When it comes to licensing audits, and as the complexity of IT environments increases, staying on top of your entitlements to mitigate over-deployment will save you time and money. With the complexity of IBM’s software licensing methods, they are no exception. Over the course of IBM’s 100+ year history, IBM has become a conglomerate of many small companies acquired through M&A. As a result, IBM’s Software Licensing is infamously complex with a variety of licensing metrics resulting in millions of audit findings. With over 80 different metrics covering the whole scope of IBM’s products, IBM’s metrics are notoriously difficult to navigate and license properly for. With IBM software commonly deployed in enterprise data centers, understanding the whole slew of licensing metrics and compliance requirements becomes crucial to ensuring you are not paying unnecessary IBM licensing fees. To help you navigate through IBM’s license complexity, let’s get to know some of the metrics and challenges associated with IBM Software Licensing.


License Agreements – Understanding Entitlement and Product Use Rights

IBM has recognized the difficulty associated with understanding their product entitlements and have tried to centralize and simplify its licensing by creating the Passport Advantage (IPAA) program. Passport Advantage is a centralized program that uses a common set of agreements, processes, and tools rather than individual agreements for each of its products. However, you cannot solely rely on Passport Advantage alone, as it does not recognize any license purchases outside of the system. Furthermore, because Passport Advantage allows you to download products without restrictions, unmanaged downloads can expose you to over deployment risks. For any legacy purchases, you will need to present the contract or Purchase Order Entitlement (POE) to IBM. You will also need to account for product migrations to get a more complete, and more accurate picture of your IBM entitlements.

In addition to IPAA, IBM uses multiple other license agreements, each with its own set of terms and conditions that are applicable depending on how the product is licensed or deployed in the environment.  Each agreement has its own set of terms and conditions that are applicable depending on how the product is licensed or deployed in the environment. Thus, you’ll want to pay close attention to any changes that impact licensing across agreements.


License Models—Varied Metrics and Complexity 

IBM’s software products are frequently deployed across the IT infrastructure and supported on multiple operating system platforms, which increases the complexity of the environment. Managing the vast deployment of IBM products is a daunting task, but for the most part, licensing can be categorized into three major “buckets” – user-based, capacity-based, and other licensing. However, the main difficulty comes from tracking which product goes with the appropriate licensing “bucket.” We’ll now cover the most popular licensing metrics, starting with what is known as Processor Value Unit (PVU).

Processor Value Unit (PVU) – Introduced in 2006, PVU based licensing was created to take the processing capacity of the server into account to determine licensing, rather than relying solely on the number of cores. This change was made to account for the increased processing power of newer technologies, and the gradual shift towards virtualization.

According to IBM, a Processor Value Unit (PVU) is a unit of measure used to differentiate licensing of software on distributed processor technologies (defined by Processor Vendor, Brand, Type and Model Number). In many virtualized environments, certain cores and processors are partitioned, or segmented off to be used for VMs. This means that using the PVU metric under full capacity, a virtual application that only uses 12 out of 24 cores on a server, would still be licensed for all 24 cores under the PVU metric, rather than the 12 cores that are currently in use to support the application.

PVU metric calculations are by far the most complicated and have many moving variables, including the use of virtualization, processor name, server model, number of sockets,  and processor model. IBM created IBM PVU tables assigning core values based on processor architecture, vendor, brand, type, and model number as well as the total cores (number of processors x core per processor). These PVU tables publicly available on their website and show the model, processing capacity, as well as the associated PVU value for the available processing technologies (x86, RISC, and System Z).

Storage Value Licensing—For products licensed by storage data, IBM counts the deployment by ‘Tebibyte’ and not the default ‘Terabyte’, which is 90 percent of a Tebibyte. This confuses many customers as it is a nonstandard way to measure storage.

User-Based Metrics—Be sure not to overlook the user-based metrics, as it is very common to over-deploy IBM’s user-based software since there aren’t any built-in controls to restrict software usage.

Disaster Recovery (DR) Environments—Cold and warm standby servers are not chargeable. Therefore, you need to be careful around IBM’s classification of “hot standby” systems, which are servers performing work such as mirroring of transactions, updating of files, and synchronization of programs, etc. Machines deemed to be running in “hot standby” mode require the appropriate software licenses from IBM.

Full Capacity Versus Sub-Capacity Licensing—To account for increased virtualization, IBM introduced licensing by sub-capacity. Instead of licensing the product for the full capacity of the server or group of servers; it instead measures the capacity in use in the environment. This helps to reduce unnecessary licensing fees as servers are not licensed by their full capacity or total CPU cores.

While sub-capacity is available to customers who agree to the terms and conditions of the agreement, full-capacity licensing is the default unless otherwise agreed in writing with IBM. Given the cost and processing advantage of running IBM software on virtual servers, most businesses prefer to virtualize their IBM environments. However, by default the software is licensed by full-capacity or all processors and cores on the physical host (and server cluster in some cases) must be licensed, as opposed to just the VM or instance running IBM software, which is known as sub-capacity licensing. For a customer to be granted sub-capacity licensing rights, the customer must agree to the terms and conditions of IBM’s sub-capacity agreement.

However, there are two requirements to be eligible for sub-capacity licensing. First, the IBM License Metric Tool (ILMT) must be installed and configured within 90 days of first use of an eligible sub-capacity product. Second, a quarterly report must be produced through ILMT and available to IBM upon IBM’s request.


What you need to know about IBM’s License Metric Tool (ILMT)

ILMT is a free tool offered by IBM to measure the metrics necessary for IBM software licensing. ILMT has several functionalities, including software discovery and identification, signature discovery, reports, license usage monitoring, and producing metrics for IBM licensing. In other words, ILMT is similar to a SAM tool that is built specifically around IBM’s PVU based products.

As it relates to licensing, the most important features of ILMT are the reports, license usage monitoring, and licensing metrics. ILMT calculates the maximum core capacity of the server that is available to the installed IBM software, and then determines the number of PVUs or other processor-core entitlements that are required. Given this information, ILMT can produce reports that contain a detailed summary of all the machines in your environment. These are the reports that must be submitted to IBM to be eligible for sub-capacity licensing.

While these features are undoubtedly valuable, they are not perfect. Part of the challenge with ILMT is that it requires significant effort to properly install and configure to capture all of the necessary information. ILMT relies on an agent being installed on a target machine, whether physical or virtual, in order to report deployment data to the ILMT license server. In cases where an agent cannot be deployed to certain enterprise systems, there needs to be a workaround process to gather the installation data from the machines.  Furthermore, many customers find that despite having ILMT installed, their coverage across the environment is incomplete, or they did not properly account for bundled software. The scans themselves can also fail, as there have been known issues with disk space, compatibility, and credentials. Be sure to be aware of these potential pitfalls when using ILMT and consult an expert as needed.

Other leading SAM tools have developed capabilities to measure IBM product use, specifically for the PVU metric. However, if used in place of ILMT, the tool outputs should be reviewed to ensure PVU calculations for both full and sub-capacity licensing are accurate, and product bundling is being addressed by the non-IBM solution.

Given the complexity and dynamic nature of IBM’s licensing models and technology portfolio, it’s very important to understand the licensing metrics to ensure that you mitigate over-deployment, as many customers have been subject to millions of dollars in license fees resulting from an IBM software audit.


