Der Change ist bereit, die Ingenieure haben ein Wartungsfenster und alles, was fehlt, ist die Freigabe für die Ausfallzeit. Aber wer sollte unterschreiben? Der ursprüngliche Service Owner ist in eine andere Abteilung gewechselt, sein Nachfolger weiß nicht, dass er die Rolle geerbt hat, und der Teamleiter sagt, es sei nicht seine Entscheidung. Die Anfrage reist von Posteingang zu Posteingang und das Fenster läuft ab.
Das gleiche passiert mit Incidents, Requests und Audits. Ein Auditor fragt, wer eine bestimmte Intervention genehmigt hat, und die Antwort wird aus alten E-Mail-Threads herausgesucht. Für das Betriebspersonal bedeutet dies sinnloses Warten und das Gefühl, eine Verantwortung zu tragen, die niemand formal delegiert hat. Für Service Owner bedeutet es das Risiko, erst nachträglich von Arbeiten an ihrem Service zu erfahren.
Warum Verantwortlichkeit verwischt
Die meisten Organisationen haben ein Dokument, das beschreibt, wer für was verantwortlich ist. Das Problem ist, dass es getrennt von dem Tool lebt, in dem die Arbeit tatsächlich stattfindet.
- Eine RACI-Matrix in einer Tabellenkalkulation wird nicht in Berechtigungen reflektiert. Die Person, die als "verantwortlich" markiert ist, kann oft nichts im System genehmigen, und umgekehrt.
- Die Eigentümerschaft ist mehrdeutig. Manchmal wird der Owner auf dem Service, manchmal auf der Anwendung, manchmal auf dem Team aufgezeichnet, und jeder Prozess wählt einen anderen.
- Es gibt keinen Ausweich-Approver. Wenn ein Owner abwesend oder nicht zugewiesen ist, stoppt der Prozess.
- Berechtigungen sind zu grob. Personen sehen entweder alles oder nichts, daher werden Rollen breiter gewährt "nur für den Fall".
Eine bessere Art, Eigentümerschaft zu denken
Verantwortlichkeit ist nur nützlich, wenn das System davon weiß und sie durchsetzt. Wir schlagen einige Prinzipien vor:
- Eine Eigentümerschaftsregel für jeden Prozess. Die Genehmigung einer Ausfallzeit, einer Anfrage oder eines Preislisten-Vorschlags sollte der gleichen Logik folgen.
- Es gibt immer einen Ausweich-Entscheidungsträger. Wenn kein Owner zugewiesen ist, ist im Voraus klar, wer entscheidet.
- Rollen haben Umfang. Eine Berechtigung gilt für einen bestimmten Kunden, ein Team oder ein bestimmtes Element, nicht für das gesamte System.
- RACI und Berechtigungen müssen übereinstimmen. Wer für etwas verantwortlich ist, benötigt die Rechte, um darauf zuzugreifen, und niemand sonst sollte sie haben.
- Jede Entscheidung ist nachvollziehbar. Wer, wann und warum.
Wie Eywo Stratum es handhabt
In Eywo Stratum hat jeder Service einen Owner und eine Regel bestimmt, wer der Owner ist. Die gleiche Regel gilt für jeden Prozess, der eine Zustimmung benötigt: Ausfallzeiten bei Changes, Requests, Patch-Vereinbarungen und Preislisten-Vorschläge. All diese landen in einer einzigen "Warten auf Genehmigung"-Queue. Wenn ein Service keinen Owner hat, entscheidet der Change-Manager als Ausweich-Approver, damit nichts stecken bleibt. Eine Ablehnung kommt immer mit einem Grund.
Berechtigungen sind auf 14 Rollen mit Umfang aufgebaut: alles, ein Kunde, ein Team oder ein bestimmtes Element. Personen erhalten genau die Rechte, die ihre Rolle erfordert. Stratum enthält auch eine RACI-Matrix mit einer Konsistenzprüfung gegenüber Berechtigungen. Sie markiert jeden, der in der Matrix als verantwortlich aufgeführt ist, aber die entsprechende Rolle im System fehlt, und umgekehrt.
Jede Entscheidung wird in einem Audit-Trail geschrieben, der fünf Jahre aufbewahrt wird. Wenn ein Auditor fragt, wer etwas genehmigt hat, dauert die Antwort nur Sekunden, nicht Tage. Während der Einführung überprüft die operationale Bereitschaftsprüfung unter anderem, dass Services zugewiesene Owner haben und dass Rollen vorhanden sind.
Fazit
Klare Eigentümerschaft ist keine Bürokratie. Sie schützt Menschen. Ingenieure wissen, wen sie fragen müssen. Service Owner wissen, dass nichts ohne ihr Wissen mit ihrem Service passiert. Und die Organisation kann jederzeit zeigen, wer für was verantwortlich war. Alles, was es braucht, ist, dass Verantwortlichkeit innerhalb des Systems lebt und nicht in einer Tabellenkalkulation neben ihm.
Service-Eigentümerschaft, Rollen mit Umfang, die RACI-Konsistenzprüfung und der Audit-Trail sind alle Teil der Standard-Edition.
Eywo Stratum Standard
Für Organisationen, die eine zuverlässige CMDB und verwaltete ITSM-Prozesse wünschen.