Service Review vorbereiten mit Entscheidungen statt KPI-Folien

Ein Service Review soll klären, ob ein IT-Service im Alltag noch hält, was er verspricht. In der Praxis endet der Termin aber oft bei Ampelfarben, Durchschnittswerten und einer Liste offener Tickets. Genau dort entsteht das Problem: Wer nur Kennzahlen zeigt, hat noch keine Entscheidung getroffen.

Service Review vorbereiten heißt deshalb mehr als Folien bauen. Der Termin braucht vorab eine Entscheidungsliste: Welche Abweichung ist nur Rauschen, welche gefährdet den Service, wer besitzt die nächste Maßnahme und welcher Punkt gehört in ein Change-, Problem- oder Verbesserungsboard? Ohne diese Vorbereitung bleibt der Review ein Bericht über die Vergangenheit. Mit Vorbereitung wird er ein Steuerungstermin für den nächsten Betriebsmonat.

ITIL beschreibt Service Management als Zusammenspiel von Practices, Rollen und Wertbeiträgen. Für Generalisten ist daran vor allem eines wichtig: Ein Service ist kein einzelnes Tool, sondern eine Leistung mit Erwartungen, Risiken, Nutzern und Verantwortlichen. Service Level Agreements und Kennzahlen helfen nur, wenn aus ihnen eine konkrete Betriebsentscheidung folgt. Auch Hersteller und ITSM-Anbieter betonen bei SLA- und KPI-Arbeit, dass Messwerte erst mit Ziel, Eskalation und regelmäßiger Auswertung sinnvoll werden.

Der Review beginnt vor dem Termin

Ein guter Service Review startet nicht mit der ersten Folie, sondern mit der Frage, welche Entscheidung der Termin ermöglichen soll. Soll ein Service stabilisiert werden? Muss eine Zusage angepasst werden? Ist ein Anbieterproblem sichtbar? Fehlen Daten aus Monitoring, Service Desk oder CMDB? Oder zeigt der Monat nur normale Schwankungen, die keine Sondermaßnahme rechtfertigen?

Diese Vorarbeit schützt vor einer typischen Falle. Kennzahlen wirken objektiv, obwohl sie ohne Kontext leicht in die Irre führen. Eine durchschnittliche Lösungszeit kann gut aussehen, wenn wenige schwere Störungen durch viele einfache Anfragen verdeckt werden. Eine SLA-Quote kann erfüllt sein, während ein einzelner Standort wiederholt ausfällt. Ein grüner Status kann trotzdem riskant sein, wenn die Werte nur manuell gepflegt wurden oder wenn Ausnahmen nicht sauber dokumentiert sind.

Deshalb gehört in die Vorbereitung eine kurze Vorbewertung. Sie trennt Rohdaten, Beobachtung und Entscheidung. Rohdaten sagen, was gemessen wurde. Die Beobachtung erklärt, was daran auffällt. Die Entscheidung legt fest, ob jemand handeln muss. Erst diese dritte Ebene macht den Review brauchbar.

Welche Daten in die Vorbereitung gehören

Für ITSM-Generalisten reichen meist fünf Datenblöcke. Erstens Service-Level-Werte wie Verfügbarkeit, Antwortzeit, Lösungszeit und vereinbarte Reaktionszeiten. Zweitens Service-Desk-Daten wie Ticketvolumen, Wiedereröffnungen, Eskalationen und Rückfragen. Drittens Störungsdaten mit Major Incidents, wiederholten Ursachen und offenen Problems. Viertens Änderungsdaten, weil fehlgeschlagene oder schlecht übergebene Änderungen häufig die Servicequalität beeinflussen. Fünftens Nutzungs- und Zufriedenheitsdaten, sofern sie belastbar erhoben werden.

Wichtig ist nicht, alle Werte in den Termin zu drücken. Besser ist eine Auswahl nach Entscheidungswert. Ein Wert gehört in den Review, wenn er eine Frage auslöst: Müssen Prioritäten geändert werden? Braucht der Service einen anderen Owner? Ist ein Lieferant einzubeziehen? Muss ein Known Error in eine Maßnahme überführt werden? Reicht ein Hinweis im Betriebshandbuch oder braucht es einen formalen Change?

