- SAP has proposed that HANA is a perfect fit for ERP. However, the evidence is that there is no advantage of HANA for ERP systems but there are many disadvantages.
- In this article, we discuss where our data comes from related to HANA’s mismatch.
Introduction to S/4HANA’s Mismatch with ERP Systems
SAP restricted S/4HANA to just the HANA database, breaking with decades of having their ERP system be database independent and creating great inconvenience and higher cost for customers. You will learn whether HANA is actually a fit for ERP systems.
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.
HANA as Perfect for MRP?
In an article titled SAP’s HANA Deployment Leapfrog’s Oracle, IBM and Microsoft published in Readwrite, the following quote reiterates this popularity.
During a multi-site news conference in New York, Palo Alto Calif., and Frankfurt, Germany, SAP demonstrated HANA’s speed using its manufacturing resource planning software. In Palo Alto, Hasso Plattner, SAP co-founder and board chairman, said the database will eventually be available in all products, whether on-premise or in the cloud. “All SAP products will go HANA,” he claimed.
HANA’s primary benefit is read access, which is beneficial for analytics. For MRP the processes used is far more important and one will not receive the same benefit. And it turns out that these statements by Hasso Plattner regarding MRP performance were false.
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 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.
A Major Advantage for Using with ERP Systems?
Column based databases like HANA are not an advantage when the database in question is supporting an application like an ERP system, or any other transaction processing system.
This is because transaction-processing systems tend to access all of the fields in a row. However, when the application in question is analytical, technically known as OLAP, then the database design/table configuration is a disadvantage because the typical query only accesses a few of the fields or columns in a table.
This is explained well in this paper from Oracle on the topic of their 12c product, which is another in-memory database.
“Oracle Database has traditionally stored data in a row format. In a row format database, each new transaction or record stored in the database is represented as a new row in a table. That row is made up of multiple columns, with each column representing a different attribute about that record. A row format is ideal for online transaction systems, as it allows quick access to all of the columns in a record since all of the data for a given record are kept together in-memory and on-storage. A column format database stores each of the attributes about a transaction or record in a separate column structure. A column format is ideal for analytics, as it allows for faster data retrieval when only a few columns are selected but the query accesses a large portion of the data set. But what happens when a DML operation (insert, update or delete) occurs on each format? A row format is incredibly efficient for processing DML as it manipulates an entire record in one operation i.e. insert a row, update a row or delete a row. A column format is not so efficient at processing row-wise DML: In order to insert or delete a single record in a column format all of the columnar structures in the table must be changed.”
This points out that for inserts, deletes or updates — which a transactions processing system — like an ERP system — does all the time. The column based table is slower than the row based — or what is known as the relational database (although using the term relational to differentiate row based on column-based databases is not technically accurate as they are both relational databases — the distinction is the format and type of tables used)
ERP on HANA Processing Problems
Getting back to the main point of this section, ERP on HANA will not speed the processing of ERP systems for most of what ERP systems do. This is Oracle’s point in this quotation from John Soat.
“SAP has not published a single benchmark result for any of its transaction processing applications running on HANA.”
I agree with John Soat, in that there is a very reasonable explanation for why SAP does not publish this…because the benchmarks are not impressive.
Where is Our Data Coming From?
This information that is provided below is from multiple sources. Some are from actual client sources. None of the sources is interested in being identified so they won’t be.
Furthermore, we have more information regarding details than we will provide in this or other articles. The reason for this is related to source protection. The way that we can provide this type of information is that the sources aren’t identified or can’t be traced by SAP through the detail that we provide.
Regarding our credibility, the reader can review our SAP prediction accuracy list.
Brightwork is not paid by SAP or any other database vendor (or any non-database vendor for that matter.) We have no incentive to push one database above another. We don’t own stock in any database vendor or any other financial tie. And furthermore, our analysis in this area should not be seen as a general endorsement for any non-SAP vendor.
This differentiates us from Forrester and Gartner who are paid by database vendors. Forrester sometimes declares these payments, Gartner never does.
The Problem Between HANA and ERP
The data we have analyzed show the following performance features of HANA.
- Simple queries for analytics run quickly, but not any more rapidly than competing databases.
- Complex queries for analytics run more quickly than a row-oriented database, but not as fast as competing databases.
- Transaction processing (things like posting goods issue, decrementing inventory, etc..) runs significantly slower on HANA than on row-oriented databases. That is even when accounting for HANA’s better hardware.
- Processor intensive operations run significantly slower on HANA than on row-oriented databases. Again, this is even when accounting for HANA’s better hardware. An example of a processor intensive activity is MRP. See our article How to Interpret HANA’s Problems with MRP.
See our other article which questions Why Do Companies Continue to Run MRP from ERP systems.
The problem with this information on HANA’s performance profile? ERP systems primary activities are number 3 & 4, transaction processing and processor intensive operations. Not 1 & 2. This means the overall system will run slower if the transaction processing and processor intensive activities are disadvantaged.
This is a severe problem for HANA’s value for ERP systems. The things HANA does well, are not related to what ERP primarily does.
Transaction Processing Problems
HANA has had continual problems in what should be the primary focus of any database that supports an ERP system, transaction processing. Transaction processing is the most important thing that any ERP system does and SAP’s marketing around the importance of analytics has not changed the primary processing type of ERP.
On April 10, 2018 Lenovo published the technical paper, Lenovo SAP S/4HANA Scale out – Cycle 1.
This paper included a number of inaccuracies, which should not be surprising as Lenovo is an SAP partner and has a series of products they are trying to sell that are connected to HANA.
Notice the hardware specification below from the Lenovo paper.
The HANA box has a higher hardware specification, but it is hidden with the AnyDB/ECC server configuration not called out.
Natural questions that arise.
- Where is the hardware configuration listing on the AnyDB/ECC server?
- How is the reader to know if the hardware is comparable? As we have pointed out in the article How Much of Performance is HANA?, many improvements that have been seen from HANA are due to the entity testing HANA against older hardware and previous versions of AnyDB.
Either Lenovo does not know how to list the specifications of the box, or more likely, Lenovo is excluding the AnyDB/ECC listings to obscure the fact that the hardware is not remotely comparable. How can this go unnoticed by those that read these studies?
Now look at the transaction processing.
Why are the exact comparisons redacted? Secondly, how is anyone to know how much of the improved transactions are from the HANA boxes higher hardware specification? And SAP promised massive improvements in performance across the board, so why are any of the transactions negative?
The redaction is quite odd, as there is no reasonable explanation why this should be.
Analytics on S/4HANA?
Now one could construct a scenario where a bunch of analytics is performed in ECC/S/4HANA. SAP has stated this as their vision. The concept is that all analytics would be performed inside the ERP system. Let us go back to the Lenovo study.
This is compared against an older version of most likely either Oracle or DB2, which did not have multimodel capability (that is column-oriented with row-oriented). However, why are any of the analytic scores slower than the older database versions?
- Observations from the field show HANA underperforming all of the competitor databases, even SQL Server even in analytic workloads. This level of improvement, up to 2846% shows the hardware difference between the ECC box and the HANA box.
- Once again we have redacted actual scores. What is being hidden here?
Columnar databases are a disadvantage for ERP systems or any transactional processing system. That is what makes SAP’s statements about SAP entirely inaccurate. Secondly, in any ERP system, data can be aggregated and updated to just a few hundred tables. These tables can be made columnar — while the rest of the database stays as row-based (or as is known as relational). This is the design deployed by Oracle 12C, and it calls into big issue the design used by ERP on HANA. Details on this plan are available in this article
These tables can be made columnar — while the rest of the database stays as row-based (or as is known as relational). This is the design deployed by Oracle 12c, and it calls into big issue the design used by SAP for ERP on HANA. Details on this plan are available in this article Which is Faster, HANA or Oracle 12C?
Thus there is no way to see HANA performance profile as anything but a net loss in performance for ERP.
This means that the migrations of ECC to HANA as well as implementations of S/4HANA, what there are of them, resulting in performance degradation for the companies that implemented them.
Furthermore, SAP customers paid a very high premium for a reduction in performance.
SAP’s Inaccurate Messaging on HANA as Communicated in SAP Videos
Fact-Checking SAP’s HANA Information
This video is filled with extensive falsehoods. We will address them in the sequence they are stated in this video.
SAP Video Accuracy Measurement
|SAP's Statement||Link to Analysis Article|
|HANA is a Platform||HANA is not a platform, it is a database.||How to Deflect You Were Wrong About HANA|
|HANA runs more "in-memory" than other databases.||HANA uses a lot of memory, but the entire database is not loaded into memory.||How to Understand the In-Memory Myth|
|S/4HANA Simplifies the Data Model||HANA does not simplify the data model from ECC. There are significant questions as to the benefit of the S/4HANA data model over ECC.||Does HANA Have a Simplified Data Model?|
|Databases that are not HANA are legacy.||There is zero basis for SAP to call all databases that are not HANA legacy.||SAP Calling All Non-HANA DBs Legacy.|
|Aggregates should be removed and replaced with real time recalculation.||Aggregates are very valuable, and all RDBMS have them (including HANA) and they should not be removed or minimized in importance.||Is Hasso Plattner Correct on Database Aggregates?|
|Reducing the number of tables reduces database complexity.||Reducing the number of tables does not necessarily decrease the complexity of a database. The fewer tables in HANA are more complicated than the larger number of tables pre-HANA.||Why Pressure SAP to Port S/4HANA to AnyDB?|
|HANA is 100% columnar tables.||HANA does not run entirely with columnar tables. HANA has many row-oriented tables, as much as 1/3 of the database.||Why Pressure SAP to Port S/4HANA to AnyDB?|
|S/4HANA eliminates reconciliation.||S/4HANA does not eliminate reconciliation or reduce the time to perform reconciliation to any significant degree.||Does HANA Have a Simplified Data Model and Faster Reconciliation?|
|HANA outperforms all other databases.||Our research shows that not only can competing databases do more than HANA, but they are also a better fit for ERP systems.||How to Understand the Mismatch Between HANA and S/4HANA and ECC.|
The Problem: A Lack of Fact-Checking of HANA
There are two fundamental problems around HANA. The first is the exaggeration of HANA, which means that companies that purchased HANA end up getting far less than they were promised. The second is that the SAP consulting companies simply repeat whatever SAP says. This means that on virtually all accounts there is no independent entity that can contradict statements by SAP.
The Necessity of Fact Checking
We ask a question that anyone working in enterprise software should ask.
Should decisions be made based on sales information from 100% financially biased parties like consulting firms, IT analysts, and vendors to companies that do not specialize in fact-checking?
If the answer is “No,” then perhaps there should be a change to the present approach to IT decision making.
In a market where inaccurate information is commonplace, our conclusion from our research is that software project problems and failures correlate to a lack of fact checking of the claims made by vendors and consulting firms. If you are worried that you don’t have the real story from your current sources, we offer the solution.
The major problem with companies that bought HANA is that they made the investment without seeking any entity independent of SAP. SAP does not pay Gartner and Forrester the amount of money that they do so these entities can be independent as we covered in the article How Accurate Was The Forrester HANA TCO Study?
Inaccurate Messaging on HANA as Communicated in SAP Consulting Firm Videos
For those interested in the accuracy level of information communicated by consulting firms on HANA, see our analysis of the following video by IBM. SAP consulting firms are unreliable sources of information about SAP and primarily serve to simply repeat what SAP says, without any concern for accuracy. The lying in this video is brazen and shows that as a matter of normal course, the consulting firms are happy to provide false information around SAP.
SAP Video Accuracy Measurement
|SAP's Statement||Link to Analysis Article|
|HANA runs more "in-memory" than other databases.||HANA uses a lot of memory, but the entire database is not loaded into memory.||How to Understand the In-Memory Myth|
|HANA is orders of magnitude faster than other databases.||Our research shows that not only can competing databases do more than HANA, but they are also a better fit for ERP systems.||How to Understand the Mismatch Between HANA and S/4HANA and ECC.|
|HANA runs faster because it does not use disks like other databases.||Other databases also use SSDs in addition to disk.||Why Did SAP Pivot the Explanation of HANA In Memory?|
|HANA holds "business data" and "UX data" and "mobile data" and "machine learning data" and "IoT data."||HANA is not a unifying database. HANA is only a database that supports a particular application, it is not for supporting data lakes.|
|SRM and CRM are part of S/4HANA.||SRM and CRM are not part of S/4HANA. They are separate and separately sold applications. SAP C/4HANA is not yet ready for sale.||How Accurate Was Bluefin Solutions on C-4HANA?|
|Netweaver is critical as a platform and is related to HANA.||Netweaver is not relevant for this discussion. Secondly Netweaver is not an efficient environment from which to develop.|
|HANA works with Business Objects||It is very rare to even hear about HANA and Business Objects. There are few Buisness Objects implementations that use HANA.||SAP Business Objects Rating|
|Leonardo is an important application on SAP accounts.||Leonardo is dead, therefore its discussion here is both misleading and irrelevant.||Our 2019 Observation: SAP Leonardo is Dead|
|IBM Watson is an important application on SAP accounts.||Watson is dead, therefore its discussion here is both misleading and irrelevant.||How IBM is Distracting from the Watson Failure to Sell More AI and Machine Learning|
|Digital Boardroom is an important application on SAP accounts.||SAP Digital Boardroom is another SAP item that has never been implemented many places.|
Financial Bias Disclosure
Neither this article nor any other article on the Brightwork website is paid for by a software vendor, including Oracle, SAP or their competitors. As part of our commitment to publishing independent, unbiased research; no paid media placements, commissions or incentives of any nature are allowed.
Search Our Other HANA Performance Content
The Risk Estimation Book
Better Managing Software Risk
The software implementation is risky business and success is not a certainty. But you can reduce risk with the strategies in this book. Undertaking software selection and implementation without approximating the project’s risk is a poor way to make decisions about either projects or software. But that’s the way many companies do business, even though 50 percent of IT implementations are deemed failures.
Finding What Works and What Doesn’t
In this book, you will review the strategies commonly used by most companies for mitigating software project risk–and learn why these plans don’t work–and then acquire practical and realistic strategies that will help you to maximize success on your software implementation.
Chapter 1: Introduction
Chapter 2: Enterprise Software Risk Management
Chapter 3: The Basics of Enterprise Software Risk Management
Chapter 4: Understanding the Enterprise Software Market
Chapter 5: Software Sell-ability versus Implementability
Chapter 6: Selecting the Right IT Consultant
Chapter 7: How to Use the Reports of Analysts Like Gartner
Chapter 8: How to Interpret Vendor-Provided Information to Reduce Project Risk
Chapter 9: Evaluating Implementation Preparedness
Chapter 10: Using TCO for Decision Making
Chapter 11: The Software Decisions’ Risk Component Model