Version 0.5 14 th October 2003

1. HR Shared Services Payroll Operating Model & Interface Architecture ProjectProject Recommendation Version 0.5 14th October 2003 Any comments, recommendations or opinions stated in this document are based on the information provided to Accenture by Lloyds TSBand, whilst Accenture does not have reason to believe that this information is in any way inaccurate or incomplete, responsibility for its accuracy and completeness does not rest with Accenture.

2. Introduction At the end of June 2003 the HRIT Steering Group initiated a project to complete a feasibility study on the replacement of the PANDA payroll system. During the course of the project a number of key decisions were made: SAP was excluded from consideration as a product by agreement with CTO and the Steering Group on the basis of cost and complexity. On the 31st July the Steering Group was presented with the recommendation that Oracle be taken forward to FBC as the system of choice. The Steering Group confirmed this recommendation for the following reasons: CTO review of the proposed architecture for Oracle confirmed it is in line with Group IT strategy of system consolidation. Oracle displayed the highest level of functional fit to defined business requirements; Oracle has much lower cost implications in meeting projected future business requirements than other solutions; The Centrefile operating costs for the Oracle solution are lower than the other solutions; The option of not implementing CentrePay will provide the Bank with flexibility over who provides Payroll services post 2007; Oracle delivers a lower risk solution for resourcing, company stability and future delivered developments; There will be a greater availability of resources for development and ongoing support. In agreeing to the recommendation the Steering Group also recognised that the Oracle solution had the largest upfront build cost. The project is still in the process of completing the detailed business case for the project however work plans including, operating model, organisational design, detailed work estimates and analysis of the current system have all been completed. During early October a series of options for the replacement of PANDA were discussed at length with Bernard O’Driscoll and Igor Andronov. This document proposes a recommendation based on those discussions, the implications of that recommendation and highlights alternative options should the recommendation not be accepted. Background Group HR and Group IT have with assistance from Accenture undertaken a feasibility study to analyse the Operating Model for payroll.

3. Recommendation The Project and Accenture’s recommendation to replace PANDA with Oracle with immediate effect, has been reviewed by Group HR (Bernard O’Driscoll) and Group IT (Igor Andronov) and the resulting recommendations are as follows: Defer the replacement of PANDA with Oracle until there is a clearer business demand Implement this replacement in one 18 month project with a total cost profile of approximately £13.5m Set aside funding of approximately £1m in 2004 to implement risk reduction initiatives around Payroll including: Documentation of PANDA and replacement of contractors with permanent IT staff Introduction in Group HR of a Payroll Management Team (3-4 FTE) Renegotiation of MSL and Centrefile contracts Set aside funding of approximately £4m as contingency should work on replacing Payroll be required in 2004 Establish an annual review by Group IT of the PANDA system to confirm its viability to meet business needs Group IT to transfer skills from Application Management to Application Development in the next 6 months to establish capabilities to deliver Payroll and HR Systems development. Define criteria for the replacement of the Payroll system Review the charging mechanism for PANDA usage These recommendations have been made on the basis that the current service from PANDA , although inefficient, has been stable for the past few years and there is no project, currently identified, which will require significant changes to the Payroll system. In addition the current business climate for investment funding and limited availability of Group IT resources has re-enforced the decision. Executive Summary Although the payroll system has an increasing inability, over time, to efficiently meet business requirements the recommendation is not to replace the PANDA system at this time.

