Category Archives for "Indirect Access"

Analysis of Snow Software on SAM + SAP Square Peg Article

What This Article Covers

  • Article Quotations
  • As SAP Landscapes and Licenses Have Become More Complex
  • SAP Specific Issues for SAM
  • The Deploy Phase of SAM
  • High Effort Required to Manage SAP Licenses


In 2016 Snow Software published the white paper SAM + SAP How Does the Square Peg Fit in the Round Hole?

In this article, we will analyze Snow Software’s white paper.

Article Quotations

As SAP Landscapes and Licenses Have Become More Complex

All around the world, enterprises are realizing that SAP’s growing offering of application software is they must employ Software Asset Management consuming an ever larger share of the enterprise IT(SAM) to assure compliance, improve procurement budget.

But what about SAP? Enterprises running SAP are now looking to SAM to help them better manage their usage and costs. Starting with their dominant position in Enterprise Resource Planning (ERP), SAP’s growing offering of application software is consuming an ever larger share of the enterprise IT budget. In fact, in the last decade, SAP customers have experienced double-digit increases in their annual costs through increased maintenance and licensing charges. In addition, over the past 10 years with Sarbanes-Oxley (SOX) and ISO/IEC 19770-1, managing IT and software assets has become critically important. Since SAP’s deployments are complex, understanding and managing SAP contracts, deployments and license usage can be challenging. Now, it is absolutely essential.

SAP’s footprint has become increasingly complicated in companies. SAP has also grabbed more and more of the IT spend. And, SAP’s support fees are continually increasing. They have moved from 15% to a minimum of 22% of the license price. SAP is increasingly looking to harvest its current account base and is one of the most difficult vendors to negotiate with.

SAM software is greatly underutilized.

SAP Specific Issues for SAM

For those who want to integrate SAP licenses with their Software Asset Management (SAM) best practices, there are challenges that must be overcome. Some consider this analogous to putting a square peg into a round hole. While it may not be as impossible as that, integrating SAP licenses into a SAM program must combine processes with powerful software tools to assist in discovery, metering, compliance, optimization and retirement/recycling. Several key considerations regarding SAP licensing from a SAM perspective are:

  • No support for Software ID Tags: As a result, inventory control and management is more challenging. SWID Tags are part of the ISO 19770 standards (ISO 19770-2 and 19770-3) and supported by vendors such as Microsoft, Adobe and Symantec. With SAP, each license is associated with a named user which can be used to identify and manage that license throughout the life cycle. Conventions and standards for the allocation of users and their names must be standardized. Discovery software is necessary to develop a SAM baseline of licenses that have been issued and deployed.
  • Different License Types: License types such as Professional, Limited Professional, Developer and Employee Self-Service have no clear-cut delineation between them. As a result, assessing compliance is difficult and puts enterprises at the mercy of SAP’s annual audit process. Software for metering of user-activity is needed to assure compliance and “best-fit” the license types through actual usage patterns.

  • Indirect Usage Fees: An increasing concern for SAP deployments, indirect usage fees are challenging to identify, assess and control. When 3rd party applications provide access to SAP data through the SAP application programming interface (API), an annual charge is applied. It’s critical for enterprises to track the level of activity and the financial exposure of these indirect license costs, which can come from B2B or mobile applications that are connecting to the backend SAP ERP system.

  • Challenge of Recycling SAP User Licenses: When an employee leaves a firm, that person’s license remains in use even though it may be marked “inactive” to prevent access to the system. Identifying duplicate, erroneous and obsolete user licenses requires sophisticated software tools that automate what can be a complicated, six-step process to recycle the license for future use.

SAP follows an approach of making license management as difficult as possible in order to gain the upper hand. The case of indirect access is a perfect example of how SAP keeps things deliberately opaque….when it benefits SAP to do so.

The Deploy Phase of SAM

  • Proper License Type for Each SAP User: Make sure the license supports the capabilities of each user. Compliance must be balanced against over licensing monthly self-audits of SAP license activity should be which can result in a 10X to 20X difference in price per carried out to best understand how the enterprise will license. Using powerful software, metering of the exact fare on an upcoming vendor audit. Usage optimization usage is the best way to “right-size” the license type. should be carried out to assess potential over-licensing from redundant, obsolete and erroneous users.
  • Indirect Usage: It’s a potentially explosive expense that must be understood and managed in the SAM context. SAP generally has a very novel provision in each of its contracts which says, “if a third party application uses the SAP system to access data, then an indirect user license is required for each user”. This can apply to mobile, B2B and B2C e-commerce applications, as well as internal portals and even point-of-sale (POS) systems. The Manage phase of an SAP deployment under SAM should involve a constant monitoring of both contractual activity and usage activity to assure the two are in balance. With automated software tools, monthly self-audits of SAP license activity should be carried out to best understand how the enterprise will fare on an upcoming vendor audit. Usage optimization should be carried out to assess potential over-licensing from redundant, obsolete and erroneous users. Metering should occur to assure both license type/role compliance and the “right-sizing” of license types. Finally, the Retire/Recycle phase of the SAM process for SAP is very important from both a financial and compliance perspective. It is not unusual for up to 25% of all SAP licenses to be obsolete, duplicate or erroneous. Following usage optimization, SAP administrators can use software tools to retire these licenses and recycle them for subsequent use. This will likely liberate some acquisition costs for new SAP licenses since the inventory on-hand should reflect the available retired and recycled licenses.

And in addition, as now SAP has every type of connection to SAP except for something called static read as being indirect access. SAP will apply indirect access when the sales it is currently obtaining and plans to obtain from an account is less than its Expected Sales Target.

High Effort Required to Manage SAP Licenses

