Operations research · Warehouse

How warehouse pick optimization is actually solved

Picking is not one problem. The operations-research literature decomposes it into five layers, solved in sequence, each with its own well-studied algorithms.

Most warehouses optimize the last layer first, which is the one with the least left to give. Here is the whole stack, and where a warehouse management system stops.

5

layers in the order-picking problem

0

derived by your warehouse system

1963

the Cube-per-Order Index paper

The hexagonal cells of a honeycomb
The problem

It has a name, and it is old

Formally this is the Order Picking Problem, or the Picker Routing Problem, and it sits where combinatorial optimization, vehicle routing and scheduling meet. One picker collecting one order is a Travelling Salesman Problem. Several pickers collecting many orders is a Vehicle Routing Problem with batching. Release the orders in timed groups and each wave becomes its own instance.

It matters because travel is roughly half of order-picking time, and order picking is the largest single component of warehouse labour cost. The canonical starting point for anyone going deeper is De Koster, Le-Duc and Roodbergen’s 2007 literature review in the European Journal of Operational Research.

The stack

Five layers, solved in this order

The order matters more than any individual algorithm. Each layer constrains the one below it, so optimizing a lower layer against a bad upper layer buys very little.

  1. 1

    Slotting

    Where should each product physically live?

    The highest-leverage layer, and the one everything downstream depends on. The classic method is the Cube-per-Order Index: rank each item by physical volume divided by order frequency, then assign locations outward from the depot. Under single-command cycle assumptions this is provably optimal, a result that goes back to Heskett (1963) and Francis (1967). The richer version is correlation or affinity slotting, which co-locates items that get ordered together. That formulation is a Quadratic Assignment Problem, which is NP-hard, so it is solved with simulated annealing, genetic algorithms or tabu search rather than exactly.

  2. 2

    Batching

    Which orders should one person carry on one trip?

    Formally the Order Batching Problem. The seed algorithm starts from one order and repeatedly adds whichever order overlaps its locations most, until the cart is full. The savings algorithm adapts Clarke-Wright from vehicle routing, merging two orders when the combined trip beats two separate ones. The most common industrial approach is cluster-first, route-second: cluster orders by pick-location density, then route each cluster. Add deadlines and it becomes a scheduling problem, a parallel-machine formulation with batch processing.

  3. 3

    Routing

    What path does the picker walk?

    For one picker this is a Travelling Salesman Problem, but a constrained one: warehouse aisles are a grid, not an arbitrary graph, so simple heuristics get close to optimal cheaply. S-shape traverses every aisle containing a pick and lands within roughly 20 to 30 percent of optimal in most layouts. Return enters each aisle only as deep as the furthest pick. Largest gap chooses the entry end that minimises backtracking and generally beats both. The combined heuristic picks the better of return or full traversal per aisle and is close to optimal for rectangular warehouses (De Koster et al., 1998). Where provable optimality is needed, Roodbergen and De Koster (2001) give an exact dynamic program that exploits aisle topology, practical to around thirty aisles.

  4. 4

    Zoning and worker assignment

    How is the floor and the workload split?

    Dividing the warehouse into zones turns worker assignment into a load-balancing problem: partition items across zones so that expected workload per picker is even, given how often each item is ordered. Written formally it is makespan minimisation, P||Cmax, which is NP-hard but tractable in practice through linear-programming relaxation with rounding, or column generation. Item velocity from ABC analysis is the usual input.

  5. 5

    Wave and release timing

    When should work be released to the floor?

    Under a stream of incoming orders, releasing a batch now or waiting for more orders to arrive is a genuine decision with a cost either way. Queuing models (M/G/1, M/M/c) are used to size waves and set release frequency. The dynamic version is a Markov Decision Process, solved by value iteration or approximate dynamic programming when the state space gets large. Reinforcement learning appears in the research literature from around 2019 and is competitive with the best metaheuristics in simulation, but it is not yet mainstream in production.

At scale

When exact methods stop being possible

The full multi-picker, multi-order problem can be written as an integer linear program and solved exactly by branch-and-bound, but only for small instances. Beyond that the field decomposes. Column generation, where each column is a feasible route and the master problem selects routes to cover every order, is the same framework used for airline crew scheduling and is the strongest exact method available at medium scale. Benders decomposition splits batch assignment from routing and iterates with cuts.

Past that, metaheuristics take over: simulated annealing with swap, relocate and 2-opt moves; tabu search, which keeps a memory of recent moves to avoid cycling and performs well on joint batching and routing (Henn, 2012); genetic algorithms, used more often for slotting than routing; and adaptive large neighbourhood search, which is arguably current best practice for this class of problem. Whatever policy is chosen, discrete-event simulation is the standard way to test it before it reaches the floor.

