Saturday, October 17, 2015

Deploying "Quick Resolves" for your Team

12:33 PM Posted by A , No comments
"Our new SCSM Deployment is just too much for simple things."

I spend more time typing all this stuff into an Incident, applying it, closing it because of that stupid background workflow issue, re-opening it, then resolving it than I do actually fixing an issue! Make this less awful!


I just deployed Service Manager. It's hard enough convincing team members this is the ultimate solution, but I can't defend how obtuse the entire Incident resolution process seems for things that take less than a minute to fix.

If there is a trend I've seen across SCSM deployment is that generally people implement the Exchange Connector and configure it to convert emails to Incidents because they are easier to work with as opposed to a Service Request...with all those activities. What's more, if you and your team are just getting started in SCSM, Incidents feel easier. You have Classifications, you have Support Groups, you have a lot of things that look and feel like a classic "ticketing" system. But more than likely you're familiar with one or both of the above scenarios.

What can we do? We can Orchestrate ourselves a way out of this and develop Incidents that resolve themselves in a single click without any programming or reverse engineering of SCSM.

PLEASE NOTE: The following (and really this entire post) is merely a suggestion to curb an issue I hear newcomers levy against Service Manager. What's more, we're solving this with the Incident from Exchange Connector scenario. Ideally, you'd implement a Service Request version of this so as to accurately track break/fix (Incident) against what's needed (Service Request). That said, I'm aware what I'm outlining probably isn't the most ITIL friendly thing.

Let's Create a New Management Pack in SCSM
1. Head into Administration
2. Management Packs
3. Create a new Management Pack, for the purposes of this demonstration let's call the management pack "Quick Resolve"

4. Next, let's move over to Library
5. Templates

Before we move on, let's revisit the original two scenarios. What's something that happens on your help desk enough, that takes seconds to solve, you want analysts to enter into SCSM, and later report on? Password resets? Come on, there has to be something! Whatever that is...

6. Create a new Incident template titled the name of the issue you just came up with and save it in your management pack "Quick Resolves". Here's an example of the bare minimum fields you probably want to fill out in this new style of Incident template.

The significance of building an Incident template is sparing your analysts/team members from filling out the same information, every time, for the same type of issue. What's more, by building a template you've just built a consistent "shape of data." That is to say, come reporting time from your data warehouse you can always find these Incidents based on their Title, Classification, Impact, Urgency, Resolution Time, etc.

Hey, wait. You said the Incident would auto-resolve. We didn't do that! LIAR! I GOT YOU!

Time to Move to Orchestrator
Good news, we have a really, really, REALLY easy runbook to build to auto-resolve our Incidents.

1. Initialize Data

2. Get Relationship (Runbook to Incident)

3. Get Incident
SC Object Guid equals Related Object Guid from Get Relationship (Runbook to Incident)

4. Get Relationship (Incident to Assigned To)
Object Guid equals SC Object Guid from Get Incident

4a. Link between Step 4 and Step 5
Exclude, Relationship Class does not equal Assigned To User

5. Get Assigned To
SC Object Guid equals Related Object Guid from Get Relationship (Incident to Assigned To)

6. Create Relationship (Set Resolved By from Assigned To)
Since we want to give analysts credit for working Incident when it comes to reporting, we need to make sure we mark them as the Resolver of the Incident.

In the above, we're defining...
Source Class = Incident
Target Class = Active Directory User
Relationship Type = Resolved By User
Source Object Guid = SC Object Guid from our original "Get Incident" activity
Target Object Guid = SC Object Guid from our recent "Get Assigned To User" activity

7. Format Incident Created Date (add 5 minutes)

I added five minutes because my assumption here is that the Incident your analyst is working on is taking less than 5 minutes to resolve. Maybe you want to make this window even tighter? Your call. The point is, we're getting the created date of the Incident and making up a Resolution Time to be set. Again, we're defining a consistent "shape" to our data.

8. Resolve Incident

Here you'll notice I set three fields
  • Status = Resolved (duh)
  • Resolution Category = Walked Through Knowledge Article (because if you think about it, if your analysts are resolving stuff this fast shouldn't there be a knowledge article you are walking people through? Something you are educating someone on? Aren't by definition these style of Incidents a user training issue?
  • Resolved Date = The Created Date/Time + 5 minutes. Specifically "Format Result" from the previous format date time step

Check your runbook in
Sync your Orchestrator connector in SCSM

Back to Service Manager!
With your runbook synced into SCSM, let's build a Runbook Automation Activity Template from it!

  • Library -> Runbooks -> Find your Quick Resolve runbook we just built.

Upon selecting it, in the top right hand corner choose "Create Runbook Automation Activity Template"

What management pack are we going to save it in? How about the one we created when we started this whole thing?! Perfect!

Once you're in your new template, give it a name, description, classify as necessary. But more importantly make sure you have "Is Ready for Automation" checked off.

Next, head into the Runbook tab -

The first step in our runbook we created a parameter called "ActivityGUID". Here you can see that very same parameter, but we need to map it to Object -> Id to ensure the data is passed correctly into Orchestrator when the Incident is saved.
Hit OK and save yourself out of this window.
Go back to your Incident template that you originally created for this "Quick Resolve" style Incident.
Head into the Activities section of the Incident, hit add, and add your recently created Runbook Automation Activity.
Save yourself out of the Incident window.
So now, you've built a really awesome, quick way to work Incidents in your system. Now it's possible to analysts to choose "Create Incident from Template" and pick the IR Template we just created (runbook and all) OR they can Apply Template to a pre-existing Incident (aka something an employee submits that you have a "quick resolve" for so as to continue to set a consistent shape to your reporting data).
The runbook will only engage once the Incident has been saved/committed into the system. Which means the only thing the analyst is filling out two fields, Affected User and Assigned To! Now analysts have but a single button to push to create Incidents and get credit for them in downstream reporting! No more weird background workflow issues preventing analysts from creating, saving, and resolving. They can resolve in one click, the OK button!
It goes without saying, you can copy and build multiple types of this Incident style. Perhaps you want to do one for everything thing that isn't a Service Request yet (which is to say, everything you don't have a process for yet within your organization.)
Wait, one last question. Why did you use Assigned To? Why not Created By User? Wouldn't that be more reliable? Wouldn't that mean analysts don't even have to fill themselves in as Assigned To?

Don't forget the scenario we designed for... employees email Incidents into your help desk. So before you go flipping this runbook trying to make it easier, remember that if an employee emails an Incident in they are the Created By User. So unfortunately, that is probably a less than ideal reporting issue to get around.