Der Artikel zur Service Desk KPI Prüfung mit Rohdaten zeigt, warum Durchschnittswerte allein nicht reichen. Für den Review ist diese Logik besonders wichtig, weil dort oft Management, Service Owner und Betrieb gemeinsam auf dieselben Zahlen schauen. Die Gruppe braucht eine gemeinsame Lesart, sonst diskutiert sie Farbe statt Folge.

Die Entscheidungsliste macht den Termin verbindlich

Eine Entscheidungsliste ist kein großes neues Formular. Sie ist eine knappe Tabelle, die jede relevante Beobachtung in eine Folgehandlung übersetzt. Die Spalten lauten: Beobachtung, betroffener Service, Risiko, Entscheidung, Owner, Termin, Nachweis. Damit wird sichtbar, ob ein Punkt nur erwähnt oder wirklich gesteuert wurde.

Beispiel: Die Wiedereröffnungsquote im Service Desk steigt bei einem Fachverfahren. Die reine KPI-Folie sagt nur, dass mehr Tickets zurückkommen. Die Entscheidungsliste fragt weiter. Ist die Wissensdatenbank falsch? Fehlt eine Rückfrage im Anfrageformular? Wird ein Workaround zu früh geschlossen? Braucht es ein Problem Ticket oder eine Änderung am Servicekatalog? Erst danach lässt sich ein Owner benennen.

Diese Struktur hilft auch bei Cloud- und Tool-Themen. Wenn nach Projektende Zugänge offen bleiben, reicht der Hinweis auf eine Abweichung nicht aus. Der Service Review muss entscheiden, wer Rechte prüft, welche Konten entfernt werden und wie Ausnahmen dokumentiert sind. Der Beitrag zu Cloud-Zugängen nach Projektende liefert dafür ein passendes Beispiel aus dem Regelbetrieb.

SLA-Abweichungen brauchen eine Ursache statt Schuldzuweisung

SLA-Abweichungen sind ein besonders heikler Teil des Service Reviews. Sie laden schnell zu Schuldfragen ein. War der Dienstleister zu langsam? Hat der Service Desk falsch priorisiert? Hat der Fachbereich zu spät reagiert? Die bessere Vorbereitung prüft zuerst, welche Art von Abweichung vorliegt.

Drei Fälle sollten getrennt werden. Eine einzelne Ausnahme mit klarer Ursache gehört in die Dokumentation und braucht nur dann eine Maßnahme, wenn der Schaden hoch war. Ein wiederholtes Muster gehört in Problem Management, weil die Ursache offenbar nicht zufällig ist. Eine dauerhaft unrealistische Zusage gehört in das Service-Level-Design, weil der Vertrag oder die Erwartung nicht mehr zum Betrieb passt.

Damit bleibt der Review fair. Er bewertet nicht nur, ob ein Ziel verfehlt wurde, sondern ob die Organisation aus der Abweichung die richtige Konsequenz zieht. Das passt zur Grundidee von IT Service Management: Messung ist kein Selbstzweck, sondern soll Leistung, Risiko und Verbesserung steuerbar machen.

CMDB und Servicekatalog liefern den fehlenden Kontext

Ein Service Review scheitert oft nicht an fehlenden Kennzahlen, sondern an fehlendem Kontext. Wenn nicht klar ist, welche Anwendungen, Standorte, Schnittstellen, Lieferanten oder Nutzergruppen zu einem Service gehören, kann ein roter Wert kaum bewertet werden. Dann bleibt unklar, ob ein Ausfall lokal begrenzt war oder einen geschäftskritischen Prozess betroffen hat.

Die CMDB muss dafür nicht perfekt sein. Sie muss für den Review die wichtigsten Beziehungen liefern: Service, technische Komponenten, Owner, kritische Abhängigkeiten und betroffene Nutzergruppen. Der Beitrag CMDB aufbauen aus IT-Inventar mit Servicefragen erklärt diesen Einstieg aus Betriebssicht. Für Service Reviews bedeutet das: Eine einfache, verlässliche Servicekarte ist wertvoller als eine große, aber ungepflegte Datenbank.

