1300 130 447
make a knowledge base
available to end users
Source - HDI Report
About the Knowledge Base
Search all the Knowledge Base
Testimonial: I have found that the new HDAA Knowledge Base reduces the time it takes me to research industry stats & reliable information for the ITSM sector. It’s easy to use search functionality encompassing KCS principles, helps to filter & tailor my searches more accurately & there are numerous new services now available through the website. Every time I return to the site there is new information published. Very impressive.
Chris Powderly, Support & Services Manager, Allens
supportworld , service management , incident management , process , process management , change management
No Result Found
In part one of this series, I looked at basic categorization schemes and why categorization is so important for decision-making. In this part, I will walk you through, step-by-step, how to create a new categorization scheme that will work for your organization.
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 grouped 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?" Here is the seven-step process to help your organization develop a categorization scheme that works:
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. Service-based categorization 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 general but not too broad. Ten to fifteen high-level choices should keep the level of detail at the correct level.
To develop an accurate high-level categorization:
Goal: Develop 10 to 15, high-level working categories.
How do you get a consensus on the high-level choices? Review the structure after three to six months of use:
Goal: Standardize on 10 to 12 categories.
Next, you must decide the secondary level. To complete this step, look at the incidents in each high-level category and further determine how to divide those tickets up effectively within the categorization. The second level should be specific but should not dive into the minutiae:
Goal: Develop 10 to 15 types per category from Step 2.
The third level provides much more granularity into the specifics of what is occurring in the incident. The level of detail here has to be driven by organizational need and the type of incidents that are captured:
Goal: Develop 10 to 15 items per type identified in Step 3.
The next step is to establish a structure that will be used and tested in the live environment. At this point, the structure is in draft form 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 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. Analyze the “other” categories on a weekly or bi-weekly basis to determine additional category/type/item (CTI) structures that must be added. Long-term use of the other structure should be avoided.
Goal: Gather information on how the draft structure works during the pilot in the live environment.
After the pilot is complete, it is crucial to now go back and review the “other” categories and determine if the categorization structure works for all incidents identified in the pilot and after. Once you’ve reviewed the "other" category, you should probably remove it from the structure as an option. It is imperative not to change the categorization structure too often after the pilot as the organization will lose the historical perspective of the data.
Goal: Improve as needed to meet the evolving needs of the business.
Once the team finalizes the categorization structure, place it under change control. Any new categorizations that are identified should only be added after an RFC is submitted and the risk of changing the structure is adequately assessed. However, some circumstances will commonly require adjustments to the categorization:
Goal: Require the organization to agree on changes to minimize risk.
Too Many or Too Few. There are many ditches to avoid in categorization. If the categorization has CTI structures with too many tickets or too few, this is an indication that the categorization scheme 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, then the structure may not have enough detail. If a CTI structure contains less than 2%, then it probably is too specific.
Avoid Constant Re-Categorization. Every change to the categorization will modify the way existing data is structured and will impact historical analysis. Changes to the categorization must be carefully planned for the risk that it can introduce. It should not, however, discourage change. Organizations are not stagnant, and neither should the categorization scheme be frozen in time.
Do Not Categorize by Symptoms. It is also essential 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 and will immediately produce unreliable data. Symptoms are more appropriate for metadata fields or other available fields in the incident record.
What Reports Are Needed? Reporting from the incident management system is essential 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. The collected data should drive improvements that are meaningful to the business and IT.
Decide first what data you need out of the incident management system. If you can get agreement on what needs to be in the reports for the incident management process and services, then it will help the organization to further define the requirements in the categorization activity. Additionally, if service level agreements are implemented, review the agreements to help to identify additional required measurements.
Maintain a Customer or Business Focus. The tendency for an IT organization is to focus the CTI structure on the internal view of IT. An internal-only 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 upon what is important to the business.
Be Sure to Train. 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 within the ITSM system and know how to handle exceptions will have higher quality data. Redundancy of categorization must be avoided through both design of the categorization but also in the operational use of the categorization.
Use Closure Categories. Changes to the categorization of an incident throughout the incident management process should be avoided. If a customer calls in and reports an incident and the categorization is selected but later it is determined to be incorrect, the best way to handle this situation is to create a closure categorization. Closure categorization provides the organization with a way to improve the process and improve the 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. Both categorizations can be helpful to find the solution the next time the issue occurs.
Put Structure Under Change Control. Once the environment has stabilized, the categorization should be under change control to ensure that any changes will keep the underlying data in its highest level of accuracy.
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 across functional silos not based upon the technology that is managed. A well-designed categorization 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, and it is especially true with categorization. Creating a useable and sustainable categorization is a tough exercise that will pay off in the end. The data collected in the incident management process represents every touchpoint, 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. That is definitely something worth doing.
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 on topics of authentic leadership, business strategy, knowledge management, organizational culture, and innovation. Julie has a B.S. in computer science from The Ohio State University and an 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. She is an HDI Business Associate and teaches training and certification classes for service and support professionals. Visit her website, and follow her on Twitter @JulieMohr, YouTube, and LinkedIn.
No Result Found
- Contact Us
- IT Membership
- Support Centre Association
- Comparison Guide
- Price Guide
- Membership Conditions
Training & Workshops
- Training Courses
- Recent Workshops
- Cancellation & Transfer Policy
- ITIL Training
- ITIL Foundations
- Support Centre Consulting
- Service Desk Consulting
- Help Desk Consulting
- Media Kit
- Update your details
- New account
© Copyright HDAA. All rights reserved.
HDAA - Energising the Service & Support Profession
Help Desk Association Australasia Pty Ltd trading as HDAA
T: 1300 130 447 T: +61 (0) 2 9986 1988 F: +61 (0) 2 9986 1330
E: firstname.lastname@example.org W: www.hdaa.com.au A: PO Box 303, Turramurra NSW 2074 Australia
ABN: 20 088 292 755
Our Services: ITIL | ITIL Training | ITIL Foundations | IT Membership | Service Desk Association | Support Centre Association | Support Centre Training | Service Desk Training | Help Desk Training | Support Centre Consulting | Service Desk Consulting | Help Desk Consulting
ITIL® and PRINCE2® are registered trade marks of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved.
RESILIA™ is a trade mark of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved.
The Swirl logo™ is a trade mark of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved.
DevOps Foundation®, is a registered mark of the DevOps Institute.
HDI® is a Registered Trade Mark. HDAA is the Australasian Gold Partner of HDI®.
KCS℠ is a Service Mark of the Consortium for Service Innovation™.
SIAM™ is a registered trademark of EXIN.