Szablon danych do analizy obsługi incydentów

Jira Service Management
Szablon danych do analizy obsługi incydentów

Szablon danych do analizy obsługi incydentów

Ten szablon pomaga uporządkować zbieranie danych potrzebnych do analizy procesu obsługi incydentów. Zawiera listę atrybutów do zebrania i działań do śledzenia, a także praktyczne wskazówki dotyczące pobierania tych informacji z systemu źródłowego. Dzięki temu można przygotować dane potrzebne do rozpoczęcia usprawniania procesu rozwiązywania incydentów.
  • Zalecane atrybuty do zebrania
  • Najważniejsze działania do śledzenia
  • Wskazówki dotyczące pobierania danych z Jira Service Management
Pierwszy raz spotykają się Państwo z dziennikiem zdarzeń? Dowiedz się jak utworzyć dziennik zdarzeń na potrzeby process mining.

Atrybuty obsługi incydentów

To zalecane pola danych, które warto uwzględnić w dzienniku zdarzeń, aby dokładnie analizować proces obsługi incydentów.
5 Wymagane 6 Zalecane 12 Opcjonalne
Nazwa Opis
Czas rozpoczęcia
EventTimestamp
Dokładna data i godzina wystąpienia działania.
Opis

Ten atrybut zapisuje znacznik czasu każdego działania w cyklu obsługi incydentu. Jest niezbędny do obliczania czasu trwania, czasu cyklu i przerw między kolejnymi krokami procesu. Dokładne znaczniki czasu umożliwiają szczegółową analizę wyników, monitorowanie SLA i wykrywanie wąskich gardeł. Na ich podstawie oblicza się między innymi czas rozwiązania i czas diagnozy.

Dlaczego to ważne

Znaczniki czasu są niezbędne do obliczania miar czasowych, określania czasu trwania procesu i wykrywania wąskich gardeł.

Skąd pobrać

Data „created” przypisana do każdego wpisu w dzienniku zmian lub historii zgłoszenia Jira.

Przykłady
2023-10-26T10:00:00Z2023-10-26T10:05:14Z2023-10-27T14:30:00Z
Działanie
ActivityName
Nazwa zdarzenia lub zmiany statusu, która wystąpiła w obsłudze incydentu.
Opis

Działanie oznacza odrębny krok lub zdarzenie w cyklu obsługi incydentu, na przykład „Utworzono incydent”, „Przypisano incydent” lub „Zaproponowano rozwiązanie”. Zwykle dane te pochodzą ze zmian statusu lub aktualizacji zapisanych w historii zgłoszenia Jira albo w dzienniku zmian. Analiza kolejności i czasu trwania działań to główny cel process mining. Pozwala ona zobaczyć rzeczywisty przebieg procesu, wąskie gardła i odstępstwa.

Dlaczego to ważne

Działania tworzą podstawę mapy procesu i umożliwiają wizualizację oraz analizę przebiegu obsługi incydentu.

Skąd pobrać

Dane pochodzą z historii zgłoszenia Jira i dziennika zmian. Obejmują zmiany statusu oraz aktualizacje ważnych pól.

Przykłady
Przypisano incydentRozpoczęto analizęRozwiązano incydent
Identyfikator incydentu
IncidentId
Unikalny identyfikator każdego zgłoszenia incydentu w Jira Service Management.
Opis

Identyfikator incydentu, nazywany w Jira również kluczem zgłoszenia (Issue Key), jest unikalnym identyfikatorem każdego zgłoszonego incydentu. Łączy wszystkie powiązane działania, komentarze i zmiany statusu, od utworzenia zgłoszenia aż do jego zamknięcia. W process mining ten identyfikator pozwala odtworzyć pełny przebieg każdego incydentu i przeanalizować cały proces.

Dlaczego to ważne

To podstawowy identyfikator, który łączy powiązane zdarzenia w jedną sprawę. Stanowi punkt wyjścia do analizy process mining.

Skąd pobrać

Standardowe pole „Key” dla zgłoszenia w Jira Service Management, np. „ITSM-123”.

Przykłady
INC-10234HELPDESK-5678OPS-9901
Data ostatniej aktualizacji danych
LastDataUpdate
Znacznik czasu ostatniego odświeżenia danych z systemu źródłowego.
Opis

Ten atrybut wskazuje, kiedy zbiór danych został ostatnio zaktualizowany. Dzięki temu osoby analizujące proces wiedzą, jak aktualne są dane. Ma to szczególne znaczenie w dashboardach do bieżącego monitorowania, gdzie aktualne informacje pomagają podejmować decyzje na czas. Zwykle wszystkie zdarzenia z jednej partii ekstrakcji mają tę samą wartość.

