How to Understand Why HANA is a Mismatch for S/4HANA and ECC

Executive Summary

  • 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.

Our Independence

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.

  1. Simple queries for analytics run quickly, but not any more rapidly than competing databases.
  2. Complex queries for analytics run more quickly than a row-oriented database, but not as fast as competing databases.
  3. 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.
  4. 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.

Brightwork Disclosure

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.

HANA & S/4HANA Question Box

  • Have Questions About S/4HANA & HANA?

    It is difficult for most companies to make improvements in S/4HANA and HANA without outside advice. And it is close to impossible to get honest S/4HANA and HANA advice from large consulting companies. We offer remote unbiased multi-dimension S/4HANA and HANA support.

    Just fill out the form below and we'll be in touch.


The Risk Estimation Book


Software RiskRethinking Enterprise Software Risk: Controlling the Main Risk Factors on IT Projects

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

Risk Estimation and Calculation

Risk Estimation and Calculation

See our free project risk estimators that are available per application. The provide a method of risk analysis that is not available from other sources.


What is the Accuracy of CONSILIO IT on MRP on HANA Performance?

Executive Summary

  • HANA on MRP
  • The Supposed Practice Test with Realistic Data Volume
  • And Now on to Big Data?
  • CONSILIO IT’s Fake MRP Test
  • CONSILIO IT’s Confusion Between Planning and Execution
  • CONSILIO IT Implies it Has Performed Full TCO and ROI Analyses of MRP on HANA
  • MRP on HANA for Simulation?
  • The Real Story on MRP on HANA (from a Research Entity Rather than Someone Trying to Sell HANA and S/4HANA Services)


In this article, we will review the accuracy of the article by IT which references information provided by the consulting company CONSILIO IT. CONSILIO IT is an SAP consulting partner, and consulting partner normally provide highly inaccurate information about SAP. Let’s see how they did in this article.


Here is how the article begins…

“In Material Requirements Planning (MRP), time-optimized and transparent processes are a critical success factor, but every minute, especially in economic turbulent times. Innovative MRP solutions based on the real-time platform SAP HANA convince with an unparalleled performance gain.”

This description starts off using deception. MRP processing is not an issue at companies unless they have misconfigured their ERP system. Also, there is no evidence that current times are more turbulent than previous economic times.

Finally, the real-time nature of HANA is not proven. HANA performs worse than Oracle 12c in analytics, and has no track record of performing well in processing or in transaction processing, which is why SAP publishes no benchmark for transactions, while in the past it did. This point is covered in the following quotation from the book SAP Nation 2.0.

“It has not helped matters that SAP has been opaque about HANA benchmarks. For two decades, its SD benchmark, which measures SAP customer order lines processed in its Sales and Distribution SD module, has been the gold standard for measuring new hardware and software infrastructure. It has not released those metrics using a HANA database. One of the (unsatisfactory) excuses offered is that the expensive hardware needed to support such a test in a lab is better shipped to paying customers.”

“In the meantime, database players like Oracle and Microsoft are offering their own in-memory switches while supporting the systems management and IT talent infrastructure most CIOs have built over the last few decades. So in a couple of years SAP may have to reverse source about database portability. SAP has already shared dates for continued support of the Oracle Database 12c in-memory switch and its Engineering Systems products like Exadata and the SPARC SuperCluster.”

HANA is an analytics database that has yet to master (updated as of information coming to us in September 2018), dual model database processing with anywhere near the promised performance.

Lets move to the next quote which addresses the performance improvement.

“27 minutes instead of 22 hours for material requirements planning – this is the performance improvement achieved by an MRP solution with SAP HANA technology compared to a classical MRP. These impressive figures have recently provided a test scenario for the specialist solution provider CONSILIO IT-Solutions, a company founded by former SAP and KPMG managers, who is constantly testing and developing new developments for its customers in the logistics, production, organization and information technology industries in innovative applications for its customers.”

This performance improvement is not matched by any of the observations that Brightwork Research & Analysis has collected (which include both client data points and benchmarks).

In fact, quite the opposite.

Our observations point to MRP performing quite a bit worse than MRP on even older versions of Oracle or SQL Server. This result was either found through rigging the test or by simply making up this number. Remember, SAP has never produced a benchmark indicating anything like this. We cover this in the following article What is the Actual HANA Performance?

