How to Properly Evaluate the Proposed Benefits of SAP HANA

Executive Summary

  • HANA is normally discussed by those that promote HANA.
  • Why it is important to separate the generalized statements from the specific improvements.

Which Way on HANA


As anyone who works in SAP knows, HANA has been the largest SAP marketing point of emphasis for several years now. However, much of the information comes from a one-dimensional perspective, one that is more promotional in nature than focused on enhancing the understanding of how and when HANA is appropriate to be deployed. This article is intended to help readers apply a framework for asking the right questions about HANA.

Item #1: Working Out HANA’s Expense

HANA is a solution, which is more expensive than other alternatives. There are several reasons for this. First, HANA uses more expensive hardware. Secondly, it is more expensive because of the premium that SAP charges for HANA software. Thirdly it is more expensive because HANA is still being worked out under the covers, and this means more implementation complications than other SAP alternatives that have had more implementations. Fourthly, in cases where HANA is implemented for an already live system, it means making a change and changes cost money. Something which I have yet to see elaborated upon in print is something that I think is quite obvious and that is that anyone can gain more performance by increasing the input or investment into a domain, but it is important to mention that the input/investment is different when making statements regarding improvement. As an example, I can say that a Maserati performs better than a Honda.

However, if I leave the price out of the equation, then it’s not really a fair comparison. Too many articles and conference presentations give little attention to costs and instead are entirely focused on explaining the benefits of HANA. One recent article that I read showed the cost savings that come from HANA from the improved capabilities that a company would obtain, but nowhere in the article were costs discussed. It almost appeared as if HANA along with its implementation were simply free.

Item #2: Different Benefits Per Application

There is no doubt that business intelligence applications benefit greatly from HANA. And this means that more implementations have occurred for SAP BI than for other SAP applications, and using HANA for SAP BI is much easier because of how business intelligence applications work versus transaction processing applications like SAP’s ERP system, makes the effort involved in migrating to HANA far easier. Secondly, the benefits differ per the type of application.

Item #3: Part of HANA’s Benefit is Simply Buying Faster Hardware

Part of the benefits that SAP is isolating to HANA is a natural transition to simpler data structures that are now feasible due to improvements and cost reductions in random access memory and solid state memory. SAP decided to make HANA their central marketing pillar by focusing on this change –, replacing the previous marketing platform of “NetWeaver.” However, we can learn quite a bit by analyzing the history of technological improvements in information technology. The servers that are presently being purchased for business intelligence applications may have 500 gigabytes of RAM in addition to multi-terabytes of solid-state storage along with the traditional hard storage. However, even servers with these types of specifications are not particularly expensive anymore. With this type of capacity, it makes less sense to place data into cube structures to enhance query performance. Whenever hardware makes a great leap forward, it takes time for the software to unwind the complexity that was built into it in order to accommodate the previous generation of hardware. So companies that no longer need the cube structures they have built will continue to use them – simply because it takes more time to pull the data out of cubes that they have already built and place them into simpler structures. Hardware can change a lot faster than software.

HANA does not Mean Benefits to All Application Elements

As a person that works both the sales side and the implementation side, I have reservations about how HANA is described as improving every facet of SAP’s applications. For salespeople, it is generally desirable to be able to make these statements, but it sets up implementation problems because implementation must manage highly-generalized expectations for improvements in too many areas. While it may be considered visionary to generalize the benefits of HANA, applications are a series of moving parts that each has their own heritage, current state of development and impact on the function of the application. HANA is an infrastructure element, a good analogy being the suspension of a car. To take this analogy further, most people would intuitively understand that improving the suspension of a car does not improve every other element of the car’s performance. Quite obviously, it does not make the engine more powerful or improve the radio or the visibility from the driver’s seat. Some other areas may improve – for instance, a better suspension can have a positive effect on the steering/controllability of the car, but the specific improvement to other elements should be explained in terms of the cause and effect and not simply assumed. However, statements regarding HANA’s speed improvement are quite frequently generalized to improve all other areas of the application without any specific explanation as to why this is the case. In the same way, HANA has no impact on the business logic of SAP, or its user interface. HANA puts infrastructure at the center of the conversation, but the infrastructure cannot continually be the center of the conversation, because it is only one piece of the puzzle.


In order to get value from HANA it is necessary for companies to move past the generalities that are often applied to HANA to the specifics. The specifics include the price of HANA for each area that it is applied. Not all applications are going to be moved to HANA, certainly not in the next few years. So which applications should, and what is the cost-benefit analysis for doing this, is an important question to ask. For most companies, the first place to implement HANA will be in their analytics.

Secondly, statements that generalize the benefits of HANA to every aspect of the application should be disregarded and emphasis given to statements that show specifically both how and why HANA will improve specific areas of the application, which should then be estimated in terms of business benefits. Being able to improve query performance by a factor of 1000 sounds great, but it may not be the primary problem that company has, and other shortcomings, such as the configuration of the system or the understanding of the functionality within the application may be far more pressing concerns. Technology improvements are much easier to estimate that business improvements. But technological improvements do not necessarily lead to proportional business improvements. As an example, increasing the horsepower of a car from 150 horsepower to 300 horsepower has little effect on the average speed that car is driven, because other constraints – ranging from speed limits to traffic, to physical laws regarding how a car can be driven without crashing into something still exist after the engine has been replaced. By purchasing HANA and investing more resources, queries can no doubt be performed more quickly, however, there are many things that an implementing company wants to improve, and this is only one area of focus. Investments in HANA must be traded off against other investments that improve other areas of the technology landscape that are also important. This logic applies not only to HANA but to any improvement that a company would make to its systems.

Search Our Other HANA Content

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.

HANA & S/4HANA Research Contact

  • Interested in Research on S/4HANA & HANA?

    It is difficult for most companies to make improvements in S/4HANA and HANA without outside advice. And it is not possible 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.


How Accurate Was John Appleby on What In-Memory Database for SAP BW?

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