CIOPolecane tematy

Czym jest ITIL 4 i w jakim kierunku zmienia się ta biblioteka najlepszych praktyk

Information Technology Infrastructure Library (ITIL) ma początek w latach 80. XX w. W roku 2007 ujrzała światło dzienne, najczęściej obecnie używana przez profesjonalistów IT, wersja 3, a 18 lutego br. ITIL doczekał się 4. wydania. Mamy więc znakomitą okazję, aby przedstawić jego nową odsłonę. Ponieważ najnowsza transformacja jest wyjątkowo znacząca, spróbuję poddać ją analizie, która pozwoli lepiej ją poznać i zrozumieć.

ITIL to biblioteka najlepszych praktyk dotyczących budowy i zarządzania pracą IT. Zasady zostały stworzone przez tysiące osób zaangażowanych w procesy organizacji informatyki – od dostawców, pracowników działów technologicznych, poprzez deweloperów, testerów i konsultantów, po użytkowników i klientów. Proponowany zbiór praktyk nie ma charakteru nakazowego. Można więc stosować go w takim zakresie, na jaki jesteśmy przygotowani, w jakim punkcie rozwoju się znajdujemy, w zależności od potrzeb własnych lub klientów oraz na bazie innych indywidualnych czynników pojawiających się w pracy.

Zrozumienie ITIL umożliwia całościowe spojrzenie na IT, zwłaszcza w 4. aspektach:

  1. organizacji, ludzi, komunikacji i kultury pracy;
  2. wykorzystania i stanu technologii;
  3. współpracowników i dostawców (oceniając ich poziom zależności oraz udział w tworzeniu łańcucha wartości);
  4. jakości istniejących procesów i standardów w firmie.

ITIL jest neutralny jeśli chodzi o rodzaj prowadzonej działalności, wykorzystywaną technologię czy kooperantów. Nie ma znaczenia czy firma jest duża, średnia czy mała. ITIL nie wskazuje czy zarządzanie IT ma odbywać się wewnętrznymi zasobami, czy powinno być outsourcowane, a także czy zasoby IT powinny być duże czy małe, a proces wytwórczy winien odbywać się w wewnątrz organizacji czy na zewnątrz. Zgodnie z pryncypiami prezentowanymi w najnowszej wersji, ITIL 4 koncentruje się na wytwarzaniu wartości i zwiększaniu efektywności działania, bez narażania klienta na nadmiarowe koszty i ryzyka.

Najbardziej widoczne różnice między wersjami ITIL 3 i 4

Do największych mankamentów poprzedniej wersji ITIL należy brak wsparcia dla takich ram projektowych, jak DevOps, Lean czy Agile. Można nawet stwierdzić, że powiązanie usług z procesem wytwórczym oprogramowania było jedynie zarysowane. Stawiało wyraźny podział pomiędzy wytwarzaniem a utrzymaniem (Design – Transition – Operation). Ten podział w nowej wersji został wyraźnie zasypany i zespolony z zastosowaniem podejścia DevOps. W wersji 3. doskwierał również brak jakichkolwiek odwołań do tzw. nowych technologii – Big Data, Cloud Computing, Robotic Process Automation i Machine Learning. Czyli usługi były opisywane w ramach świata, który praktycznie przestaje istnieć.

Nowa odsłona likwiduje „dług technologiczny” po swojej poprzedniczce. Zwiększyła się też rola klienta w całym cyklu życia usługi, wskazano nie tylko konieczność większego angażowania go w cykl utrzymania i rozwoju usług, ale zaangażowanie go już na bardzo wczesnym etapie określania potrzeb, a nie szukania rozwiązań. Ze standardu koncentrującego się na cyklu życia usług, ITIL 4 staje się metodyką skupiającą się na tworzeniu, zarządzaniu i zwiększaniu ich wartości. Nie sądzę, aby znalazł się ktoś próbujący negować takie podejście, gdyż w praktyce tak właśnie patrzy się na usługi, a przecież ITIL to zbiór najlepszych praktyk, a nie zbiór hipotez do wytestowania.

Współtworzenie wartości (Focus on value) dla klienta i użytkownika

Wiele miejsca w ITIL 4 poświęcono tzw. miękkiemu zarządzaniu i kulturze organizacyjnej. Definicja usługi uległa znacznej transformacji. Nie mówimy już o jej dostarczaniu, ale o współtworzeniu jej wartości. To jedna z najbardziej spektakularnych i istotnych zmian. Wartość w znaczeniu ITIL oznacza zarówno efektywność finansową, jak i lojalność klientów, promowanie marki, możliwości rozwoju, zdobywanie nowych rynków, zwiększenie produktywności czy redukcję kosztów. Co ważne, dotyczą nie tylko dostawcy usług, ale wszystkich interesariuszy, w szczególności klientów i użytkowników.

