Program Mercury Program Charter.

Program Mercury Program Charter

Program Charter – Table of Contents
Topic 1. Executive Summary 2. Business Case 3. Current Situation Assessment 4. Program Approach 5. Governance 6. Program Organization 7. Program Roles and Responsibilities 8. High Level Scope 9. Standards and Procedures 10. Quality Plans and Standards

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).

Our Global Finance Vision...
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 2010 Jersey 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... Guiding Principles for Program Mercury EY Transformation Approach for Program Mercury 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 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

Vision 2020 Key points You might say ...
PRESENT Key points You might say ... This graphic depicts the main elements of Vision Let me explain a little more about what each of the pieces mean and why they’re important. We will all unite under one purpose, ambition and strategy. Our purpose is: building a better working world. Our ambition is: by 2020 we will be a US$50b distinctive professional services organization. We will have the best brand. We will be the most favored employer. We will be #1 or #2 in market share in our chosen services. We will have leading growth and competitive earnings sufficient to attract and inspire world-class talent. And, we will have positive and strong relationships with our stakeholders. And our strategy is quite simply “how we will get there.” There are three pillars to this: 1. A relentless focus on winning in the market ... by delivering exceptional client service, streamlining our account landscape, innovating our services, investing in sectors, dominating in the emerging markets, empowering and supporting partners to win in the market, investing in technology and investing in knowledge. 2. Creating the highest performing teams ... by attracting, developing and inspiring the best people, and by committing to a culture of world-class teaming. 3. Strengthening global and empowering local ... by simplifying our operating model and taking advantage of our global scale. Next slide: Purpose: who we are and why we exist Link: I’d now like to take each of these in turn and look at them in a bit more detail. I’m going to start with purpose and ambition. Over the coming weeks and months, our focus is going to be very much on strategy, but it’s essential that we understand the purpose and ambition that the strategy supports.

We are grouping the Vision 2020 Finance actions into themes

Finance response to Vision 2020
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 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 Our approach Finance Strategy Implementation Themes 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

Global Finance Vision is to be ... Global Finance FY13 Priorities
Finance vision and FY13 priorities Global Finance Vision is to be ... Global Finance 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
Existing Global Finance Vision Remains Intact Vision 2020 Alignment Rough timeline for Accelerating Finance Globalization 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

Transactional services (GSS)
Exceptional Client Service Framework Our customer service framework Technology & Process enablement (Desktop / On-line, available on-demand) Business Advisors Finance Transactional services (GSS) Customer segments Delivery mechanism Dedicated resources accessible directly and without delay by customer Executive Regional managing partners Global 360 Account partners On-Site delivery along side customer Virtual support in nearby office Shared resources providing direct coverage to multiple customers Remaining Global Accounts Region SL & SSL management Legal Entities Market Segments Remote, near-shore support On-demand access to ad-hoc advisory support Core account partners 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 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

Role of the SLAs for Finance:
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 Consumption based pricing Partnership with the customers Finance User Panel Quality Standards Continuous Improvement

Critical success factors:
Finance Academy 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 “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

Top quartile performance
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 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, ,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 Practitioners & Client Serving OCA /Business/Service Line/Geography Financial, Accounting & Procurement Lack of integration across -- acceptance, pricing, budgeting, scheduling, and billing Lack of mobile connectivity to perform key client serving activities Inadequate data management controls Lack of scalability in service delivery processes Lack of integrated view from pursuit to engagement close Lack of effective process to handle partner credit Lack of account /cross client views and consistent KPIs Lack of global resource management on cross border engagements Inconsistent engagement profitability management Lack of automation, workflow, and consistent policies and governance Difficulties tracking, recording, reporting, and measuring business today Not able to support management and statutory books/reports in one system Limited visibility into spend and payment data Today Tomorrow 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

Make it work for all Service Lines and Practice sizes
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
People Processes Technology ONE team: Represent your constituents but our goal is getting to One Ernst & Young Go slow to go fast: Develop the right global process design, technical solution and architectural solution. Deploy with a repeatable process Pursue a single global instance Empower people, then hold them accountable: Allow people to make choices and decisions, but make it understood they will be accountable for their actions Design once, deploy as needed: Develop one Global Template, deploy with timing that meets business needs Build for high availability Address people issues quickly and fairly Global Enterprise focus: Think outside the box of your specific Business Unit or Geo Implement “vanilla” software Realize value: Eliminate work that offers no value to customers, impedes execution speed, or serves no regulatory/legal purpose

Program Mercury Guiding Operating Principles (cont.)
People Processes Technology Embrace change: involve the broad EY community in creating superior cross-company operations Simplicity over complexity, standardize when possible: The process of choice is the best practices in SAP Make doing business with EY significantly easier for clients and Business Partners Complexity only when no other options satisfy business needs Make Rigorously pursue data management & EAI strategies Ensure single source of truth Use the bus; eliminate point to point interfaces Seek standard solution – not necessarily perfect Streamline application portfolio: Stay within the SAP suite unless there is no proven solution within SAP suite that can solve the business problem Keep the pace of the program: Think quickly, be decisive and escalate quickly if deadlocked Change the process, not the software We will not pursue leading edge or immature solutions, unless there is clear EY competitive advantage or no viable alternative exists. Question the status quo but manage the change: Challenge what has been done before but keep focused on the task at hand Showcase for EY

Program Mercury 2. Business Case

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

3. Current Situation Assessment
Program Mercury 3. Current Situation Assessment

Support Teams / Finance & Accounting
Procurement Challenges & Benefits Summary – Back office leaders are most concerned with… Future Benefits Improves Procurement effectiveness by creating a platform that addresses consistent processes and tools globally, but agile enough to support global, region and local buying Provides KPIs and visibility to A/P data to optimize commercial management strategies Optimizes usage of GSS structures for transaction related activities and reduce costs for the Procurement function itself Focus on tracking and control at request allows better estimation of financial liabilities and cash planning Improves Firm’s control over spend proactively, rather than at invoice time, when payment is obligated Allows visibility of all Procurement contracts, at global, region and local level Ensure end-to-end view of procurement with asset tracking/ownership Allows common coding of A/P for better tracking and analytics Allows better opportunity identification through consistent global data and analytics Allows tracking that savings are realized 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

Executive & Management
Service Delivery Administration Challenges & Benefits Summary – Executive and Management are most concerned with… Business Challenges Future Benefits Supports future organizational structure and shifting KPIs as part of Vision objectives - Improves business effectiveness by creating an agile platform that addresses changing business models and enhances organizational flexibility Flexible reporting to support unique needs of a multi national / global organization. Efficient , accurate and consistent Account and Client hierarchy management used by ALL integrated systems to enhance seamless workflow . Reduces manual intervention and propensity for error caused by off line consolidations Reduces risk by improving data accuracy, controls and transparency of our performance Streamlined and integrated systems that minimize duplicative efforts Move to an efficient ‘self service’ environment reducing the cost of support functions Better enable Client Service Practitioners to focus on Client needs rather than gathering and analyzing information Creates scalable and flexible processes allowing locations to maintain their business models but operate within a common framework that delivers the highest value to our clients 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… Future Benefits Provides a common process and systems structure for all service lines and geographies to come together in support of EY’s global strategies Provides streamlined, scalable and flexible client and engagement acceptance and maintenance processes that reduce time, leverage integration and improves data consistency Improves engagement economics for a seamless flow from engagement initiation to engagement financials Promotes improved Partner teaming behaviors. Eliminates workarounds and associated overhead, e.g. creating additional codes for one engagement Simplifies billing efforts on large Global engagements by leveraging InterOp and Central billing concepts Consistent pricing and margin management tool that enables teams to plan engagements consistently and with a view on improving economics through leverage and GTH usage Single, Global resource scheduling system allowing the ability to build resource plans across jurisdictions. 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 Future Benefits Allows increased visibility for better global resource scheduling and management Provide ability to easily identify, reserve and deploy the right resources for the right Programs. Eliminates the current manually intensive process, with sub optimal visibility and results with lower than desired usage and acceptance Business Development engaged in team selling through collaboration, communication, and management of critical activity and task details with their extended sales team Reduce or eliminate the use of additional engagement codes and associated overhead Role-based systems access given to broad users community Provides common enterprise tools to support client servers with seamless service delivery management Complex Programs are managed effectively by seamlessly integrating Program and resource management capabilities Enables streamlined service delivery administration processes to allow support teams to focus on adding value through analysis 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

