How to Deflect That You Were Wrong About HANA

Introduction

There is a popular trend afoot in the HANA community that comes from either HANA defenders in SAP or HANA defenders in the SAP partner community. I call this pretending you weren't wrong about HANA. SAP and its partner community have proliferated so much false information about HANA over the past five years. Once called out on it, they need to respond to not be seen as either unknowledgeable or dishonest. There are important principles at work here. Let us take a minute to review them.

• There is HANA software to be sold!
• There are HANA services to be sold!
• It is imperative to be able to continue to mislead customers in an unmolested fashion!

In this article, I will describe the essential tactics that they employ.

First Some Background on HANA

HANA was at some point around 2011 approved as the primary marketing tentpole for SAP. Since 2011 Dr. Hasso Plattner has written four books on HANA related topics. SAP marketing and sales have released a torrent of information about HANA. My research shows that this information has in just about every case been either inaccurate or exaggerated. Dr. Hasso Plattner seems to be a true believer in HANA. Somewhere along the way, he seems to have become obsessed with HANA technology. People at SAP did not stand up to him and tell him he is overemphasizing on one topic (to the detriment of other important topics). I have brought upon many occasions that processing speed is not even among the top ten items that plague SAP projects. And if you work on SAP projects, it is hard to propose the opposite.

Instead of having anyone push back on Hasso, SAP went all in on HANA. The problem is that Hasso is not a reliable source of information on computer topics. I have concluded that Hasso Plattner makes up things about as much as Donald Trump. The major difference is that Hasso Plattner is considerably smarter. And he covers topics that are far more sophisticated than the subjects covered by Donald Trump. Thus his deceptions are much harder to ascertain. But if you study Hasso Plattner's writing and speeches long enough, a pattern of premeditated deception becomes impossible to ignore. The comments he made about a Chinese company that had an MRP run time of 24 hours, which SAP reduced with S4 running on HANA, many months before S4's production planning module had even been developed is symptomatic of provably false statements made by him. (I have a future example of a very long MRP runtime, but alas the conclusion is not purchasing HANA.)

Hasso is much like most of the partners at large consulting companies that I have met. They simply do not care what happens. What they care about is what they can pull over on other people. This is not idle criticism but is based upon quite a few conversations with partners at major consulting companies. What they care about the perception rather than the reality. And they have in fact told me that this is the right way to think.

Follow that Money

As is usually the case the vast majority of money resides on the side of those that make exaggerated claims. The money is squarely on the side of exaggerating expectations, not on telling people the truth. The truth is much less exciting and does not appeal to the desires of the audience. The audience wants to hear that the thing they purchase will have incredible performance. That everyone who uses it loves it, that it is leading edge, has a low TCO, which it will result in being able to cut overhead, etc..

Things have not changed much since the traveling medicine show salesman. Wall Street wants to hear that SAP is all about both driving innovation through HANA as well as delivering more and more applications through the cloud. Therefore, regardless of what is true, the data will be gerrymandered to give this impression. Quotas must be met, and stock options must be exercised. SAP can choose from an unlimited number of type people who will tell any lie SAP wants in any language it wants in return for money.

For this reason, people in conferences and private visits compete with each other to misrepresent reality. And the competition is fierce. Conferences like SAPPHIRE and ASUG are filled with false information. Lies were emanating not only from SAP and their partners but from employees within customers. They compete in giving mis-impressions on how much progress they have made with SAP's newest applications. In interviewing companies that interact with SAP and SAP partners and I observe the information that is provided to these enterprises. I find one misleading statement after another. I should not be surprised. The lying in the documentation is simply repeated in the actual sales process.

There is all manner of problems with this overemphasis on HANA. But one easy item to point out is that the overall performance of the system does not match the database speed of the system. That is just because you can make the database run faster by say 100 points of measurement does not mean that this 100 point translates to 100 points in application performance. And whatever the improvement in application performance does not translate to business value.

Think about a Lamborghini Veneno. This $400,000 car has a 750 horsepower engine.

