Szablon danych do zarządzania problemami

Jira Service Management
Szablon danych do zarządzania problemami

Szablon danych do zarządzania problemami

Ten szablon pomaga analizować workflow zarządzania usługami IT w Jira Service Management. Wskazuje najważniejsze dane i etapy procesu, które warto uwzględnić. Zawiera uporządkowany przegląd atrybutów i działań potrzebnych do zrozumienia, jak zespół obsługuje problemy i analizuje ich przyczyny źródłowe. Skorzystaj z tych wskazówek, aby usprawnić zbieranie danych i uzyskać praktyczne wnioski z analiz process mining.
  • Zalecane atrybuty do szczegółowej analizy
  • Etapy procesu do uwzględnienia w dzienniku zdarzeń
  • Wskazówki techniczne dotyczące ekstrakcji danych
Pierwszy raz spotykają się Państwo z dziennikiem zdarzeń? Dowiedz się jak utworzyć dziennik zdarzeń na potrzeby process mining.

Atrybuty zarządzania problemami

Poniżej przedstawiono zalecane pola danych, które warto uwzględnić w dzienniku zdarzeń, aby dokładnie przeanalizować cykl obsługi problemu.
5 Wymagane 5 Zalecane 10 Opcjonalne
Nazwa Opis
Aktywność
ActivityName
Działanie lub zmiana statusu zgłoszenia problemu.
Opis

Ten atrybut zawiera nazwę zdarzenia lub przejścia między stanami w cyklu obsługi problemu. Przykłady: „Zarejestrowanie problemu”, „Zmiana statusu na analizowany” lub „Ustalenie przyczyny źródłowej”.

Jest niezbędny do mapowania przebiegu procesu i ustalenia kolejności kroków prowadzących do rozwiązania problemu. W process mining aktywności tworzą węzły mapy procesu.

Dlaczego to ważne

Określa kroki na mapie procesu i umożliwia analizę wariantów procesu.

Skąd pobrać

Dziennik zmian Jira (History) lub przejścia między statusami zgłoszenia

Przykłady
Utworzenie zgłoszenia problemuRozpoczęcie analizyUstalenie przyczyny źródłowejAktualizacja obejścia problemuZamknięcie zgłoszenia problemu
Ostatnia aktualizacja danych
LastDataUpdate
Znacznik czasu ekstrakcji danych lub ich ostatniego odświeżenia.
Opis

Informuje, kiedy zbiór danych został ostatnio zsynchronizowany z działającym środowiskiem Jira Service Management. Dzięki temu analitycy wiedzą, jak aktualne są dane.

Pozwala sprawdzić, czy analiza odzwierciedla najnowszy stan procesu, i wykryć ewentualne opóźnienia w dostępności danych.

Dlaczego to ważne

Pozwala ocenić aktualność danych i zwiększa zaufanie do wyników analizy.

Skąd pobrać

Znacznik czasu ETL

Przykłady
2023-11-01T12:00:00Z2023-11-02T00:00:00Z
System źródłowy
SourceSystem
Nazwa systemu, z którego pochodzą dane.
Opis

Wskazuje system, z którego wyodrębniono dane o procesie. W tym przypadku wartością jest zawsze „Jira Service Management”.

Ten atrybut jest szczególnie przydatny w środowiskach korzystających z wielu systemów, ponieważ pozwala odróżnić źródła danych. W tym widoku służy głównie jako stały identyfikator pochodzenia danych.

Dlaczego to ważne

Informuje o pochodzeniu danych, zwłaszcza gdy są łączone z danymi z innych systemów zarządzania usługami IT.

Skąd pobrać

Wartość wpisana na stałe lub konfiguracja systemu

Przykłady
Jira Service ManagementJira CloudJSM-Prod
Zgłoszenie problemu
ProblemKey
Unikalny identyfikator przypisany zgłoszeniu problemu w Jira Service Management.
Opis

