W świecie, gdzie każda minuta przestoju przekłada się na realne straty, priorytetem staje się efektywne zarządzanie incydentami.

Centralnym elementem tego procesu jest recepcja zgłoszenia. To pierwszy, krytyczny krok w obsłudze incydentu IT. Polega na rejestracji incydentu zgłoszonego przez użytkownika i wprowadzeniu go do systemu obsługi zgłoszeń. To coś więcej niż odebranie telefonu – to ustrukturyzowany proces, który zapewnia udokumentowanie i wiarygodność informacji o incydencie.

Czym jest recepcja zgłoszenia?

To moment, w którym użytkownik po raz pierwszy kontaktuje się z działem IT w związku z incydentem. Incydent przestaje być indywidualnym doświadczeniem i staje się oficjalnym elementem procedury naprawczej.

Recepcja zgłoszenia obejmuje:

• Rejestracja zgłoszenia: Zapisanie w systemie ITSM. Generowany jest unikalny numer zgłoszenia, umożliwiający śledzenie postępów.
• Zebranie kluczowych informacji: Pozyskanie od użytkownika niezbędnych danych, takich jak:
  • Identyfikacja zgłaszającego: Dane kontaktowe użytkownika.
  • Opis incydentu: Szczegółowe informacje o incydencie, dotkniętym systemie/aplikacji.
  • Czas wystąpienia: Kiedy incydent się pojawił?
  • Objawy: Komunikaty błędów, nietypowe zachowanie systemu.
  • Wpływ: Jak incydent wpływa na pracę użytkownika/działalność firmy (pilność).
• Potwierdzenie przyjęcia: Wysłanie automatycznego powiadomienia do zgłaszającego z numerem referencyjnym zgłoszenia. To buduje zaufanie i daje pewność, że sprawa jest w toku.
• Wstępna kategoryzacja: Określenie rodzaju incydentu (np. problem z siecią, błąd oprogramowania). Ułatwia to przypisanie zgłoszenia do właściwego zespołu wsparcia.
• Ustalenie priorytetu: Na podstawie pilności i wpływu na biznes, wstępne określenie priorytetu zgłoszenia.

Dlaczego to tak ważne?

Efektywna recepcja zgłoszenia to fundament sprawnego działania działu IT i zadowolenia użytkowników. Oto dlaczego:

• Formalizacja procesu: Strukturyzuje obsługę zgłoszeń, eliminując ryzyko zagubienia ich w natłoku komunikacji.
• Efektywna komunikacja: Potwierdzenie przyjęcia zgłoszenia informuje użytkownika, że jego incydent jest znany i podjęto działania.
• Sprawne zarządzanie zasobami: Ułatwia przypisywanie zgłoszeń do odpowiednich zespołów wsparcia i monitorowanie postępów.
• Dane do analizy i doskonalenia: Zebrane informacje dostarczają cennych danych do identyfikacji powtarzających się incydentów i optymalizacji procesów.

Recepcja zgłoszenia w świetle ITIL 4

Recepcja zgłoszenia idealnie wpisuje się w framework ITIL 4, a w szczególności w praktyki:

• Service Desk: Praktyka Service Desk jest centralnym punktem kontaktu między użytkownikami a dostawcą usług IT. Jak wspomniano w jednym z artykułów, większość organizacji zaczyna wdrażanie ITIL właśnie od Service Desk, a recepcja zgłoszenia jest jego kluczowym elementem.
• Zarządzanie incydentami: Celem tej praktyki jest jak najszybsze przywrócenie normalnego działania usługi. Recepcja zgłoszenia stanowi pierwszy krok w tym procesie. Zgodnie z wcześniejszym wpisem, Zarządzanie Incydentami i Service Desk to praktyki wdrażane najczęściej razem.
• Zarządzanie wnioskami o usługi: Recepcja zgłoszenia obejmuje również rejestrowanie wniosków o usługi (np. prośba o nowy sprzęt, dostęp do oprogramowania). Wnioski o usługi to kolejna popularna praktyka w organizacjach.

Jira Service Management (JSM) – wsparcie dla recepcji zgłoszeń

JSM oferuje szereg funkcjonalności wspierających proces recepcji zgłoszeń:

