Request you to advise me that which configuration activities are transportable during GRC AC 10.0 Implementation

[Former Member]

Hello Experts,

I would like to request you to help me to understand the best practices on the below during GRC Access Control 10.0 Implementation.

1. BRF+ Custom rules created in DEV system, is it advisable to make new transport request in DEV and transport the same to
   Quality/Production system (OR) Import rules from DEV and upload them into Quality/Production system.

        Please advise me the best practice on the above?

   2.  I have activated required BC Sets in DEV system, is it advisable to make new transport request in DEV and transport the same to
        Quality/Production system (OR) Activate the required BC Sets in respective systems manually.

        Please advise me the best practice on the above?

   3. I would also request you to advise me that which configuration activities are transportable during GRC AC 10.0 Implementation.

Regards,

Venugopal

[Colleen · Accepted solution]

Hi Venugopal

I take the approach - if it is customising or development then you should transport it. This will ensure you have appropriate audit trail; your environments are in sync; assists in identifying Production issues (e.g. check if a transport was introduced)

The exception to this is if you have a configuration situation where the values must be different in each environment.

For BRFplus - I would transport them. For BC Sets - this decision will depend partly on how your Basis team build the system (e.g if they do install or build from client copy). At a minimum, migrate all of the configuration you did in Development through to Production.

My key recommendation: you should talk to your Solution Architects, Functional or Configuration colleagues who support your ERP component, etc and leverage their policies.

[Former Member · Accepted solution]

Hi Colleen,

Thank you so much for your inputs.

In my previous GRC 10.0 Implementation I had faced this issue, still am not clear on the best practice.

Some are advising as below:

1. Activate BC Sets in each individual systems Manually.

2. Generate MSMP Rule in each individual system and Export BRF+ Rule from DEV and Import into respective systems.

Few are advising to make a transport of each activity which we do in DEV system and transport them into respective system to maintain synch among all the systems.

I am confused now? Please advise...

Regards,

Venugopal

[Colleen · Accepted solution]

Hi Venugopal

Which people are you referring to when you say? "Few are advising to make a transport of each activity which we do in DEV system and transport them into respective system to maintain synch among all the systems."

I am a believer in transport when you can as much as possible for proper change control, testing and evidence of changes to the system. However, whatever you decide to do make sure you document it; obtain your change and release team's support; and be consistent!

You may bundle your changes into a single transport (where possible) for a release. If you do this, you need to consider what you do if you need to defer one change but all the others. Putting all developments in a single change may not help and can make it difficult if you need to defer scope.

In SCN you will receive many opinions on what to do or what someone does. Just remember you don't work on their system, know their landscape or change and risk culture. Weigh up your options and choose the best fit/most appropriate option for you solution.

[Former Member]

I would transport everything possible for consistency sake. Remember, this was one reason why GRC 10.0 was bought back to the ABAP platform and it is worth pointing out that GRC systems are audit-able, so changes do need to be tracked for compliance purposes (remember the acronym GRC)!

There are certain settings I would avoid transporting, which are the actual system connector related settings etc. This is why it is important to have connectors aligned to a "Logical Group" (which is the same name across all your various GRC landscapes) and your subsequent connector dependant settings (such as the rule set) aligned to the "Logical Group", so once it is transported to the next landscape, you should not have any issues.

I would be very cautious about "uploading/downloading" BRF+ rules. I have seen this mess up once as for some reasons the actual condition columns were not working in a QAS system as it did in the DEV system. I strongly advise that the MSMP workflow settings and custom BRF+ rules are transported properly across the landscapes.

All the best

[former_member193066]

Hello Venu,

Its all about your requireemnt and approach.

some scenarios you can download brf+ and uplaod . as good as transport.

for BC sets you can transport most of them. again depends upon you requirement best practise keep seperate requtest for all and transport each of them.

Regards,

Prasant

[jatin_grover]

Normally customers prefer to transport the objects from Dev->Quality->Production. This ensures that nothing is passed to production system which have any glitches and is a best practice.

[former_member220726]

Hi,

In our case we have done all configuration through transports only, all most all configurations are transportable, (Don’t activate BC set in system manually (I think system does not allow you to activate BC set when Client role is production in SCC4 ), but if you want to change the name of functions, risks (Ruleset) etc as per your client need, best way is download Ruleset and change the naming conventions then upload it, Also generate rules for only the new risks.

There are few bugs/Issues in the product and which can be addressed during implementation , SAP keep on releasing Notes as and when you notify any issue ; best way is go to the latest patch level (Not one patch level before latest), then start your implementation.

Uma Shankar T

SAP GRC Consultant

[Former Member]

If the problem is not totally dependant on moving to the "latest" support pack, I would still keep the "Latest Minus 1" strategy, as most small issues are fixable by implementing the actual individual SAP note (which is part of the latest support pack). If the fix has not worked, it is easier to retract the SAP note implemented.

What many customers are worried about is the regressive bugs that tend to occur when moving to the latest support pack, and once you have moved up the pack level, you can not retract back to the previous support pack easily (if at all).

[Former Member]

The scenario that Harinam described described is exactly what happened to us. Our sandbox was on SP11; it was so buggy, and we applied so much of SP12 to it, that we went to SP12 for our DEV system, and were very disappointed to discover some functionality that worked in SP11 was broken again in SP12. Some days it seems that each SP is two steps forward and three steps back. We are sorely disappointed in the quality of these SPs.

Gretchen

[Former Member]

Gretchen,

I am glad you are also advocating a similar experience as I have been through. This may sound bizarre, but to add more spanners to the works, it seems that different results are achieved with the Support Packs depending on what version of Netweaver you are using GRC. I know there are more problems on NW 7.31, therefore I wonder if there is some issues with the underlying code of the GRC tool itself.

Anyways, probably should start another discussion for this, but back ot the original point, best way forward is transports and ensuring all the SP's are on same level universally.