Best Practice – Funktionsrollen mit dem RoleDesigner konzipieren
Autor: Luca Cremer | 18. Juni 2018
Schluss mit Tabellenkalkulationen, mehrwöchigen Iterationen und nachgelagerten Bereinigen von kritischen Berechtigungen. Ich möchte Ihnen mit diesem Blogbeitrag einen toolgestützten Best Practice-Ansatz zum Aufbau eines Funktionsrollen-Konzeptes für Fachabteilungen mit dem XAMS RoleDesigner vorstellen.
Der RoleDesigner ist ein Modul der Xiting Authorizations Management Suite, einem umfassenden Werkzeug zur Unterstützung bei Berechtigungsredesigns und dem Betrieb eines neuen Berechtigungskonzepts. Dieses Modul findet hauptsächlich zu Beginn eines Berechtigungsredesigns, in der Konzeptionsphase, seine Anwendung und bietet hier viele Vorteile gegenüber klassischen Ansätzen mit Tabellenkalkulationen, wie sie in Berechtigungsredesigns lange Zeit genutzt wurden.
Wie funktioniert der RoleDesigner?
Linksstehend finden sich alle Transaktionen, die von den Benutzern im Scope während eines bestimmten Zeitraums aufgerufen wurden. In der Mitte sind die (virtuellen) Rollen des Projektes aufgelistet. Rechts finden sich die Benutzer, gruppiert nach Abteilungen.
Das Hauptbild des RoleDesigners ist ein virtuelles Cockpit, in dem Benutzer nach Funktionen gruppiert, mit virtuellen Rollen provisioniert und diese mit Transaktionen befüllt werden können.
Transaktionen können via Drag&Drop in Rollen aufgenommen werden, Rollen den einzelnen Benutzern oder ganzen Gruppen von Benutzern zugewiesen werden. Für jeden Benutzer wird angezeigt, wie hoch der Abdeckungsgrad der aufgerufenen Transaktionen durch die neuen Rollen ist. Wir empfehlen hier, mindestens 90% zu erreichen und auf 100% abzuzielen. Ausnahmen können in eine Blacklist aufgenommen werden, sodass diese Transaktionscodes nicht in die Berechnung des Abdeckungsgrades einfließen.
Woher kommen die Daten?
Eine Gruppierung der Nutzer kann über die Benutzergruppe, Funktion oder Abteilung erfolgen. Diese Daten werden direkt aus dem Benutzerstamm gelesen und können im RoleDesigner angepasst werden, um eine bessere Gruppierung zu erreichen. Diese Änderungen haben keine Auswirkungen auf den Benutzerstamm.
Der RoleDesigner verwendet die in der ST03N erfassten Aufrufstatistiken. Wenn Sie ein Redesign planen, empfehlen wir daher, frühzeitig den Zeitraum für die Erhebung der ST03N-Daten auf 13 Monate einzustellen, um Jahresabschlüsse und Quartalsabschlüsse in den Scope zu nehmen. Mehr zur ST03N und wie Sie die Parameter einstellen können erfahren Sie in folgendem Beitrag:
SAP ST03N: Änderung der Aufbewahrungszeit von genutzten Transaktionen
Der Rollenbau erfolgt im Entwicklungssystem, im Vorfeld werden jedoch die benötigten ST03N-Daten aus der Produktion exportiert. So erhalten wir für jeden Benutzer eine Liste aller von ihm benötigten Transaktionen im Rahmen der täglichen Ausübung seiner Funktion.
ST03N - Genutzte SAP Transaktionen massenweise in Excel exportieren
Werten Sie die genutzten Transaktionen Ihrer SAP User aus der ST03N aus und exportieren Sie die Daten schnell und ohne manuelle Aufbereitung in Excel
Wen muss ich an den Tisch holen?
Jede Berechtigungsrolle benötigt einen Rollenverantwortlichen, der über deren Zuweisung und Änderungen am Inhalt auf Transaktionslevel entscheidet. Wir haben gute Erfahrungen damit gemacht, diese Verantwortung in die Fachbereiche zu geben und je Fachabteilung einen dedizierten Rollenverantwortlichen für die Funktionsrollen der Abteilung zu benennen. Dieser sollte frühzeitig involviert werden, im Idealfall schon zur Rollenkonzeptionsphase.
Wichtig ist hier eine klare Aufgabenverteilung: Der Rollenverantwortliche ist fachlich verantwortlich, das heißt er entscheidet darüber, welche Transaktionen/Anwendungen mit dieser Funktion ausgeführt werden dürfen und wer die verantwortete Rolle zugewiesen bekommen darf. Die technische Umsetzung und Ausprägung der Rolle liegt in der IT.
Durch die einfache Änderbarkeit der konzipierten Rollen im RoleDesigner können hier gemeinsam mit dem Rollenverantwortlichen verschiedene Szenarien durchgespielt und verschiedene Ansätze ausprobiert werden, ohne im System etwas zu ändern.
Wie können kritische Berechtigungen identifiziert werden?
Obwohl zu diesem Zeitpunkt des Projektes nur die Transaktionen angeschaut werden, so ist es trotzdem möglich, kritische Berechtigungen und SoD-Konflikte zu ermitteln, die üblicherweise auf Berechtigungsobjekt-Ebene definiert werden. Grund dafür ist die Arbeit mit der SU24 – der Transaktion zur Pflege kundenindividueller Vorschlagswerte.
Zu jeder Transaktion wird eine Reihe vorgeschlagener Berechtigungsobjekte von der SU24 geliefert. Diese Vorschlagswerte können um eigene Vorschlagswerte ergänzt werden. Der RoleDesigner kann die SU24-Daten auslesen und verarbeiten und so Konflikte aufdecken, bevor die Rollen überhaupt in der PFCG angelegt wurden.
Wie geht es danach weiter?
In den Berichten des RoleDesigners können alle konzipierten Rollen mit einem Klick in der PFCG angelegt werden. Transaktionscodes, die der Rolle zugewiesen worden, werden ins Menü der Rolle aufgenommen, sodass auch die Berechtigungsvorschlagswerte aus der SU24 den Weg in die Rollen finden.
Für einen späteren GoLive der neuen Rollen kann die konzipierte Benutzer-Rollen-Zuordnungsmatrix exportiert werden, diese lässt sich dann zum GoLive direkt ins System importieren und setzt die dort beschriebenen Zuordnungen live.
Mit dem hier beschriebenen Ansatz haben die Rollen natürlich noch nicht den Reifegrad, um live gesetzt zu werden. Stattdessen haben wir je Abteilung verschiedene Funktionen identifiziert, für diese Funktionsrollen aufgebaut und für diese Rollen alle beinhalteten Transaktionen ermittelt.
Stehen Sie vor der Herausforderung, ein neues, Funktionsrollen-basiertes Berechtigungskonzept implementieren zu wollen? Welche Erfahrungen haben Sie bei der Konzeption eines Rollenkonzeptes für Ihre Fachabteilungen gemacht? Ich freue mich auf Ihre Fragen und Anregungen.
