An SME does not usually fail an ERP rollout because it lacks software. It fails because it tries to create order before deciding what “order” actually means.
If the process is unclear, the system will only make it faster.
The thesis is simple: before configuring Odoo, clarify processes, owners, data and exceptions. Otherwise, the company risks digitizing unresolved arguments instead of solving them. That not only makes the launch harder; it also leaves a fragile setup when the team grows or people change.
The real scene: when every department is right
Picture a 25-person SME that sells by phone, prepares orders from the warehouse and buys from several suppliers. The director sees delays. Sales says warehouse confirms too late. Warehouse says sales promises without checking stock. Purchasing says requests change at the last minute. And finance, in the middle, tries to match invoices with delivery notes that arrive incomplete.
This is the moment when many companies look at Odoo as if it were a switch. But Odoo does not decide for the company. It only forces decisions that should already exist: who creates the order, who approves it, when stock is reserved, what happens if an item is missing and which data wins when two screens say different things.
Odoo’s official documentation makes clear that applications and modules have dependencies, that adding or removing apps can affect other apps, and that changes should be tested in a duplicated database before going live. It also notes that the database administrator should understand how the business works. In practice, that means implementation is not “installing a tool”; it is redesigning a way of working. (odoo.com)
The decisions to close before you open configuration
There are four questions worth answering before touching a single module.
1. Who owns each decision. A chart of accounts is not enough. The company must define who approves discounts, who authorizes urgent purchases, who corrects a delivery note and who can change a product record. If this is not written down, the system only amplifies ambiguity.
2. Which data is master. In many companies, the same customer appears under similar names, the same product code changes by channel and units are interpreted differently by sales and warehouse. Before implementation, decide which field wins: internal reference, supplier code, sales unit or packaging. The goal is not purity; it is to avoid three versions of the same operation.
3. Which exceptions really exist. Every company says it has “special cases”. Most are just poorly defined processes. But some exceptions are real: urgent orders, partial deliveries, customers with custom pricing, returns that need technical review or purchases that need approval. If they are not separated from the standard flow, they contaminate the whole process.
4. Which measure proves improvement. Implementing without metrics is decoration. Before starting, choose three simple signals: time from order to confirmation, percentage of orders that need manual correction, and number of cross-team incidents per week. If it cannot be measured, nobody will be able to prove whether the change worked.
The uncomfortable mistake: customizing too early
This is where the uncomfortable decision appears. Many implementations speed up by asking for customizations too soon. The logic sounds practical: “if the system does not fit, we will adapt it.” But often the problem is not the system; it is that the company has not yet described its real process.
Odoo allows you to customize fields, views, automations, reports and approval rules through Studio, and its documentation explains that even that has implications for plans and data models. The temptation is to use that flexibility to cover organizational gaps. Yet the earlier you customize without criteria, the harder it becomes to learn which part of the mess was technical and which part was human. (odoo.com)
A useful rule is this: standardize what should already be the same for everyone; then adapt only what truly differentiates the business. Otherwise, the ERP becomes a mirror of old habits instead of an improvement.
A mini-case: fewer screens, more useful conversations
One SME with a warehouse and phone sales came into implementation with a common problem: each department had its favorite Excel sheet. Sales wanted to promise quickly, purchasing wanted to protect itself, warehouse wanted to avoid rush jobs, and finance wanted to invoice without chasing paperwork.
The team did not start by configuring modules. It started by building three lists: decisions, exceptions and critical data. It discovered that the real bottleneck was not the order itself, but the validation of reserved stock and the approval of urgent requests. It also found that two customer types needed different rules, while 80% of the business could follow a standard flow.
The most useful change was not “more automation”. It was stopping the endless debate over every case as if it were new. From there, the implementation tracked fewer manual corrections, fewer internal calls and more orders confirmed on the first try.
What a company should do this week if it wants to implement well
First, map the real journey of one order from arrival to payment, with the names of the people who touch each step.
Second, list ten frequent exceptions and mark which are legitimate and which are simply symptoms of disorder.
Third, choose three start-up metrics and give each one an owner. Not to police anyone, but to know whether the implementation is bringing order to the operation or merely moving the problem elsewhere.
The uncomfortable question is this: if you implemented Odoo tomorrow, which decision would still have no owner? At Codefuente, that is usually where we begin, because software only works when the company has already decided how it wants to operate.