...building hybrid clouds that can support any device from anywhere
One of the new features in Service Manager 2012 is Service Level Management. In this series of posts, I want to explain the logic behind Service Level Management and walk through how it can be configured in Service Manager 2012.
As with previous blog posts, I will start with explaining the concepts in the first blog post, and in the following blogs I will show how it’s actually works in the tool.
The Three-Part Series:
Background on Service Level Management
MOF definition: IT must manage the ongoing delivery and enhancement of its services—this is the goal of Service Level Management. Service Level Management ensures that ongoing requirements, communications, and expectations between business and IT are proactively managed. Service Level Management is also responsible for ensuring that internal IT expectations are being met.
The activities involved in Service Level Management include:
SLM Terminology from MOF:
Service Level Agreements (SLAs):
Communicate and document the agreed-upon expectations of business-facing IT services. These are formalized documents that are shared with the Customer and they are agreed upon between business and IT representatives.
Service Level Objective (SLO):
SLO’s are agreed as a means of measuring the performance of the Service Provider. SLO’s are specific measurable characteristics of the SLA such as availability, throughput, frequency, response time, or quality. This concept is part of SLM in SCSM 2012.
Operating Level Agreements (OLAs):
OLA’s are a formal way of communicating and documenting the agreed-upon expectations of dependent IT services. This is an agreement, not a contract. It is, however, useful in determining the rules of engagement and understanding the roles and responsibilities of dependent IT Services. For example, Exchange needs Active Directory (AD) so that the Exchange Support team will define a OLA with the AD team to clearly articulate who and what time to resolve AD issues that impact Exchange and their SLA.
Underpinning Contract (UC):
These are more legal in nature, the intent is to communicate what is being paid. They set the expectations between the suppliers, third parties, and the organization.
High Level Steps for Service Level Management
1. Define what is a service: Define this in your Service Catalog
2. Define a SLA Template and structure (Service Catalog)
3. Define Service Level Requirements containing business requirements in business terms
4. Negotiate SLA requirements targets measurable for the agreement between business and IT (UPC and OLA should also be defined with IT backend)
5. Define SLA content measurable terms
6. Define Reports (KPI’s) with stakeholders
Very important: Every IT-Service must have an owner that is accountable for the delivering the IT-service to the business. This person does not have to be the same person as the Service Level Manger (in most cases they are not dependent on the size of the organization).
7. Setup CSI (Continues Service Improvement) registrar / Service improvement plan.
In order to drive continuous service improvement, it’s important to drive initiatives which ensure that the service is improved over time. Three things should be defined:
In order to drive continuous service improvement, it’s important to drive initiatives which ensure that the service is improved over time.
Three things should be defined:
8. Define review meetings with Agenda, stakeholders, and frequency
This was a short introduction of what to think about before implementing SLA in Service Manager. Hopefully this indicates that an SLA is very much about the process, the people, and their organization – more so than the tool itself.
I would like to thank the Service Manager community for feedback and input on this topic.
The next blog post will focus on how Service Manager enables Service Level Agreements in the areas of Service Catalog and defining Service Levels for Service Requests and Incidents.
<p>Good SLM document. Very Handy Indeed!</p>