Dlaczego to ważne

Informuje o aktualności danych, co ma znaczenie dla trafności i dokładności analizy.

Skąd pobrać

Znacznik czasu ekstrakcji danych, dodawany podczas ich przekształcania.

Przykłady
2023-10-27T08:00:00Z2023-10-28T08:00:00Z
System źródłowy
SourceSystem
System, z którego pobrano dane.
Opis

Ten atrybut wskazuje źródło danych, którym w tym przypadku jest Jira Service Management. Jest przydatny zwłaszcza wtedy, gdy analiza obejmuje dane z wielu systemów. Wskazanie systemu źródłowego ułatwia śledzenie pochodzenia danych i diagnozowanie problemów z ich jakością lub ekstrakcją. W tym modelu wartość jest stała.

Dlaczego to ważne

Informuje o pochodzeniu danych i ułatwia ich śledzenie, szczególnie podczas analizy obejmującej wiele systemów.

Skąd pobrać

Wartość stałą należy dodać podczas ekstrakcji danych.

Przykłady
Jira Service ManagementJira Cloud
Data rozwiązania
ResolutionDate
Data i godzina oznaczenia incydentu jako rozwiązany.
Opis

Ten atrybut zapisuje znacznik czasu pierwszego przejścia incydentu do statusu rozwiązany. Oznacza koniec aktywnej pracy nad incydentem i służy do obliczenia czasu rozwiązania. Porównanie daty rozwiązania z datą utworzenia daje podstawową miarę sprawności procesu. Data ta pomaga również ocenić zgodność z SLA.

Dlaczego to ważne

Wyznacza koniec procesu rozwiązywania incydentu i umożliwia obliczenie całkowitego czasu cyklu oraz wyników SLA.

Skąd pobrać

Standardowe pole „Resolved” w zgłoszeniu Jira.

Przykłady
2023-10-28T11:20:30Z2023-11-02T10:00:00Z
Data utworzenia
CreatedDate
Data i godzina pierwszego utworzenia incydentu w systemie.
Opis

Ten atrybut wyznacza oficjalny początek cyklu obsługi incydentu. Jest to podstawowy znacznik czasu do obliczania miar, takich jak całkowity czas rozwiązania. Data utworzenia jest stała dla każdego incydentu i wyznacza początek sprawy w analizie process mining.

Dlaczego to ważne

Stanowi punkt początkowy do obliczania czasu cyklu od początku do końca oraz pomiaru SLA.

Skąd pobrać

Standardowe pole „Created” w zgłoszeniu Jira.

Przykłady
2023-10-26T09:58:12Z2023-11-01T15:20:05Z
Grupa przypisana
AssignmentGroup
Zespół lub grupa odpowiedzialna za obsługę incydentu.
Opis

Grupa przypisana to zespół odpowiedzialny za incydent. Może to być poziom wsparcia, na przykład „L1 Helpdesk”, wyspecjalizowany zespół, taki jak „Network Operations”, albo zespół programistyczny. Analiza zmian grupy przypisanej pomaga zrozumieć eskalacje i przekazywanie spraw. Umożliwia też pomiar wyników zespołów, wykrywanie wąskich gardeł na poziomie zespołu i analizę zależności między zespołami.

Dlaczego to ważne

Niezbędna do analizy wyników zespołów, przepustowości oraz przepływu pracy między poziomami wsparcia i wyspecjalizowanymi grupami.

Skąd pobrać

Często jest to pole niestandardowe w Jira, na przykład „Team” lub „Assignment Group”. Grupę można czasem ustalić na podstawie komponentów Jira lub ról w projekcie.

Przykłady
Wsparcie pierwszego poziomuZespół infrastrukturyAdministratorzy baz danych
Osoba przypisana
Assignee
Użytkownik aktualnie odpowiedzialny za obsługę incydentu.
Opis

Osoba przypisana to agent lub użytkownik odpowiedzialny za incydent w danym momencie. Śledzenie zmian tej osoby pomaga analizować przekazywanie spraw, rozkład obciążenia pracą i udział poszczególnych osób w kolejnych krokach procesu. Atrybut ten pozwala ocenić indywidualne wyniki oraz przydział zasobów w zespołach wsparcia.

Dlaczego to ważne

Ułatwia śledzenie obciążenia pracą, wykrywanie wąskich gardeł związanych z konkretnymi agentami i ocenę wpływu przekazywania spraw na czas rozwiązania.

Skąd pobrać

Standardowe pole „Assignee” w zgłoszeniu Jira.

