Almost every warehouse system project starts at receiving, because that's where the goods start. It's the wrong end. Nothing at receiving is a promise you made to a customer, and the promises are what the system has to be built to keep.
Ben Hopkins had me on the first episode of The Warehouse Underground in November 2024. He'd seen me post about working backwards and pushed on it harder than anyone has since, partly because he used to plan F-15 missions the same way, starting at the target and working back to the moment you walk into the squadron.
Every quote block below is me, on the episode, condensed for reading.
Start at the Dock and Walk Backwards
I'd love to take credit for it, but it's something I saw, I observed, and I adopted because we got better results from it.
When you're working backwards, starting at the shipping piece, you're looking to see what's important to the customer at that point in time. You have your promises you're trying to keep, and you pay attention to the type of documentation going out, the way the pallets are arranged, some of the labeling pieces. Then you start asking questions in terms of what that means, and that's what drives your requirements. Once you understand why it's important, it's where does that information come from, and you start working your way back.
Walking a warehouse backwards defeats the sentence that kills most requirements gathering. "This is how we've always done it" doesn't survive being asked which customer promise the step serves, and a fair number of steps can't answer.
Then you turn around and walk it forward:
Once we have that, we walk it forward again. Great, it's effective, but that's dog slow over there. How do we add something to it? Let's go back and layer in some complexity, maybe different modes of picking, whatever it is to get better mileage out of it.
Effective first, efficient second, and in that order deliberately. Optimizing a step you haven't yet justified is how you end up with a fast version of something you didn't need. Walking it that way also produces a description of the operation organized by flow rather than by department, and that description is what an evaluation actually needs.
Why Picking Gets Over-Indexed
The other variation I see is overemphasizing picking. It's the shiny object. You get the folks that are not in operations, and those are the metrics they think about, so they're always asking about it. But more often than not, you try to optimize something in the picking piece of the operation and you introduce bottlenecks upstream and downstream. It turns into a game of whack-a-mole.
Picking is the most legible part of a warehouse from a conference room. It has a rate, the rate has a number, and the number moves. That makes it the easiest thing to fund and the easiest thing to over-fund.
Picking is where the labor is most visible, not where the constraint necessarily is, and a system configured around the visible number will move work into the parts nobody was measuring.
Nobody Sells You the Mileage
Ben put it better than I did. If you buy a Corvette, nobody teaches you to drive like a racer. They show you what a few of the buttons do.
To continue with your analogy, they could care less. You might just park it in your garage and never pull it out. In the software side of things, you're buying access to something. The ability, but not necessarily the success or the great mileage out of it.
Especially in my world, where I'm working with folks pursuing their first WMS, there's that expectation that the vendor is going to know how you best use it and ensure that you get all the mileage out of it. That's just not the reality. If it was, I wouldn't have the work, and I wouldn't have the horror stories that I do.
A software contract transfers access, not outcomes, and every party at the table knows that except the one buying for the first time.
That makes it an allocation question rather than a trust question. The vendor is authoritative about the product and is not the party who knows what your operation needs from it. Where nobody fills that seat, the system quietly stops getting used, and the company concludes it tried a WMS and it didn't work.
Integrated and Integratable
There's a difference between integrated and integratable. Most of the time when you're dealing with a WMS, it's integratable with other systems, especially the highly capable ones.
The reason the gap between those two words costs so much is that both systems have been configured, and configuration is where uniqueness lives. Your WMS has things nobody else's has. So does your ERP. The interface between them has to reconcile two sets of decisions that were made independently, by different people, for different reasons.
You ship something out, you send a message back from the WMS saying this order is done, bill it out to the customer, and something fails. Now they've got the goods and you can't guarantee it and you didn't get paid for it. That's just one little silly scenario. There are thousands.
Integratable means a documented interface exists. Integrated means somebody has decided what happens when the two systems disagree at two in the morning, and only one of those is in the quote.
So the testing that matters is the testing designed to break things. The happy path is easy to demonstrate and easy to sign off, and it's the scenario least likely to be the one that hurts you.
Fred and the Allergens
I want Fred not to be in the middle of the putaway selection anymore, because I want to take everything he knows in his head and bake it into the system. The system can see every location and all kinds of things a person can't see unless they physically go out there.
But if the system can't look at information to know you might have two allergens that can't be stored next to each other, Fred knows this because he's a person. He knows the relationship. Now you can't tell the system how to make the determination, and bad things happen.
The second failure costs more than the first:
Or you put the system in, and the people are going to know, I can't trust that recommendation for putaway. I'm just going to do what I want anyway.
An operator who has learned that the system's recommendations are wrong will keep working around it long after the data is fixed, because trust in a system is rebuilt far more slowly than it is lost.
That makes master data a people problem with a technical surface. Dimensions and units of measure entered inconsistently over years produce something you can't trust, and the system's confident wrong answers train the floor to stop reading them. That gap is the same one behind what an ERP module can and can't hold.
What's Changed Since November 2024
The framework I describe here as Clarity First, a two-day onsite deep dive and a 90-day action plan, is the System Fit Sprint now. The backwards walk survived intact, because it's the part that works. What changed around it is the shape of the commitment: a published price, a published scope, and three named deliverables landing two weeks after the final onsite, rather than a plan whose contents you found out about by receiving it.
The method didn't need fixing. What needed fixing was that a buyer had no way to know what they were buying until after they'd bought it. That's the same complaint I make about vendors on this episode.
