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 illustrative example with invented figures. Take a technical wholesaler with around 9,000 active articles that is 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 is around €380,000 over two years.

Before the decision, the business checks a sample of 200 A and B articles against actual delivery times over the preceding 18 months. In the example, for 63 per cent of them the stored lead time deviates from the measured one by more than five working days, in both directions. For 31 articles, the stored value belongs to a supplier that hasn't shipped for over two years.

The effect is exactly the double picture described above: understated lead times produce stockouts, overstated ones produce excess stock. Both at once, in the same warehouse, from the same cause. In the example, capital tied up in articles with inflated lead times comes to roughly €210,000.

A new ERP would inherit that data. It would process it wrongly, faster and more attractively.

The fix

The wholesaler in the example doesn't have to cancel the ERP replacement. It defers it and runs a data project first, over three months, at a fraction of the cost.

First, lead time stops being maintained and starts 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 can largely be automated, because the data is already there. Nobody has ever analysed it.

Second, every critical master data field gets an owner and a review interval. Not as a guideline, but as a dated task assigned to a named person. When you redesign a workflow, write that owner next to every step that reads the field; the article on the to-be process and its data model shows the layout.

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

The example assumes that after six months stockouts fall substantially and inventory is down by around €140,000. Whether the ERP replacement is still needed can then be decided afresh on those figures.

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.