Fit to Standard Almost Broke This SAP Transformation

Most SAP transformation stories follow a familiar pattern.

They start with fragmentation, complexity and legacy pain. They end with a clean, unified platform and a sense of completion.

Yamazen’s story is different because the difficult part is not the beginning or the end. It is what happens in the middle.

The Japanese industrial and consumer-goods supplier had built up three separate core system landscapes over more than 30 years. One for production equipment, one for building materials and one for home products.

Each system had evolved in response to real business needs. Each change made sense at the time. But over decades, the result became increasingly hard to manage. Even small adjustments could create side effects elsewhere. Interfaces multiplied. Data became inconsistent. And by the time information reached decision-makers, it was often already outdated.

This is a pattern many established companies will recognise immediately. Legacy systems are rarely the result of bad design. They are the result of continuous adaptation.

One urgent requirement after another.
One exception after another.
One workaround after another.

And over a long period of time, the system still works, but nobody fully understands how.

Yamazen decided to replace this landscape with SAP S/4HANA Cloud Private Edition. The Nextage programme started in 2018 and was structured in two major stages where the full integration was completed in January 2026

• The production-equipment business went live in August 2022 and

• The remaining building-materials and home-products systems followed

The result is a shared core platform covering finance, controlling, sales, procurement, inventory and project management across all three business areas.

On paper, this looks like a classic transformation success story.

In reality, the path there was far more complex.

In the first stage of the programme, Yamazen tried to avoid repeating its past.

The logic was straightforward: If decades of customisation had created complexity, then the new system should avoid it from the start. So the project adopted a strict Fit to Standard approach. Standard processes were preferred wherever possible. Extensions were tightly controlled. Every deviation required justification.

The intention was good. The effect was more difficult.

The approval body for extensions initially rejected a large number of requests. From a governance perspective, this was consistent. From a business perspective, it created concern. Business teams began to fear something important: that the new system might remove capabilities they relied on to serve customers.

At that point, the project started to shift. More requirements were accepted.
More extensions were introduced. The original design boundaries began to stretch. Eventually, the implementation had to be reconsidered.

This is not a rare situation in SAP programs. It is actually quite typical.

Fit to Standard looks simple in theory. Use SAP standard where possible, extend only where necessary, and keep the core clean. But the difficult question sits inside the word “necessary”. Because not every deviation is the same. And a number of Business processes does not fit into a standard SAP Process.

A process might differ from standard because it reflects a real market requirement. It might exist because customers expect a specific service level.
It might be driven by regulatory or product constraints. Or it might simply exist because “this is how we do our Business”.

And this is where the real challenge begins. A system cannot distinguish between these cases. A principle on a slide cannot either.

That judgement belongs to people.

It would be easy to say that Yamazen’s first approach was simply too strict. But the deeper issue is not about strictness. It is about where decisions were made. The project tried to resolve a business question through technical governance.

An extension board can evaluate cost, complexity, maintainability and upgrade impact. These are important factors. But they do not answer the core question: “Does this process actually create business value?”

And if so, where does that value come from? Without that clarity, governance tends to oscillate between two extremes. On one side, everything is treated as unnecessary customisation. The standard becomes the goal, and business users feel that their reality is being ignored.

On the other side, every existing process is defended as essential.
Nothing can be changed, because “this is how we operate our Business today”.

Both positions avoid the real work. The real work is harder. It requires a lot of asking uncomfortable questions:

• What do we actually want to preserve?

• What are we willing to change?

• Where does a deviation create real customer value?

• And where are we simply protecting familiarity?

These are not technical questions. They are organisational ones. And they cannot be delegated to SAP, to an implementation partner or to an architecture board.

Yamazen did not abandon Fit to Standard after the first difficulties. Instead, the company adjusted how it applied it. The target architecture became clearer.
Business units were more closely involved. And IT developed a much deeper understanding of both SAP capabilities and the underlying business processes.

This changed the quality of the conversation.

