Many clients aim to mitigate most Segregation of Duties (SoD) risks by changing their current role model in the SAP system. However, it is crucial to understand the implications of this type of project and the key points that need to be addressed. In this article, written by David Torres, head of the SAP Business Line Department in Inprosec we will cover the most important aspects based on the different phases of a Role Design Project.
Preparation/Analisys
During this phase, the following elements must be defined: the Naming Convention, the Role Design Approach, and Role Mapping to Users.
- Naming Convention is a key aspect that helps everyone involved in the User Provisioning process understand what access is associated with each role. It is essential to involve all stakeholders in this task. A common misconception is that the Naming Convention is solely IT’s responsibility, which is a big mistake, as the User Provisioning process is not limited to the IT department.
- Extracting and delivering the organizational values currently in use is also crucial. The SAP system typically stores values such as company codes, plants, purchasing organizations, sales organizations, etc., which might be outdated. Allowing the project team to extract this data without a prior review by experts can lead to the creation of unnecessary roles.
- SAP users are likely to need customized transactions, but in many cases, these transactions have not been properly documented, making it difficult to incorporate them into roles. It is advisable to allocate time so that process experts assist the project team in defining these roles correctly. This activity should also be used to document any customized transactions that lack complete information.
- Job Position-Based Roles are always a complex topic when discussing Role Design Projects. Many clients wish to address this matter but are not always prepared to design these roles. The following requirements must be met to do so successfully:
- A clear definition of the job position must exist. It is also important that these positions have been reviewed and approved by the HR department.
- Each position should have, on average, more than one user. Creating job position-based roles for a single user does not follow best practices in role design.
Testing
It is essential to communicate to the testing team that this is a key activity in a Role Design Project. From a project perspective, it is recommended to optimize the definition of test scenarios.
There are two key profiles during the testing phase:
- Business Process Owners (BPOs): These individuals are responsible for ensuring that transactions function correctly. In most cases, SAP standard transactions are already documented, so this group should focus mainly on testing customized transactions.
- Champion Users: These users have extensive knowledge of SAP from the user perspective. They test job position-based roles and the role assignments defined in the previous phase.
Communication Management
Since a Role Design Project impacts the entire organization, it is recommended to define a Communication Management Plan. This plan should include the following activities:
- Workshop activities for Naming Convention.
- Workshop activities for Role Design Definition.
- Workshop activities for Organizational Values review.
- Workshop activities for Job Position Definition.
- Project Meeting for Test Scenarios Definition.
- Project Meeting for User Acceptance Test process
- Workshop activities for the definition of Global Communication for New Role Design Deployment.
- Workshop activities for the definition of Incident Management process.
These are the key points, but other activities may be included depending on the organizational culture.
Deployment
This is a critical phase, and it is important to understand that issues will arise in these types of projects. This is why the Incident Management Process was previously included as a key part of the Communication Plan.
As a best practice in incident management, it is essential to:
- Stay calm and allow the project team to work on resolving the issue.
- Classify incidents correctly:
-
- If the problem is not critical, and some users are affected but can still work, the project team will analyze the role model to identify the issue and apply the necessary solution.
- If it is a major issue, the Rollback Plan must be executed, temporarily restoring users’ previous access before the new role model implementation. The project team will then analyze the problem and restore access once the solution is ready.
If the testing phase was properly conducted, critical issues should not occur in these projects. The most common incidents include:
- Missing specific values within authorization objects→ Quick Fix.
- Missing access to transactions called through other transactions (e.g., FBL1N and FB02) → Quick Fix.
- Transactional usage data does not account for newly implemented transactions → Complex Fix.
From the client’s perspective, stakeholder commitment is crucial during this phase. In some cases, the person facing an SAP access issue may need to resolve it urgently, making it essential to have a prioritization system within the Incident Management Process. However, it is equally important to ensure that priorities are used correctly—not all incidents can be marked as critical, as this would make it difficult for the project team to prioritize problem resolution effectively.
Another important aspect during the implementation phase is how end users report incidents. In some cases, end users will attempt to solve issues following the Business as Usual (BaU) process. However, since the project is in implementation mode, the project team has designed a specific Incident Management Process for this phase.
Based on our experience, it is critical to reinforce communication efforts regarding the new role design deployment and the Incident Management Process, as this will determine the success or failure of the project.
In role design projects we have worked on, one of the biggest client concerns has been unresolved incidents due to poor communication with the project team. This happens because end users did not follow the Incident Management Process, and the Business as Usual (BaU) team, which handles daily access administration, lacked the knowledge to resolve these specific issues. This is completely understandable, as they were not involved in designing the new role model.
Thus, it is important to ensure that the Business as Usual team is aware of the project execution and that any authorization-related incidents are redirected to the project team for proper resolution.
5 Key points to take home
- Stakeholder commitment is a critical success factor for the project.
- Communication activities should not be underfunded, as they are essential for the success of the Role Design Project.
- The project team is not responsible for defining organizational values in SAP. Validating which values are correct and which are obsolete is the client’s responsibility.
- The role Naming Convention should not be solely IT’s responsibility. Since SAP roles will be requested by end users, the Naming Convention must be understandable to them.
- Incident management is key to resolving issues on time. Most delays occur due to non-compliance with the Incident Management Process.
Inprosec, experts in Role Design Proyects
If you are thinking of redesigning SAP roles in your company, at Inprosec we are specialists in role design projects, helping to optimize access to systems and ensure proper segregation of duties. Our team has the experience and knowledge necessary to accompany you in every phase of the project, from planning to deployment, ensuring that everything runs efficiently and securely.
Contact us here and let’s talk about how we can help you!