W poprzednim artykule opisywałem proces zarządzania katalogiem usług. Bardzo mocno z nim powiązany jest proces zarządzania poziomem usług. Tak naprawdę kiedyś zarządzanie katalogiem usług było w ramach procesu zarządzania poziomem usług, ale zostało wydzielone do oddzielnego procesu. Nie dziwi więc fakt, że oba procesy są spokrewnione i zarządzanie poziomem usług bez katalogu usług nie miałoby co robić, bo poziom świadczenia określa się dla usług zdefiniowanych w katalogu usług. Ponieważ katalog usług jest bardzo ważnym produktem i narzędziem w zarządzaniu usługami IT, według mnie dobrze się stało, że został do jego zarządzania powołany dedykowany proces. Co zatem zostało w procesie zarządzania poziomem usług?

Cele

Podstawowym celem procesu zarządzania poziomem usług jest zagwarantowanie, że wszystkie aktualne i planowane usługi, są dostarczane na uzgodnionym, wymaganym poziomie. Osiąga się ten cel poprzez ciągły cykl negocjacji, uzgadniania, monitorowania, raportowania i przeglądania wymaganych (dopuszczalnych) wartości parametrów SLA.

Proces koncentruje się na:

• Definiowaniu, dokumentowaniu, uzgadnianiu, monitorowaniu, mierzeniu, raportowaniu i przeglądaniu poziomu, dostarczanych usług IT. Jeżeli jest potrzeba wprowadzane są środki naprawcze
• Zapewnieniu i poprawie relacji i komunikacji z biznesem i klientami
• Zapewnieniu, że zostaną określone, konkretne i mierzalne cele (wartości dopuszczalne) dla wszystkich usług IT
• Monitorowaniu i poprawie satysfakcji klienta z jakości świadczonych usług
• Zapewnieniu, że IT i Klienci mają jasne i jednoznaczne oczekiwania co do poziomu świadczonych usług
• Zagwarantowaniu, że nawet jeżeli wszystkie wymagane wartości poziomu usług zostaną spełnione, będą podejmowane proaktywane działania, mające na celu ciągłą poprawę kosztową usług

Zakres

Rysunek z książki ITIL Service Design

W zakresie procesu zarządzania poziomu usług jest zapewnienie regularnych kontaktów i komunikacji z klientami i menedżerami biznesowymi, w zakresie związanym z poziomem świadczonych usług. W tym względzie proces SLM powinien reprezentować dostawcę usług IT przed biznesem i biznes przed dostawcą usług IT. Zakres procesu SLM obejmuje również:

• Współpracę z procesem zarządzania relacjami biznesowymi (proces na etapie strategii), w zakresie osiągnięcia celów procesu SLM
• Negocjacje i uzgodnienie przyszłych (planowanych) wymagań na poziom usług i wartości dopuszczalnych (Service Level Requirements – SLR) dla wszystkich usług
• Negocjacje i uzgodnienie aktualnych wymagań na poziom usług i wartości dopuszczalnych (Service Level Agreement – SLA)
• Rozwijanie i zarządzanie odpowiednich umów OLA, które zagwarantują dotrzymanie celów w umowach SLA
• Przeglądanie i zarządzanie umowami z dostawcami zewnętrznymi (Underpinning contracts),które zagwarantują dotrzymanie celów w umowach SLA
• Proaktywne zapobieganie awarią usług, minimalizowanie ryzyka i poprawa jakości usług
• Raportowanie i zarządzanie rzeczywistym poziomem usług i przeglądanie wszystkich przekroczeń poziomu usług zdefiniowanego w SLA
• Okresowe przeglądy SLA, OLA i zakresu usług
• Identyfikowanie możliwości usprawnień i wprowadzanie ich do rejestru usprawnień
• Inicjowanie i koordynowanie planu poprawy usług (Service Improvement Plan – SIP)

Proces zarządzania poziomem usług nie obejmuje:

• Negocjacji i uzgodnienia wymagań funkcjonalnych, oprócz tych funkcjonalności, które mogą wpływać na poziom świadczonych usług
• Pilnowania aktywności, które są konieczne do zapewnienia wymaganego poziomu usług, ale są realizowane przez inne procesy takie jak zarządzanie dostępnością i zarządzanie pojemnością.
• Negocjacji i podpisywania umów z dostawcami zewnętrznymi, za które odpowiada proces zarządzania dostawcami. SLM dostarcza tylko dane wejściowe i wymagane konsultacje.

Korzyści

Efektywnie funkcjonujący proces zarządzania poziomem usług zapewnia:

• Interfejs dla biznesu, dla wszystkich zagadnień związanych z poziomem usług
• Uzgodnione SLA z określonymi celami (wartościami dopuszczalnym) oraz informację zarządczą, że te cele są spełnione
• Wyjaśnienie przyczyn źródłowych przekroczenia SLA i podejmowanie działań, które zagwarantują nie powtarzanie się tych przekroczeń
• Wiarygodny kanał komunikacji i zaufane relacje z klientem i biznesem

Rodzaje SLA

SLA możemy definiować na kilka różnych sposobów.

• SLA zorientowane na usługę, definiujemy jedno SLA dla usługi, chociaż może z niej korzystać wielu klientów. Problemem może być zróżnicowanie poziomu SLA, jeżeli usługa korzysta z tych samych elementów konfiguracji
• SLA zorientowane na klienta, definiujemy SLA dla jednego klienta, uwzględniając wszystkie usługi jakie dla niego świadczymy
• Wielopoziomowe SLA, którego przykładem może być trzypoziomowe SLA: poziom korporacji, poziom klienta i poziom usługi

Podsumowanie

To zaczyna się robić nudne :-). Zarządzanie poziomem usług to kolejny bardzo ważny proces w zarządzaniu usługami IT. Jest odpowiedzialny za ustalenie z biznesem, na jakim poziomie będą świadczone usługi IT. Musi przy tym uwzględniać wymagania biznesu i klienta, możliwości organizacji IT, posiadane zasoby sprzętowe i softwareowe oraz obowiązujące umowy z dostawcami zewnętrznymi. Żąglowanie tymi wszystkimi elementami, wymaga nie lada umiejętności od Menedżera poziomu usług. Potrzebne jest również doświadczenie w negocjowaniu, komunikacji, budowaniu relacji i balansowaniu pomiędzy biznesem a IT.

Pytanie: Jaki rodzaj SLA stosujesz najczęściej i dlaczego?

Artykuł Zarządzanie poziomem usług pochodzi z serwisu Mariusz Siek.

Odkąd zacząłem się zajmować zarządzaniem usługami IT, uważałem że wprowadzanie najlepszych praktyk ITIL należy zaczynać od katalogu usług. Nadal tak uważam, bo jak można zarządzać usługami nie wiedząc jakie mamy usługi i jaki poziom ich świadczenia (SLA) jest określony. Potwierdza to biblioteka ITIL, która w wersji 3 w 2007 roku, oprócz procesu „Zarządzanie poziomem usług„, wprowadziła dedykowany proces „Zarządzanie katalogiem usług”. Jeżeli mamy specjalnie dla katalogu usług proces do jego zarządzania, to chyba należy uznać, że katalog usług, jest bardzo ważnym narzędziem w zarządzaniu usługami IT. Zobaczmy co zawiera proces „Zarządzania katalogiem usług”