Przykłady
John SmithEmily JonesServiceDeskAgent1
Priorytet
Priority
Poziom priorytetu incydentu, określający pilność jego rozwiązania.
Opis

Priorytet określa, jak szybko należy zająć się incydentem. Zwykle uwzględnia jego wpływ i pilność, a także bezpośrednio wpływa na cele SLA. Analiza incydentów według priorytetu pokazuje, czy te o wysokim priorytecie są obsługiwane szybciej niż pozostałe i czy priorytety są stosowane konsekwentnie. To ważny wymiar filtrowania i porównywania wyników procesu.

Dlaczego to ważne

Niezbędny do analizy realizacji SLA i sprawdzenia, czy zasoby są właściwie przydzielane do najpilniejszych incydentów.

Skąd pobrać

Standardowe pole „Priority” w zgłoszeniu Jira.

Przykłady
NajwyższyWysokiŚredniNiski
Status
Status
Bieżący etap incydentu w jego cyklu obsługi.
Opis

Pole Status wskazuje bieżący stan incydentu w zdefiniowanym workflow, na przykład „Otwarte”, „W toku”, „Oczekiwanie na klienta” lub „Rozwiązane”. Zmiany statusu są głównym źródłem danych do utworzenia dziennika działań na potrzeby process mining. Analiza czasu spędzonego w każdym statusie pomaga wykrywać wąskie gardła i ustalić, na których etapach incydenty czekają najdłużej.

Dlaczego to ważne

Bezpośrednio pokazuje postęp obsługi incydentu i stanowi główne źródło informacji o krokach procesu oraz czasie oczekiwania.

Skąd pobrać

Standardowe pole „Status” w zgłoszeniu Jira.

Przykłady
W tokuOczekiwanie na klientaRozwiązaneZamknięte
Czy wystąpiła ponowna praca
IsRework
Wskaźnik informujący, czy incydent wymagał ponownej pracy, na przykład po ponownym otwarciu.
Opis

Ten obliczany atrybut logiczny wskazuje incydenty, które wróciły do wcześniejszego etapu procesu, najczęściej po ponownym otwarciu już rozwiązanej sprawy. Powtarzanie pracy jest istotnym źródłem nieefektywności i niezadowolenia klientów. Wskaźnik ułatwia obliczenie odsetka takich incydentów i skupienie analizy na przyczynach, dla których nie udało się ich poprawnie rozwiązać za pierwszym razem.

Dlaczego to ważne

Wskazuje problemy z jakością i nieefektywność procesu, oznaczając incydenty wymagające ponownej pracy. Ułatwia ich analizę.

Skąd pobrać

Obliczane przez wykrywanie określonych sekwencji zmian statusu w dzienniku zdarzeń, na przykład „Rozwiązane” -> „Ponownie otwarte”.

Przykłady
truefalse
Docelowy czas rozwiązania
TimeToResolutionTarget
Docelowy czas rozwiązania incydentu określony w SLA.
Opis

Ten atrybut określa maksymalny oczekiwany czas rozwiązania incydentu o danym priorytecie lub typie. Rzeczywisty czas rozwiązania porównuje się z tym celem, aby ocenić zgodność z SLA. Wartość jest zwykle ustalana dynamicznie na podstawie reguł uwzględniających takie czynniki jak priorytet, waga incydentu lub typ zgłoszenia. Jest niezbędna do monitorowania realizacji SLA w dashboardzie.

Dlaczego to ważne

Wyznacza punkt odniesienia do oceny zgodności z SLA i obliczenia KPI dotyczącego odsetka incydentów, w których przekroczono SLA.

Skąd pobrać

Wartość pochodzi z konfiguracji SLA w Jira Service Management. Należy wskazać konkretny cel, na przykład „Time to resolution”.

Przykłady
4 godz.8 godz.3 dni
Identyfikator powiązanego problemu
LinkedProblemId
Identyfikator zgłoszenia problemu powiązanego z tym incydentem.
Opis

Incydenty będące objawem większego problemu często łączy się ze zgłoszeniem typu Problem. To pole przechowuje identyfikator powiązanego problemu. Analiza tych powiązań pomaga zrozumieć relacje między incydentami a problemami, ocenić skuteczność zarządzania problemami i wykrywać powtarzające się incydenty wymagające trwałego rozwiązania.

Dlaczego to ważne

Łączy incydenty z problemami leżącymi u ich podstaw. Pozwala ocenić, jak skutecznie organizacja usuwa przyczyny źródłowe, aby zapobiegać kolejnym incydentom.

Skąd pobrać

Informacje te są zapisane w sekcji „Issue Links” zgłoszenia Jira.

