When roles are designed and built well, they are easier to user and maintain.

How do you decide what goes in a role?

The first principle of role-building is: The role needs to give users the access that they need.

Consider the following scenario:

Frida: Can you create a role for me so that I can use SAP for my work?

IT: Sure. What is it that you do?

Frida: I am a Purchasing Clerk.

IT: Okay. What do you use SAP for?

Frida: I create purchase orders and update vendor master data. I also sometimes post invoices when my colleague is away.

IT: Okay, here is your role. It is called PURCHASING_CLERK and it lets you create purchase orders, update vendor master records and post vendor invoices.

This is a scenario we have seen many times in the course of our work: During the role design phase of an SAP implementation, existing users are interviewed to determine the access that they will need in SAP. Based on these interviews, new SAP roles are created and assigned to users accordingly. This helps users transition into SAP more smoothly, leading to less disruption to the business, because users have the access that they need.

The second principle: The role should be designed for a specific task/position

In the scenario above, role PURCHASING_CLERK has been built for Frida based on what she needed at the time of the interview. The role was then built to meet her requirements, not those which a Purchasing Clerk typically would require.

Consider this comparison:

When you build a role for the user, the access within the role is based on what the user needs at that point in time to perform their responsibilities, which is what we see with the role PURCHASING_CLERK. Despite this, the role name suggests that it contains only access typically required by this position.

Let’s say another user (we’ll call him Tony) joins the department as another Purchasing Clerk. By default, he is assigned the role PURCHASING_CLERK. Tony’s responsibility is to raise PRs and POs; however, this default role also gives him unneeded access to post vendor invoices. Over time, this access right will remain in the role and may not be picked up until an access risk assessment (for example, segregation of duties analysis) is performed.

One way to resolve this issue is to:

• Remove access to post vendor invoices from the role PURCHASING_CLERK
• Create another role INVOICE_CLERK which contains only access to post vendor invoices

Another solution would be to rename the original PURCHASING_CLERK role to ROLE_FOR_FRIDA. We have seen similar roles (i.e., built and named with reference to a specific user) many times at various clients. While we cannot recommend this solution, it is at least transparent to both business and IT communities.

Which roles should be built for a task and which for a position? This will be covered in our section below.

The third principle: The name of the role should accurately reflect its contents

In order for business to rely on roles as a means of communication with IT, they need to understand what each role does from its role name, without having to delve into technical details. Each role should have a role name which accurately reflects the access it contains and captures key information (e.g., organisation restrictions of the role).

When a role inadvertently allows a different level of access from what is expected, as per PURCHASING_CLERK above, misunderstandings can occur, leading to excessive access given to users.

Additionally, a role name should also indicate the level of additional restriction it carries, for example when it only allows access to a specific organisation unit. One role that we will discuss in an upcoming section is PO_CLERK_0006. This role allows access to raise POs for purchasing organisation 0006 only.

We need to note, however, that business users who seldom work with SAP may not be familiar with what purchasing organisation 0006 represents. They may know it by another name used in the course of the business instead (e.g., 0006 may represent Singapore). It is therefore important to be mindful of this and perhaps provide some sort of mapping tables for the business for such cases.

The fourth principle: The role should be resilient enough to withstand dynamic business changes

It is important to remember that while SAP configurations generally remain stable, business requirements are dynamic and can change more frequently. When a business requirement changes, existing roles need to be able to react to it without major amendments.

This means certain roles may carry additional access for some users. In real life, there may not be multiple users with the same job position who require exactly the same level of access. For example: Frida, Tony and Tina may all have the same position, which is Purchasing Clerk, however, Tina may not be responsible for raising purchase requisitions (PRs).

In this case, it may make sense to grant Tina the same role (i.e., PURCHASING_CLERK) and accept that this role assignment contains a known risk, which is the surplus access for her to raise PRs. Accepting known known risks helps streamline the administrative tasks involved in role building, maintenance and monitoring.

These could be the role assignments for the three Purchasing Clerks:

If possible, it is advisable to tag roles to logical steps/sub-processes. As an example, at a high-level, these could be the roles you might have in your Purchase-to-Pay process:

• VENDOR_MASTER_CLERK
• PURCHASING_CLERK
• WAREHOUSE_STAFF
• INVOICE_CLERK

Tagging roles to processes means that when there is a change in business requirements, for example a change in a process step:

1. The roles and users impacted can be easily identified.
2. The impact of the change can be better contained from an access perspective.

Role building in SAP

As we have seen above, users gain access to perform tasks in SAP through roles. Each user has a user master record, to which roles are assigned. The role itself carries authorisation objects. Therefore, the term access is often referred to as authorisation in SAP.