• Portale samoobsługowe: Użytkownicy mogą zgłaszać incydenty i wnioski o usługę za pośrednictwem intuicyjnych portali.
• Konfigurowalne formularze: Możliwość tworzenia formularzy zgłoszeniowych dostosowanych do różnych typów incydentów i wniosków o usługę.
• Automatyzacja przepływu pracy: Automatyczne przypisywanie zgłoszeń do odpowiednich zespołów na podstawie kategorii i priorytetu.
• Integracja z narzędziami komunikacji: Możliwość integracji z narzędziami takimi jak Slack czy Microsoft Teams w celu usprawnienia komunikacji.
• Raportowanie i analizy: Dostęp do raportów i analiz dotyczących efektywności procesu obsługi zgłoszeń.

Optymalizacja recepcji zgłoszeń

Aby recepcja zgłoszeń przebiegała jak najsprawniej, należy przeprowadzić:

• Szkolenie personelu: Zapewnij odpowiednie szkolenie dla osób odpowiedzialnych za recepcję zgłoszeń.
• Wielokanałowość: Umożliwiaj zgłaszanie incydentów różnymi kanałami (telefon, email, portal samoobsługowy).
• Automatyzacja procesów: Wykorzystaj automatyzację do przyspieszenia rejestracji i kategoryzacji zgłoszeń.
• Proste formularze: Twórz jasne i zwięzłe formularze zgłoszeniowe.
• Monitorowanie i doskonalenie: Regularnie analizuj dane i wdrażaj ulepszenia w procesie.

Podsumowanie

Recepcja zgłoszenia to fundament sprawnej obsługi incydentów w IT. To proces rejestracji incydentu, zebrania kluczowych informacji i zapewnienia użytkownikowi, że jego sprawa jest w toku. W połączeniu z narzędziami takimi jak Jira Service Management i praktykami ITIL, efektywna recepcja zgłoszeń pozwala na sprawne rozwiązywanie incydentów, minimalizowanie przestojów i zwiększanie satysfakcji użytkowników.

Artykuł Recepcja zgłoszenia w IT: Fundament sprawnej obsługi incydentów 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.

Najczęściej z praktyka Service Desk stosowana jest praktyka Zarządzania Incydentami. Nie ma chyba organizacji, która w jakiś sposób nie próbuje przywracać usługi do działania, gdy użytkownicy nie mogą z nich korzystać. Tak naprawdę, żeby obsługa incydentów byłą skuteczna praktyka Service Desk musi najpierw przyjąć zgłoszenia od użytkowników i kierować do właściwego strumienia wartości. Wydawać by się mogło, że każdy w jakimś stopniu zna praktykę Zarządzania Incydentami. Zobaczmy czy coś nas może zaskoczyć?

Cel

Celem praktyki zarządzanie incydentami jest minimalizowanie negatywnego wpływu incydentów poprzez jak najszybsze przywrócenie normalnej eksploatacji usługi.

Jeżeli mamy rozwiązania docelowe to stosujemy docelowe a jeżeli mamy tymczasowe, np. obejście to również możemy z niego skorzystać. Chcemy to zrobić jak najszybciej, czyli bez zbędnych analiz i tracenia czasu szukanie przyczyny źródłowej. Tym zajmuje się praktyka Zarządzania Problemami, którą będę jeszcze opisywał.

Ważne jest aby dobrze zdefiniować co oznacza „normalna eksploatacja usługi” aby było to tak samo zrozumiałe dla użytkowników jak i dostawcy usług.

Warto pamiętać, że praktyka Zarządzania Incydentami nie musi obejmować tylko zgłoszeń od użytkowników. Zajmuje się również incydentami, które zostały wykryte przez narzędzia monitorowania lub specjalistów z danej dziedziny.

Ścieżka decyzyjna czy rejestrować incydent powinna wyglądać jak na rysunku poniżej

Rys 1. Diagram decyzyjny rejestracji incydentu (źródło: książka ITIL 4 Zarządzanie incydentami opracowana przez Peoplecert)

Definicja incydentu

Nieplanowana przerwa w usłudze lub obniżenie jakości usługi.

Pierwsza część jest „zerojedynkowa”, usługa działa nie działa, usługa dostępna niedostępna. To zazwyczaj nie jest trudno określić. Jednak co oznacza „obniżenie jakości usługi”? Czy jak usługa działa dwa razy wolniej to już mamy incydent? Czy jak połowa użytkowników może korzystać z usługi a druga połowa nie może, to mamy incydent? Dla każdej usługi trzeba jak najbardziej precyzyjnie zdefiniować co oznacza obniżenie jej jakości.

Przy okazji incydentów można tworzyć modele incydentów, czyli powtarzalne podejście do zarządzania określonym typem incydentu. Modele incydentów mają nam pomóc w jak najszybszym rozwiązaniu incydentu.