Executives & Engagement Leaders
Finance Challenges & Benefits Summary – Executives are most concerned with… Future Benefits Increased process efficiency and effectiveness by having ONE system as well standardized, harmonized and integrated global finance processes reduces cost of finance function Provides a catalyst for change to state-of-the art global finance organization Align finance resources to focus on Vision 2020 execution and on the topics critical to the new strategy Decommission ~1,400 global and local systems Supports future organizational structure as part of Vision 2020 objectives Improves effectiveness by creating an agile platform that addresses changing business models and enhances organizational flexibility Provides a catalyst for globalization through standardized and integrated finance processes across EY Access to a financial cockpit and/or dashboard that provides timely view into KPIs Allows for seamless consolidation of financial data and enhanced analytical capability One system to support internal as well as external accounting requirements, ie Management & Legal/Statutory reporting Better support for management reporting across multiple dimensions (Area, Subarea, Sector) Flexible reporting to support unique needs of a multi national / global organization Reduces manual intervention and propensity for error 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 Future Benefits Provides a common process and systems structure for all service lines and geographies to support reduction of cost of finance function Provides streamlined, scalable and flexible client and engagement acceptance and maintenance processes that reduce time, leverage integration and improves data consistency Improves engagement economics for a seamless flow from engagement initiation to engagement financials Eliminates workarounds and associated overhead, e.g. creating additional codes for one engagement Simplifies billing efforts on engagements by switching to a workflow based centralized billing process as well leveraging Interoperability for all cross border engagements Consistent pricing and margin management tool that enables teams to plan engagements consistently and with a view on improving economics through leverage and GTH usage Consistent definitions and methodology for all pricing attributes Allows parties to understand their margin/profit share prior to proceeding as well as to get rid off manual intervention to “restate” numbers for pricing and reporting 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 Future Benefits Improves finance effectiveness by creating an agile platform that addresses changing finance landscape and enhances organizational flexibility Provide KPIs to help reduce risk, improved control and transparency of business performance as well as to manage transactional volume Optimize usage of GSS structures for transaction related finance activities, ie . Forward looking Programions including pipeline and backlog Enables finance people to focus on adding value through analysis Increase process efficiency and effectiveness by harmonizing and simplifying global finance processes Streamlined and integrated systems that minimizes duplicate efforts Allows for seamless consolidation of financial data and enhanced analytical capability Reduces risk by improving data accuracy, controls and transparency Improved visibility allows better analytics of actual spend via integrated processes facilitated by a single source system 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

Executives & Engagement Leaders
Procurement Challenges & Benefits Summary – Executives are most concerned with… Business Challenges Future Benefits Aligns processes and tools to support Vision 2020, including enabling the new Global Procurement organization and strategy Enables Global Procurement to develop global, region or local commercial management strategies, as appropriate, for more effective supplier management through visibility of global spend and suppliers Enables more cost savings through better management and control of demand, sourcing and compliance activities Allows decommission existing legacy Procurement systems; conservative estimate: $3- 4m Global visibility and analytics of data allows the development of common commercial management strategies to reduce indirect and direct costs for the Firm, leveraging global and regional volume purchasing, as appropriate 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 Future Benefits Reducing direct and indirect costs makes Firm services more competitive In terms of professional rates billed to clients In terms of expenses billed to clients Increase productivity of client-serving staff with the provision of support services, especially when travelling to client sites, with less individual effort and workarounds(e.g. internet provision, hotel services, etc) Provides basis for consistent strategies that support global, cross-border Programs with significant travel and staff sourced from multiple countries Ensure consistency with and tracking of independence considerations during the Procurement so as not to risk Firm’s ability to bid on or provide services to existing clients Ensure and track involvement of GSPs in RFPs involving clients, so as to protect and support more effective client-relationships Mitigates supplier relationship risks or brand image risks which could result from late payments 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 Key Decision Area Description Revenue Model Recognition models Standard billing rates Utilization measurement Profitability calculation Consistent approach to revenue Streamlined approach for how it should be governed in a global fee-sharing scenario Standard utilization approach to calculating profitability Cost Components Cost rates by rank/ service-line/ offering Cost Allocation approach Function vs. natural account capture Time & Expense (5-4-4) Global standard for calculating costs and cost rates Standardize cost allocation Sync time for revenue booking with indirect expenses Organization (& Legal) Structure Legal entity structure COA Design (Code-block elements) Virtual Organizations Engagement code design Client record ownership & maintenance Ability to design a future state chart-of-accounts through the determination of desired legal entity structure, and code-block elements Streamline design approach to engagement codes for managing and tracking profitability Standardize ownership of client record to properly maintain and record/report performance The Process Team Members will team with Global Process Owners across the enterprise to evaluate potential process improvement opportunities and drive resolution on key decisions

Program Mercury 4. Program Approach

It all adds up to the 80% of the overall solution
Global Design is the portion of the Solution that is common and will be leveraged & shared across EY (80%) Global 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 Q&RM Systems People Systems Local Design Global Design 1 2 Service Delivery Administration Finance Procurement 3 GL Accounts Clients Local Design 4 Local Design 5 Roles Reporting Needs 6 Local Design 7 Market Systems Finance Systems *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 EMEIA Americas Asia-Pac, Japan GSA Jan Apr July Oct 2012 2013 2014 2015 Global Design Pilot Global Deployment (illustrative of multiple go-lives) 2016 Local Design, Build, Final Prep & Go-Live Hyper Care Localization Pre-Work Local Design, Build, Final Prep and Go-Live Support Centers Global and Local Test Global Build 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

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 Inputs Outputs 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. Apr. May Jun. July Aug. Sep. Oct. Design Period 1 9 – 11 April 2013 (TBC) Mobilization L Process Grouping Working Sessions V S 9 – 11 July 2013 (TBC) 8 – 11 January 2013 (TBC) Design Period 2 1 – 3 October 2013 (TBC) Legend L Process Grouping Working Sessions V S L Launch Event 27 March 2013 (TBC) Design Period 3 V Validate Session L Process Groping Working Sessions V S S Design Showcase 26 June 2013 (TBC) 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

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 Mobilization L Process Grouping Working Sessions V S Design Period 2 Legend L Launch Event L Process Grouping Working Sessions V S Design Period 3 V Validation Session S Design Showcase L Process Grouping Working Sessions V S

Business Process Integration Business Process Integration
Our Process Groupings will enable us to focus our resources and attention during Global Design, while ensuring process integration 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 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” Finance Process Groupings (~ 67 Sub-Processes) Process Process Process Process Process Process Procurement Process Groupings (~ 27 Sub-Processes) Business Process Integration Service Delivery Administration Process Groupings (~37 Sub-Processes) Process Process Process Business Process Integration

Global Design Development and Approval Approach
Design Period 1 Operating and reporting elements and complex, critical processes with extensive cross-functional relationships 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” Q3 FY13 Q4 FY13 Q1 FY14 Uniform Set of Global Design Activities Launch Design Validate Approve Socialize 1 Process Grouping Launch Session (GPOs, Deputy GPOs & Process Leads) 2 Conduct Working Sessions (Team, Deputy GPOs,& SMEs) 4 Validation Workshop (GPOs, Deputy GPOs, Process Leads, Team) 5 GPO Sign-off on Design (GPOs, Process Leads, Deputy GPOs) Solution Showcase (Select Team Members, SMEs) 6 Informal Checkpoints (Organized by Process Leads, with GPOs and Deputy GPOs as needed) 3 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 Launch Working Sessions and Informal GPO Meetings 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
Representatives Activities & Key Deliverables Outcomes Process Conduct Global Design Working Sessions Define Future State Processes Create Functional & Tech Designs for Workflows, Reports, Interfaces, Conversions, Enhancements, and Forms (WRICEF) Design Risk and Controls Framework A Global Design that enables standard business processes, organizational design, data, and interface designs all integrated into a common framework to be leveraged across EY People Launch Sessions, Validation Workshops and Solution Showcase Events Communication Strategy & Plan Change Management Strategy Stakeholder Management activities Leadership Alignment activities Program Mercury resources are on-boarded and engaged with the Program Leadership and Stakeholders are engaged and committed Strategies are in place and ready for execution Technology End-to-End Architecture Definition Technical Strategies (e.g., Testing, COE, Co-Existence) Global Legacy System Remediation Data Conversion Approach Physical Design of Production environments A system design exists providing the end-to-end global functionality to support our Service Delivery Administration, Procurement and Finance process domains A clear strategy is in place for how the EY IT Services organization will support the Global platform in Production

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 Structures Short-Interval Schedule

Resources will be aligned per the Process Team Leads
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”

Technical Architecture
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 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) Definition Represents the organization roll-up management and reporting structure Provides the data available in the system to support the transactions and reporting Controls how transactions behave Common, Global, Finance, Service Delivery Administration, Procurement Business Processes Scalable to different practice size and complexity requirements Mapped against organization roles Technical connections with Global Systems needed to support the business processes Links to reporting needed to support the business processes Forms, formats, workflow required to support the processes Real-life EY business scenarios which link together aspects of the previous three columns Scenarios that reflect the way EY executes complex business transactions Examples Legal Entities Management P&L Structures Chart of Accounts Client Roll-up structures Client / Engagement Maintenance Order to Cash Inter-Firm Accounting Record to Report Engagement Pricing Interface to GTAC Interface to CRM (Interaction) EY Format for Client Invoices Data Conversion Cross border Tax Engagements Assurance Engagement that utilizes GTH TAS Engagement with large bonus incentives Advisory Engagement that uses other Service Lines

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 Design, Global Build and Pilot Jan 2013 Feb 2013 Mar 2013 Apr 2013 May 2013 Jun 2013 Jul 2013 Aug 2013 Sept 2013. Oct Nov 2013 Dec Jan 2014 Feb 2014 Mar 2014 Apr 2014 May Jun Global Build Pilot / Localization Global and Local Testing Center of Excellence (Support) Jul

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 7. Develop Code 9. Execute Unit Test 55 55 55 55

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: 1. Planning & Scoping 2. High-Level Design 3. Detailed Design 4. Build 5. Test 6. Deploy 7. Support

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. 1. Planning & Scoping 2. High-Level Design 3. Detailed Design 4. Build 5. Test 6. Deploy 7. Support Program Management People & Organizational Change Benefits Management Solution Architecture Process & Design Reporting & Information Management Data Management Configuration and Development Test Security and Controls Infrastructure Service Introduction

