Program Mercury

Program Mercury
Program Charter

Program Charter – Table of Contents

Program Mercury 1. Executive Summary

Global Finance Information System (GFIS) Background A little over 10 years ago Ernst & Young agreed to undertake a global effort to implement a common finance solution backbone, known as the Global Finance Information System (GFIS). The chosen software platform was PeopleSoft Financials. The software was customized extensively to satisfy the requirements of Ernst & Young. In addition to the core system, an extended internal ecosystem of over 1,000 systems was either modified or developed to extend functionality beyond the reach of the PeopleSoft solution that was implemented. These include multiple custom applications supporting pricing, scheduling, billing, and reporting, across our TAS, Tax, Assurance, and Advisory practice areas. Although Ernst & Young was willing to adopt a global standard platform (PeopleSoft), the Ernst & Young member firms were unwilling to adopt standard processes and designs. This resulted in multiple transaction processes running within multiple country solutions enabled by our three mirrored production instances. This solution framework makes it difficult, if not impossible, to consolidate information across the various solutions without a high degree of data manipulation. Today, the Ernst & Young organization considers GFIS to have serious limitations that will not allow us to support our vision for the future of the organization. In particular, as the business continues to globalize and grow, the organization struggles with the implications of product capabilities and design decisions made at the outset of the implementation. Furthermore, GFIS remains tethered to myriad ancillary systems that were developed to fill the gaps in GFIS functionality. These ancillary applications are operated at significant cost to the business relative to redundancy and lack of standardization. To add value to our internal processes, EY needs to reengineer the business and use this Program as an opportunity to transition the organization to a more cohesive global business model.

GFIS- Replacement Platform As an integral part of our GFT initiative, EY understands the need to establish a global software platform to support key aspects of Ernst & Young’s Client Service Delivery processes, and provide full support for Procurement and Finance processes. This platform must provide consistent high-quality services to the organization’s senior leaders, executives, managers, client account teams, and individual performers. To enable this initiative, EY will implement a single global instance of SAP software to support operations in 140+ countries. This platform must provide improved business and transaction processes across our global business landscape, with superior enterprise intelligence capabilities to support insight and decision-making and to help us leverage our shared service centers and Global Talent Hub (off-shore resources).

The replacement of GFIS with the new solution will be the biggest enabler to achieve the vision of Global Finance Transformation and support EY’s global strategy ...is to create a world-class global Finance function that provides consistent high-quality service to management and client account teams, lowers enterprise risk and cost, supports improved integration of the organization globally and invests in development and career paths for our people. Our Global Finance Vision... October 2010Jersey City, New Jersey Creating globally integrated and standardized Finance, Service Delivery Administration and Procurement processes Aligned on a common solution platform that is scalable to accommodate any size practice and leverages Professional Services best practices To provide a framework for consistency and quality while lowering costs and improving effectiveness Program Mercury (formerly GFIS Replacement) Mission... EY Transformation Approach for Program Mercury Guiding Principles for Program Mercury Develop a common, global set of “end to end” integrated business processes for Service Delivery Administration, Finance and Procurement Standardized, global integrated applications A Common, global, integrated set of NEW processes will eliminate the multiple variations to identically named processes, (e.g. variations to cash collections) and variations to the underlying data structures. (e.g. CoA, SMU structures) Lower total cost of ownership by retiring custom systems and running a world class GFIS Replacement in their place Eliminate the variety of business processes with one common, integrated set Rely upon a global suite of applications instead of the country oriented set in place Implement world class business processes with little or no system customization Use “out of the box” functionality instead of localizing per each country Implement an industry accepted Professional Services template

Vision 2020

We are grouping the Vision 2020 Finance actions into themes

Vision 2020 – Impact on Finance Agenda There are a number of areas that Finance will need to progress in order to enable the key components of Vision 2020. Following a thorough review of Vision 2020, we have articulated 70+ actions that we are progressing in order to develop a Finance roadmap to implement the required solution(s) to enable key components of the strategy Finance Strategy Implementation Themes Our approach We have taken a proactive approach to understanding the Vision 2020 impacts on Finance, outlining the key ‘Finance Strategy Implementation Themes’ and associated impacts How Finance will enable key components of Vision 2020 Articulation of strategy impact areas for Finance into 70+ specific strategy actions Finance Functional Leadership engaged to drive strategy actions, working with existing Global Finance Transformation Programs where possible Development of Finance Strategy Roadmap to manage Vision 2020 actions Working with required parts of the business (e.g. Markets) to progress areas that require Finance enablement (e.g. Global 360 accounts) Finance Agenda Impacts Accounts: understanding the reporting requirements for Global 360 and new accounts landscape, including the role of market segments Investments & Program costing: developing an accounting policy for sharing the costs of investments and understanding the need for a Program costing tool Metrics: review the impact of new metrics on planning and reporting EPI & Simplification: enabling the reduction of P&Ls, measurement of the reduction of indirect costs, and enabling required changes in planning and budgeting Organizational efficiency: design and implementation of the Finance Organization; Finance’s role in measuring and tracking costs at the Executive layer Finance people: Implementation of Exceptional Client Service framework for the Finance community Finance response to Vision 2020 Example decisions required Naming of Global 360 accounts to enable reporting Mapping of accounts and engagements to market segments to allow revenue, sales/pipeline and margin roll ups Required changes to planning and budgeting systems to support Vision 2020 ambitions

Finance vision and FY13 priorities Engage with and develop our people Integrate our organization Implement global finance systems, including replacing GFIS Improve decision support for our customers Support Enterprise Profit Improvement (EPI)

Overview A single, high performing finance organization worldwide ECS as a the finance mantra for serving our customers – client serving and management populations Multi-year evolution from many geographically organized, distributed and dispersed finance teams to functionally driven teams managed by Global Finance in an efficient, customer centric-model Jan - June 2013 : One integrated finance team serving the Executive Layer Build Global Support Centers for Reporting and Finance Infrastructure FY14 goal setting and reporting lines for Executive and Regional Layers shifted to Finance Service level agreements (SLA) socialization commenced Regional meetings with Partners and Management July - December 2013: Begin harmonization of titles and role descriptions First baseline customer satisfaction survey commenced Finance user review panel in place SLA signing commenced Jan – June 2014: All SLAs signed All performance reviews and goal setting under Finance Mercury implementation started

Exceptional Client Service Framework Our customer service framework Finance Business Advisors Technology & Process enablement (Desktop / On-line, available on-demand) Connected Understand the client’s business agenda Serve the client the way they want to be served Use the global network and introduce our high-caliber people Responsive Respond promptly to all client contact Raise our visibility with the client Seek — and provide — continuous feedback Insightful Present high-value insights proactively Deliver technical excellence Create business-oriented service offerings Transactional services (GSS) Finance business advisors will be supported in delivering their services by functional expertise (e.g. global reporting) and by GSS for transactional services Customer classification will be revised based on vision 2020 refinements. For e.g. customers such as market segments and region SSLs will be mainly self-enabled and therefore may require on-demand/Ad hoc finance support, where Executive, regional managing partners and region SLs management would need dedicated / shared resources to support them. Services will be delivered by resources either in close proximity to the customers or from a remote location – depending on the customers’ needs and services required. For the remote near-shore services, it is envisioned that services would ideally leverage GSS locations grouped with Controlling functions. In any event, these services would leverage low cost locations and consider language needs

Service Level Agreements (SLA) Role of the SLAs for Finance: Establish mutual partnership between finance and the customers of finance Clear definition of expected services, performance levels and accountabilities Mechanism to incorporate feedback from customers and drive continuous improvement of finance services Consumption based pricing model that is fair and economical to both developed and emerging markets Relationship Management Performance measurement and Accountability Customer Feedback, Escalation & Resolution Service Descrip-tions Consumptionbasedpricing Partnership with the customers Finance User Panel Quality Standards Continuous Improvement

As we invest in our finance talent to develop world-class business advisors, we need our “Finance Academy” to come to life with meaningful opportunities for our people Finance Academy “The Finance Academy” – helping our people to develop their own careers Critical success factors: well defined career paths and opportunities – finance functional expertise, customer service skills, management world-class training and skills development ability to identify, develop and mobilize our talent on a global scale consistency in quality of finance resources and services provided

