Most ERP projects are approved on a productivity argument. Fewer manual steps, fewer spreadsheets, faster closing, better visibility. The budget is justified by what the system will do once it is live.
Then the system goes live and the productivity gain is smaller than expected, or arrives a year later than promised. The usual explanation is that the software was the wrong fit, or the partner underdelivered. In our experience the more common cause is simpler. The company installed a new system on top of processes that were never changed to match it.
An ERP does not improve a process. It executes one. If the process is unclear, inconsistent between departments, or built around workarounds that exist only because the old tools were weak, the ERP will encode that and run it faster. Speed applied to a flawed sequence produces errors sooner, not fewer.
What an ERP actually asks of a business
Configuration is a series of decisions about how the company works. Which document triggers a stock move. Who is allowed to approve a purchase above a threshold. Whether a production order can start before materials are fully reserved. What happens to a return that arrives without a reference.
Each of these questions has a business answer before it has a technical one. In a well-run implementation, the technical work is mostly the translation of answers that already exist. In a difficult one, the implementation team discovers that the answers do not exist, or that two departments hold different answers and neither has the authority to settle it.
That is the point where implementation timelines begin to expand, and it has nothing to do with the software.
Where implementation time is really consumed
Configuration itself is fast. Odoo is a mature platform with a wide functional footprint, and an experienced team can stand up a working structure in days. What consumes months is the loop that follows.
A process question is raised. It is passed to someone who does not have the authority to decide. It returns as a partial answer. The system is configured against it. Testing reveals that finance and operations understood the answer differently. The configuration is reversed and rebuilt. The same question appears again during user acceptance testing, now with data and integrations attached to it, which makes the correction ten times more expensive than it would have been in week two.
Repeat that pattern across twenty process areas and the project is late by a year, with no single moment where anyone made an obvious mistake.
Delay is not usually caused by hard technical problems. It is caused by unresolved business decisions that surface too late.
Two legitimate directions, one expensive habit
When a company process and the standard system behaviour disagree, there are two valid responses. Configure or develop the system to support the existing process, because the process is a genuine competitive advantage or a regulatory requirement. Or change the process to match the platform standard, because the existing way of working is historical rather than deliberate.
Both are defensible. The expensive habit is deciding neither, and letting the conflict travel through the project until it becomes a customisation request during go-live preparation.
Companies that finish on schedule tend to do the same thing early. They separate the processes that make them distinctive from the processes that are simply inherited, and they accept the standard everywhere in the second group. That single decision removes most of the customisation backlog before it forms.
Signals that process change is lagging behind the system
You can usually see the gap before it affects the schedule. Watch for departments describing the same workflow in incompatible terms during workshops. Watch for approval rules that exist in policy but are routinely bypassed in practice, because the system will enforce the policy version and users will immediately treat that as a defect. Watch for master data that cannot be cleaned because nobody owns it. Watch for a project where every process question is escalated to one executive, which means no process owner has real authority.
Watch, above all, for a project plan that contains a detailed technical track and nothing on the business side except a training week before launch.
Running the two tracks together
Process change and system configuration have to advance in parallel, with the business track slightly ahead.
In practice this means naming an owner for each process area who can make binding decisions without escalation, and giving that person the time to do it. It means recording decisions in writing as they are made, so that the same question is not reopened three times. It means fixing master data ownership before migration rather than during it. And it means training people on the new way of working, not on where the buttons are, because a user who understands the intended process can navigate an unfamiliar screen while a user who only memorised screens will recreate the old workflow inside the new system.
The goal is that on the day the system goes live, nothing about how the company works is a surprise to the people using it.
Read more in our blog
Building AI agents is turning into an organisational design problem
Why we build a working prototype before the contract
Most of what is described above depends on making conflicts visible while they are still cheap to resolve. That is difficult with documents. Requirement specifications and process diagrams are read by people who interpret them differently, and the disagreement stays hidden until the system is built.
A working prototype removes that ambiguity. We build a live Odoo instance populated with realistic data for the client's industry and workflow, and the client clicks through their own process before any development contract is signed. Conflicts appear immediately. An operations manager sees that the approval step they described does not match what their team actually does. A finance lead sees that a document flow they assumed was standard requires a decision nobody has made. Those discoveries arrive in the first weeks, when changing the answer costs a conversation rather than a change request.
The prototype is also an honest test of readiness. If a company cannot describe its process well enough to recognise it in a working system, the problem is not the ERP selection. It is a process that needs definition first, and it is far better to learn that before the budget is committed.
The practical conclusion
ERP delivers productivity when the business process and the system design are decided together and on time. The software is capable of far more than most companies extract from it, and the gap between capability and result is almost always filled by decisions that were postponed.
Before choosing a platform or a partner, ask which of your processes you intend to keep, which you are willing to change, and who has the authority to decide. Then look at a working system and check whether those answers hold. That sequence is the difference between an implementation measured in months and one measured in years.
Contact Us
We'd love to hear from you! Whether you have questions, feedback, or need support, our team is here to help. Simply fill out the form below, and we aim to respond to all inquiries within 24 hours. Thank you for getting in touch!
Inquiries Regarding the Subject
Only marginally. An ERP executes a process, it does not design one. If the sequence of steps stays the same, the system replaces the tools you use to perform those steps and little else. The measurable gains come from removing duplicate entry, unclear ownership and reconciliation work, and each of those is a process decision before it is a configuration setting.
Neither extreme works well. A full redesign before implementation tends to produce documents that the system then contradicts. Leaving everything until the project starts pushes decisions into the build phase, where changing them is expensive. The practical approach is to decide the structural questions first, such as ownership, approval authority and master data rules, and refine the detail against a working system.
More than most clients expect. Configuration work is predictable and can be planned. What varies is how quickly business questions are answered and how often answers are reversed. A project where process owners decide within days runs on schedule. A project where every question waits for a monthly steering meeting will extend regardless of how fast the technical team works.
When the process is a genuine source of advantage, or when law, industry regulation or a customer contract requires it. Fiscal reporting, certification records and client-specific logistics rules usually qualify. A process that exists because a previous system could not do it another way usually does not. Separating the two groups early removes most of the customisation backlog before it forms.
One named owner for each process area, with the authority to make a decision binding on their department and the time allocated to do it. If every question is escalated to the CEO, the project has no process owners, only reporters. Decisions should be recorded in writing as they are made, so the same question is not reopened during testing.
Departments describing the same workflow in incompatible terms. Approval rules that exist in policy but are routinely bypassed in practice. Master data that cannot be cleaned because nobody owns it. A project plan with a detailed technical track and nothing on the business side except a training week before launch. Each of these predicts rework later.
No, and it is the normal starting position for an SME. Undocumented is different from undefined. The risk is not the missing document, it is the case where two departments would answer the same question differently and nobody has noticed. Working through a live system surfaces those cases faster than a documentation exercise, because people recognise their own work when they see it running.
It converts abstract requirements into something people can test. We build a live Odoo instance populated with realistic data for your industry and workflow, and your team clicks through their own process before any development contract is signed. Mismatches between the described process and the real one appear in the first weeks, when resolving them costs a conversation rather than a change request.
Review where the previous project stalled before selecting a platform again. In most cases the breakdown appears at the point where a business decision was needed and no one had the authority to make it. Fixing ownership and decision speed matters more than changing vendor. Seeing a working system before committing budget also removes the gap between what was promised in a demo and what was delivered.