Indirect Assault – What’s Your Exposure to SAP’s Indirect Use Rights?


UpperEdge deemed it critical to post this SAP customer alert on “indirect access” given what we have observed from SAP this past quarter and how we expect SAP to act in 2012. For those unfamiliar, “indirect access” scenarios occur when your employees and business partners (who are not licensed as named users) access SAP software via a third party application interfaced to SAP. SAP defines access by use, and if you check the fine print of your license agreement, you will note the intentionally broad and all-encompassing definition included.  SAP’s standard definition looks like this, “Use means to activate the processing capabilities of the Software, load, execute, access, employ the Software, or display information resulting from such capabilities.” In hindsight, most of you are likely thinking “did we really agree to such a broad definition?” Don’t beat yourself up too much; you are in the 99th percentile who thought it seemed harmless at the time.

In the past, SAP was likely to turn a blind eye to its customers’ potential “indirect access” situations.  In other situations, the issue was raised but ultimately a waiver or exception was provided.  This is no longer the case. Meet the new SAP. SAP has become much more rigorous in auditing and enforcing indirect access violations, charging customers millions of dollars in license and support fees for compliance.

The concept of indirect access has been around for quite some time. In fact, it has been somewhat of a Trojan Horse revenue stream for SAP, carefully planted in each software license agreement to be called upon when deemed appropriate. SAP is not the only software vendor to employ this subtle, passive aggressive approach to deriving additional license fees from its customers. In our opinion, the entire software industry needs to be more proactive in making its customers aware of the downstream implications of integrating and broadening the use of their application portfolios. We are singling out SAP in this alert, however, because their predatory behavior is a recent development and we do not want SAP to catch your organization off guard.

Because “indirect access” scenarios have gone relatively unchecked for so long, SAP customers have been internally and externally motivated to integrate and extend applications to create additional collaborative use scenarios with their business partners (suppliers, distributors, customers) and other non-core SAP users.  This is logical, but the downstream cost implications for unaware SAP customers who continue to build out and expand in this manner have grown more serious as SAP has become more aggressive in identifying and enforcing perceived indirect access non-compliance. From SAP’s perspective, any individual or machine that accesses the computing capabilities of the SAP software must be a licensed user. SAP’s logic is simple.  When customers extend their integration of SAP, additional users are gaining access to the software which equates to enhanced or extended solution value.  Because of this, SAP feels entitled to audit such usage and charge additional fees. However, SAP’s logic fails to consider just how limited or indirect the use – a deficiency in UpperEdge’s opinion.

When “indirect access” has been raised, the discussions have been quite contentious. Several of SAP’s customers have described SAP’s behavior as predatory because SAP never proactively made them aware of the concept of indirect access and its implications. Unfortunately for many of these unaware SAP customers, they found themselves in an unbudgeted, quarter end ambush with a prescribed deadline for reaching compliance.  As you can imagine, the longer “indirect access” scenarios have to proliferate and grow out of control in the environment, the more complex and costly the resolution.  Furthermore, resolution must be handled delicately, otherwise, SAP customers run the risk of establishing a more explicit and costly precedent moving forward.

If the concept of “indirect access” strikes a chord with your organization, UpperEdge recommends the following:

  • Determine your Ambush Profile:  Evaluate your overall license spend with SAP since the inception of the relationship and most importantly your license spend with SAP over the past 3 years.  Quantify your annual maintenance spend.  Do you fall under Product Support for Large Enterprises (PSLE)?  Your ambush profile is directly tied to SAP’s “what have you done for me lately” mentality.  The greater your recent activity and spend with SAP, the lower your ambush profile.
  • Read Your Software License Agreement and Solicit Advice from an Expert:  Read the “Definitions” ,“License Grant” and “Verification” sections of your SAP Software License Agreement in detail and consult with a third-party expert who can advise you on potential areas where you are exposed to risk.  We also recommend you consult with in-house counsel.
  • Assess Your Application Environment: Now that you have an understanding of the scope and applicability of “indirect access”, assess your overall application landscape to identify current and downstream business partner collaboration, interfaces to non-SAP applications, or other intermediary systems where you may be at risk of non-compliance.
  • Quantify and Understand the Potential Impact: Work with a third-party advisor to understand how SAP would approach the potential “indirect access” scenarios you identified in the previous step (i.e. types of named users and additional Package licenses required). Utilize SAP list prices and whatever discount and price hold options that are still current in your agreement to put a price tag on the potential impact.
  • Socialize the Potential Impact with the Business: Communicate the potential impact to your IT leadership and business base of SAP users so they are fully aware. The business base tends to be the community of users that SAP targets most frequently to expand the ecosystem of solutions.  Conversations on extending the SAP environment are always focused on business value potential and rarely highlight the downstream implications of “indirect use”.
  • Design a Plan to Mitigate Downstream Exposure: Assess the current state of the relationship with SAP, determine potential technical workarounds, and identify optimal points of leverage for tackling the issue. Designing an effective mitigation plan for “indirect use” requires a delicate and well thought out approach. Challenging the issue with SAP head on without a plan and without understanding your options is never a good strategy. You need to know your leverage points in order to effectively negotiate with SAP.  Trust me, they know their leverage points before they contact you, you need to know yours.

Also, please check out our press release, officially launching our SAP Software Audit Advisory Practice.

Leave a Comment

*

  1. Jim Davignon

    January 10, 2012

    Excellent piece Dave. Very true spoken from someone who has had to sometimes make an SAP quarterly number based on this. Oracle practically taught us this back in the late 90’s.

    Reply