5 things you need to know about SAP’s Indirect Access
If your organization was audited right now, would you be prepared to go head to head with SAP on a £54 million Indirect Access lawsuit? London-based Diageo was sued by SAP and lost. Although the final sum to be paid has not been decided yet, this sets precedence for future lawsuits involving Indirect Access. Like Diageo, there are many more SAP customers whose SAP deployments may involve Indirect Access usage and are therefore at risk of additional license and maintenance fees.
The purpose of this article is to explain what Indirect Access is, discuss what causes it, provide common scenarios for its occurrence, and suggest how to identify and avoid it.
1. What is Indirect Access?
Indirect Access is the term used to define the situation in which an SAP customer is liable for purchasing additional licenses or paying fines for “using” the software without having first acquired the appropriate licenses. Typically, this happens when a customer fails to purchase licenses for users accessing the SAP software system indirectly via a third party or custom interface.
2. What Causes Indirect Access?
When you purchase SAP licenses, you don’t really own the software. You are only allowed to use the software in certain ways. To understand what causes Indirect Access and how it becomes a problem, it is important to understand how SAP defines “Software Use”.
In our experience, SAP’s definition of “Software Use” varies across customer contracts. The most common definition, as found in SAP’s System Measurement Guide, explains “Use” as a “means to activate the processing capabilities of the software, load, execute, access, employ the software, or display information resulting from such capabilities." This definition is so broad and ambiguous that knowing exactly what constitutes Indirect Access (and what does not) can be challenging, especially in scenarios where SAP interfaces with other applications. This vague language creates room for interpretation and could be used advantageously by either SAP or the customer to justify (or refute) any claims of Indirect Access, presenting unnecessary risk and putting both parties in a vulnerable situation.
These definitions were written many years ago and technology has changed significantly since then. Business processes are changing rapidly to take advantage of once-innovative technologies now becoming ubiquitous, such as web portals, mobile devices, and IoT. These technologies interface with SAP in different ways than traditional enterprise systems. There is an increasing number of applications being coupled together to solve business issues, and necessitating the sharing of information. While such applications are being added by SAP customers, there is a lack of attention given to whether the current SAP license agreement allows it. This is the primary reason for the increase in the number of Indirect Access cases in recent years.
Another aspect to be considered is that SAP’s software is partially based on “Named User” licensure, meaning only the individual assigned to a license has the legal right to access the software. While this model is fairly common, SAP’s definition of “Named User” presents some potential challenges.
According to the SAP portal, a “Named User” is defined as an “employee of the customer, its affiliates, or of a third-party company authorized to access, directly or indirectly, the licensed software, independent of the technical interface chosen. Named users are also technical systems that exchange information with the SAP system, and their users." Under this definition, accessing the software directly or indirectly requires a named user license.
The exact language used in each customer contract agreement varies widely and can greatly affect the overall susceptibility to Indirect Access claims. For example, some contracts may permit non-named users to access the SAP system in certain business to consumer (B2C) scenarios without the risk of Indirect Access. On the other hand, some contracts may not be sufficiently clear whether a business partner or a customer may access the SAP system without their own license.
In essence, Indirect Access is influenced by the language contained in each individual contract and is most often caused when the definitions of “Use” and “Named User” are unclear or misunderstood.
3. What Are Some Common Scenarios for Indirect Access?
Here are a few situations where the risks of Indirect Access are high:
- Web-Based Storefront: A handheld iOS or Android device used to track goods movement and transfer postings which are updated into SAP in real-time
- Handheld / IoT Devices: Handheld mobile devices, or IoT devices like Google home or Alexa that can be used to automate the task of updating data into SAP in real-time. For example, using a mobile device to track goods movement and transfer postings, or a sales representative using a handheld device to place orders for customers.
- CRM/SRM Applications: Third party CRM applications which access SAP to provide information to their users. For example, a supplier remotely checking stock level for raw material, and automatically sending shipments when stock level is low.
We have found that customers with a higher probability of being reviewed by SAP for Indirect Access are those who have not had any recent purchases, undergone M&A activities, implemented competing solutions to those offered by SAP, and/or undergone significant architectural changes that may have affected their SAP architecture.
4. How Are Indirect Access Risks identified?
When an application exchanges information to and from SAP using some common communication medium, it is said to be “interfaced” with SAP. To identify Indirect Access risks, it is important to inspect every application that interfaces with SAP and assess whether the business process requires an unlicensed user to “Use” the SAP software system. Here are some recommendations to help identify Indirect Access risks:
Understand the Contract
Start by checking the definitions of “Use” and “Named Users” within your contract. Make sure to understand all the implications of the language as it pertains to your own business scenarios.
Despite any language differences found in SAP’s general terms and conditions or online versions of SAP’s measurement guide, the language regarding Indirect Access within your own signed contract supersedes everything else.
Review Your Application Architecture
Map all the applications within your Architecture. To do this properly, you must understand the flow of data between the interfacing applications and SAP. You will need to know if data is only being pulled from SAP (read only) or whether updates to SAP are being made as well. Creating a technical architecture diagram can better help you visualize the interfaces.
Understand the Business Process
Get a clear understanding of the purpose of implementing each application in the architecture, and its related business processes. The more critical a business process is to the daily operations of the organization, the more likely it is to be scrutinized. SAP is also likely to pursue customers with a new business process that directs revenue away from SAP and towards third party vendors.
Be Cautious with Interfaces
Interfaces that have a real-time information exchange have a higher potential for Indirect Access, but the level of risk depends on the type of data being exchanged. For example, interfaces which require a fairly quick response after sending a request have a higher level of risk than periodically timed batch processes or file transfers.
Typically, RFC connections (used for the real-time information transfer) and iDocs (used for exchanging documents) have a higher risk of Indirect Access. However, the frequency or method of data exchange does not matter as much as the underlying business process supported by the interface.
Identifying Indirect Access risks is challenging for both SAP and its customers due to licensing complexities and the customer’s business processes and customizations.
5. How to Avoid Indirect Access Problems
Knowing how to identify Indirect Access is the first step to mitigating its risk. Here are a few additional tips on how to mitigate risks you have identified:
Review Your Contract: Go through your contract looking for any language that enables you to complement your architecture. There is a chance that Indirect Access risk was discussed during your contract negotiations and mitigated in the contract. Check for use rights that allow B2B and B2C users to access SAP without requiring the purchase of any additional named user licenses. Avoid signing new order forms containing web links to new software use rights that supersede your older and more advantageous use rights.
Negotiate a Solution: If necessary, reach out to SAP to clarify uncertainties and try to negotiate an extended contract that covers your needs. Here are some ways in which you can work to resolve Indirect Access situations.
- Add specific and detailed language to the contract that explains how SAP software will interact with other applications, then negotiate to have such use cases excluded from having any Indirect Access liability.
- Negotiate a special low-cost license type for external users performing minimalistic activities in SAP.
- Consider replacing the named user license model entirely to a revenue or volume based model.
- Include clauses in your individual license agreements that give you leverage to use your own data from the SAP system more freely, even though it was processed by the SAP software.
Leverage New Purchases: SAP may be more flexible and easy to work with if there is potential for new SAP software purchases. Purchases of new technologies like HANA and cloud subscriptions will provide more leverage when negotiating.
Conclusion
Understanding what causes Indirect Access and how to avoid it will help you mitigate the risks of paying expensive licensing fees or getting pulled into long drawn-out legal disputes, like the Diageo lawsuit. —— Contact Anglepoint today for more information about how our team of SAP experts and architects can help you avoid Indirect Access problems and safeguard your SAP architecture. SAP@Anglepoint.com *This article represents Anglepoint’s opinion and is based on the experience of our SAP experts.