What does Service Level Management (SLM) Do In ITIL?

Introduction

Service Level Managers are also called Service Managers or even Service Delivery Managers in many organisations. This is a very key role in the ITIL® landscape and is central to managing customer expectations and customer satisfaction. Good Service Level Managers are in high demand, and the experience levels vary from about 6 years upwards.

With a higher level of experience, a service-level manager may become more adept at managing more complex IT landscapes or more complex outsourcing organizations, e.g. a multi-vendor setup. The Questions below are likely to be useful to aspiring Service Level Managers, during an interview, and after they land a new job.

It is packed with experience garnered from complex IT Service Management landscapes and while the answers follow the ITIL guidance, this is not what you will typically get in ITIL books. Therefore, the information presented is an add-on, as opposed to presenting what is already available elsewhere.

1. What is meant by ‘Service Level’? How is it determined and who determines it?

Service Level or level of service is a quantification of the scope of services. E.g. if Incident Management is a service that is provided, the IT service provider may provide some commitments on – the number of incidents resolved on a business day, the response and fix times (in minutes or hours) per level of severity, the lead time (in days) to provide a major incident report etc. Levels of service must be defined for every service provided. 

Often, levels of service are associated with financial rewards or penalties. Target service levels will typically be defined during the Service Design phase of the ITIL Lifecycle and the actual performance will be measured during the Transition, Operations and Continual Service Improvement phases.

Context of the service provisioning determines the committed service levels, but common influencing factors are – system documentation, system stability, user base, user experience design considerations etc. The technology expertise of the service provider is also important, e.g. a service provider who specialises in a technology may be able to commit to better service levels than a more generic service provider. 

Service levels are defined during the Service Design phase and the Service Level Manager defines these, with inputs from the Business Relationship Manager and in consultation with the customer and by leveraging the capability model of the service provider.

2. What does Service Level Management (SLM) hope to achieve?

The primary objective of service level management is to define, document, agree, monitor, share, report and review the level of IT services provided. SLM also ensures that appropriate information is available to Business Relationship Management so that the latter may have more effective communication with stakeholders.

Metrics collection is an ongoing process in the later phases – Transition, Operations and Continual Improvement. SLM should have the tools and methodology to analyze and make decisions regarding re-calibration of the service levels.

Apart from defining the service levels, SLM also ensures that IT and the customers have unambiguous expectations on the levels of service to be delivered. While BRM owns the customer satisfaction survey process, the SLM process ensures that the survey results can be mapped to the agreed-upon service levels.

Last, but not the least, SLM is also responsible for improving the levels of service delivered by the provider organisation. Improvements are not only necessary in the context of low customer satisfaction but also important for customer delight, especially in a scenario where there are many other competitors IT service providers, which is typical in an outsourcing scenario.

3. What are the prerequisites for a Service Level Manager to be successful?

There are mainly a couple of things that are inputs to the SLM process – the Service Portfolio and the Service Catalogue. These prerequisites define the scope of services to those managed by SLM.

The Service Catalogue should be the single source of truth for the description of services agreed upon by a customer. Among other things, the description for each service should include current details, status, interfaces and dependencies on other services (which may well be provided by other IT service providers). These services could be current services being consumed or even the ones that are being designed, developed or transitioned into the live environment.

The Service Portfolio is a superset of the Service Catalogue. It exceeds the latter in terms of its scope i.e. it also includes information on ‘retired’ services, i.e. services that are no longer offered.

The Service Portfolio is internal to the IT service provider and includes all the services that are offered to all customers.

To understand with an example, if an organization is providing Incident and Problem Management services to customer A and Problem Management and Change Management services to customer B, then the Service Portfolio of the provider will include Incident, Problem and Change Management. However, the Service Catalogue for customer A will include only Incident And Problem Management (but not Change Management), and for customer B will include only Problem and Change Management (but not Incident Management).

To put it in another way, the Service Catalogue is a customer-specific subset of the Service Portfolio, that is visible to the customer.

4. Have you heard of SLAM charts? What are these and why do we need them?