Was This Article a Paid Placement?

CONSILIO IT clearly wants to sell services in HANA and S/4HANA and they are not a reliable guide for benchmarks. Is this publication validating any of these statements or do they come straight from CONSILIO IT? Actually, is this entire article looks like a paid placement from CONSILIO IT.

“The latest new development from SAP, the HANA database system, is proving to be a powerful efficiency lever thanks to in-memory computing.”

All computing is “in memory,” which we covered in the article How to Understand Why In-Memory Computing is a Myth. So this lack of distinction makes no sense. HANA proposed that it put the entire database into memory, a technique considered inefficient, but then later we found that HANA does not work this way, it memory optimizes. HANA uses a great deal of memory as we cover in the article How HANA Takes 30 to 40 Times the Memory of Other Databases, and that is the distinction. But benchmarking clearly shows that HANA has difficulty addressing the memory in the hardware footprint.

“The technology offers increased speed in compressed storage, networking and real-time analysis: the availability of materials and their stock ranges can be displayed in real-time.”

If HANA cannot outperform other similar databases with far smaller hardware footprints, why would any of this be true?

Material and stock ranges are already displayed in real time in every system we have reviewed. It is unclear what CONSILIO IT even means here. It may simply be repeating what SAP marketing.

Compression is irrelevant as storage is quite inexpensive. Do we cover this in the article What Was John Appleby’s Accuracy in Moving BW to HANA?

The comment of networking is a non-sequitur.

With or without HANA “real-time” analytics are already possible on all data platforms, if the data is prepared. It depends upon what data is a question — but again, HANA does not show performance advantages over competitive databases.

“This demonstrates a lot of potential, rightly demonstrated in the right applications, such as the practice test mentioned at the outset. HANA-based MRP solutions can dramatically accelerate complex material supply scheduling and capacity planning.”

We will discuss our observations which contradict this further on in the article.

The Supposed Practice Test with Realistic Data Volume

“Background of the practice test: Many companies suffer from a too slow material requirements planning run because the technical possibilities of classical databases do not give a faster data processing.”

No that is incorrect. The only reason for slow MRP that we have observed is when the system is not configured properly.

Second, as HANA is an analytics database, it should not be expected to improve MRP performance. Real life observations indicate that none of the statements SAP has made about being able to perform OLTP and OLAP out of the same database are true.

“Frequently, material requirements planning is subject to constraints, especially when new concepts, such as restriction-based and optimizing methods, are to compensate for the deficits of the MRP. The data volume increases and the run times of the programs are even longer.”

This paragraph is virtually unintelligible. So we have to guess what CONSILIO IT actually means.

New methods for supply planning have existed for some time. But they were developed not because of performance problems with MRP but because the methods were considered improvements on MRP regarding the planning output. These methods are covered in the book Supply Planning with MRP, DRP and APS Systems. But how does running MRP faster address those deficits? For instance, unlike inventory optimization and multi echelon planning, MRP does not know the stocking levels of locations that surround a particular planning location. Running MRP faster does not change that limitation. Running MRP faster also does not allow MRP to constrain resources.

CONSILIO IT seems deeply confused on the issue of MRP processing speed versus what MRP actually does versus other supply and production planning methods.

And Now on to Big Data?

“It was clear to us from the outset that the Big Data technology HANA offers completely different possibilities for our customers, not only in terms of optimizing the supply chain”, says David Reibnegger, project manager at CONSILIO.”

This is a massive switch in gears on the part of CONSILIO IT.

  • First, Big Data is not related to anything written above.
  • Secondly, HANA has nothing to do with Big Data, as described in the following article, HANA Big Data Equals Big Failure.

In terms of optimization of the supply chain, there are several methods available in supply and production planning that are “optimal.” One is inventory optimization and the second is cost optimization. Why use the term optimization as a general term (i.e. meaning to improve) when there are two methods available that actually deal with real optimization?


An ECC 6.0 system with HANA DB, the so-called MRP Live, and a realistic business scenario with three plants, were created for the practice test he carried out, creating more than 300,000 materials (including configurable materials) with up to 17 disposting points. The comparison data provided a classic ECC with a MaxDB and identical master data.

The larger the amount of data, the greater the effect