Do największych mankamentów poprzedniej wersji ITIL 3 należy brak wsparcia dla takich ram projektowych, jak DevOps, Lean czy Agile. Można nawet stwierdzić, że powiązanie usług z procesem wytwórczym oprogramowania było jedynie zarysowane. Stawiało wyraźny podział pomiędzy wytwarzaniem a utrzymaniem (Design – Transition – Operation). Ten podział w nowej wersji został wyraźnie zasypany i zespolony z zastosowaniem podejścia DevOps. W wersji 3. doskwierał również brak jakichkolwiek odwołań do tzw. nowych technologii – Big Data, Cloud Computing, Robotic Process Automation i Machine Learning. Czyli usługi były opisywane w ramach świata, który praktycznie przestaje istnieć.

Dlaczego pojęcie wartości w ITIL 4 jest tak szerokie? Dlatego, że przy ocenie wartości usługi poza dającymi się skwantyfikować parametrami i funkcjonalnościami, bardzo istotną rolę odgrywa tzw. doświadczenie klienta i użytkownika (Customer/User Experience), które można zdefiniować jako całość interakcji klienta/użytkownika z organizacją i jej produktami, a zatem jest ona zarówno obiektywna, jak i subiektywna, czyli (notabene) zawiera czwarty postulat manifestu agile mówiącego o ludziach i interakcji pomiędzy nimi.

Aby dać sobie szansę na świadczenie wartościowych usług i dostarczanie prawdziwie efektywnych produktów, należy upewnić się, w jaki sposób klienci korzystają z usługi (jak pomaga im ona w realizacji celów) i „ewangelizować” wszystkich pracowników zarówno w trakcie pracy operacyjnej, jak i inicjatyw doskonalących, jak należy rozumieć wartość i jak ją realizować. Przy tej okazji wyjaśnimy od razu, jak rozumiemy poszczególne role w ramach pojęcia „usługobiorca” (Service Consumer). Klient (Customer) określa wymagania dotyczące usługi i bierze odpowiedzialność za wyniki jej używania, użytkownik (User)korzysta z tych usług w codziennej pracy, zaś sponsor autoryzuje budżet.

Zmiana zaczyna się w miejscu, w którym się znajdujesz (Start where you are)

Nie odkryję Ameryki, jeśli powiem, że nasze czasy są zdominowane przez jedną wiodącą cechę: jest nią stałość, stałość w zmienności! Już ok. 500 lat p.n.e. Heraklit z Efezu opisał koncepcję zmiany jako centralnego elementu świata (ta panta rhei – wszystko płynie). Określił to w słynnych zdaniach: „Niepodobna wstąpić dwukrotnie do tej samej rzeki. Wprawdzie niekiedy rzeczy zdają się trwać, ale trwanie ich jest złudzeniem. Nie ma rzeczy o stałych własnościach; nie ma bytu, jest tylko stawanie się”. Nie mówmy więc o oczywistościach, ale o metodzie, która pozwoli przeprowadzić zmianę w sposób kontrolowany i efektywny. Często zdarza się, że kierując się pozamerytorycznymi względami lub po prostu z braku wiedzy, pojawia się pokusa zmieniania wszystkiego co było wcześniej, aby było coś nowego, by było inaczej.

Bardzo rzadko jest to konieczne i mądre. Z reguły takie podejście skutkuje marnotrawstwem czasu, utratą jakości usług i procesów, a często również cennych zasobów ludzkich. Mam wrażenie, że każdy, kto spotkał się z taką „zmianą”, zgodzi się z tą diagnozą. Jak temu zapobiec? Framework ITIL 4 odpowiada:

  • zanim zaczniesz zmieniać, zobacz, co jest aktualnie dostępne do wykorzystania;
  • aby zrozumieć obecny stan narzędzi, usług czy procesów, trzeba je zmierzyć i obserwować.

Wymaga to rozwagi i obiektywnych kryteriów oceny. W wielu firmach rzeczywistość a cyferki w raportach to dwa różne światy. Wynika to z trudności w dokładnym pomiarze niektórych danych lub niezamierzonego odchylenia lub zniekształcenia danych generowanego przez raporty. Pozyskiwanie danych ze źródła pomaga uniknąć wniosków, które, jeśli okażą się błędne, mogą mieć katastrofalne skutki dla terminów, budżetów, klientów itp. Na koniec warto wspomnieć jeszcze o pomiarach, przy całej ich pożyteczności pamiętajmy o prawie Goodharta – „Kiedy miara staje się celem, przestaje być dobrą miarą”.

