We picked the wrong WMS. What now?

Two questions sit underneath this one. The first is whether the system is actually wrong, or whether what's wrong is what got built on it. The second is what to do about it depending on which answer the first one returns.

The first question is harder than it looks from where it's being asked. By the time a founder concludes the WMS is the wrong WMS, the implementation has usually accumulated enough problems that the system has become the most visible explanation. Some of those problems do trace to the system itself. Others trace to a configuration that was built against an inaccurate picture of the operation, or to operational readiness gaps the implementation phase wasn't structurally set up to fix. The conclusion we picked wrong is sometimes the right diagnosis and sometimes the most available explanation for a problem with multiple structural sources. Disentangling which is which is harder mid-failure than it would have been earlier, because more variables are confounded.

If the system is configuration-wrong rather than fundamentally-wrong, the path forward usually doesn't involve replacement. It involves going back to the operational picture, building it accurately this time, and rescoping configuration against what's actually true on the floor — work that should have happened before the system was selected and that's now being done under worse conditions, with sunk costs in the way. This isn't a comfortable path. It's usually the right one when the system itself can support the operation and what's failing is what got built on top of it.

If the system is fundamentally-wrong — wrong category, wrong architecture, wrong product for the operational realities that are now visible — then no amount of reconfiguration closes the gap. The system cannot do what the operation needs it to do. In that case, the question becomes how to exit on the best available terms: whether the implementation can be paused, what the contract actually permits, what the practical cost of switching is, and whether the operation can run on the current system in a degraded mode while a real selection process happens. None of that is a good situation. Some of it is recoverable. Most of the recovery comes from the next decision being made through a process that closes the gaps the first one left open.

The structural observation worth holding through both paths is that picking the wrong WMS is rarely a mistake the founder made through carelessness. It's usually the predictable output of a selection process that was structurally compromised before the founder ever sat down to demos. Every input the founder collected — peer recommendations, vendor presentations, reference calls — was shaped by someone with a stake in which system would be selected. The shortlist reflected vendor visibility more than operational fit. The vendor evaluation ran through a buyer-only frame that the questions vendors are designed to answer are specifically built for. The selection that resulted reflected the inputs accurately. The inputs were the problem.

This isn't offered as consolation. It's the same observation that determines what to do about the next selection, if there is one. The founder who concludes we picked wrong and then runs the next selection the same way is likely to pick wrong again, because the inputs haven't changed. The founder who concludes the inputs were the problem has a different starting point — and a different chance at a different outcome.