on 10-25-2010 9:36 AM
Hi
Julius wrote in another thread about implementing RAR for 2500 users:
"9 times out of 10 you will be better off building new single menu roles from cratch, in which case the ability to analyse a role for SOD's is more usefull than a user based entry."
Just wondering if anybody had tried creating single roles based on the contents of each function in RAR?
Function MM06 would contain material master data tcodes, maybe using the permissions that it contains to build from the ground up? I vaguely remember a demo of doing this in ERM.
At a previous client we ended up copying and copying and copying lots of singles to remediate which was a complete mess
e.g.
MM06 MM01
MM06 MM02
MM06 MM06
MM06 MM11
MM06 MM12
MM06 MM13
MM06 MM16
MM06 MM17
MM06 MM41
MM06 MM42
MM06 MM46
MM06 MM50
MM06 MM71
MM06 MMAM
MM06 MMDE
MM06 MMF1
MM06 MMNR
MM06 MMR1
MM06 MR21
MM06 MSC1N
MM06 MSC2N
MM06 S_ALR_87003972
MM06 S_ALR_87004117
Cheers
David
Edited by: David Berry on Oct 25, 2010 9:38 AM
David,
I wouldn't recommend this approach. Your roles should be built with the guidance from Business and Functional teams. You can run the roles against RAR to make sure there are not intra-role SoD violations.
Alpesh
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Alpesh
I'm flying this question to see if this is practical, at a granular level multiple single roles can be created when sub dividing the originals. I just wondered if building these new single roles in accordance with the RAR permissions ruleset and stating 'you gets all or nothing mate' approach might work?
Not saying this is the answer, rather throw the function back at the business to consider?
Cheers
David
Edited by: David Berry on Oct 26, 2010 10:23 PM
David,
On theoretical terms this approach seems idealistic. But, on practical terms this does not work on grounds of various reasons like Authorization setup, time, cost, efforts, nature of business & complexities, culture of the organization etc.
Also, SAP prepared this Ruleset based on many assumptions. In real time organizations vary in geographical spread, industry, operational view, financial view etc. The big challenge would be, what is sensitive and considered to be a violation by SAP may not be critical and violation by a specific organization. That organization would have different controls to deal with.
Also, in a global scenario, criticality & violation varies based on regions as well. Because, different regions may differ on regulatory frameworks, org structure, operational view etc. This may work but lot of conviction and loads of work.
Another big question would be, will it accommodate the future business growth, requirements, regulatory frameworks etc?
Thanks
Qalid
Hi Qalid
Thanks for your input, I can see there are some downsides to this approach!
If you start with lots of small single roles assigned to groups of users you end end, after remediation, with a vast number of copied/copied/copied singles have been created with the various conflicting tcodes separated as you hit different reports for different users who started with the same single role
I don't like new builds for remediation - you end up with an ongoing support burden, but, if you did have to 'go for it' then it would either be a case of building large user group job roles (no composites Julius - dog's breakfast ) to avoid cross user group auths errors or maybe build based on functions. If the business has already modified the ruleset to their needs then using the remaining values for the new build was why I asked. It's not ideal - agreed but it may give some benefits?
I'm working at a client where SU24 was never maintained so the values in the ruleset may provide some basic default objects and values to save subsequent teesting/auths issues.
Cheers
David
in my four yr interaction with GRC customer (when i was in SAP ...... ) , never saw single customer do that......
not a bad idea, however you may end up in mess.......
regards,
Surpreet
.... my 2 cents ...
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.