Przykłady
PROB-123PROB-456Brak
Kategoria przyczyny źródłowej
RootCauseCategory
Klasyfikacja podstawowej przyczyny incydentu.
Opis

Ten atrybut wskazuje podstawową przyczynę incydentu, na przykład błąd oprogramowania, awarię sprzętu lub błąd użytkownika. Zwykle jest uzupełniany po przeprowadzeniu analizy. Ma znaczenie dla skutecznego zarządzania problemami i zapobiegania kolejnym incydentom. Analiza kategorii przyczyn źródłowych pomaga wykrywać słabe punkty systemu i ustalać priorytety działań usprawniających. Duży udział przyczyn oznaczonych jako „Nieznane” może wskazywać na potrzebę usprawnienia analizy incydentów.

Dlaczego to ważne

Umożliwia analizę przyczyn źródłowych i przejście od reagowania na incydenty do zapobiegania im przez identyfikację i eliminowanie ich źródeł.

Skąd pobrać

Prawie zawsze jest to pole niestandardowe w Jira. Nazwa i dostępne wartości zależą od konfiguracji organizacji.

Przykłady
Błąd konfiguracjiAwaria sieciBłąd oprogramowania
Komponent
Component
System, aplikacja lub część infrastruktury, której dotyczy incydent.
Opis

Komponenty to podsekcje projektu Jira, które służą do grupowania zgłoszeń, na przykład według interfejsu użytkownika, bazy danych lub API. Analiza incydentów według komponentów pomaga wskazać części systemu, w których najczęściej występują problemy. Informacje te wspierają analizę przyczyn źródłowych i pomagają zaplanować ulepszanie usług lub ograniczenie długu technicznego.

Dlaczego to ważne

Umożliwia filtrowanie i analizę według produktu lub obszaru systemu, którego dotyczy incydent, co pomaga wskazać problematyczne obszary technologiczne.

Skąd pobrać

Standardowe pole „Components” w zgłoszeniu Jira.

Przykłady
Usługa uwierzytelnianiaDashboard raportowyAplikacja mobilna
Liczba przekazań
HandoffCount
Liczba zmian grupy lub użytkownika, któremu przypisano incydent.
Opis

Ta obliczana miara zlicza zmiany pól „Assignee” lub „AssignmentGroup” w cyklu obsługi incydentu. Duża liczba przekazań często wskazuje na nieefektywny proces, brak rozwiązania przy pierwszym kontakcie lub luki w wiedzy, co wydłuża czas rozwiązania. Analiza tego KPI pomaga usprawnić przydzielanie zgłoszeń i współpracę między zespołami.

Dlaczego to ważne

Pokazuje skalę utrudnień i nieefektywności wynikających ze zmiany osób lub grup odpowiedzialnych, pomagając wskazać możliwości ulepszenia procesu.

Skąd pobrać

Obliczane przez zliczenie zmian pola „Assignee” lub „AssignmentGroup” w dzienniku zmian zgłoszenia.

Przykłady
015
Przekroczenie SLA
SlaBreach
Wskaźnik informujący, czy czas rozwiązania incydentu przekroczył cel SLA.
Opis

Ten obliczany atrybut logiczny wskazuje, czy w przypadku incydentu przekroczono SLA „Time to Resolution”. Przyjmuje wartość true, gdy „IncidentResolutionCycleTime” jest większy niż „TimeToResolutionTarget”. Wskaźnik ułatwia filtrowanie i agregowanie danych w celu obliczenia KPI dotyczącego odsetka przekroczeń SLA. Jest też główną miarą wyników w dashboardzie do monitorowania SLA.

Dlaczego to ważne

Jednoznacznie pokazuje, czy dotrzymano SLA, co ułatwia obliczanie odsetka przekroczeń i wykrywanie problematycznych obszarów.

Skąd pobrać

Obliczane jako („IncidentResolutionCycleTime” > „TimeToResolutionTarget”).

Przykłady
truefalse
Sposób rozwiązania
Resolution
Wynik końcowy lub powód rozwiązania incydentu.
Opis

Pole Resolution wyjaśnia, dlaczego incydent otrzymał status rozwiązany. Typowe wartości to „Naprawiono”, „Duplikat”, „Nie zostanie wykonane” lub „Nie można odtworzyć”. Analiza rozkładu sposobów rozwiązania pozwala ocenić jakość zgłoszeń i skuteczność procesu. Na przykład duża liczba rozwiązań typu „Duplikat” może wskazywać na problem z tworzeniem zgłoszeń lub ich wstępną oceną.

Dlaczego to ważne

