Earlier this year, AXELOS® released the latest version of its widely popular ITSM (information technology service management) framework, ITIL® 4.
In this blog, we look at one of the integral parts of that framework: incident management.
What is ITIL incident management?
To understand incident management, you must first understand what an ‘incident’ is in the context of ITIL – namely, a disruption affecting an organisation’s IT services.
This encompasses everything from issues affecting a single user to those that disrupt everyone in the organisation.
Likewise, it covers issues that completely shut down a service as well as those in which the service is simply operating in a way that it shouldn’t.
Incident management is the process of logging, recording and resolving those issues. The first goal of incident management is to restore operations to normal as quickly as possible and to minimise the impact on business operations.
Speed of recovery tends to be the top priority in this process. That means issues are often addressed with temporary fixes rather than permanent solutions (we’ll come to permanent fixes later).
Because incident management affects the whole organisation, it’s typically part of an organisation’s service desk.
This provides all users with a single point of contact and gives the organisation a dedicated team that is responsible for tackling incidents.
Incident management vs. problem management
‘Incident’ and ‘problem’ might sound like two words for the same thing, but they have distinct definitions in ITIL.
A ‘problem’ is the underlying issue that causes one or more incidents. For example, a user might log a complaint saying ‘my computer doesn’t work’. That’s an incident.
It’s only once someone in your IT department has spoken to the user that they can determine what the problem is.
This is problem management, and it focuses on finding long-term fixes for incidents and ways to prevent them recurring.
It’s essential that you separate incident management and problem management, because issues will arise constantly in any organisation that uses IT, and significant delays can be costly.
For example, if the user with the broken computer has to wait until IT has figured out what caused the problem, they could be sitting around all day without being able to do any more work.
That’s obviously a waste of their time, and they’ll rightly be frustrated. But the organisation will suffer just as much, because the downtime will affect productivity.
However, if you provide a quick fix – like giving the user a new computer – you resolve the incident, and buy yourself time to work on the underlying problem.
Keeping track of incidents, problems and how they are resolved is the core of problem management.
It gives IT staff a list of common fixes that they can try, speeding up the troubleshooting process.
Logging incidents also helps the organisation determine whether the use of certain technologies or processes need to be reviewed.
For example, if users keep noting that the printer doesn’t work because it’s out of ink, the organisation should investigate.
Maybe someone in the organisation is abusing their printing privileges. More likely, there’s a problem with the printer hardware and the cartridges aren’t actually empty.
Incidents can be split into two categories.
The first are those related to user experience. This will be the case for the printer and broken computer examples previously mentioned.
Other incidents in this category include issues connecting to the network, applications that don’t open or any other anomaly that a user spots when trying to work.
The second category is technical incidents. These are errors in the hardware or software that the user won’t necessarily notice, like the hard drive becoming full or issues with the computer’s network card.
They tend to be spotted by IT during routine monitoring.
Benefits of ITIL incident management
There are several reasons to adopt ITIL’s incident management process:
- Improved incident response times
ITIL’s standardised method for incident management ensures that you are providing prompt response, analysis, documentation, ongoing management and reporting of incidents.
- Enhanced incident visibility
With a clear process for logging incidents, you can be sure that everyone in your organisation knows what to do if they have an IT issue and what’s being done about it.
You’ll also have a complete overview of the issues throughout your organisation. This helps you determine whether you have the resources to address your problems in a timely manner.
- Improved user satisfaction
No one wants their performance at work compromised because of IT issues, so prompt responses will result in happy users.
ITIL’s incident management process will also help the team responsible for addressing incidents and problems. They have documented guidelines to follow, helping them operate more efficiently and document the work they’ve done.
- Improved productivity
By aligning incident management activities with those in the rest of your organisation, you’ll see drastic improvements in its ability to detect and address issues quickly.
The ITIL incident management lifecycle
ITIL provides a seven-step process (or ‘lifecycle’) for handling incidents:
1) Incident identification
This is when the service desk first becomes aware of an issue.
User experience-related incidents are likely to be detected by a user, who will file a complaint.
Technical incidents, on the other hand, are often identified during routine monitoring.
2) Incident logging
Once the incident has been identified, it should be logged by the service desk.
They will typically require the name of the person who identified the incident, the date and time it was spotted and a description of what’s wrong.
The service desk will then conduct incident classification. This is a way of determining what kind of issue it is (does it affect a single user or many people, is it a problem with hardware or software, etc.)
Incident classification has two goals: to enable the service desk to look for any trends, and inform incident prioritisation.
Incident prioritisation is the process of determining the urgency of a resolution.
This will usually be defined as ‘high’, ‘medium’ or ‘low’, and be based on the number of affected users and the level of disruption the incident is causing.
3) Incident investigation and diagnosis
This is the first step towards resolving the incident.
The affected user discusses the incident with a member of the service desk to see if there’s an immediate fix (‘have you tried turning it off and on again?’), or if they can quickly identify the problem (‘you need to perform a system update’).
If the service desk’s hypothesis is successful, the issue is resolved and you can skip directly to step 5.
However, if there’s no immediate fix, the incident will need to progress to the next stage.
4) Incident assignment or escalation
With further work required, the service desk will assign the incident to an on-site technician or certified support staff, who will look for a workaround and then investigate the cause of the incident.
5) Incident resolution
As the name suggests, this step involves the service desk confirming that the incident has been resolved.
6) Incident closure
At this point, the incident is considered closed and the process ends.
7) User satisfaction survey
The organisation might ask users to complete a short questionnaire once the issue is closed to determine whether they were happy with the service delivery.
This is a good way of identifying any issues in the incident management process, such as unhelpful service desk staff or unsatisfactory resolutions.
Meanwhile, overwhelmingly positive feedback is a great way of boosting employee morale and it can help you identify team members who excel at their job.
Related ITIL processes
Incident management is closely related to several other ITIL service management processes, such as:
- Change management
In resolving an incident, you might identify something (software, hardware, a process, etc.) that needs to be changed.
Significant changes also tend to lead to a spike in incidents, with users suddenly having to get used to a new way of working.
- Problem management
As we discussed earlier, problems are the root causes of incidents, so whenever you initiate the incident management process, you might also need to investigate the underlying problem.
- Service asset and configuration management
An organisation’s configuration management system helps detect relationships among service components.
It also integrates configuration data with incident and problem data.
- Service level management
The service desk must maintain an agreed-upon level of service with the organisation they work with. SLM (service level management) is the system for ensuring this happens.
Incident management roles and responsibilities
The incident management team comprises:
- Incident manager
The incident manager takes overall responsibility for the organisation’s compliance with ITIL’s incident management process.
They lead the rest of the team, report KPIs (key performance indicators) to management and review the continual improvement of the incident management process.
In small and mid-sized organisations, this role is usually assigned to the service desk manager. Larger organisations may choose to appoint someone dedicated to the role.
- First-line support
This is the person (or people) who register and classify incoming incidents and take immediate remediation efforts.
They will have a solid IT knowledge, but they aren’t necessarily experts.
- Second-level support
These are the IT professionals with an advanced knowledge of software and hardware.
First-line support will escalate issues to them if the incident doesn’t have an easily identifiable solution.
Second-level support might need to interact with third-party experts from software or hardware vendors to help restore service.
Implementing incident management
To get the most out of ITIL’s incident management framework, you and your staff need an expert understanding of how it works.
A comprehensive personal certification scheme, such as our three-day ITIL Foundation course, is the perfect place to gain this knowledge.
We’ve updated our course in line with the release of IITL 4, and provide you with the key facts you need to negotiate the framework’s requirements and handle incident management.