- Lack of Simplification to HANA
- What It Means
- SAP’s Promised Cost Reductions from HANA
SAP and SAP’s surrogates have pushed the idea that HANA provides simplification of an IT environment. For example, in an article on HANA, John Appleby (an SAP surrogate) made the following statement.
“Most organizations spend a substantial amount on BI projects, and with BW on HANA they will either spend less (fewer full time employees or consultants) or achieve more for the same, in a shorter elapsed time. Our benchmarking suggests that project build times are 20-30% less with BW on HANA, leading to an overall saving of 10-12% or more for capital projects.”
We analyzed SAP’s proposal that HANA’s data model is simplified in the article Does HANA Have a Simplified Data Model?
In this article, we will evaluate this proposal of simplification from another dimension.
Lack of Simplification to HANA
The following quotation is from a reliable and verified source who works in databases.
“On the overall topic of “simplification” from the database layer into application tier point of view currently HANA looks like anything but simplification forcing significant re-mapping of functionality between different, new modules, the deployment of the Universal journal, the 400 page HANA simplification guide, etc etc.”
These are of course the areas of HANA that customers tend to not find out about until after they have either engaged in a HANA POC or implemented HANA.
“In essence SAP have partially switched from the need to develop and regression test over multiple AnyDB choices to sustain the PAM / Client NetWeaver platform choice, to forced client migration of functionality between modules and cloud (SCM is a good example roughly half the function lands in S/4HANA, roughly half in the Cloud based IBP functionality) with multiple version / functional interdependencies.
Also, HANA appliance building block sizes are not very granular.
This to me simply looks switching one set of challenges for another, it’s not really simplification.”
Areas where HANA is actually more complex continually arise the more we have looked into HANA.
First, HANA is still not a mature database. And immaturity by itself causes more complications and less simplicity. SAP is essentially denying and hiding this complexity from customers while proposing that HANA is all about simplification.
SAP has promised simplification that leads to cost savings from HANA. There is really no pathway for this to come true.
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.
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