Cele

Celem procesu Zarządzania katalogiem usług jest dostarczenie i utrzymanie jednego, spójnego źródła informacji o wszystkich produkcyjnych i projektowanych usługach i zapewnienie, aby te informacje były dostępne dla jak najszerszego grona, uprawnionych odbiorców.

Proces koncentruje się na:

• Zarządzaniu informacjami zawartymi w katalogu usług
• Zapewnieniu, że katalog usług jest dokładny i odzwierciedla aktualny stan usług, które działają produkcyjnie lub są przygotowywane do wdrożenia na produkcji
• Zapewnieniu, że katalog usług jest dostępny dla wszystkich uprawnionych interesariuszy, w sposób który zapewnia efektywne wykorzystanie zgromadzonych w nim informacji
• Zapewnieniu, że katalog usług wspiera zmieniające się potrzeby pozostałych procesów zarządzania usługami, w zakresie informacji zawartych w katalogu usług

Zakres

Proces Zarządzania katalogiem usług, obejmuje swoim zakresem:

• Przygotowanie wsadu do definicji usług i pakietów usług
• Rozwój i utrzymanie opisów usług i pakietów usług, według ustalonych standardów
• Wytworzenie i utrzymanie prawidłowego katalogu usług
• Interfejsy, zależności i spójność pomiędzy katalogiem usług a portfolio usług
• Interfejsy i zależności pomiędzy usługami i usługami wspierającymi w katalogu usług i CMS
• Interfejsy i zależności pomiędzy usługami a komponentami wspierającymi i elementami konfiguracji, w katalogu usług i CMS

Proces Zarządzania katalogiem usług nie obejmuje:

• Gromadzenia, utrzymania i wykorzystania zasobów usługi i danych konfiguracji. Tym zajmuje się proces zarządzania zasobami i konfiguracją.
• Gromadzenia, utrzymania i spełnienia żądań o usługę. Tą aktywnością zajmuje się proces spełniania żądań (request fulfillment)

Korzyści dla biznesu

Efektywne zarządzanie katalogiem usług, pozwala na osiągnięcie następujących korzyści:

• Dostarcza biznesowi centralne źródło informacji o usługach IT, ich szczegółach, statusie, poziomie świadczenia, jakie procesy biznesowe wspierają, sposobie wykorzystania.
• Zapewnienie wspólnego rozumienia usług IT przez biznes i IT, skutkujące lepszymi relacjami pomiędzy klientem a dostawcą, poprzez wykorzystanie katalogu usług jako narzędzia marketingu i komunikacji
• Lepsza koncentracja dostawcy usług na wynikach klienta, dzięki powiązaniu wewnętrznych aktywności dostawcy usługi i zasobów usługi z procesami i wynikami biznesowymi
• Poprawa wydajności i efektywności pozostałych procesów zarządzania usługami IT, poprzez wykorzystanie informacji zawartych w katalogu usług
• Lepsza wiedza, dopasowanie i koncentracja na wartości dla biznesu, dla każdej usługi, po stronie dostawcy usług IT

Rodzaje usług

Katalog usług to nie zwykła lista usług ale pewna hierarchia i struktura, która pokazuje zależności pomiędzy procesami biznesowymi, usługami i SLA. Same usługi możemy podzielić na dwie główne grupy:

• Usługi udostępniane użytkownikowi, są to usługi które wspierają procesy biznesowe klienta, bezpośrednio dostarczające oczekiwanych wyników
• Usługi wspierające, są to usługi, które wspierają funkcjonowanie usług udostępnianych użytkownikowi i nie są przez niego widziane

Ja nazywam pierwsze usługami biznesowymi a drugie usługami systemu. Oczywiście nazw usług wspierających może być więcej: infrastrukturalne, sieciowe, aplikacyjne, techniczne itp. Niezależnie jak będą się nazywać, należy zadbać aby były jednoznacznie zdefiniowane, aby każdy zainteresowany rozumiał je w ten sam sposób.

Na poniższym rysunku (z książki ITIL Service Design) pokazano rodzaje usług, przykładowe usługi, ich relacje pomiędzy nimi, procesami biznesowymi i SLA. Daje on pewne wyobrażenie, co powinien zawierać katalog usług i jak ważnym jest narzędziem.

Podsumowanie

Proces Zarządzania katalogiem usług, jest jednym z najważniejszych na etapie projektowania usług oraz w całym cyklu życia usługi. Zapewnia, że:

• wszystkie usługi funkcjonujące produkcyjnie, będą w katalogu usług opisane
• będą określone relacje pomiędzy procesami biznesowymi a usługami udostępnianymi użytkownikowi (biznesowymi)
• będą określone relacje pomiędzy usługami biznesowymi a wspierającymi (systemu)
• informacje będą aktualne, prawidłowe i odzwierciedlające rzeczywistość produkcyjną.

Jeżeli zastanawiałeś się dlaczego potrzebny jest dedykowany proces dla zarządzania katalogiem usług, to teraz już chyba nie masz wątpliwości. Wykorzystaj go aby poprawić jakość świadczonych usług IT do biznesu.

Pytanie: Ile usług masz w katalogu usług i jakie są ich rodzaje?

Artykuł Zarządzanie katalogiem usług pochodzi z serwisu Mariusz Siek.

Od 12 lat zajmuję się zarządzaniem usługami IT. W mojej pracy wykorzystuję najlepsze praktyki ITIL i doświadczenie zdobyte na przestrzeni tego okresu. Świat jednak nie stoi w miejscu i zmienia się bardzo szybko, szczególnie w obszarze technologii. Czy ITIL, który został wymyślony w latach dziewięćdziesiątych poprzedniego wieku, spełnia oczekiwania dzisiejszego IT, które musi sprostać wysokim wymaganiom biznesowym? Czy wersja trzecia ITIL, która ukazała się w 2007 roku, nadal jest aktualna i stosowanie jej przynosi spodziewane korzyści? Jak zmieni się ITIL w wersji 4, która jest zapowiadana na ten rok? Czy ITIL ma szanse w konfrontacji z DevOps, które obecnie jest jednym z najbardziej popularnych i pożądanych podejść na funkcjonowanie IT? Za dużo pytań jak na początek artykułu :-). Spróbujmy znaleźć na nie odpowiedzi.

ITIL

ITIL w wersji 3 wprowadził usługowe podejście do IT i cykl życia usługi. Cykl życia składa się z pięciu faz:

• Strategii
• Projektowania
• Wdrożenia
• Utrzymania
• Ciągłej poprawy

Cykl ten się powtarza, ponieważ zawsze możemy coś zrobić aby usługa była świadczona lepiej, taniej i na wyższym poziomie.

To podejście objęło cały cykl wytwórczy dla usługi, czego nie było w poprzedniej, drugiej wersji biblioteki. Całkowitą nowością była faza strategii. Natomiast pozostałe fazy zostały rozszerzone o brakujące procesy.