Buduj iteracyjnie na podstawie informacji zwrotnych (Progres iteratively with a feedback)

Wraz z tym postulatem wracamy do podstaw Scruma. Iteracyjność oznacza powtarzanie danej sekwencji działań określoną ilość razy, aż do uzyskania pożądanego efektu (wyniku). W naszym przypadku jest to dostarczenie usługi lub produktu. Poprzez dekompozycję zadań i uruchomienie pętli informacji zwrotnej (w Scrum są to nie tylko planowanie, przegląd i retrospekcja, ale przede wszystkim codzienny Daily Scrum i Grooming ), minimalizujemy to, co w pracy informatyka (a na pewno i w każdej innej) jest najgorsze z najgorszych, czyli robienie rzeczy, które później trafiają do kosza. Czy może być coś bardziej demotywującego? Jeśli macie jakieś pomysły, to proszę przesłać je na mój adres e-mailowy (będą nagrody).

Nowa odsłona ITIL 4 likwiduje „dług technologiczny” po poprzedniczce. Zwiększyła się też rola klienta w całym cyklu życia usługi, wskazano nie tylko konieczność większego angażowania go w cykl utrzymania i rozwoju usług, ale zaangażowanie go już na bardzo wczesnym etapie określania potrzeb, a nie szukania rozwiązań. Ze standardu koncentrującego się na cyklu życia usług, ITIL 4 staje się metodyką skupiającą się na tworzeniu, zarządzaniu i zwiększaniu ich wartości. Nie sądzę, aby znalazł się ktoś próbujący negować takie podejście, gdyż w praktyce tak właśnie patrzy się na usługi, a przecież ITIL to zbiór najlepszych praktyk, a nie zbiór hipotez do wytestowania.

Dlatego warto oprzeć się pokusie zrobienia wszystkiego naraz. Dzięki podzieleniu pracy na mniejsze zadania (osobiście uważam, że każde zadanie deweloperskie można zdekomponować w taki sposób, aby istniała możliwość jego realizacji w ciągu jednej dniówki), można zauważyć problemy, opóźnienia, wątpliwości praktycznie w trybie online. Pamiętając jednak o Heraklicie wiemy, że ciągłej ocenie powinny być poddawane nie tylko poszczególne zadania, ale zasadność i kierunek całej inicjatywy, aby dostrzegać wszelkie zmiany wokół nas i mieć pewność, że to co robimy, zbuduje wartość, której oczekujemy.

Wskazówki potrzebne do realizacji tego pryncypium to:

  • praca iteracyjna, ale ze świadomością i zrozumieniem całości;
  • informacja zwrotna, jak najczęściej i z wielu źródeł;
  • szybkość nie usprawiedliwia niekompletności i braku jakości.

Współpracuj i lansuj transparentność (Collaborate and promote visibility)

Powodzenie różnorakich inicjatyw zależy w największym stopniu od ludzi w nie zaangażowanych, a w jeszcze większym stopniu od tego, czy zostali oni obsadzenie we właściwych rolach. Pamiętacie „Wesele” Stanisława Wyspiańskiego – „Wyście sobie, a my sobie, każdy sobie rzepkę skrobie”? Ten cytat sprzed ponad 100 lat pokazuje jednak, że problem nie jest nowy. Myślę, że w jeszcze dawniejszych czasach też spędzał sen z powiek naszym protoplastom, a jednak wciąż wraca i nadal wymaga specjalnej uwagi.

Czy lubicie pracować z ludźmi, którzy „wiedzą, ale nie powiedzą”? Ja nie. Włączenie jest ogólnie lepszą polityką niż wykluczenie, o ile oczywiście nie prowadzi do chaosu. Angażując się do odpowiedzialnych zadań, możesz w zamian liczyć na nowe pomysły, zaangażowanie i entuzjazm, który trudno przecenić. Mit mówiący o tym, że za wielkimi osiągnięciami stoją jednostki jest właśnie mitem. Najwięcej możemy zyskać wtedy, kiedy mamy rzetelne informacje. Wszyscy rozumiemy, jaki jest nasz wspólny cel, i ufamy współpracownikom. Może być trudno? Może, ale warto próbować.

