SAP S/4HANA Transformation

Don’t Rent Your SAP Transformation. Own It.

By Bob Cummings

Do you feel like the standard for ERP implementation is complexity, uncertainty, and forces enterprises to outsource critical decisions?  Is it time to start taking control?

If you are an executive currently planning or navigating an SAP S/4HANA transformation, or perhaps recovering from a stalled one, you likely feel a sense of professional isolation. When these massive projects go off the rails, the internal narrative is familiar. You hear people say: “The technology is a beast that cannot be tamed,” or “Our SI messed up our project,” or “Our internal team wasn’t ready.”

We look at the wreckage of budget overruns, missed deadlines, and change-request proliferation, assuming this failure is a unique pathology of our organization.

You are not alone.  

Having spent over 35 years in the SAP ecosystem observing projects from the inside, the pattern is undeniable: The struggles you face are not anomalies; they are endemic to the traditional ERP implementation approach.  In fact, research by SAP has shown that the true culprit is neither the software, nor the SI, nor the customer staff.   Well, in some cases, it is those things, but we found that in 90% of cases, it was actually something else.  The real culprit is simply the nature of these projects. 

 As one industry veteran put it, replacing your ERP is less like an organ transplant and more like simultaneous multi-organ transplant surgery.

While over 70% of the world’s commercial transactions touch an SAP system, over 70% of those companies have not yet moved to S/4HANA, even though it has been around for over a decade… why? Because the journey is notoriously perilous. (…and SAP ECC isn’t broken.  In fact, it is a great system.) 

So what is wrong with the conventional approach to SAP projects.   

Design then Build. Create your Concept, then move into the system. We tend to reinvent the wheel on these projects.   Many months (sometimes years) are spent in the beginning documenting the AS-IS and then TO-BE states, only to be surprised later (much later) when the real system emerges that the real devils are in the details and were not considered in the Design documents.  This causes rework and project swirl, which more often than not leads the project off the rails. 

The Anatomy of the Struggle

When we map out the standard SAP S/4HANA journey, we find that the traditional sequential model creates friction at every phase. It is a timeline of escalating risk.

  1. 1. The Decision Phase: Why move? 

Why should we do anything?  Is there really a Business Case to move?   This is arguably the most difficult phase. Most companies operate on the assumption that “if it isn’t broken, don’t fix it.” Your current ECC system likely meets today’s needs. Building a business case to move to a new platform is grueling because executives struggle to see the value. Without a clear strategic “why,” inertia takes over.  That is why, for over a decade, most of the SAP installed base has still not moved to SAP S/4HANA.   There is a missing sense of urgency that even SAP’s Maintenance-End Strategy has a hard time dislodging.  

  1. 2. The Planning Phase: A Crisis of Credibility

Once a decision is made, planning begins. But credibility is already low. CFOs are conditioned to disbelieve cost and time estimates. If a CIO presents a budget, the CFO mentally multiplies it by a factor because history has taught them that ERP projects always overrun their budgets and time windows.   You don’t need to look far in Google to find these statistics. 

Who is going to help us do this project? Will we get the top skills? Compounding the struggle is a massive resource shortage. According to the user groups, the SAP ecosystem is facing a 70% skills shortage, leaving less than 30% global capacity to do the required work that is ballooning in the coming years as we face the SAP ECC end-of-maintenance dates. The result? There is no shortage of consultants.  There is a shortage of skills. Often the “experts” showing up to run your massive transformation are necessarily juniors who simply do not have the deep expertise to guide you.

3. The Design Phase: The “Paper Tiger.”

In the past, we designed systems using PowerPoint and Excel. Today, we have a high-tech landscape of BPM tools, Process Mining, Task Mining, Architecture Management, Project Management, and lots more.

These are all great tools, but one needs to learn them, integrate them with each other and build the bridge to the real underlying system.  Otherwise, you end up with mountains of documentation, descriptions of what you want, that are disconnected from the system reality. You spend months building a “Paper Tiger”, a theoretical design that has never been tested against the actual software and only becomes obvious deep in the Build phase.  It is almost impossible to Document everything that is needed.  And even if you could achieve perfect documentation, will it be read? 

  1. 4. The Build Phase: Entering “The Swirl.”

This is where the true challenge begins. The transition from Design to Build is a “Sea Change.” You are moving from a world of descriptions to a world of system reality.

Because you didn’t know what you didn’t know during the design phase, the Build phase becomes a discovery of unpleasant surprises. You realize the theoretical design doesn’t fit the actual system behavior.  The devils are hiding in the details.  SAP is a massively flexible system.  However, it can be quite unforgiving.  The power is in the details, but so are the challenges.   Once you discover the reality of the system, you hear statements like:  Oh, I didn’t realize it works like this?  Where is that Field/object we used to know?   Why was that not added to the Design? You have to backtrack to Planning, then back to Design, and rework the Build.

