How Do You Know Your Warehouse Location Data Is Right?

Most warehouse optimisation is sold on top of location data nobody trusts.

That is not a criticism of anybody’s warehouse. It is a description of what happens to a location master over five years of ordinary operation, and it is close to universal. What makes it worth a page of its own is the failure mode, which is unusually nasty.

A placement analysis run on inaccurate location data does not fall over. It does not throw an error or return an empty result. It produces a ranked list of confident, specific recommendations, formatted well enough to take to a steering committee, describing a building that does not exist. Nothing in the output signals the problem, because the arithmetic was performed correctly on the numbers it was given.

So this is the question that comes before every other question on this site. Optimisation is downstream of truth. We would rather ask it before an engagement than during one, including in the cases where the honest answer costs us the work.

This page covers why location data drifts, the four distinct ways it is wrong, why your inventory accuracy KPI almost certainly does not measure any of them, how to measure it so the number survives an argument, and how to scope the fix so it is a week of work rather than a quarter.

Why it drifts, and why nobody decided to let it

Location data goes wrong for an entirely ordinary reason: updating it is harder than not updating it.

If recording a move takes six taps on a handheld that takes a few seconds to respond, then at half past four on a Friday, with a trailer waiting on the dock, the pallet gets moved and the move does not get recorded. Nobody made a decision. The friction made it.

It happens once, which is nothing. Then it happens a few thousand more times across three years, and what you have is a location master that has quietly stopped describing the building. There was no incident, no outage, nothing to investigate. There is no moment anyone can point to.

This matters for how you fix it, and it is the reason the last section of this page exists. An accuracy problem caused by friction cannot be permanently solved by a clean-up, because the friction is still there on the morning the clean-up finishes.

And then there are the days it breaks all at once

Drift is the slow version. There are also five events that break location data in bulk, and if any of them has happened in the last two years it changes what you should expect to find.

• An ERP or warehouse system migration. Location data has to be mapped from the old scheme to the new one, and the mapping is built from what the old system believed rather than from what was on the floor. Any inaccuracy in the old master is carried across faithfully and is now much harder to trace, because the codes have changed and nobody can remember what the old ones meant.
• A racking change. Bays are added, removed, renumbered or converted from pallet to shelving. The physical work gets done over a weekend. The location master gets updated for the bays somebody remembered, which is most of them.
• A site move or a consolidation. Everything is relocated at once, under time pressure, usually by people who do not normally work in that building.
• Peak season with agency labour. Temporary staff are trained on picking and packing because that is what the volume needs. They are rarely trained on the move confirmation flow, and they are working in a building they do not know, under the heaviest volume of the year.
• A period of running on paper. Any outage where work continued and was reconciled afterwards. The reconciliation covers quantity, because quantity is what finance checks. It rarely covers location.

Ask which of these has happened recently before deciding how much to sample. If the answer is any of them, the honest prior is that the location master is worse than the people responsible for it believe, and that is not a reflection on them. It is what those five events do.

The four ways it is wrong, which are not the same problem

Our location data is bad is too coarse a statement to act on. There are four distinct failures underneath it, with different causes, different detection methods, and different consequences.

One: the item is not where the system says it is

It was moved and the move was not recorded. This is the classic case and the one everybody pictures.

The picker is sent to bay A-12-03-B, the bay holds something else or nothing, and the picker goes and finds the item two bays along or in the reserve location above. The pick eventually happens. Nothing is reported, because from the picker’s point of view nothing went wrong that they could not solve in ninety seconds.

Two: the item is somewhere the system does not know about

Overflow parked at an aisle end. A partial pallet left in a staging lane after a part-picked order. Product in a bay that was never declared to the system at all.

Here the system is not wrong about where it thinks the stock is. It simply does not know this stock exists in that place. This is the failure that a conventional audit cannot see, because a conventional audit walks the locations the system believes are occupied, and by definition this stock is not in one of those.

Three: right item, right location, wrong quantity

Detected by counting rather than by looking. It is the most commonly measured of the four and the least relevant to placement, which is a point the next section is entirely about.

Four: the location itself is fiction

A location code that exists in the master and does not exist in the building, usually left behind by a racking change that nobody backported. Or the reverse: a bay that physically exists and appears nowhere in the system, so nothing can ever be assigned to it and it fills up with whatever needs somewhere to go.

