Loading...
 

How many categories do we need

By ITIL® from Experience ©

It is common to see ITSM tools with hundreds and hundreds of categories1. As a result, several categories end up having a similar meaning (e.g. fault, error, major error). Moreover, too many categories confuse people thus, they select one based on their best guess or randomly pick one out of frustration. On the opposite end, not enough categories can affect the organization’s ability to produce meaningful management reports.

ITIL® version 22 briefly mentions categories to log events as part of the overall classification3 of tickets. However, it falls short on providing examples or guidance in the number of categories one should have. ITIL® v3 on the other has no such guidance.

Based on our experience, the short answer is:
Just enough categories to: 1) enable the process and, 2) to enable the tool to function properly

To enable the process, the category informs the IT Specialist of the work to perform. It is also used to generate management reports to enable continuous service improvement (CSI) (see Why asking what you want to report on is the wrong way to implement a tool).

To enable the ITSM tool to function the category, in general since each tool is different, can:


That being said the ideal number of categories should be:

  1. Enough to select the right process flow;
  2. No more than the tool can display without having to go to a search box/window;


Realistically, a well-designed taxonomy5 should provide approximately 10 or less categories to log an event (i.e. incident, service request, problem or RFC). Keep in mind that many categories can be replaced by information captured on the login form or by taking a decisions while executing the business process (e.g. is this a standard workstations).

Fortunately, many tools6 can be configured to display a subset of appropriate categories. Some filter based on the nature of the event (i.e. incident, service request, problem or Changes) while others only display categories applicable to the Service or Configuration Item the event is logged against. Additionally, some tools force users to classify when closing the ticket in order to identify its cause or reason (e.g. User Error) thus, further reducing the number of categories available for logging. It is therefore reasonable for a tool to have a hundred or so categories even though the user is only presented with 10 or less categories to select from.

To avoid the proliferation and duplication of similar categories first, look at the existing categories to see if one can be re-used by implementing a new tool filter. Second, identify if an appropriate synonym already exist (e.g. error vs fault). Finally, implement governance to approve each request for a new category. It should review every request for a new category to ensure that it does not replicate a tool’s functionality, like an “Urgent loan” when the priority should be used instead (e.g. device for travel).

To close, it is easier to add categories than to reduce its number after the tool goes live. Therefore, start with less and expand as each process matures.


Last updated on: 2017-01-03

Quote:
When you have too many categories users can choose from, you might as well only have one called “Other” or “Miscellaneous” because the data cannot be trusted.

More Quotes



Related:

More on ITSM Tools


Category:
Implementation > Technology (ITSM Tools)


1. Category: A named group of things that have something in common. Categories are used to group similar things together. For example, cost types are used to group similar types of cost. Incident categories are used to group similar types of incident, while CI types are used to group similar types of configuration item. Source: ITIL® glossary and abbreviations, 2011 https://www.axelos.com/Corporate/media/Files/Glossaries/ITIL_2011_Glossary_GB-v1-0.pdf
2. ITIL v2 guidance on classification states that categories:
  • specify the service or equipment to which the Incident relates
  • associate any Service Level Agreement or Operational Level Agreement in place
  • select/define the best specialist or group to handle the Incident
  • define the priority and business impact, define what questions should be asked or information checked
  • act as a matching criterion for selecting solutions, Known Errors or Work-arounds
Source: ITIL® Service Support, 4.2.11 Incident classification
3. Classification: The act of assigning a category to something. Classification is used to ensure consistent management and reporting. Configuration items, incidents, problems, changes etc. are usually classified. Source: ITIL® glossary and abbreviations, 2011 https://www.axelos.com/Corporate/media/Files/Glossaries/ITIL_2011_Glossary_GB-v1-0.pdf
4. An automated workflow “allows a company to create a workflow model and components such as online forms … as a way to manage and enforce the consistent handling of work.” Source: http://searchcio.techtarget.com/definition/workflow
5. Taxonomy: A classification of things, or the principles underlying such a classification. The term may be applied to relationship schemes such as parent–child hierarchies and network structures. A taxonomy might also be a simple organization of kinds of things into groups, or even an alphabetical list. Source: Best Management Practice portfolio: common glossary of terms and definitions Version 1, October 2012 https://www.axelos.com/Corporate/media/Files/Glossaries/AXELOS-Common-Glossary.pdf
6. Marvel MSM Categorization system is called a Dictionary. Event Builders is the name used by assyst from Axios Systems while BCM Remedy calls theirs Category, Type and Item (CTI).


Disclaimer


Copyright 2014-2017 - ITIL® from Experience - D.Matte

Google Search