Operational Level Agreement (OLA): interne Absprachen, die den IT-Support verlässlich machen

Ein Operational Level Agreement (OLA) ist eine schriftliche Absprache zwischen Teams oder Abteilungen desselben Unternehmens, wer welchen Beitrag zu einem IT-Service leistet und bis wann. Es sorgt dafür, dass die Zusagen der IT an die Anwenderinnen und Anwender nicht an einer internen Übergabe scheitern.

Ein typischer Fall: Der Support verspricht, ein Problem binnen eines Arbeitstags zu lösen. Halten kann er das nur, wenn der Kollege für das Netzwerk oder die Kollegin für die Warenwirtschaft rechtzeitig zuarbeitet. In kleinen IT-Teams gehört oft auch ein Fachbereich dazu, etwa die Personalabteilung, die neue Mitarbeitende früh genug ankündigt.

Kurz zusammengefasst

• Grundidee: Das OLA hält fest, wer im eigenen Haus was liefert, damit das SLA hält.
• Sinnvoll ab: zwei beteiligten Stellen, etwa Zentrale und Standort oder IT und Fachabteilung.
• Nicht verwechseln: Zusagen eines externen Dienstleisters gehören in den Vertrag, nicht in ein OLA.
• Schlank halten: Für kleine Teams reicht meist eine Seite pro Schnittstelle.

Stand: November 2026 · Fachlich abgeglichen mit ITIL 4 von PeopleCert/AXELOS und Angaben von Microsoft zu Microsoft 365 (Quellen am Ende)

Wann sich ein OLA im IT-Alltag lohnt

Nicht jede Zusammenarbeit braucht ein eigenes Papier. In diesen fünf Situationen spart ein OLA aber Diskussionen und Nachfragen:

1. Tickets wandern zwischen Teams

Der Support nimmt die Störung auf, das Netzwerk- oder Serverteam löst sie. Ohne Absprache weiß niemand, ab wann das zweite Team am Zug ist und wie schnell es reagieren soll.

2. Mehrere Standorte

Die Server betreut die Zentrale, Hardware tauscht jemand vor Ort. Ein OLA klärt, wer welche Einsätze übernimmt und wie die Rückmeldung ins Ticket kommt.

3. Microsoft 365 und lokale Systeme

Lizenzen, Postfächer und Teams-Richtlinien verwaltet oft eine andere Person als den Arbeitsplatz-Support. Das OLA regelt, wer Anfragen zu Microsoft 365 übernimmt und wer bei einer Störung den Dienststatus im Microsoft 365 Admin Center prüft.

4. Ein Fachbereich liefert zu

Ohne rechtzeitige Meldung der Personalabteilung steht am ersten Arbeitstag kein fertiger Laptop bereit. Auch solche Zulieferungen an die IT lassen sich in einem OLA festhalten.

5. Randzeiten und Bereitschaft

Läuft die Produktion am Samstag, muss klar sein, wer erreichbar ist und wie schnell er reagiert.

Wo eine einzige Person alles selbst erledigt, ist ein OLA überflüssig. Dort genügt eine klare Zusage im SLA.

OLA, SLA und der Vertrag mit dem Dienstleister

Viele kleine IT-Abteilungen arbeiten eng mit Systemhäusern und Cloud-Anbietern zusammen. Dabei geht oft durcheinander, welche Absprache wohin gehört. Ein Überblick mit Alltagsbeispielen:

Was ein externes Systemhaus zusagt, ist Vertragsinhalt und kein OLA. Das gilt meist auch für Schwesterfirmen im Konzern, die eine eigene Gesellschaft sind. Bei Microsoft 365 gilt das SLA von Microsoft für Onlinedienste. Ein internes OLA regelt dann nur noch, wer im eigenen Haus Störungen meldet, den Dienststatus verfolgt und die Anwender informiert.

Die Begriffe OLA und Underpinning Contract kennt man aus den älteren ITIL-Versionen V2 und v3. ITIL 4 behandelt Lieferanten in der Practice Supplier Management. Für den Alltag bleibt die Unterscheidung nützlich, weil sie zeigt, wo eine Zusage durch eine andere gedeckt sein muss.

Beispiel: OLAs für ein IT-Team mit drei Standorten

Angenommen, ein Handelsunternehmen hat seine Zentrale in Wien und Filialen in Graz und Linz. Die IT besteht aus vier Personen in Wien, in jeder Filiale kümmert sich eine Mitarbeiterin oder ein Mitarbeiter nebenbei um die Technik. Das Netzwerk betreut ein Systemhaus. Drei kurze OLAs genügen:

• IT Wien und Ansprechpersonen in Graz und Linz: Einfache Vor-Ort-Einsätze wie Druckertausch oder das Anstecken eines Ersatzgeräts werden am selben oder nächsten Arbeitstag erledigt und im Ticket bestätigt.
• IT und Personalabteilung: Eintritte kommen mit Rolle, Standort und Startdatum mindestens fünf Arbeitstage vorher, Austritte spätestens am letzten Arbeitstag.
• IT und Filialleitungen: Fällt die Kassa aus, ruft die Filiale sofort an, statt eine E-Mail zu schreiben, und nennt Kassennummer und Fehlermeldung. Wie schnell die IT zurückruft, steht dagegen im SLA mit den Filialen.

Dazu kommt der Vertrag mit dem Systemhaus, in dem dessen Reaktionszeiten stehen. Alle Werte sind Beispiele und müssen zum eigenen Betrieb passen. Entscheidend ist, dass die Zusage an die Filialen nicht kürzer ist als das, was die Zulieferer gemeinsam schaffen.

Im Alltag funktionieren solche Absprachen nur, wenn alle Anfragen an einem Ort landen. Bei ky2help^® kommen sie über E-Mail, Microsoft Teams, die Telefonanlage (CTI) und Self-Service-Portale ins selbe System. SLA-Überwachung mit Benachrichtigung und zeitgesteuerte Workflows erinnern an fällige Tickets. Die Absprachen selbst lassen sich in der Vertragsverwaltung als SLA, OLA oder UC hinterlegen.

Self-Service-Portale

Vorlage: ein OLA auf einer Seite

Für ein kleines Team muss ein OLA kein langes Dokument sein. Diese acht Punkte reichen in den meisten Fällen:

1. Wer mit wem: Namen der Beteiligten und ihre Vertretung.
2. Wofür: der Service und das SLA, das unterstützt wird.
3. Was: die Leistung, die geliefert wird, in zwei bis drei Sätzen.
4. Übergabe: was im Ticket stehen muss, bevor es weitergeht.
5. Erreichbarkeit: Zeiten, Urlaubsvertretung, Randzeiten.
6. Zielzeiten: höchstens drei Prioritätsstufen mit klaren Werten.
7. Bei Verzug: wer informiert wird und wie.
8. Überprüfung: zum Beispiel halbjährlich oder wenn ein Standort dazukommt.

Drei Tipps aus dem IT-Alltag

• Realistisch planen: Teilzeit, Urlaub und Krankenstand gehören in die Zielzeiten, nicht in die Ausnahmen.
• Gemeinsam formulieren: Ein OLA, das ein Team dem anderen vorschreibt, wird selten eingehalten.
• Zahlen nutzen, nicht Schuldige suchen: Wird eine Zielzeit oft gerissen, ist meist die Absprache falsch und nicht das Team.

Häufige Fragen zum OLA

Was ist ein OLA, einfach erklärt?

Ein OLA ist eine interne Absprache zwischen zwei Stellen im selben Unternehmen. Sie hält fest, wer welchen Beitrag zu einem IT-Service leistet und wie schnell, damit die Zusagen an die Anwenderinnen und Anwender halten.

Braucht ein kleines IT-Team ein OLA?

Nur wenn mehrere Stellen an einer Lösung beteiligt sind, etwa Zentrale und Standorte oder IT und Personalabteilung. Erledigt eine Person alles allein, reicht eine klare Zusage im SLA.

Ist die Vereinbarung mit unserem IT-Dienstleister ein OLA?

Nein. Zusagen externer Partner gehören in den Vertrag, in der ITIL-Sprache in einen Underpinning Contract. Ein OLA gibt es nur zwischen Teams oder Abteilungen desselben Unternehmens.

Wie lang sollte ein OLA sein?

Für kleine Teams reicht oft eine Seite: Beteiligte, unterstützter Service, Leistung, Übergabe, Erreichbarkeit, Zielzeiten, Vorgehen bei Verzug und ein Termin für die Überprüfung.

Wie oft sollte man ein OLA überprüfen?

Ein- bis zweimal im Jahr und zusätzlich, wenn sich etwas Wesentliches ändert, zum Beispiel ein neuer Standort, ein neuer Dienstleister oder ein geändertes SLA.

Kann ich OLAs in ky2help® hinterlegen?

Ja. Die Vertragsverwaltung von ky2help® kennt SLA, OLA und UC als Vertragsarten. Dazu kommen SLA-Überwachung und Benachrichtigung. Einen ersten Eindruck vom System gibt die Testversion, die ohne Installation im Browser läuft.

Quellen und weiterführende Artikel

Quellen

• AXELOS/PeopleCert: ITIL 4 Practice Guide Service Level Management
• PeopleCert: ITIL 4 – Zertifizierungen und Rahmenwerk
• Microsoft Learn: Microsoft 365-Dienststatus überprüfen
• Microsoft Learn: Nachrichtencenter in Microsoft 365

Weiterlesen

• Service Level Agreement (SLA) und Helpdesk
• Incident und Monitoring
• Microsoft-365-Leistungen von KYBERNA
• ky2help® für IT-Dienstleister (MSP)