A Honda sedan may have a 100 horsepower engine. Does the Veneno get you around town 7.5 times faster? Of course not. The reason you can't convince people to sell their house to buy a Veneno is that everyone drives and so he or she can't be tricked into thinking their commute will drop to 2 minutes if they buy a Veneno. But not everyone has years of database experience. Thus it is easier to trick them into thinking that HANA might have such incredible benefits. But if they didn't and I was unethical, I could simply do the math that 750 hp is 7.5 times more than 100. I would then contend that people that have a 15-minute commute could have a 2-minute commute. That is 13 minutes saved each way, which is 26 minutes a day in extra time saved!

Imagine what you could do with that time back.

In Dr. Hasso Plattner's writings, he seems to propose a direct proportional benefit from database speed to a host of other benefits. This has lead SAP to exaggerate the benefits of HANA. And the primary reason for this is to penetrate into the database layer. That is SAP is willing to mislead as many people as necessary to meet the sales quotas on HANA. People that buy HANA often don't see the second act coming.

Here is the second act. SAP has a number of other databases and applications that it wants to sell as a follow-on to HANA. And of course, none of these things will work well with "other databases." HANA is the wedge to all sort of related items it wants to sell you.

All of this fanciful talk about a brave new world with in-memory computing is part of a campaign to tie companies into a closed system. A system that will benefit SAP. I have seen many companies now with HANA on BW. BW is probably the SAP application with the most predicted benefit from HANA. It has not changed things at these companies much at all. In most cases, the business continues to use Excel while the queue of reports that the BW/BI team has to work on continues to grow. This is because new technology was added without asking the fundamental questions about the problems with BW/BI productivity and report usability.

What this means is that software salespeople and those with a sales quota at most IT consulting companies feel perfectly fine in telling a constant stream of lies to customers. Every inaccurate statement is an arrow in their quiver. Even statements that have been proven quite some time ago to be incorrect.

SAP's HANA Claims

The following are good examples of the items that are exaggerated claims by either SAP or SAP partners.

1. No aggregates EVER!!!
2. Extreme OLTP performance as well as extreme OLAP performance
3. Need little RAM as we compress EVERYTHING to very small...
4. A whole new user interfaces in Fiori.
5. HANA will lead to business process simplification when used with S4 because the data model has been simplified.
6. Updates are super fast as we update only one field instead of the whole record
7. Making use of CPU/RAM at the hardware level.

Every one of these proposals by SAP or by those that have some HANA quota to fill is false.

1. HANA still uses aggregates. There are in fact many good reasons for maintaining aggregates. Reference tables are aggregates.
2. SAP is not releasing benchmarks on HANA for OLTP because as per HANA's design these benchmarks are likely to be disappointing. But this does not stop SAP from claiming that HANA is equally effective at OLTP and OLAP (transactions and reports -- excuse me "analytics")
3. SAP's compression estimations are greatly exaggerated and require heavy archival (a cost) and will result in companies having to go back to SAP after the fact to purchase more HANA license GBs.
4. Fiori is not a complete UI for S4. Instead, Fiori is a niche set of apps. A set of apps has yet to be demonstrated to work any better than the parts of SAPGUI they are replacing. And a set of apps that in 98% percent of cases will only work with applications that sit on top of HANA.
5. S4's data models are not simplified. There are more tables than ever with a column-oriented database as many of the columns have become their tables. Indexes are eliminated with column-oriented databases. That is a reduction in complexity. But other areas increase in complexity, including the need to rewrite every single adapter that connected to ECC. Simplification of data models (even if true) does not lead to simplified business processes (which is the SAP claim).
6. SAP never mentions the need to update 20 fields in one record; we end up with 20 updates instead of one update on row-based databases.
7. The CPU and the RAM are the hardware level. You cannot benefit from using something at a level if it is already used at that level. This would be like saying "you will be able to use the steering wheel at the automobile level." There is no another way to interpret this except it is a purposely redundant statement that is supposed to sound technical and esoteric. It is designed to impress people who don't know how software works.

If you sell nonsense for a living, you are not going to stop just because I call you out on it. You need to obscure the issue so you can keep selling nonsense. From financial advising to medicine to IT consulting and strategy consulting, nonsense is a great thing to sell. It is great for your career and your pocketbook. It is just about impossible to meet a quota without it.

 Saving that Face