Ten atrybut pełni funkcję głównego identyfikatora sprawy w analizie process mining. Jest to unikalny klucz, na przykład PM-1001, generowany przez Jira Service Management podczas tworzenia zgłoszenia problemu.

Służy do grupowania wszystkich powiązanych aktywności, zmian statusu i aktualizacji w jedną instancję procesu od początku do końca. Analiza tego atrybutu pozwala zwizualizować cały cykl obsługi problemu, od jego wykrycia, przez analizę, aż po zamknięcie.

Dlaczego to ważne

To podstawowy identyfikator potrzebny do odtworzenia przebiegu procesu i śledzenia poszczególnych zgłoszeń problemów.

Skąd pobrać

Tabela zgłoszeń, pole „Key” lub „Issue Key”

Przykłady
PM-1023PM-4099PRB-3321PM-5001
Znacznik czasu
EventTimestamp
Dokładna data i godzina wystąpienia aktywności.
Opis

Ten atrybut zapisuje dokładny moment wystąpienia aktywności. Służy do chronologicznego porządkowania zdarzeń i obliczania czasu między kolejnymi krokami.

Dokładne znaczniki czasu są niezbędne do obliczania czasu realizacji, na przykład od „Zarejestrowania problemu” do „Ustalenia przyczyny źródłowej”, oraz do analizy przepustowości procesu w czasie.

Dlaczego to ważne

Umożliwia obliczanie wszystkich czasowych KPI i prawidłowe porządkowanie zdarzeń.

Skąd pobrać

Data utworzenia wpisu w dzienniku zmian Jira lub data utworzenia zgłoszenia

Przykłady
2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:20:00Z
Kategoria przyczyny źródłowej
RootCauseCategory
Klasyfikacja przyczyny źródłowej problemu.
Opis

Określa kategorię błędu technicznego lub problemu z procesem, który spowodował problem, na przykład „Błąd oprogramowania”, „Błąd człowieka” lub „Awaria sprzętu”. W Jira Service Management jest to często pole niestandardowe.

Atrybut ten zasila dashboard „Rozkład kategorii przyczyn źródłowych” i pomaga podejmować decyzje o inwestycjach w infrastrukturę lub szkolenia, które mogą zapobiec ponownemu wystąpieniu problemu.

Dlaczego to ważne

Pomaga wykrywać problemy systemowe i planować działania zapobiegawcze.

Skąd pobrać

Pole niestandardowe „Root Cause” lub „Root Cause Category”

Przykłady
Błąd oprogramowaniaBłąd konfiguracjiProblem z wydajnościąProblem po stronie dostawcy
Podsumowanie problemu
ProblemSummary
Krótki opis lub tytuł rekordu problemu.
Opis

Zawiera krótkie podsumowanie rekordu problemu. Choć jest to przede wszystkim tekst, dostarcza analitykom kontekstu podczas przeglądania poszczególnych spraw w narzędziu process mining.

Umożliwia wyszukiwanie słów kluczowych i jakościową analizę rodzajów zgłaszanych problemów.

Dlaczego to ważne

Uzupełnia identyfikator sprawy o czytelny dla użytkownika opis.

Skąd pobrać

Pole zgłoszenia „Summary”

Przykłady
Przekroczony limit czasu połączenia z bazą danych w regionie UENagły wzrost opóźnień w działaniu poczty e-mailZablokowana kolejka przetwarzania zamówień
Priorytet
Priority
Poziom ważności przypisany do rekordu problemu.
Opis

Określa pilność i wpływ problemu. Zwykle przyjmuje wartości od „Niski” do „Krytyczny”. Pole to pozwala podzielić wyniki analizy i sprawdzić, czy problemy o wysokim priorytecie są rozwiązywane w terminach określonych w SLA.

Analiza tego atrybutu w dashboardzie „Zgodność z SLA i trendy dotyczące celów” pozwala sprawdzić, czy krytyczne ryzyka biznesowe otrzymują właściwy priorytet.

