News

Better Incident Management Categorisation Model

Through our many years of implementing BMC Remedy ITSM we have worked with many customers who have struggled to define categorisation data that brings value to their service management processes.

Why is it so important to define good categorisation data?

  • They provide classification for reporting and trend analysis – for example without good incident categorisation you’d never know how many Operating System versus Application issues your organisation experienced and what actions are needed to reduce them from both Incident and Problem Management perspective.
  • Enhanced matching of records within Incident Management and other sources (Problems, Changes, Knowledge Base) for quicker solutions and diagnosis
  • Effective Assignment and approval rules – for example to auto assign the Unix related tickets to the right team for increased productivity and enhanced customer satisfaction

BMC Remedy Incident Management provides excellent granularity of the 4 categorisation sets in Incident Management.

Fusion are asked by many customers on how to structure their foundation data, how to define a consistent model and differentiate the 4 different types of Incidents categorisations:

  • Initial Operational Categorisations
  • Initial Product Categorisations
  • Resolution Operational Categorisations
  • Resolution Product Categorisations

The most frequent questions which we are dealing with are:

  • What should be recorded – the symptom (reporting issue) or the CI causing it (hardware issue)?
  • But how do you know what is the root cause actually is at incident submission time?
  • Every company has their own culture for categorising, so is there a cure-all data model?
  • Is there an easy way to understand the differences between the 4 categorisations types and apply a consistent data model which to be understood by everyone?

Yes, there is! Let’s give you an analogy which drives a model for the questions above!
Let’s imagine what would happen with the Incidents if they are treated in a hospital (they are different too, but follow pretty much the same way):

  1. The patient (our customer) experiences an incident and goes to (or calls) the clinic (the service desk).
  2. Customer then provides symptoms (issue) and the doctor (engineer) records them in the Initial Operational Categories – e.g. Failure / Connectivity / No Outgoing.
  3. The patient (customer) does not know which exact part of the body is causing the pain so shows a wide area (Service related) which is recorded in the Initial Product Categorisations – e.g. Software / Application / Reporting
  4. The doctor diagnoses the exact part of the body (noun) which is causing the pain and documents it using the Resolution Product categories – e.g. Hardware / Component / RAM
  5. The doctor applies a treatment as Resolution Operational Categorisation where Tier 1 is the action (verb) done – e.g. Modify / Hardware / Upgrade

This is how easy it is to define the various Incident Types and Incident Use cases into just 4 sets of categorisation – in a descriptive, consistent and driving the future continuous service improvement way which connects the user symptoms and their resolution from our teams.

Interested in learning more about the real-life use cases or the BMC products involved in making this happen? Or see how can Fusion help transform the way you approach categorisation data in your Service Management toolset? Contact Fusion Business Solutions

Boris Lozanov
Senior Consultant

By Daniel Swann