Dostarcza informacji o wyniku obsługi incydentu, ułatwia kategoryzowanie rozwiązań i wykrywanie tendencji w sposobie zamykania spraw.

Skąd pobrać

Standardowe pole „Resolution” w zgłoszeniu Jira. Zwykle jest ustawiane po zmianie statusu zgłoszenia na kategorię „Done”.

Przykłady
ZakończoneNaprawionoDuplikatNie zostanie naprawione
Typ wniosku klienta
CustomerRequestType
Rodzaj wniosku przesłanego przez klienta za pośrednictwem portalu usługowego.
Opis

To pole kategoryzuje wnioski z perspektywy klienta, zgodnie z ich prezentacją w portalu Jira Service Management, na przykład „Zgłoś problem z systemem”. Zapewnia zrozumiały dla użytkownika podział incydentów, który może różnić się od wewnętrznego pola „Issue Type”. Analiza tego atrybutu pokazuje, jak klienci postrzegają i zgłaszają problemy, co może pomóc w ulepszaniu portalu i oferty usług.

Dlaczego to ważne

Pokazuje kategorie incydentów z perspektywy klienta. Ułatwia analizę zapotrzebowania i ulepszanie obsługi klienta.

Skąd pobrać

Pole „Customer Request Type”, dostępne w projektach Jira Service Management.

Przykłady
Pomoc IT > Zgłoś problem z systememE-mail > Wniosek o dostęp
Typ zgłoszenia
IssueType
Rodzaj zgłoszenia, na przykład incydent, wniosek o usługę lub problem.
Opis

Jira używa typów zgłoszeń, aby rozróżniać różne rodzaje zadań. W obsłudze incydentów podstawowym typem jest „Incident”, ale znaczenie mogą mieć również inne typy, na przykład „Sub-task”. Ten atrybut pozwala ograniczyć zbiór danych do incydentów i skupić analizę process mining na właściwym procesie.

Dlaczego to ważne

Pozwala ograniczyć analizę do incydentów i oddzielić je od innych rodzajów pracy, takich jak wnioski o usługi lub zmiany.

Skąd pobrać

Standardowe pole „Issue Type” w zgłoszeniu Jira.

Przykłady
IncydentPomoc ITBłąd oprogramowania
Waga incydentu
Severity
Miara wpływu incydentu na działalność firmy.
Opis

Waga incydentu określa jego wpływ na działalność firmy, od problemu dotyczącego jednego użytkownika po awarię krytycznego systemu. Priorytet wskazuje kolejność pracy, a waga opisuje ogólny wpływ na firmę. Analiza według wagi pozwala ocenić obsługę incydentów najistotniejszych dla działalności. Często łączy się ją z priorytetem, aby uzyskać dokładniejszy obraz.

Dlaczego to ważne

Pokazuje wpływ incydentu na działalność firmy i pozwala skupić analizę na zdarzeniach powodujących największe zakłócenia.

Skąd pobrać

Zwykle jest to pole niestandardowe w Jira, ponieważ nie należy do standardowych pól systemowych. Szczegóły można sprawdzić w konfiguracji projektu Jira Service Management.

Przykłady
KrytycznyPoważnyNiewielkiBłahy
Zgłaszający
Reporter
Użytkownik, który utworzył lub zgłosił incydent.
Opis

Zgłaszający to osoba, często użytkownik końcowy, albo inny system, z którego po raz pierwszy zarejestrowano incydent. Analiza zgłoszeń według zgłaszającego pomaga wskazać użytkowników lub działy, w których problemy występują częściej. Może też ujawnić wzorce komunikacji, zwłaszcza przy analizie działań takich jak „Oczekiwanie na klienta” i „Odpowiedź klienta”.

Dlaczego to ważne

Ułatwia analizę źródeł incydentów, wykrywanie wzorców związanych z konkretnymi użytkownikami lub działami oraz ocenę opóźnień w komunikacji z klientami.

Skąd pobrać

Standardowe pole „Reporter” w zgłoszeniu Jira.

Przykłady
Alice JohnsonBob Williamsmonitoring-tool@example.com
Wymagane Zalecane Opcjonalne

Działania w procesie obsługi incydentów

To najważniejsze kroki i punkty kontrolne, które warto zapisać w dzienniku zdarzeń, aby prawidłowo odkrywać i analizować przebieg rozwiązywania incydentów.
7 Zalecane 8 Opcjonalne
Działanie Opis
Oczekiwanie na klienta
Oznacza moment, w którym zespół wsparcia czeka na informacje lub działanie ze strony klienta. Zdarzenie jest wywnioskowane na podstawie zmiany statusu na przeznaczony do oczekiwania, na przykład „Oczekiwanie na klienta”.
Dlaczego to ważne

