Blog

Service Level Management 

the team holding the gears - building the process of Service Level Management
the team holding the gears - building the process of Service Level Management
Cat:
Publication date:

Introduction

Service Level Management is one of Service Design processes. The fact should be enough to say that it’s one of most important processes, and indeed it’s. According to us it’s of crucial importance for two business aspects namely customer satisfaction and financial effectiveness of the service provider. 

Reading ITIL we can learn that objective of SLM is to: 

  • negotiate Service Level Agreements (SLA) with the customers, 
  • design services in accordance with the agreed service level targets, 
  • ensure that all Operational Level Agreements (OLA) and Underpinning Contracts (UC) are appropriate, 
  • monitor and report on service levels. 

The SLM process is very often associated only with the more formal part of it, namely ensuring that all the SLA are in place and service levels are monitored. However the question is how to organize the SLM processes in a meaningful way so that it delivers value to both customers and service provider. 

In this article we would like to share EvergoPartners experience and thoughts around practical aspects of the SLM implementation on the interface with customer as well as within service provider organization. 

SLM – SLR and SLA 

From what we have seen so far the SLM process exists on the interface with customer in a form in almost every organization. Actually it’s hard to imagine that there is no agreement between customer and service provider that defines service levels, the SLA. The question is if the service levels agreed in the agreement are optimal for both customer and service provider. The risk on the customer side is that service levels might be too high or oversized and as a result the price for the service is too high. On the other hand it can happen that service levels are too low that can result in problems once the service is live. The risk on the service provider side is that it can’t be able to meet the service levels that was agreed at least at the prices that was agreed. 

So, how to achieve situation when the risk are minimized and mitigated. Here it’s where the SLM process gives a helpful hand. 

To start we have to gather customer requirements. This is the entry point of the process. It’s really recommended that gathering and managing of the requirements is well structured. To capture the requirements we need list all the elements that have impact on the service levels and ultimately are reflected in the Service Level Agreement. The document is called Service Level Requirements (SLR). The content of the SLR may vary depending on the service provided however below you can find a basic list that can be considered at start. 

* Service requirements 

  • Capacity requirements: 
    •  Number of users, 
    • Number of concurent users, 
    • Requirements regarding changes of the capacity 
  • Availability requirements 
    • Service standard times 
    • Service critical times 
    • Max. time when service can be unavailable 
    • Availability thresholds (e.g. 99,5 %) 
    • Response times from application 
  • Service request requirements 
    • Standard service request requirements 
    • Non-standard service request procedures 
  • Incident handling requirements 
    • Types of support (by phone, by remote access, on site)
    • Support times for 1st Line (Service Desk) 
    • Reaction Times,
    • Resolution Times (depending on priority) 
    • Escalation procedures 
  • Planned service interruptions procedures 
  • Unplanned service interuptions procedures 
  • Change request requirements 
  • Security requirements 

In general the SLR should be filled in by customer as it is supposed to reflect what they need from the service to support their business processes. However we need to be aware that it’s not one time exercise. According to us it actually requires thorough and sometimes multiple discussions with customer so that both parties have common understanding of the requirements and their impact on the future cooperation, not mentioning the price for the service. It helps to rationalize customer expectations as it happens they require more than they actually need. On the other hand it also helps to find the gaps i.e. things the customers didn’t think about or underestimated. Common agreement on the SLR constitute the foundation for SLA. 

From what we have observed there is a common tendency to focus on functional requirements rather than on service level requirements and in some cases even disregard the second one at the initial phase of service design. Instead we recommend to put the service level requirements in focus to ensure that both parties have clarity on this from the very beginning. 

SLM – OLA and UC 

Once we have the clarity on the service level requirements we need to ensure that they are reflected throughout the service chain. As service delivered to customer (Business Facing Service) usually consists of multiple underlying Technical Services (also called Supporting Services) we need to secure that service level requirements can be supported by the Technical Services as well. 

Let’s take a simple example and imagine a Business Facing Service that consist of an application service hosted in a central datacenter that relies on WAN service that allows the customer to access the service from remote location. The SLR for Business Facing Service is 99% for availability is 2 hours for resolution of high priority incidents and indeed the application service availability is 99% and resolution time for high priority incidents is 2 hours. However for WAN service the corresponding parameters are respectively 97 % and 4 hours. At a first glance we can see that there is a gap but surprisingly this obvious fact is often neglected. 

Based on our experience we can say that it happens quite often that service levels agreed with customer are not compatible with service levels agreed between different organization units managing different technical services if they are agreed at all. It creates an obvious risk for service provider that it will not be able provide the service on the levels committed to customer. What worse in many cases the risk is unknown. 

This is the place for an Operational Level Agreement (OLA). The OLA describes the responsibilities of each internal support group toward other support groups, including the process and timeframe for delivery of their services. The objective of the OLA is to present a clear, concise and measurable description of the service provider’s internal support relationships. 

So, what is required to get the OLA agreed. First of all we need to know all the dependencies between Business Facing Service and underlying Technical Services as well as between Technical Services. In other words we need decomposition of Business Facing Service into Technical Services and relationships between them. Once it’s done we need to get an agreement between the organization units responsible for Technical Services being in the service chain. 

In our example there must be an OLA between unit responsible for the application service and WAN service. If we want to be on the safe side and meet customer expectation regarding service levels the WAN service must be upgraded. It will most likely have impact on WAN service costs and price of the Business Facing Service. 

It can also happen that one or many of Technical Service are being purchased from 3rd party or support for the Technical Services is provided by the 3rd party, entirely or partially. It’s the place where so called Underpinning Contracts (UC) come into picture. The UC is an agreement between service provider and 3rd party based on which the 3rd party provides supporting services that enable the IT service provider to deliver a service to a customer. Similarly to the OLA the UC must be aligned to SLA. 

In our situation it can be that both application service and WAN service can have their UC that must be aligned to the SLA. 

Summary

It’s been our (EvergoPartners) observations that many companies do not implement SLM end to end covering the whole service chain. It can create a risk and hence can’t be acceptable. From our perspective critical prerequisite for proper implementation of o the SLM is decomposition of Business Facing Services into Technical Services and clear ownerships of Technical Services within the IT Service Provider organization. Once it’s done the implementation of the SLM process can be much easier task but still requires some effort which we will be more than happy to share with You.