- SAP makes outrageous statements about MRP on HANA.
- SAP proposes that there will be no batch processing in S/4HANA.
- Yet results from global S/4HANA implementations is that S/4HANA has problems with both MRP and transaction processing.
- Gartner and Forrester, who have both been paid by SAP to repeat SAP’s proposals are silent on this issue.
- There is no coverage in this in the IT media.
Introduction to MRP on HANA
SAP has proposed that HANA is important for improving MRP performance.
SAP made these proposals some time ago. However, between making those proposals and now, Brightwork has performed extensive research into HANA. So now that much more is known.
In this article, we will review SAP’s proposals on MRP performance on HANA with this knowledge, as well as with information from the field on actual MRP performance.
What SAP Says About HANA and MRP
SAP has proposed that with HANA there will be no more batch processing. The following is how they phrased this proposal.
“No More Batch — All Processes in Real-Time”
“…enterprises can dramatically simplify their processes, drive them in real time and change them as needed to gain new efficiencies – no more batch processing is required.”
No Batch Processing in S/4HANA?
SAP proposed that there will be no latency of any process in S/4HANA due to HANA. This means that no matter what process the company sets S/4HANA to do — that process will be completed in real time. If we look at MRP, it is common for MRP to be performed on what is called a “net change” basis. This means that only product location combinations that have had a change are processed.
The reason for this is to limit time spent processing. It is common for MRP to take several hours and this job is typically scheduled every weekday in the evening so as not to disrupt business operations. Then, on the weekend, a second MRP planning run is usually scheduled that performs a complete recalculation of all relevant product locations.
The Actual Problem with MRP Performance in SAP ECC
After seeing many MRP instances, the only situations that we have seen where MRP runtimes were a problem where there were system setup issues. One issue, for example, is when there are a large number of invalid location product combinations that must be processed.
With HANA, SAP claimed, there would be no latency. We should make sure we realize how large this claim is. This means that it should be possible to schedule a complete recalculation of the entire combination of product locations in the middle of the day, as the calculation will all be instantaneous. Two minutes later, an entire MRP run of every product location should be able to be performed, and once again, the time taken to run MRP should not be measurable. That is the definition of “no latency.”
This is a peculiar claim. And there are several reasons for this. Given today’s hardware and software capabilities, unless the model is very small, it is not possible.
The first reason is that given today’s hardware and software capabilities unless the model is very small, it is not possible.
The second reason gets into the what MRP does versus what HANA is. If one takes most of the batch processes in ERP, but MRP being an excellent example, the bottleneck on processing is the calculation. That is the microprocessor load. Not the database load. So it would not be feasible that HANA, which only speeds analytical processing, to do very much to speed MRP or other types of processor intensive activities.
Hasso Plattner Weighs In
On November 30, 2015, Hasso Plattner, one of the co-founders of SAP, published “How to Understand the Business Benefits of SAP S/4HANA Better.”
“I just heard of a Chinese fashion manufacturer who installed SAP S/4HANA and reports a game changing improvement of the MRP2 run from more than 24 hours to under two hours. My advice for the smaller and midsize SAP Business Suite customers is to carefully watch the early adopters, soon approaching 2000, especially in related industries.” ‒Hasso Plattner
There are several curious things about this statement. First, This occurred before November 30, 2015. However, Hasso implies that this company moved from the pre-HANA version of SAP enterprise software — known as ECC — to HANA. (Yet, this earlier software runs on HANA.) He states that the Chinese company purchased and implemented S4 EM. However, as of June 2016, S4 EM was still some way away from full release. Only S4 Finance — previously called SAP Simple Finance — is available for purchase.
So the first question is how it is possible that this Chinese fashion manufacturer was even using S/4HANA for MRP.
But if we leave this issue to the side for a moment (it is an important question, but let us take this in stages), the question of how placing MRP on an analytics database versus a transaction processing database made such a difference in the MRP runtime is an important one.
- It is important because technically the claim does not make sense.
- Secondly, information from the field is that MRP does not run faster on HANA, but instead that it runs slower.
Feedback from Customers on MRP on HANA
The following are descriptive quotes from a person from a customer that uses MRP on HANA. They are consistent but more detailed than similar information we have received from multiple sources.
“Running MRP on HANA and the performance of the MRP job is horrendous. It runs in 8-12 hours, while the same amount of data on MSFT SQL (Server) ran in 1 hour. So far I’m quite unimpressed. Especially considering how much $$$ we spent!”
Unsurprisingly the output of MRP is not used as he describes in the following quotation.
“We don’t use the results of MRP, but we use the output to feed downstream systems. Across the board transactional performance is horrendous, the stats speak for themselves.”
This brings up a question of why MRP is being run at this customer. Is this simply to justify having gone through the expense of buying and implementing SAP?
MRP engines are easy to find and can be integrated to SAP. This customer could simply have an external MRP engine perform the processing and then put the results back into SAP.
And of course, this would allow the customer to use the results of MRP in the system — another benefit.
“Our ATP process is a heroic effort that takes an entire weekend with not a moment to spare. Jobs that we would usually run once a day in now take 8+ hours. Once we have all of our global companies in the same instance, I have no idea how our jobs are going to run with limited windows for downtime.”
The consensus of what we hear from multiple sources is certainly not “no batch processes and everything in real time” but rather significant performance problems with MRP on HANA. These are problems that did not exist when MRP was run on Oracle or DB2.
These are problems that did not exist when MRP was run on Oracle or DB2.
A Lack of SAP Claim Verification
SAP often makes statements indicating that improved performance is driving the migration to S/4HANA. These statements are typically accompanied by other amorphous examples (e.g., S/4HANA performance improvement during end-of-period close.) These statements are not checking out from the feedback that has come in from multiple SAP customers.
After extensive analysis, it turns out that these statements are not checking out from the feedback that has come in from multiple SAP customers.
Furthermore, Brightwork Research & Analysis has been the only entity specializing in SAP that has called into question whether the claims made by SAP in this area actually made any sense. Our view is that they never did make any sense and they have been targeted at executives that think they can guess if SAP is telling the truth, without relying on people with the right background to verify these claims.
Nothing to Say, Gartner, and Forrester?
Both Gartner and Forrester have been notably quite silent on whether any of SAP’s claims for HANA on transaction processing made any sense. This brings up the question of whether they actually have any interest in verifying information or see themselves as simply repeating mechanisms of vendors with the largest analyst budgets. Critiquing a vendor that pays you so much money would be biting the hand the feeds you. Gartner and Forrester can simply “look the other way” as one proposed capability of HANA are proven false after another.
Taken another way, if SAP pays about every media source, what media source has any interest in contradicting SAP? Isn’t it necessary to contradict vendors if the information provided by vendors is inaccurate? What is the definition of independence? In my last article, I quoted Gartner saying that “bias at Gartner is a non-issue.”
Not only Gartner but many other IT media entities it seems like not only a massive issue but an issue that is not going away.
The original claim made by SAP that an analytics database would eliminate all batches in the system was always highly unlikely to be true, even before receiving the feedback that we have now obtained.
It now entirely obvious that running MRP on HANA not only does not lead to the elimination of batches, but it also does not lead to performance improvement, and in fact, greatly lengthens the processing window for MRP. That is MRP on HANA so far seems like a giant step backward.
Financial Bias Disclosure
This article and no other article on the Brightwork website is paid for by a software vendor, including Oracle and SAP. Brightwork does offer competitive intelligence work to vendors as part of its business, but no published research or articles are written with any financial consideration. As part of Brightwork’s commitment to publishing independent, unbiased research, the company’s business model is driven by consulting services; no paid media placements are accepted.
MRP Repair Book
What is the State of MRP?
MRP is in a sorry state in many companies. The author routinely goes into companies where many of the important master data parameters are simply not populated. This was not supposed to be the way it is over 40 years into the introduction of MRP systems.
Getting Serious About MRP Improvement
Improving MRP means both looking to systematic ways to manage the values that MRP needs, regardless of the MRP system used. It can also suggest evaluating what system is being used for MRP and how much it is or is not enabling MRP to be efficiently used. Most consulting companies are interested in implementing MRP systems but have shown little interest in tuning MRP systems to work to meet their potential.re
The Most Common Procedure for Supply and Production Planning?
While there are many alternatives to MRP, MRP, along with its outbound sister method DRP, is still the most popular method of performing supply, production planning, and deployment planning. In the experience of the author, almost every company can benefit from an MRP “tune up.” Many of the techniques that the author uses on real projects are explained in this book.
- Chapter 1: Introduction
- Chapter 2: The Opportunities to Improve MRP
- Chapter 3: Where Supply Planning Fits Within the Supply Chain
- Chapter 4: MRP Versus MRP II
- Chapter 5: MRP Explained
- Chapter 6: Net Requirements and Pegging in MRP
- Chapter 7: Where MRP is Applicable
- Chapter 8: Specific Steps for Improving MRP
- Chapter 9: Conclusion
- Appendix A: Calculating MRP