In this article, we will examine some of the benefits of having a role model defined based on SAP®’s best practices, as well as a composite role model, in our SAP® system.
Role Model based on Best Practices
We will review the main points to consider when defining our role model:
- Logical Definition of Role Model
- Role Naming Convention
- Organizational Value Matrix
- Organizational Structure
- Risk Matrix
- Transactional Use
It is essential to define the logic of our model should follow beforehand. When dealing with an ECC system, it is often advisable to use a model of Master Roles and Derived Roles, employing Enabler Roles where necessary. For instance, to impose a specific restriction on a non-organizational value field or a custom object enabling a particular functionality.
Keeping in mind the logic best suits us for our model, we will define the naming convention of roles. It is important to strive to use the 30 characters allowed by SAP® to their fullest, ensuring that each character adds value. This approach will be highly beneficial for conducting searches through tables or easily identifying the roles we wish to assign. For instance, whether they allow modification or viewing access, which functional areas the included accesses belong to, if it is a master or derived role, which business unit it applies to, a brief description of the role’s functionality using abbreviations…
In our naming convention, it is also important to leave characters for identifying the organizational value (the plant, company, etc.) restricted by our derived role. Moreover, understanding how different organizational values interrelate is crucial in order to maintain the roles properly. For example, deriving our role at the plant level does not mean it will only contain this organizational value. It is important to know which other values, such as sales or purchasing organization, are associated with each plant to prevent unauthorized access to other organizational units.
Having a clearly defined organizational structure at the department and user position level helps us define our composite roles, which we will discuss later.
Classifying transactions in roles requires keeping our Risk Matrix (or SAP®’s standard one if we don’t have a custom one) in mind and creating roles based on functionalities, such as “create suppliers.” This approach prevents internal segregation of duties risks in our roles and maximizes the reduction of risks in our system.
Accesses should be differentiated in our roles between Display or Change (which should be easily identifiable in our role naming convention). Certain transactions may have this dual functionality, depending on the activities we select in the objects checked by the transaction.
To facilitate the assignment of transactions, it is advisable that each transaction is in a maximum of two roles, as long as it can be restricted to Display or Change. It is important to verify that none of our viewing roles are providing modification access. However, we could add the viewing transactions in the modification roles of the same functionality. This way, if a user only needs to view materials, they are given the specific display role, but if they need to modify materials, giving them the modification role would include both Change and Display accesses without the need to assign two roles.
Once we have defined and created our role model, we will base it on transactional use to give each user only what they use. It is advisable to use as broad a transactional use as possible, covering month and year-end closures.
Benefits of Role Model based on Best Practices
- Creation of a flexible model that adapts to the different requirements the company has or may have.
- An intuitive model that speeds up the identification of the role or roles we need.
- Allows specific assignment to the organizational values required by users. Thus, they cannot view or modify data from other business units to which they do not belong.
- Facilitates the reduction of risks in the system. For instance, if the company decides to activate a new risk that was not being monitored, it is easy to identify which roles are giving that risk and to remove that access from users who do not require it.
- Reduces the number of Professional Licenses assigned. As access in the system is highly restricted, we avoid having to give a professional license to a user who does not require it due to being over-authorized.
- Simplifies access identification in user provisioning.
Composite Role Model
Once we have our roles with our transactions created, SAP® allows us to create Composite Roles. These are roles that contain other roles. That is, we would make groupings of our defined permissions, for example, at the job position level.
For the definition of composite roles, having a clear organizational structure is essential, and thus we can properly design our composite roles, avoiding adding roles that give access to transactions that do not correspond to the position.
Next, we show different low-level examples of how the different positions in each department could be segregated.
Clearly, all our users in SAP® should have their department and job position properly indicated.
The creation of composite roles is recommended but not essential; it would be like a second phase of improvement after having created our role model based on best practices. It should be highlighted that a composite role model cannot be created without first carrying out all the steps mentioned at the beginning of the article, as these composite roles will contain our previously designed and created roles.
Again, transactional use will be of great value for defining the accesses that will make up our composite roles. It will also be necessary to keep the risk matrix in mind, to reduce the risks of the composite role to the maximum.
It may be necessary to create several composite roles for each Department and Position based on the segregation of access at the organizational value level. For example, in the company, there are 5 sales managers, but each one manages for each of the 5 plants the company has. Therefore, all should have the same accesses, but each one restricted to a specific plant. This should be clearly indicated in the naming convention of the composite roles.
Benefits of Composite Role Model
- Reduction in the number of incidents at the access request level. The reported incident will be resolved for the entire department, not just for the user making the request.
- More efficient management of tickets.
- The accesses that users have are clearly identified, facilitating the onboarding of a new user in SAP®.
- Simplification of the “movers” process within the company, since it would be easily identifiable the accesses of the new position, and an end date of validity could be set for the position they will no longer belong to while making the transition.
- Immediate identification of the type of License required by composite role (Department and Position).
- Automation of the registration process through integration with IDM (Identity Management System). A relationship between the job position and the SAP® role would be created, and the IDM system would perform automatic provisioning.