Większość organizacji definiuje również „Poważny incydent” (Major incident), czyli incydent o znaczącym wpływie na działalność biznesową wymagający natychmiastowego skoordynowanego rozwiązania. W organizacjach poważne incydenty są potocznie nazywane awariami i mogą dotyczyć również incydentów o wyższym poziomie złożoności.

Obejście (workaround) i dług techniczny

Nie można byłoby rozwiązać wielu incydentów, jeżeli nie korzystałoby się z obejść (workaround), czyli:

Rozwiązanie, które zmniejsza lub eliminuje wpływ incydentu bądź problemu, dla którego pełne rozwiązanie nie jest jeszcze dostępne. Niektóre obejścia zmniejszają prawdopodobieństwo wystąpienia incydentów.

Obejścia tworzone są w ramach praktyki Zarządzania Problemami, zapisywane są w bazie wiedzy a później wykorzystywane są do obsługi incydentów.

Trzeba jednak pamiętać, że stosowanie obejść a nie rozwiązań trwałych, systemowych zwiększa dług techniczny, czyli backlog wszystkich przeróbek nagromadzonych wskutek wybrania obejść zamiast rozwiązań systemowych, których wdrożenie potrwałoby dłużej.

Zakres praktyki

Zakres praktyki zarządzania incydentami obejmuje:

• Wykrywanie i rejestrowanie incydentów
• Diagnozowanie i badanie incydentów
• Przywrócenie usług, których dotyczą problemy i elementów konfiguracji do uzgodnionej jakości
• Zarządzanie zapisami incydentów
• Komunikacja z odpowiednimi interesariuszami w całym cyklu życia incydentu
• Przegląd incydentów i inicjowanie doskonalenia usług i praktyki zarządzanie incydentami po ich rozwiązaniu

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.

Dla praktyki zarządzanie incydentami zostały zdefiniowane trzy czynniki sukcesu:

• Wczesne wykrywanie incydentów – dążymy do sytuacji aby jak najwcześniej wykrywać incydenty. Co oznacza, że nie czekamy tylko na zgłoszenia od użytkowników ale podejmujemy działania proaktywne, np. monitorowanie usług i ich komponentów, w czym wspiera nas praktyka Monitorowania i zarządzania zdarzeniami. Wszystko to robimy po to, aby minimalizować czas niedziałania usługi, w szczególności czy wpływa to na użytkowników. Dzięki temu możemy uzyskać wyższą satysfakcję użytkowników.
• Szybkie i sprawne rozwiązywanie incydentów – ma wpływ na jakość świadczonych usług.
  • Dlatego dla prostych incydentów korzystamy z wcześniej przygotowanych w bazie wiedzy rozwiązań, procedur, instrukcji.
  • Dla skomplikowanych incydentów, gdy charakter incydentu jest nieznany ale systemy i komponenty są znane zespołom wsparcia oraz organizacja posiada dostęp do wiedzy eksperckiej, incydenty są zwykle kierowane do specjalistycznej grupy lub grup w celu diagnozy i rozwiązania incydentu.
  • W złożonych sytuacjach, gdy zdefiniowanie dziedziny i grupy ekspertów jest trudne lub niemożliwe, lub gdy zdefiniowane grupy ekspertów nie znajdują rozwiązania, przydatne może być podejście „Swarming„.
    To technika rozwiązywania różnych złożonych zadań. W swarmingu wiele osób z różnymi obszarami wiedzy pracuje razem nad zadaniem, dopóki nie stanie się jasne, które kompetencje są najbardziej istotne i potrzebne.
  • Incydenty mogą zostać rozwiązane samemu przez użytkowników, dzięki podejściu „shift left„. Podejście do zarządzania pracą, które koncentruje się na przenoszeniu działań bliżej źródła pracy w celu uniknięcia potencjalnie kosztownych opóźnień lub eskalacji. Wywodzi się ono z tworzenia oprogramowania ale w kontekście wsparcia podejście shift-left może charakteryzować się dostarczaniem narzędzi samopomocy użytkownikom końcowym.
  • Na szybkość rozwiązania incydentu wpływa również określenie właściwego priorytetu dla incydentu oraz określenie kategorii czyli przydzielenie do właściwej grupy wsparcia. Skierowanie incydentu do nieprawidłowej grupy wsparcia  oznacza wydłużenie jego czasu obsługi oraz skrócenie czasu rozwiązania, gdy incydent w końcu trafi pod właściwy adres. Ważne jest aby określać priorytety dla wszystkich zadań, nie tylko incydentów, realizowanych przez zespoły w organizacji aby było dla nich jasne, które zgłoszenia są priorytetowe.