1. Planning & Scoping 2. High-Level Design 3. Detailed Design 4. Build 5. Test 6. Deploy 7. Support 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.

Key Planning & Scoping Activities
2. High-Level Design 3. Detailed Design 4. Build 5. Test 6. Deploy 7. Support Key Planning & Scoping Activities Define business case, vision, and case for change Define Program charter, scope, and budget Identify key stakeholders and capture stakeholder requirements Develop estimating model Understand current-state system and processes Define vendor assessment criteria Define Solution Architecture (application and technical architecture) Define data migration scope, strategy, and tools Evaluate existing risk and control framework and identify key risks Define infrastructure strategy and application decommissioning scope Define service management requirements and strategy

1. Planning & Scoping 2. High-Level Design 3. Detailed Design 4. Build 5. Test 6. Deploy 7. Support 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.

Key High-Level Design Activities
1. Planning & Scoping 2. High-Level Design 3. Detailed Design 4. Build 5. Test 6. Deploy 7. Support Key High-Level Design Activities Updating the business case Identifying change impacts to the organization Determining training delivery methods and tools Identifying super-users Planning proof of concept and creating solution blueprint or design Defining the reporting structure and information Management landscape Defining future-state master data design and data security rules Creating a test strategy

1. Planning & Scoping 2. High-Level Design 3. Detailed Design 4. Build 5. Test 6. Deploy 7. Support 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.

1. Planning & Scoping 2. High-Level Design 3. Detailed Design 4. Build 5. Test 6. Deploy 7. Support 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.

1. Planning & Scoping 2. High-Level Design 3. Detailed Design 4. Build 5. Test 6. Deploy 7. Support Key Build Activities Review Program management plans for revisions and make adjustments Develop future-state organization structure Job and role profiles Define a detailed training plan Collect data, cleanse, and perform mock runs to prepare for legacy data migration Plan for data archiving and build a Master Data Management (MDM) process Fulfill infrastructure and environment requirements for training and testing

1. Planning & Scoping 2. High-Level Design 3. Detailed Design 4. Build 5. Test 6. Deploy 7. Support 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.

1. Planning & Scoping 2. High-Level Design 3. Detailed Design 4. Build 5. Test 6. Deploy 7. Support Key Test Activities Resolving any defects that arise from the testing cycles Retesting defects Delivering key user training Performing dry runs for data migration Preparing for cutover and deployment

1. Planning & Scoping 2. High-Level Design 3. Detailed Design 4. Build 5. Test 6. Deploy 7. Support 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.

1. Planning & Scoping 2. High-Level Design 3. Detailed Design 4. Build 5. Test 6. Deploy 7. Support Key Deploy Activities Recording the successful completion of system and performance tests Ensuring resolution of all critical open defects Completing end user training Implementing future-state organization structure Job and role profiles Running a final check to confirm that the business is prepared to use the solution effectively Confirming readiness to support the solution in production both functionally and technically

1. Planning & Scoping 2. High-Level Design 3. Detailed Design 4. Build 5. Test 6. Deploy 7. Support 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
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.)
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 Severity 2 Major
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-today operations. e.g. Unable to create a new engagement

System Testing (cont.) Severity 3 Minor Severity 4 Cosmetic
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

Communicated to the Organization
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 Alan Guthrie Program Management Team (PMT) Joe Devaney Matthew Samme Dean Hansen Ralf Broschulat Jim Miller Karen O´Neill Successful Governance Principles What is New & Different for EY “Board Level” support – EY COO Approval of GPO Concept Executive Sponsors with “skin in the game” (organization and business case) Business process decisions owned by current & future operators Team comprised of the right representation from the business Establishing GPO structure and their global decision authority Focused Executive Sponsor team with mandate to make decisions as opposed to “decision by committee”

Apply a new “mind set” to determine our true requirements
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 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 global process design and decision making Attaining Them Set of Client Server processes that are integrated on a common platform (i.e., look and feel, mobility) Scalable and flexible to address different practice sizes, capabilities & complexities Take advantage of the policy decisions to support a more globalized solution (e.g., IFRS basis for management accounting) Professional Services template to help reduce system customization Only allow uniqueness where absolutely necessary – Legal, Statutory & Regulatory Program Team will prescribe the design, not seek variations

Empowered team members with clear authority levels
Team Role Decision Category

Our Program organization structure also supports our “One Team” Approach
Business Led Our Executive Sponsors represent the EY Service Lines and Core Business Services Blended Team We picked the best people from Finance, our Service Lines, ITS, our Advisory Practice. IBM & SAP Represent EY’s Global Requirements We are creating a globally used solution to be shared across EY’s segments, countries, Service Lines & Functions Collaborate Across the Team Almost every activity requires an integrated effort and coordination with fellow team members Streamlined Structure A flat organization allows us to make decisions quickly and promotes collective team responsibility The Business is Accountable Our key Process Team Leads come from the Business, process team members are accountable to them

Work Relationships & Responsibilities Discussion
2 Core Team Members 3 1 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 customer required 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
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 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: 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

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 Countries Business - Process Governance 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
Decision rights Executive Sponsors Promote a process-focused organization Provide visible leadership to implement the strategic vision for an integrated global enterprise Resolve issues raised between Global 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 91

Governance - Guiding Principles Decision 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%) Type Qualification Example processes Type 1: Low strategic impact to the core business Accounts Payable GL transactions Type 2: Moderate impact to business T&E Expenses Resource scheduling, processes Master Data Type 3: High strategic impact to core business Tax requirements, statutory Policy change, enablement

Governance - Global Design Decision Making Process
Global Design Fit Gap 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 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 Meeting Schedule TBD by Design Review Board

Governance - Deployment Decision-Making Process
Change request during Solution Confirmation Evaluation / Review by GPO’s/ Deputies Analysis by Mercury Leads Go/No-Go Decision by Deputy/GPO Finalize Deployment Scope and Plan 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

7. Program Roles and Responsibilities
Program Mercury 7. Program Roles and Responsibilities

Executive Sponsors (Business, Finance, IT)
Role Description Program Executive Sponsors provide the strategic direction for the Program and are members of the Executive Leadership Team. There are three Executive Sponsors, each representing a different aspect of the company (the Business, Finance and IT) and all of whom support the Program mission “business driven, process led and technology enabled.” Their role involves ensuring alignment of the Program with the EY corporate strategy from a Business, Finance and IT perspective and steering and focusing the EY organization on attaining and delivering expected business benefits. Responsibilities Serve as members of the GFT (Global Finance Transformation) Steering Group Provide direction to the GFT Steering Group and Executive Leadership Team in conjunction with the Executive Sponsors for Finance and ITS Maintain final authority for priority setting, Program scope approval, budget and schedule, and settling company-wide business related issues associated with the Program Ensure Business, Finance and IT involvement at the executive level Secure dedicated Program resources (people, time and money) Champion the Program throughout EY Serve as members of the Program Executive Leadership Team and participate in the team’s regular meetings Reports To Global Executive Board Key Working Relationships Global Process Owners (GPOs) Executive Leadership Team Time Commitment Part time

Cross Program Leaders (CPLs)
Role Description Cross Program Leaders (CPLs) are responsible for ensuring Program Mercury objectives are achieved and properly balanced against the other transformation initiatives within the GFT portfolio. These leaders are part of the Executive Leadership Team. They will provide, as needed, more detailed insight on Executive Sponsor direction and objectives to the Program team leadership, and provide perspectives of other EY executive bodies to the Program team. CPLs will assist with communication of Program implications to the Executive Sponsors and with the broader EY executive community . They will also help prepare the EY support and governance organization to sustain the business finance and technology solution for the future. These roles require strong transformation experience and an understanding of EY culture and executive relationships. Responsibilities Oversight and guidance on inter-project coordination and priorities Ensure proper coordination, scope definition, issue resolution and assist with resource allocations between Project Mercury and other GFT initiatives. Provide day-to-day guidance on Executive Sponsor priorities and insights Responsible for ensuring program communication to Executive Sponsors and other EY executive bodies Provide direction to Program team on issue resolution prior to Executive Sponsor involvement Assist with resource allocation Oversight of budget Serve as members of the Executive Leadership Team Reports To Executive Sponsors Key Working Relationships Program Leader Global Process Owners (GPOs) Executive Leadership Team Executive Bodies - i.e. OEC, FEC, GFT Steering Group Time Commitment 2 – 3 days a week

