How to Understand Hidden Indirect Access Issues with SAP HANA

Executive Summary

  • In this article, we cover how HANA has sizeable indirect access liabilities, and what the rules are regarding indirect access and HANA.

Introduction

In previous articles, I have outlined some areas where HANA is not what is presented by SAP. One of these areas was the exaggerations of performance made by SAP regarding HANA. Companies are often lulled into an accepting posture concerning HANA on puffed up performance claims and confusing everything from the cost of HANA to what it can do versus other databases, without considering the other hidden implications to HANA.

HANA is selected in many cases, not because of any particular business case for HANA per se, but because HANA is “SAP’s future direction,” so it is a right safe choice. From a competitive perspective, this is interesting because it means that HANA is frequently selected over other alternatives because of non-HANA attributes.

Either way, what often receives little attention is some of the other ways that HANA can end up becoming a liability long after it is purchased. This is because the information is trickling in that SAP is enforcing extra indirect access rules on HANA.

What is Indirect Access?

Indirect access is when a software vendor charges to access the data that is stored in their system. The concept is still relatively new and tends to only apply to large and powerful software companies that have products already installed at companies. That is, as a SAP customer, you will not find out about indirect access during the sales process. Indirect access is presented as if it is copyright protected, but the way it is often treated by SAP, it is an enlargement of copyright protection. Moreover, almost undiscussed in a published form, is the way indirect access is used by large vendors to block out smaller vendors from their accounts.

Indirect access is, therefore, a form of account control. Moreover, like any technique of account, control, indirect access is designed to point out as many IT expenditures as possible back to the large IT vendors.

Indirect Access in SAP Licensing Agreements?

I do not spend much time reading SAP licensing agreements. However, I imagined indirect access had to be spelled out in these documents.

I reviewed the On Demand HANA Terms of User, which in turn directed me to the end user license agreement (EULA) for SAP on-premises indirect sales. However, when I review the EULA, the term “indirect access” does not appear a single time. SAP’s sap licensing audit team. However, indirect access terms must be stated in the SAP licensing agreements somewhere.

This leads me to question where indirect access is stipulated for SAP products, and therefore how and when SAP customers first become aware of the indirect access implications of their purchase.

Published Information on Indirect Access and HANA

Once I moved away from reading SAP licensing, I still could not find anything published on SAP’s treatment of indirect access with HANA. Moreover, SAP has a good reason not to publish on this topic. Indirect access rules and restrictions are something that they want to keep silent during the sales phase. Moreover, then spring on the customer after the sale has been made, and even better after the implementation is complete or at least somewhat far along.

After the customer finds out what a weak position they are in, and how they will be on the hook for purchasing more SAP products, the SAP account manager can say

“We should have done a better job communicating on indirect access, but at the time we were so focused on explaining all the performance benefits of HANA.”

I have been on quite a few projects with SAP, and the

“we could have communicated better”

or

“there may have been miscommunication”

are always preferable of the more accurate

“we deliberately withheld information from you.”

As Presented by the Account Executives

This is presented by the account executive with sort of a manner of “esprit de corps.” That is as if the miscommunication was somehow mutual, and therefore we both have to do better to make the relationship with SAP work.

Moreover, will the sizeable consulting partner communicate on this topic as they “advise” the customer? Not. Additionally, here is why. They want the HANA implementation business. Also, as SAP partners, they are not allowed to provide any information that may in any way interfere with a sale both by the partnership agreement with SAP as well as their internal incentives. That is what customers get for their money in the “advisory” market for SAP.

This takes me back to my time working for one particular software vendors where I explained that there were three items that the customer had purchased, let us call them A, B and C. Where B connected A and C.

When I explained this to the customer, they told me.

“We did not buy B. We only bought A and C.”

So I told them I would speak to sales to discuss the matter. Upon meeting with sales, the salesperson was furious. She told me that I “blew the deal and blew her credibility” by pointing out that B was necessary.

Conclusion

  1. Companies that purchase HANA are typically replacing another database with HANA. It now appears that HANA’s indirect access implications over any database it replaces.
  2. Companies that are thinking of purchasing HANA need to get information as to what are these other indirect access liabilities.
  3. Companies that have already purchased HANA and or are implementing HANA need to find out about these indirect access liabilities as soon as possible, as it can allow more flexibility in decision making and finding out when the SAP account manager wants to release this information to the customer. That time being when the customer has the least opportunity to do something about it.

In my next article, I will get into these topics in more detail.