SLAs sind Versprechen an Kunden – OLAs stellen sicher, dass Ihre internen Teams sie einhalten können. Mit Trupeer können Sie Stunden beim Schreiben von OLAs sparen, indem Sie mit einer kostenlosen Vorlage für eine operative Leistungsvereinbarung beginnen, sie mit Ihren Brand Guidelines anpassen und die OLA in eine Video-Durchlaufanleitung umwandeln, die jedes interne Team hinter gemeinsamen Service-Standards vereint.

Was ist eine Vorlage für eine operative Leistungsvereinbarung?

Eine operative Leistungsvereinbarung, kurz OLA, ist eine interne Vereinbarung zwischen Teams innerhalb derselben Organisation, die ein Commitment untermauert, das gegenüber jemandem außerhalb der Organisation gemacht wird. Der Service Desk verspricht dem Unternehmen eine vierstündige Lösung bei größeren Vorfällen. Dieses Versprechen gilt jedoch nur, wenn das Netzwerkteam, das Applikationsteam und alle anderen in der Kette jeweils ihren Part innerhalb einer bekannten Zeit übernehmen.

Die OLA ist der Ort, an dem diese internen Bausteine festgehalten werden. Sie ist kein Vertrag, niemand zahlt irgendjemandem, und die Durchsetzung ist rein managerial – das ist sowohl ihre Schwäche als auch der Grund, warum sie auf eine ehrliche Weise sein kann, wie es ein Vertrag nicht kann.

Eine Vorlage für eine operative Leistungsvereinbarung ist die wiederverwendbare Struktur: die Parteien, die abgedeckten Services, die Commitments, die Maßnahmen und die Regelungen für das Review. Vorlagen dafür sind leicht zu finden. Die meisten ermöglichen es Ihnen, eine OLA zu schreiben, die vollständig eingehalten wird – und trotzdem scheitert. Genau darum geht der Rest dieser Seite.

OLA vs. SLA: Wozu verpflichtet jeweils was wirklich?

Drei Dokumente gehören in diese Kategorie, und sie zu vermischen verursacht echte Probleme.

Eine Service Level Agreement ist das Commitment gegenüber dem Kunden oder dem Unternehmen. Sie wird in den Begriffen des Kunden formuliert, meist Ende-zu-Ende, und sie ist das, was an Personen außerhalb der Delivery-Kette berichtet wird.

Eine operative Leistungsvereinbarung ist intern, zwischen Teams, die beide in dieselbe Organisation berichten. Sie existiert ausschließlich, um die SLA erreichbar zu machen, und sie sollte niemals ein Commitment enthalten, das die SLA nicht braucht.

Ein zugrunde liegender Vertrag ist die kommerzielle Vereinbarung mit einem Dritten, einem Vendor oder einem ausgelagerten Anbieter, die dieselbe Kette unterstützt. Er hat rechtliche Wirkung, die die OLA nicht hat, und er hat in der Regel die geringste Flexibilität der drei, daher sollte er vor der SLA vereinbart werden und nicht danach.

Die praktische Konsequenz ist eine Reihenfolgeregel. Zuerst die zugrunde liegenden Verträge vereinbaren, dann die SLA auf Basis dessen, was diese Verträge erlauben, und anschließend die OLAs, die den Rest abdecken. Organisationen, die es in umgekehrter Reihenfolge tun, versprechen dem Unternehmen routinemäßig etwas, das kein Vendor vereinbart hat, zu liefern.

So passen Sie diese Vorlage in Trupeer an

Schritt 1: Öffnen Sie den Bereich Vorlagen

Gehen Sie im Hauptmenü zum Bereich Vorlagen.

Schritt 2: Wählen und öffnen Sie eine Vorlage

Klicken Sie auf eine beliebige Vorlage, mit der Sie arbeiten möchten, um sie zu öffnen.

Schritt 3: Ansicht der Vorlage erweitern

Falls nötig, erweitern Sie die Vorlagenansicht, um das vollständige Layout und die Details klar zu sehen.

Schritt 4: Vorlage bearbeiten

Klicken Sie auf „Bearbeiten“, um mit der Anpassung der ausgewählten Vorlage zu beginnen.

Im Editor können Sie:

