TLDR

• When migrating from ECC to Rise with SAP, be aware of the differences associated with the license types.
• ECC - counting licenses based on what transactions (authorization objects) the user has used.
• RISE with SAP - license based on which transactions (authorization objects) the user can access (based on roles).
• The SAP STAR service involves mapping licenses in S/4 based on role analysis from ECC.
• So, if your ECC roles are non-optimal, mapping to RISE with SAP will incur an average increased cost of 50-150%.
• Some tools on the market will analyze and optimize licenses (USU SAM for SAP Software) and automatically optimize roles against job positions (Pathlock Role Management).

Introduction

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.

Part One - Theoretical

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:

• Support for SAP ECC ends in 2027 (the clock is ticking)
• Development will be halted after this time, and the eventual maintenance of non-migrated companies will increase.

Migration to S/4 = RISE with SAP?

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:

• The RISE with SAP model is nothing more than S/4 but in the Cloud (certified hosting providers)
• Subscription access to the system (forget the classic on-prem license + maintenance approach)
• Some of the services carried out so far by the internal BASIS team will be carried out by SAP.

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.

What did the world of user licensing look like at the ECC?

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:

• Professional user
• Ltd Professional User
• Developer User
• Project User
• Logistic user
• Worker User
• ESS.

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.

What does the world of licensing look like in RISE with SAP?

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:

• Developer Access (factor 0.5)
• Advance Use (factor 1) - (not quite the equivalent of Professional User, more on that in a moment)
• Core Use (factor 5) - (this is not quite the equivalent of Limited Professional User, as we will discuss in a moment)
• Self-service Use (factor 30).

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:

• 1 FUE = 5 Core Use
• 2 FUE = 1 Developer Access
• 1 FUE = 30 Self-service Use
• 4 FUE = (1 Developer Access) + (5 Core Use) + (30 Self-service Use).

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:

• Sales Billing
• Sales Contract Management
• Sales Lead Management
• etc.

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?

Beware of pitfalls when migrating licenses from ECC to RISE with SAP

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.

• ECC world - license type relevant to what the user did (actual activities)
• RISE world - license type pertinent to what the user can do (what they are authorized to do)

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.

How do we map SAP ECC licenses to the new RISE environment?

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:

• Named user licenses in ECC were billed based on actual activity
• In RISE with SAP, licenses are billed based on access opportunities (authorizations).

Summary of Part One

ECC's licensing world of named user types differs significantly from the new one in RISE with SAP. The main differences are:

• license types - in ECC, you buy a specific number of specific types; in Rise, you buy FUEs, which you distribute according to a key of license types,
• scope of license type definitions - differences in scope (for example, SD user - in ECC, it is the most expensive license type; in RISE, it is a level below the most expensive),
• accounting for licenses - in ECC, based on usage, in Rise, based on authorizations (roles).

Part Two - practical

Role efficiency in ECC is 10%.

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:

• People change their positions around the organizational structure, and it is easier to add missing authorizations than to verify that there is no excess
• The "I'd like to request such a role as a colleague" scenario results in a significant increase in authorizations and in the absence of automatic de-authorization procedures, authorizations swell
• Lack of verification of authorization conflicts, role content, and who the roles should be assigned to.

Step one - define what affects the license type.

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?

USU SAM for SAP Software

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.

Knowledge of the tool

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:

• Find all users who meet the technical user requirements
• Find users who have been inactive for at least 365, 180, or 90 days
• Find those who have never logged on
• Find those who fit the definitions of Developer, Engine, Self-service, Core, and Advanced in sequence.

Using this algorithm, we can optimize current licenses on SAP systems and simulate the migration of license types from one environment to another.

Step two - A painless role reorganization project

That is, we already know that:

• The new license model in Rise with SAP is based on the definition of who is entitled to what (i.e., the content of the roles assigned to the user)
• Current non-optimal roles in ECC will have a measurable impact on the overall cost of licenses (if we map the target licenses with the SAP STAR service).

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 Role Management

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).

Objective - to create job roles tailored to actual business needs

The process is as follows:

• Logical representation of the organizational structure
• Analysis of user activity
• Automatic proposal of master roles for jobs
• Acceptance workflow with SoD analysis
• Tests
• Documentation
• The life cycle of a role – change management.

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.

Project effects

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.

Savings

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.

Summary

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:

E-Book

SAP S/4HANA: Better license migration with USU’s Managed Services

Typical S/4HANA pitfalls and solution strategies for SAP License Managers.

Download now

Learn more about USU Software Asset Management and schedule a free consultation.