Verantwortlichkeiten als Voraussetzung für skalierbaren IT-Betrieb

Eine Rolle kann im Organigramm stehen und trotzdem wirkungslos bleiben. Stellen Sie sich ein Unternehmen vor, das einen „Change Owner“ benannt hat. Ein riskantes Firewall-Update wartet seit Wochen auf die Produktivfreigabe. Der Administrator könnte es technisch einspielen. Der Change Owner fühlt sich verantwortlich. Aber niemand hat ausdrücklich festgelegt, wer das verbindliche Ja für die Produktion geben darf.

Dieses Beispiel ist konstruiert. Es beschreibt jedoch eine typische Organisationslücke: verantwortlich, aber nicht befugt. Das Gegenstück ist ebenso riskant: Eine Person besitzt die technische Berechtigung, obwohl sie die Entscheidung organisatorisch gar nicht treffen darf.

Der pragmatische ITSM-Einstieg für den Mittelstand benötigt deshalb mehr als Rollennamen. Verantwortung wird erst belastbar, wenn ein erwartetes Ergebnis, das dazugehörige Entscheidungsrecht, die technische Berechtigung und ein Eskalationsweg zusammenpassen.

Fünf Begriffe, die im Alltag auseinanderfallen

Aufgabe, Rolle, Verantwortung, Entscheidungsrecht und Berechtigung werden häufig so verwendet, als bezeichneten sie dasselbe. Für den Betrieb ist diese Unschärfe teuer, weil sie genau an kritischen Übergaben sichtbar wird.

Begriff	Praktische Bedeutung	Beispiel
Aufgabe	Eine konkrete Tätigkeit	VPN einrichten
Rolle	Ein Bündel von Aufgaben und Erwartungen	Netzwerkadministrator
Verantwortung	Für ein vereinbartes Ergebnis einstehen	Der VPN-Zugang funktioniert verlässlich
Entscheidungsrecht	Eine verbindliche fachliche oder betriebliche Entscheidung treffen dürfen	Den Zugang freigeben
Technische Berechtigung	Den für die Ausführung erforderlichen Systemzugriff besitzen	Das VPN-Konto im System anlegen

Diese fünf Ebenen müssen nicht bei derselben Person liegen. Häufig sollen sie es sogar bewusst nicht. Wer einen privilegierten Zugang technisch einrichten kann, muss ihn nicht gleichzeitig fachlich genehmigen dürfen. Wer die Freigabe erteilt, benötigt umgekehrt nicht zwingend administrative Rechte im Zielsystem.

Der entscheidende Prüfpunkt lautet daher nicht: „Haben wir eine Rolle dafür?“ Er lautet: Wer muss welches Ergebnis liefern, wer entscheidet verbindlich und wer darf die Entscheidung technisch umsetzen?

Verantwortung ohne Entscheidungsrecht erzeugt Wartezeit

Eine Person für ein Ergebnis verantwortlich zu nennen, ohne ihr das notwendige Entscheidungsrecht zu geben, schafft keine Sicherheit. Es schafft eine Warteschlange außerhalb des sichtbaren Prozesses. Der benannte Verantwortliche fragt bei einer anderen Stelle nach, diese erwartet eine Vorlage oder eine weitere Freigabe, und am Ende wartet jeder auf jeden.

Das fällt in klassischen Ticketkennzahlen häufig nicht auf. Ein Ticket kann pausiert, einem Sammelstatus zugeordnet oder gar nicht erst angelegt worden sein. Die operative Bearbeitungszeit sieht dann kurz aus, obwohl die geschäftlich relevante Entscheidung seit Tagen oder Wochen fehlt.

Deshalb gehört zu jeder wesentlichen Verantwortung mindestens:

• das erwartete Ergebnis,
• die Entscheidung, die dafür getroffen werden muss,
• der erlaubte Entscheidungsrahmen,
• eine Vertretung,
• der Eskalationsweg,
• und die Form, in der die Entscheidung nachvollziehbar bleibt.

Das ist keine Forderung nach einem Gremium für jeden Handgriff. Je geringer Risiko und Auswirkung, desto einfacher darf die Regel sein. Eine vorab genehmigte Standardänderung braucht einen anderen Weg als ein Eingriff in die zentrale Firewall.

Sechs Entscheidungen sollten nicht auf Zuruf fallen

Welche Rolle eine Entscheidung übernimmt, hängt von Aufbau, Größe und Risikoprofil des Unternehmens ab. Die folgenden Entscheidungsfelder sollten aus meiner Sicht jedoch ausdrücklich zugeordnet sein:

