The lost art of incident classification | ALC Training News

  • No comments

Do you have a cluttered-up incident management tool?

Are your incident reports meaningless?

Does the Problem Manager constantly complain about an inability to decide what to investigate?

If the answer to any of these questions is “yes” then you could have lost that art form known as incident classification.

Classification of incidents is easy, right?  Wrong!

If you get incident classification wrong it will have a damaging effect on your business. You can’t manage what you can’t define!

Why you need an organised incident classification tool

To manage and understand you need to have the capability to classify incidents, effectively and efficiently. Without this you can get the wrong impact, wrong urgency and wrong resources.  In other words you can get it very very very WRONG. Get this right and you will see the benefits ripple through your delivery of service.

I hope that you are getting the drift of why we need to classify incidents.

But if you are still not sure consider the following: Classification starts at the Service Desk and is determined by the analyst.

By the way don’t forget that an incident is the unplanned disruption to or reduction in quality of the service.

This is different to a problem which is delving into “unknown causes” and is a different topic. The assumption is that the Service desk will “know” and “understand” the incident and classify it accordingly.

Once the incident has been correctly classified the knowledge base can be interrogated to identify a potential service restoration technique “work around”. That is of course assuming that they have knowledge tools to assist with first-call resolution.

If such a restoration technique cannot be found then the correct classification will result in appropriate routing to the correct team for resolution. Sadly it is still very common to see organisations defining a classification code of “other or miscellaneous”. 

This is sometimes known as a bucket, bin or put simply in the too hard basket. In other words a rubbish receptacle even though that is not the conscious intention. Poorly classified incidents often enter the sporting arena and departments start playing different games known as “incident Ping-Pong or basketball (bouncing around)” along with many other terms. Sadly this sporting prowess does very little to address customer and user dissatisfaction.

The benefits of good incident classification 

Good classification helps us to understand what is impacted, who is affected and get the appropriate scripts, knowledge and tools to restore the service as soon as possible. Good scripts are kept as simple as possible and are one of the many ingredients in our recipe. The caller is not loaded with endless questions to determine the cause. Yes, scripts are extremely important and need to be done correctly. 

Another ingredient is the Configuration Item (CI). Symptoms are often associated with a CI and linking this is critical to avoid being thrown off the track. But beware – symptoms are logged and communicated in different ways and in some cases not even remotely similar but don’t let this fool you. If you can link the incident to a CI, you are one step closer.

So remember, log the symptoms, but in the description and not under the classification.

If you have good maturity in Service Asset and Configuration Management, you can even link the incident to the Service that is impacted as represented in the Service Catalogue. If not at the very least, link the incident to the physical CI. This will help to understand the impact the incident has on the business and lead to improved incident prioritisation.

Once the Service Desk analyst has determined that the call really is an incident, then classification can start. Be specific and categorise and sub-categorise the incident to a deeper level, e.g. Hardware – Printer – Model or Software – Application – Payroll. Don’t go overboard and keep it as simple as you can without losing quality. Three levels are a good limit.

Once the incident has been resolved, check the original classification and have a resolution classification if the original was incorrect.

This is beneficial for a few reasons including:

  • To confirm original classification was done correctly and identify potential training needs for improved initial classification.
  • Identify possible errors in the Configuration Management System (CMS).

Good classification will result in:

  • Meaningful incident reports
  • Organised incident records
  • Problem management ease in determining which incidents to investigate
  • Improved customer satisfaction

ALC Group