GRC10 AC Customer seperation

[Former Member]

Dear Experts,

I have 2 internal customers (same company but 2 different projects) who want's to share one GRC10 AC instance.

Is this a recommend procedure to put 2 different customers with different users, backendsystems and customizings on one single GRC10 Instance and seprate them in 2 different Clients? (e.g. CustomerA Client 100 and CustomerB Client 200). I like to understand the dependencies of the Customizing between both clients.

Is there someone of you who had a similar request in the past? My opinion is to seperate them in two different NetWeaver installations (SIDs) but I need a good reason for it.

thanks in advance.

Andreas

[Former Member · Accepted solution]

Hi Andreas,

This is a interesting one. Maybe it is worth thinking if GRC will be serving different purposes to Company X and Y respectively:

1) Will the 2 companies be reporting on 2 total different rule sets? GRC 10.0 can manage both

2) Will the 2 companies be utilising different roles and authorisations from each other? GRC 10.0 can also manage this from the single instance (given a good naming convention and clever use of role attributes)

3) Will the 2 companies require to utilise their own different approval process flows (if Access Request Management is to be used) ? With some time spent well, a Access Request workflow can be designed to ensure both companies approval processes are segregated.

I have worked on a few projects where a customer has been responsible for different "Brands"/"Projects", but they all share the same instance of ECC/BW/SRM etc. I have also seen big Oil and Gas companies have different ECC/BW instances for various streams in the single company. In such a scenario I have seen the single GRC system shared, but in complex Oil and Gas set-ups I have seen a dedicated GRC system for each stream (due to the share volume of users per stream and also different complex rule sets and approval workflows).

Have a think about how big the implementation would be should the single instance be shared and what common factors can be shared (i.e. rule set, target systems, approval workflow etc).

All the best

[Former Member · Accepted solution]

Hi Harinam

thank you for the valuable suggestions and sharing your experience. In fact these are thinks I have to discuss.

Let me still ask you:

1) When you say GRC10 can mange 2 total different roesets does it mean, that the roleset is client dependent?

2) As roles and authorisations are client dependent, does mean that GRC10 can manage them across different clients?

Thanks and regards, Andreas

[Former Member · Accepted solution]

GRC can manage many different rule sets now. What is worth testing is if the Management reports can handle more than 1 rule set to display within the reports (the pie and bar charts).

GRC 10 can manage different roles and authorisations across the different clients. I am not sure if you mean something else by your question.

You may want to share more concrete examples.