The move to top quartile efficiency is dependent on us being able to implement truly standardized processes, remove work effort and refocus our resources to provide the most relevant services for our customers Top quartile performance Critical success factors: Ability to design, implement and sustain standardized finance processes globally Ability to leverage world-class technology consistently and remove the costs of running legacy applications Ability to manage from the top-down the leveraging of scale and deploy our resources most effectively to deliver the services needed by our customers Ability to invest in our finance talent, from the top-down, to ensure consistency in skills and the ability to truly serve as a trusted business advisor FY20 COF: 1.24% FY15 COF: 1.40% COF: 1.31% COF: 0.90% COF: 1.28% COF: 0.98% COF: 0.50% 23,238 Revenue Programion aligned with Vision 2020 scenario

Achieving the business case target Current state FY12 Plan Future state FY20 Markets : Increased automation and globally standardized and streamlined processes, enabling a shift from on shore to off shore and reduced manual work and duplication of tasks Shift of the market function to provide more added-value and advisory support, which contribute to increase the need for trusted business advisors and senior competencies Controlling : Standardization of management reporting and centralization of resources Decommissioning of local applications (FS&I) Increased automation and process standardization, enabling a better use of off-shored resources for accounting and reporting activities PBFA : Vision 2020 simplification (Less P&L and P&L owners) Planning & Budgeting simplification (No outlook, Quarterly forecast driver based, Planning at less granular level) Process & technology enablement Enhancement of Business Insight and Decision Support TAX : GCR initiative TOTAL TOTAL FTEs: 4,019 CoF:$ 326.2m CoF (%): 1.4% Revenue: $ 23bn FTEs: 3,000 - 3,700 CoF:$ 256.7m CoF (%): 0.5% Revenue: $ 51.3bn NOTES: Current State: Cost and FTE data based on Baseline numbers Future State: Based on EPI business case

EY faces operational challenges in Service Delivery Administration, Finance, and Procurement at all levels of the organization The current environment is not sustainable and does not support EY’s global strategies Tomorrow Today Integrated processes and technology supporting both local and company-wide strategic needs Fragmented processes and dated, non-integrated systems supporting local needs implemented in many different country GFIS versions and landscapes The New Solution

Key Objectives for Program Mercury Replace GFIS Must replace GFIS which is reaching the end of it´s useful life Support Business & Strategy Better integrated and standardized SL and Finance Admin processes to support Global and Core Accounts, Service Lines and Area/Sub-Area Management Better enable Client Service Practitioners to focus on Client needs rather than gathering and analyzing information Reduce cost of the back office finance function Provide KPI´s to help reduce risk, improve control and transparency of our performance Reduce Risk & Control Program Cost Control and reduce Program cost for system replacement Operate new system at lower cost Reduce probability of failure for this big Program (scope, cost, timeline, benefits generation) Benefit Realization Increase process efficiency and effectiveness in order to generate savings Better enable a lower cost finance function Decommission ~1,400 global and local systems Implement a solution that accommodates ability to support EY strategic and firm changes

Key Principles – How we plan to improve processes and system support for all stakeholders Focus on Client Server needs at least as much as administrative optimization Harmonize and standardize end-to-end processes and policies globally by applying common design principles Make it work for all Service Lines and Practice sizes Support globalization of the Finance organization and the improvement of GSS services Design for best global firm fit, reduce optionality Keep it as simple as possible Leverage standard delivered software capabilities Involve and Integrate all stakeholders, but ensure streamlined global process design and decision making

Program Mercury Guiding Operating Principles

Program Mercury Guiding Operating Principles (cont.)

Program Mercury 2. Business Case

Program Mercury Business Case Please reach out to the PMO for access.

Program Mercury 3. Current Situation Assessment

Procurement Challenges & Benefits Summary – Back office leaders are most concerned with… Business Challenges Global Procurement strategies not enabled by multiple, inconsistent processes and tools Incomplete view or control of the Firm’s financial liabilities Support Teams / Finance & Accounting Multiple systems to capture, organize and review total spending across the enterprise

Service Delivery Administration Challenges & Benefits Summary – Executive and Management are most concerned with… Business Challenges Complex and hard coded structures provide poor flexibility for reporting , handling restructures and expansion Inability to easily access globally comparable data, especially account/client profitability across multiple organization dimensions. Executive & Management Multiple , cumbersome management and finance tools that tie up valuable client handling resources

Service Delivery Administration Challenges & Benefits Summary – Client Facing & Engagement leaders are most concerned with… Business Challenges Multiple, complex tools and approaches across the firm for all aspects of Account, Client and Engagement management Proliferation of engagement codes to support complex revenue sharing model Client Facing & Engagement Leaders Inability to price, budget and build resource plans on large, cross border engagements.

Service Delivery Administration Challenges & Benefits Summary – Support Teams are most concerned with… Business Challenges Poor resource management visibility across Service Lines and Geographies Capture the full impact and contribution of business development and sales support resources on accounts Support Teams / Finance & Accounting FMAs and Account Coordinators spend too much valuable time navigating systems and disjointed processes

Finance Challenges & Benefits Summary – Executives are most concerned with… Business Challenges Multiple , cumbersome management and finance tools and different practices result in complex finance structures/high cost of finance function Poor global visibility to profitability across Area, Sub Area, client and management organization views (e.g. New segments, FSO, etc.). Executives & Engagement Leaders Complex and costly process to produce both legal/statutory and management reporting requiring multiple systems and data reconciliation challenges

Finance Challenges & Benefits Summary – Client Facing & Engagement leaders are most concerned with… Business Challenges Multiple, complex tools and approaches across the firm for all aspects of Account, Client and Engagement management Proliferation of engagement codes to support complex revenue sharing model Client Facing & Engagement Leaders Inability to price, budget and build resource plans on large, cross border engagements.

Finance Challenges & Benefits Summary – Back office leaders are most concerned with… Business Challenges Performance level of Finance Organization not undermined by moving to globalized structures and global system landscape Finance Organization spend too much valuable time navigating systems and disjointed processes Support Teams / Finance & Accounting Multiple systems to capture, organize and review total spending across the enterprise

Procurement Challenges & Benefits Summary – Executives are most concerned with… Business Challenges Multiple Procurement organizations and commercial management strategies result in higher costs for the Firm Executives & Engagement Leaders Lack of global visibility to A/P data inhibits effective commercial management strategies for the Firm

Procurement Challenges & Benefits Summary – Client Facing & Engagement leaders are most concerned with… Business Challenges Lack of consistent commercial management strategies may reduce competitiveness of Firm services and proposals Client-service professionals spend individual time on negotiations and workarounds when travelling Client Facing & Engagement Leaders Procurement activities can jeopardize client relationships or Independence

Key policy decisions will need to be made in several policy areas – we will use our Process Teams to identify policies for creation/revision Initial key policy decisions to evaluate

Program Mercury 4. Program Approach

Global Design is the portion of the Solution that is common and will be leveraged & shared across EY (80%) Global Systems Q&RM Systems People Systems What is the Global Design? It is a framework of common . . . Global processes Data structures Organization and Report structures Global Roles & Handoffs Integration connections with global systems & platforms Professional Services best practices Data Usage Local Design Global Design 1 Service Delivery Administration 2 Finance Procurement 3 GL Accounts Clients Local Design Local Design 4 5 Roles Reporting Needs 6 Local Design Market Systems Finance Systems 7 *Representative The Global Design will cover ~80% of our requirements The remaining 20% will be added during localization / deployment It all adds up to the 80% of the overall solution