Entscheidungsfeld	Zu klärende Frage
Produktivfreigabe von Changes	Wer sagt bei welcher Risiko- und Auswirkungsklasse final Ja?
Priorisierung	Wer entscheidet bei konkurrierenden Störungen, Betriebsaufgaben und Projekten?
Berechtigungen	Wer genehmigt Vergabe und Entzug, insbesondere bei privilegierten Rechten?
Beschaffung und Budget	Wer darf innerhalb welcher Grenze beauftragen oder freigeben?
Eskalation und Ausnahme	Wer entscheidet im Notfall, und wie wird die Ausnahme nachträglich geprüft?
Dienstleistersteuerung	Wer darf anweisen, wer prüft das Ergebnis und wer nimmt die Leistung ab?

Die Liste ist kein vollständiges Governance-Modell. Sie setzt dort an, wo fehlende Entscheidungen schnell zu Betriebsrisiko, unnötiger Wartezeit oder unklaren Kosten führen.

Wichtig ist außerdem die Trennung zwischen Anstoß, Bewertung und Autorisierung. Ein Nutzer darf einen Change wünschen. Ein Administrator kann technische Machbarkeit und Risiko bewerten. Daraus folgt noch nicht, dass einer von beiden die Produktivfreigabe erteilen darf. Der Beitrag „Ein Ticketsystem löst keine organisatorischen Probleme“ zeigt, warum ein Werkzeug diese Trennung nur abbilden, aber nicht selbst festlegen kann.

Stellenbeschreibung, Prozess und Berechtigung müssen zusammenpassen

In dem von mir empfohlenen Organisationsmodell beschreibt HR Stellen und Rollen einschließlich der vorgesehenen Tätigkeiten. Der Process Owner legt fest, wie ein Prozess funktioniert und welche Entscheidungen darin notwendig sind. Service Owner beziehungsweise IT-Leitung verantworten den betrieblichen Rahmen und das Leistungsversprechen. Die technische Administration setzt die vereinbarten Rechte im System um.

Das ist kein allgemeingültiges Organigramm. Unternehmen können diese Aufgaben anders verteilen. Entscheidend ist, dass die Perspektiven zusammengeführt werden und nicht jede Stelle isoliert ihre eigene Wahrheit pflegt.

Bei einem Konflikt zwischen veralteter Stellenbeschreibung, aktuellem Prozessbedarf und technisch möglichem Zugriff sollte aus meiner Sicht der Process Owner, der Service Owner oder die IT-Leitung innerhalb der jeweiligen Befugnisse entscheiden. Für Systemrechte gilt dabei das Sicherheitsprinzip Least Privilege: Eine Person oder ein Prozess erhält nur die Ressourcen und Autorisierungen, die für die zugewiesene Funktion notwendig sind.

„Der Prozess braucht das“ ist trotzdem keine Erlaubnis, arbeitsvertragliche, mitbestimmungsrechtliche oder andere verbindliche Vorgaben zu umgehen. Wenn eine Stellenbeschreibung nicht mehr zur tatsächlichen Aufgabe passt, muss die Organisation den Widerspruch mit HR und gegebenenfalls den zuständigen Fachstellen auflösen. Die IT sollte weder dauerhaft zu breite Rechte stehen lassen noch eine organisatorische Änderung stillschweigend über das Berechtigungssystem vollziehen.

Die Entscheidung wird dokumentiert. Danach werden Stellen- oder Rollenbeschreibung, Prozessregel und technische Berechtigung wieder in Einklang gebracht. Nur die mündliche Ausnahme zu speichern, verlagert das Problem auf die nächste Prüfung oder Vertretungssituation.

Eine kleine RACI-Matrix reicht für den Einstieg

Für mittelständische IT-Organisationen halte ich eine kleine RACI-Matrix für einen brauchbaren Einstieg. Das Project Management Institute beschreibt RACI als Form der Verantwortungsmatrix mit vier Arten der Beteiligung:

• Responsible: führt die Arbeit aus,
• Accountable: steht für Ergebnis beziehungsweise verbindliche Entscheidung ein,
• Consulted: wird vorab fachlich einbezogen,
• Informed: wird über Entscheidung oder Ergebnis informiert.

Die englischen Begriffe lassen sich im Deutschen leicht missverstehen, weil „responsible“ und „accountable“ häufig beide mit „verantwortlich“ übersetzt werden. In der Matrix muss deshalb ausdrücklich stehen, wer arbeitet und wer die verbindliche Ergebnis- oder Entscheidungsverantwortung trägt.

