What Data Do You Need for a Warehouse Slotting Analysis?

A slotting analysis needs five things, and four of them are routine exports that anyone with reporting access can produce in an afternoon.

Twelve months of order lines. A location master saying which item is stored where. Item cube and weight, where they exist. Some notion of storage mode, meaning which locations are pallet rack, which are shelving, which are flow rack. And a pack or dispatch point, so that distance has somewhere to be measured from.

The fifth thing is not on that list. It is hidden inside the first one, and it is the order number.

That single field is the difference between an analysis that can tell you where to put one item and an analysis that can tell you which items should live next to each other. Almost every extract arrives without it, for an entirely reasonable reason: the person pulling the data understood that slotting is a question about items, so they produced a summary by item. It looks complete. It answers half the question. And nothing in the output announces that the other half is missing, because the recommendations that come back still look sensible. They are just all the easy kind.

That is the whole article. The rest of it is why, what each of the other inputs buys you, and how to check your own export in about ten minutes before anyone spends money analysing it.

What the analysis is actually computing

Worth being precise about the target, because every input below exists to serve it.

Slotting is deciding where each item lives. Bartholdi and Hackman, in the Georgia Tech textbook Warehouse & Distribution Science, define it as the careful placement of individual cases within the warehouse, and add the line that best explains why it is fiddly: it may be thought of as layout in the small.

The reason anyone bothers is travel. In most picking operations, roughly half of picker time goes on walking rather than picking. That figure traces to Frazelle’s work of 1996, which is the source most of the industry is quoting whenever it says travel dominates picking time. We have not found a methodology or a sample size disclosed anywhere in that citation chain, and we would rather say that than repeat the number as though it were settled.

The qualitative claim underneath it is on much firmer ground, and Bartholdi and Hackman make it in their own voice: order picking is the most labour intensive activity in most warehouses, and a large part of picker labour adds no value because it is spent travelling and searching.

So the prize is this. Whatever share of picker time is walking, some of it is walking that a different placement would not have required. The analysis exists to find that portion and put a defensible number on it. Everything below is what the arithmetic needs in order to run.

Input one: twelve months of order lines

The rows you want look like this, one row for every line somebody picked:

order number, item, quantity, date

Four columns. Every ERP and every warehouse management system exports something of this shape, none of it requires access to a live production system, and none of it needs to contain a customer name, an address or a price. That last point is worth raising early with whoever guards the data, because it usually turns a long conversation into a short one.

Twelve months, not ninety days

This is the part of the spec people push back on, and the reason is seasonality. Placement should follow demand, demand moves through the year, and a quarter cannot see a year.

Work it through with a plausible item. Say it takes 2,000 picks a year and 1,200 of those fall in November and December. Pull ninety days in March and the item shows roughly 200 picks in the window. In a warehouse carrying 10,000 active items that ranks it somewhere around three thousandth, and a velocity ranking will slot it accordingly, well back from the pack station. It sits there all summer being correctly placed. Then November arrives, it becomes a top fifty item, and all 1,200 of those picks are a long walk.

The analysis was not wrong. It was answering a question about March.

Ninety days is still worth analysing if ninety days is genuinely all the system will give up. It simply has to be labelled as what it is, and the seasonal items have to be found some other way, which usually means asking the people who work there and who already know exactly which ones they are. What you cannot do is take a ninety day ranking, call it the annual ranking, and move racking on the strength of it.

Picked lines, not ordered lines

A line that was ordered and a line that was picked are different events, and the distinction decides whether you are measuring demand or measuring work. For placement you want work: the lines somebody actually walked to and touched.

So ask explicitly what is in and what is out. Cancelled lines should not be in. Returns are not picks. Zero quantity rows usually mean something specific in your system and somebody knows what. Replenishment movements and transfer orders should be separated rather than deleted, because they are the other half of the netting question further down this page.

Watch the unit of measure

This one catches good analysts. A line for one case and a line for twenty-four eaches are the same quantity of product and a very different quantity of work. If the extract has been helpfully normalised so that every quantity is expressed in eaches, the pick count is no longer the pick count, and every item that ships by the case has been silently inflated.

What the analysis needs is the number of times somebody went to a location, plus the unit that was picked. If your file has one quantity column and no unit column, find out what happened to it before trusting the ranking.

Input two: the location master

Which item is stored where, and where that location is.

