This blog post describes how to build a custom SLA management solution in SCSM. If you are looking for more of a plug and play solution check out a solution provided by our partner Cased Dimensions that provides Service Level Management. Check out the Cased Dimensions demo video .
A question that has been discussed eagerly on forums regarding Service Manager 2010 is how to be able to take action upon incidents breaching their Service Level Agreement (SLA). In this post Patrik Sundqvist and I will show you one way to do it. There are three goals of this blog post:
When an incident is registered within Service Manager, it will get a priority based on a priority calculation drive by the urgency and impact of the incident. The priority and target resolution time are also recalculated each time the impact and/or urgency changes. The calculation is based on a matrix which can be configured directly in the console at "Administration" – "Settings" – "Incident Settings".
In the same place where you configure the priority matrix you're able to define target resolution times per priority level.
As mentioned above, when an incident is registered in Service Manager it receives a priority based on the matrix. At the same time as it receives the priority it also get's a "Target Resolution Time", which is based on the priority and the resolution time configuration.
Notice here how the Priority is set to 1 because the Impact and Urgency are both High. The priority is determined by the Urgency/Impact matrix shown above.
Here, notice how the Resolve By (also called 'Target Resolution Time') is set to the time the incident was created plus 30 minutes per the configuration shown above.
Out of the box you can manage incidents which are still active past their target resolution times by using the 'Overdue Incidents' view.
This is a pretty passive approach though and requires someone to be continually hitting refresh on the view instead of managing things by exception. You can also run an Incident KPI Trend report to see the number of incidents that didn't meet their SLA:
Wow! The Contoso service desk team is really doing a bad job of meeting their SLAs! :)
You can also run the Incident Resolution report
Either of these reports you can slice by queue, source, time range, etc. Our upcoming dashboard release for Service Manager will also have some interesting views on this data.
But again, these are also pretty passive approaches to managing incidents.
What we hear from customers a lot is that they want to take a more proactive approach to managing incident SLAs. After all some people's jobs depend on having good incident SLA numbers!
Here are a couple of things that people want to do which we don't provide for out of the box but with a little customization can be configured:
To detect and act upon incidents about to or breaching their SLA (their Target Resolution Time) you can use the built in workflow engine of Service Manager 2010. Here is how you can use this solution we provide in this blog post.
The Microsoft.ServiceManager.WorkfowAuthoring.* dlls come from the Service Manager Authoring Tool Beta 2. Be careful replacing what you have already there or replacing these in the future with new ones. Always create backups of these before you replace them!
2. Import the management pack Microsoft.Demo.IncidentSLAManagement.xml into Service Manager. Note – you can optionally configure how frequently the workflow that checks service levels runs. By default is every 15 minutes. Make sure you decide how often you want it to run before you import and don't run it too frequently! Just search for 'Minutes' in the XML and you'll see where it is set to 15. Just change it to some other number if you want before you import.
3. Go to the Administratoin/Settings view in the console. Double click on Incident SLA Management Settings and configure the warning threshold. This is the threshold at which you will change the incidents' SLA status to Warning. By default it is zero meaning there is no warning interval.
Note: this solution will start running immediately after import. If you don't want it to run immediately on import you can change the Rule Enabled attribute to "false" in the XML prior to importing and then enable it in the Administration/Workflows/Configuration view.
Now, what you will see is that any incidents which are still active past their target resolution time will be marked as Incident SLA Status = "Breached" and any incidents which are within X minutes (as defined by the Warning Threshold) of Target Resolution Time will be marked as SLA Status = "Warning". You can see this on the incident form in the Extensions tab.
To make it easy to see the incidents that are in a Warning or Breached state we have provided a couple of new views in the management pack:
Now you can use this property as part of notification subscriptions or incident event workflows to escalate or do other classification/routing things.
9. Click Next.
10. On the criteria page set it up so that "when the SLA Status change to Breached" the workflow will be triggered like this:
11. Click Next.
12. On the template screen, select the incident template you created in step #1. Click Next.
13. Optionally choose to notify people related to the incident. Click Next. Note: We have provided a couple of "out of the box" notification templates – one for 'Incident SLA Status – Warning' and one for 'Incident SLA Status – Breached'.
14. Click Create.
15. Click Close.
You can also set up notifications to other people like team leads, managers, etc. by following the same subscription logic by creating new notification subscriptions in the Administration/Notifications/Subscriptions view.
Now that you know how to use the solution now, let's take a look at how we built it.
Note: This part is intended more for developers!
The solution is comprised of the following parts:
Let's take these one at a time. Most of these concepts have already been described previously so I'll just link to them here:
Extending classes is described here .
Creating enumerations is described here .
Creating a new administration setting with form and custom task is described here .
Creating notification templates is described here .
Creating views is described here .
Creating custom Windows Workflow Foundation activities hasn't been described before so we'll do that in this blog post…
First start by creating a new Solution using the Workflow Activity Library project template
Next change your class name to something meaningful by selecting the activity in the designer and changing the name in the Properties panel:
And rename the files:
Next add some references and using statements in the .cs file (not the designer.cs file):
C:\Program Files\Microsoft System Center\Service Manager 2010\SDK Binaries\Microsoft.EnterpriseManagement.Core.dll (on management server)
C:\Program Files (x86)\Microsoft System Center\Service Manager 2010 Authoring\PackagesToLoad\Microsoft.ServiceManager.WorkflowAuthoring.ActivityLibrary.dll (on computer where Authoring Tool is installed)
Now you need to make your custom Windows Workflow Foundation activity derive from a special base class we provide. This will allow your Windows Workflow Foundation activity to use the special property binding dialog in the Service Manager Authoring Tool that allows you to bind to trigger class properties.
Change your class declaration like this:
Now you can declare some input/output parameters. Here is an example:
public static DependencyProperty WarningThresholdProperty = DependencyProperty.Register("WarningThreshold", typeof(TimeSpan), typeof(GetSLABreachingIncidents));
[DescriptionAttribute("Number of minutes prior to breach when incidents should be marked as Warning. If not speicified (00:00:00), value from database will be used.")]
public TimeSpan WarningThreshold
Then implement an Execute() method:
protected override ActivityExecutionStatus Execute(ActivityExecutionContext executionContext)
This is where the code goes that you want to execute. For example, one of the first things you'll want to do is create a connection to the management server:
EnterpriseManagementGroup emg = new EnterpriseManagementGroup("localhost");
In this particular solution we are basically making three queries each time this activity runs.
Then for those incidents which match the first query it marks them as SLA Status = breached, those meeting the second query as SLA Status = Warning, and those meeting the last query as SLA Status = <blank>.
Reminder on how to debug workflows: http://blogs.technet.com/servicemanager/archive/2010/01/19/debugging-custom-forms-console-task-... Use the Thread.Sleep trick!
Now you can build your workflow activity.
To use this new custom workflow activity:
This solution is available for testing now in an alpha version. A new CodePlex project has been started for any developers that would like to contribute.
You can get the installable download, source code, or start contributing by going to the project site on CodePlex here:
Lastly, I want to give a HUGE " Thank you!! " to Patrik for his contribution to this project!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.