BRM it is a very useful tool in GRC which help to create and maintain the roles of the company in a single repository. This module it is not only use to manage the changes in SAP Roles, will also help to:
- Maintain the Naming convention (NM) of your roles.
- Have logs of all changes done in your roles.
- Have all the documents (technical and functionals) of the changes requested in the same repository.
- Maintain the relationship between Master and Derived roles.
- Have a repository for the roles use in Access Control requests and select their respective approvers.
- Design a Workflow to approve the changes in roles.
There are two points which are very useful for the daily work with BRM:
- BRM complete part of the name of the new role following a NM. For example, if in the NM the second character of the role indicates if it is a display/task/job role, when you create a role and select the type of role, the second character of the name will update it automatically.
- BRM also allows to maintain different workflows pending on the type of the role: master role, derived, job,…
How BRM works?
The first screen you see in BRM, is the repository of all roles created and maintained. For each role you can see some attributes like application type, landscape, type, process, last update, etc. Of course, it is possible to create and update roles from BRM, but also there is an option to import it from the backend systems, with the possibility to do it in single mode or massive.
As it was explained before, to create/modify a role there is a workflow, which can be created with different standard stages. This stages usually have two tabs, one main tab which is different pending on the stage, and another which is the same in all stages. This second tab is called “Additional details”, which has the main information of the status of the role, the documents attached for the different approvals, the log of changes and more information.
The main stages you can see in BRM
Define role: the unique tab of this stage has the information of role like the detail of name and description, profile assigned, landscape, functional area, company…but one of the most important is the “Owners/approver” part. Here it is possible to select one or more approvers for the role, but there are two kind of approvers: Assignment approver (the approver in Access Control requests) and Role Content Approver (the user who will review the approval of the creation of the role and the possibility to generate it in the next environment). It is possible also to indicate delegate approvals. BRM allows to have default “Role content approvers” pending on the environment you want to update the role.
Request approval: this is a very simple stage, there are only two parts, one to ask for approval, and a table with all the approvals requested with the details of it. In the option to ask for approval, it is important to give a small description, because the approver can check the details of the change in the documents attached and in the log of changes.
Maintain authorizations: this stage connects BRM with the SAP system, using the option of “Maintain Authorizations Data”, which will open the role you want to update in the PFCG transaction of the development environment. Once the role is updated in the PFCG transaction, it is possible to synchronize the data in BRM repository, cancel this synchronization or if it a master role, propagate the change to the resto of derived roles.
In this stage, you can also have information such the actions assigned to the role, permissions, organization level, function, or data of the last change done.
Generate role: as the name of the stage indicates, here is the possibility to generate the changes saved in BRM into the environment you want, in case that the change is being in a master role, you can generate the master and all derived roles assigned to it.
You can select more than one environment, and it is recommended to generate always in the previous environment of the one you want to generate, because you will have the same in version of the role on all environments.
Analyze Access Risk: the main idea of this stage is to do a Risk Analysis of the role, in order to check if generates new SoD Risk, Critical actions or Critical Permission of your maintained Rule Sets. This is very important when you have a Role model based on Risks.
Derived Role: this stage usually is available in the Master role workflows, and it is very useful to create the derived roles. It is only needed a name, description, and organizational values to create the derived role.
BRM has available an option to have a mapping of organizational values, which can be helpful to populate the organizational values of a role automatically.
How the BRM workflow works?
For the workflow, you can use the stages you want, however the stages of “Define Role”, “Maintain Authorizations” and “Generate role” are mandatory.
Once the workflow is designed, the main and very important idea is that the workflow does not have a start and end points, it is a circular workflow. This is because in the workflow you ask for the approval to create/change a role in an environment, but usually the systems have more than one more environment, so you need to ask, at least one approval for each environment. So instead create a long unique workflow, there is a circular workflow with some stages.
In resume, BRM is a very useful tool to manage your roles in the system, to have all the documents and approvals of the changes in the same repository, and the logs of changes done by the team.