FUJ00232439
FUJ00232439
ICL Pathway ICL Pathway/POCL Interface Agreement Ref:CS/PRD/058
for Operational Business Change - Version:2.0
Product Date:8/7/99
Document Title:
Document Type:
Abstract:
Status:
Distribution:
Author:
Comments to:
Comments by:
ICL Pathway/POCL Interface Agreement for Operational
Business Change - Product
Interface Agreement
This document sets out the detailed interface between
ICL Pathway and POCL in respect of Operational
Business Change — Product for Core System Release
(CSR) -formerly New Release 2). It defines the customer
and supplier responsibilities which POCL and ICL
Pathway must undertake in order to support the delivery
of changes.
APPROVED
ICL Pathway
Reference Data Team Dennis Sandor
Dave Fletcher Martin Riddell
Alison Peacock David Wilcox
Lorraine Holt John Wright
Library
POCL
Geoff Darby
Andy Corbett Phil Ryan
Ruth Holeran Andy Radka
Jayne Westwood Ijaz Bhatti
Steve Hillsden Nick Beal
Matt Warren Nick Embling
David Anders
Horizon
Bruce Talmage
Alison Peacock /David Wilcox
COMMERCIAL IN CONFIDENCE Page 1 of 34
ICL Pathway
FUJ00232439
FUJ00232439
ICL Pathway/POCL Interface Agreement Ref:CS/PRD/058
for Operational Business Change - Version:2.0
Product Date:8/7/99
0.1 Document control
0.1. Document history
Version
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
1.0
14
2.0
Date
09/02/99
18/02/99
22/03/99
23/03/99
31/03/99
23/4/99
25/5/99
18/6/99
25.6.99
7.7.99
8.7.99
Reason
First Draft
Second Draft — supersedes first draft
Third Draft — incorporates comments from Alison Peacock and
David Fletcher
Fourth Draft — incorporates changes from David Wilcox
Fifth draft — correction to section numbering and other
comments
Sixth draft — following comments from POCL as discussed with
Geoff Darby.
To include changes proposed in the POCL/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.
To include changes proposed in the POCL/ICL Pathway
acceptance review meeting of 9/6/99.
Baseline version
Incorporate comments from POCL and Pathway
Updated baseline
0.2 Approval authorities
Name
Stephen Muchow
Ruth Holleran
Position Signature Date
ICL Pathway Customer
Service Director
COMMERCIAL IN CONFIDENCE Page 2 of 34
© 1999 ICL Pathway Ltd
FUJ00232439
FUJ00232439
ICL Pathway ICL Pathway/POCL Interface Agreement Ref:CS/PRD/058
for Operational Business Change - Version:2.0
Product Date:8/7/99
0.3. Associated documents
Please see library for details of latest versions of documents.
Reference Vers Date Title Source
1 CS/PRD/O30 1.2 29/3/99 Process for Operational Business Pathway
Change - product
2 CS/IFS/001 2.0 7/6/99 Reference Data Change Catalogue Pathway
3 AP/PRD/O01 1.1 5/3/99 APS Client Take-on process Pathway
CR/FSP/016 APS Token Verification Service Pathway
Description - NR2
5 RDP/AIS/001 3.3 2/2/98 AIS Reference Data to Pathway Type A POCL
Data
6 RDP/AIS/008 0.2 23/12/98 AIS Reference Data to Pathway Type B POCL
Data
7 CS/PRD/048 0.4 6/5/99 Changing Reference Data to Tight Pathway
Timescales
8 IM/MAN/O12 HFSO Guide — Manual Outlets
9 IM/MAN/013 HFSO Guide — Ecco
10 CR/REQ/ 0.1 Product Change Requirement and Pathway
Service Matrix
11 CS/IFS/002 1.0 1/10/98 Reference Data Change Class 1 Pathway
Analysis
12 CS/PRD/O46 0.2 16/4/99 Reference Data End-to-end Pathway
Reconciliation Process For Release
NR2
13. RDS/OLA/001 1.0 26/3/99 Reference Data- POCL/ICL Pathway POCL
Operational Level Agreement
14 CS/PRD/028 1.3 6/5/99 Process for Changing Menu Hierarchies ICL
and Icons Pathway
0.4 Glossary
AP Automated Payments
HFSO Horizon Field Services Officer
HD Reference Data changes are ‘HD’ when the change is relevant only to the
HelpDesk e.g. telephone number
HR Reference Data changes are ‘HR — High Risk’ when verification is
required (but are not subject to advanced notification)
COMMERCIAL IN CONFIDENCE Page 3 of 34
FUJ00232439
FUJ00232439
ICL Pathway ICL Pathway/POCL Interface Agreement Ref:CS/PRD/058
for Operational Business Change - Version:2.0
Product Date:8/7/99
Pure When used in reference to a Reference Data Change ‘Pure’ indicates
data which is considered to be of low risk to business integrity
RDCC Reference Data Change Catalogue
RDT ICL Pathway Reference Data Team
RDP POCL Reference Data Project
RDMC ICL Pathway Reference Data Management Centre
RM ICL Pathway Release Management
RDOT Reference Data Operational Team (POCL)
RDS POCL Reference Data System
Type A Data transmitted electronically from RDS to RDMC over an automated
interface
Type B Data transmitted electronically from RDS to RDMC over a non-automated
interface
Type C Data prepared by ICL Pathway, usually derived from Type B Data
0.5 Changes in this version
Includes some changes requested by POCL and clarifications requested by
Pathway.
Replace references to RDP with RDOT
0.6 Planned Changes
Update document references
® Revise entries relating to the scorecard
COMMERCIAL IN CONFIDENCE Page 4 of 34
ICL
FUJ00232439
FUJ00232439
Pathway ICL Pathway/POCL Interface Agreement Ref:CS/PRD/058
for Operational Business Change - Version:2.0
Product Date:8/7/99
0.
10. VOLUMES.
6 Table of content
INTRODUCTION...
INTENT OF THIS AGREEMENT...
SCOPE.........
OPERATIONAL BUSINESS CHANGE...
ROLES AND RESPONSIBILITIES...
5.1 POCL - GENERAL... oe
5.2 POCL - OUTLET SysTEms GRouP
5.3 POCL - REFERENCE DATA OPERATIONAL TEAM
5.4 POCL NeETWorK BUSINESS SUPPORT CENTRE (NBSC).
5.5 ICL PATHWAY RESPONSIBILITIES...
5.6 HORIZON SERVICE HELPDESK (HSH).
CHANGE COMMUNICATIONS...
MODELS...
7.1 INTRODUCTION.
7.2 FAST TRACK,
7.3. IMPACT OF VOLUME.
7.3.1 Bulk changes.
7.3.2 End of yeai
7.3.3 Tariff changes.
MILESTONES...
8.1 Basic.
8.2 BASIC EXPRESS...
8.2.1 Timescales.
8.3 MIGRATION SPECIAL.
8.3.1 Timescale:
8.4. ADVANCED SIMPLE.
8.5 I ADVANCED STANDARD.
8.6 ADVANCED, COMPLEX.
8.7 APCTO.
8.8 TIGHT TIMESCALES
8.8.1 Requirement.
8.8.2 Types...
8.8.3 Price Change...
8.8.4 Emergency cessation.
8.8.5 Last minute amendments.
8.9 ERROR CORRECTION.
RDCC CATEGORIES..
9.1 BASIC (2 WEEKS)...
9.2 BASIC EXPRESS (2 DAYS)...
9.3 ADVANCED SIMPLE (2 WEEKS
9.4 ADVANCED STANDARD (4 WEEKS).
9.5 ADVANCED, COMPLEX (6 WEEKS: .
9.6 AP (AS AGREED IN AP CTO & TOKEN VERIFICATION DOCUMENTS)..
10.1 NORMAL.
COMMERCIAL IN CONFIDENCE Page 5 of 34
FUJ00232439
FUJ00232439
ICL Pathway ICL Pathway/POCL Interface Agreement Ref:CS/PRD/058
for Operational Business Change - Version:2.0
Product Date:8/7/99
11. COMMERCIAL IMPLICATIONS.
11.1. ORDER AND PAYMENT...
11.2 FAILURE TO ACHIEVE LEAD TIM
12. DEVIATIONS.....
13. APPENDIX A.
COMMERCIAL IN CONFIDENCE Page 6 of 34
FUJ00232439
FUJ00232439
ICL Pathway ICL Pathway/POCL Interface Agreement Ref:CS/PRD/058
for Operational Business Change - Version:2.0
Product Date:8/7/99
1. Introduction
Currently there are a number of documents that describe the interfaces and
agreements made between ICL Pathway and POCL for change management of
Operational Business Changes laid down in [reference 10] — Service Matrix and
requirements for OBC product. There is a need to formally baseline these
documents under the contract. This interface agreement will incorporate the
agreements and become a contractually controlled document.. The working level
documents for OBC will comply with the agreements in this interface agreement.
This document exists in parallel with the OBC Requirements, Service Matrices /
Service Descriptions [ref 10].
2. Intent of this Agreement
The intent of the agreement is:
« To establish effective co-operation between ICL Pathway and POCL in the
delivery of Operational Business Change - Product, to the Post Office
counters
e Agree responsibilities and detail the interactions which must take place,
between POCL and ICL Pathway, to ensure the successful delivery of
changes within the Post Office retail network
This agreement is for the duration of Core System Release (fomerly known as New
Release 2) and will be reviewed at the end of Live Trial.
3. Scope
This document specifies how product change will be achieved through the
application of Operational Business Change procedures, which support the delivery
of pre-defined change types - as declared in reference [1].
The procedures supported by this document are those that will be used to manage
the delivery of basic and advanced changes for product Reference Data, where:
e a basic change is a change which consists solely of Reference Data which
requires no ICL Pathway intervention and may be submitted to ICL Pathway
without notice
e an advanced change is a change which requires additional ICL Pathway activity
and is subject to advanced notification
Specific areas described in this agreement are:
COMMERCIAL IN CONFIDENCE Page 7 of 34
FUJ00232439
FUJ00232439
ICL Pathway ‘ICL Pathway/POCL Interface Agreement Ref:CS/PRD/058
for Operational Business Change - Version:2.0
Product Date:8/7/99
Principles of Operational Business Change
Key Roles and Responsibilities
Description of Communications
Events and Milestones
Business Rules
Deviations to agreed standards
eoeeee
4. Operational Business Change
This section describes the high level view of Operational Business Change
processes for product changes. For full details of the processes see [ref 1].
Product Change - Operating Principles
By POCL also not
rag 1 requirement
1)
POCL request a Change I xy
Change request made to Pathway
POCL RDS of change
I
4) Pathway request a produehange
service from internal suppliers & OSG
Tnternal Suppliers Deliver
Service 1
Service 2
The information relevant to any given ADVANCED product change is
submitted by the Outlet Systems Group to ICL Pathway. The submission is
made to the Operational Business Change Product mailbox on an OBC2 form
or an OBC9 AP form. The receipt of the OBC form is the request for change
from POCL to Pathway.
At the same time (and if appropriate), a parallel submission of change
information will be made by the Outlet Systems Group to the POCL
Reference Data Operational Team — who make the relevant Reference Data
COMMERCIAL IN CONFIDENCE Page 8 of 34
FUJ00232439
FUJ00232439
ICL Pathway ICL Pathway/POCL Interface Agreement Ref:CS/PRD/058
for Operational Business Change - Version:2.0
Product Date:8/7/99
changes and pass them to ICL Pathway for application on the Horizon
system.
It is important to note that changes sent to ICL Pathway are separated into
‘Units of release’, that is an entity which, when properly authorised by OSG,
is available to be released to the ‘Live’ environment. This must be taken into
account when data is sent to ICL Pathway to ensure that all data required for
any change is included within a single ‘Unit of Release’ and that where data
for different changes are included within the same file set, all data will be
released at the same time. This means that data which has the longest lead
time will define the earliest that the ‘Unit of Release’ will be sent to the ‘Live’
environment.
The information relevant to any given BASIC product change is submitted by
the POCL Reference Data Operational Team — who make the relevant
Reference Data changes and pass them to ICL Pathway. Basic changes
consist of only Class 1 data [see ref 11 for a definition of Class 1 data]. The
receipt of the data file containing Basic (Class 1 only) data is the request for
change from POCL to Pathway.
The ICL Pathway Reference Data Team then follows the Management
Process for Operational Business Change — Product [ref 1] to manage the
delivery of the specific change.
COMMERCIAL IN CONFIDENCE Page 9 of 34
FUJ00232439
FUJ00232439
ICL Pathway ICL Pathway/POCL Interface Agreement Ref:CS/PRD/058
for Operational Business Change - Version:2.0
Product Date:8/7/99
5. Roles and Responsibilities
5.1 POCL - General
a)
Identify planned changes to current product range
Planning, initiating and managing changes to the product range
Adhering to agreed timescales [see section8]
Notifying Post Office outlets and clients of product change
Using agreed documentation and procedures [see ref 1 & 13]
Using agreed channels of communication
Maintenance and security of the OBC product and Reference Data
verification mailboxes on POCL servers
Communication of change exception information to ICL Pathway
Support of agreed error management processes
Application of correct procedure type
Ensure that ICL Pathway are notified of any exceptions to normal procedures
e.g. Requirement for change to Tight Timecales
Maintain POCL details within the change contacts list
Maintain reference documents in POCL e.g. copy of the menu hierarchy.
5.2 POCL - Outlet Systems Group
Process and communicate advanced product changes to ICL Pathway
ensuring, where necessary, that changes are submitted separately
Allocate unique Change Control Number for advanced changes.
Ensure all required change information and data is submitted to ICL Pathway
and RDS Chesterfield e.g. menu hierarchy information [ref 14].
Liase with relevant departments in POCL to collect all information, allowing
OSG to hold the position of 'single interface to Pathway’ for product changes.
Ensure all required AP information is sent at the agreed time, including Client
Take-on packs etc.
Ensure the accuracy and integrity of the change information provided to ICL
Pathway
Verify changes and sign off ready for release
Handle any queries that may crop up during any part of change process
Review the necessity of changing the OBC process and forms in light of
experience e.g. to incorporate the Accounting Node information
5.3 POCL - Reference Data Operational Team
a)
Process and transmit basic Reference Data changes to ICL Pathway over
agreed routes to agreed timetable, as specified in the OLA [ref 13].
COMMERCIAL IN CONFIDENCE Page 10 of 34
FUJ00232439
FUJ00232439
ICL Pathway ICL Pathway/POCL Interface Agreement Ref:CS/PRD/058
for Operational Business Change - Version:2.0
Product Date:8/7/99
b) Supply Reference Data to support advanced change in accordance with
standards laid down in ref [13]
c) Allocate unique Change Control Number for Basic changes.
5.4 POCL Network Business Support Centre (NBSC)
a) Provide an interface to register POCL incidents.
b) Monitor and track POCL incidents through to resolution.
5.5 ICL Pathway responsibilities
a) Receipt and progression of basic Reference Data change requests through
agreed Reference Data change procedures
b) Receipt and progression of advanced Reference Data change requests sent
electronically by POCL to the OBC Product Change Mailbox
c) The provision of changed Reference Data and reports for verification in
accordance with agreed procedures
d) The assessment of advanced change and the identification and delivery of
the change services needed to satisfy specific changes
e) Adherence to agreed timescales
f) Ensuring that supporting ICL Pathway processes are implemented to manage
the delivery of change services
g) Communicating issue and exception information to POCL to enable them to
manage and control all their relevant change activity on the POCL side of the
change interface.
h) The provision, when appropriate e.g. for AP client take on, of invoices for the
completion of work
i) The maintenance of the ICL Pathway Details within the OBC Product Change
contacts list
5.6 Horizon Service Helpdesk (HSH)
a) Provide an interface to register Pathway incidents.
b) Monitor and track Pathway incidents through to resolution.
6. Change Communications
The OBC Product Change Mailbox is the channel by which advanced change
requests are made to ICL Pathway and by which communication pertinent to the
delivery of advanced change requests is managed.
The information relevant to any given change will be submitted to ICL Pathway, via
the OBC Product change mailbox on an OBC2 form (EPOSS Adv) or OBC 9 form
(AP).
COMMERCIAL IN CONFIDENCE Page 11 of 34
FUJ00232439
FUJ00232439
ICL Pathway ICL Pathway/POCL Interface Agreement Ref:CS/PRD/058
for Operational Business Change - Version:2.0
Product Date:8/7/99
The OBC Product Change Mailbox will be monitored each ICL Pathway working day,
as defined in the OLA [ref 13] and requests will be either:
« Accepted by ICL Pathway as a confirmed order for work and (if the submission
has been made on the OBC2/OBC9/OBC20 form)
e Rejected if the forms are incomplete, incorrect or of a change type not described
in the matrix [ref 10]
All data required for Reference Data changes will be delivered by the mechanisms
described in the appropriate interface agreements or processes as appropriate.
OBC9 forms are for AP Client take-on only and will require further details along with
the request as described in ref [3] and ref [4].
ICL Pathway will be unable to process any change until the required data for the
change has been received.
In the event of problems occurring with transfer of data and or e-mail alternative
forms of information transfer will be used, e.g. Fax, floppy disc.
COMMERCIAL IN CONFIDENCE Page 12 of 34
FUJ00232439
FUJ00232439
ICL Pathway ICL Pathway/POCL Interface Agreement Ref:CS/PRD/058
for Operational Business Change - Version:2.0
Product Date:8/7/99
7. Models
7.1 Introduction
This document describes several models which define the milestones for a change.
Each category in the RDCC can be associated with one of these models. The lead
time runs from initiating a change until the change is used on the counter e.g. the
change starts when the new product can be remmed in on the counter (NOT sold)
and the lead time in these models includes POCL times and Pathway times.
The models are:
Basic change [Type A only]
Advanced, simple change [Type A, plus after-the-event changes]
Advanced, standard change [Type A, Type B, Scorecard, Testing]
Advanced, complex change [requires Type C data]
Basic express [limited service]
Migration special [product to outlet mapping, only]
Tight Timescales [Contractual requirement]
Error correction
ercececeeee
7.2 Fast track
The Term ‘Fast track’ is used to refer to four different scenarios:
1. Basic Express
An agreed lead time for a specific requirement to change certain data quickly.
Basic Express is addressed by section 8.2 e.g. it applies to changing the price of
bus fokets in 2 days (end to end). The limits for its use are defined in that
2. Tight Timescales
A contractual requirement to make any kind of reference data change quickly, in
certain circumstances.
The service that meets the Tight Timescales requirement is described in section
8.8.
COMMERCIAL IN CONFIDENCE Page 13 of 34
FUJ00232439
FUJ00232439
ICL Pathway ICL Pathway/POCL Interface Agreement Ref:CS/PRD/058
for Operational Business Change - Version:2.0
Product Date:8/7/99
3. Error Correction
When there is a need to correct errors quickly to reduce or remove the impact of
those errors quickly.
The method of changing data quickly for Error Correction purposes is described
in [ref 12] e.g. if data sent from POCL is found by Pathway to be incorrect, then
an incident will be raised to notify POCL of the error and corrected data will be
sent. The limits for its use are defined in that document.
4. Migration Special
To meet the need to apply a quick change to the Product to Outlet mappings for
an outlet which is being migrated. See section 8.3.
7.3 Impact of volume
7.1.1 Bulk changes
High volumes of OBC change, either in the form of many changes or one large
change, cause an overhead on both POCL and ICL Pathway operational units and
reduces the ability of the operational teams to achieve the milestones detailed in
section 8. In order to manage requests for high volumes of change POCL will
review bulk change situations and confirm with the operational units in POCL and in
ICL Pathway that the OBC requests can be met, in advance of agreeing with the
originator the deadline for delivery. Deviations to the models in this document will be
agreed on a case by case basis [see section 12]. The expectation is some planning
for bulk changes will be done in advance of normal lead times.
7.1.2 End of year
The end-of-year changes are an extreme form of bulk changes which need to go live
in March/April. They include cash account changes (not OBC), budget changes,
homecare stamp changes and tariff changes. The milestone models in section 8 do
not apply to end of year changes. End-of-year change needs to be managed as a
separate 'bulk change’ project.
7.1.3 Tariff changes
A tariff change may occur at other times of the year, but would still be a bulk change
and needs to be managed carefully.
COMMERCIAL IN CONFIDENCE Page 14 of 34
FUJ00232439
FUJ00232439
ICL Pathway ICL Pathway/POCL Interface Agreement Ref:CS/PRD/058
for Operational Business Change - Version:2.0
Product Date:8/7/99
8. Milestones
The milestones for these models are given in sections 8.1 - 8.7.
The models do not show activities that occur in parallel within Pathway. The
diagrams were produced in this way to allow a simple view of the milestones.
N.B. these milestones only apply for ONE change, and do not take into
account the impact of volume [see section 7.3].
ICL Pathway commits to all reasonable endeavours to deliver changes to ICL
Pathway agreed lead times. POCL must meet its milestones for end to end lead
times to be achieved.
When viewing these lead times it is important to take into account that ICL Pathway
can only prepare for an advanced change when the notification arrives. Processing
the change can usually only occur when all the necessary data has been supplied
by POCL. Where ICL Pathway ‘Type C’ data is required there is a need for ICL
Pathway Development activity. The timescale for this activity is dependent on the
type of change being made and must be taken into account in the overall ICL
Pathway leadtime. When ICL Pathway have completed work on an advanced
change the data is passed to OSG Farnborough for verification and authorisation.
ICL Pathway will not release changes to the ‘Live’ environment until authorisation is
received.
Lead times
Leadtimes must be measured with reference to the date that the change needs to
be at the outlet. This is not necessarily the date on which the change becomes
effective. Examples:
e if a product needs to be Remmed-in 6 weeks before the product is available to
sell, the lead time is measured to the date of Rem-In (when the data must be
functioning on the counter) and not to the Sell date,
e if a price change is a revaluation, the data needs to be at the counter 3 days in
advance of the change, to allow notice to be given to the Postmasters to revalue
e if achange is ready to be released 7days in advance of the date it needs to be on
the counter, the data does not need to be released until 3 days in advance.
SLA
The SLA for measurement of delivery of Reference Data to the counters is defined
in schedule G10 of the contract. The models below are built as if the authorisation
for a change is delivered overnight and the change being processed by ICL Pathway
the next working day. In practice, provided authorisation is received by ICL Pathway
by 4pm on any working day the change will normally be released on that day for
processing overnight according to the schedule.
COMMERCIAL IN CONFIDENCE Page 15 of 34
FUJ00232439
FUJ00232439
ICL Pathway ICL Pathway/POCL Interface Agreement Ref:CS/PRD/058
for Operational Business Change - Version:2.0
Product Date:8/7/99
8.1 Basic
With verification (HR) = 10 days
Without verification (Pure) = 6 days
Changes that involve changing Type A data only.
Action Duration I Result Milestone
Business generates 1 day Deliver to OSG Day 1
change
OSG processes change 1 day Deliver data to Day2
RDOT
RDOT input data 2 days Send to Pathway Day 4 (8pm)
System processes Available to Day 5 (8am)
overnight Pathway
Pathway process change 2 days Release change Day 6 (6pm)
(Pure)
or Handover to RM Day 6 (6pm)
(HR)
Pathway generate 1 day Deliver verification Day 7 (6pm)
verification reports reports to OSG
OSG check reports 2 days Notifies Pathway of Day 9 (6pm)
acceptance
Pathway process 1 day Release change Day 10 (6pm)
acceptance
System processes Data at counters (release day +1
overnight 97% nwd)
Data at counters (release day +2
99% nwa)
Data at counters (release day +3
100% nwd)
Note:
day = working day (Mon-Fri, excluding public holidays)
nwd = non working days included (Mon-Sun)
times = latest time action can occur to meet the schedule
COMMERCIAL IN CONFIDENCE
Page 16 of 34
FUJ00232439
FUJ00232439
[ omar 99 [oa mar oo [ismarse [mare iE
10 {reskname puaion [w[ TT WITTFTSTS[ IT [WITTFTSTS[u] tIwIt[ FT STs] ml twit TFT STs] w
1 JBsie change (2) 10 days =
z ‘4 ys rock I
I Business generates chan) 1 day} I I
[aT] 086 processes data Yay me
[5] ROP input cata re]
[e-] Pathe least days Patay I
[7] Rorprocesess dala 2 ay
re] ROT release change punt O days I
TS] Rit generate vertieatons 1 aay I I
[Te] Poet tacime 2daysI Pee I
[a] 086 very change 2aay
TZ I Pathway loadtime 4a Pathway
[7] Ritprocess acceptance 1a I
77 Release change HR) Oday 3
[sata ry sa
[re] Bata at counter 75% ‘ay fh I
77] Data at counters 85% 2days i ‘
TE I Data at counters 100% 3 days —
3
58
COMMERCIAL IN CONFIDENCE
Page 17 of 34
FUJ00232439
FUJ00232439
ICL Pathway ICL Pathway/POCL Interface Agreement Ref:CS/PRD/058
for Operational Business Change - Version:2.0
Product Date:8/7/99
8.2 Basic Express
An agreed lead time for a specific requirement to change certain data quickly.
Basic Express is addressed by this document. The limits for its use are:
only for the categories of change defined in section 9.2 below and
for changes which must be active on completion of the change
for changes which are received by Pathway by 10am and
it is anticipated that the volume of change will not be more than once a
week. Should the volume be greater, these changes will be processed but
the lead time cannot be guaranteed to be more than for a normal Basic
change. Service reviews will also be held.
ooofo
In order to identify that a change requires handling in this way the Change
Number must start with an agreed prefix and the other details must be as
described above. If a Change is delivered to ICL Pathway with this prefix but
the contents to not meet the specified criteria it will be processed according to
the normal leadtimes.
This service should be used sparingly as changes of this type are likely to have
impact on other changes already being processed by ICL Pathway and POCL.
If the limit is exceeded ICL Pathway and POCL may be unable to meet other
Leadtimes, OLA’s or SLA’s.
8.2.1 Timescales
Changes that involve only Type A data and are one of the named change types in
[section 9.2], the change must be required to be active on the counter within 48hrs,
the number of changes of this type are limited in number within any period, the
Change Number must have an agreed prefix.
Note: it is recommended that the normal e-mail communication is replaced by fax &
confirmed by phone for Express changes, due to the unreliability of the e-mail
system e.g. delivery can take over 3 hours.
COMMERCIAL IN CONFIDENCE Page 18 of 34
FUJ00232439
FUJ00232439
ICL Pathway ICL Pathway/POCL Interface Agreement Ref:CS/PRD/058
for Operational Business Change - Version:2.0
Product Date:8/7/99
Action Duration I Result Milestone
Business generates 2 hours Deliver to OSG Day 1 (10am)
change
OSG processes change 3 hours Deliver data to Day 1 (1pm)
RDOT
RDOT input data 7 hours I Send to Pathway Day 1 (8pm)
System processes Available to Day 2 (8am)
overnight Pathway
Pathway process change 1 hour Handover to RM Day 2 (10am)
(HR)
Pathway generate 2 hours Deliver verification Day 2 (noon)
verification reports reports to OSG
OSG check reports 4 hours Notifies Pathway of Day 2 (4pm)
acceptance
Pathway process 2 hours Release change Day 2 (6pm)
acceptance
System processes Data at counters (release day +1
overnight 97% nwd)
Data at counters (release day +2
99% nwd)
Data at counters (release day +3
100% nwd)
Note:
day = working day (Mon-Fri, excluding public holidays)
nwd = non working days included (Mon-Sun)
times = latest time action can occur to meet the schedule.
Task Name
iid E
tLe Re ele eel oles ee eee el ee
=
[Basic Express (E2E)
POCL leactine
‘Business generates change:
(086 processes data
ROP input data
atvway leadtime
ROT provesess data
FW generate veiication report
POCL Leackime
(086 very ehange
Pathway loadtime
FW process acceptance
Release change (HR)
LA
‘Data at counter 97%
Data at counters 09%
‘ala at counters 100%
Poct
COMMERCIAL IN CONFIDENCE
Page 19 of 34
FUJ00232439
FUJ00232439
ICL Pathway ICL Pathway/POCL Interface Agreement Ref:CS/PRD/058
for Operational Business Change - Version:2.0
Product Date:8/7/99
8.3 Migration special
To meet the need to apply a quick change to the Product to Outlet mappings for
an outlet which is currently being migrated. It is:
for migration use only
© for Non-core Product to Outlet mappings only
for data received by Pathway by 10am
If the HFSO discovers that there is a discrepancy in the Product to Outlet
mapping (also referred to as non-core items) at the Outlet which he is currently
migrating there will be an agreed procedure set down in references [8 & 9] for
the HFSO to contact RDOT with the requested change. This change will be
notified to ICL Pathway by the fact that the Change Number is in an agreed form
e.g. XXffffff (where ffffff is the FAD Code for the outlet) and the change only
contains Product to Outlet mapping data for an outlet currently being migrated.
If the file sent contains any other data or does not have a change number of the
prescribed format the file will be treated as would any other data file.
This process may also be used immediately following migration where mapping
errors are subsequently found.
Once ICL Pathway have confirmed that the data is of the required type the
change information will be released to the ‘Live’ environment as quickly as
possible. The authorisation for this release is implied by the Change Number
and will be confirmed by OSG as soon as possible after the event.
8.3.1 Timescales
Migration special changes are changes (usually additions) to the reference data
defining which non-core products a particular outlet can sell, where the office has
been selling the item but the reference data does not reflect this. This data is
needed so that the cash account can record those sales, when it is migrated to the
Horizon system.
COMMERCIAL IN CONFIDENCE Page 20 of 34
FUJ00232439
FUJ00232439
ICL Pathway ICL Pathway/POCL Interface Agreement Ref:CS/PRD/058
for Operational Business Change - Version:2.0
Product Date:8/7/99
Action Result Milestone
HFSO identifies required Notify RDOT
change
RDOT input data
Pathway process change
Pathway generate
verification reports
OSG check reports
System processes
Send to Pathway
Release change
Deliver verification
reports to OSG
Notifies Pathway of
acceptance
Data at counters 97% (release day +1
overnight nwd)
Data at counters 99% (release day +2
nwd)
Data at counters (release day +3
100% nwd)
Note:
day = working day (Mon-Fri, excluding public holidays)
nwd = non working days included (Mon-Sun)
Migration data files (identifiable as such) arriving by 10am will be released by
Pathway for distribution that night, for delivery by the next morning.
Migration data files (identifiable as such) received by Pathway by 4pm and
accompanied by a notifying ‘phone call, will be released that day for delivery to the
counter by the next morning.
In both cases the authorisation for release of the data is implied by the change
number. OSG will confirm this authorisation retrospectively.
COMMERCIAL IN CONFIDENCE
Page 21 of 34
FUJ00232439
FUJ00232439
ICL Pathway ICL Pathway/POCL Interface Agreement Ref:CS/PRD/058
for Operational Business Change - Version:2.0
Product Date:8/7/99
8.4 Advanced simple
Changes requiring advanced notification that involve Type A data changes only
before release.
Action Duration I Result Milestone
Business generates 1 day Deliver to OSG Day 1
change
OSG processes change 1 day Deliver notification Day 2
to Pathway
1 day Deliver data to Day 2
RDOT
RDOT input data 2 days Send to Pathway Day 4
(8pm)
System processes Available to Day 5
overnight Pathway (8am)
Pathway process request 2 days Preparations Day 4
for change complete
Pathway processes data 2 days RDT hand over to Day 6
RM
Pathway generate 1 day Deliver verification Day 7
verification reports reports to OSG
OSG check reports 2 days Notifies Pathway of Day 9
acceptance
Pathway process 1 day Release change Day 10
acceptance
Update systems & Varies Day 11+
documentation
System processes Data at counters (release day +1 nwd)
overnight 97%
Data at counters (release day +2 nwd)
99%
Data at counters (release day +3 nwd)
100%
Note:
day = working day (Mon-Fri, excluding public holidays)
nwd = non working days included (Mon-Sun)
times = latest time action can occur to meet the schedule
COMMERCIAL IN CONFIDENCE
Page 22 of 34
ICL Pathway
ICL Pathway/POCL Interface Agreement
for Operational Business Change -
Product
FUJ00232439
FUJ00232439
Ref:CS/PRD/058
Version:2.0
Date:8/7/99
feck Week? [Weeks [Week 4
1D frask nae uaten FRET WET TELS TSE TST ST PEWS ST PET TSS
20 [Advanced simple EE) 10 cay I
[2] Poct teatime 4 aaysI ‘1
[2] Bisiness omerabs cana 1 da I
re] ‘OSG processes change 1 day I
[=] Patmayteadtine 2aaysI I
a] RDT process CBC 2 daysI I
[a] esc cesses ata + day
[aT] RoPinpw cat 2easI I
[2] Patrwayleadime 3 ys I
Ps] RDT processes data 2 days} I
[Tae] Ritgenerate eit aton prs 1 day < I
[3r] Poct esate Zaye Poct
[2] osc verity change 2 daw I
T=] Patiey leading rc tamed
Evy RMprocess acceptance 1 dayI 1
[5] Retese change dear I
[Se JUodatesssiems & coat 20 dag SENS ~ = =
[a7 fata 1 dayI po SA
[a5] Data atcounter 57% day) I
35] Data ators 3% 2a
[a0] ~ ata atcounters 700% 3 days an
rz] I
COMMERCIAL IN CONFIDENCE
Page 23 of 34
FUJ00232439
FUJ00232439
ICL Pathway ICL Pathway/POCL Interface Agreement Ref:CS/PRD/058
for Operational Business Change - Version:2.0
Product Date:8/7/99
8.5 Advanced standard
Changes that, in addition to Type A data, require activities such as loading Type B
(scales and discount indicator) data, managing additional information, Scorecard
updates or testing.
Action Duratio I Result Milestone
n
Business generates 1 day Deliver to OSG Day 1
change
OSG processes change 1 day Deliver notification Day 2
to Pathway
OSG processes data 3days I Deliver data to Day 4
RDOT
RDOT input data 3days I Send to Pathway Day 7 (8pm)
System processes Available to Pathway Day 8 (8am)
overnight
Pathway process request 2days_ I Preparations Day 4
for change complete
Pathway process data 2days I Ready for testing Day 9
RDT test change 1 days RDT handover to Day 10
RM
Pathway generate 1 day Deliver verification Day 11
verification reports reports to OSG
OSG check reports 2 days Notifies Pathway of Day 13
acceptance
Pathway process 1 day Release change Day 14
acceptance
Amend scorecard mapping 1 day Day 14
Update documentation Varies Day 11+
System processes Data at counters (release day +1 nwd)
overnight 97%
Data at counters (release day +2 nwd)
99%
Data at counters (release day +3 nwd)
100%
Note:
day = working day (Mon-Fri, excluding public holidays)
nwd = non working days included (Mon-Sun)
times = latest time action can occur to meet the schedule
COMMERCIAL IN CONFIDENCE Page 24 of 34
FUJ00232439
FUJ00232439
Week 1
uit [WITTFTs[s
Week? [weeks [Week
ut [WITTFTS[sI wi tlw tT FT sTsI [Tw tress
10 [Task Name Duration
2 14 daysI ;
a 7 aaysI Poct
pa] ‘Business generates chang
pe] (086 processes change
pe] Pathway leadtime
al ROT process OBC
SEEEECECECCCECECCE
(056 processes data
ROP input data
Pathway loadtime
ROT processes data
ROT test change
RM generate verifeation ¢
POCL teadine
(0S verity change
Pathway leadtime
ROT update scorecard ma
FRM process acceptance
Release change
Update documentation
LA
Data at counter 97%
Data at counters 009%
‘Data at counters 100%
58
COMMERCIAL IN CONFIDENCE
Page 25 of 34
ICL Pathway
ICL Pathway/POCL Interface Agreement
for Operational Business Change -
Product
FUJ00232439
FUJ00232439
Ref:CS/PRD/058
Version:2.0
Date:8/7/99
8.6 Advanced, complex
Changes that require update Type C data (and Type B Cash Account).
Action Duratio I Result Milestone
n
Business generates 2days I Deliver to OSG Day 2
change
OSG processes change 3days I Deliver notification to Day 5
Pathway
OSG processes data 4days IDeliverdatatoRDOT Day6
RDOT input data 5days I Send to Pathway Day 11
(8pm)
System processes Available to Pathway Day 12
overnight (8am)
Pathway process request 2 days Preparations Day 7
for change complete & notify CD
Pathway processes data 2 days RDT handover toCD Day 13
Create Type C data 10 days I Ready for testing Day 23
RDT Test changes 2 days RDT handover to RM Day 25
Pathway generate 1 day Deliver verification Day 26 (6pm)
verification reports reports to OSG
OSG check reports 3 days Notifies Pathway of Day 29 (6pm)
acceptance
Pathway process 1 day Release change Day 30 (6pm)
acceptance
Amend scorecard mapping 1 day Day 30
Update documentation Varies Day 30+
System processes Data at counters 97% (release day +1
overnight nwd)
Data at counters 99% (release day +2
nwd)
Data at counters (release day +3
100% nwd)
Note:
day = working day (Mon-Fri, excluding public holidays)
nwd = non working days included (Mon-Sun)
times = latest time action can occur to meet the schedule
COMMERCIAL IN CONFIDENCE
Page 26 of 34
FUJ00232439
FUJ00232439
ICL Pathway = ICL Pathway/POCL I Interface nureement Ref: CS/PRD/058
[Weert We Tw [wee [Wee [Week 7]
1D_ITask Name i Phe Core pet erere rept ere st ees
20, [Advanced complex (2) 20 days
[7] POC teadkime 11 daysI Poct, —
re] Business generates chang 2 daysI I
7 ‘O56 processes change 3 days I
[70] Pathway leadtime 2 daysI I
ROT process OBC 2 dayI
72 (086 processes data 4 days
7% ROP input data 5 day
Ta I Pathway loadtime 15 daysI
75 ROT process data 2 days
76 (CD Create Type C 10 ayeI
all ROT test changes 2daysI
pe] RM generate verfeationr 1 ay)
[7] Poct teatime 3 daysI
pe] (086 vent change 3 day
[BT] Pathway teadtine ¥ ay)
pe] ROT update scorecardma 1 dayI
pe] FM process acceptance 1 ay/
pe] Release change Oday
[75 ]lpdate documentation 20 days
pe] day]
al 1 éayI
pe] 2a
[7B] Data at counters 100% 3 ay
I
8.7 AP CTO
As agreed in AP CTO & Token Verification documents [ref 3 & 4].
8.8 Tight Timescales
8.8.1 Requirement
ICL Pathway recognise the business need POCL has to implement changes in tight
time scales. Requirement 539/3 states there is a need to “implement changes to
Reference Data to tight timescales. An as example of such timescales, it shall be
possible to implement Reference Data changes consequent on a Budget by start of
business on the following day”.
8.8.2 Types
Analysis by POCL of the business requirements indicates that the drivers for change
are:
COMMERCIAL IN CONFIDENCE
Page 27 of 34
FUJ00232439
FUJ00232439
ICL Pathway ICL Pathway/POCL Interface Agreement Ref:CS/PRD/058
for Operational Business Change - Version:2.0
Product Date:8/7/99
e Governmental / legal changes
e Client requirements where there is a real business need (i.e. not due to bad
working practices)
and the types of change that require to be changed in tight timescales are:
e Price change
e Emergency cessation of a product
e Last minute amendments to details of a product introduction or change which has
been set up in advance.
8.8.3 Price Change
The most frequent changes to tight timescales are price changes and these can be
processed via the Basic Express route and so do not require additional agreements.
8.8.4 Emergency cessation
Normally cessation of a product is an Advanced Simple change with a lead time of 2
weeks. However it can be dealt with as if it was a Basic Express, with a lead time of
2 days, given that appropriate authorisation is received. The normal paperwork
would be processed after the event.
8.8.5 Last minute amendments
There are occasions when a change is known to be needed before the full details of
the change are available, and the final information may not be available until close
to the implementation date. Where this is the case an OBC change can be initiated
as normal, but with incomplete data and with agreed plans for when the final
amendments will be introduced.
For example:
Introducing a new product could be done by first producing a ‘dummy’ product,
which defines the cash account mappings and menu button, but has no real name or
price or product details included. The missing type A data could be completed or
changed when it is finally known, as if it was a Basic change.
8.9 Error Correction
COMMERCIAL IN CONFIDENCE Page 28 of 34
FUJ00232439
FUJ00232439
ICL Pathway ICL Pathway/POCL Interface Agreement Ref:CS/PRD/058
for Operational Business Change - Version:2.0
Product Date:8/7/99
The need to correct errors to reduce or remove the impact of those errors.
The method of changing data for Error Correction purposes is described in [ref
12]. The time scale for implementing these changes will be derived from the
priority of the incident that is governing the progress of the change.
9. RDCC Categories
The RDCC categories (section numbers provided, based on release 2.0 of the
RDCC) that apply to these changes are as follows. The assumptions listed in the
RDCC must be adhered to in order to apply these categorisations.
The lead times given are end-to-end lead times and therefore include time for POCL
activity. ICL Pathway commits to all reasonable endeavours to deliver changes to
ICL Pathway agreed lead times
9.1 Basic (2 weeks)
6.4.1 Change to product price
6.4.6 Revaluation
6.5.2 Change product availability (non-core)
6.4.3, 6.7.1, 6.7.5 Change to min/max quantity/value
6.7.2, 6.7.3 Change whether voidable or reversible
6.7.6 Change between existing methods of payment
6.6.1 - 6.6.3, 6.10.6 Change product names
6.7.9 Change clerk instructions
9.2 Basic express (2 days)
Note: applies to ‘Ticket and Travel’ products only.
6.4.1 Change to price non-value stock
6.5.2 Change product availability (non-core)
6.7.1 Change to min/max quantity/value
6.7.6 Change between existing methods of payment
9.3 Advanced simple (2 weeks)
6.2.1 -6.2.5 Cease non-value product*
6.2.1 -6.2.3 Cease Sell and Remit In/Out of value product (at same time)*
6.5.3 Non core product becomes core
COMMERCIAL IN CONFIDENCE Page 29 of 34
FUJ00232439
FUJ00232439
ICL Pathway ICL Pathway/POCL Interface Agreement Ref:CS/PRD/058
for Operational Business Change - Version:2.0
Product Date:8/7/99
6.7.8 Change to use of additional fields
see appendix A
9.4 Advanced standard (4 weeks)
6.4.2
Change to discount indicator
Change ability to print receipt
Change from value to non-value stock
Change to client name — non AP.
Change to calendar
Remove AP client
Change picklist for existing product
9.5 Advanced, complex (6 weeks)
Add new product - non value stock
Add new product - make value stock available to rem-in
(another 6 weeks for make available to sell)
Remove product permanently (not available at NR2)*
Cease value product and leave on Rem Out screen*
Change to scales matrix /tariff change(no Type C
required but OSG need extra time to verify the changes).
6.10.2 - 6.10.5, 6.10.7 Change to screen layout
6.1(all)
6.1.1 - 6.1.4
6.3(all), 6.8.7
6.2.1 - 6.2.3
6.4.4, 6.4.5
6.12.3, 6.12.5
6.5.4
and
6.6.7
6.5.1
Change to accounting node
Change product categorisation (changing between core
non-core which changes item between picklist and
button).
Change to Best Fit screens
Temporary withdrawal of a product
* see appendix A
9.6 AP (as agreed in AP CTO & Token Verification
documents)
6.8.1 - 6.8.5 Introducing new AP client, service or token
6.8.9 Change to client name (new token data)
6.8.7, 6.8.10, 6.8.11 Ceasing AP Client, product or token
Notes on AP change:
COMMERCIAL IN CONFIDENCE Page 30 of 34
FUJ00232439
FUJ00232439
ICL Pathway ICL Pathway/POCL Interface Agreement Ref:CS/PRD/058
for Operational Business Change - Version:2.0
Product Date:8/7/99
e Changing AP product details is treated the same way as changing EPOSS
products.
e Ceasing AP Client, product or token may be implemented as an Advanced Simple
change if required, with the client service list being amended after the event.
10. Volumes
The lead-time and milestone models were built on normal expected volumes. Any
deviation to the norm of more than 100% (one sixth of the yearly volume per month)
will result in an inability to achieve the lead times.
The normal volumes are based on historic data gathered within POCL and is
reproduced as follows.
10.1 Normal volumes
Change Type July 98 estimate Per I Per
Times per year mont I week
(Max) h
Add a standard product (EPOSS) I comple 128 10.7 I 2.5
x
Add a standard AP Client Service AP 429 35.8 I 83
Type (new client)
Add a new AP Client Service Type AP 109 9.1 2.1
(existing client)
AP change - other comple - - -
x
Delay start date of product comple 208 17.3 I 4.0
availability Xx
Extend trial of a product basic 13 1.1 0.3
Temporary withdrawal of product comple 14 1.2 0.3
(EPOSS) x
Permanent withdrawal of product comple 60 5.0 1.2
(EPOSS) x
Removal of a standard AP client standar 7 0.6 0.1
d
Removal of an AP Client Service comple 25 2.1 0.5
x
Change product availability (non- basic 306 25.5 I 5.9
core)
Change product categorisation comple 9 0.8 0.2
x
Change Parcelforce tariff comple 1 0.1 0.0
x
Change Royal Mail Tariff comple 2 0.2 0.0
x
COMMERCIAL IN CONFIDENCE Page 31 of 34
FUJ00232439
FUJ00232439
ICL Pathway ICL Pathway/POCL Interface Agreement Ref:CS/PRD/058
for Operational Business Change - Version:2.0
Product Date:8/7/99
Change between existing methods of I basic 210 17.5 I 4.0
payment (MOP)
Requirement for printing of forms (by n/a 112 9.3 2.2
Horizon) : no change to layout
Requirement for printing of forms (by
Horizon) : including changes to
layout
(NOT SUPPORTED IN OBC)
Change product names basic 105 8.8 2.0
Change client name (non AP) standar 102 8.5 2.0
d
Change client name (AP) AP
Change product price. Change basic 1012 84.3 I 19.5
standard sales rules for min /max
/mult prices, volume & value,
override price
Discount indicator standar - - -
d
Change of business rules regarding basic 1 0.1 0.0
customer eligibility (i.e. change in
clerk instructions)
Change whether voidable or basic 3 0.3 0.1
reversible
Change stock reconciliation N/a 61 5.1 1.2
requirements
(NOT SUPPORTED)
Change use of additional fields (e.g. I simple 16 1.3 0.3
for a/c numbers)
Accounting rule changes including comple 16 1.3 0.3
mapping to c/a (no other change) x
Change to c/a layout (NOT Nia
SUPPORTED)
Change to screen layout comple - - -
x
Change to calendar i.e. accounting standar - - -
days/weeks/periods/years d
[ Total 2949 246 I 57
COMMERCIAL IN CONFIDENCE
Page 32 of 34
FUJ00232439
FUJ00232439
ICL Pathway ICL Pathway/POCL Interface Agreement Ref:CS/PRD/058
for Operational Business Change - Version:2.0
Product Date:8/7/99
11. Commercial Implications
11.1 Order and Payment
a) Change orders will be accepted, as firm, once received by the OBC
Product Mailbox.
b) Currently the only chargeable Operational Business Change service is
AP Client Take On [ref 3]. Invoices for completed change activity on
this, or any future Operational Business Change service, will be sent to
POCL on a monthly basis and 30 day payment from date of invoice
conditions will apply.
11.2 Failure to achieve lead times
There are no liquidated damages or defined remedies for failure to meet any
milestone. ICL Pathway and POCL will both meet their own lead times on a
reasonable endeavours basis .
12. Deviations
Deviations to change requirements, standards and processes within the OBC
process will be managed on a case by case basis. No commitments, in terms
of delivery time, delivery standard or price can be given by ICL Pathway —
until the detail of the specific deviation is known and understood. Request of
the deviation should be submitted in advance of the OBC form. It will be
agreed between RDT, RDOT and OSG whether the deviation is possible. If
not, OSG will inform the business unit immediately.
Non OBC changes [ref 10] will be rejected by the OBC process and need to
be submitted as a Change Request.
COMMERCIAL IN CONFIDENCE Page 33 of 34
ICL Pathway
ICL Pathway/POCL Interface Agreement
for Operational Business Change -
Product
FUJ00232439
FUJ00232439
Ref:CS/PRD/058
Version:2.0
Date:8/7/99
13. Appendix A
The implementation of Remove/cease a product can be summarised as follows.
Remove ‘alue & Non- [Button & PicklistI(Complex
ermanently IValue products (n/a for NR2)
(Cease Sell INon-Value Button & PicklistISimple
products (use Type A data & Pathway
idy up afterwards)
(Cease Sell ‘'alue products (Button Complex
leave Rem
(Cease Sell ‘alue products IPicklist Complex
leave Rem
(Cease Sell & IValue products Button & Picklist/Simple
(Cease Rem (use Type A data & Pathway
idy up afterwards)
COMMERCIAL IN CONFIDENCE
Page 34 of 34