Was Kunden uns
am häufigsten fragen.

Typische Warnzeichen: ein hoher Anteil manuell gepflegter Werte und gelber/roter Ampeln in der PFCG, viele Einzel- statt abgeleiteter Rollen, großzügige „*“-Werte auf Organisationsebenen, SAP_ALL oder SAP_NEW im Produktivsystem, Sammelrollen, die quer durch mehrere Module greifen, sowie Notfalluser im Dauereinsatz. Ein gutes Frühwarnsignal ist auch, wenn jede neue Anforderung im Muster „Trace ziehen und nachpflegen“ endet und die SU24-Vorschlagswerte seit Jahren nicht mehr angefasst wurden.

Greenfield baut das Rollenkonzept vom Geschäftsprozess her neu auf – mit klarer Namenskonvention, Funktionsschnitt und Ableitung über die Org-Ebenen. Beste Qualität, aber höherer Aufwand und ein sauberes Alt-zu-Neu-Mapping nötig. Brownfield saniert den Bestand: Redundanzen entfernen, „*“-Werte ersetzen, ungenutzte Transaktionen aus Traces aussortieren, SU24 nachziehen – schneller, lässt aber strukturelle Altlasten. Hybrid übernimmt bewährte Funktionsschnitte, gießt sie aber in ein neues Namens- und Ableitungskonzept. Die Entscheidung treiben Auditdruck, Qualität des Ist-Konzepts, Zahl der Org-Ebenen und die Change-Kapazität der Fachbereiche.

Die transaktionsbasierte Welt wird um Fiori-Apps, Kataloge und Spaces ergänzt, und einzelne Prozesse ändern ihre technische Basis – etwa der zentrale Geschäftspartner (Business Partner) statt der getrennten Kreditoren-/Debitorenpflege. Damit verschieben sich Transaktionen, Vorschlagswerte und teilweise die zuständigen Berechtigungsobjekte. Wer Rollen 1:1 „mitnimmt“, schleppt vorhandene „*“-Werte mit und handelt sich doppelte Pflege auf Frontend- und Backend-Seite ein. Genau deshalb ist die Migration der beste Zeitpunkt für einen sauberen Schnitt statt für vererbte Altlasten.

Fiori trennt das Frontend (Launchpad-Inhalte über Kataloge/Gruppen bzw. Spaces & Pages und die Berechtigung auf die OData-Services, S_SERVICE) klar vom Backend mit den klassischen Berechtigungsobjekten. Business-Rollen bündeln die Apps aufgabenorientiert. Klassische Stolperfallen sind Kacheln ohne hinterlegtes Backend-Recht (oder umgekehrt), Katalogwildwuchs und fehlende Pflege beim Aktivieren neuer Apps. Wir bauen Front- und Backend konsistent und über die SU24-Vorschlagswerte gekoppelt – egal ob Embedded- oder Hub-Deployment.

Funktionstrennung heißt, dass kritische Vorgänge nicht in einer Hand liegen – und sie wird nicht über Transaktionen allein definiert, sondern über Objekt und Aktivität (ACTVT). Klassische Konflikte: Kreditor bzw. Geschäftspartner anlegen gegen Zahllauf (F110); Bestellung (ME21N), Wareneingang (MIGO) und Rechnungsprüfung (MIRO) in einer Person; Benutzer anlegen (SU01) gegen Rolle pflegen und zuordnen (PFCG); Eigenentwicklung freigeben gegen ins Produktivsystem importieren. Wir arbeiten mit einem risikobasierten Regelwerk und definieren für nicht sinnvoll auflösbare Konflikte dokumentierte kompensierende Kontrollen (Mitigating Controls).

Wir gehen die typischen Prüffelder strukturiert durch: kritische Berechtigungen (SAP_ALL, weit offene S_RFC, Tabellenzugriff über S_TABU_DIS/S_TABU_NAM, Debugging mit Replace über S_DEVELOP), Mandanten- und Systemänderbarkeit (SCC4, SE06/SE03), Standard- und technische User (SAP*, DDIC), Login-/Passwortparameter, den Notfalluser-Prozess samt Beantragung, Protokollierung und Review, SoD-Konflikte sowie das Transport- und Änderungsmanagement. Findings beheben wir ursachenbasiert – einen „*“-Wert ersetzen, statt eine Rolle zu duplizieren – und sorgen für eine prüfungsfeste, nachvollziehbare Dokumentation. Einen guten Einstieg bietet unser Katalog kritischer Berechtigungen.

