Szablon danych do zarządzania problemami
Szablon danych do zarządzania problemami
- Zalecane atrybuty do szczegółowej analizy
- Etapy procesu do uwzględnienia w dzienniku zdarzeń
- Wskazówki techniczne dotyczące ekstrakcji danych
Atrybuty zarządzania problemami
| 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
|
|||
Działania w procesie zarządzania problemami
| 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
|
|||
Instrukcje ekstrakcji danych
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.
Nie trzeba podawać danych karty kredytowej. Konfiguracja zajmuje kilka minut.