• Ciągłe doskonalenie zarządzania incydentami – nie spoczywamy na laurach ale przeprowadzamy okresowe przeglądy incydentów w celu doskonalenia skuteczności i sprawności praktyki zarządzanie incydentami. Zwykle dla każdego poważnego incydentu robimy przegląd aby wyciągnąć lekcje (lessons learned) i pomyśleć co można następnym razem zrobić lepiej i jakich wpadek uniknąć.

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

• PSF – Wczesne wykrywanie incydentów
  • Czas od wystąpienia incydentu do jego wykrycia
  • Odsetek incydentów wykrytych poprzez monitorowanie i zarządzanie zdarzeniami
• PSF – Szybkie i sprawne rozwiązywanie incydentów
  • Czas od wykrycia zdarzenia do akceptacji diagnozy
  • Czas diagnozy
  • Liczba ponownych przydziałów
  • Odsetek czasu oczekiwania w ogólnym czasie obsługi incydentu
  • Wskaźnik rozwiązań za pierwszym razem
  • Spełnienie uzgodnionego czasu rozwiązania
  • Zadowolenie użytkowników z obsługi i rozwiązania incydentów
  • Odsetek incydentów rozwiązanych automatycznie
  • Odsetek incydentów rozwiązanych przed ich zgłoszeniem przez użytkowników
• PSF – Ciągłe doskonalenie zarządzania incydentami
  • Odsetek rozwiązań incydentów wykorzystujących wcześniej zidentyfikowane i zapisane rozwiązania
  • Odsetek incydentów rozwiązanych przy użyciu modeli incydentów
  • Doskonalenie kluczowych wskaźników praktyki w czasie
  • Równowaga między metrykami szybkości i skuteczności rozwiązania incydentu

Przedstawiłem najważniejsze koncepcje związane z praktyką zarządzanie incydentami. 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 Incydentami – część 1 pochodzi z serwisu Mariusz Siek.

Praktykę ITIL, którą organizację wdrażają najczęściej to Service Desk. Większość organizacji zaczyna swoją przygodę z ITIL od praktyki Service Desk i bardzo mocno z nią powiązaną praktyką zarządzania incydentami. Czy jednak fakt, że ta praktyka jest najczęściej wykorzystywana oznacza, że wiemy jakie elementy powinna zawierać? Zobaczmy jakie są najważniejsze elementy praktyki Service Desk.

Cel i najważniejsze zagadnienia

Celem praktyki service desk jest wychwytywanie zapotrzebowania na rozwiązywanie incydentów i wniosków o usługi. Jest ona również punktem początkowym i pojedynczym punktem kontaktu dostawcy usług ze wszystkimi konsumentami: klient i użytkownicy.

Warto zwrócić uwagę, że Service Desk nie zajmuje się tylko incydentami ale również wnioskami o usługę. A ja bym powiedział, że ponieważ użytkownik wszystkie swoje sprawy zgłasza przez Service Desk, to również mogą to być problemy, zmiany, usprawnienia, propozycje udoskonaleń, uwagi do umowy SLA, uwagi do harmonogramu zmian lub wydań. Trochę się tego uzbierało a to jeszcze nie zamknięta lista.

Dobrze jest w tym miejscu wyjaśnić, wielorakie znaczenie nazwy service desk, w odniesieniu do czterech wymiarów zarządzania usługami:

• Dedykowany zespół, nazywany service desk – Organizacje i ludzie
• Zintegrowany system informatyczny, nazywany często service desk – Informacje i technologie
• Przepływy pracy i procedury komunikacji z użytkownikami i innymi zespołami  – Strumienie wartości i procesy
• Zaangażowane strony trzecie, dostawcy zewnętrzni pełniący rolę service desk

Zespół service desk może być zaangażowany również w inne praktyki takie jak: zarządzanie incydentami, zarządzanie wnioskami o usługę, zarządzanie problemami, zarządzanie konfiguracją, zarządzanie relacjami.

Komunikacja wszechkanałowa

ITIL podkreśla, że praktyka service desk powinna wykorzystywać komunikację wszechkanałową (omnichanell communication), rozumianą jako ujednolicona komunikacja w wielu kanałach oparta na udostępnianiu informacji w różnych kanałach i dostarczaniu niezakłóconych doświadczeń komunikacyjnych.

