Serviceziele beginnen beim Ärger der Nutzer

Ein Service kann grüne Kennzahlen zeigen und trotzdem Nutzer frustrieren. Genau dort beginnt die eigentliche Arbeit an guten Servicezielen.

Serviceziele sind Vereinbarungen darüber, welche Qualität ein IT-Service im Alltag liefern soll. Für ITSM-Generalisten geht es dabei nicht nur um Prozentwerte auf einem Dashboard. Entscheidend ist, ob ein Ziel die Erfahrung der Nutzer, die Prioritäten im Betrieb und die Entscheidungen bei Störungen wirklich verbessert. Wenn Nutzer warten, erneut nachfragen oder Workarounds suchen müssen, hilft eine intern schöne Kennzahl nur begrenzt.

In der technischen Praxis tauchen dafür oft drei Begriffe auf. Ein Service Level Indicator, kurz SLI, misst einen konkreten Zustand, etwa erfolgreiche Anfragen, Antwortzeiten oder Fehlerraten. Ein Service Level Objective, kurz SLO, setzt daraus ein internes Ziel, zum Beispiel eine gewünschte Verfügbarkeit oder Reaktionsqualität. Ein Service Level Agreement, kurz SLA, ist dagegen meist eine formale Zusage gegenüber Kunden oder Fachbereichen. Der Unterschied ist wichtig, weil ein internes Steuerungsziel früher reagieren muss als eine Vertragsverletzung.

Der Nutzer merkt nicht den Durchschnitt

Ein Durchschnittswert sieht schnell sauber aus. Er kann aber genau die Momente verdecken, in denen ein Service seine Wirkung verliert. Eine Anwendung kann im Monatsmittel verfügbar sein und trotzdem jeden Morgen beim Start der Arbeit hängen. Ein Portal kann technisch erreichbar bleiben, während einzelne Nutzergruppen keinen Antrag abschicken können. Ein Ticketsystem kann die Zielzeit im Mittel schaffen, obwohl kritische Rückfragen zu lange ungeklärt bleiben.

Darum sollten Serviceziele dort beginnen, wo Ärger entsteht. Welche Wartezeit wird im Alltag störend? Welche Fehlersituation blockiert Arbeit statt nur lästig zu sein? Welche Nutzergruppe ist besonders kritisch, weil sie Kundenkontakt, Produktion, Sicherheit oder Fristen betrifft? Solche Fragen übersetzen Messwerte in Servicewirkung.

Google beschreibt Service Level Objectives im SRE-Kontext als zentrales Mittel, um Zuverlässigkeit bewusst zu steuern. Das SRE Workbook zeigt, dass gute Ziele aus Nutzerwegen und messbaren Erwartungen abgeleitet werden sollten. Atlassian trennt SLA, SLO und SLI ähnlich nach Vertrag, internem Ziel und Messgröße. Für ITSM ist daraus vor allem eine praktische Lehre wichtig: Der Messpunkt muss zum Nutzererlebnis passen, nicht nur zum einfachsten technischen Zähler.

Ein Ziel ohne Handlung ist nur Berichtswesen

Ein gutes Serviceziel beantwortet nicht nur, ob etwas gut oder schlecht aussieht. Es sagt auch, was danach passiert. Wenn ein Serviceziel unterschritten wird, muss klar sein, wer prüft, welche Ursache zuerst betrachtet wird, welche Änderung gestoppt werden kann und wann eine Kommunikation an Service Desk oder Fachbereich nötig ist.

Fehlt diese Verbindung, entstehen schöne Monatsberichte ohne operative Wirkung. Teams sehen zwar, dass ein Ziel gerissen wurde, aber niemand ändert Prioritäten, Kapazitäten oder Abläufe. Der Betrieb lernt dann zu spät. Ein SLO sollte deshalb einen Entscheidungsweg auslösen. Bei drohender Zielverletzung kann ein Team zum Beispiel neue Funktionen bremsen, technische Schulden priorisieren, einen Lieferanten einbinden oder eine stabilisierende Änderung vorziehen.

Das ist kein reines Spezialistenthema. ITSM-Verantwortliche können genau hier vermitteln. Sie verbinden technische Messung mit Service Ownern, Change Management, Incident Management, Problem Management und Kommunikation. Ein Serviceziel wird erst dann nützlich, wenn diese Rollen wissen, was es für ihren Alltag bedeutet.

Nicht jeder Service braucht dasselbe Ziel

Gleiche Kennzahlen für alle Services wirken einfach, führen aber oft in die falsche Richtung. Ein internes Archiv, ein Kundenportal, eine Produktionsschnittstelle und ein Identitätsdienst haben unterschiedliche Folgen, sobald sie ausfallen oder langsam werden. Wer überall denselben Prozentwert verlangt, übersieht kritische Unterschiede und verteilt Aufmerksamkeit schlecht.