The planning process had to resolve 80,000 pre-planning requirements for finished products as well as 300 customer orders for configurable materials over a period of 12 months. The products were partly planned, partly consumption-controlled. “In order to present the effect of the HANA database as much as possible, we began with small amounts of data and successively increased the volume,” says Reibnegger, summarizing: “The result speaks for itself: The classic MRP based on MaxDB Parallelization needed 22 hours for the planning of the requirements and generated 10 million planned orders – with 52 million secondary requirements and 7 million purchase requisitions including stock transfer requirements.”

All of this seems quite unlikely. This has never happened in any of our observations and it makes no sense from the perspective of HANA’s design and what it has proven to do well previously.

It also makes no sense in terms of what HANA has shown that it is capable of. CONSILIO IT goes on to make the following ridiculous claim.

“In addition, the HANA database and the newly developed HANA MRP were able to play out their strengths with increasing data volume as the data volume increases. The more data, the greater the time-optimizing effect of the HANA in-memory database. Businesses know more quickly when they need something.”

This quotation is headed right into crazytown. This is particularly deceptive because HANA’s memory management is significantly lower performance than the competing offerings. This means that CONSILIO IT absolutely knows this entire paragraph is false. Furthermore, no database processes with an infinite improvement as more data is used. This is how a person who works in marketing thinks that databases work. If CONSILIO IT is intent on lying, they could at least try to make the lies somewhat credible. This quotation fact checks itself.

In-Memory Computing for more Efficient Production Planning

“The enormous run-time gain opens up completely new possibilities for MRP Live on HANA-based supply chain planning. For example, planning is possible during the day so that companies can react quickly and flexibly to market changes.”

This is based upon the premise of faster MRP runtimes that are proposed to have been documented by CONSILIO IT. At Brightwork Research & Analysis, we question whether any of this happened.

But even if we assume it is true, the related benefits of running MRP during the day don’t make much sense.

  • Currently, almost all companies perform a nightly MRP run, called a net change run. Remember, the forecast is already in the system.
  • As orders come in, they decrement the forecast. Therefore when new sales orders come in, they don’t necessarily increase demand.

The illusion being presented by CONSILIO IT is that just because a system can be updated quickly, the supply network can be updated quickly. But it can’t.

CONSILIO IT’s Confusion Between Planning and Execution

Real supply chains have real lead times and real constraints. The overall presentation by CONSILIO IT is an oversimplification of how supply chain planning reacts to changes. MRP is a planning method — emphasis on planning. Planning means an endeavor for the future. Execution requires instantaneous changes (on some occasions), but not planning.

Yet, the overall presentation by CONSILIO IT is an oversimplification of how supply chain planning reacts to changes. MRP is a planning method — emphasis on planning. Planning means an endeavor for the future. Execution requires instantaneous changes (on some occasions), but not planning.

And then, to top it off, in addition to misrepresenting/misunderstanding CONSILIO is basing its proposals based upon an inaccuracy regarding HANA’s improvement in MRP processing speed. CONSILIO IT is producing inaccurate information in an uncountable number of dimensions.

MRP on HANA for Better Simulation?

Here is what CONSILIO IT has to say about simulation.

“Simulation runs for the assessment of different scenarios can thus be generated and evaluated over the course of a day, unlike classical MRPs, which require several days. “With HANA, the MRP program can work substantially, unlike conventional systems, where such actions are typically shifted to night because of the amount of data,” explains Reibnegger. “With MRP Live you always have the latest planning results.”

ECC was never a good simulation environment, and there is no evidence that S/4HANA will be better. It is extremely rare to find ECC environments that perform simulation, and not enough S/4HANA environments are live to say much of anything about how companies use it.

Simulation encompasses much more than speed. MRP is better simulated in an external system that is designed for simulation. This is covered in the book How to Repair Your MRP System.

Some of the concepts are covered in the following article An Analysis of the Commonly Listed Problems with MRP.

“A more efficient planning with the MRP Live is also possible for companies with highly complex products, a large number of orders or industries with short-term demand fluctuations. As a result, companies can react very quickly and flexibly to new customer requirements during production planning and control, or to exceptional situations in production.”

This seems to imply that products with extensive BOMs could be planned better. However, current ECC systems normally don’t have a problem exploding very complex BOMs. Companies with complex BOMs tend to have fewer overall SKUs, so it tends to balance out.

The later part of the quote goes back to the topic of reacting quickly. However, just because the computer can recompute quickly does not mean the overall supply chain or the production floor can react quickly.

