How ECC user authorizations affect the cost of S/4 HANA licenses in the RISE with SAP model

Introduction

First, a handful of basic information about why the topic in the title of this post should interest every company currently using the SAP ECC system, which so far hasn't migrated to S/4:

• Gartner reports that by 2026 (the clock is ticking), 90% of new installations offered by SAP will be in the Rise with SAP model (hereafter referred to as "RWS").
• The Rise with SAP model is a cloud service that, while it’s nothing more than "regular S/4" (just in the cloud), changes the way you settle with SAP.
• In the RWS model, both the types of named user licenses and (most importantly) the licensing methods are changing.
• If the roles in ECC are not optimal, you can expect an increase in licensing costs by 50-150% due to the RWS feature (according to USU research).
• There are tools that can significantly optimize both licensing costs (USU Optimization for SAP) and manage the project of optimizing role positions as painlessly as possible (Pathlock Role Management).

FUE Full Use Equivalent

The shift from ECC to RWS includes, among other things, the introduction of the concept of FUE.
This is a new way of accounting for named user licenses, with the flexibility to choose a license according to the key below:

• Developer Access (1 user = 2 FUE),
• Advance Use (1 user = 1 FUE).
• Core Use (1 user = 1/5 FUE).
• Self-service Use (1 user = 1/30 FUE).

 

And for a quick example, a bit more simple math.

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

I’d like to point out that Advanced Use is not quite the same as a Professional User known from ECC., a Core Use adequately is not the same as Limited Professional User with ECC.

Why?

It's important to consider the changes regarding the definitions of what each type of user means. If until now, the ECC user had a Professional User license because they're handling sales processes in the SD module, that doesn't necessarily mean they need an Advanced license in RWS. If you were to just transfer the license for that user without considering the S/4 definition, you could end up overpaying for licenses.

Why?

Because licenses in S/4 (both in the S/4 on-prem model and Rise) define sales activities for license types lower than Professional..

For Core Use:

• Sales Billing,
• Sales Contract Management,
• Sales Lead Management.

That means that if you move the user (like in the example above) – you'll end up overpaying a lot.
It's worth taking a look at the contextual changes regarding what specific licenses a user will need based on the activities they engage in (or to be more precise – what access they have).

Trap – a change from „usage based” to „authorization based”.

Now, here's the crucial part – until now, each user license in ECC was billed based on the transactions the user utilized.

In RWS, the change is huge; let's look at the definition:

"Full Usage Equivalent (FUE) means the number that corresponds to the number of individuals authorized to access specified solution capabilities."

I highlighted the most important parts – In RWS, it doesn't matter whether the user has performed any action. What's important is whether they have access to it.

Yes, the authorizations are the key to settling accounts for licenses. What does it mean? If the authorizations (roles) are too large, then obviously we are overpaying for the licenses.

SAP STAR Service

SAP offers to map licences from ECC to RWS using the SAP STAR service.
Let's look at a simple operating algorithm:

This reads as follows - we take the authorisations of a particular user from ECC and map this to RWS. With this service we get a list of target licences (and finally the number of FUEs to purchase).

Authorisation experience

In our experience, the average company not addressing authorisation projects to date faces the problem of too much authorisation. The value of transactions in use is around 10%.
The rest are unnecessary accesses that may generate authorisation conflicts or just an increase in the (unnecessary) cost of the target SAP licences.

What is worth emphasising again - if you have sub-optimal authorisations in ECC today, this will most likely lead to an increase in the cost of the Rise with SAP offering. So it is important to get your accesses in order BEFORE you start the target analysis of the licensing BOM from SAP.

Sub-project - Automation of the Authorization Reorganisation Project

A considerable nightmare for any organisation operating with SAP is reorganisation projects.
They are most often connoted by the long time it takes to run a project (rather, hundreds of days of consultants + resources on the company side). In addition, they need to provide up-to-date information about the processes and transactions used in the companies - we have to appoint people from the company who have to stop dealing with current tasks for a while. And then there is the sensitive period - testing new roles (this is the moment that can, if there were errors in the previous steps, result in users not being able to perform their business processes).

That is why it is worth helping with solutions that optimise the design to its limits.
In our experience - by up to 80% of the time compared to manual reorganisation projects for authorisation.

We implement reorganisation projects using the Pathlock Role Management Tool.
The tool is used to optimise and automate each step of the creation of a new year. In a word, we are in control of the authorisation concept (maintenance of documentation, acceptance workflow, naming convention, positions and responsibilities).

What is the Purpose?

New job roles that are tailored to users' actual business needs, based on historical data.

High-level process:

• logical mapping of the organisational structure,
• analysis of user activity,
• automatic proposal of master roles for jobs,
• acceptance workflow with SoD analysis,
• tests,
• documentation,
• role life cycle - changes

The project cycle looks like this:

And a sample format with high-level job roles looks like this:

Sub-project - Licence Optimisation

With USU Optimization for SAP and dedicated rulests (in the tool) we get to control the allocation of the corresponding licences in SAP (it does not matter whether ECC or S/4).

The USU Optimisation for SAP tool comes with libraries of definitions for specific licence types in relation to the transactions and authorisation objects assigned to a specific licence. Of course, if you have custom transactions (there is no SAP without Z*), we add to the definitions those parameters of Tcodes or authorisation objects that are appropriate for the licence type.

For example, what a particular Licence definition for Core Use example (1/5 FUE):

In the second line - the definition of the transactions that a specific user has access to. A detailed list opens with content describing the required accesses:

We also have a simulation layer:

Savings - Before the Migration Bid

This approach saves licence costs at Rise with SAP from 50% to as much as 150%. Because we optimise licences before migration (even before bidding), and we know perfectly well what licences we will need.

What to do next, how to live?

There are several possibilities. We invite you to:

• downloading our e-book [PL], which will describe the above in greater detail,
• participation in dedicated webinars,
• contacting via form and directly with our experts.