Skip to Content
Author's profile photo Former Member

Replenishment Strategies in SAP ERP

Replenishment strategies can be setup by way of the MRP type on the material master’s MRP1 screen. In combination with lot sizing, various safety stocks, lead times and other indicators, the replenishment strategy is defined. It is important to understand that the replenishment strategy is not just “PD” or “V1”. It is the combination in which the four MRP screens are set up, that determines what strategy is actually executed by the system.

To make up an example; if the MRP type “PD” is combined with a safety stock, then we are communicating to the system that we want to execute the replenishment for that part as a combination of consumption based planning, whilst primarily waiting or planning for demand. We cover demand spikes with the safety stock, but the actual replenishment happens strictly after the demand comes in.

In the following we will discuss possible replenishment strategies; how they work, how they may be set up and configured and what kind of results should be expected. Special focus is given to the analytics that can be used to determine what strategy most likely works best for any given situation. What works well for a specific item today, might not work so well tomorrow. An item with very predictable consumption might suddenly receive spikes in demand and is not fit for the current replenishment strategy anymore. This is why it is so important to understand all strategies and their implications, so that the right strategy can be applied when the circumstances call for it. If the material planner knows one, two or three strategies and does not know how to switch from one to another, your supply chain will function sub-optimally. I have seen places where the MRP controller did not even have authorization to work in change mode on the four MRP screens in the material master. IT was setting lot sizes, lead times, strategies, MRP types and the like as per request. Many times the list of usable MRP types is limited to PD, and VB.

Yes, it looks like you are coaching a football team and the offense has exactly two plays they can choose from: run the ball left or through the middle. Your quarterback never learned how to throw the ball.

Let’s introduce and put together a playbook with which you and your team rip up the defense and move the ball (product) in the most effective way across the playing field (your network).

A Playbook for Replenishment Strategies

Plan on Demand (PD), the most widely used replenishment strategy in the SAP universe, also requires the most manual labor. In no way would I ever say “don’t use PD”, but give me a break; you use it for 98 percent of your raw and packaging materials? Well, maybe you don’t and then I’m particularly proud of you. since you are definitely the exception.

PD is deterministic and therefore, in its purest form, waits for demand before it springs into action. If there is demand and the MRP run gets executed, a supply proposal is generated to cover that demand. No magic, no automation, nothing. It’s as simple as that. Before your kid doesn’t ask for a bathroom you don’t look for one, right? And as long as she gives you enough lead time you don’t have a problem (ever took your three kids on a stroll through midtown Manhattan, though?)

No demand, no supply! Which works really well when the purchased part is expensive and therefore costly to store, its consumption is highly variable and unpredictable and the lead time to procure is short. But when your production lines starve because a component is missing, your customers are told that you can’t deliver the Porsche because you plan the standard cigarette lighter on demand or your bakery starts making pretzels after you walk in to buy one (or your butchers starts raising pigs after you order a pork sausage)… then we are in real trouble!

Your PDs should be worth the constant attention they need. It is ok to carefully watch and monitor how much of Johnny Walker’s Blue Label you hold behind the bar, but to tell a patron that you ran out of salt because you were waiting to buy a sack until they asked for it, is flat out ridiculous (take a quick check to see if any one of your highest consumable, standard parts is set to PD)

There are ways to make a PD work for situations described above. You can set a safety stock, create a parts forecast or work with lot sizing procedures. That way you cover up the disadvantages of a PD, with stochastic (consumption driven) methods which help you somewhat to automate. However if the part calls for such methods, why not employing a standard consumption based planning method altogether? That is why they are there and they work beautifully if combined with the right lot sizing, safety stock or availability checking rule.

Reorder level planning is a consumption based method because it requires a minimum inventory to be available at all times and does not wait until there is demand before replenishment is triggered. Imagine the way your metabolism works. Its inventory is energy and when that energy level drops you get hungry and a desire to fill it back up is triggered. You get some food and eat. Now, you don’t wait until you’re completely depleted of all energy; there is an acceptable level – or range – from where you trigger replenishment. When you trigger energy replenishment, you usually have some lead time to deal with until you get that food, eat it and metabolize it so it becomes energy. You instinctively know that you have to have enough energy left at the trigger point so that you don’t run out completely within the replenishment lead time. This is no different with the raw materials you need to keep your lines going.

This kind of replenishment, like all other ones too, only works well in certain situations. Since you can predict really well what your rate of loss of energy is over time, you intuitively know how to set your trigger point. If your energy loss rate would be completely unpredictable, the trigger point would have to be set very high, because you really don’t want to risk losing your life when you have a very sudden drop in energy.

