So bauen Unternehmen in SAP Cloud ERP Public ein sicheres, wartbares und lizenzlogisches Berechtigungskonzept mit Business Roles, Business Catalogs und Restrictions auf.
Einleitung
Ein Berechtigungskonzept in SAP S/4HANA Cloud Public Edition muss anders aufgebaut werden als in klassischen SAP-Landschaften. In SAP Cloud ERP Public stehen nicht einzelne Transaktionen oder frei modellierte Berechtigungsobjekte im Zentrum, sondern ein standardisiertes Modell aus Business Users, Business Roles, Business Catalogs und Restrictions.
Genau darin liegt in Projekten oft die eigentliche Herausforderung. Viele Unternehmen übertragen noch immer die Logik aus SAP S/4HANA Private Cloud oder aus On-Premise-Welten in die Public Cloud. Das führt zu Sonderrollen, unnötiger Komplexität und einem Rollenmodell, das weder sauber steuerbar noch sauber zur PUPM-Lizenzlogik passt.
Aus Sicht von Fink IT-Solutions ist das Berechtigungskonzept in SAP Cloud ERP Public deshalb kein Randthema. Es ist ein zentraler Baustein für Sicherheit, Governance, Betriebsstabilität und wirtschaftlich nachvollziehbare Nutzung.
Inhaltsverzeichnis
- Was ist ein Berechtigungskonzept in SAP S/4HANA Cloud Public Edition?
- Wie funktioniert das Berechtigungsmodell in SAP Cloud ERP Public?
- Welche Objekte sind im Berechtigungskonzept von SAP Cloud ERP Public zentral?
- Was ist der Unterschied zwischen Public Cloud und Private Cloud im Berechtigungskonzept?
- Warum sind Restrictions im Berechtigungskonzept von SAP Cloud ERP Public so wichtig?
- Wie hängen PUPM und Berechtigungskonzept in SAP Cloud ERP Public zusammen?
- Welche Fehler treten beim Berechtigungskonzept in SAP S/4HANA Cloud Public Edition häufig auf?
- Wie baut die Fink IT-Solutions ein Berechtigungskonzept für SAP Cloud ERP Public in der Praxis auf?
- Fazit
- FAQ
Was ist ein Berechtigungskonzept in SAP S/4HANA Cloud Public Edition?
Ein Berechtigungskonzept in SAP S/4HANA Cloud Public Edition definiert, welche Benutzer in SAP Cloud ERP Public welche Aufgaben ausführen dürfen, über welche Rollen diese Zugriffe gesteuert werden und wie organisatorische Einschränkungen, Governance und Lizenzlogik zusammengeführt werden.
Ein belastbares Berechtigungskonzept umfasst dabei mindestens:
- ein fachliches Rollenmodell
- die Zuordnung von Business Roles
- die Nutzung passender Business Catalogs
- ein sauberes Restriction Design
- die Trennung von Endanwender-, Key-User- und Administrationsrollen
- Governance für Beantragung, Freigabe und Rezertifizierung
- eine nachvollziehbare Verbindung zur PUPM-Logik (Per User Per Month-Lizenzlogik)
Die entscheidende Frage lautet deshalb nicht: Welche Einzelberechtigung braucht ein User?
Sondern: Welche fachliche Persona braucht welche Rolle in welchem organisatorischen Kontext?
Wie funktioniert das Berechtigungsmodell in SAP Cloud ERP Public?
Das Berechtigungsmodell in SAP Cloud ERP Public folgt einer klaren Logik:
Business User → Business Role → Business Catalogs → Apps & Berechtigungen
Das bedeutet:
Ein Benutzer erhält in SAP S/4HANA Cloud Public Edition keinen Zugriff direkt auf einzelne Transaktionen. Stattdessen werden fachliche Zugriffe über Business Roles gesteuert. Diese Rollen enthalten Business Catalogs, und die Catalogs bündeln die benötigten Apps und Berechtigungen.
Für die Praxis ist das entscheidend. Denn ein gutes Berechtigungskonzept in SAP Cloud ERP Public wird nicht vom Einzelfall aus gedacht, sondern von wiederkehrenden Rollenbildern.
Typische Beispiele sind:
- Kreditorenbuchhalter
- Debitorenbuchhalter
- operativer Einkäufer
- Einkaufsleiter
- Projektcontroller
- Key User Finance
- IAM Administrator
Aus FINK-IT-Sicht gilt:
Je klarer die Persona, desto sauberer das Rollenmodell.
Welche Objekte sind im Berechtigungskonzept von SAP Cloud ERP Public zentral?
Business User
Der Business User ist der konkrete Anwender oder technische Benutzer, der Zugriff auf das System benötigt.
Wichtig ist dabei:
Der Zugriff wird nicht direkt vergeben, sondern über Rollen. Genau das macht das Modell in SAP Cloud ERP Public skalierbar und releasefähig.
Business Role
Die Business Role ist das zentrale Steuerungsobjekt im Berechtigungskonzept von SAP S/4HANA Cloud Public Edition. Sie definiert, welche Aufgaben ein Benutzer fachlich ausführen darf.
Ein gutes Rollenmodell orientiert sich an stabilen Aufgaben und nicht an Personen, Einzelwünschen oder historisch gewachsenen Sonderfällen.
Business Catalog
Business Catalogs enthalten die fachlich benötigten Apps und Berechtigungen. Sie sind das technische Bindeglied zwischen Rolle und tatsächlichem Zugriff.
Restrictions
Restrictions begrenzen Rollen auf konkrete Organisations- und Datenräume. Erst dadurch wird aus einer allgemeinen fachlichen Rolle eine sicher nutzbare Produktivrolle.
Typische Restriction-Felder sind:
- Buchungskreis
- Werk
- Einkaufsorganisation
- Verkaufsorganisation
- Kostenrechnungskreis
Was ist der Unterschied zwischen Public Cloud und Private Cloud im Berechtigungskonzept?
Der Unterschied zwischen SAP S/4HANA Cloud Public Edition und SAP S/4HANA Private Cloud ist im Berechtigungskonzept wesentlich.
Berechtigungskonzept in SAP Cloud ERP Public
In SAP Cloud ERP Public ist das Modell stärker standardisiert. Im Zentrum stehen:
- Business Roles
- Business Catalogs
- Restrictions
- rollenbasierte statt individuelle Vergabe
- hohe Wartbarkeit und Releasefähigkeit
Berechtigungskonzept in SAP S/4HANA Private Cloud
In der Private Cloud oder im klassischen S/4HANA ist das Berechtigungsmodell in der Regel flexibler, technischer und näher an klassischen SAP-Logiken aufgebaut. Unternehmen haben dort mehr Freiheitsgrade im Rollendesign, aber auch mehr Komplexität in der Pflege.
Was das in der Praxis bedeutet
Wer ein Berechtigungskonzept für SAP Cloud ERP Public mit Private-Cloud-Logik aufbaut, erzeugt oft genau die Probleme, die später teuer werden:
- zu viele Sonderrollen
- fehlende Standardisierung
- unklare Governance
- schlechte Skalierbarkeit
- hoher Pflegeaufwand
- kein sauberes Zusammenspiel mit PUPM
Aus unserer Projekterfahrung ist deshalb klar:
Public Cloud braucht ein Zielrollenmodell mit Cloud-Logik, nicht mit On-Premise-Denke.
Warum sind Restrictions im Berechtigungskonzept von SAP Cloud ERP Public so wichtig?
In vielen Projekten wird zuerst viel über Rollennamen und Rollenbeschreibungen gesprochen. Der eigentliche Qualitätshebel liegt aber fast immer woanders: bei den Restrictions.
Denn auch eine fachlich korrekt benannte Rolle ist problematisch, wenn sie organisatorisch zu weit gefasst ist. Genau dann entstehen Überberechtigungen.
Ein sauberes Restriction Design beantwortet unter anderem:
- Für welche Buchungskreise ist die Rolle gültig?
- In welchen Werken darf der Benutzer tätig sein?
- Welche Einkaufsorganisationen sind freigegeben?
- Auf welchen organisatorischen Ebenen ist eine Trennung erforderlich?
- An welchen Stellen ist eine Trennung aus Compliance-Sicht zwingend notwendig?
Aus Sicht von Fink IT-Solutions ist das einer der häufigsten Schwachpunkte in Projekten.
Nicht der Rollenname ist meist das Problem, sondern die fehlende organisatorische Eingrenzung.
Wie hängen PUPM und Berechtigungskonzept in SAP Cloud ERP Public zusammen?
Der Zusammenhang zwischen PUPM und Berechtigungskonzept in SAP S/4HANA Cloud Public Edition ist strategisch wichtig.
PUPM steht für ein nutzerbezogenes Lizenzmodell. Deshalb sollte das Berechtigungskonzept nicht isoliert von der Lizenzlogik entwickelt werden. Es geht nicht nur darum, wer technisch auf etwas zugreifen kann. Es geht auch darum, dass Rollen, Nutzung und Benutzerprofile sauber zusammenpassen.
Die Herleitung ist einfach
1. Rollen steuern die tatsächliche Nutzung
Was ein Benutzer in SAP Cloud ERP Public tun kann, hängt direkt von seinen Rollen, Catalogs und Restrictions ab.
2. Zu breite Rollen verzerren das Nutzungsbild
Wenn Benutzer Funktionen erhalten, die sie fachlich nicht brauchen, entsteht nicht nur ein Sicherheitsproblem. Es entsteht auch ein unsauberes, organisatorisch schwer erklärbares Nutzungsmodell.
3. PUPM braucht klare Personas
Damit die nutzerbezogene Lizenzlogik sauber funktioniert, müssen Rollen entlang realer Benutzerprofile geschnitten werden, zum Beispiel:
- Sachbearbeiter
- Genehmiger
- Key User
- Administrator
- Prozessverantwortlicher
4. Berechtigungskonzept und PUPM müssen zusammen gedacht werden
Ein gutes Berechtigungskonzept in SAP Cloud ERP Public hilft dabei,
- Benutzergruppen sauber zu trennen
- Rollen nachvollziehbar zuzuordnen
- Sonderrollen zu reduzieren
- Nutzungsprofile klar zu beschreiben
- Governance und Wirtschaftlichkeit zusammenzuführen
Das ist aus Fink-IT-Sicht der entscheidende Punkt:
Ein sauber geschnittenes Rollenmodell schafft nicht nur Sicherheit, sondern auch Transparenz in der nutzerbezogenen Lizenzlogik.
Welche Fehler treten beim Berechtigungskonzept in SAP S/4HANA Cloud Public Edition häufig auf?
In Projekten sehen wir immer wieder dieselben Muster:
- Standardrollen werden nahezu unverändert übernommen
- Rollen werden nach Personen statt nach Aufgaben aufgebaut
- Restrictions fehlen oder sind zu weit gefasst
- operative und administrative Rollen werden vermischt
- Governance-Prozesse werden zu spät definiert
- Release-Reviews werden nicht eingeplant
- PUPM und Berechtigungskonzept werden getrennt betrachtet
Gerade die letzte Schwäche ist in SAP Cloud ERP Public relevant. Wenn Rollenmodell und Lizenzlogik nicht zusammen gedacht werden, entstehen Unschärfen bei Nutzung, Verantwortlichkeit und Wirtschaftlichkeit.
Wie baut die Fink IT-Solutions ein Berechtigungskonzept für SAP Cloud ERP Public in der Praxis auf?
Aus unserer Erfahrung funktioniert ein Berechtigungskonzept für SAP S/4HANA Cloud Public Edition dann besonders gut, wenn es in fünf klaren Schritten aufgebaut wird.
1. Fachliche Rollenmatrix erstellen
Zunächst definieren wir gemeinsam mit den Fachbereichen die relevanten Personas, Aufgaben und Verantwortlichkeiten.
2. Business Roles und Catalogs sauber zuschneiden
Danach wird festgelegt, welche fachlichen Inhalte und welche Rollen pro Persona wirklich benötigt werden.
3. Restrictions systematisch designen
Im nächsten Schritt werden Buchungskreise, Werke, Einkaufsorganisationen und andere organisatorische Merkmale sauber auf Rollen und Verantwortlichkeiten abgebildet.
4. Governance und PUPM-Logik verbinden
Dann werden Freigaben, Rezertifizierungen, Rollentrennung, Sonderzugriffe und die nutzerbezogene Lizenzlogik zusammengeführt.
5. Rollen testen und produktiv zuordnen
Zum Schluss werden Rollen pro Persona getestet, Konflikte bereinigt und Benutzer sauber produktiv zugeordnet.
Unsere Projekterfahrung zeigt:
Das beste Berechtigungskonzept in SAP Cloud ERP Public entsteht dort, wo Fachlichkeit, Organisationslogik, Sicherheit und PUPM gemeinsam gedacht werden.
Fazit
Ein belastbares Berechtigungskonzept in der SAP S/4HANA Cloud Public Edition entsteht nicht durch einzelne Rollen, sondern durch ein klares Verbesserungskonzept mit definiertem Zielbild. Dazu gehören sauber geschnittene Business Roles, passende Catalogs, präzise Restrictions sowie eine klare Governance und die nachvollziehbare Verbindung zur PUPM-Logik.
Der Unterschied zeigt sich im Betrieb: Während einfache Modelle oft nur dokumentiert sind, sorgt ein strukturiertes Verbesserungskonzept für Sicherheit, Wartbarkeit und Transparenz im SAP Cloud ERP Public.
Sie möchten Ihr Berechtigungskonzept optimieren oder neu aufsetzen? Fink IT-Solutions unterstützt Sie dabei: Kontaktformular | Fink IT-Solutions – IT-Beratung & Lösungen in Würzburg – Fink IT-Solutions.
Für die Einordnung in ein übergreifendes Zielbild und die richtige Cloud-Strategie empfehlen wir zudem unseren Beitrag zum SAP Cloud ERP Entscheidungsframework.
FAQ
Das zentrale Steuerungsobjekt ist die Business Role. Über sie werden fachliche Aufgaben, Apps und Berechtigungen für Benutzer gebündelt.
In der Public Cloud ist das Modell stärker standardisiert und auf Business Roles, Business Catalogs und Restrictions ausgerichtet. In der Private Cloud und im klassischen S/4HANA sind Berechtigungsmodelle in der Regel flexibler und technischer geprägt.
Weil sie Rollen auf konkrete Organisations- und Datenräume eingrenzen. Ohne Restrictions entstehen schnell Überberechtigungen und unnötige Risiken.
In der Regel nicht. Standardrollen sind ein sinnvoller Startpunkt, müssen aber meist an die fachlichen Anforderungen, Organisationsstruktur und Governance des Unternehmens angepasst werden.