The migration from SAP ECC to S/4 is a journey that many companies are or will be undertaking. While for some that journey is a breeze, most run into roadblocks or hurdles along the way. In this series of articles we shed some light on what to consider and how to set up for a ride.

In our 2 previous blogs we discussed elements like the case(s) for moving to S4, the different migration approaches and the team/capabilities you need on board for the journey. Now let’s dive into a bit more on the content of what needs to be done, starting with enterprise architecture.

Architecture – not just tech

In this migration it may be tempting to simplify it to exchanging the ECC system with S/4. Indeed, when you draw your “before” and “after” application landscape on a high level that is the most striking change: the box in the middle will have a new name. But as we started with the “why” of the migration, there are some goals associated with it, and that usually means that all 6 layers of enterprise architecture that we distinguish need at least a little consideration: KPI, organisation, process, data, applications and infrastructure.

Why did we start this and what does that mean?

As mentioned earlier, we’re doing this project for a solid reason. Yes we all know some people, who just love techie stuff, running workshops or doing project management, for its own sake. But we expect (and urge you!) that’s not why you are getting into this migration: there needs to be real added value, preferably measurable.

Translating the set objectives into concrete KPIs starts by clarifying what that P for “performance” means and what good looks like.

We often see organisations struggling with setting – and following –  the right KPIs on every level. It feels like these organisations are not aware that the migration could (should?) be changing more than only the outcome of the known KPIs. The migration offers the opportunity to transform the existing KPI-model into a new more forward-looking sustainable model. Questions like:

Are we getting better business results out of the new setup and how do we ensure that? Do the type of business results change as part of the transformation? When we reach what we envision with this project, how do we define this success? Since we’re doing this for the next umpteen years: how do we include targets on new (and lasting) business topics, such as ESG, further digitisation or creating an agile organisation?

These are all elements of the KPI architecture that we need to have in place to understand and agree on what good looks like and how we can make solid decisions within the project, but more importantly in the business after we’re done.

Evidently, also for the project itself there need to be KPIs, and not just on the project manager’s scope (on time, in budget), but also on the solutioning itself. How well do we ”fit to standard” and do we have solid rules (architectural principles) on when we don’t. Do we measure and keep track of the deviations, what “score” on our compliance performance there do we find acceptable?  And of course all of the more techie KPIs: availability, latency, response times – both on the systems and the organisation around IT.

If you don’t know what you’re aiming for, it makes it hard to reach.

The box in the centre

The fact that ECC (S/4) is for many organizations the box in the middle, means it is the heart of the system landscape. If you replace that, it is wise to give it great focus and attention. But the heart needs to stay connected to the rest of the body. Each application in the application architecture serves a specific function to the organisation. Although a lot of interfaces with these other applications do not change in its structure or frequency, you do need to be cautious about where you make changes to data structure or content as part of the migration.

E.g. adaptations to your chart of accounts or organisational setup that you chose to combine with the migration (as discussed in the previous article). The choice then needs to be made to reflect those same changes in the rest of the landscape (simultaneously) or put mappings in place. The latter is an easy decoupling mechanism, but you probably also don’t want to keep references to outdated structures in place until the end of times…

A balancing act between: “what do I change as part of the migration” and “what will I keep on my to do list (debt) for manageability’s sake”. Good architecture work will at the very least make the trade-offs visible and keep the organisation reminded on the “to dos”.

The topic of the data exchange brings us to a next element in the enterprise architecture: processes, as that exchange generally happens to make something happen.

End-to-end is a joy forever

Ah, the bliss of good, accessible documentation on how everything flows… and the project of migrating to S/4 is often a moment where you realise that that is not in place.

The most granular picture available is often a domain view or other functional decomposition of what part of the business is supported by what and how. And while certainly not every organisation needs the level of documentation that the manual of a space ship has, a good understanding of what processes will be impacted by the move to S/4 serves more than most people think.