Co nam grozi, jeśli zaczniemy ograniczać widoczność naszych celów, działań, sposobu pracy?

  1. Codzienne zadania mogą całkowicie przykryć możliwe do realizacji ulepszenia w sposobie pracy.
  2. Mogą prowadzić do nierównomiernego podziału pracy, pojawiania się zbyt wielu zadań w zespołach, które nie są w stanie ich realizować.
  3. Może również doprowadzić do tego, że brak informacji o tym, co się dzieje, spowoduje powstanie wrażenia, że nie dzieje się nic.

To oczywiście tylko część zagrożeń, ale warta uświadomienia w pierwszej kolejności. Pamiętajmy, że klient czy użytkownik widzie jedynie część produktu. Nie jest konieczne angażowanie go w zaznajamianie z każdym elementem, z którego składa się produkt. Użytkownika internetu nie interesuje, czy w serwerowni jest użyta skrętka, czy światłowód, liczy się możliwość szybkiego wejścia na „fejsa”.

Organizacje określają więc, które składniki produktu widzą ich konsumenci. Ponieważ produkty i usługi mają różne przeznaczenie i tworzą odmienne wartości, a każde z doświadczeń użytkownika jest unikatowe, nie można zestandaryzować ogólnego „pasa widoczności” dla klientów i użytkowników. Każdorazowo powinna być to indywidualna decyzja, również zależna od tego, na jakim etapie dojrzałości technologicznej i organizacyjnej znajduje się dostawca i odbiorca oraz w jakich relacjach pozostają. Ważne jest też zaangażowanie zainteresowanych stron i zaspokojenie ich potrzeb na wszystkich poziomach.

Definicja usługi uległa w ITIL 4 znacznej transformacji. Nie mówimy już o jej dostarczaniu, ale o współtworzeniu jej wartości. To jedna z najbardziej spektakularnych i istotnych zmian. Kluczowe dla utrzymania prostoty i praktyczności zarządzania usługami jest bowiem zrozumienie, w jaki sposób coś przyczynia się do tworzenia wartości. Przykładowo praca związana z przestrzeganiem przepisów może nie wydawać się ważna dla zespołów serwisowych zajmujących się problemami klientów. Konieczne jest ustanowienie i przekazanie całościowego obrazu pracy organizacji, aby poszczególne zespoły lub grupy mogły zrozumieć, jak wpływają na ich pracę, a ta z kolei na innych.

Wyjaśnijmy różnicę pomiędzy współpracą (Cooperation) a współtworzeniem (Collaboration). Współpraca oznacza współdziałanie z innymi, aby osiągnąć własne cele, które mogą być częścią wspólnego celu. Jednak często zdarza się, że cele poszczególnych grup przedkładane są na cele organizacji. Natomiast współtworzenie to „działanie polegające na współpracy z kimś w celu wyprodukowania lub stworzenia czegoś”. Z perspektywy biznesowej współpraca jest praktyką, w której jednostki pracują razem, aby osiągnąć wspólny cel/zadanie. Zarówno współpraca, jak i współtworzenie mogą być skuteczne, jednak to drugie ma większy potencjał.

Myśl i pracuj całościowo (Think and work holisticaly)

Żadna usługa, praktyka, proces, dział ani dostawca nie jest samodzielny. Dotyczy to zarówno jednoosobowej firmy programistycznej, jak i Facebooka czy Google. Jeśli nie będziesz w stanie zintegrować potencjału, który posiadasz, to najprawdopodobniej szybko odczują to Twoi klienci i interesariusze. Całościowe zarządzanie usługami wymaga przede wszystkim wiedzy, co powinno wchodzić w skład tego zintegrowanego systemu. Spieszę z odpowiedzią! Wróćcie do fragmentu opisującego 4. wymiary zarządzania usługami. To oczywiście nie wszystko, w złożonym systemie zmiana jednego elementu może wpływać na inne. Naszym zadaniem jest identyfikacja i analiza tych oddziaływań, dopiero później możemy planować ich rozwój, zmianę lub optymalizację.

Jak to osiągnąć? Autorzy podkreślają 4. elementy. Przede wszystkim są to: wiedza o systemie, rozpoznanie, z jakich elementów się składa, jeśli jest możliwe użycie sprawdzonych wzorców integracji, z których należy skorzystać, oszczędzając czas, i możliwość popełniania błędów, które ktoś już wcześniej popełnił. Na koniec najważniejsze, nic nie zastąpi ścisłej współpracy pomiędzy zespołami, klientami i interesariuszami. W tych miejscach jest najwięcej wiedzy o tym, co jest i jak powinno działać.

Prostota i racjonalizm (Keep it simple and practical)

