Do you know how to build a good incident management flow? If you started working with this process from ITIL 4, perhaps your flow could benefit from ITIL v3. Today, you will discover how to create an effective ITIL incident flow.
This is because the incident management flow in ITIL 4 is a simplified version of the flow in ITIL v3. This is a recurring characteristic in every update of the latest version, bringing greater flexibility and also simplification of processes.
However, the extreme simplification of the process also has its downside: the insufficiency to assemble a complete and useful incident management flow.
To solve this deficiency, today we will go back to ITIL v3, diagnose this difference, and understand what we can take advantage of in a more detailed flow, without letting it become prescriptive.
The flow in ITIL 4:
In ITIL 4, the flow is simple and only contains these 6 steps. However, the following questions remain unanswered:
What if it’s a service request?
In other words, at what point can we detect if we are actually dealing with a service request, instead of an incident?
To answer this question, it is important to understand that ITIL 4 is not prescriptive. Many things, including incident prioritization, are not even mandatory steps. In the case of prioritization, for example, it is only necessary to do it when the organization does not have enough resources to attend to the entire incident queue. If there is no shortage of resources, there is no need for prioritization.
What if our incident is a Major Incident?
This step is present in ITIL v3 but not in ITIL 4.
Where is the initial treatment by the Service Desk?
This step is also only present in ITIL v3. In the process, only the diagnostic step is described, but by whom will it be done? By the Service Desk or by first, second, or third level specialists? This opens up several questions about the flow.
Is categorization synonymous with classification?
In ITIL v3, categorization is a step described with the function of sending the incident to be treated by the specialized team for this purpose. When this is not done, it can happen that one team throws the incident to another, hindering the process and resolution.
In ITIL 4, this remains open.
And the multilevel categorization?
This occurs when there is a recategorization of a call between the opening and closing of an incident, a situation that can occur in certain contexts.
Where and how do we prioritize incidents?
When there is a need for prioritization, as happens in most organizations, at what points in this flow will this step be taken? And how? This is also only described in ITIL v3.
When do we escalate the incident?
When it was not possible to resolve in time and we need to escalate the incident, at what point should this be done? This step, also essential for the flow, is only described in ITIL v3.
How to evaluate the Incident after its conclusion
In ITIL 4, this process is described, but not with the same detail as in ITIL v3, from which we can benefit not by following it rigidly, but by analyzing our own processes with a more complete understanding of the possibilities.
And lastly, a question that ITIL 4 answers but not ITIL v3, demonstrating the complementary nature of both: what if the incident is generated by an event?
That is, how should we proceed when the incident is opened by event management, and not by a user’s call?
In this way, we will see that, from observing the flow of ITIL v3, many of the steps that answer these questions are included.
Incident Flow in ITIL v3
In comparison, the ITIL v3 flow is much more robust and contains several other steps. The main point is that this flow is not prescriptive; it should be seen as a much more robust sequence of steps that brings useful tools for analyzing our own process, adopting what is useful and discarding what is not.
In summary, in ITIL v3, the steps are as follows:
1. Incident Identification
First, we will establish the incident that we will deal with.
2. Incident Logging
Logging is essential for organizing, consulting, and analyzing incidents.
3. Incident Categorization
Categorization serves to establish which team the incident should be sent to, according to its characteristics.
4. Incident Prioritization
Prioritization depends on the impact that the incident can cause.
5. Initial Diagnosis
If the service desk can make the initial diagnosis and solve the problem, great.
6. Incident Escalation
However, if the previous step is not possible, the incident must be escalated to a more specialized team or to higher management levels.
7. Investigation and Diagnosis
Here, there is a more in-depth diagnosis through a more detailed investigation of the incident.
8. Resolution and Recovery
Then, the incident is resolved, and recovery occurs.
9. Incident Closure
The incident is finally closed.
Expanding the Incident Lifecycle Through Availability Management
The availability management practice can be used to observe the expansion of the incident lifecycle, with new phases that may be useful for our process:
For example, observe the Repair, Recover, and Restore stages, in addition to our standard incident flow, in both ITIL 4 and ITIL v3.
This serves to show how the incident management process can be expanded and analyzed in its lifecycle beyond what is established in ITIL v3 and, undoubtedly, far beyond ITIL 4.
Conclusion
As we have seen, there is an immense difference in detail between the incident management flow of ITIL 4 and the flow of ITIL v3. Much of this is due to the fact that ITIL 4 seeks a much less rigid, prescriptive approach, aiming for greater flexibility in its practices to adapt to the flexibility of organizations in the current world.
However, this does not mean that a more detailed approach is necessarily bad. ITIL v3 presents us with a larger number of steps for the incident flow, but we should not discard it or simply take it as a recipe to be followed strictly.
Instead, a more detailed understanding of the possibilities of a robust incident flow serves our organization as a guide so that we can adopt what is appropriate and discard what will not be useful, or what can rigidify the process.
Therefore, always seek all possible tools, all knowledge, and possibilities for your process are welcome. What must be kept in mind is critical thinking to decide what can be taken advantage of and modified for each individual context.
English 