Oddzielenie czasu oczekiwania jest niezbędne do prawidłowego pomiaru SLA, ponieważ często nie wlicza się go do czasu rozwiązania. Ułatwia też analizę opóźnień w odpowiedziach klientów.

Skąd pobrać

Zdarzenie jest wywnioskowane z historii zmian statusu zgłoszenia. Odpowiada timestampowi zmiany statusu na „Oczekiwanie na klienta” lub podobny.

Rejestrowanie

Ustal timestamp zmiany statusu na „Oczekiwanie na klienta”.

Typ zdarzenia inferred
Ponownie przypisano incydent
Zdarzenie występuje, gdy po pierwszym przypisaniu incydent zostaje przekazany innemu agentowi lub grupie. Jest wywnioskowane na podstawie zmiany pola „Osoba przypisana” lub „Przypisana grupa”.
Dlaczego to ważne

Śledzenie ponownych przypisań jest ważne przy analizie przekazywania pracy. Ich duża liczba często wskazuje na nieefektywności procesu, braki wiedzy lub błędne przypisanie na początku, co wydłuża czas rozwiązania.

Skąd pobrać

Zdarzenie jest wywnioskowane z historii zgłoszenia na podstawie każdej aktualizacji pola „Osoba przypisana” po jego pierwszym uzupełnieniu. Każda zmiana oznacza ponowne przypisanie.

Rejestrowanie

Wykryj kolejne zmiany pola „Osoba przypisana” po pierwszym przypisaniu.

Typ zdarzenia inferred
Rozpoczęto analizę
Oznacza, że przypisany agent rozpoczął aktywną pracę nad diagnozą incydentu. Zdarzenie jest zwykle wywnioskowane, gdy status zgłoszenia zmienia się z „Otwarte” lub „Nowe” na „W toku”.
Dlaczego to ważne

Ten ważny etap oznacza początek aktywnych działań zmierzających do rozwiązania incydentu. Pomiar czasu do tego momentu pomaga wykryć opóźnienia w kolejce i problemy z dostępnością zasobów.

Skąd pobrać

Zdarzenie jest wywnioskowane z historii zmian statusu zgłoszenia. Jego timestamp odpowiada chwili zmiany statusu na oznaczający aktywną pracę, na przykład „W toku”.

Rejestrowanie

Ustal timestamp zmiany statusu na „W toku”.

Typ zdarzenia inferred
Rozwiązano incydent
To działanie oznacza potwierdzenie, że incydent został rozwiązany, a usługa przywrócona. Często zbiega się ze zmianą statusu na „Rozwiązane”.
Dlaczego to ważne

To główny etap potwierdzający pomyślne zakończenie procesu. Czas do tego momentu jest najczęściej mierzonym KPI i odpowiada czasowi rozwiązania (TTR).

Skąd pobrać

Zdarzenie jest wywnioskowane na podstawie zmiany statusu na „Rozwiązane”. W wielu workflow jest to to samo zdarzenie co „Zaproponowano rozwiązanie” i oznacza główny moment rozwiązania incydentu.

Rejestrowanie

Ustal timestamp zmiany statusu na „Rozwiązane”.

Typ zdarzenia inferred
Utworzono incydent
Oznacza oficjalne rozpoczęcie cyklu życia incydentu, gdy zgłoszenie zostaje przesłane, a w Jira powstaje nowe zgłoszenie. Zdarzenie jest rejestrowane, gdy w systemie utworzono nowe zgłoszenie typu „Incydent”.
Dlaczego to ważne

To główne zdarzenie rozpoczynające proces. Pomiar czasu od tego działania do rozwiązania incydentu jest podstawą do obliczania całkowitego czasu obsługi i oceny przestrzegania SLA.

Skąd pobrać

To jawne zdarzenie odczytywane z timestampu „Utworzono” zgłoszenia incydentu w Jira. Informacja o utworzeniu zgłoszenia jest zapisywana w jego historii.

Rejestrowanie

Użyj timestampu utworzenia zgłoszenia.

Typ zdarzenia explicit
Zamknięto incydent
Oznacza ostateczne, administracyjne zamknięcie zgłoszenia incydentu po jego rozwiązaniu i weryfikacji. Zdarzenie jest wywnioskowane na podstawie zmiany statusu na „Zamknięte”.
Dlaczego to ważne

To końcowe zdarzenie procesu. Analiza czasu między „Rozwiązane” a „Zamknięte” może ujawnić opóźnienia w czynnościach administracyjnych lub oczekiwaniu na potwierdzenie użytkownika.

Skąd pobrać

