In a recent post I covered how the different categorizations for BMC Remedy Service Desk should be interpreted. The operational category is maybe the most important of all.
In this post I will review the most important facts that an operational categorization must accomplish and I will provide a model that fulfills these conditions.
Designing an Operational Categorization
What is the main objective of the Operational Categorization? If we follow the guide I published, the answer is: to describe the type of operation asked by the client. So the main idea is to provide a hierarchical list of the different possible demands of the client. But, it must be organized, using a defined and documented strategy.
This list of possibilities must accomplish:
- The information provided by the operational categorization must avoid entering into the scope of other categorizations, mainly focusing in not invading the product categorization.
- The three layers must have a defined meaning. That is, the first tier meaning must be defined and differentiated from the rest of tiers, and so for the other two tiers. And the meaning of tiers two and three must not vary depending on the value of tier one.
- We must maximize the interchangeability of the tier values. That its, try to not to define a closed hierarchy, but a set of possibilities for each tier that can be related without limitations (any element of tier 1, with any element of tiers 2 and 3)
- One of the best practices is to define one layer as a verb (typically the tier one), and the rest as nouns.
- The operation scope must include service restorations, service requests, events, infrastructure failure or any other thing covered by the Incident Management application.
- For each element, the different types of incidents must be reviewed to see which ones apply.
An Operational Categorization Model
My proposal is to interpret the three tiers as follows:
- Action (verb): Describes the type of action requested. Some examples can include Repair, Install, Update, Query, …
- Scope (noun): Describes the aspect of the related product for which the action is requested. It not verses about the kind of product, but the aspect of this product that is affected by the requested operation. Some examples can be: Access, Hardware, Software, Service, … For instance is the user is asking an upgrade of some software at one computer, the CI (and product categorization) could be the computer, but the action is about updating the software.
- Object (noun): A subdivision of the previous. It can be as abstract as possible to allow to be shared between different scopes. For instance, one object can be Configuration, that can be applied to all scopes (a users ask to update the configuration of the Access rules of a system; or a user reports a incident that needs reparation of the software configuration.
Rule of thumb
Normally the operational categorization must be able to conform a sentence like the next:
What I want is to <Tier 1>, in the scope of <Tier 2>, the <Tier 3> of the/my <Product>.
What I want is to Update, in the scope of Access, the Configuration of the Remedy Change Management.
What I want is to Repair, in the scope of Software, the Functionality of the Sales Management System.
Set of proposed values for tiers
Must be reviewed and adapted to your case!!
Tier 1: Action
Tier 2: Scope
- Service, when the user cannot report the scope and only knows that a service is down for him.
Tier 3: Object
- Version (or release)
Not all combinations are valid. You must check which combinations are valid for you and which type of incident is related to each elected combination.
Best practices applying the operational categorization
Implementing an operational categorization is not as easy as it seems at first sight. Also the importance of it is higher of what at the start up could like. I can provide you a set of recommendations that can help you at the implementation stage:
- Start by defining the structure of the three tiers. That is, to define what will be the meaning of tier one, two and three. Document it and make it clear providing some examples.
- Conform a board of “stakeholders” that must include representatives of all the support groups. The objective of this board will be the definition of the operational categorization list.
- Provide a draft of the list to the board, to be reviewed by all, focusing in what situation is missing and which information is confuse or redundant. Also take care if enough differentiation is present to allow the automatic assignation or flow rules to execute.
- Config the agreed list.
- Set a method (typically a SRD or incident template) to communicate RFC about the operational categorizations. Conform a CAB and maintain it updated and healthy using the change management process.
The resolution categorization can be understood as the action finally performed by the support team. So, it should follow the same strategy as the product categorization, but taking care of the possible differences between them. One must answer the questions: What the user will never request, that my team sometimes do? and What can the user request that my team never do?. For instance, your team will never repair the Internet, but a user can ask you to do it.