This creates “The Swirl”, a constant, exhausting loop of rework. Usually not once, but repeatedly.   This is where the number of change requests explodes. The cost of making design changes late in the build cycle grows exponentially. This swirl is the graveyard of budgets and deadlines, leading to the dismal statistics you read about in the press.  (Try Googling, for example, ERP Risk Statistics Gartner

  1. 5. Adoption and Innovation: Too Little, Too Late

Key users are often not involved early enough because we were waiting for a “tested system” to show them. When they finally see it, their negative feedback harms the project’s reputation, and there is no more time to make the changes they request.  By the time you reach the Change Management phase, it is often too late to make significant changes, leaving the organization unhappy.  

Finally, in the Innovation phase (post-go-live), exhaustion sets in. Companies are so exhausted by the effort of getting the system live that they become frightened to touch the system again. The implementation consultants are long gone, and the internal team is left thinking, “If the system works, don’t fiddle with it.” The system remains static, and the promise of “continuous innovation” dies. Talk to any SAP user and ask how many significant improvements were made to their systems in the last few years.

The Root Cause: Separation of Concept and Reality

Why does this happen repeatedly? The root cause is the work’s sequential nature.

In the traditional model, you lack early visibility. Because you cannot see the future system, there is a huge temptation to study the “As-Is”, your current system. You spend months analyzing the past to design the future. It’s like trying to build a modern electric car by studying a horse and carriage.  If you are not careful, you might bring the horse along and tie it to the front of the new car.  A silly analogy, but there are many very curious configurations we have seen in SAP systems that you wouldn’t believe.  These crept in there because the design was based on the old world – not the new.  

The Pivot: FrontLoad™ Your Transformation

Our goal at LeapGreat is to help customers master their transformations and become self-sufficient at it.  Our philosophy is simple: Start with your live future system on day 1.  Do Design and Build through a consecutive Refinement process.  

LeapGreat enables this through our FrontLoad™ concept that lets you test drive your future, combined with a Navigation Platform that guides you to success.

And when you start your project, launch all work streams in parallel on day one, aligned around a running system. 

The “Version 0” Approach

LeapGreat delivers your Phase 0 transformation as a service. Before the project kicks off and before you commit to a multi-year budget, we build your “Version 0” of your future system, along with your Design and integrated SAP Project Toolchain. 

This isn’t a generic demo environment. It is a working system, configured to your reality, populated with your data structures, and connected to your Toolchain.

On Day One of the project, you have:

  • A Working System: A clearly scoped “Version 0” of S/4HANA to validate standard fit and architectural direction.
  • A Working Project: Your project toolchain, equipped with the LeapGreat Hub to ensure clear navigation, visibility, traceability, and decision ownership.

This eliminates “The Swirl.” You aren’t imagining requirements; you are refining a working prototype. You shift from “Let’s specify what we want?” to “How do we refine this to fit us perfectly?”

The LeapGreat Hub: Your Control Layer

In the traditional model, your project methodology, task management, and documentation are in silos. Our Hub integrates them. It provides “one-click” transparency. You can navigate from a business process or role in the documentation directly to the live transaction in the system.

This enables us to embed our expertise and decades of S/4HANA knowledge directly into your workflow. By leveraging tools such as the Model Context Protocol (MCP) and AI, we enable your team to interrogate project context and generate test cases and process designs instantly.

The Value of Ownership: A Message to Stakeholders

The FrontLoad™ approach resolves the specific fears of your executive leadership team.

For the CFO: Capital Efficiency & Predictability

The CFO fears runaway budgets driven by unknowns, rework, and opaque delivery structures. The traditional model asks them to put effort under uncertainty.

The Pivot: ERP programs fail financially not because of SAP, but because early decisions are made without visibility into the future. LeapGreat reduces uncertainty upfront by delivering a working baseline in Phase 0. Instead of committing to a multi-year execution before understanding the system, you make informed, fixed-scope decisions based on what actually works. You are not only buying speed; you are buying financial predictability and decision discipline.

For the Enterprise Architect: Governable Agility

The Enterprise Architect fears inheriting a system they cannot explain, govern, or evolve. They fear the “loss of control” when external consultants make undocumented decisions in a silo.

The Pivot: ERP complexity becomes unmanageable when architectural knowledge is scattered across tools, documents, and people. LeapGreat uses the Hub to structure execution from the start. Documentation, decisions, and system behavior are linked directly to the live system and continuously regenerated. Your Center of Excellence inherits a Living Blueprint, not static documentation, allowing your team to govern architecture and manage future rollouts with confidence.

For the Operations Leader: Validation over Speculation

Operations leaders fear disruption. They often fall into the “Brownfield Paralysis” trap, assuming they must recreate the past before moving forward.

The Pivot: Lengthy analysis does not reduce risk; early validation does. LeapGreat delivers a Version 0 system that allows business users to interact with standard processes early and assess real operational fit. This replaces speculative planning with direct experience, aligning teams around what works and what needs refinement before large-scale rollout.

Conclusion: The Path to Self-Sufficiency

LeapGreat is not just another implementation partner. We are the Service Partner for enabling your Self-Sufficient Transformation.

Our goal is to turbocharge your internal Center of Excellence. By delivering a working Version 0 system and the Hub to navigate the transformation, we transfer capability to your organization.

We enable you to own the project, manage refinements, and work with the ecosystem on your terms. Stop guessing. Stop renting. Start owning your SAP transformation.


Ready to Take Control?

If you’re planning an SAP S/4HANA transformation, or trying to recover one, don’t move forward in the dark.

LeapGreat helps you start with a working system, not a blank slide deck.

Contact us to see what Version 0 looks like for your organization.

See your ERP in just one week.

Ready to get started? Have a few questions? Schedule a call and begin your LeapGreat journey.