Exercitation ullamco laboris nis aliquip sed conseqrure dolorn repreh deris ptate velit ecepteur duis.
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:
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:
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:
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.
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:
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:
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:
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.