Introduction

ITIL has clear definition of Service Level Management and goes into great detail regarding the process, implementation and the content of the key deliverable the Service Level Agreement (SLA). The question is, is the SLA really the key deliverable? ITIL does not go in to great detail of other items that form the make up Service Level Management and in particular Service Level Requirements (SLRs), Operational Level Agreements (OLAs), Underpinning Contracts (UCs) and the Service Catalogue. This article focuses in more detail on these items and aims to provide detailed guidance on their production. The final outcome will be an understanding of whether ITIL is too focused on the production of SLAs?

Service Level Agreements

Although this article will not focus on SLAs it is vital to outline what we mean by an SLA. 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. In my opinion the most important aspect of an SLA is that it is an Agreement and hence bears no contractual weight to meet these targets but it is still a commitment. The SLA should not favour one side but be a fair reflection of what the business wants and what IT can provide and not a smoking gun held pointing towards IT or a method of avoiding providing an adequate service to the business. 

It does however set expectations’ of what should be provided. The obvious risk of missing Service levels is damage to the business however one of the biggest failings of not hitting agreed Service Levels is the effect this will have on Customer perception that can ultimately result in Customers losing faith in IT.

Another common failing is the inability for organisations to create agreements which are simple to read and concise. An SLA should not be twenty pages long (and my experience this is not uncommon) but be simple, easy to read and preferably no longer than 3 to 4 sides of A4. ITIL itself identifies ways of making this work across large organisations with multiple services. The use of Customer based SLAs (one SLA per Customer across multiple services), Service Based SLAs (one SLA per service), and multi-tiered SLAs where there will be Corporate based SLAs, Customer based SLAs and then Service Based SLAs in three tier format all offer the ability to enable the creation of simple easy to manage SLAs.

In a previous article I have mentioned the Mathematics of Service Management and some simple rules to follow when creating metrics. These rules can be applied to SLAs, OLAS and UCs. Many organisations spend far too long coming up with encompassing SLAs that in truth are not measurable so never give an understanding of how the service is performing, therefore all the work put in to their creation is wasted.

Service Level Requirements

As mentioned at the very start of this article do we put too much emphasis on SLAs? To begin to understand this, the first question one should ask is where does this agreement come from? To ensure that an SLA can be drawn up and be a fair reflection of business and IT it is vital the business requirements for any service can be clearly understood and documented. In a mature ITIL environment gathering the requirements will be supported by the Service Desk where appropriate, who are speaking to Customers everyday, and frequent liaisons with the Availability Manager to discuss the Customers perception of the service but even in this environment the ability to gather and document a true set of Service Level Requirements which can then be made in to an SLA is far from simple.

The simple fact is that IT and the business speak a different language. To enable requirements to be gathered it is vital that initially Customers are simply asked what they need from a service avoiding the focus on 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 issue it is useful to sit with Customers who use a service (or in a service being created for the first time, through development, build, UAT etc) 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 system and you understand what they mean from their requirements it is possible to begin to transfer 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 an SLA are not applicable and if this is the case there is no reason to merely create requirements. This draft should be totally focused on the Customer and reviewed with the business to allow them to understand the translation of their requirements to an SLA and gather a picture of what each section of the SLA means.

From this negotiations can then begin. IT should go away with the requirements and understand if these can be met and where not be able to offer reason and options. The best way to ensure the business can appreciate why a requirement can or cannot be met is when it is put in financial terms (extra cost of 24 hour availability). The negotiation period will often result in multiple draft Agreements but the focus must always be what is the most we can provide our Customer without overstretching IT.

Operational Level Agreements

Now we understand where the agreement comes from how can we begin to ensure that the levels are met within IT? Operational Level Agreements (OLAs) are internal. The easiest way to look at an OLA is that it is an agreement within IT, which does not include an external supplier or internal Business Customer. 

To ensure an SLA is met it is vital that IT works together to ensure the targets can be hit. A vital piece of the Service Level Management process is prior to implementation of an SLA is that any OLAs and UCs are reviewed. What is the point in creating an SLA, which cannot be met because internally, between support teams, there are no targets? 

An OLA follows a very similar (if not identical) structure to an SLA. It can be interested in the typical areas highlighted in SLAs such as Service Hours, Responsibilities, Support details etc. however the requirements internal support groups have on each other are very different to those outlined in the SLA which encompasses a business perspective. This will mean the language used in OLAs and focus will usually be more technical than in SLAs. 

