Zum Inhalt springen

SLA & Service Level

Service Level Agreements richtig vereinbaren

Mit Service Level Agreements definierst du Kennzahlen, Servicezeiten, Überwachung und Berichte für überprüfbare IT Leistungen.

16. März 2025 7 Min. Lesezeit

Service Level Agreements richtig vereinbaren KI-generiert

Ein kritischer Dienst fällt am Montagvormittag aus. Der Anbieter bestätigt den Eingang des Tickets und teilt mit, die Störung werde „zeitnah behoben“. Für dein Fachteam hilft das kaum. Es bleibt offen, wann eine qualifizierte Reaktion erfolgt, wie lange der Dienst ausfallen darf und wer später nachweist, ob die vereinbarte Leistung erreicht wurde. Genau diese Lücken soll ein Service Level Agreement, kurz SLA, schließen.

Ein SLA ist keine Sammlung ambitionierter Qualitätsversprechen. Es ist ein Regelwerk für den Betriebsalltag. Es legt fest, welche Leistung der Anbieter in welcher Zeit, in welchem Umfang und mit welchem Nachweis erbringt. Je klarer diese Regeln formuliert sind, desto weniger Raum bleibt für Streit über Erwartungen.

Das SLA sauber in den Vertrag einordnen

Ein SLA steht selten für sich allein. Es knüpft an den Vertrag für IT Leistungen, die Leistungsbeschreibung und häufig an Regelungen zu Vergütung, Haftung, Datenschutz sowie Laufzeit an. Daher sollte klar erkennbar sein, welche Aufgabe das SLA erfüllt.

Im Vertrag sollte insbesondere stehen:

  • Für welche Dienste, Anwendungen, Schnittstellen oder Betriebsleistungen das SLA gilt
  • Welche Kundengruppen, Standorte oder Mandanten erfasst sind
  • Welche Anlagen bei Widersprüchen Vorrang haben
  • Ab wann die Service Levels gelten, etwa nach produktiver Inbetriebnahme
  • Wie Änderungen an Diensten und Service Levels vereinbart werden
  • Welche Folgen eintreten, wenn Ziele wiederholt verfehlt werden

Vermeide eine pauschale Formulierung wie: „Der Anbieter erbringt Leistungen nach branchenüblichem Standard.“ Ein solcher Standard kann als allgemeine Sorgfaltspflicht sinnvoll sein. Er ersetzt jedoch keine überprüfbaren Ziele für Verfügbarkeit, Reaktion oder Wiederherstellung.

Ebenso wichtig ist die Abgrenzung: Gehört nur der Betrieb einer Anwendung zum SLA oder auch die darunterliegende Infrastruktur? Umfasst es Schnittstellen zu Drittsystemen? Wer ist für Internetzugänge, Endgeräte oder Datenlieferungen zuständig? Ohne diese Zuordnung kann der Anbieter bei einer Störung leicht auf einen nicht erfassten Bereich verweisen.

Kennzahlen wählen, die den Betrieb wirklich steuern

Ein gutes SLA enthält wenige, aber relevante Kennzahlen. Jede Kennzahl braucht eine eindeutige Definition, einen Zeitraum für die Ermittlung, eine Datenquelle und eine Folge bei Nichterreichen.

Diese Kennzahlen kommen in vielen IT Verträgen vor:

KennzahlPräzise RegelungWichtige Klarstellung
VerfügbarkeitAnteil der verfügbaren Zeit innerhalb der vereinbarten ServicezeitWas gilt als Nichtverfügbarkeit, welche Zeiten bleiben unberücksichtigt?
ReaktionszeitZeitraum vom Eingang eines korrekt erfassten Tickets bis zur ersten qualifizierten ReaktionEine automatische Eingangsbestätigung genügt nicht
Zeit bis WiederherstellungZeitraum bis zur erneuten nutzbaren Bereitstellung der betroffenen FunktionWiederherstellung ist nicht zwingend endgültige Fehlerbehebung
Zeit bis FehlerkorrekturZeitraum bis zur nachhaltigen Beseitigung der FehlerursacheFür welchen Schweregrad gilt dieses Ziel?
BearbeitungsquoteAnteil fristgerecht bearbeiteter VorgängeWas bedeutet „bearbeitet“ und wer bestätigt den Status?
DatensicherungRhythmus, Aufbewahrung und Wiederherstellbarkeit von SicherungenDie erfolgreiche Sicherung allein belegt keine Wiederherstellbarkeit