• Neue Abschnitte hinzufügen

• Formatierungsregeln definieren oder aktualisieren

• Ein Logo hinzufügen und Position sowie zugehörige Einstellungen anpassen

Schritt 5: Speichern Sie Ihre angepasste Vorlage

Nachdem Sie alle notwendigen Änderungen vorgenommen haben, klicken Sie auf „Speichern“, um die aktualisierte Vorlage als Ihre eigene zu speichern.

Schritt 6: Vorschau ansehen und Vorlage feinjustieren

Wenn Sie sehen möchten, wie Ihre angepasste Vorlage aussieht, öffnen Sie die Vorschau.

Ausgehend vom Vorschau-Bildschirm können Sie bei Bedarf weiterhin direkt Anpassungen vornehmen und so sicherstellen, dass die Vorlage genau so erscheint, wie Sie es möchten.

Mit einer Vorlage für eine operative Leistungsvereinbarung können Sie:

• Stunden beim Schreiben sparen: Überspringen Sie die leere Seite – mit einer Struktur, die für OLAs gebaut ist.

• Interne Teams ausrichten: Integrierte Felder stellen sicher, dass jedes Team seine Verantwortung kennt.

• Im Brand bleiben: Verwenden Sie Ihr Logo, Ihre Schriftarten und Farben mit dem Trupeer Brand Kit.

• Kunden-SLAs schützen: Starke OLAs verhindern, dass interne Übergaben externe Zusagen brechen.

• Services standardisieren: Verwenden Sie dieselbe OLA-Vorlage für jede interne Vereinbarung.

• Globale Teams erreichen: Übersetzen Sie OLAs mit einem Klick in 65+ Sprachen.

Warum jedes Team seine OLA einhält – und die SLA trotzdem verletzt wird

Das ist das häufigste Muster im Service Management und wirkt wie ein Widerspruch.

Jedes Team meldet „grün“. Das Netzwerk reagiert innerhalb seiner Stunde. Das Applikationsteam löst innerhalb seiner zwei. Der Service Desk triagiert innerhalb von dreißig Minuten. Der monatliche OLA-Compliance-Report lässt sich bequem lesen. Und die Kunden-SLA wird bei einem Drittel der größeren Vorfälle verletzt.

Die Erklärung: OLAs messen die Zeit innerhalb der Teams, während die SLA die Zeit Ende-zu-Ende misst. Die Differenz zwischen diesen beiden Zahlen ist die Transitzeit: das Ticket, das in einer Warteschlange nach der Umverteilung liegt, darauf wartet, abgeholt zu werden, oder für weitere Informationen zurückgewiesen wird.

Diese Zeit gehört zu niemandem. Sie steht nicht in irgendeiner OLA, wird nirgendwo berichtet und ist häufig größer als die gesamte kombinierte Arbeitszeit.

Das bedeutet: Der Ausfall ist strukturell und kein reines Leistungsproblem. Mehr Druck auf die Teams, ihre bestehenden Zahlen einzuhalten, hilft nicht, weil sie sie bereits einhalten.

Die OLA steuert die Übergabe – nicht die Arbeit

Der Perspektivwechsel, der das behebt, ist klein – und er verändert, wofür das Dokument gedacht ist.

Eine OLA, die auf die übliche Weise geschrieben wird, verpflichtet ein Team dazu, wie lange seine eigene Arbeit dauert. Das ist der Teil, den das Team kontrolliert – also ist es der Teil, den es bereit ist zu unterschreiben. Und es ist das am wenigsten nützliche, um sich zu einigen, weil es nie die Variable war.

Eine gut geschriebene OLA verpflichtet Teams dazu, die Schnittstelle zwischen ihnen abzudecken. Was muss in einem Ticket enthalten sein, bevor es übergeben wird. Wie lange das empfangende Team Zeit hat, es aufzunehmen. Was passiert, wenn das Ticket unvollständig ist. Wer das Ticket in der Lücke besitzt.

Sobald die Übergabe zum Thema wird, werden die beiden fehlenden Felder offensichtlich. Eintrittskriterien, also was wahr sein muss, bevor die Uhr des empfangenden Teams startet. Und eine explizite Zuweisung der Transitzeit selbst, sodass die Lücke zwischen den Teams eine Zahl von jemandem ist – statt die von niemandem.

