- Should SAP’s Claims About HANA Not be Verified Because Most People Don’t Care About Database Performance?
- How SAP Uses HANA’s Performance Claims to Push for Customers to Switch Databases
- SAP’s HANA Claims Fact-Checked
In a recent article titled SAP HANA as a Mismatch for ERP and S/4HANA.
We received a response that seemed to minimize the importance of our verification of the claims made by SAP about HANA because. as the commenter put it..
“…no one cares about the db outside of a very small tech bubble – it’s all about people and process.”
This statement seems to be an attempt to pivot away from the question of whether SAP’s claims regarding SAP are true.
How SAP Uses HANA’s Performance Claims to Push for Customers to Switch Databases
SAP has very aggressively promoting customers to move to HANA under the logic that the database is incredibly important.
Here are a few examples.
- Restricting S/4HANA to HANA has been justified on the basis that no other database can offer acceptable performance versus HANA. SAP has stated that they need to design or optimize S/4HANA around a single database for performance reasons. According to Jon Appleby, who is a proxy for SAP, due to HANA’s capabilities in innovation and unparalleled performance advantage over all other databases that SAP is finished Oracle DB as is covered in the article Why Jon Appleby Was So Wrong In His HANA Predictions.
- SAP is proposing, and SAP consulting companies are relaying the message word for word (I have many of the emails that are forwarded to me from the recipients of this advice) that solutions ranging from TPM to CRM need to have HANA or the applications will not properly support the application’s functionality.
This is suspicious. It is dubious because other vendors that I track do restrict the database options of their customers in this way.
SAP’s HANA Claims Fact-Checked
Secondly, SAP’s performance claims for HANA are not only not holding up, every data point we obtain works in the opposite direction from SAP’s claims. One performance claim for HANA is true.
HANA will outperform a non-column data store database for analytics (but only within a data warehouse environment).
For all other database processing, the performance is worse. That is a serious issue that I am not sure how any pivot or alteration of the point of discussion can change what are now quite a few observations of this fact. We are not tracking performance issues with S/4HANA on multiple accounts. These observations tell a story of S/4HANA’s performance negatively impacting the project.
SAP is using the argument of HANA’s performance combined with what appear to me to be faux arguments about application compatibility between SAP’s applications and to their database to push existing databases out of SAP account. If you have read the Brightwork Study into HANA’s TCO, you might imagine that there are most likely severe implications for the customer’s IT budget to following this advice.
As this is a primary strategy of SAP, it would seem to be reasonable to validate if SAP’s statements about HANA’s performance are true. Therefore, we consider it highly relevant as to whether SAP’s claims regarding HANA’s performance are true.
The topic of the compatibility argument that increasing numbers of SAP’s applications are proposed by SAP and by SAP’s consulting partners to only be supported by HANA is another topic.
Search Our Other HANA Content
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.
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