ICL Pathway
FUJ00079865
FUJ00079865
ICL Pathway Customer Service Incident Ref: CS/PRD/074
Management Process
Version: 1.0
Company In Confidence Date: 13/11/00
Document Title:
Document Type:
Release:
Abstract:
Document Status:
Author & Dept:
Contributors:
Reviewed By:
Comments By:
Comments To:
Incident Management
Process Definition
N/A
This document details the ICL Pathway incident management
process. The processes within the document have been
broken down into different levels of detail, starting with a high
level view of incident management detailing the interaction
between the different lines of support, and a low level that
details the process activities within each line of support.
APPROVED
Evandro Manolas - ICL Pathway Customer Service Business
Effectiveness Team
Richard Brunskill, Peter Burden, Paul Curley, Bob Davis, Dave
Fletcher, Steve Gardiner, Mik Peach, Martin Riddell, Dave
Riglar, Mike Stewart, Paul Westfield, David Wilcox.
Evandro Manolas
Distribution: ICL Pathway Library, people who require approved versions
only
© 2000 ICL Pathway Limited Company In Confidence Page: 1 of 1
Last Printed: 06/11/00 11:43
FUJ00079865
FUJ00079865
ICL Pathway ICL Pathway Customer Service Incident Ref: CS/PRD/074
Management Process
Version: 1.0
Company In Confidence Date: 13/11/00
0.0 Document Control
0.1 Document History
Version No. [Date Reason for Issue Associated
(CP/PinICL No.
(0.1 (04/07/00 First draft - to detail the baseline
Incident Management process
41.0 13/11/00 [Developed for approval
0.2 Approval Authorities
Name [Position Signature Date
Peter Burden ‘Support Services
Manager
Martin Riddell (Operations Services
Manager
Paul Westfield Infrastructure
Services Manager
0.3. Associated Documents
Reference Nersion Date Title Source
1. (CS/IFS/007 1.0 HSH /NBSC Interface ICL Pathway
Agreement
2. ICS/MAN/002 {3.0 (07/02/00 \CS Support Operations ICL Pathway
Manual
3. \CS/MAN/005_ 3.0 18/02/00 ICS Infrastructure Services IICL Pathway
(Operations Manual
4. ICS/PRD/021_ 2.0 13/11/00 IICL Pathway Customer ICL Pathway
‘Service Problem
Management Process
5. ICS/PRD/O31 /1.0 24/01/00 IICL Pathway Customer ICL Pathway
Service Business Continuity
Management
6. ICS/PRD/081 [1.0 (05/09/00 IICL Pathway End to End ICL Pathway
(Customer Complaint
Process
7. ICS/PRD/O86 0.1 Release Mgt process for ICL Pathway
Fast-Track Software
Release
© 2000 ICL Pathway Limited
Company In Confidence
Page: 2 of 1
Last Printed: 06/11/00 11:43
FUJ00079865
FUJ00079865
ICL Pathway ICL Pathway Customer Service Incident Ref: CS/PRD/074
Management Process
Version: 1.0
Company In Confidence Date: 13/11/00
8. ICS/PRO/048 1.0 15/06/99 INR2 Horizon System ICL Pathway
[Helpdesk Processes and
Procedures Description
(9. ICS/PRO/111 1.0 16/10/00 ITPS Reconciliation and ICL Pathway
Incident Management
10. IDE/PRO/O15 1.0 25/10/00 IICL Pathway Development IICL Pathway
Directorate Incident/Defect
Management
11. IDSP/PLA/HH/O Horizon System Helpdesk ICL
08 ‘Activities for Call Monitoring Outsourcing
M2. IDSP/PRO/HH/0I1.0 (04/06/98 Horizon System Helpdesk ICL
10 Incident Procedures \Outsourcing
13. PA/PRO/OO1_ I7.0 (07/04/00 (Change Control Process _‘IICL Pathway
14. SU/PRO/001_ [3.0 (02/11/98 IHorizon System Help Desk IICL
(Call Routing Table (Outsourcing
0.4 Abbreviations/Definitions
‘Abbreviation Definition
A&G Advice and Guidance
IBCM Business Continuity Manager
BIMS Business Incident Management System (MSU)
ICS (Customer Service
IDM [Duty Manager
IHSH [Horizon System Helpdesk (ICL Outsourcing)
KEL [Known Error Log (ICL Pathway)
IMBCI [Major Business Continuity Incident
IMSU Management Support Unit (ICL Pathway)
INBSC. Network Business Support Centre (PON)
(OSD (Operational Services Division (of ICL)
OT! Open Teleservice Interface
IRDT IReference Data Team (ICL Pathway)
IRO Roll Out
IPM IProblem Manager
IPO Post Office
IPON Post Office Networks
IRDT [Reference Data Team (ICL Pathway)
© 2000 ICL Pathway Limited Company In Confidence Page: 3 of 1
Last Printed: 06/11/00 11:43
FUJ00079865
FUJ00079865
ICL Pathway ICL Pathway Customer Service Incident Ref: CS/PRD/074
Management Process
Version: 1.0
Company In Confidence Date: 13/11/00
IROHD Roll Out Helpdesk
ISLA Service Level Agreement
ISMC System Management Centre (ICL Outsourcing)
ISSC System Support Centre (ICL Pathway)
ISL IHSH Shift Leader
ISTSA Senior Technical Support Adviser
TSA ITechnical Support Adviser
IUKSS IUK System Service (ICL Outsourcing)
0.5 Changes in this Version
Version (Changes
(0.1 First draft
1.0 Updates to all processes based upon comments to version 0.1
0.6 Changes Expected
(Changes
[Routing from HSH to MSU to change once MSU move from PinICL to Powerhelp
0.7. Process Key
LoL /°O-
Process or activi Sub-Proces Decisior Adelay Process Input Connector Start / Enc The direction c
at lowest level of flow between
detail processes
© 2000 ICL Pathway Limited Company In Confidence Page: 4 of 1
Last Printed: 06/11/00 11:43
ICL Pathway ICL Pathway Customer Service Incident Ref: CS/PRD/074
Management Process
Version: 1.0
Company In Confidence Date: 13/11/00
FUJ00079865
FUJ00079865
0.8 Table of Contents
1. INTRODUCTION
2 SCOPE
3 PROCESS SUMMARY
4 INCIDENT MANAGEMENT PROCESS
4.1 First Line Support
4.11 Log call and verify
4.1.2 Attempt to resolve
4.1.3 Route incident to second line support
4.1.4 Closure
4.2 Second Line Support
4.2.1 The System Management Centre
4.2.2 The UKSS
4.3 Third line support
43.1 The System Service Centre
43.2 The Management Support Unit
4.3.3 The Reference Data Team
43.4 ICL Operational Services Division (3" line support)
4.4 Fourth Line Support
44.1 Fourth line support incident management process
5 INCIDENT MANAGEMENT LINKS TO PROBLEM / BUSINESS CONTINUITY
31
MANAGEMENT
© 2000 ICL Pathway Limited Company In Confidence Page: 5 of 1
Last Printed: 06/11/00 11:43
FUJ00079865
FUJ00079865
ICL Pathway ICL Pathway Customer Service Incident Ref: CS/PRD/074
Management Process
Version: 1.0
Company In Confidence Date: 13/11/00
1
Introduction
Incident Management is a service that encompasses a broad range of teams
and functions, and which links into a variety of many other service
management disciplines. Incident management within ICL Pathway also has
very close links with Incident Management in PON, and there are agreed
communications links between the two organisations.
This document details the baseline processes for incident management within
ICL Pathway.
Scope
Within the document incident management has been broken down to two
different levels.
- The first level (Section 3) provides an overview (deployed) of the complete
incident management process, highlighting the links between the different
levels of support and the support units that exist within each level.
- The next section (Section 4) breaks down of each line of support to lower
level details.
Key factors within the processes include the flow of information, and the
communication links that exist between the different teams and functions.
© 2000 ICL Pathway Limited Company In Confidence Page: 6 of 1
Last Printed: 06/11/00 11:43
FUJ00079865
FUJ00079865
ICL Pathway ICL Pathway Customer Service Incident Ref: CS/PRD/074
Management Process
Version: 1.0
Company In Confidence Date: 13/11/00
3 Process Summary
4st LINE SUPPORT i 2nd LINE SUPPORT 3rd LINE SUPPORT 4th LINE SUPPORTI I Notes:
1. Excludes exceptions
and mis-routing
Resolve
incident 2. This is the key
(DS/PRO/015)
process and ignores
system constrained
routing, e.g. routing
smc
tovaus cone Investigate Resolve Investigate in and out of the
ince incident incident incident MSU is via the SSC.
3. This process also
assumes that initial
routing will be correct
and that there is no
re-routing.
Attempt to
resolve
incident
Verify
caller
Resolve
incident
Resolve
incident
Route to
2nd tine 4
support
Attempt to
resolve
incident
Attempt to
resolve
incident
reports
Customer
Complaint
Process
(CSIPRD/081)
Attempt to
resolve
incident
Links to Problem / Business Continuity Mgt
Incident
Management
process
[Section 4]
Route to Route to
incident 3rdline —-4 4th line
support ‘support
Problem Business
Management Continuity
Mgt Process
© 2000 ICL Pathway Limited Company In Confidence Page: 7 of 1
Last Printed: 06/11/00 11:43
FUJ00079865
FUJ00079865
ICL Pathway ICL Pathway Customer Service Incident Ref: CS/PRD/074
Management Process
Version: 1.0
Company In Confidence Date: 13/11/00
4 Incident Management Process
This section looks more cl
losely into what happens at each level of support,
starting with first line support through to fourth line support. Each section will
explain the inputs and outputs for each line of support and the activities that
are carried out within the support function.
4.1 First Line Support
First line support within ICL Pathway is provided by the HSH.
“The HSH deal with all technical and operational calls related to the ICL
Pathway environment or the data feeds into ICL Pathway from PON and their
clients. It provides a single point of contact for outlet staff and ICL Pathway
operation staff.” [Ref.8]
The incident management system used by the HSH is ‘Powerhelp’.
This section looks at:
@ the inputs into the HSH
@ the process activities that the HSH go through on receipt of an input
¢@ the outputs of the HSH
Inputs HSH Process Activities Outputs
Post Office Sites
NBSC (PON)
PON Clients —_—_>
All Pathway supporting
organisations
PON business units
Other supporting organisations
Resolved (Closed) Incident
Passed to NBSC
HSH [Routed to SMC
Routed to UKSS
Escalation
Referral to PM/BCM
Routed to Roll Out Helpdesk
© 2000 ICL Pathway Limited
Company In Confidence Page: 8 of 1
Last Printed: 06/11/00 11:43
FUJ00079865
FUJ00079865
ICL Pathway ICL Pathway Customer Service Incident Ref: CS/PRD/074
Management Process
Version: 1.0
Company In Confidence Date: 13/11/00
4.1.1 Log call and verify
A2 AS
a Call to thi
all to the a
START HSH Receive caller
(Caller quotes
HSH ref.) ae oe
Existing Update incident
incident? record and inform
/ caller of progress
AT
Log Call Open a new
incident
Yes IA"
Caller passed Take call NBSC
- erificationy details referral?
Verify Caller
Ag
Inform caller that
call can not be
continued
Incident
resolution
process
(Section 4.1.2)
Appropriate
call?
A15
A14
Close incident
(Section 4.1.4)
Refer caller
to the NBSC
A call to the HSH can derive from a number of sources (see Section 4.1). If
the caller is ringing for an update on a particular incident the HSH provide the
caller with details of the present situation as indicated within the incident
record on Powerhelp.
If the call is a new call the HSH open a new incident record on Powerhelp and
then verify the caller [Ref.12]. If the caller fails verification the incident is
closed and no further action is taken. If the caller passes verification the HSH
take the details of the call.
If the HSH determine that the call has come through to the wrong helpdesk,
the caller is provided with the details of the NBSC and the call closed. The
only exception to this being if the caller has already been referred to the
helpdesk by the NBSC, in which case the HSH will progress the incident
[Ref.1].
© 2000 ICL Pathway Limited Company In Confidence Page: 9 of 1
Last Printed: 06/11/00 11:43
FUJ00079865
FUJ00079865
ICL Pathway ICL Pathway Customer Service Incident Ref: CS/PRD/074
Management Process
Version: 1.0
Company In Confidence Date: 13/11/00
4.1.2 Attempt to resolve
A16 1A18 A19
Pass incident
Verified to NBSC J Until incident
incident & cross-refer resolved
helpdesk no.'s
A22 1A20
Inform caller that Close Incident
call will be passedI Section 4.1.4)
to the ROHD (Section 4.1.4)
A23 A25
Route call to
Route call to Resolve via second line
the ROHD A&G? support
(Section 4.1.3)
A24 1A30
Investigate Provide advice
incident and guidance
A26
RollOut Resolve Incident Pass incident
Helpdesk incident resolved? to NBSC?
v Yes
1A27 1A33
Pass incident
Close to NBSC &
incident cross-refer
helpdesk ref no's
1A34
A28
Close incident
END (Section 4.1.4)
The HSH will decide whether or not the incident requires immediate routing to
2°¢ line support, or whether or not the call can be resolved via Advice and
Guidance. If, after providing Advice and Guidance, the incident is still
unresolved, it is routed to 2" line support.
If the incident has been resolved after providing advice and guidance the
HSH close the incident (See Section 4.1.4 for closure process).
© 2000 ICL Pathway Limited
Company In Confidence
Page: 10 of 1
Last Printed: 06/11/00 11:43
FUJ00079865
FUJ00079865
ICL Pathway ICL Pathway Customer Service Incident Ref: CS/PRD/074
Management Process
Version: 1.0
Company In Confidence Date: 13/11/00
4.1.3 Route incident to second line support
A35
Incident
requiring
second line
suppport
A39 Ado
Check opening
hrs & advise PO PJ} Route call
of ‘no later than’ to the UKSS
time for engineer
Engineer
required?
A441
ukss
process
(Section 4.2.2.1)
A37 Ad2
Route call = _______ 3} Monitor incident
to the SMC (Section 4.1.3.1)
IA38
smc
process
(Section 4.2.1.1)
When routing an incident to second line support, the HSH can route the
incident to the UKSS (Section 4.2.2.1) if it is determined that an engineer is
required on site, or to the SMC (Section 4.2.1.1). See [Ref.14] for routing
criteria.
Having routed an incident to second line support the HSH will monitor it until
the incident has been resolved and is ready for closure. See Section 4.1.3.1
for the monitoring process.
© 2000 ICL Pathway Limited Company In Confidence Page: 11 of 1
Last Printed: 06/11/00 11:43
FUJ00079865
FUJ00079865
ICL Pathway ICL Pathway Customer Service Incident Ref: CS/PRD/074
Management Process
Version: 1.0
Company In Confidence Date: 13/11/00
4.1.3.1 Monitoring
A43 Aaa IA46
Regular Check incident PON action
incident resolution required? Suspend call
monitor progress
No
Incident
resolved?
Close incident
(Section 4.1.4)
1A47
Until PON
accomplished
action
(A49
Escalate the
incident
The HSH regularly monitor calls that are passed to second line support. If an
incident requires action to be taken by PON or one of the outlets, then the call
is suspended until the action has been completed. The purpose of this is to
stop the SLA clock since ICL Pathway are unable to take action to resolve the
incident whilst PON or an outlet need to carry out certain tasks.
If a call is in danger of not meeting its SLA, the incident is escalated.
© 2000 ICL Pathway Limited
Company In Confidence
Page: 12 of 1
Last Printed: 06/11/00 11:43
FUJ00079865
FUJ00079865
ICL Pathway ICL Pathway Customer Service Incident Ref: CS/PRD/074
Management Process
Version: 1.0
Company In Confidence Date: 13/11/00
4.1.4 Closure
A52
Requirement
to close an
incident
No IA54
Contact
losure approval originator to
agree closure
A58 As9 nt
‘oute call to
Closure Able to Route call to second line
agreed? resolve? second we support
Suppo (Section 4.1.3)
IA64
Close incident
Resolve incident
Escalate?
jA63.
Until closure
agreed
IA62
Escalate the
incident
A Powerhelp incident can be closed by the HSH or by the SMC. However,
before closing an incident, the HSH/SMC check to ensure that, where
required, the originator of the call has agreed to close the incident. If
agreement has not been obtained, it must be sought.
If agreement is not obtained, the incident may have to be sent back to second
line support for resolution if it can not be resolved within first line support. If
there is any dispute as to whether the incident has been resolved, the issue is
escalated.
© 2000 ICL Pathway Limited
Company In Confidence
Page: 13 of 1
Last Printed: 06/11/00 11:43
ICL Pathway
ICL Pathway Customer Service Incident Ref:
Management Process
Company In Confidence
CS/PRD/074
Version: 1.0
Date: 13/11/00
FUJ00079865
FUJ00079865
4.2 Second Line Support
Second line support within ICL Pathway is provided by:
- The System Management Centre (SMC)
- UK System Service (UKSS)
4.2.1 The System Management Centre
The System Management Centre (SMC) provides second line support to the
HSH, and also use Powerhelp as their incident management system.
Inputs
HSH
SMC
Outputs
Resolved incident
Routed to SSC
Routed to OSD
Routed to UKSS
Routed to MSU (via SSC)
© 2000 ICL Pathway Limited
Company In Confidence
Page: 14 of 1
Last Printed: 06/11/00 11:43
FU.
ICL Pathway ICL Pathway Customer Service Incident Ref: CS/PRD/074
Management Process
Version: 1.0
Company In Confidence Date: 13/11/00
4.2.1.1 SMC Incident resolution / routing
B1 B2
Incident Analyse
received incident
B3
Close
incident
(Section 4.1.4)
Close
incident?
BB
UKSS
process
(Section 4.2.2.1)
B11
Until original
incident
resolved?
B14
Close
incident
(Section 4.1.4)
87 ae
Route incident to
UKSS & update Re-route
Powerhelp 10 UKSS3
B10
Yes“ B9
Associate uplicat
duplicate call uplicate
to original call ?
Attempt to res
B13
Apply Resolve with
KEL KEL?
B16
Route
incident to third Route to Third
line support Line Support
B17
SSC or
OSD?
ssc osD
process process
(Section 4.3.1.1) (Section 4.3.4.1)
© 2000 ICL Pathway Limited
Company In Confidence Page: 15 of 1
Last Printed: 06/11/00 11:43
FUJ00079865
IJ00079865
Investigate Incident
‘olve
FUJ00079865
FUJ00079865
ICL Pathway ICL Pathway Customer Service Incident Ref: CS/PRD/074
Management Process
Version: 1.0
Company In Confidence Date: 13/11/00
On receipt of an incident, and after having analysed it, the SMC can either:
Resolve the incident with a KEL.
Determine that the incident is a duplicate call and link it to the original.
Decide that the call requires a UKSS engineer to visit the site (Section
4.2.2.1).
Or, failing any of the above, route the call to Third Line Support for further
investigation, either the SSC (Section 4.3.1.1) or OSD (Section 4.3.4.1).
In some cases, following analysis, the SMC will be able to close the incident
(Section 4.1.4). This happens in situations where an incident has been routed
back to the SMC, from either UKSS or third line support, for closure.
In other cases, the SMC may be required to carry out checks on an incident
returned for closure, to ensure that it has been resolved. If the incident fails
the checks, it is routed back to the appropriate support unit for further
analysis.
© 2000 ICL Pathway Limited Company In Confidence Page: 16 of 1
Last Printed: 06/11/00 11:43
FUJ00079865
FUJ00079865
ICL Pathway ICL Pathway Customer Service Incident Ref: CS/PRD/074
Management Process
Version: 1.0
Company In Confidence Date: 13/11/00
4.2.2 The UKSS
The UKSS provide engineer support for the Horizon system hardware at the
Post Office outlets via second line support to the HSH and the SMC.
© 2000 ICL Pathway Limited Company In Confidence Page: 17 of 1
Last Printed: 06/11/00 11:43
FUJ00079865
FUJ00079865
ICL Pathway ICL Pathway Customer Service Incident Ref: CS/PRD/074
Management Process
Version: 1.0
Company In Confidence Date: 13/11/00
C1 c2
Incident Assign
received Engineer
C3 Send an
engineer to sit
Site visit by
engineer
c4
Investigate and Resolve incidei
verify h/w fault
Hardware
fault?
C6 Route call
back to P'help
with instruction
to re-route
c8
Call originated
from HSH?
HSH process
(Section 4.1.3)
SMC process
(Section 4.2.1.1)
4.2.2.1 UKSS Incident management
C10
Repair fault
>) acceptance to
C11
Gain Postmasters
close call
¥
C12
Clear call on
remote system
¥
C13
Route call back
for closure
C14
Closure process
(Section 4.1.4)
There is an OTI link between Powerhelp and the systems used by UKSS for
incident management. Once an incident is routed to the UKSS an engineer is
automatically assigned to the call.
© 2000 ICL Pathway Limited
Company In Confidence
Page: 18 of 1
Last Printed: 06/11/00 11:43
FUJ00079865
FUJ00079865
ICL Pathway ICL Pathway Customer Service Incident Ref: CS/PRD/074
Management Process
Version: 1.0
Company In Confidence Date: 13/11/00
Having been assigned an incident the UKSS engineer visits the affected site.
If, on investigation, the engineer determines that no hardware fault exists, the
call is routed back to Powerhelp to be re-routed for resolution appropriately.
If the incident is confirmed as a hardware fault, the engineer carries out the
necessary repairs. Once the work has been completed, in order to close the
incident, the engineer must have acceptance from the Postmaster that the
fault has been repaired. This is done via the Postmaster signing an
acceptance card (SVR card). The engineer clears the call on their remote
system.
Clearing the call on the remote system routes the incident back to Powerhelp
to indicate that the call has been resolved and can be closed.
© 2000 ICL Pathway Limited Company In Confidence Page: 19 of 1
Last Printed: 06/11/00 11:43
FUJ00079865
FUJ00079865
ICL Pathway ICL Pathway Customer Service Incident Ref: CS/PRD/074
Management Process
Version: 1.0
Company In Confidence Date: 13/11/00
4.3 Third line support
Third line support is provided by:
- The System Service Centre (SSC)
- Outsourcing Services Division (OSD)
- The Management Support Unit (MSU)
- The Reference Data Team (RDT)
4.3.1 The System Service Centre
“The aim of the SSC is to provide a support capability to Pathway that
resolves technical problems in the minimum time and with the minimum
amount of disruption to the service. The SSC aims to provide a centre of
technical expertise for Customer Service, providing technical advice,
guidance, and expertise relating to all parts of the Pathway system”. [Ref.2]
The SSC uses PinlCL as its incident management system and diagnostic
database.
Inputs Process Outputs
Resolved incident
Routed to MSU
SMC ——> ssc fs Routed to RDT
Routed to 4th line support
Referral to PM/BCM.
Note: For further information about the SSC see [Ref.2].
© 2000 ICL Pathway Limited Company In Confidence Page: 20 of 1
Last Printed: 06/11/00 11:43
FUJ00079865
FUJ00079865
ICL Pathway ICL Pathway Customer Service Incident Ref: CS/PRD/074
Management Process
Version: 1.0
Company In Confidence Date: 13/11/00
4.3.1.1 SSC Incident Management process
FA F2 F7 Route FB
back to the SMC
Incident Investigate Appropriate to re-route to f=} SMC Process
received incident incident? appropriate (Section 4.2.1.1)
support unit
F10 F114
Route
MSU Process
eter (Section 4.3.2.1)
ONS F14
Route
- Ref Data RDT Process
Investigat the incident i
9 error? to the RDT (Section 4.3.3.1)
No
FIs is 6 h ‘ FAT
‘oute the incident]
Known ack tothe SMC [>] SMC Process
error? for resolution (Section 4.2.1.1)
FA9 F20
Associate SSC closure
Attempt Duplicate? duplicate PinicL [I process.
to resolv to original PinICL. (Section 4.3.1.3)
24 F26 F29
Raise a Develop, test Potential
KEL and authorise problem/MBCI
workaround (Section 4.1.4.1)
F35 Collect F28
Yes,
evidence and Raise a problem
Ipropose a solution] Pass to te pl ATP.
if possible Sth line? to agree
F36 Route F38 F30
Incident PinICL +
supporting info to Resolve worthy fT oe
4th line support
F37 F39 F32
4th Line Support SSC closure Raise a Add Fs
Process process business incident workaround END
(Section 4.4.1) (Section 4.3.1.3) ‘on the HSH to KEL
F43
HSH Process
(Section 4.1.1)
© 2000 ICL Pathway Limited Company In Confidence Page: 21 of 1
Last Printed: 06/11/00 11:43
FUJ00079865
FUJ00079865
ICL Pathway ICL Pathway Customer Service Incident Ref: CS/PRD/074
Management Process
Version: 1.0
Company In Confidence Date: 13/11/00
There is an OTI link between Powerhelp and PinlCL (the incident
management system used by the SSC). On receipt of an incident PinICL the
SSC investigate the incident.
If on investigation the SSC determine that:
- The incident was incorrectly routed, it is passed backed to the SMC to
route to the appropriate support unit (Section 4.2.1.1).
- The incident is a business incident, and not system related, it is routed
through to the MSU (Section 4.3.2.1).
- The incident is a reference data incident it is routed through to the
Reference Data Team (Section 4.3.3.1).
- The incident is a known error, it is passed backed to the SMC to deal with
(Section 4.2.1.1)
- The incident is already known, i.e. it is a duplicate incident, the SSC
associate the duplicate PinICL to the original PinlICL and close the
duplicate PinICL. Go to Section 4.3.1.3 for the SSC closure process)
If the none of the above apply, the incident is either resolved by the SSC or
routed to 4" line support for resolution. However, a decision first has to be
made as to whether a business incident is associated with the incident being
dealt with. If so, the SSC will raise a new business incident with the HSH
(Section 4.1.1).
The SSC raise a KEL for incidents that they have not come across before and
require further work and time before they are resolved. This is then used by
the SMC to stop duplicate incidents being sent through to the SSC.
If a workaround can be developed, it is added to the respective KEL to be
used as required. If the workaround requires agreement from PON, a Problem
is raised to obtain the agreement.
If the incident can not be resolved by the SSC, it is passed to 4" line support
(Section 4.4.1) for resolution. If the SSC can resolve the incident, the
appropriate actions are taken until the incident is ready for closure (Section
4.3.1.3).
© 2000 ICL Pathway Limited Company In Confidence Page: 22 of 1
Last Printed: 06/11/00 11:43
FUJ00079865
FUJ00079865
ICL Pathway ICL Pathway Customer Service Incident Ref: CS/PRD/074
Management Process
Version: 1.0
Company In Confidence Date: 13/11/00
4.3.1.2 Monitoring and Updating
F45
Monitor incidents
TP passed to 4th line
ras support
F47
Monitoring
requirement
Update PinICLs
with progress
F46
LJ Monitor incidents
upon SSC stack
F49
Update Powerhelp
with PinICL
details
Relevant to
P*help?
No
F50
Continue }g-——__]
monitoring
The SSC monitor all the incidents passed to them through to closure. The
monitoring function extends to those incidents that are awaiting resolution on
the SSC’s incident stack and those incidents that are passed to 4" line
support for resolution.
The SSC update the incident PinlICL with regular progress reports on the
status of the incident resolution.
If the update is relevant to the HSH/SMC it is passed backed to the
Powerhelp system.
The monitoring function is a continual operation.
4.3.1.3 Closure
F51 F52 F53
PinICL. Agree closure Close PinICL and
ready for of incident [9 route back to the
closure with originator SMC for closure
Once the SSC has resolved an incident, or received an incident back from 4".
line support for closure, the PinICL can be closed. The SSC contact the
originator of the incident to agree that it can be closed.
Once agreement for closure has been reached, the SSC close the incident
PinlCL. The incident is then returned back to the SMC (Section 4.2.1.1).
F54
SMC Process
(Section 4.2.1.1)
© 2000 ICL Pathway Limited Company In Confidence Page: 23 of 1
Last Printed: 06/11/00 11:43
FUJ00079865
FUJ00079865
ICL Pathway ICL Pathway Customer Service Incident Ref: CS/PRD/074
Management Process
Version: 1.0
Company In Confidence Date: 13/11/00
4.3.2 The Management Support Unit
“Reconciliation [business] incidents may arise for a number of different
reasons. In all cases there is a mismatch between the information held in
different parts of the ICL Pathway system. The task of the Management
Support Unit (MSU) is to investigate and financially resolve reconciliation
incidents. If a similar reconciliation incident occurs a number of times, the
MSU identifies it as a problem incident to be managed through the problem
management process. [Ref.3]
4.3.2.1 The MSU Incident Management Process
a1 G3 G4
Incident Duplicate Attach details to BIMS process
received incident? existing BIMS [CSIPRO/111]
G7 G5
Initiate BIMS Inform HSH to
rocess close duplicate
bs incident
G8 G6
HSH closure
Linked system BIMS process process
[CS/PRO/111] (Section 4.1.4)
G9
Until BIMS
‘cleared’
G15 Is10
Raise a system aac
incident with the Return incident
HSH
G16 G14
HSH incident HSH closure
logging process process
(Section 4.1.1) (Section 4.1.4)
Currently, all MSU incidents are received via the SSC.
© 2000 ICL Pathway Limited Company In Confidence Page: 24 of 1
Last Printed: 06/11/00 11:43
FUJ00079865
FUJ00079865
ICL Pathway ICL Pathway Customer Service Incident Ref: CS/PRD/074
Management Process
Version: 1.0
Company In Confidence Date: 13/11/00
If on investigation the MSU notice that the incident is a duplicate, the details
of the duplicate incident are added to the existing BIMS report [Ref.9], and
the duplicate incident is closed.
If the incident is new, the MSU log the details into the BIMS/MER report
[Ref.9].
If it is not a duplicate incident the MSU initiate the BIMS process [Ref.9]. This
is the process used by the MSU to deal with the business incident. Once the
reconciliation details have been obtained by the MSU to settle the business
fault with PON (i.e. the BIMS has been ‘cleared’, the incident can be closed.
lf the MSU identify that a system fault is linked to the business incident, and
that the system fault has not yet been raised as an incident, the MSU will
raise a system fault with the HSH.
Note: MSU contact to the HSH is via the SSC.
© 2000 ICL Pathway Limited Company In Confidence Page: 25 of 1
Last Printed: 06/11/00 11:43
ICL Pathway
ICL Pathway Customer Service Incident
Management Process
Company In Confidence
FUJ00079865
FUJ00079865
Ref: CS/PRD/074
Version: 1.0
Date: 13/11/00
4.3.3 The Reference Data Team
Reference Data related incidents are routed through to the Reference Data
Team (RDT) for analysis and resolution. As with the SSC, the RDT use
PinlCL as their incident management system.
4.3.3.1. The RDT Incident Management Process
H1 H2
Incident Investigate
received from, incident
the SSC
H4
Route incident
back to SSC
H7
Email
PON RD with
copy of the PinICLI
and HSH ref no.
H10 H8
Route
incident PinICL +
supporting info to
4th line support
Until incident
accepted by
PON
H11
Fourth Line
Support process
(Section 4.4.1)
Resolve incident
A
H14
Route incident
back via the SSC
for closure
H13
Until incident
resolved
H15
SSC process
(Section 4.3.1.3)
HS
SSC process
(Section 4.3.1.1)
© 2000 ICL Pathway Limited
Company In Confidence
Page: 26 of 1
Last Printed: 06/11/00 11:43
FUJ00079865
FUJ00079865
ICL Pathway ICL Pathway Customer Service Incident Ref: CS/PRD/074
Management Process
Version: 1.0
Company In Confidence Date: 13/11/00
RDT investigate the incident routed to them by the SSC, and check to ensure
that the incident is a reference data fault. If it is not, it is routed back to the
SSC for further investigation (Section 4.3.1.1).
If the incident is confirmed as a reference data fault, RDT decide whether
PON are responsible for its resolution. If so, RDT send the appropriate PON
team an email, which includes a copy of the PinICL and the HSH incident
reference number, requesting the PON team to resolve the incident. Once
PON have replied to the RDT and accepted responsibility for resolution, RDT
send the PinlCL incident back, via the SSC, for closure (Section 4.3.1.3).
If ICL Pathway is responsible for resolution, RDT decide whether they are
able to resolve the incident, or if it must be routed through to 4" line support
for resolution. If the incident requires resolution by 4" line support RDT route
the incident via PinICL to 4" line support (Section 4.4.1).
If RDT are responsible for resolution, they initiate procedures to resolve the
incident. Once the incident is resolved, it is sent back via the SSC, for closure
(Section 4.3.1.3).
© 2000 ICL Pathway Limited Company In Confidence Page: 27 of 1
Last Printed: 06/11/00 11:43
FUJ00079865
FUJ00079865
ICL Pathway ICL Pathway Customer Service Incident Ref: CS/PRD/074
Management Process
Version: 1.0
Company In Confidence Date: 13/11/00
4.3.4 ICL Operational Services Division (3" line support)
OSD provide the same level of third line support as the SSC. The difference
being that in general the SSC provide 3” line support for software incidents,
whereas the OSD, in general, provide 3” line support for network and central
system related incidents.
4.3.4.1 OSD Incident Management Process
J
Incident
received from,
the SMC
J4 J5
Bend incident bach
to the SMC for
re-routing
J2
J3
Correctly
routed?
SMC process
(Section 4.2.1.1)
Investigate
incident
J6
Resolve
incident
J7
Until
incident
resolved
J8
Route incident
back for closure
J9
Closure process
(Section 4.1.4)
© 2000 ICL Pathway Limited Company In Confidence Page: 28 of 1
Last Printed: 06/11/00 11:43
FUJ00079865
FUJ00079865
ICL Pathway ICL Pathway Customer Service Incident Ref: CS/PRD/074
Management Process
Version: 1.0
Company In Confidence Date: 13/11/00
On receipt of an incident from the SMC, OSD investigate the incident.
On occasion the OSD may determine that the incident has been incorrectly
routed, and is not an incident that the OSD can resolve. If this is the case the
incident is routed back to the SMC for re-routing, informing them as to where
the incident should be sent for resolution (Section 4.2.1.1).
If the incident does belong within OSD, the appropriate measures are taken
to resolve the incident.
Notes
i. OSD 3” line support is split into different units. The SMC is able to route an
incident to one of four of the OSD units. These are known as:
CFM1 (Unix/NT)
CFM3 (Networks)
CFM5 (Service Management)
CFM6 (VME)
ii. OSD also use 4" line support resource if they are unable to resolve an
incident themselves. However, since OSD are a supplier to ICL Pathway,
links to OSD’s 4" line support are not dealt with within this document.
© 2000 ICL Pathway Limited Company In Confidence Page: 29 of 1
Last Printed: 06/11/00 11:43
FUJ00079865
FUJ00079865
ICL Pathway ICL Pathway Customer Service Incident Ref: CS/PRD/074
Management Process
Version: 1.0
Company In Confidence Date: 13/11/00
4.4 Fourth Line Support
Fourth line support is the final level of support within the ICL Pathway
incident management process. If an incident is routed through the first three
levels of support, it is resolved by fourth line.
© 2000 ICL Pathway Limited Company In Confidence Page: 30 of 1
Last Printed: 06/11/00 11:43
FUJ00079865
FUJ00079865
ICL Pathway ICL Pathway Customer Service Incident Ref: CS/PRD/074
Management Process
Version: 1.0
Company In Confidence Date: 13/11/00
K1 K2 K4
Ne Return incident to
Incident Investigate Progress for "
received incident esolution?, Srd line support
with reasons
Ly
Ko
K7
ROT process
(Section 4.3.3.1)
Initate CP
process
¥
K11
Incident routed to
appropriate
development unit
Change
Management
process
[PA/PRO/001]
SSC process
(Section 4.3.1.1)
K12
Incident impacted
by appropriate
development unit
K13
Incident routed toI
RMF stack
(Code 55 - Live
Imapct supplied) development unit
K16 Deferred
PinICL routed to
incident
appropriate
K14
Release
Management
Process
[CS/PRD/086]
K18
Incident returned
to 3rd line suppot
for closure
K19
SSC closure
process
(Section 4.3.1.3)
K21
Incident PiniCL
sent back to
development unit
Incident
Yes
K20
Release
stopped?
OTT testing
uccessfulZ
K22 k23
New PinICL raised} New PiniCL sent
and linked to [9] to appropriate
original PinicL development unit
4.4.1 Fourth line support incident management process
On receipt of an incident, 4" line support initiate investigation procedures
[Ref.10]. In some cases, 4" line may be able to resolve the incident without
the need for any development, or they may decide that the incident does not
require progression through fourth line. If so, the incident is routed back to 3"
line support detailing the action to be taken to resolve the incident.
© 2000 ICL Pathway Limited
Company In Confidence Page: 31 of 1
Last Printed: 06/11/00 11:43
FUJ00079865
FUJ00079865
ICL Pathway ICL Pathway Customer Service Incident Ref: CS/PRD/074
Management Process
Version: 1.0
Company In Confidence Date: 13/11/00
If a CP is required, the Change Management process is initiated and the
incident PinICL returned to 3” line support.
If a CP is not required, the incident is sent to the appropriate development to
impact. Once impacted the Release Management Process takes over [Ref.7].
The incident is returned to 3% line support once testing has proved to be
successful.
© 2000 ICL Pathway Limited Company In Confidence Page: 32 of 1
Last Printed: 06/11/00 11:43
FUJ00079865
FUJ00079865
ICL Pathway ICL Pathway Customer Service Incident Ref: CS/PRD/074
Management Process
Version: 1.0
Company In Confidence Date: 13/11/00
5 Incident Management links to Problem / Business
Continuity Management
In incident can lead to a Problem [Ref.4] or a Business Continuity Incident
[Ref.5] being raised.
At any stage in the incident management process, within any line of support,
a problem can be raised. In most cases a problem will be identified at first line
support through the identification of a trend of similar incidents or a single
incident.
When raising a problem or a business continuity incident, the Customer
Service Duty Manager is paged. The Duty Manager (DM) determines if a
problem or business continuity incident exists and takes the appropriate
action. If the DM determines that neither a problem or business continuity
incident exist, the originator is informed and no further action taken.
Pt P2
Potential eae bed
Problem ! [Problem
Notifier]
v
P3
Obtain details
from problem
notifier
[DM]
Ps P6
Assign a Problem Problem
Manager to the Je} Management
problem Process
[DM] (CS/PRD/021)
P4
Problem?
PS Pg Business
Continuity
Inform BCM of
situation a Management
(DM) rocess
(CS/PRD/031)
P41. Inform
notifier that
no further action
is being taken
[DM)
© 2000 ICL Pathway Limited Company In Confidence Page: 33 of 1
Last Printed: 06/11/00 11:43