Wiele organizacji IT nadal funkcjonuje w oparciu o procesy opisane w ITIL, z uwzględnieniem ich potrzeb i wymagań. Według mnie nie straciły one nic ze swojej aktualności, chociaż mogą się wydawać „ciężkie”, mało zwinne i bardzo sformalizowane. Czy ich biurokracja jest w stanie sprostać, wymaganiom na wykonywanie kilku wdrożeń dziennie?

Rys 1. Na podstawie książki ITIL Service Transition.

DevOps

Po drugiej stronie mamy DevOps, który mocno się rozpycha i pokazuje, że można do wytwarzania i wdrażania usług, rozumianych jako oprogramowanie i infrastruktura sprzętowa, zastosować takie rozwiązania, które pozwolą szybko, sprawnie i bezproblemowo, dostarczać na produkcję nowe funkcjonalności i aplikacje. W największym uproszczeniu, DevOps to połączenie wytwarzania usług (development) z ich utrzymaniem (operations). Usuwamy odwieczny mur pomiędzy rozwojem i utrzymaniem, i tak organizujemy pracę zespołu aby mógł szybko dostarczać wartość biznesową na produkcję. Nie chodzi tu oczywiście tylko o ludzi ale przede wszystkim procesy i narzędzie. Musimy zastosować pełną automatyzację testów, ciągłą integrację, infrastrukturę jako kod i kilka innych specyficznych dla DevOps rozwiązań.

Rys 2. Na podstawie wideo What is DevOps

Wspólne elementy

Czy to oznacza, że nie można pogodzić DevOps z ITIL? Na pierwszy rzut oka, wydaje się, że są to dwa różne światy, jednak po bliższym przyjrzeniu się znajdziemy kilka części wspólnych.

• Cykliczność. Oba podejścia uwzględniają cykliczne działanie, które ma na celu ciągłe doskonalenie wytwarzanych i implementowanych rozwiązań. Łatnie to widać na dwóch powyższych rysunkach. Oczywiście częstotliwość tych cykli jest inna ale można ją próbować synchronizować.
• Procesy. W obu metodykach wykorzystywane są procesy, które muszą być dobrze zaprojektowane, dostosowane i wdrożone do potrzeb organizacji. Co ciekawe niektóre tak samo lub bardzo podobnie się nazywają: zarządzanie zmianą, zarządzanie wydaniami, zarządzanie pojemnością i zarządzanie konfiguracją. Nie trzeba wyjaśniać, że np. proces zarządzania zmianą w ITIL aby działał na potrzeby DevOps musi zostać odpowiednio zmieniony, zaadaptowany i zautomatyzowany.
• Ciągłe doskonalenie. Nie ważne czy nasz cykl wytwórczy trwa jedną godzinę, jeden dzień czy jeden miesiąc, mamy świadomość, że nie dostarczymy idealnego rozwiązania i będziemy musieli je poprawiać, usprawniać i rozwijać. Tak samo do tego zagadnienia podchodzą obie metodologie i to daje szansę na ich wspólne funkcjonowanie.
• Narzędzia. Do wsparcia procesów zarówno w ITIL jak i DevOps potrzebne są specjalistyczne narzędzia. Oczywiście są to innego rodzaju narzędzia, bo specyfika jest różna ale bez narzędzi, obsługa procesów nie byłaby możliwa.

Chociaż ITIL i DevOps, wydają się dwoma, odmiennymi światami, to można znaleźć kilka cech wspólnych, które pozwalają na funkcjonowanie obu podejść jednocześnie w tej samem organizacji. ITIL nie wyklucza DevOps i DevOps nie wyklucza ITIL. Można wykorzystać obie metodologie i stworzyć własne rozwiązanie dopasowane do potrzeb organizacji. Wydaje się, że to ITIL, zgodnie z dewizą „adopt and adapt” musi dopasować się do DevOps a nie odwrotnie. Wymaga to jednak poważnego zastanowienia się jak to zrobić.

Pytanie: Czy uważasz, że można pogodzić ITIL i DevOps i dlaczego?

Artykuł Czy ITIL i DevOps można pogodzić? pochodzi z serwisu Mariusz Siek.

Przejście z etapu projektowania i wytwarzania do etapu eksploatacji usługi IT, oprócz procesu walidacji i testowania, wymaga jeszcze zarządzenia wydaniami i wdrożeniami, które te wydania wprowadzą na produkcję. Żeby nie było, mamy dedykowany proces, który się tym zajmuje i pomaga nam abyśmy o niczym nie zapomnieli. Jakie są najważniejsze elementy tego procesu, chciałbym napisać w tym artykule.

Cele

Proces zarządzania wydaniami i wdrożeniami odpowiada za zaplanowanie, zaharmonogramowanie i kontrolę budowania, testowania i wdrażania wydań oraz dostarczenie nowych funkcjonalności dla biznesu, jednocześnie zapewniając integralność istniejących na produkcji usług.

Realizacja tej odpowiedzialności wymaga:

• Zdefiniowania i uzgodnienia planów wydań i wdrożeń z wszystkimi udziałowcami, w tym z klientem
• Przygotowania i przetestowania pakietu wydania, składającego się z elementów konfiguracji, które są ze sobą spójne
• Zapewnienia integralności pakietu wydania oraz komponentów wchodzących w jego skład, w całym procesie wdrożenia
• Przechowywania pakietów wydań w repozytorium wydań (Definitive Media Library)
• Wdrożenia pakietu wydania z repozytorium wydań na produkcję, zgodnie z planem i harmonogramem
• Zagwarantowania, że wszystkie pakiety wydania mogą być monitorowane, instalowane, testowane, weryfikowane, odinstalowywane i wycofane
• Zagwarantowania, że nowa lub zmieniona usługa, w zakresie technologii i organizacji, dostarcza oczekiwane wymagania funkcjonalne i niefunkcjonalne
• Rejestrowania i zarządzania ryzykami i zagadnieniami, związanymi z nową lub zmienioną usługą oraz podejmowanie działań naprawczych
• Zagwarantowania transferu wiedzy do użytkowników aby mogli lepiej wykorzystać dostarczane usługi
• Zagwarantowania przekazania umiejętności i wiedzy do zespołu utrzymania, aby mógł świadczyć wsparcie zgodne z SLA

Zakres

Zakres procesu zarządzania wydaniami i wdrożeniami obejmuje procesy, systemy i funkcje, wymagane do przygotowania pakietu, testowania i wdrożenia wydania na produkcję.

W szczególności dotyczy elementów konfiguracji takich jak:

• Infrastruktura sprzętowo-programowa
• Zasoby wirtualne jak serwery i dyski
• Aplikacje i oprogramowanie standardowe
• Szkolenia na użytkowników i zespołów utrzymania
• Usługi oraz związane z nimi umowy np SLA, katalog usług

Proces zarządzania wydaniami i wdrożeniami:

• Odpowiada za testowanie wydania, jednak samo testowanie jest wykonywane w ramach procesu walidacji i testowania
• Nie odpowiada za akceptację zmian, która jest przeprowadzana w procesie zarządzania zmianą

