Empty shelves, full warehouses: master data as destiny

Garbage master data does one specific thing to a physical supply chain: it produces full warehouses and empty shelves at the same time. The stock exists; the system just does not believe it is in the right place, the right unit or the right price. Two of the most expensive retail failures on record — Target Canada and Haribo's 2018 SAP migration — were, underneath, the same failure. Master data is the instruction set your trucks execute.

Why do full warehouses and empty shelves happen at the same time?

Target Canada is the cleanest case in the record, because the data was wrong on the way in rather than corrupted by a migration. Racing toward launch, the chain loaded roughly 75,000 SKUs into SAP by hand, using merchandising staff who in many cases had never touched the system — the ramp cost of putting green hands on unfamiliar tooling, paid here in corrupted rows instead of slow tickets. Product dimensions, case-pack quantities, units of measure and currencies went in wrong at scale. None of that looks broken. The record saves cleanly and the screen looks fine.

Then the physical system runs on it. A replenishment engine that thinks a case holds six units when it holds twenty-four orders four times too little, or a quarter too much. Distribution centres fill with stock the store system cannot correctly call forward, because a barcode, a pack size or a location will not reconcile. The result was the paradox that defined the collapse: warehouses bursting while shelves sat empty. The chain closed all 133 stores and cut 17,600 jobs, with losses well north of two billion dollars — a business killed, in large part, by fields in a table.

The lesson people take away is "Target expanded too fast." The more useful one is narrower: a physical supply chain is a machine that executes master data literally. It has no judgement and cannot tell that a value is absurd. Bad data is not a reporting problem you tidy up later; it is an instruction the forklift follows.

Wasn't Haribo just a normal ERP migration?

Haribo shows the identical failure arriving through a different door. In 2018 the company moved 16 factories across 10 countries onto SAP S/4HANA in a big-bang cutover. When it went live, logistics and fulfilment broke, and the trademark Gold Bears thinned out of German supermarket shelves during the autumn peak. TechTarget reported a roughly 25% drop in sales tied to the disruption.

Nothing was wrong with the sweets. The factories still made them. What broke was the data plumbing between production, warehouse and dispatch — master and transactional records that did not map cleanly onto the new system's model, so orders could not be fulfilled even though the stock physically existed. The signature is the same as Target Canada: product on one side of a wall, a system that cannot correctly connect it to demand on the other. One arrived through 75,000 hand-keyed rows, the other through a conversion that did not preserve meaning. Two independent triggers, one root cause. That is why master data is the first thing to get right and the last thing anyone budgets for: it is invisible until the trucks are already loaded wrong.

Why is beer the hardest master-data problem of all?

Put a brewer's catalogue through the same machine. A single liquid — one lager — is not one product. It is a matrix of SKU x pack configuration x returnable deposit x market. The same beer ships as a single can, a six-pack, a case, a returnable keg; each pack carries its own unit of measure, its own barcode and its own deposit, and each market layers a deposit scheme, a tax code and a language on top. A top-three global brewer runs tens of thousands of these combinations across dozens of operating companies.

Two things make this worse than flat retail. First, the deposit. A returnable bottle whose master data is wrong is not merely mispriced — it corrupts a two-way physical loop. Every empty that comes back is a liability that has to reconcile against what went out, so a wrong deposit code or unit does not spoil one line item; it unbalances the returnable-asset ledger across the whole estate. Second, the combinatorics multiply the blast radius. In flat retail a wrong case-pack breaks one SKU. In beverage, the same base product wrong at the parent level propagates through every pack, every market and every deposit variant that references it. Get the master right and everything downstream — pricing, replenishment, empties, settlement — has a spine to hang on. Get it wrong and you are Target Canada with a deposit ledger attached.

Why doesn't testing catch it before go-live?

Because bad master data passes every test that is not specifically looking for it. A record with the wrong case-pack or currency is structurally valid: it saves, it displays, it moves through the workflow untouched. It only becomes visibly wrong when a physical process acts on it at volume — which is precisely the thing you do not do until go-live. Conference-room pilots run on clean, curated sample data, the happy path, not the tens-of-thousands-of-rows reality keyed under a deadline. So the defect is real from day one and invisible until the day it is most expensive to find.

This is also why big-bang cutovers are structurally dangerous, and it compounds a base rate that is already unforgiving. As the McKinsey and Oxford study of large programmes shows, big IT projects run 45% over budget and deliver barely half their promised value on average, and a data defect that only surfaces at full scale is exactly the tail risk that turns a disappointing programme into an existential one. The work of finding and fixing those records is invisible in every other way too. It is unglamorous data-quality labour that, like the maintenance load where 42% of engineering time never touches a feature, appears on no roadmap and gets cut first when the timeline tightens — which is how it ends up being discovered by a forklift.

So what is the actual failure mode?

Strip away the retail-strategy narratives and both stories reduce to one sentence: the physical system inherited an instruction set it could not question, and executed it faithfully. Neither company was short of stock, technology or money — both ran SAP, both had warehouses full of product. What they lacked was a guarantee that the values in the master records corresponded to the physical world. The direction out is unglamorous and mostly organisational: treat master data as a product with a named owner rather than a migration task; validate against physical reality — does this case-pack, this deposit, this unit actually exist in the warehouse — not merely against schema; and prove it at real volume on one small slice before betting an estate on it, which is the whole argument for standing master data up as a governed spine on a shared event bus instead of a field buried inside each application.

None of this is a technology problem you can buy your way out of. The tooling to store SKU-pack-deposit-market combinatorics has existed for decades. What changes, year to year, is only the appetite for finding out at full scale. As brewers consolidate onto shared platforms across more operating companies, the master-data surface grows rather than shrinks, and the next full-warehouse-empty-shelf event will not announce itself as a data problem. It will look like a logistics failure, a demand miss, a bad quarter. It will be the table, quietly, as it was both times before.