1. Copyright © 2003 Americas’ SAP Users’ Group Microsoft’s SAP Upgrade based on the Quarterly Release Strategy Scott Baxter Lead Program Manager, EAS Becky Moe Senior Program Manager, CAIT Tim Gale Product Manager, Corporate Accounting May 19 th, 2003

2. Key Learning Points  Leveraging Microsoft's Quarterly Release framework to minimize impact of SAP Upgrade on organizations  Importance of strong communication and resource planning  No “One Size Fits All” approach to training and documentation

3. Company Profile Employees: US39,640 International14,726 Total54,366 Vendors WW19,757 Agency Temps WW4,500 Total24,257 Contingent Staff:

4. SAP at Microsoft  General Facts  400 company codes (180 with headcount)  15,000 active cost centers (5,500 with headcount)  140,000 active internal orders  User Numbers  2,000 named; 50,000+ total users  600+ concurrent users  Modules Implemented  SD, MM, FI, CO, AM, HR, BW, APO, RE, PS  System Information  950+ GB in single, central database  6.25 GB growth per week  99.9+% availability (excluding quarterly releases)  Microsoft’s First and Best Customer

5. Upgrade – Objectives  “Just Another Quarterly Release”  Upgrade SAP to Enterprise by August 2003  Minimize production downtime  Keep performance similar or better  Reduce number of repairs  Identify and retire obsolete custom objects

6. Quarterly Release/Upgrade Resources  Continuity maintained from release to release  Quarterly release resources utilized for Upgrade  Enterprise Application Services (EAS)  SAP Program Management  SAP Product Management  Business Unit IT Partners

7. Quarterly Release/Upgrade Resources Enterprise Application Services (EAS)  Perform all custom SAP programming (ABAP) and related unit testing  Support conceptual stage of design phase  Perform functional and performance testing  Maintain stable and cost-effective SAP environment  Manage production issue resolution  Review and analyze Hotpacks

8. Quarterly Release/Upgrade Resources SAP Program Management  Manage SAP change request process  Support envisioning process from an IT and SAP perspective  Drive design process for SAP changes  Complete SAP configuration activities  Support functional and regression testing processes  Serve in a consulting role for escalated production issues  Review and analyze Hotpacks

9. Quarterly Release/Upgrade Resources SAP Product Management  Manage SAP change request process  Manage CR prioritization for each Release  Liaison to Business Representatives  Assist business in development of requirements  Manage User Acceptance Testing (UAT) and Business Process Regression Testing (BPRT)  Training and rollout  Communication

10. Quarterly Release/Upgrade Resources Business Unit IT Partners  Responsible for integrated tools and applications  Examples:  Web Extensions  Data Warehouses  Partner with SAP teams on envisioning process from an IT perspective  Support Upstream/Downstream Testing Activities

11. Preliminary Analysis Business Analysis IT Costing & Prioritization Development Test Preliminary candidate cutoff Code complete UATBPRT Candidate cutoff Requirements deadline Quarterly Release Phases/Milestones Business Need Identified & Business Case Developed  Stakeholder Requirements Documentation  Stakeholder  Product Mgmt IT Work Effort Estimated  Program Mgmt Technical Spec Complete  Program Mgmt User Acceptance Testing  Product Mgmt  Stakeholder Product Studio Item (for tracking) & Candidate List Created  Product Mgmt Candidate Prioritization  All Stakeholders  Product Mgmt Effort Adjusted Final Candidate List  All Configuration & Development  Program Mgmt  IT Development Business Process Testing  Product Mgmt  Stakeholder Preliminary Work Effort Estimated  Product Mgmt  Program Mgmt Quarterly Business Review “Draw the Line”  Executive Sponsors IT Resources Assigned IT Unit Testing  Program Mgmt  IT Development GoLive

12. Quarterly Release Schedule FY2003 Milestone Q1Q2Q3Q4 Preliminary Candidate Cutoff BizCase Due BizCase Due 5/03/02 Fri 8/02/02 Fri 11/01/02* Fri N/A* Requirements Deadline Detail requirements due Detail requirements due 5/24/02 Fri 8/30/02 Fri 11/29/02 Fri N/A Candidate cutoff Effort adjusted request listing Effort adjusted request listing 6/07/02 Fri 9/06/02 Fri 12/06/02 Fri N/A Specification Cutoff Spec reviews complete Spec reviews complete 6/21/02 Fri 9/20/02 Fri 12/20/02 Fri N/A Code Complete Development and Unit test Development and Unit test 7/05/02 Fri 10/04/02 Fri 01/03/03 Fri N/A UAT Complete Stakeholder buyoff Stakeholder buyoff 7/19/02 Fri 10/18/02 Fri 01/17/03 Fri N/A BPRT Complete Business Process Test Business Process Test 8/02/02 Fri 11/01/02 Fri 01/31/03 Fri N/A Release to Production Production handoff 8/09/02 Fri 11/08/02 Fri 02/07/03 Fri N/A *=Q3-Contingent on complexity of the SAP upgrade: Pre approved items only; Q4-Closed-SAP upgrade

13. Upgrade Timeline

14. Scoping & Planning  Roles & Responsibilities replicated from Quarterly Release process, simplifies process of organizing upgrade project team  Plan for 6 month black-out for change requests  Give sufficient lead time to allow critical business and IT changes to occur before the blackout  Executive sponsorship for project plan and resource requirements  SAP technical enhancements considered where processes and support can be simplified

15. Scoping & Planning System Landscape designed to minimize need for dual maintenance DEVMS2PRODMSS 4.5 4.7 ADJMSV TEST MSU TEST T02 TEST MST DEVMS1TESTMSTPRODMSS ADJMSY TESTMSX

