Why Does S/4HANA Need B/4HANA for Analytics?

Executive Summary

  • For years SAP proposed that applications on HANA would remove the need for a data warehouse.
  • Now the message is changing, and B/4HANA is back in the mix.


The original presentation of S/4HANA was that because of HANA, and the reporting schemas would no longer be necessary. The elimination of the data warehouse would be possible because S/4HANA would report directly off of the column-oriented tables, which were optimized for reporting.

Part of the point of S/4HANA was to minimize the use of the need for the data warehouse. The idea went, that if all SAP applications used HANA, and a company used all SAP applications than they would no longer need a data warehouse. SAP described this as using embedded analytics, which we covered in the article What is the Value and Future of SAP Embedded Analytics?. This vision, of course, left out entirely the reports that go across applications, which of course still required a central repository, which shall we call a “data warehouse.” We quote from the following to illustrate how on SAP consulting company explains this obvious fact.

“To achieve this, you need a system that can collect, merge and harmonize data from various sources. A single S/4 system cannot achieve this. SAP does not recommend using embedded analytics to consolidate data from multiple systems, and it is meant for operational reporting only. Even though the S/4 system comes with an embedded BW system, it is not designed to be used as your enterprise data warehouse.”

And illustrated in this slide.

And this quote from SAP.

“Most of us would have for sure thought for once that Embedded BW on S4HANA would replace BW as whole and would not need BW in future. Which is kind of myth looking at the basic nature and capabilities of the EDW(Enterprise Data Warehouse). Its correct the Embedded BW can be used to support certain business processes on SAP Business Suite and S4HANA like BPC optimized. However, there are many other reasons why we can’t use Embedded BW for all the EDW needs. Based on many documents and notes following are the major reasons for which it becomes obvious to use SAP BW4HANA”

Again, who created this “myth?” Lets not be coy about this. SAP proposed this myth.

Over a span of several years, I don’t recall telling people that HANA would lead to the elimination of the data warehouse. Quite the opposite, and those people telling me that I need to get with the “brave new world of analytics” within each application were SAP consultants. Even in private, with no one listening, the adherence to SAP talking points by SAP consultants never ceases to amaze me. 

Who Thought This Illogical Approach Would Work and Evangelized The Design?

Normally the less technical the resource, the more they thought this would happen, with salespeople who had never personally worked with databases or analytics software being the most vociferous that this was the future that HANA allowed. They topped this off by proposing that only SAP had the vision to make this happen. This following quotation is verbatim.

“Hasso Plattner always hated analytics systems. He saw them as a failure of the application to provide the reporting. His vision is to eliminate the data warehouse, and HANA is how he will do it.”

SAP Analytics Products are All Jumbled In

Another undiscussed issue is how many products are now part of this solution. Let us review a slide.

This slide is already a bit out of date as Lumira has been discontinued, and Cloud for Analytics is the replacement product. But let us review all of the products that are part of this design.

  1. SAP Cloud for Analytics
  2. SAP Business Objects
  3. SAP Lumira

How much are all of those licenses going to add up to? Is this us or does this appear like a confusing combination of items?

The New Reality of S/4HANA and the Data Warehouse

Years after SAP presented this vision, and they are now changing their story regarding data warehousing. SAP is now proposing that customers use something called embedded BW which is the junior version or BW/4HANA which is the more advanced version that is merely the rebranded stand along BW but which of course only runs on HANA and pushes out other database vendors from the mix. Embedded BW is implemented within S/4HANA and according to SAP is for “strategic analysis” rather than the standardly embedded analytics that are for more or less canned analytics.

We have been saying for some time that the embedded analytics in S/4HANA are simply for canned analytics. Because they are canned, they don’t even leverage HANA as they can be pre-compiled, with only net change information updated.

One of the reasons its very easy to overestimate the number of apps, or tiles of functionality included in S/4HANA is because so many of the tiles are really just reports, as the slide above illustrates. Once in the transaction/report, there is normally not much that one can do other than some basic searching or filtering. 


It is understood that more analytics than the canned “embedded analytics” are required for non-standard reporting, but why did SAP port an obsolete product like BW to S/4HANA? One of the main points of HANA was that a heavy overhead BI environment with their very heavy maintenance overheads like the SAP BW was supposed to be no longer necessary.

Column-Oriented Tables: A Simplified Data Model

Recall the simplified data model? We covered the topic in the article, and contradicted the notion that S/4HANA had a simplified data model in the article Does S/4HANA Have a Simplified Data Model?

However, while the data model is no simpler, it is, that is column-oriented tables, are certainly more optimized for read access or that is for reporting and analytics. The idea that was presented by SAP was that a simpler lighter BI environment, for instance like Lumira (now discontinued), or SAP Analytics Cloud (not yet ready to be implemented) or a mature visualization product like Tableau or Qlik was supposed to be able to be used. So far the number of application of HANA has been for the BW, which speeds BW, but does little to reduce the lengthy reporting queues sitting behind most BW implementations globally.

Continuing to Work Off of Data Cubes?

Something else odd was that there are graphics that show both embedded BW and B/4HANA using data cubes. They also work off of Core Data Services that feed the data cubes which we covered in the article How to Understand HANA Lock in with Core Data Services.

Again why are either of these products using data cubes? Data cubes are actually not cubes, they are star schemas which are designed to speed row oriented tables. The point of using columnar tables is so that they can read accessed very quickly without any intermediate object such as a star schema.

SAP Backtracks on the Design Proposals of HANA

The story around SAP analytics keeps getting weirder and more complicated, and it contradicts what were supposed to be the original benefits of HANA.

With new articles coming from compliant SAP consulting companies, we have the explanation that companies still need a data warehouse, which means that SAP’s vision of entirely embedded analytics has failed. Alternatively, should we say, what SAP stated about doing away with the data warehouse because of the embedded analytics will never come true? We knew it would never come true, as it never made any sense. We told many SAP consultants this in discussions, but they overrode the concerns and told us this all made sense at SAP. Five or six years after the fact, SAP is finally changing its messaging (although not admitting it is changing its messaging).

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.

S/4HANA Implementation Research

We offer the most accurate and detailed research into S/4HANA and its implementation history. It is information not available anywhere else and is critical correctly interpreting S/4HANA, as well as moderating against massive amounts of inaccurate information pushed by SAP and their financially biased consulting ecosystem.

Select the description that best matches you.

Option #1: Do You Work in Sales for a Vendor?

See this link for an explanation to sales teams.

Option #2: Do You Work for an Investment Entity that Covers SAP?

See this link for an explanation for investment entities. 

Option #3: Are You a Buyer Evaluating S/4HANA?

For companies evaluating S/4HANA for purchase. See this link for an explanation to software buyers

Search Our Other S/4HANA Content






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