Almost every ERP business case promises a single source of truth. Considerably fewer programmes deliver one. The software goes live, the modules are configured, training is completed — and the finance team still maintains a parallel spreadsheet, because the numbers in the system are not the numbers they trust.

In our experience the cause is almost never the platform. It is that three questions were left unanswered while the implementation proceeded regardless.

1. Who owns each data object?

A customer record exists in sales, in finance, and in support. Before go-live, exactly one function must own its definition and be accountable for its accuracy. Where ownership is shared, it is effectively absent, and the record diverges within weeks of launch.

This is an organisational decision, not a technical one, and it cannot be delegated to the implementation partner. What a partner should do is force the question early and refuse to configure around an unresolved answer.

2. Which processes are you standardising, and which are genuinely differentiated?

The instinct to replicate existing processes in the new system is the most reliable predictor of cost overruns. Every deviation from standard platform behaviour carries a permanent tax: it must be retested at each upgrade, documented for every new joiner, and maintained by someone who understands why it exists.

The discipline worth applying is straightforward. A process qualifies for customisation only if it is a genuine source of competitive advantage or a hard regulatory requirement. Everything else adopts the standard flow, even where that means changing how people work.

  • Differentiated: a pricing model that reflects a commercial arrangement no competitor offers.
  • Regulatory: statutory reporting formats or tax treatment specific to your jurisdiction.
  • Neither: an approval sequence that exists because a former manager preferred it that way.

3. How is migration sequenced?

Migrating everything simultaneously maximises risk at exactly the moment your team has least familiarity with the system. Migrating one function at a time extends the period of dual running and integration overhead. Neither is universally correct, but the choice should be explicit and made on the basis of transaction volume and reconciliation burden — not scheduling convenience.

Where we generally advise starting: the function whose data quality is already strongest. It builds confidence, surfaces integration issues while the stakes are low, and gives the wider organisation a working reference implementation to reason about.

What good looks like at go-live

A useful test is whether the shadow spreadsheets disappear. If a department is still reconciling the system against its own records three months after launch, the programme delivered software but not a single source of truth. That gap is recoverable, but it is considerably cheaper to prevent than to remediate.

We implement ERP and CRM platforms as a certified Odoo partner and on other platforms where they fit the operation better. In either case the sequence above matters more than the badge on the software.