Einführung von neuen Organisationsebenen

Neue Organisationsebenen einführen

Das SAP-System arbeitet mit den verschiedensten Organisationsebenen (sog. Org-Ebenen oder Org-Levels). Eine der häufigsten ist der Buchungskreis (BuKrs), aber auch Werk, Einkaufsorganisation, Vertriebsweg etc. gehören dazu.

Über diese Org-Ebenen kann man nun innerhalb einer Masterrolle die Berechtigungen „global“ vergeben, und diese Rolle nach den einzelnen Org-Ebenen ableiten. Es entsteht damit eine abgeleitete Rolle, in der bis auf die Org-Ebenen die gleichen Berechtigungen vorliegen wie in der Masterrolle. Diese Rolle wird dann durch die unterschiedliche Bewertung der Org-Ebene auf bestimmte Benutzer zugeschnitten, die für die Org-Ebenen die Rechte haben sollen.

Die Anzahl der abgeleiteten Rollen zu dem Master ist fast beliebig. Das hat den Vorteil, bei Änderungen des Masters mit nur einem Klick alle abgeleiteten Rollen zu generieren und die Anpassung zu übertragen.

Was ist aber bei Eigenentwicklungen, eigenen Berechtigungsobjekten mit der Verwendung der Org-Ebenen? Kann man eigene Org-Ebenen anlegen?

Es gibt im System einen Report mit dem Namen PFCG_ORGFIELD_CREATE, mit diesem lassen sich auf ein B-Objekt Org-Ebenen definieren.

Doch Vorsicht.

Lassen Sie den Report zunächst nur im sog. Testmodus laufen. Er ermittelt zunächst die Auswirkungen, die Ihr Vorhaben haben wird. Denn was ist mit den Rollen, in denen das B-Objekt schon existiert und das B-Feld schon bewertet ist?

Alle Rollen, bei denen Sie die betroffenen B-Objekte ändern, werden inaktiv und müssen nachbearbeitet werden. Deshalb ist es bei der Konzeption des Rollenkonzeptes so wichtig auch über die Org-Ebenen zu diskutieren.

Noch schlimmer: Das Org-Ebenen-Feld wird mandantenübergreifend angelegt, da die Rollen aber mandantenbezogen sind, müssen Sie in allen Mandanten den Report im Testmodus laufen lassen, um sich einen Überblick über die Auswirkungen zu verschaffen.

Je früher Sie die Entscheidung zur Einführung einer neuen Org-Ebene fassen, um so weniger Nachfolgearbeiten werden Sie haben. Wenn die Berechtigung bisher noch nicht verwendet wurde, dann haben Sie leichtes Spiel.

Auch lassen sich nicht alle Felder in Org-Ebenen umwandeln, so geht das bei der Aktivität (ACTVT) nicht. Bei den Transaktionscodes „TCD“ ist die Org-Ebene auch verboten..

Die Einführung neuer Org-Ebenen lassen sich auch nicht transportieren: Sie müssen in den einzelnen Systemen manuell definieren

Trotz allem kann es für den Rollenadministrator eine erhebliche Hilfe sein, neue Org-Ebenen zu definieren. Auch wenn damit Nacharbeiten an bestehenden Rollen notwendig werden. Denn die Möglichkeit der Ableitung nach einer Org-Ebene überkompensiert die Nacharbeiten.

Die Org-Ebenen sind technisch in der Tabelle USORG gespeichert. Erkennbar sind die Orgebenen im PFCG durch Bewertungen in den B-Feldern die eine $-Variable darstellen – also z.B. $BUKRS. Bitte achten Sie auf diese Bewertungen. Denn falls Sie eine $-Variable überschreiben, gibt das System zwar manchmal eine Meldung aus, nicht immer. In einem solchen Fall ist die Rolle fehlerhaft und lässt sich nach der Generierung nicht mehr reparieren.
.
Wie und mit welchen Mitteln Sie neue Org-Ebenen vermeiden können, oder welche Implikationen neue Org-Ebenen auf die Entwicklung haben, wird Ihnen auch im
eBook: Techniken im Berechtigungswesen gezeigt.

Bernd Klüppelberg

2 Responses to “Einführung von neuen Organisationsebenen”

  1. Bin ja schon länger in SAP-Berechtigungsangelegenheiten unterwegs, aber heute erstmals hier in diesem Blog gelandet und ganz begeistert.
    Da wir gerade vor einem ähnlichen Problem stehen, z.B. Berechtigungsgruppen auf Konten neu zu definieren, möchte ich nicht für jede Kontengruppe, die ausgeprägt werden soll, eine neue Mutterrolle aufmachen, damit geht ja der Vorteil der Referenzrollen über die Wupper.
    Mal eben eine neue Orgebene on the Fly ist angesichts der hohen Anzahl weiterverwendeter Rollen in einem anderen Mandanten auch nicht gerade eine tolle Alternative.
    Gibt es neben der Verwendung von Werterollen nicht doch irgendeine Möglichkeit, in abgeleiteten Rollen zusätzliche Berechtigungsobjekte zu ergänzen, die man dann in der Mutterrolle vielleicht garnicht aufnimmt o. ä. Bei allen bisherigen Herangehensweisen sind mir meine Anpassungen in der abgeleiteten Rolle gnadenlos überklatscht worden.

  2. Hallo Steefi,
    danke für den netten Kommentar.
    Es gibt Möglichkeiten, die sich aber auf Fremdprodukte beziehen, im Standard PFCG werden die Child-Rollen immer von der Masterrolle „überklatscht“.

    Da es sich hier aber um Kontengruppen handelt, wäre mein Vorschlag, es mit Value-Rollen zu probieren.

    Im Master wird das entsprechende Objekt inaktiviert. Jeder Benutzer erhält entsprechend seiner Zugriffsberechtigung eine Value-Rolle, die nur die Kontengruppe(n) beinhaltet.
    Durch Ableitung des Masters werden in allen Child-Rollen auch die Objekte inaktiviert, die zugeordnete Value-Rolle aber lässt den Benutzer wieder zu einer Kontengruppe zu.
    Man kann – zur Vereinfachung der Useradministration – hier mit Sammelrollen vereinfachen. Oder man hat – und das habe ich schon bei einigen Kunden gemacht – sog. Musteruser angelegt, die nur kopiert werden müssen, ansonsten aber gesperrt angelegt sind.

    Man könnte im Userantrag für besondere Gebiete die Kontengruppen auch ankreuzen lassen, dahinter steht dann, die Zuordnung der entsprechenden Value-Rollen.
    Der entscheidende Vorteil dieser Methode, ist dass der User-Buffer (SU56) niedlich klein bleibt!

    Wie gesagt, es gibt auch Fremdprodukte, deren Rollen sich in SAP als Einzelrollen abbilden, im Produkt aber eine Vielzahl von Vererbungsmöglichkeiten unabhängig von Org-Ebenen anbieten.

    Gruß
    Bernd Klüppelberg

Schreiben Sie bitte einen Kommentar





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