Data Governance: The Foundation of Scalable Growth

Data governance in an SME is not a policy document. It is four decisions: who owns each set of records, what a correct record looks like, who may change one, and what happens when two systems disagree. Make those four and most data problems stop recurring. Skip them and every system you buy inherits the same mess.

This page covers why growth exposes the problem, the four decisions, what to do about systems that disagree, and how much of this an SME actually needs.

Why does growth expose this?

Because informal ownership scales badly.

At eight people, everyone knows that Jen maintains the customer list and that the price file in the shared drive is the real one. Nothing is written down and nothing needs to be. At thirty people across three teams, that knowledge is no longer shared, and the same questions get answered differently depending on who is asked.

The visible version is two reports that disagree. The underlying version is that two people both believed they owned the number, and neither was wrong.

Acquisitions accelerate it. A second entity arrives with its own customer list, its own product codes and its own idea of what a completed order means. Consolidating the ledgers is the easy part. Agreeing what a customer is takes longer.

The four decisions

1. Who owns each set of records. One named person per domain: customers, products, pricing, suppliers, employees. Not a committee and not a department. The owner is who decides, not who types.

2. What a correct record looks like. Which fields are mandatory, what format they take, and what the record may not be created without. This is the one that prevents most problems, because it is enforceable in the system rather than in a reminder.

3. Who may change one. Creating a customer and changing a credit limit are different acts. Most SMEs give everyone both, then discover a discount was applied permanently rather than once.

4. What happens when systems disagree. Name the system of record for each domain, in advance. When the CRM and the ledger disagree about a customer's address, one of them wins by prior decision rather than by whoever is in the room.

Four decisions, an afternoon, and they outlast whatever software you are running.

What does this look like inside Odoo?

Mostly configuration, which is the point.

• Required fields and formats per model, so an incomplete record cannot be saved rather than being cleaned later.
• Access rights by role, separating who can create from who can approve, with record rules where a team should only see its own.
• Audit trail on the fields that matter. Odoo tracks changes to flagged fields with who and when, which answers most disputes without an investigation.
• Archiving rather than deleting, so a superseded record stays searchable and stops appearing in everyday lists.
• One catalogue across companies, shared where it should be shared, so a group is not maintaining four versions of the same product.

None of this is exotic. It is ordinary configuration that usually gets skipped because it is nobody's job during an implementation.

How much governance does an SME actually need?

Less than the term implies.

A thirty-person business does not need a data governance framework, a steering group or a maturity model. It needs the four decisions written on one page, the mandatory fields set in the system, and someone to notice when a new system arrives without an owner.

What is worth adding as you grow:

• A review when a new system is bought. Which domain does it own, and which system of record does it defer to?
• A retention position. How long records are kept and what happens at the end, which matters for privacy obligations and for keeping the database usable.
• A check at onboarding and offboarding. Access granted by role on day one, and removed on the last day.

For businesses pursuing certification, the same decisions do double duty. ISO 9001 wants documented control of records, which is the four decisions written down. See ISO 9001.

Where does this sit relative to a migration?

Before it, and it is the cheapest time to do it.

A migration forces the questions anyway: which customer record is real, what a product code means, who decides. Doing it deliberately turns a painful part of the project into a decision log you keep afterwards. Doing it by default means the answers get improvised under deadline and forgotten.

The practical sequence is to settle ownership first, then clean, then load. Cleaning without ownership produces a clean list that degrades again within a year. See Clean Data, Clean Start for the cleaning itself.

How we work

Ooda Consulting is based in Sydney at Level 6/201 Kent St and works with SMEs across Australia and New Zealand. The Australian team scopes the work and supports it afterwards, with a dedicated senior developer doing the build.

See Data Governance for how we run this, or Odoo ERP Implementation for where it sits in a build.

Frequently asked questions