What is SLM? ITIL Service Level Management: Meaning, Purpose and Process

ITIL Service Level management (SLM)

Photo Attribution: Elena Pimukova/Shutterstock.com

The ITIL Guru sat at his desk, looking over the latest additions in the Continuous Improvement Register (CIR). As a CIR review board member, he liked what he saw -- more IT staff contributing improvement ideas, making him feel good about the progress. The phone rings.

"ITIL Guru. How may I assist you today?"

"Hi Guru, this is Betty. I want your help. The CIO asked me to come to her office tomorrow. She wants me to take over the role of practice owner for Service Level Management (SLM). Since the previous owner did not communicate very often to IT, I don't know what the practice does or accomplishes. Can you give me your expert opinion about the role of SLM?"

"Betty, I am always happy to help explain ITIL.

"The fact that you don't know much about SLM speaks volumes! Because SLM is the one practice that gathers all the operational metrics for all the other ITIL practices on how well IT meets business expectations and influences all five service lifecycles, SLM should have volumes to say. It is impossible to improve when you don't know how you are doing now. As Ken Blanchard says, 'Feedback is the breakfast of champions.'1

"Betty, tell me what you do know about SLM."

"I know it has something to do with Service Level Agreements (SLAs). And that an SLA is a document on how IT plans to deliver our services. That is about it."

"Well, there is so much more to SLM than SLAs. Let me try to break it down into manageable chunks for you. SLM is a unique ITIL practice. SLM's activities span most of the service lifecycles. And, most importantly, SLM regularly publishes operational metrics, a scorecard on how IT is meeting agreed business expectations.

ITIL Service Level Management Process Flow Diagram

ITIL Service Level Management Process Flow Diagram

"How does SLM convert business needs into valuable services?

"To understand SLM, you must understand the full depth of how SLM contributes to the ITIL service lifecycle. In the graphic above, it is easy to see that SLM contributes to four of the five lifecycles: Service Design, Transition, Operations, and Continuous Improvement. I chose this diagram because it describes the beginning when the business requires a new service to support a business strategy. The business manager cannot just contact Change Enablement because change does not even know about this service. The ITIL best practice route for a new service request is Portfolio Management, the gatekeeper for all IT services

Portfolio Management practice:

  • Confirms the new requirements
  • Determines that IT does not offer an alternative
  • Determines that the new service meets the strategic direction (e.g., ROI, TCO, architecture, etc.)
  • After analysis, creates a Change Proposal and Service Charter (high-level service requirements) for Change Enablement, and Change enters the Request for Change (RFC).

Now, SLM becomes involved with many other practices in the design phase. SLM:

  • Identifies business leaders, the service owner, and project team roles
  • Starts developing support strategies (e.g., the proper levels of availability, performance, security, and continuity)
  • Must address all these warranty targets and incident response requirements.

Remember, this is the design phase only.

Next, in the Transition Lifecycle Stage, SLM:

  • Involves all the IT service groups that contribute to the delivery and maintenance of the new service
  • Creates Operational Level Agreements (OLA) between all the functional teams that detail roles and responsibilities that fully support the SLA.

"When the new service is operational in the live environment, SLM gathers data to validate performance and user experiences. Any deviations from the planned performance are opportunities to improve. SLM uses the Continuous Improvement Practice to initiate improvement actions.

"Betty, are you still with me?"

"Yes. I had no idea that SLM had this much responsibility. It is certainly more than just creating an SLA."

"I agree with you, Betty. Now that you understand the big picture let's dive a little deeper."

Why Does Every IT Organization Need SLM?

"Service Level Management definition: 'The purpose of the SLM practice is to set clear business-based targets for delivery of service levels, and to ensure that IT properly assesses, monitors, and manages against these targets.'2

"These targets are the foundation of a Service Level Agreement (SLA).

"'An SLA is a documented agreement between a service provider and a customer that identifies both services required and the expected level of service.'3

According to ITIL, some of the key requirements for successful SLAs include:

  • Must relate to a defined 'service' in the Service Catalog.
  • They should relate to defined business outcomes and not simply operational metrics. The best practice is to use balanced bundles of metrics, such as customer satisfaction and critical business outcomes.
  • SLAs should be an agreement (e.g., through engagement and discussions between the service provider, service consumer, including all stakeholders, sponsors, users, customers, and Supplier Management)
  • SLAs use simple writing that is easy to understand and use for all parties."

