Don’t tell anyone but for some reason I can post to the SysAid blog now... and to start I want to provide a simple introduction to incident management. Humble is what I do best. Oh, and I’d better be on my best behavior. So I’ll quickly cover:
If you read my blog, then you know I refer to ITIL quite a bit (you might think too much) but you can quite easily use your own self-created process and activities or look to alternative sources of advice such as ISO/IEC 20000, ISACA’s COBIT, USMBOK, or Microsoft’s MOF.
To set the scene, corporate IT organizations need to consistently provide:
Incident management can help with all three, but will support the latter point for the most part. Incident management helps to keep business services available and employees productive. And most IT shops already do some form of incident management – though they might call it IT support, help desk, ticketing, service desk, or something else.
Put simply, incident management is the process or set of activities used to identify, understand, and then fix IT-related (but business impacting) issues, whether it be:
ITIL, the IT service management (ITSM) best-practice framework formally known as the IT Infrastructure Library, uses the term “incident management” to describe the handling of such IT issues from identification through to resolution.
With the objective of incident management being:
“To restore normal service operation as quickly as possible with minimum disruption to the business.”
This is where the IT issue requiring attention (“Any event that disrupts, or could disrupt, an IT service and/or business operations”) is termed an incident.
According to industry surveys, incident management is consistently reported as being undertaken by approximately 95% of organizations. And this process or set of activities is commonly supported by fit-for-purpose technology, i.e. a service desk, IT help desk, or ITSM solution.
ITIL separates out the severely business-impacting incidents as “major incidents.” These highly disruptive incidents – such as an online sales system or the corporate HQ’s internet service being down – are often treated as emergencies with significant IT resources applied to ensure a speedy resolution and the resumption of business operations as soon as possible. Some organizations will operate a separate major incident management process. If you would like to read more on this, Rob England, aka the IT Skeptic, has written a great blog on major incident management.
At the other extreme are service requests, which are non-incident-related calls to, or contacts with, the IT service/help desk. And, as the name suggests, these are requests for new or changed IT services such as:
It’s important to treat incidents and service requests separately due the relative urgency of an IT issue versus the need for a new IT service.
ITIL defines the objectives of the incident management process as:
It might sound complicated but it does really just boil down to the earlier ITIL incident management objective of “To restore normal service operation as quickly as possible with minimum disruption to the business.”
ITIL recommends that incidents be managed through a lifecycle, or process, that includes a number of steps, activities, or sub-processes – from the initial identification or reporting of the incident through to its resolution and the closure of the incident record. This is the order:
Continuous ownership, monitoring, tracking, and communication are involved throughout each step as per the sexy little diagram I have created below.
The benefits of incident management include, but are not restricted to:
Well there you have it – my first post in the SysAid blog. Did you find it helpful?
If you want to read more from me on incident management, then please look at: