Szablon danych do zarządzania incydentami

Uniwersalny szablon process mining
Szablon danych do zarządzania incydentami

Szablon danych do zarządzania incydentami

Uniwersalny szablon process mining

To ogólny szablon danych do process mining dla procesu Zarządzanie incydentami. Aby uzyskać dokładniejsze wskazówki, skorzystaj z szablonów dla konkretnych systemów.

Wybierz konkretny system
  • Uniwersalna struktura danych dla każdego systemu zarządzania incydentami
  • Zalecane atrybuty i działania do szczegółowej analizy
  • Wskazówki dotyczące ekstrakcji danych, w tym przykłady dla konkretnych systemów
Pierwszy raz spotykają się Państwo z dziennikiem zdarzeń? Dowiedz się jak utworzyć dziennik zdarzeń na potrzeby process mining.

Atrybuty zarządzania incydentami

W tej sekcji opisano zalecane pola danych i właściwości spraw, które są potrzebne do utworzenia dziennika zdarzeń i szczegółowej analizy procesu zarządzania incydentami.
5 Wymagane 8 Zalecane 4 Opcjonalne
Nazwa Opis
Identyfikator incydentu
IncidentId
Unikalny identyfikator przypisany do każdego incydentu. Służy jako klucz główny, który pozwala śledzić incydent przez cały cykl jego życia.
Opis

Identyfikator incydentu to unikalny kod alfanumeryczny, który odróżnia dany incydent od pozostałych w systemie. Jest nadawany podczas tworzenia incydentu i pozostaje niezmienny aż do jego trwałego zarchiwizowania lub usunięcia.

W process mining identyfikator incydentu pełni funkcję identyfikatora sprawy (Case ID) i stanowi podstawę analizy. Pozwala połączyć powiązane zdarzenia, zmiany statusu i czynności w jedną instancję procesu. Grupując wszystkie zdarzenia pod wspólnym identyfikatorem, analitycy mogą dokładnie odwzorować przebieg każdego incydentu, od pierwszego zgłoszenia po rozwiązanie i zamknięcie.

Dlaczego to ważne

Identyfikator pozwala połączyć powiązane czynności i zdarzenia, aby odtworzyć pełny cykl życia incydentu na potrzeby process mining.

Skąd pobrać

To klucz główny incydentu. Zwykle znajduje się w nagłówku lub głównym rekordzie każdej tabeli albo obiektu incydentu.

Przykłady
INC0010032TICKET-84321789456123
Nazwa czynności
ActivityName
Nazwa konkretnej czynności biznesowej, zdarzenia lub zmiany statusu, które wystąpiły w cyklu życia incydentu.
Opis

Nazwa czynności opisuje odrębny krok lub zadanie wykonane w ramach procesu obsługi incydentu. Czynności te tworzą mapę procesu i mogą obejmować zarówno automatyczne zdarzenia systemowe, takie jak „Wykryto naruszenie SLA”, jak i ręczne działania użytkownika, na przykład „Przypisano agenta” lub „Przekazano obejście problemu”.

Ten atrybut ma podstawowe znaczenie w analizie process mining. Określa węzły na grafie procesu, dzięki czemu analitycy mogą zobaczyć przebieg pracy, znaleźć typowe ścieżki, wykryć wąskie gardła i analizować odstępstwa od standardowej procedury. Szczegółowość i czytelność nazw czynności bezpośrednio wpływają na jakość i zakres uzyskiwanych wniosków.

Dlaczego to ważne

Ten atrybut określa kroki procesu i umożliwia wizualizację oraz analizę przebiegu obsługi incydentu.

Skąd pobrać

Nazwę często ustala się na podstawie dzienników zdarzeń, ścieżek audytu, zapisów zmian statusu lub pól z opisem zadań w systemie do zarządzania incydentami.

Przykłady
Utworzono incydentPrzypisano grupęIncydent rozwiązanyZmieniono status na oczekujący
Znacznik czasu zdarzenia
EventTimestamp
Dokładna data i godzina wystąpienia danej czynności lub zdarzenia dotyczącego incydentu.
Opis

Znacznik czasu zdarzenia wskazuje dokładny moment wykonania czynności. Każda czynność w cyklu życia incydentu powinna mieć przypisany znacznik czasu, który pozwala ustalić kolejność zdarzeń.

Ten atrybut jest niezbędny w analizie process mining opartej na czasie. Umożliwia obliczanie czasu między czynnościami, czasu trwania poszczególnych kroków oraz całkowitego czasu rozwiązania incydentu. Analiza znaczników czasu pomaga wykrywać wąskie gardła, mierzyć dotrzymywanie SLA i sprawdzać, jak zmienia się wydajność procesu. To podstawa obliczania wskaźników KPI, takich jak średni czas rozwiązania.

Dlaczego to ważne

Pozwala ustalić chronologiczną kolejność zdarzeń, niezbędną do obliczania czasu trwania, wykrywania wąskich gardeł i analizy zmian wydajności procesu.

Skąd pobrać

Dane można znaleźć w dziennikach zdarzeń, tabelach historii audytu lub w polach takich jak „data ostatniej modyfikacji” czy „data utworzenia” powiązanych rekordów.

Przykłady
2023-10-26T10:00:00Z2024-01-15T14:35:10Z2023-11-01T09:12:45Z
Data ostatniej aktualizacji danych
LastDataUpdate
Znacznik czasu wskazujący, kiedy dane tego rekordu zostały ostatnio odświeżone z systemu źródłowego.
Opis

Znacznik czasu ostatniej aktualizacji danych wskazuje, kiedy dane zostały ostatnio pobrane lub zsynchronizowane z systemu źródłowego. To pole metadanych informuje o aktualności analizowanych danych.

W analizie process mining ten atrybut pozwala ocenić, jak aktualne są uzyskane wnioski. Użytkownicy mogą sprawdzić, czy analizują dane bieżące, czy migawkę z wcześniejszego momentu. Ma to znaczenie przy monitorowaniu operacji i podejmowaniu decyzji na podstawie aktualnych, istotnych danych.

Dlaczego to ważne

Informuje o aktualności danych, dzięki czemu analitycy wiedzą, na ile bieżąca jest analiza procesu.

Skąd pobrać

Wartość jest zwykle generowana i zapisywana w każdym rekordzie podczas pobierania i przekształcania danych (ETL).

Przykłady
2023-10-26T23:59:59Z2024-01-16T04:00:10Z2023-11-02T01:05:00Z
System źródłowy
SourceSystem
Nazwa lub identyfikator systemu, z którego pobrano dane o incydencie.
Opis

Atrybut „System źródłowy” wskazuje pochodzenie danych. W środowiskach korzystających z kilku narzędzi ITSM lub zintegrowanych systemów pozwala odróżnić rekordy z poszczególnych źródeł.

Atrybut ten nie służy bezpośrednio do tworzenia mapy procesu, ale pomaga weryfikować dane i zarządzać nimi. Analitycy mogą prześledzić pochodzenie danych, wyjaśnić rozbieżności między systemami i podzielić analizę na segmenty. Można na przykład porównać procesy obsługi incydentów w ServiceNow i Jira używanych w tej samej organizacji.

Dlaczego to ważne

Informacja o pochodzeniu danych pomaga je weryfikować, rozwiązywać problemy i porównywać dane w środowiskach korzystających z wielu systemów.

Skąd pobrać

Często jest to stała wartość dodawana podczas pobierania danych albo pole dostępne w tabelach systemu źródłowego.

Przykłady
ServiceNowJira Service ManagementBMC HelixZendesk
Kanał zgłoszenia
ReportingChannel
Metoda lub kanał, za pośrednictwem którego zgłoszono incydent, na przykład e-mail, telefon lub portal samoobsługowy.
Opis

Kanał zgłoszenia wskazuje, skąd wpłynęło zgłoszenie incydentu. Atrybut ten pokazuje, w jaki sposób użytkownicy kontaktują się z zespołem wsparcia: bezpośrednio, na przykład telefonicznie, czy automatycznie, na przykład przez alerty monitoringu systemu.

Analiza procesu według kanału zgłoszenia może ujawnić istotne różnice w sprawności obsługi. Incydenty zgłoszone przez portal samoobsługowy mogą być rozwiązywane szybciej, ponieważ często od początku zawierają bardziej uporządkowane informacje. Taka analiza pomaga optymalizować kanały wsparcia i zachęcać do korzystania z efektywniejszych metod.

Dlaczego to ważne

Pozwala analizować sprawność obsługi i ścieżki rozwiązywania incydentów według źródła zgłoszenia, co pomaga planować kanały kontaktu i przydzielać zasoby.

Skąd pobrać

Informacja ta jest zwykle rejestrowana automatycznie lub wybierana przez agenta podczas tworzenia incydentu.

Przykłady
E-mailTelefonPortal samoobsługowyAlert systemowy
Kategoria incydentu
IncidentCategory
Klasyfikacja incydentu, często uporządkowana hierarchicznie, na przykład: sprzęt > laptop > bateria.
Opis

Kategoria incydentu pozwala uporządkować zgłoszenia według rodzaju problemu. Zwykle ma strukturę hierarchiczną, która umożliwia stopniowe uszczegóławianie klasyfikacji i grupowanie incydentów na potrzeby raportowania oraz analizy.

Kategoryzacja jest ważna przy analizie przyczyn źródłowych i trendów. Analiza map procesów z podziałem na kategorie pomaga wykrywać powtarzające się problemy i wzorce związane z określonymi rodzajami incydentów. Na przykład proces rozwiązywania incydentu związanego z oprogramowaniem może wyglądać zupełnie inaczej niż w przypadku problemu ze sprzętem. Dane te służą do obliczania wskaźników KPI, takich jak dokładność wstępnej kategoryzacji i odsetek powracających incydentów.

Dlaczego to ważne

Jest niezbędna do analizy przyczyn źródłowych, wykrywania trendów w powracających incydentach i sprawdzania, jak obsługiwane są różne rodzaje problemów.

Skąd pobrać

To standardowy, często obowiązkowy zestaw pól w rekordzie incydentu, używany do klasyfikacji.

Przykłady
Oprogramowanie | Aplikacja | Problem z logowaniemSprzęt | Drukarka | Brak odpowiedziSieć | Wi-Fi | Wolne połączenie
Metoda rozwiązania
ResolutionMethod
Kod, kategoria lub opis wskazujący, w jaki sposób ostatecznie rozwiązano incydent.
Opis

Metoda rozwiązania opisuje wynik obsługi incydentu i sposób jego rozwiązania. Może to być standardowy kod lub opis podjętych działań w formie tekstu. Przykłady: „Instruktaż dla użytkownika”, „Zainstalowano poprawkę oprogramowania”, „Nie wykryto usterki” lub „Duplikat incydentu”.

Atrybut ten dostarcza ważnych informacji o końcowym etapie procesu. W process mining analiza incydentów według metody rozwiązania pomaga ocenić skuteczność różnych sposobów postępowania. Może wskazać zgłoszenia zamknięte bez rzeczywistej naprawy lub typowe metody rozwiązywania określonych kategorii incydentów. Na tej podstawie można rozwijać bazę wiedzy i zwiększać odsetek spraw rozwiązanych przy pierwszym kontakcie.

Dlaczego to ważne

Pokazuje, jak rozwiązywane są problemy, i pomaga znaleźć możliwości automatyzacji, rozbudowy bazy wiedzy oraz szkoleń.

Skąd pobrać

Zwykle pole wypełniane przez agenta wsparcia przy zmianie statusu incydentu na „Rozwiązany” lub „Zamknięty”.

Przykłady
Rozwiązany przez Service DeskNie wykryto usterkiDuplikatWdrożono aktualizację oprogramowania
Priorytet
Priority
Poziom priorytetu incydentu, który określa pilność i kolejność jego rozwiązania.
Opis

Priorytet określa względne znaczenie incydentu i wymagany czas reakcji. Często wynika z połączenia wpływu incydentu i jego pilności. Poziomy zwykle obejmują zakres od krytycznego do niskiego.

W process mining analiza incydentów według priorytetu pokazuje, jak proces obsługuje zgłoszenia o różnym stopniu pilności. Analitycy mogą porównać czas rozwiązania incydentów o wysokim i niskim priorytecie, aby sprawdzić, czy dotrzymywane są SLA i czy zasoby są właściwie przydzielane. Można też odpowiedzieć na pytanie: czy najpoważniejsze incydenty są rzeczywiście obsługiwane najszybciej?

Dlaczego to ważne

Umożliwia analizę wydajności procesu przy różnych poziomach pilności i sprawdzenie, czy incydenty krytyczne są obsługiwane szybciej niż pozostałe.

Skąd pobrać

Dostępny jako standardowe pole w głównym rekordzie incydentu. Można go ustawić ręcznie lub obliczyć automatycznie na podstawie wpływu i pilności.

Przykłady
1 - Krytyczny2 - Wysoki3 - Średni4 - Niski
Przypisana grupa
AssignedGroup
Zespół wsparcia, kolejka lub grupa, która obecnie odpowiada za obsługę incydentu.
Opis

Przypisana grupa wskazuje, który zespół odpowiada za incydent w danym momencie. Zgłoszenia często trafiają kolejno do różnych grup, na przykład do Service Desk pierwszej linii, zespołu sieciowego drugiej linii lub zespołu wsparcia aplikacji trzeciej linii.

Ten atrybut jest niezbędny do analizy przekazywania spraw i obciążenia pracą. Process mining pozwala zobrazować przepływ incydentów między zespołami, zmierzyć czas oczekiwania w kolejce każdego zespołu i wykryć wąskie gardła wynikające z częstych zmian przypisania. Ułatwia analizę wydajności i współpracy zespołów. Stanowi też podstawę dashboardu „Analiza przekazywania i ponownego przypisywania”.

Dlaczego to ważne

Pozwala analizować przekazywanie spraw między zespołami, mierzyć czas oczekiwania w kolejkach oraz oceniać wydajność i obciążenie poszczególnych zespołów.

Skąd pobrać

Informacja ta jest zwykle zapisana w rekordzie incydentu i aktualizowana za każdym razem, gdy incydent zostaje przypisany do nowego zespołu.

Przykłady
Service DeskOperacje siecioweAdministracja bazami danychWsparcie aplikacji, poziom 2
Przypisany agent
AssignedAgent
Agent wsparcia lub użytkownik przypisany do obsługi incydentu.
Opis

Przypisany agent to konkretna osoba odpowiedzialna za incydent. Przypisana grupa wskazuje zespół, a agent jest osobą, która pracuje nad rozwiązaniem.

Ten atrybut umożliwia szczegółową analizę wydajności i obciążenia pracą. Śledzenie przypisań na poziomie agentów pomaga kierownikom oceniać produktywność, określać potrzeby szkoleniowe i równomiernie rozdzielać zadania. W process mining może ujawnić złożone wzorce ponownego przypisywania, które nie są widoczne na poziomie grupy, oraz pokazać, jak praca poszczególnych osób wpływa na czas rozwiązania.

Dlaczego to ważne

Umożliwia szczegółową analizę obciążenia pracą, wydajności i zmian przypisania poszczególnych osób w zespołach i między nimi.

Skąd pobrać

Pole w głównym rekordzie incydentu. Jest aktualizowane, gdy agent przejmuje odpowiedzialność za incydent lub zostaje do niego przypisany.

Przykłady
Jan KowalskiAnna Nowakagent.12345Emilia Jones
Status incydentu
IncidentStatus
Bieżący lub historyczny stan incydentu w cyklu jego życia, na przykład „Nowy”, „W toku” lub „Zamknięty”.
Opis

Status incydentu wskazuje etap, na którym znajduje się incydent w danym momencie. Pokazuje ogólnie, na jakim etapie rozwiązywania jest zgłoszenie. Typowe statusy to: nowy, przypisany, w trakcie obsługi, oczekujący, rozwiązany i zamknięty.

Ten atrybut ma podstawowe znaczenie w analizie procesu, ponieważ zmiany statusu często wyznaczają czynności na mapie procesu. Analiza czasu spędzonego w poszczególnych statusach pomaga wykrywać wąskie gardła, na przykład incydenty długo oczekujące. Status służy też do obliczania liczby otwartych incydentów i śledzenia postępów w ich rozwiązywaniu.

Dlaczego to ważne

Pozwala śledzić postęp obsługi incydentu i często służy do wyznaczania czynności na mapie procesu. Analiza czasu spędzonego w każdym statusie pomaga wykrywać opóźnienia.

Skąd pobrać

Zwykle jest dostępny jako podstawowe pole w głównym rekordzie incydentu lub w jego historii.

Przykłady
NowyW tokuOczekiwanie na klientaRozwiązanyZamknięty
Waga incydentu
Severity
Miara wpływu incydentu na działalność, wskazująca, jak mocno oddziałuje on na użytkowników lub usługi.
Opis

Waga incydentu określa jego wpływ na działalność. Odpowiada na pytanie, jak poważny jest problem, niezależnie od jego pilności. Na przykład awaria całego systemu ma wysoką wagę, a drobny błąd wizualny niską.

Analiza incydentów według wagi pomaga ustalić, które problemy powodują największe zakłócenia. Process mining może pokazać, czy incydenty o wysokiej wadze są rozwiązywane inną, sprawniejszą ścieżką. Atrybut ten wspiera analizę przyczyn źródłowych i przydzielanie zasobów do proaktywnego zarządzania problemami, aby zapobiegać nawrotom najpoważniejszych incydentów.

Dlaczego to ważne

Pozwala podzielić incydenty na grupy i sprawdzić, czy problemy o dużym wpływie są rozwiązywane inaczej lub sprawniej niż te o mniejszym wpływie.

Skąd pobrać

Standardowe pole w rekordzie incydentu, często używane razem z pilnością do ustalania priorytetu.

Przykłady
1 - Wysoki2 - Średni3 - NiskiKrytyczny
Dotknięta usługa
AffectedService
Usługa biznesowa, aplikacja lub element konfiguracji (CI), którego dotyczy incydent.
Opis

Atrybut „Dotknięta usługa” łączy incydent z konkretnym elementem infrastruktury IT, takim jak aplikacja biznesowa, serwer lub urządzenie sieciowe. Często jest powiązany z bazą zarządzania konfiguracją (CMDB).

Atrybut ten dostarcza ważnych informacji o wpływie incydentu na działalność. W process mining umożliwia analizę niezawodności konkretnych usług lub zasobów. Organizacje mogą sprawdzić, które usługi generują najwięcej incydentów, przeanalizować sposób ich rozwiązywania i ustalić priorytety zarządzania problemami, aby zwiększyć stabilność usług istotnych dla działalności. Pomaga też ocenić szerszy wpływ incydentów IT na firmę.

Dlaczego to ważne

Łączy incydenty z konkretnymi usługami biznesowymi lub elementami IT, dzięki czemu można sprawdzić, które usługi są najbardziej podatne na problemy i jaki jest ich wpływ.

Skąd pobrać

Zwykle jest powiązany z bazą zarządzania konfiguracją (CMDB) lub wybierany z katalogu usług w formularzu incydentu.

Przykłady
Usługi poczty elektronicznejFinanse SAP ERPFirmowa sieć VPNSRV-SQL-01
Liczba ponownych przypisań
ReassignmentCount
Łączna liczba przypadków przypisania incydentu do innego agenta lub grupy.
Opis

Liczba ponownych przypisań pokazuje, ile razy incydent przekazano dalej w trakcie jego obsługi. Wysoka wartość często wskazuje na nieefektywność, błędne przypisanie na początku lub braki w wiedzy zespołów wsparcia.

To przydatny atrybut w analizie process mining. Process mining pozwala zobrazować zmiany przypisania, a wcześniej obliczona liczba ułatwia filtrowanie danych i pomiar wskaźników KPI. Wartość jest wykorzystywana bezpośrednio w dashboardzie „Analiza przekazywania i ponownego przypisywania”. Pomaga wykrywać sytuacje, w których zgłoszenia krążą między zespołami, co wydłuża czas rozwiązania i frustruje użytkowników.

Dlaczego to ważne

Wskaźnik ten bezpośrednio mierzy nieefektywność procesu. Wysoka liczba ponownych przypisań często wiąże się z dłuższym czasem rozwiązania i może wskazywać na problemy z kierowaniem zgłoszeń lub kompetencjami zespołów.

Skąd pobrać

Często jest dostępny jako standardowe pole licznika w rekordzie incydentu. Jeśli go brakuje, można go obliczyć, zliczając zmiany przypisania w dzienniku audytu incydentu.

Przykłady
0135
Status SLA
SlaStatus
Informuje, czy incydent mieści się w limitach SLA, jest zagrożony przekroczeniem czy już je przekroczył.
Opis

Status SLA pokazuje, jak incydent wypada na tle ustalonych limitów czasowych, takich jak czas reakcji lub rozwiązania. Typowe statusy to „W trakcie”, „Zagrożony przekroczeniem” i „Przekroczony”.

Ten atrybut bezpośrednio mierzy jakość obsługi i stanowi ważną miarę w dashboardzie z przeglądem realizacji SLA. W process mining można porównać przebieg obsługi incydentów, w których przekroczono SLA, z tymi, w których dotrzymano limitów. Pozwala to wskazać konkretne działania, opóźnienia i pętle poprawek, które najczęściej prowadzą do naruszeń SLA, a następnie zaplanować ukierunkowane usprawnienia procesu.

Dlaczego to ważne

To bezpośrednia miara realizacji założonych celów. Analiza incydentów z przekroczonym SLA pomaga wskazać problemy w procesie, które obniżają jakość obsługi.

Skąd pobrać

Zazwyczaj jest to pole obliczane w narzędziu ITSM i aktualizowane dynamicznie na podstawie priorytetu i wieku incydentu oraz zdefiniowanych reguł SLA.

Przykłady
W tokuWstrzymanyPrzekroczonyZagrożony przekroczeniem
Zgłaszający
Requester
Użytkownik, pracownik lub system, który jako pierwszy zgłosił incydent.
Opis

Zgłaszający to osoba, która napotkała problem i zainicjowała zgłoszenie incydentu. Może to być pracownik firmy lub klient zewnętrzny. Atrybut może też zawierać informacje o dziale lub organizacji zgłaszającego.

Analiza incydentów według zgłaszającego lub jego działu pomaga ustalić, czy określone grupy użytkowników napotykają więcej problemów niż inne. Może to wskazywać na potrzebę szkoleń lub lokalne problemy ze środowiskiem pracy. W process mining umożliwia analizę procesu wsparcia z perspektywy użytkownika i porównanie doświadczeń różnych grup.

Dlaczego to ważne

Umożliwia analizę z perspektywy użytkownika i pomaga sprawdzić, czy określone osoby, działy lub lokalizacje nie zgłaszają nieproporcjonalnie dużej liczby incydentów.

Skąd pobrać

Standardowe pole w rekordzie incydentu, zwykle wypełniane danymi użytkownika, który utworzył zgłoszenie lub w którego imieniu je utworzono.

Przykłady
Alicja JohnsonDział sprzedażyb.williamsCustomer-XYZ Corp
Wymagane Zalecane Opcjonalne

Działania w procesie zarządzania incydentami

Tabela przedstawia najważniejsze kroki procesu i etapy, które warto śledzić, aby prawidłowo odkryć proces i zrozumieć przebieg rozwiązywania incydentów.
7 Zalecane 7 Opcjonalne
Działanie Opis
Incydent ponownie otwarty
Do tego zdarzenia dochodzi, gdy wcześniej rozwiązany incydent wraca do aktywnego statusu. Zwykle użytkownik zgłasza wtedy, że problem powrócił albo zaproponowane rozwiązanie nie zadziałało.
Dlaczego to ważne

Wysoki odsetek ponownie otwieranych incydentów może wskazywać na niską jakość rozwiązań, niepełną analizę przyczyn źródłowych lub przedwczesne zamykanie zgłoszeń. To ważny wskaźnik przy analizie ponownej pracy.

Skąd pobrać

Zdarzenie można wywnioskować z historii statusów, gdy status incydentu zmienia się z „Rozwiązany” lub „Zamknięty” na aktywny, na przykład „W toku”.

Rejestrowanie

Wykryj zmianę statusu z rozwiązanego na otwarty i zapisz znacznik czasu tej zmiany.

Typ zdarzenia inferred
Incydent rozwiązany
Ta czynność oznacza, że wdrożono rozwiązanie i zakłada się, że usługa została przywrócona użytkownikowi. To ważny etap, który zwykle zatrzymuje zegar SLA dotyczący rozwiązania incydentu.
Dlaczego to ważne

To ważny punkt końcowy przy pomiarze czasu rozwiązania incydentu. Okres między tym etapem a ostatecznym zamknięciem pozwala analizować opóźnienia w potwierdzeniu przez użytkownika oraz zasady automatycznego zamykania.

Skąd pobrać

Zwykle jest to jawne zdarzenie rejestrowane, gdy agent zmienia status incydentu na „Rozwiązany” lub „Naprawiony”.

Rejestrowanie

Użyj znacznika czasu z dziennika audytu, zarejestrowanego przy zmianie statusu incydentu na „Rozwiązany”.

Typ zdarzenia explicit
Incydent zamknięty
Ostatnia czynność w cyklu życia incydentu. Rekord zostaje formalnie zamknięty i staje się historyczny, tylko do odczytu. Często następuje to automatycznie po upływie określonego czasu w statusie „Rozwiązany”.
Dlaczego to ważne

To oznacza koniec cyklu życia incydentu. Analiza całego okresu od utworzenia do zamknięcia pokazuje pełny czas trwania procesu, łącznie z czynnościami administracyjnymi po rozwiązaniu.

Skąd pobrać

Zdarzenie jest rejestrowane przy jawnej zmianie statusu incydentu na „Zamknięty” w historii. Zapis zawiera końcowy znacznik czasu.

Rejestrowanie

Użyj znacznika czasu z dziennika audytu, zarejestrowanego przy zmianie statusu incydentu na „Zamknięty”.

Typ zdarzenia explicit
Przypisano grupę
Oznacza pierwsze przypisanie incydentu do konkretnej grupy wsparcia lub zespołu, który ma go zbadać. To pierwsze formalne przekazanie sprawy i początek workflow rozwiązywania problemu.
Dlaczego to ważne

To ważny etap kierowania zgłoszenia. Opóźnienie w przypisaniu lub skierowanie do niewłaściwego zespołu może znacznie wydłużyć czas rozwiązania i spowodować niepotrzebne przekazania między zespołami.

Skąd pobrać

Zdarzenie ustala się na podstawie dziennika audytu, wyszukując pierwsze uzupełnienie pola „Assignment Group” lub „Support Team”.

Rejestrowanie

Ustal znacznik czasu pierwszego uzupełnienia pola „Assignment Group” w historii incydentu.

Typ zdarzenia inferred
Rozpoczęto analizę
Oznacza, że przypisany agent rozpoczął pracę nad incydentem. Zwykle odpowiada zmianie statusu z „Assigned” lub „New” na „In Progress”.
Dlaczego to ważne

Ten etap kończy początkowy czas oczekiwania w kolejce i rozpoczyna aktywną pracę. Pomiar czasu do tego zdarzenia pomaga ocenić dostępność agentów i opóźnienia w reakcji.

Skąd pobrać

Zdarzenie to zwykle ustala się na podstawie zmiany statusu w historii incydentu.

Rejestrowanie

Ustal znacznik czasu pierwszej zmiany statusu incydentu na „In Progress”, „Work in Progress” lub podobny status oznaczający aktywną pracę.

Typ zdarzenia inferred
Utworzono incydent
Ta czynność oznacza formalne utworzenie rekordu incydentu w systemie. Rozpoczyna jego obsługę i zapisuje początkowe zgłoszenie użytkownika lub narzędzia monitorującego.
Dlaczego to ważne

To główne zdarzenie rozpoczynające proces. Analiza czasu od utworzenia zgłoszenia do kolejnych etapów pozwala mierzyć całkowity czas rozwiązania i wykrywać opóźnienia na początku procesu.

Skąd pobrać

Zdarzenie to zwykle ustala się na podstawie znacznika czasu utworzenia rekordu głównego incydentu lub zgłoszenia w systemie źródłowym.

Rejestrowanie

Użyj znacznika czasu „create_date” lub „submitted_on” z głównego rekordu incydentu.

Typ zdarzenia explicit
Wykryto naruszenie SLA
Zdarzenie obliczane, gdy czas reakcji na incydent lub jego rozwiązania przekracza limity określone w umowie SLA. Nie wynika z ręcznego działania użytkownika, lecz z upływu czasu.
Dlaczego to ważne

Naruszenia SLA to jeden z podstawowych wskaźników KPI. Analiza tego, kiedy i dlaczego do nich dochodzi, pomaga usprawnić świadczenie usług i wywiązywać się ze zobowiązań umownych.

Skąd pobrać

To zdarzenie nie występuje bezpośrednio w dziennikach. Jest wyliczane przez porównanie znaczników czasu zdarzeń z terminami SLA zapisanymi w rekordzie incydentu.

Rejestrowanie

Porównaj znacznik czasu rozwiązania incydentu z polem „Termin SLA”. Jeśli rozwiązanie nastąpiło później, utwórz zdarzenie naruszenia SLA ze znacznikiem czasu odpowiadającym terminowi SLA.

Typ zdarzenia calculated
Ponownie przypisano incydent
Oznacza przekazanie incydentu do innej grupy wsparcia lub innemu agentowi. Zwykle następuje, gdy początkowy zespół nie może rozwiązać problemu i potrzebna jest inna wiedza specjalistyczna.
Dlaczego to ważne

Częste ponowne przypisania wskazują na nieefektywność procesu, błędne skierowanie zgłoszenia na początku lub braki wiedzy w zespole. Analiza tych przekazań pomaga usprawnić przebieg rozwiązywania incydentów.

Skąd pobrać

Zdarzenie ustala się na podstawie dziennika audytu, wykrywając każdą zmianę pola „Assignment Group” lub „Assignee” po pierwszym przypisaniu.

Rejestrowanie

Utwórz nowe zdarzenie dla każdej zmiany pola „Assignment Group” po jego pierwszym uzupełnieniu.

Typ zdarzenia inferred
Przekazano obejście problemu
Oznacza przekazanie użytkownikowi tymczasowego rozwiązania, które przywraca działanie usługi. Ogranicza ono wpływ problemu na działalność firmy, gdy opracowywana jest trwała naprawa.
Dlaczego to ważne

Przekazanie obejścia problemu to ważny etap obsługi poważnych incydentów. Pozwala osobno mierzyć czas ograniczenia skutków problemu i czas wdrożenia trwałego rozwiązania.

Skąd pobrać

Może to być jawny status lub znacznik, ale często zdarzenie ustala się na podstawie notatek agentów lub dzienników komunikacji, wyszukując określone słowa kluczowe.

Rejestrowanie

Wykryj zdarzenie na podstawie konkretnego statusu, takiego jak „Workaround Provided”, albo wyszukując w komentarzach agentów słowa kluczowe, na przykład „workaround” lub „temporary fix”.

Typ zdarzenia inferred
Przypisano agenta
Ta czynność oznacza moment, w którym konkretny agent przejmuje incydent lub otrzymuje go do obsługi. Odpowiedzialność przechodzi wtedy z poziomu zespołu na konkretną osobę.
Dlaczego to ważne

Śledzenie przypisań do agentów pomaga analizować obciążenie i wyniki pracy oraz wykrywać wąskie gardła, w których zgłoszenia czekają na dostępnego agenta.

Skąd pobrać

Zdarzenie można wykryć, śledząc zmiany pola „Assignee” lub „Assigned To” w dzienniku audytu incydentu.

Rejestrowanie

Użyj znacznika czasu z dziennika audytu, gdy pole „Assignee” zostaje po raz pierwszy uzupełnione lub przypisane do innego użytkownika.

Typ zdarzenia explicit
Sklasyfikowano incydent
Oznacza sklasyfikowanie incydentu, w tym określenie jego kategorii, typu i elementu. To ważny etap wstępnej oceny, który pomaga skierować zgłoszenie do właściwego zespołu i zastosować odpowiednią procedurę rozwiązania.
Dlaczego to ważne

Błędna klasyfikacja może powodować opóźnienia, ponowne przypisania i zniekształcenie raportów. Analiza tej czynności pomaga ocenić jakość wstępnej oceny zgłoszeń i jej wpływ na sprawność rozwiązywania incydentów.

Skąd pobrać

Zdarzenie to zwykle ustala się na podstawie dziennika audytu lub tabeli historii, wyszukując pierwsze uzupełnienie pól związanych z klasyfikacją.

Rejestrowanie

Wykryj pierwszą aktualizację pól takich jak „Category”, „Subcategory” lub „Configuration Item” po utworzeniu incydentu.

Typ zdarzenia inferred
Ustalono priorytet incydentu
Ta czynność następuje po ustaleniu priorytetu incydentu, zwykle na podstawie jego wpływu i pilności. Priorytet określa docelowy czas reakcji i rozwiązania zgodnie z umowami SLA.
Dlaczego to ważne

Priorytet bezpośrednio wpływa na przydział zasobów i kolejność obsługi zgłoszeń. Analiza tego etapu pomaga dopilnować, by incydenty krytyczne były obsługiwane w pierwszej kolejności, a SLA dotrzymywane.

Skąd pobrać

Zdarzenie można wykryć, monitorując w dzienniku audytu zmiany pola „Priority” lub „Severity”.

Rejestrowanie

Użyj znacznika czasu z dziennika audytu powiązanego z aktualizacją pola „Priority”.

Typ zdarzenia explicit
Wznowiono pracę
Oznacza moment wznowienia obsługi wstrzymanego incydentu. Zwykle następuje po otrzymaniu potrzebnych informacji, dzięki czemu agent może kontynuować pracę.
Dlaczego to ważne

Ta czynność jest niezbędna do dokładnego pomiaru czasu oczekiwania na czynniki zewnętrzne. Czas między stanami „Pending” i „Resumed” pokazuje, jak długo proces był wstrzymany z przyczyn niezależnych od zespołu.

Skąd pobrać

Zdarzenie ustala się na podstawie historii statusów incydentu, gdy status zmienia się z „Pending” na „In Progress” lub inny status oznaczający aktywną pracę.

Rejestrowanie

Zapisz znacznik czasu zmiany statusu incydentu ze stanu oczekiwania na stan aktywny.

Typ zdarzenia inferred
Zmieniono status na oczekujący
Zdarzenie następuje, gdy prace nad incydentem zostają wstrzymane, zwykle w oczekiwaniu na informacje od użytkownika, dostawcy lub innego podmiotu zewnętrznego. W tym stanie zegar SLA zazwyczaj się zatrzymuje.
Dlaczego to ważne

Analiza czasu w stanie oczekiwania ujawnia zależności zewnętrzne i opóźnienia. Długi czas oczekiwania może maskować nieefektywność wewnętrzną i zniekształcać wskaźniki czasu rozwiązania.

Skąd pobrać

Zdarzenie ustala się na podstawie historii statusów incydentu, gdy status zmienia się na „Pending”, „On Hold” lub „Awaiting User”.

Rejestrowanie

Zapisz znacznik czasu za każdym razem, gdy status incydentu zmieni się na jeden z określonych statusów oczekiwania.

Typ zdarzenia inferred
Zalecane Opcjonalne

Instrukcje ekstrakcji danych

Jak przygotować dane do process mining.

Metody ekstrakcji zależą od systemu. Szczegółowe instrukcje znajdą Państwo w

naszym przewodniku ETL   lub   wybierz konkretny proces i system.

Gotowi do rozpoczęcia?

Już dziś zacznij usprawniać proces zarządzania incydentami. Wybierz poniżej instrukcję ekstrakcji dla konkretnego systemu lub skorzystaj z uniwersalnego szablonu, aby utworzyć dziennik zdarzeń i rozpocząć analizę procesu.

Rozwiązuj incydenty szybciej, zacznij usprawnienia już teraz

Wskaż wąskie gardła, ogranicz przestoje i zwiększ efektywność zespołu.

Rozpocznij okres próbny

Karta kredytowa nie jest wymagana. Konfiguracja zajmuje 5 minut.