The Global Design will be the foundation for the Pilot and Roll-ins, ensuring we have a common & consistent model, overlapped tasks allow a quicker roll-in 2012 2013 2014 2015 2016 Jan Apr July Oct Jan Apr July Oct Jan Apr July Oct Jan Apr Global Design Global Design Pilot Localization Pre-Work LocalDesign, Build, Final Prep & Go-Live Hyper Care GSA Global Build Global and Local Test Support Centers Global Deployment (illustrative of multiple go-lives) Localization Pre-Work Local Design, Build, Final Prep and Go-Live EMEIA Localization Pre-Work Local Design, Build, Final Prep and Go-Live Americas Global Design Pilot Global Deployment Global Design Global, common design – 9 months Representative input from Core Team, and from the Extended Team and SMEs as needed Prescriptive Global Design will be delivered to the organization Global Template approved by GPOs Pilot Build and Test Global Template and Pilot Localization Mitigate risk by production Pilot proof of concept Germany/Switzerland/Austria/Canada Mix of client types – OCA, Global, Local All Service Lines and Functions Multi-language, Multi-currency Go-Live July 2014 Global Hubs Repeatable implementation using common design Localization focused on legal/statutory requirements Three overlapping waves over 24 months Parallel activities and teams needed for execution Localization Pre-Work Local Design, Build, Final Prep and Go-Live Asia-Pac, Japan

Global Design – Context Diagram Time Resources Budget Vision 2020 Program Goals & Objectives Key Principles Draft Future State Models Prioritized Requirements Leading Practices Delivered Software Business Process Hierarchy Global Processes Roles & Handoffs Reporting Structures Operational Efficiencies Common Design Pilot / Global Build Input Enabled Operating Model Constraints Global Design Phase Outputs Inputs Enablers Empowered Team Members Global Design Methods and Tools Global Process Owners / Deputies Effective Governance and Decision-Making

Global Design – Key Principles Focus on Client Server needs at least as much as administrative optimization Harmonize and standardize end-to-end processes and policies globally by applying common design principles Make it work for all Service Lines and Practice sizes Support globalization of the Finance organization and the improvement of GSS services Global Design Key Principles Reduce optionality, design for best global firm fit Keep it as simple as possible Leverage standard delivered software capabilities Involve & integrate all stakeholders, but ensure streamlined global process design and decision making

Creating EY’s Global Design will take nine months and consists of three repeatable three-month cycles of Working Sessions followed by one day Validation Workshops Global Design Phase Dec. Jan. Feb. Mar. Key dimensions of Global Design will be presented to the GPOs for approval during Mobilization, including: Design Period 1 through 3 process scope SMEs to be included in Working Sessions associated with discrete processes and / or sub-processes Decision authority by process / sub-process domain Launch Session and Validation Session planning and scheduling (e.g., specific dates and meeting invitations) Effective resourcing and empowered decision-making is key to remaining on schedule This kick-off event incorporates Design Period 1 Launch-related activities Apr. May Jun. July Aug. Sep. Oct. 9 – 11 April 2013 (TBC) Design Period 1 L V Process Grouping Working Sessions Mobilization S 9 – 11 July 2013 (TBC) 8 – 11 January 2013 (TBC) Design Period 2 1 – 3 October 2013 (TBC) V S Legend L Process Grouping Working Sessions 27 March 2013 (TBC) Design Period 3 Launch Event L Validate Session V L S Process Groping Working Sessions V 26 June 2013 (TBC) Design Showcase S

Global Design – Fundamentals Who participates? Program team members comprised of representative members from all geographies, Service Lines, organizations and functions Specific alignment of resources to working sessions per your Process Team Leads Alignment of cross-functional resources through the Process Integration Lead Where will the Working Sessions be held? EY Secaucus (and select alternative locations as required) When will the Working Sessions take place? January through September 2013 How long will the Working Sessions run? Days to weeks according to scope as defined in the Integrated Program Plan

Global Design Key Dates Kick-off / Design Period 1 Launch – 8 through 11 January 2013 Design Period 2 Launch – 27 March 2013 (TBC) Design Period 1 Validation Session – 9 through 11 April 2013 (TBC) Design Period 3 Launch – 26 June 2013 (TBC) Design Period 2 Validation Session – 9 through 11 July 2013 (TBC) Design Period 3 Validation Session – 1 through 3 October 2013 (TBC)

Organizing Global Design – “Design Periods” and “Process Groupings” Our program scope includes over a hundred discrete processes We have apportioned these processes into Design Periods and Process Groupings Criteria used to assign processes into Periods and Groupings include: Mission criticality and complexity Logical sequencing and degrees of process integration Anticipated amount of time required for process design Each Grouping will be put through a uniform set of activities encompassed in Working Sessions during the Global Design phase Global Design Phase Design Period 1 L V Process Grouping Working Sessions Mobilization S Design Period 2 Legend V S L Process Grouping Working Sessions Launch Event L Design Period 3 Validation Session V L S Process Grouping Working Sessions V Design Showcase S

Our Process Groupings will enable us to focus our resources and attention during Global Design, while ensuring process integration Design Period 3 Non-complex, basic transactional processes Largest number of discrete processes, but expected to be supported “out of the box” Design Period 2 Fewer mission-critical processes with some cross-functional relationships Larger number of discrete processes, but less complex Design Period 1 Operating and reporting elements and complex, critical processes with extensive cross-functional relationships Processes anticipated to need more time to complete design Finance Process Groupings (~ 67 Sub-Processes) Procurement Process Groupings (~ 27 Sub-Processes) Business Process Integration Service Delivery Administration Process Groupings (~37 Sub-Processes) Business Process Integration

Global Design Development and Approval Approach Design Period 2 Fewer mission-critical processes with some cross-functional relationships Larger number of discrete processes, but less complex Design Period 3 Non-complex, basic transactional processes Largest number of discrete processes, but expected to be supported “out of the box” Design Period 1 Operating and reporting elements and complex, critical processes with extensive cross-functional relationships Q3 FY13 Q4 FY13 Q1 FY14 Uniform Set of Global Design Activities Launch Design Socialize Validate Approve 1 2 4 5 6 Process Grouping Launch Session (GPOs, Deputy GPOs & Process Leads) Conduct Working Sessions (Team, Deputy GPOs,& SMEs) Validation Workshop (GPOs, Deputy GPOs, Process Leads, Team) GPO Sign-off on Design (GPOs, Process Leads, Deputy GPOs) Solution Showcase (Select Team Members, SMEs) 3 Informal Checkpoints (Organized by Process Leads, with GPOs and Deputy GPOs as needed) X X X X X GPO Involvement

The Program will Launch each Design Period, Conduct Working Sessions, and engage GPOs in dialogue using a common approach Working Sessions and Informal GPO Meetings Launch Launch Sessions Combined Launch Sessions for Service Delivery Administration, Procurement, and Finance domains Used to communicate / reinforce: Process Grouping scope Working Session topics SME appointments Team member / SME alignment Process integration points Decision authorities Working Session schedule Who: Process / Cross-Functional Teams, SMEs When: At the start of the three month Working Session cycle Where: Secaucus, NJ Duration: ~1 day Solution Design Working Sessions Teams leverage “pre-work” prepared during the Mobilization phase as the backdrop for Working Session activities Through workshops associated with discrete processes, Process Teams will complete solution design, including: Common business processes and information requirements Functional and technical enhancements to delivered capabilities Change and organizational impacts Cross-Functional teams will leverage work output to support: Process role alignment with broader Organizational Design efforts Benefits Realization efforts (e.g., application sun-setting) Legacy system remediation Continuous involvement of GPOs vis-à-vis informal check points Who: Process Teams, Cross-Functional Teams, SMEs When: Q3 and Q4 FY13; Q1 FY14 Where: Secaucus, NJ Duration: ~ 3 months per Process Grouping

After each three month cycle of Working Sessions, the associated Process Groupings will be Validated, Approved and Socialized Validate Approve Socialize Validation Workshops Conduct Validation Workshops based on output of Working Sessions Validate full Process Grouping with the all GPOs Use Executive Story-Boards to communicate design Who: GPOs, Deputy GPOs, Process Team Leads, select Team members When: Following the completion of the three month Working Session cycle Where: Depending on GPO availability Duration: 1.5 – 3 days GPO Sign-off on Design Official sign-off by all GPOs Conditional sign-offs may be given if additional steps are required to secure approval Design associated with highly complex processes may span more than one Process Grouping Who: GPOs, Deputy GPOs, Process Leads, select team members When: At the completion of each Validation Session Where: Conference Calls & in-person meetings based on GPO location Duration: Combined with Validation Workshop Solution Showcase Inform SMEs across EY about the approved solution design related to each Process Grouping Solution Showcase will span several weeks and provide outreach to all global regions Conducted by a small team of program resources Who: Select team members communicating to SMEs who participated in the Working Sessions When: Following Process Grouping design approval Where: Across EY global regions Duration: Several weeks X

