POL00393885
POL00393885
.
Service Management Framework
D
Incident Management
FRAMENIORK
DernTion
— -
‘CROSS DOMAIN
Process
Author Nick Embling Reference HOR/BSM/FMK/002
Version 08 Classification I Working Level Document
Date Status Draft
Authority Name Signature Date
POCL
ICL Pathway
POL00393885
POL00393885
INCIDENT MANAGEMENT FRAMEWORK
TABLE OF CONTENTS. Introduction---------------------------------------------n anna nnnnnnnnne 3
2. Terminology--------------------------=-------- nnn nnn nnn nnn nnn nnn nnn 3
3. Roles and FOrums---------------------------nnennnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn 5
4, Incident Management---------------------------------------------------------------9--nnnn nanan nnn 5
5. General-------------------------------------------------------------------------------------------------- 7
0.1 DOCUMENT HISTORY
Version Date Details
01 Separated from “Incident and Problem Management” and updated
with observations from procedural walkthroughs.
0.2 updated with comments from BSM review
0.3 12/2/99 updated with comments from ICL Pathway and the DSS.
0.5 24/5/99 updated to common framework format
06 1/7/99 produced for the Framework Steering Group
07 13/8/99 ‘Amended to reflect separation of cross domain processes; for formal
review by POCL and ICL Pathway.
08 18/8/99 Updated by Framework Steering Group - issued for formal review by
POCL and ICL Pathway
0.2. REFERENCE DOCUMENTS
Doc. Ref.
Title
Reference
0.3. DISCLAIMER
This is a Working Document. As such it is without prejudice to any of the parties and
nothing contained herein shall be deemed or construed as affecting existing contractual
obligations or creating new contractual obligations between any of the parties.
Page 0 of 7
HOR/SMF/FMK/002
Version 0.8.
POL00393885
POL00393885
INCIDENT MANAGEMENT FRAMEWORK
1. Introduction
1.1 This paper sets out the definitions, practices and policies which have been
agreed for the day to day management and resolution of Incidents across the
POCL and ICL Pathway live service environment. The Incidents referred to in
this document are Cross Domain Incidents, i.e. those Incidents that affect more
than one organisation.
1.2. This document does not apply to contractual issues. There are separate and
formal arrangements for the consideration, escalation and resolution of any
contractual difficulties that arise between POCL and ICL Pathway. All disputes
of a contractual nature must be progressed in accordance with the Authorities
Agreement Clause 807.
1.3. Although Incident Management always involves Helpdesks it may also include
activities that occur in other functions and areas within organisations.
2. Terminology
2.1. Within a Service Management environment it is important to ensure a common
understanding of the terminology that is used.
2.2. The following denotations are applied as part of the Horizon Service
Management Framework and have been agreed between POCL and ICL
Pathway. The definition of an Incident is best explained in conjunction with the
definition of a Problem.
2.2.1 Incidents
Incidents are individual day to day events resulting from:
¢ faults or failures in equipment, software, services or procedures;
e user error;
© user requests for advice and guidance.
Such an event may be resolved locally or be raised as an Incident. An
Incident will be deemed to exist when it is logged on a POCL or ICL
Pathway Incident Management system.
Incidents are managed via a framework of function specific services,
fronted by Help Desks. Once a solution or temporary procedure has been
applied and accepted the individual Incident will be closed.
Page 1 of 7
HOR/SMF/FMK/002 Version 0.8
POL00393885
POL00393885
INCIDENT MANAGEMENT FRAMEWORK
2.1.2. Problems
A Problem is a record of an underlying cause which may result in
Incidents.
A Problem potentially exists when a defect in the specification, design,
production, implementation, or use of any of the service components
results in any aspect of the service not meeting expectations.
A Problem will be raised when the impact of the defect (e.g. the level and
severity of the related incidents) is substantial enough to warrant action to
eradicate it.
A Problem will be deemed to exist when it is logged on a POCL or ICL
Pathway Problem Management system.
A Problem will be closed when it has been agreed that the underlying
cause has been fixed or removed.
2.1.3. Escalation
Incidents may be escalated to various levels between POCL and ICL
Pathway. This process is intended to bring increasing levels of
management attention and/or expertise to bear upon the resolution of an
Incident. Escalation should be considered to be an exceptional resort, and
the reasons for resorting to escalation should be examined for each
occurrence. Escalation to a higher level will normally occur either:
¢ when an issue is causing increased concern through time delay and
consequent business impact, or
¢ when it has not been possible to reach agreement on some aspect of the
definition or management of the issue.
2.14 Temporary Procedures
An Incident may be resolved by the application of a temporary procedure,
which will be agreed between the Helpdesk managing the Incident and
the organisation within which the Incident occurred. This will be at the
discretion of the parties involved, who must take into account any actual
or potential impact on other business areas.
When a Problem is raised, a temporary procedure may be identified as a
method of resolving the related Incidents until such time as the Problem
is resolved. These temporary procedures must be agreed between POCL
and ICL Pathway, at which point they are designated “Authorised
Temporary Procedures”.
Page 2 of 7
HOR/SMF/FMK/002 Version 0.8
POL00393885
POL00393885
INCIDENT MANAGEMENT FRAMEWORK
3. Roles and Forums
3.1 Context
POCL and ICL Pathway have differing structures and roles; the roles detailed
below are common to both organisations, but do not represent the totality of the
organisation structure. The formal job titles may differ from those below, but
POCL and ICL Pathway will identify a direct equivalent to those roles.
3.2. Helpdesk Operator
The Helpdesk Operator takes incoming calls at the Helpdesk, logs Incident
details, may be mandated to resolve the Incident if possible, otherwise refers it
to second line support or an expert domain for resolution, closes the Incident
when resolved.
3.3. The Operational Service Manager
The escalation route must include the Operational Service Manager, who is a
member of the Horizon Service Review Forum.
3.4 Horizon Service Review Forum
The HSRF can arbitrate when agreement cannot be reached between the Service
Management functions, and will be informed of volumes and trends of Incidents
and their resolution.
4. Incident Management
4.1 Incident Management Policy
4.1.1. The primary purpose of Incident Management is to deal quickly and
effectively with day to day events that interrupt normal performance of
the systems, services, processes and procedures in a live operational
environment.
4.1.2 Incidents will generally require either a technical and/or business related
solution. Simple faults or failures may be resolved through localised
support arrangements within an operational group or unit.
4.1.3. All other faults, failures, reconciliation errors or requests for advice and
guidance will be reported to an appropriate Help Desk service. The
relevant Help Desk will thereafter assume responsibility for control and
co-ordination of the efforts required to resolve the incident. It is
anticipated that many incidents will be resolved over the telephone by
front line Help Desk staff. Others will need referring to one or more
expert domains where the responsibility and/or skill exists to provide a
solution.
Page 3 of 7
HOR/SMF/FMK/002 Version 0.8
POL00393885
POL00393885
INCIDENT MANAGEMENT FRAMEWORK
42
43
4.1.4 The resolution of incidents will be prioritised according to business
impact and may require escalation. There will be target resolution times
according to the category/ priority of a particular incident and agreed
escalation routes.
4.1.5 All Help Desk services within the POCL and ICL Pathway service
domains will either maintain records and statistics to facilitate
performance reporting and incident trend analysis, or will provide such
records to another domain for this purpose. This type of information
feeds into the Problem Management function and overall Service Review
process
4.1.6 In the event of a serious incident involving outage of a major component
of the end to end service, the Cross Domain Business Continuity
Management Framework provides guidance about the invocation of
Contingency Plans and related decision paths/escalation routes.
Incident Management Principles
In order to meet the objectives outlined above POCL and ICL Pathway will
follow this policy:
e All Incidents should be recognised as such and reported to the appropriate
Help Desk
« Accounting and reconciliation errors will be classified as Incidents.
e All Incidents will be recorded and assigned a unique number by the Help
Desk.
¢ Priority and severity values will be assigned to all Incidents.
¢ Incidents will be carefully diagnosed and responsibility for resolution clearly
assigned.
e Incidents will be resolved without unnecessary delay and against
performance targets.
* There must be clear and pre-defined routes for the escalation of Incidents to
support increasing levels of management focus.
¢ Incidents will only be closed when the Incident originator agrees that the
Service has been restored to normal.
e The impact of an Incident will be assessed and all operational areas affected
will be informed.
« Wherever possible, potential Incidents will be identified in advance and pre-
defined routes to resolution will be developed.
« Advice and guidance provided by Helpdesks must be consistent.
Incident Management Process
POCL and ICL Pathway will develop and maintain complementary and
consistent internal procedures for reporting, registration, monitoring, control,
Page 4 of 7
HOR/SMF/FMK/002 Version 0.8
POL00393885
POL00393885
INCIDENT MANAGEMENT FRAMEWORK
resolution and closure of cross domain Incidents. These will be embodied and
described in the Cross Domain Process for Incident Management (REF)
44 Escalation Policy
44.1 When it is decided to escalate a cross domain issue, it is important that the
escalation is simultaneous (or as close to simultaneous as is practicable)
and that it is to an equivalent level in each of the organisations affected.
Because organisation structures are not always direct equivalents, it is
sometimes necessary to combine roles in order to achieve a synchronous
escalation. The Escalation process is designed to focus on the Horizon
Service Review Forum, so that any issue escalated reaches that level
within each organisation at the same point in the escalation process.
4.4.2 The decision to escalate will be made when it is considered that the issue
in question cannot be resolved at the level at which it is being managed.
Participating counterparts in other organisations must be informed, and
each should escalate the issue to the next level.
4.4.3 Escalation should be distinguished from referral, referral being
notification that occurs during the normal operation of a process, so that
referral of a Business Continuity Incident to the Operational Service
Manager is not escalation, as it is a step in the standard process for
Business Continuity.
44,4 Itis desirable that escalation points for all Service Management
disciplines are constant, thus ensuring that managers are dealing with the
same contacts for all escalated issues.
5. General
5.1 For further detailed information about the management of incidents and
problems across the live environment, reference should always be made to the
detailed procedures which exist within POCL and ICL Pathway.
Page 5 of 7
HOR/SMF/FMK/002 Version 0.8