Znacie to uczucie? Wchodzicie na spotkanie zarządu. Po jednej stronie stołu siedzi „Biznes” – panowie w drogich garniturach i panie z tabletami, które liczą ROI szybciej niż wy wpisujecie hasło do roota. Po drugiej stronie siedzi „IT” – ludzie, którzy wiedzą, czym jest Kubernetes, ale boją się kontaktu wzrokowego.

Atmosfera gęstnieje.

Dyrektor Finansowy pyta: „Dlaczego wczoraj nie mogliśmy wystawiać faktur przez dwie godziny?! Ile na tym straciliśmy?”.

A szef infrastruktury, patrząc w buty, odpowiada: „Mieliśmy niespodziewany skok utylizacji CPU na klastrze bazodanowym spowodowany nieoptymalnym query i musieliśmy zrestartować serwis, żeby zwolnić locki”.

Cisza.

Dyrektor Finansowy słyszy: „Byliśmy zajęci psuciem rzeczy i w sumie to nie nasz problem, to wina query”.

Informatyk myśli: „Wyjaśniłem przecież dokładnie, o co chodzi, czepiają się”.

I tu, cały na biało (albo w smart casual), wchodzi on. Business Relationship Manager (BRM).

Mówi: „Mieliśmy zator w systemie, bo wpłynęło nietypowo dużo zamówień naraz. System się przytkał, ale już działa. Żeby to się nie powtórzyło przy Black Friday, musimy dokupić trochę mocy obliczeniowej. Kosztuje to tyle, co połowa tego, co wczoraj straciliśmy”.

Biznes kiwa głową: „Kupujcie”.

IT oddycha z ulgą: „Dostaniemy nowy sprzęt”.

O tym dzisiaj będzie. O tym, że BRM w ITIL 4 to nie jest kolejna nudna rola dla kogoś, kto nie umie kodować. To jest, moi drodzy, tłumacz symultaniczny z języka „nerd” na język „pieniądz”.

ITIL 4, czyli koniec z siedzeniem w piwnicy

Kiedyś IT było dostawcą usług. Jak elektrownia. Pstrykasz i ma być światło. Jak nie ma, to dzwonisz z awanturą. Ale ITIL 4 wywrócił to do góry nogami. Teraz nie jesteśmy „dostawcą”, jesteśmy „partnerem”. Mówimy o współtworzeniu wartości (Value Co-creation). Piękne hasło, prawda? Ale co ono znaczy w praktyce?

Znaczy tyle, że IT nie może już tylko „dowozić ticketów”. Musi rozumieć, po co ten biznes w ogóle istnieje. I tu wkracza BRM.

BRM to taki most nad przepaścią. Albo lepiej – terapeuta małżeński. Jego zadaniem jest sprawić, żeby te dwa światy, które z natury się nie rozumieją, zaczęły ze sobą rozmawiać, a nie tylko na siebie warczeć.

Dyplomata w strefie wojny, czyli zarządzanie oczekiwaniami

Największy błąd IT? Obiecywanie gruszek na wierzbie, żeby tylko „Biznes” dał im spokój.

– „Zrobicie nam tę aplikację na wczoraj?”

– „Yyy, no postaramy się”.

A potem jest płacz i zgrzytanie zębów, bo „postaramy się” dla biznesu znaczy „będzie gotowe”, a dla programisty „spróbuję, jak skończę kawę i trzy inne projekty”.

Kluczową kompetencją BRM-a jest Expectation Management, czyli brutalna szczerość ubrana w ładne słowa. BRM musi umieć powiedzieć „NIE”. Ale nie takie „nie, bo mi się nie chce”, tylko:

„Słuchajcie, możemy to zrobić na wczoraj, ale wtedy system X przestanie działać, a bezpieczeństwo będzie na poziomie hasła 'admin1′. Chcecie podjąć to ryzyko?”.

BRM to ten gość, który bierze wymagania biznesowe (często brzmiące jak list do Świętego Mikołaja) i zamienia je na specyfikację techniczną. A potem bierze specyfikację techniczną i tłumaczy biznesowi, dlaczego to tyle trwa i kosztuje. Bez niego IT robi to, co myśli, że jest potrzebne, a Biznes dostaje to, czego nie chciał.

Efekt Arbuza – zmora każdego CIO

Słyszeliście kiedyś o „Efekcie Arbuza” (Watermelon Effect)? To moje ulubione zjawisko w korporacjach, z którym BRM musi walczyć każdego dnia.

Wyobraźcie sobie taką sytuację: Mamy spotkanie przeglądowe SLA (Service Level Agreement). Wyświetlacie slajdy. Wszystko jest na ZIELONO.

• Dostępność serwera: 99,99% (Zielono!)
• Czas reakcji na zgłoszenie: < 15 min (Zielono!)
• Rozwiązanie incydentu: < 4h (Zielono!)

Jesteście z siebie dumni jak pawie. A po drugiej stronie stołu klient jest CZERWONY ze wściekłości. Jak to możliwe? Przecież SLA się zgadza!

Ano tak, że arbuz jest zielony na zewnątrz, a czerwony w środku.

Może i serwer działał przez 99,99% czasu, ale padł akurat w te 5 minut, kiedy Prezes robił najważniejszy przelew roku.

Może i czas reakcji był 10 minut, ale polegał na automatycznym mailu „Przyjęliśmy zgłoszenie”, po czym przez 4 godziny nikt nic nie zrobił, a Pani Krysia z księgowości nie mogła zamknąć miesiąca.

Statystyki są super, ale Experience (doświadczenie) użytkownika leży i kwiczy.

I tu rola BRM jest nieoceniona. To on nie patrzy tylko w Excela. On idzie do tej Pani Krysi, pije z nią kawę i pyta: „Słuchaj, jak ci się z nami pracuje?”. I wtedy dowiaduje się prawdy, której nie pokażą żadne systemy monitoringu. Dowiaduje się, że system co prawda działa, ale jest tak nieintuicyjny, że ludzie wolą liczyć na kalkulatorze.

BRM przebija tę zieloną skórkę arbuza i sprawdza, czy w środku nie ma krwistej miazgi.

Podsumowując: Po co ci ten BRM?

Możecie pomyśleć: „Eee tam, kolejne stanowisko dla kogoś, kto będzie chodził na lunche”. Błąd.

W nowoczesnym ITIL 4, gdzie technologia zmienia się szybciej niż nastroje nastolatka, potrzebujesz kogoś, kto trzyma rękę na pulsie relacji.

Bez BRM-a jesteście tylko „działem od komputerów”. Z dobrym BRM-em stajecie się strategicznym partnerem, bez którego firma nie może istnieć. BRM sprawia, że IT przestaje być kosztem, a zaczyna być inwestycją.

Więc jeśli jesteś informatykiem – znajdź swojego BRM-a i postaw mu piwo. On codziennie tłumaczy twoje „nie da się” na język, który sprawia, że nie zwalniają cię z pracy. A jeśli jesteś menedżerem i zastanawiasz się, dlaczego IT cię nie rozumie – może czas zainwestować w tłumacza?

