Master Data Governance: One Version of the Truth
Ask two departments for "the customer list" and you will get two different answers. One customer appears three times with slightly different names; a supplier has two codes; half the items have no unit of measure. This is the master data problem, and it quietly corrupts every report, price and delivery built on top. Master data governance is the discipline of keeping shared reference data correct, complete and unambiguous — one version of the truth that every system can trust.
What counts as master data
Master data is the relatively stable, widely shared core that transactions reference: customers, suppliers, items and materials, organizational units, employees, warehouses, chart of accounts. It changes slowly, is read by many systems, and gets copied everywhere. That combination — slow change, wide read, frequent copy — is exactly why it rots: nobody owns it, so everybody bends it.
Rule 1: One write path
The single most effective rule: each master entity has exactly one authoritative system and one create-and-modify path. Customer masters are created only in the CRM, items only in the ERP, org structure only in the HR system. Every other system receives copies, read-only. The moment a second system gains write access, divergence is guaranteed and reconciliation becomes a permanent tax. If the business truly needs two creation points, put a registration service in front that issues the canonical ID.
Rule 2: A named steward per domain
Technology cannot decide whether "ABC Ltd" and "ABC Limited" are the same company. Assign a human steward to each domain — customer, supplier, item, org — with the authority and the tooling to approve merges, reject duplicates and set naming standards. Stewardship is a part-time role for the person who actually uses the data daily, not a distant data-department function.
Rule 3: Quality as measured metrics
"Improve data quality" is unactionable; a dashboard is not. Pick a handful of dimensions and measure them monthly:
- Completeness — what percent of customers have a tax ID, a real address, an assigned owner?
- Uniqueness — how many near-duplicates does the fuzzy matcher find per thousand records?
- Consistency — do the ERP, CRM and portal agree on the same attribute values for the same ID?
- Timeliness — how long does a correction take to reach every downstream copy?
Post the numbers where the stewards see them. What gets measured gets budget.
Rule 4: Governed distribution
Copies are unavoidable, so make them flow through one governed channel: the owning system publishes change events or scheduled snapshots; downstream systems subscribe and never write back. Use the integration pattern that fits each consumer's latency need — events for milliseconds, batch for overnight. Every copy carries the canonical ID, so reconciliation is a join, not a detective story.
The migration you cannot skip
Governance written on top of a dirty master stays dirty. Budget an explicit migration phase before the rules go live: merge obvious duplicates, backfill the critical fields, retire codes that point at nothing. This cleanup is unglamorous and usually larger than expected, but it is the difference between governance that holds and governance that is quietly abandoned within a year.
The order matters less than the commitment: each rule only works because the others hold. A single write path with no steward becomes a bottleneck; metrics with no distribution channel become trivia; distribution with no quality gate becomes a well-organized copy of bad data.
Conclusion
Master data governance is not a one-time cleanup; it is a set of standing rules: one write path, a named steward, measured quality, governed distribution. Get those four right and every downstream report stops being a negotiation. And since portals, documents and workflows all consume master data, governance is also the quiet prerequisite for a document and knowledge base that can be trusted.