Free Downloads

MindMaps:
ISO 20000: 2011
and
ITIL 2011 MMap
 

Templates:
Request for Change (RFC) Template

Major Incident Report Template

Posters:
ISO 20000/ITIL Timeline poster

    

Sponsored Links

 

Google

May 29, 2007

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.



10 comments:

Anonymous said...

It seems to me that we need to avoid referring to the noun in our classifications. There seems to be a best practice advantage (applicability across multiple noun groupings) to keeping these values as symptomatic adjectives. Examples might include:

Fault:Performance:Slow

or

Fault:Availability:Down

or

Help:Information Needed:Uncertain

or whatever...

I've seen people attempt to include the noun in their categories and it simply explodes the list into thousands instead of a couple hundred.

doctor said...

Well, this is probably coming from experience and with good intentions.

This could be something you mention to a customer at the beginning of incident category tree definition. On the other hand, every new organization differs more or less in their processes and attitude, so if someone wants nouns, I wouldn’t be so worried about grammar ;-)

What is most important is to implement periodical review/amend process which will enable the organization to adjust to new requirements. Organizations learn a lot with time and practice.

Category tree should not be a holly cow, and business should not be afraid to redefine the tree (or maybe the whole process) if it shows to be inadequate. Continuous improvement…

Thanks for your comment.

Anonymous said...

Thank you for this excellent article.
I would add that it is costly to redefine the classification in terms of design, training and reporting. In my business, we made the mistake of an overly technical classification. With my experience, a focused approach on symptoms is better because it corresponds to the requests made by the customer (for incidents or requests).
I therefore propose the following structure to complete the examples:
Type:Service:Component:Symptom
(Incident:Email:Sending:I can not send emails externally)

Thank you for your return.

doctor said...

Dear Anon,

Of course, this is an excellent approach when working with end users, and requires shorter education curve on your SD staff.

When you do system support, then a slightly more techie classification is allowed.

So it all depends on who are the customers, what your process is, and what do you work with. PEOPLE, PROCESS, TECHNOLOGY, as we heard before.

Thanx for your comment.

Rohit said...

Thank you for this article and has been really insightful.

A thought though, since for any IM tool there are two aspects to PEOPLE, a) the Initiator of the Incident b) the Receiver (the Resolution team). However, the understanding in terms of the way we classify the Incidents could be totally different. The Initiator, most of the times from the Business side, will be more comfortable with Service Way of calssifying whereas the Resolution team, mostly from the Technical Side, will be more comfortable with Technical or Application oriented classification.

I welcome your thoughts.

doctor said...

True, Rohit.

So maybe we would need technical and business classification?
This reminds us of the ServiceCatalog structure in ITIL V3!

So business can determine what business service is in danger (by selecting CI from Business Service Catalog), and SD operator will choose technical category which is later important in defining the queue or assignment people.

Afterwords, business and SD can draw reports according to parameters they need and understand.

Thanks for your comment!

Anonymous said...

Il semble que vous soyez un expert dans ce domaine, vos remarques sont tres interessantes, merci.

- Daniel

Anonymous said...

Hey - I am really delighted to discover this. cool job!

Anonymous said...

https://communities.bmc.com/communities/docs/DOC-128

I found this to be a great resource for anyone trying to take a shot at determining CTI's.

D.Matte said...

ITIL proposes a technique and steps to prepare incident categorization from scractch.

See ITIL® Service Operations, Section 4.2.5.3. Page 50 in the 2007 Edition and page 78 in the 2011 Edition.

www.ITILfromExperience.com