Neues SAP-System – neue Berechtigungen?

Das Thema Berechtigungen wird bei vielen SAP-Einführungen oder -Umstellungen lediglich als Nebensächlichkeit angesehen. Dabei ist es ein wichtiges Thema und sollte mit der nötigen Sorgfalt bedacht werden. Der anfängliche Mehraufwand lohnt sich vor allem bei der Neueinführung eines Systems.

Im neuen S/4 System sind Berechtigungen je nach Funktionsumfang des Nutzers sowohl auf Datenbankebene als auch auf Applikationsebene nötig. Die Datenbankebene ist hierbei für die Datenhaltung z. B. der Stammdaten zuständig. Vor der Einführung von HANA wurde für diese Ebene bspw. eine Oracle-Datenbank verwendet. Die Applikationsebene bezieht sich auf die eigentlichen Anwendungen, die diese Daten verarbeiten.

Neuerungen – von R/3 zu HANA

Auf Applikationsebene hat sich bzgl. Berechtigungen wenig verändert. Beim Umzug der Berechtigungen von R/3 auf S/4 sind an erster Stelle die neuen Transaktionen und Objekte zu beachten, wie z. B. Business Partner. Um das Berechtigungskonzept anzupassen, sollte man sich zunächst einen Überblick darüber verschaffen, welche Transaktionen wegfallen und welche neu hinzukommen. Anschließend wird geprüft, ob bei vorhandenen Rollen nur Änderungen durchgeführt werden müssen oder diese komplett ersetzt werden sollten.

Ein weiterer Unterschied, der sich von der Umstellung von R/3 auf ein HANA-System ergibt, sind die Begrifflichkeiten. Wo vormals noch von Berechtigungen und Rollen die Sprache war, werden nun Begriffe wie Privilegien eingeführt. Funktionen für die User werden in der Datenbank entweder über Rollen oder über spezielle Privilegien vergeben.

Erstellt man eine Rolle, werden Privilegien zugeordnet und in einem sogenannten Repository Object gespeichert. Eine Rolle kann durch eine andere erweitert werden und so all ihre bisherigen Privilegien vererben. Insgesamt gibt es fünf:

• • • System Privileges: Berechtigungen von administrativen Aufgaben
    • Object Privileges: Berechtigung von Datenbankobjekten
    • Package Privileges: Lese- und Schreibberechtigung von Repositories
    • Analytic Privileges: Beschränkung von Berechtigungen auf Daten
    • Application Privileges: HANA-Applikationsmanagement

Rollentypen in der HANA-Datenbank

In HANA können zwei Arten von Rollen unterschieden werden: Catalog- und Repository-Rollen. Abweichungen sind vor allem in den Zuständigkeiten bzw. der Verfügbarkeit der Rollen zu finden. Da SAP selbst die Nutzung von Catalog-Rollen empfiehlt, wird hier nicht weiter auf die Repository-Rollen eingegangen. Bei Catalog-Rollen kann ausschließlich der Entwickler der jeweiligen Rollen selbst die Rolle verwalten. Wird der zugehörige User gelöscht, fallen auch seine erstellten Catalog-Rollen weg. Generell sollten diese User auf der Datenbank nie gelöscht, sondern nur deaktiviert werden. Ein weiterer Nachteil von Catalog-Rollen ist, dass diese nicht transportiert werden können.

Berechtigungen für SAP Fiori

Um als SAP-Endnutzer SAP Fiori nutzen zu können, werden verschiedene Berechtigungen benötigt. Hierunter fallen beispielsweise Berechtigungen für das Launchpad oder OData-Berechtigungen, für welche SAP vorgefertigte Template-Rollen bereitstellt. Außerdem benötigt der Nutzer RFC-Backend-Berechtigungen, um eine gesicherte Verbindung auf den Backend-Server aufzubauen.

Den Endanwendern werden spezifische Berechtigungen für die Nutzung von Key-Performance-Indikatoren zugeordnet. Hier empfiehlt SAP, Rollen zu erstellen, die auf Benutzergruppen basieren. Auf diese Weise kann sichergestellt werden, dass User nur für ihre Tätigkeit relevante Applikationen sehen. Diese Berechtigungen werden auf dem Frontend-Server gepflegt.

Fazit

Mit dem Rollenkonzept auf Datenbankebene kommt ein neuer Arbeitsbereich auf Berechtigungsspezialisten zu. Je früher man damit anfängt, umso mehr Know-how kann im Laufe der Umstellung aufgebaut werden.

"Es lohnt sich, sich mit Berechtigungen frühzeitig auseinander zu setzen. Oft genügen geringfügige Änderungen bestehender Rollen, um die volle Funktionalität zu gewährleisten."

Man vermeidet so unerwarteten Aufwand während und/oder gar erst gegen Ende eines Projekts.