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?

Artykuł OLA – czy ktoś ją kiedyś widział? pochodzi z serwisu Mariusz Siek.

ITIL a model usługowy

ITIL już w 2007 roku wprowadził model usługowy prezentując trzecią wersję najlepszych praktyk w zarządzaniu usługami IT. Model ten zakłada, że usługa jest podstawowym elementem w zarządzaniu usługami IT. W tym celu został stworzony cykl życia usługi, który pokazuje etapy jej funkcjonowania od strategii, przez projektowanie i wytwarzanie, po wdrożenie, utrzymanie operacyjne aż po ciągłą jej poprawę. W ten sposób ITIL nie skupia się tylko na wdrożeniu i utrzymaniu usług ale wskazuje potrzebę zaangażowania na etapie strategii, projektowania i tworzenia usług oraz ich ciągłego doskonalenia.

Dlaczego więc 10 lat po wprowadzeniu tego innowacyjnego podejścia nadal wiele organizacji nie stosuje tych praktyk u siebie? Postaram się pokazać najważniejsze problemy i wskazać dla nich rozwiązania.

Strategia

Pierwszym etapem w cyklu życia usługi jest Strategia. Jest ona elementem przygotowywanym przez najwyższe kierownictwo organizacji (zarząd, dyrektorzy) i na tym poziomie nikt nie patrzy oczami usług tylko celów biznesowych, planów sprzedażowych, KPI. Poziom dyskusji jest na tak wysokim poziomie, że nie jest to właściwe miejsce do spojrzenia usługowym modelem. Jestem w stanie nawet zaakceptować takie podejście chociaż uważam, że w jakimś stopniu ten czynnik usługowy powinien być uwzględniony. Zarząd powinien wspierać się wiedzą managerów usług IT, którzy mają potrzebne kompetencje i doświadczenie i są w stanie przełożyć wysoko poziomową strategię na usługi.

Projektowanie i wytwarzanie

Kolejnym etapem w cyklu życia usługi jest projektowanie i wytwarzanie usług, w ramach którego większość organizacji nie myśli nadal usługowo. Powoływane są projekty, które mają za zadanie dostarczyć określone produkty, którymi najczęściej są aplikacje, systemy i rozwiązania, które nie koncentrują się na usługach dla użytkownika. Ponieważ nie mamy usług to nie są definiowane dla nich wymagania SLA, co oznacza że na etapie wytwarzania nikt nie myśli jak usługi będą działać po wdrożeniu na produkcję. Menedżerowie usług IT nie uczestniczą od początku w realizacji projektu i definiowaniu wymagań tylko są traktowani jako zło konieczne i angażowani na krótko przed wdrożeniem produkcyjnym, gdy podstawowe założenia są już określone i produkty są już w zaawansowanym stanie. Wtedy oczekuje się, że Service Level Manager zdefiniuje usługi, określi dla nich SLA i zweryfikuje wymagania podczas testów niefunkcjonalnych (wydajność, pojemność, dostępność). Nie ma w projekcie zaplanowanych zasobów na realizację testów niefunkcjonalnych i zaczyna się przepychanka, kto je wykona.

Czy można temu zaradzić oczywiście, że tak. Jak to zrobić?

• Powołać w projekcie rolę Service Level Managera, który od jego początku będzie uczestniczył w definiowaniu wymagań SLA (niefunkcjonalnych)

• Traktować wymagania niefunkcjonalne tak samo jak wymagania funkcjonalne, zapewniając zasoby projektu do ich opracowania i weryfikacji

• Zaplanować testy wymagań niefunkcjonalnych i uwzględnić przez projekt, zasoby potrzebne do ich przeprowadzenia

Wdrożenie

Kolejnym etapem w cyklu życia usługi jest wdrożenie usług na produkcję. Tu jest trochę lepiej jednak nadal nie wdrażamy usług tylko aplikacje, systemy, pakiety itp. Nie przekazujemy wiedzy o przygotowanym rozwiązaniu z zespołów wytwórczych do zespołów utrzymania. Jeżeli działamy w modelu DevOps to jeszcze mamy szansę na odpowiednie obsługiwanie błędów z produkcji ale przy innym podejściu do utrzymania już raczej szanse są minimalne. Nie jest tworzona w trakcie wytwarzania, baza znanych błędów i nie jest ona przekazywana do utrzymania.

Co można zrobić aby było lepiej?

• Rejestrować i procesować zmiany (Change Request) do usług a nie systemów

• Utworzyć bazę wiedzy i znanych błędów na etapie wytwarzania i przekazać do utrzymania w ramach wdrożenia

• Zaangażować osoby z utrzymania na etapie wytwarzania w celu lepszego poznania rozwiązania, które będzie wdrażane na produkcję

Utrzymanie operacyjne

Na tym etapie również nie lubimy modelu usługowego. Zespoły utrzymania odpowiadają za działania aplikacji i systemów, które składają się na usługi. Często jest tak, że dwa lub więcej zespołów odpowiada za aplikacje i systemy wchodzące w skład jednej usługi. W przypadku nie działania usługi lub jej niepoprawnego działania nie ma podejścia usługowego tylko każdy zespół sprawdza u siebie i wskazuje na inny zespół, że problem jest po ich stronie. Brak jest właściciela usługi (Service Manager/Owner) po stronie zespołów utrzymania, który by odpowiadał całościowo za jej działanie. Użytkownicy zgłaszają błędy do aplikacji a nie usług. Narzędzia wspierające obsługę zgłoszeń (ITSM) nie są skonfigurowane pod usługi tylko aplikacje/systemy.

Jak to zmienić?

• Powołać rolę Service Managera/Ownera, który w IT będzie odpowiadał za działanie usługi, niezależnie z jakich składa się aplikacji i systemów

• Zdefiniować w narzędziu ITSM usługi zamiast aplikacja i systemy

• Przeprowadzić kampanię edukacyjną wśród użytkowników z usługowego podejścia

Ciągła poprawa

Ten etap jest często pomijany i nie wykorzystywany. Duża ilość błędów na produkcji, niewystarczające zasoby ludzkie do ich naprawiania i ciągła presja czasu powodują, że nie ma kiedy i kim przeprowadzać ciągłą poprawę usługi.

Tutaj nie ma złotego środka. Trzeba przygotować Plan Poprawy Usługi (Service Improvement Plan), w takim zakresie, który pozwoli posiadanym zasobom ludzkim realizować go w ramach swoich obowiązków lub zwiększyć skład osobowy zespołów aby mogły wykonywać zadania związane z poprawą usług.

Mam nadzieję, że zwiększanie świadomości o potrzebie usługowego podejścia w IT zaowocuje zmianą percepcji na wszystkich etapach cyklu życia usługi, co będzie z korzyścią zarówno dla Biznesu i Użytkowników usług jak i działów IT dostarczających te usługi.

Artykuł Model usługowy – Dlaczego organizacje go nie wykorzystują? pochodzi z serwisu Mariusz Siek.