Service Owner: eine Adresse für den ganzen Service
Die Rolle steht in keinem aktuellen Rahmenwerk mehr als Pflichtposten, gebraucht wird sie trotzdem, sobald an einem Service mehr als ein Team beteiligt ist.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Ohne benannte Verantwortung endet jede Frage in einer Weiterleitung
Der Test ist einfach. Frag in der eigenen Organisation, wer für einen bestimmten Service verantwortlich ist. Kommt der Name einer Abteilung, ist die Rolle nicht besetzt. Kommt der Name einer Person, die davon selbst überrascht ist, ebenso wenig.
Was fehlt, merkt man nicht am Tagesbetrieb, der läuft meistens. Es fehlt bei den Entscheidungen dazwischen: ob eine Zusage angepasst wird, ob ein Ausbau gerechtfertigt ist, ob eine wiederkehrende Störung endlich beseitigt wird oder ob der Service in dieser Form überhaupt noch gebraucht wird. Diese Fragen haben keine Frist, also bleiben sie liegen.
Der Preis fällt als schleichende Verteuerung an. Services, die niemand hinterfragt, laufen weiter, weil das Abschalten Arbeit macht und niemand entscheiden darf. Der Aufwand steckt dann in Systemen, deren Nutzen niemand mehr benennen kann.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Der Aufbau im Detail
Der Aufbau
Service Owner = Ergebnisverantwortung + Mandat + Zugriff auf Kennzahlen + Schnittstelle zur Fachseite + Mitsprache bei Änderungen + Eskalationsadresse - 01 Der Kern
ErgebnisverantwortungDie Zusage, dass dieser Service den vereinbarten Nutzen liefert. Verteilt auf mehrere Personen verschwindet diese Verantwortung, statt sich zu halbieren.
- 02 Sichtbar getragen
MandatDie Rolle wirkt über Abteilungsgrenzen hinweg, ohne Weisungsrecht zu haben. Ohne erkennbare Rückendeckung der Leitung bleibt sie eine Bitte unter vielen.
- 03 Eigene Zahlen
Zugriff auf KennzahlenKosten, Ticketaufkommen, Zusagen und ihre Einhaltung. Wer die Zahlen erst erfragen muss, erfährt sie zu spät und in bereits gefilterter Form.
- 04 Eine feste Adresse
Schnittstelle zur FachseiteEin regelmäßiger Termin mit den fachlich Verantwortlichen, in dem Bedarf, Beschwerden und Weiterentwicklung besprochen werden, statt alles über Tickets zu verhandeln.
- 05 Vor der Freigabe
Mitsprache bei ÄnderungenÄnderungen mit erheblicher Auswirkung auf den Service werden nicht ohne die Person entschieden, die für das Ergebnis geradesteht.
- 06 Im Ernstfall
EskalationsadresseBei schweren Störungen übernimmt der Service Owner die Kommunikation zur Fachseite und hält damit der technischen Arbeit den Rücken frei.
Wenn es nicht funktioniert
Das siehst du
Der Service Owner erfährt von einer Änderung an seinem Service erst aus dem Störungsticket danach.
Warum
Die Rolle ist nirgends mit den betroffenen Configuration Items verknüpft, also taucht sie in keiner Bewertung auf.
Was hilft
Den Service Owner am Configuration Item hinterlegen und ihn bei Änderungen mit Auswirkung auf diesen Service automatisch einbeziehen.
Das siehst du
Zwei Personen halten sich für zuständig, entschieden wird trotzdem nichts.
Warum
Der Service wurde nach technischen Grenzen geschnitten, die Fachseite sieht dagegen einen einzigen Geschäftsvorgang.
Was hilft
Den Servicezuschnitt an dem ausrichten, was die Fachseite bestellt, und die technischen Bestandteile darunter hängen.
Das siehst du
Die Rolle steht im Organigramm, aber niemand ruft dort an.
Warum
Es gibt keinen eigenen Termin mit der Fachseite, also läuft weiterhin alles über den Service Desk.
Was hilft
Einen festen Turnus mit den fachlich Verantwortlichen einrichten und diesen Weg für Bedarf und Beschwerden bekannt machen.
Das siehst du
Der Service Owner sitzt in jedem Störungscall und kommt zu nichts anderem.
Warum
Die Rolle wurde mit der technischen Koordination im Ausfall vermischt.
Was hilft
Für schwere Störungen eine eigene technische Leitung benennen und dem Service Owner ausdrücklich die Kommunikation nach außen zuweisen.
Das siehst du
Niemand kann sagen, was der Service eigentlich kostet.
Warum
Die Kosten liegen in Infrastruktur- und Personalbudgets, die nicht nach Services geschnitten sind.
Was hilft
Zumindest die direkt zurechenbaren Kosten je Service ausweisen, auch wenn eine vollständige Verrechnung nicht erreichbar ist.
Sechs Voraussetzungen, die die Rolle tragen
- 01 Ein Servicezuschnitt, den die Fachseite als eine Leistung erkennt.
- 02 Ein Mandat, das die Leitung erkennbar mitträgt.
- 03 Direkter Zugriff auf Kosten, Aufkommen und Zielerreichung.
- 04 Ein fester Termin mit den fachlich Verantwortlichen.
- 05 Eine Einbindung in Änderungen mit erheblicher Auswirkung.
- 06 Eine klare Trennung von der technischen Leitung im Ausfall.
Was du mitnimmst
Du kannst die Rolle so zuschneiden, dass sie in deiner Organisation trägt, und du kennst die Punkte, an denen sie erfahrungsgemäß leerläuft.
Den Service richtig schneiden
Du orientierst den Zuschnitt an dem, was die Fachseite bestellt, und nicht an der technischen Landschaft darunter.
Das Mandat klären
Du legst fest, worüber die Rolle entscheidet und worüber sie nur berät, und machst das für alle beteiligten Bereiche sichtbar.
An die Zahlen kommen
Du sicherst der Rolle direkten Zugriff auf Kosten, Ticketaufkommen und Zielerreichung, statt sie auf Berichte anderer angewiesen zu lassen.
Vom Process Owner trennen
Du unterscheidest die Verantwortung für einen Ablauf über alle Services von der Verantwortung für einen Service über alle Abläufe.
In Änderungen eingebunden sein
Du verknüpfst die Rolle mit den Configuration Items des Service, damit sie bei Bewertungen von selbst auftaucht.
Die Rolle entlasten
Du legst die technische Koordination im Ausfall in andere Hände, damit der Service Owner die Kommunikation übernehmen kann.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Die Verantwortung reicht weiter als die Weisungsbefugnis
Ein Service läuft selten in einer Abteilung. Der Betrieb sitzt an einer Stelle, die Anwendungsbetreuung an einer zweiten, ein Teil beim Lieferanten, und die Fachseite bestellt bei einer vierten. Der Service Owner ist die Person, die über all das hinweg für das Ergebnis geradesteht, ohne den Beteiligten fachlich vorgesetzt zu sein.
Das funktioniert nur mit zwei Dingen: einem Mandat, das die Leitung erkennbar mitträgt, und Zugriff auf die Zahlen. Wer einen Service verantworten soll, ohne die Kosten, das Ticketaufkommen und die Zielerreichung zu kennen, verwaltet am Ende Beschwerden.
Die Aufgaben, die tatsächlich anfallen
Im Alltag besteht die Rolle aus wenigen wiederkehrenden Tätigkeiten: den Leistungsumfang mit der Fachseite abstimmen und schriftlich halten, die Kennzahlen und vor allem ihre Aussagekraft prüfen, die Weiterentwicklung priorisieren, bei Änderungen mit erheblicher Auswirkung mitentscheiden und bei schweren Störungen die Kommunikation zur Fachseite verantworten.
Nicht dazu gehört die Steuerung des Tagesbetriebs. Wer als Service Owner in jedem Störungscall sitzt, kommt nie zu der Arbeit, für die die Rolle geschaffen wurde. Bei einem schweren Ausfall ist die Aufgabe die Kommunikation nach außen und nicht die technische Koordination, sonst fehlt beides.
Abgrenzung zu Process Owner und Product Owner
Der Process Owner verantwortet einen Ablauf über alle Services hinweg, etwa Change Enablement, und fragt, ob dieser Ablauf funktioniert. Der Service Owner verantwortet einen Service über alle Abläufe hinweg und fragt, ob dieser Service liefert. Die beiden Sichten kreuzen sich, und an dieser Kreuzung entstehen die nützlichen Diskussionen.
Der Product Owner kommt aus der agilen Produktentwicklung und entscheidet über die Reihenfolge der Umsetzung im Team. Wo ein Service im Wesentlichen aus einem Produkt besteht, fallen die beiden Rollen oft zusammen. Wo ein Service aus mehreren Produkten und Zulieferungen besteht, tun sie das nicht, und dann braucht es beide nebeneinander.
Was ITIL 4 daran verändert hat
In der Lifecycle-Welt von ITIL v3 war der Service Owner eine beschriebene Rolle mit festem Aufgabenkatalog. ITIL 4 verzichtet auf solche Kataloge und arbeitet stattdessen mit Kompetenzprofilen, die den Tätigkeiten in den Practices zugeordnet werden. Das ist beweglicher und lässt zugleich eine Lücke, wenn niemand sie bewusst schließt.
Praktisch heißt das: Der Titel steht in keinem Rahmenwerk mehr als Pflichtposten, die Frage dahinter muss trotzdem beantwortet werden. Wer ist ansprechbar, wenn dieser Service nicht liefert? Solange darauf eine Person antwortet und nicht eine Abteilung, ist die Rolle besetzt, ganz gleich wie sie im Organigramm heißt.
Dazu passende Kurse
Wie Verantwortung, Wertströme und Teamzuschnitt in einer Serviceorganisation zusammenhängen, behandelt das Modul Create, Deliver & Support, und wer dort einsteigen will, kann sich zunächst die Kurse für Service-Verantwortliche ansehen .
Wie sicher bist du beim Thema wirklich?
Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.
Wo du genau das übst
Katharina war eine super Dozentin mit sehr viel Wissen. Sie ist auf alle Fragen eingegangen und konnte alle klären.
Ein sehr anspruchsvolles Training welches von einer sehr kompetente Trainerin geleitet wurde.
Alles in allem bin ich sehr zufrieden, da der Trainer sich viel Mühe gegeben hat und alles sehr gut erklären konnte.
Häufige Fragen
Wie viele Services kann eine Person verantworten?
Muss ein Service Owner technisch tief drinstecken?
Was ist der Unterschied zum Service Level Manager?
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem ITIL & PRINCE2-Programm den passenden Kurs für deinen Stand zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.
Die Rolle trägt erst, wenn sie Zahlen, Mandat und einen Termin hat
Wie Verantwortung, Teamzuschnitt und Wertströme in einer Serviceorganisation zusammengehen, behandelt das Modul Create, Deliver and Support.