The Key to Quality Service Level Management
By Karsten Smet ITIL has clear definition of Service Level Management and goes into considerable detail on the process, implementation and content of the key deliverable, the Service Level Agreement (SLA). The question is, is the SLA really the key deliverable?
PRINT
COMMENT
By Karsten Smet
ITIL does not go in to such detail on the other items of Service Level Management that are the Service Level Requirements (SLRs), Operational Level Agreements (OLAs), Underpinning Contracts (UCs) nor the Service Catalogue.
A Service Level Agreement is a documented agreement between IT and its Customer (Internal to an Organisation), on the levels of a service being provided. The most important aspect of a SLA is that it is an Agreement and bears no contractual weight to meet these targets. It is a commitment. The SLA should not favour one side. It is a fair reflection of the business requests and requirements, and those that IT can provide. It should not be a smoking gun pointed at IT, nor does it relieve IT from providing adequate service to the business. It does however set expectations. The obvious risk of missing Service Levels is damage to the business. Yet another and just as important is the effect on Customer perception that can ultimately result in the loss of faith in IT. Another common flaw is the inability for organisations to create agreements that are simple and concise. A SLA should be no more than 3 to 4 pages, not twenty (very common).
Do we put too much emphasis on SLAs? To answer that question, we need to understand where this agreement originates. It is equally important to understand the business requirements for any services IT provides and that they are concise and well documented.
ITIL has clear definition of Service Level Management and goes into considerable detail on the process, implementation and content of the key deliverable, the Service Level Agreement (SLA). The question is, is the SLA really the key deliverable?
The purpose of this article is to discuss these important parts of a SLA and to provide guidance on their uses. The outcome will be an understanding of why ITIL places so much importance on the production of SLAs. Service Level Agreements
A Service Level Agreement is a documented agreement between IT and its Customer (Internal to an Organisation), on the levels of a service being provided. The most important aspect of a SLA is that it is an Agreement and bears no contractual weight to meet these targets. It is a commitment. The SLA should not favour one side. It is a fair reflection of the business requests and requirements, and those that IT can provide. It should not be a smoking gun pointed at IT, nor does it relieve IT from providing adequate service to the business. It does however set expectations. The obvious risk of missing Service Levels is damage to the business. Yet another and just as important is the effect on Customer perception that can ultimately result in the loss of faith in IT. Another common flaw is the inability for organisations to create agreements that are simple and concise. A SLA should be no more than 3 to 4 pages, not twenty (very common).
ITIL identifies how to make this work across large organisations with multiple services. Customer based SLAs (one SLA per Customer across multiple services), Service Based SLAs (one SLA per service) and multi-tiered SLAs (Corporate based SLAs, Customer based SLAs and Service Based SLAs in three tier format) all offer the ability to enable simple and easy to manage SLAs. Use simple, achievable rules when creating metrics that apply to SLAs, OLAS and UCs. Too many organisations spend far too long coming up with encompassing SLAs that in truth are not measurable and will never provide an understanding of how the service is performing. The time spent creating these large documents is a waste. Service Level Requirements
Do we put too much emphasis on SLAs? To answer that question, we need to understand where this agreement originates. It is equally important to understand the business requirements for any services IT provides and that they are concise and well documented.
In a mature ITIL environment, the Service Desk (where appropriate) will support gathering the requirements. They are speaking to Customers everyday, and frequently liaise with the Availability Manager to discuss the Customers perception of the service. Even with a Service Desk in place, the ability to gather and document a true set of Service Level Requirements and then construct into a SLA is far from simple. IT and the business speak a different language. Customers should communicate in their own words what they need from a service. Avoid the SLA headings such as "Availability, Throughput etc." as these will mean little to an everyday User or Customer. In an ideal world where time is not an obstacle, it is useful to sit with Customers who use or will use a service for the first time and understand their requirements, not just take what they say and translate to "what we think they want".
Once it is clear what they want from a service and you understand what they mean from their requirements, it is possible to begin to transform the information into an SLA. The basic template should be derived from, and maintained within Service Level Management. It may be that certain headings of the SLA template are not applicable and if this is the case, there is no reason to create additional requirements.
To better understand the translation of their requirements to a SLA, and to gather a picture of what each section of the SLA means, completely focus the draft on the Customer and review with the business. From this, negotiations can then begin. Once IT is confident they understand the requirements, they are in a good position to evaluate whether they can achieve these goals, or offer options. The best way for IT to ensure the customer appreciation of why a requirement can or cannot be met is to translate the service into financial terms (extra cost of 24x7 availability). The negotiation period will often result in multiple draft SLAs but the focus must always remain on the most we can provide our Customer without overextending IT.