Most SAP programs are approved before the hardest questions have been asked.
The business case is built around the destination — the efficiency gains, the process improvements, the competitive capabilities that a modern SAP platform will deliver. It is rarely built around an honest assessment of whether the organization is ready to get there.
The result is predictable: projects that begin with ambition and end with overruns, under-adoption, and a gap between what was promised and what was delivered. Not because SAP failed. Because the organization walked into implementation before it answered the questions that determine whether an SAP program succeeds or struggles.
How to use this framework:
Read each question carefully. Answer it honestly — not aspirationally. If your answer reveals a gap, treat it as a pre-implementation workstream, not something to resolve after go-live. The organizations that get SAP right do so because they addressed these gaps before the project started, not during it.
Question 1 : Do we know what business outcomes we are actually trying to achieve — and have we said no to everything else?
This sounds like a straightforward question. It rarely has a straightforward answer.
Most SAP programs begin with a list. Faster financial close. Better inventory visibility. Improved customer experience. Integrated supply chain. Streamlined procurement. Real-time analytics. AI-powered forecasting. It is a compelling list. It is also a scope problem waiting to happen.
Every item on that list is achievable. Trying to achieve all of them simultaneously, in a single program, with a single team, on a single budget, is how projects become unmanageable. Scope expands. Timelines slip. Teams lose focus. The original business case becomes unrecognizable by month eighteen.
The organizations that execute SAP programs with speed and clarity make a different choice at the beginning. They define two or three outcomes that are genuinely critical to the business — the ones that will demonstrably change commercial performance, operational efficiency, or competitive position — and they ruthlessly deprioritize everything else for phase one.
This is not a compromise. It is a strategy. A focused SAP program that delivers its core outcomes in twelve months creates more value — and more organizational momentum — than a sprawling program that partially delivers everything in thirty-six.
The diagnostic question:
If you could only achieve one outcome from this SAP program in the first twelve months — the one that would most tangibly change your business — what would it be? If your leadership team cannot align on a single answer, your scope is not ready.
Question 2 : Who owns this program — and do they have the authority to make decisions when it gets hard?
Every SAP program has an executive sponsor on paper. Far fewer have one in practice.
Nominal sponsorship — a senior leader whose name is on the governance document but who attends the steering committee once a month and delegates every difficult decision — is one of the most reliable predictors of SAP program failure. It is also one of the most common organizational patterns.
The reason executive sponsorship matters is not ceremonial. It is operational. SAP programs surface organizational conflict. They require business units to change processes they have owned for years. They force trade-offs between competing priorities. They demand decisions — about scope, about resources, about timeline, about design — that cannot be resolved at the project level.
When those decisions escalate, and the executive sponsor is not genuinely engaged, one of two things happens: the decision gets deferred, which costs time and money, or the decision gets made by whoever has the most organizational influence in the room, which is rarely the person with the clearest view of what’s right for the program.
| ✓ Ready to proceed | ✗ Pause and resolve first |
|---|---|
| Named executive owns outcomes, not just oversight | Sponsorship is delegated to a VP or Director |
| Sponsor attends key design workshops personally | Sponsor is only present at monthly steering meetings |
| The sponsor is only present at monthly steering meetings | Escalation path requires multiple approval layers |
| The sponsor can commit budget adjustments without the committee | Every budget decision requires a new approval cycle |
| The program director has direct access to the sponsor between meetings | Program director has direct access to the sponsor between meetings |
If your honest assessment of your sponsorship model looks more like the right column than the left, this is a pre-implementation issue to resolve — not a program risk to manage.
Question 3 : Is our data honest — and do we know what it will take to make it trustworthy?
There is a version of this question that every organization believes it has answered. “Yes, we know our data has issues. We’ll clean it up during the project.”
This answer is almost always wrong — not in its assessment of data quality, but in its confidence that data remediation can be executed as a parallel workstream during an active implementation. It cannot. Not at the scale most organizations require.
Data is the foundation of every SAP process. Master data — materials, vendors, customers, cost centers, chart of accounts — defines how every transaction behaves. If that foundation is inconsistent, incomplete, or duplicated, the consequences don’t appear in testing. They appear in production, when a purchase order won’t process because the vendor master is missing a required field, or a financial report is wrong because the same cost center exists under three different codes.
The honest version of data readiness requires answers to questions that most organizations have not asked:
- How many active vendor records do we have — and how many are duplicates or inactive?
- Who is the named business owner of each master data domain? Not the IT owner — the business owner.
- What is our current data completeness rate for the fields SAP requires? Have we measured this?
- Do we have the internal capacity to complete data cleansing on the timeline the implementation requires, or do we need dedicated resources?
- What is our plan for data governance post-go-live — to prevent the same quality issues from recurring?
None of these questions has comfortable answers for most organizations. That discomfort is exactly why they need to be asked before the project starts.
The most common data mistake in SAP programs:
Treating data migration as an IT task. Data quality is a business problem with an IT component — not the other way around. Every master data domain needs a named business owner who is accountable for the quality of the data that goes into the new system.
Question 4 : Have we designed for adoption — or just for go-live?
Go-live is the most visible milestone in an SAP program. It is also, in many ways, the least important one.
What matters is not whether the system goes live. What matters is whether the people who need to use it actually do — correctly, consistently, and in ways that deliver the business outcomes the program was designed to achieve. A technically successful go-live with poor adoption delivers a fraction of the available value. In some cases, it delivers negative value — because the organization now has a modern system running legacy processes.
Designing for adoption means making it central to the program — not a training track that begins six weeks before go-live, but a structured workstream that starts at day one and runs through stabilization.
Adoption starts with process design. If the people who will use the new system are not involved in designing the processes they will follow, adoption will be poor regardless of how well the system is configured. Business users need to co-design their workflows — not just review them in a UAT cycle.
Training must be role-specific, not generic. The most common training failure in SAP programs is system-centric training — here is what each screen does — rather than role-centric training — here is how you do your job in the new system. Users don’t need to understand SAP. They need to understand how to do their specific tasks.
Resistance is a design input, not a management problem. When business users resist a new process or system, the instinct is to manage that resistance. The better instinct is to understand it. Resistance usually signals a legitimate concern — a workflow that doesn’t work for a real use case, a process that ignores an operational constraint, a change that creates more work rather than less. Surfacing these concerns before go-live is valuable. Discovering them after is expensive.
Hypercare is not optional. The first 60-90 days after go-live are the highest-risk period for adoption failure. Users are learning new workflows under operational pressure. Issues surface that weren’t caught in testing. Frustration peaks. Organizations that withdraw implementation support immediately after go-live consistently underperform those that maintain a dedicated hypercare team through stabilization.
Ask your implementation partner this question:
“Show me your adoption methodology — not your training plan, your adoption methodology.” If they can’t distinguish between the two, that tells you something important about how they approach go-live.
Question 5 : Are we choosing a partner for this program — or for the next ten years?
The most expensive SAP mistake is not a failed implementation. It is a successful implementation with the wrong architecture — one that locks the organization into a set of design decisions that make every future capability harder to add, every future upgrade more disruptive, and every future innovation more expensive to deploy.
The partner decision is not just a question of who can get you to go-live. It is a question of who will help you build an SAP landscape that is genuinely future-ready — clean-core, cloud-first, extensible through BTP, and data-ready for AI.
These architectural principles are not theoretical. They are practical decisions that get made in every design workshop, every configuration session, and every customization discussion. The right partner makes the right call in those moments — choosing the standard process over the custom one, the cloud-native approach over the legacy pattern, the BTP extension over the core modification. The wrong partner takes the path of least resistance, which is almost always the path of maximum future cost.
What to look for in a long-term SAP partner:
Deep delivery experience across ERP, CX, BTP, and Data — not just one capability
A clean-core philosophy that is demonstrated in their delivery approach, not just their sales materials
Reference clients who will speak honestly about how the partner performed under pressure
The willingness to push back on your team’s requests when those requests would compromise the architecture
A post-go-live relationship model — not just an implementation contract
The partner conversation is also where organizational self-awareness matters. If your organization struggles with decision-making, a partner who tells you what you want to hear will accelerate that dysfunction. If your organization needs to be challenged on legacy process assumptions, a partner who defaults to ‘yes’ will deliver a modern system running old thinking.
The best SAP partnerships are honest ones. They involve a partner who will tell you when your approach is likely to create problems — and an organization that is willing to hear it.
What These Five Questions Have in Common
Reading across these questions, the pattern is clear. They are all asking a version of the same thing: is your organization prepared to do what it takes to succeed — not just to start?
Starting an SAP program is easy. Organizations do it every day with insufficient clarity on outcomes, nominal sponsorship, unresolved data debt, no adoption strategy, and a partner selected primarily on price. Some of those programs succeed despite these gaps. Most do not deliver what they promised.
The organizations that consistently get SAP right are the ones that treat the pre-implementation period as seriously as the implementation itself. They invest in answering these questions — honestly, with the right people in the room — before scope is locked, before budget is committed, and before the decisions that shape the next three years of their technology landscape become irreversible.
That investment is not a delay. It is the most valuable thing an executive can do for an SAP program before it begins.
ASAR Digital’s Fast, Simple SAP philosophy:
We built our pre-implementation advisory practice around exactly these questions — because we have seen, repeatedly, what happens when they are not answered before implementation begins. Our goal is to help organizations go into SAP with clarity, not just commitment.
Not sure your SAP program is starting from the right foundation?
Before scope gets locked in and complexity compounds, talk to ASAR Digital. Our pre-implementation advisory is designed to surface the gaps that derail programs — and help you close them before they become expensive. It’s the conversation most organizations wish they’d had six months earlier.