In order to perform a task in SAP, a defined set of authorisation objects is required. For each authorisation object, relevant authorisation field values are required. If any of these authorisation objects is missing or incorrect authorisation field values are assigned, the user will not be able to complete the task. Read our blog post on the SAP authorisation concept to learn about this.

A role is therefore made up of these authorisation objects, along with their authorisation field values. For example, to create purchase orders (POs), The following authorisation objects are required:

Essentially, there are two levels of access required to perform a task in SAP.

1. The first level: Authorisation object S_TCODE gives you access to execute a specific transaction code (t-code). Each t-code in SAP is correlated to a task. When a user executes a t-code, they are taken to the SAP screen on which the task details are entered. For example, executing t-code ME21N takes the user to the PO creation screen, on which details of the PO can be entered.
2. The second level: Each t-code has a set of corresponding authorisation objects. For t-code ME21N, as per the table above, the corresponding authorisation objects are M_BEST_BSA, M_BEST_EKG, M_BEST_EKO and M_BEST_WRK. Having the authorisation objects and their required field values allows the user to complete the task. For example: After entering PO details, the user will be able to save the PO.

In SAP, roles are built using a handy functionality called the Profile Generator (PFCG). The purpose of Profile Generator is to ensure that roles are built with all the authorisation objects required to perform a specific task. The relationship between t-code and authorisation object(s) can be maintained using t-code SU24. The use of PFCG reduces the administrative effort required in building the role and fixing broken access.

The above two levels of access mentioned above are also reflected in the role-building process.

1. The first step of the process is to select the task(s) to for the role, which adds them to the user menu. See below for more information about user menu.
2. Based on the selected tasks’ t-codes, PFCG suggests corresponding authorisation objects to add to the role. In the second step of the role-building process, selected authorisation objects are added to the role.

Through these steps, all the required authorisation objects are added to the role. The collection of these authorisation objects are referred to as a profile. The role therefore acts as a container for the profile. A profile can technically be assigned directly to a user master record. However, a user compare programme, which is usually scheduled to run on a nightly basis, will identify direct profile assignments* and remove them.

When a user logs into SAP through the SAP GUI (Graphical User Interface), they will see a menu. There are two types of menu that can be displayed:

• The SAP standard menu lists all available tasks in their SAP system. Despite having all the tasks displayed, the user will only be able to start tasks which they have t-code authorisation to.
• The user menu, on the other hand, will only show tasks that the user has t-code authorisation to.

For more information about how users log into SAP, please read our blog on the basics of SAP access. To find out about the steps involved in building PFCG roles, click here.

*Only applies to generated profiles.

Variations in role building

Composite role

Two or more roles can be combined together to form a composite role. A composite role can be made up of both single and/or composite roles. Any single or composite role can be assigned directly to a user master record. However, as mentioned above, authorisation objects cannot be directly assigned to a user.

Composite roles can be appealing because they can make your role structure appear organised and streamlined. However, having too many layers in your role architecture (for example, when you have a composite role containing one/more composite roles) can lead to a reduced visibility about what the roles contain. Ultimately, it is important to determine the level of visibility you need in order to aid communication effectively between IT and business.

Master-derived role

When SAP is used across various organisation units requiring the same roles, the master-derived role concept can be used. This saves the administrator from having to create similar roles from scratch, reducing administrative efforts and risks of inaccurate authorisations. Master and derived roles are sometimes also referred to as parent and child roles.

Typically, this approach is used when the same roles can be used by different organisation units simply by modifying the organisational authorisation objects. What happens in practice is as follows:

• A master role is created containing all required authorisation objects and their corresponding authorisation field values, except for the organisational authorisation object field: This is given a dummy value (‘’) or given access to all organisation units (*). Organisational authorisation object fields are those which specify which organisation unit(s) access is granted to.
• A new role is then created by deriving it from the master role (deriving roles is a standard functionality in PFCG). The relevant organisation unit is specified for the organisational authorisation object, therefore creating a complete set of authorisation objects. The resulting role is what is called a derived role.

Let’s say that the role for purchase order (PO) creation is used in various purchasing organisations within the same company. The table below shows the differences in field values between a master role and its derived roles, where:

• PO_CLERK_MASTER: Master role which enables the creation of PO
• PO_CLERK_0006: PO creation role for purchasing organisation 0006
• PO_CLERK_0008: PO creation role for purchasing organisation 0008

The master-derived role concept is extremely effective when a global process template is used. This usually happens in large, often multinational organisations, which have decided to use the same processes, therefore the same roles, across the organisation.

