ERP failures get the headlines. A distributor whose warehouse system fails has the same magnitude of problem and almost none of the coverage, because a general ledger that won't close is a story and a building that can't ship is just a bad quarter. If moving inventory is your bread and butter, those are the same event.
I made that argument on episode 159 of Distribution Talk, hosted by Jason Bader. Jason got involved with warehouse systems in the mid-90s and his show is aimed at wholesale distributors rather than 3PLs.
What follows isn't a transcript. It's the handful of things I said on that show that I'd argue harder now, plus the one place I'd push back on Jason. Every quote block below is me, on the episode, condensed for reading.
The Question the Vendor Isn't Structured to Ask
Jason asked what knocks these projects around. I started here:
We always see the best in our businesses. Someone's going to ask you, are your processes well-defined? The gut answer is, yeah, they are. We don't know what we don't know. We're so close to it. We don't necessarily see all the gaps and all the ugly stuff that lies behind it.
Then the part Jason pulled for his show notes:
A vendor won't slow you down and ask those hard questions, because they're not geared to fixing them for you. There's an assumption that you've already done the homework, your people are on board, and that's going to be something you own. But they don't bring that up explicitly. It's just this assumption that kind of goes unsaid.
I said won't. Two years on I'd say it isn't their question at all. A WMS vendor is genuinely authoritative about one thing, which is their own product, and the honest version of "are your processes defined" ends with a qualified buyer deciding not to buy this quarter. Nobody has to be acting in bad faith for that question to go unasked. It has no owner on that side of the table.
The vendor is the wrong party to ask, because every honest answer to that question costs them the deal they're in the room to close.
Which party is authoritative about what, and where each one's incentive bends, is the whole of who you should trust to tell you which system you need.
You're Already on the Clock
There's some external event that's causing urgency, and now the business has to jump. By default, there's going to be assumptions that go unchecked.
The forcing function is usually external. A client lost, a lease not renewed, a retailer rolling out a compliance program, a sponsor with a thesis and a timeline. The urgency doesn't create the unchecked assumptions. It removes the occasion to check them.
They surface anyway, at the worst possible moment:
You get into the design phase and the vendor will ask you a question, and instead of getting one answer like you're expecting, you get four or five. And that's the very beginning of this implementation. Now we have to invest time and get clarity where we thought we had it. And the clock's running. You've already spent this. You have a budget.
Four answers to one question is normal. Often it means four people each solved a real problem their own way and nothing ever forced them to reconcile. The timing is the problem.
You pay for consensus either way. The only question is whether you pay for it at your own rate before you buy, or at the integrator's rate with the meter already running.
Eighty Percent of What You Do, Everyone Does
The operation itself isn't necessarily all that special. About 80% of what goes on there, everyone else does. You're looking for that 20%.
Receiving, putaway, picking, packing, counting, shipping. Every system in the category does those, which means every demo does those, beautifully, because a demo is built to show the part that was never in doubt. Both sides walk out satisfied about the eighty percent and no closer on the twenty that decides the outcome.
The feature requirements are skin deep. Surface level. Lot management? Oh yeah, we support lot management. But you didn't ask those detailed questions that really get into it.
One of those detailed questions is what a lot actually is inside the system. If the lot code and the expiry date are attributes written onto inventory records, nothing stops warehouse A from holding lot XYZ of SKU ABC dated 12/31/2026 while warehouse B holds the same lot of the same SKU dated 12/31/2027. Both are in the system. As far as the system is concerned, neither one is wrong. That is more common than it ought to be.
Every vendor in the category supports lot management. What separates them is whether a lot is something the system understands and constrains across sites and back into the ERP, or two fields it will let you fill in twice with different answers.
Getting to the twenty percent is a writing problem before it's a shopping problem. It's why requirements have to come out of your floor rather than a template, and why the questions you bring into a demo matter more than the demo does.
Your ERP Knows What You Have. It Doesn't Know Where It Is.
Jason asked where the return on one of these systems actually comes from. My answer started with a distinction most distributors have never had a reason to make:
From the ERP standpoint, a lot of times you deal with logical buckets of inventory. I know I have seven pallets in the warehouse. I don't know where each of those seven are, or what's on those.
The cleanest illustration of that gap is a multi-site transfer:
If you have a bunch of different warehouses and you're doing transfers to rebalance inventory, there's a lot of technical complexity there that you may not have today with an ERP. You can click a button and it sucks inventory out and spits it back into another one. You do all the physical stuff, but you didn't have to deal with barcodes.
In the ERP that rebalance is one keystroke and the physical work is invisible to the system. In a warehouse system the same move is a designed sequence of scans that has to be staffed and timed, and as I put it on the show, if you don't factor that in it can be crushing from a labor perspective. The surprise lands in the wrong direction: the new system appears to add work at the moment it was supposed to remove some.
When the module tells you there are seven pallets, it's doing exactly what it was built to do. It keeps the count. A warehouse runs on which pallet, in which location, holding which lot.
That distinction has its own piece now: the warehouse module is already paid for, and that's the problem, alongside the narrower question of whether your ERP's module can handle what you're describing.
The Hours Nobody Counts
Two of the returns I named for Jason don't appear on any report a distributor currently runs, which is why they never make it into the business case. The first is counting:
It gets rid of a lot of the physical counts. Those really expensive, let's stop everything and go from one wall to the next. If you utilize cycle counting on a recurring basis, you never have to stop the facility again.
Worth being precise here, because I wasn't. Plenty of ERP warehouse modules will happily record a cycle count. What they can't support is counting continuously while the building keeps working, and that's a different capability, resting on a location-and-container-level record the module doesn't keep. The savings are in the shutdown you stop scheduling.
The second is travel:
The old adage of I have paper and I'm walking back to some central location to find out what I'm doing next.
A few minutes later I reached for the image distributors already have for that:
You basically just have your truck and there's no trailer on it, and you're spending all this time to drive the resources to get to where it is.
That's bobtailing. A tractor burning fuel and hours hauling nothing. A paper warehouse runs a great many bobtail miles, and none of them belong to a specific order, so none of them appear anywhere you'd think to look.
Bobtail hours never show up on a report, which is why adding volume so often means adding people at close to one for one. The only lever paper gives you is another body walking the same empty aisles.
They do show up somewhere, though, in the same place every other unrepresented process does: as workarounds that keep multiplying without anyone deciding to add one.
What's Changed Since June 2024
Two housekeeping notes and one disagreement.
On the show I call the assessment Clarity First. It's the System Fit Sprint now, with a published scope, a published price and a fixed set of deliverables.
When Jason asked how people find me, I said LinkedIn. There's more to point at these days, including most of the arguments above written down properly.
And there's one place I'd push back on him. Jason closed by saying it's not an if, it's a when, and that he knows distributors at $7 million in revenue running this technology. He's right that it isn't only for the big kids. But revenue is the wrong axis. What decides whether you need a real warehouse system is how much of your operation runs on rules you don't set: a retailer's routing guide, a client SLA, lot traceability with legal teeth, B2B and B2C moving out of the same building.
Size tells you how much warehouse you have. Complexity tells you how much of it the system has to hold on your behalf, and those two numbers come apart far more often than they line up.
A distributor at $7 million carrying all four of those constraints needs this more than one at $70 million carrying none of them.
