The concept of multiplying money by time has occupied a lot of thought from Eli Goldratt for quite long time. The entities of money and time represent two different dimensions and thus the product of the two represents their combined impact.
In the financial area value-days are known for very long time, but with one substantial addition: the concept of “price of money” is accepted and widely used. The value of the product of money and time can be translated into money in the same way as other types of value. “The price of money” is an interest rate and it allows quantifying the financial worth of loans as well as investments. More on it – later in this post.
The use of dollar-days replaces certain, grossly biased, performance measurements that express
The damage of failing to achieve the delivery commitments
Thus, Throughput-Dollar-Days (TDD) is by definition a negative performance measurement. The best value you can get is zero. The prime use of TDD is measuring on time and in-full delivery of orders. When an order is late, relative to the promise to the client, then the T of the order multiplied by the late-days is far superior to simple due-date performance. Consideration of lateness creates motivation for efforts to minimize the lateness. Without it there is a real concern that once an order is late it loses its priority because the damage to the measurement has been done.
About twenty years ago the flight captains of El-Al, the Israeli airline, were measured by their on-time pull back from the terminal, and the bonuses were determined by it. As a traveler I could see the efforts to be on-time. But, when there was a delay it was alarming to see how people stopped to run and started walking, slowly, because they did not mind anymore.
However, TDD generates several negative branches. The T worth of an order is a key factor in the measurement. But, do you really like to give automatic higher priority to $1,000 order over $500 order? This measurement does not consider the damage to the reputation and does not consider the characteristic of the client and the level of business with that client. Buffer management, the formal TOC priority scheme in Operations, totally ignores the T of an order for setting the priority. So, is TDD an additional priority mechanism?
Another question is why to use the T of an order rather than the revenue? From the client perspective the worth of an order is the full price. We like to get the full payment, including the TVC, as soon as possible. The division of the revenue to TVC and T has nothing to do with the need to get the payments on time. Shouldn’t we use RDD (revenue*days-late) as a measurement?
My biggest issue with the concept of dollar-days is that it is not intuitive. DD generates very high numbers, which are quite confusing when compared with the net worth. An order of $1K delayed for 60 days, is 60K DD. How clear the true state of the situation is reflected by this one number?
Eli Goldratt wished TDD becomes a key measurement for the whole supply chain – keeping every link responsible for possible loss of sales. The practical problem is: how to measure the TDD of items that are sold from stock? When there is a shortage we suspect some lost sales – it is less clear how much. We can use statistics of sale-days, which are actually based on forecasts. Problem is, forecasts are quite confusing and many do not understand the ramifications.
My conclusion is that TDD has the potential of creating real value, but we should review the logic and be ready to introduce changes. Reservations and new ideas are welcome.
Inventory-Dollar-Days (IDD), supposedly the twin concept of TDD, is actually a different concept. The original idea was that while TDD expressed failing to deliver, IDD represents the effectiveness of the investment in inventory.
IDD is the accumulation of the cost of every item in inventory, the actual price paid for it, multiplied by the days passed since the purchasing. So, it represents the dollars invested combined by the time those dollars have been held without generating value.
So, in order to achieve very low TDD we need to invest in inventory. An analysis is required to set a standard for the “right” level of IDD that would achieve reasonable value of TDD.
Does really the IDD represent the effectiveness of the investment? IDD does not consider whether the items leaving the IDD calculations have generated money or just scrapped. While items spend time in inventory, or being processed but not sold, their real worth in money might have changed, but the IDD cannot relate to it – the real value would be revealed only when the item is sold.
What value we get from IDD?
We can use it to identify items that are both expensive and spent long time in inventory, contributing the most to the IDD, motivating operations to get rid of those items. It also motivates the purchasing people to be more careful when they order large amount of such materials. If this motivation is important, can’t we identify those items by crossing together the expensive items and their aging? Is the use of one number, which is not intuitive, a better way?
IDD is for inventory and it cannot be used for other investments. Suppose we have bought a new machine. The intention is to use it for many years. Dollar-days would accumulate from the day of purchasing the machine. Without considering the T generated by that machine the IDD of infra-structure is useless.
Here comes the concept of ‘Flush’ as a measurement of such an investment. The dollar days start with the initial investment. From that date negative dollar-days (DD) accumulate. Additional expenses increase the negative DD. When T is generated positive DD are added. Hopefully, at a certain time the state of the investment-DD would reach zero: the DD of the investment is fully recovered. Flush is the number of days to the breakeven of the DD of the original investment.
Flush is superior to the simplistic measurement of the time to return the cost of the investment.
But, is Flush superior to Net-Present-Value (NPV), where the DD are converted into money?
Flush ignores whatever happens after the DD become breakeven. More income might be generated, which have no impact on Flush. I also think we cannot simply ignore the concept of the “price of money”, which is a simpler, yet effective, way to evaluate an investment.
The real difficulty in evaluating an investment is the risk associated by it. Both Flush and NPV do not provide a good answer to that.
Another point that puts Flush in a funny perspective: When one spends money for pleasure then its DD would grow to infinity. Does this seem intuitive to you?
Do you like to discuss this further?
Eli Schragenheim 
Another great post, Eli. Thank you.
CUSTOMER SERVICE LEVELS
You are correct. TDD provides insights using comparative values to indicate whether a firm is serving its customers (relatively) better today than yesterday, or last week, or last month. But the TDD data provide no value in guiding improvement.
I believe that companies ought to require near real-time data capture of the reason codes for delayed customer shipments. The list of reason codes should be restricted to a predefined set of values, and should be capture, perhaps, at more than one point over the delay period. (For example, 1] upon entry into “Delayed Shipment” status; 2] after X hours or days delay; and 3] upon actual shipment.)
These reason codes, T-dollars, and days-delayed should then be Pareto analyzed so that the biggest causes of TDD can be rationally attacked by a cross-functional team so as to become a part of a POOGI.
INVENTORY MANAGEMENT
The gross dollar-value of inventory and its number of days on-hand really provide very little information for any kind of POOGI. Again, the numbers can be captured and show trends in performance, but they can’t tell you why things are getting better or worse. Nor do they provide much guidance as to actions to take to achieve improvement.
The value of inventory is NOT found in having it, or even the number of days one has it. For example, IDD value may be very low (read: good) for company that is achieving very low customer service levels, as well.
The true value of inventory is found in having the RIGHT QUANTITY of the RIGHT GOODS at the RIGHT TIME.
Debra Smith and Chad Smith, in their excellent book DEMAND DRIVEN PERFORMANCE USING SMART METRICS proposed some outstanding metrics predicated on strategic buffers:
For unacceptable service levels:
1) Days in the RED ZONE over the last 180* days
2) Days out of stock over the last 180* days
3) Days out of stock with demand (SOWD) over the last 180* days
For unacceptable flow performance:
1) Days in the GREEN ZONE > 15* days over the last 180* days
2) Days over top of GREEN (OTOG) 15* days over the last 180* days
* Note: These values may change by industry, position in the supply chain, or other circumstances
When these kinds of metrics are Pareto analyzed by a cross-functional supply chain team, rational actions may be derived to create a POOGI.
Let me know your thoughts on these matters. Thanks, again, for the great article.
LikeLike
Thank you Richard for your thoughts and I apologize for my late response. I should use some measure of responding quickly to comments, some kind of TDD.
TDD and IDD (to a lesser degree) work as a GENERAL MEASURE of performance!
When one looks for the critical contributors to them certain caution should be taken. An alternative way to locate problems in performance could be to manage two Pareto lists: One that looks on failing to supply especially high value items and the other on orders/items that were “too-late”. Is maintaining two Pareto charts is much more complex than maintaining one?
Note Richard that the metrics proposed by Debra and Chad look at days – not on the combination of value-days.
LikeLike
I respond because I like to argue with Eli, not really because I disagree, and to show a more complete picture. Let me take the Devil’s advocate position here.
Eli make a good point about TDD in that it could well be that an order with $500 worth of T that s one day late is “more important” to the company than a 1,000 T order which is 5 days late. It just depends. Is the customer also low on stock at his end? Is this the 3rd time and your company has now struck out permanently? We can’t even guess these things from TDD.
But let’s take a practical situation where a wholesaler is managing 40,000 SKUs in total. Most wholesale trades are old, commoditized and highly competitive. Therefore, they suffer with relatively lower margins. As good as Dynamic Buffer Management (DBM) is, this wholesaler will always have some items that are out of stock, maybe 100 to 200. Because he can’t afford to add extra stock on every item, this is a fact of life. It is also unlikely that they afford the manpower to respond to every shortage situation. Anyway, DBM will be raising the buffers of the items in shortage, constantly improving. So, which ones should the replenishment clerk address?
I’d say first they address the TDD that someone is hollering about. After that, they address the ones with the biggest TDD, until they run out of time to allocate to that effort.
A second useful aspect of TDD, which Richard commented on briefly in his response above, is a chart of its change over time. Rising TDD is a problem, if it is rising outside the previous range.
What are the causes? Conversely, dropping TDD is good and again, you should check the causes.
With respect to TDD vs. RevenueDD, I find that it usually makes no difference which one you use. The product of time and dollars gives a large number denominated in “badness” only. Nobody intuitively knows what the number itself means. In my wholesaler example above the T% will be in a narrow range. RDD would only produce a proportionally bigger aggregate figure which when charted over time would look just the same, except for the numerical denomination of the Y axis.
More rarely, there are companies where T% varies a lot. In such cases, I far prefer TDD to RDD, because, showing greater damage to the seller may provoke a more urgent response.
Seems useful to me!
LikeLike
Hi Henry, I certainly enjoy our discussions. I also fully agree with that watching the graph of the total TDD gives value. Actually my conclusion in my post regarding TDD was:
TDD has the potential of creating real value, but we should review the logic and be ready to introduce changes.
The challenge of using TDD is to understand well the boundaries of its use.
I like to make a point about the wholesaler managing 40,000 SKUs. I think it is wrong to let DBM manage all 40,000 SKUs. I think the more sensible strategy is to define what SKUs to manage for excellent availability (using DBM to review the buffers) and what SKUs to announce that sometimes they are available and sometimes not! However, choosing what not to commit to perfect availability has to include considerations that are not part of TDD. The quality of the supplier and the ROI of maintaining high enough target level that is effective in protecting availability are, to my mind, the main important factors. I’d also add the assessment of how the customer would react to the missing item? Is there a natural alternative? Is it the specific item so important to the customer as to push him to look for another wholesaler (and purchase everything he needs there)?
LikeLike
Hi Eli,
Let me try to contribute in some way with my understanding of TDD and IDD, and see if what I consider to be a proposed direction is acceptable.
As initially defined TDD is a negative indicator and as such it would be very difficult to deploy, implement and manage without major resistances.
On the other hand, IDD is an indicator aimed at bringing management attention to the inventory investment in order to cause higher turn-over of such investment.
Why do we need some indicator to manage Throughput? TDD was conceived to realize that late orders cause some impact in the company´s ability to generate more throughput on time, and the way to do so is by quantifying the impact of such lateness by multiplying the value of T by the time of lateness.
TDD is therefore an important indicator but not easily implemented. If what one tries to accomplish is immediate revenues from sales, then there are two basic issues to take into consideration:
1. Lateness in delivering the order
2. Lateness in collecting revenues
The first one deals with the company´s capacity to honor due date commitments and the second one with customer´s capacity to honor the terms of payment or company´s ability to assure collecting payments.
Many issues are to be included for each of the two. For example, if sales require down payments for processing an order, how does one account for the down payments made?
Basically TDD and IDD are indicators which are interconnected to each other. As IDD is reduced due to sales, TDD is somehow affected but not necessarily in a positive way.
If a company sells goods from inventory granting credit terms to the buyer, should IDD not take into account that such inventory is still an investment until full payment is received?
When one goes back to the conceptual definitions, Throughput is the VELOCITY by which INVENTORY is turned into REVENUES, so TDD measures the impact of reducing velocity by delaying true revenues, but it does not measures Throughput generated on time which is by all means what a company aims for.
So, there is a need to integrate these concepts to develop a good indicator. On the one hand we need to account for T generated on time and also T delayed, combining the two into one indicator.
Let´s say for example that all T generated on time would produce an indicator of 100, so all revenues received “on time” are accumulated with a value of Tt multiplied by 100. Each T delayed (TD) is multiplied by the time delayed and accumulated to a value of all TDD delayed. The sum of all sales, on time and delayed, make up the total value of T that a company generates, but of that value we subtract the value of T and the result is divided by T from sales, giving us an indicator of the impact of the delays in T from revenues. Now we can calculate the true VELOCITY of T for that company.
CASE N° 1
Sales T T Delayed Relative Relative
(days) Velocity TDD Impact
1 $100,00 $5,00 1 0 $- 0,0%
2 $650,00 $28,00 2 -1 $-28,00 -23,3%
3 $900,00 $56,00 1 0 $- 0,0%
4 $185,00 $13,00 4 -3 $-39,00 -32,5%
5 $750,00 $18,00 2 -1 $-18,00 -15,0%
Total $2.585,00 $120,00 $-85,00
VELOCITY 29,17%
CASE N° 2
Sales T T Delayed Relative Relative
(days) Velocity TDD Impact
1 $100,00 $5,00 1 0 $- 0,0%
2 $650,00 $28,00 2 -1 $-28,00 -23,3%
3 $900,00 $56,00 1 0 $- 0,0%
4 $185,00 $13,00 2 -1 $-13,00 -10,8%
5 $750,00 $18,00 1 0 $- 0,0%
Total $2.585,00 $120,00 $-41,00
VELOCITY 65,83%
CASE N° 3
Sales T T Delayed Relative Relative
(days) Velocity TDD Impact
1 $100,00 $5,00 1 0 $- 0,0%
2 $650,00 $28,00 1 0 $- 0,0%
3 $900,00 $56,00 2 -1 $-56,00 -46,7%
4 $185,00 $13,00 1 0 $- 0,0%
5 $750,00 $18,00 1 0 $- 0,0%
Total $2.585,00 $120,00 $-56,00
VELOCITY 53,33%
The above cases illustrate that T delivered and collected “on-time” would have a T Delayed (days) of 1, but it could be Zero and the formulas reworked, and T delivered and/or collected with delays would show the value for days delayed.
A company should aim at a VELOCITY of 100%, thus the more “on-time” generation of revenues should provide an indicator of how well Due Date Performance and Revenue Collections are implemented.
Company strategy should set terms of sales based on market conditions and profitability for collecting revenues “on-time” and then measure VELOCITY accordingly.
Other adjustments can be made but the idea is to have a way of determining true VELOCITY in the generation of T. Only then would TDD have some significance for improving velocity.
IDD should become a management focusing indicator only as it pertains to targeted inventory turnover ratios, using revenues generation to reduce inventory investment from sales. As long as a sale is not collected, the value owed should be considered part of the inventory investment.
The above are just some ideas as to what I believe should be worked on for further improvement. This is the direction I suggest for dealing with this issue in order to include the concept of VELOCITY in the generation of T.
LikeLike
Michael, I have to admit that I do not understand your calculations of the Velocity. I assume some explanations are missing. I understand your point of considering not just the late orders, but also those that were shipped as planned. But, what is that velocity you speak about when you do not consider the official (promised) lead-time from getting the order until it is shipped? How would the velocity measurement impact decision making relative to the impact of the TDD? Tell me on average I’m not so bad?
There is a big difference between TDD and IDD that I should have included in my post, but it is missing.
TDD is an accumulative measurement. So, I can measure the TDD generated in a month. There are some small issues on how to balance between months, but this is not a big problem. So, within the month the TDD contains only orders that should have been shipped before the month and then accumulate more T multiplied by late-days.
IDD is a snap-shot. It can jump up and down within one day, relative to TDD, within that month, that goes up or stay straight. Looking on the average IDD loses it’s impact. The measurement of inventory turns, which could be used for dollar-turns in inventory, is much simpler to use.
Generally speaking, TDD is a valuable general indicator of delivery performance. When it goes significantly up – we should worry. When I like to look on the contributor to TDD I’d look on TWO lists:
1. Orders that were late more than others.
2. The big orders, by T or Revenue, that were late.
I think I can make conclusions only if I separate the two parameters in the TDD.
I fail to see the value of IDD. I do see a lot of value in looking into the inventory items and see which items are held for long time. I like to check whether those items in inventory have still potential to be sold, and this could lead to certain actions, from writing-off those items off to using them as planned.
I also need to monitor the money that is held in inventory. I just don’t see the big value in merging the two different perspectives together.
LikeLike
Hi Eli,
I would like to send you a spreadsheet with my proposed approach for TDD as this venue does not allow attachments nor it did format the tables included in my previous post. Please let me know where to send the spreadsheet.
I will also think about IDD and will let you know when I have some input to consider.
LikeLike
My email addresses are:
elyakim@netvision.net.il
elischragenheim@gmail.com
I’ll be glad to understand your calculations.
Eli
LikeLike
On IDD.
Inventory-Dollar-Days (IDD)
What is the purpose? Clearly, IDD is to help manage the investment in Inventory.
The way IDD is calculated at any given time is multiplying for each item in inventory the cost of such item and then by the number of days held in inventory.
So, when the quantity of an item is reduced by sales the remaining quantities are used to generate IDD, which doesn´t say anything about having held more quantities for extensive periods until some are eventually sold, nor for not having enough to meet market demand.
IDD therefore assumes that once inventory is reduced, hopefully by sales, the past inventory investment held for a time period has been erased. A negative branch derived from IDD is that management may pursue having the lowest possible inventory investment and jeopardizing potential sales.
Therefore, implementing IDD should be only done when a full and clear understanding of its usefulness has been achieved, otherwise reactions to its significance may trigger unnecessary and wrong decisions.
The best value one can obtain from IDD is when it’s combined with another tool from TOC: Inventory Buffer Management.
Inventory Buffer Management sets a Buffer for each item held in inventory, which is adjusted as sales and replenishment behavior triggers adjusting the buffer level. Thus, IDD usefulness would be as a complementary indicator for Inventory Buffer Management.
Understanding that Inventory Buffer Management aims at maintaining the right investment in inventory to meet market demand, having a successfully implemented Inventory Buffer Management should make IDD unnecessary. But, and there is always a “but..”, IDD could be transformed into a most valuable indicator for keeping Inventory Buffer Management functioning correctly.
Let´s illustrate. When an item´s buffer becomes too big for whatever reason, one adjusts down the size of the buffer but the existing inventory level is still in existence. This is where IDD can become a useful indicator.
Also, when an item´s buffer becomes too little one adjusts upward the size of the buffer in order to avoid not being able to meet market demand. In this case IDD would show a lower value but it cannot reflect something good because having too little inventory is detrimental for potential revenue generation from sales.
Therefore, IDD should be calculated as two distinctive indicators: 1) IeDD; and 2) IgDD, where Ie represents the excess in inventory quantities for items above a certain level in the upper zone of the buffer and Ig represents the gap in quantities for items which have penetrated the lower zone of the buffer. Once a Buffer level is set for an item, management would only need to include a level in the upper zone of the Buffer for which IeDD woud be calculated to keep an eye in not overstocking any item.
If Inventory Buffer Management functions correctly, investment in inventory should be about “right” to protect market demand and IDD by itself would not indicate if such investment is too low or if it is too high. Also, without Inventory Buffer Management IDD would be essentially meaningless.
The direction for implementing a useful IDD indicator should be to call management attention for both cases: 1) overstocked items; and 2) understocked items, at any given time. So, now one would have two indicators to evaluate: IeDD reflecting overstock of items that should be managed to reduce existences by sales, promotions and any other marketing possibilities; and IgDD reflecting danger of potential loss of sales for not having enough inventories to cover any potential demand on time, and both based on Inventory Buffer Management.
This is my thinking for contributing to the issues brought forward by Eli on TDD and IDD.
Regards.
LikeLike
Regarding Michael’s suggestions above for IeDD and IgDD, when we created our Elucidate software to manage inventory Buffers, we included SDD (Surplus $ days) and RDD (Risk $ Days). I think our SDD is equivalent to Michael’s IeDD and our RDD is the same as his IgDD.
I have to say, we haven’t found them very useful in managing inventory. Let me explain why.
SDD measures the product of the $ value of the on-hand inventory above the top of its Buffer and the days the surplus is present. As Michael points out, this happens naturally. When a Buffer declines and there is still demand for the product, it cures itself. So, its use is only to call attention to the situation where there is no demand for the product. Occasionally, one can revive a dead product through substitution, aggressive discounting or returns to the supplier but usually dead products are a problem without a clear effective action. This means that SDD, mainly tells a business operator that he is in trouble due to a past error and there is no way out.
RDD measures the amount of inventory missing from the Red Zone times the number of days it has been gone. This condition naturally happens when demand is higher than usual or resupply is slower. DBM automatically reacts by increasing the Buffer when the Red Zone is penetrated “too much,” so no action is required here. If the Red Zone is fully consumed TDD reports that situation. That only leave a potential benefit for the items that are in their Red Zones persistently without running out. When we looked at these lists, we found that 99 times out of 100 no action is needed. Consequently, only people with both excess time and hysteria pay any attention to it, raising their stress without increasing performance.
LikeLike
I agree with Henry. We need not to stretch implementing IDD when Inventory Buffer Management is in place and working. Overstock can be easily detected and dealt with, and penetration into the red zone of the buffer is already manage with Inventory Buffer Management.
LikeLike
I concur with the others regarding DBM (dynamic buffer management) and IDD. When DBM is functioning, there are much better metrics for identifying problems, or impending problems. Metrics such as the following make a lot of sense with DBM:
1. Days OTOG (over top of green) > 15 days of the last 180 days
2. Days OTOG 15 days of the last 180 days
4. Days in CRITICAL RED (lower half of RED ZONE) of the last 180 days
5. Days stocked-out of the last 180 days
6. Days stocked-out with demand (SOWD) of the last 180 days
Note: The 180-day limit is suggested and may vary by business and industry.
LikeLike
Somehow during the posting of the comment, number 3 got deleted. It should read:
3. Days in GREEN ZONE > 15 days of the last 180 days.
Sorry.
LikeLike
The simple measurements used by Richard are an example that it is possible to implement inventory management practices without using IDD, which I think is confusing due to the multiplication of very different entities: money and time.
There are cases where overstock is intentional and necessary – for instance preparing inventory for a huge peak of sales. Depending on the amount of excess capacity on the weakest link Production might need to prepare the stock ahead of time. Increasing the buffer earlier than the start of the peak is a serious mistake because the demand, before the peak, is not inline with the buffer and buffer-management for the short term is getting wrong messages.
LikeLike
Thanks, Eli.
Overstock that is “intentional,” is not, by definition, “overstock.” Rather, it is planned stock. Therefore, what one is really doing is increasing the size of the buffer.
You are correct in saying that such planned adjustments in buffer sizes need to be done in advance of expected increases and decreases in demand. How much in advance will depend upon the capacities of the resources supply the buffer. Some may be able to handle the full adjustment in a single replenishment cycle; others may require several replenishment cycles to build up the necessary buffer quantities.
Since these buffer size adjustments are planned, they do not put the stock into a “too much GREEN,” or OTOG position. Rather, the buffer condition can still be monitored using the same metrics. After all, if–after adjustment to the buffer–you find that you are still in one of the metric zones (in my earlier response), then attention need to be taken to discover why. Correct?
LikeLike
Richard, when the “right” buffer is 100, but a peak in three months would require a buffer of 300, and you need to start producing now – increasing the buffer might cause “too much green”, because the demand is not, yet, increased. It is possible to increase the buffer slowly, but I think it might cause too many mistakes. I prefer to keep the buffer intact until the right time to increase it – and create an intentional overstock, radiating to everybody involved that this is a special intentional move in view of the coming peak. People should be aware of logic even when the computerized system does not fully “understand” the objective.
An alternative way is to create a special SKU for the stocked goods produced for the peak. This is a way to bypass the temporary misalignment between the buffer and the current demand. I prefer the simple approach.
LikeLike
Eli,
Increasing stock without increasing the size of the buffer would, indeed, lead to “too much GREEN.” However, adjusting the buffer size (as a percent of the original buffer size) as stock increases keeps the system from reporting “too much GREEN,” and send appropriate signals if demand or supply change outside of expected limits.
Using the percent increase or percent decrease method for seasonal or other expected demand variation keeps the original buffer quantity (say, 100) intact while allowing the actual buffer size to be adjusted for the expected demand variation (say, +20 percent, leading to an actual buffer quantity of 120). When the trend is expected to reverse (at the end of peak season, for example), the percent adjustments are appropriately reversed (-20 percent) to get the buffer back to its normal (non-seasonal) value.
LikeLike
Interesting. I do the opposite of Eli. Let’s say the season is back-to-school and I expect a 300% increase in demand, just like Eli’s example. I don’t know exactly when the demand will come, as different schools start at different times. And, the plant or the manufacturer I buy from does not have enough capacity and stock to promptly supply me everything I order.
In Elucidate, I triple the Buffer and freeze DBM action until I am sure the back-to-school season has started. That way, I get the bigger Buffer a safe time before the season and don’t have to worry that DBM will fight me by dropping the Buffer (due to too much time in the Green zone) before the season has a chance to fully kick in.
I don’t want to radiate that I chose to raise the inventory over the Buffer, because my replenishment manager may learn to ignore surpluses or may not notice a smaller surplus until it is too late to return to the vendor.
In the case above, the peak back-to-school season is followed by stronger than average demand. I will probably simple allow DBM to adjust the peak season Buffers down automatically. I do not prefer Richard’s approach, because I am unsure that the “normal” demand after the peak will be the same as before the peak. e.g. In my school supplies example, the after-the-peak demand will be more than the summer doldrums.
Instead of a lengthy season, had the extra inventory been for a demand surge period less than the replenishment time, I end up raising the Buffer 1 RT + some safety before the event and manually reduce the Buffer to normal 1 RT before the expected end of the event. This does result in what appears to the replenishment manager as surplus over the Green zone during the actual event period and maybe for a while afterwards if they were generous with their purchases.
LikeLike
Yes Henry, this would work. The difference between us is whether you shut-off DBM or tolerate that the software would show surplus inventory and explain to your people that this is intentional and the reasons. When you shut-off DBM you also radiate to your people that it is an intentional managerial move. I think that clever and responsible people might ask questions how come DBM does not reduce the level.
I fully agree on the need to reduce the buffers more than RT before the end of the peak. It appeared on a previous post of mine (Facing Seasonality).
LikeLike
Richard, I think you are mistaken. DBM does not (should not) reduce the buffer when there is surplus of inventory above the green. DBM starts checking when the on-hand enters the Green Zone. Increasing the buffer when the demand is low and the supply strong would generate “too much green” signals. Thus, Henry has chosen to shut DBM off when the stock increases before the peak starts.
LikeLike
I’m sorry, Eli. I don’t believe that I said that DBM reduces the buffer when there is a surplus of inventory (OTOG). I spoke of buffer size adjustments based on expected increases or decreases in demand (such as seasonal or promotional changes).
I apologize for any misunderstanding.
LikeLike
Richard, sorry for my misunderstanding. But, when you increase the buffer prior to the expected increase in sales, the chance of DBM telling you to decrease it is high. However, you are still before the true increase in sales and you need the stock to be in place. This was the issue: having to prepare the increase of stock BEFORE the start of the peak. You speak about 20% increase, I’m concerned with a need to multiply the buffer by a factor of 3. I can do it slowly, but even then the demand is not increasing for quite some time until the peak and if I don’t shut-off DBM it’d reduce the buffer.
This discussion has deviated from the topic of TDD and IDD and it comes back to managing the seasonality. I suggest that if you like to discuss that point further, let’s do it through my direct email: elischragenheim@gmail.com.
LikeLike