Understanding what SAP licenses have been contractually purchased across a global enterprise and over several decades can be challenging. The deployment of SAP systems across the enterprise can also be remarkably complex and difficult to understand. Powerful discovery tools such as the Snow SAP Optimizer can be configured to look across dozens or hundreds of SAP systems within the enterprise, and create a coherent, unified and comprehensive inventory of licenses authorized for use within the SAP system.

Yes…and deliberately so. The more complex and time-consuming SAP can make license management, the more they can take advantage of the situation.

A discovery tool should generate a comprehensive summary of what user licenses have been allocated across the inter-linked SAP servers in your system.

Using automated SAP discovery software can also be helpful in understanding the license allocation by both the SAP license types and the department or cost-code. This more detailed summary information is essential during the SAM procurement phase where the enterprise has full knowledge of (a) what it has already contractually purchased, (b) what licenses have been deployed and are active, and (c) what the real usage profit is for each license.

Right, this is what SAM software can provide.


This is a good quality article from Snow that brings up the knowledge level of the reader.


Sikka, Brian. SAM + SAP How Does the Square Peg Fit in the Round Hole? Snow Software.

Analysis of Snow Software on SAP’s LAW Transaction

What This Article Covers

  • Article Quotations
  • Who Was the Law Transaction Designed For?
  • Pretending LAW is SAM
  • How SAP Presents the LAW Transaction to Customers
  • SAP’s Self Centered Approach to “Compliance”
  • The Idea that SAP Offers Everything You Need – – Even the Software to Negotiate Against Them
  • SAM Being Designed for the Customer
  • How SAP Keeps the Licensing Information at an Aggregate Level
  • Indirect Access and Snow


Snow Software published the white paper SAP’s License Administration Workbench is NOT a Software Asset Management or License.

In this article, we will analyze Snow Software’s white paper.

Article Quotations

Who Was the Law Transaction Designed For?

C-Level management is increasingly scrutinizing the trajectory of spending on legacy platforms across the enterprise such as SAP. They are evaluating SAP licensing optimization and management tools, processes and solutions as a means to tackle the escalating costs.

We have LAW, which is free from SAP, why would we need another tool? are often the first words coming from the SAP Administration team. The problem with this response is that SAP’s LAW (License Administration Workbench) is a measurement and reporting tool, not an optimization tool. LAW makes plenty of assumptions that favor SAP, and provides almost no insight into the efficiency of the licensing assignments and deployment. As a self-audit tool, its primary purpose is to provide a foundation from which SAP evaluates the potential for an additional true-up of license sales annually.

True, LAW is for SAP’s use. Actually, SAP misrepresents what the LAW transaction is to customers in their online technical documentation in order to give customers the impression that LAW is for the customer, when in fact LAW is primarily for SAP.

Pretending LAW is SAM

SAP’s License Administration Workbench known as L-A-W is used as a tool to prepare audit data for SAP* to review. LAW collects and consolidates SAP license-relevant measurement data (users, engines, self-declaration products) for the component and central system.

System Administrators can get a more consolidated overview of the licenses provisioned and deployed. SAP uses LAW measurement data to bill customers when additional licensing is required. It’s important to note that LAW is NOT an optimization tool and does not indicate which users are inactive or over-licensed.

An SAP administrator at a large global enterprise commented recently that: LAW feeds SAP’s internal audit team of engineers, contract lawyers and salespeople with the data they need to escalate your charges every time.

That is a powerful assertion and one based as much on emotion as fact. But the passion does not belie the fact that SAP’s LAW tool and SAP-focused Software Asset Management/License Optimization solutions do very different things. Comparing the two is like comparing the proverbial apples and oranges.

This is all very much true. But SAP does not want its customers to know anything about this.

How SAP Presents the LAW Transaction to Customers

SAP describes its License Administration Workbench (LAW) with precision: The License Administration Workbench (LAW) is a tool for the central consolidation of license audit data and supports you in the SAP license audit process for complex system landscapes. In particular, the LAW simplifies the classification, combination, and consolidation of data for users that work in multiple systems and clients.

As you can see, SAP itself has never tried to position LAW as anything other than a tool to aggregate audit data for contract compliance.

I see it a bit differently. It looks like SAP intends to obscure who the LAW is there to serve. If you read the SAP text, it makes it seem as if LAW is for the customer. It is actually natural for the customer to come to that conclusion. That is why the next comment is not at all surprising.

However, in meetings between CFOs, CIOs and SAP administrators, you will often hear SAP administrators say something along these lines: We have the SAP LAW tool to manage our SAP users, engines and license types, so we don’t need a Software Asset Management/License Optimization solution.
Does this assertion stand up to the facts?

Exactly. The explanation of LAW by SAP leads SAP customers to do exactly what SAP wants them to do, which is to not investigate SAM tools.

The SAP contract expressly requires the customer to provide the LAW data as part of the audit process. In most cases, if the company is unable to provide this data, it will permit SAP to connect to its SAP systems to collect the data.

That is not a good idea. Companies don’t want SAP anywhere near its systems. This is the problem with Solution Manager as well. Solution Manager, if setup correctly to do so, allows SAP to monitor your system.

SAP’s Self Centered Approach to “Compliance”

We do not dispute that SAP’s LAW is used to help monitor compliance. If the company has users out of compliance, SAP will detect this and come up with a renegotiated set of fees for the company to bring itself back into compliance with its contract.

Which will in 100% of cases be highly SAP centric with SAP taking maximum advantage of any customer that does not offer resistance.

But what the LAW tool does not do is provide data for the purpose of optimizing the number of named SAP users, optimizing access and use of engines in a deployment, or optimizing the roles and license types assigned to users.

LAW does not provide information to the customer that they need to use against SAP. That is by design.

SAP’s LAW is classified as an audit compliance tool and serves that exact purpose.

As I said, I don’t see that SAP is being clear about what LAW is really designed for.

