What your WMS will never fix

There is one conversation that comes up in almost every first meeting. The operations director describes the problems—inventories that do not match, pickers going round in circles, trucks waiting—then concludes with the sentence that makes us uncomfortable: ‘so we need a WMS’.

Sometimes, yes. Often, not yet.

Here are five things a WMS will not fix. They must be decided beforehand, they are decided without us, and they cost infinitely less than the IT project being considered as a way around them.

1. A location-addressing system that does not exist

This is the number-one issue, by a long way.

Fundamentally, a WMS can do only one thing: tell someone where to go and pick what. If your locations do not have stable, physically legible, unique and consistent names, the software has nothing to say. It will record movements to fictitious addresses, while your teams continue to search by guesswork—with an extra data-entry task on top.

This work does not require an IT budget. It requires a naming decision—aisle–bay–level–position, or whatever system you choose, but chosen once—labels that are readable from a forklift driving position, and someone responsible for maintaining them. It is a few weeks’ work. Everything else depends on it.

2. A load unit that no one has defined

A simple question that rarely gets an immediate answer: when you say ‘a pallet’, what exactly do you mean?

A physical pallet? A homogeneous pallet containing one item? A contractual quantity agreed with a customer? A handling unit that you track individually, or simply a logical grouping?

Until that vocabulary has been settled, everyone involved in the project is talking about something different without realising it. Sales promises lead times by the pallet, the warehouse thinks in cartons, invoicing counts lines, and the system inherits the ambiguity—which it turns into contradictory business rules.

3. Docks sized for the business of five years ago

An oral procedure is not a procedure: it is a habit carried by the people who learned it on the job.

Configuring a WMS means fixing rules precisely: who checks what at receipt, when a delivery is refused, how a discrepancy is handled, who authorises an exceptional issue. If these rules do not exist anywhere in writing, they will be invented during the project—by the integrator, under pressure, with whoever happens to be available that day.

That is how companies end up with systems that rigorously apply rules no one ever thought through.

A warehouse procedure fits on one or two pages. Receiving, put-away, picking, checking, shipping, inventory, returns and nonconformity management: eight short documents, reviewed by the people who do the work. This is not a documentation exercise; it is the raw material for configuration.

5. Inventory records that are wrong

This is the most painful one, because it is discovered late.

A WMS starts with the inventory you give it. If the opening discrepancy is substantial—and it almost always is when inventory was maintained in a spreadsheet—the system spends its first few weeks producing unexplained shortages and impossible picks. Teams conclude that ‘the new software does not work’, and trust never fully returns.

The inventory migration is not an end-of-project formality. It is a workstream in its own right, to be completed beforehand, with independent counts and an explicit decision about how discrepancies will be handled. We recommend treating the migration as a separate deliverable, with its own date and approval—not as a box to tick the day before go-live.

So when does a WMS become the right answer?

When the five points above have been addressed—or at least started—and the remaining difficulty is an information problem: you do not know where inventory is in real time, you cannot trace a batch, you cannot prove a service, you cannot manage productivity, or you cannot absorb more volume without adding more people.

Those are genuine reasons. They justify a project, and its return on investment can be observed.

Conversely, if your difficulty lies in the physical organisation, the software will document it precisely—without solving it.