redesigning SAP roles

Question: John or other qualified SAP Security experts,

We are getting ready to do a total redesign on our SAP roles and I wanted to get some input from you or others as to the new role strategy.

The first option we have is one role per job that cross's functional area's and does exactly what the job does. SOD's with be considered at the time of building the role with the help of an aftermarket tool. The advantages I see in this is there is no opportunity for cross talk in authorizations and there is not excess access give to any particualr employee. The is also no opportunity for SOD's to be created when adding roles to a user to gain functionality.

The second option would be to build roles that are segragated by the type of access such as reporting roles, Update transaction roles, Display transaction roles. These roles would be assigened to the users as needed. There seems to be some advantages to doing it this way also, more flexibility but the potentail to cause SOD issues and cross talk by having multiple roles per user.

The last option which I least favor is building roles by sub process's and then assgiening then as needed to accomplish a job. This presents lots of crosstalk issues and can create lots of SOD's when the roles are lumped together.

What are your thoughts on this subject?

Thanks,

Mark

Answer:
Above all Keep it simple...

A role is "all the access needed for the person to do their Job", Corrolary -" a person may have more than one job". This requires you to add value by extending the request to make the role a fully operation one. Example, if the role is CREATE then the user should be able to Change the mess they made and view it.

SAP is integrated, you should expect the roles to be cross-funcitional" provided no SOD exists.

A user should have a minimum of two roles
1. Generic stuff - Printing, RFC, SU3, SU53, etc.
2. their job.


If you company addops a VIEW ALL ( non-private and critical data excluded) you would have three roles.

Answer:
I agree completely. Simple is better.

Answer:
Sometimes too simple is stupid.

If you wind up making a role for every user so that you could make it simple then you made it stupid.

Roles should describe logical jobs in a well managed enterprise. It may just be that yuo have a lot of employes in your not so well managed company that do more than one job.

So I will add another benchmark: You should not have more than 4 roles per module (counting AP, AR and GL separately). Undoubtedly you will exceed this once or twice but only if you have serious discussion and debate on the benefits of the increase.

Under this scenario, employees who do more than one job will have more than one role. My benchmark is that most employees have two roles but many employees have 3 to 5 roles.

Answer:
If you wind up making a role for every user is not simple an too time consuming.

You will need to re-engineer your processes and streamline and standardize them. Too many companies adopt the "It was not invented here, so it must not work" mentality and want SAP to work the way the use to rather than streamlining and adopting stndard practices.

Your company's control concerns will dictate the number of roles per module as dictated by risk and potential for occurance. Four per module, a good start but a generality. FI alone has AR, AP(non-payment run), Close coordinator, Post to closed period, Master data maintenance ( which could be more than one), Payment run, FI access to payer table if you have HR installed, etc.

Answer:
Plano SAP Man,

I deited your topic title. Please use a meaningful topic title or face a locked topic.

Thanks,

Snowy
_________________
SapFans Moderator
NetWeaver ‘04–SAP Web AS for ORACLE certified

Search: /forums/search.php
SAP Notes: http://service.sap.com/notes
SAP Help: http://help.sap.com
Basic Rules: /forums/viewtopic.php?t=222759

Answer:
Plano SAP man,

thanks for creating the "frustrated Snowy" topic.

I locked both topics.

stop being a texan Cowboy and get a life
_________________
SapFans Moderator
NetWeaver ‘04–SAP Web AS for ORACLE certified

Search: /forums/search.php
SAP Notes: http://service.sap.com/notes
SAP Help: http://help.sap.com
Basic Rules: /forums/viewtopic.php?t=222759
Copyright ?2007 - 2008 www.jt77.com