​BACKGROUND

Most of Smart Software’s blogs, webinars and white papers describe the use of our software in “normal operations.” This one is about “irregular operations.”  Smart Software is in the process of adapting our products to help you cope with your own irregular ops. This is a preview.

I first heard the term “irregular operations” when serving a sabbatical tour at the U.S. Federal Aviation Administration in Washington, DC. The FAA abbreviates the term to “IROPS” and uses it to describe situations in which weather, mechanical problems or other issues disrupt the normal flow of aircraft.

Smart Inventory Optimization® (“SIO”) currently works to provide what are known as “steady state” policies for managing inventory items. That means, for instance, that SIO automatically calculates values for reorder points (ROP’s) and order quantities (OQ’s) that are meant to last for the foreseeable future. It computes these values based on simulations of daily operations that extend years into the future. If and when the unforeseeable happens, our regime change detection method reacts by removing obsolete data and allowing recalculation of the ROP’s and OQ’s.

We often note the increasing speed of business, which shortens the duration of the “foreseeable future.” Some of our customers are now adopting shorter planning horizons, such as moving from quarterly to monthly plans. One side effect of this change is that IROPS have become more consequential. If a plan is based on three simulated years of daily demand, one odd event, like a large surprise order, doesn’t matter much in the grand scheme of things. But if the planning horizon is very short, one big surprise demand can have a major effect on key performance indicators (KPI’s) computed over a shorter interval – there is no time for “averaging out”. The planner may be forced to place an emergency replenishment order to deal with the disruption. When should the order be placed to do the most good? How big should it be?

SCENARIO: NORMAL OPS

To make this concrete, consider the following scenario. Tom’s Spares, Inc. provides critical service parts to its customers, including SKU723, a replacement circuit board sold under the trade name WIDGET. Demand for WIDGET is intermittent, with less than one unit demanded per day. Tom’s Spares orders WIDGETs from Acme Products, who take either 7 or 10 days to fulfill replenishment orders.

Tom’s Spares operates with a short inventory planning horizon of 28 days. The company operates in a competitive environment with impatient customers who only grudgingly accept backorders. Tom’s policy is to set ROP’s and OQ’s to keep inventory lean while maintaining a fill rate of at least 90%. Management monitors KPI’s on a monthly basis. In the case of WIDGETS, these KPI targets are currently met using an ROP=3 and an OQ=4, resulting in an average on hand of about 4 units and average fill rate of 96%.  Tom’s Spares has a pretty good thing going for WIDGETS.

Figure 1 shows two months of WIDGET information. The top left panel shows daily unit demand. The top right shows daily units on hand. The bottom left panel shows the timing and size of replenishment orders back to Acme Products. The bottom right shows units backordered due to stockouts. In this simulation, daily demand was either 0 or 1, with one demand of 2 units. On hand units began the month at 7 and never dropped below 1, though in the next month there was a stockout resulting in a single unit on backorder. Over the two months, there were 4 replenishment orders of 4 units each sent to Acme, all of which arrived during the two-month simulation period.

GOOD TROUBLE DISRUPTS NORMAL OPS

Now we add some “good trouble” to the scenario: An unusually large order arises part way through the planning period. It’s “good” because more demand implies more revenue. But it’s “trouble” because the normal ops inventory control parameters (ROP=3, OQ=4) were not chosen to cope with this situation. The spike in demand might be so big, and so disadvantageously timed, as to overwhelm the inventory system, creating stockouts and their attendant backorders. The KPI report to management for such a month would not be pretty.

Figure 2 shows a scenario in which a demand spike of 10 units hits in the third day of the planning period. In this case, the spike puts the inventory under water for the rest of the month and creates a cascade of backorders extending into the next month. Averaging over 1,000 simulations, month 1 KPI’s show an average on hand of 0.6 units and a miserable 44% fill rate.

FIGHTING BACK WITH IRREGULAR OPERATIONS

Tom’s Spares can respond to an irregular situation with an irregular move by creating an emergency replenishment order. To do it right, they have to think about (a) when to place the order (b) how big the order should be and (c) whether to expedite the order.

The timing question seems obvious: react as soon as the order hits. However, if the customer were to provide early warning, Tom’s Spares could order early and be in better position to limit the disruption from the spike. However, if communication between Tom’s and the customer making the big order is spotty, then the customer might give Tom’s a heads-up later or not at all.

The size of the special order seems obvious too: pre-order the required number of units. But that works best if Tom’s Spares knows when the demand spike will hit. If not, it might be a good idea to order extra to limit the duration of any backorders. In general, the less early warning provided, the larger the order Tom’s should make. This relationship could be explored with simulation, of course.

The arrival of the replenishment order could be left to the usual operation of Acme Products. In the simulations above, Acme was equally likely to respond in 7 or 14 days. For a 28-day planning horizon, taking a risk on getting a 14-day response might be asking for trouble, so it may be especially worthwhile for Tom’s to pay Acme for expedited shipping. Maybe overnight, but possibly something cheaper but still relatively fast.

We explored a few more scenarios using simulation. Table 1 shows the results. Scenarios 1-4 assume a surprise additional demand of 10 units arrives on Day 3, triggering an immediate order for  additional replenishment. The size and lead time of the replenishment order varies.

Scenario 0 shows that doing nothing in response to the surprise demand leads to an abysmal 41% fill rate for that month; not shown is that this result sets of the next month for continued poor performance. Regular operations won’t do well. The planner must do something to respond to the anomalous demand.

Doing something in response involves making a one-time emergency replenishment order. The planner must choose the size and timing of that order. Scenarios 1 and 3 depict “half sized” replenishments. Scenarios 1 and 2 depict overnight replenishments, while scenarios 3 and 4 depict guaranteed one week response.

The results make clear that immediate response is more important than the size of the replenishment order for restoring the Fill Rate. Overnight replenishment produces fill rates in the 70% range, while one-week replenishment lead time drops the fill rate into the mid-50% to mid-60% range.

TAKEAWAYS

Inventory management software is expanding from its traditional focus on normal ops to an additional focus on irregular ops (IROPS). This evolution has been made possible by the development of new statistical methods for generating demand scenarios at a daily level.

We considered one IROPS situation: surprise arrival of an anomalously large demand. Daily simulations provided guidance about the timing and size of an emergency replenishment order. Results from such an analysis provide inventory planners with critical backup by estimating the results of alternative interventions that their experience suggests to them.

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.