Transcription
Martin RiedelManaging SAP ERP 6.0 Upgrade Projectswww.sap-press.comBonn Boston
Contents at a Glance1Introduction .132Getting Started .173Planning an Upgrade Project .574Managing an Upgrade Project . 1175Executing an Upgrade Project . 1596Upgrade Tools and Services . 1997Customer Cases and Upgrade Communities . 253AppendixASAP ERP Upgrade Checklist – Project Preparation . 323BSAP ERP Upgrade Checklist – Blueprint . 327CSAP ERP Upgrade Checklist – Realization . 333DSAP ERP Upgrade Checklist – Final Preparation forCutover . 341ESAP ERP Upgrade Checklist – Production Cutover &Support . 343FReferences . 345GAuthors and Contributors . 351www.sap-press.com
Contents1Introduction .132Getting Started .172.1171820222.22.32.42.5Introduction to SAP ERP 6.0 .2.1.1 Evolution of SAP ERP 6.0 .2.1.2 Functional Overview of SAP ERP 6.0 .2.1.3 What Runs Best on SAP ERP 6.0? .2.1.4 Integrated and Switchable IndustryFunctionality .2.1.5 Solution Browser Tool for SAP ERP .SAP Enhancement Packages—Concept and Overview .Discovery Process .2.3.1 Collecting Preliminary Information .2.3.2 Stakeholder Analysis and Involvement .2.3.3 Determining the Business Value of newFunctions .2.3.4 Organizing Delta Training and Workshops .2.3.5 Trying out new Functions .2.3.6 Finalizing the Business Case and Justifyingthe Upgrade .Why Upgrade Your ERP Software? .2.4.1 Upgrade Approaches .2.4.2 Essentials of an Upgrade Justification .2.4.3 Operational Excellence .2.4.4 Business Strategy .2.4.5 Sustainability .2.4.6 TCO .2.4.7 Cost Reduction Opportunities for aTechnical Upgrade .2.4.8 The Downside of not Upgrading .Determining the Value of an Upgrade 434648487
Contents3Planning an Upgrade Project 01108110110112113114115116Managing an Upgrade Project . 1174.14.28Determining the Upgrade Strategy and Scope .3.1.1 Factors Influencing the Complexity of anUpgrade .3.1.2 Technical Considerations .3.1.3 Enhancement Packages Installation Scope .3.1.4 Unicode Conversion Options .3.1.5 Other Factors Influencing the Upgrade .Resourcing Models and Approaches .3.2.1 Internally Managed .3.2.2 Externally Managed .3.2.3 Summary .Scheduling an Upgrade .Estimating Cost and Effort .3.4.1 Trial Upgrade .3.4.2 Preliminary Upgrade Assessment .Project Standards and Procedures .Risk Management .3.6.1 Identifying Risks .3.6.2 Risk Management During the Project .3.6.3 Risk Classification .3.6.4 Identifying Potential Upgrade Project Risks .3.6.5 Risk Identification Checklist .3.6.6 SAP Safeguarding for Upgrade .Building a Project Team .4.1.1 Project Team Scope .4.1.2 Project Team Roles .4.1.3 Project Team Training .4.1.4 Project Team Availability .Quality Assurance and Testing .4.2.1 Testing Focus .4.2.2 Test Stages and Test Progression .4.2.3 Testing Resources .4.2.4 Test Systems .4.2.5 Test Data Management 8
Contents4.2.64.34.45Choosing Between Manual or AutomatedTesting .4.2.7 Benefits of Automated Testing .4.2.8 Benefits of Manual Testing .4.2.9 SAP Solution Manager .4.2.10 Test Activities in the SAP Upgrade Road Map .4.2.11 Test Case Templates for EnhancementPackages for SAP ERP .4.2.12 Successful Testing .4.2.13 Quality Management and Quality Gates .Cutover Planning .4.3.1 Input from Previous Project Phases .4.3.2 Cutover Plan Contents .4.3.3 Cutover Prerequisites .4.3.4 Sample Cutover Plan for a Weekend Upgrade .4.3.5 Unicode Conversion Phase .4.3.6 Post Cutover Activities .Best Practices .4.4.1 Project Management .4.4.2 Technical Best Practices .4.4.3 Upgrade Project Errors 49153157Executing an Upgrade Project . 1595.15.2Managing the System Landscape During anUpgrade Project .5.1.1 Recommended System Landscape .5.1.2 Project Preparation .5.1.3 Upgrade Blueprint .5.1.4 Upgrade Realization .5.1.5 Final Preparation for Cutover .5.1.6 Production Cutover and Support .Downtime Minimization .5.2.1 Definitions: Downtime, Uptime, Runtime .5.2.2 Why is Downtime Necessary? .5.2.3 Downtime Facts and Figures .5.2.4 Choosing an Upgrade Strategy .5.2.5 Elements of Business Downtime During anUpgrade 21721759
188189191193194194196197Upgrade Tools and Services . 1996.16.26.310Factors that Influence Upgrade Runtime andDowntime Duration .5.2.7 Incremental Conversion (ICNV) .5.2.8 Customer-Based Upgrade (CBU) .5.2.9 Unicode Conversion .5.2.10 Near Zero Downtime .5.2.11 Unicode Conversion Downtime .5.2.12 Best Practices – Upgrade Tuning .5.2.13 Testing .5.2.14 Splitting Downtime .Training .5.3.1 Consider the Training Focus .5.3.2 Create a Training Plan .5.3.3 SAP Education .5.3.4 E-Learning .Lessons Learned .5.4.1 Project Management Aspects .5.4.2 Functional Aspects .5.4.3 Technical Aspects .SAP Solution Manager in Upgrade Projects .6.1.1 Two Scenarios .6.1.2 SAP Upgrade Road Map – Overview .6.1.3 SAP Upgrade Road Map – Details .Technical Upgrade Tools .6.2.1 SAPup and Upgrade GUI for ABAP .6.2.2 SAPjup and SDTGUI for Java .6.2.3 Synchronization of ABAP and Java Upgrades .6.2.4 Upgrade Preparation .6.2.5 Application-Specific Upgrade (ASU) Toolbox .Supporting Upgrade Tools .6.3.1 Solution Browser Tool for SAP ERP .6.3.2 Quick Sizer .6.3.3 Upgrade Dependency Analyzer .6.3.4 Scenario and Process Component List .6.3.5 Business Process Change Analyzer 9219220221223223
Contents6.3.66.3.76.46.56.66.77Solution Documentation Assistant .SAP Custom Development ManagementCockpit .Testing Tools .6.4.1 SAP Solution Manager for Testing .6.4.2 SAP Test Data Migration Server (SAP TDMS) .6.4.3 Business Process Change Analyzer (BPCA) .6.4.4 Solution Documentation Assistant .6.4.5 Upgrade Project Testing withSAP Test Workbench .6.4.6 SAP Quality Center by HP .6.4.7 SAP LoadRunner by HP .6.4.8 SAP Test Acceleration and Optimization .Tools for Downloading and Installing SAPEnhancement Packages .6.5.1 Maintenance Optimizer .6.5.2 Enhancement Package Installation Toolsand Process .Upgrade Services .6.6.1 SAP Upgrade Value Assessment .6.6.2 Quick Upgrade Analysis for SAP ERP .6.6.3 Technical Upgrade Planning for SAP ERP .6.6.4 Upgrade Coaching for SAP ERP 6.0 .6.6.5 Technical Upgrade Service for SAP ERP .6.6.6 SAP Enterprise Support Services .6.6.7 SAP Safeguarding for Upgrades .SAP Testing Services 43245246248248250250Customer Cases and Upgrade Communities . 2537.1Customer Cases .7.1.1 Cincinnati Insurance Company .7.1.2 Indesit Company SpA, Italy .7.1.3 Nebraska Public Power District (NPPD) .7.1.4 Pacific Coast Companies, Inc. .7.1.5 SAP AG, Walldorf, Germany .7.1.6 Scientific Atlanta .7.1.7 SEWAG, Germany .7.1.8 TransAlta .www.sap-press.com25325425826626827327828229311
Contents7.2Upgrade Community .7.2.1 Deutschsprachige SAP-Anwendergruppe e. V.(DSAG) – Cooperation at all Levels .7.2.2 SAP ERP Upgrades, ASUG and YOU .7.2.3 Club des Utilisateurs SAP Francophone (USF) .297298302306Appendix . 321ABCDEFGSAP ERP Upgrade Checklist – Project Preparation .SAP ERP Upgrade Checklist – Blueprint .SAP ERP Upgrade Checklist – Realization .SAP ERP Upgrade Checklist – Final Preparation for Cutover .SAP ERP Upgrade Checklist – Production Cutover & Support .References .Authors and Contributors .323327333341343345351Index . 35912www.sap-press.com
How should the system landscape be set up during an upgradeproject? How can downtime be minimized, and what supporttools and methods exist? What about training the project teamand end users? Chapter 5 answers these questions and providesrecommendations based on lessons learned from numerousupgrade projects.5Executing an Upgrade ProjectThis chapter looks at the execution phase of an upgrade. Based on twomain upgrade challenges perceived by customers, its focus is on downtime minimization and training. In addition, we will look at systemlandscape strategies that can help you successfully complete yourupgrade project.You can follow several different paths to tackle downtime. We will showyou how careful analysis of your situation can help you manage thisissue successfully. We will also describe the options offered by SAP tokeep downtime to a minimum.DowntimeminimizationThe section on a recommended system landscape outlines a recommendation for how to set up and manage your system landscape in anupgrade project. It is not feasible within the scope of this book to showall possible system landscapes, as each is customer-specific. However, itis instructive to examine and understand a basic setup that shows howthe system landscape evolves throughout the project. From this, you canbegin to analyze your own system landscape and take the necessarymeasures to build the appropriate environment specific to your requirements.Recommendedsystem landscapeWhen planning to tackle an upgrade, it will most likely become apparent a knowledge gap exists for many of your staff, either on the technicalside or in terms of the functionality that will be implemented. In the section on training, you will find numerous recommendations for deter-Trainingwww.sap-press.com159
5Executing an Upgrade Projectmining the training your organization will need as well as suggestionsfor relevant SAP courses.Lessons learnedFinally, we will look at some of the lessons learned from upgradeprojects. These will give you insight into what makes a successfulproject, based on real experience from SAP's involvement in numerousupgrade projects.5.1Managing the System Landscape During anUpgrade ProjectThe goal of this section is to provide guidance and recommendations fora standard three-system SAP customer landscape; however, it cannotfully explore all of the potential additional systems and interdependencies you might have in your specific landscape.A number of factors have a direct influence on the specific system landscape you choose for the upgrade project, most notably the following:왘The code freeze strategy.왘The technical availability of hardware for setting up temporary systems during the project (sandbox and training systems).왘The operational ease of setting up sandbox systems, shadow systems,and so on in your IT environment or with your hosting service provider.Depending on the scope of the upgrade, your upgrade project can lastseveral months. During this time, it is often inevitable that you will needto make at least some changes to the production system. For many customers, it is not possible to expect the business to suspend all changes tothe system during that time. Therefore, you must define an appropriatechange management strategy that will restrict and regulate changes tothe production system within the context of the system landscape youare using for upgrade testing and project refinement.Code freezeThe code freeze period will usually start after the development systemhas been established. From that point in time, double maintenance ofcoding and other system configuration changes is necessary. At a point160www.sap-press.com
Managing the System Landscape During an Upgrade Project5.1close to the cutover weekend (usually after the final integration testingat the latest), you will also have to define a “hard” code freeze strategywhich restricts transports even more and allows only the most urgent ofchanges to be implemented. Section 4.4, “Best Practices,” in Chapter 4,provides a recommendation for a code freeze strategy.You should also consider the need to set up separate systems for trainingpurposes, interface testing, modification adjustments, and customdevelopments. Most customers, however, will use a three-tier systemlandscape with an additional sandbox as the "playground" for theupgrade project.5.1.1Recommended System LandscapeThis section provides you with recommendations on how to set up yoursystem to minimize upgrade risks and minimize the duration of thecode-freeze period. The examples show a typical three system landscape, consisting of a development system, a quality assurance/consolidation system, and a production system. The recommendations showhow additional copies of these systems are used to perform requiredactivities during the upgrade project such as adjusting custom developments and testing. We will look at how the systems evolve during thedifferent phases of the upgrade project:왘Project preparation왘Upgrade blueprint왘Upgrade realization왘Final preparation for cutover왘Production cutover (go-live) and supportThe scenarios are based on a suggested timeline, which runs over fourmonths. For each phase, each scenario gives a suggested duration, inweeks. The recommendations assume that you have the appropriatehardware available for creating additional systems. We describe actualproject work, how each system is upgraded to the new release from theold release, and the transport routes required.www.sap-press.com161Multiple systems
5Executing an Upgrade ProjectRecommendedproject activitiesRecommended project activities are suggested for each team involved ateach phase, as follows:왘Project managementThe team in charge of the upgrade project that manages all activitiesthat are part of the project.왘TechnicalThe IT team that manages the system technology such as hardware,the operating system, and database software.왘DevelopmentThe software development team responsible for custom developments and modifications to the core SAP software.왘Business expertsExperts from the organization's business units who understand thebusiness processes and how SAP functionality is used within eachprocess.Although the system landscape shown in Figure 5.1 assumes an upgradefrom SAP R/3 4.6C to SAP ERP 6.0, the source release is not a relevantfactor in these examples, except for very old SAP R/3-releases. The mainobjective is to show how the system evolves with systems runningeither the source or the target release, culminating in an upgraded production system.5.1.2Project PreparationProject preparation is the first phase of the project, where initial work isdone on an upgraded copy of the production system.Sandbox systemThe project management team must first arrange for an upgrade projectsystem to be available. The next step is to prepare the upgrade projectsystem (the sandbox system) as a copy of the production system (see Figure 5.1). Ideally, you should include as much realistic production data aspossible in the upgrade project system.162www.sap-press.com
Managing the System Landscape During an Upgrade ProjectSBX4.6CUpgrade projectsystemSysteDEV4.6CProductivesystem3 wksMonth 15W8 wksMonth 2mcopyQAS4.6C3 wksMonth 3PRD4.6C2 wksTimelineMonth 4Figure 5.1 System Landscape During the Project Preparation PhaseProject ActivitiesThe following activities should be carried out in the project preparationphase:왘The project management team creates a detailed project plan, nominates the project team, and orders temporary hardware.왘The technical team prepares the sandbox system (SBX), also known asthe upgrade project system.왘The development team reviews custom developments and modifications.왘The business experts study material on the new release (for examplerelease notes and the contents of the Solution Browser tool for SAPERP). They start preparing test scenarios and planning test execution.Deliverables/OutputYou have now established an upgrade project system (the sandbox system). The first version of the project plan is available, along with com-www.sap-press.com1635.1
5Executing an Upgrade Projectprehensive understanding of the scope of the project in terms of technical, process, and functional changes that will be included.5.1.3Upgrade BlueprintIn the upgrade blueprint phase, the focus is on experimenting with thesandbox system through familiarization and testing of the new software(see Figure 5.2).Upgrade projectsystemSBX6.0ProductivesystemDEV4.6C3 wksMonth 15 wksMonth 2QAS4.6C3 wksMonth 3PRD4.6C2 wksTimelineMonth 4Figure 5.2 System Landscape During the Upgrade Blueprint PhaseDiscoveryUsing this system, the technical, development, and business teams canbegin the process of "discovering" the new software.Project ActivitiesThe following activities should be carried out in the upgrade blueprintphase:왘The technical team executes a technical upgrade on the upgradeproject system. A key activity is running and measuring the upgraderegarding downtime, and testing downtime minimization approaches.164www.sap-press.com
Managing the System Landscape During an Upgrade Project왘Developers perform SPDD/SPAU adjustment and test custom developments and modifications. SPDD/SPAU adjustment is not a necessary step and can be skipped to reduce project effort.왘Business experts carry out upgrade Customizing and testing of business processes (test cycle I: takes two weeks)5.1Deliverables/OutputAt the end of this phase, business processes should be running properlyin the sandbox system and there should be detailed documentation ofthe adjustment activities carried out by the development team.These activities will help you refine the project plan and better understand the scope of the project.5.1.4Upgrade RealizationThe upgrade realization phase marks the beginning of the dual maintenance period (of the DEV' and DEV systems). Figure 5.3 shows the system landscape during the upgrade realization phase.Upgrade intenanceProductivesystem1. Copy2. UpgradeDEV6.03 wksMonth 13 wksMonth 2QAS6.03 wksMonth 3PRD4.6C2 wksTimelineMonth 4Figure 5.3 System Landscape During the Upgrade Realization Phasewww.sap-press.com165Refine the projectplan
5Executing an Upgrade ProjectDual maintenanceIn this phase, you create a copy of the development system (DEV') andperform a technical upgrade on the main development system (DEV).Alternatively, you can create the 6.0 DEV system as an upgrade from acopy of the production system (if size and security considerations allowit). This has the following advantages:왘Consistency of DEV and PRD concerning development objects is easily enforced.왘The upgrade of the production copy can yield a good assessment forthe production upgrade (discarding factors such as machine size).A disadvantage of copying the production system and upgrading it forthe creation of the DEV system is the loss of versioning information,especially for ABAP developments.Development activities concerning the upgrade project take place primarily in the main development system. However, the copy of DEV(DEV') is used to provide continuous support to the production system.During dual maintenance, any changes you make to the contingency system because of production support requirements must also be made inthe upgraded development system. It is important to consider a codefreeze during this period. For suggestions on managing a code freezeduring the dual maintenance period, see Section 4.4.2, “Technical BestPractices,” in Chapter 4. Changes you make to the development copy(not yet upgraded) are transported to the quality assurance system (QAS)and from there to the production system (PRD).Project priorityAlthough the upgrade project should take priority, it is possible to continue working on concurrent projects. For example, you could work ona project that introduces custom development in the upgraded development system but for which the changes are not transported to the production system until after final the production cutover.Project ActivitiesThe following activities are carried out in the realization phase:왘The technical team sets up a temporary development system formaintenance (DEV’) and upgrades the development system (DEV).166www.sap-press.com
Managing the System Landscape During an Upgrade Project왘Developers manually redo the SPDD and SPAU adjustment, manuallyredo the adjustment for custom developments, and perform shortunit testing in the development system (DEV).왘The business experts redo Customizing adjustments and perform unittesting in the development system (DEV).Deliverables/OutputBy the end of this phase, you should have completed the unit testing forcustom developments in the development system (DEV).5.1.5Final Preparation for CutoverIn the final preparation for cutover phase, you create a copy of the quality assurance system (QAS') and upgrade the original quality assurancesystem (QAS). Figure 5.4 shows the system landscape during this phase.Upgrade projectsystemSBX6.0TemporarysystemDEV‘4.6CQAS ‘4.6CDualmaintenanceProductivesystem3 wksMonth 11. Copy2. UpgradeDEV6.05W8 wksMonth 2QAS6.0Transferchanges3 wksMonth 3PRD4.6C2 wksTimelineMonth 4Figure 5.4 System Landscape During the Final Preparation for Cutover PhaseDuring this phase, you continue dual maintenance of the developmentsystems. You also transfer changes that you make in DEV' to DEV, andtransport changes to both quality assurance systems.www.sap-press.com167QA systemupgrade5.1
5Executing an Upgrade ProjectProject ActivitiesThe following activities are carried out during this phase:왘The technical team sets up the temporary quality assurance system(QAS'), upgrades the QAS system, transports project work to the QASsystem, and continues to refine the cutover plan based on the workdone so far.왘Developers correct errors in custom developments.왘Business experts perform final integration tests in the QA system (testcycle II: takes one week) and regression testing in the upgraded QAsystem.Deliverables/OutputDuring this phase, the testing of business processes is completed, thedowntime estimate is refined, and the cutover plan is finalized andapproved. You should now be in a position to embark on the final phase:the cutover weekend where you upgrade the production system.5.1.6Production Cutover and SupportThe production cutover and support phase is the final phase that marksthe completion of the upgrade project and culminates with the go-live ofthe production system. Figure 5.5 shows the system landscape for thisproject phase.ProductivesystemDEV6.03wks5W8 wksMonth 1Month 2QAS6.03 wksMonth 3Transferchanges2 wksPRD6.0TimelineMonth 4Figure 5.5 System Landscape During the Production Cutover and Support Phase168www.sap-press.com
Downtime Minimization5.2Project ActivitiesThe following activities are carried out during this project phase:Final phase왘The technical team upgrades the production system (PRD) (includingdowntime). When finished, it performs post-upgrade activities.왘Business experts sign off on the upgraded production system.왘Depending on the archiving strategy, DEV’ and CON’ may bearchived.왘It might also be advisable to keep DEV’ available for some time afterthe upgrade to check the former functionality in case of unexpectederrors.Deliverables/OutputAt the end of this phase, the SAP ERP 6.0 system is released for productive operations and the temporary system landscape is removed. This isthe final milestone: formal project closure. However, there is still a needfor ongoing support of the upgraded system. Appropriate support activities must be adjusted and establishe
6 Upgrade Tools and Services. 199 7 Customer Cases and Upgrade Communities. 253 Appendix A SAP ERP Upgrade Checklist – Project Preparation. 323 B SAP ERP Upgrade Checklist – Blueprint. 327 C SAP ERP Upgrade Checklist – Realization. 333 D SAP ERP Upgra
