ERP-Berechtigungen dürfen nicht vom Vorgänger kopiert werden

Eine neue Mitarbeiterin übernimmt die Aufgaben eines Kollegen. Die scheinbar schnellste Berechtigungsanweisung lautet: „Bitte dieselben Rechte wie der Vorgänger.“ Damit werden aber nicht nur seine regulären Aufgaben kopiert. Häufig wandern alte Vertretungen, Projektrollen, individuelle Ausnahmen und längst vergessene Zusatzrechte mit.

Das Ergebnis funktioniert zunächst. Gerade deshalb bleibt der Fehler lange unsichtbar. Niemand kann später zuverlässig erklären, welche Tätigkeit jedes Recht begründet und wer die Kombination genehmigt hat.

ERP-Berechtigungen sollten nicht von einer vermeintlich passenden Person abgeleitet werden. Ausgangspunkt sind die tatsächlichen Aufgaben, Entscheidungskompetenzen und Datenbereiche einer fachlichen Rolle. Die Person wird anschließend einer oder mehreren geprüften Rollen zugeordnet.

Fünf Ebenen müssen zusammenpassen

In der Praxis werden unterschiedliche Begriffe häufig vermischt. Für ein nachvollziehbares Modell hilft eine klare Kette:

1. Aufgabe: Was muss die Person fachlich tun, etwa einen Lieferanten anlegen?
2. Geschäftsrolle: In welchem Verantwortungszusammenhang tut sie das, etwa Kreditorenbuchhaltung?
3. ERP-Funktion: Welche Transaktionen, Masken, Aktionen oder Dienste werden dafür benötigt?
4. Datenumfang: Für welche Gesellschaft, Niederlassung, Kostenstelle oder Belegart gilt das Recht?
5. Entscheidungsrecht: Darf die Person nur vorbereiten, verbindlich freigeben oder kontrollieren?

Ein technischer Zugriff beantwortet die letzte Frage nicht automatisch. Jemand kann eine Freigabeschaltfläche sehen und trotzdem organisatorisch nicht befugt sein, sie zu benutzen. Umgekehrt kann eine fachlich befugte Rolle ihre Aufgabe nicht erfüllen, wenn das technische Recht fehlt.

Der Beitrag „Verantwortlichkeiten als Voraussetzung für skalierbaren IT-Betrieb“ vertieft diese Trennung. Für ERP-Systeme muss sie bis in konkrete Funktionen und Datenbereiche übersetzt werden.

Der Vorgänger ist ein Hinweis, keine Vorlage

Der bisherige Stelleninhaber kann zeigen, welche Funktionen im Alltag wahrscheinlich benötigt werden. Seine Berechtigungen sind aber nur ein unsicheres Indiz. Sie können enthalten:

• historische Aufgaben, die längst entfallen sind,
• temporäre Projekt- oder Vertretungsrechte,
• manuell gewährte Fehlerbehebungen,
• Rechte aus einer früheren Position,
• zu weit gefasste Standardrollen,
• unerkannte Konflikte aus mehreren Rollenkombinationen.

Wer diese Kombination kopiert, übernimmt ihre Geschichte ohne Begründung. Besser ist der umgekehrte Weg: Die Führungskraft und der Process Owner beschreiben die Tätigkeit. Der fachliche System- oder Datenverantwortliche ordnet eine freigegebene Rolle zu. Die IT setzt diese Zuordnung technisch um und weist auf Konflikte hin.

Das BSI fordert in ORP.4 unter anderem eine bedarfsgerechte Berechtigungsvergabe, geregelte Beantragung und Genehmigung, zeitnahe Anpassung sowie regelmäßige Überprüfung. Eine Personenkopie liefert für den Bedarf gerade keine belastbare Begründung.

Rollen werden rückwärts aus dem Prozess gebaut

Ein Rollenmodell sollte nicht mit allen vorhandenen ERP-Rechten beginnen. Diese Sicht erzeugt schnell technische Kataloge, die der Fachbereich kaum prüfen kann. Der sinnvollere Startpunkt ist ein relevanter Geschäftsprozess.

Für jeden Prozessschritt wird geklärt:

• Welche fachliche Aufgabe wird erledigt?
• Welche Daten werden gelesen, erstellt, geändert oder gelöscht?
• Welche Entscheidung oder Freigabe ist enthalten?
• Welche Organisationseinheiten und Wertebereiche sind betroffen?
• Welcher Nachweis muss erhalten bleiben?
• Welche andere Aufgabe darf nicht unkontrolliert mit ihr kombiniert werden?

Erst danach werden die notwendigen ERP-Funktionen zu einer Geschäftsrolle gebündelt. Technische Standardrollen des Herstellers können dabei Ausgangsmaterial sein. Sie sind kein Beweis dafür, dass Umfang und Kombination zur eigenen Organisation passen.