While this article is not an exhaustive list of IBM licensing metrics or a complete audit defense playbook, we hope that this provides some clarity and insights around IBM’s complex licensing models and ILMT to better prepare for your next software review or IBM renewal. If you would like more information on how Connor’s Software Advisory Services may help reduce your vendor licensing risks and optimize IT spend, please contact us at info@connor-consulting.com.

In recent years, Salesforce – one of the largest enterprise SaaS vendors – has started to conduct an increasing amount of license verification reviews for their products. Many organizations are still not familiar with cloud or SaaS-based licensing. Most believe that if you sign up for a certain number of subscription-based licenses, you are free to use the software without any risk of audit or vendor non-compliance.

If your company has recently signed a Salesforce agreement or is thinking of purchasing Salesforce products for the first time, you might be surprised to learn that:

  1. Salesforce’s product portfolio is quite extensive. They offer many editions for each product at various prices.
  2. Salesforce is legally entitled to perform license verifications to check if usage inside your organization matches the contractual quantities.
  3. Salesforce licensing, as well as cloud licensing in general, comes with certain risks that may result in higher unexpected costs.

In this article, we will compare the different product functionalities and pricing for each of the most common product editions offered by Salesforce. We will also help identify ways to optimize your Salesforce usage by assessing your environment and efficiently re-assigning licenses where appropriate to save costs.


Understand Salesforce Products and License Agreements

Salesforce is a Customer Relationship Management (CRM) solution that offers a single platform, capable of integrating multiple business areas like marketing, sales, commerce, service, finance, and many more. Basically, each product comes in different bundles called editions that vary in functionality and pricing. Currently, there are 4 editions available to choose from, each geared toward specific business needs: Essentials, Professional, Enterprise or Unlimited.

For example, small companies with less than 10 users may be looking for the cheapest option for Service or Sales Cloud, and the Essentials edition—which includes basic functionalities and is priced at 25USD/user/month—may fit their business needs. On the other hand, large organizations can opt for any of the more expensive editions, the Unlimited edition being the complete solution with unlimited CRM support. Pricing per user ranges from 75 to 300 USD/month, depending on the volume of subscription licenses needed and license types selected.

According to Salesforce, the most popular edition is the Enterprise edition, which allows customers to customize their product and integrate it with other systems. Additionally, there is a Developer edition intended for development use only, allowing users to integrate Salesforce with other applications and develop new tools and applications. The Developer Edition also provides access to many of the features available in Enterprise Edition; however, production use is restricted.

In terms of license types, the options are even more extensive, and it’s not an easy task to choose the right licenses for your company. At the most basic level, Salesforce offers 6 license types:

  • Standard User Licenses
  • Chatter User Licenses
  • Communities User Licenses
  • Service Cloud Portal User Licenses
  • Sites and Site.com User Licenses
  • Authenticated Website User Licenses

However, the list above is not extensive, and there are many other licenses available for purchase. Some of them are limited to company use, while others, like the Customer Portal User licenses, extend to customers and partners.

Before purchasing Salesforce products, or if you want to add more users to your existing license pool, we recommend analyzing and understanding the different license types so you can choose the most suitable type for the intended end-users. Basically, a user license includes a baseline of features that a specific user may access (every user is allowed to use only one license type). Moreover, edition requirements vary for each user license type. For example, a Communities User License will only be available with Enterprise, Performance, Unlimited, or Developer editions, while the Lightning Platform App user will be available with Enterprise and Unlimited editions only. Therefore, you’ll need to understand the differences and limitations of each product and edition before entering into an agreement with Salesforce as it can overwhelm IT, business, and procurement teams.

Since all Salesforce products are in the cloud, many assume that Salesforce will never audit its customers for software subscription usage. While Salesforce may not have a well-known customer compliance program, they are legally entitled to perform a license verification of your company’s usage of their products. We have identified the audit clause from the “Master Subscription Agreement” to which every customer is engaged, and the specific terms could vary depending on what has been negotiated in your specific contract:

Usage Limits. Services and Content are subject to usage limits specified in Order Forms and Documentation. If Customer exceeds a contractual usage limit, SFDC may work with Customer to seek to reduce Customer’s usage so that it conforms to that limit. If, notwithstanding SFDC’s efforts, Customer is unable or unwilling to abide by a contractual usage limit, Customer will execute an Order Form for additional quantities of the applicable Services or Content promptly upon SFDC’s request, and/or pay any invoice for excess usage in accordance with the “Invoicing and Payment” section below. (Source: Salesforce.com)

While Salesforce avoids the use of words such as “audit” or “license verification”, they are still entitled to check if any licenses are being used in excess of what’s been purchased by a customer. Like a typical software audit or license verification review, Salesforce will charge for any unlicensed products through an “order form(s) for additional quantities” that get added to your current subscription agreement. Thus, customers will need to proactively manage their user/subscription usage to ensure that they stay in compliance with their Salesforce agreements. Failure to do so will result in unplanned IT OPEX fees, so it’s important to have a SaaS management strategy as part of your overall Software Asset Management (SAM) program.


Top 3 Ways to Make the Best out of Your Salesforce Licenses

Because there are many functionalities for Salesforce products, it can be quite challenging to decide on the best option needed for your employees. This is the reason why we recommend our customers to perform the following activities on their environment before signing a new Salesforce agreement or renewing an existing one.

  1. Evaluate Your Company Structure through Organizational Charts

We strongly recommend evaluating your entire organization by reviewing available organizational charts that include roles and titles for all users in the company and compare them with the functionalities of each license type offered by Salesforce. You may also need to verify responsibilities with key leaders or managers in each respective function. Although it can be a labor-intensive task, this will not only help you assign the most suitable license type for each user, but will also help you compare costs and functionalities for each of them and decide what’s needed and what’s not. Not all users will require access to the full CRM functionality, and some of them may be able to perform his/her daily duties with read-only access. As mentioned above, the prices can vary from $25 per user to upwards of $300 per user which can quickly add up depending on the size of your company.

  1. Ensure Credentials are Not Being Shared by Multiple Users 

One of the common risks of a user-based licensing model is the fact that multiple users can share credentials of a single license. This practice not only violates the terms of your license agreement with Salesforce, but it also poses a security risk and can expose your organization to cyber threats and attacks. The terms of usage that do not allow shared credentials are stated in the “Salesforce Master Subscription Agreement” referenced below:

Usage Restrictions. Customer will not (…) (f) attempt to gain unauthorized access to any Service or Content or its related systems or networks, (g) permit direct or indirect access to or use of any Services or Content in a way that circumvents a contractual usage limit, or use any Services to access or use any of SFDC intellectual property except as permitted under this Agreement, an Order Form, or the Documentation (…). (Source: Salesforce.com)

Bear in mind that there is one situation where Salesforce allows users to share credentials: if any user is experiencing any issues, administrators can log in to Salesforce as the user experiencing the problem, for troubleshooting purposes.

In order to avoid violating the user restrictions, we recommend leveraging an organizational chart (see above) to map out the number of users that are licensed for Salesforce and the specific requirement by functional area and employee role. By running a SaaS management tool (e.g., Zylo, Flexera, etc.) across your environment, you can determine the number of users accessing Salesforce and which modules they’re accessing, reconciling this usage data to your subscription entitlements within your Salesforce contract(s). If you discover that more users are accessing Salesforce than your company is licensed to, you should conduct a mock audit to identify whether there are users that can be optimized/re-assigned prior to purchasing additional subscription licenses. 

  1. Reduce Costs by Re-Assigning Users

