Incident categorization is a challenge for organizations. Whether it is due to culture, politics, complexity, or an inability to agree – every organization at some point finds that the categorization of incidents is difficult. Why does it cause so much of a challenge? Every organization is different. The products and services are different. The service levels are different. The customers are different, and the knowledge is different. Even the reports are different. Each one of these distinguishing factors impacts how incidents are tracked and monitored. There is no master categorization theme to use because it is up to your organization to define what works for your environment.
What is Categorization?
Incidents are prioritized and categorized during the incident management process. The prioritization gives us the importance of the incident related to impact to the business and the urgency related to the timing of when the incident occurs. Categorization is the process of arranging the incidents into classes or categories. In the incident management process, this provides us the ability to track similar incidents related to the products and services that are offered to the business.
Why is Categorization Important?
When an incident is first categorized, it enables the analyst to search for knowledge in the form of incidents, problems or known errors. When an incident can only be categorized in one way, the search against previous knowledge is more efficient. If knowledge is not present, the categorization provides the structure to begin gathering the information necessary to diagnose and categorize the new knowledge. The act of categorizing the incident speeds up the process and creates higher efficiency within the process flow.
The next value-add of the categorization is defining the group that the incident is escalated to if the issue cannot be solved. When the escalation group is tied to the categorization, the organization can eliminate errors in the escalation process. Finally, another benefit to efficient categorization is the ability to produce meaningful reports, conduct trend analysis, and this helps the organization to take a more proactive approach to managing services.
In the service lifecycle, there are other aspects of value delivery that are tied to the categorization. The service catalog provides a view of the services that are in the operational environment. The ability to put services into categories that make sense to our customers makes it easier for customers to find information about those services and how to request them. The categorization of incidents is directly related to the ability to categorize our services. All too often organizations try to categorize incidents before they understand how to categorize services. Even worse, if you decide to categorize incidents without understanding services, then the categorization is likely to be very technology focused and cannot provide a view of the impacted service. A technology focus will limit proactive service management.
Incident management drives process improvement through the analysis of incidents to identify improvement opportunities. Categorization is also linked to what skills are needed to support the products and services that are offered and training and career development of analysts.
Categorization is also critical to establishing expectations when the organization develops operational level agreements. What is solved at the Service Desk before it is escalated to level 2? The organization needs a core understanding of the types of incidents related to services, the level of support provided at the service desk and what is provided by level 2 and beyond.
Event management also has a direct dependency on incident categorization. The ability to build automation that supports filtering events and correlate to identify incidents and determine the appropriate control action is vital to the success of the process.
Proactive problem management is nearly impossible to do without proper categorization. Imagine trying to run a report that provides visibility into all incidents and reports related to a specific service, type of issue, or component if the analyst can log a single incident in five or six different categorizations. There will be no ability to conduct trend analysis. A report may find some similarities between incidents and problems but without the full picture we may not
It is no wonder why this is difficult to do, with so many dependencies and requirements, how do we create a categorization scheme that works?
At the core, categorization is like a set of buckets. Each bucket holds a bunch of incidents and within the bucket; these incidents would then be logically groups by a subset of characteristics within the bucket. The first decision that needs to be made is what is the highest level of the hierarchy?
Categorization is based upon a hierarchical structure that has multiple levels of classification. The hierarchy is often described as a category/type/item structure. Once the analyst picks a high-level category, a type is chosen followed by an item. If this is done efficiently, the category defines a subset of types, and the selection of a type provides a subsection of items. This hierarchy simplifies the categorization of incidents, reduces error and helps to tie the unique category/type/item (CTI) to an owner.
Step One – Identify the Buckets
Incidents can be categorized by call, by type, by caller, by technology, by incident or by service. The first decision is which of these is most important to the customer? Typically organizations that are implementing service management will take the approach of starting with the service. A service focus provides a substantial amount of value to understanding service performance and helps to identify improvements to services. This upper-level classification will not work with all organizations. External service providers may decide to choose a customer at the highest level.
The key is to keep the upper or primary level broad but not too broad. Ten to fifteen high-level choices should maintain the level of detail at the correct level.
Step Two – Verify Buckets
How do you get these high-level choices? Start with 3-6 months of historical records and begin to assemble the incidents by your high-level criteria and limit the organization to the number of selections that are possible.
Step Three – Dump the Buckets
The secondary level is what has to be decided next. This exercise is completed by looking at the incidents that are put into a bucket and further deciding how to divide those tickets up efficiently within the bucket. The second level should be specific but should not dive down into the minutiae.
The third level provides much greater visibilities into the specifics of what is occurring in the incident. Again, the level of detail here has to be driven by organization need and the type of incidents that are captured.
An example of this type of structure would be as follows:
- Choice 1: What is the affected service? Select service.
- Choice 2: What is the type of issue affecting the service? Select type.
- Choice 3: What is the specific item that the user is facing? Select item.
Step Four – Pilot the Buckets
The next step is to establish a temporary structure that will be used and tested in the live environment. At this point, the structure is temporary to allow for modification based upon actual calls that are received. Each call that does not fit into the structure should be reviewed to determine if a change is needed to the structure. To not slow down the flow and handling of incidents, an “other” category is often used. All analysts are encouraged to put incidents into the other category when the structure doesn’t handle the type of incident reported. The other categories are then analyzed on a weekly or bi-weekly basis to determine additional CTI structures that must be added. Long-term use of the other structure should be avoided.
Problems to Avoid
There are many ditches to avoid in categorization. If the categorization has many CTI structures with too many tickets or too few, this is an indication that the level is not effective. The exact number is hard to determine but is more easily expressed in percentages. If you have a CTI structure that holds 25% of your ticket volume than the structure may not have enough detail. If a CTI structure contains less than 2%, then it probably is too specific.
Changes to the categorization throughout the incident management process should be avoided. If a customer calls in and reports an incident and the categorization is determined but later to be found as incorrect, the best way to handle this is to create a closure categorization. Using a closure categorization provides the organization a way to improve the process and improve training of analysts recording the incidents. Also, some incidents will present symptoms that indicate a particular structure, but it is uncovered through diagnosis that the issue turns out to be something very different. To find the solution the next time the issue occurs will be easier to find if both categorizations are kept.
The tendency for an IT organization is to focus the CTI structure on the internal view of IT. An internal view will serve the purpose of identifying improvements in components but won’t serve the need to drive improvements in services. The data collection must be business driven not IT driven. The external view will provide data collection that will support better decision-making and analysis based on what is important to the business.
It is also important to focus on capturing information that is factual and not symptom-based. A specific IT incident can have many different symptoms. To categorize by symptoms would very quickly permit multiple categorizations for one type of incident. Multiple possible categorizations will immediately produce unreliable data.
Critical Success Factors
Decide first what data you need out of the incident management system. If you can get agreement on what needs to be in reports on the incident management process and services, then it will help the organization to define the outcome of the categorization activity. Service level agreements are instrumental to identifying what we should measure in the environment. The categorization ensures that those measurements are possible.
Training is essential to the correct categorization of incidents. Even the best-defined categorization scheme is subject to error. Organizations that are trained on how to categorize with the ticketing system and know how to handle exceptions will have higher quality data. Redundancy of categorization must be avoided through design and operation.
Once the environment has stabilized, the categorization should be under change control. A formal control process will ensure that any changes to the structure will ensure that the underlying data is kept at its highest level of accuracy possible. Every change to the categorization will change the way existing data is structure. A structure that is under constant change will impact historical analysis. Changes to the categorization structure must be carefully planned for the risk that it could introduce. It should not, however, discourage change. Organizations are not stagnant, and neither should the categorization scheme be frozen in time.
Reporting from the incident management system is important for overall quality improvement of services, processes, technologies, people, and the overall customer experience. All service management processes use this data to support decision-making. It is important to keep this in mind when data is structured, captured and used in reports that are provided to these processes. All existing processes that are defined and managed will need this data as an input, and their needs must be taken into account.
Benefits of Good Categorization
The benefits of a good categorization scheme are many. The categorization will ease the process of logging incidents, reduce redundancy, and strengthen the organization’s ability to manage knowledge and use it to support decision making. The underlying data will enable the organization to take a proactive view of service management and identify improvement opportunities. The view will be cross-functional silos not based on the technology that is managed. A cross-functional view will provide a better overall view of the services and how they are meeting customer expectations and service level targets.
Someone once said that nothing in life worth doing is easy. Categorization is a tough exercise that will prove to pay off in the end. The data collected in the incident management process represents every touch point, every aspect of the customer experience. If we capture that knowledge in a way that it can be reused to support continual improvement, the organization will improve services, improve customer satisfaction, and improve efficiency and effectiveness of operation. Categorization done right is something worth doing!
About the Author:
Julie is a dynamic, engaging change agent who brings authenticity, integrity, and passion to practitioners worldwide. Through her books, articles, speaking, consulting, and teaching — her purpose is to spark change in the world with thought-provoking dialog and interaction. Julie has a B.S. degree in computer science from The Ohio State University, a MaED from the University of Phoenix, and is currently pursuing her Ph.D. in Management and Organizational Leadership in Information Systems & Technology from the University of Phoenix. She is an ITIL Expert, Certified Help Desk Director, and Certified Governance IT Professional.
Julie captivates audiences at conferences worldwide on topics of authentic leadership, business strategy, knowledge management, organizational culture, and innovation.
Follow Julie —