Nothing as such. There are many methodologies out there, but most align around the SAP Activate methodology. SAP has had an official implementation methodology for decades. ASAP came first. Then SAP Activate replaced it, bringing agile principles, fit-to-standard workshops, and guided configuration. It is a well-structured framework.
Yet, with all those decades of experience and improvements, why is it that Gartner still predicts that more than 70% of ERP initiatives will fail to meet their business case goals? The methodology keeps improving. The statistics stay stubbornly similar.
With such a good Methodology and implementors with so many years of experience, why is it that the statistics stay constant?
The problem is not that the methodology is broken. In fact, it is excellent. I have seen many successful projects using it. But I have seen even more that reflects Gartner’s statistics.
The challenge that we have seen is that the methodologies assume a sequence of events based on a Design-then-Build framework. This makes absolute sense. After all, you first need to document what you want and then build your system. But that is also the core issue we keep seeing on projects. How do you know what you want unless you have first seen what the system can do?
Imagine Buying a Car with a Design → Build Methodology
You go to the dealer and say you would like a family van. The dealer says: Sure, join me in the conference room so that we can design what it is you are looking for.
You are a bit puzzled, but follow her to the conference room. There, she shows you pictures of family vans, presentations about the future of driving, the history of the car company, and many technical specs on the capabilities of the engine.
After long discussions about your dream car, she then prints out a deck of specs and asks you to sign at the bottom so they can put in an order to the factory to build your car.
You are a bit nervous when you sign because you don’t understand all the technical details about what makes up a car.
You take delivery of the car 8 weeks later and are surprised and disappointed by several things that were never discussed or were misunderstood.
Thankfully for us, that is not how the car industry works anymore.
(Sadly, it is how most ERP transformations work)
Today, a car dealer just hands you a set of keys, tells you to do a test-drive in a similar family van on the lot, and then you let them know after doing a thorough test drive what changes or options you would like.
Imagine if ERP could work like that.
Is there a Way to enable that?
In the early part of the ERP project, you spend weeks or months in workshops defining requirements and designing processes. You document those decisions in a blueprint or fit-to-standard analysis. Then you hand that blueprint to a configuration team, which builds the system. Testing comes later. Training users comes even later.
The flaw is that this sequence asks people to make binding decisions about a system they have never seen or used. They, of course, see some demos, sandbox systems, Proof-of-Concept systems, and Model Companies of Templates. But they don’t see their own real-life working development system with their own process and their own data until very late in the Realization phase. You could call that phase the ‘Surprise’ phase, because your real system usually looks quite different from the demos you saw. As practitioners have observed on SAP Community, after a few months on most projects, the methodology is no longer adhered to because of late surprises and rushed rework. The framework is followed in name only, because the gap between what gets agreed in a workshop and what the system actually does is too wide for most business users to evaluate abstractly in the early phases. There is nothing wrong with the methodology; it is just that the devils are hiding in the details. We don’t know what we don’t know. In the first phases, we are usually looking at conceptual documentation that goes down to Level 3 or 4. The devils hide in Levels 5 – 20.
Making binding decisions on a system you cannot see is how surprises get built into the plan. A process that looked acceptable in a slide deck turns out to be unworkable when your own real data and process adjustments flow through it. A configuration that seemed minor in design has operational consequences nobody anticipated. The pushback comes later, during testing or after go-live, when the day-to-day reality of working in the system reveals friction that the workshops could not simulate. By then, the project is too deep into its timeline, and the cost of rework is high.
Consider a mid-market manufacturer that followed Activate by the book. Blueprinting was completed on schedule. Fit-to-standard workshops ran for ten weeks with strong attendance. The project entered the build phase on time and on budget. Then, during integration testing, the warehouse team discovered that the standard picking process did not account for their multi-site consolidation logic. Rework took eleven weeks. The go-live slipped by four months. The methodology was not misapplied. The problem was that nobody could see the gap until their real working system exposed it.
What Would the Right Sequence Look Like?
The core challenge is that the customer commits budget, resources, and organizational attention before ever seeing their own system work. The methodology treats system visibility as an output. It should be an input. But alas, it is not easy to do a quick pre-implementation of your system before starting the project. Or is it?
If business users could see, test, and react to a running system implemented with their own data and processes before the Fit-to-Standard begins, so that they can test-drive, most of the problems described above would not arise. Fit-to-standard conversations would become concrete instead of abstract. Process owners would identify gaps against a real system, not a diagram. Training could start with something that exists. And scope decisions would be grounded in evidence rather than assumptions. Testing could be done early.
This is the principle behind LeapGreat’s FrontLoad™, which delivers your working SAP S/4HANA system configured with customer data before the traditional methodology sets out. The Methodology then turns into a Pre-Flight checklist. The team behind it, which includes holders of patents for SAP ERP infrastructure technologies and the original authors of the SAP Best Practices Manufacturing Baseline, built the approach specifically to address the sequencing problem that they saw customers struggling with.
The Methodology Is Not the Problem. The Detailed System Visibility is.
SAP Activate is a great framework. Fit-to-standard is a sound principle. The failure is not in the methodology itself but in the assumption that people can make all decisions about a system they have never seen. Reverse the sequence, and most of the problems that methodology is supposed to prevent simply do not arise. We wrote more about this pattern in Why SAP Transformation Programs Discover Problems Too Late.
In fact, you can leave SAP Activate as it is, but with a running system in advance, you turn it into a checklist rather than a sequence, allowing you to conduct a true Agile transformation. Most mature industries in the world actually work on a Build → Refine model rather than Design → Build. We believe it is time to do the same for ERP Transformations.
Curious what that looks like in practice? Explore the LeapGreat FrontLoad™ approach, or get in touch to see how it works with your data.