Co to oznacza w praktyce dla użytkownika? Dostawca usługi udostępnia wiele kanałów komunikacji użytkownikowi, które są ze sobą zintegrowane. Dzięki integracji informacje i dane mogą przepływać pomiędzy kanałami. Użytkownik może wedle swojej wygody, w czasie życia zgłoszenia różnymi kanałami przekazywać informacje, wykonywać czynności wynikające z procesu, komunikować się z zespołami wsparcia, nie tylko z service desk.

Generalnie im więcej kanałów tym lepiej ale pod warunkiem, że wszystkie kanały są operacyjne, to znaczy działają i można z nich korzystać. Duża ilość kanałów pozwala użytkownikom wybrać ulubiony kanał do komunikacji z service desk. Im więcej kanałów tym większa przepustowość zespołu service desk, bo część kanałów jest zautomatyzowana i nie wymaga obsługi ludzkiej, dzięki temu użytkownik może przekazać swoje zgłoszenie i otrzymać potwierdzenie jego przyjęcia. Zgłoszenia z różnych kanałów muszą być rejestrowane w jednym miejscu, rejestrze zgłoszeń, aby można było nimi później zarządzić.

Empatia w usłudze i moment prawdy

Praktyka service desk na co dzień spotyka się z użytkownikami i komunikuje z nimi. Dlatego ważne jest aby pracownicy service desk wykazywali się empatią w usłudze, czyli zdolnością do rozpoznawania, zrozumienia, przewidywania i prognozowania zainteresowań, potrzeb, intencji i doświadczeń innej strony w celu ustanowienia, utrzymania i doskonalenia relacji usługowej.

Chociaż opiera się ona na zdolności zrozumienia uczuć, emocji i potrzeb innych ludzi, w tym przypadku użytkownika, nie oznacza to, że pracownicy service desk powinni brać na siebie wszystkie, szczególnie negatywne emocje i frustrację użytkowników. Powinien za to je rozpoznać i zrozumieć oraz wykazać się zrozumieniem i gotowością do pomocy.

Pamiętajmy, że żadne narzędzia, technologia, nawet AI nie mogą zaspokoić empatii w usługach. Może to być tylko uzyskane poprzez interakcje międzyludzkie za wykorzystaniem kanałów takich jak czat, wideo, połączenia głosowe, w tym telefon oraz poprzez spotkanie twarzą w twarz.

Praktyka service desk odpowiada za komunikację między użytkownikami a dostawca usług, w trakcie których dochodzi do momentu prawdy, czyli każdy epizod, w którym klient lub użytkownik styka się z jakimś aspektem organizacji i uzyskuje wrażenie związane z jakością jej usług. Pozwala to ustalić i spełnić oczekiwania klienta, a ostatecznie uzyskać jego zadowolenie.

Każdy kontakt użytkownika z dostawcą usług, wpływa na jego doświadczenie i zadowolenie, dlatego tak ważne jest aby dostawca usług, korzystając z praktyki service desk dbał o dobra komunikację z każdym użytkownikiem.

Zakres praktyki

Zakres praktyki service desk obejmuje:

• Ustanowienie i utrzymywanie kanałów komunikacji i interfejsów między dostawcą usług a użytkownikami
• Komunikację z użytkownikami
• Umożliwienie, rejestrowanie i śledzenie komunikacji pomiędzy dostawcą usług a użytkownikami.

Czynniki sukcesu praktyki (PSF)

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.

Dla praktyki service desk zostały zdefiniowane dwa czynniki sukcesu:

• Umożliwienie i ciągłe doskonalenie efektywnej, sprawnej i wygodnej komunikacji pomiędzy dostawcą usług a jego użytkownikami. W ramach którego określane są kanały wsparcia dostępne dla użytkowników i klientów oraz ich zakres sprawności, efektywności i wygody. Kanały musza spełniać potrzeby użytkowników i klientów. Nie wystarczy zapewnić tylko sprawnego wysyłania komunikatów ale również zadbać i weryfikować, że komunikaty zostały zrozumiane i przyniosły określony skutek. Pamiętamy o wszechkanałowości, która została omówiona powyżej.
• umożliwienie efektywnej integracji komunikacji użytkowników ze strumieniami wartości. Praktyka service desk jest wejściem komunikacji do wielu różnych strumieni wartości. Użytkownik przekazujący zgłoszenie do service desk nie wie czy to jest incydent, problem, zmiana, wniosek o usługę. To rolą praktyki service desk jest skierowanie zgłoszenia do odpowiedniego strumienia wartości.

