SAP-Berechtigungen nach dem Umstieg auf S/4HANA neu aufbauen
Die Konversion verschiebt Transaktionen, Datenmodell und Oberfläche gleichzeitig. Ein kopiertes Rollenmodell bildet danach weder die Arbeit noch die Kontrollen ab, die eigentlich gemeint waren.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Das alte Rollenmodell beschreibt ein System, das es so nicht mehr gibt
In den meisten Häusern ist das Berechtigungswesen über Jahre gewachsen. Eine Rolle entstand, weil jemand eine Transaktion brauchte, die nächste, weil eine Vertretung kurzfristig etwas buchen musste, und irgendwann kam eine Sammelrolle darüber, damit die Zuordnung schneller geht. Das funktioniert, solange sich das System nicht bewegt. Die Konversion auf SAP S/4HANA bewegt gleich mehrere Ebenen auf einmal, und deshalb fällt in diesem Moment auf, dass niemand mehr genau sagen kann, warum eine bestimmte Berechtigung in einer bestimmten Rolle steckt.
Fachlich ist der auffälligste Punkt der Geschäftspartner. Er ist in SAP S/4HANA das führende und obligatorische Objekt für Kunden- und Lieferantenstammdaten, und die gewohnten Transaktionen für den Debitoren- und Kreditorenstamm gibt es nicht mehr eigenständig, sie werden auf die Transaktion BP umgeleitet. Eine Rolle, die bisher sauber zwischen Debitorenpflege und Kreditorenpflege getrennt hat, trifft danach auf eine einzige Oberfläche, hinter der beides liegt. Die Trennung muss also anders gebaut werden als vorher, sonst ist sie einfach weg.
Dazu kommt die Oberfläche. SAP Fiori ist die vorgesehene Oberfläche für SAP S/4HANA, und für die volle Nutzererfahrung muss sie installiert und konfiguriert werden. Damit hängt der Zugriff nicht mehr nur an den Berechtigungsobjekten im ABAP-Backend, sondern zusätzlich an Katalogen und Gruppen auf der Oberflächenseite. Das BSI formuliert das im Baustein zum SAP-ERP-System als klare Anforderung: Werden neben dem ABAP-Backend weitere Komponenten wie SAP HANA und SAP NetWeaver Gateway für Fiori-Anwendungen verwendet, muss das Design der Berechtigungen zwischen den Komponenten abgestimmt und synchronisiert werden. Wer nur eine Seite pflegt, produziert entweder tote Kacheln oder offene Türen.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Die Fälle, die nach dem Go-Live wirklich auflaufen
Sortiert nach dem, was im Support ankommt, nicht nach der Systematik dahinter. Zu jedem Fall steht die Ursache im neuen System und der Umbau, der ihn dauerhaft erledigt.
Symptom
Sachbearbeiter melden, dass sie Kunden oder Lieferanten nicht mehr anlegen können. Die Rolle enthält aber genau die Transaktionen, mit denen sie das seit Jahren gemacht haben.
Ursache
Der Geschäftspartner ist in SAP S/4HANA das führende und obligatorische Objekt für Kunden- und Lieferantenstammdaten. Die spezifischen Transaktionen für Debitoren- und Kreditorenstamm gibt es nicht mehr eigenständig, sie werden auf die Transaktion BP umgeleitet. Die alte Rolle zeigt damit auf einen Einstieg, der die Prüfungen des Geschäftspartners gar nicht kennt.
Lösung
Bau die Rolle auf den Geschäftspartner um und nimm die dazugehörigen Berechtigungsobjekte auf. Die fachliche Trennung zwischen Kunden- und Lieferantenpflege bildest du danach über die Rollen des Geschäftspartners und die Berechtigungsfelder ab, nicht mehr über zwei getrennte Transaktionen. Rechne damit, dass diese Trennung im Fachbereich neu abgestimmt werden muss, weil sie technisch anders funktioniert als vorher.
Symptom
Nach dem Upgrade fehlt an einer Stelle eine Berechtigung, die vorher nie gefehlt hat, und an einer anderen Stelle prüft das System offensichtlich nicht mehr das, was im Konzept steht.
Ursache
Die Vorschlagswerte für Berechtigungsprüfungen kommen von SAP und werden über Upgrade, Support Package oder Hinweis ausgeliefert. Sie liegen in einer SAP-Sicht und in einer Kundensicht, und nur die Kundenwerte wirken beim Arbeiten im Profilgenerator. Ändert SAP seine Werte, passiert in den Kundentabellen von allein nichts.
Lösung
Führ den Abgleich der Vorschlagswerte über Transaktion SU25 durch und übernimm die von SAP gepflegten Werte. Das ist keine Kür, SAP führt diesen Schritt im Upgrade Guide als verpflichtende Nacharbeit. Plan die Nacharbeit an den betroffenen Rollen gleich mit ein, denn geänderte Vorschlagswerte schlagen bis in die einzelnen Rollen durch.
Symptom
Eine Fiori-App fehlt im Launchpad oder bricht beim Start ab, obwohl die Berechtigungen im Backend nachweislich vorhanden sind.
Ursache
Der Zugriff hängt an zwei Ebenen. Im Backend entscheiden Berechtigungsobjekte, auf der Oberfläche entscheiden Kataloge und Gruppen darüber, was überhaupt angeboten wird. Neue oder geänderte Inhalte in den SAP-Fiori-Katalogen wirken sich auf bestehende PFCG-Rollen aus, ohne dass jemand die Rolle angefasst hat.
Lösung
Nutze die Aktionen zur Aktualisierung der Anwendungsgruppen im Rollenmenü und zur Prüfung der betroffenen Rollen und behandle Backend und Oberfläche als einen Vorgang. Das BSI fordert für genau diese Konstellation, dass das Berechtigungsdesign zwischen den Komponenten abgestimmt und synchronisiert wird. Ein Team, das nur das Backend pflegt, wird diese Fehler nie zu Ende bekommen.
Symptom
Jemand aus der Buchhaltung kann plötzlich Kostenarten pflegen, obwohl seine Rolle unverändert aussieht und das Berechtigungskonzept diese Aufgabe im Controlling verortet.
Ursache
Im neuen Datenmodell decken Konto und Kostenart dasselbe Feld ab, bestehende Sachkonten und Kostenarten werden bei der Migration in dieses Modell überführt. SAP hält in der Simplification List ausdrücklich fest, dass Kundenrollen mit Menüs und Berechtigungen angepasst werden müssen und dass für die Pflege primärer und sekundärer Kostenarten Berechtigungen für beide Seiten nötig sind.
Lösung
Schneid die Stammdatenpflege im Rechnungswesen fachlich neu. Klär mit Finanzbuchhaltung und Controlling gemeinsam, wer Konten anlegt, wer Kostenarten anlegt und wo die Freigabe liegt, und bild das anschließend im Rollenmodell ab. Diese Abstimmung gehört vor die Konversion, nicht in die Woche nach dem Go-Live.
Symptom
Eine Berechtigung, die während der Stabilisierung nachgepflegt wurde, ist nach dem nächsten Transport wieder verschwunden, und niemand kann rekonstruieren, wer sie ursprünglich vergeben hat.
Ursache
Die Rolle wurde direkt im Produktivsystem geändert. Das BSI verlangt für den Regelfall das Gegenteil: Berechtigungsrollen werden im Entwicklungssystem angelegt und gepflegt und mit dem Transport-Management-System weitergereicht, und das Produktivsystem ist vor Berechtigungsänderungen zu schützen.
Lösung
Sperr den Weg über das Produktivsystem und richte stattdessen einen kurzen, dokumentierten Änderungsweg ein: Antrag, Genehmigung, Änderung im Entwicklungssystem, Transport. Das Qualitätssicherungssystem sollte dabei bei der Berechtigungsvergabe analog zum Produktivsystem betrieben werden, sonst prüfst du gegen ein System, das andere Regeln hat als das Ziel.
Symptom
Für die Projektphase hat jemand weitreichende Sammelprofile im Produktivsystem vergeben, und ein Jahr später hängen sie immer noch an denselben Kennungen.
Ursache
Es gab kein Notfallkonzept, sondern nur einen schnellen Ausweg. Die Profile SAP_ALL und SAP_NEW* sowie das Berechtigungsobjekt S_DEVELOP mit Änderungsberechtigung sollten nach BSI-Vorgabe im Produktivsystem nicht vergeben werden, ausgenommen sind ausdrücklich nur Notfallkonten.
Lösung
Richte einen Notfallzugang ein, der beantragt, zeitlich begrenzt und protokolliert wird, und zieh die Dauerberechtigungen zurück. Kritische Berechtigungen und kritische Rollenkombinationen gehören danach regelmäßig identifiziert, überprüft und bewertet, sonst wächst der nächste Bestand genauso still nach wie der letzte.
Fünf Punkte, an denen ein kopiertes Rollenmodell reißt
- 01 Debitoren- und Kreditorenpflege laufen jetzt über eine einzige Oberfläche.
- 02 Konto und Kostenart liegen im selben Datenmodell und brauchen beide Berechtigungen.
- 03 Kacheln und Kataloge auf der Oberfläche entscheiden mit über den Zugriff.
- 04 Geänderte SAP-Vorschlagswerte wirken erst nach dem Abgleich in den Kundentabellen.
- 05 Weggefallene Transaktionen bleiben als Leichen in Menüs und Berechtigungen stehen.
Was du nach dieser Seite in eine belastbare Reihenfolge bringen kannst
Ein Rollenmodell entsteht nicht dadurch, dass jemand die Fehlermeldungen der ersten Woche nacharbeitet. Die folgenden sechs Punkte sind die Reihenfolge, in der die Arbeit tatsächlich zusammenpasst, und sie beginnt bewusst nicht im System, sondern bei der Frage, wer welche Aufgabe hat.
Vom Arbeitsplatz her denken, nicht von der Transaktion her
Beschreib zuerst die Arbeitsplätze im Fachbereich und erst danach, was sie im System dafür brauchen. Das BSI empfiehlt genau diesen Weg: Das Rollenkonzept orientiert sich an der Organisationsstruktur, Rollen unterscheiden sich nach Anzeige- und Änderungsberechtigung, und Leute mit derselben Aufgabe arbeiten auch mit denselben Berechtigungen.
Den Bestand auswerten, statt ihn zu übernehmen
Vor der Konversion lässt sich messen, welche Transaktionen im Altsystem tatsächlich benutzt wurden und von wem. Diese Auswertung ist die einzige belastbare Grundlage dafür, welche Berechtigungen im neuen Modell wirklich gebraucht werden. Alles, was über Jahre in keiner Aufzeichnung auftaucht, ist ein Kandidat für den Wegfall und keiner für die Übernahme.
Die Vorschlagswerte abgleichen, bevor Rollen entstehen
SAP liefert Vorschlagswerte für Berechtigungsprüfungen aus, diese Daten werden in Transaktion SU22 angezeigt. Die Kundenwerte liegen in SU24, und nur diese wirken, wenn im Profilgenerator PFCG gearbeitet wird. Nach einem Upgrade können sich die SAP-Werte geändert haben, deshalb schreibt SAP den Abgleich über Transaktion SU25 ausdrücklich vor.
Backend und Oberfläche gemeinsam schneiden
Nach dem Abgleich der Vorschlagswerte folgt die Nacharbeit an den PFCG-Rollen, und dabei zählen auch neue oder geänderte Inhalte in den SAP-Fiori-Katalogen. SAP nennt dafür die Aktionen zur Aktualisierung der Anwendungsgruppen im Rollenmenü und zur Prüfung der betroffenen Rollen. Beides gehört in denselben Arbeitsgang und nicht in zwei Projekte.
Rollen im Entwicklungssystem bauen und transportieren
Berechtigungsrollen sollten nur im Entwicklungssystem angelegt und gepflegt und mit dem Transport-Management-System weitergereicht werden. Wer im Produktivsystem nachbessert, verliert die Änderung beim nächsten Transport und hat außerdem keine Spur davon, wer wann was verändert hat.
Kritische Berechtigungen von Anfang an ausschließen
Die Profile SAP_ALL und SAP_NEW* sowie das Berechtigungsobjekt S_DEVELOP mit Änderungsberechtigung gehören nach BSI-Vorgabe nicht ins Produktivsystem. Ausgenommen sind Notfallkonten, und die brauchen ein eigenes Konzept mit Protokollierung, sonst werden aus der Ausnahme dauerhafte Berechtigungen.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Was die Konversion technisch am Berechtigungswesen verändert
Die Bausteine bleiben dieselben. Eine Rolle enthält ein Menü und Berechtigungsdaten, daraus erzeugt der Profilgenerator ein Berechtigungsprofil, und über die Benutzerpflege landet die Rolle an einer Kennung. Ein Berechtigungsobjekt bündelt dabei mehrere Berechtigungsfelder, und ein Feld für die Aktivität entscheidet darüber, ob jemand anzeigen, anlegen oder ändern darf. Dieses Grundmuster hat die Konversion überlebt, und deshalb wirkt der Umstieg auf den ersten Blick harmlos.
Verändert hat sich, worauf die Objekte zeigen. Die Simplification List zu SAP S/4HANA nennt an vielen Stellen genau diese Folge: Kundenrollen mit Menüs und Berechtigungen müssen angepasst werden. Mal, weil Transaktionen nicht mehr unterstützt sind und aus Menüs und Berechtigungen entfernt gehören, mal, weil ein Vorgang jetzt über eine Fiori-Anwendung läuft und die Rolle diese Anwendung erst im Launchpad sichtbar machen muss, mal, weil zwei früher getrennte Stammdatenbereiche im selben Objekt zusammenlaufen.
Der zweite Unterschied ist die Oberfläche. In On-Premise und in der Private Cloud bleiben klassische Transaktionen und das SAP GUI verfügbar, SAP Fiori ist aber die vorgesehene Oberfläche und muss für die volle Nutzererfahrung installiert und konfiguriert werden. Für das Berechtigungswesen heißt das: Es gibt jetzt zwei Wege in dieselbe Funktion, und beide müssen dasselbe erlauben und dasselbe verbieten. Eine Rolle, die im Launchpad nichts anbietet, aber im GUI alles zulässt, ist keine Berechtigung, sondern eine Illusion von Ordnung.
Warum Kopieren so verlockend ist und warum es trotzdem nicht trägt
Das Argument für die Kopie klingt gut: Die Leute machen dieselbe Arbeit wie vorher, also brauchen sie dieselben Berechtigungen. Der Haken ist, dass die alte Rolle nicht die Arbeit beschreibt, sondern die Geschichte der letzten zehn Jahre. Darin stecken Berechtigungen für Vertretungen, die es nicht mehr gibt, für Auswertungen, die nie jemand aufgerufen hat, und für Sonderfälle aus einem Projekt, das längst abgeschlossen ist. Diese Ablagerungen wandern beim Kopieren mit, und im neuen System wirken sie oft breiter als vorher, weil die dahinterliegenden Objekte inzwischen mehr abdecken.
Dazu kommt ein Nachweisproblem. Das BSI verlangt, dass alle relevanten Daten aufbewahrt werden: die Zuordnung eines Benutzers zu einer natürlichen Person, die Zuweisung von Berechtigungen sowie Art, Umfang, Änderungen und die ändernde Stelle. Wer eine gewachsene Rolle kopiert, kann für keinen einzigen Eintrag darin sagen, wer ihn wann genehmigt hat. Spätestens bei der ersten Prüfung ist das die unangenehmere Diskussion, weil sie nicht mit einem Nachtrag zu erledigen ist.
Der dritte Punkt ist der Aufwand, den die Kopie nur verschiebt. Jede weggefallene Transaktion, jede geänderte Prüfung und jede neue Fiori-Anwendung erzeugt später einen Einzelfall im Support. Die Summe dieser Einzelfälle ist regelmäßig größer als der Aufwand, das Modell einmal sauber neu zu schneiden, und sie verteilt sich über Monate auf Leute, die dafür keine Zeit eingeplant haben. Ein neu gebautes Modell kostet Projektzeit, ein kopiertes kostet Betriebszeit, und die Betriebszeit ist teurer.
Die Reihenfolge, in der ein neues Rollenmodell entsteht
Am Anfang steht die fachliche Beschreibung. Welche Arbeitsplätze gibt es, welche Aufgaben gehören dazu, welche Organisationseinheiten sind betroffen. Das BSI beschreibt dafür ein Muster, das sich bewährt hat: eine Businessrolle je Arbeitsplatz, die alle notwendigen Einzel- und Sammelrollen umfasst, und kritische Funktionen, die nur einzelne Leute ausüben sollen, in zusätzlichen Rollen daneben. Damit bekommt die Mehrheit eine Zuordnung, und die Ausnahmen bleiben sichtbar, statt in einer großen Rolle zu verschwinden.
Danach folgt die technische Seite. Die Vorschlagswerte werden abgeglichen, die Rollen entstehen im Entwicklungssystem, und die Berechtigungsdaten werden dort gepflegt, wo der Profilgenerator sie anbietet. Die Gesamtberechtigung mit Stern und weit gespannte Intervalle in Objektausprägungen sollten dabei vermieden werden, weil sie die Prüfung faktisch abschalten. Bei Eigenentwicklungen gehört die Zuordnung von Berechtigungsobjekten zu Transaktionen ausdrücklich gepflegt, sonst prüft das System an dieser Stelle gar nichts.
Erst danach kommt der Test, und der ist der Teil, den Projekte regelmäßig zu kurz planen. Getestet wird nicht, ob eine Rolle sich erzeugen lässt, sondern ob eine Person mit dieser Rolle einen vollständigen Vorgang durcharbeiten kann und an der richtigen Stelle stehen bleibt. Dafür braucht es echte Vorgänge aus dem Fachbereich und ein Qualitätssicherungssystem, das bei der Berechtigungsvergabe analog zum Produktivsystem eingestellt ist. Alles andere verschiebt die Fehler nur auf den ersten Arbeitstag im neuen System.
Was im Betriebsmodell liegen bleibt, auch wenn SAP betreibt
Beim Weg über RISE with SAP führt der Zielpfad auf SAP Cloud ERP Private, und SAP übernimmt einen erheblichen Teil des technischen Betriebs. Der Leistungsschnitt steht in einem eigenen Vertragsdokument zu Rollen und Verantwortlichkeiten, und dort ist die Zuordnung eindeutig: Definition, Pflege, Überprüfung und Prüfung von Rollen, Profilen und Berechtigungen sind nicht als Standardleistung geführt, ebenso wenig die Verwaltung der Benutzer.
Für die Planung heißt das etwas sehr Praktisches. Die Frage, wer nach dem Umstieg Rollen baut, wer sie genehmigt und wer die Zuordnung pflegt, wird durch das Betriebsmodell nicht beantwortet. Sie bleibt im eigenen Haus, und wenn dafür keine Stelle benannt ist, landet sie erfahrungsgemäß bei der Person, die zuletzt damit zu tun hatte. Das ist genau die Konstellation, aus der Rollen entstehen, die niemand mehr erklären kann.
Das gilt auch für die Fachlichkeit dahinter. Wer entscheidet, ob eine Freigabegrenze bei einer bestimmten Summe liegt, ist keine Systemfrage, sondern eine Frage des Fachbereichs. Das Berechtigungskonzept schreibt diese Entscheidung nur auf und setzt sie durch. Ein Projekt, das die Berechtigungen der Basisabteilung überlässt, bekommt am Ende ein technisch sauberes Modell, das die falschen Grenzen zieht.
Was danach dauerhaft laufen muss
Ein Rollenmodell ist mit dem Go-Live nicht fertig, es fängt dort an zu altern. Das BSI verlangt deshalb, dass kritische Berechtigungen regelmäßig identifiziert, überprüft und bewertet werden, und zwar ausdrücklich auch kritische Rollenkombinationen und additive Effekte, die erst entstehen, wenn jemand zwei für sich harmlose Rollen gleichzeitig hat. Diese Prüfung braucht einen Termin im Kalender, sonst findet sie nicht statt.
Der zweite Dauerlauf ist die Änderung selbst. Berechtigungen werden beantragt, genehmigt, geändert und gelöscht, und für jeden dieser Schritte muss eine Vorgehensweise definiert sein. Sinnvoll ist eine Genehmigung nach dem Vier-Augen-Prinzip, im ersten Schritt durch die Führungskraft der anfragenden Person und im zweiten durch die Stelle, die für den betroffenen Prozess verantwortlich ist. Wer genehmigt, sollte die betroffenen Abläufe und den Inhalt der Rollen im eigenen Verantwortungsbereich kennen.
Der dritte Punkt betrifft die technischen Kennungen. Neben den Leuten arbeiten Hintergrundjobs und Schnittstellen im System, und auch für sie gilt das Minimalprinzip. Ein einziger technischer Benutzer für viele Schnittstellen und Jobs sammelt zwangsläufig zu viele Berechtigungen an und erhöht das Risiko, dass ein Problem an einer Stelle den gesamten Betrieb trifft. Diese Kennungen gehören szenarienbezogen geschnitten und in dieselbe regelmäßige Prüfung wie die Dialogkennungen.
Dazu passende Kurse
Weil sich der Aufbau eines Rollenmodells schlecht aus Dokumentation allein erschließt, sind Kurse zum Berechtigungskonzept im SAP-System der kürzere Weg als der Versuch am eigenen Produktivsystem.
Wer Berechtigungen ernst nimmt, stößt schnell auf Kennungen, Schnittstellen und Protokollierung außerhalb des ERP, und dafür gibt es Kurse zu Zugriffsschutz über das SAP-System hinaus .
Wie sicher bist du beim Thema wirklich?
Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.
Wo du genau das übst
Häufige Fragen
Können wir die Berechtigungen nicht erst nach dem Go-Live aufräumen?
Was genau erledigt der Abgleich der Vorschlagswerte, und was nicht?
Brauchen wir für die Fiori-Oberfläche ein zweites Berechtigungskonzept?
Wie gehen wir mit Berechtigungen um, die aus einer Eigenentwicklung stammen?
Lohnt sich ein Werkzeug für die Analyse, oder reicht Bordmittel?
Quellen
- SAP, Upgrade Guide for SAP S/4HANA 2025, Abschnitt Default Authorization Values and PFCG Roles
- SAP, Simplification List for SAP S/4HANA 2025 FPS01
- BSI, IT-Grundschutz-Baustein APP.4.2 SAP-ERP-System
- BSI, Umsetzungshinweise zum Baustein APP.4.2 SAP-ERP-System
- SAP, RISE with SAP S/4HANA Cloud Private Edition, Roles and Responsibilities
Passt thematisch dazu
Damit das neue Rollenmodell nach dem Start nicht wieder auseinanderläuft, braucht es dauerhaft die Trennung zwischen Regelwerk und Umsetzung im System .
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem SAP-Programm den passenden Kurs für deinen Stand zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.
Berechtigungen einmal von der Aufgabe her aufbauen
Im Kurs zum Berechtigungskonzept bei cmt gehst du den Weg von der fachlichen Beschreibung über Rolle und Profil bis zur Prüfung im System durch, und zwar an Fällen, wie sie nach einer Konversion tatsächlich auflaufen.