In recent years, new products and “new” license metrics such as HANA licensing, SAP engines, indirect access or the cloud have made it almost impossible for licence holders to establish transparency or gain a clear overview of the SAP licences they use and need in their companies. Many SAP customers were perfectly comfortable with this; after all, they had “the best SAP contract” and the “best conditions”, why would they need to take a closer look at their license usage? Now this attitude is coming back to haunt them, as they find themselves facing multiple challenges with regard to their SAP license management – challenges that cannot be resolved with SAP audit tools or manual Excel-based solutions. Their actual need for SAP user licenses is based entirely on SAP system usage, which – as we have long been aware in SAP user and role management – changes constantly.

1. SAP license purchases are based on estimates of future system usage. When SAP products are launched, the customer’s existing license pool is usually not taken into account. This is due to the fact that the SAP sales department’s offer is based entirely on information provided by the customer. In most cases it is however impossible for SAP customers to determine how many employees will need a license, or rather, precisely which employees will need licenses in the future, before the project actually starts (before the product is launched). As a result, the amount of required user licenses has to be estimated, which leads to SAP customers buying new SAP licenses for employees who already have the necessary usage rights. Overlicensing is therefore almost always inevitable.

2. Interpretation of different license types: SAP has been offering new user license types on their price lists for some time now. Compared to the expensive “SAP Professional User” license, prices for these license types are extremely attractive. Their descriptions, unfortunately, are not. As has been the case in the past, they leave room for interpretation. For instance, no list describing exactly which transactions a user is permitted to execute with the corresponding license is provided. But without this information, how can a company determine which license types they need? The wake-up call usually comes with a SAP system measurement further down the line, when SAP “claims” that the license type is not sufficient for its actual use. Then the company will have purchased the wrong license types and find itself additionally paying for expensive maintenance it cannot even use.

3. Allocation of Named-User license types: According to SAP’s standard terms and conditions, SAP customers must allocate licenses in accordance with their use. However, before users can work with SAP, they have to have the necessary SAP permissions. These two terms are often confused, making allocation of Named-User licenses based on allocated SAP roles extremely costly. Anyone who is familiar with SAP permissions knows that every SAP user has more permits than he or she actually needs. There is no effective way to avoid this, as business needs result in permits for SAP roles increasing constantly over time. And because uses are constantly changing, allocating license types manually in SU01 doesn’t make things easier either. An employee who needed a “SAP Worker User” license last month, for instance, might need a “SAP Project User” license this month because he or she has changed departments and therefore their field of work. The SAP basis department however will frequently be unaware of these changes. The result: user licenses are allocated incorrectly and the license pool does not match the actual usage.

4. Constant changes in license demand: As previously stated, usage of SAP systems varies constantly. Employees leave the company, new staff are hired or their roles change. Today’s license pool can already be the wrong one next year. But how can companies monitor these changes? Which of their obsolete licenses can they shut down? Manual tracking via Excel lists cannot answer these questions. The same goes for SAP engines. The amount of and need for purchased licenses is constantly increasing – from SAP’s point of view. New SAP products replace old ones which are no longer being developed. These licenses could potentially be changed. But how can companies stay on top of these processes? What has been installed? What is still in use and what isn’t? A SAP audit is of no use here because SAP still measures many SAP engines incorrectly, if it measures them at all.

5. Commercial challenges through constant changes to the Pricing and Conditions List (PCL): SAP issues a new list of prices and conditions every quarter. DSAG endeavours to document the changes. But who has time to go through a long list of changes every three months? Which alterations could affect your own business? Are the changes relevant? In principle, only the specific PCL that applies when you purchase your SAP licenses matters. But if you want to proactively optimize your license pool, you should know which license metrics have changed. Is the product you bought a year ago still available at the same conditions in the current price list? Or will you have to switch to another metric in the short or medium term? Will the new metric be cheaper or more expensive for you?

6. Unspecific contracts and price lists: Even if you are familiar with your company’s SAP contract(s) and the corresponding Pricing and Conditions Lists – the descriptions offer no clear interpretation. You basically never know if the SAP sales department (SAP compliance department) will unexpectedly present you with new demands during the next contract negotiation. As the current case regarding “indirect access” illustrates, this represents an incalculable financial risk for all SAP customers. Furthermore, it depends when SAP NetWeaver was introduced. Mrs Renate Thomas-Marcinkowski of Continental Automotive GmbH pointed out at our last Expert Roundtable in Cologne that depending on the NetWeaver license options chosen in 2007, “indirect access” may be a non-issue – something probably only few SAP sales representatives or SAP customers know. The same goes for the SAP product “Open Hub”: the external systems connected via Open Hub do not require additional licenses for what is known as “indirect access”. In such cases, an initial SAP system architecture analysis has to be carried out in addition to the SAP contract analysis and the SAP system use analysis in order to determine the actual demand for SAP licenses.

7. SAP system measurement: Any SAP customer will probably have realised by now that his or her actual license demand cannot be determined with SAP’s audit tools. From SAP’s point of view, the SAP audit tools have only one purpose: to generate more turnover from long-standing customers. It’s no secret that these audit tools are flawed and may produce inflated results because the user summary is not working optimally or license consolidation fails to correctly consider the client-specific license types. The manual system clean-up many businesses perform is time-consuming and prone to errors. SAP engine measurement has already been discussed. “Indirect access” cannot be measured at all. Java systems? HANA? Business Objects? Of course SAP is continuously developing its audit tools. Particular caution should be exercised with LAW 2.0. SAP needed an entire year to get it working at all, and it is still defective in many areas. I can only advise against using it at this point in time. But what will SAP be able to measure in the future? Will it be able to recognise if a SAP user with a “SAP Worker User” license performs a transaction that is not part of the Worker User scope? If I were responsible for these things at SAP, I would include this in system measurement in the future.

8. Compliance, a legal necessity: “Compliance” is a difficult issue when it comes to SAP licenses. Basically, you can never really be SAP compliant. The SAP contracts, the Pricing and Conditions List and the descriptions are far too vague. On the other hand, CEOs are personally liable if they commit copyright infringement. This applies, for example, if SAP systems are used without having purchased the corresponding user licenses. Or in other words: if the company is underlicensed. That is why I believe SAP’s vague descriptions are a trick they will probably keep up in the future. Worried about underlicensing, SAP customers will prefer to purchase more licenses than they actually need. That way, they feel on the safe side. As long as the SAP sales department is happy, so is the CEO. And SAP will grant you a generous discount for the purchase of your useless excess licenses. So, the SAP customer manages to get “the best deal” again. Wouldn’t it be better to just buy what you really need? That would also be a way to achieve compliance.

Conclusion

SAP licensing is an increasingly complex topic in which SAP does not support its clients. Instead of helping them, customers are confused by questionable additional demands and inadequate audit tools. The consequence are unnecessary license purchases in the order of millions – not least due to fear of underlicensing. Manual “system adjustments” prior to a SAP system measurement or tracking use via Excel do not solve these challenges. SAP customers who become aware of these challenges seek the assistance of external SAP license experts who not only have the corresponding experience at their disposal but also the tools to regain transparency within the SAP license jungle. Only those who have a constant overview of their SAP system usage know what they need to purchase and when, and which user licenses to shut down.