Service Manager 2012 and Service Level Management – Part 1

  • Article

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:

  1. Service Level Management and the concepts (this post)
  2. Defining Priority matrix and Queues for SLA
  3. How Service Manager enables Service Level Agreements in Service Manage

 

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:

  • Managing business relationships (no tool can do this, but reporting is key for managing client expectations)
  • Tracking changing business needs (no tool can do this, this is truly people)
  • Creating the service catalog (Service Manager has a Service Catalog)
  • Defining, measuring, and maintaining OLAs (Currently not supported in Service Manager)
  • Defining, measuring, and maintaining UCs (Currently not supported in Service Manager)
  • Defining, measuring, and maintaining SLAs (Currently in Service Manager)

 

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.

 

image

 

High Level Steps for Service Level Management

1. Define what is a service:  Define this in your Service Catalog

  • Example: Collaboration, is that one service or is it 4 services? (Email, Calendar, Lync, SharePoint)
  • Split service into “utility” and “warranty.”
    • Utility:   Functionality that needs to be delivered.
    • Warranty:  How is the functionality going to be delivered (Continuity, Availability, Capacity, Security)

2. Define a SLA Template and structure (Service Catalog)

  • It’s important to define a standard for this, so the same information is available across SLA;s and these are negotiated on the same terms and language.

3. Define Service Level Requirements containing business requirements in business terms

  • It’s important to define the SLA in business terms that the business understands and it should not have too many technical expressions and content.

4. Negotiate SLA requirements targets measurable for the agreement between business and IT (UPC and OLA should also be defined with IT backend)

  • When negotiating the SLA requirements, it’s important to set realistic goals and also make sure that all KPI’s are measurable.
  • It’s important to understand if the requirements can be met and that they are aligned with UC and OLA.
  • Try to see if there is any historic data that can be used to get a realistic idea of what’s feasible (setting a base line).  For example, is a priority 1 incident for a service being solved within an hour or a day for a given service?

5. Define SLA  content measurable terms

  • Make sure it can be measured. SLA is not worth anything if it can’t be measured. Perception is not evidence of anything. J
  • Service Manager and other System Center components can collect the data for SLA KPI’s.

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).

  • It’s important to identify the stakeholders of the service and also understand what level of information these stakeholders require.
  • Define frequency for the stakeholders, i.e. when do they need the reports?

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:

    • CSI Registrar: Capture things that can be improved
    • CSI improvement plan: Ensure that the registrar get implemented
    • Owner: Define a person that is accountable for delivering the service and drive CSI

8. Define review meetings with Agenda, stakeholders, and frequency

  • To align and drive CIS, an ongoing meeting should be put in place with an agenda.  In most cases this is driven by the Service Owner at a defined schedule.

 

Do:

  • Make sure you have a IT Service owner – someone accountable for report definition and improvement of SLA for the IT-service.
    Start with the most simple services to get experience, and work with the more valuable/critical later when you have more experience and less room for mistakes.   To begin, make a plan for how and when.

 

  • Try to automate data gathering and reporting for review meetings.
    Make a simple SLA structure.  Start simple and go more advanced as you get better.
  • Make sure that there is support and governance approval from the organization.
    • This includes understanding what support is needed from the organization in order to implement the SLA. 
    • E.g., Hard terms / soft terms: Education, hardware procurement if any).

Don’t do:

  • Don’t put too much text in the SLA, nobody reads it anyway Smile.
  • Avoid circulating to too many stakeholders.
  • Don’t make the language too complicated or academic.

 

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.

 

Stay tuned