Category Archives for "SAP License Strategy"

Are SAP Customers Actually Under Licensed After Indirect Access?

What This Article Covers

  • SAP’s Obsession with and Normalization of the Term Under Licensed
  • Extending The Faux Olive Branch
  • SAP’s New Favorite Word……”Unlicensed” and Its Use with Respect to Indirect Access
  • How About Being Overlicensed?
  • SAP’s Overemphasis on the Term Underlicensed Versus Other Vendors
  • The Likelihood of Being Overlicensed Verus Underlicensed

Introduction

SAP has written a great deal about customers that are “under licensed” with respect to indirect access. In this article, we will describe how SAP uses the term under licensed.

This is a quotation from their announcement at SAPPHIRE on indirect access.

If you’re fully licensed, there’s no action for you.

That would logically follow.

Still, it is curious how SAP can make the fact that a company is in license compliance with SAP sound like SAP is doing their customers a favor by telling them there is no action to be taken.

But while the statement from SAP sounds innocuous, it should be noted that is no way of knowing if you are “fully licensed.” This is because, under SAP’s definition of indirect access, which we call Type 2, all customers that use non-SAP products are potentially not fully licensed. This is the problem with clarity that SAP has very deliberately put out into the market.

Here SAP is proposing that something is “knowable” when in fact it is entirely at the discretion of SAP. This would be like me saying “guess how many coins are in my pocket. If you guess correctly you will win a new set of steak knives. However, how will you ever know how many coins are in my pocket for sure if I am the one who reveals to you how many coins I, in fact, have in my pocket? 

This is the problem with the opacity that SAP has very deliberately put out into the market with respect to indirect access.

From this deliberately created insecurity, SAP then proposes that customers reach out to them to find out if they are unlicensed.

However, if you’re questioning whether you are under-licensed, let’s talk about it. We want customers to proactively engage us on this topic.

Under SAP’s definition of Type 2 indirect access, 100% of customers would need to reach out to SAP to find out for sure.

Naturally, this is less work for SAP.

But SAP demands do not stop there. SAP also wants the following:

  • SAP wants customers to accept their interpretation of indirect access and normalize Type 2 indirect access.
  • SAP also prefers that no meddlesome outsiders be used to negotiation with SAP. It is SAP’s preference that work with them one on one.
  • All customers need is to talk to your SAP account executive.

SAP has a lot of requests on indirect access, and customers that accept them uncritically set themselves for quite a few liabilities.

In order to get customers to do what they want, SAP offers the following carrot.

SAP assures customers who proactively engage with SAP to resolve such under-licensing of SAP software that we will not collect back maintenance payments for such under-licensing.

SAP could teach a master class on deceptive writing. Look at the previous paragraph and what does it appear to say?

  • At first glance, it may appear to say that SAP will not collect back payments for under-licensing. However, SAP will only waive back maintenance payments.
  • So in return for a reduction in 22%+ in support payments, SAP will get a sizable number of companies to report to SAP.

Seems like a pretty good deal for SAP.

Yet, SAP wrote the paragraph as if they were offering a gift to their customers.

Strange gift. Is this a concession to customers, or simply a way to get customers to come forward to do what SAP wants?

This is how SAP wants its customers to think of their relationship so that they will lower their guard. 

But savvy customers should think. Is this really a good description of how SAP tends to behave in negotiations? 

Extending The Faux Olive Branch

Now the faux olive branch is further extended.

We will look at your specific circumstances when resetting your licensing agreement, including providing you the opportunity to receive credit for certain products you may have already licensed so you can update to the new metrics.

That should normally be the case, so this is no concession.

Translation, you as a customer owe SAP money. They owe it because of the all-encompassing definition of Type 2 indirect access places all SAP customers into the bucket of being potentially under license. This gives SAP maximum latitude in when to indirect access charges against a customer.

But if you report to SAP, they will go easy on you…at least that is the pitch.

Like a kid who just got a new paint set, SAP is slathering the term “under licensed” everywhere it can. In doing so, it seeks to adjust the conversation with customers to how much a problem SAP under licensing is.

SAP’s Overemphasis on the Term Underlicensed Versus Other Vendors

Without the faux concept of Type 2 indirect access, SAP and Oracle are vendors with the lowest degree of under licensing in enterprise software.

Vendors like Teradata or SAS not use this terminology. In fact, I was not able to find a single result for the terms “Teradata + under licensed” or “SAS + under licensed” in Google.

SAP defenders will often defend dodgy practices by saying that “everyone is doing it.” However, both observations, our network, as well as Google seem to be saying that not all vendors behave this way.

SAP’s New Favorite Word……”Unlicensed” and Its Use with Respect to Indirect Access

