ITIL® V2 had 10 processes, but the current one, ITIL® V3 has almost tripled the count to 26. One process that stands out and is perhaps the most popular of them all is the incident management process. There is a common problem in organizations practicing incident management – the scope and activities surrounding incident management is perhaps not fully understood. It is clubbed with another process which deals with the other side of the coin: request fulfillment management process.
In this article, I will discuss the problem on hand, and offer tips on how it can be implemented, if there is a need to combine them together.
The Problem
Clubbing one process with another is not the issue, but sacrificing the goals of one for the other is a concern.
Let’s say that a doctor has two patients coming in. One is worried about a scar on his thigh and the other is oozing blood from his nostrils. Who do you think the doctor should tend to first? Well, the gravity of conflict of interest we face in ITIL® implementation is similar to what the doctor is faced with. The choice to be made is simple on the outset, but in the thick of action, things could go awry. The solution will look something like this: Understand the impact, and prioritize activities.
I will explain the basics of both the processes and then take you through how things should be dealt with if they are to be implemented as one process. I have jointly implemented them as a single process, yet they are discrete in their own ways.
Basics of Incident and Request Fulfillment Process
Incident management is a quick remedy. Your car is broken down and you need to get home. Fixing your car takes time, so you catch a cab back home. The end result of getting home is achieved, so the means do not really matter. We will deal with the actual solution in a different process altogether – problem management.
Incident is a disruption to a service. An example could be your cell phone being out of range. Incident management deals with resolving the issue, meaning bringing the service back as quickly as possible. Whether you are asked to move into range, or replacing your cell phone with a powerful one with a better signal, is just another example of how means do not matter. The end result must be achieved - you should be able to get a signal on your cell phone.
In incident management, time is of the essence. The quicker the resolution, the higher the success rate. So, when defining incident management, we set the key performance indicators mostly around the timing.
Request fulfillment deals with service requests. A service request is an add-on to what you already have. Going with the same cell phone example, let’s say you want to access 3G on your cell phone, and you send an email requesting it to be activated. This is a service request. You are requesting for something you don’t already have, and it is considered an add-on. The ability to talk on a cell phone is the primary feature and everything additional like 3G, text messages and voice mail are enhancements.
When dealing with enhancements, time is generally not of the essence. One can still argue that time can still mean something; the quicker it is fulfilled, the more money will be made. But 99 out of 100 times, this is not the case.
So, a service request like 3G must be fulfilled in a timely manner, but does not necessarily require scrambling frantically to complete. There will not be a temporary way of getting it done quickly, to then look at permanently enabling it. Service requests are straight forward. What needs to be done for every service request will be documented, and more often than not, it will be a push of a button.
Implementation Gone Wrong
I have seen some badly implemented combined versions of incident and request fulfillment management processes. In ITIL® V2, both were conjoined as a single process, but were clearly segregated in terms of definition and goals. In ITIL® V3, they have taken out the ambiguity that might have existed by defining two separate processes.
When you combine the processes but fail to define the scope and draw a clear boundary, along with service level agreements (SLAs), key performance indicators (KPIs) and critical success factors (CSFs), engineers will end up giving you 3G access before they sort out the cell phone signal issues.
Contracts these days carry penalties for missed incident resolution SLAs. So, it is imperative that process architects look at carving out incidents out of the hay stack, and dealing with them before anything else.
Clubbing the Processes
SLAs are generally different for incidents and service requests. While incidents are in hours, service requests could stretch out to days and weeks. If you find a SLA which is the same for both, it is a case of proposal and bidding gone wrong. These two are never even.
Today, companies talk about cut backs and cost savings mostly. A logical way of achieving it is to merge the incident and request fulfillment management processes. In fact, it is one of the easier mergers that can be achieved from the list of 26. I will opt for it as well.
How you implement ITIL® depends on a number of factors, like organization structure, maturity, contract, technology and the capability of support teams. Considering all these factors, incident and request fulfillment management processes can be implemented in a number of ways.
If you are to combine it, for starters, service requests must have different priorities than that of incidents. If incidents have priorities like P1, P2 and P3, then service requests can be P4 and P5, or you can create a new structure with SR1, SR2 and SR3. The idea is to differentiate incidents from service requests if the same set of people are handling it.
Prioritize incidents over service requests – meaning handle incidents before you handle service requests. This must be documented and made known to everyone who works on both. With the flow of things, and with the eagerness to reduce the ticket count, I have seen engineers handling the easier ones (service requests) before the troubled ones (incidents).
Another structure that I have implemented is organizing a logical team for fulfilling service requests alone. The team changes on a rotating basis. This way, the same personnel do not end up with service requests and the rest with incidents. It could lead to a decrease in motivation and dissatisfaction in teams, while rotating the teams will break the monotony.
If you prefer dedicated teams, it can work very well as well. It may not be an approach to fully utilize people resources. I would opt for this when the service request count matches incident count or exceeds it.
Sign up for a free 3-day trial to get access to TrainSignal’s entire training library, including accredited prep for ITIL® v3 Foundations.
ITIL® is a Registered Trade Mark of the Cabinet Office.
Discussion