SAP Upgrade Methodology:
Introduction:
SAP R/3 Upgrade is the most important phase of any Project. Upgradation is done especially to meet any unique business requirements of an Enterprise, to move away from custom programming (though not altogether) and adapt standard SAP functionality.
Methodology:
The Upgrade Project Lifecycle can be explicitly divided into the following phases:
Phase I:
- Project plan
- Test planning
- Release strategy
- Resource mobilization
- Contingency Planning
This is the Planning Phase of any Upgrade Project. Before beginning, it is highly essential to verify that there is technically a direct upgrade path between the source and target versions on the SAP Service Marketplace including any Industry Solutions. Redefine Business case and Metrics; Establish the Project Plan, then the Agenda for the Project is scheduled, derive the Project estimates, validate the estimate and the resource needs, organise the same. Leveraging the existing processes for development, testing, deployment and transition will decrease the work efforts by 10-30% in contrast to its comparable implementation. Ensure that the scope for Technical upgrades are restricted to the existing functionality and processes, effort is required to confirm if there are any major changes on them based on the review of SAP released notes and documentation.
Phase II:
- Gap Analysis between SAP old and newer versions.
- Identify business flows & custom development for testing
- Test scripts preparation
- Business flow testing in Sandbox system
- Error Identification
- New functionality Identification
This is the Analyze Phase of any Upgrade project. Analyze business processes, Identify Application requirements, Assess Process gaps and define a Role based Authorization design. A list of Development objects critical to the SAP Upgrade must be defined with accuracy. All Efforts to identify the interface points and all application integration.Incase, Client has a test model that is recently used then complete the Test Scripts, Expected results and Test data else complete the re-work and re-development of the entire Test Model. A Sandbox instance needs to be created early in the analysis Phase. Performing Sandbox Upgrade to the new SAP version using the existing Development or Production instance will enable us to forecast the new requirements and the changes foreseen in the Upgrade. It is very essential to conduct SAP Technical Upgrade Assessment and Go-live Functional Check. During Integration Testing, check for unusual long runtimes for Custom Program and transactions; identify any new errors in the existing functionality along with the new functionality that needs to be added.
Phase III:
- Determine Resolution for Gaps
- Identify and design the configuration required
- Determine development work for error resolution
- Consultant testing in Test System
- Design new functionality
- Identify Conversion activities in Productive system
- Super User Training
This is the Design Phase of any Upgrade Project. During this phase, Configuration Upgrades are made and minimal configuration adjustments are detected and adjusted during testing. About 10-20% Design effort is required to remediate the errors in the custom report and other Technical developments since there is a change in the standard SAP Data Model and Data Dictionary objects. Here, Consultant Testing plays an important role in the identifying the minimal errors and adjusting the same. Plan Conversion activities since existing data is in place during the Technical Upgrade.
Phase IV:
- Configure the systems as per the gaps and errors
- Implement relevant SAP Notes & Patches
- Implement Programming Changes
- Implement new functionality
- Consultant/Superuser testing in Test System
This is the Build Phase of any Upgrade Project. Complete the master configuration as per the errors identified and gaps recognized. Build and test the Application components and Technical Architecture through SAP notes and Development changes for the new functionality.Hence, it is necessary to install all the environments needed to support the Upgrade environment. Prepare training material and all the documentation that is necessary for the Enduser/Superuser training in the Test System.
Phase V:
- Final Superuser testing and confirmation
- Resolution of errors identified in Super user testing
This is the Test Phase of any Upgrade Project. Application testing and Integration testing should be completed in full in order to ensure that Upgrade relevant changes works in tune with the Business Processes. Super Users play an important role in testing the same and reporting any new unforeseen errors but at the same time responsibility lies within the Consultants and the Technical Team to ensure that any functionality not working is not a totally new requirement and is a part of the already existing functionality. This will avoid any time and effort being wasted in a totally new functionality.Hence, there should be a trial run of the upgrade process, including all pre- and post-validation tasks, business continuity tasks, and technical upgrade tasks. This is to ensure the Completeness of the Cut-over strategy, resource allotments and various dependencies.
Phase VI:
- Transport upgrade relevant changes in Productive System
- Final Conversion activities
- Go-live
This is the Deploy Phase of any Upgrade Project. Plan for deployment. For this, it is highly important to assess Deployment readiness, authorize deployment, Plan a detailed Release strategy to transport the Upgrade relevant changes to Production. The next task in line will be the plan on Conversion of Data and hence Migration to the Production.Normally, majority of the Upgrades stabilize within a week before the actual handoff to the Support Team.
Testing Management & Control:
Testing is extremely essential, test scripts should be actual, provided by business. Business should be involved as much as possible, to prevent testing of programs or functionalities that is no more used and ensure that programs and functionalities that are used are also tested. Actual and complete test scripts prevent losing time by ineffective testing and surprises after go-live.
Testing has to be done with different customers, domestic and foreign in different countries, to detect language dependent errors.
Print programs in MM (Purchase Order) and SD (Sales Order, Delivery, Invoice) need special attention, because they are very often and very much modified to suit special customer requirements.
The output has to be tested thoroughly and inspected very attentively. The following needs to be checked:
- Are all necessary fields printed out
- Are addresses right and not only with one item line, but with two, three or many.
- Are the texts printed right, is with languages everything in order etc.
User acceptance test with real business roles should be done as extensively as possible, because what is functioning with consultant authorisations /sap-all might not be functioning with business roles with much less authorisations.
Release Strategy:
Follow a detailed and planned strategy to release transport requests relevant to Upgrade. The transport can start from the Sandbox System.But, before being imported to the Development System; the transport requests can be stored in a buffer. Similarly, transport from Development System to Quality Assurance System and from Quality assurance to Production system follows the same strategy.
Country Version Approach & Impact:
Country versions should be given special care to ensure that country-specific deviations and Taxes due to legal implications work well without any issues.
The Go Live Approach , Follow-up Activities, Critical Success Factors & Deliverables:
All development should be stopped. Just the minimum of changes absolutely necessary for support should be done, no other new modules or add-ons should be installed at the same time, otherwise the situation can become very complicated.
Dump analysis is very important to detect errors and these dumps should be taken care of on a daily basis, when testing and after go-live
User variants /batch job variants tend to disappear or become outdated.
Interfaces should be tested very carefully, by users themselves, because only they know what they are really doing. The interface might be functioning basically, but for example the search help for material is not functioning at all. It is difficult to compile all such details in test scripts.
For workflow, a really experienced expert should be involved. Otherwise the search for errors might cost lots of time.Many programs are involved, standard and customer objects and their interrelationship is difficult to see and debug, especially with background processes. And if workflow is not working after upgrade, it might be difficult for customer to find workaround.
It is good to keep a non-upgraded system until the go-live and intensive care period is over. It is quite often good to see, how customer programs were functioning before upgrade, copying of pre-upgrade programs or methods might be very useful to make customer programs run again, when they are using standard ABAP objects that are changed by upgrade or even no more existing after upgrade. And users tend to claim after upgrade that functionalities are no more working, which never have been functioning, to get them without a change request. All these should be taken care of.
Hence, I believe that the above mentioned methodology and key points would suffice to ensure a planned and successful Upgrade without any major surprises or chaos.
