Guidance: GRC Workspace Page Variant Architecture & Multi-BU RAM Strategy

[desmond_teo]

Hi Community, 

As an alternative to the my other question of using custom workspaces as a solution;
We would like to seek inputs/advice on using page variants as an alternative option when adding a new BU to share the GRC workspace under the same instance.

Another team in my organisation has configured / setup the workspace before hand and tailored it to their BU's requirements.

[Current Context] 

• Workspaces/Roles:
  BU #1 has setup first in the instance and currently configured GRC: Risk Management Workspace across the three default roles/audiences (Business Op-Risk Manager, IT Risk Manager, Operational Risk Manager).
  
  

• Entity Hierarchy:
  BU #1 has defined and set the Root Entity Class with it mapped to a default RAM (RAM_A).
  
  Organizationally, the new BU (BU #2) which we are trying to add is the parent of BU #1 and oversees multiple child departments that may require future RAM variants in future.

• RAM:
  BU #1 has configure the RAM to their needs and set it to the root Entity class. 
  A new RAM will need to be added to BU #2, both BU's do not share the RAMs.

[Questions / Challenge]

Q1. Role & Page Variant Strategy

To onboard BU #2 onto the same instance / GRC workspace, should we be:

- Adding custom roles/audience under global scope for Page Variants to work in the GRC: Risk Management Workspace?

- How do we best structure variant ordering and audiences to prevent routing collisions?

The default roles/audiences for the risk workspace is "taken" by BU #1:

1. Business Op-Risk Managers

2. IT risk manager

3. Operational risk manager

Is the correct approach to add/create custom roles under global scope for BU #2
(So that the variants will work and both BUs can be segmented?)

Proposed new roles/audiences to be created: 

4. Business op-risk manager #2

5. Operational risk-manager #2

6. IT risk manager #2

Q2. Entity Class Hierarchy Restructuring

BU #1 has set the Root Entity Class with it configured to their RAM (RAM_A).

What is the best practice for re-parenting BU #1 under a new BU #2 Root Entity Class without invalidating active risk assessments or scoring configurations?

Q3. Multi-RAM Architecture

How should Entity Classes and Risk Assessment Methodologies (RAMs) be structured so BU #2 and its future sub-departments can run distinct RAMs independently alongside BU #1?

Thank you, in advance for your guidance!