Alles andere in einer OLA-Vorlage ist Administration. Diese beiden sind das Dokument.

Eintrittskriterien: Was muss wahr sein, bevor die Uhr startet

Das zerstörerischste Verhalten in einer Kette mit mehreren Teams ist das Zurückweisen: Ein Ticket kommt ohne ausreichende Informationen an, das empfangende Team gibt es zurück, und seine Uhr wird zurückgesetzt.

Zurückweisen ist aus Sicht des empfangenden Teams völlig rational. Es können nicht am Ticket gearbeitet werden, und die Compliance wird an der eigenen Lösungszeit gemessen – daher schützt das Zurückgeben beide Seiten. Außerdem ist es der Ort, an dem ein großer Anteil der verstrichenen Zeit entsteht, und es ist in jedem Report unsichtbar, der Teams getrennt misst.

Eintrittskriterien beheben das, indem die Verpflichtung nach oben verlagert wird. Jede OLA-Zeile listet die spezifischen Felder auf, die für dieses Team ausgefüllt sein müssen, damit es die Arbeit akzeptiert. Bei einer Übergabe im Netzwerk könnte das der Gerätename, der Standortcode, der exakte Fehltext, die Zeit der ersten Beobachtung und ob andere Nutzer betroffen sind, sein. Bei einer Übergabe in der Applikation könnte es der Nutzer, die Transaktionsreferenz, die Schritte zur Reproduktion und ein Screenshot sein.

Dann ändert sich die Formulierung des Commitments des sendenden Teams. Nicht „Triagieren innerhalb von dreißig Minuten“, sondern „ein Ticket übergeben, das die Eintrittskriterien innerhalb von dreißig Minuten erfüllt“. Dieselbe Uhr, andere Verpflichtung – und der Anreiz sitzt nun bei dem Team, das die Informationen tatsächlich zusammentragen kann.

Das empfangende Team behält das Recht, abzulehnen, und dieses Recht sollte eng gefasst sein: Eine Ablehnung ist nur gültig, wenn ein benanntes Eintrittskriterium wirklich fehlt, und jede Ablehnung wird mit dem Grund protokolliert. Das Logging macht aus dem Zurückweisen eine unsichtbare Gewohnheit eine Zahl, die jemand erklären muss.

Kostenlose Vorlage für eine operative Leistungsvereinbarung: die Struktur zum Kopieren

Kopieren Sie von hier. Felder, die mit einem Sternchen markiert sind, sind die, die Standardvorlagen auslassen.

Header. OLA-Referenz und Version. Parteien, also die beiden Teams namentlich. Die SLA oder der Service, den sie unterstützt. Gültigkeitsdatum, Review-Datum und der benannte Owner auf jeder Seite.

Scope. Welche Services, Systeme oder Anfragetypen das abdeckt, und explizit, was es nicht abdeckt.

Servicezeiten. Abdeckung für jede Partei, einschließlich Regelungen außerhalb der Geschäftszeiten und wie sie sich unterscheiden. Nicht übereinstimmende Servicezeiten zwischen zwei Teams in derselben Kette sind eine häufige und still tödliche Lücke.

Commitments-Tabelle. Eine Zeile pro Anfragetyp oder Priorität, mit: dem Auslöser, den Eintrittskriterien, Reaktionszeit, Lösungs- oder Rückgabezeit, der zugewiesenen Transitzeit und dem Eskalationspunkt.

Eskalation. Wer in jeder Phase kontaktiert wird, über welchen Weg, und nach wie lange. Fügen Sie den Pfad außerhalb der Geschäftszeiten hinzu.

Abhängigkeiten. Was dieses Team von anderen benötigt, einschließlich eines ggf. zugrunde liegenden Vertrags mit einem Dritten, mit eigenen Zeiten, die notiert sind, damit die Rechnung geprüft werden kann.

Messung. Was gemessen wird, aus welchem System, von wem und wie oft es berichtet wird. Fügen Sie Zurückweisungsrate neben Antwort- und Lösungszeit hinzu, da es die Kennzahl ist, die zeigt, ob die Eintrittskriterien funktionieren.

