Why HANA Has Problems with Transaction Processing

Executive Summary

  • HANA has performance problems when supporting transaction processing applications like S/4HANA.
  • We cover one possible reason for this.


SAP proposed that HANA is optimal for processing either OLAP or OLTP. And SAP had a specific design which SAP claimed allowed for this to happen.

This is explained by the following quotation from Rolf Paulsen.

HANA’s Design with Respect to Column Oriented Tables

The common quotation.

HANA combines OLTP and OLAP capabilities, with row store and columnar store in the same box” –

..is misleading at least because it suggests row store belongs to OLTP and columnar store to OLAP in HANA. Unlike products of other vendors, HANA does not provide “hybrid” tables that combine row store and columnar store in parallel. A HANA table is either columnar or row stored but row store tables are the exception for very volatile and fast-changing data. E.g. the size of all row store tables together has a hard limit of 1,945 GB per instance. The sophisticated issue are the transactional operations on the many columnar tables. The price for having data in the columnar form convenient for fast analysis has to be paid on data manipulation. No “row” of a columnar table gets updated, there are only inserts and complex “delta merges” on a short-lived row representation of the columnar data.

How HANA’s Design Has Changed Over Time (and How the Explanation of HANA Has Changed Even More)

It is important to remember that when HANA was first introduced, it was introduced as a 100% column-oriented table database. Obviously, with this design, HANA ran into major problems in transaction processing. This was one of the many indications that SAP did not understand what it was doing when it first designed HANA. Our view is that HANA was overly “boxed in” but the original design objectives of Hasso Plattner. This is explained in the following quotation from John Appleby.

With ERP on HANA, we, of course, don’t need separate row and column stores for transactional and operational reporting data. Plus as Hasso Plattner says, we can use the DR instance for read-only queries for operational reporting.

That is what SAP thought at this time, but then in SPS08, suddenly SAP added rows oriented tables to HANA. Yes, running an entirely column-oriented database for a transaction processing system never made any sense. Appleby himself describes this change in our critique of his article in How Accurate Was John Appleby on HANA SPS08? This article is written in November 2014, and in June of 2014, or seven months later, SAP already had to change its design.

Therefore, what Appleby states here is reversed. HANA’s performance for ERP systems must have been atrocious before they added row oriented stores.

More analysis of this quote can be found in the article John Appleby, Beaten by Chris Eaton in Debate and Required Saving by Hasso Plattner.

Later versions of HANA decreased the percentage of column-oriented tables to roughly 1/3 of the total tables in the database for S/4HANA. 

The Oracle Database Design

Oracle’s design is different, which is covered in part by this quote from Oracle.

“The IM column store encodes data in a columnar format: each column is a separate structure. The columns are stored contiguously, which optimizes them for analytic queries. The database buffer cache can modify objects that are also populated in the IM column store. However, the buffer cache stores data in the traditional row format. Data blocks store the rows contiguously, optimizing them for transactions.”

The Issue in the Interaction Between Transaction Processing and Columnar Tables

This quote on Rolf’s part is compelling.

“The sophisticated issue is the transactional operations on the many columnar tables.

The price for having data in the columnar form convenient for fast analysis has to be paid on data manipulation.

No “row” of a columnar table gets updated, there are only inserts and complex “delta merges” on a short-lived row representation of the columnar data.”

The CPU Consumption Issues of HANA

If we can restate this, the following can be said about Rolf Paulsen’s quotation.

  • Rolf proposes that the columnar tables are updated by a transaction (let us say HANA is supporting a transaction processing system rather than BW).
  • Therefore this update is problematic from transactions being processed to the database.

Results from the Field

Results from the field indicate HANA still has problems with both transactions and running CPU intensive processes like MRP/DRP, as we covered in the article HANA as a Mismatch for S/4HANA and ERP.

The CPU issue is clearly because of the overload of data into memory, causes significant CPU consumption, often requiring a HANA reboot, as we covered in the article How to Understand HANA’s High CPU Consumption. However, the continued transaction processing performance issues could be in part related to the exact problem you bring up here in Rolf’s quote above.

Removing Duplicate Data by Porting an Analytics Database Design to the Non-Analytics Application?