The bare minimum is item to location, which gets you a picture of the current state, and the current state is what everything else is compared against. But a location code on its own is a label, not a position. A code like A-12-03-B tells the analysis nothing about distance unless something else says where aisle A is, how far along bay 12 sits, and how high level B is.

So the useful version carries some geometry: aisle, bay, level, and ideally a coordinate pair or enough of a rack layout to derive one. Plenty of sites do not have this in a system anywhere. It exists as a printed floor plan taped to a wall, and somebody has to sit down and turn it into a table. That is a real cost and it should be budgeted rather than discovered.

There is a shortcut worth knowing when the geometry genuinely does not exist. You do not always need true distances in order to rank placement changes. Aisle number plus position along the aisle, treated as a rough grid, is usually enough to separate a good placement from a bad one, because the differences being hunted are large ones. A shortcut like that should always be declared in the output, though. An analysis that quietly substitutes an approximation for a measurement and then reports the result to three decimal places is doing something dishonest with your money.

Input three: item cube and weight, where they exist

Cube is the volume a unit occupies. Weight is what it weighs. Together they decide how much of an item fits in a good location, and therefore how often that good location has to be refilled.

This is the input most likely to be missing, and it is the one that kills projects outright.

The independent consultancy F. Curtis Barry & Co, writing about why slotting efforts fail, lists missing item cube and weight data as a direct cause of teams abandoning the work in their write-up of the aspects that hurt slotting efforts.

The reason it matters is the second half of the economics, and it is the objection a good operations director raises inside the first ten minutes. Every item you move closer to the pack station goes into a smaller, more convenient location. It therefore runs out sooner. Somebody then has to walk out to reserve stock and bring more forward.

Bartholdi and Hackman are blunt about where that ends:

Notice that some skus could positively hurt efficiency if they were stored in the forward pick area in less than their maximum amounts.

And, more directly:

if too little is stored, restock costs consume any pick savings.

A restock is a more expensive movement than a pick. So the correct question is never how much walking does this save the pickers. It is how much walking does this save, net of the replenishment it creates. You cannot compute the second half without knowing how much of the item fits in the location, and you cannot know that without cube.

If you do not have cube and weight, the analysis is not dead. It has to be scoped down honestly, to the placement changes where the volume question does not bite, and the missing input has to be reported as a limit on the answer rather than smoothed over. Any report that presents a net saving while having had no volume data to net with is presenting a gross saving with a better adjective on it.

Input four: storage mode

Bartholdi and Hackman define a storage mode as a region of storage or a piece of equipment for which the costs to pick from any location are all approximately equal. Pallet rack is one mode. Carton flow rack is another. Bin shelving is another. A mezzanine is another.

This matters because the pick rates are not remotely comparable between them. The textbook’s own figures: bin shelving runs at roughly 50 to 100 picks per person hour, and flow rack at roughly 150 to 500 picks per person hour, with wide variation.

That spread is larger than almost any travel saving you are going to find.

Which means an analysis that treats every location as equivalent and optimises purely for distance can quite happily recommend moving an item out of flow rack and into a nearer shelving bay, make the operation slower, and report a shorter walk while doing it. Distance is not the only cost. It is just the one that is easiest to compute, which is precisely why it is the one that gets over-weighted.

A mode label on every location, even four or five crude categories, prevents that entire class of error. It is the cheapest input on this list and the one most often left out.

Input five: where the trip ends

Distance needs an origin. Usually that is the pack station, the dispatch lane or the outbound dock. Sometimes there are several and different orders route to different ones, in which case the analysis wants to know which.

It is a one line input, people forget it, and then they wonder why the model put the fast movers in a corner.

Now the field that gets dropped

Everything above is the ordinary part, and it is ordinary because most of it survives an export intact. The order number frequently does not, and here is why its absence is invisible.

Slotting is not one job. It is two, and they need different data.

• The first job is velocity. Which items get picked most often, and are those items close to where the trip ends. This is a question about single items. Count how many times each item was picked, rank the list, compare the ranking against the distances, and the mismatches fall out. You can do all of it from a summary. It is genuinely easy, and the textbook says as much about the basic model: it can be realized easily, for example, on a spreadsheet.
• The second job is affinity. Which items keep turning up on the same order as each other, and are those items near each other. This is not a question about single items. It is a question about pairs, and a pair only exists if something in the data says these two lines went out together.

That something is the order number.

Velocity tells you how far a single pick is. Affinity tells you how long a whole trip is. They are different questions, they can give different answers, and the second one is usually where the larger numbers live, because a picker does not make one pick and go home.

