L = λW
In that post, I stated that a goal in a process is to make the inputs flow as fast as possible through a system in order to produce an output. As an example, I shared an example from Amazon.com. Specifically, I stated that in a click-to-ship system, we want product to move with velocity. Is that always possible in a system and can that be a realistic goal?
In reality, customer orders arrive sporadically, stochastically, and unpredictably. Imagine a supply chain consisting of a network of ~30 U.S. and Overseas distribution centers (I’m talking about Amazon.com here). These distribution centers are multi-echelon, which means that products are stored in both “Prime” locations and in “Reserve” locations. In these types of systems, the products in “Reserve” locations replenish the “Prime” stock, and Amazon’s outside suppliers replenish products in the “Reserve” locations. In that supply chain, often times, orders create spikes in demand that disrupts manufacturing schedules, cause overtime, decimates raw material supplies or current inventory levels, and wipes out finished goods buffers.
Demand also creates service problems for customers who wouldn’t be able to get the products they wanted because a spike in demand had consumed finished goods stocks or Reserve inventory. The challenge is to extend the smooth flow of materials and information upstream, beyond the plant-level, but all the way through the supply chain including to the distribution centers in the U.S. and Overseas and outside suppliers. The solution is to smooth out the peaks and valleys in the demand coming from the distribution centers by leveling the type and quantity of production and filling orders from carefully controlled finished goods markets or on-hand inventory.
Leveling, or Demand Production Leveling, is technically known as Heijunka. This word comes from the Toyota Production System and is a Lean Manufacturing term. The goal of heijunka is to create balance by leveling demand the flow of production in a system. Graphically, you can imagine Heijunka to look like the following:
Amazon.com has a pull system in place — a very, very good one, though it’s not completely pull. Creating pull is a prerequisite to having flow and demand production leveling (more on pull in another post). In other words, information systems must allow for Amazon’s suppliers to know the inventory levels of the Amazon.com Reserve stock. So, information flow and product flow are key in these situations: when the MIN level of Reserve Inventory is reached, the information system should pull from the supplier the right amount of inventory to bring the Reserve levels back to planned levels.
Back to heijunka. At Amazon.com, there is a buffer in place that stages all orders. This means that when an order is made, orders sit in a queue — a virtual queue before that order is dropped or assigned to an fulfillment center. This buffer or waiting queue acts as a load leveler; else, orders would be coming into a fulfillment center at the rate of demand, which is characterized by peaks and valleys. But, the goal is to level demand production, since we can’t entirely control demand. In other words, velocity is still key, but we must have balance in the system first in order to pull an order through with velocity.
Another example of Heijunka is from Medtronic, a medical device manufacturer. They dealt with the same problems I mention above — unforseen demand and on-the-whim reactions to that demand which created imbalance in their system. Their approach was to create a Value-stream map, which shows process, time, and waste dimensions in a system. Below is their current state map of their distribution process:
Mapping revealed that the daily operation required 16 people and that an order took 367 minutes to progress from initial download to actual shipping. During the 367 minutes of lead time, the order was actually being worked on for just 28.3 minutes. Much of the rest of the time, it was waiting for the next processing step to occur, as represented by the inventory triangles between steps. The logistics team calculated the lead time represented by the inventory triangles. The triangle between pick and the next step, check. It showed that the logistics team found 144 lists or orders waiting to be checked. In the data box for check, the team recorded its observation that the cycle time for an operator to check an order was one minute. Since there were two people checking orders, it would take them 72 minutes to process the 144 lists or orders in the queue.
What is amazing about what this team discovered is that only 7% of the time, the product was undergoing a value-adding stem. The rest of the time, was waste. Is there a way to make this process leaner, with less waste?
The next action for the logistics team was to map out and implement a leaner future-state by using the information uncovered during the current-state mapping process. For example, scanning at both the check and pack steps was a duplication of work, an obvious waste that the team wanted to eliminate. The problem was how to make sure the orders weren’t mixed up in the totes. Many of Medtronic’s products were small and had to be put in totes to prevent them from falling through the conveyor. The team then realized that the conveyor was causing the need for double scanning. If orders were picked, placed on a cart instead of a conveyor, and wheeled to a scanning terminal, then the pick, check, and pack steps could be combined into one “assembly” station. The team made the improvement. The only significant cost was a $3,000 fee to the scanning program vendor for reprogramming.
This new process is much leaner, quicker, supports pull, creates balance, and is much faster than the previous process. Many steps were eliminated and waste was reduced. The outcome? From click-to-ship, the process moves with velocity, and the customer receives his or her product much quicker. Notice the Heijunka box above — this creates the balance and reduces unthoughtful reactions to unpredictable demand.
In this post, I used a lot of technical terms that I will write about seperately in the future. I used,
- Value-Stream Mapping
I’ll be extending these posts to include Lean, Six Sigma, and Theory of Constraints concepts with real examples from my time at Amazon, Kaiser Permanente, and my stint as a Deshi at Toyota.