Do You Need a Warehouse Management System? An Honest Test

The pick list comes off the printer in item-code order. The picker starts at the far end of the racking because the first line happens to be a code beginning with A, walks back past the door for line two, returns almost to where he started for line three, and finishes the eight-line order roughly four hundred metres later. He does this thirty times a shift. Nobody has ever measured it, because walking does not look like work being done badly — it looks like work.

Somewhere in the following months, a vendor demonstrates a warehouse management system with directed put-away, wave picking and a handheld that tells the operator exactly where to go. It is genuinely impressive, and it would genuinely fix the walking. The question is whether it is the cheapest thing that would fix the walking, and the honest answer, in most mid-market warehouses in this country, is no.

What a WMS actually does that an ERP module does not

Both hold locations. Both can hold batches, expiry dates and serial numbers. Both can print a pick list and receive a scan. The difference is not the data model; it is the decision-making around movement, and it appears in a small number of specific capabilities.

Capability	ERP inventory, basic	ERP inventory with locations and barcodes	Dedicated WMS
Multiple stock locations	Usually yes	Yes, with hierarchy	Yes, with attributes per bin
Pick list sequenced by travel path	Rarely	Usually, by location sort order	Yes, optimised, and configurable per zone
Directed put-away by rule	No	Basic rules	Yes, on capacity, velocity, hazard, temperature
Batch, wave and zone picking	No	Sometimes, in simple forms	Yes, this is the core of the product
Task interleaving	No	No	Yes — put away on the way back from a pick
Replenishment of pick faces from bulk	Manual	Rule-based, simple	Yes, triggered and prioritised
Slotting analysis and re-slotting	No	No	Yes, usually as a separate module
Cartonisation and pack planning	No	No	Yes
Labour standards and operator productivity	No	No	Yes
RF and voice device support	Limited	Barcode scanning, mobile screens	Full, with device management
Cost	Included	Included, plus scanners	Licence, implementation, and a permanent interface

Read that table from the bottom up, because the bottom rows are what people buy and the top rows are what they need. A warehouse walking four hundred metres per order has a problem in row two, not row eight. Row two is available in almost every mid-market ERP inventory module in the world, and it is switched off or unconfigured in most of the ones I have looked at.

Four numbers that decide it

Stop discussing the warehouse in adjectives. Produce these four figures for last month and the decision mostly makes itself.

Picks per day, counted as lines, not orders. An order for one line and an order for forty are not the same work. Count the lines picked per day, averaged across a normal month, and separately record the peak day, because peaks are what break a manual process rather than averages.

Active picking locations. Not the number of racks, and not the theoretical number of bin positions. The number of distinct locations a picker might have to visit in a normal week. A warehouse with forty active faces and a warehouse with four thousand are not the same problem, however similar the square footage.

Control requirements per line. What proportion of picks must capture a batch, an expiry date or a serial number at the moment of picking, and what proportion must obey a rule about which one to take — first expiry first out, or a minimum remaining shelf life a customer's contract demands. This axis has nothing to do with volume and it can force capability into a small warehouse.

The labour cost of the current pick path. Number of pickers, hours paid, fully loaded cost per hour, and — the important part — an estimate of what share of that time is spent walking, searching or waiting rather than handling goods. You do not need a study to get this. Follow two pickers for two hours with a stopwatch and a clipboard. The rule of thumb across manual picking operations is that travel is the largest single component of a picker's time, commonly put at around half, and it is the component that responds most to changes costing nothing.

Those four numbers plot into three broad regions. The bands below are shapes, not thresholds to be quoted at a board meeting, and they move with how much of the day is peak.

Where you sit	Lines per day	Active locations	Sensible answer
Small and simple	Up to a few hundred	Tens	ERP inventory, location sort order, barcode scanning. A WMS here is a cost with no return
The wide middle	Several hundred to a couple of thousand	Hundreds	Almost always ERP inventory configured properly, plus scanners and a slotting review. This is where money is most often wasted on a WMS
Genuinely large or genuinely complex	Several thousand upward, or multiple shifts and waves	Thousands	A WMS earns its place, particularly with mixed case and piece picking, cross-docking or serious serialisation
Small but heavily regulated	Any	Any	Judge on control, not volume. Sometimes the ERP module plus enforced batch rules is enough; sometimes it is not

The pick path problem, which is usually the whole problem

If travel is half the picker's time, then the sequence of the pick list is the highest-value thing in the warehouse, and it is set by a sort order.

A pick list sorted by item code sends the picker on a route determined by an alphanumeric coincidence. A pick list sorted by location, where the location codes were assigned in the physical order a person walks the building, sends him on a single pass. The difference on an eight-line order is routinely a factor of two or three in distance, and it costs nothing but the discipline of numbering the racks in walking order and setting one sort field. That is the first move, and almost nobody makes it before shopping for software.

The second is slotting. In every warehouse a minority of items account for the majority of picks, and in most warehouses those items sit wherever there was space on the day they arrived. Moving the highest-frequency items to the locations closest to dispatch, at waist height, shortens every route and reduces the handling injuries as well. This is a weekend with a forklift and a movement report, and no software will produce that step change again afterwards.

The third is picking more than one order per trip. Batch picking — collecting the same item for several orders in one visit, then sorting at a bench — collapses travel when orders are small and overlapping. It needs a sorting discipline and a place to put things, not a system. Zone picking, where each picker owns an area and orders are consolidated at the end, scales further and needs slightly more coordination.

Only after those three have been done does the marginal value of a WMS's optimisation become visible, because a WMS optimises the route within the layout it is given. Handing it a badly slotted warehouse produces the same walk, directed more precisely.

Put-away, which decides everything downstream

Where goods land when they arrive determines every pick for the rest of their life, and it is usually decided by a forklift driver looking for a gap.