Dlaczego to ważne

Pozwala porównywać wyniki procesu według ważności dla firmy.

Skąd pobrać

Pole zgłoszenia „Priority”

Przykłady
NajwyższyWysokiŚredniNiski
Przypisana grupa wsparcia
SupportGroup
Zespół techniczny lub grupa, której obecnie przypisano analizę problemu.
Opis

Wskazuje zespół odpowiedzialny za rekord problemu w chwili danego zdarzenia. W Jira Service Management odpowiada za to zwykle pole „Component” lub pole niestandardowe, takie jak „Support Group”.

Ten atrybut jest niezbędny w dashboardzie „Wąskie gardła przy przekazywaniu spraw między grupami wsparcia”. Analitycy mogą sprawdzić, jak problemy przechodzą między zespołami i gdzie najdłużej pozostają.

Dlaczego to ważne

Niezbędne do analizy procesów w organizacji i wykrywania utrudnień we współpracy między zespołami.

Skąd pobrać

Pole zgłoszenia „Component” lub pole niestandardowe „Support Group”

Przykłady
Administracja bazami danychOperacje siecioweWsparcie aplikacji, poziom 2
Użytkownik
UserKey
Unikalny identyfikator lub nazwa użytkownika, który wykonał daną czynność.
Opis

Wskazuje osobę lub konto systemowe odpowiedzialne za wykonanie danej czynności. Może to być osoba przypisana do zgłoszenia, która zaktualizowała rekord, albo autor zmiany statusu.

Dane te służą do analizy wykorzystania zasobów, wykrywania wąskich gardeł przy przekazywaniu spraw między użytkownikami oraz ustalania odpowiedzialności w procesie zarządzania problemami.

Dlaczego to ważne

Niezbędne do analizy przekazywania spraw, rozdziału obowiązków i obciążenia zasobów.

Skąd pobrać

Pole Jira „author” w dzienniku zmian lub pole „assignee” w zgłoszeniu

Przykłady
j.smithsystem_automationm.doe
Czy problem został ponownie otwarty
IsReopened
Flaga informująca, czy problem ponownie otwarto po zamknięciu.
Opis

Flaga logiczna ustawiana na „prawda”, gdy status rekordu problemu zmienia się z zamkniętego na otwarty. Dane te służą do analizy „Odsetka ponownie otwartych problemów”.

Częste ponowne otwieranie problemów może wskazywać na niską jakość trwałych poprawek lub niewystarczające procedury weryfikacji.

Dlaczego to ważne

Wskaźnik jakości pokazujący skuteczność poprawek.

Skąd pobrać

Ustalane na podstawie zmian statusu

Przykłady
truefalse
Data utworzenia
CreatedDate
Data utworzenia rekordu problemu.
Opis

Znacznik czasu pierwszego zarejestrowania problemu w systemie. Znacznik czasu zdarzenia określa, kiedy wykonano daną czynność, natomiast ten atrybut służy często do filtrowania danych na wysokim poziomie, na przykład „Pokaż wszystkie problemy utworzone w pierwszym kwartale”.

Jest punktem odniesienia w analizie wieku spraw.

Dlaczego to ważne

Data odniesienia do analizy wieku spraw i liczby nowych zgłoszeń.

Skąd pobrać

Pole zgłoszenia „Created”

Przykłady
2023-01-012023-06-15
Dostępne obejście problemu
WorkaroundDetails
Informuje, czy dla problemu udokumentowano obejście.
Opis

Informuje, czy opis tymczasowego obejścia istnieje lub został opublikowany. Pozwala śledzić „Czas publikacji obejścia”.

Analiza tego pola pokazuje, jak szybko zespół może przywrócić stabilność usługi, zanim znajdzie trwałe rozwiązanie.

Dlaczego to ważne

Pozwala mierzyć, jak szybko firma otrzymuje tymczasowe rozwiązanie problemu.

