FUJ00232480
FUJ00232480
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 7.0
COMMERCIAL IN CONFIDENCE Date: 28/08/2001
Document Title: ICL Pathway / PON Interface Agreement for Operational
Business Change - Product
Document Type: Interface Agreement
Release: CSR+
Abstract: This agreement defines for CSR+ the requirement, the service
solution and the obligations of PON and ICL Pathway for
delivering Operational Business Change — Product.
Document Status: Approved
Author & Dept: David Wilcox, John Wright ICL Pathway Customer Service
Contributors: Stephen Muchow Nick Embling
Martin Riddell David Anders
John Wright Dave Ireland
David Wilcox Andy Corbett
Bernadette O’Donnell
Reviewed By:
Comments By:
Comments To: Document Controller & Author
Distribution: ICL Pathway Library,
people who require approved versions only,
Horizon Library
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 1 of 1
FUJ00232480
FUJ00232480
ICL Pathway ICL Pathway / PON Interface Agreement for _—Ref: CS/PRD/058
Operational Business Change - Product
Version: 7.0
COMMERCIAL IN CONFIDENCE Date: 28/08/2001
0.0 Document Control
0.1 Document History
ersion {Date lReason for Issue Associated
INo. CCN No.
0.1 09/02/99 First Draft
(0.2 18/02/99 Second Draft — supersedes first draft
0.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 1
ICL Pathway
ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 7.0
COMMERCIAL IN CONFIDENCE Date: 28/08/2001
FUJ00232480
FUJ00232480
2.5
2.6
2.7
2.8
2.9
13.0
13.1
13.2
3.3
13.4
3.5
4.0
5.0
9.1
5.2
5.3
6.0
7.0
03/12/99
22/12/99
05/01/00
11/01/00
13/01/00
20/01/00
09/05/00
15/06/00
02/07/00
30/08/00
28/11/00
11/12/00
9/1/2001
1/3/2001
12/4/2001
14/6/2001
13/7/2001
28/8/2001
[THIS DOCUMENT WAS FORMALLY WITHDRAWN BY ICL PATHWAY
Re-issued following significant ICL Pathway /
PON discussions.
Reviewed after PON / ICL Pathway meeting
on 20/12/99.
Changed to include ICL Pathway commercial
comments.
Changes following PON /ICL Pathway review
on the 10/1/2000
Changes following PON.ICL Pathway review
on 13/1/2000
Updated baseline. CCN 496b
Updated for CSR+
All references to POCL replaced by PON.
Cross-references to RDCC section numbers
deleted.
Updated following comments from PON
Updated following meeting with PON
Updated following meeting with PON
Updated following meeting with PON
Updated baseline
Updated baseline following comments from
PON
Removes reference to CSR plus addition of
new definitions
Amendments following meeting with PON
Further amendments following meeting with
PON
Updated baseline following final comments
Updated baseline following further essential
change of name from Postwatch to Postcomm
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 3 of 1
FUJ00232480
FUJ00232480
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 7.0
COMMERCIAL IN CONFIDENCE Date: 28/08/2001
0.2 Approval Authorities
IName [Position ignature [Date
Martin Riddell ICL Pathway
(Customer Service
Director
IDon Grey IPON Head of
Business Service
Management
© 2001 ICL Pathway Limited
COMMERCIAL IN CONFIDENCE
Page: 4 of 1
FUJ00232480
FUJ00232480
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 7.0
COMMERCIAL IN CONFIDENCE Date: 28/08/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 Process for Operational Business Change -ICL
Product Pathway
2. ICS/IFS/001 2.2 27/8/99 Reference 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
+ NR2 Pathway
5. IRDP/AIS/001 3.3 02/02/98 [AIS Reference Data to Pathway Type A IPON
Data (CSR)
6. IRDP/AIS/001 4.4 21/01/00 _IAIS Reference Data to Pathway Type A IPON
[Data (CSR+)
7. IRDP/AIS/008 (0.2 23/12/98 [AIS Reference Data to Pathway Type B IPON
[Data (CSR)
8. IRDP/AIS/008 I4.3A {01/10/99 AIS Reference Data to Pathway Type B IPON
[Data (CSR+)
9. ICS/PRD/048 1.0 I23/6/99 (Changing Reference Data to Tight ICL
ITimescales 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 forliCL
(Operational Business Change — Outlet Pathway
12. IRDS/OLA/001 1.0 = {26/3/99 [Reference Data —- PON / ICL Pathway IPON
\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 IPON
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. ICS/OLA/022 (0.2 I19/3/2001 ICounter News Review Process ICL
Pathway
© 2001 ICL Pathway Limited
COMMERCIAL IN CONFIDENCE Page: 5 of 1
FUJ00232480
FUJ00232480
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 7.0
COMMERCIAL IN CONFIDENCE Date: 28/08/2001
18. ICS/PRD/077 2.0 17/11/00 IReference Data Alert Process ICL
Pathway
19. ICS/PRD/O28 [1.3 I6/5/99 Process for Changing Menu Hierarchies IICL
land Icons Pathway
20 ICS/PDN/018 0.1 = 21/6/2001 [Horizon ICON Service Description ICL
Pathway
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 6 of 1
FUJ00232480
FUJ00232480
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 7.0
COMMERCIAL IN CONFIDENCE Date: 28/08/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: 7 of 1
FUJ00232480
FUJ00232480
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 7.0
COMMERCIAL IN CONFIDENCE Date: 28/08/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), which has now been integrated within the
[Development strand of BSM.
[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.
here 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
ICCN (Change Control Note as defined in the Codified Agreement.
CCN (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
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 8 of 1
FUJ00232480
FUJ00232480
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 7.0
COMMERCIAL IN CONFIDENCE Date: 28/08/2001
jon any other part of the Horizon system and changes containing only
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.
CSR (Core System Release — superseded by CSR+
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.
[Error IA 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 \A 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
Pathway 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 IThis document (except where the Interface Agreement for Outlet is
(Agreement specifically referred to, then see [ref. 11]).
Live Fix \A 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.5.2 for the definition.
Special
MIS 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
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 9 of 1
FUJ00232480
FUJ00232480
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 7.0
COMMERCIAL IN CONFIDENCE Date: 28/08/2001
(Changes, excluding changes specifically required to implement software
lchanges.
OBC forms Electronic Forms used to interchange information relating to OBCs
lbetween PON and ICL Pathway e.g. OBC 2.
IOLA (Operational Level Agreement
IPM Postmaster
IPOCL Post Office Counters Limited — the former name of PON.
IPON IPost Office Network - name which supersedes POCL.
IPostcomm IThe Postal Services Commission, that is the Government appointed
regulator for postal services
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
lby ICL Pathway without additional notification from PON over and above
[the 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
IReference 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 IReference 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
RDS 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,
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 10 of 1
FUJ00232480
FUJ00232480
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 7.0
COMMERCIAL IN CONFIDENCE Date: 28/08/2001
lor earlier than, the Start Date. (see also, Agreed Date.)
[Rework Activity required to progress a change when an Error Correction File or
(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 \Transaction 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 IData prepared by ICL Pathway.
IUnauthorised [An OBC that has been released to the live environment but has not been
change lauthorised.
IUnit of Release IA combination of files which are intended to be released together. The
ismallest 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 have changed.
forking (9am to Spm, Monday to Friday, excluding English Public Holidays.
eekdays
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 11 of 1
ICL Pathway
FUJ00232480
FUJ00232480
ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 7.0
COMMERCIAL IN CONFIDENCE Date: 28/08/2001
0.5 Changes in this Version
Version
(Changes
5.1
Remove all references to CSR
Addition of definition of Business Critical Advanced change
Detail on limitations for Tight Timescale change
Addition of ICON change
5.2
oT
Further amendments following meeting with PON
Removal of Appendix A as it is no longer relevant
5.3
Further amendments following meeting with PON
Wording of Tight Timescales has reverted to that in version 5.0}
with the exception of Emergency Cessation which changes as al
result of the introduction of ITM’s
Introduction to BCAC amended to ensure clarity of BCAC vis-a-vis)
Tight Timescales
Text from Appendix B moved to section 8.6
Clarification on process steps to show those processes which canI
occur in parallel
Clarification on Migration Special
Minor amendments to Appendix regarding change types
6.0
Minor amendments for clarification
Remove italicised section in 9.3.2 regarding rework volumes
7.0
Essential change from Postwatch to Postcomm with a few minor
amendments
0.6 Changes Expected
(Changes
le The inclusion of Outlet Reference Data, in particular with regard to errors andI
rework
le Section 3.4: Further amendment to process for the production and
communication of Counter News articles that relate to Reference Data changes.
le Section 9.3: Errors and rework and thresholds.
le Appendix A: volumes amended to include impact of LFS/SAPADS.
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 12 of 1
FUJ00232480
FUJ00232480
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 7.0
COMMERCIAL IN CONFIDENCE Date: 28/08/2001
le Appendix B: ability to change a core product to non-core
le Changes necessary for Network Banking
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 13 of 1
FUJ00232480
FUJ00232480
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 7.0
COMMERCIAL IN CONFIDENCE Date: 28/08/2001
0.7 Table of Contents
1 SUMMARY SHEET...
2 INTRODUCTION...
2.1 INTENT OF AGREEMENT. - . - soon 19
2.2. MAINTENANCE OF THIS AGREEMENT. 19
2.3. FUTURE DEVELOPMENTS. 20
2.4 SERVICE MANAGEMENT POLICY......ccosneennne sstsenannnnnnnennnnnnannnenee . see senianannennenae 20
2.5 ALERTING WHEN DATA IS AT RISK OF LATE DELIVERY. nnn sone 20
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..
3.5 ICON CHANG!
4 TYPES OF CHANGE
4.1 INTRODUCTION.
4.2. STANDARD CHANGES.
4.2.1 Basic - Pure.
4.2.2 Basic — High Ris)
4.2.3 Advanced Simple....
4.2.4 Advanced Standard...
Advanced Complex.
4.5 FAST-TRACK CHANG!
Basic Express......
Migration Special.
Tight Timescales.
Live Fix.
Business Critical Advanced Change.
5 LEAD-TIME FOR CHANGES...
5.1 INTRODUCTION.
5.2. BASIC - PURE.........
5.3 Basic — HIGH RIsK.
5.4. ADVANCED SIMPLE.
5.5. ADVANCED STANDARD,
5.6 ADVANCED COMPLEX...
Action... costes
5.7 AP CLIENT TAKE-O)
5.8 BASIC EXPRESS.
Action....... .
5.9 MIGRATION SPECIAL.
Actiol
6 VOLUME OF CHANG!
6.1 INTRODUCTION. 42
6.2. COMMITTED VOLUMES. 42
6.2.1 Peaks in Business Change activity.....co0.--
7 DELIVERABLES....
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 14 of 1
FUJ00232480
FUJ00232480
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 7.0
COMMERCIAL IN CONFIDENCE Date: 28/08/2001
7.1 PON To ICL PaTHWay.
7.2. ICL PatHway To PON..
7.3. FUTURE DATING.
8 ROLES & RESPONSIBILITIES.
8.1 PON — GENERAL.
8.1.1 Administration and Control...
8.1.2. Implementation...
8.1.3 Files & Reference Data... oe
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... os
9.3 ERRORS AND REWORK.
9.3.1 Recording Pre-Live Incidents.
9.3.2. Rework categorisation and thresholds.
9.4 ESCALATION.
9.5 I CHARGING.
10 APPENDIX A: OBC VOLUMES FOR YEAR 2001...
11. APPENDIX B: STANDARD CHANGES - DETAILS...
11.1.1 Basic - Pure.
11.1.2. Basic — High Ris!
11.1.3. Advanced Simple.
11.1.4. Advanced Standard.
IL1.5 Advanced CompleX.....-
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 15 of 1
FUJ00232480
FUJ00232480
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 7.0
COMMERCIAL IN CONFIDENCE Date: 28/08/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 ee alee
Basic Change - Type A Reference Data only (no PON verification I 4 1 5
Pure required)
Basic Change —__— [Type 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. 3&4]
Token verification.
ICON Change Introduction of new/amended ICON [see ref 20]
Fast-track:
Basic Express A subset of Basic HR, for a specific requirementto 1.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
outlet, normally where the product is already being
sold prior to migration.
[Tight Timescales IA change under contractual requirement 539/3, to [Agreed when
make any kind of Reference Data change quickly, injrequested
specified circumstances.
Business —CriticalAn advanced change which requires shorter lead [Agreed when
Advanced Change {time than would normally be required for such a requested
change
Live Fix A change to correct a live incident. (ref. section Defined in OLAs
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 16 of 1
FUJ00232480
FUJ00232480
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 7.0
COMMERCIAL IN CONFIDENCE Date: 28/08/2001
1.5.4 and 9.3). [refs. 12 & 13) I
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 17 of 1
FU.
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 7.0
COMMERCIAL IN CONFIDENCE Date: 28/08/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. It will be reviewed for
any future major software release and on an on-going basis. It is maintained by ICL
Pathway on behalf of both parties.
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:
FUJ00232480
}J00232480
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 18 of 1
FUJ00232480
FUJ00232480
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 7.0
COMMERCIAL IN CONFIDENCE Date: 28/08/2001
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.
e 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.
e 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 known 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: 19 of 1
FUJ00232480
FUJ00232480
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 7.0
COMMERCIAL IN CONFIDENCE Date: 28/08/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.
Interface Interface Interface
I PON Pathway Pathway PON Pathway
process process process I process * I process
* 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 section 3.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.
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.
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 20 of 1
FUJ00232480
FUJ00232480
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 7.0
COMMERCIAL IN CONFIDENCE Date: 28/08/2001
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: 21 of 1
FUJ00232480
FUJ00232480
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 7.0
COMMERCIAL IN CONFIDENCE Date: 28/08/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: 22 of 1
ICL Pathway
FUJ00232480
FUJ00232480
ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 7.0
COMMERCIAL IN CONFIDENCE Date: 28/08/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: 23 of 1
FUJ00232480
FUJ00232480
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 7.0
COMMERCIAL IN CONFIDENCE Date: 28/08/2001
ICL Pathway generates and delivers the RDMC
\Verification Report and the Comparison Report to
IBSM and delivers the actual Reference Data change
ito 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 Business
lauthorise Service
completed IManagement
change
IBSM verifies the OBCs on the counter / reports (as
lappropriate) and confirms the change as delivered is
he change required, and authorises the release of
he OBC to the live estate.
IBSM also sets the Alert flag on the Authorisation
Form, when appropriate. (see section 2.5)
IN.B. The following steps may stat
rt after step 1 and run in parallel
5 IReview ICL Pathway
(Counter
News
larticles
ICL Pathway reviews, and responds to, all relevant
(Counter News or other Horizon update articles beforeI
publication and distribution (when required) to
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
lin pursuit of the delivery of contractual services.
[The process is described in [ref 17]
DN: this process is still under discussion
6 IChange ICL Pathway
delivered to
counters
ICL Pathway releases Reference Data for all
lauthorised OBCs to the live estate.
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)
here agreed with PON, the release may be held
lpending 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).
3.5 ICON Change
Whilst the introduction of ICONs (the pictures which appear on buttons) on the
Horizon desktop is not contractually a part of the OBC process, the scope of this
document has been extende
dd to include the process for introducing new, or
amending existing, ICONs. The process and agreed timescales for ICON change
are described in [ref 20].
© 2001 ICL Pathway Limited
COMMERCIAL IN CONFIDENCE Page: 24 of 1
FUJ00232480
FUJ00232480
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 7.0
COMMERCIAL IN CONFIDENCE Date: 28/08/2001
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.
The RDCC Product Change categories that apply to these changes are listed in
sections 4.2 and 4.5 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 B: Standard Changes - Details, 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
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 25 of 1
FUJ00232480
FUJ00232480
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 7.0
COMMERCIAL IN CONFIDENCE Date: 28/08/2001
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
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.
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 26 of 1
FUJ00232480
FUJ00232480
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 7.0
COMMERCIAL IN CONFIDENCE Date: 28/08/2001
(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:
e Changing AP product details when an end-to-end test file is not required falls
outside the category of AP change and is to be treated in the same way as any
other product change.
e Ceasing AP Client, product or token when the service is Live, i.e. it is not being
withdrawn from a current CTO cycle, is to be implemented as an Advanced
Simple change, with the client service list being amended after the event.
4.4 ICON Change
Changes to ICONs are processed in a similar way to other OBC changes however,
in most cases ICONs are produced in batches rather than individually. Leadtimes
are currently under discussion. Full details of the process for ICON changes are
described in [ref 20]
4.5 Fast-track changes
4.5.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
ooo]
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 27 of 1
FUJ00232480
FUJ00232480
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 7.0
COMMERCIAL IN CONFIDENCE Date: 28/08/2001
the specified criteria it will be processed according to the normal lead-
times. ICL Pathway will inform PON using the incident process.
* 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 calendar
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 calendar 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 calendar day period.
4.5.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.
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.
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.
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 28 of 1
FUJ00232480
FUJ00232480
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 7.0
COMMERCIAL IN CONFIDENCE Date: 28/08/2001
4.5.3 Tight Timescales
4.5.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.5.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
e 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 the ICL
Pathway Customer Service Director or their nominated authorised deputies.
4.5.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 may be
processed via the fast-track Basic Express route.
b) Emergency cessation
From the CSR+ version of Horizon the ability to transact a product is controlled by
the use of Item Transaction Modes and therefore these type of changes may be
processed via the fast-track Basic Express route.
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.
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 29 of 1
FUJ00232480
FUJ00232480
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 7.0
COMMERCIAL IN CONFIDENCE Date: 28/08/2001
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. 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
e 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 ‘I + ‘I I 4 + I +2 I Weeks
Interim product __ Interim product enjetals Introdused or cla
introduced as introduced as introduced as_re-mapped at a
standard change high priority Basic Express later date asa
with interim exceptional ° standard change
values change with 9
interim values
4.5.3.4 Limitations when information is available at a very late stage
Whilst acknowledging that PON may not have control over legal or governmental
changes it must be recognised that the ability of the end to end process to produce,
check, authorise and release Reference Data takes a finite time and therefore it may
not be possible in all circumstances to meet the requirements. To this end the
following are guidelines to the limitations for Tight Timescales changes where the
information is only made available at a very late stage (e.g. 4 p.m. on a budget day).
« The time to key the data into the RDS system, extract and transmit to ICL
Pathway must be considered (probably a minimum of 1 hour)
« The time that RDMC takes to process the incoming data must be considered
(approximately 30 minutes)
e If counter checks at OSG are required an absolute minimum of 2 hours is
required for RDT system processing. It is therefore likely that this time will
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 30 of 1
FUJ00232480
FUJ00232480
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 7.0
COMMERCIAL IN CONFIDENCE Date: 28/08/2001
not be available and therefore checking of the data can only be by review of
reports — minimum of 30 minutes to produce and transmit to OSG
e The time that OSG will take to validate reports, or view data on counters
should time be available for extract, needs to be considered (estimated as a
minimum of 30 minutes)
e In order to meet normal operational schedules, authorisation to release a
Tight Timescales change should be received by ICL Pathway by 7:30 p.m.
e The introduction of new items is impossible overnight. If there is a possibility
that new items will be needed their skeleton data must be set up in advance,
as described above in section 4.5.3.3.c
e Changes to Menu Hierarchy can only be achieved within Tight Timescales
when sufficient time is available — under normal circumstances, where the
normal leadtime is not available, a Business Critical Advanced Change may
be appropriate
e An overnight change should therefore only be of the type which amends the
price or name of items
On the basis of the above timings, the latest time for commencement for an
overnight Tight Timescales change, such as Budget annoucements, to be with
RDOT for keying is 5 p.m. for a change to be checked by report and 3 p.m. for a
change to be checked by counter. Whilst these timings are theoretically possible
any error which occurs in data preparation or is discovered during checking may
affect the ability of all parties to complete the exercise. Therefore, wherever
possible more time should be given.
4.5.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)
4.5.5 Business Critical Advanced Change
It has been recognised that the ICL Pathway and PON operational units have the
ability, in some circumstances, to shorten the OBC lead time without adversely
impacting the success of the change, or any other change in the system.
A Business Critical Advanced Change category has been introduced to permit
operational units to decide, where possible, to deliver change within a shorter time
than the specified leadtime. _BCAC does not replace Tight Timescales but rather
offers an alternative, operational, method (similar to Basic Express) of progressing
Advanced changes.
= Each instance of a Business Critical Advanced Change must be agreed by each
the groups involved in the processing of the change (normally BSM/OSG, RDOT
and RDT) before the change is submitted to ICL Pathway for action. This must
include agreement on the effective date for the Reference Data
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 31 of 1
FUJ00232480
FUJ00232480
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 7.0
COMMERCIAL IN CONFIDENCE Date: 28/08/2001
= The leadtime requirement for such a change must be shorter than that which
would normally be required to complete the change
= The agreed leadtime requirement must be achievable
= Any errors or modifications which occur in the delivery of such a change are
likely to cause failure to achieve the agreed leadtime
= Only minimal changes to the Menu Hierarchy are possible within shortened
leadtimes. If the introduction of a new item is required in short timescales this
should be considered via the PLU in the first instance with buttons to follow
= A maximum of 1 such change is permitted within any single week and 2 such
changes in any rolling 4 week period
= RDORF may, by agreement, modify the maximum quoted above
= RDORF will review each instance of such a change to establish why it was
necessary to invoke this process (without prejudice to any business
confidentiality)
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 32 of 1
FUJ00232480
FUJ00232480
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 7.0
COMMERCIAL IN CONFIDENCE Date: 28/08/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: 33 of 1
ICL Pathway ICL Pathway / PON Interface Agreement for
Operational Business Change - Product
COMMERCIAL IN CONFIDENCE
FUJ00232480
FUJ00232480
Ref: CS/PRD/058
Version: 7.0
Date: 28/08/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: 34 of 1
FUJ00232480
FUJ00232480
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 7.0
COMMERCIAL IN CONFIDENCE Date: 28/08/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 days 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: 35 of 1
FUJ00232480
FUJ00232480
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 7.0
COMMERCIAL IN CONFIDENCE Date: 28/08/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: 36 of 1
ICL Pathway
ICL Pathway / PON Interface Agreement for
Operational Business Change - Product
COMMERCIAL IN CONFIDENCE
FUJ00232480
FUJ00232480
Ref: CS/PRD/058
Version: 7.0
Date: 28/08/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 2 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: 37 of 1
FUJ00232480
FUJ00232480
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 7.0
COMMERCIAL IN CONFIDENCE Date: 28/08/2001
5.6 Advanced Complex
Changes that require update Type C Reference Data.
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 4 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: 38 of 1
ICL Pathway
ICL Pathway / PON Interface Agreement for
Operational Business Change - Product
COMMERCIAL IN CONFIDENCE
FUJ00232480
FUJ00232480
Ref: CS/PRD/058
Version: 7.0
Date: 28/08/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.5.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: 39 of 1
FUJ00232480
FUJ00232480
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 7.0
COMMERCIAL IN CONFIDENCE Date: 28/08/2001
5.9 Migration Special
To meet the need to apply a quick change to the Product to Outlet mappings for an
outlet
Action Result Milestone Owner
required change identified Notify RDOT * PON
RDOT input Reference Send to Pathway * PON
Data
Pathway process change Release change - 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: 40 of 1
FUJ00232480
FUJ00232480
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 7.0
COMMERCIAL IN CONFIDENCE Date: 28/08/2001
6 Volume of change
6.1 Introduction
The PON forecast volume of Operational Business Change is shown in Appendix A:
OBC Volumes for Year 2001
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 A] is deemed to be
the baseline volume of OBCs for this agreement for the year 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: 41 of 1
FUJ00232480
FUJ00232480
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 7.0
COMMERCIAL IN CONFIDENCE Date: 28/08/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 Postcomm.
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 42 of 1
FUJ00232480
FUJ00232480
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 7.0
COMMERCIAL IN CONFIDENCE Date: 28/08/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: 43 of 1
FUJ00232480
FUJ00232480
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 7.0
COMMERCIAL IN CONFIDENCE Date: 28/08/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: 44 of 1
FUJ00232480
FUJ00232480
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 7.0
COMMERCIAL IN CONFIDENCE Date: 28/08/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
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: 45 of 1
FUJ00232480
FUJ00232480
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 7.0
COMMERCIAL IN CONFIDENCE Date: 28/08/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: 46 of 1
FUJ00232480
FUJ00232480
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 7.0
COMMERCIAL IN CONFIDENCE Date: 28/08/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: 47 of 1
FUJ00232480
FUJ00232480
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 7.0
COMMERCIAL IN CONFIDENCE Date: 28/08/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
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.
VVVVV
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).
Vv
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].
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: 48 of 1
FUJ00232480
FUJ00232480
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 7.0
COMMERCIAL IN CONFIDENCE Date: 28/08/2001
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.
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 49 of 1
FUJ00232480
FUJ00232480
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 7.0
COMMERCIAL IN CONFIDENCE Date: 28/08/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.
« 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: 50 of 1
FUJ00232480
FUJ00232480
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 7.0
COMMERCIAL IN CONFIDENCE Date: 28/08/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. 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.
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
« AP Client Take-On is charged as specified [see ref. 3].
« Deviations to the service will be charged as per the CCN.
e Invoices will be raised and paid in accordance with Schedule A10.
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 51 of 1
FUJ00232480
FUJ00232480
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 7.0
COMMERCIAL IN CONFIDENCE Date: 28/08/2001
10 Appendix A: OBC Volumes for Year 2001
The volume of change estimated by PON for the year 2001 is as follows.
The values were provided initially in December 1999, and amended during 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 iD
Subtotali1232
(Advanced Simple
(Change additional fields 18
Subtotali18
Advanced Standard
(Change accounting calendar 4
Subtotall1
Advanced Complex
Add EPOSS product 516
Permanent cessation of product 363
(Change mapping to c/a 24
(Change Menus 13,
Prange picklist ordering:
Cash Declaration/ONCH 4
Cash Rem Out - Notes 4
Cash Rem Out - Coin Full Bags 4
Cash Rem Out - Coin Partial Bags 4
Cash Rem Out - Unusable Coin 41
2
3
ri
CRE OVS
Rem Out - Other Postage Stamps
Change Royal Mail tariff
(Change Advice Notes Product Group Ordering (add or
remove Group, alter order)
(Change Parcelforce tariff (limited range) 4
(Change Non-Value Stock Product Group Ordering (addor {8
remove Group, alter order)
(Change Non-Value Stock Item Ordering within Product GroupI1
(Change Advice Notes Item Ordering within Product Group _/
Subtotali952
Advanced AP
Add AP client 251
Add AP service 111
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 52 of 1
FUJ00232480
FUJ00232480
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 7.0
COMMERCIAL IN CONFIDENCE Date: 28/08/2001
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 bE
INew VAT E
INew currency k
(Change currency bE
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: 53 of 1
FUJ00232480
FUJ00232480
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 7.0
COMMERCIAL IN CONFIDENCE Date: 28/08/2001
11 Appendix B: 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.
11.1.1 Basic - Pure
Increase product availability (non-core)
Change clerk instructions
11.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
Cease Item Transaction Mode for a product
Restart Item Transaction Mode for a product
Change ability to print receipt
11.1.3 Advanced Simple
Non core product becomes core
Change use of additional fields
11.1.4 Advanced Standard
Change discount indicator (not used)
Change value to non-value stock
Change client name — non AP
Change calendar
Remove AP client
Change pick-list for existing product
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 54 of 1
FUJ00232480
FUJ00232480
ICL Pathway ICL Pathway / PON Interface Agreement for Ref: CS/PRD/058
Operational Business Change - Product
Version: 7.0
COMMERCIAL IN CONFIDENCE Date: 28/08/2001
11.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)
Change scales matrix/tariff change (no Type C required but BSM need extra
time to verify the OBCs).
Change screen layout (Menu Hierarchy)
Change accounting node
Change Best Fit screens
Add Item Transaction Mode with Item Transaction Mode Code
Change Picklist ordering: t
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 items are to be included in the next version of the RDCC.
© 2001 ICL Pathway Limited COMMERCIAL IN CONFIDENCE Page: 55 of 1