Umowa operacyjna (OLA) to wewnętrzne porozumienie między działami lub zespołami w organizacji, określające zasady współpracy niezbędne do świadczenia usług IT. Dokument ten precyzuje role, odpowiedzialności oraz parametry jakościowe, które muszą być spełnione przez poszczególne jednostki organizacyjne.

OLA stanowi kluczowy element zarządzania usługami IT, uzupełniając Service Level Agreement (SLA). Podczas gdy SLA określa zobowiązania wobec klientów zewnętrznych, OLA reguluje współpracę wewnętrzną niezbędną do realizacji tych zobowiązań. Dokument ten definiuje między innymi:

• Czasy reakcji i rozwiązywania problemów między zespołami
• Standardy komunikacji i eskalacji
• Wskaźniki wydajności dla procesów wewnętrznych
• Zakresy odpowiedzialności poszczególnych działów

W praktyce IT Service Management (ITSM), OLA zapewnia, że zespoły takie jak Service Desk, administracja systemów czy rozwój oprogramowania działają w skoordynowany sposób. Przykładowo, gdy zespół wsparcia zobowiązuje się w SLA do rozwiązania incydentu w ciągu 4 godzin, OLA określa, że zespół infrastruktury musi dostarczyć niezbędne informacje diagnostyczne w ciągu 1 godziny.

Wdrożenie OLA przynosi wymierne korzyści: redukuje konflikty między zespołami, przyspiesza rozwiązywanie problemów oraz poprawia ogólną jakość usług IT. Jest to szczególnie istotne w organizacjach stosujących metodyki takie jak DevOps, gdzie współpraca między zespołami jest fundamentem sukcesu.

OLA, SLA i UC – trzy poziomy umów w ITSM

W zarządzaniu usługami IT funkcjonują trzy powiązane rodzaje umów, które razem tworzą hierarchię wsparcia. SLA wyznacza zobowiązania wobec klienta, OLA opisuje wewnętrzne zobowiązania operacyjne wspierające to SLA, a UC (Underpinning Contract) wiąże zewnętrznych dostawców z wymaganymi poziomami wsparcia. Gdy cele w tych dokumentach są niespójne, ryzykujesz automatyczne naruszenie SLA wobec klienta.

• SLA – umowa zewnętrzna między dostawcą a klientem; określa mierzalne poziomy usług widoczne dla odbiorcy;
• OLA – umowa wewnętrzna między zespołami tej samej organizacji; niewidoczna dla klienta końcowego;
• UC – prawnie wiążący kontrakt z zewnętrznym dostawcą lub podwykonawcą dostarczającym komponenty usługi.

Różnica konsekwencji jest istotna. Naruszenie UC pociąga skutki prawne i finansowe wobec strony zewnętrznej, natomiast złamanie OLA skutkuje wewnętrzną odpowiedzialnością operacyjną, która może przełożyć się na naruszenie SLA i kary umowne wobec klienta. Więcej o poziomach umów znajdziesz w Service Level Agreement (SLA), OLA, Underpinning Contract (UC) – Matrix42 Docs.

OLA w ITIL – miejsce umowy operacyjnej w bibliotece dobrych praktyk

W ITIL v3 OLA jest wymagane w ramach procesu Service Level Management, w fazie Service Design, i wykorzystywane w Service Operation. ITIL 4 zachowuje tę rolę w praktyce Service Level Management, podkreślając, że umowy muszą być wspierane przez ludzi, partnerów i technologię działających w spójnych strumieniach wartości. Badanie akademickie z 2020 roku (Wiranti i in., ICIC) potwierdziło, że pełne wdrożenie Service Level Management wymaga trzech dokumentów: SLR (Service Level Requirement), SLA oraz OLA.

ITIL 4 zaleca też łączenie klasycznych metryk technicznych z metrykami doświadczenia użytkownika (XLA) i wskaźnikiem satysfakcji CSAT. Chodzi o uniknięcie efektu arbuza, w którym dashboardy świecą na zielono, a użytkownicy pozostają niezadowoleni.