Cele należy osiągać, wykonując minimalną liczbę kroków. Jeśli myślisz o uzyskaniu wartościowych efektów, Twoje myślenie musi być racjonalne i praktyczne. Jeśli cokolwiek – proces, usługa, akcja lub metryka – utrudnia uzyskanie zakładanego wyniku, należy go wyeliminować. Bardzo często spotykam się z tym, że analitycy koncentrują się nie na celu, jaki trzeba uzyskać, ale na analizie problemów, jakie mogą pojawić się w jego trakcie. W efekcie zaczyna się tworzyć usługę lub proces oparty na wyjątkach, który już w swoim założeniu nie może być wydajny, nie mówiąc już, jak bardzo będzie skomplikowany. Dlatego zawsze należy myśleć o tym, co chcemy zbudować, a nie zastanawiać się, co i dlaczego może się nie udać. Wyjątki należy brać naturalnie pod uwagę i nie wolno ich lekceważyć, ale nie mogą stać się głównym składnikiem procesu. Ich ujednolicona obsługa uchroni nas przed wieloma problemami i pozwoli zaoszczędzić dużo czasu.

Istotne dla utrzymania prostoty i praktyczności zarządzania usługami jest zrozumienie, w jaki sposób coś przyczynia się do tworzenia wartości. Na przykład praca związana z przestrzeganiem przepisów może nie wydawać się ważna dla zespołów serwisowych zajmujących się problemami klientów. Konieczne jest ustanowienie i przekazanie całościowego obrazu pracy organizacji, aby poszczególne zespoły lub grupy mogły zrozumieć, jak wpływają na ich pracę, a ta z kolei na innych.

Projektując, zarządzając lub operując praktykami, miejmy jednak na uwadze sprzeczne cele. Prostota nie oznacza trywializowania, prostota to szczyt wyrafinowania z uwzględnieniem potrzeb wszystkich użytkowników usług. W firmie musi istnieć równowaga między konkurującymi celami, które zdarzają się wszędzie. Koncentracja na tym, aby „dużo” robić bez jakości (bo biznes naciska), prowadzi do powstawania długu technologicznego i procesowego, obarczania innych skutkami własnych błędów. Nie praktykujcie tego!

Optymizuj i automatyzuj (Optimize and automate)

Czego nie powinniśmy robić w żadnym wypadku. Nie można optymalizować, mierzyć ani automatyzować chaosu. To nie tylko nie przynosi efektów, ale stwarza złudne poczucie, że może i coś nie działa, jak trzeba, ale „pracujemy nad tym”, a w rzeczywistości chaos się jedynie pogłębia.

Maksymalizacja wartości pracy wykonywanej przez zasoby ludzkie i techniczne jest dogmatem i zawsze trzeba do niej dążyć (choć można to robić na kilka sposobów). Technologia może pomóc w zwiększeniu efektywności i realizacji często powtarzalnych zadań, kierując uwolnione w ten sposób zasoby ludzkie do bardziej złożonych prac. Nowa generacja narzędzi jeszcze bardziej poszerza te możliwości i jest to z pewnością kierunek, który będzie się bardzo dynamicznie rozwijał (Machine Learning, Cognitive Computing, Artificial Intelligence czy Blockchain). Nie można jednak polegać wyłącznie na technologii! Czynnik ludzki nadal musi oceniać i mierzyć uzyskiwane efekty, ponieważ automatyzacja dla samej automatyzacji może zwiększać koszty, zmniejszać kreatywność oraz usypiać czujność na zachodzące wokół zmiany.

Optymalizacja oznacza uczynienie czegoś tak efektywnym i użytecznym, jak to konieczne. Zanim działanie zostanie skutecznie zautomatyzowane, należy je zoptymalizować w takim stopniu, w jakim jest to możliwe i uzasadnione. W tym przypadku niezwykle ważne jest jednak ustalenie granicy, do której zamierzamy optymalizować procesy i usługi. Często bywa, że polepszenie parametrów o niewielki procent wiąże się z tak ogromnymi kosztami, że po prostu nie warto tego robić. Zbyt często zapominamy także, że w najprostszej formie automatyzacja może również usprawnić wdrażanie standaryzacji i zadań manualnych, umożliwić na przykład takie uściślenie procesu, które pozwoli „automatycznie” podejmować decyzje przez tak zwany interfejs białkowy.

Marek Kłos,
ITIL Expert/ITIL 4 Managing Proffesional,
kierownik Działu Operacyjnego IT, Rossmann

Część 2. artykułu na temat biblioteki ITIL 4 opublikujemy w kolejnym numerze ITwiz 11-12/2019.

Tagi

Podobne

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *