ITIL: Introduction to Incident Management

When something does not go as expected, we call it an issue or a problem.

To illustrate with an example, let’s imagine your broadband internet connection which you have subscribed through an ISP fails to connect to the network. You call their customer care and report the loss of your internet connection.

In this example, your internet connection is a service which you are subscribing to, and the disruption that you face is termed as an incident under Information Technology Infrastructure Library (ITIL).

The art of managing incidents to quick successful recovery is Incident Management.

Incidents in ITIL

Any disruption to the service availed will go down as an incident in ITIL. It may include any service you are leveraging from your service provider like telephony, cable TV, internet and so on. You get the idea right?

Official ITIL definition for an incident goes like this:

“Any event which is not part of the standard operation of a service and which causes, or may cause, an interruption to, or a reduction in, the quality of that service.”

Objective of Incident Management

You are bound to have incidents, and there are always technicians to resolve it. But life in not that easy.

You are not the only customer and the technician is not dedicated to you, waiting for your call to report an incident. In reality, there are thousands of customers if not more and just a handful of technicians who are responsible for recovery of service.

Incidents get reported through various mediums such as emails, telephone, text messages, and walk-ins amongst others. Any service provider who has thousands of customers can expect at least a thousand incidents reported in a day, and as I mentioned earlier, the technician strength will not be an equal match to the reported incidents.

How does one manage this challenge? How can a service provider keep customers happy if incidents are reported in heaps and a handful of engineers are present to man the system?

The answer is incident management. It is an art of managing incidents and a field I specialize in.

The goal of incident management is to ensure that the interrupted service comes back up as soon as possible, nothing more nothing less. The official definition as listed on ITIL is as follows:

“Restore a normal service operation as quickly as possible and to minimize the impact on business operations.”

The definition pretty much sums it up; the service needs to be restored as quickly as possible, and how you do it is the strategy that will either lift you higher in the market or sink you deeper.

Prioritizing Incidents

Ten customers call the customer care and report ten incidents simultaneously, which are not connected to each other. There is one engineer who works on incidents at this point in time. Which of the ten incidents does he choose to work on first? First come first serve basis does not gel well here, nor picking numbers randomly.

The organization must therefore have a process of ranking incidents and in ITIL we call it prioritizing incidents.

A priority is derived by simple addition of urgency and impact. Urgency is how critical the incident is to the customer, and the impact refers to the extent of disruption. Generally, impact is associated with a monetary value.

Priority = Urgency + Impact

Let’s say there is an individual who reports an incident stating that his internet connection is slow. We will call this Incident A. At the same instant, another call lands in the call center from a business stating that their internet connection is down for the entire office, around 150 users are affected; we’ll mark this Incident B.

We need to rank these incidents to ensure that the one ranking higher is picked up first. Comparing the two incidents, the impact is higher in Incident B and so is the urgency. Incident A will rank lower as the outage is not total with performance degradation, and the timeline to resolve the incident doesn’t look too pressing. Incident B will be prioritized over Incident A and the engineer will look at higher priority incidents first and move down the list.

This kind of prioritizing will be done for all the incidents that land into the call center’s bin, and this clearly ensures that severe incidents are dealt aptly in a timely fashion.

Simple Incident Management Model

Let me explain this simple model through an illustration.

A hardware manufacturer’s customer care gets a call from a business stating that the server that is hosting small business server is showing high CPU utilization.

As per the model suggested by me in the image above, there are two functional groups which will be employed, service desk and the technician group.

The service desk is the first point of contact for customers. The reported incident is recorded on their database and classified – assigning a priority and ensuring all the obtained details are accurate. This incident is then routed to the technician group. In many cases, service desk would have basic knowledge of troubleshooting and act as the first level of support.

The technician group picks up the incident and performs the investigation and diagnosis, in which they assess the incident details, gather and analyze details and suggest a resolution. The suggested resolution is implemented to resolve the incident, either by fixing the plug permanently or providing a temporary workaround. It does not matter what the solution is, as long as it fixes the disruption.

The technician group sends the incident back to the service desk with the update that the incident has been taken care of. The service desk takes a confirmation from the customer before bringing a logical end to the incident. If the incident is still unresolved, the incident is re-routed to the technician for a review and the process loops around as long as the incident is open.

There are a number of ways to achieve incident management, and the one illustrated above is perhaps the simplest of the lot.

What is a Service Request?

While you are trying to digest the concepts of incident management, I want to introduce a new concept that goes hand in glove with incidents – service requests. A service request is not a disruption to the existing service, instead, it adds on or enhances the existing service functionalities.

An example could be getting access to a web portal. You would raise a service request instead of an incident to get the required level of access. It is not an incident as you did not have access to the portal earlier, and your request is an add-on to what you already have.

Many organizations, especially those who claim to follow ITIL framework, don’t differentiate between incidents and service requests and handle everything under the banner incidents. I find this practice disgusting as the two are situated on two different poles, and most definitely have different objectives.

Effective Incident Management Increases Revenue

Think about it. Customers report incidents as there is a disruption to the service they are receiving, and you may rightly guess that they are not very happy about it. If the service provider organization has implemented effective incident management process, it will lead to restoration of service at the earliest.

This will make the customer happy, although initially he/she was unhappy over not being able to avail a service they are paying for. Restoring the service quickly ensures customer satisfaction, and there are plenty of positive implications with a happy customer. Word of mouth gets around quicker than lightning, and will lead to expansion in business. The last thing any company wants, is to lose customers owing to bad customer service – read resolution of incidents.

More Related Posts

1. Introduction to MPLS: Multiprotocol Label Switching for Cisco Professionals
2. Longhorn's Server Manager will Change Server Management
3. Words for Training Contest — 3rd Place Winning Essay
4. Faster Windows File Management with Free Xplorer2 Lite
5. How to Obtain Your Project Management Professional (PMP) Certification