Ein Service Level ohne Messregel ist nur eine Erwartung

„Kritische Störungen werden innerhalb von vier Stunden gelöst.“ Der Satz wirkt eindeutig, bis die erste Abweichung diskutiert wird. Beginnen die vier Stunden mit dem technischen Alarm, dem Nutzeranruf oder der Annahme durch den Dienstleister? Läuft die Zeit nachts weiter? Endet sie mit einem Workaround, mit der technischen Reparatur oder erst mit der Bestätigung des Fachbereichs?

Eine Zielzahl ohne Messregel erzeugt keine Verbindlichkeit. Sie verschiebt die Auseinandersetzung nur vom Vertrags- oder Abstimmungstermin in den späteren Störungsfall.

Ein steuerbares Service Level verbindet eine relevante Leistung mit einer reproduzierbaren Messung und einer vereinbarten Reaktion. Erst wenn alle Beteiligten dasselbe Ereignis aus denselben Daten bewerten, kann ein Ziel steuern statt nur gut zu klingen.

Indikator, Ziel und Vereinbarung trennen

Die Begriffe SLI, SLO und SLA werden häufig vermischt. Für die praktische Arbeit hilft eine einfache Trennung:

• Ein Service Level Indicator (SLI) ist die konkret definierte Messgröße, etwa der Anteil erfolgreicher Anmeldevorgänge innerhalb eines Zeitfensters.
• Ein Service Level Objective (SLO) ist der Zielwert für diesen Indikator.
• Ein Service Level Agreement (SLA) ist die Vereinbarung mit dem Kunden oder Auftraggeber, die Leistung, Zielwerte, Verantwortungen und mögliche Folgen zusammenführt.

Das Google-SRE-Kapitel zu Service Level Objectives betont, dass Messgrößen von dem ausgehen sollten, was Nutzer am Service interessiert, und nicht nur von dem, was leicht messbar ist. Diese Logik gilt auch ohne SRE-Organisation: CPU-Auslastung kann technisch wichtig sein, ist aber noch kein Leistungsversprechen an den Vertrieb oder die Produktion.

Vom Nutzerbedarf rückwärts messen

Vor jeder Kennzahl steht die Frage: Welche nutzbare Eigenschaft soll verlässlich sein?

Bei einem ERP-Service können das beispielsweise sein:

• Mitarbeitende können innerhalb der Servicezeit Aufträge erfassen,
• bestätigte Buchungen gehen nicht verloren,
• ein definierter Monatsabschluss kann fristgerecht durchgeführt werden,
• kritische Störungen erhalten schnell eine qualifizierte Reaktion,
• der Mindestbetrieb wird innerhalb der vereinbarten Zeit wiederhergestellt.

Erst danach wird entschieden, welche technischen und prozessualen Messgrößen diese Erfahrung ausreichend abbilden. Häufig braucht es mehrere Ebenen: Verfügbarkeit, Antwortzeit, erfolgreiche Transaktion, Reaktionszeit des Supports und Zeit bis zur Wiederherstellung.

Eine einzelne Ticketkennzahl kann die Servicequalität nicht vollständig vertreten. Ein Ticket kann schnell geschlossen sein, während der Nutzer weiterhin nicht arbeiten kann. Umgekehrt kann ein Service technisch verfügbar sein, obwohl eine entscheidende Transaktion fehlschlägt.

Jede Zeitmessung braucht Start und Ende

Bei Reaktions- und Wiederherstellungszeiten muss der Messpunkt eindeutig sein.

Mögliche Startpunkte sind:

• erstes fachliches Auftreten der Beeinträchtigung,
• erster technischer Alarm,
• Eingang im vereinbarten Meldekanal,
• vollständige Erfassung der notwendigen Pflichtangaben,
• qualifizierte Annahme durch den zuständigen Support.

Diese Zeitpunkte können weit auseinanderliegen. Welcher davon gilt, hängt vom Leistungsversprechen und vom beeinflussbaren Bereich ab. Ein externer Dienstleister kann nicht zuverlässig ab einem Ereignis messen, von dem er keine Kenntnis erhält. Die interne IT darf deshalb aber nicht so tun, als hätte der Nutzer vorher keinen Ausfall erlebt.

Auch das Ende muss geklärt sein:

• erste Rückmeldung,
• Beginn qualifizierter Bearbeitung,
• verfügbarer Workaround,
• wiederhergestellter Mindestbetrieb,
• vollständige technische Lösung,
• fachliche Bestätigung und Abschluss.

Response Time, Restore Time und endgültige Resolve Time beantworten unterschiedliche Fragen. Sie sollten nicht unter dem allgemeinen Wort „Lösungszeit“ zusammenfallen.

Konstruiertes Beispiel: Gleicher Zielwert, anderes Ereignis

Das folgende Beispiel ist konstruiert.

Ein Unternehmen und sein Dienstleister vereinbaren für eine kritische ERP-Störung eine Wiederherstellung innerhalb von vier Stunden. Ein Nutzer meldet den Ausfall morgens an den internen Service Desk. Dieser prüft zunächst Netzwerk und Arbeitsplatz und eskaliert später an den Dienstleister.

Die interne IT misst ab dem ersten Nutzerhinweis. Der Dienstleister startet seine Uhr mit der formal angenommenen Eskalation. Während einer Rückfrage nach Protokolldaten pausiert er zusätzlich die Messung. Nach der technischen Korrektur wartet die IT noch auf die fachliche Prüfung.

Beide Parteien können mit ihrem jeweiligen Bericht plausibel behaupten, das Ziel eingehalten oder verfehlt zu haben. Nicht die Mathematik ist falsch. Das Messmodell ist unvollständig.

Die Lösung besteht nicht zwingend in einer einzigen gemeinsamen Uhr. Es kann eine Ende-zu-Ende-Kennzahl für die Servicewirkung und zusätzlich eine Lieferantenkennzahl für dessen beeinflussbaren Abschnitt geben. Die Beziehung zwischen beiden muss sichtbar bleiben.

Servicezeit und Kalender verändern den Zielwert

„Vier Stunden“ ist ohne Kalender nicht vollständig. Zu klären sind:

• Gilt das Ziel rund um die Uhr oder nur während einer Servicezeit?
• Wie werden Feiertage und regionale Unterschiede behandelt?
• Was geschieht mit Meldungen kurz vor Ende der Servicezeit?
• Gibt es für kritische Prioritäten eine abweichende Bereitschaft?
• Welche Zeitbasis und Zeitzone verwendet das System?

Ein Ziel von vier Service-Stunden kann bei einer Meldung am Freitagnachmittag bis Montag reichen. Das kann für einen Büroservice angemessen und für eine laufende Produktion untragbar sein. Die Geschäftsanforderung bestimmt den Kalender, nicht die Standardeinstellung des Ticketsystems.

Pausen und Ausnahmen brauchen enge Regeln

Messuhren werden häufig bei „Warten auf Kunde“ oder „Warten auf Dienstleister“ angehalten. Eine unbegrenzte Pause kann jedoch schlechte Bearbeitung unsichtbar machen.

Eine Pausenregel sollte beantworten:

• Welcher konkrete Zustand berechtigt zur Pause?
• Welche Information oder Entscheidung fehlt tatsächlich?
• Wer hat die Anfrage wann an wen gestellt?
• Könnte parallel weitergearbeitet werden?
• Wann wird erinnert oder eskaliert?
• Wie erscheint die Pause im Ende-zu-Ende-Bericht?

Geplante Wartung, höhere Gewalt, angekündigte Änderungen oder nicht unterstützte Komponenten können legitime Ausnahmen sein. Sie müssen eng definiert, nachvollziehbar markiert und separat ausgewertet werden. Eine lange Ausschlussliste macht aus dem Service Level sonst eine Schönwetterkennzahl.

Aggregation kann kritische Einzelfälle verdecken

Ein Monatswert von 99 Prozent sagt nicht, wie die Ausfälle verteilt waren. Ein langer Ausfall zu einem kritischen Zeitpunkt kann geschäftlich schwerer wiegen als mehrere kurze Unterbrechungen außerhalb der Kernzeit.

Neben dem aggregierten Ziel können deshalb sinnvoll sein:

• Anzahl und Dauer einzelner kritischer Ausfälle,
• längste zusammenhängende Unterbrechung,
• Erfüllung je Priorität oder Servicekomponente,
• Nutzer- oder Standortgruppen mit abweichender Erfahrung,
• Wiederholungsstörungen,
• Anteil ungeplanter gegenüber geplanter Nichtverfügbarkeit.

