provided by: 
Originally published at Internet.com Incident classification and initial support and the activities carried out by service desk staff to determine how to work or route an incident for resolution. The IT Infrastructure Library (ITIL) covers classification very well. There are numerous checklists and samples available and most service management systems offer built-in assistance with classification.
Still, many IT organizations struggle with classification. This is evidenced by the number of incidents coded as "unknown" or "other." This means that classification has failed; leading to more downtime and decreased service quality.
These mis-categorized incidents often bounce from technician to technician and, as the clock runs out, IT has to escalate and resolve them. This is one of the root causes of "fire fighting" and consumes significant organizational resources.
There are several relatively quick and easy fixes for this problem, and below I describe 8 simple steps to improve incident classification.
Classification
Classification is understanding, identifying, and quantifying affected systems. Effective classification helps route the incident to the correct team. Classification starts to go wrong when diagnostic scripts become to complex.
While extremely valuable, scripts require diligent management effort. However, trying to collect massive amounts of data through dozens of questions slows the process down, complicates the workflow, and results in incomplete classification.
A simple observation is to keep your diagnostic scripts as simple and purposeful as possible.
To improve classification, examine the following 8 areas:
Use diagnostic scripts. Use scripts to standardize and formalize incident classification. Without a repeatable process like a script you cannot reliably classify incidents. Without good, easy to use scripts you will not obtain management information required to maintain their effectiveness.
Classify by configuration item (CI), not symptoms. The classic mistake often repeated is to classify an incident based on what the user says (e.g., thinks) is the problem.
This is a recipe for bouncing incidents. Symptoms change, can be misleading, and quite often the user honestly does not know what they are experiencing.
Instead, collect information (No.1 above) and base the decision on the affected service, system, etc. Do record the symptoms in a comments field, but know that different users report different symptoms for the same incident. Classifying on symptom is worst- not best-practice.
Classify incidents, not calls. Logging calls is a very different activity from classification and initial support. Call logging simply gathers route data a specialist will use later. If you are logging calls, then do not bother trying to perform incident classification.
Keep it simple. Review all diagnostic scripts often to make sure they are not too complicated. Good enough is perfect. Too much time spent trying to make a perfect script often results in something to difficult and long winded for staff to complete in a reasonable amount of time.
Always make sure you include "other" or "unknown" as diagnostic codes. These codes are indicators that your scripts need maintenance.
Use a service catalog. If you have a service catalog, use it. If you do not have one, consider implementing one. Service catalogs can dramatically improve the speed of incident classification as you have to collect less information. This improves data accuracy in the incident record, and assists in routing, escalation, and support.
Use your tools. Most of the automated software tools available today provide really well implemented incident classification features, but you have to use them! Check into the capabilities of your systems, and if possible, use them. Reemember tip No.4.
Take maturity into account. You can't win the Super Bowl with a high school football team. For new organizations, or those without strong process controls, you will need to change slowly over time. You need to assess your maturity to establish your expectations. Don't try to take your high school team to the super bowl.
Validate your scope. It is very important to realize that not every single event that occurs warrants an incident. It is easy to set your scope too wide or too narrow.
To wide and every normal automated system event can become an incident; swamping your staff and systems. To narrow and you are not delivering the highest value.
A good rule-of-thumb is to raise an incident only if there is some action required. This means that normal diagnostic messages on throughput, utilization and so on should not be incidents. Set your scope carefully for highest performance.
A Simple Classification Scheme
As I mentioned before, configuration items should form the basis for incident classification. There are two basic methods available: you can classify incidents based on the system or service under question (e.g., "email"); or you can classify on the physical configuration item (e.g., "workstation").
You could start using physical configuration items and, as you mature and document services using a service catalog, you could expand to include services.
Regardless of classifying on service or configuration item (CI), you should include at least the following three fields: Type, Category, and Sub-category.
The type field helps concentrate the required support, and often aids in prioritization as well. There are three basic types in the ITIL: Fault, Service Request, Assistance Inquiry.
After identifying the type of incident, the category is used to select a technology domain. When setting up your categories try to keep them to as few as possible.
If you are going to have a system based on classification of physical CIs then a simple list of ITIL CI types works well. The ITIL describes the following categories: Hardware, Software, Network, People, Process, Accommodation, and Documentation.
The Sub-category field specifies more detail. Entries will be quite specific to your organization and less generic than type or category. Again, it is best to start with a small list. Following are some examples:
* Hardware: Workstation, printer, monitor, phone, etc. * Software: Order entry, AR/AP, etc. * Accommodation: Moves, Adds, Changes, etc.
Such a classification system might look as follows:
* Type: Fault * Category: Software * Sub-category: Database * Note: User reports "SQL error" when looking up customer "H.Marquis"
Notice how user reported symptoms are in the notes. The diagnosis is based on CI, and can now specifically route to the right group for restoration.
This type of system is pretty easy to develop, and the required scripts are small. You will also find it very effective for routing incidents to the right support group.
The Benefits
A simple, yet effective classification system provides many benefits:
* Quickly finds workarounds and fixes to incidents. * Properly routes incidents to the correct support group. * Speeds diagnoses by collecting the right information. * Helps build and maintain a knowledge base * Improves the efficiency of technical groups. * Enhances customer satisfaction. * Increases user productivity. * Establishes a strong base for proactive operations.
In the end, the benefits far outweigh the work involved.
Hank Marquis is a managing partner and CTO at itSM Solutions, an ITSM education and mentoring company.
Author: Hank Marquis
Read article at Internet.com site