Skip to Content

This post is part of a series about DDMRP in SAP. If you haven’t already, you are invited to read first the initial introduction and a brief explanation of why DDMRP is needed, and then the posts about the first three DDMRP components: inventory positioning, buffers, and buffer adjustments. This post is about the forth component, demand driven planning.

Demand Driven Planning

This is a big topic, so I will have to cut even more corners than usual and assume you already have some background knowledge. If you have not already, I highly encourage you to read the DDMRP book by Ptak and Smith (where the chapter devoted to Demand Driven Planning is, not surprisingly, the lengthiest one, and has several examples that will certainly make the concepts more clear).

The Demand Driven Planning component is where supply orders are actually generated. On one hand, and assuming everything else has already been aligned according to what was discussed in the previous posts, this should not be too difficult since in essence we are talking about a reorder point type planning (ok, with a few, but critical, tweaks). On the other hand, these tweaks will affect the MRP engine, the core of any ERP, so things can get tricky.

The basic idea is that you calculate a so-called “net flow position”, which is physical stock plus quantity on order minus qualified sales order demand. Sales order demand is “qualified” if it is past due, due today, or if it is a spike (and a day is considered a spike if it is a configurable number of times above ADU). If, then, the net flow position for a given part is below the top of yellow, a supply order is generated up to top of green.

Implementation in SAP

We should be able to take advantage of a lot of things from SAP’s MRP engine, but we’ll have to make some adjustments. Compared to the standard SAP reorder point planning (VB) we have to consider that:

  1. the reorder point itself (top of yellow) is frequently adjusted (ideally daily), mainly because of the constant adjustment of ADU;
  2. the replenishment quantity is also dynamic (we’ll replenish up to the top of green);
  3. the stock position includes elements usually not considered in a typical reorder point planning (qualified sales order demand).

Let’s deal (briefly, as always) with each of these in turn.

The reorder point must be, then, equal to top of yellow. One option would be to update the material master daily before MRP runs, but this would mean a big number of master data updates which we’ll usually want to avoid. The best option would probably be to calculate this dynamically during MRP execution (but remember ADU was already calculated beforehand) using badi MD_MRP_PARAMETERS.

We’ll want to replenish up to top of green, so lot size HB is probably the closest one to what we need. Again, the maximum stock can be updating by changing the material master or, probably better, using MD_MRP_PARAMETERS.

It should be possible to consider the correct demands in the net flow equation by configuring the mrp type (to include external requirements) and then make some adjustments / filtering of the relevant demands in badi MD_CHANGE_MRP_DATA. For dependent demands (ie, requirements from planned orders) a minor modification will be required, since the good guys at SAP decided this is not something you would want to include in reorder point planning.

We usually finish by discussing the official software compliance criteria, which in this case is:

Here a “planner workbench” is mentioned, which we have not discussed so far. This will be a list in a way similar to MD07 but adapted for DDMRP, where the planner will be able to see the situation for each material and the supply order proposals. While the development itself is not difficult, it is critical to have a good design for this transaction, as the usability of the whole solution will depend on this. Instead of using the standard MRP engine, you could of course use this workbench to create supply order suggestions. I would recommend, though, to use the MRP engine as much as possible, so that other standard functionalities are not lost (for example, lot sizing).

There is much more to Demand Driven Planning, and here, as usual, I have just covered the basics.

In the next post, I’ll cover a bit of the last DDMRP component, which deals with execution.

To report this post you need to login first.

1 Comment

You must be Logged on to comment or reply to a post.

  1. Joaquin Perez

    Hi Rui Pedro,

    Thanks for the series. It is refreshing to have a clear explanation of a topic when all you read recently is marketing disguised as analysis.

    There are surely advantages in having the values calculated dynamically (like buffers and their placement). The plan improvement can feel “revolutionary” when compared with the results if someone is infrequently adjusting values in the system.

    However, to me the real problem with production planning (variability exists and there is no reliable way to predict it) cannot be overcome with a different way to calculate the numbers. All approaches are limited by this fact and try to improve it in similar ways.That is why when DDMRP says strategic buffers I hear safety stock and when it says Demand Adjust Factors I hear forecasting.

    In any case, I find commendable that you have draft a potential SAP implementation of DDMRP with a simplified approach supported on ECC available functionality.

    As you certainly know, Camelot provides a DDMRP SAP certified solution for SCM and for IBP and is “co-innovating” with SAP a Demand-Driven Rhythm Wheel Planning (DDRWP) solution. It looks to me that they all will be part of the future standard S4/HANA functionality.

    But it looks like they are leaving behind customers, that would like to implement DDMRP, but are still planning with ECC. That is the niche (not that small) that you are addressing.

    Let me suggest using flexible planning to enter the DAF values by periods. You can create a customized structure to both enter values as to show some calculated values as a projection of time. The values will not make sense at an aggregated level but you can save yourself all the work of coding a similar planning book transaction.

    I like a good challenge and I’m dedicated to design and implement homemade solutions in APO and PP, so you can contact me directly if you want to discuss any of these ideas.

    Regards

    Joaquin

     

    (0) 

Leave a Reply