No matter what your starting point is, your migration to SAP S/4HANA needs the right structure and methodology
By David Lumley and Alex Bennell
There’s an old joke in which some people out walking ask a farmer the way to the nearest village. The farmer sighs and says: “Well, I wouldn’t start from here.”
It’s a ridiculous answer, because the walkers have no choice but to start from where they are.
Similarly, in an established business, no one begins from the best place. And so, when something new comes along, it’s not likely to be a simple trip. Instead, it’s a journey – and a journey with baggage.
Step 1 – simplify the core
ERP platforms are a case in point. The obligatory transition to SAP S/4HANA is beset by a huge amount of legacy SAP custom code, which is most probably where the unique business value of the enterprise resides. It’s code that’s built on an ageing platform, that is inflexible, and that provides no easy use of the technology enablers that are available now.
In our two previous posts, the first of which is here and the second here, we’ve considered the opportunities the shift to SAP S/4HANA provides for a radical rethink of finance, admin and technology functions. But first, organizations need to take stock of where they are – and of how they’re going to deal with all that baggage.
The first step could be to simplify the legacy core. This means removing bolt-ons, workarounds, and redundant processes that have crept in over time, and moving innovation and customization outside the core. It means strengthening what’s left – in other words, retaining in the core anything that works for the organization, and that is aligned with industry practices. It also means that the organization makes a new promise to itself, and sticks to it – and that is to be more selective henceforth about what really constitutes a core process, and to keep it clean.
Step 2 – build layers
With the groundwork done, organizations can start to build. This means exploring opportunities currently outside their core that may form a useful part of the design they have defined. Such opportunities might include digital applications, third-party tools, other systems, other applications, and developments tailor-made for individual organizations by a knowledgeable services provider. They then need to consolidate these into the strong architecture they have established in order to stop it turning into chaos. (Remember: they have a new sense of determination now, and they need to maintain it.)
Layering in this way will enable an enterprise to prepare for constant change. It’s an approach that embraces not just the ERP architecture, but also the organization’s entire business landscape.
As the process continues, enterprises need to ensure that events and stages along the way don’t distract them from the path they have set for themselves – and that is to develop and sustain a core that is strong, safe, and intelligent, and that retains sufficient flexibility to evolve in line with the needs of the times and of their organizations.
Do it in stages – and look for support
There’s one further point that needs to be made about implementation, and it’s an important one. Moving from SAP to SAP S/4HANA might seem to be a huge and daunting undertaking if it were conducted as one big “lift and shift.” But it doesn’t have to be this monolithic. With support and guidance, it can be handled incrementally, gradually creating a renewable enterprise along the way in one integrated architecture.
In a way, this brings us back to the analogy with which we started. Yes, it’s a journey, and with baggage to carry – but if you make the trip in stages, and if you have knowledgeable travelling companions who know the way, and who can help to share the load, it’s nowhere near as daunting.
And you won’t need to speak to any unhelpful farmers, either.
(David Lumley is Global Head of FPIA Consulting, Capgemini’s Business Services; Alex Bennell is UK Head of SAP Corporate Finance and Procurement, Applications)
