FUJ00001989
FUJ00001989
Fujitsu Services Fujitsu Services/Post Office Ltd Interface Agreement — Ref: CS/PRD/058
for Operational Business Change — Reference Data Version: 13.0
COMMERCIAL IN CONFIDENCE Date: 22 February 2006
Document Title:
Document Type:
Release:
Abstract:
Document Status:
Author & Dept:
Contributors:
Internal Distribution:
External Distribution:
Fujitsu Services / Post Office Ltd Interface Agreement for
Operational Business Change - Reference Data
Interface Agreement
S90
This Interface Agreement defines for the $90 release of the Horizon
System (which includes Branch Trading, Prompts Track & Trace,
and APOP) the requirement, the service solution and the
obligations of Post Office Ltd and Fujitsu Services for delivering
Operational Business Change — Reference Data.
Approved
David Wilcox, Fujitsu Services Post Office Account Customer
Service
David Anders
Mark Knight
Ijaz Bhatti
Fujitsu Services Post Office Account RDT
Post Office Ltd Sales and Service
Post Office Ltd Marketing and Direct Sales Product Deployment
Post Office Ltd Reference Data Operational Team
Post Office Ltd Horizon Commercial
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE, Page: I of 71
Fujitsu Services
Fujitsu Services/Post Office Ltd Interface Agreement
for Operational Business Change — Reference Data
COMMERCIAL IN CONFIDENCE
Ref:
Version:
CS/PRD/058
13.0
Date: 22 February 2006
FUJ00001989
FUJ00001989
Approval Authorities:
‘Name Position Signature Date
David Wilcox Fujitsu Services Post Office
Account Reference Data
Manager
Rabia Cody Post Office Ltd OBC
Reference Data Service
Manager
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE,
Page: 2 of 71
FUJ00001989
FUJ00001989
Fujitsu Services Fujitsu Services/Post Office Ltd Interface Agreement — Ref: CS/PRD/058
for Operational Business Change — Reference Data Version: 13.0
COMMERCIAL IN CONFIDENCE Date: 22 February 2006
0.0 Document Control
0.1. Document History
10.0 20/12/2002 Updated for Contract Amendment agreed by both
Parties
10.1 17/02/2003 Updated to include Debit Card Service, Branch
Change, changing core to non-core
10.2 08/07/2003 Update to include changes agreed in relation to
release of data. Addition of Mails information
10.3 21/10/2003 Update following comments
Change to volumes for Network Reinvention
(section 7.3)
11.0 27/11/2003 Approved version
WL Internal version not issued for review
11.2 01/07/2005 Changes for S70 and S80
12.0 24/08/2005 Approved version (withdrawn)
12.1 21/10/2005 Incorporate comments missed from v 12
12.2 20/12/2005 Incorporate comments from 12.1 review
13.0 22/02/2006 Approved version
0.2 Review Details
Review Comments by :
Review Comments to :
Mandatory Review Authority — Name
Fujitsu Services Aileen Davis
Hilary Forrest
Jan Venables
Post Office Ltd Rabia Cody
Andy Corbett
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE, Page: 3 of 71
Fujitsu Services
Fujitsu Services/Post Office Ltd Interface Agreement
for Operational Business Change — Reference Data
COMMERCIAL IN CONFIDENCE
Ref: CS/PRD/058
Version: 13.0
Date: 22 February 2006
FUJ00001989
FUJ00001989
David Anders
Mark Knight
Keith Baines
Matt Warren
David Thompson
Optional Review / Issued for Information
Fujitsu Services
John Shepherd
Mik Peach
Kevin McKeown
Tan Daniel
Liz Evans-Jones
Post Office Ltd
Liz Tuddenham
Bernadette O’Donnell
Ijaz Bhatti
0.3 Associated Documents
Please see library for details of latest versions
of documents.
1. CS/PRD/030 Process for Operational Business Change - I Fujitsu :
Product Services
2. CS/IFS/001 Reference Data Change Catalogue Fujitsu
+ + Services
CS/IFS/010 Reference Data Change Catalogue Network
+ Banking Appendix
Note: The original documents which made
RD/CCL/001
CCL up the RDCC are being replaced by a set of
documents, the base one being
RD/CCL/001 with appendices which are in
the same number series. These will, in the
course of time, also absorb business rules
3. CS/PRD/110 AP Client Service Introduction and Change I Fujitsu
Process Services
4. CS/SER/001 CS Services Catalogue Fujitsu
Services
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE,
Page: 4 of 71
FUJ00001989
FUJ00001989
Fujitsu Services Fujitsu Services/Post Office Ltd Interface Agreement — Ref: CS/PRD/058
for Operational Business Change — Reference Data Version: 13.0
COMMERCIAL IN CONFIDENCE Date: 22 February 2006
D
5. Not currently used
6. RDP/AIS/001 AIS Reference Data to Pathway Type A Post
Data Office
Ltd
7. Reference not currently used but entry
retained to avoid amending other references
8. RDP/AIS/008 AIS Reference Data to Pathway Type B Post
Data Office
Ltd
9. CS/PRD/048 Changing Reference Data to Tight Fujitsu
Timescales Services
10. CS/IFS/002 Reference Data Change Class 1 Analysis Fujitsu
Services
1. CS/IFS/003 Fujitsu Services / Post Office Ltd Fujitsu
Operational Business Change ~ Branch Services
Interface Agreement
12. RDS/OLA/001 Reference Data — Post Office Ltd / Post
Pathway Operational Level Agreement Office
Ltd
13. PON/OSG/OLA PON OSG / ICL Pathway Operational Post
/001 Level Agreement Office
Ltd
14. OSG/OPS/001 Operational Business Change Product Post
Verification Procedures Office
Ltd
15, RD/TEC/951 Reference Data Rules and Values Post
Office
Ltd+
Fujitsu
Services
16. CS/POL/006 Service Management Framework Part A Fujitsu
Services
17. CS/OLA/022 Communications Interface Agreement Fujitsu
Services
18. Reference not currently used but entry
retained to avoid amending other references
19. I CS/PRD/028 Process for Changing Menu Hierarchies Fujitsu
and Icons Services
20. CS/PDN/018 Horizon Icon Service Description Fujitsu
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE, Page: 5 of 71
FUJ00001989
FUJ00001989
Fujitsu Services Fujitsu Services/Post Office Ltd Interface Agreement — Ref: CS/PRD/058
for Operational Business Change — Reference Data Version: 13.0
COMMERCIAL IN CONFIDENCE Date: 22 February 2006
D
Services
21. RDP/TEC/977 Network Banking Reference Data Rules Post
and Values Office
Ltd +
Fujitsu
Services
22 CS/PRD/108 Conventions for naming of Operational Fujitsu
Business Change Reference Data Services
Unless a specific version is referred to above, reference should be made to the current
approved versions of the documents.
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.
ADC Advanced Data Capture — see also AP-ADC
Adow Any day of the week, as opposed to working weekdays.
Advanced. Product and Branch Business changes available through the OBC processes that
Change require a notice of change to be delivered to Fujitsu Services before
implementation. In the case of Product Change they may or may not be
supported by Reference Data files from Post Office Ltd. Advanced Changes are
subdivided into Complex, Complex Extended, Standard, Simple or AP. [see
section 4.2].
Advanced Product Change that requires advance notice to be given to Fujitsu Services in
Complex Change I order for Type C Reference Data to be created.
Advanced Product Change that requires advance notice to be given to Fujitsu Services in
Complex order for Type C Reference Data to be created, also requires additional
Extended Change I validation/verification above that needed for Advanced Complex Change
Advanced Product Change that requires advanced notice to be given to Fujitsu Services,
Simple Change I where the additional activities required can be carried out after the OBC has
been released and therefore do not extend the lead-time for that OBC.
Advanced Product Change that requires advanced notice to be given to Fujitsu Services,
Standard Change I where the additional activities required do extend the lead-time for that OBC,
but the change does not require Type C Reference Data.
After the event I Changes which need to be made to complete an OBC, but are not needed before
changes the release of the OBC e.g. documentation updates.
Agreed Release _I For each delivery of Reference Data that is to be released to the live estate Post
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE, Page: 6 of 71
FUJ00001989
FUJ00001989
Fujitsu Services Fujitsu Services/Post Office Ltd Interface Agreement — Ref: CS/PRD/058
for Operational Business Change — Reference Data Version: 13.0
COMMERCIAL IN CONFIDENCE Date: 22 February 2006
Date Office and Fujitsu Services shall agree a release date (the “Agreed Release
Date”) which shall be in accordance with the principles defined in section 10.1
of this document and is the date on which Fujitsu Services initiates the release
of that Reference Data to the live estate
Amendment file I A file containing records changing previously received Reference Data which is
still being processed — must be released with the original file.
AP Automated Payments
AP-ADC Automated Payments — Advanced Data Capture — additional facility added in
S60
Authorisation Post Office shall be responsible for final validation and authorisation of Post
Date Office supplied Reference Data, the date of such authorisation being referred to
as the “Authorisation Date”.
Authorisation A document that is sent from Post Office Ltd to Fujitsu Services to say the
Form following for the named Product Change OBC.
e The Verification Report has been checked.
¢ 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,
v
The Name of the person who conducted the Business Test,
v
The Conclusion of the Business Test, whether Pass or Fail,
e If Fail, the Failure Reason and Mitigating Action
e — If Pass, indicate whether the Comparison Report had been
checked Yes or No.
For Product change the form provides the notice of authorisation.
Branch Change is now pre-Authorised
Authorisation The Authorisation process results in Fujitsu Services being directed by Post
Office Ltd to implement in the live estate those authorised Reference Data
changes that are covered by the notice of authorisation.
Authorisation is an assertion by Post Office Ltd that they have diligently and
conscientiously performed the specified [ref. 14] Business Tests, and that within
the bounds of the specified tests the results indicate that the effects of the
authorised Reference Data change is the effect that Post Office Ltd intended.
Fujitsu Services is responsible for ensuring that all other effects on the system
are consistent with the stated requirement.
Each party accepts responsi’
responsibility to test.
lity for those aspects of a change for which it has
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE, Page: 7 of 71
FUJ00001989
FUJ00001989
Fujitsu Services Fujitsu Services/Post Office Ltd Interface Agreement — Ref: CS/PRD/058
for Operational Business Change — Reference Data Version: 13.0
COMMERCIAL IN CONFIDENCE Date: 22 February 2006
The notice of authorisation shall be communicated via an Authorisation Form.
N.B. Certain types of change are pre-authorised and may be implemented to the
live estate by Fujitsu Services without any further notification by Post Office
Ltd.
Authorised An OBC which has passed through the Authorisation process and has been
Change authorised.
Basic Change Product Changes available through the OBC processes that DO NOT require a
notice of change to be delivered to Fujitsu Services. Currently Basic Changes
always consist of Class 1 Reference Data.
BAU Business As Usual. Processes within Post Office Ltd that occur regardless of
whether the Horizon system is in use.
BCR Business Change Request (referred to in Post Office Ltd as “Change Control
Number”). A unique identification number for an OBC.
Branch Term used to refer to individual post offices. Replaces the formerly used term
“outlet”.
Branch Changes I Changes to Branch information available through the Horizon system
implemented wholly, or in part, through changes to Reference Data
Business Tests _I Tests used by Post Office Ltd to ensure a Product change seen on the
Verification Counter and/or described in the Verification and Comparison
reports meets the requirement.
Where Business Tests fail to identify problems that were apparent at the time
the tests were carried out, the specified tests will be improved by joint review
and change control.
CccD Contract Controlled Document
CCN Change Control Note as defined in the Contract.
CCN Change Control Number (referred to in Fujitsu Services as “Business Change
Request”).
Change Type For example, Basic Pure, Advanced Simple, Advanced Complex, AP etc.
Chip & PIN Technology used on bank cards
Class 1 Class 1 Reference Data is the subset of data items which have no impact on any
other part of the Horizon system and changes containing only Class 1 Reference
Data (Basic Changes) can be implemented by Fujitsu Services without advance
notice [see ref. 10]. Class I data is subsetted into HD, HR and Pure.
Comparison The output from Fujitsu Services’s software tool which is used for identifying
Report the changes that have occurred on a Horizon counter. It provides information to
Post Office Ltd for verification purposes.
CR Change Request as defined in the Contract
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE, Page: 8 of 71
FUJ00001989
FUJ00001989
Fujitsu Services Fujitsu Services/Post Office Ltd Interface Agreement — Ref: CS/PRD/058
for Operational Business Change — Reference Data Version: 13.0
COMMERCIAL IN CONFIDENCE Date: 22 February 2006
CSR+ Core System Release Plus
CTO Client Take-On (AP)
DCS Debit Card Service
Deviation to the I A single instance of an agreed variation to the workload which falls outside of
service specified levels.
Effective Date The date on which any Reference Data is required to be effective on counters in
the live estate.
Note: Reference Data has an attribute ‘Start Date’. In many instances this is the
effective date however there are occasions where the ‘Start Date’ is the date on
which the Reference Data is keyed or there may be a need to have the data
effective later than the original ‘Start Date’
EMV ‘Europay Mastercard Visa’ (The Europay-Mastercard-Visa specifications for
chip-based payment cards. EMV part I corresponds with [and generally
conforms with] ISO 7816 parts 1-5; the other parts of the specification cover the
details of a standard credit/debit application and the requirements for terminals).
Error A part of a change that does not meet the requirement or specifications, whether
Reference Data definitions, file format, milestones, delivery route or other
aspect of the OBC processes. (see also Rework)
Error correction I A file containing records for the purpose of correcting errors to previously
file received Reference Data which is still being processed-must be released with
the original file.
Exception A change that falls outside of the agreed levels e.g. to lead-times or volumes and
is not a ‘Deviation to the service’.
FJS Fujitsu Services
HD (Basic) Reference Data changes are ‘HD’ when the change is relevant in Fujitsu
Services only to the HelpDesk e.g. telephone number.
HR (Basic) Reference Data changes are ‘HR — High Risk’ when verification is required by
Post Office Ltd (but are not subject to advanced notification).
HSD Fujitsu Services Horizon Service Desk.
IMPACT Improved accounting — project name for introduction of new POL financial
systems at S80
Interface This document (except where the Interface Agreement for Branch is specifically
Agreement 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 is
recorded on the Fujitsu Services HSD and / or the Post Office Ltd NBSC help
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE, Page: 9 of 71
FUJ00001989
FUJ00001989
Fujitsu Services Fujitsu Services/Post Office Ltd Interface Agreement — Ref: CS/PRD/058
for Operational Business Change — Reference Data Version: 13.0
COMMERCIAL IN CONFIDENCE Date: 22 February 2006
desks.
MAAWP Maximum Authorising Agent Wait Period
Mails Contractual name for the Application which provides the smart post service —
also includes smart post help and smart post admin
MCWP Maximum Counter Wait Period
Migration See section 4.2.5.2 for the definition.
Special
MIS Management Information System
NBS Network Banking Service
NBSC Post Office Ltd Network Business Support Centre.
NBX Network Banking eXchange
NSS Network Support Services, Post Office Ltd.
(formerly known as Business Service Management When it included the
Change Implementation Team, formerly known as the Service Provision Team
or OSG.)
NWB Network Banking
OBC Operational Business Change.
Any change, usually supported by Reference Data changes, that is implemented
through the OBC process e.g. Advance and Basic Changes, excluding changes
specifically required to implement software changes.
OBC RDST OBC Reference Data Service Team — the POL team responsible for Reference
Data requests to FJS
OBC forms Electronic Forms used to interchange information relating to OBCs between
Post Office Ltd and Fujitsu Services e.g. OBC 2.
OLA Operational Level Agreement
OSG Former acronym of OBC RDST - still commonly used
Outlet Term formerly used to refer to individual post offices. Now replaced by the term
“branch”.
Pathway Fujitsu Services (Pathway) Ltd — no longer used contractually but still may
appear within systems and documentation
Peak An incident recording system used within Fujitsu Services (previously called
PinICL)
PLU Product Look Up
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE, Page: 10 of 71
FUJ00001989
FUJ00001989
Fujitsu Services Fujitsu Services/Post Office Ltd Interface Agreement — Ref: CS/PRD/058
for Operational Business Change — Reference Data Version: 13.0
COMMERCIAL IN CONFIDENCE Date: 22 February 2006
PM Postmaster
POCL Post Office Counters Limited — the former name of PON.
POL Post Office Ltd - name which supersedes POCL and PON
Postcomm The Postal Services Commission, that is the Government appointed regulator
for postal services
Pre-authorised A pre-authorised change is a Reference Data change that by agreement [see
change section 3.5 for Branch and section 4 for Product] does not require verification
by Post Office Ltd and can be released by Fujitsu Services without additional
notification from Post Office Ltd over and above the delivery of a conformant
file.
Pre-live Incident I The 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 (Peak) operated by Fujitsu Services.
Product Changes I Changes to the products or appearance of products available through the
Horizon system implemented wholly or in part, through changes to Reference
Data.
Pure (Basic) When used in reference to a Reference Data Change ‘Pure’ indicates Reference
Data which is considered to be of low risk to business integrity.
RDCC Reference Data Change Catalogue
RDMC Fujitsu Services Reference Data Management Centre
RDORF Reference Data Operational Review Forum
RDOT Post Office Ltd Reference Data Operational Team (Chesterfield)
RDP Post Office Ltd Reference Data Project
RDS Post Office Ltd Reference Data System
RDS80 Updated version of RDS introduced at Horizon S80 release
RDT Fujitsu Services Reference Data Team
Release Day The day on which Reference Data is Released to the live system.
Released to the I Reference Data released by Fujitsu Services into the TMS agent. The end point
live system for the process defined in this document. The SLT [see section 3.2] covers the
delivery of Reference Data to the branches.
REM Remittance
Required Date The date on the OBC form (Advanced Changes) that specifies when the change
needs to be available at the branches. Normally this is the same as, or earlier
than, the Start Date. (see also, Effective Date.)
Rework Activity required to progress a change when an Error Correction File or
Amendment File is provided.
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE, Page: 11 of 71
FUJ00001989
FUJ00001989
Fujitsu Services Fujitsu Services/Post Office Ltd Interface Agreement — Ref: CS/PRD/058
for Operational Business Change — Reference Data Version: 13.0
COMMERCIAL IN CONFIDENCE Date: 22 February 2006
IRM Fujitsu Services Release Management
SEPT (Central) I Security Equipment and Projects Team - Central Administration (formerly NIST
and NIET)
smart post Horizon desktop service based on Escher Mails — replaces Scales service
SLT Service Level Target as defined in the Contract
Start Date The 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 Effective 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 Post Office Ltd to Fujitsu Services over a
non-automated interface.
Type C Data prepared by Fujitsu Services.
Unauthorised An OBC that has been released to the live environment but has not been
change authorised.
Unit of Release I A combination of files which are intended to be released together. The smallest
is a single file. Where Amendment or Error Correction files are applied to a
change in progress, the unit of release will be all files associated with the
original OBC.
Validation Confirming that the observed result of the change implemented is the same as
(Validate) that expected and fulfils the requirements as specified to Fujitsu Services —
activity performed by Fujitsu Services.
Verification Confirming that the observed result of the change implemented is the same as
(Verify) that expected and fulfils the requirements of the business — activity performed
by Post Office Ltd.
Verification A non-live Horizon counter provided to Post Office Ltd to which OBCs are
Counter applied in order for Post Office Ltd to verify the change, before its release to the
live estate.
Verification A report produced from the RDMC to show which Reference Data records have
Report changed.
Working 9am to Spm, Monday to Friday, excluding English Public Holidays.
weekdays
[Terms defined in the Contract shall have the same meaning where used in this CCD]
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE, Page: 12 of 71
FUJ00001989
FUJ00001989
Fujitsu Services Fujitsu Services/Post Office Ltd Interface Agreement — Ref: CS/PRD/058
for Operational Business Change — Reference Data Version: 13.0
COMMERCIAL IN CONFIDENCE Date: 22 February 2006
0.5 Changes in this Version
Drop down of relevant provisions from N01 from the old Codified
Agreement. Also changes to introduce new & replacement terminology
(eg. Agreement instead of Codified Agreement) have been made.
Inclusion of new definitions from Schedule 15 (Agreed Release Date
& Authorisation Date) into the document. Introduction of volumetric
limits in accordance with Heads of Agreement and agreement to move
towards work index system as agreed between Post Office & Fujitsu
Services (cf para 6.2). Planned capability volumetrics in relation to
Network Reinvention activity (cf para 6.3).
10.1 « Name of document changed as all Reference Data is now included
e Remove reference to Pathway
e Add details relating to Debit Card Service
e Change sections as necessary to accommodate branch change
e Add section on changing products from non-core to core and back
e Add section on process for permanently closing branches
« Remove Appendix A — OBC volumes for year 2002
10.2 e Amended following comments to version 10.1
e Addition of Appendix on Mails
e Inclusion of new section 10.2 regarding Release of Reference Data to
close the gap with Schedule 15 of the contract. Also amended
definitions of Agreed Release Date, Authorisation Date and Effective
Date to conform to this
e Added appendix on process for handling PinICLs between Fujitsu
Services and Post Office Ltd
10.3 e Amended following comments to version 10.2
e References to ‘Agreement’ in section 0.4 changed to ‘Contract’
e Agreement now recognises the Mails service
e Section 7.3 amended in light of change requirement for Network
Reinvention
11.0 e Issued for approval
1.1 ¢ Internal version not issued for review
11.2 e Add or amend IIN range for NWB/DCS becomes Advanced Complex
due to introduction of Chip and PIN
© Change of signatories
© Heading corrected
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE, Page: 13 of 71
Fujitsu Services
FUJ00001989
FUJ00001989
Fujitsu Services/Post Office Ltd Interface Agreement — Ref: CS/PRD/058
for Operational Business Change — Reference Data Version: 13.0
COMMERCIAL IN CONFIDENCE Date: 22 February 2006
¢ Missing comments incorporated
e Add S80 elements
* Change wording of section 2.5 regarding Alerting to incorporate
current Alerting Process document (CS/PRD/077)
¢ Remove section 2.6.2 with regard to NBE (NBE replaced by NBX)
e Change section 7.3 with respect to network reinvention
12.0 e Issued for approval — version withdrawn as comments had been mssed
12.1 e Change HSH to HSD
12.2 e Replace all reference to Cash Account with Branch Trading Statement
e Replace all references to PinICL with Peak
* Correct errors in some lead time models
e Clarify Migration Special
© Re-instate change ITN range in High Risk for non Chip and Pin Card
13.0 e Issued for approval
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE, Page: 14 of 71
FUJ00001989
FUJ00001989
Fujitsu Services Fujitsu Services/Post Office Ltd Interface Agreement — Ref: CS/PRD/058
for Operational Business Change — Reference Data. Version: 13.0
COMMERCIAL IN CONFIDENCE Date: 22 February 2006
0.6 Changes Expected
e This document is amended as required when new releases of the Horizon system are
released
e This document may need amendment if agreement is reached on the use of the work
index measurement mechanism
0.7 Table of Contents
1 SUMMARY SHEET...
2 INTRODUCTION.
INTENT OF INTERFACE AGREEMENT
MAINTENANCE OF THIS INTERFACE AGREEMEN
FUTURE DEVELOPMENTS
SERVICE MANAGEMENT POLICY
ALERTING WHEN PRODUCT DATA I
[ RISK OF LATE DELIVERY
. CONTRACTUAL OBLIGATIONS WITH RESPECT TO NBS.
2.6.1 Extensibility
3
3.2 SERVICE LEVEL TARGET
33 OPERATIONAL BUSINESS CHANGE PROCESSES FOR PRODUCT CHANGE
3.3.1 Process Diagram
3.3.2 Process Steps
3.4 ICON CHANGE
3.5 OPERATIONAL BUSINESS CHANGE PROCESSES FOR BRANCH CHANGE ......
4 TYPES OF CHANGE.
41 INTRODUCTION...
42 PRODUCT CHANGES
4.2.1 Standard Changes
4.2.2 AP (including ADC)
4.2.3 System Parameters - Pure.
4.2.4 Icon Change.....
42.5 Fast-track changes
43 BRANCH CHANGES ..
4.3.1 HelpDesk.
4.3.2. Advanced
5 LEAD-TIME FOR PRODUCT CHANGES...
5.1 INTRODUCTION.
5.2 S
53
54
5.5 ADVANCED STANDARD
5.6 ADVANCED COMPLEX
5.7 ADVANCED COMPLEX EXTENDED
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE, Page: 15 of 71
FUJ00001989
FUJ00001989
Fujitsu Services Fujitsu Services/Post Office Ltd Interface Agreement — Ref: CS/PRD/058
for Operational Business Change — Reference Data Version: 13.0
COMMERCIAL IN CONFIDENCE Date: 22 February 2006
5.8 AP AND ADC CLIENT TAKE-ON....
SYSTEM PARAMETERS - PURE
6 I LEADTIMES FOR BRANCH CHANGES..
7 VOLUME OF CHANGE...
71 INTRODUCTION,
72 COMMITTED VOLUMES
73 NETWORK REINVENTION
8 DELIVERABLES...
8.1 Post OFFICE LTD TO FUJITSU SERVICES...
8.2 FUSITSU SERVICES TO POST OFFICE LTD.
83 FUTURE DATING...
9 ROLES & RESPONSIBILITIES....
91 Post OFrFicE LTD— GENERAL...
9.1.1 Administration and Control.
9.1.2 Implementation...
9.1.3 Files & Reference Data.
9.2 POST OFFICE LTD - REFERENCE DATA OPERATIONAL TEAM
93 Post OFFICE LTD NETWORK BUSINESS SUPPORT CENTRE (NBSC) .
94 FUJITSU SERVICES RESPONSIBILITIES
9.4.1 Administration and Control.....
9.4.2 Implementation...
9.4.3 Files & Reference Data.
9.5 HORIZON SERVICE HELPDESK (HSH.
9.6 VERIFICATION, AUTHORISATION & RELEAS!
10 ORDERS AND EXCEPTIONS...
10.1 RELEASE OF R,
10.2 ORDERS...
10.3. EXCEPTIONS
10.4 ERRORS AND
10.4.1 Recording Pre-Live Incidents
10.4.2 Rework categorisation and thre:
10.5 ESCALATION...
10.6 CHARGING......
11. APPENDIX A: STANDARD CHANGES - DETAILS....
11 PRODUCT CHANG!
1111 Basic - Pure.
111.2 Basie — High Risk.
11.1.3 Advanced Simple:
ILA Advanced Standard
TAS Advanced Complex.
111.6 Advanced Complex Extended.
11.1.7 System Parameters — Pure.
11.2. BRANCH CHANGES...
11.2.1 HelpDesk (HD) ..
11.2.2 Advanced..
12 APPENDIX B: CHANGING TRANSACTABLE PRODUCTS BETWEEN CORE AN
CORE.
FERENCE DATA
1 CHANGING ITEMS FROM CORE TO NON-CORE ..
2 CHANGING ITEMS FROM NON-CORE TO CORI
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE, Page: 16 of 71
FUJ00001989
FUJ00001989
Fujitsu Services Fujitsu Services/Post Office Ltd Interface Agreement — Ref: CS/PRD/058
for Operational Business Change — Reference Data Version: 13.0
COMMERCIAL IN CONFIDENCE Date: 22 February 2006
13. APPENDIX C: PERMANENT CLOSURE OF BRANCHES 70
13.1 BACKGROUND .. 70
13.2. PROCESS.
14. APPENDIX D - MAILS...
14.1 SUBSCRIPTION GROUP:
14.2 TIME BETWEEN CHANG
14.3 LEADTIMES FOR MAILS CHANGE!
14.4 MAILS HELP DATA .. cove
15 APPENDIX E - PEAK CONTROL BETWEEN FUJITSU SERVICES AND POST OFFICE LTD75
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE, Page: 17 of 71
FUJ00001989
FUJ00001989
Fujitsu Services Fujitsu Services/Post Office Ltd Interface Agreement — Ref: CS/PRD/058
for Operational Business Change — Reference Data Version: 13.0
COMMERCIAL IN CONFIDENCE Date: 22 February 2006
1 SUMMARY SHEET
This section summarises the content of this Interface Agreement as a “quick reference” guide
to change types. It does not replace the detail contained in the following sections (should
there be differences, the latter shall prevail).
Note: the Lead-time includes processing within both Post Office Ltd and Fujitsu Services, but
not distribution to the Horizon counters
Product ane
Standard: Servic
es
Basic Change - Type A Reference Data only (no Post Office Ltd 4 1 5
Pure verification required)
Basic Change — Type A Reference Data only (Post Office Ltd 6 4 10
High Risk I verification is required)
Advanced Type A Reference Data, plus after-the-event changes 6 4 10
Simple Change
Advanced Type A & Type B Reference Data, MIS change & 9 5 14
Standard Change _I Fujitsu Services testing required
Advanced Change that requires Type C Reference Data from 14 I IL I 25
Complex Change I Fujitsu Services
Advanced Change that may require Type C Reference Data from I 14 I 16 I 30
Complex Extended I Fujitsu Services or may need longer
Change validation/verification times than Advanced Complex
AP Change Change required for AP Client Take-On and Token [see refs. 3&4]
verification (including ADC).
Icon Change Introduction of new/amended Icon [see ref 20]
System Parameters I Amend specified Horizon system parameters within 1 2 3
— Pure defined limits
Product
Fast-track:
Basic Express A subset of Basic HR, for a specific requirement to 15 I05 I2
change specific Reference Data quickly.
Migration Special I An addition to the non-core product mappings for a 0.75 I0.25 I 1
branch, normally where the product is already being
sold prior to migration.
Tight Timescales I A change to make any kind of Reference Data change I Agreed when
quickly, in specified circumstances. requested
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE, Page: 18 of 71
FUJ00001989
FUJ00001989
Fujitsu Services Fujitsu Services/Post Office Ltd Interface Agreement — Ref: CS/PRD/058
for Operational Business Change — Reference Data Version: 13.0
COMMERCIAL IN CONFIDENCE Date: 22 February 2006
Business Critical I An advanced change which requires shorter lead time Agreed when
Advanced Change _I than would normally be required for such a change requested
Live Fix A change to correct a live incident. (ref. section 4.2.5.4 I Defined in OLAs
and 10.4). (refs. 12 & 13)
Branch:
Help Desk (HD) Type A Reference Data only (no Post Office Ltd Defined in [ref
verification required) 11]
Advanced Type A Reference Data only to support more complex I Defined in [ref
changes in branches (e.g. relocation). May require Post I 11]
Office Ltd verification.
N.B. The breakdown of the leadtimes shown above are indicative only of the time taken
within each organisation. The overall leadtime should always be taken as the true indication
of the time required to effect a change. When considering the date by which data is to be
delivered to Horizon counters and the total amount of time required to implement a change, in
addition to the leadtime shown above consideration must also be given to distribution time to
the Horizon counters (see section 3.2) following authorisation.
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE, Page: 19 of 71
FU.
Fujitsu Services Fujitsu Services/Post Office Ltd Interface Agreement — Ref: CS/PRD/058
for Operational Business Change — Reference Data Version: 13.0
COMMERCIAL IN CONFIDENCE Date: 22 February 2006
2 Introduction
This document is a Contract-Controlled Document (CCD).
2.1 Intent of Interface Agreement
The intent of this Interface Agreement is to establish effective co-operation between Fujitsu
Services and Post Office Ltd for the timely efficient and cost effective delivery of Operational
Business Change using Reference Data to Horizon enabled post office counters.
This Agreement has been renamed and extended to recognise both Product and Branch
Reference Data.
This Interface Agreement identifies:
¢ Post Office Ltd and Fujitsu Services requirement for changes introduced via Reference
Data,
e the agreed end-to-end service solution for Fujitsu Services and Post Office Ltd, 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 Fujitsu Services and Post Office Ltd for the management of
Operational Business Changes. This document provides an “umbrella” agreement for those
and they will comply with the agreements made within this Interface Agreement.
Whilst this Interface Agreement serves as an umbrella for other documentation it cannot
supersede any contractual obligations defined within the Contract. 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 Interface Agreement
This Interface Agreement is applicable to the S80 Horizon release. It will be reviewed for any
future major software release and on an on-going basis. It is maintained by Fujitsu Services
on behalf of both parties.
FUJ00001989
IJ00001989
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE, Page: 20 of 71
FUJ00001989
FUJ00001989
Fujitsu Services Fujitsu Services/Post Office Ltd Interface Agreement — Ref: CS/PRD/058
for Operational Business Change — Reference Data Version: 13.0
COMMERCIAL IN CONFIDENCE Date: 22 February 2006
2.3 Future Developments
Post Office Ltd and Fujitsu Services agree to work jointly to improve the quality and
effectiveness of the Reference Data interface as follows:
e Review the functionality, scope and effectiveness of the Reference Data test environment
and enhance where appropriate.
¢ 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.
e Identify risks to the Reference Data service and take remedial action to eliminate or
mitigate such risks.
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 product data is at risk of late delivery
When it is known that Reference Data for Product changes may be at risk of non delivery by
the time it is required at branches (the Effective Date) it may be necessary to alert parts of
Post Office Ltd so that the relevant staff (branch, helpdesk etc.) are made aware that a
required change may not be present when expected. The only time this is a potential problem
is if the data has been released the day before it is due to become effective and there are then
problems in the overnight processing and/or delivery of the data. In practice the majority of
Reference Data is released at least two days before it is due to become effective and therefore
there is only a small risk of an issue arising.
The principles of the process with respect to data being delivered overnight to become active
at branches the following day are:
© to provide warning to relevant parties in Post Office Ltd and Fujitsu Services, that
there is risk of critical reference data not being available at branches the following
day
e to allow appropriate contingency to be invoked against that risk where lack of the
data would cause critical problems
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE, Page: 21 of 71
FUJ00001989
FUJ00001989
Fujitsu Services Fujitsu Services/Post Office Ltd Interface Agreement — Ref: CS/PRD/058
for Operational Business Change — Reference Data Version: 13.0
COMMERCIAL IN CONFIDENCE Date: 22 February 2006
The process follows the following stages:
e OBC RDST would indicate to RDT (on the authorisation form) that Post Office Ltd
would wish to be informed of overnight processing problems
e RDT would inform FJS duty management and data centre operations that an alert request
had been made
e In the event of overnight processing issues data centre operations would advise the FJS
duty manager of the problem and the FJS duty manager would then advise the Post Office
Ltd duty manager
2.6 Contractual obligations with respect to NBS
The contract for supply of the Network Banking Service included a number of contractual
obligations which have been carried forward into this document.
2.6.1 Extensibility
The NBS shall support, through changes to or the introduction of appropriate Reference Data,
the introduction and removal of new instances of and changes to each of the items (marked as
suffix NWB) shown in Appendix B: Standard Changes — Details. The parties may agree to
vary the allocation of the items from time to time, such variation to be documented by Fujitsu
Services in the working document entitled “Reference Data Change Catalogue”
(CS/IFS/001).
2.6.1.1 Introduction and Change
The introduction of changes to and new instances of items specified above in 2.6.1
(a) shall be effected using only the agreed functions and processes used for
introduction of and changes to reference data for those Post Office Services
existing at the time of introduction of the NBS into this Agreement.
(b) shall not cause to be exceeded:
(i) any limit or range in respect of any such item (including, without
limitation, limits or ranges on the number of IINs) where such limit or
range is specified in the CCD entitled “Horizon Capacity Management and
Business Volumes” (PA/PER/033); and/or
(ii) if no such limit or range is specified in that CCD then a reasonable limit or
range
2.6.1.2 Verification of NBS Reference Data
Post Office Ltd shall be responsible for verifying all NBS related Post Office Reference Data
for use in End to End Banking, save to the extent that Fujitsu Services is obliged to do so (for
the purposes of the use of such Post Office Reference Data within the Post Office Service
Infrastructure) in accordance with paragraph 2.6.1.1 above. For the avoidance of doubt, the
Change Control Procedure shall be used if Post Office Ltd requires, in connection with the
introduction of any of the items referred to in paragraph 2.6.1 above, Reference Data
validation or testing of the NBS (or any element thereof) outside the scope of this Interface
Agreement.
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE, Page: 22 of 71
FUJ00001989
FUJ00001989
Fujitsu Services Fujitsu Services/Post Office Ltd Interface Agreement — Ref: CS/PRD/058
for Operational Business Change — Reference Data Version: 13.0
COMMERCIAL IN CONFIDENCE Date: 22 February 2006
3 Scope
3.1 Interfaces
This Interface Agreement covers all the interfaces between Fujitsu Services and Post Office
Ltd that support the Operational Business Change process for pre-defined Product and Branch
changes.
Interface Interface Interface
Fujitsu
mput” \/Post Office Services Post Office Fujitsu arpa
Ltd process} process ILtd processI Services
* this step is not
needed if change isI
pre-authorised
The start is the point where an OBC form has been completed and issued within Post Office
Ltd, and the end point is where the Reference Data has been released within Fujitsu Services
for delivery to the live counters.
The delivery of the Reference Data to counters, following release authorisation, is covered by
the SLT [see section 3.2].
This Interface Agreement applies to both Product and Branch Changes where:
e a Basic Product Change and HelpDesk Branch Change is a change which consists solely
of Reference Data which requires no additional Fujitsu Services actions and may be
submitted to Fujitsu Services without notice
e an Advanced Change Product Change is a change which requires additional Fujitsu
Services activity and is subject to advanced notification
e an Advanced Branch Change is a change which is subject to advanced notification
Note: Reference Data for Branch Change is usually necessary to support activities such as: a
new Branch Opening, a Branch Relocation, conversion of a Branch franchise, a Branch
Closure. Reference Data also supports changes to branch details such as: opening hours,
telephone number, name and address but excludes the addition or removal of individual
counters. The specific activity for branch change is described in [ref 11]
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE, Page: 23 of 71
FUJ00001989
FUJ00001989
Fujitsu Services Fujitsu Services/Post Office Ltd Interface Agreement — Ref: CS/PRD/058
for Operational Business Change — Reference Data Version: 13.0
COMMERCIAL IN CONFIDENCE Date: 22 February 2006
3.2 Service Level Target
The contractual provisions relating to the distribution of Reference Data to Branches are
defined in Contract Schedule 15.
For convenience the Service Level Targets that appear in Schedule 15 are shown below:
© 96% of Counter Positions will have received the correct version of the Reference Data
by the start of Post Office Core Day on the day following the Agreed Release Date
(i.e. by Day B);
¢ 97% of Counter Positions will have received the correct version of the Reference Data
by the start of Post Office Core Day two days after the Agreed Release Date (i.e. by
Day C);
© 98% of Counter Positions will have received the correct version of the Reference Data
by the start of Post Office Core Day three days after the Agreed Release Date (i.e. by
Day D);
¢ 100% of Counter Positions will have received the correct version of the Reference
Data by the start of Post Office Core Day nine days after the Agreed Release Date (i.e.
by Day J).
For definitive information regarding the above service levels please refer to Schedule 15 of
the contract which takes precedence over this CCD.
3.3, Operational Business Change processes for Product Change
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 Procedure.
A summary of the process is given below.
Note:
Not every Change Type follows every step of the process [see section 4.2].
The timescales for each stage of the process are defined in [section 4.2].
The types of change that the process applies to are defined in [section 4.2].
The responsibilities of each party are defined in [section 9].
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE, Page: 24 of 71
FUJ00001989
FUJ00001989
Fujitsu Services Fujitsu Services/Post Office Ltd Interface Agreement — Ref: CS/PRD/058
for Operational Business Change - Reference Data Version: 13.0
COMMERCIAL IN CONFIDENCE Date: 22 February 2006
3.3.1 Process Diagram
Note: feedback loops exist at all stages for error correction, but are not shown,
) » Ae
entific OBC OBC
request request
Post Office Lid
Operational Fdcus
& Physical
stock ete
Operational Focus
ete
Unauthorised Fujitsu
Services
Fujitsu Services
“Presive™ lz
Fujitsu Services Authorised Post Office
“Live” Ltd
Post Office Ltd
Fujitsu
Data Services
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE, Page: 25 of 71
FUJ00001989
FUJ00001989
Fujitsu Services Fujitsu Services/Post Office Ltd Interface Agreement — Ref: CS/PRD/058
for Operational Business Change — Reference Data Version: 13.0
COMMERCIAL IN CONFIDENCE Date: 22 February 2006
3.3.2 Process Steps
A I Event A— Post Office Ltd I The relevant unit in Post Office Ltd identifies the
Identify business need to introduce, change details of, or
change withdraw a product.
1 I Take Post Office Ltd I The relevant unit in Post Office Ltd identifies if the
actions to change is a Basic Reference Data change, or an
implement Advanced OBC change.
the changes
The relevant unit raise the required OBC forms to:
© Request Post Office Ltd Reference Data Operations
Team (RDOT) to change the Reference Data (for
both Basic and Advanced Changes)
e and request an OBC — Product Change from Fujitsu
Services (for Advanced Changes).
Post Office Ltd OBC RDST confirm the change
requested is an Advanced OBC change and request
Fujitsu Services to make the change.
Post Office Ltd OBC RDST supply any required
additional information to support the Advanced OBC
change.
Post Office Ltd ensure that all necessary
communications and supporting actions for the OBC are
complete.
2 I Update Ref. I Post Office Ltd I Post Office Ltd RDOT changes the Reference Data in
Data system I RDOT RDS to meet the OBC requested and send it to Fujitsu
& send to Services and other users within Post Office Ltd.
Fujitsu N.B. This step is not used where no RDS data is required
Services
3 I Generate Fujitsu Fujitsu Services receives the Reference Data from RDOT
Change and I Services (for all changes) and receives the OBC form and
validate necessary additional information from Post Office Ltd
where OBC RDST (for Advanced Changes).
necessary
Fujitsu Services initiates any required internal actions
e.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
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE, Page: 26 of 71
Fujitsu Services
FUJ00001989
FUJ00001989
Fujitsu Services/Post Office Ltd Interface Agreement — Ref: CS/PRD/058
for Operational Business Change — Reference Data Version: 13.0
COMMERCIAL IN CONFIDENCE Date: 22 February 2006
validated by Fujitsu Services where necessary.
Fujitsu Services generates and delivers the RDMC
Verification Report and the Comparison Report to Post
Office Ltd OBC RDST and delivers the actual Reference
Data change to the verification counters, as appropriate.
Note: Fujitsu Services does not send Pure Basic and
Migration Special Changes to Post Office Ltd OBC
RDST for authorisation, as they are pre-authorised by
Post Office Ltd.
Verify &
authorise
completed
change
Post Office Ltd
OCRDST
Post Office Ltd OBC RDST undertake OBC counter and
report verification (as appropriate) and confirm the
change as delivered is the change required, and
authorises the release of the OBC to the live estate.
Post Office Ltd OBC RDST may also request an alert be
raised if the data is at risk of not being available by the
time it becomes effective. (see section 2.5)
N.B. Some changes are Pre-Authorised — please refer to
[ref 22]
N.B. The following steps may start
after step 1 and run in parallel
5 I Review Fujitsu Fujitsu Services reviews, and responds to, all relevant
Operational I Services Operational Focus or other Horizon update articles
Focus before publication and distribution (when required) to
articles confirm that the contents correctly reflect the system and
will not have an unnecessary impact on Helpdesk
resources. Post Office Ltd shall accept all amendments
reasonably requested by Fujitsu Services in pursuit of the
delivery of contractual services.
The process is described in [ref 17]
6 I Change Fujitsu Fujitsu Services releases Reference Data for all
delivered to I Services authorised OBCs to the live estate.
counters Fujitsu Services will raise Delivery Alert on the Release
Day, if the Alert Flag is set and the change is to be
effective next day. (see section 2.5)
Where agreed with Post Office Ltd, the release may be
held pending communication to the Branches e.g. via
Operational Focus. (However if release delay risks the
Start Date, there may need to be another change
processed to amend the start date of the change).
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE, Page: 27 of 71
FUJ00001989
FUJ00001989
Fujitsu Services Fujitsu Services/Post Office Ltd Interface Agreement — Ref: CS/PRD/058
for Operational Business Change — Reference Data Version: 13.0
COMMERCIAL IN CONFIDENCE Date: 22 February 2006
3.4 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
extended to include the process for introducing new, or amending existing, Icons. The
process and agreed timescales for Icon change are described in [ref 20].
3.5 Operational Business Change processes for Branch Change
The process for effecting changes at branches is fully described in [ref 11]. In some cases
there will be a need for Reference Data to support the physical changes at branches (e.g.
temporary closure for refurbishment). In some cases there will be a need to change Reference
Data when there is no physical work required (e.g. change of opening times).
Whilst the definitive process is in [ref 11] it is worth noting the general steps within this
document:
Post Office Ltd submit Reference Data via RDS to RDMC
2. Fujitsu Services produce reports and send them to the relevant Post Office Ltd SEPT
(CENTRAL)
3. Fujitsu Services release the data no earlier than 48 hours after receipt
Post Office Ltd check reports and if errors are found submit a fresh change
Should Post Office Ltd find an error during the 48 hour window a direct request to Fujitsu
(usually by telephone) may be made to stop the release of the data. In this instance the
telease is no longer pre-authorised and becomes a change which requires authorisation
ws
Note: Reference Data for branch temporary closures is only sent by Post Office Ltd to Fujitsu
when the temporary closure is expected to exceed 10 days.
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE, Page: 28 of 71
FUJ00001989
FUJ00001989
Fujitsu Services Fujitsu Services/Post Office Ltd Interface Agreement — Ref: CS/PRD/058
for Operational Business Change — Reference Data Version: 13.0
COMMERCIAL IN CONFIDENCE Date: 22 February 2006
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.1
and 4.2.5 below. The assumptions listed in the RDCC must be adhered to, in order to apply
these categorisations.
Change types for Branch Changes are defined in [ref 11]
4.2 Product Changes
4.2.1 Standard Changes
The order of the change types in this section is significant and is an indication of the level of
tisk with each type and therefore the amount of checking that is deemed to be necessary. The
change types are of varying 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 or Advanced
Complex Extended.
A complete list of changes applicable to each type is held within the RDCC. Should Post
Office Ltd 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 A: Standard Changes - Details, shows a representative list of the changes for each
type.
4.2.1.1 Basic - Pure
Basic Changes do not require advanced notification from Post Office Ltd to Fujitsu Services
(OBC form). The delivery of the Reference Data file using agreed mechanisms 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. Fujitsu Services 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.1.2 Basic — High Risk
Basic Changes do not require advanced notification from Post Office Ltd to Fujitsu Services
(OBC form). The delivery of the Reference Data file using agreed mechanisms is the request
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE, Page: 29 of 71
FUJ00001989
FUJ00001989
Fujitsu Services Fujitsu Services/Post Office Ltd Interface Agreement — Ref: CS/PRD/058
for Operational Business Change — Reference Data Version: 13.0
COMMERCIAL IN CONFIDENCE Date: 22 February 2006
for change. The file must identify that its contents are a Basic High Risk change. The file may
contain more than one change of the same type. All Basic files contain only Class 1 Reference
Data items. Fujitsu Services 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 Post Office Ltd before release.
4.2.1.3 Advanced Simple
Advanced Simple changes require advanced notification from Post Office Ltd to Fujitsu
Services (an OBC form) to request the change. Associated Reference Data files must be
identifiable as such through the BCR number. Fujitsu Services checks the contents of the file
are appropriate for this type of change. Fujitsu Services has actions to take to implement the
change (in addition to processing the Type A Reference Data file from Post Office Ltd) 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 Post Office Ltd before release.
4.2.1.4 Advanced Standard
Advanced Standard changes require advanced notification from Post Office Ltd to Fujitsu
Services (an OBC form) to request the change. Associated Reference Data files must be
identifiable as such through the BCR number. Fujitsu Services checks the contents of the file
are appropriate for this type of change. Fujitsu Services has actions to take to implement the
change (in addition to processing the Type A Reference Data file from Post Office Ltd) 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 Post Office Ltd before release.
4.2.1.5 Advanced Complex
Advanced Complex changes require advanced notification from Post Office Ltd to Fujitsu
Services (an OBC form) to request the change. Associated Reference Data files must be
identifiable as such through the BCR number. Fujitsu Services checks the contents of the file
are appropriate for this type of change. Fujitsu Services 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 Post
Office Ltd before release.
4.2.1.6 Advanced Complex Extended
This category of change has been introduced to differentiate from ordinary Advanced
Complex changes as the leadtime is longer to allow for additional validation/verification
which is necessary because of the additional complexity of the change. In all other respects
this category is identical to Advanced Complex.
4.2.2. AP (including ADC)
AP changes are similar to Advanced Complex changes and require notification from Post
Office Ltd to Fujitsu Services (an OBC form) to request the change. Associated Reference
Data files must be identifiable as such through the BCR number. Fujitsu Services checks the
contents of the file are appropriate for this type of change. Fujitsu Services has actions to
take to implement the change e.g. test Tokens and supply test files to the appropriate Post
Office Ltd Client for Post Office Ltd End to End testing of changes. These changes require a
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE, Page: 30 of 71
FUJ00001989
FUJ00001989
Fujitsu Services Fujitsu Services/Post Office Ltd Interface Agreement — Ref: CS/PRD/058
for Operational Business Change — Reference Data Version: 13.0
COMMERCIAL IN CONFIDENCE Date: 22 February 2006
Verification and a Comparison report, additional testing and authorisation by Post Office Ltd
before release.
(as described in relevant AP documentation)
Introduce new AP client, service or token
Change client name (new token data)
Cease AP Client, product or token
Introduce new Smart Card
ADC changes are implemented using the same basic process mechanisms as AP although the
timing may differ.
Notes on AP change:
e Changing AP/ADC 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/ADC Client, product or token when the service is Live, i.e. it is not being
withdrawn from a current CTO/ADC cycle, is to be implemented as an Advanced Simple
change, with the client service list being amended after the event.
4.2.3, System Parameters - Pure
With the introduction of Network Banking there is the need to provide a relatively speedy
method of changing some specific system parameters within defined limits. This new
category provides the mechanisms by which Post Office Ltd can request such changes.
Provided that the requested change falls within the limits specified within the Agreement
Fujitsu Services will process the request and deliver the change directly to the Live estate as
there is no verification possible for such changes.
4.2.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. Full details of the process for
Icon changes are described in [ref 20]
4.2.5 Fast-track changes
4.2.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.2]. However, the lead-times [see section 5.9] 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 *
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE, Page: 31 of 71
FUJ00001989
FUJ00001989
Fujitsu Services Fujitsu Services/Post Office Ltd Interface Agreement — Ref: CS/PRD/058
for Operational Business Change — Reference Data Version: 13.0
COMMERCIAL IN CONFIDENCE Date: 22 February 2006
Change min/max quantity/value
Change Long/ Medium / Short name
Add/Amend/Cease End of Session prompt
Add/Amend/Cease Transaction prompt
Add/Amend branch exclusion for urgent suspension
Disable/Enable End of Session prompts at specified branch(es)
Disable/Enable Transaction prompts at specified branch(es)
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 Post Office Ltd OBC RDST by 10am on a working
weekday and
® only normal volumes of change as defined in [section 7.2]
© the Change Number must start with defined prefixes [ref. 15 and 22]. If a Change
is delivered to Fujitsu Services with this prefix but the contents do not meet the
specified criteria it will be processed according to the normal lead-times. Fujitsu
Services will inform Post Office Ltd 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 Post Office Ltd’s
responsibility to provide any additional notification required to users.
© 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.2.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.1]. Migration Specials are pre-authorised for release
and no verification is required.
Migration Special changes are additions or removals to the Reference Data defining
which non-core products a particular branch can or cannot sell. This Reference Data is
needed so that the correct range of Products is available at the branch
Note: The term ‘Migration Special’ was originally used during the roll-out of the
Horizon system and although it has no specific meaning in the context of the Horizon
system today it is still well understood within users of the Reference Data change process
and hence the name remains for this category of change.
The limits for use are:
® additions to Non-core Product to Branch mappings only
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE, Page: 32 of 71
FUJ00001989
FUJ00001989
Fujitsu Services Fujitsu Services/Post Office Ltd Interface Agreement — Ref: CS/PRD/058
for Operational Business Change — Reference Data Version: 13.0
COMMERCIAL IN CONFIDENCE Date: 22 February 2006
® Reference Data must be received by Fujitsu Services by 10am for release to be
actioned on the day of receipt or a phone call is required before 4 p.m. 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 a branch by virtue of:
the urgency with which the data needs to be delivered to the branch.
® Migration Specials refer to one branch or one product — the normal Basic Pure
change may have any combination of products and branches.
Where possible Post Office Ltd should use the Basic Pure change for addition of non-
core association records.
Once Fujitsu Services has confirmed that the Reference Data is of the required type it
will be released to the ‘Live’ environment.
4.2.5.3, Tight Timescales
4.2.5.3.1 Requirement
Fujitsu Services recognises that there may be occasions where Post Office Ltd will be
required to implement changes to Reference Data to timescales which are outside the control
of Post Office Ltd, for example changes announced in the Chancellor of the Exchequer’s
Budget. The implementation of Reference Data in support of such changes must be handled
in a very bespoke manner. Fujitsu Services will use reasonable endeavours to meet the
requirements requested by Post Office Ltd.
4.2.5.3.2 Definition
A Tight Timescale change that cannot be processed using the normal timescales defined for
such a change. It may be caused by either:
® an emergency situation where normal lead-times cannot be adhered to because of legal
circumstances outside of Post Office Ltd control, or
© to allow Post Office Ltd to exploit commercial opportunities
emergency introduction of a Transaction or End of Session prompt to cover legal
obligations (e.g. Money Laundering)
Each instance of such change must be notified in writing by Post Office Ltd to Fujitsu
Services and agreed between Post Office Ltd Head of Sales and Service and the Fujitsu
Services Customer Service Director or their nominated authorised deputies.
4.2.5.3.3 Types
Analysis by Post Office Ltd of the business requirements indicates that the types of change
that require to be actioned in Tight Timescales are:
e Price changes
« Emergency cessation of a product
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE, Page: 33 of 71
FUJ00001989
FUJ00001989
Fujitsu Services Fujitsu Services/Post Office Ltd Interface Agreement — Ref: CS/PRD/058
for Operational Business Change — Reference Data Version: 13.0
COMMERCIAL IN CONFIDENCE Date: 22 February 2006
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.
©) 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
eg.
© product name may be set to “test name” or other identifiably interim name.
e the Branch Trading Statement mapping may be to a line marked as “temporary” .
e the button for the product may not be introduced until a later date, with the product only
available to be sold by PLU initially.
The “interim” product should be verified using standard processes for product change [see
sections 3.3 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 10.3].
The interim details will be later replaced using:
* 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 Branch Trading Statement mapping.
An example of the timeline is shown below:
~( -5 -4 = = - 1
° I I Bf pt OE Weeks
Price /name — Button introduced
details introducedor c/a re-mapped at
as Basic Express a later date as a
standard change
Interim product
introduced as high
priority
© 2006 Fujitsu Si: ¢xceptional Cy IN CONFIDENCE
change with
interim values
FUJ00001989
FUJ00001989
Fujitsu Services Fujitsu Services/Post Office Ltd Interface Agreement — Ref: CS/PRD/058
for Operational Business Change — Reference Data Version: 13.0
COMMERCIAL IN CONFIDENCE Date: 22 February 2006
Interim product
introduced as
standard change
with interim
values
4.2.5.3
Whilst
4 Limitations when information is available at a very late stage
acknowledging that Post Office Ltd 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 Fujitsu Services
must be considered (probably a minimum of I hour)
The time that RDMC takes to process the incoming data must be considered
(approximately 30 minutes)
If counter checks at Post Office Ltd are required an absolute minimum of 2 hours is
required for RDT system processing. It is therefore likely that this time will 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 OBC RDST
The time that Post Office Ltd 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)
In order to meet normal operational schedules, authorisation to release a Tight
Timescales change should be received by Fujitsu Services by 7:30 p.m.
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.2.5.3.3.c
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
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 announcements, 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.
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE, Page: 35 of 71
FUJ00001989
FUJ00001989
Fujitsu Services Fujitsu Services/Post Office Ltd Interface Agreement — Ref: CS/PRD/058
for Operational Business Change — Reference Data Version: 13.0
COMMERCIAL IN CONFIDENCE Date: 22 February 2006
4.2.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 branches.
(see section 10.4)
4.2.5.5 Business Critical Advanced Change
It has been recognised that the Fujitsu Services and Post Office Ltd 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 without the
need for authorisation to be obtained at a senior level within both Post Office Ltd and Fujitsu
Services.
= Each instance of a Business Critical Advanced Change must be agreed by each of the
groups involved in the processing of the change (normally Post Office Ltd Change
Implementation Team, RDOT and RDT) before the change is submitted to Fujitsu
Services for action. This must include agreement on the effective date for the Reference
Data
= 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 I 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)
4.3 Branch Changes
Note: From June 2005 all branch changes are pre-authorised. Please refer to section 3.5.
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE, Page: 36 of 71
FUJ00001989
FUJ00001989
Fujitsu Services Fujitsu Services/Post Office Ltd Interface Agreement — Ref: CS/PRD/058
for Operational Business Change — Reference Data Version: 13.0
COMMERCIAL IN CONFIDENCE Date: 22 February 2006
4.3.1 HelpDesk
Help Desk (HD) changes are those changes which are considered to be of very low risk in the
event that the information is incorrect (e.g. change of a phone number at a branch). They do
not require advanced notification to Fujitsu Services and provided that any file received by
Fujitsu Services only contains changes consistent with being HD then the change is
considered to be pre-authorised and will be released with no further acti
4.3.2: Advanced
Advanced Branch Changes are mostly associated with physical activity in branches. The
Reference Data is supported by an OBC form defining the actual requirement. Reports are
provided to the Post Office Ltd SEPT (Central) to enable them to ensure that the change is as
required.
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE, Page: 37 of 71
FUJ00001989
FUJ00001989
Fujitsu Services Fujitsu Services/Post Office Ltd Interface Agreement — Ref: CS/PRD/058
for Operational Business Change — Reference Data Version: 13.0
COMMERCIAL IN CONFIDENCE Date: 22 February 2006
5 Lead-time for Product Changes
5.1 Introduction
The lead-times quoted in this section are the end-to-end times covering both Post Office Ltd
and Fujitsu Services 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 [section4.2].
These lead-times apply for the volumes given in [section7].
The lead-time runs from initiating a change until the change is Released to the live system.
Delivery to Counters following release is as described in section 3.2
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.
Whilst there are indications of the time taken at each stage of the processing these cannot be
taken to be definitive, ie. the overall leadtime should be taken as the most significant
information.
N.B. The leadtime should be used in relation to when data is required to be delivered to
counters on the Live estate, which may be earlier than the start date on the data.
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE, Page: 38 of 71
FUJ00001989
FUJ00001989
Fujitsu Services Fujitsu Services/Post Office Ltd Interface Agreement — Ref: CS/PRD/058
for Operational Business Change - Reference Data. Version: 13.0
COMMERCIAL IN CONFIDENCE
Date: 22 February 2006
5.2 Basic - Pure
Changes that involve changing Type A Reference Data only and do not require verification.
End-to-End lead time = 5 working days
Business generates change
Post Office Ltd processes
change
RDOT input Reference Data
Fujitsu Services System
processes
Fujitsu Services process
change
I day
1 day
2 days
1 day
Deliver OBC to Post Office Day 1 (6pm)
Ltd
Deliver Reference Data to Day 2 (6pm)
RDOT
Send to Fujitsu Services Day 4 (8pm)
Available to Fujitsu Services. Day 5 (8am) *
Release change Day 5 (8pm)
(release day) ay i:
Post Office
Ltd
Post Office
Lid
Post Office
Ltd
Fujitsu.
Services
Delivery to Counters following release is as described in section 3.2
* 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 Fujitsu
Services, for distribution.
Basic — Pure Reference Data files received by Fujitsu Services by 4pm and
accompanied by a notifying ‘phone call’, on a working weekday, will be released that
night by Fujitsu Services, for distribution.
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE, Page: 39 of 71
Fujitsu Services
Fujitsu Services/Post Office Ltd Interface Agreement
for Operational Business Change — Reference Data
COMMERCIAL IN CONFIDENCE
Ref:
Version: 13.0
FUJ00001989
FUJ00001989
CS/PRD/058
Date: 22 February 2006
5.3 Basic — High Risk
Changes that involve changing Type A Reference Data only and required verification.
End-to-End lead time = 10 working days
Business generates change 1 day
Post Office Ltd processes 1 day
change
RDOT input Reference Data 2 days
Fujitsu Services System
Fujitsu Services process and 2 days
validate change a
‘Fujitsu Services generate. 2 days
RDMC verification &
comparison reports
Post Office Ltd check 2 days
reports and verify change
Fujitsu Services process _ Immediate
authorisation
Available to Fujitsu Services
Deliver OBC to Post Office Ltd Day 1 (6pm)
Deliver Reference Data to Day 2 (6pm)
RDOT
Send to Fujitsu Services Day 4 (8pm)
Day 5 (8am)
Deliver Reference Data to Post Day 6 (6pm)
Office Lid a.
Deliver Reports to Post Office Day 8 (6pm)
Lid
Notifies Fujitsu Services of Day 10 (8pm)
authorisation
Release change
Day 10 (8pm)
(release day) I
Fujitsu
Post Office
Ltd
Post Office
Ltd
Post Office
Ltd
Services
Fujitsu
Services
Post Office
Ltd
Fujitsu
Services
Delivery to Counters following release is as described in section 3.2
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE,
Page: 40 of 71
Fujitsu Services
Fujitsu Services/Post Office Ltd Interface Agreement
for Operational Business Change — Reference Data
COMMERCIAL IN CONFIDENCE
Ref:
Version: 13.0
Date: 22 February 2006
FUJ00001989
FUJ00001989
CS/PRD/058
5.4 Advanced Simple
Changes requiring advanced notification that involve Type A Reference Data changes only
before release.
End-to-End lead time = 10 working days
Business generates change I day
Post Office Ltd processes I day
change
Post Office Ltd processes I day
Reference Data
RDOT input Reference Data 2 days
Fujitsu Services System
‘processes
Fujitsu Services process
request for change
“Fujitsu Services processes I
Reference Data and validate
change I
Fujitsu Services generate
-RDMC verification &
comparison reports
2Qday
Post Office Ltd check
reports and verify change
2 days
Fujitsu Services process Immediate _
authorisation /
Update systems &
I Varies
documentation ee
Deliver OBC to Post Office
Ltd
Deliver notification to Fujitsu
Services
Deliver Reference Data to
RDOT
Send to Fujitsu Services
I Available to Fujitsu Services.
Preparations complete
I Deliver Reference Data to Post I
Office Lid /
I Deliver Reports to Post Office —
tld co ae
Notifies Fujitsu Services of
authorisation
Release change
(release day)
Day I (6pm)
Day2
(6pm)
Day 2
(6pm)
Day 4
(8pm)
Day 5
(8am)
Day 4
(6pm)
Day 6
(6pm)
/ Day &
_ (6pm)
Day 10
(8 pm)
Day 10
pm)
‘Day 11+
Services I
Post Office
Lid
Post Office
Ltd
Post Office
Ltd
Post Office
Lid
Fujitsu.
- Services
_ Services
Fujitsu
Services,
Post Office
Ltd
Fujitsu”
Fujitsu
_Serviees
Delivery to Counters following release is as described in section 3.2
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE,
Page: 41 of 71
Fujitsu Services
Fujitsu Services/Post Office Ltd Interface Agreement
for Operational Business Change — Reference Data
COMMERCIAL IN CONFIDENCE
Ref:
Version: 13.0
FUJ00001989
FUJ00001989
CS/PRD/058
Date: 22 February 2006
5.5 Advanced Standard
Changes that, in addition to Type A Reference Data, require activities such as loading Type B
Reference Data, managing additional information, MIS updates or testing.
End-to-End lead time = 14 working days
Business generates change 1 day
Post Office Ltd processes 1 day
change
Post Office Lid processes 2 days
Reference Data
RDOT input Reference Data 3 days
Fujitsu Services System
processes I
Fujitsu Services process 2 days
request for change :
Fujitsu Services process 2 days
Reference Data —
_RDT validate change I days
Fujitsu Services generate 2 day
-RDMC verification & i
comparison reports
Post Office Ltd check 2 days
reports and verify change
Fujitsu Services process _ Immediate
authorisation ey :
Amend MIS mapping “day
Update documentation _ Varies
Deliver OBC to Post Office Day 1 (6pm)
Ltd
Deliver notification to Fujitsu Day 2
Services (6pm)
Deliver Reference Data to Day 4
RDOT (6pm)
Send to Fujitsu Services Day 7
(8pm)
Available to Fujitsu Services. — Day &
/ (8am)
Preparations complete Day 4
: (6pm)
Ready for validation Day 9
(opm)
Deliver Reference Data to Day 10
I Post Office Ltd (6pm)
Deliver Reports to Post Day 12
Office Lid (6pm)
Notifies Fujitsu Services of Day 14
authorisation (8 pm)
Release change Day 14
(release day) (8 pm)
Day 14
(6pm)
Day 12+
Post Office
Ltd
Post Office
Ltd
Post Office
Ltd
Post Office
Ltd
Fujitsu
Services
Fujitsu
Services
- Fujitsu
Services
Fujitsu
Services
Post Office
Lid
- Fujitsu
Services
Fujitsu
Services
— Fujitsu
Services
Delivery to Counters following release is as described in section 3.2
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE,
Page: 42 of 71
Fujitsu Services Fujitsu Services/Post Office Ltd Interface Agreement
for Operational Business Change - Reference Data
COMMERCIAL IN CONFIDENCE
FUJ00001989
FUJ00001989
Ref: CS/PRD/058
Version: 13.0
Date: 22 February 2006
5.6 Advanced Complex
Changes that require update Type C Reference Data.
End-to-End lead time = 25 working days
Office Ltd
Post Office Ltd processes 2 days Deliver notification to
change Fujitsu Services
Post Office Lid processes 2 days Deliver Reference Data to
Reference Data RDOT
RDOT input Reference Data 5 days Send to Fujitsu Services
“Fujitsu Services System I Available to Fujitsu
“processes I I ices
Fujitsu Services processes 2days = —_—_—‘I Preparation complete
“request for change _ Lo : /
RDTCreateTypeC = days Ready for validation
Reference Data i
RDT Validate changes == 2days__—_I Deliver Reference Data to
i I Post Office Ltd
Fujitsu Services generate / Deliver Reports to Post
RDMC verification® = Office Lid
Gsupresnrepens
Post Office Ltd check 3 days Notifies Fujitsu Services of
reports and verify change authorisation
Fujitsu Services process — Immediate I Release change
authorisation == G@elease day)
Amend MIS mapping ©
Update documentation
(6pm) Lid
Day 6 Post Office
(6pm) Lid
Day 11 Post Office
(8pm) Lid
ney oy
Cam)
Services
_ Fujitsu
Services
Fujitsu
‘Services
- Fujitsu
‘Services
Day 25 Post Office
(8 pm) Ltd
I Day 25
Day ba
(6pm)
Ltd
Day 4 Post Office
Delivery to Counters following release is as described in section 3.2
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE, Page: 43 of 71
Fujitsu Services
Fujitsu Services/Post Office Ltd Interface Agreement
for Operational Business Change — Reference Data
COMMERCIAL IN CONFIDENCE
FUJ00001989
FUJ00001989
Ref: CS/PRD/058
Version: 13.0
Date: 22 February 2006
5.7 Advanced Complex Extended
Changes that may require updated Type C Reference Data and/or extended
validation/verification.
End-to-End lead time = 30 working days
Business generates change
Post Office Ltd processes
change
Post Office Lid processes
Reference Data
RDOT input Reference Data
Fujitsu Services System
“processes
Fujitsu Services processes _
request for change
RDT Create Type C
Reference Data
_RDT Validate changes
Fujitsu Services generate
-RDMC verification &
“comparison reports —
Post Office Lid check
reports and verify change
Fujitsu Services process
authorisation
Update documentation
2 days
2 days
2 days
5 days
“3 days
_ Immediate
Deliver OBC to Post
Office Ltd
Deliver notification to
Fujitsu Services
Deliver Reference Data to
RDOT
Send to Fujitsu Services
Available to Fujitsu
Services:
Preparation complete
Ready for validation
I Deliver Reference Data to
Post Office Ltd
Deliver Reports to Post
Office Lid
Notifies Fujitsu Services of
authorisation
Release change
(release day)
Day 2 (6pm)
Day 4
(6pm)
Day 6
(6pm)
Day I
(8pm)
Day 12
(Sam)
— Day 13
(6pm)
_ Day 23
(6pm)
: Day 25 :
_ fopm)
Day 27
(6pm)
"Day 30
(8 pm)
"Day 30
pm
' Day 30+
Post Office
Ltd
Post Office
Ltd
Post Office
Ltd
Post Office
Ltd
Fujitsu
‘Services
_ Fujitsu
Services
Fujitsu
‘Services
Fujitsu
Services
Post Office
Ltd
Fujitsu
Services
Delivery to Counters following release is as described in section 3.2
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE,
Page: 44 of 71
Fujitsu Services
Fujitsu Services/Post Office Ltd Interface Agreement
for Operational Business Change — Reference Data
COMMERCIAL IN CONFIDENCE
FUJ00001989
FUJ00001989
Ref: CS/PRD/058
Version: 13.0
Date: 22 February 2006
5.8 AP and ADC Client Take-On
As described in AP/ADC Client Service Introduction and Change Processes & CS Services
Catalogue documents [ref. 3 & 4].
5.9 Basic Express
Changes that involve only Type A Reference Data and are one of the named change types in
[section 4.2.5.1]. From a volume perspective Basic Express are a subset of Basic — High
Risk.
End-to-End lead time = 2 working days
Business generates change
Post Office Ltd processes
change
RDOT input Reference Data
Fujitsu Services System
‘processes
Fujitsu Services process
change
Fujitsu Services generate
verification reports
Post Office Ltd check
reports and verify change
Fujitsu Services process
authorisation
2 hours
3 hours
7 hours
2 hours
2 hours
4 hours
2 hours
Deliver OBC to Post Office
Ltd
Deliver Reference Data to
RDOT
Send to Fujitsu Services
Available to Fujitsu
Services
Deliver Reference Data to
Post Office Ltd
Deliver Reports to Post
Office Lid
Notifies Fujitsu Services of
authorisation
Release change
(release day)
Day I (10am)
Day I (1pm)
Day I (8pm)
Day 2 (8am)
Day 2 (10am)
Day 2 (noon)
Day 2 (4pm) *
Day 2 (6pm)
Post Office
Lid
Post Office
Ltd
Post Office
Ltd
Fujitsu
Services
Fujitsu
Services
Post Office
Lid
Fujitsu
Services
Delivery to Counters following release is as described in section 3.2
* Note: As Basic Express is a form of Fast Track change and therefore outside the norm
it is a Fujitsu Services requirement that authorisation is received by 4 pm.
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE,
Page: 45 of 71
FUJ00001989
FUJ00001989
Fujitsu Services Fujitsu Services/Post Office Ltd Interface Agreement — Ref: CS/PRD/058
for Operational Business Change - Reference Data Version: 13.0
COMMERCIAL IN CONFIDENCE Date: 22 February 2006
5.10 Migration Special
To meet the need to apply a quick change to the Product to Branch mappings for an branch
End-to-End lead time = 1 working day
required change identified Notify RDOT * Post Office
Ltd
RDOT input Reference Data Send to Fujitsu Services * Post Office
Ltd
Fujitsu Services process Release change * Fujitsu
change (release day) Services
Delivery to Counters following release is as described in section 3.2
* 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
Fujitsu Services, for distribution.
Migration Special Reference Data files received by Fujitsu Services by 4pm and
accompanied by a notifying ‘phone’ call, on a working weekday, will be released that
night by Fujitsu Services, for distribution.
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE, Page: 46 of 71
FUJ00001989
FUJ00001989
Fujitsu Services Fujitsu Services/Post Office Ltd Interface Agreement — Ref: CS/PRD/058
for Operational Business Change — Reference Data Version: 13.0
COMMERCIAL IN CONFIDENCE Date: 22 February 2006
5.11 System Parameters - Pure
Changes that involve changing system parameters and do not require verification (i.e. are pre-
authorised).
End-to-End lead time = 3 working days
Business generates change I day Deliver OBC to Post Office Day 1 (6pm) Post Office
Ltd Ltd
Post Office Ltd processes I day Deliver information to Fujitsu Day 2 (10am) Post Office
change Services Lid
Fujitsu Services process 2 days Release change Day 3 (8pm) Fujitsu
_change i i i i Services _
Delivery to Counters following release is as described in section 3.2
* Note:
System Parameters — Pure requests arriving by 10 a.m., on a working weekday, will
be processed and the data released by Fujitsu Services for distribution on the night
following.
At the Network Banking release of the Horizon system the only System Parameters
that may be amended using this category are:
MCWP
MAAWP
Amendments will be within limits defined within the Agreement.
6 Leadtimes for Branch Changes
The leadtimes for supplying Reference Data for Branch Changes are defined in [ref 11]
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE, Page: 47 of 71
FUJ00001989
FUJ00001989
Fujitsu Services Fujitsu Services/Post Office Ltd Interface Agreement — Ref: CS/PRD/058
for Operational Business Change — Reference Data Version: 13.0
COMMERCIAL IN CONFIDENCE Date: 22 February 2006
7 Volume of change
7.1 Introduction
The measurement of volumes of change has been revised with effect from the signing of
CCN1100 on 31‘ December 2002. All previous definition of volumes is superseded by the
volumes quoted below.
7.2 Committed volumes
The service provided by Fujitsu Services as specified within this document is constructed as
follows
a) it has the capability to handle an overall maximum of 300 business as usual changes
within one month with the following limits within each of the categories
- Branch Changes 140 per month
- Pre-Authorised Product Change 40 per month
- High Risk Product Change 50 per month
- Advanced Product Change 100 per month
- Automated Payment Change 120 per month
N.B. This maximum includes rework, which is expected to be a maximum of 30 files in
any month.
b) to enable Post Office Ltd to manage the volume and categorisation of changes that are
supplied into this service and to facilitate Fujitsu Services capacity management and
alignment of resources to meet these requirements for managing Reference Data changes,
the framework for a Work Index system has been agreed. The Work Index system will
specify in units an indication of the amount of work required for each file or associated
activity
c) The monthly Work Index limit will be 5000 units which will be equivalent to the
workflow represented by the 300 changes and the identified constraints as specified in a)
above
(DN: It has proved impossible to create a direct correlation between 300 changes and 5000
work units due to the fact that the two figures are measuring completely different things
changes is a simple statement of the number of individual requests whereas work units reflect
the effort required. This needs further consideration for a future release of this document]
The Reference Data Operational Review Forum will oversee the introduction of the Work
Index system and will be responsible for its continued development. The RDORF will
monitor and review the effectiveness of the process and any issues which arise from these
limits.
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE, Page: 48 of 71
FUJ00001989
FUJ00001989
Fujitsu Services Fujitsu Services/Post Office Ltd Interface Agreement — Ref: CS/PRD/058
for Operational Business Change — Reference Data Version: 13.0
COMMERCIAL IN CONFIDENCE Date: 22 February 2006
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.
NWB), is exceptional to these committed volumes and as such will not be counted within any
measurement against this Interface Agreement.
7.3, Network Reinvention
For the period March 2003 to December 2004, Post Office Ltd were running a Network
Reinvention programme. Within the context of this agreement in addition to the volumes
stated above (and not included in the Work Index system) the service was amended to handle
additional Branch and Pre-authorised or High Risk Product Changes. The maximum volumes
of Network Reinvention changes to be handled in any one month at that time were 300
Branch Changes and 23 Pre-authorised or High Risk Product Changes and the maximum
volume of all Branch Changes that could be guaranteed to be processed in any working
weekday was 22 (see Note below). A separate naming convention was agreed for Network
Reinvention changes so that they are shown independently in RDORF reports.
Note: Whilst the Network Reinvention programme was in place, in order to provide the
required level of service Fujitsu Services could only guarantee to process a maximum of 22
Branch Changes in total (i.e. Business as Usual and Network Reinvention) in any working
weekday. Priority was always given to Business as Usual changes. Any Network
Reinvention changes not processed on any working day were then given priority on the next
working day after Business as Usual changes have been processed. In this context changes
received after 10 a.m. on any working weekday are considered as business for the following
working weekday.
Since the formal period of the Network Reinvention programme has concluded but in
recognition that there are still a small number of occasions when similar activities are
required, Fujitsu Services will continue to accept such changes in addition to normal
committed volumes but with the following service limits:
Maximum number of Network Reinvention Changes in any one month — 20
Daily maximum guaranteed (combined bau and Network Reinvention) - 15
8 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 10.4 for managing errors]
Correctly dated (see section 8.3)
Delivered by the relevant deadlines set out in the Interface Agreement [see sections 5 and
6 for required milestones]
© Delivered through the agreed mechanisms.
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE, Page: 49 of 71
FUJ00001989
FUJ00001989
Fujitsu Services Fujitsu Services/Post Office Ltd Interface Agreement — Ref: CS/PRD/058
for Operational Business Change — Reference Data Version: 13.0
COMMERCIAL IN CONFIDENCE Date: 22 February 2006
8.1 Post Office Ltd to Fujitsu Services
Post Office Ltd shall deliver to Fujitsu Services:
1) Reference Data for Advanced and Basic changes
2) Operational Business Change forms for Advanced changes and System Parameter Pure
3) Supporting items and/or information appropriate for changes e.g. AP tokens, Operational
Focus
4) Authorisation for Advanced and High Risk Basic Product changes and Advanced Branch
changes (where appropriate)
8.2 Fujitsu Services to Post Office Ltd
Fujitsu Services shall deliver to Post Office Ltd:
1) Reference Data direct to Live Counters, for OBCs that are pre-authorised by Post Office
Ltd.
2) Reference Data to Verification Counters, for Product Change OBCs to be verified, and
that:
e include Type C Reference Data for Advanced changes when necessary
e has been validated to ensure changes work as requested on the OBC forms.
3) Verification and Comparison Reports (as appropriate for Product Change) that identify
exactly what changes to the counter have been implemented
4) RDMC report (as appropriate) for Advanced Branch Changes
5) Reports to RDORF on volumetrics
8.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 Post Office Ltd if the OBC process is not initiated sufficiently in advance of
the Effective Date to allow for:
e the IFA lead-time for processing, validation, authorisation and release to the Live system
for that particular type of change
e the distribution time to branches.
e additional contingency where Post Office Ltd consider the Reference Data to have
business critical importance
Where, for whatever reason, Post Office Ltd are unable to initiate the OBC process
sufficiently in advance, then Post Office Ltd and Fujitsu Services would establish an Effective
Date to supersede the Start Date.
Fujitsu Services 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.
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE, Page: 50 of 71
FUJ00001989
FUJ00001989
Fujitsu Services Fujitsu Services/Post Office Ltd Interface Agreement — Ref: CS/PRD/058
for Operational Business Change — Reference Data Version: 13.0
COMMERCIAL IN CONFIDENCE Date: 22 February 2006
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 Post Office Ltd delaying authorisation of the
telease of Reference Data is not an approved method.
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE, Page: 51 of 71
FUJ00001989
FUJ00001989
Fujitsu Services Fujitsu Services/Post Office Ltd Interface Agreement — Ref: CS/PRD/058
for Operational Business Change — Reference Data Version: 13.0
COMMERCIAL IN CONFIDENCE Date: 22 February 2006
9 Roles & Responsibilities
9.1 Post Office Ltd —- General
Post Office Ltd shall, without limitation:
9.1.1 Administration and Control
a) Appoint and communicate to Fujitsu Services the name of an owner for this Interface
Agreement. The owner shall maintain and communicate to Fujitsu Services the list of
change authorisers for Product Reference Data.
b) Measure & report on the performance of processes carried out by Post Office Ltd under
this Interface Agreement.
c) Arrange and chair regular Reference Data Operational Review Forums
d) Participate in the Service Review process, to cover all aspects of the process and its
operation, including the provision of forecasts of changes to volumes which might affect
those defined in section 7.2.
e) Review the OBC process, documentation and forms to identify and implement
improvements jointly with Fujitsu Services.
f) Maintain details of the Post Office Ltd contacts relevant to these processes within the
change contacts list in the OLAs [ref. 12 & 13].
g) Ensure that all staff involved in the OBC process are aware of their role and
responsibilities
9.1.2. Implementation
a) Ensure Post Office staff and clients are aware of changes in time to make the necessary
preparations
b) Resolve queries from Fujitsu Services that are material to an OBC
c) Communicate issues and exception information to Fujitsu Services, as reasonably
necessary to assist them, to enable them to manage and control all their relevant change
activity on the Fujitsu Services side of the change interface.
d) Provide the Postmaster communication (e.g. Operational Focus, Memo View) to Fujitsu
Services for comment before release and make any amendments reasonably required by
Fujitsu Services [ref 17]
e) Identify potential variations to the service as soon as known e.g. peak activity
f) Process and communicate Advanced Product changes, in accordance with timescales in
[section 4.3], to Fujitsu Services ensuring, where necessary, that changes are submitted
separately in units of release.
g) Verify relevant Product and Branch changes and provide authorisation ready for release
[in accordance with section 9.6]
h) Ensure that the Post Office Ltd copy of reference documents, e.g. copy of the Menu
Hierarchy, is available to Post Office Ltd staff who require it
i) Maintain and ensure the security of the OBC Product and Reference Data verification
mailboxes on Post Office Ltd servers.
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE, Page: 52 of 71
FUJ00001989
FUJ00001989
Fujitsu Services Fujitsu Services/Post Office Ltd Interface Agreement — Ref: CS/PRD/058
for Operational Business Change — Reference Data Version: 13.0
COMMERCIAL IN CONFIDENCE Date: 22 February 2006
9.1.3 Files & Reference Data
a) Ensure the date contained in the Reference Data is in accordance with the required lead-
times [see sections 5 and 6]
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 Fujitsu Services e.g.
menu hierarchy information [ref. 14] AP CTO/ADC packs etc.
f) Ensure the accuracy and integrity of the change information and Reference Data provided
to Fujitsu Services
g) Reference Data for Mails Application produced from Design Studio, checked according
to guidelines supplied by Fujitsu Services
h) Ensure that a complete set of Mails Help files is submitted whenever any change is
required to the help data
9.2 Post Office Ltd - Reference Data Operational Team
Post Office Ltd RDOT shall, without limitation:
a) Process and transmit basic Reference Data changes to Fujitsu Services 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), using
prefixes and suffixes as defined in [ref 22], where necessary.
d) Ensure that the content of any file is consistent with the change identifier, prefix and
suffix.
9.3 Post Office Ltd Network Business Support Centre (NBSC)
NBSC shall, without limitation:
a) Provide an interface to log Post Office Ltd Live incidents raised by Post Office Ltd or
Fujitsu Services.
b) Monitor, track and provide updates on Post Office Ltd Live incidents, to resolution.
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE, Page: 53 of 71
FUJ00001989
FUJ00001989
Fujitsu Services Fujitsu Services/Post Office Ltd Interface Agreement — Ref: CS/PRD/058
for Operational Business Change — Reference Data Version: 13.0
COMMERCIAL IN CONFIDENCE Date: 22 February 2006
9.4 Fujitsu Services responsibilities
Fujitsu Services shall, without limitation:
9.4.1 Administration and Control
a)
b)
c)
qd)
e)
fy
Appoint and communicate to Post Office Ltd the name of an owner for this Interface
Agreement.
Measure & report to RDORF the performance of Fujitsu Services processes carried out
under this Interface Agreement.
Participate in the Service Review process, to cover all aspects of the process and its
operation, including the provision of a monthly OBC Reference Data Summary report
which summarises activity for the previous month and the volume of change received
over the previous year.
Review the OBC process, documents and forms to identify and implement improvements
jointly with Post Office Ltd.
Maintain the details of the Fujitsu Services contacts relevant to these processes within the
OBC Product Change contacts list in the OLAs [ref. 12 and 13].
Ensure that all staff involved in the OBC process are aware of their role and
responsibilities
9.4.2 Implementation
a)
b)
c)
d)
e)
f)
8)
h)
i)
D
Ensure Fujitsu Services staff and suppliers are aware of changes in time to make the
appropriate preparations, where necessary
Review the Postmaster communication/instructions and notify Post Office Ltd of any
amendments reasonably required, before issue.
Communicate issues and exception information to Post Office Ltd, as reasonably
necessary to assist Post Office Ltd, to enable them to manage and control all their
relevant change activity on the Post Office Ltd side of the change interface.
Receive and progress Basic and Help Desk Reference Data change requests through the
Reference Data change procedures
Receive and progress advanced Reference Data change requests. These may be sent
electronically by Post Office Ltd to the OBC Product Change Mailbox or via fallback
routes (e.g. fax)
Assess Advanced Product changes and identify and deliver the change services needed to
satisfy specific changes
Ensure that supporting Fujitsu Services processes are implemented to manage the
delivery of change services
Ensure that appropriate updates to the Menu Hierarchy are forwarded to Post Office Ltd
librarian for onward distribution within Post Office Ltd
Provide invoices for the completion of work, when appropriate [see section 10.6]
Release correctly authorised changes to meet the Effective Date [see section9.6]
9.4.3 Files & Reference Data
a)
b)
c)
Provide changed Reference Data, Verification and Comparison Reports for Product
Changes in accordance with agreed procedures [see section 0.3]
Provide Reference Data and RDMC reports for Advanced Branch Change
Provide Post Office Ltd with guidelines for checking Mails Reference Data
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE, Page: 54 of 71
FUJ00001989
FUJ00001989
Fujitsu Services Fujitsu Services/Post Office Ltd Interface Agreement — Ref: CS/PRD/058
for Operational Business Change — Reference Data Version: 13.0
COMMERCIAL IN CONFIDENCE Date: 22 February 2006
d) Ensure that Mails Help files are correctly processed against the previously delivered data
so that the increment sent to the Live counters achieves the change required
9.5 Horizon Service Desk (HSD)
HSD
a)
b)
shall, without limitation:
Provide an interface to log Fujitsu Services Live incidents raised by Post Office Ltd or
Fujitsu Services.
Monitor, track and provide updates on Fujitsu Services Live incidents, to resolution.
9.6 Verification, authorisation & release
Note!
)
vvv
2)
VVVVV
v
3)
Vv
4)
Vv
Note:
Fujitsi
: for details of the process [see section 3.3].
Post Office Ltd 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 Fujitsu Services.
Fujitsu Services 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/instruction is appropriate
Raise any queries with Post Office Ltd 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 Post
Office Ltd for verification.
Post Office Ltd shall
Perform Authorisation
Gain the agreement of Fujitsu Services, where Post Office Ltd wish to release a
change that contains a known deviation from the original intention (including an
inappropriate communication).
Fujitsu Services shall
Explain to Post Office Ltd’s reasonable satisfaction any queries which Post Office Ltd
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 Post Office Ltd
approve as acceptable deviations from the original intention.
Release the Reference Data for authorised changes to the live system provided Post
Office Ltd has complied with its obligations set out in [section 9.6 para 3].
certain changes are pre-authorised. When a pre-authorised change is received by
u Services, being identified by the correct naming [ref 22] the change will be released
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE, Page: 55 of 71
FUJ00001989
FUJ00001989
Fujitsu Services Fujitsu Services/Post Office Ltd Interface Agreement — Ref: CS/PRD/058
for Operational Business Change — Reference Data Version: 13.0
COMMERCIAL IN CONFIDENCE Date: 22 February 2006
according to the prescribed schedule for such a change without any other form of
authorisation.
Each party accepts responsibility for those aspects of a change for which it has responsibility
to test.
Business tests for the purpose of verifying changes to Reference Data are conducted by Post
Office Ltd 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 Fujitsu Services. Authorisation from Post Office Ltd to Fujitsu Services
to release Reference Data is made on the basis of these tests.
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE, Page: 56 of 71
FUJ00001989
FUJ00001989
Fujitsu Services Fujitsu Services/Post Office Ltd Interface Agreement — Ref: CS/PRD/058
for Operational Business Change — Reference Data Version: 13.0
COMMERCIAL IN CONFIDENCE Date: 22 February 2006
10 Orders and exceptions
10.1 Release of Reference Data
The release of Reference Data shall be in accordance with Schedule 15 Annex 2 paragraph
3.2. Specifically the Agreed Release Date (i.e. Day A) for each change shall be set on the
following principles:
1. The date by which the Reference Data is required to be effective on the counters in the
live estate is the “Effective Date”
2. Where the Authorisation Date is 10 days or less before the Effective Date the Agreed
Release Date will be no later than the next Working Day following Authorisation.
3. For the avoidance of doubt, for Tight Timescale requests in accordance with paragraph
4.2.5.3 of this document, the Agreed Release Date shall be the same as the Authorisation
Date.
4. Where the Authorisation Date is more than ten days before the Effective Date the Agreed
Release Date will be no later than the first Working Day following the tenth day before
the Effective Date
5. If there is more than one set of Reference Data which needs to be released at or about the
same time and in the view of Fujitsu Services releasing all Authorised data would impose
a risk on the delivery of some of that data, in order to achieve maximum distribution by
the Effective Date:
a) the order in which Reference Data will be released will be based on business
criticality of the Reference Data, as assessed by Post Office Ltd and by agreement
with Fujitsu Services
b) anew Agreed Release Date will be agreed for any Reference Data changes which
are delayed as a result of modifying the order of release of the changes
6. Where authorisation relates to Mails data the Agreed Release Date will be in accord with
the above principles when taking account of the necessary delays for delivery and release
of Mails data as described in 14.2 (Time between changes)
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE, Page: 57 of 71
FUJ00001989
FUJ00001989
Fujitsu Services Fujitsu Services/Post Office Ltd Interface Agreement — Ref: CS/PRD/058
for Operational Business Change — Reference Data Version: 13.0
COMMERCIAL IN CONFIDENCE Date: 22 February 2006
10.2 Orders
e The receipt in the CS Reference Data team mailbox of the OBC form is the confirmed
request from Post Office Ltd to Fujitsu Services, for Advanced Product and System
Parameter Pure Changes
The receipt in an agreed mailbox of the OBC form is the confirmed request from Post Office
Ltd to Fujitsu Services, for Advanced Branch Changes.
e The receipt in an agreed mailbox of the OBC form for an ICON batch is the confirmed
order for any chargeable ICON within that batch.
e The receipt of a Reference Data file containing only Basic (Class 1 or HD Reference
Data) in the RDMC, is the confirmed request for change from Post Office Ltd to Fujitsu
Services.
e The receipt of a correctly completed Authorisation Form from Post Office Ltd is the
confirmed authorisation to release the change.
e The receipt of pre-authorised change files (e.g. Migration Special, Pure Basic, HD or
System Parameter Pure, branch change) 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]), unless
agreed by all parties in advance of any update to the RDCC, will not be accepted and need
to be submitted as a formal (non-OBC) request to Fujitsu Services. 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 formal request has been approved the
delivery mechanisms will be the same as, or similar to, those used for OBC.
10.3 Exceptions
Exceptions, e.g. to volumes or lead-times, will be processed using available resources without
any guarantee of service delivery. Both Post Office Ltd and Fujitsu Services 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 Network Banking) is not an exception.
Post Office Ltd 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.
10.4 Errors and Rework
The Volume of Reworks for BAU changes (i.e. excluding Network Reinvention) is included
in the limits quoted in section 7.2 above but is expected to be a maximum of 30 per month for
BAU changes. This section relates to errors or rework for both Product and Branch Reference
Data, where appropriate.
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE, Page: 58 of 71
FUJ00001989
FUJ00001989
Fujitsu Services Fujitsu Services/Post Office Ltd Interface Agreement — Ref: CS/PRD/058
for Operational Business Change — Reference Data Version: 13.0
COMMERCIAL IN CONFIDENCE Date: 22 February 2006
10.4.1 Recording Pre-Live Incidents
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 the 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
8.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.
Pre-live incidents are recorded on the Peak system used internally by Fujitsu Services Ltd. As
some Peak’s relate to work required by Post Office Ltd it is necessary for Post Office Ltd to
have visibility of Peak data. Details of the passing of information between Fujitsu Services
and Post Office Ltd are shown in Appendix E — Peak control between Fujitsu Services and
Post Office Ltd
10.4.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.
Appropriate steps shall always be taken to establish and eliminate the root cause of Rework.
This will be monitored by the RDORF
10.5 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.
10.6 Charging
e AP Client Take-On (including ADC) is charged as specified [see ref. 4].
e Deviations to the service will be charged as per the Commercial Terms.
e Invoices will be raised and paid in accordance with the Agreement.
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE, Page: 59 of 71
FUJ00001989
FUJ00001989
Fujitsu Services Fujitsu Services/Post Office Ltd Interface Agreement — Ref: CS/PRD/058
for Operational Business Change — Reference Data Version: 13.0
COMMERCIAL IN CONFIDENCE Date: 22 February 2006
11 Appendix A: Standard Changes - Details
Section 4.2.1 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.
N.B. It should be noted that whilst a change may fall into a specific category if there is an
associated change which falls into a different category with a longer lead time on which the
first change is dependent, both changes will adopt the category of the second change.
11.1 Product Changes
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
Add routing gateway (NWB/DCS)
Change name only ~ in routing gateway (NWB/DCS)
Change Bank name only - in Issuer Scheme (NWB/DCS)
Add Banking Operation (when associated item already exists) (NWB/DCS)
Change presentation sequence override only - in Banking Operation (NWB/DCS)
Add method of entry (NWB/DCS)
Change method of entry (NWB/DCS)
Add IIN range for existing non Chip and Pin bank card (NWB/DCS)
Change IIN range for existing non Chip and Pin bank card (NWB/DCS)
Add/Amend/Cease End of Session prompt
Add/Amend/Cease Transaction Prompt
Disable/Enable End of Session prompts at specified branch(es)
Disable/Enable Transaction prompts at specified branch(es)
Changes to Mails which are achieved by amending Reference Data within Design
Studio only
[DN: Please see note regarding Chip and PIN in section 11.1.6]
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE, Page: 60 of 71
FUJ00001989
FUJ00001989
Fujitsu Services Fujitsu Services/Post Office Ltd Interface Agreement — Ref: CS/PRD/058
for Operational Business Change — Reference Data Version: 13.0
COMMERCIAL IN CONFIDENCE Date: 22 February 2006
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
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 screen layout (Menu Hierarchy)
Change accounting node
Add Item Transaction Mode with Item Transaction Mode Code
Change Picklist ordering:
Add/Change/Remove non-value stock product group ordering
Change non-value stock item ordering within product group
Add/Change/Remove advice notes product group ordering
Change advice notes item ordering within product group
Changes to Mails which require Fujitsu Services data alone or in conjunction with
Post Office Ltd Reference Data from RDS or produced within Design Studio
Change End of Session prompt screen heading text
11.1.6 Advanced Complex Extended
Changes to Mails data for Tariff Change
Changes to Horizon reports text fields or content which can be achieved directly using
Fujitsu Services Reference Data.
[DN: The majority of changes to Horizon reports and receipts can only be achieved
hy code changes and are therefore subject to a Work Order. This mechanism within
the OBC processes is limited to those changes which can be made through Reference
Data only and requests for such changes not currently listed in the Reference Data
Change Catalogue must be confirmed with Fujitsu Services prior to raising the OBC.
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE, Page: 61 of 71
FUJ00001989
FUJ00001989
Fujitsu Services Fujitsu Services/Post Office Ltd Interface Agreement — Ref: CS/PRD/058
for Operational Business Change — Reference Data Version: 13.0
COMMERCIAL IN CONFIDENCE Date: 22 February 2006
11.1.7
As changes of this nature are identified they will be added to the Reference Data
Change Catalogue]
Network Banking and Debit Card Service changes other than those listed in Basic
High Risk and System Parameter — Pure.
Change routing gateway — physical (name only change is categorised as HR)
Add Issuer Scheme
Change Issuer Scheme (change to Bank name only is categorised as HR)
Add Banking Operation (when associated item does not exist)
Add NWB Card
Change NWB Card
Add NWB Token Element
Change NWB Token Element
Add IIN range for existing bank card (NWB/DCS)
Change IIN range for existing bank card (NWB/DCS)
[DN: The introduction of all Network Banking entities and amendments to them, with
the exception of those noted in Basic ~ High Risk and System Parameters ~ Pure, will
be Advanced Complex Extended It should be noted that in the future additional
checking of Network Banking Reference Data may be deemed to be necessary, in a
similar fashion to that currently used for AP, in which case leadtimes will need
further consideration.
Please note that Network Banking Contract Schedule NOI defines the leadtime for
changes in this category to be Advanced Complex. At the time that Contract Schedule
NOI was agreed the overall leadtime for Advanced Complex changes was 30 days
however the leadtime for Advanced Complex has since been reduced to 25 days. The
overall leadtime for Advanced Complex Extended changes is 30 days and is therefore
consistent with the leadtime agreed within Contract Schedule NO1.
The introduction of Chip and PIN functionality means that changes of IIN for Chip
and PIN cards now fall into this category due to the fact that IIN data is also held in
the PinPAD and amendments to PinPAD data require action from Fujitsu Services.
Any other changes to data held in the PinPAD will also fall into this category.]
System Parameters — Pure
At the Network Banking release of the Horizon system the only System Parameters
that may be amended using this category are:
MCWP
MAAWP
Amendments will be within limits defined within the Agreement.
N.B. There are similar parameters within the Debit Card Service which may only be
changed using the Work Order mechanism.
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE, Page: 62 of 71
FUJ00001989
FUJ00001989
Fujitsu Services Fujitsu Services/Post Office Ltd Interface Agreement — Ref: CS/PRD/058
for Operational Business Change — Reference Data Version: 13.0
COMMERCIAL IN CONFIDENCE Date: 22 February 2006
11.2 Branch Changes
11.2.1 HelpDesk (HD)
Low risk changes to branch details — e.g. telephone number
11.2.2, Advanced
Higher risk changes to branch details e.g.
¢ Opening times (no physical changes to branch)
e Refurbishments, branch opening/closure, relocations (physical activity
required and therefore Reference Data needs to be dovetailed with this
activity)
12 Appendix B: Changing transactable products between Core
and Non-Core
The following information is provided to give guidance on how to change products from Core
to Non-Core (extreme care is required) and Non-Core to Core (much simpler). Additional
information will be found in the document relating to Business Rules [ref 15]
12.1 Changing items from core to non-core
Although this sounds a simple task there are a number of factors which must be considered to
achieve the change. The major factor is the controlled termination of the item at branches
where it is no longer to be available, especially if those branches may have residual stock.
The cessation of Core or Non-core items globally can be controlled by the removal of Item
Transaction Modes in the required sequence (usually Serve Customer, followed by Bulk Input
Mode, followed by housekeeping modes). A non-core item being removed from an
individual branch by cessation of the non-core link is handled similarly but by an automated
process (referred to as graceful retirement) controlled by the Fujitsu Services system.
When an item is changed from core to non-core there clearly must be non-core links for those
branches which are still required to transact the item after the change however graceful
retirement will not be activated for branches which do not have any non-core links.
The following points need to be considered:
e¢ Would the immediate termination of the item at branches cause an issue (i.e. could
a Branch Trading Statement reprint be requested — is there any value stock being
held at branches which will no longer be linked)
e If yes to the above is it imperative that the existing item is retained (most likely
that there are other systems which rely on the data)
When considering the effect of immediate termination at branches it is very important to take
account of the effect on Branch Trading Statement reprints and stock. If a branch requests a
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE, Page: 63 of 71
FUJ00001989
FUJ00001989
Fujitsu Services Fujitsu Services/Post Office Ltd Interface Agreement — Ref: CS/PRD/058
for Operational Business Change — Reference Data Version: 13.0
COMMERCIAL IN CONFIDENCE Date: 22 February 2006
reprint which includes items which have now gone from their counters and yet have been
transacted within the allowable reprint period, the reprint will be unable to correctly identify
the items and may therefore produce erroneous data. If there is value stock at a branch it will
not be accounted for.
It therefore follows that the action to be taken depends on the type of item being changed and
whether graceful retirement is an essential activity.
1. Instant removal of the item is an issue but it is not imperative that the existing item is
retained
This scenario is probably the most straightforward one to execute as the existing item can
be ceased in a controlled fashion (ceasing the Item Transaction Modes as required) and
the new item introduced at the appropriate time and with the necessary non-core links. It
is therefore the preferred option for value stock items and may also provide the simplest
way of handling all changes from core to non-core.
Note: this methodology is the only one which guarantees that no residual information
remains at branches where the item is no longer used. Either of the following options
may result in branches having some visibility of the item without the ability to use it.
This is because of the way the menu-hierarchy/pick list are built by the Horizon Desktop.
2. Instant removal of item is an issue and the existing item must be retained
In this case the only solution is to make the item non-core and at the same time provide
non-core links for every branch in the estate. This ensures that when the non-core links
are ceased for branches which are no longer to transact the item the automated graceful
retirement activity will take place and therefore Branch Trading Statement reprints will
perform correctly and value stock may be remitted out or will eventually go into the
discrepancy account.
Having created the non-core links to ensure that graceful retirement is activated there are
still two options to remove the unwanted links, largely dependent on the number to
remain but also governed to some extent by RDS bulk upload facilities:
a) cease all non-core links and then re-instate those required (graceful termination
will only occur on those not re-created)
b) cease non-core links on those which are to be removed
3. Instant removal of item is not an issue
N.B. Please see note above regarding the Branch Trading Statement. In practice this option is
only viable when there is an absolute guarantee that there are no transactions in the system
which could be requested for Branch Trading Statement reprint. and there is no stock at any
branches. This therefore suggests that the items in question should only be non-value stock.
If there is any doubt as to the likely outcome then this option MUST NOT be used.
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE, Page: 64 of 71
FUJ00001989
FUJ00001989
Fujitsu Services Fujitsu Services/Post Office Ltd Interface Agreement — Ref: CS/PRD/058
for Operational Business Change — Reference Data Version: 13.0
COMMERCIAL IN CONFIDENCE Date: 22 February 2006
If this option is viable the change is still relatively simple. The item record is changed
to non-core and non-core links are created, effective at the same time that the item
changes to non-core, for those branches which are to continue to use the item.
The item will then become unavailable at branches which no longer have the non-core
links present.
12.2 Changing items from non-core to core
The process for changing items from non-core to core is much more straightforward then
changing from core to non-core. However, to minimise risk of branches receiving the ending
of the non-core links before the changed item information the change must be presented in
two parts:
i) change item to core
ii) cease all non-core links (released when all branches have received i) above
13 Appendix C: Permanent Closure of Branches
13.1 Background
Because of the rate of change of Post Office Branches (with some becoming permanently
closed) there is a need for a mechanism which will reduce the risk of marking a branch
permanently closed when in fact it is still operational. This process is therefore designed to
reduce that risk whilst allowing for bulk data to be submitted for the tidy of the RDS and
RDMC systems.
The mechanics of closing a branch and removing equipment, making changes to non-core
links for another branch and installing additional counter terminals is all handled within
existing OBC process (product and branch). Within the context of this process the only
criteria is that at Day 0 (the last day of trading and public service) the branch is marked as
Temporary Closure within RDS.
13.2 Process
No sooner than 35 days following the successful completion of the OBC processes to remove
the equipment (35 days ensures that any residual data has been collected from the branch
equipment) all branches which fall within the period will become subject to a single change
(or group of changes depending on volume) within this process. In order to simplify the
process it is invoked at the beginning of each month for branches which were temporarily
closed up to 2 months previously, ie. excluding those which were processed in the
immediately preceding month.
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE, Page: 65 of 71
FUJ00001989
FUJ00001989
Fujitsu Services Fujitsu Services/Post Office Ltd Interface Agreement — Ref: CS/PRD/058
for Operational Business Change — Reference Data Version: 13.0
COMMERCIAL IN CONFIDENCE Date: 22 February 2006
Step 1. RDOT will submit to Fujitsu Services a spreadsheet containing the FAD codes
for each branch which is now deemed to be ready to be Permanently Closed following
agreement within Post Office Ltd.
Step 2. Fujitsu Services will check the status of each of the FAD codes listed and
advise RDOT if all of them are in the correct state for Permanent Closure (i.e. they are
no longer receiving or transmitting data to/from the Data Centre).
Step 3. If the answer to Step 2 contains any FADs which are not in a suitable state
RDOT will be advised and the process is terminated, i.e. a completely fresh list must
be submitted. When a list is confirmed as being OK RDT processes will retain the
FADs for checking later in the process.
Step 4. RDS is updated for all of the FADs which are by now confirmed as OK. This
will produce one or more files for delivery to RDMC. Each file will contain the data
for one or more FAD codes, including the cessation of non-core links associated with
that FAD. Change ID’s will be prefixed BTIDY convention and a control Peak will
be raised periodically to enable audit.
Step 5. RDMC will load the data
Step 6. RDT processes will check the data against the list which was confirmed in
step 3.
Step 7. If there are any discrepancies found between Steps 1, 3 and 6, or a branch has
now become active, remedial action will be necessary before the data is released
through the RDDS system. Note: this may include the necessity of introducing the
branch as a new one.
Step 8. Once any anomalies from step 7 have been sorted out the data is released to
RDDS (the data is pre-authorised and therefore no further authorisation is required
from Post Office Ltd)
Should the final list processed through step 8 include any branches which have not been
previously subject to a closure process within other Fujitsu Services systems, Fujitsu Services
will request Post Office Ltd to raise an OBC20 to ensure that all other Fujitsu Services
systems are consistent with the new status.
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE, Page: 66 of 71
FUJ00001989
FUJ00001989
Fujitsu Services Fujitsu Services/Post Office Ltd Interface Agreement — Ref: CS/PRD/058
for Operational Business Change — Reference Data Version: 13.0
COMMERCIAL IN CONFIDENCE Date: 22 February 2006
14 Appendix D —- Mails
Mails is an Horizon desktop service which has replaced the Scales facility. It is based on the
mails package developed by Escher, adapted to be integrated within the Horizon system. The
Reference Data for Mails is produced directly by Post Office Ltd using an Escher supplied
tool, Design Studio. The process for effecting change to the Horizon counters by OBC RDST
sending data to RDT for implementation (that is over a non-automated interface).
Verification and Authorisation are performed using normal processes.
In addition to the Reference Data for the Mails application the Horizon counter supports
HTML which Post Office Ltd have developed to assist the counter staff when using the Mails
application. The updating of this help data is handled using OBC processes even though the
data is not strictly Reference Data.
Because of the way in which the data is transmitted to the counters there are constraints which
need to be considered with regard to the frequency with which changes can be made. The
following information is provided to give an outline of the way in which the system works
and how the constraint can be viewed.
14.1 Subscription Groups
Subscription groups have been introduced to the Horizon system and their first use is for
Mails. The use of subscription groups involves two groups being used and there is a
mechanism to ‘toggle’ between those groups.
The messagestore which exists on each counter in the Horizon system contains data from
itself and its neighbouring counters (nodes 1 to 31), from Correspondence Servers in the data
centre for its own data (nodes 32 to 59) and from subscription groups in the Correspondence
Servers, Groups 111111111 and above. (Note that the FAD code of the branch is the Group
ID in messagestore terms). The Mails Application does not understand the temporal data
which other parts of the Horizon system use however it also differs from other parts of the
Horizon system in that it can be directed to a specific group id from where it should read its
data. It is this ability which has been used to provide a temporal switching capability for
Mails.
Whenever the Mails Application looks for its data, it first looks in the messagestore for a
control object which tells it which subscription group is to be used. The switching between
the groups, or ‘toggling’ is achieved by sending a ‘trigger’ object to the counter at the end of
new data going into one of the subscription groups, the counter then changes the ‘toggle’
object in accordance with the start date in the ‘trigger object’. The ‘toggle’ object is itself a
normal, temporal, object and therefore causes the switch to the relevant subscription group to
occur at the correct date and time.
Note: Mails help data is temporal and therefore does not to use mechanism. Mails help data
is always held in subscription group 111111112.
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE, Page: 67 of 71
FUJ00001989
FUJ00001989
Fujitsu Services Fujitsu Services/Post Office Ltd Interface Agreement — Ref: CS/PRD/058
for Operational Business Change — Reference Data Version: 13.0
COMMERCIAL IN CONFIDENCE Date: 22 February 2006
14.2 Time between changes
Note: this does not apply to Mails Help
There are only two subscription groups available for Mails reference data and therefore there
is an inevitable constraint on how quickly the data can change. One of the groups must
contain the data which is current and there can only be one change ‘in the pipeline’ at any
point in time. Whilst in theory it would be possible to push a second change into the original
group once the start date had been reached for the second group, there needs to be time
allowed for any offices which have failed to synchronise their messagestore with the data
centre so that they don’t suddenly get change occurring on what, to them, may be their active
group.
For example:
1. Group A is currently active and has been since 1/1/2003
2. Group B has been loaded with data with a start date of 1/5/2003 (in the future)
3. On counters in offices which are communicating correctly with the data centre the
‘trigger’ object for the Group B data has created ‘toggle’ objects which will ensure
that on 1/5/2003 the counter starts using Group B (referred to as “paragraph 3”
offices)
4. On counters in offices where there has been a communications failure there is no
Group B data and therefore no ‘toggle’ object (referred to as “paragraph 4” offices.
5. When counters in paragraph 3 reach 1/5/2003 they will switch to Group B and Group
A becomes available for fresh data however offices in paragraph 4 are still using
Group A (although this may have incorrect tariff or script data it is still consistent)
6. When offices in paragraph 4 establish connection to the data centre they will replicate
the Group B data and when this completed the ‘trigger’ object will create the ‘toggle’
object and the counter will start using Group B immediately
7. If new data was loaded into Group A before offices in paragraph 4 had replicated
Group B there is a risk that the Group A data arrives before the Group B data and
causes the Group A data to become unstable. This is why there is an enforced delay
between deliveries to the original group after a change is sent down.
There is an important point with regard to the delivery and start date. Whilst Group A in the
example above must not be changed whilst offices are still potentially using it, if the delivery
to Group B was made in plenty of time so that all offices had the data by the time it should
start, Group A can be changed immediately. This cannot extend to a third change within the
21 day period.
For example:
a) Group B in the above example (start date 1/5/2003) is available for replication by
9/4//2003 (21 days before start date)
b) Group A can have fresh data loaded into it on 2/5/2003 with a start date at any time in
the future because by 1/5/2003 all offices will have correctly ‘toggled’ to Group B
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE, Page: 68 of 71
FUJ00001989
FUJ00001989
Fujitsu Services Fujitsu Services/Post Office Ltd Interface Agreement — Ref: CS/PRD/058
for Operational Business Change — Reference Data Version: 13.0
COMMERCIAL IN CONFIDENCE Date: 22 February 2006
c) A further change cannot be delivered until 22/5/2003 at the earliest to allow the 21
days for b) replication to elapse (but note that the closer the start date is to 1/5/2003
the higher the risk that offices will not have replicated in time)
N.B. 21 days is a pragmatic timeframe although somewhat cautious. Normally offices will
not be offline for that length of time but allowing for major issues, such as a complete
shutdown in the communications network to an office, needs to be considered so that risk is
removed as much as possible.
14.3 Leadtimes for Mails changes
The leadtimes for changes to Mails data will be the same as for all other types of changes and
are broken down as follows:
© Changes (other than tariff) which can be made by Post Office Ltd OBC RDST
amending Reference Data within Design Studio — High Risk
© Changes (other then tariff) which can be made by Post Office Ltd OBC RDST
amending Reference Data within Design Studio in conjunction with EPOSS Data
from RDS along with associated Fujitsu Services data Advanced Complex
e Changes of Fujitsu Services data only which relate to the Mails system —
Advanced Complex
e Tariff change - Advanced Complex Extended
e Any change which requires changes to Mails scripts are subject to the change
control process and are not processed through the OBC process
e Mails Help — Advanced Complex
14.4 Mails Help Data
This is not strictly Reference Data but it is handled using the same fundamental processes as
Reference Data without any implied lead times. Whenever a change is required Post Office
Ltd supply the complete web site to be used on the Horizon counters. RDT then run a process
which produces an increment to the data currently on the counters and this data is then used to
update the currently Live data. Normal validation and verification is performed on this data.
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE, Page: 69 of 71
FUJ00001989
FUJ00001989
Fujitsu Services Fujitsu Services/Post Office Ltd Interface Agreement — Ref: CS/PRD/058
for Operational Business Change — Reference Data Version: 13.0
COMMERCIAL IN CONFIDENCE Date: 22 February 2006
15 Appendix E — Peak control between Fujitsu Services
and Post Office Ltd
Please note that the PeakPeak system has replaced the previous system called Peak however
the two names are often used interchangeably.
This section describes the agreed mechanisms for passing Peak’s from the Fujitsu Services
Peak system to Post Office Ltd and entering responses from Post Office Ltd into the Peak
system. The passing of data between the organisations is necessary because Post Office Ltd
do not have direct access to the Peak system.
The interface for all Peak’s relating to Reference Data for both the Live service and data
provided by Post Office Ltd to support new facilities required by Change Request is the
Fujitsu Services Reference Data Team (RDT).
All Peak’s which need to go to Post Office Ltd will be routed (Peak term) to the RDT team
for onward transmission (in practice the largest number of Peak’s destined for Post Office Ltd
are raised by RDT).
When RDT receive a Peak to be sent onwards the Peak is routed to the appropriate Post
Office Ltd team. In Peak terms these teams are:
POCLRefDataAP _(issues arising which are specifically AP related)
POCLRefDataNCA (issues arising from branch data)
POCLRefDataRDO (issues arising from RDS system or RDOT keying)
POCLRefDataOSG (issues arising from EPOSS data)
Please note that these identities were created when the Post Office Ltd name was POCL and
the teams were as described by the names. Whilst the company name and the individual team
names have changed the use of these Peak names will not be changed as they are for routing
purposes only.
Once the Peak has been routed within the Peak system itself RDT will create an e-mail and
copy in the contents of the Peak on to the e-mail. The subject line in the e-mail must contain
the word ‘Peak’ and the number of the Peak for ease of recognition.
On a periodic basis (at least monthly) RDT will provide a listing of outstanding Peak’s to all
interested parties. RDORF monitors Peak trends and Peak’s outstanding to ensure that issues
are addressed in a timely fashion.
Post Office Ltd must always explicitly respond to the Peak and not rely on the delivery of any
data to be the notification of an update to the Peak.
When RDT receive the explicit response, the Peak will be updated, in most cases by copying
the data in the e-mail into the Peak system. If the response indicates that no further action
will be undertaken by Post Office Ltd the Peak will be routed to the originating team. RDT
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE, Page: 70 of 71
FUJ00001989
FUJ00001989
Fujitsu Services Fujitsu Services/Post Office Ltd Interface Agreement — Ref: CS/PRD/058
for Operational Business Change — Reference Data Version: 13.0
COMMERCIAL IN CONFIDENCE Date: 22 February 2006
will advise the originator of the response that the Peak has been removed from the POCL
stack.
Under some circumstances a Peak may be necessary to show that a problem has occurred but
where no further action is required from Post Office Ltd e.g. where a file has been sent to
RDMC twice. In order to record that the problem occurred RDT will create a Peak, route it to
the relevant Post Office Ltd team and immediately route it back to RDT and, in most cases,
close the Peak. A copy of the Peak will be sent to the relevant team in Post Office Ltd.
© 2006 Fujitsu Services COMMERCIAL IN CONFIDENCE, Page: 71 of 71