John Appleby and others repeatedly proposed that HANA would eliminate duplicate data (that is the data that is redundant between the ERP system and the data warehouse). Analysis of this claim performed in this article How Accurate Was John Appleby on HANA Replacing BW? 

But the “solution” meant turning the ERP system database into something like the database for a data warehouse (if one does not want to use star schemas). The row-oriented databases supported data warehouses quite well but used an intermediary structure called the star schema. As a point of comparison, Brightwork Research & Analysis uses an application that creates star schemas in the background without the user seeing anything, and easily beats the performance of SAP BW. SAP BW requires the configuration of star schemas when BW sits on top of a row-oriented DB. That is, creating star schemas does not need to be as rigorous as it is in SAP’s BW. It can be made to create the schemas in the background from just loading a flat-file, which contains the relationships (as one example). 

How SAP Has Been Hiding HANA’s Transaction Processing Performance

John Appleby stated that SAP no longer would use the SD benchmark as we covered in the article The Hidden Issue with the SD HANA Benchmark. This is because it no longer fit with how companies used SD (that is, the sales and distribution module of ECC, a transaction processing system). And, even in 2019, there is still no SD benchmark for HANA published by SAP. Instead, SAP created an analytics benchmark called the BW-EML, which we covered in The Four Hidden Issues with SAP’s BW-EML Benchmark.

All of this is strongly indicative that the SAP has run the SD benchmark internally, but choose not to publish the baseline because the performance would match what has been reported to us from the field, that HANA simply performs poorly for transaction processing. However, this never stopped SAP from claiming HANA had far better performance than any other database, including Bill McDermott’s claim that HANA performed 100,000x faster than any other database. SAP needs its customers to replace their current database with HANA to meet their revenue objectives and to increase account control further. Once HANA is installed, SAP will apply indirect access rules to HANA, which will include requiring second HANA instances and licenses to copy any data out of HANA, as we covered in the article The HANA Police and Indirect Access Charges.

Advice on Enjoying the Quiz

To see the full screen just select the lower right-hand corner and expand. Trust us, expanding makes the experience a whole lot more fun.



As far as adding columnar capabilities to a row-oriented database, all of the primary database vendors were able to do the same thing. Sybase IQ was around for at least 15 years before HANA and had a similar design to HANA, but it was just never prevalent.

Oracle, IBM, SQL Server all added column stores to their databases after SAP did (and all of these vendors had superior knowledge of memory optimization versus SAP).

But it is not a question of if one can, its a matter of “why would you?” SAP essentially proposed that an analytics database is a fantastic database for a transaction processing system — and that furthermore, they were the only one to figure this out.

Financial Disclosure

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.

What We Do and Research Access

Using the Diagram

Hover over each bullet or plus sign to see more explanation. To move to a different bullet point, just “hover off” and then hover over the new bullet.


Research Access

  • Do You Need to Access Research in this Area?

    Put our independent analysis to work for you to improve your spend.



TCO Book



Enterprise Software TCO: Calculating and Using Total Cost of Ownership for Decision Making

Getting to the Detail of TCO

One aspect of making a software purchasing decision is to compare the Total Cost of Ownership, or TCO, of the applications under consideration: what will the software cost you over its lifespan? But most companies don’t understand what dollar amounts to include in the TCO analysis or where to source these figures, or, if using TCO studies produced by consulting and IT analyst firms, how the TCO amounts were calculated and how to compare TCO across applications.

The Mechanics of TCO

Not only will this book help you appreciate the mechanics of TCO, but you will also gain insight as to the importance of TCO and understand how to strip away the biases and outside influences to make a real TCO comparison between applications.
By reading this book you will:
  • Understand why you need to look at TCO and not just ROI when making your purchasing decision.
  • Discover how an application, which at first glance may seem inexpensive when compared to its competition, could end up being more costly in the long run.
  • Gain an in-depth understanding of the cost, categories to include in an accurate and complete TCO analysis.
  • Learn why ERP systems are not a significant investment, based on their TCO.
  • Find out how to recognize and avoid superficial, incomplete or incorrect TCO analyses that could negatively impact your software purchase decision.
  • Appreciate the importance and cost-effectiveness of a TCO audit.
  • Learn how SCM Focus can provide you with unbiased and well-researched TCO analyses to assist you in your software selection.
  • Chapter 1:  Introduction
  • Chapter 2:  The Basics of TCO
  • Chapter 3:  The State of Enterprise TCO
  • Chapter 4:  ERP: The Multi-Billion Dollar TCO Analysis Failure
  • Chapter 5:  The TCO Method Used by Software Decisions
  • Chapter 6:  Using TCO for Better Decision Making

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 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 the 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 are far more critical, 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 small, it is not possible.