This is the worst of the four for placement work, because a recommendation that assigns a fast mover to a location which does not exist will be handed to somebody to execute. What actually happens next is that they put it in a sensible nearby bay and do not tell anyone, which creates a fresh instance of failure type one, in the highest-traffic part of the building, generated by the optimisation project itself.

What each one does to the analysis

• Type one makes the model compute a distance to a place the item is not. Every number attached to that item is wrong, and it is wrong quietly.
• Type two means work is happening that the model cannot see at all. Those picks exist in the order history and resolve to a location that never appears in the location master, so they either get dropped from the join or get attributed to the wrong place.
• Type three corrupts the replenishment netting, because how often a location needs refilling depends on how much of the item is in it.
• Type four produces recommendations that cannot be executed as written, and the improvisation that follows is unrecorded by construction.

Any accuracy measurement worth having distinguishes at least types one, two and four. Most measure only type three.

Cycle counting does not measure this

This is the section most likely to send somebody off to check something, so it is worth being precise.

Cycle counting is usually reconciling quantity by item. Does the system’s on-hand figure for item A-4471 match the physical count of item A-4471. That is a real and important control, it is what finance cares about, and it is what most inventory accuracy reporting is built from.

It can be excellent while location accuracy is terrible.

If item A-4471 is supposed to be in three locations and is actually in three different locations, but the total quantity across the site is right, an item-level count passes cleanly. The stock is all there. It is simply not where the system says it is, which is the only thing a placement analysis cares about.

So a site can report healthy inventory accuracy month after month, be genuinely proud of it, and still be unable to support a slotting project. The KPI is not lying. It is answering a different question, and nobody noticed because the two questions share the word accuracy.

The test is one sentence long. Ask whoever owns the number: does this reconcile quantity by item across the site, or quantity by item at each individual location? If the answer is the first one, it is not telling you what you have been assuming it tells you.

One further note, in the interest of being straight about what we do and do not know. The WERC DC Measures survey carries a quality metric named Inventory Count, percent by location. We have not been able to confirm from the source whether that measures location-level accuracy or the coverage of a cycle-counting programme, and those are very different things. So we are not going to build an argument on it, and we would treat any benchmark quoted from it with caution until somebody produces the verbatim definition. If you have the current edition to hand, that definition is worth reading before anyone benchmarks you against it.

Nobody owns it, which is why it stays broken

Worth naming, because it explains why an obvious problem persists in well-run buildings.

Inventory quantity has an owner. It reconciles to the balance sheet, somebody in finance asks about it monthly, and there is a named person whose performance is attached to it.

Location accuracy usually has no owner at all. Operations assume the system reflects the floor. IT assume the floor reflects the system. Finance does not ask, because the total is right. The people who feel it are the pickers, who have adapted, because a picker who cannot find something and goes and finds it anyway is not raising a ticket, they are doing their job.

The practical consequence is that the problem is invisible at every level where somebody could authorise fixing it. Before any of the measurement below is worth doing, decide whose number it is going to be.

How to measure it so the number survives an argument

The method is a sample walk: take a set of locations, go and look at them, compare what is there against what the system says. Simple. What is usually done badly is everything about how the sample is chosen and how large it is.

Define what counts as wrong, in writing, before you walk

Otherwise the number is arguable afterwards, and it will be argued about, because it is going to be an uncomfortable number.

Decide up front how you will record each of: wrong item present, extra item present that the system does not list, quantity mismatch, location does not exist, location physically empty when the system says it holds stock. Decide whether a quantity out by a single unit counts as a failure. Decide whether an item found in the next bay along counts as wrong, which it does, and be ready for that to be unpopular in the room.

Write the definition down and have the person who will later dispute the result agree to it before anyone walks anywhere. That single step is worth more than doubling the sample size.

Pick the locations at random, from the master

This matters more than the sample size, and it is where most audits are quietly worthless.

If you walk the aisles nearest the office, or the ones the supervisor suggests, or the ones that are easiest to reach, you have measured the best part of the building. Pull the full location list, randomise it, and walk the ones that come up, including the awkward ones at height and the ones in the far corner that need a truck to reach.

