One Owner Per Data Domain, Named — Or Three Versions of Every Number

There are four records for the same customer. One says Al Noor Trading LLC, one says AL NOOR TRADING L.L.C., one says Al Noor Trdg, and one is a walk-in account somebody used in a hurry three years ago and never closed. Three of them have open balances. The credit limit sits on one of them.

Everybody in the building knows this. Somebody has raised it in a meeting. It has been agreed that it should be cleaned up. It has been agreed at least twice.

The reason it has not been cleaned up is not that the work is hard — a competent person could deduplicate that list in a fortnight. The reason is that on the day after the cleanup finishes, a salesperson will need an account for a customer whose trade licence has not arrived, will find that the form now demands a licence number, and will phone somebody who can make the field go away. Unless there is a named person whose answer is no, the field goes away, and the list starts decaying again from a cleaner starting point.

That is the whole subject. Master data quality is not a data problem and it is not a software problem. It is an authority problem, and it is one of the specific findings an independent system audit produces most reliably, because it is visible from the outside in a way it is not from the inside.

What master data is, and what it is not

Worth being precise, because the word gets applied to everything and then means nothing.

Master data is the small set of records that other records point at. Customers, suppliers, items, the chart of accounts, employees, projects, warehouses, units of measure, tax codes. They are nouns. They persist. They are referenced by thousands of transactions and they are created by a handful of people.

Transactional data is the events: the invoice, the goods receipt, the timesheet, the payment. It is high volume, it is created by everybody, and it is mostly self-correcting because somebody is looking at it — an invoice for the wrong amount gets disputed by the customer within the month.

The asymmetry is the point. A wrong invoice is one wrong invoice. A wrong customer record is wrong on every document that will ever point at it, forwards and backwards, and nobody disputes it because nobody is looking at the master record. Which is why the effort of governing master data is worth spending, and why the same effort spent on transaction validation buys much less than it feels like it should.

Why "everyone owns it" is the same as "nobody owns it"

The usual arrangement is that master data belongs to whoever needs it. Sales creates customers, purchasing creates suppliers, the warehouse creates items, finance creates accounts. This is not a stupid arrangement — those are the people with the knowledge — and it fails for a structural reason rather than a behavioural one.

Everyone who creates master data is under pressure to do something else. The salesperson is not creating a customer record; they are trying to raise a quotation before the end of the day and the system will not let them until a customer exists. The customer record is an obstacle between them and their actual job. Every field on it is a tax.

So they enter the minimum that gets past validation. If validation is loose, the minimum is very small. If validation is tight, they find the account somebody else created, or the walk-in account, or they phone somebody who can loosen it. None of that is misconduct. Every one of those responses is the rational act of a person doing the job they are measured on.

Which means the decay rate of your master data is set by two things: how much friction the creation process imposes, and whether the friction can be removed by asking. The second one is the important one, and it is the one that is never written down.

Owner, steward, custodian — and only one of them matters

Data governance material draws a three-way distinction, and it is worth knowing which of the three you are actually short of, because organisations usually have two.

The custodian is IT. They run the database, the backups, the access control. Almost every company has this and it is almost never the gap.

The steward is the person who does the work: merges duplicates, fixes the classification, chases the missing trade licence, runs the exception report. Many companies have someone doing this, often unofficially, often the person who is best at exports.

The owner is the person who decides the rules and is allowed to say no. Which fields are mandatory. What the naming convention is. Who may create a record at all. Whether an exception is granted. This one is usually missing, and it is the only one of the three that changes the decay rate — because the steward is cleaning up behind a process that keeps producing the same mess, and the custodian is faithfully backing it up.

The test for whether you have an owner is not whether a name appears on an organisation chart. It is this: in the last six months, who refused a request to bypass a master data rule, and what happened next? If nobody can produce an instance, you do not have an owner. You have a steward and a hope.

The rules that are actually worth having

Most master data policies fail by being too long. They specify everything, so nobody reads them, so nothing is enforced, so the policy is evidence of intent rather than a control.

Four rules per domain, roughly, is what survives.

Who may create a record. The smallest useful control on this list, and the least popular. Restricting creation to a named few converts a decay problem into a queue problem, and a queue is manageable in a way that decay is not. It works only if the queue is fast; a two-day wait for a customer account produces the walk-in workaround within a week and you are worse off than before.

Which fields are mandatory and which are conditionally mandatory. The distinction is what makes the rule survivable. A trade licence number is mandatory for a credit customer and not for a cash sale. A tax registration number is mandatory before a taxable invoice can be raised, not before the record can exist. Rules that ignore the legitimate exception get bypassed at the exception, and the bypass becomes the path.

