Indirect Access violations occur when an SAP licensee breaches SAP’s definition of appropriate “use.” The most challenging aspect to 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.
SAP is no longer nipping at its customers’ heels on the issue of Indirect Access and instead is shocking some of its loyal customers by going for the jugular. Through our customers, we have observed SAP uses Indirect Access violations as an excuse for predatorily squeezing fees from their customers, and worse, seizing the opportunity to reduce flexibility and promote an anti-competitive environment.
The concept of Indirect Access deserves your attention because it can expose both old and new SAP customers to substantial incremental fees. In fact, customers who feel quite comfortable given their long-standing relationship with SAP may be at greatest risk because their landscape of perceived unlicensed users may be the least pruned, thus exposing them to a compliance ambush.
Net new customers are also affected by SAP’s aggressive business practices. Although they can educate themselves about SAP’s behavior and negotiate accordingly from the get-go, SAP’s definition of how their software cannot be used will handcuff even its new, informed customers into agreements which expose their company and include ludicrous restrictions on data extraction.
Is SAP justified in seeking repayment for perceived violations of its license agreements?
According to SAP, the concept of Indirect Access falls under a special licensing scenario whereby license requirements are based upon utilization of the software without regard for the technical interface that is used to access functions and/or data. 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. However, this is not where SAP’s definition stops.
Where is SAP going overboard with Indirect Access?
SAP’s use of Indirect Access scenarios as a means for identifying customer non-compliance is primarily excessive in terms of its broad-reaching definition of “use” and its data extraction and workaround restrictions within its standard license agreement.
When a licensed user pulls its own business data from an SAP system, one would think that SAP’s IP was unaffected. However, although any IP associated with producing business data via a specific SAP process is paid for and in compliance within the license agreement, SAP is now expecting only SAP processes to be used to extract a customer’s data from SAP’s system to another non-SAP system. It is requiring additional licenses for its customers to extract their own data. We have even seen SAP demand back payment from its customers who have reasonably built integrated environments with non-SAP systems. These data restrictions, coupled with increased Indirect Access policing, can be perceived as impediments to fair competition.
Customers pay for SAP user licenses to create the data in the first place. Thus, SAP’s customers should reserve the right to access their own data via non-SAP processes for their own use. This does not infringe upon SAP’s processes or their IP. If customers do not intend to give SAP exclusive rights over their data when signing on with SAP, they need to review their landscape carefully and plan how to manage SAP if they are audited. It is critical that new customers are careful during the negotiation stage to ensure this language is not included in their agreement. As we discussed in an earlier post, SAP’s broad definition of use was allowed to sneak by in most customer contracts. SAP lulled its customers into thinking it was harmless; however, the following examples demonstrate otherwise.
Common scenarios SAP considers to be Indirect Access use:
- A third-party software package extracts transactional and master data from SAP’s Business Warehouse which then allows the customer to slice and dice the data from an analysis standpoint. The data does not update SAP after the “slice and dice” has been performed. Customer orders are subsequently entered into SAP via a non-SAP application which previously captured all of the order information. SAP considers this use via Indirect Access because the non-SAP application users are activating the processing capabilities of the SAP software. In this case, SAP would require named user licenses for all of the non-SAP application users interfaced to the SAP software as well as licensing of the SAP Sales and Service Order Processing package for orders generated by users without a named user license.
- An SAP customer publishes an order to one of its suppliers through a non-SAP application whereby a request then comes back to SAP to check a credit limit or inventory level. In this scenario, when data goes out of SAP and then back into SAP via a non-SAP application, SAP considers this use by way of Indirect Access.
- A member of your sales team is conducting a call with one of your customers who asks for a prior purchase history. Your salesperson requests this information using Salesforce.com which then reaches out to SAP to get the information. From SAP’s perspective, Salesforce is acting more as an intermediary system, while SAP retrieved the information through the activation of its processing capabilities. In this scenario, SAP requires the salesperson to also have an SAP user license.
- A member of your engineering team is using a third-party engineering application for some product design work but needs to obtain additional engineering data out of SAP to complete the work. By now, it should not surprise you that SAP constitutes this Indirect Access as use, and therefore, your engineer would also require an SAP user license.
Every SAP customer has at least one of the above listed scenarios built into their current environment or perhaps planned in a future roadmap. If SAP is allowed to go unchecked, we expect it to be more fervent in its pursuit and enforcement of Indirect Access compliance scenarios as a way to generate additional license fees.
Why is SAP’s stance on Indirect Access a concern?
SAP customers should be highly concerned with its continued expansion of “use” through Indirect Access (especially in the context of increasingly interconnected environments and the move towards the Internet of Things) because there is no real transparency on the issue in the marketplace and the overall impact for ill-informed/unprepared SAP customers can be enormous.
What should SAP customers do?
Indirect Access is an issue CIOs simply cannot afford to ignore. The primary challenge for SAP customers who are faced with a letter claiming non-compliance due to an Indirect Access scenario lies in the ambiguity of the definition of “use” within the agreement. Although SAP has started to clarify the concept of Indirect Use at an agreement level for its more recent customers (provided SAP is pushed to do so via the appropriate negotiation strategy), a majority of agreements remain broad and vague relative to Indirect Access as a means of use. As written, the definition of “use” can basically be any scenario that activates the processing capabilities of the SAP software.
If you recently received a letter from SAP’s Office of License Compliance claiming Indirect Access, take a look at our key initial steps for successfully reacting to the SAP audit notification.
To assess whether your organization is at risk of Indirect Access claims by SAP, use our SAP Indirect Access Risk Assessment Tool.
- What SAP’s Indirect Access White Paper Said and Didn’t Say
- Software Audits Continue to Rise: Understand the Software Vendor’s Audit Playbook
- Will SAP Competitors Fight the Indirect Access Madness?
- The Underlying Implications of SAP’s New Indirect Access Order Licensing Policy
- How CIOs Are Converting SAP Underutilization into Savings