A warehouse management system is a system of record for one building. The disappointments tend to trace back to buying it in order to answer a question that lives outside that building, or underneath it.
I made that case on episode 213 of The Manufacturing Executive, hosted by Joe Sullivan. The audience is mid-size manufacturers, which is why this is the conversation where I spent the most time on what a warehouse system isn't. That turns out to be the more useful half for everyone else too.
Every quote block below is me, on the episode, condensed for reading.
Where the System of Record Stops
The ERP is your system of record across the whole business. It does a lot of different things, a lot of modules out there. A warehouse management system is more focused in that sense. It's the system of record within the four walls.
Joe asked what makes a real WMS different from whatever shipped inside the ERP. The scope answer is the important one, and it cuts in both directions. Inside the four walls the warehouse system knows more than the ERP ever will. Outside them it knows nothing, and there's a specific place manufacturers discover that:
You can have your raw materials, you deliver them to a line, and you lose all visibility. You know it's there, but you can't see it until it pops out the other end as a finished good.
There's another system, a manufacturing execution system. MES. It does great on the shop floor, dealing with all those intricate processes, managing the production lines. That's something that would play well with a warehouse management system, but that a warehouse management system won't do on its own in most senses.
Vendors will say yes to work orders, because they do support work orders in the sense they mean it. What they support is inventory leaving a location and finished goods arriving at one. If what you need is the middle, that's a different category of system, and no configuration budget converts one into the other.
A warehouse system is authoritative about inventory being moved and stored. The moment inventory is being transformed, you are outside what it was built to know, and that line doesn't move.
This matters well beyond manufacturing. Kitting, light assembly and repack are the same question in miniature. The test is whether the work happens to inventory sitting somewhere, or to inventory being changed into something else, and what the company calls itself doesn't come into it.
The Demo Doom Loop
One thing I call out, and I've coined it, or I just happened to be lucky and discover it with somebody else, is this concept of a demo doom loop. You recognize that you need a solution, and someone on your team will go out and start talking to vendors asking for general demos. And it more or less boils down to, I'll know it when I see it. But in reality, it's not necessarily that obvious.
So it breeds this concept of FOMU. Fear of messing up. I don't want to stick my neck out if I don't have a good sense of, is this the right solution for me? And it can lead you to buying or picking one for the wrong reasons.
You don't yet have criteria, so you go look at systems, hoping the criteria will emerge from the looking. They don't. Every demo is competent, because every demo is built to be. Nothing gets disqualified, so there's always one more worth seeing.
The demo doom loop is what happens when vendor demonstrations are used to work out what you need. Nothing in a demo can disqualify anything, so the loop ends when somebody gets tired or a date arrives.
Nobody inside the loop is structured to break it, which is a separate argument I made elsewhere. The buyer's half is fixable on your own: decide what would rule a system out, in writing, before the first call. Then a demo has something to fail.
Some of It Is Going to Get Slower
It's not always going to make your processes more streamlined. When you get into this next layer of control, you're tracking all these activities. You might have been able to push a button in the ERP world and it suddenly takes care of something. Here you're going through and tracking all those activities. You see what happens, you get some timestamps, you get some accountability on who's doing what. That means there's going to be some parts of your process that slow down, but net, you're making big strides forward.
A step that used to be one keystroke becomes several scans performed by a person walking. The net is still strongly positive or none of this would be worth doing. Some individual steps get worse, and the business case should name which ones.
A system that adds control adds steps. A projection that shows only the faster ones is describing a different building than yours.
It also reframes the customization question. Some of that friction is the system doing its job, and some is the system fighting a process that should change, and telling those apart is most of the work.
The Data the System Inherits
What I typically use as an example is dimensions at the SKU level. The physical characteristics of your inventory. Those aren't necessarily captured in the ERP, and if they are, they're not always done consistently or accurately. Somebody might put some information in, another person does it a different way, and then you rinse and repeat a thousand times, and you have this swiss cheese of data.
A warehouse system doesn't repair that. It consumes it, and then makes decisions with it. Directed putaway, cartonization, slotting and travel optimization are all math performed on dimensions, and math on bad dimensions produces confident, wrong instructions at scale.
The other half of the inheritance isn't in a field at all:
In a manufacturing scenario, or something that's regulated, there might be inventory that can't be placed next to other inventory. Allergens can't be mixed. You might have chemicals that are dry versus liquid, and you don't want the liquid above the dry. There's all these different rules, and at this point it typically lives more in somebody's head than somewhere documented that's easily referenceable.
Every constraint that currently lives in an experienced person's judgment has to become a rule the system can enforce, or it stops being enforced the day the system starts directing the work.
That gap is how a rollout goes live successfully and still disappoints. The system did what it was told. It was told less than the person it replaced knew, which is the same gap behind outgrowing an ERP's warehouse module in the first place.
Sometimes the Answer Is a Different ERP
When you don't have those things consistently applied in your ERP, it limits the mileage you're going to get out of the WMS. Sometimes that implies you're not ready for a WMS yet. You're ready to look at another ERP.
That's an expensive sentence to say out loud to somebody who called you about a warehouse system, and it's why the assessment comes before the vendor conversation. The sequencing has a price attached:
You don't want to put a WMS in and then replace the ERP afterwards, because now you've just added more complexity, more integration pain down the road. You have to revisit what you did to make the two systems talk together in the first place.
Being integratable and integrated are vastly different, especially when you're working with multiple vendors.
Every system in both categories is integratable. That word means a documented interface exists. Integrated means somebody reconciled two different ideas of what a unit of measure is, decided which system wins when they disagree, and built the thing that handles the disagreement at two in the morning. Replacing the ERP afterward means paying for that reconciliation twice.
The order you buy in is a cost decision, settled before either purchase by whichever problem is the real constraint.
So the ERP vendor's recommendation deserves a harder look than it usually gets, and the module you already own is the right place to start rather than the thing to route around.
What's Changed Since July 2024
We offer clarity first, and it's not necessarily broadcast yet. I'm still working through taking my model down from 12 weeks down to effectively less than two.
That landed. It's the System Fit Sprint now, deliverables two weeks after the final onsite, with a published price and a published scope. The 90-day action plan I describe on the episode, and the option to continue together for months afterward, are both gone. Three fixed deliverables, and no implementation services at all, because staying out of implementation is what keeps the recommendation worth anything.
The audience has narrowed too, and this episode is a fair place to say where the edge is. The work is built for 3PLs and distributors whose operations run on rules they don't set: client SLAs, retailer routing guides, lot traceability with legal teeth. Manufacturers with a real distribution operation share that problem. Manufacturers whose problem is on the production line do not, and that's the same boundary as the first section of this page.
The most useful answer an outside read can produce is that you're about to buy the wrong category of system. Nobody selling either category can give you that answer.
