Fujitsu
FUJ00232545
FUJ00232545
Fujitsu Services/Post Office Ltd Interface Ref: CS/PRD/058
Services Agreement for Operational Business Change - ‘Version: 12.0
Reference Data
COMMERCIAL IN CONFIDENCE Date: 24 August 2005
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
S80
This Interface Agreement defines for the S80 release of the Horizon
System (which includes the change to Branch Trading, Prompts and
first stages of Track & Trace) 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
© 2005 Fujitsu Services COMMERCIAL IN CONFIDENCE Page: 1 of 69
Fujitsu
Fujitsu Services/Post Office Ltd Interface
Services Agreement for Operational Business Change - _ Version:
Reference Data
COMMERCIAL IN CONFIDENCE
Ref:
CS/PRD/058
12.0
Date: 24 August 2005
FUJ00232545
FUJ00232545
Approval Authorities:
Name Position Signature Date
Dave Baldwin
Rabia Cody Post Office Ltd OBC
Reference Data Service
Change Manager
© 2005 Fujitsu Services COMMERCIAL IN CONFIDENCE
Page: 2 of 69
Fujitsu
Services
Fujitsu Services/Post Office Ltd Interface Ref: CS/PRD/058
Agreement for Operational Business Change - ‘Version: 12.0
Reference Data
COMMERCIAL IN CONFIDENCE Date: 24 August 2005
FUJ00232545
FUJ00232545
0.0 Document Control
0.1. Document History
Version I Date Reason for Issue Associated
No. CCN No.
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
lL Internal version not issued for review
11.2 01/07/2005 Changes for S70 and S80
12.0 24/08/2005 Approved version
0.2 Review Details
Review Comments by :
Review Comments to :
Mandatory Review Authority Name
Fujitsu Services
Aileen Davis
Hilary Forrest
Denise Miller
Post Office Ltd
Rabia Cody
Andy Corbett
David Anders
Mark Knight
Nick Samuel
Matt Warren
© 2005 Fujitsu Services COMMERCIAL IN CONFIDENCE Page: 3 of 69
FUJ00232545
FUJ00232545
Fujitsu Fujitsu Services/Post Office Ltd Interface Ref: CS/PRD/058
Services Agreement for Operational Business Change - ‘Version: 12.0
Reference Data
COMMERCIAL IN CONFIDENCE Date: 24 August 2005
Optional Review / Issued for Information
Fujitsu Services John Shepherd
Mik Peach
Kevin McKeown
Tan Daniel
Nikki Hawkins
Post Office Ltd Liz Tuddenham
Bernadette O’ Donnell
Ijaz Bhatti
0.3 Associated Documents
Please see library for details of latest versions of documents.
Reference Vers I Date Title Source
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
4 Banking Appendix
Note: The original documents which made
RD/CCL/001 .
cc 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
5 Not currently used
6. RDP/AIS/001 AIS Reference Data to Pathway Type A Post
Data Office
Ltd
7. Not currently used
8. RDP/AIS/008 AIS Reference Data to Pathway Type B Post
© 2005 Fujitsu Services COMMERCIAL IN CONFIDENCE Page: 4 of 69
FUJ00232545
FUJ00232545
Fujitsu Fujitsu Services/Post Office Ltd Interface Ref: CS/PRD/058
Services Agreement for Operational Business Change - ‘Version: 12.0
Reference Data
COMMERCIAL IN CONFIDENCE Date: 24 August 2005
Data Office
Ltd
9. CS/PRD/048 Changing Reference Data to Tight Fujitsu
Timescales Services
10. I CS/IFS/002 Reference Data Change Class 1 Analysis Fujitsu
Services
11. I CS/TFS/003 Fujitsu Services / Post Office Ltd Fujitsu
Operational Business Change — Branch Services
Interface Agreement
12. I 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. I CS/POL/006 Service Management Framework Part A Fujitsu
Services
17. I CS/OLA/022 Communications Interface Agreement Fujitsu
Services
18. Not currently used
19. I CS/PRD/028 Process for Changing Menu Hierarchies and I Fujitsu
Icons Services
20. ICS/PDN/018 Horizon Icon Service Description Fujitsu
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
© 2005 Fujitsu Services COMMERCIAL IN CONFIDENCE Page: 5 of 69
Fujitsu
Services
FUJ00232545
FUJ00232545
Fujitsu Services/Post Office Ltd Interface Ref: CS/PRD/058
Agreement for Operational Business Change - ‘Version: 12.0
Reference Data
COMMERCIAL IN CONFIDENCE Date: 24 August 2005
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.
Abbreviation _I Definition
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 validation/verification above that needed for Advanced Complex Change
Change
Advanced Simple
Change
Product Change that requires advanced notice to be given to Fujitsu Services,
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
Standard Change
Product Change that requires advanced notice to be given to Fujitsu Services,
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
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
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
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
© 2005 Fujitsu Services COMMERCIAL IN CONFIDENCE Page: 6 of 69
FUJ00232545
FUJ00232545
Fujitsu Fujitsu Services/Post Office Ltd Interface Ref: CS/PRD/058
Services Agreement for Operational Business Change - ‘Version: 12.0
Reference Data
COMMERCIAL IN CONFIDENCE Date: 24 August 2005
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,
> — The Name of the person who conducted the Business Test,
> The Conclusion of the Business Test, whether Pass or Fail,
e — If Fail, the Failure Reason and Mitigating Action
e — If Pass, indicate whether the Comparison Report had been
checked Yes or No.
For Branch Change OBC the form shall state the BCR and the FAD code
For both Product and Branch change the form provides the notice of
authorisation.
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 responsibility for those aspects of a change for which it has
responsibility to test.
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 I Reference Data.
BAU Business As Usual. Processes within Post Office Ltd that occur regardless of
whether the Horizon system is in use.
© 2005 Fujitsu Services COMMERCIAL IN CONFIDENCE Page: 7 of 69
FUJ00232545
FUJ00232545
Fujitsu Fujitsu Services/Post Office Ltd Interface Ref: CS/PRD/058
Services Agreement for Operational Business Change - ‘Version: 12.0
Reference Data
COMMERCIAL IN CONFIDENCE Date: 24 August 2005
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.
CCD 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 1 data is subsetted into HD, HR and Pure.
Comparison The output from Fujitsu Services’s software tool which is used for identifying the
Report 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
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
© 2005 Fujitsu Services COMMERCIAL IN CONFIDENCE Page: 8 of 69
FUJ00232545
FUJ00232545
Fujitsu Fujitsu Services/Post Office Ltd Interface Ref: CS/PRD/058
Services Agreement for Operational Business Change - ‘Version: 12.0
Reference Data
COMMERCIAL IN CONFIDENCE Date: 24 August 2005
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’.
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).
HSH Fujitsu Services Horizon System Helpdesk.
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 HSH and / or the Post Office Ltd NBSC help
desks.
MAAWP Maximum Authorising Agent Wait Period
Mails Contractual name for the Application which provides the SmartPost 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
NBX Network Banking eXchange
NBS Network Banking Service
NBSC Post Office Ltd Network Business Support Centre.
NIST Network Implementation and Security Team (formerly known as NIET)
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.)
© 2005 Fujitsu Services COMMERCIAL IN CONFIDENCE Page: 9 of 69
FUJ00232545
FUJ00232545
Fujitsu Fujitsu Services/Post Office Ltd Interface Ref: CS/PRD/058
Services Agreement for Operational Business Change - ‘Version: 12.0
Reference Data
COMMERCIAL IN CONFIDENCE Date: 24 August 2005
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.
OBCRDST 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 OBCRDST - 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 bit still may
appear within systems and documentation
PinICL An incident recording system used within Fujitsu Services
Peak The replacement system for PinICL (both names are used interchangeably)
PLU Product Look Up
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 —_I A pre-authorised change is a Reference Data change that by agreement [see
change section 4] 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 (PinICL) 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
© 2005 Fujitsu Services COMMERCIAL IN CONFIDENCE Page: 10 of 69
FUJ00232545
FUJ00232545
Fujitsu Fujitsu Services/Post Office Ltd Interface Ref: CS/PRD/058
Services Agreement for Operational Business Change - ‘Version: 12.0
Reference Data
COMMERCIAL IN CONFIDENCE Date: 24 August 2005
RDOT Post Office Ltd Reference Data Operational Team (Chesterfield)
RDP Post Office Ltd Reference Data Project
RDS Post Office Ltd Reference Data System
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 I 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.
RM Fujitsu Services Release Management
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
© 2005 Fujitsu Services COMMERCIAL IN CONFIDENCE Page: 11 of 69
FUJ00232545
FUJ00232545
Fujitsu Fujitsu Services/Post Office Ltd Interface Ref: CS/PRD/058
Services Agreement for Operational Business Change - ‘Version: 12.0
Reference Data
COMMERCIAL IN CONFIDENCE Date: 24 August 2005
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]
0.5 Changes in this Version
Version Changes
10 ¢ 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
e 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
© 2005 Fujitsu Services COMMERCIAL IN CONFIDENCE Page: 12 of 69
FUJ00232545
FUJ00232545
Fujitsu Fujitsu Services/Post Office Ltd Interface Ref: CS/PRD/058
Services Agreement for Operational Business Change - ‘Version: 12.0
Reference Data
COMMERCIAL IN CONFIDENCE Date: 24 August 2005
¢ References to ‘Agreement’ in section 0.4 changed to ‘Contract’
« Agreement now recognises the Mails service
¢ Section 7.3 amended in light of change requirement for Network
Reinvention
11.0 e Issued for approval
11.1 ¢ Internal version not issued for review
11.2 « Add or amend IIN range for NWB/DCS becomes Advanced Complex
due to introduction of Chip and PIN
e Change of signatories
¢ Heading corrected
© Missing comments incorporated
« Add S80 elements
e 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 ¢ Issued for approval
© 2005 Fujitsu Services COMMERCIAL IN CONFIDENCE Page: 13 of 69
FUJ00232545
FUJ00232545
Fujitsu Fujitsu Services/Post Office Ltd Interface Ref: CS/PRD/058
Services Agreement for Operational Business Change - ‘Version: 12.0
Reference Data
COMMERCIAL IN CONFIDENCE Date: 24 August 2005
0.6 Changes Expected
Changes
¢ 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... sees
MAINTENANCE OF THIS INTERFACE AGREEMENT.
FUTURE DEVELOPMENTS.
SERVICE MANAGEMENT POLICY.
ALERTING WHEN PRODUCT DATA IS AT RISK OF LATE DELIVERY,
CONTRACTUAL OBLIGATIONS WITH RESPECT TO NBS...
2.6.1 Extensibility.
3.1 INTERFACES.
3.2 SERVICE LEVEL TARGET.
3 OPERATIONAL BUSINESS CHANGE PROCESSES FOR PRODUCT CHANG
3.3.1 Process Diagram.
3.3.2 Process Steps
3.4 ICON CHANGE.
RoE
NNN
a
3.5 OPERATIONAL BUSINESS CHANGE PROCESSES FOR BRANCH CHANGE.........+
4.1 INTRODUCTION..
42 PRrobuct CHANGE!
Standard Change:
AP (including ADC
System Parameters - Pure.
Icon Change...
2.5. Fast-track change
43 BRANCH CHANGES.
4.3.1 HelpDesk...
4.3.2 Advanced.
5. INTRODUCTION
5.2 Basic - PUR
53 Basic — HIGH Ris!
54 ADVANCED SIMPL
5.5 ADVANCED STANDARD...
5.6 ADVANCED COMPLEX.
3.7 ADVANCED COMPLEX EXTENDED.
5.8 AP AND ADC CLIENT TAKE-ON...
© 2005 Fujitsu Services COMMERCIAL IN CONFIDENCE Page: 14 of 69
FUJ00232545
FUJ00232545
Fujitsu Fujitsu Services/Post Office Ltd Interface Ref: CS/PRD/058
Services Agreement for Operational Business Change - ‘Version: 12.0
Reference Data
COMMERCIAL IN CONFIDENCE Date: 24 August 2005
5.9
5.10 MIGRATION SPECIAL... .
5.11 SYSTEM PARAMETERS - PURE.
6 LEADTIMES FOR BRANCH CHANGES...
7 VOLUME OF CHANGE.........c00008
71 INTRODUCTION......
72 COMMITTED VOLUMES
73 NETWORK REINVENTION.
8.1 Post OFFICE LTD TO FUusITSU SERVICES.
8.2 FusITsu SERVICES TO Post OFFICE LTD.
8.3 FUTURE DATING......
9 ROLES & RESPONSIBILITIES...
91 Post Orrick 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 TEAN
93 Post OrFIce Lrp NETWORK BUSINESS SUPPORT CENTRE (NBSC).
94 FUJITSU SERVICES RESPONSIBILITIES,
9.4.1 Administration and Control.
9.4.2 Implementation...
9.4.3 Files & Reference Dat
95 HORIZON SERVICE HELPDESK (HSH_
96 VERIFICATION, AUTHORISATION & REI E,
10.1 RELEASE OF REFERENCE DATA.
10.2
10.3
10.4
10.4.1 Recording Pre-Live Incidents.
10.4.2 Rework categorisation and thresholds.
10.5 ESCALATIO!
10.6 CHARGING,
11. APPENDIX A: STANDARD CHANGES - DETAILS.....
1d PRopucT CHANGES
TAL Basic - Pure.
111.2 Basic — High Risk.
1113 Advanced Simple
1114 Advanced Standar
ILLS Advanced Comple:
111.6 Advanced Complex Extended...
IL1.7 System Parameters — Pure.
11.2 BRANCH CHAN
11.2.1 HelpDesk (HD)...
11.2.2 Advanced.
12. APPENDIX B: CHANGING TRANSACTABLE PRODUCTS BETWEEN CORE AND NO!
CORE...
12.1 CHANGING ITEMS FROM CORE TO NON-CORE...
12.2. CHANGING ITEMS FROM NON-CORE TO CORE.
13. APPENDIX C: PERMANENT CLOSURE OF BRANCHES...
© 2005 Fujitsu Services COMMERCIAL IN CONFIDENCE Page: 15 of 69
FUJ00232545
FUJ00232545
Fujitsu Fujitsu Services/Post Office Ltd Interface Ref: CS/PRD/058
Services Agreement for Operational Business Change - ‘Version: 12.0
Reference Data
COMMERCIAL IN CONFIDENCE Date: 24 August 2005
13.1 BACKGROUND..
13.2 PROCESS......
14. APPENDIX D - MAILS.
14.1 SUBSCRIPTION GROUP:
14.2 TIME BETWEEN CHANGES..
14.3 LEADTIMES FOR MAILS CHANGES.
14.4 MAILS HELP DATA... .
15 APPENDIX E - PINICL CONTROL BETWEEN FUJITSU SERVICES AND POST OFFICE LTD
68
© 2005 Fujitsu Services COMMERCIAL IN CONFIDENCE Page: 16 of 69
FUJ00232545
FUJ00232545
Fujitsu Fujitsu Services/Post Office Ltd Interface Ref: CS/PRD/058
Services Agreement for Operational Business Change - ‘Version: 12.0
Reference Data
COMMERCIAL IN CONFIDENCE Date: 24 August 2005
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.
Change Category I Definition Lead-time
(see section 4) (working weekdays)
Product Ra I Hale I Tera
Standard: Ltd I Servie
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 Fujitsu Services testing required
Advanced Change that requires Type C Reference Data from 14 11 I 25
Complex Change I Fujitsu Services
Advanced Change that may require Type C Reference Data from 14 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 I 0.25 I 1
branch, normally where the product is already being
sold prior to migration.
Tight Timescales
A change to make any kind of Reference Data change
quickly, in specified circumstances.
Agreed when
requested
© 2005 Fujitsu Services COMMERCIAL IN CONFIDENCE
Page: 17 of 69
FUJ00232545
FUJ00232545
Fujitsu Fujitsu Services/Post Office Ltd Interface Ref: CS/PRD/058
Services Agreement for Operational Business Change - ‘Version: 12.0
Reference Data
COMMERCIAL IN CONFIDENCE Date: 24 August 2005
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.
© 2005 Fujitsu Services COMMERCIAL IN CONFIDENCE Page: 18 of 69
FUJ00232545
FUJ00232545
Fujitsu Fujitsu Services/Post Office Ltd Interface Ref: CS/PRD/058
Services Agreement for Operational Business Change - ‘Version: 12.0
Reference Data
COMMERCIAL IN CONFIDENCE Date: 24 August 2005
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:
e 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.
© 2005 Fujitsu Services COMMERCIAL IN CONFIDENCE Page: 19 of 69
FUJ00232545
FUJ00232545
Fujitsu Fujitsu Services/Post Office Ltd Interface Ref: CS/PRD/058
Services Agreement for Operational Business Change - ‘Version: 12.0
Reference Data
COMMERCIAL IN CONFIDENCE Date: 24 August 2005
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.
e Continuously monitor the toolset available in the test environment, in particular the
Reference Data comparison tool for identifying impact of planned Reference Data changes
with the possibility of enhancement where appropriate.
© Continuously monitor and where necessary improve the Reference Data Change Catalogue
(RDCC) relating to Reference Data requirements
e Review the consolidated set of Business Rules and procedures which have been jointly
developed and implemented.
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 theprocess 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
© to allow appropriate contingency to be invoked against that risk where lack of the
data would cause critical problems
The process follows the following stages:
© 2005 Fujitsu Services COMMERCIAL IN CONFIDENCE Page: 20 of 69
FUJ00232545
FUJ00232545
Fujitsu Fujitsu Services/Post Office Ltd Interface Ref: CS/PRD/058
Services Agreement for Operational Business Change - ‘Version: 12.0
Reference Data
COMMERCIAL IN CONFIDENCE Date: 24 August 2005
* OBCRDST would indicate to RDT 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.labove. 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.labove, Reference Data
validation or testing of the NBS (or any element thereof) outside the scope of this Interface
Agreement.
© 2005 Fujitsu Services COMMERCIAL IN CONFIDENCE Page: 21 of 69
FUJ00232545
FUJ00232545
Fujitsu Fujitsu Services/Post Office Ltd Interface Ref: CS/PRD/058
Services Agreement for Operational Business Change - ‘Version: 12.0
Reference Data
COMMERCIAL IN CONFIDENCE Date: 24 August 2005
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
Post Office Services Post Office Fujitsu
Ltd processI process Ltd processI Services
l } * process
* this step is not
needed if change is
pre-authorised
The start is the point where an OBC form has been completed and issued within 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]
© 2005 Fujitsu Services COMMERCIAL IN CONFIDENCE Page: 22 of 69
FUJ00232545
FUJ00232545
Fujitsu Fujitsu Services/Post Office Ltd Interface Ref: CS/PRD/058
Services Agreement for Operational Business Change - ‘Version: 12.0
Reference Data
COMMERCIAL IN CONFIDENCE Date: 24 August 2005
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 section4.2].
The timescales for each stage of the process are defined in [section4.2].
The types of change that the process applies to are defined in [section4.2].
The responsibilities of each party are defined in [section 9].
© 2005 Fujitsu Services COMMERCIAL IN CONFIDENCE Page: 23 of 69
Fujitsu
Services
Fujitsu Services/Post Office Ltd Interface
Agreement for Operational Business Change —
Reference Data
COMMERCIAL IN CONFIDENCE
Ref:
Version:
FUJ00232545
FUJ00232545
CS/PRD/058
12.0
Date: 24 August 2005
3.3.1 Process Diagram
Note: feedback loops exist at all stages for error correction, but are not shown,
Operational F%
& Physical
stock etc
“Pre-live”
“Live”
OBC
request
Post Office Ltd
Operational Focus
etc
Fujitsu Services
Fujitsu Services
Post Office Ltd
OBC
request
Unauthorised Fujitsu
Services
Authorised Post Office
Lid
Fujitsu
Data Services
© 2005 Fujitsu Services COMMERCIAL IN CONFIDENCE
Page: 24 of 69
FUJ00232545
FUJ00232545
Fujitsu Fujitsu Services/Post Office Ltd Interface Ref: CS/PRD/058
Services Agreement for Operational Business Change - ‘Version: 12.0
Reference Data
COMMERCIAL IN CONFIDENCE Date: 24 August 2005
3.3.2 Process Steps
Step Taken by Description
A I Event A- Post Office Ltd I The relevant unit in Post Office Ltd identifies the business
Identify need to introduce, change details of, or withdraw a
change product.
1 I Take actions I Post Office Ltd I The relevant unit in Post Office Ltd identifies if the
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)
¢ and request an OBC — Product Change from Fujitsu
Services (for Advanced Changes).
Post Office Ltd OBCRDST confirm the change
requested is an Advanced OBC change and request
Fujitsu Services to make the change.
Post Office Ltd OBCRDST 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
test where necessary additional information from Post Office Ltd
necessary OBCRDST (for Advanced Changes).
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
validated by Fujitsu Services where necessary.
© 2005 Fujitsu Services COMMERCIAL IN CONFIDENCE Page: 25 of 69
FUJ00232545
FUJ00232545
Fujitsu Fujitsu Services/Post Office Ltd Interface Ref: CS/PRD/058
Services Agreement for Operational Business Change - ‘Version: 12.0
Reference Data
COMMERCIAL IN CONFIDENCE Date: 24 August 2005
Fujitsu Services generates and delivers the RDMC
Verification Report and the Comparison Report to Post
Office Ltd OBCRDST 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
OBCRDST for authorisation, as they are pre-authorised
by Post Office Ltd.
4 I Verify & Post Office Ltd I Post Office Ltd OBCRDST undertake OBC counter and
authorise OCRDST report verification (as appropriate) and confirm the
completed change as delivered is the change required, and authorises
change the release of the OBC to the live estate.
Post Office Ltd OBCRDST 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).
© 2005 Fujitsu Services COMMERCIAL IN CONFIDENCE Page: 26 of 69
FUJ00232545
FUJ00232545
Fujitsu Fujitsu Services/Post Office Ltd Interface Ref: CS/PRD/058
Services Agreement for Operational Business Change - ‘Version: 12.0
Reference Data
COMMERCIAL IN CONFIDENCE Date: 24 August 2005
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:
1. Post Office Ltd submit Reference Data via RDS to RDMC
2. Fujitsu Services produce reports and send them to the relevant Post Office Ltd Network
Implementation and Equipment Team (Central)
Pre-authorised changes
3. Fujitsu Services release the data
4. Post Office Ltd check reports and if errors are found submit a fresh change
Changes that require authorisation
5. Post Office Ltd check reports and if errors are found inform Fujitsu Services that a
correction is necessary and produce corrected Reference Data — go back to 1
6. Post Office Ltd authorise the change for release
7. Fujitsu Services release the change
© 2005 Fujitsu Services COMMERCIAL IN CONFIDENCE Page: 27 of 69
FUJ00232545
FUJ00232545
Fujitsu Fujitsu Services/Post Office Ltd Interface Ref: CS/PRD/058
Services Agreement for Operational Business Change - ‘Version: 12.0
Reference Data
COMMERCIAL IN CONFIDENCE Date: 24 August 2005
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
risk with each type and therefore the amount of checking that is deemed to be necessary. The
change types are in order of increasing risk from those which need little or no checking, as the
effect of an error would be minimal on the Live estate, to those which need extensive
checking, as the effect of an error may be significant on the Live estate. Those changes, which
are deemed to require minimal or no checking, are classified as Basic - Pure. Those changes,
which are deemed to require most checking, are classified as Advanced — Complex 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
for change. The file must identify that its contents are a Basic High Risk change. The file may
© 2005 Fujitsu Services COMMERCIAL IN CONFIDENCE Page: 28 of 69
FUJ00232545
FUJ00232545
Fujitsu Fujitsu Services/Post Office Ltd Interface Ref: CS/PRD/058
Services Agreement for Operational Business Change - ‘Version: 12.0
Reference Data
COMMERCIAL IN CONFIDENCE Date: 24 August 2005
contain more than one change of the same type. All Basic files contain only Class I 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
Verification and a Comparison report, additional testing and authorisation by Post Office Ltd
before release.
© 2005 Fujitsu Services COMMERCIAL IN CONFIDENCE Page: 29 of 69
FUJ00232545
FUJ00232545
Fujitsu Fujitsu Services/Post Office Ltd Interface Ref: CS/PRD/058
Services Agreement for Operational Business Change - ‘Version: 12.0
Reference Data
COMMERCIAL IN CONFIDENCE Date: 24 August 2005
(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 *
Change min/max quantity/value
Change Long/ Medium / Short name
Add/Amend/Cease End of Session prompt
© 2005 Fujitsu Services COMMERCIAL IN CONFIDENCE Page: 30 of 69
FUJ00232545
FUJ00232545
Fujitsu Fujitsu Services/Post Office Ltd Interface Ref: CS/PRD/058
Services Agreement for Operational Business Change - ‘Version: 12.0
Reference Data
COMMERCIAL IN CONFIDENCE Date: 24 August 2005
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 OBCRDST 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.
=o 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 only to the Reference Data defining which non-
core products a particular branch can sell, normally where the branch has been selling the
item but the Reference Data does not reflect this. This Reference Data is needed so that
the Cash Account can record those sales, when it is migrated to the Horizon system.
The limits for use are:
© additions to Non-core Product to Branch mappings only
® 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 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.
© 2005 Fujitsu Services COMMERCIAL IN CONFIDENCE Page: 31 of 69
FUJ00232545
FUJ00232545
Fujitsu Fujitsu Services/Post Office Ltd Interface Ref: CS/PRD/058
Services Agreement for Operational Business Change - ‘Version: 12.0
Reference Data
COMMERCIAL IN CONFIDENCE Date: 24 August 2005
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
e Emergency cessation of a product
e Product introduction or change where the product has been created in advance with
interim details.
a) Price Change
The most frequent Tight Timescale changes are price changes. These may be processed via the
fast-track Basic Express route.
b) Emergency cessation
From the CSR+ version of Horizon the ability to transact a product is controlled by the use of
Item Transaction Modes and therefore these type of changes may be processed via the fast-
track Basic Express route.
© 2005 Fujitsu Services COMMERCIAL IN CONFIDENCE Page: 32 of 69
FUJ00232545
FUJ00232545
Fujitsu Fujitsu Services/Post Office Ltd Interface Ref: CS/PRD/058
Services Agreement for Operational Business Change - ‘Version: 12.0
Reference Data
COMMERCIAL IN CONFIDENCE Date: 24 August 2005
©) 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 cash account mapping may be to a line marked as “temporary” .
e the button for the product may not be introduced until a later date, with the product only
available to be sold by PLU initially.
The “interim” product should be verified using standard processes for product change [see
sections 3.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:
e a Basic Express change for the final information relating to price and name. This must be
identifiable as part of the Tight Timescale change, and will be verified via the Verification
Report for Basic Express, before the change is released
e standard changes that occur after the go live of the product e.g. the introduction of the
button, or the change of the Cash Account mapping.
An example of the timeline is shown below:
Weeks
Interim product _ Interim product Price f name int Button ’
introduced as introduced as . ‘ah ed introduces da cla
standard change high priority introduced as re-mapped at a
with interim exceptional Basic Express later date as a
values change with standard change
interim values
4.2.5.3.4 Limitations when information is available at a very late stage
Whilst 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
© 2005 Fujitsu Services COMMERCIAL IN CONFIDENCE Page: 33 of 69
FUJ00232545
FUJ00232545
Fujitsu Fujitsu Services/Post Office Ltd Interface Ref: CS/PRD/058
Services Agreement for Operational Business Change - ‘Version: 12.0
Reference Data
COMMERCIAL IN CONFIDENCE Date: 24 August 2005
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).
e 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)
e The time that RDMC takes to process the incoming data must be considered
(approximately 30 minutes)
e 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 OBCRDST
e 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)
e 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.¢
e Changes to Menu Hierarchy can only be achieved within Tight Timescales when
sufficient time is available — under normal circumstances, where the normal leadtime is
not available, a Business Critical Advanced Change may be appropriate
e An overnight change should therefore only be of the type which amends the price or
name of items
On the basis of the above timings, the latest time for commencement for an overnight Tight
Timescales change, such as Budget 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.
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. I 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.
© 2005 Fujitsu Services COMMERCIAL IN CONFIDENCE Page: 34 of 69
FUJ00232545
FUJ00232545
Fujitsu Fujitsu Services/Post Office Ltd Interface Ref: CS/PRD/058
Services Agreement for Operational Business Change - ‘Version: 12.0
Reference Data
COMMERCIAL IN CONFIDENCE Date: 24 August 2005
= 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.
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 activity.
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 NIST (Central) to enable them to ensure that the change is as
required.
© 2005 Fujitsu Services COMMERCIAL IN CONFIDENCE Page: 35 of 69
FUJ00232545
FUJ00232545
Fujitsu Fujitsu Services/Post Office Ltd Interface Ref: CS/PRD/058
Services Agreement for Operational Business Change - ‘Version: 12.0
Reference Data
COMMERCIAL IN CONFIDENCE Date: 24 August 2005
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, i.e. 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.
© 2005 Fujitsu Services COMMERCIAL IN CONFIDENCE Page: 36 of 69
FUJ00232545
FUJ00232545
Fujitsu Fujitsu Services/Post Office Ltd Interface Ref: CS/PRD/058
Services Agreement for Operational Business Change - ‘Version: 12.0
Reference Data
COMMERCIAL IN CONFIDENCE Date: 24 August 2005
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
Action Duration I Result Milestone Owner
Business generates change 1 day Deliver OBC to Post Office Day I (6pm) Post Office
Lid Ltd
Post Office Ltd processes I day Deliver Reference Data to Day 2 (6pm) Post Office
change RDOT Ltd
RDOT input Reference Data 2 days Send to Fujitsu Services Day 4 (8pm) Post Office
Ltd
Fujitsu Services System Available to Fujitsu Services Day 5 (8am) *
processes
Fujitsu Services process I day Release change Day 5 (8pm) Fujitsu
change (release day) 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.
© 2005 Fujitsu Services COMMERCIAL IN CONFIDENCE Page: 37 of 69
FUJ00232545
FUJ00232545
Fujitsu Fujitsu Services/Post Office Ltd Interface Ref: CS/PRD/058
Services Agreement for Operational Business Change - ‘Version: 12.0
Reference Data
COMMERCIAL IN CONFIDENCE Date: 24 August 2005
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
Action Duration Result Milestone Owner
Business generates change 1 day Deliver OBC to Post Office Ltd Day I (6pm) Post Office
Ltd
Post Office Ltd processes I day Deliver Reference Data to Day 2 (6pm) Post Office
change RDOT Lid
RDOT input Reference Data 2 days Send to Fujitsu Services Day 4 (8pm) Post Office
Ltd
Fujitsu Services System Available to Fujitsu Services. Day 5 (8am)
processes
Fujitsu Services process 2 days Deliver Reference Data to Post Day 6 (6pm) Fujitsu
change Office Ltd Services
Fujitsu Services generate 2 days Deliver Reports to Post Office Day 8 (6pm) Fujitsu
RDMC verification & Lid Services
comparison reports
Post Office Ltd check 2 days Notifies Fujitsu Services of Day 10 (8pm) Post Office
reports authorisation Ltd
Fujitsu Services process Immediate Release change Day 10 (8pm) Fujitsu
authorisation (release day) Services
Delivery to Counters following release is as described in section 3.2
© 2005 Fujitsu Services COMMERCIAL IN CONFIDENCE
Page: 38 of 69
FUJ00232545
FUJ00232545
Fujitsu Fujitsu Services/Post Office Ltd Interface Ref: CS/PRD/058
Services Agreement for Operational Business Change - ‘Version: 12.0
Reference Data
COMMERCIAL IN CONFIDENCE Date: 24 August 2005
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
Action Duration Result Milestone Owner
Business generates change I day Deliver OBC to Post Office Day 1 (6pm) Post Office
Lid Lid
Post Office Ltd processes 1 day Deliver notification to Fujitsu Day 2 I Post Office
change Services (6pm) Lid
Post Office Ltd processes I day Deliver Reference Data to Day 2 Post Office
Reference Data RDOT (6pm) Lid
RDOT input Reference Data 2 days Send to Fujitsu Services Day 4 Post Office
(8pm) Lid
Fujitsu Services System Available to Fujitsu Services. Day 5
processes (8am)
Fujitsu Services process 2 days Preparations complete Day 4 Fujitsu
request for change (6pm). Services
Fujitsu Services processes 2 days Deliver Reference Data to Post Day 6 Fujitsu
Reference Data Office Lid (6pm) Services
Fujitsu Services generate 2 day Deliver Reports to Post Office Day 8 Fujitsu
RDMC verification & Lid (6pm) Services
comparison reports
Post Office Ltd check 2 days Notifies Fujitsu Services of Day 10 Post Office
reports authorisation (8 pm) Lid
Fujitsu Services process Immediate Release change Day 10 Fujitsu
authorisation (release day) (8 pm) Services
Update systems & Varies Day 11+ Fujitsu
documentation Services
Delivery to Counters following release is as described in section 3.2
© 2005 Fujitsu Services COMMERCIAL IN CONFIDENCE
Page: 39 of 69
Fujitsu
Services
Fujitsu Services/Post Office Ltd Interface
Agreement for Operational Business Change —
Reference Data
COMMERCIAL IN CONFIDENCE
Ref:
Version: 12.0
FUJ00232545
FUJ00232545
CS/PRD/058
Date: 24 August 2005
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
Action
Business generates change
Post Office Ltd processes
change
Post Office Ltd processes
Reference Data
RDOT input Reference Data
Fujitsu Services System
processes
Fujitsu Services process
request for change
Fujitsu Services process
Reference Data
RDT test change
Fujitsu Services generate
RDMC verification &
comparison reports
Post Office Ltd check
reports
Fujitsu Services process
authorisation
Amend MIS mapping
Update documentation
Duration
I day
1 day
2 days
3 days
2 days
2 days
I days
2 day
2 days
Immediate
1 day
Varies
Result
Deliver OBC to Post Office
Ltd
Deliver notification to
Fujitsu Services
Deliver Reference Data to
RDOT
Send to Fujitsu Services
Available to Fujitsu Services
Preparations complete
Ready for testing
Deliver Reference Data to
Post Office Ltd
Deliver Reports to Post
Office Ltd
Notifies Fujitsu Services of
authorisation
Release change
(release day)
Milestone
Day I (6pm)
Day 2
(6pm)
Day 4
(6pm)
Day 7
(8pm)
Day 8
(8am)
Day 4
(6pm)
Day 9
(6pm)
Day 10
(6pm)
Day 12
(6pm)
Day 14
(8 pm)
Day 14
(8 pm)
Day 14
(6pm)
Day 12+
Owner
Post Office
Lid
Post Office
Ltd
Post Office
Lid
Post Office
Ltd
Fujitsu
Services
Fujitsu
Services
Fujitsu
Services
Fujitsu
Services
Post Office
Ltd
Fujitsu
Services
Fujitsu
Services
Fujitsu
Services
Delivery to Counters following release is as described in section 3.2
© 2005 Fujitsu Services COMMERCIAL IN CONFIDENCE
Page: 40 of 69
FUJ00232545
FUJ00232545
Fujitsu Fujitsu Services/Post Office Ltd Interface Ref: CS/PRD/058
Services Agreement for Operational Business Change - ‘Version: 12.0
Reference Data
COMMERCIAL IN CONFIDENCE Date: 24 August 2005
5.6 Advanced Complex
Changes that require update Type C Reference Data.
End-to-End lead time = 25 working days
Action Duration Result Milestone Owner
Business generates change 2 days Deliver OBC to Post Office Day 2 (6pm) Post Office
Ltd Ltd
Post Office Ltd processes 2 days Deliver notification to Day 4 Post Office
change Fujitsu Services (6pm) Ltd
Post Office Ltd processes 2 days Deliver Reference Datato Day 6 Post Office
Reference Data RDOT (6pm) Ltd
RDOT input Reference Data 5 days Send to Fujitsu Services Day 11 Post Office
(8pm) Ltd
Fujitsu Services System Available to Fujitsu Day 12
processes Services (8am)
Fujitsu Services process 2 days Preparations complete & Day 7 Fujitsu
request for change notify CD (6pm) Services
Fujitsu Services processes 2 days RDT handover to CD Day 13 Fujitsu
Reference Data (6pm) Services
Create Type C Reference 5 days Ready for testing Day 18 Fujitsu
Data (6pm) Services
RDT Validate changes 2 days Deliver Reference Data to Day 20 Fujitsu
Post Office Ltd (6pm), Services
Fujitsu Services generate 2 day Deliver Reports to Post Day 22 Fujitsu
RDMC verification & Office Ltd (6pm) Services
comparison reports
Post Office Ltd check 3 days Notifies Fujitsu Services of Day 25 Post Office
reports authorisation (8 pm) Lid
Fujitsu Services process Immediate Release change Day 25
authorisation (release day) (8 pm)
Amend MIS mapping I day Day 25 Fujitsu
(6pm) Services
Update documentation Varies Day 25+ Fujitsu
Services
Delivery to Counters following release is as described in section 3.2
© 2005 Fujitsu Services COMMERCIAL IN CONFIDENCE
Page: 41 of 69
FUJ00232545
FUJ00232545
Fujitsu Fujitsu Services/Post Office Ltd Interface Ref: CS/PRD/058
Services Agreement for Operational Business Change - ‘Version: 12.0
Reference Data
COMMERCIAL IN CONFIDENCE Date: 24 August 2005
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
Action Duration Result Milestone Owner
Business generates change 2 days Deliver OBC to Post Office Day 2 (6pm) Post Office
Ltd Lid
Post Office Ltd processes 2 days Deliver notification to Day 4 Post Office
change Fujitsu Services (6pm) Ltd
Post Office Ltd processes 2 days Deliver Reference Datato Day 6 Post Office
Reference Data RDOT (6pm) Ltd
RDOT input Reference Data 5 days Send to Fujitsu Services Day 11 Post Office
(8pm) Ltd
Fujitsu Services System Available to Fujitsu Day 12
processes Services (8am)
Fujitsu Services process 2 days Preparations complete & Day 7 Fujitsu
request for change notify CD (6pm) Services
Fujitsu Services processes 2 days RDT handover to CD Day 13 Fujitsu
Reference Data (6pm) Services
Create Type C Reference 10 days Ready for testing Day 23 Fujitsu
Data (6pm) Services
RDT Validate changes 2 days Deliver Reference Data to Day 25 Fujitsu
Post Office Ltd (6pm) Services
Fujitsu Services generate 2 day Deliver Reports to Post Day 27 Fujitsu
RDMC verification & Office Lid (6pm) Services
comparison reports
Post Office Ltd check 3 days Notifies Fujitsu Services of Day 30 Post Office
reports authorisation (8 pm) Ltd
Fujitsu Services process Immediate Release change Day 30
authorisation (release day) (8 pm)
Amend MIS: mapping I day Day 30 Fujitsu
(6pm). Services
Update documentation Varies Day 30+ Fujitsu
Services
Delivery to Counters following release is as described in section 3.2
© 2005 Fujitsu Services COMMERCIAL IN CONFIDENCE
Page: 42 of 69
Fujitsu
Services
Fujitsu Services/Post Office Ltd Interface
Agreement for Operational Business Change —
Reference Data
COMMERCIAL IN CONFIDENCE
FU.
Ref:
Version:
CS/PRD/058
12.0
Date: 24 August 2005
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].
End-to-End lead time = 2 working days
FUJ00232545
}J00232545
Action
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
Fujitsu Services process
authorisation
Duration
2 hours
3 hours
7 hours
2 hours
2 hours
4 hours
2 hours
Result
Deliver OBC to Post Office
Lid
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)
Milestone Owner
Day 1 (10am) Post Office
Ltd
Day 1 (Ipm) Post Office
Lid
Day 1 (8pm) Post Office
Lid
Day 2 (8am)
Day 2 (10am) Fujitsu
Services
Day 2 (noon) Fujitsu
Services
Day 2 (4pm) * Post Office
Ltd
Day 2 (6pm) 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.
© 2005 Fujitsu Services COMMERCIAL IN CONFIDENCE
Page: 43 of 69
FUJ00232545
FUJ00232545
Fujitsu Fujitsu Services/Post Office Ltd Interface Ref: CS/PRD/058
Services Agreement for Operational Business Change - ‘Version: 12.0
Reference Data
COMMERCIAL IN CONFIDENCE Date: 24 August 2005
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
Action Result Milestone Owner
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.
© 2005 Fujitsu Services COMMERCIAL IN CONFIDENCE
Page: 44 of 69
FUJ00232545
FUJ00232545
Fujitsu Fujitsu Services/Post Office Ltd Interface Ref: CS/PRD/058
Services Agreement for Operational Business Change - ‘Version: 12.0
Reference Data
COMMERCIAL IN CONFIDENCE Date: 24 August 2005
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
Action Duration I Result Milestone Owner
Business generates change 1 day Deliver OBC to Post Office Day I (6pm) Post Office
Lid Ltd
Post Office Ltd processes I day Deliver information to Fujitsu Day 2 (10am) Post Office
change Services Ltd
Fujitsu Services process 2 days Release change Day 3 (8pm) Fujitsu
change 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]
© 2005 Fujitsu Services COMMERCIAL IN CONFIDENCE Page: 45 of 69
FUJ00232545
FUJ00232545
Fujitsu Fujitsu Services/Post Office Ltd Interface Ref: CS/PRD/058
Services Agreement for Operational Business Change - ‘Version: 12.0
Reference Data
COMMERCIAL IN CONFIDENCE Date: 24 August 2005
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.
The baseline for Reference Data record changes is given in the AIS [ref. 5].
© 2005 Fujitsu Services COMMERCIAL IN CONFIDENCE Page: 46 of 69
FUJ00232545
FUJ00232545
Fujitsu Fujitsu Services/Post Office Ltd Interface Ref: CS/PRD/058
Services Agreement for Operational Business Change - ‘Version: 12.0
Reference Data
COMMERCIAL IN CONFIDENCE Date: 24 August 2005
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.
eeee
8.1 Post Office Ltd to Fujitsu Services
Post Office Ltd shall deliver to Fujitsu Services:
© 2005 Fujitsu Services COMMERCIAL IN CONFIDENCE Page: 47 of 69
FUJ00232545
FUJ00232545
Fujitsu Fujitsu Services/Post Office Ltd Interface Ref: CS/PRD/058
Services Agreement for Operational Business Change - ‘Version: 12.0
Reference Data
COMMERCIAL IN CONFIDENCE Date: 24 August 2005
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
© 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. 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
release of Reference Data is not an approved method.
© 2005 Fujitsu Services COMMERCIAL IN CONFIDENCE Page: 48 of 69
FUJ00232545
FUJ00232545
Fujitsu Fujitsu Services/Post Office Ltd Interface Ref: CS/PRD/058
Services Agreement for Operational Business Change - ‘Version: 12.0
Reference Data
COMMERCIAL IN CONFIDENCE Date: 24 August 2005
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.
) 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]
) Identify potential variations to the service as soon as known e.g. peak activity
Process and communicate Advanced Product changes, in accordance with timescales in
[section 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
a
@
Ra]
© 2005 Fujitsu Services COMMERCIAL IN CONFIDENCE Page: 49 of 69
FUJ00232545
FUJ00232545
Fujitsu Fujitsu Services/Post Office Ltd Interface Ref: CS/PRD/058
Services Agreement for Operational Business Change - ‘Version: 12.0
Reference Data
COMMERCIAL IN CONFIDENCE Date: 24 August 2005
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.
© 2005 Fujitsu Services COMMERCIAL IN CONFIDENCE Page: 50 of 69
FUJ00232545
FUJ00232545
Fujitsu Fujitsu Services/Post Office Ltd Interface Ref: CS/PRD/058
Services Agreement for Operational Business Change - ‘Version: 12.0
Reference Data
COMMERCIAL IN CONFIDENCE Date: 24 August 2005
9.4 Fujitsu Services responsibilities
Fujitsu Services shall, without limitation:
9.4.1 Administration and Control
a)
b)
c)
d)
e)
f)
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)
n)
i)
a)
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
© 2005 Fujitsu Services COMMERCIAL IN CONFIDENCE Page: 51 of 69
FUJ00232545
FUJ00232545
Fujitsu Fujitsu Services/Post Office Ltd Interface Ref: CS/PRD/058
Services Agreement for Operational Business Change - ‘Version: 12.0
Reference Data
COMMERCIAL IN CONFIDENCE Date: 24 August 2005
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 Helpdesk (HSH)
HSH shall, without limitation:
a) Provide an interface to log Fujitsu Services Live incidents raised by Post Office Ltd or
Fujitsu Services.
b) Monitor, track and provide updates on Fujitsu Services Live incidents, to resolution.
9.6 Verification, authorisation & release
Note: for details of the process [see section 3.3].
1) 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.
VVV
2) 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.
VVVVV
Vv
3) 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).
4) 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].
v
v
Note: certain changes are pre-authorised. When a pre-authorised change is received by
Fujitsu Services, being identified by the correct naming [ref 22] the change will be released
according to the prescribe schedule for such a change without any other form of authorisation.
© 2005 Fujitsu Services COMMERCIAL IN CONFIDENCE Page: 52 of 69
FUJ00232545
FUJ00232545
Fujitsu Fujitsu Services/Post Office Ltd Interface Ref: CS/PRD/058
Services Agreement for Operational Business Change - ‘Version: 12.0
Reference Data
COMMERCIAL IN CONFIDENCE Date: 24 August 2005
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.
© 2005 Fujitsu Services COMMERCIAL IN CONFIDENCE Page: 53 of 69
FUJ00232545
FUJ00232545
Fujitsu Fujitsu Services/Post Office Ltd Interface Ref: CS/PRD/058
Services Agreement for Operational Business Change - ‘Version: 12.0
Reference Data
COMMERCIAL IN CONFIDENCE Date: 24 August 2005
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)
© 2005 Fujitsu Services COMMERCIAL IN CONFIDENCE Page: 54 of 69
FUJ00232545
FUJ00232545
Fujitsu Fujitsu Services/Post Office Ltd Interface Ref: CS/PRD/058
Services Agreement for Operational Business Change - ‘Version: 12.0
Reference Data
COMMERCIAL IN CONFIDENCE Date: 24 August 2005
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.
© 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.
© 2005 Fujitsu Services COMMERCIAL IN CONFIDENCE Page: 55 of 69
FUJ00232545
FUJ00232545
Fujitsu Fujitsu Services/Post Office Ltd Interface Ref: CS/PRD/058
Services Agreement for Operational Business Change - ‘Version: 12.0
Reference Data
COMMERCIAL IN CONFIDENCE Date: 24 August 2005
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 PinICL system used internally by Fujitsu Services Ltd.
As some PinICL’s relate to work required by Post Office Ltd it is necessary for Post Office
Ltd to have visibility of PinICL data. Details of the passing of information between Fujitsu
Services and Post Office Ltd are shown in Appendix E — PinlCL 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.
¢ Invoices will be raised and paid in accordance with the Agreement.
© 2005 Fujitsu Services COMMERCIAL IN CONFIDENCE Page: 56 of 69
FUJ00232545
FUJ00232545
Fujitsu Fujitsu Services/Post Office Ltd Interface Ref: CS/PRD/058
Services Agreement for Operational Business Change - ‘Version: 12.0
Reference Data
COMMERCIAL IN CONFIDENCE Date: 24 August 2005
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/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]
© 2005 Fujitsu Services COMMERCIAL IN CONFIDENCE Page: 57 of 69
FUJ00232545
FUJ00232545
Fujitsu Fujitsu Services/Post Office Ltd Interface Ref: CS/PRD/058
Services Agreement for Operational Business Change - ‘Version: 12.0
Reference Data
COMMERCIAL IN CONFIDENCE Date: 24 August 2005
11.1.3
11.1.4
1L.1.5
11.1.6
Advanced Simple
Non core product becomes core
Change use of additional fields
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
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
Change Best Fit screens
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
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
by 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.
© 2005 Fujitsu Services COMMERCIAL IN CONFIDENCE Page: 58 of 69
FUJ00232545
FUJ00232545
Fujitsu Fujitsu Services/Post Office Ltd Interface Ref: CS/PRD/058
Services Agreement for Operational Business Change - ‘Version: 12.0
Reference Data
COMMERCIAL IN CONFIDENCE Date: 24 August 2005
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 ITN 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
Surther consideration.
Please note that Network Banking Contract Schedule NO1 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 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.
© 2005 Fujitsu Services COMMERCIAL IN CONFIDENCE Page: 59 of 69
FUJ00232545
FUJ00232545
Fujitsu Fujitsu Services/Post Office Ltd Interface Ref: CS/PRD/058
Services Agreement for Operational Business Change - ‘Version: 12.0
Reference Data
COMMERCIAL IN CONFIDENCE Date: 24 August 2005
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)
¢ 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 Cash Account reprint be requested — is there any value stock being held at
branches which will no longer be linked)
e Ifyes 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 cash account reprints and stock. If a branch requests a reprint which
includes items which have now gone from their counters and yet have been transacted within
© 2005 Fujitsu Services COMMERCIAL IN CONFIDENCE Page: 60 of 69
FUJ00232545
FUJ00232545
Fujitsu Fujitsu Services/Post Office Ltd Interface Ref: CS/PRD/058
Services Agreement for Operational Business Change - ‘Version: 12.0
Reference Data
COMMERCIAL IN CONFIDENCE Date: 24 August 2005
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 Cash Account 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 Cash Account. 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 Cash Account 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.
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.
© 2005 Fujitsu Services COMMERCIAL IN CONFIDENCE Page: 61 of 69
FUJ00232545
FUJ00232545
Fujitsu Fujitsu Services/Post Office Ltd Interface Ref: CS/PRD/058
Services Agreement for Operational Business Change - ‘Version: 12.0
Reference Data
COMMERCIAL IN CONFIDENCE Date: 24 August 2005
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
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, i.e. excluding those which were processed in the immediately preceding
month.
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.
© 2005 Fujitsu Services COMMERCIAL IN CONFIDENCE Page: 62 of 69
FUJ00232545
FUJ00232545
Fujitsu Fujitsu Services/Post Office Ltd Interface Ref: CS/PRD/058
Services Agreement for Operational Business Change - ‘Version: 12.0
Reference Data
COMMERCIAL IN CONFIDENCE Date: 24 August 2005
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 PinICL 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
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.
© 2005 Fujitsu Services COMMERCIAL IN CONFIDENCE Page: 63 of 69
FUJ00232545
FUJ00232545
Fujitsu Fujitsu Services/Post Office Ltd Interface Ref: CS/PRD/058
Services Agreement for Operational Business Change - ‘Version: 12.0
Reference Data
COMMERCIAL IN CONFIDENCE Date: 24 August 2005
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 OBCRDST
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 I 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.
© 2005 Fujitsu Services COMMERCIAL IN CONFIDENCE Page: 64 of 69
FUJ00232545
FUJ00232545
Fujitsu Fujitsu Services/Post Office Ltd Interface Ref: CS/PRD/058
Services Agreement for Operational Business Change - ‘Version: 12.0
Reference Data
COMMERCIAL IN CONFIDENCE Date: 24 August 2005
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
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)
© 2005 Fujitsu Services COMMERCIAL IN CONFIDENCE Page: 65 of 69
FUJ00232545
FUJ00232545
Fujitsu Fujitsu Services/Post Office Ltd Interface Ref: CS/PRD/058
Services Agreement for Operational Business Change - ‘Version: 12.0
Reference Data
COMMERCIAL IN CONFIDENCE Date: 24 August 2005
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:
e Changes (other than tariff) which can be made by Post Office Ltd OBCRDST
amending Reference Data within Design Studio — High Risk
© Changes (other then tariff) which can be made by Post Office Ltd OBCRDST
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. 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.
© 2005 Fujitsu Services COMMERCIAL IN CONFIDENCE Page: 66 of 69
FUJ00232545
FUJ00232545
Fujitsu Fujitsu Services/Post Office Ltd Interface Ref: CS/PRD/058
Services Agreement for Operational Business Change - ‘Version: 12.0
Reference Data
COMMERCIAL IN CONFIDENCE Date: 24 August 2005
15 Appendix E - PinICL control between Fujitsu Services
and Post Office Ltd
Please note that the PinICL system has been replaced by an updated system called Peak
however the two names are currently being used interchangeably.
This section describes the agreed mechanisms for passing PinICL’s from the Fujitsu Services
PinICL system to Post Office Ltd and entering responses from Post Office Ltd into the PinICL
system. The passing of data between the organisations is necessary because Post Office Ltd
do not have direct access to the PinICL system.
The interface for all PinICL’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 PinICL’s which need to go to Post Office Ltd will be routed (PinICL term) to the RDT
team for onward transmission (in practice the largest number of PinICL’s destined for Post
Office Ltd are raised by RDT).
When RDT receive a PinICL to be sent onwards the PinICL is routed to the appropriate Post
Office Ltd team. In PinICL 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 PinICL names will not be changed as they are for routing
purposes only.
Once the PinICL has been routed within the PinICL system itself RDT will create an e-mail
and copy in the contents of the PinICL on to the e-mail. The subject line in the e-mail must
contain the word ‘PinICL’ and the number of the PinICL for ease of recognition.
On a periodic basis (at least monthly) RDT will provide a listing of outstanding PinICL’s to all
interested parties. RDORF monitors PinICL trends and PinICL’s outstanding to ensure that
issues are addressed in a timely fashion.
Post Office Ltd must always explicitly respond to the PinICL and not rely on the delivery of
any data to be the notification of an update to the PinICL.
When RDT receive the explicit response, the PinICL will be updated, in most cases by copying
the data in the e-mail into the PinICL system. If the response indicates that no further action
will be undertaken by Post Office Ltd the PinICL will be routed to the originating team. RDT
will advise the originator of the response that the PinICL has been removed from the POCL
stack.
© 2005 Fujitsu Services COMMERCIAL IN CONFIDENCE Page: 67 of 69
FUJ00232545
FUJ00232545
Fujitsu Fujitsu Services/Post Office Ltd Interface Ref: CS/PRD/058
Services Agreement for Operational Business Change - ‘Version: 12.0
Reference Data
COMMERCIAL IN CONFIDENCE Date: 24 August 2005
Under some circumstances a PinICL 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 PinICL, route
it to the relevant Post Office Ltd team and immediately route it back to RDT and, in most
cases, close the PinICL. A copy of the PinICL will be sent to the relevant team in Post Office
Ltd
© 2005 Fujitsu Services COMMERCIAL IN CONFIDENCE Page: 68 of 69