Ausnahmen. Vereinbarte Umstände, unter denen die Commitments nicht gelten, z. B. während eines erklärten größeren Vorfalls oder bei einem Change Freeze.

Review. Daten und was ein Review außerhalb des regulären Zyklus auslöst.

Kopieren Sie bis hierher. Halten Sie es auf zwei oder drei Seiten. Eine OLA, die lang genug ist, um zweimal gelesen werden zu müssen, wird während eines Vorfalls nicht konsultiert – und während eines Vorfalls ist es genau dann wichtig.

So prüfen Sie, ob die OLAs wirklich zur SLA aufaddieren

Bevor Sie irgendetwas unterschreiben, machen Sie die Rechnung. Das dauert fünfzehn Minuten und wird fast überall übersprungen, weil die OLAs Tag für Tag einzeln mit unterschiedlichen Teams ausgehandelt werden.

Zwei Regeln machen das nützlich. Die Transitzeit muss als eigene Zeile auftauchen, weil das der ganze Punkt ist. Und jede Kette braucht Puffer, weil eine Kette, die sich exakt zur SLA aufsummiert, verletzt wird, sobald irgendetwas auch nur leicht schiefgeht. Zehn bis fünfzehn Prozent sind ein angemessener Spielraum.

Wenn die Summe die SLA überschreitet, haben Sie drei ehrliche Optionen: die SLA neu verhandeln, die Zeit eines Teams mit etwas reduzieren, das es möglich macht, oder eine Übergabe entfernen. Was Sie nicht tun können: OLAs unterschreiben, die eine Verletzung garantieren, und dann die Performance dagegen steuern. Genau in dieser Position befinden sich überraschend viele Service Desks.

Der Retailer, dessen Transitzeit länger war als seine Arbeit

Die Rendlesham Group betreibt mehrere Retail-Marken mit etwa sechstausend Mitarbeitenden und einem internen IT-Service-Desk, der Stores und Head Office unterstützt.

Ihre P2-Incident-SLA gegenüber dem Unternehmen betrug vier Stunden bis zur Lösung. Die Verletzungsrate bei P2 lag seit zwei Jahren bei rund achtunddreißig Prozent. Die OLA-Compliance jedes Teams wurde monatlich gemeldet und jedes Team war „grün“.

Irgendjemand hat schließlich jede Zustandsänderung bei hundertzwanzig verletzten P2-Vorfällen zeitgestempelt.

Die mittlere gesamte verstrichene Zeit betrug sechs Stunden und einundfünfzig Minuten. Davon entfielen drei Stunden und zwölf Minuten auf Zeit innerhalb eines Teams, das aktiv am Ticket gearbeitet hat. Drei Stunden und neununddreißig Minuten waren Transit: in einer Warteschlange nach der Umverteilung sitzen, darauf warten, abgeholt zu werden, oder zurückgewiesen werden.

Mehr als die Hälfte der verstrichenen Zeit bei einem verletzten Vorfall gehörte zu niemandem und wurde nirgendwo gemeldet.

Der größte einzelne Beitrag kam vom Zurückweisen. Einundvierzig der hundertzwanzig Tickets waren mindestens einmal von einem empfangenden Team wegen unzureichender Informationen zurückgegeben worden, und jedes Zurückweisen fügte zusätzlich eine mittlere Dauer von einer Stunde und zwanzig Minuten hinzu sowie die Uhr dieses Teams zurückzusetzen. Die zwei häufigsten Gründe waren kein angehängter Fehltext oder Screenshot und keine Bestätigung, welches Store der Vorfall betraf.

Die Änderungen waren eng gefasst. Eintrittskriterien wurden in jede OLA-Zeile geschrieben. Das Commitment des Service Desks wurde von „Triage innerhalb von dreißig Minuten“ auf „ein Ticket übergeben, das die Eintrittskriterien innerhalb von dreißig Minuten erfüllt“ umformuliert. Pro Übergabe wurden fünfzehn Minuten Transitzeit zugewiesen und gegen das empfangende Team angerechnet, sobald die Eintrittskriterien erfüllt waren. Und jedes Zurückweisen wurde mit einem Grund protokolliert.

