FUJ00119994
FUJ00119994
ICL End to end support process Operational Ref: CS/FSP/006
Pathw: reemenI Version: 1.0
‘athway agreement Date: 10/10/99
Document Title: End to End Support Process, Operational Level Agreement
Document Type: Specification
Abstract: Defines the operational responsibilities of the units
involved in the end to end support of the Pathway solution
software in relation to each other.
Status: Draft
Distribution: SMC Manager,
Horizon Helpdesk Manager
Pathway Development Manager
Library
Author: Mik Peach
Comments to: Author
Comments by: 26/9/97
COMMERCIAL IN CONFIDENCE Page 1 of 20
© 1997 ICL Pathway Ltd
FUJ00119994
FUJ00119994
ICL End to end support process Operational Ref: CS/FSP/006
Pathway agreement Version: 1.0
Date: 10/10/99
Q Document control
0.1 Document history
Version Date Reason
0.1 12/9/97 First Draft
0.2 23/9/97 Draft including comments from SSC Manager
03 8/12/97 Draft incorporating comments from Development Manager
1.0 10/10/99 Administrative change to version 1.0
Addition of one sentence in the Introduction (section2)
confirming that support is required at all times.
0.2 Approval authorities
Name Position Signature Date
Stephen Muchow CS Director
0.3 Associated documents
Reference Vers Date Title Source
0.4 Abbreviations
ssc Software Support Centre
SMC Systems Maintenance Centre
HSH Horizon Systems Helpdesk
Incident A packet of support work usually taking the form of a single problem
call, recorded on the relevant call management system
Resolution That which provided a permanent fix for an incident
Workroun A temporary fix for an incident
COMMERCIAL IN CONFIDENCE Page 2 of 20
FUJ00119994
FUJ00119994
ICL End to end support process Operational Ref: CS/FSP/006
Pathway agreement Version: 1.0
Date: 10/10/99
d
PinICL ICL Proprietary call management system
Powerhelp Call management system supplied by Astea Inc
0.5 Changes in this version
Comments incorporated from Development manager.
COMMERCIAL IN CONFIDENCE Page 3 of 20
FUJ00119994
FUJ00119994
ICL End to end support process Operational Ref: CS/FSP/o06
Pathwa agreement Version: 1.0
Y 9 Date: 10/10/99
0.6 Table of content
3 HSH/SMC obligations to SSC......ccccssssesecsssseeesssseeseessseeesesssseeeeesssensssee 7
4 SSC Obligations to HSH/SMC.
5 SSC Obligations to 4" line support.
6 4'" line support obligations to SSC.
Appendix A Definition of call priorities.
Appendix B_ Definition of time allowed for calls within the support
community......17
COMMERCIAL IN CONFIDENCE Page 4 of 20
ICL
FUJ00119994
FUJ00119994
End to end support process Operational Ref: CS/FSP/o06
Pathway agreement Version: 1.0
Date: 10/10/99
2 = Introduction
The purpose of this process agreement is to formally document the objectives and
responsibilities which each unit involved in the support of the Horizon solution has towards the
other units similarly involved.
This process agreement specifically excludes the management of Operational problems for
which CFM is wholly responsible, and all hardware related calls.
This process agreement also documents the measures by which each unit will be measured in
its performance of those objectives and responsibilities.
This document does not attempt to define the processes by which each unit will function, since
these are documented elsewhere, although it does outline briefly parts of those processes where
they relate specifically to the obligations between the units.
The document is laid out in the form of specific obligations between each level of support, and
the other level (s) of support to which it relates, with specific measures in bold italics after
each obligation.
Note that support for the Pathway system is required 2ghrs _* 365 days per year and therefore
there is likely to be a requirement for some or all lines of support to provide the service on this
basis.
COMMERCIAL IN CONFIDENCE Page 5 of 20
FUJ00119994
FUJ00119994
ICL End to end support process Operational Ref: CS/FSP/o06
Pathwa agreement Version: 1.0
Y 9 Date: 10/10/99
3 Scope
The scope of this document is limited to the units responsible for the support of the software in
the Pathway Solution.
COMMERCIAL IN CONFIDENCE Page 6 of 20
ICL
Pathway
FUJ00119994
FUJ00119994
End to end support process Operational Ref: CS/FSP/o06
agreement Version: 1.0
9 Date: 10/10/99
3
a)
b)
©
d
e
HSH/SMC obligations to SSC
From the point of view of the SSC, the HSH and SMC units can be treated as one “unit”
since incidents reported to the SSC should always have been passed from the HSH to the
SMC prior to being received. Each of these units has separate responsibilities, and only the
SMC has a direct interface to the SSC. For the purpose of this document however they are
treated as a single entity.
The functions of this unit are -
To receive calls from the customer, whether this be ITSA, Postmasters, the PDA etc.
To log all calls on a call management system (currently Powerhelp)
No complaints from customers regarding calls not being logged.
To “filter” all hardware calls and route them to ICL Sorbus
No hardware calls passed to SSC except in circumstances where ICL Pathway need to
be made aware, e.g. recurrent hardware problems which need to be adressed
between ICL Pathway and a supplier.
To “filter” all calls for which the problem is already known to the support community and
for which a resolution is already known or has been generated. In this context the term
“resolution” can take a number of forms, including
i) The statement that the problem is resolved in release xxx of the Horizon
solution
ii) There is a documented workaround for the problem.
iii) The documentation relating to that part of the system is under review or
being changed.
No calls passed to the SSC which are subsequently resolved as known errors, except
in cases where the symptoms reported by the customer did not match the symptoms
recorded in the known error documentation, and which therefore the HSH/SMC
could not reasonably have been expected to find.
To retain in the Powerhelp systems duplicate incidents - i.e. incidents which are
repetitions of an incident which has already been passed to the SSC, and to ensure that
when the resolved incident is received from the SSC, the duplicated calls are closed.
No duplicated incidents passed to the SSC, except in cases where the symptoms
reported by the customer did not match the symptoms recorded in the original
incident, and which therefore the HSH/SMC could not reasonably have been
expected know as a duplicate .
To ensure that the correct evidence for any problem is collected prior to the incident being
passed to the SSC for investigation.
COMMERCIAL IN CONFIDENCE Page 7 of 20
FUJ00119994
FUJ00119994
ICL End to end support process Operational Ref: CS/FSP/o06
Pathwa agreement Version: 1.0
Y 9 Date: 10/10/99
No calls rejected by the SSC on the basis that the evidence was inadequate.
Specifically excluded from this measure are instances where, although the evidence
was inadequate, the SSC had not documented the evidence required and occasions
where the evidence required was unobtainable.
g) To ensure that any incident which requires investigation by the SSC is passed onto the call
management system used by ICL Pathway (currently PinICL) assigned to the correct SSC
team (EDSC).
No calls lost because of incorrect assignment by HSH/SMC
h) To ensure that if there are any updates made to incidents passed to the SSC which will
assist the SSC in diagnosis, then these are sent to the SSC in the same manner as g).
No complaints from SSC staff regarding updated calls not being received by the SSC.
i) To ensure that any calls passed to the SSC are passed in a timely manner. The exact timings
will be defined in the final version of this document. The timings will be a vary according
to the total time allowed for resolution of the problem in the contract between ICL
Pathway and the customer. These timings will therefore be dependant on the priority of
the incident, with less time will be allowed for an “A” priority call than will be permitted
for (for example) a “C” priority.
Specific targets for timescales are documented in appendix B of this document.
j) To ensure that the priority of any incident is assessed and recorded correctly.
No calls passed to the SSC whose priority does not conform to the specification
defined in appendix A
k) To ensure that reports are available to the SSC concerning -
i) number of calls received
ii) number of calls passed to SSC by priority
iii) time taken between receipt of the call and transfer to SSC by priority
iv) time between receipt of the call by SSC and the resolution passed back to HSH/SMC
by priority.
COMMERCIAL IN CONFIDENCE Page 8 of 20
ICL
FUJ00119994
FUJ00119994
End to end support process Operational Ref: CS/FSP/o06
Pathway agreement Version: 1.0
Date: 10/10/99
8
4 SSC obligations to HSH/SMC
a) To receive incidents passed from the HSH/SMC
b) To ensure that any incidents so received are maintained on the call management system
used by ICL Pathway (PinICL). Where updates are made to the calls which are of relevance
to the HSH/SMC, then the SSC will ensure that these updates reach the Powerhelp system.
c
To ensure that the incident reported is correctly resolved and the resolution recorded on
the PinICL system and the incident and resolution passed back to the HSH/SMC call
management system (Powerhelp). The resolution should include a full explanation of the
problem and the action taken to resolve it, be this a workround or a code change, or other
action.
No complaints regarding incorrect diagnosis of problems from HSH/SMC
No complaints regarding calls closed on PinICL not subsequently transferred back
to Powerhelp.
d) To ensure that the incident is resolved within the total time allowed by the contract
between the customer and ICL Pathway.
No complaints from the HSH regarding late resolution of problems, no invocation of
penalty clauses by the customer because of slow resolution of incidents.
e) To ensure that the HSH/SMC is made aware of the evidence requirements for any form of
incident and that this documentation is fully maintained.
No complaints from the HSH/SMC that they did not know the evidence required to
be collected for any call. A specific exception to this would be the situation in which
a completely new type of call was received, causing the SSC to update the relevant
documetation.
f) To create and maintain a register of known deficiencies with the Pathway solution, and the
resolution for these problems (where known), and to allow access to this register to
HSH/SMC so that they can fullfill the function of filtering known errors.
“known error” system to be created and populated by December 1997 with access
provided to all of the support community.
To ensure that any resolutions or workrounds that are passed to the SMC have been tested
and have been correctly authorised via the Release Authorisation process.
No untested workrounds or resolutions to be passed from SSC to HSH/SMC.
The exception to this rule would be the case where resolutions are being passed to
the SMC specifically to be down-loaded to the Pathway rigs for testing prior to
general release.
COMMERCIAL IN CONFIDENCE Page 9 of 20
FUJ00119994
FUJ00119994
ICL End to end support process Operational Ref: CS/FSP/o06
Pathwa agreement Version: 1.0
Y 9 Date: 10/10/99
h) To ensure that the HSH/SMC is supplied with documentation relating to new releases of
the Pathway solution in sufficient time to enable HSH/SMC staff to become familiar with
the product prior to its release.
HSH/SMC to be supplied with such documentation for any release prior to MOR for
that product release.
i) To ensure that for any incident which has been resolved and passed back to the Powerhelp
system, the customer has been contacted and made aware of the closure.
No complaints from HSH/SMC to SSC regarding failure to ensure customer
agreement with the closure of an incident.
j) To hold workshops and skills transfer sessions relating to technical aspects of the Pathway
solution and diagnostic techniques.
No complaints from HSH/SMC with regard to lack of technical training where this
training could have been supplied by the SSC.
k) To ensure that the following figures are available to the HSH/SMC on demand.
i) Number of calls currently outstanding at the SSC by priority
ii) Number of calls where resolution has been deferred to the next release
iii) Number of calls against age in the SSC or 4'” line support units.
COMMERCIAL IN CONFIDENCE Page 10 of 20
FUJ00119994
FUJ00119994
ICL End to end support process Operational Ref: CS/FSP/o06
Pathwa agreement Version: 1.0
Y 9 Date: 10/10/99
5 SSC Obligations to 4" line support
a) To ensure that all calls passed to 4" line are logged on a call management system
(currently PinICL)
b) To “filter” all calls for which the problem is already known to the support community and
for which a resolution is already known or has been generated. This includes problems for
which a resolution is known to the SSC but not yet incorporated into the known
deficiencies register available to HSH/SMC.
No calls passed to 4'" line support which are subsequently identified as known
errors, except in cases where the resolution was known to 4" line, but this
information had not been passed to the SSC.
c) To retain in the PinICL system, under the SSC “stack” duplicate incidents - i.e. incidents
which are repetitions of an incident which has already been passed to the 4"" line support,
and to ensure that when the resolved incident is received by the SSC, the duplicated calls
are closed. Under normal circumstances, where a duplicate incident is identified by the
SSC, this will be reported back to the HSH/SMC and closed as a duplicate incident on
PinICL.
No duplicated incidents passed 4" line support.
d) To ensure that the correct evidence for any problem is collected prior to the incident being
passed to 4"" line support for investigation. Where appropriate, this should also contain the
method of recreation of the problem.
No calls rejected by 4" line support on the basis that the evidence was inadequate.
Specifically excluded from this measure are instances where, although the evidence
was inadequate, 4'" line support had not indicated to the SSC the evidence that
would be required for such an incident.
e) To ensure that any incident which requires investigation by 4'” line support is assigned to
the correct PinICL team dependant on the specific product in which the incident has
occurred.
No calls misrouted because of incorrect assignment by SSC
f) To ensure that if there are any updates made to incidents passed to the SSC, then these are
sent to the 4"" line support units in the same manner as e).
No cases of incident updates received by the SSC not being passed to 4"" line support.
g) To ensure that any calls passed to 4'" line support units are passed in a timely manner. The
exact timings will be defined in the final version of this document. The timings will be a
vary according to the total time allowed for resolution of the problem in the contract
between ICL Pathway and the customer. These timings will therefore be dependant on the
COMMERCIAL IN CONFIDENCE Page u1 of 20
FUJ00119994
FUJ00119994
ICL End to end support process Operational Ref: CS/FSP/o06
Pathwa agreement Version: 1.0
Y 9 Date: 10/10/99
priority of the incident, with (for example) less time allowed for an
will be permitted for a“C” priority.
priority call than
Specific targets for timescales are documented in appendix B of this document.
COMMERCIAL IN CONFIDENCE Page 12 of 20
FUJ00119994
FUJ00119994
ICL End to end support process Operational Ref: CS/FSP/o06
Pathwa agreement Version: 1.0
Y 9 Date: 10/10/99
h) To ensure that the priority of any incident is assessed and recorded correctly.
No calls passed to 4'" line support whose priority does not conform to the
specification defined in appendix A
i) To “filter” all calls for which the problem is not one of the following -
i) software error
ii) documentation error.
No calls passed from the SSC to 4"" line units to be subsequently resolved as anything
other than software errors or documentation issues.
j) To ensure that for any incident passed to 4" line support, the exact area of the problem has
been identified, and wherever possible a workround already produced and passed to the
release authorisation process.
No cases identified by 4‘ line support staff of inadequate diagnosis by SSC
k) To ensure that for any code error a probable solution is indicated prior to passing to 4" line
support, and wherever possible, the possible solution has undergone limited testing.
1) For areas of the Pathway solution where the product has “matured”, i.e. no further releases
of the product are expected, accept full responsibility for the product (including 4" line
support and responsibility for the production of any code required to resolve incidents).
m) To create and maintain a register of known deficiencies with the Pathway solution, and the
resolution for these problems (where known), and to allow access to this register to 4‘* line
units so that they can enter details of resolutions created within their area
“known error” system to be created and populated by the SSC with access provided
to all of the support community.
n) To ensure that for any incident which has been resolved and passed back to the SSC , the
customer has been contacted and made aware of the closure.
No instances of the SSC failing to ensure customer agreement with the closure of an
incident.
COMMERCIAL IN CONFIDENCE Page 13 of 20
ICL
FUJ00119994
FUJ00119994
End to end support process Operational Ref: CS/FSP/o06
Pathway agreement Version: 1.0
Date: 10/10/99
6 4" line support obligations to SSC
a) To receive incidents passed from the SSC
b) To ensure that any incidents so received are maintained on the call management system
used by ICL Pathway (PinICL).
No cases of lack of updates on incidents on PinICL.
c) To ensure that the incident reported is correctly resolved and the resolution recorded on
the PinICL system and the incident and resolution passed back to the SSC. Where
appropriate, this should also contain the method of recreation of the problem.
No cases of incorrect diagnosis of problems from SSC staff
d) To ensure that the incident is resolved within the total time allowed by the contract
between the customer and ICL Pathway.
No complaints from the HSH regarding late resolution of problems, no invocation of
penalty clauses by the customer because of slow resolution of incidents.
Specific targets for timescales are documented in appendix B of this document.
e) To ensure that the SSC is made aware of the evidence requirements for any form of
incident, This will be documented by the SSC and maintained in accordance with the SSC
obligations to HSH/SMC.
No cases to arise of SSC not knowing the evidence required to be collected for any
call. A specific exception to this would be the situation in which a completely new
type of call was received, causing the SSC to update the relevant documentation
following specification of the evidence from 4" line support.
f) To enter resolution information into the known deficiencies register maintained by the
ssc.
No discrepancy to arise between the known resolutions for problems and those
which are documented on the known error system.
To ensure that any resolutions or workrounds that are passed to the SSC have been tested
and have been correctly authorised via the Release Authorisation process.
a
No untested workrounds or resolutions to be passed to SSC from 4‘* line support.
The exception to this would be the situation in which 4" line support requested the
SSC to test and report back ona resolution.
COMMERCIAL IN CONFIDENCE Page 14 of 20
ICL
FU.
End to end support process Operational Ref: CS/FSP/o06
Pathway agreement Version: 1.0
Date: 10/10/99
h) To ensure that the SSC is supplied with documentation relating to new releases of the
Pathway solution in sufficient time to enable SSC staff to become familiar with the product
prior to its release, and in sufficient time to enable the SSC to adequately train HSH/SMC
staff. The SSC preference for this documentation would be a support guide. An outline
description of the contents of a support guide is given in Appendix C
SSC to be supplied with such documentation for any release at least 3 weeks prior to
MOR for that product release, and preferably as a continual process during the
course of development.
To ensure that the SSC is supplied with access to source code developed within Pathway
development (with the exception of Riposte).
All source code for a release to be made available to the SSC prior to the MOR for
that release of the product, with final versions being made available prior to MOT.
j) To ensure that where a “mature” product is being passed to the SSC for the SSC to accept
full responsibilty, documentation, source code, and training are made available to the SSC.
FUJ00119994
IJ00119994
COMMERCIAL IN CONFIDENCE Page 15 of 20
FUJ00119994
FUJ00119994
ICL End to end support process Operational Ref: CS/FSP/o06
Pathwa agreement Version: 1.0
Y 9 Date: 10/10/99
Appendix A Definition of call priorities
A- BUSINESS STOPPED, a Post Office down, unable to process any
business, or central system failure which will result in a number of
Post Offices being unable to process work.
B- BUSINESS RESTRICTED, a Post Office restricted in its ability to
transact business, e.g. one counter down.
C- NON-CRITICAL, a Post Office working normally but with a known
disability, e.g. an interim solution (workround) has been provided.
D- INTERNAL, an internal HSH/SMC problem, e.g. a help desk PC or a
phone set inoperable.
COMMERCIAL IN CONFIDENCE Page 16 of 20
FUJ00119994
FUJ00119994
ICL End to end support process Operational Ref: CS/FSP/006
Pathway agreement Version: 1.0
Date: 10/10/99
Appendix B Definition of time allowed for calls
within the support community.
The commitment to the customer with regard to resolving software calls is as
follows -
A Priority - 2 working days
B Priority - 4 working days
C Priority - 7 working days
D Priority - 28 working days
It is expected that although calls may enter the SSC at high priority, in the
majority of cases the SSC will produce a workround for the problem, and at this
stage the priority of the call will be reduced in order to provide 4" line support
with sufficient time to seek a code resolution.
Since it is incumbent upon the SSC to produce a workround, and on 4" line
support units to produce the final code solution to any software problem, for
the majority of its “life” any incident should be with those units.
The target times within each line of support for each call therefore should be...
A priority
HSH / SMC to be transferred to SSC not later than 0.5 hour after
being logged
ssc to be transferred to 4‘ line not later than 1 working
day after initial logging
4" line to resolve not later than 2 working days after initial
logging.
COMMERCIAL IN CONFIDENCE Page 17 of 20
ICL End to end support process Operational Ref:
CS/FSP/o06
Version: 1.0
Pathway agreement Date. 10/10/99
B priority
HSH / SMC to be transferred to SSC not later than 1 hour after
being logged.
ssc to be transferred to 4" line not later than 2 working
days after initial logging
4" line to resolve not later than 4 working days after initial
logging.
C priority
HSH /SMC to be transferred to SSC not later than 2 hours after
being logged.
ssc to be transferred to 4" line not later than 3 working
days after initial logging
4" line to resolve not later than 7 working days after initial
logging. If a workround has been generated for the
problem, then this may be deferred to the next release
of the software if agreed with the customer.
D priority
HSH / SMC to be transferred to SSC not later than 4 hours after
being logged.
SSC to be transferred to 4" line not later than 14 working
days after initial logging
4" line to resolve not later than 28 working days after initial
logging. If a workround has been generated for the
problem, then this may be deferred to the next release
of the software if agreed with the customer.
COMMERCIAL IN CONFIDENCE
Page 18 of 20
FUJ00119994
FUJ00119994
FUJ00119994
FUJ00119994
ICL End to end support process Operational Ref: CS/FSP/o06
Pathwa agreement Version: 1.0
Y 9 Date: 10/10/99
AppendixC Outline definition of the contents of a
support guide
a) Outline of the purpose of the product
- function
- the way in which it performs the function
- outline of the code standards used, and the language used
b) Code paths
- which procedures call which other procedures
- what parameters are passed, and what the procedures do.
- what is output from each procedure
c) Errors
- what errors the software can produce
- which procedures produce them
- what events/activities cause them to be produced
- what to do about them when they are produced.
- list of known deficiencies in the product
- expected clearance dates for known deficiencies
- workrounds in place to overcome known deficiencies.
d) Messages
- where a product uses an internal message format then
details of the message format and examples of decoding these
COMMERCIAL IN CONFIDENCE Page 19 of 20
FUJ00119994
FUJ00119994
ICL End to end support process Operational Ref: CS/FSP/o06
Pathwa agreement Version: 1.0
Y 9 Date: 10/10/99
e) API
- Either in the support guide or as a separate document
- details of all of the functions that can be called
- what they do
- what parameters can be passed to them
- what the parameters mean
- what options/defaults for each parameter
- what is output from these functions
f) Support route
- How to contact support
- what hours they work
- what level of service is offered
- expected clearance timescales for problems of different severities
COMMERCIAL IN CONFIDENCE Page 20 of 20