5 Mistakes That Kill a WMS Rollout (and How to Avoid Them)

In this episode of Rozmowy Logistyków, Piotr Skobało and Adam Sobolewski share experience from over a dozen WMS deployments. They talk about what can go wrong, and why some of these projects never finish at all, drawing lessons from 5 real mistakes seen at different companies.

HOW MUCH A WMS COSTS, AND WHAT IT DEPENDS ON

The cost of deploying a WMS ranges from tens of thousands of złoty for a simple mini-warehouse solution to several million for complex, multi-site projects at global operators. When evaluating vendors, roughly 250 system features are typically mapped — from basic functions to detailed integration capabilities — and the payment-model decision (a one-time fee vs. SaaS spread over years) is a separate financial thread that needs its own analysis.

MISTAKE 1: AN IMPRECISE NEEDS ANALYSIS

A project that starts with the sentence "we want to deploy a WMS" without spelling out specific functional requirements is the easiest way to blow the budget by 50-100%. If 40 processes get mapped instead of the real 70-80, the budget reserve runs out halfway through the project. The needs analysis also has to look at least two or three years ahead — the example of a spare-parts distributor who, halfway through an 18-month WMS rollout for the B2B channel, suddenly remembered its plans to enter e-commerce (small-item picking, courier integration), shows how costly it is to leave future sales channels out at the start. It's worth bringing in an external consultant even just for this stage — a single "outside eyes" Q&A session opens people's eyes to gaps in the mapping.

MISTAKE 2: INSUFFICIENT INVOLVEMENT OF OPERATIONAL STAFF

The statistics on WMS deployments aren't encouraging: out of 10 projects, around two end in total failure, and another three run with serious problems. The main reason isn't technology, it's how the change is managed — if the project is communicated to employees as "your processes are dumb, now we'll do it smart," a shift supervisor or team leader effectively sabotages the rollout, openly or passively. A real case: a logistics operator where employees openly boycotted the rollout, because management never explained that the system wasn't meant to cut headcount — a year and a half later, the deployment is still stalled.

MISTAKE 3: INSUFFICIENT TESTING UNDER REALISTIC CONDITIONS

Tests run by the project team's own experts (too skilled to catch real problems) don't substitute for testing under the conditions rank-and-file employees will actually work in. A concrete example: a picking process tested correctly by a small project team failed in production, because the labels in the warehouse had the racking row numbers swapped relative to what the scanner displayed — for three people who knew the layout, that was a non-issue; for a dozen-plus new employees, it meant total confusion. The software fix took 3 minutes, but the hours of crisis calls and root-cause investigation would have been unnecessary if the tests had reflected a real-world scenario. The other side of the coin: system vendors also have to test rigorously — in one deployment, the vendor admitted after three days of the system running that it couldn't guarantee its stability, and the company reverted to its old solution as a backup within two hours.

MISTAKE 4: TRAINING TREATED AS AN AFTERTHOUGHT

Deployments are usually tested by a narrow group of "power users," but that doesn't guarantee the system will work at the scale of the whole enterprise with 50, 100, or 500 employees on the floor. Training needs to be budgeted as a full-fledged line item in the project, not something that "can be done in half an hour" — a productivity drop after go-live (typically a double-digit percentage) is unavoidable, but how long it lasts depends directly on the quality of training. It's worth setting board expectations up front: things won't be better on day one after go-live, they'll be worse, and that's normal — otherwise all that's waiting is disappointment.

MISTAKE 5: UNDERESTIMATED IT INFRASTRUCTURE

A WMS deployment is a logistics and IT project at the same time, never solely one or the other — a case where the head of IT wrote a year before the planned rollout, "I don't think this will work," shows how costly a lack of collaboration from the very start can be. A practical example: a heavy-equipment trading company only discovered at the testing stage that scanners lost range in the aisles of the warehouse yard where large quantities of steel were stored — a simple network audit done earlier would have allowed the process to be designed around it (e.g. recording picking results in batches, not online) instead of patching the problem at the last minute.