Korzyści

Dobrze i efektywnie działający proces zarządzania wydaniami i wdrożeniami, przynosi następujące korzyści:

• Zmiana dostarczana jest szybciej, optymalnie kosztowo i ze zminimalizowanym ryzykiem
• Gwarancja wykorzystania nowych lub zmienionych usług przez klientów i użytkowników, w sposób, który wspiera cele biznesowe
• Poprawa spójnego podejścia do wdrożenia w zakresie zmiany biznesowej, zespołów usługowych, dostawców i klientów
• Przyczynienie się do spełnienia wymagań audytowych, związanych z monitorowaniem w całym procesie wdrożenia
• Zmniejszenie kosztów dostarczanej usługi – zespoły IT nie muszą rozwiązywać problemów związanych z wdrożeniem

Pilot

Bardzo użytecznym rozwiązaniem przy wdrażaniu nowych usług jest skorzystanie z pilota, czyli wdrożenie usług tylko dla wybranych użytkowników. Należy jedna zwrócić uwagę na właściwe dobranie liczby użytkowników. Jeżeli użytkowników będzie za mało, to weryfikacja będzie nie wystarczająca i nie zostaną wykryte błędy, które wystąpią następnie na produkcji. Jeżeli użytkowników będzie za dużo, to nie uzyskamy odpowiedniej elastyczności i prędkości, w osiągnięciu oczekiwanych korzyści pilota.

Ważne jest aby dobrze ustalić kryteria, na podstawie których będziemy oceniali, czy pilot zakończył się sukcesem i możemy wdrożyć usługę dla wszystkich użytkowników.

Odpowiednie przygotowanie i przetestowanie wydania, pozwala na jego sprawne przeprowadzenie na produkcji i zminimalizowanie niedostępności usług dla biznesu. Bardzo dużo zależy od pakietów instalacyjnych, które wykorzystywane są do wdrożenia wydania na produkcji, dlatego trzeba zwrócić szczególną uwagę, na ich przygotowanie. Najważniejsze aspekty to kompletność i instrukcje instalacji oraz poprawność przygotowanych paczek. Dobrze wykonana praca, zaowocuje krótszym czasem trwania wdrożenia i mniejszą ilością błędów, które podczas niego wystąpią. Warto poświęcić czas i energię w proces zarządzania wydaniem i wdrożeniami, aby zagwarantować sobie wysoki poziom usług na produkcji.

Pytanie: Jak często wdrażasz wydania na produkcję?

Artykuł Zarządzanie wydaniami i wdrożeniami pochodzi z serwisu Mariusz Siek.

W grupie procesów, odpowiedzialnych za przejście z etapu projektowania i wytwarzania do etapu eksploatacji usługi IT, jest w ITIL nowy proces zarządzania walidacją i testowaniem usług IT. Nie jest to nowa dziedzina, bo samo testowanie oprogramowania ma długą historię i jest samodzielnym obszarem. Ponieważ jest on bardzo ważny w dostarczaniu poprawnie działających usług, warto zastanowić się, jakie są jego najważniejsze elementy i na co trzeba zwrócić uwagę. Uważam, że proces ten nie jest właściwie doceniany i wykorzystywany, a konsekwencje tego widzimy w działaniu usług IT na produkcji.

Konsekwencje

Czy na co dzień zastanawiamy się, jaka jest różnica pomiędzy walidacją a testowaniem?

Walidacja to sprawdzenie, czy usługa spełnia zdefiniowane wymagania biznesu a testowanie, ma za zadanie, wykrycie wszystkich błędów w działaniu usługi.

Jakie są konsekwencje, niewystarczającej i źle przeprowadzonej walidacji i testowania usługi?

• Występują incydenty, wynikające z błędów lub niewłaściwego zrealizowania wymagań biznesu
• Wymagane jest większe wsparcie Service Desk w wyjaśnieniu i tłumaczeniu, niewłaściwie działających usług
• Trudniej zdiagnozować i wykryć błędy i problemy w funkcjonowaniu usługi
• Mamy większe koszty, związane z naprawą błędów na produkcji, zamiast podczas etapu testowania rozwiązania
• Dajemy mniejszą wartość usługi dla klienta, z powodu jej nieefektywnego działania

Cele

Głównym celem procesu walidacji i testowania usługi jest zapewnienie, że nowe lub zmienione usługi IT, spełniają wymagania projektowe i odpowiadają na potrzeby biznesu.

Ważnymi elementami procesu są również:

• Zagwarantować, że wydanie zawiera nową lub zmienioną usługę, która przyniesie oczekiwane rezultaty i wartość dla klienta w ustalonych kosztach, zasobach i warunkach brzegowych.
• Zapewnić odpowiednią jakość wydaniu i wszystkim elementom wchodzącym w jego skład
• Sprawdzić, że usługa spełnia wymagania funkcjonalne biznesu i dostarcza oczekiwaną użyteczność
• Zweryfikować, że usługa spełnia wymagania niefunkcjonalne takie jak: dostępność, wydajność, niezawodność, bezpieczeństwo
• Potwierdzić, że wymagania klienta dla nowych lub zmienionych usług są poprawnie zdefiniowane oraz podjęte zostały działania aby wyeliminować błędy przed wdrożeniem na produkcję
• Zaprojektować i wdrożyć, dobrze zorganizowany proces walidacji i testowania, który dostarczy wiarygodnych dowodów, że zostały spełnione wymagania funkcjonalne i niefunkcjonalne dla usługi
• Wykryć, ocenić i zaadresować zagadnienia, błędy i ryzyka na etapie wdrożenia (przejścia)

Zakres

Proces walidacji i testowania jest wykorzystywany do:

• Oceny jakości wszystkich aspektów związanych z usługą i jej dostawcą
• Weryfikacji usług dostarczanych przez wewnętrzne zespoły, jak i dostawcę zewnętrznego.
• Nowych usług, jak i dla zmian wprowadzanych w usługach lub ich komponentach.
• Wykonania weryfikacji w środowisku biznesowym i sprawdzenia wszystkich aspektów, związanych z działaniem usługi, w tym takich, które nie zależą od dostawcy usługi np. sieć publiczną (Internet), zasoby klienta.

Testowanie bardzo mocno związane jest z procesem zarządzania wydaniem i wdrożeniem i wspiera go bezpośrednio, na różnych etapach.

Wyniki testów wykorzystywane są przez proces zarządzania zmianą, podczas oceny zmiany i ryzyka jej wprowadzenia na produkcję.

Korzyści

Jakie korzyści daje dobrze funkcjonujący proces walidacji i testowania:

• Zadowolony biznes, klient i użytkownik, z dostarczenia usługi spełniającej wymagania funkcjonalne i niefunkcjonalne
• Mniej błędów na środowisku produkcyjnym zgłaszanych przez użytkowników
• Większą dostępność usług dla użytkowników, związaną z mniejszą liczbą awarii
• Mniejsze koszty świadczenia usługi, wynikające z napraw na etapie testowania zamiast na produkcji
• Listę znanych błędów, wykrytych na etapie testowania, które nie zostały naprawione i wymagają obsługi na etapie utrzymania

