The Information Technology Infrastructure Library (ITIL) is fast becoming the worldwide, de facto standard for IT service management. ITIL can be defined as a set of best practices for managing the processes required to effectively managing the delivery of IT services and support. Each of the processes defined in ITIL are designed to drive a specific IT business function or discipline.
Understanding the differences between–and the relationships among–these processes is an important first step in implementing ITIL. This Research Byte provides an explanation of three ITIL processes that are often confused.
The Structure of ITIL
ITIL is divided into three major areas: Service Support, Service Delivery, and Security Management. Within the Service Support category, ITIL includes the following key disciplines:
- Service Desk
- Incident Management
- Problem Management
- Change Management
- Release Management
- Configuration Management
While these terms are undoubtedly familiar to many IT personnel, the formalization that ITIL brings to these disciplines is typically far beyond the level of sophistication in the majority of IT organizations. Additionally, the distinctions and separation of tasks within each of the support disciplines are also significantly more defined than most IT organizations have implemented in the past.
For instance, the majority of IT shops have not traditionally drawn a distinction between Incident Management and Problem Management, or between instances of incidents and problems. ITIL, on the other hand, clearly defines these as separate disciplines with their own unique set of processes. IT support personnel can be quite confused by ITIL’s specific use of the terms incident and problem if they have been using these terms interchangeably, or if they think that an incident becomes a problem when it can’t be solved by Level 1 support.
Unfortunately, educating support personnel on these complex relationships is sometimes glossed over, to the detriment of the support process. This article provides a discussion of the often complex relationships between Incident Management, Problem Management, and Change Management and instances of incidents, problems, and changes.
A Review of the Disciplines
First, a bit of ITIL review about the objectives of Incident and Problem Management. The objective of Incident Management is to restore service as quickly as possible. Therefore, an incident is active until service is verified as restored. The objective of Problem Management is to minimize the economic impact of service disruption by diagnosing the root causes of incidents, gathering information on known errors and by providing work-arounds, temporary fixes, and permanent fixes.
Therefore, while an incident is active only until service is restored, a problem continues to be active until appropriate outputs (e.g. work-arounds, permanent fixes) are published and implemented. This means that incidents and problems are not synonymous. Neither do incidents become problems. Rather incidents, problems, and changes each have a many-to-many relationship with the other two.
An Example of the Relationships
Let’s look at one example of the relationships of an incident, a problem, and a change over time. This timeline is shown in Figure 1.
The sequence of events as shown in Figure 1 is as follows:
-
At TIME = 0, an External Event is detected by the Incident Management process. This could be as simple as a customer calling to say that service is unavailable or it could be an automated alert from a system monitoring device.
The incident owner logs and classifies this as incident i2. Then, the incident owner tries to match i2 to known errors, work-arounds, or temporary fixes, but cannot find a match in the database.
-
At TIME = 1, the incident owner dispatches a problem request to the Problem Management process anticipating a work-around, temporary fix, or other assistance. In doing so, the incident owner has prompted the creation of Problem p2.
-
At TIME = 2, the problem owner of p2 returns the expected temporary fix to the incident owner of i2. Note that both i2 and p2 are active and exist simultaneously. The incident owner for i2 applies the temporary fix.
- In this case, the work-around requires a change request. So, at Time = 3, the incident owner for i2 initiates change request, c2.
-
The change request c2 is applied successfully, and at TIME = 4, c2 is closed. Note that for a while i2, p2 and c2 all exist simultaneously.
- Because c2 was successful, the incident owner for i2 can now confirm that the incident is resolved. At TIME = 5, i2 is closed. However, p2 remains active while the problem owner searches for a permanent fix. The problem owner for p2 would be responsible for implementing the permanent fix and initiating any necessary change requests.
This is just one example of the relationships between these disciplines. In reality, there are many other possible examples of the way that Incident Management, Problem Management and Change Management are interrelated.
Process Relationships Can be Complex
It is also important to note that not all problem requests are created because of an incident. Some problem requests are initiated by proactive problem control discovering a likely cause of future incidents. In this case, an instance of a problem may have no related instance of an incident. The problem may initiate a change request to implement a permanent fix. In this case, the problem will be linked to an instance of change.
In another case, the incident control activity of the Problem Management process may discover that multiple incidents have the same root cause and link all these incidents to a single instance of a problem.
Another incident may implement a temporary-fix created previously by the problem control activity of Problem Management. In this case, the incident will have a relationship with the earlier problem that created the temporary-fix without ever initiating a new problem request.
As can be seen, these relationships can become quite intricate. As mentioned earlier, confusion about the relationships between incidents, problems, and changes can sometimes be glossed over during the training phase, which will often slow the adoption of ITIL concepts and ITIL-centric support systems. Support personnel do not have to know every possible permutation of these relationships, but, they should understand that incidents, problems, and changes are not synonymous and can have quite complex interactions.
Commentary by Robert Boyd, a Contributing Research Analyst for Computer Economics. Mr. Boyd is an ITIL consultant with 15 years of experience supporting some of the world’s largest data centers.
ITIL is one of over 35 IT management best practices tracked by Computer Economics in our annual study. For more information, see our report IT Management Best Practices and download the free summary.
