The biggest challenges of S/4HANA implementation

SAP is one of the biggest IT companies in the world which leads to major investments in S/4HANA. At the end of the day, S/4HANA is at the leading edge of ERP functionality. This comes with lots of innovation, speed, and the latest technology as well as some drawbacks. Some of them have easy fixes, some not so much. Let’s look at some of the points and see how an API platform can help to resolve them. 

PwC and LearnIX survey found out that the top 3 challenges for S/4HANA migration are:

• Complex legacy landscapes (a challenge for 60% of respondents)
• A high degree of customization (a challenge for 59% of respondents)
• Unclean master data (a challenge for 51% of respondents)

Complex legacy landscapes

If there is one thing that enterprises are very bad at, it’s saying goodbye to legacy systems. It is often too costly and requires too many resources for planning and execution to sunset the system. In most cases, enterprises opt to work around this problem – leaving legacy systems as is and adding tons of custom code on top. To add complexity, legacy systems often come with complex data structures and data transformations. 

Once your enterprise gets to S/4HANA migration, you have to take these systems into account. There are 3 options for each legacy system:

1. Replace with a modern system, which often is a long and expensive task
2. Try to integrate directly with S/4HANA and replace legacy down the road (adding even more cost)
3. Connect with S/4HANA using API Platform. Once you decide to sunset your legacy system, you will have to change only System – API Platform integration while API Platform – S/4HANA integration can remain mostly the same with minor adjustments.

As you can see the two benefits of the API platform in this case are:

1. You transform your legacy system into a building block that can be replaced at any time. While it remains, it still can communicate with surrounding systems as before and with S/4HANA as per “target architecture”
2. Data mapping and transformation can be done with the integration process allowing for much easier and cheaper data migration down the road.
3. You have a centralized body of governance that can issue naming conventions and other agreements – that puts your enterprise in a state where if you decide to change any of the legacy systems, your new APIs will have to be developed using agreed conditions while apart from changing endpoints, there is no impact on API platform or surrounding systems – they keep using the same functionality as before. Same as changing a light bulb, it shouldn’t require you to undergo expensive reconstruction just because you want to switch from one type to another.

A high degree of customization

Any customization in ECC or between ECC and surrounding systems will have to be revisited. In the best-case scenario, the migration can be done with minor development. Worst case (and this case occurs quite often) you will have to throw out all existing integrations and rebuild from scratch (throwing out part of previous investments). S/4HANA shares many capabilities with ECC, but as S/4HANA was a complete redesign it differs considerably in some areas. S/4HANA is created to take advantage of capabilities that were not available in ECC.

As a result, it is clear that you will have to rebuild a lot. While it’s clear that no API Platform can help with improving internal customizations in ECC that will not work in S/4HANA. At the same time, some customizations can be rebuilt to work as a building block with the API Platform (see the previous point). And most importantly – since you have to rethink your process and way of working, you can avoid the same pitfall in the long term. Unless your enterprise doesn’t see further than the next quarter of the current financial year, the next upgrade costs can be dramatically decreased, and importantly – your system architecture can be set up in a way that would allow the onboarding of any system fast and simple. All customizations will remain on the system side while the API platform would support clear, straight connectivity with S/4HANA. 

This is the case where your IT house is made of API bricks, API bricks are glued together with API Gateway and you can replace them one by one without rebuilding the house.

Unclean master data

Data migration from ECC to S/4HANA is an extensive and often underestimated task. It is estimated that moving unclean legacy data can take up to 40% of your total data migration cost. This means that you have to do heavy data analysis and land on clean, clear data, which will be the basis for your fresh start with S/4HANA. 

Sounds simple to migrate and transform what is needed. The problem starts once some stakeholders decide that legacy data is still needed (because of internal decisions, government regulations, or other reasons). The solution from the API Gateway point of view would be to first still clean out and migrate clean data to S/4HANA while the remaining data shall be served from external databases via APIs to S/4HANA and surrounding systems.

Complex system for large enterprises

S/4HANA is not a simple system. Its implementation requirements and migration process make this ERP system not suitable for small enterprises or enterprises with simple products. S/4HANA cloud is best suited for organizations of 1500+ employees who want to run a two-tiered ERP system (hybrid). S/4HANA requires heavy involvement of S/4HANA experts, business analysts, and business representatives as well as data experts. This means that a big part of your business will be concentrated around S/4HANA migration. You need to consider not only direct costs of implementation but related costs (time and resources spent on redesigning the process, data cleanup and migrations and redesign of supporting apps and integrations, etc.). Concerning fact is that according to a recent survey almost half of CTOs think that S/4HANA migration can be completed in less than 2 years which is a very optimistic estimate and can end up costing lots of unmet targets and unpaid bonuses. 

As you can see it’s a huge project with lots of moving parts and redesigns. If you are spending so much time on redoing things, you should consider the API platform not only to help with the migration itself and its consequences on leaving ECC, but a crucial part in evolving API economy and business process modeling for short and long terms. Once you are running an infrastructure where everyone needs to play by the same rules any following migrations should be considerably cheaper and faster – once you build up your API infrastructure reflecting your business process, you can start manipulating them on an entirely different level. Get in touch with us to discuss this more in detail, because we can support you in this journey and make it smooth!