Incident Management Three Tier Categorization

[Barbara21]

Incident Management has a two tier categorization. However, the organization I work for wants to add a third category. Has anyone implemented a third category in Incident Management? Adding a third tier can be a little messy and the list will grow longer throughout the years, probably in weeks.   I dislike the idea, but I would like to hear the opinions and recommendation of others.

Thank you,

Barbara Tejeda

[Uncle Rob]

I worked at a company that went through 3 different ITSM tools in 5 years.   Each time the central focus of pain was attempting to manage all work by putting it in a 2 - 4 tier taxonomy.   That fecal loop finally ended when they purchased ServiceNow and started really investing in Catalog definition, usage of different task types, and development of custom apps.   Suddenly the need to categorize all things in one place was radically decreased.

More recently, I worked at a company with a 7 tier category tree.   Once again, it was the main driver on a train that was so far off the tracks.   Cost to re-architect everything was right around $0.5M

Categorization is a dead idea.   You couldn't waste money faster if you converted it to beer and drank it until you were continuously urinating into the middle of your bank account.   Over the last 2 decades of IT, it has continuously been viewed as the most important place to focus implementation efforts with the consistently lowest return on investment.   There's no surer way to avoid the best practices of CMDB and Service Catalogs than a multi-tier taxonomy.

My advice?   If you can't convince the company to carefully consider their task types, invest in Catalog & CMDB, maximize opportunities for Search then there's little hope.   The trick is to deflect the pain onto the parties asking.   When you build the category tree, offload the maintenance of it to another group.   With three tiers, I give you a year before the number of changes requires a full time ServiceNow admin.   Get that maintenance onto someone else's P&L.

Best of luck.

[Uncle Rob]

Also, more positively, I'd love the opportunity to demo your stakeholders what some careful planning, CMDB, Catalog, and utilization of Contextual Search can do.

[TrevorK]

We started off with a category tree - and we faced the same questions you are most likely faced with every time "well what if someone wants this?". The category tree seems to bring out the negative nancy in the meeting with people looking for reasons it will fail and throwing out all sorts of one-off use cases that it does not meet.   So, one of the ideas that we have moved forward with is that the categorization is not important, what is important is what Business Service and Configuration Item (CI) is being impacted by the change. We use Business Services and CIs throughout the entire platform for classification because it allows us to easily demonstrate to stakeholders at various levels where our resources are going.   Our forms allow the users to pick the appropriate Business Service (we have two levels) and the appropriate CI. If they pick the CI it will automatically populate the Business Services for them.

At first people seemed against it, but they never had an answer to "Well, why are you doing something that we do not ultimate associate with a Business Service?".

For example, our very high level stake holders are not interested in what applications or servers are causing issues, but rather where are resources are being used in terms of Operations, Research, Infrastructure, etc. Other levels of people, such as team leaders and managers, are more concerned about the lower level items - such as what server is experiencing the most issues, what applications are creating the most support calls, etc.

I think this is what Robert is also stating above with using the CMDB as a driver and the catalog as a means to deliver the right "category" without the user having to ever select it. At least, I think he is saying that.

[spearmintlane]

As someone evaluating ServiceNow I have a couple of comments/questions about this.

1. How do you determine the operation that is being performed on the incident -- was it a connectivity issue, hardware failure, etc?
   1. How do you determine the difference between what the user is saying the issue is, versus what investigation determines the actual issue is?
      1. Example: User says that it's a connectivity issue with Outlook, but the investigation determines that it's a hardware failure on their network interface card
   2. Having these types of metrics in standardized fields makes it easier for management to understand that there's a specific issue with a particular type of CI to determine defects and other issues
2. It's been my experience that many companies are not at a maturity to actually populate the CMDB with CI's in the beginning. Being able to at least know that it's related to a specific product type (i.e. Microsoft Outlook) without actually having a CI is very valuable.
   1. How can you accomplish this?