Our 2026 Convictions, Revisited

In January we published three convictions for 2026 in ERP transformation. Bold claims are easy to publish in January and easy to forget by December. We would rather be measured on them.

So this is the mid-year score. One conviction is holding, and moving faster than we expected. One is holding for a reason we did not anticipate. And one, the one I personally pushed hardest internally, as directionally right with the wrong unit of measurement. I have changed my mind on the mechanism.

A note on method: the January piece argued that the market would stop paying for presence and start paying for evidence. It then presented its case without much evidence of its own. Fair criticism, and I’ll fix it here. Everything below that can be sourced, is sourced.

The scorecard

Conviction 1: Outcome-based pricing, holding, and accelerating

We said ERP transformation pricing would shift from time-and-materials toward outcomes. I believe this more strongly now than I did in January.

The demand side is what convinced me. Enterprises are not willing to pay the day rates they paid five to ten years ago. That is the whole story in one sentence. It is not a philosophical shift toward “value pricing” — it is a budget reality that CFOs have already priced in, and every partner in the ecosystem is feeling it.

If your day rate is under pressure and your margin depends on it, you have three moves.

Move it nearshore or offshore. The most common response, and the weakest one on its own. It relocates cost, it does not change throughput per person. You still need the same number of hours to reconstruct context that was lost between Explore and Realize. And in SAP work specifically, the coordination overhead of a distributed model often eats a meaningful share of the rate arbitrage.

Deliver with fewer people. Correct instinct, but it only works if output per person goes up. Otherwise it is just a slower project sold as a leaner one. Smaller teams without better tooling is a promise you cannot keep past the second sprint.

Use the right platforms. This is the only one of the three that changes the underlying unit economics rather than redistributing them. It is also the one the ecosystem is least equipped for.

The build-or-buy question nobody wants to answer

Here is what I see across the SAP partner ecosystem right now: a lot of internal builds. Accelerators, GPT wrappers, internal document generators, prompt libraries dressed up as platforms.

I understand the impulse. Software margin looks attractive when service margin is compressing, and every partner has an architect who can prototype something in a quarter.

But I would be careful. Building an internal accelerator and building software are different businesses. Software means a security review from every enterprise client, a roadmap that survives SAP’s release cadence, an ISV-grade support model, and a maintenance cost that never goes to zero. Most partners do not have that capability in-house, and the honest ones will tell you the prototype was fun and the second year was not.

So the question for a partner CEO in 2026 is not can we build this. It is: is a self-built tool the thing that will differentiate us, or is delivery capability the thing that will differentiate us? For most, it is the second. That is the opportunity and it is why I think the partner ecosystem is a market, not a competitor.

One more thing, because the January piece did not say it clearly enough: outcome-based pricing is not an anti-consultancy argument. Outcome pricing rewards whoever has the highest throughput at a defensible quality level. If you have that, your margin goes up, not down. It only punishes the firms whose model depends on the meter running.

Where I could still be wrong: attribution. If adoption fails because the client’s change management was weak, who carries that? Nobody has solved this cleanly, and it is the single biggest reason outcome pricing has been predicted for twenty years without fully arriving. What is different now is that the tooling to evidence who delivered what finally exists. That is necessary. I am not yet certain it is sufficient.

Conviction 3: Governance — holding, for a reason I did not anticipate

In January we argued AI would only be allowed into ERP delivery under enterprise-grade control: data boundaries, least privilege, audit logs, versioning, deterministic outputs.

All still true. All now table stakes. Any serious vendor clears that bar, so it no longer explains why enterprises are hesitating.

The actual blocker in 2026 is financial predictability.

SAP moved AI to consumption-based pricing. Christian Klein put it plainly in March: *“It would be foolish to still charge subscription base, because AI is so powerful that it will automate a lot of tasks.”*¹ From July 2026, use-based AI pricing became the default framework for cloud renewals.² Directionally, I think SAP is right. But look at what it does to a CIO’s budget.

Under AI Units, a large share of consumption is triggered by background processes rather than explicit user actions, and agentic workflows consume dramatically more than interactive ones — a high-volume agentic approval process can burn through more units in a week than a query-based deployment does in a month.² Overages invoice outside the normal billing cycle. And enterprises have essentially no institutional experience forecasting this kind of spend.

That is the conversation I am actually having with customers. Not “is it secure.” It is: what will this cost me next quarter, and what did the last quarter buy me?