Key Working Relationships
Program Leader Role Description The Program Leader, who is part of the Executive Leadership Team, is responsible for the overall definition and day-to-day management of the program while creating an environment that will lead to a successful outcome. This individual will maintain strong working relationships with the Executive Sponsors, Cross Program Leaders, the Global Process Owners and key executive stakeholders from across the business, communicating on program matters, providing regular updates on program progress and soliciting input. This role requires strong decision making and communication skills, a thorough understanding of EY culture and an independent viewpoint. Responsibilities Define the program approach, methods, structures, organization and scope Define the governance process needed to position the program for success within EY Define the governance process needed to most effectively run and manage the program Provide day-to-day leadership and management of the program team Create the approach and structures that allow EY to develop global business processes, (including business/function input and their acceptance) to meet requirements Provide regular status and decision updates to the GFT Steering Group, OEC, FEC, Executive Sponsors, Area Leaders and other groups of EY executives Establish a network of Business/Functional representatives to engage with the program and ensure the success of those relationships Manage program level leadership and cross functional leader teams Direct and oversee program activities, tasks and deliverable completion Achieve the right quality level and outcome of program tasks, activities, and deliverables Serve as member of the Executive Leadership Team and head of the Program Management Team Provide expertise and perspective to all areas of the program, including but not limited to: Business process design ERP technology Change management Data Governance Organizational impact Deployment strategy Reports To Cross Program Leaders Key Working Relationships Global Process Owners Executive Leadership Team Program Leadership Team GFT Steering Group Area/Function Business Representatives and Executives Time Commitment Full Time

ERP ITS Lead Role Description The ERP ITS Lead, a member of the Executive Leadership team, is responsible for managing and facilitating EYG information technology activities of the program that are outside the contractual responsibility of the systems integrator. This includes the design, build and test of legacy system and global application (for example EDW) changes required for implementing the ERP package, and the necessary integration work. Responsible for the definition, procurement, rack and stack, build, environment management and release management for all technical environments within the scope of EY. Responsible also for ensuring ITS plays a pro-active role in defining, planning and executing the deployment strategy (including application sun-setting). Part of the overall management team responsible for day to day management of the ERP program governance, plan and delivery Responsibilities Overall responsibility for managing the technology and infrastructure matters during the delivery of Program Mercury to the agreed timelines and quality assurance standards Responsible for the following: Manage Enterprise Architecture Procurement, set-up and maintenance of Technical Infrastructure Manage Application Development including legacy systems changes and integration to the ERP platform Manage Legacy Systems and Integration Environment & Release Management Oversee setup and maintenance of system environments (test, QA, sandbox, production, etc) Manage list of systems subsumed Represent program and technology issues and requirements for the company Serve as member of the Executive Leadership Team and Program Management Team Reports To Program Leader Key Working Relationships Executive Leadership Team Program Leadership Team ITS CBS Organization (both headquarters and local) Time Commitment Full Time

Systems Integrator (SI) Lead
Role Description The Systems Integrator Lead provides advice on the SI solution functional and technical strategy. This position is held by the external SI program manger. In this role, the SI Lead is responsible for the oversight of SI related program relationships and SI program team members, as well as the proactive management of SI related issues and risks. Responsibilities Ensure SI best practices are applied to the solution design, project plan, and roles and responsibilities Provide strategic direction for SI program team members (consultants) Assist with the development of the overall project plan Provide direct management of SI team members including the resolution of personnel issues, etc. Provide support and advice for the Program Leadership Team Advise on global deployment strategy Advise on scope Manage budget within SI scope, working with the Program Leadership Team Serve as member of the Executive Leadership Team and Program Leadership Team Reports To Solution Design & Delivery Lead Key Working Relationships Executive Leadership Team Program Leadership Team Business Process Teams ITS Time Commitment Full

Process Integration Lead
Role Description The Process Integration Lead, who is part of the Program Management Team, ensures the development of standardized, global, harmonized business processes for all EY Service Lines, Organizations and Areas while meeting the needs of varying practice sizes. This position will make sure the processes are integrated end-to-end for efficient and effective access to data and reporting support. The Process Integration Lead will ensure process design and delivery seamlessly links to, and drives other workstreams, such as Data Management, Change Management, Technology, Deployment etc. The Process Integration Lead also assists the Program Leader with communicating the new process design to the GPO community with the objective of reaching agreement and gaining approval. Responsibilities Responsible for coordinating the overall integration of the future state processes and the day-to-day project management of the process teams Responsible for Finance, Service Line and Procurement process activities, creating, controlling, improving them along with assisting in deploying them Coordinate and collaborate work with all the process, change management, and technical team leads to ensure integration of all in-scope business processes within the program. Coordinate and work closely with the Global Process Owners to ensure the Service Line, Organization and Area requirements are properly addressed, without jeopardizing the overall vision for global processes Leads the process design teams, providing direction and daily management Champion process commonality across the EY enterprise and provide leadership in resolving cross team integration issues Ensure that the program approach addresses the unique needs of the Business Units and geographies without compromising the agreed to Global Temple Design Ensure smooth and integrated processes across the full value chain Provide insight to process design ensuring consistency, integration and standardization Serve as member of the Program Management Team Reports To Program Leader Key Working Relationships Program Leadership Team Global Process Owners Global Process Owner Network Time Commitment Full Time

ERP Solution Design and Delivery Lead
Role Description The ERP Solution Design and Delivery Lead, who is a member of the Program Management Team, is responsible for managing the ERP technology for design, build and test to support the business defined requirements. They will help shape and define the technical solution and ensure best practice is adopted where possible and keep the technical solution as “standard “ as possible to minimize development and future on-going support costs. This Lead will work closely with the ERP ITS Program lead to ensure the ITS strategy and roadmap is followed and be a key point of Integration back into the Global ITS portfolio. The role will own the day to day management of the System Integrator (SI) and be the first point of escalation of SI related risks / issues and will ensure the agreed SI spend is managed to budget while owning first line responsibility for SI related changes. This lead will own the definition of the future state operating model to support the solution deployed, and they will define and build the Support Center to support the end state operating model. Responsibilities Bring ERP solution / industry / product best practice within their leadership team Manage all aspects of technical solution build and test for the ERP solution Manage system test, integration test and performance testing of the solution Manage all program level ERP Solution related risks / issues Report progress to Executive Leadership and key stakeholders as per the program meeting cadence in collaboration with the ERP ITS lead and ERP Business lead Work with the ERP ITS lead to shape and define the deployment roadmap and implementation plan Work with the ERP ITS lead to define and implement the future state Support Centers for Program Mercury after go-live Serve as member of the Program Management Team Reports To Program Leader Key Working Relationships Program Leadership Team Executive Leadership Team ITS Time Commitment Full Time

Program Management Office (PMO)
Role Description The Program Management Office (PMO) provides centralized administrative functions in support of the Program Management Team (PMT). This includes coordinating program infrastructure, program administration and status reporting. The PMO is responsible for defining and managing the program related administrative processes, procedures, templates, etc., and controlling the collection of information and the generation of performance reports on behalf of program managers. The PMO includes the following three roles: PMO Manager PMO Administrative Assistant PMO Financial Analyst Responsibilities Establish program infrastructure Manage and maintain the integrated project plan including tracking deliverables, milestones and schedule Manage issue and risk logs to ensure the identification, escalation and resolution of risks and issues in a time efficient manner to minimize impacts to the program Establish metrics for measuring program tasks against established targets, standards and guidelines to ensure the creation of quality deliverables Maintain program documentation in a central repository Administer project tools and methodology Provide program team training to educate the team on the project processes, tools and methodology Coordinate space and hardware Manage time and status reporting Reports To Program Leadership Team Key Working Relationships Business Process Teams and Cross-Functional Teams Time Commitment Full Time

Global Process Owners (GPOs)
Role Description The GPOs are EY Executives responsible for each business process within the Global Template Design ensuring adherence to an enterprise design approach that best meets the needs of all individual Service Lines, Organizations, Areas and overall EY. GPOs have decision making authority for sign-off on all business policy, process and procedures for their assigned process area. GPOs are responsible for working with all impacted Service Lines, Organizations and Areas to ensure a successful transformation of their business processes and soliciting their input as needed Responsibilities Work with EY Service Lines, Organizations and Areas to understand issues and pain-points and help refine the scope Focus on finding the solution that balances Service Line, Organization and Area functions and the greater EY Sign-off on all business process and policy decisions pertaining to their respective process areas. Report to and coordinates closely with, the Program Executive Sponsors on a regular basis Work closely with the Program Leadership Team and the Process Leads to review design decisions, scope, and implementation issues Serve on the GFT Steering Group Preside over the Design Control Board when their process area’s issues and changes are presented Escalate unresolved enterprise/cross-functional issues to the Executive Sponsors Champion of the program throughout the organization Role extends post implementation to continue maintenance/governance of their business processes on an on-going basis Reports To GFT ERP Executive Sponsors Key Working Relationships GFT Steering Group Global Process Owners (GPOs) Global Process Owner Network Program Leadership Team Business Process Teams Time Commitment 4 – 6 hours per week

