June 24, 2009
Categorization in Service Manager
In the Service and Incident modules, categorization is the most important piece of information applied to a ticket. Categorization allows the tickets to be subdivided, organized, reported on, and allows for unique workflow by type. Whether you are upgrading, implementing, or just configuring Service Manager 7.1, careful attention to categorization will greatly increase the product usability.
In Service Manager 7.1, categorization changes from a four-tiered Category, Subcategory, Product Type and Problem Type to a three tiered Category, Area, and Sub Area. The underlying fields have not changed and the fourth categorization field remains for organizations that still need it. The difference in Service Manager 7 is that the categorization tree applies to a Service Area and Configuration Item. These are now segregated from the categorization and allow the Categorization to be more specific to the affected service.
- Category is the highest level and reflects the overall area that is affected
- Area (or Subcategory) subdivides the category into a more granular view of the affected area
- Sub Area (or Product Type) is commonly used to house CI information or the actual item that is affected
Problem Type is no longer a required part of the categorization tree. This field can be optionally used to describe the primary symptom being reported.
This structure is very integrated into the Service Manager product and the categorization structure can provide support for:
- Driving alerts and notifications
- Providing a centralized view to which items are having Service Interruptions
- Automatic assignment to a particular group
- Automatic severity assigned to certain items
- Providing a good standard for reporting and metrics
If your organization does not currently have a formal categorization structure or your organization is not utilizing the methodology supported by Service Manager, it is a good idea to review that structure and implement a new categorization scheme for Service Manager.
There is no one perfect structure for categorization. This is why there is no “published” categorization. No one method will work for all organizations. A financial service desk will want to track different information than an internal support service desk. The trick is finding a balance between under-categorization and over-categorization.
If your categorization structure is under-categorized, it won’t offer enough choices and will not enable your organization to recognize and identify trends and provide predictive problem analysis. Likewise, a categorization structure that is too granular will leave an agent lost in the web of details, unable to make a clear choice between selections.
While designing a categorization structure, there are some good design principles to follow:
- ITIL recommends limiting the top level category to approximately 5 to 7 selections. Beyond that number, it becomes far too complicated to categorize incidents in a timely and efficient manner
- Whenever possible, place the failed component (item) at the same level in the structure. Typically, this is the Sub Area field. Knowledgeable agents are able to use this field to abbreviate their search and be more efficient in the categorization of their incidents.
- Maintain standardized lists of problem types. In many cases, the same types of problems are reported across the enterprise. By maintaining a more common list of problem types, agents are able to quickly and efficiently categorize incidents
Good categorization is extremely important to the enterprise in being able to enter and report on incidents. As noted above, categorization drives the alerts and notifications, automatic assignments and provides a foundation for reporting and metrics. The larger and more diverse the organization is, the more important good categorization becomes.
There are some Best Practices and Good Practices to follow when categorizing issues: These include:
- Do NOT over-categorize
- Review categorization frequently and remove unused categorizations
- Use controls when adding categorizations (Review and Approve)
- Avoid the use of “Other” as a category
- Review the usage of Generic “Catch-All” categorizations over time and add new categorizations as required
- Categorization should describe the symptom of what’s wrong, not provide the solution
How to get started structuring your Categories? A good idea is to hold categorization workshops. Set up a comfortable environment with white boards and refreshments and invite a few of your major stakeholders. Avoid inviting too many people to the workshops. Make sure that your selection of users is diverse and represents people across the enterprise.
Make certain to allow enough time for the categorization workshops. If your time frames allow, set aside a few days of dedicated meeting time for the task. Always have a moderator present who is willing to work through any conflicts that arise. Also, it’s an excellent idea to have a scribe present to take notes and detail the work provided in the session.
After development of the categorization structure, allow time to take a test drive using actual tickets and agents. Get their feedback on what works and what doesn’t. At a minimum, they will feel engaged and involved in the project.
Lastly, if you have an existing structure, you will have to provide a bridge to re-categorize old items into the new structure. A good idea is to have a single lookup table with the old categorization fields and the new categorization fields in the same record. That way, the old categorization in a ticket may be looked up and automatically swapped to the new categorization when there is a clear path from the old to the new.
The Categorization Structure within Service Manager is extremely valuable to the overall Service and Incident modules within Service Manager. It is a good idea to avoid, wherever possible, breaking the inherent functionality provided by the tool and to require all pieces of the structure. It may seem painful at first, but the rewards are well worth it.
~Kim Euker, StrataCom