So I would restate the conviction. Governance in 2026 is not only a control problem. It is a forecasting problem. A governance model that cannot answer the cost question is incomplete, however good its audit log is.

Two consequences follow.

First, SAP is right to be careful, and I say that as someone whose company would benefit commercially from them moving faster. Agents acting on live enterprise data — real master data, real financial postings — is a genuinely hard problem, and the reputational cost of getting it wrong at SAP’s scale is asymmetric. Caution here is not conservatism. It is correct sequencing.

Second, this is why so many enterprises are still in pilot. It is not that they doubt the effect. Most leaders I speak to are convinced AI will change ERP delivery substantially. They cannot yet write the business case, because they cannot bound the cost or attribute the value. Until you can forecast the spend, you cannot approve it — and so the pilot never becomes a programme.

The vendors that win the next twelve months will be the ones that make consumption legible: what was spent, on which artifact, for which decision, and what it replaced.

Conviction 2: Deliverables-first — where I have changed my mind

This is the one I would rewrite.

In January we claimed that by end of 2026, high-performing programmes would treat workshops as a last resort, run fewer meetings and produce more deliverables per week. The instinct was right: discovery is where ERP programmes lose time, and manual synthesis is genuinely wasteful.

But the unit was wrong.

The bottleneck in Explore is not producing the artifact. It is confirmation, validating that a documented requirement actually reflects business intent, and getting the people who own the process to stand behind it. That part is complex, political, and does not compress just because you generated the document faster. If you optimise only for artifact volume, you produce more documents that still need the same painful validation, and you have moved the queue rather than shortened it.

I also underrated something structural. Producing more deliverables is worth very little if they land in disconnected places. And the SAP landscape is exactly that problem: business intent lives in workshops and transcripts; architecture lives in SAP LeanIX; process lives in SAP Signavio; requirements, backlog and test cases live in SAP Cloud ALM. SAP has been building an Integrated Tool Chain across those three with a unified meta model, and that direction is right.³ But standing them up is not the same as connecting the reasoning that runs through them.

What I believe now

The unit of progress is not the deliverable. It is the connected, traceable decision.

Business intent has to be captured with its real complexity, translated into the tools that already exist in the SAP toolchain, enriched with actual business capability context, and then carry traceability across every stage, so that six months later, anyone can ask why was this decision made, on what input, by whom and get an answer in seconds rather than a forensic exercise.

That is the layer that is missing today. The individual tools are strong and increasingly stand-alone. The connective tissue — intent in, traceable decisions across, evidence out — is where the value sits, and it is not something any single one of those tools will own by itself.

There is an ownership shift underneath this too. Traceability of that kind has historically lived with the SI, in their methodology, their templates, their people. Enterprises increasingly want to own it. They want the decision history in their own system, visible to them, surviving the end of the engagement and the rotation of the delivery team. I do not think that is a rejection of consulting. It is a rejection of context leaving the building when the contract ends.

Put those together and the economics change in a specific way: the software-to-implementation spend ratio. Today a disproportionate share of transformation budget goes to human effort assembling, reconciling and re-explaining information that a connected system should carry. Shift part of that spend into software that holds the intent, the connections and the traceability and keep expert humans on the judgment calls where they are genuinely irreplaceable and you get more transformation per euro. Not by removing the experts. By stopping the waste of putting them on reconstruction work.

That is the bet we are making. The traditional SAP consulting model, priced by presence, with the connective tissue held in people’s heads is the part that is broken. Qorelo is built to replace that specific part, natively against the SAP toolchain rather than beside it.

What I would tell an ERP leader for the rest of 2026

Renegotiate on throughput, not on rate. Pushing day rates down without changing how work is produced just buys you a more junior team. Ask your partner what their output per person per week is and how they evidence it.

Make AI consumption forecastable before you scale it. Name an owner. Report consumption monthly by use case. Separate committed spend from overage exposure. If you renew after July 2026 without this, you are accepting an unbounded line item.²

Ask where your decision history lives. If the answer is “in the partner’s methodology,” you do not own your transformation. You are renting it.

Stop buying tools that do not connect. A stand-alone tool that produces beautiful artifacts into a silo adds a reconciliation task. Buy for the seams.

Closing

Two of our three January convictions are holding. One of them is holding for a reason we did not see coming, governance turned out to be about forecasting, not just control. And on the third, I had the right diagnosis and the wrong prescription: the problem in Explore is not artifact volume, it is connected, traceable decisions across a toolchain that does not yet talk to itself.

We will publish the full-year score in January, including whatever we get wrong between now and then.