In den folgenden zwei Quartalen sank die Zurückweisungsrate von vierunddreißig Prozent der P2s auf neun. Die mittlere Transitzeit sank von drei Stunden und neununddreißig Minuten auf eine Stunde und sechs Minuten. Die P2-Verletzungsrate sank von achtunddreißig Prozent auf elf.

Die interne Lösungszeit eines Teams änderte sich nicht wesentlich. Niemand arbeitete schneller. Die Zeit, die zuvor zu niemandem gehört hatte, wurde einfach jemandem zugeordnet.

So entwerfen Sie eine operative Leistungsvereinbarung – Schritt für Schritt

Starten Sie bei der SLA, nicht bei einer Vorlage. Schreiben Sie auf, was dem Kunden versprochen wurde, Ende-zu-Ende, inklusive Definition der Uhr.

Karten Sie die Kette ab. Jedes Team, das in dieser Reihenfolge einen Anfragetyp berührt, einschließlich jedes Dritten. Zeichnen Sie die Übergaben als eigene Schritte, nicht als Pfeile.

Fragen Sie für jede Übergabe das empfangende Team eine Sache: Was brauchen Sie im Ticket, um mit der Arbeit zu beginnen, ohne es an uns zurückzugeben. Diese Antwort, aufgeschrieben, sind Ihre Eintrittskriterien. Teams können das meist schnell und präzise beantworten – und die meisten wurden noch nie danach gefragt.

Jetzt Zeiten vereinbaren – innerhalb der obigen Rechnung, nicht Team für Team. Das als ein einziges Gespräch mit allen Beteiligten zu machen, dauert eine Stunde und verhindert das Summenproblem vollständig.

Weisen Sie die Transitzeit explizit zu und entscheiden Sie, wer sie verantwortet. Fünfzehn Minuten pro Übergabe sind ein sinnvoller Startpunkt, und sie sollte gegen das empfangende Team angerechnet werden.

Vereinbaren Sie die Messung, einschließlich Zurückweisungsrate, und woher sie kommt. Wenn Ihre Tools das nicht liefern können, ist das eine wichtige Erkenntnis, bevor Sie unterschreiben – statt beim ersten Review.

Führen Sie es dann ein Quartal lang durch, bevor Sie es formal festschreiben. Erste Versionen sind meist an ein oder zwei Stellen falsch, und es ist einfacher, sie zu korrigieren, bevor Unterschriften existieren.

Häufige OLA-Fehler und was jeder einzelne kostet

Teams messen und nicht die Kette. Alle sind „grün“ und die SLA wird trotzdem verletzt. Das häufigste Scheitern und das Thema dieser Seite.

Keine Eintrittskriterien. Zurückweisen wird zur rationalen Verteidigung des empfangenden Teams, und die verstrichene Zeit wächst unsichtbar.

Zeiten, die sich nicht aufaddieren. Die OLA-Definition garantiert eine Verletzung, und niemand hat sie jemals durchgerechnet.

Nicht übereinstimmende Servicezeiten. Ein Team deckt bis sechs ab, das nächste bis fünf. Alles, was nach fünf ankommt, liegt über Nacht, was kein Report zeigt, weil beide Teams innerhalb ihrer Zeiten sind.

SLA-Formulierungen in eine OLA kopieren. Penalties, Credits und rechtliche Formulierungen gehören hier nicht hinein, und wenn man sie importiert, verhandeln Teams defensiv statt ehrlich.

Eine OLA mit einem Dritten schreiben. Wenn Geld den Besitzer wechselt, ist es ein zugrunde liegender Vertrag und braucht Procurement und Legal – nicht eine Vorlage. Unsere IT procurement policy template deckt den Genehmigungsweg ab.

Unterschreiben und ablegen. Eine OLA, die niemand prüft, beschreibt eine Service-Kette, die innerhalb von etwa einem Jahr nicht mehr existiert.

So verwalten und reviewen Sie OLAs, sobald sie existieren

Berichten Sie die Kette, nicht die Komponenten. Eine Zahl ist entscheidend: die Ende-zu-Ende-Performance gegenüber der SLA. Und die OLA-Kennzahlen existieren, um das zu erklären – nicht, um alleine zu stehen.

