W ostatnim czasie bardzo dużo pisałem o katalogu usług i SLA, ponieważ według mnie są to najważniejsze elementy w zarządzaniu usługami IT. Wykorzystujemy je w relacjach zewnętrznych biznesu z IT. Jednak gdy już je mamy opracowane i uzgodnione pomiędzy biznesem i IT, powinniśmy zadbać również o przełożenie SLA na OLA i Underpinning Contracts (UC). Brak uregulowania wymagań na poziom usług w OLA i/lub UC jest bardzo często przyczyną niedotrzymania SLA z biznesem.

Dlaczego jednak większość organizacji tego nie robi? Dlaczego tak się dzieje? Przybliżę to zagadnie w tej publikacji.

Jak OLA się nazywa?

OLA czyli Operation Level Agreement jest to wewnętrzne porozumienie pomiędzy zespołami IT, które określa jaka jest odpowiedzialność poszczególnych zespołów wewnątrz IT za dotrzymanie SLA przed biznesem. Właściwie, ktoś może powiedzieć po co nam OLA przecież mamy SLA. Czy to nie wystarczy? Odpowiedź brzmi nie.

Dlaczego więc w IT nie lubimy OLA?

• OLA kojarzona jest z formalizmami a tych żaden administrator czy programista nie lubi
• Nie rozumiemy różnicy pomiędzy SLA, OLA i UC
• Zakładamy, że jakoś to będzie, przecież do tej pory dawaliśmy sobie bez tego radę
• Nie wiemy jak OLA mogłaby nam pomóc w codziennej pracy

Poszukajmy, jakie korzyści mamy ze zdefiniowania i wprowadzenia OLA?

• Zespoły IT dowiadują się jakie wymagania (SLA) zostały uzgodnione dla usług, za utrzymanie których odpowiadają
• Dokonujemy podziału odpowiedzialności pomiędzy poszczególne zespoły IT, które świadczą wsparcie
• Uzgadniamy zasady komunikacji pomiędzy zespołami IT
• Definiujemy ścieżki eskalacji, w przypadku sytuacji konfliktowych

Co OLA oznacza w praktyce?

Podejrzewam, że większość z Was nadal nie wie jak OLA zastosować w praktyce. Wyjaśnię to na przykładzie jednego parametru SLA. Tym parametrem jest czas rozwiązania incydentu określony w SLA dla usługi.

Zakładamy, że czas rozwiązania incydentu w SLA wynosi 8 godzin. Co powinniśmy określić w OLA? Większość organizacji wsparcia składa się z trzech linii wsparcia:

• I linia wsparcia stanowi przeważnie Service Desk, do którego incydenty wpadają w pierwszej kolejności
• II linia wsparcia to zespół utrzymania odpowiedzialny z utrzymanie danej usługi (aplikacji)
• III linia wsparcia składa się z zespołu wytwórczego i/lub zespołu infrastruktury

Jak podzielić czas rozwiązania incydentu z SLA, pomiędzy trzy linie wsparcia? Poniżej moja propozycja z komentarzem.

• I linia wsparcia = 1 godzina. Service Desk według ITIL powinien rozwiązywać 70% zgłoszeń od użytkowników. Dodatkowo powinien robić to szybko i sprawnie. Dlatego jeżeli w ciągu 1 godziny nie jest w stanie znaleźć rozwiązania powinien przekazać incydent do II linii wsparcia
• II linia wsparcia = 1 godzina. Zespół utrzymania po otrzymaniu incydentu z Service Desk, bada i diagnozuje incydent w celu znalezienia rozwiązania. Ma większe kompetencje niż Service Desk. Jednak jeżeli w ciągu 1 godziny nie znajdzie rozwiązania lub obejścia powinien przekazać incydent do III linii wsparcia
• III linia wsparcia = 6 godzin. Zespół wytwórczy i/lub zespół infrastruktury w zależności, jakiego obszaru (błąd w kodzie oprogramowania czy niepoprawnie działająca infrastruktura) dotyczy incydent rozwiązuje zgłoszenie.

Czas rozwiązania a eskalacja funkcjonalna

Zaraz, zaraz ktoś powie, jak to I i II linia wsparcia na rozwiązanie mają po 1 godzinie a III linia wsparcia 6 godzin? Coś tu się nie zgadza. Wszystko jest poprawnie, ponieważ mamy w tym przypadku do czynienia z eskalacją funkcjonalną. Jeżeli pierwsza linia wsparcia nie potrafi ustalić przyczyny incydentu w ciągu jednej godziny, musi przekazać zgłoszenie do kolejnej linii wsparcia. Jakby Service Desk umiał rozwiązać incydent miałby 8 godzin aby to zrobić (cały czas rozwiązania z SLA).

Analogicznie II linia wsparcia ma 7 godzin na rozwiązanie incydentu. Jednak jeżeli w ciągu jednej godziny nie znajdzie rozwiązania przekazuje incydent do III linii wsparcia, która ma już tylko 6 godzin na rozwiązanie. Jak widać trzecia linia wsparcia ma nie najdłuższy ale najkrótszy czas na rozwiązanie zgłoszenia.

Dla każdego parametru SLA trzeba przeprowadzić analogiczne ćwiczenie aby ustalić, który zespół wsparcia odpowiada, za jaką część parametru SLA.

Pytanie: Czy stosujesz w swojej organizacji OLA i dla jakich parametrów SLA najczęściej?