W 2019 roku AXELOS zrobił coś, co większość ludzi przeoczyła. Praktyka, którą wszyscy znali jako Change Management, dostała nową nazwę: Change Enablement. To nie był kosmetyczny lifting. Zmiana nazwy z “zarządzania” na “wspieranie” miała pokazać, że zmiana w IT to nie kwestia kontroli, tylko umożliwienia. Problem w tym, że większość organizacji nadal traktuje ten proces jak checkpoint na autostradzie, a nie jak mechanizm, który ma coś przyspieszyć.
W oficjalnej dokumentacji ITIL 4 znajdziesz sformułowanie, że celem Change Enablement jest “maksymalizacja liczby udanych zmian poprzez właściwą ocenę ryzyka, autoryzację i zarządzanie harmonogramem”. Brzmi rozsądnie. Ale kiedy patrzysz, jak to wygląda w praktyce, w zespole 30 osób wdrażającym nowy moduł CRM, zaczyna się teatr. Ktoś wypełnia Request for Change, ktoś inny zasiada w Change Advisory Board, a potem wszyscy czekają dwa tygodnie na decyzję, która mogła zapaść w 20 minut.
Kreacja wniosku o zmianę
RFC to skrót, który brzmi jak droid z Gwiezdnych wojen. Request for Change. W teorii prosty dokument opisujący, co się zmieni, dlaczego i jakie jest ryzyko. W praktyce dwunastostronicowy formularz, który nikt nie czyta do końca. Widziałem wniosek o zmianę konfiguracji firewalla, gdzie osiem stron to były załączniki z poprzednich zmian skopiowane przez kogoś “dla pewności”.
Kluczowy moment to opis ryzyka i uzasadnienia biznesowego. ITIL 4 mówi, żeby ocenić wpływ zmiany na usługi, ale rzadko kto zadaje pytanie: co się stanie, jeśli tej zmiany NIE zrobimy? Widziałem zespoły blokujące upgrade systemu CMS przez trzy miesiące, bo RFC nie zawierał “pełnej analizy wpływu”. System działał na wersji z 2018 roku z dziurami bezpieczeństwa jak szwajcarski ser, ale proces był zachowany.
Ocena i kategoryzacja
ITIL 4 wyróżnia trzy typy zmian: standardowe, normalne i awaryjne. Standardowe to te z pre-approval, powtarzalne, niskoryzykowne. Normalne wymagają pełnej oceny. Awaryjne to sytuacja “wszystko się pali”.
Problem zaczyna się, gdy 80% zmian ląduje w kategorii “normalne”, bo nikt nie chce brać odpowiedzialności za stworzenie procedury standardowej. Restart serwera aplikacyjnego po patchu? Normalna zmiana, CAB, cztery dni oczekiwania. W startupie robiłem to raz w tygodniu jednym kliknięciem, tu potrzeba eskalacji do dyrektora IT.
Ocena ryzyka to kolejny temat. W dokumentacji ITIL jest mowa o “właściwej ocenie”, ale co to znaczy właściwa? Widziałem macierze ryzyka, gdzie ktoś oceniał wpływ zmiany na skali od 1 do 5, a potem mnożył przez prawdopodobieństwo. Wyszło 12. Co to oznacza? Nikt nie wiedział, ale zmiana została odrzucona.
Autoryzacja przez odpowiednie ciało
Change Advisory Board brzmi poważnie. W rzeczywistości to spotkanie ośmiu osób, z których połowa jest tam, bo “zawsze była”. Kierownik bezpieczeństwa, przedstawiciel biznesu, architekt, ktoś z operations. ITIL 4 mówi, że CAB powinien być proporcjonalny do skali organizacji, ale widziałem firmę 50-osobową z CAB liczącym 12 ludzi.
Autoryzacja trwa czasem 15 minut, czasem dwa tygodnie. Zależy, czy akurat dyrektor IT jest na urlopie. Emergency Change Advisory Board to wersja dla sytuacji kryzysowych, teoretycznie zwołuje się go w 2 godziny. Praktycznie bywa, że nikt nie odbiera telefonu, bo jest piątek o 17:00.
Planowanie i koordynacja wdrożenia
Zatwierdzono zmianę. Teraz ktoś musi ją zaplanować. ITIL 4 wspomina o “zarządzaniu harmonogramem zmian”, co brzmi prosto, dopóki nie masz 40 zmian w kolejce i trzech okien serwisowych w miesiącu. Kto decyduje, co idzie pierwszego? Priorytet biznesowy? Kto go określa?
Koordynacja to taniec między zespołami. Zmiana w bazie danych wymaga zgody DBA, ale DBA jest na szkoleniu. Zmiana w sieci wymaga, żeby security wyłączył IPS na 10 minut, ale security nie odpowiada na maile. Widziałem wdrożenie przesunięte trzy razy, bo kalendarz zmian był zarządzany w Excelu i dwie osoby edytowały go równocześnie.
Przegląd i zamknięcie
Post-implementation review to etap, o którym wszyscy zapominają. ITIL 4 zaleca ocenę, czy zmiana osiągnęła zamierzony cel, czy wystąpiły incydenty, czy coś należy poprawić. W praktyce bywa, że zmianę zamyka się tydzień po wdrożeniu formularzem “wszystko OK”, bo nikt nie chce wracać do tematu.
Zamknięcie zmiany powinno obejmować aktualizację CMDB, dokumentację, lessons learned. Widziałem zespół, który przez rok wprowadzał zmiany w infrastrukturze i ani razu nie zaktualizował bazy konfiguracji. Kiedy przyszedł audyt, okazało się, że CMDB pokazuje stan z 18 miesięcy wcześniej.
ITIL 4 nie jest zły. Problem w tym, że organizacje traktują go jak listę checkboxów do odhaczenia, a nie jak zestaw zasad do zinterpretowania. Pięć etapów ma sens, jeśli rozumiesz, po co one są. Jeśli nie, stajesz się zakładnikiem procesu, który miał ci pomóc.
Źródła
- AXELOS, ITIL 4 Practice Guide: Change Enablement, 2019.
- Schwaber K., Sutherland J., “Scrum Guide”, scrumguides.org, 2020.
- Brooks F.P., “The Mythical Man-Month”, Addison-Wesley, 1975.
Zdjęcie: Pavel Danilyuk / Pexels