Rodzaje testów

Ile mamy rodzajów testów?

• Testy funkcjonalne, nazywane również testami użyteczności, które powinny zawierać
  • Sprawdzenie dostępu do usługi (logowanie, zmiana hasła itp)
  • Weryfikację działania procesów biznesowych i wymaganych procedur
  • Przekazanie wiedzy i kompetencji
  • Kompatybilność i współdziałanie z innymi usługami i komponentami
  • Sprawdzenie dokumentacji
• Testy wydajnościowe, sprawdzające pojemność usługi
• Testy dostępności, weryfikujące wymagania związane z wysoką dostępnością
  • Testy kopii zapasowej i odtwarzania z backupu
  • Testy ciągłości działania
• Testy bezpieczeństwa, sprawdzające wszystkie aspekty związane z bezpieczeństwem
• Testy konfiguracji, tworzenia i instalacji wydania na produkcji
• Testy mierzenia i raportowania SLA dla usługi
• Testy procedur i instrukcji związanych z utrzymaniem usługi

W przypadku procesu walidacji i testowania, sprawdza się dobrze znana zasada z wojska: im więcej potu na ćwiczeniach tym mniej krwi i ofiar w walce i boju. Im więcej czasu, energii i zasobów poświęcimy na rzetelne przetestowanie usługi przed wdrożeniem, tym mniej problemów będziemy mieli, z działaniem tej usługi na produkcji. Oczywiście jak wszędzie musimy znaleźć złoty środek, aby etap testów nie sparaliżował nam cyklu wprowadzania zmian. Z drugiej strony nie możemy sobie pozwolić aby niewystarczająco przetestowane usługi, były implementowane na środowisku produkcyjnym i zaburzały prawidłowe działanie tej lub innych usług. Pamiętajmy, że koszt usunięcia błędów na etapie testowania jest mniejszy, niż gdy musimy je rozwiązywać na działającym środowisku produkcyjnym.

Pytanie: Których rodzajów testów nie wykonujesz i dlaczego?

Artykuł Walidacja i testowanie usług IT pochodzi z serwisu Mariusz Siek.

ITIL w wersji 3, czyli 11 lat temu, rozszerzył proces zarządzania konfiguracją na zarządzanie zasobami i konfiguracją (Service Asset and Configuration Management – SACM). Rewolucji nie było, proces tylko objął swoim zakresem, nie tylko typowe elementy informatyczne, które składają się na usługę ale również inne zasoby potrzebne do jej świadczenia. Proces ten jest bardzo ważny, ponieważ z danych przez niego zarządzanych korzystają inne procesy zarządzania usługami IT takie jak: zarządzanie zmianami, zarządzanie incydentami i problemami, zarządzanie poziomem usług. Co obejmuje proces SACM i jakie są jego najważniejsze elementy?

Cele

Głównym celem procesu zarządzania zasobami i konfiguracją jest zapewnienie, że zasoby wymagane do dostarczenia i świadczenia usług podlegają odpowiedniej kontroli, a dokładna i prawidłowa informacja o nich jest dostępna wtedy, kiedy jest taka potrzeba. Na tą informacje składają się dane o konfiguracji i relacjach pomiędzy zasobami.

Szczegółowymi celami są:

• Zapewnienie, że zasoby pod nadzorem IT są identyfikowane, kontrolowane i właściwie utrzymywane przez cały ich cykl życia
• Identyfikowanie, kontrolowanie, rejestrowanie, raportowanie, audytowanie i weryfikowanie usług i elementów konfiguracji w zakresie ich wersji, danych bazowych, komponentów składowych, atrybutów i relacji.
• Odpowiedzialność za zarządzanie i ochronę integralności danych elementów konfiguracji w cyklu ich życia, poprzez bliską współpracę z procesem zarządzania zmianą.
• Zapewnienie integralności elementów konfiguracji, wymaganych do świadczenia usług, poprzez utworzenie i utrzymywanie systemu zarządzania konfiguracją (Configuration Management System – CMS)
• Utrzymywanie prawidłowej informacji o historycznej, aktualnej i planowanej konfiguracji usług i CI (element konfiguracji)
• Wspieranie efektywnych i wydajnych procesów zarządzania usługami IT, poprzez zapewnienie aktualnej informacji o konfiguracji, pozwalającej na podejmowanie decyzji w odpowiednim czasie np. akceptacja zmian i wydań lub rozwiązywanie incydentów i problemów

Zakres

Dlaczego zarządzanie zasobami i konfiguracją jest takie ważne? Do wyjaśnienia potrzebne jest zdefiniowanie, co to jest zasób (asset) i jak się ma do elementu konfiguracji (Configuration Item – CI).

Zasób związany z usługą IT, który wymaga zarządzania, aby dostarczyć tą usługę nazywamy elementem konfiguracji.

Każdy element konfiguracji jest zasobem ale nie każdy zasób jest elementem konfiguracji. Np. serwer jako fizyczne urządzenie będzie zarówno zasobem jak i elementem konfiguracji, natomiast wiedza Service Desk do rozwiązywania incydentów, jest bardzo ważnym zasobem ale nie jest elementem konfiguracji i jako taka nie jest objęta procesem SACM.

Zakresem procesu SACM jest zarządzanie pełnym cyklem życia wszystkich elementów konfiguracji i wprowadzanymi do nich zmianami. Proces SACM ma wiele interfejsów do innych procesów zarządzania usługami IT, takich jak zarządzanie zmianą, incydentami, problemami, poziomem usług.

W zakresie procesu nie ma zarządzania środkami trwałymi, rozumianego jako zarządzanie zasobami w aspekcie finansowym, chociaż oba procesy mogą obejmować te same zasoby.

Korzyści

Wdrożenie i korzystanie z procesu zarządzania zasobami i konfiguracją daje wiele korzyści organizacji.

• Optymalny proces SACM zapewnia wydajność świadczonych usług IT oraz zmniejsza ich koszty i ryzyka
• Jest nieocenionym źródłem wiedzy dla pracowników IT o konfiguracji usług i ich relacjach z elementami konfiguracji
• Pozwala lepiej planować zmiany i wydania
• Zwiększa szanse na zakończenie sukcesem oceny, planowania i wdrażania zmian i wydań
• Zapewnia rozwiązywanie incydentów i problemów zgodnie z SLA
• Pomaga w lepszym dopasowaniu do standardów oraz regulacji prawnych
• Daje możliwość wyznaczania kosztów usługi
• Umożliwia zmniejszenie kosztów i nakładów czasu na znalezienie informacji o konfiguracji

Podstawowe terminy

W dobry zrozumieniu procesu zarządzania zasobami i konfiguracją, pomaga poznanie i rozróżnianie następujących terminów:

