- HANA is presented as a desirable item without understanding what HANA entails.
- We observe that HANA may have become a MacGuffin for many customers.
We have spent years analyzing an enormous amount of marketing information on HANA and after receiving numerous emails about how both SAP and SAP consulting companies explain and pitch HANA to customers in private. We recently observed that there are compelling similarities between HANA and a plot device called a MacGuffin.
What is a MacGuffin?
In script writing, there is a plot device called a MacGuffin. Wikipedia explains in the following way.
“In fiction, a MacGuffin (sometimes McGuffin or maguffin) is a plot device in the form of some goal, desired object, or another motivator that the protagonist pursues, often with little or no narrative explanation. The MacGuffin’s importance to the plot is not the object itself, but rather its effect on the characters and their motivations. The most common type of MacGuffin is a person, place, or thing (such as money or an object of value). Other more abstract types include victory, glory, survival, power, love, or some unexplained driving force.”
How SAP Uses HANA as a Controlling Concept or MacGuffin
Recently I began thinking about how SAP uses HANA. Recently I was told that SuccessFactors would be migrated to HANA. Here is the exact sentence.
Our first thought when I hear of a CRM system being ported to HANA is…
CRM has the lowest processing needs of enterprise applications. It does not need a database like HANA that is optimized for analytics, and for short query analytics at that.
SAP and its consulting partners are advising their customers to use HANA in situations where it makes no sense to use it. This is wasting the customer’s budgets on HANA implementations that will do very little except drive revenues to SAP and to their consulting partners. They are relying upon a series of unsubstantiated claims about HANA, claims that they cannot substantiate, and refuse to substantiate.
Mindless Recommendations Courtesy of SAP and SAP Consulting Partners
One of the factors that are incredibly prevalent with regards, so HANA is that it has instilled a sort of mindlessness in SAP and SAP proponents.
- Get analytics and transactions optimally from the same database? Yes? Incur more maintenance or technical complications to do so, of course not!
- Apply unproven database performance benefits to an application that does not need it? Absolutely!
- Focus on HANA with SuccessFactors, when it is well known that SuccessFactors requires development focus in other areas, but of course!
Why think or provide any evidence of any kind or consider the benefits of the uses of different databases to different applications when one can just work for uncritically analyzed assumptions and say HANA is the answer in 100% of cases!
This is the same unthinking approach that led companies to purchase ERP systems before ERP systems were ever proven to improve the condition of those companies that implemented them. We covered this feeding frenzy of exaggerated claims and misinformed decision making in the book The Real Story Behind ERP: Separating Fiction from Reality.
Placing SAP ByDesign on HANA
This is reminiscent of ByDesign being placed on HANA. Customers have all manner of complaints about ByDesign. The most common complaint customers have about ByDesign has nothing to do with database speed. But yet ByDesign was migrated to HANA with great fanfare.
The problem is that HANA has been presented as an item of unlimited virtue by SAP and SAP proponents. Yet SAP has been unable to substantiate their claims around HANA. But this has not stopped SAP from making these claims.
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.
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