Skąd pobrać

Pole niestandardowe „Workaround”

Przykłady
Uruchom ponownie usługęWyczyść pamięć podręczną przeglądarkiNie podano
Kod rozwiązania
ResolutionCode
Kod określający sposób rozwiązania problemu.
Opis

Określa końcowy wynik obsługi problemu, na przykład „Naprawiono”, „Nie będzie naprawiane”, „Duplikat” lub „Nie udało się odtworzyć”.

Pozwala odróżnić problemy rozwiązane od zamkniętych z powodów administracyjnych. Dzięki temu obliczenia KPI, takie jak „Średni czas do ustalenia przyczyny źródłowej”, są dokładniejsze.

Dlaczego to ważne

Pozwala odróżnić skuteczne naprawy od zamknięć administracyjnych.

Skąd pobrać

Pole zgłoszenia „Resolution”

Przykłady
ZakończonoNie będzie realizowaneDuplikatNie udało się odtworzyć
Liczba powiązanych incydentów
LinkedIncidentCount
Liczba incydentów powiązanych z tym rekordem problemu.
Opis

Liczba zgłoszeń incydentów powiązanych z rekordem problemu. Atrybut ten pokazuje skalę wpływu problemu na użytkowników.

Jest wykorzystywany w KPI „Liczba powiązań incydentów z problemami”, aby nadawać priorytet problemom generującym najwięcej zgłoszeń do wsparcia.

Dlaczego to ważne

Pozwala określić wpływ na firmę na podstawie liczby incydentów.

Skąd pobrać

Liczba powiązań w tabeli „issuelinks”, gdzie typ to „Problem/Incident”

Przykłady
011550
Powiązane zgłoszenie zmiany
LinkedChangeRequest
Identyfikator zgłoszenia zmiany powiązanego z tym problemem.
Opis

Przechowuje identyfikator zgłoszenia zmiany (RFC) utworzonego w celu wdrożenia trwałej poprawki. To powiązanie jest niezbędne w dashboardzie „Opóźnienie w rozpoczęciu realizacji zgłoszenia zmiany”.

Łączy proces zarządzania problemami z procesem zarządzania zmianami i umożliwia analizę obu procesów.

Dlaczego to ważne

Łączy analizę problemu z jego usunięciem w procesie zarządzania zmianami.

Skąd pobrać

Powiązania zgłoszenia, których typ to „is fixed by” lub podobny

Przykłady
CR-404CHG-1099CR-5512
Przeprowadzenie przeglądu po wdrożeniu
ReviewStatus
Informuje, czy przeprowadzono przegląd po wdrożeniu (PIR).
Opis

Informuje, czy w sprawie odnotowano czynność „Przegląd po wdrożeniu” lub ustawiono odpowiednią flagę. Dane te są niezbędne w dashboardzie „Zgodność z wymogiem przeglądu po wdrożeniu”.

Pozwalają sprawdzić, czy organizacja spełnia wymagania dotyczące nadzoru i ciągłego doskonalenia.

Dlaczego to ważne

Wskaźnik zgodności pokazujący, czy organizacja wyciąga wnioski z doświadczeń.

Skąd pobrać

Pole niestandardowe „PIR Status” lub wystąpienie czynności „PIR”

Przykłady
UkończonoOczekujeNie dotyczy
Status naruszenia SLA
SlaBreachStatus
Informuje, czy w przypadku rekordu problemu przekroczono uzgodniony poziom usług.
Opis

Pole logiczne lub status wskazujący, czy czas rozwiązania problemu przekroczył uzgodniony termin. Dane te są wykorzystywane w dashboardzie „Zgodność z SLA i trendy dotyczące celów”.

Wyróżnia sprawy, które mogą narazić organizację na ryzyko braku zgodności lub kary.

Dlaczego to ważne

Niezbędne do monitorowania zgodności i wyników.

