- Major Studies
- Market Assessments
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:
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:
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.
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.