SAP Roles and Authorization

[Former Member]

Dear All,

We are planning to review or audit by our internal team (Technical and Functional) of existing roles and authorization.

I request you all to please share your experience how to follow this process.

Thanks and Regards,

Nirav

[Former Member]

In Audit they will ask for the users with access to

1.SAP_ALL & SAP_NEW

List of users having access to the following Tcodes:
1. MIRO
2. F-42
3. F-43

Process followed in giving authorisation (Approving Mail)

Process followed For transports

[Former Member]

Adding to Shahnas, PA30 t-code should not be assigned to any other function group except HR.

[Former Member]

What are you trying to achieve? You need to be really clear about that before you start, or you could waste a lot of time looking for the wrong things, and making unnecessary changes.

[Former Member]

Dear Steve,

Thanks for your reply.

We have implemented SAP in 2009. At that time Roles and Authorizations were design.

From 2009 to 2012 there are lots of changes in Authorizations, also changes in employees work profile and business process. 

For example one user has 5 roles assigned. There may be possibility that from 5, many roles has same T-code assigned. So if we want to remove authorization from that user then we have to check how many roles have this authorization. It may possible that one role is assign to other user also and that other user also affect if we remove authorizations.

Now Our SAP Team, Our Company’s senior employees also know much about SAP now.

So we want to recreate  roles in  a proper way so administrative activity will be made ease.

We are doing this activity first time by ourselves. So request you all to please share your experience.

with regards,

Nirav Bhatt

[Former Member]

So this is about ease of maintenance rather than because of any audit pressure or reduce segregation of duties issues? If it was the latter, the first thing I would suggest is to have an auditor on the team, and to get some external help rather than trying to do it on your own. I would also suggest looking at SAP's GRC software.

But since it is just for your own benefit, things are much easier. It is quite common to discover after a little while of live running that your initial role design wasn't as good as it could be. We were fortunate enough to have an auditor involved from the beginning and so things were quite good from the start.

There are two ways to approach this. You can either change the roles that you have, improving them incrementally until you get to something acceptable to you, or you can start again and redesign your role set from scratch to work the way you want, and then migrate users from old to new. Which you choose will depend on how far away your current role design is from your ideal.

Either way, though, you first need to know what you are aiming for. What would your ideal role design look like? Think about the problems you have now. Do you end up adding a transaction to a role for one user, only to find you've also given it to others who shouldn't have it? If so, you need to break up your roles into smaller pieces. Do you find that making a small change for a number of users means changing many roles? Maybe you need to consolidate some roles into a single larger one?

Ultimately wherever you end up is going to be a compromise - there's no single "right way" to do this. You just need to find the way that works best for you. That will almost certainly be different from the way that works best for me. It will depend on the structure of your team, the structure of your company, etc.

Hope that helps a little. While you are going to do the work yourselves, you might consider getting some external help to get you started. We've done all of our security work ourselves, but it has been valuable to occasionally get external advice to make sure we're still doing things in a sensible way.

Steve.

[Former Member]

So you are wanting to audit yourself? Actually that is a very healthy thing (self evaluation) but does require some discipline and honesty and normally also a fair dose of experience helps to be able to self reflect.

I often recommend peer-reviews to customers. That is much better than personal self-assessments and helps knowledge transfer and harmonizing (best practice) ways of doing things.

"Now Our SAP Team, Our Company’s senior employees also know much about SAP now."

Perfect...  🙂

What I do on my projects (we have tricks and a tool for this) is that we model the requirements via a "role wizard" which asks them lots of questions and shows them what the impact is on the roles and how many they will have as a result of decisions and compare it to existing roles... (for example, they decide to authorize on individual cost centers and groups of them linked to profit centers and do not want to use hierarchy nodes or want to promote BEGRU to an org.level.. etc... and click "Next"... -> kaduff... the tools tells them what this seemingly harmless decision will have as an impact and they can carve it out of the menu based job roles as a result or rethink whether it is a good idea...

The real trick for the long term investment is to work out a good plan and then get everyone to stick to it, without creating ZJULIUS and ZSTEVE roles with nonesense in them. So... save the various qualitative parameters, naming conventions, SOD checks, allowed functional tolerances, license classifications, etc as a "project" and integrate it into the STMS so that "cowboys" cannot transport their own inventions and in the development system you have a full role version management (with comparisons and restore capability - like in the ABAP workbench).

This works like a charm and you can also book SAP eduction training for it: search google for "SAP AND WCHXIT"  -> Use of expert methodologies and tools to make your life easier in sustainable compliant role lifecycle management...  🙂

It is offered in German and English, but only by SAP Switzerland and the SAP UK at the moment.

Not sure whether that helps you further, but that is how I do it and there is a fan club for it..  🙂

Cheers,

Julius

[shivraj_singh2]

Nirav,

I would support the point Steve made. Internal review of all Roles & Authorizations is a team effort, and Technical and Functional teams should make it very clear what are the objectives of this whole exercise. This review is not limited to adding/removing few tcodes or profile, it will also involve setting up the guidelines for future to keep your system & access clean & free of any risks and violations. So starting point is same as Steve mentioned - "What are you trying to achieve?"

Regards,

Shivraj