Your Warehouse Hunts for Work. That Is the Productivity Problem.

A picker in most warehouses opens a screen, reads a list of transfers, and chooses one. That single habit is the reason warehouse picking productivity cannot be measured at all. The order of work ends up decided by whoever reads fastest, the walk path is whatever each person feels like, two people are sent to the same aisle while a third crosses the building twice, and there is no such thing as a standard time for a putaway — so every discussion about productivity is one person's impression against another's.

The fix is not a bigger screen, a bonus scheme or a better-motivated picker. It is that work is given out rather than hunted: one operator, one screen, the next task, sized into a work order by count, time, weight and volume, and confirmed by scanning the location rather than by pressing a button. Everything you want to know afterwards — cost per line, labour per order, whether the second shift is genuinely slower — becomes arithmetic the moment that is true, and stays unanswerable while it is not.

That is the whole answer. The rest of this article is why the list persists, what directed work actually consists of, the confirmation problem that quietly destroys stock accuracy, and the order to do it in.

The list is not laziness. It is the only thing the software offered.

It is worth being fair to the warehouse here, because the habit is usually blamed on the people performing it.

A standard ERP inventory module is built around the transfer. A transfer is a document: it has lines, a source, a destination and a state, and it exists so that stock moves and the accounting behind the move posts correctly. All of that is right, and none of it gets thrown away — the receipts, the quantities, the valuation and the journal entries behind a transfer are the part that works. Businesses reaching this point have usually already worked through whether they need a warehouse system at all, and concluded that they do.

What the transfer was never designed to be is a unit of labour. Nobody wrote it to answer "what should this person do next". So the interface it offers is a list of documents, and a list of documents can only be chosen from. The operator is behaving rationally inside a tool that has no other affordance. When a business tries to close that gap with rules — pick in order, take the oldest first, do not skip — it is writing procedure to compensate for a missing idea, and procedure loses to a busy Tuesday every time.

The distance between a stock module out of the box and a warehouse execution system is often described as a feature list. It is not. It is one idea: work is dispatched, not discovered. Most of what a warehouse suite does is a consequence of that idea rather than an addition to it, which is also why bolting three features onto the list does not get you there. This is the operational half of the case we set out for operations that store, move or clear other people's goods; the commercial half follows from it.

What "directed" actually means

Four things, and the fourth is the one that gets left out.

The task, not the document. The unit the operator receives is a single piece of work — go to this bin, take this quantity of this item, put it here — rather than a transfer with eleven lines on it that he will interleave in his own order. The transfer still exists behind it. He does not see it.

A work order that is sized. Tasks are batched into a work order with real limits: how many, how long, how heavy, how much volume. A batch sized by line count alone is how someone ends up given twelve tasks that turn out to be four pallets of water, and a batch with no limits at all is how the last two lines get abandoned near the end of a shift.

Sequenced by the building, not by the document. The order of tasks follows the physical layout so the walk path is a route rather than a series of decisions. This is where the time actually is. In most operations the picking is a small share of the clock and the walking is most of it, which is why re-sequencing usually beats making anyone move faster.

Interleaved. A putaway placed on the way back from a pick, when it is genuinely on the path, rather than queued as separate work to be done later by someone walking the same aisle again. This is the one most implementations skip, because it only becomes possible once the first three are true, and it is where a meaningful part of the gain lives.

Two adjacent decisions belong to the same idea and are worth naming, because leaving them on their old setting undoes much of the benefit. Putaway has to be directed by a rule table read in order, first match wins — and when no bin qualifies, the honest outcome is an exception on a named person's list rather than a default bin. A default here is how a pallet ends up somewhere unsuitable with a location record that says everything was fine. And replenishment has to be raised when a pick crosses the minimum, once, not once per pick, or the exception list becomes noise inside a week and people learn to close it without reading.

The confirmation that proves nothing

This is the part that costs the most and is argued about the least.

In a great many warehouses the operator completes a task by pressing a button labelled Confirm. What that records is that somebody pressed a button. It does not record that the goods were where the system said, that the operator was standing there, or that the quantity in front of him matched the quantity on the screen. The two are treated as the same event and they are not remotely the same event.

