Szablon danych do analizy obsługi incydentów
Szablon danych do analizy obsługi incydentów
- Zalecane atrybuty do zebrania
- Najważniejsze działania do śledzenia
- Wskazówki dotyczące pobierania danych z Jira Service Management
Atrybuty obsługi incydentów
| 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
|
|||
Działania w procesie obsługi incydentów
| 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
|
|||
Instrukcje pobierania danych
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.
Karta kredytowa nie jest wymagana • Konfiguracja zajmuje 5 minut