3/Nov/2016 - Blog updated for re-tagging. Content migrated from SCN
This document has been written to explain how you can customise the ROLE METHODOLOGY steps depending on role criteria. The configuration requires the use of a BRF+ rule that using CND_GRP (condition group) as the rule result.
Please note, that this is not the same as Condition Group Mappings for Default Approvers (specified via NWBC screens). If you are interesting in the condition group mappings for default approvers then click here: BRM Default Approvers via Condition Groups
What’s it all about?
Business Role Management makes use of the role maintenance process steps known as the Role Methodology. You have two options with configuring Role Methodology:
- Default only – every role will have the same set of methodology steps. You can alter the default in IMG, however the steps apply to all roles. The default is also the methodology steps that is loaded when you first choose to create a new role.
- Custom BRF+ - configure use of condition groups and map different role methodologies depending on the role criteria. This provides great flexibility to have different steps depending on role information; require approval for some and not others; and a different sequence of steps.
Why isn’t the default enough?
This all comes back to your BRM design (funny that). If you have business rules that determine different scenarios for roles then you will want a set of steps to match them. For example, you might decide the Process Owner (i.e. Role Content Owner) does not need to approve Derived Roles so you don’t need an approval step. You might have decided Business Roles don’t need Test Documentation (random example here). You might even decide you’d rather a different sequence of steps depending on the role (i.e. Approve role before making a change).
Put simply, default methodology is inflexible and may not match your business process for role management. Configuring multiple methodologies allows you to match process to steps in the system.
Just a few lessons learned before we hit the configuration
From configuring this functionality and also responding to questions in SCN, there a few lessons learned I thought I’d share relating to this topic.
Why do some roles miss some role methodology steps?
Okay, I’m going to contradict myself to what I said above. The default methodology is meant to apply the same steps to all roles regardless of role criteria. However, the GRC component has an additional mapping table in the back-end that determines which methodology steps apply to the specific role. For example, a business role is a non-technical role and therefore, would never require a step to “Maintain Authorisations”. As a result, if you were to add “Maintain Authorisations” as a step for a Role Methodology that applies to business roles, it still will not appear in your NWBC screens.
When is the role methodology going to take place?
When you build a role for the first time, the calculation of the role methodology does not occur until after you press save on the DEFINE ROLE stage. Only the attributes related to the definition phase can be used as the criteria for the role methodology. Initially, the default methodology will appear. On save of the Define Role stage a “recalculation” of the methodology will occur.
The Role Methodology is not determined until:
- Create New Role > After the Role Definition is saved (default methodology will load)
- Maintain Role > On open the methodology will load (possibly you may need to Reapply Methodology if the configuration has changed)
- Reapply Methodology – it will check if layout needs to change and adjust accordingly
My approach has been to include 1 step for the default methodology – Define only. This removes all other steps from the user. When they press save, the role is then evaluated and the process steps are calculated and added to the NWBC screen to continue role maintenance. My thought was this makes it clear to the user that the steps will be defined once they specify the role attributes.
What does this mean in the NWBC?
The Default Role Methodology (box selected in Define Methodology Processes and Steps in IMG) will load when a new role is created, regardless of role type (as per screen shot below).
On completing and saving of the Define Role > Details information, the BRFplus rule is executed and the methodology is updated. The GRACROLE table stores the methodology for the role and the step is it up to.
If changes are made to the role methodology, the administrator can choose to “Re-Apply”. The Role Definition in GRACROLE table is re-evaluation and if it does not match the methodology, the methodology will reset.
Summary of Steps to configure Methodology
This section does not capture the Business Role Manage configuration steps for other aspects of BRM (such as role type, project, etc). This is a high level overview of the step intended to show you how the configurations comes together. It is not meant to act as step by step instructions.
- Activate BC Set GRAC_ROLE_MGMT_METHODOLOGY
- BRFplus Function for METHODOLOGY
- Assign Condition Groups to BRFplus Functions
- Define Methodology Processes and Steps
- Associate Methodology Process to Condition Group
[1] Activate BC Set GRAC_ROLE_MGMT_METHODOLOGY
Activating this BC Set will provide the baseline configuration date for role types, steps, etc is populated. Regardless of your design, it is best to activate this BC Set and then make the necessary configuration changes.
[2] BRFplus Function for METHODOLOGY
The IMG provides a step to automate creation of the BRF+ rule by creating the application, function and decision table structure.
Transaction: GRAC_GEN_ERM_BRFRULE
Program: GRAC_GENERATE_ERM_BRFRULE
IMG Navigation: Governance, Risk and Compliance > Access Control > Role Management > Generate BRFPlus Applications, Approvers, and Methodology Functions
One the program has created the BRF+ function and decision table, you can then maintain the decision table. In this, you will need the CND_GRP as your output. Create a rule for each different role scenario you need to handle.
The Column Name for GRAC_CNGP is the return result. These values must match the Condition Group Id in Associate Process Methodology to Condition Group.
[3] Assign Condition Groups to BRFplus Functions
IMG Navigation: Governance, Risk and Compliance > Access Control > Role Management > Assign Condition Groups to BRFPlus Functions
Within the IMG you need to tell GRC which BRF+ function to execute when Methodology is evaluated. Again, Condition Group is used but it is not the same as the CND_GRP that you mapped out in the previous step. You only need to create one entry for METHODOLOGY and map it to the Application/Function that you created. Unlike the MSMP, you do not enter the Application or Function Ids (alphanumeric number).
If this step is not completed, then BRM will only use default methodology.
From a background table point of view, the GRACCNDGPTYPE contains technical information used to build/evaluate the Methodology rule.
[4] Define Methodology Processes and Steps
In this step you build each methodology scenario. For each scenario, you then define the necessary steps including the sequence. The Define step information will come as part of the BC Set. There should be no need to update this configuration unless you need to add the elusive Provisioning Step.
[5] Associate Process Methodology to Condition Group
IMG Navigation: Governance, Risk and Compliance > Access Control > Role Management > Associate Methodology Process to Condition Group
In this step of the configuration, you need to map the BRFPlus Results for Condition Group (CND_GRP) to the Methodologies that you just configured. You are able to map multiple condition group outputs to the same methodology step.
Useful Tables
| Table | Description/Comments |
| GRACCNDGPTYPE | GRC ERM Condition Group Type |
| GRACCNDGPTYPET | GRC ERM Condition Group Type Text |
| GRACCNDGPTPBRF | Condition group type to BRF+ function assignment |
| GRACCNDGPMTH | Condition Group to Method |
| GRACMTH | Method |
Happy role building with Access Controls
Regards
Colleen
P.S I would love to hear your thoughts on designing the role methodology configuration and lessons learned.
- SAP Managed Tags:
6 Comments
