moving towards an exception minded business...

One of the first things I look at when optimizing the SAP supply chain at customers, is how the material planners evaluate the exception messages, which are generated when not everything goes by the plan. SAP ERP has an impressive setup providing for a number of features allowing for exception monitoring and taking actions to balance demand with supply. However, these features are rarely used to its fullest potential. Following some thoughts and recommendations:

I see many people using MD07 and almost everybody uses MD04, but not many people use MD06 or MD05. Sometimes I hear people say "why should I use MD06 when the information is already outdated?". It is usually known that MD06 / MD05 is a snapshot in time; a stock / requirements list as it was created at the time of the last planning run. It is the so-called MRP list, because it has the time stamp of the last MRP run.

When you use MD07, you will get a list with all materials belonging to an MRP controller (or a product group) and their associated, dynamically created stock / requirements lists. This is a good thing if you are cleaning up outdated elements, but not if you want to get in the mode of an exception minded business and you want to tend to those things getting off plan only. MD06 is the transaction to use for that!

This is because in MD06 you have the ability to limit the list to a certain date (other than in MD07 you are asked to provide a ‘from’ and a ‘to’ date in the initial screen). Since the planning run creates the MRP list as the last step of the planning sequence, the MRP list has a time stamp and is, or was, valid only at that specific time and date.

By entering yesterday’s date, you will only get MRP lists which were created yesterday. Therefore you get a list of all materials which were planned yesterday – and none others! That is a great thing, since no one wants to work off a list which is comprised of materials which one needs to look at and materials one does not need to look at (why looking at materials which were not planned and therefore have not received an MRP relevant change since the last time I looked at it?)

Call up MD06 first thing in the morning with yesterday’s date if MRP runs before midnight (…and with today’s date if MRP runs after midnight). And do it every day! After it’s done for a while, the list becomes manageable and allows for a quick and focused exception management.

What do the exception messages mean? Exception messages are generated by the MRP run and categorized into 8 groups. I think SAP has done a great job of how they categorized and grouped these various messages in the standard delivery. I have seen many installations were people (consultants and customers – users and IT personnel) reconfigured the assignment of exception messages to groups. I have not seen any such cases where anything was achieved by such re-grouping. Let me have a shot at my own interpretation of these groups of exception messages and what I think was intended by this grouping:

Group 1 contains exception messages where the opening date lies in the past. Usually, this is a newly created order proposal since the system tries to alert you to this fact every time the planning run is executed, but if you set the run to not create new proposals every time the opening horizon is missed, you will simply get exception 05 on an existing proposal. If you missed the opening date, you missed the date when you had to converted a planned order into a purchase requisition. And this is assuming that you have maintained an opening horizon in the schedule margin key and you create planned orders first before you want a purchase requisition.

Group 2 contains exception messages where you missed the release date to convert a purchase requisition into a purchase order. Like in group 1 messages, this is usually and newly created order proposal. There is also message 63 which tells you that the system has suggested a production start that lies before the order start in lead time scheduling. This happens when you don’t have the system to adjust the basic dates (customizing in OPU5).

Group 3 messages are more serious problems. Now we did not only miss the start but are already past the finish date. We are still on the proposal side of things, so the planning run keeps on trying to adjust the proposals and usually creates new ones. Here we can also see exception 64, which tells us that the production finish is after the order finish – also because we don’t adjust the basic dates maintained in OPU5.

Group 4 are general messages like when a new order proposal was generated and there is no problem with scheduling (01). Or an order proposals quantity has been changed (42) or an order proposal was re-exploded (44). If an order proposal has been changed manually since the last run, you will also get an exception (46). These messages don’t pose a problem and are of the informative kind. It is important to know that you can only view exceptions out of group 4 in MD06 – not in MD07! This is, because the system can’t tell when the last planning run was, since the dynamically created stock / requirements situation (in MD07) has no time stamp.

Group 5 exceptions point to messages resulting from errors in the BoM explosion. For example, if the planning run couldn’t find a suitable BoM, there was missing config to support the explosion, or if there was no valid run schedule in repetitive manufacturing (54)

In Group 6 we deal with exceptions resulting from an availability check or stock shortages and stock excesses. If we dip into safety stock (96), push the inventory above the maximum defined in the coverage profile (25 for MTS, 26 for MTO) or exceed a quota (70), we are alerted and have the opportunity to take action to remedy.

Group 7 contains all rescheduling messages (expedite in 10, push out 15 and cancel 20) and the ‘proposal’ message 30 which tells us that the demand is inside the lead time and cannot be fulfilled without expediting.

Like with group 4, messages out of Group 8 cannot be seen in MD07 but only in MD06. In case the planning run was terminated for a material, message 98 in group 8 is shown.

So what’s the sense in grouping these exceptions? It is simply to prioritize the workload for the exception handler when they call up MD06 in the morning. My suggestion for the sequence is based on experience out of many installations, but it is slightly different from customer to customer. Find your own and adjust it as you go and see fit.

I deem group 8 the most important. You do not want to have any materials in your portfolio where the planning run aborts. Clean those out first. Next you might want to look at group 5. These are structural problems and the planning run can’t even come up with a date or quantity since the demand does not get exploded down to the lower level. Then group 3; not only did we miss a date to firm a receipt, we are so far behind that we missed the date when the receipt was supposed to come in to fulfill a demand. Before that, you will have to deal with the group 2 problems where you missed the date when a proposal needed to be firmed so that we can receive the quantity after the regular lead time. If you miss that date, rescheduling and manual expediting is your only option.

Group 1 exceptions are only relevant when you use an opening horizon and want to have an additional check where your external procurement is triggered first by a planned order and then by a purchase requisition.  Therefore group 7 messages ought to be tackled next. These require expediting and may take a much longer time frame but in the least, I would create a list at this point, which I can execute throughout the day (call vendors, check with purchasing, look at the warehouse for inventories etc.).

Next is group 6. Inventory excess or shortages usually require a change in strategy… and that cannot be done on the fly in the morning during an exception handling session. Again, make a list and see if you can reduce these exceptions over time, applying a different MRP type, changing the lot size procedure, looking at safety stock etc. etc. Last but not least you have a look at the general messages in group 4. Why is there a new proposal? Why has one been changed? These messages are information only and don’t necessarily require action.

As you reduce your exceptions (you will never be able to rid yourself of all of them), you will find all kinds of problems in the process, the master data setup, the system setup or with human behavior. You will get yourself into a more analytical mode of operandi and proactively solve issues rather than work transactionally and constantly try to put out fires.

It is a very worthwhile exercise to learn about all exception messages and why they are being created. Don’t waste your time trying to make sense of them by regrouping and re-interpreting what SAP has already figured out for you!