Skąd pobrać

Logika pola SLA w Jira Service Management

Przykłady
DotrzymanoPrzekroczonoWstrzymano
Zgłaszający
ReporterName
Użytkownik, który pierwotnie zarejestrował problem.
Opis

Wskazuje osobę, która utworzyła rekord problemu. Nie musi to być osoba, której przypisano zgłoszenie. Analiza zgłaszających pomaga ustalić, skąd pochodzą wykryte problemy, na przykład od pracowników Service Desk lub administratorów systemu.

Uzupełnia analizę „Wykrywanie proaktywne a reaktywne”.

Dlaczego to ważne

Wskazuje źródło zgłoszenia problemu.

Skąd pobrać

Pole zgłoszenia „Reporter”

Przykłady
monitoring_servicehelpdesk_leadnetwork_admin
Źródło wykrycia
DetectionSource
Sposób wykrycia problemu, na przykład proaktywny lub reaktywny.
Opis

Wskazuje, w jaki sposób wykryto problem. Typowe wartości to „Proaktywny monitoring”, „Zgłoszenie z Service Desk” lub „Powiadomienie od dostawcy”.

Atrybut ten służy w dashboardzie „Wykrywanie proaktywne a reaktywne” do oceny dojrzałości procesu zarządzania problemami.

Dlaczego to ważne

Pozwala ocenić dojrzałość procesu i skuteczność systemów monitorowania.

Skąd pobrać

Pole niestandardowe „Source” lub „Detection Source”

Przykłady
Proaktywny monitoringEskalacja incydentuPowiadomienie od dostawcy
Wymagane Zalecane Opcjonalne

Działania w procesie zarządzania problemami

Poniżej przedstawiono najważniejsze kroki i etapy procesu, które warto uwzględnić w dzienniku zdarzeń, aby prawidłowo odkryć przebieg rozwiązywania problemów.
8 Zalecane 6 Opcjonalne
Działanie Opis
Aktualizacja obejścia problemu
Uzupełnienie lub aktualizacja pola tekstowego „Workaround”. To zdarzenie oznacza udokumentowanie tymczasowego rozwiązania.
Dlaczego to ważne

Mierzy czas potrzebny na ograniczenie skutków problemu dla firmy. Jest niezbędne do obliczania KPI „Czas do udostępnienia obejścia problemu”.

Skąd pobrać

Historia zgłoszenia Jira: zmiana pola „Workaround” (wartość nie jest pusta)

Rejestrowanie

Rejestrowane po zmianie pola Workaround

Typ zdarzenia explicit
Powiązanie incydentu z problemem
Powiązanie zgłoszenia incydentu ze zgłoszeniem problemu. Informacja o tym jest zapisywana w tabeli powiązań zgłoszeń lub w ich historii.
Dlaczego to ważne

Pozwala określić wpływ i zakres problemu. Jest niezbędne do obliczania KPI „Głębokość powiązań incydentów z problemami” i ustalania priorytetów na podstawie wpływu na biznes.

Skąd pobrać

Powiązania zgłoszeń Jira: utworzenie powiązania typu „causes” lub „relates to”

Rejestrowanie

Rejestrowane po utworzeniu powiązania między zgłoszeniami

Typ zdarzenia explicit
Przypisanie do grupy wsparcia
Przypisanie zgłoszenia problemu do konkretnego zespołu technicznego lub grupy wsparcia. Zmianę można śledzić w niestandardowym polu „Support Group” albo w polu „Assignee”, jeśli grupy nie są używane.
Dlaczego to ważne

Niezbędne do analizy przekazań i wąskich gardeł między zespołami. Częste przekazywanie może wskazywać na nieefektywne kierowanie zgłoszeń.

Skąd pobrać

Historia zgłoszenia Jira: zmiana pola „Support Group” lub „Assignee”

Rejestrowanie

Rejestrowane po zmianie pola przypisania

