The new SAP licensing model can be expensive!

Serious consequences of unchecked authorizations during S/4 migration

In the future, everything but a greenfield approach to the changeover will actually no longer make sense. The far-reaching consequences of the change from consumption-based to authorization-based licensing are fatally underestimated by most existing SAP customers. At an online IT conference held at the end of January, a company survey on checking SAP authorization roles confirmed this impression to a large extent: A good 85 percent of companies check these roles only irregularly or not at all, or do not want to or cannot provide any information on this - which experience shows is based on the latter. Too many are therefore unaware of the consequences of the new licensing model for migration, and this should change as soon as possible.

Over the past 25 years, SAP authorization projects have traditionally looked like this: Usually under time pressure, an authorization concept was defined that somehow worked compliantly, and roles were then simply built so that users could use what they needed, see pages 12 and 20 of this issue.It is also clear that the question of licensing has been neglected in the technical assignment of authorizations in most companies to date, which has often led to authorizations getting out of hand. Some users have up to 500 authorizations, of which only 25 percent are needed at most.

If customers are now asked which licensing model and authorization concept they are using to prepare for the switch to S/4, they are usually unaware of what the choice between a product and a contract conversion ultimately means. Until now, no one has given serious thought to the fact that there could be different access technologies with monetary implications. But this is exactly the case now: New technologies in S/4 projects require corresponding scenarios, the SAP license model has become more and more complex and is now changing fundamentally!

Product Conversion 

A Product Conversion primarily means that old contracts remain in place for the time being and seems to have the least impact. In contrast to Contract Conversion, it is possible here to retain the existing contracts with SAP and thus also their terms and conditions for licensing. New products from S/4 are then added, which means that anyone who wants to use a new engine that is only available under S/4 buys it and licenses it accordingly. But he remains more or less in the ECC area with his usage licenses and continues to miss according to consumption and not according to authorization. This means that there is no conversion from existing licenses as in the case of contract conversion. Initially, a contract for the specific additional purchase is simply added to the existing one, and the licensing continues to be based on actual use.

Contract Conversion

A contract conversion is basically the replacement of the existing contracts. One takes the existing contracts, the license value and also the software value, which is in these licenses and contracts, together and evaluates them. A new contract is then created for S/4 and this applies from then on with all its consequences. The decisive factor here is: In S/4, licensing is now based on theoretical authorizations and no longer on actual use by the user. For this purpose, SAP records over a standard period of three months which authorizations a user could have used in the system - for which a license is then due solely on the basis of the possible use.

What is then relevant is no longer the actual transaction, but simply everything that could theoretically have been done with one's authorizations. And that can be extremely problematic with the overly generous authorization concepts described above. In addition, tools that previously provided very reliable results for optimizing SAP licenses have become obsolete with the new licensing model.

The fallacy

The comparison of the two approaches could lead to the comfortable conclusion that if you choose Product Conversion, everything remains the same as far as permissions are concerned, and only Contract Conversion brings the problems described above into the house. In many respects, however, this is too short-sighted. This is because there are new applications in the new models, while others are dropped, and if you then build roles, the smallest change can lead to them no longer being license-compatible, which has the corresponding consequences.

In addition, experience shows that in the event of a product conversion, the required permissions for the newly purchased products are usually simply added to the old roles. As far as the role is concerned, this is expanded instead of being reduced to a healthy level. As a result, there is hardly any examination of the existing SAP roles, with the consequence that authorizations that are no longer needed are still not removed. Apart from the still urgent security issue, however, the following now applies: Excessive authorizations will become very, very expensive in the medium term. 

Experience shows that, on average, a user needs just 25 percent of the permissions assigned to him or her, which is not a problem in the short term, at least not financially, as long as licensing can be based on consumption. In the medium term, however, there is no way around the fact that licensing will have to be based on authorizations. The experience of the last few years in the ECC area has shown that these changes will definitely come, even if the outcry in the DSAG e. V. and other committees is great. From this point on, without exception, it will no longer be the did-do of a user that decides, but exclusively the could-do. And then those 75 percent that have never been used will be included.

What to do?

As a first step, SAP now offers a tool to determine at the push of a button whether a role is expensive. After a non-binding registration, an Excel table shows which authorization object is assigned to which license type and to what extent. And you can use a test run that outputs exactly how expensive an S/4 license would currently be. The result should prompt most companies to address the problem immediately. But how then does one future-proof authorizations and licenses in the role migration project? The clear answer is: Anything but a greenfield approach now makes no sense with S/4 authorizations! Here, it is also no use to say we are cleaning up, because this is not done as thoroughly as a new creation.

The approach: Green Field with tool support

The correct approach to a best practice is to determine what was really needed by performing a consumption analysis of all users in the current system, and to perform a role analysis as a follow-up to the consumption analysis. Once it has been clarified how the current roles reflect actual consumption, the licenses are reallocated on the basis of the consumption analysis. In order to accomplish this, tools such as those from Pathlock are indispensable at this point in time for the continuous monitoring of the results. This applies both to the analysis of what is being used and to the results of role and entitlement re-creation.