Durchschnittswerte sind besonders vorsichtig zu verwenden. Bei stark verteilten Bearbeitungszeiten können Median und obere Perzentile mehr zeigen als ein Mittelwert. Die Methode muss für die Zielgruppe verständlich bleiben.

Datenquelle und Messverantwortung müssen feststehen

Monitoring, Ticketsystem, Anwendungstelemetrie und Nutzerfeedback können unterschiedliche Ausschnitte zeigen. Ein belastbares Modell dokumentiert:

• führende Datenquelle,
• Zeitstempel und Zeitsynchronisation,
• Erfassungs- und Korrekturregeln,
• Umgang mit fehlenden oder doppelten Ereignissen,
• verantwortliche Rolle für Datenqualität,
• Zugriff auf Rohdaten bei Streitfällen,
• Aufbewahrung und Reproduzierbarkeit des Berichts.

Wenn der Dienstleister allein misst, aufbereitet und bewertet, braucht der Auftraggeber ausreichende Transparenz. Das bedeutet nicht, jede Logzeile zu erhalten. Messdefinition, Ereignisliste und begründete Korrekturen müssen jedoch prüfbar sein.

Die Service-Level-Karte

Eine kompakte Karte kann auch für interne Services verwendet werden.

Feld	Festlegung
Nutzerbedarf	Welche nutzbare Eigenschaft soll verlässlich sein?
Serviceumfang	Nutzer, Standorte, Komponenten und ausgeschlossene Bereiche
Indikator	genaue Messgröße mit Einheit und fachlicher Bedeutung
Ziel	Wert, Zeitraum und gegebenenfalls Prioritätsklasse
Start und Ende	auslösende und abschließende Ereignisse
Servicezeit	Kalender, Zeitzone und Bereitschaft
Pausen und Ausnahmen	zulässige Gründe, Nachweis und Eskalation
Datenquelle	führendes System, Rohdaten und Datenqualitätsowner
Aggregation	Berechnung, Rundung, Mindestmenge und Einzelfallansicht
Verantwortung	Service Owner, Messung, Berichtsempfänger und Entscheider
Reaktion	Analyse, Verbesserungsmaßnahme, Eskalation oder Vertragsfolge

Der Servicekatalog liefert den Leistungszusammenhang. Die Karte konkretisiert, welche Qualität für diese Leistung zählt und wie sie beobachtet wird.

Ein Bericht ohne Entscheidung ist Ablage

FitSM verbindet Service Level Management mit Service Reporting und Review. Ein Bericht sollte deshalb nicht nur Zahlen verteilen, sondern eine Entscheidung vorbereiten:

• Welche Abweichung ist fachlich relevant?
• Handelt es sich um einen Einzelfall, ein Muster oder ein Messproblem?
• Welche Ursache liegt im eigenen Betrieb, beim Lieferanten oder im Service-Design?
• Welche Maßnahme wird priorisiert?
• Muss Ziel, Kapazität, Prozess oder Vertrag angepasst werden?

Ein verfehltes Ziel löst nicht automatisch eine Vertragsstrafe aus. Bei internen Services können Ursachenanalyse, Investitionsentscheidung oder bewusste Risikoakzeptanz sinnvoller sein. Ohne vorher vereinbarte Reaktion bleibt der Zielwert allerdings folgenlos.

Nicht jeder Service braucht einen formalen SLA

Für ein kleines internes Team kann ein dokumentierter SLO mit Service Owner, Messregel und regelmäßigem Review ausreichend sein. Ein juristisch ausformulierter Vertrag zwischen internen Abteilungen erzeugt nicht automatisch bessere Leistung.

Mehr Formalität ist sinnvoll, wenn externe Lieferanten, geschäftskritische Leistungen, Kundenverträge, finanzielle Folgen oder häufige Streitfälle beteiligt sind. Auch dann gilt: Wenige relevante und sauber gemessene Ziele sind wertvoller als ein Katalog von Kennzahlen, den niemand zur Steuerung verwendet.

Ein Service Level wird nicht durch die Zahl verbindlich, sondern durch seine gemeinsame Bedeutung. Wenn Nutzerbedarf, Messweg und Reaktion zusammenpassen, kann die Organisation Leistung verbessern. Fehlt diese Verbindung, bleibt selbst ein präziser Prozentwert nur eine unterschiedlich interpretierte Erwartung.