ERP Case Studies Top 10 c orporate IT f ailures Seven keys to successful projects

1. ERP Case StudiesTop 10 corporate IT failures Seven keys to successful projects

2. ERP Case Studies • 38% of ERP systems are never implemented ...and of those that are • 50% exceed the original budget by a factor of three

3. ERP Case Studies

4. ERP Case Studies

5. ERP Case Studies

6. ERP Case Studies

7. Seven Keys to Successful Projects Seven essential ingredients of successful ERP projects 1. Real EXECUTIVE SPONSORSHIP • visible, vocal, continuous • not figureheads • not just the CIO 2. A convincing BUSINESS CASE • not just IT benefits • based on a transformed business model--integration and commonality of processes • clearly defined, understood and accepted

8. Seven Keys to Successful Projects Seven essential ingredients of successful ERP projects 3. REALISTIC EXPECTATIONS • resistance to change • “we can do it faster and cheaper” • optimistic projections on technology • “best is the enemy of the good” • “flawless start-up” • clearly understood and accepted risks

9. Seven Keys to Successful Projects Seven essential ingredients of successful ERP projects 4. Ruthless SCOPE CONTROL • avoid modifications and bolt-ons • “kill-off” legacy systems • users get what management believes they need and only what they are willing to pay for • only changes accepted are those that “keep the CEO out of jail or cost us a major customer”

10. Seven Keys to Successful Projects Seven essential ingredients of successful ERP projects 5. Execution based on SPEED and FOCUS • get something “live” quickly--within the 1st year • frequent implementations--every 6 to 9 months • implement company company-wide within 3.5 to 5 years • “speed not haste” 6. A formal PLANNING and EXECUTION METHODOLOGY • driven by schedule and intermediate milestones--not strictly by deliverables • invest in tools upfront • learn from and APPLY lessons learned • NEVER, NEVER skimp on training or testing • recognize the methodology will evolve as the project does

11. Seven Keys to Successful Projects Seven essential ingredients to successful ERP projects 7. An effective PROJECT ORGANIZATION • experts from the business • experienced technical staff who know the software and how it should be used • build team skills for the long haul • clear roles and responsibilities • encourage ingenuity, but not mavericks • no confusion between consensus and decision making • continuity of people during the project and after start-up • regular cross-project communications • open and honest status reporting • “bigger is not necessarily better” • recognize the project organization will evolve with the project

12. ERP case studiesTop 10 corporate IT failures

13. ERP Case Studies Computerworld’s Top 10 Corporate IT Failures • AMR Reservation system for hotel and car rentalbookings • Snap-On Conversion to a new Baan-based order entrysystem • FoxMeyer SAP ERP system • Greyhound Reservation and bus-dispatch system • Hershey Foods IBM-led installation and integration of SAP,Manugistics and Seibel software

14. ERP Case Studies Computerworld’s Top 10 Corporate IT Failures • Norfolk Southern Systems integration resulting from merger with Consolidated Rail • Oxford Health Plans New billing and claims-processing system based on Unix and Oracle databases/tools • Tri-Valley Growers Oracle ERP and application integration • Universal Oil Products Project cost and engineering specification system • W. W. Grainger SAP ERP system • Fidelity Brokerage Internet trading system

15. ExxonMobil STRIPES

16. ExxonMobil STRIPES—Speed not haste During 2001 the project went Live with 8 Affiliates in 17 Countries with 5000 users on a full scale SAP IS-OIL implementation replacing on average 100 major applications per Affiliate. ExxonMobil’s business is highly automated running 100’s of daily interfaces and a batch schedule of 10,000 Jobs. The implementation included establishing common processes, necessary infrastructure, change management, organisational design and training. And included all European process and system changes needed to complete the merger between two oil giants, realignment to a global functional organization and the introduction of the EUR currency.

17. ExxonMobil STRIPES ExxonMobil STRIPES program background • A five year program to replace legacy systems throughout the companies downstream operations outside of North America. • Project activities included establishing common processes, system configuration and report development, data conversion, interface development, technical infrastructure, organization design, testing, training, and start-up support. • Process scope included order-to-cash, purchase-to-pay, supply, financial/tax/treasury, volume and profitability reporting, and plant maintenance. • A common SAP system, centrally developed by a team of 150 ExxonMobil and 150 Consultants/contractors (from 26 nationalities) supported by local implementation teams peaking at 300 people.

18. ExxonMobil STRIPES ExxonMobil STRIPES program background (con’t) • By end of 2001 all major European countries(18) and users(10,000) have been converted to STRIPES---195 company codes/legal entities, 2900 plant and 13,000 storage locations • Other implementations are currently underway in AsiaPacific, Japan and Latin America • System will ultimately support over 20,000 users in 80 countries on four production instances. • Functionality covered IS-Oil, FI, CO,AM, MM, SD, PP/PI, PM, PS Workflow, ALE

