The importance of process clarity
ERP implementations in large(er) organisations
Why process knowledge is more important than software
Our Flydoo senior consultants, with decades of ERP experience in often complex environments, have advised clients more than once to pause high-visibility ERP projects. Budgets had already been approved, contracts signed, and management indicated they were ready to "go digital". However, the underlying processes are often not suitable for a straightforward transition to the intended new digital goal.
Our experts testify: "ERP only works if your processes are ready for it."
The problem that no ERP can solve
During our many years of ERP implementation projects and assessing readiness to go "integrated", we often discover:
- Unstructured supply chains
- Lack of clear KPIs and vision
- Undocumented workflows
- Automation silos
Unfortunately, the reality here is: ERP is not the cause of chaos; ERP will simply digitise what already exists in this case.
Software is an accelerator
Software amplifies the state of your business:
- Strong processes become stronger
- Weak processes fail faster
Most medium-sized organisations not only suffer from technological shortages — they often also face "alignment gaps".
The right first step
Our advice for larger and more complex environments is simple: map your workflows and standardise what is important. Ensure the involvement of management and then reconsider the implementation of ERP when the organisation is ready.
The golden rule
Frequently asked questions
Why does process clarity matter so much?
Because ERP enforces processes. If processes are unclear, the project either drifts (everyone configures their own version) or stalls (no one can decide). Clarity upfront pays back many times over.
Should we redesign processes or replicate the existing ones?
Both — and in that order. Replicate first to keep continuity, then improve once people are comfortable on the new system. Trying to redesign and migrate at the same time is the classic failure pattern.
Who should own the process design?
The business, not IT or the partner. The partner facilitates, IT enables, but the people who run the process every day own it.
How detailed should the process documentation be?
Detailed enough to configure Odoo, train users and audit later — not so detailed that nobody reads it. One page per process plus a few flow diagrams beats a 200-page binder.
What if our processes are not standardised across entities?
Use the project to converge them where possible, and accept entity-specific variations only with a clear business reason. Unjustified variations are technical debt waiting to happen.