Strip the order number out and you have not degraded the analysis. You have deleted one of its two halves cleanly, leaving the other half working perfectly and saying nothing about the loss.

What the missing field costs, with the arithmetic

This is a worked illustration using invented but plausible inputs. Substitute your own; the structure is the point, not the figures.

Take a warehouse carrying 10,000 active items with the pack station at one end of the run. Two items, call them A and B, ship together on 40 orders a week. Across all orders A gets picked 900 times a year. B gets picked 350 times.

Rank all 10,000 items by pick frequency and place them outward from pack in that order. A lands around position 300, roughly 15 metres out. B lands around position 2,100, roughly 95 metres out. Both placements are correct by the velocity model. Neither is a mistake in its own terms.

Now walk one of those 40 orders. If A and B sat next to each other at 15 metres, the trip is out and back, about 30 metres. As placed, the picker has to reach B at 95 metres regardless, collecting A on the way, so the trip is about 190 metres.

That is 160 extra metres, on every one of those orders.

40 orders a week over 52 weeks is 2,080 orders a year. Multiply by 160 metres and you get 332,800 metres, or near enough 333 kilometres a year.

Convert that to time using your own pace rather than one borrowed from an article. A loaded picker covering a metre a second, which is a conservative assumption and yours to replace, turns 332,800 metres into 332,800 seconds. About 92 hours a year. Of walking. Generated by one pair of items, both of which are sitting exactly where the velocity ranking says they belong.

A warehouse with 10,000 items does not have one such pair. It has as many as its order mix produces, and in any business with kits, consumables, spares or a repeating order pattern, that is a great many. Those hours never appear in the report, because the field that would have found them was not in the file.

And it lands, as everything in this trade eventually does, in lines picked and shipped per person hour. Ninety two hours a year is one person’s fortnight. Multiply across the pairs and decide whether it was worth keeping a column.

The other reason velocity alone misfires

There is a second failure, more physical than arithmetical, and it comes from the same source that flagged the cube and weight problem. F. Curtis Barry & Co note that naive velocity-only slotting creates congestion, by clustering all the A movers into one aisle.

Think about what a pure velocity ranking does geometrically. It takes every item people pick a lot and puts them all in the same small area, because that area is the closest one. Then it sends every picker there. You have shortened each individual walk and concentrated all of the traffic into the place with the least room in it.

Bartholdi and Hackman name the two kinds of interference this produces. The first is interference at a location, when both pickers want to pick from the same small area. The second is interference in an aisle, when one worker wants to pass another and is unable to because of the narrowness of the aisle.

Neither of those appears in a distance model. Distance models assume a picker who is never in anybody’s way. This is the clearest argument for treating the output of a slotting analysis as a ranked list of candidate moves for people who know the building, rather than as an instruction set to be executed.

How to check your extract in ten minutes

Before anyone spends money analysing a file, five checks. All of them can be done in a spreadsheet, and any one of them failing tells you something worth knowing now rather than in month three.

One: is there an order number, and does it repeat?

Open the file and find the order number column. Then confirm that the same order number appears on more than one row. If every order number occurs exactly once, you do not have order lines, you have order headers, and the affinity half is already gone. If there is no order number column at all, stop here and go back to whoever produced it, because nothing further you do will recover it.

Two: does the row count make sense?

Estimate it independently before you look. If the site ships around 500 orders a day, five days a week, at an average of four lines per order, then twelve months should produce roughly 130,000 orders and something in the region of 520,000 rows.

If the file holds 40,000 rows, something aggregated it on the way out. If it holds almost exactly 130,000 rows, you have one row per order, which is check one failing again in a different costume. And if it holds a suspiciously round number, particularly 50,000 or 100,000 or 1,048,576, you have hit an export row limit and are looking at a truncated file.

Three: do the dates span twelve months evenly?

Pivot the rows by month. You want twelve buckets, none empty and none suspiciously thin. A missing or light month usually means a system migration, a reporting cut-off or a job that failed quietly, and any of those changes what the ranking means.

Four: do the items in the order lines exist in the location master?

Join the two files on item code and count what fails to match. A small tail of orphans is normal and is usually discontinued lines. A large one means the two extracts came from different item numbering, different legal entities or different sites, and joining them will produce answers that are confident and wrong.

Five: what is in, and what is out?

