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.