Master data management, explained without the jargon

Most teams know this matters. Fewer have decided who owns it. Here is master data management without the vocabulary that usually surrounds it.

Most data problems are ownership problems that turned into technical ones. It is the sort of thing that looks like polish right up until it costs you an enquiry.

The short version

Two systems with different customer records will disagree at the worst moment. The teams that handle this well are rarely the ones with the biggest budgets. The failure mode is not doing it wrong, it is doing it once and assuming it stays done.

Why people complicate it

Most of the confusion comes from tooling rather than from the idea itself. It is worth being explicit about, because assumptions differ quietly.

Decide which system is authoritative for each entity. There is a version of this that is over-engineered, and it is worth avoiding. If it only works because one person remembers to do something, it does not work yet.

Making it stick

Reconciliation is cheaper than arbitration later. The teams that handle this well are rarely the ones with the biggest budgets. It is worth deciding this deliberately rather than inheriting whatever the last person set up.

In practice

Numbers get quoted in meetings long after anyone remembers how they were calculated. Three things worth confirming about master data management before you move on:

• Someone can say what the current setup is without going to look
• Two systems with different customer records will disagree at the worst moment — and you know whether that is true here
• There is a way to tell whether the last change to this helped

If any of that sounds like a description of your current setup, it is fixable.