Przykładowa struktura dokumentu OLA – co powinien zawierać

Dobrze przygotowany dokument OLA porządkuje współpracę w kilku obowiązkowych sekcjach:

• zakres usługi i strony umowy z nazwami zaangażowanych zespołów;
• cele i mierzalne poziomy usług z konkretnymi wartościami KPI;
• role i odpowiedzialności każdej ze stron;
• procedury eskalacji oraz zasady raportowania i monitoringu;
• postanowienia o ciągłości i odtwarzaniu usług;
• sekcja zatwierdzeń, wersja i kontrola zmian dokumentu.

Gotowe listy kontrolne dla takiej struktury znajdziesz w Checklist SLA OLA – IT Process Wiki (ITIL).

Proces tworzenia OLA – od projektu do wdrożenia

Tworzenie OLA inicjuje zazwyczaj Service Level Manager lub właściciel procesu ITSM, opierając się na istniejących lub planowanych SLA. Dane wejściowe to katalog usług, wymagania klientów (SLR) oraz mapa zależności między zespołami zestawiona z aktualnymi możliwościami operacyjnymi grup wsparcia. Cykl życia dokumentu ma pięć etapów:

• inicjacja i zbieranie wymagań;
• opracowanie treści i negocjacje między kierownikami zespołów;
• formalne zatwierdzenie i publikacja pod kontrolą zmian;
• użytkowanie operacyjne z monitoringiem KPI;
• cykliczny przegląd, aktualizacja lub wycofanie przy zmianie struktury albo zakresu usług.

Negocjacje prowadzą kierownicy zaangażowanych zespołów wewnętrznych (helpdesk, infrastruktura, bezpieczeństwo) pod nadzorem Service Level Managera. Przed wdrożeniem dokument musi zostać formalnie podpisany przez wszystkie strony i objęty change control. W małej organizacji z dojrzałymi procesami cały cykl zamyka się w kilka tygodni, a w dużym środowisku z wieloma grupami wsparcia negocjacje potrafią trwać od 2 do 6 miesięcy.

FAQ

Co to jest OLA?

OLA to skrót od Operational Level Agreement, czyli umowa na poziomie operacyjnym. To wewnętrzny dokument między dostawcą usług IT a innym działem tej samej organizacji, który precyzuje odpowiedzialności i czasy reakcji potrzebne do dostarczenia usługi klientowi.

Czym różni się OLA od SLA?

• strony umowy – SLA łączy dostawcę z klientem, OLA łączy zespoły wewnętrzne;
• cel – SLA opisuje poziom usługi dla odbiorcy, OLA opisuje, jak zespoły współpracują, aby ten poziom osiągnąć;
• widoczność – SLA jest widoczne dla klienta, OLA pozostaje wewnętrzne;
• konsekwencje – naruszenie SLA grozi karami umownymi, naruszenie OLA rodzi odpowiedzialność operacyjną.

Czym jest UC i jak ma się do OLA?

UC (Underpinning Contract) to trzeci poziom umów w ITSM: prawnie wiążący kontrakt z zewnętrznym dostawcą lub podwykonawcą. Różni się od OLA tym, że dotyczy strony zewnętrznej, podczas gdy OLA reguluje współpracę zespołów wewnętrznych.

Jakie KPI stosuje się w OLA?

Najczęściej mierzysz średni czas reakcji na zgłoszenie, średni czas rozwiązania incydentu (MTTR) oraz dostępność usługi. Uzupełniają je wskaźnik rozwiązania przy pierwszym kontakcie, wskaźnik ponownego otwarcia zgłoszeń i koszt obsługi jednego zgłoszenia. Szczegóły znajdziesz w haśle Key Performance Indicator (KPI).

Czy OLA jest wymagane przez ITIL?

Tak. W ITIL v3 OLA jest częścią procesu Service Level Management, a ITIL 4 utrzymuje je w praktyce Service Level Management. Bez OLA trudno powiązać wewnętrzne zobowiązania zespołów z poziomami usług obiecanymi klientowi w SLA.