SAP’s self-declaration products: What are the technical metrics?

SAP self-declaration products raise a lot of questions among the end users and most of you probably searched throughout Google pages trying to find a response. How to find out the license metric and current value of metrics? Does this sound familiar? If it does, read on. In the first article of our “How much do you know about the SAP self-declaration products?” series, we explained what SAP’s enterprise metrics are and in which circumstances enterprise metrics represent a more favorable licensing model. In the second article, we aim to shed some light on the technical metrics and briefly describe the most common compliance issues for technical metrics.

Technical metrics

When your company is growing rapidly in terms of employees and revenue and/or a software program is not used by the entire company, then the best option might be to license your software using a metric which can be technically measured, if SAP offers the licensing of such program on such metric.

The so called technical metrics’ measurements are typically depending on the hardware or software architecture of the licensed software program (e.g. number of cores, virtualization instances) or usage information that should be collected from a software program’s interface (e.g. users accessing it).

Keep reading and you’ll discover why measuring the use information of these products is far from straight forward.

Number of cores

Most of the self-declarable engines (SAP applications) with a technical metric are sold by SAP by number of cores (e.g. Hybris Apps). So, what should you count? “The number of cores in CPUs (central processing units) that are available for use by the licensed software” (Software Use Rights). The calculation method differs depending whether virtualization is in place.

For some of the SAP users it becomes confusing when some applications are licensed on number of cores per CPU while for others the metric is CPU. The latter has been inherited by SAP when they acquired the BusinessObjects Company. Its definition stated the same principle – counting the number of cores per CPU where the software program is deployed. Thus, although the metric name doesn’t explicitly mention “cores”, the metric definition is very clear. Since BusinessObjects BI Package is no longer included in SAP’s offer, solely existing BI Package customers still have this metric.

Counting the number of cores is useful when you deploy the software program for a large population of users on a limited number of servers. This makes the CPU consumption relatively small in terms of cost compared to user-based licenses.

Number of users

A high number of self-declarable SAP engines (such as SAP Profitability and Cost Management, SAP Process Control or SAP Digital Asset Management by OpenText) are licensed by the number of users “directly or indirectly accessing the software”.

This metric should not be confused with the SAP Named User Licenses for Classic ERP (professional user or limited use licenses) that are required anyway for users to access the SAP engines.

Basically, without having an SAP License Type assigned (professional, employee, employee self-service, etc.) an individual cannot even access an SAP engine. This is the principle that governs SAP’s licensing practices.

In most cases, the users accessing a certain engine will be visible in each application interface. If they are not visible there, the application owner or administrator should keep track of the users authorized to access the software program.

Given this, identifying the user population can be quite a struggle, contrarily to Classic ERP user license types which are easily detectable through USMM. On top of this, each application has a different architecture and display of its user interface, so applying the same instructions to all of them is impossible.

Counting the number of users instead of CPU/cores usually is in the end users’ advantage when the authorized users’ population is not very high compared to the servers’ processing capacity where the applications are deployed.

Reporting or analytics applications are the most feasible to be licensed on number of users.

Number of objects

When we talk about licensing based on number of objects, these items are characterized by the following principle: summing up the items registered in a software program.

An object can be represented by supplier items (stored in a Master Data Management repository for example), material items (product, article, contract, asset, etc.) or even business partners (a business partner is a person within an organization, a group of persons or even the entire organization having a business agreement with the end user).

What can go wrong when licensing by the number of objects? Not being able to identify the repository where these objects are stored or not being able to separate the objects depending on your specifically defined metric (e.g.  master data object, business partner objects or customer objects) Depending on the nature of these objects, they can be files created internally by your employees or contractors, or externally by customers or partners).

What can you do? Document right from the beginning the technical aspect of the application you deploy. Create a process for monitoring the objects creation and keep an eye on the license quantity.

Common compliance issues for technical metrics

Self-declarable products in general are not captured by SAP’s standard measurement tools.

As a result of this, end users should monitor the usage consumption of the technical metrics on their own and should keep track of the consumption.

However, more often than not we see that end users do not have a process for maintaining the users’ access (for example checking every 6-12 months if the users accessing the applications are still active or they still need the access).

Based on our experience, this is due to the difficulty of retrieving the use information. If you perform a compliance check, make sure you document your findings and create a process to be followed during your next internal audit.