The process conversations most SAP programmes avoid — and why skipping them costs more than the system itself
Hello, everyone!
After twenty years of delivering SAP ERP and SAP Commerce Cloud enterprise implementations, I have learnt that projects rarely fail because of the technology. They fail because nobody challenges the underlying processes. Change management is often treated as an optional extra — something to be dealt with after the system goes live, if at all.
This months edition focuses on this issue. It explores what breaks SAP transformation programmes, why its rarely the software, and what it actually takes to build a solid foundation.
Why SAP S/4HANA and Commerce Cloud implementations struggle — and its not the software
The numbers are hard to ignore. Roughly 70% of ERP implementations run over time, over budget, or fall short of the business value they were supposed to deliver. The root cause is seldom in the system. It starts earlier — in how the project was scoped, what was assumed without being validated, and which conversations were avoided because they were uncomfortable.
The organisations that break the pattern share one thing: they treated the process conversation as part of the technical work, not separate from it. What that looks like in practice — and what the other 70% consistently skip — is worth understanding before your next implementation begins.
The process problems that quietly sabotage SAP S/4HANA projects from the inside
Every organisation carries process debt — workarounds that became workflows, exceptions that became the rule, and ownership that was never clearly assigned. In normal operations, its manageable. In an ERP implementation, it becomes load-bearing. The system inherits everything the process carries.
What makes this difficult is that the people closest to these processes often cant see them clearly. They describe how they work today. They rarely question whether its how they should work tomorrow. Thats not a criticism — its a structural problem, and its the consulting teams job to name it. The specific patterns that derail implementations most often, and what to do about them, are documented here.
SAP Commerce Cloud is not a website. The planning has to reflect that.
When SAP Commerce Cloud projects are scoped like frontend projects, they go wrong in predictable ways. The complexity isnt in the storefront — its in the integrations, in the business logic thats accumulated over years, in the backend processes the new architecture has to serve. Understanding that before the build starts determines whether the timeline is realistic and whether the go-live holds.
This piece maps the planning complexity that most teams underestimate — and what a properly structured implementation actually looks like from the first week.
→ SAP Commerce Cloud Implementation: Beginning, Planning, and Complexity
SAP Commerce Cloud is not a navigation exercise. Its an innovation one.
Theres a version of an SAP Commerce Cloud implementation that keeps the business exactly where it is — just on newer infrastructure. And theres a version that genuinely changes what the business can do. The difference isnt in the technology chosen. Its in whether the project was set up to ask the harder question: not how do we migrate what we have, but what we should be capable of that we arent today.
→ SAP Commerce Cloud Is Not a Website: What Digital Transformation Actually Requires
The mission stays the same: find a partner who challenges what youre used to, cleans up whats quietly limiting you, and builds a foundation the next chapter of your business can actually run on. Not a roadmap. A working system — delivered by people who know the difference and are willing to say so.
For more successful digital transformation projects.
Borislav Minkov
Your Digital Transformation Partner