You have your major incidents, and you have your critical incidents. So, what’s the real difference between them?
The problem is that major and critical can get a little fuzzy. Depending on the organization the terms “major” and “critical” can mean the same thing, or cover entirely different ground. A definition needs to be given and communicated to the organization formally in documents, such as policy, procedures, work instructions, etc. You really want to avoid allowing the users to make up their own definitions — that will lead to a whole new layer of confusion. As long as the definitions are made clear then you should be in the green.
ITIL Incidents and Their Definitions
To define these terms, we should first understand the difference between an internal customer and an external customer. An internal customer is someone using the system from within the organization, essentially an employee. Meanwhile, an external customer is someone who is paying for the product or services — what you’d typically think of when told to define a “customer”.
Next is agreeing on what is critical or major or any other status that is used to influence behavior (i.e. procedures, work instructions, etc) for the particular incident situation. These terms will also influence responses included in service level agreements (SLA) for service support.
Priority = Impact + Urgency
Within the service desk tool, impact can be listed as low, medium, high, major, and/or critical. Urgency can have the same listings. A major or critical incident that won’t break the business right away — something that can be dealt with over time using IT Service Community Management (ITSCM) plans and business priorities — can simply be assigned low priority. An organization may choose to not use priority capabilities, but have a checkbox within the service desk tool to indicate if an incident is major or critical. Another decision point for major or critical incidents can be decided before the prioritization, and during detect and identification based on input from a requestor. For example, the service desk manager could tell the staff: “If you receive a call from X, please treat the incoming call as a major or critical incident and follow the appropriate procedures immediately.”
Incident Management Process
So, what are we saying after all of that? Basically determining if an incident is critical or major is up to you and how you define it within your organization. Here are the key aspects of managing different kinds of incidents:
- Formally define and distinguish the different incident types
- Maintain clear, differentiated procedures, work instructions, and responses for major/critical incidents
- Understand incident management needs as it relates to other integrations
- Understand ITSCM plans related to major or critical incidents
When it comes down to it though, you should decide what is best for the organization and its customers. Enabling coordination and collaborative efforts for managing your major and/or critical incidents is the main goal. As the organization moves to maturing and becoming more service oriented, the better the incident management process is, the easier it will be to support the organization’s strategic intent and priorities.
About Anthony Orr
With more than thirty years working in various IT strategy, managerial, consulting, executive advisory, marketing, and technical positions. Anthony is author of the ITIL v3 2011 publications and the ITIL MALC exam book, as well as a Sr. Examiner for the ITIL v2, v3 and Cyber-Resilience certification examinations. He has published numerous podcasts, videos, booklets, white papers and articles, including a white paper, Synergies between ITIL and DevOps, with AXELOS. Anthony has traveled to over 50 countries and lectured at universities around the world.
Read more articles by Anthony