ICL Pathway
FUJ00232464
FUJ00232464
ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 9/1/2001
Document Title:
Document Type:
Release:
Abstract:
Document Status:
Author & Dept:
Contributors:
Reviewed By:
Comments By:
Comments To:
Distribution:
ICL Pathway / PON Interface Agreement for Operational
Business Change - Product
Interface Agreement
CSR+ with CSR
This agreement defines for CSR+ with CSR the requirement,
the service solution and the obligations of PON and ICL
Pathway for delivering Operational Business Change —
Product.
Authorised
David Wilcox, John Wright ICL Pathway Customer Service
Stephen Muchow Nick Embling
Martin Riddell David Anders
John Wright Dave Ireland
David Wilcox Andy Corbett
Bernadette O'Donnell
Document Controller & Author
ICL Pathway Library,
people who require approved versions only,
Horizon Library
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 1 of 55
FUJ00232464
FUJ00232464
ICL Pathway ICL Pathway / PON Interface Agreement for _—Ref: CS/PRD/058
Operational Business Change - Product
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 9/1/2001
0.0 Document Control
0.1 Document History
ersion {Date [Reason for Issue Associated
INo. (CCN No.
0.1 09/02/99 First Draft
(0.2 18/02/99 Second Draft — supersedes first draft
10.3 22/03/99 Third Draft — incorporates comments from
Alison Peacock and David Fletcher
(0.4 23/03/99 Fourth Draft — incorporates changes from
David Wilcox
10.5 31/03/99 Fifth draft — correction to section numbering
and other comments
10.6 23/04/99 Sixth draft — following comments from PON as
discussed with Geoff Darby.
(0.7 25/05/99 To include changes proposed in the PON/ICL
Pathway meeting of the 30/4/99 and the
acceptance review meeting of the 25/5/99. To
include comments following ICL Pathway
commercial review.
0.8 18/06/99 To include changes proposed in the PON/ICL
Pathway acceptance review meeting of
9/6/99.
1.0 25/06/99 Baseline version
1.4 07/07/99 Incorporate comments from PON and
Pathway
2.0 08/07/99 Updated baseline CCN 496a
2.1 29/07/99 Incorporated comments from PON following
rejection of CCN 496a
2.2 23/08/99 Incorporated comments from PON / ICL
Pathway review meeting of 5/8/99.
2.3 27/08/99 Incorporated comments from PON (David
Anders) review of 25/8/99.
Amended elements in line with proposed
method of product removal
2.4 14/09/99 Identification that the maximum volume of
change could be agreed outside of this
document.
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 2 of 55
FUJ00232464
FUJ00232464
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 9/1/2001
[THIS DOCUMENT WAS FORMALLY WITHDRAWN BY ICL PATHWAY
2.5 03/12/99 Re-issued following significant ICL Pathway /
PON discussions.
2.6 22/12/99 Reviewed after PON / ICL Pathway meeting
on 20/12/99.
2.7 05/01/00 Changed to include ICL Pathway commercial
comments.
2.8 11/01/00 Changes following PON /ICL Pathway review
on the 10/1/2000
2.9 13/01/00 Changes following PON.ICL Pathway review
on 13/1/2000
13.0 20/01/00 Updated baseline. CCN 496b
13.1 09/05/00 Updated for CSR+
All references to POCL replaced by PON.
Cross-references to RDCC section numbers
deleted.
3.2 15/06/00 Updated following comments from PON
3.3 02/07/00 Updated following meeting with PON
3.4 30/08/00 Updated following meeting with PON
3.5 28/11/00 Updated following meeting with PON
4.0 11/12/00 Updated baseline
5.0 9/1/2001 Updated baseline following comments from
PON
0.2 Approval Authorities
Name [Position ignature [Date
Stephen Muchow ICL Pathway
(Customer Service
Director
[Harvey Skipsey IPON Head of
Business Service
Management
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 3 of 55
FUJ00232464
FUJ00232464
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 9/1/2001
0.3 Associated Documents
Please see library for details of latest versions of documents.
IReference Vers [Date Title Source
1. ICS/PRD/030 3.0 27/10/00 IProcess for Operational Business Change -/ICL
Product Pathway
2. ICS/IFS/001 2.2 27/8/99 IReference Data Change Catalogue ICL
Pathway
3. AP/PRD/001 1.4 16/08/99 APS Client Take-On process ICL
Pathway
4. ICR/FSP/016 2.1 [28/06/00 IAPS Token Verification Service Description IICL
L NR2 Pathway
5. IRDP/AIS/001 3.3 02/02/98 AIS Reference Data to Pathway Type A IPPON
[Data (CSR)
6. IRDP/AIS/001 4.4 [21/01/00 IAIS Reference Data to Pathway Type A PON
Data (CSR+)
7. IRDP/AIS/008 (0.2 23/12/98 AIS Reference Data to Pathway Type B PON
[Data (CSR)
8. IRDP/AIS/008 4.3A {01/10/99 IAIS Reference Data to Pathway Type B PON
[Data (CSR+)
9. ICS/PRD/048 1.0 I23/6/99 _IChanging Reference Data to Tight ICL
[Timescales Pathway
10. ICS/IFS/002 1.0 (01/10/98 Reference Data Change Class 1 Analysis {ICL
Pathway
44. ICS/IFS/003 3.0 19/07/99 {ICL Pathway / PON Interface Agreement forIICL
(Operational Business Change — Outlet Pathway
12. IRDS/OLA/001 1.0 = {26/3/99 IReference Data - PON / ICL Pathway PON
(Operational Level Agreement
13. PON/OSG/OLA/ (2.0 (6/12/00 IPON OSG / ICL Pathway Operational Level PON
(001 [Agreement
14. IOSG/OPS/001 1.1 14/01/00 Operational Business Change Product PON
erification Procedures
15. IRD/TEC/951 1.4 28/07/00 IReference Data Rules and Values IPON+
ICL.
Pathway
16. ICS/POL/006 0.1 Service Management Framework Part A ICL
Pathway
17. (Counter News Review Process
18. ICS/PRD/077 2.0 17/11/00 Reference Data Alert Process CL
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 4 of 55
FUJ00232464
FUJ00232464
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 9/1/2001
Pathway
19. ICS/PRD/O28 [1.3 (6/5/99 [Process for Changing Menu Hierarchies IICL
land Icons [Pathway
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 5 of 55
FUJ00232464
FUJ00232464
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 9/1/2001
0.4 Abbreviations/Definitions
The text in the remainder of this document uses the abbreviations and definitions
shown below. They are not intended to be definitive in any other contractual
context.
scious Definition
(Advanced IBusiness changes available through the OBC processes that require a
Change notice of change to be delivered to ICL Pathway before implementation.
IThey may or may not be supported by Reference Data files from PON.
(Advanced Changes can be subdivided into Complex, Standard, Simple or
IAP. [see sections 3.1 and 4].
(Adow (Any day of the week, as opposed to working weekdays.
Advanced (Change that requires advance notice to be given to ICL Pathway in order
(Complex for Type C Reference Data to be created.
Change
Advanced (Change that requires advanced notice to be given to ICL Pathway, where
Simple Change {the additional activities required can be carried out after the OBC has
lbeen released and therefore do not extend the lead-time for that OBC.
Advanced (Change that requires advanced notice to be given to ICL Pathway, where
Standard [the additional activities required do extend the lead-time for that OBC, but
(Change ithe change does not require Type C Reference Data.
After the event IChanges which need to be made to complete an OBC, but are not
changes Ineeded before the release of the OBC e.g. documentation updates.
Agreed Date here the Start Date or Required Date are invalid or cannot be met an
alternative date will be agreed between PON and ICL Pathway.
Amendment file IA file containing records changing previously received Reference Data
hich is still being processed — must be released with the original file.
(AP (Automated Payments
(Authorisation IA document that is sent from PON to ICL Pathway to say the following for
Form ithe named OBC.
le The Verification Report has been checked.
le The Verification Counters have been tested and:
> The Identity and Name of the Business Test performed to verify
the changes,
> The Date and Time the Business Test was conducted,
> The Name of the person who conducted the Business Test,
> The Conclusion of the Business Test, whether Pass or Fail,
e If Fail, the Failure Reason and Mitigating Action
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 6 of 55
FUJ00232464
FUJ00232464
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 9/1/2001
e If Pass, indicate whether the Comparison Report had been
checked Yes or No.
IThe form provides the notice of authorisation.
(Authorisation [The Authorisation process results in ICL Pathway being directed by PON
[to implement in the live estate those authorised Reference Data changes
Ithat are covered by the notice of authorisation.
(Authorisation is an assertion by PON that they have diligently and
conscientiously performed the specified [ref. 14] Business Tests, and that
ithin the bounds of the specified tests the results indicate that the effects!
lof the authorised Reference Data change is the effect that PON intended.
ICL Pathway is responsible for ensuring that all other effects on the
isystem are consistent with the stated requirement.
Each party accepts responsibility for those aspects of a change for which
lit has responsibility to test.
IThe notice of authorisation shall be communicated via an Authorisation
Form.
Authorised ‘An OBC which has passed through the Authorisation process and has
(Change lbeen authorised.
[Basic Change __IChanges available through the OBC processes that DO NOT require a
notice of change to be delivered to ICL Pathway. Currently Basic
(Changes always consist of Class 1 Reference Data.
BAU Business As Usual. Processes within PON that occur regardless of
hether the Horizon system is in use.
BCR Business Change Request (referred to in PON as “Change Control
Number”). A unique identification number for an OBC.
IBSM Business Service Management — includes the unit currently known as
[OSG (Outlet Systems Group).
[Business Tests [Tests used by PON to ensure a change seen on the Verification Counter
land/or described in the Verification and Comparison reports meets the
requirement.
Where Business Tests fail to identify problems that were apparent at the
time the tests were carried out, the specified tests will be improved by
joint review and change control.
ICCD (Contract Controlled Document
CCN (Change Control Note as defined in the Codified Agreement.
ICCN (Change Control Number (referred to in ICL Pathway as “Business
(Change Request”).
(Change Type __ IFor example, Basic Pure, Advanced Simple, Advanced Complex, AP etc.
Class 1 (Class 1 Reference Data is the subset of data items which have no impact
jon any other part of the Horizon system and changes containing only
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 7 of 55
FUJ00232464
FUJ00232464
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 9/1/2001
(Class 1 Reference Data (Basic Changes) can be implemented by ICL
Pathway without advance notice [see ref. 10]. Class 1 data is subsetted
linto HD, HR and Pure.
(Comparison IThe output from ICL Pathway’s software tool which is used for identifying
[Report ithe changes that have occurred on a Horizon counter. It provides
information to PON for verification purposes.
ICR (Change Request as defined in the Codified Agreement.
ICSR (Core System Release
ICSR+ (Core System Release Plus
(CTO (Client Take-On (AP)
Deviation to the [A single instance of an agreed (by CR) variation to the workload which
service falls outside of specified levels e.g. to volumes or timescales.
[Error A part of a change that does not meet the requirement or specifications,
hether Reference Data definitions, file format, milestones, delivery route
lor other aspect of the OBC processes. (see also Rework)
Error correction IA file containing records for the purpose of correcting errors to previouslyI
ffile received Reference Data which is still being processed-must be released
ith the original file.
Exception IA change that falls outside of the agreed levels e.g. to lead-times or
‘olumes and is not a ‘Deviation to the service’.
IHD (Basic) IReference Data changes are ‘HD’ when the change is relevant in ICL
IPathway only to the HelpDesk e.g. telephone number.
IHFSO [Horizon Field Support Officer
IHR (Basic) Reference Data changes are ‘HR — High Risk’ when verification is
required by PON (but are not subject to advanced notification).
IHSH ICL Pathway Horizon System Helpdesk.
Interface [This document (except where the Interface Agreement for Outlet is
(Agreement specifically referred to, then see [ref. 11]).
Live Fix IA change to Reference Data to correct a Live Incident
Live Incident [The occurrence of an incident, which relates to the live environment and
lis recorded on the ICL Pathway HSH and / or the PON NBSC help desks.
Migration \See section 4.4.2 for the definition.
Special
IMIS Management Information System
INBSC. IPON Network Business Support Centre.
(OBC \Operational Business Change.
(Any change, usually supported by Reference Data changes, that is
implemented through the OBC process e.g. Advance and Basic
Changes, excluding changes specifically required to implement software
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 8 of 55
FUJ00232464
FUJ00232464
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 9/1/2001
changes.
OBC forms Electronic Forms used to interchange information relating to OBCs
between PON and ICL Pathway e.g. OBC 2.
OLA \Operational Level Agreement
IPM Postmaster
IPOCL Post Office Counters Limited — the former name of PON.
IPON Post Office Network - name which supersedes POCL.
IPOUNC. Post Office Users National Council
IPre-authorised IA pre-authorised change is a Reference Data change that by agreement
change [see section 4] does not require verification by PON and can be released
by ICL Pathway without additional notification from PON over and above
Ithe delivery of a conformant file.
Pre-live Incident IThe occurrence of an incident, which is observed during Reference Data
processing and validation before release to the live environment, and is
recorded on an Incident Management System (PinICL) operated by ICL
Pathway.
Product (Changes to the products or appearance of products available through the
(Changes Horizon system implemented wholly or in part, through changes to
Reference Data.
Pure (Basic) hen used in reference to a Reference Data Change ‘Pure’ indicates
[Reference Data which is considered to be of low risk to business integrity.
IPway ICL Pathway
IRDCC. Reference Data Change Catalogue
IRDMC ICL Pathway Reference Data Management Centre
IRDORF Reference Data Operational Review Forum
IRDOT IPON Reference Data Operational Team
IRDP IPON Reference Data Project
IRDS IPON Reference Data System
IRDT ICL Pathway Reference Data Team
[Release Day __ IThe day on which Reference Data is Released to the live system.
[Released to the [Reference Data released by ICL Pathway into the TMS agent. The end
live system point for the process defined in this document. The SLA [see section 3.3]
covers the delivery of Reference Data to the outlets.
IREM Remittance
[Required Date IThe date on the OBC form (Advanced Changes) that specifies when the
change needs to be available at the outlets. Normally this is the same as,
or earlier than, the Start Date. (see also, Agreed Date.)
[Rework Activity required to progress a change when an Error Correction File or
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 9 of 55
FUJ00232464
FUJ00232464
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 9/1/2001
(Amendment File is provided.
IRM ICL Pathway Release Management
Start Date IThe earliest date specified within any record within any file of Reference
Data for a particular OBC. The Start Date is used by the Horizon
counters to determine when the functionality comes into effect. This date
should always be a future date when taking into account lead times.
(see also Agreed Date & Required Date.)
TMS ITransaction Management Service.
[Type A Data transmitted electronically from RDS to RDMC over an automated
interface.
[Type B Data transmitted electronically from RDS to RDMC over a non-automated
interface.
[Type C Data prepared by ICL Pathway.
IUnauthorised [An OBC that has been released to the live environment but has not been
change lauthorised.
[Unit of Release [A combination of files which are intended to be released together. The
smallest is a single file. Where Amendment or Error Correction files are
lapplied to a change in progress the unit of release will be all files)
lassociated with the original OBC.
erification (Confirming that the observed result of the change implemented is the
(Verify) same as that expected and fulfils the requirements of the business.
erification IA non-live Horizon counter provided to PON to which OBCs are applied inI
(Counter lorder for PON to verify the change, before its release to the live estate.
erification IA report produced from the RDMC to show which Reference Data records
[Report lhave changed.
forking 9am to 5pm, Monday to Friday, excluding English Public Holidays.
/eekdays
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 10 of 55
ICL Pathway
FUJ00232464
FUJ00232464
ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 9/1/2001
0.5 Changes in this Version
Version (Changes
3.2 le Additional explanations added regarding CSR+ and CSR
le Minor typographical errors have been corrected
le The section on Interfaces has been reworded for clarity
Je References to ‘Business Unit’ have been changed to ‘Internall
Account Team’
3.3 Je Additional definitions (eg Agreed, Required, & Start Dates, ErrorsI
& Rework)
e Addition of section on future dating, section 7.3
e Clarification of some specific CSR limitations (eg comment on ITMI
in Appendix A)
3.4 le Section 1: Summary
Je Section 2.2: Service Management Policy, re pre-live and live
incidents
le Section 3.4: Process re Counter News and Alert process
le Section 4.2.5: Inclusion of Changing Picklist ordering asI
Advanced Complex change
le Section 5: Lead-time tables
le Appendix A: table
Je Appendix B: volumes
le Various amendments following review with PON
3.5 Je Section 2.1 amended to indicate that this agreement isI
subservient to the contract
le Section 2.4 — Service Management Policy — removed as this is}
now covered in the Service Management Framework
documentation
Je Section 2.5 added — Alerting
e The table from section 4.1 has been removed as it was duplicated!
in the summary in section 1
le Some detail from section 4.2 has been moved to Appendix D
Je Section 9.3.2 — Errors and Rework — amended
4.0 le A number of minor amendments for clarification before release for
approval
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 11 of 55
FUJ00232464
FUJ00232464
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 9/1/2001
5.0 A number of minor typographical amendments observed after
release of version 4
0.6 Changes Expected
(Changes
Removal of References to CSR when all outlets have migrated to CSR+.
Introduction of scope and definition of data entry verification by PON.
The inclusion of Outlet Reference Data, in particular with regard to errors andj
rework
Section 3.3: SLA comment, when Schedule G10 review completed.
Section 3.4: Further amendment to process for the production and
communication of Counter News articles that relate to Reference Data changes.
Section 9.3: Errors and rework and thresholds.
Appendix B: volumes amended to include impact of LFS/SAPADS.
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 12 of 55
FUJ00232464
FUJ00232464
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 9/1/2001
0.7 Table of Contents
1 SUMMARY SHEET...
2 INTRODUCTION...
2.1 INTENT OF AGREEMENT. - . - soon 16
2.2. MAINTENANCE OF THIS AGREEMENT. 16
2.3. FUTURE DEVELOPMENTS. 17
2.4 SERVICE MANAGEMENT POLICY......ccosneennne sstsenannnnnnnennnnnnannnenee . see senianannennenae 17
2.5 ALERTING WHEN DATA IS AT RISK OF LATE DELIVERY. nnn sesenwed 7
3 SCOPE...
3.1 INTERFACES.
3.2. OUTLET CHANGES....
3.3. SLA. .
3.4. OPERATIONAL BUSINESS CHANGE PROCESSES.
3.4.1 Process Diagram
3.4.2 Process Steps..
4 TYPES OF CHANGE...
4.1 INTRODUCTION.
4.2 STANDARD CHANGES.
4.2.1 Be - Pure.
4.2.2 Basic — High Ris
4.2.3. Advanced Simple.......
4.2.4 Advanced Standard...
4.2.5. Advanced Complex.
43 AP...
4.4 FAST-TRACK CHANGES...
4.4.1 Basic Express.
4.4.2 Migration Special.
4.4.3 Tight Timescales.
4.4.4 — Live Fix,
5 LEAD-TIME FOR CHANGE!
5.1 INTRODUCTION...
5.2 BASIC - PURE. ssssennsene
5.3. BASIC — HIGH RISK...
5.4. ADVANCED SIMPLE.
5.5 ADVANCED STANDARD...
5.6 ADVANCED COMPLEX.
5.6.1 Action............
5.7 AP CLIENT TAKE-ON.
5.8 Basic EXPRESS.
5.8.1 Action...
5.9 MIGRATION SPECIAL.
5.9.1 Action........
VOLUME OF CHANG!
a
6.1 INTRODUCTION.
6.2. COMMITTED VOLUMEB........
6.2.1 Peaks in Business Change activity...
DELIVERABLES....
7.1 PON To ICL PATHw.
7.2 ICL Patuway To PON,
Sy)
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 13 of 55
FUJ00232464
FUJ00232464
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 9/1/2001
7.3. FUTURE DATING. a so sen sone 39
8 ROLES & RESPONSIBILITIES...
8.1 PON — GENERAL... senna
8.1.1 Administration and Control.
8.1.2 Implementation......... .
8.1.3 Files & Reference Data...
8.2 PON - REFERENCE DATA OPERATIONAL TEAM....
8.3. PON NETWORK BUSINESS SUPPORT CENTRE (NBSC).
8.4 ICL PATHWAY RESPONSIBILITIES.
8.4.1 Administration and Control.
8.4.2. Implementation...
8.4.3 Files & Reference Data...
8.5 HORIZON SERVICE HELPDESK (HSH)...
8.6 VERIFICATION, AUTHORISATION & RELEASE...
9 ORDERS AND EXCEPTIONS...
9.1 ORDERS.
9.2 EXCEPTIONS....... nee
9.3 ERRORS AND REWORK... .
9.3.1 Recording Pre-Live Incidents.
9.3.2 Rework categorisation and thresholds.
9.4 ESCALATION... ese sess este os sess ose
9.5 CHARGING... ssunnnnnnenennsnesee ests crcraesneee 4B
10 APPENDIX A: REMOVE/CEASE PRODUCT AND ITM’S....
11. APPENDIX B: OBC VOLUMES FOR YEAR 2000........scsseesseee
12. APPE!
IX C: PON BUSINESS TESTS...
13. APPENDIX D: STANDARD CHANGES - DETAILS..
13.1.1 Basic - Pure.
13.1.2 Basic ~ High Ris
13.1.3 Advanced Simple.
13.1.4 Advanced Standara
13.1.5 Advanced Compler....cccccccccscsvesvessceseeses sessiesessesseeseeseseee
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 14 of 55
FUJ00232464
FUJ00232464
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 9/1/2001
1 SUMMARY SHEET
This section summarises the content of this agreement as a “quick reference” guide
to change types. It does not replace the detail contained in the following chapters
(should there be differences, the latter shall prevail).
Note: the Lead-time includes processing within both PON and ICL Pathway, but not
distribution to the outlets.
Change Definition Lead-time
Category (see section 4) (working
weekdays)
Standard: PON Pway —Jfotal
Basic Change - Type A Reference Data only (no PON verification I 4 1 5
Pure required)
Basic Change —_IType A Reference Data only (PON verification is {6 4 10
High Risk — Irequired)
Advanced [Type A Reference Data, plus after-the-event 6 4 10
Simple Change changes
Advanced Type A & Type B Reference Data, MIS change & {9 is) 14
‘Standard Change ICL Pathway testing required
Advanced ComplexChange that requires Type C Reference Data from I14 6 {30
(Change ICL Pathway
AP Change Change required for AP Client Take-On and [see refs. 384]
Token verification.
Fast-track:
Basic Express A subset of Basic HR, for a specific requirement to I1.5 (0.5 [2
change specific Reference Data quickly.
Migration Special IAn addition to the non-core product mappings for anj0.75 {0.25 /1
joutlet, normally where the product is already being
sold prior to migration.
Tight Timescales A change under contractual requirement 539/3, to [Agreed when
make any kind of Reference Data change quickly, injrequested
specified circumstances.
Live Fix A change to correct a live incident. (ref. section Defined in OLAs
4.4.4 and 9.3). (refs. 12 & 13)
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 15 of 55
FU.
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 9/1/2001
2 Introduction
This document is a Contract-Controlled Document (CCD).
2.1 Intent of Agreement
The intent of this Interface Agreement is to establish effective co-operation between
ICL Pathway and PON for the timely efficient and cost effective delivery of
Operational Business Change — Product using Reference Data to Horizon enabled
post office counters.
[DN Aspects of this agreement are also relevant to Outlet Reference Data, e.g.
those sections which cover errors and rework.]
This Agreement identifies:
e PON’s and ICL Pathway’s requirement for Product changes introduced via
Reference Data,
e the agreed end-to-end service solution for ICL Pathway and PON, both
separately and jointly, for implementing such changes and
e the obligations of both parties, both separately and jointly, that must be met in
order to deliver the solution.
There are a number of documents (which are not CCDs) that describe the
interfaces and agreements made between ICL Pathway and PON for the
management of Operational Business Changes. This document provides an
“umbrella” agreement for those others and they will comply with the Agreements
made within this Interface Agreement.
Whilst this Agreement serves as an umbrella for other documentation it cannot
supersede any contractual obligations defined within the Contract schedules. The
timescales shown later in this document are those which are agreed by both parties
to be operationally viable and as such form the basis of normal business practice
when implementing changes to Reference Data.
2.2 Maintenance of this Agreement
This Agreement is applicable to the CSR+ Horizon release with CSR, whilst CSR is
still in use in any outlet. It will be reviewed once CSR is no longer in use and for any
future major software release and on an on-going basis. It is maintained by ICL
Pathway on behalf of both parties.
FUJ00232464
IJ00232464
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 16 of 55
FUJ00232464
FUJ00232464
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 9/1/2001
2.3 Future Developments
PON and ICL Pathway agree to work jointly to improve the quality and effectiveness
of the Reference Data interface as follows:
e Review the functionality, scope and effectiveness of the Reference Data test
environment and enhance where appropriate.
e Continuously monitor the toolset available in the test environment, in particular
the Reference Data comparison tool for identifying impact of planned Reference
Data changes with the possibility of enhancement where appropriate.
« Continuously monitor and where necessary improve the Reference Data Change
Catalogue (RDCC) relating to Reference Data requirements.
e Review the consolidated set of Business Rules and procedures which have been
jointly developed and implemented.
¢ Continuously improve the scope and effectiveness of Business and System tests.
The programme for delivery of each of the above will be overseen by the RDORF.
2.4 Service Management Policy
Service Management Policy is described in [ref 16]
2.5 Alerting when data is at risk of late delivery
When it is known that Reference Data may be at risk of non delivery by the time it is
required at outlets an Alert may be required. The detail of the Alert Process is
described in [ref 18].
The principles of the Alert Process with respect to data being delivered overnight to
become active at outlets the following day are:
¢ to provide warning to relevant parties in PON and ICL Pathway, that there
is risk of critical reference data not being available at outlets the following
day
e to allow appropriate contingency to be invoked against that risk where lack
of the data would cause critical problems
The process may similarly be invoked if the final milestone is know to be at risk (see
section 9.3)
The process is initially invoked by PON setting the Alert Flag on the Release
Authorisation Form. If the Release Day is the day prior to the Start Date, and the
Alert Flag is set, RDT will initiate the warning process.
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 17 of 55
FUJ00232464
FUJ00232464
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 9/1/2001
3 Scope
3.1 Interfaces
This Agreement covers all the interfaces between ICL Pathway and PON that
support the Operational Business Change process for pre-defined product changes
for release CSR+ of the Horizon system and for release CSR, until such time as all
outlets have migrated to CSR+.
The majority of detail within this document is applicable from the time when the
interface between the PON RDS system and ICL Pathway RDMC is using the
Application Interface Specification for CSR+. However, certain CSR+ functionality
will not be available at individual outlets until the outlet has migrated to CSR+ .
Whilst Reference Data is sent to all outlets, as appropriate, some of this data will
only be usable at an outlet when that outlet has migrated to CSR+ (e.g. Logistics
Inventory and Accounting items ). There are also other functions which should not
be used until ALL Horizon outlets have migrated to CSR+ (e.g. removal of non-core
links from outlets causing the graceful termination of a product at the specified
outlet).
Interface Interface Interface
I PON Pathway Pathway PON Pathway
process process I process I process * I process I
* this step is not
needed if change is
pre-authorised
The start is the point where an OBC form has been completed and issued within
PON, and the end point is where the Reference Data has been released within ICL
Pathway for delivery to the live counters.
The delivery of the Reference Data to counters, following release authorisation, is
covered by the SLA [see section3.3].
It applies to both Advanced and Basic Product Changes where:
e a Basic Change is a change which consists solely of Reference Data which
requires no additional ICL Pathway actions and may be submitted to ICL
Pathway without notice
« an Advanced Change is a change which requires additional ICL Pathway activity
and is subject to advanced notification.
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 18 of 55
FUJ00232464
FUJ00232464
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 9/1/2001
3.2 Outlet Changes
This Interface Agreement does not cover Reference Data for Outlet Change [see ref.
11].
[DN: Refer to statement in section 2.1]
3.3 SLA
The contractual provisions relating to the distribution of Reference Data are defined
in the SLA in Schedule G10 of the contract.
[DN. The wording of G10 is under review between PON and ICL Pathway]
3.4 Operational Business Change processes
The Operational Business Change (OBC) process for product change is defined in
[ref. 1] and the types of change that qualify for the OBC process are defined in the
Reference Data Change Catalogue (RDCC) [ref. 2]. Changes not found in the
RDCC must be requested via the normal Change Control mechanism (CR/CCN).
A summary of the process is given below.
Note:
Not every Change Type follows every step of the process [see section 5].
The timescales for each stage of the process are defined in [section 5].
The types of change that the process applies to are defined in [section 4].
The responsibilities of each party are defined in [section 8].
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 19 of 55
FUJ00232464
FUJ00232464
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 9/1/2001
3.4.1 Process Diagram
Note: feedback loops exist at all stages for error correction, but are not shown,
OBC OBC
request request
Counter News
& Physical
stock ete
Counter News
ete
Unauthorised
“Pre-live”
Authorised
“Live”
Data
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 20 of 55
ICL Pathway
FUJ00232464
FUJ00232464
ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 9/1/2001
3.4.2 Process Steps
Step [Taken by Description
A IEventA- [PON Internal {Internal Account Management in PON identify the
Identify Account business need to change details for or to introduce orI
Ichange Management _ to withdraw a product.
[Team
1 [Take actions
to implement
ithe changes
PON Internal
Account
Management
Team
Internal Account Management in PON identify if the
change is a Basic Reference Data change, or an
(Advanced OBC change.
[The relevant Internal Account Management Team
raise the required OBC forms to:
e Request PON Reference Data Operations Team
(RDOT) to change the Reference Data (for both
Basic and Advanced Changes)
e and to request BSM to request an OBC —Product
Change from ICL Pathway (for Advanced
Changes).
BSM confirm the change requested is an Advanced
OBC change and request ICL Pathway to make the
change.
BSM supply any required additional information to
support the Advanced OBC change.
PON ensure that all necessary communications and
supporting actions for the OBC are complete.
2 IUpdate Ref.
Data system
\& send to
Pathway
PON RDOT
IPON Reference Data Operations Team changes the
[Reference Data to meet the OBC requested and
isend it to ICL Pathway and other users within PON.
3 IGenerate
Change and
jtest where
Inecessary
ICL Pathway
ICL Pathway receives the Reference Data from
IRDOT (for all changes) and receives the OBC form
land necessary additional information from BSM (for
(Advanced Changes).
ICL Pathway initiates any required internal actions
le.g. ensure Reference Data is appropriate for the
OBC requested as defined in the RDCC [ref. 2],
generate Type C Reference Data, test changes.
Changes are tested and validated by ICL Pathway
here necessary.
© 2001 ICL Pathway Limited
COMMERCIAL IN CONFIDENCE Page: 21 of 55
FUJ00232464
FUJ00232464
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 9/1/2001
ICL Pathway generates and delivers the RDMC
\Verification Report and the Comparison Report to
IBSM and delivers the actual Reference Data change
‘0 the verification counters, as appropriate.
INote: ICL Pathway does not send Pure Basic and
[Migration Special Changes to BSM for authorisation,
las they are pre-authorised by PON.
4 \Verify & PON Internal IBSM verifies the OBCs on the counter / reports (as
lauthorise Account lappropriate) and confirms the change as delivered is
completed IManagement_ {the change required, and authorises the release of
Ichange [Team he OBC to the live estate.
IBSM also sets the Alert flag on the Authorisation
Form, when appropriate. (see section 2.5)
I Review ICL Pathway ICL Pathway reviews, and responds to, all relevant
(Counter (Counter News or other Horizon update articles beforeI
News publication and distribution (when required) to
larticles confirm that the contents correctly reflect the system
land will not have an unnecessary impact on helpdesk
resources. PON shall accept all amendments
reasonably requested by ICL Pathway in pursuit of
he delivery of contractual services.
[The process is described in [ref 17]
DN: this process is still under discussion
6 IChange ICL Pathway ICL Pathway releases Reference Data for all
delivered to lauthorised OBCs to the live estate.
counters ICL Pathway will raise Delivery Alert on the Release
Day, if the Alert Flag is set and the change is to be
effective next day. (see section 2.5)
Where agreed with PON, the release may be held
pending communication to the Outlets e.g. via
(Counter News. (However if release delay risks the
Start Date, there may need to be another change
lprocessed).
4 Types of Change
4.1 Introduction
Change types are pre-defined for inclusion into the OBC — product process. This
definition can be found in the Reference Data Change Catalogue (RDCC) [ref. 2].
Each pre-defined change type is grouped as shown in the table in section 1.
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 22 of 55
FUJ00232464
FUJ00232464
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 9/1/2001
The RDCC Product Change categories that apply to these changes are listed in
[sections 4.2 and 4.4] below. The assumptions listed in the RDCC must be adhered
to, in order to apply these categorisations.
4.2 Standard Changes
The order of the change types in this section is significant and is an indication of the
level of risk with each type and therefore the amount of checking that is deemed to
be necessary. The change types are in order of increasing risk from those which
need little or no checking, as the effect of an error would be minimal on the Live
estate, to those which need extensive checking, as the effect of an error may be
significant on the Live estate. Those changes, which are deemed to require minimal
or no checking, are classified as Basic - Pure. Those changes, which are deemed
to require most checking, are classified as Advanced - Complex.
A complete list of changes applicable to each type is held within the RDCC. Should
PON decide that additional checking is required, a change may be submitted in a
type with a higher risk position in this section. However the converse is not true, in
that a change can never be requested with a lower risk position than the type shown
in the RDCC.
Appendix D shows a representative list of the changes for each type.
4.2.1 Basic - Pure
Basic Changes do not require advanced notification from PON to ICL Pathway (OBC
form). The delivery of the Reference Data file using agreed mechanisms [see
section 0.3] is the request for change. The file must identify that its contents are
Basic Pure changes. The file may contain more than one change of the same type.
All Basic files contain only Class 1 Reference Data items. ICL Pathway checks the
contents of the file are appropriate for the type of change. Pure changes do not
require verification and are pre-authorised for release.
4.2.2 Basic — High Risk
Basic Changes do not require advanced notification from PON to ICL Pathway (OBC
form). The delivery of the Reference Data file using agreed mechanisms [see
section 0.3] is the request for change. The file must identify that its contents are a
Basic High Risk change. The file may contain more than one change of the same
type. All Basic files contain only Class 1 Reference Data items. ICL Pathway checks
the contents of the file are appropriate for the type of change. High Risk changes
require a Verification and a Comparison report and authorisation by PON before
release.
4.2.3. Advanced Simple
Advanced Simple changes require advanced notification from PON to ICL Pathway
(an OBC form) to request the change. Associated Reference Data files must be
identifiable as such through the BCR number. ICL Pathway checks the contents of
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 23 of 55
FUJ00232464
FUJ00232464
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 9/1/2001
the file are appropriate for this type of change. ICL Pathway has actions to take to
implement the change (in addition to processing the Type A Reference Data file
from PON) e.g. update documentation, but these actions can occur after the change
has been released and therefore do not extend the lead-time for the change. These
changes require a Verification and a Comparison report and authorisation by PON
before release.
4.2.4 Advanced Standard
Advanced Standard changes require advanced notification from PON to ICL
Pathway (an OBC form) to request the change. Associated Reference Data files
must be identifiable as such through the BCR number. ICL Pathway checks the
contents of the file are appropriate for this type of change. ICL Pathway has actions
to take to implement the change (in addition to processing the Type A Reference
Data file from PON) e.g. process Type B files, and these actions must occur before
the change has been released, therefore the lead-times are longer than for Simple
or Basic changes. These changes require a Verification and a Comparison report
and authorisation by PON before release.
4.2.5 Advanced Complex
Advanced Complex changes require advanced notification from PON to ICL
Pathway (an OBC form) to request the change. Associated Reference Data files
must be identifiable as such through the BCR number. ICL Pathway checks the
contents of the file are appropriate for this type of change. ICL Pathway must
generate Type C Reference Data to implement the change and test that the change
works as requested in the OBC form. These changes require a Verification and a
Comparison report and authorisation by PON before release.
4.3 AP
AP changes are similar to Advanced Complex changes and require notification from
PON to ICL Pathway (an OBC form) to request the change. Associated Reference
Data files must be identifiable as such through the BCR number. ICL Pathway
checks the contents of the file are appropriate for this type of change. ICL Pathway
has actions to take to implement the change e.g. test Tokens and supply test files to
HAPS (or the appropriate PON Client) for PON End to End testing of changes.
These changes require a Verification and a Comparison report, additional testing
and authorisation by PON before release.
(as described in AP CTO & Token Verification documents)
Introduce new AP client, service or token
Change client name (new token data)
Cease AP Client, product or token
Introduce new Smart Card
Notes on AP change:
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 24 of 55
FUJ00232464
FUJ00232464
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 9/1/2001
e Changing AP product details is treated the same way as changing EPOSS
products.
e Ceasing AP Client, product or token may be implemented as an Advanced
Simple change if required, with the client service list being amended after the
event.
4.4 Fast-track changes
4.4.1 Basic Express
A Basic Express change is a subset of Basic High Risk changes and must comply
with the definitions in [section 4.2.1]. However, the lead-times [see section 5]
specified for a Basic Express change can only be achieved where verification can
be performed on the basis of the Verification Report and not a Comparison Report.
The type of change must be such that there is minimal risk of error occurring
elsewhere within the system as a result of applying the change and is therefore
limited to:
Change price of non-value stock
Change price of revaluable value stock *
Change min/max quantity/value
Change Long/ Medium / Short name
The limits for use are:
only for the categories of change which conform to the above e.g. ‘Ticket
and Travel’ products or to meet the requirement for Tight Timescales
only OBCs that must be active on completion of the change within 48hrs
OBCs must be received by BSM/OSG by 10am on a working weekday and
only normal volumes of change as defined in [section 6]
the Change Number must start with defined prefixes [ref. 15]. If a Change
is delivered to ICL Pathway with this prefix but the contents do not meet
the specified criteria it will be processed according to the normal lead-
times. ICL Pathway will inform PON using the incident process.
oocoefo
* Note: When a Basic High Risk change is to change the price of revaluable value
stock, Horizon counters will prompt counter staff on each of the three days prior
to when revaluation will need to be performed, provided that the Reference Data
is already at the counter. Should a similar change be put through the Basic
Express mechanism, this prompting period may be for less than three days. It is
PON’s responsibility to provide any additional notification required to users.
x Where the change is as described above, the requirement for completion within
48hrs may be extended, if required, to allow for this 3 day period.
4.4.2 Migration Special
A Migration Special change is a specific subset of Basic Pure changes and must
comply with the definitions in [section 4.2.1]. Migration Specials are pre-
authorised for release and no verification is required.
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 25 of 55
FUJ00232464
FUJ00232464
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 9/1/2001
Migration Special changes are additions only to the Reference Data defining
which non-core products a particular outlet can sell, normally where the outlet
has been selling the item but the Reference Data does not reflect this. This
Reference Data is needed so that the Cash Account can record those sales,
when it is migrated to the Horizon system.
The limits for use are:
additions to Non-core Product to Outlet mappings only
© Reference Data must be received by Pathway by 10am for release to be
actioned on the day of receipt or a phone call is required requesting a
later file to be released
© Reference Data files must be identifiable as Migration Specials
Migration Specials differ from the standard Basic Pure change for adding non:
core associations to an outlet by virtue of:
© the urgency with which the data needs to be delivered to the outlet,
normally identified by the HFSO at the time that the outlet is migrated.
Migration Specials refer to one outlet or one product — the normal Basic
Pure change may have any combination of products and outlets.
Where possible PON should use the Basic Pure change for addition of non-core
association records.
Once ICL Pathway has confirmed that the Reference Data is of the required type
it will be released to the ‘Live’ environment.
4.4.3 Tight Timescales
4.4.3.1 Requirement
Requirement 539/3 states there is a need to “implement changes to Reference Data
to tight timescales. As an example of such timescales, it shall be possible to
implement Reference Data changes consequent on a [Treasury] Budget by start of
business on the following day”.
4.4.3.2 Definition
A Tight Timescale change is caused by either:
* an emergency situation where normal lead-times cannot be adhered to because
of legal circumstances outside of PON control, or
¢ to allow PON to exploit commercial opportunities.
Each instance of such change must be notified in writing by PON to ICL Pathway
and agreed between PON Head of Business Service Management and ICL Pathway
Customer Service Director or their nominated authorised deputies.
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 26 of 55
FUJ00232464
FUJ00232464
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 9/1/2001
4.4.3.3 Types
Analysis by PON of the business requirements indicates that the types of change
that require to be actioned in Tight Timescales are:
e Price changes
e Emergency cessation of a product
e Product introduction or change where the product has been created in advance
with interim details.
a) Price Change
The most frequent Tight Timescale changes are price changes. These will be
processed via the fast-track Basic Express route.
b) Emergency cessation
Normally, cessation of a product (i.e. ending the ability to transact a product) is an
Advanced Simple change with a lead-time of 2 weeks*. By agreement, it will be dealt
with as if it were a Basic Express, with a lead-time of 2 working weekdays. The
normal processing will occur after the event e.g. generation of Comparison Reports.
* see Appendix A
c) Product introduction or change (with interim details)
A new product (or product change) can be introduced in advance of all details being
available e.g. to meet a late-breaking business opportunity. Mandatory details
should be provided initially, although some will have interim values
e.g.
product name may be set to “test name” or other identifiably interim name.
e the cash account mapping may be to a line marked as “temporary” .
e the button for the product may not be introduced until a later date, with the
product only available to be sold by PLU initially.
The “interim” product should be verified using standard processes for product
change [see sections 3.4 and 5.6].
To set up the interim product the normal lead-times should be adhered to (e.g. 30
working weekdays for a new product). When the interim product cannot be set up
with the normal lead-times, it will be dealt with as a high priority exception [see
section 9.2].
The interim details will be later replaced using:
e a Basic Express change for the final information relating to price and name. This
must be identifiable as part of the Tight Timescale change, and will be verified
via the Verification Report for Basic Express, before the change is released
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 27 of 55
FUJ00232464
FUJ00232464
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 9/1/2001
standard changes that occur after the go live of the product e.g. the introduction
of the button, or the change of the Cash Account mapping.
An example of the timeline is shown below:
6 -5 I -4 ! -3 I -2 ! -1 ! 0 I +1 I +2 I Weeks
Interim product _ Interim product ental introduced or cla
introduced as introduced as introduced as re-mapped at a
standard change _high priority Basic Express Tater date as a
with interim exceptional ° standard change
values change with 9
interim values
4.4.4 Live Fix
The time scale for incident correction is driven by the impact of the incident, the
complexity of the solution and the Start Date (or Agreed Date) for the change to be
live at the outlets. (see section 9.3)
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 28 of 55
FUJ00232464
FUJ00232464
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 9/1/2001
5 Lead-time for changes
5.1 Introduction
The lead-times quoted in this section are the end-to-end times covering both PON
and ICL Pathway activities. Each party must meet each milestone applicable to it in
order that the subsequent milestones and the end-to-end lead-times are achieved.
The types of change that relate to each category are defined in [section 4].
These lead-times apply for the volumes given in [section 6].
The lead-time runs from initiating a change until the change is Released to the live
system.
For information only, the SLAs to be achieved as set out in the Codified Agreement,
Schedule [G10], are shown at the end of each model. The SLA applies to the
delivery of the released Reference Data not to the delivery of the OBCs.
Notes:
For simplicity, the models used do not show activities that occur in parallel.
day = working weekday (Mon-Fri, excluding English Public Holidays)
adow = any day of the week, includes non working weekdays (Mon-Sun)
times = latest time action can occur to meet the schedule
Where a time is given next to a milestone, the time is critical to achieving that
milestone. Where the time is not given, the default is for the handover between
organisations to be complete by 8am. Failure to achieve a milestone by the given (or
default) time potentially extends the lead-time of the change.
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 29 of 55
ICL Pathway ICL Pathway / PON Interface Agreement for
Operational Business Change - Product
COMMERCIAL IN CONFIDENCE
FUJ00232464
FUJ00232464
Ref: CS/PRD/058
Version: 5.0
Date: 9/1/2001
5.2 Basic - Pure
Changes that involve changing Type A Reference Data only and do not require
verification.
Action Duration I Result Milestone I Owner
Business generates 1 day Deliver OBC to BSM Day 1 (6pm) PON
change
BSM processes change 1 day
RDOT input Reference 2 days
Data
Pathway System
processes
Pathway process change 1 day
System processes
Deliver Reference Data to
RDOT
Send to Pathway
Available to Pathway
Release change
(release day)
Data at counters 97%
Day 2 (6pm) PON
Day 4 (8pm) PON
Day 5 (8am) *
Day 5 (8pm) I ICL
Pathway
(release day
overnight +1 adow)
Data at counters 99% (release day
+2 adow)
Data at counters 100% (release day
+3 adow)
* Note:
Basic — Pure Reference Data files (identifiable as such by virtue of the OBC
prefix used) arriving by 10am, on a working weekday, will be released that
night by Pathway, for distribution.
Basic — Pure Reference Data files received by Pathway by 4pm and
accompanied by a notifying ‘phone call’, on a working weekday, will be
released that night by Pathway, for distribution.
© 2001 ICL Pathway Limited
COMMERCIAL IN CONFIDENCE Page: 30 of 55
FUJ00232464
FUJ00232464
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 9/1/2001
5.3 Basic — High Risk
Changes that involve changing Type A Reference Data only and required
verification.
Action Duration I Result Milestone I Owner
Business generates 1 day Deliver OBC to BSM Day 1 (6pm) PON
change
BSM processes change 1 day Deliver Reference Data to Day 2 (6pm) PON
RDOT
RDOT input Reference 2 days Send to Pathway Day 4 (8pm) PON
Data
Pathway System Available to Pathway Day 5 (8am)
processes
Pathway process change 2 days Deliver Reference Data to Day 6 (6pm) ICL
BSM Pathway
Pathway generate RDMC 2 day Deliver Reports to BSM Day 8 (6pm) ICL
verification & comparison Pathway
reports.
BSM check reports 2 days Notifies Pathway of Day 10 (8pm) I PON
authorisation
Pathway process. Immediate Release change Day 10 (8pm) I ICL
authorisation (release day) Pathway
System processes Data at counters 97% (release day
overnight +1 adow)
Data at counters 99% (release day
+2 adow)
Data at counters 100% (release day
+3 adow)
© 2001 ICL Pathway Limited
COMMERCIAL IN CONFIDENCE
Page: 31 of 55
FUJ00232464
FUJ00232464
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 9/1/2001
5.4 Advanced Simple
Changes requiring advanced notification that involve Type A Reference Data
changes only before release.
Action Duration I Result Milestone Owner
Business generates 1 day Deliver OBC to BSM Day 1 (6pm) PON
change
BSM processes change 1 day Deliver notification to Day 2 PON
Pathway (6pm)
BSM processes 1 day Deliver Reference Data to Day 2 PON
Reference Data RDOT (6pm)
RDOT input Reference 2 days Send to Pathway Day 4 PON
Data (8pm)
Pathway System Available to Pathway Day 5
processes (8am)
Pathway process request 2 days Preparations complete Day 4 {ICL Pathway)
for change (6pm)
Pathway processes 2 days Deliver Reference Data to Day 6 ICL PathwayI
Reference Data BSM (6pm)
Pathway generate RDMC 2 day Deliver Reports to BSM Day 8 ICL PathwayI
verification & comparison (6pm)
reports
BSM check reports 2 days Notifies Pathway of Day 10 PON
authorisation (8 pm)
Pathway process Immediate Release change Day 10 ICL PathwayI
authorisation (release day) (8 pm)
Update systems & Varies Day 11+ ICL PathwayI
documentation
System processes Data at counters 97% (release day +1
overnight adow)
Data at counters 99% (release day +2
adow)
Data at counters 100% (release day +3
adow)
© 2001 ICL Pathway Limited
COMMERCIAL IN CONFIDENCE
Page: 32 of 55
ICL Pathway
ICL Pathway / PON Interface Agreement for
Operational Business Change - Product
COMMERCIAL IN CONFIDENCE
FUJ00232464
FUJ00232464
Ref: CS/PRD/058
Version: 5.0
Date: 9/1/2001
5.5 Advanced Standard
Changes that, in addition to Type A Reference Data, require activities such as
loading Type B (scales and discount indicator) Reference Data, managing additional
information, MIS updates or testing.
Action Duration I Result Milestone Owner
Business generates 1 day Deliver OBC to BSM Day 1 (6pm) PON
change
BSM processes change 1 day Deliver notification to Day 2 PON
Pathway (6pm)
BSM processes 3 days Deliver Reference Datato Day 4 PON
Reference Data RDOT (6pm)
RDOT input Reference 3 days Send to Pathway Day 7 PON
Data (8pm)
Pathway System Available to Pathway Day &
processes (8am)
Pathway process request 2 days Preparations complete Day 4 ICL Pathway
for change (6pm)
Pathway process 2 days Ready for testing Day 9 ICL Pathway}
Reference Data (6pm)
RDT test change 1 days Deliver Reference Data to Day 10 ICL Pathway}
BSM (6pm)
Pathway generate RDMC 2 day Deliver Reports to BSM Day 12 ICL Pathway}
verification & comparison (6pm)
reports
BSM check reports. 2 days Notifies Pathway of Day 14 PON
authorisation (8 pm)
Pathway process Immediate Release change Day 14 ICL Pathway}
authorisation (release day) (8 pm)
Amend MIS mapping 1 day Day 14 ICL PathwayI
(6pm)
Update documentation Varies Day 12+ ICL Pathway}
System processes Data at counters 97% (release day +1
overnight adow)
Data at counters 99% (release day +2
adow)
Data at counters 100% (release day +3
adow)
© 2001 ICL Pathway Limited
COMMERCIAL IN CONFIDENCE
Page: 33 of 55
FUJ00232464
FUJ00232464
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 9/1/2001
5.6 Advanced Complex
Changes that require update Type C Reference Data.
5.6.1 Action Duration I Result Milestone Owner
Business generates 2 days Deliver OBC to BSM Day 2 (6pm) PON
change
BSM processes change 2 days Deliver notification to Day 5 PON
Pathway (6pm)
BSM processes 2 days Deliver Reference Data Day 6 PON
Reference Data to RDOT (6pm)
RDOT input Reference 5 days Send to Pathway Day 11 PON
Data (8pm)
Pathway System Available to Pathway Day 12
processes (8am)
Pathway process request 2 days Preparations complete & Day7 IICL Pathway
for change notify CD (6pm)
Pathway processes 2 days RDT handover to CD Day 13 ICL Pathway
Reference Data (6pm)
Create Type C Reference 10 days Ready for testing Day 23 ICL Pathway
Data (6pm)
RDT Test changes 2 days Deliver Reference Data Day 25 ICL Pathway
to BSM (6pm)
Pathway generate RDMC 2 day Deliver Reports to BSM Day 27 ICL Pathway
verification & comparison (6pm)
reports
BSM check reports 3 days Notifies Pathway of Day 30 PON
authorisation (8 pm)
Pathway process Immediate Release change Day 30
authorisation (release day) (8 pm)
Amend MIS mapping 1 day Day 30 ICL Pathway
(6pm)
Update documentation Varies Day 30+ ICL Pathway
System processes Data at counters 97% (release day +1
overnight adow)
Data at counters 99% (release day +2
adow)
Data at counters 100% (release day +3
adow)
© 2001 ICL Pathway Limited
COMMERCIAL IN CONFIDENCE
Page: 34 of 55
ICL Pathway
ICL Pathway / PON Interface Agreement for
Operational Business Change - Product
COMMERCIAL IN CONFIDENCE
FUJ00232464
FUJ00232464
Ref: CS/PRD/058
Version: 5.0
Date: 9/1/2001
5.7 AP Client Take-On
As described in AP Client Take-On & Token Verification documents [ref. 3 & 4].
5.8 Basic Express
Changes that involve only Type A Reference Data and are one of the named
change types in [section 4.4.1].
5.8.1 Action Duration I Result Milestone Owner
Business generates 2 hours Deliver OBC to BSM Day 1 (10am) PON
change
BSM processes change 3 hours Deliver Reference Data Day 1 (1pm) PON
to RDOT
RDOT input Reference 7 hours Send to Pathway Day 1 (8pm) PON
Data
Pathway System Available to Pathway Day 2 (8am)
processes
Pathway process change 1 hour Deliver Reference Data Day 2 (10am) ICL
to BSM Pathway
Pathway generate 2 hours Deliver Reports to BSM Day 2 (noon) ICL
verification reports Pathway
BSM check reports 4 hours Notifies Pathway of Day 2 (4pm) * PON
authorisation
Pathway process 2 hours Release change Day 2 (6pm) ICL
authorisation (release day) Pathway
System processes Data at counters 97% (release day +1
overnight adow)
Data at counters 99% (release day +2
adow)
Data at counters 100% (release day +3
adow)
* Note: As Basic Express is a form of Fast Track change and therefore outside
the norm it is a Pathway requirement that authorisation is received by 4 pm.
© 2001 ICL Pathway Limited
COMMERCIAL IN CONFIDENCE
Page: 35 of 55
FUJ00232464
FUJ00232464
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 9/1/2001
5.9 Migration Special
To meet the need to apply a quick change to the Product to Outlet mappings for an
outlet
5.9.1 Action Result Milestone Owner
(HFSO) identifies required Notify RDOT * PON
change
RDOT input Reference Send to Pathway * PON
Data
Pathway process change Release change iy ICL
(release day) Pathway
System processes Data at counters 97% (release day +1
overnight adow)
Data at counters 99% (release day +2
adow)
Data at counters 100% (release day +3
adow)
* Note:
Migration Special Reference Data files (identifiable as such by virtue of the
OBC prefix used) arriving by 10am on a working weekday, will be released
that night by Pathway, for distribution.
Migration Special Reference Data files received by Pathway by 4pm and
accompanied by a notifying 'phone’ call, on a working weekday, will be
released that night by Pathway, for distribution.
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 36 of 55
FUJ00232464
FUJ00232464
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 9/1/2001
6 Volume of change
6.1 Introduction
The PON forecast volume of Operational Business Change is shown in Appendix B
On a 3 monthly basis the Operational Service Review Forum will review actual and
forecast volumes to estimate the impact on future capacity and lead-times.
6.2 Committed volumes
The parties agree that the PON Dec ‘99 estimate in [Appendix B] is deemed to be
the baseline volume of OBCs for this agreement for the year 2000 and the basis for
2001. The Reference Data Operational Review Forum will review both changes to
forecast and actuals against the baseline.
The baseline for Reference Data record changes is given in the AIS [ref. 5].
Data, which is required specifically for the implementation of a new system release
(e.g. CSR+), is exceptional to these committed volumes and as such will not be
accounted within any measurement against this Agreement.
Where:
e the quarterly forecast figures (or observed actuals) for a rolling 12 month period,
show an increase of more than 15% on the baseline for the (aggregated) total of
all OBCs or for all Reference Data records or
e Fast-track changes (excepting Migration Specials) exceed 10% of the rolling
annual total volume of changes, then
a Change Request (CR) is required for full impacting of the resource needed to
deliver the end-to-end process and to establish a new baseline.
Where these limits are exceeded changes will be processed as exceptions [see
section 9.2].
N.B. Changes requested directly by ICL Pathway or required to support a major
system upgrade or as otherwise agreed (e.g. database tidying activity) may be
excluded from change volumes by agreement between PON and ICL Pathway.
6.2.1 Peaks in Business Change activity
e Where the total volume of Business changes raised in any week is no more than
15% above the baseline, the changes will be processed to meet the agreements
specified in this document.
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 37 of 55
FUJ00232464
FUJ00232464
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 9/1/2001
e Where the total volume of Business changes raised in any week is more than
15% above the baseline, this is termed a ‘peak’.
e Where the ‘peak’ is between 15% and 30% above the baseline, notification must
be given at least 1 week in advance, for the changes to be processed to meet the
agreements specified in this document.
e Where the ‘peak’ is between 30% and 50% above the baseline, notification must
be given at least 4 weeks in advance, for the changes to be processed to meet
the agreements specified in this document.
e Where the total volume of Business changes raised in any week is anticipated to
be greater than 50% above the baseline, or where the notice period of a peak is
not possible, the changes will be treated as an exception [see section 9.2].
« Where sufficient notice of an increase in volume over 50% above the baseline is
available, a CR can be raised to change the baseline.
e Where the total volume of Business changes is greater than 20% above the
baseline, over a 3-month period, a CR is required to change the baseline
volumes.
RDORF will ensure that there is careful co-ordination of each component of the
change(s) and will prioritise between current work, where necessary.
Examples of peak activity are end of year and tariff changes.
a) End of year
The end of financial year changes will normally represent a peak in change activity.
Changes that can be expected at this time of year include:
e Cash Account changes (which are not covered by OBC processes but do need to
be co-ordinated with the OBC activity)
e changes caused by Budget decisions
e other product changes, e.g. Tariff Change or the introduction of new Homecare
Stamp Changes.
PON and ICL Pathway will plan and manage these changes as separate peak
change projects.
b) Tariff changes
A Tariff Change may include new product introduction, revaluation, price changes
and/or scales data changes, with multiple changes of each type. It may cause a
large overhead on verification, particularly of scales data, and requires careful co-
ordination, as well as being open to last minute amendment by POUNC.
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 38 of 55
FUJ00232464
FUJ00232464
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 9/1/2001
7 Deliverables
To ensure milestones are not put at risk all deliverables must be:
Complete and identifiable e.g. cross referencing change numbers
Error free [see section 9.3 for managing errors]
Correctly dated (see section 7.3)
Delivered by the relevant deadlines set out in the Interface Agreement [see
section 5 for required milestones]
e Delivered through the agreed mechanisms.
7.1 PON to ICL Pathway
PON shall deliver to ICL Pathway:
1) Reference Data for Advanced and Basic changes
2) Operational Business Change forms for Advanced changes
3) Supporting items and/or information appropriate for changes e.g. AP tokens,
Counter News
4) Authorisation for Advanced and High Risk Basic changes
5) Volumetric forecasts, including peaks
7.2 ICL Pathway to PON
ICL Pathway shall deliver to PON:
1) Reference Data direct to Live Counters, for OBCs that are pre-authorised by
PON.
2) Reference Data to Verification Counters, for OBCs to be verified, and that:
e include Type C Reference Data for Advanced changes when necessary
« has been validated to ensure changes work as requested on the OBC forms.
3) Verification and Comparison Reports (as appropriate) that identify exactly what
changes to the counter have been implemented
4) Reports to RDORF on volumetrics, including observed peaks.
7.3 Future Dating
Reference Data records contain a ‘Start Date’ which is the date on which the change
is to become effective on the Horizon counters. This date should always be in the
future when the data is created and remain a ‘future date’ throughout processing
and distribution so that it is still a future date when it arrives at the counters.
There is a risk to PON if the OBC process is not initiated sufficiently in advance of
the Start Date to allow for:
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 39 of 55
FUJ00232464
FUJ00232464
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 9/1/2001
e the IFA lead-time for processing, validation, authorisation and release to the Live
system for that particular type of change
« the distribution time to outlets
e additional contingency where PON consider the Reference Data to have
business critical importance
Where, for whatever reason, PON are unable to initiate the OBC process sufficiently
in advance, then PON and ICL Pathway would establish an Agreed Date to
supersede the Start Date.
ICL Pathway reserves the right to log as a pre-live incident, the receipt of any
Reference Data which is not future dated. This is because data which has an
immediate start date (i.e. any date in the past at the time when the data reaches the
Horizon counter) may have an adverse effect and may create additional calls to
HelpDesks.
The scheduling of non-future dated data by OSG delaying authorisation of the
release of Reference Data is not an approved method.
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 40 of 55
FUJ00232464
FUJ00232464
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 9/1/2001
8 Roles & Responsibilities
8.1 PON —- General
PON shall, without limitation:
8.1.1 Administration and Control
a)
b)
)
a)
e)
f)
Appoint and communicate to ICL Pathway the name of an owner for this
Interface Agreement. The owner shall maintain and communicate to ICL
Pathway the list of change authorisers for Product Reference Data.
Measure & report on the performance of processes carried out by PON under
this Interface Agreement.
Participate in the Service Review process, to cover all aspects of the process
and its operation, including the provision of regular forecasts of volumes, at least
annually.
Review the OBC process and forms to identify improvements.
Maintain details of the PON contacts relevant to these processes within the
change contacts list in the OLAs [ref. 12 & 13].
Ensure that all staff involved in the OBC process are aware of their role and
responsibilities
8.1.2 Implementation
a)
b)
c)
q)
Ensure Post Office staff and clients are aware of changes in time to make the
necessary preparations
Resolve queries from ICL Pathway that are material to an OBC
Communicate issues and exception information to ICL Pathway, as reasonably
necessary to assist them, to enable them to manage and control all their relevant
change activity on the ICL Pathway side of the change interface.
Provide the Postmaster communication (e.g. Counter News) to ICL Pathway for
comment before release and make any amendments reasonably required by ICL
Pathway
Identify potential variations to the service as soon as known e.g. peak activity
Process and communicate advanced product changes, in accordance with
timescales in [section 5], to ICL Pathway ensuring, where necessary, that
changes are submitted separately in units of release.
Verify changes and provide authorisation ready for release [in accordance with
section 8.6]
Ensure that the PON copy of reference documents, e.g. copy of the Menu
Hierarchy, is available to PON staff who require it
Maintain and ensure the security of the OBC Product and Reference Data
verification mailboxes on PON servers
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 41 of 55
FUJ00232464
FUJ00232464
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 9/1/2001
8.1.3 Files & Reference Data
a) Ensure the date contained in the Reference Data is in accordance with the
required lead-times [see section 5]
b) Where possible, all Reference Data which should be applied as a unit, as
defined by business rules or the OBC, should be supplied in a single file. Where
this is not possible, subsequent files must be identifiable as the same unit of
release.
c) Recognise that the file is the unit of release and all changes within one file are
constrained by the longest lead-time.
d) Allocate unique Business Change Request number (Change Control Number).
e) Ensure all required change information and data is submitted to ICL Pathway
e.g. menu hierarchy information [ref. 14] AP CTO packs etc.
f) Ensure the accuracy and integrity of the change information and Reference Data
provided to ICL Pathway
8.2 PON - Reference Data Operational Team
PON RDOT shall, without limitation:
a) Process and transmit basic Reference Data changes to ICL Pathway over routes
& timetables, as specified in the OLA [ref. 12].
b) Supply Reference Data to support advanced change in accordance with
specified standards [see section 0.3].
c) Allocate unique Business Change Request number (Change Control Number)
where necessary.
d) Ensure that the content of any file is consistent with the change identifier.
8.3 PON Network Business Support Centre (NBSC)
NBSC shall, without limitation:
a) Provide an interface to log PON Live incidents raised by PON or ICL Pathway.
b) Monitor, track and provide updates on PON Live incidents, to resolution.
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 42 of 55
FUJ00232464
FUJ00232464
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 9/1/2001
8.4 ICL Pathway responsibilities
ICL Pathway shall, without limitation:
8.4.1 Administration and Control
a) Appoint and communicate to PON the name of an owner for this Interface
Agreement.
b) Measure & report to RDORF the performance of ICL Pathway processes carried
out under this Interface Agreement.
c) Participate in the Service Review process, to cover all aspects of the process
and its operation, including the provision of 3 monthly reports on the volume of
change received over the previous year.
d) Review the OBC process and forms to identify improvements.
e) Maintain the details of the ICL Pathway contacts relevant to these processes
within the OBC Product Change contacts list in the OLAs [ref. 12 and 13].
f) Ensure that all staff involved in the OBC process are aware of their role and
responsibilities
8.4.2 Implementation
a) Ensure ICL Pathway staff and suppliers are aware of changes in time to make
the appropriate preparations, where necessary
b) Review the Postmaster communication (e.g. Counter News) and notify PON of
any amendments reasonably required, before issue.
c) Communicate issues and exception information to PON, as reasonably
necessary to assist PON, to enable them to manage and control all their relevant
change activity on the PON side of the change interface.
d) Receive and progress basic Reference Data change requests through the
Reference Data change procedures
e) Receive and progress advanced Reference Data change requests. These may
be sent electronically by PON to the OBC Product Change Mailbox or via
fallback routes (e.g. fax)
f) Assess advanced changes and identify and deliver the change services needed
to satisfy specific changes
g) Ensure that supporting ICL Pathway processes are implemented to manage the
delivery of change services
h) Ensure that appropriate updates to Menu Hierarchy are forwarded to PON
librarian for onward distribution within PON
i) Provide invoices for the completion of work, when appropriate [see section 9.5]
j) Release correctly authorised changes to meet the Agreed Date [see section 9.3]
8.4.3 Files & Reference Data
a) Provide changed Reference Data, Verification and Comparison Reports in
accordance with agreed procedures [see section 0.3]
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 43 of 55
FUJ00232464
FUJ00232464
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 9/1/2001
8.5 Horizon Service Helpdesk (HSH)
HSH shall, without limitation:
a) Provide an interface to log ICL Pathway Live incidents raised by PON or ICL
Pathway.
b) Monitor, track and provide updates on ICL Pathway Live incidents, to
resolution.
8.6 Verification, authorisation & release
Note: for details of the process [see section 3.4].
1) PON shall
Verify the OBC form before keying the Reference Data.
Use the RDS system built in validation rules on the Reference Data keyed in.
Verify the Reference Data once it has been keyed, before it is sent to ICL
Pathway.
VV Vv
2) ICL Pathway shall
Check that all the Reference Data required for an OBC has been received.
Check that the contents of a file are appropriate for that file / change type.
Confirm that the Postmaster communication e.g. Counter News is appropriate
Raise any queries with PON relevant to the progression of an OBC
Produce a Verification and Comparison Report (where necessary) for
changes delivered to the verification counters.
Confirm that the change works technically, before sending data and reports to
PON for verification.
VVVVY
Vv
3) PON shall
> Perform Authorisation
> Gain the agreement of ICL Pathway, where PON wish to release a change
that contains a known deviation from the original intention (including an
inappropriate communication).
4) ICL Pathway shall
> Explain to PON’s reasonable satisfaction any queries which PON have
arising from the validations carried out, or, where the change is part of the
technical implementation, accept responsibility for that element of the
change.
> Not unreasonably withhold its agreement to release changes which PON
approve as acceptable deviations from the original intention.
Release the Reference Data for authorised changes to the live system
provided PON has complied with it obligations set out in [section 8.6 para 3].
Vv
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 44 of 55
FUJ00232464
FUJ00232464
ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
ICL Pathway
Operational Business Change - Product
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 9/1/2001
Each party accepts responsibility for those aspects of a change for which it has
responsibility to test.
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 45 of 55
FUJ00232464
FUJ00232464
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 9/1/2001
9 Orders and exceptions
9.1 Orders
e The receipt by the OBC Product Mailbox of the OBC form is the confirmed
request from PON to ICL Pathway, for Advanced Changes.
e The receipt of a Reference Data file containing only Basic (Class 1 Reference
Data) in the RDMC, is the confirmed request for change from PON to ICL
Pathway.
e The receipt of a correctly completed Authorisation Form from PON is the
confirmed authorisation to release the change.
e The receipt of pre-authorised change files (e.g. Migration Special or Pure Basic)
clearly identified as such and containing that type of change, is the authorisation
for release of the changes.
e Requests for non-OBC changes (i.e. those not defined in the RDCC [ref. 2]) will
not be accepted and need to be submitted as a Change Request. However, the
change request may also initiate an update to the RDCC so that new changes
are introduced to the OBC process, where agreed. In many cases once a CR
has been approved the delivery mechanisms will be the same as, or similar to,
those used for OBC.
9.2 Exceptions
Exceptions, e.g. to volumes or lead-times, will be processed using available
resources without any guarantee of service delivery. Both PON and ICL Pathway
shall notify the other party when a request is recognised to be an exception.
Note: An agreed Deviation to the Service (e.g. Reference Data necessary for the
implementation of a new system release such as CSR+) is not an exception.
PON may wish to change the priority of an exceptional change so that it is given
preference over normal changes. In this instance the agreed lead-times may be
extended pro rata for displaced activities.
9.3 Errors and Rework
N.B. This section relates to errors or rework for both Product and Outlet Reference
Data, where appropriate.
9.3.1 Recording Pre-Live Incidents
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 46 of 55
FUJ00232464
FUJ00232464
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 9/1/2001
All observed errors will be recorded as pre-live incidents in accordance with the
OLAs (refs. 12 & 13). The change will be suspended awaiting corrective action,
potentially delaying the achievement of that milestone for all changes affected by the
error. For example, a file containing records that are rejected will not be processed
until the rejected records are corrected and any other change which is in any way
associated with the rejections may also be delayed. Where the achievement of a
milestone is at risk, corrective action will be taken by the appropriate party or
parties, by agreement, in order to achieve the final milestone, where possible.
A pre-live incident will be raised for late deliverables.
If the Start Date contained within Reference Data record is not future dated or is set
to a date prior to the Required Date a pre-live incident will be raised i.e. the Start
Date is either prior to the date on the OBC form, or is not consistent with the overall
lead-times (see section 7.3).
If it is known that the final milestone will not be achieved, or an alert has been
requested and the data is being released and will become active on the following
day an Alert may be necessary as described in section 2.5.
9.3.2 Rework categorisation and thresholds
Rework files are files which are, or appear to be, either Amendment files or Error
Corrections files to a change that is currently being progressed (e.g. PON Client has
requested a name change to a product before it has gone live). They necessitate
additional activity by all parties and as such may have an impact on lead-times.
DN: the remainder of this section is still subject to review between PON and
ICL Pathway and anticipates the inclusion of Reference Data for Outlet
Change.
Rework files are divided into 5 major categories as follows:
1) Product Business Imperative — where the PON Client or PON Market Facing
Units have requested a change
2) Product Other
3) Outlet Business Imperative — where physical changes at an outlet cannot be
completed due to issues with PON suppliers
4) Outlet Other
5) Common - errors originating in RDS (system or process error)
These major categories Product Other and Outlet Other may be subdivided e.g.
© OBC error — where the OBC details were submitted incorrectly
« Pathway — where a request for Rework has been made by Pathway (other
than for Error or Usability)
e Rules — where rules do not exist or are unclear or ambiguous (broken
rules are Errors)
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 47 of 55
FUJ00232464
FUJ00232464
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 9/1/2001
e TIP— where a request for Rework is made by TIP
RDORF shall review the number of Rework files transmitted to ICL Pathway by PON
with the aim of:
1) understanding reasons for Rework
2) reducing instances of Rework in each of the above categories
Thresholds for the acceptable level of rework in each of the above categories are
currently under review by an RDORF sub-group and will be recorded in the CSR+
version of this document.
The measurements will be based on:
a) the number of rework files received in any quarter as a percentage of
the total number of Product Changes in the quarter for the categories:
1) Product Business Imperative
2) Product Other
b) the number of rework files received in any quarter as a percentage of
the total number of Outlet Changes in the quarter for the categories:
1) Outlet Business Imperative
2) Outlet Other
c) the number of rework files received in any quarter as a percentage of
the total number of Changes (Product and Outlet) in the quarter for the
category:
1) Common Entities
RDORF is responsible for monitoring the urgent progress of this activity.
Appropriate steps shall be taken to establish and eliminate the root cause of
Rework.
9.4 Escalation
Disagreements about the service e.g. whether a change is exceptional, will be
raised, and wherever possible resolved, at the RDORF. If agreement cannot be
reached at the RDORF, either party may invoke formal escalation mechanisms.
9.5 Charging
e AP Client Take-On is charged as specified [see ref. 3].
e Deviations to the service will be charged as per the CCN.
¢ Invoices will be raised and paid in accordance with Schedule A10.
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 48 of 55
FUJ00232464
FUJ00232464
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 9/1/2001
10 Appendix A: Remove/Cease Product and ITM’s
Item Transaction Modes and Horizon
The effect of changes to ITM’s on CSR counters is achieved by use of the Menu
Hierarchy. This poses a number of limitations due to the way in which the system
was designed. For example:
e Items on picklists will appear on Remit In, Remit Out, and Serve Customer
picklists and can be used in all three however removal can also only be from all
three at the same time
e There is no ability to ‘gracefully’ remove products from a CSR counter, i.e.
because ITM’s are not used it is not possible to remove one mode without others
unless the item can only be sold, or remitted through a button only
e Because items cannot be ‘gracefully’ removed it is not possible to provide any
functionality to remove non-core items from outlets other than by complete
removal
In CSR+ the use of ITM’s provides the capability of having different transaction
modes available at different times and therefore the ‘graceful’ termination of items is
achievable, however whilst CSR counters are still in use it is necessary to consider
the methodology to be used for the CSR counters in preference to the CSR+
capabilities. Once there are no CSR counters in the Live estate full use of ITM’s
can be made without further consideration (other than any relevant rules)
Whilst CSR counters are still in use on the Horizon system the implementation of
Remove/cease a product is summarised as follows.
Action Type of Position on Type of change
product screen
Remove Value & Non- Button & Pick- I N/a (data cannot be end dated at
permanently I Value products I list CSR)
(Cease Sell INon-Value IPick-list Simple
products (use Type A Reference Data to end
lpicklist link & Pathway document
lafterwards)
(Cease Sell INon-Value Button (Complex (Type C Reference data)
products
(Cease Sell ‘alue products [Button (Complex
leave Rem
(Cease Sell ‘alue products Pick-list IN/a
leave Rem
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 49 of 55
FUJ00232464
FUJ00232464
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 9/1/2001
(Cease Sell & [Value products Pick-list Simple
(Cease Rem (use Type A Reference Data to end
ipicklist link & Pathway document
lafterwards)*
(Cease Sell & Value products {Button (Complex (Type C Reference Data)*
(Cease Rem
* NB Not anticipated to be used at CSR, as it must be confirmed by BSM that offices
have no stock remaining, and no transactions in the current period.
Also making a core product non-core whilst CSR counters are still in use can only
be implemented by introducing a new product.
When CSR+ is fully implemented in all outlets the above changes will be
implemented using Item Transaction Modes
© 2001 ICL Pathway Limited
COMMERCIAL IN CONFIDENCE Page: 50 of 55
ICL Pathway ICL Pathway / PON Interface Agreement for Ref:
Operational Business Change - Product
FUJ00232464
FUJ00232464
CS/PRD/058
Version: 5.0
COMMERCIAL IN CONFIDENCE Date:
9/1/2001
11 Appendix B: OBC Volumes for Year 2000
The volume of change estimated by PON for the year 2000 is as follows.
The values were provided initially in December 1999, and amended with the
Changing Picklist ordering changes in August 2000.
(Change and Category
(OBC
Volume
IBasic Change
(Change price & min/max price/volume
(660
Increase non core product availability in outlets
432
(Change MOP for product (existing MOPs)
86
(Change customer sales rules
27
(Change product name
22
(Change voidable / reversable
iS
Subtotali1232
(Advanced Simple
Change additional fields
18
Subtotal18
Advanced Standard
(Change accounting calendar
4
Subtotall1
Advanced Complex
Add EPOSS product
516
[Permanent cessation of product
363
(Change mapping to c/a
4
(Change Menus
13
Change picklist ordering:
. Cash Declaration/ONCH
Cash Rem Out - Notes
Cash Rem Out - Coin Full Bags
Cash Rem Out - Coin Partial Bags
Cash Rem Out - Unusable Coin
Rem Out - Other Postage Stamps
GaARON>=
Change Royal Mail tariff
(Change Advice Notes Product Group Ordering (add or
remove Group, alter order)
(Change Parcelforce tariff (limited range)
(Change Non-Value Stock Product Group Ordering (add or
remove Group, alter order)
(Change Non-Value Stock Item Ordering within Product Group}
(Change Advice Notes Item Ordering within Product Group
4
Subtotal952
(Advanced AP
(Add AP client 251
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 51 of 55
FUJ00232464
FUJ00232464
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 9/1/2001
Add AP service 111
Remove AP service 41
(Change client name 37
Remove AP client 26
Subtotal466
(Change requiring Change Request
(Change printed forms 32
(Change stock reconciliation 15
Change VAT. k
INew VAT rE
INew currency E
(Change currency kt
Subtotal47
(Other (processed via ITMs in CSR+, interim arrangements
lin CSR)
(Change product start date 77
[Temporary cessation of product 32
(Change product between core & local 18
SubtotalI127
Grand Totall2843
DN: volumes yet to be amended to include impact of LFS/SAPADS. e.g.
increase in “Add EPOSS product”. Also Refresh Cash Account details
(usually to amend text on Cash Account lines)
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 52 of 55
FUJ00232464
FUJ00232464
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 9/1/2001
12 Appendix C: PON Business Tests
Business tests for the purpose of verifying changes to Reference Data are
conducted by PON and are described in [ref. 14]. These tests include, where
appropriate, review of Verification and Comparison Reports and the functional
testing of Reference Data on test counters supplied by ICL Pathway. Authorisation
from PON to ICL Pathway to release Reference Data is made on the basis of these
tests.
13 Appendix D: Standard Changes - Details
Section 4.2 gives details of the hierarchy of changes which are Standard Changes.
The complete list of changes applicable to each type can be found in the RDCC [ref
2]. Below is a representative sample of the changes for each type.
13.1.1 Basic - Pure
Increase product availability (non-core)
Change clerk instructions
13.1.2 Basic — High Risk
Change product price
Revaluation
Change min/max quantity/value
Change whether voidable or reversible
Change between existing methods of payment
Change product names
13.1.3 Advanced Simple
Cease non-value product*
Cease Sell and Remit In/Out of value product (at same time)* t
Non core product becomes core
Change use of additional fields
* These changes cannot be fully implemented through Reference Data alone until all
outlets are operating at CSR+. See appendix A for more detail regarding
implementation whilst outlets are still operating at CSR
t+ Although, within the CSR release of the Horizon system, the facility exists to
perform this combined action, it is not normally used due to the complexity of the
necessary procedural management. In CSR+ the ‘cease sell’ and ‘remit’ functions
become separate by the use of Item Transaction Modes.
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 53 of 55
FUJ00232464
FUJ00232464
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 5.0
COMMERCIAL IN CONFIDENCE Date: 9/1/2001
13.1.4 Advanced Standard
Change discount indicator
Change ability to print receipt
Change value to non-value stock
Change client name — non AP
Change calendar
Remove AP client
Change pick-list for existing product
13.1.5 Advanced Complex
Add new product - non value stock
Add new product - make value stock available to rem-in
( up to 6 weeks prior to it being made available for sale)
Remove product permanently*
Cease value product and leave on Rem Out screen*
Change scales matrix/tariff change (no Type C required but BSM need extra
time to verify the OBCs).
Change screen layout
Change accounting node
Change product categorisation i.e. making a non-core product core*
Change Best Fit screens
Temporary withdrawal of a product
Add/Change/Remove Item Transaction Mode/Item Transaction Mode Code*
Add/Change/Remove Logistics Inventory/Accounting Items
Change Picklist ordering: Tt
Add/Change/Remove non-value stock product group ordering t
Change non-value stock item ordering within product group t+
Add/Change/Remove advice notes product group ordering t
Change advice notes item ordering within product group t
* These changes cannot be fully implemented through Reference Data alone until
all outlets are operating at CSR+. See Appendix A for more detail regarding
implementation whilst outlets are still operating at CSR
+ These items are to be included in the next version of the RDCC.
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 54 of 55