Global Design Summary – Representative Activities, Deliverables and Outcomes

January 2013 Immediate Areas of Focus – Organization Structures Working Sessions Aligning the EY organizational structure with the organizational structure within SAP will be an immediate area of focus; key related activities include: Cross Process Team Org. Structure design sessions (1/15 through 1/18/13) Brief the GPOs on “Straw-Man” Org. Structure design (1/23/13) Solicit GPO insight relative to Vision 2020 considerations (by 2/1/13) Complete the Organizational Structure design (by 2/15/13) Brief the GPOs on the design and implications (2/20/2013) Resourcing: Select team members Work Plan per the: Integrated Program Plan Organization StructuresShort-Interval Schedule

January 2013 Immediate Areas of Focus – Global Common Process Working Sessions Process-centric Working Sessions will be performed in parallel with Organization Structure sessions beginning in January / February timeframe and will include: Service Delivery Administration: Account Maintenance (January through March) Client Maintenance (January through March) Resource Scheduling (January through September) Engagement Pricing (January through June) Engagement Maintenance (February through June) Procurement: Supplier Set-Up and Maintenance (February through March) Finance: Supplier Set-Up and Maintenance (February) Statutory and Tax Accounting (January through February) Resources will be aligned per the Process Team Leads Work will be performed per the Integrated Program Plan and supporting “Short-Interval schedules”

Longer Term Areas of Focus – Technical Architecture with Integration and WRICEF Technical Architecture (e.g., Applications, Interfaces, Information, Infrastructure, Security) Wider than SAP: Global System Interfaces Coexistence Data to migrate from existing systems New code block BPD Input Technical POC Data Profiling User Experience Strategy Portal Strategy Mobility Strategy Input Technical Architecture Integration Strategy Imaging & Document Management Strategy Input Business input required: Production Availability Capacity Response time Capacity Recoverability NFRs Clear Method TOGAF 3rd Party Quality Assurance

Longer Term Areas of Focus – Technical Architecture with Integration and WRICEF In addition to providing support for the Business Process teams the Technical Architecture team will address the following: Test Strategy Data Migration Strategy Support Center Strategy Set-up of IBM Global Delivery Center Agree system changes and milestones with CBS and Markets ITS Service Delivery Teams

Global Design – Key Areas of Focus (Definitions and Examples) Working Sessions will address all dimensions of Global Design, including Organization Structures, Global Common Processes & Roles, WRICEF and Architecture These components (among others) support our business scenarios + +  Organization Structures Global Common Processes & Roles Integration / WRICEF Global EY Template Scenarios Technical Architecture (e.g., Applications, Interfaces, Information, Infrastructure, Security)

Global Design and Pilot Phase Schedule – Overlapping Phases Beginning in July 2013, the Global Design, Global Build and Pilot phases overlap Global Build resources will begin to on-board in June 2013 The Global Build team will begin to work on: Global System integrations Design stemming from Design Period 1 and 2 Working Sessions Localization associated with the Pilot will begin in September 2013 The Pilot is scheduled to go live in July 2014 Global Design, Global Build and Pilot Jan2013 Feb2013 Mar2013 Apr2013 May2013 Jun2013 Jul2013 Aug 2013 Sept 2013. Oct 2013. Nov2013 Dec 2013 Jan2014 Feb2014 Mar2014 Apr 2014 May 2014 Jun 2014 Jul 2014 Global Design Global Build Pilot / Localization Global and Local Testing Center of Excellence (Support)

Global Delivery Methodology CMMI certified global delivery center approach to offshore development, configuration and testing will be leveraged Methodology Phase Global Design Global Build Testing Communication & Coordination (all teams) EY site 1. Document Processes (BPD) 11. Execute Scenario Test 12. Integration Test 3. Document Functional Specification (FSD) 2. Identify GAPs 6. Tech Design Walkthrough 8. Ongoing Issue resolution and clarification 10. Review Test Results Global Delivery Centers 4. Approve FSD Learn processes 5. Create Technical Design Document & Unit Test Plan 9. Execute Unit Test 7. Develop Code

EY Major Program Transformation Structure EY’s Major Program Transformation (MPT) methodology is structured in seven phases that closely follow the standard, proven, and well-accepted Software Development Lifecycle. The phases are, in order of execution:

EY Major Program Transformation Structure (cont.) The MPT methodology also contains 12 work streams that cut across all phases of the Program. The 12 work streams work together in an integrated fashion through all 7 phases of the implementation lifecycle. The methodology is structured this way to improve cross-work stream integration, something experience has shown to be key to delivering high-quality Programs on time and on budget.

The planning and scoping phase is the first phase of the implementation Program and provides initial planning and preparation for the entire Program. The purpose of this phase is for stakeholders and/or decision-makers to define clear Program objectives and an efficient decision-making process. The primary objectives of this phase are to issue a Program charter, outline Program goals, scope and priorities, and recruit and on-board a Program team. Correctly on-boarding a Program team is key, and the first step in this process is for the Program manager(s) to develop a Program plan and conduct a kick-off meeting. The kickoff meeting is critical, since at this time, the Program team as well as the process owners become aware of the Program charter and objectives and are assigned their roles and responsibilities, which last throughout the Program.

The purpose of the high-level design phase is to illustrate through documentation how the company will operate its business using the new solution. The primary objectives of this phase are to conduct workshops to gather high-level business and design requirements, to identify gaps where the standard out-of-box system does not cover all required functionalities, to develop the high-level process flows, to detail the high-level future-state business process and solution designs, and to define the key performance indicators (KPIs) for the processes. These documents are further refined during the detailed design phase.

The purpose of the detailed design phase is to create a detailed process-oriented and technical documentation of the results gathered during requirements and design workshops. The primary objectives of this phase are to conduct workshops and to understand the detailed designs, and functional specifications and configuration designs are created for various processes. Perform a needs analysis to identify the end user training needs. Also, identify high-level business scenarios to be used for system testing during the test phase of the Program. Major activities performed during this phase include working with the configuration and development and Test work streams to ensure they understand the future-state system requirements. The success of the Program depends on a clear definition of value, establishment of a permanent benchmark and continuous measurement against this benchmark throughout the implementation lifecycle.

The purpose of the build phase is to implement the business scenarios and processes designed and documented during the design phases in the development environment. The primary objectives of this phase are to translate functional specifications into technical specifications, to configure and build the system (including creating custom code), to conduct unit tests for development objects, and to build and test user profiles.

The purpose of the test phase is to conduct various test cycles to confirm the system has been built correctly as per the business, technical and design requirements defined in the Planning and Scoping, high-level design and detailed design phases. A primary objective of this phase is to perform system integration testing by the configuration and development work stream. This is performed by the process and design work stream to test the new application’s ability to support the identified business processes, test data, roles and controls and to validate that all business requirements outlined in the requirement traceability matrix have been met; performance and stress testing. System integration testing confirms that the system operates within acceptable performance guidelines when processing the agreed-upon upper-limit loadings in a production or simulated production environment. User acceptance testing (UAT) is also performed by the business owners with assistance from the process and design and test work streams. UAT is the final quality control procedure to determine whether the software product is performing as expected.

The purpose of the deploy phase is to finalize readiness of the solution and to confirm go live readiness. The go/no-go decision meeting is critical in this respect, since, at this time, all work stream leads confirm readiness of the solution, and the stakeholders and/or decision-makers announce their decision on whether to proceed with go-live. On successful completion of this phase, the organizational, business, functional, technical and system aspects of the Program should be ready to be used in production. The primary objectives of this phase are to prepare deployment tools and processes, and to perform timely and accurate completion of cutover to production, including manual and automated data migration steps. On successful completion of this phase, the organizational, business, functional, technical and system aspects of the Program should be ready to be used in production.