We recommend companies to have a dedicated Salesforce resource to evaluate each license assignment and maximize the use of purchased licenses when additional user licenses need to be provisioned. We also recommend performing an internal assessment or mock audit of your Salesforce licenses and their assigned usage, and check whether users are still active, or they if they still require their Salesforce license to perform their daily activities. If licenses are not needed anymore, you can easily re-assign licenses from one user to another, based on actual consumption needs. This type of mock audit should be performed regularly to manage compliance risk or potential shelf-ware across your Salesforce environment.

Additionally, you should manage users and their roles regularly. For example, if certain employees only need to perform an update of their profiles for HR purposes and do not login into the Salesforce platform frequently, you may want to reconsider the type of license they currently use. Note the annual cost of a single Salesforce Sales + Service Cloud Enterprise user license is $2100, while the annual license cost of a Lightning Platform Plus is $1200. By identifying those users who do not need a full Salesforce license and assigning them a license with less functionalities can lead to significant cost savings for your company.


Connor is Here to Help

Although Salesforce licensing may seem overwhelming and can be a nightmare to manage, it is worth the effort to assess your current licenses and actual usage, as you could be at risk for over-deployment or your company may be spending way more than it should with the vendor. When it comes to SaaS management and SAM, partnering with an industry expert like Connor can help you quickly evaluate your current business needs, and determine the best license options for your employees and enterprise. To learn more, contact infor@connor-consulting.com today.

In late 2018, Oracle announced they will make you pay for using Java. This news has caused a great deal of confusion among both customers and Software Asset Management experts. Many people, for good reason, believe they need to pay fees to Oracle to move forward with their Java usage. However, access to the open source Java license hasn’t been cut off completely. Read on to find out how you can continue to benefit from a free Java license and when to upgrade to a paid license. ­

First and foremost, you’ll need to understand the difference between the two (2) different Java offerings from Oracle.

There are currently two versions of Oracle’s Java:

  • Oracle OpenJDK
  • Oracle JDK (also known as Java Standard Edition or Java SE)

Let’s clear up any confusion surrounding OpenJDK’s pricing — OpenJDK remains a free product even with the new licensing rules. This is because OpenJDK is licensed under the GNU General Public License, which is a free license for software and guarantees end users the freedom to run, modify, and share the software for free. Although certain limitations apply, OpenJDK is intended for both public and commercial use and will remain free for the foreseeable future.

However, it is important to understand Oracle’s new release cadence and how this can affect your organization. Oracle has announced that upgrades for OpenJDK will be released every 6 months, and each release will replace the previous one. Consequently, any new bug fixes can only be applied in 6-month intervals. Also, any security risks identified in any of the previous Java versions will only be addressed in security patch updates every 6 months. This forces customers to perform upgrades for their Java environment twice a year aligned to Oracle’s release calendar, which may lead to performance issues or instability, along with IT operational challenges.

Depending on the size of your organization, you may require a dedicated team to test, install, and update new Java versions before implementing them, as well as check for any system anomalies or compatibility issues with other applications. Not only will the teams need to install and test these updates twice a year, but they will also be required to monitor and manage the Java environment more diligently than before. This may not be practical for many IT departments, who are continually faced with having to both run and grow their businesses.

For those IT departments who can’t dedicate a team to Java updates, they may prefer Oracle JDK. Though not free, Oracle JDK provides 3 years of licensing and support, and customers will have immediate access to security patches, updates, and bug fixes throughout the entire support period. IT teams will have 3 years of runway before they need to upgrade to the next Java version so this allows more time to properly test and integrate Java into their IT landscape. However, it all comes down to what end-users are more comfortable with from an IT operations perspective — upgrading Java in 6-month intervals or doing so every 3 years.

Understand your Java environment.

So, should you stick with the free license or move to the paid one? This is the question most organizations are currently assessing. If you are currently deploying Java or you’ve been planning to start using Java, you should start by asking your IT leaders the below questions.

Question 1: What version of Java do you use?

We believe this is the most important fact to know about your Java environment. Without proper knowledge of your Java environment, you won’t be able to make effective licensing decisions.

After you find out your currently deployed license version, you can consider the following three (3) options if you want to stay with Oracle Java:

  1. Stay on your current version of Java without performing any updates that will force you to accept Oracle’s new licensing terms. This option is not recommended because of security threats that might leave your entire organizations exposed to cybersecurity attacks. If you are still using Java 8 or lower, then you may want to rethink the entire Java environment for a possible upgrade or an alternative solution.
  2. Purchase Oracle support for Java 11. This is the first version made available for the 3 years subscription licensing model. If you decide to transition to Java 11, it’s key to note that desktop pricing is $2.50 per user per month, or lower with tiered volume discounts. Processor pricing for use on Servers and Cloud deployments is $25 per month or lower, depending on the purchasing volume. For more details around licensing metrics and volume-based pricing, check out Oracle’s Global Price List for Java http://www.oracle.com/us/corporate/pricing/price-lists/java-se-subscription-pricelist-5028356.pdf.
  3. Upgrade to Java 12. This is the latest version of OpenJDK released by Oracle in March 2019 and can be used for free in any environment. However, based on the new licensing rules of Oracle, you should be prepared to upgrade to the next version in September 2019, given the 6-month release schedule. While companies with small Java environments might not see any issue with upgrading this often, larger organizations may need to consider the effort and resources needed to support this IT and change management process.

Question 2: Where is Java being deployed?

If your company uses Java for testing and developing only (non-production), then you can keep using Oracle JDK without paying for it. However, if Java is heavily deployed in your production environments, you will need to purchase the proper licenses from Oracle or re-consider your options as discussed above. Oracle has confirmed that it no longer offers any commercial support for OpenJDK builds after the April 2019 update.

Question 3: How many applications and users are Java-dependent?

You’ll want to be able to assess all possible risks of using OpenJDK vs Oracle JDK, and also, understand the financial impact of moving to the subscription-based licensing model. Before making a decision, it is essential to understand how the release frequency may affect the applications running on Java and how IT resources will be impacted to effectively support the updates.

Actual and intended usage are also very important factors in deciding which licensing metric or model is best suited for your organization. Oracle licenses JDK on the “Named User Plus*” metric, which means that you will be required to pay for all the “individuals authorized to use the programs which are installed on a single server or multiple servers regardless of whether the individual is actively using the programs at any given time. A non-human operated device will be counted as a named user plus in addition to all individuals authorized to use the programs if such devices can access the programs.”

Alternatively, you can also license JDK on the “Processor*” metric which “shall be defined as all processors where the Oracle programs are installed and/or running. Programs licensed on a processor basis may be accessed by your internal users (including agents and contractors) and by your third-party users.” (Source: Oracle Java SE Subscription Global Price List)

To summarize, the most important difference between the two available Java builds come down to how often customers will receive updates and support. If you’re using the OpenJDK version, Oracle won’t be providing updates to past versions and new releases will follow a 6-month schedule, whereas Oracle JDK will provide access to patches and updates throughout your subscription term, allowing more flexibility on product upgrading timelines. Also, understanding actual and intended and will help you determine the most effective licensing model for you, factoring in any IT operational impact and subscription costs to your organization.

