MDM versus the ERP zoo and local spreadsheets

When a BI project fails to deliver, the first impulse is to change the tool. Buy a different platform, hire a different analyst, commission a different dashboard. I have watched this cycle repeat three times in a row inside the same company.

The problem is almost never the tool. The problem is that the same data carries different names in different systems, is calculated differently, and shares no common key. Dirty master data breaks any BI, regardless of how good the tool is.

What master data is and why it matters more than the dashboard

Master data is the reference layer that connects everything else. Counterparties, products, warehouses, employees, cost categories. If an ERP records a supplier as "Acme Ltd.", the procurement spreadsheet calls it "Acme", and the accounting system has it as "Acme Ltd. (primary)", then analytically those are three different objects.

No BI tool fixes this automatically. It will faithfully produce three rows where there should be one.

Master data management - MDM - is the discipline that answers: who is the source of truth for each reference table, how do changes enter it, and how do other systems receive the current version.

What a typical zoo looks like

In a company with several systems, the picture tends to be this:

• The ERP holds the "official" supplier directory, but adding records is inconvenient, so part of the operations happen around it.
• The CRM maintains its own customer list, which does not synchronise with the ERP, or syncs once a day.
• The sales team keeps a live price list in Excel because updating the ERP takes three days.
• The warehouse uses its own product codes that do not match the manufacturer codes or the codes in the finance system.

When an analyst tries to build an end-to-end report - say, margin by product including logistics - they spend 80% of the time reconciling these discrepancies. And the result still needs to be explained at the meeting with caveats.

Why spreadsheets become part of the architecture

Local spreadsheets do not appear because people are lazy. They appear because the system does not give them the flexibility they need at the moment they need it. A spreadsheet is a fast way to meet a real need.

The problem is not the spreadsheet itself. The problem is that six months later that spreadsheet becomes the source for other spreadsheets, then for reports, then for decisions. When the person who built it leaves the company, the understanding of how it works leaves with them.

Spreadsheets should not be banned. The right question is: what real need are they meeting, and how do you build a managed process for that need.

What proper MDM delivers

When reference data is centralised and governed:

• every report counts against the same objects, regardless of which system it comes from;
• changes to reference tables propagate across all systems predictably;
• data from different periods can be compared without first spending time "aligning" it;
• new systems connect to an existing reference layer instead of creating their own copies;
• analysts work with data rather than with the cleanup of data.

MDM does not require a separate expensive product on day one. Often it is enough to designate an owner for each reference table, describe the change process, and create one table that everyone trusts.

A practical test

Before buying the next BI tool or commissioning another dashboard, I suggest answering a few questions:

1. Who in the company owns the supplier directory? The product directory?
2. If the same supplier has been entered in two different systems, how is that discovered?
3. When an analyst builds a sales report, which system is the product list taken from?
4. If two reports show different numbers, is there a clear rule for which one to trust?

If these questions have no clear answers, the problem is not the dashboard. The problem is that the data is not yet ready to serve as a source for analytics.