ServiceNow only has two-tier categorization for Incidents (Category and Subcategory). Sometimes during Incident Management workshops I hear from clients that they need additional categorization, sometimes as many as five levels.

I always try to talk them out of this decision, and that they should stick with the ServiceNow out-of-the-box setup.

Why is that? It is easy to add the fields? Well, first a little history.

My History with Incident Categorization

I did programming on Peregrine ServiceCenter and HP ServiceCenter for ten years. These products revolved around categorization. It was a time-consuming process during workshops to decide on the categorization and the maintenance that followed it wasn't fun either.

Peregrine Service Center categorized Incidents by SCIM (System, Component, Item, Module). Peregrine also had a category field as well.

SCIM was mostly used for reporting. This five-layer categorization was a huge maintenance issue. Since it was used for reporting, I was sometimes asked to update closed incidents when the SCIM was changed. It was not good practice to update a closed incident, but the reports needed to be accurate.

Later on Peregrine was bought by HP. HP Service Manager switched to CSSP (Category, Subcategory, Product Type, Problem Type). Some still used this for reporting, but often the mindset was changed to make things event driven. When a certain CSSP was selected, the Assignment Group or other fields would be set.

Today, HP Service Anywhere has one categorization field.

What a change right? Why have all these software vendors abandoned the large categorization structure?

Reasons to choose two-layer categorization

Ease of Use. I have seen cases where there are over 50K categorization rows. It is likely technicians can't find the right categorization sometimes or have templates to get around using it. Moving to a two-layer categorization approach could go from the existing large number of entries to much smaller amount.
Popular Opinion. Most companies now choose this generic approach for categorization. ServiceNow OOB has 25, but most companies have 50 - 100.
Old Method. These large categorization setups are holdovers from old ITSM applications like Peregrine before CMDB and Service Catalog existed.
CMDB. Configuration Item field or affected items related list now more accurately captures CI information is more dynamically updated than categorization. By picking a CI, you know if it is server or software issue and all the other details that are contained in a CI.
Maintenance. Large categorization structures are often not maintained due to complexity. Duplicates and similar items occur when this happens. Reports not accurate due to these issues.
Technician Incident Time. It was frequently found that technicians spent a major amount of time categorizing their incidents. This was not a good usage of time to many companies

Companies are a final decision point on their categorization structure. The culture change of a two-tier categorization structure might be too much. In that case, I go ahead and build a larger categorization. However it is good to let them know the drawbacks before that decision is made.

Hope this helps on your implementation.

Mike