- 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.
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.
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.
Hasso Plattner has stated that he does not like BI systems. And we have been pitched this idea by a wide variety of SAP resources in the past, and quite aggressively. This was combined with a declaration that Fiori was going to allow all these fantastic things to happen on the UI side.
But that does not happen now, and Fiori, as readers may know, is something that we have predicted is an intermediate offering on the way to a new UI. If not see the article Why Fiori Will Not Survive.
So there is no pathway for that to happen for a while. SAP has no way of achieving the front end required for this, and this information on benchmarking for HANA illustrates that HANA is weak in performing the long queries that are required for ERP system analytics.
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.
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