The Key to an Effective SLA is OLAs Between All Groups Supporting the SLA

"Just to review. The business requires a new service. We start with Service Level Requirements (SLR) from the customer. Before accepting a new or changed service into operations, both customers and providers must agree on the SLA, detailing the service level targets to be achieved and specifying responsibilities of all parties.

"Following this, best-practice organizations map out and agree on value streams and processes. Value streams define the activities, workflows, controls, and procedures needed to achieve agreed objectives.

"'A value stream is a series of steps that an organization uses to create and deliver products and services to a service consumer.'4

One of the first value streams to map is when a user needs an incident resolved. Design the value stream options in documentation and train teams to manage and improve the streams:

  • What guidance is there for the Service Desk to address different issues and log the incident?
  • Are knowledge articles available?
  • If they cannot resolve the issue at the Service Desk, how do they escalate? (e.g., which functional team(s), how do they document, and the timelines)
  • What priorities are available, how are they determined, how do they set user expectations?
  • What is the documented workflow?
  • Service Desk detailed instructions for linking incidents to problems.
  • Problem Management directives for action.

 "Now we are ready for a critical element to ensure that SLAs are meaningful, realistic, and provide value. Now we can write OLAs between all the possible functional teams in supporting the new service.

"'An Operational Level Agreement (OLA) is an agreement between an IT service provider and another part of the same organization.'5

"OLAs support the IT service provider's delivery of IT services to customers and define the goods or services provided and the responsibilities of both parties. OLAs define the tasks, the order of the actions, communication channels, time frames, inputs, outputs, acceptance criteria, and value creation at each step.

"The OLA between every IT functional team documents how the IT organization works together to support the SLAs. Quite simply put, you will find it nearly impossible to sustain quality support for business services without OLAs.

"I wrote a blog on the relationship between SLAs and OLAs. You might want to read it before you visit with the CIO.

There are Three Types of SLA Structures

In the Service Design stage, SLM will determine the most appropriate type of SLA structure. There are three basic types.6

  1. Service-Based SLA

    This SLA covers one service for all the customers of that service. Service-based is the easiest to write if delivery capabilities are similar for all customers.

  2. Customer-Based SLA

    Customer-based SLA is an agreement with an individual customer group, covering all the services they use.

  3. Multi-Level SLA

    This SLA is a hybrid of the other two. For example, the SLA might have three sections.

    • Corporate level: The corporate level part covers all the generic SLA issues appropriate to every customer throughout the organization.
    • Customer level: The customer level part covers all SLA issues relevant to a customer group or business unit, regardless of the service used.
    • Service level: The service level part covers all SLA issues relevant to the specific service delivered to a particular customer group (one for each service covered by the SLA).

"Bottom line: Every service offered in the service catalog must have an SLA. A best practice is embedding a link to the SLA right in the service catalog record.

The Relationships of All SLM Activities in One Diagram7

ITIL Service Level Management Activities & Relationships Diagram

"Betty, I think you have a fantastic opportunity to deliver SLM to the company. In my opinion, SLM is the driving force for cohesive, laser-focused service delivery to drive value for the business. Once you explain to the CIO what SLM could be, the work and fun begin!"

Footnotes:
1. The New One Minute Manager, Ken Blanchard, Spencer Johnson, May 5, 2015
2. ITIL Foundation, ITIL 4 Edition, AXELOS GLOBAL BEST PRACTICE, 2019, p.152
3. Ibid, p. 152
4. Ibid, p. 33
5. ITIL Service Design, AXCELOS, 2011, p. 410.
6. Ibid, p. 111
7. Ibid, p. 110

Client Success

  • 50% reduction in time to deploy Giva's change, incident, problem, asset management and knowledgebase modules
  • 60% reduction in the 5 year Total Cost of Ownership (TCO)
  • Saved at least 1 FTE due to lower ongoing administration
  • Saved 1 week per month due to easy to use reports
  • Increased to 90% achievement in meeting service level agreements
  • 70% reduction in generating reports and admin; eliminated 35 hours/month
  • 50% faster to create/assign a service request
  • 60% increase in information captured during the initial phone call
  • 50% increase in the number of service requests created due to intuitive design
  • 80% increase in productivity by using Giva's dashboards and reports
  • 60% increase in meeting service level agreements
  • 45% increase in the number of the calls logged due to Giva's intuitiveness and ease of use
  • 50% increase in productivity by using Giva's integrated custom forms