4. Oracle Rationale It has been agreed with Group IT and Finance that moving to an Oracle platform has the following advantages: Group IT endorse the benefits of moving from a PANDA architecture to a more supportable and flexible Oracle based environment delivering greater levels of functionality (See Attachment D). Moving to Oracle now would avoid incremental costs currently estimated to be a minimum of £13.5m by 2010 (see Attachment C). A move to an integrated payroll architecture will also allow the Bank to separate the processing of it’s net pay providing it with additional flexibility and options for renegotiating the payroll outsourcing contract required in 2007. Implications The decision to defer the replacement of the PANDA solution in the short to medium has the following implications: Lloyds TSB will need to take steps to improve application management of the PANDA system. This includes documenting the pay element algorithms, managing staff continuity and potentially increasing staff levels at a cost of approximately £500k; The cost of implementing business changes in PANDA is higher than in Oracle. Delay in moving to Oracle now will increase costs to other projects. Refer to Attachments A and C; The future cost of replacing PANDA will increase due to on-going development and maintenance to the application (i.e. increasing the number of pay elements directly impacts the effort required to transfer platforms); Despite current stability, the risk to payroll operations will increase over time, especially if there are any significant extensions being made to PANDA; Should this option be followed the PANDA system will need to be reviewed annually and each time the Bank undertakes a new project impacting payroll. The replacement of the PANDA system will take 18-24 months to complete Executive Summary Group IT have ratified the recommendation to replace PANDA with Oracle .

5. Alternative Options In addition to the recommendation there are 4 other alternative options for implementing Oracle available to the Bank, should the recommendation be overturned. All figures exclude capitalisation effects which will reduce the revenue requirements but will add risk on the balance sheet. All payback calculated up to 2010 hence delay in implementation means deferred benefits.

6. Option 1 – Immediate implementation targeting a cut-over date of March 2005. This option will deliver the new Payroll system in time for the 2005 tax year end, and would minimise the risk to future developments, but would place a strain on both HR and IT resources. This option would have the following profile: 2004 2005 2006 Cost Design & Build (£8m) Test & Deploy (5.6m) Delivery Options This option will require a rapid ramp up of Group IT resources which will clash with the current scheduled projects for 2004 . • Test & Deploy Includes • 1)  Product Test • 2)  UAT • 2 Operational Parallel Runs • Data Conversion • Deployment Test • Business Readiness • Post go-live support • Design and Build Includes • 1)  Documentation of the Payroll Elements • 2)  Development of coding standards • Design of operating models • Interface design, build and Unit test • Design labs for process development • Technical architecture design and implementation Financials The financial business case is weak requiring £13.6 m1 investment over 2 years with a payback over 7.6 years. This profile requires an investment in 2004 of £8m over the current investment portfolio. 1 The FBC is still to be completed before the financial numbers can be finalised the number is currently +/- 10%. This number includes 20% contingency.

7. Option 2 – Slow the replacement of the Payroll system targeting a cut-over date of March 2006. This option will spread the cost of the implementation, allow the Bank to reduce operational risks first and then begin to ramp up the project whilst maintaining momentum. This option would have the following profile: Delivery Options This option will allow resource challenges to be addressed whilst maintaining momentum but will require the project to be managed over a 2 year period. 2004 2005 2006 Cost Test & Deploy (£6m) Build & Test (£7m) (£3.5m) Preparation for Build (£3m) 1)  Complete of the FBC2)  Run the ITT for an Implementation Partner3)  Ramp up the skills in AD and developing the skills migration plan from AM 4)  Complete the Study Phase includingi)  Implementation Plansii) Test Plansiii) Implementation ToR 5)  Define coding and test standards 6)  Documentation of Pay Elements and Calculations7)  Designoperating processes Risk Mitigation (£500k) 1)  Secure the PANDA resources and knowledge 2)  Implement the Payroll Management team 3)  Renegotiate and redefining the relationship with Centrefile4)  Renegotiate the MSL contract 5) Document the PANDA operations Financials The financial business case requires £16.5 m1 investment over 3 years with a payback over 10 years. This option does however reduce the 2004 investment required to below £4m. 1 The FBC is still to be completed before the financial numbers can be finalised the number is currently +/- 10%. This number includes 20% contingency.

