Ein Operational Level Agreement, kurz OLA, ist ein zentrales Steuerungsinstrument im IT-Service-Management. Es sorgt dafür, dass interne Teams ihre Beiträge so abstimmen, dass externe Servicezusagen gegenüber Fachbereichen oder Kunden realistisch eingehalten werden können. Gerade in modernen Betriebsmodellen mit Cloud, DevOps, Provider-Steuerung und steigenden Compliance-Anforderungen gewinnt das OLA deutlich an Bedeutung.
Begriffserklärung: Was ist ein Operational Level Agreement?
Ein Operational Level Agreement ist eine dokumentierte interne Vereinbarung zwischen beteiligten Leistungseinheiten eines Service Providers, etwa Service Desk, Netzwerk, Plattformbetrieb, Security oder Applikationsmanagement. Ziel ist es, interne Verantwortlichkeiten, Reaktionszeiten, Eskalationswege und Qualitätsziele so festzulegen, dass ein übergeordnetes SLA eingehalten werden kann. Im Unterschied zum SLA richtet sich ein OLA also nicht primär an den externen Kunden, sondern an interne Teams; im Unterschied zu einem Underpinning Contract bezieht es sich nicht auf externe Lieferanten.
Im IT-Umfeld ist das relevant, weil Servicequalität heute nicht mehr nur von einem Team abhängt. ITIL 4 betont, dass Service Level Management nicht bloß SLA-Verwaltung ist, sondern auf wirksame Servicequalität und kontinuierliche Verbesserung zielt. OLAs schaffen dafür die interne Verbindlichkeit.
Funktionsweise & technische Hintergründe
Ein OLA zerlegt einen Service in operative Beiträge. Beispiel: Ein SLA fordert die Wiederherstellung eines kritischen Dienstes innerhalb von vier Stunden. Damit dies erreichbar ist, definiert das OLA etwa 15 Minuten für Triage im Service Desk, 30 Minuten für Incident-Übernahme durch den Second Level, 60 Minuten für Plattformanalyse und feste Eskalationen an Rufbereitschaft oder Supplier Management. So entsteht eine interne Leistungskette mit messbaren Übergaben.
Typische Inhalte eines OLA sind Rollen, Verantwortlichkeiten, Betriebszeiten, Priorisierung, Abhängigkeiten, Eskalationsstufen, Messpunkte und Reporting. Technisch werden diese Werte meist in ITSM-Werkzeugen hinterlegt und mit Incident-, Problem-, Change- und Monitoring-Daten verknüpft. Wichtig ist, dass Metriken nicht isoliert entstehen, sondern aus Servicezielen, Reporting-Anforderungen und verfügbaren Daten abgeleitet werden.
Anwendungsbeispiele in der Praxis
In Behörden unterstützt ein OLA den stabilen Betrieb von Fachverfahren, indem Service Desk, Rechenzentrum und Fachapplikationsbetrieb verbindlich zusammenarbeiten. In Industrieunternehmen sichert es Produktions-IT und MES-Systeme gegen lange Ausfallzeiten ab. Im Finanzsektor hilft es, hohe Anforderungen an Verfügbarkeit, Nachvollziehbarkeit und Eskalation im Zusammenspiel von Infrastruktur-, Security- und Applikationsteams zu erfüllen. Auch in Multi-Provider-Umgebungen ist ein OLA wichtig, um interne Leistungen sauber von externen Lieferverpflichtungen abzugrenzen.
Nutzen und Herausforderungen
Vorteile eines Operational Level Agreement sind vor allem höhere Transparenz, klarere Verantwortlichkeiten, bessere Messbarkeit und realistischere SLA-Erfüllung. Strategisch verbessert ein OLA außerdem die Skalierbarkeit des Betriebs, weil Schnittstellen standardisiert werden. Organisatorisch sinkt das Risiko, dass Tickets zwischen Teams verloren gehen oder Eskalationen zu spät erfolgen.
Dem stehen Herausforderungen gegenüber: Zu detaillierte OLA-Konstrukte erhöhen die Komplexität, schlecht abgestimmte Kennzahlen fördern lokales Optimieren statt Servicequalität, und in hybriden Umgebungen mit Cloud-Providern entstehen schnell Abhängigkeiten zwischen internen OLAs und externen Verträgen. Zudem verschiebt sich modernes Service Management zunehmend von rein technischen Kennzahlen hin zu Experience-orientierten Messgrößen. OLAs bleiben wichtig, sollten aber mit kunden- und nutzerbezogenen Sichtweisen ergänzt werden.
Alternative Lösungen
| Lösung | Fokus | Typische Parteien | Stärke | Grenze |
|---|---|---|---|---|
| OLA | Interne Betriebszusagen | Interne IT-Teams | Operative Steuerbarkeit | Für Endkunden wenig sichtbar |
| SLA | Servicequalität nach außen | Provider und Kunde | Klare Kundenerwartung | Ohne OLA oft schwer einhaltbar |
| Underpinning Contract | Externe Lieferverpflichtung | Provider und Lieferant | Steuerung von Drittparteien | Weniger Einfluss auf interne Abläufe |
| XLA | Nutzererlebnis | Provider und Business | Höhere Business-Nähe | Schwerer messbar und interpretierbar |
Die sinnvollste Praxis ist meist die Kombination: SLA für das Business, OLA für interne Teams, Underpinning Contracts für Lieferanten und ergänzend XLA-Metriken für die Nutzerperspektive.
Fazit
Ein Operational Level Agreement ist weit mehr als interne Bürokratie. Richtig aufgebaut macht es Servicezusagen technisch umsetzbar, messbar und auditierbar. Für professionelle IT-Organisationen ist das OLA daher ein verbindendes Element zwischen SLA, operativem Betrieb und kontinuierlicher Verbesserung. Besonders in komplexen Enterprise- und Behördenumgebungen ist ein sauberes OLA oft der Unterschied zwischen formal versprochener und tatsächlich gelieferter Servicequalität.
FAQs
Wofür braucht man ein OLA, wenn bereits ein SLA existiert?
Ein SLA definiert das Serviceversprechen gegenüber dem Kunden. Das OLA legt fest, wie interne Teams dieses Versprechen praktisch einhalten.
Welche Kennzahlen gehören in ein gutes OLA?
Typisch sind Reaktionszeit, Wiederherstellungszeit, Eskalationsfristen, Übergabezeiten zwischen Teams, Betriebszeiten und Reporting-Zyklen.
Ist ein OLA auch in Cloud- und DevOps-Umgebungen sinnvoll?
Ja. Gerade dort sind Zuständigkeiten verteilt. Ein OLA schafft klare Schnittstellen zwischen Plattform-, Security-, Operations- und Applikationsteams.
Autor
Florian Deinhard
Artikel erstellt: 02.09.2024
Artikel aktualisiert: 07.04.2026
