The pattern nobody wants to admit
At least here in Finland, ERP programs representing investments of tens, sometimes hundreds, of millions of euros are being quietly frozen or abandoned mid-flight. This is not a fringe phenomenon. It is happening in major listed companies with experienced leadership teams and access to the world's best technology partners.
My direct observations imply that the root cause is rarely the technology. Implementation partners play a role, and the blame often lands on their desk. I argue that the true root cause is a fundamental misunderstanding of what this kind of transformation actually requires.
When the vendor's logic takes over
The approach most organizations take is, on the surface, rational. Adopt standardized best-practice processes, minimize customization, and let the system shape the organization. CFOs appreciate the discipline. CIOs see a path to reducing technical debt. The logic holds together beautifully until reality arrives.
Every organization carries its own history:
- Multi-entity group structures.
- Integration landscapes where dozens of systems exchange data through interfaces no single person fully understands.
- Operational choices that reflect deliberate strategic decisions made over years.
- Just to name a few.
When a standardized ERP meets this reality, the collision is expensive. Best-in-class processes turn out to be best-in-class for a reference customer with their legacy, not this organization. Workarounds accumulate. Stakeholders disengage. And eventually someone at executive level asks the question that should have been asked at the start: what exactly are we building, and why?
By that point, answering honestly can cost your seat at the table.
Where things start going wrong
Leaders without a shared vision
The organization enters the transformation without a grounded picture of its current or future operating model. The vendor's reference model fills the vacuum. It feels like progress but rarely is.
Architecture work is skipped for speed
Process architecture work gets compressed in the interest of momentum. Moving to configuration before the foundations exist is the organizational equivalent of pouring concrete before the soil survey and structural calculations are complete.
Complexity hidden rather than modeled
The true complexity of the integration landscape and real operations is rarely surfaced honestly in the early phases. But complexity does not disappear. It resurfaces during implementation, at maximum cost.
Strategic thinking outsourced
System expertise and business expertise are not the same thing. And business expertise sitting in a consultant's slide deck is not the same as the operational knowledge held by the people who do the work every day. Organizations that skip that layer lose control of outcomes.
The work that actually makes the difference
The organizations that succeed with large-scale ERP transformation do the spade work first. Not the exciting work of system demos, vendor beauty contests, and selection workshops, but the unglamorous digging into how the business actually operates today, where data really lives, which integrations are genuinely critical, and what the organization needs to become before a single vendor is invited to present.
They also keep process design and system selection separate. When organizations treat the two as the same thing, system capability ends up shaping process design rather than the other way around, and that is a reversal that costs far more to fix than to prevent.
This is the foundation of Flovio's approach. We prepare organizations for complex system renewals by building the process and business architecture that technology decisions should be based on. In practice this means process modeling, end-to-end architecture work, data and integration requirements, and the organizational preparation that allows implementation partners to do their best work, on time and without expensive surprises.
"It's always a pleasure to start our work from Flovio's deliverables."
Three questions worth sitting with
Do we have a leadership-owned picture of your future operating model, independent of any vendor's reference models?
Not a vision statement. A genuine, grounded understanding of how your organization must function differently to succeed in the long term.
Have we modeled our complexity honestly, including the parts that are inconvenient or politically sensitive?
What is not surfaced in planning resurfaces in implementation.
Are we treating this as a business transformation that uses technology as an enabler, or as a technology project with a change management workstream attached?
This answer will determine more about your program's trajectory than any other single factor.
Courage before configuration
The organizations that succeed are not the ones with the largest budgets or the most prestigious partners. They are the ones willing to face their own organization honestly its history, its accumulated complexity, its inconvenient truths before committing to a technological path.
The technology was never the hard part. The willingness to be honest about your current state and clear-eyed about where you are heading, without flinching, is what separates the transformations that land from the ones that stall.
Brené Brown says: Clear is Kind. In the same spirit the most precious gift a leadership team can give their organization is an unpolished portrait of where they are starting from.
FAQ
Frequently asked questions
Why do ERP programs fail?
- Most ERP programs do not fail because of the technology. They fail because the organisation never built an honest, shared picture of how it actually operates before configuring the system. The implementation then encodes assumptions that do not match reality, and the gap surfaces as cost, delay, and resistance.
Is ERP failure a technology problem or a process problem?
- It is overwhelmingly a process and organisational problem. Modern ERPs are highly capable; the binding constraint is how well leadership understands its own processes, decisions, data, and exceptions. Without that understanding, no platform SAP, Oracle, Dynamics, or otherwise can compensate.
What should a company do before starting an ERP project?
- Establish a clear, unromanticised view of current operations: end-to-end processes, the decisions inside them, the data they depend on, and where the real exceptions live. Align leadership on what the new system must change and what it must preserve. This baseline is what makes scoping, configuration, and change management tractable.
How do you reduce ERP implementation risk?
- Treat the program as a process and capability transformation that happens to involve software. Invest in process clarity early, govern scope against that clarity, keep data quality work tied to the processes that use the data, and resist the urge to defer hard organisational decisions to go-live.
What does 'clear is kind' mean in an ERP context?
- It means giving the organisation an honest portrait of where it is starting from including the parts that are messy instead of an idealised vision. Clarity at the start prevents the painful, expensive course corrections that show up mid-implementation.
Dr. Katariina Kemppainen
One of Finland's sharpest voices on process intelligence and the operational foundations for the AI era. With a PhD in Operations Management from Aalto University and over two decades across academia, global corporations and entrepreneurship, Katariina believes processes are the user interface to AI. Without world-class processes, intelligence lacks the context and direction it needs to create lasting value.
All essays by this authorFree briefing · PDF
Take the executive checklist with you.
The ten pitfalls above, plus an eight-question diagnostic you can run with your steering committee. Email it to yourself in one click.
Read next