FUJ00119992
FUJ00119992
ICL Pathway ICL Pathway Customer Service Problem and Alert Ref: CS/PRD/021
Management Process
Version: 4.0
COMPANY IN CONFIDENCE Date: 27/11/2001
Document Title: ICL Pathway Customer Service Problem and Alert Management
Process
Document Type: Process Definition
Release: N/A
Abstract: This document defines the ICL Pathway Customer Service Problem
Management Process.
Document Status: For Approval
Author & Dept: Nathan Monk - ICL Pathway CS Business Effectiveness Team
Contributors: Eric Hillier, Bob Davis,
Reviewed By: Paul Westfield, Eric Hillier, Mik Peach, Bob Davis, Alex
Nicholson, Dave Law
Comments By:
Comments To: Nathan Monk
Distribution: ICL Pathway Library
© 2000 ICL Pathway Limited COMPANY IN CONFIDENCE Page: 1 of 26
Last Printed: 27/11/2001 08:43
FUJ00119992
FUJ00119992
ICL Pathway ICL Pathway Customer Service Problem and Alert Ref: CS/PRD/021
Management Process
Version: 4.0
COMPANY IN CONFIDENCE Date: 27/11/2001
0.0 Dotuwment Control
O.L Document History
1.0 05/11/97 ICL Pathway Problem Management
Process
Ll 16/04/98 Update
1.2 25/05/98 Update
1.3 19/07/98 Update
1.4 03/12/98 Update
1.5 02/04/99 Update
1.6 29/07/99 Updated following internal review and
comments
2.0 26/08/99 Stored in PVCS as “Version Complete”
2.1 15/05/00 Updated following a review of the CS
Problem Management Operation
3.0 13/11/00 Updated with comments from version 2.1,
and developed for approval.
3.1 19/11/01 Updated following annual process review,
and incorporation of the CS divisional
alert process.
4.0 27/11/01 Updated with comments from review of
version 3.1 and developed for approval
0.2 Approve Authoritiey
Paul Westfield Infrastructure Service
Manager
0.3 Associated Documenty
© 2000 ICL Pathway Limited COMPANY IN CONFIDENCE Page: 2 of 26
Last Printed: 27/11/2001 08:43
FUJ00119992
FUJ00119992
ICL Pathway ICL Pathway Customer Service Problem and Alert Ref: CS/PRD/021
Management Process
Version: 4.0
COMPANY IN CONFIDENCE Date: 27/11/2001
1. I CS/FS/008 ICL Pathway / POL Interface Agreement for the ICL Pathway
Problem Management Interface
2. I CS/PRD/074 ICL Pathway Incident Management Process ICL Pathway
3. I CS/PRO/110 ICL Pathway Problem Management Database ICL Pathway
Procedures
4. I PA/PRO/OO1 Change Control Process ICL Pathway
CS/QMS/001 Customer Service Policy Manual ICL Pathway
Unless a specific version is referred to above, references should be made to the
current approved versions of the document.
0.4 Abbrevictions/Definitiony
ATP Authorised Temporary Procedure
cP Change Proposal
cs ICL Pathway Customer Service
CS Line Man Customer Service Line Manager
CS Ops Support Customer Service Operational Support
CSAC Customer Service Action Centre
DM ICL Pathway CS Duty Manager
FSMP. Field Service Management Process.
HSH Horizon Systems Helpdesk
ICL PW ICL Pathway
ICL PW PM ICL Pathway CS Problem Manager
PIR Post Implementation Review
PM ICL Pathway Problem Manager
POL Post Office Limited
POL BSM PM POL Business Service Management Problem Manager
RO Resolution Owner
TP Temporary Procedure
0.5 Changes nm thy Veriow
he document has been revised to take account of latest devel lopment in
Problem Management thinking and also to fit in with latest process and
© 2000 ICL Pathway Limited COMPANY IN CONFIDENCE P
age: 3 of 26
Last Printed: 27/11/2001 08:43
FUJ00119992
FUJ00119992
ICL Pathway ICL Pathway Customer Service Problem and Alert Ref: CS/PRD/021
Management Process
Version: 4.0
COMPANY IN CONFIDENCE Date: 27/11/2001
policy developments.
3.0 Revision of the Process following comments to version 2.1 and of the
Problem Management Role.
3.1 Addition of the alert management process and updates to improve links
with other ICL processes.
4.0 Revision of the process following comments on version 3.1. Submitted for
approval.
0.6 Chongey Expected
© 2000 ICL Pathway Limited COMPANY IN CONFIDENCE Page: 4 of 26
Last Printed: 27/11/2001 08:43
ICL Pathway ICL Pathway Customer Service Problem Management Ref:
Process
Version:
COMPANY IN CONFIDENCE Date:
CS/PRD/021
4.0
26/11/01
FUJ00119992
FUJ00119992
0.7 Table of Contents
1 INTRODUCTION
2 SCOPE
24 Top level Process Diagram.
3 DEPLOYED PROCESS
4 ROLES WITHIN THE PROBLEM MANAGEMENT PROCESS
41 Problem Originator
42 Problem Manager
43 Resolution Owner/Team
5 PROBLEM MANAGEMENT PROCESS
5.1 Problem Notification
1.1 Assign Problem Manager
5.1.2 Provide details of the Problem
Problem Analysis
Log Problem
Analyse Problem
Assess Impact
Prioritise
. Problem Manager Action
5.3.1 Agree Problem Owner
5.3.2 Agree Action and Update plan
5.3.3. Requirement for a Temporary Procedure
5.4 Problem Resolution
5.4.1 Identify Root Cause
5.4.2 Develop permanent solution
5.4.3 Agree solution
5.44 — Implement solution
5.5 Problem Monitoring
5.5.1 Monitor Solution Implementation
5.5.2. Solution Implemented
5.6 Problem Closure
5.6.1 Requirement for a PIR
5.6.2. Close Problem
5.7 (Authorised) Temporary Procedure
5.7.1 Temporary Procedure Development
© 2000 ICL Pathway Limited COMPANY IN CONFIDENCE
Page: 5 of 26
ICL Pathway ICL Pathway Customer Service Problem Management
Process
COMPANY IN CONFIDENCE
Ref:
Version:
Date:
CS/PRD/021
4.0
26/11/01
FUJ00119992
FUJ00119992
3.7.2 Until Problem resolved
5.7.3 Withdrawal of the Temporary Procedure
5.8 Escalation to Divisional Alert
5.8.1 Engage Divisional Alert
5.8.2. Manage Divisional Alert
24
24
25
© 2000 ICL Pathway Limited COMPANY IN CONFIDENCE
Page: 6 of 26
FUJ00119992
FUJ00119992
ICL Pathway ICL Pathway Customer Service Problem Management Ref: CS/PRD/021
Process
Version; 4.0
COMPANY IN CONFIDENCE Date: 26/11/01
1 Introduction
Not all incidents and complaints that arise at the helpdesk can easily be resolved using
the incident management process [Ref.2]. Some incidents have a wide impact, some
may be difficult and time consuming to resolve, whilst others may arise as a result of a
single underlying issue. Therefore, some incidents may require referral to the Problem
Management process operated by ICL Pathway Customer Service.
A key element for success in the resolution of incidents and complaints that are
referred to ICL Pathway Customer service is an effective Problem Management and
Alert process.
Definitions of incidents and problems are given in ICL Pathways Policy Manual
(CS/QMS/001).
2 Scope
This document details the Problem Management process, which includes the raising
of alerts.
The scope begins at the point that a problem is identified. The process is divided up
into the major Problem Management elements as shown in the “Deployed Process”
within Section 3.
The scope includes the handling of Cross-Domain problems and the raising of
Divisional and Corporate alerts.
The diagram below highlights the feeds in and out of the problem management
process.
Each of the suppliers is able to identify problems that link in to the ICL Pathway
Customer Service Problem Management process. The customers are those who
potentially benefit from the resolution of a problem.
2.1 Top level Process Diagraw
Comptaint
Management [>
€S PROBLEM & ALERT
Business
Gontnuty
© 2000 ICL Pathway Limited COMPANY IN CONFIDENCE Page: 7 of 26
FUJ00119992
FUJ00119992
ICL Pathway ICL Pathway Customer Service Problem Management Ref: CS/PRD/021
Process
Version: 4.0
COMPANY IN CONFIDENCE Date: 26/11/01
3B Deployed Process
Identification I Notification Analysis Action Resolution I Monitor : Closure
‘(Duty Manager) ' (Problem Manager) '(Problem Manager): (Resolution Owner) ‘(Problem Manager) ' (Problem Manager)
(start ) Provide PM with p__,t09 problem on Set up resolution Identity Monitor solution II
a 7 details of problem Problem Database team root cause implementation :
I '
/ Ensure permanent f \ boy ~
identified Assign Problem Analyse/Define Agree action & Until solution I 4 .
problem problem update plan deveonnrent implemented 1 >< PIR Required? >—YESI PIR
‘Assess impact of
woblem “TP Required?
Escalation to
Divisional Alert
Prioritise problem
Agree solution
Implement solution
Close problem
( END
Temporary Procedure
Problem Management)
© 2000 ICL Pathway Limited
COMPANY IN CONFIDENCE
Page: 8 of 26
FUJ00119992
FUJ00119992
ICL Pathway ICL Pathway Customer Service Problem Management Ref: CS/PRD/021
Process
Version: 4.0
COMPANY IN CONFIDENCE Date: 26/11/01
4 Roles within the Problem Management Process
4.1 Problem Origmetor
The person who initially raised the problem.
4.2 Problem Manager
The Problem Manager is the person assigned with responsibility for managing a
problem through to resolution.
The Problem Manager will apply Project Management principles to progress the
problem to resolution. This includes:
- Constructing a plan (including key target dates),
- Securing appropriate resource and commitment,
- Monitoring.
The duties of the Problem Manager include:
INITIAL e Logging the problem onto the Problem Management
ACTIONS database.
¢ Define problem
¢ Initial impact assessment and prioritisation
e Establishment of initial closure criteria
ONGOING e Problem Control
ACTION
- Temporary procedure management
- Alerts
- Inform and communication (cross-domain?)
© Keep record on Problem Management database updated
© 2000 ICL Pathway Limited COMPANY IN CONFIDENCE Page: 9 of 26
FUJ00119992
FUJ00119992
ICL Pathway ICL Pathway Customer Service Problem Management Ref CS/PRD/021
Process
Version: 4.0
COMPANY IN CONFIDENCE Date: 26/11/01
MANAGE PROBLEM Identify Resolution Owner
RESOLUTION Agree an action plan and update report
Validate and agree root cause*.
Design solution (proposed deliverable(s) including
implementation plans)*.
Agree solution.
MANAGE Manage implementation of the solution
IMPELMENTATION - Manage action plan
OF SOLUTION 8 P
- Management of change
- Monitor progress
CLOSURE Problem closure
- Confirm closure criteria is met
- Conduct Post Implementation Review (If
applicable).
The Problem Manager is the only formal communication channel between the Service
Management teams of ICL Pathway and POL.
4.3 Resolution Owner/Teaw
The Resolution Owner/Team is the authority assigned to resolve a particular problem
and is responsible for developing a permanent solution. In some circumstances the
Problem Manager may assume the role of Resolution Owner.
* Maybe delegated to any third party ICL personnel depending on pervious relevant
experience and availability.
© 2000 ICL Pathway Limited
COMPANY IN CONFIDENCE Page: 10 of 26
FUJ00119992
FUJ00119992
ICL Pathway ICL Pathway Customer Service Problem Management Ref: CS/PRD/021
Process
Version: 4.0
COMPANY IN CONFIDENCE Date: 26/11/01
5 Problem Management Process
The process followed by the Problem Manager to ensure the resolution of a problem
depends upon whether the problem is internal to ICL Pathway, or a cross-domain
problem that requires interactions with a POL BSM Problem Manager.
5.1 Problem Notification
NOTIFICATION
(Duty Manager)
At
Problem Determine CS unit
START} » notification >» tomanage
y (Originator) / problem
(om)
¥ Assign
Az Problem
Identify potential
Problem Manager Manager
within unit
(OMICS Line Man)
y
“Can
‘Potential PM's work
load accommodate.
‘new problem 7
3
Provide PM with
details of problem I
(OMOriginator) Provide
details of
problem
Problem analysis
(ection 5.2)
5.1.4 Assign Problem Manager
The Duty Manager is informed of individual problems, problems maybe
communicated to the Duty Manager by the internal CS organisation or an external
source. The Duty Manager then identifies potential Problem Manager/s (PM) best
placed to manage the problem. Before a finial decision can be made the DM must
check the workload of the potential PM/s and assign the problem to an individual PM
whose workload can accommodate it. Any difficulties with assigning a PM are
discussed with the appropriate CS Line Managers.
5.1.2 Provide detaily of the Problew
The DM together with the problem originator provides the assigned PM with all the
available details of the Problem.
© 2000 ICL Pathway Limited COMPANY IN CONFIDENCE Page: 11 of 26
FUJ00119992
FUJ00119992
ICL Pathway ICL Pathway Customer Service Problem Management _ Ref: CS/PRD/021
Process
Version: 4.0
COMPANY IN CONFIDENCE Date: 26/11/01
5.2 Problem Analysis
(Problem Manager)
Bt Log
Fr Le bl
‘Notieation », the Problem Problem
(Section 5.1) Database
(PM)
ence ee nee eee ene eee cyccnceceee been eee ee eee eee
B2
Contact problem
originator
(PM)
a
BS
Define Problem Analyze
em) Problem
Yv
. B4 _/ Does
\ Inform originator of problem
END j« existing problem already
- PM) exist?
END N
Impact
‘on PW business
\ operations?
<
y
v
BE
Keep relevant
people updated
until problem
closes
(PM)
Be
Define closure
criteria and record
on the D’base
0)
Problem Manager
Action
(Section 5.3)
BS
Assess impact of
problem
87
Determine priority
of the problem
(PM)
Assess
Impact
Priorities
© 2000 ICL Pathway Limited
COMPANY IN CONFIDENCE
Page: 12 of 26
FUJ00119992
FUJ00119992
ICL Pathway ICL Pathway Customer Service Problem Management Ref: CS/PRD/021
Process
Version: 4.0
COMPANY IN CONFIDENCE Date: 26/11/01
5.2.1 Log Problew
All the details of the problems, along with any action taken to date, must be logged on
the database [Ref.3]. This includes cross referencing the problem to any existing
incident numbers or linked PinICL numbers, and also the POL problem number if the
problem is a cross-domain Problem (see Section 5.3).
5.2.2 Anolyse Problew
The Problem Manager contacts the originator of the problem in order to understand, if
necessary, the problem more fully. It also allows the originator to know who the
Problem Manager is and be informed of the Problem Reference number. The Problem
Manager is then in a position to define the problem. If the problem already exists, the
originator is notified of the Problem Manager dealing with the existing problem.
5.2.3 Assess lmpoct
If the problem doesn’t already exist, the Problem Manager assesses the impact of the
problem. This allows the problem Manager to decide who is impacted by the problem
so that they can be informed and kept updated. In the case of a cross-domain Problem
information from the POL Problem Manager should be taken into account.
5.2.4 Prioritie
Having assessed the impact of the Problem the Problem Manager assigns a priority to
the problem. The priority defines how urgent the problem is.
The Problem Manager also determines the closure criteria for the problem, i.e. the
conditions under which the problem can be closed. This is also captured on the
database.
Tf required, the Problem Manager can request the HSH to set up a Master Incident to
capture incidents arising as a result of the problem. The priority of the problem could
subsequently increase (or be lowered) if the volumes of incidents arising changes
dramatically.
© 2000 ICL Pathway Limited COMPANY IN CONFIDENCE Page: 13 of 26
FUJ00119992
FUJ00119992
ICL Pathway ICL Pathway Customer Service Problem Management _ Ref: CS/PRD/021
Process
Version: 4.0
COMPANY IN CONFIDENCE Date: 26/11/01
5.3 Problem Manager Action
Act
From
Cross
Problem
Anayss—_/ domain, Y
(Section 5.2) / Sgobiem:
N
Internal Problen + Cross-domain ProblemI
T
1 : ¥
1 ct
resolution owner : Mae eee.
my lanagement team
' (PM)
1
1
1
1
' ca
I Agree problem
H priority with POL
' PM
(PM) i
' Assign
I resolution
I owner
1 on
1 3
1 Agree
1 responsibilty for
‘ resolution with
1
1 (PM)
1
1
1
1 os
1 Agree closure
criteria and update
schedule with POL “Y —~<ICL Fesoition -
cM owner
cr cA
‘Agree plan of Agree closure Agree action
action & update criteria & update and update
with resolution schedule with plan
owner PON PM
(PM) (PM)
x TP required >
wae Requirement
1 fora Temporary
x Procedure
Problem ce
Resolution Ensure a TP is Proce weess
(Section 5.4) Developed ponbagen
© 2000 ICL Pathway Limited
COMPANY IN CONFIDENCE
Page: 14 of 26
FUJ00119992
FUJ00119992
ICL Pathway ICL Pathway Customer Service Problem Management Ref: CS/PRD/021
Process
Version: 4.0
COMPANY IN CONFIDENCE Date: 26/11/01
5.3.4 Agree Problem Owner
At this stage the Problem Manager must decide whether or not the Problem impacts
POL), i.e. a cross-domain Problem.
If the problem is identified as cross-domain the POL BSM Problem Management
team is contacted [Ref.1]. Once a POL BSM Problem Manager has been established
the Problem Managers from ICL Pathway and POL agree the priority of the problem,
and also decide which organisation is responsible for the resolution of the problem
5.3.2 Agree Action and Update plaw
A plan of action (including target dates) and an update schedule is then agreed with
the Resolution Owner. The Problem Manager is then in a position to monitor the
resolution progress and take action should any delays occur.
If the Problem is cross-domain, then having agreed which organisation is responsible
for the resolution of the problem, the Problem Managers agree the closure criteria, i.e.
the conditions under which the problem can be closed, and also an update schedule to
keep each other informed of progress.
5.3.3 Requirement for a Temporary Procedure
Whether the problem is cross-domain or internal to ICL Pathway, the Problem
Manager decides if a temporary procedure (TP) is required to address incidents arising
as a result of the problem whilst a permanent solution to the problem is being
developed. Ifa TP is required, see Section 5.7.
© 2000 ICL Pathway Limited COMPANY IN CONFIDENCE Page: 15 of 26
FUJ00119992
FUJ00119992
ICL Pathway ICL Pathway Customer Service Problem Management Ref: CS/PRD/021
Process
Version: 4.0
COMPANY IN CONFIDENCE Date: 26/11/01
5.4 Problem Resolution
RESOLUTION
(Problem Manager)
From Problem ; \
Mera retin y Yes
(Section 53)
j Identity
ICL Pathway responsible for resolution pow responsible fr resolution root
i cause
We :
oe :
o1 :
Deternine oot :
cause of problem :
(eM) ‘
Ensure a - {I pereps
orem gc) : permanent {e
+ — developed — ‘ ~
em {I PoNBSM PM)
: Develop
: permanent
-—— : Solution
03 \ ' oe
Unt proposed 1 I una Proposed)
souton developed 1 I scton developed
“I NO ‘No on
No po i ote
1 pres proposed
Aero soltion {I Satter wn tot
1 I (eon ssi em)
x :
y : : Agree
Agree? > : Agree? solution
08 :
eres proposed ; :
solution wiin €—Yes——< 1088, H Yes
Pow sh Pit domain? I :
(PM) ‘
oe :
; . crange I on
L. pee Sp eared >¥85™) Manegoment I I implementation
faye cP requea?, werent I moter
(PA/PRO/001) H
Ne : Implement
: solution
M :
o7 > Motitor
Ensure Problem
Implementation of I eecnga'ss)
soon i
(PM) t
© 2000 ICL Pathway Limited
COMPANY IN CONFIDENCE
Page: 16 of 26
FUJ00119992
FUJ00119992
ICL Pathway ICL Pathway Customer Service Problem Management Ref: CS/PRD/021
Process
Version: 4.0
COMPANY IN CONFIDENCE Date: 26/11/01
5.4.1 Identify Root Cause
If ICL Pathway is responsible for the resolution of the Problem, whether or not it is an
internal problem or a cross-domain problem, the root cause of the problem must be
determined before any feasible solution can be developed. The level of investigation is
determined by the business impact and risk of the initial problem.
Please Refer to Corporate Customer Satisfaction Framework (If online double click on
Hyperlink) for more information on Root Cause Analysis.
5.4.2 Develop permanent solution
Having Investigation the root cause of the problem the Problem Manager ensures that
the resolution owner develops and proposes a permanent solution to the problem, all
the while keeping the Problem Manager updated with progress.
If responsibility for resolution lies within POL, the POL BSM Problem Manager
ensures that a proposed solution is developed.
5.4.3 Agree solution
If ICL Pathway is responsible for resolution, the Problem Manager agrees the
proposed solution with the resolution owner. If the problem is cross-domain, the
Problem Manager must also agree the solution with POL BSM PM.
If POL is responsible for the resolution of the problem, after having developed a
proposed solution, the POL BSM PM will agree the solution with the ICL Pathway
CS PM.
5.4.4 Implement solution
If ICL Pathway is responsible for the resolution, then after having agreed the proposed
solution, the Problem Manager ensures the process for implementing the change is
initiated. In many cases, this requires the initiation of the formal Change Management
process [Ref.4].
If POL is responsible for resolution, then once the solution has been agreed with the
ICL Pathway Problem Manager, the POL BSM Problem Manager ensures that the
solution is implemented.
© 2000 ICL Pathway Limited COMPANY IN CONFIDENCE Page: 17 of 26
FUJ00119992
FUJ00119992
ICL Pathway ICL Pathway Customer Service Problem Management Ref: CS/PRD/021
Process
Version: 4.0
COMPANY IN CONFIDENCE Date: 26/11/01
5.5 Problem Monitoring
MONITORING
(Problem Manager)
1
From Monitor ,
Resolution /-» implementation of Monitor
(Section 5.4) solution ___ solution —
f (PM) implementation
4 “Senior PM* E3
Suspend “SY agree to >», Suspend problem
roblem?
suspend? (PM)
a on
E2 E4
Until solution 4 N eeu problem \ insgiton
implemented ay be
v
v
Problem Problem
resolved? Yes Closure ES
. , (Section 5.6) Re-open problem
(PM)
No
y
Resolution by .
POL? Yes B )
No
¥.
c }
5.5.1 Monitor Solution Implementation
The Problem Manager monitors the resolution and implementation of the problem to
ensure constant progress against deadlines. If deadlines are not being met, or progress
is slow, then if necessary, the Problem Manager can escalate (see Section 5.8) the
problem to ensure continuous progress against requirements.
In certain circumstances a problem can be suspended to save the Problem Manager
writing updates that do not add any further information or benefit to the Problem
Management database log. E.g. a resolution to a problem is due to be released into the
live estate within the next scheduled software release. The problem may be suspended
© 2000 ICL Pathway Limited COMPANY IN CONFIDENCE Page: 18 of 26
FUJ00119992
FUJ00119992
ICL Pathway ICL Pathway Customer Service Problem Management Ref: CS/PRD/021
Process
Version: 4.0
COMPANY IN CONFIDENCE Date: 26/11/01
until the software release is run and the new resolution can be monitored. A problem
can only be suspended once it has been authorised by the senior problem Manager.
5.5.2 Solution Implemented
Once the solution has been implemented, the Problem Manager determines whether
the problem has been resolved. If not, then action must be taken to understand why the
problem still remains and to ensure that a solution is developed that resolves the
problem. Again, escalation may be used to ensure that resources are available to
develop a solution to meet target deadlines.
If the problem has been resolved, the Problem Manager can move on to closing the
problem.
© 2000 ICL Pathway Limited COMPANY IN CONFIDENCE Page: 19 of 26
ICL Pathway
ICL Pathway Customer Service Problem Management Ref:
Process
Version:
COMPANY IN CONFIDENCE Date:
CS/PRD/021
4.0
26/11/01
FUJ00119992
FUJ00119992
5.6 Problem Closure
CLOSURE
(Problem Manager)
From F2 F3
Monitoring / > PIR Yes» Carry out PIR
(Section 5.5) required? (eM)
on
F4
No Until PIR I
complete /
F6 £5
Cross-domain >
problem?
Agree Closure
with PON BSM PM
(PM)
Yes
F7
Close problem
(PM)
Fa
END
Requirement
fora PIR
Close
problem
5.6.1 Requirement for a PIR
Before the Problem is formally closed the Problem Manager decides if a Post
Implementation Review (PIR) is required. In the case of a Cross-Domain Problem,
either organisational Problem Manager can request a PIR. A PIR should take place if
the Problem Manager was unhappy with the way that the problem was resolved. The
Review should include all the main players within the resolution of the problem with a
view to running through the problem and determining which parts of the process could
have been implemented more efficiently. The end result is to initiate improvement
actions to ensure that the process is operated as it should be or ultimately improved.
The PIR is presided over by the Problem Manager who requested it.
© 2000 ICL Pathway Limited
COMPANY IN CONFIDENCE
Page: 20 of 26
FUJ00119992
FUJ00119992
ICL Pathway ICL Pathway Customer Service Problem Management Ref: CS/PRD/021
Process
Version: 4.0
COMPANY IN CONFIDENCE Date: 26/11/01
5.6.2 Close Problew
If a PIR is has been carried out, this should be used as the authority to close the
problem. The problem is closed after all actions arising from the PIR have been
completed.
If the problem was cross-domain, it cannot be closed until agreed with the POL BSM
Problem Manager. If agreement is required from the POL BSM Problem Manager,
evidence of their agreement to close is required, i.e. letter, email, fax etc.
© 2000 ICL Pathway Limited COMPANY IN CONFIDENCE Page: 21 of 26
FUJ00119992
FUJ00119992
ICL Pathway ICL Pathway Customer Service Problem Management _ Ref: CS/PRD/021
Process
Version: 4.0
COMPANY IN CONFIDENCE Date: 26/11/01
5.7 (Authorised) Temporary Procedure
(AUTHORISED) TEMPORARY PROCEDURE
(Problem Manager)
Reguirerent Eronecomed, I
(section 53) > problem? ves
No \
Y '
Boes TP meet AP already inI TP already in oes TP meet
requirement? “Yes place? H place? Yes—P< requirements?
: Y
No ! No
v ;
Gt : es
Ensue I Agree ho wil
‘No development of I dovelop ATP with No
I rp Hl PON BSM PM.
(PM) ! (PM)
+ J
i G7
Al 2 ' Ictto ensure .
mire, } develop >I development of Development
H (PM)
' Yes
I cs
‘Does TP meet. I ti \ ce
Tareas > Lm Qe.) I unitate) Ne
~ : BSM PM / Proposed
Yes I ~ ~
"8 fo i t
sa ! /
Record and : “Agree ATP “Agree ATP.
register TP : with PON? \ with PON?
(PM) : . ve
Yes ‘
! I ves vhs
y ' wy
ot \ eto ce
Ensure TPis I ! Ensure ATP is Record and
implemented I} implemented regster ATP
on ‘Pa Pi
permanent) Unti
> lution I problem
implemented resolved
cr
Ensure (AJTP is I \ Withdrawal
withdrawn [TM CEND Sy ot TP
(PM)
© 2000 ICL Pathway Limited
COMPANY IN CONFIDENCE
Page: 22 of 26
FUJ00119992
FUJ00119992
ICL Pathway ICL Pathway Customer Service Problem Management Ref: CS/PRD/021
Process
Version: 4.0
COMPANY IN CONFIDENCE Date: 26/11/01
5.7.14 Temporary Procedure Development
If a Temporary Procedure (TP) is already in place then the Problem Manager
determines whether or not the TP meets current requirements. In the case of cross-
domain problems, the Problem Manager agrees with the POL BSM Problem if the
existing Temporary Procedure meets requirements.
Note: Cross-domain temporary procedures are agreed between the Problem Managers
of both organisations. Once agreed, the TP is known as an Authorised Temporary
Procedure (ATP).
If an existing TP meets current requirements then no further action is taken until the
TP is withdrawn.
If an existing TP does not meet current requirements, or no TP is yet in place, the
Problem Manager ensures that a TP is developed, recorded and registered, and finally
implemented. Development of the Temporary Procedure must include an
implementation and withdrawal plan.
If a cross-domain problem requires an ATP to be developed, the Problem Managers
agree which organisation is responsible for developing the ATP. The Problem
Manager of the organisation responsible for the development of the ATP ensures that
an ATP is developed. This is then agreed with their counterpart, recorded and
registered, and implemented.
5.7.2 Until Problem resolved
A TP remains in place until a permanent solution has been developed and
implemented. During this time, the Problem Manager(s) regularly review and monitor
a TP to ensure that it is working as it should.
5.7.3 Withdrawel of the Temporary Procedure
Once a permanent solution to the problem has been developed and implemented, the
temporary procedure is withdrawn. This must be carried out in a co-ordinated manner
alongside the implementation of the permanent solution.
© 2000 ICL Pathway Limited COMPANY IN CONFIDENCE Page: 23 of 26
FUJ00119992
FUJ00119992
ICL Pathway ICL Pathway Customer Service Problem Management Ref: CS/PRD/021
Process
Version: 4.0
COMPANY IN CONFIDENCE Date: 26/11/01
Engage Divisional Alert ,
Ht
Monitor Problem
(Probiem Manager)
CS Alert
y
Manage CS cs Ha
es —— Respond to CS Alert +¢ interactions
uisiness Alert CON toon
{CS Service Mgt) —» I
Ew
4 team Hs
y directive Non es
\ I Directorates
initiate an
Divisional (Ce)
Alert? /
Y
Manage Divisional Alert
Instruction to start Divisional Alert
Reporting
a x
He
Ho HS
Non cs Administer Alert update pve
- — I Probiem Alert
Directorates Divisional Alert (Live Problems) °e
ipdates
(CS ADMIN) (eSPM)
Divisional Alert Instruction
Report update I instruction to CS Admin "SV
(Live Probiem) I pw
Divisional Alerts y
>I H7
-_ Mat Respond to Questions! Respond wo Alen
( © \e— toam Divisional Alert I Question Pond to Ale
En (et Pataey Mgt requests question/instruct
- Tom (CS Mgt Team)
Senior mgt
ce
5.8.1 Engage Divisional Alert
During the life of a problem, the Problem Manager constantly monitors the progress
of the problem resolution to ensure that everything is on track and that target deadlines
are being met. At any point during the Problem Management process the Problem
© 2000 ICL Pathway Limited COMPANY IN CONFIDENCE Page: 24 of 26
FUJ00119992
FUJ00119992
ICL Pathway ICL Pathway Customer Service Problem Management Ref: CS/PRD/021
Process
Version: 4.0
COMPANY IN CONFIDENCE Date: 26/11/01
Manager or a member of the CS Management Team can highlight a problem for a
potential Divisional Alert.
The Divisional Alert status is intended to bring increasing levels of management
attention and/or expertise to bear upon the resolution of a Problem. Divisional Alerts
should only be considered for use in exceptional circumstances.
Potential Divisional Alerts may normally occur when:
e Anissue is causing increased concern through time delay and consequent business
impact, or
e It has not been possible to reach agreement on some aspect of the definition or
management of the Problem.
5.8.1.1 Specific to Process Box H1, H2, H3 and H4
If a Problem Manager or CS Service Manager feels that a problem is suffering from
any of the circumstances listed above then they can escalate the problem to the CS
Management Team. The CS Management Team will decide whether to raise a
Divisional Alert or not.
5.8.2 Manage Divisional Alert
5.8.2.1 Specific to Process Box H5
Divisional alert reporting for selected live problems is initiated by an instruction from
the CS Director or nominated person. A parallel instruction to the relevant CS
Problem Manager initiates the provision of problem updates.
CS Ops Support produces an alert update every time they receive a problem update
from the CS Problem Manager. Alert reports are produced and sent to an agreed
distribution list until they are instructed to close the Alert from the CS Director or
nominated person.
CS Ops Support also receive requests, e.g. “Please close alert”, these will be
progressed, passed on to the relevant CS Problem Manager and copied to the CS
Management Team and CS Director or nominated person.
5.8.2.2 Specific to Process Box H6
The decision by the CS Management Team to escalate a live problem to Divisional
alert is communicated to the appropriate CS Problem Manager.
The CS Problem Manager responds by providing regular problem updates to CS Ops
Support. The CS Problem Managers will produce a problem update typically twice
weekly or as stipulated by the CS Director or nominated person.
Note: CS Problem Managers continue to update the CS Problem Database at least
once a week. The database update includes a summary of the information provide to
CS Ops Support.
© 2000 ICL Pathway Limited COMPANY IN CONFIDENCE Page: 25 of 26
FUJ00119992
FUJ00119992
ICL Pathway ICL Pathway Customer Service Problem Management Ref: CS/PRD/021
Process
Version: 4.0
COMPANY IN CONFIDENCE Date: 26/11/01
Specific questions from ICL Pathway Directors are passed to CS Problem Managers
with a request to include an answer to the question in the next problem update. The
CS Management Team interacts directly with CS Problem Managers when required.
Note: If a cross-domain problem is being escalated, the Problem manager must ensure
that the counterpart organisational Problem Manager is informed so that escalation can
take place to the same level within the partner organisation. This ensures that the same
management levels are aware of the situation should they need to contact each other.
5.8.2.3 Specific to Process Box H7
ICL Pathway Directors (and other selected Pathway Managers) receive live problem
alert reports, and thereby remain aware of serious live problems.
ICL Pathway Directors interact with PON Senior Management as and when required.
For problems where action or a decision is required, they communicate Directives to
the appropriate ICL Pathway Directorate(s), e.g. change priorities, sanction additional
Tesource.
When appropriate, the CS Management Team responds directly to the ICL Pathway
Management Team, e.g. to answer a non-specific or general question.
In very exceptional circumstances, the ICL Pathway Management Team may use
standard procedures to escalate a selected live problem to ICL Corporate Red Alert
status (CSAC). Any questions or requests relating to the alert report are communicated
to CS Ops Support
5.8.2.4 CS Mgt team escalation to CSAC
In normal circumstances escalation to CSAC will be at the discretion of the ICL PW
Management Team. However, in exceptional circumstances, e.g. Severe Business
Continuity, the CS Director or nominated person may raise an alert directly with
CSAC and provide notification to the ICL PW Management team in Parallel.
© 2000 ICL Pathway Limited COMPANY IN CONFIDENCE Page: 26 of 26