Czym jest change enablement?

Wprowadzając zmiany w organizacjach, mamy możliwość wpłynięcia na pracę zespołów, usług, klientów czy rozwiązań. Właśnie w takich sytuacjach może pomóc praktyka change enablement. Zakres change enablement jest definiowany przez każdą organizację i odnosi się zwykle do infrastruktury, aplikacji, procesów, relacji z dostawcami i wszystkiego, co ma wpływ na usługę lub produkt.

Change enablement to praktyka zarządzania w ITIL 4, która wprowadza zmiany w uporządkowany i bezpieczny sposób, skuteczne balansując między oczekiwaną korzyścią a potencjalnym ryzykiem. Efektywne wykorzystanie change enablement może ułatwić wszystko, od codziennego utrzymania organizacji po złożone projekty transformacyjne.

Change enablement musi umiejętnie zrównoważyć potrzebę dokonywania zmian, które przyniosą dodatkową wartość z potrzebą ochrony klientów i użytkowników przed ewentualnym niekorzystnym wpływem zmian. Wszystkie zmiany powinny być oceniane przez osoby, które są w stanie zrozumieć znaczenie ryzyka i potencjalnych korzyści. Zmiany muszą być zatwierdzane przed wdrożeniem, a ich ocena nie powinna wywoływać niepotrzebnych opóźnień.

Przeczytaj także:

Ważne jest rozróżnienie między change enablement a zarządzaniem zmianą organizacyjna (organizational change management). Gdy zarządzanie zmianą organizacyjną dotyczy ludzkich aspektów zmian koniecznych do wprowadzenia usprawnień czy transformacji organizacyjnej, change enablement koncentruje się na zmianach, które dotyczą produktów i usług.

Jaki jest cel change enablement?

Celem change enablement jest zadbanie o to, aby przeprowadzane w organizacji zmiany były wdrożone z sukcesem. Cel ten można osiągnąć uwzględniając trzy podstawowe elementy: zarządzanie ryzykiem, zarządzanie harmonogramem zmian (change schedule) oraz przez prawidłową autoryzację (change authority).

Czym jest zmiana wg ITIL 4? Zmiana to dodawanie, modyfikowanie lub usuwanie jakiegokolwiek komponentu, który w sposób pośredni lub bezpośredni może mieć wpływ na działanie usługi IT.

Istnieją trzy kategorie zmian, którymi można zarządzać na różne sposoby i są one takie same jak w ITIL v3: zmiany standardowe (standard change), zmiany normalne (normal changes)i zmiany krytyczne (emergency changes).

Zmiany standardowe. Są to zmiany obarczone niskim ryzykiem, wstępnie zatwierdzone, dobrze zrozumiałe i w pełni udokumentowane. Można je wdrożyć bez dodatkowego zezwolenia. Są dobrze opisane, regularnie wykonywane i tam, gdzie to możliwe proces ich wprowadzania jest zautomatyzowany.

Zmiany krytyczne. Trzeba je wprowadzić tak szybko jak to możliwe, gdy tylko pojawi się incydent lub trzeba wdrożyć np. poprawki dotyczące zabezpieczeń. Proces oceny i autoryzacji tych zmian jest przyspieszony, aby zapewnić ich szybkie wdrożenie. O ile to możliwe, zmiany awaryjne powinny podlegać również testom, ocenie i autoryzacji. Za ich wprowadzenie może odpowiadać niezależny organ odpowiedzialny np. grupa menedżerów, którzy rozumieją związane z nimi ryzyko biznesowe.

Zmiany normalne. Jeśli coś nie jest zmianą standardową albo krytyczną, wówczas jest zmianą normalną. To zmiany, które należy zaplanować, ocenić i zatwierdzić przez stworzenie wniosku zmiany (request for change). Organem odpowiedzialnym za zmiany jest zwykle osoba, która może podjąć szybką decyzje, często używając automatyzacji, aby przyspieszyć zmianę.

W przypadku praktyki change enablement trzeba zrozumieć jeszcze na czym polega harmonogram (change schedule) i autoryzacja zmian (change authority).

