ITIL Service Level Management
Adopting the Service Level Management (SLM) process is a key principle of CSI. While in the past many IT organizations viewed SLM as merely a smattering of isolated agreements around system availability or help desk calls this is no longer true. SLM is no longer optional. Today's business demands that IT be driven by the service model. This service orientation of IT toward the business becomes the foundation for the trusted partnership that IT must endeavour to create. Today IT is a core enabler of every critical business process. IT can no longer afford to operate as the 'geeks in the basement' but rather must strive to be included in every channel of communication and level of decision making all the way to the boardroom.
SLM involves a number of steps:
- Fully accepting that the IT organization must become a service provider to the business or cease to be relevant
- Involving the business and determining their service level requirements
- Defining the internal portfolio of services: services that are planned, in development, in production. This service portfolio also contains modular or component services which will make up a finished service package
- Defining a customer-facing Service Catalogue which details every service and service package offered by IT with options, parameters and pricing
- Identifying internal IT departmental relationships, negotiating the terms and responsibilities of the internal relationships, and codifying them with Operational Level Agreements (OLAs)
- Identifying existing contractual relationships with external vendors. Verifying that these Underpinning Contracts (UCs) meet the revised business requirements. Renegotiating them, if necessary
- Utilizing the Service Catalogue as the baseline, negotiate Service Level Agreements (SLAs) with the business
- Create a Service Improvement Plan (SIP) to continually monitor and improve the levels of service.
Once the IT organization and the business begin working together through Service Level Management, IT management soon realizes that the old definitions of 'successful IT' are beginning to fall by the wayside. A high network availability percentage or great ratings in a customer satisfaction survey are no longer the end goal but merely positive metrics rolling towards the achievement of a service level. IT management understands that with the adoption of Service Level Management a fundamental shift has taken place. The definition of success in IT is now crystal clear. It has become the service level - a set of expectations mutually agreed to by IT and the business. IT is then structured, managed, staffed, funded, and operated to meet or exceed the service levels. The service level rules and everything else is just details. A complete SLM process is defined in the ITIL Service Design publication.
More on Service Level Management
Read more on Service Level Management here:
Service Level Management - Service Level Agreement
A service level agreement is a document which defines the relationship between two parties: the provider and the recipient. This is clearly an extremely important item of documentation for both parties. If used properly it should:
- Identify and define the customer's needs
- Provide a framework for understanding
- Simplify complex issues
- Reduce areas of conflict
- Encourage dialog in the event of disputes
- Eliminate unrealistic expectations
Specifically it should embrace a wide range of issues. Amongst these are usually the following: Services to be delivered Performance, Tracking and Reporting Problem Management Legal Compliance and Resolution of Disputes Customer Duties and Responsibilities Security IPR and Confidential Information Termination
Although an SLA is an excellent expectations-managing mechanism, it's important to manage your own expectations of what it can realistically accomplish. Unfortunately, some people view an SLA as a complaint-stifling mechanism or a quick fix to a troubled relationship; however, using it for such purposes creates more problems than it solves. Instead, think of an SLA as:
- A communications tool. The value of an agreement is not just in the final product; the very process of establishing an SLA helps to open up communications.
- A conflict-prevention tool. An agreement helps to avoid or alleviate disputes by providing a shared understanding of needs and priorities. And if conflicts do occur, they tend to be resolved more readily and with less gnashing of teeth.
- A living document. This is one of its most important benefits. The agreement isn't a dead-end document consigned to the Forget Forever file. On a predetermined frequency, the parties to the SLA review the agreement to assess service adequacy and negotiate adjustments.
- An objective basis for gauging service effectiveness. An SLA ensures that both parties use the same criteria to evaluate service quality.
The most common way to create an SLA is to use a template. The most well known of these is The SLA Toolkit. This includes a template, but there is far more to it. For example, there is a guide to take you through the template itself, a checklist/questionnaire to review existing agreements, as well as a training presentation to explain concepts and background.
Service
A service, within the context of an SLA, is collection of IT capabilities that combine to make a business process possible. The service is used by the end user in the business to support the user's job or the objectives of the organization. It is not a specific IT thing, rather it is a collection of IT resources that make a business process possible.
For example, email is a service that is offered to the business to support various com-munications functions. It makes business communications possible in the modern world and underpins a majority of business transactions. The service is comprised of hardware, software, networking, end-points, training, and support, all of which helps allow the business to effectively communicate internally and externally. Many of the components that comprise the service - like network infrastructure - are shared across multiple services. However, the individual components are not a service in themselves. Rather, each is just one of many parts that comprise the service.
When defining a service it is critical to understand and define the service in the context of the business process it is supporting. By defining a service from the business-use perspective, the SLA will be more relevant and will help ensure that the service pro-vided supports the current and future needs of the business.
Level
The level in an SLA defines the specifics or performance criteria of how a service is delivered and should behave. The details of level are very important because they define how to measure and manage the service and ensure that the service delivered is actually facilitating the business.
Continuing with the email example, a level for email can include the size of an email inbox or the maximum time for delivering a message. When defining levels, it is criti- cal to consider the needs of the business user. If these needs are not considered, organizations risk misaligning the service with the business need. Quality discussions with business users will help in defining meaningful level requirements.
IT organizations tend to define level in terms of things that can be easily measured, such as server uptime or application response time. While system availability is a con- cern to business users, IT-centric metrics are only part of what makes a service mean-ingful to the business. IT organizations need to challenge themselves to identify the elements of level that are the essence of what makes a service meaningful to the business.
Agreement
The agreement in an SLA happens when business users and IT concur that the service and the level at which it is provided meet a business need. With agreement, IT organizations can make definitive decisions on architecture, support models, and deployment. Agreement allows business users to assess and plan for the timing, volume, and effectiveness of their processes. Most importantly, agreement makes the IT services relevant and aligned to the needs of the business.
As mentioned previously, organizations are rapidly evolving from a world based on physical processes to one based on virtual processes. If the business is going to have confidence in implementing these changes to the virtual business processes, agreement on service and the way it supports the business will be key. Agreement gives the business confidence that the service will support the business and key processes, with controls in place to ensure that their new virtual factories will be stable, quality-driven resources for the long term.
Service Level Management - Service measurement
An important beginning point for highlighting improvement is to establish baselines as markers or starting points for later comparison. Baselines are also used to establish an initial data point to determine if a service or process needs to be improved. As a result, it is important that baselines are documented, recognized and accepted throughout the organization. Baselines must be established at each level: strategic goals and objectives, tactical process maturity, and operational metrics and KPIs.
If a baseline is not initially established the first measurement efforts will become the baseline. That is why it is essential to collect data at the outset, even if the integrity of the data is in question. It is better to have data to question than to have no data at all.
Basically, there are four reasons to monitor and measure:
- To validate - monitoring and measuring to validate previous decisions
- To direct - monitoring and measuring to set direction for activities in order to meet set targets. It is the most prevalent reason for monitoring and measuring
- To justify - monitoring and measuring to justify, with factual evidence or proof, that a course of action is required
- To intervene - monitoring and measuring to identify a point of intervention including subsequent changes and corrective actions.
The four basic reasons to monitor and measure lead to three key questions: 'Why are we monitoring and measuring?', 'When do we stop?' and 'Is anyone using the data?' To answer these questions, it is important to identify which of the above reasons is driving the measurement effort. Too often, we continue to measure long after the need has passed. Every time you produce a report you should ask: 'Do we still need this?'
It is obvious that all the activities of the improvement process will assist CSI in some way. It is relatively simple to identify what takes places but the difficulty lies in understanding exactly how this will happen. The improvement process spans not only the management organization but the entire service lifecycle. This is a cornerstone of CSI.
-
Define what you should measure
At the onset of the service lifecycle, Service Strategy and Service Design should have identified this information. CSI can then start its cycle all over again at 'Where are we now?' This identifies the ideal situation for both the Business and IT. -
Define what you can measure
This activity related to the CSI activities of 'Where do we want to be?' By identifying the new service level requirements of the business, the IT capabilities (identified through Service Design and implemented via Service Transition) and the available budgets, CSI can conduct a gap analysis to identify the opportunities for improvement as well as answering the question 'How do we get there?' -
Gathering the data
In order to properly answer the 'Did we get there?' question, data must first be gathered (usually through Service Operations). Data is gathered based on goals and objectives identified. At this point the data is raw and no conclusions are drawn. -
Processing the data
Here the data is processed in alignment with the CSFs and KPIs specified. This means that timeframes are coordinated, unaligned data is rationalized and made consistent, and gaps in the data are identified. The simple goal of this step is to process data from multiple disparate sources into an 'apples to apples' comparison. Once we have rationalized the data we can then begin analysis. -
Analysing the data
Here the data becomes information as it is analysed to identify service gaps, trends and the impact on business. It is the analysing step that is most often overlooked or forgotten in the rush to present data to management.. -
Presenting and using the information
Here the answer to 'Did we get there?' is formatted and communicated in whatever way necessary to present to the various stakeholders an accurate picture of the results of the improvement efforts. Knowledge is presented to the business in a form and manner that reflects their needs and assists them in determining the next steps. -
Implementing corrective action
The knowledge gained is used to optimize, improve and correct services. Managers identify issues and present solutions. The corrective actions that need to be taken to improve the service are communicated and explained to the organization. Following this step the organization establishes a new baseline and the cycle begins anew.
While these seven steps of measurement appear to form a circular set of activities, in fact, they constitute a knowledge spiral. In actual practice, knowledge gathered and wisdom derived from that knowledge at one level of the organization becomes a data input to the next.