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.

Interne Zuarbeit sichtbar machen

Ein OLA wirkt nur, wenn Übergaben und Fristen im Ticket nachvollziehbar sind. Erfahren Sie, wie ky2help® Serviceprozesse über Teamgrenzen hinweg abbildet.

ky2help® kennenlernen

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.

MerkmalAusprägung
Operational Level Agreement (OLA)
PartnerServiceanbieter und interne Einheit
GegenstandTeilleistung für einen Service
BindungInterne Vereinbarung, kein Vertrag
BeispielzielAnnahme eines Tickets in 60 Minuten
Service Level Agreement (SLA)
PartnerServiceanbieter und Kunde
GegenstandService aus Sicht des Kunden
BindungExtern meist Vertragsteil, intern verbindliche Absprache
BeispielzielLösung in acht Servicestunden
Underpinning Contract (UC)
PartnerServiceanbieter und externer Lieferant
GegenstandZugekaufte Leistung
BindungVertrag mit Rechtsfolgen
BeispielzielAustausch 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.

Mehr zur Automatisierung

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.

Interne Zusagen messbar steuern

Laufen Weitergaben per E-Mail und stehen Fristen in Tabellen, zeigt sich eine Lücke im OLA erst bei der SLA-Verletzung. In einer Live-Demo zeigen wir Ihnen, wie ky2help® Fristen überwacht, rechtzeitig eskaliert und Vereinbarungen zentral verwaltet.

  • Vertragsarten SLA, OLA und UC zentral verwaltet
  • SLA-Überwachung mit Benachrichtigung und Eskalationsmanagement
  • Workflows im Prozessdesigner ohne Programmierung anpassen

Live-Demo vereinbaren

Oder ky2help® kostenlos testen

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

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.

Mehr über API's

Was ist Authentifizierung? Erfahren Sie, wie Identitäten geprüft, Konten geschützt und moderne Anmeldeverfahren wie Zwei-Faktor-Authentifizierung Ihre Sicherheit erhöhen.

Zur Authentifizierung

Was ist ein Backlog? Erfahren Sie, wie priorisierte Aufgabenlisten Teams helfen, Projekte agil zu steuern, Prioritäten zu setzen und Fortschritte transparent zu machen.

Mehr über Backlog

Erfahren Sie, wie eine Balanced Scorecard Unternehmen hilft, Strategie, Ziele und Kennzahlen zu verbinden und Erfolge messbar zu machen.

Zur Balanced Scorecard

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.

Mehr zu Change Management

Erfahren Sie, wie KI-gestützte Chatbots Kommunikation automatisieren, Kundenservice verbessern und Prozesse effizienter gestalten.

Mehr zu Chatbots

Was ist Continuous Integration? Erfahren Sie, wie automatisierte Builds und Tests Entwicklungsprozesse beschleunigen, Fehler vermeiden und Softwarequalität steigern.

Mehr dazu

Zentrale Konfigurationsdatenbank mit CIs und Beziehungen für Transparenz, Abhängigkeits-/Impact-Analysen, Audit-Sicherheit und Change-/Incident-Beschleunigung.

Mehr über CMDB

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.

Mehr über CSI

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.

Mehr über CES

Was ist DevOps? Erfahren Sie, wie Entwicklung und IT-Betrieb durch Automatisierung, Zusammenarbeit und CI/CD zu schnelleren, stabileren Software-Releases führen.

Mehr über DevOps

Was ist die DSGVO? Erfahren Sie, wie die Datenschutz-Grundverordnungpersonenbezogene Daten schützt, welche Pflichten Unternehmen haben und welche Rechte Betroffene haben.

Mehr über DSGVO

Was ist ESM? Erfahren Sie, wie Enterprise Service Management Prozesse vereinheitlicht, Services digitalisiert und alle Abteilungen effizient miteinander verbindet.

Mehr über ESM

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.

Mehr über HAM

Ein Helpdesk ist die zentrale Schnittstelle zwischen den Anwendern eines Unternehmens und den dafür zuständigen Support-Teams. 

Mehr über Helpdesk

Ein Incident ist eine Beeinträchtigung eines IT-Services, die dazu führt, dass der Service nicht wie vorgesehen genutzt werden kann.

Mehr über Incident

Erfahren Sie, wie der internationale Standard Unternehmen hilft, Informationssicherheit systematisch aufzubauen, Risiken zu minimieren und Vertrauen zu schaffen.

Mehr über Incident

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.

Mehr über ITIL

IT Service Management (ITSM) beschreibt die Gesamtheit spezialisierter organisatorischer Fähigkeiten, um IT-Services effizient zu betreiben.

Mehr über ITSM

