Best Practices Incident Categorization? An idea, feedback appreciated?

dinokotenoglou
Kilo Contributor

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?

1 ACCEPTED SOLUTION

Ken_Michelson
Kilo Guru

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


View solution in original post

17 REPLIES 17

varunp
Tera Guru

How is your solution working?

 

I am looking for the same kind of solution. 

 

how you achieve this?

KeithM2
Kilo Contributor

I found another helpful article.  Granted it is 9 years old but it had some good points

https://community.servicenow.com/community?id=community_question&sys_id=3d9c03e5db9cdbc01dcaf3231f96...

 

Hope it helps!

Taras1
Tera Contributor

the link does not work