Role Redesin

[Former Member]

Hello Expert

From last few days I was serching for a standard (systematic) approach that can be followed for ROLE Redisign .

I cam accross few poiinters like Using master and derived role concept or may be Job based or task based role .

I am really intersted in knowing the best practice or commonly used practice for ROLE Redesign mostly where organization have large number(20000) of roles.

Any input is highly appreciated .

Thanks & Regards

AKM

[Former Member · Accepted solution]

Hi Ashish,

20,000 roles are too high. By the way, how many users you have??? Ideally if you have 20,000 roles built in the system, you should have about 1 Lac users.

The best way is always to maintain a Master/Derived concept. In lot of scenarios such as PO approval etc may request multiple roles, which you can reduce by building custom tables, and transaction codes. Below are some of the thumb roles:

1. A role should be designed for a group of users and not an individual.

2. A role should be defined based on a business process/task and not simply for a group of tcodes.

3. Roles should be grouped based on business process & Sub business process only.

4. Avoid using profiles and PDAGs (Pre Defined Activitiy groups which are delivered by SAP) to the maximum possible.

Here are some of the tips:

1. Identify the obsolete roles and delete them.

2. Identify the roles which are with minimum transaction codes and merge them into one by grouping on business process. Quickly you can generate a report using AGR_TCODES to find out the Roles Vs Tcode assignment.

3. Identify the roles with open org.fields using AGR_WITH_EMPTY_FIELDS report.

4. Identify the roles with open auth objects using AGR_WITH_EMPTY_FIELDS.

5. Re-design your entire role frame work and match to tasks & positions.

This way you can reduce the # of roles to as less as possible.

Hope this helps!!

Regards,

Raghu

[Former Member]

Thanks Raghu & David for your valuable input .

Let me tell you how i was thinking to take up this situation .

I wanted to start with role clean up by checks already proposed above .

Then as a next step list down all Business process and find out critical one from BP owner .

We can then start with those critical BP and identify the sub BP or JOB level like manager ,employee supervisior and can see if role already exist for them .

If role exist then can start mapping to JOb level .If role doesnt exisit then would prefer to modify it but creating new role will be last resort .

May be by this way i think we can aleast align aouthorization system to BP .Later we can USe RAR to remdaite or mitigate .

I am also reluctant to create any new role as it can create a mess .I feel role mapping to BP will be a challenging task bcoz of large number of role ?

Any idea how we can do this role mapping to BP efficiently .

Kindly do let me know if we can try some thing else also in above mentioned steps .

@ Raghu : There are close to 500 users in the system .

Best Regards

AKM

[Former Member]

Hi Ashish

I hate derived roles and, since you already have a fair few roles I would be reluctant to start build any more immediately but bear in mind that building from scratch does mean you have to UAT and provide full support if your SU24 settings are lax or your original roles were never tested in isolation if you start pick'n'mixing them. Guessing the 20000 roles are pretty small...

The trouble with tiny single roles, assigned across multiple user groups is that those 20000 roles will quickly become 40000 once you start copying/removing a single tcode and assigning to one or two users to avoid upset the rest of the people using the original.

Granularity and RAR don't make good bed fellows

Carry out the checks already proposed, run SUIM for unassigned roles (watch out for parent roles without org levels if you use them and expired roles/users), try SM20N edited - I can't find the original thread to credit the poster for this transaction but I think it was either Julius or Alex - edited if available to see if the used transactions can be easily identified, running that can remove a good chunk of access.

Try to avoid a new build if time and business buy-in is low - remediation should be a correction of access at role and user level and not a chop it to pieces and start again (IMO anyway)

If you get to a reasonable level of SoD's then combining into user group composites reduces admin and confusion and can help stop user group access drift since changes to compoiste have to be transported.

Lots of things to do and there's no one correct way - it's all up to you and your imagination to get the best result with budget and on time.

Cheers

David

Edited by: David Berry on Oct 18, 2010 7:38 PM