Eight challenges in SAP license management
In recent years, transparency and thus the overview of the SAP license used and required has been completely lost due to new products as well as "new" license metrics (Hana licensing, SAP engines, indirect use or cloud).
This didn't bother many SAP customers: After all, they had the "best SAP contract" and the "best conditions". So why should they take a closer look at license usage?
Today, it turns out that they would have done better. Because now they face numerous challenges when it comes to SAP license management. And they can't even begin to solve them with SAP audit tools or manual, Excel-based solutions.
The SAP license requirement (usage rights) is based 1:1 on the usage of the SAP systems, which - as has long been known from SAP user and SAP role management - is constantly changing.
1. SAP license purchases are based on estimates of future usage.
When new SAP products are introduced, the existing customer-owned license inventory is usually never taken into account. This is because SAP Sales submits its offer to SAP customers on the basis of information that they themselves have provided in advance.
At the same time, before the project begins (product launch), customers usually cannot know exactly how many employees will need a license or who exactly these employees will be in the future. As a result, the number of required usage rights must be estimated.
And this inevitably leads to SAP customers buying new SAP licenses for employees who already have the required usage rights. Thus, overlicensing is usually unavoidable.
2. interpretation of different types of licenses:
For some time now, SAP has been offering new SAP user license types in its price lists. The prices for these license types are extremely attractive compared to the expensive "SAP Professional User" license. Unfortunately, the descriptions are not.
As in the past, the descriptions leave room for interpretation. For example, a precise list of which transactions a user may execute with the corresponding license is not provided. But without this list, how can you decide which type of license you need in your company?
The awakening usually comes at the later SAP system measurement, when SAP "claims" that the license type is not sufficient for use. Then, as a rule, you have bought the wrong license type and pay for the expensive maintenance, even though you cannot use it at all.
3. allocation of named-user license types:
According to SAP's terms and conditions, SAP customers must issue licenses based on usage. However, before a user can use SAP, he or she needs the corresponding SAP authorizations. These two terms are often confused with each other.
Thus, assigning named-user licenses based on the assigned SAP roles can be expensive fun. After all, anyone familiar with SAP authorizations knows that every SAP user has more authorizations than they actually need.
This cannot be prevented effectively because the rights in the SAP roles increase constantly over time due to the requirements from the business. However, the manual assignment of the license type in SU01 does not make the assignment any easier due to the constantly changing uses.
For example, an employee who needed an "SAP Worker User" license last month may already need an "SAP Project User" license this month because he has changed departments and thus his work area. However, the SAP Basis department does not usually notice these changes.
As a result, usage rights are assigned incorrectly and the license portfolio does not match the actual usage.
4. constant change in licensing requirements:
As described above, the uses of SAP systems are constantly changing. Employees leave, new employees are hired or their activities change. The license inventory you have today may be the wrong one next year. But how to monitor these changes? Which of the licenses that are no longer needed can be decommissioned?
Keeping manual Excel lists cannot answer these questions. The same applies to the SAP engines. The inventory or demand is constantly increasing - from SAP's point of view. New SAP products replace old ones that are no longer being developed. Licenses can be converted if necessary. But how do you keep track? What has been installed? What is still used and what is not?
Against the background that many SAP engines are still not measured by SAP or are measured incorrectly, the SAP audit does not help at this point.
5. commercial challenges:
through constant changes to the Price and Conditions List (PKL): A new PKL is published by SAP every quarter. DSAG endeavors to document the changes.
But who can read the long list of changes every three months? Which change, if any, affects you? Are the changes relevant? Well, basically you only have to be interested in the PKL at which you buy SAP licenses.
However, if you want to proactively optimize your license inventory, you should know when which license metric changed.
Does the product I bought a year ago still exist at the same conditions in the current price list? Or do I have to switch to another metric in the short or medium term? Is the new metric cheaper or more expensive for me?
6. non-specific contracts and PKL:
Even if you know your SAP contract (SAP contracts) and the associated PKL - the descriptions do not allow for a clear interpretation. Basically, you never know if SAP Sales (SAP Compliance Department) will unexpectedly approach you with new demands during the next contract negotiation.
As the current case of "indirect use" shows, this presents all SAP customers with an incalculable financial risk. Furthermore, it depends on the point in time when SAP NetWeaver was introduced.
Ms. Renate Thomas-Marcinkowski from Continental Automotive GmbH pointed out to me at our last Expert Roundtable in Cologne that, depending on the NetWeaver license selected in 2007, the topic of "indirect use" was completely covered.
A fact that I'm sure very few SAP sales employees or SAP customers are aware of. The same applies to the SAP product "Open Hub". The external systems that are connected via Open Hub also do not need to be additionally provided with licenses for so-called "indirect use".
In addition to the SAP contract analysis and the SAP system usage analysis, an SAP system architecture analysis must also be performed here for the first time in order to determine the actual need for SAP licenses.
7. SAP system measurement:
By now, it should be clear to every SAP customer that it is not possible to determine their actual license requirements with SAP's audit tools. After all, from SAP's point of view, the SAP audits have only one purpose: to generate more revenue with existing customers.
It is no secret that these audit tools are flawed and may overcharge because user aggregation does not work optimally or license consolidation does not properly account for customer-specific license types. The manual "system cleanup" performed by many companies is very time-consuming and error-prone.
I have already mentioned the topic of engine measurement above. "Indirect usage" cannot be measured at all. Java systems? Hana? BusinessObjects? SAP is, of course, constantly developing its audit tools. You should be especially careful with LAW 2.0.
After it took SAP a whole year to get it working at all, it still works incorrectly in many areas. I can only advise everyone against using it currently. But what will SAP be able to measure in the future? Will it be able to detect that an SAP user with an "SAP Worker User" license has executed a transaction that is not part of the functional scope?
If I were responsible for this at SAP, I would check this in the SAP system survey in the future.
8. legal compliance obligation:
The topic of "compliance" is a difficult one in connection with SAP licenses. Basically, you can never be compliant with SAP. The SAP contracts, the PKL and the descriptions are far too vague for that.
On the other hand, CEOs are personally liable if they commit copyright infringements. Among other things, this is the case if SAP systems are used without the corresponding right of use having been acquired. Or, to put it another way: if you are underlicensed.
For this reason, I think SAP's woolly descriptions are a trick that it will continue to use in the future. For fear of underlicensing, SAP customers prefer to buy more licenses than they actually need.
That way, they feel on the safe side. And as long as SAP sales are satisfied, so is the CEO. But then SAP gives them a generous discount for the useless licenses they bought too much. D
he SAP customer has thus once again received the "best contract". But wouldn't it be better to buy only what you really need? This is another way to establish compliance.
Conclusion
SAP licensing is an increasingly complex topic in which SAP does not support customers. Instead of helping their customers with this, they are further unsettled by dubious subsequent claims and inadequate audit tools.
The result - not least due to the fear of being underlicensed - is unnecessary license repurchases in the millions. Manual "system cleaning" before SAP system measurement or tracking usage on an Excel basis do not solve the challenges.
SAP customers who have become aware of these challenges are seeking support from external SAP licensing experts who have the relevant experience as well as the tools to restore transparency in the SAP licensing jungle.
Only those who have a constant overview of the use of their SAP systems know what they need to purchase and when, or which usage rights they can part with.