Funktionstrennung richtet sich gegen gefährliche Kombinationen

Einzelne Rechte können für sich sachgerecht sein und gemeinsam ein Risiko erzeugen. Typische Konflikte sind beispielsweise:

• Lieferantenstammdaten ändern und Zahlungen freigeben,
• Bestellung anlegen und denselben Vorgang genehmigen,
• Benutzer verwalten und die eigene Tätigkeit kontrollieren,
• Buchung erfassen und Korrektur oder Auszahlung allein freigeben.

NIST SP 800-53 Revision 5 behandelt Account Management, Separation of Duties und Least Privilege als zusammenhängende allgemeine Kontrollprinzipien. Der Standard schreibt kein konkretes ERP-Rollenmodell für den Mittelstand vor. Er stützt aber die Grundidee, Rechte auf notwendige Aufgaben zu begrenzen und kritische Prozessschritte nicht unkontrolliert in einer Hand zu bündeln.

In kleinen Unternehmen lässt sich eine ideale Trennung nicht immer personell abbilden. Dann ist die ehrliche Lösung nicht, den Konflikt im Rollenmodell zu verstecken. Er wird dokumentiert, von einer befugten Stelle akzeptiert und durch eine geeignete Kontrolle begrenzt – etwa eine unabhängige nachgelagerte Prüfung, engere Wertgrenzen, zusätzliche Protokollauswertung oder eine zeitlich begrenzte Freigabe.

Konstruiertes Beispiel: Die alte Vertretung reist mit

Das folgende Beispiel ist konstruiert.

Eine neue Mitarbeiterin in der Kreditorenbuchhaltung erhält die Rechte ihres Vorgängers. Dessen Konto vereinte eine reguläre Buchhaltungsrolle, eine frühere Projektrolle und eine temporäre Vertretung für einen erkrankten Kollegen. Dadurch kann die neue Mitarbeiterin sowohl Lieferantenstammdaten ändern als auch Zahlungen vorbereiten.

Keine einzelne Zuweisung wirkt auf den ersten Blick ungewöhnlich. Erst die wirksame Kombination zeigt den Konflikt. Bei einer rollenbasierten Neuanlage wäre zunächst die Tätigkeit beschrieben, dann die reguläre Geschäftsrolle zugeordnet und ein notwendiger Zusatz separat beantragt worden. Die temporäre Vertretung hätte ein Ablaufdatum und einen dokumentierten Kontrollmechanismus erhalten.

Das Beispiel behauptet keinen tatsächlichen Schaden. Es zeigt, warum funktionierende Zugriffe kein Nachweis für angemessene Rechte sind.

Eine Rollen- und Berechtigungskarte

Ein mittelständisches Rollenmodell muss nicht mit hunderten Seiten beginnen. Für die wichtigsten Geschäftsrollen genügt zunächst eine Karte, die fachliche Begründung und technische Umsetzung verbindet.

Feld	Inhalt
Rollenname und Zweck	verständliche Geschäftsrolle statt Personenname
Aufgaben	konkrete Tätigkeiten im Prozess
Entscheidungsumfang	vorbereiten, ausführen, freigeben oder kontrollieren
ERP-Funktionen	benötigte Transaktionen, Aktionen, Dienste oder technischen Rollen
Datenumfang	Gesellschaften, Standorte, Bereiche, Belegarten und Wertgrenzen
Voraussetzungen	Schulung, Funktion, Vertrag oder andere organisatorische Bedingung
Konflikte	unzulässige oder prüfpflichtige Rollenkombinationen
Genehmigung	fachlich befugte Rolle und notwendige Mitzeichnungen
Ausnahme	Begründung, Zusatzkontrolle, Owner und Ablaufdatum
Review	Prüfanlass, Turnus, Nachweis und letzte Entscheidung

Die Karte sollte für Fachverantwortliche lesbar bleiben. Eine reine Liste technischer Berechtigungsobjekte kann ergänzend notwendig sein, darf aber nicht das einzige Entscheidungsdokument werden.

Zuständigkeiten dürfen nicht bei der IT enden

Die IT kann zeigen, welche Rechte technisch wirksam sind. Sie kann nicht allein entscheiden, welche Tätigkeit oder Freigabekompetenz eine Person fachlich besitzen soll.

Eine sinnvolle Aufteilung ist:

Rolle	Verantwortung
HR und Führungskraft	organisatorische Zuordnung, Eintritt, Wechsel und Austritt
Process Owner	Aufgaben, Entscheidungspunkte und notwendige Funktionstrennung
fachlicher System- oder Daten-Owner	Inhalt und Genehmigung der Geschäftsrollen
Informationssicherheit oder Kontrollfunktion	Regeln für Konflikte, Privilegien und Nachweise
IT-Administration	technische Umsetzung, wirksame Rechte, Protokollierung und Rückmeldung

