Going Lean and Staying Agile
Lean warehousing refers to the application of 'lean' principles to warehousing and logistics operations. These principles are derived from lean manufacturing that calls for the identification and elimination of waste (waste is defined as any activity that does not add value). Lean warehousing is a process of continuous improvement involving a constant review of warehouse operations (from ASN creation through product shipment), removal of activities that do not add value, and the enhancement/addition of processes that create value. Since the best feedback comes from those who use them, every warehouse operator is encouraged and empowered to constantly think of better ways of working. Improvement techniques like the 5s framework (sort, set in order, shine, standardize and sustain) are applied.
If lean has much benefit, why is its adoption limited? The reasons are many; but one of them is the dissonance between continuous operational improvements and software development cycles.
Let me give you an example. Imagine that you are employed as a Receiver in the warehouse. Your job is to stack the incoming cases on a pallet for putaway. Your WMS has been configured to recommend 20 cases to be stacked per pallet. However, you begin to notice that your organization is asking its vendors to sometimes send the same item in smaller case dimensions, thereby allowing you to stack 30 cases per pallet and override the system suggestion. In other words, the number of cases that can be stacked on a pallet is a function of the case type and not a function of the item number. Unfortunately, your system has not been designed to recommend the quantity by case type.
Since the system was likely developed based on certain assumptions that have now evolved, you request your IT team to modify the WMS. IT places your requirement on a wish list. Since your organization follows the traditional waterfall model of software development, this list is evaluated every 3-6 months. Assuming that your request is rated important (a very big if), it will be designed, coded, tested and deployed alongside other requirements. If you are extremely lucky, your changes will hit the system within 6 months. In most cases, it takes a year.
And therein lies the disconnect. You want to empower your associates to constantly think of improvements, but the desired software changes come through only after a year. You want your warehouse operations to be lean, but your software operations are not.
I believe that the successful adoption of lean warehousing will only materialize when lean thinking also permeates systems design and development. The waterfall model has its utility in certain situations, but if you are talking continuous improvement and incremental change, the agile method is better suited. An organization needs to invest significant time and effort to the adoption of agile practices, and if it works with IT partners and third party integrators, their practices must be aligned as well.
I do want to highlight that the frequency of incremental change does not matter. I have come across one client who prefers changes every 2 months while another wants them every 2 weeks. A recent engagement revealed an agile software development process where there are no 50 page functional specifications or multiple approval cycles. Instead, rapid incrementalism is the mantra. Business & IT work closely with each other. Design through deployment (including documentation and user testing) conclude within 4 weeks. And these take place even with an offshoring element in the mix.
When you create an environment where employees think, suggest improvements and make changes, and their work is supported by flexible software tools that support these changes, you get a lot more than just lean warehouses. You get motivated employees and happier customers. Now wouldn't we all want more of that?