Erfahren Sie, wie die japanische Kaizen-Methode durch kleine, stetige Verbesserungen Prozesse optimiert, Qualität steigert und Mitarbeitende einbindet.

Mehr über Kaizen

Erfahren Sie, wie die Kanban-Methode durch Visualisierung, Flusssteuerung und kleine Verbesserungen Teams effizienter und flexibler arbeiten lässt.

Mehr über Kanban

Key Performance Indicators (KPIs) machen Ziele messbar, bewerten Leistung und unterstützen datenbasierte Entscheidungen im Unternehmen.

Mehr über KPIs

Erfahren Sie, wie KI funktioniert, wo sie eingesetzt wird und warum sie unsere Arbeitswelt verändert – zwischen Innovation und Verantwortung.

Mehr über KI

Machine Learning ist ein Teilgebiet der Künstlichen Intelligenz (KI). Es ermöglicht Systemen, Muster und Zusammenhänge in Daten eigenständig zu erkennen.

Mehr zu Machine Learning

Erfahren Sie, wie Multi-Faktor-Authentifizierung funktioniert, warum sie Konten wirksam schützt und welche Methoden besonders sicher und benutzerfreundlich sind.

Mehr über MFA

Erfahren Sie, wie die systematische Überwachung von IT-Systemen Leistung, Sicherheit und Verfügbarkeit verbessert – für stabile und effiziente Prozesse.

Mehr über Monitoring

Erfahren Sie, wie Natural Language Processing funktioniert, wo es eingesetzt wird und warum es Kommunikation, Analyse und Serviceprozesse revolutioniert.

Mehr über NLP erfahren

Der Net Promoter Score (NPS) gehört zu den bekanntesten Kennzahlen zur Messung von Kundenzufriedenheit und -loyalität im Umfeld von IT-Ticket-Systemen.

Mehr über den NPS

Der Net Promoter Score (NPS) gehört zu den bekanntesten Kennzahlen zur Messung von Kundenzufriedenheit und -loyalität im Umfeld von IT-Ticket-Systemen.

Mehr über den NPS

Operational Level Agreements (OLA) regelt interne Zusammenarbeit, unterstützt SLA-Ziele unterstützen und macht Serviceprozesse verlässlicher. 

Mehr zu OLA

Operational Performance Indicator (OPI) sind ein zentrales Instrument, um die Leistungsfähigkeit operativer Prozesse in Unternehmen messbar zu machen. 

Mehr zu OPI

Predictive Maintenance ist ein moderner Instandhaltungsansatz, der nicht auf starre Intervalle setzt, sondern auf datenbasierte Vorhersagen.

Zu Predictive Maintenance

Die Root Cause Analysis (RCA) ist eine strukturierte Methode, um Ursachen eines Problems oder einer Störung zu identifizieren und zu beseitigen. 

Mehr über RCA

Was ist eine REST API? Erfahren Sie, wie REST-Schnittstellen Systeme verbinden, Daten austauschen und moderne Anwendungen schnell, flexibel und skalierbar machen.

Mehr zu REST API

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.

Zur Root Cause Analysis

Was ist Scrum? Erfahren Sie, wie das agile Framework Teams hilft, flexibel zu arbeiten, schneller Ergebnisse zu liefern und Projekte kontinuierlich zu verbessern.

Mehr zu Scrum

Verständlich erklärt: Wie Service Level Agreements Leistungen definieren, Qualität messbar machen und Servicebeziehungen strukturieren.

Mehr über SLA erfahren

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.

Mehr zu SSO

Erfahren Sie, wie das Software Asset Management (SAM) Softwarebestände transparent macht, Kosten optimiert und Compliance sowie IT-Sicherheit stärkt.

Mehr zu SAM

Kompakt erklärt: Wie Sprints Teams helfen, in kurzen Zyklen zu planen, zu liefern und sich kontinuierlich zu verbessern.

Mehr zu Sprints

Was ist eine SOP? Erfahren Sie, wie Standard Operating Procedures Abläufe standardisieren, Qualität sichern und Organisationen zuverlässiger machen.

Mehr zu SOP

Erfahren Sie, wie User Experience entsteht, warum sie entscheidend für Erfolg und Zufriedenheit ist und wie gute Nutzererlebnisse gestaltet werden.

Mehr zu User Experience

Webhooks ermöglichen es, Ereignisse aus einem System in Echtzeit an ein anderes zu übermitteln, ohne dass ständige Abfragen erforderlich sind. 

Mehr zu Webhooks

Was ist ein Workflow? Erfahren Sie, wie strukturierte Abläufe Prozesse vereinfachen, Qualität sichern und Unternehmen effizienter machen.

Mehr über Workflows