Many organizations are working on it or contemplating it: the move to SAP S/4 HANA. Deemed a necessary evil by some, and a huge opportunity for business benefits by others. One thing is certain, the route is perilous and a lot of resources have already been wasted on it – while the majority of organisations still have to get started on it. Here, we share our experiences and some pointers on how to
get it right.

SAP… the German business software we all love and hate at the same time. With about  40.000 companies running SAP ECC for their core processes, it is definitely wide-spread and a serious backbone to many companies and industries. Its dependability and sturdiness has been core to its success and that of many organisations, and at the same time a cause of frustration when (online) business demanded quick turnarounds on new business models and features.

In comes SAP S/4, the ERP redeveloped for a new age. Although it was launched already half a decade ago, most companies still need to embark on their journey to S/4. On the one hand, the benefits of S/4 compared to what’s in place still prove hard to sell. On the other hand, moving to S/4 is not the same as a periodic upgrade, and even those have been traditionally put off by many organizations.

Some have made the move, spurred on by the promise and vision, or by the necessity of having to changes anyway and combining this with S/4. From those cases quite a few lessons can be learned, that can benefit those that still have to go… 

This is the first in a series of short articles, highlighting some of these lessons. Use it to your advantage, and stay tuned for the next ones!

Where to and in how many steps?

What is your intention for the move to S/4? The most basic scenario may simply be to stay “in support” with your ERP. With a bit more ambition you see it as the establishment of a new base to support (changing) business requirements better. Next level is if you even have concrete business transformation goals that the move to S/4 will help reach.

When you’re touching the core of your business, it generally should not only bring the pain and risks of a migration as in that basic scenario, but add some real business benefits, too. Since it’s called a migration, it is often first just passed on to IT. Making sure that it is not just an IT party is essential to making the
whole thing worth it. At the same time blowing it up and putting too many things into one project or program and tying it to one date does not make things easier to manage, either. So, think about a solid transition (or transformation) roadmap.

The roadmap allows for making the journey in manageable stages instead of one big leap. Funnily enough, this does not have to take longer! With a good roadmap both the scope of each step and the outlook beyond is transparent – reducing risks and enabling buy-in, preventing scope creep due to cramming everything in the project in a “now or never” spirit and making the dependencies so complex that nothing moves in the end (or everything breaks).

As the migration/conversion itself can be quite a big thing, and some things are really best done at the same time (e.g. chart of accounts or legal structure changes or clean up), it is worth investigating what can already be done before (in ECC, in the organisation, in other legacy) and what can be done after  the go-live with S/4 (improvements, automations). For the latter this should still be tied to the project or in some other way firmed, as to avoid the perception that “later” may turn out to be “never”. 

Why and how – and why that way?

Having clear goals (and not just a budget) at the start helps, but sticking to realising those along the way is what really matters. Eyes on the ball, please. Having a shared understanding of what a program will deliver when, and what we will have to do to make that happen, avoids discussions and disappointments. Having clear (and committed!) what is truly important and what is a nice to have, ensures we can make tough decisions when we are under pressure of time or money.

A lot of the pressure of time and money can be avoided anyway: we are still surprised how many projects start without a clear method and plan (and not just a planning). Then of course: truly understanding that plan, approach and methodology and not just on “PowerPoint-level” beforehand. And sharing that understanding and the implications across all teams and streams. This prevents a lot of surprises and delays along the way. Know what you are getting into, what the consequences of the approach are and what risks need to be monitored. What are the entry criteria of each phase and how are we ensuring those are covered by the steps before?

No “we’ll cross that bridge when we get there”, under the guise of Agile. No kicking the can down the road (or to the next phase) on difficult topics. Ask every question and demand clear and complete answers from your partners and your own people in this. No, you’re not stupid when asking basic questions, you’ll feel stupid if you don’t and the project slips up because those basics were assumed but not covered.

When you have done all of this you will have secured a foundation to that allows you to be in control of the project, your partners and last but not least your results.

If you feel you lack sufficient constructive criticism in your organisation, ask an independent party to be the challenger (and teach your own people in the process).

What’s next

Now that we have discussed the why and the how – yes, still on a high level 😉, we’ll dive into the what and who and quite a few more with their common pitfalls in the next part of this series.

Let us know what you think, share your builds or questions. We’re always interested in your feedback and different perspectives.

If you feel you could use some help or reflection on your own S/4 journey, wherever you are on it, reach out to us for a candid conversation.