8. Option 3 – Phased release of the Payroll system implementing Pensioner Payrolls in 2004 and targeting a cut over date of March 2006 for the remaining payrolls. This option will spread the cost of the implementation, and allow the Bank to prove the technology and development processes, and declare a success early. This option will have the following profile: Delivery Options This option will allow the declaration of an early win in the implementation of Payroll but will extend the overall development time. 2004 2005 2006 Cost Group Payroll Design Build & Test (£6m) Pensioner Design Build Test & Deploy (£5.5m) Group Payroll Test & Deploy (£5.5m) Phased Release Risk Mitigation (£5.5m) 1)  Establishes technical infrastructure early 2) Tests development processes with a smaller build 3) Facilitates dry run of Lloyds TSB test and acceptance processes with a smaller payroll 4) Facilitates fine tuning of payroll operational model during 2005, thus lowering business change risk for group payroll in 2006 5) Allows Lloyds to attack group payroll with anexperienced team 6) Develops in house Oracle Payroll skills 7) Reduces overall delivery risk profile Assumptions 1)  40 week project 2) 25 pay elements, basic reporting 3) Pension processes and data conversion only 4) Operational model implementation 5) Full infrastructure implementation Financials The financial business case requires £17 m1 investment over 3 years with a payback over 10 years. 1 The FBC is still to be completed before the financial numbers can be finalised the number is currently +/- 10%. This number includes 20% contingency.

9. Option4 – Do nothing This option would only be recommended should the Bank be confident that there will be no future developments on the PANDA system. Delivery Options This option will only be applicable should no future development work be planned on PANDA.

10. Attachment A Business Flexibility Examples

11. Example of where future flexibility will be impaired - Implementation of Business Intelligence and Management Information A key component of the new business strategy is the availability of flexible Business Intelligence. In the case of HR data this will require the manipulation of HR and Payroll data to establish trends and identify risks which the business can then act upon. Examples would include: diversity of bonus and variable pay across the Bank; Overtime costs by pay element and diversity; the correlation of pay and absence trends. Within the current HR systems architecture the synchronisation of HR and Pay data does not exist or is carried out by double keying and interfaces, therefore the data required for reporting is out of synch. To deliver flexible reporting to Line Managers through LMDA requires an interface between HRIS and PANDA.. The cost of this and supporting process changes has been estimated at a minimum of £2.6m. This method would not allow the use of proprietary software and pre-built reporting increasing future cost exposure. Example of where future flexibility has been impaired - Flavours The delivery of flexible benefits highlighted the complexities of developing a reward process on a separate payroll system. Had payroll been delivered through an integrated Oracle solution, the following tasks would not have to have been developed: Interfaces of flex salary (average earnings figure) into HRIS; Flex Salary exception handling processes; A process and system to deal with future pay period transactions (3 interfaces); Payroll and HRIS exceptions process which can impact employee satisfaction. The cost of the additional work required to address these functional gaps has been estimated at £1m. All developments of external systems which require access to Payroll will need to complete these additional build tasks, this is further compounded by the high level of testing required and lack of expertise in the Bank. Attachment A – Business Flexibility

12. Attachment B PANDA Risk Exposure

