Na papierze, procesy ITILa nie lubią się z projektami. Dla wdrożeń, ITIL® oferuje – pozornie – alternatywę, w postaci zarządzania zmianą i zarządzania wydaniem i wdrożeniem. Praktyk jednak wie, że prawdziwą efektywność i idealny balans innowacyjności z iteracyjnością, osiąga się, łącząc podejścia. Nie będzie to jednak proste. Nie ma jednej metody pojmowania zmian w świetle projektów i vice versa.
Udostępnij!
Niezbędne podstawy ITIL®
Wewnętrzna logika ITILa opiera się na pojęciu procesu. Uporządkowanego zbioru czynności, zaprojektowanego, by spełniać określone cele. Proces, w przeciwieństwie do projektu, jest mierzalny w każdym aspekcie. Nie ma końca i jest absolutnie powtarzalny. Tę zależność idealnie ilustruje przykład: wyobraź sobie, że musisz ocenić dzień pracy programisty i operatora ServiceDesku. Musisz wiedzieć, przynajmniej orientacyjnie, czy dzień pracy obu był efektywny czy nie. W przypadku kogoś, kto pełni rolę single point of contact i spędza swój dzień reagując na zgłoszenia i telefony, sprawa jest prosta – liczba obsłużonych zgłoszeń, liczba zamkniętych ticketów czy wniosków, średni czas obsługi zgłoszenia… Wystarczy je porównać z przeciętnymi wynikami całej populacji operatorów i już wiemy, czy osoba kończąca właśnie dzień pracy jest wzorem dla innych czy obszarem do wzmocnienia. Tymczasem to samo ćwiczenie, w przypadku programisty, staje się zadaniem pełnym założeń, uproszczeń i traci zupełnie sens. Co liczyć, by wiedzieć że programista miał produktywny dzień? Linie kodu? Nawet w porównaniu z uśrednionymi wynikami reszty zespołu, nie daje nam to zbyt wiele. Poza tym, parametr ten w żaden sposób nie przekłada się na sukces projektu, nad którym pracuje programista. Czasem to jedna linijka jest tą kluczową, a tysiące to oczywista i mozolna praca.
Dzieje się tak, gdyż w naszym przykładzie, to programista pracuje projektowo, a operator procesowo. Projekt można obiektywnie ocenić dopiero po osiągnięciu końca, kiedy to weryfikowane będą założenia finalne. Jeśli funkcjonalności zlecone naszemu programiście przez projekt działają, kiedy nadejdzie stosowny czas, programista jest skuteczny. Jeśli nie, to programista staje się obszarem do wzmocnienia. Jest to pewne uproszczenie, bowiem w projekcie istnieją kryteria częściowe, jak choćby kamienie milowe, nie wspominając o kontroli, którą nad projektem dają nam modele i metodologie zwinne. Niemniej, przykład ilustruje idealnie diametralne różnice w podejściu projektowym i procesowym. Czy zatem obie filozofie mają punkty wspólne? Czy możliwa jest bezkonfliktowa współpraca?
Punktem wspólnym może być to, co ITIL® nazywa zarządzaniem zmianą. Proces gwarantujący, że wprowadzane do środowiska modyfikacje będą odpowiednio oceniane pod kątem ryzyka (zarówno ryzyka związanego z wprowadzeniem, jak i nie wprowadzaniem zmiany), kosztu, wartości dla biznesu. W obszarze wdrożeń, czy – jak chce ITIL – przekazywania do działania mieści się ten obszar, który z równym powodzeniem może być pojmowany jako proces i jako projekt.
Czy zmiana to projekt?
ITIL zakłada, że na pewnym etapie cyklu życia usługi informatycznej konieczne są zmiany. ITIL sugeruje również, że nowe usługi można wdrażać w środowisko produkcyjne za pomocą zmian lub całych ich grup. Jak jednak tak pojmowane zmiany mają się do realizowanych przez organizację projektów? W praktycznej realizacji obu koncepcji znajdziemy więcej różnych przykładów, wiele różnych modeli. Wśród nich, dwa zasługują na szczególne wyróżnienie.
Po pierwsze, można przyjąć założenie, że każda zmiana, której cykl życia kontrolowany jest procesowo, jest w istocie projektem. Procesy zarządzania zmianą i zarządzania wydaniem i wdrożeniem awansują wtedy do roli bytu sterującego całością, podchodzą holistycznie do modyfikacji infrastruktury czy dodawania nowych elementów. Proces zyskuje wtedy prymat nad projektem, który staje się narzędziem naprawy, doskonalenia czy modyfikacji środowiska pracy. Dzięki Radzie ds. Zmian, ważnej części tego procesu, organizacja zyskuje możliwość karmienia go wiedzą ekspercką i znacząco obniża się ryzyko podjęcia złej decyzji. Liczba wprowadzanych zmian jest wtedy limitowana tylko i wyłącznie ilością zasobów, jakie organizacja jest w stanie poświęcić pracy rozwojowej czy wdrożeniom.
Po drugie, istnieje taki model, w którym projekty funkcjonują niezależnie od zarządzania zmianą. Proces wprowadzania modyfikacji do środowiska jest wtedy osobny i ma dużo węższe kompetencje. Styka się z projektami tylko w tym momencie, w którym jego rezultaty wymagają faktycznego wdrożenia w środowisko produkcyjne. Ten model nie łączy filozofii projektu i procesu w spójną całość, ale umożliwia też wprowadzanie zmian inicjowanych lub przygotowywanych poza biurem lub zespołem projektów. Jest to zatem metoda wielce przydatna w strukturach rozproszonych, gdzie drobne modyfikacje środowiska produkcyjnego mogą powstawać bliżej Operacji, po stronie biznesu lub gdziekolwiek indziej i nie wymagają narzędzi projektowych do zaistnienia. Stąd najczęściej obserwujemy ten model jako wiodący tam, gdzie rozgranicza się wprowadzanie nowych usług lub produktów na rynek od doskonalenia tych już istniejących. Dajemy wtedy klientowi i Operacjom większą swobodę w modyfikowaniu ich środowiska pracy. Jest to podejście preferowane tam, gdzie katalog usług lub produktów jest bogaty, a struktura wewnętrzna organizacji podzielona i zdywersyfikowana.
Poza tymi dwoma jest jeszcze wiele innych modeli. W niektórych projekt trwa od koncepcji, przez projektowanie aż do wdrożenia i wczesnego wsparcia, które wieńczy przekazanie Operacjom kontroli. Wtedy proces zarządzania zmianą zaczyna się zaraz po wczesnym wsparciu i odnosi się do tych modyfikacji, które przyjdą później. O ile takie rozwiązanie ma wiele zalet i umożliwia wprowadzenie mocnego podziału na design i utrzymanie, ma również wady. Wymaga, by obie strony równania posiadały zbliżone kompetencje, zdolności i zasoby, gdyż obie będą w pewnym stopniu odpowiedzialne za te same działania. Jeśli posłuchamy zbioru najlepszych praktyk, jakim jest ITIL, to nie będzie jedna z praktyk polecanych.
Co jest najlepszą praktyką?
Projekty i procesy są wysoce wyspecjalizowanymi narzędziami i powinny być obecne w każdej organizacji informatycznej. W efekcie bowiem, zyskujemy dostęp do dwóch znaczących wartości, jakie się za nimi kryją – kreatywności i elastyczności – dzięki projektom i stabilnej powtarzalności – dzięki procesom. Dzięki projektom odpowiadamy na pytania, których nikt jeszcze nie zadał, gdyż ich ideą jest znajdować rozwiązania lub poprawiać sytuację zastaną. Z kolei procesy, pozwalają zoptymalizować powtarzalne czynności i uzyskać w każdej iteracji satysfakcjonujący poziom jakości. Dzięki projektom osiągamy innowację i wzrost jakości, dzięki procesom gwarantujemy te czynniki konsekwentnie i regularnie.
Najlepsze praktyki nie odpowiedzą za nas na pytanie, w którym miejscu postawić granicę między pracą projektową a procesem ale znający oba te obszary praktyk będzie w stanie stworzyć rozwiązanie adekwatne do warunków swojego środowiska.
