Role Methodology Access Restriction

[Former Member]

Hi,

We are implementing BRM for a client. And the client wants to divide the role methodology authorizations among 3 set of admins. Meaning the

• First set of admins can only Define Role, Maintain Authorizations and Derive Roles.
• Second set of users can do Risk Analysis and assign Mitigation controls, Attach Test Cases and Initiate Approval and the
• Third set of admins can do Role Generation.

How do we achieve this? Can we restrict the above set of users to see only those Tabs(see below screen) which suit their Job?

Regards,

Mohamed Fazil

[madhusap · Accepted solution]

Hi Fazil,

We also have similar requirement where the team which creates roles through BRM are not aware of Risk analysis process and they don't want to perform risk analysis task. Below are steps we are following.

Role Management Team:

• They receive a Service request for Creation of New Roles/Modification of existing roles from the Local Admin team with authorizations details.
• Once received they will create role through BRM, and completes the steps Define Role and Maintain Authorization Data
• Once they complete these steps will inform the GRC support team through Email to perform risk analysis for the roles which they created/modified.

GRC Support Team

• GRC Support team will run Risk Analysis and Impact analysis for the role and if there are any risks will share the details with the Local Admin team (one who initiates role changes) who in turn will mitigate the risk or suggest to cancel the changes.
• If mitigate the risk, then it goes for Mitigation Assignment Approver and once approved, Local admin team informs the GRC Support team
• GRC Support team verifies and then informs the Role Management team to proceed with next steps.

Role Management Team:

• After confirmation from GRC support team, Role management team initiates the approval and up on approval will generate the role.

Basically, we defined this for a client based on their requirement and they are following the same as part of their Post Go-Live Operations & Support (O&S) process. By this we are making clear that the concerned team is responsible for any discrepancies.

I am not sure whether you can restrict the steps in a methodology process based on authorizations or any other way. Let us check if the experts any advise for this even I am looking forward for that.

Regards,

Madhu.

[alessandr0 · Accepted solution]

Dear both,

did you check authorization object GRAC_ROLED? Never tested this, but you can restrict the activity as follows:

01	Create
02	Change
03	Display
06	Delete
08	Change History
38	Perform
61	Export
64	Generate
71	Analyze
90	Copy
91	Maintain Approvers
B3	Derive
FS	Search All Roles
V1	Compare
V2	Synchronize
V3	Maintain Authorization
V4	Maintain Test Results
V5	Assign Default Roles
V6	Certify
V7	Reaffirm

For example if the role management team should not be allowed to generate the roles do not give authorization for the same.

Does that answer the question?

Regards,

Alessandro

[Former Member · Accepted solution]

Thanks Alessandro It works.

[Former Member]

Hi Mohamed,

Administrators can take action , as per authorizations assigned to them. So, i think there is no substantial meaning of dividing role methodologies as per Admin.

Normally, methodology is divided as per type of roles(eg. single, composite) or System or Landscape, and not on Definition/Risk Analysis/Role generation because every role has to go through all the steps.i.e a role which is defined, will go through Risk Analysis and then generation.

Regards

Plaban

[Colleen]

Hi Plaban

Large SAP sites with regional and country specific teams would have a requirement to split the different methodology steps between different members. Also, some might have the role definition and testing sit with Functional whilst the Authorisations sit with security. Some have role derivation and org value updates sit with one team whilst the rest sit with another.

This all comes back to business process for role management design. Splitting between role types is more common.

Regards

Colleen