Also, if you are very far away from food – let’s say on a marathon run where you can’t stop and sit down for lunch – you may eat some extra carbohydrates beforehand so that your energy level is very high and gets you through a long lead time. And last, but certainly not least, you want to think about your service level. What is the percentage of time that would be acceptable for you to wither away? (Now this metaphor does not work that well anymore).

These three variables determine where you set your reorder level. The more predictable the consumption, the lower the reorder level needs to be. The longer the lead time, the higher the reorder level needs to be. And the higher your expectation to never run out (e.g. a 99% service level), the higher the reorder level for safety. In the latter case the reorder level moves up exponentially. This kind of thinking will also help us to determine at what situation reorder level planning does not make sense anymore. Obviously, if you have unpredictable consumption in combination with a long lead time and high expectations to never run out, you should look for another strategy. Your reorder level, and therefore your inventory holding, is too high.

Oh… and don’t forget about the other dimensions: value and size. Salt, something that is cheap and does not take up much room, is assumed to be in inventory at all times (I wouldn’t go back to a restaurant that could not get me a salt shaker on the table, after I asked for it). Even if the use is unpredictable, or it takes a long time to get it, or I never want to run out. It still makes sense to bring it back in after it breaks through an even very high reorder level, since it is cheap to hold and easy to store.

Of course you could also plan salt on demand, but the point is, that if you do that you would have to watch your salt at all times and with the reorder level procedure you get automation; you don’t have to watch it; it’s out of the way and plans itself.

SAP ERP provides you with four standard reorder level procedures to choose from (technically there is a fifth one for time-phased planning which we will cover later):

  • – VB, the most basic of them all, where you set your reorder level manually and MRP just simply creates a supply proposal when inventory breaks through that level
  • – V1, which also uses external requirements, like a sales order, within the replenishment lead time only, to calculate when the reorder level is broken
  • – VM, where the reorder level (and the safety stock) is calculated automatically by the material forecast
  • – And V2 which is a combination of V1, using external requirement s and VM, which calculates reorder level and safety stock using the material forecast

Be careful with the automated reorder level procedures. They use consumption patterns, lead time and service level to calculate reorder levels and if one of the parameters is off, your inventories might go through the roof. I always suggest to set the procedure to ‘manual’ and simulate a calculation procedure without saving it. If you do it that way, you can perform “what-ifs” and monitor what’s happening without risk.

Before we get to other consumption based replenishment strategies, I would like to explore another method, which is very often confused with a reorder level procedure and is not controlled by the MRP type on the MRP1 screen. However, it is a consumption based replenishment strategy nonetheless: Kanban!

In its original, simple sense, Kanban uses two bins with a certain quantity of parts in each, and when one is empty, replenishment is executed while the other bin – or its content – is used up. You just have to design the quantity available in each bin, so as to have enough in one bin to not run out while the other is filled back up.

So when do you use that kind of thing? Instead of a reorder level procedure? Because it’s the same thing? I don’t think so. Going back to our energy example, it becomes clear that there are situations where you cannot simply trade a reorder level procedure for Kanban.  I don’t have a second bin of energy that I can switch to, while I fill the empty one up. On an airplane you usually have more than one tank and on my 1957 Money M20A, I was able to switch over to the right wing tank before the left wing tank emptied out, but that is simply not always possible (hmm… was my fuel supply really Kanban controlled?). When you fill Rum into bottles from a tank over the bottling line, you don’t want to switch back and forth between two tanks but rather start the replenishment process for the blending at some point when that one available tank gets to a level where the replenishment lead time fills it back up to where it needs to be, before you run out.

Kanban is great for parts needed on an assembly line. You put two bins of screws on there and the worker takes what she needs. When the bin is empty, she takes screws from the second bin and sends the empty one to the warehouse for replenishment.

Material forecast: I have not yet seen an SAP installation where the MRP type VV is used to its full potential. Here are my five cents:

First off: a VV can also be used for finished goods. It’s just that SAP never thought about configuring that option into the initial version, so they didn’t customize the standard software delivery that way. You will have to maintain some entries for VV in customizing transaction ???? before you can sell a VV product in a sales order. There are many situations that would call to set a finished product to VV. As an example, you can create a forecast in the material rather then in S&OP and then copy the VV forecast as a VSF into demand planning. This has the advantage that you have perfect, individual control over the product’s forecast and the added advantage that sales orders consume that forecast.

