In a recent post I covered how the different categorizations for BMC Remedy Service Desk should be interpreted. Also I’ve reviewed the operational categorization. The other side of categorization is the product categorization.
In this post I will review the most important facts that a product categorization must accomplish and I will provide a model that fulfills these conditions.
Designing a Product Categorization
What is the main objective of the Product Categorization? If we follow the guide I published, the answer is: to describe the type of product related with the clients incident/request. So the main idea is to provide a hierarchical list of the different possible product types. But, it must be organized, using a defined and documented strategy.
This list of possibilities must accomplish:
- The information provided by the product categorization must avoid entering into the scope of other categorizations. That is, just talk about the product.
- The three tiers must conform an organized division of your products in gendres, families, or any subdivision you want.
- Don’t include the product name, version or manufacturer name in the product category. Even when you will have one product for this category, create a category that is not the name. For instance, don’t create a category Software/OS/Windows, and another Software/OS/Linux.
- Don’t forget including any type of product that an incident, problem or change can be related to. For instance, if you control the versions of main documents using the change management application, you must have a category (or categories) for documents.
- Don’t include redundancy. It must be clear which product category a CI is related to. Avoid to have categories that can describe the same CI (like network/equipment, and hardware/router). Also avoid a container strategy that implies redundancy like (Equipment/Laptop/Memory and Equipment/Server/Memory).
A Product Categorization Model
My proposal is to interpret the three tiers as follows:
- Scope: Describe the kind of product, like software, hardware, document, location, etc.
- Family: Divides the scope in bigger groups. You can have only one family for one scope. In that case, duplicate the name of the scope as the Family. For instance, the document scope can be divided only in one family: the document family. The idea is not to define a type of product, but a family of types. For instance, don’t create a family for keyboards, but a family for peripherals.
- Type: Defines a type of product. You can be as concrete as you want but without indicating the product name, manufacturer o technical characteristics. The level of precision must depend on your needs. For instance, some organizations will have a PC to define a desktop PC, laptop or any personal comuter. But other would need a higher level of detail with high-end workstation, workstation, desktop, laptop, notebook, … Rule of thumb: try to minimize the level of detail (to minimize the number of categories) to the minimum required by your needs. To go beyond normally only increases time and cost.
Must be reviewed and adapted to your case!!
Tier 1: Scope
Tier 2: Families for Hardware
- Process Equipment
Tier 3: Types for Hardware/Process Equipment
- Desktop PC
A product category is very dependent to the organization. The product categorization of a not IT company, will have a lot of personal equipment. An IT services company will focus in organizing the server farms and CPD parts. So there is no unique perfect product categorization.
Best practices applying the product categorization
To implement a product categorization is much easier that the operational. Your IT staff will probably understand the meaning of each category just taking a look at the list.
You must integrate the categorization with your CMDB. Trying to implement the product categorization without switching on the CMDB is by far more complex that with a CMDB. The reason, because when selecting a related CI in the forms, product categorizations can be populated automatically. This will make much more easy to teach to your team. Also you can be sure that your product categorizations is complete, since all your CI are related to one. Is not possible to find a prodcut without any valid categorization.
Product Categorization and Resolution Product Categorization
As stated in the categorization guide I published, the product categorization verse about the product commented by the user, and the resolution product categorization verses about the actual CI that is related. BMC has designed workflow that works in this like. When you select a service CI in the incident ticket form (HPD:Help Desk), the product category is populated. When you select a CI, the resolution product category is populated. I think that this workflow is not enough.Yes, there are a lot of cases when the user talks about its service, but sometimes the user goes beyond the service. For instance. The user can report an incident about an Internet Failure. The Service CI can be “Communications”. But the user is not talking about the WIFI or the VPN services, is talking about the internet. So I think that this workflow is useless in most of the cases.
So I recommend to teach your service desk staff to provide the product category, and let the related CI (populated by the support staff) to set the resolution product category.