ERP programs begin when you will — but they do not end when you please.
A Machiavelli-inspired perspective helps explain why ERP programs so often disappoint. They follow recurring patterns — almost like their “DNA” — that repeatedly produce the same outcomes. Despite decades of experience, many programs stumble into the same traps:
- Systems that don’t fit business needs
- No clear business objectives
- IT-driven instead of business-driven projects
- Too much customization
- Weak change management
- Poor master data
These issues are well known, yet companies continue to follow the same implementation playbook, and so the results rarely change.
Business vs. System Processes
A central problem lies in the way “process” is understood. ERP projects usually focus on system transaction processes ( transactions) — how orders, invoices, or production postings move through the system. But what really matters are operative business processes — how work is actually done, how value is created, and what rules and practices guide daily operations.
Picture: operative business process vs system process and task to be performed, for example #2 is create order
Because ERP programs emphasize system processes, the real business issues often remain invisible until very late, surfacing in UAT or even after go-live. By then, gaps between system transactions and daily operations have already hardened into expensive problems.
As one Cxx once put it: “Often people limit themselves to (system) process modeling and do not think business modeling — the why, what, how, and where value is created.”
Where Requirements Go Wrong
In ERP programs, business requirements are typically gathered early — often years before implementation and one time event. These lists become inputs for RFX, vendor selection, and project scoping. But in practice, the “requirements” are often just user-reported system pain points or descriptions of existing transaction steps.
This raises a critical question: are the requirements based on business process expertise and value, or simply on how the old system works today?
If requirements are only “transaction checklists”, projects inevitably end up with systems that fail to address real business needs.
A Value-Based Approach
To change the outcome, we must flip the sequence:
- Start with operative processes — how the business actually runs and creates value.
- Define the future state to support strategy — what capabilities are needed to improve performance or avoid opportunity costs.
- Translate those needs into system capability requirements — but accept that ERP may only cover part of the technical landscape. Real operations often depend on multiple systems and integrations. 2020´s Value add business specific “grown jewels” can be done also outside of the ERP, not only as ERP enhancements
This approach turns the focus from “implementing a tool” to supporting how the business operates and grows value. Follow the mindset that ERP is not an IT project; it is a business change project with IT as enabler but not on driver seat
Avoiding the “Dark Time” After Go-Live
The gap between standard ERP and real daily operations often appears only in UAT or early deployments. By then, it’s too late to make meaningful corrections.
Instead:
- Show standard functionalities early to highlight potential gaps.
- Link ERP system processes & capabilities with L3 business process and capability maps, including business rules and differences across units or lines.
- Continuously define and update business requirements — not just once at the start.
- Treat ERP and related tools as modular capabilities, not rigid monoliths. Use them for what they are meant to do, and build value on top where needed.
Closing Thought
ERP projects fail when treated as system exercises, as they often are today, instead of business-led, value-oriented reinvention. Business value doesn’t come from system transactions — it comes from how operations run.”
Or put simply:
“Start an ERP program only if you know how to finish it.” for this you need to take different approach.
0 Comments