Review vierteljährlich, mit allen Parteien im Raum. Bilaterale Reviews reproduzieren das ursprüngliche Problem, weil die Lücken zwischen den Parteien liegen, die nie im selben Gespräch sind.

Beobachten Sie drei Dinge. Die Zurückweisungsrate nach Übergabe, die Ihnen zeigt, wo die Eintrittskriterien nachgebessert werden müssen. Die Transitzeit nach Übergabe, die zeigt, wo sich Warteschlangen bilden. Und der Anteil der Vorfälle, die einen Pfad genommen haben, den die OLA nicht beschreibt – das zeigt, dass das Dokument von der Realität abgedriftet ist.

Lösen Sie ein Review außerhalb des regulären Zyklus aus, wenn ein Team sich reorganisiert, wenn ein System zwischen Teams wechselt, wenn ein neuer Dritter in die Kette eintritt oder wenn sich die SLA ändert. Alle vier Ereignisse passieren häufiger als der jährliche Review-Zyklus annimmt.

OLA, SLA oder zugrunde liegender Vertrag: Was brauchen Sie?

Wenn das Commitment gegenüber jemandem außerhalb Ihrer Delivery-Organisation gilt – egal ob externer Kunde oder internes Business Unit, das bedient wird – dann ist es eine SLA.

Wenn es zwischen zwei Teams innerhalb derselben Organisation ist, ohne dass Geld den Besitzer wechselt, dann ist es eine OLA.

Wenn es mit einem Lieferanten unter einer kommerziellen Vereinbarung ist, dann ist es ein zugrunde liegender Vertrag und braucht Legal und Procurement statt dieser Vorlage.

Der knifflige Fall ist das Shared Service Center oder ein internes Team mit einem Chargeback-Modell, das zwischen einer OLA und einer SLA liegt. Die praktische Antwort ist, es als OLA zu schreiben und jede Sprache über Penalties zu entfernen, weil interne Penalty-Regime zuverlässig defensives Verhalten erzeugen – und schlechteren Service.

Für die kundenorientierten Definitionen und Antwortformulierungen, die oben auf all dem liegen, decken unsere help desk response template und ticket and resolution template die Ebene ab, die der Endnutzer tatsächlich sieht.

Kann ich eine OLA-Vorlage in Word oder Excel bekommen?

Word für die Vereinbarung, weil Scope, Ausnahmen und Review-Abschnitte Fließtext sind und das Dokument zur Freigabe für die Unterschrift zirkuliert.

Excel für zwei Teile speziell. Die Commitments-Tabelle, in der Sie die Eintrittskriterien, Zeiten und Transit-Zuweisung in Spalten haben möchten, die Sie sortieren und prüfen können. Und das Rechenblatt, in dem jede Kette gegen ihre SLA aufsummiert und alles markiert wird, dem es an Puffer fehlt. Dieses zweite Blatt ist das, das sich lohnt, zuerst zu bauen, weil es oft verändert, was Sie eigentlich vereinbaren wollten.

PDF für die unterschriebene Version, exportiert aus der Quelle. Behalten Sie die Arbeitsversion bearbeitbar, weil die Eintrittskriterien nach dem ersten Quartal echter Zurückweisungen angepasst werden müssen.

So halten Sie OLA und Realität synchron

Eine OLA beschreibt eine Kette von Arbeit, die sich ständig verändert. Teams reorganisieren sich, Systeme wechseln, Tools ändern sich – und das Dokument ist das letzte, das irgendjemand aktualisiert.

Der Teil, der am schnellsten veraltet, sind die Eintrittskriterien, weil sie beschreiben, was ein Ticket enthalten muss – und was ein Ticket enthalten muss, hängt davon ab, wie das aktuelle Tooling und der aktuelle Prozess tatsächlich funktionieren.

Trupeer AI hilft dabei, indem es die zugrunde liegenden Prozeduren günstig hält, um sie aktuell zu machen. Zeichnen Sie den Triage- oder Übergabeprozess einmal auf, und Sie erhalten eine schriftliche Prozedur mit den Schritten und Screens, die der Service Desk befolgen kann und die klar zeigt, welche Informationen gesammelt werden. Wenn sich das Tooling ändert, erneut aufzeichnen statt neu schreiben.

Aufzeichnen. Gebrandet. Übersetzen. Trupeer.