CONSILIO IT Implies it Has Performed Full TCO and ROI Analyses of MRP on HANA

“Even if the MRP Live is not yet fully developed and certain functionalities such as the termination of planned orders or long-term planning are still in development, the costs for an MRP solution based on HANA will have been quickly amortized, especially because of the supply Chain ‘time’ is de facto just another word for ‘money’. And here is already true: Fast, faster, MRP Live.”

Seems like something written on the back of a cereal box.

CONSILIO IT seems to be underplaying the very high costs associated with HANA. And of course CONSILIO IT’s consulting costs.

  • Does CONSILIO have any idea if this is true.
  • Have they calculated a full TCO for ERP on HANA? A full ROI?
  • How do they know what they are writing is true or are they simply guessing. They should say.

The Real Story on MRP on HANA from a Research Entity Rather than Someone Trying to Sell HANA and S/4HANA Services

In the previous Brightwork article, How to Interpret the Performance Problems of MRP on HANA,

We covered the observations that have been coming in about how the many problems that have surfaced when running MRP on HANA.


CONSILIO IT is making some outlandishly false claims about MRP on HANA and most likely lying about the performance improvement that it “tested.” They both provide false information about HANA performance and then top it off by misunderstanding how supply and production planning works. The cherry on top is to further propose, falsely, that MRP run times are currently a problem at many companies that run ECC (something SAP also says, but did not seem to say back when they were selling ECC for some reason).

This is all standard practice. SAP or the SAP consulting company produces exaggerated claims that are tantalizing to buyers, who then bring in the consulting company only to be disappointed.

Everything piece of information provided here by CONSILIO is inconsistent with what we know about both supply chain planning and our research into HANA.

  • This article receives a 1 out of 10 for accuracy. Literally, nothing in it was true.
  • It is obviously a paid placement, and most the article is “written” by CONSILIO IT, and then simply released it through IT

Brightwork Disclosure

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.

HANA & S/4HANA Question Box

  • Have Questions About S/4HANA & HANA?

    It is difficult for most companies to make improvements in S/4HANA and HANA without outside advice. And it is close to impossible to get honest S/4HANA and HANA advice from large consulting companies. We offer remote unbiased multi-dimension S/4HANA and HANA support.

    Just fill out the form below and we'll be in touch.




The Real Story on ERP Book

ERPThe Real Story Behind ERP: Separating Fiction From Reality

How This Book is Structured

This book combines a meta-analysis of all of the academic research on the benefits of ERP, coupled with on project experience.

ERP has had a remarkable impact on most companies that implemented it. Unplanned expenses for customization, failed implementations, integration, and applications to meet the business requirements that ERP could not–have added up to a higher Total Cost of Ownership for ERP were all unexpected, and account control, on the part of ERP vendors — is now a significant issue affecting IT performance.

Break the Bank for ERP?

Many companies that have broken the bank to implement ERP projects have seen their KPIs go down— but the question is why this is the case. Major consulting companies are some of the largest promoters of ERP systems, but given the massive profits they make on ERP implementations — can they be trusted to provide the real story on ERP? Probably not, however, written by the Managing Editor of SCM Focus, Shaun Snapp — an author with many years of experience with ERP system. A supply chain software expert and well known for providing authentic information on the topics he covers, you can trust this book to provide all the detail that no consulting firm will.

By reading this book you will:

  • Examine the high failure rates of ERP implementations.
  • Demystify the convincing arguments ERP vendors use to sell ERP.
  • See how ERP vendors take control of client accounts with ERP.
  • Understand why single-instance ERP is not typically feasible.
  • Calculate the total cost of ownership and return on investment for your ERP implementation.
  • Understand the alternatives to ERP.


  • Chapter 1: Introduction to ERP Software
  • Chapter 2: The History of ERP
  • Chapter 3: Logical Fallacies and the Logics Used to Sell ERP
  • Chapter 4: The Best Practice Logic for ERP
  • Chapter 5: The Integration Benefits Logic for ERP
  • Chapter 6: Analyzing The Logic Used to Sell ERP
  • Chapter 7: The High TCO and Low ROI of ERP
  • Chapter 8: ERP and the Problem with Institutional Decision Making
  • Chapter 9: How ERP Creates Redundant Systems
  • Chapter 10: How ERP Distracts Companies from Implementing Better Functionality
  • Chapter 11: Alternatives to ERP or Adjusting the Current ERP System
  • Chapter 12: Conclusion

