Authorizations in SAP connected to Roles in ARIS

Hi Harry,

sorry, reading your article only now.

This is how you should model on EPC level. For each step, assign (or have automatically assigned) the FAD.

On the FAD, next to the related SAP transaction(s), you can also model the roles (object type: Person Type).

In regards to Read/Write/Delete: Use the role definition to show that information. For instance, you define a role for 'Maintain(er)', and a role for 'Display(er)'. The Maintain role you should assign to the Create and Change X-steps, and the Display Role you should assign to the Display Step. This is how you define simple security roles. They are usually a collection of (between 1-5) SAP Transactions of a particular process.

For example, Role 'Display Source List' has access to transactions ME03, ME0M and ME43. Role 'Maintain Source List' has access to transactions ME01, ME04, ME05.

I would also recommned the Matrix Model.

You can talk to your local SAG ARIS Consultant/Account Executive & ask if they have a report for you which connects SAP transactions (screens) direclty to Roles (Person Types) via the Function object in the midlle.

Hope that helps, best regards,

Frank

Hi Harry,

long time no see. :-)

What you are looking at is a lot more complex that you might be aware.

1) SAP has pre-defined authorisation concepts and they will prefer using these over your input from process models. They also work in hierarchies for roles.

2) Your process modell will not cover the entire processes related to the SAP system and hence you don't have the full picture modelled in ARIS as a foundation for the authorisation concept. Very often not documented are the master data processes that are using a lot of transactions. The reference model only shows some of these transaction codes. Anything around the SAP Basis work is usually not documented in the processes either.

3) The authorisation conditions in SAP incl. the authorisation profiles usually contain:

- transaction code (BTW: there are different transaction codes that allow create or delete)

- data access (Business objects from the reference model are covering quite some parts of this)

- logical grouping within the data (e.g. one can change the sales office locations but only for Europe, not for the rest of the world).

There is also are also usually 2 general approaches to this in SAP:

1) I give the user rather too much access rights and when complaints come in, I will narrow it down or

2) I give very limitted access and when complaints come in, I will extend it.

Only for the later approach will anyone even ask for input like you are contemplating.

When you are thinking about providing input for the authorisation concept for SAP you have to be sure you understand the level of detail required and check what information you really have modelled in ARIS. The next question is then who will keep this information up-to-date if you have documented it. Chances are the guys managing the authorisation in SAP won't tell you of any changes they apply on weekly basis.We are talking after all about around 15,000 transaction codes and their combination with data and it's usage...

My 5 cents for this discussion.

Cheers,

Carmen

Hi Carmen and Frank,

thanks both for your thoughts and ideas, I too have taken a long time to react to these. Sorry about that, discussions should be active and alive, uh?

Carmen's short(?) contribution reveals there is a lot more to this subject that you see when you first have a look at it. Fascinating. One needs to think carefully where to start and how to set the scope.

Carmen - indeed long time no see, hope to get together again some time soon!

Regards from Denmark  / Harry