Service-Level für IT-Betrieb verständlich formulieren

Warum vage Service-Level im IT-Betrieb teuer werden

Viele Serviceanbieter legen den Leistungsumfang – Verfügbarkeit, Fehlerbehebung, Wartung, Support, Schulung, Weiterentwicklung – nicht exakt fest. Die Rechtsanwaltskanzlei Harlander & Partner beschreibt die Folge: Der Anbieter liefere sich damit der teils berechtigten, teils laienhaften und unberechtigten Erwartungshaltung des Kunden aus, die nur allzu oft laute: „Alles, immer, sofort, im Preis inkludiert.“

Fehlen solche Vorgaben, führt das nach derselben Quelle zwangsläufig zu schwankenden, fehleranfälligen und schwerer kalkulierbaren Leistungen – der Anbieter macht sich damit das Leben selbst schwer. Ein Service-Level-Agreement wirkt dem entgegen: Es definiert die zu erbringenden Leistungen exakt und regelt notwendige sowie außerplanmäßige Unterbrechungen samt Folgen. Für beide Vertragsparteien wird die Leistung dadurch planbar.

Ohne Messung bleiben Kapazitätsprobleme unsichtbar. Gut gestaltete SLAs verbessern laut Atlassian Konsistenz, Verantwortlichkeit und Vertrauen der Benutzer und decken Engpässe und Kapazitätslücken auf. Sie sind damit nicht nur ein Kontrollinstrument gegenüber dem Dienstleister, sondern die gemeinsame Planungsgrundlage für Personal, Budget, Priorisierung und Erwartungshaltung.

Was ein Service-Level-Agreement für IT-Services festhält

Für den Serviceanbieter ist ein Service Level Agreement laut Atlassian eine klar formulierte Vereinbarung mit dem Kunden – intern oder extern –, die erbrachte Services, die zu erwartende Reaktionsfähigkeit und die Art der Leistungsmessung festhält. Dazu zählen Verfügbarkeit und Reaktionsfähigkeit des Supports. Ein SLA enthält zeitbasierte Ziele und Regeln, wie schnell Tickets bestätigt, aktualisiert und erledigt werden.

Gängige Beispiele sind eine Serviceverfügbarkeit von 99,9 % oder eine Supportreaktion innerhalb von 24 Stunden (Atlassian). SLAs formalisieren Serviceerwartungen und können zusätzlich die Entschädigung bei Verstößen gegen die Anforderungen definieren.

Harlander & Partner nennen als typische SLA-Inhalte: Zielsetzung; umfasste Leistungen und Ausschlüsse; Vertragsparteien; Rollen und Verantwortlichkeiten; Definition der Servicequalität (Verfügbarkeit, Zuverlässigkeit, Wartbarkeit); Kennzahlen mit Ober- und Untergrenzen; Fehlerklassen; Messmethoden; Reporting; Reaktionszeiten; Wartungsintervalle und Wartungsfenster; außerordentliche Wartung; Support-Typen und Support-Level; Berechtigungen; Kommunikationswege; Ticketsysteme; Sprachen; Öffnungszeiten; Betriebsurlaube; Schulungen; Verrechnung; Laufzeit; Kündigung; Änderungen; Sanktionen; Boni und Streitschlichtung. Als Prüfraster zeigt diese Aufzählung sofort, welche Punkte in der eigenen Vereinbarung fehlen.

Kernelemente eines wirksamen SLA (nach Harlander & Partner)

Leistungen so beschreiben, dass sie im IT-Alltag prüfbar sind

Ein klar definiertes SLA legt fest, wer was bis wann und in welcher Qualität liefert (METRAS). Prüfbar wird eine Leistungsbeschreibung, wenn sie konkret statt vage formuliert ist. METRAS nennt als Beispiel „Kalibrierung der Messgeräte gemäß EN ISO 17025 mit Rückverfolgbarkeit zu nationalen Normalen“ – Tätigkeit, anzuwendendes Regelwerk und Ergebnis in einem Satz. Für den IT-Betrieb heißt das: In jeder Leistungszeile System oder Asset, Tätigkeit, Auslöser, Intervall und das am Ende vorliegende Ergebnis nennen.