Face-saving. As I learned when I worked in Asia, face-saving is big in Asian culture. And the term was used a lot when I worked there. But while I don't support mean-spiritedness, people that make big claims that turn out to be the false need to own up to it and be exposed for being wrong. If not we would not have science. We would be more concerned about embarrassing people who were wrong and never make progress. So to protect Stan's face, we would continue to agree that the moon is made of green cheese.

This is presently a big problem in IT and IT forecasting. I like to say that the only thing anyone is held accountable for regarding prediction is meeting their sales quota. Gartner has quite poor accuracy in their forecasts.

• They were responsible for priming the ERP bubble in the eighties.
• The marketplace bubble in the late nineties.
• They are currently pumping up the Big Data and analytics bubble as well as the IoT bubble.

But do you see Gartner paying a financial penalty for being the Helen Keller of IT forecasting? No, they are richer, more powerful and more influential than ever.

Unfortunately, there is no entity that calls out individuals or companies that knowingly distribute false information on IT topics. And this has lead to a bubble in buffoonery.

Diverting Attention from Previous False Statements

I have spent a good deal of time investigating the performance claims and many other claims on HANA. Here is what I have found.

• The uniqueness of HANA's performance has been explained in my previous articles as completely manufactured by SAP. There was never any truth to it. The people that proposed this are diminished in my eyes for the lies that they told. At the tip of the lying spear is Dr. Hasso Plattner, but there are plenty of other culprits.
• SAP has proposed that end of period close, and MRP use is held back by not having a database like HANA. This is false as neither process is a bottleneck at the vast majority of companies. If as a company you have a system processing constraint with either of these processes, you are in the distinct minority. Instead of moving to HANA, you should try to find lower cost ways of figuring out what the problem is. As soon as a person raises either of these issues I know that one of two things must be true. Either they know its incorrect but are willingly stating that these things are the case. Or secondly, and perhaps what can be more forgiven, they are simply repeating what the read in some SAP marketing material. Let us discuss reasonable expectations. One should not expect account managers or partners who have never touched SAP in 10 years or been on an SAP project to be reliable sources of information on technology topics.

Recently SAP proposed that even backflushing is performed because of a lack of database speed. And that HANA was going to come to the rescue to all these poor companies that have had to perform backflushing because their ECC systems cannot perform goods issue due to system performance problems. This is truly farcical as backflushing moves the goods issue processing from real-time to be run in batch. Can SAP seriously think they can convince people that ECC sitting on a non-HANA database lacks the processing capability to perform something as simple as a goods issue in real time??

Backflushing has never been done (at least in the modern era) because of performance limitations. Backflushing is performed because the company wanted to carry out the activity first and record the issues after the fact. Backflushing is very common in process industry manufacturing. This is because it can often be unclear how much material will be consumed in a manufacturing process.

Diverting Attention

HANA proponents enjoy diverting the attention from the original topic. They gain the high ground by claiming other benefits that come from these other areas of "improvement." The deflection mechanism is the consistent approach by those who have been consistently wrong on HANA. The algorithm looks like this:

1. Standard HANA Pitch: If you find an uninitiated audience, give the standard line about how HANA is revolutionary due to its speed. Hide the fact that other database vendors have the same technology. Pretend that you invented the idea that data can be stored in an SSD.
2. Dealing with Hecklers, Malcontents & People that Won't Accept the Sales BS: If (on the rare occasion) you find an individual who knows this is not true, respond that HANA is much more than a database and about "much more than speed." Do this even though you know that each of the items that are "not just a database" actually has their names like HANA Studio, HCP. And that these products have no logical reason to have the term HANA in their product name. And further, ignore that SAP's first promotion of HANA has been based upon database speed.
3. Misdirection: Having regained the argumentative high ground, now make false claims, but now in different areas. I call this maneuver the "Hasso Plattner." Make so many claims in so many different areas that the person you are speaking to may not feel comfortable addressing them all. Force the respondent to perform research in many different areas to respond to your proposals. But you conduct no research at all! Simply repeat false statements provided to you by SAP marketing.
4. Use Project "Proof": Bring up illusory benefits that you have seen at all these clients you have visited. Where HANA is just transforming, the way companies do business. This will also communicate to the LinkedIn community that you are a real expert in HANA. Don't bring up any complications of HANA. And never discuss costs.
5. Employ the Concept of Universal Virtue: Talk about how you are all about improvements. And that these things are necessary to make these improvements. Promote the concept that both you and SAP are all about "client value." I had one commenter state that SAP should be allowed "maximum forgiveness" for any false statements that it made. The reason? Because it was all about moving companies to a "fill in the blank" (digital economy), (memory resident future), (IoT), (running simple),(integrated solutions).

