Before configuration: six decisions that keep an ERP project on track.

Before configuring Odoo, the business and implementation team need an agreed scope, named process owners and clear rules for the records the system will handle. Decisions left unresolved at this stage often return as rework during testing.

The following six questions provide a starting point for the design brief.

1. 01

   What is the source of truth?

   Decide where customers, products, employees, projects, accounts and opening balances will be governed. If two departments can independently create the same master record, reporting will inherit the confusion.

2. 02

   Who owns each process?

   Name the person accountable for sales, purchasing, inventory, finance, projects and HR decisions. A consultant can design a workflow, but the business must decide which rule is correct.

3. 03

   Where is approval actually required?

   Approvals should protect value, policy or risk. Document the amount limits, roles, substitutes and escalation route. Adding approval everywhere usually slows work without improving control.

4. 04

   Which exceptions are legitimate?

   Real operations include partial deliveries, advance payments, urgent purchases, returns and corrections. Agree how those situations should be recorded instead of treating them as side conversations outside the ERP.

5. 05

   Which dimensions must reporting preserve?

   Project, branch, cost centre, department, vehicle or product category may all matter. Decide which dimensions belong on each transaction so management reports do not depend on manual spreadsheet classification.

6. 06

   What is the smallest safe go-live scope?

   Define the users, companies, modules, integrations and historical data required for the first operating cycle. A phased launch is valuable only when each phase is complete enough to run without shadow systems.

Turn the decisions into an implementation plan.

These decisions create a usable design brief. Roles become clearer, master-data templates have an owner, approval matrices can be tested and reports have defined dimensions. The team can then test the agreed rules and handle exceptions consistently.

The practical measure of readiness is simple: a user should know what record to create, a manager should know what they are approving and finance should know how the transaction reaches the ledger. Record these decisions in the design brief and use them as acceptance criteria during testing.