Supplementary memorandum submitted by
Accenture (RPA Sub 14a)
Thank you for your letter of 26 May in which
you ask Accenture to provide further supplementary evidence in
relation to a number of questions. I attach a memorandum which
provides responses to these questions.
I would also like to take this opportunity to
emphasize to the Committee the following key points:
— Accenture's involvement in the project
has been to build and maintain to build and maintain a new claim
processing system, known as RITA (RPA Information Technology Application).
— RITA is an important but single piece
of the overall jigsaw to enable the RPA to make payments. There
are a range of other IT systems and business processes which need
to be functioning for the RPA to make payments. Accenture does
not have responsibility for these other systems and processes.
— Accenture has delivered RITA within
the timeframe and budget agreed with the RPA despite a challenging
environment. RITA is functioning as designed and has been in operation
and fully stable since October 2005, which is what was required
from the RITA system to allow the RPA to make payments from February
2006. The RITA system did not "gum up".
As you know, we have provided evidence at different
times to the Committee: in addition to the attached memorandum,
we provided written submissions on 2 December 2005 and 5 May 2006,
oral evidence on 22 May and the corrected transcript of that oral
evidence. Please treat all of this evidence as a whole and the
various components should be read in conjunction with one another.
Accenture remains committed to assisting the
Committee with its enquiry and if you have any additional questions
please do let me know.
1. Any interchange of ideas Accenture had
with paying agencies (or IT providers for paying agencies) in
other EU countries (Qq 448-449).
Accenture works with the Department of Agriculture
and Food in Ireland where we have built a number of IT systems
to support the processing of Arable Area Aid, SPS and Forestry
payments. This work commenced in 2001 and is ongoing. The SPS
system was built to support an implementation of SPS specific
to Ireland.
eSpatial is our subcontractor for the work for
the Department of Agriculture and Food in Ireland, providing a
spatial software package (iSmart), spatial software development
expertise and spatial data cleansing. We understand that eSpatial
has had some involvement with other Paying Agencies.
The RPA held a workshop with their Dutch counterparts
in early 2004 to exchange ideas and experiences. Accenture was
invited by the RPA and participated in this workshop. We also
had also some contacts with the Dutch Ministry of Agriculture
between June and August 2004 when it commenced its procurement
of the IT system to support payments to farmers but we did not
maintain our interest in the procurement and did not subsequently
bid.
We have also built the Integrated Fisheries
Information System (SI2P) for the Portuguese General Directorate
of Fisheries and Aquiculture (DGPA). The SI2P system provides
functions including processing of applications for EU fishery
project grant aid and the management of fishing boat licences.
We are not aware of any of our staff having
attended conferences which have discussed how IT could be used
to implement CAP Reform.
2. The dates of meetings between Accenture
and the Defra Permanent Secretaries, and the subjects of discussion
at those meetings (Qq 469-475).
According to our records, meetings between Accenture
and the DEFRA Permanent Secretaries took place on the following
dates:2003: 11 March, 7 November, 11 December 2004: 14 May, 2
July, 20 July, 3 September, 5 October, 5 November, 3 December
2005: 14 January, 2 March, 6 April, 6 May, 13 June, 14 July, 19
September, 18 October, 18 November, 16 December 2006: 6 February,
6 March, 19 April, 22 May.
These meetings were primarily to discuss the
status and progress of the RITA project and to address any key
issues facing the RITA project.
In our communications with the Permanent Secretaries
we did provide updates about the RITA system and highlighted some
factors critical to the RPA getting the full benefit from the
RITA system, and therefore being able to make payments on time.
These were factors that were outside the scope of our contract
and beyond our control and into which we had limited visibility
and we were therefore not in a position to comment on their deliverability
by the RPA (as per our note to Q454 of the transcript of oral
evidence).
3. Confirmation of the date on which it was
communicated to Accenture that the volume of land changes was
significantly higher than was originally anticipated (Q 552).
The increased volume was not formally notified
to us, but in our capacity of Senior (External) Supplier on the
Programme Board, Accenture became aware over time from regular
business reports generated by the RITA system and Board discussions
that the volume of land changes was higher than anticipated and
increasing over time. During early 2005 we noticed the increasing
number of land changes to the extent that we raised it as formal
issue with the RPA in April 2005. In October 2005, we agreed to
the RPA's request to support the outsourcing of land change updates
to a third party.
Neither the January 2003 nor the May 2004 contracts
provided estimated volumes of land changes. These were first provided
by the RPA to Accenture in September 2003 as part of developing
Release 1A (RLR implementation) which went live in September 2004.
4. The specific reasons why the optical character
reader system was not deployed for the 2005 SPS scheme year (Q597-598).
(+Q600)
There are two factors which contributed to the
RPA's decision not to deploy the Optical Character Reader (OCR)
System for the 2005 SPS scheme year.
In April 2003, a technical pilot of the OCR
System was undertaken. Although the pilot was technically successful,
the RPA had concerns over the impact of this technology on existing
business processes and associated risks. The RPA therefore decided
not to take the OCR System forward at that time within IACS, but
it was marked for consideration in a future delivery after the
initial implementation of pre-CAP Reform IACS Support. The CAP
Reforms of June 2003 then caused the programme to be re-planned
and the OCR System was targeted for Release 3.
In August 2004, the RPA and Accenture entered
into a Change Request to increase confidence that Release 3 would
be delivered on schedule, in time for SPS 2005 processing. This
included splitting the Release into Release 3A and Release 3B.
The OCR System was moved to Release 3B.
The High Volume Data Capture (in Release 3A0)
facility was introduced through the same change request to provide
data capture support for SPS 2005 within Release 3A.
The OCR System has since been installed in March
2006 for the 2006 SPS scheme year.
5. When the first test on the partial payments
system was carried out to establish whether the interface between
the RPA software systems worked correctly (Q 621). (+Q607-609)
As part of our contractual commitments to the
RPA, Accenture provided a contingency management plan to the RPA
in May 2003 which outlined contingency management arrangements
that Accenture had put in place to manage any potential delays
in delivery of RITA. In line with our normal practice in relation
to contingencies, we advised the RPA at this time to consider
contingency arrangements outside the RITA system.
The first test of the interface between RITA
and the RPA's partial payments system took place in late November
2005. This was the earliest opportunity to undertake this test
using fully synchronised RITA and RPA environments. A further
test took place between 1 December and 7 December 2005.
A final retest of the partial payments system
interface from RITA was undertaken between 11 April and 28 April
2006 following revisions by the RPA to the partial payments approach.
These tests were successful.
6. An estimate of the increased costs associated
with the changes that became necessary as a result of the increased
volume of land parcels and mapping changes (Q 637).
A number of changes were made by Accenture to
the RITA system to address the increased volumes but these did
not result in an increased cost to the RPA.
Additional hardware was purchased by the RPA
from third party suppliers and commissioned into the live RITA
service by the end of August 2005 to provide increased processing
capacity on the RITA system.
7. It might be inferred from your oral and
written evidence (paragraphs 29-30) that the stability issues
surrounding RITA had been addressed by increasing the capacity
of the IT system to allow for more operators to use it at any
one time. It would be helpful if Accenture could confirm this
understanding and also let the Sub-Committee know whether the
system was at any point working to its newly enlarged capacity,
or whether there would have been scope for the RPA to have deployed
more users onto the system to deal with the additional tasks that
were being generated.
The increase in the capacity in July/August
2005 of the RITA system did have a major contribution to improving
the stability of the system and through this enabled the RITA
system to support more RPA users. In addition, Accenture continued
to tune RITA in the live service to remove performance bottlenecks
identified and allow better use of the available capacity, as
is common practice on any new major implementation.
Standard RITA service hours are from 8 am-6
pm Monday to Friday. In order to make full use of RITA, the RPA
requested Accenture to increase the service hours from 6 am-9
pm Monday to Friday and 8 am-6 pm on weekends which Accenture
did at no increased cost to the RPA. In terms of users, in September
2005 for example, the average daily peak was between 850-900 concurrent
RPA users. In October 2005, the average daily peak was above 1,000
concurrent RPA users.
8. Whether Accenture could confirm if the
system for handling claims processing creates a constant log of
the number of claims that are awaiting validation and the number
of tasks that remain outstanding.
The RITA system enables reports to be generated
which provide information about the number of claims awaiting
validation and also the number of tasks outstanding.
Additionally, it allows for provision of information
on the number of fully validated claims and the number of claims
awaiting authorisation that have had a definitive entitlement
established.
As the technology provider of RITA, Accenture
provides a service from which these types of reports are and can
be generated for use by the RPA.
9. Accenture's response to Helen Ghosh's
assertion that it would be "inconceivable" that Defra/RPA
could have "delivered a programme of this scale without an
outhouse partner" such as Accenture (Q 226).It would
be usual to use an external partner for a programme of this scale
for the following reasons:
— The scale of the IT enabled change
programme.
— The complexity of the change programme.
— The skill set required to implement
the change programme which has required RPA to employ other third
party advisors as well as Accenture.
10. Despite the questions already answered
by Accenture on the subject of testing, you may feel there is
something you could add to explain why the elements of the IT
system could not have been tested with real data prior to January
or February 2006 (Q 559).
Each individual RITA Release was tested prior
to go-live in accordance with our contractual obligations.
In November 2005, the RPA requested Accenture,
in a change request, to complete live-data tests. The live-data
tests were outside of the original contractual scope of testing.
The objective of these tests was to de-risk
payment processing by executing the RITA batch processes from
definitive entitlement processing through to the payments interface
from RITA to the RPA payments system (OREGON). These tests aimed
to confirm that the RITA batch processes could run successfully
against live data and to flush out any issues caused by unforeseen
data permutations ahead of time critical live processing by the
RPA.
These tests were conducted from January through
February 2006. They identified issues which were resolved ahead
of the time critical live processing by the RPA. These issues
related essentially to unexpected data permutations.
As the SPS 2005 scheme was new and there were
no historical records or "live data" to use, the possibility
of undertaking realistic live data testing which would provide
more confidence over and above the contracted testing scope was
limited. The tests conducted from January through February 2006
required the use of a recent clone of the live data on the RITA
system. This clone was not available with sufficient quantity
and quality of level 2 validations before this time.Both the testing
of the individual RITA system releases and the live data testing
achieved their objective of ensuring that the RITA system was
stable and capable of making payments, as is evidenced by the
fact that the RPA commenced making full payments on 20 February
2006.
As we made clear during our oral evidence on
22 May, the RITA system did not "gum up" in February/March
2006.
11. It would be very welcome if there was
anything that Accenture could add to help clarify exactly what
a "task" is, how tasks are generated, how they can be
resolved, and the significance to the validation process of having
task outstanding.
The RITA system is built upon a software tool
sometimes referred to as a workflow engine which, at its simplest,
facilitates the movement of tasks through a work process.
A "task" is an item of work for an
RPA user to perform which is created by the RITA system and delivered
to the user electronically. These tasks are generated based on
defined business rules and require specific user actions to resolve
them. That action may, for example, require contact with the customer
that has submitted a claim form or land change. Once the user
has performed the resolving actions, they close the "task",
and the RITA system then progresses the claim to the next stage
at which point a user may be required to undertake further tasks.
For payments to be made, RPA users need to clear
all outstanding validation tasks and authorise a payment. Authorisation
of payments is done in batches of 100 claims, and without authorisation,
no payment will be made.
June 2006
| 
