What do you do when you are forecasting an intermittently demanded item, such as a spare part, with average demand of less than one unit per month?  Most of the time the demand is zero, but the part is significant in a business sense; it can’t be ignored and must be forecasted to be sure you have adequate stock.

Your choices tend to center around a few options:

Option 1:  Round up to 1 each month, so your annual forecast is 12.

Option 2:  Round down to 0 each month, so your annual forecast is 0.

Option 3:  Forecast “same as same month last year” method so the forecast matches last year’s actual.

There are obvious disadvantages to each option and not much advantage to any of them.  Option 1 often results in a significant over forecast.  Option 2 often results in a significant under-forecast.  Option 3 results in a forecast that is almost guaranteed to miss the actual significantly since the demand isn’t likely to spike in the exact same period. If you MUST forecast the item, then we would normally recommend option 3 since it is the most likely answer that the rest of the business would understand. 

But a better way is to not forecast it at all in the usual sense and instead use a “predictive reorder point“ keyed to your desired service level. To calculate a predictive reorder point, you can use Smart Software’s patented Markov bootstrap algorithm to simulate all possible demands that could occur over the lead time, then identify the reorder point that will yield your target service level.

You can then configure your ERP system to order more when on-hand inventory breaches the reorder point rather than when you are forecasted to hit zero (or whatever safety stock buffer is entered). 

This makes for more common-sense ordering without the unneeded assumptions that are required to forecast an intermittently demanded, low-volume part.

​If you had your head up lately, you may have noticed some additional madness off the basketball court: The failure of Silicon Valley Bank. Those of us in the supply chain world may have dismissed the bank failure as somebody else’s problem, but that sorry episode holds a big lesson for us, too: The importance of stress testing done right.

The Washington Post recently carried an opinion piece by Natasha Sarin called “Regulators missed Silicon Valley Bank’s problems for months. Here’s why.” Sarin outlined the flaws in the stress testing regime imposed on the bank by the Federal Reserve. One problem is that the stress tests are too static. The Fed’s stress factor for nominal GDP growth was a single scenario listing presumed values over the next 13 quarters (see Figure 1). Those 13 quarterly projections might be somebody’s consensus view of what a bad hair day would look like, but that’s not the only way things could play out.  As a society, we are being taught to appreciate a better way to display contingencies every time the National Weather Service shows us projected hurricane tracks (see Figure 2). Each scenario represented by a different colored line shows a possible storm path, with the concentrated lines representing the most likely.  By exposing the lower probability paths, risk planning is improved.

When stress testing the supply chain, we need realistic scenarios of possible future demands that might occur, even extreme demands.   Smart provides this in our software (with considerable improvements in our Gen2 methods).  The software generates a huge number of credible demand scenarios, enough to expose the full scope of risks (see Figure 3). Stress testing is all about generating massive numbers of planning scenarios, and Smart’s probabilistic methods are a radical departure from previous deterministic S&OP applications, being entirely scenario based.

The other flaw in the Fed’s stress tests was that they were designed months in advance but never updated for changing conditions.  Demand planners and inventory managers intuitively appreciate that key variables like item demand and supplier lead time are not only highly random even when things are stable but also subject to abrupt shifts that should require rapid rewriting of planning scenarios (see Figure 4, where the average demand jumps up dramatically between observations 19 and 20). Smart’s Gen2 products include new tech for detecting such “regime changes”  and automatically changing scenarios accordingly.

Banks are forced to undergo stress tests, however flawed they may be, to protect their depositors. Supply chain professionals now have a way to protect their supply chains by using modern software to stress test their demand plans and inventory management decisions.

Figure 1: Scenarios used the Fed to stress test banks.

Figure 2: Scenarios used by the National Weather Service to predict hurricane tracks

Figure 3: Demand scenarios of the type generated by Smart Demand Planner

Figure 4: Example of regime change in product demand after observation #19

What’s the difference, and why it matters for inventory planning.

Those new to the parts planning game are often confused by the many variations in the names of parts. This blog points out distinctions that do or do not have operational significance for someone managing a fleet of spare parts and how those differences impact inventory planning.

For instance, what is the difference between “spare” parts and “replacement” parts? In this case, the difference is their source. A spare part would be purchased from the equipment’s manufacturer, whereas a replacement part would be purchased from a different company. For someone managing a fleet of spares, the difference would be two different entries in their parts database: the source would be different, and the unit price would probably be different. It is possible that there would also be a difference in the useful life of the parts from the two sources. The “OEM” parts might be more durable than the cheaper “aftermarket” parts. (Now we have four different terms describing these parts.) These distinctions would be salient for optimizing an inventory of spares. Software that computes optimal reorder points and order quantities would arrive at different answers for parts with different unit costs and different rates of replacement.

Perhaps the largest distinction is between “consumable” and “repairable” or “rotable” parts. The key distinction between them is their cost. It is foolish to try to repair a stripped screw; just throw it out and use another one. But it is also foolish to throw out a $50,000 component if it can be repaired for $5,000. Optimizing the management of inventory for fleets of each type of part requires very different math. With consumables, the parts can be regarded as anonymous and interchangeable. With “rotatables”, each part must essentially be modeled individually. We treat each as cycling through states of “operational,” “under repair,” and “standby/spare.” Decisions about repairable parts are often handled by a capital budgeting process, and the salient analytical question is, “what should be the size of our spares pool?”

There are other distinctions that can be drawn among parts. Criticality is an important attribute. The consequences of part failure can range from “we can take our time to get a replacement” to “this is an emergency; get those machines back in action pronto”. When working out how to manage parts, we must always strike a balance between the benefits of having a larger stock of parts and the dollar costs. Criticality shifts the balance toward playing it safe with larger inventories. In turn, this dictates higher planning targets for part availability metrics such as service levels and fill rates, which will lead to larger reorder points and/or order quantities.