And include the locations the system says are empty. Nobody ever audits an empty location, which is exactly why phantom stock accumulates in them, and an audit that only visits locations the system believes are occupied cannot detect failure type two at all. That is half the reason the audit exists.

Now the sample size, and why thirty is not a number

Suppose you walk a sample and 8 in every 100 locations disagree with the system. What have you actually learned? That depends entirely on how many you walked, and the arithmetic here is not a matter of opinion.

Putting a conventional confidence interval around that result:

• Walk 30 locations. The true rate could plausibly be anywhere from 0 to about 18 in 100. That range spans essentially perfect to roughly one location in six being wrong. You have learned nothing you can act on.
• Walk 100 locations. Roughly 3 to 13 in 100. Still a wide band, but it now excludes perfect, which is often the only thing you needed to establish.
• Walk 400 locations. Roughly 5 to 11 in 100.
• Walk 1,000 locations. Roughly 6 to 10 in 100. Now you have a number you can put in front of a sceptic and defend.

The uncomfortable implication is that a spot check of thirty bays, which is what most people mean when they say they checked, is compatible with almost any state of the world. It is not a small measurement. It is not a measurement.

The good news is that walking a location is fast. Two people doing 400 locations is a day of work, and that day buys the difference between an opinion and a number. It is the cheapest thing on this page and the one most likely to change what happens next.

Record what kind of wrong, not just how many

A single accuracy figure tells you the size of the problem and nothing about its shape. The same number produced mostly by failure type one and mostly by failure type four leads to two completely different projects.

So the audit sheet should have a column for the failure type, a column for the aisle, and a column for whether the location is a pick face or reserve. Those three columns turn a number into a plan, and they cost nothing to collect while you are standing there anyway.

Re-measure afterwards on a fresh random sample

Same size, same written definition of wrong, locations drawn again rather than re-walking the ones you corrected. Re-walking the corrected ones measures whether you corrected them, which you already know, and it is the single easiest way to produce a reassuring number that means nothing.

What to fix first, using data you already have

The instinct is to audit and correct the whole building. In a site with 10,000 locations that is a project with a budget and a steering committee, which means it will not be approved, which means nothing will happen.

There is a much better cut available, and it comes free with the order-line extract from the previous article in this series.

Not every location matters equally. The ones that matter for picking are the ones with picks against them. Take twelve months of order lines, join them to the location master, and count picks per location. In a typical distribution the answer is heavily skewed. If 1,200 of your 10,000 locations carry the bulk of the picking activity, then those 1,200 are the audit, and 1,200 locations is a week of work rather than a quarter.

The remaining locations still matter for stock control and for the finance number. They matter much less for placement, because nothing is walking to them.

This ordering has a second benefit that is worth more than the first. The high-pick locations are the pick faces, which are the ones being touched constantly and are therefore drifting fastest. You are fixing the part that breaks most, which is also the part every downstream analysis depends on most.

And it has a third. A week-long audit with a defined scope is a thing a DC manager can authorise. A whole-building programme is a thing that needs a business case, and the business case needs a number, and the number needs an audit. Starting with the picked locations breaks that loop.

The clean-up is not the fix

A location clean-up produces a satisfying before and after. It also decays, at exactly the rate the friction dictates, because nothing about the reason the data went wrong has changed.

If confirming a move takes six taps on a slow device, it will keep not happening at half past four on a Friday. Any accuracy programme that does not change that number of taps is buying itself a few quarters, and the shape of the graph afterwards is entirely predictable to everyone except the people who commissioned it.

It is also worth seeing what the friction is costing directly, because that number usually funds fixing it on its own. Take a site doing 800 move confirmations a day. Suppose the current flow takes around 25 seconds by the time the device has responded and the worker has found the right screen, and a better one would take 8. That is 17 seconds, 800 times a day, which is about 3 hours and 45 minutes a day. Across 250 working days it is somewhere near 940 hours a year, on the confirmation step alone, before counting anything the missing confirmations cost downstream.

Substitute your own numbers, and get them by standing next to the process with a stopwatch rather than by asking. People consistently underestimate how long their own system takes, because they have stopped noticing the waiting.

So the durable version of this work has two halves and the second one is the real one. Correct the data, then reduce the cost of keeping it correct. The second half is a process and tooling question rather than a data question, and it is usually where the money actually is.