When a business team said, “We cannot change this process,” IT was no longer limited to accepting or rejecting the statement.

Instead, the team could:

• understand the process in detail

• question its purpose

• explore alternatives

• and explain trade-offs more clearly

In other words, the discussion became more analytical and less defensive and the IT become a real partner for the Business Teams.

The second stage still followed Fit to Standard. But the number of uncontrolled extensions stayed within a manageable range. The principle did not change.
The understanding around it did.

This is the key insight.

SAP transformation does not become stable through stricter rules alone.
It becomes stable when IT and business share enough understanding to make informed trade-offs together. That requires more than workshops or requirement sessions. It requires real ownership of the future process design on both sides.

Clean Core has become one of the central ideas in SAP modernisation. If used well, it helps organisations to reduce modification debt, simplify upgrades and adopt innovation faster.

Used poorly, it becomes something else entirely. A rule that is applied without context. The goal is not to minimise extensions at all costs.

A system can be technically “clean” and still fail in practice.
It can still produce workarounds, spreadsheets and shadow systems if the underlying processes are not well understood.

The real goal is something completely different. The Complexity of any System should be intentional, not accidental.

That means every extension should be understood in terms of:

• why it exists

• what value it creates

• who owns it

• and what it costs over time

Yamazen’s final architecture reflects this balance. Core processes such as finance, sales, procurement, inventory and project management sit in SAP.
Differentiating capabilities remain in surrounding systems where needed.

This is not about being strict or relaxed. It is about being deliberate. Because complexity itself is not the problem. Unexamined complexity is.

Yamazen’s next step makes this even more relevant. The company has built a Yamazen Data Platform (YDP), which combines real-time SAP data with information from other systems, including its sales platform. It also uses SAP Signavio to analyse processes, distinguish standard flows from exceptions, and improve data quality.

This is a direction many industrial companies are now taking from small to big Enterprises. Consolidate fragmented core systems, Improve data accessibility and Introduce AI to support or automate decisions.

At first glance, this looks like a technology evolution. But the real challenge is not technical. An AI agent does not clarify ambiguity. It executes it faster.

If a process is inconsistent across business units, the agent inherits that inconsistency. If exceptions are handled informally, the agent lacks the context to interpret them. If nobody can explain why a process deviates from standard, automation may either preserve a workaround—or remove something important.

This is why data quality is not only a technical topic. It is also a process design topic. Behind every data point sits a decision:

• Why was this order treated differently?

• Why did this approval take another route?

• Is this exception a competitive advantage or a broken process?

Process mining and analytics tools can make these patterns visible.
But they cannot decide what they mean. That interpretation still belongs to the organisation. And before AI agents can act reliably, companies need clarity on the facts of which processes are stable, which exceptions are valid and where human judgement must remain central.

This is why ERP transformation work is not just about systems. It is about making the logic of the business explicit.

Yamazen’s project does not offer a perfect blueprint.

It offers something more realistic: a transformation that learned. The first stage exposed a gap between architectural ambition and operational reality.
The second stage improved the way IT and business worked together to close that gap.

The result is not a system without extensions. It is a system where extensions are understood, justified and controlled. That difference is critical.

Because it determines whether S/4HANA becomes a true modernisation—or just a new version of the old landscape.

Clean Core is not a dogma. If every deviation is blocked, the business breaks.
If every request is accepted, the legacy simply continues in a new form.

The real work sits somewhere in between.

It requires understanding which processes truly differentiate the company and which ones only survived because nobody questioned them. Only then does the foundation become strong enough for the next step. Including AI.

Not just with clean data. But with a business that understands why it works the way it does.

Stay clever. Stay curious. Stay honest about complexity.

The Cloud Advisor,
Uwe Zabel

🚀 Curious how SAP modernisation can create a foundation for AI without rebuilding decades of legacy? Follow my journey here on The Cloud Advisor’s Book of Stories, where cloud, AI and enterprise worlds collide. Or ping me directly, because building the future works better as a team.