One thing to remember: When a master role is changed, the derived roles need to be regenerated too. Any changes to the master role will not automatically be copied over to the derived roles (however, it is only a one-step manual action to mass generate all derived roles).

A real scenario: Roles should be built in Development and transported to Production after proper testing. When a master role is changed:

• The related derived roles should be regenerated in Development too.
• Testing should be performed on both master and derived roles.
• All the roles, master and derived, should be transported into Production.

Master roles should not be assigned to users, although technically it is possible to. Therefore, when master/derived roles are used, additional monitoring may need to be performed to ensure that the master roles are not assigned to any users (especially when access to all organisation units, or * value, is defined). When SAP GRC is used, master roles can be made unavailable for access requests.

Common role design architecture

SAP role design is more than just its technical elements. While the technical architecture may be meticulously designed and organised, it will not achieve its desired benefits unless the users, most of whom sit in the business, are able to understand and gain value from it in their daily application. This goes back to our point above about roles being a bridge between business and IT.

This requires synergies between the way SAP is used to how the organisation operates. What it means when it comes to authorisation is the following:

• SAP role structure should replicate the way the organisation is structured. This enables an almost one-to-one mapping between organisational job role and the SAP role, allowing the business and IT to have a more consistent understanding about both business authorisation requirements and how they can be fulfilled in basic technical SAP terms.

If you use SAP HR, roles can be assigned to HR positions instead of users. Users will receive role assignments based on their HR position. However, this will only be effective when the HR organisation structure is mature and stable enough.

• Business processes should be accurately reflected in SAP. This could mean that adjustments would need to be made in the business, or vice versa, in order to streamline their processes and get closer to one of the standard SAP ways of working. This means that the authorisation elements of the process, i.e., at points where human input is required, are equally supported by the inbuilt standard SAP functionality. The process of standardising business processes usually takes place before/during SAP implementation, as part of a wider business transformation project.

Synergy between SAP authorisation concept and business requirements can be achieved through the following role architecture:

• Build single roles for tasks. For example, single roles can be built for the following:
  • CREATE_PR: Gives access to create and maintain purchase requisitions.
  • CREATE_PO: Gives access to create and maintain purchase orders.
• Build composite roles for positions. For example, the position PURCHASING_CLERK can be made of single roles CREATE_PR and CREATE_PO.

The diagram below shows how synergy can be achieved between SAP and the business:

The portion in the diagram within the grey box represents a single role, which is built in order to enable a task to be completed. One or more single roles are then combined into a composite role, which is also referred to as the job roles above. End users can then recognise what the job role allows them to do and would be able to recognise which job role they need to perform their tasks.

The following conditions are required in order to achieve the above diagram:

• All tasks performed in the organisation are clearly defined and well-designed. This is done by the business and defined outside the system.
• Next, SAP roles are named based on the business-defined tasks above. This allows any tasks belonging to access risks to be easily identified.

As a result of the above two conditions, the content of each SAP role should be in agreement with the role name. For example, if a role is called DISPLAY_PO, then the underlying SAP authorisations should allow access to purchase orders only (no other data) and only display access (no create/ maintain) should be granted.

Other role assignments

On top of a job role (i.e., a role required to do their responsibilities per their job position), the user will also be assigned with other roles:

1. All users will be assigned a role containing basic authorisations granted to all users, e.g., employee self-service, etc.
2. Each user may be assigned a display-only role for the specific area that they work in. For example, the Purchasing Clerk may receive a display-only role which allows access to view all purchasing documents (e.g., purchase orders, purchase requisitions, RFQs) in their specific organisation unit.

Access risks within roles

Access risks, comprising of segregation of duties (SoD) and critical access risks, can exist at user-level and role-level. When a role has an access risk violation, the users assigned with this role will also inherit the same access risk violation. It is therefore ideal to have roles which are free of access risk violations.

Additionally, even when all the roles are free from such violations, there may still be violations at user-level. The combination of multiple roles to one user may open up expected and unexpected authorisations. Essentially, an authorisation object under one role can, in combination with an authorisation object from a different role, give these additional authorisations. Please refer to the section called Cross-pollination of our blog post on the SAP authorisation concept.

Access risk violations are most easily identified using a tool (SAP GRC and MARC are examples of such tools) – this would automate the analysis process, reducing the amount of time and effort required. When a tool is not used, a preliminary manual check can be performed by inspecting the role names. As long as the roles have been built following the listed principles approach and carry clear and accurate naming, this preliminary check could provide a beneficial starting point.