I’m very excited to present the first of many blog posts for the new version of Service Manager 2012! The Beta is now public and I am now allowed to blog about all the great features that we all were waiting for! Let’s go …
With Service Manager 2012 it is possible to measure the efficiency of your Service Desk. Many companies want to know if Incidents or Service Requests are processed within the defined time frames (Service Levels). The new Service Level Management feature allows us to do that in very detail.
****************************************************
The complete SCSM SM12 (Beta) Series:
#1 – Service Level Objectives (SLO)
#2 – Service Requests
#3 – Automation of Service Requests
#4 – Enable Self-Service for Service Requests
#5 – Parent/Child Incidents
#6 – Release Management
#7 – Connectors
#8 – Permissions for triggering System Center Orchestrator runbooks
****************************************************
In the Administration area you have several objects to configure the Service Management feature. Let’s take a look at those.
Calendar
With the calendar it’s possible to define a set of hours that you are working with specific tickets. For more important tickets you could use a 7×24 calendar, for less important tickets you could use a calendar that defines the regular business hours. In this example I create a single calendar that reflects the business hours of our company.
Metrics
Metrics define what exactly to measure. When talking about Incidents, it could be interesting to measure the Incident resolution time or the Incident reaction time. You can create as much metrics as you need and use them later in the Service Level Objectives configuration.
Service Level Objectives (SLO)
Now it’s time to bring everything together. In this example, I want to define a Service Level Objective for all Priority 1-Incidents: they should be resolved within 4 hours and if this is not the case, the Service Level should breach. Let’s take a look at the configuration.
First, define what class objects you are interested. In my case, I’m interessted in Incidents.
Now we have to define what Incidents the new SLO should apply to. In this example I want to apply the SLO to all Priorty 1-Incidents. Therefore I have to create a queue that holds all those Incidents and select the queue here. All other Incidents will not have a SLO assigned. So in a real world scenario you would have a bunch of SLOs for Incidents with specific Priorities, for VIP Users or for Incidents that relate to specific Business Services.
Last, I must choose what calendar and what metric to apply to the Priority 1-Incidents, and I have to define the target time for the resolution as well as a warning threshold.
That’s it. Now it’s time to check the configuration. I created an incident and did not resolve it within the time defined in the SLO. If I open the incident now, a message is displayed immediately telling me that at least one SLO has breached.
When switching to the Service Level-Tab, you can see the details and the status about the different SLOs that apply to the Incident. Based on the configuration it’s possible that multiple SLOs apply to a single Incident.
To get a better overview, you will find two views to display all Incidents in warning or breached state in a single list.
With this new feature it’s possible to configure your Service Level Objectives in very detail and let Service Manager measure things for you. This is great and a huge step forward from what we had in SM10.
Stay tuned for upcoming SM12 blog posts!
Marcel