The naming convention, written as examples rather than as prose. Al Noor Trading LLC, not Rules for the capitalisation of legal suffixes. Somebody entering a record at four in the afternoon will match a pattern. They will not parse a paragraph.

What happens on the exception. The rule that is missing everywhere. There has to be a defined way to create a record that does not meet the standard, with an approval, a flag on the record, and something that chases it. A customer created without a trade licence is fine if the record knows it is incomplete, somebody is told, and the sale cannot progress past a defined point until it is fixed. Without that path, the exception is handled by weakening the rule for everybody.

That last one is where most policies die, and it is the same failure mode as an approval process people route around: a control with no legitimate exception path does not get obeyed, it gets circumvented, and the circumvention is invisible.

Ownership is per domain, not per department

One person cannot own all master data in a mid-market company, and appointing a Data Owner as a title produces someone with responsibility for everything and authority over nothing.

Assign per domain, and assign to the function that carries the consequence of it being wrong rather than the one that creates it most often.

Note the first row. Customers are created by sales and owned by finance, and that separation is the whole point: the person who benefits from the record existing quickly is not the person who decides what it must contain. Where sales owns the customer master, the mandatory fields erode within a year, and the erosion is entirely reasonable at every individual step.

The counter-argument — that finance does not know the customer well enough to enter the record — is correct and is not an objection. Sales still enters it. Finance decides what the form demands and holds the exception approval. Creation and ownership are different verbs.

Why the cleanup project does not hold

Most companies attack this as a project. Buy a week of somebody's time, deduplicate the customer list, standardise the item codes, close the dead accounts. It works. The list is genuinely better on the last day.

Then it decays, and it decays at exactly the rate it decayed before, because nothing that produced the decay was changed. Eighteen months later somebody proposes the project again, and the second proposal is harder to fund than the first because the first one visibly did not last.

The order that works is the reverse of the intuitive one. Fix the creation process first, then clean up. A clean list feeding a broken process is a temporary condition. A governed process feeding a dirty list improves monotonically, because every new record is right and the old ones get fixed as they are touched.

This is also the honest answer to when a migration should happen. Master data cleaned during an implementation is cleaned at consultancy day rates, under time pressure, by people who do not know which of the four Al Noor records is the real one — which is one of the specific reasons a company can be ready for an ERP in every way except this one, and should spend six months on it before signing anything.

The measurements that tell you whether it is working

Four numbers, none of them requiring software you do not have.

Duplicate rate. Count records that are probably the same entity, expressed as a percentage of the master. Measure it monthly. The number matters less than its direction.

Completeness on the fields that carry consequence. Not all fields — the ones that stop something. Customers without a tax registration number. Items without a valuation method. Suppliers without bank details verified. A completeness figure across every field is a vanity metric because it averages the important with the decorative.

Exception volume. How many records were created outside the standard last month, and how many of those are still incomplete. A rising number means the rule is wrong or the queue is slow, both of which are fixable. A zero means nobody is using the exception path, which means they are using a different one.

Time to create. How long from a request for a new customer to a usable record. This is the number that predicts every other one, and it is the one nobody measures. If it is two days, you will have walk-in accounts. If it is twenty minutes, you will not.

That last point generalises. Master data discipline is not sustained by the seriousness of the policy; it is sustained by the creation process being fast enough that nobody needs to go around it.

What this does not fix

Ownership of master data settles what a record must contain. It does not settle which system's copy of that record is authoritative when three systems hold one, and that is a different decision with a different answer — the one that has to be made before any integration is designed, because an integration built without it copies a disagreement rather than resolving it.

Nor does it fix the report that disagrees with the other report. A named owner per domain removes one of the two causes: the version of the number that differed because the underlying records differed. The other cause is that the two reports define the number differently, which is how a dashboard starts confidently lying to you with perfectly clean data underneath it.

The short version

Master data decays because creating it is an obstacle to somebody's real job, and every shortcut taken is individually reasonable. Cleaning it up without changing that is a project that has to be repeated.

You almost certainly have a custodian and a steward. What you are missing is an owner: a named person, per domain, who sets the rules and has refused a request in the last six months. If you cannot name the refusal, the rules are preferences.

Assign ownership to the function that carries the consequence rather than the one that does the typing, keep the rules to about four per domain with a real exception path in them, and measure the time it takes to create a record — because that number, not the policy, decides whether anyone follows it. Where the ownership question is genuinely unanswerable from inside, an independent read of the systems usually finds that the answer already exists and has simply never been said out loud.