Besser ist eine kurze Serviceklassifizierung. Welche Nutzer sind betroffen? Wann wird aus einer Störung ein Geschäftsproblem? Gibt es manuelle Ausweichwege? Wie schnell muss der Service nach einem Fehler wieder belastbar sein? Welche Daten oder Sicherheitsrisiken hängen daran? Aus diesen Fragen entstehen passende Ziele. Ein Identitätsdienst braucht vielleicht besonders strenge Wiederherstellung und klare Alarmierung. Ein internes Berichtssystem braucht eher transparente Zeitfenster und klare Kommunikation.

Auch die Messperiode zählt. Ein Monatsziel kann für Managementberichte genügen, aber für Betriebssteuerung zu träge sein. Wenn ein kritischer Dienst am Montagmorgen ausfällt, hilft die Erkenntnis am Monatsende kaum. Darum brauchen manche Services kurze Warnschwellen, Trendprüfungen oder Tagesfenster, während andere mit längeren Betrachtungen auskommen.

Service Desk und Fachbereich brauchen dieselbe Sprache

Serviceziele bleiben schwach, wenn nur Plattformteams sie verstehen. Der Service Desk braucht eine einfache Übersetzung: Was ist normal, was ist kritisch, welche Nutzerwirkung ist bekannt und welche Aussage darf nach außen gegeben werden? Fachbereiche brauchen ebenfalls Orientierung. Sie müssen verstehen, ob ein Ziel echte Servicequalität beschreibt oder nur eine technische Teilansicht.

Hilfreich ist eine kurze Zielkarte pro wichtigem Service. Darauf stehen der Nutzerweg, die Messgröße, das Ziel, die Warnschwelle, der Besitzer, die erste Maßnahme und die Kommunikationsregel. Diese Karte muss nicht bürokratisch sein. Sie soll unter Druck helfen. Wenn eine Kennzahl kippt, muss niemand erst fragen, ob das nur ein Diagrammproblem oder ein Servicerisiko ist.

Die gleiche Sprache verhindert auch falsche Erwartungen. Ein SLA mag erst bei einer bestimmten Schwelle verletzt sein. Der Betrieb sollte aber früher reagieren, sobald die Nutzererfahrung erkennbar schlechter wird. Genau dafür sind interne Serviceziele wertvoll. Sie schützen vor dem Reflex, erst bei formaler Vertragsverletzung aktiv zu werden.

Fehlerbudgets machen Prioritäten sichtbar

Ein nützlicher Ansatz aus der SRE-Welt ist das Fehlerbudget. Vereinfacht bedeutet es: Ein Service darf in einem definierten Rahmen Fehler oder Ausfälle haben, ohne dass das Ziel verletzt wird. Wird dieser Rahmen zu schnell verbraucht, zeigt das eine klare Prioritätsfrage. Soll das Team weiter neue Funktionen liefern oder zuerst Stabilität verbessern?

Für ITSM kann dieses Denken sehr praktisch sein. Es schafft eine gemeinsame Entscheidungsgrundlage zwischen Entwicklung, Betrieb und Management. Nicht jede kleine Störung löst sofort einen Großalarm aus. Aber wiederholte Belastung wird sichtbar, bevor sie sich in Beschwerden, Eskalationen oder Vertragsproblemen niederschlägt.

Wichtig ist, Fehlerbudgets nicht als Freibrief zu missverstehen. Sie sind kein Argument, Nutzerprobleme auszuhalten. Sie sind ein Frühwarnsystem für Prioritäten. Wenn ein Budget schmilzt, braucht der Service eine ehrliche Diskussion über Ursachen, Risiken und nächste Arbeit.

Der Einstieg gelingt klein

Ein guter Start braucht keine perfekte Messplattform. Ein Team kann mit einem kritischen Service beginnen und drei Fragen stellen. Welcher Nutzerweg entscheidet über den Wert des Service? Welche Messgröße kommt diesem Nutzerweg am nächsten? Welche Handlung folgt, wenn die Warnschwelle erreicht wird?

Danach wird das Ziel mit echten Störungen und Tickets verglichen. Passt die Kennzahl zu dem Ärger, den Nutzer melden? Erkennt sie Probleme früh genug? Führt sie zu einer besseren Entscheidung? Wenn nicht, wird sie angepasst. Genau darin liegt der Unterschied zwischen Kennzahlenpflege und Serviceverbesserung.

Serviceziele sind also kein Selbstzweck. Sie sollen den Betrieb vom Bericht zur Entscheidung bringen. Wer beim Ärger der Nutzer beginnt, findet schneller die Messpunkte, die wirklich zählen. Dann werden Zahlen nicht nur gesammelt, sondern zu einem Werkzeug für bessere Prioritäten, klarere Kommunikation und zuverlässigere Services.

Quellen und Einordnung: Google SRE Book zu Service Level Objectives, Google SRE Workbook zur Umsetzung von SLOs, Atlassian zu SLA, SLO und SLI, IBM Übersicht zu IT Service Management. Stand der Quellenprüfung 23.06.2026. Der Beitrag enthält keine Preise, Gebühren oder Leistungssätze.