Ask, in writing, whether cancelled lines, returns, replenishments and transfer orders are included, and what unit the quantity is expressed in. Nobody minds being asked and everybody assumes somebody else already did.

A file that passes those five is analysable. A file that fails one has just saved you the cost of finding out later.

Where these fields actually break

Four practical traps, each of which has made an otherwise clean extract useless.

• Kits and bills of material. If a kit ships as one line but is picked as six, an extract taken from the sales side undercounts the work by a factor of six for exactly the items that move most. Take the extract from the picking side wherever the system allows it.
• Aggregation on the way out. Reporting layers love to group by item and date. A weekly summary per item is not order lines, it is a velocity report that has already thrown the pairing away. The tell is check one above.
• Two systems, two truths. Where the ERP holds the orders and a separate warehouse system holds the locations, item codes very often diverge, with prefixes, check digits, or a mapping table that lives in one person’s head. Reconcile before analysing, not after the report looks strange.
• Retention has already run. Picking history is transactional data, and transactional data has a retention policy attached to it somewhere. Purge and archive jobs are configured once, usually by somebody optimising database size, and they do not ask what the history was for. If you think you might want to do this next year, go and find out today how long your pick history is kept. It is a five minute question and the wrong answer is not recoverable.

One thing worth checking whatever you do about slotting

A quiet finding from the same textbook, which is worth more than many slotting projects and takes an afternoon to check.

It is a popular misconception that an ABC analysis refers exclusively to the ranking of skus by dollar-volume... dollar-volume will be of little interest to us.

Most in-house ABC classifications rank items by revenue, or by the dollar value moved, because that is the report the ERP produces by default and because finance asked for it first. For placement, that is the wrong variable. A picker’s walk does not know what an item is worth. It knows how often somebody has to go and get it, and how much space it takes up when they do.

If your A, B and C classes were built on dollar volume and are now being used to decide where stock sits, they are optimising something other than labour. Go and look at how yours was derived. It is a five minute question with a large answer and it costs nothing.

What you should expect back

If somebody runs this analysis for you, the output should contain all of the following, and you should push back where it does not.

• Current versus achievable travel, expressed both as distance and as hours, with the pace assumption stated in the open rather than buried in a footnote.
• A ranked list of placement changes, ordered by what each one is worth, because the benefit concentrates in a small number of items and you should never have to do all of them to get most of the value.
• The affinity pairs, meaning the item pairs that ship together and are stored apart. This is the part that requires the order number, and it is the part to check for first, because its absence is the sign that the extract was short a column.
• Savings net of the replenishment they create, not gross pick savings.
• A statement of what the data could not answer. Missing cube, a short window, no storage mode, an approximated geometry. Every real dataset has some of these.

That last one is the one to watch. A report that declares no limitations has not found none. It has either not looked, or it is not saying.

And the currency all of it should be converted into is lines picked and shipped per person hour. That is the measure the floor is already run against, it is the one on the WERC DC Measures benchmark, and it is the only unit in which a placement argument can actually be settled.

If the data does not exist

It happens, and it is not the end of the exercise.

A site with no location geometry, no cube and a picking system that will not surrender order numbers can still do the useful version, which is this: count picks per item for as long a window as the system will give up, print the list, walk the building with it, and look at what is far away and should not be. That is not an analysis. It is a walk with a list. It also finds things, and it costs a morning.

What a walk with a list will not find is the affinity half, and the affinity half is where the trips live. So the second thing to do, on the same day, is find out what it would take to get order numbers onto the extract. Sometimes it is a checkbox in a report definition and takes ten minutes. Sometimes it is a retention policy that has already deleted the history and the answer is that you start collecting from today. Knowing which of those you are in is worth having now.

The person to ask is whoever writes reports against the ERP, not whoever administers it. They will know within a minute whether the field is reachable.

What we ask for

If you want to know how much of your pick travel is waste, the list at the top of this article is the entire ask. Twelve months of order lines with order number, item, quantity and date. A location master. Item cube and weight where you have them. Standard exports, no production access, nothing installed, no cost and no obligation.

What comes back is current versus achievable travel, the ranked list of moves, the affinity pairs, and an honest account of what the data could not tell us.

And if the order number is not on your extract, tell us that too. It is a finding in its own right, and it is the first thing worth fixing.

For the argument about why placement comes before routing, and the shift-level arithmetic behind it, 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.

If you run Dynamics 365 and want to know what the ERP computes here and what it leaves to you, see Can Dynamics 365 optimize inventory placement?.