Thinking in end-to-end (E2E) processes and setting this up in a model brings several benefits. For one it gives insights into hand-overs: interfaces yes, but also between departments. Those are the areas that you want to make sure to cover when managing project dependencies, integration and user acceptance testing. Playing out scenarios over the end-to-end processes also helps understanding impacts and risks and allows for taking contingency measures.

Secondly, End-to-end helps in preventing sub-optimisation – driving effectiveness and efficiency across the organisation instead of in one function or process. Especially when there are more transformative changes as part of the program, there is often a benefit in one area, with some more effort in another. Seeing the whole picture of the chain, and the overall KPIs, then helps people understand their contribution and generates buy in. We can’t overstate the importance of taking along the user community (even those outside your own organisation) for success.

What about the people?

This also ties into another element of the enterprise architecture: organisation. Having clear who does what, why and where there may be cracks that things fall into or conflicts of interest due to misaligned KPIs. Also where is a second pair of eyes required (and an extra process step) to drive compliance. Tying “organisation” into the E2E process architecture and approach, ensures consistency and completeness: getting this clear benefits you in all of those topics that involve the “people” later on: training, OCM, authorizations, testing…

Getting started on E2E process modelling may seem like a daunting task (we get that feedback a lot). It really does not have to be, especially when you don’t try to reinvent the wheel, but leverage what is already out there and focus on understanding and making the mindset your own. The difficulty then usually lies in “where is it justified that I don’t follow the standard process” – and that comes back to the “stick to standard” and differentiate only where it add true value that we have discussed before.

Regarding tooling for process modelling: since we are talking about SAP here, a natural choice may be Signavio as it often comes with the package. Again, think about how it fits the rest of your setup, be smart but don’t overengineer your choices. Understand what the tools can do, and relate this to your ambitions and capabilities. Next step, and does require that you’ve set it up right, is to leverage the tools to also measure your process compliance and performance and drive optimisation.

What lies beneath

Okay, so infrastructure is the obvious next one, and we’re taking a bit of a broad definition here, as there’s always the grey area between the tech and functional, hard- and software.

The foundation to S/4 is the HANA database and platform, which often means new skills in the technical (architecture) domain. This of course also depends on your hosting strategy, and SAP likes to push for “Rise”. We all know that “cloud” still is a datacentre, just one that you, on the receiving end, don’t know the individual servers in. Since the ERP is generally not the only system in your environment, it means that you still need the wizzes that understand how A talks to B what needs to happen to make that work securely, robustly and consistently. And what to do when it is not…

Another part of infrastructure are the user end-points. In S/4 most “SAPGui transactions” have been replaced by Fiori apps, and many of these have been designed to go mobile. Super of course to be able to check things on the go, or on a portable device in an operational setting, but it means a lot for things like security, connectivity (and replication).

And then we have not even spoken about the infrastructure demands during the project itself: how do I enable my environments, when do they need to be available and when frozen. Especially when going goldfield instead of greenfield the dependencies with “regular changes” need to be managed. The project will run for some time, how will I deal with service packs, do I have a n-1 policy on the versions and how do I sustain that during the project.

Concluding

Where the project manager concerns itself with project process, timelines, budget and resources – and that is what is generally brought forward to the steerco, we advocate for a strong architecture steer on the content of the project – in alignment with the bigger picture of the enterprise.  Who “owns” the end result (and what is it)?

Ensuring that you have got all 6 layers addressed properly. This does not mean that you have to bulk up on people in your project (separate topic: please don’t). The competencies and capabilities to make sure that the whole thing actually works together should be in place – and that this should also have a seat at the table where the decisions are made. Make sure you have your equivalent of a design authority that controls the project from a content perspective.

And yes, a lot of the architecture work should be done at the start of the project. However, making sure that the execution is done accordingly and/or making well-informed changes when things turn out differently is equally important. No leaning back for architects, roll up those sleeves!

What’s next

So much more to share! So we will.

Please also feel free to ask your questions or share things you’re running into, we’re happy to go into “requests” as well! Either in a next article or over a cup of coffee/tea…

Reach out to us, even just to say hi.