Artykuł Most nad przepaścią: Jak BRM łączy „język IT” z „językiem biznesu” (i dlaczego to ratuje d#$&) pochodzi z serwisu Mariusz Siek.

W świecie zarządzania usługami IT (ITSM) dzieje się coś niezwykłego. Rewolucja napędzana przez sztuczną inteligencję (AI) zmienia fundamentalnie sposób, w jaki świadczymy i wspieramy usługi. W kontekście dynamicznie rozwijającego się frameworku ITIL 4, AI staje się nie tylko futurystyczną wizją, ale realnym narzędziem, które pozwala organizacjom osiągnąć niespotykaną dotąd efektywność. Co więcej, narzędzia takie jak Jira Service Management (JSM) są idealną platformą do wdrażania tych innowacji.

ITIL 4, ze swoim naciskiem na elastyczność, tworzenie wartości i adaptację do zmieniających się warunków, doskonale komponuje się z możliwościami, jakie oferuje sztuczna inteligencja. AI pozwala na automatyzację, optymalizację i poprawę jakości wielu procesów ITSM, z których niektóre wydawały się dotąd niemożliwe do efektywnego zarządzania.

AI w akcji: Kluczowe zastosowania w ITSM z Jira Service Management

Jak konkretnie AI zmienia ITSM, szczególnie w ekosystemie Jira Service Management? Oto kilka kluczowych obszarów:

• Inteligentne chatboty i automatyzacja L1: Zapomnijmy o monotonnych i czasochłonnych zadaniach na pierwszej linii wsparcia (L1). W Jira Service Management, dzięki integracji z rozwiązaniami AI, chatboty mogą samodzielnie rozwiązywać proste problemy, odpowiadać na często zadawane pytania (FAQ) i kierować użytkowników do odpowiednich zasobów. Odciążają one personel IT i skracają czas oczekiwania użytkowników, umożliwiając im szybkie uzyskanie pomocy bez angażowania człowieka.
• Inteligentne przypisywanie zgłoszeń: Jednym z wyzwań w zarządzaniu incydentami jest prawidłowe przypisywanie zgłoszeń do właściwych zespołów wsparcia. Algorytmy AI, zasilane danymi z JSM (treść zgłoszenia, historia podobnych problemów, statusy projektów, dostępność specjalistów), potrafią precyzyjnie przekierować zgłoszenie do najbardziej kompetentnego zespołu. Dzięki temu skraca się czas rozwiązania problemu i zwiększa satysfakcję użytkowników. Przykładowo, jeśli zgłoszenie dotyczy problemu z pocztą e-mail, AI automatycznie przydzieli je do zespołu odpowiedzialnego za systemy pocztowe.
• Analityka predykcyjna i proaktywne rozwiązywanie problemów: AI nie tylko reaguje na problemy, ale jest w stanie je przewidywać. Dzięki analizie ogromnych ilości danych dostępnych w JSM (logi systemowe, dane o wydajności, historia incydentów, metryki SLA), algorytmy predykcyjne mogą zidentyfikować potencjalne awarie, zanim one nastąpią. Pozwala to na proaktywne działania konserwacyjne, minimalizując przestoje i wpływ na użytkowników. Wyobraźmy sobie system, który sam wykrywa anomalie w sieci i zgłasza je w JSM, zanim użytkownicy zaczną odczuwać negatywne skutki.
• Optymalizacja zarządzania problemami i bazami wiedzy: AI może pomóc w identyfikacji przyczyn źródłowych problemów poprzez analizę korelacji między incydentami zarejestrowanymi w JSM. Dodatkowo, może wspomagać tworzenie i aktualizowanie baz wiedzy (np. w Confluence, często zintegrowanym z JSM), sugerując nowe artykuły na podstawie rozwiązanych problemów i najczęściej zadawanych pytań. Dzięki temu baza wiedzy jest zawsze aktualna i pomocna dla użytkowników lub grup wsparcia.

Dlaczego AI jest tak aktualna w ITSM?

Powodów, dla których AI jest jednym z najgorętszych tematów w IT i ma tak duży wpływ na ITSM, jest wiele:

• Rosnąca złożoność systemów IT: Współczesne środowiska IT są coraz bardziej skomplikowane i rozproszone, co generuje większą liczbę incydentów i zapytań. AI pomaga zarządzać tą złożonością w sposób skalowalny.
• Potrzeba szybszego rozwiązywania problemów: W dobie cyfryzacji, każda minuta przestoju to wymierne straty finansowe i negatywny wpływ na reputację dostawcy usług. AI znacząco przyspiesza procesy wsparcia i rozwiązywania incydentów.
• Rosnące oczekiwania użytkowników: Użytkownicy końcowi, przyzwyczajeni do błyskawicznej obsługi w innych dziedzinach życia, oczekują szybkiej, efektywnej i dostępnej 24/7 obsługi IT. AI pozwala sprostać tym oczekiwaniom.
• Dostępność danych i mocy obliczeniowej: Rozwój technologii chmurowych, takich jak te wspierające Jira Service Management, oraz postęp w obszarze Big Data sprawiają, że AI staje się coraz bardziej dostępna i efektywna w praktycznych zastosowaniach.

Przyszłość ITSM z AI i Jira Service Management

Integracja ITIL 4 z AI, zwłaszcza na platformach takich jak Jira Service Management, to nie tylko chwilowy trend, ale konieczność dla organizacji, które chcą pozostać konkurencyjne i świadczyć usługi IT na najwyższym poziomie. Sztuczna inteligencja nie zastąpi człowieka (chociaż dzisiaj trudno to przewidzieć), ale stanie się jego niezastąpionym partnerem, uwalniając personel IT od rutynowych zadań i pozwalając im skupić się na bardziej strategicznych wyzwaniach. To przyszłość, w której zarządzanie usługami IT jest inteligentne, proaktywne i przede wszystkim – zorientowane na użytkownika.

Czy Twoja organizacja jest gotowa na tę transformację?

Artykuł ITIL 4 i AI w ITSM (JSM): Jak sztuczna inteligencja zmienia oblicze zarządzania usługami IT? pochodzi z serwisu Mariusz Siek.

W pierwszej części artykułu opisałem kluczowe koncepcje praktyki Umożliwianie Zmian w ITIL 4. Teraz skupimy się na głębszym zrozumieniu strumieni wartości, procesów, ról, technologii oraz rekomendacji, które są kluczowe dla efektywnego wdrażania zmian w organizacji.

Strumienie wartości i procesy

Umożliwianie Zmian ma na celu zmaksymalizowanie liczby udanych zmian usług i produktów poprzez zapewnienie odpowiedniej oceny ryzyka, autoryzację zmian i zarządzanie harmonogramem zmian. Praktyka integruje się ze strumieniami wartości, aby zmiany były skuteczne, bezpieczne i terminowe.

Dwa kluczowe procesy w praktyce Umożliwianie Zmian to:

• Planowanie i Optymalizacja Umożliwiania Zmian: Ten proces obejmuje czynności związane z oceną, priorytetyzacją i planowaniem zmian.
• Zarządzanie Cyklem Życia Zmian: Kontrola nad całym cyklem życia zmian, od zgłoszenia do wdrożenia i weryfikacji.

Proces 1: Planowanie i Optymalizacja Umożliwiania Zmian

Kluczowe dane wejściowe:

• Rekordy (zapisy) zmian
• Aktualne modele zmian i standardowe procedury zmian
• Zasady i wymogi regulacyjne
• Informacje o konfiguracji usług
• Informacje o zasobach IT
• Katalog usług
• Umowy SLA z konsumentami i dostawcami/partnerami
• Wytyczne i ograniczenia finansowe
• Informacje o ryzyku
• Informacje o potencjale wykonawczym i wydajności
• Zasady i plany ciągłości

Kluczowe wyniki:

• Zdefiniowane role i obowiązki dla praktyki umożliwiania zmian
• Raport z analizy przeglądu zmian
• Inicjatywy udoskonalające
• Żądania zmian
• Zaktualizowane modele zmian
• Zaktualizowane standardowe procedury zmian

Ten proces polega na strategicznym podejściu do zmian, zapewniając, że są one wprowadzane w sposób przemyślany, minimalizując ryzyko i maksymalizując wartość.

Rys 1. Proces Planowania i optymalizacji umożliwiania zmian (źródło: publikacja ITIL 4 Umożliwianie zmian opracowana przez Peoplecert)

Działania procesu planowania i optymalizacji umożliwiania zmian:

• Inicjacja umożliwiania zmian (Change Enablement Initiation) : Zespół odpowiedzialny za wprowadzenie lub formalizację istniejących praktyk zarządzania usługami dokumentuje początkową wersję następujących elementów: rola zmiany w strumieniach wartości, istniejące procesy i procedury związane ze zmianą, role i obowiązki praktyki, poziomy i obowiązki w ramach uprawnień do zmiany, kryteria kategoryzacji i priorytetyzacji zmian, modele zmian.
• Przegląd i Planowanie Zmian (Change Review and Planning): Menedżer zmian wraz z właścicielami usług, przeprowadza przegląd dostępnych procesów, procedur i modeli zmiany. Identyfikuje możliwości optymalizacji modelu zmiany i standardowych procedur zmiany, w tym standaryzację nowych typów zmian.
• Inicjacja Doskonalenia Modelu i Procedury Zmian (Change Model and Procedure Improvement Initiation): Menedżer zmiany lub Koordynator zmian rejestruje inicjatywy udoskonalenia, które będą realizowane w ramach praktyki ciągłego doskonalenia lub inicjuje żądanie zmiany, jeśli modele zmiany i procedury są zawarte w zakresie praktyki umożliwiania zmian.
• Komunikacja Aktualizacji Modelu i Procedury Zmiany (Change Model and Procedure Update Communication: Jeśli model zmiany zostanie pomyślnie zaktualizowany, jest on przekazywany odpowiednim interesariuszom wraz z zaktualizowanymi procedurami i inną odpowiednią dokumentacją.

Proces 2: Zarządzanie Cyklem Życia Zmian

Kluczowe dane wejściowe:

• Żądania zmiany
• Modele zmian i standardowe procedury zmian
• Zasady i wymogi regulacyjne
• Informacje o konfiguracji i zasobach IT
• Katalog usług
• Umowy o poziomie usług (SLA) z konsumentami i dostawcami/partnerami
• Wytyczne i ograniczenia finansowe
• Informacje o ryzyku
• Informacje o potencjale wykonawczym i wydajności
• Zasady i plany ciągłości
• Zasady i plany bezpieczeństwa informacji

Kluczowe wyniki:

• Rekordy zmian
• Harmonogram zmian
• Raporty z przeglądu zmian
• Zmienione zasoby i usługi

Ten proces zapewnia kontrolę nad wszystkimi etapami zmiany, od jej zgłoszenia do pomyślnego wdrożenia i weryfikacji.

Rys 2. Proces Zarządzanie cyklem życia zmian (źródło: publikacja ITIL 4 Umożliwianie zmian opracowana przez Peoplecert)

Działania procesu zarządzania cyklu życia zmiany:

1. Zgłoszenie zmiany (Change Registration): Rejestracja propozycji zmiany w systemie.
2. Ocena zmiany (Change Assessment): Ocena wpływu, ryzyka i wartości zmiany.
3. Autoryzacja zmiany (Change Authorization): Uzyskanie formalnej zgody na wdrożenie zmiany.
4. Planowanie wdrożenia (Change Planning): Opracowanie szczegółowego planu wdrożenia.
5. Wdrożenie zmiany (Change Realization Control): Wprowadzenie zmiany w środowisku produkcyjnym.
6. Przegląd i Zamknięcie Zmiany (Change Review and Closure): Potwierdzenie, że zmiana została wdrożona poprawnie i działa zgodnie z oczekiwaniami. Zakończenie procesu zmiany i udokumentowanie wyników.

Organizacje i Ludzie

Praktyka Umożliwianie Zmian wymaga zaangażowania różnych osób i zespołów w organizacji. Dwie kluczowe role to:

Rola 1: Manager Zmiany (Change Manager)

• Cel: Zmaksymalizowanie liczby udanych zmian, minimalizacja ryzyka i zakłóceń.
• Odpowiedzialności:
  • Nadzorowanie całego procesu zmian.
  • Koordynacja działań różnych zespołów.
  • Ocena ryzyka i wpływu zmian.
  • Utrzymywanie harmonogramu zmian.
  • Raportowanie o postępach i wynikach zmian.
• Kompetencje:
  • Znajomość ITIL 4.
  • Umiejętność zarządzania ryzykiem.
  • Komunikacja i umiejętności interpersonalne.
  • Umiejętność rozwiązywania problemów.

Rola 2: Autoryzujący Zmianę (Change Authority)

• Cel: Podejmowanie decyzji dotyczących zatwierdzania zmian na podstawie oceny ryzyka i wpływu na usługi.
• Odpowiedzialności:
  • Ocena wniosków o zmiany.
  • Zatwierdzanie lub odrzucanie zmian.
  • Upewnianie się, że zmiany są zgodne z politykami i procedurami organizacji.
• Kompetencje:
  • Wiedza techniczna.
  • Zrozumienie biznesowe.
  • Umiejętność podejmowania decyzji.

Informacje i technologie

Technologia odgrywa kluczową rolę w automatyzacji i usprawnieniu procesu Umożliwiania Zmian.

Narzędzia wspierające praktykę Umożliwianie Zmian:

• Systemy zarządzania usługami IT (ITSM): Narzędzia takie jak ServiceNow, Jira Service Management, Freshservice, które automatyzują workflow zmian, umożliwiają śledzenie postępów i zarządzanie dokumentacją.
• Narzędzia do zarządzania konfiguracją (CMDB): Bazy danych konfiguracji (CMDB) pomagają zrozumieć relacje między różnymi elementami infrastruktury IT i ocenić wpływ zmian.
• Narzędzia do automatyzacji wdrożeń: Narzędzia takie jak Ansible, Chef, Puppet umożliwiają automatyzację wdrażania zmian, zmniejszając ryzyko błędów i przyspieszając proces.
• Narzędzia do monitoringu i alertów: Systemy monitoringu, takie jak Nagios, Zabbix, Datadog, pomagają monitorować wydajność i dostępność usług po wdrożeniu zmian.
• Narzędzia do zarządzania projektami: Narzędzia takie jak Microsoft Project, Asana, Trello pomagają w planowaniu i zarządzaniu złożonymi zmianami, które są realizowane jako projekty.

Partnerzy i Dostawcy

Partnerzy i dostawcy mogą odgrywać ważną rolę w praktyce Umożliwianie Zmian, szczególnie w obszarach, które wymagają specjalistycznej wiedzy lub zasobów.

Rola partnerów i dostawców:

• Dostarczanie oprogramowania i narzędzi: Dostawcy systemów ITSM, CMDB i narzędzi do automatyzacji.
• Usługi konsultingowe: Pomoc w projektowaniu i wdrażaniu procesów Umożliwiania Zmian.
• Wsparcie techniczne: Pomoc w rozwiązywaniu problemów związanych z wdrożeniem zmian.
• Outsourcing operacji: Przekazanie części zadań związanych z zarządzaniem zmianami zewnętrznemu dostawcy.

Rekomendacje dotyczące sukcesu praktyki

Aby praktyka Umożliwianie Zmian była skuteczna, warto wziąć pod uwagę następujące rekomendacje:

• Zrozumienie kontekstu biznesowego: Upewnij się, że zmiany są zgodne z celami biznesowymi organizacji.
• Komunikacja: Komunikuj zmiany wszystkim zainteresowanym stronom.
• Automatyzacja: Automatyzuj procesy, gdzie to możliwe, aby zmniejszyć ryzyko błędów i przyspieszyć wdrożenia.
• Ciągłe doskonalenie: Regularnie przeglądaj procesy Umożliwiania Zmian i wprowadzaj ulepszenia.
• Szkolenia: Zapewnij odpowiednie szkolenia dla wszystkich osób zaangażowanych w proces zmian.
• Kultura uczenia się: Stwórz środowisko, w którym błędy są traktowane jako okazja do nauki i doskonalenia.
• Wybór odpowiednich narzędzi: Wybór narzędzi, które integrują się z istniejącym środowiskiem i wspierają potrzeby organizacji.
• Monitorowanie metryk: Ustalenie metryk do monitorowania efektywności procesu zmian i identyfikowanie obszarów do poprawy.

Umożliwianie Zmian to kluczowa praktyka w ITIL 4, która pomaga organizacjom skutecznie zarządzać ryzykiem i wdrażać innowacje. Stosując się do powyższych rekomendacji, możesz zwiększyć prawdopodobieństwo sukcesu wdrożonych zmian i osiągnąć korzyści biznesowe.

Artykuł Prosto o ITIL – Praktyka Umożliwiania Zmian – Zaawansowane aspekty skutecznej transformacji – część 2 pochodzi z serwisu Mariusz Siek.

„Zmiany, zmiany, zmiany…” – słowa Stanisława Barei z kultowej komedii „Co mi zrobisz jak mnie złapiesz” idealnie oddają realia współczesnego IT. Zmiany są nieuniknione, a sposób, w jaki nimi zarządzamy, decyduje o naszym sukcesie lub porażce. W dzisiejszym artykule, opartym na mojej wiedzy i doświadczeniu, przyjrzymy się praktyce ITIL 4, która pomaga nam w efektywnym zarządzaniu zmianami – Umożliwianiu Zmian (Change Enablement). To klucz do zwinnego i bezpiecznego wprowadzania innowacji w Twojej organizacji. Jak już wspomniałem wcześniej przy okazji omawiania praktyki Service Desk, odpowiednie podejście do zmian to fundament stabilnego IT.

Cel Praktyki

Praktyka Umożliwiania Zmian w ITIL 4 ma na celu minimalizację ryzyka związanego z wprowadzaniem zmian w środowisku IT, przy jednoczesnym maksymalizowaniu korzyści biznesowych.

Chodzi o to, by zmiany były wprowadzane w sposób kontrolowany, z pełną świadomością potencjalnych konsekwencji, ale bez nadmiernego hamowania innowacji. Celem jest zapewnienie, że każda zmiana jest właściwie oceniona, zaplanowana i wdrożona, a także monitorowana po wdrożeniu, aby upewnić się, że przynosi oczekiwane rezultaty. Bez sprawnego Umożliwiania Zmian, jakakolwiek próba wdrożenia nowych technologii, czy optymalizacji istniejących procesów, może zakończyć się chaosem i kosztownymi błędami.

Koncepcje i Pojęcia Kluczowe

Zrozumienie podstawowych pojęć jest kluczowe dla skutecznego wdrożenia praktyki Umożliwiania Zmian:

• Zmiana (Change): Definiowana jako dodanie, modyfikacja lub usunięcie czegokolwiek, co może mieć bezpośredni lub pośredni wpływ na usługi IT. Przykłady to: aktualizacja oprogramowania, zmiana konfiguracji serwera, wdrożenie nowej aplikacji, modyfikacja procesu biznesowego wspieranego przez IT.
• Rodzaje Zmian:
  • Standardowe (Standard Changes): Zmiany o niskim ryzyku, dobrze udokumentowane i powtarzalne. Mają predefiniowaną procedurę wdrażania i są zatwierdzane automatycznie, bez konieczności udziału Change Advisory Board (CAB). Przykładem może być cykliczna aktualizacja oprogramowania antywirusowego lub restart serwera w celach konserwacyjnych.
  • Normalne (Normal Changes): Zmiany, które wymagają oceny ryzyka i zatwierdzenia przez Change Authority (zwykle CAB). Wymagają szczegółowego planowania i koordynacji, ponieważ mogą mieć istotny wpływ na usługi IT i biznes.
  • Pilna (Emergency Changes): Zmiany wprowadzane w trybie pilnym w celu naprawy awarii lub zapobieżenia poważnemu problemowi. Wymagają przyspieszonej procedury zatwierdzania i wdrożenia, ale nadal powinny być kontrolowane, aby uniknąć dodatkowych problemów.
• Change Authority: Osoba lub grupa odpowiedzialna za zatwierdzanie zmian. W przypadku zmian normalnych zazwyczaj jest to CAB, natomiast zmiany standardowe mogą być zatwierdzane automatycznie lub przez wyznaczonego właściciela zmiany. Kluczowe jest, aby Change Authority posiadało odpowiednią wiedzę i uprawnienia, aby podejmować trafne decyzje.
• Ryzyko (Risk): Potencjalne negatywne skutki związane z wprowadzeniem zmiany. Ocena ryzyka powinna uwzględniać prawdopodobieństwo wystąpienia problemu oraz jego wpływ na biznes. Należy brać pod uwagę takie aspekty jak: przerwy w dostępności usług, utrata danych, naruszenie bezpieczeństwa, negatywny wpływ na produktywność użytkowników.
• CAB (Change Advisory Board): Grupa doradcza, składająca się z przedstawicieli różnych działów IT i biznesu, której zadaniem jest ocena i zatwierdzanie zmian normalnych. CAB zapewnia, że zmiany są rozpatrywane z różnych perspektyw i że uwzględniane są wszystkie istotne czynniki.

Zakres Praktyki

Praktyka Umożliwiania Zmian obejmuje następujące działania:

• Identyfikacja Zmian: Rejestrowanie wszystkich proponowanych zmian w systemie zarządzania zmianami (np. w systemie ITSM). Każda zmiana powinna być odpowiednio udokumentowana, z uwzględnieniem celu zmiany, zakresu, planowanych działań, zasobów potrzebnych do wdrożenia oraz potencjalnych ryzyk.
• Ocena i Planowanie: Analiza wpływu zmiany na usługi IT (np. na dostępność, wydajność, bezpieczeństwo), ocena ryzyka, opracowanie planu wdrożenia i planu awaryjnego (rollback plan). Plan wdrożenia powinien zawierać szczegółowy harmonogram, listę zadań, przypisanie odpowiedzialności oraz kryteria sukcesu.
• Zatwierdzanie Zmian: Uzyskanie zgody od Change Authority na wdrożenie zmiany. Decyzja o zatwierdzeniu powinna być oparta na analizie ryzyka, ocenie wpływu na biznes oraz dostępności zasobów.
• Wdrożenie Zmian: Realizacja planu wdrożenia zgodnie z ustalonym harmonogramem. Podczas wdrożenia należy monitorować postęp prac, identyfikować potencjalne problemy i reagować na nie w sposób proaktywny.
• Monitorowanie i Raportowanie: Śledzenie postępu wdrożenia, identyfikacja problemów i raportowanie o statusie zmian do interesariuszy. Regularne raportowanie pozwala na utrzymanie kontroli nad procesem zmian i zapewnia transparentność.
• Przegląd Po Wdrożeniu (Post Implementation Review – PIR): Ocena skuteczności zmiany po jej wdrożeniu, identyfikacja lekcji wyciągniętych i wprowadzenie usprawnień do procesu zarządzania zmianami. PIR pozwala na ciągłe doskonalenie procesu zarządzania zmianami i minimalizację ryzyka w przyszłości.

Czynniki Sukcesu Praktyki

Aby praktyka Umożliwiania Zmian przynosiła oczekiwane rezultaty, należy zwrócić uwagę na następujące czynniki:

• Jasne i Zrozumiałe Zasady: Polityka zarządzania zmianami powinna być prosta, zrozumiała i dostępna dla wszystkich zainteresowanych stron. Powinna określać role i odpowiedzialności, procedury zatwierdzania zmian, kryteria oceny ryzyka oraz zasady komunikacji.
• Zaangażowanie Biznesu: Zmiany w IT powinny być wprowadzane w oparciu o potrzeby biznesowe i w ścisłej współpracy z użytkownikami. Reprezentanci biznesu powinni być zaangażowani w proces planowania i oceny zmian, aby upewnić się, że są one zgodne z celami strategicznymi organizacji.
• Automatyzacja: Wykorzystanie narzędzi do automatyzacji procesów zarządzania zmianami, takich jak systemy ITSM (ServiceNow, Jira Service Management, BMC Helix ITSM), może znacznie przyspieszyć i usprawnić proces. Automatyzacja pozwala na redukcję błędów, zwiększenie efektywności i poprawę jakości zarządzania zmianami.
• Komunikacja: Regularna i transparentna komunikacja z interesariuszami na temat planowanych i wdrażanych zmian jest kluczowa dla budowania zaufania i minimalizowania negatywnego wpływu na użytkowników. Komunikacja powinna obejmować informacje o celu zmiany, zakresie, harmonogramie, potencjalnych ryzykach oraz planowanych działaniach.

Kluczowe Metryki

Monitorowanie kluczowych metryk pozwala na ocenę skuteczności praktyki Umożliwiania Zmian i identyfikację obszarów do poprawy. Przykładowe metryki to:

• Procent Udanych Zmian: Odsetek zmian, które zostały wdrożone bez problemów i przyniosły oczekiwane rezultaty. Wysoki wskaźnik udanych zmian świadczy o efektywnym procesie planowania, oceny ryzyka i wdrożenia.
• Średni Czas Wdrożenia Zmiany: Czas potrzebny na wdrożenie zmiany od momentu zgłoszenia do momentu zakończenia wdrożenia. Krótki czas wdrożenia świadczy o sprawnym procesie zarządzania zmianami i szybkiej reakcji na potrzeby biznesowe.
• Liczba Nieudanych Zmian: Liczba zmian, które zakończyły się niepowodzeniem i wymagały wycofania. Wysoka liczba nieudanych zmian może wskazywać na problemy w procesie planowania, oceny ryzyka lub wdrożenia.
• Liczba Nagłych Zmian: Liczba zmian wprowadzanych w trybie pilnym, co może świadczyć o problemach w planowaniu i proaktywnym zarządzaniu zmianami. Wysoka liczba nagłych zmian może prowadzić do chaosu i zwiększonego ryzyka wystąpienia problemów.

To dopiero początek naszej podróży po świecie Umożliwiania Zmian. W drugiej części artykułu zagłębimy się w procesy, role, technologie i partnerów zaangażowanych w tę praktykę. Dowiesz się, jak skutecznie wdrożyć zarządzanie zmianami w Twojej organizacji, aby stały się one Twoim sprzymierzeńcem w drodze do sukcesu.

Artykuł Prosto o ITIL – Praktyka Umożliwiania Zmian – Jak Sprawnie Wprowadzać Nowości w Świecie IT? – część 1 pochodzi z serwisu Mariusz Siek.

Praktyka zarządzania wnioskami o usługi, to kolejną najczęściej wykorzystywana w organizacjach, po Service Desk i Zarządzaniu Incydentami, praktyka ITIL. Nie ma chyba w tym żadnego zaskoczenia, bo wnioski o usługi, udostępniane są użytkownikom aby mogli zamawiać realizację działań, które są ściśle związane ze świadczonymi usługami. Zresztą, sam Service Desk, jako praktyka zajmuje się incydentami i wnioskami o usługę. Jak widać, zależności pomiędzy tymi trzema praktykami są mocne.

Cel

Celem praktyki zarządzanie wnioskami o usługi jest wspieranie uzgodnionej jakości usługi poprzez obsługę wszystkich wstępnie zdefiniowanych, inicjowanych przez użytkownika wniosków o usługi w sposób efektywny i przyjazny dla użytkownika.

Warto zwrócić uwagę, że wnioski o usługę może składać rola użytkownik a nie klient. ITIL jasno rozróżnia te dwie role, co nie znaczy, że jedna osoba nie może pełnić obu tych ról.

Użytkownik składając wniosek o usługę, może go wybrać z listy wcześniej zdefiniowanych działań oraz powinien wiedzieć kiedy jego wniosek zostanie zrealizowany.

Wniosek o usługę

Wniosek użytkownika lub upoważnionego przedstawiciela użytkownika inicjujący działanie związane z usługą, które zostało uzgodnione jako normalna część dostarczenia usługi.

Oprócz użytkownika, wniosek o usługę może złożyć jego upoważniony przedstawiciel, czyli np. kierownik, przełożony, menedżer i jest to normalna część świadczenia usługi, nie incydenty, nie problemy i nie zmiany.

Jakie najczęściej elementy obejmują wnioski o usługę? Są to:

• Wniosek o dostęp do zasobu, usługi lub oferty usług – chyba najczęściej występujący, tzw. Dostępy, czyli nadawanie, zmiana i odbieranie uprawnień dostępu do aplikacji, zasobów, usług.
• Żądanie inicjujące działanie związane z usługą (wykonywane przez dostawcę usług lub wspólnie z użytkownikiem) – np. zamówienie raportu, wymiana toneru w drukarce, zwiększenie quoty skrzynki email.
• Zapytanie o informacje – np. w jakich godzinach pracuje biuro, jak można skorzystać z samochodu służbowego, jak zarezerwować środowisko do wykonania testów
• Informacje zwrotne, pochwały lub skargi – pewnie częściej skargi niż pochwały

Co do zasady wnioski o usługę nie wymagają autoryzacji (akceptacji). Są jednak dwa wyjątki. Wnioski dotyczące zagadnień bezpieczeństwa, np. nadania uprawnień do aplikacji, muszą być zaakceptowane przez przełożonego lub kogoś z zespołu ds. bezpieczeństwa informacji, zanim będą mogły być zrealizowane. Podobnie jest z wnioskami o usługę, które dotyczą poniesienia kosztów finansowych. Tutaj również wymagana jest akceptacja np. dyrektora finansowego, przed realizacją wniosku.

Ponieważ wnioski o usługę są ustandaryzowane, czyli dobrze znane i sprawdzone, można je również częściowo lub w pełni zautomatyzować.

Wnioski o usługę i sposób ich realizacji mogą mieć wpływ na doświadczenie użytkownika i w konsekwencji na jego satysfakcję lub jej brak.

Typowy strumień wartości związany z realizacją wniosku o usługi może obejmować, następujące praktyki i działania:

• service desk: przetwarzanie zapytania użytkownika
• zarządzanie wnioskami o usługi: kierowanie i prowadzenie realizacji zgłoszeń
• zarządzanie infrastrukturą i platformą: wykonywanie niezbędnych operacji technicznych
• zarządzanie wydaniami: udostępnianie komponentów usługi użytkownikom
• umożliwienie zmian: koordynacja niezbędnych zmian
• zarządzanie bezpieczeństwem informacji: dostarczanie lub modyfikowanie dostępu.

Model wniosku o usługi

Powtarzalne, predefiniowane podejście do realizacji określonego rodzaju wniosków o usługi.

Ponieważ aktywności wykonywane w ramach wniosków o usługę są powtarzalne, możemy opracować predefiniowane podejścia (modele) do ich realizacji. Model wniosku o usługę zawiera:

• procedury i przepływy pracy, w tym możliwe opcje i decyzje
• role i odpowiedzialne zespoły (zazwyczaj jako macierz RACI)
• automatyzacja i używane narzędzia
• podmioty zewnętrzne uczestniczące w umowach i wspierające je.

Katalog wniosków o usługi

Widok katalogu usług, dostarczający szczegółowych informacji na temat wniosków o usługi dotyczących istniejących i nowych usług, który jest udostępniany użytkownikowi.

Wszystkie wnioski o usługę przechowywane są w katalogu wniosków o usługę, który jest widokiem katalogu usług. Należy pamiętać, że wsad merytoryczny do katalogu wniosków o usługę opracowuje praktyka zarządzania wnioskami o usługę ale za ich umieszczenie w katalogu usług, odpowiada praktyka zarządzania katalogiem usług.

Zakres

Zakres praktyki zarządzanie wnioskami o usługi obejmuje:

• zarządzanie modelami wniosków o usługi
• przetwarzanie wniosków o usługi składanych przez użytkowników lub ich przedstawicieli
• zarządzanie realizacją wniosków o usługi zgodnie z uzgodnionymi modelami
• przegląd i ciągłe doskonalenie wydajności przetwarzania i realizacji zgłoszeń

Czynniki sukcesu praktyki

Dla każdej praktyki ITIL definiuje czynniki sukcesu (Practice Success Factors – PSF), czyli złożony funkcjonalny komponent praktyki, który jest wymagany, aby praktyka spełniała swoje przeznaczenie, cel.

Dla praktyki zarządzanie wnioskami o usługę zostały zdefiniowane dwa czynniki sukcesu:

• Zapewnianie optymalizacji procedur realizacji wniosków o usługi dla wszystkich usług. Ważne jest, aby identyfikować, dokumentować i testować procedury realizacji wniosków o usługi oraz przydzielać odpowiedzialność za działania. Procedury realizacji wniosków o usługi powinny podlegać ciągłemu doskonaleniu w oparciu o monitorowanie wydajności realizacji i satysfakcji użytkowników.
• Zapewnianie, że wszystkie wnioski o usługi są realizowane zgodnie z uzgodnionymi procedurami i w sposób satysfakcjonujący użytkownika. Procedury realizacji wniosków o usługę powinny być zoptymalizowanie i udokumentowane, wtedy będzie zapewnione, że są łatwe do planowania i realizacji.

Kluczowe metryki

Skuteczność i wydajność praktyk ITIL powinna być oceniana w kontekście strumieni wartości, do których praktyki się przyczyniają. Kontekst biznesu i strumieni wartości jest ważny przy definiowaniu, czy wydajność praktyki jest uważana za dobrą, czy nie.

Metryki są powiązane ze zdefiniowanymi czynnikami sukcesu praktyki i potwierdzają lub nie, że dany czynnik sukcesu został osiągnięty lub nie. Poniżej zdefiniowane kluczowe metryki dla praktyki zarządzania wnioskami o usługę

• PSF – Zapewnianie optymalizacji procedur realizacji wniosków o usługi dla wszystkich usług
  • Kompletność katalogu wniosków o usługi; liczba i procent wniosków o usługi, które nie są wspierane procedurami realizacji
  • Liczba i odsetek wniosków o usługi, które nie mogły zostać zrealizowane zgodnie z uzgodnioną procedurą z powodu błędów/niedociągnięć w procedurze
  • Zadowolenie członków zespołu realizujących wnioski zgodnie z dostarczanymi instrukcjami
  • Średni czas i koszt potrzebny do realizacji wniosków (według typów/modeli)
  • Odsetek wniosków o usługi z całkowicie lub w dużej mierze zautomatyzowaną realizacją (liczba, odsetek w katalogu, odsetek w całkowitej liczbie i czas realizacji)
• PSF – Zapewnianie, że wszystkie wnioski o usługi są realizowane zgodnie z uzgodnionymi procedurami i w sposób satysfakcjonujący użytkownika
  • Liczba i odsetek wniosków zrealizowanych zgodnie z umową SLA
  • Wpływ incydentów spowodowanych nieprawidłową realizacją wniosków o usługi
  • Zadowolenie użytkowników z realizacji wniosków
  • Liczba i odsetek zrealizowanych wniosków z odchyleniami od uzgodnionych procedur

Przedstawiłem najważniejsze koncepcje związane z praktyką zarządzanie wnioskami o usługę. W drugiej części artykułu opiszę strumienie wartości i procesy, organizacje i ludzie (role i odpowiedzialności), informacje i technologie, czyli narzędzia wspierające praktykę, relacje z partnerami i dostawcami oraz rekomendacje związane z osiągnięciem sukcesu przez praktykę.

Artykuł Prosto o ITIL – Praktyka Zarządzanie wnioskami o usługi – część 1 pochodzi z serwisu Mariusz Siek.

W pierwszej części o praktyce Zarządzanie Incydentami omówiłem kluczowe definicje, elementy, PSF i KPI praktyki. W drugiej części przedstawię strumienie wartości i procesy, role i odpowiedzialności, informacje i technologie, zaangażowanie partnerów i dostawców oraz najważniejsze rekomendacje związane z praktyką Zarządzania Incydentami.

Strumienie wartości i procesy

Praktyka Zarządzania Incydentami składa się z dwóch procesów:

• Obsługa i rozwiązanie incydentów. Proces ten koncentruje się na obsłudze i rozwiązaniu poszczególnych incydentów, od ich wykrycia do zamknięcia.
• Okresowy przegląd incydentów. Proces ten zapewnia nabyte doświadczenia z obsługi i rozwiązania incydentów oraz ciągłe doskonalenie podejść do zarządzania incydentami.

Obsługa i rozwiązanie incydentów

Kluczowe dane wejściowe:

• Zapytania użytkowników
• Monitorowanie i dane dotyczące zdarzeń
• Zapytania użytkowników
• Informacja o konfiguracji usług
• Informacje o zasobach IT
• Katalog usług
• Umowy SLA z korzystającymi i dostawcami/partnerami
• Informacje o potencjale wykonawczym i wydajności
• Polityki i plany ciągłości działalności
• Polityka i plany bezpieczeństwa informacji
• Zapisy problemu
• Baza wiedzy

Kluczowe wyniki:

• Zapisy incydentu
• Komunikacje dotyczące statusu incydentu
• Wnioski o zbadanie problemu
• Wnioski o zmianę
• Aktualizacje bazy wiedzy
• Przywrócone elementy konfiguracji i usługi

Rys 1. Proces Obsługi i rozwiązania incydentu (źródło: książka ITIL 4 Zarządzanie Incydentami opracowana przez Peoplecert)

Działania procesu obsługi i rozwiązania incydentu:

• Wykrywanie incydentu – Incydent może zostać wykryty przez Użytkownika lub system monitorowania jako zdarzenie. Użytkownik zgłasza incydent do Service Desk za pomocą uzgodnionych kanałów komunikacji. Agent service desk wykonuje wstępną klasyfikację zapytania użytkownika, potwierdzając, że zgłoszenie faktycznie dotyczy incydentu.
• Rejestrowanie incydentu – Agent service desk rejestruje incydent, dodając do zapisu incydentu wszystkie dostępne dane. Im więcej wartościowych danych zostanie zebranych tym łatwiejsza będzie diagnoza incydentu.
• Klasyfikacja incydentu – Agent service desk określa kategorię incydent, czyli do jakiej grupy wsparcia ma trafić incydent i priorytet incydentu, czyli jak szybko incydent ma zostać rozwiązany.
• Diagnoza incydentu –  Jeżeli rozwiązanie jest dostępne w bazie wiedzy, agent SD rozwiązuje incydent. Jeżeli nie ma rozwiązania incydentu w bazie wiedzy, odpowiedni zespół wsparcia wykonuje diagnozę w celu znalezienia rozwiązania incydentu. W diagnozie incydentu, praktykę Zarzadzania Incydentami może wspierać praktyka zarządzania problemami.
• Rozwiązanie incydentu – Po znalezieniu rozwiązania odpowiednie zespoły wsparcia stosują rozwiązanie, pracując sekwencyjnie lub równolegle. Rozwiązanie incydentu może wymagać zainicjowania zmiany. Jeśli rozwiązanie nie działa, wykonywana jest dodatkowa diagnoza.
• Zamknięcie incydent – Po potwierdzeniu przez użytkownika rozwiązania incydentu może zostać on zamknięty. Jeżeli użytkownik nie potwierdza skutecznego rozwiązania to incydent trafia ponownie do diagnozy.

Okresowy przegląd incydent

Proces ten koncentruje się na ciągłym doskonaleniu praktyki zarządzanie incydentami, modeli incydentów i procedur obsługi incydentów. Jest on wykonywany regularnie lub wyzwalany przez raporty dotyczące incydentów podkreślające nieefektywność i inne szanse na doskonalenie. Regularne przeglądy mogą odbywać się co dwa do trzech miesięcy lub częściej, zależnie od skuteczności istniejących modeli i procedur

Kluczowe dane wejściowe:

• Aktualne modele incydentów i procedury Zapisy incydentów Raporty dotyczące incydentów
• Polityki i wymogi regulacyjne
• Informacje o konfiguracji Informacje o zasobach IT
• Umowy SLA z korzystającymi i dostawcami/partnerami
• Informacje o potencjale wykonawczym i wydajności,
• Polityki i plany ciągłości działalności
• Polityki i plany bezpieczeństwa

Kluczowe wyniki:

• Zaktualizowane modele incydentów
• Zaktualizowane procedury obsługi incydentów
• Zapisy incydentu
• Komunikacja na temat zaktualizowanych modeli i procedur dotyczących incydentów
• Wnioski o zmianę Inicjatywy doskonalenia Raporty z przeglądów incydentu

Rys 2. Proces Okresowy przegląd incydentu (źródło: książka ITIL 4 Zarządzanie Incydentami opracowana przez Peoplecert)

Działania procesu Okresowego przeglądu incydentu:

• Przegląd incydentu i analiza zapisów dotyczących incydentu – Kierownik ds. incydentów, wraz z właścicielami usług i innymi odpowiednimi interesariuszami, wykonuje przegląd wybranych incydentów, takich jak poważne incydenty, incydenty nierozwiązane w określonym czasie lub wszystkie incydenty w określonym czasie. Identyfikują oni szanse na optymalizację modelu incydentów i procedur obsługi incydentów, w tym automatyzację przetwarzania i rozwiązania incydentu.
• Rozpoczęcie doskonalenia modelu incydentu – Kierownik ds. incydentów rejestruje inicjatywy doskonalenia, które mają być wprowadzane w życie z udziałem praktyki ciągłego doskonalenia lub inicjuje wniosek o zmianę
• Komunikacja dotycząca aktualizacji modelu incydentu – Jeśli model incydentu zostanie pomyślnie zaktualizowany, następuje komunikacja z odpowiednimi interesariuszami. Zazwyczaj jest to wykonywane przez osobę zarządzającą incydentem i/lub właściciela usługi albo zasobu.

Organizacje i ludzie

W praktyce Zarządzania Incydentami mamy dwie role: Kierownik/Menedżer ds. incydentów oraz Kierownik/Menedżer ds. poważnych incydentów Odpowiedzialności poszczególnych ról zostały opisanie poniżej.

Kierownik/Menedżer ds. incydentów odpowiada za:

• Koordynację obsługi incydentów w organizacji lub w określonym obszarze, takim jak terytorium, produkt lub technologia, zależnie od projektowania organizacyjnego
• Koordynowanie pracy ręcznej z incydentami, zwłaszcza tymi obejmującymi wiele zespołów
• Monitorowanie i przegląd pracy zespołów zajmujących się obsługą i rozwiązaniem incydentów
• Zapewnianie wystarczającej świadomości o incydentach i ich statusie w całej organizacji
• Przeprowadzanie regularnych przeglądów incydentów i inicjowanie doskonalenia praktyki zarządzanie incydentami, modeli incydentów i procedur obsługi incydentów
• Rozwój wiedzy organizacji w zakresie procesów i metod praktyki zarządzanie incydentami.

Kierownik/Menedżer ds. poważnych incydentów (Major Incident Manager), ma podobny zakres obowiązków jak Kierownik/Menedżer ds. incydentów tylko zajmuje się wyłącznie poważnymi incydentami.

W obsłudze incydentów dobrze korzystać z kultury nieobwiniania, tak by nie szukać winnych incydentów aby ich ukarać ale znajdować trwałe rozwiązania incydentów i przyczyny źródłowe problemów. Zespoły uczestniczące w rozwiązywaniu incydentów powinny ciągle podnosić swoje kompetencje i dzielić się zdobytą wiedzą z innymi aby zwiększać skuteczność rozwiązywania incydentów.

Informacje i technologie

Najczęściej wykorzystywane narzędzia automatyzacji dla praktyki Zarządzania Incydentami:

• Narzędzia do monitorowania i zarządzania zdarzeniami
  • Wykrywanie incydentów
  • Analiza trendów i zdarzeń podczas diagnozowania incydentów
  • Potwierdzenie rozwiązania incydentu
• Narzędzia do zarządzania przepływem pracy i współpracy
  • Zarządzanie cyklem życia incydentów
  • Wsparcie i automatyzacja modeli incydentów
  • Komunikacja między specjalistami zaangażowanymi w obsługę i rozwiązanie incydentów
  • Integracja praktyk ze strumieniami wartości usług
• Narzędzia do zarządzania wiedzą
  • Klasyfikacja i przydział incydentów, identyfikacja znanych rozwiązań incydentów
• Narzędzia do zarządzania konfiguracją usług
  • Klasyfikacja i diagnoza incydentów
• Narzędzia do klasyfikacji i analizy, w tym wspomagane uczeniem maszynowym (Machine Learning)
  • Klasyfikacja i analiza incydentów
• Zdalna administracja, diagnoza, wdrożenie i inne narzędzia do zarządzania infrastrukturą i oprogramowaniem
  • Diagnoza i rozwiązanie incydentów
• Narzędzia do planowania i priorytetyzacji pracy
  • Planowanie i śledzenie inicjatyw w zakresie doskonalenia
• Narzędzia do analizy i raportowania
  • Pomiar i raportowanie praktyki
• Narzędzia ankietowe
  • Zbieranie informacji zwrotnych w celu doskonalenia praktyki

Rekomendacje dotyczące automatyzacji zarządzania incydentami:

• Automatyzacja strumienia wartości
• Zezwalanie na różne przepływy pracy w przypadku incydentów inicjowanych przez użytkowników i zdarzenia
• Niekomplikowanie nadmiernie przepływów pracy i reguł biznesowych
• Zwracanie uwagi na pomiary i raportowanie od samego początku
• Zapewnienie odpowiedniej komunikacji
• Wykorzystanie umiejętności uczenia maszynowego

Partnerzy i dostawcy

Partnerzy i dostawcy mogą wspierać praktykę zarządzania incydentami w obszarach:

• Wykonywanie działań procesów, w szczególności diagnozowanie i rozwiązanie incydentu. Ważne jest zapewnienie efektywnej integracji podmiotów zewnętrznych z przepływami pracy związanymi z incydentami i wymianą informacji, a także przestrzeganie przez nie odpowiednich polityk. Model incydentów określają w jaki sposób strony trzecie uczestniczą w obsłudze incydentów. Dobrze jest również zapewnić jasne i zrozumiałe kanały komunikacji.
• Dostarczanie narzędzi oprogramowania. Dostawcy zewnętrzy zapewniają narzędzia klasy ITSM, które są wykorzystywane również przez inne praktyki. Najlepiej jakby to było zintegrowane narzędzie do zarządzania usługami.
• Konsulting i doradztwo. Wyspecjalizowani dostawcy, którzy zdobyli wiedzę w zakresie zarządzania incydentami, mogą pomóc w ustanowieniu i rozwoju praktyk, przyjęciu metod i technik oraz wstępnym opracowaniu modeli incydentów.

Rekomendacje dotyczące sukcesu praktyki

• Spójrz na incydenty z perspektywy korzystającego z usług
• Gromadzenie i ponowne wykorzystywanie danych wspierające rozwiązywanie incydentów
• Zrozumienie, zarządzanie i doskonalenie strumienia wartości rozwiązania incydentów, a nie tylko praktyki zarządzanie incydentami
• Rozwijaj praktykę w sposób ciągły, ale nie komplikuj jej nadmiernie
• Stosuj odpowiednie techniki w przypadku złożonych incydentów
• Pomiar praktyki i wytworzenie regularnych raportów i tablic wskaźników dla interesariuszy

Artykuł Prosto o ITIL – Praktyka Zarządzanie Incydentami – część 2 pochodzi z serwisu Mariusz Siek.

W pierwszej części opisałem cztery praktyki od których warto zacząć swoją podróż z ITIL: zarządzanie katalogiem usług, zarządzanie poziomem świadczenia usług, service desk i zarządzanie incydentami. Na początek mogą wystarczyć ale od początku należy planować wykorzystanie kolejnych praktyk.

ITIL 4 bardzo mocno podkreśla znaczenie strumieni wartości usług, które wykorzystują wiele, różnych praktyk. Jedna praktyka nie może dostarczyć wartości dlatego trzeba korzystać z wielu, powiązanych ze sobą praktyk.

Jeżeli spojrzymy na strumień wartości „przywrócenie usługi do działania”, to wspomniane cztery praktyki są niewystarczające. Kolejną praktyką, jaką należy „wdrożyć” jest zarządzanie konfiguracją usług.

Zarządzanie konfiguracją usług

Jedna z ważniejszych praktyk, która pomaga rozwiązywać incydenty i problemy oraz wprowadzać zmiany. Jest to praktyka „backendowa”, ponieważ nie korzystają z niej praktyki taki jak zarządzanie incydentami i problemami oraz umożliwianie zmian.

Obejmuje elementy konfiguracji (Configuration Item – CI) oraz bazę zarządzania konfiguracjami (Configuration Management Database – CMDB), w której zawarte są wszystkie elementy konfiguracji oraz relacje pomiędzy CI.

Te informacje są bezcenne do:

• Określenia kategorii incydentu i problemu, czyli wskazania do jakiej grupy wsparcia zgłoszenie ma być skierowane. Mówiąc prościej kto ma rozwiązać incydent lub problem.
• Zdiagnozowania i rozwiązania incydentów, wykorzystując model/mapę usługi można szybko i skutecznie weryfikować jak nie działanie jednego elementu konfiguracji wpływa na inne elementy konfiguracji w tym na usługę.
• Badania przyczyn źródłowych problemów, które mogą być złożone nie było by możliwe bez informacji o elementach konfiguracji i zależnością między nimi. Współpraca wielu zespołów może być wymagana aby rozwiązać problem.
• Wprowadzania zmian zakończonych sukcesem, jest tylko możliwe, jeżeli wiadomo jak zmiana jednego elementu konfiguracji wpływa na inne elementy konfiguracji i usługi.

Jednym słowem jeżeli nie masz CMDB z odpowiednimi informacjami to dłużej rozwiązujesz incydenty, przez dłuższą diagnozę i przekazanie do właściwego zespołu wsparcia, więcej czasu zajmu Ci badanie przyczyny źródłowej błędu/problemu i masz większe ryzyko, że źle oceniłeś zmianę i mniejsze prawdopodobieństwo, że wdrożysz ją prawidłowo.

Zarządzanie problemami

Praktyka zarządzania problemami została już wywołana do odpowiedzi przy okazji zarządzania konfiguracją usług. Jeżeli mamy już wdrożoną praktykę zarządzania incydentami i chcemy aby było mniej incydentów, to musimy zacząć rozwiązywać problemy. W każdej usłudze, systemie, aplikacji były, są i będą błędy. Nie ma usług bez błędów, dlatego tak ważne jest aby identyfikować potencjalne źródła problemów rejestrować je i rozwiązywać.

Problemy to zagadnienia bardziej złożone niż incydenty dlatego do ich obsługi powinny włączyć się wszystkie zespoły w organizacji. Wymagana jest współpraca pomiędzy wieloma interesariuszami aby znaleźć przyczynę źródłową oraz rozwiązanie problemu. Zidentyfikowane i zarejestrowane problemy oraz znane błędy łączymy z incydentami.

Praktyka zarządzania problemami opracowuje obejścia (workaround) dla incydentów i udostępnia je praktyce zarządzania incydentami, najlepiej poprzez bazę wiedzy. Jeżeli zarządzanie incydentami nie może samodzielnie rozwiązać incydentu, może wspierać się zarządzaniem problemami, które pomaga opracować i dostarczyć rozwiązanie incydentu.

Umożliwianie zmian

Rozwiązując incydent lub problem może się okazać, że wymagane jest wdrożenie zmiany. Wtedy należy złożyć wniosek o zmianę (Request of change – RfC) czyli skorzystać z praktyki umożliwiania zmian. Każda zmiana związana jest z ryzykiem i każda zmiana wymaga autoryzacji, akceptacji. W przypadku incydentów możemy potrzebować realizacji zmiany pilnej a w przypadku problemów powinniśmy korzystać ze zmiany normalnej, którą planujemy w harmonogramie zmian.

Nie możemy wprowadzić żadnej zmiany na środowisko produkcyjne, jeżeli nie „przejdzie” ona przez praktykę umożliwiania zmian, która jest policjantem pilnującym aby wprowadzanie zmiany nie zaburzały produkcyjnie działających usług.

Do pełnego wdrożenia zmiany na produkcji potrzebujmy jeszcze praktykę zarządzania wdrażaniem, która odpowiada za przeniesienie komponentów do środowiska produkcyjnego i wydaniem, która pozwala udostępnić usługę lub funkcjonalność użytkownikom.

Zarządzanie wnioskami o usługę

Na koniec praktyka, która dotyczy normalnego świadczenia usług, nie incydenty, nie problemy, czyli zarządzanie wnioskami o usługę. Tą praktykę bardzo często organizacje wdrażają aby obsługiwać zmiany standardowe, które są dobrze znane i sprawdzone. Wnioski o usługę udokumentowane są w katalogu wniosków o usługę, który jest częścią katalogu usług, obsługiwanego przez praktykę zarządzanie katalogiem usług. Pamiętamy, że wnioski o usługę związane są z konkretnymi usługami i powstają na etapie tworzenia usługi, tak aby mogły być odpowiednio przetestowane i sprawdzone. Ponieważ wnioski o usługę realizowane są na podstawie procedur, ich czas wykonania można określić, tak aby użytkownik, składając wniosek, wiedział jak długo będzie czekał na realizację.

Jeszcze zostało kilka ważnych praktyk więc dokończę ich opis w części trzeciej.

Artykuł Prosto o ITIL – Od czego zacząć wdrażać ITIL? – część 2 pochodzi z serwisu Mariusz Siek.

„Zmiany, zmiany, zmiany … ” cytując za klasykiem z polskiej komedii „Co mi zrobisz jak mnie złapiesz” w reżyserii niezapomnianego Stanisława Barei, to nieodzowny elementy w zarządzaniu usługami. Swoją drogą, wypowiada je ulubiony aktor Barei, Stanisław Tym, który w ostatnich dniach przeszedł na drugą stronę życia.

Jak wiemy z każdą zmianą związane jest ryzyko i każda zmiana wymaga akceptacji, dlatego zmianom poświęca się dużo uwagi, między innymi poprzez praktykę ITIL „Umożliwiania zmian”. Teraz jednak nie o tym.

Systemy i usługi funkcjonują w środowisku, które jest co raz bardziej zmienne, niepewne, złożone i niejednoznaczne (VUCA). Biznes oczekuje wprowadzania co raz więcej zmian, skracania czasu dostarczania usług do klienta i wysokiego poziomu świadczonych usług. Czy jest możliwe poradzić sobie w takich warunkach?

ITIL 4 proponuje cele, zasady, metody i techniki związane z IT wysokich prędkości (High velocity IT), które mają pomóc osiągać zamierzone cele.

1. Kluczowe cele

Kluczowymi celami związanymi z szybkim wprowadzaniem zmian są:

• Wartościowe inwestycje, które wykorzystują IT w sposób strategiczny, innowacyjny i efektywny kosztowo. Organizacje mając określone zasoby, powinny nimi tak zarządzać aby wykorzystywać je do  realizacji projektów i zadań, które będą cechowały się jak największym zwrotem z inwestycji (ROI) i przyczyniały się do osiągania celów strategicznych organizacji.
• Szybki rozwój, który zapewnia sprawnie wykonywane i dostarczane usługi i produkty IT. Wykorzystywane są metodyki Agile i DevOps (DevSecOps), które pozwalają optymalnie wykorzystać cykl wytwarzania usług i produktów, które dostarczane są iteracyjnie i przyrostowo oraz jak najwięcej czynności i działań jest zautomatyzowanych (CI/CD).
• Odporność operacji, gwarantująca wysoką odporność produkcyjnych usług i produktów IT na występowanie incydentów, w szczególności tych poważnych. Wysoka odporność, pozwala na ciągłość działania usług i produktów IT na produkcji. Wystąpienie awarii nie powoduje niedostępności usługi i/lub jest bardzo szybko mitygowane lub naprawiane dzięki zaprojektowanej architekturze oraz automatyzacji.
• Współtworzenie wartości, pozwalające na efektywną interakcję między dostawcami usług a korzystającymi z usług. Dostarczana usługa ma tylko sens, kiedy zapewnia korzystającemu z niej wymaganą wartość, pomaga mu osiągać wyznaczone cele i dostarcza oczekiwanych rezultatów. Rola konsumenta jest równie ważna jak rola dostawcy usług w współtworzeniu wartości.
• Zapewnienie zgodności, zapewniające przestrzeganie wymagań dotyczących nadzoru, zarządzania ryzykiem i zgodności (Governance, Risk, Compliance – GRC). Fakt, że wprowadzamy szybko zmiany, nie oznacza że nie muszą one spełniać zasad, reguł i polityk obowiązujących w organizacji dostawcy usług i konsumenta usług. Zapewnienie zgodności jest kluczowym celem, który powinien być osiągnięty. Nie przestrzeganie zasad, może doprowadzić do nie dostarczenia wartości dla konsumenta.

2. Minimalizacja ryzyka

Aby zmniejszyć ryzyko związane z wprowadzanymi zmianami, zmniejszamy zakres wprowadzanych zmian. Możemy to zrobić dzięki mikrousługom (microservices) i odpowiednio zaprojektowanej architekturze usług i produktów.

Mniejsze zmiany można szybciej wytworzyć, przetestować i wdrożyć na produkcję. Wdrożenie małej zmiany zmniejsza ryzyko niepowodzenia oraz  ewentualne negatywne skutki jakby poszło coś nie tak.

Małą zmianę możemy też szybko wycofać, jeżeli byłaby taka konieczność. Jeżeli wdrażamy dużo i często małych zmian, to doskonalimy nasze umiejętności aby przeprowadzać takie zmiany szybko i bezproblemowo od developmentu do udostępnienie użytkownikom na produkcji.

3. Kluczowe wzorce zachowań

Osiąganie celów opisanych w punkcie 1. wspierane jest przez podejmowanie kluczowych wzorców zachowań, takich jak:

• Akceptacja niejednoznaczności i niepewności. Należy pogodzić się z faktem, że funkcjonujemy w niestabilnym i niejednoznacznym środowisku. Systemy i usługi zawsze będą miały błędy i będą ulegały awariom. Należy to zaakceptować i wykorzystywać eksperymenty w poszukiwaniu rozwiązań i nie obawiać się bezpiecznych i przemyślanych porażek.
• Okazywanie sobie wzajemnego zaufania. Nie można skutecznie i efektywnie współpracować, jeżeli nie można ufać drugiej stronie. Chodzi tu o zaufanie do osób we własnym zespole, pomiędzy zespołami dostawcy usług, w stosunku do partnerów i dostawców czy wreszcie w stosunku do klienta i użytkownika. Szanujemy umiejętności zawodowe innych osób i ufamy, że podejmują dobre decyzje. Szczerze ale również delikatnie przekazujemy informacje zwrotne. Chodzi o stworzenie przyjaznego środowiska pracy, gdzie nie będzie funkcjonowała kultura obwiniania a ludzie będą się czuli dobrze w zgodzie ze swoimi wartościami. Należy zachęcać pracowników do zabierania głosu i dzielenia się wiedzą a kierownictwo do nie odczuwania oporu przed przyznaniem się do niewiedzy lub poproszeniem o pomoc.
• Ciągłe podnoszenie poprzeczki. Należy zawsze kwestionować status quo i nigdy nie być zadowolonym z obecnego stanu. Jeżeli nawet coś działa dzisiaj, może się okazać, że jutro będzie niewystarczające. Zachęcamy do kultury ciągłego doskonalenia, bo zawsze można coś poprawić, udoskonalić lub zmienić, choćby w niewielkim stopniu, z czego będzie zadowolony klient i użytkownicy.
• Pomaganie klientom w realizacji zadań. Każda organizacja powinna stawiać swoich klientów na pierwszym miejscu. Niezależnie jakie zadania czy działania wykonuje dostawca usług, powinien pamiętać, że odbiorcą usług i produktów jest klient i użytkownik. Ich satysfakcja i zadowolenie z korzystania z usługi lub produktu, powinno być najważniejszy celem dostawcy usług. Jeżeli klient lub użytkownik będzie niezadowolony, to niezależnie co zrobił dostawca nie będzie to miało znaczenia. Usługi i produktu oraz praktyki wykonywane przez dostawcę muszą dostarczać wartość oraz wspierać osiąganie rezultatów oczekiwanych przez korzystającego z usług.
• Zobowiązanie się do ciągłego pogłębiania wiedzy. Świat zmienia się tak szybko, że jeżeli się nie rozwijamy, doskonaląc naszą wiedzę i umiejętności, to się cofamy. Ten wzorzec zachowań stanowi podstawę wszystkich pozostałych. Musimy być świadomi potrzebnych informacji i wiedzy, które należy pozyskać aby podejmować lepsze decyzje. Pamiętamy o niejednoznaczności i niepewności, co oznacza że nie jesteśmy przewidzieć wszystkiego w zmiennym środowisku. Każdy w organizacji powinien ciągle się uczyć, poszerzać swoją wiedzę i zwiększać poziom posiadanych informacji. W ciągłym uczeniu pomagają krótkie pętle informacji zwrotnych oraz przeprowadzanie eksperymentów kwestionujących i doskonalących hipotezy.

Kierowanie się opisanymi kluczowymi celami i przyjmowanie kluczowych wzorców zachowań, pomaga mieć kontrolę nad zmiennym, niestabilnym i niejednoznacznym środowisku.

Zachowajmy otwartość umysłu, poszerzajmy ciągle swoją wiedzę i pamiętajmy o dostarczaniu i współtworzeniu wartości z klientem, a pojawiające się zagrożenia będziemy w stanie zidentyfikować i podjąć skuteczne działania aby każdą zmianę zakończyć z sukcesem.

Jak jesteś przygotowany na wprowadzanie wielu zmian w środowisku VUCA?

Artykuł Prosto o ITIL – Jak wprowadzać szybko i bezpiecznie zmiany? pochodzi z serwisu Mariusz Siek.

1.  Święta, święta i po świętach

Koniec roku to czas do podsumowań, refleksji i wyciągania wniosków z tego co już minęło. Ja również podsumuję może nawet więcej niż rok.

Od czasu do czasu słyszę głosy, że ITIL kończy się powoli. Nie przystaje do obecnych czasów, nie wprowadza nic nowego tylko odświeża to co już było 10-15 lat temu. Zacząłem się zastanawiać czy faktycznie tak jest, przecież w każdej plotce jest część prawdy. To jaka ta prawda „naprawdę” jest? Skąd biorą się takie opinie i czy mają uzasadnienie?

Od razu chcę jasno powiedzieć, że każdy może mieć swoje zdanie i ja to zdanie szanuję, w końcu każdy człowiek jest innym, ma swoje doświadczenie i swój własny świat. Nie będę próbował nikogo przekonywać czy starał się zmienić jego opinię. To jest wyłącznie moje doświadczenie, spostrzeżenia i wnioski płynące z serca.

2.  Dawno, dawno temu w odległej galaktyce …

Moja przygoda i podróż z ITIL zaczęła się w październiku 2005 roku, kiedy to brałem udział w szkoleniu ITIL Foundation. ITIL był wtedy w wersji 2 i był to dla mnie całkiem nowy obszar wiedzy. Początek też nie był typowy bo w praktyce zacząłem zajmować się katalogiem usług i umową SLA. W tamtym czasie większość zaczynała od Service Desku, zarządzania incydentami, problemami, zmianą i konfiguracją. Kiedyś napiszę szczegółowo moją historię z ITIL.

Spodobał mi się ten ITIL i zacząłem zdobywać doświadczenie oraz kolejne obszary wiedzy oraz certyfikaty.

ITIL v2 składał się z 11 procesów podzielonych na dwa obszary Service Support (zarządzanie incydentami, problemami, zmianami, wersją i konfiguracją)  i Service Delivery (zarządzanie poziomem usług, dostępnością, pojemnością, ciągłością, bezpieczeństwem i finansowe) i jednej funkcji Service Desk.

Organizacje wdrażały wybrane procesy i wykorzystywały najlepsze praktyki w zarządzaniu usługami IT. Była też możliwość certyfikacji ISO 20000, która potwierdzała, że organizacja ma „wdrożone” wszystkie 11 procesów. Był to elitarne grono, również w Polsce było trochę takich organizacji z tym certyfikatem.

Dzięki wykorzystaniu ITIL, organizacje mogły efektywnie obsługiwać incydenty, problemy, zmiany, zarządzać CMDB itd.. Jeżeli ktoś korzystał z ITIL postrzegany był jako zaawansowany w zarządzaniu usługami IT. Jeżeli organizacja chciała, miała możliwość wdrożenia wszystkich 11 procesów i jednej funkcji.

3.  ITIL v3 czas na zmiany

Około 2007 roku rozpoczęło się wprowadzanie nowej wersji ITIL. Ilość procesów wzrosła do 27. Pojawił się cykl życia usługi od strategii, przez projektowanie, wdrożenie, operacje a skończywszy na ciągłym doskonalenie. Oczywiście procesy z ITIL v2 zostały jednak pojawiły się całkiem nowe, które miały uzupełnić aktywności na poszczególnych etapach cyklu życia usługi. Pewne luki, które były dostrzegane w ITIL v2 zostały wypełnione i został zamknięty cały cykl życia usługi. Oczywiście wdrożenie wszystkich procesów było już dużym wyzwaniem i organizacje korzystały z tych, które były im w danym momencie potrzebne. Zresztą zasada ITIL „adopt and adapt”, oznacza, że wybieramy i dopasowujemy te elementy ITIL, które pasują do naszych potrzeb.

4.  Kto się nie rozwija ten się cofa

ITIL zawsze potrafił słuchać potrzeb biznesu  oraz IT i dopasowywać się do zmian w technologii i otoczeniu biznesowym. Rozglądał się również dookoła i zauważał inne metodyki pracy takie jak Lean, Agile, DevOps. Miał jednak świadomość, że każdej czegoś brakuje i sam ITIL w pewnych obszarach jest niewystarczający.

Na tej bazie w 2020 roku powstał ITIL 4, który wskazuje konieczność dostarczania wartości, skupieniu się na doświadczeniu użytkownika i klienta, strumieniach wartości oraz transformacji cyfrowej. Widzi również potrzebę szukania synergii z innymi metodykami pracy Lean, Agile i DevOps, poprzez wprowadzenie siedmiu podstawowych zasad. Z nowych rzeczy, oprócz podstawowych zasad, pojawia się system wartości usług (SVS), jako model zarządzania usługami IT oraz łańcuch wartości usług, którego sześć działań pomaga tworzyć strumienie wartości w organizacjach.

Możemy również wykorzystać cztery wymiary zarządzania usługami, które pozwalają na całościowe, holistyczne spojrzenie na zagadnienia związane z zarządzaniem usługami. Mamy 34 praktyki jako mięso zarządzania usługami i główne narzędzie do realizacji pracy i osiągania celu w ramach kroków  strumieniu wartości usług.

5.  Gdzie jest obecnie problem z wykorzystaniem ITIL?

Według mnie wiedzy, metod, praktyk i technik jest tak dużo, że komuś zaczynającemu trudno jest się w tym odnaleźć i zrozumieć od czego zacząć, co wybrać i na czym się skupić. Ponad 3 lata już prowadzę szkolenia z ITIL 4 i mogę powiedzieć, że dopiero teraz poznałem i rozumiem kluczowe elementy, nie jest to jednak jeszcze cała wiedza. Nikt nie czyta wszystkich 34 praktyk i bardzo dobrze, bo nie taki jest cel ITIL.

Niezależnie co robisz, pamiętaj o wspomnianej już zasadzie „adopt and adapt”. Selektywnie wybieraj tą wiedzę, która jest Tobie lub Twojej organizacji potrzebna i stosuj ją w praktyce, pamiętając o zaczynaniu, tam gdzie się aktualnie znajdujesz, podejściu iteracyjnym z informacją zwrotna oraz ciągłym doskonaleniu. Wykorzystanie ITIL to nie pojedyncze wdrożenie ale podróż i droga, która nigdy się nie kończy. Nie wystarczy coś zrobić jednorazowo, trzeba cały czas to udoskonalać, rozwijać, jeżeli trzeba rozszerzać, obserwując co działa a co nie. ITIL to nie jest już metodyka ale cała filozofia działania, która pomaga funkcjonować w świecie VUCA i nadążać za szybkim tempem zmian, jakie stawia przed IT biznes.

Jeżeli ktoś jest na etapie, że nie ma świadomości, że nie wie, to jak może wybrać najlepsze praktyki zarządzania, skoro jest to dla niego nieistniejąca galaktyka? Jak nie mając podstaw w zarządzaniu usługami, a takie podstawy daje ITIL Foundation, można zarządzać usługami IT? Dlaczego nie chcemy poznać tych zasad, które pomogą nam przebyć tą podróż w sposób świadomy, prostszy, skuteczny? Dlaczego organizacje nie doceniają ponad 30 lat doświadczenia zbieranego w różnych obszarach zarządzania usługami?

6.  Recepta na bolączki?

Każdy, kto w organizacji zajmuje się w jakimś stopniu zarządzaniem usługi IT a tak naprawdę, jest to każda osoba, która pracuje w dziale IT, powinna przejść szkolenie ITIL 4 Foundation. To są podstawy aby zrozumieć model usługowy i poznać język i słownictwo, którym wszyscy powinni się posługiwać. Na tym szkoleniu oprócz nowych elementów ITIL 4, poznaje się 15 praktyk, które są najczęściej wykorzystywane w organizacjach. Nadal jest to podstawowa wiedza ale daje ona możliwości dalszego rozwoju.

Są oczywiście kolejne szkolenia i kto będzie potrzebował tej wiedzy może w nich uczestniczyć ale żadne szkolenie, nie zastąpi samokształcenia i samodzielnego rozwoju i nauki. O każdej z 34 praktyk trzeba doczytać samemu. Zagłębić się w te tematy, które aktualnie są dla Ciebie ważne i którymi się zajmujesz. Opis 34 praktyk to źródło nieocenionej wiedzy dla każdego do początkującego po doświadczonego w zarządzaniu usługami. Poznawaną wiedzę trzeba stosować w praktyce inaczej bardzo szybko ulatuje z ludzkiego umysłu.

Pamiętajcie, że ten rozwój musi być ciągły, systematyczny, regularny. Działanie zrywami nie jest skuteczne. Małe ale regularnie wykonywane kroki dotyczące rozwoju wiedzy, umiejętności i kompetencji,  czasem przynoszą oczekiwanie rezultaty.

W podróży z ITIL można skorzystać z pomocy doświadczonych specjalistów, w końcu podróż z drugim człowiekiem (ludźmi) jest ciekawsza, łatwiejsza, nie nudzi się i mija szybciej. Jeżeli wiec nie mamy wystarczającej wiedzy, doświadczenia i czasu aby samemu poznawać i wykorzystywać najlepsze praktyki ITIL, znajdźmy kogoś kto podzieli się swoją wiedzą, doświadczeniem i umiejętnościami. Tak, trzeba ponieść tego koszty ale lepiej patrzeć na to jak na inwestycję we własny rozwój, doskonalenie i transformację. Może się okazać, że taka pomoc przemieni się z czasem w partnerstwo i wspólne podążanie wybraną drogą.

Artykuł Czy ITIL umarł? pochodzi z serwisu Mariusz Siek.

W poprzednim artykule opisywałem jak utworzyć nową usługę za pomocą strumienia wartości usług. Drugim najczęściej występującym w organizacjach strumieniem wartości jest „Przywrócenie usługi do działania”. O kluczowych elementach strumienia wartości usług możesz zapoznać się w artykule „Prosto o ITIL – Jak Strumienie Wartości Usług dostarczają wartość?”

Dostawca usług świadczy swoje usługi konsumentom i zapewnia wsparcie użytkownikom w przypadku gdy usługa przestanie funkcjonować, musi ją jak najszybciej przywrócić do działania. Zapewnia mu to dobrze opracowany i wdrożony strumień wartości.

Składa się on z następujących elementów.

1. Wejścia strumienia

Wejściem do strumienia wartości usług jest potrzeba przywrócenia wartości, jaką jest prawidłowo działająca usługa. Wymagania te mogą pochodzić od:

• Użytkowników, którzy nie mogą korzystać z produktu lub usługi działającej na produkcji. Ta utrata produktywności prowadzi do utraty wartości.
• Monitoringu, prowadzonego przez dostawcę usług, w celu wykrywania zdarzeń, które wpływają na niedziałanie lub niepoprawne działanie usługi. Te proaktywne działania pozwalają rozwiązywać incydenty, zanim zostaną zgłoszone przez użytkowników. W takim przypadku można powiadomić użytkowników o podjętych działaniach.

2. Kroki strumienia

Krok 1 – Potwierdź i zarejestruj zapytanie od użytkownika

1. Działanie łańcucha wartości usług – Angażowanie
2. Opis  – Zaangażowanie klienta lub użytkownika w celu zebrania jak najwięcej informacji o zgłoszeniu i zarejestrowaniu go przez Service Desk. Na tym etapie nie jest jeszcze wiadomo czy mamy do czynienia z incydentem, problemem, wnioskiem o usługę czy zmianą.
3. Wspierające praktyki zarządzania

1. 1. Zarządzanie katalogiem usług
   2. Service Desk

Krok 2 – Zaklasyfikuj zapytanie jako incydent i podejmij próbę jego rozwiązania

1. Działanie łańcucha wartości usług – Dostarczanie i wspieranie
2. Opis  – Agent Service Desk, na podstawie zarejestrowanych informacji, klasyfikuje zapytanie od użytkownika jako incydent i podejmuje próbę jego rozwiązania. W tym celu korzysta z Bazy Wiedzy, w której wyszukuje gotowe rozwiązanie dla zgłoszonego incydentu.
   Jeżeli rozwiązanie przywraca usługę do działania kończy się strumień wartości, ponieważ odzyskaliśmy wartość.
   Jeżeli Agent SD nie znajduje rozwiązania w bazie wiedzy, eskaluje (przekazuje) incydent do obsługi przez specjalistów w odpowiednim zespole wsparcia (kategoria incydentu).
3. Wspierające praktyki zarządzania

1. 1. Zarządzanie konfiguracją usług
   2. Zarządzanie incydentami
   3. Zarządzanie wiedzą
   4. Monitorowanie i zarządzanie zdarzeniami
   5. Service Desk

Krok 3 – Uzyskaj poprawkę od zespołu specjalistów

1. Działanie łańcucha wartości usług – Uzyskanie/tworzenie
2. Opis  – Wykonanie tego kroku może być przeprowadzone w zależności od kontekstu, w różny sposób:

1. 1. Agent SD szuka poprawki na stronie www dostawcy zewnętrznego (vendor). Cały czas kontrola incydentu jest po stronie SD a nie vendora.
   2. Agent SD zgłasza incydent do dostawcy zewnętrznego (vendor). Mamy równoległe incydenty w systemie zgłoszeń dostawcy usługi i dostawcy zewnętrznego. Kontrola incydentu jest po stronie SD.
   3. Agent SD przekazuje incydent do wewnętrznego zespołu wsparcia, jednocześnie przekazując jego kontrolę.
   4. Agent SD przekazuje incydent do zewnętrznego zespołu wsparcia. Kontrola incydentu może zostać po stronie SD lub być przekazana na zewnątrz.

1. Wspierające praktyki zarządzania

1. 1. Zarządzanie konfiguracją usług
   2. Zarządzanie incydentami
   3. Zarządzanie infrastrukturą i platformami
   4. Zarządzanie wiedzą
   5. Service Desk
   6. Zarządzanie finansowe usługami
   7. Walidacja i testowanie usług
   8. Programowanie i zarządzanie oprogramowaniem
   9. Zarządzanie dostawcami

Krok 4 – Wdróż poprawkę

1. Działanie łańcucha wartości usług – Projektowanie i przekazywanie
2. Opis  – Po uzyskaniu, przetestowaniu i walidacji, poprawka dla incydentu wdrażana jest dla użytkownika lub do środowiska produkcyjnego. Wdrożenie może zostać przeprowadzone na kilka sposobów np. z wykorzystaniem continuous integration/continuous delivery (CI/CD) w celu dystrybucji rozwiązania na produkcję.
3. Wspierające praktyki zarządzania

1. 1. Zarządzanie konfiguracją usług
   2. Zarządzanie wdrażaniem
   3. Zarządzanie incydentami
   4. Zarządzanie wiedzą
   5. Service Desk
   6. Zarządzanie finansowe usługami
   7. Programowanie i zarządzanie oprogramowaniem
   8. Zarządzanie dostawcami

Krok 5 – Zweryfikuj, że incydent został rozwiązany

1. Działanie łańcucha wartości usług – Dostarczanie i wspieranie
2. Opis  – Po wdrożeniu poprawki na produkcję, należy zweryfikować czy jest ona skuteczna i rozwiązała incydent. Potwierdzenie rozwiązania incydentu powinien wykonać użytkownik (zgłaszający) aby sprawdzić czy wartość została odzyskana w satysfakcjonujący sposób, z perspektywy użytkownika a nie dostawcy usług. W tym celu agent SD kontaktuje się z użytkownikiem. Incydent może być zamknięty po potwierdzeniu rozwiązania przez użytkownika
3. Wspierające praktyki zarządzania

1. 1. Zarządzanie incydentami
   2. Zarządzanie wiedzą
   3. Zarządzanie konfiguracją usług
   4. Service Desk
   5. Zarządzanie poziomem świadczenia usług

Krok 6 – Uzyskaj informacje zwrotne od klienta

1. Działanie łańcucha wartości usług – Angażowanie
2. Opis  – Po rozwiązaniu incydentu należy poprosić klienta/użytkownika lub innych interesariuszy o informacje zwrotna, która pozwoli zidentyfikować możliwości poprawy usługi, sposób komunikacji z użytkownikiem, procedury obsługi incydentów lub praktyki, które są wykorzystywane w strumieniu wartości.
3. Wspierające praktyki zarządzania

1. 1. Ciągłe doskonalenie
   2. Zarządzanie infrastrukturą i platformami
   3. Service Desk
   4. Programowanie i zarządzanie oprogramowaniem
   5. Zarządzanie dostawcami

Krok 7 – Zidentyfikuj możliwości doskonalenia

1. Działanie łańcucha wartości usług – Doskonalenie
2. Opis  – Na podstawie zebranych informacji zwrotnych od wszystkich interesariuszy można zaplanować działania związane z doskonaleniem obejmujące: komponenty systemu wartości usług SVS, strumień wartości usług, relacje z klientem, użytkownikiem, dostawcą zewnętrznym lub innymi interesariuszami, sposoby definiowania i postrzegania wartości. Inicjatywy związane z doskonaleniem muszą być zarejestrowane w rejestrze ciągłego doskonalenia i następnie w odpowiedni sposób zarządzone.
3. Wspierające praktyki zarządzania

1. 1. Zarządzanie konfiguracją usług
   2. Ciągłe doskonalenie
   3. Zarządzanie wdrożeniem
   4. Zarządzanie incydentami
   5. Zarządzanie infrastrukturą i platformami
   6. Zarządzanie wiedzą
   7. Monitorowanie i zarządzanie zdarzeniami
   8. Zarządzanie problemami
   9. Zarządzanie ryzykiem
   10. Service Desk
   11. Finansowe zarządzanie usługą
   12. Walidacja i testowanie usług
   13. Zarządzanie poziomem świadczenia usług
   14. Programowanie i zarządzanie oprogramowaniem
   15. Zarządzanie dostawcami

3. Wyjście strumienia

Po rozwiązaniu incydentu, usługa zostaje naprawiona i odzyskane jest dostarczana wartość. Użytkownicy mogą w pełni korzystać z możliwości jakie daje usługa.

Każdy krok w strumieniu wartości usług „Przywrócenie usługi do działania” przyczynia się do tworzenia wartości. Głównymi narzędziami wspierającymi współtworzenie wartości są wymienione w każdym kroku praktyki zarządzania. Bez korzystania z odpowiedniego zestawu praktyk dla każdego z kroków, nie jest możliwe dostarczanie wartości.

Czy mógłbyś zastosować taki strumień wartości w swojej organizacji? Jakiego kroku Ci brakuje lub jaki według Ciebie jest niepotrzebny. Zapraszam do dyskusji.

Artykuł Prosto o ITIL – Jak strumień wartości przywraca usługę do działania? pochodzi z serwisu Mariusz Siek.