This article aims to exemplify all the necessary information that helps decide on the size of license costs in the RISE with SAP model. In it, I point out that:
Current non-optimal roles in ECC will have a measurable impact on license values in RISE with SAP.
I have divided the article into the following two segments:
Part One – Theoretical – I describe the differences between ECC and S/4 environments in the RISE with SAP model. In it, I draw attention to the possible pitfalls of these differences and show an example of such differences that can impact license valuation.
Part Two—Practical—This part demonstrates the working methodology associated with license simulation and role optimization, still in the ECC environment, to save on FUE license costs to the limit.
To begin with, a handful of basic information, admittedly reproduced here and there - but for this article, it is worth confirming a few of them:
Following Gartner's report (October 2023), we can also state that the new environments offered by SAP will be overwhelmingly on the RISE with SAP model. What does this mean for existing customers who are still to migrate? There are several vital elements to look out for:
While still comparing the classic on-premises version of S/4 to the RISE with SAP model, one must remember to mention the change in the licensing of named users. The classic approach, in which we had a pool of users for whom licenses were purchased, is replaced by tokenization. SAP introduces the concept of Full Use Equivalent and flattens the types of permits. We'll talk more extensively about FUE in a moment.
Again, a kind of summary—we are back to the basics of licensing principles. Until now, customers could read which types of licences corresponded to the usage of which business functions in their contracts with SAP.
These records were complicated insofar as they verbally described the activities that the user was supposed to perform (I especially emphasize patience, the reason for this will become apparent in a moment). The activities carried out by the Professional User consisted of several bullet points, where one would look in vain for a reference of these functions to the execution of specific transactions. On the one hand, this is a complicated process. Still, on the other hand, if it were linked to transactions, an easy workaround for the licenses (thus optimizing costs) for creative clients would be to rewrite the functions on Z*, but let's leave that topic.
We have a set of licenses, and a description of what functions can be performed by the user performing the function.
So again, to remind you - licenses for ECCs include the following:
If you have bought 200 Professionals and are only using 170, then the remaining 30 can be shelved or distributed to unlicensed users. In addition, be careful if you don't assign a user the proper license (or don't do it at all) because when you audit the licenses, you may find that there is a significant cost involved.
In addition, consider the definitions of license types. Let's assume we have an example: in an ECC system, a Professional User is assigned a license because he performs sales processes in the SD module. By contract definition - any operational activity in the ECC for sales requires a Professional User license.
Let's remember the example above (for Professional and SD). We'll come back to it in a moment. Let's record the basic information about the new requirements. In the new systems, we distinguish between the following license types:
SAP is introducing the concept of FUE, or Full Use Equivalent. This is the first major difference between ECC and RISE. Up until now, you used to buy a specific number of users. Today, you buy tokens (a number of FUEs), so to speak, which you use to grant specific types of licences (according to a multiplier, which I have described with the number "factor").
This works according to a simple calculation, for example:
In theory, FUE allows customers to navigate the number of license types efficiently and flexibly without buying a specific number of each type. The difference in license types is not all. There are still differences in the definitions of the license types themselves. So, we return to the example of the SAP ECC and Professional User that performed sales activities.
If you perform a simple license transfer for this user in isolation from the S/4 definition, you might overpay for licenses. Why? Because licenses in S/4 (both in the S/4 on-prem and RISE models) define sales activities for license types lower than Professional. And so for Core Use:
What does this mean? Nothing less than the need to carefully translate license types about actual activities. There are still some differences, so how do you migrate licenses?
In addition to the difference in the scopes of definitions discussed above, another important aspect is the defacto key to understanding what the customer should do BEFORE the migration conversation with SAP. Let's look at the FUE definition:
"Full Usage Equivalent (FUE) means the number corresponding to the number of individuals authorized to access specified solution capabilities."
I have made bold the keyword for clarity. What does it mean in the context of migration? A total change of existing licensing habits.
I will stray from the topic to remind you of the averaged results of the authorization audits we have completed. Their results were usually that users use 10% of the authorisations assigned. The remaining 90% (on average, irrespective of industry and client geo-location) are redundant authorizations that should not be assigned to users. And yet they are. What might this mean in terms of migration? Costs—considerable ones.
We already know that 1:1 migration of existing user types is not possible, and this needs to be approached with an appropriate working methodology. The SAP STAR service, which supports ECC customers in migrating to S/4, can help. One of its outcomes is the ability to map licences from ECC to S/4 based on appropriate adaptation of specific users' contextual differences.
The word 'mapping' is important here, as we are not talking about optimisation but only about reflecting the before-and-after state. This is all based on the users' roles in the ECC.
And here we come to the point:
ECC's licensing world of named user types differs significantly from the new one in RISE with SAP. The main differences are:
As I mentioned, in organizations that have yet to address the role optimization project effectively, we observe a tendency to exaggerate the content of roles assigned to users greatly. On average, only 10% of the authorizations assigned are actually used by users.
Why is this happening? There are many factors. Let us describe a few of them:
As I mentioned - the SAP contract contains descriptive definitions of license types. These describe what activities users can perform (or can be authorized to do). This verbal description does not include specific definitions of transactions or authorization objects. So, how do we map these definitions?
The first tool from the SAM market leader focuses on the specifics of SAP licenses. It allows for full-fledged license optimization in SAP, whether discussing ECC or S/4 (on-prem or Cloud). This post focuses on the RISE with SAP model, which looks at authorizations assigned to specific users.
The USU SAM for SAP Software tool has libraries of definitions for specific license types about the transactions and authorization objects assigned to a particular license. Of course, if you have custom transactions (there is no SAP without Z*), we add those parameters of T-codes or authorization objects that are appropriate for the license type to the definitions.
The construction of the specific license definition for the Core Use example (1/5 FUE) is as follows:
On line 2 above, the definition of the transactions to which a particular user has access appears. A detailed list opens with content describing the required accesses:
Additional information on license levels also includes data on authorization objects.
After updating with custom transactions and authorization objects, we simulate changes in license types for the migration scenario.
The software works by filtering the user to meet the requirements of a particular license type. The (high-level) algorithm is as follows:
Using this algorithm, we can optimize current licenses on SAP systems and simulate the migration of license types from one environment to another.
That is, we already know that:
So, it is important to sort out the roles before we start talking to SAP about the intended values of the FUEs we want to buy.
Role reorganization projects are often associated with never-ending discussions by the business about the legitimacy of given role accesses. There can always be a transaction that we want to use for something. What if I'm doing my work at a crucial time? Isn't it better to give more comprehensive access today?
Every authorization project requires an appropriate identification of the job necessary activities, such as a list of business processes that can be mapped with transactions and authorization objects. What if such a process list is absent in the organization or needs to be updated?
The best practices sewn into the tools come to the rescue, allowing the necessary roles to be built efficiently and tailor-made. This allows job roles to actually meet specific business needs without generating excessive accesses.
Pathlock is the market leader in dedicated solutions for SAP authorization management and security (and not only SAP, but for this article, we focus on the SAP area).
The tool automates everything possible in the tedious, if manually executed, process of creating business-matched roles. In a nutshell, the tool controls the entire authorisation concept (maintenance of documentation, acceptance workflow, naming convention, positions, and responsibilities).
The process is as follows:
Stage 1 - Organizational structure
Here, we create a mapping of each element of the organisational structure logically from departmental and divisional to job level. Considering the org level, any differences in access are also at the level of authorization objects.
Step 2 - Analysis of user activity
We treat the positions from the previous step as a kind of box. We put the current users into these. Pathlock Role Management analyses ST03 (and information from SU24, among others).
Step 3 - Automatic proposal of master roles for a position
After analysis, the system proposes the content of the leading roles for the positions, with the distinction of details resulting from the different parameters of the authorization objects. Depending on which organizational level the employee works in or what they are responsible for. The role proposal is based on historical data from stage 2.
Stage 4 - Acceptance workflow with SoD analysis
Those responsible for the business area accept the content of the roles. The information for acceptance may also include SoD analysis.
Stage 5 - Tests
The critical point at which users test new entitlements. The stage is transparent to end-users due to the application of the following algorithm: The user acts, and the system checks if the action is possible from the new roles, and if yes, it performs it. If not, was it available in the old roles? If no - do not execute it. If yes - he can perform it, and the project team will immediately get information about the differences between old and new roles and can make an informed decision.
Stage 6 – Go Live and documentation
Once the new roles have been ultimately ported to production, the user can quickly revert to the old rights (under emergency access) for a set period. Complete documentation is created.
Stage 7 - the role life cycle
When the content of roles (in terms of codes and authorization objects) changes, the authorization team quickly changes the master roles. It propagates the changes according to the organizational structure key. Changing roles for additional organizational units takes minutes.
Let's summarise the project—we have roles tailored to our needs, still in the ECC environment. We are ready to simulate roles using USU tools, as they come with libraries containing levels of licence types broken down against the transactions and authorisation objects held in the roles.
From the projects the USU team is undertaking, if roles are not optimised prior to mapping using the SAP STAR service, the increase in the value of FUE licences can be between 50% and 150%. Significant amounts of money can be avoided, as I described above.
Migrating from ECC to RISE with SAP is a process that must also take into account the mapping of license types for the target users. There are a fair number of changes to definitions and billing (if only from the perspective that in the Rise model, it is not what the user has done that is billed, but what they can do, i.e., what they are authorized to do through the roles they have).
Addressing two themes - role optimization and simulation of license levels - will significantly reduce the expected cost of RISE with SAP's target license subscriptions.
The author is Head of Security Development at LUKARDI, an exclusive SAM partner for USU in Poland.
Resources:
Learn more about USU Software Asset Management and schedule a free consultation.