cancel
Showing results for 
Search instead for 
Did you mean: 

How practical is it to build new roles based on the Function tcodes?

Former Member
0 Kudos

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

Accepted Solutions (0)

Answers (2)

Answers (2)

Former Member
0 Kudos

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

Former Member
0 Kudos

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

Former Member
0 Kudos

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

Former Member
0 Kudos

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

Former Member
0 Kudos

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 ...