FUJ00119600
FUJ00119600
ICL PATHWAY LTD - BA/POCL/ICL REVIEW
draft 3.3
1 Introduction
ICL is pleased to respond to the request for our input to the HM Treasury Expert Panel.
In preparing this paper we have considered the outstanding issues, as we see them, in accordance with the terms
of reference of the Panel and these issues are summarised below. [We have also considered a number of lesser
issues, which although current and pertinent, are within normal expectation and management scope of a project of
this scale and are in process of resolution. For completeness we have listed these in Appendix A and will be
happy to discuss these further if required.]
We have structured this paper into Sections covering Design, Build, Finance, Operate (DBFO) and Programme
Management, recognising the PFI nature of the contract, and address each in turn,
ICL’s role is essentially that of the service provider, with a process chain beginning/ending with over 300 Post
Office clients including BA, through POCL to millions of UK citizens and businesses, with complex interfaces,
processes, and business rules. It is therefore key to recognise the importance of End to End Management
arrangements and Programme Planning disciplines and controls.
We have sought to comply with the Treasury's injunction not to focus on the question of who is to
blame for the delays to date. However we naturally stand by the views we have expressed on this issue
which were in our opinion largely borne out by the PA Audit Report of September 1997.
DN: Suggest replace para 4 with the following:
“ICL’s role is essentially to provide a service which will enable the automation of all transactions that
go across the Post Office counters. The POCL network serves the needs of over 300 clients and
28million customers per week. This service involves a process chain with complex interfaces,
processes, and business rules. It is therefore key to recognise the importance of End to End
Management arrangements and Programme Planning disciplines and controls.”
2 Design Phase2.1 Introduction
This phase extends from the solution design through to the development, testing and release of the contracted
Services. Three releases have been made, the last, Release 1c, in November 1997. This provides a Benefit
Payment Service (BPS) and an Order Book Control Service (OBCS) and runs over a comprehensive
infrastructure which includes an ISDN network, a production-level data centre and a full set of supporting
services including Card Production and Help Desks. Release 1C is currently paying Child Benefit to 28,000
customers and checking in excess of 100,000 order books per week.
Release 1c was limited to 205 outlets because the full level of security specified was not available at that time.
Pathway believes that Release le is capable of handling in excess of 2000 outlets. [more -me] It has proven to be
stable in live use and has experienced no fraud. The Release 1c systems were the starting point for succeeding
design phase work.
The Design Phase will be concluded by the development and delivery of two further releases:
¢ New Release 2. - scheduled for Live Trial in January 1999 and the start of National Roll Out in April 1999.
This release will be subjected to formal acceptance.
Treasury/draft33.doc 1 29 April 1998
CONFIDENTIAL
FUJ00119600
FUJ00119600
© New Release 2+ - the scope has been agreed between ICL Pathway and Sponsors although the detailed
contents and timescales are to be defined. This release is targeted for July 1999 and will be used for the
majority of National Roll Out. It will also be used for completing acceptance.
New Release 2 provides further required extensions to BPS and introduces EPOSS (Electronic Point of Sale
Service) and APS (Automated Payment Service). It also delivers a higher level of security specification and
audit functionality and is configured to support the complete Post Office Counters network of circa 19,000
outlets.
The development of the business functionality is now complete, except for a small number of EPOSS
enhancements due in early May, and is under test. To ensure the availability of New Release 2 well before the
required date of January 1999, ICL Pathway has been working to an internal date of early October 1998. Some
difficulties have been encountered in testing, specifically with the Reference Data/EPOSS mapping, and a five-
week impact is forecast against the October date.
Planning to produce a Horizon Programme Plan in support of a January 1999 Live Trial between ICL Pathway,
Horizon and CAPS is well advanced. The resultant Pathway element of the plan will contain sufficient
contingency to derisk the Live Trial date.
The scope of New Release 2+ has been agreed through joint ICL Pathway/Sponsor workshops. A plan of work
exists to complete the contents definition of the release at which point [WHEN?] the actual planned date for
delivery will be identified.
The Benefit Payment Service is now fully developed except for Soft EVP (Extended Verification Process using
rule-based techniques) and On-Line Enquiries. OBCS is complete.
Requirements work for Soft EVP is complete and design is in progress. On-Line Enquiries (On-Line access by
CAPS to Pathway’s systems for payment and Card status) is planned to be implemented in NR2+. If volumes of
traffic at NR2 increase[ to what] above a defined level, then Pathway will seek to implement this facility as a
maintenance update to NR2.
Therefore there is now very little risk that suitable business functionality for DSS will not be delivered on time or
will fail to meet the specification.
[DN: better description of design/development status of O/L enquiries required.]
2.2 Design Phase Issues
As with any major development activity a number of previously unforeseen issues have occurred, the status of the
more significant of these is given below.
2.2.1 Issue 1. Reference Data and EPOSS [ta to reword and shorten]
The EPOS Service is not directly implemented, but is required to be parameter-driven as much as possible
through Reference Data. This data therefore includes information such as the structure of the POCL
organisation, (¢.g. its regions and POCL’s own Clients), the accounting rules (c.g. the mapping of transaction
data to accounting lines), the “look and feel” of the EPOSS MMI (Man Machine Interface e.g. icons, menu
hierarchies and report layouts), and product processing information (c.g. identities, prices, methods of payment,
validation rules and token handling).
Because much of the detailed functionality of EPOSS is, in effect, contained within Reference Data, the contract
level of specification is open to a range of detailed interpretations. To objectify this detail Pathway and POCL
agreed to develop the Service through prototyping - always, however, within the constraints of the functionality
specified in the contract. This activity identified many issues related to the automation of existing business
processes and took much longer than planned.
Such data is very complex and far-reaching in its effect and must be subject to rigorous change control from the
POCL business through to the outlets. Management attention has been brought to the issue to ensure that all
parties understand the significance of Reference Data and are implementing the business change processes
required, both during the test stages and live running. There are currently no EPOSS functional non-compliances
but POCL is concerned that further issues may be identified later in the testing cycle and there may be
insufficient time to resolve them.
Risk: [ ta ]
Resolution: [ ta]
i
Treasury/drafi33.doc
CONFIDENTIAL
29 April 1998
FUJ00119600
FUJ00119600
Related documents: EPOSS Functional Specification and EPOSS Issues List
2.2.2 Issue 16. FAD Code - ICL Pathway need for a unique identifier for a Post Office Outlet
The unique identities of post office outlets are defined, in specifications under Change Control between POCL,
DSS and ICL Pathway, in the form of POCL’s Financial Accounting Division (FAD) codes. POCL has indicated
that it may wish to change their usage as part of a major business reorganisation. {DN check pointers} If this
were to occur then Pathway, POCL, DSS and, we believe, such POCL Clients as British Gas would have to
change their systems in concert. Changes to Pathway’s product base and support for sponsor business processes.
would be fundamental: POCL has introduced a 10-digit random number into reference data to represent the
outlet but all systems already depend on the 7-digit FAD code which contains the post office’s parent region.
Pathway’s systems are designed to allow for the maintenance of post offices identities up to a annual limit of
2.6%, I aeo??I provided this is reasonably phased, and are capable of handling the anticipated changes from
openings, closings, mergers, relocations, and status changes (¢.g. Branch to franchise). The systems depend on
discontinued codes not being reused foreseeably. The redrawing of regional boundaries for example which
entailed wholesale immediate reuse of the same codes would be unsupportable.
Discussions have taken place at the working level but without a firm resolution being found. The issue has been
escalated to senior management in POCL to seek firm assurances that any changes in FAD code usage would not
interfere with its continued use as the unique outlet identifier.
Risk: [me ]
Resolution: [me ]
Related documents:
2.2.3 [TO ANNEX] Issue 1
The RCD has been negotiated over a period of months. It represents a balance between the principle
enshrined in the Final (Drop Down) version of the contract that not all functionality will be delivered in
the first general release and the concerns expressed by sponsors as to those features and functions they
were prepared to live without for a period. The inability to deliver all functionality in NR2 timescales is
the continuing absence of a firm specification baseline for such functional areas as EPOSS, audit, Smart
AP, soft EVP, and mobile configurations, on top of only recently resolved Agreements to Agree with
respect to on-line CAPS facilities (not required under the contract to be in NR2 but nonetheless
included in order to address BA’s operational needs) and a large number of change requests which have
destabilised the design baseline more generally. Despite this the technical content of the release, as
defined in the RCD, has been agreed at the programme level.
The Authorities have indicated their willingness to sign off the RCD, but only subject to a number of
conditions. Although represented as ‘without prejudice’, these amount to new contractual limits and
restrictions on ICL Pathway’s degrees of freedom under the contract. For example, unless NR2+ passes
Acceptance within 3 months of start of Rollout, Rollout would have to cease at that point. A sudden
stop of this nature would in practice require a notice period, reducing the Rollout period still further.
Limitations to BA revenue guarantees are also sought. ICL Pathway formally rejected certain of these
conditions on 27" March and await the Authorities’ response.
Risk: Without a formally signed off RCD, ICL Pathway is proceeding at its own risk on the
development of NR2. Any subsequent changes, due to lack of sign off, will lead to schedule slip.
Resolution: Formal sign-off of the RCD.
Related documents:
DELETED
3 Build Phase
31 Introduction
Having developed and tested the systems and processes to automate both Horizon and the DSS payment
authorisation and card management services, the challenge is to achieve a rapid and even rollout of post office
Treasury/draft33.doc 3 29 April 1998
CONFIDENTIAL
FUJ00119600
FUJ00119600
infrastructure and cards to BA customers. Such a rollout is not assured, either with respect to the post office
estate or card enablement. Both are subject to critical dependencies which lie more in the POCL and BA domains
than within Pathway’s.
3.2 Build Phase Issues [If to reword
3.2.1 Issue 6/7: Suitability of individual post offices for automation
Experience with preparing the existing 205 Post Office outlets for automation and detailed joint surveys of a
representative sample of 100 outlets have identified significant issues and costs associated with automating the
Post Office estate. Joint actions taken by POCL and ICL Pathway have not been able to mitigate these costs
although the agreement of a Rollout strategy and two part 39 week preparation process mitigates the impact on
achieving the required rollout beat rate of 300 outlets per week, at least initially.
Of the 100 representative outlets surveyed against the recently issued health and safety guidelines, only a small
proportion are amenable to automation without significant work. The implications on both cost and time are
substantial. The outcome of this survey was:
Category A (no modifications necessary) 3%
Category B (Shelves & stands necessary) 33%
Category C (modifications to counters necessary) 46%
Category D (no solution found) 18%
Pathway has accepted responsibility for ‘optimising’ existing space through use of shelves and stands. This
only solves a third of the problem. We see it as POCL’s responsibility to ensure that sufficient space exists in
post offices to be optimised.
The cost of additional work to achieve ‘sufficient space’ is estimated to be in the range £13m to £20m. POCL
has no budget for such work and has taken the position that ICL Pathway are responsible for full automation
under whatever physical circumstances, a position ICL Pathway has rejected on the grounds that it has no control
over the postmaster or the environment he is prepared to make available.
Risk: The planned implementation beat rate of 300 per week will not be sustained.
Resolution: While a preliminary agreement has been made to allow the Live Trial surveys to proceed, the bigger
issue remains unresolved and it has been suggested that independent arbitration be used to resolve.
Related documents: Letter from Tony Oppenheim to David Miller dated 17" February. 100 Trial Surveys
Report (ref. IM/REP/029, version 2.0, 4/3/98)
3.2.2 Issue 10: In-Office migration [lIf/mc to check]
There are outstanding issues around in-Office migration. There is a practical need to help postmasters move live
data from existing automated or manual systems to Horizon as post offices are automated. This largely revolves
around who undertakes the task and when is it undertaken. The contractual responsibility lies with Pathway.
POCL have staff who deal with postmasters on a regular basis and who are well positioned to carry out this task
using tools provided by Pathway. In April 1997, Pathway and POCL agreed in principle that Pathway would
sub-contract this work to POCL against an estimated cost of £2.2m. Doubts have been expressed by POCL about
the validity fo this quotation owing to a perceived change of strategy for in-office migration. Discussions
continue to resolve this issue but without final agreement, this will soon become an item on the critiacl path, so
early resolution is vital.
Risk: Office automation will be delayed due to no agreement being reached on in-office migration.
Resolution: Reconsider the need to carry out migration outside normal post office opening hours. In most
outlets, workload reduces after 3 p.m. Commercial organisations undergoing major systems change typically
close branches for the day.
Related documents:
3. Issue 23: Pace of Card rollout [If to check,
Treasury/drafi33.doc 4 29 April 1998
CONFIDENTIAL
FUJ00119600
FUJ00119600
The Horizon system involves the introduction of 19 million payment cards to benefit customers. In order to
effectively and efficiently plan the production of cards and the surrounding support processes such as customer
education and training, it is vital that Pathway fully understand the projected pace of card rollout and any
particular variables that may apply. This covers peak volumes, peak variances, seasonal variances and specifics
such as customers of a post office which is installed in January not being card enabled until February (due to
timing of training of BA staff). Moreover it is vital that Pathway is fully up to date on the migration plans for
individual benefits. Pathway believes that all of the above data exists within current plans but this data has not
been shared. The solution was predicated on all benefit types (Child Benefit, Pensions, Income Support, JSA,
etc.) being interfaced within the DSS domain to CAPS very carly in the programme life (Requirement 951 stated
January 1997), the personal data being validated for the purpose of instructing Pathway to issue the cards and
loaded on to CAPS, and the BA regions being trained in the new card based methods of payment. Thus, the
contract allows a lag of six months to complete the rollout of cards following completion of post office rollout.
The contract also includes a daily card issue limit of 66,000 during rollout, which constrains any ‘catch up’ in the
event that card enablement gets off to a slow start.
Risk: Delayed card rollout will cause non- retention of post office clerk training messages, affecting steady state
service and possible need for re-training. There will be an under-utilisation of production capacity, followed by
demand in excess of the 66,000 daily limit ). Customer education will become more complex and costly ).
Peaking and lost training messages will result in higher rate of help desk calls and cost (Pathway responsibility),
putting pressure on help desk capacity and service levels. Not having a reliable prediction of card take-on
volumes makes scheduling difficult and inhibits Pathway’s ability to mitigate its costs.
Resolution: CAPS to disclose in greater detail its current plans for benefit type migration, data cleansing,
personal data record loads on to CAPS, regional training, and its intentions for pilot implementations prior to full
scale card enablement. Joint working and risk mitigation is required to avoid further delays to the programme
driven by the card enablement process. Changes to benefit type migration should be the subject of a Change
Request against the Requirement 951 baseline.
Related Documents: Requirement 951 and related benefit type migration schedule. CAPS Strategy document on
pilots. CAPS Strategy document on implementation.
3.2.4 Issue 31: Accuracy of Benefit Personal Data from CAPS BA’s records of customer addresses need to
be correct for the process to work. A Pick Up Notice is sent to a customer when his first card is ready for
collection at his post office. The PUN needs to reach the customer for bar code security matching to the card: he
cannot pick up the card without it. In addition, the “Extended Verification Procedure’ depends on maintenance of
the correct name and address details, as well as other personal data eg date of birth (as used by financial services
companies generally). If these details are not maintained correctly, the customer will be rejected under EVP
procedures and his card impounded. He will then need to go to a DSS office, have his details updated, obtain a
temporary token to enable an emergency payment, and have a new card issued to him: this is costly to all
concerned and damaging to customer satisfaction. Finally, if addresses fail Royal Mail’s bar-coding requirements
but are otherwise correct, Pathway faces additional postage costs.
Risk: BA plans to carry out a full scale data cleansing exercise and this is expected to improve the quality of
addresses. The problem arises where customers move house within a district and do not change nominated post
office, or where the nominated post office is close to work and the customer moves house. In either case, with
BA’s knowledge requirement currently being confined to nominated post office, there is no natural feedback loop
to ensure that BA data is kept up to date. BA’s target accuracy is 94%, which if realised would still result in some
4000 customers a day not receiving PUNs (6% of 66,000 card issues). [Since PUNs are only issued for the first
card, how are we affected by change of address within a district? Have I missed something?IThis would put great
stress on DSS offices and encourage the BA to slow down card issue pending a more satisfactory confirmation of
personal details. The result would be delay to completion of card rollout as xxx above.
Resolution: Joint DSS/ Pathway discussion to find a means to secure BA data checks, eg. a tear-out slip in Order
Books.
Related documents:
4 Operate Phase
41 Introduction
Treasury/draft33.doc 5 29 April 1998
CONFIDENTIAL
FUJ00119600
FUJ00119600
The programme has already successfully introduced three releases of the Horizon system into live operation. The
first release, known as 1A (or IGL - Initial Go Live), ran from 23 September 1996 for 15 months and piloted the
use of Payment Cards with more than 1400 customers at 10 post offices in the Stroud area. The second release,
1B, introduced the Order Book Control System (OBCS) at a further 195 post offices in the North East and South
West of England and ran from May 1997 in parallel with 1A. The current product, 1C, was released in November
1997 and introduced the Benefit Payment Service (BPS) at the 195 1B post offices and upgraded the 10 1A sites
giving 205 post offices with 354 counter terminals delivering OBCS and BPS. By the end of March 1998,
162,352 payments with a total value of £4,748,355.76 had been processed by the Horizon system. In excess of
100,000 order books are being checked each week through OBCS and [xxx] Books stopped and impounded.
Successive releases have achieved stable and reliable operation in progressively improving timescales and both
internal and independent sources concur that the system has achieved a high degree of acceptability both from
post office staff and their customers. Feedback is regularly sought from post office staff with respect to the
quality and effectiveness of helpdesk and field support services and shows that these services consistently win
their approval and acclaim.
Although current transaction volumes are orders of magnitude smaller than the future steady state product
transaction volumes, the service patterns of behaviour to support them are now above the critical mass required
for successful scale translation. Indeed, the limit of 205 post offices supplying Child Benefit payment and OBCS
would seem to be unnecessarily restrictive. Release 1C and its underlying support services and processes are
capable now of delivering multiple benefit payment types to, say, 2000 post offices. This would represent a more
statistically significant sample of operational working with the benefit of a wider diversity of end-user and
customer responses and criticisms from which to learn and ultimately secure further improvements in steady
state. At the same time, there would be increased opportunity to combat fraud through wider use of OBCS.
4.2 Operate Phase Issues
4.2.1 Issue 30: Training & Turnover Training
Pathway have the responsibility to train 72,000 staff and agents on the Horizon system. This will involve
each trainee undertaking a competency test. There is a concern around the capacity of all sub-office staff to
take on board the training and the subsequent use of the Horizon system. This is borne out by experience
with Release 1C in the 205 offices.
POCL have the responsibility for turnover training (once the initial 72,000 are trained). The approach
proposed by POCL is that POCL will train staff and sub-postmasters ‘on the job” in a business as usual way
but will not administer competency tests. Sub-postmasters’ assistants will be trained by the sub-postmaster.
The turnover rate for sub-postmasters” assistants is currently c. 17%. Over time, a significant percentage of
agents staff will not be competently trained to use the Horizon system.
Risk: Longer queues, an increase in transaction times, a knock-on effect on customer service and an
increased level of calls to the Pathway help desks.
Resolution: POCL to accept that not all current staff will be capable of operating in an automated
environment and have contingency actions in place. This will necessitate speedy resolution of any such
situations that arise. POCL to accept that all users of the system will need training to ensure competency and
efficiency at the counter and that a competency test should still be administered during steady state.
Related Documents: Training & User Awareness baseline document, version 2.2, dated 26/03/98, ref:
BP/TRN/OO1 ; Release 1C turnover training strategy document, version 1.0, dated 16/1/98, ref.
PIT/ICSTRAT
5 Programme Management
5.1 Introduction
Since the PA Audit Report in September 1997 the arrangements for Programme Management have been
substantially overhauled. The replacement of the PDA with a strengthened team within POCL, led by
an Horizon Programme Director as a POCL board level appointment, with the implementation of
clearer lines of management and communication is causing beneficial change. In particular the tighter
Treasury/drafi33.doc 6 29 April 1998
CONFIDENTIAL
FUJ00119600
FUJ00119600
linkages envisaged between Horizon and Pathway are already beginning to happen in areas of testing,
programme planning and implementation.
However, it will take time for the new arrangements to bed in and the management processes to mature.
Further it is yet to be proven that the programme management arrangements will remove the “agendas
in conflict” root cause identified in the PA audit report as affecting programme delivery.
5.2.1 ___ Issue 15 Schedule Slip [me to reword]
Pathway has been working to an internal date of 5" October for the availability of New Release 2 for
live use. All parties accepted this as a challenging date. The start of Live Trial was set as January 1999
due to perceived risk to the 5 October date.
Risk: ICL Pathway’s schedule has recently suffered a five week slip due to problems encountered in the
early stages of testing. As a result, there is no longer a three-way (ie POCL, CAPS, Pathway) plan that
supports a Live Trial starting in January 1999.
Resolution: Complete existing planning exercise between POCL, CAPS and Pathway to produce a
plan in support of Live Trial in January 1999.
Related documents:
5.2.2___Issue 27 Absence of Horizon Programme Plan [Master Plan]
The last Master Plan produced for the Programme was in March 1997, Since then a drafi has been
produced in March 1998 but this is not yet agreed.
Risk: The absence of a live Master Plan poses a risk as no single plan exists that captures key dates
and dependencies from the individual plans produced by CAPS, POCL and Pathway.
Resolution: Subsequent to the planning exercise identified on 5.2.1 above, produce and agree a
Horizon Programme Plan.
Related documents:
5.2.3 Issue 29. Sign off [mc to reword]
Many documents critical to Pathway’s design have been subject to significant delay. It is nonetheless a
fact that unless critical documents are dealt with in a timely manner commensurate with the rapid
turnaround implicit in the original contract, delays will continue to occur.
Such documents include change control notes, agreements to agree matters, and acceptance
specifications.
: Delay to document review and sign off will lead to schedule slip of NR2 and/or NR2+.
Resolution: Documents to be reviewed and signed off to required timescales.
Related documents:
6 Finance
61 Introduction
A PFI with a short operating franchise relative to the scale of the initial design and build investments is bound to
be very sensitive to delay. This programme is no exception. Because revenue is only earned on service delivered,
delay reduces operating revenue and increases design and build costs. The resulting adverse cash flow increases
the cash call and financing costs.
Banking arrangements of some £250m were put in place last year against the then cash forecast. Fujitsu will stand
behind its existing commitments. These will suffice for 1998 but will no longer finance the whole of the build
phase. The absence of a viable business case acts as an inhibitor to attracting the additional funds required.
Treasury/drafi33.doc 7 29 April 1998
CONFIDENTIAL
FUJ00119600
FUJ00119600
6.2 Spend to date and committed
Approximately £150m has been spent by Pathway to date, mostly on the Design phase, with another
£100m committed by firm orders. In addition, a further £250m of cost will be incurred to complete the
Build phase, plus interest costs. The majority of the balance (o go is contracted for and is subject to
cancellation charges. Cancellation charges would apply also to the Operate phase.
6.3 Cash requirement and business case
The current cash forecast, depending on the assessment of risk, is that the cash requirement will peak at between
£400m and £450m. Some £200m of additional funds will be required over and above currently committed
facilities. The maximum cash exposure occurs towards the end of the Build phase. The actual peak cash
requirement will depend on any additional slippage and also the attribution of costs from the issues list
highlighted in this paper. Delay impacts cash and profit by at least £10m per month of delay.
As a critical mass of transactions begins to flow, charges to POCL and BA increase to approximately
£175m per annum based on forecast volumes. The operational service becomes profitable and generates
cash. The transaction volume and hence the level of profit and cash generation depends critically on
whether BA make a concerted drive for ACT or because delays to the automation programme lead to a
loss of POCL’s market share with its other clients. The volume guarantees and the absolute price per
transaction both fall over time, such that achieving only the guarantees would result in a barely
profitable steady state operation.
Depending on the level of risks to timescales, costs and revenues, aggregate losses of between £200m
and £300m are now predicted, but would be significantly greater if volumes were to fall towards
guaranteed levels. Pathway retains the volume risk and expects to have to perform well in order to drive
the higher volumes.
64 Charges to BA and POCL,
Charges to BA/POCL to September 2005 are expected to be in the range £600m to £1.0 billion (to May
2005 in the case of BA) depending on volumes. These charges are net of remedies assumed in respect
of failure to achieve contracted service levels. Reconciliation and fraud risk transfer costs are included
in the operating cost projections.
The split of charges in steady state is expected to be roughly:
e £102m for the Horizon counter service, of which:
- £32m is BES related, declining to £28m (to DSS account, via POCL)
- £70m is in respect of other POCL clients, increasing to £74m
e £75m for PAS/CMS declining to £65m (directly to DSS account).
The changes over time (from 2000 to 2005) reflect the mix shift from BA business to other clients/new
business and also year on year price reductions of 3% per annum. Volumes and added value of non-BA
transactions will grow as new products are introduced and existing products re-engineered.
1 Summary and Conclusions
7.1 ICL firmly believes that the Horizon Programme is deliverable and that the business imperatives
can be met. These imperatives include not only the facilities and services required by BA, resulting
in substantial savings in fraud and in administrative costs, but also those required by POCL’s other
clients who account for the majority of Counter Transactions,
7.2 The technical issues are well understood. The remainder of the design and build can, ifall agree, be
completed on the basis of teamwork involving all three parties. Once full scale roll-out begins then
ICL can (assuming the commercial problems caused by the delay and by the numerous revisions in
the development phase are resolved) build, finance and operate a world-class system.
7.3 ICL has been in discussions with Ministers and officials in DSS,DTI, HM Treasury and Cabinet
Office regarding potential new applications of the system. Pathway has designed the system to be
Treasury/drafi33.doc 8 29 April 1998
CONFIDENTIAL
FUJ00119600
FUJ00119600
capable of delivering new facilities to BA and other government clients, such as Social Banking,
ISAs, Stakeholder Pensions and Better Government (government.direct).
74
The limited roll-out in 205 Post Offices is working well and Ministers and officials who have seen
the system demonstrated have been impressed - ICL would be pleased to extend this invitation to the
Panel. We are prepared (if the commercial problems are resolved) to continue to devote substantial
resources, including project financing, from the ICL Group to achieve a fully performing system..
7.5 Full roll-out will be complex, demanding absolute commitment from all parties.
7.6 The successful operation of the Horizon system for DSS is dependent on CAPS being completed on
time and operating successfully.
7.7 The 1997 PA Audit Report identified the need for substantial changes / improvements from the
original management arrangements, towards current best practice. This process is under way, but
progress needs to be sustained.
7.8 The Programme brings major new infrastructure and re-engineers processes and procedures within
POCL, DSS and POCL’s other clients. It does this whilst minimising impact on existing customers.
Having achieved automation, the opportunity will now exist to provide new services and choices to
the customer based on large scale infrastructure of network, counters and cards.
7.9 The Treasury's paper asks what would be the extra cost. ICL's need to secure an adequate rate of
return on the capital and skills invested in the programme would not require an increase in its fee
per transaction provided that an adequate extension of the period after the system is fully
operational can be agreed. Given the delays and the extra development work required by BA/POCL
a five year steady-state period is inadequate.
Treasury/drafi33.doc 9 29 April 1998
CONFIDENTIAL