POL00000900
POL00000900
ICL Pathway CS Support Services Operations Manual Ref: CS/QMS/004
Version: 2.0
COMMERCIAL IN CONFIDENCE Date: 29/01/01
Document title:
Document type:
Release:
Abstract:
Document
status:
Owner:
Author & Dept:
Contributors:
Reviewed by:
Comments by:
Comments to:
Distribution:
CS Support Services Operations Manual
Operations Manual
N/A
This is the top-level procedures document describing
the activities carried out by the Support Services
Unit within ICL Pathway Customer Service
APPROVED
Peter Burden
Richard Burton, A&TC, Technical Authors
Peter Burden
Peter Burden
Customer Service Director
CS Operations Services Manager
CS Support Services Manager
CS Infrastructure Services Manager
Pathway document library
SSC Manager
OTT Manager
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 1 of 67
POL-0061572_Fi87/11
ICL Pathway
POL00000900
POL00000900
CS Support Services Operations Manual Ref: CS/QMS/004
Version: 2.0
COMMERCIAL IN CONFIDENCE Date: 29/01/01
0.0 Document Control
0.1 Document History
Any hardcopy of this document
CONTROL unless otherwise stated.
is NOT UNDER CHANGE
0.1 25/9/00 First draft for internal CS review
0.2 17/10/00 I Draft for comment within Support
Services
0.3 03/11/00 I Updated in line with comments
from within Support Services
1.0 07/11/00 I Approved version
2.0 29/01/01 I Updated to reflect changes
required after business continuity
walk-through
0.2 Approval Authorities
Peter Burden
Support Services
Manager
0.3 Associated Documents
The version numbers and dates the following table shows are those that
were current when this document was written. If you wish to look at one
of these referenced documents, search for the document in the Pathway
Document Library (PVCS) and refer to the latest version.
CS/QMS/001 1.0 CS Policy Manual ICL
Pathway
cs
CS/QMS/002 1.0 CS Process Manual ICL
Pathway
cs
CS/QMS/005 2.0 CS Operations Services I ICL
Operations Manual Pathway
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 2 of 67
POL-0061572 F/s87/2
ICL Pathway
CS Support Services Operations Manual Ref:
Version:
COMMERCIAL IN CONFIDENCE Date:
POL00000900
POL00000900
CS/QMS/004
2.0
29/01/01
cs
CS/QMS/006 1.0 8/11/00 I CS Infrastructure ICL
Services Operations Pathway
Manual cs
CS/PRD/074 1.0 ICL Pathway CS ICL
Incident Management Pathway
Process cs
CS/FSP/006 1.0 10/10/9 I End-to-End Support ICL
9 Process Operational Pathway
Level Agreement cs
CS/PRD/021 3.0 ICL Pathway Problem ICL
Management Process Pathway
Definition cs
CS/PRO/100 4.0 Routing of Software ICL
Code Fixes Pathway
cs
CS/PRO/102 3.0 Daily and Weekly ICL
Procedures for the Pathway
Release Management cs
team
0.4 Abbreviations/Definitions
BRT Business Recovery Team
CMT Crisis Management Team
cs Customer Service
CSRM Customer Service Release Manager
KEL Known Error Log
HSH Horizon System Helpdesk
OCR Operational Correction Request
OSD Operational Services Division (of ICL)
OTl Open Teleservice Interface
OTT Operational Test Team
RM Release Management
SSC System Support Centre
© 2001 ICL Pathway Limited
COMMERCIAL IN CONFIDENCE
Page: 3 of 67
POL-0061572 F/87/3
POL00000900
POL00000900
ICL Pathway CS Support Services Operations Manual Ref: CS/QMS/004
Version: 2.0
COMMERCIAL IN CONFIDENCE Date: 29/01/01
SMC System Management Centre
0.5 Changes in this Version
First draft for internal CS review
0.2 Minor updates prior to comment from within Support
Services
0.3 Minor updates, particularly in the OTT section
1.0 Approved version
2.0 To incorporate changes as a result of business continuity
walkthrough
0.6 Changes Expected
Change
Changes as a result of the annual review of this document
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 4 of 67
POL-0061572 F/87/4
POL00000900
POL00000900
ICL Pathway CS Support Services Operations Manual Ref: CS/QMS/004
Version: 2.0
COMMERCIAL IN CONFIDENCE Date: 29/01/01
0.7 Table of Contents
1
2
3
4 System Support Centre.
4.1 Overview
4.1.1 SSC responsibilities to first and second line support...... 8
4.1.2 SSC responsibilities to fourth line Support.............ceeeeee 9
4.2 Applications support
4.2.1 Role of first line support..
4.2.2 Role of second line support
4.2.3 Role of third line SUPPOFT......... ccc seeeeesseeeesseeseseeseeeteeees 11
4.2.4 Role of fourth line SUPPOFt.........:eeeceeesseteeeeeeeeeeeeeeeeneee 13
4.3 Operational change
4.4 SSC reference kit.
4.4.1 Overview.....
4.4.2 Updating the hardware asset register... eeeeeeeeees 16
4.5 Diagnostic information..........cccccecscceesesseeseeessereseeeseeeeeenees 17
4.5.1 Maintaining the Known Error Log on the SSC intranet
site 17
4.5.2 Transferring knowledge between support units............ 17
4.6 Diagnostic tools
4.6.1 Overview
4.6.2 Developing diagnostic tools..........ccecccsseesseseseeeereeeeeee 17
4.7 SSC intranet Site... ceeceesscceeeesesessesseneeseeseseeeesaeeseraeeee 18
4.7.1 Known Error Logs (KELS)........:::seseeesseeeseeeeseeeeeeeeeeeeenaee 18
4.7.2 Change proposals
4.7.3 Release management
4.7.4 Operational Change/Corrections.......ccccccccscesceeseerseeeeee 19
4.7.5 Work INStructiONnS.........c.ccccceessecesseceseeeenseteeseneeseeneeseenaae 19
4.7.6 Other facilities........cc cccecceceeecceeeeesssceeecseseeeseeseesneeeneeee 19
4.8 Access to the live system
4.9 Additional technical support to Pathway CS. .
5 Operational Test Team (OTT)........cccssscecesssseeeeesssssseseeeeeeereeeee
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 5 of 67
POL-0061572 F/87/5
POL00000900
POL00000900
ICL Pathway CS Support Services Operations Manual Ref: CS/QMS/004
Version: 2.0
COMMERCIAL IN CONFIDENCE Date: 29/01/01
5.1 Overview..
5.2 Scheduling testing
5.3 Controlling testing
5.4 Recording rig ProDleMs.........cssecesssseeeeeessteeeeeeeseentneeeeeeerereee
5.5 Controlling OTT documents
5.5.1 Creating a new OTT document...
5.5.2 Updating an existing OTT document :
5.6 Recording the fix level of the test rig.........ceeeeseeeeeeeeeeeee
6 Release ManageMe nt........cccccccsssseecessesteeeeeeeeeeeeesseeeeneeeeeeterers
6.1.1 Deciding whether a software fix should be developed. 24
6.1.2 Defining the release plan and time scales
6.1.3. Managing the delivery of supporting services
6.1.4 Creating the Software fixX........ cc cceeeesseeeeeseneeeeseetneeereeeee
6.1.5 Re-raising a release NOLE.........cccecsceceeseeeeereeeeeeesereeeneee
6.1.6 Authorising the software fix
6.1.7 Completing the release proces:
6.1.8 Work Instructions
6.1.9 Software Distribution Service REVieW...........:ccccseceeees 28
7 BUSINESS CONTINUILY........c ce ceeecesseeesseeeene cece eeereeeseeeeerseeteneneeeee
8 Appendix A Process diagrams.
A.1__ First and second line support.
A.2.— Third and fourth line support...
A.3 Support and release management Process... eee 32
A.4_ Deciding whether a software fix should be developed....... 33
9 Appendix B_ Operational Correction Request form.
10 Appendix C SSC Business Recovery Plan
10.1 Section 1 ICL Pathway Generic
LO.L.1 INtrODUCtION........cceeceeseeeeseeeeeeeeeeeceeeeceaeeeeseserseseneseneeeeee
10.1.2
10.1.3
10.1.4 Assumptions..
10.1.5 Change Management .
10.1.6 AUGIt.. cece ee ceeeeeeeeesaeeeeeeeaeeeeeesneeeeeesneanaeeee 41
10.1.7 TEStING.......cccccceseccssceescesseceseseesesssseesseceseeeersesessesensaeeee 41
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 6 of 67
POL-0061572 F/s7/6
POL00000900
POL00000900
ICL Pathway CS Support Services Operations Manual Ref: CS/QMS/004
Version: 2.0
COMMERCIAL IN CONFIDENCE Date: 29/01/01
10.1.8 Business continuity process at Pathway.
10.2 Section 2 SSC specific
10.2.1 Strategy explanation ..........ccccccceseseseeeeeeeeeeeeeeeeeeseeeennees
10.2.2 Pre-disaster ACtiONS........c:cccccccseeseeesseeseesesseseaeseeeseseeene]!
10.2.3 SSC Contact numbers
10.2.4 Action Checklist
10.2.5 External Contacts -
10.2.6 Vital RECOrS.......ccccscccesecssceseseseeeceeeseeeseeseeeeseseseeseeaeee
10.2.7 Critical EQuipMent....... ee ecceeeeeeeeeeeeereneeeeeeererseeeennenees
10.2.8 SSC Back up Facilities at FELO1
11 Appendix D SSC PC Build Details
1. sIntroduction
This manual provides a high-level description of the activities of the
Support Services Unit within Pathway Customer Service.
2 Scope
This manual primarily provides a description of the operations of
the CS Support Services Unit. However, to put these operations in
context, it also describes some of the activities of other units where
they are relevant. This is particularly the case in the software
release management area. There are other manuals that describe
operations within the other areas of Pathway Customer Service.
Where necessary, in addition to this manual, there are process
documents, lower-level procedures and work instructions that
describe some of the operations in more detail.
Appendix A, at the end of the manual, contains diagrams of some of
the processes.
3 Overview
The purpose of the CS Support Services Unit is to support Pathway
Customer Service in the day-to-day delivery of the Pathway
solution. The prime operational units are:
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 7 of 67
POL-0061572 F/87/7
POL00000900
POL00000900
ICL Pathway CS Support Services Operations Manual Ref: CS/QMS/004
Version: 2.0
COMMERCIAL IN CONFIDENCE Date: 29/01/01
e« System Support Centre (SSC)
Responsible for all support activities, and, in particular, it
provides third line support for all applications in the Pathway
estate
e Operational Test Team (OTT)
Tests all software fixes and, where applicable, changes to
reference data to ensure there is no risk to the live service
e Release Management (RM)
Responsible for the release of software changes to the live estate
4 System Support Centre
This section of the manual describes the operations and
responsibilities of the System Support Centre (SSC).
4.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
4.1.1SSC responsibilities to first and second line support
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
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 8 of 67
POL-0061572 F/s7/8
POL00000900
POL00000900
ICL Pathway CS Support Services Operations Manual Ref: CS/QMS/004
Version: 2.0
COMMERCIAL IN CONFIDENCE Date: 29/01/01
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
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
4.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
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 9 of 67
POL-0061572 F/s87/9
POL00000900
POL00000900
ICL Pathway CS Support Services Operations Manual Ref: CS/QMS/004
Version: 2.0
COMMERCIAL IN CONFIDENCE Date: 29/01/01
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
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
11. 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
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 10 of 67
POL-0061572F/87/10
POL00000900
POL00000900
ICL Pathway CS Support Services Operations Manual Ref: CS/QMS/004
Version: 2.0
COMMERCIAL IN CONFIDENCE Date: 29/01/01
4.2 Applications support
Appendix A in this manual contains process diagrams showing the
roles of the support units.
4.2.1 Role of first line support
The HSH run by OSD, provides first line support to Horizon system
users. The helpdesk has its own procedures, Horizon System
Helpdesk Incident Procedures (DSP/PRO/HH/010). The HSH uses
Powerhelp, an application supplied by Astea Inc, as its helpdesk
system.
When the HSH receives a service call, its first task is to determine
whether or not the call relates to a hardware or software problem.
For hardware problems, it contacts OSD to schedule engineers and,
if necessary, spare parts to resolve the problem. Hardware and
networking issues should be resolved through operational resilience
or change control processes and should not be passed through to
the SSC.
The HSH also does not pass requests for advice and guidance to the
SSC that it can provide directly to the customer.
However, if it cannot resolve a call quickly, or if there is a possibility
of a software problem, the Helpdesk transfers the call to the second
line support team for further investigation.
4.2.2 Role of second line support
The System Management Centre (SMC) is also run by OSD and
provides second line support to Horizon system users. On receipt of
a call from the HSH, the SMC's first task is to determine whether or
not the service call is a software code problem.
The SMC also uses Powerhelp as its helpdesk system. The system
has an Open Teleservice Interface (OTI) link to the SSC's call
management system.
The HSH will have prioritised the call according to the criticality of
the fault as follows:
Priorit Meaning Notes
y
A Business A post office that is wholly inoperative
stopped and unable to process any business
B Business A post office that is restricted in its
restricted ability to transact business, for
example, one counter inoperative
Cc Non-critical A post office that is working normally,
but with a known incapacity, for
example, an interim solution has been
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 11 of 67
POL-0061572F/87/11
POL00000900
POL00000900
ICL Pathway CS Support Services Operations Manual Ref: CS/QMS/004
Version: 2.0
COMMERCIAL IN CONFIDENCE Date: 29/01/01
provided
D Internal An internal HSH/SMC problem, for
example, a helpdesk PC or a telephone
not working
SMC carry out any appropriate pre-authorised activities for
resilience and recovery purposes as defined in their procedures.
Both HSH and SMC have access to KELs (Known Error Logs) which
contain authorised workarounds and repetitive manual action that
they can implement.
If the service request call indicates a software problem which has
been seen before, and for which a workaround is already available,
the SMC follows its own internal procedures to ensure that the
workaround is passed to the customer.
If the service request call indicates a software problem which has
been seen before, and for which a workaround is not available, the
SMC links the current call to the first call and does not pass the call
to the SSC. This ensures that the SSC does not receive duplicate
calls for the same problem.
If the service call indicates a software problem that has not been
seen before, the SMC follows its own internal procedures to pass the
call to the SSC, providing information about the problem and
Pathway's exposure, that is, the number of calls received and the
potential number of counters that are affected. They also provide
details about the software version installed on the platform.
4.2.3 Role of third line support
The System Support Centre (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. If the problem is known, the SSC carries out any pre-authorised
actions that are available to it, for example, workarounds in the
KEL
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 12 of 67
POL-0061572F/87/12
POL00000900
POL00000900
ICL Pathway CS Support Services Operations Manual Ref: CS/QMS/004
Version: 2.0
COMMERCIAL IN CONFIDENCE Date: 29/01/01
3. If the 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
4. If the 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. If the 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. If the 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 PiniICL 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
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 13 of 67
POL-0061572F/87/13
POLO0000900
POL00000900
ICL Pathway CS Support Services Operations Manual Ref: CS/QMS/004
Version: 2.0
COMMERCIAL IN CONFIDENCE Date: 29/01/01
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
4.2.4Role 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
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.
4.2.4.1 Pathway Development and A&TC
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.
4.2.4.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.
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 14 of 67
POL-0061572F/87/14
POL00000900
POL00000900
ICL Pathway CS Support Services Operations Manual Ref: CS/QMS/004
Version: 2.0
COMMERCIAL IN CONFIDENCE Date: 29/01/01
4.2.4.3 OSD
Generally where OSD acts as fourth line support, it also has
responsibility for first, second and third line support - therefore, the
procedures involved are entirely OSD internal procedures. In those
instances where SSC, not OSD, provides third line support the
procedures as defined in 4.2.4.1 will be followed.
4.2.4.4 Eicon
Eicon do not use the PinICL system, but require calls to be logged
by calling 0208 967 8098. Note that this telephone diverts outside
normal office hours to 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 30/12/1999 this was
Dan Dixon,
The Eicon contract is held in FELO1 by the Finance Director
4.3 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. It can also be completed by an SSC staff
member who detects that the data in the system has become
corrupted in the course of diagnosing a fault
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.
The authoriser must be one of the following:
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 15 of 67
POL-0061572F/87115
POL00000900
POL00000900
ICL Pathway CS Support Services Operations Manual Ref: CS/QMS/004
Version: 2.0
COMMERCIAL IN CONFIDENCE Date: 29/01/01
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
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
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 OSD 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
11. 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:
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 16 of 67
POL-0061572F/s7/16
POL00000900
POL00000900
ICL Pathway CS Support Services Operations Manual Ref: CS/QMS/004
Version: 2.0
COMMERCIAL IN CONFIDENCE Date: 29/01/01
12. Checks the electronic signatures
13. Files the OCR in the completed OCR folder on the SSC server
4.4 SSC reference kit
4.4.1 Overview
The SSC reference kit consists of two rigs at BRAO1. One is the
reference rig for the live system and the other is the reference rig
for the next release of software.
OSD maintains both rigs. The live reference rig is operated and
managed by OSD. The second rig is operated and managed by SSC
staff.
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.
4.4.2 Updating the hardware asset register
The SSC maintains a hardware asset register for all of Pathway CS.
The following section describes the procedure to add to and remove
hardware from the asset register. Note that this procedure includes
all CS IT kit not just reference kit.
4.4.2.1 Adding new hardware
Whenever hardware is added within Pathway CS at Bracknell the
asset register is updated. The CS staff member sends an email to
the SSC Manager in the following format:
Asset Serial ICL serial number
Asset Manufact Serial Manufacturer's serial number (non-ICL)
Asset Product For example, Compaq Deskpro
Asset Owner For example, Rig xxx
Asset Owner Building BRAO1
Asset Owner Location For example, Rig Room
Asset Owner Charge For example, UPA66
Code
Asset Comments For example, Correspondence Server C
Asset hw or sw HW or SW
Owning Asset For example, Rig name
Value at Purchase If known
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 17 of 67
POL-0061572F/87117
POLO0000900
POL00000900
ICL Pathway CS Support Services Operations Manual Ref: CS/QMS/004
Version: 2.0
COMMERCIAL IN CONFIDENCE Date: 29/01/01
Date of purchase Formatted as dd/mm/yy
Depreciation Years Always 3
Current Value Leave blank
4.4.2.2 Removing hardware
4.5
Whenever hardware is removed from Pathway CS at BRAO1, the
asset register is updated. The CS staff member sends an email to
the SSC Manager in the following format:
Asset Serial ICL serial number
Asset Manufact Serial Manufacturer's serial number (non-ICL)
Asset Comments Where to
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.
4.5.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.
4.5.2 Transferring knowledge between support units
4.6
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.
Diagnostic tools
4.6.1 Overview
The SSC develops and maintains tools that can assist in the
diagnostic process. The SSC diagnosticians develop the tools
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 18 of 67
POL-0061572F/87/18
POL00000900
POL00000900
ICL Pathway CS Support Services Operations Manual Ref: CS/QMS/004
Version: 2.0
COMMERCIAL IN CONFIDENCE Date: 29/01/01
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.
4.6.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 intranet site. This database
contains details of known diagnostic tools developed in the SSC and
by other support units.
1. If a suitable tool already exists, it should be used
2. If a 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. If the diagnostician has sufficient development skills to develop
the tool him or herself, the SSC Manager schedules the
development work required
4. If the 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
4.7 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.
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 19 of 67
POL-0061572F/87/19
POL00000900
POL00000900
ICL Pathway CS Support Services Operations Manual Ref: CS/QMS/004
Version: 2.0
COMMERCIAL IN CONFIDENCE Date: 29/01/01
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.
4.7.1 Known Error Logs (KELs)
The intranet site holds known error details in Microsoft Word 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.
4.7.2 Change proposals
The intranet site holds copies of each Change Proposal (CP) in a
searchable form as Microsoft Word 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.
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.
4.7.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:
« Date
For example, show all fixes applied to the live environment since
date xxxx
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.
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 20 of 67
POL-0061572F/87/20
POLO0000900
POL00000900
ICL Pathway CS Support Services Operations Manual Ref: CS/QMS/004
Version: 2.0
COMMERCIAL IN CONFIDENCE Date: 29/01/01
4.7.4 Operational Change/Corrections
The intranet site holds copies of both SSC Operational Correction
Requests and OSD 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.
OSD have control over the OSD 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.
4.7.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
4.7.6 Other facilities
4.8
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
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 BRAO1.
Patch panels enable staff to use these PCs to access the test rigs in
BRAO1.
The build script for these PCs was written by OSD, but is held in the
SSC. The PC build was performed in accordance with the Access
Control Policy.
Access from the PCs to the live system to the live system is
controlled by SecurelD, uses firewalls, and an encrypted link, and
conforms to the Access Control Policy.
The SSC access to the system is for two purposes:
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 21 of 67
POL-0061572F/87/21
POL00000900
POL00000900
ICL Pathway CS Support Services Operations Manual Ref: CS/QMS/004
Version: 2.0
COMMERCIAL IN CONFIDENCE Date: 29/01/01
e Assist in diagnosis of problems on the live system
e 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.
4.9 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:
« Riposte message store
e Counter event logs
e 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
« 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:
« 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.
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 22 of 67
POL-0061572F/87/22
POL00000900
POL00000900
ICL Pathway CS Support Services Operations Manual Ref: CS/QMS/004
Version: 2.0
COMMERCIAL IN CONFIDENCE Date: 29/01/01
5 Operational Test Team (OTT)
The Operational Test Team (OTT) within Pathway CS is responsible
for testing fixes prior to their application to the live environment to
ensure that they work and do not adversely affect the environment.
5.1 Overview
To test a software fix, the Operational Test Team carries out the
following activities:
e Scheduling the testing
« Controlling the testing
e Recording rig problems
« Controlling OTT documents
e Recording the fix level of a rig
The following sections describe the process.
5.2 Scheduling testing
The main test scheduling task is carried out using the Release
Management Data Base in conjunction with Release Management.
The OTT team does the following:
1. Populates the OTT testing cycle on the RMDB and allocate
resource.
2. Ensures that sufficient documentation is available for the testing
purposes
3. Receives Release Note from RM
4. Liaises with OSD to get the fix applied to the test rig
5. Files the documentation when testing is complete.
If the fix is rejected during testing due to a fault, OTT send it
back to the relevant unit for correction..
If multiple software fixes are included on one Release Note, one
may fail while the others are successful. In this case, if the fixes
are dependent on each other the whole release is rejected, or, if
the fixes are independent the Release Note may continue and
the failed element is re-scheduled to join a later release of fixes.
6. Updates the release database to show the fix has been tested
successfully (or rejected (with a reason))
7. OTT sends the software fix release note back to Release
Management.
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 23 of 67
POL-0061572F/87/23
POL00000900
POL00000900
ICL Pathway CS Support Services Operations Manual Ref: CS/QMS/004
Version: 2.0
COMMERCIAL IN CONFIDENCE Date: 29/01/01
5.3 Controlling testing
This section describes how the OTT control testing.
When fixes are fast tracked, some of the preparation, for example,
documentation, may have been delayed until after the release has
been distributed. Therefore, some of these activities are revisited to
complete the full schedule of preparation and testing as identified
on the software fix release note.
1. Testers use copies of the following information, where relevant :
e Release note
« Relevant PinICLs
« Handover note
2. When a test has been scheduled, the testers carry out the
following actions:
(a) Produce the test script
(b) Undertake any other preparation necessary for the test
(c) Carry out the test to confirm that the problem occurs as
expected
(d) The fix is applied to the test rig (by OSD)
(e) Test after the fix has been applied
(f) Test after the fix has been regressed
(g) If the fix passes the test, pass the relevant documents and
the updated test script to the OTT Manager. If the fix fails
the test, return it to fourth line support for redevelopment.
5.4 Recording rig problems
Rig problems are recorded in log books. There is one log for each of
the rigs used by OTT. The log book is kept by the counters
belonging to the rig.
1. Whenever a problem is found on a rig, OTT makes an entry in
the appropriate log book. The kind of incidents that are logged
are:
e Hardware faults on any of the kit
e Errors reported by any of the kit
¢ Communications faults
e Afix applied to all hardware except counters
e Afix removed from all hardware except counters
e Anything for which a call is logged with HSH or SMC
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 24 of 67
POL-0061572F/87/24
POL00000900
POL00000900
ICL Pathway CS Support Services Operations Manual Ref: CS/QMS/004
Version: 2.0
COMMERCIAL IN CONFIDENCE Date: 29/01/01
2. The entry in the log book includes the following information:
e Date of the incident.
e Details of the incident
e Call number - if the incident is reported to HSH or SMC
e Status of the incident with HSH or SMC. That is, Open, Closed,
with HSH or SMC
3. When the incident is resolved, OTT updates the log with:
e Closure information
e Date of closure
5.5 Controlling OTT documents
This section describes how OTT maintain documents and notes.
OTT maintains all documents on the machine Sscdiag4 in folder
oTTShare.
5.5.1Creating a new OTT document
To create a new OTT document, the OTT staff member carries out
the following steps:
1. Allocates a new number for the document from the appropriate
index file
2. Updates the index file to show the newly allocated number and
prints a copy of it
3. Creates the new document using the appropriate template
4. Informs other team members that they have created a new
document
5.5.2 Updating an existing OTT document
To update an existing document, the OTT staff member carries out
the following steps:
1. Locates the document by referring to the appropriate index file
2. Updates the document
3. Informs other team members that they have changed the
document
5.6 Recording the fix level of the test rig
A white board documents the fix level of all the counters attached
to the OTT rig.
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 25 of 67
POL-0061572F/87/25
POL00000900
POL00000900
ICL Pathway CS Support Services Operations Manual Ref: CS/QMS/004
Version: 2.0
COMMERCIAL IN CONFIDENCE Date: 29/01/01
OTT updates the white board whenever:
e A fix is applied or removed from a counter
e Acounter is rebuilt or replaced
6 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:
e Deciding whether a software fix should be developed
e Defining the release plan and time scales
e Managing the delivery of supporting services
e Creating the software fix
e Re-raising a release note
e Authorising the software fix
e Completing the release process
Appendix A contains a block diagram of the process.
6.1.1 Deciding whether a software fix should be developed
This section describes how ICL Pathway CS decide if a fix should be
implemented for a problem. See Appendix A.4 process diagram.
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 attend the RMF meeting as follows:
e System Support Centre
e ICL Pathway Development
¢ Operational Test Team
e Configuration Management
« Customer Service
e ICL Outsourcing
e Other units as required
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 26 of 67
POL-0061572F/87/26
POL00000900
POL00000900
ICL Pathway CS Support Services Operations Manual Ref: CS/QMS/004
Version: 2.0
COMMERCIAL IN CONFIDENCE Date: 29/01/01
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, risks, issues, alternative options and
time scales for the open PinlCLs. 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
e CS Operations Manager
e Problem Manager
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.
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 27 of 67
POL-0061572F/87/27
POL00000900
POL00000900
ICL Pathway CS Support Services Operations Manual Ref: CS/QMS/004
Version: 2.0
COMMERCIAL IN CONFIDENCE Date: 29/01/01
Where an emergency fix has been applied to get systems up and
running, release management processes may be applied
retrospectively
6. If the 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 upversioned 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 returns 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 the Customer
Satisfaction Manager 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.
6.1.2 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 POCL, 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
e All parties involved agree to a high-level plan for each release
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 28 of 67
POL-0061572F/87/28
POL00000900
POL00000900
ICL Pathway CS Support Services Operations Manual Ref: CS/QMS/004
Version: 2.0
COMMERCIAL IN CONFIDENCE Date: 29/01/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 release.
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 PinlICL 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
6.1.3 Managing the delivery of supporting services
See Appendix A.5 process diagram
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
« For documentation: notification of completion of update, and the
documentation itself, so that CSRM can distribute it
e For hardware: notification of operational readiness.
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 29 of 67
POL-0061572F/87/29
POL00000900
POL00000900
ICL Pathway CS Support Services Operations Manual Ref: CS/QMS/004
Version: 2.0
COMMERCIAL IN CONFIDENCE Date: 29/01/01
¢ 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
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.
6.1.4 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 are involved, ICL
Pathway development manage them and complete the release note
on their behalf.
6.1.5 Re-raising a release note
A software fix could fail in OTT 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).
Information about the new work-packages is typed into the existing
PinICL as a new progress commentary. The associated PinICL record
in the Release Management database is amended by the adding a
suffix letter, starting with ‘a’ to the record name. For example the
record name PC0001589a indicates that the initial fix associated
with PinICL PCO0001589a has failed and that a new one needs to be
delivered.
6.1.6 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.
6.1.7 Completing the release process
1. Either OSD/SMC or OSD Service Management distributes
software. After the software has been distributed, CSRM receive
notification of the success or otherwise of the release:
e If OSD/SMC or OSD Service Management confirm the
successful release of the software, CSRM receive the release
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 30 of 67
POL-0061572F/87/30
POL00000900
POL00000900
ICL Pathway CS Support Services Operations Manual Ref: CS/QMS/004
Version: 2.0
COMMERCIAL IN CONFIDENCE Date: 29/01/01
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.
6.1.8 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
6.1.9 Software Distribution Service Review
A review is held on a monthly basis with the unit providing the
software distribution service.
7 Business continuity
The Pathway CS Support Services Manager is responsible for
ensuring that a business recovery plan is in place for the SSC. See
Appendix C for details.
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 31 of 67
POL-0061572F/87/31
POL00000900
POL00000900
ICL Pathway CS Support Services Operations Manual Ref: CS/QMS/004
Version: 2.0
COMMERCIAL IN CONFIDENCE Date: 29/01/01
8 Appendix A Process diagrams
(It should be noted that the process diagrams given in this
document only provide general context and guidance. Within
Customer Service formal process documents are published in the
CS/PRD/xxx range)
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 32 of 67
POL-0061572F/87/32
POL00000900
POL00000900
ICL Pathway CS Support Services Operations Manual Ref: CS/QMS/004
Version: 2.0
COMMERCIAL IN CONFIDENCE Date: 29/01/01
A.1 First and second line support
OSD Responsibility
(OSD Procedures used)
Incident report
from Customer
1 Line Support -
Horizon System
Helpdesk (HSH)
advice or
guidance be
given
Provide advice
and guidance
Is
problem H/W
or SW
Contact ICL
System Service
2nd Line Support -
System
Maintenance
Centre (SMC)
Helpdesk
Verify
that problem is
sw
Is
solution
available
No
Yes
v
Provide Link call to 1st
‘solution or call so that
workaround to duplicate calls
Customer do not reach
SSC
System Support Centre _
Responsibility Spd Line Support
“syst rt
(SSC Procedures used) Centre (SSC),
A.2 Third and fourth line support
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 33 of 67
POL-0061572F/87/33
POLO0000900
POL00000900
ICL Pathway CS Support Services Operations Manual Ref: CS/QMS/004
Version: 2.0
COMMERCIAL IN CONFIDENCE Date: 29/01/01
3" Line Support - “Incident report
System Support Centre from SMC (2!
Responsibility Line)
(SSC Procedures used)
Determine likely
area of fault
Allocate call to
member of
centre for
analysis
Is the
fault a known
problem
Yes
No
Provide solution
to Customer
Diagnose cause
from Live System
or Reference Kit
Is the
fault a code
bug
Identify nature of
fault and isolate
sub-system
causing fault
Determine the
location the code
fault and a
possible solution.
Pass to 4” Line
Support
4th Line Support - 4" Line Support -
Various units provide 4" Pathway development, or
OSD, or
Line Support Escher, or
HPS, or
Enterprise systems, or
EMC
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 34 of 67
POL-0061572F/87/34
ICL Pathway
CS Support Services Operations Manual
COMMERCIAL IN CONFIDENCE
POLO0000900
POL00000900
Ref: CS/QMS/004
Version: 2.0
Date: 29/01/01
A.3 Support and release management process
Problems in
live
environment
gn
Manage operations and
support issues
[OSD Ops /SSC]
Vv
Decide whether a
software fix should be
developed
[Forum]
Vv
Define the release
plan and timescales
[Forum]
* SSC involved
* SSC involved
* SSC involved
YY
Create the
software fix
[Development]
Manage supporting
activities
ICS Rel Mgr]
v
Operationally test
the change
{CS OTT/OSD
Ops]
<—>
Configuration manage
the software
[cM]
Vv
Authorise the
software fix
[CS Rel Mgr]
Vv
Distribute software
[SMC/ 1OSD Ops]
poe
Changed live
environment
© 2001 ICL Pathway Limited
COMMERCIAL IN CONFIDENCE
Page: 35 of 67
POL-0061572F/87/35
POL00000900
POL00000900
ICL Pathway CS Support Services Operations Manual Ref: CS/QMS/004
Version: 2.0
COMMERCIAL IN CONFIDENCE Date: 29/01/01
A.4 Deciding whether a software fix should be
developed
Identified If fastrack is requried, support request CSRM
software fixes to manage a ‘virtual forum’ and non-urgent
\ testing & documentation will be scheduled
Vv after release
Distribute list of In emergency, the following people can
identified fres to be I authorise a fix to be produced without
esr lore contacting the CS Release Manager: the SSC
‘el Mar]
Manager, the CS Operations Manager and
“I the Problem Manager.
waming
it Identify own situation
Pee eoomen re dependancies, Retum to orginator
i risk, options, issues ise CR if
[Service Mgt] {All Forum members] [ssc]
INew call raised on new
Consider the felease, Old cal
I__yp] closed. Reason is
situation Fixed at Release nnn’
(Forum) [CSRM]
Escalate to Cust
Satsfacton
—>
Decide whether appropriate
to fix [Forum] [CS Rel Mgr}
Do not fix 7
‘Append authorisation
to PinICL. PiniCL
then transferred to.
development
Close call on CS Rel
gr authority & give
—> reason
{8c {SSC}
Fixes to be
created
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 36 of 67
POL-0061572F/87/36
POL00000900
POL00000900
ICL Pathway CS Support Services Operations Manual Ref: CS/QMS/004
Version: 2.0
COMMERCIAL IN CONFIDENCE Date: 29/01/01
A.5 Managing the delivery of supporting services
Notification of I
service
requirements
v
Prepare for release: Schedule access
v
Confirm completion
of preparation to
CSRM [various]
v
Sign off rel note when
all supporting
preparation is complete]
[CSRM]
v
Await
authorisation
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 37 of 67
POL-0061572F/87/37
POL00000900
POL00000900
ICL Pathway CS Support Services Operations Manual Ref: CS/QMS/004
Version: 2.0
COMMERCIAL IN CONFIDENCE Date: 29/01/01
9 Appendix B Operational Correction Request
form
The following page contains an example of an OCR form.
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 38 of 67
POL-0061572F/87/38
POL00000900
POL00000900
ICL Pathway CS Support Services Operations Manual Ref: CS/QMS/004
Version: 2.0
COMMERCIAL IN CONFIDENCE Date: 29/01/01
ICL Pathway SSC Operational Correction
Request (OCR)
OCR Title
Raised by (Name) Location
Date/time raised Type of change (e.g.
SQL script)
‘System to be changed Required to be done
(e.g. PAS/CMS) by (date/time)
Associated PiniCL
number
Authorizatio Authorizer
n signature (Print
name)
Authorizatio Authorizer
n date position
DATABA FILE
SE Chang
Change es
Ss
Table name File name
Parameter File
description location
Helpdesk Location of
screen backup
Purpose and details of the change
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 39 of 67
POL-0061572F/87/39
POLO0000900
POL00000900
ICL Pathway CS Support Services Operations Manual Ref: CS/QMS/004
Version: 2.0
COMMERCIAL IN CONFIDENCE Date: 29/01/01
Regression path
Work done by (SSC signature)
Work done by (Print Name)
Witnessed by (SSC or 4™ line signature)
Witnessed by (SSC or 4™ line Print name)
Completed at (Date and time)
Was change tested on reference rigs prior to YES 7 NO
application to live
‘System state before change
‘System state after change
Comments
See notes on the reverse of this document for the procedure for use.
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 40 of 67
POL-0061572F/87/40
POL00000900
POL00000900
ICL Pathway CS Support Services Operations Manual Ref: CS/QMS/004
Version: 2.0
COMMERCIAL IN CONFIDENCE Date: 29/01/01
ICL Pathway SSC Operational Correction
Request Process
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 correction originator must -
i) Complete an OCR form for every correction to data on the live system.
This can be done by anyone within ICL Pathway, but is normally completed by the Duty Manager,
other Problem Manager or Business Support Manager when an incident or problem has been caused
by an error in the data. It can also be completed by SSC staff members who, in the course of
diagnosing a fault detect that the data in the system has become corrupted.
ii) Email the OCR form to an authorizer, electronically signing it where possible, and where this is not possible, telephoning the authorizer to
ii)
ii)
iii)
confirm that the OCR is being sent.
The correction authorizer must be one of the following -
* Duty Manager
* Business Support Manager
* CS Operations Manager
* SSC Manager
* Release Manager
The correction authorizer will
Authorize the correction, or report back to the originator to specify why the correction is not being
authorized
Forward the OCR form to the SSC electronically with an encrypted electronic signature file.
The SSC staff member who is to perform the correction will
check the electronic signature of the authorizer before proceeding
Store the OCR form and the signature file in the “received OCRs” section on the SSC server
Wherever possible, produce a script to make the data correction, and test this on the SSC reference rig
prior to it running on the live system. Sections in the OCR form confirm whether or not this has been
done.
iv) Prior to the correction being made, document the state of the affected part of the system on the OCR
form.
v) Prior to the correction being done, complete on the OCR form the regression path details. If no
regression path is possible, then this must be stated.
vi) When corrections are to be made to the live system, at least two people must be in attendance. This will
normally be SSC staff, but can be one SSC staff member and one person from the 4" line support unit
responsible for the relevant area in which the data correction will take place, or one SSC staff member
and one OSD staff member.
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 41 of 67
POL-0061572F/87/41
POL00000900
POL00000900
ICL Pathway CS Support Services Operations Manual Ref: CS/QMS/004
Version: 2.0
COMMERCIAL IN CONFIDENCE Date: 29/01/01
vii) On completion of the data correction, document the state of the affected part of the system and mail an
electronically signed copy of the OCR form to the “witness”. The witness will then also electronically sign
the form and email it to either the SSC manager or the SSC web site controller.
viii) Update the PinICL and report back to the originator to confirm that the correction has been completed
The SSC manager or SSC web site controller will
ix) Check the electronic signatures
x) File the OCR in the “completed OCR” section on the SSC server.
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 42 of 67
POL-0061572F/87/42
POL00000900
POL00000900
ICL Pathway CS Support Services Operations Manual Ref: CS/QMS/004
Version: 2.0
COMMERCIAL IN CONFIDENCE Date: 29/01/01
10 Appendix C SSC Business Recovery Plan
10.1Section 1 ICL Pathway Generic
10.1.1 Introduction
This appendix provides instructions for staff working for ICL
Pathway SSC on how to respond to a major incident affecting the
building at BRAO1, personnel, assets or the business.
The SSC is responsible for the safekeeping and communication of
the business continuity plan within the team.
This plan has been developed to ensure that Pathway can recover
from a major disruption in a timely and efficient manner. However,
the existence of this plan alone does not guarantee a successful
recovery. This plan must be kept current as personnel, equipment,
facilities, and business processes change. The participants in the
recovery process must know and understand their roles in the
execution of the plan. Physical and information environments on
which the plan depends must be monitored to ensure that they are
being maintained and are available for recovery if needed.
Furthermore, the plan must be tested regularly for validity.
10.1.2 Objectives
The primary objectives of the SSC business continuity plan are:
e to provide a tested vehicle which, when executed, will permit an
efficient, timely resumption of all critical business functions in
order to continue operations
e to contain, within acceptable levels, the financial and operational
impacts that Pathway could suffer following a disruption
« to minimise impacts upon customers
e To minimise the impact to the public and to the industry image
of Pathway
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 43 of 67
POL-0061572F/87/43
POL00000900
POL00000900
ICL Pathway CS Support Services Operations Manual Ref: CS/QMS/004
Version: 2.0
COMMERCIAL IN CONFIDENCE Date: 29/01/01
10.1.3
Scope
This plan provides for recovery of the SSC operations within one
working day of a disruption.
The plan covers:
10.1.4
staff relocation
communication with customer and suppliers
recovery of critical records
rebuild of critical equipment
Assumptions
The Plan has been developed with the following assumptions:
10.1.5
correct data files are backed up and stored remotely
office IT at FELO1 will be available within 2 hours of invocation
all necessary critical records have been stored offsite and can be
recovered within two hours after an incident has been notified to
the SSC Manager or his deputy
Change Management
This plan will be reviewed regularly
10.1.5.1 Change Checklist
Changes that may affect the plan are:
10.1.6
SSC personnel and related details
critical business functions
third Parties providing support to the SSC
software
hardware
critical records.
Audit
Audit of the plan will be conducted according to the ICL Pathway
Audits policy and annual plan.
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 44 of 67
POL-0061572F/87/44
POL00000900
POL00000900
ICL Pathway CS Support Services Operations Manual Ref: CS/QMS/004
Version: 2.0
COMMERCIAL IN CONFIDENCE Date: 29/01/01
10.1.7 Testing
The plan will be reviewed once per annum or when significant
organisation changes take place. Any resulting plan changes will be
collated and incorporated into this document and the plan re-
issued.
10.1.8 Business continuity process at Pathway
This plan is derived from the document “Business Recovery Plan
704 Systems Support Centre”, which defines the Pathway business
continuity process (BCP). The following flowchart shows the flow of
high level activities that make up the BCP.
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 45 of 67
POL-0061572F/87/45
ICL Pathway
COMMERCIAL IN CONFIDENCE
CS Support Services Operations Manual
POLO0000900
POL00000900
Ref: CS/QMS/004
Version: 2.0
Date: 29/01/01
1) Assess & advise
meeting
2) Gather data
meeting
3) Decide and communicate
immediate strategy
meeting
4) Monitor actions
& gather data
meeting
5) Decide & communi
Team Leader
Crisis Management
Team Feedback
CMT Input
CMT Input
BRT 2.0 Invocation of
Bus Recovery plans &
medium term strateg
meeting
6) Monitor actions
& Gather Data
CMT Input
meeting
7) Decide & communicé
long term
CMT Input
BRT 4.0 Implement
restoration of normal ops/
clear backlog
strategy
8) Close out meeting
CMT Input
CMT Input
© 2001 ICL Pathway Limited
COMMERCIAL IN CONFIDENCE
Page: 46 of 67
POL-0061572F/87/46
POL00000900
POL00000900
ICL Pathway CS Support Services Operations Manual Ref: CS/QMS/004
Version: 2.0
COMMERCIAL IN CONFIDENCE Date: 29/01/01
10.2Section 2. SSC specific
10.2.1 Strategy explanation
In the event of a disaster affecting BRAO1 which is so severe that
the existing arrangements for UPS, backup generators etc are
ineffective, that there is a total building loss, then some SSC staff
will move to FELO1.
SSC access PCs, which are used to access the live system, have
been built and will be maintained in a secure area in FELO1.
A room in FELO1 which has been set up with the required firewall
and connections to the live service will be used, and SSC staff will
connect their own PCs into the available sockets.
OSD staff will be required during this process as a final check on the
connections to the live system through routers and firewalls.
SSC maintains all essential data on the SSC web site, off site copies
of which are held by both the senior technician and the SSC
manager. These copies will be used if necessary to recover the web
site, which contains diagnostic information, including Known Error
Logs.
10.2.2 Pre-disaster Actions
1. Ensure that the essential documentation on the SSC web site is
correctly backed-up, and that off-site copies are maintained.
2. Ensure that essential equipment is lodged at the backup site
(FELO1) in a secure area
3. Ensure that the essential SSC staff who will travel to FELO1 in the
event of an emergency have access to the site, and to the
secure area where the kit is maintained.
4. Ensure that OSD have installed, and are maintaining the required
communications connections from the backup site to the live
estate.
10.2.3 SSC Contact numbers
Anscomb
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 47 of 67
POL-0061572F/87/47
POLO0000900
POL00000900
ICL Pathway CS Support Services Operations Manual Ref: CS/QMS/004
Version: 2.0
COMMERCIAL IN CONFIDENCE Date: 29/01/01
Ballantyne john
Carroll trick Senior
Technician
Chambers Anne _ ——
Coleman ichard I
“Critchley raham a
Foster pe
Greenwood Kath G RO
Harvey Martin _—_—
Hawkes hris
Longley arbara. SSC
Coordinator
Maxwell Gary
O'Connor idan
Parker teve Senior
Technician
Patel
“Peach SSC Manager
Rowe = - —_
Seddon ave Hi
pkins en en
Simpson arrett
Squires steve
Steed =
Streeter Ni el 7
Wright ti
10.2.4 Action Checklist
TL-BRTL.O.1 ‘Team Leader or Deputy notified of an Start End Complete: Y/N
Incident by a member of CMT. Record name I Date/Time: Date/Time:
of caller.
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 48 of 67
POL-0061572F/87/48
POLO0000900
POL00000900
ICL Pathway CS Support Services Operations Manual Ref: CS/QMS/004
Version: 2.0
COMMERCIAL IN CONFIDENCE Date: 29/01/01
TL-BRT1.0.2 Ensure that the Crisis Controller or Deputy Start End Complete: Y / N
has been informed Date/Time: Date/Time:
TL-BRTI.0.3 Ensure that all staff stay by a telephone on Start End Complete: Y_
stand by until otherwise informed Date/Time: Date/Time:
TL-BRT1.0.4 On receiving a call from the CMT, please Start End Complete: Y/N
ensure that the following is ascertained before I Date/Time: Date/Time:
undertaking any unrequested actions:
TL-BRT1.0.5 1.Exaetly what has happened ? Start End Complete: Y/N
Date/Time: Date/Time:
TLBRT1.0.6 2.Who has been informed? Start End Complete:
Date/Time: Date/Time:
TL-BRTLO.7 3.What is the impact ? Start Complete: Y/N
Date/Time
TL-BRT1.0.8 4.Whiat is the estimated time of inoperability ?_ I Start End Complete: Y / N
Date/Time: Date/Time:
TL-BRILO.9 5.Do 1 need to go to the alternate location? I Start End Complete: Y/N
Date/Time: Date/Time:
TL-BRT1.0.10 6.Do 1 need to contact other staff? Start End Complete: Y/N
Date/Time: Date/Time:
TL-BRTLO.1 7.How do 1 contact the CMT? Start End Complete: Y/ N
Date/Time: Date/Time:
TL BRT2.0.33 Ensure that all staff are accounted for. Start End Complete: Y/ N
Date/Time: Date/Time:
TL-BRT2.0.34 Obtain details regarding any personnel Start End Complete: Y/ N
seriously affected by the Incident Date/Time: Date/Time:
TL-BRT2.0.35 Contact Deputy (as available) and ensure that I Start End Complete: Y/N
all other team members are contacted as soon Date/Time: Date/Time:
as is reasonable
TL-BRT2.0.36 When will you attempt to contact these staff — I Start Complete: Y/ N
again ? Date/Time:
TL BRT2.0.1 Check with next of kin if these staff are away I Start Complete: Y/ N
or on holiday ete. Date/Time:
TL-BRT2.0.2 Leave message that they are to contact the Start End Complete: Y/ N
Team Leader before returning to work. Date/Time: Date/Time:
TL-BRT2.0.3 If unsure of the situation and cannot confirm Start End Complete: Y/N
it via the CMT, everyone should stay near the Date/Time: Date/Time:
telephone that the CMT has the number for
and await instruction
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 49 of 67
POL-0061572F/87/49
POLO0000900
POL00000900
ICL Pathway CS Support Services Operations Manual Ref: CS/QMS/004
Version: 2.0
COMMERCIAL IN CONFIDENCE Date: 29/01/01
TL-BRT2.0.4 Keep in regular contact with Team Members Start End Complete: Y/ N
to reassure them that the situation is under Date/Time: Date/Time:
control and provide advice.
TL-BRT2.0.5 When notified by the CMT, ensure that you Start End Complete: Y/ N
and your staff pack and proceed to your Date/Time: Date/Time:
Alternative Team Location as requested.
TL-BRT2.0.6 Identify any critical activities, documents, or Start End Complete: Y/N
actions possibly affected by the Incident Date/Time: Date/Time:
TL-BRT2.0.7 Identify all critical aspects of work in progress I Start Complete: Y/N
Date/Time:
TL-BRT2.0.8 Identify the key events that have recently Start End Complete: Y/N
occurred to the company. Date/Time: Date/Time:
TL-BRT2.0.9 Identify any deadlines that may occur soon. Start End Complete: Y/N
Date/Time: Date/Time:
TL-BRT2.0.10 Identify the extent of any lost data. Start Complete: Y/N
Date/Time:
TL-BRT2.0.11 Identify any catch-up processes that may be Start Complete: Y/N
required to perform. Date/Time: Date/Time:
TL-BRT2.0.12 Identify any work around procedures that Start End Complete: Y N
may be required. Date/Time: Date/Time:
TL-BRT2.0.13 Identify any special staffing requirements for I Start End ‘Complete: YN
the organisation. Date/Time: Date/Time:
TL-BRT2.0.14 Identify any special projects that may alter Start End Complete: Y/N
the recovery priorities. Date/Time: Date/Time:
TL-BRT2.0.15 Inform the CMT members of the business Start End Complete:
requirements identified Date/Time: Date/Time:
TL BRT2.0.16 Start the Incident Log Start End Complete: Y/N
Date/Time: Date/Time:
TL-BRT2.0.17 Create a staff location list for all members of Start End Complete: Y/N
staff. Date/Time: Date/Time:
TL-BRT2.0.18 Assist with all personal problems arising from I Start End Complete: Y / N
the Incident. Date/Time: Date/Time:
TL-BRT2.0.19 Maintain status information on any company I Start End Complete: Y/N
personnel receiving medical treatment or Date/Time: Date/Time:
other disaster related services.
TL-BRT2.0.20 Report the level of employee assistance being I Start End Complete: Y/N
provided to the CMT. Date/Time: Date/Time:
TL-BRT2.0.21 If appropriate, arrange for petty cash to be Start End Complete: Y/N
made available. Date/Time: Date/Time:
PL-BRI2.0. If appropriate, arrange for hotel Start End Complete:
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 50 of 67
POL-0061572F/87/50
POLO0000900
POL00000900
ICL Pathway CS Support Services Operations Manual Ref: CS/QMS/004
Version: 2.0
COMMERCIAL IN CONFIDENCE Date: 29/01/01
accommodation to be made available for Date/Time: Date/Time:
members of staff.
TL BRT2.0.23 If appropriate, arrange travel for relevant Start End Complete: Y/
members of staff. Date/Time: Date/Time:
TL-BRT2.0.24 Identify and arrange for essential equipment — I Start End Complete: Y/N
to be provided. Date/Time: Date/Time:
TL BRI2.0.25 Stand down other non-essential personnel & — I Start End Complete: Y/N
services. Date/Time: __I Date/Time:
TL-BRT2.0.26 If required to work at alternative location or I Start End ‘Complete: Y/N
away from home, consider the checklist items I Date/Time: Date/Time:
below:
~ Business Continuity Plan
- Mobile phone
- Charger & spare batteries
- Travel plugs
- Laptop - Charger & spare batteries
Money & Credit cards
~ Food & Beverages
- Change of clothes
- Overnight Bag
- Own contact list
- Passwords
~ Security Pass
- Medi
ine - for personal use
- Passport
- Driving License
TL-BRT2.0.27 Inform close family of departure to Alternate I Start End Complete: Y/N
Site or Crisis Management Site. Date/Time: Date/Time:
TL-BRT2.0,28 Provide the Incident Management Team with I Start End Complete: Y/N
a contact list with the alternate site locations I Date/Time: Date/Time:
at which each team member is located
TL-BRT2.0.29 Support Resumption Management in filling I Start End Complete: Y/N
requests for additional personnel. Date/Time: Date/Time:
BRT2.0.30 A
internal phone directories to ensure Date/Time: Date/Time:
st in the creation and maintenance of Start End Complete: Y/N
communication among relocated business
areas as necessary.
TL-BRT2.0.31 Use company credit card where possible to Start End Complete: Y/N
pay for critical expenses and keep rec Date/Time: Date/Time:
safe so they can be sent to Finance staff
TL-BRT2.0.32 Do not exceed a reasonable level of Start End Complete: Y/N
expenditure without authority from the Date/Time: Date/Time:
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 51 of 67
POL-0061572F/87/51
POL00000900
POL00000900
ICL Pathway CS Support Services Operations Manual Ref: CS/QMS/004
Version: 2.0
COMMERCIAL IN CONFIDENCE Date: 29/01/01
CMT,
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 52 of 67
POL-0061572F/87/52
POL00000900
POL00000900
ICL Pathway CS Support Services Operations Manual Ref: CS/QMS/004
Version: 2.0
COMMERCIAL IN CONFIDENCE Date: 29/01/01
10.2.5 External Contacts
Listed below are the contacts who may need to be informed
following an incident.
Name: osD Work:
Belfast
Address: Belfast Home:
Fax:
Mobile:
EMail Address:
Contact Unix Team - i
Name: Andy Gibson !
NT Team - :
Darren Dillon
Name: HSH /
SMC
Address: STEO9 Home:
Fax:
Mobile:
EMail Address:
Contact lan Cooley
Name:
Name: BRAOL
Access
Security
consultants -
Address: Via Workplace Home:
Technology
Fax:
Mobile:
EMail Mike.Wood: GRO}
Addres
s:
Contact I Mike Wood = /Paul
Name: I Sinclair
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 53 of 67
POL-0061572F/87/53
POL00000900
POL00000900
ICL Pathway CS Support Services Operations Manual Ref: CS/QMS/004
Version: 2.0
COMMERCIAL IN CONFIDENCE Date: 29/01/01
Name:
Pathway
Development
Address:
ICL
FELO1
Fax:
Mobile:
EMail
Addres
s
PeterJerami_ GRO ]
Contact
Name:
Peter Jeram
Name:
CS Support
Services
Manager
Address:
ICL
BRAOL
Home:
Fax:
Mobile:
EMail
Addres
st
Contact
Name:
Peter Burden
© 2001 ICL Pathway Limited
COMMERCIAL IN CONFIDENCE Page: 54 of 67
POL-0061572F/87/54
POL00000900
POL00000900
ICL Pathway CS Support Services Operations Manual Ref: CS/QMS/004
Version: 2.0
COMMERCIAL IN CONFIDENCE Date: 29/01/01
10.2.6 Vital Records
This list contains all the vital records for the department. These
records should be re-created as part of the departmental recovery
process.
Record Name: Operation Manual
Media Type: Word document
Recovery Source: PVCS
Source Contact Details: Alex Hanson CM
Required By: All SSC staff
Record Name: Back Up Procedures
Media Type: HTML Pages
Recovery Source: SSC Web site backup copies
Source Contact Details: I SSC manager, SSC Senior technician
Required By: All SSC staff
Record Name: Department Contact List
Media Type: HTML Pages
Recovery Source: SSC Web site backup copies
Source Contact Details: I SSC manager, SSC Senior technician
Required By: All SSC staff
Record Name: Known Error Log / OCP database
Media Type: HTML Pages
Recovery Source: SSC Web site backup copies
Source Contact Details: I SSC manager, SSC Senior technician
Required By: All SSC staff
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 55 of 67
POL-0061572F/87/55
POL00000900
POL00000900
ICL Pathway CS Support Services Operations Manual Ref: CS/QMS/004
Version: 2.0
COMMERCIAL IN CONFIDENCE Date: 29/01/01
Record Name: SSC support CD
Media type: Compact Disc
Recovery Source: SSCDIAG4 backup copies
Source contact details: SSC Manager, SSC Technicians
Required by: All SSC Staff
10.2.7 Critical Equipment
Listed below is information regarding the equipment that may be
required following an incident.
Equipment Name:
Description: SSC Build PCs
Location: FELO1
Required By: All SSC staff who have moved to FELO1
Owner: SSC Manager
Quantity: 5
Requirements Over Time :Required 4 hrs after disaster declared
Equipment Name:
Description: SSC Web server / Powerhelp access PC
Location: FELO1
Required By: All SSC staff who have moved to FELO1
Owner: SSC Manager
Quantity: 1
Requirements Over Time :Required 4 hrs after disaster declared
Equipment Name:
Description: Access to Powerhelp
Location: FELO1
Required By: SSC Co-ordinator
Owner: SSC Manager
Quantity: 1 link
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 56 of 67
POL-0061572F/87/56
POL00000900
POL00000900
ICL Pathway CS Support Services Operations Manual Ref: CS/QMS/004
Version: 2.0
COMMERCIAL IN CONFIDENCE Date: 29/01/01
Requirements Over Time :Required 4 hrs after disaster declared
Equipment Name:
Description: Access to live system
Location: FELO1
Required By: SSC Diagnosticians
Owner: OSD
Quantity: 5 links to live system, with connectors available, firewall
access
Requirements Over Time :Required 4 hrs after disaster declared.
10.2.8 SSC Back up Facilities at FELO1
The kit will be located in meeting room 6 - "D" block (M6).
Reception will be able to give directions and a swipe card that
works for D block (normal cards will not work).
The Pathway private network is patched to lap point 21 in the
meeting room.
OSD Service Management (e.g. Steve Gardiner or Ken Wood) will
setup/remove this patch. This network point will be used via a 16
port hub to drive all the red network PC’s
The Pathway public network is patched to point H10 in the meeting
room. This should be directly connected to the PiniCL admin system
(SSCPublic)
SSCFELO1 - SSC workstation (connected to Red network Hub)
SSCFELO2 - SSC workstation (connected to Red network Hub)
SSCFELO3 - SSC workstation (connected to Red network Hub)
SSCFEL04 - SSC workstation (connected to Red network Hub)
SSCFELO5 - SSC workstation (connected to Red network Hub)
SSCFELO6 - SSC workstation (connected to Red network Hub)
SSCPublic - PinICL system. (connected to public network point H10)
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 57 of 67
POL-0061572F/87/57
POL00000900
POL00000900
ICL Pathway CS Support Services Operations Manual Ref: CS/QMS/004
Version: 2.0
COMMERCIAL IN CONFIDENCE Date: 29/01/01
SSC staff logon to the workstations using their normal PWYDCS
username and password.
TCP/IP details
Red network via hub:-
SSCFELO1 223.94.9.11
SSCFELO2 223.94.9.12
SSCFELO3 223.94.9.13
SSCFELO4 223.94.9.14
SSCFELO5 223.94.9.15
SSCFELO6 = 223.94.9.16
Netmask: 255.255.255.0
Gateway: 223.94.9.254
WINS: 223.64.1.73
WINS: 223.74.1.73
Public network via lap point H10:-
SSCPUBLIC 192.168.77.144
Netmask 255.255.255.0
Gateway 192.168.77.1
Password details for these PC’s can be found in the file
\SSC\passwords.txt.asc on the SSC Support CD. This is a PGP
encrypted file which can be opened by the following keys:-
Mik Peach, Steve Parker, Richard Coleman, John Simpkins
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 58 of 67
POL-0061572F/87/58
POL00000900
POL00000900
ICL Pathway CS Support Services Operations Manual Ref: CS/QMS/004
Version: 2.0
COMMERCIAL IN CONFIDENCE Date: 29/01/01
11 Appendix D- SSC PC Build Details
Full details of the SSC workstation build are found in the file
\SSC\SSCWorkstationBuild.doc on the SSC support CD.
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 59 of 67
POL-0061572F/87/59