SLA im Facility Management: Was es ist und warum man es braucht

Fragen Sie einen Facility Manager und einen Dienstleister, was "schnell" bedeutet, und Sie bekommen zwei unterschiedliche Antworten — genau diese Art von Uneinigkeit soll ein SLA verhindern. Ein Service Level Agreement macht aus einem vagen Serviceversprechen eine konkrete, messbare Zusage: wie schnell eine Reaktion erfolgen muss, wie schnell eine Behebung erfolgen muss und was passiert, wenn eine der beiden Fristen verpasst wird. Ohne SLA ist "wir schicken so schnell wie möglich jemanden" weder durchsetzbar noch messbar, und niemand kann zur Verantwortung gezogen werden, wenn eine defekte Anlage drei Tage lang unrepariert bleibt. Mit einem SLA ist ein verpasster Notfalleinsatz keine Meinungsverschiedenheit über Erwartungen mehr, sondern eine Zahl gegen ein Ziel, sichtbar für alle Vertragsparteien. In diesem Artikel schauen wir, was ein SLA im Facility Management konkret ist, was es abdecken sollte und wie man Zielwerte setzt, die auch im laufenden Betrieb Bestand haben.

Ein Service Level Agreement (SLA) ist eine definierte, messbare Verpflichtung zwischen einem Facility-Team und einem Dienstleister — intern oder extern —, die festlegt, wie schnell und wie gut eine Aufgabe erledigt wird. Es umfasst typischerweise die Reaktionszeit (wie schnell eine Anfrage bestätigt wird), die Lösungszeit (wie schnell sie behoben wird) und den Qualitätsstandard, den die Arbeit erfüllen muss, sowie die Konsequenz, wenn der Dienstleister eines dieser Ziele verfehlt. Ein SLA ist nicht dasselbe wie ein allgemeines Serviceversprechen — es ist eine konkrete, vertragliche Zahl, die entweder eingehalten wurde oder nicht, und genau das macht sie durchsetzbar.

Ein vollständiges SLA ist mehr als eine einzelne Reaktionszeit-Zahl. Eine sauber definierte Vereinbarung legt typischerweise fest:

• Reaktionszeit: die maximale Zeit zwischen Erfassung einer Anfrage und Bestätigung oder Eintreffen eines Technikers vor Ort, meist nach Dringlichkeit gestaffelt.
• Lösungszeit: die maximale Zeit bis zur tatsächlichen Behebung des Problems, getrennt von und meist länger als die Reaktionszeit.
• Qualitätsstandards: der Zustand, den die erledigte Arbeit erfüllen muss — eine definierte Checkliste oder Abnahmekriterien, nicht nur "erledigt".
• Berichtsanforderungen: wie und wie oft die Leistung gegenüber dem SLA dokumentiert und dem Facility-Team mitgeteilt wird.
• Eskalationsverfahren: was passiert und wer benachrichtigt wird, wenn ein Ziel zu scheitern droht.
• Vertragsstrafen und Abhilfen: die finanzielle oder vertragliche Konsequenz — eine Gutschrift, eine Gebührenreduzierung —, wenn ein Ziel verfehlt wird.

Ohne definiertes SLA bedeuten "schnell" und "gut" genau das, was jede Partei im Streitfall gerade behauptet — und ein Streitfall ist der denkbar schlechteste Moment, um eine Definition zu verhandeln. Ein klares SLA beseitigt diese Unschärfe, bevor sie zum Problem wird: Beide Seiten wissen genau, welche Leistung erwartet wird, und eine verpasste Frist ist eine Tatsache, keine Diskussion. Diese Klarheit schützt auch das Budget — ein Facility-Team, das über die Verlängerung eines Dienstleistervertrags entscheidet, hat einen tatsächlichen Leistungsnachweis zur Hand, statt eines allgemeinen Eindrucks, ob sich das Jahr über "reaktionsschnell" angefühlt hat. Bei Mehrstandort-Betrieben ist ein einheitliches SLA über alle Standorte hinweg das, was einen Leistungsvergleich zwischen Dienstleistern überhaupt erst ermöglicht — statt sich auf Einzelmeinungen zu verlassen.

Die meisten funktionierenden SLAs bauen auf einem kleinen, wiederkehrenden Satz von Kennzahlen auf:

