Defining Categories

I often hear from organizations that they are not reaping the expected benefits from their Incident Management Systems or integrated Service Management suites. One of the biggest reasons is that they are struggling to determine how to categorize incidents, problems, service requests, changes, and so forth. Coming up with the right categories for your organization is easier said than done. If you’ve had to do it multiple times, you’re not alone. Having said that, it is important to persist. Categories drive many process activities such as:
  • Incident matching
  • Second- and third-level escalations
  • Workflow management
  • Self-service decision tree logic
  • Priority definition
  • Knowledge base searches
  • Trend and root cause analysis
  • Metrics production
  • SLA reporting

Miscategorized records cause inefficiencies, ineffective reporting and can even damage the relationships between lines of support. For example, are your second-line support teams regularly asking “why was this record assigned to me?” If so, it may be time to stop blaming the Service Desk and start looking at your categories. You may find that your tool is driving those incorrect escalations.

Most tools provide the ability to capture three or four levels of granularity. While your categories will be unique to your organization, there are a few common steps you can take whether you are just getting started, or need to start over.

  1. Hold a brainstorming session with all process stakeholders and decide on the highest level categories. Start with broad, easy to understand and use categories. A good rule of thumb is to have 10 or fewer categories at the high level, including an “Other” category.
  2. If possible, pilot your high level categories for a short period of time. Use a simple check sheet, a temporary field in your system… whatever works. Run the pilot long enough to log a few hundred records, produce some reports, track the use of “Other,” and collect enough data to conduct a meaningful analysis.
  3. Analyze the results. If a category was never or rarely used, do you really need it? Was “Other” used? If so, why? Is there a category you missed? Do your analysts need training? Refine your high level categories (or your training program) as needed and then begin defining your lower level categories.
  4. When defining lower level categories, reach agreement on the rules you’ll use when determining data values based on the results you want to produce and the workflow you want to drive. Such rules may include:
  • Category: High level – what – noun (e.g., hardware, software, application, network, database, security, etc.)
  • Subcategory/type: More specific – what – noun (e.g., subcategories for the “hardware” category may include printer, laptop and BlackBerry)
  • Item: Most specific – what – noun (e.g., items for a “printer” may include power supply and sheet feeder)
  • Symptom: Action or error – verb – user perspective (e.g., symptoms may include an error message appearing on the printer display such as paper jam or printer ink low

If possible, expand your pilot to include your lower level categories. If that isn’t possible, use a spread sheet to collect data values from all stakeholder groups. View the spread sheet as a “living document” for a pre-defined period of time. Review and refine the data values until you are ready to go live.

Now, about that “Other” category. Some say you should never have an “Other” category. The Professor disagrees. The reality is that if you do not have an “Other” category, people are just going to take a guess or pick the first option on the list. Providing an “Other” category enables you to know when people are unsure what to select. The key is to monitor the use of “Other,” perhaps by having it trigger an email to the Process Manager for review, or by producing a regular report. You can then take appropriate action such as providing training or adding a new category if needed.

Effective categories provide the information needed to monitor, measure and improve your processes and services. They also facilitate streamlined processes and workflow automation. The most effective categories are customer and business focused, easy to understand and use (10 or fewer at the highest level), designed to produce the desired results, and rigorously maintained. Want more info? The ITIL V3 Service Operation publication provides additional guidance and examples.

Comments

glenn861 said…
I promote the use of the name of the service as the top level. This allows an easy tie to SLAs and supports problem management from a service perspective. For lower levels I start with the defect, i.e. top category is "Printing," the next level is "can't print." The classification of the cause fills out the picture, i.e. "User access."

Glenn Robinson
Ultra/ProLogic

Popular posts from this blog

The Role of Process Practitioner

The Difference between Change and Release Management

What is the difference between Process Owner, Process Manager and Process Practitioner?

Search This Blog