SAP’s Big Idea: ERP Data and Big Data on the Same Database?

What This Article Covers

  • One of the Main Proposals of HANA
  • Important Foundational Logic to the SAP Proposal
  • The Kaeser Kompressor Case Study Explanation
  • The Problem with SAP’s Single Database Proposal


SAP has been proposing for some time that there would be a massive change in how data is stored and analyzed. In this article, we will cover what SAP has proposed and whether if it is feasible.

SAP’s Proposal

Since HANA was first introduced, SAP has been proposing that HANA can do all types of database processing, transaction, analytics, read, write, insert, etc.. SAP has proposed, because of the universal Swiss Army Knife aspect of HANA, that SAP customers can stop moving data out of the ERP system (and in fact all systems, but lets keep to the more simple version of the argument) and it can run all reporting on the ERP system. This would break with the way that reporting/analytics has been previously setup, where the data is migrated to a specialized data store, called a data warehouse. In the current solution design for instance when ECC is used with either BW or BusinessObjects, either BW or Business Objects sits on the data warehouse.

Important Foundational Logic to the SAP Proposal

The foundational logic to this proposal is found in the column oriented database design. The column-oriented table is optimized for reading access. Both BW and BusinessObjects places data from applications where they originate into data cubes. These data cubes can be actual cubes called MOLAP, or emulated cubes called ROLAP. For the purposes of this article, the distinction is not important. What is important is that for many years, data cubes were the standard approach for improving the read speed and therefore the report run speed of data.

With the combination of the column-oriented table design, which contains special advantages when combined with the data to be accessed being placed into memory (as is explained in the article How SAP HANA is Such as Fast Database), data cubes are no longer necessary. SAP has not done much with this ability, however, as SAP’s customers already invested in creating data cubes and “universes” (a BusinessObjects term) in their data warehouses. So while it is a relatively straightforward manner to take BW and place it onto HANA, it is far less simple to reverse engineer all of the data cubes that have been built up over years. So the data cubes that have been created in the past mostly stay in place. Much of the software development in BW and BusinessObjects has been in creating a backend that allows data to be accessed more quickly. This is a capability that has been addressed with a combination of hardware and the database table design.

The concept behind doing away with the data warehouse and simply combining the ERP system with the reporting system on a HANA database is what I have covered up to this point. However, the following SAP promotional video takes the concept a step further, but stating that not only would reporting be placed on HANA, but HANA would also be a location for Big Data.

The Kaeser Kompressor Case Study Explanation

Has Kaeser Kompressor actually moved to reporting, Big Data and running ERP off of a single database? Or, is Kaeser Kompressor describing a concept that SAP has put forward that sounds appealing? 