The purpose of the support phase is to provide support for the solution during the period immediately following production cutover and to plan and execute transition to long-term production support (functional and technical). The primary objectives of this phase are to establish processes to enable knowledge transfer, set up go-live training sessions and ensure that training materials are kept up to date. On the successful completion of this designated extra-care period, sustaining production support processes and staff become the core support for continuous improvement in the ongoing solution. Reviewing Program management plans, reviewing Program actuals and closing budget, and conducting post-implementation assessment leads to conclusion of Program-oriented activities for the respective Program scope.

Phase I – Program Mobilization & Global Design Program Mobilization The initial sub-Phase of the program is focused on confirming the high level scope and vision of the program, mobilizing and orientating the Program team members, embedding the required program management processes and procedures and approving the approach at both an overall program level and for each individual work stream. Global Design The Global Design sub-phase is tasked with fully specifying and agreeing the scope and design of the Program Mercury including processes, roles, organizational and business change and the technology components and architecture required to enable the delivery of the defined vision and the interim state (i.e. coexistence of old and new solutions until the latter is deployed globally). Data migration, legacy system integration and archiving requirements are defined and confirmed during the Program Mercury Global Design sub-phase, and a detailed legacy data profiling process is employed as a means of accelerating the development of comprehensive data cleanse plans.

Phase II – Program Realization The Realization Phase is concerned with building, testing and deploying the System developed during the Global Design Phase to a pilot group of EY Network Members with the express intent of proving that the System is capable of supporting the Business Requirements representative EY member firms. The phase comprises three sub-phases: Realization Final Preparation Go-Live & Hypercare

Phase II – Program Realization (cont.) Realization The objective of the Realization phase is to build the System, test the System, conduct data migrations and prepare the pilot sites for the impact of the change. Building the System requires configuring the system and creating the WRICEF development objects to address the specifications documented in the Global Design Phase. In parallel, data conversions cycles are executed to prove out the data migration tools and approach, as well as serving to confirm the accuracy of the cleansed data. The plans for the key Realization activities are driven from the strategies that are agreed in the Program Mobilization Phase, and subsequently fully detailed during the Global Design Phase. Final Preparation The objective of the final preparation phase is to verify readiness for go-live, including user acceptance, end user training, site preparation, system management, cut over and transition management activities. Go-Live & Hypercare The objective of the go-live and hypercare phase is to move from a pre-production environment to a live production operation and ultimately to transition to the support organization. IBM will provide production support assistance during the go-live and support phase to help facilitate an effective and orderly transition for on-going production support over to the long term support organization.

Phase III – Global Deployment The Deployment Phase is concerned with the roll-out of the developed solution as proven during the Pilot Realization Phase to the remaining EY Network Members globally. The key objective of the Phase is to deploy the System in a cost and time effective manner and in a way that adheres to the developed common design, allowing localization only to meet local statutory and legal requirements.

Global Design, Pilot & Global Deployment Transition

Global Deployment High-Level Phasing – Preliminary Draft

Development Cycles and Regional Hubs Setup Timing – Preliminary Draft EMEAI Regional Hub

System Testing As set out in the Program RACI, a comprehensive Program Mercury Testing Strategy will be developed and Accepted during the Program Mercury Global Design Phase. For the avoidance of doubt, no test phase will be considered complete, and hence, unless otherwise agreed by EYG Services, no subsequent test phase may commence until all severity 1 and 2 issues relating to the test phase have been resolved, and the level of outstanding severity 3 and 4 defects has been reduced to below the targets set for the specific testing phase. Definitions of testing defects can be found on the following two slides.

System Testing (cont.) Severity 1 Critical System Status The software is unusable with no workarounds available. Business Impact Seriously compromises or prevents a single or multiple firm’s ability to conduct its day-to-day business Severity 2 Major System Status A business critical process is unusable and no workarounds exist. Business Impact Materially impacts a single or multiple firm’s ability to conduct its day-to-day operations. e.g. Unable to create a new engagement

System Testing (cont.) Severity 3 Minor System Status System performance issue or bug affecting some but not all users, a short-term, manual workaround is available, but is not scalable. Business Impact Requires operational users to expend significant additional manual effort in the production environment to achieve their tasks. Examples: Integration between CRM and Program Mercury Platform to provide client details not functioning correctly requiring manually look-ups Specific screen navigation flow is not configured, but the user can navigate through other screens to get to the one required Data integrity issues impacting reports and queries Severity 4 Cosmetic System Status Inquiry regarding a routine technical issue; information requested on application capabilities, navigation, installation or configuration; bug affecting a small number of users. Acceptable workaround available. Business Impact Minor problems not impacting service functionality.

Program Mercury 5. Governance

A good decision making framework is the single most important action we can take to ensure program success Our decisions must be… Properly Informed Made in a timely manner Accepted as Final Communicated to the Organization We will focus on these elements of our decision framework Governance structure based on proven key principles Apply a new “mind set” to determine our true requirements Empowered team members with clear authority levels

Program and Business Process Governance Structure Program Governance Structure Global Executive Executive Leadership Team (ELT) Global Process Owners (GPO) GPO Customer Relationship Management GPO Service Delivery Support GPO Finance GPO Analytics GPO Procurement GPO People GPO Q&RM Executive Sponsors Business Dave Holtze Finance Michael Ventling IT Mo Osborne Program Chell Smith Business TBD Business(Emerging Markets) TBD Regular update and consultation with: Robin Hutchinson Mark Jarvis Carol Calandra OEC/MEC/FEC GFT Advisory Committee Oliver Graf Kathy Pawlus Greg Liss Larry Phelan Kevin Kelly Stephen Heil Cross Program Leaders Axel Meyer Program Management Team (PMT) Joe Devaney Alan Guthrie Matthew Samme Dean Hansen Ralf Broschulat Jim Miller Karen O´Neill

Apply a new “mind set” to determine our true requirements

Empowered team members with clear authority levels Team Role Decision Category

Our Program organization structure also supports our “One Team” Approach

Work Relationships & Responsibilities Discussion 2 Core Team Members 1 3 Process Teams The Process team Leads and teams work directly with the GPO’s and Deputies on Global Design Business process decisions They also engage SME’s identified by the GPO’s or from their own network Program Management activities will be handled & communicated by the Program Management Team Business Process Integration Lead is responsible for providing overall coordination on execution of Program Business Process Integration Lead has authority to ‘tap” and guide any resource 1 2 3

Work Relationships & Responsibilities Discussion Core Team Members 5 4 Process Teams Process Team Leads provide day to day direction to their team members Process Team Leads also call upon the Cross Functional Teams for “expert” support Cross-Functional Teams Cross-Functional Team Leads provide a common framework and design for their area or expertise to the process teams Cross-Functional team plans are not stand alone; they support the Process Team plans 4 5

Business Process Governance What is business process governance? Single point of business ownership for global processes The scope of these business processes is global However, the ERP business process governance program is focused on the interface between Program Mercury and process owners in the business Why is it important to EY? To enable business ownership of EY business processes GPO / Deputy GPO’s are single point of contact for in-scope business process decision-making globally To achieve control and balance of global business process standardization Standard objective: 80-90% standardization, 10-20% specific legal, regulatory or customerrequired customization To ensure decisions are made in the best interest of EY globally Best practice sharing across EY through a network of expert process users and SMEs Governance scope: All business processes supported by Mercury SAP

Process governance stakeholder groups and interfaces Interface: Countries request system and process change Office of GPO communicates importance of standardization Office of GPO’s share best practices Interface: Coordinate to implement an ERP solution that supports business processes GPO prioritize enhancements and customization requests to the ERP solution Business - Process Governance GPO’s define a set of global processes that form the base of the ERP solution Deputy GPO’s manage change process and customization requests for business processes, prioritize and secure agreement Countries Program Mercury Interface: Program communicate new functionality, system enhancement, release schedule Countries enable End Users, Super Users through Training Program ensures the validation of Global Designs/solutions (fit-gap) Process Teams design and deploy a timely, high-quality ERP solution Process Teams perform cost analysis of proposed ERP enhancements and customization End users leverage the Global template in activities according to defined procedures Regions / Countries collaborate with Program Mercury to identify legal and statutory requirements