Zdarzenie jest wywnioskowane z historii zmian statusu zgłoszenia. Odpowiada timestampowi zmiany statusu na końcowy „Zamknięte”.

Rejestrowanie

Ustal timestamp zmiany statusu na „Zamknięte”.

Typ zdarzenia inferred
Zaproponowano rozwiązanie
Oznacza, że znaleziono i wdrożono rozwiązanie, a incydent oczekuje na potwierdzenie lub końcową weryfikację. Zdarzenie jest wywnioskowane na podstawie zmiany statusu na „Rozwiązane”.
Dlaczego to ważne

To ważny etap, który oznacza koniec aktywnej pracy zespołu wsparcia. Często w tym momencie zatrzymuje się zegar SLA.

Skąd pobrać

Zdarzenie jest wywnioskowane z historii zmian statusu zgłoszenia. Jego timestamp odpowiada chwili zmiany statusu na „Rozwiązane” lub równoważny.

Rejestrowanie

Ustal timestamp zmiany statusu na „Rozwiązane”.

Typ zdarzenia inferred
Dodano komentarz
Oznacza zdarzenie związane z komunikacją lub dodaniem notatki przez użytkownika do zgłoszenia incydentu. Jest rejestrowane za każdym razem, gdy ktoś opublikuje komentarz.
Dlaczego to ważne

Analiza częstotliwości komentarzy może dostarczyć informacji o sposobie komunikacji, efektywności współpracy i złożoności incydentu. Pomaga też wykryć incydenty wymagające nadmiernej liczby wiadomości.

Skąd pobrać

To jawne zdarzenie. Jira zapisuje timestamp i autora każdego komentarza. Dane są dostępne w historii komentarzy zgłoszenia lub przez API.

Rejestrowanie

Użyj timestampu każdego komentarza dodanego do zgłoszenia.

Typ zdarzenia explicit
Klient odpowiedział
Oznacza, że klient przekazał wymagane informacje i można kontynuować obsługę incydentu. Zdarzenie jest wywnioskowane, gdy status zmienia się z „Oczekiwanie na klienta” na status aktywny.
Dlaczego to ważne

To działanie oznacza koniec opóźnienia spowodowanego oczekiwaniem na klienta. Analiza czasu między „Oczekiwanie na klienta” a tym zdarzeniem pozwala ustalić średni czas odpowiedzi klienta.

Skąd pobrać

Zdarzenie jest wywnioskowane z historii zmian statusu zgłoszenia. Występuje, gdy status zmienia się z „Oczekiwanie na klienta” na przykład na „W toku”, często po dodaniu komentarza przez klienta.

Rejestrowanie

Wykryj zmianę statusu z „Oczekiwanie na klienta” na „W toku”.

Typ zdarzenia inferred
Ponownie otwarto incydent
Oznacza ponowne uruchomienie obsługi wcześniej rozwiązanego incydentu, ponieważ problem wystąpił ponownie lub rozwiązanie okazało się nieskuteczne. Zdarzenie jest wywnioskowane na podstawie zmiany statusu z „Rozwiązane” lub „Zamknięte” na status otwarty.
Dlaczego to ważne

Ponownie otwarte incydenty bezpośrednio wskazują na jakość rozwiązania i są ważnym miernikiem konieczności ponownej pracy. Ich analiza pomaga wykrywać przedwczesne zamknięcia i nieskuteczne rozwiązania.

Skąd pobrać

Zdarzenie jest wywnioskowane z historii zmian statusu zgłoszenia. Jest rejestrowane, gdy status zmienia się ze stanu końcowego, takiego jak „Rozwiązane” lub „Zamknięte”, na „Otwarte” lub „W toku”.

Rejestrowanie

Wykryj zmianę statusu z „Rozwiązane” lub „Zamknięte” na status otwarty.

Typ zdarzenia inferred
Powiązano ze zgłoszeniem problemu
Zdarzenie występuje, gdy incydent zostaje powiązany ze zgłoszeniem typu „Problem” na potrzeby analizy przyczyn źródłowych. Jest rejestrowane, gdy utworzono powiązanie „dotyczy” lub „spowodowane przez” ze zgłoszeniem typu „Problem”.
Dlaczego to ważne

Śledzenie tego powiązania pozwala ocenić, jak skutecznie organizacja przechodzi od ograniczania skutków incydentu do analizy przyczyn źródłowych i zapobiegania problemom.

Skąd pobrać

To jawne zdarzenie zapisywane w historii powiązań zgłoszenia. Każde utworzone powiązanie ma timestamp. Można filtrować powiązania ze zgłoszeniami typu „Problem”.

Rejestrowanie

