Solved: Role Design Startegy

Former Member · ‎11-02-2011

Hi All,

Any insights are greatly appreciated

I am strong believer that SAP Security role design startegy should be simple and easy to manage with single roles rather than having composites. At current cleint, I tried to sell this idea and tried to avoid composite role design because of problems I have seen after go-live (SODs, maintainence issues, problem analysis effort)

For some inexplicable reasons, I did not succeed completely now we are building roles with 3 tiers, 1 tier being common access role- single, second being display -single and 3 tier is composite role for each job function , having a combination of different task-based process roles . This is n+1 implementation with global roll out followed by individual markets. There will another tier of roles developed on need basis during blueprint of different market roll-outs

Can anyone give me inputs if this kind of composite approach combined with 3-tier have been used and what will be potential nightmares after go-live

Thanks in Advance

Former Member · ‎11-03-2011

I would suggest that it will depend quite a bit upon the business requirements, but a lot more on how many staff there are; potentially on how many roles would end up being created.

However, when I set-up our roles, I used only single roles (no composite) and that has worked well (150+ users at the moment, more to be added later, possibly up to 450) There is an arguement for saying that we could easily switch to composite roles now, but we still get quite a bit of role movement and keeping them as single roles has proven to be better. Perhaps in a few years if it settles down we may then look at it again.

Our roles are based upon job function, but in some cases, we have a "clerk", "supervisor", & "manager" role. The user in the supervisor function would have both "clerk" and "supervisor" role, but not manager. We also have some generic roles e.g. "purchase requisition" which are used by a larger number of people. This allows the specific items to be managed in one role rather than in say 8 or 10 roles.

Each role can then have different t-codes or authorisations; as they are cumulative, that gives the required access to do the job. It's also fairly easy to test that the role is working as we want it to do.

It took a while to get it right, but now it seems to be working really well for us. Moving people between job functions is really straight forward and easy to do. It's also very easy to add new users and will prove to be very easy as the new staff get added over the next few years.

I would suggest that the old axiom is true; the more work you do at the beginning, the less you will have to do afterwards.

Regards

Tony

Former Member · ‎11-03-2011

I would suggest that it will depend quite a bit upon the business requirements, but a lot more on how many staff there are; potentially on how many roles would end up being created.

However, when I set-up our roles, I used only single roles (no composite) and that has worked well (150+ users at the moment, more to be added later, possibly up to 450) There is an arguement for saying that we could easily switch to composite roles now, but we still get quite a bit of role movement and keeping them as single roles has proven to be better. Perhaps in a few years if it settles down we may then look at it again.

Our roles are based upon job function, but in some cases, we have a "clerk", "supervisor", & "manager" role. The user in the supervisor function would have both "clerk" and "supervisor" role, but not manager. We also have some generic roles e.g. "purchase requisition" which are used by a larger number of people. This allows the specific items to be managed in one role rather than in say 8 or 10 roles.

Each role can then have different t-codes or authorisations; as they are cumulative, that gives the required access to do the job. It's also fairly easy to test that the role is working as we want it to do.

It took a while to get it right, but now it seems to be working really well for us. Moving people between job functions is really straight forward and easy to do. It's also very easy to add new users and will prove to be very easy as the new staff get added over the next few years.

I would suggest that the old axiom is true; the more work you do at the beginning, the less you will have to do afterwards.

Regards

Tony

Former Member · ‎11-03-2011

Can anyone give me inputs if this kind of composite approach combined with 3-tier have been used and what will be potential nightmares after go-live

SOD separation is difficult with composites. you may end up with many related composites such as "AP Clerk 1", "AP Clerk 2"... "AP Clerk N". with each unable to exist on its own, because it contains just an enabler piece that was stripped away to avoid having a SOD embedded in a role. Or composites that contain task-based functions (not tied to a job role) so a user could end up being assigned several composites.

The best compromise I've seen is use composites, but permit single role assignments as well. For example... maybe 80% of AP Clerks would get the "AP Clerk" composite and all is fine. But the other 20% would get this composite plus several single roles because they provide specialized functions, or tasks that cause a SOD (that can be mitigated). An extra advantage to this approach is seen during Access Reviews. For the 80% assigned the composite, the review could be a simple validation that the person is still in the same job function, a fast and simple review. The Access Review would then focus on the "exceptional" access provided by the single role assignments. It really can streamline these notorious reviews. Maybe that could work for you.

Former Member · ‎11-08-2011

I hope that it will work out. I pushing for 3 tier design with single roles Thanks for your inputs