Branimir Valentic I am sure that you have heard users of an IT service say that they have problems, errors, malfunctioning or something similar when there is degradation in the service. Based on ITIL methodology, they are having Incident(s). ITIL defines an Incident as “unplanned interruption to an IT service or reduction in the quality of an IT service or a failure of a CI (Configuration Item) that has not yet impacted an IT service.” We define normal operating state of a Service through SLA parameters, service description and operational parameters. If they are not achieved – an Incident has occurred.
Importance of Incident Management
Why are Incidents and the Incident Management process so important? Because Incidents are a user’s introduction to a support organization. When an Incident occurs, users need support from their service provider, and the Incident Management process starts.
If we consider the complete lifecycle of an IT service, Service Operation (where Incident Management is defined) is part of the service lifecycle, for most of the services that last longest. This means that the support organization is around for a long time when needed by their users. That’s one of the reasons why an efficient Incident Management process is important. Another reason is that users typically don’t see Problem Management or Change Management (or, at least, the bulk of the change process). They are also very important, but not right in front of users like Incident Management.
Island with many bridges
Incident Management is not an “isolated island” in IT Service Management. It influences, or is influenced by, many other processes in IT Service Management. Incident Management’s task is to restore normal service operation as quickly as possible. This will quite often include implementation of various workarounds – just to enable service operation as quickly as possible. But, that doesn’t mean that we know what really caused an Incident. That is the aim of Problem Management. When Problem Management defines the root cause of one or more Incidents, it could start Change Management. Since change includes equipment or CIs (Configuration Items) in most of the cases, for efficient Change Management it is advisable to have Service Asset and Configuration Management in place. On the other side, an Incident could be started by an Event, which is handled by Event Management.
Handling
Besides Event Management and monitoring tools, an Incident could be started in several ways:
- By users – usually via Service Desk or self-service portal
- By suppliers or vendors
- By technical staff (inside the support organization)
It’s important that the lifecycle of all Incidents are managed by the Incident Management process. Efficient support organizations use tools to manage Incidents. Tools provide many functions, but from experience, there are a few elements that are important for Incident handling:
Self-service portal – web-based interface that users use to open, escalate or control status of Incidents they open. The portal is an integral part of the IT Service Management tool. It should be simple to use and it should not require too much information from the user (requestor/user data, subject, description, category/topic and priority).
Incident category (or Incident topic) – information that relates to the Incident catalogue, used to categorize the Incident and (optionally) direct the Incident ticket to a specific support group. Incident ticket routing based on category can speed up resolution of an Incident, but I saw some examples where an Incident was routed to a group which contained only one person. If that person is absent, the Incident will not be resolved. The category is defined in the Incident catalogue.
Priority – correct prioritization is important due to the obligations defined in the SLA. That directly impacts the order in which Incidents will be handled. For example, if two Incidents are not assigned to a support person, the Incident that requires less time to resolve must be handled first. To learn more about setting priorities, read this article: All About Incident Classification.
Service Desk – one of the functions according to ITIL. It’s a single point of contact for users and, if not opened via self-service portal, the starting point of an Incident. Incident Management and Service Desk are tied together. If a user contacts the Service Desk, it is important that the Service Desk gathers as much information as possible about the Incident. This will contribute to the quality and time effectiveness of the Incident resolution.
Support groups – it is common situation that Incident Management has several support levels. There are many reasons for that, I will mention just few. Sometimes there are many services in use. Or they are specific and it is hard to have knowledge about every single service or services that are customer specific (e.g. custom implementation of networking technology). Therefore, more expert knowledge is needed to solve Incidents. So organizations have 2nd or 3rd level support. Or they include vendors in their Incident (or Problem) Management process. This is functional escalation. It is important to have governance on Incidents so they don’t get lost in re-routing between support groups.
Figure: Example of Functional and Hierarchical escalation of Incidents
Value creator
When implementing IT Service Management (based on ITIL) Incident Management is usually first (or one of the first) processes to implement. With or without tool implementation, quality of abovementioned elements is equally important. If not implemented, either clear communication and reachability of the support organization will fail (missing self-service portal or service desk), or the Incident process will be incomplete (lack of technical expertise needed to solve complicated incidents if there are no support teams in functional escalation, or difficulties in compliance with SLA if priorities and categories are not defined and matched).
Efficient Incident Management is the foundation of a support organization. It highly influences users’ perception of the IT support organization, and serves as a starting point for other processes inside the IT support organization like Change Management or Problem Management. With poorly implemented Incident Management, other processes will lack the data needed to provide results. Therefore, value created by the Incident Management process will be seen both externally by customers, and internally by other processes and functions in IT Service Management. Incident Management should be the rock on which IT Service Management processes and organizations are built.
Download a free sample of our Incident Management process template to gain more knowledge regarding incident management.