Process governance stakeholder groups and interfaces Program Mercury Interface: Program communicates solution capabilities, release schedule Countries enable End Users, Super Users through Training Program ensures the validation of Global Designs/solutions (fit-gap) Interface: Coordinate to implement solution that supports business processes GPO prioritize enhancements and customization requests to the ERP solution Process Teams design and deploy a timely, high-quality solution Process Teams perform cost analysis of proposed solution enhancements and customization Business - Process Governance Countries GPO’s approve a set of global processes that form the base of the ERP solution Deputy GPO’s manage change process and customization requests for business processes, prioritize and secure agreement End users leverage the Global template in activities according to defined procedures Regions / Countries collaborate with Program Mercury to identify legal and statutory requirements Interface: Activities external to the Program Mercury scope

Governance - Roles and Responsibilities Responsibilities Role Decision rights Executive Sponsors Promote a process-focused organization Provide visible leadership to implementthe strategic vision for an integratedglobal enterprise Resolve issues raised betweenGlobal Process Owners GPO Provide Governance to global process across EY Decide on the definition, direction of, and changes to the global process Appoint Deputy GPOs Make final determination for changes presented by Deputies Resolve cross-functional conficlts Business Deputy GPOs Manage and optimize a subset of global processes included in the Mercury solution Ensure that business stakeholders maximize value from the solution Prioritize initiatives Ensures process standardization at a Global level Make final recommendation for change requests to GPO Elevate issues to GPO as needed Select key SMEs, users in enterprise / practice to provide input on process Process Teams Design and deploy a timely and high-quality SAP solution Evaluate cost of potential changes Collaborate with Deputies/GPO’s to prioritize change effort Resolve system issues Elevate governance issues to Program Mercury leader Design Operational aspects Program Mercury

Governance - Guiding PrinciplesDecision Making Process Governance is sponsored and supported by executive management Clear accountability and role definition Governance members have full authority in their roles Focus is enterprise-wide, in the best interest of EY globally Processes are segmented based on strategic impact Type 1: Low complexity and impact -> Team Lead level (70%) Type 2: Moderate complexity and impact  Program (20%) Type 3: High strategic impact  GPO (10%)

Governance - Global DesignDecision Making Process Evaluation and review by key SME’s, Process Leads, and Process Deputies Go/No-Go Decision by Deputy / GPO Prioritization for inclusion and development phase Global Design Fit Gap Fit gap assessment of business requirements against SAP Preliminary type classification (1,2,3) based on process impacted Agree Fit Gaps Assess cost and technical feasibility Prioritize Fit Gaps Agree Fit Gaps to be delivered Approved Fit Gaps to be included in Pilot Release or, prioritized for subsequent releases Type of Decision/ actions Decision-Maker Process Team Leads GPO / Deputies Process Team Leads Design Review Board GPO / Deputies Process Team Leads Escalation Deputy GPO GPO Program Management Program Management TBD by Design Review Board MeetingSchedule

Governance - DeploymentDecision-Making Process Finalize DeploymentScope and Plan Change request during Solution Confirmation Analysis by Mercury Leads Go/No-Go Decision by Deputy/GPO Evaluation / Review by GPO’s/ Deputies Type of Decision/ actions Identification of Global Model gaps during Localization Workshops Preliminary type classification (1,2,3) based on process impacted Quantify benefit to the Region / Practice Submit change request based on process type and benefit threshold Investigate design best practice Analyze cross functional impacts and technical prerequisites Estimate design and development cost Document Cost/ Benefit analysis Work with Process Deputies and GPO’s on final deployment scope definition Review Process type classification and Cost/ Benefit Analysis Go/No-Go decision on development scope change request Document impacts on deployment budget and schedule Development Resource allocation Agree with Process Lead on testing schedule Decision-Maker Mercury Team, Process Deputy, and Regional / Practice Leadership Process Leads Deputy GPO Process Leads Design Review Board Deputy GPO Process Leads Escalation First to GPO, Program Management Deputy GPO Program Management GPO To GPO & Program Management TBD by Design Review Board Meeting Schedule

Program Mercury 6. Program Organization

Program Mercury Organization Structure

Program Mercury 7. Program Roles and Responsibilities

Executive Sponsors (Business, Finance, IT)

Cross Program Leaders (CPLs)

Program Leader

ERP ITS Lead

Systems Integrator (SI) Lead

Process Integration Lead

ERP Solution Design and Delivery Lead

ProgramManagement Office (PMO)

Global Process Owners (GPOs)

Global Process Owner Network

Global Process Owner Deputy

Process Team Leads (Procurement, Service Delivery Administration, Finance)

Architecture Office – Business Lead

Architecture Office – ITS Lead

Operational Finance Lead

Tax / Statutory Lead

Business Transformation - Change Management Lead

Business Transformation - Benefits Realization Lead

Deployment Technology Lead

Deployment Business Lead

Support Center Lead

Program Mercury Phase Specific RACI The following table documents the specific roles and accountabilities of all parties for the Program Mercury Global Design phase. The RACI chart uses these definitions: Responsible (R): The party doing the work to achieve the activity; there is typically one role with a participation type of responsible, although others can be delegated to assist in the work required Accountable (A): The party ultimately answerable for the correct and thorough completion of the activity, and the one who delegates responsibility for the work; the accountable party must sign off on (approve) work the responsible party provides; only one party can be accountable for each task or Work Product in the RACI chart Consulted (C): Those whose opinions or input are sought, typically subject matter specialists; and with whom there is two-way communication Informed (I): Those who are kept up-to-date on progress, often only on completion of the activity; and with whom there is just one-way communication. Often a party “Accountable” for an activity may also be “Responsible” for completing it (indicated on the chart by the activity having a role “Accountable” for it, but no role “Responsible” for its completion, i.e. it is implied.)

Program Mercury Phase Specific RACI - PMO

Program Mercury Phase Specific RACI – Change Management

Program Mercury Phase Specific RACI – Training

Program Mercury Phase Specific RACI – Functional/Process

Program Mercury Phase Specific RACI – Analytics & Controls

Program Mercury Phase Specific RACI – Technical

Program Mercury Phase Specific RACI – Data Migration & COE

Program Mercury 8. High Level Scope

Organization Scope The Program will design and deploy a single, common solution for all EY Network Members globally other than those specifically excluded, including EYG Services and its existing and planned shared service functions (including GSS and Regional Finance Centres). The following EY member firms are excluded from the Program: Syria Material changes to the EY organization, such as creation of new entities, acquisitions, mergers, consolidations or reorganization of current businesses may impact the overall work effort. These types of changes will be jointly discussed between EYG Services and IBM and will be addressed though the Change Control Procedure.

Process Scope The following table details the SAP Level 3 processes in scope for the Program Mercury Global Design Phase. The definition of a Level 3 process is based on the definitions outlined in the SAP Modelling Handbook – Modelling Standards as follows: “The Business Process is the level that aggregates business oriented functions or steps to a unit that is meaningful and comprehensive in the sense that the steps or functions incorporated are essential to fulfil a business mission related task. I.e. a Business Process is defined by steps that transform an input into an enriched output”

Process Scope (cont.) The following definitions shall apply with respect to the complexities indicated below: High Complexity shall be defined as processes that are unique and/or not supported by the solution capabilities that will require significant design changes to the solution (SAP/Legacy) enabled through complex WRICEF development Medium Complexity shall be defined as processes that are supported by the solution, but changes to the solution may still be required to enable the process, enabled through WRICEF development Low Complexity indicates that the processes are standard and are supported by the solution with minor to no changes to the design or impact to EY’s current processes, as supported through system configuration

Process Scope – Client Service DeliveryClient/Account Maintenance

Process Scope – Client Service DeliveryEngagement Pricing & Maintenance

Process Scope – Client Service DeliveryResource Scheduling

Process Scope – Client Service Delivery:Engagement Economics - Monitor Budget/Estimate to Complete (ETC)

Process Scope – Client Service Delivery:Engagement Economics - Time and Expense & Billing

Process Scope – FinanceProgram Accounting & Accounts Receivable

Process Scope – FinanceTreasury / Cash Management

Process Scope – FinanceAccounts Payable

Process Scope – FinanceRecord to Report

Process Scope – FinanceFixed Assets

Process Scope – ProcurementItem and Supplier Maintenance & Sourcing to Contract Management

