FUJ00079875
FUJ00079875
ICL Pathway Ltd Operations Manual for Customer Service Directorate Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
Document Title: Operations Manual for the Customer Service Directorate
Document Type: Manual
Release: N/A
Abstract: This document outlines the organisation and services provided
by the Customer Service Directorate within ICL Pathway
Document Status: Approved
Originator & Dept: A. Nicholson, Business Effectiveness Team
Contributors: Richard Brunskill, Dave Law, Mike Stewart, Pat Lywood, Reg
Barton, Graham Hooper, Eric Hillier, Dave Wilcox, Dean Felix
Reviewed By: Peter Burden, Richard Brunskill, Dave Law, Mike Stewart, Pat
Lywood, Reg Barton, Graham Hooper, ic Hillier, Dave
Wilcox, Dean Felix
Comments By:
Comments To:
Distribution: Customer Service Management Team
ICL Pathway Document Management
ICL Pathway BMS Site
ICL Pathway Programme Directorate, Business Effectiveness
Team (for maintenance)
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 1 of 92
ICL Pathway Ltd Operations Manual for Customer Service Directorate Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
0.0 Document Control
0.1 Document History
Version No. I Date
Reason for Issue
0.1 26/9/01 First Draft
0.2 22/11/01 Issued for internal review
1.0 26/11/01 Updated following incorporation of review comments and
issued as approved
0.2 Approval Authorities
‘Name Position Signature Date
Martin Riddell Director, Customer Service
0.3 Associated Documents
Reference Version I Date Title Source
CS/QMS/001 Customer Service Policy Manual I ICL
Pathway
CS/QMS/002 Customer Service Process Manual I ICL
Pathway
CS/PRO/105 Local Procedure when raising a I ICL
Purchase Order Pathway
CS/PRD/021 ICL Pathway CS Problem I ICL
Management Process Pathway
CS/PRD/023 ICL Pathway Office Desktop I ICL
Ordering Process Pathway
CS/PRD/029 Process for Operational Business I ICL
Change - Outlet Pathway
CS/PRD/030 Process for Operational Business I ICL
Change - Product Pathway
CS/PRD/031 ICL Pathway Business Continuity I ICL
Management Pathway
CS/PRD/050 Process for Operational Business I ICL
Change Reference Data Pathway
CS/PRD/058 Interface agreement for Reference I ICL
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 20f 92
FUJ00079875
FUJ00079875
FUJ00079875
FUJ00079875
ICL Pathway Ltd Operations Manual for Customer Service Directorate Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
Data Pathway
CS/PRD/074 ICL Pathway Incident I ICL
Management Process Pathway
CS/PRD/076 Service Visit Reply Card Process I ICL
Pathway
CS/PRD/081 ICL Pathway CS End to End I ICL
Customer Complaints Process Pathway
CS/PRD/086 Release management Processes ICL
Pathway
CS/PRD/090 Operational Business Change- I ICL
Outlet Change-Invoicing Process I Pathway
CS/PRD/093 ICL Pathway Divisional Alert I ICL
Process Pathway
CS/PRD/102 ICL Pathway Field Service I ICL
Management Process Pathway
Unless a specific version is referred to above, reference should be made to the current
approved versions of the documents.
0.4 Abbreviations/Definitions
AIS Application Interface Specification
AP Automated Payment
APS Automated Payment Service
BMS Business Management System
BRE Business Research Establishment
BSA Business Support Analyst
CA Contracting Authorities
CcP Change Control Proposal
CD Counter Development
CEM Call Enquiry Matrix
CM Configuration Management
cP Change Proposal
cs Customer Service
CSPM Customer Service Problem Manager
© 2001 ICL Pathway Ltd
Commercial in Confidence
Page: 3 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd Operations Manual for Customer Service Directorate Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
CTO Client take on
DM Duty Manager
DN Draft note
DPA Data Protection Act
EPOSS Electronic Point of Sale Service
FRMS Fraud Risk Management Service
HSH Horizon System Helpdesk
HSRF Horizon Service Review Forum, a joint review of the service held
between POL and ICL Pathway
HSSM Horizon System Service Management
IRF Invoice Request Form
MCVP Management Care Visit Programme
MIS Management Information Systems
MSU Management Support Unit
MTBF Mean Time Between Failures
NBSC Network Business Support Centre, part of POL’s organisation
OBC Operational Business Change
OLA Operational Level Agreement
ORR Operational Readiness Review
OSG Main ICL Pathway contact in POL for product change
OSR Operational Service Review
PinICL A problem incident notice raised by ICL Pathway
PM Problem Manager
PMD Problem Management Database
PMS Pathway Security Manager
POL Post Office Limited
PORF Purchase Order Request Form
PPD Processes and Procedures Description
PVCS A Proprietary Configuration Management System developed by
‘Merant International Ltd'
QMS Quality Management System
© 2001 ICL Pathway Ltd
Commercial in Confidence Page: 4o0f 92
ICL Pathway Ltd
FUJ00079875
FUJ00079875
Operations Manual for Customer Service Directorate Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
RDCC Reference Data Change Catalogue
RDMC Reference Data Management Centre (a ICL Pathway database)
RDS Reference Data System (a POL database)
RDT Reference Data Team
RED Reconciliation Exception Database
RTR Real Time Recording
SLA Service Level Agreement
SLAM Service Level Agreement Monitor
SLCA Service Level Contract Administrator
SMB Service Manager - Benchmarking
SMC System Management Centre
SSC System Support Centre
TIP Transaction Information Processing
0.5 Changes in this Version
Version
‘Changes
1.0
Inclusion of relevant comments following internal Cs review
0.6 Changes Expected
Changes —
“Updated as a result of future planned review schedule
© 2001 ICL Pathway Ltd Commercial in Confidence Page: Sof 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd Operations Manual for Customer Service Directorate CS/QMS/007
Version: = 1.0
Commercial in Confidence 26/11/01
0.7 Table of Contents
1 INTRODUCTION 7
2 ORGANISATION 8
3 SERVICES PROVIDED 9
3A System Support Centre 9
3.2 Client Interface Management 20
3.3 Operations Services 23
3.4 Operational Support Services 27
3.5 Reference Data Management 29
3.6 Message Broadcast Service 33
3.7 Outlet Business Change 34
3.8 Field Service Management 36
3.9 Service Management 37
3.10 Problem Management 42
3.1 New Service Introductions 46
3.12 Management Support 58
3.13 Security Management 73
3.14 Management Accounting 90
3.15 Management Planning 1
© 2001 ICL Pathway Ltd
Commercial in Confidence
Page: 6 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd —_ Operations Manual for Customer Service Directorate —_ Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
1 Introduction
The mission statement of the Customer Service Directorate is:
“We provide cost effective services to the Post Office which meets our SLAs
The Post Office regard us as a valued partner
ICL see us as the ‘best of breed’ service organisation”
This Operations Manual defines the key services that are provided by Customer
Service to underpin the Mission Statement.
The following information is detailed:
© Roles/Responsibilities
¢ Key processes owned/used
¢ Customer/Supplier Interfaces (e.g. Formal reviews held)
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 7 of 92
ICL Pathway Ltd
Operations Manual for Customer Service Directorate Ref:
FUJ00079875
FUJ00079875
CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
2 Organisation
At the time of approval of this plan the top-level organisation chart is as follows:
For the latest version please refer to the “organisation charts” section of the ICL
Pathway BMS intranet site.
Wain
Customer Senice Decor
‘Suzanne Smith Rosemary Wells
PA Secretary + Management Accountant
Peter Burden Graham Hooper Pat Lywood Paul Westfield
Operafons Seourty Manager Service Introduction Manager Infrastructure Services Manager
& Support Services Manager
WikPeach
FSi Sit Cente
Mie Stevart
pats Seis
Dave Wilcox
Reference Data
Jot ight
Cele
Tenia Rejnals
“Si Bess Constant
Peter Robinson I Eric Hillier
Business Consubant [> Senior Problem Manager
Sela Banber
Release Manager
I Vetr Gough
Buses At
‘Maer Serves ireducton
Reg Baton Richard Bs OweLar
Fie Senice Manager Nenagenen Supt erage Seg Svices Menage
Fi See Manage Bases Supa Osta Bsness Ooge
(oLPatg LT. Serica Maagenent
peat Seices
SeveePerkmarce
© 2001 ICL Pathway Ltd
Commercial in Confidence Page: 8 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd —_ Operations Manual for Customer Service Directorate —_ Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
3 Services Provided
3.1 System Support Centre
3.1.1 Overview
The principles by which the SSC operates are documented in End-to-End
Support Process Operational Level Agreement (CS/FSP/006) which defines
the responsibilities of the four levels of support towards each other. This
document is effectively a service level agreement between the support units,
outlining specific tasks and measures of success.
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.
More specifically the SSC has responsibilities to:
e First and second line support
e Fourth line support
3.1.1.1 Roles/Responsibilities
The responsibilities of the SSC to first and second line support, that is the
Horizon System Helpdesk (HSH) and the System Management Centre (SMC)
respectively, are to:
1. Receive incidents passed from the HSH and SMC
2. Ensure that any incidents received are maintained on the call management
system. When updates are made to the calls that are relevant to the HSH or
SMC, the SSC ensures that these updates reach the Powerhelp system
3. Ensure that the reported incident is resolved correctly and the solution is
recorded on the PinICL system
4. Ensure that the incident and solution are passed back to the HSH and SMC
call management system. The solution includes a full explanation for the
problem and the action taken to resolve it
5. Ensure that the incident is resolved within the total time allowed by the
contract between the customer and Pathway
6. Ensure that the HSH and SMC are made aware of the evidence
requirements for any form of incident and that this documentation is fully
maintained
7. Create and maintain a register of known deficiencies within the Pathway
system and the solution to these problems, where known
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 9 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd —_ Operations Manual for Customer Service Directorate —_ Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
8. Allow the HSH and SMC access to this register so that they can fulfil their
function of filtering out known errors
9. Ensure that any solutions or workarounds they pass to the SMC have been
tested and have been correctly authorised via the software release
management process
10. Ensure that the HSH and SMC are supplied with documentation relating to
new releases of software in sufficient time to enable their staff to become
familiar with the product prior to its release
11. Ensure that, for any incident which has been solved and passed back to the
Powerhelp system, the customer has been contacted and made aware of the
call closure
12. Hold workshops and skills transfer sessions relating to technical aspects of
the Pathway system and diagnostic techniques
13. Ensure that the following figures are available to the HSH and SMC on
demand:
(a) Number of calls by priority currently outstanding with the SSC
(b) Number of calls where resolution has been deferred to the next release
(c) Number of calls by age currently outstanding with the SSC or fourth
line support unit
3.1.1.2 SSC responsibilities to fourth line support
The responsibilities of the SSC to fourth line support are to:
1. Log all calls on a call management system
2. Filter out all calls for which the problem is already known to the support
community and for which a solution is already known or has been
generated. This includes problems for which the SSC knows a resolution
but has not yet incorporated the resolution into the known error log
3. Retain duplicate incidents in the PinICL systems and ensure that when the
resolved incident is received by the SSC the duplicated calls are closed.
Duplicate incidents are repetitions of an incident that has already been
passed to fourth line support.
4. Ensure that the correct evidence for any problem is collected prior to the
incident being passed to fourth line support for investigation.
5. Ensure that any incident that requires investigation by fourth line support
is assigned to the correct PinICL team depending upon the specific product
in which the incident has occurred
6. Ensure that any updates made to incidents passed to the SSC are sent to the
fourth line support units
7. Ensure that any calls passed to fourth line support units are passed in a
timely manner. The timing varies depending on the priority of a call
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 10 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd —_ Operations Manual for Customer Service Directorate —_ Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
8. Ensure that the priority of any incident is assessed and recorded correctly
9. Filter out all calls for which the problem is not one of the following:
(a) Software error
(b) Documentation error
10. Ensure that for any incident passed to fourth line support the exact area of
the problem has been identified and, wherever possible, a workaround has
already been produced
1
. Ensure that, for any code error, a probable solution is indicated prior to
passing the incident to fourth line support and, wherever possible, the
proposed solution has undergone limited testing
12. Accept full responsibility for the product, including fourth line support,
and for the production of any code required to resolve incidents, for areas
of the Pathway system where the product has matured, that is, no further
releases of the product are expected
13. Create and maintain a register of known deficiencies of the Pathway
system and the solution to these problems, where known, and allow access
to this register to fourth line units so that they can enter details of solutions
created within their area
3.1.2 Role of the SSC relating to Application Support
The SSC within Pathway Customer Service provides third line support for
most applications.
The SSC uses PinICL as its call management system and diagnostic database.
Calls from second line support are transferred from Powerhelp to PinICL via
an OTI link, and updates to the PinICL calls are transferred back to second
line support using the same mechanism.
When the SSC receives a call from second line support, second line support
has already assessed the call as a software problem and flagged it with the
appropriate priority. The SSC handles the call as follows:
1. The SSC checks details of known problems on the intranet site to
determine whether or not the problem is similar or identical to a problem
already known.
2. Ifthe problem is known, the SSC carries out any pre-authorised actions
that are available to it, for example, workarounds in the KEL
3. Ifthe problem is not known, the SSC checks the diagnostic evidence and,
if necessary, obtains further evidence from the live system to determine the
nature of the fault.
The SSC also uses its reference kit to recreate the symptoms reported by
the customer and may then be able to obtain diagnostic data in a controlled
fashion
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 11 of 92
FUJ00079875
FUJ00079875
ns Manual for Customer Service Directorate Ref: CS/QMS/007
Version: 1.0
ICL Pathway Ltd — Operati
Commercial in Confidence Date: 26/11/01
4. Ifthe problem is identified as a code fault, the SSC determines the area of
code that has failed and, if possible, identifies a solution to the problem for
fourth line support to implement. If possible, it tests the proposed solution
before passing the call to fourth line support
5. Ifthe problem is urgent, that is, a workaround has not been found, the SSC
escalates the problem to fourth line support via PinICL. Note that any
urgent corrective action is a one-off implementation of the solution to the
problem.
If the problem is not urgent, for example, a workaround has been
implemented, the customer is satisfied and the support call has been
cleared, the SSC still passes the problem to fourth line support via PinICL
to generate a permanent fix. However, the SSC Manager may lower the
priority of the PinICL to reflect the lack of urgency of the problem
6. Ifthe problem is not identified as a code fault, the SSC identifies the exact
nature of the fault and isolates the system that caused the symptoms. This
may happen, for example, when the code is operating within specification
but the customer reports symptoms which were not expected
7. Once the SSC has passed the call to fourth line support, it remains
responsible for ensuring that the call is dealt with in a timely manner and
for informing the SMC and HSH of any updates to the call
8. The SSC identifies the software that needs to be released permanently to
the live environment as the long-term solution to the problem and notifies
the CSRM accordingly
Note. Closing calls on PinICL and Powerhelp
e The SSC closes a call on PinICL when a resolution has been identified for
the call and the details passed to the SMC, for example, a definition of the
release that will contain the fix, as detailed in the release management
process
e The SMC and HSH use PowerHelp and close a call when the fix has been
distributed to the relevant equipment. This may be fairly simple if it is on
the central servers, but it may involve considerable work if it requires a
code release to all post office counters
3.1.3 Role of fourth line support
The fourth line support unit receives the request and does one of the
following:
e Returns with a recommendation for action that the SSC can carry out
e Returns with a workaround that the SSC can progress as if it had generated
it
e Rejects the request, for example, on the grounds that the problem will be
resolved in a system software release that is due imminently
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 12 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd —_ Operations Manual for Customer Service Directorate —_ Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
e Identifies a fix but does not produce it until authorised by the Release
Management Forum
Where necessary, internal Pathway fourth line support also provides the
interface with PinICL for external fourth line support units and updates the
PinICL with progress reports.
A number of units provide fourth line support to the Pathway system as
described in the following sections.
3.1.3.1 Pathway Development
These development teams use the PinICL system to manage calls. Their
process is essentially the same as the SSC with the exception that any
development required to resolve a problem goes through the release
management process.
The SSC and the development team discuss the problem and assign the
PinICL call to either a specific development team, if the product has been
identified, or to the general development team, if not.
If the development team requires additional information, it redirects the call
back to the SSC, which returns the call to the development team once they
have obtained the required additional information.
If a patch is produced to resolve the call, this is handled through the release
management process.
3.1.3.2 Escher
Escher also uses the PinICL system. The process for routing a call to Escher is
via the Pathway development team and therefore the process is as described
above.
3.1.3.3 ISD
Generally where ISD acts as fourth line support, it also has responsibility for
first, second and third line support - therefore, the procedures involved are
entirely ISD internal procedures. In those instances where SSC, not ISD,
provides third line support the procedures as defined in 4.2.4.1 will be
followed.
3.1.3.4 Eicon
Eicon’s Canadian call centre. 12 SSC staff are registered with Eicon as having
the authority to raise calls, and 2 SSC staff members have undergone training
with Eicon in diagnostic requirements.
Escalation to Eicon management for any issues is via the SSC manager and
the Eicon Service manager. As of 03/09/2001 this was Dan Dixon,
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 13 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd —_ Operations Manual for Customer Service Directorate —_ Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
The Finance Director holds the Eicon contract in FELO1
3.1.4 The Role of the SSC relating to Operational change
The SSC has access to the live system which can be used to correct data on the
system when this has been corrupted in some way. The procedure for doing
this is as follows:
The originator of the change:
1. Completes an Operational Correction Request (OCR) form for every
change to data on the live system.
The originator may be anyone within ICL Pathway, but is normally the
Duty Manager, or a Problem Manager or Business Support Manager when
an incident or problem has been caused by an error in the data. An SSC
staff member who detects that the data in the system has become corrupted
in the course of diagnosing a fault can also complete it. In the case of an
SSC staff member, the form is completed on the SSC web site direct, other
people currently complete a Microsoft Word version of the form and use
email.
2. Emails the OCR form to an authoriser, electronically signing it where
possible, and where this is not possible, telephoning the authoriser to
confirm that they are sending an OCR. For SSC staff members, the OCR
form on the web must always be digitally signed.
The authoriser must be one of the following:
e Duty Manager
e Business Support Manager
e CS Operations Manager
e SSC Manager
e Release Manager
The authoriser:
1. Authorises the change, or reports back to the originator why they are not
authorising the change
2. Forwards the OCR form to the SSC electronically with an encrypted
electronic signature file, or in the case of the SSC manager digitally sign
the web-held OCR.
The SSC staff member who is to perform the change:
3. Checks the electronic signature of the authoriser
4. Stores the OCR form and the signature file in the received OCRs folder
on the SSC server
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 14 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd ns Manual for Customer Service Directorate Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
5. Wherever possible, produces a script to make the data change and tests
the script on the SSC reference rig prior to running it on the live system
6. Completes the relevant sections on the OCR form to confirm whether
they have produced and tested a script or not
7. Prior to making the change on the live system, documents the state of the
affected part of the system and completes the regression path details on
the OCR form.
Note. If no regression path is possible, this must be stated on the OCR
form
8. Makes the change on the live system.
At least two people must be present when making changes to the live
system. Normally these are SSC staff, but can be one SSC staff member
and one person from the fourth line support unit responsible for the area in
which the data change will take place, or one SSC staff member and one
ISD staff member
9. On completing the data change, documents the state of the affected part of
the system and mails an electronically signed copy of the OCR form to the
second person who was present while making the change.
10. The second person also electronically signs the form and emails it to either
the SSC Manager or the SSC web site controller. In the case of an SSC
raised and authorised OCR, both staff members digitally sign the web-held
OCR form.
. Updates the PinICL and reports back to the originator to confirm that the
change has been completed
The SSC Manager or SSC web site controller:
12. Checks the electronic signatures
13. Files the OCR in the completed OCR folder on the SSC server
3.1.5 SSC reference kit
3.1.5.1 Overview
The SSC reference kit consists of a rig at BRAO].
ISD maintains the rig. The rig is formally “owned” by the Pathway Testing teams, but
with an agreement for the SSC to take priority on it at no notice in order to reproduce
an urgent fault.
The general requirement is for the SSC to have reference kit that mirrors as closely as
possible the equipment in use at any post office. The function of this kit is to duplicate
problems reported by customers in a controlled fashion. The SSC also uses the
reference kit to provide a link to live system diagnosis and, where authorised, data
change.
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 1S of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd —_ Operations Manual for Customer Service Directorate —_ Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
3.1.6 Diagnostic information
The SSC, as third line support for products in the Pathway system, has responsibility
for ensuring that first and second line support units are provided with sufficient
information to enable them to diagnose known problems correctly and to provide
advice and guidance to the customers.
In this way, support requests from customers that are passed to the SSC should be
restricted to either complex end-to-end process problems that require in-depth
analysis of all of the systems involved or new software faults.
3.1.6.1. Maintaining the Known Error Log on the SSC intranet site
The SSC generates and maintains a Known Error Log (KEL) system that uses
searchable documents in HTML format. The mechanism for searching is a query
entry in an intranet site. The KEL system is available to first, second, third and fourth
line support units as well as SSC staff.
3.1.6.2 Transferring knowledge between support units
The SSC intranet site has KEL search facilities and other useful diagnostic data,
documents and tools.
SSC and SMC staff raise KELs based on customer-observed symptoms.
KELs are further maintained once the fault has been resolved.
Other diagnostic information, including support Guides for the various products are
also held on the SSC intranet site, as are contact numbers for SSC and ISD staff.
These documents are NOT controlled however, and in case of any doubt, reference
needs to be made to the master copies of the documents which are held in PVCS.
3.1.7 Diagnostic tools
3.1.7.1 Overview
The SSC develops and maintains tools that can assist in the diagnostic process. The
SSC diagnosticians develop the tools themselves; the individual authors are
responsible for maintaining these developments.
Development is performed on an ad hoc basis whenever there is a requirement to
generate a tool to assist in the diagnosis of faults.
All diagnostic tools are registered on the SSC intranet site.
The tools themselves are made available to all members of the SSC and, where they
are able to assist other support units within Pathway, they are made accessible
together with any documentation about their use.
3.1.7.2. Developing diagnostic tools
Before developing a diagnostic tool, establish whether or not the required tool has
already been produced by reference to the diagnostic tools database on the SSC
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 16 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd —_ Operations Manual for Customer Service Directorate —_ Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
intranet site. This database contains details of known diagnostic tools developed in the
SSC and by other support units.
1. Ifa suitable tool already exists, it should be used
2. Ifa suitable tool does not already exist, the SSC staff member:
(a) Defines the requirement for the tool to the SSC Manager
(b) Waits for authorisation before proceeding
3. Ifthe diagnostician has sufficient development skills to develop the tool him or
herself, the SSC Manager schedules the development work required
4. Ifthe diagnostician does not have sufficient development skills to develop the
tool, the SSC Manager:
(a) If these skills are available within the SSC, identifies the resource required
to develop the tool
(b) If necessary, goes outside the SSC to obtain the development resource
5. Log the fact that the tool is being developed in the diagnostic tools database on the
SSC intranet site and forward this information to all of the relevant units which
may have use of this tool
6. Maintain a copy of the tool in the diagnostic database on the SSC intranet site
3.1.8 SSC intranet site
This site was created by and is maintained by SSC staff, although it provides a
resource for other support staff within the Pathway estate.
The following sections describe the key features of the site. As the contents of the site
are under constant review, the following details may change.
3.1.8.1 Known Error Logs (KELs)
The intranet site holds known error details in HTML format, the contents of which
may be searched for, in full text form. Documents are created to a defined template
wherever possible. An application has been generated which limits the properties of
the document to a subset of possible values, for clarity and ease of search. This
application is made available to all support units.
The process for creating KEL entries outside of the SSC has not yet been formulated,
but it is expected that no KEL will be allowed onto the system before it has been
authorised by SSC staff.
3.1.8.2 Change proposals
The intranet site holds copies of each Change Proposal (CP) in a searchable form as
HTML documents. These documents are not definitive. As copies of the CPs are
taken before they reach the Pathway Change Control Board the status of any CP is
indeterminate - it may, or may not, have been approved.
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 17 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd —_ Operations Manual for Customer Service Directorate —_ Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
Maintaining the CPs in this form allows diagnosticians to see that someone has
looked at an activity in an area of the Pathway operations regardless of whether or not
that activity was actually carried out.
3.1.8.3 Release management
The Release Management database is held on the same server as the Intranet site. This
database is used to control the flow of fixes through the Operational Testing processes
and through release to the live environment.
The intranet site provides a controlled interface to this database, allowing searches to
be made by:
e Date
For example, show all fixes applied to the live environment since date «xxx
e PinICL
For example, show the state of a PinICL in the release process (delivered, due to
be tested, due to be released to live)
Similar searches can be made on a Release note as described for a PinICL.
3.1.8.4 Operational Change/Corrections
The intranet site holds copies of both SSC Operational Correction Requests and ISD
Operation Change Requests. The intention being to provide a mechanism in which
both urgent and planned changes at the operational level can be viewed quickly.
ISD have control over the ISD change requests, and the SSC intranet site provides a
repository and search mechanism only. For SSC Correction requests, inserting the
data into the intranet server is mandated by the process — Appendix B of this
document.
3.1.8.5 Work Instructions
There is a requirement for Work Instructions which may augment, or temporarily
replace documented procedures. These are logged and maintained on the SSC Intranet
site. There is a password protection mechanism, so that only the SSC manager, or
nominated deputy, can create new, or amend existing Work Instructions. All staff are
allowed to search the work instructions
3.1.8.6 Other facilities
The intranet site also contains smaller sections that provide:
1. Links to commonly used web sites
2. A bulletin board for SSC staff to add points of interest regarding the operation of
the live system
3. Access to commonly used SQL queries and other items of code
4. Access to various documents relating to the live system
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 18 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd —_ Operations Manual for Customer Service Directorate —_ Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
3.1.9 Access to the live system
All diagnostic staff in the SSC (product specialists and systems specialists) have
access to the live system via PCs (see Appendix D for build details) that are
connected to a private LAN in BRAOI. Patch panels enable staff to use these PCs to
access the test rigs in BRAOI.
The build script for these PCs was written by and is held by the SSC. The PC build
was performed in accordance with the Access Control Policy, and a copy is registered
in PVCS.
Access from the PCs to the live system to the live system is controlled by SecurelID,
uses firewalls, and an encrypted link, and conforms to the Access Control Policy.
The SSC access to the system is for two purposes:
e Assist in diagnosis of problems on the live system
© Correct data which has become corrupted
In the second case, SSC staff may only correct data in response to an authorised
Operational Correction Request and only then when there are two or more people
present.
3.1.10 Additional technical support to Pathway CS
In addition to the normal support activities, the SSC provides other technical
resources to Pathway CS. It is the only unit with sufficient access to the live systems
to be able, for example, to analyse:
e Riposte message store
e Counter event logs
¢ Central system NT event logs
Consequently, the SSC runs daily checks for:
¢ Post offices that have not communicated with the central systems for 24 hours
e Any NT events that indicate that TIP processing has failed or that transactions
have not been harvested
It is also able to respond to other specific requests such as:
e Number of reboots performed by each counter in the estate
e Analysing the message store to investigate a suspected breach of security at a
counter or one of the central systems
CS units requiring such information contact the SSC Manager or the appropriate
diagnostician who deals with the request as promptly as possible.
The SSC also acts as a development unit for tools which may be required by ICL
Pathway CS, and other (e.g. HSH/SMC) support units.
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 19 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd —_ Operations Manual for Customer Service Directorate —_ Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
Such developments can be requested by any member of ICL Pathway Customer
Service, or by unit managers from other support units. The developments must be
registered with the SSC manager, who will authorise the development, allocate the
relevant staff, and maintain a record of the development being produced and the
expected delivery times.
These developments are intended to improve the productivity of the staff requesting
them, and do not form any part of the ICL Pathway live estate, and are therefore do
not conform to the documentation or testing standards required for the ICL Pathway
system.
3.2 Client Interface Management
3.2.1. Summary
This unit is responsible for the introduction and ongoing management of services
relating to the client interfaces - HAPS, APS clients, LFS and TIP, ensuring the
service is delivered within the agreed parameters and operational timetables.
Its responsibilities are:
e Service development including the preparation and review of processes,
procedures and documentation, client liaison (including Client Take On),
developing support arrangements and participation in test programmes.
e Service introduction including the development and delivery of a service
introduction plan containing details of delivery milestones, SLA and OLA
targets and support requirements.
e Ongoing Service Management support for implemented services covering
operational reviews and service improvement planning, MIS analysis and
problem management.
3.2.2 The Interface Services
There are a number of interfaces in place that facilitate the delivery of transaction
files between the ICL Pathway and POL infrastructure. These are different to the
ISDN connections to POL Outlets. The service is responsible for ensuring that
transactions, harvested from the POL Outlets, are delivered to POL, through the
appropriate interface, in accordance with the Service Schedule Agreements. Each
interface and its corresponding SLA is managed as an individual service, but in
some areas may involve other interfaces.
The service provided is based on the contents of the Service Definition
Agreements (Schedule n01), Service Levels and Remedies Agreements (Schedule
n08) and the Service Management Agreement (Schedule 05). These are contract
controlled documents and separate schedules are in place for each interface (n =
character depicting specific interfaces).
There are four interface services:
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 20 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd Operations Manual for Customer Service Directorate Ref: CS/QMS/007
Version: = 1.0
Commercial in Confidence Date: 26/11/01
HAPS, APS clients (of which there are several), TIP and LFS.
3.2.3. Service Introduction
As an aid to the Service Manager in delivering a full operational service around
the interface in question, a service introduction plan (where appropriate) is
prepared, which documents related information, requirements and actions. For
example, this includes plans to date and milestone timescales, work still to be
done, relating documentation, SLAs and OLAs, support requirements, contacts
and links between interested parties.
The following activities take place for each interface in preparation for Live
service. Some of the activities may over-spill into Live operation of the service.
e Liaison with the Development and Design teams to understand the Application
Interface and Technical Interface Specifications created.
e Liaison with the Requirements team to review all agreements made and any
service descriptions in place, if produced.
e Liaison with the client to commence the production of the OLA based on the
SLA and specification details. Eventually to become a formal Operational
Review meeting once the service is Live.
e Participation in Workshops to prepare or review procedures (if and when
applicable).
e Liaison with internal support services to ensure that they are aware of the SLA
and OLA commitments.
e Set up of ICL Pathway/POL Service Review with agreed Agenda.
e Liaison with Business Continuity Manager to ensure Business Continuity and
Disaster Recovery procedures are documented.
e Involvement in any operational test programmes, where requested.
e Produce or review any related documents within ICL Pathway.
e Review of any related documents produced by third party suppliers.
e Review of any related documented produced by the customer, if requested.
e Participation in the production and review of Incident Matrix.
e Creation of risk registers.
e Creation of project plans, if required.
e Creation of new call categories within CEM, if required.
e Processing of Change Requests submitted through the Change Management
process, if required.
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 21 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd —_ Operations Manual for Customer Service Directorate —_ Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
e Set up and agreement of Client Take On (CTO) procedures, OLA and
schedules (outside of normal service management activities and relating in
APS only).
e General, ad-hoc communication with the customer, other internal teams and
third party suppliers through phone calls and Email.
¢ Completion of actions arising from meetings held.
e Implementation of Disaster Recovery solutions, where appropriate (and in
accordance with Change Management Procedures)
3.2.4 Service Management
The following activities either take place as standard processes or are managed on
an ad-hoc basis in order to maintain or improve services.
e Chair or attend Service Reviews (if appropriate and at agreed intervals -
usually monthly).
e Escalation point for service related Incidents and Problems. To be managed as
per the standard procedures in place.
e Escalation point for service related customer complaints. To be managed as
per the standard procedures in place (Incident or Problem Management
procedures). Generally a reactive service.
e Review of OLA as part of Operational Review, as and when appropriate.
e Processing of Change Requests submitted through the Change Management
process, if required.
e Review of daily transaction delivery reports produced by third party suppliers.
e Review of monthly SLA Management statistical reports produced internally
(by MSU).
e Manage or review any relating plans, where appropriate.
e Ongoing review of procedures in place (any changes to go through Change
Management process). Usually highlighted through Workshops or Operational
Review meetings.
e Implementation of Disaster Recovery solutions, where appropriate and in
accordance with Change Management procedures.
e Participate in scheduled Contingency Tests, where appropriate.
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 22 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd —_ Operations Manual for Customer Service Directorate —_ Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
3.3. Operations Services
The Operations Services Unit is responsible for all aspects of live service operation.
The unit is divided into a number of units as shown in the following diagram.
3.3.1 Availability management
The following sections describe the different areas of availability management.
3.3.1.1 Duty management
This section describes operations relevant to the Duty Manager (DM).
The Duty Manager (DM) role is undertaken by Service Managers in CS
Operations Services on a rota. A Duty Manager handbook contains phone
numbers of Service Managers and other contacts, and copies of relevant
procedures.
The DM receives escalated calls from:
e The Horizon System Helpdesk (HSH)
e¢ The System Management Centre (SMC)
e The Management Support Unit (MSU) or the System Support Centre
(SSC)
e POL Service Management
The DM decides whether or not the incident needs to be managed through ICL
Pathway Problem Management procedures.
The document DSP/PRO/HH/010 Horizon System Helpdesk Incident
Procedures explains the types of calls that are escalated to the DM.
3.3.1.2 Types of call
The prioritisation of calls is described in Horizon System Helpdesk Incident
Prioritisation CS/FSP/00S.
The DM receives calls from the HSH for the following circumstances:
¢ Specific A priority incidents (the different priority categories are described
in CS/FSP/005)
e After the action times in the SLAs for both A and B priorities have elapsed
When necessary, the DM also receives calls out of HSH working hours from
the SMC/SSC or the ISD Duty Manager.
3.3.1.3. Duration of cover
The daily DM rota, (Weekdays only, Operational Hrs 0800-1800), is operated
by the Availability team.
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 23 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd —_ Operations Manual for Customer Service Directorate —_ Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
At other times the OOH DM is resourced from a pool of ICL Pathway Service
Managers. Operational times are 1800-0800 weekly and 24 hour cover at the
weekends Sat/Sun.
There is a Daily update at 0800 from the OOH DM to the Daily DM to hand
over any outstanding calls or issues.
There is a daily update at 1800 from the Daily DM to the OOH DM to hand
over any outstanding calls or issues.
The handovers at the end of each shift on any outstanding problems or issues,
are by phone or in person to the relieving DM, although a DM may see a
particular problem through to completion, even after their duty period has
ended.
3.3.1.4 Duty management procedure
The overall duty management procedure is as follows:
1. The DM receives a high priority call that may indicate a possible problem
2. The DM finds out the details of the incident, problem or multiple incidents,
and may make initial phone calls to the support units to help decide
whether a problem exists (see 4.1.5 below).
If the incident is not a problem, the DM informs the caller to deal with it
through the normal A priority channels, ending the procedure.
If the incident is a problem, the DM initiates the Problem Management
Process as in the following steps
3. If the Problem Management Process is initiated, the DM (or maybe the PM
Problem Manager, currently under review in PM forum) enters the details
of the problem as a progress commentary in a new PinICL call in the
PinICL Problem Management Database. The PinICL call is assigned to the
Problem Management stack. However, if the problem needs to be dealt
with immediately, the DM enters the details on to the database following
completion of the immediate action. (If the incident occurred out of hours,
then the problem is recorded at the earliest opportunity)
4. The DM appoints the Problem Manager (PM) most capable of handling the
problem. In some cases, due to the levels of personnel available, the DM
may be the PM, particularly if the incident has occurred outside normal
working hours.
If the appropriate PM is unavailable or unable to manage the problem, the
DM escalates the problem to the appropriate Customer Service Manager
who will help to decide who the PM should be
5. Following nomination, the DM enters the PM on to the Problem Database
as the new owner (assignee) of the problem (this may already be done, see
note in 3, currently under review). The PinICL record is updated, closed
and possibly reviewed but remains on the Problem Management stack.
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 24 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd —_ Operations Manual for Customer Service Directorate —_ Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
3.3.1.5 Deciding whether a problem exists
To help decide whether an incident is a problem, the DM considers the
following areas:
Areas of I Problem criteria
consideration
Business e Adverse publicity on ICL Pathway.
impact e Possible affects upon Release dates.
Time scales ¢ The predicted time to resolve an incident is unacceptable.
Customer e Widespread customer dissatisfaction.
dissatisfaction
Breadth of I ¢ The incident affects more than 10 outlets.
problem © Does the problem classify as an MBCI
Cost e The financial cost to ICL Pathway to resolve the incident is
excessive and possibly impacts the ICL Pathway budget.
Complexity e A variety of resources that need managing are needed to
resolve the incident.
e Resources external to ICL Pathway are required, such as
input from POL.
Security © The incident has possible security implications.
Impact on e The incident impacts other organisations such as POL, and
other they need to be informed.
organisations
If the DM is in doubt as to whether an incident is a problem, the incident is
resolved as a problem.
3.3.2. OCP changes
An operational change process (OCP) is also in operation. This process covers
changes required to the live operation and provides an audit trail for all changes
made to the operational estate (Not counter changes). This process is owned and
administered by ISD Service Management on a daily basis. The Daily Duty
Manager is responsible for the daily sign off as the CS representative but may well
seek the advise and sign off from the responsible Service Manager. All other
parties in CS Operations and ISD Operations are also signatories to the process.
3.3.3 Business continuity
A key requirement in the ICL Pathway solution is that of business continuity,
which is effected by producing operational processes and procedures to ensure
that any component failure has minimal effect on the service provided. Refer to
CS/PRD/031 (ICL Pathway CS Business Continuity Management) which defines
how Business Continuity is managed.
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 25 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd —_ Operations Manual for Customer Service Directorate —_ Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
POL and ICL Pathway recognise the term Business Continuity as having three
closely related components:
¢ Resilience
Steps taken to avert a loss of service or disaster or reduce the likelihood of a
disaster or loss of service
¢ Contingency
Interim processes and procedures adopted during the loss of service
e Recovery
Business and technical arrangements to restore a lost system or service and
manage the process of reversion to normal processing and full resumption of
service
The principal requirement with respect to the provision of contingency plans is
that they should conform to an overall service continuity framework. The
document Business Continuity Framework (CS/SIP/002) and associated
contingency plan documents for each component service of the ICL Pathway
solution have been produced and are regularly reviewed to ensure they meet the
changing requirements of the service continuity framework.
The Business Continuity Framework document does the following:
e Provides a definition of the Business Continuity Framework and contingency
plans as specified in Requirement 830
e Provides a detailed definition of ICL Pathway deliverables associated with
business continuity and the methods of review and assurance
e Defines the contents and format of the contingency plans
e Defines the overall test strategy adopted for testing of the contingency plans
e Defines the management processes for the management of Major Business
Continuity Incidents
There are contingency plans for all the service elements of the ICL Pathway
solution. Most plans cover service elements but a few cover individual ICL
Pathway sites, which provide more than one service to the Horizon service.
Each contingency plan provides a summarised description of the service or
services within its scope. It also describes the measures already taken to minimise
the risk of not being able to provide those services.
The contingency plan then sets out what actions the relevant service managers
need to take to instigate any recovery or contingency procedures specific to the
provision of the service or services.
Each business contingency plan defines the initial and on-going test strategies. For
each test, a test script has been produced which clearly explains the objectives of
the test exercise and all details necessary to ensure that those objectives are
achieved.
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 26 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd —_ Operations Manual for Customer Service Directorate —_ Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
3.3.4
3.3.4.1
3.3.4.2
3.3.4.3
3.3.44
The document Business Continuity Test Plan (CS/PLA/011) brings together the
testing requirements of all the contingency plans that have been generated and
documents the schedule and methodology to be adopted for business continuity
testing, both before National Rollout and on an ongoing basis.
Supplier management
Overview
The Service Managers within the availability team perform supplier
management. The suppliers involved are ISD (Network management,
Operations and support), Sequent/I]BM (mainframe systems) and Energis
(Network provision). Suppliers and service performance is monitored and
reviewed on a daily, weekly and monthly basis.
Daily
Regular telephone contact between the Service Managers and suppliers is
undertaken. This contact is used to manage issues and incidents that arise on a
sometimes, daily basis. The service managers utilise management information
from incidents and trends to support this regular contact.
Weekly
The service (and supplier) performance is reviewed at a weekly meeting
(names “prayers”). This weekly review looks at the issues and problems
arising from the operation of services throughout the week identifying issues
and placing actions on suppliers to address those issues.
Monthly
Supplier performance is reviewed formally on a monthly basis, each supplier
provides a monthly management report containing the supplier view of service
availability, service exceptions, trends analysis and performance statistics.
Additionally, ICL Pathway produce monthly MIS statistics giving a view from
an incident and problem perspective.
A monthly meeting, chaired by the Operations Services Manager, is held with
all suppliers present to review overall and individual supplier performance.
3.4 Operational Support Services
Operational Services provide key administrative support to Pathway in order to
service the requirements of its client more effectively.
Key areas of functionality are in: -
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 27 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd —_ Operations Manual for Customer Service Directorate —_ Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
3.4.1 Problem Management
It is the responsibility of the Operational Services team to maintain the Problem
Management Database. Problem Managers within CS raise calls on PinICL. These
calls are transferred onto the Problem Management database. The database is
updated daily and is accessible by POL via the RAS intranet and to Pathway via
the CS intranet. A copy of the report can be found on V:/Olpublic/A CS problem
management report.
Operational Services liase with POL to maintain continuity of cross-domain
problems. (POL sends Pathway a cross-domain report, each week, which is cross-
checked with Pathway’s own problem management database).
3.4.2 Change Proposal
Change Proposals (CP) are a means of cascading and obtaining approval of
changes to the Pathway Programme. A meeting is held every week with
representatives of all sections of Pathway to discuss CP's (PCCB). Change
Management (CM) owns this process. CS has their own process to ensuring one
voice of agreement from CS is passed onto the programme.
Operational Services are responsible for collating all CS impacts on a database
and informing CM and therefore Pathway of their outcome. Change proposals are
held within a library on PVCS, the tool for recording an audit trail of documents
and change proposals for the Pathway programme.
Specific functions include: -
e Use the CP Access Database to record all CS impacts.
© Chasing actions that arise from meeting of the Pathway Change
Control Board.
e Update CP status changes.
« Manage Customer change Notes, Customer Change Requests
e Relay costing of impacts to the Finance department.
e Manage the life cycle of the CP process on behalf of Pathway
Customer and suppliers/contractors like ISD.
3.4.3. Non Polling
Operational Services play an important part in managing all Non Polling incidents
of outlets in the Pathway programme. Non Polling impacts services in the outlets
and can attract a penalty if left unattended.
A report is produced from the TIVOLI web of all outlets that have not polled
overnight. Operational Services updates this report with additional outlet
information and cascades this to POL, SMC, Pathway and Energis. This triggers
off the investigative process (amongst the above-mentioned teams) for non-
polling until every incident is resolved. Operational Services analyses and
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 28 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd Operations Manual for Customer Service Directorate Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
investigates non-polling incidents on a daily basis and prepares updated reports,
which are distributed, to POL, SMC and Energis. Relevant reports produced are -
1. Initial Non Polling report 2. Non Polling analysis and 3.Non polling updates.
3.4.4 Duty Management
As part of Pathway’s contractual commitment to the customer, CS has an
obligation to service customer requirements 24 hours/365 days. Operational
Services organise and distribute rotas of Service Managers on duty. Time sheets
of duty managers are checked and validated and passed to Payroll.
3.4.5 Operational Change Requests
For any operational system changes authorised electronic signatures have to be
received from Security, SSC, Duty Managers, Development etc. Operational
Services manage the approval aspect of this process by cascading the authorised
electronic signatures between all the relevant parties and returning the completed
electronic authorisation to ISD for action.
3.4.6 Security
All Pathway staff visiting a Post Office outlet are required to have a valid security
pass issued by POL. Operational Services process the documentation for security
clearance and manage the process of requesting and issuing of temporary and 3
year passes between ICL security and POL security.
3.4.7. General Activities
Activity Driver Frequency
Adhoe printing from PVCS and I MI As required
PinICL for CS Staff
General PinICL and PVCS) MI As required
training
Maintaining Pathway Telephone I MI As required
Directory
3.5 Reference Data Management
The overall objective of this team is to manage, in conjunction with other units in ICL
Pathway, all aspects of POL supplied Reference Data and associated ICL Pathway
Reference Data delivery to the live environment
The Reference Data Team (RDT) is responsible for the management of Reference
Data to support Operational Business Change (OBC) .
The RDT is responsible for the control of product reference data, as follows:
e POL product changes, such as the price of stamps
e ICL Pathway generated changed to support POL changes
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 29 of 92
ICL Pathway Ltd —_ Operations Manual for Customer Service Directorate —_ Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
¢ Other ICL Pathway generated changes, such as the menu hierarchy
e AP Client and services changes.
The end-to-end process is described in Process for Operational Business Change -
Product (CS/PRD/030)
The RDT is also responsible for control of outlet reference data changes in support of
the service delivered by the OBC team. The RDT team is also responsible for
providing a source of information to other parts of the ICL Pathway and Post Office
organisation with respect to Reference Data. This sometimes necessitates members of
RDT providing varying levels of support, dependant on the nature of the problem
being investigated.
3.5.1 Change types
The reference data changes that are covered by this process fall into two types:
basic and advanced.
Change Description
type
Basic Basic changes are those that ICL Pathway can implement without
prior notice. They consist of changes to reference data that can be
implemented with no more than the basic control and release
activity by ICL Pathway. The data that forms the content of these
changes is referred to as ‘Class 1’ data.
Advanced I Advanced changes are those which need additional activity by ICL
Pathway before the change can be implemented for example,
updating the Menu Hierarchy with a new button. Different
advanced changes require different activities by ICL Pathway.
The activities may be:
¢ Load Type B data (see below for definition of Type B data)
e Create Type C data (see below for definition of Type C data)
e Manage additional information (see below for definition of
additional information)
© Validate the change
¢ Maintain documentation
¢ Formal authorisation
© 2001 ICL Pathway Ltd
Commercial in Confidence Page: 30 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd — Operati
FUJ00079875
FUJ00079875
ns Manual for Customer Service Directorate Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
3.5.2 Types of data
Data type
Description
Type A data
Data that is sent electronically from the POL RDS system to the
ICL Pathway RDMC system, over an agreed interface, as
defined in the AIS document (application interface specification)
see Application Interface Specification Reference Data to ICL
Pathway (BP/IFS/007)
Type B data
Data that is sent from POL to ICL Pathway, but not over the
interface from the RDS to the RDMC. For various reasons, this
data has not been included in the Type A AIS, although it may
becomes Type A data in the future for example, scales tariffs.
Type B data is received either via the gateway between POL and
ICL Pathway or as an electronic file by email or on floppy disc,
will be passed as an electronic file for example, over email or via
a floppy disc
Type C data
Data that ICL Pathway must create to support requested
changes to the Horizon system for example, changing Menu
Hierarchy, cash account and other report layouts. POL must
explain what result is expected for ICL Pathway to implement
the change, for example, for a new core product, where the new
button should go in the menu hierarchy
Additional
information
Several changes require additional information or ‘objects’.
Additional information may be needed as follows:
© To allow ICL Pathway to create Type C data, for example
the position of a new button
e Because objects such as tokens are needed for ICL
Pathway to complete the testing phase
3.5.3 Activities
The following activities are involved in implementing Reference Data changes:
1. Receiving Type A data - Basic change data
raw PF YN
Receiving Business Change Request
Receiving Type A — Advanced change
Receiving Type B data
Receiving additional data
Monitoring progress
Requesting and loading Type B and C data
© 2001 ICL Pathway Ltd
Commercial in Confidence Page: 31 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd —_ Operations Manual for Customer Service Directorate —_ Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
8. Validating and Verifying Reference Data changes
9. Receiving authorisation
10. Releasing change
The activities performed depend on the type of change and are defined in the
RDCC (CSAFS/001).
3.5.4 Product change activities
RDT carry out the following activities to implement product changes:
3.5.4.1 Receiving Type A (and B) data-Basic change Basic changes require only simple
reference data changes and can typically be implemented quickly and easily. The document
Receiving Type A Reference Data (CS/PRO/074) describes the procedure for the RDT to
receive and process Type A Reference data.
Again Assessing the impact of a change request (CS/PRO/077) describes the
procedure for the RDT to assess the impact of a Business Change Request and
to create a plan for implementing the change
e Receiving Type A data-Advanced change. Advanced changes require ICL
Pathway Customer Service to undertake additional activities, such as creating
Type C data, and take longer to implement. For Advanced changes, POL
submit a Business Change Request to Customer Service.
e Receiving Type B data. As described in Receiving Type A data.
e Receiving Additional Information
Some changes require additional information or objects from POL, such as
position of new buttons.
3.5.4.2 Monitoringprogress
The RDT monitor progress on BCRs using a number of tools including the RDMC
workstation
3.5.4.3 Requesting and loading Type B and C data. The document Requesting, managing
and loading Type B and C Reference Data (CS/PRO/078) describes the procedure for the
RDT to create a request for Counter Development to create Type B and C Reference Data,
and to load the data when received from Counter Development on to the RDMC database
3.5.4.4 Validating and Verifying Reference Data changes
For product changes the data is validated internally. POL BSM receive
verification Reports and in most cases they are able to view the change on
dummy counters in Farnborough. POL BSM verify the data and authorise it for
release to Live.
For outlet changes verification reports are produced and sent to the Network
Change Authoriser (NCA) of the territory the change is concerned with. The
NCA authorises the release of the data by returning an OBC24 form.
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 32 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd —_ Operations Manual for Customer Service Directorate —_ Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
3.5.4.5 The service description for the APS Token Verification Service is described in
APS Token Verification Service Description for Release 2 (CS/FSP/016).
The RDT validate APS Client data changes provided by POL by carrying out
the activities described in the document AP Token Verification procedure
(CS/PRO/079)
In the event that validation of verification fails, additional data is supplied by
POL or ICL Pathway, as necessary, and the process is repeated Authorisation
POL BSM Authorise changes to reference data associated with BCRs.
3.5.4.6 Releasingchange
Once Reference Data has been authorised by POL BSM, it is released to live by the RDT.
This procedure is described in Releasing Reference Data to the Live Environment
(CS/PRO/081)
3.6 Message Broadcast Service
A document (CS/OLS/022, Communications Interface Agreement, v.1.0) has been
written to describe the processes involving the Post Office and ICL Pathway in the
authoring, validation and broadcasting of items for broadcast using the Message
Broadcast Service. The document covers processes and responsibilities for the
authorship and validation of messages, and summarises the end to end procedures for
originating the information and for getting it to the required destination. It also
ensures that all personnel involved in the process (including HSH) get sufficient
visibility of all messages.
Detailed processes related to the use of the Message Broadcast Service itself are
contained in a PON authored document: Message Broadcast Service Management
Framework (PON/BSM/PRO/001).
3.6.1 Validating PON originated Articles
The same document (CS/OLA/022) also describes the processes involving PON and
ICL Pathway in the authoring and validation of articles written for publication
(usually in Counter News, but not exclusively), and authorised temporary procedures
(ATPs). It covers processes and responsibilities for the authorship and validation of
articles. Its aim is to ensure that both organisations are aware of their individual
responsibilities, in the authorship and validation of Horizon related information being
distributed to post office outlets. It also ensures that all personnel involved in the
process get sufficient visibility of all relevant articles. The validation cycle within ICL
Pathway includes HSH and the technical authors.
The end to end procedures for originating the information and for getting the article to
the required destination are covered in a PON authored document Working Level
Procedures for the Implementation of Authorised Temporary Procedures
(CHE/APR/008).
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 33 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd —_ Operations Manual for Customer Service Directorate —_ Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
3.7 Outlet Business Change
3.7.1 Overview
Outlet Business Change (OBC) refers to the service managed by the CS Strategic
services Unit OBC team, to deliver agreed physical and configuration changes to
the Horizon counter system at post offices where requested by a change order
from Post Office Limited.
Agreed changes are those changes defined as Post Office Limited requirements
within the Operational Business Change catalogue (document ref CS/REQ/006)
and such changes are planned with a lead-time in advance of delivery.
3.7.2 Types of Outlet Business Change
By managing planned OBC change, the CS Strategic Services Unit supports the
delivery of the following Post Office Limited required change types:-.
e PLANNED office refurbishment (same counter configuration)
e PLANNED office opening (new counter configuration)
e PLANNED office closure (either temporary or permanent)
e PLANNED office relocation (either same or new counter configuration)
e PLANNED office counter increase or decrease
e PLANNED office counter change (trolley or mobile)
e PLANNED office counter peripheral change (display type or weigh scales)
e PLANNED office change communications type (VSAT to ISDN or vice
versa)
e EMERGENCY office closure (unplanned temporary closure)
e PLANNED office re-opening (following an emergency closure)
e BASIC and ADVANCED reference data changes to office details
3.7.3. Process for Outlet Business Change
The OBC process stages determine the implementation of each type of change.
© CS OBC team receives and processes the change orders from Post Office
Limited
¢ CS OBC team check orders for conformance to the service predefined time-
scales
e CS OBC team liase with Post Office Limited, Network Transformation
e CS OBC team schedules service components with CS service suppliers
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 34 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd —_ Operations Manual for Customer Service Directorate —_ Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
© CS service suppliers deliver service components to the post office.
¢ CS OBC team manage the end to end service process, which links all of the
component services together, and ensures the success of the change
e A completion record for all changes is sent to the customer
3.7.4 Key OBC Service Suppliers
The OBC process stage is resourced and delivered by approved service suppliers.
e Energis provide post office communications infrastructure either through BT
for an ISDN service solution or through HOT for a VSAT service solution.
e ISD provide site survey and preparation services through RoMec, and Horizon
equipment services through UKSS engineering.
e ISD also provides Horizon system configuration services through MSS and
SMC.
e Pathway CS SSC provides software support for OBC.
3.7.5 OBC Service Management
The CS OBC Service Manager has a team of Service Controllers each owning the
changes for a geographical territory. The Horizon estate is split into three
territories, North, West and East, and maps onto the organisational structure of the
Post Office Limited Network Transformation Team territory. The Service
Controllers each have responsibility for up to 60 post offices changes per month,
and control these changes by liasing with the customer and suppliers on a daily
basis. The following document set governs the delivery of the OBC service: -
e CS/REQ/006 — OBC Change Catalogue
e CS/PDN/015 — Outlet Change Service Descriptions
e CS/PDN/017 — Outlet Change Schedule of Service Prices
e CS/IFS/003 — ICL Pathway / Post Office Limited, Interface Agreement for
OBC - Outlet
e CS/PDN/029 — The Management Process for OBC - Outlet
3.7.6 OBC Service Monitoring
There is a continuous stream of change activity, which is active work in progress.
The delivery of change is subject to daily monitoring and ongoing telephone and
electronic mail discussion with suppliers and customers.
An OBC database is used to monitor and control operational changes and a new
tool, OCMS will enhance OBC scheduling and monitoring from January 2002.
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 35 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd —_ Operations Manual for Customer Service Directorate —_ Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
3.7.7 OBC Service Completion
When Post Office Limited wish to alter the details a change that has been
previously ordered on an OBC20 form, they request an amendment by issuing an
OBC21 request to the OBC team. Records are kept in the OBC database of all
OBC services that have been delivered, and these are used to calculate the
payment for services on a monthly basis. An invoice is then generated and sent to
Post Office Limited for payment.
ICL Pathway has declared a limit for the maximum number of OBC changes that
can be delivered over a period. This is expressed as a percentage of the live estate
averaged over one year, and is documented in The Management Process for OBC.
Post Office Limited can request that this limit is increased by raising a Change
request to ICL Pathway.
3.7.8 OBC Service Review
Regular monthly reviews are held between the customer (Post Office Limited
Network Transformation Meeting), and the CS OBC Service Manager, to discuss
any OBC service issues and to look for ways to improve or enhance the service
delivery process. The CS OBC Service Manager also holds regular reviews with
the Service Managers from the suppler organisations, with this same objective.
3.7.9 Horizon Rollout Tail
The OBC service has been used to manage the National Rollout tail activity,
installing the 93 remaining post offices taking over the task from the ICL Pathway
Implementation Directorate.
3.8 Field Service Management
3.8.1 Overview
The role of the ICL Pathway Field Service Manager is to manage system
problems that affect individual Post Office outlets. As a result, the impact of the
problem on Post Office business will be minimised, and service levels/customer
satisfaction is maintained. Root causes to problems will be identified, and actions
applied to ensure that the circumstances do not recur.
The FSM team is field-based, and geographically spread across the UK. Each
FSM is responsible for an area of the country.
The role operates within the overall framework of the ICL Pathway Customer
Service Problem Management Process, the End-to End Customer Complaint
Process, and the ICL Pathway/POL Problem Management Interface Agreement,
and the high level process is documented separately in the Field Service
Management Process Document CS/PRD/102.
By reference to extracts from the Horizon System Helpdesk logs, or in response to
referrals from other members of ICL Pathway Customer Service, the Field Service
Managers identify individual Post Offices where there appears to be an underlying
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 36 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd —_ Operations Manual for Customer Service Directorate —_ Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
problem giving rise to a higher than expected level of incidents. A visit to the
outlet is then requested through Post Office Ltd BSM, and subsequently visited by
the Field Service Management. All relevant information is collected during the
visit to assist the FSM with a problem investigation. If immediate actions do not
resolve the issues at the outlet, then an entry is made on the Problem Management
Database, and reviewed regularly at a joint meeting with the Post Office Ltd
Problem Manager.
The Field Service Managers act as Problem Managers within ICL Pathway
Customer Service team, with focus on individual office issues. As such, they may
be appointed as Problem Managers within the terms of the ICL Pathway Customer
Service Problem Management Process (Ref: CS/PRD/021) by the Duty Manager,
in response to cross-domain problems raised by POL BSM. Additionally, within
the terms of the Problem Management Process (Ref:CS/PRD/021), responsibility
for specific office problems may be passed to the appropriate FSM by any other
Problem Manager (Ref Para. 5). The Field Service Managers also participate in
the Management Care Visit programme.
3.9 Service Management
3.9.1 Overview
The Strategic Services Unit exists to ensure that the services required by Post Office
Limited and agreed and offered by ICL Pathway at the post office counter, and in
conjunction with the National Business Support Centre, are available when needed
and meet the service level commitments associated with those services. The Strategic
Services Unit ensures that the Horizon system is properly implemented and operated
across the post office estate, and remains usable for the post office to conduct daily
business for the duration of the ICL Pathway contract.
The Strategic Services Unit has responsibility for conformance to the following
processes that have been implemented through the service management frameworks
and agreed with Post Office Limited:
e The Incident Management Process
e The Problem Management Process
e The Complaint Management Process
Service Management is provided by the Strategic Services Unit to manage the quality
and SLA conformance of suppliers to deliver the following services to post offices as
contracted for between Post Office Limited and ICL Pathway.
© Operation of the Horizon Systems Helpdesk
© Operation of post office break fix engineering service
e Operation of the OBC service (Section 3.6)
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 37 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd Operations Manual for Customer Service Directorate Ref: CS/QMS/007
Version: = 1.0
Commercial in Confidence Date: 26/11/01
The Service Management focus is on providing a consistent and reliable service to
resolve incidents and problems encountered in the Horizon estate, while managing
customer and supplier relationships with the objective of continuous service
improvement. In addition the Strategic Service Unit has a service management
function that seeks opportunities to improve customer satisfaction with the Horizon
system in the post office outlet environment through direct feedback from the end
users. To achieve this the Strategic Services Unit:-
e Provides Service Management resource for managing problems
e Takes Service Management action on issues raised on engineer reply cards
e Allocates Service Managers to the Management Care Visit Programme
e Takes ownership of the Customer Complaint Process.
¢ Monitors supplier performance on a daily and weekly basis
e Reviews suppliers on a monthly basis at the Operational Service Review
The Strategic Services Unit is also responsible for the development and evolution of
these services to support the product life cycle and the introduction of new products
over of the duration of the Horizon Programme.
3.9.2 Key Processes — Incident Management
The Strategic Services Unit has the overall responsibility of ensuring that the
Horizon System Helpdesk function is being performed effectively by the ICL
Pathway service supplier, and the SLAs are monitored daily by the Service
Manager pick up any deviation in performance. The Service Managers have
objectives to ensure that:-
e The Incident Management process supports the flow of incidents through the
support chain, and that matters relating to the quality and performance of
suppliers operating the incident management process are properly addressed
and resolved.
e The Incident Management process supports the prompt resolution of incidents
and achievement of agreed service levels.
e Trends, multiple incidents, or incidents with serious business impact are
properly captured and recorded as problems in the Problem Database and the
Service Manager takes ownership and manages the problem through to
resolution.
¢ Customer complaints are recorded and dealt with appropriately and in an
acceptable timescale, and are escalated where necessary.
e A nominated Service Manager from the Strategic Services Unit performs the
Duty Manager role during core day hours on two days of every week.
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 38 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd —_ Operations Manual for Customer Service Directorate —_ Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
3.9.3. Key Processes — Problem Management
All Service Managers in the Strategic Services Unit take on the role of Problem
Manager for specific problems within their area of responsibility or expertise.
They manage problems in accordance with the Problem Management process,
providing weekly updates to the Problem Management Database.
3.9.4 Key Processes - Complaint Management
The Strategic Services Unit manages the Customer Complaints Process on
behalf of Pathway Customer Service. This involves following steps for each
complaint received:-
¢ Receive complaints proper to ICL Pathway CS from Post Office Limited or
directly to ICL Pathway.
e Log and acknowledge the complaint with the complainant
® Investigate the complaint
Provide a response to the complainant in the appropriate manner
© Close the complaint record once it is agreed that all concerns have been
answered
Identify any improvement opportunities and ensure a plan is put in place to
action them
© Monitor all complaint calls received at HSH Helpdesk for conformance to
resolution times, accuracy and consistency of responses.
e Measures the success of improvement initiatives by monthly reviews of
complaint statistics at the Operational Service Review with key service
suppliers and the NBSC Helpdesk Forum.
¢ Hold a quarterly meeting with the NBSC Customer Relations team to look at
trends and process improvement opportunities.
Note it is not ICL Pathway policy to pay compensation to a complainant but
reimbursement of costs will be considered if investigations show this to be
justified in particular circumstances.
3.9.5 Key Processes — Customer Satisfaction
The SVR process allows feedback on service delivery to be monitored by the
Strategic Services Unit. A card (Reply Card) left at the post office following an
engineer’s visit allows a Postmaster to comment on the quality of the service
provided by an engineer during their visit, and it also invites comment on the
service provided by the Helpdesk. The SVR process has several stages:-
e Ordering of new cards and arranging for any changes with printer supplier
e Distribution of new cards to the Engineer Support Managers
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 39 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd —_ Operations Manual for Customer Service Directorate —_ Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
3.9.6
3.9.7
e Engineer gives a card to the Postmaster following a visit to a post office
e Cards have prepaid postage and are returned by Postmasters direct to the
Strategic Services Unit address
e The Service Manager carries out an initial sift to identify urgent complaints or
concerns before passing them to be input into the SVR database
e Issues are referred to the appropriate section/s for comment and action and
comment
e Any serious concerns by a Postmaster is responded to by letter
e A meeting with the relevant support staff is held bi-monthly to review statistics
and levels of customer satisfaction/ concerns
To monitor the post office end user’s perception of post-implementation services, the
Strategic Services Unit participates in the Management Care Visit Program (MCVP) -
a monitoring program implemented to ensure ICL Pathway fully understands the
Postmaster’s view of the service that ICL Pathway delivers.
The MCVP involves senior ICL Pathway managers visiting randomly selected post
offices and collecting feedback using an aide memoir for the interview.
The resulting information gathered on these visits is collated and entered into a
database to identify common issues and facilitate statistical reporting. Each Service
Manager is targeted with completing 12 post office visits per year.
Key Processes — Problem site monitoring
Problem sites are identified weekly, based on statistics of top ten callers to the
Horizon System Helpdesk. The top ten post offices will initially include all categories
of calls, however for the purposes of this analysis, Software/ Hardware/ Network calls
will be ignored (these areas are dealt with separately by Field Service Managers). The
top ten are then analysed to identify specific problems with the objective of
identifying any gaps in training of the user for the site as a whole or in a specific area.
Those post offices identified as being significantly above the average for calls to the
Helpdesk, will be raised as Problem Sites on ICL Pathway Problem Database through
normal Problem logging channels to Post Office Limited BSM.
Key Service Suppliers
The key suppliers monitored through the OSD Service Review process by Strategic
Services are:
¢ Horizon System Helpdesk — who provide the point of contact for post offices
reporting Horizon system and service problems.
¢ UK System Service — who provides engineer services at the post office for both
incident resolution and OBC services.
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 40 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd —_ Operations Manual for Customer Service Directorate —_ Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
The ICL Pathway Management Support Unit is an internal supplier to the unit. The
MSU provides service performance information used by the Strategic Services Unit to
monitor and improve the service delivered to the customer. The performance data is
held on the CS Intranet — a local web site.
Additionally the following document set provides essential information for, the
successful, delivery of business as usual activity to the Post Office Outlet.
[CS/FS/005 HSH Incident Prioritisation]
[CS/FSP/002 HSH Call Enquiry Matrix]
[CS/PLA/015 HSH Continuity Plan]
[CS/PRD/021 ICL Pathway Problem Management Process]
[CS/PRD/074 ICL Pathway Incident Management Process]
3.9.8 Service Monitoring
A good customer/supplier relationship is essential to the successful delivery of service
to Post Office Limited. Therefore a set of monthly service reviews are vital to the
success of this relationship. All service reviews follow an agreed format, having an
agenda, a chairperson, an action list, and minutes.
The specific set of reviews the Strategic Services Unit play an active part in are:
e The Horizon Service Review Forum where ICL Pathway performance in the
delivery of the end to end service is reviewed with Post Office Limited Business
Service Management, against contracted SLAs.
e The HSH/NBSC Review Forum — where operational matters effecting the delivery
of helpdesk service to the post office are reported and reviewed by participation of
representatives from both customer and supplier helpdesks.
e The Network Transformation Forum where OBC service performance and issues
are reviewed.
e The Operational Service Review, where the “key” suppliers performance is
reported and reviewed.
3.9.9 Service Development
Service Managers have the responsibility for introducing services to support new
Horizon products and early participation at the design and specification stage of a
development programme is necessary to ensure a successful implementation.
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 41 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd Operations Manual for Customer Service Directorate Ref: CS/QMS/007
Version: = 1.0
Commercial in Confidence Date: 26/11/01
3.10 Problem Management
3.10.1
3.10.2
3.10.3
Purpose
Problem Management exists within the Infrastructure Services function. The aim
of problem management is to identify and manage the removal of the root causes
of issues that cause incidents to be raised from within the ICL Pathway estate.
A problem is an underlying cause that may or may have already resulted in
incidents and potentially exists when a defect in the specification, design,
production, implementation, or use of any of the service components results in any
aspect of the service not meeting expectations.
A problem will be raised when the impact of the defect is substantial enough to
warrant action to eradicate it. The problem will be closed when it has been agreed
that the underlying cause has been fixed or removed.
Source of Problems
Problems arise from various sources within the Horizon operational estate and can
be identified by customer representatives, Field Service Managers or ICL Pathway
staff managing and supporting the day-to-day operations of the Horizon estate.
POL identifies issues based upon feedback from within a number of their
operational units. POL raise the potential problem via the ICL Pathway daytime
Duty Manager.
The units managing the day-to-day operations and support of the horizon estate
escalate potential problems to the duty manager. The duty manager will decide if
the issue in hand is to be treated as an incident, a problem or a major business
continuity incident. This is usually decided based on the operational impact,
severity and visibility of the issue.
The Field Service Managers (FSM) interface on a daily basis with the outlets and
identify “problem” outlets from various sources such as trend analysis of incidents
raised, feedback from outlets and POL. The FSM will arrange visits to outlets to
interview the outlet staff and ascertain the scope of the issues within the outlet.
Many of these issues are resolved within the FSM processes but those not
resolved may require elevation to problem level. On such occasions these
problems may be entered directly to the problem management database.
Resources
Problem management within ICLP is resourced from the various operating and
service management units within Customer Service. Problems are allocated to
individual problem managers depending on areas of knowledge and expertise,
areas of responsibility and availability. The service managers who operate as duty
managers in Infrastructure Services carry out this allocation
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 42 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd Operations Manual for Customer Service Directorate Ref: CS/QMS/007
Version: = 1.0
Commercial in Confidence Date: 26/11/01
In addition there is a senior problem manager with normal problem management
responsibilities plus specific tasks such as problem management skills
development, mentor to service managers, monitoring problem updates etc.
There is a problem management database, which provides the basis for the
recording and management of problems controlled by a database administrator
A database administrator has responsibility for general maintenance of the
database, ensuring that problem managers submit updates, production of reports
and ensuring that information on the database is available to POL.
3.10.4 Role of the Problem Manager
The role of the Problem Manager is to co-ordinate the resolution of a problem and
act as a single point of contact for everyone involved with the problem.
Essentially this is a management function.
3.10.5
3.10.5.1
The actions carried out to achieve the required outcome are: -
Investigate and establish the facts
Understand and evaluate all the information available.
Define the problem
Articulate and record the problem and success criteria
Assess the impact and urgency
Establish the impact of the problem on the customer and ICL
Establish responsibilities
Identify the solution owner, agree actions, resources and contingencies.
Monitor and report on progress
Continually review/update reports on plans, actions and timescales.
Escalate where necessary
Escalate to Divisional or Corporate Alert when necessary.
Evaluate success and close the problem
Agree the successful conclusion and close the problem.
Key External Interfaces
As well as the ongoing day-to-day interfaces with other departments internal to
ICL Pathway, there are a number of external organisations that are crucial to the
problem management function.
POL
Both ICLP as the supplier and POL as the customer have responsibilities for
the delivery of a problem management service. It is crucial to the success of
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 43 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd Operations Manual for Customer Service Directorate Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
3.10.5.2
ISD
this service that ICLP and POL work together in all aspects of problem
management.
It is inevitable that there are occasions during problem investigation where it is
not clear in whose area of responsibility a problem lies. It is essential that a
clear understanding exists as to how information and knowledge will be
shared on these occasions.
There is an agreement that sets out this working relationship between ICLP
and POL for the problem management interface between POL (BSM) and
ICLP Customer Service. (Ref. CS/IFS/008). This defines the interaction
required between POL and ICLP when cross boundary problems are raised
and reviewed.
The document defines: -
i. the individual and joint responsibilities of each party
ii, problem notification between POL and ICLP and between ICLP and
POL
iii. problem acceptance
iv. problem control and status
v. teview processes
vi. escalation
vii. potential MBCI’s
viii. agreed priority levels
As a key service supplier for ICLP to the Horizon outlets ISD has a crucial
role to play in the resolution of problems.
There is an agreement that sets out this working relationship between ICLP
and ISD for the problem management interface between ISD Service
Management and ICLP Customer Service. (Ref. CS/IFS/009). This defines the
interaction required to identify, raise and manage problems across the two
divisions.
The document defines: -
e the individual and joint responsibilities of each party
e problem types
© problem control and status
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 44 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd —_ Operations Manual for Customer Service Directorate —_ Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
e review process
3.10.5.3 Other
There is, on occasions, a requirement for ICLP to interface with other third
party suppliers either directly or via POL or ISD in relation to Problem
Management. These third parties are contracted to ICLP, POL or ISD and the
interface is by the appropriate route and subject to the terms of the contract.
Examples are Energis, BT, Escher, Tivoli, Cap Gemini etc.
3.10.6 Review Processes
3.10.6.1 Cross-Domain Problem Management Forum
The cross domain problem management forum is held monthly prior to the
Horizon Service Review Forum (HSRF) and is intended to highlight and
discuss any problems that are cause for concern and may be discussed at the
HSRF.
Either party can identify specific problems to be included in the agenda and
also deals with process issues and progressing outstanding actions.
3.10.6.2 Post Implementation Review Meeting (PIR)
A PIR is carried out if the Problem Manager on either side is unhappy with the
way a problem is resolved or managed. The PIR reviews the way the problem
was handled and looks to highlight the areas that did not operate well and
require improvement, either within the operation of the process or the process
itself.
The output of the PIR is to initiate improvement actions to ensure that the
process is operated as it should be or ultimately improved.
Any action points arising from a PIR will become agenda items at the Gross
Domain Problem Management Review Forum.
3.10.7 Documentation
The following documents are specific to the function of Problem Management: -
CS/PRD/021 ICL Pathway Problem Management Process.
CS/PRO/063_ ICL Pathway Customer Service Problem Management
Procedure.
CS/PRO/110 ICL Pathway Customer Service:
Problem Management Database Procedures.
CS/IFS/008 ICL Pathway/POL Interface Agreement for the Problem
Management Interface.
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 45 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd —_ Operations Manual for Customer Service Directorate —_ Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
CS/IFS/009 ICL Pathway/ISD Interface Agreement for the Problem
Management Interface.
CS/PRD/093_ ICL Pathway Divisional Alert Process.
The following documents are associated with the function of Problem Management: -
CS/QMS/001 CS Policy Manual
CS/QMS/002 CS Process Manual.
3.11 New Service Introductions
The purpose of the CS Service Introduction Team is to support ICL Pathway
Customer Service in the introduction of new facilities and changes to the existing ICL
Pathway solution. The prime functional units are:
¢ Change management
Responsible for the management of Change Proposals within Customer
Service. Responsible for the scheduling of changes to the ICL Pathway
Live estate.
e Service Introduction
Responsible for ensuring that Customer Service is prepared for new
services being introduced to the ICL Pathway solution.
¢ Major release Implementation
Responsible for the organisation and successful completion of major
upgrades to the live estate.
e Release Management (RM)
Responsible for the release of software changes to the live estate.
e Release budget Management
Responsible for providing an estimation of costs for running a live service
including the new service.
Responsible for providing an estimation of costs for the implementation of
software changes and the subsequent actuals.
3.11.1 Change Management
This section of the document describes the role that the Service Introduction Team
plays in Change management.
The aim of the unit is to ensure that all changes to the estate are managed in a
controlled way through Customer Service.
More specifically the unit has responsibilities to:
e Manage CPs through Customer Service
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 46 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd —_ Operations Manual for Customer Service Directorate —_ Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
3.11.2
3.11.3
3.11.4
e Schedule changes to the live estate via the RATS forum
e Liaise with the rest of ICL Pathway on any potential changes forecast
e Interface with the ISD Operational change process
Manage CPs through Customer Service
The unit is responsible to the programme for all changes from a Customer Service
viewpoint by gaining an impact view from all units within CS and reviewing those
impacts on a weekly basis. Ensuring that CPs submitted by CS staff meet the
required criteria and are targeted at the correct release date.
Change timetable
Weekly CS change review meetings are held and are attended by management
representatives from Infrastructure Services, Operations and Service Introduction.
The objective of these meetings is to review the latest position regarding CPs on
the PCCB agenda and ensure that all impacts and actions are completed. No
minutes are produced for these meetings.
The output from these meetings is reported at the weekly Project Change Control
Board.
Change management administration
The operations support team is responsible for the following processes with
change management:
e Registration of change proposals (CP) from within ICL Pathway that require
impacting by Customer Service staff or/and their suppliers.
e The collation and filtration of all impact statements and the response to
Change Management with the impacts in a timely manner.
¢ Reception of supplier change proposals (SCP) for impact within ICL Pathway
e Tracking of approved CP action through to implementation or completion
e Management of actions arising from CP impacting and approval processes
e Production of change management MIS reports specific to Customer Service
and its suppliers
All CPs or SCPs raised within Customer Service are managed by the operations
support team. The team is the prime interface between Customer Service and its
suppliers into the ICL Pathway change management system. All CPs or SCPs are
recorded onto the CP database and managed through its lifecycle from a Customer
Service viewpoint.
CPs are issued daily at various priorities and the team identifies who within CS or
its suppliers needs to provide an impact statement. The impact statements are
chased and then collated into a CS response, these are provided to CM for review
by the PCCB.
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 47 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd —_ Operations Manual for Customer Service Directorate —_ Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
3.11.5 Schedule changes via RATS
The RATS forum is a regular meeting held between the Service Introduction
Team; Operations and Support and various other parts of ICL Pathway, including
representatives from Development Directorate.
The aim of the forum is to ensure that all changes to the live estate, outside of a
major release, are scheduled and hence implemented in a controlled manner.
Where possible changes are grouped together to minimise the number of changes
on the live estate and to obtain efficiencies in testing.
The following items are considered during scheduling:
e Business impact and hence urgency of the change
¢ Dependencies on the change
e Grouping with other changes
e Implications for testing
CPs that are targeted at an interim ICL Pathway release are also discussed at the
forum. The aim of the forum is to identify a potential time when the CP can be
implemented to live and agree or otherwise that the CP can go ahead at the targeted
release. For the scheduling of CPs, and agreement that a CP can be implemented
during a specific interim release the following items are considered:
e All impacts supplied on the CP.
e Potential delivery dates of software changes from Development
e Additional hardware procurement
e Business impact and hence urgency of the change
e Dependencies on the change
e Grouping with other changes
¢ Implications for testing
Once the scheduling of a CP has been considered an impact from RATS is entered on
PVCS.
The Release Management Team performs the administration of the RATS
forum. This activity includes:
e the selection of CPs for discussion
e bringing forward all other items for scheduling
¢ updating the CPs with the result of the forum
e updating the other relevant control system with relevant details
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 48 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd Operations Manual for Customer Service Directorate Ref: CS/QMS/007
Version: = 1.0
Commercial in Confidence Date: 26/11/01
3.11.6
3.11.7
3.11.8
3.11.9
Potential changes
The unit has a responsibility to liaise with the other ICL Pathway units regarding
potential changes that are under discussion for implementation.
This is to ensure that any planning is realistic in terms of implementation on the
live estate.
Operational change
An operational change process (OCP) is also in operation. This process covers
changes required to the live operation and provides an audit trail for all changes
made to the operational estate that are made outside of the Release Management
process. The OCP service is managed and run by ISD on a daily basis. The
Service Introduction Team is responsible for the management processes within CS
for this service and any service developments.
The SSC has access to the live system, which can be used to correct data on the
system when this has been corrupted in some way. The procedure for doing this is
controlled via an OCR.
The SSC ensures that the relevant control systems are kept current and
administration activities required by managers within Customer Service are met.
Service Introduction
This section of the document describes the role that the Service Introduction Team
plays when a new service is required of the operational system.
When a new service is required to become part of the live operational service
there are a number of activities that need to be undertaken with Customer Service
to ensure the implementation is smooth and complete. These activities are co-
ordinated by the Service Introduction Team.
Major activities
The major activities involved in the area:
e Ensure all of Customer Service and its suppliers are aware of the new
service requirement
e Liaise with the main ICL Pathway project manager for implementation of
the new service to ensure Customer Service concerns and requirements are
met
e Ensure the various units with Customer Service and its suppliers are aware
of any requirements on them from the new service
e Ensure the various units with Customer Service and its suppliers are ready
to meet any additional requirements on them from the new service
e Produce and agree a service introduction plan
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 49 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd Operations Manual for Customer Service Directorate Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
e Collate revised costings for running the new operational services
3.11.10 Major Release Implementation
This section of the document describes the role that the Service Introduction Team
plays in the implementation of a major new release.
When the ICL Pathway programme plans a major new release it is the
responsibility of the Service Introduction Team to manage the implementation of
that release to the live estate. This involves a number of activities that are not
necessarily all done by the same individual:
¢ Agreeing the implementation dates
¢ Liaising with POL
¢ Production of implementation plan
e Production of Release notes and strategy documents
e Accepting handovers from PTU and TDA
e Organising the actual upgrade slots and their manning
¢ Post upgrade activities
3.11.11 Implementation dates
The actual implementation dates for a major release are documented at the high
level on the Programme Plan.
The Customer Service implementation plan and Level 3 plan should ensure the
dates on the Programme plan are correct.
The dates and timings of the upgrade are agreed with POL; ISD; SMC; MSS and
Development Directorate.
Any conflict in dates with other activities is resolved between the various parties.
Conflicts should be easily identifiable on the CS Management plan.
3.11.12 Liaison with POL
There are numerous levels of communication with POL relating to any specific
major release implementation. These are detailed below:
3.11.13 Release migration strategy
This document is produced by SIT and is based on the migration strategy
produced by the TDA. It should be approved by the manager of CS and be agreed
with the customer prior to the upgrade. There is normally one version for the
counter and one for the data centre if this is appropriate.
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 50 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd —_ Operations Manual for Customer Service Directorate —_ Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
3.11.14 Release Note
This document is produced by SIT and is based on the Release note provided by
PTU. It should be approved by the manager of CS
3.11.15 Post upgrade report
This document is produced by SIT and is based on the experience of the upgrade
and the first two weeks running following the upgrade. The manager of CS should
approve it. There is normally one version for the counter and one for the data
centre if this is appropriate.
3.11.16 Support Notice
This document is produced by SIT and is based on the arrangements for the
upgrade. It should be approved by the manager of SIT.
3.11.17 Release authorisation
Release authorisation can take one of two formats depending on the size of the
release.
3.11.17.1 Small releases
For small releases no formal criteria is defined. POL sign off the release to
live via an email based on the contents of the Release Note; migration strategy
and discussions regarding the status of the release.
3.11.17.2 Large releases
For large release formal release authorisation criteria are agreed and reviewed
on a regular basis prior to the upgrade. These criteria work on a traffic light
system and criteria can be set against ICL Pathway and other POL suppliers
e.g. OpTIP.
3.11.18 Status reviews
Regular meetings are held with POL to review the status of all the planned
upgrades.
3.11.19 Implementation plan
An implementation plan is produced by SIT to cover all activities required to
complete the upgrade.
The plan itself covers all activities, both pre and post upgrade, to ensure that all
requirements are met and all dependencies are recognised.
The plan is based on the migration strategy that is produced by Development
Directorate. The plan is reviewed on a regular basis with all parties taking part, or
interested in the upgrade.
© 2001 ICL Pathway Ltd Commercial in Confidence Page: Sl of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd —_ Operations Manual for Customer Service Directorate —_ Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
3.11.20
3.11.21
3.11.22
3.11.22.1
3.11.22.2
3.11.23
3.11.24
3.11.25
3.11.26
Documentation
Most of the documentation produced has been covered in the adjoining sections.
A few additional documents are covered here. These are for internal ICL Pathway
use only.
Support Notice
This document is produced by SIT and is based on the arrangements for the
upgrade. It should be approved by the manager of SIT and covers all internal
contacts.
Authorisation criteria
Release authorisation can take one of two formats depending on the size of the
release. This criteria controls the handover from Development Directorate to
Customer Service.
Small releases
For small releases no formal criteria is defined.
Large releases
For large release formal release authorisation criteria are agreed and reviewed on a
regular basis prior to the upgrade.
Handovers from PTU and TDA
A number of formal handovers are required from other parts of ICL Pathway into
Customer Service before the release will be authorised for live usage.
Release Note
A Release note is provided by PTU to documents the contents and outstanding
issues with the release.
Sign off
A sign off form is received from PTU to confirm that the release is tested and
ready for release to the live estate.
A separate sign off may be provided for the counter and data-centre part of any
upgrade.
Migration strategy
Development Directorate provides a migration strategy. It provides details on the
method to be used for migrating the live estate.
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 52 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd —_ Operations Manual for Customer Service Directorate —_ Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
3.11.27 Actual upgrade
The major activities involved in the upgrade are split between the data centre and
counter. The activities are very dependent on the content of the actual release. The
order for release is documented in the Release Note provided by Development
Directorate.
3.11.28 Post upgrade activities
A number of activities are often left until the main part of the data centre upgrade
is complete. The activities are very dependent on the content of the actual release.
The order for release is documented in the Release Note provided by
Development Directorate.
3.11.29 Release Management
This section describes the operations performed by Customer Service Release
Management team. The CS Release Manager (CSRM) is responsible for
authorising changes to the live Horizon environment.
The following procedures are described:
* Deciding whether a software fix should be developed
¢ Defining the release plan and time scales
e Managing the delivery of supporting services
e Creating the software fix
© Re-raising a release note
e Authorising the software fix
© Completing the release process
3.11.30 Deciding whether a software fix should be developed
This section describes how ICL Pathway CS decides if a fix should be
implemented for a problem.
1. ICL Pathway CS holds a Release Management Forum weekly to decide what
fixes should be created and to assess the impact of any associated risk.
Representatives of each unit involved in the software release process should
attend the RMF meeting as follows:
e System Support Centre
e ICL Pathway Development
¢ Operational Test Team
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 53 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd —_ Operations Manual for Customer Service Directorate —_ Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
¢ Configuration Management
e Customer Service
e ICL Outsourcing
¢ Other units as required
The SSC represents the customer in the RMF in terms of the calls made to the
helpdesks. The Service Managers know of other problems that are significant
to the customer, through parallel escalation processes. The Service Managers
feed their knowledge into the RMF through the CSRM
2. The CSRM sends a list of all outstanding open calls to each member in
advance of the RMF meeting, allowing the attendees to identify their
requirements.
The calls are cleared calls, that is, have a corrective action in place and are
awaiting closure, either because the decision has not been made whether to
create a fix, or the decision has been made to create a fix and it has not been
completed
3. Each attendee brings with them information about the dependencies, priorities,
tisks, issues, alternative options and time scales for the open PinICLs. It may
not be possible to estimate how long certain activities will take until the
priorities have been agreed, therefore, some information may not be available
until after the RMF meeting
4. The open calls are discussed, with the information provided by the members.
For example, details of any workaround and business impact, until the
situation is understood. Then the RMF decides whether a release is required
5. If SSC consider a problem too urgent to wait for the weekly RMF meeting, it
requests the CSRM to fast track the fix.
The CSRM assesses the situation and, based on the priorities of each unit, the
risk of releasing the fix, the alternative options, any dependencies between
fixes and any other issues, decides either the problem can wait until the
weekly RMF meeting or agrees to a fast track solution.
If the fix is fast tracked, the CSRM holds a virtual forum by taking the release
request to each RMF member (in person or by phone, fax or PinICL) for input
and sign off. The activities in the high level plan are reduced to a minimum
before the release and the rest of the activities, for example, documentation,
are carried out after the release has been made.
In an emergency, the following people can authorise a fix to be produced
without contacting the CS Release Manager:
e SSC Manager
© CS Operations Manager
e Problem Manager
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 54 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd —_ Operations Manual for Customer Service Directorate —_ Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
If this happens, the person authorising the fix ensures that the CS Release
Manager is informed so that the release process can incorporate the fix.
Where an emergency fix has been applied to get systems up and running,
release management processes may be applied retrospectively
6. Ifthe RMF decides not to develop and release a fix, one of the following
actions takes place:
(a) The RMF decides that a live problem can wait until the next major
software release. In this case, the CSRM clones the call on the new release
and returns the call on PinICL to EDSC.
(b) If the original is not a live fault it is up-versioned and returned to Gen Dev.
(c) The RMF identifies the call as not being a problem at all, that is, the
perceived shortfall is the way the system was designed to work. RMF
retums the call to the originator so they can raise a change request for an
enhancement to the system
(d) If rejection is considered to have significant impact to the customer, the
CSRM escalates the problem to Strategic Services before authorising
closure of the call
Note: Fourth line support PinICLs include problems that are not in the current live
environment. These are not relevant to the release management process and are
managed by development. However, if a fourth line support PinICL identifies a
problem in the current release, the RMF decides whether or not to postpone the
fix.
3.11.31 Defining the release plan and time scales
Once the decision has been made to create a fix; the following issues may need to
be taken into account.
1. Any dependencies between calls.
2. Any situations where a new release will run in parallel to an old release
before the old release is upgraded.
3. The priority of each fix according the different needs of each CS unit.
4. CSRM updates the report for POL, for which they are currently
responsible, with the expected completion date to resolve the call
5. For most releases, the delivery date is not significant. The release is
simply distributed at the earliest convenient time. For releases that have a
significant date line, the following steps are taken:
e Each unit involved in the release provides details of the time scales in
which they can complete the required work
¢ All parties involved agree to a high-level plan for each release
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 55 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd —_ Operations Manual for Customer Service Directorate —_ Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
The CSRM is responsible for determining the availability of the
Operational Test Rig. and co-ordinating the allocation of users to it.
6. The CSRM:
(a) Creates a software fix release note
(b) Captures all the information and raises a release PinICL for each
telease.
The Release PinICL references all the PinICL calls (or HSH / SMC calls)
that it covers and each original PinICL call is updated with the new Release
PinICL number. Progress queries on the original PinICL calls are found by
reference to the software fix release note attached to the new Release
PinICL
(c) Attaches the release note to the PinICL and sends it to PIT
7. The manager for each unit updates the release PinICL with details of their
progress
8. The CSRM monitors the progress of the software fix release note by
accessing the release PinICL and manages any deviations from the high-
level plan to ensure that all units are aware of the delay and the impact can
be minimised. The CSRM does this by negotiation with the different units
in the release process both in and outside of the RMF.
If necessary, the CSRM escalates problems to Service Management
Notes:
1. The CSRM owns the plan
2. A release PinICL is a different kind of PinICL to those used by
SSC so that it is not counted in problem statistics
3.11.32, Managing the delivery of supporting services
Other units may be involved in the release process who are not part of the normal
RMF, for example, training, helpdesks, documentation, bench-marking, hardware
installation. In most cases fixes will not affect these units, but, if any of these units
are involved, the CSRM co-ordinates their activities, identifying any testing
requirements and receiving notification from the units when their preparation are
complete, as follows:
e For HSH and SMC: notification of operational readiness
e For documentation: notification of completion of update, and the
documentation itself, so that CSRM can distribute it
e For hardware: notification of operational readiness.
e For user training: notification that the training material is ready, trials of
the material are scheduled on the Operational Test Rig, training is
delivered where necessary
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 56 of 92
FUJ00079875
FUJ00079875
ns Manual for Customer Service Directorate Ref: CS/QMS/007
Version: 1.0
ICL Pathway Ltd — Operati
Commercial in Confidence Date: 26/11/01
Provided that all the supporting preparation is complete, CSRM sign off the
release note.
Note that the time taken for the distribution of the documentation has to be
taken into account in the delivery schedule of the release.
Most fixes do not normally affect any of these other units.
3.11.33 Creating the software fix
Fourth line support creates the fix and the Tivoli installation scripts, and unit tests
and documents the fix. Any fixes that fail testing must be recreated.
ICL Pathway development complete the release note with details, such as the
affected estate, and send it via PinICL to Configuration Management. If external
fourth line support is involved, ICL Pathway development manage them and
complete the release note on their behalf.
3.11.34 Re-raising a release note
A software fix could fail in LST or it could be applied in the wrong way. When a
failed fix is investigated and the content of the release is found to be at fault, then
one or more new work-packages are developed. CSRM withdraw the original
software fix release note and raise a new one to cover the new work-package(s).
3.11.35 Authorising the software fix
The CSRM authorises the software fix release, having:
1. Ensured that all testing and preparation is complete
2. All sign offs have been attained.
3.11.36 Completing the release process
1. Either ISD/SMC or ISD Service Management distributes software. After the
software has been distributed, CSRM receive notification of the success or
otherwise of the release:
e If ISD/SMC or ISD Service Management confirm the successful release
of the software, CSRM receive the release PinICL from CM. If the
delivery was only to the pilot estate, which may be the case for high risk
fixes, CSRM authorise the full delivery to go ahead
e If the distributing unit report problems with the distributed software,
CSRM may authorise the regression of the release. (Regression means
withdrawing the software fix that had been installed)
2. Provided that the release is successful, CSRM sign off the release note as
complete. CSRM then close the release PinICL.
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 57 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd —_ Operations Manual for Customer Service Directorate —_ Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
3.11.37 Work Instructions
A set of work instructions complement the processes above. They are held on the
Customer Service V drive with an index at v:ReleaseMgt\CSRM Working
Documents\DocPlan_Index_1
3.11.38 Software Distribution Service Review
A review is held on a monthly basis with the unit providing the software
distribution service.
3.11.39 Release budget management
This section of the document describes the costs that are maintained by the
Service Introduction Team.
Costs associated with service introduction are collected in several places:
1. When the ICL Pathway programme is discussing new business opportunity it
is the responsibility of the Service Introduction Team to manage the
estimation of the costs associated with:
¢ implementation
e subsequent live running of the new service.
e other CS involvement e.g. SLA measurement changes
a. When the ICL Pathway programme plans a major new release it is the
responsibility of the Service Introduction Team to manage the costs associated
with the implementation of that release to the live estate. Estimates are made
prior to the implementation and actuals are produced after the event.
b. When the ICL Pathway programme plans a new service it is the responsibility
of the Service Introduction Team to manage the estimation of the costs
associated with the live running of the new service.
c. When an interim counter fix is applied to the live estate in isolation (i.e. with
no other fixes going at the same time) the actual ISDN line charges are found
out and recorded.
3.12, Management Support
3.12.1 Business Support
3.12.1.1 EPOSS and APS reconciliation
Reconciliation incidents may arise for a number of different reasons. In most
cases there is a mismatch between the information held in different parts of the
ICL Pathway system. The task of the Business Support (BS) section is to
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 58 of 92
ICL Pathway Ltd — Operati
FUJ00079875
FUJ00079875
ns Manual for Customer Service Directorate Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
investigate and financially resolve reconciliation incidents. If a similar
reconciliation incident occurs a number of times, the BS team identifies it as a
problem incident to be managed through the problem management process.
Possible incidents that may occur are:
¢ Unmatched transaction reversals
e Transaction rejection by TIP
e Incidents raised by clients
e Incidents raised by customers
e EPOSS counter reconciliation report errors
e APS reconciliation reports
The Business Support Analyst investigates Business Incidents.
3.12.1.2 Daily APS and EPOSS reconciliation report retrieval and checking
Following the implementation of release CSR+, the full set of APS and
EPOSS reconciliation reports are delivered automatically to the appropriate
folder held on the MIS Client PC situated within MSU. These reports are
available daily before 08.00hrs. In the event that a system problem prevents
this automatic process from being completed, both APS and EPOSS reports
will be extracted from central systems by CS / SSC and delivered to CS /MSU
daily via e mail to be available before 08.00hrs.
The Business Support Analyst will retrieve and analyse the reports daily. If
any errors are present on the reports, these will be investigated and any
incidents and queries will be identified and reported to POL.
3.12.1.3 Investigating reconciliation incidents
This section describes the general procedure that the BS follow to investigate
all types of reconciliation incidents. The BS:
1.
If an error has been identified, the Business Support Analyst will
raise and log a call. This call will provide a unique reference
number. This log will also provide a PinICL, which will detail the
error on the report.
. Business Support Analyst will raise a Business Incident
Management Service Report (BIMS) including details of the
rejected transaction. Where applicable a Manual Error Report
(MER) is issued.
. SSC are notified of the error via the PinICL and they will
investigate the reason for the transaction rejection/error by
checking the transaction details for invalid or corrupted fields.
SSC provide the BS team with the correct details using the PinICL
and entering the findings onto BIMS.
© 2001 ICL Pathway Ltd
Commercial in Confidence Page: 59 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd —_ Operations Manual for Customer Service Directorate —_ Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
5. This BIMS report is issued to POL on a daily basis at the end of the
business day.
3.12.1.4 Dealing with recurring reconciliation incidents
This section describes the procedure to deal with recurring reconciliation
incidents.
This procedure is jointly carried out by the BS Team and the Customer
Service Problem Manager (CSPM). The CS Problem Manager investigates the
incident after the Management Support Unit has dealt with the financial
reconciliation.
The procedure is as follows:
1. If the same or similar reconciliation incident occurs more than once, the
BS team reports it as a problem incident to the Customer Service Problem
Manager (CSPM) by sending an email requesting investigation of the
incident.
The email contains details of the type of incident and the PinICL reference
number. In addition, the BS team passes hard copies of all similar
incidents to the CSPM.
2. The CSPM progresses the incident investigation after the BS team has
carried out financial reconciliation. The BS team requests a response time
from the CSPM of less than two weeks.
3. The CSPM sends a progress report detailing the findings of the
investigation to the MSU on an agreed date.
4. On receiving the progress report, the MSU updates the existing System
Incident Log (SIL).
5. If POL or the Horizon System Service Manager (HSSM) request further
investigation of the problem incident, the MSU issues an updated System
Incident Log (SIL) report to POL and HSSM for information.
Invoicing: If a MER is issued to supply details of missing or erroneous
transactions, Pathway are liable for an agreed charge. MSU manager and POL
agree on a monthly basis the level of this charge based upon the number of
MER’s issued. If agreement cannot be reached between the two parties, a Case
Law referral form is completed by the MSU manager and passed to Pathway
Commercial for discussion and agreement with the POL counterpart. The
subsequent decision is then used as a precedent for similar incidents, which
may occur.
3.12.1.5 Dealing with reconciliation enquiries
Enquiries resulting from POL being unable to complete a reconciliation of the
ICL Pathway reports to their internal totals are referred to the Horizon System
Helpdesk.
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 60 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd —_ Operations Manual for Customer Service Directorate —_ Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
The Helpdesk logs the call and provides a call reference number. If the query
is resolved during this initial call, the Helpdesk closes the call.
If the Helpdesk is unable to resolve the query, it passes the call to the ICL
Pathway BSU reconciliation team who take over ownership of the call and
communicate directly with POL to resolve it.
The reconciliation team logs all the calls that they receive requiring
investigation as reconciliation queries and maintains a full audit trail.
3.12.1.6 Archiving the reports
Customer Service hold electronic copies of all reconciliation reports for seven
years and are able to provide copies of any reconciliation report or file on
request within this period.
3.12.1.7 I Monitoring and Managing Customer Satisfaction
The MCVP process is being reviewed while ICL Pathway work with the POL
to decide how they wish to progress this activity.
3.12.1.8 MCVP
To monitor the users’ perception of ICL Pathway’s post-implementation
services, the Management Support Unit manages the Management Care Visit
Program (MCVP) - a monitoring program implemented to ensure ICL
Pathway fully understands the Post Masters view of our service. The MCVP
involves senior ICL Pathway representatives visiting selected post offices and
collecting feedback using a predefined interview pack. It is expected around
500 outlets per annum will be visited.
3.12.1.9 Training
Before the interviewers have any contact with the post offices, the
Management Support Unit-Business Support Manager will:
1. Explain the purpose and the goals of the MCVP.
2. Go through the interview procedure and questionnaire in detail.
3. Present all other relevant documentation.
4
Answer any questions and addresses any concerns raised by the
interviewers.
All interviewers will be briefed to inform them that each interview must
follow a standard procedure so that the results can be fairly compared and a
true analysis obtained.
3.12.1.10 Preparations and documentation
The interviewers will be sent electronic copies of relevant documentation, plus
hard copy interview packs containing all relevant reference documentation.
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 61 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd —_ Operations Manual for Customer Service Directorate —_ Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
The interviewers maintain the interview packs as necessary and take them to
interviews. The interview pack contains:
° Procedure document (including the Interviewer’s Summary Guide)
. Phone script
. Sample forms
° Other documents that the questionnaire refers to
. Questionnaire
. List of post offices to contact
The interviewer will then arrange interviews at the Post Office Outlets
allocated to them, attend and conduct the interview and complete the MCVP
report.
3.12.1.11 Service Visit Records
In addition to the MCVP the Management Support Unit also runs the Service
Visit Reply card process, which is used to monitor the service performance
achieved by ICL engineers who visit outlets to conduct remedial or change
activity.
Through this process Post Masters are able to comment on the quality of the
service provided by an engineer during his visit, including any related contact
to the Horizon System Helpdesk (HSH).
3.12.1.12 Routine monthly analysis
The Business Support Unit carries out an initial analysis of the returned cards
and pick out any issues needing immediate action. Having done this, the cards
are then passed to the Management Support Unit for monthly analysis and
formal reporting purposes. Generally reports cover:
e The percentage of feedback cards returned compared with total visits
made. ICL System Service provide the number of total visits made.
¢ The percentage of positive and negative responses by question.
¢ Comments on key areas of satisfaction or dissatisfaction.
3.12.2. Service Performance
The efficient provision of information to the customer, ICL Pathway and ICL /
Fujitsu staff about the performance of the ICL Pathway system is a key part of the
Service Performance component of the ICL Pathway solution. This activity is
managed by MSU in ICL Pathway Customer Service, with emphasis placed on the
following specific areas:
e The monitoring of service performance (in accordance with Service Level
Agreements, where applicable), raising and in some cases resolving any issues
arising there from
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 62 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd —_ Operations Manual for Customer Service Directorate —_ Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
¢ The support of the activities of the CS organisation and the broader Pathway
ICL organisation through the provision of management information(MI) on
both a regular and ad-hoc basis
e To support Post Office counters Ltd (POL) through the provision of
information on an ad hoc basis
In practical terms, this is achieved by means of a number of clearly
identifiable data extraction, processing and reporting activities that can be
categorised according to the nature of the requirement, ie. what they are
driven by:
¢ Legislative obligations
¢ Contractual obligations
¢ Good business practice
e Issue management and investigation
For the most part, these activities are periodic (daily, weekly monthly or
quarterly) but some are event driven. The following table identifies the
specific deliverables according to frequency and associated activities that help
monitor service performance:
Activity Driver Frequency
Service Performance Report MI Weekly
Service Review Book Contract Monthly /
Quarterly
Vital Statistics Report MI Monthly
Business Incident Management Report Contract Monthly
SLA Remedial Calculations Contract Quarterly
Ad Hoc Query Customer As Req
Outlet Data Maintenance MI Daily
Powerhelp Data Extraction MI Daily
HSH Performance Reporting MI Daily
Non polled Outlet Reporting MI Daily
YG Pilot Rollout Programme Monthly Report Customer Monthly
YG Daily Call Statistics MI Daily
YG Weekly Call Extraction MI Weekly
YG Weekly Transaction Extraction MI Weekly
Benchmarking Contract Monthly
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 63 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd Operations Manual for Customer Service Directorate Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
OBCS Volumes & Values MI Monthly
Daily Call Volumes MI Daily
Slow Running Report (AHQ 317) MI Weekly
PDA Transaction Volume (Report 202) MI Monthly
AP Monthly Transaction Volume (Report 344) MI Monthly
Data Extraction and Maintenance MI/Customer Daily/Weekly or
¢ Non Polling Outlets as required
e Restarts
e All Calls
Field Service Manager’s Weekly Report MI Weekly
Field Service Manager’s Monthly Report MI Monthly
3.12.2.1 Producing and scheduling MIS reports
The Service Performance team produces MIS reports that measure and
monitor system and business performance. This is done on a regular or adhoc
basis, as can be evidenced in the table above.
3.12.2.2 Ad hoc report queries
This section describes how MSU deals with ad hoc report queries in a
controlled manner to provide a response within five working days. Requests
for ad hoc reports come from a single point of contact within POL Service
Management, or internally from departments within ICL Pathway
The procedure is completed by one of the MSU Information Analysts as
follows:
1. When MSU receives an ad hoc report query, (via the Ad Hoc Query
Mailbox) on an Ad Hoc Query Request Form, the analyst updates the Ad
Hoc Query Database with details of the request and issues an immediate
confirmation of receipt by return of e-mail. The Analyst will also estimate
the length of time the report will take to produce or advise if the
information cannot be supplied.
2. The Ad Hoc Query Database enables MSU to control the requests that it
receives. If an ad hoc report is requested on a regular basis the Analyst
asks the requestor to confirm the frequency with which the report is
required and if the expectation is that the report is to continue, MSU will
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 64 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd —_ Operations Manual for Customer Service Directorate —_ Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
request the originator to raise the appropriate Change Request
documentation.
3. If the Analyst estimates that the ad hoc report will take longer than 5 days
to complete, agreement with the requestor is sought for an extension to the
timescale. This is confirmed by e-mail via the Ad Hoc Query Mailbox.
4. When the report has been run and the results sent to the requestor, or if the
requestor cancelled the request, the Analyst will close the request and file
details of the report within the Ad Hoc Query Database
3.12.2.3 Service Review Book
The Service Review Book (SRB) is a monthly document that reports on
service performance for the previous calendar month. It is issued to Post
Office Networks (POL) and ICL Pathway Management.
The SRB has two issues, a data only version - to be issued on the fifth working
day of each month, via e-mail, and a data & comments version - to be issued
on the tenth working day of each month, via e-mail.
Each end of POL quarter (Feb, May, Aug, Nov), as well as producing the data
for that month, quarterly data is also produced.
This report identifies key areas within the Horizon solution and analyses
volumetrics and service performance information, in line with the Contract.
The MSU Information Analysts complete the report.
1. Obtain Transaction volumetrics from the Data Warehouse using the
Business Objects reporting tool for the applicable transaction streams
requiring analysis. Obtain Help Desk call details and volumetrics from the
Powerhelp system or local databases using either the Business Objects
reporting tool or Access queries. Obtain System Service calls from local
database. Obtain Training information from Strategic Services Team.
Obtain Business Incidents from Business Support Team.
2. Analyse the information retrieved according to the requirements of the
report.
3. Present the data in the agreed manner — either in tabular or graphical
format.
4. Alert respective departments within ICL Pathway of any adverse
performance noted.
5. Pass the completed report sections to the Intranet Administrator to place
into the Customer Service Intranet site.
6. Issue email copies of the report to the Management Team and POL
Management.
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 65 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd —_ Operations Manual for Customer Service Directorate —_ Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
3.12.2.4 Weekly Service Performance Report Production
MSU publishes a Weekly Service Performance Report for the ICL Pathway
Management Team and others (on a need to know basis.) This report contains
data one week in arrears to enable the data to be collected from the outlets.
Wherever possible though, an up to date position is reflected within this
report. A reporting week is from Sunday to Saturday.
This report identifies key areas within the Horizon solution and analyses
volumetrics and service performance information.
The MSU Information Analysts complete the report.
1. Obtain Transaction volumetrics from the Data Warehouse using the
Business Objects reporting tool for the applicable transaction streams
requiring analysis. Obtain Help Desk call details and volumetrics from the
Powerhelp system or local databases using either the Business Objects
reporting tool or Access queries.
2. Analyse the information retrieved according to the requirements of the
report — these
are ongoing and can change week on week.
3. Present the data in the agreed manner — either in tabular or graphical
format. Include a
written analysis of any trends and observations.
4. Alert respective departments within ICL Pathway of any adverse
performance noted. This should be completed via the PinICL system.
5. Pass the completed report sections to the Intranet Administrator to place
into the Customer Service Intranet site.
6. Issue hard copies of the report to the Management Team or others as
requested.
3.12.2.5 Service Level Agreements
The following sections describe how MSU monitors and maintains Service
Level Agreements for all ICL Pathway contracts that are under formal change
control.
3.12.2.6 Maintaining Service Level Agreements
ICL Pathway stores and maintains service performance measures and related
data within a software application called the Service Level Contract
Administrator (SLCA). MSU maintains all parameters that relate to the service
levels on the SLCA via File Controller access.
MSU uses the SLCA to:
e Raise a CP for a change of service performance measure agreed between
customer, ICL Pathway and associated supplier
e Change parameter values via the Maintain performance measure facility in
the SLCA
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 66 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd
ns Manual for Customer Service Directorate Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
¢ Change the effective ‘from date’ for all changes made
e Log changes using the audit module within the SLCA application giving
cross-references to the changes
e Check that the electronic changes are reflected within the commercial
contracts of the Customer, ICL Pathway and associated supplier
MSU uses the SLCA for manual update to:
e Enter details from source data in the format and structure defined in the
contract standing data application
e Validate data before input and after input before commit
e Log changes using the audit module within the SLCA
e Retain all source data used as input for audit purposes
e Input manual performance measures source data in the required time-frame
for the period under review
3.12.2.7 Monitoring Service Level Agreements
ICL Pathway has responsibilities to demonstrate to its customer that it:
© Monitors service delivery in all areas where performance measure criteria
exist
e Applies service management at all levels with alerts raised where service
falls below expectation
SLA conformance information is obtained from the Data Warehouse, MSU
developed databases and information supplied from the Pathway suppliers.
Following is a list of data gathered or generated by System Performance:
e HSH Telephony: Conformance information calculated by ISD and
delivered to MSU daily
e HSH Call to Resolution: Call details obtained by ISD and delivered to
MSU daily where conformance is calculated
e System Service: Call details obtained by ISD, amendments to call duration
are calculated by ISD and supplied to MSU on a daily basis where
conformance is calculated
e Data File Delivery: For all Data File Delivery SLAs, MSU run queries
against the Data Warehouse. These are:
e APS/OBCS/TPS/ APS Client
e APS Ref Data / OBCS Stops / Ref Data
e LFS
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 67 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd —_ Operations Manual for Customer Service Directorate —_ Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
3.12.2.8 Business volumetrics
The ICL Pathway programme is significantly affected by the level and
variance of business volumetrics. The baseline for volumetrics is the reference
source of the Workload Brief, subsequently updated and maintained as the
Workload Compendium. This is a customer-owned document from which the
Service Performance Unit generates enhanced supporting business volumetrics
on behalf of ICL Pathway.
The outputs from this impact analysis are the prime source of data for
planning and sizing activities carried out by the ICL Pathway development
teams and by ICL Pathway's suppliers.
When a new version of the Workload Compendium is issued, the Service
Performance Unit carries out an impact analysis on any changed areas. If the
level of change in any area is greater than 5%, the Service Performance Unit
notifies the ICL Pathway Director, Finance and Commercial to enable
contractual variance analysis to be carried out and provides associated impact
analysis data.
Supplementary impact can arise from changes to supplier-related volumetrics
as described in the following sections. They are dealt with and processed in
the same manner as changes to the Workload Compendium.
After carrying out the impact analysis of any changes, the Service
Performance Unit updates the ICL Pathway Business Volumetrics portfolio.
This portfolio is the means by which business volumetric changes are
communicated to ICL Pathway.
Implementing business volumetrics processing is described in associated work
procedures and instructions held by the Service Performance Unit.
3.12.2.9 Horizon System Helpdesk volumetrics
The Service Performance Unit maintains Horizon System Helpdesk (HSH)
call volumetrics. The HSH volumetrics model provides data about HSH call
volumetrics during the whole life of the ICL Pathway system. In particular, it
produces daily and monthly analyses.
The outputs from the model are a main source of data for planning and
commercial use by the HSH supplier as well as for sizing activities by the ICL
Pathway development teams.
The key input parameters that contribute to re-appraisal of the HSH call
volumetrics model and result in a new issue of the model are changes to:
¢ Workload Compendium
¢ Horizon plan
e ICL Pathway commercial model
e System MTBF parameters
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 68 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd —_ Operations Manual for Customer Service Directorate —_ Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
Less significant changes that result in reappraisal of the HSH call volumetrics
model and result in an update to the current model are:
¢ Minor adjustment in roll-out programme profile
¢ Correction to key commercial ratios
e Minor update to ICL Pathway commercial model
e Minor changes in Workload Compendium
¢ Minor changes in Horizon plan
In addition to the above, MSU and the HSH Manager hold a quarterly review
of the key ratios relating to inappropriate calls handled by the HSH. Where
they agree, they adjust the key ratios accordingly and release a new version of
the current HSH model.
Before releasing a new version of the model, either within ICL Pathway or
externally, the Service Performance Unit ensures that the Director, Customer
Service, validates the model and the Director, Finance and Commercial,
authorises it. ICL Outsourcing receives a copy of each variant of the HSH call
volumetrics model output.
MSU updates the ICL Pathway Business Volumetrics portfolio with details
about changes to the HSH model. This portfolio is the means by which
business volumetrics changes are communicated throughout ICL Pathway.
Implementing HSH call volumetrics processing is described in associated
work procedures and instructions held by MSU
Ad hoc analysis volumetrics:
MSU deals with ad hoc analysis volumetrics as they arise. It obtains source
data either from the existing volumetrics models or by specific enquiry to the
ICL Pathway Service Performance Data Warehouse by access to a Business
Objects Universe.
MSU only accepts requests for ad hoc data volumetrics from sources who are
authorised to have access to the data. Requestors must make requests to MSU
on an Ad Hoc Query Request Form. The Service Performance Unit supplies
the form to the requestor either electronically or as a hard copy.
MSU reviews requests for ad hoc volumetrics and, if it finds them acceptable,
gives the requestor an estimate of:
e Delivery time
¢ Format of results
e Constraints that limit the resolution of the query
e Limits to be applied
If it is unable to progress the query, MSU gives:
e Reasons for not progressing the query or for delay
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 69 of 92
FU.
ICL Pathway Ltd —_ Operations Manual for Customer Service Directorate —_ Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
FUJ00079875
IJ00079875
e Costs that may need to be met
e Limitations of use of any data to be provided
MSU aims to provide a response to all queries within a time frame
commensurate with business need and cost in an effective and professional
manner.
Implementing ad hoc volumetrics query processing is described in associated
work procedures and instructions held by MSU.
3.12.2.10 Field Service Manager Statistics
3.
4.
MSU provides weekly and monthly statistics to a team of Field Service
Managers. This team is responsible for the proactive identification and
management of system problems that affect individual Post Office outlets. The
idea is to minimise the impact of problems on Post Office outlet business and
to restore service levels and customer satisfaction.
The weekly FSM report can be divided into the following categories: -
. Record of outlets with the highest incidents of Environmental (E),
Hardware (H), Complaint (M), Network (N), Operational (O) and
Software (S) related calls on a national and regional basis.
Details of all the above calls
Frequency of calls by FAD code that conform to the above criteria over a 13
week period.
Details of calls filtered by key words
The monthly FSM report include:-
. Monthly record of outlets with the highest incidents of Environmental (E),
Hardware (H), Complaint (M), Network (N), Operational (O) and Software
(S) related calls on a national and regional basis.
. Frequency of calls by FAD code that conform to the above criteria over a 13
week period.
Monthly report of top 30 outlets with the highest incidents of ‘restarts’.
Two-month variance analysis of calls per outlet.
3.12.2.11 CS intranet site
The CS Infrastructure Services unit provides and maintains an intranet site for
use by ICL Pathway Customer Service and senior ICL Pathway management.
The site address is currently:
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 70 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd —_ Operations Manual for Customer Service Directorate —_ Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
The site is based on a Windows NT Personal Web Server; the documents are
created using MS FrontPage.
Currently, the site provides the following facilities and information:
¢ Management information reports
¢ ICL Pathway CS organisation and contact information
¢ Noticeboard
e CS procedures and operations manuals
e Site search
The CS intranet site administrator is responsible for maintaining and
developing the site. This includes the following tasks:
e Updating and archiving reports
¢ Managing usernames and password access to report pages
e Updating organisational information. Note that staff are expected to update
their own personal and contact details
e Ensuring that procedures and operations manuals on the site are updated to
reflect the latest versions of documents in the ICL Pathway library
3.12.3 IT Infrastructure
The CS Infrastructure Services Unit is responsible for ordering all Office Desktop
equipment for ICL Pathway. The process involves a number of people and
departments within and outside ICL Pathway:
e The originator of the request for IT equipment
e The CS Infrastructure Services IT administrator who manages the ordering
process
e The ICL Pathway Accounts Department which raises the purchase order and
pays the invoice
e The supplier who supplies the goods or service
The following description of the process is divided into three sections:
1. Raising an order
2. Processing an order
3. Receiving the goods
3.12.3.1 Raising an order
To raise an order:
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 71 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd —_ Operations Manual for Customer Service Directorate —_ Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
1. The individual originating the order identifies the requirement and
technical specifications of the equipment.
For standard desktop equipment, for example, PCs and printers, CS
Infrastructure Services are able to advise on what to purchase and the
suppliers to use so a detailed technical specification need not accompany
such requests. For non-standard orders, for example, specific software or
servers, it is the responsibility of the originator to determine the
specifications and technical requirements
2. The originator checks with CS Infrastructure Services to see if the
proposed supplier is already registered on the ordering system.
If there is a known supplier, the originator checks with the CS IT
department to find out if they have the supplier’s information. For a new
supplier, the originator provides the supplier’s bank details and a copy of
the supplier’s company letterhead showing the VAT number with the
purchase request
3. Having established the specification and technical requirements the
originator completes a Purchase Order Request Form (PORF). Refer to
Local Procedure when raising a purchase order (CS/PRO/105) when
raising the order
4. The originator takes the completed PORF to his or her department
manager for approval.
5. The originator sends the completed PORF to the IT administrator in the CS
Infrastructure Services Unit together with any quotations they have
obtained and any Change Proposals they have raised.
3.12.3.2 Processing an order
To process an order after the originator has completed the PORF:
1. The IT administrator checks the PORF and decides whether the order is a
standard, blanket, or call off order. See Purchasing Goods and Services
(PA/PRO/020) for more details. He or she then assigns a reference number
to the order.
2. The IT administrator checks that the correct cost centre code has been used
and obtains authorisation of the completed PORF from the manager of the
CS Infrastructure Services Unit.
If an order is rejected, the IT administrator informs the originator of the
reason for the rejection
3. The IT administrator enters the order details on to the Oracle Database and
passes the PORF to the Accounts Department for the purchase order to be
raised. The Accounts Department creates the purchase order, adding
supplier account codes and giving the purchase order a unique number.
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 72 of 92
ICL Pathway Ltd
FUJ00079875
FUJ00079875
Operations Manual for Customer Service Directorate Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
The Accounts Department returns a hard copy of the purchase order to the
CS IT department within 24 hours of receiving the PORF.
The IT administrator attaches a copy of the purchase order to the rest of
the order information and enters the details of the order onto a spreadsheet
for reference purposes, such as monthly analysis.
The IT administrator faxes the purchase order to the supplier together with
an order Acknowledgement Form.
The supplier faxes the Acknowledgement Form back to ICL Pathway to
acknowledge receipt of the order and advise ICL Pathway of the expected
delivery date.
The IT administrator emails the originator with the expected delivery date
so that the originator can arrange to accept the delivery when it arrives
3.12.3.3 Receiving the delivery
To receive the delivery:
1.
When the goods are delivered to ICL Pathway, the IT administrator is
contacted and informs the originators asking them to collect and sign for
the goods.
Note: CS Infrastructure Services do not store deliveries. Once they have
advised the originator of a delivery, the originator must make
arrangements to collect the goods.
If the goods are delivered off-site, the supplier sends a copy of the delivery
note to the CS IT administrator. An appropriate person on-site checks and
signs for the goods and informs the CS IT administrator of any problems.
The IT administrator files a copy of the delivery note with the rest of the
order documentation.
The supplier sends the invoice directly to the ICL Pathway Accounts
Department. The Accounts Department checks the invoice against the
original purchase order. When they are satisfied that the invoice matches
the purchase order, they send the invoice to the originator.
The originator checks the invoice against the delivered goods to confirm
that they also match and, if so, returns the invoice to the Accounts
Department for payment.
3.13 Security Management
3.13.1 Overview
The purpose of the CS Security Unit is to protect ICL Pathway’s investment in IT
assets, and to ensure the confidentiality, integrity and availability of all information
conveyed, processed or stored, by the services it provides. It supports ICL Pathway in
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 73 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd Operations Manual for Customer Service Directorate Ref: CS/QMS/007
Version: = 1.0
Commercial in Confidence Date: 26/11/01
all operational security matters to maintain ICL Pathway’s legal and contractual
obligations.
The function of the Unit is organised in three work categories as shown in the
following diagram. Diagram has been removed.
CS Security Unit
Policy Compliance and I Security
Vulnerability Operation I
3.13.2 Policy Compliance and Vulnerability
This considers two main requirements, both of which are considered of equal
importance from a security perspective.
a) It is the policy of ICL Pathway Limited to protect its investment in IT
assets, and to ensure the confidentiality, integrity and availability of all
information conveyed, processed or stored, by its services. These are set
out in relevant security related sections of the Codified Agreement.
b) ICL Pathway must remain fully compliant with relevant UK legislation,
UK and European regulations and ICL Group IT Security policies and
continue to meet the security obligation placed on it under contract. It is
therefore essential to track and anticipate emerging UK and European
regulations that could affect ICL Pathway’s operation and ensure that an
ongoing programme of compliance and audit review is maintained in order
to respond appropriately to any changes in risk.
Activities in this area are supported by compliance with and maintenance
of, various security-related CCDs, policies and security audit reports.
3.13.3. Security Operations
This comprises those activities that support day to day operational security
requirements. These are discrete activities that are carried out in order for ICL
Pathway to meet its specific security functional activities under contract.
Activities in these areas are supported by specific process / procedural
documentation and manuals.
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 74 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd —_ Operations Manual for Customer Service Directorate —_ Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
3.13.4. Administration and Organisation
This comprises those activities that support the way in which the Security Unit
conducts its work and how it interfaces with other parts of ICL Pathway, the
Customer and other 3“ party contacts and suppliers.
The Unit’s structure consists of the Pathway Security Manager (PSM) with direct
reports consisting of Security Functional Managers and Security Analysts. The
PSM reports directly to the Director of Customer Service.
3.13.5 Policy Compliance and Vulnerability
3.13.5.1 Security Policy
3.13.5.1.1 Primary Security Policy
Primary security policy is embodied in the ICL Pathway Security Policy
(RS/POL/002). This document is consistent with the requirements of the ISO
Code of Practice for Information Security Standards (ISO17799) and draws its
authority from Schedule AO2 of the Codified Agreement. RS/POL/002 is a CCD
and is included in the CCD list (SUP/CON/001).
The Security Policy is applicable throughout ICL Pathway and identifies specific
roles and responsibilities for Security within the organisation. It is subdivided into
high-level policy statements that are commensurate with the key controls of
1SO17799 and in line with ICL Group IT Security Policy.
Specific security enforcing policy is contained in the Security Functional
Specification (RS/FSP/001). This document is also a CCD and is supported by
various security-related Contract Referenced Documents — most notably the
Pathway Access Control Policy (RS/POL/003).
Other relevant policies include Customer initiated and owned security
documentation with which ICL Pathway must comply but which POL is
responsible for maintaining. The Unit’s primary interface with the Customer is via
the POL IT Security Conformance Manager.
3.13.5.2 Maintain extant policy.
All policy has to be maintained in order to comply with legal, contractual and
best-practice obligations. The activities necessary to support this requirement are
reflected in the annual CS Security activity plan and the security policy
documentation. It is also mandated by other ICL Pathway Programme Office
documentation.
3.13.6 Document Management.
CS Security maintains its documentation set and undertakes reviews in accordance
with Programme Office / Document Management guidelines (PA/PRO/010) and
via the use of the Programmes PVCS facility (CM/MAN/003).
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 75 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd —_ Operations Manual for Customer Service Directorate —_ Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
The primary documentation set is N_A_CS_SECURITY_%. Some relevant
documentation is also contained in the documentation set maintained by the ICL
Pathway Audit Manager.
The ICL Pathway Security Manager is responsible for ensuring compliance with
Programme Office procedures and may delegate responsibility for document
maintenance to the Analyst responsible for the specific area of work in question.
Relevant procedural security documentation is also available on the Business
Management System (BMS) website.
3.13.7 18017799 and Group IT Security Policy.
3.13.7.1 Overview
1SO17799 is the British Standard for Information Security Management. It
provides a proven, internationally recognised best-practice framework upon which
to maintain information security within ICL Pathway and has been adopted by
ICL Group Security (GISI) as part of the Group IT Security Policy (CPM21) and
overarching Group Security Policy (CPM20). Compliance with the Standard is
also reflected within the Codified Agreement. .
ISO17799 facilitates development and maintenance of an Information Security
Management System (ISMS) through:
e A Security Policy;
e An assessment of security threats, vulnerabilities and risks;
e An ongoing programme of compliance.
3.13.7.2 Application within ICL Pathway
1SO17799 guidelines are reflected for the ICL Pathway environment in
RS/PRO/028, which is available to all staff.
It has been identified that whilst this document provides an accurate reflection of
the requirements of ISO17799, it does not provide the most appropriate way of
communicating these throughout the organisation or for placing the operational
responsibility for ensuring specific compliance with staff Line Managers.
A project has therefore been initiated to implement a revised plan for maintaining
ISO17799 compliance within the organisation.
3.13.8 Legislation
ICL Pathway is required under Law and within the requirements of contract to
comply with all applicable legislation. Apart from compliance with Common
Law, ICL Pathway has specific obligations is respect of the Data Protection,
Police and Criminal Evidence and Regulation of Investigatory Powers Acts.
CS Security maintain an interface with ICL Group Legal Services and with
Masons (The ICL Pathway Solicitors) to ensure that its input to legal issues and
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 76 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd —_ Operations Manual for Customer Service Directorate —_ Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
activities on behalf of ICL Pathway are commensurate with overarching ICL and
contractual obligations. It undertakes this directly or via the Director of
Commercial and Finance or ICL Pathway Commercial Manager.
CS Security also reviews emerging legislative issues by visiting various
Government and Legal web-sites. Its primary interface to the Customer is via the
POL Commercial Manager.
3.13.9 Data Protection Act (DPA)
The Data Protection Act 1998 came into force on the 24.10.01 and deals with the
necessary requirements to ensure that the confidentiality of personal information
is maintained. The Act is based on a number of Data Protection Principles and is
far-reaching in scope.
CS Security ensures that ICL Pathway and its operational systems are in line with
extant DPA legislation. It provides DPA input to existing and new projects as
required and assistance and information to the customer and other ICL Pathway
employees. The Unit considers the likely impacts of the updated legislation on
Horizon and works with the Customer and other interested parties to identify and
address areas of non-conformance within ICL Pathway and the Horizon system.
An important element is ensuring the appropriate level of awareness is introduced
and maintained amongst ICL Pathway staff. This is achieved via various
workshops, seminars and leaflets.
3.13.10 Police and Criminal Evidence Act (PACE)
Compliance with the relevant sections of PACE is relevant in connection with the
investigation support that ICL Pathway provides to POL. This is primarily in
respect of the prosecution of Post Office counter staff who abuse POL rules for
the management of the Horizon system and of benefit claimants who seek to
defraud the OBCS system that is operated via the Horizon Infrastructure. POL
maintains interfaces with relevant investigation staff in the Department for Work
and Pensions.
The Unit’s interface with the Customer is via the Consignia Group Internal Crime
Manager.
3.13.11 Regulation of Investigatory Powers Act (RIPA)
RIPA provides regulatory controls for the investigation of suspected criminal
activity. It is relevant in connection with the detection and prosecution of
individuals by POL and in the production of data related evidence from the
Horizon system.
The Unit’s interface with the Customer is via the Consignia Group Internal Crime
Manager.
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 77 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd —_ Operations Manual for Customer Service Directorate —_ Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
3.13.12
3.13.12.1
3.13.12.2
3.13.13
3.13.14
3.13.15
Penetration Testing
Scope
ICL Pathway is contractually obliged to provide and maintain a secure system that
protects the confidentiality, availability and integrity of the data it processes and
stores.
Periodically ICL Pathway is required to demonstrate that the Horizon system has
adequate protection mechanisms to obviate the possibility of a successful attack
by hacking or denial of service activities. In these instances the ICL PSM will
enlist the help of a reputable external company to undertake penetration tests of
the Horizon infrastructure and produce a report detailing recommendations for
improving security controls.
Testing
Testing is sensitive and is generally undertaken on a test environment that
replicates the live service. The Security Manager works closely with consultants
from the chosen Company and, where appropriate the Customer, to produce
detailed testing scripts. Testing requires support from various Development and
Testing units within ICL Pathway.
Supplier/Product Testing & Assurance
CS Security undertakes periodic risk assessments and reports on 3% Party
suppliers of products and services to the Horizon system. This provides assurance
that the security requirements placed upon ICL Pathway under contract are
adequately reflected in the supplied services.
Inputs include service and product specifications. Outputs include security
assessment reports and recommendations for the ICL Pathway Board and/or
Contract Managers
Compliance Projects
Periodically a number of reviews are undertaken by CS Security on a project
management basis to ensure compliance with high-level legal, policy or
contractual obligations. These may be instigated as a result of changes in
legislation, ICL Group policy or the contract with the Customer. Resource is
sourced from within the Unit but may require the use of outside consultants. The
implementation of any recommendations is generally effected via CP.
Two such projects are related to IS017799 compliance and DPA compliance.
1SO17799 Compliance
A current review is underway to ensure that ISO17799 guidelines are adequately
reflected and enforced within the ICL Pathway environment.
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 78 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd —_ Operations Manual for Customer Service Directorate —_ Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
It has been identified that whilst this document provides an accurate reflection of
the requirements of ISO17799, it does not provide the most appropriate way of
communicating these throughout the organisation or for placing the operational
responsibility for ensuring specific compliance with staff Line Managers.
A project has therefore been initiated to implement a revised plan for maintaining
1SO17799 compliance within the organisation. Work has started on preparing the
information security control grid that will facilitate self-assessment schedules for
ISO17790 compliance. The objective of this exercise is to identify and produce a
gap analysis to record all non-compliance throughout the various Pathway
divisions. Implementation of a corrective action programme will then be
progressed across the Pathway organisation through the ISO17799 Workshop
Group as part of ISO9001 accreditation work.
CS Security and Pathway Internal Audit are working together on a tool to measure
ICL Pathways compliance to ISO17799.
3.13.16 DPA Compliance
The Data Protection Act 1998 came into force on the 24.10.01. The new Act has
widespread impact across ICL Pathway and the advent of Network Banking
brings with it additional responsibilities for the protection of personal information.
CS Security are undertaking a review to ensure that the legal and contractual basis
upon which ICL Pathway records, processes and stores personal information on
behalf of POL and its Agents is fully agreed and reflected in the Codified
Agreement.
The Unit will consider the likely impact of the updated legislation on Horizon and
progress compliance in conjunction with interested parties. Compliance with the
DPA will be achieved through a combination of input to relevant processes and
procedures and awareness programmes.
3.13.17 Security Audits
CS Security undertakes a number of audits in accordance with Security Policy and
the CS Security annual activity plan. The audits are designed to ensure ongoing
compliance with security policy and operational processes and are often
undertaken in conjunction with Pathway Internal Audit.
The Security manager is responsible for undertaking these audits and may
designate or co-opt other ICL Pathway resources as required.
Target areas for the audits are determined by various factors including associated
recommendations from other Pathway Compliance Units, reported security events,
requests from the respective Business Unit Managers or as a result of changes in
the actual or perceived threats to ICL Pathway assets. Security Audits general
involve a site visit and review of relevant physical, IT, personnel and documentary
processes and procedures. They require close liaison with designated staff in the
target business unit and the undertaking of various interviews with relevant staff.
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 79 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd —_ Operations Manual for Customer Service Directorate —_ Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
The scope of the audits varies according to circumstances but the requirements of
1SO17799 and legal/contractual obligations are generally used to form an opinion
of compliance.
The output is a report with recommendations where appropriate. Corrective
actions are documented in a Corrective Action Plan (CAP) which are monitored
until completed by the actionee.
3.13.18 Security Awareness
CS Security has an obligation under contract to provide a programme of ongoing
security awareness for both ICL Pathway and POL/POL staff. This is designed to
reinforce general security messages consistent with the requirements of ISO17799
and also to target areas where non-compliance has been reported.
Maintenance of the security awareness programme is the responsibility of a
designated security analyst within CS Security. There is an equal responsibility
placed on line managers within the various Business Units to ensure that security
awareness is fostered in the day-to-day working environment.
3.13.18.1 Awareness Programme for Pathway
It is essential that all staff working for ICL Pathway receive appropriate security
awareness at the earliest opportunity. New recruits to ICL Pathway receive a
security handout and briefing as part of their induction training.
Security awareness is an ongoing activity and has to be reinforced periodically
with advice and guidance. This is normally based on a theme and supported by the
requirements of ISO17799. The awareness programme documented in
RS/MAN/001 is updated periodically to reflect changes in the prevailing threats.
The Business Management System is used as a mechanism to provide links to
associated security documents in an easily searchable, intuitive manner.
3.13.18.2 Awareness for Post Office
Post Office personnel are informed and advised of appropriate best security
practices, based on ISOI7799 by newsletter articles. It is important that the format,
style and content are relevant, pragmatic and understandable and the appropriate
training vehicle is discussed with POL.
Examples are used wherever possible to highlight potential issues and solutions
proposed in a pragmatic and appropriate way.
3.13.19 Change Control
3.13.19.1 OCP Authorisation
All operational change potentially affecting the security of the live estate requires
appropriate authorisation by the PSM or designated deputy. This includes changes
to security enforcing components or code such as firewall rulebases.
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 80 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd —_ Operations Manual for Customer Service Directorate —_ Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
CS Security input to the Operational Change Process used within both CS and
ISD Operations to manage and authorise OCPs. The “CSPathwayCP” mailbox
sends OCPs to the Security Manager and Deputy who consider whether the
change is commensurate with extant security policy and procedures and then
authorise or reject the proposal.
Contingency arrangements are in place with Security ASD in the event that the
PSM or deputy is unavailable.
3.13.19.2 CSCP Review
CS Security manages formal Change Proposals via the CSCP Review Process.
The security impact of all CPs is considered by the PSM and resultant impacts are
fed back to the “CSPathwayCP” mailbox for action. The Unit also complies with
the Pathway “Change Order” process.
The Unit is also responsible for raising CPs relating to security changes and
support these throughout the change life cycle.
3.13.19.3 CP Review
CS Security inputs as appropriate to PCCB/CCB deliberations on various CPs that
have a security impact.
3.13.20 Problem Management
3.13.20.1 PinICL Support
The Unit has access to the PinICL system and has four security-related “stacks” in
respect of both security policy and operational security issues.
3.13.20.2 CS Problem Process
CS Security provides input as appropriate to the CS Problem Management
Database and provides regular updates on problem resolution.
3.13.21 Business Risk Assessment
CS Security provide ongoing daily support to security compliance by undertaking risk
assessments of operational processes and procedures used within ICL Pathway in
support of the Horizon system.
All operations and applications have a security element and the Unit receives requests
from Business Units throughout Pathway for security related advice. The Unit
facilitates problem resolution by undertaking discrete assessments to establish the
threats, vulnerabilities and risks associated with emerging issues and uses these to
balance security requirements against the need for operational expedience.
This requires a full understanding of both legal and contractual liabilities. Relevant
staff in all Pathway Business Units are consulted as required.
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 81 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd —_ Operations Manual for Customer Service Directorate —_ Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
3.13.22 Security Operations
3.13.22.1 Security Event Management (SEM)
3.13.22.1.1. SEM System
The Tivoli SEM system is used primarily by CS Security to track and report
events of security significance. The Unit has access to a SEM workstation to
which related events are forwarded for monitoring and analysis. A designated
Analyst within CS Security is responsible for the daily monitoring of the system.
Effective Security Event Management relies partly on identifying new features
and vulnerabilities introduced by new systems. Operating system and applications
are reviewed accordingly to optimise security configurations and minimise
security weaknesses. Tivoli Event Filters are configured and updated where
appropriate to trap security related event messages according to their severity.
Events may be recorded and forwarded purely for reassurance that processes are
working properly or conversely to alert CS Security to inappropriate activity for
investigation. Virus incidents are one such type of alert.
3.13.22.1.2 Security Incidents & Investigations
Incidents can be categorised as potential and actual. They vary according to
severity and how many systems are affected. Initial analysis will determine the
type of incident, scope and frequency. All incidents are logged and details
recorded for trend analysis and to facilitate a controlled, co-ordinated and timely
response. A disciplined approach is required to ensure that accurate facts are
promptly obtained and reviewed.
Maintaining the integrity and confidentiality and availability of associated data
and information is critical. Evidence may be required for prosecution and/or for
company disciplinary procedures.
3.13.22.1.3. Event Analysis & Reporting
Trend analysis is used to help identify procedural or technical weaknesses and
inform corrective actions.
Outputs from analyses are used specifically to ensure that excessive system access
is minimised and all users operate systems according to the rule of least privilege.
As the understanding of existing systems improves, enhancements to security can
be carefully assessed. Reports are referred to the PSM for action.
3.13.23, Key Management
The Horizon system is required to provide a secure centrally managed facility that
gives end-to-end protection to Post Office business streams. The Horizon system
and its associated business systems use cryptography extensively to protect the
integrity and confidentiality of business data.
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 82 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd —_ Operations Manual for Customer Service Directorate —_ Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
Key management encompasses the creation, distribution, protection, installation,
monitoring and periodic replacement of cryptographic material. Cryptographic
material may be either manually or automatically managed within Pathway:
Manual cryptographic keys are the responsibility of the Security Manager who is
the designated Crypto custodian for Pathway;
Automated cryptographic keys are managed by the Key Management System
(KMS) under the control of the Key Manager.
3.13.23.1 Manual Key Management.
Most cryptographic keys are managed automatically by KMS. Some however are
generated in a secure offline environment, supplied on a floppy disk and then
installed manually on the appropriate platform.
Primary key inputs are provided internally via the Managed Key Service (part of
IPDU Cryptography) or regularly by CESG. The latter undertakes regular audit
reviews of arrangements for the physical protection of key material.
The CS Security Manager is the designated Cryptographic Key Custodian for ICL
Pathway and utilises a small group of designated Key Custodians and Key
Handlers in both ISD and POL to operate the manual key management service.
Primary responsibilities are to:
e manage the manual cryptographic estate
¢ oversee the secure production of manual keys
¢ monitor manual key expiry and instigate renewal
e control keys for central servers and existing FTMS applications
e receive, register and log use of specified manual cryptographic keys
e manage enforced key changes that are outside KMS control and ensure a
smooth transition as required
e investigate provision of the existing manual key processes within KMS
3.13.23.2 Process and Procedures
Procedures for cryptographic keys are carefully controlled and documented.
Monthly audits of existing key holdings are undertaken and actual or potential
breaches are reported immediately to the Director of CS and the subject of
immediate investigation.
All cryptographic key activities are undertaken in a secure operating
environment to minimise potential for compromise whilst handling removable
media.
3.13.23.3 KMS Key Management
The KMS automates many key management processes and, from a central point
of control, shields the Pathway business services from the complexities of key
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 83 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd —_ Operations Manual for Customer Service Directorate —_ Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
administration. KMS was developed by ICL Pathway to meet contractual
obligations to the Post Office. Its main features are:
e Centralised control and automated key management;
e Secure delivery of cryptographic material across the live Pathway estate;
e Support for Pathway’s operational cryptographic needs.
The CS Security Key Manager administers the Key Management System. All
activities conducted through the Key Management platforms are in accordance
with the KMS User Guide, RS/MAN/006. The main functions of the role are to:
¢ create, certify and distribute the keys installed at the Post Office and campus
platforms to meet planned migration/rollout/re-roll dates
© monitor the status of key material proactively and on request
e undertake forced key changes as necessary
e investigate outstanding deliveries, in particular delays to routine key changes
e conduct additional CA Public Key (CAPU) validity checks as necessary
e produce management status reports on request
e administer Key Management system data changes
e check the Key Management task list daily for new actions
e record and resolve problems in conjunction with first, second, third and fourth
line support
e maintain the KMS User Guide and update as appropriate for planned new
developments
3.13.23.3.1 Functional Changes.
The Key Manager maintains contact with other Pathway Units and keeps
informed about proposed KMS functionality and other changes that affect the
provision of KMS. To this end the Key Manager responsibilities are to:
e keep up to date with Pathway developments such as Network Banking,
Your Guide and EFTPOS
e review existing and emerging documents for the proposed introduction of
new cryptographic features
¢ keep abreast of KMS developments and issues so as to provide timely
advice to management of any KMS functionality impacts
e be aware of KMS System test results and any impact these might have on
programme delivery timescales
© provide KMS assistance towards the smooth transition to OCMS.
3.13.23.3.2. KMS Event Logging
The KMS is concerned with two main types of event, Tivoli events and KMA
events. Tivoli events are reports of incidents detected by applications running
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 84 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd —_ Operations Manual for Customer Service Directorate —_ Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
on the operational systems; KMA events are used to trigger cryptographic
activities such as distributing keys to an outlet.
The Key Manager is responsible for periodic checking and investigation of
any failures relating to the following automated KMA events and for re-
scheduling them to run again if necessary:
e Preparing and creating client keys for installation prior to Post Office
outlet rollout.
e Activating and distributing keys to a client.
e Permanent or temporary closure of a Post Office outlet.
e Re-opening of a Post Office outlet.
The KMS Auditor is involved in the investigation of Tivoli events. Tivoli
systems management provides the primary means of managing the Pathway
systems. When an application detects a security problem the local platform
logs an event which Tivoli harvests. Security events are separated out and
forwarded to the Pathway Security Analyst acting in the KMS Auditor role.
In addition, the Key Manager and KMS Auditor perform the following
activities:
e Responding to events forwarded by the SMC
e Examining the Application and System event logs on request.
3.13.23.3.3 Security Controls
The KMS system is operated in a secure environment to:
e ensure the integrity of all keys on all relevant platforms
e interpret audit trail and task-generated output - noting, escalating and
responding to security breaches as appropriate
© protect removable media
© oversee any hardware or software changes to the CAW or Key Manager
Workstations as arranged
e avoid disclosure or loss of any assigned tokens, passwords and safe
combinations
3.13.24 Audit Data Extractions
This section describes an overview of the activities and control used for the
extraction of audit data from the audit servers. This information may be requested
by POL Investigation/Audit personnel to support their regulatory activities or by
ICL Pathway for problem management purposes.
3.13.24.1 Data Extractions for POL
Data extractions for POL are requested by the Consignia Group Internal Crime
Manager via a Request for Information (RFI) form. The form details the outlet
FAD code and date range for which the data is required and the relevant priority
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 85 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd —_ Operations Manual for Customer Service Directorate —_ Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
of the request. A designated analyst in CS Security uses the ICL Pathway Legato
GUI to provide an audit trail of all work carried out on the Audit Servers and to
identify which files are needed to fulfil the relevant RFI. Tivoli is used to identify
the appropriate cluster number, which is then used to check the results from the
GUI. An OCP is raised to enable ISD Network staff based at the datacentres to
identify and load the required tapes. Once all the files have been restored, they are
seal checked and a message store is generated. The requested set of information is
then extracted with the use of Riposte Query and burnt to closed CD
3.13.24.2 Service Delivery Review
CS Security carries out data extractions in respect of 50 RFIs per year with a
maximum burst rate of 7 per calendar month. This non-formal agreement with
POL is subject to contractual agreement. Future service levels are the subject of an
impending CR. There is no specified time frame in which to complete RFI’s and
priorities are agreed on an ad-hoc basis.
3.13.24.3 Pathway Data Extractions
ICL Pathway SSC occasionally request audit data to help investigate Horizon
System Issues. These requests have a lower priority than all POL RFI’s and are
actioned as soon as possible. SSC request data extractions by raising a PinICL on
the CS Security “Data Extraction” stack.
3.13.24.4 CD Preparation & Despatch
All RFIs are burnt to ‘closed’ CD, to ensure the data can not be modified. The
CD is virus- checked with the latest anti-virus software. The data is provided in
both Excel 95 and 98 formats. Also included is a “Read me” word document
explaining what is contained on the CD, which virus scan engine and virus
definition were used to check the CD and who to contact in the event of a query.
CDs may contain sensitive information and are sent special delivery to the POL
requestor or delivered by hand to SSC.
3.13.25 Investigation Support
ICL Pathway has no current contractual obligation to provide prosecution support
to POL. CS Security currently provide this support on a “without prejudice” basis
pending contractual agreement.
3.13.25.1 Collation of Evidence
Evidence in support of POL internal investigations and in support of POL’s
obligations to the Department for Work and Pensions is collated from a number of
different sources. Transaction data is gathered from the Audit Server. Data in
support of system integrity is sourced from the HSH (Powerhelp calls), MSU
(non-polling) and PinICLs. The latter provides evidence to support the attestation
that the outlet under investigation was operational during the period in question.
CS Security has direct access to the HSH Website.
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 86 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd —_ Operations Manual for Customer Service Directorate —_ Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
3.13.25.2 Preparation of Witness Statements
CS Security currently provides three types of witness statements:
e An overview of the Horizon system and its associated integrity controls;
e An overview of the Horizon system and its associated integrity controls
together with a statement in support of an evidential CD containing data
produced in response to an RFI.
e An overview of the Horizon system and its associated integrity controls
together with a statement in support of an evidential CD containing data
produced in response to an RFI and an explanation of the Order Book Control
System.
3.13.25.3 Legal Requirements
In order to provide admissible evidence CS Security ensures it keeps up to date
with emerging or changing legislation. This information is sourced via appropriate
web-sites or via the Consignia Group Internal Crime Manager as part of the
regular Joint Audit and Security Liaison Meetings
3.13.25.4 Court Attendance
CS Security provides witnesses to attend Court if required to support statements.
Whilst ICL Pathway has no contractual obligation to do this it does so to avoid
formal subpoena.
CS Security personnel provide statements of fact. They are not expert witnesses.
Where expert witness testimony is required other members of ICL Pathway or
ISD Operations may be required.
3.13.26 Virus Management.
3.13.26.1 Anti-Virus Measures
Maintaining updated Anti-Virus protection on the Live Estate and reporting
potentially infected files preserves the integrity and availability of the data
throughout the Horizon System. Automatic notification and prompt virus incident
response is included in CS/PRD/101 and RS/PRO/043, currently being
incremented for final review and formal baseline.
CS Security manages the implementation of virus checking software on the live
Horizon estate. This involves the initial distribution and ongoing updates of anti-
virus software onto selected workstations and servers within the Pathway Live
Estate.
3.13.26.2 Software Delivery Processes
Initial delivery is via Tivoli MANLCF and regular monthly updates of the latest
anti-virus definition files utilises a procedure created specifically for delivery of
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 87 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd Operations Manual for Customer Service Directorate Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
Common Objects. This procedure requires only one release note to enable the PIT
team to produce a Fast Track baseline, thus eliminating the need for using Work
Packages. Full details are contained in the project [VCS PID (DE/PRD/002) and
details of the delivery procedure are contained in PA/PRO/045.
3.13.26.3 Event Reporting & Analysis
Virus event reporting is via both manual and automatic notification. These are
outlined in RS/PRO/043.
Manual alerts rely upon the raising of a call, via the HSH Helpdesk, by users of
workstations that receive a virus warning. ISD Operations monitor event logs on
servers and also raise a Helpdesk call.
Automated alerts capture relevant NT events and forward them in real time via
Tivoli to both SMC and CS Security. CS Security analyse details to understand
the threat and to inform corrective actions. Where appropriate the software
Vendor is contacted for advice and guidance.
3.13.26.4 Review of Virus Threats
CS Security undertakes daily checks of emerging viruses and other malware via
automatic e-mail notification from various Vendors and via the Web. Notification
is also received from ICL Group. These are used to inform threats and determine
the required defensive measures.
3.13.26.5 Horizon Pass Management
(CS Security provide contingency for this activity)
All Pathway staff and Engineers needing access to Post office outlets require a
Horizon Security Identity Pass. This pass provides authorised persons with
suitable identification that can be verified by Post Office Managers via a call to
the Post Office Regional Help line.
The associated procedure is co-ordinated by Pathway in conjunction with POL
and ICL Group Security. The requester completes the necessary forms and the
application is vetted by POL. Once approved ICL Group Security issue the pass to
CS Security, which forwards to the appropriate individual.
Management also involves replacement, temporary, invalidated and cancelled
passes and details are provided twice a week to POL.
3.13.26.6 Horizon Passes Audit
An audit of all Horizon Security Passes is performed every 6 months to ensure
that CS Security has captured, invalidated and destroyed all Horizon Security
Passes belonging to ex-employees and contractors of ICL Pathway.
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 88 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd —_ Operations Manual for Customer Service Directorate —_ Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
3.13.27. Live System Access
3.13.27.1 Live Access Authorisation
Security policy mandates that all users requiring access to the live system have to
be approved by CS Security. This is a fundamental security access control
requirement.
The procedure involves the completion of an application form, which is authorised
by the individual’s Business Unit Manager. This is forwarded to CS Security who
validates the request and sends to ISD Operations via the ISD mailbox for
activation on the system.
3.13.27.2 Token Administration
Security policy mandates that all users who access the live system from locations
remote from the datacentres do so via secondary token authentication. ICL
Pathway uses SecurID tokens for this purpose. Tokens provide additional
assurance as to the identity of users.
Tokens are managed by a designated member of CS Security who maintains a
record of receipt, allocation and destruction and undertakes a quarterly review to
ensure the cancellation of tokens that are no longer required. The associated
activation of Tokens on the system is undertaken by ISD Operations.
Tokens are supplied by RSA Security and administered by Aslan.
3.13.28 Fraud/Security Countermeasures and Investigations
3.13.28.1 Countermeasures
CS Security keeps up to date with developments in Fraud and Security
countermeasures and uses this to inform risk assessments. The Section subscribes
to various publications and journals and maintains informal contact with like-
minded groups via e-mail and the Web.
3.13.28.2 Internal Investigations
3.13.29
The Unit undertakes internal investigations into alleged or suspected abuse of
assets by ICL Pathway personnel. Investigations are undertaken in conjunction
with HR, the Director of CS and other senior managers.
Security Administration
3.13.29.1 Security Board
The ICL Pathway Security Board owns ICL Pathway’s Security Strategy and
determines the adequacy of security policy. The Security Board includes
representatives that are nominated by the Director, Customer Service and
participants including Horizon Security Liaison staff, represent a broad range of
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 89 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd —_ Operations Manual for Customer Service Directorate —_ Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
interests to ensure that alternative perspectives are considered. Whenever
necessary, the Security Board can commission independent specialists to
undertake studies, investigations or audits.
The Security Board meets as required.
3.13.29.2 S4 Forum
The S4 Forum is a group that includes representatives from security-related roles
within ICL Pathway. These include CS Security and ASD Security personnel.
This informal group meets generally on a fortnightly basis to discuss matters of
general security interest and potential future impact.
3.13.29.3 Joint Audit / Investigation Meetings
The PSM attends the Joint Audit / Investigation meetings that are arranged on a
quarterly basis by the ICL Pathway Audit Manager. Participants include the
Consignia Group Audit Manager and Internal Crime Manager.
The remit of the Group is to discuss and resolve any issues relating to audit and
the provision of audit data in support of investigations.
3.13.29.4 GISI Liaison
The Unit maintains contact with ICL Group Security to ensure that Group IT
Security Policy is adequately enforced throughout ICL Pathway.
3.13.29.5 Event Management Forum
CS Security is represented on the Event Management Forum, which is organised
by the SMC. This meets monthly and discusses incidents of recurring high-
volume system events with a view to ensuring that KELs are accurately
maintained and event filtering is optimised.
3.13.29.6 Customer Care Visits
The PSM undertakes Customer Care Visits in accordance with the agreed CS
programme.
3.14 Management Accounting
The CS Management Accountant follows the ICL Pathway processes to establish and
maintain the operating forecast for Customer Service. These processes are defined in
the Processes: Planning and Reporting (PM/PRO/001)
The Management Accountant follows the Month-end forecast procedure
(CS/PRO/106) to update the previous month’s forecast with the following elements:
e The ICL Pathway Project Plan
e¢ New Change Proposals (CPs), with CS costs
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 90 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd —_ Operations Manual for Customer Service Directorate —_ Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
e Update from other parts of ICL forecasts, that is, from Infrastructure Services
Division (ISD)
e Actual figures of costs for the month from the Oracle Financials system
e Forecasts from CS Service unit managers, with advice from the management
accountant.
¢ Forecasts from the CS Director
e Head Count (number of staff) from Human Resources
Once the forecast has been reviewed by the ICL Pathway Directors, the final
operating forecast for the month is given to the CS Director, the CS Direct
Reports and ICL Pathway Finance.
Actual costs in Oracle Financials are made up from invoices and financial adjusting
journals made by the CS Management Accountant and ICL Pathway accountants.
The invoices are checked as described in Local Procedure when Receiving Invoices
for Authorising (CS/PRO/103).
When raising a purchase order, in preparation for an invoice, staff are referred to
Local Procedure when Raising a Purchase Order (CS/PRO/105).
3.15 Management Planning
CS Planning produces three different types of plans, namely:
Major Release Management Plan
e CS time recording plans for "Business as Usual" and chargeable activities
e Release specific Level 4 plans
3.15.1 Major Release Management Plan
The CS Major Release Management Plan is an informational document used to
draw together various levels of plan from several sources to present all the
information in a single document. It contains data from:
The Programme Level 1, 2 & 3 plans
CS Level 4 Release Introduction plans
ISD Scheduled activities document
CS Business Continuity plans.
The Major Release Management Plan is updated with information from these
sources at least monthly and distributed to each CS Manager & Service Manager.
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 91 of 92
FUJ00079875
FUJ00079875
ICL Pathway Ltd —_ Operations Manual for Customer Service Directorate —_ Ref: CS/QMS/007
Version: 1.0
Commercial in Confidence Date: 26/11/01
3.15.2 CS Time Recording Plans
Two time recording plans exist within Customer Service; one covers those
activities deemed as ‘Business as Usual’ for which no time and materials charges
are made, the second covers those activities resulting from additional business
which is charged to the customer on a time & materials basis.
The Business as Usual plan is fairly static and requires little change except for
occasional organisational moves. The RTR Administrator in Feltham processes
the change requests to this plan.
The additional business plan, known as the CS CCN plan, is more dynamic, with
new business activities being approved every week. Each new business activity,
for which CS have to undertake work, is added to the plan once it is authorised for
work to commence. Resources and timescales are added as listed in the approved
change document. A weekly interchange between the CS CCN plan and the RTR
Time-Recording system keeps the plan up to date with time booked to each
chargeable activity.
3.15.3 CS Release Specific Level 4 Plans
Level 4 plans are produced for every major activity involving work on the Live
Horizon System. These plans are at detailed timed activity level. A major upgrade
may consist of over a thousand such detailed activities and to get to this level of
detail involves many hours of preparatory meetings starting several weeks before
the main event. The major dates are taken from the Programme Level plans but
there is feedback from the level 4 plans up to the Programme Level plans to
ensure that changes resulting from the detailed planning
© 2001 ICL Pathway Ltd Commercial in Confidence Page: 92 of 92