If you Google “types of spare parts”, you will discover other classifications and distinctions. From our perspective at Smart Software, the words matter less than the numbers associated with parts: unit costs, mean time before failure, mean time to repair and other technical inputs to our products that work out how to manage the parts for maximum benefit.

We often encounter Excel-based reorder point planning methods.  In this post, we’ve detailed an approach that a customer used prior to proceeding with Smart.  We describe how their spreadsheet worked, the statistical approaches it relied on, the steps planners went through each planning cycle, and their stated motivations for using (and really liking) this internally developed spreadsheet.

Their monthly process consisted of updating a new month of actuals into the “reorder point sheet.”  An embedded formula recomputed the Reorder Point (ROP) and order-up-to (Max) level.  It worked like this:

• ROP = LT Demand + Safety Stock
• LT Demand = average daily demand x lead time days (assumed constant to keep things simple)
• Safety Stock for long lead time parts = Standard deviation x 2.0
• Safety Stock for short lead time parts = Standard deviation x 1.2
• Max = ROP + supplier-dictated Minimum Order Quantity

Historical averages and standard deviations used 52-weeks of rolling history (i.e., the newest week replaced the oldest week each period).  The standard deviation of demand was computed using the “stdevp” function in Excel.

Every month, a new ROP was recomputed. Both the average demand and standard deviation were modified by the new week’s demand, which in turn updated the ROP.

The default ROP is always based on the above logic. However, planners would make changes under certain conditions:

1. Planners would increase the Min for inexpensive parts to reduce risk of taking an on-time delivery hit (OTD) on an inexpensive part.

2. The Excel sheet identified any part with a newly calculated ROP that was ± 20% different from the current ROP.

3. Planners reviewed parts that exceed the exception threshold, proposed changes, and got a manager to approve.

4. Planners reviewed items with OTD hits and increased the ROP based on their intuition. Planners continued to monitor those parts for several periods and lowered the ROP when they felt it is safe.

5. Once the ROP and Max quantity were determined, the file of revised results was sent to IT, who uploaded into their ERP.

6. The ERP system then managed daily replenishment and order management.

Objectively, this was perhaps an above-average approach to inventory management. For instance, some companies are unaware of the link between demand variability and safety stock requirements and rely on rule of methods or intuition exclusively.  However,  there are problems with their approach:

1. Manual data updates
The spreadsheets required manual updating. To recompute, multiple steps were required, each with their own dependency. First, a data dump needed to be run from the ERP system.  Second, a planner would need to open the spreadsheet and review it to make sure the data imported properly.  Third, they needed to review output to make sure it calculated as expected.  Fourth, manual steps were required to push the results back to the ERP system.

2. One Size Fits All Safety Stock
Or in this case, “one of two sizes fit all”. The choice of using 2x and 1.2x standard deviation for long and short lead time items respectively equates to service levels of 97.7% and 88.4%.    This is a big problem since it stands to reason that not every part in each group requires the same service level.  Some parts will have higher stock out pain than others and vice versa. Service levels should therefore be specified accordingly and be commensurate with the importance of the item.  We discovered that they were experiencing OTD hits on roughly 20% of their critical spare parts which necessitated manual overrides of the ROP.  The root cause was that on all short lead time items they they were planning for an 88.4% service level target. So, the best they could have gotten was to stock out 12% of the time even if “on plan.”   It would have been better to plan service level targets according to the importance of the part.

3. Safety stock is inaccurate.  The items being planned for this company are spare parts to support diagnostic equipment.  The demand on most of these parts is very intermittent and sporadic.  So, the choice of using an average to compute lead time demand wasn’t unreasonable if you accept the need for ignoring variability in lead times.  However, the reliance on a Normal distribution to determine the safety stock was a big mistake that resulted in inaccurate safety stocks.  The company stated that its service levels for long lead time items ran in the 90% range compared to their target of 97.7%, and that they made up the difference with expedites.  Achieved service levels for shorter lead time items were about 80%, despite being targeted for 88.4%.    They computed safety stock incorrectly because their demand isn’t “bell shaped” yet they picked safety stocks assuming they were.  This simplification results in missing service level targets, forcing the manual review of many items that then need to be manually “monitored for several periods” by a planner.  Wouldn’t it be better to make sure the reorder point met the exact service level you wanted from the start?  This would ensure you hit your service levels while minimizing unneeded manual intervention.

There is a fourth issue that didn’t make the list but is worth mentioning.  The spreadsheet was unable to track trend or seasonal patterns.  Historical averages ignore trend and seasonality, so the cumulative demand over lead time used in the ROP will be substantially less accurate for trending or seasonal parts. The planning team acknowledged this but didn’t feel it was a legitimate issue, reasoning that most of the demand was intermittent and didn’t have seasonality.  It is important for the model to pick up on trend and seasonality on intermittent data if it exists, but we didn’t find their data exhibited these patterns.  So, we agreed that this wasn’t an issue for them.  But as planning tempo increases to the point that demand is bucketed daily, even intermittent demand very often turns out to have day-of-week and sometimes week-of-month seasonality. If you don’t run at a higher frequency now, be aware that you may be forced to do so soon to keep up with more agile competition. At that point, spreadsheet-based processing will just not be able to keep up.

In conclusion, don’t use spreadsheets. They are not conducive to meaningful what-if analyses, they are too labor-intensive, and the underlying logic must be dumbed down to process quickly enough to be useful.  In short, go with purpose-built solutions. And make sure they run in the cloud.