Fixed locations mean each item always lives in the same place. Everyone learns the building, finding things does not require a system, and the cost is space: you hold empty capacity for every item at its peak, all year. Fixed slotting works well with a modest item count and stable range, which describes a lot of manufacturing stores.

Random locations mean goods go wherever there is a suitable gap and the system records it. Space utilisation improves substantially. The price is absolute dependence on the system being right — if a bin record is wrong, the goods are effectively lost, because nobody knows where to look. Random storage without scanning at the moment of put-away is not a strategy, it is a way of hiding inventory from yourself.

The hybrid is what most well-run warehouses actually do: fixed pick faces for the fast movers, sized to hold a day or two of demand, with random bulk storage above and behind, and a replenishment rule that refills the pick face from bulk before it empties. This gives short pick routes and good space use at once, and it is configurable in a competent ERP inventory module without buying anything.

Whatever the rule, some constraints are not negotiable and belong on the location rather than in someone's memory: weight limits, temperature-controlled areas, chemical segregation, and the separation of quarantined or rejected stock from released stock. In a food operation, the expiry date carried on the lot with first-expiry-first-out enforced on picking is a put-away and picking rule before it is a report, and it is the single most effective control against a category of write-off that everybody accepts as inevitable.

Barcode versus paper

This is the change with the best return in the whole discussion and it is far cheaper than a WMS.

Paper picking has a defect rate nobody in the building can quote, because the errors are discovered by the customer. Two similar codes, a hurried transcription, a quantity written as 12 that was 120. Scanning at the moment of the action — scan the location, scan the item, key the quantity — turns a transcription task into a confirmation task, performed in front of the goods rather than at a desk twenty minutes later.

Three details determine whether it works.

Scan where the action happens. A batch of scans done at the end of a shift from a stack of paper reproduces every error of the paper process and adds a false audit trail.

Barcode the locations as well as the items. Scanning the item alone confirms what was taken and not where it came from, which leaves the location record — the thing random storage depends on — unverified.

Do not put a scanner in front of an inaccurate stock record. Scanning enforces the record. If the record is wrong, the picker is now blocked by a system telling him confidently that the item he is holding does not exist. That is how scanning projects get abandoned in month two, and the fix is upstream: the counting loop that makes the stock figure true has to be running first.

The case for not buying one

Vendors are honest about what a WMS does and quiet about what it costs beyond the licence. Three arguments deserve to be made properly, because they win more often than they are heard.

It creates a second system of record for the same physical goods. The ERP holds stock for valuation, purchasing and order promising. The WMS holds stock for movement. Now there are two, and they will disagree — after a failed message, an emergency correction made in one and not the other, a cancelled order, a return handled by a person in a hurry. The reconciliation between them becomes somebody's permanent job, and the answer to "how much do we have" acquires a follow-up question about which system you mean. This is the general shape of the integration problem in its most operational form, and the cost of it does not appear in any business case.

The interface is permanent and it is not simple. Item masters, stock movements, receipts, orders, allocations, returns, adjustments and cycle counts all cross the boundary, and each direction needs error handling for the case where the far end rejects a message. Both products will change versions on their own schedules. This is a standing tax, paid annually, in money and in the attention of whoever gets called at seven in the morning when the interface is stuck.

The underlying problem is usually layout, slotting and data. A WMS applied to a warehouse with 78 per cent stock accuracy, no location numbering discipline and fast movers scattered at the back does not fix any of those. It executes the same bad geometry faster and it makes the accuracy problem more visible and more painful, because now the system is directing people to bins it believes are correct.

There is a fourth argument that is less comfortable. A WMS assumes an operating discipline — scan every move, no undocumented transfers, no manual overrides — and a warehouse that cannot sustain that discipline today will not acquire it by purchasing software. The discipline is the change project. The software is the easy half.

When it genuinely is the right answer

There are cases where the ERP module runs out, and they are recognisable.

Multiple picking waves per day with cut-off times, where the sequencing of work across a shift is itself a planning problem. Mixed pallet, case and piece picking with cartonisation. Cross-docking, where goods are allocated to outbound orders before they are put away. Serialisation at scale, where every unit is individually tracked and the volume makes manual capture impossible — regulated device distribution reaches this point at lower volumes than most industries, because the trace obligation does not scale down. Labour management as a real management practice, with standards and measured performance per operator. And any degree of automation — conveyors, sorters, carousels — which needs a system built to talk to equipment.

If two or more of those describe you, the conversation is worth having properly. If none of them do, the honest recommendation is to spend a fraction of the money on scanners, location numbering, slotting and a counting programme, and revisit in eighteen months with real figures.

What to do first, in order

Number the locations in the order a person physically walks the building, and sort every pick list by that field. Measure lines per hour before and after; the difference will surprise people who have worked there for years.

Run a movement report and re-slot the top few per cent of items into the nearest, most accessible faces. Repeat it every six months, because ranges change and slotting decays.

Barcode the locations and the items, and scan at the point of the action. Fix the stock accuracy that the scanning will immediately expose.

Set put-away rules so that arriving goods have a defined destination rather than a discretionary one, with fixed faces for movers and rules for the constraints that matter.

Then measure the four numbers again. If the picking is still the constraint after all of that, you have a real case for a WMS, you know exactly which capability you are buying, and you will specify the interface boundary properly — which system owns stock of record, how returns and adjustments flow, and what happens to an order in flight when a message fails.

Most companies never reach that point, and the money stays in the business. If the warehouse is the reason a wider project is being considered, it is worth putting a figure on what the current pick path and the current error rate actually cost before anyone quotes for software; the cost of chaos estimator gives a rough shape, and the sequencing question — configure what you have or add another system — is the same one that runs through every process automation decision worth making.