SAP loves to pitch the narrative of being under licensed. A full analysis of this announcement can be found at the article An Analysis of SAP’s Faux Policy Change on Indirect Access.

How About Being Overlicenced?

SAP will never speak about customers that are over-licensed. However, being over licensed is quite common. There are several reasons for this. Users are created, but then sometimes abandoned.

  • People leave the company but their users are still in the system
  • Consultants come and go
  • Customer over purchase SAP licenses and never optimize their licenses.

In speaking with multiple SAM or software asset management vendors on this topic, in most instances, over licensing is more common than under licensing. SAP will not give back money to a company, so being over licensed means having a “bank” of unused licenses that can be used in the future. During the yearly soft audit run by

In fact, SAP has very little interest in even discussing the topic of overlicensing, even though it is far more common than underlicensing.

  • Yearly Soft Audit: During the yearly soft audit run by SAP the customer only hears back if they are “under licensed.”
  • The One Time Overlicensing is Brought up by SAP: If you are over licensed, SAP will have nothing to say on the matter. Over-licensing may be used by the account executive to get the customer to purchase a product the account executive wants them to purchase. Finally, at this point, the discussion of trading in unused licenses will be brought to make the sale for the new product.

Conclusion

  • Companies should never accept SAP’s presentation of their licensing state. The licensing status presented by SAP is a mechanism to get the most license revenue out of the customer.
  • Companies should not simply accept the assumption regarding Type 2 indirect access.
  • Brightwork’s extensive research into the topic has illustrated that neither SAP nor any of SAP’s surrogates (ASUG, Deloitte, Gartner, etc..) have provided accurate information on indirect access. In fact, much of it is deliberately misleading.

References

Modern Pricing for Modern Times

Analysis of Snow Software on Ways to Cut Spending

What This Article Covers

  • Quotes from Snow Software
  • Analysis of the Quotes

Introduction

Snow Software wrote a paper titled 5 Ways to Cut Spending on SAP Software. In this article, we will analyze this paper.

Quotes from Snow Software’s Article

SAP has more than 40 named user license types in its standard definitions, ranging in price from $60 to $7,000 per license. These license types determine what transactions the user is permitted to perform in the environment. SAP puts the onus on its customers to assign the appropriately named user license type to each user account. Without the right data upfront, the only way to do this is to generalize and attempt a best-fit. The work that individuals perform can change year on-year. This means that a license type which once fit well beforehand is no longer compliant

It is in fact quite interesting that SAP has such a broad continuum of user license prices.

Organizations typically end up overspending because they do one or both of the following:

  1. Purchase unnecessarily costly named user license types to ensure coverage of user’s requirements, but also cover them for use of transactions that they do not need.
  2. Keep user-license assignments static until the next SAPmandated system measurement, and then pay the fees that SAP requests for any shortfall.

So basically customers have a hard time optimizing their licenses. I think there is a common misimpression that the company’s contract or purchasing arm will perform license optimization. This is not the case. And one does require software to provide the necessary information. This also keeps SAP from leading the discussion, which will, of course, lead to more of what SAP wants, rather than what the customer needs.

During a proof of concept, Snow typically discovers around 20% of licensed users in an organization who have been inactive for more than 90 days. Users who have been inactive for more than 90 days (or whatever date is deemed appropriate) can have their license returned to a pool (re-harvested) for reassignment as and when they are required.

This was quite interesting. This means that many customers are over licensed. This is also interesting because SAP only ever discusses the potential of being “under licensed.”

This environment evolves over time as new systems are added. Users must be licensed to access these systems and so they are often provided with a new account, the username of which may be different from the username they have for other systems.

Another issue where SAM software can assist.

Indirect Usage is, in simple terms, where an SAP system is accessed or queried through a third-party application. The way in which that application interacts with the SAP system and underlying data can have a significant impact on licensing requirements and financial exposure at the point of audit. If any individuals are accessing SAP-stored data through third-party software, organizations must ensure that they have an SAP named user license of the right type provisioned for them.

Why this is true. The assumption presented here is that all integrations to SAP applications mean that the customer needs to have licenses. This is an endorsement of SAP’s Type 2 indirect access. However, Brightwork has repeatedly questioned whether this type of indirect access is even valid. This is the concerning feature of SAP, that they can make a proposal which breaks with the legal precedent in licensing, and pretty soon everyone from consulting companies to SAM vendors is repeating it.

Organizations should build up an architectural diagram of Indirect Usage across the SAP environment. This places them in a strong position when SAP audits because any additional fees are based upon real usage, not an estimated and perhaps overinflated value which is indefensible because of lack of visibility.