The Problem with SAP’s Single Database Proposal

  • HANA’s Claim to be a Swiss Army Knife: SAP has asserted that HANA is equally good at all types of data processing, however, it has provided no evidence to back up this claim. SAP has stopped performing a benchmark for transaction processing, which is exactly the type of processing that HANA could be expected to be poor at performing. This is covered in the article What is the Real Performance of HANA? Secondly, what is very well known by SAP, (as I have spoken to people inside of SAP) is that SAP is poor at writing data to the database. This may not be all that surprising as column-oriented tables are inferior to row oriented tables for writing data, however, the number of problems that I am hearing about on projects that use HANA for S/4HANA indicates that SAP may have made some tables that should have been kept as row-oriented, to be column-oriented. It should have been fairly obvious that SAP should not have done this, but increasingly it is appearing as if SAP did make mistakes in the development of HANA. These design problems fall in stark contrast to the marketing material released by SAP, and effusive articles written by people like John Appleby of Bluefin Solutions, who were simply repeating SAP marketing literature in order to ingratiate themselves to SAP by publishing information that built up HANA expectations to a fever pitch, as is covered in the article How John Appleby Was So Wrong in his HANA Predictions.
  • Reversing the Work Done in Data Warehousing: SAP is proposing a radical change in how the analytics/reporting systems are setup. It means reversing course and removing large amounts of investment that companies have already implemented.
  • Buying New Hardware and Software: A customer must purchase very expensive hardware, software and consulting. Their payback is that they might incur lower future costs in both integration (no integrations to the data warehouse from ERP or any other application would be necessary) and IT labor, as report developers would no longer need to create complex data structures like data cubes to reach the desirable report speed. SAP BW, in particular, is saddled with a horribly inefficient backend where the data cubes are created. Yet, while the expensive hardware, software and consulting are a certainty with respect to implementing HANA, the savings are simply predicted. And in case anyone is curious, SAP’s ability to predict cost savings is not very high.
  • Purchasing S/4HANA: One can run ECC on HANA, called Suite on HANA, but SAP wants customers to move to S/4HANA to receive the proposed vision. ECC on HANA is an expensive proposition. S/4HANA is not only an expensive proposition, it has a far higher probability of failure than success. S/4HANA is an immature application that has very little implementation success. This is covered in the research The S/4HANA Implementation Study.
  • HANA’s Cost: HANA is the most expensive database on the market. It is priced per GB, and its price is very high per GB. HANA is one of the only databases to be sold this way. And this means that it is not feasible to keep very much data in HANA. SAP has a comeback on this, which is that HANA compresses so that the data footprint is in fact very small. I have reviewed all of SAP’s claims in this area, as have many others, who are not at liberty to write publicly on the topic, and the arguments have been found to be deceptive. SAP has created a very expensive database and there is no way around that fact. SAP created the compression argument to combat the very real perception that HANA is so expensive.
  • Big Data: The Kaeser Kompressor video pushes the concept into ludicrous territory. No company would place large amounts of unstructured data into HANA. Firstly, HANA is not a Big Data database. It is a column-oriented design, not an unstructured repository like NoSQL or Hadoop. Secondly, even if for some strange reason it wanted to, it could not affort do.


SAP is presenting a fantasy to customers. The intent to provide such an overwhelming vision, that their customers simply purchase HANA. So that their customers want to move to S/4HANA so that they can receive all the benefits of running ERP and reporting off of a single database. However, upon analysis, this vision is really not all that compelling. Secondly, even if the vision were compelling, there are very large barriers, including SAP’s own pricing of HANA, the maturity of S/4HANA, to making the vision a reality. Furthermore, SAP’s proposal on this topic has lead companies like Kaeser Kompressor to propose even more unrealistic visions, such as a single database for not only the ERP system and for reporting, but for Big Data as well.

How Much Do You Know About?


This quiz will ask basic questions around SAP HANA.

Our Work on HANA

We are the most prominent research entity that tells the real story HANA and S/4HANA. Both Forrester and Gartner take money from SAP, and Forrester created a false research report on how HANA reduces TCO in return for money. Companies like IBM, Deloitte, and Accenture have mindlessly repeated all of the SAP marketing talking points on HANA and S/4HANA have encouraged their customers to only accept HANA and S/4HANA so they can get the implementation business.

  • Are you a company interested the actual performance benefit from HANA and S/4HANA?
  • Do you need pricing and accurate database sizing for HANA for costing purposes?
  • Are you interested in accessing unbiased and deep research on HANA and S/4HANA for your company?

For more information fill out the form at the end of this page.

Supporting Articles

This article is based on some my previous articles on HANA DB.

This article covers whether SAP’s relentless HANA push has paid off.

This article covers how HANA DB is marketed versus other databases.

This article covers what moving to the cloud means for HANA.

This article covers if HANA DB has a simplified data model.

This article includes what one gets from Fiori. This article goes into how Fiori has been misrepresented by SAP and its partners in the sales process to get people all bubbly about S4, and what a huge surprise so many companies will get if they rely upon Fiori.

This article covers how Gartner got Fiori so wrong. Gartner clearly did close to zero research to praise Fiori and recommend it, without having any understanding of how Fiori works.

This article questions which is faster, HANA DB or Oracle 12C.

This article questions the validity of SAP’s Run Simple marketing program.

This article discusses the exaggerated claims made in so many articles about HANA.

This article questions whether SAP will have to backtrack on limiting S4 to HANA.

This article describes how the HCP is designed for cloud washing to make SAP implementations seems more cloud-based then they are.

Getting Clear on SAP’s Claims on S/4HANA

Executive Summary

  • It is very difficult to get clear on S/4HANA. SAP uses the language of selling to propose a number of false concepts including the idea that S/4HANA has a simplified data model, that Fiori is complete, that there has been a reimagined business model and business process. Further, that SAP will never have any latency, and that everything will run so smoothly on HANA.
  • In other words, just a typical explanation from SAP.