• Zasób usługi (service asset)– każdy zasób lub zdolności (umiejętności) potrzebne do świadczenia usługi. Przykładowe zasoby usługi to fizyczny lub wirtualny serwer, licencja oprogramowania lub wiedza w głowie menedżera.
• Element konfiguracji (configuration item)– zasób usługi, który musi być zarządzany, w celu dostarczenia usługi IT. Wszystkie CI są zasobami usługi. Każdy CI musi być pod kontrolą procesu zarządzania zmianą.
• Rekord konfiguracji (configuration record)– zestaw atrybutów i relacji dotyczących CI. Rekordy konfiguracji są przechowywane w CMDB i zarządzane przez CMS. Zwracam uwagę, że CI nie są przechowywane w CMDB, tylko rekordy konfiguracji, opisujące CI, znajdują się w CMDB.
• System zarządzania wiedzą o usłudze (service knowledge management system – SKMS)– zestaw narzędzi i baz danych wykorzystywanych do zarządzania wiedzą, informacją i danymi. Wiele elementów konfiguracji jest dostępne w postaci wiedzy i informacji. Przykładowe to SLA, raporty, katalog usług. Są one przechowywane w SKMS ale proces SACM nie jest odpowiedzialny za zarządzanie tą bazą.

Proces zarządzania zasobami i konfiguracją jest źródłem wiedzy, informacji i danych, dla procesów zarządzania zmianami, wydaniami, incydentami, problemami i poziomem usług. Bez niego wskazane procesy, nie mogły by działać poprawnie. Pełni rolę procesu wspierającego i to jak będzie funkcjonował i jak zarządzał powierzonymi elementami konfiguracji, ma znaczący wpływ na działanie innych procesów zarządzania usługami, a w rezultacie na jakość świadczonych usług IT dla użytkownika. Sprawdź jak proces zarządzania zasobami i konfiguracją funkcjonuje w Twojej organizacji i podejmij działania, które poprawią wykryte błędy i niedociągnięcia.

Pytanie: Jaki aspekt procesu zarządzania zasobami i konfiguracją jest dla Ciebie najważniejszy?

Artykuł Zarządzanie zasobami i konfiguracją pochodzi z serwisu Mariusz Siek.

Napisałem już dwa artykuły o zarządzaniu zmianą, jednak cały czas mam nieodparte wrażenie, że nie wyczerpałem tematu. Po pierwsze dlatego, że proces jest bardzo złożony i może mieć kilka wariantów. Po drugie, jest jednym z ważniejszych procesów ITSM w każdej organizacji. Na co jeszcze warto zwrócić uwagę, co jest istotnym elementem, który decyduje, czy dobrze czy źle działa on u nas w firmie?

Rodzaje zmian

Mamy trzy rodzaje zmian, które możemy wprowadzać w organizacji: standardowa, pilna i normalna. Z każdą wiąże się inny sposób postępowania i inny jest cel jej zastosowania. Można powiedzieć, że dobieramy narzędzie do pracy jaką mamy wykonać.

• Zmiana standardowa stosowana jest w sytuacji niskiego ryzyka, powszechnie wykonywanych aktywności, dla których określone są procedury i instrukcje i jest wstępnie autoryzowana
• Zmiana pilna wykorzystywana jest, gdy musimy wprowadzić zmianę tak szybko jako to możliwe w celu rozwiązania krytycznego incydentu lub wdrożenia poprawki bezpieczeństwa
• Zmiana normalna obejmuje pozostałe przypadki, nie wskazane dla zmiany standardowej i pilnej.

Zmiana standardowa

Każda zmiana standardowa powinna korzystać z ustalonego modelu zmian, który określa jak z nią postępować, począwszy od tego, jak powinna być rejestrowana, przez sposób zarządzania po jak powinna być wdrażana.

Dla zmiany standardowej jej autoryzacja jest zdelegowana z menedżera zmian na inną rolę, np zarządzającego licencjami, service desk, dział zakupów itp.

Najważniejsze elementy związane ze zmianą standardową to:

• Ustalone zdarzenie wyzwalające zmianę takie jak service request lub wyjątek powstały w procesie zarządzania zdarzeniami
• Zadania są dobrze znane, udokumentowane i sprawdzone
• Autoryzacja zmiany jest z góry przekazana do innych ról
• Akceptacja finansowa jest z góry ustalona lub pod kontrolą wnioskującego o zmianę
• Ryzyko jest zwykle niskie i dobrze rozumiane

Jeżeli zmiana spełnia powyższe kryteria, może być wdrażana w tym trybie. Jest to duże ułatwienie i uproszczenie, dla wprowadzania znacznej ilości zmian. Sprawdź jak dużo zmian możesz wprowadzać w ten sposób i korzystaj z niego codziennie.

Zmiana pilna

Ten rodzaj zmiany powinien być wykorzystywany tylko w wyjątkowych sytuacjach. Głównie gdy usługa IT przestaje działać a sposobem na jej uruchomienie jest wprowadzenie zmiany. Mimo krótkiego czasu na procesowanie zmiany nie należy zapominać o:

• Uzyskaniu akceptacji zmiany przez radę ds. zmian pilnych (ECAB). Szczególnie taka zmiana wymaga akceptacji, odpowiednich osób, aby nie wprowadziła więcej i większych problemów, niż te które ma rozwiązać. Procedura dla zmiany pilnej musi jasno określać, kto podejmuje decyzje o wprowadzeniu tego rodzaju zmiany.
• Przetestowanie zmiany, przed wdrożeniem na produkcję. Mimo pośpiechu i chęci jak najszybszego przywrócenia usługi IT do działania, nie można pominąć kroku związanego z skutecznym sprawdzeniem, czy zaproponowane rozwiązanie jest prawidłowe i efektywnie rozwiąże awarię. Tylko w szczególnych przypadkach, można zdecydować o wdrożeniu zmiany, bez jej testowania. Powinna to jednak być świadoma i podjęta jednogłośnie decyzja.
• Ocenie wpływu zmiany w jednej usłudze na działanie pozostałych usług. Analizy wpływu musi być przeprowadzona i być podstawą do podjęcia decyzji o akceptacji zmiany.

Zmiana normalna jest nudna, dlatego nie będę się o niej się rozpisywał :-). Chciałem jednak zwrócić uwagę na jeden element, który powinien występować, dla każdej z rodzajów zmian.

Plan wycofania

Plan wycofania to bardzo ważny element dla wprowadzania zmian. Zawsze może coś pójść nie tak i musimy mieć plan postępowania na tę okoliczność. Wiem, że większość zespołów zakłada, że wszystko pójdzie dobrze i po co tracić czas na przygotowywanie planu wycofania. Jak jednak pokazuje życie, może zdarzyć się taka sytuacja i musimy być na nią przygotowani. Pamiętajmy, że plan wycofania powinien być przetestowany i uwzględniony w czasie trwania zmiany, a tym samym niedostępności usługi. Plan wycofania musimy mieć opracowany i przetestowany, zarówno dla zmiany normalnej jak i pilnej. W przypadku zmiany standardowej, możemy mieć go uwzględnionego w procedurze lub instrukcji, na podstawie której wykonywana jest zmiana.

Miałem świadomość, że proces zarządzania zmianą jest obszerny ale nie sądziłem, że pokazania jego najważniejszych elementów jest tak trudne w kilku artykułach. Wygląda na to, że będę musiał jeszcze pociągnąć ten temat w kolejnym tygodniu.

