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

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.
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
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
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
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
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
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.
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
- Cube-per-order-index slotting with s-shape or largest-gap routing. The warehouse-management baseline.
- Clustering-based batching with largest-gap routing. Common in mid-market ERPs.
- Integer-programming batching over pre-computed routing costs, where a solver licence exists.
- Metaheuristics at large third-party-logistics scale.
- Reinforcement learning, still mostly academic.
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.

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.

What the system does
- Stores the location
- Enforces the put-away rule
- Ranks the bins
- Builds the pick work
- Directs the worker

What nobody derives
- The cube-per-order ranking
- The affinity clusters
- The zone split
- The wave size
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.

Dynamics 365 directs every pick. Why is the walking still whatever it is?
Four configuration objects decide where a picker goes and in what order, and every criterion inside them is about which stock rather than how far. In version 10.0.49 Microsoft added a preview wave step that does measure distance — it reorders pick lines within a work record, from coordinates you maintain, toward a fixed objective. Read precisely, it tells you which part of the walk the ERP owns and which part nobody owns yet.
Read more12 min read
Is advanced warehouse management a setting you can turn on later?
Microsoft publishes a migration tool for moving items onto warehouse management processes, and states that open inventory transactions do not block it. The requirements, the validation list and two unsupported cases are the real answer — and the setting that is genuinely hard to revisit is not this one.
Read more8 min read
Batch above or below location — which did you choose, and can you change it?
Where the batch number sits relative to location decides whether the order or the warehouse chooses which batch ships. Microsoft names both models, and the question of whether you can change your mind has three different answers — one yes, one no, and one that depends on whether the level structure matches.
Read more8 min read
Why does your pick path zig-zag? Your location format is a sort key
A location name is a string, and anything that orders pick lines orders that string. Microsoft's location format has a fixed-length segment field — the page documents the width it enforces, and a fixed width is what stops aisle 10 sorting before aisle 2 — plus a ten-character ceiling on the whole name, and a sort code that is documented for warehouses which do not use warehouse management processes at all.
Read more8 min read
One wave template, or four? What wave design says about your building
A wave template decides when work is created, in what batches, and whether a person sees it first. One template for a mixed building means parcel, pallet and line-feed work share a rhythm — and one field on it decides whether a wave that cannot reserve inventory fails loudly or quietly puts the stock in a blank location.
Read more8 min read
Why is one worker doing the pick, the put and the load?
Microsoft's own example work template has four lines — pick, put to staging, pick from staging, put to the truck. They land on one worker because they share one work class, and the field that separates them is the same field that decides which workers are allowed to see each part.
Read more8 min read
Work creation failed at 07:05. Which location directive did it stop on?
Whether a wave stops when no location can be found is a setting on the Location directive failures page. Two documented conditions make a directive line skip silently rather than fail. And Microsoft ships a coverage view that colours which directives, lines and actions were evaluated and which one found a location.
Read more8 min read
Is Dynamics 365 WMS fast enough for a high-volume distribution centre?
Microsoft answers the scale question in its own deprecation register. Three warehouse surfaces were deprecated with performance named as the reason, each replaced by something it calls significantly faster — so the useful question is not whether the product is fast enough but whether you are still running the pages it retired.
Read more8 min read

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.