The Idea that SAP Offers Everything You Need — Even the Software to Negotiate Against Them

The data collected and painstakingly merged is used by SAP’s internal audit team to determine the company’s compliance with its existing contracts and to set out the best strategy moving forward to optimize additional revenue from the customer. In this respect, the emotional outburst from the SAP administrator quoted in the introduction is a fair reflection of the truth.

Right. But also, there is something else at play.

This issue extends out to software far beyond SAM. IT departments that use SAP have a very strong bias against non SAP tools. The idea is that even if the SAP tool that is offered lacks what the other tool has, one should always go with SAP. I have dealt with this sentiment repeatedly in my consulting experience.

More than half of SAP’s annual revenue and more than 75% of its profits come from its installed base of customers and the annual maintenance fees flowing from those contracts. SAP, not unlike any other software vendor, has a clear purpose for the audit data provided by the LAW.

SAP is increasingly relying upon its support revenue because it is selling less of its core products. In a word, it is saturated in its customers, and many emerging areas in IT, like IoT and Big Data have little to do with SAP or ERP systems generally.

SAM Being Designed for the Customer

The SAP user and usage data collected by the Snow Optimizer for SAP Software is substantially more comprehensive than the systems measurement data displayed by SAP’s LAW tool and can provide a substantially better picture of what usage is really happening across the company.

SAM software, unlike the LAW transaction, is actually designed for the customer.

How SAP Keeps the Licensing Information at an Aggregate Level

The License Administration Workbench does not provide a way to distinguish between a named user that logged into the system last week or two years ago, and is only focused on gathering (not analyzing or optimizing) audit-related data for future billing.

SAP does not want customers optimizing its use of licenses.

SAP’s LAW software can consolidate licenses across multiple SAP systems into a consolidated view based on the logon name and a number of other fields. By default, it aggregates user licenses by the logon name. LAW does this for audit purposes and does not provide any detailed information or analysis to isolate, detect or correct unintended duplicate users in the system.

In this case, a higher level of aggregation suits SAP, so that is what LAW provides.

Duplicate users involve one actual user having more than one unique named SAP user login. There may be valid reasons why a user has been assigned multiple SAP licenses, but in many cases, this was not the original intent.

A simple example is if a woman changes her last name after marriage and is assigned a new SAP login name. Care must be taken to consolidate these two user names into one by ultimately retiring the original one.

Again, there will be a major difference in the design of software if it is designed for the vendor to maximize their license draw from the account, versus designed for the customer and designed to minimize this draw. However, Snow’s examples here repeatedly show that the more detailed information provided by SAM software is actually more accurate.

Indirect Access and Snow

SAP’s LAW tool captures usage data which is analyzed by the SAP Audit team to determine if there is potentially indirect access activity occurring and if the enterprise is properly licensed for such activity. In most cases, the enterprise is not, and SAP will push for additional indirect license purchases which can add up to a meaningful cost.

The Snow Optimizer for SAP software collects the same usage data, and also looks to isolate potential indirect access violations. The difference is that with Snow Optimizer for SAP Software the company can (a) determine the exact source of the indirect access violation, and (b) be aware of it in advance of SAP and correct it ahead of the audit.

Brightwork publishes the most information on SAP indirect access. And indirect access is something that SAP (in our view) plans to increase in the future. Therefore, this functionality described by Snow is more important than ever.

The company may take licensing or programming action to address the compliance issues in advance of an on-site SAP visit. Companies should develop an architectural diagram of all applications and portals connecting to SAP that documents the inter-connection, the direction of the flow of information, and the number and type of users of the application.

Quite true.


This is a good quality article from Snow that brings up the knowledge level of the reader.


SAP’s License Administration Workbench is NOT a Software Asset Management or License, Snow Software.

Analysis of Snow Software on Determining SAP Indirect Access Exposure

What This Article Covers

  • Article Quotations
  • So What is Indirect Access?
  • SAP Add Ons
  • IoT and other Databases
  • Fee or No Fee?


In this article, we will analyze Snow Software’s article on whether it is possible to determine your internet access exposure.

Article Quotations

SAP licensing is complicated. License entitlements can be open to interpretation and contract amendments can mean that financial liability for one customer may be very different in comparison to another, even if their usage and requirements are identical. It often depends on what deal was struck at the time of purchase.

Traditionally SAP licensing reviews and system measurements have focused on direct usage of an organization’s SAP environment. Direct usage on an individual level describes one user accessing SAP data directly through the SAP interface. The transactions which they perform determine what license type (or types) the user should be assigned. This in turn determines the associated cost for that user to perform their required tasks within the SAP system.

Even correctly managing licensing of direct users is more complicated than it might first appear. An organization with 10,000 users of its SAP environment could have many groups of users who transact in very different ways. The users may change jobs and so need to use the SAP environment differently from one year to the next. Other users leave the organization and of course it’s no longer necessary to have a license assigned to them.

Very true. Actually, most of what SAM software does is actually manage direct user licenses.

If your organization’s doesn’t keep on top of this and effectively manage licenses, you’ll almost definitely be paying over the odds for your licenses or you will be hit with a big fee following system measurement (LAW) submission or a more comprehensive SAP audit.

And this is in fact very common as most SAP customers do not use SAM software.

The risk becomes even greater when you consider Indirect Usage. That’s because you may face licensing liability for a far greater number of users compared to those who you know directly access the SAP system. That 10,000 user license requirement could two, three, even four times more if a third-party application accesses your SAP data.

There are really two ways to look at this. One is that the type of indirect access most often enforced by SAP is called Type 2 indirect access. Brighwork has repeatedly questioned the validity of SAP’s creation of Type 2 indirect access.

The second way of looking at it is that SAP does enforce Type 2 indirect access, although it does not actually have the right to do this.

