WMS: What It Actually Does, and What It Will Not Do

Ask five people in a warehouse what a WMS is and you will get five answers, most of them describing the stock module in an ERP. The distinction matters more than it sounds, because it decides whether a system can tell someone what to do next or can only record what they already did.

This is a practitioner's view of what a warehouse management system actually does, where the boundary with ERP sits, and the three things that kill WMS implementations long before go-live.

The one-sentence difference between ERP and WMS

Your ERP knows what you own. A WMS knows where it is, in what condition, in which unit, and who last touched it.

That sounds like a detail until you try to run a pick. An ERP stock record says you have 400 units of an article. A WMS says 120 are in pick location A-12-3 in eaches, 240 are on two pallets in bulk location R-04, and 40 are in quarantine pending a QC decision. Only the second answer lets you send someone to fetch 60 units without them wandering.

The practical test: can the system direct work, or only record it? If it produces a pick list sorted by article number rather than by walking route, and if it cannot tell you which of three locations to take stock from, it is a stock module. That is not an insult — plenty of operations run perfectly well on one. It is just not a WMS, and buying it expecting WMS behaviour is the most common disappointment in this category.

Directed work is the whole product

The value of a WMS is concentrated in a handful of decisions it makes on your behalf, every time:

Which location to pick from, given FEFO or FIFO rules, whether a batch is blocked, and how much walking each option costs.
Where to put stock away, based on velocity, dimensions and the existing contents of nearby locations.
When to replenish a pick face from bulk, ideally before the picker arrives to find it empty rather than after.
In what sequence to release work, so that a wave of orders becomes an efficient set of routes instead of many overlapping ones.

Notice that each of these is a small optimisation applied thousands of times a day. That is why WMS business cases are usually built on picking productivity and stock accuracy rather than on any single dramatic saving, and why they are sensitive to whether people actually follow the direction the system gives.

The three things that kill implementations

1. Master data that cannot support slotting

Slotting and putaway logic need to know how big things are. Dimensions, weight, units per case, cases per pallet, whether an item can be stacked and whether it can share a location with another article.

Most warehouses discover during implementation that their article master has none of this, or has it for the 200 SKUs someone measured in 2019 and not for the 4,000 added since. Measuring the range is unglamorous, slow, and cannot be shortcut by the software. It is the single most common reason a WMS project runs late, and it is entirely predictable — which means it can be started before you have chosen a supplier.

2. A scan infrastructure that fights the process

Every confirmation step in a WMS is a scan, and every scan is a second or two of someone's day plus a small chance of a misread. Design the flow badly and you add scans that prove nothing: scanning a location you were directed to and could not have reached by accident, scanning a carrier that only ever holds one order.

The counter-error is worse and more common in reverse: removing so many confirmations that the system's picture of the warehouse drifts from reality, and nobody notices until a cycle count says so. The judgement is about which steps carry real risk of being wrong, not about minimising taps.

3. Nobody owns the exceptions

A WMS is excellent at the normal case and needs a human for everything else: a short pick, a damaged pallet, an item that will not scan, a location that contains something the system says it should not. If there is no named person and no defined route for these, they are resolved informally — usually by someone overriding the system — and the data quality that the whole business case rests on erodes quietly from week one.

Where WMS stops and WCS or WES begins

If you have conveyors, sorters, AS/RS or AMRs, there is a second layer of software beneath the WMS. A warehouse control system (WCS) drives the equipment; a warehouse execution system (WES) sits between, balancing work across resources in real time.

The boundary matters commercially because vendors draw it differently. Some WMS products include enough execution logic to run modest automation; some automation suppliers ship a WCS that quietly performs WMS functions and then constrains your choices later. The question to ask a supplier is not "do you integrate with automation" but "which system decides the sequence of work, and which one just carries it out?"

What the ERP integration actually looks like

In almost every case the shape is the same: orders and expected receipts flow down from the ERP, confirmations flow back up. What makes it non-trivial is not the direction but the partials.

A receipt arrives short. Does the ERP hold the purchase order open, and does the WMS know it is allowed to accept the remainder tomorrow?
An order is picked incomplete. Does it ship as a partial with a backorder, or wait? The answer usually differs per customer, which means the rule lives in one system and the execution in the other.
Stock is corrected in the WMS after a cycle count. Does it write back as an adjustment with a reason code, or as a silent overwrite the finance team discovers at period end?

These are the questions that turn a two-week interface into a two-month one, and they are answerable during selection rather than during build.

When you do not need a WMS

