An alternative to the traditional task-role concept

In our blog post about the principles of role building, we talk about the SAP way of role-building, which is to use the Profile Generator (PFCG) and its automatic functionality.

Essentially, for each transaction code (t-code) assigned during role-building, PFCG will propose a set of authorisation objects (and required field values) for this t-code. These authorisation object field values are those which will be checked during the running of the t-code. Using PFCG, therefore, can help ensure that all relevant authorisation object field values are defined for the role, therefore minimising the risk of authority check errors during transaction execution.

This standard approach works in the majority of SAP implementations. It is often also referred to as the task-role approach (or the PFCG role approach).

An alternative role concept, called the enabler role concept, does not follow the standard SAP role building approach, but came about due to the belief that it would allow for simpler and more flexible user access management.

The fundamental difference between the two concepts boils down to the following:

In the task role concept, complete authorisations are defined in a role. Therefore, when this role is assigned to a user, the user receives sufficient authorisation to complete a task in SAP.
In the enabler role concept, functional authorisations and organisational authorisations are separated and assigned to different roles. Therefore, for a user to complete a task in SAP, at least two roles will be required: One functional role and one organisational role. We will explain more about functional and organisational authorisation objects in the next section.

To understand more about the SAP authorisation concept, please check out our blog post here.

Functional and organisational authorisation objects

In order to gain access to complete a task in SAP, a defined combination of authorisation objects is required.

As an example, the table below shows the authorisation objects required for creating a purchase order (t-code ME21N). Two of them are functional and three are organisational: These three are authorisation objects in which access can be restricted to specific organisation units only.

All of these authorisation objects, functional and organisational, are required in order to create a PO:

If only the functional authorisation objects are assigned, the user will be able to start the initial screen for t-code ME21N, but not create and save the PO.
Conversely, if the user is only assigned the organisational authorisation objects, they will not be able to even start t-code ME21N.

Following the enabler role concept, two roles will need to be created to contain these authorisations. They will look similar to the following:

Let’s explore another task in SAP: Posting vendor invoices. These are the roles which will need to be built if we follow the enabler role concept. They are for t-code MIRO, which is used to post invoices from MM, and its corresponding authorisation objects.

These are the authorisation object descriptions:

M_RECH_AKZ = Invoices: Accept Invoice Verification Differences Manually. This object allows the user to accept/reject differences identified during invoice matching. An invoice can only be posted after identified differences are accepted.
M_RECH_WRK = Invoices: Plant. This object allows the user access to invoices in defined plant(s) only.

Having only the functional role assigned will only allow the user access to execute t-code MIRO, without being able to post the invoice. Conversely, having only the organisational role assigned will not allow the user to even start the t-code for vendor invoice creation at all.

Therefore, we see that the functional role behaves as a gateway which allows the relevant t-code to be started. Without access to start this t-code, the user will not even be able to enter the details for the transaction.

The enabler role concept relies on the functional role acting as a gateway. If we have a secure gateway, any user can be assigned all organisational authorisation objects, because this assignment in itself will not give the user authorisation to start any t-code. Assignments of the relevant organisational authorisation role allows the user to complete this transaction – hence why it is referred to as the enabler role.

Consider the following:

In the enabler role concept, we can essentially combine all organisational roles together to form a common organisation role across the system. All users with access to carry out a business task can be assigned this common organisational role. On the other hand, all functional roles stay discrete and should be assigned in a more selective manner.

Have a look at these two users:

We can see that despite needing access to perform different tasks, both Tiara and Anand can be assigned one common organisational role. When this is magnified to the whole organisation, the efforts required on role-building and maintenance are dramatically reduced.

Organisational restrictions

When there is more than one organisational unit, for example in multi-company corporations using the same SAP instance, there will be more than one common organisational role in the system.

Consider the authorisation objects required for creating POs (i.e., per PO_CLERK role above). These authorisation objects have to be assigned the appropriate field values. Let’s assume there are three organisational units setup within one SAP system. These are the values required to create POs for these units:

(Click table to enlarge)

Purchasing Clerks in these organisations will be given the same common functional role, but different organisational role according to where they work.

These are the authorisation objects in each of their roles:

Therefore:

Users who belong to the same organisation have a common organisational role but may have different functional roles.
Users who are allowed access to the same transaction have the same functional role but may have different organisational roles.

Task role vs. enabler role concept

As you can see, the enabler role concept requires the administrator to go against the way SAP is setup in two ways:

When a role is built, PFCG will propose all relevant authorisation objects for the t-code in the role. This includes all relevant organisational authorisation objects. The enabler role concept requires that the organisational authorisation objects proposed be disregarded and removed from the role. This creates a role which only contains the functional authorisation objects only. This could lead to an incomplete authority check, as standard SAP programmes are built to check whether all required authorisation objects are present at the time of running a transaction.
Secondly, the enabler roles then have to be manually created to contain authorisation objects for specific organisation units. This, again, goes against the standard SAP way of working. PFCG is most effective when a t-code is first assigned to the role (and authorisation objects after) – instead, in the organisational role, no t-code is assigned.

Furthermore, any supplementary tools outside the ERP application usually assume that the standard SAP role architecture (i.e. task role concept) is followed. This is relevant, in particular when using authorisation-support tools such as SAP GRC. While you would still be able to perform a risk analysis on user-level, role-level risk analysis would present a problem as no single role gives full-authorisation in itself (therefore suggesting that no risk violations occurs at role-level).

Below is a comparison table between task role and enabler role concepts.

(Click table to enlarge)

In conclusion, the main draw for using the enabler role concept is the reduced number of roles when common functional authorisations are required across a large number of organisational units. Having fewer roles naturally suggests there would be smaller administrative efforts.

However, these benefits should be considered along with the costs of implementing the enabler role concept: Namely, increased documentation requirements and more manual role-building procedure.

Additionally, the main concern with the enabler role concept is the risk of unintentional excessive authorisations granted to users. The concept does not differentiate between display and maintain authorisations (learn more about ACTVT field in our blog post on the SAP authorisation concept). Instead, all users are given access to maintain for the relevant organisation unit(s) – this is based on the assumption that if a user has access to a transaction code, it must mean that they require access to maintain the corresponding task.

In reality, there will be users who only need display access to some tasks: For example, an Invoice Clerk is responsible for posting invoices. However, often they would have to verify the amount to be paid by inspecting the corresponding PO and goods receipt. An Invoice Clerk therefore only needs display access to POs and goods receipts, but this may not be possible when an enabler role concept is used.

To resolve this, additional monitoring may be required on users with excessive maintain access. The monitoring would likely need to be done in a more manual way and may involve a review of the users’ activities in SAP.

This is not to say that the enabler role concept has no place in SAP implementations – we have seen instances where it might be more suitable. One of our clients, for example, had numerous company codes within one SAP system. In each company code, there were multiple employees with the same job role but different organisational authorisation requirements – a legacy that proved complicated to simplify due to their data privacy requirements.

In such situations, an enabler role concept might be more suitable for the following reasons:

Firstly, if the task role concept is followed, the client might need to create a unique role per user. Therefore, the efficiency gain that would usually come from assigning the same role to multiple users would not apply.
Secondly, the resulting number of roles built on a task role concept would require too much time and effort to create, maintain and monitor.

However, whenever the enabler role concept is used, it is a must to maintain a clear and detailed documentation. This could be a live document in which any change to roles should be documented. More rigorous access risk assessment process also has to be put in place. Find out more to learn more about access risks and segregation of duties in SAP.