Brightwork Analysis of SAP’s 2017 White Paper on Indirect Access
Executive Summary
- SAP’s produced a highly misleading 2017 white paper on indirect access.
- In the white paper, SAP introduced a new policy for SAP ECC customers and S/4HANA.
- We analyze SAP’s proposal regarding indirect static read scenarios and Order-to-Cash (O2C) and Procure-to-Pay (P2P).
Video Introduction: Brightwork Analysis of SAP’s 2017 White Paper on Indirect Access
Text Introduction (Skip if You Watched the Video)
SAP produced a white paper on indirect access. This white paper is filled with deceptions and is where SAP sets the pretext for how it will apply its fallacious concept of indirect access to SAP customers. It also sets up a ridiculously complex scheme where customers would be charged per transaction processed. The white paper sets up a scenario where customers would be paying other vendors indirect access fees. If followed, this design would create high overhead chaos within customer environments. You will learn about SAP’s accuracy and what the paper says about how SAP will enforce indirect access in the future.
Our References for This Article
If you want to see our references for this article and other related Brightwork articles, see this link.
Notice of Lack of Financial Bias: We have no financial ties to SAP or any other entity mentioned in this article.
SAP’s Executive Summary
“This white paper is intended to communicate the Indirect Access on-premise pricing policy changes made in Q2017, as well as outline the future direction with respect to the licensing of Indirect Access.
The technology landscape has changed dramatically over the years and so has the way customers consume and use SAP software. Unlike the past when most use of SAP ERP involved employees of our customers logging into the SAP ERP system directly, there are now a multitude of scenarios related to ERP usage as shown in Figure 1.”
Populations using SAP ERP: In addition to employees, there are business partners, consumers, devices, automated systems, bots, etc. that now use SAP ERP.
Access to SAP ERP: Direct access by users logging into the system, as well as access via other SAP and 3rd-party applications, platforms, multiple layers, etc.
“While SAP maintains its position that any use of SAP Software needs to be properly licensed, we are embarking on a journey to modernize our licensing policy. Policy changes discussed herein are designed to focus on outcomes related to SAP customers’ use of our software based on the value delivered. This outcome-focused approach will eliminate the need to count individual users or other parties indirectly accessing SAP ERP in certain scenarios. This approach will ensure greater pricing transparency, predictability and consistency.”
SAP has a storyline on indirect access they present that puts them in the best possible position to extract unrealistic amounts of money from their customers. But to do this, they must get them to accept certain false assumptions. Part of SAP’s storyline is that so many other systems are accessing or connecting to SAP for the first time.
That is not exactly what is being said, but it is implying many more connections to SAP.
The Truth of SAP’s Connections to Many Applications
The truth is that SAP was always deeply connected to many applications. And at that time, they did not charge indirect access fees.
“In order to modernize SAP’s licensing policies, we started a project in 2016 and have been working with user groups, customers, industry analysts and other stakeholders to understand and address the concerns related to indirect access. We identified the three most common indirect access scenarios: (1) order-to-cash, (2) procure-to-pay, and (3) indirect static read. These common scenarios cover the majority of indirect access scenarios we have observed over the years. The pricing changes for these common scenarios is our first step in the longer journey of modernizing our licensing policy. We will continue this journey by working with the relevant stakeholders in order to comprehensively address all indirect access scenarios”
That was not the intent of “starting” this project. SAP has never been focused on modernizing licensing policies. In fact, SAP is the only vendor I am aware of (please comment if you know of another one) that states in its pricing list that releasing its pricing information would cause it damage. Companies that want to modernize their licensing policies don’t release media material about how they want to do it. They just do it.
What SAP tried to do, which is covered in the article, How to Best Understand SAP’s Faux Change in Indirect Access Policy, is to address customer’s concerns about SAP’s strange implementation of indirect access, which has kept as secretive as it could (to be able to use it against customers). SAP’s intent of releasing new information about indirect access, which was done at SAPPHIRE 2017, to get customers to reduce their defensive posture regarding the topic.
However, as I covered in the article The Danger In Underestimating SAP’s Indirect Access when SAP was asked about how much it would charge per sales order and purchase order, it would not publish any information. Everything would be on a case-by-case basis. Is that “modernizing” its licensing policies?
Actually Indirect Access?
Secondly, what SAP calls indirect access is not actually indirect access by the definition of any other software vendor.
“We encourage customers to engage with us. We are committed to working with customers who are under-licensed or interested in reconfiguring their licenses per the new policy. SAP assures customers who proactively engage with us in good faith to resolve such under-licensing, that we will not pursue back maintenance payments for SAP Software for such under licensing.”
Customers should not engage with SAP. SAP cannot monitor indirect access with their license transactions. So they depend on customers to reach out to them and willingly provide information, which SAP will frequently use against the customer.
This sounds like a “carrot,” but in fact, it hides as a “stick.”
Background Information on Indirect Access
“Use” is defined in SAP’s current contractual documents as: “to activate the processing capabilities of the Software, load, execute, access, employ the Software, or display information resulting from such capabilities.” Additionally, “Use may occur by way of an interface delivered with or as a part of the Software, a Licensee or third-party interface, or another intermediary system.” Use is defined broadly to cover both direct and indirect access scenarios and any use of the SAP Software requires an appropriate license.
“Indirect Use / Indirect Access” are a commonly used terms throughout SAP and our ecosystem that describe the same thing. Indirect acess is use which occurs by way of a non-SAP frontend or non-SAP intermediary software. The picture below shows the difference between use via direct access and use via indirect access
This graphic is a keeper! Basically, any system connected to SAP is indirect access. This would include all custom-built applications that were at the customer before SAP was implemented. Therefore, SAP should be, under this definition, able to charge for these connections as well.
How SAP Sets Up the False Construct Around “Use of SAP”
“All use of SAP software requires a license. This includes use which occurs directly (direct access) by way of a user interface delivered with or as a part of the Software or indirectly (indirect access) through a non-SAP front-end or non-SAP intermediary software.”
- “Direct access to ERP is licensed based on users.
- Indirect access to ERP historically has also been primarily licensed based on users. However, as mentioned earlier, we have embarked on a journey to move away from user-based licensing to a more transparent and predictable licensing model focused on outcomes related to our customers’ use of the SAP ERP system.”
Really, well, that is a change. If SAP had used this graphic back when it was rising as a software vendor, no one would have purchased their software. This is the type of policy that only a monopoly vendor can employ after it is already in the account.
Secondly, indirect access has historically only been shown as “scenario 1” above, where the customer develops an app to bypass paying a user license, which has historically been quite uncommon. Two other scenarios described in the above graphic are only considered to be indirect access by SAP.
New On-Premise Licensing Policy for Common Indirect Use Scenarios
SAP does on to say about Order to Cash Scenarios
Order-to-Cash Scenario
“In an order-to-cash scenario different classes of individuals (e.g., employees of licensee, employees of business partners of the licensee and/or consumers), devices, automated systems, etc. use SAP software to participate in the licensee’s order-to-cash process.”
In the past:
“Every employee of the licensee and every employee of a business partner of the licensee who used the SAP software directly or indirectly was required to be licensed as a Named User in order to participate in the licensee’s order-to-cash process
Any consumer participating in the licensee’s order-to-cash process was licensed based on the number of sales or service orders placed by the consumers. Note: both “Business Partners” and “Consumers” are terms which are defined in each licensee’s software contracts.”
No, that is incorrect. In the past, say before 2012, users that would use, say, Salesforce, and then sent information to SAP would not have been required to purchase an SAP license if they never logged into SAP. Order to Cash was priced per sales order? I am scratching my head to when that was.
SAP’s price list states that S/4HANA Enterprise Management is charged per user. Cash Management is priced per revenue unit, but that is the only pricing that is not user-based that I could find. My price list may be out of date, but SAP is talking about the past here.
New Policy for SAP ECC Customers
“Instead of requiring the licensing of users, this new policy allows certain indirect order-to-cash scenarios to be licensed via “orders”, as outlined below.
“Orders” in an order-to-cash scenario is defined as the number of sales and service orders processed by the system annually; a metric that is more transparent and predictable compared to Named Users.”
Going forward
“Any employee of the licensee who uses the SAP ECC software indirectly (through a non-SAP front-end or non-SAP intermediary software) to participate in the licensee’s order-to-cash process will continue to be licensed as a Named User.
Any employee of a business partner of the licensee who uses the SAP ECC software indirectly (through a non-SAP front-end or non-SAP intermediary software) to participate in the licensee’s order-to-cash process does NOT need to be licensed as a Named User for such use. Instead, the Use of the software would be licensed based on the number of Orders as defined above.
Any Use of the software by consumers participating in the licensee’s order-to-cash process would continue to be licensed based on Orders.
Any Use of the software by devices, robots, or automated systems participating in the licensee’s order-to-cash process would also be licensed based on Orders.”
This may be SAP’s policy, but it is entirely inconsistent with the entirety of the software industry’s history.
Are These Assumptions Proposed by SAP True?
Connecting a non-SAP system to SAP is not “using ECC software indirectly.” If that were true, then the non-SAP software vendor would also be due licenses because the customer is using (under that set of assumptions) their software indirectly through SAP!
It’s encouraging to see that SAP will not be charging indirect access fees for SAP to SAP connections. However, this illustrates one of the primary issues with SAP’s application of Type 2 indirect access.
If customers are only charged when non-SAP applications are connected to SAP applications, this creates a barrier to entry to purchasing non-SAP applications. This is a violation of the tying agreement clause in US antitrust law. In fact, this issue is covered in the article, SAP Indirect Access, and Violation of US Anti-Trust Law.
Hmmmmm……is SAP Insecure About its Offerings?
This certainly makes it appear as if SAP is extremely insecure about competing on the strength of its offerings and is seeking to coerce its customers into buying SAP applications and databases. As a policy question, why would the US allow larger vendors to force anti-competitive controls like this on companies?
New Policy for SAP S/4HANA Enterprise Management Customers
“Unlike in SAP ECC, any employee of the licensee who uses the SAP S/4HANA Enterprise Management software (S4) indirectly (through a non-SAP front-end or non-SAP intermediary software) to participate in the licensee’s order-to-cash process does NOT need to be licensed as a Named User. Instead, such indirect access by these individuals would be licensed based on Orders.
For employees of a business partner of the licensee, consumers, and devices, the new pricing approach is the same as described under SAP ECC.”
Right, that is SAP’s plan. It is unclear why customers should accept this. SAP might be persuaded to change their position if it were explained to them that this policy would lead to outsourcing support to a non-SAP provider.
“Orders are licensed via a traditional perpetual license model, similar to how we license other on premise products today. The pricing is tiered, meaning that the price per order decreases as the volume of orders increases. The pricing is also differentiated for business to business (B2B) vs business to consumer (B2C) scenarios, taking into account different order volumes and values.”
Except, SAP won’t publish the pricing as it will be applied on a “case by case basis.”
Procure-to-Pay Scenario
“In a procure-to-pay scenario, different classes of individuals (e.g., employees of licensee and/or employees of business partners of the licensee), devices, automated systems, etc. use SAP software to participate in the licensee’s procure-to-pay process.”
New Policy for SAP ECC Customers
Instead of requiring the licensing of users, this new policy allows certain indirect procure-to-pay scenarios to be licensed via “Orders”, as outlined below.
“Orders” in a procure-to-pay scenario means the number of purchase orders processed by the system annually; a metric that is more transparent and predictable compared to “Named Users.”
In the future:
Here the same policy that applied for sales orders applies for Order to Cash.
Indirect Static Read Scenario
“Indirect static read is a scenario in which information has been exported from an SAP system (other than SAP Analytics Packages) to a non-SAP system pursuant to a predefined query that meets the following criteria:”
“Was created by an individual licensed to use the SAP system from which the information is being exported runs automatically on a scheduled basis, and”
“the use of such exported information by the non-SAP systems and/or their users does NOT result in any updates to and/or trigger any processing capabilities of the SAP System
SAP’s new policy is that the use of such exported data in 3rd-party non-SAP systems does not need to be licensed, as long as all of the above criteria for indirect static read are met.
Indirect static read scenarios are applicable in the context of data exported out of the SAP ERP system or any non-analytics package from SAP. SAP Analytics packages that are excluded from this policy are: SAP BusinessObjects Enterprise; SAP BusinessObjects Lumira; SAP BusinessObjects Predictive Analytics; SAP Business Warehouse.”
Of the various ideas presented in SAP’s 2017 indirect access announcement, the “static read” concept is the most deliberately misleading.
Scenario Indirect Static Read?
SAP then provides the list of reading access actions that would and would not classify as an indirect “static read.” However, the way SAP listed them is confusing, so I have reorganized them below.
Indirect Static Read Actions (Allowed)
“An employee of SAP’s customer views reports (e.g., financial statements, forecasts, etc.) in a non-SAP system where such data was transmitted from an SAP system prior to an employee accessing the non-SAP system.
A licensed employee of SAP’s customer downloads information from SAP ERP to a 3rd party software system so that others can view that information in the 3rd party software
Customers of SAP’s customer view a product catalog on a portal built on and operating on the SAP Cloud Platform, where product and pricing info originating from an SAP ERP and/or SAP S/4HANA system was transmitted to the portal prior to the individual accessing the portal.
An employee of SAP’s customer views his customer’s master data in a table within 3rd party application where such information originated in SAP ERP and was downloaded to 3rd party application prior to the employee accessing it.
An employee of SAP’s customer accesses a 3rd-party data analysis tool to sort, filter, and analyze data that was transmitted from an SAP application prior to the employee accessing the 3rd-party tool.”
Basically, what this amounts to is that customers can report on data generated in SAP using a non-SAP system.
Not Indirect Static Read Actions (Disallowed)
“An individual (not licensed to access SAP ERP) adds information to a predefined query, specifying a particular attribute to be included in such query, which was created by an individual licensed to access SAP ERP, which was set-up to run on an automated, regular basis.
Data stored in the SAP system is transferred to a 3rd-party planning and consolidation application prior to an employee viewing and processing the data in the 3rd-party application
An employee of SAP’s customer accesses a 3rd-party application to sort data that was transferred from an SAP application prior to the employee accessing the 3rd -party tool and this employee subsequently initiates a transaction within the 3rd -party application which in turn triggers the updating of information in an SAP Application
Customers of SAP’s customer or a sales associate of SAP’s customer accesses a custom portal which is built on and is operating on the SAP Cloud Platform, where information such as product inventory or customer data which originated in an SAP ECC and/or SAP S/4HANA system was transmitted from SAP in direct response to the inquiry from such individual
An employee of SAP’s customer accesses a 3rd-party application to view a report which has been downloaded from SAP Business Warehouse
An employee of SAP’s customer views his customer’s order status in 3rd party application, where such information originated in SAP ERP and was loaded from SAP in direct response to the customer’s inquiry
A sales associate of SAP’s customer checks inventory status of several products in a custom-built inventory system where such information originated in SAP ERP and was downloaded from SAP ERP in direct response to the inquiry.”
What this means is that anything but passively reviewing SAP information is indirect access.
In fact, even adjusting a query is indirect access, which means that companies that use external reporting applications, not from SAP, can easily run afoul of SAP’s rules and regulations on indirect access.
Frequently Asked Questions
Order-to-Cash (O2C) and Procure-to-Pay (P2P)
“If the customer is properly licensed for these scenarios today, does he / she need to do anything? No, customers properly licensed today do not need to do anything.”
Right, of course. This is actually another propagandistic statement. Being properly licensed means, according to SAP, that you agree with SAP’s application of Type 2 indirect access. SAP will beat this horse until it is absolutely dead and until no one questions the assumption. SAP repeatedly does this in its literature, but its literature on indirect access may be one of the most extreme examples.
“Can existing customers purchase more of the same if they have previously licensed Orders to cover consumer scenarios and envision increase in order volumes? There is no change to SAP’s practice of allowing existing customers to license “more of the same”.”
SAP needs to work on writing more clearly because this is the type of sentence you have to guess as to its meaning.
“How is indirect Use addressed when SAP cloud applications are used in conjunction with SAP on premise ERP (ECC or S/4 HANA) systems? Properly licensed individuals using an SAP cloud application (e.g. SAP SuccessFactors, SAP Ariba, etc.) connected to a properly licensed SAP ERP system, can generally access such ERP system to the extent necessary to operationalize the SAP cloud application without any additional ERP licenses.”
Why did SAP feel the need to point this out?
Conflating Cloud with Indirect Access
This is a pattern on the part of SAP to conflate the cloud with indirect access. SAP has conflated the two, and ASUG (a surrogate of SAP) has also done this. The two things have nothing to do with each other. SAP had all kinds of applications connecting to it (or in SAP’s vernacular, engaging in scurrilous indirect access violations) when SAP was first introduced in a major way in 1980 before anyone had ever heard of SaaS.
“How are indirect access scenarios that utilize EDI for receiving orders licensed? Going forward, such scenarios will be licensed via orders triggered through EDI. However, if a different approach was used in the past, SAP will not require customers to change the approach or re-open this discussion.”
SAP wants to be paid for each EDI message now into SAP.
“How are indirect access scenarios that utilize SAP Exchange Infrastructure (XI), SAP Process Integration (PI), or SAP Process Orchestration (PO) licensed? The license for XI, PI, or PO covers the various integration scenarios and not the underlying value provided by ERP. Indirect access of ERP via XI, PI, or PO, if it occurs, still needs to be licensed.”
That would be consistent with everything else SAP has said. This was, by the way, the argument presented by Diageo to defend itself against SAP’s claims. However, this is a highly illogical argument. Whether an SAP integration application is used to connect to SAP is not the issue.
Indirect Static Read
“Must a current contract be amended for a customer to take advantage of Indirect Static Read use rights? SAP intends to apply its Indirect Static Read policy to customers even if the contract does not include Indirect Static Read language.”
Right. But why is that legal? SAP will enforce a term that is not in the contract because the static read is not any contracts. But they will enforce it anyway. Sure, that makes sense. Customers should be able to push back on this for rather obvious reasons.
SAP will enforce a term that is not in the contract because the static read is not in any contracts. But they will enforce it anyway. Sure, that makes sense. Customers should be able to push back on this for rather obvious reasons.
“If a customer has previously licensed Named Users for what is now defined as Indirect Static Read scenario, what are his / her options going forward? If such Named Users are not needed for other scenarios, customers can leverage SAP’s existing extension policies to replace the associated maintenance payments with either (1) a cloud solution purchase or (2) an on-premise solution purchase.”
Horse Trading for Licenses
That is the desired outcome for all indirect access claims made by SAP. SAP will horse trade for licenses. Particularly for licenses that Wall Street wants to see SAP sell, including HANA and S/4HANA.
“Above you note that Indirect Static Read scenarios are applicable in the context of data exported out of ERP or any non-analytics package from SAP. Does this imply that anyone viewing data in a 3rd-party application that was exported from an SAP Analytics package requires an SAP license? Indirect Static Read requires appropriate analytics package licenses, if the data is exported out of SAP Analytics package (e.g BOBJ) given the value add of organizing data in an intelligent and easy-to-consume manner, which is provided by such analytics solutions. However, the individuals participating in such scenarios do not need to be additionally licensed to use SAP ERP.”
This paragraph is lunacy.
SAP is confusing customers because its entire claim regarding Type 2 indirect access has nothing to do with “value add.” But this paragraph does communicate that you can export data using an SAP analytics application (but apparently, not ECC, if the logic follows) and use it in, say, Excel without being charged. But this brings up the question of SAP’s charge for export from a non-SAP application. This is another very bad sign for customers.
This paragraph is a very bad sign for customers.
Conclusion
This is yet another in what has become a pattern of deceptive articles about indirect access emanating from SAP and ASUG. The white paper is negotiating propaganda put out as something to “educate” customers. It desires the customer to accept several false assumptions to allow SAP to better leverage indirect access into SAP’s financial advantage.
Software vendors that compete with SAP should be put on high alert by this white paper. SAP is clearly intent on pushing its customers very hard on indirect access and in excluding other vendors as aggressively as they can. Vendors that compete with SAP should begin collaboratively doing things to thwart SAP. SAP’s type 2 indirect access claims and the Byzantine logic justify indirect access are becoming more and more extreme.
The Problem: Secrecy Around Indirect Access
Oracle, SAP, and their consulting partners, ASUG, and the IT media entities all have something in common. They don’t want indirect access understood. Media outlets like Diginomica are paid to distribute PR releases as articles, as we covered in the article SAP’s Recycled Indirect Access Damage Control for 2018. The intent is to lower SAP customers’ concern around indirect access so that indirect access is underestimated, as we covered in the article The Danger in Underestimating SAP Indirect Access.
The primary providers of information in the SAP space are all financially linked to SAP. SAP does not want indirect access understood, so these entities do as they are told by SAP.