One thing is clear. The better prepared your organization is, the better you understand overall usage of your SAP environment from every user and the better you can map this to existing entitlements, the stronger you will be when it comes to an audit or a negotiation. To do this effectively, you need a system that can automatically consolidate all of the necessary data and automate the required tasks.

That is certainly true.

So What is Indirect Access?

A simple example of Indirect Usage is where an SAP system is accessed or queried through a third-party application. The way in which that third-party system interacts with the SAP system, whether the interaction originates from a users’ actions and whether data is manipulated or changed within the SAP system all contributes to whether SAP defines the need for an additional license and, therefore, additional cost.

If you had to read that sentence twice, you’re likely not to be the only one. The fundamental issue is that SAP “Indirect Usage” changes definition from company to company and that is causing confusion amongst the SAP user community.

And the answer as to why is that SAP selectively applies indirect access in order to maximize the revenue taken from its customers. In some cases, it is not in SAP’s sales interest to bring up the topic, in other cases, it is.

In a rather ironic twist of fate, the push from the large SAP user communities across the globe for more clarity on Indirect Usage has actually led to potentially greater financial exposure. That’s because SAP made changes to their enforcement of the price and conditions list (PCL) in October 2016. More on this below. Indirect Usage is categorized in a few different ways depending on the technical method used to access the SAP environment. To add to the opacity around this, there is also a greater or lesser likelihood that SAP will choose to charge additional license fees dependent on the “type” of Indirect Usage there is.

That may be true. It seems that whenever SAP releases more information on indirect access, it expands what its definition of indirect access is.

External Third Party Systems

Common examples of this type of Indirect Usage include large ISVs like, Workday and QlikView; Business Intelligence systems and payroll systems. This may also include smaller systems to perform a particular task not possible in default SAP software.

In this instance, the third party systems are accessing the SAP environment, pulling data and often writing it back via a connection to the SAP environment. Here a “user” must be set up to gain access to the SAP system. On the surface then it can appear like only one user (or a small number of users) is performing actions on the SAP system. In reality though, the “user” will be performing far more tasks than is possible for a single person to undertake.

Multiple users are indirectly using SAP data to perform tasks. The challenge that someone investigating this type of Indirect Usage often faces is that they are unaware of these third-party systems within their organization’s IT estate. To identify such systems requires either surveying application owners or looking for anomalous usage directly within the SAP system.

Once again, this is Type 2 indirect access. It is not historically what has been called indirect access.

Flags to look out for include:

#1: “Work time” check for all users: Checks rolling two-day time windows for constant activity without a pause of at least eight hours

#2: “Volume of work” check: Looks for users with an extraordinary amount of activity (measured by changed or newly created DB table entries)

#3: “Cross-component usage” check: Looks for users which changed DB table entries or newly created them from different SAP modules in the same second.

In practice, the interviewing process alone is insufficient and attempting to analyse the SAP system manually is impractical for a system with over a certain amount of users. This is because it requires manual consolidation of numerous data sources before any possible conclusions can be made.

The more efficient approach is to use a system which can automatically consolidate the data meaning that anomalous activity can be identified much faster.

This method of Indirect Usage is the clearest cut and we covered this in a lot more detail last year. If a system accesses SAP in such a way, you are likely to be financially liable. It’s extremely important to understand precisely how the interaction takes place, how may third-party users may require a license and what type of license they will require.

Yes, SAM software is one of the primary ways to determine the Type 2 indirect access that the customer is performing. Although this still may not provide the details of all the indirect access exposure.

SAP Add Ons

In October 2016, SAP made changes to their enforcement of the price and conditions list (PCL) with the intention of clarifying some of the definitions around SAP and based upon pressure from the various user groups across the globe. This is where the irony lies because it has, in fact, led to a new license requirement for third-party add-ons.

Within the PCL, SAP added that users, in addition to the Runtime usage right of the SAP NetWeaver Foundation, must acquire an additional SAP NetWeaver Foundation for Third Party Applications.

This means that users of a third-party system which is an add-on to SAP and installed via the NetWeaver platform must pay an additional license fee on top of their existing Named-User license.

So SAP charges double for NetWeaver? One to run SAP apps and one to run non-SAP apps. This double purchasing is very similar to SAP’s policy on HANA, which is covered in the article The HANA Police and Indirect Access Charges.

Many customers see this as a shift of the goalposts and it will be particularly frustrating to organizations who were recommended to develop customer-specific solutions into their landscape by SAP itself.

SAP has been constantly shifting the goalposts on the topic of indirect access. And this is something that my research indicates will continue in the foreseeable future.

Because this enforcement is new, many organizations will not be immediately exposed to financial liability and SAP typically takes a staggered approach to enforcing licensing rules.

The best advice and option would be not to rest easy because of the lag between rule creation and rule enforcement. Make sure that you understand what your potential liability might be. Consider whether there are named user licenses which are assigned to inactive users and making up shelfware. If there’s a potential for this shelfware to use a third-party add on, there may be a case for SAP to charge your organization the additional fee. If your shelfware is properly expired and retired, there is no risk. Again, an automated system which can do the leg work for you will ensure you are in a stronger, optimized position.

These are all very good points.

IoT and other Databases

The third and final category to consider is also the least well defined. However, it still absolutely should be taken into account. This category concerns “things” writing data to the SAP system. “Things” could mean sensors in a warehouse measuring temperature throughout the building and alerting when that temperature moves outside of defined parameters. It could mean data transferred from mining vehicles when they return to base, tracking usage of the vehicle and distance travelled to estimate when tyres need changing or when the truck must be serviced. In this real example, the customer wasn’t liable for any additional named user license because there is no human interaction. The data is transferred automatically when the vehicles cross a threshold.