Global Process Owner Network
Role Description The Global Process Owner Network is network of EY personnel who will support the GPOs to establish global business processes. GPOs may utilize the whole GPO Network as needed; network members do not report to a single GPO. They will provide input to the design of supporting systems and processes in order to ensure their respective Area needs will be accommodated. Membership will be representative of EY Service Lines, Organizations and Areas. These individuals will facilitate engagement of Subject Matter Representatives (SMRs) as required to ensure the global needs of business areas and geographies are accommodated. These individuals will be leveraged throughout the program to represent major stakeholder groups offering guidance and input for the Global Template Design Responsibilities Work with the Global Process Owners to ensure representation of the various Service Lines, Organizations and Areas are represented Serve as “change agents” within their respective Service Line/Organization/Area Champion policy changes required to achieve future-state Build commitment among the various stakeholder groups Advocate the Global processes and explain them to the business Ensure that the standardized global processes will be adopted by all areas Help resolve site specific conflicts and ensure all decisions made will benefit the global business rather than just local or regional needs Attend and contribute to the process design workshop(s) as needed Help resolve questions/issues identified during the design and/or implementation phase Reports To Global Process Owners (GPOs) Key Working Relationships Global Process Owners Global Process Owner Network Business Process Teams Time Commitment 4 – 8 hours per week

Global Process Owner Deputy
Role Description GPO Deputies report to and represent their assigned Global Process Owner (GPO) in managing the day- to-day GPO-related issues and activities in their respective process areas. Deputies are responsible for supporting each business process’s Global Template Design ensuring adherence to an enterprise design approach that best meets the needs of the individual Service Lines, Organizations, Areas, and overall EY. GPO Deputies are responsible for working with all impacted EY Service Lines, Organizations and Areas to ensure a successful transformation of the business processes. Responsibilities Work with EY Service Lines, Organizations and Areas to understand issues and pain-points and help refine the scope Focus on finding the solution that balances Service Line, Organization and Area functions and the greater EY Report to and coordinates closely with their GPO on a regular basis Work with the Program Leadership Team and Process Team Leads Work with members of the GPO network Preside over the Design Control Board when their process area issues and changes are presented Escalate unresolved enterprise/cross-functional issues to their GPO Maintain strong knowledge of and network within, their process area Coordinate with the KPD Integration Lead Identify and ensures the right SMRs are involved Identify key stakeholders that need to be consulted on a GPO issue Champion of the program throughout the organization Reports To Global Process Owners (GPOs) Key Working Relationships Global Process Owners (GPOs) Global Process Owner Network Program Leadership Team Business Process Teams Time Commitment 16 hours per week

Process Team Leads (Procurement, Service Delivery Administration, Finance) Role Description Business Process Leads, who are members of the Program Leadership Team, will be responsible for driving day-today process design activities in pursuit of common global solutions. They will work closely with the GPOs and GPO Network to define processes and systems. During localization and roll-out they will work with Sub Areas to accommodate the legal and statutory needs of each market while enabling implementation of the global processes at a local level. The Business Process Leads will work collaboratively across Service Lines, Organizations and Areas to develop solutions that accommodate the collective needs of all. Responsibilities Provide day to day management of Process team project activities along the project life cycle (e.g. Start up and Prep, Global Design, Localization, Build, Test, Train, Cutover, and Post Implementation Support) Across the life cycle of the program this individual will be responsible for facilitating a wide range of project activities inclusive of: Capture the business requirements for assigned process/sub-process areas of assignment Ensure the “To-Be” environment best represents current business requirements and future objectives and achieves the objective of standardized and streamlined EY processes where possible (processes, people, organization, data, measures, policies and technology) Develop user scripts, job descriptions, business processes (with associated controls) and assist with system test Manage process & system integration across the scope of the program (e.g., system interfaces, legacy systems, etc.) Identify risks, communicate them to program management, and work to resolve them Develop and execute integration test plans Participate in knowledge transfer to enable sustainment Participate in development of end user training and security Participate in production cutover Execute and validate final data conversion results Execute post-implementation support plan Serve as members of the Program Leadership Team Reports To Program Lead Key Working Relationships Process Integration Lead Global Process Owners Global Process Owner Network Program Leadership Team Business Process Teams and Cross- Functional Teams Time Commitment Full Time

Architecture Office – Business Lead
Role Description Facilitates the optimization of the business unit’s performance by enhancing the alignment between business processes and Information Technology. Plays a key role in structuring, integrating and maintaining the knowledge base of the business in terms of governance / accountability, business functions, business processes and business information. Maintains the supporting documentation comprising the business architecture. Supports the architecture team to facilitate technical solutions for business requirements supporting the organization’s architecture vision. Contributes to end-to-end business process mapping for capabilities supported by the architecture team. Responsibilities Lead and facilitates cross-functional, collaborative teams in transformational initiatives using business architecture principles to ensure target state is achieved Develop and applies expert knowledge of assigned and related business domains and enterprise and business architecture discipline Partner with the Business to understand, and document the business principles, business goals and the strategic business drivers of the organization; Assist in the roadmap communication and education of others (e.g. Training Curriculum), ensuring common understanding of the long-term vision and strategies Capture and understand business objectives, measures and targets to provide traceability Ensure that target state designs align to and enable business and enterprise objectives Perform current state assessments against target state to identify people, process, technology and information gaps Utilize the current state assessments and architectural designs to develop a transformation roadmap Lead the development of an integrated view of the business using a repeatable approach, cohesive framework and defined techniques Consult with appropriate business resources to ensure integration across domains Serve as the primary liaison to the architecture community (i.e., Technology, Information, Organization Design, Process Engineering) and Program Management to ensure alignment Develop and maintain working relationships with business leaders/strategy owners Analyze the current business environment to detect critical deficiencies and identify improvement opportunities Reports To Program Leader Key Working Relationships Process Integration Lead Global Process Owners Time Commitment Full Time

Architecture Office – ITS Lead
Role Description The Enterprise Architect Lead will define and maintain the overall ERP architecture and enterprise architecture. After working with the program manager and ITS lead in finalizing the hardware vendor, this position will wok on designing the ERP landscape, interface architecture and the systems/instances are working appropriately. Responsibilities Lead the hardware sizing exercise for the selected Hardware vendor Design ERP system landscape Design ERP DR system and ensure it aligns with EY BCP and DR plan Design and execute DR testing plan during the program implementation phase upon agreement from the PMO team. Partner with Legacy System & Integration, Data Management, Environment & Release Management team to design the ERP system landscape Partner with Security, Operations and Infrastructure team to design the ERP landscape. Partner with testing team to design testing strategy for infrastructure components and assist in executing the testing. Reports To ITS Lead Program Leader Key Working Relationships Process Integration lead Global Process Owners Time Commitment Full time

Operational Finance Lead
Role Description The Operational Finance Lead, who is a member of the Program Leadership Team, will be responsible for driving day-to-day process design activities in pursuit of common global solutions . They will work closely with the process team leads to define processes and systems that enable the business to achieve the objectives outlined. During localization and roll-out they will work with the Sub Areas to accommodate the legal and statutory needs of each market while enabling implementation of the global processes at a local level. The Operational Finance Lead will work collaboratively across Service Lines, Organizations, and Areas to develop solutions that accommodate the collective needs of all. Responsibilities Provide day to day management of Operational Finance Process team project activities along the project life cycle: This includes phases such as Start up and Prep, Global Design, Localization, Build, Test, Train, Cutover, and Post Implementation Support Across the life cycle of the program this individual will be responsible for facilitating a wide range of project activities inclusive of: Capture the business requirements for assigned process/sub-process areas of assignment Ensure the “To-Be” environment best represents current business requirements and future objectives and achieves the objective of standardized and streamlined EY processes where possible (processes, people, organization, data, measures, policies and technology) Manage process integration across the scope of the program (e.g., system interfaces, legacy systems, etc.) Identify risks, communicate them to program management, and work to resolve them Develop and execute integration test plans Participate in knowledge transfer to enable sustainment Participate in development of end user training and security Participate in production cutover Execute post-implementation support plan Serve as members of the Program Leadership Team Reports To Program Leadership Team Key Working Relationships Process Integration lead Global Process Owners Time Commitment Full Time

Tax / Statutory Lead Role Description The Tax / Statutory Lead, who is a member of the Program Leadership Team, will be responsible for ensuring day to day process design activities properly address in country tax and statutory requirement, in pursuit of common global solution. The lead will work closely with the Global Process Owners, GPO Network, and in country tax/statutory experts to define processes and systems that comply with all rules and regulations. Responsibilities Provide day to day management of Tax & Statutory Team activities along the program life cycle, e.g. Start up and Prep, Global Design, Localization, Build, Test, Train, Cutover, and Post Implementation Support Across the life cycle of the program this individual will be responsible for facilitating a wide range of project activities inclusive of: Review business requirements for adherence to local tax and statutory requirements Ensure the “To-Be” environment best represents current business requirements and future objectives and achieves the objective of standardized and streamlined EY processes where possible (processes, people, organization, data, measures, policies and technology) Identify firm related risks at the local & global levels, communicate them to program management, and work to resolve them Serve as member of the Program Management Team Reports To Program Leadership Team Key Working Relationships Process Integration lead Global Process Owners Program Management Team Time Commitment Full Time

