On September 18, 2025, LeapGreat hosted a LinkedIn Live panel exploring why so many SAP S/4HANA projects fail despite decades of accumulated experience. Moderated by Ross, the conversation featured Sana Asher (SAP Advisor), Patrik Fiegl (VP, Global Head of Strategic Product Partnerships at Tricentis), and Bernhard Lang (Co-Founder of LeapGreat).
Their shared message was simple: S/4HANA programs fail less from technology and more from governance, behavior, and readiness. The system works; the way organizations approach it often doesn’t.
Asher summed up the paradox: “We keep doing the same things over and over again, and we keep getting the same result.” Lang reflected on how delivery has evolved, “In the nineties, one person might do everything from conversation to coding. Today, that’s split across four or five roles”, and argued that this fragmentation creates blind spots. Fiegl added a reminder that “tools don’t do the job, you need guidance on the tools.”
This article distills their discussion into a practical operating model for ERP and in particular SAP leaders to cut complexity, tighten control, and build internal capability.
1. Root causes of persistent ERP complexity
After 50 years of ERP evolution, the pain points remain familiar: late alignment, unclear ownership, and unrealistic expectations. Complexity accumulates not because S/4HANA is inherently flawed, but because organizations repeat the same fragmented behaviors.
Asher pointed out that while the software is stable, the problem lies in adaptation, how teams interpret and absorb change. Projects often begin as tactical implementations rather than strategic transformations. Leadership underestimates the cultural and behavioral shift required to adopt fit-to-standard practices.
Lang traced the issue to the fragmentation of delivery models. In earlier decades, “full-stack” consultants could translate business requirements into configuration and code. Today, responsibilities are split among analysts, developers, and business stakeholders. That specialization is necessary, but without strong integration and shared process ownership, the seams show. Misaligned workstreams and siloed decision-making magnify confusion and cost.
Fiegl added a systemic dimension: modern ERP spans “financial, commercial, material, and human interactions.” That breadth, he said, demands architectural discipline, yet too often, programs treat ERP as “a technical exercise instead of an enterprise transformation.”
Self-diagnosis
Ask yourself:
- Are your workstreams planned in isolation?
- Do business, configuration, and testing align to a single process map?
- Is fit-to-standard governed by evidence or by negotiation?
- Does your first meaningful demo appear only in Realize?
- Who truly owns decisions, the customer, or the SI?
What good looks like
A successful approach starts with a single process backbone linking strategy, design, configuration, and testing. Fit-to-standard becomes a managed decision process with clear owners and criteria. The customer, not the system integrator, owns the plan, outcomes, and definitions of success.
A practical example: during Phase Zero, stand up a minimal “version zero” system showing three to five critical flows end-to-end with anonymized data. Seeing the system early surfaces design conflicts and accelerates buy-in.
Lang’s warning captures the point: “You can’t outsource responsibility, you have to take responsibility and take these decisions.”
2. Control, alignment, and methodology as levers
If complexity begins with fragmentation, control is regained through methodology and transparency. Fiegl was blunt: “Tools don’t do the job. You need to have guidance on the tools.” Without a connected tool chain and disciplined process, even the best automation leads to chaos.
A unified tool chain, linking ALM, process modeling, and test automation, creates the spine for visibility and accountability. But it only works if governance defines who makes which decisions, when, and based on what evidence.
Asher argued for a deliberate Phase Zero: a planning stage that sets governance, process hierarchy, and decision rights before configuration begins. “Spend the time planning,” she said, “so you can adapt quickly later.”
Lang, meanwhile, described control as a leadership skill. “Enforcing standard is not about bureaucracy, it’s about facilitation,” he said. Teams must be able to challenge business users and show why standard works. That requires confidence, not compliance.
What good looks like
Control means visibility. Each process and risk should trace through the tool chain to specific backlog items, configurations, and automated tests. Every Explore workshop ends with a “show me early” demo rather than a slide deck. KPIs shift from deliverables to behaviors: time-to-first-demo, decision latency, standard adoption rate, and rework trend.
Fiegl’s “test intent” idea connects governance to quality. Define what success protects, customer delivery, pricing logic, compliance, and align risk-based test suites accordingly. “If quality comes late,” he warned, “it will not be good quality.”
When done right, methodology and tool integration often cuts rework significantly, because information flows instead of being recreated.
3. Building capability and ownership inside the customer
The third pillar is cultural: projects fail when ownership is outsourced.
Lang has seen this pattern across industries. “Decision making is often delegated to the project team,” he said, “and that doesn’t work.” The SI can bring expertise, but only the customer can make and sustain business decisions.
Asher agreed, noting that most clients underestimate their internal skill gap. Before kickoff, she recommended upskilling teams so they can evaluate fit-to-standard decisions and understand the system’s possibilities. Without that foundation, governance collapses under dependency.
Fiegl expanded the point: “Transformation is a team sport.” Tool chains and playbooks help, but execution still hinges on communication and mutual understanding. Success requires a core leadership spine, enterprise architecture, process owners, QA, change, and data, who operate as one team.
What good looks like
- A standing Design Authority that rules quickly on standard vs custom.
- A core test team staffed by business users who understand process risk.
- Biweekly show-and-tell demos where business users see working functionality.
- A small Center of Excellence (CoE) to run releases, regression, and adoption.
For example, a manufacturing client can rotate plant managers through demos of standard inventory workflows, letting them validate what works and capture feedback directly in the tool chain. Decisions stay visible, and accountability stays in-house.
Asher emphasized that adoption planning must start from day one. Change management is not an add-on; it’s a workstream equal to data or integration.
From vision to operating model
The panel agreed that successful transformation connects strategy to execution through an integrated information chain:
strategy → process → configuration → testing.
In companies, SAP leaders sit at the center of that chain. They must ensure that enterprise models translate into process hierarchies, that those processes map to configurable elements in ALM, and that testing draws on the same structure.
Fiegl illustrated this with “test intent.” Suppose your business risk is on-time delivery for regulated goods. From day one, tag that flow, define success, and automate its smoke tests. Every configuration affecting it triggers a retest. This creates real-time assurance, not after-the-fact inspection.
Asher reinforced the behavioral aspect: “Show me early.” Each iteration should include working system demos. Visual confirmation eliminates misinterpretation and speeds alignment across teams.
A 30-60-90-day roadmap
Day 0–30: Build the spine.
Establish governance, a Design Authority, and escalation paths. Define the scope of Phase Zero, select your tool chain, and draft a Level-2 process catalog. Identify the ten highest-value flows and write your first test intent.
Day 31–60: Make it visible.
Run fit-to-standard show-and-tell sessions. Capture every decision in the tool chain. Baseline Level-3 processes and automate initial smoke tests for top-risk flows. Create masked golden data and start weekly readiness reporting.
Day 61–90: Build capability.
Formalize the CoE charter. Execute the change plan tied to the demo cadence. Run weekly regression tests, track variance backlog, and report on readiness metrics, standard adoption, rework, and decision latency.
Each milestone reinforces the others: governance builds control, control enables speed, and visibility sustains alignment.
Common objections, and answers
“We’ll let the SI decide.”
You can’t outsource accountability. As Lang said, responsibility must stay with the business. The SI can support execution, but only the customer can decide what standard means.
“We don’t have time for Phase Zero.”
Skipping planning is a false economy. Asher’s point was clear: preparation prevents paralysis. A well-run Phase Zero sets the structure for control and saves months of rework later.
“Testing can wait.”
Fiegl’s rule applies universally: “If quality comes late, it will not be good quality.” Risk-based testing begins in Explore, not UAT. Early automation stabilizes the program and protects the go-live window.
Metrics that matter
EAs should own leading indicators, not just lagging outcomes. Track:
- Phase Zero completion (artifact checklist achieved).
- Time-to-first-demo (in weeks from kickoff).
- Decision latency (median days to approve standard vs variance).
- Percent standard adoption (by process scope).
- Automated test coverage (top-risk flows).
- Rework rate (per sprint).
- Adoption readiness (business signoff participation).
These metrics forecast risk before it becomes visible on cost or timeline charts.
The September 18 LeapGreat panel landed on a shared truth: S/4HANA success depends less on technology and more on behavior. Asher called out the habit of repeating old patterns. Lang emphasized leadership and responsibility. Fiegl showed how integrated methodology and early quality turn vision into control.
For leaders, the takeaway is direct. Treat S/4HANA as a business transformation. Anchor scope in process, define decision rights, link strategy to testing through a connected tool chain, and demonstrate value early. Build internal capability so ownership never leaves your organization.
Do that, and complexity stops owning you.