Typ zdarzenia explicit
Rozpoczęcie analizy
Zmiana statusu problemu na aktywny etap analizy, na przykład „Under Investigation” lub „In Progress”. Oznacza początek aktywnej pracy nad problemem.
Dlaczego to ważne

Rozpoczyna pomiar czasu analizy. Pomaga odróżnić czas oczekiwania w kolejce od faktycznej pracy nad problemem.

Skąd pobrać

Historia zgłoszenia Jira: zmiana statusu na „Under Investigation” lub „In Progress”

Rejestrowanie

Porównanie aktualizacji pola statusu

Typ zdarzenia inferred
Ustalenie przyczyny źródłowej
Moment formalnego zapisania przyczyny problemu. Można go określić na podstawie zmiany statusu na „Root Cause Identified” lub uzupełnienia pola „Root Cause”.
Dlaczego to ważne

Ważny etap kończący analizę. Niezbędny do obliczenia „Średniego czasu do ustalenia przyczyny źródłowej”.

Skąd pobrać

Historia zgłoszenia Jira: zmiana statusu na „Root Cause Identified” LUB uzupełnienie pola „Root Cause”

Rejestrowanie

Porównanie pola statusu lub sprawdzenie, czy pole zostało uzupełnione

Typ zdarzenia inferred
Utworzenie zgłoszenia problemu
Pierwsze zdarzenie, czyli utworzenie zgłoszenia problemu w systemie. Jest ono wyraźnie zapisane w historii zgłoszenia jako znacznik czasu utworzenia.
Dlaczego to ważne

Wyznacza początek cyklu obsługi problemu i umożliwia analizę liczby zgłoszeń. Jest niezbędne do obliczania przepustowości procesu i tempa napływu zgłoszeń.

Skąd pobrać

Tabela zgłoszeń Jira: znacznik czasu w polu Created Date lub karta History: zdarzenie Issue Created

Rejestrowanie

Rejestrowane po zatwierdzeniu operacji utworzenia zgłoszenia

Typ zdarzenia explicit
Weryfikacja rozwiązania
Potwierdzenie, że poprawka skutecznie rozwiązała problem. Można je rozpoznać po zmianie statusu na „Resolved” lub określony status „Verified”.
Dlaczego to ważne

Kontrola jakości potwierdzająca skuteczność poprawki. Opóźnienia na tym etapie mogą wskazywać na wąskie gardła w testach lub akceptacji użytkowników.

Skąd pobrać

Historia zgłoszenia Jira: zmiana statusu na „Resolved” lub „Verified”

Rejestrowanie

Porównanie aktualizacji pola statusu

Typ zdarzenia inferred
Zamknięcie zgłoszenia problemu
Ostateczne zakończenie cyklu obsługi problemu. Jest rejestrowane wprost po zmianie statusu na „Closed”.
Dlaczego to ważne

Definitywny koniec instancji procesu. Jest niezbędny do obliczenia całkowitego czasu realizacji i odsetka zamkniętych zgłoszeń.

Skąd pobrać

Historia zgłoszenia Jira: zmiana statusu na „Closed”

Rejestrowanie

Rejestrowane po zmianie statusu na Closed

Typ zdarzenia explicit
Naruszenie SLA
Zdarzenie oznaczające przekroczenie ustalonego czasu rozwiązania problemu określonego w umowie SLA. Wykrywa się je, porównując docelowy termin SLA z datą rozwiązania.
Dlaczego to ważne

Niezbędne do raportowania zgodności. Pomaga ustalić, które priorytety lub kategorie najczęściej nie mieszczą się w wyznaczonych terminach.

Skąd pobrać

Dzienniki SLA w Jira Service Management: „Time to Resolution” przekracza cel lub jest obliczane na podstawie danych

Rejestrowanie

Ustal na podstawie danych z pola SLA lub porównaj Due Date z Resolution Date

