Operational Categorization for BMC Remedy

Repairing computer

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

Tiers definition

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, SoftwareService, … 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>.

For instance,

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

  • Repair
  • Install
  • Update
  • Delete
  • Query
  • Check

Tier 2: Scope

  • Access
  • Hardware
  • Software
  • Service, when the user cannot report the scope and only knows that a service is down for him.

Tier 3: Object

  • Application
  • Authentication
  • Availability
  • Cancellation
  • Component
  • Connectivity
  • Credentials
  • Data
  • Functionality
  • Log
  • Password
  • Patch
  • Performance
  • Peripheral
  • System
  • 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.

Resolution Categorization

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.

Posted on by Jose Huerta in Best practices, Featured

About Jose Huerta

Jose is a project manager and service manager from Mallorca (Spain). The last years, he has been closely related to Remedy at almost all levels: deployment, customization, consulting, administration and service management. His work doesn't end with BMC products, but he's continually exploring other aspects of IT management, as the leader of development projects and IT services.

3 Responses to Operational Categorization for BMC Remedy

  1. Alain Rivet

    Good morning everyone,

    Does anyone has insights on how we should approach operational catégories linked to tasks? We’ve been using Jose’s approach to develop our list:

    What I want is to , in the scope of , the of the/my .

    The draft of our 1st tier goes as follow

    •Install/Add
    •Replace/Modify
    •Update
    •Move
    •Delete
    •Inform

    We were focusing on operations that could be performed through tickets (change, incidents, problems, requests) but we then realized that tasks could also be categorized and we started considering adding some actions in the first tier to reflect some of the operations that could be performed through tasks. Actions like

    •Check
    •Authorize

    Any advices on how we should address this from a functional standpoint? I know we can create categories that would only be visible for tasks but what I would like to know is if tasks categories are worth the effort (for creating and maintaining them and enforce their use throughout the organization) down the road or if we should concentrate on tickets categories alone.

    I understand my question is very specific on the context under which the ITSM implementation takes place so there’s probably no universal answer to it. I was hoping this crowd would have good insights and best practices for using op. categorization with tasks.

    Thanks!

    Alain Rivet

    • Jose Huerta

      I’m glad that you use my approach.

      First, in a recent Remedy deployment we used the Check/Verify category for operational categorization. This was the default category for events created automatically from an external system (and placed at the Help Desk form). For instance, 50 % of the time over 90 % of CPU at a server is an event created and need a support group to check it.

      Second, the uses of categorizations are: business logic and reporting.

      Business logic examples: SLA’s that apply depending on categorization (you can have some SVT related to tasks), auto assignment, etc.
      Reporting examples: Mean time of task execution (grouped by category)

      If those uses don’t worth the effort of categorizing, then forget about it.

  2. Juanjo

    Muy bueno el articulo, otra cosa es como defender en cliente esta propuesta que particularmente a mi siempre me ha parecido la mejor.

Add a Comment