- KYBERNA AI
-
ITSM & ESM Software
- ITSM & ESM Software ky2help®
- Lösung nach Branchen
- Bauunternehmen & Baugewerbe
- Finanzdienstleistungen & Banken
- Gesundheitswesen & Kliniken
- Hospitality & Hotelgruppen
- Industrie & Fertigung
- IT-Dienstleister, MSPs & Systemhäuser
- Öffentliche Verwaltung & Behörden
- Sicherheitsdienste & Leitstellen
- Telekommunikation & Netzbetreiber
- Versicherungen & Sozialversicherungen
- ky2help® Referenzen
- Kontakt
- ITSM & ESM Wissenswelt
- Glossar
- IT Services
- eAuktion
- Über uns
- News & Blog
- Support

Glossar
Fachbegriffe einfach erklärt
Operational Level Agreement (OLA): Definition, Inhalte und Einsatz im IT Service Management
Ein Operational Level Agreement (OLA) ist eine dokumentierte Vereinbarung zwischen einem IT-Serviceanbieter und einer anderen Einheit derselben Organisation, die festlegt, welche Teilleistung diese Einheit zu einem Service beiträgt und welche Ziele dafür gelten. Typische Partner sind der Service Desk und Fachteams wie Netzwerk, Datenbanken oder Anwendungsbetrieb.
Das OLA sichert von innen ab, was ein Service Level Agreement (SLA) dem Kunden zusagt. Bekannt wurde der Begriff durch ITIL, wo er schon in ITIL V2 und ITIL v3 zum Service Level Management gehörte. ITIL 4 stellt ihn nicht mehr in den Mittelpunkt, an der Sache ändert das wenig: Auch die Norm ISO/IEC 20000-1:2018 verlangt für interne Lieferanten eine dokumentierte Vereinbarung über Ziele, Aktivitäten und Schnittstellen.
Das Wichtigste in Kürze
- Zweck: Ein OLA macht interne Zuarbeit planbar, damit die Ziele im SLA erreichbar sind.
- Inhalt: beteiligte Teams, unterstützter Service, Teilleistung, Übergabepunkte, Servicezeiten, Zielwerte je Priorität, Messung, Eskalation und Überprüfung.
- Abgrenzung: Das SLA gilt gegenüber dem Kunden, das OLA zwischen Einheiten derselben Organisation, der Underpinning Contract (UC) gegenüber externen Lieferanten.
- Praxis: Wirksam wird ein OLA erst, wenn seine Zielzeiten an der Weitergabe von Tickets im ITSM-System hängen und Abweichungen ausgewertet werden.
Stand: November 2026 · Fachlich abgeglichen mit ITIL 4 von PeopleCert/AXELOS und ISO/IEC 20000-1:2018 (Quellen am Ende des Artikels)
Was ein OLA regelt: Bestandteile im Überblick
Ein OLA ist kein zweites SLA. Es beschreibt eine Teilstrecke der Servicekette und beantwortet die Frage, was ein Team liefern muss, damit ein anderes Team seine Zusage halten kann. Bewährt haben sich diese Bestandteile:
- Parteien und Rollen: beteiligte Teams, Verantwortliche für das OLA und Ansprechpersonen im Tagesgeschäft.
- Bezug zum Service: der unterstützte Service aus dem Servicekatalog und die SLAs, die von dieser Zuarbeit abhängen.
- Teilleistung: was genau erbracht wird, etwa die Analyse von Netzwerkstörungen, die Rücksicherung einer Datenbank oder die Einrichtung neuer Benutzerkonten.
- Übergabepunkte: welche Angaben ein Ticket bei der Weitergabe enthalten muss und ab wann die Zuständigkeit wechselt. Ohne klare Übergabe lässt sich keine Frist sauber messen.
- Servicezeiten: Erreichbarkeit des Teams, Rufbereitschaft und Regeln für Wartungsfenster.
- Zielwerte je Priorität: zum Beispiel Zeit bis zur Annahme, bis zur ersten Rückmeldung und bis zur Lösung oder Umgehungslösung.
- Messung und Bericht: Datenquelle, Messmethode und Berichtsrhythmus.
- Eskalation und Änderung: wer bei drohender Verfehlung informiert wird, wann das OLA überprüft wird und wer Änderungen freigibt.
Zielwerte aus dem SLA ableiten
Die Zielwerte eines OLA folgen aus dem SLA, nicht umgekehrt. Angenommen, ein SLA sagt für Störungen der Priorität 2 eine Lösung innerhalb von acht Servicestunden zu. Der Service Desk braucht für Erfassung, Erstanalyse und Weitergabe höchstens 30 Minuten. Das OLA mit dem Netzwerkteam sieht eine Stunde für die Annahme und fünf Stunden für Lösung oder Umgehung vor. Damit bleiben anderthalb Stunden Puffer für Rückfragen, Bestätigung durch den Anwender und Abschluss. Alle Werte sind Beispiele.
Reaktions- und Lösungsziele sollten dabei getrennt betrachtet werden. Die Reaktionszeit aus dem SLA erbringt meist der Service Desk allein. Die OLAs der Fachteams stützen vor allem die Lösungszeit.
OLA, SLA und Underpinning Contract: die Unterschiede
Ein Service lässt sich als Kette von Zusagen beschreiben. Nach außen steht das SLA. Dahinter stützen OLAs die interne Zuarbeit und Underpinning Contracts die Leistungen externer Lieferanten.
| Merkmal | Ausprägung |
|---|---|
| Operational Level Agreement (OLA) | |
| Partner | Serviceanbieter und interne Einheit |
| Gegenstand | Teilleistung für einen Service |
| Bindung | Interne Vereinbarung, kein Vertrag |
| Beispielziel | Annahme eines Tickets in 60 Minuten |
| Service Level Agreement (SLA) | |
| Partner | Serviceanbieter und Kunde |
| Gegenstand | Service aus Sicht des Kunden |
| Bindung | Extern meist Vertragsteil, intern verbindliche Absprache |
| Beispielziel | Lösung in acht Servicestunden |
| Underpinning Contract (UC) | |
| Partner | Serviceanbieter und externer Lieferant |
| Gegenstand | Zugekaufte Leistung |
| Bindung | Vertrag mit Rechtsfolgen |
| Beispielziel | Austausch von Hardware am nächsten Werktag |
Nicht jede interne Absprache ist ein OLA. Ein Service Level Objective (SLO) ist ein einzelner Zielwert, der in einem SLA oder OLA stehen kann, für sich genommen aber keine Vereinbarung ist. Eine Standard Operating Procedure beschreibt, wie eine Aufgabe erledigt wird, aber nicht, bis wann.
ITIL 4 behandelt das Thema in den Practices Service Level Management und Supplier Management und betrachtet Services als Wertströme über Teamgrenzen hinweg. Der Begriff OLA bleibt in Unternehmen gebräuchlich. ISO/IEC 20000-1:2018 verwendet ihn nicht, fordert in Abschnitt 8.3.4.2 aber für interne Lieferanten und für Kunden, die selbst zuliefern, eine dokumentierte Vereinbarung. Ein Beispiel für Letzteres ist die Personalabteilung, die Eintritte rechtzeitig melden muss, damit die IT den Arbeitsplatz bereitstellen kann.
OLAs im Ticket- und Eskalationsprozess
Ob ein OLA trägt, entscheidet sich an der Weitergabe eines Tickets. Damit OLAs über viele Teams und Standorte einheitlich funktionieren, sollten sie nach demselben Muster aufgebaut und im ITSM-System gesteuert werden. Vier Regeln helfen dabei:
1. Standardisieren statt einzeln verhandeln
Ein einheitliches OLA-Muster mit festen Abschnitten und derselben Prioritätsmatrix wie im SLA spart Abstimmungsaufwand. Teamindividuell sind nur Teilleistung und Zielwerte. Kommt ein neues Team hinzu, füllt es das Muster aus, statt ein eigenes Dokument zu entwerfen.
2. Die Frist an die Zuweisung koppeln
Die OLA-Zeit beginnt, wenn ein Ticket der zuständigen Gruppe zugewiesen ist und die vereinbarten Übergabekriterien erfüllt. Unvollständige Tickets sollten mit Begründung zurückgewiesen werden dürfen. Sonst pendeln sie zwischen den Teams, und keine Messung ist aussagekräftig.
3. Vor der Frist eskalieren
Eine Benachrichtigung an die bearbeitende Gruppe bei 75 Prozent der OLA-Zeit und an die Teamleitung bei Überschreitung (Beispielwerte) lässt noch Zeit zum Handeln. Wer erst nach Ablauf informiert, dokumentiert nur noch die Verfehlung.
4. Wartezeiten begründen
Wartet ein Team auf einen externen Lieferanten oder auf Angaben des Anwenders, sollte der Grund im Ticket stehen. So lässt sich später unterscheiden, ob eine SLA-Verletzung aus einer OLA-Teilstrecke, einem Underpinning Contract oder einer offenen Rückfrage stammt.
Zum Funktionsumfang von ky2help® gehören SLA-Überwachung mit Benachrichtigung, ein flexibles Eskalationsmanagement sowie zeit- und aktionsgesteuerte Workflows. In der zentralen Vertragsverwaltung lassen sich OLAs als eigene Vertragsart neben SLA und UC hinterlegen. Abläufe wie Weitergabe, Rückweisung und Eskalation werden im integrierten Prozessdesigner per Drag-and-Drop angepasst, ohne Programmierung. Arbeitet die Entwicklung in Jira, steht dafür eine Standardschnittstelle bereit.
Kennzahlen, Überprüfung und typische Fehler
Kennzahlen für OLAs
Ein OLA braucht wenige, gut definierte KPIs. Bewährt haben sich:
- Erfüllungsquote je Team und Priorität: Anteil der Tickets, deren OLA-Ziel eingehalten wurde.
- Rückweisungsquote: Anteil der Tickets, die wegen fehlender Angaben zurückgegeben wurden. Ein hoher Wert deutet auf unklare Übergabekriterien hin.
- Weiterleitungen pro Ticket: Viele Stationen sprechen für unklare Zuständigkeiten.
- Anteil an SLA-Verletzungen: Wie oft lag die Ursache einer SLA-Verletzung in einer OLA-Teilstrecke?
Überprüfung
OLAs sollten mindestens einmal im Jahr überprüft werden und zusätzlich immer dann, wenn sich ein SLA, die Teamstruktur oder ein Lieferant ändert. Die Ergebnisse fließen in die kontinuierliche Verbesserung ein, in ITIL 4 die Practice Continual Improvement, in ITIL v3 Continual Service Improvement.
Typische Fehler
- Das OLA hat keinen Bezug zu einem SLA und bleibt deshalb ohne Maßstab.
- Die Zielwerte aller Teilstrecken ergeben zusammen mehr als das SLA erlaubt.
- Die Frist startet, obwohl die Übergabekriterien nicht erfüllt sind.
- Messwerte werden von Hand in Tabellen gepflegt und sind nie aktuell.
- Das OLA dient als Instrument für Schuldzuweisungen statt zur gemeinsamen Steuerung.
- Leistungen einer rechtlich eigenständigen Konzerngesellschaft werden als OLA geführt, obwohl dafür ein Vertrag nötig ist.
Häufige Fragen zum Operational Level Agreement
Was ist ein Operational Level Agreement?
Ein Operational Level Agreement (OLA) ist eine dokumentierte Vereinbarung zwischen einem IT-Serviceanbieter und einer anderen Einheit derselben Organisation. Es legt fest, welche Teilleistung diese Einheit zu einem Service beiträgt und welche Ziele dafür gelten, damit die Zusagen im SLA erreichbar sind.
Was ist der Unterschied zwischen OLA und SLA?
Das SLA regelt die Leistung gegenüber dem Kunden, also was der Service aus dessen Sicht leisten muss. Das OLA regelt die Zuarbeit zwischen Teams derselben Organisation, zum Beispiel zwischen Service Desk und Datenbankteam, die nötig ist, um das SLA einzuhalten.
Ist ein OLA ein Vertrag?
Nein. Weil beide Partner zur selben Organisation gehören, hat ein OLA keinen Vertragscharakter. Verbindlich wird es durch Freigabe der Verantwortlichen, etwa der IT-Leitung, und durch regelmäßige Auswertung. Leistungen externer Lieferanten oder rechtlich eigenständiger Konzerngesellschaften gehören dagegen in einen Vertrag.
Wer ist für ein OLA verantwortlich?
In der Regel die Person, die das Service Level Management verantwortet, gemeinsam mit den Leitungen der beteiligten Teams. Sie stimmen Teilleistungen und Zielwerte ab, geben das OLA frei und prüfen es regelmäßig.
Gibt es OLAs in ITIL 4 noch?
Der Begriff gehörte in ITIL V2 und ITIL v3 zum Service Level Management. ITIL 4 stellt ihn nicht mehr in den Mittelpunkt und behandelt die Abstimmung von Teilleistungen in den Practices Service Level Management und Supplier Management. In der Praxis ist der Begriff weiterhin verbreitet.
Kann ky2help® OLAs abbilden?
Die Vertragsverwaltung von ky2help® kennt OLA als eigene Vertragsart neben SLA und UC. Dazu kommen SLA-Überwachung mit Benachrichtigung, Eskalationsmanagement und zeitgesteuerte Workflows. Wie Ihre internen Zielzeiten abgebildet werden, zeigen wir Ihnen gern in einer Live-Demo.
Quellen und weiterführende Artikel
Quellen
- AXELOS/PeopleCert: ITIL 4 Practice Guide Service Level Management
- AXELOS/PeopleCert: ITIL 4 Practice Guide Supplier Management
- PeopleCert: ITIL 4 – Zertifizierungen und Rahmenwerk
- Advisera: SLAs, OLAs und UCs in ITIL und ISO 20000 (englisch)
- ISO/IEC 20000-1:2018, Abschnitt 8.3.4.2 (Normtext, kostenpflichtig über ISO und die nationalen Normungsorganisationen)
Weiterlesen im Glossar und in der Wissenswelt
Alle Glossar-Artikel in der Übersicht
Erfahren Sie, wie Microsofts Verzeichnisdienst Benutzer, Geräte und Rechte zentral verwaltet – sicher & zukunftsfähig für Unternehmen.
Mehr zu Active Directory
Was ist eine API? Erfahren Sie, wie Programmierschnittstellen Anwendungen verbinden, Prozesse automatisieren und Innovation in der digitalen Wirtschaft ermöglichen.
Was ist Authentifizierung? Erfahren Sie, wie Identitäten geprüft, Konten geschützt und moderne Anmeldeverfahren wie Zwei-Faktor-Authentifizierung Ihre Sicherheit erhöhen.
Was ist ein Backlog? Erfahren Sie, wie priorisierte Aufgabenlisten Teams helfen, Projekte agil zu steuern, Prioritäten zu setzen und Fortschritte transparent zu machen.
Erfahren Sie, wie eine Balanced Scorecard Unternehmen hilft, Strategie, Ziele und Kennzahlen zu verbinden und Erfolge messbar zu machen.
Das Change Advisory Board (CAB) berät bei der Bewertung und Freigabe von Changes im IT Service Management. Erfahren Sie, wann ein CAB gebraucht wird und wie ITIL 4 die Freigabe regelt.
Mehr zum CAB
Gesteuerter Change-Prozess mit Risikoanalyse, CAB-Freigaben und Kommunikation, um Ausfallzeiten zu reduzieren und Releasessicher in Produktionsumgebungen zu bringen.
Erfahren Sie, wie KI-gestützte Chatbots Kommunikation automatisieren, Kundenservice verbessern und Prozesse effizienter gestalten.
Was ist Continuous Integration? Erfahren Sie, wie automatisierte Builds und Tests Entwicklungsprozesse beschleunigen, Fehler vermeiden und Softwarequalität steigern.
Zentrale Konfigurationsdatenbank mit CIs und Beziehungen für Transparenz, Abhängigkeits-/Impact-Analysen, Audit-Sicherheit und Change-/Incident-Beschleunigung.
Was ist CSI? Erfahren Sie, wie Continual Service Improvement in ITIL hilft, IT-Services dauerhaft zu optimieren, Qualität zu steigern und Kundenzufriedenheit zu sichern.
Der Customer Effort Score ist eine Kennzahl, die beschreibt, wie viel Aufwand ein Kunde betreiben muss, um sein Anliegen mit einem Unternehmen zu lösen.
Was ist DevOps? Erfahren Sie, wie Entwicklung und IT-Betrieb durch Automatisierung, Zusammenarbeit und CI/CD zu schnelleren, stabileren Software-Releases führen.
Was ist die DSGVO? Erfahren Sie, wie die Datenschutz-Grundverordnungpersonenbezogene Daten schützt, welche Pflichten Unternehmen haben und welche Rechte Betroffene haben.
Was ist ESM? Erfahren Sie, wie Enterprise Service Management Prozesse vereinheitlicht, Services digitalisiert und alle Abteilungen effizient miteinander verbindet.
Was ist Hardware Asset Management? Erfahren Sie, wie Unternehmen mit HAM ihre IT-Geräte effizient verwalten, Kosten senken und Sicherheit im gesamten Lebenszyklus sichern.
Ein Helpdesk ist die zentrale Schnittstelle zwischen den Anwendern eines Unternehmens und den dafür zuständigen Support-Teams.
Ein Incident ist eine Beeinträchtigung eines IT-Services, die dazu führt, dass der Service nicht wie vorgesehen genutzt werden kann.
Erfahren Sie, wie der internationale Standard Unternehmen hilft, Informationssicherheit systematisch aufzubauen, Risiken zu minimieren und Vertrauen zu schaffen.
Erfahren Sie, wie das Framework IT-Prozesse strukturiert, Qualität sichert und die IT an den Geschäftszielen ausrichtet – praxisnah und modern mit ITIL 4 oder ITIL 5.
IT Service Management (ITSM) beschreibt die Gesamtheit spezialisierter organisatorischer Fähigkeiten, um IT-Services effizient zu betreiben.
Erfahren Sie, wie die japanische Kaizen-Methode durch kleine, stetige Verbesserungen Prozesse optimiert, Qualität steigert und Mitarbeitende einbindet.
Erfahren Sie, wie die Kanban-Methode durch Visualisierung, Flusssteuerung und kleine Verbesserungen Teams effizienter und flexibler arbeiten lässt.
Key Performance Indicators (KPIs) machen Ziele messbar, bewerten Leistung und unterstützen datenbasierte Entscheidungen im Unternehmen.
Erfahren Sie, wie KI funktioniert, wo sie eingesetzt wird und warum sie unsere Arbeitswelt verändert – zwischen Innovation und Verantwortung.
Machine Learning ist ein Teilgebiet der Künstlichen Intelligenz (KI). Es ermöglicht Systemen, Muster und Zusammenhänge in Daten eigenständig zu erkennen.
Erfahren Sie, wie Multi-Faktor-Authentifizierung funktioniert, warum sie Konten wirksam schützt und welche Methoden besonders sicher und benutzerfreundlich sind.
Erfahren Sie, wie die systematische Überwachung von IT-Systemen Leistung, Sicherheit und Verfügbarkeit verbessert – für stabile und effiziente Prozesse.
Erfahren Sie, wie Natural Language Processing funktioniert, wo es eingesetzt wird und warum es Kommunikation, Analyse und Serviceprozesse revolutioniert.
Der Net Promoter Score (NPS) gehört zu den bekanntesten Kennzahlen zur Messung von Kundenzufriedenheit und -loyalität im Umfeld von IT-Ticket-Systemen.
Der Net Promoter Score (NPS) gehört zu den bekanntesten Kennzahlen zur Messung von Kundenzufriedenheit und -loyalität im Umfeld von IT-Ticket-Systemen.
Operational Level Agreements (OLA) regelt interne Zusammenarbeit, unterstützt SLA-Ziele unterstützen und macht Serviceprozesse verlässlicher.
Operational Performance Indicator (OPI) sind ein zentrales Instrument, um die Leistungsfähigkeit operativer Prozesse in Unternehmen messbar zu machen.
Predictive Maintenance ist ein moderner Instandhaltungsansatz, der nicht auf starre Intervalle setzt, sondern auf datenbasierte Vorhersagen.
Die Root Cause Analysis (RCA) ist eine strukturierte Methode, um Ursachen eines Problems oder einer Störung zu identifizieren und zu beseitigen.
Was ist eine REST API? Erfahren Sie, wie REST-Schnittstellen Systeme verbinden, Daten austauschen und moderne Anwendungen schnell, flexibel und skalierbar machen.
Was ist eine Root Cause Analysis? Lernen Sie Methoden wie 5 Why, Ishikawa und Fehlerbaum kennen und erfahren Sie, welche Methode zu welcher Störung passt.
Was ist Scrum? Erfahren Sie, wie das agile Framework Teams hilft, flexibel zu arbeiten, schneller Ergebnisse zu liefern und Projekte kontinuierlich zu verbessern.
Verständlich erklärt: Wie Service Level Agreements Leistungen definieren, Qualität messbar machen und Servicebeziehungen strukturieren.
Was ist SSO? Erfahren Sie, wie Single Sign-On funktioniert, wie es Sicherheit und Komfort verbindet und warum es in modernen IT-Landschaften unverzichtbar ist.
Erfahren Sie, wie das Software Asset Management (SAM) Softwarebestände transparent macht, Kosten optimiert und Compliance sowie IT-Sicherheit stärkt.
Kompakt erklärt: Wie Sprints Teams helfen, in kurzen Zyklen zu planen, zu liefern und sich kontinuierlich zu verbessern.
Was ist eine SOP? Erfahren Sie, wie Standard Operating Procedures Abläufe standardisieren, Qualität sichern und Organisationen zuverlässiger machen.
Erfahren Sie, wie User Experience entsteht, warum sie entscheidend für Erfolg und Zufriedenheit ist und wie gute Nutzererlebnisse gestaltet werden.
Webhooks ermöglichen es, Ereignisse aus einem System in Echtzeit an ein anderes zu übermitteln, ohne dass ständige Abfragen erforderlich sind.
Was ist ein Workflow? Erfahren Sie, wie strukturierte Abläufe Prozesse vereinfachen, Qualität sichern und Unternehmen effizienter machen.