Comments on Brightwork Articles on Safety Stock - Brightwork Research & Analysis

Table of Contents: Select a Link to be Taken to That Section

Executive Summary

This article contains comments from articles on safety stock.

Introduction

These comments are in response to the articles on safety stock.

Comment #1: Bill Gherwilm

“Shaun, for me there are a few issues I have with this function. Safety stock is a pretty simple calculation s = Z * Std Dev of Demand * SqRt of LT. It can be a little more complex to include LT variability, but all versions revolve around the above. My first real issue is with white paper explanation of the calculations. I don’t completely follow what the constant values in the functions are replicating. I assume it’s trying to replicate the Z (Inverse Norm in excel) but this is not explained or mentioned. I have a model build in Excel that replicates the white paper functions but I can’t get past those constants and can’t get a standard calc to line up. I may need to revisit this and try again. The second is that for us, lead-time variability is unknown, and not understood. At the same time, there is no easy way to review or understand what should be populated in the Prod Master for this % value, that I know of anyway. While we understand why the inputs are important, we are struggling getting the requisite information put together so that we can feed the calculation (either by using inputs from DP or the product master). Any insight or documentation you might know about is appreciated.”

Bill,

That is right. Lead time variability is half of the equation. Lead time variability is a problem for every company I have consulting with. There is a related topic which is how frequently should the variability be updated, as well as the lead times themselves. These issues are of course highly connected. If lead times are updated, then variability becomes less of an issue. What I have seen is that lead times are not updated frequently enough in most cases, so, therefore, more inventory must be carried. Loosely translated the company pays for its lack of information by having to have more coverage.

Your traffic department may have a record of delivery metrics that you may be able to leverage to build a database. Depending on what they have to offer the initiative could be somewhat time-consuming or prohibitive to do.

However, you bring up a good point in that you are having a hard time determining what to populate the percentage value with. Actually, I agree with this as the documentation on exactly what the fields mean is lacking on the part of SAP. This is another reason that this functionality is so rarely employed. SAP is providing the fields, but not doing what it needs to do in order to make it practically implementable. The sad fact is that SAP often gets to the point where they can simply say they “have” functionality, and then go no further. This belies SAP’s sales over practical implementation orientation. Sales requests get top billing over implement ability when it comes to resource allocation.

I would love to point you to some documentation, or to something I have written. But as I mentioned in the article, no client I have worked at has ever implemented it, and no client has ever asked me to test it for them. The cursory analysis of SAP’s Help indicates to me that SAP has little interest in documenting it. This means that the results must simply be tested against an external calculator (which you sound like you are building in Excel). This would have to be done in any case. Although I believe there are online calculators that you can use instead of building it yourself.

As for replicating the logic in Excel, I think I did this back when I was doing more quantitative supply chain work in the mid 1990’s, but I can’t remember my experience exactly. I thought I was able to get it to work. However, since then I have relied upon its calculation in applications. So I can’t help you there.

Comment #2: From John Vanerp

“Bill,

I am working on a SNP project at the moment where we are also implementing Advanced SS planning. See below for the SS formula.

The difficulty as you mentioned is getting the lead time historical information to determine an average lead time and the lead time deviation. Also, lead time variation may not be a normal distribution, so the SS calculation using LT variation tends to be an approximation.

Hope this helps, John

The safety stock calculation is as follows when using both forecast and lead time error. k= service level

SS = k * SqRt [ (Std Dev of Demand^2 * Average LT) + (Std Dev of LeadTime^2 * Demand^2) ]
Demand variability during lead time = Std Dev Demand * SqRt [Average LT]
Average demand during variable part of LT = Std Dev LT * Demand

Total variability during lead time = SqRt [ (Std Dev of Demand^2 * Average LT) + (Std Dev of LeadTime^2 * Demand^2) ]”

I thought the other commenters should be interested to learn that I have recently run into another client that tested the Enhanced Safety Stock method and turned it off. Again, for the same reason, it outputs a safety stock level which is both too high and also not sufficiently controllable. They want to enable it again, by I have to ask why, as the functionality has not changed since they tested it several years ago. I would like to find the documentation on why it did not provide good results, but that will most likely be difficult.

It should also be understood that Enhanced Safety Stock is a lot of work to set up, requiring the auto-population of lead times and lead time variability among other elements.

I can think of no good reason to even test this functionality in SAP. Every client I have run into or spoken to has decided not to go forward with it. Companies want to control their safety stock and not put it on autopilot.

Before even testing in SAP, place the formula for 5 or 10 products into Excel. Estimate the input values from the experiences of planners, and see if you can live with the results. In the vast majority of cases, they won’t be able to.

I just see too many companies burning hours on this. However, my question I think has been fully answered. Companies do not bypass this functionality because they are not evaluating it. They bypass it because it’s too complex to maintain and is not even the way most want to manage their safety stock. These are great reasons to pass on functionality.

For those readers interested, I have another client (now 6 years after this article was first published) that tested the dynamic safety stock formula (without activating it in SAP first), and once again, it produced a safety stock that was too high.

Interestingly, as many times as these experiences pile up, it does not seem to reduce the interest in activating dynamic safety stock.

This article has been updated and is now significantly larger than when first published. I added explanations related to the forecast error used towards the bottom of the article.

Would You Like to Comment and Have it Added to This Thread?

Just provide your comment in the chatbox in the lower left of this screen.