SAP HANA Introduction

SAP HANA is SAP’s database which combines a columnar database with very fast hardware.

There has been quite a bit of marketing information written on S/4HANA or HANA ERP. S/4 is the ERP system then runs on the HANA infrastructure in the most recent release. The “S” is supposed to stand for simple, and the “4” being what would follow “3” as in R/3. The overall naming convention is strange and confusing all by itself. When the finance area is referred to it is “S/4HANA Simple Finance,” and when the supply chain area is referred to its “S/4 Simple Logistics.” There is no way I can see the world “simple” being continually used on projects, so these names are going to have to change at some point. HANA is the infrastructure/database, and I am not aware of any application having the database name as part of its name, so at some point, S/4HANA will probably be renamed to something without HANA in the overall name.

S/4HANA or HANA ERP is the first major upgrade to what was R/3. It would take a lot of time to explain all the changes, but this article won’t focus on that. Instead, I will concentrate on making sense of the statements made about S/4HANA or HANA ERP by SAP. This should of significant value to people because the messaging on S/4HANA is confusing.

In this article we will cover some of the common claims made by SAP about S/4HANA.

The Language of Selling

What should be understood is that S/4HANA marketing documents are not necessarily designed to be true, but to sell S/4HANA. That is why much of the S/4HANA material often seems strange to an experienced implementer. There was never anything that was ERP in 2004. R/2 was a green screen system. R/3 was a client-server system, which had a Windows user interface. R/3 has been renamed over the years to ECC and then to SAP ERP (which never took) and then to Business All in One, but none of these names meant anything regarding referring to something new in the application, they were just marketing terminological changes.  R/3 has stabilized some years ago, which means that it has seen little in functionality enhancement since that time.

SAP proposes that S/4HANA has the following benefits:

  1. Simplified Data Model
  2. Completely Fiori
  3. Guided Configuration
  4. Reimagined Business Models
  5. Reimagined Business Processes
  6. No More Batch — All Processes in Real Time
  7. Reimagined Business Decisions

Claim 1: Simplified Data Model?

I moved this response over to a separate article titled Does S/4HANA have a Simplified Data Model?

Claim 2: Completely Fiori?

Fiori is the new SAP user interface. However, SAP S/4HANA has a tremendous number of screens, and there is no way that SAP is finished with all of these screens at this time. Therefore, a large number of screens cannot yet be Fiori.

Claim 3: Guided Configuration?

I can’t tell you how many times I have heard about guided configuration. It should be remembered the IMG, which ships with the previous ERP version of SAP ERP was supposed to be guided setup as well, but it never was. S/4HANA may have a few helpful screens, but it won’t be guided configuration.

Claim 4: Reimagined Business Models?

S/4HANA brings ECC to HANA. It is a monumental task to do that simply. It’s very likely that business models will be “reimagined,” instead what companies should look for is if S/4HANA can be made to work.

Claim 5: Reimagined Business Processes?

Same thing, SAP is not offering new application functionality in S/4HANA. ERP on HANA is about an infrastructure and user interface upgrade. The business functionality is roughly the same as in ECC.

Claim 6: No More Batch — All Processes in Real Time?

S/4HANA is an ERP system, and that means it’s a transaction processing system. There are some processing that is performed in batch, such as MRP and closing the quarter for financial reconciliation, but this is a very simple type of processing. Most transactions in ERP are already processed immediately or in real-time.

Claim 7: Reimagined Business Decisions?

Hmmm…this one seems to propose massive differences on reporting for ERP on HANA. Clearly, S/4HANA will be much faster, however, the idea reporting would be so much better also depends upon the reporting application. HANA has several tools, such as HANA Live Browser, but this is not S/4HANA, and all of these tools are too new and unproven to make big statements about.

SAP shows slides with reducing in the time for processing. However, it overestimates the time that the transaction processing system takes. Yes, ERP on HANA will be better, but companies currently don’t have a real problem with closing. It’s a nice to have, but SAP is overemphasizing the benefits here.

Again this focuses on the two most processing-intensive processing within ERP which is financial closing, reporting, and MRP.