The consequence arrives months later as a stock discrepancy, and by then it is undiagnosable: four hundred confirmations happened, one of them was fiction, and nothing distinguishes them. That is a large share of the reason the stock figure so many decisions rest on turns out to be wrong — not theft, and not usually carelessness, but a system that accepted an assertion and recorded it as an observation.

A directed move should be confirmed by scanning the bin's own check digit. It is a small change and it converts the record from a claim into evidence. The operator can no longer confirm from the break room, from the office, or from the aisle he meant to visit next. Everything downstream — the count programme, the billing run, the productivity figures — inherits its reliability from this one decision, which is why it is worth accepting the friction it adds.

We took the same view building our own logistics suite on Odoo — in Logix a directed move simply will not confirm without the location scan, because a refusal in code was cheaper than a rule taught to every new joiner for the next ten years.

The same logic settles counting. A counter who can see the expected number is confirming, not counting. So the count is blind, a variance inside tolerance posts itself, and a variance outside tolerance goes to somebody who is not the counter. That second condition is not bureaucracy. One person alone with a discrepancy and the authority to clear it is the mechanism by which shrinkage becomes an adjustment nobody reviewed, and it is the reason the rule is about who approves rather than about who counts.

What becomes measurable, and what to do with it

Once work is dispatched and confirmed by scan, a set of questions that used to be opinions become queries:

• How long a putaway of a given profile actually takes, as a distribution rather than an average — and the distribution is the useful half, because the tail is where the operational problem is.
• Cost per line, per order and per customer, from real labour rather than from an allocation percentage somebody agreed years ago.
• Which locations generate the most travel, which is the input to a slotting change and the only honest basis for one.
• Whether the second shift is genuinely slower, or is given harder work.
• What a peak week costs in labour, before you negotiate next year's rates.

Two cautions, both learned the expensive way. Do not attach individual productivity figures to pay before the measure has run unobserved for a season. The first weeks of a new measure are always wrong — tasks are mis-sized, some locations are mis-modelled, and someone has found the shortcut. Publishing a league table on top of that teaches people to game the measure rather than to do the work, and you cannot un-teach it.

And do not buy the reporting before the dispatch. A dashboard over hunted work shows you, very beautifully, numbers that mean nothing, which is a specific case of why so many ERP dashboards are confidently wrong. The measurement is a consequence of the operating model, never a substitute for it.

The order to do it in

Roughly this, and the sequence matters more than the pace:

1. Locations, properly. Every bin a real record with a check digit, capacity and characteristics. Nothing else works without it, and it is the step most often half-done.
2. Scan confirmation on the moves you already have, before any new machinery. On its own this changes what your stock figure means.
3. Directed putaway with a rule table the operation can edit, and an exception when no rule matches.
4. Task dispatch and work orders, sized and sequenced.
5. Blind counting with separated approval.
6. Interleaving and slotting, which are optimisations and belong last, on measurements taken from the four steps above.

A three-person operation with one store, one van and no customer but itself should stop after the second step and possibly before it. Directed work is not free: it costs configuration, hardware and a period during which the floor is slower while people learn. It earns that back where volume, headcount or a third-party contract makes the labour material, and it does not earn it back on ten lines a day. Being told which level you need — basic, located, or directed — is a reasonable thing to demand of anyone selling you this, and if the answer is always the top one, that tells you something about the seller rather than about your warehouse.

What to make a vendor show you

Not a slide. Ask for four things on a database with your own traffic in it, and watch a person do them:

Give a task to an operator and take it away again. Ask what happens when he is reassigned mid-work order, and whether the half-finished batch strands stock in a state nobody owns.

Confirm a move without scanning. If the system lets it through, ask what stops it, and do not accept a training answer to a systems question.

Break the putaway rules deliberately — present a pallet nothing in the table can take. A default bin is a failing answer; an exception on a named person's list is the passing one.

Ask for the standard time for a putaway, from the system, on your data. This is the question that separates a product that dispatches work from a product that lists it, because only one of them has ever known.

Everything above is a system property rather than a matter of discipline, which is the recurring theme of how we scope this kind of implementation: a rule a person is asked to remember is a rule that holds until the day it matters.

The pallet is the other half of the same problem, and it is the one that decides whether cross-docking, single-scan moves and third-party segregation are ordinary or impossible. That is the subject of what changes when the pallet becomes a record rather than a set of lines.