Szablon danych do zarządzania incydentami
Szablon danych do zarządzania incydentami
- Zalecane atrybuty do zebrania
- Najważniejsze aktywności do śledzenia
- Wskazówki dotyczące pobierania danych z ServiceNow Problem Management
Atrybuty zarządzania incydentami
| Nazwa | Opis | ||
|---|---|---|---|
|
Czas zdarzenia
EventTime
|
Dokładny znacznik czasu wskazujący, kiedy miała miejsce czynność. | ||
|
Opis
Czas zdarzenia, nazywany też znacznikiem czasu, określa dokładną datę i godzinę zakończenia czynności lub zmiany stanu. W ServiceNow jest zwykle zapisywany w polu sys_updated_on dla każdej zmiany odnotowanej w historii audytu. Ten atrybut jest niezbędny do prawidłowego uporządkowania zdarzeń i przeprowadzania analiz opartych na czasie. Służy do obliczania czasu cyklu, czasu oczekiwania w kolejce i odstępów między czynnościami. Wskaźniki te pomagają wykrywać wąskie gardła, mierzyć wyniki względem SLA i oceniać efektywność procesu. Dokładność znaczników czasu ma zasadnicze znaczenie dla wiarygodności wszystkich miar czasu trwania.
Dlaczego to ważne
Ten znacznik czasu porządkuje czynności chronologicznie i umożliwia obliczanie wszystkich miar czasu, takich jak czas cyklu i czas trwania wąskich gardeł.
Skąd pobrać
Tabela sys_audit w ServiceNow, pole sys_created_on lub pole sys_updated_on z tabeli incident dla ostatniego stanu.
Przykłady
2023-04-15T10:05:21Z2023-04-15T11:22:00Z2023-04-16T09:00:30Z
|
|||
|
Identyfikator incydentu
IncidentId
|
Unikalny identyfikator każdego rekordu incydentu, używany jako główny klucz do śledzenia całego cyklu życia. | ||
|
Opis
Identyfikator incydentu to unikalny numer przypisywany każdemu zgłoszonemu incydentowi w ServiceNow. Służy jako główny identyfikator sprawy i łączy wszystkie powiązane czynności, aktualizacje oraz komunikację od momentu utworzenia incydentu do jego zamknięcia. W analizie process mining ten identyfikator ma podstawowe znaczenie. Pozwala połączyć zdarzenia dotyczące każdej sprawy w ich właściwej kolejności. Na tej podstawie można odkrywać mapy procesów, analizować warianty i obliczać czasy od początku do końca. Bez unikalnego identyfikatora incydentu dla każdej sprawy nie dałoby się prześledzić jej przebiegu aż do rozwiązania.
Dlaczego to ważne
To niezbędny identyfikator sprawy, który łączy wszystkie zdarzenia w cyklu życia incydentu i umożliwia analizę procesu od początku do końca.
Skąd pobrać
Tabela incydentów ServiceNow, pole number.
Przykłady
INC0010001INC0010045INC0010239
|
|||
|
Nazwa czynności
ActivityName
|
Nazwa konkretnego zdarzenia lub zadania, które miało miejsce w danym momencie cyklu życia incydentu. | ||
|
Opis
Nazwa czynności opisuje konkretny etap lub zmianę stanu w procesie zarządzania incydentami, na przykład „Utworzenie incydentu”, „Przydzielenie incydentu do pracownika” lub „Zamknięcie incydentu”. Dane te pochodzą zwykle ze zmian ważnych pól incydentu, takich jak 'State' lub 'Assignment Group', albo z konkretnych wpisów w dzienniku. Ten atrybut jest niezbędny do utworzenia mapy procesu. Określa węzły grafu procesu, dzięki czemu analitycy mogą zobaczyć przepływ incydentów, wskazać typowe ścieżki, wykryć wąskie gardła między czynnościami i analizować warianty procesu. Szczegółowość i poprawność nazw czynności bezpośrednio wpływają na jakość analizy procesu.
Dlaczego to ważne
Określa etapy na mapie procesu, która stanowi podstawę analizy i wizualizacji w process mining.
Skąd pobrać
To atrybut pochodny, zwykle generowany przez logikę transformacji danych na podstawie zmian pól takich jak state, assignment_group i assigned_to w tabeli sys_audit lub incident.
Przykłady
Utworzenie incydentuZmiana grupy przypisaniaPropozycja rozwiązaniaZamknięcie incydentu
|
|||
|
Ostatnia aktualizacja danych
LastDataUpdate
|
Znacznik czasu wskazujący, kiedy dane tego rekordu zostały ostatnio odświeżone z systemu źródłowego. | ||
|
Opis
Ten atrybut zapisuje datę i godzinę ostatniego pobrania lub aktualizacji danych z ServiceNow. To pole metadanych informuje o aktualności analizowanych danych, a nie o zdarzeniu w samym procesie. Informacja ta pozwala ocenić, na ile aktualna jest analiza. Użytkownicy mogą sprawdzić, jak świeże są dane, co ma znaczenie w przypadku dashboardów operacyjnych i decyzji opartych na niedawnych zdarzeniach. Pomaga to ocenić, czy dane nadal są aktualne i przydatne.
Dlaczego to ważne
Informuje użytkowników o aktualności danych, co ma zasadnicze znaczenie dla trafności i dokładności analizy.
Skąd pobrać
Ten znacznik czasu jest generowany i uzupełniany przez narzędzie lub proces pobierania danych podczas ich wczytywania.
Przykłady
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
|
|||
|
System źródłowy
SourceSystem
|
System, z którego pobrano te dane. | ||
|
Opis
Ten atrybut wskazuje źródło danych o incydentach, którym w tym przypadku jest ServiceNow Problem Management. Zazwyczaj jest to stała wartość dodawana podczas pobierania i transformacji danych. Jeśli analiza obejmuje dane z wielu systemów, pole to ma zasadnicze znaczenie dla śledzenia pochodzenia danych i ich rozdzielania. Pomaga analizować wskaźniki i procesy we właściwym kontekście oraz porównywać procesy w różnych systemach źródłowych.
Dlaczego to ważne
Informuje o pochodzeniu danych, ułatwia śledzenie ich przepływu i pozwala prawidłowo interpretować je w środowiskach korzystających z wielu systemów.
Skąd pobrać
Zazwyczaj jest to stała wartość dodawana podczas pobierania danych.
Przykłady
Zarządzanie problemami w ServiceNowServiceNow
|
|||
|
Grupa przypisania
AssignmentGroup
|
Zespół lub grupa wsparcia odpowiedzialna za obsługę incydentu. | ||
|
Opis
Grupa przypisania to zespół pracowników odpowiedzialnych za rozwiązanie incydentu. Zgłoszenia są często przekazywane między grupami, na przykład z działu pomocy technicznej pierwszego poziomu do wyspecjalizowanego zespołu sieciowego drugiego poziomu. Ten atrybut jest niezbędny do analizy przekazań między zespołami i wykrywania systemowych wąskich gardeł. Dashboard „Wskaźnik przekazań i ponownych przydziałów” wykorzystuje te dane, aby pokazać, które zespoły często uczestniczą w przekazywaniu zgłoszeń. Umożliwia też porównywanie wyników różnych grup wsparcia i ustalenie, w których częściach organizacji znajduje się wiedza potrzebna do rozwiązywania incydentów.
Dlaczego to ważne
Pokazuje, który zespół odpowiada za incydent, i umożliwia analizę wyników pracy, obciążenia oraz przekazań między grupami.
Skąd pobrać
Tabela incydentów ServiceNow, pole assignment_group.
Przykłady
Service deskWsparcie sieciAdministratorzy baz danych
|
|||
|
Priorytet
Priority
|
Priorytet incydentu określający wymaganą pilność reakcji. | ||
|
Opis
Priorytet to ważne pole w ServiceNow, które określa kolejność i tempo obsługi incydentu. Zazwyczaj wynika z wpływu i pilności incydentu oraz bezpośrednio wpływa na cele SLA. Atrybut ten jest podstawą segmentacji i analizy wyników. Dashboard „Przegląd zgodności z SLA” wykorzystuje priorytet do oceny, czy incydenty o wysokim priorytecie są rozwiązywane w wyznaczonym czasie. Analiza czasu cyklu według priorytetu pozwala sprawdzić, czy incydenty krytyczne są obsługiwane szybciej niż mniej istotne. To ważny wymiar niemal każdego KPI i dashboardu.
Dlaczego to ważne
Pozwala podzielić incydenty według ich znaczenia dla działalności, co ma zasadnicze znaczenie przy monitorowaniu zgodności z SLA i przydziale zasobów.
Skąd pobrać
Tabela incydentów ServiceNow, pole priority.
Przykłady
1 - Krytyczny2 - Wysoki3 - Umiarkowany4 - Niski
|
|||
|
Przypisany pracownik
AssignedTo
|
Użytkownik lub pracownik, któremu obecnie przydzielono obsługę incydentu. | ||
|
Opis
Ten atrybut wskazuje konkretnego pracownika wsparcia odpowiedzialnego za incydent w danym momencie. Informacja ta jest niezbędna do analizy rozkładu obciążenia, wyników pracy i przekazań między osobami. W analizie pole „Przypisany pracownik” pomaga zobrazować przydział zasobów i wykryć nadmiernie obciążone osoby. Jest też wykorzystywane w dashboardzie „Przekazania i ponowne przydziały”, który pokazuje, ile razy zmienia się osoba odpowiedzialna za incydent. Może to wskazywać na nieefektywność lub braki w wiedzy. Analiza czasu rozwiązania według pracownika może również ujawnić osoby osiągające najlepsze wyniki lub potrzebujące dodatkowego szkolenia.
Dlaczego to ważne
Umożliwia analizę obciążenia i wyników pracy oraz przekazań między pracownikami, co pomaga ocenić efektywność wykorzystania zasobów.
Skąd pobrać
Tabela incydentów ServiceNow, pole assigned_to.
Przykłady
Beth AnglinDavid LooHoward Johnson
|
|||
|
Stan incydentu
IncidentState
|
Bieżący status incydentu w jego cyklu życia. | ||
|
Opis
Stan incydentu wskazuje jego bieżący etap, na przykład 'New', 'In Progress', 'On Hold' lub 'Resolved'. Zmiany stanu są często głównym źródłem czynności rejestrowanych w dzienniku zdarzeń na potrzeby process mining. Analiza czasu spędzonego w każdym stanie pomaga wykrywać wąskie gardła. Na przykład długi czas w stanie 'On Hold' może wskazywać na zależność od czynników zewnętrznych lub użytkowników. Sekwencja zmian stanu stanowi również podstawę mapy procesu i pokazuje, jak incydenty zmierzają do rozwiązania.
Dlaczego to ważne
Pozwala śledzić przebieg incydentu, analizować czas spędzony na poszczególnych etapach i wykrywać wąskie gardła procesu.
Skąd pobrać
Tabela incydentów ServiceNow, pole incident_state lub state.
Przykłady
NowyW trakcieOczekiwanie na informacje od użytkownikaRozwiązanyZamknięty
|
|||
|
Czy ponownie otwarto
IsReopened
|
Flaga wskazująca, czy incydent ponownie otwarto po jego rozwiązaniu. | ||
|
Opis
Ta flaga logiczna przyjmuje wartość true, jeśli po osiągnięciu stanu „Resolved” lub „Closed” stan incydentu zmienił się z powrotem na aktywny, na przykład „In Progress”. Zwykle można to ustalić na podstawie aktywności „Incident Reopened” w dzienniku zdarzeń. Ponownie otwarte incydenty często wskazują, że rozwiązanie było niepełne lub nieskuteczne. Analiza takich przypadków pomaga wykryć przedwczesne zamknięcia i powracające problemy, których nie usunięto za pierwszym razem. Wysoki odsetek ponownie otwartych incydentów może obniżać satysfakcję użytkowników i produktywność zespołu, dlatego jest ważnym miernikiem kontroli jakości.
Dlaczego to ważne
Flaga wskazuje problemy z rozwiązaniem incydentu i pozwala wykryć przypadki wymagające dodatkowej pracy po uznaniu ich za rozwiązane.
Skąd pobrać
Obliczane przez sprawdzenie kolejności aktywności dla każdego incydentu i ustalenie, czy po stanie „resolved” pojawił się stan „open”.
Przykłady
truefalse
|
|||
|
Czy przekroczono SLA
IsSlaBreached
|
Flaga wskazująca, czy rozwiązanie incydentu nastąpiło po terminie SLA. | ||
|
Opis
Ten obliczany atrybut logiczny oznacza incydenty, w przypadku których doszło do naruszenia umowy SLA. Jest wyznaczany przez porównanie rzeczywistego timestampu rozwiązania z „Terminem realizacji SLA”. Jeśli incydent rozwiązano po tym terminie, flaga przyjmuje wartość true. Atrybut ten stanowi podstawę dashboardu „Przegląd zgodności z SLA” i powiązanych KPI. Upraszcza analizę, zamieniając porównanie czasu na prosty wymiar true/false. Dzięki temu można łatwo odfiltrować wszystkie incydenty z przekroczonym terminem i sprawdzić ich wspólne cechy, takie jak kategoria, grupa przypisania czy priorytet.
Dlaczego to ważne
Ułatwia analizę zgodności z SLA. Można szybko odfiltrować incydenty, w których nie dotrzymano terminu, i dokładniej zbadać ich przebieg.
Skąd pobrać
Obliczane przez porównanie timestampów „Resolved At” i „SlaDueDate”. (Resolved At > SlaDueDate).
Przykłady
truefalse
|
|||
|
Element konfiguracji
ConfigurationItem
|
Konkretny komponent IT, usługa lub zasób, którego dotyczy incydent. | ||
|
Opis
Configuration Item (CI) to zasób z bazy Configuration Management Database (CMDB), którego dotyczy incydent. Może to być serwer, aplikacja, laptop lub urządzenie sieciowe. Analiza incydentów według CI pomaga wykrywać zawodne zasoby i usługi. Pokazuje, które elementy infrastruktury IT generują najwięcej incydentów, co może pomóc w podjęciu decyzji o modernizacji lub wymianie. W process mining filtrowanie według CI pozwala sprawdzić, czy incydenty dotyczące krytycznych aplikacji są obsługiwane inaczej lub sprawniej niż pozostałe.
Dlaczego to ważne
Wskazuje zasób, którego dotyczy incydent. Ułatwia wykrycie problematycznych elementów infrastruktury IT i ukierunkowanie działań usprawniających.
Skąd pobrać
Tabela incydentów ServiceNow, pole cmdb_ci.
Przykłady
SAP ERP ProductionOracle DB Server 05Usługa poczty e-mail
|
|||
|
Identyfikator problemu
ProblemId
|
Identyfikator powiązanego rekordu Problem, jeśli incydent jest częścią większego problemu. | ||
|
Opis
Problem ID łączy incydent z odpowiednim rekordem w module Problem Management. Dzieje się tak, gdy incydent zostaje rozpoznany jako objaw większego problemu, który dotyczy wielu użytkowników lub usług. To powiązanie ma znaczenie dla dashboardu „Liczba powtarzających się incydentów” i KPI „Odsetek powtarzających się incydentów”. Pozwala analitykom grupować incydenty wynikające z tej samej przyczyny źródłowej, mierzyć pełny wpływ problemu i śledzić skuteczność jego rozwiązania. Duża liczba incydentów powiązanych z problemami może świadczyć o tym, że zespół wsparcia działa głównie reaktywnie.
Dlaczego to ważne
Łączy incydenty z przyczyną źródłową, co pozwala analizować powtarzające się problemy i mierzyć efekty zarządzania problemami.
Skąd pobrać
Tabela incydentów ServiceNow, pole problem_id.
Przykłady
PRB0040001PRB0040015PRB0040102
|
|||
|
Kategoria
Category
|
Ogólna klasyfikacja incydentu, na przykład sprzęt, oprogramowanie lub sieć. | ||
|
Opis
Kategoria określa ogólny rodzaj incydentu. Często wraz z podkategorią pomaga skierować incydent do właściwego zespołu wsparcia i służy do raportowania oraz analizy trendów. W process mining ten atrybut jest niezbędny w dashboardach „Poprawność kategoryzacji incydentów” i „Liczba powracających incydentów”. Analiza incydentów, których kategoria zmienia się w trakcie procesu, pozwala wykryć problemy z wstępną oceną. Filtrowanie mapy procesu według kategorii może też ujawnić, czy określone typy incydentów przebiegają innymi ścieżkami lub napotykają specyficzne wąskie gardła.
Dlaczego to ważne
Umożliwia analizę typów incydentów, pomiar poprawności kategoryzacji oraz analizę kierowania zgłoszeń i trendów.
Skąd pobrać
Tabela incydentów ServiceNow, pole category.
Przykłady
SprzętOprogramowanieSiećBaza danych
|
|||
|
Kod rozwiązania
ResolutionCode
|
Kod wskazujący sposób ostatecznego rozwiązania incydentu. | ||
|
Opis
Kod rozwiązania określa rodzaj zastosowanego rozwiązania, na przykład czy problem rozwiązał użytkownik, czy usunięto znany błąd albo zastosowano obejście. Pole to zazwyczaj uzupełnia pracownik przy zamykaniu incydentu. Atrybut ten bezpośrednio zasila dashboard „Skuteczność typów rozwiązań”. Pozwala analizować, ile incydentów zamknięto po trwałym usunięciu problemu, a ile po zastosowaniu tymczasowego obejścia. To ważny wskaźnik jakości usług i ich długoterminowej stabilności. Duży udział obejść może oznaczać, że problemy źródłowe nie są właściwie rozwiązywane.
Dlaczego to ważne
Określa sposób rozwiązania incydentu, umożliwia porównanie trwałych poprawek z tymczasowymi obejściami i wspiera analizę przyczyn źródłowych.
Skąd pobrać
Tabela incydentów ServiceNow, pole close_code lub własne pole kodu rozwiązania.
Przykłady
Rozwiązano (obejście problemu)Rozwiązano (trwale)Nie rozwiązano (anulowano na prośbę użytkownika)Znany błąd
|
|||
|
Liczba ponownych przypisań
ReassignmentCount
|
Liczba przekazań incydentu do innej grupy lub innemu agentowi. | ||
|
Opis
To pole zlicza, ile razy incydent przekazano między różnymi grupami przypisania. Bezpośrednio pokazuje tarcia w procesie i często służy jako KPI. Wartość tego atrybutu wpływa na dashboard „Odsetek przekazań i ponownych przypisań” oraz KPI „Średnia liczba przekazań na incydent”. Duża liczba ponownych przypisań może wskazywać na błędne początkowe kierowanie zgłoszeń, brak odpowiednich umiejętności na danym poziomie wsparcia lub niejasny podział odpowiedzialności za proces. Ograniczenie tej liczby często jest celem działań usprawniających, ponieważ zwykle skraca czas rozwiązania incydentu.
Dlaczego to ważne
Bezpośrednio mierzy liczbę przekazań w procesie. Jej wzrost może wskazywać na nieefektywność, błędne kierowanie zgłoszeń i możliwości usprawnienia.
Skąd pobrać
Tabela incydentów ServiceNow, pole reassignment_count.
Przykłady
0135
|
|||
|
Termin realizacji SLA
SlaDueDate
|
Data i godzina, do których incydent powinien zostać rozwiązany zgodnie z SLA. | ||
|
Opis
Termin realizacji SLA to obliczony timestamp określający, do kiedy należy rozwiązać incydent. Wyznacza go umowa o gwarantowanym poziomie świadczenia usług (SLA), z uwzględnieniem takich cech incydentu jak priorytet. Ten atrybut jest potrzebny do dashboardu „Przegląd zgodności z SLA” i KPI „Odsetek naruszeń SLA dla krytycznych incydentów”. Stanowi punkt odniesienia przy porównywaniu terminu z rzeczywistym czasem rozwiązania. Analiza incydentów, których termin SLA zbliża się do końca, może pomóc w odpowiednio wczesnej eskalacji i ustalaniu priorytetów.
Dlaczego to ważne
Określa termin rozwiązania, dzięki czemu można mierzyć zgodność z SLA i wykrywać incydenty zagrożone przekroczeniem terminu.
Skąd pobrać
Ta wartość znajduje się zwykle w tabeli task_sla powiązanej z tabelą incydentów. Odpowiednim timestampem jest pole planned_end_time.
Przykłady
2023-05-20T17:00:00Z2023-06-01T09:00:00Z
|
|||
|
Waga incydentu
Severity
|
Poziom wpływu incydentu na działalność firmy. | ||
|
Opis
Waga incydentu określa jego wpływ na operacje biznesowe. Wraz z pilnością często służy do automatycznego wyliczania priorytetu incydentu. W analizie jest ważnym wymiarem dashboardu „Przegląd zgodności z SLA”. Pozwala sprawdzić, czy organizacja dotrzymuje poziomów usług w przypadku najbardziej uciążliwych incydentów. Uzupełnia operacyjny obraz wyników oparty na priorytecie o perspektywę biznesową.
Dlaczego to ważne
Mierzy wpływ incydentu na działalność firmy. Pomaga ustalać priorytety i analizować obsługę najpoważniejszych problemów.
Skąd pobrać
Tabela incydentów ServiceNow, pole severity.
Przykłady
1 - Wysoka2 - Średnia3 - Niska
|
|||
|
Zgłaszający
CallerId
|
Użytkownik, który jako pierwszy zgłosił incydent. | ||
|
Opis
Pole Caller wskazuje użytkownika końcowego lub klienta, którego dotyczy incydent i który go zgłosił. Dzięki tej informacji wiadomo, kogo dotknęła przerwa w działaniu usługi. Analiza incydentów według zgłaszającego nie zawsze jest centralnym elementem analizy przebiegu procesu, ale może ujawnić, że problemy nieproporcjonalnie często dotyczą konkretnych osób lub działów. Może to wskazywać na potrzebę szkoleń albo lokalne problemy ze środowiskiem pracy. Pole zapewnia też bezpośredni kontakt z klientem na potrzeby ankiet satysfakcji i komunikacji.
Dlaczego to ważne
Wskazuje użytkownika, którego dotyczy incydent. Umożliwia analizę według działu lub osoby i ułatwia komunikację z użytkownikiem.
Skąd pobrać
Tabela incydentów ServiceNow, pole caller_id.
Przykłady
Abel TuterCarolina PashDon Goodliffe
|
|||
Aktywności w procesie zarządzania incydentami
| Działanie | Opis | ||
|---|---|---|---|
|
Propozycja rozwiązania
|
Moment, w którym pracownik wsparcia wdrożył poprawkę i zmienił stan incydentu na 'Resolved'. To ważny etap przed ostatecznym zamknięciem. | ||
|
Dlaczego to ważne
Ta czynność oznacza koniec aktywnej pracy i początek etapu potwierdzenia rozwiązania. Czas między tym zdarzeniem a „Zamknięciem incydentu” może ujawnić opóźnienia w potwierdzeniu przez użytkownika lub weryfikacji.
Skąd pobrać
Zdarzenie odtwarza się na podstawie tabeli 'sys_audit', gdy pole 'state' w tabeli 'incident' zmieni się na 'Resolved'. W tym momencie często uzupełniany jest znacznik czasu 'resolved_at'.
Rejestrowanie
Należy użyć znacznika czasu zmiany pola 'state' na 'Resolved' lub znacznika czasu 'resolved_at'.
Typ zdarzenia
inferred
|
|||
|
Przydzielenie incydentu do grupy
|
Ta czynność ma miejsce, gdy incydent zostaje przydzielony do konkretnej grupy wsparcia. To ważny etap kierowania zgłoszenia, rejestrowany na podstawie zmian w polu grupy przypisania. | ||
|
Dlaczego to ważne
Śledzenie przydziałów jest niezbędne do analizy przekazań, czasu oczekiwania w kolejce każdej grupy oraz wykrywania nieefektywnego kierowania zgłoszeń i wąskich gardeł.
Skąd pobrać
Zdarzenie odtwarza się na podstawie tabeli 'sys_audit', śledząc moment uzupełnienia lub zmiany pola 'assignment_group' w tabeli 'incident'.
Rejestrowanie
Należy użyć znacznika czasu z dziennika audytu dla zmian pola 'assignment_group'.
Typ zdarzenia
inferred
|
|||
|
Rozpoczęcie pracy
|
Oznacza, że pracownik rozpoczął analizę lub pracę nad incydentem. Zdarzenie jest zwykle odtwarzane na podstawie zmiany stanu incydentu z 'New' lub 'Assigned' na stan aktywny, taki jak 'In Progress'. | ||
|
Dlaczego to ważne
Ten etap kończy początkowy czas oczekiwania w kolejce i rozpoczyna aktywne działania zmierzające do rozwiązania incydentu. Pomiar czasu do rozpoczęcia pracy jest ważny przy analizie wąskich gardeł.
Skąd pobrać
Zdarzenie odtwarza się na podstawie tabeli 'sys_audit', wyszukując moment zmiany pola 'state' w tabeli 'incident' na wartość oznaczającą aktywną pracę, na przykład 'In Progress'.
Rejestrowanie
Należy ustalić znacznik czasu zmiany pola 'state' na 'In Progress' lub podobną wartość.
Typ zdarzenia
inferred
|
|||
|
Utworzenie incydentu
|
Początek cyklu życia incydentu. Nowy incydent zostaje formalnie zarejestrowany w ServiceNow. Zdarzenie jest rejestrowane na podstawie znacznika czasu utworzenia rekordu incydentu. | ||
|
Dlaczego to ważne
To główne zdarzenie rozpoczynające proces. Analiza czasu od tej czynności do rozwiązania incydentu jest podstawą pomiaru całkowitego czasu cyklu i zgodności z SLA.
Skąd pobrać
Znacznik czasu 'sys_created_on' w tabeli 'incident' jest jawnym znacznikiem czasu tego zdarzenia.
Rejestrowanie
Należy użyć znacznika czasu 'sys_created_on' z rekordu incydentu.
Typ zdarzenia
explicit
|
|||
|
Zamknięcie incydentu
|
To ostatnia czynność w cyklu życia incydentu. Oznacza, że incydent został rozwiązany i potwierdzony, a dalsze działania nie są potrzebne. Zdarzenie jest jawnie rejestrowane za pomocą znacznika czasu zamknięcia. | ||
|
Dlaczego to ważne
Jako końcowe zdarzenie procesu ta czynność jest niezbędna do obliczenia całkowitego czasu cyklu życia incydentu i analizy czasu potrzebnego na działania po jego rozwiązaniu.
Skąd pobrać
Znacznik czasu 'closed_at' w tabeli 'incident' jest jawnym znacznikiem czasu zdarzenia. Zazwyczaj jest ustawiany, gdy pole 'state' zmienia się na 'Closed'.
Rejestrowanie
Należy użyć znacznika czasu 'closed_at' z rekordu incydentu.
Typ zdarzenia
explicit
|
|||
|
Zmiana grupy przypisania
|
Przekazanie incydentu z jednej grupy wsparcia do innej. Zdarzenie rejestruje się, obserwując kolejne zmiany pola 'assignment_group' po jego pierwszym uzupełnieniu. | ||
|
Dlaczego to ważne
Częste ponowne przydziały mogą wskazywać na błędne początkowe kierowanie zgłoszeń, złożoność procesu lub braki w wiedzy. Ta czynność ma zasadnicze znaczenie przy obliczaniu KPI „Średnia liczba przekazań na incydent”.
Skąd pobrać
Zdarzenie odtwarza się na podstawie tabeli 'sys_audit', śledząc każdą zmianę pola 'assignment_group' po pierwszym przydzieleniu.
Rejestrowanie
Należy zidentyfikować każdy oznaczony znacznikiem czasu wpis o zmianie pola 'assignment_group' w dzienniku audytu.
Typ zdarzenia
inferred
|
|||
|
Dodanie komentarza przez wsparcie
|
Pracownik wsparcia dodaje notatkę dotyczącą pracy lub komentarz widoczny dla użytkownika. To jawne zdarzenie rejestrowane w strumieniu aktywności incydentu. | ||
|
Dlaczego to ważne
Zdarzenie pokazuje komunikację i działania zespołu wsparcia związane z analizą incydentu. Częstotliwość i czas dodawania komentarzy dostarczają informacji o przebiegu analizy.
Skąd pobrać
Dane pochodzą z tabeli 'sys_journal_field', w której rejestrowane są wpisy w polach 'work_notes' i 'comments' tabeli 'incident'.
Rejestrowanie
Należy użyć znacznika czasu utworzenia wpisów w dzienniku, w których element ma wartość 'work_notes' lub 'comments'.
Typ zdarzenia
explicit
|
|||
|
Eskalacja incydentu
|
Zdarzenie występuje, gdy wzrasta priorytet lub poziom ważności incydentu, co często wymaga szybszej reakcji lub zaangażowania innych zasobów. Można je odtworzyć, wykrywając wzrost wartości pola 'priority'. | ||
|
Dlaczego to ważne
Eskalacja często oznacza, że incydent jest poważniejszy, niż początkowo zakładano, lub zbliża się przekroczenie SLA. Analiza tych zdarzeń pomaga zrozumieć wyjątki w procesie.
Skąd pobrać
Zdarzenie odtwarza się na podstawie tabeli 'sys_audit', wyszukując zmianę pola 'priority' na wartość oznaczającą wyższy poziom pilności.
Rejestrowanie
Należy wykryć wzrost wartości pola 'priority', na przykład zmianę z '3 - Moderate' na '2 - High'.
Typ zdarzenia
inferred
|
|||
|
Kategoryzacja incydentu
|
Początkowa klasyfikacja incydentu, podczas której określa się między innymi pola Category, Subcategory i Priority. Zdarzenie jest zwykle odtwarzane na podstawie historii audytu, gdy te pola zostaną po raz pierwszy uzupełnione lub zaktualizowane krótko po utworzeniu incydentu. | ||
|
Dlaczego to ważne
Prawidłowa kategoryzacja ma zasadnicze znaczenie dla właściwego kierowania i ustalania priorytetów. Śledzenie tej czynności pozwala analizować, jak często zmienia się kategoryzacja i jaki ma to wpływ na czas rozwiązania.
Skąd pobrać
Zdarzenie odtwarza się na podstawie tabeli 'sys_audit', wyszukując pierwszą zmianę pól takich jak 'category', 'subcategory' lub 'priority' dla danego incydentu.
Rejestrowanie
Należy ustalić znacznik czasu pierwszej aktualizacji pól klasyfikacji w dzienniku audytu.
Typ zdarzenia
inferred
|
|||
|
Oczekiwanie na potwierdzenie użytkownika
|
Incydent ma stan oczekiwania na potwierdzenie przez użytkownika, że zaproponowane rozwiązanie zadziałało. Zdarzenie jest zwykle odtwarzane na podstawie konkretnego stanu, takiego jak 'Awaiting User Info', po rozwiązaniu incydentu. | ||
|
Dlaczego to ważne
Ten etap może stać się poważnym wąskim gardłem, jeśli użytkownicy długo nie odpowiadają. Pomiar czasu jego trwania pomaga wykryć problemy w komunikacji i możliwości automatycznego zamykania incydentów.
Skąd pobrać
Zdarzenie odtwarza się na podstawie tabeli 'sys_audit', wyszukując zmianę na konkretny stan oczekiwania po rozwiązaniu incydentu. Nazwa stanu może być niestandardowa, na przykład 'Awaiting Caller'.
Rejestrowanie
Należy ustalić znacznik czasu zmiany pola 'state' na wartość oznaczającą oczekiwanie na informacje od użytkownika.
Typ zdarzenia
inferred
|
|||
|
Ponowne otwarcie incydentu
|
Zdarzenie występuje, gdy użytkownik zgłasza, że problem nadal występuje po oznaczeniu incydentu jako rozwiązany. Można je odtworzyć, gdy stan incydentu zmieni się z 'Resolved' na stan aktywny, taki jak 'In Progress'. | ||
|
Dlaczego to ważne
Ponownie otwarte incydenty wskazują na nieskuteczne rozwiązania i konieczność ponownego wykonania pracy. Śledzenie tej czynności jest niezbędne do pomiaru jakości rozwiązań i odsetka spraw rozwiązanych za pierwszym razem.
Skąd pobrać
Zdarzenie odtwarza się na podstawie tabeli 'sys_audit', wykrywając zmianę pola 'state' ze stanu 'Resolved' z powrotem na stan aktywny, taki jak 'In Progress' lub 'Assigned'.
Rejestrowanie
Należy ustalić znacznik czasu zmiany pola 'state' ze stanu 'Resolved' na stan aktywny.
Typ zdarzenia
inferred
|
|||
|
Powiązanie incydentu z problemem
|
Ta czynność ma miejsce, gdy incydent zostaje formalnie powiązany z rekordem problemu, co oznacza, że jest częścią większego, źródłowego problemu. Zdarzenie odtwarza się, gdy pole 'problem_id' w rekordzie incydentu zostanie uzupełnione. | ||
|
Dlaczego to ważne
Powiązanie z problemem to ważny krok w przejściu od reaktywnego usuwania skutków incydentów do proaktywnej analizy ich przyczyn źródłowych. Dane te są wykorzystywane w dashboardzie „Liczba powracających incydentów”.
Skąd pobrać
Zdarzenie odtwarza się, wykrywając uzupełnienie pola referencyjnego 'problem_id' w tabeli 'incident'.
Rejestrowanie
Należy ustalić na podstawie dziennika audytu znacznik czasu uzupełnienia pola 'problem_id'.
Typ zdarzenia
inferred
|
|||
|
Przydzielenie incydentu do pracownika
|
Moment, w którym konkretny pracownik grupy wsparcia przejmuje odpowiedzialność za incydent. Zdarzenie rejestruje się, śledząc zmiany pola 'assigned_to'. | ||
|
Dlaczego to ważne
Pozwala to szczegółowo analizować obciążenie pracowników i rozwiązywanie spraw przy pierwszym kontakcie. Można ustalić, jak długo incydent czeka na rozpoczęcie pracy przez konkretną osobę po przydzieleniu go do grupy.
Skąd pobrać
Zdarzenie odtwarza się na podstawie tabeli 'sys_audit', śledząc moment uzupełnienia lub zmiany pola 'assigned_to' w tabeli 'incident'.
Rejestrowanie
Należy użyć znacznika czasu z dziennika audytu dla zmian pola 'assigned_to'.
Typ zdarzenia
inferred
|
|||
Instrukcje pobierania danych
Gotowi do rozpoczęcia?
Ten szablon zawiera dane potrzebne do rozpoczęcia analizy procesu zarządzania incydentami za pomocą process mining. Zacznij usprawniać rozwiązywanie incydentów.
Rozwiązuj incydenty szybciej: usprawnij obsługę w ServiceNow
Skróć MTTR o 35% w ServiceNow. Wykrywaj problemy i zwiększaj satysfakcję.
Nie trzeba podawać danych karty płatniczej. Zacznij usprawniać procesy w kilka minut.