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.

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.
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.
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.
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.

Four Service Characteristics

Recently I came across several articles by researchers and experts that laid out definitions and characteristics of services. ITIL provides us with a definition that can help drive the creation of value-laden services: A means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks. An area that ITIL is not so clear is in terms of service characteristics. Several researchers and experts put forth that services have four basic characteristics (IHIP): Intangibility—Services are the results of actions not things. They have no physical presence and represent a logical set of elements. One way to think of service is “work done for others.” Heterogeneity—Also known as “variability”; services are unique items because of the mechanisms used to deliver services, which is people. Because the people element adds variability, the service is variable. This holds true, especially for the value proposition—not eve...

What Is A Service Offering?

The ITIL 4 Best Practice Guidance defines a “Service Offering” as a description of one or more services designed to address the needs of a target customer or group. As a service provider, we can’t stop there! We must know what the contracts of our service offering are and be able to put them into context as required by the customer. Let’s explore the three elements that comprise a Service Offering. A “Service Offering” may include: Goods, Access to Resources, and Service Actions 1. Goods – When we think of “Goods” within a service offering these are the items where ownership is transferred to the consumer and the consumer takes responsibility for the future use of these goods. Example of goods that are being provided in the offering – If this is a hotel service then toiletries or chocolates are yours to take with you. You the consumer own these and they are yours to take with you. ...

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

This article was originally published in 2015. With the Introduction of ITIL 4, some of this best practice has changed. See ITIL 4 and the Evolving Role of Roles . Updated Definitions in ITIL 4: Process Owner: In ITIL 4, the concept of 'processes' has expanded into broader 'practices.' Consequently, the Process Owner is now often referred to as the 'Practice Owner.' This individual is accountable for the overall design, performance, integration, and improvement of a specific practice within the organization. They ensure that the practice achieves its intended outcomes and aligns with the organization's objectives. Process Manager: Now commonly known as the 'Practice Manager' in ITIL 4, this role is responsible for the day-to-day management of the practice. The Practice Manager ensures that activities are carried out as intended, manages resources assigned to the practice, and oversees the practitioners performing the work. Process Practit...

Anonymous 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

August 11, 2009 at 3:57 PM

Search