Process Scope – ProcurementProcure-to-pay, Supplier Management & Spend Performance Management

Technical Infrastructure Scope IBM will design and specify the required technical infrastructure to support the Program. The technical infrastructure scope will comprise the following main components: The number of SAP components, required landscapes (such as Sandbox, Development, Quality Assurance Systems, Production), number of SAP instances (including Java, Netweaver, Sybase, BI/BO and ABAP needs by instance) and High Availability (HA) and Disaster Recovery (DR) requirements The non-SAP bolt-ons and enablers that will be implemented to augment or support the SAP Infrastructure and functionality The tools that will be used to manage and enable the Program The detailed technical infrastructure for the Program will be Accepted as part of the Work Products for the following two Milestones during the Program Mercury Global Design Phase: PM – 16 – Sandbox & Development System Technical Architecture Approved GD – 17 – Technical Architecture Approved

Technical Infrastructure Scope (cont.) The initially estimated infrastructure scope for the SAP landscape components and bolt-ons to support the SAP Application Component Scope and 3rd Party Software requirements as detailed in the Program Mercury Global Design Phase ISOW and subject to confirmation in the previously identified Milestones is listed below and on the following slides.

Technical Infrastructure Scope (cont.)

WRICEF Scope - Basis of Estimate WRICEF Basis of Estimate The following tables detail EYG Services' initial estimate of WRICEF together with the estimated complexity breakdown of the objects. IBM has determined the level of effort associated with WRICEF design, development and testing included in the resource estimates.

Training & Languages Scope Training IBM shall provide any training that may be required in order to properly use the Work Products and/or any IBM provided software and tools, such training being specified in the relevant Statement of Work, provided that there shall be no additional charge for training relating to IBM provided software and tools. Languages The Program Mercury SAP solution will be designed and configured in English. Where required, outputs and forms will be developed in local languages available within the standard SAP product.

Program Mercury 9. Standards and Procedures

Program Operations Table of Contents Operating Principles Key Components of the Program Office Meeting Cadence Integrated Master Program Plan Status Reporting Risk Management Issue Management Change Request Management Time Reporting Collaboration Tools Points of Contact

Operating Principles Governance Issue escalation process established Program Governance tools Scope Clearly defined and stable Roles Clearly defined roles and reporting structure Responsibilities Clearly defined and managed Accountability Dates and deliverables focus with continuous tracking Decision Making PMO RAID Deadlines Dates Are Set – they will not change

Key Components to the Program Office What we do and how you will work with us Program Management Office Program Planning/ Tracking/ Reporting Issue Management Risk Management/ Quality Assurance Scope Management and Change Control

Meeting Cadence

Integrated Program Master Schedule Level 1 – Program Phases Phases are the sequential Program building blocks for delivering the transformation Phases Level 4 – Key Activities The Program Phases and Stages are based on the Major Program Transformation (MPT) Methodology, which incorporates ASAP We have identified the Key Activities required to support initial stages of the program Level 2 & 3 – Program Stages & Sub-Stages Stages represent the major groups of activities within each Phase and will end with a major milestone or work product Sub-Stages represent how we breakdown each Stage Stages Sub-Stages Level 5 – Work plan The Work Plan will contain tasks, resources, dates and links to work products required to deliver the program

Reporting Program – Status Report Status Work Products Exec Summary Activities Risks Issues Resource

Risk Management A Risk Management Process will be followed throughout the Program Mercury to deal effectively and proactively with any program’s risks that may negatively impact any of its aspect and subsequently its success. The objective of this process is to enable the team to identify, document, track and bestrespond to theimpact of program risks throughout the lifecycle of the program. Key activities related to risk management include the following: Why do we need a risk management process? Identification: Identifying and documenting potential program’s problems Evaluation: Analyzing and documenting the potential impact; Prioritizing the risk based on risk level Escalation: Defining the appropriate level of authority for addressing the risk Response: Developing and implementing a risk response approach to best deal with the risk Monitoring: Controlling and reporting on risk management What is a risk? . A risk is defined as the probability of an undesirable event occurring or a desirable event failing to occur and the consequential impact on the program.

Risk Management (continued) How will we manage risks? Any Program team member can identify a risk applicable to a particular aspect of the program (e.g. scope, deliverables, timescales) Risks will be documented by Team Leads using the Program Mercury risk log located in Quickr , providing an easy online access to all program team members. Risks will be categorized by the magnitude of potential impact. To ensure a consistent documentation of the program’s risks, some mandatory information will have to be captured and tracked for all risks. Monitoring The Team Lead reviews the risk, evaluates and documents the risk impact on deliverables, timeframe, resources or program finances. After analyzing the risk and consulting with the appropriate resources, the Team Lead assigns an impact level which will determine the next steps of the risk response: “Low” impact level: Propose a risk response approach and plan, and assign team members to the activities, “Medium” or “High” impact level: the Team Lead will escalate therisk for review and decision as per escalation procedure. Monitoring

Risk Management (continued) How will we manage risks? Risks will be escalated to the appropriate level of authority as follows: A Risk will automatically be escalated if: It is medium/high impact level or could impact activities on/near the critical path, No decision was reached at current level. If a risk has occurred and became an issue, then the issue will be managed in accordance with the issue management process. Monitoring As owner of the Risks Log, the BPI will: Review and discussimpact levels set by the Team Leads during the weekly status meetings, and update as needed, Manage Medium level risks and assign Team Leads to coordinate the response approach and plan (as needed), Escalate High level risks to PMT during Tuesdays’ PMT meeting After a risk response approach and plan have been validated by the appropriate Authority, Team Leads coordinate the risk response plan and communicate the status to PMO weekly. Assigned team members will be responsible for implementing the appropriate risk response activities. Monitoring

Issue Management An Issue Management Process will be followed throughout the Program Mercury to manage any issue that may impact the success of the program. The process will be used to deal effectively and timely with the program’s issues throughout the program’s lifecycle. The objective of this process is to enable the team to identify, track and resolve issues promptly, and therefore manage the program’s problems. Key activities related to issue management include the following: Why do we need an issue management process? Identification: Identifying and defining issues Evaluation: Analyzing and documenting the impact and prioritizing its severity and resolution actions Escalation: Defining the appropriate level of authority for resolution Resolution: Developing and implementing issue resolution Monitoring: Control and reporting on issue management What is an issue? An issue is a formally defined problem that is impeding the progress of a program (i.e. resource, timing, priority) and can occur throughout the lifecycle of a program.

Issue Management (continued) How will we manage issues? Any Program team member can identify an issue applicable to a particular aspect of the program (e.g. scope, deliverables, timescales) Issues will be documented by the Team Leads using the program issue log located in the “Quickr” , providing an easy online access to all program team members. Issues will be categorized by type and priority, with an estimated closure date. To ensure a consistent documentation of the issues, some mandatory information will have to be captured and tracked for all issues. Monitoring The Team Lead reviews, evaluates and documents the issue and its impacts on deliverables, timeframe, resources or program finances. After investigating the issue and consulting with the appropriate resources, the Team Lead assigns a severity level which will determine the next steps of the issue resolution: “Low” severity level: the Team Lead will assign Team Members to the issue resolutionactivities, “Medium” or “High” severity level: the Team Lead will escalate theissuefor review and decision as per escalation procedure. Monitoring

Issue Management (continued) Issues will be escalated to the appropriate level of authority as follows: An issue will automatically be escalated if: It is medium/high severity level or will impact activities on or near the critical path It impacts timeframe, resources or program finances and will require a change request (see Change Request Management Process), the issues will be rated “High”. No decision was reached at current level. How will we manage issues? Monitoring As owner of the Issue Log, the BPI will: Review and discussseverity levels set by the Team Leads during the weekly status meetings, and update as needed, Manage Medium level issuesand assign Team Leads to coordinate the resolution plan, Escalate High level issues to PMT during Tuesdays’ PMT meeting After a plan to address the issue has been validated by the appropriate Authority, Team Leads will coordinate the issue resolution plan and communicate the status of issue to PMO weekly. Assigned team members will be responsible for implementing the appropriate resolution activities. Monitoring

