Executive Clarity · Mission: BETTER!

Every Transformation Begins Twice

Every transformation begins first in the boardroom, then in the project plan. Most organisations arrive at the second beginning without completing the first — and pay for it for years. With Gaby Schnug and Maximilian Müller.

Originally published on LinkedIn in Mission: BETTER! on 15 July 2026 — this is the canonical sapperment edition.

If you only have 60 seconds:

SAP’s vision for the Autonomous Enterprise exposes a question most organisations have been avoiding.

Not “which ERP should we run?”

But “what kind of company do we want to be in ten years — and does our transformation plan actually get us there?”

The organisations that succeed won’t necessarily migrate first. They’ll decide first.

That is what this article is about.

Every Transformation Begins Twice

Almost every project I have seen starts the same way.

Someone picks a Go-Live date.

Not because the architecture is ready. Not because the data is clean. Not because the organisation has agreed on what it is actually trying to become.

The budget cycle needed a number. The board presentation needed a milestone. The system integrator needed a delivery plan.

So the Go-Live date was fixed.

And from that moment on, something subtle happened.

The project quietly began making decisions on behalf of the business.

Every requirement was judged against the deadline. Every compromise became “good enough for now.” Every difficult conversation was deferred to a later phase that rarely came.

That is not a business transformation.

That is a countdown.

There is a sentence I have found myself repeating in almost every executive workshop over the past year.

Every transformation begins twice.

First in the boardroom, where the right questions either get asked or get avoided.

Then in the project plan, which faithfully executes whatever was — or wasn’t — decided above.

Most organisations arrive at the second beginning without ever having properly completed the first.

The system integrator arrives. Requirements workshops begin. Timelines are built. Resources are allocated. The programme develops momentum.

And only then — usually three or four months in, when reversing course has become genuinely expensive — does somebody ask the questions that should have opened the conversation:

Should this process even exist in its current form?

Why do we have 847 (a number I unpacked in a previous issue) custom developments — and who actually uses them?

What are we trying to become, and does this programme get us there?

By the time those questions surface, the answer to all of them has already been constrained by the decisions made before anyone thought to ask.

The Go-Live date is not a strategy.

It is a symptom — of a planning culture that mistakes movement for direction, and activity for architecture.

The organisations that get this right do something that sounds almost trivially simple.

They do the first transformation before they start the second one.

The Transformation Illusion

Here is something I have observed repeatedly, and it still surprises people when I say it out loud.

Two organisations can buy the same category of software, follow comparable methodologies, and still end up in completely different places three years later.

I saw both ends of that spectrum firsthand.

At a large bank in APJ, I watched a transformation executed extremely well. The groundwork was done before the project ever kicked off — the hard conversations about what to keep, what to retire, and what the bank was actually trying to become happened early, not as an afterthought during hypercare.

At an oil and gas company in Malaysia, I saw the opposite. Real difficulties — not because the technology failed, but because the organisation moved straight into implementation without ever properly answering those same questions. The programme had momentum. It didn’t have direction.

Same category of transformation. Completely different outcomes.

The difference had nothing to do with technology. It had everything to do with the conversations that happened — or didn’t happen — before implementation ever began.

Three years later, one organisation barely talks about its ERP anymore.

It has become infrastructure — reliable, boring, invisible in the way good infrastructure is supposed to be.

The other still talks about its ERP every Monday morning.

Because it never became invisible. It stayed a project long after it should have become a capability.

The difference wasn’t software.

The difference was transformation.

The Hidden Cost of the Project That Starts Too Early

Here is a pattern I have seen often enough to call it a rule.

The programme kicks off. The integrator arrives. The first workshop is scheduled before the first hard question has been asked. And somewhere in the project plan, under a workstream called “Change Management,” sits a budget line that everyone agrees is important and almost nobody treats that way.

That is where the cost accumulates.

Not in the licence. Not in the infrastructure. In the gap between what the system was built to do and what the organisation was prepared to become.

Most ERP programmes underinvest in two things simultaneously — and they are not unrelated.

The thinking that should happen before implementation begins. And the human work of getting an organisation to operate differently.

Both get compressed by the same force: a Go-Live date that was set before either question was properly answered.

A side note on OCM, because it deserves one.

Organisational Change Management isn’t a workstream.

It’s the distance between the system you implement — and the organisation that is ready to use it. The greater that distance, the lower the value your ERP will ever produce.

When that distance is large — because processes were redesigned without the people who own them, because the why was never explained clearly enough to survive the first difficult upgrade, because adoption was measured at go-live instead of six months after — no amount of hypercare closes it.

I put this to Gaby Schnug, who has spent her career inside exactly this problem. Her answer cut straight through the framing most programmes still use.

“One of the biggest misconceptions I see is that organisations believe Change Management starts after the solution has been designed. In reality, it starts the moment leaders decide how they want the organisation to work.”

That single distinction — before the design versus after it — is the difference between OCM as insurance and OCM as architecture.

Here is where most programmes get it wrong. They hire for the fluffy part — the town halls, the newsletters, the stakeholder maps, the training decks nobody reads twice. It looks like progress. It produces almost nothing.

There is Change Management. And there is the Management of Change.

Change Management documents the transition. The Management of Change actually moves people through it — makes the hard calls on sequencing, sits with the sponsor who is quietly resisting, decides which battles to fight this month and which to let go. One is a plan. The other is a practice.

