All About Incident Classification

Incident classification is among the main tasks of Service Desk 1st tier people. It adds structured data to a basically hectic unstructured series of info we get from a nervous Customer.

Aside from prioritisation, which is another important issue, there are three main reasons for classification of incidents:

• Assignment and escalation
• Problem analysis
• Reporting

First reason gives us a hint why a Customer shouldn't categorize an incident. He is not trained for that, he reports his problem (over the phone, web, mail...) and it is an Operators task to assign the incident to a proper category.

Reporting is important because it provides inputs to other ITSM processes (Problem, Change...) and helps us stay in good relations with the Customer and the Management.

Therefore, the Incident Management tool should allow assigned people to re-classify the incident (change it's category) along the escalation path. Because sometimes the problem shows to be somewhere else. I.e. it's not the printer but the network. Some of the top Incident Management tools I know are very rigid regarding this and I know some Service Desks which used to close existing incident and open another one with a proper classification in this case. Sad.

Activities

Now, what are the best practices telling us, how do we assign categories to incidents? ITIL does not prescribe a hard coded form of classification. Usually the chosen IM tool will guide us, no matter how much is it advertised as fully customizable to adapt to your business process. So one should have this on the list of important factors during a tool selection process.

Here are a few things we should do:

• First, everyone has a legacy incident database. Being new to ITIL IM doesn't mean that you didn't resolve tickets, incidents or issues before. Take a look at the structure of legacy data, and discuss what is useful for your business process, what hierarchy should you prefer, and what's missing.
• Consider the management and customer reporting needs, this should give you some ideas.
• Business should understand your categories, although they are usually technical.
• Key Performance Indicator list - should define what is important.
• Review your process definitions and your main competency matrix. Are you technology or business oriented? Try to define your category tree based on that. See your legacy incidents, try to assign defined categories to them and analyse. Is it any good?
• Your Services Catalog and your SLAs should tell you a lot. Even if you don't have them, you probably know what are the major business critical services: mail, printing, document management, accounting. The longer the list, the more probable that you'll want to put these in the root of the category tree.
• Talk to your Problem Management people, they should know a lot.
• Brainstorm a lot.
• Start an Incident Management Pilot project for a month, and use your classification system. Analyze. See what's right and what can be better. Redefine if necessary. It's better to try and err then not to try at all until major production.

Possible Problems

• 1st line Operator education
• Customer portals sometimes offer a classification tool to a customer during Incident reporting. If this is done, this should be on a very basic level, and always checked and redefined by a 1st level operator.
• Depending on business process definition and classification scheme, it will be difficult for a 1st level operator to differ between Incidents, RFCs and Service Requests.

Examples

Now, how does this look in practice? As I mentioned, a tool can influence your decision a lot. Peregrine Service Center gives you a structure:
Category:Subcategory:ProductType:ProblemType
It's a nice four-tiered schema.

Remedy gives you
Category:Type:Item
A three-tiered schema, very good technical schema.

HP OpenView Service Desk provides two categories in combination with type and service.
It's fair to mention that the above tools and most of the others allow some amount of customization, adding or removing categories, and dynamically requesting different depth of classification based on type or main category. So whatever tool you choose, there is a chance that you will be able to adapt it fairly to your process. It's just that some of them will require more time/money and customized solutions can create problems on upgrades to following versions.

Now, examples? Some standard three tiered schema examples:

• Software:Server:Exchange (Technical classification according to your org. chart - Department:Team:Assignment)
• Server:Software:Exchange (Technical classification By CI categorization)
• Printing:Printer:Cannot Print (Service oriented - Service:Component:Problem)
• E-mail:Outlook:Access (Service oriented)

Depending on business requests and technology, some creativity is allowed here. For one of my customers we created the following: they had in-house developed IM tool, and some specific needs, so we created a category tree of unrestricted depth, with technology-oriented categories. Every node (category) has its own assigned Queue and escalation schema. Their expertise level varied with technology so some tickets had category field like:

Network:Switch

and some were:

Software:Server:OperatingSystem:Microsoft:Windows2k3

This system works for two years now, and they are a happy customer. They have a bit more complex reporting then usual, but also the classification that fits their business process.

Remember that along with categorization, Incidents carry a lot more of structured data (Priority, CI Info, SLA...), so in most cases a nice three-tiered categorization combined with these data will cover all your needs.

Of course, if there is a need for more, then a four-tiered possible classification would look like:

Software:Server:IBM:Domino
or:
Email:Server:Domino:JunkMail Filter (Service:Component:ProductType:ProblemType)

After all mentioned, one does understand that there is no easy formula. Sometimes the best way to understand things is to try and make mistakes. I hope that the above concerns will at least help you make less of them.