Change Request Management An Change Request Management Process will be followed throughout the Program Mercury to manage any arising changes that may impact the success of the program. The process will be used to deal effectively and timely with the program’s changes throughout the program’s lifecycle. The objective of this process is to enable the team to promptly identify, and properly address changes. Key activities related to Change Request management include the following: Why do we need an Change Request Management process? Identification: Identifying and defining the changes Evaluation: Analyzing and documenting the changes business case (i.e. nature, impact) Decision: Defining the appropriate level of authority for decision Execution: Developing and implementing plan to address changes Monitoring: Controlling and reporting changes What is a change? A change is a formally defined modification or deviation from the Program’s initial assumptions with impact on the agreed scope of work, and/or associated schedule, and cost.

Change Request Management (Continued) How will we manage Program changes? Change Requests will be identified as part of the Issue Management process activities. Only the PMT can add Change Requests on the log. All requests are an output of PMT decisions on High Level issues. Preliminary change request information will be logged by the PMO in the Program Mercury “Change Request log” located in “Quickr” . An issue reference number will be documented to ensure that issues and change request logs are cross-referenced. Monitoring Further details of the Change Request will be documented by the Team Lead following initial information completion by the PMO. To ensure consistent documentation of the changes, as well as a complete assessment of the related impacts, some mandatory information will have to be captured and tracked for all changes.

Change Request Management (Continued) How will we manage Program changes? After it is logged in the Change Request log by the PMO, the Program Mercury “Change Request” is sent to the Team Lead for review, evaluation and documentation of a detailed “business case”. The sections of the form provide specific detail as relates to: Impacts analysis on the Program Costsassessment of the Change execution Overall impact level of the change request Priority determination of the Change execution After investigating the change, the Team Lead will send the change request business case to the BusinessProcess Integration (BPI) for review Monitoring The BPI confirms the Change Request business case and change Impact Level, and sends to the PMT for further action: Low and Medium Impact Level: PMT reviews the business case and makes a decision, High Impact Level: PMTescalates tothe Design Control Board for decision. Change requests status will be set to either “Approved”, “Rejected” or “On-Hold”, based on the decision of the PMT and/or DCB Approved Business Cases will be posted in Quickr for consultation by Team Leads. Monitoring

Time Reporting - EYG

Time Reporting - ITS

Time Reporting – Advisory

Time Reporting – Advisory (continued)

Time Reporting (continued) Working in Secaucus When working in Secaucus, team members need to be on-site no later than 10am Monday until 5pm Thursday; otherwise, look at coming in Sunday evening or leaving Friday Local resources are expected to be on-site Monday through Friday U.S. based team members will be on-site every week Monday through Thursday with a rolling Friday on-site coverage International based team members will work with the respective Work stream Team Lead to determine the appropriate travel schedule

Collaboration Tools A central home space for all team members Team Libraries will be utilized to manage work products Manage and track issues, risks, and change request logs Reserve off-line conference rooms within the calendar Manage vacations within the calendar view Will have program announcements centrally located Program discussion threads Useful links to SAP, IBM, engagement codes, org charts, etc.

Program Mercury Collaboration Tools

Collaboration Reference Materials

Program Document Repositories

Collaboration Tool (SharePoint)

Tools Usage by Program Lifecycle Phase

Process Level Work Products Business Case Legacy Change Mgmt Risks Infra- structure Issues Cross Team Process (Maintain Engagement) BPD Process Model GAP GAPs KDD KDDs KDE KDEs CSD CSDs xFS xFS xTS xTS Test Script xTS xTS Test Result BPP BPPs Solution Manager Sharepoint ARIS HP ALM uPerform

Work Product to BPH Alignment – Global Design Program BPH Process node contains documentation for: Core Business Processes Master Data Processes BPH Master Data node Contains documentation for: Master Data definitions Master Data Key Data Element ie: Cross Functional Scenario Key Design Decision Scenario ie: Purchasing Master Data Master Date Key Data Element Business Process Business Process Business Process Business Process BPH Node GAP Document WRICEF Functional Spec Process Step

Status - Business Process Design Document 9. Rejected – 20% Needs rework 1. Not started – 00% Specification not started 2. In Progress – 25% Specification in progress 3.Stage 1 Completed -50% BPD 3.1 – 3.4 & 3.10 4.Ready for Review -75% All section of BPDD 5. DGPO Approve - 95% All sections completed, Team Lead approved,DGPO approved 6. GPO Approved – 100% Completed 7. Cancelled – 150% Removed from scope 8. Deferred - 175% Removed from scope Not Started Rejected In Progress Stage 1 Complete Ready for Review DGPO Approved GPO Approved * * Locked for editing Cancelled* When to use: To document the business process for a scenario. Deferred*

Status - WRICEF Functional Specification Process Lead Approval No Yes 1. Not started – 00% Specification not started 2. In Progress – 25% Specification in progress 3.Ready for Review -75% Ready for review 4. Process Lead Approval Process lead approval 5. Completed -100% WRICEF Approved 6. Cancelled – 150% Removed from scope 7. Deferred – 175% Removed from scope Not Started In Progress Approved Ready for Review Technical Communication 8. Technical Communication Completed * * Locked for editing When to use: To document functional specification for a process Cancelled* Deferred*

Status - GAP 1. Identified – 00% GAP open 2. In Progress – 25% GAP in progress 3.Ready for Review – 75% Ready for review 4. Completed – 100% PMO Accepted 5. Rejected - 100% PMO Rejected Identified In Progress Approved Ready for Review Completed * Rejected * * Locked for editing When to use: When a mandatory business requirements can not be met by the SAP application.

Status - Key Data Element Process Lead Approval No Yes 1. In Progress – 25% Change request in progress 2.Ready for Review – 75% Ready for review 3. Process Lead Approval Process lead approved 4. Completed -100% Completed In Progress Ready for Review Approved When to use: A customized field is required A standard field is used in a unique way . Completed * * Locked for editing

Status - Key Decision Document 1. In Progress – 25% Change request in progress 2. Completed – 100% Completed In Progress Completed * Approved When to use: Document a Key Decision that was made for a Business Process

What is Solution Managers – Work Product Management Central storage of all Program documentation in SAP Knowledge Warehouse with the main focus on Business Blueprint and Configuration Provides functions to create, edit, store, upload, and download documentation (in SOLAR01 / SOLAR02) Predefined templates / document types are shipped with SAP Solution Manager: Templates for scenario descriptions, diagrams, and installation guides Customer Input Templates (CITs) Templates for interfaces, forms, and reports Creation of Program-specific documentation types and templates

Solution Manager – Work Product Features Add a Work Product Create a Work Product using a template Upload a Work Product View a Work Product Change a Work Product Change directly Sign-in /Sign-out Maintain Attributes Keywords Status codes Remove a Work Product

Solution Manager Keywords

Solution Manager File Naming Conventions Description Team Sequential Number <Team>_<Doc>_<nnnn>_<Geo>_<Description> Document Type BPD - Business Process Definition CDF – Conversion Functional Specification EDF – Enhancement Functional Specification FDF – Form Functional Specification IDF – Interface Functional Specification KDE – Key Data Element KDD – Key Decision Document RFD - Report Functional Specification WFD – Work Functional Specifciation Document Type Geo – WW, CA, UK TEAM PRO - Procurement FIN - Finance SDA – Service Delivery Administration GEO 2 Character code for the area – WW =World Wide

Work Product Roles

Reporting Document Attributes Status Values Documentation Type Priority Keywords (such as Team Names, Releases, etc. Person Responsible Reporting Capabilities Standard SAP Reports Detail Status Entry Dashboard

Program Mercury 10. Quality Plans and Standards

Program Mercury Quality Plan Please reach out to the PMO for access.

Program Mercury

Program Mercury

Presentation Transcript

Program Mercury

Mercury

Mercury

Update on CAMR Mercury Monitoring Program

mercury

Mercury

Mercury

Mercury

Mercury

Mercury

Mercury

Mercury

Mercury

MERCURY

Mercury

Mercury

Mercury

Mercury

Program Mercury Latest Scenario January 2014

CBDA BIOSENTINEL MERCURY MONITORING PROGRAM

Mercury Monitoring Under a Trading Program

Mercury Program

Mercury Program