What is actually deployed, roughly in order of adoption

  1. Cube-per-order-index slotting with s-shape or largest-gap routing. The warehouse-management baseline.
  2. Clustering-based batching with largest-gap routing. Common in mid-market ERPs.
  3. Integer-programming batching over pre-computed routing costs, where a solver licence exists.
  4. Metaheuristics at large third-party-logistics scale.
  5. Reinforcement learning, still mostly academic.
Before any of it

None of this survives bad location data

An optimal route to the wrong location is worse than a poor route to the right one.

Every layer above assumes the system knows where things actually are. If the recorded location and the physical location disagree often enough, a routing improvement is not merely wasted, it is negative: the picker walks the efficient path, finds nothing, and searches anyway. This is the sequencing most optimization projects get wrong, and it is why we ask about location accuracy before anything else.

It is also the honest reason a diagnostic comes before a proposal. If the location data is not good enough to trust, that is the finding, and it is worth more than a routing model built on top of it.

An empty bin on a shelf
The last mile

Which layer your ERP derives

A warehouse management system executes these layers well. What it does not do is derive the policy.

Each of those is an input somebody chose, and in most operations that somebody chose it once, in a spreadsheet, longer ago than they would like to admit.

That gap is the whole of our work. Dynamics is the system of record; the optimization app is the system of intelligence. It reads the order history you already have, computes the placement the literature above says is optimal for it, and hands the recommendation and its evidence to the person who owns the process.

It does that from outside. We don’t touch your ERP core, we surround it with intelligence, and the results are written back where your WMS already reads them. If an implementation partner put your Dynamics in, they keep their scope and your upgrade path stays intact.

Roller tracks on a flow rack

What the system does

  • Stores the location
  • Enforces the put-away rule
  • Ranks the bins
  • Builds the pick work
  • Directs the worker
Handwritten calculations on paper

What nobody derives

  • The cube-per-order ranking
  • The affinity clusters
  • The zone split
  • The wave size
Sources

Where to read further

  • De Koster, Le-Duc & Roodbergen (2007). “Design and control of warehouse order picking: a literature review.” European Journal of Operational Research. The canonical survey; start here.
  • Roodbergen & De Koster (2001). Exact dynamic programming for picker routing in warehouses with multiple cross aisles.
  • De Koster et al. (1998). The combined heuristic, and its near-optimality on rectangular layouts.
  • Heskett (1963); Francis (1967). Cube-per-order index, and its optimality for single-command cycles.
  • Henn, Koch & Wäscher (2012). Order batching solution approaches, including tabu search and simulated annealing.

Each method, written up

Slotting, batching and routing — what each one does, the data it needs, and where it stops being worth doing.

Browse all engineering writing
Rows of small wooden index drawers filled with filing cards

FAQ

Common questions

You need a record of where stock is kept, and you need that record to be right. That is usually a warehouse management system, though a well-run Business Central or Finance & Operations setup already holds one, and warehousing is where those two differ most.

What matters is not which product you run. It is whether a picker sent to a bin by the system actually finds the thing there.

Ask which of the five layers above it touches, and where its ranking comes from. Most built-in slotting ranks bins against a rule somebody configured, which is execution.

The question this page is about is whether that rule was derived from your own order history, when it was last recomputed, and what it was set to optimize for. If your vendor derives it and recomputes it as your orders change, you may not need us.

No. It means no known method finds the provably best answer quickly as the problem grows, so past a certain size the field stops asking for the best answer and asks for a good one with a known bound. That is what the named heuristics are for.

In an operation where placement was set once by hand and never revisited, the distance between a good answer and the best one is rarely what is holding you back.

There is no threshold we can give you honestly. It depends on how much of your picking time is spent walking rather than on floor area or headcount, and that split is specific to your layout and your order profile.

A small operation with dense, stable, well-placed stock may have very little to gain. One that has never recomputed placement since the racking went in usually has more. Working out which you are is what the assessment is for, and it comes before anyone proposes anything.

No. Everything above runs on exported history: order lines and a location master. Nothing is installed, no production access is needed, and nothing is changed in your system while the work is done.

No, and if you did that would be a poor sign. The output is a placement recommendation with the reasoning attached, aimed at the person who already owns the decision, so a warehouse or operations manager can judge whether it is sensible.

The methods on this page are named so that you can check the work, or hand it to someone who can. Not because you need to run any of it yourself.

Find out what your current placement is costing you

Send order lines and a location master. We compute what the current placement costs in picker travel. If the location data is not reliable enough to trust, we tell you that instead. No cost, no obligation.