Stop Picking Solutions. Start Picking Problems.

I was with a client who wanted to speed up order filling because it was consuming a lot of labor. On the surface, that sounded like the obvious problem to solve. A lot of people would have looked right there first, and honestly, I understand why. When one part of the operation is pulling that much labor, it gets everybody’s attention fast. It feels like the cleanest place to go make an improvement.

But we stopped and looked at what happened after the orders were filled.

That changed the whole conversation.

Shipping was already tight. The dock was already the constraint. So if we had made order filling faster first, we would not have solved the real problem. We would have just pushed more product to a dock that could not handle it. The output from picking would have improved on paper, but the operation itself would have gotten worse. Product would have piled up at the door, and now you are dealing with a new mess created by your own improvement.

That is the kind of thing people miss when they get locked onto the first problem they can see.

Order filling was not a fake problem. It was using a lot of labor. That part was real. The mistake would have been assuming that because it was visible, it had to be the first thing to fix. That is not always how operations work. A process can feel slow in one spot because another spot downstream is already limiting what can actually move through the building.

That is why I always want to follow the work one more step.

In this case, once we looked downstream, the answer changed. The question was no longer, “How do we make order filling faster?” The question became, “What happens if we do?” And the answer was pretty clear. We would just feed more volume into a part of the process that was already struggling. That is not improvement. That is just moving the pain to a different location.

So we stopped, regrouped, and worked on shipping first.

That may sound simple, but it is an important discipline. A lot of bad automation decisions start when somebody sees one painful area, then starts looking for equipment to speed it up before they understand whether speeding it up will actually help the operation. A robot can be useful. An AMR can be useful. A storage system can be useful. A sweeper can be useful. But none of that matters if you are solving the wrong problem first.

Equipment is a tool. It should come after the process is understood, not before.

I think that gets lost because equipment is easy to picture. You can see it. You can demo it. You can imagine it running. What is harder is standing in the operation long enough to see where the work actually stops. That part is less exciting, but it is where the decision gets better.

What I liked about this client example is that it is a very normal mistake. Nobody was being careless. Nobody was chasing something ridiculous. They were looking at a real labor draw and trying to improve it. That is exactly why the story matters. A smart team can still end up pointed at the wrong first project if they do not trace the process all the way through.

That is also why I do not like starting with the machine. Once people get attached to a piece of equipment, they naturally start trying to make the operation fit the tool. They go hunting for justification. The better move is to stay with the process long enough to understand what fixed would actually mean. In this case, fixed did not mean filling more orders faster. It meant getting product through shipping without creating a pileup at the dock. Once that was clear, the order of decisions got a lot cleaner.

That is the whole point of the story.

Before you speed up one step, follow the work to the next one. See where it backs up. See what happens if the first step starts producing more. Then decide what needs to be fixed first, and only after that decide whether equipment belongs in the answer.

A lot of money gets wasted when people improve one part of a process without checking what happens next. In this case, faster order filling would have looked like progress for about five minutes, right up until product started stacking up at the dock.

That is why I keep coming back to the same basic idea. Pick the problem first. Then pick the tool. If you do that in the wrong order, you can make the operation worse while telling yourself you improved it.