Świat biznesu słynie z używania mylących buzzwordów i żargonu branżowego. Tak jest w przypadku rozróżniania między zmianą standardową a zmianą normalną.
Nie jest zaskoczeniem, że wiele osób zadaje sobie pytanie: „Jaka jest różnica między zmianą normalną a standardową?”. Jest to szczególnie prawdziwe, biorąc pod uwagę fakt, że standard i normalny są synonimami, które są stosunkowo wymienne w większości okoliczności.
Zanim pójdziemy dalej w dół króliczej nory zmiany, upewnijmy się, że jesteśmy na tej samej stronie tego, co mamy na myśli, gdy mówimy „zmiana” w pierwszej kolejności.
Download Now: ITIL 4 Best Practice e-Books
Te całkowicie nowe dla 2020 roku e-booki ITIL podkreślają ważne elementy najlepszych praktyk ITIL 4. Szybko zrozumiesz kluczowe zmiany i koncepcje, które można zastosować w praktyce, napisane przez autorów ITIL 4.
Czym jest zmiana?
W kontekście świata biznesu IT, a dokładniej świata zarządzania ITIL, zmiana odnosi się do modyfikacji oprogramowania organizacji, niezależnie od tego, czy są to aplikacje wewnętrzne, czy produkty skierowane do klienta. Zmiana w tym kontekście obejmuje aktualizacje istniejącego kodu i systemów, które są testowane i wdrażane w środowiskach rzeczywistych.
Ten proces zarządzania zmianą jest obsługiwany przez kierownika ds. zmian oraz zespoły doradcze ds. zmian (CAB). CAB na ogół zajmuje się dwoma głównymi rodzajami zmian, na temat których zbiera informacje przed wydaniem ostatecznej zgody na wdrożenie:
- Zmiana standardowa
- Zmiana normalna
Te konkretne definicje i oznaczenia mogą się zmieniać w zależności od potrzeb organizacji, ale istnieją pewne ogólne zasady, zgodnie z którymi zwykle działają. Zacznijmy badanie tych procesów od zmiany standardowej.
(Zmiany awaryjne, które omówimy później, to zmiany bardziej pilne i wrażliwe, którymi zajmuje się Zespół Doradczy ds. Zmian Awaryjnych lub ECAB, będący zwykle podzbiorem CAB.)
Czym jest zmiana standardowa?
Zmiany standardowe, czasami nazywane zmianami rutynowymi, to zwykle zmiany wstępnie zatwierdzone, które uważa się za obarczone niewielkim lub żadnym ryzykiem. Są to dość powszechne zdarzenia, które mają określone wytyczne i procedury, których przestrzegają. Zmiany standardowe są wdrażane często z powtarzalnymi krokami, które rzadko wymagają modyfikacji. CAB zazwyczaj nie przegląda każdego przypadku zmiany standardowej, a zamiast tego ustanawia protokół i przegląd wytycznych dotyczących wprowadzania zmian standardowych.
Zmiany standardowe to często obszary, w których można wdrożyć automatyzację, aby przyspieszyć proces i zwiększyć wydajność. Zmiany te zostały dopracowane w zgrabne, uporządkowane i systematyczne podejście, które niezawodnie prowadzi do sukcesu. Zautomatyzowanie aspektów tych standardowych zmian może drastycznie ograniczyć czas tracony na ten proces i uwolnić godziny pracy na prace wymagające odrobiny ludzkiej pomysłowości.
Zarządzanie zmianą w ramach ITIL definiuje zmianę standardową jako:
„Wstępnie zatwierdzoną zmianę, która jest obarczona niskim ryzykiem, stosunkowo powszechna i zgodna z procedurą lub instrukcją pracy”.
Za standardową należy uznać usługi, które dział IT oferuje swoim użytkownikom końcowym. Usługi takie jak:
- Lifecyklowa wymiana sprzętu
- Poprawki i aktualizacje oprogramowania
- Zmiany w zaporach sieciowych
- Nowe wpisy DNS
To wszystko są przykłady wstępnie autoryzowanych zadań, które dział IT może wykonać natychmiast po pojawieniu się żądania zmiany lub wymogu. Po autoryzacji takich zmian wymagane jest minimalne planowanie w celu wykonania żądania zmiany. Zmiany te zazwyczaj powstają jako zgłoszenia serwisowe od użytkowników końcowych i są z góry dobrze przewidziane, niekoniecznie w określonych ramach czasowych.
Standardowe zmiany mogą również obejmować zmiany operacyjne, które przebiegają według określonego harmonogramu, takie jak cykle odświeżania drukarek, stacji roboczych i urządzeń sieciowych.
Procedura wdrażania zmian jest prosta i rzadko wprowadza problem lub ryzyko. Przed autoryzacją standardowych zmian przeprowadzana jest dokładna procedura oceny ryzyka. Jedynie zmiana biznesowa lub incydent informatyczny wymagałby ponownej oceny ryzyka związanego ze zmianami standardowymi.
Zmiana jest określana jako zmiana standardowa, ponieważ zatwierdzenie i wstępna autoryzacja zależy od uznania organizacji lub dostawcy usług. Procedura związana z wprowadzeniem zmiany jest dobrze udokumentowana. Związane z tym ryzyka są obliczane i uwzględniane z dużym wyprzedzeniem. Niezbędne środki ograniczania ryzyka są podejmowane jako część procedury wdrażania zmian. Po otrzymaniu wniosku o zmianę nie jest wymagane dodatkowe zatwierdzenie ze strony decydentów lub Zespołu Doradczego ds. Zmian (CAB).
Utrzymanie wniosku o usługę IT jako zmiany standardowej ma swoje zalety z punktu widzenia zarządzania usługami IT (ITSM). Proces zmiany przebiega z minimalnymi zakłóceniami, zwłaszcza w sytuacji, gdy silosy informacyjne i działowe mogą powodować niepotrzebne opóźnienia i ograniczenia we wdrażaniu zmian. Posiadanie wstępnej autoryzacji, udokumentowanej procedury wdrożeniowej i obszernej oceny ryzyka pozwala działowi IT sprawnie i skutecznie świadczyć żądaną usługę, co jest dokładnie celem ram ITIL związanych z zarządzaniem zmianami.
Mogą zdarzyć się sytuacje, w których dział CAB wkroczy do akcji i zorientuje się, że należy dodać lub usunąć pozycje z listy zmian standardowych, które wymagają bardzo niewielkiego nadzoru. Ogólnie rzecz biorąc, zmiana standardowa przebiega bezproblemowo podczas zaplanowanego okna serwisowego i ma niewielki wpływ, jeśli w ogóle jakikolwiek, na usługi w czasie rzeczywistym. Stanowi to bezpośredni kontrast w stosunku do zmian awaryjnych, które wymagają bezpośredniego nadzoru i dokładnego rozważenia.
Co to jest zmiana awaryjna?
Zmiany awaryjne są w zasadzie dokładnym przeciwieństwem zmian standardowych. ITIL definiuje zmianę awaryjną jako:
„Zmianę, która musi być wprowadzona tak szybko, jak to możliwe”.
Przykłady zmian awaryjnych obejmują:
- Wdrożenie poprawki bezpieczeństwa dla exploita zero-day
- Odizolowanie sieci od rozległego ataku Distributed Denial of Service (DDoS)
Zmiany te zazwyczaj stanowią kryzys lub okazję, którą należy się zająć bez nadmiernego ryzyka. Oczekuje się zatem akceptowalnego poziomu ryzyka i stosuje się określone procedury jako strategię ograniczania ryzyka. Przed wdrożeniem zmiany awaryjnej wymagane są również określone zatwierdzenia i autoryzacja.
Nie oznacza to długich spotkań członków CAB, ale nadzór wysokiego szczebla nad procesem zarządzania zmianą. Proces ten musi przebiegać w oparciu o szybkie działania wszystkich zainteresowanych stron na każdym etapie procesu zarządzania zmianą. W rezultacie zmiany awaryjne nie są dokładnie testowane, a odpowiednie decyzje są podejmowane jako wyważony kompromis między ryzykiem a nagrodą.
Zręczność organizacji określa, jak dobrze może ona zarządzać zmianami awaryjnymi. Przebieg procesu zarządzania zmianą jest podobny jak w przypadku zmian normalnych, ale w przyspieszonym czasie, zgodnie z wytycznymi ITIL. Skuteczna obsługa Zmiany Awaryjnej decyduje o stabilności usług IT świadczonych użytkownikom końcowym. Dlatego wpływ zmiany awaryjnej powinien zostać udokumentowany i oceniony w celu przyszłego usprawnienia procesu zarządzania zmianą.
W protokołach zarządzania zmianą awaryjną należy również uwzględnić proces naprawy lub wycofania. Dzięki temu możliwe będzie przywrócenie stanu pierwotnego, gdy działania związane z wdrażaniem zmian wprowadzą dodatkowe ryzyko i problemy.
Zmiany awaryjne nie pojawiają się w oczekiwanym czasie i są niczym innym niż zwykłymi zmianami. Zmiany awaryjne są wprowadzane w odpowiedzi na nieprzewidziane przeszkody, takie jak błędy w zabezpieczeniach i exploity. Zmiany awaryjne są natychmiast zgłaszane do kierownika ds. zmian, a następnie przesyłane do ECAB w celu dalszej analizy. Obowiązkiem ECAB jest ocena ryzyka związanego z proponowanymi zmianami awaryjnymi i rozważenie niebezpieczeństwa, jakie dany problem stanowi dla organizacji i jej usług.
ECAB dąży do znalezienia szybkiego, ale skutecznego rozwiązania nowo wykrytego problemu i pracuje w ściśle określonym terminie, który nie pozostawia miejsca na typową biurokrację związaną z większością operacji wprowadzania zmian. Informacje muszą być szybko zebrane i przeanalizowane, aby podjąć decyzję o najlepszym sposobie działania w celu rozwiązania danego problemu. Zmiany awaryjne są szybko testowane i w razie potrzeby natychmiast wdrażane. Celem zmian awaryjnych jest jak najmniejszy wpływ na usługi działające na bieżąco i jak najszybsze zatrzymanie krwawienia. Pozostawia to niewiele możliwości dla procedur standardowych, ponieważ najczęściej wymagane są rozwiązania nieszablonowe.
To, co pozostaje gdzieś pośrodku zmian awaryjnych i zmian standardowych, to zmiany normalne.
Co to jest zmiana normalna?
Większość organizacji definiuje zmiany normalne jako wszelkie zmiany, które NIE są zmianami awaryjnymi ani standardowymi. Zmiany normalne nie są wstępnie zatwierdzane, tak jak zmiany standardowe, ale też nie działają na bardziej restrykcyjnej linii czasowej i nie mają charakteru Dzikiego Zachodu, jak zmiany awaryjne, które wymagają wolności od biurokracji i ograniczających wytycznych. Zmiany zwykłe przechodzą przez proces CAB dla każdej wprowadzanej zmiany.
To umożliwia nadzór nad zmianami i daje CAB możliwość oceny, czy dana zmiana zwykła występuje na tyle często, że można jej nadać powtarzalne wytyczne, które mogłyby przekształcić ją w zmianę standardową. Każda zmiana zwykła jest przetwarzana jako wniosek o zmianę (Request for Change – RFC), który jest przekazywany do komitetu ds. oceny skutków regulacji i ostatecznie zatwierdzany lub odrzucany przez kierownika ds. zmian.
Zmiany zwykłe są dość powszechne, ale zazwyczaj wymagają nieco unikalnego lub nowatorskiego podejścia, w przeciwieństwie do zmian standardowych, które na ogół można zrealizować za pomocą przewodników krok po kroku lub pewnych podstawowych zarysów. Normalne zmiany przechodzą autorewizję, podczas której zespół analizuje zmianę w ramach zakresu zadania i ocenia jej wykonalność, zanim przeforsuje ją do CAB. Następnie CAB analizuje proponowaną zmianę i zapewnia, że spełnia ona wymogi zgodności i wszystkie protokoły bezpieczeństwa, zanim zostanie ostatecznie przekazana Kierownikowi Zmiany do ostatecznego zatwierdzenia.
ITIL definiuje zmianę normalną jako:
„Zmianę, która nie jest zmianą awaryjną ani zmianą standardową. Są to zmiany, które muszą być ocenione, autoryzowane, a następnie zaplanowane zgodnie ze znormalizowanym procesem. Zmiany te są przewidywane i planowane z wyprzedzeniem, a odpowiednie standardowe kontrole zarządzania zmianą mogą być odpowiednio opracowane. Zmiana normalna jest jednak wdrażana dopiero po uzyskaniu formalnej autoryzacji i zatwierdzenia. Zmiany o niskim ryzyku mogą wymagać autoryzacji ze strony lokalnych zespołów informatycznych, natomiast zmiany o wysokim ryzyku mogą wymagać zatwierdzenia przez CAB lub wyższe kierownictwo biznesowe i informatyczne. Wszystkie czynności w ramach kontroli procesu zarządzania zmianą są praktykowane w przypadku zmian normalnych.
Przykłady mogą obejmować migrację krytycznych zasobów informacyjnych, aplikacji i obciążeń roboczych z serwerów lokalnych do centrów danych w chmurze.
Definiowanie zmian jako normalnych zmniejsza ryzyko dla organizacji i dostawców usług informatycznych, ponieważ planowanie każdej zmiany zapewnia, że ryzyko jest starannie ograniczane, a żądania zmiany przynoszą pożądane wyniki. Jednak wdrażanie zmian normalnych jest również procesem długotrwałym i czasochłonnym. Oprócz procesu zatwierdzania i autoryzacji dostawca usług potrzebuje silnej widoczności i kontroli procesu zmian, przedmiotowych systemów i związanych z nimi zależności.
Zarządzanie i wdrażanie zmian normalnych wymaga zatem zaawansowanych technologii ITSM do starannej analizy, testowania, zarządzania i realizacji procesu zmian i systemów. Po wdrożeniu zmiany normalnej dział IT ocenia powodzenie wdrożenia i przyszłe wymagania dotyczące podobnych zmian. W idealnej sytuacji dział informatyczny doskonali swój proces zarządzania zmianą, narzędzia i możliwości, aby przekształcić zwykłą zmianę w zmianę standardową. W ten sposób zmniejsza się obciążenie działu informatycznego i dostawców usług związane z zarządzaniem zmianami, a jednocześnie uzyskuje się kontrolę nad procesem zarządzania zmianami, jaką uzyskuje się w przypadku zmian standardowych.
Podsumowanie
Ten proces zarządzania zmianami pomaga zwiększyć powodzenie wdrożeń przy jednoczesnym zmniejszeniu ryzyka i zminimalizowaniu przestojów. Różne rodzaje zmian i ich kategoryzacja pomagają w sprawnym przeprowadzeniu całego procesu zmian. Standardowe zmiany są dokonywane z niewielkim lub żadnym nadzorem, podczas gdy zmiany awaryjne wymagają starannego zarządzania i szczegółowej analizy. Zmiany normalne plasują się szczęśliwie pomiędzy tymi dwoma skrajnościami.
Różnica pomiędzy zmianą standardową, normalną i awaryjną powinna być obserwowana z perspektywy koncepcyjnej, poza różnicami w konwencji nazewnictwa. Terminy Standardowa i Normalna mogą wydawać się synonimami, ale podstawowe różnice reprezentują skuteczność procedur i kontroli zarządzania zmianą. Dlatego ważne jest, aby mieć silną praktykę umożliwiającą zmiany w rozróżnianiu tych trzech typów zmian poprzez dokładną ocenę wniosków o zmianę i incydentów prowadzących do wymogu zmiany.
Te trzy typy zmian pomagają organizacjom rozwiązywać problemy w miarę ich pojawiania się przy jednoczesnym zachowaniu stałego tempa, którego oczekuje się od nowoczesnych organizacji DevOps.
Czytanie uzupełniające
- BMC Service Management Blog
- Typy & Poziomy zarządzania zmianą
- Zarządzanie zmianą w chmurze
- Organizational Change Management (OCM): A Template for Reorganizing IT
- Facilitating Change through Effective Communication