Business Transformation - Change Management Lead
Role Description Change Management Lead, who is a member of the Program Leadership Team, provides the leadership and direction for managing the processes and organizational change associated with the program objectives and implementation. Work streams include business readiness, stakeholder management and communications, organizational alignment, training development and execution and all other activities needed to prepare the EY organization to implement ERP in the defined scope. This individual works closely with the Program Leadership and Management teams and is responsible for working with all impacted business and regional executives to ensure a successful enterprise-wide transformation. Responsibilities Lead all Change Management activities and provides integration with core, regional and country change management teams Work with Program Leadership Team and the Program Management Team to achieve strategic alignment of Program Mercury with key stakeholder groups including: Service Lines, Organizations, Areas and Global Process Owner Network Develop engagement plans to involve key stakeholders throughout the course of the program Develop and implement program communication strategy and plan Develop business readiness approach and plan, and implement in conjunction with rollout teams to prepare EY for changes in organizational structure, job responsibilities and procedures Review Global Template Design, process decompositions and Key Policy Decisions and identify change issues and impacts Work closely with the Benefits Realization Lead collaborating on capturing and understanding the key changes and impacts associated with the program Continuously monitor and manage the needs of the business and program for new challenges. Develop and manage the training strategy, development of materials and training delivery Work with Area country-specific deployment teams and executives to develop viable global and regional change management plans Serve as member of the Program Leadership Team Reports To Program Leader Key Working Relationships Process Integration Lead Global Process Owners Cross functional Teams Key Stakeholder Groups Program Leadership Team Time Commitment Full Time

Business Transformation - Benefits Realization Lead
Role Description The Benefits Realization Lead, who is a member of the Program Leadership Team, is responsible for identifying the benefits associated with the program and developing the analytics and reporting to track these benefits throughout the course of the program. As key metrics and KPI’s are defined for measuring the attainment of the “To Be” processes, this role will be responsible for data gathering and benchmarking current operational performance to ensure that the strategic objectives, goals and financial benefits are met and that Global Process Owners are in concurrence with the “To Be” KPIs and metrics to be used in measuring and reporting on the “To Be” processes. The Benefits Realization Lead works closely with the Change Management Lead collaborating on capturing and understanding the key changes and impacts associated with the program. Responsibilities Revalidate program benefits / costs from the Business Case Define benefit measures for cost, process and other benefit areas Implement enterprise-wide tracking system to periodically measure progress towards meeting targets Define the tasks and resources necessary to execute the Benefits Realization plan for the life of the program Develop the implementation plan for Benefits Realization Partner with the Service Lines, Organizations and Areas to drive change and fulfillment of business transformation objectives Develop target process performance/FTE analysis Develop new job roles to support new process model Design “to-be” organization structure and coordinate people strategies, i.e., severance, retention, recruiting Identify Service Line/Organization/Area impacts and target reductions Implement Service Line/Organization/Area structure Identify, correct, control, and monitor post-implementation issues Leverage cross Service Line/Organization/Area lesson’s learned Serve as member of the Program Leadership Team Reports To Program Leader Key Working Relationships Process Integration Lead Global Process Owners Key executives Program Leadership Team Time Commitment Full Time

Deployment Technology Lead
Role Description The Deployment Technology Lead, who is a member of the Program Leadership Team, is responsible for coordinating all technical aspects of the deployment activities, developing the repeatable deployment approach, and identifying the appropriate technical resources and expertise. This position will work closely with the EY ITS Organization, which is the primary relationship for this role. The Deployment Technology Lead will assist the Program Management Team with the development of the overall deployment strategy, approach and roadmap, and help achieve attainment of the buy-in and sign-off on both. . Responsibilities Assist with development of the overall strategy for the enterprise ERP deployment and rollout including: Conduct an assessment to understanding the global, area and sub area requirements Define the approach, timing and rollout schedule Define deployment rollout groupings and phases Coordinate the development of the deployment team organizational structure and deployment roles and responsibilities (i.e. identifying core team, site team, regional Support Centers and Global Shared Services (GSS)) Establish key milestones Develop a roadmap describing the deployment approach, including the plan, principle, timing and resources Identify roles, responsibilities and resources and skills required to develop and support the technical aspects of deployment Coordinate with Program Leadership team to ensure requirements are met Serve as member of the Program Leadership Team Reports To Program Leader Key Working Relationships Cross Functional Teams ITS Program Leadership Team Time Commitment Full Time

Deployment Business Lead
Role Description The Deployment Business Lead, who is a member of the Program Leadership Team, is responsible for a smooth transition of business support processes from the sub areas to the Global Shared Services (GSS) environment. This role is responsible for deploying the business processes to the business and GSS, while helping to ensure the new processes are understood and implemented. This position’s primary relationship is with the GSS organization, and will work with them to accept any new or revised business processes resulting from Program Mercury. The Deployment Business Lead will assist the Program Management Team and the Deployment Technology Lead with the development of the overall deployment strategy, specifically as it pertains to GSS, and help achieve attainment of the buy-in and sign-off of both. Responsibilities Assist with development of the overall strategy for the enterprise ERP and rollout with specific responsibility of the GSS aspects, including: Conduct an assessment to understanding the global, area and sub area requirements for GSS Define the approach, timing and rollout schedule for the GSS Define deployment rollout groupings and phases for the GSS Work with Deployment Technical Lead to develop the deployment team organizational structure and roles and responsibilities for the regional Centers of Excellence (Support Centers) and GSS Establish key milestones for the GSS Own the GSS aspects of the Global Template Design and responsible for participation in the process design to ensure consistency, standardization and minimum disruption to business Work with GSS organization to develop new GSS business processes to support the new ERP solution Develop an overall approach and plan for identifying, designing and deploying business processes to the GSS Identify roles and responsibilities, resources, and skills required for the new GSS organization with the newly implemented ERP solution Serve as member of the Program Leadership Team Reports To Program Leader Key Working Relationships Global Process Owners Cross Functional Teams GSS Program Leadership Team Time Commitment Full Time

Support Center Lead Role Description The Support Center Lead, who is a member of the Program Leadership Team, is responsible for the development of the company-wide Support Center strategy and the ramp of up the organization to be ready for the post implementation support of Program Mercury. The role of the Support Center will evolve over time to include overall responsibility for support and delivery of ERP applications within EY as Program Mercury reaches various implementation milestones. Responsibilities Establish ERP SME roles within EY, post Program Mercury Provide support for existing installed ERP instances and related processes to meet ongoing business needs Coordinate with ITS to support the EY ERP Enterprise strategy Develop methods, tools and standards for the sustainment of Program Mercury after completion Maintain the change control process after Program Mercury completion (5 years from now) Serve as a member of the Program Leadership Team Reports To Program Leadership Team PMO Key Working Relationships Process Teams Core Solutions Time Commitment Full Time Change Center of Excellence to SUPPORT CENTER Validate with slide 41 – Day 1

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
Core Team Work-stream Work Products Activity EY Business EY ITS EY Advisory IBM SAP PMO Integrated Program Plan Alignment with Enterprise Plan Workshop Schedule Detailed Pilot Realization Plan & Resource Schedule Planning & Tracking C R A/R Deployment Strategy Define deployment approach and plan I Updated resource plan & budget Financial Management Risk Register Issue Log Issue and Risk Management Work Product Acceptance Criteria Program Charter Program Governance model Decision Making Model Mobilization Phase Gate Review Package Global Design Phase Gate Review Package Performance Management Program Testing Strategy Define Program test approach Program Standards Quality plan & standards Quality Assurance Program Tools Strategy Program Reporting

Program Mercury Phase Specific RACI – Change Management
Work-stream Work Products Activity EY Business EY ITS EY Advisory IBM SAP Change Management Program Team Kick-off & On-boarding Events Orientations & Program Global Template Kick- off C A/R Communications strategy and plan Global Design communication event materials Program Communications I Stakeholder engagement strategy Stakeholder Management R Target Operating Model Business Change Impact Assessment Organizational change strategy High-Level Organizational & Job Impact Assessment Detailed Pilot Realization Organizational Change Plan Common role catalogue Benefits Areas & Drivers Value Realization Plan

Program Mercury Phase Specific RACI – Training
Work-stream Work Products Activity EY Business EY ITS EY Advisory IBM SAP Training Program Knowledge Transfer Plan Program Team Training Enterprise Learning Assessment Training Needs Analysis Training & Education Strategy Training Catalogue Training Strategy C A/R R

Program Mercury Phase Specific RACI – Functional/Process
Core Team Work-stream Work Products Activity EY Business EY ITS EY Advisory IBM SAP Functional / Process Inventory of Confirmed Business Requirements SAP Organisational Structure Design / Configuration Rationale SAP General Settings Design / Configuration Rationale Master Data & Coding Structure Design / Configuration Rationale Business Process Hierarchy Process Definition Documents Process Flow Diagrams Key Design Decisions Inventory of High-Level Localisation Requirements Run Global Template workshops C R A/R Functional Gaps List Conduct Fit/Gap Analysis with SAP Requirements Traceability Matrix I Common Gap functional specifications Functional Specifications for Program Mercury Platform Legacy system remediation functional specifications Functional Specifications for Legacy System Re- engineering