Honestly: if you have a few hundred SKUs in fixed locations, low order volume and stable staff who know where things are, a WMS will add administration without adding much accuracy. The threshold is less about size than about variability — many SKUs, seasonal peaks, temporary staff, batch or serial tracking, or a customer who demands traceability. Any of those makes the human memory that has been holding the operation together unreliable.

The cheaper intermediate step is often barcode scanning against your existing stock module, which buys accuracy without buying directed work. It is a legitimate destination, not only a stepping stone.

Picking strategy is a WMS choice, not a floor decision

How you pick is usually described as an operational preference. In practice it is constrained by what your WMS supports, which is why it belongs in selection rather than in the first month after go-live.

Discrete picking — one order, one picker, start to finish. Simple, easy to hold someone accountable for, and the least efficient by walking distance.
Batch picking — one picker collects the same article for many orders in one pass, then the orders are sorted afterwards. Efficient for many small orders sharing a narrow range; requires a sort step and somewhere to put it.
Zone picking — each picker owns an area and an order passes between zones. Reduces walking sharply, introduces handover and the risk of an order sitting in a zone nobody is working.
Wave picking — work is released in planned blocks aligned to carrier cut-off times rather than continuously. Powerful for hitting a 17:00 truck; unforgiving when a wave is planned badly.

The question for a supplier is which of these the system can run at the same time, because most operations need more than one: batch for e-commerce singles, discrete for large B2B orders, waves during peak. A system that supports only one forces the operation to fit the software.

Cycle counting is what replaces the annual stocktake

A WMS earns much of its accuracy claim through cycle counting: counting a small number of locations continuously instead of closing the warehouse once a year. It is the mechanism by which the system's picture is kept honest.

Two practitioner points that rarely make it into vendor material. First, count by location, not by article — counting an article means visiting every location that holds it, while counting a location is a bounded task someone can finish. Second, the count that matters is the one on an empty location: if the system says a pick face holds twelve and the picker finds nothing, that is a discrepancy you want surfaced immediately, and a good WMS lets the picker report it as a zero-count on the spot rather than as an exception ticket.

Set the counting frequency by value and velocity rather than uniformly, and expect the first months to be noisy — early counts measure the accuracy of your data migration as much as the accuracy of your operation.

How we approach it

A WMS selection is a process question before it is a software question, which is why we start with a €2,500 audit: current flows, master-data readiness, integration points and the honest question of whether directed work is the constraint. Where AI is genuinely useful in a warehouse it is usually narrow and specific — demand forecasting feeding replenishment, or vision-based checks at pack-out — not a replacement for the WMS itself. If a build follows, a €20,000 proof of concept runs on your data for four to six weeks, and production starts from €50,000.

Frequently asked questions

Is a WMS the same as the warehouse module in my ERP?

Usually not. The test is whether the system directs work or records it. A WMS decides which location to pick from and in what sequence; an ERP stock module records that a quantity moved.

Some larger ERPs have genuine WMS modules with location management and directed work — check for slotting, replenishment and wave logic specifically, not the label.
If pick lists come out sorted by article number rather than by route, you have a stock module.
The ERP stays the system of record for ownership and value; the WMS owns location, condition and unit.

What data do we need before a WMS implementation starts?

Article dimensions and weights across the full range, units per case and cases per pallet, plus location dimensions and any stacking or compatibility rules. This is the work that most often delays go-live and it does not require a chosen supplier.

Measure by velocity: the fast-moving 20% of SKUs cover most of the picking, so start there and you can go live on a partial set.
Decide the unit hierarchy explicitly — each, inner, case, pallet — because the WMS will force the question anyway.
Budget real time for it. A range of a few thousand SKUs is weeks of measuring, not days.

How long does a WMS implementation take?

For a single site without automation, three to six months is realistic, and the variance is driven almost entirely by master data and integration rather than by the software.

Add time if the ERP interface has to handle partial receipts, backorders and stock adjustments with reason codes — those three account for most interface overruns.
Automation pushes it out considerably, because the WCS/WES boundary has to be agreed and tested with equipment that arrives late.
Go live in one flow first — usually outbound picking — rather than switching the whole site in a weekend.

Where does AI genuinely help in a warehouse?

In narrow places, feeding decisions the WMS already makes — not as a replacement for it.

Demand forecasting improving replenishment timing and slotting, so fast movers sit closer to dispatch before the peak rather than after it.
Vision checks at pack-out, catching wrong-item and wrong-count errors before they become customer complaints.
Anomaly detection on stock movements, surfacing the locations where the system's picture and reality diverge fastest.
What it does not do is replace directed work. The optimisation logic in a mature WMS is deterministic and well understood, and swapping it for a model makes it harder to explain, not better.