• Reaktionszeit: Zeit von der Ticketerstellung bis zur Bestätigung oder zum Eintreffen, meist in Minuten oder Stunden nach Prioritätsstufe gemessen.
• Lösungszeit: Zeit von der Bestätigung bis zur vollständigen Behebung, getrennt nach Dringlichkeitsstufe erfasst.
• Erstlösungsquote: der Anteil der Probleme, die beim ersten Einsatz gelöst werden, ohne einen Folgeeinsatz für dasselbe Problem.
• Erledigungsquote: der Anteil der planmäßigen vorbeugenden Wartungsaufgaben, die pünktlich erledigt werden — getrennt von reaktiven Reaktionskennzahlen.
• Verfügbarkeit: der Anteil der Zeit, in der eine kritische Anlage (HLK, Aufzüge, Kühltechnik) betriebsbereit statt außer Betrieb ist.
• Kundenzufriedenheit: Rückmeldung der Person, die das Problem gemeldet hat — erfasst Servicequalität, die reine Geschwindigkeitskennzahlen nicht abbilden.

Ein SLA-Ziel, das auf dem Papier beeindruckend aussieht, aber niemand tatsächlich einhalten kann, ist schlimmer als gar kein SLA — es gewöhnt beide Seiten daran, das Dokument als Fiktion statt als geltenden Standard zu behandeln. Realistische Zielwerte beginnen bei historischen Daten: Welche Reaktions- und Lösungszeiten hat die aktuelle Aufstellung tatsächlich erreicht, und wie viel Spielraum gibt es, das zu verschärfen, bevor es angesichts von Anfahrtszeiten, Ersatzteilverfügbarkeit und Dienstleisterkapazität unrealistisch wird. Auch die Kritikalität sollte die Staffelung bestimmen — ein Ausfall der Kühlung im Serverraum und eine flackernde Flurbeleuchtung sollten niemals dasselbe Reaktionszeit-Ziel teilen, und alle Dringlichkeitsstufen in ein einziges pauschales SLA zu packen, ist einer der häufigsten Gründe, warum Ziele verfehlt werden. Zielwerte müssen außerdem die Standortrealität widerspiegeln: Ein SLA, das für ein einzelnes, leicht erreichbares Gebäude geschrieben wurde, hält selten unverändert dem Kontakt mit einem Portfolio aus ländlichen oder schwer zugänglichen Standorten stand.

Die beiden Begriffe werden oft synonym verwendet, erfüllen aber unterschiedliche Zwecke. Die folgende Tabelle zeigt den Unterschied.

Die meisten SLAs, die sich im laufenden Betrieb nicht bewähren, teilen einen von wenigen wiederkehrenden Schwachpunkten:

• Ein pauschales Ziel für jede Anfrageart: einen Rohrbruch und eine quietschende Tür mit demselben Reaktionszeit-Ziel zu behandeln, macht das SLA entweder für Notfälle zu langsam oder für Routinearbeiten unrealistisch schnell.
• Keine definierte Konsequenz bei verpasstem Ziel: ein SLA ohne festgelegte Abhilfe ist ein Vorschlag, keine Vereinbarung — es hat keine Wirkung, wenn die Leistung nachlässt.
• Nur die Reaktionszeit messen: eine schnelle Bestätigung, gefolgt von einer langsamen Behebung, lässt das eigentliche Problem trotzdem ungelöst — Lösungszeit und Qualität brauchen eigene Ziele.
• Zielwerte setzen, die nie gegen historische Daten geprüft wurden: ein aus einer Vorlage oder einem anderen Portfolio kopiertes SLA passt oft nicht zu dem, was am jeweiligen Standort tatsächlich erreichbar ist.
• Kein regelmäßiger Überprüfungszyklus: ein einmal unterschriebenes und nie wieder überprüftes SLA driftet von veränderten Standortbedingungen, Dienstleisterkapazitäten oder Geschäftsprioritäten ab.

Wowworks verfolgt die SLA-Leistung automatisch für jedes Ticket über alle Standorte hinweg — Reaktionszeiten, Lösungszeiten und Erledigungsquoten werden gegen das vereinbarte Ziel erfasst, nicht erst bei der Vertragsverlängerung aus dem Gedächtnis rekonstruiert. Statt sich auf die eigene Darstellung eines Dienstleisters zu verlassen, erhalten beide Seiten dieselben Daten, mit Eskalationshinweisen bevor ein Ziel verfehlt wird. So werden beispielsweise 97% aller Notdiensteinsätze innerhalb von 4 Stunden vor Ort erfolgreich abgeschlossen — ein Wert, der ohne durchgängiges SLA-Tracking kaum belegbar wäre. Für Organisationen, die SLAs über mehrere Dienstleister und Standorte steuern, macht genau diese Struktur aus einem Service Level Agreement mehr als ein Dokument in der Schublade — sie macht daraus einen Standard, der tatsächlich durchgesetzt wird.