The first reason is that given today’s hardware and software capabilities, unless the model is 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 the full release. Only S4 Finance — previously called SAP Simple Finance — is available for purchase.

So the first question is how is it 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 matter 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.

  1. It is essential because technically, the claim does not make sense.
  2. 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 into SAP. This customer could simply have an external MRP engine to 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 have any interest in verifying information or see themselves as merely 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 is 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 oppose 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 transaction 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?

The 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 that 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 offer.

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. 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 persistent 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 some 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 of 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 the 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?

Advice on Enjoying the Quiz

To see the full screen, just select the lower right-hand corner and expand. Trust us, expanding makes the experience a whole lot more fun.



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

Financial Disclosure

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.

What We Do and Research Access

Using the Diagram

Hover over each bullet or plus sign to see more explanation. To move to a different bullet point, just “hover off” and then hover over the new bullet.


Research Access

  • Do You Need to Access Research in this Area?

    Put our independent analysis to work for you to improve your spend.







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

Executive Summary

  • This is the Consilio S/4HANA, which is part of our research study.
  • We evaluate the accuracy of this case study.


In this article, we will review the accuracy of the article by IT Daily.net, which references information provided by the consulting company CONSILIO IT. CONSILIO IT is an SAP consulting partner, and consulting partners usually 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 delivering 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.

Let’s 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).

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 merely 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 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? 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, its 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 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 only 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 on 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 the slow MRP that we have observed is when the system is not configured correctly.

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 incomprehensible. 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 about the issue of MRP processing speed versus what MRP 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 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 crazy town. This is particularly deceptive because HANA’s memory management is significantly lower performance than the competing offerings. This means that CONSILIO IT knows this entire paragraph is false. Furthermore, no database processes with infinite improvement as more data are 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 rapidly updated. 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 while 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 while 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 proper 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 typically don’t have a problem exploding very complex BOMs. Companies with complex BOMs tend to have fewer overall SKUs, so it manages to balance out.

The later part of the quote goes back to the topic of reacting quickly. However, just because the computer can recompute rapidly does not mean the overall supply chain or the production floor can respond 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 merely 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.

Advice on Enjoying the Quiz

To see the full screen, just select the lower right-hand corner and expand. Trust us, expanding makes the experience a whole lot more fun.



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 incorrect information about HANA performance and then top it off by misunderstanding how supply and production planning work. 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.

Every 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. Nothing in it was true.
  • It is obviously a paid placement, and most of the article is “written” by CONSILIO IT, and then simply released it through IT Daily.net.


Financial Disclosure

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.

What We Do and Research Access

Using the Diagram

Hover over each bullet or plus sign to see more explanation. To move to a different bullet point, just “hover off” and then hover over the new bullet.


Research Access

  • Do You Need to Access Research in this Area?

    Put our independent analysis to work for you to improve your spend.






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?

Executive Summary

  • SAP proposes that ERP and Big Data should reside on the same database.
  • We evaluate the reasonableness of this proposal for using one giant database.


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 recommended 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 suggested, because of the universal Swiss Army Knife aspect of HANA, that SAP customers can stop moving data out of the ERP system (and all systems, but let’s keep to the more simple version of the argument). It can run all reporting on the ERP system. This would break with the way that reporting/analytics has been previously set up, 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 place data from applications where they originate into data cubes. These data cubes can be actual cubes called MOLAP, or emulated cubes called ROLAP. For 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 the 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 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 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 Problems with SAP’s Single Database Proposal

Issue#1: 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 precisely 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 hear 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 reasonably evident that SAP should not have done this, but increasingly it appears 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. They were simply repeating SAP marketing literature 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.