Program Mercury Phase Specific RACI – Analytics & Controls
Core Team Work-stream Work Products Activity EY Business EY ITS EY Advisory IBM SAP Analytics & Controls Analytics & Reporting Strategy Confirm Analytics and Reporting Strategy A/R R C Controls Strategy Critical Control Specifications Design Security & Controls for Program Mercury Platform I Critical Operational Reports Specified Inventory of Operational & Statutory Reports Inventory of Additional EDW Reports Design Operational Analytics and Reports development

Program Mercury Phase Specific RACI – Technical
Core Team Work-stream Work Products Activity EY Business EY ITS EY Advisory IBM SAP Technical Non-functional requirements specification C A/R R Landscape Management & Release Strategy E2E Architecture Definition I Program Mercury Integration Strategy Configuration Strategy Development Standards End user audit Hardware Sizing Sandbox & Development Environment Technical Architecture Detailed technical architecture design Physical Architecture for Program Mercury Platform Program Mercury Global Design Phase Security Policy Security strategy SAP Security Authorisation Model Sandbox Environment established Development Environment established Establish Sandpit and Development Environments Inventory of Global & Pilot Interfaces Global Interface Functional Specifications Design integration between SAP and global systems

Program Mercury Phase Specific RACI – Data Migration & COE
Core Team Work-stream Work Products Activity EY Business EY ITS EY Advisory IBM SAP Data Migration Data Migration & Cleansing Strategy Detailed Data Migration Specifications & Cleanse Plans Data Migration Strategy Development R A/R Pilot Site Data Quality Audit C I Support Center Support Center Strategy Support Center Processes & Organisation Design Define Support Center approach

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 Delivery Client/Account Maintenance
Process Area SI Assessed Process Complexity High Med Low Client Service Delivery Client / Account Maintenance Client Maintenance Create prospect ✔ Convert prospect to client Accept Client (change “Pending” to “Active” status) Modify Client Attributes Inactivate Client (change “Active” to “Inactive” status) Merge Clients Account Maintenance Create Account Modify Account Attributes Account Interface and Update Missing / Invalid DUNS number process

SI Assessed Process Complexity
Process Scope – Client Service Delivery Engagement Pricing & Maintenance Process Area SI Assessed Process Complexity High Med Low Engagement Pricing Create new opportunity pricing plan ✔ Modify opportunity pricing plan Create new engagement pricing plan Modify engagement pricing plan Engagement Maintenance Create opportunity Modify opportunity Convert opportunity to chargeable engagement Modify chargeable engagement Close engagement – Manual Close engagement – Automatic Create non-chargeable / authorised engagement Modify non-chargeable / authorised engagement Mass creation of engagements Mass change of engagements

Process Scope – Client Service Delivery Resource Scheduling
Process Area SI Assessed Process Complexity High Med Low Resource Scheduling Automatic resource request from pricing ✔ Manual resource schedule request Modify resource schedule request Schedule resources Confirm schedule Request schedule change

Process Scope – Client Service Delivery: Engagement Economics - Monitor Budget/Estimate to Complete (ETC) Process Area SI Assessed Process Complexity High Med Low Engagement Economics Monitor Budget / Estimate to Complete (ETC) Create initial budget – automatic ✔ Create initial budget – manual Modify budget Manage ETC impacts Manage engagement revenue Create change request

Process Scope – Client Service Delivery: Engagement Economics - Time and Expense & Billing Process Area SI Assessed Process Complexity High Med Low Time and Expense Capture time ✔ Reclassify time (individual) Reclassify time (mass) Expense pre-approval Capture expense Modify expense Expense appraisal Request cash advance Billing Create manual invoice Create automatic invoice Reverse invoices

Process Scope – Finance Program Accounting & Accounts Receivable
Process Area SI Assessed Process Complexity High Med Low Program Accounting Time & expense (T&E) capture ✔ Revenue recognition Cost allocation Inventory / Time / Expense Transfer Resource Related Billing Accounts Receivable Receipt entry Post AR receipt Reverse AR receipt Dunning AR reserve AR write-off

Process Scope – Finance Treasury / Cash Management
Process Area SI Assessed Process Complexity High Med Low Treasury / Cash Management Establish and maintain cash control ✔ Perform bank reconciliations Netting Report and manage cash balances Forecast cash requirements

Process Scope – Finance Accounts Payable
Process Area SI Assessed Process Complexity High Med Low Accounts Payable Accounts Payable (AP) Vendor setup and maintenance ✔ Invoice processing Perform matching process Non-PO invoice approval Matching error resolution Payment processing Cancel payment

Process Scope – Finance Record to Report
Process Area SI Assessed Process Complexity High Med Low Record To Report General Ledger (GL) Adding GL account ✔ Subscribing to GL account Closing GL account Journal entry processing Journal reversals Closing and adjustments Allocations Inter-firm billing Currency revaluation Account consolidation Bank reconciliation Transaction Tax (GST / VAT)

Process Scope – Finance Fixed Assets
Process Area SI Assessed Process Complexity High Med Low Fixed Assets (FA) Planning and budgeting for FA purchases ✔ Asset acquisition Asset management (classification / categorisation) Manage periodic asset depreciation Asset disposal Reporting (PA, BI)

Process Scope – Procurement Item and Supplier Maintenance & Sourcing to Contract Management Process Area SI Assessed Process Complexity High Med Low Item and Supplier Maintenance Item Maintenance ✔ Supplier Maintenance Purchase Information Record Maintenance Sourcing to Contract Management Execute Contracts

Process Scope – Procurement Procure-to-pay, Supplier Management & Spend Performance Management Process Area SI Assessed Process Complexity High Med Low Procure-to-pay Requisition of Goods and Services ✔ Purchase Order Creation and Management Receipt of Goods and Services Invoicing (with finance) Payment Processing (included in Finance) Supplier Management Supplier Integration (Portal and Self Service) Supplier performance monitoring Spend Performance Management Management reporting Spend analysis

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. Application Component Environment Instance Qty SAP ERP Enterprise Core (ECC 6.0 with Enhancement Pack 6) SBX Sandbox DB/CI 1 DEV DV1 N+1 QAS QA1 N+1 PPR PPR App Server Application 2 PRD PRD App Server 4 HA PRD DR PRD DR Application TRN

Application Component Environment Instance Qty SAP Business Intelligence (BI SAP NW 7.3 with Enhancement Pack 1) SBX Sandbox DB/CI 1 DEV DV1 N+1 QAS QA1 N+1 PPR PRD PRD HA PRD DR TRN SAP Supplier Relationship Management (SRM 7.0 with Enhancement Pack 2)

Application Component Environment Instance Qty SAP Process Integration ( PI SAP NW 7.3 with Enhancement Pack 1) SBX Sandbox DB/CI 1 DEV DV1 N+1 QAS QA1 N+1 PPR PRD HA PRD DR Solution Manager (Version 7.1 Support Release 1) PRD SAP Test Data Migration Server (SAP TDMS 4.0) SAP Duet Enterprise (DUET Enterprise 2.0 Ramp-up GAA 11/15/2012) Installed on ECC DEV NA Installed on ECC DV1 Installed on ECC PPR Installed on ECC PPD Installed on ECC HA Installed on ECC DR

Application Component Environment Instance Qty SyBase: SUP Enterprise Developer SAP Mobile Platform Limited Run Time Option SAP Timesheet Mobile Application SAP Travel Receipt Capture Mobile Appl. HR Approval mobile Application Travel Expense Approval Mobile Application DEV DB/CI 1 DV1 N+1 PPR PRD PRD HA PRD DR Sales and Use Tax Vertex (Installed on ECC - SBX, DEV, DV1, QAS, QA1, PPR, PRD, HA, DR and TRN) SAP NetWeaver PI Adaptors (STAR, SWIFT and generic EDI) Installed on PI servers

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
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.

9. Standards and Procedures
Program Mercury Operations Overview – Day 2 Slides 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 Scope Roles Responsibilities
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 Meeting Frequency Purpose Process Lead’s
Status Meeting Weekly Fridays @ 10:30 am Weekly checkpoint with process teams on business design & overall status Cross Functional Lead’s Status Meeting Weekly Mondays @ 2:30 pm Weekly checkpoint on cross-functional integration with the process teams and overall status Program Team Integration Meeting Weekly Tuesdays @ 8 am Weekly integration meeting with the Process & Cross Functional Leads with the Business Process Integration Lead Program Leader & ITS Lead Update @ 9 am Summary of process & cross-functional status meetings in preparation for PMT Meeting PMT Meeting @ 10 am Weekly forward planning meeting providing recommendations & advice on ST and future plans Opportunity for strategic updates from executive and cross-program leadership and focus on any downward communications from leadership Cross PMO Coordination Meeting Weekly Wednesdays Weekly program management coordination between Program Mercury, GFT, and ITS Programs Cross-Program Leadership Meetings Weekly 9 am Monthly CPL strategic coordination with the PMT for decision making on large program issues / economics Prepare for Executive Sponsor meetings Program Operations Update Weekly Thursdays @ 12 pm Weekly coordination with PMO to review the program operations GFT & Program Mercury Coordination Determine & understand program integration points

Integrated Program Master Schedule
Phases Level 1 – Program Phases Phases are the sequential Program building blocks for delivering the transformation 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 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 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
Work Products Exec Summary Activities Risks Issues Resource