In kleinen Organisationen können mehrere Verantwortungen bei derselben Person liegen. Die Entscheidungen sollten trotzdem unterscheidbar dokumentiert werden. Sonst wird aus technischer Machbarkeit stillschweigend fachliche Genehmigung.

Ausnahmen brauchen ein Ende

Vertretungen, Projekte und Störungsbehebungen machen Zusatzrechte manchmal notwendig. Problematisch wird nicht die Ausnahme an sich, sondern ihre unbefristete Vererbung.

Jede Ausnahme sollte deshalb enthalten:

• einen konkreten Zweck,
• die zusätzlich gewährten Rechte,
• eine fachliche Genehmigung,
• bekannte Funktionstrennungs-Konflikte,
• eine geeignete Zusatzkontrolle,
• einen Beginn und ein Ablaufdatum,
• einen Owner für Verlängerung oder Entzug.

Eine automatische Befristung ist hilfreich, sofern der Prozess rechtzeitig über das Ende informiert und eine begründete Verlängerung ermöglicht. Sonst entsteht lediglich ein neuer Zeitdruck zur pauschalen Freigabe.

Eintritt, Wechsel und Austritt bilden einen Prozess

Der Eintritt erhält viel Aufmerksamkeit, der interne Rollenwechsel oft deutlich weniger. Gerade dort sammeln sich Rechte: Die neue Rolle kommt hinzu, während alte Zuweisungen bestehen bleiben.

Für jede organisatorische Änderung sollten daher drei Aktionen gemeinsam ausgelöst werden:

1. benötigte neue Geschäftsrollen bestimmen,
2. nicht mehr begründete Rollen entziehen,
3. Konflikte der verbleibenden Gesamtkombination prüfen.

Beim Austritt sind neben dem Konto auch technische Identitäten, Vertreterzuordnungen, offene Freigaben und persönliche Integrationen zu berücksichtigen. Die führende Information über Stellen- und Rollenwechsel stammt in der Regel aus HR und Führung. Das ERP oder IAM kann den Ablauf unterstützen, die fachliche Entscheidung aber nicht selbst erfinden.

Der Review muss wirksame Rechte prüfen

Eine Liste genehmigter Rollen kann sauber aussehen, während ihre technische Kombination weitergehende Rechte erzeugt. Ein Review sollte deshalb sowohl die fachliche Zuordnung als auch die tatsächlich wirksamen Berechtigungen betrachten.

Zu prüfen sind:

• Passt die Geschäftsrolle noch zur aktuellen Tätigkeit?
• Werden alle enthaltenen Funktionen weiterhin benötigt?
• Welche Rechte entstehen aus mehreren Rollen gemeinsam?
• Bestehen unzulässige oder akzeptierte Konflikte?
• Sind Ausnahmen und Vertretungen abgelaufen?
• Gibt es ungenutzte, verwaiste oder besonders privilegierte Konten?
• Stimmen Datenumfang und Wertgrenzen noch?
• Wurden auffällige Nutzungen oder Umgehungen sichtbar?

Microsoft Dynamics 365 bietet beispielsweise produktspezifische Funktionen für Funktionstrennung und rollenbasierte Sicherheitsauswertungen. Andere ERP-Produkte bilden Rollen und Konflikte anders ab. Ein vorhandener Report ersetzt in keinem System die fachliche Entscheidung, ob die Kombination zur Aufgabe passt.

Der Nutzen des Reviews zeigt sich nicht an möglichst vielen entzogenen Rechten. Gute Signale sind nachvollziehbar begründete Rollen, weniger ungeklärte Konflikte, rechtzeitig beendete Ausnahmen und kürzere Klärungswege bei Rollenwechseln. Eine reine Zahl von Berechtigungsänderungen kann dagegen Aktivität messen, ohne die Qualität zu zeigen.

Mit einem kritischen Prozess beginnen

Ein vollständiger Neuaufbau aller ERP-Rollen kann das Vorhaben blockieren. Der bessere Einstieg ist ein Prozess mit hoher Wirkung oder erkennbarem Konfliktpotenzial, etwa Kreditorenanlage und Zahlung.

Gehen Sie diesen Prozess rückwärts durch: Aufgaben, Entscheidungen, Datenbereiche und notwendige Trennungen. Bauen Sie daraus wenige verständliche Geschäftsrollen und gleichen Sie diese mit den wirksamen technischen Rechten ab. Dokumentieren Sie unvermeidbare Konflikte samt Kontrolle und Ablaufdatum.

So entsteht ein belastbarer Kern, der schrittweise erweitert werden kann. Der entscheidende Wechsel lautet: Rechte werden nicht mehr von Personen geerbt, sondern aus verantworteten Aufgaben begründet.