Yes, this is true, SAP sets about to cheat its customers whenever possible. So SAM software is necessary because the customer must have access to usage information that is independent of SAP.

SAP licensing is not only based on per-user metrics, but includes software engines as well. SAP engines (aka packages, modules and add-ons) are optional applications for which additional licenses must be purchased. The metric used for licensing differs by engine, and is based upon the objects that exist within that application or its total CPU consumption. For example, the metric for SAP Payroll Processing is number of master records, while the metric for SAP E-Recruiting is number of employees.

This is apparent from reading the SAP Price List. It is so complex to price many of SAP’s applications, that even account executives rely on a professional pricing expert that does nothing but pricing within SAP. What Snow software is saying is that this pricing is built into their software. We are not validating this, but if true it is an impressive accomplishment given SAP’s pricing complexity.

SAP licensing is both complex and open to interpretation. Typically, environments have been running for many years, so it is difficult to get a handle on which licenses are assigned to which users, whether those licenses are correct for the user and indeed whether a license is required at all.

This quotation highlights how licensing must be run occasionally as the usage of the SAP system changes over time.

Conclusion

Snow Software’s paper was quite helpful and educational. The indirect access quotations are a concern for reasons already listed in this article.

References

http://go.snowsoftware.com/rs/377-PWR-208/images/5Ways_To_Cut_Spending_On_SAP_Software_en_aug.pdf?aliId=12824339

Type One Versus Type Two Indirect Access

What This Article Covers

  • Two Types of Indirect Access
  • Type One Indirect Access
  • Type Two Indirect Access
  • Differentiated Prices
  • Indirect Access Mind Map

Introduction

Often in discussions around indirect access, I have the person I am discussing the topic with bringing up the point around the advice that one receives to check the contracts.

This is also a concept that is promoted by those that work on contracts for a living. The idea is that all that is necessary to protect oneself is to have the sentence taken out of the SAP contract that states that the customer can only access SAP software either “directly or indirectly” through a license.

The problem with this approach to dealing with the issue is not the existence of this clause, and this is why statements regarding taking an entirely contract focused approach to indirect access will not work. It is also why it is inaccurate to state that in the SAP v. Diageo case was due to Diageo not paying close enough attention to the contract. It falls into the same category of misinformation and misunderstanding that SaaaS was responsible for the game-changing on indirect access.

To see why, and hopefully, to increase the knowledge in this area, I decided to cover what I am calling two different types of indirect access. In all of my reading on this topic, I don’t recall anyone proposing this, but it makes logical sense, and using this terminology will help mitigate confusion on this topic.

Two Types of Indirect Access

I view there being two basic types of indirect access. One of these types is a legitimate complaint on the part of the vendor. The other is not a legitimate complaint and is an attempt by one vendor, SAP, to expand the definition of indirect access in such a broad way that if it were accepted it would totally change the landscape in the enterprise software market. It would give the largest software vendors, even more, leverage than they already possess. In fact, I am now getting reports of other software vendors copying SAP and at least trying to invoke SAP’s definition of indirect access.

Type One Indirect Access

Type one Indirect access is when a company develops a user interface or uses a third party user interface to connect to an application. By using a user interface to access the data and functionality within the system, type one indirect access cheats software vendors out of rightful revenue.

Type one indirect access is completely well founded and is difficult to argue with. However, the problem with considering this type of indirect access is that it is not very common. It has been the historical reasons that software vendors have gone after customers for extra licenses.

Type Two Indirect Access

SAP has the following definition of indirect access, which I took from JNC’s article on this topic.

“Indirect access is user or third party application creating, manipulating or viewing data in the SAP systems via an interface.”

Well congratulations, SAP is describing any system to system interaction. Therefore SAP deserves a license sale for any system that is connected to SAP. So if a customer purchased 1000 licenses of Salesforce, it now owes SAP 1000 of ECC. SAP created its definition which in an amazingly self-serving manner for a company that already has its software installed at so many customers, changes the game to its benefit.

I quote from Dave Blake of UpperEdge

The most challenging aspect of SAP’s claim of a license grant violation here lies in the very definition of use itself. The definition fails to specifically identify the concept of indirect use which leaves it completely up to SAP to determine when a violation has occurred and to what magnitude. In the past, SAP briefly nipped at its customers’ heels on the issue of indirect access, but recently, SAP has shocked some of its loyal customers by going for the jugular. Through our customers, we have observed SAP use indirect access violations as an excuse for predatorily squeezing fees from their customers, and worse, seizing the opportunity to reduce flexibility and promote an anticompetitive environment.

That is correct. I like this entire paragraph, but the part that hits home is that SAP has created its definition of indirect access that no one outside of SAP seems to agree with. Dave Blake goes on to explain the following:

Although they can educate themselves about SAP’s behavior and negotiate accordingly from the get-go, SAP’s new definition of how their software cannot be used will handcuff even its new, informed customers into agreements which expose their company and now also include ludicrous restrictions on data extraction.

Once again, this contradicts the commonly presented idea that all one needs to do is to check the license contract. I also like the term ludicrous. I think I previously used the term lunacy to describe SAP’s new “interpretation” of indirect access, so ludicrous and lunacy seem kissing cousins as words, so Dave and I seem to agree on adjectives to use.

From our perspective, where non-compliance is clear, SAP is entirely within its right to demand payment for its customers’ use infractions. For example, it is acceptable for SAP to tout indirect use as a protective restriction when there is a legitimate reason for SAP to protect its intellectual property (IP). When unlicensed users knowingly take advantage of SAP’s infrastructure and unique processing capabilities without paying, SAP is justified in requesting its customer pay additional fees for the additional benefit. We also do not fault SAP for protecting its IP in situations where its processes enhance the capabilities of other systems. But of course, this is not where SAP’s definition stops.

I don’t know if this is the same distinction I am drawing between Type 1 and Type 2 indirect access, but it does sound similar.

If we take Dave Blake’s comment, regarding “knowingly take advantage of SAP’s infrastructure without paying…”

This wording gets a bit tricky. The reason being that when integrated, all applications take advantage of each other “infrastructure,” its data and its processing. That is the nature of application integration. If a CRM system sends sales orders to ECC, it is leveraging the infrastructure of SAP. But if the customer purchases SAP CRM, SAP does not charge the same license price for the ERP license. Actually in most cases waiving the license fee. SAP CRM is leveraging ECC’s infrastructure the same way as Salesforce. The fact that SAP is engaging in such differential pricing puts it into the category a tying agreement under US anti-trust law. In fact, I don’t think there should be much debate on this, and the details can be read in my article How to Fight Indirect Access with Tying Agreement Law.

So SAP applies a double standard. First, it will allow its applications to “indirectly access” (that is under its expanded definition) other applications, but if the software from another vendor does the same thing, then SAP wants licenses of the connected to system to be paid. That is indirect access only applies when the application is from a different software vendor. However, that is a completely inconsistent definition of indirect access. I want this point emphasized so.

  1. It is illogical for SAP to apply for indirect access only to non-SAP applications.
  2. It is illogical for SAP to have a definition of indirect access that is entirely contrary to the overall history of licensing of software.
  3. If SAP was going to take this approach to indirect access, they should have done so back in the 1980s when they started selling their ERP application. If they had, they would have never grown into what they are today.

If indirect access were applied to other types of software then if data were exported from Excel in a CSV format and then uploaded to a non-Microsoft database, then Microsoft would be owed an extra license of Excel. But on the other hand, if an Access or SQLServer were used, then no extra license of Excel would be required. That is the exact logic that SAP is using with its current determination. But it gets worse than that. If you agreed to purchase another unrelated application, for instance, Outlook, then the Microsoft account executive would waive the indirect access license for Excel!

Therefore, while I think Dave Blake here is on the right path, I don’t think the language is sufficiently specific to differentiate what is real indirect access from faux indirect access. This is why I prefer the terms Type One from Type Two indirect access. Type One is a legitimate form of indirect access. Type Two, which I also call SAP’s type isn’t.

Differentiated Prices

But there is also an extra dimension which must be captured, and it is not captured by the Type One and Type Two distinction that I have covered thus far. And, this is the questions of differential pricing as well as indirect access only applying to non-SAP applications being connected to SAP applications.

Indirect Access Mind Map

To help people make sense of this, I have the following mindmap graphic, with an accompanying description of the likely outcome depending upon where you are on the map.

  • A.) If both systems in question are SAP, then SAP will not apply for indirect access. Indirect access not defined by the use, but by whether the connecting system is sold by SAP.
  • B.) If you don’t buy other licenses from SAP that are unrelated to the first system that is being connected to, then SAP may decide to apply indirect access license fees.
  • C.) If you are willing to purchase other licenses from SAP, then the indirect access issue will most likely go away. SAP applies for indirect access inconsistently. It is used to punish customers that buy as much from SAP as SAP thinks they should.
  • D.) If you are not willing to purchase licenses immediately, but the account executive still sees you as a high or better than average potential account, then you will most likely not face indirect access charges.
  • E.) If you appear to be moving away from SAP, then indirect access becomes much more likely.

References

SAP Indirect Access Explained

SAP and Indirect Use: Is SAP Taking Advantage of its Customers?