How not to get lost on the route to SAP S/4 HANA – Part 2
Hearing some of the stories on SAP S/4 programs it may feel that Frodo’s quest to get rid of the One Ring was a walk in the park. It really does not have to be like that. In this series of articles, we share our experiences and some pointers on how to get it right.
In the first part we discussed some questions (and suggestions) related to the why and how of embarking on the SAP S/4 journey. If you have not had a chance to read it, you can find it here.
Now let’s dive into the next part.
What … field?
As S/4 is a really separate product from ECC (and with it SAP has gotten rid of all sorts of obligations around portability and down-and upward compatibility) any migration is on the basic level a new implementation. Then comes the choice, do we go “greenfield” or “brownfield”. Greenfield is in essence putting down a new system and set that up with today’s knowledge and business requirements – not being bound or aided by all that we’ve built and used in “legacy ERP”. And Brownfield taking over all that we’ve got onto this new platform.
Due to some of the more fundamental changes/choices SAP has made as part of the redevelopment, a “Brownfield” comes with (technical) restrictions in any case. From code that is no longer functioning on the HANA platform to functions that have been “Simplified” – which in some cases means: “lean, mean and a lot better – welcome to the 21st century” and in some cases just: “no longer available”.
Fortunately you can check where you may have issues with these Simplifications and the restrictions because of custom developments through a “Readiness Check”. This is an analysis of the usage of the ECC system and custom code allowing to assess the impact of the move – and how much it would hurt to let go of your old ways/take them with you to S/4.
But since this is a migration and not an upgrade – there is another important angle to this green/brown field choice. Which and how much data do I want to take along? Which settings would I want differently than when I started with SAP many years ago? If we would be talking about cars here: in an upgrade we do some tuning to the engine and maybe refurbish the seats and clean the windows, with S/4 we’re getting a new car. And the family that is using it, may have changed.
Fields of golden
So there is a 3rd option called “Goldfield” – which is of course more appealing just by its name compared to “brown” 😉. The idea is that you mix the benefits of starting afresh with keeping what you’ve built and hold dear. Core to this is “Selective Data Transition” (SDT)– cherry picking which data and customising settings you take along, and in the process of migrating also transform these to the new-world standards.
As anyone who has ever done a migration of/to an ERP knows, the complexity lies with the interdependencies of the data. You can only get rid of your old materials or customers or vendors if there are no open items, orders or residual stock for these. Even though the parties that do this SDT have seemingly magical tools to transform data as part of the process, it still means that the business has got their work cut out to minimise these types of open ends – and determine what’s “necessary/sufficient” going forward.
Unfortunately there is no magic wand here – you’ve got to do this work eventually. And since we still encounter many organisations where the quality of data and the ownership is not really best in class, a heads up on getting ready to deal with it.
So the next question then becomes: which part of all of the work do you have to do yourself, and which part can you leave to partners – and under which conditions.
Who do you need on your quest? (and how many)
On this journey you are going to need some travel companions. Depending on your own capabilities, capacity and ambitions they may be somewhere between “guns for hire” or partners that really have your back and are in this with you. Either way, you need to be knowledgeable and smart about what you are going to be paying for – or end up paying for it in a different way.
Depending what you aim to achieve as described in part 1, the program breaks down in a few parts: (1) the data conversion/migration (always), (2) the SAP system changes and those of the landscape around it – (minimal if based on Simplification, to more extensive based on need/ambition) and the (3) process- and other business changes (hey, Fiori!) that you want or need to establish (again, minimal to extensive). And last but not least – tying it all together – overall integration (4).
Data migration (1)
When choosing the Selective Data Transition (SDT)-approach for the data migration/conversion, there are only a limited number of parties that have the capabilities and the “blessing” of SAP to do this. This blessing is important, as even though S/4 is a separate product to ECC and with that the functionality is different, you do want to have guarantees that your data integrity stays in tact if you’re only transferring part of it and doing some transformative magic to it as well. Thus, if you’re going “Goldfield” you are already reducing the numbers of potential sherpas for the data migration part of the journey to a handful.
As most of these team up with a set of System Integrators (SIs) to do other parts of the work involved, that narrows down the field quickly. That’s easy, one could think, but you do want to ensure you get what you need, and not what the SI wants to sell to you.
Systems changes (2)
Important note here, is that SAP Services is one of the parties that does the SDT, and also offers help on the other aspects of the move such as the system changes. It is important to note that compared to other SIs, SAP has one unique selling point that is immediately their limitation as well: they know SAP best… and only SAP. So if you have a system and process landscape with complex integrations to other (non-SAP) systems: you will need someone additional (could be yourself, of course) to act as the real systems integrator. Yes, S/4 is not entirely different to ECC and many interfaces are still the same, but if especially if you take the opportunity to make some structural changes to your (master data, process, org structure) setup, you kind of want to make sure nothing else keels over in the landscape.
Business changes (3)
And then there’s that part of the changes to the business (organisation) setup and processes. If you have a mature organisation, a good enterprise architecture capability and the mechanisms in place to facilitate the discussions on the decisions for the future, you are well equipped. Most organisations are not there. And for their normal day to day work that’s fine. But with this project, you need to have that capability and be able to rely on it. So either grow it or partner up with one or multiple dependable partners that have your back on this, taking the business support role and/or the essential role of enterprise architecture.
The business support role is often tied to “Organisational Change Management”. Another point to be cautious about, as many organizations don’t realise its importance to the success of a program. We once had a client that stated
“we don’t do change management here”
at the beginning of a transformation journey. At some point along the ride he did change his mind, but ideally you take it seriously from the onset.
The overall mold and glue (4)
Then all of this needs to come together with overall integration and orchestration. Especially when you have multiple parties taking pieces of the puzzle, you need to ensure that it all comes together in the same puzzle – no gaps, missing pieces or misalignments. In the end, you’re the one that ends up with the mess (of delayed or worst case: not going live, tremendous issues in hyper-care, or endless CRs and finger pointing and blame games between the parties).
Clear contracts are one side of the story (we could dedicate an article series to that alone), but a truly collaborative/partnership spirit and culture and executing on the governance is what keeps you from having to go back to the letter of the contract – with a lawyer.
Now that we’ve discussed the different parts of the team that you need to assemble, it may feel like a lot to consider. And that’s true, and essential. We do not mean to scare you off – just want to ensure you are well prepared. This will become the team you’re going to be having good and bad times with on the journey. Who keeps you safe, on track, keeps the pace, morale high, and makes sure that no-one and nothing gets left behind? This may rarely be one party (some of the big SIs will be able/want to offer all to you) as you really should find the best combination that fits your needs and situation, and keeps you sharp and honest. The crux is that – within whatever combination you end up with – you have the capability to consciously assess, decide and execute from the start and along the way.
Very simple tip (but too often neglected): checking whether on the crucial roles, you have people that actually have done a full life cycle (from start to handover to operations) on a similar project before.
Now that we’ve looked at some of the why, how, who, whereto, we’ll dive into some more specific “what”s and “when”s and other topics like architecture, end-to-end processes, business partners, to rise or not to rise in the next episode(s).
As always, we’re eager to hear from you and your S/4 stories or questions. Feel free to reach out to us with any comments, feedback or other queries. Or just to say hi.