So what does the VV do? It is a consumption-based replenishment strategy, in that it maintains inventory in anticipation of actual demand. The inventory is replenished to a forecast which is based on the materials own consumption history. Hence ‘material forecast’. This is a good strategy when you have predictable demand but the lead time to replenish is long. Since you put ‘artificial’ demand out there by way of a forecast, MRP is able to generate all supply elements way ahead of time and all you have to do is to turn the requisition into an order at the date the system tells you to do so. But beware;  it does not take demand spikes into consideration. Any changes in demand will flow into the consumption pattern and eventually be picked up by the forecast module. The system might increase or decrease the forecast or tell you that the current underlying model does not hold water anymore. So, like all the other strategies, you can only use a VV when it fits the bill. Don’t blame SAP when you use VV for a finished product and you complain that it does not pick up immediately on a demand spike. It simply won’t.

It’s like a squirrel planning for his family for the winter. Rocky has a forecast in his head and brings walnuts in to provide for the upcoming winter season. Should he become unusually hungry, he just eats up what he has and does not bring in more to cover that spike. There are no more nuts! So it is with your long lead time items that are predictable. If it takes 6 months to bring in peach skin micro fiber from China, you don’t want additional sales orders introduce nervousness into your procurement schedule… because it just won’t do any good anyway.

You can cover variability in demand; but in case of the VV you do this with safety stock. Either static, forecast adjusted, or dynamic with a range of coverage profile. Once the safety stock is depleted you run out and the service level degrades.

A VV provides a high degree of automation, but it needs to be monitored and SAP provides various options to do so. One of the parameters you can look at to see how good the forecast was, is the error total (FS). It looks at each period where there was a forecast and subtracts the forecast values from what was actually consumed. As the consumption most likely differs from the forecast, the question is: how much different? If the underlying model (constant, trend, season or seasonal trend) is correct then the error should sometimes exceed and sometimes fall short of what was forecasted and over the long run average out and approximate zero.

Another parameter calculated by the forecasting app is mean absolute deviation (MAD). This is a measure of variability and forecast quality. The MAD is calculated by adding up all absolute values of Error and dividing it by the sum of the actual consumption values. Thi provides you with a measure on how much the actual consumption deviates from the forecast on average. The smaller the MAD, the better the forecast was; the smaller the average deviation, the better.

Now the system is able to calculate the tracking signal for you which is determined taking the error total divided by the MAD. If you think about it; when that coefficient is high, then you have am]n error total which is high above zero (therefore a bad model underlying your forecasting) and a low mean absolute deviation (meaning that consumption follows some pattern, just not the one you had selected). Or, in different terms, the error total should be close to zero and therefore if you get a high number out of the formula FS/MAD, you have such a high error total that you might have to change gears and select a different strategy altogether.

What is being compared to the tracking signal (TS = FS/MAD) in SAP is the tracking limit. It is maintained on the forecast screen and in standard is set to 4.0. If the tracking limit is exceeded by the tracking signal, you get an exception message in MP33 and you can even set the system so that a new model selection procedure is automatically initialized.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member

      Very useful article thanks

      Author's profile photo Former Member
      Former Member

      Nice Article - Thanks.

      Author's profile photo Former Member
      Former Member

      Excellent metapharic illustration! Thanks for this.

      Author's profile photo Daniel Strange
      Daniel Strange

      Fantastic post Uwe! Brilliant use of metaphors to describe some difficult business scenarios. Thanks for taking the time to write this.

      Author's profile photo Former Member
      Former Member

      thank you Uwe. your article was very interesting.

      now I have a question for you:

      my customer use propylene for its production stored in tanks. the problem is that they have 3 different type of propylene that could be in all of that tanks with the role that no more than one type or one batch can be stored at the same time in the same tank.

      How can I replenish them considering that they have to be replenished only when the tank is empty?

      I thought about MRP Area, Storage BIN or Kanban but my doubt is that the tank is not dedicated to a single propylene type.


      May you help me?


      thanks a lot.


      Maria Grazia

      Author's profile photo Former Member
      Former Member
      Blog Post Author

      Dear Maria Grazia


      the only method that I can think of on th spot is Kanban. I once developed this process for a rice company which stored rice in silos but there are too many unknowns for me to come up with a definite solution...


      all the best


      Author's profile photo Former Member
      Former Member

      Great summary of the complexities involved with MRP in SAP and how often settings can be overlooked, especially when it comes to the inter-relationships between the settings. Having a solution that ties together all the settings as well as all the uncertainties in demand, lead-time, and yield can make identifying the right strategy much easier. The key is to link them together with a metric to guide decisions, tools like SAP Simple Logistics (S/HANA Enterprise Management) combine the multiple screens but it can't tell you the impact of the different strategies. Fortunately, there are solutions to this.