Ich empfehle für jede wesentliche Entscheidung genau eine accountable Rolle. Das ist eine bewusste Gestaltungsregel für Übersicht, keine Behauptung, dass jedes RACI-Modell weltweit so verwendet werden muss. Mehrere Ausführende und beratende Rollen sind möglich. Mehrere gleichrangig Entscheidungsverantwortliche führen dagegen schnell zurück zur Ausgangsfrage: Wer sagt am Ende Ja oder Nein?

Die Matrix sollte klein beginnen. Tragen Sie nicht jede Routineaufgabe des IT-Betriebs ein, sondern zunächst die sechs kritischen Entscheidungsfelder. Prüfen Sie für jede Zeile:

1. Ist genau eine Rolle entscheidungsverantwortlich?
2. Besitzt diese Rolle die organisatorische Befugnis innerhalb einer klaren Grenze?
3. Ist eine Vertretung geregelt?
4. Können die ausführenden Rollen die Entscheidung technisch umsetzen, ohne selbst ungewollt die Freigabe zu übernehmen?
5. Wissen konsultierte und informierte Stellen, wann sie einbezogen werden?

Rollenbeschreibungen bleiben wichtig. Sie erklären aber häufig besser, wer grundsätzlich was tut, als wer in einer konkreten Konflikt- oder Ausnahmesituation entscheidet. Die Matrix macht diesen Unterschied sichtbar.

Das Entscheidungslog ergänzt, was die Matrix nicht erklären kann

Eine RACI-Matrix zeigt die stabile Zuordnung. Sie dokumentiert nicht, warum in einem strittigen Einzelfall eine bestimmte Entscheidung gefallen ist. Dafür genügt ein knappes Entscheidungslog.

Ein Eintrag sollte nur die Informationen enthalten, die später tatsächlich benötigt werden:

Feld	Inhalt
Entscheidung	Was wurde verbindlich entschieden?
Entscheidungsverantwortung	Welche Rolle hat innerhalb welcher Befugnis entschieden?
Anlass und Risiko	Warum war die Entscheidung notwendig?
Beteiligte	Wer wurde konsultiert oder informiert?
Geltungsdauer	Dauerhafte Regel oder befristete Ausnahme?
Folgeaktion	Welche Dokumentation, Berechtigung oder Prozessregel muss angepasst werden?

Das Log ist kein zweites Ticketsystem und kein Protokoll jeder Kleinigkeit. Es gehört zu Entscheidungen, bei denen später mit vertretbarem Aufwand nachvollziehbar sein muss, wer auf welcher Grundlage entschieden hat. Eine befristete Ausnahme ohne Ablaufdatum oder Folgeaktion ist keine kontrollierte Ausnahme, sondern eine neue informelle Regel.

Matrix und Log erfüllen damit unterschiedliche Zwecke: Die Matrix schafft Übersicht über den Normalfall. Das Log hält die begründete Abweichung oder strittige Entscheidung nachvollziehbar.

Personalunion ist nicht automatisch ein Fehler

In kleineren IT-Organisationen übernimmt eine Person häufig mehrere Rollen. Das ist weder ungewöhnlich noch grundsätzlich schlecht. Eine IT-Leitung kann zugleich Service Owner und Process Owner sein. Ein Administrator kann operative Arbeit und fachliche Koordination verbinden.

Problematisch wird Personalunion, wenn dieselbe Person eine kritische Leistung verspricht, erbringt, freigibt und kontrolliert, obwohl Risiko oder Nachweispflicht eine unabhängige Prüfung erfordern. Das gilt besonders bei privilegierten Berechtigungen und Änderungen mit hoher betrieblicher Auswirkung.

Auch ohne zusätzliche Stelle lassen sich Rollen gedanklich und im Ablauf trennen. Eine Person sollte bei einer Entscheidung erkennbar in einer bestimmten Rolle handeln. Für kritische Vorgänge kann eine zweite vorhandene Rolle prüfen oder freigeben. Wo niemand unabhängig prüfen kann, muss die Geschäftsführung das verbleibende Risiko bewusst akzeptieren oder externe Unterstützung organisieren.

Spätestens bei folgenden Signalen reicht informelle Abstimmung häufig nicht mehr:

• Entscheidungen bleiben wiederholt liegen, weil jeder die andere Person für zuständig hält.
• Der Ausfall einer Schlüsselperson blockiert Freigaben oder den Betrieb.
• Mehr Standorte, Dienstleister oder Schnittstellen müssen koordiniert werden.
• Vertragliche, regulatorische oder Audit-Anforderungen verlangen belastbare Nachweise.
• Das Vier-Augen-Prinzip fehlt bei Entscheidungen mit hohem Risiko.