It is acceptable to have OLAs that do not focus on typical SLA items such as Availability and Service Hours but are merely a set of statements agreed between IT areas because there is no specific Service to measure. This could be between an IT area and IT procurement where there is no IT service but without this in place IT kit may not be purchased in time to support SLAs somewhere else in the business.

A common misconception of OLAs is that every SLA has a specific set of OLAs in place to meet them. This would result in departments having multiple, potentially duplicate, OLAs and become unmanageable and impossible to measure. An example of an OLA that every IT organisation should have in place is between the Service Desk and the support groups. This is vital in restoring service and hence part of meeting all SLAs. 

OLAs are notoriously difficult to get in place, as internal areas often do not want to feel that one area is being pressured more than another. It begins an interesting internal IT battle where it is vital that the Service Level Management team are empowered to make decisions.


Underpinning Contracts

Underpinning Contracts (UCs), often called Schedules, are contractual agreements between any third party suppliers of IT Support to your IT Organisation. It is vital to keep these up to date and ensure that the third party will provide required levels of support as necessary. This is different to an OLA and SLA because it is contractual so these targets MUST be met once agreed and failure for meeting these targets may well result in legal action.

The UC will be full of legal jargon and hence will also be larger than an SLA or OLA and is more complex to read. The important thing to remember when writing and agreeing an Underpinning Contract is to ensure you aim the targets at the correct level. For example if your Service Hours are too high the Contractor may charge more for their service, if they are too low an Organisation may incur large costs for out of hours support. This is a fine balance but one which must be accurately managed by the Service Level Manager and their team.

Service Catalogue

How do we know what Services we provide and hence what needs an SLA in place? This is the one of the jobs of the Service Catalogue. The Service Catalogue is often overlooked in its importance. The best way to approach the population of a Service Catalogue is to understand what Services the Customers perceive. It is not uncommon for a Customer to have a single service that is made up from three or four separate applications where at least one of these is invisible to the business. 

By asking Customers (i.e. SLRs) you can begin to document what goes in to the Service Catalogue, where the complete set of ITIL processes are in use it will be possible to get some of this information from the Service Desk who receive comments directly from Customers on the Services provided. Any Service Management tools should also be audited as Services forgotten about by IT may still be active and have had Incidents, Problems and Changes logged against them. The Configuration Management Database will also outline Services, but the key is always to understand the Customers perception.

A Service Catalogue can appear in many different formats such as word documents, spreadsheets etc. and ITIL does offer guidance on the sort of information captured in the Service Catalogue, however expanding on this to make a catalogue a worthwhile within an IT support Organisation I personally feel the following items should be considered;

• Service Name
• Basic Service Description
• Key Business Users
• Importance of Service
• Key Support areas
• Planned Maintenance/Outage data
• SLA (in place and where it is located)

By providing slightly more information it is possible to use this resource within a Service Desk to support the allocation of priority to faults and direct Incidents to the relevant area alongside the Configuration Management Database. This will also aid in the general support Service Desk staff can give to improve Customer satisfaction through system knowledge, understanding Customer usage etc. The Service Catalogue should also facilitate the ability for organisations to ‘speak the same language’. 

Conclusion

I personally empathise with ITIL in its reluctance to detail how to use OLAs, SLRs, UCs and the Service Catalogue because these subjects are not simple to define. The techniques in writing and documenting SLAs are much more prescribed than any of the other areas that are open to debate and an Organisations ‘Service Level Management groups’ perception of the framework. It could be a weakness that this is the case as many companies have decided against OLAs and UCs and use SLAs throughout their IT support structure which will often detract, and potentially destroy, the benefits delivered by Service Level Management due to the prescribed format of SLAs which will not fit third parties and internal support groups., however every organisation is different and hence every OLA and UC format will also differ from organisation to organisation. 

ITIL is very focused on the production of SLAs but I do not believe that they over emphasise this point. The framework is very much Customer based and trying to improve the IT service that is provided to the business and hence looks at how the production of SLAs helps support this. The important thing to realise is that SLAs are pointless if they mean nothing and without the deliverables highlighted within this article Service Level Management will fail as a process. If SLAs are the key deliverable of SLM then it is fair to say that the above deliverables are the locksmith cutting the key to ensure it fits the Service Level Management lock.