You are here

A New Specter Looms: User Licensing Based on SAP authorizations.

There has hardly been a moment of calm at SAP in recent years, what with the heated discussions around Indirect Access and SAP NetWeaver Third Party Applications, and now a new specter has emerged: user licensing based on SAP authorizations.

SAP’s current, predominant licensing method allows customers to map named user licenses to actual usage. The new method will map to what users are authorized to do.  In most cases there will be a significant discrepancy between the two methods, and not usually to the customer’s benefit.

It’s only natural that organizations strive to assign the cheapest SAP licenses to keep costs as low as possible. The SAP Basis Administrator usually determines which transactions and functions the user is performing and assigns an appropriate license type. The SAP System Administrator assigns an authorization role to users to ensure security of the system, while allowing them access to the functions granted by the license type. For practical reasons, authorization roles are not tailored specifically to each individual but to a group of individuals performing a similar function. The upshot being that users tend to be authorized to use more functions than they actually do.

SAP licensing is complex and often ambiguous. Since 2008, the Price and Conditions List from SAP contains similar wording against each license type: “…is a Named User authorized to perform the following roles supported by the licensed software…” Up until now, this would have been understood as a user being authorized to perform certain functions because the corresponding license had been acquired. However, SAP has introduced another interpretation and as such, the scope of functions that a user could use will determine the license type and cost.

SAP customers could now be faced with the difficult task of redesigning their licensing models to ensure no extra costs are incurred, while ensuring their business-critical systems are kept up and running. To add to the pressure, this must be done before their next LAW submission.

This becomes particularly important for companies who have negotiated contracts with SAP for a large number of low-cost users with closely defined licenses. The example below shows a typical user, with a named user Enterprise Self Service (ESS) license allowing access to all transactions necessary to his role. The authorization role assigned to him allows for access to additional transactions, which he does not use. In the new scenario, a more expensive, Worker/ Logistics license type would be charged for.

One of Snow Software’s customers, a US food manufacturer with 2,000 users on three SAP systems, recently experienced the implications of this change. They initially focused on their 110 Limited Professional Users and found:

  • A high number of roles per user
  • The ratio between permitted and used TCODEs was very high
  • The number of TCODEs per role was too high. On average, they were authorized for 145 but were only using 25.

This organization used Snow Optimizer for SAP Software to review its licenses and by adjusting the authorization roles for its Limited Professional users realized a license savings potential of between $400k to $500k for just for these 110 users.  (Perpetual license costs for software would otherwise have been in the region of $110k + 21% maintenance cost p.a.)

Until a court ruling clarifies whether SAP can legally enforce licensing by authorizations, it would be a risk for SAP customers not to adhere to SAP’s interpretation of the wording in the Price and Conditions List. When the new USMM (SAP’s user measurement tool) comes out slated for release around the end of the year, it will monitor the authorizations that organizations have assigned to their users and charge accordingly.

So, in practical terms what can you do? The first step is to get prepared - optimize your SAP systems today and know more about your licensing situation than SAP does so that when the new USMM is launched you don’t get any nasty surprises and a hefty audit fee.

SAP® Glossary




Authorization   An Authorization defines which data can be accessed by a user
Authorization Concept   Roles and Authorizations allow the users to access SAP Standard as well as custom Transactions in a secure way. SAP provides certain set of generic Standard roles for different modules and different scenarios. There are basically two type of roles: 1. Master Roles- with Transactions, Authorization Objects and with all organizational level management. 2. Derived Roles- with organizational level management and Transactions and Authorization Object copied from Master Role. An authorization concept describes the structure and functions associated with authorization assignment and checking in SAP systems There are four Role components: • Transaction Codes • Profile • Authorization Objects • Organizational Leve
Authorization object   An Authorization Object is an element of the authorization concept. Authorization Objects enable the definition of complex authorizations by grouping up to 10 authorization fields in an AND relationship to check whether a user is allowed to perform a certain action. To pass an authorization test for an object, the user must Satisfy the authorization check for each field in the object.
Authorization Profile   An Authorization Profile is an element of the
authorization concept. Authorization Profiles give users access to the SAP
system. They contain authorizations, which are identified using the name of an authorization
object and the name of an authorization. If a profile is specified in user
master data, the user is assigned all of the authorizations defined in this
profile.
Organizational Level     This defines actually the organizational elements in SAP, e.g.: Company Code, Plant, Planning Plant, Purchase Organization, Sales Organization, Work Centers, etc.
Transaction     A transaction is the call of a program via a transaction code.
Transaction code (TCODE)     A transaction code is a sequence of characters that identifies a transaction in the SAP system. A transaction code can contain up to 20 characters and should always begin with a letter. Permitted characters are letters from A to Z, numbers from 0 to 9, and the underscore.