It’s a contentious discussion that’s been going on for quite some time. Lately, we often get asked this question: Do you have to assign SAP named-user licenses based on roles and authorizations or actual use? It’s time for an answer.
You probably won’t be surprised that SAP provides different information on this subject. On the one hand, SAP likes to refer to a common passage, which is found in every license description: “… is a defined user who is entitled to use the following [roles] of the software, for which he acquired the software rights …”. On the other hand, SAP writes in their System Measurement Guide1:
“To be able to measure all users of your SAP installation clearly and exactly, you must classify your users in accordance with the current use and the underlying price list before every system measurement.”
Why SAP license allocation cannot be based on authorizations
In order to assess whether it would be feasible to assign licenses based on authorizations alone, you have to take a closer look at the SAP authorization concept. It would need to be ensured that a user can always be equipped with precisely those authorizations that entitle him to carry out the activities his job requires them to. No more and no less.
To assign authorizations, roles are created based on underlying transactions, objects, or access patterns (create, change, and display). The latter variant is actually irrelevant, since even an Employee Self-Service (ESS) user can create data within specific objects. The authorization to “Create” is a global permission in different cases. This means that the necessary differentiation of the special authorizations for creating an ESS user cannot be made. Using the example of provisioning an ESS user, global permissions aren’t specific enough to make a clear distinction here.
Further, basing license allocation on objects is also impossible, since executed functions cannot always be matched unequivocally with certain objects. Example: You can give an ESS user the option to book their times in an SAP system using a Z transaction. This way, the user does not use the actual ESS objects. These times are then pushed into the HCM, because direct access to the HR system is not desired for safety-relevant reasons.
This leaves us with the third option, transaction-based license allocation. Determining which transactions a user has accessed to by means of authorizations, and whether these transactions match with a certain license type is not defined anywhere. You would need a set of rules in place that defines if a user group X is entitled to a certain transaction, then this corresponds to license type Y. However, such a rule set does not exist. This makes it impossible for any company to decide which transaction correlates with which license.
As a result, one has to work with imprecise collections of permissions and has to accept overlap because in a given warehouse a licensed user could potentially update material either as a Logistic User, a Shop Floor User, a Professional or a defined Production Limited Professional user.
How do we approach the topic of licensing at VOQUZ?
SAP mentions in the description of the annual system measurement that user classifications need to be based on “current use”. To put some mustard on it, during unfriendly on-site audits SAP mainly focuses on current use as well and analyzes which transactions users have executed in the past three months.
Therefore, with samQ we automated the user classification based on actual user behavior, since behavior drives component use and executed transaction patterns. To assign licenses, we created a transparent set of rules that we provide to all of our samQ customers.
With the next samQ release 2.1 (available September 2017), we also provide a new add-on that can comparedeltas between licenses assigned based on real use and assigned based on static roles. In addition, samQ can also display all unused authorization objects and transactions, that a user currently has access to and could potentially execute. This allows each customer to easily improve their roles and authorization management processes.