S/4HANA In-Place System Conversion Blog Series 01/10 : When to Choose ?

[satinder_singh]

I am S/4HANA evangelist and support customers on their HANA journey. Recently I completed a project for S/4HANA conversion and through this blog series I want to take you through my project life-cycle; How to start, plan and execute; What to keep in mind and watch out for. This is topic #1 of 10 part blog series.

So lets start with, when to chose the in-place conversion method over other options available like Greenfield, Landscape Transformation, 2 step approach (Suite On HANA, Simple Finance) etc. If you are an existing SAP customer with 1) no major concerns / pain points about your current system's "setup" 2) no roadblocks (with respect to add-ons / business functions) are identified as part of assessment (more on this later), 3) want to retain "current" customization and data in the target landscape as-is, then in-place system conversion is the recommended option for you. In-place System Conversion to S/4HANA allows minimal business impact, zero impact to integrated applications (except for out of the box SAP integration which might get impacted based on the version interoperability : Note 2251604) and continue with as-is business process (except for "limited" mandatory S/4HANA features).

Figure 1 : System Conversion Pros and Cons (Source OpenSAP)

Some Myths about System Conversion that deter customers from choosing this option are:
Myth #1 : There are a lot of prerequisites for System Conversion.
Myth #2 : My data/configuration is not clean hence data migration will have a lot of issues.
Myth #3 : 600+ Simplification Items mean a major change to my existing business processes.

My take is that most of the long time SAP customers, who have trust in the system they have built and do not want to restart from zero with a greenfield approach, will prefer in-place system conversion.

The fact that none of the above myths are true does not mean that you will not get new benefits from S/4HANA innovations but it means that you can adopt them at your own pace instead of being forced to adopt them all at one go, including the FIORI adoption !!! Infact, while these above myths are always proven wrong post S/4HANA go-live, what customers learn later is that, user adoption and change management are bigger issues. Thus the availability of innovations (help with value case of the project) and ability to adopt innovation in phases (controlled change management) is a great combination with S/4HANA.

S/4HANA has come a long way since its first version (1511) where you had a lot of product issues and also the tools provided by SAP were very rigid. Today SAP has done away with a lot of prerequisites for System Conversion and also the improved the conversion tools to allow the data variations that do not impact to-be S/4HANA system (a lot of RED flags are converted into Warnings and Exemptions). Also S/4HANA data model (in latest versions) is simplified based on customer's feedback and usage frequency of the product features (200 Simplifications in 1511 vs 654 simplifications in 1909). In addition, there are various technical implementation options available for In-place System Conversion like. 2 step, SUM DMO, Downtime Optimized SUM DMO, Shell Copy with selective data migration etc that provides you flexibility to chose the implementation plan based on the fine tuned requirements.

Once the initial inclination towards in-place system conversion is established, next "MUST" step is to perform a thorough assessment of your active business processes, technical and infrastructure setup to identify the potential roadblocks to S/4HANA and plan early for them. In my experience I have seen that almost all of the customers did an assessment before embarking upon S/4HANA Program. Our organization has a detailed methodology for the same called 'Safe Passage Assessment' supported by our proprietary tool "Infosys S/4Assist" which helps you to deep dive on your landscape (NelsonHall Blog). This tool set provides you additional information on top of SAP provided Readiness Check and Custom Code Impact Analysis to plan your in-place system conversion. Although the detailed assessment will be done to get the project approvals, it is also recommended to do another assessment (for delta impact) to help plan project phases better, just before the start of the project to identify impact based on the current system state and S/4HANA version chosen (With S/4HANA since a new major version is released every year, it is recommended to go with latest version / FPS; what is available when you start your DEV system conversion and then the same version is frozen for go-live).



Once it is decided that In-place System Conversion is the right option for you, decide on the timeline for your program (considering the business availability, other critical programs running in parallel or critical roadblocks called out in the assessment😞
#1 If you can start the program immediately ; then proceed to TOPIC 02 directly.
#2 If there will be a delay, then you can execute a lot of pre-projects in your ECC system itself while waiting for the actual conversion to start. e.g.

1. Some of the mandatory S/HANA features are available in ECC too (FSCM, Settlement Management etc) hence can be implemented or the design/prototype completed in ECC itself.


2. CVI allows you to split BP activation into 2 parts wherein the BP conversion can be done in PROD upfront and BP activation later as part of  conversion project. This provides more time to business to do data cleanup and also saves project effort as CVI is done once in PROD instead of multiple times for each conversion cycle (more on this in TOPIC 04).


3. Typical usage of Custom code varies between 50%-75% thus the unused code can be de-commissioned; either as pre-project or during the conversion project using the customer code migration FIORI App.


4. Good part of the custom code remediation and cleanup can be done in ECC that will simplify the conversion phase later


5. Some aspect of change management can be expedited where the new feature is already available (but optional and coexists with old feature) in ECC but old feature is deprecated in S/4HANA.


6. Any other recommendation called out during assessment with respect to add-ons / business functions.


7. Read more examples in the blog.

Now that we know when to chose in-place system conversion and how to confirm if it is the right option for you, it is important to decide the scope of the program to avoid unnecessary complexities to the program. As In-place System Conversion to S/4HANA is mostly a technical program, my recommendation will be to keep additional / optional new features as pre or post projects. Thus it is important to define a clear project charter which will serve as guide-post too during the later execution stages.

One of the big reasons I have seen customers missing the schedule of their conversion program is either a poor assessment or loose program charter !!! Read this blog to learn what other customers have to say.

In TOPIC 02, we will discuss "How to prepare for S/4HANA In-place System Conversion".