13. Risk Exposure. High cost of future developments – PANDA's heavy customisation makes any additional pay developments disproportionately difficult and expensive to implement. In comparison with a package-based Oracle solution, it is estimated that over 7 years, the potential cost differential for the same system changes will be approximately £13.5m. Refer to Attachments A and C. Time to replace – Should the replacement become mandatory because of PANDA developing a critical fault or legislation be introduced which it cannot support, it will take 18mths to 2 years to deliver a new payroll solution. Over reliance on manual calculations – The Bank’s evolution since Panda’s implementation has highlighted the functionality restrictions inherent in PANDA resulting in a substantial overhead of manual calculations being required to support the pay process. This contributes to overpayments to employees. Accountability for pay – There is currently no clear accountability within the Bank for the end to end delivery of all processes affecting pay including testing of any developments. Any Business expertise is in the outsourced payroll partner Centrefile or contractors, leaving the Bank exposed to incomplete testing of changes impacting payroll. Lack of data integrity – The division of data between PANDA and HRIS is not clear, with HR and payroll data being duplicated between the two systems. There is no holistic MI information and this contributes to unreliable MI which potentially leads to misinformed business decisions, and exposes the bank to compliance issues with Data Protection Act e.g. Absence Data management Incompatibility of system functionality – The Bank has invested over £14m in HRIS over the last 3 years to deliver advanced functionality in support of processing efficiencies and service improvements. This functionality cannot easily be replicated in PANDA (implemented 13 years ago) for example effective dating, organisational hierarchies and on-line payslips, resulting in both manual and system workarounds. MSL support for Delphi 370 – There are 10 clients currently on the Delphi 370 system, who between them generate only £1.5m in revenue per year for MSL. There is a strong risk that should a number of these clients move away from Delphi, MSL will no-longer wish to extend support. Attachment B - Risks Continuing to run PANDA presents the Bank with considerable increasing risk to a critical process which pays 70,000 employees and 30,000 pensioners over £1.5 billion

14. Attachment C Cost Avoidance Examples

15. Attachment C – Cost Avoidance by moving to Oracle now Acquisitions and Divestments and Pay Restructuring Over the next few years Lloyds TSB will undoubtedly go through a number of acquisitions and divestments both large and small and at least one restructuring of its pay structures. Each time this process is undertaken work is required to either add or remove resources from both the Payroll and HR systems. This can become complex in terms of interface feeds. Following an integrated HR and Payroll strategy will reduce this work effort significantly, requiring changes to be made in one system only. It can be estimated that this will save up to 50% of the data conversion effort for the new acquisition. Using the I&I integration to HRIS as an example this saving could equate to 2,500 days for each acquisition. It can be assumed that integration of this kind will occur at least once every years. This could equate to a saving of approximately £7.5m over 6 years. Implementation of Strategic Business Units Company re-organisations may occur frequently and typically require complex changes to employee hierarchies and cost code structures. In an architecture of separate HR and Payroll systems, changes must be made to both systems and then tested to ensure data is synchronised and will remain so. Reports and views may also need to be tested or altered to allow for changed codes. Within an integrated architecture the level of saving depends on the scale of the change, but work effort will be reduced by as much as 66% due to the absence of an interface between separate systems. It can be assumed that re-organisations will occur at least twice every year, saving in the region of 400 days of work a year. This could equate to a saving of up to £2.5m over 6 years.

16. Attachment D Oracle Functionality Benefits

17. Examples of Oracle “out-of the box” functionality which is of significant importance, which cannot be currently supported by PANDA and which drives up administrative overhead. Effective Dating Under the current process, any pay changes to be made at a future date outside the current period will be processed using a manual process of entering data physically into diaries. This process increases the risk of keying errors. Oracle Effective dating would allow data keying to be spread over the period instead of bunching for specific periods. These benefits can equate to around 10% savings in administration. Automated Retro Payments RetroPay is the Oracle Payroll method of amending employee pay, which has already been paid. The system will allow temporarily rollback and re-process the payroll for the employee assignments identified. The old and new balances are compared and element entries are created in the Retro Elements based on the differences found. The correction of back pay will effect many HR processes. It is estimated by Centrefile that up to 50% of salary changes are received into payroll late. A key user of this process will be the Sellers Back Dated Pay amendments. This process can alter paid salary for more than 12 months in arrears. QuickPay QuickPay provides the ability to carry out payroll processing for an individual employee. This functionality maybe used to process payment for new starters who have missed the cut-off. It may be used to process payment for leavers or hardship cases that need to be processed between payroll cycles. The QuickPay functionality can also be used to calculate how much net pay an employee would be paid, then roll it back to remove all results from the database. Attachment D – Functional Benefits Of Oracle Platform

18. Appendix 1 Work Breakdown Summary