On the other hand, a scenario where additional licenses were required was in a slightly different form of data exchange via Electronic Data Interchange or EDI. In this case, warehouse scanners were used to read data from barcodes into the SAP system. The difference was that humans click the button to read activate the scanner. The customer in this case was told that they needed named user licenses for each user who could potentially use the barcode scanner and hence “use” the SAP system.

The reason this requires drawing ludicrous distinctions is that SAP’s proposal on Type 2 indirect access makes no sense. If the scenario above means that SAP is owed indirect access fees, then all systems that connect to SAP also should receive indirect access fees as well.

”From a legal perspective, the issue of indirect usage and SAP’s respective license types is complicated as its assessment involves questions of contract law, copyright law and possibly also of competition law. What matters is that companies using SAP software are aware of the risk that is attached to indirect usage of the software.

In order to be able to evaluate such risks, technical tools that help to get an idea of the intensity of indirect usage helps. If a company believes that it has a high risk with regard to this issue and does not want to meet SAP’s additional payment request, an individual legal analysis may help to clear the picture.“

Fee or No Fee?

So that is the distinction. Involve a human user in some way and you may be asked to license that user. Remove any human interaction and you are unlikely to need to pay for additional licenses (at the time of writing). As in all of the examples above, however, this won’t stay the same forever and if your organization is embracing new technologies at a rapid rate, just remember that SAP might want a cut of the pie at some point down the line.

Again, the advice remains the same. Understand usage, understand the architecture of your environment and continually optimize. Do not let things change over time without tracking it. If you do, you could be faced with a substantial unbudgeted bill.


Snow Software has made a good effort in getting into the details and have provided some very good information in this article. There is a lot of detail in this article that does not appear to have been published elsewhere.

  • At Brightwork, our perspective on Type 2 indirect access enforcement by SAP is inconsistent with what all other software vendors do, and what has been the historical interpretation of indirect access.
  • It also is the case the indirect access is applied so differently by SAP based upon factors related to the sales situation at the customer, that it does not only come down to technically whether a customer meets the definition of Type 2 indirect access.


Analysis of SAP’s 2017 White Paper on Indirect Access

What This Article Covers

  • SAP’s Executive Summary
  • Background Information
  • New On Premise Licensing Policy for Common Indirect Use Scenarios
  • Order-to-Cash Scenario
  • New Policy for SAP ECC Customers
  • New Policy for SAP S/4HANA Enterprise Management Customers
  • Procure-to-Pay Scenario
  • New Policy for SAP ECC Customers
  • New Policy for SAP S/4HANA Enterprise Management Customers
  • Frequently Asked Questions


In this article, we will analyze SAP’s white paper on indirect access to measure its accuracy, as well as what the paper says about how SAP will enforce indirect access going forward.

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 are presenting 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 for the first time so many other systems are accessing or connecting to SAP.

That is not exactly what is being said, but it is implying many more connections to SAP. 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 (in order to be able to use it against customers). SAP’s intent of releasing new information about indirect access, which was done at SAPPHIRE 2017, as 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 replied that it would not publish any information and that everything would be on a case by case basis. Is that “modernizing” its licensing policies?

Secondly, what SAP is calling 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, and so they depend on customers to reach out to them and to willingly provide information, which SAP will frequently use against the customer.

This sounds like a “carrot” but in fact, it hides as “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. 

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 what is shown as “scenario 1” above, where an app is developed by the customer to bypass paying a user license — something which has historically been quite uncommon. Two 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

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 prior to 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 for 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 history of the software industry. 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 application, then 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.

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 may be persuaded to change their position if it were explained to them that this policy will lead to outsourcing support to a non-SAP provider.

Orders are licensed via a 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.”

Going forward:

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 concept of “static read” is the most deliberately misleading.

Scenario Indirect Static Read?

SAP then provides the list of read 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 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, customers can report on data that was 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.”

Basically, 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 that are not from SAP can very 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 how one of the most extreme examples of it.

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?

This is a pattern on the part of SAP to conflate cloud with indirect access. SAP has conflated the two, and ASUG 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 the 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’s 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 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 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.

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.

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 here 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. 


This is yet another in what has become a pattern of deceptive articles about indirect access emanating both from SAP and from ASUG. The white paper is a type of negotiating propaganda put out as something to “educate” customers. It desires the customer to accept a number of false assumptions in order 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 doing things in a collaborative manner to thwart SAP, as SAP’s type 2 indirect access claims and the Byzantine logic for how they justify indirect access is becoming more and more extreme.

To this end, I have begun the Brightwork Indirect Access Alliance (BIAA for short).

This is an information sharing service that vendors can join that is designed to help defend against these tactics by SAP.

Contact me for details.


Analysis of Snow Software on SAP Optimizer

 What This Article Covers

  • An Analysis of Snow’s Web Page on Snow Optimizer


Part of what we do at Brightwork Research & Analysis is review the accuracy of media output of IT entities. In this article, we will focus on Snow Software’s media output on SAP indirect access.


  • “View consolidated usage data across all SAP systems
  • Automate SAP user license administration
  • Identify and trace indirect usage
  • Centrally manage contracts and addendums
  • Contain HANA license costs
  • Optimize BusinessObjects licensing
  • Install and manage within the SAP environment (SAP certified)”

This is interesting in that it shows licensing for HANA and for BusinessObjects. It is curious that it is called out separately.


Snow Optimizer for SAP Software provides deep-dive analysis into transactional and individual usage data, identifying opportunities to reduce costs and liabilities by eliminating duplicate users and unused licenses.  The solution can automatically recommend ‘best-fit’ license types based on user behavior, making it easy to switch from expensive licenses to cheaper ones where appropriate.  Automatic monitoring frees up SAP administrators to focus on core duties and ensures information is always up-to-date in case of an audit or review. Contract Management and compliance reports can provide guidance and insight as well as help achieve savings through better negotiations with vendors.

