Ein Operational Level Agreement (OLA) ist eine interne Vereinbarung zwischen zwei oder mehreren Abteilungen oder Teams innerhalb derselben Organisation, die die gegenseitigen Leistungserwartungen und Verantwortlichkeiten festlegt, die erforderlich sind, um die gegenüber externen Kunden zugesagten SLAs einzuhalten. Während ein SLA (Service Level Agreement) das externe Versprechen an den Kunden ist, ist ein OLA das interne Versprechen der beteiligten Teams untereinander.
Ein OLA beantwortet die Frage: Was muss jede interne Einheit leisten, damit das Gesamtsystem die zugesagten Leistungsparameter gegenüber dem Kunden erfüllt? Wenn ein SLA eine Reaktionszeit von 2 Stunden verspricht, dann legt das OLA fest: Die IT-Abteilung stellt die Systemumgebung in 30 Minuten bereit, das Operations-Team eskaliert innerhalb von 15 Minuten, das Entwicklungsteam liefert einen Lösungsvorschlag innerhalb von 60 Minuten.
SLA, OLA und UC: die drei Vereinbarungsebenen
SLA
Service Level Agreement – externe Ebene
Vereinbarung zwischen Dienstleister und Kunde. Definiert, was der Kunde erwarten darf. Das externe Versprechen.
OLA
Operational Level Agreement – interne Ebene
Vereinbarung zwischen internen Teams. Definiert, was jede Einheit beitragen muss, damit das SLA eingehalten wird. Das interne Versprechen.
UC
Underpinning Contract – Lieferantenebene
Vertrag mit externen Zulieferern oder Unterauftragnehmern. Sichert die Leistungen ab, die intern nicht erbracht werden können.
Warum OLAs in der Automatisierung besonders wichtig sind
Automatisierte Prozesse sind oft auf mehrere Teams verteilt: Das Operations-Team überwacht die Laufzeit, das Entwicklungsteam ist für Bugfixes zuständig, die IT stellt die Infrastruktur bereit, das Fachteam definiert Regelwerke. Wenn ein Workflow nachts ausfällt und ein Kunde auf eine Reaktion innerhalb von 2 Stunden vertraut, muss klar sein, wer was tut: Wer wird alarmiert? Wer entscheidet? Wer führt den Fix durch? Wer kommuniziert mit dem Kunden? Ohne OLA wird das zu einer ungeklärten Frage unter Zeitdruck – mit OLA ist es ein abgestimmter Prozess.
Typische OLA-Inhalte in Automatisierungsprojekten
Monitoring-Verantwortung
Welches Team überwacht welche Systeme? Wer empfängt welche Alerts? In welchen Zeitfenstern?
Eskalationspfade
Wer wird bei welchem Fehlertyp kontaktiert? In welcher Reihenfolge? Mit welcher Reaktionszeit?
Wartungsverantwortung
Welches Team ist für Updates, Patches und Konfigurationsänderungen zuständig? Wer gibt Freigaben?
Bereitschaftsdienst
Wer ist außerhalb der Geschäftszeiten erreichbar? Wie wird der Bereitschaftsdienst organisiert und vergütet?
Änderungsmanagement
Wie werden Änderungen an Workflows oder Konfigurationen beantragt, reviewed und genehmigt?
Kommunikationspflichten
Wer informiert den Kunden bei Störungen? Mit welchem Inhalt? In welcher Zeit nach Erkennung?
OLA vs. SLA: die wichtigste Abgrenzung
Ein SLA ist ein Versprechen an den Kunden – es definiert den externen Anspruch und ist oft vertraglich bindend mit Penalty-Regelungen. Ein OLA ist eine interne Betriebsvereinbarung – es definiert, wie die Organisation intern funktionieren muss, um das SLA einzuhalten. OLAs sind typischerweise weniger formal als SLAs, aber nicht weniger wichtig: Ein OLA, das nicht eingehalten wird, gefährdet unweigerlich das SLA, das nach außen versprochen wurde.
OLA und Verantwortungsklarheit
Der wichtigste Nutzen eines OLAs ist nicht das Dokument selbst, sondern der Prozess seiner Erstellung: Teams müssen gemeinsam klären, wer was tut, wer was entscheiden darf und wie koordiniert reagiert wird. Dieser Klärungsprozess deckt oft Lücken in der internen Verantwortungsverteilung auf – Situationen, in denen niemand klar zuständig ist – und schließt sie, bevor sie im Ernstfall zum Problem werden.
Praxisbeispiel
Ein Automatisierungsdienstleister hat gegenüber einem Kunden ein SLA mit 2-Stunden-Reaktionszeit bei kritischen Ausfällen vereinbart. Intern regelt ein OLA die Umsetzung: Das Monitoring-System sendet bei kritischen Alerts sofort eine SMS an den Bereitschaftsdienst (Reaktionszeit: 10 Minuten). Der Bereitschaftsdienst klassifiziert das Problem und eskaliert bei Bedarf an den Lead-Entwickler (Reaktionszeit: weitere 15 Minuten). Der Lead-Entwickler initiiert einen Remote-Fix oder eskaliert an den Infrastruktur-Lead. Parallel informiert das Operations-Team den Kunden innerhalb von 20 Minuten nach Erkennung. Das OLA stellt sicher, dass die 2-Stunden-SLA-Garantie selbst bei Nacht und am Wochenende eingehalten werden kann – weil jeder Schritt und jede Verantwortlichkeit im Voraus geklärt wurde.
