SAP transformation has no shortage of information. There are product announcements, implementation methods, migration deadlines, reference architectures and partner presentations.
What is often missing is clarity.
Clarity about what the organisation is trying to become. Which capabilities genuinely differentiate it. Which complexity still creates value. Where innovation should live. Who owns adoption after go-live. And how technology decisions connect to economics, governance and business outcomes.
That is the gap Executive Clarity is built to close.
SAP transformation does not have an information problem
It has a translation problem.
Boards discuss growth, resilience, efficiency, customer experience and AI. Programmes discuss scope, workstreams, integrations, testing and go-live.
Both conversations are necessary. Too often they are not the same conversation.
The original ambition remains visible in the steering deck, but it stops governing daily decisions. Architecture follows inherited complexity. The roadmap follows a deadline. Partners follow their incentives. Go-live becomes the measure of success because nobody agreed on a better one.
This is how a transformation can deliver its software and still miss its purpose.
The hardest move is not from ECC to S/4HANA. It is from why the business needs to change to how the organisation will build, adopt and continuously improve its future operating model.
Why now
For years, deadlines did much of the decision-making.
The dates were familiar: mainstream maintenance through 2027, optional extended maintenance through 2030, and SAP's innovation commitment for S/4HANA through 2040. These facts created momentum. They did not create direction.
On 9 July 2026, the European Commission made SAP's commitments concerning maintenance and support for on-premises ERP legally binding. The legal details matter. The strategic consequence matters more: customers gained more room to make architecture decisions under deliberate governance rather than contractual pressure.
That did not make cloud less relevant. SAP's direction at Sapphire 2026 became more ambitious, not less. The Autonomous Enterprise depends on governed business processes, trusted data and AI — with SAP Business AI Platform bringing together BTP, Business Data Cloud and Business AI.
The destination expanded at the same moment the journey became more open.
That creates choice. It also creates responsibility. When a deadline stops making the decision for you, leadership has to make it instead.
WHY is not enough
Most transformation programmes can explain why they exist: reduce technical debt; standardise processes; lower operating cost; improve data quality; accelerate innovation; become ready for Business AI.
These are sensible ambitions. They are not yet decisions.
A useful WHY changes what the organisation will do. It determines what will be protected, what will be retired, where the company will standardise and where it will continue to differentiate.
- If the ambition is standardisation, local exceptions need an economic burden of proof.
- If the ambition is speed, decision rights cannot remain distributed across twenty committees.
- If the ambition is AI readiness, data ownership and process governance cannot be postponed until after ERP go-live.
- If the ambition is continuous innovation, the ERP core cannot remain the default home for every new requirement.
The WHY becomes real only when it changes the HOW.
HOW is not a project plan
A migration factory is not a strategy. A target architecture without decision rights is not an operating model. A backlog without a traceable business outcome is simply a list of work.
Every transformation begins twice: first in the boardroom and then in the project plan.
The problem is not that organisations skip the first discussion completely. The problem is that its logic rarely survives translation into delivery. The board approves an ambition. The programme receives a scope. Architecture receives requirements. Partners receive work packages. Teams start producing.
Somewhere between those handovers, the transformation begins to drift.
What is missing is a decision architecture that remains visible from the first board conversation to the final backlog item.
WHY → DECIDE → DESIGN → DELIVER → EVOLVE
- 01 WHY
Define the business you are trying to become.
- 02 DECIDE
Make the trade-offs explicit.
- 03 DESIGN
Connect architecture and operating model.
- 04 DELIVER
Sequence value, not activity.
- 05 EVOLVE
Measure transformation after go-live.
WHY — define the business you are trying to become
Begin with the future operating model, not the deployment model.
What should customers, employees and partners experience differently? Which capabilities should become faster, cheaper or more resilient? Where does the company genuinely earn its margin? What must it be able to change in weeks rather than years?
Without that destination, Public Cloud, Private Cloud, RISE, GROW, Clean Core and BTP become labels searching for a problem.
DECIDE — make the trade-offs explicit
In one landscape review, a mature SAP system contained 847 custom developments. The useful question was not how many could technically be converted. It was: What business advantage disappears if we remove this?
That question turns architecture into economics. Every material process, extension, interface and report should be classified:
Public Cloud is attractive where standardisation is a strategic advantage. Private Cloud is justified where controlled flexibility protects genuine business value. Hybrid and Two-Tier ERP are valid where sequencing, geography or business-model differences matter more than architectural purity.
The recommendation must be conditional, not ideological.
DESIGN — connect architecture and operating model
Architecture is not only a diagram of systems. It is a distribution of responsibility.
Who owns process standards? Who can approve an exception? Who governs business data? Where may teams extend the solution? Who carries the cost when temporary complexity becomes permanent?
The technical model and the management model must agree.
A stable ERP core with uncontrolled decision rights will not remain clean. A modern data platform without business ownership will not create trusted data. An AI layer connected to inconsistent processes will automate inconsistency faster.
The ecosystem is part of that design. A connector, alliance announcement or reference architecture does not answer who owns adoption, who is rewarded, who supports the solution and who turns initial implementation into sustained value.
Integration is not an operating model.
DELIVER — sequence value, not activity
A mature roadmap does not merely say “migrate.” It explains what becomes possible, in what order, and how the organisation will know.
- Visibility — establish what is actually used, connected, owned and paid for.
- Classification — keep, retire, relocate or redesign inherited complexity.
- Architecture — choose the deployment and platform model based on evidence.
- Platform — establish integration, extension, data and governance capabilities early.
- Roadmap — move the right domains in the right order and connect every release to business value.
This is not a waterfall argument. It is a decision-order argument. Iteration is healthy. Reversing dependencies is expensive.
EVOLVE — measure transformation after go-live
Go-live proves that the programme delivered software. It does not prove that the organisation became better.
The real test comes later: Can a newly acquired business be integrated faster? Can a regulatory change be absorbed without opening another major programme? Can a new AI capability use trusted process and data context? Can the business launch a new model without rebuilding the ERP core? Can leaders see whether the expected value was realised?
Transformation is not a temporary activity performed every ten years. It is an organisational capability.
What Executive Clarity will cover
Public or Private Cloud, RISE or GROW, Two-Tier ERP and selective retention — assessed through business fit, economics and operating-model readiness rather than slogans.
Licences, subscriptions, infrastructure, implementation, integration, change, operations, risk and value realisation.
Not “no customisation,” but disciplined differentiation: what belongs in the core, on BTP, or nowhere at all.
How trusted process context, governed data and platform choices determine whether AI creates business capability.
Decision rights, sponsorship, process ownership, partner incentives, change and the capability to keep evolving.
How we will work
Executive Clarity will keep three things separate:
Supported by primary or clearly identified sources.
What the available evidence reasonably suggests.
My judgment, shaped by more than 25 years across SAP customers, consulting, SAP itself and five continents.
Recommendations will be conditional rather than ideological. Vendor claims will be treated as inputs, not conclusions. Expert perspectives will be brought in where they strengthen the decision — not added as decoration.
Every article should leave a CIO, CFO or transformation sponsor with something usable on Monday morning.
Three articles. One connected case.
Why you now have a choice.
Why the decision has to come before the plan.
Why the ecosystem may decide for you if you do not.
Together they establish the starting position: You have more choice. Choice requires better decisions. Better decisions need an operating model capable of turning intent into execution.
That is the movement from WHY to HOW.
Five questions for the leadership team
- What company are we trying to become — not what ERP are we trying to install?
- Which three capability decisions have materially changed our scope or architecture?
- Can every major custom development be classified as keep, retire, relocate or redesign?
- Who owns value and adoption after the implementation partner leaves?
- Which business capability will prove, three years after go-live, that the transformation worked?
If the answers are clear, the programme is moving from WHY to HOW.
If they are not, it is simply moving.
The protagonist is the organisation making the decision.
This is not SAP as the protagonist. It is the executives accountable for what that decision makes possible.
Cut through the noise.
Understand the decisions.
Build what lasts.
Not WHY instead of HOW. Not strategy instead of execution.
WHY governing HOW — from the boardroom to the backlog, and from go-live to measurable value.