Die Antwort muss nicht sofort eine neue Vollzeitstelle sein. Sie kann aus klareren Befugnissen, geregelter Vertretung, einer externen Kontrollrolle oder der organisatorischen Trennung einzelner Entscheidungen bestehen.

Regulierung erhöht den Nachweisbedarf – aber nicht pauschal die Stellenzahl

ISO/IEC 27001:2022 beschreibt Anforderungen an ein risikobasiertes Informationssicherheits-Managementsystem und verbindet dabei Menschen, Prozesse und Technik. Die Norm gilt für Organisationen unterschiedlicher Größe und lässt das Managementsystem an Kontext und Risiken anpassen. Daraus folgt nicht automatisch, dass jede Rolle mit einer eigenen Person besetzt werden muss. Wer die Norm anwendet oder sich zertifizieren lässt, muss organisatorische Zuständigkeiten jedoch belastbar in das Managementsystem einordnen können.

Für besonders wichtige und wichtige Einrichtungen im Anwendungsbereich des deutschen BSI-Gesetzes ist die Aussage konkreter. § 30 BSIG verlangt geeignete, verhältnismäßige und wirksame technische und organisatorische Risikomanagementmaßnahmen sowie deren Dokumentation. Nach § 38 BSIG muss die Geschäftsleitung betroffener Einrichtungen diese Maßnahmen umsetzen und ihre Umsetzung überwachen.

Diese Pflichten gelten nicht pauschal für jeden Mittelständler. Ob ein Unternehmen in den Anwendungsbereich fällt, muss anhand des Gesetzes und der konkreten Tätigkeit geprüft werden. Auch dort schreibt die bloße Nennung von NIS-2 nicht für jede betriebliche Entscheidung eine bestimmte RACI-Matrix oder separate Stelle vor. Sie macht aber deutlich, warum Verantwortung nicht in einer allgemeinen Formulierung wie „die IT kümmert sich“ enden darf.

Messen Sie die Wartezeit auf Entscheidungen mit

Geklärte Verantwortung zeigt sich nicht an der Zahl ausgefüllter Rollenbeschreibungen. Sie zeigt sich im Arbeitsfluss:

• weniger Entscheidungen bleiben ohne Eigentümer liegen,
• die Zeit bis zu einer Freigabe sinkt,
• Rückfragen wie „Wer darf das entscheiden?“ werden seltener,
• und Eskalationen entstehen weniger häufig allein aus Zuständigkeitslücken.

Die reine Ticketlösungszeit kann diese Wirkung verdecken. Sie sieht gut aus, wenn ein Vorgang während der Freigabe pausiert wird oder die strittige Entscheidung gar nicht als Ticket erfasst ist. Für kritische Abläufe ist deshalb die gesamte Durchlaufzeit aussagekräftiger: vom erkannten Entscheidungsbedarf über Beratung und Wartezeit bis zur verbindlichen Entscheidung und Umsetzung.

Das bedeutet nicht, jede Minute einer Managemententscheidung zu vermessen. Beginnen Sie mit wenigen wiederkehrenden Entscheidungen und prüfen Sie, wo die tatsächliche Wartezeit entsteht. Wenn technische Umsetzung zwei Stunden dauert, die Freigabe aber zwölf Tage, liegt der Engpass nicht im Administrationsteam.

Beginnen Sie mit einer Entscheidung, nicht mit dem Organigramm

Skalierbare Verantwortung entsteht nicht durch möglichst viele Rollen. Sie entsteht durch wenige, verständliche und handlungsfähige Zuordnungen.

Nehmen Sie eine Entscheidung, die zuletzt unnötig lange gedauert hat. Benennen Sie das erwartete Ergebnis, eine entscheidungsverantwortliche Rolle, ihren Befugnisrahmen, die ausführenden und beratenden Rollen, eine Vertretung und den Eskalationsweg. Prüfen Sie anschließend, ob die technischen Berechtigungen genau zu dieser Vereinbarung passen.

Wenn das für eine Produktivfreigabe funktioniert, übertragen Sie das Muster auf Priorisierung, Berechtigungen, Budget, Ausnahmen und Dienstleistersteuerung. Erst dann lohnt es sich, die Matrix zu erweitern oder im Tool abzubilden.

Eine Rolle auf dem Papier schafft noch keine Verantwortung. Eine Person, die weiß, wofür sie einsteht, verbindlich entscheiden darf und deren Entscheidung umsetzbar sowie nachvollziehbar ist, schon.