How disruptive is FILLRATE100?
Inventory is required when supply time is longer than the need for a product or material.
The amount of inventory needed is equal to the maximum expected consumption before the next replenishment.
So the factors to determine the amount of required inventory are consumption, replenishment time (RT), and variability of both. It is something like: I = consumption x RT x SafetyFactor, where SafetyFactor is a factor to cover for the variability.
Note: Consumption or sale are equivalent for this analysis. All this analysis is valid per SKU - stock keeping unit.
Most organizations that manage inventories do some of these things:
They determine a minimum or safety stock. When inventory hits this stock, a replenishment order is placed.
The quantity to replenish is either an EOQ - Economic Order Quantity or is determined by a forecast.
The time between two consecutive orders depends on the variabilibility of consumption, so the time between two replenishments is also variable.
And replenishment time is also long because the minimum quantities to order cover for many days (or weeks or months) of consumption.
As already mentioned, Required Inventory to cover all future consumption (100% fill rate) results in a very high amount under these conditions.
As most of the inventory was determined with a forecast, which is not 100% accurate, the inventory ends up with excess inventory for some items and shortages for others.
As forecast is responsible for the mistakes contained in the inventory, the usual direction is to try to improve forecast.
There are many techniques to improve it, taking into account multiple variables, using sophiscated algorithms. Today, AI is being used to try improvements in this area.
However, by how much can we reduce inventories with a better forecast? Or reduce shortages?
The problem is extended and it is chronic because there is no challenge to the basic assumptions that lead to the current mode of operation of most suplly chains.
FILLRATE100 is based on avoiding forecast for the daily operation.
This decision forces us to:
Fixing the frequency to replenish each SKU. This action reduces also to zero the variability of replenishment time.
Increasing frequency as much as possible (or equivalently, reducing time between two consecutive orders to the minimum possible).
The expected results:
Shortages are solved much faster, if there are any.
Inventory as the result of much less time and much less variability, is greatly reduced.
Why is this idea so disruptive?
All the policies that drive bigger batches (production, purchasing, transportation, etc.) are based on minimizing the Logistical Costs. The disruption is to challenge the validity of those costs.
One typical policy is to send only full trucks, because the unit freight cost is less than sending half full trucks.
Now, consider what happens when we wait for the trucks to be full. Some items are late and we have shortages. To remedy that, we fill the trucks with more than needed, and those items end up as excess.
With our suggestion, we wouldn't send more trucks per day. Maybe some of them are not full, and by the unit cost calculations, we think we are increasing costs. However, we haven't increased the number of trucks, so the freight cost is exactly the same as before. It can be even lower, transporting less weight.
This is just one example to show how the basic assumptions to make decisions in logistics are flawed, and by challenging them, we can build a disruptive innovation.
Note: All these ideas were developed by late Dr. Eliyahu Goldratt, author of The Goal.
For each location, decide a fix frequency to replenish each SKU in that location. For most cases, when the origin location is another warehouse, replenishing everyday is reasonable. For a CD, where the origin (source) is a plant or an external supplier, the reasonable frequency is around one to two weeks.
For each SKU-Location, decide an initial buffer (buffer is a target inventory in units). Here we do some math, however it is not critical to do a perfect calculation, because the buffers will be monitored and adjusted to follow the consumption trends.
On the predetermined day, for each SKU generate an order to replenish only for what was consumed. Another way to calculate this is Order = Buffer - OnHand - Transit. Send the orders with the decided frequency.
Consumption not only has variations around an average. The average can grow or decrease.
We need a mechanism to adjust the buffer size to the new reality, so we don't have shortages when demand grows or excess inventory when demand decreases.
The buffer is divided in three zones. The lower part is red, the middle is yellow and the upper is green.
For each SKU at each location we have a buffer. And we also have the On Hand stock and the On Transit stock. We define Buffer Status = On Hand / Buffer. The colors that Buffer Status can take are:
Black: zero On Hand, a shortage.
Red: between 0 and 1/3.
Yellow: between 1/3 and 2/3.
Green: between 2/3 and 1.
Lightblue: More than 1, excess inventory.
The mechanism to adjust buffers is:
Get buffer status everyday for each SKU-Location.
When buffer was red more than a predetermined limit, we say it was TMR - Too Much Red.
When buffer was green more than a predetermined limit, we say it was TMG - Too Much Green.
TMR triggers an increase of 1/3 of the buffer. This tells the system to replenish the consumption plus the increase.
TMG triggers a decrease of 1/3 of the buffer. The new green is below On Hand, so no replenishments are ordered until inventory is consumed below the new buffer.
A full replenishment time must pass before we look for another adjustment, to avoid the over reaction of the system.
Forecast is not knowledge. However, when we have knowledge, we use it.
Examples of knowledge:
Seasonality and Promotions are events where we know demand will be much higher than usual. We can prepare our buffers to face that event in good shape. (A separate tutorial explains the suggested procedure in these cases).
Discontinued products. We don't need to wait for TMG to reduce buffer. We can directly set the buffer to zero.