Master Data: The Quiet Error Source That Looks Like a System Problem

The symptom

The sentences sound the same in every business. "You can't rely on the stock figures." "The material requirement is never right." "We have the system, but we check it in Excel anyway."

This usually turns into a discussion about the system. The ERP is too old, too rigid, badly implemented; a replacement gets evaluated, quotes come in. What almost nobody does at this stage: take a sample of fifty articles and check the stored master data against reality.

Those who do generally find the same thing. The system is calculating flawlessly. It is simply calculating with lead times, minimum stock levels, bills of material and routings belonging to a business that stopped existing five years ago.

The mechanism

Master data has an awkward property: it is created once, and after that only touched when something goes wrong. There is no occasion to maintain it, because an out-of-date value doesn't announce itself — it quietly produces a slightly wrong answer.

Four field types run off the rails with particular reliability.

Lead times. When the article was created, whatever the supplier said at the time was entered. Since then the supplier has changed, the quantity has changed, the supply chain has changed. The value sits unaltered in the system and drives every reorder suggestion.

Minimum and reorder levels. Usually set once by instinct, often in a quieter year. They determine when capital gets tied up, and they are effectively never revisited.

Bills of material. Engineering changes reach the shop floor before they reach the system. Production works from the current revision; the system costs from the old one. Both are convinced they are right.

Routings and standard times. The same story as changeover times: established once, carried forward thereafter.

The real damage comes from a feedback loop. Because the results aren't right, someone checks them — in a spreadsheet of their own. That spreadsheet becomes the working basis. Which further reduces any reason to correct the master data, since nobody is using it anyway. After two years there are two parallel truths, and the maintained one is unofficial.

The cost

An anonymised example, altered in detail, real in pattern. A technical wholesaler with around 9,000 active articles was facing an ERP replacement. The justification: unreliable reorder proposals, stock levels too high and stockouts too frequent at the same time. The budget for the replacement was around €380,000 over two years.

Before the decision, a sample of 200 A and B articles was checked against actual delivery times over the preceding 18 months. The result: for 63 per cent, the stored lead time deviated by more than five working days from the measured reality — in both directions. For 31 articles, the stored value belonged to a supplier that hadn't shipped for over two years.

The effect was exactly the double picture described above: understated lead times produced stockouts, overstated ones produced excess stock. Both at once, in the same warehouse, from the same cause. Capital tied up in articles with inflated lead times came to roughly €210,000.

A new ERP would have inherited that data. It would have processed it wrongly, faster and more attractively.

The fix

The ERP replacement wasn't cancelled, but deferred — and a data project was run first, over three months, at a fraction of the cost.

First, lead time stopped being maintained and started being measured: derived from the actual purchase order and goods receipt records of the previous 24 months, per article and supplier, using the median rather than the mean. This could largely be automated, because the data was already there — it had simply never been analysed.

Second, every critical master data field was given an owner and a review interval. Not as a guideline, but as a dated task assigned to a named person.

Third, a simple deviation alert was set up: where the real delivery time on a goods receipt differs materially from the stored value, a task is created. The master data now maintains itself in the course of normal operations.

After six months, stockouts had fallen substantially and inventory was down by around €140,000. Whether the ERP replacement is needed at all is now being discussed rather differently.

The pattern travels: a system is only as good as the data it calculates with — and you check that before you replace the system. That sequence is part of a process analysis. Fixed scope, fixed duration, fixed price.

The next step

Pull twenty of your most important articles and compare the stored lead time against the last five real goods receipts. If more than a handful deviate significantly, you don't have a system problem.