FUJ00098169
FUJ00098169
Fre)
FUJITSU
THE POSSIBILITIES ARE INFINITE
Fujitsu Services input to Feasibility
Study
For
End to End re-Architecting of Post
Office Systems
24 March 2003
(With Pricing)
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
Table of Contents
1 MANAGEMENT SUMMARY...
1.1 POST OFFICE REQUIREMENTS
1.2 FUJITSU SERVICES RESPONS
1.2.1 Target Architecture
1.2.2 Migration steps ..
1.3. COMMERCIAL APPROACH
1.3.1 Lifecycle proces:
1.3.2 System Integration
1.3.3. Application Development
1.3.4. Support and Maintenance
13.5 Pricing.....
1.4. KEY DECISIONS NE)
1.5 SUMMARY...
THE TARGET ARCHITECTURE.
2.1 KEY CONCEPTS AND PRINCIPLES.
2.2 TARGET APPLICATION ARCH. STU!
2.3. TARGET SYSTEMS/APPLICATION MANAGEMENT ARCHITECTURE.
2.4 TARGET PHYSICAL ARCHITECTURE
2.5 STRUCTURE OF SYSTEMS, SERVICES AND THEIR SOURCING
Stability of interfaces
Tight coupling of data models
Reconciliation, Audit
SLAs...
Support considerations.
26 SERVICE OPERATIONS AND SUPPORT ..
3. TRANSFORMATION PROJECTS...
3.1 BASELINE ASSUMPTION ..
3.2 PROJECTS
Project I - Better Overnight Cash on Hand Data
Project 2 - Automated Ledgering for Cash / Bank.
Project 3 - Automatic Cash remittance of pouches into branches
Project 4 - Branch Liability Management.
Project 5 - Client Settlement and Ledgering
Project 6 - Improved Cash / Stock Management
Project 7 - Automated Ledgering for Stock ..
Project 8 - Personal Agents Ledgers...
Project 9 - Simplified & Improved Transaction Processin
Project 10 - Reference Data Improvements
Project 12 - Management Information (local/central)
Project 13 - Cross Selling
Project 14 - HTML Hel,
Project 15 - Printing of Virtual Stocl
Project 16 - Local Destruction of Stock.
Project 17 - Debt Recovery Case Management
3.2.17 Project 18 - Ref Data Process Improvements ..
3.3, OVERALL SOLUTION CONSIDERATIONS ACROSS PROM
nN
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 2
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
3.3.1 Financial System Overview...
3.3.2. Approach to Satisfying Non-Functional Requirements .
4 MIGRATION ACTIVITIES...
4.1 MIGRATION PRINCIPLES
4.2 PROJECT DEPENDENCIE
4.3. MIGRATION PHASING
4.4 BUSINESS PROCESS ANALYSIS AND DESIGN
4.5 DESIGN PROPOSALS
4.6 BUSINESS CASE REVIE
4.7 ROADMAP PLAN
4.8 DEPENDENCIES ON POST OFFIC]
5 PRICING ASSUMPTIONS FOR TRANSFORMATION PROJECTS...
5.1 PRINCIPAL ASSUMPTIONS,
5.1.1 Financial System Assumption:
5.2 BUSINESS PROCESS ANALYSIS & PROGRAMME MANAG!
5.2.1 Business Process Analysis & Design
2 Programme Management.
5.3 E2E RELEASE I — PROJECTS 1,2, AND 3.
5.3.1 Project 1 - Better Overnight Cash on Hand Data Assumptions
5.3.2 Project 2 - Automated Ledgering for Cash / Bank assumptions .
5.3.3. Project 3 - Automatic Cash remittance of pouches into branches Assumptions.
5.4 E2ERI — PRC 8 4, 5,6 AND 7..
5.4.1 Project 4 - Branch Liability Management Assumptions
5 Project 5 - Client Settlement and Ledgering Assumptions
5 Project 6 - Improved Cash / Stock Management assumption:
5.4.4 Project 7 - Automated Ledgering for Stock Assumptions
5.5 E2E RELEASE 3 — PROJECTS 8, 9 AND 17
5.5.1 Project 8 - Personal Agent Ledgers Assumptions
5.5.2 Project 9 - Simplified & Improved Transaction Processing assumptions
5.5.3 Project 17 - Debt Recovery Case Management
5.6 E2E— RELEASE INDEPENDENT PROJECTS ..
Project 10 - Reference Data Improvements (IT Solution)
Project 12 - Management Information (local/central)
Project 13 - Cross Selling
Project 14 - HTML Hel
Project 15 - Printing of Virtual Stock
Project 16 - Local Destruction of Stock
Project 18 - Reference Data Process Improvements
6 VARIATION OF FUJITSU SERVICES HORIZON FEES AND CHARGES.......82
6.1 SICOMMITMENT FEE AND ADDITIONAL SYSTEMS INTEGRATION CHARGES
6.2. END-TO-END.
6.3. CHANGES TO REQUIREME
6.4 OPERATIONAL CHARG
7 PROPOSED COMMERCIAL ARRANGEMENTS
7.1 LIFECYCLE PROCESS .
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 3
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
7.2 SYSTEM INTEGRATION...
7.3 APPLICATION DEVELOPMENT .
7.4 SUPPORT AND MAINTENANCE.
7.5 OPERATIONS ......
7.6 SERVICE BOUNDARIE
8 POSSIBLE ALTERNATIVE PROJECTS.
8.1 FINANCIAL SYSTEM HARDWARE OPTION.
8.2. UsE oF SAP/ BW AS AN ALTERNATIVE FOR MIS
8.2.1 Reporting from SAP BW
8.2.2 Background..
8.3. CENTRAL STOCK MANAGEMENT (VALUE STOCKS). i
8.3.2. Assumptions: 90
This costing assumes Swindon Warehouse only - not Hemel as this is assumed to be in the RMG domain. 90
9 SIZING ASSUMPTIONS FOR SAP R/3. 90
10 FUJITSU CAPABILITY...
11 COSTS AND BENEFITS
11.1 I BUSINESS PROCESS ANALYSIS & PROGRAMME MANAGEMENT
11.1.1 Business Process Analysis & Design
11.1.2 Programme Management
11.2 E2E RELEASE I — PROJE
11.2.1 E2E Release I Costs.....
11.2.2 E2E Release 1 Benefit analysis
11.3. E2E RELEASE 2—PROJECTS 4, 5, 6 AND 7.
11.3.1 E2E Release 2 Costs...
11.3.2. E2E Release 2 Benefit analysis
11.4 E2E RELEASE 3— PROJECTS 8, 9 AND 17
11.4.1 E2E Release 3 Costs...
11.4.2. E2E Release 3 Benefit analysis
11.5 II E2E— RELEASE INDEPEND! PROJEC
11.5.1 Project 10 - Reference Data Improvements (IT Solution)
11.5.2 Project 12 - Management Information (local/central
11.53 Project 13 - Cross Selling
11.5.4 Project 14 - HTML Help.
11.5.5 Project 15 - Printing of Virtual Stock
11.5.6 Project 16 - Local Destruction of Stocl
11.5.7 Project 18 - Reference Data Process Improvements
11.6 Cost SUMMARY ....
11.7. Cost BENEFIT SUMMARY we
11.8 I OpTION— SAP FINANCIAL & STOCK MANAGEMENT SYSTEM HARDWARI
11.8.1 Costs
81,2, AND3
11.9 Option—SAP/ BW ALTERNATIVE TO MIS 04
11.9.1 Costs 104
11.10 OPTION — CENTRAL STOCK MANAGEME} 05
11.10.1 Costs...
12 GLOSSARY OF TERMS
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 4
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
Accuracy: Fujitsu Services endeavours to ensure that the information contained in this
document is correct but, whilst every effort is made to ensure the accuracy of such
information, it accepts no liability for any loss (however caused) sustained as a result of
any error or omission in the same.
Prices: Fujitsu Services reserves the right to vary these prices dependent on further
analysis and impacts, in the event that Fujitsu Services undertakes this work under a
contract with Post Office.
Copyright: © Fujitsu Services Limited 2003. All rights reserved. No part of this
document may be reproduced, stored or transmitted in any form without the prior
written permission of Fujitsu Services.
™ indicates registered trademark.
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 5
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
1 Management Summary
Post Office is experiencing a major change in its operating and commercial
environment. It must transform its cost base, processes and behaviours to meet the
challenge.
Embracing the Joint IS Landscape arrangements from the extended Horizon agreement,
Fujitsu Services has been working with Post Office analysing where cost benefits could
be realized through re-architecting the current estate of Post Office systems and through
adoption of new business processes.
This document sets out a blueprint for a programme of migration to a coherent system
set which will deliver the target process improvements as quickly as possible and at
least risk. It takes account of where natural process boundaries exist to define the
logical demarcation lines between Fujitsu Services and the Prism consortium. It
contains proposals to deal with the taking of contractual responsibility for delivery and
operations but also considers how work might be shared in a controlled fashion among
the various parties.
Fujitsu Services is pleased to submit this document, developed as an input to the Post
Office E2E feasibility study and looks forward to continued joint working in the
development of effective systems to support the Post Office business. All pricing and
timescales assume this approach.
This paper sets out Fujitsu Services approach to the systems re-architecture, explains
the design aims, outlines indicative pricing and offers a proposed implementation plan.
1.1 Post Office requirements
The analysis of the requirements has been conducted as a joint activity with Post Office
IT Directorate, Business Systems and, critically, Post Office business departments.
Business representatives contributed significantly through workshops and meetings
with analysts and through validation and verification of findings. For the feasibility
study, the focus has been on understanding the key business issues and associated costs
and benefits and documenting at a high level the affected business processes. This will
serve as a solid basis for subsequent analyses of the detailed requirements. The Post
Office requirements that were captured during the End-to-End Feasibility Study are
documented in the Business Requirement Specification dated 21" February 2003. The
Business Requirement Specification document provides the requirement baseline
against which this paper has been prepared.
Post Office and Fujitsu Services have identified the following as the key areas of
potential savings and operational improvements:
a Stock Management (£1.9m - £2.2m annual saving identified)
o Reductions in stock handling and transportation costs
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 6
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
o Reductions in stock write-offs
o Automation of form production and reductions in form printing
a Accounting (£9.5m annual saving)
o Reductions in product matching
o Decrease in debt (lower write-offs)
o Improvements in client settlement
o Elimination of various legacy systems (esp. CBDB and OPTIP)
a Cash Management (£4m annual saving)
o Automation of order processing in cash centres
o Decrease in cash centre write-offs
o Lower borrowing costs
o Improved cash flow
a Sales (£2.5m - £5.5m annual saving)
o Improvements in customer session support (Method of Payment)
o Support for product-related cross-selling
o Printing of (virtual) stock
o Improved conformance to process through prompts and the introduction
of HTML help facilities
Q Management Information (£2m - £5m annual saving)
o Availability of performance information
o Incentivisation based on product profitability and basket analysis
o Elimination of legacy MI systems
a Reference Data management (£1.2m annual saving)
o Improved reference data management processes
o Elimination/replacement of legacy reference data systems
The potential to realise the annual savings of at least £21m has been confirmed by Post
Office stakeholders from the affected business areas.
It should be pointed out that £21m p.a. represents the low side of the savings
opportunity. Neither has any estimate been made of revenue upside opportunities as
these were outside the scope of this work piece.
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 7
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
1.2 Fujitsu Services Response
This paper is Fujitsu Service’s response to the above requirements. The principles
embodied in this proposal are:
= Transformation of the current systems landscape is to be based on a series of
projects, each delivering business benefits in it own right, as well as contributing
towards the realization of the strategic systems organisation, i.e. a very different
approach from the ‘big bang’ ERA proposed implementation;
= The projects covered by this paper are those agreed with Post Office (IT Directorate
and Business Systems);
= Fujitsu Services is willing to discuss with Post Office a prime contract arrangement
where management of the overall programme is undertaken by Fujitsu Services.
This approach will reduce the overall programme risk and ensure single company
responsibility. This is not costed into the estimates given;
= Fujitsu Services is keen to work with Post Office to identify sub-contractors who
may have specific skills and experience that would position them well to undertake
some of the development work;
= We have assumed that maximum use will be made of pre-paid SI for these projects.
While we have estimated its use in our indicative pricing, the actual call on pre-paid
SI must be made by Post Office;
= The proposed solution approach minimises costs and risks to Post Office by
adopting optimum service boundaries and an incremental, step by step, approach to
development which moves the business progressively towards Post Office IT
Directorate’s strategic architecture;
= The sequencing of projects is devised to deliver early benefits to support the Post
Office objective of early return to profitability. We are however proposing an urgent
start to the design work to maintain the proposed schedule;
= We have assessed in this paper how the proposed approach releases the cost savings
identified in Schedule 10 of the new agreement;
= The proposed commercial arrangements aim to create the simplest possible
structure within which change can be managed without undue contractual
overheads.
1.2.1 Target Architecture
The proposed transformation programme aims to develop the Post Office systems
towards an end position as depicted in the diagram below.
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 8
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU aren ae
Figure 1 — Target Application Architecture
The key changes from the current position are:
= A new Financials System maintaining all the required ledgers and providing more
up-to-date information on the business. It will support Debt Recovery and client
settlement. This system will replace the CBDB complex (Pivot, Class, various add-
on systems);
= Enhanced Management Information facilities, providing a range of management
reports and support for ad-hoc queries not available from the standard financial
reports (The MIS, together with the Financial System, will replace a range of
existing reporting systems and tools);
= Enhanced Horizon Transaction Management System, encompassing client file
transfer and reconciliation, transaction level enquiries and integrating the data flows
between Counters, Financial and the Sales MI Systems. This will replace the OpTip,
TPS and AP systems and be a development of the Network Banking DRS system;
= Enhanced SAP ADS (delivered by Business Systems), better integrated with the
Logistics Feeder Service, which will facilitate more accurate and immediate cash
reporting;
= New Inventory Management improving control over stock holdings;
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 9
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
Fujitsu Services does not propose to manage all these systems. The scope of its
proposals for the enhanced Horizon technical infrastructure, and the logic for that
scope, are described in this document.
1.2.2 Migration steps
A set of transformation projects was identified during the requirements analysis stage,
which together can result in the target systems being established. A few of the projects
need to be executed in a specific order because of interdependencies, but otherwise it is
possible to compose different migration scenarios addressing target areas serially or in
parallel as needs and investment capability demand.
a Accounting & Cash Management Programme
o Cash Ledger (3 projects)
o Branch, Client & Stock ledgers.
o Completion of Financials & decommissioning of legacy systems
o Reference Data infrastructure & processes
a Stand-alone projects
o Automated cash ordering
o Stock inventory management
o Automated stock ordering
o MI- Sales incentivisation
o Cross selling
o (HTML) Help
o Printing Virtual stock
© Local destruction of stock
The identified business benefits have been attributed to the individual projects allowing
Post Office to make informed decisions on prioritisation — this information is presented
in the financial summary.
1.2.2.1 Proposed Migration Approach
The proposed programme recognizes that the urgency for introduction of new or
improved processes and systems must be tempered by availability of investment
funding and the ability of the affected units to adapt to introduced changes. The
programme has been structured to deliver early business benefits to fund the later
investments.
A key outcome of the transformation programme is the establishment of a modern
financial system that delivers accounting information in a timely and accurate manner.
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 10
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
The new Financial System represents a major investment. To avoid a “big bang”
introduction of the system and all associated processes, Fujitsu Services proposes an
incremental introduction, spreading the costs over several of the transformation projects
and supporting the investment in the system’s development by realised benefits from
the early projects. The early usage of the Financial System will be for timely
Management Information. The proposed approach will result in longer parallel running
of the new Financial System alongside the current CBDB complex of systems, thus de-
risking transition and allowing more time to define and bed-down new business
practices.
The modernisation of, and in some case creation of new, key business processes in Post
Office back-office operations will result in some degree of re-work and tuning, as
experience with the new business and system processes is gained. To minimise the
amount of re-work, it is proposed that Post Office exploits the capabilities of the
Horizon Architecture Lab, the costs of which are covered by the Commercial Terms
already proposed. By prototyping key aspects of the new solution, the Lab will create a
visualisation environment against which users will be able to pin down requirements for
system functionality, information availability and structuring of user interfaces. This
will shorten the analysis phases of projects and de-risk their implementation.
The joint working approach, which forms a key aspect of the renewed Horizon
agreement, has been embraced in the analysis stage preceding this proposal. It has
worked well and achieved good progress and common understanding between Post
Office and Fujitsu Services. The systematic analysis adopted has delivered an overall
map of business processes and a set of requirements positioned within the map. This
business context now needs to be completed and it must be maintained throughout the
forthcoming stages of further and more detailed analysis. To maintain the momentum
and to facilitate early system improvement, the phased completion of requirements and
solution design is needed in order that S60 and Project 5 can progress to plan. This
should tackle both the overall business requirement (especially by completing the areas
of Inventory Management and Sales and Marketing) and begin detailed analysis of
specific transformation opportunities (especially Cash Management and Accounting).
1.3. Commercial approach
This paper is based on the commercial framework of the extended Horizon agreement.
The proposed commercial arrangements exploit the “Working Together” processes and
“Pre-paid SI” resources. However the usage of pre-paid SI is to be decided by Post
Office. The indicative prices in this document are based on the following assumptions:
a It has been assumed that this programme will have first call on Pre-paid
SI that is not already committed. Incremental SI charges will apply
where resources over and above those in Core are required, either
because of skills shortage or peaks in workload. Pre-paid SI does not
cover hardware or sub-contracted resources;
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 11
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
a It has been assumed that maximum use will be made of pre-paid SI and
for this purpose, a broad assumption has been made that 70% of
available pre-paid SI will be used for these projects;
a No discount has been assumed in relation to the additional SI resources,
although forward commitment will qualify Post Office for a 20%
discount subject to the conditions set out in the Amendment;
a Three releases are proposed, so as to smooth the work and minimise the
demand for additional resources while still meeting the target timescales,
although we will need to move at pace in order to achieve the proposed
Release windows;
a Pricing is indicative and is presented on a T&M basis with no
contingency. It would be prudent for Post Office to uplift these figures,
either for its own contingency for T&M or to cover possible variances of
a feasibility stage estimate;
a The operating fees are to cover costs, which are incremental to the
contracted baseline;
a Hardware and SAP software costs are excluded on the basis that Post
Office may already have spare capacity, which could be applied to the
identified requirements;
a These and other assumptions and dependencies are set out in this
document;
a Other new business initiatives will share Release testing costs therefore a
proportion of such costs have been attributed to End to End.
1.3.1 Lifecycle process
It is assumed that the Joint IS Landscape process will be followed and that no
significant resources or timescales will be expended on competing for packages of the
solution.
1.3.2 System Integration
This paper assumes that the Fujitsu Services domain will include the integration of:
Counter systems
Enhanced Horizon Transaction Management systems (covering reconciliation with
clients, on-line transaction processing with clients’ agent systems (NBE,
Streamline, e-Pay), support for Post Office back-office transaction processing)
New Financial System
Enhanced Reference Data Management Centre (RDMC) addressing all reference
data needs of the Fujitsu Services systems domain
Enhanced Horizon Logistics Feeder Service (LFS)
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 12
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
Fujitsu Services will also be responsible for integration with externally provided
systems and services, in particular with:
= Cash Centre systems (SAP ADS) operated by Business Systems
= Centralised file transfer facility (EDG) operated by Business Systems
= Sales Management Information System
= Any new Post Office Reference Data system(s)
1.3.3. Application Development
Fujitsu Services proposes that it will be the Application Developer for:
= Counter applications
= Enhanced Horizon Transaction Management systems
m Enhanced Reference Data Management Centre (RDMC)
= Logistics Feeder Service (LFS)
Fujitsu Services proposes to subcontract the application development of the New
Financial System within its overall E2E design, and would welcome close dialogue
with Post Office on who that subcontractor should be and on agreeing terms with that
subcontractor. The baseline assumption that covers the indicative costs is that the
development will be undertaken by Fujitsu Consulting (Fujitsu Services sister
company) extensively supported by Zenzar (an offshore development company, in
which Fujitsu has a significant stake) and by SAP.
1.3.4 Support and Maintenance
Fujitsu Services will support and maintain all systems within the expanded Horizon
domain (to the left of the dotted line in paragraph 2.2 below), ensuring that appropriate
back-to-back arrangements are in place with any supplier/subcontractor.
1.3.5 Pricing
The indicative costs provided in this document by Fujitsu Services assume T&M. No
contingencies have been incorporated and the profile of costs over time is aligned with
anticipated expenditure timing.
Fujitsu Services will be pleased to discuss with Post Office possibilities of a fixed price
contract or a form of benefit sharing. Such discussions may be appropriate once the
requirements analyses for the Transformation Projects have been completed.
In summary, to release £16.9M of annual savings, we are estimating an investment of
£16.7M one off with a recurring charge of £1.3M to cover running costs and software
support.
© 2003 Fujitsu Services Lid Commercial in Confidence Page: 13
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
Of these figures, £4.9M is estimated as the cost of the new financial system while
£11.8M is estimated as the cost of Horizon related development. We have roughly
estimated the use of pre-paid SI as some £7.1M of the Horizon related work.
Specific details of the cost breakdown is provided in Section 11.
1.4 Key Decisions needed
To achieve the required timetable for deployment of the new and improved systems, it
is essential that:
= Analysis and process business design progress is maintained (authority to proceed
with next phase of work is required immediately)
= Analysis of detailed Release 1 requirements needs to complete urgently and design
work needs to commence during April to ensure that development can proceed to
deliver within the S60 Horizon release timeframe
Other timetable considerations are covered within section 4. It is important to note that
delays will result in release windows being missed and consequently will delay the
realisation of the identified business benefits. Delays are also likely to cause some of
the dependencies within the Horizon Agreement not being met in time for the scheduled
SI commitment fee reduction in Spring 2005. Such delays would increase the future
Horizon costs.
1.5 Summary
This paper has come about as a result of excellent joint working between Post Office
and Fujitsu Services representatives. We believe the approach of breaking the overall
project into manageable sub projects will:
a Enable the implementation to be undertaken in a risk reduced way
a Ensure that benefits are delivered early
Fujitsu Services is happy to discuss prime contractor status with Post Office and also
the allocation of specific work pieces to other sub-contractors.
We look forward to early commitment to continue work thus ensuring that the exacting
programme timescales can be achieved and early release of savings happens.
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 14
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
2 The Target Architecture
Having formulated the E2E re-architecting programme as a series of projects, each
addressing particular business needs, it is important, from the design viewpoint, to have
a clear vision of the end solution and thus to avoid purely tactical developments which
can inadvertently result in over complex solutions, high on-going costs and difficulties
in subsequent evolution. This section describes the envisaged strategic systems estate.
2.1 Key Concepts and principles
The key principles underlying the proposed solution architecture are:
= Minimisation of duplicate functions — to reduce production/maintenance costs and
improve potential for change
= Consolidation of related processing — to minimise movements of data, reduce audit
and reconciliation points
= Adoption of commodity platform products — to minimise hardware and associated
support costs and to maximise availability of skilled resources that can be deployed
= Use of packages, where business requirements can be mapped onto generic product
capabilities
= Clean separation of functional areas to retain flexibility to insert major new
capabilities in future, for example Customer Relationship support.
= Clean process boundaries to minimise the difficulties (costs) of business risk
transfer and reconciliation.
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 15
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
2.2 Target Application Architecture
Pictorially, the target organisation of application systems at the end of the currently
envisaged transformation programme is as follows:
=
=
=]
Figure 2 - Target Application Architecture
The key components of the target application architecture are:
Post Office Financials — a system managing a set of ledgers representing the full Post
Office trading position. The ledgers will include accounting for branch transactions by
client, and account for cash and stock. The Financial System will be fed by transaction
summaries generated within the "up-stream" parts of the Horizon infrastructure. This
system will also provide the necessary facilities to support client settlement and debt
management and provide an auditable set of accounts.
Debt Recovery Case Management — will be a facility provided to support Debt
Recovery staff in managing the resolution of branch and client discrepancies. The
system will provide facilities for tracking progress in resolution of individual cases
(whether these result in write-offs or demands for settlement). It will be implemented as
a module of the PO Financials.
Transaction Management — this system will provide transaction-level enquiry
capability as well as reconciliation of transactional-level data from Post Office branches
against Client supplied files. The system will provide facilities to investigate
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 16
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
transactional discrepancies and unusual trading patterns identified by Rota checks/MIS
reports and will also support customer/client enquiry handling. Although the initial
implementation covers Client interactions as either Horizon-initiated on-line requests or
file exchanges, it is envisaged that more sophisticated access could be provided to the
information managed by Transaction Management to Clients. For example, an Enquiry
Portal could be implemented.
Adjustment Notification — this component within the Transaction Management system
will propagate from the central operations instructions (or proposals) for
adjustments/write-offs that Sub-Post Masters are requested to apply to their Branch
Liability Statements via counter terminals.
Logistics Feeder Service (LFS) — will be enhanced and integrated with SAP ADS.
Management Information System (MIS) — is assumed to be an evolution of the
existing Sales MI system. (An option for exploitation of SAP BW may be feasible, (see
section 8) however our current understanding of the reporting requirements would
require a system of very significant capacity. Clarification of the assumptions may
make this option appropriate and economic.)
SAP ADS - will be enhanced to integrate with LFS and ultimately to provide PO
Financials with direct feeds.
2.3 Target Systems/Application Management Architecture
The business applications will exist in a support environment comprising numerous
services as described below. To minimise cost of E2E re-architecting, the already-
extensive support functionality of Horizon will be re-used wherever possible.
System management - The existing Horizon System Management regime provides
event management, software distribution and inventory management. These established
services will be extended to the new systems introduced as part of end-to-end re-
engineering.
Back-up and restore - The Maestro based back-up and restore regime already in place
within Horizon data centres will be enhanced to provided tape based back-ups of new
systems. Back-up will exploit the existing investment in Horizon robotic tape silo.
Archiving and Audit -The existing Horizon audit services, enhanced with Centera
storage as part of the Network Banking programme, will provide archive and audit
services for the new data centre services, thus minimising hardware and software
investments and exploiting existing support procedures.
Security - While new services are not expected to require the same stringent level of
security that is provided within the existing Horizon environment they will benefit from
many aspects of the existing regime, including user management, audit and archive
management, role based authentication and access control, secure network
infrastructure and physical site security.
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 17
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
Reference Data management - The existing unified reference data management
service provided by RDMC and RDDS will be extended to the new systems within the
Horizon domain ensuring that all reference information has a single point of definition
while being consistent across all systems.
Capacity Management - Horizon capacity management service will be enhanced to
track the capacity requirements of all new Horizon systems.
Help Desk - The Horizon help desk (HSH) will provide support for all new systems
within the Horizon domain. The provision of 3" and 4" line support will be as
documented for the relevant services in the existing Horizon contract
File Transmission - Where the new systems require the transmission of files to
systems beyond the Horizon domain, this will be performed via the existing FTMS
service, and where possible exploiting the capabilities of the Royal Mail Group’s EDG
system.
Figure 3 - Target Systems/Application Management Architecture
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 18
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
2.4 Target Physical Architecture
This paper is based on introduction of powerful commodity server platforms to support
the new application functionality. In particular, the Transaction Processing and
Financial Systems will be implemented on Solaris platforms to take full advantage of
competitive prices of hardware and associated services.
= I
all
Figure 4 — Target Physical Architecture
The Horizon network and the Post Office network, on which back-office workers will
reside, will be interconnected. For the purposes of this paper, the existing
interconnection has not been upgraded; the capacity of the link will be reviewed when
more detailed requirement is available.
2.5 Structure of systems, services and their sourcing
The target architecture and the evolution towards it strongly suggest where the optimal
contractual boundaries should exist to minimise programme costs, particularly in terms
of change management, reconciliation and audit overheads, management of fragmented
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 19
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU aren ae
SLAs and similar overheads. Additionally, it is essential that there is clear overall
responsibility for integration and service delivery. The diagram below shows the
proposed separation of the application estate into separately contracted domains.
Extended Horizon Domain I Business Systems
Domain
Contragtual Boundary
Figure 5 — Structure of systems and their sourcing
The rationale for the paper encompasses technical, financial and management benefits,
specifically:
2.5.1 Stability of interfaces
The evolutionary nature of the transformation programme means that for several
interfaces between systems only partial specifications will be available at any one time.
If a contractual boundary were to run through such interfaces, the consequences of the
interface evolving over time will include:
= Need to keep aligning both suppliers’ systems and hence Contract changes (with
financial implications)
= Need to align both suppliers’ delivery plans
= More complex test plans and arrangements
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 20
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
The E2E transformation programme, as comprehended from our work with Post Office,
will introduce or affect several inter-system interfaces and systems behind them. Those
which will be developed quickly and remain stable thereafter are:
a ES-FS
a SAPHR
= EDG
= SAP ADS
and therefore can be integrated across a contractual boundary without undue future
problems/costs.
However, the following interfaces will keep evolving during the E2E programme, as
will the functionality of systems at both sides:
= Transaction Management to Post Office Financials
= Counters to Transaction Management
and therefore should remain within the same contract domain.
2.5.2 Tight coupling of data models
The various systems within the overall estate implement overlapping data models.
Where the evolution of the systems alters the models it will be important that these are
maintained in step across cooperating systems. The implications of this are the same as
for interfaces in the section above. The systems where such close affinity exists are:
= Horizon counters
= Transaction Management
= Post Office Financials
= MIS
And hence these systems should be managed within a single domain of control.
The pricing included in this paper assumes that the new Post Office Financials will be
implemented within the Fujitsu Services domain but that Sales MIS is retained within
Post Office (notwithstanding the arguments in favour of transferring it across).
2.5.3 Reconciliation, Audit
Within its contracts with suppliers, Post Office will transfer various obligations and
liabilities onto the suppliers, who in turn will ensure that their solutions contain
appropriate provisions for tracking their achievement (or otherwise) of the obligations
and providing sufficient information to determine where they are not liable for
deleterious events that may affect Post Office business. All these provisions are, of
course, part of the overheads of any solution. Where inappropriate boundaries are
established, the amount of information that needs to be collected and retained can be
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 21
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
very considerable and in general, there will be significant duplication of data and
functionality.
Within the proposed architecture, the ideal inter-system (contractual) boundaries are
those that coexist with natural organisational boundaries and hence those where the
“protection” mechanisms (audit, reconciliation, security firewalls etc) need to reside
anyway. In particular, the natural boundaries are:
= Between Post Office and 3“ parties (i.e. client interfaces, NBE interface, external
service providers such as e-Pay, Streamline)
= Between Post Office and Royal Mail Group
= Between Post Office units operating as (potentially) separate entities e.g. Branch
network and Cash Centres or Stock Warehouses (which could potentially be out-
sourced/sold or replaced by 3“ party suppliers)
The above reasons suggest that the following systems are logically the most separable
from Horizon:
m SAP ADS and other warehousing systems
= SAPHR
= ES-FS
2.5.4 SLAs
In general, business objectives and business outcomes are measured in terms of results
at the end of business process strands. The most effective Service Levels are expressed
in terms directly related to business objectives. However, where suppliers contribute
only partially to the achievement of business outcomes, it is necessary to devise indirect
measures. The more fragmented the service provision, the harder it is to devise a set of
meaningful SLAs that have a direct bearing onto business performance.
2.5.5 Support considerations
An integrated approach to supporting the deployed IS/IT services is required. It is
essential that the responsibility for resolution of any problem is clearly identifiable and
that a single party is managing the delivery of the solution to a particular problem
within required time constraints.
2.6 Service operations and support
The target architecture introduces new systems and services, which need to be
managed, operated and supported. The following arrangements, above those already
covered by the Horizon agreement, are proposed:
= New Financial System — to be deployed within the manned Horizon Data Centre
and operated alongside the other Horizon central systems. The co-location of the
systems will allow consolidation of audit, archiving and back-up facilities and
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 22
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
services as well as maintaining close proximity of the Financial System to its main
(volume) source of data (i.e. the Transaction Management System). The integration
within expanded Horizon enables Fujitsu Services to take responsibility for the
complete transaction processing activity culminating in the ledger outputs, without
the need for mid-process reconciliation.
= Management Information System — it is proposed, but not assumed, that Sales MIS
will be transferred to the manned Horizon Data Centre where it will be operated and
maintained. The rationale for this move is as for the Financial System with respect
to operational synergies.
The Horizon Support Desk will field all second line support for Financial and MI
Systems.
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 23
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
3 Transformation Projects
3.1 Baseline Assumption
The transformation projects, which collectively represent the End-to-End re-
architecting programme and which are described below, are expected to be carried out
from a baseline position, comprising the existing Horizon technical infrastructure and
services amended by the following changes/developments which have been assumed to
be committed as part of other programmes:
= Exploitation of EDG for client file deliveries
= AP enhancements implemented to insert additional transaction data at the counter
(i.e. avoiding central data entry into transaction stream)
= Migration of Horizon central processing from Dynix to Solaris
= Mails 3.3
3.2 Projects
The individual Transformation Projects are described in the following subsections and
for each, the application architecture diagram illustrates, by shading, which components
of the overall architecture are affected by the project being described.
3.2.1 Project 1 - Better Overnight Cash on Hand Data
Within the Cash Management
function two — fundamental
changes have made Post Offices Maoagsnest
Information
funding position a critical
business survival issue:
Managenest
(SAP/ADS)
= The business is trading at a
loss
= The migration of benefit
payments from order books
to ACT will be accompanied
Stock
by the loss of pre-funding by i
government departments of beaded
the necessary cash in the ewe
network
The business will have to borrow funds to fund any trading losses and working capital
needed in branches. Such borrowing is limited in availability and its costs reduce
profitability. From April 2003 the DTI will provide a loan and will require a robust
statement of cash holding as security.
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 24
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
To support the business in managing through this difficult situation, the business
requirements, detailed below, will be addressed by this project:
= To be able to accurately identify physical cash at the branch rather than overall cash
which can include cash equivalents such as cheques.
= Improve management information, linked to financial statements, to support the
management of cash
= Drive down cash holdings and therefore reduce the DTI borrowing requirement,
which in turn will reduce the level of interest paid.
= To be able to forecast and manage cash-flow within the DTI target (£330m for
2002/03)
The first project being proposed addresses the above funds-related requirements by
providing summaries of values by different methods of payments, and in particular by
maintaining a central “Funds Ledger” showing the daily funding position for the whole
of Post Office.
It is proposed that a skeleton “Financial System” be introduced (which will evolve to
the full Financial System with subsequent projects) to implement the Funds Ledgers.
Initially, only Method of Payment movements will be posted to the Financial System,
namely, details of any funds Remitted-in or Remitted-out of each branch, together with
the net change in the branch’s funding position, as a result of the transactions that have
been carried out with customers. This will facilitate tracking of the overall funding
position of each branch and for the totality of branches.
To establish the total consolidated cash position, Cash Handling Centres will be treated
as pseudo-branches. Movements of cash between Banks and the Cash Centres and
movements of Cash to and from Branches will together provide the overall Cash
Position for the organisation. Of this total, the amounts assigned to the care of
postmaster agents, the amounts held on Post Office premises and cash in transit will all
be clearly identified.
The following issues need to be addressed to improve accuracy of funding visibility:
= Eliminate the inaccurate use of “Fast Cash” at settlement when the method of
payment is not actually cash
Our understanding is that some SPMs use Fast Cash when they have actually received a
cheque, and subsequently “convert the cash into a cheque”. Work is required to
investigate the frequency of this: it is proposed that this type of transaction is flagged as
being of interest to Verification.
= Effect of less than 100% polling of branches each day
The current requirement is to successfully poll 97% of branches each day, and normally
achievement is significantly higher. There are two options for dealing with non-polled
outlets:
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 25
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
co Accept latest balances available from when the outlet was last polled (as a result
the overall position should be no more than 1% inaccurate, but this percentage
could rise if some major event caused a high non-polled situation)
co Develop functionality that identifies non-polling outlets and provides estimates
based on historical and/or partial data (this requires retention and use of
appropriate historic data and could prove costly).
The first option is assumed in the priced solution.
3.2.1.1 Outline Solution Design
The following provides an overview of the design:
= The Counter Settlement Process will be enhanced to endorse any cheques used in
Settlement with details of the counter session, thus associating cheques (that are
later remitted to the clearing system) with sessions and allowing identification of
cheques potentially accepted outside of normal counter operation.
m As part of the Branch EOD process, a summary of Fund Movements will be
produced
o This summary will include all Method of Payment “products”.
o Remitting-In and Remitting-Out will be summarised separately from other
transactions. Adjustments will be summarised separately, since they may be of
significance. (They represent cash being swapped for cheques, for example.)
= Such summaries will be harvested to the central Transaction Management System
= The movements will be posted to the Financial System
= The Financial System will be set up to receive the cash movements by branch with
the branches being set up as Profit Centres on SAP
= An outline chart of accounts needs to be determined and details established for the
accounts relating to Funds reporting
m The ES-FS interface requirement and summary chart of accounts used by RMG
needs to be considered so that implementation of this project anticipates future
evolution
= Accounts will be set up in the balance sheet for the various Method of Payment to
capture the cumulative cash position
= As far as possible, Cheque processing process, for which support is to be
implemented in a later project (P2), needs to be anticipated to avoid any later re-
work
Balance Sheet reporting (SAP Financial Statements) will be set up to capture the outline
balance sheet and the detail for accounting for funds
NB Trading Day concept will be implemented with agreed and consistent period end
closing.
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 26
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
3.2.1.2 Sizing and scalability
At the branch, the summarisation work will be done as part of the EOD processing.
Centrally, a Funds Movement Report will be produced from each Branch for each day.
This means that up to 18,000 such summaries will be posted to the Financial System
each day. Existing scalability mechanisms within Horizon will handle this load and the
SAP system has been sized accordingly.
The SAP R/3 system is scaleable, however with the expected volumes, Fujitsu Services
recommends that stress testing should be carried out during the implementation. This
has been assumed in the costs. To ensure that the systems performance is optimal,
Fujitsu Services will exploit the SAP Competence Centre at Fujitsu Siemens Computers
to carry out QA checks on the system before go-live and also, periodically during
operations. In support of the estimates within this document, experience of Fujitsu
Consulting SAP Practice and of SAP has been employed.
3.2.1.3 Security Approach
No special security implications have been identified. The SAP product provides role-
based authentication enabling appropriate business related controls to be defined and
managed in a scalable way. The SAP server will be set up within a DMZ, and
appropriate firewalls and rules bases will be implemented.
3.2.1.4 Resilience requirements
Existing Horizon resilience provisions will continue to deliver dependably the output
files from the current Horizon TPS Host.
See also section 3.3.2.4.
3.2.1.5 Operational requirements
The main requirement here is to deploy the new Financial System, establish Super-users
and continue to operate the service.
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 27
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
3.2.1.6 Expected Deliverables
3.2.1.6.1 New or enhanced functions
Component Description
Counter
Cheque Endorsement
EOD production of MoP Movement Summary
Agent
TPS Harvester to Harvest Summaries
Host
Produce SAP Interface file from TPS Host
Ledgers
Ledger entries in the SAP ‘funds ledger’
Exceptions handling for un-posted BAPIs
Table 1 — Project 1 Functions
3.2.1.6.2_ New or enhanced Interfaces between systems
The interface from the branch to the Data Centre will continue to use the existing
Riposte messaging middleware.
The interface to the Financial System is described in Section 3.3.1. It will be based on
XML summaries from the Transaction Management system fed into SAP using
standard IDOCs and BAPIs. This is a standard way of introducing documents into SAP.
3.2.2 Project 2 - Automated Ledgering for Cash / Bank
Recognising the business
critical nature of the
management of Post
Office’s funding, part of the
previous project (see
Section 3.2.1) was to enable
information on cash onmses - wages
movements to and from the a “Soteton)
Cash Centres to be recorded
Management
Inforaton
Stock
in the new Financial System. ee olancnen
It is anticipated that initially Mazen
posting of Cash Centre t
movements would be done
manually, however as a
second step this project will
provide an interface between SAP ADS and the new Financial System to automate this
flow thus further improving the accuracy and timeliness of cash holding information.
Losities Feeder
service
Furthermore, details of Bank movements will be recorded in the ledgers, thus
maintaining the total position of Post Office’s funds.
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 28
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
The specific business requirements addressed by this project will:
= improve the integration of cash centre holdings into cash-flow management
= bring together all the elements of cash-flow and provide cohesive management to
deliver cash-flow targets.
= deliver a single, comprehensive view of cash (funds) in one place
= improve management information, linked to financial statements, to support the
management of cash (funds)
= enable cash holdings to be driven down and therefore reduce the DTI borrowing
requirement, which in turn will reduce the level of interest paid.
= facilitate forecasting and management of cash-flow within the DTI target (£330m
for 2002/03)
= enable proper accounting of cash when the new Financial System becomes the
corporate ledger system
3.2.2.1 Outline Solution Design
The main focus for this project involves changes to SAP ADS (in the Business
Systems’ domain) with some work involved in developing the Financial System to
utilise the information feed. The procedure for accounting for cheques (as reported
from the cheque handling centres and banks) also needs to be established at this point to
ensure the ledgers reflect the process and to efficiently report the position accurately.
The requirement is for a SAP ADS interface to be defined, which enables the data to be
loaded from a file into the Financial System and for the file to be delivered from SAP
ADS and loaded each evening.
It is assumed that SAP ADS will conform to the same input file format for the Financial
System as that defined in Sections 3.2.1. The Cash Centre is assumed to be treated like
a branch and therefore the flow of information into the Financial System will reflect the
Cash Centre as another branch. The Financial System will be extended to handle the
information coming from SAP ADS.
The interface will effectively produce a journal into the ledgers to account for the cash
movements in the cash centres and also any external sales that occurred in the Cash
Centres.
The information passed to the new Financial System will neither include the detail by
stock keeping unit (SKU) nor by denomination.
This project will also address the bank information flow to the ledgers directly from the
bank. It is assumed that the information is available electronically and that it can be
uploaded directly into the SAP FI bank account, to confirm the cleared cash position at
the bank.
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 29
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU vee cea
3.2.2.2 Sizing and scalability
There will be a single feed per day from SAP ADS to the Financial System, the volume
of data transmitted is assumed to be insignificant
3.2.2.3 Security Approach
A logical link will be provided between SAP ADS and the Financial System exploiting
the Post Office and Horizon physical networks. Initially this assumes exploitation of
FTMS to pull the file from Huthwaite to the Fujitsu Services Data Centre where it will
be placed in the Input area for the Financial System.
No special security implications are assumed.
3.2.2.4 Resilience requirements
Normal FTMS resilience implemented within Horizon is considered appropriate.
3.2.2.5 Operational requirements
Normal FTMS Operation, together with exploitation of the Horizon automatic audit of
data received.
3.2.2.6 Expected Deliverables
3.2.2.6.1 New or Enhanced Functions
Component Description
Ledgers
Extend Cash Ledger to receive Cash Centre
information
Cheque accounting procedure and ledgering
Host
Produce SAP Interface file from SAP ADS
External
Bank file interface
Table 2 — Project 2 Functions
3.2.2.6.2 New or Enhanced Interfaces between systems
The interface to the Financial System, described in Section 3.3.1.
3.2.3. Project 3 - Automatic Cash remittance of pouches into branches
To further improve the accuracy and timeliness of the Cash Management view of Post
Office’s funding, over and above the improvements made by the previous projects (see
Sections 3.2.1 and 3.2.2) this project will ensure notification, to central systems, of
movements of cash between Cash Centres and branches.
The particular business requirements being addressed by this project are:
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 30
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
= To improve the financial
controls for cash remittances
(where there are currently
losses of £5m per annum)
= Improve management
information, linked to
financial statements, —to
support the management of
cash (funds)
= To enable cash holdings to be
driven down and_ therefore
reduce the DTI borrowing
requirement, which in turn
will reduce the level of
interest paid.
= To be able to forecast and manage cash-flow within the DTI target (€330m for
2002/03)
These requirements exist for both Cash and Stock pouches, however they have not been
identified as a priority for the Stock management function to same the degree as for
Cash management. Therefore, this project only addresses increasing the control of Cash
pouches.
It is currently permissible for a Pouch to be received by a branch, but for details of its
contents not to be “Remitted-In” to the counter system for some time. This results in
the contents not being properly accounted for within the overall system, and in
particular for any Cash not being reported as belonging to the branch until it is
Remitted-In, thus presenting an inaccurate view of the overall Cash Position.
A Delivery Note is produced by the systems as soon as the pouch is delivered as a
receipt for the person making the delivery. An electronic version of this Delivery Note
is also passed back to SAP ADS (via LFS) indicating that a pouch has been received at
the branch. However there is nothing recorded at the time indicating what the content
of the pouch actually is (and at present there is no way of telling within the system).
The proposal is to ensure that the value of the cash is automatically Remitted-In to the
outlet as part of the Delivery Process. There are a number of possible ways of
achieving this, however the mechanism selected is:
The Cash Centre / Stock Warehouse functionality is extended to produce a “Delivery
Notification” when the pouch is packed and to pass this through SAP ADS to LFS and
hence to the counter such that the Delivery Notification will normally arrive at the
outlet prior to the pouch.
When the barcode on the pouch is scanned, the Delivery Notification will be found and
the content can be used to Remit-In the content as defined by the Cash Centre / Stock
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 31
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
Warehouse. If the Postmaster subsequently finds any errors, then these can be recorded
as Discrepancies.
Note that the current system allows the postmaster to Remit-In whatever value he likes
and it is left to some central processing to identify any mismatches between what is
Remitted-In and what was Dispatched. Forcing the Despatched values to be Remitted-
In and then highlighting any Discrepancies should simplify the central processes.
One drawback of this approach is that if the Delivery Notification has not arrived at the
outlet before the pouch, then it will not be possible to do an automatic Remit-In. This is
expected to be the case in about 1% of pouches assuming that Delivery Notifications
are produced overnight. The figure may be a bit higher if they are generated the same
day as the actual pouch delivery. The detailed requirements analysis will define the
action to be taken in these cases.
3.2.3.1 Outline Solution Design
The following provides an overview of the design:
= An additional file feed will be provided from SAP ADS to LFS providing details of
the Delivery Notification. Such files would be sent periodically as required. A
detailed timetable of when such files are likely to be delivered will be agreed.
= The LFS Host will be enhanced to pick up these files and to process the content into
a new Interface table in a similar way to that in which Planned Orders are
processed.
= An agent will be provided to distribute the Delivery Note to the branch.
= Consideration will be taken as to the scheduling of inward connections from counter
to ensure that there is a reasonable chance of the Delivery Note getting to the
counter in time. The working assumption is that there is no need to change the
current schedule, which is designed to support the flow of LFS data from the branch
to the Data Centre.
= Changes, at the counter, will be made to the LFS Delivery screen. In summary:
o The receipt of a pouch will initiate a search for the associated Delivery Note
o If the Delivery Note is found, the system will Remit-In the contents
automatically
o The clerk will have the option to check the contents (now or later) and a
separate dialogue will allow him / her to declare any discrepancy between the
amount Remitted-in and the actual content. Any such discrepancy will then be
handled as a suspense item until the matter is resolved. Note that the pouch
number is used as a “link” for any such transaction to allow any subsequent
error correction to be managed.
c If the Delivery Note is not found, then the Delivery Notification returned to
SAP ADS will indicate that fact.
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 32
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
co When the Delivery Note arrives the Auto Remit-in of the content can take place
as a background process.
Then, a further Delivery Notification will be sent to SAP ADS informing it that
the pouch has actually been Remit-in.
= Any additional Delivery Notifications would be handled using the existing LFS
Harvesting mechanisms.
3.2.3.2 Sizing and scalability
Cash Deliveries take place no more than twice per week per outlet, so the volume of
Delivery Notifications will be about 5,000 per day.
3.2.3.3 Security Approach
No additional security considerations are envisaged. The existing link between Horizon
and SAP ADS has the required security.
3.2.3.4 Resilience requirements
Normal FTMS resilience facilities are assumed.
3.2.3.5 Operational requirements
There may need to be additional deliveries from SAP ADS to Horizon. A schedule for
such additional deliveries will be defined as part of the detailed design. When the
branch Remits-In the pouch this information will be included in the feed to the ledgers
with the transaction data stream.
3.2.3.6 Expected Deliverables
3.2.3.6.1 New or Enhanced Functions
Component Description
Host
Receive Delivery Note from SAP ADS
Agent
Load Delivery Note to Riposte
Counter
Auto Remit-In when Delivery Note Received
Dialogue to Reconcile Delivery Note and Pouch raising discrepancies if
necessary
Handle Late arrival of Delivery Note
Ledgers
Extend accounting to receive the remitting-in and out information
Table 3 — Project 3 Functions
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 33
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
3.2.3.6.2_ New or enhanced Interfaces between systems
3.2.4
Additional data flows need to be defined and to be carried by the existing systems
interface from Horizon to SAP ADS.
Project 4 - Branch Liability Management
Within the “Accounting,
Reconciliation and Settlement,
including Debt Recovery and
Branch Control” area of the
business the following key ca
business priorities have been oy
identified:
= Simplify identification of debt stock
= Reduce the amount of sree —
Manages
reconciliation
= Increase the amount of debt
recovered
= Put the emphasis on clients
and customers to validate the data
= Simplify branch processes by reducing the amount of paper
= Centralise/consolidate agents debt
= Enable matching of cash at branches with settlement with client
In recognition of these priorities this project addresses specific requirements behind
these business drivers and issues:
= Re-focus on Debt Recovery (financial recovery of money), target 95%
o Only 10% of discrepancies are actually debt
= Establish a central debt-monitoring environment to enable the identification of debt
with a high degree of accuracy
= Increase accounting control in branches
= Improve timing, accuracy, granularity and summarisation levels
= Establish an appropriate and flexible accounting hierarchy
= Modify the method of recovering debt e.g. using payroll for agents
Branch Debt is currently identified within the Transaction Processing system when the
Cash Accounts are being checked. Generally this means that it is of the order of two or
three weeks after the original Debt was incurred before it is spotted and investigated.
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 34
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
The next (analysis) phase of the programme will carry out a complete analysis of what
activities at the outlet can result in a need for Debt Recovery. The following are
candidates:
= Discrepancies identified during Stock or Cash Declaration process that the
Postmaster is not prepared to accept.
As part of the Declaration process the Postmaster will be given the option of “making
up the difference” when a discrepancy is spotted (effectively selling him / her the stock
if it is a stock discrepancy or topping up the cash in the till in the case of a cash
discrepancy). Alternatively he can refuse to make up the discrepancy and force the
discrepancy into a “suspense” account for later resolution.
= Discrepancies found during Remitting-In of pouches (see section 3.2.3)
In addition, it is anticipated that the following activities will be carried out centrally as
part of the Debt Recovery function:
= Rota Checks. These are periodic checks of any supporting paperwork provided by a
branch against (currently) the Cash Account. This process can give rise to some
additional discrepancies that need to be resolved.
= Activity Checks. These are analyses of transactions in a branch against statistical
trends where any unusual transactions are identified and investigated. Unusual
transactions may also be identified where the volume or value of particularly
vulnerable transaction types exceed some pre-defined thresholds.
m Cheque checks. The handling of cheques provides a number of opportunities for
errors, which may not be visible in the branches accounts. For example, the number
or values of cheques received at the “cheque-processing centre” may not match that
Remitted-Out of the branch. In addition there are further opportunities for cheques
to generate errors (for example they could “bounce”)
To address these issues, an enhanced Transaction Management system will be
introduced, initially only providing the functionality to support the Branch Debt
Recovery process The project will introduce the Branch Liability Statement concept.
The scope of the project is as follows:
= The Transaction Management System will not, at this stage, be linked to the
Reconciliation mechanisms for Banking, Debit Card and AP clients. Reconciliation
will continue to operate through the current Cash Account mechanism managed by
existing systems.
= Enhancement of the Financials System, introduced in section 3.2.1, to record
summaries of all branch activities (i.e. not just the cash movement).
This will implement the first part of the Debt Recovery and Verification processes and
provide support for investigation of Branch Discrepancies.
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 35
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
For discrepancies and issues identified within the Financial System, the Transaction
Management system can be used to examine the detailed transactions that make up the
problem ledger entries.
A key aspect of the solution is the concept of “correcting transactions”, to be applied at
the Branch based on information generated in the centre. This will to keep the Branch
Liability (as seen at the outlet) in step with the central view of Branch Liability. The
proposed solution is to centrally generate “correcting notices” and propagate them
automatically to Branches. It is for the Postmaster to endorse the correction and thereby
create a new transaction, which brings the accounts back into balance. The nature of
the correcting notice will vary according to the underlying problem: typically a write-
off of a small keying error or bounced cheque, which had been correctly administered,
or alternatively an increase in the Post Master’s liability if it is determined that
stipulated checks were not carried out correctly in the Branch. Write-offs could be
made automatic whereas in all cases where the Post Master is invited to increase his
liability he would be expected to acknowledge acceptance of the correcting transactions
before they are applied.
The benefit of the proposed approach is that the new processes can be introduced before
all the new facilities/enhancements in the back-office systems are implemented. The
manner in which any corrections are applied to the Branch Position (as reflected in the
Branch Liability Statement) means that the corrections will flow through to both the
Cash Account and to the Branch Liability Statement, thus enabling the parallel back-
end systems to “keep in step”.
In terms of system developments and implementations, this project is split into two
parts:
= Transaction Summarisation and Posting
= Discrepancy Correction Notification
They are considered separately below
3.2.4.1 Transaction Summarisation and Posting
3.2.4.1.1 Outline Solution Design
The following provides an overview of the design:
= As part of the Branch EOD process, a Summary of the Branch’s trading for that
Trading Day will be produced.
All transactions will be summarised, to simplify their posting to the Financial System.
Transaction data will be enriched to include its Trading Date as an attribute.
= Support will be provided to enable counter processes to operate without the need to
roll-over Stock units into new Cash Account periods. This will be implemented in
such a way that the use of Cash Accounts can be removed by activating a Reference
Data change when the cash account is no longer required (i.e. in a later project).
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 36
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
= Summaries will be harvested to the Transaction Management system
= Movements will be posted to the Financial System.
The interface introduced at 3.2.1 will be further extended to support this flow
In addition to producing the summarisation of the day’s transactions for posting to the
Financial System, the branch system will be enhanced to produce the BLS locally at the
branch at any time (on request).
3.2.4.1.2 Sizing and scalability
EOD processing will generate about 18,000 Summarisations daily, to be passed from
the Transaction Management System to the Financial System. This volume of data is
assumed to fit into a single file, which can be loaded into the Financial System.
3.2.4.1.3 Security Approach
No special security implications have been identified.
3.2.4.1.4 Resilience requirements
Existing resilience provisions will continue for delivering the output files from the TPS
Host
See also section 3.3.2.4.
3.2.4.1.5 Operational requirements
User administration is introduced for Post Office users that require access to the
Transaction Management and Financial Systems.
3.2.4.1.6 Expected Deliverables
3.2.4.1.6.1_ New or Enhanced Functions
Component Description
Counter
EOD production of Trading Summary
Produce BLS Report
Include Trading Date in all Transactions
Agent
TPS Harvester to Harvest Summaries
Transaction interrogation for investigation
of errors
Host
Produce SAP Interface file from TPS Host
Ledgers
Profit Centre and Cost Centre accounting
Accounts receivable — Agents liability
Table 4 — Project 4a Functions
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 37
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
3.2.4.1.6.2 New or enhanced Interfaces between systems
The interface from the branch to the Data Centre is based on the existing Riposte
messaging middleware.
The interface to the Financial System is described in section 3.3.1.
3.2.4.2. Discrepancy Correction Notification (DCN)
3.2.4.2.1 Outline Solution Design
The following provides an overview of the design:
= A DCN service will be introduced within the Transaction Management System and
Financial System. Errors detected within the Financial System, will periodically be
notified in the form of Discrepancy Notices to the Transaction Management
System.
It is assumed that it is sufficient to distribute such Notices daily, and hence that this
mechanism can be incorporated into the overnight Bulk processing.
The Transaction Management System will cause the Notices to be distributed to the
Branches where the necessary adjustments can be made to the BLS.
The distribution of Notices will be achieved by exploiting Horizon’s existing memo
distribution capability.
= The counter will be developed to react to Notices.
To ensure that branch staff is aware of changes to the branch position, the following
simple mechanism is proposed to be implemented:
c The Notice will be encapsulated in a Memo aimed at the Manager / Supervisor
co When the Memo is viewed at the counter, the Postmaster will be given
information to enable creation of a normal “Error Notice” transaction, which is
already supported on the counter.
= During this project the complete E2E process for handling DCNs (including those
where the Postmaster declines to action an increase in his liability) needs to be
designed (including the ledgers).
= The process and data flows for cash and stock declaration will be specified
including the processing of discrepancies.
= The reconciliation and interrogation requirements will need to be defined.
= Within the Financial System, the processing of identified discrepancies will utilise
“suspense accounts” and “open item” functionality of SAP. By matching items,
using unique references, it will be possible to identify which discrepancies remain
open.
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 38
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
3.2.4.2.2. Sizing and scalability
The volume of Error Notices is expected to be modest. It is assumed that there will be
less than one per branch per week, i.e. no more than 3,000 per day.
3.2.4.2.3 Security Approach
There are no special security implications, given that the Postmaster is assumed to
control the entry of any Correcting Transactions rather than the system doing it
autonomously.
3.2.4.2.4 Resilience requirements
No specific additional requirements were identified. It is assumed that Error Notices
could be delayed for a number of days due to network failures. However this is seen as
acceptable as it still represents a significant improvement above the current procedures,
which rely on the post.
3.2.4.2.5 Operational requirements
The new Discrepancy Correction Notification Service needs to be set up and operated.
3.2.4.2.6 Expected Deliverables
3.2.4.2.6.1 New or Enhanced Functions
Component Description
Host
Import Error Notices from Financials and make available to Agent
Counter
Dialogue to allow Postmaster to Accept Reject Error Notice
Ledgers
Accounting for discrepancy correction notification
Table 5 — Project 4b Functions
3.2.4.2.6.2_ New or enhanced Interfaces between systems
The interface from the branch to the Data Centre is based on the existing Riposte
messaging middleware.
The interface to the Financial System is described in section 3.3.1.
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 39
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
3.2.5 Project 5 - Client Settlement and Ledgering
As identified within the
“Accounting, Reconciliation
and Settlement, including Debt Coon) Manga
Iieeezatsn
Recovery and Branch Control”
area of the business, the
following priorities remain
SS,
after completion of the costes
F fi i: platen
previous project (see Section =
NY
\
cx
‘Mamgemeat
9 Gabans)
f
3.2.4):
Set
warehouse
Mangement
\
Sock
m= Reduce the amount of 7 ez
reconciliation required i
= Put the emphasis on clients Ny loatete
and customers to validate
the data
= Enable matching of cash at branches with settlement with client
This project is designed to specifically address the following business requirements:
= To report Business and Client information separately and accurately
= Deliver performance measures of throughput and the actual financial debt
= Rationalise legacy systems for reporting of client and business information
= Improve timely data availability, accuracy, granularity and summarisation levels
= Avoidance of losses from remittances and client settlement
= Accounting and settlement on Post Office data, not clients’
o (It should be noted that settlement estimating can produce positive or negative
interest position)
= Cash centre accounting is manual, weekly, therefore no through view from
transaction to settlement
Client Settlement and Ledgering is one of the main sources of Transaction Management
work, requiring reconciliation of transactions with clients and the accounting of any
discrepancies that emerge from this. The Transaction Management System will provide
the interface to all client systems (both AP and on-line) and perform reconciliation
associated with such clients. The new Financial System will take over the support for
client settlement, thus enabling the settlement to take place based on the actual figures
available from the Transaction Management System reflecting the actual feeds to the
clients.
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 40
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
Further analysis, expected during the next phase of the programme, will determine the
precise approach to be adopted for migration of financial information between the
legacy and the new system.
3.2.5.1 Outline Solution Design
This development may best be portrayed as an integration of the current Horizon Host
Systems to provide a single Transaction Store for the Transaction Management System.
This project should have no impact on the counter. At the Data Centre the following
changes are needed:
= Create a single Transaction Source for all Transactions.
= All Transactions will be passed onto the MI system. This should be considered to be
an equivalent to the current OPTIP flow.
= Summaries of transaction volumes (from the BLS) will be passed through a new
interface to SAP HR to support Postmaster Remuneration
= EOD Information is required to enable “closed days” to be identified, thus allowing
Reversals to be “netted out”, and also to enable “Non-polled” information to be
available to users.
= A User interface will be provided to enable Post Office users to enquire of the
Transactions being held.
= Any Transactions currently processed by DRS or APS will be retained for a period
to support investigation. The remainder can be discarded once they have been
passed to MIS
= The following changes will be made to the APS functionality:
co The need to compare the AP data with the TPS Data will be eliminated since
there will now only be a single flow.
co Client Summaries will be produced and reconciled based on the Trading Date
held within the Transactions rather than as at present. The Client Summaries
will be output as a “posting file” for the Financial System. Assembly and
delivery of files to clients will be as at present.
= The analysis of the client flows to accounts payable in the ledgers will need to be
finalised. It is expected that clients will be managed on an “open item” basis and
ensuring that settlements are easily processed and that liabilities are easily identified
at any point in time.
= In SAP, clients will be set up as vendors. Several vendors will be created for clients
with several products. The accounts will thus be separated to reflect possibly
different attributes that need to be associated with them e.g. because there are
different terms of payment. Vendors can be grouped together. In the case of
Girobank accounts, these accounts will be set up separately in the first instance and
grouped together for payment purposes. This structure will facilitate evolution, for
example when Girobank is no longer used.
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 41
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
= Automatic payment runs from accounts payable will generate a BACS file, which
will be transmitted to the bank. The bank will carry out the client settlement.
Manual payments can also be processed through this route.
= SAP will receive client master data from the Reference Data Management Centre.
= The following changes will be made to the DRS functionality:
o C112 flow from TPS Host will be eliminated (no longer be needed)
co A “posting file” for the Financial System will replace a set of Reports. This
Posting File will reflect the Settlement information received from the Client
(e.g. NBE or Streamline)
co The MSU process will be changed to operate on reports from the Financial
System, however it will still move Reconciliation Discrepancies into Final State
when they have been fixed
oc The current “Exception Reports” generated by DRS will be replaced by the
ability to drill down and view Transactions in Exception states.
Having made these changes a single Transaction Management system will have been
created instead of separate TPS, APS and DRS Systems. LFS will continue to provide
the SAP ADS interface, though this may also be considered to be part of the
Transaction Management System.
3.2.5.2 Sizing and scalability
The volume of Data should be no different from the present (together with the
additional data generated by earlier projects). However, the retention of data will
change as follows:
= Client Transactions (i.e. existing DRS and APS) will be held for 56 days.
It is assumed that any exceptions will have been resolved in that time.
= Information on non-polled outlets will be held for a similar period
= Other transactions will not be retained once they have been delivered to the MIS
system
m Transaction Summaries will not be retained once they have been delivered to the
Financial System and SAP HR.
It is assumed that there will be at most 150 users of the Transaction Management
System, all from Post Office.
3.2.5.3 Security Approach
Further discussions with Post Office will be needed to ascertain what security controls
need to be implemented for user access to systems within the Horizon Data centres.
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 42
New Fujitsu Proposal
FUJITSU eer
FUJ00098169
FUJ00098169
21 March 2003
Version 1
3.2.5.4 Resilience requirements
The new Harvesting process will ensure that no Transactions are lost and that any
duplicates (which can arise following failures) are eliminated.
See also section 3.3.2.4,
3.2.5.5 Operational requirements
It is assumed that the new Transaction Management System workload will fit into the
current Horizon Host systems.
3.2.5.6 Expected Deliverables
3.2.5.6.1 New or Enhanced Functions
Component Description
Host
Create Transaction Management DB
Load data as required (from Riposte Audit)
Generate MIS feed of all Transactions
Feed of Summaries to SAP HR
Support current DRS and APS functionality based on the new
Transaction feed.
Pass AP Client Summaries to Financial System
Pass DRS Reports to Financial Systems
Base DRS Reconciliation on Financial System and DRS Workstation
Ledgers
Accounts Payable set up
Automatic payments to bank (BACS)
Table 6 — Project 5 Functions
3.2.5.6.2 New or enhanced Interfaces between systems
The evolving interface to the Financial System is described in section 3.3.1.
3.2.6 Project 6 - Improved Cash / Stock Management
For the Stock Management function,
the identified business priorities are
to reduce operational costs in the
Transaction Stock and Value Stock
operations, whilst maintaining
existing availability levels.
This project will provide the ability
for the Branch to check Cash / Stock
Orders (as notified through Planned
Orders) and to adjust the orders and
© 2003 Fujitsu Services Ltd Commercial in Confidence
Page: 43
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
place emergency orders electronically through the Horizon counter.
This project will address the following business requirements, drivers and issues:
= Reduced cost
= Centrally managed stock transport orders.
= POL liabilities for losses.
= Reduced operation charges in warehouse
= Reduced cost for transportation
= Stock availability
a 99% availability for Royal Mail products
co 98% availability for other value products (fishing licenses, local authority
schemes)
The following capabilities could also be provided as part of this project if further
analysis yields a positive business case:
= Provide Delivery Notes and automatic Remitting-In of Value Stock (as described in
section 3.2.3 for Cash)
= Posting details of Stock Movements to the Stock Management System
Although not included in the costs for this project, these features would additionally
improve the situation around the following business identified issues:
POL liabilities for losses.
Derived sales figures (CBDB) currently used for MI and settlement
Lack of single, consolidated view of stock.
Section 8.3 indicates the possible solution and its costs for a Stock Management
system.
3.2.6.1 Outline Solution Design
This project is targeted at allowing branches to place their cash / stock orders
electronically through Horizon. It is assumed that Advice Notes (currently used to
request that cash / stock be returned) will continue to operate as at present. If any
changes are required to Advice Note handling (and in particular allowing an Advice
Note to generate a Remit-Out), then these are outside of the current scope.
The following evolution of the Horizon solution is anticipated:
= The Planned Order, passed from SAP ADS to LFS will be structured so that it is
possible to identify the individual items in the Planned Order.
= LFS and the Planned Order Loader agent will be updated to reflect the structure in
the Planned Order sent to the counter
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 44
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
= The Counter Application that displays and prints Planned Orders will be enhanced
to reflect the structure. It will also provide an “Edit Mode” that allows a Planned
Order to be modified and an Updated Planned Order to be returned to LFS. In
addition it will support the ability to add additional items to a Planned Order or to
create an Emergency Order from scratch. In all cases Reference Data will be
required to define what items can be ordered in the proposed manner.
m The LFS Harvester and Host will be enhanced to pass Updated Planned Orders and
Emergency Orders back to SAP ADS. It is assumed that these are posted onto SAP
ADS as part of the existing feeds that carry Delivery / Collection information
periodically during the day.
In addition the Automatic Remitting-In of Cash (described in section 3.2.3) is extended
to automatically remit in Stock pouches, assuming that SAP ADS can provide a
Delivery Notice with the relevant information, mapping the Stock Items to Products.
If required the Stock management could be implemented on SAP and integrated with
the Financial System. At this stage the requirements for this are not known, however an
indicative price is included in section 8.3. Note that this would be a separate (new)
project.
3.2.6.2 Sizing and scalability
Planned Orders are expected twice per week for Cash and once per fortnight for Value
Stock. Currently there are no Planned Orders for Transaction Stock. Assuming that the
Emergency Order mechanism will be used for Transaction Stock, with one order per
fortnight, this will generate no more than 10,000 orders per day.
3.2.6.3 Security Approach
No changes to Horizon security envisaged within this project.
3.2.6.4 Resilience requirements
No new Resilience requirements need to be met - overnight delivery of order messages
is anticipated as the norm.
3.2.6.5 Operational requirements
No special Operational Requirements.
3.2.6.6 Expected Deliverables
3.2.6.6.1 New or Enhanced Functions
Component Description
Host
Enhanced structure for Planned Orders
Transmit Amended / Emergency Planned Orders to SAP
ADS
Agent
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 45
FUJITSU
New Fujitsu Proposal
Ref: BD/PRP/011
FUJ00098169
FUJ00098169
21 March 2003
Version 1
3.2.6.6.2 New or enhanced Interfaces between systems
3.2.7
Component Description
Load Enhanced Planned Order
Harvest Amended / Emergency Planned Orders
Counter
Provide enhanced dialogue to view Planned Order
Provide Planned Order Amendment Dialogue
Provide Emergency Order Dialogue
Support Auto Remit-In of Stock
Table 7 — Project 6 Functions
Additional data flows will be defined and will be carried across the existing systems
interface from Horizon to SAP ADS.
Project 7 - Automated Ledgering for Stock
This is the equivalent of the changes
described in section 3.2.2, but to
handle Stock Movements rather than
Cash.
This project, in conjunction with the
previous projects, supports the
fulfilment of the requirement from the
“Accounting, Reconciliation and
Settlement (including Debt Recovery
and Branch Control)” area of the
business to “enable proper accounting
of cash and stock”, for stock.
3.2.7.1 Outline Solution Design
This project will enhance SAP ADS and enable the Financials System to utilise the
SAP ADS information feed. The SAP ‘Light’ solution for financials is assumed and
hence that the stock balances will not be transferred into the POL Ledgers by product,
but only for total value. This would change were it decided to account for Stock in the
SAP Financial System. The assumption is that SAP ADS will conform to the same
input file format for the Financial System as that defined in section 3.2.1 and hence that
no further developments are required.
© 2003 Fujitsu Services Ltd
Commercial in Confidence
Page: 46
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
3.2.8 Project 8 - Personal Agents Ledgers
This project is the final step in
implementing the new Financial 7
System. Once completed, all the { ‘Clients: J oe
current back-end systems’ 7
processing can be transferred to the
new system and the old systems can —
be decommissioned. rence oom
(SAP ADS)
There are a number of existing
systems that currently rely on s v
CBDB for their data. Mostly, these
will be switched off, with perhaps a)
few being changed to obtain their
data from the Transaction
Management system before the decommissioning of CBDB takes place. It is important
to note that the implementation of the new Financial System will deliver a range of
important soft (i.e. financially un-quantified) benefits, in particular providing increased
robustness to Post Offices accounts.
Additionally, this project delivers the Personal Agents ledger, which builds on the
Branch Ledger, grouping information for multiple branches owned/managed by
common agents. The interface from ES-FS for the debt recovery items processed
directly into ES-FS, will be implemented in this project, to give a total liability view in
the POL Ledgers.
Dependent on the cost/benefit assessments of doing so, the project may additionally
provide collection of expenditure items allocated to branches, which is currently done
in ES-FS. This may be achieved by transfer of data from ES-FS or by moving the
process of collecting order processing and cost accounts to operate on the Post Office
Financial System. The option to account for expenditure by branch within the new
Financial System is not costed within this document.
3.2.8.1 Outline Solution Design
The current assumption is that this project will involve, only, a limited set of changes to
the Financial System, and provision of one additional interface. Decommissioning costs
of POL Systems (OpTIP and CBDB) are not fully known, further analysis may be
required in this area, although Post Office probably already has sufficient understanding
of the costs for the purposes of the Feasibility Study.
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 47
FUJITSU
New Fujitsu Proposal
Ref: BD/PRP/011
FUJ00098169
FUJ00098169
21 March 2003
Version 1
This project is designed to simplify
the internal processing within the
Transaction Management area. In
particular, in the context of the new
simpler business processes and flow,
which will have been established by
this time, there will be opportunities
to reduce internal reconciliation and
automate more of the exception
processing.
3.2.9.1 Outline Solution Design
The functionality of APS, TPS and
Apptexon
3.2.9 Project 9 - Simplified & Improved Transaction Processing
{saan
i
DRS, which would have been enhanced in earlier projects, will be rationalised and
duplicate functions will be eliminated.
Specifically:
= TPS will be decommissioned
= Cash Account data will be removed from RDMC / RDDS and Counters
Within the area of Reference Data
management the key _ business
priorities have been specified as:
= To ensure consistency in
reference data usage within Post
Office and Fujitsu Services
domains
= To simplify the current
processes
= To allow changes, such as
organisational changes, to be
implemented in a more timely
fashion
Leading to the requirements:
= To support data driven change within the business
= To reduce costs of operation
3.2.10 Project 10 - Reference Data Improvements
wrsboose
© 2003 Fujitsu Services Ltd
Commercial in Confidence
Page: 48
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
= To remove inconsistent reference data usage within the organisation
= To effect a vastly improved speed to market for new capabilities
= To implement an automated end-to-end process to capture reference data changes,
to minimise delays and errors.
= To centralise the many locally held reference data sources
To address these requirements a number of specific improvements were identified
which will deliver the needed benefits. The steps taken to manage Reference Data need
to be implemented as a joined-up process and supported by improved tooling,
particularly to assist with automation of Reference Data checking and faster flow of
information from capture to its deployment.
Therefore, this project covers the re-engineering of the Post Office Reference Data
Systems and the processes to support the input and validation of data to the systems.
Reference Data requirements, which are specific to individual projects, will be
addressed as parts of each of those projects, and allowances have been made within the
individual project cost estimates.
3.2.10.1 Outline Solution Design
It is assumed that any residual Reference Data System needs, over and above those
required by Fujitsu Services projects within this paper, will be provided within the
domains of the other systems requiring the Reference Data (e.g. SAP ADS). It may be
beneficial to redevelop the Post Office RDS system, and the WRDS initiative may be
the best starting point for such a development. Fujitsu Services lacks, at present,
sufficient information to support a construction of a proposition and hence to estimate
associated costs.
3.2.11 Project 12 - Management Information (local/central)
The business _ priorities —_— for
Management Information have been sry
identified as: ( Glieais I) EI
= Having systems which enable the Ss, :
quick production of MI to serve
flexible organisation structures
= Generating a commercially based
culture in the retail line via profit
and loss visibility
= Improving the timeliness of
information
Other projects identified earlier
within this paper will provide much management-relevant data, in particular financial
information, in a timely manner for it to be useful. It is recognised that a number of
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 49
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
further requirements for management information exist, and the Sales MI system is
considered an appropriate starting point for evolving a sophisticated MIS to address
these requirements. The flow of transactional data from the Transaction Management
system can provide a wealth of raw data from which management information can be
derived, especially if this is enriched by suitable additional feeds (e.g. market data, sales
targets, expenditure information from financials, etc). While Fujitsu Services has
proposed, but not costed, the moving of the operation of the Sales MIS service into the
Fujitsu Services domain, no account has been taken of the potential costs of future
developments.
Although further analysis is required to establish a more comprehensive view of the
requirements, the following types of reports are expected to be delivered from the MIS:
= Basket Analysis and Incentivisation effects
= Profit & Loss projections for Branches and/or products
3.2.11.1 Outline Solution Design
Fujitsu Services recognises that management information needs evolve as the business gains
understanding of its performance and seeks further information to maintain business
improvement. Such evolution is difficult to predict and it can fundamentally alter the needs for
data and processing capacity.
Some of the MI needs of Branches could be met by local processing, rather than by
centralised MIS. A demonstration of the possible approach was developed and given to
Post Office, and Fujitsu Services will welcome further discussion about this approach to
satisfying at least some of the local management information needs. The advantages of
the local approach include exploitation of local processing capacity, which could reduce
the scale of the central system, and immediacy/availability of relevant local information
to Branch Managers. The local approach may also reduce report distribution costs.
3.2.12 Project 13 - Cross Selling
In reviewing the Sales area of the
business the following business
requirements were identified:
= Developing & maintaining product
delivery processes which ensure
value is delivered to clients who
will thus wish to retain Post Office
as their channel
= Opening new markets and
developing new product offerings
with new and existing clients to
bridge the earnings gap created by
the loss of some existing products
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 50
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
= Improving the contribution to earings by reducing costs of delivering and
administering existing products
= Having an IT capability that supports a wide range of customer propositions
= Having exit strategies for non profitable products
= Designing non conformance out of the service
Many of the projects within this paper support these requirements. This project is
designed to provide facilities to counter staff, which will enable/ encourage them to
actively cross-sell products.
Through this project, a facility will be provided at the counter, where an attribute
associated with a product in Reference Data can trigger a prompt to the clerk suggesting
a cross-selling opportunity.
The prompt and the trigger will be added into the Reference Data model and passed
through from the Reference Data Systems to the Horizon Desktop. The counter
software will be enhanced to detect the trigger and display the appropriate prompt.
It is assumed that any cross-selling prompts will be common to all outlets where a
product is sold. It is also assumed that this project delivers a solution that does not
require customer identity and preferences to be know. A more comprehensive solution
based on principles of Customer Relationship Management can be proposed, but that is
seen outside the current E2E re-architecting scope. Fujitsu Services would be very
happy to discuss this further with the “New Opportunities” team. The E2E architecture
does not preclude the introduction of sophisticated CRM capabilities.
3.2.12.1 Outline Solution Design
The paper here is:
= That the Product Reference Data model be enhanced such that for each product a
list of potential “cross-sell” products can be specified
= The RDMC will propagate such data to the counter
= The counter will check for any cross-sell links during any sale and if present will
present the clerk with a cross-sell dialogue at the end of the “triggering transaction”
= For costing purposes, the “cross-sell dialogue” is assumed to be represented
textually, however consideration will be given to presenting an interactive link to
displays such as pick lists
3.2.12.2 Sizing and scalability
Further analysis is required to ascertain the volumes of links between products that may
be desired. Here in it is assumed that “cross-selling” reference data will be held
separately from the main reference data and connected by links.
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 51
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
3.2.12.3 Security Approach
No particular security implications have been identified.
3.2.12.4 Resilience requirements
No special resilience implications have been identified.
3.2.12.5 Operational requirements
No specific requirements have been identified that would require extension to existing
Horizon provisions. Once the functionality is available at the counter, the provision of
such prompts will be handled by the normal OBC mechanism.
3.2.12.6 Expected Deliverables
3.2.12.6.1 New or Enhanced Functions
Component Description
Host
Ref Data Support for enhanced Products.
Counter
Detect Cross -Sell trigger and launch Cross-Sell
dialogue
Table 8 — Project 12 Functions
3.2.12.6.2 New or enhanced Interfaces between systems
The Product Reference Data flow from RDS to RDMC will be enhanced to support this
additional flow.
3.2.13 Project 14 - HTML Help
As described in the previous project (see
Section 3.2.12) the Sales area of the
business identified requirements around = \“"** /
increasing sales, reducing costs of
delivering and administering products and
improving conformance of sales processes. =}
It is recognised that further support to the
clerk, provided through the counter
system, would address these requirements.
The introduction of Mails has provided the
ability to extend the amount of Help
available with a button on the Horizon
Desktop. Through this project the underlying technology will be exploited further.
Other desktop buttons will be provided, so if there are particular activities within which
extended help is appropriate for the clerks, this feature can be exploited.
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 52
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
3.2.13.1 Outline Solution Design
The implementation of Mails has introduced the standard Web Riposte facility of
Extended Help to the counter. The Help facility is provided by a set of HTML pages,
which can be associated with any Desktop Button. This extended help capability can be
exploited with any other aspects of the system that POL consider would be of benefit.
The following developments are envisaged:
= The solution is assumed to exploit the Web Riposte mechanisms for “Effective
dates” (achieving effects similar to Temporal Objects). A development of generic
HTML Help loader will be carried out to support direct loading of Help Data into
Correspondence Servers.
= Further analysis will be carried out to define Authoring and Authorising processes
to be used in conjunction with this facility. These processes will be co-ordinated
with the current Type C Reference Data processes. It is assumed that (Type B)
direct feed of Help texts from Post Office will be utilised.
3.2.13.2 Sizing and scalability
Experience with the Mails Help information has shown that there are potential
problems in distributing large numbers of changes in a single “chunk”. To avoid such
problems, a mechanism will need to be put in place to divide Help Text into
manageable chunks for distribution and utilise the “Effective Dates” feature of Web
Riposte to co-ordinate the activation of changes.
Help Text will be distributed using WebRiposte Subscription Groups facility. It is
assumed that the rate of change in help text will not be excessive and hence that the
existing Horizon distribution mechanisms will suffice without imposing undue
overheads on the network.
3.2.13.3 Security Approach
No additional security implications have been identified.
3.2.13.4 Resilience requirements
No additional resilience implications have been identified.
3.2.13.5 Operational requirements
No specific requirements. Once the functionality is available at the counter, the
provision of Help Text will be handled by the normal OBC mechanism. It is assumed
that the frequency of change will not exceed the thresholds defined for the OBC service
in the Horizon Agreement.
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 53
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
3.2.13.6 Expected Deliverables
3.2.13.6.1 New or Enhanced Functions
Component Description
Agent
HTML Help Loader
Host
Possible support through RDMC
Table 9 — Project 14 Functions
3.2.13.6.2 New or enhanced Interfaces between systems
The RDS (or its replacement) to RDMC interface will be enhanced to support the
management of Help Text.
3.2.14 Project 15 - Printing of Virtual Stock
It is recognised that the business
priority, for the Stock Management a
function, is to reduce operational ( Clients) ecg
costs in the Transaction Stock and ln il
Value Stock operations whilst
maintaining existing —_ availability
levels.
Many of the business requirements
for this area of the business are
addressed through projects described
above (see Sections 3.2.6 and 3.2.7).
One possible way of further reducing
the costs of Stock Management is to
print the stock locally (i.e. adopt the notion of “Virtual Stock”). However there are a
number of potential challenges to be overcome to achieve a cost justified initiative. In
particular:
= The existing counter printer is relatively slow and of low print quality. It is unlikely
to provide sufficient quality for printing of secure stock
= There are security implications in printing value stock, since if the outlet can print
it, then so could the customers on home PCs
= Printing forms on the back-office A4 printer may be a feasible option, however the
back-office is sometimes remote from the counter and the printer is shared by all
counters (there is only one back-office printer per branch, even in the largest
branch). Further analysis is required to segment the Branches, consider the
realisable benefits and set those against the costs of appropriate printing facilities
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 54
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
3.2.14.1 Outline Solution Design
Until further analysis is concluded, it is not possible to present a meaningful proposition
that could be adjudged beneficial.
3.2.15 Project 16 - Local Destruction of Stock
Currently, all unused value stock is returned for central destruction. It is recognised that
the business driver for the Stock Management function, is to reduce operational costs in
the Transaction Stock and Value Stock operations. This project has been designed to
further reduce these costs by
implementing system controls to o~
support the reduced reliance on central i Cleat iE
stock destruction process and to -
enable at least partial local destruction
of Value Stock. The feasibility of the
project will be dependent on the view
taken by Post Office on risks and
liabilities associated with making such
a facility available to Branches.
TF ‘suas
It is proposed that this project
introduces a counter transaction to
record that value stock had been
destroyed locally. This capability will be supplemented by central monitoring, based
on reports constructed within the MIS.
3.2.15.1 Outline Solution Design
The paper within this project is that a new button will be provided on the counter,
which enables a “Remit-out to bin”. Any security / authorisation is assumed to be
handled by business processes and checks within the Financial and MI systems.
3.2.15.2 Sizing and scalability
No implications.
3.2.15.3 Security Approach
The provision of the facility will need to be accompanied by an audit process, using
teports from the Financial and MI Systems.
3.2.15.4 Resilience requirements
No specific requirements have been identified.
3.2.15.5 Operational requirements
No specific requirements have been identified.
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 55
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
3.2.15.6 Expected Deliverables
3.2.15.6.1 New or Enhanced Functions
Component Description
Counter
Support for new “Remit-Out to bin” function
MIS
Local Stock Destruction Reports
Table 10 — Project 16 Functions
3.2.15.6.2 New or enhanced Interfaces between systems
None.
3.2.16 Project 17 - Debt Recovery Case Management
This project has been designed to
further address the business priorities in
and requirements around Debt A Chea
Recovery. These requirements have
been partially addressed within
projects above (see Sections 3.2.4 &
3.2.5). This project will provide
mechanisms to support Case
Management within Debt Recovery.
3.2.16.1 Outline Solution Design
With only skeletal requirements
available from the initial analysis it is
assumed that the Customer Service Management (CSM) functionality in SAP will be
sufficient to satisfy the case tracking requirements. The proposed facility is aimed at
providing a system to monitor debt recovery cases and to provide a repository of
information to track the status of each case.
3.2.17 Project 18 - Ref Data Process Improvements
This project aims to deliver a process
improvement by achieving a closer ee
inter-working between the currently
separate teams within Post Office and
Fujitsu Services, which manage the
Reference Data within their separate
domains. The paper is to create a single
team environment, thus reducing
© 2003 Fujitsu Services Ltd Commercial in ¢
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
overlap in the Reference Data verification processes and speeding up the propagation of
reference data changes from creators to the ultimate consuming systems.
3.2.17.1 Outline Solution Design
This project is a business process change and may not require any additional systems
support. A merger between the Post Office Ref Data systems and the FS RDT rig will
be assessed as part of this project.
3.3 Overall Solution Considerations across Projects
3.3.1 Financial System Overview
The Financial System, which will be implemented, will be a SAP system, including the
following modules: FI-GL (General Ledger), FI-AR (Accounts Receivable), FI-AP
(Accounts Payable), CO-PCA (Profit Centre Accounting, CO-CCA (Cost Centre
Accounting). This is described as the ‘Light’ option as it does not hold product level
information.
The objective is to minimise duplication of data and produce financials based on a
single data source. The recommended architecture involves the integration of the
Horizon EPOSS solution with an SAP R/3 back end financial solution and with MI, the
latter meeting the management information requirements needed to manage the
business. (It should be noted that for management information, an option of utilising the
SAP/BW module is presented in Section 7, however, further study of BW viability to
support the required data volumes is required, and hence the MI based solution is the
one assumed at this stage).
The advantage of the proposed architecture is that management reporting is based on
information, which is closely linked to financials, but the volumes and processing of
data will not affect the utilisation of the Financial System. The ‘reporting engine’ will
be a separate entity from that supporting the financials.
Rationale behind the model:
= The assumption is that there is no reason to fundamentally change the present
separate system designs in the Cash and Stock Management (SAP ADS) area
(however there are detailed changes required to the SAP ADS functionality as
described in various projects). The front-end systems will not fundamentally change
and will feed the necessary information into the SAP financials and into MI or BW.
= The Branch reporting on a daily or ad hoc basis will be produced from the system
within the Branch. This will provide daily operational activity in order for the
Branch to be able to manage their business. The branch ledger will be recorded in
the SAP Financial System to get an overall view of the Branch position.
= There will be a transition to an end state, which will involve a change in source of
some of the management information and also the reference data requirements.
These are seen to evolve during the course of the implementation.
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 57
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
= The creation of branches as individual profit centres and the use of MIS or
optionally of SAP’s Business Warehouse are integral to the design. The
presumption is that the Sales MI system will be enhanced to provide whole office
views for individual branches, and integrated views of multiple branches.
Alternately, Profit Centre Accounting (CO-PCA) could be implemented in BW but
there are concerns about sizing/capacity. Further analysis is required in this area.
See Section 7 for the optional SAP BW proposition.
The key elements of the new model:
m The single source of data from Horizon will produce reconcilable summaries, via
Transaction Management, back to the transaction data before posting to the
financials.
= Transaction ‘drill down’ will take place in the Transaction Management system
(subject to the constraints described elsewhere), as the information in the financials
will be at a summary level.
= BW/MI will be the source of management accounting information based on a
summarised data stream from Horizon and the Transaction Management system.
= The inventory volumes used for risk management will need to come from a separate
‘stock management’ system, as the financials will not hold the balances for stock at
item level.
= SAP accounting model:
c Branches will be set up as:
¢ Profit centres in order to account for individual branch activity in total
© Cost centres as in ES-FS, for cost assignment. This will be in line with the
ES-FS model in order to facilitate integration
o The Agents will be set up as:
¢ Customer accounts to account for debts outstanding and for logging of debt
collection items identified through discrepancy correction notification.
o Clients will be set up as:
e Vendors to give an open item ledger against which to pay clients and also to
monitor total Post Office liability.
The system will be hosted on a dedicated Open Systems server running under the
Solaris operating system. Data storage will be on EMC disk arrays.
The normal way for managing change for SAP is to have a set of three interconnected
servers:
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 58
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
Development Test Live
‘System ‘System ‘System
Figure 6 - SAP Deployment
Any changes are passed through from the Development System, through to the Test
System and then onto the Live System in a controlled manner.
The SAP system supports a number of interfaces:
= Bulk Interface to / from other Systems
These interfaces are provided by means of reading / writing files in well known
“interface directories”. The format of such files will be defined as part of the design
process, however the format is expected to be XML.
a Interface to external SAP Systems
SAP provides a mechanism for exporting / importing information directly to / from
external SAP systems.
= Interactive Interface to support users
SAP provides a Client application that can be deployed on users’ PCs that supports
access to those SAP functions to which that user is entitled.
= Support /Management Interfaces
All changes made to the SAP system are fully audited.
Financial Data (including the audit data) is held within the Financial System for 3
months after which it is archived off to the Archive System. It should be noted that
archived documents can be viewed and printed, but not amended, and this enables on-
going viewing of these documents even though they have been archived.
3.3.1.1 Interfaces to/from the Financial System
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 59
FUJITSU
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
Ref: BD/PRP/011 Version 1
Interface
Comments
Project
1
Transaction
Management to Finance
Cash & cheque transactions only
e Daily summaries created and posted
to the ledgers
e Specification of the interface to be
established
NB
Cheques out of branch to EDS built into
interface
Discrepancy transactions picked up at this
point although not delivered to SAP ledgers
until later project
SAPADS to FI/CO
Extend interface from project 1 with SAP.
ADS as the source (like a branch)
Bank to FI
Receive bank statement to ledger
« Assume one bank account
NB The bank statements need to be
processed in both the new and legacy
systems
Assumptions:
EDS processing & onward cheque
management needs further investigation, but
can be automated if required.
Interface uses same method as in project 1
i.e. via Transaction Management
Data migration - assume opening balances
are declared cash to the nearest date to
migration and the balance is then derived
from the further transactions to the close
date.
Error handling from
branch declarations
Inbound handling of errors generated by
branch declarations identified by
discrepancies between derived and declared
positions (cash and stock)
Outbound error
notification
Outbound error notification for adjustment to
Horizon transaction flow. Further analysis is
needed to determine whether workflow is
required or not
Assumption
Rota checks - identified errors generated
from MI will be processed manually into
financials
Inbound Client
transactions
Inbound accounts payable transactions to
create the client ledger documents
Inbound Client
settlement details
For client settlements made on client data
where there is an automatic and validated
data stream. This interface will create the
posting of cash in accounts payable and
generate a payment run to BACS. The
transactions will need enough data to be
able to perform an automatic matching with
ledgered items. The functionality will need
to be confirmed.
© 2003 Fujitsu Services Ltd
Commercial in Confidence Page: 60
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FU ITSU Ref: BD/PRP/011 Version 1
Project Interface Comments
5 Outbound BACS Standard SAP functionality to produce the
payment file outbound BACS payment to the bank
(assume one bank).
5 Finance to ES-FS. Interface to transfer all ledgered items to ES-
FS automatically (currently manual)
5 Assumptions Data migration assumed to be year end
close balances at 31/3 — details to be
confirmed with POL
7 ‘Stock Ledger’ to Fl Interface of stock movements (not by
product) to the stock accounts in POL
Ledgers
7 Assumption The information source is SAP ADS or
equivalent stock management system
8 Wash up items Branch debt items which are processed in
ES-FS should be interfaced to the POL
Branch Ledgers to give a full Branch liability
view. Care should be taken in the book-
keeping for these items to ensure that they
are not duplicated when the interface to ES-
FS in project 5 is run.
Other items that have not yet been identified
in terms of current CBDB interface
requirements. These are not known.
8 Assumption All purchasing is processed to the ledgers
through ES-FS as current and the complete
POL ledgers can only be seen in ES-FS.
Table 11 — Outline Financial System Interfaces
3.3.1.2. Reference Data Considerations
Items to consider Comments
Branch existence and maintenance Effective dates
Branch hierarchies (type — managed or agency) Effective dates
Chart of Accounts
Client accounts (Accounts payable master data) Effective dates
Product information and product hierarchy (SAP heavy Effective dates
option only)
Client to Product mapping (not in SAP ‘Light’)
Terms of payment
Table 12 — Reference Data for Financial System
3.3.2, Approach to Satisfying Non-Functional Requirements
3.3.2.1 Auditing and Archiving
It is assumed that the current Audit and Archive policy will be retained, namely:
e Any data passed to an external system will be audited
© 2003 Fujitsu Services Ltd
Commercial in Confidence Page: 61
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
e Data for which subsequent audit access is needed will be archived when
immediate access is no longer required
In particular, this means that data passed between systems within the Horizon Domain
will not be audited.
3.3.2.2, Deployment
The new Financial System will be deployed on Open Systems Solaris Platforms in the
existing Fujitsu Services Data Centres. Data storage will be on EMC disk arrays.
The MI System will be moved into the existing Fujitsu Services Data Centres, thus
eliminating the need to transport the all Transaction details outside the Data Centre.
3.3.2.3 Systems Management
System management is the provision of the services enumerated below to any platform
in an integrated remotely managed solution that is sympathetic to any special needs of
the infrastructure (for example scalability, lights-out operation, security threats) and
also minimises direct personnel costs. The following are included:
= amanaged framework
= software distribution
= distributed monitoring
= event management
= time synchronisation
= user management
a third line support service
The E2E re-architecting projects require the main solution components to be managed
under the system management scope definition, which is assumed as:
= Transaction Management System
cone or more Oracle applications
o executing on the Solaris operating system
o on Open Systems hardware
o physically situated in the Horizon Data Centre
= Financials System
co aSAP based application with backend data base (Oracle)
o executing on the Solaris operating system
co on Open Systems hardware
o physically situated in the Horizon Data Centre
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 62
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
The new solutions will be bought under the existing enterprise wide management
solution that services the Horizon Data Centre and Post Office counter estate. The
design maximises re-use of the existing investment in software, people and process.
FIS
Enterprise
Management
‘Transaction
Processing
Financials - SAP
Figure 7 — Systems Management Architecture
Figure 7 shows the re-use potential from the existing Horizon solution in:
= Open Systems components
= Oracle database products
= Fujitsu Services Enterprise management
Once the full requirements for the E2E are analysed, the existing management facilities
will be reviewed to determine whether their functionality needs to be enhanced to
satisfy all the attributes of the Transaction Management and Financials Systems.
The new platform for financials is SAP R/3. SAP, as an application environment, is
supplied with built-in component for system management, called Computing Centre
Management System (CCMS).
Each required system management service at the enterprise management level will be
carried through to the SAP environment directly using CCMS components or
configuring (appropriate to the SAP environment) and invoking existing Horizon
Solaris management agents to give the most cost effective and pro-active end to end
solution.
The service design will cover at least:
= Derivation of product components for each service at each level (hardware, OS,
application)
© 2003 Fujitsu Services Lid Commercial in Confidence Page: 63
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
= Configuration of product component to match operational, security requirements
and host characteristics
= Integration where appropriate into the existing Horizon bespoke management layer
= Test on rigs representative of final solution
= Upgrade of operational process and procedures
The main work will be in incorporating the SAP systems. Existing Host support will
also be extended within this program.
3.3.2.4 Resilience
Our understanding is that the current Transaction Processing and Financial Systems
(OPTIP and CBDB) have a 48 hour recovery requirement met by a 3“ party DR
contract.
However, current Horizon systems have full resilience with the ability of a standby host
at the other data centre being able to take over the work of a failed host within about 4
hours. This is supported by the use of Mirrored EMC disks across the two sites, with
tape backups being taken automatically using BCVs to reduce the system downtime.
Given the low cost of disk storage, it is proposed that this mechanism is also employed
for the new Transaction Management and Financial Systems.
3.3.2.5 Testing
Each element of the new solution will be tested independently based on their interface
specifications. Testing up to the service boundary between Fujitsu Services and Post
Office domain is assumed on the basis of DIT testing at the boundary. If further end to
end testing is required, this will need to be specified and costed.
3.3.2.6 User Administration / Access
There will be a large number of users for the Financial System (up to 400) who will all
need to be managed. In particular, these users will be resident outside the confines of
the existing Horizon Data Centres and so will need to have their access into the Data
Centre securely managed.
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 64
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU aren ae
Royal Mail
Central
Postmaster Systems
Remuneration
Royal Mail
Terminals
Figure 8 — Post Office Interconnection
The assumed responsibility for managing the users is split between Fujitsu Services and
Post Office as follows:
e Fujitsu Services Responsibility
o Manage Central Systems
o Create Power Users within Accounting and Transaction Management
that will be capable of creating end users within these systems.
o Manage Communications between Horizon Data Centre and Post Office
Network
¢ Post Office Responsibility
o Manage User Terminals and Environment
o Inform Horizon of new / deleted Users and their Roles within those
managed by Fujitsu Services
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 65
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
o Create end users within the Transaction Management and Accounting
and manage the assignment of these users to the roles provided by the
system for business users
3.3.2.7 Security
To ensure that end users accessing the new back end systems from within the Post
Office Domain do not have access to the secure Horizon environment, the application
servers for these systems will be placed in a separate protection domain with limited
access into the main Horizon protection domain.
3.3.2.8 Training
It is assumed that training will be provided by Post Office.
No specific Training Facilities are to be provided by Fujitsu Services.
4 Migration Activities
The delivery of the End-to-End re-architecting programme will comprise many
activities. The following subsections define the key activity areas and propose effective
approaches for their delivery.
4.1 Migration Principles
The Post Office businesses identified and quantified a number of key business benefits
during the course of the Requirements Capture activities conducted as part of the End-
to-End Feasibility Study. Subsequent analysis identified a number of potential projects
that would individually deliver to the Post Office the capability to realise these target
benefits. Working with the Post Office project team, the projects profiles were further
refined and a potential delivery schedule identified, taking into account the inter-
dependencies between projects and legacy systems that are to be replaced. The
resulting programme is described in this paper. It has been specifically designed to
provide Post Office with a phased introduction of benefits, structured to balance
business needs with investment constraints that require both an early return on
investment and a modest cash flow exposure.
The adoption of natural service boundaries enables a simpler testing regime to be taken.
Reconciliation activities are now focussed on the external boundaries to Post Office
businesses, removing the requirement to support reconciliation across contracting
boundaries that are internal to Post Office.
The resulting programme schedule is presented below in the context of the existing
Horizon release schedule, as requested by the Post Office project team. It has been
assumed that the back-end components of the solution proposed by Fujitsu Services can
be developed independently of the Horizon Counter Release Schedule. Therefore it is
expected that there will be opportunities to further refine the programme scheduling.
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 66
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
4.2 Project Dependencies
Interdependencies between the projects in the proposed set are shown in the chart below
(Figure 9). The design of the proposed release phasing has taken these
interdependencies into account.
The remaining projects, which are not subject to these dependencies, can be
implemented independently, namely:
a Reference Data improvements
a MIS - Basket Analysis
a Cross-selling prompts
a HTML Help
a Printing of Virtual Stock
a Local Destruction of Stock
These remaining projects, for which interdependencies do not exist, have been
positioned within the proposed release schedule according to the current understanding
of the business requirement and the implied development implications.
Automatic Jy Automated
Remittance of Frate Ledgering
Cash Pouches I) Reporting I_ for Cash/Bank
Automatic
Consolidation Of
New Debt
Recovery
Mechanisms
Introduction:
OfNew Ledger Enhanced Ledger
System System
Better Ovemight Branch Liability
Management
Timely and
Accurate Ledgers
Increased
Accuracy
Branch
Stock Reporting
Automatic
Consolidation Of
Stock Position
Improve Stock
and
Cash ManagementI
Stock Management
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 67
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
Figure 9 — Project dependencies
4.3 Migration Phasing
Taking into account the principles and project dependencies detailed above, Fujitsu
Services propose the following phasing of the project activities:
1. Business Process Analysis and Design (see section 4.4)
2. Horizon Release S60
Containing
= E2E Release I - Creation of cash/bank ledgers reporting cash/near cash
positions at branches and cash centres based on new Post Office
Financial system
= Sales MI system feeds replacing TPS to OpTIP feed
= Exploitation of HTML help at the branch
Note: Although it is not viewed as being a release dependent project, it is
envisaged that Reference Data Process Changes to remove duplication of
data entry and verification across Post Office and Fujitsu Services can be
completed within the Release 1 timescale to reduce operating costs
3. Horizon Release S80
Containing
= E2E Release 2
e Creation of branch, client and stock ledgers on new Post Office
Financial system
¢ Creation of Branch Liability Management capability
e Stock Inventory Management
= Basket Analysis MI reports (if carried out by Fujitsu Services)
= Cross-Selling prompts at branch
= Capability for local destruction of stock at branches
4. Horizon Release S90
Containing
= E2E Release 3
¢ Finalisation of ledgers on new Post Office Financial system
e Simplified & Improved Transaction Processing
© Debt Recovery case handling
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 68
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
= Branch P&L MI reports (if carried out by Fujitsu Services)
= Capability to print stock at branch (if a viable business case can be
made)
Note: The project phasing presented is based on the assumption that Fujitsu Services is
the prime contractor for this work and that it is conducted under the Joint Working ISL,
as defined in the Agreement, enabling overlapping stages of work during the
Requirement Analysis and Solution Specification Stages
4.4 Business Process Analysis and Design
The feasibility study, of which this paper is one of the deliverables, needs to be
followed by full analysis of the business and technical requirements in those areas
where Post Office agrees to undertake transformation projects:
a Overall business process design — to set the context within which new or
enhanced systems will support the business
Q Detailed business process and business data definitions — in specific areas where
automation and system support will be implemented
It is recognised that, in several areas, new business processes and practices are being
introduced and the lack of previous experience of such processes can make the design
and analysis task difficult and protracted. Therefore, we propose that Post Office, with
assistance from Fujitsu Services analysts, establishes an E2E demonstrator system,
using the facilities of the Horizon Architecture Lab, to rapidly prototype key aspects of
the solution and thus provide the stakeholders with a visualisation environment to
quickly identify the optimal solutions. This paper assumes that this visualisation work
will form a significant part of the Requirement Analysis “Start Up” activity detailed in
Schedule 12 of the Agreement to enable continuity of work pending the outcome of
Post Office review and approval of the Feasibility Study findings
The Business Process definitions will be documented using the System Architect tool,
outputs of which can be shared between Post Office and Fujitsu Services. These models
will become a key part of Conceptual Design documents, which will also capture key
functional and non-functional requirements for the systems that are to be delivered.
4.5 Design Proposals
To achieve the required timescales, S60 and project 5 will need to be progressed at
pace. In particular, the solution design will need to be developed in parallel with
requirements. There are also pressures on S80 and dependencies are set out in
paragraph 4.8.
4.6 Business Case reviews
It is anticipated that Post Office will review the Design Proposals against the original
business cases, to confirm the commercial viability of the proposed solutions. Where a
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 69
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
business case may not remain strong enough, the design and associated requirements
will be jointly reviewed to identify any opportunities for improvements.
4.7 Roadmap Plan
The requirements identified to date are scheduled as transformation projects and shown
in the Gantt chart embedded below. Indicative costs contained within this document are
based on this timetable. Fujitsu Services has assumed that Post Office will authorise
Fujitsu Services work at an uninterrupted pace in order to achieve the proposed
schedule.
FB)
E2E FS Plan VO3.4
4.8 Dependencies on Post Office
The scheduling of the End-to-End Transformation projects detailed in the Roadmap
(section 4.7) and the indicative costs detailed in section 5 are based on the following
dependencies on Post Office:
a Authorisation for the Requirements Analysis and Design activities,
detailed in section 5.2.1, to enable work to start by 31% March 2003,
proceeding under joint ISL;
a Active participation of Post Office business domain owners in support of
the Requirements Analysis and Design and subsequent Release and
Project activities, in particular to enable sufficient requirement detail and
solution definition to be produced to enable development work on the
End-to-End Release 1 Transformation Projects (section 5.3) to
commence by 5" May 2003;
a Authorisation for the End-to-End Release 1 Transformation Projects,
detailed in (section 5.3), to enable development work to start by 5"" May
2003;
a Authorisation for the End-to-End Release 2 Transformation Projects,
detailed in (section 5.4), to enable design work to start by 2" June 2003
and development activities to commence in early August 2003;
a Authorisation for the End-to-End Release 3 Transformation Projects,
detailed in (section 5.5), to enable design work to start by 1‘ December
2003;
a The Advanced Data Capture aspects of the AP Enhancement
requirement are implemented and funded by the Change Programme (i.e.
not the End-to-End Transformation Programme) prior to commencement
of the implementation stage of Release 2 (section 5.4);
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 70
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FU ITSU Ref: BD/PRP/011 Version 1
a The deployment of Mails to the branch network is completed prior to
commencement of the Cross Selling Project (section 3.2.12) and HTML
Help.
5 Pricing Assumptions for Transformation Projects
The following subsections present the assumptions, which underlie the implementation
costs, of the individual End-to-End Transformation Projects and Releases.
5.1 Principal Assumptions
The principal assumptions used in the pricing approach are listed below. Any project
specific assumptions that have been made are given within the sections containing
individual project costs.
= The project pricing has been estimated based on the release profile detailed in the
Road Map shown in section 4.7 above. In particular, it has been assumed that the
releases in so far as possible will utilise the standard “pre-paid” SI resources
provided for by the Agreement. These cost assumptions will need to be reassessed
if the End-to-End and/or Change Plans schedules are varied;
= Post Office users will access the services provided by the End-to-End Projects
through existing Post Office PC and network infrastructure. User support and client
(i.e. user PC based) software will continue to be procured through existing Post
Office channels and the cost estimates do not include provisions for these services;
= The interconnection between Post Office network and Horizon network exists. Its
capacity has not been assessed and hence any upgrades, should such be required, are
not included;
= Post Office users accessing services delivered by End-to-End Project support
enquiries will continue to be handled via existing support channels. The Horizon
support service will interface to the Post Office user support service provider to
manage service related enquiries relating to services delivered by the End-to-End
projects;
= Post Office will be responsible for management of Post Office user access to
services delivered by the End-to-End projects. Support for 10 administrative Post
Office users will be provided for the purposes of this user management function.
User access to individual services will be password protected and restricted to user
names registered through the user management function;
= It has been assumed that a solution design can be produced to handle the
performance requirements of the End-to-End projects without the need for
upgrading the Horizon Correspondence Servers and/or the Horizon data network;
= It has been assumed that the existing links between Horizon and Post Office data
centres have sufficient capacity to accommodate the access requirements to the
extended Horizon estate, namely: Post Office users, SAP ADS, SAP HR and ES FS;
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 71
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
= It has been assumed that the switch over to the new Financial System will occur
simultaneously across all Horizon branches and that the Cash Account period and
cut-over timing will be aligned to minimise service introduction costs.
Furthermore, the switch over, together with any implied user interface changes, will
be effected by Reference Data;
= It has been assumed that the legacy TPS service will be required to run for a period
of 35 days after the cut-over to the new Financial System to accommodate flow-
through of Cash Accounts from non-polled branches;
= It has been assumed that OBCS support will not be required by the time accounting
switches over to the new financial system implemented by the End-to-End projects.
Should OBCS remain, then the OBCS host and agents will continue to be operated
and a new report will be produced from the OBCS host to provide Client Settlement
information to be loaded into the Financial System equivalent to that being
produced from Transaction Management for other clients. No attempt will be made
to fully integrate OBCS into Transaction Management. No costs for the continued
operation of OBCS or for such developments have been included.
= It has been assumed that the End-to-End projects are implemented without any
requirement for branch site visits by Horizon engineers;
= Data relating to client transactions (existing DRS and APS) needs to be retained in
the new Transaction Management System for the period during which settlement is
finalised. It is understood from discussions with Post Office that this period is a
maximum of 56 days from the date of the original counter transaction;
= It is assumed that delivery of client files to a central point (EDG) will not alter the
current Horizon OLAs for file delivery times and that these times refer to delivery
of the files to the central point;
= No increase in support for litigation investigations has been assumed;
= Ithas been assumed that there will be no additional service level reports produced;
m It has been assumed that there is not a requirement to audit access to the
Management Information service;
= It has been assumed that details relating to Transaction Management service user
sessions will be retained for audit purposes. Audit records relating to the
transaction data held within the service are already covered by existing audit
provisions in the Horizon estate;
= Itis assumed that arrangements relating to Post Office access to audit records are as
detailed in the existing Agreement;
= The level of support required to cover the migration to the new Financial System
and the de-commissioning of interfaces to superseded legacy systems will be re-
assessed during the requirements analysis stage of the programme. The cost
estimates given do not include any incremental costs beyond that normally
provisioned for a system release;
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 72
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
= For the purpose of these costings, it has been assumed that all additional hardware
and SAP licences needed for the Financial system will be assigned by Post Office
out of spare capacity or procured by Post Office. Until the specification of the
hardware platform is known, it is not possible to provide maintenance and support
costs and therefore these are not included in the Fujitsu Services costings. (Should
this assumption be incorrect, an indicative price for a hardware provision to support
the Financial System is given in Section 8);
= Itis assumed that training will be provided by Post Office Ltd.;
= It is assumed that Post Office will provide up to date anti-virus software on all
workstations that access systems within the extended Horizon domain;
= It is assumed that no additional effort is required in monitoring firewall events for
Post Office users;
= It is assumed that no additional penetration testing is required;
= It is assumed that all systems retain the level of security associated with the systems
they replace. In particular it is not assumed that they will necessarily comply with
1SO17799;
= It is assumed that Post Office will lead on any End-to-End testing which may be
required beyond the Horizon service boundary.
5.1.1 Financial System Assumptions
The development of the new Financial Systems will occur incrementally through
several Releases. The following assumptions apply overall to the Financial System
Solution.
5.1.1.1 Solution
The following assumptions are made with respect to the design of the Financial System
in SAP:
= Standard SAP v4.7 is being used
= SAP licenses will be dealt with by RMG directly and therefore this paper does not
include provision for SAP license costs. Examination of existing SAP licenses will
determine how many additional licenses may be required to cover the anticipated
400 named users of the new Financial System
= It is assumed that no server licenses are required by the Post Office, however if on-
going support is required several Basis licenses will be required and this will be
covered by the Post Office
= It is assumed that any on-going maintenance charges relating to additional SAP
licenses will be covered by the Post Office, so the costs have not been included in
this paper
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 73
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
= Standard SAP reports will be delivered, any additional reporting will need to be
considered in addition to this paper
= Volumes will not be held in SAP FI/CO so the source of the information for SAP
HR for Agent's remuneration will come from Transaction Management. Volumes
required for inventory risk management are assumed to come from an inventory
management system, not from the financial ledgers unless the option to implement
Stock Management in SAP is taken.
= Data migration will be limited to opening balances e.g. Cash, Stock and Balance
Sheet, assuming ‘go-live’ takes place over year-end.
= Fujitsu Consulting will utilise off-shore capability for the SAP technical
development in order to reduce the implementation costs
= Post Office will supply super-users to the project full time for the duration of the
project - probably about 10 people
= The Super-users will be responsible for getting approval before the system goes live
in each phase.
= Reference Data interfaces will be addressed during each project
= The costing has been based on projects running parallel over a 23 month period
starting in May 2003 in order to maximise the utilisation of the core implementation
team
= The project phasing has been timed to aim for a year-end phased go-live, if the
timing changes, this may affect the costing because of a heavier data migration
requirement.
= Ifthe phasing of the projects is changed the pricing will need to be revisited.
= Product level detail will not flow through to the financial ledgers except where the
client ledger depends on a separation, as the product level reporting is assumed to
be done from MI.
= Training - End User training and change management will be handled by Post
Office.
= Key users who will become members of the implementation should be sent on a
generic SAP training to give them an overview of SAP and the terminology used.
This training is not included in the current costing.
= Notional branch profitability is currently calculated by the ABC system and the
mechanism for this calculation will not be changed
5.1.1.2 Migration
The following assumptions are made with respect to migrating to the new Financial
System in SAP:
= Cash account closure - cutover needs to be carefully considered and realignment of
period closures should be made and notified to agents prior to final cutover during
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 74
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
project 8 such that there is a clean start to the new accounting solution. This is
especially significant in the discontinuation of the cash accounts and to which
period they report in the final instance before cutover.
= Audited account balances should be passed through to the new systems and the
auditor should be involved in signing off the opening balances before
commencement of the new system. This will facilitate the clean transition to the
new environment.
= It is assumed that any data required for the cutover to the new financial system will
be readily available and will be provided by the Post Office.
5.2 Business Process Analysis & Programme Management
5.2.1 Business Process Analysis & Design
5.2.1.1 Assumptions
Completion of the overall business process map is necessary before the individual, but
linked, transformation projects begin. Only then will a coherent overall context exist
within which each project can be implemented.
This activity will be led by Post Office and supported by Fujitsu Services. It will
commence immediately after submission of this paper to maintain maximum progress
and continuity of the programme.
Detailed analysis of requirements, data structures and business procedures will be
carried out within the individual Transformation Projects and hence the costs for these
are included within the individual project costs below.
5.2.2 Programme Management
5.2.2.1 Assumptions
In accordance with the Joint Working ISL defined in the Agreement, it has been
assumed that Management of the Solution Specification, Solution Build and Test and
Implementation Stages of the End-to-End Transformation delivery programme will be a
Fujitsu Services responsibility. In addition, management resources will be required to
co-ordinate Fujitsu Services work during the Requirements Analysis Stage, Migration
Planning and the transition into the individual implementation projects.
The estimates detailed below cover the period April 2003-March 2005 (inclusive) as
detailed in the Programme Road Map (section 4.7).
5.3 E2E Release 1 — Projects 1, 2, and 3
E2E Release 1 comprises Transformation Projects 1, 2, and 3. The following
assumptions were made within the scope of each constituent project:
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 75
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
5.3.1 Project 1 - Better Overnight Cash on Hand Data Assumptions
= As part of this project, it is assumed that the existing Sales MI system will be
interfaced to an identical feed of information to that provided to OpTIP. It has been
assumed that there will be no development costs associated with the provision of
this feed.
= The “opening cash position” of each branch will be obtained from the branches at a
defined point. Thereafter, ongoing transactions and declarations from branches will
adjust the opening position accordingly. Detailed requirements / design will
determine how a co-ordinated opening position is established and synchronised with
that held in the current system.
= A complete cash position across the estate cannot be guaranteed due to non-polled
branches. It is assumed that the small amount of inaccuracy caused by incomplete
polling is acceptable, since the visibility of actual cash position will be significantly
better than at present.
= It is assumed that Cheque Endorsement is provided as part of the NS&I (phase 2)
changes for S60, and that the Cheque Endorsement functionality proposed for this
project will build upon that implemented for NS&I
= The following assumptions are made with respect to the Financial System:
o All products will be treated in the same way, for the purposes of data feed from
Transaction Management
co Method of payment will be logged correctly at the till
c_ The opening balance will be posted to the new ledgers using the derived cash
position
ca No changes will be made to standard IDOC/BAPI structures for the interface
from Transaction Management
o Transaction Management will provide SAP Business Connector with
information in XML format
5.3.2 Project 2 - Automated Ledgering for Cash / Bank assumptions
= Fund movement information from the banks will be provided in a standard form,
which is compatible with SAP. Such information will be posted to the new
Financial System as well as to the current Systems.
= It is assumed that Post Office has a standard bank account access package and that
Post Office will have the means to transfer the account information to SAP.
= Again, a starting position needs to be obtained for both SAP ADS and the Bank.
= The following assumptions are made with respect to the Financial System within
this project:
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 76
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
co One Bank to interface to the Financial System - additional bank statement
interfaces will require more effort
o Cash in transit between Cash Centres and Branches maintained in SAP ADS
5.3.3 Project 3 - Automatic Cash remittance of pouches into branches
Assumptions
= It is assumed that Inventory Management for Cash is done within SAP ADS.
= It is assumed that there is a simple way of distinguishing Cash Pouches from Stock
Pouches, e.g. by the range of bar codes used
= It is assumed that if Delivery Notes are not available overnight, that they are made
available in sufficient time to avoid the need for additional communication
connections between branches and the Data Centre.
= It is assumed SAP ADS would want a Delivery Notification returned when Cash is
Remitted-In. Alternatively the initial Delivery Notification could be delayed until
the goods are Remitted-In. NB it is likely that if the Delivery Note is not in the
outlet, then any Delivery Notification will be unable to get to SAP ADS
= The following assumptions are made with respect to the Financial System within
this project:
c Pouch confirmed at branch only on Horizon receipt
o Every pouch is bar-coded & scanned before goods issue from SAP ADS
o LFS automatic messaging to and from SAP ADS to branch
o All cash accounting between cash centres and branches will be done in SAP
ADS including cash in transit
co CFF continues to be used for Cash-flow Forecasting - the information available
should be more accurate, having implemented projects 1 to 3.
o If CFF relies on the declaration information by denomination, the accuracy of
this flow is dependent on the business process for declaring cash. If the
accuracy of this information is to be improved, it will require a business process
change to gather >50% of declarations each night. However, a more accurate
total cash position is available from the new Financial System. The Financial
System does not hold denominational information or even the split between
coins and notes. If this breakdown is not required in CFF, a feed to SAP ADS
or CFF can be set up to improve the cash flow forecasting. This is not currently
priced in the proposed model.
5.4 E2E Release 2 — Projects 4, 5, 6 and 7
E2E Release 2 comprises Transformation Projects 4, 5, 6 and 7. The assumptions that
relate to the projects are documented in the following subsections.
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 77
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
5.4.1 Project 4 - Branch Liability Management Assumptions
= It is assumed that all Discrepancy Notices will be handled the same way.
= Discrepancy Notices will use memo view interface (i.e. no EPOSS changes
required)
= It is sufficient to distribute Discrepancy Notices no more than once per day, and so
this mechanism is part of the overnight Bulk processing and does not need to be
Interactive
m It is assumed that if an agent rejects a Discrepancy Notice then a different
Transaction is written.
= Transactions are summarised before posting into the ledgers
= Transition from the cash summaries in the Project 1 (see section 3.2.1) to the
complete BLS will not necessarily take place at the same time for all branches.
= A start position on all accounts within the ledgers needs to be derived from the
branch information and aligned with the existing financial systems.
= FS assume that the definition of format and procedures to produce the new Branch
Liability Statement can be easily achieved
= During migration it will be essential to produce and process existing cash accounts
in parallel with the new Branch Liability statement
5.4.2 Project 5 - Client Settlement and Ledgering Assumptions
= Itis assumed that OpTIP can be turned off after this project.
= Itis assumed that CBDB will be made to accept the current OpTIP feed.
m It is assumed that information required by the MI System, currently routed via
OpTIP, will be passed to the MI system directly (prior to OpTIP being
decommissioned)
= It is assumed that summaries of transaction volumes (from the BLS), to be passed to
SAP HR to support Postmaster Remuneration, will be provided by a periodic File
Interface.
= It is assumed that it is acceptable to reduce the holding of old DRS data from the
current 90 days, to the required 56 days.
= Itis assumed that a BACS interface will only need to be set up for one bank.
m It is assumed that SAP HR performs agent remuneration calculations using
transaction volume information provided by the Transaction Management system
and that no additional information needs to be supplied.
= Cost estimates assume that the Transaction Management system has a user
population of 150 users, of which there are 40 active at any one time, generating
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 78
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU vee cea
approximately 1 transaction a second (in total across all users). Usage profile is
assumed to be mixed 60/40 enquiry to update;
= It is assumed that no more than 8 enquiry screens are required
5.4.3 Project 6 - Improved Cash / Stock Management assumptions
= It is assumed that no changes are made to the current mechanism of sending Advice
Notes requesting the return of excess / redundant Stock or Cash.
m The interface for all stock items (i.e. cash, value and transaction stock) will be
provided by SAP ADS. Costs for the SAP ADS extensions are not included in the
estimates provided below;
5.4.4 Project 7 - Automated Ledgering for Stock Assumptions
= It is assumed that the data from SAP ADS will not flow to the ledgers at the SKU
level.
= It is further assumed that SKU level information will be available within SAP ADS
only.
= Stock value will then be managed in the financial ledgers.
= The integration with Horizon SAP ADS may need to be bigger if product
information is required. This is not included in the current costing and will require
inventory management (MM) to be operational in the new system.
5.5 E2E Release 3 — Projects 8, 9 and 17
The E2E Release 3 comprises Transformation Projects 8, 9, and 17. The assumptions
pertaining to the projects are detailed below.
5.5.1 Project 8 - Personal Agent Ledgers Assumptions
= Assume further analysis will be done to determine further requirements in this area,
as the known interfaces to ES-FS have been captured, but no other interfaces from
CBDB have been considered.
5.5.2 Project 9 - Simplified & Improved Transaction Processing assumptions
None.
5.5.3 Project 17 - Debt Recovery Case Management
5.5.3.1 Assumptions
= It is assumed within the design for the Financial System that all purchasing goes
through ES-FS as at present
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 79
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
5.6 E2E — Release independent Projects
The following Transformation projects are treated as independent of the three E2E
Releases above. It is assumed that these will be included within the three release
deliveries as outlined above. Specifically, no additional release costs have been
assumed.
5.6.1 Project 10 - Reference Data Improvements (IT Solution)
5.6.1.1 Assumptions
= It is assumed that the business benefits identified with Reference Data
Improvements can be realised primarily through improvement of the associated
change management processes
= It is assumed that a significant number of the legacy system managed by the current
Post Office Reference Data Systems will be replaced as part of the End-to-End
Transformation Programme. The residual requirement for Reference Data
management within the non-Fujitsu Services estate requires further definition to
enable indicative cost estimates to be produced
= Indicative implementation costs for Reference Data management within the Fujitsu
Services estate have been included in the individual projects based on current
understanding of the requirement
= Itis assumed that the current interface from RDS to RDMC is unchanged as a direct
result of this project (though other projects may well introduce changes to the
interface).
5.6.2 Project 12 - Management Information (local/central)
The target architecture assumes that the MI System is best situated within the enhanced
Horizon domain alongside the Transaction Management System. However, for the
purposes of pricing, it is assumed that Post Office will continue to operate and evolve
the Sales MI system through the present sourcing arrangements. This is because
without carrying out due diligence on the presently deployed hardware and
implementation of the application, Fujitsu Services cannot assess with any accuracy
what steps and upgrades may be necessary to meet the new requirements. Fujitsu
Services will be pleased, if requested, to carry out the due diligence and assess specific
requirements in future, as there are expected to be significant cost and operational
advantages in co-locating the MIS system alongside the Horizon Transaction
Management System and employing operating and support services already in place in
the manned Horizon Data Centre.
5.6.2.1 Assumptions
= Itis assumed that the data feed to the new MIS will be identical to the feed currently
supplied to OPTIP. Costs for this feed to the MI system are included in the Project 5
proposal
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 80
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
5.6.3 Project 13 - Cross Selling
5.6.3.1 Assumptions
= It is assumed that Post Office are responsible for supplying approved text for Cross
Selling prompts with appropriate product associations through the use of Reference
Data
= System test and release costs are dependent on the composition of the target release,
which has not been determined at this stage. These costs are therefore not included
in the estimates provided
= It is assumed the present Item Structure mechanism in Type A Reference Data can
be extended or exploited to designate the relationship between the products that can
be cross sold
5.6.4 Project 14 - HTML Help
5.6.4.1 Assumptions
= It is assumed that Post Office are responsible for supplying approved text for use in
HTML Help
= System test and release costs are dependent on the composition of the target release
which has not been determined at this stage. These costs are therefore not included
in the estimates provided
= It is assumed that the HTML mechanism will be built on top of the structures being
set up for Mails, and that the Mails programme provides for the management of its
HTML help data
5.6.5 Project 15 - Printing of Virtual Stock
5.6.5.1 Assumptions
a Insufficient requirement details have been provided to cost this project
= The costs associated with improving the printing facilities in all the branches
outweigh benefits associated with this project
5.6.6 Project 16 - Local Destruction of Stock
5.6.6.1 Assumptions
= It has been assumed that Post Office will introduce strong business process support
to address authorisation, verification, audit and related requirements and that these
processes will not require system support other than the functionality detailed in
section 3.2.15 above;
= It is assumed that existing mechanisms, such as Advice Notes or Memos, are used
to instruct the postmasters that stock should be destroyed.
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 81
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU vee cea
= System test and release costs are dependent on the composition of the target release,
which has not been determined at this stage. These costs are therefore not included
in the estimates provided
5.6.7 Project 18 - Reference Data Process Improvements
5.6.7.1 Assumptions
This project aims to deliver a process improvement by achieving a closer inter-working
between the currently separate teams within Post Office and Fujitsu Services, which
manage the Reference Data within their separate domains. The proposal is to create a
single team environment, thus reducing overlap in the Reference Data verification
processes and speeding up the propagation of reference data changes from creators to
the ultimate consuming systems.
= Post Office will allocate appropriate resources from the businesses to work with
Fujitsu Services to define and implement the process performance improvements
required to deliver the target business benefits
= Delivery of this project will not require changes to the Horizon infrastructure and is
therefore independent of the Horizon release programme.
= Process improvements will be defined and agreed by 30" September 2003 (Row 2
of Agreement Schedule 12 Annex B)
= Process improvements will be implemented and introduced into the operational
service by 31° March 2004 (Row 2 of Agreement Schedule 12 Annex B)
6 Variation of Fujitsu Services Horizon Fees and Charges
The fees and charges in the Horizon Agreement are based on the assumption that
simplifications in the Horizon solution resulting from the End-to-End Re-architecture
programme will result in a reduction in Fujitsu Services costs. The timetable against
which these cost reductions are assumed is detailed in Schedule 12 of the Agreement.
In the event that the dependencies detailed in Schedule 12 are not met due to delay or
failure on the part of Post Office, Schedule 10 defines additional fees and charges that
Post Office will pay Fujitsu Services. This section summarises the status of the
Schedule 12 dependencies based on the findings of the End-to-End Feasibility Study
and the Fujitsu Services Design Proposal.
6.1 SI Commitment Fee and Additional Systems Integration
Charges
6.2 End-to-End
The Variation in SI Commitment Fee and Additional Systems Integration Charges
relating to End-to-End Re-architecture are detailed in Section 6.1.1, Schedule 10 of the
Horizon Agreement. They relate to the objectives described in the first column of the
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 82
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
table in Annex A of Schedule 12 (replacement of current TIP and APS feeds by Single
Data Source and revised accounting methods).
Objective £m £m Status
(p.a.) (Total Contract)
Client business rules based on I0.373 1.867 \Addressed (Projects 1-3)
Trading day (Row 1, Item 1)
Trading day basis of all 10.233 1.167 \Addressed (Projects 1-3)
accounting periods (Row 1,
Item 2)
Branch Liability Statement Row I0.327 1.633 IAddressed (Projects 1-3,4,5)
1, Item 3
Only transaction audit functions I0.233 1.167 IAssumed achieved by Projects
at centre (Row 2, Item 2) 4,5,9 but Incremental cost for new
Transaction Management functions
included in Projects 4,5
‘Standard counter & back office I0.467 12.333 Partially addressed (Projects 1-3).
systems (Row 2, Item 3) Remainder assumed dependent on
Product Re-Engineering (not
laddressed by E2E)
EPOSS2 (Row 2, Item 3, 1) 10.233 1.167 IAssumed dependent on Product
Re-Engineering or major new
counter enhancements e.g. for new
products (not addressed by E2E)
Digital signature removal (Row I0.233 1.167 Not addressed
2, Item 3, 6)
No central Transaction 10.233 1.167 IAssumed dependent on Product
enrichment (Row 2, Item 4) Re-Engineering (not addressed by
E2E)
No Data Warehouse (Row 3) I0.233 1.167 IAssumed will be achieved by
Horizon DW elimination (underway)
- new costs associated with
provision of data feeds to MIS, are
included in Project 5
Reduced Documentation 10.233 1.167 [Assumed addressed by streamlined
requirement (Row 4) processes
Total: £2.8m £14m
6.3 Changes to Requirements and Testing Regime
The Variation in SI Commitment Fee and Additional Systems Integration Charges
relating to changes in the Requirements and Testing Regime are detailed in sections
8.11, 8.12 and 8.13 of Schedule 20 of the Agreement. They relate to an improved
development process that will result in reductions in Fujitsu Services Systems
Integration costs.
© 2003 Fujitsu Services Lid Commercial in Confidence Page: 83
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FU ITSU Ref: BD/PRP/011 Version 1
Objective £m i€m Status
(p.a.) _I(Total Contract)
‘Changes to Requirements and £1.4m_ I£7.0m Action underway for
Testing Regime, including: Conceptual Design and Design
e Conceptual Design and Proposal CCD
Design Proposal CCD by
31st March 2003
e New Testing Regime CCD
by 31%t August 2003
6.4 Operational Charges
The Variations in Operational Charges are detailed in Section 5.11, Schedule 10 of the
Horizon Agreement. They relate to the objectives described in the first column of the
table in Annex B of Schedule 12 (simplification of system boundaries and improvement
of reference data processes).
Objective £m £m Status
(p.a.) (Total Contract)
‘Simplification of boundaries - reduced I0.4 12.0 [Addressed (Project 9)
solution complexity (Row 1)
Improved reference data processes [0.2 1.0 Addressed (Project 18)
(Row 2)
Total: /£0.6m. I£3.0m
7 Proposed Commercial Arrangements
Our proposal for End-to-End re-architecting has been formulated within the commercial
framework of the extended Horizon agreement. The proposed commercial
arrangements exploit the “Working Together” processes and Pre-paid SI resources.
Projects have been "bundled" into three releases. These are arranged to deliver early
wins and are phased to smooth out work for high utilisation of Pre-paid SI.
The scope of the expanded Horizon technical environment, which we are proposing
should fall within Fujitsu Services’ remit, is designed to establish clean service
boundaries, which are optimised for:
= Fujitsu Services' taking of E2E delivery, transition and operational responsibility
and risks;
= Eliminating E2E system and personnel overheads associated with system
boundaries, which cut across business processes.
The indications of prices given in this document are based on the principles and
assumptions set out in the following paragraphs. It has been generally assumed that
Post Office will wish this programme to have first call on Pre-Paid SI.
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 84
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
The cost of hardware for the Financial System is excluded on the assumption that Post
Office may have spare capacity. It is Fujitsu Services understanding that Post Office is
already licensed for SAP software and so no further S/W charge for this is included.
7.1 Lifecycle process
It is assumed that the Joint IS Landscape process will be followed and that no
significant resources or timescales will be expended on competing for packages of the
solution.
7.2 System Integration
Fujitsu Services will be the overall Integrator of the E2E solution up to the point where
there are clean file transfer boundaries.
Fujitsu Services will be responsible for the technical integration and validation of all
application and infrastructure components within the expanded Horizon technical
environment
The expanded Horizon technical environment which best meets the objective of clean
service boundaries comprises:
= Counter systems in Branches
= Communications network between Branches and the Fujitsu Services data centres;
= Enhanced Horizon Transaction Management Systems - dealing with file transfers to
clients, New Financial system, and SAP ADS; on-line transaction processing with
clients’ or agent’s systems (e.g. NBE, Streamline, e-Pay) reconciliation with clients;
and support for Post Office back-office operations (discrepancy
reconciliation/investigation and notifications)
= New Financial system
= Enhanced Reference Data Management Centre (RDMC) addressing all reference
data needs within the Fujitsu Services systems domain
= Logistics Feeder Service (LFS)
= And possibly the MI System, if Post Office agree to transfer the system into the
Fujitsu Services domain and contingent on outcome of Due Diligence
Fujitsu Services will also be responsible for establishing clean system and service
boundaries with systems outside the expanded Horizon technical environment, in
particular with:
= Cash Centre systems (SAP ADS) operated by Business Systems
= Centralised file transfer facility (EDG) operated by Business Systems
a Any new Post Office Reference Data system(s)
= Sales MIS (if remaining outside the Fujitsu Services domain)
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 85
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
Pricing is presented on the basis of T&M. Post Office may wish to add some element
of contingency to allow for possible variances as requirements become clear or Release
dates are adjusted.
7.3 Application Development
Fujitsu Services will be the Application Developer for:
= Counter application
= Enhanced Horizon Transaction Management systems
= Enhanced Reference Data Management Centre (RDMC)
= Logistics Feeder Service (LFS)
Fujitsu Services will subcontract the application development of the New Financial
System within its overall E2E design, and would welcome close inter-action with Post
Office on who that subcontractor should be and on agreement of terms. The baseline
assumption used to estimate costs is that development will be undertaken by Fujitsu
Consulting (a Fujitsu Services sister company) supported by Zenzar (an offshore
development company in which Fujitsu has a significant stake), with additional support
from SAP. The costs shown include provision for managing the subcontract.
7.4 Support and Maintenance
Fujitsu Services will support and maintain all systems within the expanded Horizon
technical environment, ensuring that appropriate back-to-back arrangements are in
place with any supplier/subcontractor.
The proposed solution assumes that users of the Financial and Transaction Management
systems will access them from personal computers managed by Business Systems (or
Prism). Fujitsu Services will seek to reach an agreement with Business Systems for
support of these Post Office users and any application components that need to be
maintained on their PCs. Since the Fujitsu Services solution only requires a SAP Client
and a Browser on the PC, such arrangements should be straightforward, especially as
Business Systems will already be supporting the same SAP Client for Royal Mail
Group.
7.5 Operations
The costs associated with systems and services not included in the existing Horizon
technical infrastructure are identified as incremental charges. They are derived
according to the pricing "rules" set out in the Amendment.
7.6 Service Boundaries
The service boundary is designed to enable Fujitsu Services to take responsibility for
the integrity of complete business process outputs:
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 86
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
= design and development (to API/AIS specifications at the boundary);
= testing and implementation (to DIT testing at the boundary);
= the expanded operations including the Financial Systems
The integrity of the financial and cash information is achieved by applying best practice
perpetual inventory and double book-keeping methods and by ensuring that transactions
always flow from the counter to the financial system without manual intervention or
service boundary.
Data errors caused by system mismatches should be eliminated (except for the case
below) by enforcing consistent end of day cut offs and reversal rules.
Reconciliation of on-line transactions as between transaction log and client/ agent
system will identify transactions which broke or were cancelled after NWB
authorisation (for example) and determine the adjustments which should be made and
by whom (client records, settlement, etc.).
Timing differences due to non-polled Branches will still occur and provision is made to
deal with these.
Post Office personnel may inspect transactions, which are found to have been subject to
EPOSS keying errors (where the value of the transaction is not captured automatically
by the system from a token) and post messages to postmasters to correct such errors.
Post Office personnel may inspect transactions subject to bad debts (e.g bounced
cheques) and post messages to postmasters to either recover or write off those debts.
Alternatively, these messages could be generated automatically according to floor
limits. Trend analysis by Branch could be considered as an additional aid to exception
management.
The need for reconciliation between TPS and OpTIP is rendered redundant and is
eliminated.
8 Possible Alternative Projects
Earlier in the document, alternatives to some of the projects have been identified and
these are outlined below:
8.1 Financial System Hardware Option
A preliminary assessment of hardware requirement to support the Financial System and
the Central Stock Management (see 8.3) implementations and on-going services on
Fujitsu-Siemens platforms running under the Solaris operating system has been made.
This is based on Fujitsu Services current understanding of the scale of the Post Office
requirement. Section 9 contains the summary sizing and hardware description.
The indicative prices are given in Section 10.
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 87
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
8.2. Use of SAP / BW as an alternative for MIS
8.2.1 Reporting from SAP BW
SAP BW is presented here as an alternative to using MI to report the Profit and Loss by
Branch, Client, Product type, etc. This would be closely linked to the SAP financials
and fed by the transaction management system in such a way that reconciliation to the
financials would be much easier than using a separate MI system. SAP BW and SAP
financials would be fed with the same source information with different levels of
granularity.
The objective for this alternative project would be to hold the data in BW in a low level
format for operational purposes for a limited period (e.g. 90 days) and then archive it,
leaving the report information, summarised into InfoCubes for on-going reporting
purposes. This will avoid duplication of the detailed level information and also make
reporting more efficient. The information is summarised into multi-dimensional
InfoCubes which are dependent on the business dimensions e.g. Branch, Client, Product
type, Trading day etc.
Another advantage of using SAP BW to fulfil this function is that any structures e.g.
profit centre hierarchy can be mapped directly between the systems, such that changes
made in the financials will flow through to BW. SAP BW offers a seamless integration
with other SAP components, which enables and simplifies the extraction of business
objects at the application level.
8.2.2 Background
SAP BW is part of the SAP Business Intelligence solution. It delivers enterprise-wide
data warehousing, a business intelligence platform, and a suite of business intelligence
tools. To meet varying needs, SAP BW has three conceptual layers: an operational data
store, a data warehouse, and multidimensional models. These three layers are built on
the SAP BW information model.
Because Post Office will be collecting business information from various sources, BW
can facilitate the integration of that data into one reporting source. BW comes equipped
with various extraction, transformation, and loading (ETL) tools, which facilitate the
inclusion of non-SAP data into the BW system. For POL, the majority of source
information will be provided by from the Transaction Management System. This
information will be brought into BW using Business Application Programming
Interfaces (BAPIs), which will be designed depending on the POL data model.
A data warehouse is designed to optimise queries on large amounts of historic and
granular data, supporting strategic, rather than operational, decision making. An
operational data store (ODS) is designed to support queries on small amounts of
granular data that is updated frequently. It stores detailed data and supports tactical,
day-to-day decision-making. SAP views ODS as a near real-time information
environment that supports operational reporting by interacting with existing
transactional systems, data warehouses, or analytical applications.
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 88
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
The final topology of the SAP BW solution will be dependent on the information needs
of POL. This will require further analysis before the final design recommendation to
address the MI requirements, especially considering those items which are currently
being dealt with in the Sales MI solution e.g. for basket analysis and trend analysis. It is
assumed that this will not be included in this SAP BW solution.
SAP BW provides a flexible approach to data warehousing topology. It provides the
capabilities needed to build and maintain an enterprise data warehouse, and the
technology to support data marts that are closely linked to the central data warehouse.
This coherent topology maintains a clear, enterprise-wide view while it reduces data
redundancy and inconsistency.
The implementation approach by Fujitsu would be to use a ‘TeamSAP’ team along with
SAP to design and deliver the BW solution for POL, given the complexity of the
requirements and current systems. The implementation team would be lead by a SAP
BW architect and the progress of design and implementation would be periodically QA-
checked by SAP Walldorf for tuning the system and ensuring the optimal system
capability is achieved.
It is assumed that the licenses for BW are included in the licensing agreement that
Royal Mail Group already has in place with SAP. Additional licenses may need to be
purchased against this agreement. Costs for BW licenses have therefore not been
included in this estimate.
8.3. Central Stock Management (Value stocks)
It is possible to implement the MM (materials management) module on the same
system as the financials in order to manage stock in the Swindon warehouse. This will
enable the visibility of stock levels and therefore the potential liability for stock losses.
In order to implement this an interface will be required from the existing Warehouse
Management for goods received and sent from the warehouse. The functionality
available within MM standard functionality is described in the following sections.
8.3.1.1 Planned orders and stock replenishment
Central Requirements Planning involves ensuring that articles are available when
recipients (e.g. Branches) require them. The quantities required have to be procured in
good time. The following activities are required:
e Monitoring the stock
e Taking open stock transfer orders of recipients into account
e Creating forecasts
e Calculating requirement quantities
© Creating follow-on documents
e Approvals
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 89
FUJITSU
New Fujitsu Proposal
Ref:
BD/PRP/O11
FUJ00098169
FUJ00098169
21 March 2003
Version 1
8.3.1.2 Stock transport orders
Stock Transport Orders can be used if it is necessary to record the transfer of stock
between sites (Warehouse, Branches) e.g. if those sites are in two different physical
locations in the country, and a formal document requesting the transfer should be sent
to the supplying site.
A transfer to stock in transit is then carried out by the supplying site, with reference to
the PO, followed by a stock receipt in the receiving site.
8.3.1.3 Inventory Management and Logistic Execution
Recording (via interfaces from related systems in Warehouse and Branches) results of:
= Outbound processing
Goods issues for outbound deliveries
= Inbound processing
Transfer Postings
= Other goods movement
= Counting/revaluation figures
8.3.2. Assumptions:
= All purchasing goes through ES-FS as current
= Warehouse(s) system(s) will be able to send required data
= Branch related data would be received from Horizon
This costing assumes Swindon Warehouse only - not Hemel as this is
assumed to be in the RMG domain
9 Sizing Assumptions for SAP R/3
The Following assumptions have been used when sizing the SAP R/3 System.
Selected User Data
R/3 Module INo. Users Grade ‘Sessions
Fl 70I — Light 15
FI 180) Normal 1.5
Fl 60I Heavy) 15
CO 20) Normal 1.5
CO 10I Heavy 1.5
© 2003 Fujitsu Services Ltd
Commercial in Confidence
Page: 90
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FU ITSU Ref: BD/PRP/O11 Version 1
MM 20) Normal 2.0
MM 10I Heavy) 2.0
Selected Transaction Data
Transaction Remark Batch/Direct #/YI #LINESITime
Interval
Reporting PCA Reports IBatch 5000) 10000000:00_ -
18:00
Postings to ClientPurchase Batch 500000000: 1\00:00 -
Ledgers invoice 07:00
‘Client Settlement Outgoing Batch I 36000 1\09:00 -
payments 19:00
Postings FromIGL = accountBatch 1000000000 1\00:00 -
Transaction entries 19:00
Management
‘Client Settlement Outgoing Direct 500 1208:00 -
payments 18:00
From Debtors Receipts —_ofiDirect 5000 12\08:00 -
payment 18:00
‘Stock out fromIGoods out Batch 10000000) 100:00 -
Branch 19:00
Remits intoIGoods Batch 1000000 108:00 -
Branch received 19:00
Disk space is calculated to be 1.5 TB of data, based on a retention period of 3 months.
Further analysis is required to validate the posting frequency and granularity and also,
the frequency of the archiving. The calculation of these figures was initially based on a
combination of the light and heavy options on data processing as noted in the Post
Office document entitled “Granularity of Ledgers”. The light option gave
approximately 600m transactions and the heavy option gave approx. 13.5bn
transactions to be posted to the GL annually. It has been assumed that 1bn would be
closer to the actual postings depending on the final set up and procedures. This will
need to be reassessed once further analysis has been carried out.
These SAP sizing assumptions have led to the following platform configuration
m The Oracle database, which will support the implementation, will be hosted in the
main Horizon Data Centre on an Open Systems 20way 1.3 Ghz Sparc Solaris
platform with 24GB of memory
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 91
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
= This System having 4.5 TB of EMC disc storage attached. 3TB duplexed business
data and 1.5TB business continuity volume, to assist backup
= A smaller DR system with its own 4.5TB of disc storage will be sited in the
Horizon DR site. As a consequence, a reduced service would be offered in the
period immediately following a disaster.
= Fourteen application servers, split between the two sites provide support for the end
users and batch processing.
= An additional tape library will be established at each site to provide back up and
restore capabilities
10 Fujitsu Capability
The E2E programme, as devised, makes available to Post Office a wide range of Fujitsu
Group capabilities.
The Financial System proposal is based on experience and resources of Fujitsu
Consulting, an important member of the Fujitsu family. Application Management for
SAP is proposed to be supported by Zenzar. Hardware sourcing is proposed from
Fujitsu-Siemens.
Fujitsu Consulting (FC)
Fujitsu Consulting with in excess of 700 consultants across 10 countries has been
delivering SAP-based solutions for a number of years, and has recently signed a letter
of intent to become a Global SAP Services Partner. This reinforces the FC
commitment, in every region, to close working with SAP to deliver quality solutions to
their clients and demonstrates the regard that SAP has for the organisation’s
capabilities.
FC has a Fujitsu Consulting Solutions Centre in India, with more than 70 SAP
consultants, from which FC can resource projects to reduce the cost of implementation
and on-going support to UK clients. The organisation in India is IS09001 and RPG
QA certified, and is the first organisation to achieve and enterprise wide SEI CMM
Level 5 Certification.
Fujitsu, through Fujitsu Siemens Computers runs a Global mySAP Competence Centre
at SAP Walldorf, where FC work closely with SAP to develop robust platforms and
new solutions e.g. Mobility.
Fujitsu boasts a Global Technology Partnership with SAP. Once FC achieves their
Global Services Partnership, FC will have both Global Partnerships in place. Fujitsu
will be one of 3 organisations in the world that will be able to make this claim.
Fujitsu Consulting in the UK has a growing SAP delivery capability which consists of
Functional and Technical Consultants who are able to deliver SAP solutions to it’s
clients.
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 92
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
For the Post Office Project FC will resource the implementation with a combination of
local project management, local functional consultants and development consultants
sourced from their offshore centre, who will work locally during the implementation.
Using a combination of ASAP (SAP’s implementation methodology) and Fujitsu’s
Macroscope Methodology, FC are able to implement SAP to a high standard of quality
and proven sustainability.
References:
Fujitsu Consulting in the UK has implemented SAP functionality in various
organisations, including:
¢ Honda Motors Europe (HME). FC extended HME’s SAP system to include
export functionality.
e Fujitsu Siemens Computers (FSC). FC provided a team to implement SAP in
FSC’s UK subsidiary. FC also provided project management for the European
rollout. FC worked in cooperation with SBS (Siemens Business Systems) in
Germany.
¢ Greenfield retail organisation rolling out to the UK on SAP IS-Retail.
« THUS. Scottish telecommunications company for whom FC provide on-going
support and maintenance of their productive SAP environment.
FC has several current projects, which include HME, who have asked FC to return to
implement their European Trading System on SAP and another blue chip
manufacturing company for whom FC are developing their manufacturing functionality
on SAP. FC has also developed a pre-configured solution on SAP, which FC is
implementing in a manufacturing organisation, which supplies the motor industry.
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 93
New Fujitsu Proposal
FUJITSU re
21 March 2003
Version 1
FUJ00098169
FUJ00098169
11 Costs and Benefits
The benefits attributed to each of the projects are cross-referenced to the relevant
section in the Post Office Business Requirements Specification entitled Business
Requirements — End-to-End Re-Architecting Post Office Product, Branch, Client, Cash
and Stock Processes & Systems Feasibility Study, a paper which was published on
21/2/03
The following subsections present the implementation costs together with a cost/benefit
analysis of the individual End-to-End Transformation Projects described in this
proposal. In the context of the cost tables below, the term “Horizon Software” is used
to refer to platform related software (e.g. operating system and DBMS). The term
“Horizon SI” is used to refer to resources used for Horizon application development
and support activities.
11.1 Business Process Analysis & Programme Management
11.1.1 Business Process Analysis & Design
Resource Type Man Days I Estimated
Task Total
Horizon SI 305} £370,840
Additional Resources (Financials) 50 £66,600}
TOTAL £437,440)
11.1.2 Programme Management
Resource Type Man Days I Estimated
Task Total
Horizon SI 1330 £1,152,045]
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 94
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU vee cea
11.2 E2E Release 1 — Projects 1, 2, and 3
11.2.1 E2E Release 1 Costs
COST CATEGORIES CHARGEABL I CHARGEABL
E (One Off) E (pa)
Horizon SI Initial (Devt & Test) £1,303,533
Horizon CS Release £16,950
Horizon SI Ongoing £61,595]
Horizon CS Operate £328
Financials SI Initial (Devt & Test) £1,405,770I
Financials SI Ongoing £378,600}
HORIZON SUB-TOTAL £1,320,482I £61,923
FINANCIAL SYSTEM SUB-TOTAL £1,405,770I £378,600)
TOTAL £2,726,252I £440,523)
11.2.2 E2E Release 1 Benefit analysis
Annual Benefit (from E2E Business Requirements Specification)
£m p.a.
Automated accounting cash 100% of 1.00 = 1.00
deliveries/collections - less write-offs
(3.2.1 benefit 2)
Improved understanding of cash 100% of 040 = 0.40
cycle decreases borrowing costs
(3.2.1 benefit 3)
Improved understanding of cash 100% of 220 = 220
cycle to improve cash flow (3.2.1
benefit 5)
3.6
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 95
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
11.3 E2E Release 2 — Projects 4, 5, 6 and 7
11.3.1 E2E Release 2 Costs
COST CATEGORIES CHARGEABLE I CHARGEABLE
(One Off) (p.a.)
Horizon SI Initial (Devt & Test) £5,147, 164)
Horizon CS Release £223,838}
Horizon Hardware Purchase £576,532
Horizon SI Ongoing £275,005)
Horizon CS Operate £4,102,
Horizon Hardware Maintenance £115,306
Financials SI Initial (Devt & Test) £2,344,280I
Financials SI Ongoing £318,120)
HORIZON SUB-TOTAL £5,947,533I £394,412)
FINANCIAL SYSTEM SUB-TOTAL. £2,344,280I £318,120)
TOTAL £8,291,813I £712,532
11.3.2 E2E Release 2 Benefit analysis
Annual Benefit (from E2E Business Requirements Specification)
£m
Automated order processing from 100% of 040 = 0.40
branch through to cash centre (3.2.1
benefit 1)
Automated order processing 100% of 040 = 0.40
(Transaction Stock) (3.2.2 benefit 1)
Reduction in Hemel costs - 60% of 0.50 = 0.30
headcount (3.2.2 benefit 2)
Reduction in stock specials - 100% of 0.20 = 0.20
transport (3.2.2 benefit 3)
Stock write-offs (3.2.2 benefit 4) 100% of 0.10 = 0.10
Re-engineering of products and 25% of 0.20 = 0.05
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 96
New Fujitsu Proposal
FUJITSU een
FUJ00098169
FUJ00098169
21 March 2003
Version 1
Annual Benefit (from E2E Business Requirements Specification)
£m
forms (3.2.3 benefit 2)
Creation of effective debt 100% of 1.00 = 1.00
management process (3.2.3 benefit
3)
Implementation of new accounting 100% of 0.10 = 0.10
model (3.2.3 benefit 4)
Elimination of legacy systems - 100% of 4.20 = 4.20
OpTIP (3.2.3 benefit 5)
6.75
11.4 E2E Release 3 — Projects 8, 9 and 17
11.4.1 E2E Release 3 Costs
COST CATEGORIES CHARGEABLE I CHARGEABLE
(One Off) (p.a.)
Horizon SI Initial (Devt & Test) £1,797,851
Horizon CS Release £426,203}
Financials SI Initial (Devt & Test) £1,126,882I
Financials SI Ongoing £75,720)
HORIZON SUB-TOTAL £2,224,053I £0
FINANCIAL SYSTEM SUB-TOTAL. £1,126,882) £75,720
TOTAL £3,350,935I £75,720)
11.4.2 E2E Release 3 Benefit analysis
Annual Benefit (from E2E Business Requirements Specification)
£m p.a.
Re-engineering of products and 75% of 0.20 = 0.15
forms (3.2.3 benefit 2)
Elimination of legacy systems - 100% of 130 = 1.30
CBDB (3.2.3 benefit 6)
Elimination of legacy systems - small 100% of 0.70 = 0.70
systems (3.2.3 benefit 7)
Variation in Horizon SI Commitment 50% of 4.20 = 2.10
Fee (3.2.7 benefit 1)
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 97
New Fujitsu Proposal
FUJITSU re
FUJ00098169
FUJ00098169
21 March 2003
Version 1
Annual Benefit (from E2E Business Requirements Specification)
Variation in Horizon Operating 66.7% of 0.60
Charge (3.2.7 benefit 2)
11.5 E2E — Release independent Projects
£m p.a.
= 0.40
4.65
The following Transformation projects are treated as independent of the three E2E
Releases above. The indicative costs presented do not include a provision for release
related system testing and release costs, which would need to be estimated and added to
these costs when the functional composition of the target release is known.
11.5.1 Project 10 - Reference Data Improvements (IT Solution)
11.5.1.1 Costs
Costs have not been provided for this project.
11.5.2 Project 12 - Management Information (local/central)
11.5.2.1 Costs
Costs have not been provided for this project; see 1“ assumption above.
11.5.3 Project 13 - Cross Selling
11.5.3.1 Costs
COST CATEGORIES CHARGEABL I CHARGEABL
E (One Off) E (p.a.)
Horizon SI Initial (Devt & Test) £166,096)
Horizon SI Ongoing £11,733}
TOTAL £166,096 £11,733
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 98
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU
Ref: BD/PRP/011
Version 1
11.5.3.2 Benefit assessment
Annual Benefit (from E2E Business Requirements Specification)
£m p.a.
Creation of product related cross 100% of 050 = 0.50
selling (3.2.4 benefit 3)
0.50
11.5.4 Project 14 - HTML Help
11.5.4.1 Costs
COST CATEGORIES CHARGEABLE I CHARGEABLE
(One Off) (p.a.)
Horizon SI Initial (Devt & Test) £171,941
Horizon SI Ongoing £11,159]
TOTAL £171,941 £11,159
11.5.4.2 Benefit assessment
Annual Benefit (from E2E Business Requirements Specification)
£m p.a.
Conformance - Increased use of 100% of 0.50 = 0.50
prompts (3.2.4 benefit 4)
0.50
11.5.5 Project 15 - Printing of Virtual Stock
11.5.5.1 Costs
Costs have not been provided for this project as it was confirmed as being non-viable,
in its current form, at the 17 March 2003 End-to-End Programme Steering Group
meeting.
© 2003 Fujitsu Services Ltd
Commercial in Confidence Page: 99
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU vee cea
11.5.6 Project 16 - Local Destruction of Stock
11.5.6.1 Costs
COST CATEGORIES CHARGEABLE I CHARGEABLE
(One off) (pa)
Horizon SI Initial (Devt & Test) £244,290
Horizon Software Purchase
Horizon SI Ongoing £14,917]
TOTAL £244,290) £14,917]
11.5.6.2 Benefit assessment
Annual Benefit (from E2E Business Requirements Specification)
£m p.a.
Reduction in Hemel costs - 40% of 0.50 = 0.20
headcount (3.2.2 benefit 2)
0.20
11.5.7 Project 18 - Reference Data Process Improvements
11.5.7.1 Costs
Resource Type Man Days I Estimated
Task Total
Horizon SI 170 £194,240)
11.5.7.2 Benefit assessment
Annual Benefit (from E2E Business Requirements Specification)
£m p.a.
Implement Virtual team (3.2.5 benefit 100% of 050 = 05
2)
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 100
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
Annual Benefit (from E2E Business Requirements Specification)
£m p.a.
Variation in Horizon Operating 33.3% of 060 = 0.20
Charge (3.2.7 benefit 2)
0.70
11.6 Cost Summary
The total set of costs for all the projects addressed by this proposal (excepting the SAP /
BW MIS and Central Stock Management options detailed in section 8 is summarised in
the table below.
COST CATEGORIES CHARGEABLE I CHARGEABLE
(One Off) (p.a.)
Horizon SI Initial (Devt & Test) £10,547,999)
Horizon CS Release £666,991
Horizon Hardware Purchase £576,532
Horizon SI Ongoing £374,409]
Horizon CS Operate £4,430)
Horizon Hardware Maintenance £115,306
Financials SI Initial (Devt & Test) £4,943,532)
Financials SI Ongoing £772,440I
HORIZON SUB-TOTAL £11,791,521 £494,145]
FINANCIAL SYSTEM SUB-TOTAL £4,943,532I £772,440)
TOTAL GROSS PRICE £16,735,053} £1,266,585I
ESTIMATED PRE-PAY £7,129,600I
TOTAL NET PRICE £9,605,453I
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 101
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
Initial analysis of the man power requirement over the period April 2003-March 2005,
during which the Transformation Programme development is assumed to be executed
(see Roadmap in section 4), shows that the achievable utilisation of Pre-Pay amounts to
9,094 man days from a total of 13.455 man days eligible from Pre-Pay. This number
assumes that in any one monthly period a maximum of 70% of the available Pre-Pay SI
will be usable by the E2E Programme. Taking this into account the calculated Net
Price is as shown above. The main assumption in this analysis is that the End-to-End
Programme has first call on Pre-Pay resources.
11.7 Cost Benefit Summary
\Annual Benefit (from E2E Business Requirements Specification)
% £m £m p.a.
Automated order processing from I100% of j0.40 I= Io.40
branch through to cash centre (3.2.1
benefit 1)
Automated accounting cash 100% of I1.00 I= I1.00
\deliveries/collections - less write-offs
(3.2.1 benefit 2)
Improved understanding of cash 100% of I0.40 I= Io.40
cycle decreases borrowing costs
(3.2.1 benefit 3)
Improved understanding of cash 100% of I2.20 I= I2.20
lcycle to improve cash flow (3.2.1
benefit 5)
IAutomated order processing 100% of I0.40 I= I0.40
(Transaction Stock) (3.2.2 benefit 1)
Reduction in Hemel costs - 100% of I0.50 I= I0.50
headcount (3.2.2 benefit 2)
Reduction in stock specials - 100% of I0.20 I= I0.20
transport (3.2.2 benefit 3)
Stock write-offs (3.2.2 benefit 4) 100% of I0.10 I= I0.10
Re-engineering of products and 100% of jo.20 I= Io.20
forms (3.2.3 benefit 2)
Creation of effective debt 100% of I1.00 I= I1.00
management process (3.2.3 benefit
3)
Implementation of new accounting [100% of I0.10 I= I0.10
model (3.2.3 benefit 4)
Elimination of legacy systems - 100% of I4.20 I= I4.20
OpTIP (3.2.3 benefit 5)
Elimination of legacy systems - 100% of 1.30 I= /1.30
CBDB (3.2.3 benefit 6)
Elimination of legacy systems - smallI100%. of Io70 I= Io.70
systems (3.2.3 benefit 7)
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 102
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
\Annual Benefit (from E2E Business Requirements Specification)
%, £m £m p.a.
Creation of product related cross 100% of [0.50 I= I0.50
selling (3.2.4 benefit 3)
‘Conformance - Increased use of 100% of I0.50 I= I0.50
prompts (3.2.4 benefit 4)
Implement Virtual team (3.2.5 100% of I0.50 I= I0.50
benefit 2)
Variation in Horizon SI Commitment I50% of I4.20 I= I2.10
Fee (3.2.7 benefit 1)
\Variation in Horizon Operating 100% of jo6o I= Io.6o
Charge (3.2.7 benefit 2)
Total: 16.90
The following graph illustrates the relationship between projected expenditure (gross
and net) and associated business benefit realisation.
E2E Accumulated Cost/Benefit
70.000
60.000
50.000
40.000
30.000
—@- Gross Cost/Benefit
—m— Net Cost/Benefit
£m
20.000
10.000
0.000
-10.000
sbesasasasas
2005/06 I 2006/07 2009/10
-20.000
Quarters
11.8 Option — SAP Financial & Stock Management System
Hardware
The costs below cover hardware provision for both the Financial Management and
Stock Management systems. This option may be attractive if Post Office intend to
move towards fully Open Systems infrastructure.
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 103
FUJITSU
New Fujitsu Proposal
Ref: BD/PRP/011
FUJ00098169
FUJ00098169
21 March 2003
Version 1
11.8.1 Costs
COST CATEGORIES CHARGEABLE I CHARGEABLE
(One Off) (p.a.)
Financials CS Release £360,382
Financials Hardware Purchase £2,714,671
Financials Software Purchase £58,811
Financials CS Operate £39,753]
Financials Hardware Maintenance £542,934)
Financials Software Support £11,762
TOTAL £3,133,864) £594,449)
11.9 Option — SAP / BW Alternative to MIS
11.9.1 Costs
These costs relate to the option described in section 8. The indicative costs presented
do not include a provision for End-to-End system testing and release costs, which
would need to be estimated and added to these costs when the functional composition
of the target release is known.
The SAP license requirements are assumed to be
covered by existing Post Office/Royal Mail Group SAP licensing arrangements and no
provision is therefore included below.
COST CATEGORIES CHARGEABLEI CHARGEABLE
(One off) (pa)
Financials SI Initial (Devt & Test) £1,422,523I
Financials Hardware Purchase £941,276}
Financials SI Ongoing £242,400]
Financials Hardware Maintenance £188,255)
TOTAL £2,363,799) £430,655
© 2003 Fujitsu Services Ltd Commercial in Confidence
Page: 104
New Fujitsu Proposal
FUJITSU een
2
FUJ00098169
FUJ00098169
1 March 2003
Version 1
11.10 Option — Central Stock Management
11.10.1 Costs
These costs relate to the option described in section 8.3. The indicative costs presented
do not include a provision for End-to-End system testing and release costs, which
would need to be estimated and added to these costs when the functional composition
of the target release is known. The SAP license requirements are assumed to be
covered by existing Post Office/Royal Mail Group SAP licensing arrangements and no
provision is therefore included below. The hardware costs (including on-going
maintenance) are assumed to be covered by the hardware platform arrangements for the
main SAP financial system and are therefore not included in the costs below.
COST CATEGORIES CHARGEABLE I CHARGEABLE
(One Off) (p.a.)
Financials SI Initial (Devt & Test) £528,950)
Financials SI Ongoing £151,440]
TOTAL £578,950) £151,440
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 105
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/O11 Version 1
12 Glossary of Terms
For readability, an effort was made to limit the usage of abbreviations. Where these are
used, they are generally explained; however, in diagrams and where brevity was
preferable abbreviations do appear.
ACT Automated Credit Transfer
AP Automated Payment
APS Automated Payment Service — an existing Horizon facility, will
continue as part of Transaction Management
BACS Banking Automated Clearing Service.
BACS Ltd. — The company that owns and operates the
automated clearing house that processes Direct Debits and Direct
Credits on behalf of the UK banks
BAPI Business Application Programming Interfaces (SAP’s tool for
data integration with systems external to SAP)
BCV Business Continuity Volume. An EMC Facility for taking
backups of data with minimal downtime.
BLS Branch Liability Statement
BW Business Warehouse, SAP’s integrated MI system.
CBDB Counters Business Database - Existing Post Office system for
managing financial information
CCMS Computer Centre Management System
CFF Cash Flow Forecasting
CLASS Existing System (part of CBDB) — Counter Ledgers and
Settlement System, to be replaced by new financial system
CO-CCA SAP Cost Accounting Module - Cost Centre Accounting
CO-PCA SAP Cost Accounting Module — Profit Centre Accounting
cs Correspondence Server
CSM Customer Service Management
DB Data Base
DBMS Data Base Management Software
DR Disaster Recovery
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 106
FUJITSU
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
Ref: BD/PRP/011 Version 1
DRS Data Reconciliation Service — an existing Horizon facility to be
expanded to form the basis of Transaction Management
DTI Department of Trade and Industry
EDG Enterprise Data Gateway — existing Royal Mail Group facility
for data transmission (to clients)
EMC American Corporation which manufactures highly resilient, high
volume data disk storage systems
[Also Electromagnetic Conductance when used in context of
testing systems for emitted radiation]
EOD End of Day
EPOS Electronic Point Of Sale
E2E End-to-End
ERP Enterprise Resource Planning
ES-FS Enterprise SAP Financial System —existing Royal Mail Group
system
FI-CO SAP Finance Module Cost Accounting
FI-AP SAP Finance Module Accounts Payable
FI-AR SAP Finance Module Accounts Receivable
FI-GL SAP Finance Module General Ledger
FJ Fujitsu
FJS Fujitsu Services
FTMS File Transfer Management System
GL General Ledger
HTML Hyper Text Mark-up Language
H/W Hardware
IDOC Intermediate Document (SAP’s tool for containing data for
delivery to/from SAP)
IS/IT Information Systems/Information Technology
LAN Local Area Network
LFS Logistics Feeder Service
MIS Management Information System
MI Management Information
© 2003 Fujitsu Services Ltd
Commercial in Confidence Page: 107
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/011 Version 1
MM Material Management
MOP Method of Payment
MSU Management Support Unit (within Fujitsu Services, Customer
Service)
NBE Network Banking Engine
NS&I National Savings and Investments
OBC Outlet Business Change
OBCS Order Book Control Service
ONCH Ovemight Cash Holdings
OPTIP Existing Post Office system - Operational Transaction processing
system, to be replaced by Transaction Management
Os Operating System
PCA Profit Centre Accounting
PIVOT Postmasters Information — Volumes of Transactions (POL)
POL Post Office Ltd
PO-FS Post Office Financial System
Prism CSC led consortium bidding for RMG Outsource
QA Quality Assurance
RDDS Reference Data Distribution Service (Fujitsu Services)
RDMC Reference Data Management Centre — existing Horizon facility
RDS Reference Data System - Existing Post Office system
Riposte Product from Escher Group, part of Horizon solution
RMG Royal Mail Group
SAP Systeme, Anwendungen, Produkte in der Datenverarbeitung AG
(a German software manufacturer)
SAP ADS SAP Advanced Distribution System
SAP BW SAP Business Warehouse — SAP supplied component
SAP FI SAP Financials
SAP HR SAP Human Resources support system within Royal Mail Group
SAP R/3 SAP Enterprise Resource Planning package
SI Systems Integration
© 2003 Fujitsu Services Ltd Commercial in Confidence Page: 108
FUJ00098169
FUJ00098169
New Fujitsu Proposal 21 March 2003
FUJITSU Ref: BD/PRP/011 Version 1
SKU Stock Keeping Unit
SLA Service Level Agreement
SPM Sub-Postmaster
STO Stock Transport Orders
S/W Software
TME Tivoli Management Environment - existing Horizon
infrastructure product set, supporting s/w distribution, event
management
TPS Transaction Processing Service — existing Horizon service
TSD Technical Support Desk — existing Horizon support service
UAT User Acceptance Test
VPN Virtual Private Network, security service protecting wide-area
network and also in the local area network within the branches
WAN Wide Area Network
WRDS Warehouse Reference Data System — existing Post Office system.
developed in conjunction with the Sales MI system
XML eXtensible Mark-up Language
© 2003 Fujitsu Services Ltd
Commercial in Confidence Page: 109