Incident Classification Schemes

As an IT Service Management consultant implementing Service Desk solutions, one of the core assignments I give my clients ahead of time is to consider how they would like to classify Incidents—i.e. Incident taxonomy. I start this process early because I find it is one of the most difficult things about Incident management my clients struggle with. The problem is there is no right or wrong answer to this task but there is some guidance I also provide.
When identifying an Incident classification scheme, you must consider the two main reasons you need to accurately classify incidents which are:

  • To facilitate quick and accurate routing of an Incident to the proper Team or individual the first time.

  • After the fact reporting to identify areas for “Continuous Service Improvement” as defined by ITIL. That is, create a scheme that will allow for the use of a metrics-driven approach to identifying opportunities for improvement to services and to measure the impact of improvement efforts. i.e. the reduction of Incidents in that area.

The other thing I suggest is to consider how your IT organization is structured from a functional perspective. This can be pretty much a no brainer because most organizations are structured along the lines of Security, Network, Hardware, and Enterprise Applications, etc. So generally, the top level of a classification scheme will follow these lines, but I am going to suggest a bit more intelligence to this.

So, given everything said above how do we come up with this scheme (taxonomy)? My approach is as follows:

  • Do not go any deeper than three levels. I used to say two, but I have been experimenting with a third level called “Symptom” for better identification of specific recurring issues. So, the structure might be Category, Sub-Category, and Symptom. Now in Category I try to move away from the traditional values of Hardware, Software, Network and try to make more specific use of the top-level by, for example, In the “Category drop-down having:

    • Enterprise Applications – SAP 

    • Enterprise Application – HR

    • Hardware – Workstation

    • Hardware – Printer

    • Productivity Software – Microsoft Office

    • Productivity Software – Adobe Creative Suite

  • Then if SAP is selected Expose the Sub-Category field with the various SAP modules that may be the subject of the incident such as:

    • Asset Accounting

    • Sales and Distributing

    • Material Management

    • Production Planning

  • Next, we expose the “Symptom” field which further refines the classification of the incident with values such as:

    • Data Issue

    • Navigation Issue

    • Functionality Issue

    • Abnormal termination

  • All other details would be listed in the description field or as an attachment.

Another example might be when selecting the Category of “Hardware – Printer” we would expose “Sub-Category” with values:

    • Locally Attached Printer

    • Network Printer

  • Then we expose the “Symptom” field with values:

    • Error Code displayed (Add to description)

    • Can’t connect

    • Paper Jam

    • Out of Ink

    • Won’t print

Hopefully, you get the idea. With a scheme along these lines, the “category” field can usually be used for automation of Incident routing and the sub-category and symptom fields can be very useful for identifying areas for Continuous Improvement.

 

By Gary Guglielmo | August 10th, 2020 | 0 Comments

Follow us on Twitter