Podsumowując. Korzystaj ze wszystkich rodzajów zmian a zwiększysz sprawność swojej organizacji w zarządzaniu zmianami. Nie zapomina tylko, że każda zmian musi być zaakceptowana (autoryzowana), przetestowana i mieć plan wycofania.

Pytanie: Które rodzaje zmian najczęściej stosujesz i dlaczego?

Artykuł O czym zapomniałeś zarządzając zmianą? pochodzi z serwisu Mariusz Siek.

Tak jak obiecałem, poruszam temat zarządzania zmianą IT. Jest to jeden z najważniejszych i kluczowych procesów w zarządzaniu usługami IT, który ma wpływ na pozostałe. Od jakości funkcjonowania procesu zarządzania zmianą IT zależy, jaka będzie dostępność usług, czy IT będzie spełniało oczekiwania biznesu, na wprowadzanie wymaganych zmian, jak będziemy dbali o bezpieczeństwo informatyczne. Zarządzanie zmianą jest postrzegane w organizacji, jako biurokracja i zbędny nakład pracy. Czy takie opinie są słuszne i właściwie oceniają rolę procesu? Przyjrzyjmy się najważniejszym zagadnieniom w procesie zarządzania zmianą aby rozwiać powstające wątpliwości.

Źródła zmian

Generalnie możemy wskazać dwa źródła zmian:

• Pierwsze wynikające z działań biznesowych mających na celu wdrażanie nowych usług lub usprawnianie już istniejących. Nazywane bywa również proaktywnym.
• Drugie wynika z obsługi incydentów i problemów i nazywane bywa reaktywanym.

Mamy tu pewną analogię do procesu zarządzania problemami i podobieństwo w podejściu.

Dla kogo proces zarządzania zmianą?

Proces zarządzania zmianą można zastosować w każdej organizacji. Może on być bardzo złożony albo bardzo prosty. Znajdzie swoją implementację w różnej wielkości i rodzaju organizacji. Można z niego skorzystać wprowadzając małe i duże zmiany, na każdym etapie cyklu życia usługi. Nie ma znaczenie czy zmiana ma duży czy mały wpływ oraz jak jest planowana. Można go zastosować do zmian o różnym budżecie i poziomie finansowania. Jednym słowem proces zarządzania zmianą można zastosować wszędzie.

Cele i oczekiwania

Celem procesu zarządzania zmianą jest nadzorowanie cyklu życia wszystkich zmian, w celu umożliwienia wdrożenia korzystnych zmian, z jak najmniejszym zagrożeniem dla działania produkcyjnych usług IT. Dobrze wdrożony i funkcjonujący proces zarządzania zmian powinien:

• Odpowiadać na zmieniające się wymagania biznesu, poprzez zwiększanie wartości oraz zmniejszanie incydentów, zagrożeń i dodatkowej pracy
• Odpowiadać na żądania zmian z biznesu i IT, które będą spełniały potrzeby biznesu
• Zapewniać, że zmiany są rejestrowane i oceniane, a zatwierdzone zmiany mają określany priorytet i są planowane, testowane, wdrażane, dokumentowane i przeglądane w kontrolowany sposób.
• Zapewniać, że wszystkie zmiany do elementów konfiguracji są rejestrowane w systemie zarządzania konfiguracją (Configuration Management System – CMS)
• Dążyć do optymalizacji całego ryzyka biznesowego, zarówno go minimalizując jak i akceptując, jeżeli daje szansę na korzyści dla biznesu

Zakres

Informację o zakresie zacznijmy od definicji zmiany według ITIL

„Dodanie, modyfikacja lub usunięcie dowolnego elementu konfiguracji, który może mieć wpływ na działanie usługi IT”.

Szczerze mówiąc bardziej podoba mi się definicja z książki „Projekt Feniks”.

„Dowolna fizyczna, logiczna lub wirtualna operacja dotycząca aplikacji, baz danych, systemów operacyjnych, sieci oraz sprzętu, która może wpływać na świadczenie usług”

Zmiany mogą dotyczyć wszystkich elementów konfiguracji w całym ich cyklu życia, takich jak:

• zasoby fizyczna jak serwery, macierze, przełączniki, routery itp.
• zasoby wirtualne jak serwery wirtualne lub macierze wirtualne
• zasoby informacyjne jak umowy i porozumienia, w tym katalog usług, SLA itp.

Zarządzanie zmianą. Dotyczy wszystkich zmian związanych z pięcioma aspektami projektowania usług:

• Rozwiązania dla nowych lub zmienianych usług, zawierające wymagania biznesowe
• Narzędzia i systemy do zarządzania informacją oraz zarządzania i kontroli usług w ich cyklu życia
• Architektura w zakresie technologii i zarządzania, wymagana do dostarczenia usługi
• Procesy potrzebne do zaprojektowania, wdrożenia, działania i poprawy usługi
• Systemy, metody i metryki pomiarowe dla usług, architektury, komponentów i procesów

Poza procesem zarządzania zmianą są zmiany związane z:

• Znacznie większym wpływem niż zmiana usługi, np zmiana struktury organizacyjnej
• Zmianami na poziomie operacyjnym np. naprawa drukarki lub innych standardowych komponentów

Zarządzanie zmianą nie odpowiada za koordynowanie wszystkich procesów zarządzania usługami IT, mające na celu bezproblemowe wdrożenie projektu. Te aktywności są przeprowadzane przez proces planowania i wsparcia wdrożenia.

Korzyści dla biznesu

Proces zarządzania zmianą daje wymierne korzyści.

• Ochrona biznesu i innych działających usług, podczas wprowadzania zmian
• Wdrażanie zmian, które spełniają uzgodnione wymagania klienta i są optymalne kosztowo
• Zmniejszenie nieudanych zmian, a dzięki temu zakłócenia działania usług
• Zmniejszenie nieautoryzowanych zmian, a w konsekwencji zakłócenia działania usług oraz czasu obsługi incydentów
• Bezzwłoczne dostarczanie zmian zgodnie z wymaganiami biznesu
• Śledzenie zmian przez cały czas życia usługi
• Przyczynianie się do lepszego szacowania jakości, czasu i kosztu zmiany
• Ocena ryzyk związanych z wdrożeniem usługi
• Zwiększenie produktywności pracowników poprzez zmniejszenie nieplanowanych i pilnych zmian, co przekłada się na większą dostępność usług
• Zmniejszenie MTRS (średniego czasu odzyskiwania usługi) poprzez szybsze i bardziej skuteczne wdrażanie działań naprawczych
• Współpraca z procesem zarządzania zmianą biznesową w celu identyfikowania możliwości usprawnienia biznesu

Zmiana, RFC, rekord zmiany

Bardzo często pojęcie zmiany, RFC (Request for Change) i rekordu zmiany traktowane są jako tożsame. Tak jednak nie jest. Zmiana określona jest poprzez definicję w punkcie Zakres. RFC to formalna propozycja zmiany, zawierająca szczegółowe informacje związane ze zmianą. Rekord zmiany zawiera wszystkie szczegółowe informacje związane ze zmianą, w tym dokumentuje cykl życia zmiany. Nie mylmy więc tych trzech pojęć ponieważ oznaczają coś innego.