Użyj timestampu utworzenia powiązania ze zgłoszeniem typu „Problem”.

Typ zdarzenia explicit
Przekazano do zespołu specjalistycznego
Oznacza przekazanie incydentu do zespołu specjalistycznego, na przykład wsparcia drugiej linii lub zespołu programistycznego, w celu uzyskania zaawansowanej pomocy. Zdarzenie jest wywnioskowane na podstawie zmiany niestandardowego pola „Zespół wsparcia” lub konkretnego ponownego przypisania.
Dlaczego to ważne

Pozwala wskazać incydenty wymagające specjalistycznej wiedzy i śledzić przepływ pracy między poziomami wsparcia. Ułatwia wykrywanie wąskich gardeł w zespołach specjalistycznych i analizę wzorców eskalacji.

Skąd pobrać

Zdarzenie jest wywnioskowane z historii zgłoszenia na podstawie zmian niestandardowego pola określającego przypisany zespół lub zmiany pola „Osoba przypisana” na członka znanej grupy specjalistycznej.

Rejestrowanie

Wykryj zmianę niestandardowego pola „Przypisany zespół” lub określone zmiany osoby przypisanej.

Typ zdarzenia inferred
Przypisano incydent
To działanie oznacza pierwsze przypisanie incydentu agentowi lub grupie wsparcia. Jest rejestrowane przy pierwszym uzupełnieniu pola „Osoba przypisana” lub „Przypisana grupa”.
Dlaczego to ważne

Mierzy czas pierwszej odpowiedzi i przypisania, które są ważnymi elementami wskaźników SLA. Pomaga wykryć opóźnienia przed rozpoczęciem aktywnej analizy.

Skąd pobrać

Zdarzenie jest wywnioskowane z historii zgłoszenia na podstawie pierwszej zmiany pola „Osoba przypisana”, gdy jego poprzednią wartością było „Nieprzypisane”.

Rejestrowanie

Wykryj pierwszą aktualizację pola „Osoba przypisana” w historii zgłoszenia.

Typ zdarzenia inferred
Ustalono priorytet incydentu
Oznacza ustawienie priorytetu lub ważności incydentu, które określają jego pilność i wpływ na działalność firmy. Zdarzenie jest zwykle wywnioskowane na podstawie pierwszego uzupełnienia lub zaktualizowania pól „Priorytet” lub „Ważność” po utworzeniu zgłoszenia.
Dlaczego to ważne

Śledzenie priorytetyzacji pomaga ocenić, czy incydenty są analizowane szybko i według spójnych zasad. Opóźnienia na tym etapie mogą bezpośrednio wpływać na obliczenia SLA i przydział zasobów.

Skąd pobrać

Zdarzenie jest wywnioskowane z historii zgłoszenia, w której zapisywane są zmiany wszystkich pól. Należy znaleźć pierwszą aktualizację pola „Priorytet” lub niestandardowego pola „Ważność” po utworzeniu zgłoszenia.

Rejestrowanie

Wykryj pierwszą zmianę pola „Priorytet” w historii zgłoszenia.

Typ zdarzenia inferred
Zastosowano obejście
Oznacza wdrożenie tymczasowej poprawki, która przywraca usługę na czas opracowywania trwałego rozwiązania. Zdarzenie można wywnioskować na podstawie zmiany statusu lub konkretnego komentarza.
Dlaczego to ważne

Pomiar czasu potrzebnego na wdrożenie obejścia jest ważnym wskaźnikiem szybkości przywracania usługi. Pozwala odróżnić tymczasowe ograniczenie skutków problemu od jego trwałego rozwiązania.

Skąd pobrać

Zdarzenie jest często wywnioskowane. Może oznaczać zmianę statusu na „Zastosowano obejście” lub dodanie publicznego komentarza zawierającego określone słowa kluczowe, na przykład „obejście”.

Rejestrowanie

Wykryj określoną zmianę statusu lub słowo kluczowe w komentarzu.

Typ zdarzenia inferred
Zalecane Opcjonalne

Instrukcje pobierania danych

Jak pobrać dane z Jira Service Management

Gotowi do rozpoczęcia?

Skorzystaj z tego szablonu danych, aby usprawnić obsługę incydentów, wskazać nieefektywności i skrócić czas rozwiązywania. Zacznij usprawniać proces już dziś.

Usprawnij obsługę incydentów i rozwiązuj je szybciej

Skróć MTTR o 35% i zwiększ zadowolenie użytkowników dzięki sprawniejszym procesom.

Rozpocznij bezpłatny okres próbny

Karta kredytowa nie jest wymagana • Konfiguracja zajmuje 5 minut