sap grc workflow, and system migration

[Former Member]

1. is there any way to deactivate temporarily the approval workflow and the load/push done without any approval activity taking place ? What it may be the effort to do that ? is it worthy to do that ? (remember in our case OIM (Oracle Identify Management) tool pushing the request using MY ACCESS.

2. What is the best approach/strategy to move all development that we will be doing in GRC-CUP and/or GRC-RAR into the next GRC Environment (Testing) ? I need to have a table indicating the different options benefits and disadvantages for each option, including the risk that we can have for each option. (I know we have only once option which is export and import file but if you know the strategy that will be great).

3. I need to propose an approach to synchronize the changes that my client may introduce for GRC-RAR in terms of Risk Ruleset and Mitigations in Production GRC (Production) (They are doing the changes directly in production and then they moved into their our development GRC landscape). Given that our development environment for GRC (Development) is not in the same synch cycle, we need to have a process in places with detailed steps to synchronize Ruleset and Mitigations without overwriting any work that we will do.

[Former Member]

Great, thanks much.

[simon_persin4]

Hi Junaid,

Which version are you on? for version 10.0, now that we are on an ABAP platform, the same big rules apply to GRC as would apply to a standard SAP environment. You should have a proper strategy and process around the management of change.

If you have a strategy in place for the ERP systems, then this might be a good place to start. However, you need to consider a number of different things with regards to GRC specific configuration.

In my mind you have two real options for managing rulesets; either use transports wherever possible, or rely on the production change workflows and make the changes directly. Any hybrid process runs the risk of causing major confusion in both your support teams and your auditors.

Each option comes with its benefits and pitfalls. I suppose it also depends on your clients attitude to the data itself. If they consider it production relevant master data, then they maybe happy with managing it in the production system then that might be the simplist option. However, you do run the risk of failing the standard controls on code management which auditors will look to for relying on the production integrity.

If you transport the changes, then you will effectively render any workflow controls on changes to this aster data redundant unless you trigger those workflows from a pre-production environment (which again might not be reliable from a change management perspective).

For previous versions, you effectively have to rely on manual controls around import export or manual re-configuration. This places reliance on the testing and post implementation validation processes.

Simon

[Former Member]

thanks Simon very much for the reply, we are using here 5.3 version. infect i need know the risk if we are doing changes from PRD to DEV or Testing. you think do we have to change manually or follow the migraion path.

1. Production fellows not informing us while they re doing changes . (so what is the best to sysn all change data from prd ro dev)

2. v. Strategy for Synchronizations from PRD and DEV

3. Strategy for moving the configuration from Dev to Test and Prd

thanks much again for the help