ERP systems

Standard while it holds, custom where it counts

Odoo covers a great deal, and every custom module is code to maintain at each upgrade. The rule is simple: customise where the process is the company's competitive advantage, stay on the standard everywhere else.

When customisation is needed it lives in separate, versioned modules rather than edits to the core: that is what keeps the door open to future upgrades.

The numbers you actually decide on

Analytical accounting is the part that pays off most: once costs attach themselves to the job, the site or the product line, margin stops being a year-end estimate and becomes something you watch while the work is still running.

For that to work the data has to be born already assigned — from the phone of the person on site, from the document coming in, from the shift recorded — not reconstructed afterwards from memory.

Go-live without stopping the work

Separate environments for testing and production, database templates to start from a proven configuration, data migration rehearsed several times before the real day, and a way back if something doesn't add up.

On go-live day nobody has to learn everything: you start from the flow that matters most and add the rest once the first one really runs.

What "configuring" Odoo actually means

Between installing the product and having it useful lie dozens of decisions no manual takes for you: what your categories are called, which states an order passes through, who may approve what, which fields are mandatory and — above all — which are not.

This is where the project is won or lost. A well-configured system feels bespoke while being standard; a badly configured one forces people into workarounds that, six months later, have become the real process.

Our rule: every mandatory field must have someone downstream who uses it. If nobody reads that data, the field is simply slowing thirty people down every day.

When a custom module is warranted

A module is written when your way of working is a competitive advantage and the standard would force you to give it up. Not when a screen is disliked: that is solved by configuration, at a hundredth of the cost.

The module lives separately from the core, with its own lifecycle and its own automated checks. It is the difference between an upgrade done in an afternoon and one postponed for two years until the system becomes an archaeological artefact.

And it carries a maintenance cost that should be stated upfront: every new Odoo version requires checking the modules. A few hours if they are written well, weeks if someone has been inside the core.

Go-live day, and the week after

Go-live is not the finish line: it is the most fragile moment of the project. The first two weeks need someone sitting beside the people working, not a support number — because the real problems are not software errors, they are cases the analysis never saw.

During the same period a short friction list is kept and two items a week are fixed. That is the signal deciding whether the system is used or worked around: people accept an imperfect system that improves, not a perfect one that doesn't listen.