Best Practices Incident Categorization? An idea, feedback appreciated?

[dinokotenoglou]

I am not sure if this is in the right area.   If the moderators need to move it, please do.

We are now past our 3rd month after moving to ServiceNow for Incident, Change, Request, etc.   I am trying to find a way to build a methodology to handle Incident Categorization so that we can make trending reports, root cause analysis, etc.

I had read this link and it gave some good insight.   https://community.servicenow.com/thread/159790?q=How%20to%20categorize%20Incidents?

I had an idea and am currently developing it.   It is not perfect, but I would appreciate and feedback or suggestions to help make it better.

BACKGROUND

• Company has ~ 50,000 employees
• We process ~60,000 Incidents a month
• Overall theme is to customize ServiceNow as minimal as possible.
• We kept the Category and Subcategory very close to what is out of box.
• We use the CMDB to capture all Applications, Services, PC and VM clients, and we even have a few "Generic" CIs to capture other assets (ISP connection for travelers, local printers, BOYD device, etc)
  • Note due to to size and complexity of our company our choices of CIs is immense
• I believe we have the Reporting Analytics module and we do have access to Tableau as well.   I do know we have looked at Numerify as possible option as well.

APPROACH

We have created and developed tables storing Category+Subcategory+CI combinations and that would tag incidents with a broader category.   Let's call this final result the "Category Profile"

  (Ex Incidents with CIs with Skype 2010, Skype 2013, Lync 2010, etc would be grouped under "Skype Lync")

We would report on the "Category Profile" in Management reports.   We would still be able to dive down to the actual Incidents for finer reporting, quality control for ticket creation, etc.

I will admit there are some downsides to this approach

1. Unless we customize ServiceNow heavily I dont see how this can be reported within the tool.   Right now we are running tests in Excel exports which will eventually be translated to Tableau workbooks
2. Starting and maintaining these tables are a chore.   It has gotten easier, but will always need to be maintained as we add new technologies and services.
3. The Category+Subcategory+CI combination is manually built and maintained by people.   Mistakes could be made and we may need to break down "Category Profiles" into smaller ones.

This is still a work in progress and we have much work to do, but it is beginning to show some promising results.   We are reaching out to other peers and partners including Big Data folk to see what they think.

May i have some constructive opinions and feedback from seasoned ServiceNow owners?   What do you think of this approach?   What are you doing in your company to Categorize Incidents?

[Ken_Michelson · Accepted solution]

Dino,

I spent many years consulting to companies on how to implement ITIL/ITSM good practices, regardless of the tool they were using. Every company is different, but generally the companies that are stuck in the category/sub-category mindset are still acting more as a helpdesk than a servicedesk. There are many reasons that this is the case, and I'm not going to try to change your processes with one community post, but more often than not, the use of Cat/Subcat is done because "we have always done it that way" and "because management requires reports broken down by these values [that often are never really acted upon anyway]"... however the desired process outcome is often not discussed, but people are focused too much on meeting their metrics, and not improving service.

You have hit the nail on the head with the "data management" issue that always follows with cat/subcat structures. I know that trying to customize ServiceNow as little as possible is a great theme to follow, but the categorization for incident vs. problem vs. change really tend to be quite different.

So generally I start with asking what you are trying to achieve with the values? Are you trying to drive Knowledgebase results? Are you trying to determine routing or assignment? Do your cat/subcat values align with how customers report issues, or with how IT tries to interpret the issues? Without answers to these and some other questions, it is hard to recommend a specific best practice.

So just to get you thinking... what would happen if you eliminated Category and Subcategory, and simply had a "Business Service" CI choice and a "specific CI" choice which only had major systems and HW owned by the caller listed? What if you kept Category only, designed it as "reported category" and had a "resolution category" to mirror it? (i.e. reported as an application issue, but it was really a network issue)

At a basic level, if you keep category/subcat I always recommend, just as I do with business service definition, that you think functionally, not technically. Having a category of "Skype Lync"... well that is just redundant if you choose Lync as your system CI... and on top of that, if you eliminate Lync and start using Google Hangouts... you are going to have to completely redo your category/subcat structure. If you had named it "Communication and Collaboration"... it doesn't matter what tool you have, the value wouldn't need to change [btw, that could be your supporting business service rather than a category]

Just food for thought.

-Ken Michelson

[dinokotenoglou]

Great response Ken.   Let me respond.

So generally I start with asking what you are trying to achieve with the values? Are you trying to drive Knowledgebase results? Are you trying to determine routing or assignment? Do your cat/subcat values align with how customers report issues, or with how IT tries to interpret the issues? Without answers to these and some other questions, it is hard to recommend a specific best practice.

We are trying to capture the summary of the call for basic tracking.   (EX - I called because I cannot get on the Internet.   Turns out the ISP has an outage, ergo, the INC should be tagged as ISP Outage, even if the customer thought otherwise.)