Zuerst ist auszuwählen, welche Produkte und Leistungen die kritischen eigenen Tätigkeiten direkt beeinflussen. METRAS nennt Wartungsdienste, Kalibrierdienste, Referenzmaterialien und IT-Support für das Laborinformationssystem (LIMS). Im IT-Betrieb sind das jene Dienste, deren Ausfall oder Verzug Kernprozesse stoppt; sie brauchen eine vollständige Leistungsbeschreibung samt Zeit- und Eskalationsregeln. Unkritische Leistungen kommen mit einer kurzen Beschreibung aus.

Wartung, Störungsbehebung, Bereitstellung und Support sind getrennt zu beschreiben, weil sie unterschiedlichen Logiken folgen. Wartung ist planbar und gehört in definierte Wartungsintervalle und Wartungsfenster samt Regelung für außerordentliche Wartung. Störungsbehebung ist ereignisgetrieben und braucht Reaktions- und Behebungszeiten. Bereitstellung – etwa neuer Arbeitsplätze, Konten oder Zugänge – wird in Arbeitstagen zugesagt. Support braucht Öffnungszeiten, Kanäle, Support-Typen und Berechtigungen. Wartungsintervalle, Wartungsfenster, außerordentliche Wartung, Öffnungszeiten, Support-Typen, Support-Level und Berechtigungen führt Harlander & Partner als SLA-Inhalte an.

Kennzahlen, Reaktions- und Behebungszeiten festlegen

Als Richtwert gilt, zwei bis drei messbare Kennzahlen (KPIs) festzulegen (METRAS). Typische Größen sind Verfügbarkeit, Reaktionszeit und Behebungszeit; Harlander & Partner nennen zusätzlich Ober- und Untergrenzen, Fehlerklassen und Messmethoden als SLA-Inhalte. METRAS veranschaulicht die Form solcher Kennzahlen mit „Messunsicherheit ≤ 0,05 %, Lieferzeit ≤ 10 Arbeitstage“ – also Vergleichsoperator plus konkrete Zahl plus definierte Einheit.

Zeitziele werden nach Dringlichkeit gestaffelt. METRAS nennt als Praxisbeispiel: „Kritische Störung am LIMS: Reaktion ≤ 30 Minuten, Behebung ≤ 4 Stunden“. Eine solche Staffelung setzt voraus, dass im SLA steht, was eine kritische, was eine mittlere und was eine geringe Störung ist – andernfalls wird die Einstufung bei jedem Vorfall neu verhandelt.

Reaktionszeit bezeichnet die erste qualifizierte Rückmeldung im definierten Kanal, Behebungszeit die Wiederherstellung des Service. Werden beide Werte getrennt definiert, kann dieselbe Frist nicht unterschiedlich gelesen werden. Verfügbarkeitszusagen wie 99,9 % (Atlassian) sind nur überprüfbar, wenn zusätzlich der Bezugszeitraum, die Messstelle und die Behandlung geplanter Wartungsfenster festgelegt sind.

Top 3 messbare Kennzahlen für IT-SLA (nach METRAS)

1. Verfügbarkeit — 99,9 % im Monatszeitraum

Eskalation, Ansprechpartner und Kommunikationswege regeln

METRAS sieht als Kernelement eines SLA ein Eskalationsverfahren mit klaren Ansprechpartnern auf beiden Seiten vor – drei Eskalationsstufen mit Kontaktdaten. Harlander & Partner ergänzen Kommunikationswege, Ticketsysteme, Support-Typen und Support-Level sowie Berechtigungen. Genau diese Punkte entscheiden in der Praxis darüber, ob eine Eskalation tatsächlich jemanden erreicht.

Festzuhalten ist, welcher Kanal für welche Meldung gilt – etwa Ticketsystem, Hotline oder definierte Mailadresse – und dass eine Meldung außerhalb des Ticketsystems die Fristen nicht unterbricht oder sie erst auslöst. Ebenso gehört ins Dokument, wer beim Kunden berechtigt ist, eine Eskalation auszulösen, und wer beim Anbieter ab welcher Stufe übernimmt. Sind Support-Level und Berechtigungen definiert, lässt sich eine Eskalation ohne Rückfragen auslösen.

Nachweise und Reporting ohne Papierlawine

