Demand-Driven MRP – Part VI: Planning

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.