Close

Ready for ITSM at high velocity?

Typy zarządzania zmianami dla zespołów ITSM

Zarządzanie zmianami jest praktyką IT związaną z zarządzaniem usługami mającą na celu zminimalizowanie przerw w dostawie usług IT w trakcie wprowadzania zmian w systemach oraz usługach o znaczeniu krytycznym. Zmiana polega na dodaniu, zmodyfikowaniu lub usunięciu czegoś, co może mieć bezpośredni lub pośredni wpływ na usługi.

Ilustracja typów zmian

Zmiany standardowe

Zmiany standardowe to zmiany obarczone niewielkim ryzykiem, często powtarzane i wstępnie zatwierdzone. Są one wprowadzane często i postępują zgodnie z udokumentowanym, zatwierdzonym procesem.

Zmiany te są powszechne, a ich wdrażanie odbywa się zgodnie z dobrze zdefiniowanym procesem. Ponieważ proces ten został już oceniony pod kątem ryzyka i zatwierdzony, czynności tych nie trzeba powtarzać przy każdej kolejnej zmianie.

Zmiany standardowe mogą doskonale nadawać się do automatyzacji, dzięki czemu zespoły będą mogły skupić się na zmianach normalnych i awaryjnych. Według niektórych firm zautomatyzować można nawet 70% zmian standardowych.

Przykłady zmian standardowych

  • Dodanie pamięci RAM lub przestrzeni dyskowej
  • Wymiana uszkodzonego routera na identyczny sprawny router
  • Utworzenie nowej instancji bazy danych

Zmiany normalne

Zmiany normalne to zmiany nieawaryjne bez zdefiniowanego, wstępnie zatwierdzonego procesu.

Niektóre zmiany normalne — np. zmiana centrum danych — są mimo wszystko obarczone wysokim ryzykiem i mogą wymagać oceny ryzyka oraz zatwierdzenia przez zespół doradczy ds. zmian. Inne mogą być obarczone niskim ryzykiem i szybko zatwierdzane przez wyznaczony zespół ds. zmian lub w drodze automatycznych kontroli i weryfikacji.

Przykłady zmian normalnych

  • Uaktualnienie do nowego systemu zarządzania treścią
  • Migracja do nowego centrum danych
  • Poprawa wydajności

Zmiany awaryjne

Zmiany te wynikają z nieoczekiwanego błędu lub zagrożenia i wymagają natychmiastowej reakcji — zazwyczaj w celu przywrócenia obsługi klientów lub pracowników albo zabezpieczenia systemów przed zagrożeniem.

Pilny charakter zmian awaryjnych oznacza, że muszą być one rozpatrywane w znacznie krótszym czasie, ponieważ ryzyko związane z długotrwałym procesem weryfikacji jest większe niż ryzyko związane z szybkim rozwiązaniem problemu.

How you categorize your changes depends on factors including your organization, processes, and risk tolerance. We advocate dropping the "one size fits all" approach, and treating each change differently based on risk assessment. As your organization learns more about previous incidents, particular systems, and incorporates other relevant data, it should be possible to designate a higher share of changes as standard and pre-approve them. Modern change management should make change requests as simple and streamlined as possible.

Przykłady zmian awaryjnych

  • Wdrożenie poprawki zabezpieczeń
  • Postępowanie w przypadku awarii serwera
  • Rozwiązywanie poważnego incydentu

Jak należy dzielić zmiany na kategorie?

Kategorie te stanowią przydatne ramy, ale zalecamy, aby zespoły używały ich jedynie jako drogowskazów do rozwijania praktyk zmian, które odpowiadają ich własnym potrzebom. Sposób klasyfikacji zmian przez zespół zależy od czynników, takich jak organizacja, procesy i tolerancja ryzyka. W Atlassian zalecamy rezygnację z podejścia uniwersalnego i traktowanie każdej zmiany indywidualnie, w oparciu o ocenę ryzyka. W miarę pozyskiwania przez organizację większych ilości informacji o poprzednich incydentach i poszczególnych systemach oraz uwzględniania innych istotnych danych, powinno być możliwe wyznaczenie większej liczby zmian jako standardowych i ich wstępne zatwierdzenie. Nowoczesne zarządzanie zmianami powinno maksymalnie uprościć i usprawnić składanie wniosków o zmiany.

Skuteczniejsze zarządzanie zmianami dzięki systemowi Jira Service Management

Nowe funkcje zarządzania zmianami w systemie Jira Service Management zapewniają zespołom bogatsze informacje kontekstowe na temat zmian z poziomu narzędzi programistycznych, dzięki czemu mogą one podejmować lepsze decyzje i minimalizować ryzyko. Integracja z nowoczesnymi przepływami pracy projektowania oprogramowania pozwala szybciej zrozumieć zmiany i wprowadzać innowacje.