16. Analysis and Design  Necessary configuration and programming changes identified  SAP RBE tool used to build inventory SAP transactions & programs being used  Inventoried items reviewed and tested by Program Management  “Broken” items categorized in Timeboxes  Obsolete programs eliminated  Significant changes between SAP releases identified and communicated  Delta documentation  Navigational instructions

17. Development and Test Timeboxes  Four Timeboxes to organize effort and impact  Core Transactions, Repairs & User Exits  Inbound and Outbound Interfaces  Reports/Security  Contingency  Clearly Defined Deadlines  Program Specifications  Configuration  Testing

18. Testing: UAT & BPRT  User Acceptance Testing:  ALL SAP transactions, reports and programs used  All bugs should be identified and fixed prior to BPRT  Broad security access assigned to prevent impact on user acceptance testing  Security Roles tested centrally by small teams  Business Process Regression Testing:  Occurs over 10 weeks beginning 5/19  Follows guidelines used for normal quarterly release process  Comprehensive End to End testing including tools and upstream/downstream systems  Broad Security Role testing

19. Testing: Inventories & Scripts  Existing Quarterly Release test inventories leveraged for Upgrade Project  Updated to reflect new and retired transactions  Opportunity to enhance for existing transactions  Business Units own and maintain independent repositories of test cases and scenarios  Various tools used (Access DB, Excel, SharePoint)  Users are critical in defining scope and documenting test cases  Global Testing Networks developed to support ongoing regression testing  Detailed test scripts required and used in many operational groups  Other groups identify test cases only and rely on subject matter expertise for testing

20. Testing: International Scope  Regional Product Managers/Coordinators - Critical  Manage International testing effort  Regular meetings with Corporate team  Evangelists and communication liaisons for their regions  International Finance/Procurement resource constraints required focus on “Unique” requirements  Examples:  Country specific Statutory Reports  Country specific tax calculations (e.g. VAT)  Accounts Payable processing in each subsidiary  SAP allocations executed by subsidiaries  Subsidiary specific output requirements such as Dunning or Purchase orders  International Fixed Asset Depreciation

21. Testing: Issue Management  Effective Issue/Bug Management Tools are Essential  IT Teams Share Bug Tracking Tool (Product Studio)  Enhanced visibility and reporting  Efficient status tracking  Maintain IT & Biz Contacts, Steps to Reproduce, Dev Status, Testing Status…  Relevant documents such as specifications are attached or linked  Business groups maintain independent issue tracking tools  Examples:  Excel  SharePoint  Product Studio

22. Product Studio for Bug Tracking

23. Communication and Coordination  Establish communication framework early  Evangelize SAP Upgrade Benefits regularly  Schedule project kick-off meetings  Set expectations  Confirm support  Maintain Team Web Sites (SharePoint)  Communication  Store Project documentation  Contact information  Issue and Risk Management  Links to other sites and information  Hold Frequent Status Meetings  Team specific and cross organizational  Schedule Brown Bag Sessions  Send Weekly Status Reports and Meeting Summaries

24. Documentation & Training  Business Units determine own documentation and training strategy  Common themes across organizations  Web Based Self-Help Training & Documentation  Delta documentation & training to support testing  Train the trainer approach widely used  Workshops  Limited End User Live Training  Factors resulting in different strategies  Centralized versus decentralized users  Size of user groups  Cross organizational considerations  Extent that Web Tools are used  Resources  Distributed Project Management  Turnover considerations  Use of Vendors to initiate transactions

25. Documentation & Training  World Wide Operations  Widely distributed user community  Domestic and International  Cross Organizational  International scope requires Regional Coordinators  Broad Range of Training & Documentation Products  Step by Step Procedures  Quick Reference Cards  Mandatory workshops with workbooks  Online quizzes testing proficiency  Web Based Training and Documentation  Live Training Two Weeks prior to Go-Live  Train the Trainer approach

26. Documentation & Training  Finance  Widely distributed user community  Domestic and International  Cross Organizational  International Scope Requires Regional Product Managers  Communication, coordination, education  High use of Web Tools minimize training requirements  Reporting  Posting Journal Entries  Master Data Maintenance  Web Based Training and Documentation  Live Workshops  Formal Training Focus Several Weeks Prior to Go-Live

27. Documentation & Training  HR/Payroll  Small, centralized user group  Limited training required  Preliminary delta training provided to support testing  Existing Online Documentation Manual Updated  Procurement  Centralized domestic Accounts Payable  Limited training needed for domestic team  High use of Web Tools minimize training requirements  International and Domestic  Some international subsidiaries require training and documentation  Where web tools not implemented  Regional Product Managers key to success

28. Lessons Learned  “Technical” does not necessarily = “Simple”  EARLY analysis of Security  Impact from new and retired transactions  EARLY analysis of new, changed and retired transactions  User education and documentation requirements  Impact on security profiles  Old versus New decisions for similar transactions  Impact on RFCs  Plan for EARLY development  RFC impacts  Internally released function modules  Unicode enabled programs  Good documentation for custom programs is important  Provide sufficient user education early to support testing  Make sure ALL groups budget project support capacity

29. Wrap up Project Status:  All analysis, development and unit testing complete in test environment 5/19  Business Process Regression Testing beginning 5/19  Formalized training for most groups starting in July  On schedule for release to production 8/8 Summary:  Upgrades are unique so start assessment early  Cannot over communicate  Get Executive Sponsorship from all teams participating  Effective Cross Organizational Partnering is Critical  Limit scope if possible  Flexibility is a must!

30. Copyright © 2003 Americas’ SAP Users’ Group Thank you for attending! Please remember to complete and return your evaluation form following this session. Session Code: [2305]