If SAP has massively exaggerated the issue of HANA performance. Both of the perspective of the performance itself as well as the application or business case for that performance. Then that is a problem. It is not an adequate or honest response to respond to this particular criticism with a comment related to how HANA is "more than a database." That only starts up another discussion. It may or may not be, but the statement I made is regarding HANA's performance and value. That statement needs to be answered without diverting into other areas because one can't respond to the actual question with convincing evidence.

Conclusion

Getting quality IT information is a tricky business. There are a lot of overconfident and dishonest people out there who will unthinkingly repeat false information, and then defend their positions if questioned. They will try to sell the future, pretend they have seen benefits where they haven't, use unproven arguments like a new application that no one has performed a TCO calculation on automatically lowers TCO, use ad-hominem attacks, rely on concepts that have been long ago disproven (best practices, preconfigured solutions, rapid deployment solutions).

The one thing they all have in common is never admitting they were wrong.

About Shaun

Shaun Snapp is the author of many books on technology and SAP. He is the Managing Editor of Brightwork Research & Analysis. Brightwork is a website focused on publishing storylines that do not have a way of getting out through the traditional mediums in enterprise software.  

See Shaun's LinkedIn profile here. Think about connecting with him, as he likes to connect to his readers. His other LinkedIn articles are here.

Supporting Articles

This article is based upon a number of my previous articles on HANA.

This article covers whether SAP's relentless HANA push has paid off.

This articlecovers how HANA is marketed versus other databases.

This article covers what moving to the cloud actually means for HANA.

This article covers if HANA actually has a simplified data model.

This articlecovers what one actually gets from Fiori. This article gets into how Fiori has been misrepresented by SAP and its partners in the sales process in order to get people all bubbly about S4, and what a huge surprise so many companies will get if they rely upon Fiori.

This article covers how Gartner got Fiori so wrong. Gartner clearly did close to zero research to praise Fiori and recommend it, without having any understanding of how Fiori actually works.

This article questions which is actually faster, HANA or Oracle 12C.

This articlequestions the validity of SAP's Run Simple marketing program.

This article discusses the exaggerated claims made in so many articles about HANA.

This article questions whether SAP will have to backtrack on limiting S4 to HANA.

This article describes how the HCP is designed for cloud washing to make SAP implementations seems more cloud based then they actually are.

References

Backflushing is covered in my book on Process Industry Manufacturing Software.

Process Industry Manufacturing Software: ERP, Planning, Recipe, MES & Process Control

How Process Industry Manufacturing is Unique

From a distance, all process industry plants look the same. But under closer inspection, it is clear that every plant is very different. In fact, process industries have the widest variety of unique manufacturing requirements of all the manufacturing categories. As an example, this book shows examples that range from petroleum refining to power generation to cheese manufacturing. For this reason, no off-the-shelf planning application will meet all the requirements.

Through extensive graphics, screen shots—and links to videos available online—this book gives a thorough analysis of planning and the software solutions that meet the process industry’s unique and varied requirements.

The Only Book of Its Kind

This is the only book to cover ERP, planning, recipe management and manufacturing execution and scheduling (MES) as well as process control software all in one book.

By reading this book you will:

• Understand the difference between process and discrete manufacturing and why software solutions designed for discrete manufacturing leave process industries with gaps in functionality.
• Examine batch and continuous processing within process industries.
• Lessen the confusion around terminology, such as recipes, formulas, bill of materials and more.
• Learn about common software functionality designed for process industries.
• Know what to look for when selecting software to meet your business requirements for production planning.
• Explore the software applications from PlanetTogether, Arena Solutions, Hamilton Grant, and AspenTech and how their solutions meet the complexities of process industries.

