This blog post will cover how you can set up incident resolution service level agreements (SLAs) in Service Manager 2010. There are some things that we still need to add support for in this area, but we’ll at least explain what you can do with SCSM today in this blog post. I’ll also point the areas that are gaps we need to fill and later we’ll announce when and how we are going to fill those gaps.
To begin with, let’s talk about what you can do in SCSM 2010. Service Manager out of the box has support for SLAs based on the target resolution time. Another common SLA metric is target response (“acknowledgement”) time. We don’t have support for that out of the box right now.
Target resolution time is determined by the incident priority. If you go to Administration\Settings\Incident Settings you will find this dialog:
For each priority level (1-9) you can define a different Target Resolution Time. The Target Resolution Time is defined as the Time Created + Target Resolution Time for the incident’s current priority. For example, if I created an incident with priority = 3 at 8:00 in the morning, I would have until 12:00 noon to resolve that incident. If the incident status changes to Resolved prior to 12:00 then I have met the SLA.
The Target Resolution Time is always displayed at the top of the incident form as the “Resolve By:” field.
This incident is Priority = 4 and per the matrix above has a target resolution time of Time Created (9/21/2010 12:59 PM) + 4 hours = 9/21/2010 4:59 PM.
The priority value is not directly settable in the UI because it is a function of the Impact and Urgency values. In the example above when Impact = Low and Urgency = Medium that is configured to have a priority of 4.
You can also add additional Impact and Urgency items in the Library\Lists view and then you can work with a larger matrix:
Note: changing either these settings or the target resolution time settings above will not take affect until after you close and restart the console and they will not retroactively be applied to incidents. If the incident urgency or impact value changes when the workflow runs to evaluate it’s target resolution time again it will use the updated settings.
Assuming we go with the default configuration of Urgency: High, Medium, Low and Impact: High, Medium, Low at this point we have established the following pattern:
That alone might be good enough for some customers, but a lot of people want to map different SLAs for different customers, different classifications of incidents, different services, different affected configuration items, etc. First lets work this out on “paper” like this for a situation where we want to have different SLAs depending on how important a user is in an organization (from an IT guy’s perspective :) ).
You can do the same kind of thing for other types of schemes including mixing and matching criteria using OR/AND statements:
It’s really up to you how you want to classify these things, but in the end (at least for SCSM 2010) you have to map these all down to a certain pair of Urgency and Impact values which in turn drives Priority which in turn drives the Target Resolution Time.
Now the question is “How do you implement this map that you have created on paper?” There are a few different ways:
A couple of important notes:
Now, let’s point out some of the limitations currently in SCSM 2010:
We are working on addressing these issues as soon as possible, but in the meantime you can start to map your SLAs to SCSM using the approach described above for target resolution times.
Another thing you can look into is a solution provided by our partner Cased Dimensions that provides Service Level Management. Check out the Cased Dimensions demo video.
Hope that helps clear things up!
Please leave any helpful comments or suggestions in the comments below so we can factor those in for future improvements.
"There is a workflow in SCSM out of the box that changes the Priority and Target Resolution Time property value each time there is a change in either Urgency or Impact. So – even if the incident is updated via a template being applied in a workflow the Priority and Target Resolution Time will be updated within a few seconds to match the new Urgency and Impact values."
I am creating incidents via the SDK and I see the Priority get set by a system workflow, but I don't ever see the Target Resolution set until someone opens an incident and saves it.
Are you certain of this? I just did some testing and it works fine for me. I even checked in the MP to make sure that there is a workflow in there that is triggered on create. It has the same configuration as the update workflow.
what is the Target Resolution Time variable? I cannot find it in the incident class... and i want to insert the resolution time in a notification template. It is possible to retrieve this variable in the incident class?
ok :) i've found it
$Context/Property[Type='CoreIncident!System.WorkItem.Incident']/TargetResolutionTime$ aka "Resolved by"
In this post you show that you have changed the impacy to show 5 categories. Adding is easy but how have you edited the names of the default categories, low medium and high, I can't do this in mu console the defaults are greyed out.
Is it possible to allow the users to be able to choose the Impact when creating a ticket via the web portal? I realize that they can determine the urgency of a given ticket, but having the provide the Impact would be extremely helpful in our situation.
Sorry - It's not possible to allow users to choose the impact level at this time.
Travis, any updates to this?
Mostly hoping for the customized solution for operating hours. We only operate 8 hours a day...
Also, is there any way to implement a "on hold" functionality. For example, using the Exchange connector and the request information from affected user scenario, I would like the target resolution clock to stop ticking until the affected user replies to the email.
Another scenario might be such basic things as laptop users leaving mid day taking their laptops with them, I'd like the Analyst to be able to manually put the incident on hold in those kind of scenarios.
Keep up the good work!
Trana010 - Some of those features, especially business hours, will probably be coming in SCSM 2012 due out around the end of this year. Given that we are so close to that release and that there are a number of other areas that I could invest my time in developing that wont be covered by SCSM 2012 and that there is already a partner solution from cased dimensions for this, I don't think I'll be building a workaround for business hours.
Thanks Travis, makes perfect sense, cant wait for 2012! :)
my customar want to change incidet status when they are check the set first response check box. Is it possible? and what is "set first response" attribute class?
@Firat Yasar -
What you need to do is subscribe to the first response date changing from Null to Is Not Null and then apply a template which changes the status value. Unfortunately, the console doesn't allow you to do that. You could do it in MP XML.
The checkbox that you see on the 'Set First Response or Comment' dialog is not bound to a property itself. If the checkbox is checked and the incident is saved then the first response date property is set to Now.
Just want to check I'm not missing something here! :)
I am using SCSM 2010 and we require some way of measuring first response times. I can see how using created date compared to assigned to can work, but was wondering about this "set first reponse checkbox" is that only in scsm 2012?
Also when I click link to blog post near bottom of article:-
"•There isn’t a Response Time SLA capability out of the box although it is possible to add support for that as described in this blog post." I get redirected to the same page, is this correct?
Yes, first response date (including the checkbox to set it) is a feature of SCSM 2012+.