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]

Jeremy,

I've also been a proponent of having a "resolution service" but as you have pointed out, it is often a supporting service that is the resolution.

-Ken

[jpkishere]

Hey Ken -

Yes we just talked about potentially (in the longer term) having a resolution service field instead of the resolution category.   Probably something we will evaluate after getting some better data from the Service offerings that we just rolled out.

The hope was to be able to do a simple pivot table on service and then resolution code and help do a 10,000 foot view of problem management to see where to start fishing.

Thanks for feedback.

[chriswest]

This thread could not be more interesting for me. We are at the very initial stages of understanding the implications of the various option as we transition from SCMS into SN.

We are very keen to move to a Business Service orientated approach, so am reading everything I can get hold of.

Very interested to see how your experiences develop.

Thank you all.

Chris

[ecracer]

I too found this thread at the perfect time.   We're rapidly approaching go-live for our initial release (small - incident & knowledge).   We are moving from Remedy and very poorly implemented Op Cats and Prod Cats with very very poor CMDB.

When implementing Remedy, I wrestled with the same basic issue... there are no hard and fast rules for CATEGORIZATION.   It is somewhat bounded technically, but really is an area of configuration that can be used flexibly, based on the requirements of your organization.   THAT is where the difficulty creeps in.

I find myself trying to get key users within the IT community to agree on what they want from incident management in terms of data about the work we deliver to keep the organization running.   The opinions vary from IT discipline to IT discipline... the infrastructure guys have one, fairly simple idea... while the SAP team would like cat/sub-cat to have provide a combination for 1000's of scenarios.   One for every conceivable issue they might have.

I'm prepared to make a call, as unpopular as it might be.   I've been coming to an approach very similar to what Ken advocates.   I've been trying to think of cat/sub-cat from the point of view of employees (callers) also... how do they think about issues they report.   This yields a relatively simple group of combinations - such as cats:   Accounts & Access, Collaboration & Communication, Application Issues, etc.   Sub cats within the Accounts & Access category might be password resets, password unlocks, etc.   Or issues reported for applications (cat), might have sub-cats as logon issues, data issues, transactions not working, etc.

Then - we use business services and ultimately CI's to provide a pretty robust set of data.   Couple that with closure codes on incidents (maybe we tweak those a bit) and you have a pretty good idea of the broad areas (types) of incidents you're dealing with, the specific business service and info about the resolution outcome.

My thinking is start more simply, make it easy (and quick) for the service desk agent to categorize and look at the data we have after 4-6 months.   Then we adjust from there.   I'm also looking ahead to tweaking the descriptions on Categories when we implement self-service and allow the employee (caller) to select the category at least.   (EXAMPLE:   "internal" category = Customer Hardware while the "What are you having problems with drop down = "My computer".   My computer maps to Customer hardware category and we go from there with the SD agent ultimately selecting the sub-cat)

To wrap:   Excellent discussion and info here... perfect timing.   Planning to read through and hit the links contained here again a second time to get it all to sink in.

Thanks to all.

[jpkishere]

To provide updates since the last time I posted here.   I couldn't be happier with the changes that we did.   Below are a few key items that are helping us move forward as an IT organization based on walking away from Categorization and moving to Service Offerings:

1. We now have very specific data for what services are generating the workload which is helpful to trend volume and evaluate staffing levels
2. We now have very specific escalation paths for all of our service offerings, making resolution on priority issues happen quicker and making it very clear on how to escalate vs. tribal knowledge from before.
3. We now have very specific change approvers for each of the Service Offerings (we do Service offering approvers + CAB (which is just BRMs) for approvals), this allows us to not push all changes through the CAB and have a more efficient/agile process.
4. We now have an owner for each Service Offerings, when we look at items from an Enterprise Architecture perspective this is helpful.   I created Service offerings dashboards which filter relevant data to all the Service Offering Owners (i.e. SLA met %'s, Change %s, Request and Incident volume, KB usage, etc.)
5. We assign all of our assignment groups a Level 1, Level 2 or Level 3 value.   Doing this and combining the Service Offering data I can focus where I need to on the Shift Left that is desperately needed here.
6. We do use Resolution Codes based on 7 different options; we have a simple pivot table report we run that shows top 20 service offerings pivoted on resolution code so we can make high-level decisions for problem management (e.g. Resolution code of User Training/Education in high numbers means we need to improve User Experience/Training).
7. Allows us to focus our limited resources on the proper things (i.e. on problem management and KB creation with the top incident generators) since all of the above let's us make data driven decisions.

As far as changing the organization's mindset, for #5 we were able to put an estimated amount of dollars we spend on support for each level which (i believe) has been eye opening for leaders in other groups.   This also (in our organization) shows that we have too many Level 3 people working incidents and need to improve our Level 2 team.   Re-allocating resources based on the data I gather above is a simple discussion since I have the data.  

I make decisions at a 1,000 foot level with the above data (GIGO) and often times we find the data can be misleading when i got down a level or two within the organization.   The model still works, it is just in a state of on going continuous improvement and it drives the right conversations.

Hope this helps!