Der SOP creator deckt die Prozeduren ab, von denen die OLA abhängt, und unsere IT SOP template zeigt, wie Sie entscheiden, welche davon es wert sind, gepflegt zu werden. Documentation hält die Vereinbarungen und Prozeduren zusammen, und Setup-Anweisungen finden Sie im document template setup guide.

Häufig gestellte Fragen

Gibt es eine kostenlose Vorlage für eine operative Leistungsvereinbarung in Word?

Die Struktur oben lässt sich direkt in Word oder Google Docs einfügen – inklusive der Eintrittskriterien und Transit-Zuweisungsfelder, die Standardvorlagen auslassen. Es gibt keinen gesicherten Download und kein Formular. Halten Sie die Commitments-Tabelle in einer Tabelle (Spreadsheet) und referenzieren Sie sie, denn dieser Teil muss sortiert und aufsummiert werden.

Gibt es eine kostenlose Vorlage für eine operative Leistungsvereinbarung in PDF?

Exportieren Sie die unterschriebene Version einmal als PDF, nachdem die Parteien sie vereinbart haben, und behalten Sie die Arbeitskopie bearbeitbar. Eintrittskriterien müssen fast immer nach dem ersten Quartal angepasst werden, sobald Sie sehen können, wofür Tickets tatsächlich zurückgewiesen werden.

Gibt es eine kostenlose Vorlage für eine operative Leistungsvereinbarung in Excel?

Excel ist der richtige Ort für die Commitments-Tabelle und für den Rechencheck. Eine Tabelle mit einer Zeile pro Übergabe und einem laufenden Gesamtwert gegenüber der SLA, die jede Kette mit weniger als zehn Prozent Puffer markiert. Wenn Sie dieses Blatt erstellen, bevor Sie verhandeln, verändert sich häufig, was am Ende verhandelt wird.

Wo finde ich ein Beispiel für eine OLA als PDF?

Mehrere ITSM-Anbieter und Regierungsstellen veröffentlichen OLA- und SLA-Vorlagen als Dokumente, und sie sind für die Struktur in Ordnung. Lesen Sie sie für die Abschnitte, nicht für den Inhalt, denn die Commitments in jedem veröffentlichten Beispiel sind die Kette von jemand anderem – und die Zeiten sind außerhalb der SLA, für die sie gebaut wurden, bedeutungslos.

Wer unterschreibt eine operative Leistungsvereinbarung?

Der benannte Owner auf jeder Seite, der der Manager sein sollte, der für die Delivery dieses Teams verantwortlich ist – nicht eine Funktion im Service Management. Eine OLA, die nur vom Service Management unterschrieben wird, ist eine Absichtserklärung, weil die Person, die dafür Ressourcen bereitstellen muss, nicht im Raum war.

Wie viele OLAs braucht ein Service Desk?

Weniger als die meisten Teams erwarten. Eine pro Team-Paar, das regelmäßig Arbeit austauscht, und die alle Anfragetypen in einer einzigen Commitments-Tabelle abdeckt – statt eine pro Service. Ab etwa einem Dutzend wird die Pflege zur Einschränkung, und die Dokumente veralten schneller, als sie reviewt werden.

Sollte eine operative Leistungsvereinbarung Penalties enthalten?

Nein. Es gibt keine rechtliche Beziehung, um sie durchzusetzen, und interne Penalty-Regime erzeugen zuverlässig defensives Verhalten: Teams lehnen Arbeit ab, streiten über den Start der Uhr und optimieren für ihre eigene Zahl statt für das Ergebnis. Berichten Sie stattdessen die Kette Ende-zu-Ende, wodurch die gemeinsame Konsequenz sichtbar wird, ohne dass jemand bestraft wird.

Wie oft sollten OLAs reviewed werden?

Vierteljährlich mit allen Parteien vor Ort – plus ein Review außerhalb des regulären Zyklus, sobald sich ein Team reorganisiert, ein System zwischen Teams wechselt, ein Dritter in die Kette eintritt oder sich die zugrunde liegende SLA ändert. Der vierteljährliche Rhythmus fängt Abdrift ab, und die Auslöser fangen die Änderungen ein, die das Dokument über Nacht falsch machen.