Typ zdarzenia calculated
Ponowne otwarcie problemu
Zmiana statusu problemu z „Resolved” lub „Closed” z powrotem na status aktywny. Może oznaczać nieskuteczną poprawkę lub odrzucenie rozwiązania.
Dlaczego to ważne

Podstawowy miernik jakości. Wysoki odsetek ponownie otwieranych zgłoszeń może wskazywać na nieskuteczną analizę przyczyn źródłowych lub testy.

Skąd pobrać

Historia zgłoszenia Jira: zmiana statusu z „Closed”/„Resolved” na „Open”/„In Progress”

Rejestrowanie

Porównanie sekwencji zmian pola statusu

Typ zdarzenia inferred
Powiązanie z wnioskiem o zmianę
Powiązanie wniosku o zmianę (RFC) ze zgłoszeniem problemu. Oznacza rozpoczęcie procesu wdrażania trwałej poprawki.
Dlaczego to ważne

Mierzy czas od ustalenia przyczyny do rozpoczęcia działań naprawczych. Umożliwia analizę KPI „Opóźnienie przejścia do zarządzania zmianą”.

Skąd pobrać

Powiązania zgłoszeń Jira: utworzenie powiązania typu „is fixed by” lub powiązanie ze zgłoszeniem typu „Change”

Rejestrowanie

Rejestrowane po utworzeniu powiązania ze zgłoszeniem typu Change

Typ zdarzenia explicit
Przegląd po wdrożeniu
Przegląd przeprowadzany po wdrożeniu poprawki. Można go wykryć po zmianie statusu na „In Review” lub aktualizacji pól dotyczących PIR.
Dlaczego to ważne

Działanie związane ze zgodnością, które zapewnia zapisanie wniosków. Umożliwia analizę „Zgodności z wymogiem przeglądu po wdrożeniu”.

Skąd pobrać

Historia zgłoszenia Jira: zmiana statusu na „In Review” LUB aktualizacja pola „PIR Notes”

Rejestrowanie

Porównanie pola statusu lub aktualizacji pól PIR

Typ zdarzenia inferred
Wdrożenie trwałej poprawki
Przejście statusu oznaczające wdrożenie rozwiązania. Zwykle można je rozpoznać po zmianie statusu na „Implementing” lub „Fixed”.
Dlaczego to ważne

Oznacza zakończenie technicznych prac naprawczych. Służy do pomiaru czasu wdrożenia.

Skąd pobrać

Historia zgłoszenia Jira: zmiana statusu na „Implemented”, „Pending Verification” lub „Fixed”

Rejestrowanie

Porównanie aktualizacji pola statusu

Typ zdarzenia inferred
Zmiana priorytetu problemu
Zmiana pola Priority w zgłoszeniu problemu. Można ją wykryć, monitorując zmiany pola „Priority” w historii zgłoszenia.
Dlaczego to ważne

Wskazuje na eskalację lub obniżenie priorytetu problemu. Analiza pomaga ocenić trafność wstępnej klasyfikacji i czas obsługi zaległych zgłoszeń o wysokim priorytecie.

Skąd pobrać

Historia zgłoszenia Jira: zmiana pola „Priority” z poprzedniej wartości na nową

Rejestrowanie

Rejestrowane po aktualizacji pola Priority

Typ zdarzenia explicit
Zalecane Opcjonalne

Instrukcje ekstrakcji danych

Jak pobrać dane z Jira Service Management

Gotowi do rozpoczęcia?

Już dziś zamień dane dotyczące zarządzania problemami w praktyczne wnioski. Pobierz przewodnik lub skontaktuj się z naszym zespołem wsparcia, aby rozpocząć analizę process mining.

Usprawnij przepływ zarządzania problemami

Skróć czas realizacji o 30% i zwiększ stabilność środowiska IT.

Rozpocznij okres próbny

Nie trzeba podawać danych karty kredytowej. Konfiguracja zajmuje kilka minut.