The intent of this article is to point out the importance of MRP lists and the ramifications of phasing them out in S/4HANA MRP Live.

Introduction

One of the many innovations that S/4HANA brings is MRP Live. There are tons of blogs, technical articles and SAP official documentation on that and it is not the purpose of this article to repeat them.

Enough to say is that the paramount feature of MRP Live is a shift of number crunching from an application server to SAP HANA database in an attempt to harvest the power in-memory  processing.

It is nicely illustrated by the following diagrams:

Source: Classic MRP and MRP Live Technical changes (source: blogs.sap.com)

Along with SAP HANA introduction, MRP Live brings several simplifications and differences in comparison to classic MRP. Refer to the following notes for details:

• 2638465 – MRP differences between S/4HANA and ERP systems
• 2640393 – Differences between t-code MD01N and classic MRP t-codes MD01/MD02/MD03

Who moved my MRP Lists?!

One of the prominent changes in MRP Live is lack of MRP lists – as simply as that:
MRP Live does not create MRP list.

• SAP Help on MRP Live: Incompatible Changes shows the following table:

• Whereas note 2268085 – S4TWL – MRP Live on SAP HANA – MD01N explains:

MRP Lists

MRP lists were intended for checking the MRP result. MRP lists were used to find materials with issues quickly. MRP lists are snapshots of the material supply and demand situation at the time of the last MRP run. The snapshot is often outdated. With HANA, stock/requirements lists can be read with high speed. The MRP apps determine materials with issues in real-time. In SAP S/4HANA there is no need for outdated MRP lists.

In my opinion both the decision to sunset MRP lists in MRP Live and the rationale presented above are fundamentally wrong. 

The confusion around stock/requirements lists (transactions MD05 and MD06) and MRP lists (transactions MD04 and MD07) stems from the fact that they look virtually the same and they talk the same language, the language of MRP exceptions.

However they tell two completely different stories:

1. Stock/requirements list shows the current planning situation and MRP exceptions resulting from the current misalignment of supply in relation to demand.
2. Whereas MRP list shows the result of MRP planning and MRP exceptions resulting from MRP planning run.

It is of utmost importance not to mix those two and not to try to use one in place of another.
MRP results simply can not be evaluated with stock/requirements lists.

The value of MRP lists

Caetano Almeida provided a great explanation of the purpose of MRP lists in his blog article: Why should I use transaction MD05 to analyze the MRP results? I do encourage to read it carefully.

Let me just add three points here, that I deem of the utmost importance.

Manage MRP run errors (group 5 and 8)

The most basic job of MRP is to balance supply and demand. However in order to do so MRP has to run without errors for all the materials in the planning scope. Therefore the first task of MRP controller (that is after the morning coffee of course) is to check for any erroneous MRP runs.

It’s easy with MRP lists as all materials where MRP run has failed are marked with an MRP exception of the group 5 or 8. The MRP exception itself details the error which typically is caused by an attempt to plan a material flagged for deletion or a problem with BOM explosion issue.

All these material can be quickly and efficiently zeroed in on with the search function (binoculars icon) of MRP list collective display i.e. MD06 transaction.

MRP exceptions of the group 5 and 8 are not available in stock/requirements list collective display i.e. MD07 transaction. Therefore MRP Live lacks a tool to conveniently deal with MRP run errors.

Continuous master data tuning (group 4)

The truizm or the fact of today’s life is an ever going change. To reflect changes in business environment MRP needs to be adjusted accordingly, mainly through fine tuning of master data e.g. lead times, minimal order quantities, insourcing vs outsourcing etc.

Hence the second task of MRP controller (that is after the morning coffee and dealing with MRP errors) is to check if MRP still yields valid results, if procurement proposals generated by MRP run still conform to business rules. To do that the MRP controller needs to evaluate those proposals, which again are conveniently marked with MRP exceptions of group 4 and easy to find with MRP lists.

MRP exceptions of the group 4 are not available in stock/requirements list collective display i.e. MD07 transaction. Therefore MRP Live lacks a tool to conveniently fine tune MRP related master data.

Workload stability (mainly group 7)

Imagine the following scenario:

1. You are in a simple trading, buy-and-sell business.
2. You are a seasoned MRP controller, handling 1.5k material numbers (it’s a substantial number, however not exorbitant for an experienced SAP user, who has the right tools and knows how to used them).
3. You are managing your materials just right, keeping a nice balance between demand and supply. You focus on inventory reduction and your MRP exceptions are under control.
4. Now out of the blue you experience demand surge – maybe your customers have gotten out of COVID-19 paralysis or one of your items has gone viral and everybody wants it or your competitor has gone out of business.
5. As a result you see a tidal wave of sales orders way exceeding demand plan and what your vendors have already committed to. As a result MRP starts screaming at you (mainly through MRP group 7 exceptions) to expedite supply.
6. You do what you can – you call the vendors, you ask them and plea to them, you negotiate with them. But there is only so much what you and them can do. The demand surge is not going to be covered and MRP exceptions are not going to vanish. You just need to acknowledge them and focus on any upcoming issues.
7. You have done what you could, have acknowledged all the exceptions.
8. From now on you would like to focus on new issues only.

With MRP classic the situation is relatively easy to handle and MRP lists are the right tool for the job:

• Next net MRP run will create only MRP lists for materials which demand/supply situation changed, i.e. the materials that require MRP controller attention.
• MRP list collective display (MD06 transaction) features processing indicator i.e. materials that have been already analyzed by MRP controller can be ticked off and then filtered out.

Those functions are not possible with stock/requirements list as MD07 always display current MRP situation and current demand/supply situation and current MRP exceptions (all of them).

In other words MRP controller using MD07 will always see all MRP exceptions even if nothing can be done about them. Here MRP lists cancel the noise out of MRP exceptions and provide much needed stability to MRP controller work load.

MRP Live lacks a tool to focus MRP controller attention on materials that really need their attention and a tool to shield MRP controller from irrelevant MRP exceptions that have already been dealt with.

Conclusion

I really appreciate technical improvements of MRP Live harvesting the power of HANA database. Also the much needed simplifications make MRP implementation and usage easier and more comfortable. However to jettison MRP list on a way is too much of a simplification as it undercuts MRP Live usability tremendously.

In fact without tools to:

• to manage MRP planning errors
• to fine tune master data
• to stabilize MRP controller tasks

I can not honestly see how MRP Live can be used efficiently in real life scenarios and complex business environments.

Simply put, MRP Live doesn’t provide any means to check the results of MRP plannings.

Here I would plea to SAP:

Get MRP list back. Make them optional if they hinder performance but get them back.

Vote to support: https://influence.sap.com/sap/ino/#/idea/249067

Disclaimer: Opinions and views expressed herein are solely my own.