Best Practices Incident Categorization? An idea, feedback appreciated?

dinokotenoglou · ‎06-09-2016

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

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
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.
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 · ‎06-09-2016

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

dinokotenoglou · ‎06-09-2016

One more Reply. I did some searching and found this article.

How to Classify Incidents

I think it helped clarify what you talked about. Instead of focusing on the technical aspects of these Incidents focus on the service behind them.

You did give me some more information to ponder on.

I will still drive forward on my current approach because it does get us one level deeper and it might lay ground work for a better model.

juliezhang · ‎06-13-2017

Hi Dino,

This is a very interesting topic for incident categorization and root cause categorization. We are now exploring ServiceNow and thinking to move to ServiceNow.

Several demos have been conducted by ServiceNow to us about incident management. However, for Incident categorization and root cause/resolution categorization, I believe it is something beyond the platform.

We are struggling with the categorization too at this moment. As this topic has been published quite for newly one year and I wonder how's the progress of your categorization.

Do you have anything to share? My starting point is to try the incident categorization from the service perspective and the root cause/resolution from Service component perspective, kind of "what is wrong, and what to improve?". And I am thinking the incident root cause shall differ from the problem management root cause, for example, you may have "unknown by restarting server" in incident management as a resolution code but this is not acceptable for problem management and such resolution code in incident management would usually trigger a problem topic.

To me, the incident categorization is for several purposes, for the very basic one is still for the service desk to quickly identify which team to resolve the issue, but the more important value is to have a good understanding for management to understand how's the performance of the IT service we provided to business and the trend of service so as to find any improvement area(CSI).

I can see that Jeremy or others also mentioned that the difficult part is really to align the understanding of the incident categorization and resolution code among the different IT team/personnel. This is somehow a challenge also to me to convince them a good set of incident categorization and root cause.

This is the very first time for me to come here or join such community. I'm not sure if it is proper if you can provide your email to me so that we can discuss more?

I'm also okay to for your further information here.

Thanks again!

jpkishere · ‎06-21-2016

We just basically just (2 weeks ago) did what Ken is talking about and got rid of Category and Sub-Category and were replaced with Service Offerings (i.e. Business Services).

It is still to early to tell if it was the proper move but hopefully after a full quarter we will have some numbers that make more sense. In the past the categories like Other got most of the attention (like 70%) since we didn't have all of our services captured. The biggest challenge in implementing it was for the team to focus on which Service to choose that is having the problem, versus the service that fixed it.

We are now working on refining resolution codes to drive value out of those since what we have isn't really providing much value today.

The biggest challenge we had with it was conceptual. Getting the Service Desk (and others) to choose the Service that was truly impacted versus what the fix was. For example for some tickets they would assign the Service offering as Patch Management, since applying patches resolved the issue. Instead it should have been Outlook which was truly the service impacted. We have a decent amount of services to 1000+ so we had to do a good job on the naming conventions and the descriptions so the Service Desk could search fairly easily. We found that in week one there was lots of incorrectly assigned ones and that in week two after "reinforcing" the concept folks have adapted pretty well.

Building the Service Offerings has other benefits as well since we have now required Service Offering's on Change and Knowledge so they can be tied back to a service versus a CI. When we roll out Project management then we can ensure all of our Projects are tied to a Service Offering.

dinokotenoglou · ‎06-21-2016

Thanks for the input Jeremy.

I have been pondering Ken's original post and it is growing on me more and more. I even had an opportunity to talk with some peers from outside our company and they chimed in with the same info that supports Ken's conclusion.

Jeremy keep us posted on how things go. I would be very interested.

For us, I think the best move is to go the painful path. Start with categorizing based on incident or technical versus business service. Then after a few months talk about what works well and what does not work well and what did we learn. Then we can talk about next steps and move to a business centric model.

It will take us some time, but we have only been on ServiceNow for a few months and we plan to be on it for a LONG time. I am not in any rush.

jpkishere · ‎06-21-2016

Dino -

Like most things we start here with a crawl, walk and run approach. So i would argue we are in the walk stage and you are in the crawl stage so makes perfect sense!

Good Luck with your implementation.

Jeremy