With that said, we strongly recommend evaluating your entire IT landscape that runs on Java and taking the necessary measures to ensure you won’t spend more time and money than needed to keep your Java environment reliable, stable, and secure. By partnering with a 3rd party licensing expert and initiating a Java risk assessment, you can help your company stay compliant with Oracle and save millions of dollars in unplanned subscription or software licensing fees. To learn more or to schedule a no-charge Java evaluation, contact Connor at info@connor-consulting.com today.

In the first 3 parts of our SAP blog series, we’ve walked through SAP’s more challenging indirect use licensing model, from its history, the new Digital Access Model, to some tips on selecting the licensing model that is best for you. However, even with all of the indirect use knowledge, indirect use only covers one part of your SAP environment; should SAP audit you, they will be reviewing your entire SAP environment.

While many companies know they should perform self-assessments and evaluations before an official audit, most hesitate to perform them due to a lack of skills, resources, or time.

Introducing the “SAP License Assessment in 21 days” which is powered by our Connor for SAP Optimization tool.

To support companies in baselining and fine-tuning their SAP environments with a quick turnaround, minimal effort, and actionable insights, we have created a risk-based assessment program fuelled by the latest in automation software. By taking a deep dive into your SAP usage data, and combining it with unparalleled expertise in SAP licensing, we can craft a vendor negotiation playbook so you can ace an SAP audit, or prepare for an upcoming contract renewal in just 21 days. Our phase by phase approach is described below.

Day 1 to 10: Software baselining & reconciliation. Create a complete overview of your SAP landscape.

Together, we will define the specific application and engagement scope with the customer. Once set and agreed upon, we’ll proceed to the initial phases of the assessment: data collection and validation.

The first phase of the SAP License Assessment is the most complex and is often the most difficult for companies to complete. It involves a combination of data collection and validation techniques to provide a holistic picture of what the customer owns and what is deployed (and used) across all systems.

By centralizing and interpreting all software purchase records (SAP master agreements, order forms, transfer of license, termination letters, etc.) we’ll help to create a comprehensive inventory of all your software and support entitlements that can be compared to actual product installations. In parallel, we’ll measure your SAP application usage for any in-scope products leveraging our Connor for SAP Optimization tool.

The tool was designed to rapidly scan all SAP systems across both production and non-production environments, and baseline every SAP user and detectable product deployment across reachable application servers.  It not only detects created users in the SAP systems, but it also pinpoints any indirect access anomalies or risks, and documents created through external applications. Best of all, it is mostly automated and requires minimal customer intervention! Discussions with applications owners and SMEs will help validate any findings and increase the completeness and accuracy of the assessment.

By the end of the first phase, we’ll reconcile the collected data so that customers can quickly determine whether they are out of compliance or over-licensed for SAP software.

Day 11 to 16: License optimization. Achieving proactive management for software usage.

In the second stage, we’ll focus on resolving any existing compliance issues resulting from phase one, and determine the appropriate course of action, if any. While the first stage is perhaps the most complex, the second stage is probably the most crucial step in the assessment.

With the data collected in the first phase, our automation tool can efficiently reclassify licenses based on the actual usage and authorizations that are assigned in the SAP systems. By pinpointing inactive users, the tool will help you reduce your software usage and allow for effortless reallocation of unused licenses to active users. Engine usage and associated metrics are also easy to identify and you can decide if you want to keep the same metrics or license the engines on more cost-effective or available metrics.

We’ll also take extra steps to create a list of all users and their assigned license types to avoid unnecessary license costs, whether or not your company plans to migrate to S/4HANA. By counting both the documents created in the system and the maximum number of SAP users, we can calculate the financial exposure for indirect access fees. Based on the results, we’ll perform a cost-benefit analysis of the different license scenarios and recommend the most cost-efficient solution tailored to your environment.

In addition, our solution can provide intelligent alerts about any suspicious SAP data consumption. You can also control the allocations of SAP licenses in real-time through intelligent mapping of the proper license type to the actual usage.

Day 17 to 21: Audit Defense & True-Up Assistance. Getting the expert support needed to negotiate successfully with SAP.

In the final stage, Connor will leverage its deep SAP knowledge, as well as its IT sourcing and license compliance experience, to assist with challenging SAP negotiations in order to optimize license costs, improve commercial terms, and reduce non-compliance risk. In addition, we will work closely with customers to find the best product offerings and purchase timelines to effectively meet their future business needs.

Beyond the SAP Digital Access Model Blog Series

If you haven’t been following this series of blogs, you can access the first three installments in the series below:

With the insights you’ve gained in this 4-part series, you should be armed with the information necessary to challenge SAP during a software audit or upcoming contract negotiation.

However, having the knowledge alone doesn’t get you to your desired outcomes with SAP. You must take the appropriate or recommended actions in order to implement an effective SAP license management program. It’s no trivial task, but the good news is you’re not alone and you can learn from other companies’ costly mistakes!

At Connor, we’re industry experts when it comes to vendor licensing and IT spend optimization and can help you implement an effective SAM program, just as we’ve done for other major companies. Whether it be SAP or any other major vendor in your IT landscape, we will level the playing field on future vendor audits and deals, saving your organization millions of dollars. For more information on our 21 day SAP License Assessment or no-cost risk evaluation, please contact us at info@connor-consulting.com today.

If you’ve been following this SAP blog series, you should have a good understanding of the changes from SAP’s old indirect use licensing to the vendor’s new Digital Access Model (DAM). Now that you have a firm grasp of each model after reading through parts 1 and 2 of our SAP series, how do you know what’s the best licensing model for your company? To start, it’s prudent to lay out the pros and cons of each model.

The old licensing model’s greatest strength is that it’s a familiar and common user-based licensing model. Many companies are already licensed for user-based indirect use through their existing SAP agreements; since the DAM was introduced in 2018, many companies have not yet converted to it. If you stick with your current licensing model, you can avoid administrative licensing paperwork, although you may not be able to effectively optimize your software environment and reduce unnecessary SAP vendor spend.

Additionally, licensing named users is quite common across the software industry, and many SAM tools have built-in functionality that can match license entitlements to specific user deployments. In theory, if you’re able to track and measure all users accessing SAP, you’ll be able to manage licensing and vendor compliance.

However, this leads to the old licensing model’s greatest weakness — it’s very difficult to track all remote and indirect users. As discussed in part 1 of this series, this was one of the major customer complaints with the old licensing model. While it may be relatively easy (depending on your company size) to track your company’s internal users, it gets more difficult tracking all customers and external users who access your ERP or SAP system. Without a clear definition of what indirect use activity entails, many customers are not able to identify and count users who needed to be licensed, resulting in major license fees or penalties resulting from an audit.

The new DAM is meant to be simpler for customers to manage and track. Instead of having to license individual users, the DAM calculates users based on documents created which is a lot easier to measure and track, given there are specific SAP tables you can query based on the document type. In addition, SAP plans on moving all existing customers to S/4HANA by 2025, so you will likely receive better support for the DAM, as compared to the older licensing model.

The challenge with the DAM is that it is still uncharted territory and a relatively new license model. Due to SAP’s aggressive auditing history, many customers are still skeptical about switching to the DAM thinking it is a vendor ploy to upsell additional software. Document-based licensing is also unfamiliar to many organizations, and while SAP may be pushing to convert all of its customers by 2025, it’s hard to predict how the DAM will unfold in the next few years.