NIS-2 macht aus Best Practice eine Nachweispflicht: rollenbasierte Zugriffskontrolle nach dem Least-Privilege-Prinzip, regelmäßige Rezertifizierung, ein dokumentierter und protokollierter Notfallzugriff und nachvollziehbare Protokollierung privilegierter Aktionen. Für SAP heißt das praktisch: kein dauerhaftes SAP_ALL, ein sauberes Rollen-Owner-Konzept, wiederkehrende User-Access-Reviews und Logging kritischer Zugriffe – etwa über das Security Audit Log (SM19/SM20), bei besonders sensiblen Daten ergänzt um Read Access Logging. Es muss jederzeit belegbar sein, wer auf was zugreifen kann und warum.

Wir kombinieren zwei Quellen: einen Berechtigungstrace über einen repräsentativen Zeitraum (STAUTHTRACE bzw. ST01, ergänzt um Nutzungsauswertungen) und einen fachlichen Soll-Abgleich im Workshop mit dem Bereich. Das tatsächlich Genutzte wird gegen die SU24-Vorschlagswerte gespiegelt, die Rolle in Entwicklung/QS gebaut und mit echten Prozessen verprobt. Ergebnis sind die wirklich benötigten Objekte und konkrete Org-Werte statt „*“. So vermeiden wir gleichzeitig Überberechtigung und das ständige Nachfordern fehlender Rechte.

Der Funktionsschnitt wird einmal als Master-Rolle definiert, die Org-Ausprägungen (Buchungskreis, Werk, Einkaufsorganisation, Personalbereich …) je Variante als abgeleitete Rolle. Dazu gehört ein durchdachtes Org-Ebenen-Konzept – inklusive der Sonderfälle wie Berechtigungsgruppen bei S_TABU_DIS oder RESPAREA im CO/PSM-Umfeld – damit Org-Werte nicht einzeln über die Rollen verstreut gepflegt werden müssen. Eine klare Namenskonvention macht Ableitung, Zweck und Zuständigkeit auf einen Blick erkennbar.

Ein Redesign hält nur mit einem Betriebskonzept dahinter. Dazu gehören gepflegte SU24-Vorschlagswerte als verbindliche Quelle, ein benannter Rollen-Owner mit definiertem Änderungsprozess, regelmäßige Rezertifizierungen, ein kontrollierter Notfalluser statt Dauer-Workaround, der Verzicht auf direkte Wertepflege im Produktivsystem und ein laufendes Monitoring kritischer Berechtigungen. Ohne diese Leitplanken wächst jede Rollenlandschaft binnen Monaten wieder zu.

In Phasen mit Rückfallebene: Analyse (Ist-Zustand, Traces, SoD, Findings) → Soll-Konzept und Namenskonvention → Rollenbau im Entwicklungssystem → Test und Verprobung echter Prozesse mit dem Fachbereich in der QS → Mapping der User auf die neuen Rollen → kontrollierter, meist nach Bereichen gestaffelter Cutover → Hypercare. Einen „Big Bang“ ohne Rückfalloption gibt es nicht; das Mapping von alt zu neu wird dokumentiert, damit jederzeit nachvollziehbar bleibt, warum wer welche Rolle erhält.

An keine. Wir arbeiten mit dem SAP-Standard (PFCG, SU24/SU25, SUIM, den Trace-Werkzeugen) und mit dem Berechtigungs- oder GRC-Werkzeug, das bei Ihnen bereits im Einsatz ist – herstellerunabhängig. Maßgeblich ist, was zu Ihrer Systemlandschaft und Ihren Prozessen passt, nicht was eine Lizenz vorgibt. Unsere Berater bringen Erfahrung über verschiedene Werkzeuge, SAP-Module und Branchen hinweg mit und arbeiten DACH-weit, remote wie vor Ort.