ITSM Basics: A Simple Introduction to Incident Management

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:

• What incident management is
• Major incidents and service requests
• The objectives of incident management
• The “incident lifecycle”
• The benefits of incident management

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.

Where Incident Management Fits In

To set the scene, corporate IT organizations need to consistently provide:

• Uninterrupted IT and business services
• A level of service that meets customer needs at an acceptable cost
• Speedy resumption of service when IT issues or failures occur, particularly when these issues adversely affect business operations

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:

• A faulty laptop
• Email delivery issues, or
• A lack of access to the corporate network, a business application, or the internet, for example

Incident Management Definition

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.

Separating Out Major Incidents and Service Requests

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:

• A request for new hardware or software
• An access request: for an application or shared drive
• Information on a particular IT service, e.g. what does application X do and should I have access?
• “How to” information, e.g. how do I access my emails while out of the office?

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.

Incident Management Objectives

ITIL defines the objectives of the incident management process as:

• “Ensuring that standardized methods and procedures are used for efficient and prompt response, analysis, documentation, ongoing management and reporting of incidents.
• Increasing the visibility and communication of incidents to business and IT support staff.
• Enhancing the business perception of IT through the use of a professional approach in quickly resolving and communicating incidents when they occur
• Aligning incident management activities and priorities with those of the business.
• Maintaining user satisfaction with the quality of IT services.”

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.”

The “Incident Lifecycle”

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:

1. Incident detection and recording
2. Initial classification and support
3. Escalation to a major incident process where needed
4. Invocation of the service request process if not an incident
5. Investigation and diagnosis
6. Resolution and recovery
7. Incident closure

Continuous ownership, monitoring, tracking, and communication are involved throughout each step as per the sexy little diagram I have created below.

Incident Management Benefits

The benefits of incident management include, but are not restricted to:

• Shortening the “incident lifecycle” and decreasing downtime, thus maximizing business productivity.
• Resolving incidents before they can adversely impact business operations.
• Making better use of potentially scarce IT resources. Having defined roles and responsibilities and a single, consistent process not only speeds things up but also reduces duplication of effort and wastage.
• Facilitating better collaboration between different IT teams and preventing dropped issues or issues “ping-ponging” between teams.
• The ability to leverage existing knowledge to speed up resolution.
• Reducing the costs associated with both IT service delivery and IT support.
• Reducing the adverse effect of business-impacting incidents. This might potentially include lost revenue, lost reputation, or even lost customers.
• The ability to identify, and act on, opportunities to improve IT services and IT service delivery.
• Improving customer service and the business’s perceptions of the IT organization as a whole.

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:

• 12 Tips For Getting Started With Incident Management – Part 1
• 12 Tips For Getting Started With Incident Management – Part 2
• The Greatest Ever Code to Incident Categorization