Issue#2: Reversing the Work Done in Data Warehousing

SAP is proposing a radical change in how the analytics/reporting systems are set up. It means reversing course and removing large amounts of investment that companies have already implemented.

Issue#3: 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 inefficient backend where the data cubes are created. Yet, while the expensive hardware, software, and consulting are a certainty concerning implementing HANA, the savings are simply predicted. And in case anyone is curious, SAP’s ability to predict cost savings is not very high.

Issue #4: 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 a costly 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.

Issue#5: 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, minimal. I have reviewed all of SAP’s claims in this area, as have many others, which are not at liberty to write publicly on the topic, and the arguments are deceptive. SAP has created a very expensive database, and there is no way around that fact. SAP created the compression argument to combat the real perception that HANA is so expensive.

Issue# 6: Big Data

The Kaeser Kompressor video pushes the concept into the 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 afford do.

Advice on Enjoying the Quiz

To see the full screen, just select the lower right-hand corner and expand. Trust us, expanding makes the experience a whole lot more fun.



SAP is presenting 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 not all that compelling. Secondly, even if the vision were compelling, there are huge barriers, including SAP’s 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.

Financial Disclosure

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.

What We Do and Research Access

Using the Diagram

Hover over each bullet or plus sign to see more explanation. To move to a different bullet point, just “hover off” and then hover over the new bullet.


Research Access

  • Do You Need to Access Research in this Area?

    Put our independent analysis to work for you to improve your spend.


The Risk Estimation Book

Rethinking 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

How to Get Clear on SAP’s Claims on S/4HANA

Executive Summary

  • SAP makes a large number of false proposals around S/4HANA.
  • In this article, we review these claims for accuracy.

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” is 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 a guided setup as well, but it never was. S/4HANA may have a few helpful screens, but it won’t be a guided configuration.

Claim 4: Reimagined Business Models?

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

Claim 5: Reimagined Business Processes?

The same thing, SAP is not offering new application functionality in S/4HANA. ERP on HANA is about an infrastructure and user interface upgrade while 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. Some processing is performed in batch, such as MRP and closing the quarter for financial reconciliation, but this is a 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 in reporting for ERP on HANA. 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 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 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 the 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 suitable 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 is 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.

How Accurate is SAP’s Page on S/4HANA?

In this article, we will review SAP’s S/4HANA page and check it for accuracy.

Quotes from the SAP’s S/4HANA Page

The Next Generation ERP Suite with Big Data and IoT?

The next-generation ERP business suite

Run a truly live business with SAP S/4HANA, an intelligent ERP suite designed specifically for in-memory computing. SAP S/4HANA is the digital core that connects your enterprise with people, business networks, the internet of things, big data, and more. Take control and run a live business with SAP S/4HANA and experience the power of a digital core.

