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.

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.

Jednym z niedocenianych i nie w pełni wykorzystywanych procesów ITIL, jest proces zarządzania problemami. Wynika to z wielu powodów. Jednym z nich jest błędne rozróżnianie incydentu, znanego błędu i problemu i taktowanie ich jako tych samych zdarzeń. Drugim bardzo częstym błędem jest łączenie roli managera incydentów i problemów, co zaciera różnice pomiędzy obydwoma procesami oraz wprowadza niepoprawne zrozumienie, jakie są ich pryncypia. Przybliżę trochę proces zarządzania problemami aby lepiej go zrozumieć i docenić jego bardzo ważną, proaktywną rolę w zarządzaniu usługami IT.

Cel

Celem procesu zarządzania problemami jest zminimalizowanie negatywnego wpływu incydentów i problemów na działanie biznesu oraz proaktywne zapobieganie pojawiania się incydentów związanych ze znanymi błędami.

Kluczowe działania, jakie powinny być wykonywane w tym procesie to:

• Zapobieganie występowaniu problemów i incydentów
• Eliminowanie powtarzających się incydentów
• Minimalizowanie wpływu incydentów, którym nie można zapobiec

Incydenty a problemy

Incydenty mogą powodować powstanie problemów ale nie muszą. Jednocześnie rozwiązanie występujących problemów, powinno zapobiec występowaniu, związanych z danym problemem incydentów.

Procesy zarządzania incydentami i problemami są niezależne i mają całkiem inny charakter, jednak mają również wiele punktów wspólnych takich jak: narzędzie (klasy ITSM, baza znanych błędów), kategoryzacja zgłoszeń, wpływ i priorytet zgłoszeń.

Mimo tych bliskich relacji, nadal nie powinniśmy łączyć tych procesów, w szczególności jedną osobą, która za nie odpowiada.

Reaktywnie vs. proaktywnie

Proces zarządzania problemami ma dwa oblicza: reaktywne (zdarzeniowe) i proaktywne (ciągłe). Reaktywne, wywoływane jest poprzez wystąpienie incydentu lub incydentów. Głównym jego celem jest zapobiegnięcie wystąpienia incydentów w przyszłości i wskazanie obejść, jeżeli są możliwe do zastosowania.

Proaktywne, wywoływane jest poprzez działania związane z ciągłą poprawą usług. Przykładowym działaniem proaktywnym jest analiza trendów, mająca na celu znalezienie nieznanych przyczyn historycznych incydentów. Aktywności z proaktywnego zarządzania problemami uzupełniają proces ciągłej poprawy usług (Continual Service Improvement).

Jeżeli nawet mamy już funkcjonujący proces zarządzania problemami, to zbyt dużą wagę przywiązujemy do działań reaktywnych, zamiast większość czasu poświęcać na działania proaktywne, takie jak:

• Identyfikowanie i rozwiązywanie problemów i znanych błędów zanim wystąpią kolejne incydenty
• Przeprowadzanie okresowych przeglądów incydentów w celu znalezienia trendów i schematów
• Wykonywanie przeglądów awarii (major incident)
• Przeprowadzanie okresowych przeglądów logów i źródeł utrzymaniowych
• Przeprowadzanie burzy mózgów w celu zidentyfikowania ewentualnych problemów
• Stosowanie list kontrolnych do proaktywnego zbierania danych o usługach, w celu wykrycia niezidentyfikowanych błędów

Działania proaktywne przynoszą znacznie więcej korzyści, niż działania reaktywne i powinny być wykonywane ciągle aby poprawiać poziom usług oraz zwiększać wartość dla biznesu.

Wartość dla biznesu

Właściwie to dlaczego mamy podejmować działania proaktywne, skoro ledwo wystarcza nam czasu na reaktywne działania? Odpowiedź brzmi bo warto :-). Korzyści są zarówno dla biznesu jak i dla IT. Najważniejsze z nich to:

• Wyższa dostępność usług IT. Zarejestrowane rozwiązania incydentów przyspieszają rozwiązania nowych, zmniejszając ilość i czas rozwiązania incydentów
• Wyższa produktywność pracowników IT, poprzez nie wykonywanie nie zaplanowanych prac, wynikających z obsługi incydentów i krótszy czas spędzany nad rozwiązaniem nowych incydentów, dzięki znanym błędom i obejściom.
• Zmniejszone koszty związane z obejściami i poprawkami, które nie są skuteczne
• Zmniejszenie wysiłków związanych z „gaszeniem pożarów” i rozwiązywaniem powtarzających się incydentów

Techniki rozwiązywania problemów

Jest wiele metod i sposobów aby skutecznie rozwiązywać problemy. Przykładowe z nich podałem poniżej. Resztę znajdziesz w publikacji ITIL v3 Service Operation.

• Analiza chronologiczna. Najprostszy sposób, analizujący wszystkie zdarzenia i powiązania pomiędzy nimi w porządku ich występowania.
• Analiza oddziaływania na biznes. Określamy dla problemu na ile osób miał wpływ, jaki był czas trwania niedostępności, jakie były koszty awarii dla biznesu.
• Analiza Kepner i Tregoe, która mówi
  • Zdefiniuje problem
  • Opisz problem w zakresie tożsamości, lokalizacji, czasu i wielkości
  • Określ możliwe przyczyny
  • Przetestuj najbardziej prawdopodobne przyczyny
  • Zweryfikuje i ustal prawdziwą przyczynę

Proces zarządzania problemami, pełni bardzo ważną funkcję w zarządzaniu usługami IT, w szczególności jego proaktywna część. Zwróć uwagę jak ten proces działa u Ciebie. Pamiętaj, że nie trzeba rozwiązać wszystkich problemów. W wyniku analizy można uznać, że koszt usunięcia problemu jest za wysoki i nie opłaca się tego robić. To też jest sposób na obsłużenie problemu ale musi zostać podjęte z sposób jak najbardziej świadomy.

Pytanie: Jakie działania proaktywne podejmujesz w procesie zarządzania problemami?

Artykuł Proaktywnie zarządzaj problemami! pochodzi z serwisu Mariusz Siek.