You are on page 1of 8

Incident Management

Process description version 1.1

© Copyright 2015 OpenTRIM AB 1


Table of content
Introduction...............................................................................................................................3
Purpose.................................................................................................................................3
Trigger...................................................................................................................................4
Process description...................................................................................................................5
Overview...............................................................................................................................5
Activities................................................................................................................................6
Responsibility........................................................................................................................7
Measurement........................................................................................................................8
Process organization.............................................................................................................8

© Copyright 2015 OpenTRIM AB 2


Introduction
An incident is defined as:
” An unplanned interruption or a deterioration in the quality of an IT service. An error in a
component in the IT environment that does not directly affect the quality of the delivery (for
example, a hard drive with redundancy) should also be classified as an incident.”

Purpose
The main purpose of the Incident Management process is to restore the agreed service level
as quickly as possible and to reduce the negative consequences for the business. This
means that if the IT organisation is not able to rectify the error directly, a temporary solution
(workaround) which restores the functionality for the user can be sufficient. The purpose also
means that an incident should as far as possible be rectified in such a way that the business
suffers no further negative effects.
The purpose of Incident Management is achieved through:
 Ensuring that standardised methods and procedures are used
 Making incidents visible internally and in the business
 Acting professionally through communicating and resolving incidents rapidly when
they arise
 Starting out from the business's priorities when prioritising incidents

© Copyright 2015 OpenTRIM AB 3


Trigger
Incident Management is triggered through:
 A user contacting Service Desk about an error
 A system automatically registering an error
 Someone in the IT department detecting an error
 A supplier contacting the IT organisation about an error

Input
The following inputs are needed for Incident Management:
 Documentation of all IT services and their associated components.
 Information about known errors and temporary solutions
 Information about previous incidents
 Information about changes implemented in the IT environment
 Agreed service levels for the IT services
 Documented criteria for prioritising and escalation

Output
The following outputs are generated by Incident Management:
 Resolved incidents
 Updated documentation about activities performed that are linked to the incident
 Categorised incidents for further analysis of the problem process
 Registered problem record
 Feedback to the Change Management process for incidents linked to a change
 Information and statistics about incidents

© Copyright 2015 OpenTRIM AB 4


Process description
Overview

© Copyright 2015 OpenTRIM AB 5


Activities

Activity Description Routine


Registration All issues must be registered with the
concerned user, equipment and a detailed
description of the issue.
Categorisation Categorise the issue according to a
predefined list.
Prioritisation The priority is determined through a Routine prioritizing
combination of current impact, future impact
Routine Major Incident
and time frame according to the prioritisation
model. If it is a Major Incident it trigger
Major Incident procedure
Initial The service desk analyst tries to resolve the Known Error
diagnosis incident immediately using his/her own
Known Error Database
knowledge or documentation in previously
registered incidents, problems and known System documentation
errors and subsequently closes the issue. Service documentation
Incident Verify functionality with initiator. Routine How to close
solved Incidents
If it solved continue to verify and close.
Otherwise go to Escalation
Escalation Escalation to second line support within Routine How to Escalate and
Service Desk or an external supplier is called Contact information needed
functional escalation.
Investigation Second line support does not usually have the System documentation
and diagnosis user on the line and can therefore put more
Service documentation
time and energy into resolving the incident.
Agreements

Incident If it solved continue to verify and close. If it Routine How to register a


solved is not register a Problem and trigger Problem problem
Management and escalate.
Routine How to Escalate and
Contact information needed
Verify and All solution groups can close an issue after Routine How to close
close having checked with the user that the Incidents
function is restored.

© Copyright 2015 OpenTRIM AB 6


Responsibility

Activity Responsible Accountable Consulted Informed


Registration Service Desk or Incident Service Desk Service Desk
any within the Manager Manager
IT organization
Categorisation Service Desk Incident Service Desk User
Manager Manager
Prioritisation Service Desk Incident Service Desk IT Operations
Manager Manager Manager
Initial diagnosis Service Desk Incident Service Owner User
Manager
Incident solved Service Desk Incident Service Desk User
Manager Manager
Escalation Service Desk Incident Service Owner User
Manager
Investigation and Technical Incident IT Operations User
diagnosis Analyst Manager Manager
Service Desk
Applications Problem Manager
Analyst
Service owner
Incident solved Technical Incident IT Operations User
Analyst Manager Manager
Service Desk
Applications
Analyst
Verify and close Service Desk Incident Service Desk User
Manager Manager

© Copyright 2015 OpenTRIM AB 7


Measurement
Metrics Description Responsible
Number of Incident per month Measure workload on Incident Manager
Service
Number of solved incident in Service Measure level of knowledge Service Desk
Desk and documentation within Manager
Service Desk
Mean time solved incidents Measure Service Desk Incident Manager
effectiveness
Number of incidents per service/system Measure service/system Service Owner
quality
Number of Major Incidents Measure service/system Service Owner
quality

Process organization

Role Name Contact


Incident
Manager
Process owner
Service Desk
Manager
Major Incident
Manager

© Copyright 2015 OpenTRIM AB 8

You might also like