This is what SAM software for SAP provides users. SAM software should allow companies to “right size” their licenses.


Through this functionality, Snow Optimizer for SAP Software provides comprehensive data about Indirect Usage which enables the organization to significantly reduce financial exposure and to highlight risk in the future.

Another important reason for SAM software is indirect usage. Indirect usage from SAP comes quickly, which is why it is important to have SAM software already installed.


Snow Optimizer for SAP Software maintains up-to-date details on all SAP license allocations, giving SAP administrators the ability to adjust license types and distribution on-the-fly. Automated rule sets quickly align individual users with the correct license in the correct system based on their activities.

Alerts can be triggered when the organization nears license limits under current contracts or specific activity restrictions.  Pre-defined rules help organizations prevent actions that would incur unexpected or unacceptable costs.

The concept of SAM software is that it is constantly used, to provide an accurate picture of usage versus the customer’s licensing. Alerts are particularly helpful in keeping logic working in the background that can tell the customer when a change occurs.


Snow Optimizer for SAP Software can be used to test a variety of “what-if” scenarios that enable the organization to model how changing the deployed license types would affect SAP licensing and support costs. Scenarios can be played out in the solution without making any changes on the live system until the organization is happy with the results, avoiding potentially costly licensing mistakes.

What if planning has quite a lot of uses. For instance, knowing what the costs will be when making changes to the software and the usage of the software that is planned.


How Accurate is the Certero Article on Software Audits?

 What This Article Covers

  • An Analysis of Certero’s Web Article Accuracy on SAP Software Audits
  • Virtualization
  • Monitoring Usage
  • Indirect Access


Part of what we do at Brightwork Research & Analysis is review the accuracy of media output of IT entities. In this article, we will focus on Certero’s media output. Certero is a software vendor that offers SAM software.


Virtualization is a mature technology that can help you save money, time and carbon emissions. Consequently, just about every major organization has adopted it in one form or another, somewhere on their IT estate.

But, there is a major issue with virtualization that many organizations overlook – the impact it has on your software licensing. Unless you are fully aware of these implications and are able to manage your license position, you could end up paying more for additional software licenses (and fines if the shortfall is discovered during a vendor audit) than you saved through virtualizing in the first place.

That is quite true. In fact, a major motivation for virtualization was to save money on software licenses. However, eventually the software vendors became savvy to virtualization and they changed their license terms to account for it. This greatly reduced the incentives to virtualize as the potential software cost reductions were always greater than the hardware cost reductions.

And vendors do know how to audit and determine penalties on their software when virtualized.

Monitoring Usage

Dependent on the terms of your license grant, the need to measure the usage of your software could be important in ascertaining whether you are compliant and also what you have to pay. Certain software vendors, like SAP and Oracle, charge for software based on metrics that can be unique to your business. For example, if you are a car manufacturer, the metric could be based on the number of cars you have built.

Yes, that is also true. And SAP and Oracle as well as other differ from each other as well.

Indirect Access

As if the licensing agreements of the likes of Oracle, SAP and Microsoft were not complicated enough already, many user organizations fall foul of something called indirect usage and end up owing significant amounts as a result of licensing non-compliance.

Indirect usage, indirect access, or multiplexing as it is sometimes called, is where your software (be it Oracle, SAP, Microsoft etc.) is accessed indirectly by a non-named third party, which can either be a person or machine. For example, an organisation has created a system that allows all their employees to enter their expenses. That system then sends all that employee expense information to a second system using a single named user account.


Key to getting to grips with indirect access is the ability to correctly classify users of your software as direct or indirect and so make sure they are given the correct license type. Identifying indirect access can be tricky without the help of an automated monitoring tool.

This is another way of saying monitoring usage also, which is what SAM software does.

However, there are tell-tale signs that make indirect access easier to spot. These include things like a user accessing a system all day long (no human user would do that) or a very large volume of work processed within a set period by one user (again, no human could conceivably process such a volume within that time).

That makes a lot of sense.

One way to avoid indirect access problems in the Oracle world, for example, is to license via processor, rather than Named User. Sadly, there is no such corresponding license in the SAP world, where you are limited to Named User.

The distinction that I would want to be drawn here is that SAP enforces indirect access quite a bit differently than Oracle. SAP is the only vendor I have yet observed charge for what I have called Type 2 indirect access.


This article by Certero earns a Brightwork Accuracy Score of 9.5 out of 10. There is nothing inaccurate in the article, and the only area that could be adjusted is adding some specificity.


Software audits: What can go wrong – 2?

Interpreting SAP’s Misleading Support Video

What This Article Covers

  • SAP’s Video on Support
  • The Enormous Costs of SAP On Site Support


In previous article such as What to Do About SAP’s Declining Support, we have brought the support issue front and center. SAP has cut support costs to the point where they have 90% margins and most the support personnel work in 3rd word nations that SAP pays around $25 to $35 per day.

SAP Support Video

This is why it is either sad or amusing (depending upon your perspective) to see support videos like the following from SAP.

This video is simply highly misleading. As a a consulting who has often used SAP support, SAP’s underinvestment in support is quite apparent. Secondly, in the video, SAP mentions MaxAttention, but what they leave out is that MaxAttention is even more expensive than the base 22% of license revenue support. And it leads to consultants coming to the client to pitch their services, so its unclear how it is really support.

The Enormous Costs of SAP On Site Support

The costs that are implied in the design towards the end of this video are enormous. It also brings up the question of why so many support personnel would be necessary for SAP, when this support overhead is really not replicated at the vast majority of other software vendors.


Customers should not be confused by this video. SAP support has declined significantly over the past 10 years in particular. And SAP is not giving its support sufficient resources to do the job properly.