Bei der Verfügbarkeit solltest du die Berechnungsformel direkt aufnehmen. Eine typische Regel lautet sinngemäß: Verfügbarkeit ist die vereinbarte Servicezeit abzüglich nicht verfügbarer Zeit, geteilt durch die vereinbarte Servicezeit, multipliziert mit 100.

Entscheidend sind dabei die Begriffe „Servicezeit“ und „nicht verfügbare Zeit“. Ein Dienst kann technisch erreichbar sein, aber zentrale Funktionen können ausfallen. Definiere daher, ob etwa eine nicht nutzbare Anmeldung, ein Fehler in einer Kernfunktion oder der Ausfall einer Schnittstelle als Nichtverfügbarkeit zählt.

Lege auch fest, welche Zeiten aus der Berechnung herausfallen. Denkbar sind vorab angekündigte Wartungsfenster, Störungen in klar benannten Fremdsystemen oder Fehler, die allein aus deinem Verantwortungsbereich stammen. Solche Ausnahmen sollten eng beschrieben sein. Eine offene Ausnahme für „Umstände außerhalb der Kontrolle des Anbieters“ schafft eher neue Diskussionen als Klarheit.

Servicezeiten und Prioritäten konkret festlegen

Eine Reaktionszeit ohne Servicezeit ist nicht aussagekräftig. „Reaktion innerhalb von vier Stunden“ kann völlig unterschiedlich wirken, je nachdem, ob die Uhr rund um die Uhr läuft oder nur innerhalb eines bestimmten Zeitfensters.

Regle daher mindestens:

  • Tage und Uhrzeiten der Servicebereitschaft
  • Zeitzone, sofern Teams international arbeiten
  • Behandlung von Wochenenden und Feiertagen
  • Zugangswege für Störungsmeldungen, etwa Portal, E Mail oder Telefon
  • Voraussetzungen für ein wirksames Ticket
  • Beginn und Ende der jeweiligen Frist
  • Berechtigte Personen auf Kundenseite
  • Eskalationskontakte auf beiden Seiten

Besonders praxisrelevant ist die Priorisierung. Ein SLA sollte nicht allein mit Prioritäten wie P1 bis P4 arbeiten, wenn deren Bedeutung offenbleibt. Beschreibe stattdessen die Kriterien anhand von Auswirkung und Dringlichkeit.

Ein kritischer Vorfall kann etwa vorliegen, wenn eine zentrale Geschäftsaufgabe für einen erheblichen Nutzerkreis nicht nutzbar ist und kein gangbarer Umweg besteht. Eine niedrigere Priorität liegt nahe, wenn nur einzelne Nutzer betroffen sind oder eine nutzbare Alternative vorhanden ist. Wichtig ist außerdem, wer die Priorität festlegt und unter welchen Bedingungen sie im Verlauf angepasst werden darf.

Die Reaktionszeit sollte eine qualifizierte Handlung verlangen. Dazu kann gehören, dass der Anbieter einen zuständigen Bearbeiter benennt, erste Analyseschritte dokumentiert und den nächsten Statuszeitpunkt mitteilt. Eine automatisch erzeugte Ticketnummer ist keine fachliche Reaktion.

Überwachung und Reporting vor Vertragsende festlegen

Ein Service Level ist nur so gut wie sein Nachweis. Vereinbare daher nicht nur Zielwerte, sondern auch die Methode ihrer Ermittlung. Sonst liegen am Monatsende zwei Auswertungen vor, die zu unterschiedlichen Ergebnissen kommen.

Kläre diese Punkte ausdrücklich:

  • Welches System liefert die Daten, etwa ein Monitoring Werkzeug oder das Ticketsystem
  • Von welchem Ort und gegen welchen Prüfpunkt die Verfügbarkeit überwacht wird
  • In welchem Takt eine Prüfung erfolgt
  • Wie Beginn und Ende einer Störung ermittelt werden
  • Wie parallele Störungen gezählt werden
  • Wie Wartungszeiten in der Auswertung markiert werden
  • Wie lange Rohdaten und Berichte verfügbar bleiben
  • Wer Einwände gegen einen Bericht bis wann erheben kann

Bei einer cloudbasierten Anwendung genügt es nicht immer, nur die Erreichbarkeit einer Startseite zu überwachen. Sinnvoller kann ein Test zentraler Nutzerabläufe sein, etwa Anmeldung, Datenabfrage oder Übermittlung einer Transaktion. Das hängt vom konkreten Dienst ab. Entscheidend ist, dass der Prüfpunkt dem tatsächlichen Geschäftszweck nahekommt.

