Our clients utilize a wide variety of enterprise resource planning (ERP) computer software packages.  Most have the potential to maximize the productivity and profitability of an organization’s investment in stock inventory.  But occasionally we run into a road block.  A software designer will ignore common sense to ensure “statistical integrity”.  I recently experienced two of these episodes.

The first involved the calculation of safety stock.  Safety stock is insurance inventory maintained in case of unusual demand or delays in receiving a replenishment shipment.  Many systems will calculate the safety stock based on a multiple of the deviation (i.e., the difference) between the forecast and actual sales or usage over the past several months.  A client called and reported that his software was calculating a very high safety stock quantity for an item even though the forecast has consistently exceeded actual usage over the past 12 months.  As a result of the high forecasts and large safety stock quantity the product was incredibly overstocked.  I called the software support department and spoke to the designer of the system.  I explained that in calculating safety stock, he should only consider months where actual usage exceeded the forecast (i.e., there would not be enough stock to cover actual customer requests).  The designer, in a condescending tone, stated that I did not understand statistical standard deviation theory. According to that theory, all deviations between the forecast and actual usage must be considered in the calculation of safety stock; even those where the forecast was much higher than what was actually sold.  He went on to explain that my thoughts were not only “statistically invalid” but would lead to an “unstable statistical environment”.  When I asked how he could justify a lot of safety stock in my customer’s situation where the forecast was, on average, twice actual sales he replied that it was a “feature” of their software.  I guess a similar feature resulted in the incredibly high forecast.  Features like this can easily lead to bankruptcy.

Another client called with a different situation.  One of his stocked products has sporadic sales.  He sold one piece two months ago and another piece ten months ago.  His system is instructing him to maintain eight pieces of this very expensive item in stock.  I called the software company and they explained that in stocking an item with sporadic usage they consider the previous six sales of the item.  This may seem reasonable but the four previous sales were recorded over two and a half years ago.  I asked that the system be modified to only consider transactions that occurred during the previous 12 months.  I was told that “too small a sampling is not statistically valid” and that the previous six sales must be considered regardless of how long ago they occurred.  Decreasing popularity of products over time is not considered in their model.

Your computer system should produce reasonable forecasts and replenishment parameters.  Whether they are considered to be statistically valid by a mathematician is immaterial.  You need realistic, real-world, results.  That is why we suggest the following steps when helping a client implement or better maintain their replenishment system:

  1. In a test environment, have the system forecast and set replenishment parameters for all of your inventory items.
  2. Ask your buyers to review the results and choose several items they would like to review with the software support staff.  Be sure that they note how the parameters should be corrected.
  3. Discuss these items with the software support staff.  Determine if system parameters of features need to be changed to provide you with reasonable results.

The most valuable replenishment tool most companies have is the expertise of their buyers, planners and purchasing agents.  A system should help them do a better job, not frustrate them in order to maintain statistical validity.