Additionally, there is a potential risk of double licensing users if you don’t manage your SAP software diligently. In the past, users already covered by a Professional User license accessing SAP through third-party applications were not charged for indirect access. With the DAM, any user who updates the SAP system and creates a document through external applications will be charged through the new pricing model. This opens up the possibility that a Professional User who creates a document in SAP through a third-party application could be charged twice: once for the documents created in SAP and the second time for any other indirect access usage. Unless you’re tracking those indirect users who are also creating documents within SAP, your company is likely to overpay.  Below is a table which summarizes the pros and cons of each licensing method:

User-Based SAP Licensing Digital Access Model (DAM)
  • Familiar license model
  • Many customers are already licensing SAP through a user-based model
  • Many SAM tools have the functionality to aid with user-based licensing
  • Avoids having to keep track of all internal and external users (e.g., indirect access)
  • SAP is pushing for customers to make the switch


  • Tracking external users is very difficult
  • True-up fees may become very large if you aren’t properly licensed
  • The DAM is still not widely adopted, so it’s hard to tell how well the model works
  • There is a risk for double licensing

Converting to Digital Access: Current Options

Given this information, it’s now time to consider your existing options. There are three (3) viable options available when it comes to adopting/or not adopting the DAM.

  1. Keep your current license agreement and do nothing

This option is recommended for any customers who are content with their current contract and the indirect access model based on named-users and maintain an effective way of counting direct and indirect application users of SAP.

  1. Keep your current contract with the possibility to exchange the old Indirect Access licenses to the new Digital Access licenses.

If you purchased any of the engines to cover the indirect scenarios (order-to-cash, procurement-to-pay, or Platform User licenses) you can obtain a vendor credit and switch to DAM based on SAP’s trade-in values.

  1. Move to S/4HANA with a converted contract

This option is for customers who want to give up the legacy model and switch entirely to S/4HANA. In most cases, SAP will credit you 100% of the value of the old agreement towards purchasing licenses under the S/4 license model. SAP will incentivize you to move to S/4HANA, along with any of their other cloud-based solutions. Customers are responsible to pay for any difference in license or subscription fees after credits are applied by SAP.

Identifying Licensing Risks: 5-step Customer Roadmap

Whatever option you end up choosing, we recommend all customers be proactive and not get blindsided by SAP. If you can’t decide whether to migrate to the DAM or stay on your current contract, you can start with the following five (5) steps to analyze your SAP landscape so you can make the smartest, most cost-efficient decision:

  1. Create an architectural diagram for your entire IT environment

Creating a graphic representation of all applications and connections, focusing on software that sends and receives data from SAP, is valuable to your organization if it doesn’t exist already. The diagram should be updated whenever new external applications are implemented or existing ones retired. For smaller companies, it may more efficient to identify only the third-party applications that send data to SAP, whereas larger enterprises will want to maintain a bi-directional application interface view.

  1. Get an overview of all connection types between SAP and non-SAP applications

You need to identify data connections between SAP systems and other software. Depending on the size of your IT environment, this may be a very time-consuming activity, but it’s useful for recognizing indirect access. Start by looking for users created in SAP that interface or exchange data with external applications.  There are tools that can aid you with this exercise, along with 3rd parties you can engage with this licensing expertise.

  1. Identify entries in the SAP tables

This is an important step in identifying whether third-party applications are updating any tables in SAP by sending data. You should keep in mind the nine document types measured for indirect use and check the tables where these documents are recorded. Based on the volume of entries registered to SAP, you can identify potential digital access risks. Note that documents created through direct access should be ignored, as well as any other documents created through SAP cloud, such as Ariba, SuccessFactors, Concur, etc.

  1. Find users who update SAP through external applications

Once you have identified all third-party applications that communicate with SAP and excluded any applications that fall under the indirect static read, you’ll arrive at a reliable user list for any interfacing third-party applications.

This list needs to be compared against a list extracted from SAP so you exclude users who already have a license assigned in the SAP system. All other users require an SAP license.

  1. Compare prices of both licensing models

Based on the number of users and the volume of documents created in your SAP system, you can decide which license type is more cost-effective for your organization. Put simply, if the interactions between third party applications and SAP generate a high volume of documents, you’ll want to stick to the old licensing model for now. If you’re not producing many documents within SAP tables, but have a high number of internal and external users, it may be more cost-effective to switch to the DAM.

Switching licensing models is certainly not an easy decision to make. You’ll want to ensure you have a complete and accurate of a picture of your SAP licensing environment, then perform a cost-benefit analysis on which model is best for your organization.

Once you’ve made the decision that’s most suitable for your company, you’ll want to be sure you are well prepared for an SAP audit. Given that SAP is pushing all customers to switch to the DAM by 2025, SAP will likely ramp up the volume of customer audits globally to capitalize on the complexity of their user-based licensing model and to leverage any software findings to negotiate conversions to the DAM.

In the last part of this series, we’ll cover how to proactively prepare for an SAP audit, and complete a software baseline and optimization effort in just 21 days.


If you want to learn more about how SAP’s licensing models, and how to protect against SAP audits or prepare for an upcoming contract renewal, contact Connor at info@connor-consulting.com today.

In part 1 of this SAP blog series, we covered SAP’s older indirect use licensing model and some of its shortcomings. To recap, many customers were dissatisfied with SAP’s licensing model, complaining that indirect use was not clearly defined, and that this led to unfair licensing practices and enforcement. Pushed by these complaints, and the visibility around lawsuits involving Diageo and Ab InBev, SAP changed their indirect use licensing model in April of 2018 to the Digital Access Model (DAM).

So what’s new about the Digital Access Model, and did it ameliorate some of the issues with the previous model?

There are two major changes in the DAM. First, the new model focuses on measuring the use of the Digital Core. The new SAP digital core platforms have been updated from SAP ECC to include the SAP HANA in-memory database, SAP S/4HANA and S/4HANA Cloud. SAP also offered a definition of indirect use, grounding the definition in the use of the Digital Core:

“Indirect/Digital Access is when people or things use the Digital Core without directly logging into the system. It occurs when humans, any device or system, indirectly use the Digital Core via non-SAP intermediary software, such as a non-SAP frontend, a custom-solution, or any other third-party application. It also occurs when non-human devices, bots, automated systems, etc. use the Digital Core in any way.” (Source: SAP ERP Pricing for the Digital Age).

By basing indirect use on the Digital Core, customers now have a clearer understanding of the specific instances of indirect use that needs to be licensed. At the same time, SAP remains somewhat vague on how far indirect use extends using all-encompassing phrases such as “in any way” and “any other third-party application.” We’ll cover some potential ramifications of these terms in part 3, but in the meantime, try to grasp Digital Core use in your environment and how your SAM tools can be leveraged to measure such usage.

The second major change that the DAM made was to shift away from user-based licenses, to a document-based model. Instead of licensing the number of users using SAP systems, the DAM calculates licenses based on the number of documents created, regardless of who created them.

The DAM outlines nine (9) system-generated document types that are considered relevant for licensing. The 9 document types are:

  1. Sales Order 2. Invoice 3. Purchase Order 4. Service & Maintenance Document 5. Manufacturing Document 6. Quality Management Document 7. Time Management Document 8. Financial Document 9. Material Document

To count the necessary licenses, SAP multiplies the number of documents by a corresponding multiplier, 1.0 for document types 1 through 7, and 0.2 for types 8 and 9. For example, 10 sales orders would be calculated as:

10 Sales Orders * 1.0 (document multiplier) = 10 licenses,

