- SAP has relentless promoted HANA, but HANA has not actually paid off it is more of a liability for both customers and eventually for SAP.
- We cover how SAP markets HANA versus how competitors market both applications and databases.
Introduction to SAP’s Investment in HANA
SAP has made a tremendous investment into marketing HANA. At the time it the strategy was originated, it was thought to become a stunning success those Hasso Plattner and by those loyal to him. You will learn what SAP’s main focus on SAP HANA means for the marketplace and for the messaging that has come from SAP, and how this messaging has been interpreted and reacted to by customers.
A Brief History of SAP HANA
It is acknowledged that the push toward HANA originated by Hasso Plattner, the best known of the original founders of SAP. He has written three books on in-memory computing since 2011.
SAP HANA was accepted as the major marketing tent pole and has been the primary driver of SAP’s marketing and sales messaging at this time. This was a transition for SAP, as the prior tent pole was called Netweaver, which was for all intents and purposes, discarded when SAP HANA arrived on the scene. Four years after the fact it’s almost difficult to remember how dominant Netweaver was in SAP’s marketing message.
The Tent Pole Concept
A tent pole is a term used by movie studios to describe the largest budgeted and highest grossing movies or television programs it produces. It “keeps the tent” or operation up. I have adopted the term here to mean the major marketing theme employed by any software vendor.
In analyzing the marketing tent poles used by SAP going back to the company’s origin, interesting things surface. SAP’s first tent pole was the integration of operations to finance in its ERP system. This was highly effective as it both resonated with customers and it also happened to be true.
What Has Been the Real Customer Buy-In on SAP HANA?
The marketing and sales investment in SAP HANA has been enormous. So what has been the client’s response to the big HANA push?
It ‘s hard to answer this question of SAP HANA’s success and adoption rate from the outside looking in because SAP marketing and those that write about SAP (who want HANA business) create the impression that a lot is happening with SAP HANA. Tracking SAP HANA sales provide an enlarged view because sales do not mean implementation success, and SAP stopped breaking out HANA sales as a separate item a while ago, which apparently reduces the visibility to sales. Some speculate this may have been to obscure SAP HANA’s real growth rate, but they did have a good reason or cover story for doing this. But I have now counted several ways in which SAP is providing a misleading view as to SAP HANA adoption. One way has been to count licenses that were given away to customers, who have no plan for implementing HANA — as “customers.”
From the inside of companies I see as a consultant, the picture looks much different. It turns out that even at this late date, more than four years after SAP HANA has been introduced, there are relatively few SAP HANA implementations.
Reasons Why it is Difficult to Justify HANA
Some of the reasons for this which are often discussed among the more educated SAP sales people that I work with. I won’t go into all of them because that would be another article, but here are three central reasons:
- Price: As HANA is on the upper end regarding costs, and often comes to $1 million in just hardware costs alone (per application), the actual software is at the upper end of SAP’s offerings. HANA consultants are also at the very high end in cost (as well as being difficult to find). I would suggest that anyone investigating HANA’s costs simply take the hourly rate of a large consulting company HANA resource and multiply it by 160 hours per month, and this will build an appreciation for the sticker shock HANA customers face.
- SAP’s Account “Headroom”: If SAP were a small portion of the spend of IT departments it would be one thing, but SAP already has such a sizable part of the IT spend of its customers that up-selling customers from their current position are a major challenge.
- HANA’s Benefits Focus: SAP has developed all types of aspirational material on how to use in-memory computing and they employ very effective solution specialists to present this. However, HANA just does not address the primary pain points that SAP customers have. There is a very apparent misalignment between what SAP is promoting and what SAP customers are focused on.
The Real Issues on SAP Projects
The fact is the biggest problems that the clients face are not the speed of processing of transactions or that business intelligence output does not run quickly enough. I would think anyone who works on SAP projects would know that there are more pressing issues that SAP customers face such as the following:
- Maintaining current systems accurately
- Improving the uptake of the system by users
- Configuring some of the existing functionality that is not working as desired
- Maintaining master data (Which so often leads to SAP systems being used less than optimally.)
Some these items were added to the video I created on the adoption of HANA by customers.
In Defense of SAP HANA
If a person from SAP, or who worked for a SAP consulting partner were to comment on this post, they would most likely say that there is a world of difference when HANA is added to SAP. That I am not “getting it,” perhaps that I lack vision, am a bad person, etc.. However, the issue is not whether I agree with it, as I don’t buy SAP software.
Rather the issue is whether customers agree with SAP on HANA. Up to this point, where SAP and their consulting partners have had more than enough time to present the case, customers have not agreed with SAP that HANA is something that is critical for them.
While some customers have purchased HANA, and most of these purchases are for a single application category; analytics, and un-coincidentally, HANA is primarily an analytics database.
SAP HANA Competitors
SAP spends lots of time discussing the benefits of HANA SAP. However, when the describe HANA SAP, they often tend to make it sound as if their SAP HANA competitors aren’t doing anything with their databases. However, that isn’t true. Let us go to the quotes. The following is from the vendor Anaplan.
“…HANA is an analytics database heavily used on-premise for small sets of users, and, per its name, is not intended for planning (i.e., to allow users to make changes to plans). This leads to performance bottlenecks when modifying plans and viewing resulting calculations. Another side effect of HANA SAP is that horizontal scaling across servers and cores is not supported for planning use cases. No doubt it will take time for the newest of the CPM products to mature and stabilize, especially from a company unfamiliar with the cloud. There is no confirmation that SAP will take on the enormous effort to re-architect for multitenancy, the speed of planning changes, and horizontal scaling.
..SAP Cloud for Planning, has had difficulties addressing large enterprise needs due to insufficient modeling capabilities. Even smaller companies have challenging modeling needs due to their industry-specific revenue modeling requirements, the use of driver based forecasting and “what-if” scenarios, consolidation rules, or their hyper-growth nature. Modeling flexibility is lacking, making room for spreadsheet proliferation.
Only Anaplan can scale for more complex models and large enterprises, three since Anaplan does not use off-the-shelf in-memory computing, but instead has a patented in-memory, Java-based planning engine. In particular, the patented Anaplan Hyperblock™ technology is optimized for planning and not merely analytics, unlike HANA SAP. What’s more, Anaplan’s unparalleled modeling flexibility makes it possible for Anaplan customers to scale horizontally across hardware without compromising speed, in contrast to off-the-shelf frameworks such as Apache Hadoop.”
So as one can see, every vendor has their story. Oracle, IBM and SQL Server have all made improvements to their database. Yet again, SAP discusses them as if only HANA is moving forward, while all others stay still.
Checking With SAP HANA Competitors on HANA SAP
An important principle here is verification. SAP makes exaggerated claims on HANA SAP. But not only do SAP HANA competitors not agree with SAP’s assertions but computer science experts do not agree with SAP on many of its contentions regarding HANA SAP. Also, SAP has published scant benchmarking data versus SAP HANA competitors like Oracle.
How SAP Markets HANA
HANA is one of the SAP’s major marketing tent poles that it has used throughout its existence. I estimate that HANA is the largest marketing initiative ever undertaken by a company in enterprise software. However, any tentpole only has so much of a lifecycle. Either the concept is successful and is eventually adopted by competitors such that it is less of a differentiator, or it wears out its welcome and something else becomes the new emphasis point. To see examples of how differently the competition markets see this article.
It is now common to hear about “HANA fatigue.” For four years just about every SAP conference has been distinctly HANA flavored. One of my clients told me of her experience of at one SAP conference where the HANA pitch was so strong it took on as she described it a “cultish vibe.” That is a signal from the market to be aware of.
SAP can only keep talking about something for so long before either the audience accepts it or rejects it, and it is time to move on. That time is approaching for HANA. This is not to say that SAP won’t continue to improve HANA, reduce its price, and increase its implement-ability, but that it’s probably time for the marketing emphasis to change to a new 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.
SAP presents a one-sided perspective on the cost and risk of applications. I cover both these topics in the following book.
Software Selection Book
Enterprise Software Selection: How to Pinpoint the Perfect Software Solution Using Multiple Information Sources
Mastering Software Selection
Software selection is a form of forecasting, just as any another purchase decision is a forecast of how successfully the purchased item will meet expectations. Forecasting is necessary because it is not feasible to implement each application under consideration before it is purchased to see how it works in the business.
The Importance of Software Selection
What You Can Expect from the Book
Essential reading for success in your next software selection and implementation. Software selection is the most important tasks in a software implementation project, as it is your best (if not only) opportunity to make sure that the right software the software that matches the business requirements is being implemented. Choosing the software that is the best fit clears the way for a successful implementation, yet software selection is often fraught with issues, and many companies do not end up with the best software for their needs. However, the process can be greatly simplified by addressing the information sources that influence software selection.
This book is a how-to guide for improving the software selection process and is formulated around the idea that much like purchasing decisions for consumer products the end user and those with the domain expertise must be included. In addition to providing hints for refining the software selection process, this book delves into the often-overlooked topic of how consulting and IT analyst firms influence the purchasing decision and gives the reader an insider’s understanding of the enterprise software market. By reading this book you will:
- Learn how to apply a scientific approach to the software selection process.
- Interpret vendor-supplied information to your best advantage.
- Understand what motivates a software vendor.
- Learn how the institutional structure and biases of consulting firms affect the advice they give you, and understand how to interpret information from consulting companies correctly.
- Make vendor demos work to your benefit.
- Know the right questions to ask on topics such as integration with existing software, cloud versus on-premise vendors, and client references.
- Differentiate what is important to know about software for improved “implement-ability” versus what the vendor thinks is important for improved “sell-ability.”
- Better manage your software selection projects to ensure smoother implementations.
- Chapter 1: Introduction to Software Selection
- Chapter 2: Understanding the Enterprise Software Market
- Chapter 3: Software Sell-ability versus Implement-ability
- Chapter 4: How to Use Consulting Advice on Software Selection
- Chapter 5: How to Use the Reports of Analyst Firms Like Gartner
- Chapter 6: How to Use Information Provided by Vendors
- Chapter 7: How to Manage the Software Selection Process
- Chapter 8: Conclusion
- Appendix a: How to Use Independent Consultants for Software Selection
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