Auch der Servicekatalog spielt hinein. Er beschreibt, was Nutzer erwarten dürfen, welche Varianten es gibt und welche Eingaben für eine Anfrage nötig sind. Wenn im Review regelmäßig Rückfragen, falsche Bestellungen oder unklare Zuständigkeiten auftauchen, ist das ein Hinweis auf Katalogarbeit. Dann sollte die Entscheidungsliste nicht nur ein Ticket an den Betrieb erzeugen, sondern auch eine Verbesserung am Katalogeintrag.

Eine einfache Vorlage für die Vorbereitung

Für den nächsten Service Review reicht ein schlanker Ablauf. Eine Woche vor dem Termin werden die relevanten KPI- und Ticketdaten gezogen. Drei Tage vor dem Termin prüft der Service Owner die auffälligen Abweichungen. Zwei Tage vor dem Termin ergänzt der Betrieb bekannte Ursachen, laufende Changes und offene Problems. Einen Tag vor dem Termin wird die Entscheidungsliste vorbefüllt und an die Teilnehmenden verteilt.

Die eigentliche Besprechung arbeitet dann nicht mehr jede Zahl einzeln ab. Sie startet mit den drei bis fünf wichtigsten Entscheidungen. Danach werden nur die Werte betrachtet, die für diese Entscheidungen nötig sind. Am Ende muss jeder offene Punkt einen Owner, einen Termin und einen Nachweis haben. Ohne diese drei Angaben ist der Review nicht abgeschlossen.

Eine kopierbare Mindestvorlage sieht so aus:

• Service und Zeitraum: Welcher Service wurde betrachtet und welcher Monat zählt?
• Auffälligkeit: Welche Kennzahl, Störung, Anfrage oder Änderung löst die Diskussion aus?
• Auswirkung: Welche Nutzer, Standorte, Prozesse oder Risiken sind betroffen?
• Entscheidung: Beobachten, Problem analysieren, Change planen, Service Level anpassen oder Katalog verbessern?
• Owner und Termin: Wer übernimmt den nächsten Schritt bis wann?
• Nachweis: Wo wird die Entscheidung dokumentiert, etwa Ticket, Problem Record, Change, Review-Protokoll oder Servicekatalog?

Häufige Fragen aus der Praxis

Wie viele Kennzahlen braucht ein Service Review?

So wenige wie möglich und so viele wie nötig. Entscheidend ist, ob die Kennzahl eine Betriebsentscheidung unterstützt. Werte ohne Folgefrage gehören eher in den Anhang als in die Hauptdiskussion.

Wer besitzt die Entscheidungsliste?

Der Service Owner sollte die Liste führen. Betrieb, Service Desk, Provider und Fachbereich liefern Daten und Bewertungen. Die Verantwortung für die Entscheidung darf aber nicht zwischen den Rollen verschwimmen.

Muss jede SLA-Abweichung in ein Problem Ticket?

Nein. Ein einzelner erklärbarer Ausreißer kann dokumentiert werden. Wiederholte Muster, unbekannte Ursachen oder hohe Auswirkungen sprechen dagegen für Problem Management oder eine formale Verbesserungsmaßnahme.

Was ist der häufigste Fehler im Review?

Der häufigste Fehler ist ein Termin ohne Folgehandlung. Ein Review, der nur berichtet, erzeugt Aufwand ohne Steuerungswirkung. Ein Review mit Entscheidungsliste macht sichtbar, welche Änderung im Betrieb wirklich beschlossen wurde.

Fazit für den nächsten Betriebsmonat

Ein Service Review ist dann wertvoll, wenn er den nächsten Betriebsmonat beeinflusst. KPI-Folien zeigen, wo etwas auffällt. Die Entscheidungsliste klärt, was daraus folgt. Wer den Termin so vorbereitet, reduziert Nachfragen, vermeidet Scheintransparenz und macht Servicequalität verhandelbar, ohne in Schuldzuweisungen zu rutschen.

Stand der Quellenprüfung: 27.08.2026.

Quellen: PeopleCert zu ITIL und IT Service Management, Atlassian zu Incident Management KPIs, BMC zu SLA Best Practices, Freshworks zu SLA Management.

Bildquelle: Pexels / Foto-ID 3184339 / https://www.pexels.com/photo/3184339/ / CC0-Lizenz