SLAM is an acronym for Service Level Agreement Monitoring, and SLAM charts are visual depictions of the actual level of compliance against the agreed levels.

SLAM charts are built on top of data that is provided by the Service Transition, Operations and Continual improvement processes. The concept of SLAM forms the basis of many of the tools that are in use today to monitor the health of IT services and infrastructure.

SLAM charts will almost always include some visual aids to denote the health levels – usually on a Red-Amber-Green (RAG) traffic-lighting model, where Red is poor health and needs immediate attention, and Amber denotes services that need to be monitored so that they do not slip into the Red zone.

Online tools and most of the cloud service providers will use SLAM charts for their customers built using agreed thresholds defined during the service design phase. E.g. two customers A & B, both requiring 98% Availability of a service may have different tolerance levels for service degradation. Customer A may define an Amber threshold as 96% to 97.99%, while customer B may have a more relaxed lower limit at 92% but a slightly stricter upper limit at 98.10%.

Dynamic SLAM charts may be used extensively by the operations teams such as the Application Management and the Technical Management Teams as well as the Service Desk. Modern tools allow drill down to the service level.

SLAM charts are also used in service status reporting and in re-defining the service strategy – in the BRM process. They are a sure-shot source of current and historical information (trends over time) for the stakeholders involved in Service Improvement – for increased customer satisfaction and beating the competition.

5. What is an SLA? Does it always have to be documented?

The SLA is an acronym for Service Level Agreement. SLAs must always be mutually agreed upon and between the customer and the IT service provider and documented. SLA information must be available to the ‘people on the ground’ – namely the development, application management, technical management and Service Desk teams.

SLAs will be referenced in the contract, and be used to arrive at contract pricing, as well as in defining rewards and penalties for the organization providing the services.

Contracts are legal documents, so, there is always a possibility that the contents of the SLA documentation will be referenced during any legal proceedings. E.g. for medical equipment running on software at a hospital, there may be an SLA for providing on-site technical services in case of failure during surgery. Failure to do so may risk the life of a patient, and therefore invite legal action against the service provider.

With the above, it is quite evident that SLAs must always be documented without exception.

The SLA must only contain what can be effectively monitored and measured. This is because it is difficult to define any contractual reference to subjective items.

6. A very junior member of your team is curious about ‘OLA’. How do you explain it to her?

OLA is an acronym for Operational Level Agreements. An IT service provider will typically agree to provide certain services at specified levels.

This is documented in the Service Level Agreement (SLA). However, in the real world, the service provider organization may need to contract with other organizations, or even with other internal departments. Let us see this with a couple of examples.

Let us say the customer contracts with an IT Service Provider X for providing Incident Management, Problem Management and Change Management services for System A. System A interfaces with a backend system B, which is serviced by another IT service provider Y.

Upon investigating an incident, the Application Management team infers that the real issue lies in System B, so they pass the incident to the team in Organisation Y. Now, ownership for adhering to the service levels for the incident still lies with Organisation X. What if the team in Y accepts the incident, but reduces priority because they have other incidents to look at?

How can org X ensure that Y attaches due importance to this incident? Through an OLA. Org X must formalize an OLA with Y, so that this incident is taken up within the OLA. For all such delegated Severity 3 incidents will be turned around in no more than 20% of the overall SLA resolution. So, if the agreed service level with Org X for Severity 3 is 10 business hours, the expected turnaround time from Org Y is 2 hours.

7. Describe a typical day in the life of a Service Level Manager.

The Service Level Manager is the process owner for the Service Level Management (SLM) process. This is a critical role, and he wears many hats at a time. With the customer, he needs to negotiate and agree to the service levels for each service in the Service Catalogue – some of these would be for current services, and some for future services. Agreements may also be needed for improvements to service levels for current services, e.g. the IT Service Provider may commit to a 98% compliance for Year 1 of the contract and promise a 0.5% improvement Year-on-Year (YoY) basis. So, effectively, they are committing to 98.5% compliance in Year 2 and 99% in Year 3.