One of the main best practices to focus when implementing the BMC Remedy Service Desk is the correct use of categorization tools. Each element can be categorized in order to obtain the next main advantages:
- Reporting improvement.
- Problem investigation (in the incident review task)
- Easy search.
- Look for solutions of previous similar cases.
In this line, the difference between a correct and wrong categorization is the benefit we can obtain later.
BMC do not provide and extense guideline for designing a correct library of categories. The philosophy is more like to a free interpretation/adaptation of the categories to the user needs. In this post I will review the different categories available in Incident Management, providing a guide to service managers in this controversial topic. This is not the only possible guide. It is my guide. Some other implementations can be as valid (and more) than mine. But if you’re a bit lost about categories it can be helpful.
Understanding categories
- Operational Category
- Product Category
- Resolution Category
- Resolution Product Category
This implies having a four dimensional categorization for each incident. The most easy way to understand the four categories is to think in four answers to four different questions. Using this concept, the Operational Category question can be “What is the operation demanded by the user?”, being the answer to this question the category you must choose for each incident.
The questions related to the four categories are:
- Operational Category: What kind of operation is demanded by the user?
- Product Category: Which is the product related with the problem/request?
- Resolution Category: What kind of operation had to be done by the IT staff?
- Resolution Product Category: What is the actual product related with the operation done by the IT staff?
Let’s think about these questions and its meaning. The Operational Category and the Resolution Category are both very similar. Both questions are related with an operation. The difference between both is that the operational category is related with the user point of view, and the resolution category is related with the operation performed by the IT staff. For instance, Let’s imagine a broken network card. The user can’t connect to the Internet, so he calls the Service Desk, creating an incident. The Operational Category of this incident will be something like “Repair/Network/Connectivity”.
But when the IT staff investigates the incident, they determine that the card must be replaced, so the Resolution Category would be “Replace/Hardware/Component”
The difference between Product Category and Resolution Product Category is very similar to the previous one. The Product Category determines the product the user is talking about. In the previous example, It would be “Network/Internet”. The Resolution Product Category is the product actually related with the resolution category. In the previous example it would be “Hardware/System Component/Network Card”.
Presenting the four categories as answers to the stated questions will make easier to your IT staff to understand its meaning, and provide a correct categorization. Also the user versus IT staff categorization can provide a lot of information to the business intelligence department. It can answer questions like “What is the most common incident for users?”. They don’t care about the root cause. For them it is the same if the network card is broken, the router is down, the VLAN is not properly configured or its user account doesn’t have enough privileges. The incident is the same: “I can’t connect to the Internet”. But also you can answer questions for problem investigation. For IT staff is the same if the user doesn’t have Internet connection, the sales application doesn’t initiate or the user can’t make login. For them the problem is a broken network card. May be it’s time to change the approved model of network card at the DML.
So this dual point of view can be of great value.
An easy way to remember or explain each category dimension is to divide the categorization form like the figure at the start of this chapter. Horizontally, the form is divided in two blocks, being the left side the user point of view and the right side the IT staff point of view. Vertically, the form is also divided in two blocks, being the upper side “What action”, and the lower side “where to action”, or “which product”.
Also there is OOB workflow at the help desk form that is in line with this understanding of categories. For instance, when you select a related CI, the resolution product category is populated. This is because the related CI is not the CI the user is talking about, but the one that holds the root cause of the IT staff action.
Implementation Guide
IT staff can see the categorization as a bureaucratic loose of time. Also it is easy that the use of the categorization is not the same for all support groups, preventing you for crossing the categorization information of both groups. In order to achieve a good implementation I can provide you some best practices:
- The list of categories must avoid the information redundancy. That is avoid defining the product in the operational category and vice versa. For instance: “Install/OS/Windows” is a bad operational category.
- The implementation must include the four categories from the beginning, and implement gradually among the support groups. That is, start with the most collaborative support group, consolidate the list of categories after the experience, and then expand these categories over the rest of support groups. Don’t implement the categories gradually (starting with the product, then the operational, then the resolution, …) because the most common behavior of the IT staff would be to include the information from other categories into the implemented ones. For instance, change the operational category once they realize that the operation is not a repair (what asked the client) to a replace.
- The use of categories must be audited or forced by some social strategy (or by workflow). IT staff initially tends to avoid the categorization. You can establish a KPI about the percentage of incidents correctly categorized and rank your IT staff. Or you can create a workflow rule than warms the user if modified incident is not correctly categorized. Or you can send a notification to the assigned user each week reporting the incidents not categorized.
- IT staff must be aware of the advantages of using categories. Quick wins must be defined to show the advantages. That means early reporting using the categorizations, or implementing a problem quest reviewing incidents procedure based on categories. Anything that can demonstrate the value of categories to the users.
Jose, I enjoyed reading your take on categorizations. There’s some good food for thought here. Good luck with the blog. I look forward to your future postings.
Thanks Bruce. I really appreciate your comment.
Thank you very much, Jose. This was right on the money as to what we needed to explain Remedy’s categorizations to not only our executives, but ourselves as well.
Yes. If you don’t convince your users, they can force you in the future to discard using this tool.
Excellent write up.. I appreciate your effort.. thanks..
Thanks!
Great Post Jose. Good Information, really helpful.
Hello Jose, Could I ask you please to contact me at the email address that I provided above? I have some questions that I’d like to ask you off-line.
Thanks!
What is the meaning of Weight Field while prioritizing the incident?
Wheter this Weight field is automatically populated after Impact & Urgency are setup?
Could you clarify the details
The weight field is just part of the prioritization system. When configuring the priorities, you can give a weight to each urgency and each impact option. Adding both weights you get the overall weight that is used to determine the priority.
The reason to have a weight is only because you would be able to see how the priority was determined. IMHO, it is a system field that must not be shown to users.