You don’t want someone who can run the workshops. You want someone who can manage the change itself — who treats resistance as information, not an obstacle to route around, and who is willing to be unpopular in month three so the organisation actually adopts the system in month nine.

The programmes that get OCM right treat it as a design constraint, not a delivery activity. They ask, from the very beginning: what has to be true about how this organisation works for this architecture to deliver its promised value?

That question belongs in the first conversation. Not the last one.

The hidden cost of starting too early is not the rework. It is the distance you carry forward — and that distance does not disappear at go-live. It compounds.

The Layers of Transformation

I often draw transformation as a pyramid — business strategy at the base, then organisation and governance, then process and data, then the ERP core, with Business AI at the top. (The pyramid diagram appears in the original LinkedIn edition.)

Most organisations start somewhere in the middle.

Successful ones start at the bottom.

The logic is simple. AI without trusted processes automates inconsistency. Data without governance creates noise. ERP without business strategy produces expensive infrastructure. Every layer depends on the integrity of the one beneath it.

One of the most common questions in SAP transformation is whether organisations should begin with Public Cloud or Private Cloud.

The right question is whether the organisation is ready to change the way it operates. Because Cloud ERP does not transform a company. Leadership does. Architecture does. The right decisions, made before the first requirements workshop, do.

Technology enables all of it.

It causes none of it.

Before approving the next ERP programme, four questions deserve honest answers in the boardroom — not the project plan.

1. Which capabilities genuinely differentiate us, and which complexity have we simply never had the courage to retire?

Not every process deserves to survive transformation. The ones that do should be protected deliberately, not by default.

2. Where should future innovation live — inside the ERP core, on BTP, or somewhere else entirely?

This question determines Clean Core strategy more directly than any vendor guideline. Answer it before the architecture conversation begins, not during it.

I put this to Maximilian Müller, who runs SAP Business Technology Platform at AKQUINET and watches organisations make this mistake from the inside. His answer was blunt:

“One of the biggest architectural mistakes I see is using the ERP core as the default place for innovation. Every new requirement ends up becoming another customization simply because the ERP already exists.”

His fix is a discipline, not a workaround: the ERP stays stable, and innovation moves to the platform. BTP lets organisations build faster without eroding the Clean Core they just fought to establish.

“That’s why the question isn’t ‘Can we build it?’ It’s ‘Where should it belong?’”

3. Are we redesigning the business, or replacing the software?

Both are legitimate programmes. They are not the same programme. Confusing them is where the majority of transformation cost originates.

4. Does our target operating model actually support an AI-first future — or does it assume that AI is something we will add later?

Later is not a strategy. The foundation for Business AI is built during the ERP transformation, or it is built again afterwards at significant cost.

If those questions are answered first, implementation becomes significantly more predictable.

If they are answered afterwards, it becomes significantly more expensive.

Transformation is not measured on go-live weekend.

It is measured three years later — when the next acquisition arrives, when the next regulation lands, when the next AI capability becomes available and some organisations can deploy it in weeks while others schedule a programme to evaluate it.

The winners of the next decade will not be the companies that migrated fastest.

They will be the companies that built an operating model capable of changing continuously.

Because in the era of SAP Business AI and the Autonomous Enterprise, transformation is no longer something you do.

It is something you become.

And organisations don’t become different because they bought different software.

They become different because they learned to make different decisions.

Monday Morning

If you’re a CIO, CFO or Transformation Sponsor, ask your team these four questions this week:

  • Have we defined our future operating model before selecting our future ERP?
  • Can we explain why every major customization still exists?
  • Is Business AI part of today’s architecture — or tomorrow’s wishlist?
  • Are we measuring success by Go-Live, or by business capability three years afterwards?

Expert contributors

Gaby Schnug is an Organizational Change & Transformation Leader specialising in SAP S/4HANA transformation, governance, leadership enablement, and organisational adoption. She helps organisations embed change as a strategic capability rather than treating it as a project workstream, ensuring that technology investments translate into measurable business outcomes through leadership, accountability, and sustainable adoption.

Maximilian Müller is Head of SAP Business Technology Platform at AKQUINET. His view on where transformation programs go wrong is direct: the ERP stays stable; innovation moves to the platform. SAP BTP lets organizations build faster without eroding the Clean Core they just fought to establish. As he puts it, the real architectural question was never “Can we build it?” — it’s “Where should it belong?”

Andreas BORN advises executives on the future of enterprise transformation at the intersection of SAP Cloud ERP, Business AI, Data and the SAP partner ecosystem. With more than 25 years of global SAP experience across customers, consulting and SAP itself, he helps organizations navigate the journey from today’s ECC landscapes to tomorrow’s Autonomous Enterprise.

Together

This publication deliberately brings together three perspectives that are too often treated independently.

  • Business Strategy & Enterprise Architecture — ensuring technology decisions are driven by long-term business outcomes.
  • Organisational Change & Leadership — ensuring people, governance and adoption evolve alongside technology.
  • Platform Innovation & Clean Core — ensuring innovation happens where it creates value without increasing technical debt.

Only when these three disciplines work together can organisations fully realise SAP’s vision of the Autonomous Enterprise.

Because successful transformation is never just about implementing a new ERP system. It is about aligning strategy, architecture, people and platforms to build the operating model of the future.