The Danger in Underestimating SAP Indirect Access

 What This Article Covers

  • What SAP Would Like Customers to Believe
  • The Real Use of Indirect Access
  • Listening to ASUG on the Frequency of Indirect Access Frequency
  • The Frequency of Indirect Access
  • The Size of Indirect Access Claims


Indirect access tends to only be known companies that have not been subject to an indirect access claim when a major indirect access (IA) public event occurs, such as a court case documents being filed. Good examples of this are Diageo and InBev. However, what is the prevalence of indirect access?

In this article, we will discuss information that has been coming in from the field. But first, we will begin with what SAP would like their customers to believe about the prevalence of indirect access. 

What SAP and SAP Consulting Partners Would Like Customers to Believe

Generally, both SAP and the SAP consulting partners would prefer that their customers do not know anything about indirect access. It is amusing to see IBM, Deloitte or Accenture comment on how to manage indirect access, a consulting company that has a partner relationship with SAP may be able to run a SAM software project, but none can represent their client’s interests against SAP. Consulting companies to compete to see how to ingratiate themselves to SAP, they don’t dare risk offending them. As an example of a recent pursuit which the client was not told about indirect access and had to find out about it from a competing vendor. The customer asked the consulting company why they had not informed them of the indirect access liability.

How much does SAP want customers and prospects to lower their guard?

At SAPPHIRE SAP produced an announcement that was intended to assuage their customer’s concerns about indirect access.

I analyzed this announcement in the article How to Best Understand SAP’s Faux Policy Change on Indirect Access and concluded that it was really no change in policy aside from more specific charging of customers when SAP brings and indirect access claim. DSAG, which is the German SAP user group, and UpperEdge, were two of the only other media entities willing to call out SAP when they are wrong on indirect access, came to the same conclusion that I did on the announcement.

Since that article, I have learned that SAP will not even publish what it intends to charge per purchase order or sales order for indirect access, which was a major part of the announcement. Instead, SAP has stated that customers would be charged “on a case by case basis.” Of course, they will be. This increases the secrecy of the cost of indirect access. The announcement made it seem like SAP is opening up, but then when asked questions, SAP goes back into secrecy mode.

Listening to ASUG on the Frequency of Indirect Access?

ASUG, which is supposed to be a user group, but is actually a marketing arm of SAP, has been telling members that indirect access is rare and that it is merely the high-profile cases (such as Diageo and InBev) that push it to the forefront. This is covered in more detail in the article Is ASUG Lying About the Frequency of SAP Indirect Access? 

As ASUG is really just SAP in “sheep’s clothing” what we can take from ASUG’s stance, is that this is in fact what SAP wants customers to think about IA. I have never been in an SAP-ASUG meeting, but by the looks of it, they get together and SAP basically tells ASUG exactly what messages they want to relay, and ASUG relays those messages no questions asked.

All of this is curious, because ASUG members pay membership fees, and fly to ASUG conferences to be told information that is inaccurate, is 100% beneficial to SAP and to the customer’s disadvantage and is what SAP wants them to believe. ASUG cannot both represent the interests of SAP and of their members.

  • As I stated in the “Faux Policy Change Article,” SAP’s overall intent is to get its customers to lower their guard.
  • The less that their customers are prepared, the more SAP is able to use indirect access as a hammer against them.
  • Time is of the essence. SAP uses restricted timelines to get customers to acquiesce to their demands. The less preparatory work they have done before SAP drops an indirect access claim upon them, the more likely they will end up doing what SAP wants, and this is covered in the article The Time Issue Faced with Indirect Access.

The Reality of Indirect Access Frequency 

SAP has been quite effective with indirect access to drive license revenues, so they don’t have a very good reason to stop doing it. They are catching customers off guard and there is a very poor defense normally available to customers. And vendors that are affected by indirect access are uncoordinated. Essentially the issue is dealt with by individual account teams, that are in most cases not coordinated even within a single software vendor with respect to indirect access.

There are several other reasons for the success SAP is having against customers in indirect access.

  1. Source Issues and Finding Unbiased Representation: Many of the sources relied upon for information on indirect access have already aligned with or are in some way remotely controlled by SAP. This is covered in the article Taking a Multidimensional Approach to Indirect Access.
  2. Confusion with the Roll of Attorneys: Few attorneys know anything about indirect access. Unless the issue is going to court, and this is unlikely and unknown by anyone early in the process, unless the attorney already has a strong familiarity with indirect access, hiring an attorney is not going to help very much. There are several steps that do help. And keeping good notes is important whether an attorney is eventually contacted or whether they are not engaged. Secondly, bringing up attorneys that are unfamiliar with the topic is a lengthy process. If an indirect access claim is brought, time is of the essence in getting control over the situation.
  3. The Lack of SAM Software: Surprising as it may seem, most SAP customers still don’t use SAM software. So when SAP drops an indirect access claim on them, they aren’t even in a position to know what their overall license usage is or to know their specific indirect access exposure. SAM covers all usage measurement, indirect access being just one. Customers really don’t want to not have SAM software installed and then have to deal with both going through a SAM project, negotiating with the SAM vendor, then learning how SAM software reports look, all with SAP and an indirect access claim and their short timelines for response putting extra pressure on the company. SAM software and projects are measured in the hundreds of thousands and are good for more than just indirect access. Indirect access claims are measured in the millions, and sometimes tens of millions.

Indirect Access Frequency

The information I am getting from the field is that indirect access is actually increasing.

I have been tracking indirect access for around a year and a half. This is the point when vendors first started communicating to me that SAP would bring up the topic of indirect access charges as soon as it looked like the other vendor was about to get a contract from SAP.