I had to say that having written books on MRP and tested MRP in many systems if an in-memory computing is being justified to run MRP faster, there is something wrong with that story. It may be that many people do not know that MRP is very simple and was designed to run on hardware from the 1970s. I quote from my book Repairing Your MRP System:

“Even though MRP is mathematically simple, it performs a number of repetitive calculations that prior to MRP had to be calculated manually, which was a very tedious task. Converting large volumes of sales orders into production orders and purchase orders was quite a feat when this capability was first developed independently in the early 1960’s at J. I. CASE and Stanley Tools. Yet quite a few companies continued using their old systems before industry converted over to MRP in the late 1970’s.”

Claim 8: TM and Ariba Run on HANA?

SAP implies in slides that TM and Ariba run on HANA. Yet, neither SAP TM nor Ariba runs on HANA. I can’t tell if that slide is trying to say that, or that S/4 just can integrate to other SAP applications. However, that is not a feature of S/4 as the same was true of ECC/Business All In One.

I assume that SAP would agree that it offered an integration solution before S/4 showed up on the scene. I will have a future article on what this means from the integration perspective. However, all new tables say all new mapping for the interfaces that do exist.

The slide also includes all the trendy terms, like Internet of Things and Big Data — and one I had never heard of before, called Omni-Channel. Omni-Channel simply means to offer a sales experience across multiple retail channels — such as online, offline, etc.. This has nothing to do with SAP as SAP has no product that does this — and these three things just tell the executive that “we do the new sexy.” It’s a subliminal messaging that “we get it.”

A big message about S/4HANA or ERP on HANA has been getting lean. So SAP has a few good slides on this that explain how this works. The first slide shows database aggregates and indices in the database.

Claim 9: Reducing the DB Footprint?

SAP has proposed that one of the benefits of columnar databases is that they require less aggregation and indices. The blue are the aggregates and indices that are still necessary with ERP on HANA.

This shows how SAP was able to shrink the size of the data that S/4HANA or ERP on HANA takes up. However, it also needs to be stressed that you will pay a lot more per GB when using anything on HANA, so these changes won’t translate to cost savings.

Claim 10: Data to Flow Through HANA Outside of ERP?

SAP proposes that data will now be pulled through HANA ERP and to areas outside of HANA ERP.

Why is this true? This is one of the most bizarre claims that I have seen from SAP. Is information currently pushed in R/3/ECC? But not in HANA ERP. This is the first time I have heard of this. If anyone has a perspective on this that may support some validity, please comment on this article.

Claim 11: S/4HANA in the Cloud Little Used?

There is a lot of talk about all the options available for S/4HANA or HANA ERP. However, S/4HANA in the cloud is quite expensive. And being able to put an ERP system in the cloud, or any other application for that matter should not be considered a big deal.

I happen to find most of the SAP’s material on the cloud more confusing than anything, and I have spent so much time on sales proposals where the topic of either on-premise or cloud is discussed, and it always seems to break toward on-premise. Also, except for purchased applications like SuccessFactors or Ariba, most of the SAP investments are still being sold on-premise.


Statements about HANA ERP have to analyzed because a lot of the information in these types of sales slides is fanciful. It is easy just to view a slide and let it pass you by, and I think I tended to do this for a while on S/4HANA and HANA. It’s another thing to evaluate if what is written makes sense. I have worked on HANA ERP sales pursuits, and I don’t like using these types of slides because they create expectations that are too high.

Curious about the reality of S/4HANA implementations? See our The S/4HANA Implementation Study, for real story and details on actual S/4HANA implementations.

HANA & S/4HANA Question Box

  • Have Questions About S/4HANA & HANA?

    It is difficult for most companies to make improvements in S/4HANA and HANA without outside advice. And it is close to impossible to get honest S/4HANA and HANA advice from large consulting companies. We offer remote unbiased multi-dimension S/4HANA and HANA support.

    Just fill out the form below and we'll be in touch.

HANA & S/4HANA Question Box

  • Have Questions About S/4HANA & HANA?

    It is difficult for most companies to make improvements in S/4HANA and HANA without outside advice. And it is close to impossible to get honest S/4HANA and HANA advice from large consulting companies. We offer remote unbiased multi-dimension S/4HANA and HANA support.

    Just fill out the form below and we'll be in touch.


I cover MRP in the following book.

MRP Repair Book


MRP System

Repairing your MRP System

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

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