Chapters

• Chapter 1: Introduction
• Chapter 2: Continuous Versus Batch Processing
• Chapter 3: The Discrete Manufacturing Focus of Most Manufacturing Software
• Chapter 4: Co-Products and By-Products
• Chapter 5: Recipe Management
• Chapter 6: Overlapping and Leading and Lagging Operations
• Chapter 7: Mixing/Blending/Pooling Operations
• Chapter 8: Changeovers and Cleaning
• Chapter 9: Constraint Planning and Process Control
• Chapter 10: Manufacturing Execution Scheduling (MES)
• Chapter 11: ERP for Process Industry Manufacturing
• Chapter 12: Conclusion

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 other 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

Software selection is the most important part of any software implementation because it is the best opportunity to match the software with the business requirements, which is the most important factor in determining the success of the project. This book explains how to get the right information from the right sources in order to perform software selection correctly.

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 properly interpret information from consulting companies.
• 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.

Chapters

• 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

Enterprise Software TCO: Calculating and Using Total Cost of Ownership for Decision Making

Getting to the Detail of TCO

One aspect of making a software purchasing decision is to compare the Total Cost of Ownership, or TCO, of the applications under consideration: what will the software cost you over its lifespan? But most companies don't understand what dollar amounts to include in the TCO analysis or where to source these figures, or, if using TCO analyses produced by consulting and IT analyst firms, how the TCO amounts were calculated and how to compare TCO across applications.

The Mechanics of TCO

Not only will this book help you appreciate the mechanics of TCO, but you will also gain insight as to the importance of TCO and understand how to strip away the biases and outside influences to make a true TCO comparison between applications.

By reading this book you will:

• Understand why you need to look at TCO and not just ROI when making your purchasing decision.
• Discover how an application, which at first glance may seem inexpensive when compared to its competition, could end up being more costly in the long run.
• Gain an in-depth understanding of the cost categories to include in an accurate and complete TCO analysis.
• Learn why ERP systems are not a great investment, based on their TCO.
• Find out how to recognize and avoid superficial, incomplete or incorrect TCO analyses that could negatively impact your software purchase decision.
• Appreciate the importance and cost-effectiveness of a TCO audit.
• Learn how SCM Focus can provide you with unbiased and well-researched TCO analyses to assist you in your software selection.

Chapters

• Chapter 1:  Introduction
• Chapter 2: The Basics of TCO
• Chapter 3:  The State of Enterprise TCO
• Chapter 4:  ERP: The Multi Billion Dollar TCO Analysis Failure
• Chapter 5: The TCO Method Used by Software Decisions
• Chapter 6: Using TCO for Better Decision Making

Gartner and the Magic Quadrant: A Guide for Buyers, Vendors, and Investors

How to Figure Out How to Effectively User Gartner

Whether you are a software buyer, a large or small vendor, or are wondering how Gartner can help you make better investment decisions, this book will give you new insights to Gartner’s research. By studying the methodology behind such popular analytical tools as the Magic Quadrant, you will understand how a vendor earned its rating and whether or not the ratings are justified!

Understanding Gartner, It's History and It's Incentives

Starting with the history of Gartner and how it compares to other IT analyst firms, this book gives a realistic assessment of the value of Gartner research to a company and provides ideas about other resources that could complement Gartner’s analysis. You will also have the tools to level the playing field between large, medium and small vendors when using Gartner’s analysis in selecting software.

Chapters

• Chapter 1: Introduction
• Chapter 2: An Overview of Gartner
• Chapter 3: How Gartner Makes Money
• Chapter 4: Comparing Gartner to Consumer Reports, the RAND Corporation, and Academic Research
• Chapter 5: The Magic Quadrant
• Chapter 6: Other Analytical Products Offered by Gartner
• Chapter 7: Gartner's Future and Cloud Computing
• Chapter 8: Adjusting the Magic Quadrant
• Chapter 9: Is Gartner Worth the Investment?
• Chapter 10: Conclusion
• Appendix a: How to Use Independent Consultants for Software Selection
• Appendix b: What Does the History of Media Tell Us About This Topic
• Appendix c: Disclosure Statements and Code of Ethics