FUJ00119991
FUJ00119991
ICL Pathway ICL Pathway Problem Management Process Venton CSPRDIO2L
Date: 26/08/99
Document Title: ICL Pathway Problem Management Process
Document Type: Process Description
Abstract: This document defines the ICL Pathway Problem Management
Process. The process has been developed so that it covers both
problems that are only visible to ICL Pathway, and also
problems that impact POCL as well as ICL Pathway.
Status: For Approval
Distribution: Julia Bowes
Richard Brunskill
Peter Burden
Paul Curley
Bob Davis
Michael Fiore
Stephen Muchow
Alex Nicholson
Mik Peach
Alison Peacock
Janet Reynolds
Martin Riddell
Mike Stewart
Julie Welsh
Paul Westfield
Mike Woolgar
John Wright
Library
Author: Evandro Manolas
Comments to: Author
Comments by:
COMMERCIAL IN CONFIDENCE Page I of 33
© 1999 ICL Pathway Ltd
FUJ00119991
FUJ00119991
ICL Pathway ICL Pathway Problem Management Process Ref. CS/PRD/021
Version: 2.0
Date: 26/08/99
O Document controt
0.1 Document history
Version Date Reason
1.0 05/11/97 ICL Pathway Problem Management Process
Ll 16/04/98 Update
1.2 25/05/98 Update
13 19/07/98 Update
14 03/12/98 Update
1S 04/02/99 Update
1.6 29/07/99 Updated following internal review and comments
2.0 For approval
0.2 Approval authoritiey
Name Position Signature Date
Paul Westfield
Martin Riddell
0.3 Associated documenty
Reference Vers Date Title Source
1 CS/PRD/012 Ll 26/01/98 Release Authorisation and Distribution ICL Pathway
Process for Software Fixes
2 CS/PRD/063 0.3. 27/08/99 Generic Service Management Processes ICL Pathway
3 CS/PRO/063 0.2 04/02/99 Proposed Problem Management ICL Pathway
Procedures to support the Customer
Service Operations Manual
4 HOR/SMF/PM_ 1.5 01/07/99 Service Management Framework — POCL
G/002 Problem Management
5 PA/PRO/001 6.0 Change Control Process ICL Pathway
COMMERCIAL IN CONFIDENCE
Page 2 of 33
FUJ00119991
Management Process.
- Amendment to Temporary Procedure description within Section 5.
- Amendment to the role of the Problem Manager, Section 6.
COMMERCIAL IN CONFIDENCE
FUJ00119991
ICL Pathway —_ ICL Pathway Problem Management Process Ref. CS/PRD/021
Version: 2.0
Date: 26/08/99
0.4 Abbreviationy
cP Change Proposal
cs ICL Pathway Customer Service Department
DM Duty Manager
ETP Emergency Temporary Procedure
DA Database Administrator
HSH Horizon Systems Helpdesk
ICL PW ICL Pathway
ICL PW PM _ ICL Pathway Problem Manager
ICL PW SM _ ICL Pathway Service Management
PIR Post Implementation Review
PM Problem Manager
POCL Post Office Counters Limited
SSC Systems Support Centre
0.5 Changes Ww thiy vervow
- Withdrawal of Service Improvement Opportunities from the Problem
Page 3 of 33
FUJ00119991
FUJ00119991
ICL Pathway ICL Pathway Problem Management Process Ref. CS/PRD/021
Version: 2.0
Date: 26/08/99
0.6 Toble of content
L, Introduction... eecceeeeeeeesseeesseeeeseeeneeessesesneeessesesseesnsesssseeensessseesnessnnersnsesee®
2. Scope...
3. Definition of a Problem 2.0.2.0... ceccecccecc cesses tess eesneeseeseeeneeneesneesnseneeeseseeeenessneeseeeneenee
DAaWnwY
4. The Service Management Framework .............c..ccccesees cesses eeseseeseeseeseeeesseeteeneeeeseeneenes
x
5 Glossary Of Terms ..........cccceseeseeseesessesseesesneseesesnessesvenesesnesseaneseesssneereareeeeseeneereanereeseenee
6. Problem Management Roles .0..........2..c:cseseesseesseesseeseesseseeeseeesneesneeneeseesseeeneeseeseeeeeenee 8
6.1 Problem Originator oo... eee eeceseeseeseseesseseeeeeseseessesneeeesuesseueeneeeseeeeenees 8
6.2 Problem Manager ...............cceccsecseecsesseesseseeeeseesseeseeseeereeseesreesnesaeeseeneesneenneeaeesees 8
6.3 Problem Resolution Manager ............c.ccs:ccsecsesseseeseereesesreeeeseeseeeeteeeestesteseeeeeeee &
7. Problem Management Principles ...........2.....2.ccccesceeees ces ees ee eeseeeeeeeeseeeseeeenneeeeeneeeee
8. Problem Management Process ..............cccceeee eeneseeeeeeeeeneeneeteeeeeeteeeeteeeeeeeees LO
8.1 Problem Assessment Process ...............sccecce esses eesreeesneesenersneesreneeneesseees LO
8.1.1 Problem Assessment Description ..........0..c0:cesceseeeseeteeseeseeteeeeeeeeeeee LT
13
8.2.1 Internal Problem Management Description ................c0cceeceeseesneeeeeeeeeee LS
8.2 Internal Problem Management................
8.2.2 Temporary Procedures
8.2.2.1 Temporary Procedure Description .............2.0.:tcc cesses 1D
8.2.3 Internal Communication «0.0.0.0... eeseeeseesecs ese eesseesneesessenseeeoneenneeneenne 20
8.3 Cross-Domain Problem Management ................. 221
8.3.1 Cross-Domain Problem Management Description .............0:.0:1eeeee 24
8.3.2 Authorised Temporary Procedures ................ 27
8.3.2.1 Authorised Temporary Procedures Description...............00.00000.29
8.4 Escalation...
8.5 Problem Prioritisation 0.00... cess eesseecsseesseesseessesesneesseesssneessenssntesneeeneees SZ
COMMERCIAL IN CONFIDENCE Page 4 of 33
FUJ00119991
FUJ00119991
ICL Pathway ICL Pathway Problem Management Process Ref: SSPRD ODL
Version: 2.
Date: 26/08/99
1 Introductiow
Not all incidents that arise at the helpdesks can easily be resolved using the incident
management processes. Some incidents have a wide impact, some may be difficult
and time consuming to resolve, whilst others may relate to a single underlying issue.
Therefore, some incidents may require referral into ICL Pathway Service
Management, as well as being passed through their regular support routes, to aid
resolution
A key element for success in the resolution of incidents that are referred to the ICL
Pathway Service Management team is an effective Problem Management process.
2 Scope
This document details the ICL Pathway Problem Management process. For detailed
procedures please refer to [Ref.3].
The process starts by determining whether a problem has a cross-domain impact, i.e.
the problem impacts POCL as well as ICL Pathway. The process then splits into two
sections.
The first part defines the process for the management of problems that are internal to
ICL Pathway, and only impact ICL Pathway.
The second section defines the process for resolving problems that impact POCL as
well as ICL Pathway, and how the two organisations work together to resolve such
problems.
Note:
The processes reflect, and are based upon, the high level cross-domain Problem
Management process agreed between ICL Pathway and POCL. [Ref. 2/4]. See Section
4 for a further explanation of the high level cross-domain process.
COMMERCIAL IN CONFIDENCE Page 5 of 33
FUJ00119991
FUJ00119991
ICL Pathway ICL Pathway Problem Management Process Ref. CS/PRD/021
Version: 2.0
Date: 26/08/99
3 Definition of a Problew
As agreed with POCL.
A Problem is a record of an underlying cause that 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 issue has been
fixed or removed.
4 The Service Management Framework
ook I
PATHWAY
PATHWAY Contractual
Framework
Definition
Service
Management
vy v Vv Vv Vv Vv Framework
Documents
Service Business
change Service Performance Probiem hnoident
Configuration Continuty
ceguraton Management Review Reporting Management Management Contin
\
Joint
@oss-Domain
Problem
Management Process
12 Pathway Oxganisatonal
ey Level
nagemer Docurention
Process
v
The above diagram highlights the Service Management Framework documents. These are
high level, non-contractual agreements between ICL Pathway, POCL. As can be seen,
Problem Management is a part of the framework, and ICL Pathway’s Problem Management
process will relate to the higher level documentation as agreed with POCL.
COMMERCIAL IN CONFIDENCE Page 6 of 33
FUJ00119991
FUJ00119991
ICL Pathway ICL Pathway Problem Management Process Ref. CS/PRD/021
Version: 2.0
Date: 26/08/99
5 Glossary of Terwy
Authorised Temporary Procedure
A Temporary Procedure that has been agreed by both ICL and POCL Problem
Management teams to resolve incidents that are associated to a problem. The need to
develop an ATP will be dependent upon the nature, impact and probable duration of a
problem.
Change Proposal
An official request to change/update part of the Horizon solution.
Database
A manual or electronic storage facility for a problem record
Emergency Temporary Procedure
The term used for a Temporary Procedure that is in use to resolve incidents that are
associated to a cross-domain problem, until it has been authorised as an Authorised
Temporary Procedure by both the ICL and POCL Problem Management Teams.
Incident
An incident is an individual day to day event resulting from: faults or failures in
equipment, software, services or procedures; 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. Once a solution or temporary procedure has been applied and accepted, the
individual Incident will be closed.
Post Implementation Review
A review of the Problem Process following resolution. Both ICL and POCL Problem
Managers or Business Continuity Managers will attend the review. The objective of
the review is to look for improvement opportunities in the process using the
experience of the last Problem / Business Continuity event.
Problem
See definition on Page 6
Temporary Procedure
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, impacts on other business areas.
COMMERCIAL IN CONFIDENCE Page 7 of 33
FUJ00119991
FUJ00119991
ICL Pathway ICL Pathway Problem Management Process Ref. CS/PRD/021
Version: 2.0
Date: 26/08/99
6 Problem Management Roley
6.1 Problem Originator:
The person who raises the problem, and notifies Service Management within the
parent organisation of the problem.
6.2 Problem Manager:
The Problem Manager is the person within the Service Management organisation with
responsibility for managing a problem and ensuring it is resolved. The duties of the
Problem Manager include:
e Accepting a problem
e Logging the problem onto the organisational problem
database, and keeping the database updated
e Brokering prioritisation
e Reviewing solutions
¢ Monitoring progress
¢ Closing problems
The Problem Manager is the only communication channel between the Service
Management teams of the two organisations (ICL Pathway and POCL).
6.3 Problem Resolution Manager:
The person appointed to resolve a particular problem. Responsible for creating a
team, developing a solution, developing an implementation plan, brokering with
interested parties, submitting to the Problem Manager, and to Change Control.
COMMERCIAL IN CONFIDENCE Page 8 of 33
FUJ00119991
FUJ00119991
ICL Pathway ICL Pathway Problem Management Process Ref. CS/PRD/021
Version: 2.0
Date: 26/08/99
7 Problem Management Principles
The following principles have been used in the development of the ICL Pathway
Problem Management process. Changes to the principles may require the review and
revision of the processes detailed within this document.
Problems will be managed by Problem Managers
All Problems will be logged on the Problem Database
All problems on the database must be updated and maintained regularly
Problems will be impacted locally before being raised as a cross-domain problem
Responsibility for the management of a problem must be clearly allocated.
Problems will be prioritised based upon business impact
Closure criteria will be agreed at the start of a problem. Once the problem has
been resolved the criteria will be used to decide when it can be closed.
Where required, the Problem resolution process will be managed to ensure timely
delivery of the solution to the required quality
The escalation of a Problem can occur at any point during the management
process in order to provide a higher degree of management focus
(Authorised) Temporary Procedures may be developed to provide short to medium
term work around solutions whilst a long term solution is prepared
Problems will be closed after the solution has been proved to meet agreed closure
criteria.
A Post Implementation Review can be requested for any problem.
The Problem Manager must inform those impacted by a Problem, or involved in
the resolution process, of the Problem, and keep the parties updated at all times.
COMMERCIAL IN CONFIDENCE Page 9 of 33
FUJ00119991
FUJ00119991
ICL Pathway ICL Pathway Problem Management Process Ref: CS/PRD/021
Version: 2.0
Date: 26/08/99
8 Problem Management Process
The process and procedures used by the Problem Manager to work towards the resolution of a problem will depend upon the type of problem that is being
dealt with. These can be divided into two categories: Internal Problem Management and Cross-Domain Problem Management.
COMMERCIAL IN CONFIDENCE Page 10 of 33
ICL Pathway ICL Pathway Problem Management Process
Ref: CS/PRD/021
FUJ00119991
FUJ00119991
Version: 2.0
Date: 26/08/99
8.1 Problem Assessment Process
1 10 Pa 2
Problem vonage
originated from: Decision to Escalate
itv cL woe > Goa >) seaidea
Panwa problem
2 4
Aseign aProtiem
Problem reported to. —3pl
DM fromPoCl, ‘Manager
{0M}
Dees problem
areadyexst
on database?
3 6 7 ° 10 1
, No obtain Assensprotem No Log problem InormHSH to
Prablem essed ceaistramcal Lp] anadetneciosre Prictise problem [3p ontte Prasion create Master
fromincdent egiralr aera Datatose a ren
nag PM] iPM} PM Are incidents arising PM]
Yes we arecutal te
es amt problem?
Cross-Damain
Contact
ariginator
ASAP,
(PM)
COMMERCIAL IN CONFIDENCE
8
Inform originator of
the existing problem
and update chase
(PM)
Page 11 of 33
implications?
FUJ00119991
FUJ00119991
ICL Pathway ICL Pathway Problem Management Process Ref. CS/PRD/021
Version: 2.0
Date: 26/08/99
8.1.1 Problem Ayesment Description
Process
Step
Actions
Problems can arise from different sources:
a) A problem can arise from within ICL Pathway. For example, via an internal
audit or a Service Review Forum that highlights a problem. This will be
reported to a CS Service Manager who can either assign him/herself as the
Problem Manager, or assign another Service Manager as the Problem Manager.
b) POCL can also report a problem into ICL Pathway. This is reported via the
Duty Manager who will subsequently assign a Problem Manager to progress
the problem on behalf of ICL Pathway.
ce) A problem can also be assigned to a Problem Manager from the Duty Manager
who has made a decision that a potential problem referred via the HSH or one
of ICL Pathway support units, such as the SCC, is a problem.
5,6
Having been assigned a problem, the Problem Manager contacts the originator of
the problem to obtain all the details required to understand the situation and to
make an assessment of what action is required. If the originator is not contactable,
the Problem Manager will only continue with the process if enough information is
available to do so, and contact the originator as soon as possible thereafter. If there
is not enough information to continue, the Problem Manager must wait until
contact has been made with the originator before continuing.
The Problem Manager assesses the problem. This might require contacting the
relevant expert domains that are dealing with the problem, e.g. SSC or OSD, to
learn as much as possible about the problem. This will help the Problem Manager
to determine the appropriate course of action.
The Problem Manager checks to see if the problem has already been recorded on
the Problem database. If the Problem is already being dealt with, the Problem
Manager will inform the originator of the existing problem and provide the contact
details of the Problem Manager who is responsible for the problem.
If the problem does not already exist, the Problem Manager will prioritise it and
record the problem on the Problem database. (see Section 8.5 for prioritisation)
Note: The Problem Manager is responsible for keeping the database updated with
the actions and events taken throughout the life of the problem through to its
closure.
Most problems will arise via the incident management process, so an incident(s)
will already exist for a problem. If there is the potential for more incidents to be
logged with the HSH as a result of a problem, the Problem Manager will inform
the HSH to create a Master Incident. The Master Incident will be used to capture
the volume of incidents arising as a result of the problem. There is the potential for
COMMERCIAL IN CONFIDENCE Page 12 of 33
FUJ00119991
FUJ00119991
ICL Pathway ICL Pathway Problem Management Process Ref: CS/PRD/021
Version: 2.0
Date: 26/08/99
the priority of the problem to be raised if it is found that a high volume of incidents
is arising and a solution is required more urgently.
The Problem Manager will then make a decision as to whether or not the problem
should be dealt with as an ‘Internal’ problem (Section 8.2) or as a ‘Cross-Domain’
problem, i.e. the problem impacts POCL (Section 8.3).
Note:
Escalation — Go to Section 8.4
COMMERCIAL IN CONFIDENCE Page 13 of 33
FUJ00119991
FUJ00119991
ICL Pathway ICL Pathway Problem Management Process Ref: CS/PRD/021
Version: 2.0
Date: 26/08/99
Monitor CP
progress
[PM]
Initiate a CP
[PM]
2 3 14
Internal Ensure proposed Agree an Once devel oped Yes No
problem corrective action update plan with check wability of >)
identified is developed the domain proposal >
[PM] [PM] [PM] sacl
required?
8.2 Internal Problew M ement
COMMERCIAL IN CONFIDENCE
Page 14 of 33
FUJ00119991
FUJ00119991
ICL Pathway ICL Pathway Problem Management Process Ref: CS/PRD/021
Version: 2.0
Date: 26/08/99
Approved? 18 22
Escalate Carryouta PIR
[PM] [PM]
20 21 23
Until fix
developed
Until fix
Agree release Sp] _ Monitor retease
released
schedule of fix
[PM] PM}
development >
Close problem Lo)
[PM]
Ensure
©> implementation of
corrective action
[PM]
COMMERCIAL IN CONFIDENCE Page 15 of 33
FUJ00119991
FUJ00119991
ICL Pathway ICL Pathway Problem Management Process Ref: CS/PRD/021
Version: 2.0
Date: 26/08/99
8.2.1 Internal Problem Management Description
Process I Action
Steps
12 Having prioritised (section 8.5) and logged the problem on the database, and
determined that it is an internal problem, i.e. does not impact POCL, the Problem
Manager ensures that the appropriate expert domain is developing proposed
corrective action.
13 To keep up to date with the development of the proposal, the Problem Manager
will agree an update schedule with the expert domain. The Problem Manager is
then in a position to monitor the progress of the proposal and take action should the
proposal be delayed.
14 Once a proposal has been developed, the Problem Manager will check the viability
of it resolving the problem. If it is not viable, the proposal must be redeveloped.
15 Once a viable solution has been proposed, the Problem Manager decides if a
Change Proposal (CP) [Ref.4] is required in order for the change to be developed
and released. If a CP is required continue to Step 16.
If a CP is not required, the Problem Manager will ensure that the corrective action
is implemented. Go to Step 22.
Requirement for a CP
, 17,I The Problem Manager ensures that a CP is initiated [Ref.5] and monitors its
18 progress through the Change Management process. If the CP is not approved, the
problem will be escalated to aid the resolution process.
19 Once the CP has been approved, the Problem Manager monitors the development
of the fix, ensuring that planned implementation targets are adhered to.
20,21 Once the fix has been developed, the Problem Manager ensures that the release
schedule [Ref.1] developed for the fix meets the requirements of the problem
solution. Satisfied with the release schedule the Problem Manager will monitor its
release into the live environment, to ensure that the expected targets are met.
COMMERCIAL IN CONFIDENCE Page 16 of 33
FUJ00119991
FUJ00119991
ICL Pathway —_ ICL Pathway Problem Management Process Ref. CS/PRD/021
Version: 2.0
Date: 26/08/99
Post Implementation Review and Closure
22 If a review of the resolution of the problem is required, the Problem Manager will
lead a Post Implementation Review (PIR). The review looks at the way the
problem was resolved, from initial problem analysis through to the release of the
problem. Any improvement opportunities arising from the review will be
implemented for future problem resolution.
23 The PIR, if initiated, will be used as the closure authority for the problem. If a PIR
is not used, the problem will be closed when the Problem Manager, in agreement
with any other parties involved in the resolution process, agree that the closure
criteria have been satisfied.
COMMERCIAL IN CONFIDENCE Page 17 of 33
FUJ00119991
FUJ00119991
ICL Pathway ICL Pathway Problem Management Process Ref: CS/PRD/021
Version: 2.0
Date: 26/08/99
8.2.2 Temporary Procedurey
Yes
26
Ensure immediate
segue? Implementation of Initiate aCP b->C)
TP [PM]
[PM]
Yes Yes
Requirment for
a Temporary 25
Procedure Ensure Once developed Yes No
a temporary check viability of >C)
Does aTP Proceso aire Is temporary IsacP
alreadyexst? procedure Is immediate required?
Mable? implementation
required?
COMMERCIAL IN CONFIDENCE Page 18 of 33
ICL Pathway
ICL Pathway Problem Management Process Ref:
Version:
Date:
CS/PRD/021
2.0
26/08/99
FUJ00119991
FUJ00119991
30
Ensure TP is
withdrawn,
[PM]
28
Monitor CP
progress
Pr
Mi]
Ts the 1P
already
implemented?
No
3
Esure
implementation of
TP
[PM]
COMMERCIAL IN CONFIDENCE
Can it stay
until a new
TP is proposed?
Has the TP
‘already
implemented?
Escalate
[PM]
32
Monitor TP
{PM}
Page 19 of 33
Until Problem
resolved
Withdraw
temporary
procedures
{PM}
FUJ00119991
FUJ00119991
ICL Pathway ICL Pathway Problem Management Process Ref. CS/PRD/021
Version: 2.0
Date: 26/08/99
8.2.2.1 Temporary Procedure Description
Process
Steps
Action
24, 25
If a temporary procedure (TP) is in place, the Problem Manager will decide if the
TP is adequate, i.e. does it resolve an incident associated to the problem, and if so,
ensure there are no external impacts associated with the TP. If the TP is adequate,
then go to Step 31.
If the current TP is not adequate, the Problem Manager ensures that an alternative
temporary procedure is developed.
If there is no TP currently in place, the Problem Manager ensures that the
appropriate parties propose a TP.
Once the TP has been proposed, the Problem Manager checks that it allows
associated incidents to be resolved. If not, the proposed TP must be redeveloped.
26
Once the TP is approved, the Problem Manager must decide if the problem
requires that the TP be immediately implemented. If so, the PM ensures that
measures are taken to release the TP into the live environment as soon as possible.
If a Change Proposal is required continue to Step 27, else go to Step 31.
equirement for a CP
27, 28,
29, 30
If the TP requires a Change Proposal (CP), the Problem Manager ensures a CP is
initiated. The Problem Manager will subsequently monitor the CP through the
Change Management process [Ref.5]. If there are any delays, or if the CP is
rejected, the Problem Manager will escalate the problem.
If the CP is rejected, and the TP has already been released due to the nature of the
problem, the Problem Manager must decide if the TP can remain in place until a
new TP is developed and approved, or whether it must be withdrawn.
Implement, Monitor and Close
31,32 I The Problem Manager monitors the development and implementation of the
temporary procedure, ensuring that planned targets are applied to.
33 The temporary procedure is withdrawn in parallel with the release of the problem
solution
Note: Escalation — See section 8.4
COMMERCIAL IN CONFIDENCE Page 20 of 33
FUJ00119991
FUJ00119991
Ref: CS/PRD/021L
Version: 2.0
Date: 26/08/99
ICL Pathway ICL Pathway Problem Management Process
u 35 36
Inform Keep domain ,
Until Problem Inform all that > 4)
‘On. domain Ie updated with = I}-
Ne
of problem progress resolved probl em is sed
[PM] [PM]
8.2.3.1 Internal Communication Description
Process I Action
Steps
34,35, I The Problem Manager communicates with any internal domain that may be
36 impacted by the problem, and keeps them updated with events of the problem
resolution until the problem has been closed. This includes informing the HSH to
close a Master Incident if one had been created once a problem has been closed.
COMMERCIAL IN CONFIDENCE Page 21 of 33
FUJ00119991
FUJ00119991
ICL Pathway ICL Pathway Problem Management Process Ref: CS/PRD/021
Version: 2.0
Date: 26/08/99
8.3 Crosy-Domaw Problem Management
Many problems raised within ICL Pathway will have an impact upon POCL. This section looks at the management of such Cross-Domain problems.
Yes
Is an ATP
required? No
Did problem
originate from ay ° Agree 40 4 a2
POCL? Contact \gree problem closure criteria and
POCL Problem priority with POCL I J>I update schedule [Po Analyse problem [Jey Peineresoluion I yj Agree resolution >)
Mgt team PM with POCL PM {ICL PW PM] CL WPA Mee pw Pan
{ICL PW PM] [ICL PW PM] [ICL PW PM] t 1 t ]
Cross-Domain
problem
identified
Does problem
impact any
internal domains?
COMMERCIAL IN CONFIDENCE Page 22 of 33
ICL Pathway
ICL Pathway Problem Management Process
CS/PRD/021
2.0
26/08/99
FUJ00119991
FUJ00119991
‘Await solution
proposal
Broker and
agree POCL
ICL PW PM}
DoICL have
resolution actions?
44
Ensure a solution
proposal is created
ICL PW PM}
45
Broker and
agree proposal
with POCL PM
{ICL PW PM}
COMMERCIAL IN CONFIDENCE
52
Ensure
implementation of
corrective action
[ICL PW PM]
isacp
required?
y No
Yes
Yes
4a
Initiate a CP vo
{ICL PWPM] nccewem
Page 23 of 33
CP Approved?
No
Escalate
ICL PWPM)
ICL Pathway — ICL Pathway Problem Management Process
Ref:
Version:
Date:
CS/PRD/021
2.0
26/08/99
FUJ00119991
FUJ00119991
Monitor
> development
of fix
ICL PWPM}
L_-»I
50
Until fix
developed
‘Agree Release
Schedule
fic PWPM
61
Monitor release
fix,
{ICL PW PM)
COMMERCIAL IN CONFIDENCE
PIR required?
Until fix
released
Page 24 of 33
bad 54
Until problem
"esohed Initiate PIR Fy Agree PIR with
= rerewen {ICL PW PM]
85 56
Agree problem Close prob
mesure FI pxcbern
flCLPOCL} [lcLiPocl]
FUJ00119991
FUJ00119991
ICL Pathway ICL Pathway Problem Management Process Ref. CS/PRD/021
Version: 2.0
Date: 26/08/99
8.3.1 Cross-Domoiw Problem Management Description
Process I Actions
Step
37,38 I If the ICL Pathway PM (ICL PW PM) has identified a problem that is felt to have
cross-domain implications, the POCL Problem Management team will be
contacted and notified of the problem.
The nominated ICL Pathway and POCL Problem Managers then agree the priority
(section 8.5) of the problem
(Note: If the ICL PW PM has any doubts whether a problem has cross-domain
implications, it should be progressed in accordance with cross-domain procedures
until the situation is clarified.)
If the problem was notified to ICL Pathway by the POCL Problem Manager
(POCL PM), the ICL PW PM will contact the POCL PM to agree the priority of
the problem.
39 The ICL Pathway and POCL Problem Managers decide upon the criteria for
closure. This will be used to assess the proposed solution, and also to agree closure
of the problem.
It is also important that an update schedule is agreed between the Problem
Managers to keep each other informed of progress on a regular basis.
Note: If the Problem Managers decide that an ATP is required, see step 57.
40 The ICL PW PM analyses the problem to understand the resolution requirement
that is needed and to determine which organisation is responsible for developing
and implementing the solution. This may require discussions with the appropriate
expert domains to understand what is required to resolve the problem.
41,42 I The ICL PW PM defines and agrees with the POCL PM the problem resolution
requirements.
If ICL Pathway has no problem resolution actions continue to step 43, else go to
step 44.
POCL responsible for resolving the problem
43 Once a solution proposal has been developed by POCL, agree with the POCL PM
the proposal’s viability. The proposal must provide a technical solution and an
implementation plan. Once agreement has been reached, progress updates should
be communicated via the agreed update schedule until the problem has been
resolved. Go to step 53.
COMMERCIAL IN CONFIDENCE Page 25 of 33
FUJ00119991
FUJ00119991
ICL Pathway ICL Pathway Problem Management Process Ref. CS/PRD/021
Version: 2.0
Date: 26/08/99
ICL Pathway responsible for resolving the problem
44, 45
The ICL PW PM ensures that the correct expert domain is developing a solution
proposal. The proposal must provide a technical solution and an implementation.
plan. Once developed the proposal is brokered with the POCL PM until an
agreement is reached.
If a CP is required [Ref.5] to implement the solution continue to step 46, else go to
step 52.
ICL Pathway with actions to provide resolution to the problem
a) Requirement for a CP
46,47, I The ICL PW PM ensures that a CP is raised to approve the problem solution and
48 monitor its progress through the Change Management process. If the CP is not
approved, the problem will be escalated to aid the resolution process.
49,50, I The ICL PW PM monitors development of the fix, following CP approval. Once
51 the fix has been developed, the ICL PW PM ensures that the release schedule
[Ref.1] developed for the fix meets the requirements of the problem solution, as
agreed with the POCL PM. Once satisfied with the release schedule the ICL PW
PM will monitor its release into the live environment, to ensure that the expected
targets are met.
b) CP not required
52 The ICL PW PM ensures that the correct action is taken to implement the solution.
Post Implementation Review (PIR)
53, 54
Once the fix/corrective action has been implemented and released into the live
environment, a PIR may be requested by either the POCL or ICL Pathway Problem
Managers. Either party can request a PIR in order to review the way the problem
was resolved, and to investigate ways in which the resolution process can be
improved.
If a PIR is not requested, go to step 55.
The organisational Problem Manager that requests a PIR is responsible for
initiating and chairing the review. Therefore, if the POCL PM requested a PIR,
then the POCL PM is responsible for initiating and chairing it.
The review will look at the way the problem was resolved, from initial problem
analysis through to the release of the problem. Any improvement opportunities
arising from the review will be implemented for future problem resolution.
COMMERCIAL IN CONFIDENCE Page 26 of 33
FUJ00119991
FUJ00119991
ICL Pathway ICL Pathway Problem Management Process Ref. CS/PRD/021
Version: 2.0
Date: 26/08/99
Problem Closure
55, 56
If a PIR had taken place, it will be used as the authority to agree closure of the
problem. This will be signed off both the ICL Pathway and POCL Problem
Managers. Both the ICL Pathway and POCL Problem Managers will attach a copy
of the minutes of the PIR to the problem record held on their respective Problem
databases.
If a PIR was not used, the ICL Pathway and POCL Problem Managers agree
closure when the closure criteria have been satisfied. An email from each Problem
Manager will be used as the authority to close the problem.
Once closure has been agreed, the Problem Managers close the problem on their
individual problem databases, and inform all other relevant parties that the
problem has been closed.
When closing the problem record on the problem database, the reasons for closure
must be stated.
COMMERCIAL IN CONFIDENCE Page 27 of 33
ICL Pathway ICL Pathway Problem Management Process
Ref:
Version: 2.0
Date: 26/08/99
CS/PRD/021
FUJ00119991
FUJ00119991
8.3.2 Authorised Temporary Procedurey
58
Decide whois
responsible for
developing ATP
{ICL/ POCL PM]
IsaTP
alreadyin
place? Yes
oT
Authorise TP
as an ATP
[ICL PW PM]
COMMERCIAL IN CONFIDENCE
Is ICL the
ATP resolver?
Until ATP
proposed
60
Ensure an ATP is
proposed
{ICL PW PM]
59
Broker and
agree ATP with
POCL PM
{ICL PW PM]
62
Ensure
implementation of
ETP
[ICL PW PM]
Is ATP
Wable?
6
Broker and
agree ATP with
POCL PM
{ICL PWPM]
Is immediate
implementation
required?
Page 28 of 33
Agree?
Yes
ICL Pathway
FUJ00119991
FUJ00119991
ICL Pathway Problem Management Process Ref. CS/PRD/021
Version: 2.0
Date: 26/08/99
No
66
Is ATP Noy] Ensure arPis
already Tanit stay withdrawn
implemented? until anew: [PM]
ATPis
proposed?
63 64 Spproved? 65
Monitor CP
Initiate CP —>I Escalate
[ICL Pw PM} nL eM {ICL Pw PM}
Yes
68 69
No Yes Withdraw
Monitor and Until Problem
@ Has ATP already > Control TP) "vesolved sempre >
IsacP been implemented [ICLIPOCL PM] fcupoct}
required? as an ETP?
67
Until ATP
implemented
Esure
implementation of
ATP
ICL PW PM]
COMMERCIAL IN CONFIDENCE
Page 29 of 33
FUJ00119991
FUJ00119991
ICL Pathway ICL Pathway Problem Management Process Ref. CS/PRD/021
Version: 2.0
Date: 26/08/99
8.3.2.1 Authorised Temporary Procedures Description
57, 58
If a Temporary Procedure (TP) is not already in place then the ICL PW PM
decides with the POCL PM which organisation is responsible for developing an
Authorised Temporary Procedure (ATP).
If a TP is already in place, it must be decided if the TP can be used an ATP. If not
a new ATP must be developed with POCL and ICL Pathway agreeing who is
responsible for developing the ATP.
If the TP can be used as the ATP then it will be authorised as an ATP. Go to Step
68.
If a new ATP needs to be developed and ICL Pathway is the nominated ATP
developer go to Step 60, else continue to Step 59.
POCL responsible for developing the ATP
59
If ICL Pathway is not the nominated ATP developer then the ICL PW PM awaits
the ATP proposal from POCL. Once agreement for the proposal is reached, POCL
will take action to implement and release the ATP into the live environment. Go to
Step 68.
ICL Pathway responsible for developing the ATP
60, 61,
62
The ICL PW PM ensures an ATP is proposed. This may require enlisting the help
of an expert domain to help decide the action that needs to be taken.
Once a viable proposal has been developed, the ICL PW PM brokers and agrees it
with the POCL PM.
It must then be decided whether or not the ATP needs to be implemented
immediately. If immediate implementation is required, the ICL PW PM must
ensure that the ATP is implemented as an Emergency Temporary Procedure
(ETP).
Note: The Emergency procedure will be classified as an ATP once it has been
brokered with POCL and, where required approved via a Change Proposal.
63, 64,
65, 66
If the ATP requires a Change Proposal (CP), the ICL PW PM ensures a CP is
initiated. The ICL PW PM will subsequently monitor the CP through the Change
Management process [Ref.5]. If there are any delays, or if the CP is rejected, the
ICL PW PM will escalate the problem.
If the CP is rejected, and the ATP has already been released (as an ETP) due to the
nature of the problem, the Problem Manager must decide if the ETP can remain in
place until a new ATP is developed and approved, or whether it must be
withdrawn.
Implement, Monitor and Close
COMMERCIAL IN CONFIDENCE Page 30 of 33
FUJ00119991
FUJ00119991
ICL Pathway ICL Pathway Problem Management Process Ref. CS/PRD/021
Version: 2.0
Date: 26/08/99
67,68 I The ICL PW PM monitors the development and implementation of the ATP,
ensuring that planned targets are applied to.
69
Once the problem has been resolved, the ICL PW PM ensures that the ATP is
removed in a co-ordinated manner with the release of the problem fix.
Note: Escalation — See section 8.4
COMMERCIAL IN CONFIDENCE
Page 31 of 33
FUJ00119991
FUJ00119991
ICL Pathway ICL Pathway Problem Management Process Ref. CS/PRD/021
Version: 2.0
Date: 26/08/99
8.4 Exalation
Process
Steps
Action
70
At any time during the Problem Management process, whether the problem is
being resolved as a cross-domain problem or as an internal problem, the Problem
Manager can escalate the problem to the next level of management.
The process of escalation is intended to bring increasing levels of management
attention and/or expertise to bear upon the resolution of a Problem. Escalation
should be considered to be an exceptional resort.
Escalation to a higher level will normally occur either:
e when an issue is causing increased concern through time delay and consequent
impact, or
e when it has not been possible to reach agreement on some aspect of the
definition or management of the issue
71 Escalate the problem to the next level of management
Note: If a cross-domain problem is being escalated, the ICL PW PM must ensure
that the POCL PM is informed of the escalation so that escalation can take place
within POCL to the same level.
72 The ICL Pathway Problem Manager will continue to manage the escalated problem
through to its resolution, acting as the interface between the higher levels of
management now involved via escalation and those who were already involved in
the problem resolution.
COMMERCIAL IN CONFIDENCE Page 32 of 33
FUJ00119991
FUJ00119991
ICL Pathway ICL Pathway Problem Management Process Ref. CS/PRD/021
Version: 2.0
Date: 26/08/99
8.5 Problem Pricrituetion
The prioritisation categories are as follows:
‘A’ Priority Problems that directly impact, or have the potential to directly
impact, POCL’s customers and clients.
‘B’ Priority Problems that impact, or have the potential to impact, PO outlets
‘C’ Priority POCL systems / ICL Pathway
The above priorities will be used to provide an initial priority to a problem upon its
identification. It is this priority that will be logged upon the problem database when
the problem is first entered into the system.
Once the problem is investigated and analysed more fully, if required, the priority of
the problem can be raised or lowered.
Note:
If the priority needed changing for a cross-domain problem, i.e. a problem that
impacts both ICL Pathway and POCL, the change must first be agreed with POCL.
General Priority Principles
Below is a guide to help understand the general priority principles.
Priority Interpretation
A Major impact, fix required for urgent implementation
B Significant impact, fix required
Cc Varied impact, consider fix or monitor
COMMERCIAL IN CONFIDENCE Page 33 of 33