The requirement everyone agreed on

If you have ever wondered whether decisions made at the beginning of a project really matter, this story shows how much impact they can have on a customer’s SAP landscape for years to come.

It is about a requirement everyone agreed on because it sounded simple. The problem was that nobody checked how much complexity was hiding behind it.

The situation

Let’s assume that we have an SAP S/4HANA implementation.

There are several possible implementation approaches. You will commonly hear terms such as greenfield, brownfield and selective data transition—sometimes also called bluefield.

In a greenfield implementation, we design the processes largely from the beginning instead of taking everything that already exists. This approach is also common for customers that did not previously use an SAP system.

A brownfield implementation is closer to a conversion. We take an existing SAP ERP system and convert it to SAP S/4HANA while keeping much of the existing configuration, processes and data.

A selective data transition is similar in some ways to a brownfield implementation, but we selectively transfer only the processes, data and solutions that we want to keep in SAP S/4HANA.

Each of these approaches can work. The problem starts when a lift and shift is understood as: “Let’s move everything first and think about it later.”

What happened

Currently, there are also many projects described as finance transformations.

In this type of project, the existing ERP systems can remain responsible for most of the operational processing. They are connected to SAP S/4HANA through integrations and transfer the required financial data. SAP S/4HANA can then be used mainly for financial posting and reporting.

This is an interesting approach because the implementation can be completed faster. You do not necessarily have to analyse and redesign every process in every connected system. You take the required output, transfer it to SAP S/4HANA and post it there.

At least, this is the assumption.

Because everyone was focused on the integration, some basic functionalities were overlooked. These included forms, validations, billing logic, calculations and other rules that existed in the previous system.

The assumption was that all required logic had already been applied and that only the final data would be transferred.

Unfortunately, the final data was not as final as everyone thought.

Instead of properly analysing which parts of the existing logic were still required, a very large amount of custom ABAP code was carried forward.

And when I say “a very large amount,” I mean enough custom code to make a simple change not so simple anymore.

The project performed a lift and shift, but it also lifted the existing maintenance problem and shifted it into the new landscape.

Why it happened

Not every organisation starting an SAP project already has an experienced internal SAP team.

Sometimes the team has only recently been created. Important people may not yet be available at the beginning of the project, but the project still needs to start because management has already approved the timeline.

The people involved do what they can, but without the right experience it can be difficult to identify all the long-term risks.

As a result, an organisation may agree to the solution proposed by the consulting company without asking enough questions about its future impact.

The solution itself might work. The main issue appears later, during maintenance.

Imagine that you want to make a small adjustment to a form or change something in the billing logic. Before doing that, someone needs to understand a very large amount of custom ABAP code and determine which parts are still relevant.

A change that initially sounds small can therefore require much more analysis than expected.

The project might save time during the implementation, but the work does not disappear. Part of it is simply moved to the support and maintenance phase.

The lesson

This lesson is mainly for project managers, business owners, solution architects and programme directors.

When considering a lift-and-shift solution, try to have at least one person who understands its potential long-term impact.

Do not ask only whether the solution can be delivered. Also ask whether it can be maintained.

Before agreeing to this type of solution, it is worth checking:

• Which business rules are hidden inside the existing custom code?
• Which parts of the current solution are still required?
• Which parts are being transferred only because nobody has analysed them?
• Who will maintain the solution after go-live?
• What will happen when the business requests a change?
• Are we saving time, or are we only moving the work to a later stage?

Consultants should also consider these questions when proposing such solutions.

The approach with the least resistance during implementation might later become the approach with the highest maintenance effort.

Sometimes a requirement sounds simple only because nobody has checked what is hiding behind it.