Der regelmäßige Bericht sollte nicht nur eine Prozentzahl enthalten. Er sollte Vorfälle mit Priorität, Dauer, Ursache, ergriffene Maßnahmen, offene Risiken und wiederkehrende Fehler sichtbar machen. Bei wiederholten Problemen braucht es zudem einen Mechanismus für Ursachenanalyse und einen Maßnahmenplan mit Verantwortlichen.

Schwammformulierungen erkennen und ersetzen

Viele SLA Texte wirken auf den ersten Blick professionell, bleiben aber rechtlich und operativ zu unbestimmt. Prüfe besonders kritisch diese Formulierungen:

SchwammformulierungBessere Richtung
„Der Anbieter stellt eine hohe Verfügbarkeit sicher.“„Der Dienst erreicht innerhalb der vereinbarten Servicezeit die festgelegte Verfügbarkeit nach der beschriebenen Berechnungsformel.“
„Störungen werden zeitnah behoben.“„Für jede Priorität gelten festgelegte Zeiten für qualifizierte Reaktion, Wiederherstellung und Fehlerkorrektur.“
„Wartungen erfolgen bei geringem Betriebsrisiko.“„Planbare Wartungen erfolgen nur im vereinbarten Wartungsfenster und werden innerhalb der vereinbarten Frist angekündigt.“
„Der Anbieter berichtet regelmäßig.“„Der Bericht enthält die benannten Kennzahlen, Vorfälle, Ursachen, Maßnahmen und Abweichungen für den festgelegten Berichtszeitraum.“
„Der Anbieter eskaliert bei Bedarf.“„Bei Überschreitung einer festgelegten Zeit erfolgt die Eskalation an die benannten Rollen auf Anbieter und Kundenseite.“

Achte auf Wörter wie „angemessen“, „üblich“, „unverzüglich“, „bei Bedarf“ oder „nach Möglichkeit“. Sie können im Einzelfall sinnvoll sein, ersetzen aber keine messbare Leistungszusage.

Folgen bei Zielverfehlung sinnvoll regeln

Ein SLA ohne Folge bei wiederholter Verfehlung bleibt oft folgenlos. Häufig werden Gutschriften vereinbart. Dann sollte eindeutig geregelt sein, wie die Gutschrift berechnet wird, auf welche Vergütung sie sich bezieht, wie du sie geltend machst und ob sie je Zeitraum begrenzt ist.

Noch wichtiger ist das Verhältnis zu weiteren Rechten aus dem Vertrag. Prüfe, ob eine Gutschrift weitere Rechte verdrängt oder nur zusätzlich gilt. Bei wiederkehrender Zielverfehlung können außerdem besondere Eskalationen, ein verbindlicher Verbesserungsplan oder ein Recht zur Beendigung relevant sein. Das gehört zu den Haftungs und Leistungsregeln des Gesamtvertrags und sollte nicht isoliert im SLA stehen.

Checkliste für die SLA Prüfung

Vor der Freigabe solltest du diese Fragen mit IT Betrieb, Fachbereich, Einkauf und Rechtsabteilung durchgehen:

  • Sind alle kritischen Dienste und Abhängigkeiten erfasst?
  • Hat jede Kennzahl eine eindeutige Definition und Berechnungsgrundlage?
  • Passen Servicezeiten und Prioritäten zu den Geschäftsanforderungen?
  • Sind Reaktion, Wiederherstellung und Fehlerkorrektur voneinander getrennt?
  • Ist geregelt, welche Ereignisse die Uhr anhalten dürfen?
  • Sind Monitoring, Datenquelle und Berichtsinhalt nachvollziehbar beschrieben?
  • Gibt es klare Eskalationen bei kritischen Vorfällen und wiederholter Zielverfehlung?
  • Passen Gutschriften und weitere Folgen zum wirtschaftlichen Risiko?
  • Ist festgelegt, wie Änderungen am SLA wirksam werden?

Bei uns in München behandeln wir genau solche Vertragsfragen anhand typischer Betriebssituationen und Formulierungen. Passende Seminare und Termine findest du bei uns auf cmt.de.

Ein SLA entfaltet seinen Wert nicht durch möglichst viele Kennzahlen, sondern durch eindeutige Regeln für die wenigen Punkte, die deinen Betrieb tatsächlich schützen. Dieser Beitrag ersetzt keine Prüfung des konkreten Vertrags im Einzelfall.

Nächster Schritt

Passenden Kurs zu SLA & Service Level finden.

Feste Termine, erfahrene Trainer, Präsenz in München und Durchführungsgarantie. Buchen kannst du direkt auf cmt.de.