And what is also interesting is that the indirect access issues brought up to me have been all over the spectrum of the different software categories. Although CRM does seem to be one of SAP’s favorite areas to bring indirect access claims. SAP seems to have an anger management issue when losing to Salesforce.

However, the outcome of these indirect access claims is normally the same. The customer is forced to purchase software from SAP it never wanted to purchase. When SAP reports sales to Wall Street it implies that 100% of them are voluntary. However, with SAP’s use of indirect access, and increasing percentage are sales motivated by indirect access claims.

The Size of Indirect Access Claims

The size of indirect access claims is also increasing. I am now learning of tens of millions of dollars in indirect access claims. I have individual case studies, but I do not want to publish the specific multiple of tens of millions. SAP benefits if these case studies are kept as secret as possible.

The size of these claims is changing behavior and is allowing SAP to win license sales that they had lost prior to bringing the claim.

I am working on research into indirect access which I will publish, and the announcement is described in this article. Vendors and customers that are impacted by indirect access have to share their story. The more that it is kept secret, the more SAP wins. If vendors fear reprisal by SAP, that is what anonymous sourcing is all about. I have yet to expose any source that I kept anonymously.


SAP is ramping up, not ramping down its indirect access claims against its customers, and the claim sizes are growing. One should not be lulled into a false sense of security by Bill McDermott’s happy face at SAPPHIRE on this topic. As I said previously, Bill McDermott was specifically chosen by Hasso Plattner, because he had a “happy face.” But McDermott’s pleasant demeanor is stark contrast to the hard edge I witness in SAP’s use of indirect access for many SAP customers.

SAP customers are receiving a large amount of inaccurate information from sources ranging from ASUG to Deloitte, to Diginomica and this is because so many entities in IT are in some way dependent upon SAP for their revenues. The money is very clearly on the side of agreeing with SAP. I was told by one reader recently to switch sides and to begin writing in favor of SAP, as the pay is much better.

Companies that are dependent on SAP for their revenues cannot be expected to write objectively or to provide objective advice about SAP. Other entities like JNC Consulting do not even seem to question (in their articles) whether the Type 2 indirect access employed by SAP is actually valid or its historical context.

All of this combined with the timelines imposed by SAP on indirect access claims means that the deck is firmly stacked in their favor. And one of the ways of keeping it this way is to underreport and de-emphasize what is really a widespread usage of indirect access.

Is ASUG Lying About the Frequency of SAP Indirect Access?

What This Article Covers

  • What SAP Would Like Customers to Think About AI
  • What is Indirect Access Frequency?
  • What are ASUG’s Incentives?


I have critiqued ASUG in several previous articles such as ASUG’s Biased and Inaccurate Coverage of SAP Indirect Access. My observation of ASUG’s media output is that ASUG is uniformly repeating SAP’s marketing messaging, that it appears to have no independence from SAP whatsoever, and that it writes false information about SAP. This article will explain what has happened to ASUG. This article will cover what ASUG says about how frequently customers actually face an indirect access claim by SAP. But first, we need to get into what SAP would like customers to think about indirect access.

What SAP Would Like Customers to Think About IA

We don’t have to search very far to determine what SAP would like customers to think about indirect access. In the article How to Best Understand Faux Change on Indirect Access, I covered that SAP created their announcement as a way to make customers minimize their preparation regarding indirect access. I won’t go over the entire article, but in the conclusion, I stated the following:

SAP intends to mislead the SAP customer base into lowering their guard by making a few slight modifications to indirect access that may end up amounting to as close as possible to zero change in SAP’s enforcement of indirect access.

Therefore, it is clear that SAP does not want customers to worry their “pretty little head” about indirect access. And the reason for this is very simple. If customers do not prepare for indirect access, SAP can spring indirect access on their customers and receive less prepared pushback from customers. In fact, I concluded that the entire reason for the announcement on indirect access that occurred at SAPPHIRE was to make many customers that were concerned about it, become less concerned. The entire announcement did not do anything to reduce the concern that customers should have regarding indirect access but instead was worded in a way that it seemed like it did.

The Frequency of Indirect Access Claims

Apparently, when asked directly about indirect access, ASUG seems to have several answers.

  1. One is to state that few customers actually receive an indirect access claim, and the reason that customers have been hearing so much about it is that those scenarios tend to be “noisy.”
  2. Secondly, ASUG will offer their services as mediators if a customer faces an indirect access claim from SAP.

As for the second response, I cover that in the article on the “faux change to indirect access,” so I won’t repeat it here. But for the former answer, it is interesting how well this dovetails with what SAP would like customers to believe. This is a constant issue with ASUG that they state exactly what SAP wants to be stated. However, an independent entity would not perfectly match up with another entity on every single issue like this by chance. And it is well known that SAP uses ASUG as an outlet for publishing SAP marketing material. For example, if Brightwork were to suddenly begin to have talking points that are copied from the press releases of a software vendor on the website one would be right to question our independence. For this reason, we have ceased to see ASUG as having any independent voice from SAP.

Therefore, ASUG’s statements on any topic, can simply by seen as SAP’s statements on any topic, and there is no reason to assume that ASUG is filtering this message in any way.


We don’t know exactly how prevalent indirect access is. However, entities like ASUG and Deloitte or Accenture want indirect access to be as silent as possible. When Deloitte or Accenture are helping a company with a software selection, they do not inform their client of indirect access liabilities that come along with SAP. Why would they? It reduces the likelihood of the customer choosing SAP. And this is the problem with entities like ASUG and like Deloitte or Accenture. They pretend to represent the interests of their members or clients, but ultimately they are all simply tools of SAP.


The statements by ASUG on indirect access were brought by several anonymous sources that attended ASUG meetings on indirect access and that corroborate the statements made by ASUG.

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


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.


  • 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.


Modern Pricing for Modern Times

1 2 3