Then someone decides it is time for a real system.
The technical part of that project is rarely what causes trouble. Configuring Odoo for a distributor or a manufacturer is well understood work. The difficulty is that a system needs the same operation performed the same way every time, and the company has never worked like that. Nobody wrote the process down because there is no single process. There are five people doing the same job in five reasonable ways.
Informal processes are not a sign of a badly run company
It is tempting to treat the existing chaos as a failure to be corrected. That framing loses information and it loses the team.
Informal processes usually exist for a reason. A sales manager skips the credit check for one customer because that customer has paid on time for eleven years. A production planner keeps a private sequence because the official one ignores a machine that needs warming up. These shortcuts are compressed experience. Some of them are waste. Some of them are the only thing keeping delivery dates realistic.
An implementation that treats every deviation as an error will produce a system that is technically correct and operationally ignored. The first job is to find out which variations carry knowledge and which are just accumulated habit.
What actually breaks these projects
The system goes live. For two weeks, usage looks reasonable. Then the numbers stop matching reality.
Nobody announced a rebellion. What happened is quieter. The warehouse kept its own spreadsheet because the system takes four clicks and the spreadsheet takes one. Sales agreed a discount by phone and entered it later, or not at all. A supervisor kept the paper log "just in case" during the transition and never stopped.
Now the company has two records of the truth, and the ERP is the less accurate one. At that point managers stop trusting reports, which removes the last reason for anyone to enter data carefully. The project is over even though the software works.
Where the resistance comes from
Resistance is almost never about technology. In our projects it comes from four places.
The first is loss of discretion. A person who could decide things now has to follow a route someone else configured. If that route is worse than their judgement, they are right to resist.
The second is visibility. When work becomes recorded, mistakes become recorded too. People who were previously judged on outcomes are now judged on timestamps. This concern is legitimate and it deserves a direct answer rather than a slogan about transparency.
The third is unpaid effort. Data entry costs the person doing it and usually benefits somebody else, often the finance department. If the person entering the data gets nothing back, they will do it late, badly, or not at all.
The fourth is the knowledge holder. In most SMEs there is one person whose position depends on knowing something nobody else knows. A system that writes down that knowledge reduces their leverage. They rarely object openly. They object by finding problems.
What works
Map how the work is done, not how it should be done. Sit with the people doing it and record the actual sequence, including the exceptions. The gap between the official process and the real one is where the implementation risk lives. This is also the fastest way to find the variations worth keeping.
Standardise where variation costs money, and only there. A company with no standard processes cannot absorb standardisation everywhere at once. Pick the two or three points where inconsistency produces measurable loss: stock accuracy, order confirmation, invoicing. Leave the rest alone until the first set holds.
Let the team see the system with their own workflow before anything is agreed. Abstract discussion about future processes produces polite agreement and no commitment. A configured environment showing their order flow, their product structure and their document templates produces specific objections. Specific objections are what you want. They are cheap to fix before the build and expensive after it.
Make the system give something back to the person using it. If a warehouse operator scans a location and the system tells them where the next pick is, scanning survives. If it only produces a report for the head office, scanning stops. Every mandatory input needs a visible return for the person providing it.
Give each process an owner inside the company. Not a module owner, a process owner. Someone whose name is attached to "how we confirm an order" and who has authority to change it. Without that, every disagreement escalates to the implementation partner, which is the slowest possible path.
Convert the knowledge holders instead of routing around them. Their rules belong in the system, credited to them. A planner who sees their own sequencing logic configured into production scheduling becomes the strongest advocate in the building. Excluded, they become the most effective obstacle.
Set a date when the parallel system stops. Running the spreadsheet and the ERP together feels safe and guarantees failure. Two records of the truth means neither is maintained. Agree the cutover date during the project, not after go live, and make sure someone senior enforces it.
Measure adoption, not go live. Go live is an event. Adoption is a number: how many orders entered on the day they were agreed, how many stock movements recorded within the shift, how many documents created outside the system. Track it weekly for the first two months and the problems appear while they are still small.
How this shapes an Odoo project
In practice this changes the shape of the work more than the configuration itself.
Discovery becomes observation rather than a questionnaire. We look at how documents move today, including the parts that live in messaging apps and paper.
Before any commitment, we build a working Odoo environment configured around the client's actual workflow, using demo or anonymised data. The team clicks through it, argues with it, and tells us what is wrong. This is where the informal processes surface, because people recognise what is missing far more reliably than they can describe what they need.
Rollout is phased by process, not by department. One process moves fully into the system and stays there before the next one starts. A department that half uses the system does not create a reference point for anyone else. A process that is fully inside it does.
After go live we monitor usage, not just uptime. Where a step is being avoided, there is usually a design reason, and it is normally cheaper to change the step than to escalate the pressure on the team.
When to slow down
Some conditions are worth naming before a project starts, because they predict trouble more reliably than technical complexity.
If nobody in the management team can say what the system is supposed to improve, the project has no acceptance criteria and will be judged on feelings. If the sponsor is the IT manager rather than an operational leader, decisions about process will have no authority behind them. If the company is in the middle of a peak season, a merger or a management change, the attention required is not available.
None of these are permanent. They are reasons to fix the sequence rather than push the timeline.
Frequently asked questions
How long does an ERP implementation take in a company with no documented processes?
Longer in discovery, not necessarily longer overall. Most of the additional time goes into observing and agreeing how work will be done. Compressing that stage moves the cost to the rollout, where it is higher.
Should we document and fix our processes before choosing an ERP?
Partly. Enough to know which processes carry the most cost and confusion. Full documentation ahead of an implementation tends to describe an ideal that the system then contradicts. It is usually more efficient to document against a working configuration.
What if our team simply refuses to use the system?
Refusal is normally a symptom. In our experience it points to a step that costs more than it returns, a process owner who was never appointed, or a parallel system that was never switched off. Each of these has a specific fix.
Can AI reduce the effort of standardising processes?
It reduces the analysis and configuration time significantly, which is why we can show a working environment early. It does not decide which variations in your business are worth keeping. That decision requires people who know the operation.
If your processes exist mainly in people's heads and you want to see what they look like inside a working system before committing to anything, that is the conversation we prefer to start with. Contact GetConn.pro