Understanding the Service Level Agreement
In essence, the SLA describes the service and the quality measures by which the delivery of that service will be judged. It is also an opportunity to clarify what is and is not provided. In addition to the service provider responsibilities, any customer responsibilities are also stated here.
It is important that the SLA is an actual written agreement, not a vague “understanding.” It should be signed by all parties to the agreement, including the service provider and the customer. Ensuring that the signatories have the authority to make the agreement is important; often the SLM will do all the preparatory work, but the IT director actually signs, showing that the commitment is that of the whole department.
The SLA should be written in plain language, with as few technical expressions as possible; where these are unavoidable, a glossary should be provided. It is crucial that the business users understand what the technical commitments actually mean. If the agreement is with an internal service provider, legal terminology is unnecessary and can cause confusion.
What Does an SLA Contain?
Let’s examine the typical contents of an SLA.
The first essential element in a good SLA is a simple description of the purpose and scope of the document so that any reader is clear what the intention is. Typically this might consist of a statement such as “This document is the service level agreement between the IT department of Company A and the customer department of Company B for the provision of (specified) services within the head office and branch offices of Company B. Provision of services to overseas subsidiaries are excluded from this agreement.” Even better is to also include a description, in business terms of the service, such as “The (specified) service tracks delivery of orders from the warehouse to the end customer using GPS data.”
As with all important documents, it should be clear the period to which the agreement applies: “This agreement is valid from January 1, 2012, until December 31, 2012.” Version numbers are also essential, if any changes are to be tracked. It is good practice to review and reissue SLAs annually, even if there have been no changes. This is to ensure that any changes that take place in the service or in the organization are picked up and included in the SLA. It is a good idea to define the SLA as a document configuration item, subject to change management.
It is important to make the distinction between the service and the support provided for that service and to specify the hours that each of these is available. For example, email may be available 24 hours a day, but support may be offered only between 9 a.m. and 5 p.m. A fault occurring at 6 p.m. will not be responded to until the following day. There should be no confusion regarding the support hours, because it will be these hours that are used to judge whether an incident response or fix met the target.
What level of availability and reliability has been agreed on? (We will be looking at availability management in more detail in Chapter 6.) Is the level of availability expressed in business terms, such as “no more than five breaks, with a total combined downtime of two hours in any month,” or in a less meaningful 99.x percent?
The SLA should state what level of throughput is reasonable. If the business decides to employ temporary staff to clear a backlog of orders, resulting in twice as many transactions per hour, will the service still be guaranteed at the same response time?
The situation regarding any service continuity provision should be stated. This might be a target for the return of the service following a disaster or major disruption. However, if there is no such plan, this should be stated. “In the event of a major disruption, there is no guaranteed target for a return to normal service provision. Service will be restored as soon as possible.” In this situation it is permissible to use the expression, “as soon as possible” as in the event of a major disruption, which has not been planned for, the IT department would do the best they could, but cannot give any guarantees.
Security aspects of the service should be stated in the SLA. What security is provided by the service provider in terms of data protection, encryption, and so on? What are the customer responsibilities for safeguarding passwords, or for ensuring unattended screens are always locked and so on.
The SLA should state the method used to calculate priority levels for incidents and state the target times for incidents to be resolved and requests to be fulfilled. It should be clear whether this target applies to all incidents and requests; some service providers are unwilling to make commitments that they may not achieve, so they commit to a very low service level. Stating in the SLA that the target is, for example, “90 percent of all priority-one faults will be resolved within two hours” means that exceptional circumstances leading to a short-term drop in service (such as a snowstorm preventing engineers from getting to work) will not cause an SLA breach, so the provider is willing to commit to a faster response.
Other possible SLA contents would include specifying agreed downtime for maintenance and critical business periods when changes would not be applied to the service.
If the service provider charges for providing services, the basis for charging should be stated clearly. Is it a charge per head or a charge for particular elements, such as per gigabyte of storage, and so on? Is there a rebate if service fails to reach the agreed standard?
Finally, the methods by which the service provision is to be judged should be stated. What reporting will be provided? How frequently will service review meetings be held? Who will attend?
Building the SLA
As stated earlier, every service provided consists of a number of elements. To make a commitment in an SLA, the service level manager must be confident that each part of that service will be delivered to the required standard. This is achieved by ensuring that agreements exist with the internal teams providing elements of the service and that the necessary contracts exist with third-party suppliers to underpin those aspects of the service provided by external bodies. Taken together, these agreements form the basis of what can be promised in the SLA. We are going to look at these different agreements in the following pages.
Let’s look first at operational-level agreements (OLAs). These are straightforward agreements between internal support departments or other internal departments who are supplying an element of the service. Typical commitments might include the hours during which support is provided, what level of on-call support is provided, what technology each team supports, and what is outside their area of expertise. Commitments to follow the agreed processes may also be included, such as a commitment to monitor the queue of incidents on the service management tool set at least hourly and to provide regular status updates on outstanding incidents.
OLAs describe the commitments for each IT team; sometimes other internal teams involved in providing the overall service may be included (such as office facilities, the training department, and so on). As you have seen, these agreements can be simple and are often not more than one or two pages. As with SLAs, the signatories must hold the authority to make the commitments contained within the agreement.
A useful tip when trying to understand what OLAs are required for a particular service is to use the RACI matrix described in Chapter 7. All those areas where responsibility was identified are potential areas for inclusion in an OLA.
As with SLAs, the work does not stop with signing the agreement; the monitoring and reporting of OLA performance against the agreed targets is an ongoing SLM responsibility. Any deviation from delivering against these targets must be identified and addressed if the customer SLA is to be delivered. Failure to deliver against an OLA may cause a breach in SLA targets. Simple reporting against OLA targets, showing a rolling 12-month trend, will identify any areas at risk of breach or any gradual but continual deterioration. The service level manager has to identify and act upon any such issues, taking these up with the relevant team manager, possibly as part of an overall service improvement plan (SIP).
It is recommended that OLAs be reviewed at least annually, or after any major reorganization, to ensure that they remain current; they may also be identified as configuration items (CIs), subject to change management. Categorizing OLAs and other agreements as CIs ensures that the relationship between a service and its supporting agreements is clear and the impact of any changes is fully considered. For more details about configuration items and their relationship to change management, see Chapters 8 and 9.
The second set of agreements that need to be in place to support a service level agreement are the underpinning contracts (UCs). These agreements are with the external organizations that provide elements of the overall service. Because these suppliers are external, these agreements will be contractual and therefore legally enforceable. As with OLAs, the service level manager must identify which third parties provide elements of the service provided in the SLA and ensure that the targets within the UC are at least as demanding as the resolution targets within the SLA. Working with the supplier management process, the SLM must ensure that sufficient monitoring and reporting are in place to confirm that the contracted service is being provided to the required level. Typical third-party suppliers might include Internet service providers, hardware and software maintainers, and so on. As stated earlier, the contractual nature of UCs will mean that the language used in these agreements will often be legalistic; however, it is important that the required service targets are clear and unambiguous.
Every commitment in the SLA should be supported by an underpinning agreement, either an OLA or a UC.
Figure 5.1 shows the relationship between the various agreements.
FIGURE 5.1 The service relationships and dependencies
Based on Cabinet Office ITIL® material. Reproduced under license from the Cabinet Office.
Structuring the Agreement
An important decision taken during the planning phase of implementing SLM is to decide upon the most suitable SLA structure for the organization. There are three options specified by ITIL: customer-based, service-based, and multilevel, each with advantages and disadvantages:
- A service-based SLA is one in which each SLA refers to only one service. The service described is provided to all users of that service, so the requirements of all customer groups need to be ascertained. This option is useful for organization wide services such as email. There are disadvantages to this approach, however. The service provided across all locations may not be of equal quality, because of network issues, for example. Different departments may have differing requirements. This requirement can be addressed by agreeing on gold, silver, and bronze service levels within the SLA. Difficulties can also arise when trying to identify the appropriate signatory to the agreement, because the service is provided to many customer groups. An external service provider may also use this type of agreement for a standard service in their catalog.
- Another option is to have one agreement covering all the services provided to a single customer or customer group. This is called a customer-based SLA. For example, the human resources department would have a customer-based SLA, as would the finance department, and so on. This is straightforward from the customer point of view, because all the services they use are in a single agreement. It is also a fairly easy to identify the appropriate signatory. From the IT provider’s viewpoint, however, customer-based agreements means that the same service may appear in multiple SLAs, which can be difficult to monitor.
By using a combination of service-based and customer-based SLAs, the service level manager can provide a simple framework, covering all services.
- The third option is a multilevel SLA. This option has three levels:
- The corporate level contains information that is applicable to all users across the organization. This saves a lot of repetition of this information in every SLA and should not need frequent updating.
- The customer level contains information that is applicable only to that particular customer, whatever service is being used.
- The service level will contain information on a particular service as it is delivered to that particular customer. There may be several of these sections.
The multilevel SLA prevents unnecessary duplication of effort and can be a very effective approach. It does require that the SLM understands the relationships between the various services and customers (Figure 5.2).
FIGURE 5.2 Multilevel SLA structure
Based on Cabinet Office ITIL® material. Reproduced under license from the Cabinet Office.