19. Development of Work Estimates Over the period of the last 2 months the project team have worked closely with a large number of different groups to understand the detail of the work required to implement the current Payroll system on to an Oracle Platform. Applications Management Review Project Applications Development Finance Review Work Breakdown Steve Webb Richard Symes Mel Macdougal Panda CTO Group IT Group HR Accenture SMEs Group IT Oracle Oracle DBA’s Contractors

20. In Scope Archive & decommissioning of existing payroll systems LTSB (PANDA) and I&I RBS/Payroll Solutions payrolls. Migrate the LTSB and I&I UK and offshore payrolls to the Oracle payroll module. Migrate the 10 pensioner payrolls for both I&I and LTSB to the Oracle payroll module. Review and rebuild the LTSB on-line absence process. Configure 303 payroll elements and related calculations. Reconfigure 75 of the curretn150 letters and develop 10 new letters. Develop 15 reports and implement 42 delivered reports (6i not CEUL) Train 50 Users. Develop 55 Interfaces and write 26 migration programs. Map 94 processes impacted by payroll (15 of which are core payroll processes) Run Development on Oracle eStudio for 5 months Purchase 1840 GB of additional disks to support development Customise 10% of HRIS forms and develop 12 new payroll and absence forms Out of Scope C&G Staff & Pensioner payrolls. AFD Staff & Pensioner payrolls. Re-defining the BIPASS system. Re-engineering the Pensions systems. Workflow. On-line Leavers process. On-line payslips. Development of any CEUL reports Dependencies The production and development environments must be upgraded to Oracle 11.5.9, 9I and AIX 5L by May’05 Integration of I&I HR processes (not payroll) into HRIS must be completed before the Oracle solution is implemented; EDI links with the Inland Revenue will be covered by another project and implemented prior to HAPI. Contingency Contingency 20% on element configuration 25% on payroll calculation documentation 10% at a project level to allow for the current accuracy of data 5% at a project level to allow for potential downtime of development server 5% at a project level to allow for ramp up of staff in AD Charging Assumes that Accenture resources staffed through Group IT will be charged through at £385 from 2004 Assumes that Oracle resources staffed through Group IT will be charged at £1000 from 2004 Assumes that Panda and DBA resources are to be charged at the premium rate of £850 Upgrades & Hardware The ongoing annual cost of Oracle upgrades is £128k.  With a major upgrade costed in for 2008 at £220k The cost of additional boxes for the development or running of Payroll have not been included in the estimates. The Application DBA’s have advised that additional disk space is all that is required. Testing Three passes of 4 weeks each for product test. Each pass contains a two week test followed by 2 weeks to fix and re-run test.  Each pass likely to contain differing test scenarios using “made-up” data. 8 weeks Integration test in parallel with Product Test UAT – two 4 week passes. First 4 weeks using made up data. Second 4 weeks a “retrospective” parallel using a prior period real data Two period of parallel operations post “go-live”. Legacy is master until decided otherwise. A Performance Test pre go-live to test response times under load A Deployment test to validate data conversion load times, re-config times, etc A Deployment Verification Test to practice post go-live user approval process An Operations test prior to go-live On-Going Support Assumes ongoing Application Maintenance level of 3 FTE. Operating Model and Systems Build Summary The scope of the Payroll project is focused on the delivery of a new operating model for Payroll. It incorporates the implementation of an Oracle payroll solution with the following characteristics.

21. Work Effort and Resource Requirements Based on the assumption that Group IT will deliver the majority of the technical build through the SDC’s and the applications development team, the estimated cost of the build is £11m. Group IT will need to deliver 9,000 days of work over 12 months.

22. Work Effort and Resource Requirements The anticipated schedule of work anticipates that the project will take approximately 63 weeks to deliver with cut over happening after 55 weeks (March ’05 should work commence in November ’03). Illustrative Only

23. Work Effort and Resource Requirements Based on the anticipated schedule of work, the peak resource requirement for Group IT can be estimated at 35 FTE. Illustrative Only