We would use this for tracking, trending, etc.

We use this for site specific analysis and we even use it to track user tickets after an app launch.

With the size, complexity, and changing nature of our company this is a big challenge.

So just to get you thinking... what would happen if you eliminated Category and Subcategory, and simply had a "Business Service" CI choice and a "specific CI" choice which only had major systems and HW owned by the caller listed? What if you kept Category only, designed it as "reported category" and had a "resolution category" to mirror it? (i.e. reported as an application issue, but it was really a network issue)

Interesting theory.   I can see us heading towards that direction.   Unfortunately I cannot see us going that path without some customization in SNow.

I do wonder if we used this approach for ~ 6 months and used lessons learned to a smarter solution.

At a basic level, if you keep category/subcat I always recommend, just as I do with business service definition, that you think functionally, not technically. Having a category of "Skype Lync"... well that is just redundant if you choose Lync as your system CI... and on top of that, if you eliminate Lync and start using Google Hangouts... you are going to have to completely redo your category/subcat structure. If you had named it "Communication and Collaboration"... it doesn't matter what tool you have, the value wouldn't need to change [btw, that could be your supporting business service rather than a category]

Let me give you a detailed snapshot of how this works.   A very small snippet of one of the tables is:

Inquiry Help -> Access -> Skype for Business -> Skype \ Lync

Software -> Error Message -> Lync 2010 -> Skype \ Lync

Software -> Access -> Lync 2013 -> Skype \ Lync

Even though tickets with these settings are different variations they all have to do with Skype or Lync.

If we need to dive in deeper to these Skype or Lync tickets we can since the original ticket info is left untouched

If we need to bring in a new technology or version ala Google Hanouts we can rejigger all of the Skype \ Lync entries to Communication and Collaboration.

These tables will need to reviewed on a regular basis, but it is easier to maintain than create.

A HUGE flaw with out plan is agents improperly categorize tickets.   At least we can use these Category Profiles and go back to QC and show agents how tickets should be categorized and even get feedback from them on how to do this better.

I doubt this is the final answer, but I can see us getting things a step better.

Ken,

Do you have any success stories or white papers that you refer back to?

[Ken_Michelson]

I will see if I have any blogs or white papers we use.

Regarding "without some customization in ServiceNow", what NOW provides is great, but it is a "common denominator" approach, which isn't best practice for every organization. It's generally the "configuration vs. customization" discussion as well, but adding a field and hiding a few others is more on the configuration side.

There's all sorts of features that ServiceNow has from tags to keywords to custom fields that really can eliminate the need for a huge list of categories or subcategories. If there is any doubt what values to choose, or if a call could result in multiple different results... then the value of those is reduced.

Let me use one of your examples to make another point: "Software --> Error Message --> Lync 2010 -> Skype\Lync"

When was the last time anyone cared how many calls came in on which the user reported an error message?? Never? then why have it as a subcategory? It provides no value. It could easily be put in worknotes. If it is necessary, have a KB article about the error messages that get linked. Then you can report on how many issues were reported with particular error messages. Lync 2010 could be the CI chosen... and you really don't know if it is software caused or not.

That said, if you have so many CIs that you want a category field just to make filtering the CIs easier... that's a UI configuration/usability reason to have the field, and not really a business/process reason to have the field... (I'm not totally against configuration fields )

Agents mis-categorizing... exactly. How many man hours go into developing configuring, and maintaining large category/subcat lists and what is the value it produces?

If I wasn't in back to back meetings today (I really should be listening more to the one I'm on now ) I would write more.

Here is a blog written by one of my team on the subject: The Case to Get Off Categories (and use a CMDB)

-Ken Michelson

[dinokotenoglou]

Ken,

Let me use one of your examples to make another point: "Software --> Error Message --> Lync 2010 -> Skype\Lync"

When was the last time anyone cared how many calls came in on which the user reported an error message?? Never? then why have it as a subcategory?

.

I agree, but as I said they kept the default SubCategories from SNow.   This is why these are grouped together under the "Category Profile" of "Skype \ Lync."   Then the Collaboration group can dive down into those types of tickets and find out if they are issues, questions, etc.

I do like what you have shared.

I told my peers that this kind of work is like an archaeological dig.   You go down each level and discover more and more.   You may discover you need to dig somewhere else.

I don't think approach is sustainable.   Currently I have 3,000 different combinations that output ~ 70 or so "Category Profiles."   That does sound crazy, but we do have over 500K entries in our CMDB.   This approach does give us the first steps and could lay the groundwork to something that you described about basing things around business focused issues.

I will look at the blog post you shared and I will continue to look for best practice work.   I am also trying to reach out to our SNow vendor contacts to see if they have any success stories.