Nachweis- und Dokumentationspflichten sind ein eigenes Kernelement: erforderliche Zertifikate, Berichte und Nachweise. METRAS nennt als Beispiel Kalibrierzertifikate mit Angabe der Messunsicherheit und der Rückverfolgbarkeit. Der Umfang ist auf das Nötige zu begrenzen; METRAS empfiehlt ein einfaches SLA-Dokument mit maximal einer bis zwei Seiten pro Lieferant, aufgebaut aus den fünf Kernelementen Leistungsbeschreibung, Kennzahlen, Reaktions- und Behebungszeiten, Eskalationsverfahren sowie Nachweis- und Dokumentationspflichten.

Damit Service-Level nachvollziehbar sind, gehören Messmethoden und Reportingintervalle ausdrücklich ins SLA; Harlander & Partner führen Messmethoden und Reporting in der Liste der SLA-Inhalte. Die Messmethode legt fest, aus welchem System die Zeitstempel stammen, wie Zeiten außerhalb der Öffnungszeiten behandelt werden und wie Verfügbarkeit erhoben wird. Teams können solche SLAs mit visuellen, in Serviceprojekte eingebetteten Timern, Benachrichtigungen und Berichten definieren, verfolgen und automatisieren (Atlassian) – die Zahlen fallen damit im Ticketsystem an und nicht in einer nachträglich erstellten Tabelle.

Formulierungshilfen für klare Service-Level

Aktiv formulieren heißt: Subjekt, Tätigkeit, Zeitbezug und Ergebnis in einen Satz. Statt einer Tätigkeitsumschreibung „Betreuung des Servers“ steht dann, wer den Server bis wann wartet, bis wann eine Störung behebt und welchen Nachweis er danach vorlegt. Das entspricht der Grundanforderung, dass ein SLA festhält, wer was bis wann und in welcher Qualität liefert (METRAS).

Fehlerklassen und Wartungsfenster sind vorab zu definieren, weil sie die Fristen steuern. Harlander & Partner führen in der Liste der SLA-Inhalte: Fehlerklassen, Wartungsintervalle, Wartungsfenster, außerordentliche Wartung, Öffnungszeiten, Betriebsurlaube und Sprachen. Öffnungszeiten, Betriebsurlaube und Fenster an Feiertagen bestimmen, wann Fristen überhaupt laufen und ob sie an unterbrochenen Tagen weiterlaufen oder ruhen.

Ausschlüsse gehören ausdrücklich ins Dokument – Harlander & Partner nennen sie als eigenen SLA-Inhalt. Pauschalversprechen wie „alles, immer, sofort, im Preis inkludiert“ vermeidet, wer je Leistung nennt, was enthalten ist, was nicht und was gesondert verrechnet wird; in der Liste der SLA-Inhalte finden sich dafür Verrechnung, Sanktionen, Boni und Streitschlichtung. Die Abstimmung erfolgt in einem gemeinsamen Gespräch über Erwartungen und Möglichkeiten mit dem Dienstleister bzw. der internen IT (METRAS, Schritt 4 des Vorgehens).

Service-Level lebendig halten

Topdesk nennt als SLA-Best-Practices unter anderem, SLAs an den Unternehmenszielen auszurichten, klare und messbare Ziele zu setzen, flexibel zu bleiben und SLAs zu aktualisieren. Der laufende Abgleich mit den Betriebsabläufen ist auch haftungsrelevant: Eine praxistaugliche, an die betrieblichen Abläufe und die Leistungsfähigkeit des Unternehmens des Serviceanbieters angepasste Ausgestaltung ist nach Harlander & Partner zur Vermeidung von Haftungen notwendig.

Ein fixer Reviewtermin und eine Regel, wer Änderungen schriftlich bestätigt, gehören ins Dokument selbst – Laufzeit, Kündigung und Änderungen sind dort als SLA-Inhalte vorgesehen. Ändern sich Kapazitäten, Systeme oder Zuständigkeiten, wird die betroffene Leistungszeile samt Kennzahl angepasst, nicht das gesamte Dokument neu verhandelt. Ändert sich eine Service-Verfügbarkeits- oder Zeitvorgabe, muss die Messmethode mitgezogen werden, sonst messen Reporting und Vereinbarung nicht mehr dasselbe.