19. ExxonMobil STRIPES STRIPES Project Issues and Challenges • Multiple languages, currencies and legal requirements • Defining what is common • New technologies • An huge spaghetti bowl (1000s) of aging legacy systems • Change management • Enforcing a common design world-wide • Managing project costs • Dealing with multiple, concurrent roll-outs • Maintaining continuity of PwC consultants and Client team members

20. STRIPES Process Scope Refining Terminals MaintenancePM / PS / MM Management ReportingCO/PA SIS Procure to PayMM SupplyMM / PP/PI / IS-OIL Order Fulfilment SD / IS-OIL Financials/TreasuryFI / CO Integration Retail Industrial &Wholesale Marine Asphalt, Wax,LPG

21. Project organization evolved from a process oriented development team to track-based roll-out structure Development through Pilot (process oriented) Roll-out (track approach) Infrastructure Order To Cash Design and Construction(Process oriented) Supply Procure To Pay Data Conversion Interfaces / Enhancements / Batch Infrastructure Data Conversion Development Management Reporting Organization design (Training / Controls / Authorizations) Finance / Tax Plant Maintenance/Projects Testing Start-Up

22. Team Responsibilities Central and Local Local Team dominates Change Management Training / Controls / Authorizations Testing Common Design - One Team Start-Up Central Team dominates Central Team composedof Client Corporate andFuture Local implementation team members Infrastructure Design and Construction(Process Oriented) Interfaces/ Batch Data Conversion

23. Project priorities and team organization changes from Pilot to Common Design to Roll-out Pilot • Meet the schedule with no significant business interuptions • Demonstrate SAP functionality and reengineered processes • Develop team’s capability and knowledge • Project organization is process team driven Common design • Meet the schedule within budget • Focus on development of common, integratedbusiness processes • Develop repeatable implementation approaches forSAP configuration, interfaces, data conversion, organizational design, training development and delivery and start-up • Project organization is process team driven

24. Project priorities and team organization changes from Pilot to Common Design to Roll-out Rollout • Focus is on speed and cost • Track based project organization and methodology--Analysis, Design and Configuration, Interfaces, Data Conversion, Organization Design and Start-Up • Integration team focuses on live operations and roll-out • Live operations support and change control increase in importance

25. STRIPES Roll Out Methodology

26. Case Study: Interface StrategyCommon Requirements across business units... Interface Strategy--common requirements across business units... • Financial Postings • Credit / Debit Memos • Material Movements • Sales History Common design as basis for rapid roll-out ...So Why Reinvent the Wheel?

27. LS1 SAP Database LS 2 LS3 Mapping Program Legacy System Specific File Format Traditional Interface Architecture

28. STRIPES Interface Architecture LS1 LS2 LS2 LS3 Error Handling / Reporting Standard Interface Formats Standard Interface Groups Legacy System Mapping File Transfer Application Link Enabling Batch Scheduler SAP Database Reusability / CommonalitySAP standard interfaces when provided IDocs wherever possibleLocal team systems map to SIF

29. STRIPES Project Tools • Design and construction – PwC Ascendant Toolset • Testing – Mercury test management and regression testing tool • Batch management database - SOM • Data conversion loading - SAP’s LSMW • Problem management tool • Change management tool • Project communication - Intranet site • Training - PwC EPSS • Training – PwC developed CBTs • Time Recording/Project Stewardship – Webster/Powerpoint/Excel • Metrics - Cockpit • Work request database

30. Global Roll Out Best Practices Study • Background - Purpose of Study • Two of the most significant costs in rolling out SAP to a new country or business unit are: • Recurring Configuration--effort required to configure the SAP system for a new Company/ Geography/Language /Plant within the parameters of the common design. • Data Conversion--each new business unit requires converted data to establish the SAP system, with potentially separate unique source systems for this data • Additional challenges on a roll-out are presented by: • need to preserve the common design • logistics presented by multiple geographically dispersed countries • local legal & statutory requirements • local language issues • support of live operations • staff continuity on a long project

31. Summary Recommendations Recurring Configuration • Have most experienced business process team members to communicate requirements for recurring configuration • Depending on available skills, process team members or SAP technical team member can complete recurring configuration • Consider using recurring configuration as a means for training new process team members in design • Use existing project material (templates, presentations) for recurring configuration • Team owning design should own configuration Data Conversion • Leverage existing design work: LSMW common design, controls catalogues, loading plans, QA processes, regression test • Co-locate data conversion loading team. Consider including data conversion in process teams - especially for early phases. If not, then organize team by process module with clear link to process teams • Use project knowledgeable business analysts to work with local team on data preparation

32. Summary Recommendations Strong Business Support • Communicate project goals • Ensure local management buy-in and commitment of resources from analysis through implementation Maintain project Best practices • Continue enforcement of commonality/common design • Strong central team with high degree of communication between process teams and technical staff (interfaces and reports analysts) Scope & Change Control • Define framework and apply process for receiving upgrades to common design; for making local changes • Define appropriate controls for disparate team Other • Leverage experienced staff - re-locate, fly-ins • Staff initial phases with roll-out country staff. Consider how to staff roll-out e.g. overstaff in first phase • Staff project with executives known and respected by local business community