Rollentypen und ihre Auswirkungen

Heute wollen wir uns anschauen, welche Rollentypen es im SAP®-System gibt.

Ja ich weiß, das ist ein alter Hut! Doch kann ich ggf. auf einige weniger bekannte Dinge hinweisen, wie man einzelne Rollentypen einsetzt, oder welche man zwar einsetzen kann, diese aber doch – gerade am Anfang des Rollenkonzepts – enorme Zusatzarbeit bescheren können.
Fangen wir also an:

1. Die Einzelrolle

Die Einzelrolle soll einmal folgendermaßen definiert werden:

Eine Einzelrolle enthält mindestens eine Transaktion mit allen ihren Ausprägungen.

2. Die Masterrolle und Childrolle

Die Master- und die Childrollen stehen für die Möglichkeit von einer Rolle sogenannte Ableitungen zu erstellen. Diese Ableitungen unterscheiden sich nur in der unterschiedlichen Bewertung der sog. Organisationsebenen (=Org-Levels).

D.h. man erstellt eine Rolle mit einer Anzahl zugeordneter Transaktionen. Im System sind nun global sog. Organisationsebenen definiert, die in eine Rolle vom System mit einer eigenen Bewertung eingebaut werden können. Diese Organisationsebenen sind bspw. der Buchungskreis, die Einkaufsorganisation etc. Man baut sich nun eine Rolle, den sog. Master und bewertet dort die offenen Berechtigungen der Org-Levels mit bspw. „*“.

Im Nachhinein werden nun für jedes Org-Level weitere Rollen definiert, die die gleichen Transaktionen und Berechtigungsobjekte haben, nur dass in ihnen die Org-Levels jeweils anders bewertet sind. Man vergibt dann noch den Namen der Masterrolle und hat somit eine sog. abgeleitete Rolle oder eine Child-Rolle.

Der Vorteil an einer solchen Kombination von Master- und Childrollen ist die leichte Veränderbarkeit der Rollen. Wird bspw. eine neue Transaktion in die Rolle aufgenommen, dann wird nur die Masterrolle verändert. Die Childrollen – deren Struktur ja quasi vererbt wird – kann dann auf  „Knopfdruck“ mitverändert werden. Ja, dieses Vorgehen verbietet sogar die Veränderung der Childrolle, außer in den Org-Levels!

3. Die Valuerolle

Anders ist es bei der sog. Valuerolle (der Werterolle). Hier werden keine Transaktionen, sondern nur Berechtigungsobjekte definiert.

Eine Valuerolle kann man dann einem Benutzer zuordnen, und er erhält zusätzlich ein bestimmtes Recht.

Voraussetzung für die Anwendbarkeit einer Valuerolle ist natürlich, dass in den anderen, dem Benutzer zugeordneten Rollen, nicht dieses „Valuerollen-Objekt“ überlagert wird. D.h. in den Einzel- und Childrollen  werden die Objekte der Valuerolle ausgeschaltet.

So kann man z.B. in allen Rollen die Berechtigung für Up- und Download (S_GUI) inaktivieren. Damit hat zunächst kein Benutzer mehr das Recht einen Download oder Upload zu tätigen.

Definiert man nun eine Valuerolle mit dem Recht zum Download (S_GUI ACTVT=61),  und eine 2. Rolle mit dem Recht zum Upload (S_GUI ACTVT=60), dann können durch Zuordnung genau dieser beiden Rollen pro Benutzer diese Recht – unabhängig  von anderen Rollenbewertungen – gesteuert werden.

Man setzt Valuerollen auch oft bei der Unterscheidung des Zugriffs auf bspw. der Kostenstelle oder einer Kontengruppe im System ein.  Die Valuerolle stellt somit ein Mittel dar die Einführung eines neuen Org-Levels zu vermeiden.

4. Die Sammelrolle

Wie uns die System-Dokumentation zeigt, gibt es auch noch eine 4. Rollenart, die sog. Sammelrolle. Sie sammelt mehrere Rollen in einer Rolle, also einer Sammelrolle. Dazu gibt es in der Transaktion PFCG sogar eine eigene Funktion.

Dies hört sich gut an, doch möchte ich am Anfang des Konzeptes doch von der Sammelrolle abraten. Denn Änderungen an der Sammelrolle, bspw. wie Namensänderungen sind nur über Löschung und Neuanlage möglich, was einen erhöhten Aufwand darstellt. Überhaupt glaube ich, dass man im Konzept völlig auf Sammelrollen verzichten kann, und sie nur zu speziellen Dingen, wie einem generell feststehendem Benutzertyp einsetzen sollte.

Man tut sich einfach leichter, bei Anpassungen.

So, das soll es gewesen sien zu den unterschiedlichen Rollentypen. Weitere Informationen zu Rollentypen ihre Anwendung und das Handling können Sie im eBook: Techniken im Berechtigungswesen nachschlagen.

Herzliche Grüße

Bernd Klüppelberg

Schreiben Sie bitte einen Kommentar





SAP Berechtigungen, -Konzepte, -Technik | System Beratung Bernd Klüppelberg