Risk Management Why do we need a risk management process?
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 best respond to the impact 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? Risk Response Risk Identification Risk Evaluation Risk Escalation 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 Risk Response Risk Identification Risk Evaluation Risk Escalation 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 the risk for review and decision as per escalation procedure. Monitoring

Risk Management (continued)
How will we manage risks? Risk Response Risk Identification Risk Evaluation Risk Escalation Risk Level Magnitude of Risk Potential Impact Escalation Low Minor or moderate impact on cost, schedule, program outcomes Flows to Team Lead for risk response Medium Significant impact on program outcomes Flows to Integration Lead for risk response High Major impact or very significant impact on cost schedule or other program outcomes Flows to PMT for risk response (ELT as needed) 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 Risk Response Risk Identification Risk Evaluation Risk Escalation As owner of the Risks Log, the BPI will: Review and discuss impact 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 Why do we need an issue management process?
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? Issue Resolution Issue Identification Issue Evaluation Issue Escalation 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: Issue Resolution Issue Identification Issue Evaluation Issue Escalation “Low” severity level: the Team Lead will assign Team Members to the issue resolution activities, “Medium” or “High” severity level: the Team Lead will escalate the issue for review and decision as per escalation procedure. Monitoring

Issue Management (continued)
How will we manage issues? 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. Issue Resolution Issue Identification Issue Evaluation Issue Escalation Issue Severity level Escalation Low Flows to Team Lead for decision Medium Flows to Business Process Integration Lead (BPI) for decision High Flows to PMT for decision. PMT can decide to escalate to ELT level as needed Monitoring As owner of the Issue Log, the BPI will: Review and discuss severity levels set by the Team Leads during the weekly status meetings, and update as needed, Manage Medium level issues and assign Team Leads to coordinate the resolution plan, Escalate High level issues to PMT during Tuesdays’ PMT meeting Issue Resolution Issue Identification Issue Evaluation Issue Escalation 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? Execution Change Identification Change Evaluation Change Decision 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? Change Execution Change Identification Change Evaluation Change Decision 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 Costs assessment 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 Business Process Integration (BPI) for review Monitoring Change Execution Change Identification Change Evaluation Change Decision 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: PMT escalates to the 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 / Expense Charge Code Sub-Code Description
Finance (FY13) Time Configuration Key Design Questions Architecture Data Conversion Development Systems Testing UA Testing Training PMO Deployment Cutover Expense Expenses

Time Reporting - ITS Time / Expense Charge Code Sub-Code Description
ITS (FY13) Time Configuration Key Design Questions Architecture Data Conversion Development Systems Testing UA Testing Training PMO Deployment Cutover Expense Software (Expenses Only) Hardware (Expenses Only) Expenses

Time Reporting – Advisory
Charge Code Sub-Charge Code (for Time only) Sub-Code Description Advisory (FY13) 0100 Benefits PMO 0110 Chg Mgt Key Design 0111 Chg Mgt UA Test 0112 Chg Mgt Training 0113 Chg Mgt Cutover 0120 Controls Key Design 0121 Controls UA Test 0122 Controls Training 0123 Controls Cutover 0130 Deploy Data Con 0131 Deploy UA Test 0132 Deploy Training 0133 Deploy Cutover 0140 Fin Key Design 0141 Fin Data Con 0142 Fin UA Test 0143 Fin Training 0144 Fin Cutover

Time Reporting – Advisory (continued)
Charge Code Sub-Charge Code (for Time only) Sub-Code Description Advisory (FY13) 0150 PMO 0160 Pol Key Design 0161 Pol Training 0162 Pol Cutover 0170 Proc Key Design 0171 Proc Data Con 0172 Proc UA Test 0173 Proc Training 0174 Proc Cutover 0180 Reporting Key Design 0181 Reporting UA Test 0182 Reporting Training 0183 Reporting Cutover 0190 Svr Deliv Key Design 0191 Svr Deliv Data Con 0192 Svr Deliv UA Test 0193 Svr Deliv Training 0194 Svr Deliv Cutover

Time Reporting – Advisory (continued)
Charge Code Sub-Charge Code (for Time only) Sub-Code Description Advisory (FY13) 0200 Tax Key Design 0201 Tax UA Test 0202 Tax Training 0203 Tax Cutover 0210 Tech Arch

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

A central home space for all team members
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
Communication Tool When to Use it Lotus Notes More detailed ( ) messaging between individuals or groups or when a record of an interaction might be required Unlimited number of participants Sametime For brief or instant online one-on-one or group discussion, without the visual capability to see Participation is ideally suited for 2-3 people, for greater numbers it is suggested to use Lotus Notes or Sametime Meeting Sametime Meeting Instant or prearranged discussion including the option to share desktop or document views (can be initiated through Sametime Connect or Participation exceeding 40 individuals might cause performance issues Conference Room Video Conferencing (VC) One-on-one or group discussion originating from a conference room, with visual capability to see others Contact your local VC Coordinator ( for an accurate number of allowable participants Tandberg Online one-on-one or group discussion originating from a user’s computer, with visual capability to see others Participation exceeding eight individuals might cause performance issues Sharepoint / Quickr Online document repository that allows teams to share Program-related documents, in addition the “check out” feature allows for virtual collaboration on documents

Collaboration Reference Materials
Communication Tool Reference Site(s) Lotus Notes Sametime Sametime Meeting Conference Room Video Conferencing (VC) Tandberg Telepresence

Program Document Repositories
SharePoint/Quickr Change Requests (CR) General PMO Documentation Issues Log Program Change Requests (PCR) Program Standards Program Procedures Risk Log Stakeholder Impact Analysis Training Strategy Mobile Strategy Portal Strategy Imagining & Document Management Strategy Integration Strategy Business Benefits SAP Solution Manager Conversion Functional Specifications (CDF) Enhancement Functional Specifications (EDF) Form Functional Specifications (FDF) GAP Analysis Documents (GAP) Interface Functional Specifications (IDF) Key Data Elements (KDE) Key Decision Documents (KDD) Business Process Definition Documents (BPDD) Report Functional Specifications (RDF) Workflow Functional Specifications (WDF) Configuration Document Specifications (CDS)

Collaboration Tool (SharePoint)

Tools Usage by Program Lifecycle Phase
Tool Category MOB GD GB TEST DPLY SUPP Common Tools / Decisions / Actions Req’d Program Planning & Management MS Program, IBM Extensions to SAP Solution Manager (Detail Status Entry, Dashboard) Document Management – Strategic (e.g. Program Procedures, Executive Presentations) MS Sharepoint, Lotus Quickr (interim) Document Management – Tactical (Issues, Risks, Status Reports, Workshop Minutes) Document Management – Solution (Key Decisions, Process & Technical WP) SAP Solution Manager (Program) Scope Management (BPH) Process Modeling Software AG ARIS, MS Visio Visualization iRise Training Development / Content Management Ancile uPerform / ProductivityPak, Transport Management SAP CTS+, SAP Solution Manager (Change Request Management), Revelation Software Concepts Rev-Trac (Selection Required) Test Management HP ALM / Quality Center Test Automation HP QuickTest Professional, SAP TAO, Worksoft Certify (Selection Required) Test Data Management SAP TDMS (Test Data Migration Server) Performance Testing HP Loadrunner Data Migration SAP Data Services, IBM Ready-To-Launch (Dependent on Complexity of Data) 177

Process Level Work Products
(Maintain Engagement) BPD Process Model GAP GAPs KDD Issues Risks Cross Team KDDs KDE KDEs Change Mgmt Business Case Infra- structure CSD CSDs Legacy 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% 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
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% Not Started In Progress Approved Ready for Review Process Lead Approval No Yes Technical Communication 8. Technical Communication Completed * * Locked for editing When to use: To document functional specification for a process Cancelled* Deferred*

Status - GAP Approved 1. Identified – 00% GAP open Identified
2. In Progress – 25% GAP in progress 3. Ready for Review – 75% Ready for review 4. Completed – 100% PMO Accepted 5. Rejected % 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
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 Process Lead Approval No Yes 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
Codes Description Team Team_PRO Team - Procurement Team_SDA Team - Service Delivery Administration Team_FIN Team – Finance Complexity Complex1_H Complexity High Complex2_M Complexity Medium Complex3_L Complexity Low

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

Function/Work Product
Work Product Roles Function/Work Product Read Maintain Delete Create Business Process Definition Document Anyone Scenario Team Member Process Team Lead GAP Analysis Document Key Decision Document Key Data Elements Configuration Elements Workflow Functional Specifications Report Functional Specifications Interface Functional Specifications Conversion Functional Specifications Enhancement Functional Specifications Form Functional Specifications Change BPH Design Control Board Standard Reports N/A Update Status Run DSE Run Dashboard PMO

Reporting Capabilities
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

10. Quality Plans and Standards
Program Mercury 10. Quality Plans and Standards

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

Program Mercury Program Charter.

Similar presentations

Presentation on theme: "Program Mercury Program Charter."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Program Mercury Program Charter.

Similar presentations

Presentation on theme: "Program Mercury Program Charter."— Presentation transcript:

Similar presentations

About project

Feedback