whereas 10 Financial Documents would be calculated as:

10 Financial Documents * 0.2 (document multiplier) = 2 licenses.

Importantly, license calculations are based on the initial document created, rather than documents read, updated, or deleted.

To give a more concrete example, imagine a customer using a sales management application to store sales, purchase orders, and payment data. Payment data is automatically transferred to the ERP, resulting in the creation of accounting records stored in the SAP system. Since only the financial module is updated through the third-party application, SAP will charge for the total number of accounting documents created in the system and license them based on the “Financial Document” document type.

But let’s alter scenario a bit and imagine that sales orders are registered on a web platform and are ultimately stored in an ERP. In this scenario, the initial sales order generates an invoice order first, and then an accounting entry in SAP. In this scenario, because SAP’s licensing rules specify that only the originally created document is counted, the customer would not get charged for all documents created in SAP (i.e. the sales doc., invoice doc, or financial doc.), but only the original sales order document.

To sum up, the key takeaways are:

  1. Digital Access is based on usage of the Digital Core (S/4HANA).
  2. Digital Access licenses documents, rather than licensing users.

In other words: Digital Access-Digital Core-Document Based

Currently, SAP customers can choose to license their software by named user (the old model) or by the DAM. But how do you know which option is best, and more importantly, less costly for your organization? In part 3, we’ll point out some potential pitfalls of both licensing models to help you make an informed decision about which licensing model is best suited for your organization.

If you want to learn more about how SAP’s licensing models, and how to protect against SAP audits or prepare for an upcoming contract renewal, contact Connor at info@connor-consulting.com today.

Note: This is the first of a four-part blog series

Imagine yourself in this scenario: your company runs an online business that sells products and services to thousands of daily customers and tracks all transactions through an on-premise or cloud-based financial/ERP system. All of a sudden, your ERP software vendor comes to audit you and demands true-up license fees for every single one of your customers that have ever made a transaction through the system, on top of your usual user licensing requirements. Wouldn’t you be disgusted by those findings?

Unfortunately, this isn’t exactly a fictional story, and SAP has recently taken the spotlight in the software industry for similar practices related to indirect software usage. Indirect use, which refers to virtual software use by either humans or bots, is a widely known software asset management (SAM) issue, and it has had major consequences for companies licensing SAP products.

If you’re worried about your SAP licensing and want to prepare for a potential SAP audit or right-size for an upcoming contract renewal, then our 4-part Indirect Use Guide will ensure you are ready to make well-informed licensing decisions for your company. In this 4-part SAP audit defense blog series, we’ll walk you through a brief history of SAP’s indirect use licensing methods, the ins and outs their new and improved Digital Access Model (DAM), key considerations before making the switch to DAM, and a guide to completing an SAP license assessment in about 21 days.

Part 1: SAP Indirect Use Licensing – A Brief History

When SAP first started charging customers for indirect use, they required named-user licenses for everyone accessing the SAP system through third-party applications. This meant that sales representatives and business customers who carried out sales and order related activities through a web platform were also required to be licensed for SAP products. The problem with this model was that it was often unclear what was meant by indirect use and how far it extended, as external users could be making updates to SAP database tables through a non-SAP application. Without full transparency and a clear definition of the users that required a license through indirect use, companies had a hard time managing their SAP licensing.

Understandably, many companies were unhappy with this reporting structure, and several companies refusing to pay indirect use licensing fees were brought to court, most notably beverage companies Diageo and AB InBev in 2017. Both companies refused to pay their initial multimillion-dollar license fees related to indirect use, and SAP took legal action on them.

Diageo’s case revolved around their deployment of two systems using SAP’s ERP interface mySAP. The original agreement between SAP and Diageo was signed in early 2004, and the systems in question were deployed around 2011. Ultimately, a high court sided with SAP ruling that Diageo was liable to pay SAP for the additional 54.5 million Euro licensee fees related to indirect use by customers and other sales representatives. For the most part, this case was settled in public and gave a lot of visibility to SAP’s aggressive software audit practices.

However, AB InBev’s $600 million case was settled in private. According to CIO.com, this came down to the method of enforcement. By enforcing the license agreement through Commercial Arbitration, the court case was able to be handled in private behind closed doors. For this reason, we still do not know how much AB InBev paid SAP to settle the case, although we know that the case was resolved outside of court.

As a result of these lawsuits, and the subsequent backlash from other SAP customers, SAP announced an improved approach for indirect use in late 2017. Organizations could cover any indirect use triggered by the creation of sales and purchase orders in the SAP system by licensing two engines: Sales and Service Order Processing or Purchase Order Processing. In other words, an unlimited number of sales and purchase orders could be created by an unlimited number of users, as long as you licensed the above SAP applications. However, the new model was not helpful or cost-effective to all customers, and many ended up still having to license indirect use by purchasing named-user licenses.

The Switch to Digital Access

Due to these shortcomings, SAP introduced a new licensing model in 2018, known as the Digital Access Model (DAM). While DAM is still a newer licensing model, SAP has been pushing for its customers to make the switch. In part two of this series, we’ll cover how DAM works, and the main changes from the older indirect use licensing model.

Getting Started with Your Audit Defense Strategy

If you want to learn more about how to protect against SAP audits, our compliance and software advisory experts help you successfully prepare for difficult vendor audits and boost the effectiveness of your SAM programs.

To learn more about our SAM and Audit Defense offerings, contact Connor Consulting at info@connor-consulting.com today.

Among the largest software vendors, Oracle is infamous for its aggressive audit practices. Oracle has built a compliance machine comprised of over 150 practitioners worldwide, known as License Management Services (LMS), which conducts audits of its customers in all major geographies. Due to the complexity of Oracle’s licensing rules and policies, and the costly nature of these software reviews, an audit can last for months until an official conclusion is reached.

Put simply, Oracle’s audits are one of the most feared in the software licensing world and they can bury your IT resources if you are not well prepared.

To help Oracle customers gear up and survive an Oracle license audit, we have compiled a list of common software issues that have caught many customers off-guard, leading to excessive fees paid to the vendor. We also share leading practice recommendations so you can mitigate licensing risks and reduce findings during an Oracle review.

Don’t fall into the Virtual Machine (VM) trap

If you use VMware or other virtualization solutions to host your Oracle products you need to be aware of the difference between soft and hard partitioning. Sometimes known as segmenting, partitioning occurs when CPUs on a server are separated or partitioned into individual sections, each operating as its own individual system. Partitioning can be accomplished virtually by having the OS limit the number of CPUs for a particular server, known as soft partitioning, or by physically separating segments of a server, known as hard partitioning. See Oracle’s official definitions here: http://www.oracle.com/us/corporate/pricing/partitioning-070609.pdf.

As it relates to Oracle’s licensing metrics, soft partitioning is not permitted as a legitimate method of determining or limiting “the number of software licenses required for any given server or cluster of servers.” Basically, if you’re using a virtual machine to limit the number of CPUs used by your Oracle product and only expect to pay for that usage, you will be met with an unpleasant surprise during an audit. That’s because Oracle will take into consideration all CPUs on the server or cluster and not just your virtual machine setup when calculating your deployment. Said another way, if there is a single VM on a node within a server cluster that is running Oracle, all CPUs within the cluster will need to be licensed for the Oracle application under Oracle’s soft partitioning rule.

