Warehouse optimization sounds like one of those motherhood statements.
As with many basic concepts the devil is in the details and in the case of warehouse optimization the detail is in the qualiﬁer: What are we optimizing to?
This is not an academic question but one of those that reaches to the heart of warehouse design theory. The key is to recognize that with the wide range of real-life warehouse needs one solution does not meet all needs.
Consider a few practical alternatives and the real life situations where they may apply.
Optimize to maximum cube: In this case the fundamental tradeoff is between accessibility and storage density. A real life example is records storage, where an item once placed in storage may not be accessed for several years.
Optimize to efficient turnover: In this case you want to optimize to speed and also lowest handling cost. A real life example is an LTL (less-than-truckload) truck dock.
Optimize to minimum capital investment: If the boss says we have no capital dollars to spend on warehousing then outsourcing via a third party provider quickly becomes your only practical alternative.
Of course, in the real world most of us do not have the luxury of designing to a single factor. We have to optimize to multiple constraints and one key issue is to how to accommodate the tradeoffs between the various requirements. This begs the question, “Where does one start?”
There is a saying in business, “The customer is always right”. While I don’t agree with it in all cases—for example, if it is going to bankrupt the company—it is a good and usually easy-to-defend decision. In practical terms though, what does optimizing to customer service mean?
A long time ago—pre-Internet days—I was asked to design a Toronto warehouse for an automotive parts business. I was asked for a warehouse design that would allow for delivery of parts to a mechanic with a car on the hoist who has just discovered he needs a part that he did not plan for.
Unlike an automotive dealer, who has a parts department in the same complex, his customers were usually independent garages that serviced many automotive types and did not have an extensive parts inventory.
In addition to supplying the part; my customer wanted an invoice with the delivery, so his customer could bill the end user at job completion.
His objective was for the mechanic—within the greater Toronto area—to not interrupt the job but complete it while the car remained on the hoist. Thus, in practical terms, he needed the part to be delivered in 20 minutes. The geographic area covered Oshawa to Milton from east to west and Aurora to Oakville from north to south.
Thus the supply chain had—within 20 minutes—to be capable of:
1. Taking the order;
2. Doing all warehousing functions;
3. Producing the invoice;
4. Delivering the part.
The ﬁrst problem you face is distance. Even in non-rush-hour trafﬁc, from a warehouse located in Oshawa, getting a part to a customer located in Milton within 20 minutes is impossible. Locating a warehouse in the centre, say at 401 and 400 is still a problem because you still need time to take the order, do all the warehousing functions and produce the invoice. Maybe in the future this will be possible with drone delivery, if it ever takes off.
The only practical warehousing solution is multiple warehouses, not a single site.
Starting at the beginning of the order-taking cycle, one of the ﬁrst issues we faced was the real-world problem of identiﬁcation. In our case the mechanic will not bring in the old part but expects a replacement based on his description. Ask yourself how many mechanics have proper part identity at their ﬁngertips.
The next decision is what inventory do you stock. Given that the average automotive manufacturer has 10s of thousands of parts in inventory, it is fair to say that this inventory decision has huge impacts on all aspects of the warehouse. Another problem is that many of these parts are not very often used, or are only used late in an automobile’s life cycle.
The biggest problem we faced was efﬁciency. Picking single parts and delivering them is expensive and there is not much you can do for efﬁciency if you only have a few minutes to select and ultimately deliver an item.
This example shows one of the risks you face when you emphasize a single factor, particularly one that is service oriented. You can make it work. The problem is whether can you make a proﬁt at the same time.