Kluczowe metryki (KPI)

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

• PSF – Umożliwienie i ciągłe doskonalenie efektywnej, sprawnej i wygodnej komunikacji pomiędzy dostawcą usług a jego użytkownikami
  • Jakość informacji otrzymywanych za pośrednictwem kanałów service desk, mierzona względem uzgodnionych kryteriów jakości informacji
  • Jakość informacji otrzymywanych za pośrednictwem kanałów service desk, mierzona względem uzgodnionych kryteriów jakości informacji
  • Zadowolenie kluczowych interesariuszy komunikacji z jakości informacji i wygody kanałów komunikacji service desk
• PSF – Umożliwienie efektywnej integracji komunikacji użytkowników ze strumieniami wartości
  • Jakość informacji otrzymywanych za pośrednictwem kanałów service desk mierzona względem wymagań strumieni wartości usług (jak dobre są informacje rejestrowane przez service desk na temat incydentów, zgłoszeń i innych zapytań)
  • Zadowolenie kluczowych interesariuszy korzystających z informacji poinformowanych za pośrednictwem kanałów service desk
  • Liczba i odsetek nieprawidłowej selekcji zapytań użytkowników (zapytania wysłane do niewłaściwego strumienia wartości usługi/praktyki/strumienia)

Przedstawiłem najważniejsze koncepcje związane z praktyką service desk. 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 Service Desk – część 1 pochodzi z serwisu Mariusz Siek.

Proces zarządzania incydentami (Incident Management) jest najczęściej wdrażanym i wykorzystywanym procesem ITIL. Ma na to wpływ wiele czynniki ale najważniejszym jest fakt, że w każdej organizacji występują jakieś zdarzenia w działaniu usług IT, które wymagają pomocy ze strony zespołów wsparcia. Nie oznacza to, że jest to najłatwiejszy proces. Wręcz przeciwnie według mnie to jeden z bardziej złożonych i jednocześnie ważnych procesów. Jego wdrożenie wymaga dobrego przygotowania i przemyślenia jak proces powinien funkcjonować w naszej organizacji. Zobaczmy, na jakie aspekty należy zwrócić uwagę.

Narzędzie ITSM

Zaczynam od narzędzia aby obalić mit, że do obsługi incydentów wystarczy wdrożyć narzędzie klasy ITSM i już wszystko będzie działać jak w szwajcarskim zegarku. Sam ITIL podpowiada, że „głupiec z narzędziem, jest nadal głupcem”. Zobacz mój artykuł „Czy narzędzia pomogą Ci w utrzymaniu usług IT?”. Nie oczekujmy, że jak wdrożmy narzędzie to, rozwiąże ono wszystkie nasze problemy. Tak się nie stanie. Narzędzie może pomóc w zarządzaniu incydentami ale wcześniej trzeba je odpowiednio skonfigurować i dopasować do naszych realiów. Narzędzie upraszcza pewne czynności ale nie gwarantuje, że incydenty będą rozwiązywane w SLA. Za to odpowiadają pracownicy, którzy są tylko ludźmi.

Wybór narzędzi ITSM, które wspierają procesy ITIL, w tym zarządzanie incydentami jest wiele. Wybór trzeba poprzedzić analizą, która pomoże nam porównać ich możliwości z naszymi wymaganiami.

SLA

Wymagania na poziom usług, bardzo często zawierają dwa parametry: czas reakcji i czas rozwiązania. Oba one związane są z obsługą incydentów. Po pierwsze musimy je dobrze mierzyć, ustalając z biznesem ich czas rozpoczęcia i zakończenia. Częstym błędem jest pomijanie tej kwestii i liczenie czasów reakcji i rozwiązania według uznania IT, bez weryfikacji z biznesem. Rodzi to dużo sytuacji stresowych na styku IT-biznes i nie pomaga w budowaniu dobrych relacji. Opisałem to zagadnie w artykule „Jak mierzyć parametry SLA cz1”.

Musimy również pamiętać aby monitorować stopień wykorzystania czasu reakcji i rozwiązania. Tutaj pomaga nam narzędzie, które liczy upływający czas i wysyła komunikaty, zgodnie ze zdefiniowanymi regułami do osób obsługujących incydent jak i menedżerów zarządzających. Monitorowanie, pozwala podejmować działania, które zapobiegną przekroczeniu dopuszczalnych wartości czasów reakcji i naprawy. Komunikaty powinny być wysyłane, już po upłynięciu połowy czasu na obsługę.