Proces zarządzania zmianą, powinien być oczywiście wspierany przez narzędzie (narzędzia), które pozwolą na wystawianie RFC i procesowanie zmiany w trakcie jej cyklu życia. Dobrze aby proces był zintegrowany z CMDB a najlepiej z CMS aby można było oceniać wpływ zmiany na elementy konfiguracji i działające usługi oraz zasięgać informacji o usługach IT i ich parametrach SLA.

Pytanie: Jakie zmiany wprowadzasz najczęściej?

Artykuł Zarządzanie zmianą IT – proces pochodzi z serwisu Mariusz Siek.

Czytam właśnie książkę „Projekt Feniks” i uświadomiłem sobie, chociaż zawsze o tym wiedziałem, jak bardzo ważny jest w organizacji proces zarządzania zmianami IT. O samej książce napiszę recenzję jak skończę czytać, bo warto zapoznać się z tą pozycją.

Wydawało mi się, że żadna organizacja, nie może funkcjonować, nie mówię o efektywnym działaniu, bez wdrożonego i działającego sprawnie procesu zarządzania zmianą. Przykład z książki, chociaż tylko hipotetyczny, pokazuje że jednak są takie firmy, gdzie nikt nie panuje nad zmianami. Czy ten przypadek jest odosobniony i wszystkie organizacje mają świadomość ważności tego procesu? Jak wdrożyć i stosować proces aby nie sparaliżować funkcjonowania firmy i jego działu IT?

Proces – strażnik zmian

Nad zorganizowanym, efektywnym i bezpiecznym sposobem wprowadzania zmian, czuwa proces zarządzania zmianą. Wiem, że w IT i nie tylko nikt nie lubi procesów ITSM i uważa je za formalizmy i biurokrację, która jest hamulcowym, dla działań i prac jakie muszą wykonywać specjaliści. Nikt jednak nie wymyślił nic lepszego, a proces wprowadza zasady, które ustalają sposób postępowania ze zmianą i pozwala ją kontrolować. Kluczowa również jest rola menedżera zmian (change manager), który jest „złym” policjantem, pilnującym aby zmiany były wprowadzane tylko w ramach procesu oraz według wymagań w nim określonych. W większości organizacji jest to praca na pełny etat, a w bardzo dużych organizacjach potrzebujemy więcej niż jedną osobę do pełnienia tej roli.

Ważną funkcję pełni również rada ds. zmian (change advisory board – CAB), która jest ciałem doradczym i opiniującym zmiany.

Dobrze zaprojektowane i wdrożone zarządzanie zmianą IT, daje gwarancję i bezpieczeństwo organizacji, że nie będzie ona działać sama na swoją szkodę. To pewnego rodzaju zabezpieczenie, które chroni firmę samą przed sobą.

Niestety w książce „Projekt Feniks”, proces zarządzania zmianą, nie funkcjonuje zupełnie. Jest omijany na każdym kroku, między innymi przez brak dedykowanej osoby do pełnienia roli menadżera zmian.

Ja osobiście nie spotkałem się z takim przypadkiem. Moje doświadczenie z procesem zarządzania zmianą, pokazuje że zawsze był używany i lepiej lub gorzej kontrolował wprowadzane na produkcję zmiany.

Narzędzie

Nie można dobrze wykorzystywać zarządzania zmianą IT, bez zaimplementowania go w narzędziu, które będzie go wspierać. Słowo „wspierać” jest tu kluczowe. Narzędzie może pomóc w korzystaniu z procesu lub wręcz przeciwnie zniechęcić do niego. Jeżeli tylko mamy dobrze zaprojektowany proces zarządzania zmianą, na pewno znajdziemy narzędzie, w którym będziemy mogli go zaimplementować. Rynek obecnie dostarcza bardzo duży wybór takich narzędzi, nie znaczy, że wybór przez to jest łatwiejszy :-). Najważniejsze jest zaimplementowanie workflow oraz takie zaprojektowanie pól do wypełnienia aby wymagać tylko niezbędnych informacji, nie zniechęcając przy tym do korzystania z nich.

W „Projekt Feniks” mieli wdrożone narzędzie, jednak nikt z niego nie korzystał. Dlaczego? Tłumaczyli, że wprowadzanie i procesowanie zmiany zajmuje więcej niż jej wykonanie. Aby reanimować proces zarządzania zmianą, uruchomili zgłaszanie zmian na „karteczakch”, które wieszali na tablicach i w ten sposób, kategoryzowali zmiany i zarządzali harmonogramem ich wprowadzania. Doliczyli się prawie 1000 zmian w tygodniu. Ciekawe dokąd ich ten sposób zaprowadzi?

Ja osobiście wykorzystywałem różne narzędzia. Zaczynałem nawet z pomocą Microsoft Sharepoint ale najwięcej korzystałem z HPSM i Atlassian Jira. Według mnie Jira jest jednym z lepszych narzędzi do implementacji procesów ITSM, w tym zarządzania zmianami.

Zmiana

Jedną bardzo ważną rzecz również uświadomiło mi książka. Co rozumiemy przez zmianę? Jakie aktywności powinny podlegać procesowi? Spodobała mi się definicja zmiany z książki 

„Dowolna fizyczna, logiczna lub wirtualna operacja dotycząca aplikacji, baz danych, systemów operacyjnych, sieci oraz sprzętu, która może wpływać na świadczenie usług”.

Co to oznacza w praktyce? Każdy restart serwera, cykliczne uruchomienie skryptu lub procedury, włączenie lub wyłączenie serwera jest zmianą. Ktoś może powiedzieć, że nie uda się zarządzać takimi zmianami w procesie zarządzania zmianą. Niestety nie ma racji. Proces daje nam do tego typu zmian narzędzie w postaci zmiany standardowej, która jest autoryzowana, niesie za sobą niskie ryzyko, jest powszechnie wykonywana i dobrze opisana w instrukcjach i procedurach.

W mojej ocenie, zmiana standardowa nie jest w wystarczającym stopniu spopularyzowana i wykorzystywana w organizacjach IT, co jest dużym błędem i zmniejsza świadomość ludzi z IT, jaki wpływ mają ich działania, na funkcjonowanie produkcyjnych usług.

Zarządzanie zmianą IT, to jeden z ważniejszych i popularnych procesów ITSM. Mimo częstego oporu i prób jego obchodzenia, jest stosowany w większości organizacji IT. Nie jest to widzi misie ludzi z IT ale codzienna konieczność, jeżeli chcemy mieć kontrolę, nad tym co jest wdrażane i wykonywane na środowisku produkcyjnym, a co może mieć negatywny wpływ na świadczenie usług dla biznesu. Będę musiał poświęcić temu zagadnieniu oddzielny artykuł aby przybliżyć najważniejsze aspekty procesu zarządzania zmianą. Może już w następnym tygodniu? :-).

Pytanie: Jaka jest definicja zmiana w Twojej organizacji?

Artykuł Zarządzanie zmianą IT – jak nie sparaliżować firmy? pochodzi z serwisu Mariusz Siek.