Obviously, customers have raised a lot of complaints about this practice, but Oracle remains adamant in rejecting soft partitioning, despite most VMware environments being set up through this method. Oracle is unlikely to change its stance on this issue, so we strongly recommend that you review your entire system architecture and underlying hardware’s physical processors before setting up a virtual environment with Oracle software.

License all non-production environments

One of the most frequent mistakes that Oracle customers make is installing software on their non-production environment without paying for it.

According to Oracle’s licensing rules, it is mandatory for organizations to license all development, test, staging, and pre-production environments the same way they would license production environments. Keep in mind that you are required to use the same licensing metrics for both production and non-production environments. When you calculate your license requirements, you also need to consider all instances within your organization, including database and application software. Be especially careful when there are any changes to your system architecture that may increase the processor count, such as the addition of new servers or moving a node from one Oracle server cluster to another.

Some customers may have negotiated special clauses in their agreements to license non-production environments differently, but you should assume that’s not the case for you unless you’ve verified otherwise in your contractual language.

Take the time to understand your Unlimited License Agreement

The Unlimited License Agreement (“ULA”) is one of the most confusing agreements that Oracle offers to its customers. You might think that having “unlimited” in its name grants you full rights over how you use the software and what software you can deploy. In fact, this agreement very specifically limits the number of products you can use, where you can use those applications, and how long you can use them.

ULAs are generally limited to specific entities and include a pre-defined list of products which require an upfront payment. They also include specific provisions regarding the termination of the contract. At the end of a typical 3-year term, customers have two options: to renew the ULA or to terminate it. If you end your ULA, you are required to certify all Oracle products and this certification must be signed by a C-level officer of your company. This means you need to declare installations of each ULA product, providing the required license counts across your IT environment. Oracle then draws a “line in the sand” and grants you perpetual rights to the declared software quantities for which you pay support and maintenance fees, governed by the ULA clauses. Be advised that Oracle may challenge your certification numbers and request additional support or detail to verify the figures. In some cases, the sales team may suggest that you work with LMS to obtain more specific or accurate certification numbers by running their home-grown scripts across your Oracle landscape. In these instances, there is likely suspicion that your counts are inaccurate or that you’re “stockpiling” your deployments which is prohibited by your license agreements.

Also, if you miss any installations during the certification, your usage will not be entirely covered by the perpetual licenses granted at the end of your ULA, and you will be non-compliant for any undeclared software running in your environment.  Another licensing “gotcha” is that Oracle does not allow you to declare software licenses deployed in the public cloud (e.g., AWS or Azure). You can deploy software in these environments, but they are not counted as part of your certification, so upon ULA expiration, you’ll likely be out of compliance for these cloud-based deployments.

In order to avoid paying extra fees after your ULA terms, we recommend performing an internal assessment each year to have a definitive summary of your Oracle deployments before the expiration date approaches. It’s leading practice to leverage LMS scripts or utilities that are recognized by Oracle to baseline your software installations on-premise and in the cloud, and to begin this process at least 6 months before your ULA end date.

Don’t be fooled by pre-installed options and packs

Another issue frequently identified during Oracle audits is the deployment of product options and packs that were not intended. These licensing pitfalls mainly apply to Oracle database products since they have a plethora of supporting features. Depending on the version, the database product includes additional options and packs (e.g., fine-tuning pack) that are automatically enabled during installation, and it’s not highly intuitive for IT users to “unselect” them. This is very common for customers who leverage Oracle Enterprise Manager (“OEM”) to manage their Oracle deployments. Before the release of the 11gR2 database, end-users had the ability to select or deselect the desired options during the installation of the database. However, it was still an issue because most end-users believed they were entitled to use everything that was being offered in the installation panel.

We believe this is the most covert licensing tactic that Oracle employs since the vendor allows you to install these options by default and without any disclaimers, and they are not generally covered by the standard database license in your agreement.

So, what can you do? Although Oracle software which is installed and/or running technically needs to be licensed, in practice LMS usually only charges for options found in use at the time of the audit. Since LMS has its own scripts to scan Oracle environments, it is only during the audit that most of the customers are faced with non-compliance findings and are required to pay extra fees. In order to avoid these unplanned fees, it is recommended to have your Oracle administrators implement internal controls and procedures to keep track of all these enabled options and the associated usage. You should instate a process that allows you to self-audit your Oracle environment and disable features, options, and packs that aren’t needed to support your applications.

Spend a bit more time to understand your licensing metrics

Metrics are often treated lightly by organizations when they buy software, but they are at the core of any licensing model. Despite its importance, most organizations don’t have the expertise or enough bandwidth to go through their agreements, identify their licensing metrics, and understand how they affect purchasing and software requirements.

It certainly doesn’t help that Oracle offers a wide range of licensing metrics and policies for their growing product portfolio. Customers can easily get confused with the various metrics including “Named User Plus” (NUP), “Processor,” “Application User,” “Monitored User,” “Expense Report,” and so on. Each licensing metric measures deployment differently and is used to calculate the applicable fee for the associated software product.

We recommend checking the metrics defined in your agreements with your Software Asset Management (SAM) department or software experts familiar with Oracle licensing, compliance, and audits. Creating a centralized matrix with each Oracle product and the corresponding metric may help you keep track of your Oracle licenses and usage. Ideally, this information should be maintained within your SAM tool, where automated reconciliations are performed against your Oracle deployments referencing these product metrics. At a minimum, mock audits should be conducted to proactively identify and remediate Oracle licensing gaps, well ahead of any ULA certification or contract renewal.

Connor Consulting is here to help

Although Oracle’s licensing rules may seem overwhelming and are not always easy to follow, Connor Consulting can help you successfully navigate through the pitfalls of Oracle’s licensing environment. Our practitioners have years of software licensing, contract compliance, and IT sourcing experience for major vendors including Oracle, SAP, and IBM, and we have helped many IT organizations prepare for difficult vendor audits and boost the effectiveness of their SAM programs.


To learn more about our SAM and Audit Defense offerings, contact Connor Consulting at info@connor-consulting.com today.



Are SAP audits completely transparent and easy to follow?! The short answer is no, simply because SAP’s licensing models are as complex as their products. After organizations spend years to implement SAP products, they believe they’re done, until they receive an audit notification letter from SAP in order to uncover any intentional or inadvertent software sprawl within the organization. Much like other software vendor audits, their goal is to recover lost revenues.

Usually, each software vendor has its own auditing methodology and SAP makes no exception. Compound these unique auditing methodologies that are difficult to follow with highly complex IT environments, and it’s no wonder many customers tend to miss key information when they acquire SAP software and end up using more licenses than they originally paid for. This combination of miscommunication between SAP and their customers, lack of knowledge on how software licensing works, along with the inherent complexities of their IT environments and SAP contracts, drastically increases the odds of software over-deployments or failing an audit.

At Connor Consulting, we have extensive experience in Software Advisory and SAP Auditing with seasoned leaders who have conducted hundreds of license assessments and have established effective software asset management (SAM) programs for Fortune 500 companies. Based on our deep knowledge and a proven track record, we’ve compiled a list of leading practices you need in your toolkit to pass an SAP License Audit.

1. Keep track of all the things you agreed in writing with SAP

This goes without saying, but in comparison to other IT supplier agreements, SAP contracts can be very complex, and the extensive use of legal jargon makes them difficult to understand and translate for software tracking purposes; however, you need to be in control of your license purchases at all times and keep a record of any custom licensing models or metrics.

