Even the best-executed change cannot deliver value if it addresses the wrong business priority. Here's why the design stage has become the highest-leverage decision in the SAP change lifecycle — and why getting it right separates change that creates value from change that just gets shipped.
When I joined Basis Technologies, I spent my first weeks doing what anyone joining a new company does: having a lot of conversations and trying to understand where the real opportunity sat. There was one observation that came up again and again: the people responsible for SAP change management had, for years, been focused almost entirely on change execution; on doing change right. Delivering it safely, controlling the risk, and getting it into production without breaking anything.
That focus made complete sense for the world it was built in, and the discipline it produced was real and valuable. Today, however, the question is no longer just how to deliver change effectively, but how to ensure the changes entering the pipeline are the ones most likely to deliver value for the business.
A significant share of enterprise value is now determined before delivery even begins. Teams have largely solved for delivering change well; the opportunity being left on the table sits in an earlier stage, in change design. In deciding what to build in the first place (and whether it is worth building at all). Not doing change right, but doing the right change.
That distinction sounds small. It isn’t. You can have a fast, efficient, well-run change function and still destroy value, if you’re pointing it at the wrong changes. Doing change right is necessary. Designing the right change is what determines the return, and ultimately the economic value captured by the SAP change function.
The Most Overlooked Decision in SAP Change
Every SAP change goes through a design stage. It’s where a business need becomes a defined change — requirements captured, options considered, feasibility assessed, effort estimated — before a single transport moves.
Yet in most organizations, this stage is almost invisible: it has no budget line, it rarely has its own metrics, and it’s often treated as administrative paperwork before the real work of delivery begins. That framing can be an expensive mistake. By the time a change reaches delivery, most of its economic fate (cost, timeline, value) has already been decided.
From “Can We Build It?” to “Should We Build It?”
For most of the last two decades, change design was a technical exercise. A business stakeholder raised a requirement, then a consultant translated it into system terms, judged feasibility, estimated effort, and placed it in the backlog. The model wasn’t wrong for its time — it was built to manage scope, control risk, and get qualified work through the change control board. Its core question was always: can we build this, and what will it take?
What it was not built to answer was the harder question: should we build this, and what will it be worth?
When budgets were larger, timelines longer, and the business moved at roughly the speed of IT, you could get away with not asking that question. Today, that world is long gone. The business now moves in days while changing SAP often takes months, and every change entering the pipeline without a clear value case takes up capacity that a higher-value change could have used instead.
The Cost of Doing the Wrong Change Right
What makes a weak design stage so costly? Flawless execution can’t save you from a change that should never have been approved in the first place. You can hit the timeline, come in on budget, clear every quality gate, deploy cleanly, and close the project — yet still deliver something that generates little or no business return, because the design was wrong from the outset.
I’ve seen versions of this more often than I expected, like an integration that solves a technical problem nobody was losing money on, or a workflow redesign that strips steps out of a process that wasn’t the constraint. Or even a custom build chosen over standard configuration at three times the cost, because no one put the alternative on the table.
None of this shows up as a noticeable failure. On-time and on-budget look fine, and the delivery dashboard stays green, but the capacity was spent and the return never materialized. The waste is real; it’s just invisible, because it was designed in before delivery began.
A change function optimized for delivery speed, pointed at poorly designed changes, simply reaches the wrong destination faster.
Change design has to move from a technical intake exercise to a business value-led exercise. That doesn’t mean sidelining the technical team — the opposite. It means bringing business stakeholders and technical teams together at the design stage, in parallel rather than in sequence, to answer five questions before a change is committed to the backlog.
The Five Questions Every Change Should Answer
Before a change enters the backlog, business and IT should use these questions to agree not just whether it can be built, but whether it should be.
1. What business outcome are we actually trying to achieve?
Not the system change or the functional requirement — the outcome. What decision gets made faster, what cost removed, what risk eliminated, what revenue enabled? If the answer is vague, the design isn’t ready to proceed.
2. What are the options?
Most SAP changes are designed as if there is only one way to solve the problem. There rarely is — standard configuration versus custom build, process redesign versus system change, phased versus full. Each carries a different cost, timeline, and impact, and surfacing the options before committing is where significant value is created or quietly left on the table.
3. What is the feasibility?
This is where the technical team’s expertise becomes genuinely valuable — not as gatekeepers deciding whether a requirement can enter the queue, but as partners who can tell the business what each option will really involve and where the risk sits.
4. What will it cost and how long will it take?
Not as a budget formality, but as a decision input. A change that delivers $500k a year but costs $800k and takes eighteen months has a very different case than one delivering the same outcome for $150k in six. The design stage is where you work that out, not after the contract is signed.
5. What will it return?
The ROI estimate doesn’t need to be precise; it needs to be honest. A genuine assessment of the value expected, the confidence behind it, and the assumptions it rests on. That gives the business a real basis for prioritization, rather than a queue ordered by whoever argued hardest.
Worked through together, these five questions turn the design stage from a handoff into a shared decision. The business understands what it’s buying; the technical team understands why it matters; both own the answer.
What This Looks Like in Practice
Take GlobalCo, the notional $10 billion enterprise (from my last article that introduced the new metrics every SAP leader needs): 242 active change projects, a pipeline economic value of around $460 million a year.
Under the old model, those 242 changes entered the backlog because each was individually feasible and approved. Nobody asked whether they were collectively the right 242.
Run them through a business value-led design stage and the picture changes: some have no clear outcome, some a far cheaper option nobody surfaced, some a delivery cost that destroys their ROI — and some are exactly right, now with a defensible number attached for the first time.
If even a tenth of that pipeline is poorly designed, that’s $46 million of value being managed without economic justification. Improving design quality doesn’t just trim waste; it raises the average return of everything the change function delivers.
Where Demand Quality Fits With the Four Executive Change Metrics
The four executive metrics I set out in my previous article — change pipeline economic value, time to value, cost of poor quality, and cost to deliver — remain the right top-line measures. They span the whole change process, from the moment the business asks for something to the moment it’s live in production. Nothing here replaces them.
What the design stage adds is a measure that feeds and supports those four, specifically at the front of the process. I’d call it demand quality: the proportion of changes entering your pipeline that arrive with a clear business outcome, a considered choice of option, an honest cost and effort estimate, and a defensible return. It isn’t a fifth top-line metric competing with the others — it’s the quality of what enters the pipeline, and because each one of the four measures something downstream of that entry point, demand quality shapes them all.
The four metrics below act as the scoreboard for demand quality: they show whether the changes entering the pipeline are strong enough to deliver value once they move through the system.
- Change pipeline economic value. The headline number is only as trustworthy as the value cases behind it. High demand quality means the changes entering the pipeline carry outcomes that have been genuinely assessed; low demand quality, and much of it rests on outcomes that were assumed rather than tested.
- Time to value. This metric runs from business ask to production. A well-designed change moves through delivery cleanly; a poorly designed change generates rework and rescoping that stretches the clock. Many time-to-value problems blamed on delivery actually originate at design and surface late.
- Cost of poor quality. A meaningful share of production incidents trace back not to a coding error, but to a change that was ambiguous or wrong by design. Resolving that at the design stage removes a whole category of downstream failure before it reaches production.
- Cost to deliver. The efficiency ratio of the function rises when capacity is spent on changes worth delivering. Raising demand quality lifts the return on the whole function without adding a single person to the team.
These four executive metrics measure the whole journey from business to production. Demand quality is what determines how much value is on the journey in the first place, and the design stage is where it’s set.
Why This Matters Now More Than Ever
Change design has always mattered. What’s changed is the pace and volume of demand SAP teams are now being asked to support. Every SAP leader I speak to tells a version of the same story: demand on the change function is rising sharply — S/4HANA programs, AI-driven process change, regulatory deadlines, business-as-usual — while budgets are scrutinized, skilled people are scarce, and teams shrink. The expectation, stated or not, is to deliver significantly more with the same or less.
That makes capacity the binding constraint, and the design stage is where you decide how to spend it. Every unit spent on a change that shouldn’t have been built is stolen from one that should, increasing the economic cost of delay across the entire portfolio.
Declining to build the wrong change is the cheapest, highest-leverage way to protect a stretched team — the work you don’t build costs nothing to deliver. And for the organizations already mid-migration to S/4HANA, the design decisions being made right now — Clean Core versus customization, designing for adaptability versus point-in-time need — will define the landscape for a decade. They are far too consequential to leave to a technical intake process.
Every Change Must Earn Its Place in The Pipeline
What this points to is less a new process than a different question, asked by a different combination of people. The old goal of change design was to get qualified requirements into the backlog efficiently. The new goal is to ensure every change entering it has earned its place.
That requires genuine joint ownership, between the business and IT, of the value case for change — and the honesty, at the design stage, to say when a change is unlikely to deliver sufficient business value or doesn’t have a strong enough case to proceed. That honesty is uncomfortable. It is also, increasingly, the difference between an SAP function that generates value and one that simply generates activity.
For every change in your pipeline right now, do you know the business outcome it’s designed to deliver, the options that were considered, what it will cost to build, and what it will return? Or did it simply pass a feasibility check on its way into the backlog? For most organizations, honestly answered, the gap is wide.
Changes are in flight that no one can attach a clear outcome to; options were never explored; costs and returns were never weighed against each other when the decision was made. Closing that gap is the work of the design stage.
It’s not that organizations don’t know these questions matter. It’s that answering them consistently across hundreds of SAP changes is incredibly difficult without the right operating model. Making value-led design a repeatable capability requires a structured way for business and IT to evaluate options, assess impact, and build confidence in the decisions entering the pipeline.
Design the Right Change, the First Time
Most organizations already have established processes for delivering SAP change. The greater opportunity lies in ensuring the right changes are entering the pipeline in the first place.
That means moving beyond feasibility alone and giving business and IT teams the ability to evaluate options, understand impacts, assess value, and build stronger cases for change before delivery begins. Without that intelligence, organizations risk spending scarce capacity on initiatives that are technically successful but commercially disappointing.
Klario was built to address exactly this as the decision intelligence layer of Intelligent Change Management. An agent-led SAP change design assistant, Klario gives you a guided workflow to move from business request to build-ready design decision with greater clarity, evidence, and alignment. By guiding teams through requirements definition, options evaluation, business case development, Clean Core assessment, and impact analysis, Klario helps ensure every change decision is driven by value from the start, rather than opinion.
Turn Better Change Design Into a Repeatable Capability
Doing change right will always matter — it is the floor. But designing the right change, in the right way, for the right return is the ceiling. And the ceiling is where the value is.
The organizations that get the most from their SAP investment in the years ahead will be the ones that make better decisions about what to build in the first place. Those that learn to ask, earlier and more honestly than their competitors, a deceptively simple question: is this the right change to make?
If you would like to see how leading SAP teams in large organizations are using Intelligent Change Management software to improve demand quality and make more confident change design decisions, book a meeting with one of our SAP experts. Let us walk you through how Klario can help you identify the right change, the first time, every time.