I. From the Project Manager perspective.
Every SAP S/4HANA conversion project will have its own particularities and complexities, but I hope that this blog post will help the PM community approach, prepare and plan a conversion project to SAP S/4HANA.
Customers have several options for their move to SAP S/4HANA. The most common approaches are: New Implementation, Selective Data Transition and Conversion (also known as Brownfield).
When a customer decides to go for the Conversion approach, it is usually for the following reasons:
- The current ERP SAP ECC implementation is successfully supporting the business, fully covering the processes as they currently are and also you want to keep all the historic data.
- The conversion is usually the fastest way to go to SAP S/4HANA, something between 6-9 months is more than reasonable.
Database size is an important factor to be considered but usually affects the downtime window rather than the complexity of the system preparation to be converted to SAP S/4HANA.
- It is usually the smoothest way to start to take benefit of the innovations in SAP S/4HANA, starting for instance with SAP Fiori.
Arguments for choosing Conversion
Once you decided that the conversion is the preferred option to move to SAP S/4HANA, you might ask yourself how to prepare the project, what are the relevant topics to estimate the project effort, how to set up the timeline, or how to decide about the number of conversion test iterations?
Before answering those questions, let me provide some indications which will make your project easier:
Sponsorship matters:
A conversion project is not only an IT project. Moving to SAP S/4HANA will have functional impact and will require the functional teams to assess and execute the functional changes and validate the system once it is converted to SAP S/4HANA. So, it’s important that the entire organization is aligned with the movement. Therefore, it is crucial to have a strong sponsor coming from the top.
Also, appropriate sponsorship will be very beneficial when convincing the customer organization about the downtime window for the conversion of the productive system.
Keep your system stable:
Don’t implement new functionalities on your current system while running the conversion project as you will create a moving target. During the conversion project you must keep your system as stable as you can, only changing those things that are completely necessary to maintain your business up and running.
Do housekeeping in your system:
It will be easier to move to SAP S/4HANA when your system is “clean” and up to date.
Remove obsolete and non-used custom code, as this will reduce the effort for adapting your custom code to SAP S/4HANA. There are some classic SAP tools e.g.: UPL, SCMON and CCLM which might help you to identify non-used custom code. Removing the waste will always be helpful.
II. Project Preparation and Key Topics for effort estimate
Readiness Check screenshot
It should be executed in your productive system or in a recent copy of it, and it will help you to identify:
- The SAP S/4HANA simplification items relevant for your conversion and the activities that are behind.
Your functional consultants have to analyze the result of the RC and be able to estimate the effort behind adapting each of the items relevant for the conversion to SAP S/4HANA. Based on our experience the most effort consuming items are:
- Business Partner / CVI
- General Ledger Migration
- New Asset Accounting
- Material Ledger
- New Credit Management
- Revenue Recognition > RAR
- Rebate Management > Settlement Management
- New Cash Management
- The custom code that is affected by the conversion and the correctives actions needed to be compliant with SAP S/4HANA.
To estimate the effort, you will need the support of ABAPers and functional consultants as they will be able to detect if the changes on the custom code could have side effects on functional implementations. Some typical examples are the “order by” on select statements or the Material Number Field Length Extension.
- The add-ons and business functions which are not compatible with SAP S/4HANA.
The RC will identify those add-ons that are not compatible with SAP S/4HANA. These add-ons can block the conversion; therefore, they have to be removed from your system. If the functionalities that they offer are not available in SAP S/4HANA but are a business requirement you have to look for an alternative to meet these requirements. For 3rd party add-ons the best way to know if an add-on is compatible with SAP S/4HANA is to check it with the vendor.
With the business functions the situation is similar, incompatible business functions with SAP S/4HANA have to be removed from the source system.
- RC will also provide information about required changes on integrations related with SAP BW extractors and IDoc interfaces
- And last, it will identify the SAP Fiori roles and apps which might be relevant to you as a quick win to start to benefit from the innovations in SAP S/4HANA.
These topics will be the main effort drivers to “only” prepare a system to be converted, but they are not as complex as they might seem.
To make the project effort estimation complete, you have to consider the effort of the actual conversion activities, the number of test conversion iterations to be executed, and the effort coming from other potential activities that might be needed for your project scope, e.g. validation activities..
The important thing from a PM perspective is not to miss any of the previous topics.
Another dimension to not forget is the landscape and hardware needs. The most common landscape running an SAP ECC system is: DEV -> QAS -> PRD, so for SAP S/4HANA, the same will be needed. It’s important to start the provisioning accordingly, and again, the RC will provide the relevant information about the SAP S/4HANA sizing needed including the potential DB growth.
The conversion test cycles must be done on sandbox systems, with the source system (SAP ECC) and target (SAP S/4HANA) being as similar as possible to what we currently have as productive system (SAP ECC) and what we will have as productive on SAP S/4HANA.
Sandbox Iterations
III. Approach: Iterations and planning (major activities)
I usually approach a conversion project with the following major phases
Project Approach
1. Preparation
Fully described from the system perspective previously, we identify the functional and technical impacts of moving to SAP S/4HANA and the target architecture.
Just like in any other project we must define the project plan, the validation plan, and the resource plan, considering that both technical and functional consultants will be required, in-line with the simplification items detected.
2. Sandbox Iteration I
To test the conversion process a sandbox system as recent copy of the productive system is needed. The source sandbox system should be as similar as possible to the productive in terms of hardware and processing capacity. This is crucial to plan the cut-over for going live as you have to record the amount of time that you spent during all the conversion steps.
For the same reason the sandbox target system must be aligned with what we will have as productive system in SAP S/4HANA and, of course, meet the minimum sizing requirements.
Don’t forget to follow the conversion guide, do not improvise.
Major activities during this phase will be:
- Prepare the source sandbox system to be converted, mainly adjusting the relevant items coming from the SI_Checks on the system.
- Execute the conversion and migration to SAP S/4HANA with the standard SAP tools provided (DMO of SUM).
- Adjustment of the objects and custom code to SAP HANA and SAP S/4HANA.
- Execute testing activities including integration testing.
This first conversion is very important to:
- Detect all issues and errors that might occur during the conversion process and the solution for them. It’s very likely that you must repeat some conversion phases to refine the process, so maintain save points allowing you to go back when needed.
- Identify those topics needed for the conversion that you can transport to your current productive system or complete them on it, so your productive system is better prepared for the conversion and you get them out of the project’s critical path, such as: CVI/BP, installation of technical and functional notes, ABAP adjustments which might be advanced and also fixes on data (usually on finance) among others.
This is very important as during the next sandbox conversion iteration you will be able to test and validate that all these topics are correctly implemented.
- Document accurately the entire conversion process and all your activities, splitting them basically in two major phases:
- The uptime: DMO of SUM prepares the system to be converted but the system can still be used as usual, except that at some point the system will be blocked for changes.
- The downtime: DMO of SUM requires to stop operations and the system will be down to finish the conversion activities on the target system on SAP S/4HANA.
Register the time spent in each of these activities, don’t forget the backups and how long they take.
All of this will be the basis for the cut-over plan, it will be your cookbook, your recipe for the conversion of the productive system, which you will refine during the second conversion iteration. - Start to manage the downtime window that will be needed inside the customer organization.
With the results of this iteration you should be able to start to plan the duration of the downtime and the concrete go-live date according to the business needs. Customers usually look for long weekends as it’s easier to stop system operations for more time than on a regular weekend.
3. Sandbox Iteration II
The number of sandbox conversion iterations is not fixed, it will depend on how successful the previous ones were.
Assuming that with the previous conversion test all activities, errors and their solutions were detected, Iteration II as the last one before the conversion of the productive system, is crucial as a dry run:
- Execute this iteration with the most recent copy of the productive system. Do not forget that your productive system should already include the topics mentioned previously: CVI/BP, fixes on data, preparation notes…
- Maintain the productive system as stable as you can, freeze the system and only make changes if really needed for the business continuity
- Refine the cookbook, review all the activities and their sequence, add the time spent on each of them and assign an owner to each activity.
You will have a clear idea how long the uptime and downtime phase will take, so you can start to plan when the conversion activities in the productive system have to start to meet the go-live date.
All of this will be the basis for your cut-over plan.
- Test the system converted to SAP S/4HANA again. End-to-end and integration testing.
Remark: During all the test conversion iterations and then during the conversion of the productive system it is crucial to maintain the same versions of tools and products.
4. Productive Conversion
As mentioned before the cut-over plan is based on the results of the previous sandbox conversion iterations. A good cut-over plan must cover the conversion process end-to-end and should ideally cover the following phases:
cut over phases
- Preparation:
Important to be sure that we have everything we need for the conversion of the productive system.
Relevant points here among others: check that we have access to source and target systems, that we have the appropriate credentials, that conversion tools are ready, that we have the appropriate filesystems.
- Uptime phase:
Start uptime phase of the conversion process with enough time to arrive at the downtime window with some buffer.
Remember that during this phase the system can be used as usual. This adds workload to the system which can provoke some activities to take a bit longer than initially planned.
Once the uptime is finished, you’re ready for the stop of operations.
- Stop of operations and downtime phase:
The source productive system will be stopped, and a full backup needs to be made before continuing with the downtime conversion activities, just in case we need to activate a fallback plan.
The downtime will include the technical conversion activities for moving the system to SAP S/4HANA, the finance and logistics conversion activities for functionally converting the system to SAP S/4HANA, and finally some manual post conversion steps.
All these activities and their duration were identified during the previous sandbox iteration runs.
- Testing and start of operations
Once the system is running on SAP S/4HANA, it’s important to test that the most critical processes are running as expected. Only then the new system in SAP S/4HANA can be released for regular operations and to all the users.
In case the productive conversion does not go as planned, the go-live needs to be stopped and the system reverted to the original one. It’s important to always include a fallback plan just in case of need.
5. Development and Quality Assurance systems
Finally, you must complete your entire SAP S/4HANA landscape.
Meanwhile your Development (DEV) and Quality Assurance (QAS) system are moved to SAP S/4HANA, what usually is recommended is to use the last sandbox system converted as the pre-productive system.
QAS system usually is generated as a homogeneous copy from the productive system. Homogeneous copies with SAP HANA are quite easy and fast. Although, another approach could be to convert the QAS system to SAP S/4HANA before the conversion of the productive system, and then consider this conversion as another test run.
The strategy commonly used for moving the DEV system to SAP S/4HANA is the conversion instead of a homogeneous copy from the productive system, because:
- Customers normally don’t want to lose the projects / programs that they were developing prior to the conversion project. With the conversion process these projects / programs will be moved to SAP S/4HANA.
- Normally the hardware capacity of the DEV system is much lower than the capacity of the productive system, so the entire database doesn’t fit. With the conversion, you will only move the data to SAP S/4HANA that was in DEV.
To sum it up, there is not a fixed strategy for DEV and QAS systems and it will depend on the customer’s requirements.
IV. Conclusions.
As described previously, most effort and complexities can be found in the preparation of the conversion and in the first iteration. The first iteration is important to identify and solve problems and issues, document lesson learnt and also draft the cookbook for the cut-over
Additional iterations should focus on refining the conversion process, solving new incidents if there are, fine tune technically the process to minimize downtime and to set up the cut-over plan.
Remember that it is also very important to maintain the productive system as stable as you can, to avoid having a moving target or a "different" system every time a new conversion iteration is executed.
And last, as soon as you can, start to manage the downtime window with the business.
Example of Project Plan
Thanks,
David
- SAP Managed Tags:
28 Comments
