Odoo ERP Implementation for Manufacturing
Manufacturing is the hardest ERP implementation to get right, and the reason is not the software. It is that a factory has a physical reality the system has to match, and a discrepancy that would be a rounding error in a trading business becomes a production stoppage on a shop floor.
What follows is what tends to go wrong, in the order it usually goes wrong, drawn from the pattern across manufacturing projects rather than from any one of them. If you want the service overview instead, that is on the Odoo for manufacturing page. This is the part people only find out afterwards.
The bill of materials is never as ready as everyone says
Ask a manufacturer whether their BOMs are accurate and the answer is yes. Open them and you find quantities that were right two design revisions ago, components that are no longer bought, scrap allowances carried in somebody's head, and two products that share a sub-assembly recorded differently in each.
None of that matters while production is run by experienced people who know what the drawing really means. All of it matters the moment the system starts issuing material against those numbers, because it will issue exactly what the BOM says.
The honest sequence is to pick the products that make up most of your volume, verify those BOMs against what the shop floor actually consumes, and accept that the long tail gets corrected over the first few months. Attempting to verify everything before go-live is how manufacturing projects slip by a year.
Routings and cycle times get invented
The second problem follows the first. Capacity planning needs work centre definitions, operation sequences and realistic cycle times. When those numbers are not measured they get estimated, and estimates in a factory are optimistic.
A plan built on optimistic cycle times produces a schedule nobody can hit, and a schedule nobody can hit gets ignored within two weeks. After that the planning module is dead weight and the real schedule lives on a whiteboard again.
The alternative is to go live with simple work orders and no capacity scheduling, measure actual times for a couple of months from the system's own records, and switch on planning once the numbers are yours rather than someone's guess. It feels like doing less. It is the difference between a plan that is followed and one that is not.
Opening stock decides whether anyone trusts the system
This is the one we argue about most, and it is not negotiable for good reason. If physical stock and system stock disagree on day one, every material requirement, every shortage report and every costing is suspect. Production asks for material that is not there, or sits idle next to material the system cannot see.
People do not conclude that the data is wrong. They conclude that the system is wrong, and they go back to the register. Recovering from that takes longer than the count would have.
A full physical count, reconciled, immediately before cutover. Raw material, work in progress and finished goods, including the work in progress nobody wants to count because it is halfway through a process. That last category is where the error usually hides.
Work in progress is the part nobody designs
Trading businesses move stock from one place to another. Manufacturing consumes it and creates something else, and the state in between has to be modelled.
Decisions worth making deliberately: whether material is issued to a work order all at once or operation by operation, where partially finished goods sit in the stock structure, how scrap and rework are recorded so the costing stays honest, and whether a quality check blocks a move or merely records a result.
These are configuration choices, not customisations, and they are difficult to change after a few months of transactions. Getting them wrong is the most common reason a manufacturing implementation needs rework later.
Costing comes out different and somebody has to explain it
Most manufacturers cost products in a spreadsheet with a standard overhead percentage. An ERP costs them from actual material consumed, actual time booked and the overhead rule you configured. The two numbers will not agree.
Usually the system is closer to the truth, and that is uncomfortable. Products thought to be profitable turn out not to be, and the finance team has to defend a figure that contradicts years of reporting.
Decide the costing method before go-live, not after — standard, average or FIFO, and how labour and overhead are absorbed. Then expect to spend a session explaining the variance, and keep the old spreadsheet for one quarter so the comparison can be made rather than argued about.
Traceability is cheap to build and expensive to retrofit
If you have lot or serial traceability requirements — food, pharma, automotive components, anything with a recall exposure or a customer audit — configure it from the first day, even if nobody is asking for it yet.
Switching traceability on later means the history before the switch has none, which defeats the point of having it. It is one of the few things genuinely worth building before there is a business case for it.
Training the wrong people
Manufacturing training usually goes to production managers and planners. The people who determine whether the system reflects reality are machine operators, store keepers and quality inspectors — the ones booking material, confirming operations and recording rejections.
If they were not trained, the data is wrong from week one no matter how good the configuration is. Shop floor training in the language people actually work in, at the machine rather than in a conference room, is what decides adoption. Odoo training for that group is not the same exercise as training managers.
A sequence that holds up
- Inventory, purchasing and sales first, with a verified opening count. Manufacturing without trustworthy stock is pointless.
- Simple work orders next — consume material, produce output, record what happened. No scheduling yet.
- Quality checks and traceability, configured at the start if they are ever going to be needed.
- Costing, reviewed against the old spreadsheet for a quarter.
- Capacity planning and scheduling last, on measured cycle times from your own records.
- Maintenance, subcontracting and multi-level assemblies as separate phases after that.
A manufacturer who goes live on steps one and two in eight weeks, and reaches step five in nine months with real numbers, ends up further ahead than one who tried to do all six at once.
Frequently asked questions
Opening stock that was never properly counted. Every material requirement, shortage report and product cost is built on it, so production either asks for material that is not there or ignores material the system cannot see. People conclude the system is wrong rather than the data, and recovering that trust takes longer than the physical count would have.
No, and waiting for that is how manufacturing projects slip by a year. Verify the BOMs for the products that make up most of your volume against what the shop floor actually consumes, and correct the long tail over the first few months. What you cannot do is go live on BOMs nobody has checked, because the system issues exactly what they say.
Usually not. Planning needs measured cycle times, and estimated ones are optimistic, which produces a schedule nobody can hit and which is therefore ignored within two weeks. Go live with simple work orders, let the system record actual times for a couple of months, then plan on your own numbers.
Because the system costs from actual material consumed, actual time booked and the overhead rule you configured, rather than from a standard percentage. The ERP figure is usually closer to the truth, which is uncomfortable when a product thought to be profitable is not. Keep the old spreadsheet for one quarter so the variance can be compared rather than argued about.
From the first day, if there is any chance of needing it. Traceability switched on later has no history before the switch, which defeats its purpose in a recall or a customer audit. It is one of the few things worth configuring before a business case exists for it.