Kategoryzacja i priorytetyzacja

Kolejnym bardzo ważnym elementem w procesie zarządzania incydentami, jest poprawne przypisanie kategorii do zgłoszonego incydentu. To jest odpowiedzialność pierwszej linii wsparcia czyli Service Desk (Help Desk). Dlaczego jest to takie ważne? Na podstawie kategorii, zgłoszenie przydzielane jest do właściwej grupy wsparcia. Jeżeli zrobimy to niepoprawnie, tracimy cenny czas rozwiązania, ponieważ incydent trafi do niewłaściwej osoby, która zwróci go ponownie do Service Desk. Może to być od 30 minut do kilku godzin, w zależności jak szybko zgłoszenie zostanie „odbite” do SD.

Równie istotne jest nadanie incydentowi właściwego priorytetu, z którym wiąże się długość czasu rozwiązania. Z jego wyborem związana jest pilność, czyli jak szybko powinien być rozwiązany oraz wpływ, czyli skutki jakie wywołuje incydent np. na ilu użytkowników oddziaływuje. Jeżeli wybierzemy za niski priorytet, może się okazać, że przy jego zmianie, upłynął już cały czas rozwiązania i mamy przekroczenie wartości dopuszczalnej czasu rozwiązania.

Eskalacja funkcjonalna i hierarchiczna

Obie eskalacje są bardzo ważne. Nie wyobrażam sobie funkcjonowania procesu zarządzania incydentami bez tych mechanizmów. Ponieważ o tym zagadnieniu napisałem oddzielny artykuł zapraszam do zapoznania się z nim „Eskalacja funkcjonalna a hierarchiczna – czy ich używasz?”.

Incydent manager

Incydent manager, to kluczowa rola dla efektywnie i sprawnie funkcjonującego procesu zarządzania incydentami. Jeżeli ktoś tego nie rozumie, niech nie oczekuje, że proces będzie działał sam. Osoba ta lub w dużych organizacjach wiele osób, pilnuje przede wszystkim aby incydenty były rozwiązywane zgodnie z SLA. Jest to szczególnie ważne, gdy dostawca zewnętrzny, musi płacić kary umowne, za nie dotrzymanie czasów reakcji lub czasu rozwiązania. To jednak nie jedyna jego rola. Incydent manager koordynuje obsługę incydentów, rozstrzyga kwestie sporne, motywuje grupy wsparcia do działania, analizuje kategorie i ilość incydentów. To bardzo ważna rola, bez której proces zarządzania incydentami, nie może działać poprawnie.

Obsługa incydentów, to ciągła gonitwa i walka o dotrzymanie SLA. Warto jednak od czasu do czasu się zatrzymać i sprawdzić czy nasz proces działa poprawnie i jest optymalnie dopasowany do naszej organizacji. To będzie wymagało wysiłku i dodatkowej pracy ale opłaci się nam ona. To zadanie również dla incydent managera, pamiętaj aby mieć go zawsze na pokładzie.

Pytanie: Co możesz poprawić w swoim procesie zarządzania incydentami?

Artykuł Czy dobrze zarządzasz incydentami? pochodzi z serwisu Mariusz Siek.

Proces zarządzania incydentami, to jeden z najczęściej wykorzystywanych procesów ITSM z biblioteki dobrych praktyk ITIL. Dużo organizacji ma tak naprawdę tylko wdrożony ten jeden proces. Chociaż ja zalecam rozpoczęcie przygody z ITIL od katalogu usług (patrz artykuł Katalog usług – dlaczego jeszcze go nie masz?), posiadania dobrze funkcjonującego procesu zarządzania incydentami, też jest ważne i ostatecznie może być uruchamiane w pierwszej kolejności. W szczególności, że proces zarządzania incydentami odpowiada za bardzo ważne parametry SLA. Czy jednak na pewno dobrze funkcjonuje w Twojej organizacji? Jak wykorzystujesz eskalację funkcjonalną i hierarchiczną, najważniejsze elementy tego procesu?

Eskalacja funkcjonalna

Bardzo często korzystamy z eskalacji funkcjonalnej, nie do końca mając tego świadomość. Eskalacja funkcjonalna określa, jak należy się zachować podczas rozwiązywania incydentu, jeżeli I lub II linia wsparcia nie potrafi go rozwiązać. Jakie jednak powinny być kryteria przekazania zgłoszenia do kolejnej linii wsparcia? Należy określić dwa wyzwalacze:

• Pierwszy musi być związany z kompetencjami.
  • Jeżeli I linia wsparcia (Service Desk), nie umie rozwiązać zgłoszenia (incydentu), przekazuje zgłoszenie do II lub III linii wsparcia. Od Service Desk zależy, czy posiada odpowiednią wiedzę i doświadczenie czy zgłoszenie można przekazać od razu do III linii wsparcia z pominięciem II.
  • Jeżeli II linia wsparcia (zespołu utrzymania) nie umie rozwiązać zgłoszenia (incydentu), przekazuje zgłoszenie do III linii wsparcia (zespoły wytwórcze lub infrastruktury)
• Drugi musi być związany z czasem.
  • Jeżeli I linia wsparcia, nie znajdzie rozwiązania incydentu w ustalonym czasie, zgłoszenie przekazywane jest do II linii wsparcia
  • Jeżeli II linia wsparcia, nie znajdzie rozwiązania incydentu w ustalonym czasie, zgłoszenie przekazywane jest do III linii wsparcia

Należy zwrócić szczególną uwagę, aby dobrze zdefiniować czas na znalezienie rozwiązania dla I i II linii wsparcia.

• Nie może to być za mało, bo wtedy większość incydentów będzie trafiać do II linii wsparcia a w konsekwencji również do III. Spowoduje to „zatkanie” się tych zespołów w obsłudze incydentów i nie dotrzymanie SLA związanego z czasem rozwiązania.
• Nie może to być za dużo, aby czas poświęcony na obsługę incydenty przez Ii lub II linię wsparcia, nie zmniejszał czasu na rozwiązane, odpowiednio przez II i III linię wsparcia.

Poruszałem to zagadnienie w artykule OLA – czy ktoś ją kiedyś widział?, gdzie podałem przykładowy podział czasu rozwiązania pomiędzy I, II i III linię wsparcia. Zachęcam do zapoznania się.

Eskalacja hierarchiczna

Równie ważna co eskalacja funkcjonalna, jednak znaczniej rzadziej wykorzystywana jest eskalacja hierarchiczna. Określa ona jakie działania należy podjąć, jeżeli mamy do czynienie z poważnym incydentem (zagadnieniem) lub czynności związane z badaniem i diagnozą oraz rozwiązaniem i przywróceniem trwają za długo. Nazywana jest również eskalacją zarządczą, ponieważ dotyczy kadry zarządzającej wszystkich szczebli od menedżerów zespołów, przez menedżerów procesów iTSM a na dyrektorze ds. IT i członkach zarządu kończąc.

Eskalacja hierarchiczna dotyczy dwóch aspektów:

• Informacyjnego – menadżerowie muszą być poinformowani o możliwych problemach z rozwiązaniem incydentu aby byli świadomi tego faktu.
• Decyzyjnego – w przypadku zagrożenia nie dotrzymania czasu rozwiązania, wymagane jest podejmowanie decyzji, które pozwolą nie przekroczyć czasu rozwiązania lub zminimalizować jego niedotrzymanie.

Zasady stosowania eskalacji hierarchicznej muszą być opisane w procedurze eskalacji, która będzie odpowiednio wdrożona w organizacji. Niestety taka procedura rzadko występuje, dlatego zwrócić szczególną uwagę na jej przygotowanie. Może nie będzie potrzebna codziennie ale jak już będzie to zaoszczędzi dużo czasu i zamieszania w procesie decyzyjnym.

Eskalacja funkcjonalna vs hierarchiczna

Tak naprawdę eskalacja hierarchiczna jest uzupełnieniem eskalacji funkcjonalnej. Jeżeli III linia wsparcia nie umie rozwiązać incydentu, wtedy w ramach procedury eskalacyjnej, kierownictwo organizacji podejmuje decyzję czy zwiększyć zasoby wewnętrzne potrzebne do rozwiązania czy może należy sięgnąć po zewnętrznych specjalistów. Jak widać obie eskalacje się uzupełniają i pominięcie którejś w procesie zarządzania incydentami, wpływa na jakość funkcjonowania procesu.

Mam nadzieję, że przybliżyłem Wam te dwa zagadnienia i już teraz nikt nie będzie miał wątpliwości do czego służą, i że są bardzo potrzebne.

Pytanie: Jak wykorzystujesz eskalację funkcjonalną i hierarchiczną w swojej organizacji?

Artykuł Eskalacja funkcjonalna a hierarchiczna – czy ich używasz? pochodzi z serwisu Mariusz Siek.