SAP has been using the term “digital core” for some time now to describe its ERP system. However, it is not clear why. SAP then states that S/4HANA connects your enterprise with people (true), business networks (true), the internet of things (false), big data (false), and more (whatever that might be.

I cover SAP’s IoT solution in the article Why SAP’s Leonardo Seems So Fake. SAP has no Big Data business, and Big Data has nothing to do with ERP systems, SAP or non-SAP. So this part of SAP’s web article is merely false.

What is S/4HANA?

SAP S/4HANA is a real-time enterprise resource management suite for digital business. It is built on our advanced in-memory platform, SAP HANA, and offers a personalized, consumer-grade user experience with SAP Fiori. Deployable in the cloud or on premise, SAP S/4HANA can drive instant value across all lines of business – no matter your industry or business size.

It is unclear what SAP even means at the beginning of this paragraph. It is merely a sales talk.

S/4HANA is built on an advanced in-memory platform. No other vendor offers in memory for ERP systems, but not because they can’t but because it does not make very much sense. And it is very expensive to do so.

SAP offers Fiori, but Fiori is still being developed, and almost no customer uses Fiori, which is covered in the article The Math of Probable S/4HANA and Fiori Usage. No matter what, if a company implements S/4HANA, they will need to use the SAPGUI. This is covered in the article What is Actually in the Fiori Box?

Hmmm….there is no evidence that S/4HANA can drive instant value across all lines of business. S/4HANA has very few live clients. SAP would have no way of even knowing if this sentence regarding value is true.

Immediate, Intelligent, and Integrated ERP?

SAP S/4HANA is the digital core – the nerve center – of your entire business. It consolidates internal and external elements into a single, living structure that goes beyond traditional ERP software. In other words, it connects all of your processes, provides you with live information and insights, and seamlessly integrates your enterprise with the digital world at large.

S/4HANA does not go beyond traditional ERP software. S/4HANA is roughly 93% identical to ECC’s code, (based upon a code analysis).

S/4HANA does what ECC does. It does not provide live information more than ECC. S/4HANA’s reports are faster (because it sits on an analytical database). But it is unclear how much customers will use this capability versus reporting off of the business warehouse.

It is difficult to tell if SAP wrote the last sentence as comedy or is merely trying to see how much they can pull on people, but S/4HANA does not “seamlessly integrate your enterprise with the digital world at large.” Who would even write such a thing? If true, it would mean that S/4HANA is already perfectly integrated with all digital applications that exist. Which rather, obviously, it doesn’t.

Core Finance: Achieve operational excellence and innovation–company-wide

Provide world-class support for local market requirements, languages, and currencies with solutions from SAP. Our scalable and open architecture optimized for in-memory databases can help you simplify and accelerate your financial operations – enabling you to improve performance and focus on growth and innovation.

Yes, S/4HANA has strong support for multiple languages and currencies…as did ECC.

The statement regarding an in-memory database simplifying and accelerating financial operations has been extensively studied by Brightwork and was found to be false. This was covered in An Analysis of the SAP S/4HANA 1610 Information.

Digital World Requirements?

In today’s digital world, organizations need greater flexibility and the ability to execute without limitations. Learn how SAP S/4HANA can help your organization address every opportunity in the digital world.

The world has been digital for some time. Why is SAP focusing on items being digital as of 2016 and 2017? This fixation with the term digital to sell software and consulting services is covered in the article The Problem with Digitial Transformation and Modern IT Projects.

Accelerate your SAP S/4HANA Deployment?

Utilize our industry-leading SAP HANA Enterprise Cloud to shorten your time-to-value and deploy a digital core. Enjoy the full power of SAP HANA in a private, managed cloud environment that is supported by the most knowledgeable resources in the industry – from infrastructure to applications.

No, that is entirely untrue. First SAP HANA Enterprise Cloud is not industry leading. AWS is the widely acknowledged industry leader in cloud hosting. It does not make very much sense to host with SAP. And SAP itself has mostly given up competing directly with AWS as they demonstrated with their multicloud announcement at SAPPHIRE 2017, which is covered in the article How to Best Understand SAP’s Multicloud Announcement.

Furthermore, the most knowledgeable resources on the cloud, PaaS, IaaS, etc., would tend to work at AWS as they have a much more significant business in the cloud than does SAP, and they are the clear industry leaders.

Transition to SAP S/4HANA?

Our Digital Business Services organization and partner ecosystem is committed to your success. They will provide guidance at every stage of your digital transformation, based on your unique business needs and goals, so you can take full advantage of S/4HANA innovations.

That is curious. Almost no SAP consulting partners have any experience with S/4HANA because it is so lightly installed. SAP will indeed provide guidance every stage of the project, but not of the digital transformation because unless the company is moving from a system that is not based on computers, no S/4HANA implementations are a digital transformation.

SAP pulled out all the stops to falsify information for this article.

This SAP article has a Brightwork Accuracy Score of 1 out of 10. There is no score lower than this.

Advice on Enjoying the S/4HANA Quiz

To see the full screen, just select the lower right-hand corner and expand. Trust us, expanding makes the experience a whole lot more fun.



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.

Financial Disclosure

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.

What We Do and Research Access

Using the Diagram

Hover over each bullet or plus sign to see more explanation. To move to a different bullet point, just “hover off” and then hover over the new bullet.


Research Access

  • Do You Need to Access Research in this Area?

    Put our independent analysis to work for you to improve your spend.



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