We are stating this plainly because it is the half most likely to be skipped by anybody selling an optimisation project, ourselves included. The clean-up is visible and billable. The friction reduction is neither, and it is the one that decides whether any of it holds.

What this is worth, and an honest note about the size of it

Location accuracy does not appear on the floor’s scoreboard, which is a problem when you need to fund fixing it. Here is the chain that connects it to something that does, and then a caveat that most people selling this work will not give you.

A picker sent to a location where the item is not does not stop working. They search. They check the bay above and below, they check the next aisle, they call someone, and eventually they either find it or they raise an exception and the line goes short. That time is spent, it is not picking, and it is invisible to every system that measures only completed picks.

Bartholdi and Hackman, in the Georgia Tech textbook Warehouse & Distribution Science, break picker time into travelling, searching, extracting, and paperwork. Searching is a named category in its own right. That is where inaccurate location data lands. Not in travel, in search.

So the measurement to take is not distance. It is how often a picker arrives at a location and does not find what they were sent for, and what each of those events costs. Both are obtainable. The first comes from exception records if your system logs them, or from a fortnight of tally marks on a clipboard if it does not. The second comes from standing next to the process with a stopwatch for an afternoon.

Now the honest part. Work it through and the number is often smaller than you expect. Take 60 failed-find events across an operation in a shift, at 90 seconds each. That is 90 minutes a shift. Across 250 shifts it is around 375 hours a year, which is a meaningful number and is not a transformation.

Put it in the metric that settles arguments. Twenty pickers over a seven and a half hour productive shift is 150 person-hours. An operation picking at 100 lines per person hour ships 15,000 lines in that shift. Recover 90 minutes of searching and, assuming the work exists to fill it, you ship on the order of 150 more lines. Lines picked and shipped per person hour moves from 100 to about 101.

Every figure in those two paragraphs is an illustration with round numbers, not a benchmark and not a promise. Put your own in.

That modest result is deliberately included, because it is the truth and because it leads somewhere important. The reason to fix location accuracy is not the search time you recover. It is that accurate location data is the precondition for the placement work, and the placement work is where the large numbers live. Fixing accuracy pays for itself modestly and directly. What it actually buys is the ability to do the next thing at all.

Anyone who presents a location accuracy project as a large productivity win on its own is either counting something else or has not done the arithmetic.

If the answer is bad

Then that is the project, and the slotting work waits.

This is the part we will say even when it costs us an engagement, and we would rather say it here, on a public page, than in a room after a proposal has been written. An analysis run against a location master that does not match the building will be precise, confident, well-presented and wrong, and the fact that the arithmetic was performed correctly will be no comfort to anybody.

The sequence is: decide whose number it is, define what wrong means, measure it properly on a random sample, fix the locations that carry the picks, reduce the friction that broke them, re-measure on a fresh sample, and then have the placement conversation.

That first stretch is where the unglamorous money is. It is also the stretch nobody demos, because a location master that is true does not look like anything. It is very hard to sell and it is the thing that has to happen first.

What to do this week

• Pull your location master and count the locations. Then count how many have had a pick against them in the last twelve months. The ratio between those two numbers tells you how big the real audit is, and it is almost always far smaller than the building.
• Ask what your inventory accuracy number actually reconciles. Quantity by item across the site, or quantity by item at each location. If it is the first, it is not measuring what you have been assuming it measures.
• Walk 100 random locations, chosen from the master rather than by eye, including ones the system says are empty. It is an afternoon. It will not give you a precise figure, and it will tell you very quickly whether you have a problem worth measuring properly.
• Time a move confirmation. Count the taps, count the seconds, with a stopwatch rather than from memory. That number is the reason the data drifts, and it decides whether any fix survives contact with a Friday afternoon.
• Find out which of the five bulk-breakage events has happened in the last two years. Migration, racking change, site move, peak with agency labour, or a period running on paper. It changes what you should expect to find.

For what a placement analysis needs once the location master is trustworthy, read What data do you need for a warehouse slotting analysis?.

For the argument about why placement comes before routing, read What is warehouse slotting, and should you fix it before routing?.

For the full ground-up treatment of the problem this sits inside, read Warehouse Pickup Optimization: The Operator’s Guide.