Make sure to keep track of all contracts and order forms. You can create an SAP vendor risk matrix, where you inventory your active licensing agreements, detailing key dates, products, metrics and highlighting any high-risk contract provisions (e.g., audit and/or M&A clause). In case you miss any, don’t hesitate to contact SAP and request your copy. It’s always better to be prepared, otherwise, you will regret it when SAP issues the proverbial audit letter to your CIO. Also, never rely on SAP or its audit agent to provide you with the correct license entitlements during a review. It’s imperative that you always double-check those figures to minimize any potential non-compliance and/or the need for future software purchases.

2. Make sure you are always able to collect the metrics agreed with SAP

There’s a wide range of industries and business functions that SAP products cover. So naturally, there’s also a great variation of the metrics used to measure consumption. Hence, to understand your license consumption, you need to be aware of your specific metrics that aren’t always spelled out clearly in purchase documents or software contracts.

To achieve that, one common method is to perform a license verification by running the transaction codes “USMM” and “SLAW.” These are the measurement tools offered by SAP, native to the applications; however, in most cases, this information will not be enough. There might be metrics customized for your business that cannot be measured automatically or systematically. For example, “annual sales revenue” or the “number of local stores in your distribution chain,” or the “number of beds” can be a license metric if you are a hotel chain.

Getting all of this data for an audit can be very time-consuming and may involve multiple departments within your organization. As such, you might want to have a repeatable process for collecting this information periodically or as part of your regular software asset management operations. Remember, SAP will have you fill in a self-declaration form for all of your licensed metrics, and your responses are expected to be both timely and accurate. If there are holes or figures that raise “red flags,” it could warrant further audit inquiries and prove to be very costly for your organization.

3. Never delete an inactive user from the system

SAP, through the usage data you are required to send during an audit, will also see a report of all the users that have been deleted from the system. Of course, user accounts deleted prior to the audit will be a contentious point for SAP due to the way they license their software in customer agreements. SAP employs a “named user” licensing model, which means you cannot have multiple persons using the same account.

There are different types of “named user” licenses. From the Professional User, which is the most expensive license, to Employee or Employee Self-Service, which are the most basic and relatively inexpensive license types.

Based on your contract terms, it’s your SAP administrator’s responsibility to assign the correct license type to the people in your organization. Furthermore, you always need to control the number of users, their license types and their roles so that it stays within contractual limits. When SAP performs an audit, they investigate all users created in the system and their assigned license type. It doesn’t matter whether they are active or not. As a result, you might end up paying additional license fees even for users that are no longer your employees. Ongoing tracking and maintenance of SAP user accounts are essential SAM related tasks that can help reduce licensing fees and optimize your SAP user environment.

The best approach here is to not delete inactive users, but instead, lock their user ID, set an end date and remove their assigned roles. As an extra measure of caution or audit risk mitigation, you can also move all locked user accounts to a user group created for “Expired” or “Terminated” users.

4. Beware of huge indirect access charges

Indirect usage of your SAP software requires additional licensing and you may not even be aware of it. Indirect access happens when third-party applications connect to SAP ERP and extract or modify information in the database. SAP will investigate those and will charge a lot of money for improper licensing.

The issue with keeping track internally of your indirect usage is that it’s a time-consuming process and you need to understand SAP’s indirect access rules before performing any sort of internal mock audit. In addition, you run the risk of double-counting users who already have an SAP license assigned for the direct usage.

Your best option is to use the available inventory tools. They are not free, but they will save you precious time and minimize the amount of data errors. If you’re looking for unpaid tools, recently SAP has released a tool that aims to support customers in analyzing their indirect usage. Unfortunately, as per SAP’s release notes, it’s still under development and doesn’t offer many useful features for customers now.

Much more useful than SAP’s utilities are third-party inventory tools. They work by searching for any type of documents exchanged by external applications with the SAP system (e.g. sales documents, purchase documents, material documents, etc.). Additionally, SAP access via any other technical interface such as “RFC,” “BAPI,” or “Idocs” will be determined. The results will indicate whether there is any risk for indirect access, as well as any license gap between SAP usage and contractual entitlements.

5. Make sure you correctly uninstall SAP software

Improper uninstallation of software leaves traces that can be misinterpreted by SAP. As such, if there are any historical installation traces identified on your production or development systems, SAP might consider the product still in use and will assess a fee for those licenses. On a regular basis, make sure that you perform system maintenance as part of your normal SAM operations to keep your SAP environment clean.

An effective way to do that is to periodically simulate an audit to detect false positives or remnants of prior installs and plan on how to deal with them. As mentioned above, you can generate your software usage report by using SAP transaction codes like “USMM” and “SLAW” or run certified inventory tools. Based on the usage report, you will be able to identify those metric IDs that are no longer relevant, and which might indicate an old installation of the engine.

However, the best thing you can do is to have a process on how to correctly uninstall your software. All the steps for a correct uninstallation can be found on SAP’s support portal and can be accessed with your customer credentials.

SAP audits are among the most nerve-wracking and frustrating vendor audits because of the complexity of their licensing models, their large product portfolio, customized software metrics, and the list can go on; however, if you follow these five (5) best practices, you will have a better chance to successfully pass an SAP audit and may even have an opportunity to optimize your licensing environment.

If you’re interested in learning more about SAP audit defense leading practices and how your company would perform during an SAP audit, contact us to schedule a free high-level SAP license assessment today.

San Francisco, California., July 10, 2018 — Connor (http://connor-consulting.com/), a global leader in contract compliance and software licensing today announced the appointment of Rich Reyes as Executive Vice President (EVP) responsible for leading the company’s newly formed Software Advisory practice, including operations and client delivery for key accounts.

“Rich’s deep experience in software license compliance, asset management and IT spend management gives him a unique perspective that our clients have been clamoring for,” said Viresh Chana, Founding Partner of Connor. “ His expertise and experience will be a competitive advantage to our Software Advisory clients as Rich will bring valuable insights for our clients as they tackle their IT risks and software audits.”   

Most recently, Rich was a Managing Director at ClearEdge Partners, providing software asset management (SAM), cloud migration license readiness, and IT contract optimization services to Fortune 100 clients.  Prior to ClearEdge, Rich created and ran the SAM department at Safeway, later acquired by Albertsons Companies. He helped Safeway navigate through the IT supplier and contractual risks of M&A and was responsible for the IT Asset Management and Strategic Sourcing functions of the combined company, which had roughly $60 billion in total annual revenue.  Rich has a Big-4 background and also spent several years in the software industry overseeing customer audit programs.

“I am incredibly excited to join the Connor team, filled with an amazing group of thought leaders and consultants worldwide, who bring extensive Big-4 experience and industry insights from Fortune 500 companies,” said Reyes.  “Our practitioners are deeply versed in contract compliance, software licensing and SAM, but I truly believe it’s our commitment to delivering actionable insights and inspired outcomes with an innovative client approach that sets us apart from our competitors.”

With the launch of the Software Advisory practice led by Reyes, Connor is providing the following professional services to companies:

  • Audit Playbook & Defense
  • Software Asset Management (“SAM”) Services
    • Program Design & Implementation
    • Program Fitness & Assessments
    • Practice Audits & True-Ups
    • Managed SAM
  • Cloud Migration Software License Readiness
  • M&A Software License Preparedness
  • IT Contract Optimization

For more information about Connor and Rich Reyes, visit http://www.connor-consulting.com/.