Harmonogram zmian służy do planowania zmian, wspomagania komunikacji, unikania konfliktów i przydzielania zasobów. Może być również używany po wdrożeniu zmian, aby zapewnić informacje potrzebne do zarządzania incydentami, problemami i planowaniu kolejnych ulepszeń. Niezależnie od tego, kto jest organem odpowiedzialnym za zmianę, może pojawić się potrzeba komunikacji w całej organizacji. Na przykład ocena ryzyka może wymagać zebrania informacji od wielu osób ze specjalistyczną wiedzą. Ponadto zwykle istnieje potrzeba przekazania informacji o zmianie, aby upewnić się, że pracownicy są przygotowani przed wdrożeniem zmiany. Pozwala to unikać konfliktów podczas wprowadzania zmian, np. gdy dwóch administratorów chce wprowadzić jednocześnie zmiany na jednym serwerze.

Organ autoryzacyjny to osoba lub grupa osób upoważniona, aby podejmować decyzje czy dana zmiana czy typ zmian może zostać wdrożona. ITIL zwraca uwagę, aby takie change authority istniało dla różnych typów zmian. Tak, aby decyzję za ich wprowadzenie były podejmowane przez osoby o odpowiednich kompetencjach. W organizacjach typu high-velocity zdecentralizowanie zatwierdzanie zmian jest powszechną praktyką, co sprawia, że wspólna ocena (peer review) jest czynnikiem sukcesu.

**Najpierw change control teraz praktyka change enablement**

ITIL v3 opisywał proces zarządzania zmianą (change management process). Nazwa została zmieniona, aby uniknąć pomyłki z zarządzaniem zmianą organizacyjną (organizational change management), które w wielu organizacjach nazywa się po prostu zarządzaniem zmianą (change management).

To pojęcie ciągle jest stosowane. Jednak wraz z ITIL 4 nastąpiła zmiana pojęcia z procesu change management na praktykę change control. Nazwa zmieniła się, aby zaakcentować bardziej elastyczne podejście tej praktyki w najnowszej wersji ITIL. Jednak gdy testowano terminologię biblioteki ITIL w 2019 roku, brzmienie pojęcia change control nie odpowiadało wielu organizacjom, które wdrożyły u siebie zwinne metody pracy jak Agile czy DevOps. Dlatego, aby jak najlepiej oddać znaczenie tej praktyki zmieniono nazwę na change enablement. Zmieniono również zakres change enablement. Nie obejmuje już decyzji inwestycyjnych, które zostały przeniesione do zarządzania portfelem (portfolio management).

Posiadanie wydajnej i skutecznej praktyki umożliwiającej zmianę pomaga organizacjom przyspieszyć wykonywanie pracy i chroni je przed przestojami i wynikającymi z nich problemami. Jedna znacząca zmiana w tej praktyce obejmuje znacznie większy nacisk na delegowanie uprawnień do autoryzacji zmiany (change authority) z dala od scentralizowanego podejmowania decyzji.

Dlaczego change enablement jest praktyką?

Dlaczego w ITIL 4 doszło do zmiany i zamiast procesów pojawiły się praktyki? W poprzednich wersjach ITIL był po prostu sekwencją czynności, ale w ITIL 4 praktyka jest czymś, co organizacja może zrobić, ponieważ dysponuje odpowiednimi zasobami.

Poprzednia wersja ITIL zawierała opisy 26 procesów. Każdy z tych procesów opisywał workflow czynności, a także dostarczał informacji o rolach, metrykach i inne informacje związane z procesem. Przykłady procesów obejmują zarządzanie incydentami, problemami czy zarządzanie dostępnością. ITIL 4 nie odnosi się już do procesów, ale skupia się na 34 praktykach, dając organizacjom większą swobodę w definiowaniu procesów dostosowanych do ich potrzeb. Dlatego ITIL 4 odnosi się do change management jako praktyki i zmienia jej nazwę na change enablement.

Praktyki to coś znacznie więcej niż procesy i workflow. Praktyki odnoszą się do koncepcji każdego z czterech wymiarów zarządzania usługami ITIL: Organizations & people, Value streams & processes, Information & technology, Partner & suppliers.

Change enablement w ITIL 4 dotyczy zatem ról, umiejętności, ludzi, partnerów i zasobów, a także samego procesu. Zmiana musi dostosować się do potrzeb biznesu, aby dostarczyć wartość. Change enablement w wersji ITIL 4 zwraca uwagę na fakt, że normalna zmiana może być zainicjowana ręcznie np. poprzez zgłoszenie żądania zmiany, to teraz istotną rolę odgrywa automatyzacja. Zaimplementowana efektywnie technologia może być wykorzystana do stworzenia zautomatyzowanego pipeline’u, który umożliwia zautomatyzowanie większości etapów praktyki change enablement.