FUJ00079797
FUJ00079797
ICL Pathway ICL Pathway Problem Management CS/PRD/021
Process 35705198
Document Title: ICL Pathway Problem Management Process
Document Type: Process Description
Abstract: This document defines the ICL Pathway Problem
Management Process and its interactions between ICL
Pathway’s suppliers and customers.
Status: Authorised
Distribution: ICL Pathway Customer Service,
HSH - Andy Muse
HSH - Larry Cotterell
PCHL - Dave Wilson
CFM - Dave Campbell
SMC - Derek Miles
SMC - Sharon Towes
Library
Author: Evandro Manolas
Comments to: Author
Comments by:
COMMERCIAL IN CONFIDENCE Page 1 of 37
© 1997 ICL Pathway Ltd
FUJ00079797
FUJ00079797
ICL Pathway ICL Pathway Problem Management oSIPRDI021
Process 25/05/98
0 Document control
0.1 Document history
Version Date Reason
1.0 05/11/97 ICL Pathway Problem Management Process
1.4 16/4/98 Update
0.2 Approval authorities
Name Position Signature Date
Paul Westfield
Peter Burden
Martin Riddell
Mik Peach
0.3 Associated documents
Reference Vers Date Title Source
1 CS/PRO/0044 1.0 21/10/97 ICL Pathway Problem Management Pathway
Structure
2 PA/PRO/014 2.1. 21/01/98 PinICL Incident Management Process Pathway
3 CS/FSP/005 0.1 16/09/97 Horizon System Helpdesk Incident Pathway
prioritisation
4 PA/PLA/O003 0.6 29/07/97 Disaster Recovery Plan Pathway
5 HH/PRO/011 1.0 30/05/97 Horizon System Helpdesk Call Routing CFM
Table
6 4.0 July‘97 ICL Customer Red Alert Handbook ICL Grp
7 PDA/SVM/ 2.0 10/10/97 SCoP - Service Code of Practice for PDA
CP /001 Help Desks in the Card Environment.
(Currently under revision)
8 Service 0.3 23/07/97 Incident and Problem Management PDA
Management/
INCPROB.doc
9 PDA/SVM/PM/ 1.1 17/9/97 Problem Management in the PDA PDA
001
COMMERCIAL IN CONFIDENCE Page 2 of 37
FUJ00079797
FUJ00079797
ICL Pathway ICL Pathway Problem Management oSIPRDI021
Process 25/05/98
0.4 Abbreviations
0.5
BA
DM
CAPS
COLS
COPS
HSH
IS&P
ITSA
OOH
OSM
PCHL
PDA
PIR
PM
POCL
PRCS
PSM
RHD
SCoP
SLA
SMC
SPOC
TSA
Benefits Agency
Duty Manager
Customer Accounting & Payment Strategy
CAPS Operations and Live Support
CAPS Operational Support
Horizon Systems Helpdesk
Information Systems & Process
Information Technology Services Agency
Out of Hours
Operational Service Management
Payment Card Helpline
Programmes Delivery Authority (now known as PSM)
Problem Investigation Review
Problem Manager
Post Office Counters Limited
Payments Repository Computer System
POCL Service Management
Regional Helpdesk
Service Code of Practice
Service Level Agreement
System Management Centre
Single Point of Contact
Technical Support Advisor
Changes in this version
- Version 1
COMMERCIAL IN CONFIDENCE
Page 3 of 37
FUJ00079797
FUJ00079797
ICL Pathway ICL Pathway Problem Management oSIPRDI021
Process 25/05/98
0.6 Table of content
1
2
3. Distinction between an ‘Incident’ and a ‘Problem .
4. ICL Pathway Incident to Problem Management Process Flowchatt............ 8
4.1 Explanation of the Incident to Problem Management Process ......... 9
5. Problem Sources.
5.1 The PSM group (formerly the PDA
6. Deciding whether a problem exists...............0...ccecceeee eect eeeeeeeeeeeeeeeeeeeeeeees
7. The Problem Management Process Flowchaft...............0.::ccccseeeeeeeeeeeeee V4:
7.1 The Problem Management Process. .............0.:::ccceeeeeeeeeeeeeeeeeeeees 15
8. The Duty Manager.
8.1 The Duty Manager Role
8.2 Evening/weekend Shift Proposal.................:c::cecceceseeseeseseeeeeeeeeseeee 19
8.3 Duty Manager Change OVED..............::ccceceseeseeseneeseeseeeeeeeseeeeseeseeeees 19
9. The Problem Managel..............:.:ccccceceeececeeeseeeseeeeeeeeeeseeeeeeeseseeeeseeeeeeeees 20
10. The Problem Manager Database..
10.1 Advantages of the database
10.2 Keeping the Database Updated... eecececeeeeeeeeeeeeneeeeeeeeee 23
10.3 Problem Management Priorities........0.........ceeeeeeeteeeeeeeeeeeeeeneeeees 24
11. The Escalation Process...
11.1 Escalation Internally..
11.1.1 Escalation for Actio
11.1.2 Escalation for Information. ............-:ccceeeeeeeeeeenereeeeeeee 26
11.2 Escalation Externally.........0...cccccceccececceeeseeeeseeeceeeeeeseeseeeeseneeeeeaeenes
11.2.1 Escalation for Action
11.2.2 Escalation for Information.
11.3 Escalation Call Matrix
COMMERCIAL IN CONFIDENCE Page 4 of 37
FUJ00079797
FUJ00079797
ICL Pathway ICL Pathway Problem Management oSIPRDI021
Process 25/05/98
Appendices
Appendix 1 Escalation Levels... ccecececceeeeceeeeeeeeeeeeceeeeeeeeeseeeeeneeeeeeees 31
Appendix 2 Contact points..
Appendix 3 HSH Key Words..
Appendix 4 Escalation Matrix Example.
Appendix 5 HSH Incident to Problem Management Approx. Time Scales..... 35
Appendix 6 Terms of Reference for Duty Managet...................:::ceeeeeees 36
Appendix 7 ICL Pathway Service Manage?s..............:.::::::csceseseeeeeeeeeeeeeeeees 37
COMMERCIAL IN CONFIDENCE Page 5 of 37
FUJ00079797
FUJ00079797
ICL Pathway ICL Pathway Problem Management oSIPRDI021
Process 25/05/98
1 Introduction
Problem Management within ICL Pathway is a growing area. The current
Problem Management Process now needs updating to take account of
Problem Management developments within ICL Pathway, and to prepare for
problems that will occur in the future once roll-out begins. The problems need
to be managed effectively and efficiently, and the process needs to take
account of the increasing number of problems.
The document also takes into consideration the PDA Service Code of
Practice for Help Desks in the Card Environment (known as SCOP). The
SCOP ‘....serves to describe the services involved in the Card Payment
environment for Release 1c, their roles and responsibilities and the way they
interact with each other. This document (SCOP) also gives an overview of
the procedures for incident and problem management and the escalation
process.’
- SCOP Version 2.1, P9, Para 1.1
2 Scope
This document defines how Problem Management within Pathway is
presently initiated, looking at the processes that take place until the
resolution of a problem. The baseline will be used to develop future Problem
Management.
Key areas include:
1. The change over from Incident Management to Problem Management, and
the role of the Duty Manager within this process.
2. A high level view of the Problem Management Process.
3. The introduction of a Problem Management Database to capture the
growing number of problems.
4. The Escalation Process. When escalation should take place. Who should
be escalated to.
Incident
Management
v
No Yes
Possible
«Kk problem Duty Management Problem Manager
Problem
Management}
Database
I Escalation
I Management
COMMERCIAL IN CONFIDENCE Page 6 of 37
FU.
ICL Pathway ICL Pathway Problem Management oSIPRDI021
Process 25/05/98
3
Distinction between an ‘Incident’ and a ‘Problem’.
Incident
Definition of an “Incident”
Source: PDA Service Management - Service Code of Practice
Ref: PDA / SVM/ CP / 001
Version 2.1, Page 11. Paragraph 4.3.2.1
“Incidents” - are individual day to day faults or failures in equipment, software,
services or procedures. These are generally raised by users and / or
customers at an operational level and managed via a framework of function
specific Help Desk services. Each event will require the further identification of
a specific solution or authorised temporary procedure to resolve it. Individual
incidents may be escalated for ACTION or INFORMATION. Once a solution
or authorised temporary procedure has been applied or accepted the
individual incident will be closed. An incident or series of related incidents may
give cause for a wider concern and be symptomatic of an underlying problem.
Problem
Definition of a “Problem”
The SCOP provides a generic definition for the PDA, Pathway, BA, ITSA and
POCL.
Source: PDA Service Management - Service Code of Practice
Ref: PDA/ SVM/ CP / 001
Version 2.1, Page 12. Paragraph 4.3.2.2
“Problems” - are typically matters of concern with wider implications for the
overall service environment. These might be highlighted through operational
experience, research or trend analysis of Help Desk incidents. A problem will
often have fundamental implications (either actual or potential) for the larger
community of users and/or customers. Incidents may be symptomatic of
problems. For example, the application of an interim authorised temporary
procedure could enable the closure of an incident, but management of the
underlying problem would be concerned with developing a permanent
solution.....
COMMERCIAL IN CONFIDENCE Page 7 of 37
FUJ00079797
IJ00079797
FUJ00079797
FUJ00079797
ICL Pathway ICL Pathway Problem Management oSIPRDI021
Process 25/05/98
4 ICL Pathway Incident to Problem Management
Process
In order to establish the Problem Management Process it is first necessary to
understand the Incident Process that may eventually lead to the Problem
Management Process being invoked.
COMMERCIAL IN CONFIDENCE Page 8 of 37
FUJ00079797
FUJ00079797
ICL Pathway ICL Pathway Problem Management CS/PRD/021
Process 12
25/05/98
Call to
HSH L \ No
Incident i >< Trend?
J 4.4.4 Yes
v
Ys ON “No
A “A S S Continue
‘Assign ‘A’ priority €————< Kay Word 7 Problem? _ Monitoring
J h 12 I No Yes 415
L \ A Problem
Inform Duty ><A Priority Inform Duty Management /
Yes Manager “Level? lanager Flowchart I
\ No >
L___ 4.15
Inform
Duty Manager
4434 413.28
Yes teita yO sla target S > Clear Incident
Problem? “exceeded? ~~
J No
Y
Resolve as an Inform Dut chosen”.
incident “Manager ‘Complete
4434 413.213 [res 4.
oe
Problem I
> Management Close incident <<!
Flowchart
14.1.4
COMMERCIAL IN CONFIDENCE
Page 9 of 37
FUJ00079797
FUJ00079797
ICL Pathway ICL Pathway Problem Management oSIPRDI021
Process 25/05/98
4.1 Explanation of the Incident to Problem Management Process
4.1.1 Calls logged at HSH
All calls that come through to HSH are logged as incidents. The priority level
of the incident is then determined by HSH having extracted as much
information as they can from the caller. Calls can be logged as either A, B, C
or D priority calls. Generally, C and D priorities arise from internal sources
only.
4.1.2 Key words
To help the HSH operator determine whether a call is escalated to the Duty
Manager (See Section 8 for the role of the DM), a set of key words have been
developed (Appendix 3). If any of these key words are mentioned by the
caller then the call is assigned an ‘A’ priority code and the DM will be
contacted via the pager (Pager 01893-271678). If a key word is not used then
the call matrix will be used to determine the priority. Reference 3 lists the
priorities assigned to calls received at the HSH.
Note: The use of key words is a temporary measure until the HSH call matrix
and routing tables are fully populated and functional.
4.1.3 Priorities
4.1.3.1 ‘A’ priority
When an incident is set as an ‘A’ priority, then most of the time the DM is
informed of the incident. (Exceptions to this are ‘A’ priorities assigned to Post
Office Hardware calls. In these instances the designated routing table is
followed.) The DM then decides whether or not the incident is a problem (see
Section 6) or should be handled through the normal ‘A’ priority channels. If it
is regarded as a problem the Problem Management process is started (See
Section 7).
If the ‘A’ priority is not regarded as a problem but a resolution can not be
reached within the agreed SLA targets then the Duty Manager is again
informed and Problem Management may be invoked.
Note: As with the use of key words, once the HSH call matrix and routing
tables have been fully populated, only specific ‘A’ priority calls will result in
the DM being contacted.
4.1.3.2 ‘B’ priority
If an incident is classed as a ‘B’ priority incident, Problem Management is
only called upon if no resolution can be implemented within the specified ‘B’
priority SLA targets.
4.1.3.3 ‘C’ and ‘D’ priority
Generally, no incident should be classed as a ‘C’ or ‘D’ priority if there is any
chance of Problem Management being established. Any ‘C’ or ‘D’ priority
incidents should be worked on until they are cleared.
Note: There are no SLA’s_ in place at present for ‘C’ or ‘D’ priorities.
However, when SLA’s are put in place then Problem Management could
COMMERCIAL IN CONFIDENCE Page 10 of 37
FUJ00079797
FUJ00079797
ICL Pathway ICL Pathway Problem Management oSIPRDI021
Process 25/05/98
4.1.4
4.1.5
4.1.6
be instigated if the SLA’s are broken.
Clearance
Once an incident has been resolved it is then cleared, however, it is not
necessarily closed. For example, a Post Office that is down may have a
temporary fix put in place in order for the Post Office to run again, in which
case the incident is cleared. However, the incident will not be closed until the
underlying cause has been corrected.
Trends
One other way the Problem Management Process can be invoked is through
the establishment of incident trends. For example, if a number of incidents
are showing to be of similar nature and coming from the same source, then
there might be a common fault that has not yet been highlighted. This would
therefore need to be investigated with a view to starting off the Problem
Management Process.
It is the responsibility of the Senior TSA to identify trends and to flag the
awareness of them to the Duty Manager.
Time Scales
The above process seems to take us through a long time delay. However, as
Appendix 6 shows, the process from logging an incident to an incident
becoming a problem is not very long.
Note: Appendix 5 shows approximate times for the immediate escalation of
an incident to Problem Management.
COMMERCIAL IN CONFIDENCE Page 11 of 37
FUJ00079797
FUJ00079797
ICL Pathway ICL Pathway Problem Management oSIPRDI021
Process 25/05/98
5 Problem Sources
5.1 Internal and external sources
A problem can derive from a number of sources . These can be internal to
Pathway and external. The following sources have been identified:
De La Rue
POCL (inc. outlets & RHD’s)
BA (via ITSA)
Oracle (via SSC)
Energis (via CFM)
Royal Mail
CFM
SSC
PCHL
HSH
Pathway internal
If any of the above sources wish to raise a problem, then they must first log
the call with the Horizon System Helpdesk.
If a supplier has a problem that they wish to raise with Customer Service, it
should first be registered with the HSH. The next point of contact should then
be the Service Manager, or the DM if the Service Manager is unavailable.
(Appendix 8 lists Pathway Service Managers)
If a customer has a problem to raise with the Customer Service Department
then the DM will be the first point of contact after the call has been registered
with the HSH.
Conversely, points of contact with the above sources also need to be clarified
so that Pathway know who to contact when a problem needs escalating
externally. If the supplier has a CS Service Manager, then the Problem
Manager should first contact the Service Manager rather than going straight
through to the supplier. The Service Manager will then decide whether he/she
or the Problem Manager will contact the supplier.
(See Appendix 2 for known contact points)
COMMERCIAL IN CONFIDENCE Page 12 of 37
FUJ00079797
FUJ00079797
ICL Pathway ICL Pathway Problem Management oSIPRDI021
Process 25/05/98
5.1.1.1
5.1.1 POCL Service Management (PSM)
(formerly known as PDA Operational Service Management)
PSM play an important part within Problem Management. They are informed
of all problems that have an impact on customer organisations outside of
Pathway, and act as the point of contact for POCL and currently the BA. It is
therefore worthwhile spending a little more time explaining the problem links
with them.
PSM contacting Pathway
Currently, PSM sometimes report problems directly to the Customer Service
department without reference to an HSH incident call number. In order to
provide a clear audit trail, PSM must reference their problems to an HSH
incident call number. Therefore, in future, when PSM call with a problem that
isn’t linked to a incident number, then they should be asked to provide one
before registering the problem.
5.1.1.2 Cross Boundary problems
Also, as mentioned in SCoP (Page 16, Paragraph 4.8.3.2), the PDA [now
PSM] will be made aware of cross-boundary problems. Therefore if, for
example, the ITSA Help Desk logged a call with HSH that was viewed as a
problem, they will also contact the PDA.
When it is necessary to contact PSM about a known problem, then the PSM
problem owner should be contacted, and the PSM reference number quoted.
5.1.1.3 Pathway contacting PSM
If a new problem is to be reported to PSM, then any member of the team can
be contacted. Once a new problem has been reported, a PSM problem
reference number will be issued. This should then be used for all future
communication relating to that specific problem.
Details of any PSM problem can be obtained from the PSM Database
Controller. The Database Controller is based in Newcastle where the PSM
Problem Management Database sits.
The Database Controller issues weekly updates on all PSM problems, of
which a copy is sent to the ICL Pathway Service Management team.
(DN: As of the 1* June, the BA arm of PSM will integrate into the DSS as
part of the COLS team. However, for the short term all BA problems will
be reported to PSM who will relay back to the BA. Any future changes
will be reflected in this document)
COMMERCIAL IN CONFIDENCE Page 13 of 37
FUJ00079797
FUJ00079797
ICL Pathway ICL Pathway Problem Management oSIPRDI021
Process 25/05/98
6 Deciding whether a problem exists.
When a possible problem is received by a Duty Manager or someone within
the Service department, then a decision has to be made as to whether a
problem exists or not. To help decide the following areas should be
considered:
Areas of I Explanation
Consideration
Business Impact @ Are there any reconciliation implications?
™@ Is there any adverse publicity on Pathway?
™@ Are there any possible effects upon the
Release dates?
Time Scales ™@ How long would it take to resolve the situation
given current resources?
Customer ™ How dissatisfied are the customers and how
Dissatisfaction widespread is the dissatisfaction?
Breadth of Problem ™@ Does the incident cover a small area, i.e. less
than 10 Post Offices, or is the problem more
spread i.e. a whole region?
Cost @ What is the cost to Pathway in order to resolve
the incident? Would it greatly impact Pathway
financially - does it have any effect on
Pathway’s budget?
Complexity ™@ What resources are required to resolve the
incident?
™ Does resolution require input from a number of
sources, possibly including external
resourcing?
Security ™ Does the incident have any _— security
implications?
Impact on other] ™ Will the incident impact other organisations
organisation such as BA or POCL. If so then they need to be
informed
If the DM is in doubt as to whether an incident is a problem, then the incident
should be resolved as problem.
COMMERCIAL IN CONFIDENCE Page 14 of 37
FUJ00079797
FUJ00079797
ICL Pathway ICL Pathway Problem Management CS/PRD/021
Process 12
25/05/98
7 The Problem Management Process Flowchart
Pager! I
phone E >,
Possible problem ou teta XS “tmmediate Xe* bears inaad
problem? action? {DM
No I No 712
PROBLEM MANAGER
RO v
Enter details on
Treat as an to Problem Agree action plan Yes
[HSH] Database [PM/Orig] PM
[DM '
fra J 742! KR Tiss ‘ 7.1.8
DUTY MANAGER Inform relevant
BODE SAGER Assign Problem I La) secre eyes I Af) Aves role Implement acon
— ce if necessary [PM] Lar
(eM (PM emi
714 Khas 7.19
v.
Keep originator .
notified at all C pga? >
Wied at Progress
(PM
I Ce Wl Yes
Problem
Investigation ¢ I Clearincident Ig Le Resovedto
Review [HSH] originators
(PM) ‘agreement?’
I raat TAO
COMMERCIAL IN CONFIDENCE Page 15 of 37
FUJ00079797
FUJ00079797
ICL Pathway ICL Pathway Problem Management oSIPRDI021
Process 25/05/98
7.1
Explanation of the Problem Management Process Flowchart
Once a ‘problem’ has been recognised through the Incident Management
Process then the Problem Management Process is started.
The Duty Manager
Having diverted a call through its normal incident route (see ref: “Horizon
System Helpdesk Call Routing Table’, Version 1.0, 30/05/97, for further
information on routing), the HSH will inform the DM of the possible problem.
On receipt of a possible problem from the HSH, the DM will find out the
details of the incident and possibly make initial phone calls to the support
units to help decide whether the incident requires ‘problem’ status. For
example, there may be a situation where an ‘A’ priority deadline is
approaching, but a resolution is in place that will take perhaps 30 minutes to
an hour over the deadline. Would it be necessary to start off the Problem
Management Process? As long as the parties concerned are all aware of the
situation, and all in agreement, then the Problem Management Process can
be avoided. If a potential problem is decided not be a problem, then the
normal incident path is followed.
Once the DM has decided to action the Problem Management Process, all
parties concerned will be informed. For example, if the call came in from
ITSA, then ITSA will be informed that the Problem Management Process has
been initiated.
Database recording
Having decided that a problem exists the problem will then be recorded on
the Problem Management Database (See Section 10). If an ‘Out of Hours’
Duty Manager has responded to the call then the problem will be recorded at
the earliest opportunity. It may also be the case that the Duty Manager must
act on the problem straight away and does not have time to enter the details
immediately on to the database. If this is the case then the details should be
entered at the next available opportunity.(For more information on the
Problem Management Database process refer to Section 10)
Appointment of Problem Manager
After deciding that a problem exists the DM will appoint the Problem Manager
most capable of handling the problem. For example, any problems with the
Payment Card Help Line should be managed by PCHL Service Managers. If
they are unavailable or unable to manage the problem, then the DM will
escalate the problem to the appropriate Customer Service Manager who will
then help to decide who the Problem Manager will be. (Please see Section 9
for the role of the Problem Manager)
Inform Service Manager
If the problem has any cross-boundary implications then the Problem
COMMERCIAL IN CONFIDENCE Page 16 of 37
FUJ00079797
FUJ00079797
ICL Pathway ICL Pathway Problem Management oSIPRDI021
Process 25/05/98
Manager, who may not necessarily be the Service Manager, will inform the
relevant Service Manager of the situation.
Assessment of the Problem
The PM will contact the assignee of the problem i.e. SSC or CFM, to gather
as much information about the problem as possible. If the PM does not know
who was assigned the problem, then the information can be retrieved from the
HSH.
Agree Action Plan with the originator
Having gleaned as much about the problem as possible in the time available,
the PM will agree a course of action with the originator. This will include
update intervals , deadlines and, if necessary, agreed escalation levels.
Keeping Originator notified
It is imperative that the originator is kept informed about the problem at all
times and not kept in the dark. This may be done pro-actively, through agreed
regular update intervals, or re-actively when an unexpected twist occurs and
the originator needs to be informed.
Escalation
If escalation is necessary the PM will escalate to the appropriate level. (See
Section 11 for more details on escalation)
Implement Action Plan
Following discussions with the originator the PM will implement the agreed
action plan. It may be just a co-ordinating role, or it may just require updating
the originator through the agreed times.
If no progress is being made and it is found that the agreed deadlines are not
going to be reached then the problem should be escalated. If necessary this
process is continued to the highest level of escalation.
7.1.10 Problem Closure
When the problem has been resolved to the satisfaction of all parties then the
problem/incident can be cleared and closed. Once the HSH have closed the
original incident the related problem can also be closed by the PM on the
Problem Management Database
If the problem is not resolved to the satisfaction of all concerned parties, then
it is necessary to find out why and to restart the Problem Management
Process.
7.1.11 Problem Investigation Review
Following the resolution of a problem the PM should carry out a review of the
problem in order to understand what went wrong to cause the problem, and
what is to be done to stop the problem re-occurring. The same problem
should not occur again. This information should be entered into the database
upon closure of the problem. (For more information on PIR refer to section
COMMERCIAL IN CONFIDENCE Page 17 of 37
FUJ00079797
FUJ00079797
ICL Pathway ICL Pathway Problem Management oSIPRDI021
Process 25/05/98
9.1.6)
Important: Throughout the life of a problem, the PM must keep the Problem
Management Database updated at all times to reflect the latest situation.
COMMERCIAL IN CONFIDENCE Page 18 of 37
FUJ00079797
FUJ00079797
ICL Pathway ICL Pathway Problem Management oSIPRDI021
Process 25/05/98
8 The Duty Manager
The daily Duty Manager role will be undertaken by Service Managers in
Customer Service Operations between the hours of 0800-1800 Monday to
Friday and will be contacted on the Duty Managers pager.
The OOH (Out of Hours) Duty Manager role will cover ALL other hours (1800-
0800 Monday-Friday and 1800 Friday to 0800 Monday)
CalltoHSH) incident Assign Problem
Incident 0g incident Manager
MSH] [DM
v a
Resolve as an le No Possible Problem lx
incident Management
[HSH] problem? [CS/PRDIO21)
Yes
vy v
No
Pager the Duty origina
ger the riginator
tanage satisfied?
Yes
v v
Pass on call no.
& call details to Close call
OM HSH
[HSH]
v
No Yes
sita
problem?
8.1 Duty Manager Role
™ Whenever the HSH receive a call that is perceived as a possible problem
the Duty Manager is paged. On being paged the DM contacts the HSH to
find out all the details of the call and the call number. The DM then decides
if the call is a problem. If not then it will be dealt with through the normal
incident management guidelines.
Note: If the DM can not be contacted, then the HSH should call a member
of the Pathway Service Management team.
COMMERCIAL IN CONFIDENCE Page 19 of 37
FUJ00079797
FUJ00079797
ICL Pathway ICL Pathway Problem Management oSIPRDI021
Process 25/05/98
8.2
8.3
@ If it is a problem then the DM will initiate the Problem Management
process. This starts by logging the call on to the Problem Management
Database and assigning a Problem Manager to the problem (this could
even be the DM). The Problem Management Process is then implemented.
Once the problem is resolved to the originators approval the HSH will
close or clear the call.
Evening / weekend Shift proposal
™@ It is proposed that there will be one mobile phone for the evening /
weekend DM. Therefore, even if it is not known who the DM is, by ringing
the one number, the DM on duty will always be contactable.
™@ The duties of the ‘out of hours’ DM will be the same as the daily DM.
However, it is envisaged that they will be involved more as Problem
Managers due to the hours they will be working and the fewer number of
personnel being available as Problem Managers.
Duty Manager Change Over
™@ It is proposed that if a DM who is about to end their shift has any
outstanding problems or issues, then these should be passed on to the
relieving DM. The main reason for this is to avoid confusion as to who to
contact if two DM’s are on at the same time. Also, the resolution to a
problem might not be foreseeable in the near future and it is therefore
more practical for a DM to hand over an issue rather than see it through.
™@ The relieving DM will be contacted via the DM mobile phone if an ‘out of
hours’ DM, or paged if a ‘working day’ DM.
Note: For the DM Terms of Reference see Appendix 6
COMMERCIAL IN CONFIDENCE Page 20 of 37
FUJ00079797
FUJ00079797
ICL Pathway ICL Pathway Problem Management oSIPRDI021
Process 25/05/98
9.1
The Problem Manager
The role of the Problem Manager (PM) is to co-ordinate the resolution of a
problem.
Duties
The Problem Manager will be appointed by the DM after an incident call has
been identified as a problem.
He/she will act as the point of contact for everyone involved with the problem.
Assess problem
Having been assigned a problem, the Problem Manager will contact the
parties that have been assigned with the problem. Amongst others, this might
be SMC, SSC or CFM. It is the responsibility of the PM to obtain all the
information that is necessary in order to help develop a plan of action.
Agree course of action with originator
Having assessed the problem, the PM can agree a course of action with the
originator. The plan should include time scales and, if necessary, escalation
procedures.
The time scales will encompass regular updates to the originator and a
proposed deadline for the problem to be resolved.
If escalation is required then the PM will make sure that all parties on the
escalation ladder are informed (See Section 11). The PM should also
escalate to the same level that the problem originator has escalated to.
The agreed action plan should also look to develop a plan of ‘corrective
action’ to ensure that the problem is not repeated.
Update problem on Problem Management Database
All events relating to the problem should be captured onto the Problem
Management Database which will already have a record of the problem set
up in it. The Problem Manager will regularly update the database as
necessary so that the latest events are always depicted for anyone enquiring
on the problem.
Keeping all parties aware
Many parties / ‘expert domains’ (internal to Pathway or external) may be
involved in the resolution of a problem. The Problem Manager is responsible
for obtaining updates from all the parties, and also to keep the parties aware
of the latest events. It could be compared to leading a team with everyone
having the same objective and working towards the same goal i.e. the
resolution to a problem.
If it is recognised that the resolution of a problem is going to exceed it’s
deadline date, the Problem Manager will discuss with the originator a new
course of action. Again, this might require escalation.
Seeking originators approval
COMMERCIAL IN CONFIDENCE Page 21 of 37
FUJ00079797
FUJ00079797
ICL Pathway ICL Pathway Problem Management oSIPRDI021
Process 25/05/98
10
Once a problem has been resolved the Problem Manager will check that the
originator agrees with the solution. If the originator does not agree that the
problem has been resolved satisfactorily, then the PM must sort out the
problem with the originator, and if necessary, agree a new course of action.
The above process is then repeated.
[DN: If an agreement can not be reached then an arbitration route
should be available to resolve any dispute. This is to be developed for
the next issue]
Problem Investigation Review
Having resolved a problem, the PM should carry out a Problem Investigation
Review (PIR). This is necessary for a number of reasons:
@ An understanding as to why the problem occurred.
™@ To determine whether the problem was resolved as efficiently as
possible.
™ Could anything have been done to resolve the problem more
quickly?
@ Were the correct resources used?
@ Were the right people involved and informed?
@ Was the problem originator happy with the way the resolution was
reached?
The Problem Manager should comment on the following areas, and attach the
comments in to the database problem on closure of the problem.
@ What was the problem;
™@ Reason for the problem;
™@ Action taken to resolve the problem;
™@ What actions have been taken to stop the problem from re-occurring;
@ Any other comments.
Note: A PIR can also be called by the originator. For example, if CAPS had
raised a problem they might arrange a meeting, with those involved in the
resolution of the problem, to understand what went wrong and what has been
done to stop it happening again. The details of such a meeting should then
be linked into the database.
Close problem
Once a problem has been resolved to the originators agreement, and the
originator agrees that it can be closed, the HSH will close the related incident
on the Powerhelp system. The PM will close the problem on the Problem
Management Database.
The Problem Management Database
COMMERCIAL IN CONFIDENCE Page 22 of 37
FUJ00079797
FUJ00079797
ICL Pathway ICL Pathway Problem Management Cs/PROIO21
Process .
25/05/98
Ne Resolve out of the
problem? ><Does a problem > erobiom mat
° \ exist? process.
~ Yes
Y
“immediate °° pp) Take immediate
action? _ action
No
Ww
Enter details on to
Prob. Mgt D'base
[DMics}
Vv,
[Problem /
I Management
Database I
a
we
[ICL Problem /
I Management
I Process
I [CS/PRDI021]
——
Update database
as necessary
[PM]
a a
Problem /
I Management
Database }
Continue:
problem
process to I
completion
__ No
[>< Does originator I
agree?
Yes
Close problem on
database
[PM]
a ae
Problem I I
Management I
Database I /
COMMERCIAL IN CONFIDENCE
Page 23 of 37
FUJ00079797
FUJ00079797
ICL Pathway ICL Pathway Problem Management oSIPRDI021
Process 25/05/98
™@ Once it has been decided that a problem exists the DM will enter the
details of the problem on to the Problem Management Database. The only
exception to this being if a problem needs to be dealt with immediately.
This being the case then the details will be entered on to the database
following completion of the immediate action.
10.1 Advantages of a database
1. The storage of problems will enable users to retrieve quickly and
easily problems that have occurred in the past
A number of users can use the database at the same time
Use of the database will help stop the duplication of problems
Trends can be identified, and action can then be taken to
investigate these trends.
5. Statistical analysis can be carried out. For example, the average
duration of a problem, or the average number of problems arising
each week.
6. The database can also be used as a tool to identify which
problems are being dealt with by specific problem managers, and
therefore help to decide who to assign to new problems that may
arise.
7. The database can help with weekly/monthly problem reviews.
10.2 Keeping the database updated
™ Once the details of the problem have been entered into the database the
DM will nominate a Problem Manager. Following nomination, the Problem
Manager will be entered on to the database as the new owner of the
problem.
™@ The Problem Management Process will then begin. Throughout the life of
the problem, the Problem Manager will constantly update the problem
within the database so that the database always reflects the current
situation. Review dates should be set on the database record to signify
when an update might be expected.
The reason for this is so that anyone needing to know the current progress of
a problem will be able to find out via the database without having to contact
the Problem Manager who may not even be available.
@ A problem will only be closed on the database once the Problem Manager
has gained the approval of the problem originator that the problem has
been solved satisfactorily.
COMMERCIAL IN CONFIDENCE Page 24 of 37
FUJ00079797
FUJ00079797
ICL Pathway ICL Pathway Problem Management oSIPRDI021
Process 25/05/98
10.3 Problem Management Database Priorities
The database user must assign a priority to every problem entered into the
database. The Problem Management Database priorities (A,B,C) should not
be confused with the HSH incident priorities (A,B,C & D). They are different
and should not be perceived as having the same meanings. In most cases,
problems are related to a number of Post Offices having a problem rather
than a single Post Office.
Priority ‘A’ - a problem that requires immediate attention. As with the incident
priority it can be ‘BUSINESS STOPPED’ as a result of a Post Office, or a
number of Post Offices, being down and unable to use the Horizon System
for business. Or a central system failure which will result in a number of Post
Offices being unable to process work. An ‘A’ priority will warrant the problem
being escalated to senior management. Whenever an ‘A’ priority is assigned
on the database, an e-mail will be sent to the Customer Service Director and
the Direct Reports, informing them of the problem.
Priority ‘B’ - a problem that requires immediate attention but does not need
to be escalated to a higher level.
Priority ‘C’ - non-urgent issues that require a Problem Manager to manage
them to resolution. The default for every new problem is ‘C’.
COMMERCIAL IN CONFIDENCE Page 25 of 37
FUJ00079797
FUJ00079797
ICL Pathway ICL Pathway Problem Management SSIPRDIO21
Process :
25/05/98
The Escalation Process
No
PM Probiem > Senge >< Escalate? A> Resoive probiem Close Problem
Yes
Vv ic
{nfo I Escalate for I Escalate for
For info or for >——}—> _ information information
‘action? I “internal nternally
Action ; y
extemal No
‘tsomaton action enema Inemal or > < Escaatfor SI Escalation for
intemaly enteral? infomation Informal
Yes I
Resolve problem
externally
L
Close problem
External
Escali
for Action
Internal Escalation for
Action
I
Escalate for I
action internally
Escalate for
information
‘externally?
Resolve problem I———-}e} Close Problem
Yes
I
Escalate for I
information}
omy
Notes:
Internal escalation is escalation to
PIW Customer Service
External escalation is escalation to
PAW suppliersicustomers
‘The PM is responsible for all
actions and decisions.
COMMERCIAL IN CONFIDENCE
Page 26 of 37
FUJ00079797
FUJ00079797
ICL Pathway ICL Pathway Problem Management oSIPRDI021
Process 25/05/98
11.1 Escalation Internally
It is important to note that escalation within Pathway and the problem
originators domain should always be running in parallel. So, for example, if
De La Rue called the HSH with a problem that required escalation and they
said it had been escalated to a senior manager, then Pathway should be
escalating to the same level. The reason for this being that the senior
manager in De La Rue might contact his/her equivalent in Pathway, and it is
always ‘better practice’ for a manager to be aware of a problem from their
own sources rather than hear it from the organisation where the problem
originated from.
This should also be the case even if Pathway have assigned a low severity
level to a problem. So if, for example, a problem came in to the HSH and is
assigned a Severity Level 5 (see Section 11.3.1), then the problem would not
normally be escalated to the Duty Manager. However, if the problem was
escalated to a higher level within the problem originators organisation, then
escalation should be paralleled within Pathway.
11.1.1 Escalation for Action
Escalation for action can occur in two ways.
1. When the PM first receives a problem and has to make a decision whether
to escalate.
2. When the PM, after attempting to resolve a problem, falls into difficulties
and again has to make a decision whether to escalate.
In both of the above situations, the PM will ‘escalate for action’ if:
- he/she does not know how to resolve a problem, or
- there are ‘barriers’ stopping the PM resolving the problem,
and it requires a higher authority to help overcome it.
- a decision needs to be made by a higher authority
- in a ‘disaster’ situation, decisions might have to be made at
ICL
board level.
11.1.2 Escalation for Information
Escalation for information should be to: Operations Service Manager;
Service Management ;
Customer Service Director.
Escalation for information can occur in two ways:
@ Firstly, when ever a problem is entered in to the Problem Management
Database as an ‘A’ priority (see Section 10), the Customer Service Director
and the Direct Reports are e-mailed automatically so that they are aware of
the problem. However, this is then dependent upon the Director and the
Direct Reports reading their e-mail for them to be aware of the problem.
™ Therefore, and secondly, in some cases, it will be necessary to make sure
COMMERCIAL IN CONFIDENCE Page 27 of 37
FUJ00079797
FUJ00079797
ICL Pathway ICL Pathway Problem Management oSIPRDI021
Process 25/05/98
11.2
that the above managers are immediately aware of a problem. So as well
as an e-mail being sent, it will be necessary to contact them personally so
that they are immediately aware of an urgent problem.
It is the decision of the PM to determine when to escalate for information.
Examples of escalation for information might include:
1. PCHL/HSH not available to customers for a period in excess of 15 minutes.
2. More than 10 Post Offices are unable to communicate with the central suite
of systems for a period in excess of 60 minutes.
3. Problems that affect more than 25 beneficiaries or more than 10 Post
Offices
Escalation Externally
‘When escalating any issue externally, it is good practice to inform the
authority concerned and PDA that the issue has been escalated within own
organisation and to what level. This practice prevents perceived lack of
communication. In addition, the escalating authority should state what action
(escalation for action) they require or why they are escalating the issue
concerned (escalation for information).’
- SCOP Version 2.1, P16, Para 5.2.6
11.2.1 Escalation for Action
When a PM decides that a problem needs to be dealt with externally, then
there is an option to follow one of two paths.
Escalation can either be to the PDA (now PSM) who currently act as a liaison
between Pathway and POCL / BA. From here the PSM will then escalate the
problem to the other parties or deal with the problem themselves if they
impact the customer.
If escalation is not through the PDA then it will be directly to the other parties.
i.e. directly to Royal Mail, Energis etc.. However, any problems escalated
externally, not through the PSM, should be escalated to the PSM as
‘information’ if they impact the customer.
11.2.2 Escalation for Information
11.3
Any problem that has any repercussions outside of Pathway will be escalated
to the PDA for ‘information’ who act on behalf of the Post Office and the
Benefits Agency. The PDA will then inform the relevant parties. However,
escalation to the PDA should always follow internal escalation.
Escalation Call Matrix
However the escalation process is defined, particularly at a high level basis, it
does not explain who, where, when or how to escalate to in particular
situations.
COMMERCIAL IN CONFIDENCE Page 28 of 37
FUJ00079797
FUJ00079797
ICL Pathway ICL Pathway Problem Management oSIPRDI021
Process 25/05/98
For example, if there was a problem with a server:
Who should be informed of a problem?
Are they internal or external parties?
Who should be escalated to for information or for action?
When should escalation take place?
To help with these questions, an escalation matrix document is under
development to help the Problem Manager in decision making. A Problem
Manager can use the escalation process chart as a guide but it can not be
used to make specific decisions, and in certain situations a Problem Manager
may not always know the answers.
Appendix 4 gives an example of the proposed escalation matrix that can be
used by the Problem Managers to help make decisions as to when to
escalate and who to escalate to.
For each supplier/customer a matrix will be developed. Each matrix will house
all potential problems that could arise from that particular supplier or
customer.
Each potential problem will be allocated a ‘Severity Level’ which determines
the level of escalation to be achieved. (See Section 11.3.1) By each potential
problem and severity level there will be a brief guide that will list possible
courses of action the Problem Manager might wish to take in order to resolve
the problem as quickly and effectively as possible.
The escalation matrix document will also incorporate the:
™ Customer Red Alert Process - ‘... a co-ordinated response by ICL to a
Situation of extreme customer dissatisfaction... .’
™ Disaster Recovery Plan that contains procedures to be followed in the
event of a disaster within the Pathway Structure.
[DN: A draft escalation matrix document will be available in the near
future. In order to populate the escalation matrices, the next task is for
Pathway’s suppliers/customers to provide Pathway with all possible
problems. Each matrix can then be developed so that for every problem
the required severity level can be set, and a guide of possible actions
can be developed.
The matrix also needs an owner. This is yet to be established.]
COMMERCIAL IN CONFIDENCE Page 29 of 37
FUJ00079797
FUJ00079797
ICL Pathway ICL Pathway Problem Management oSIPRDI021
Process 25/05/98
11.3.1 Severity Levels
The Severity Levels will range from 1 - 5. These also correspond with the
escalation levels as defined in the SCoP.
The following escalation routes have so far been proposed. Please note
however, that they could change.
Level I Escalation
1 HSH ‘A/B’ priority. (Treat as a normal ‘A’ or ‘B’ priority incident.)
2 HSH urgent ‘A’ priority. Immediate escalation to Duty Manager.
3 HSH urgent ‘A’ priority. Immediate escalation to DM.
DM escalates to Customer Service Managers.
4 HSH urgent ‘A’ priority. Immediate escalation to DM.
DM escalates to Customer Service Managers & Customer Service
Director
5 HSH urgent ‘A’ priority. Immediate escalation to DM.
DM escalates to Customer Service Managers & Customer Service
Director Customer Service Director escalates to ICL Pathway
Director.
™@ Possibly start an Orange / Red Alert procedure
™@ Severity Level 1 being the lowest level of action required. E.g. escalation
will only be invoked if an incident raised with the HSH is going to breach its
agreed SLA times.
™ Severity Level 5 could invoke an immediate Orange or Red Alert action.
Orange alert enables the “raiser” to identify a resource in the same business
division to meet a problem situation
"A Customer Red Alert (CRA) is a co-ordinated response by ICL [Group] to a
situation of extreme customer dissatisfaction or distress. It provides special
management attention and rapid deployment of resources to solve the
problem quickly and effectively.”
- ICL Customer Red Alert Handbook, Issue 4 - July 1997
Alerts have their own database and must be maintained with daily updates.
Please see alert manuals for further information.
Note: The Severity levels are used as initial entry levels for incidents raised
with the HSH. Therefore, an incident raised as a Severity Level 1 could also
end up bringing into a play an alert procedure. The severity levels help to
COMMERCIAL IN CONFIDENCE Page 30 of 37
FUJ00079797
FUJ00079797
ICL Pathway ICL Pathway Problem Management oSIPRDI021
Process 25/05/98
determine the initial action to be taken with a problem. They do not explain
what action is to be taken later on in a problems life cycle. For example, it
might be the case that a problem, initially allocated a severity level of 1,
needs to be escalated as the solution was ineffective and the problem has
become more urgent.
COMMERCIAL IN CONFIDENCE Page 31 of 37
FUJ00079797
FUJ00079797
ICL Pathway ICL Pathway Problem Management oSIPRDI021
Process 25/05/98
Appendix 1
Escalation Levels
Source: PDA Service Management - Service Code of Practice
Ref: PDA/ SVM/ CP / 001
Version 2.1, Page 98
Escalation I Level 1 Level 2 Level 3 Level 4 Out of
level Hours
ICL HSH Duty Service Customer Duty
Pathway Manager Manager Manager Service Manager
Director
Tel: Not known
“vpn: yet
IGRO
COMMERCIAL IN CONFIDENCE
Page 32 of 37
FUJ00079797
FUJ00079797
ICL Pathway ICL Pathway Problem Management CS/PRD/021
Process dar0s/08
Appendix 2
Contact points to external / internal authorities.
Authority Contact Name/Position
De La Rue Cards
Pathway Project Manager
(Rob Elliss - to be confirmed)
Telephone Number
De La Rue
Security Print
Office Systems Manager
(Graham Clarke - tbc)
Oracle
SSC Manager (Mik Peach)
Payment Card
PCHL Service Development
Helpline Manager (Dave Wilson)
SSC SSC Manager (Mik Peach)
SMC SMC Manager - (Derek Miles ),
else the Duty Shift Manager
POCL Service
POCL Service Management
GRO
Management team
COLS COLS
Royal Mail Pathway Programme Manager
(Paul Kennedy)
Note:
De La Rue
De La rue Cards should be contacted with regard to any potential card problems
e.g. if a problem resulted in the file of card orders not being sent, or Royal Mail went
on strike and could not pick cards up.
De La Rue Security Print should be contacted with regard to any potential
problems regarding temporary tokens.
COMMERCIAL IN CONFIDENCE
Page 33 of 37
FUJ00079797
FUJ00079797
ICL Pathway ICL Pathway Problem Management oSIPRDI021
Process 25/05/98
Appendix 3
Horizon System Help Desk Key Words
‘To help the HSH operator determine whether a call is escalated to the Duty
Manager, a set of key words have been developed. If any of these key words are
mentioned by the caller, then the call is assigned an ‘A’ priority code and the DM will
be contacted via the pager. ‘
The key words include:
Business Critical
Critical
Severity 1
Priority 1
Reconciliation*
Immediate Priority
‘Contingency’ suggested
* Reconciliation calls are currently in the process of being added in to the
HSH Call Matrix
COMMERCIAL IN CONFIDENCE Page 34 of 37
FUJ00079797
FUJ00079797
ICL Pathway ICL Pathway Problem Management eSiPRDI021
Process 25/05/98
Appendix 4
Escalation Matrix for:
PCHL
SEVERITY LEVEL I GUIDE
1 Helpdesk down _ for 4 Inform PDA that PCHL is down. Make sure other Help Desks are aware that PCHL is
more than 15 mins. down. Check with SSC and CFM as to problem. Agree course of action with PCHL.
2 I Bootle site is 3 Following discussions with senior management and PCHL, possibly look to invoke
inoperable contingency.......
3 I Shortage of staff to A I Lee
man help desk
COMMERCIAL IN CONFIDENCE Page 35 of 37
FUJ00079797
FUJ00079797
ICL Pathway ICL Pathway Problem Management CS/PRD/021
Process 12
25/05/98
Appendix 5
HSH incident to Problem Management Time Scales (tbc)
STEP I ACTION AVERAGE TIME I CUMULATIVE
TAKEN (Mins) I TIME TAKEN
1 Call to HSH 0 0
2 Telephone Call 4 4
3 General administration 4 8
4 Inform HSH Shift leader / Senior TSA 2 10
5 Shift leader / Senior TSA pager the 1 11
Duty Mgr
6 Duty Manager calls HSH to investigate 5 16
7 Duty Manager decides if it is a problem 10 26
8 Duty Manager logs call on to database 5 31
9 Duty Manager assigns Problem 9 40
Manager
The above table looks at the situation where a call that is made to the HSH is
escalated immediately to the DM. Please note that escalation to the DM could
also occur after the SLA’s for action times for both ‘A’ and ‘B’ priorities have
elapsed. For example, an ‘A’ priority hardware fault should be fixed within 4
hours. If the 4 hour deadline is to be breached then the DM will be informed.
Note: The above times are an approximation. Urgent problems could reach
the Problem Manager more quickly. It could be the case that the Duty
Manager acts as the Problem Manager, therefore cutting 10 minutes out of
the process.
COMMERCIAL IN CONFIDENCE
Page 36 of 37
FUJ00079797
FUJ00079797
ICL Pathway ICL Pathway Problem Management CS/PRD/021
Process 12
25/05/98
Appendix 6
Terms of Reference for Duty Manager
Times of Operation Start 0800 Mon- 0759 Mon ie 24hr/7days
Normal Day Location Feltham Office (Fel01)
Continuous Availability SPOC (Single Point of Contact) for Daily
Issues/Problems/Escalation
Continuous updates with HSH
Duty Manager Rota with HSH
Pager Contact
Appointment of Problem Managers as per Problem Manager Process
Duty Manager Book containing Process’s/Contacts/Names/Telephone
Numbers/Escalation Routes
USEFUL TELEPHONE NUMBERS
HSH-Horizon System Helpdesk ITN
an __MOBILE _ HOME
Suzanne Breen i i I
Dave Campbell
Vince Cochrane
Andy Muse
OPERATIONS.
Alex Nicholson
Martin Riddell
Mike Stewart
COMMERCIAL IN CONFIDENCE Page 37 of 37
FUJ00079797
FUJ00079797
ICL Pathway ICL Pathway Problem Management oSIPRDI021
Process 25/05/98
Appendix 7
ICL Pathway Service Managers
Service Manager Services to: Services from:
Paul Curley / Martin Molloy I POCL HSH
SMC.
Systems Service
POCL
John Wright / Jeremy BA Girobank (PCHL)
Lindegaard Stewart De La Rue
Royal Mail
Paul Curley and Martin Molloy
™@ services to POCL
™ services from Horizon System Helpdesk, from SMC second-line support,
from Systems Service (i.e. engineers from Sorbus) and from POCL (i.e.
service provided by POCL in relation to cards - booking them in etc.)
John Wright and Jeremy Lindegaard-Stewart
™@ services to BA
™ services from Girobank (Payment Card Helpline), from De La Rue
(Cards/PUNs/Temporary Tokens production) and from Royal Mail (delivery
of Cards/PUNs/Temporary Tokens)
COMMERCIAL IN CONFIDENCE
Page 38 of 37