Is There Value In Moving to Suite-on-Hana First Prior to S/4HANA

[former_member192418]

If you are an existing SAP ERP customer thinking about transitioning to S/4HANA then chances are you have spent some time pondering this question. Breaking down an IT project into smaller parts and tackling each part independently -when technically possible- is generally not a bad idea. In the case of S/4HANA, that would mean first to migrate your database to SAP HANA leaving your ERP data structures and application layer intact (aka Suite-on-HANA). At a second stage, you would then transition to the new S/4HANA data model and application code line. For the purpose of this blog, I refer to this approach as the two-step approach.

At the face of it, a two-step approach seems like a prudent course of action especially given the mission-critical nature of ERP in organizations today. However, you should only consider this route for the right reasons as it comes with cost and effort implications that can be avoided in a one-step move to S/4HANA.

In this fourth installment of the “S/4HANA Business Case Blog Series” I present a case where opting for the two-step approach isn't the most prudent course of action and a couple of cases where it is.

 

The case against the two-step approach

Customers that I’ve spoken to that are contemplating the two-step approach are considering it from the standpoint of de-risking their transition to S/4HANA. They point to the new S/4HANA data model and code line as sources for their perceived risk of not going for a one-step approach. I use the term “perceived risk” not to take away from the importance of risk mitigation as a necessary element in any ERP project. I use it because S/4HANA today is in its 4th release (1809) with over 5,000 customers (as of Q3 earning calls) who are either live or who have a project with an active known go-live date. So, the risk factors that might have existed back during the early launch days of 2015 when the solution had a limited scope (Simple Finance only), and less number of live customers is long gone.

However, perhaps you are well aware of S/4HANA’s latest release scope and customer adoption figures and still thinking about moving to Suite-on-Hana first as a way of de-risking the project and easing the transition to S/4HANA. If that is the case, then a two-step approach will not achieve your desired goal. Yes, you will get the chance to run your ECC as-is on HANA and test that out for a period before moving to S/4HANA. However, if the source of your perceived risk was the code-line and data model change then moving to Suite-on-Hana will not mitigate any of that perceived risk as it doesn’t allow you to test these changes. This means that your perceived risk remains unchanged once the time comes to move from Suite-on-Hana to S/4HANA.

A far better – and more economical -way to mitigate that perceived risk is to test the impact of these changes using the available S/4HANA readiness check tools and start tackling the recommended pre-projects such as moving to the new SAP Credit Management (FSCM) if you are still on the older version (SD-BF-CM). This is something you can do today in your current ERP system without the need to move to Suite-on-HANA. If you aren’t aware of the readiness check tools, then check out this 2-min video from my colleague Carl Dubler who explains them very effectively.

It is worth noting that if you opt for the two-step approach, you will still need to undergo IT planning and testing efforts before going live with Suite-on-Hana. Yes, these efforts might be less than those required to move directly to S/4HANA as the data model doesn’t change, but that doesn’t mean they can be casually dismissed or ignored. Moreover, the Suite-On-HANA planning and testing costs will not reduce or count towards any future planning and testing efforts required for moving from Suite-on-HANA to S/4HANA. You will still have to incur these efforts too. Given that the benefits to the business and end users of Suite-on-Hana will be barely noticeable compared to S/4HANA, you will have to weigh these against increasing the overall implementation costs and efforts of your S/4HANA project by adding an intermediate step. You also need to consider whether your business and end users are ready to undergo two projects vs. one.

Some S/4HANA customers moved to Suite-on-Hana first during the early days because they were trying to ease their transition to S/4HANA. However, when asked during ASUG events what they would have done differently if they were to do it all over again, many of these customers stated that they would have done a one-step migration citing the avoidable double effort of the Suite-on-Hana intermediate step.

 

The case for the two-step approach

There are a couple of cases where incurring the added efforts and costs of the two-step approach can yield net positive cost savings.

Let's say you have a burning pain point around transaction latency in your current ERP environment that has a quantifiable financial impact to the business – such as long MRP runs that result in material shortages and late deliveries- that need to be addressed immediately and can't wait for the S/4HANA pre-projects and custom code remediation. If the measured financial impact of the latency is more than the costs and efforts of adding the intermediate Suite-On-HANA step then, in this case, the two-step approach would make sense. In this scenario, the short term financial business gains that result from eliminating the latency would end up offsetting the added effort of the two-step approach.

The second case is more due to contracting issues. Let’s say a company decides to move to S/4HANA but is still in the early planning phases of the project. At the same time, their classic database contracts are about to expire before they can complete the recommended S/4HANA pre-projects and custom code remediation. In this case, it could make sense from a cost standpoint to retire the classic database contracts and move to Suite-on-HANA first until the S/4HANA planning and pre-projects can be completed. This would be in contrast to incurring the costs of renewing these contracts knowing that the company will be moving off of their classic databases in the near term. This is because the licensing of HANA in Suite-on-Hana deployments counts towards future HANA licensing in S/4HANA deployments. So the added efforts and project costs of Suite-On-Hana can be offset by savings from retiring the classic database contracts.

 

Conclusion

Even though SAP’s migration tools (SUM/DMO) fully support a one-step move from ERP 6.0 to S/4HANA, customers still have the technical option to stop at Suite-on-HANA first before continuing to S/4HANA. If you decide to take this option make sure you are doing it for the correct reasons so you can reap benefits from the added effort and costs of that approach.

Please share your thoughts in the comment area below. Perhaps there are other reasons you are considering in going to Suite-on-HANA first before S/4HANA that your specific company or IT department is facing that I haven’t considered.

Finally and if you haven’t already, check out some of the other blogs in this blog series below.

How to write your first “Hello World!” SAP S/4HANA business case – Part I

How to write your first “Hello World” S/4HANA business case – Part II

How To Build The S/4HANA Business Case Part III – A Deeper Look Into Days Sales Outstanding