- SAP HANA has an enormous number of exaggerated articles.
- We cover the accuracy of the proposals contained in these articles.
Introduction to SAP HANA Exaggerations
Recently I spent time analyzing quite a few articles on SAP HANA benefits. What I have noticed that SAP HANA articles tend to have a high “aspirational content” ratio. I think any potential software buyer needs to be concerned with this tendency of SAP HANA articles to take on a playful and exaggerated nature. Once you research to understand what supports these statements, it often turns out to be often be nothing at all.
A large number of these articles seem to propose benefits that are supposed to be uncritically accepted by the reader. In this article, we will cover the exaggeration undertaken by SAP.
Aspiration for SAP HANA Benefits!
For example, one of the common issues that I find is that while the benefits are listed, the costs are not. How costs are addressed is through asserting that SAP HANA reduces TCO. How much seems to depend on the entity proposing. According to SAP, the TCO reduction is “dramatic.” According to Capgemini, the TCO reduction is “huge.”
What are these things based upon?
The only study I could find on this was a SAP commissioned study from Forrester Research back in 2014. In How Accurate Was Forrester’s TCO Study for SAP HANA? I critiqued the Forrester study. Long story short, it is so filled with holes that I believe the study lacks any validity whatsoever. SAP got what they wanted out of Forrester, but no one should consider this seriously.
Interestingly, what is left out of all references to the study is that the cost savings are entirely projected.
A lot of other articles seem to be confused as to distinctions cost and benefits analysis as they commingled ROI with TCO. Sufficient to say, if you cannot keep ROI separate from TCO, then it is difficult to take that author and that article seriously.
How Many Extra Costs to Properly Maintain HANA?
SAP HANA dramatically changes a company’s approach and skills it needs for SAP and has all types of associated extra costs. SAP emphasizes the dramatic changes, but it positions them entirely as cost and effort reduction.
That is incorrect and misleading.
It makes no sense to continually transition so quickly from the costs to the benefits side of the equation. Moreover, now that we are on the subject, the benefits that are attributed to SAP HANA, at least by many authors, are another big problem with the information published on SAP HANA.
Focusing on the Declared SAP HANA Benefits
To illuminate this point, I will provide a list of SAP HANA benefits. This is a direct quotation from an article produced by a senior member of one of the major SAP consulting companies.
After reviewing this list, let us perform a little test to see how many of the items relate to SAP HANA benefits.
“Some focus on the details of the technology. But why should business leaders care? Those who have recognized that in-memory computing allows them to do things differently have realized these benefits:
- Ease of integrating data from multiple sources
- Increased speed to deployment and speed to value
- Flexibility to meet changing business needs
- Enhanced mobile analytics
- The power to turn data into action.”
Now let us go through each item to see if these are true:
Total Integration with S/4HANA?
SuccessFactors, Fieldglass, Concur, Ariba, are not all integrated to S/4HANA. SAP states that they all sit on the same database! That is untrue. However, again, with how SAP treats time when it makes statements, SAP may be saying this will be true 5-10 years from now. If the projections can be unlimited across the timeline, then anything can be said to be true.
Secondly, outside of S/4HANA Finance, S/4HANA does not exist as it is not released. (I have a future article on this as some consulting companies are proposing to clients that version 1511 is a completed product) An ancient Chinese proverb says that “You cannot be integrated into an application which does not exist — grasshopper.”
*One commenter stated that by using a slide from S/4HANA I appeared to confuse S/4HANA with HANA. This slide, while about S/4HANA is also about HANA itself as it proposes that all these applications are integrated on SAP HANA. That is incorrect. It is the exact opposite of what this slide presents in real life.
Integration as One of the SAP HANA Benefits?
“Ease of integrating data from multiple sources.” – SAP
I do not recall in-memory computing being referenced before as improving integration. Readers can check the Wikipedia entry on In-Memory Computing and In-Memory Database, and the word “integration” does not appear a single time. Isn’t that a bit concerning?
This brings up a logical and factual problem that undermines the credibility of so many SAP HANA benefits articles. The items tend to morph the benefits from area to another field. Specifically, this is a major weakness in the articles by Hasso Plattner, who shows a pattern of writing disjointed articles that commingle multiple topics — often in a single sentence. The strategy seems to be to combine so many proposals that they overwhelm the reader into agreeing. Alternatively, as my friend likes to say “it is all about the Big Data now.”
Let the competition between simplistic platitudes begin.
Back to the specific statements. SAP HANA does not provide any extra ease of integrating data from multiple sources as it is not an ETL (extraction, transformation, and load) tool. SAP’s ETL tool is called SAP PI/PO. The background idea here may be that everything will run on one giant SAP HANA instance so data can be moved between the applications. However, we are far away from that state. Moreover, also, why would every application want to sit on the same SAP HANA database? SAP HANA is only optimized for reporting processing. This gets into the question of HANA performance, which does not, as SAP has stated work equally well for either analytics or transaction processing.
Before we make projections reducing ETL, let us acknowledge what is currently proven and what is conjecture. SAP HANA proponents continuously transmute time.
Conveniently Switching Between Doing Now and Doing in the Future
If you want to climb Mount Everest than that is in the future. You cannot logically describe your experiences of climbing a mountain you have never climbed.
- HANA is the database, and the more quickly we can move away from referring to it as a platform, the more we can make progress in understanding what HANA does versus what it does not do.
- We have to decide where we are going to “live mentally” when understanding SAP HANA. If we want to live in the land of marketing hyperbole, then we can call SAP HANA a platform and transmute time and ascribe benefits to SAP HANA which have never been proven. However, unless one works in SAP marketing, it makes little sense to accept any of their proposals without independent verification that they are true.
Is “Faster to Deploy” One of the SAP HANA Benefits?
In most cases, HANA will not provide an…
“increased speed to deployment and to value.” – SAP
First, you cannot be faster to deploy than something that is already installed. HANA is replacing databases that are already deployed. I would very much like to see HANA implemented quicker than an already deployed database.
Do you see a pattern here?
We seem to get back into the topic of time transmutation repeatedly. Luckily the Dr. Strange movie is coming out soon, so I will be able to get on the same page with all the time alterations that are so familiar with HANA proponents.
However, that is just a beginning point, even if we start from two new systems being compared, HANA will take longer to implement because it is more sophisticated and less tested than previous SAP products. Aside from the speed of implementation question, it also means higher risk. Anyone who thinks that new products implement faster than older products with many implementations behind them does not work in software and does not know SAP.
Now, there may be a higher payoff although that is not proven in any of the articles on HANA. However, the risk and project duration should account for the relative newness of HANA.
A Good Idea to Migrate BW to HANA?
The one case where this may not be the case is with a BI/BW implementation. When BW is implemented on top of HANA, it means time saved through less time spent configuring the Data Workbench. However, that is only for a fresh installation. For companies that already configured the data structures, it will mean there is now less of a need for those structures. Moreover, of course, HANA is as pure analytics database design, so it will always work best for analytics applications like BW. However, no other SAP application should be expected to receive this implementation benefit.
So this quotation should be changed to
“May be faster to deploy under some limited circumstances.”
Flexibility to Meet Changing Business Needs one of the SAP HANA Benefits?
“Provide flexibility to meet changing business needs.” – SAP
HANA will not provide flexibility to meet changing business needs unless that changing business need is processing something faster….and something processed faster for analytics. Moreover, secondly, SAP has provided no evidence that HANA performs analytics processing faster than alternatives — as is covered the article What is the Actual Performance of HANA.
It sure seems like I have to keep pointing out this fact to authors on HANA. HANA is a database; it is not application functionality.
- Application functionality is where addressing changing business needs are typically met.
- The database layer is where data from the application is stored.
This issue has arisen from SAP itself when it tells clients that things like HANA will replace APO, which again is like saying Oracle 12C will replace APO or replace CRM. It is both incorrect and confusing to say that a database returns an application.
So let us establish and important feature of the software.
Databases do not replace applications. What SAP meant was that IBP, which is APO’s potential replacement would replace APO, and IBP runs on HANA. However, that is a much different statement.
HANA for Mobility one of the SAP HANA Benefits?
“Enhanced mobile analytics” – SAP
You seriously don’t need HANA for mobile analytics; check what the emphasis point are in mobility from any of the other analytics vendors. They do not emphasize the backend.
It is hard to see why this would be claimed as a benefit for mobile computing. This is because the bottleneck on mobile computing has far more to do with the bandwidth than the database. Also, SAP has in effect no mobility business, and won’t for the foreseeable future. SAP fought that battle and could not compete with low-cost and high-quality iOS development. So is SAP proposing that its database will speed mobility applications that are not SAP?
The uptake on Fiori will have something to with this as Fiori, although not admitted to by SAP, is primarily a mobile application. However, Fiori’s future is unknown at this point. (not good, not bad, just unknown) However, there is no evidence to support the contentions by SAP and their partners that Fiori is the future.
Right now, almost no one uses Fiori. See my articles on Fiori for why this is the case.
Convert Data Into Action as one of the SAP HANA Benefits?
“HANA allows companies to convert data into action.” – SAP
This is true, but it seems like someone’s catchphrase or something to be put on a bumper sticker. So it is not false, it is irrelevant as a differentiator.
Any application converts data into action (or technically the potential for action).
If one thinks about it, data has been translated into action by devices since before computers were invented, as the counting boards (the earliest known counting device) used by the Babylonians also could convert data into action.
One Example of A Correct Statement?
The one example from the list of something that sort of can be considered to apply to HANA can also apply to counting boards…and that cannot be a good thing.
These types of articles/promotional material on HANA are all too familiar. The information in them is completely unreliable. They are designed to get prospects bubbly and to reach out to them. This misinform the reader and give the reader nothing in return for their attention. They are published by Accenture/IBM/Capgemini/Infosys…(fill in the blank) all of whom have shown a willingness to make any statement that they think will increase their revenues. None of them have any independence from SAP.
Believing them increases the risk of software implementation.
What is possibly most interesting is that many of the supposed improvements that are listed in these types of articles are not improvements that can be traced back to HANA.
Financial Bias Disclosure
This article and no other article on the Brightwork website is paid for by a software vendor, including Oracle and SAP. Brightwork does offer competitive intelligence work to vendors as part of its business, but no published research or articles are written with any financial consideration. As part of Brightwork’s commitment to publishing independent, unbiased research, the company’s business model is driven by consulting services; no paid media placements are accepted.
I cover how to interpret risk for IT projects in the following book.
The Risk Estimation Book
Better Managing Software Risk
The software implementation is risky business and success is not a certainty. But you can reduce risk with the strategies in this book. Undertaking software selection and implementation without approximating the project’s risk is a poor way to make decisions about either projects or software. But that’s the way many companies do business, even though 50 percent of IT implementations are deemed failures.
Finding What Works and What Doesn’t
In this book, you will review the strategies commonly used by most companies for mitigating software project risk–and learn why these plans don’t work–and then acquire practical and realistic strategies that will help you to maximize success on your software implementation.
Chapter 1: Introduction
Chapter 2: Enterprise Software Risk Management
Chapter 3: The Basics of Enterprise Software Risk Management
Chapter 4: Understanding the Enterprise Software Market
Chapter 5: Software Sell-ability versus Implementability
Chapter 6: Selecting the Right IT Consultant
Chapter 7: How to Use the Reports of Analysts Like Gartner
Chapter 8: How to Interpret Vendor-Provided Information to Reduce Project Risk
Chapter 9: Evaluating Implementation Preparedness
Chapter 10: Using TCO for Decision Making
Chapter 11: The Software Decisions’ Risk Component Model