ITIL Incident Management is an important concept in the lifecycle for IT service management (ITSM). This article will walk through an example and includes a sample incident to get you started.
Put On Your Riot Gear
Incident management is a core component of the ITIL (Information Technology Infrastructure Library) lifecycle for IT. Incident management deals primarily with your first line helpdesk – and is affectionately known as “fighting fires" in IT circles. ITIL incident management really deals with restoring a service as quickly and efficiently as possible.
When constructing an ITIL incident management diagram, you’ll learn that there is a defined process for following the life of an incident from initial report to closure. The main process steps are:
- Incident Identification and Logging
- Classification and Prioritization
- Investigation and Diagnosis
- Resolution and Recovery
- Incident Closure
I like to break the incident lifecycle into three phases – pre-action, action and post-action. Pre-action focuses on identifying the incident and performing administrative tasks. The “action" phase deals with actually solving the incident. Post-action deals with closure of the incident and wrapping things up.
Although you may not consciously go through each step for every incident, if you look close enough, you’ll find that you do go through them no matter the effort you put into resolving an incident.
This phase deals with four ITIL lifecycle process steps – Incident Identification, Logging, Classification and Prioritization.
- Incident Identification – just like it sounds, this step is to determine that an incident has occurred. Ideally, you’d have monitoring systems in place to warn you of impending issues so you can resolve incidents before users notice, but sometimes this isn’t possible.
Logging – this step is necessary to document the incident. No matter how small, all incidents need to be recorded (use this template) to ensure you can go back and look at incident trends and to give credit where work was done. Logging should at a minimum note the data and time of the incident, the person reporting the incident and a description of the problem. Ideally you’d track additional information such as urgency, priority, affected services, etc.
- Classification – incident classification is useful for a look back to determine if there are trends in the types of incidents you receive. You will need to develop an appropriate classification scheme with 3-4 levels. For example, you may have categories for Hardware and Software with each broken into various types of hardware and software such as printers, servers, Microsoft Office, and so on. Don’t go category crazy by creating hundreds of categories – remember that you need your service desk personnel to use this system!
Prioritization – this step asks that you look at both the urgency (how quickly does something need to be done) along with the impact (how many services are affected, is there risk to life and limb?). As an example, an incident that has high urgency and high impact should be worked on before something with low urgency and high impact.
The Action phase deals with resolving the actual incident and includes ITIL processes for Investigation, Diagnosis, Resolution and Recovery.
- Investigation and Diagnosis – investigation includes initial diagnosis – is this something the service desk can handle or does it need to be escalated to management or a higher level service desk? The incident can then be investigated – what specifically is wrong, what does the end user expect? The service desk should have a full picture of what the incident entails before finding a resolution.
- Resolution and Recovery – this is pretty simple – the resolution step focuses on finding a solution to the incident and reporting back to the requestor.
This phase deals with how to close out the incident.
- Incident Closure – Instead of simply closing out an incident, you should make sure your service desk personnel check with the end user to ensure the incident was handled satisfactorily. If so, the incident can be closed. The service desk personnel should also consider whether or not this was a recurring problem (in which a problem report should be created).
Obviously, this was just a brief introduction into using an ITIL Incident Management Diagram – additional information can be found on the ITIL Open Guide.