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.

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!

How is your solution working?

I am looking for the same kind of solution. 

how you achieve this?

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!

the link does not work