> Ciągłe doskonalenie procesów > Zarządzanie zgłoszeniami serwisowymi > Jira Service Management > Szablon danych

Szablon danych do analizy obsługi zgłoszeń serwisowych

Jira Service Management

← Wróć do przewodnika ulepszania procesów

Atrybuty obsługi zgłoszeń serwisowych(17) Działania w procesie obsługi zgłoszeń serwisowych(13) Instrukcje pobierania danych(3)

Szablon danych do analizy obsługi zgłoszeń serwisowych

Ten szablon pomaga uporządkować zbieranie danych potrzebnych do analizy procesu obsługi zgłoszeń serwisowych. Zawiera listę atrybutów do zebrania, działań do śledzenia oraz wskazówki dotyczące pobierania tych informacji z systemu. Ułatwia przygotowanie danych i pozwala lepiej zrozumieć przebieg operacji.

Zalecane atrybuty do szczegółowej analizy
Najważniejsze działania do śledzenia podczas odkrywania procesu
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.

Pobierz szablon

Atrybuty obsługi zgłoszeń serwisowych

Poniżej przedstawiono zalecane pola danych, które warto uwzględnić w dzienniku zdarzeń, aby kompleksowo analizować obsługę zgłoszeń serwisowych.

5 Wymagane 5 Zalecane 7 Opcjonalne

	Nazwa	Opis
	Czas rozpoczęcia EventTime	Dokładna data i godzina wystąpienia danej czynności lub zdarzenia.
Opis Czas rozpoczęcia, czyli znacznik czasu zdarzenia, wskazuje dokładny moment wykonania czynności. To ważny element analizy process mining, ponieważ określa kontekst czasowy całego procesu. Znacznik czasu służy do uporządkowania zdarzeń, obliczania czasu między czynnościami i całkowitego czasu obsługi sprawy oraz oceny wyników procesu względem celów czasowych, takich jak SLA. Bez dokładnych znaczników czasu nie można ustalić przebiegu procesu, wykryć opóźnień ani zmierzyć jego sprawności. Dlaczego to ważne Znacznik czasu pozwala uporządkować zdarzenia, obliczyć czas trwania i cykl obsługi oraz wykryć wąskie gardła procesu. Skąd pobrać To znacznik czasu przypisany do każdej zmiany statusu w dzienniku zmian zgłoszenia Jira. Czas utworzenia zgłoszenia znajduje się w polu „created”. Przykłady 2023-10-26T10:00:00Z2023-10-26T10:15:32Z2023-10-27T14:20:05Z
	Czynność ActivityName	Nazwa konkretnego zdarzenia lub zadania, które wystąpiło w cyklu życia zgłoszenia serwisowego.
Opis Ten atrybut opisuje czynność lub zmianę statusu, która nastąpiła w określonym momencie obsługi zgłoszenia serwisowego. Przykłady: „Utworzono zgłoszenie”, „Przypisano zgłoszenie”, „Wdrożono rozwiązanie” i „Zamknięto zgłoszenie”. Analiza kolejności i częstotliwości tych czynności stanowi podstawę process mining. Pozwala wizualizować mapy procesów, wykrywać wąskie gardła i odchylenia od standardowego workflow. Dzięki temu można ocenić sprawność procesu i jego zgodność z wymaganiami. Dlaczego to ważne Określa kolejne etapy procesu, umożliwiając wizualizację mapy procesu oraz analizę przebiegu workflow i odchyleń. Skąd pobrać Zwykle ustalany na podstawie historii zmian statusu zgłoszenia Jira. Każdy wpis dotyczący pola statusu w dzienniku zmian zgłoszenia odpowiada jednej czynności. Przykłady Wstępna ocena zgłoszeniaProśba o informacjeWdrożenie rozwiązaniaZgłoszenie serwisowe zamknięte
	Identyfikator zgłoszenia serwisowego ServiceRequestId	Unikalny identyfikator każdego zgłoszenia serwisowego, pełniący funkcję klucza głównego dla powiązanych zdarzeń.
Opis Identyfikator zgłoszenia serwisowego, w Jira często nazywany kluczem zgłoszenia (Issue Key), jednoznacznie wskazuje każde zgłoszenie przesłane przez użytkownika lub system. Łączy wszystkie kolejne zdarzenia, od rejestracji po ostateczne zamknięcie, dzięki czemu można przeanalizować cały przebieg obsługi zgłoszenia. W process mining ten identyfikator jest niezbędny do powiązania zdarzeń z konkretną sprawą. Dzięki niemu każda czynność, zmiana statusu i znacznik czasu są przypisane do właściwego zgłoszenia, tworząc spójny przypadek do analizy. Dlaczego to ważne Ten identyfikator sprawy łączy wszystkie powiązane czynności w jeden przepływ procesu od początku do końca, umożliwiając jego analizę. Skąd pobrać To pole „key” zgłoszenia w Jira Service Management. Przykłady SR-2023-001IT-45892HELP-105
	Data ostatniej aktualizacji danych LastDataUpdate	Znacznik czasu wskazujący, kiedy dane zostały ostatnio odświeżone z systemu źródłowego.
Opis Ten atrybut zapisuje datę i godzinę ostatniego pobrania danych z Jira Service Management. Informuje, jak aktualne są dane wykorzystywane w analizie, dashboardach i KPI. Przy podejmowaniu decyzji warto wiedzieć, kiedy dane zostały zebrane. Znacznik czasu pozwala ustalić, czy analizowane informacje są bieżące, czy pochodzą z wcześniejszego okresu. Ma to wpływ na aktualność wniosków. Dlaczego to ważne Informuje o aktualności danych i pozwala ocenić, czy analiza opiera się na najnowszych informacjach. Skąd pobrać To pole metadanych generowane i zapisywane przez narzędzie lub skrypt do ekstrakcji danych po zakończeniu działania. Przykłady 2023-10-27T02:00:00Z2023-10-28T02:00:00Z
	System źródłowy SourceSystem	System, z którego pobrano dane zgłoszeń serwisowych.
Opis Ten atrybut wskazuje źródło danych, w tym przypadku Jira Service Management. Może się wydawać zbędny przy analizie danych z jednego źródła, ale jest niezbędny przy łączeniu danych o procesach z wielu systemów. Ułatwia prześledzenie pochodzenia danych i kontrolę ich jakości. Pozwala też filtrować i porównywać procesy obejmujące różne platformy. Dlaczego to ważne Wskazuje pochodzenie danych, co ma znaczenie dla zarządzania danymi i łączenia informacji o procesach z różnych systemów firmowych. Skąd pobrać Zwykle jest to stała wartość dodawana podczas ekstrakcji i transformacji danych, aby oznaczyć źródło zbioru. Przykłady Jira Service ManagementJiraSM
	Osoba przypisana Assignee	Użytkownik lub agent aktualnie przypisany do obsługi zgłoszenia serwisowego.
Opis Osoba przypisana odpowiada za kolejne działanie lub rozwiązanie zgłoszenia serwisowego. Wartość tego atrybutu może się zmieniać w trakcie obsługi zgłoszenia, gdy jest ono przekazywane między agentami lub zespołami. Atrybut ten służy do analizy obciążenia pracą, oceny wyników i zarządzania zasobami. Pozwala filtrować proces według agenta, porównywać czas rozwiązania zgłoszeń i wykrywać potrzeby szkoleniowe lub nierównomierne obciążenie, które prowadzi do powstawania wąskich gardeł. Dlaczego to ważne Atrybut ten pomaga analizować obciążenie agentów, oceniać ich wyniki i sprawdzać, jak przydzielane są zasoby. Skąd pobrać Odpowiada polu „assignee” w zgłoszeniu Jira. Przykłady Alice JohnsonBob WilliamsNieprzypisane
	Priorytet zgłoszenia RequestPriority	Priorytet przypisany do zgłoszenia serwisowego, na przykład niski, średni, wysoki lub krytyczny.
Opis Priorytet zgłoszenia określa jego pilność i wpływ na działalność firmy. Na tej podstawie ustala się kolejność obsługi, a często także docelowy czas rozwiązania i wymagania SLA. W analizie procesu priorytet pozwala podzielić zgłoszenia na grupy. Można porównać czas obsługi i realizację SLA dla poszczególnych poziomów priorytetu oraz sprawdzić, czy zgłoszenia o wysokim priorytecie są obsługiwane szybciej i zgodnie z założeniami. Pozwala to ocenić skuteczność ustalania priorytetów. Dlaczego to ważne Pozwala podzielić zgłoszenia na grupy i sprawdzić, czy te o wysokim priorytecie są obsługiwane szybciej i spełniają bardziej rygorystyczne wymagania dotyczące poziomu usług. Skąd pobrać Odpowiada polu „priority” w zgłoszeniu Jira. Przykłady NajwyższyWysokiŚredniNiski
	Status zgłoszenia RequestStatus	Bieżący status zgłoszenia serwisowego w jego cyklu życia.
Opis Ten atrybut określa bieżący stan zgłoszenia serwisowego, na przykład „Otwarte”, „W trakcie realizacji”, „Oczekiwanie na klienta” lub „Rozwiązane”. Pokazuje, na jakim etapie znajduje się zgłoszenie w danym momencie. Dziennik czynności przedstawia historię procesu, a bieżący status pomaga analizować otwarte sprawy i wykrywać te, które utknęły. Można na przykład sprawdzić zgłoszenia, które wyjątkowo długo mają status „Oczekiwanie na dostawcę”, i wskazać opóźnienia oraz zależności od podmiotów zewnętrznych. Dlaczego to ważne Pokazuje bieżący stan każdej sprawy, ułatwiając analizę pracy w toku oraz wykrywanie zgłoszeń, które utknęły lub długo pozostają otwarte. Skąd pobrać To pole „status” w zgłoszeniu Jira. Przykłady OtwarteW trakcie realizacjiOczekiwanie na klientaRozwiązane
	Termin realizacji SLA SlaDueDate	Docelowa data i godzina rozwiązania zgłoszenia serwisowego zgodnie z SLA.
Opis Termin realizacji SLA to obliczony znacznik czasu określający, do kiedy należy rozwiązać zgłoszenie. Zależy od priorytetu i typu zgłoszenia oraz zasad Service Level Agreement (SLA) skonfigurowanych w Jira Service Management. Atrybut ten jest podstawą dashboardu „Wyniki SLA dla zgłoszeń serwisowych” i KPI „Wskaźnik realizacji SLA”. Porównanie rzeczywistego czasu rozwiązania z terminem pozwala ustalić, czy zgłoszenie rozwiązano na czas, po terminie, czy też istnieje ryzyko naruszenia SLA. Dlaczego to ważne Stanowi punkt odniesienia przy ocenie wyników. Umożliwia obliczenie zgodności z SLA i pomaga ustalać priorytety pracy. Skąd pobrać Informacje o SLA są zarządzane w Jira Service Management i dostępne przez API. Często są przechowywane w polach niestandardowych, które aktualizują się dynamicznie. Przykłady 2023-10-28T16:00:00Z2023-11-01T09:00:00Z
	Typ zgłoszenia RequestType	Klasyfikacja zgłoszenia serwisowego, na przykład „Wniosek o dostęp” lub „Problem ze sprzętem”.
Opis Typ zgłoszenia określa jego charakter. To podstawowy wymiar analizy, ponieważ różne rodzaje zgłoszeń mogą wymagać innych sposobów rozwiązania, poziomów SLA i zasobów. Podział analizy procesu według typu zgłoszenia pozwala dostosować usprawnienia do konkretnych workflow. Wąskie gardło przy zgłoszeniu „Reset hasła” będzie inne niż przy „Przygotowaniu nowego serwera”. Atrybut ten pomaga też tworzyć przydatne dashboardy, na przykład „Jakość rozwiązywania według kategorii”. Dlaczego to ważne Atrybut ten pozwala porównywać procesy, obciążenie pracą i wyniki dla różnych kategorii zgłoszeń serwisowych. Skąd pobrać Często odpowiada polu „issuetype” w Jira lub niestandardowemu polu „Request Type” w Jira Service Management. Przykłady Wniosek o nowe kontoPomoc informatycznaWdrożenie nowego pracownika
	Czy zgłoszenie otwarto ponownie IsReopened	Wartość logiczna wskazująca, czy zgłoszenie serwisowe zostało ponownie otwarte po rozwiązaniu.
Opis Ten obliczany atrybut przyjmuje wartość prawda lub fałsz. Wartość prawda jest ustawiana, jeśli workflow zgłoszenia obejmuje czynność „Ponownie otwarto zgłoszenie”. Atrybut ustala się na podstawie kolejności czynności w każdej sprawie. Wskaźnik ten służy do obliczania KPI „Wskaźnik ponownego otwarcia zgłoszeń serwisowych” i zasilania dashboardu „Liczba ponownie otwartych zgłoszeń serwisowych”. Wysoki wskaźnik ponownego otwarcia może świadczyć o niskiej jakości rozwiązań za pierwszym razem, co prowadzi do ponownej pracy i spadku zadowolenia klientów. Analiza typów zgłoszeń i sposobów rozwiązania powiązanych z tym wskaźnikiem pomaga wskazać obszary wymagające poprawy. Dlaczego to ważne Bezpośrednio mierzy ponowną pracę i jakość rozwiązań za pierwszym razem, czyli wskaźniki skuteczności procesu i zadowolenia klientów. Skąd pobrać Obliczany podczas transformacji danych przez sprawdzenie, czy po zmianie statusu na „Rozwiązane” w historii czynności sprawy występuje przejście do statusu „Ponownie otwarte”. Przykłady truefalse
	Kanał Channel	Sposób przesłania zgłoszenia serwisowego, na przykład przez e-mail, portal lub API.
Opis Atrybut Kanał wskazuje, w jaki sposób zgłoszenie serwisowe trafiło do systemu. W Jira Service Management typowe kanały to portal klienta, e-mail lub zgłoszenie utworzone bezpośrednio przez agenta. Analiza procesu według kanału pomaga zrozumieć zachowania użytkowników i usprawnić obsługę. Może wykazać, że zgłoszenia z niektórych kanałów są rozwiązywane dłużej lub wymagają dodatkowych wyjaśnień. Może to wskazywać na potrzebę ulepszenia formularzy w portalu albo reguł przetwarzania wiadomości e-mail. Dane te można wykorzystać w dashboardzie „Trendy w obsłudze zgłoszeń serwisowych”. Dlaczego to ważne Pomaga sprawdzić, czy kanał zgłoszenia wpływa na czas rozwiązania, kompletność informacji lub ogólną sprawność procesu. Skąd pobrać Informacje te są dostępne w Jira Service Management w polu „Request channel type”. Dostęp do nich może wymagać odpowiednich uprawnień API lub użycia pola niestandardowego. Przykłady portale-mailapi
	Organizacja Organization	Organizacja klienta lub dział wewnętrzny, do którego należy zgłaszający.
Opis Ten atrybut przypisuje zgłaszających do organizacji lub działów. Jira Service Management ma wbudowaną funkcję „Organizations”, która pozwala agentom obsługiwać zgłoszenia od wielu klientów lub zespołów wewnętrznych. Analiza według organizacji dostarcza kontekstu biznesowego. Pomaga ustalić, którzy klienci lub działy korzystają z największej liczby zasobów wsparcia, które grupy regularnie zgłaszają problemy oraz czy SLA są dotrzymywane w różnych jednostkach organizacyjnych. Dlaczego to ważne Ułatwia analizę zapotrzebowania na obsługę i wyników według klienta lub działu wewnętrznego, dostarczając informacji przydatnych w działalności firmy. Skąd pobrać Dane pochodzą z pola „Organizations” przypisanego do zgłoszenia serwisowego w Jira Service Management. Przykłady Acme CorporationDział finansowyGlobal Tech Inc.
	Przypisany zespół AssignedTeam	Zespół lub grupa odpowiedzialna za obsługę zgłoszenia serwisowego.
Opis Ten atrybut wskazuje zespół przypisany do zgłoszenia. Zwykle jest to szersza jednostka niż pojedyncza osoba przypisana. Ułatwia analizę wyników zespołów, na przykład porównanie zespołu wsparcia pierwszej linii z zespołem operacji sieciowych. Atrybut ten przydaje się w dashboardach, takich jak „Obciążenie agentów i wskaźniki rozwiązywania zgłoszeń”. Pozwala agregować wyniki na poziomie zespołu, porównywać je na równych zasadach i oceniać wkład poszczególnych zespołów w obsługę zgłoszeń. Dlaczego to ważne Umożliwia analizę wyników i równoważenie obciążenia na poziomie zespołu lub działu, a nie tylko pojedynczego agenta. Skąd pobrać Może to być niestandardowe pole w Jira, na przykład „Team”, lub wartość ustalona na podstawie danych w profilu osoby przypisanej. Przykłady Wsparcie IT, poziom 1Zespół infrastrukturyWsparcie aplikacji
	Rozwiązanie Resolution	Końcowy wynik lub sposób zakończenia obsługi rozwiązanego zgłoszenia serwisowego.
Opis Pole Resolution wskazuje przyczynę zamknięcia zgłoszenia serwisowego. Typowe wartości to „Done”, „Won't Do”, „Duplicate” i „Cannot Reproduce”. Zawiera więcej informacji o zakończeniu sprawy niż sam status „Rozwiązane” lub „Zamknięte”. Analiza sposobów rozwiązania pomaga ocenić jakość i charakter wyników. Na przykład duża liczba zgłoszeń oznaczonych jako „Duplicate” może wskazywać na problem z ich przesyłaniem. Z kolei sprawdzenie, które rozwiązania prowadzą do ponownego otwarcia zgłoszeń, może ujawnić nieskuteczne działania. Dlaczego to ważne Pokazuje kontekst zakończenia zgłoszenia, ułatwiając ocenę jakości rozwiązania i wykrywanie przyczyn zamykania zgłoszeń. Skąd pobrać Odpowiada polu „resolution” w zgłoszeniu Jira. Zwykle jest ono ustawiane, gdy zgłoszenie przechodzi do statusu z kategorii „done”. Przykłady ZakończoneNie zostanie zrealizowaneDuplikatNaprawione
	Stan SLA SlaState	Informuje, czy zgłoszenie serwisowe spełnia wymagania SLA, narusza je czy nadal jest w trakcie realizacji.
Opis Stan SLA to obliczany atrybut, który klasyfikuje każde zgłoszenie serwisowe na podstawie dotrzymania terminu SLA. Możliwe wartości to „Dotrzymane”, „Naruszone” i „W trakcie realizacji”. Stan ustala się przez porównanie znacznika czasu rozwiązania z polem „SlaDueDate”. To podstawowy atrybut dashboardu „Wyniki SLA dla zgłoszeń serwisowych” i służy do obliczania KPI „Wskaźnik realizacji SLA”. Zapewnia czytelny, szybki podgląd zgodności z wymaganym poziomem usług, potrzebny do raportowania, zarządzania umowami i utrzymania jakości obsługi. Dlaczego to ważne Zapewnia czytelny i szybki obraz realizacji SLA, ważny przy ocenie jakości obsługi i zgodności z umowami. Skąd pobrać Obliczany podczas transformacji danych. Jeśli zgłoszenie rozwiązano przed terminem „SlaDueDate”, stan ma wartość „Dotrzymane”. W przeciwnym razie ma wartość „Naruszone”. Przykłady DotrzymaneNaruszoneW trakcie realizacji
	Zgłaszający Reporter	Użytkownik, który utworzył lub zgłosił zgłoszenie serwisowe.
Opis Zgłaszający to osoba, często użytkownik końcowy lub klient, która przesłała zgłoszenie serwisowe. Atrybut wskazuje osobę, która rozpoczęła proces. W analizie można go wykorzystać do badania wzorców zgłoszeń według użytkownika, działu lub grupy klientów. Pomaga odpowiedzieć na pytania: „Które działy przesyłają najwięcej zgłoszeń?” lub „Czy określeni użytkownicy regularnie zgłaszają te same problemy?”. Informacje te pomagają zapobiegać problemom i lepiej szkolić użytkowników. Dlaczego to ważne Wskazuje osobę zgłaszającą i pozwala analizować liczbę oraz rodzaje zgłoszeń według użytkownika, działu lub klienta. Skąd pobrać Odpowiada polu „reporter” w zgłoszeniu Jira. Przykłady Charles DarwinMarie CurieIsaac Newton

Wymagane Zalecane Opcjonalne

Działania w procesie obsługi zgłoszeń serwisowych

To najważniejsze kroki i kamienie milowe procesu, które warto zapisać w dzienniku zdarzeń, aby dokładnie odkryć i usprawnić proces.

5 Zalecane 8 Opcjonalne

	Działanie	Opis
	Przedstawienie rozwiązania	W wielu workflow service desk jest to osobny etap, na którym rozwiązanie zostaje przedstawione zgłaszającemu do akceptacji. Można go wywnioskować ze zmiany statusu zgłoszenia na „Pending Customer Acceptance” lub „Awaiting Confirmation”.
Dlaczego to ważne To działanie pozwala oddzielić czas oczekiwania na odpowiedź klienta po przedstawieniu rozwiązania od czasu pracy zespołu wewnętrznego. Skąd pobrać Działanie można wywnioskować z historii zgłoszenia. Znacznik czasu odpowiada chwili zmiany statusu na wartość oznaczającą oczekiwanie na weryfikację rozwiązania przez klienta. Rejestrowanie Znajdź znacznik czasu zmiany statusu na „Pending Customer Acceptance” lub równoważny. Typ zdarzenia inferred
	Przydzielenie zgłoszenia	To działanie następuje, gdy zgłoszenie serwisowe zostaje przypisane konkretnemu agentowi lub zespołowi do rozwiązania. Jira jawnie rejestruje zmiany pola „Assignee”, dzięki czemu można dokładnie ustalić czas przydzielenia.
Dlaczego to ważne To ważny punkt pomiaru czasu od wstępnej oceny do przydzielenia oraz rozkładu obciążenia agentów. Oznacza przejście od oczekiwania w kolejce do aktywnej obsługi. Skąd pobrać Działanie można odczytać z historii zgłoszenia, wyszukując pierwsze ustawienie pola „Assignee” lub jego zmianę z wartości oznaczającej brak przypisania. Rejestrowanie Użyj znacznika czasu pierwszej zmiany pola „Assignee” w historii zgłoszenia. Typ zdarzenia explicit
	Utworzenie zgłoszenia serwisowego	To działanie rozpoczyna cykl życia zgłoszenia serwisowego. Użytkownik składa je przez portal, e-mail lub inny kanał. W Jira zdarzenie jest rejestrowane w chwili utworzenia nowego zgłoszenia typu „Service Request”, wraz ze znacznikiem czasu utworzenia.
Dlaczego to ważne To główne zdarzenie rozpoczynające proces. Jest niezbędne do obliczenia całkowitego czasu obsługi oraz analizy liczby i rozkładu zgłoszeń w czasie. Skąd pobrać To jawnie rejestrowane zdarzenie w tabeli historii zgłoszenia. Znacznikiem czasu działania jest pole „created” w zgłoszeniu Jira. Rejestrowanie Użyj znacznika czasu utworzenia zgłoszenia z tabeli „issues” lub historii. Typ zdarzenia explicit
	Zgłoszenie serwisowe rozwiązane	Wyznacza dokładny moment, w którym zgłoszenie uznaje się za zrealizowane, a rozwiązanie zostaje odnotowane. Jira uzupełnia pole „Resolution Date”, gdy zgłoszenie po raz pierwszy otrzymuje status z kategorii „Done”.
Dlaczego to ważne To główny kamień milowy kończący proces, niezbędny do obliczenia czasu rozwiązania zgłoszenia i oceny realizacji SLA. Oznacza koniec aktywnej pracy nad zgłoszeniem. Skąd pobrać To jawne zdarzenie. Znacznik czasu odpowiada wartości pola „Resolution Date” w zgłoszeniu Jira. Pole jest ustawiane przy pierwszej zmianie statusu na należący do kategorii „Done”. Rejestrowanie Należy użyć pola „resolutiondate” ze zgłoszenia Jira. Jest ono uzupełniane automatycznie. Typ zdarzenia explicit
	Zgłoszenie serwisowe zamknięte	Oznacza ostateczne, administracyjne zamknięcie zgłoszenia serwisowego. Często następuje automatycznie po upływie określonego czasu w stanie „Rozwiązany”. To końcowy etap cyklu życia zgłoszenia w Jira.
Dlaczego to ważne To ostateczne zdarzenie kończące proces. Analiza czasu między statusami „Rozwiązany” i „Zamknięty” pozwala ocenić nakład pracy administracyjnej lub zasady automatycznego zamykania zgłoszeń. Skąd pobrać Ustalane na podstawie historii zgłoszenia. Znacznik czasu odpowiada ostatniej zmianie statusu na „Zamknięty” lub równoważny status końcowy. Rejestrowanie Ustalenie znacznika czasu ostatniej zmiany statusu na „Zamknięty”. Typ zdarzenia inferred
	Ponowne otwarcie zgłoszenia	To działanie rejestruje przypadki, w których wcześniej rozwiązane zgłoszenie serwisowe wraca do aktywnej obsługi. Można je wywnioskować ze zmiany statusu z „Resolved” lub „Closed” na status otwarty lub będący w toku.
Dlaczego to ważne Śledzenie ponownie otwieranych zgłoszeń jest niezbędne do pomiaru jakości rozwiązań i wskaźnika First-Time Resolution Rate. Wysoki odsetek ponownie otwieranych spraw wskazuje na nieskuteczne rozwiązania lub powracające problemy. Skąd pobrać Działanie można wywnioskować z historii zgłoszenia, identyfikując zmianę statusu z kategorii „Resolved” lub „Closed” na kategorię „Open” lub „In Progress”. Rejestrowanie Znajdź zmianę statusu z kategorii „Done” na kategorię „To Do” lub „In Progress”. Typ zdarzenia inferred
	Potwierdzenie rozwiązania	Działanie następuje, gdy zgłaszający formalnie akceptuje zaproponowane rozwiązanie, co często powoduje automatyczną zmianę statusu na „Resolved”. Zwykle można je wywnioskować z tej zmiany statusu.
Dlaczego to ważne Ten punkt potwierdza skuteczność rozwiązania i uruchamia zatrzymanie zegara SLA. Pozwala mierzyć czas, jakiego klienci potrzebują na potwierdzenie naprawy. Skąd pobrać Działanie można wywnioskować z historii zgłoszenia. Znacznik czasu odpowiada zmianie statusu z „Pending Customer Acceptance” na „Resolved” lub „Closed”. Rejestrowanie Ustalenie znacznika czasu zmiany statusu z „Oczekiwanie na akceptację klienta” na „Rozwiązany” lub „Zamknięty”. Typ zdarzenia inferred
	Prośba o informacje	Oznacza moment, w którym agent potrzebuje dodatkowych informacji od zgłaszającego, aby kontynuować rozwiązywanie sprawy. Zwykle można to wywnioskować ze zmiany statusu zgłoszenia na „Waiting for customer” lub „Pending Input”.
Dlaczego to ważne Częste lub długotrwałe cykle „Information Requested” mogą wskazywać na niejasne zgłoszenia początkowe lub nieskuteczną komunikację. Są istotnym źródłem opóźnień. Skąd pobrać Działanie można wywnioskować z historii zgłoszenia. Znacznik czasu odpowiada chwili zmiany statusu na „Waiting for customer” lub równoważny. Rejestrowanie Znajdź znacznik czasu zmiany pola „status” na wartość oznaczającą oczekiwanie na klienta. Typ zdarzenia inferred
	Przekazanie informacji	Działanie następuje, gdy zgłaszający przekazuje potrzebne informacje, dzięki czemu agent może wznowić pracę. Można je wywnioskować ze zmiany statusu zgłoszenia z „Waiting for customer”, często po dodaniu komentarza przez zgłaszającego.
Dlaczego to ważne To działanie zamyka pętlę wymiany informacji z klientem. Czas między prośbą o informacje a ich otrzymaniem jest istotną częścią czasu oczekiwania w procesie. Skąd pobrać Działanie można wywnioskować z historii zgłoszenia. Znacznik czasu odpowiada chwili zmiany statusu z „Waiting for customer” z powrotem na „In Progress”. Rejestrowanie Znajdź znacznik czasu zmiany pola „status” ze stanu oczekiwania z powrotem na stan aktywny. Typ zdarzenia inferred
	Rozpoczęcie współpracy z dostawcą	To działanie oznacza, że zgłoszenie serwisowe zostało przekazane zewnętrznemu dostawcy lub wymaga jego interwencji. Można je wywnioskować ze zmiany statusu na „Waiting for vendor” lub „With Third Party”.
Dlaczego to ważne Śledzenie współpracy z dostawcami pomaga wykrywać zależności zewnętrzne i opóźnienia, na które wewnętrzny service desk nie ma bezpośredniego wpływu. Skąd pobrać Działanie można wywnioskować z historii zgłoszenia. Znacznik czasu odpowiada chwili zmiany statusu na status oznaczający oczekiwanie na dostawcę. Rejestrowanie Znajdź znacznik czasu zmiany pola „status” na wartość taką jak „Waiting for Vendor”. Typ zdarzenia inferred
	Wdrożenie rozwiązania	Oznacza, że agent wykonał potrzebne działania lub opracował rozwiązanie zgłoszenia serwisowego. Zwykle można to wywnioskować ze zmiany statusu na „Pending Review” lub bezpośrednio na „Resolved”.
Dlaczego to ważne Ten punkt oznacza zakończenie zasadniczych prac nad rozwiązaniem. Czas do tego momentu często obejmuje główną część procesu, która przynosi wartość. Skąd pobrać Działanie można wywnioskować z historii zgłoszenia. Jego znacznik czasu odpowiada zmianie statusu na „Resolved”, „Pending Acceptance” lub podobny status poprzedzający zamknięcie. Rejestrowanie Znajdź znacznik czasu zmiany pola „status” na wartość oznaczającą zakończenie pracy. Typ zdarzenia inferred
	Wstępna ocena zgłoszenia	Oznacza wstępną ocenę zgłoszenia serwisowego, podczas której określa się jego priorytet, kategorię i wpływ. Zwykle wnioskuje się o tym działaniu na podstawie zmiany statusu, na przykład z „New” na „In Progress” lub na dedykowany status „Triaged”.
Dlaczego to ważne Analiza czasu wstępnej oceny pozwala sprawdzić efektywność początkowej obsługi zgłoszeń. Opóźnienia na tym etapie mogą znacznie wydłużyć czas rozwiązania i utrudnić realizację SLA. Skąd pobrać Działanie można wywnioskować z historii zgłoszenia, identyfikując pierwszy znacznik czasu zmiany statusu z początkowego „New” lub „Open” na status aktywny, taki jak „In Progress”. Rejestrowanie Znajdź pierwszą zmianę statusu z „New” lub równoważnego statusu początkowego, zgodnie z workflow projektu. Typ zdarzenia inferred
	Zakończenie współpracy z dostawcą	Oznacza moment, w którym zewnętrzny dostawca zakończył swoje działania, a zgłoszenie serwisowe wraca do zespołu wewnętrznego. Można to wywnioskować ze zmiany statusu zgłoszenia z „Waiting for vendor”.
Dlaczego to ważne Pomiar czasu współpracy z dostawcą pomaga oceniać jego wyniki i zrozumieć wpływ podmiotów zewnętrznych na całkowity czas rozwiązania zgłoszenia. Skąd pobrać Działanie można wywnioskować z historii zgłoszenia. Znacznik czasu odpowiada chwili zmiany statusu dostawcy z powrotem na „In Progress”. Rejestrowanie Znajdź znacznik czasu zmiany pola „status” ze stanu oczekiwania na dostawcę z powrotem na stan aktywny. Typ zdarzenia inferred

Zalecane Opcjonalne

Instrukcje pobierania danych

Jak pobrać dane z Jira Service Management

Kroki

Zalogujcie się do instancji Jira Service Management i przejdźcie do menu głównego.
Wybierzcie Filtry, a następnie Zaawansowane wyszukiwanie zgłoszeń. Otworzy się Issue Navigator, w którym można tworzyć zapytania.
W pasku wyszukiwania wpiszcie zapytanie JQL (Jira Query Language) podane w sekcji zapytań, aby odfiltrować zgłoszenia serwisowe do analizy. W razie potrzeby zmieńcie klucz projektu i zakres dat.
Kliknijcie przycisk Szukaj, aby uruchomić zapytanie. Sprawdźcie listę wyników i upewnijcie się, że zawiera właściwy zestaw danych.
W prawym górnym rogu strony wyników kliknijcie ikonę Eksportuj (zwykle przedstawia pudełko ze strzałką skierowaną na zewnątrz).
Z menu rozwijanego wybierzcie XML. Należy użyć formatu XML, ponieważ standardowy eksport CSV nie zawiera szczegółowej historii zmian potrzebnej do utworzenia pełnego dziennika zdarzeń.
Zapiszcie pobrany plik XML na komputerze. Zawiera on wszystkie zgłoszenia z zapytania wraz z pełną historią zmian osadzoną w danych każdego zgłoszenia.
Ponieważ wyeksportowany plik XML nie ma formatu dziennika zdarzeń, trzeba go przetworzyć. Użyjcie skryptu, na przykład w Pythonie, PowerShellu lub innym języku, aby odczytać plik XML.
Skrypt powinien przejść przez każde zgłoszenie w pliku i utworzyć zdarzenie „Utworzono zgłoszenie serwisowe” na podstawie znacznika czasu utworzenia. Następnie powinien odczytać historię zmian każdego zgłoszenia i znaleźć zmiany pól „status” oraz „assignee”, które odpowiadają wymaganym działaniom. Dla każdej znalezionej zmiany należy utworzyć nowy wiersz.
Skrypt powinien przekształcić dane w płaski plik CSV z kolumnami ServiceRequestId, ActivityName, EventTime oraz wszystkimi pozostałymi wymaganymi i zalecanymi atrybutami.
Wynikiem działania skryptu będzie dziennik zdarzeń. Zapiszcie plik CSV i przygotujcie go do przesłania do narzędzia process mining.

Konfiguracja

Filtr projektu JQL: Użyjcie project = "[Your JSM Project Key]", aby wybrać konkretny projekt zarządzania usługami. Zastąpcie tekst zastępczy kluczem projektu, na przykład „JSM” lub „HELPDESK”.
Filtr typu zgłoszenia JQL: Użyjcie issuetype = "Service Request" albo konkretnej nazwy typu zgłoszenia serwisowego skonfigurowanej w systemie.
Zakres dat: Zaleca się ograniczenie eksportu do określonego przedziału, aby kontrolować jego rozmiar. Użyjcie warunku takiego jak created >= "YYYY-MM-DD" AND created <= "YYYY-MM-DD". Dobrym punktem wyjścia jest zakres od 3 do 6 miesięcy.
Format eksportu: Należy wybrać format XML. CSV nie zawiera danych z historii zmian potrzebnych do utworzenia dziennika zdarzeń.
Uprawnienia w Jira: Osoba wykonująca eksport musi mieć uprawnienie „Przeglądanie projektów” dla wskazanego projektu Jira, aby móc wyświetlać i eksportować zgłoszenia.
Ilość danych: Domyślny eksport z interfejsu Jira często ogranicza się do 1 000 zgłoszeń jednorazowo. Jeśli zapytanie zwraca więcej wyników, należy eksportować dane mniejszymi partiami, zawężając zakres dat dla każdego eksportu.

Przykładowe zapytanie config

project = "JSM" AND issuetype = "Service Request" AND created >= "2023-01-01" AND created <= "2023-12-31" ORDER BY created ASC

Kroki

Uzyskajcie dostęp do bazy danych: Zdobądźcie dane logowania tylko do odczytu oraz informacje o połączeniu z bazą SQL zaplecza instancji Jira: nazwę hosta, port i nazwę bazy danych. Zwykle wymaga to pomocy administratora bazy danych lub działu IT.
Sprawdźcie schemat Jira: Połączcie się z bazą danych za pomocą klienta SQL, takiego jak DBeaver, SQuirreL SQL lub SQL Server Management Studio. Zapoznajcie się z najważniejszymi tabelami: jiraissue (podstawowe dane zgłoszeń), changegroup (historia zmian), changeitem (szczegóły poszczególnych zmian), project (szczegóły projektów), issuetype i priority.
Znajdźcie identyfikatory pól niestandardowych: Atrybuty takie jak RequestType i SlaDueDate często są polami niestandardowymi. Ich identyfikatory można znaleźć, odpytując tabelę customfield: SELECT id, cfname FROM customfield WHERE cfname IN ('[Your Request Type Field Name]', '[Your SLA Field Name]');. Zapiszcie te identyfikatory, aby wykorzystać je w głównym zapytaniu.
Dostosujcie zapytanie SQL: Skopiujcie podany skrypt SQL do klienta SQL. Zastąpcie wszystkie wartości zastępcze ujęte w nawiasy kwadratowe rzeczywistymi wartościami z konfiguracji Jira. Dotyczy to kluczy projektów, nazw typów zgłoszeń i statusów oraz identyfikatorów pól niestandardowych.
Ustawcie zakres dat: Znajdźcie warunek WHERE i.created >= '[YYYY-MM-DD]' w początkowej części zapytania issue_base. Zmieńcie datę, aby określić przedział pobierania danych.
Uruchomcie zapytanie: Wykonajcie zmodyfikowany skrypt SQL. Zapytanie jest przeznaczone do popularnych baz SQL, takich jak PostgreSQL, SQL Server i MySQL. W dużych instancjach Jira jego wykonanie może potrwać kilka minut.
Sprawdźcie wyniki: Po zakończeniu zapytania sprawdźcie, czy zwrócono wiersze i czy kolumny takie jak ServiceRequestId, ActivityName i EventTime zawierają oczekiwane dane.
Wyeksportujcie dane: Zapiszcie pełny zestaw wyników z klienta SQL w pliku CSV. Nadajcie mu opisową nazwę, na przykład jira_servicerequest_eventlog.csv.
Przygotujcie plik do przesłania: Otwórzcie plik CSV i sprawdźcie, czy nagłówki kolumn dokładnie odpowiadają wymaganym nazwom atrybutów, na przykład ServiceRequestId, ActivityName i EventTime. Zapiszcie plik w kodowaniu UTF-8, aby zapewnić zgodność z ProcessMind.

Konfiguracja

Wymagania wstępne: Potrzebny jest bezpośredni dostęp tylko do odczytu do produkcyjnej bazy danych Jira lub jej repliki. Standardowy dostęp do aplikacji nie wystarczy. Konieczna jest również dobra znajomość workflow konkretnego projektu Service Desk, w tym dokładnych nazw statusów, typów zgłoszeń i pól niestandardowych.
Najważniejsze filtry zapytania: Zapytanie musi być skonfigurowane tak, aby pobierało właściwy zestaw danych. Zwróćcie szczególną uwagę na warunki WHERE:
- p.pkey IN ('[Your Project Key]'): To najważniejszy filtr. Ogranicza dane do jednego lub kilku wskazanych projektów Jira Service Management.
- it.pname = '[Your Service Request Issue Type]': Dzięki temu pobierane są wyłącznie zgłoszenia serwisowe, a nie incydenty, problemy ani inne typy zgłoszeń.
- i.created >= '[YYYY-MM-DD]': Ten filtr określa datę początkową pobierania danych. Do wstępnej analizy zaleca się zakres obejmujący ostatnie 3–6 miesięcy.
Mapowanie statusów workflow: Poprawność dziennika zdarzeń zależy od właściwego odwzorowania nazw statusów Jira w zapytaniu. Zastąpcie teksty zastępcze, takie jak [Status for Triage], [Waiting for Customer Status] i [Resolved Status], nazwami używanymi w danym workflow.
Wydajność: Uruchomienie zapytania bezpośrednio na dużej, aktywnie używanej bazie Jira może zużyć znaczne zasoby i wpłynąć na wydajność aplikacji. Zaleca się pobieranie danych z repliki tylko do odczytu lub poza godzinami szczytu.

Przykładowe zapytanie sql

WITH issue_base AS (
    SELECT 
        i.id AS issue_id,
        i.issuenum,
        i.project AS project_id,
        p.pkey || '-' || i.issuenum AS ServiceRequestId,
        i.created AS creation_timestamp,
        i.resolutiondate AS resolution_timestamp,
        u.display_name AS Assignee,
        pr.pname AS RequestPriority,
        s.pname AS RequestStatus,
        it.pname AS IssueTypeName, 
        cf_type.stringvalue AS RequestType,
        cf_sla.datevalue AS SlaDueDate
    FROM jiraissue i
    JOIN project p ON i.project = p.id
    LEFT JOIN issuetype it ON i.issuetype = it.id
    LEFT JOIN issuestatus s ON i.issuestatus = s.id
    LEFT JOIN priority pr ON i.priority = pr.id
    LEFT JOIN app_user u ON i.assignee = u.user_key
    LEFT JOIN customfieldvalue cf_type ON i.id = cf_type.issue AND cf_type.customfield = [Your Request Type Custom Field ID]
    LEFT JOIN customfieldvalue cf_sla ON i.id = cf_sla.issue AND cf_sla.customfield = [Your SLA Due Date Custom Field ID]
    WHERE p.pkey IN ('[Your Project Key]') 
    AND it.pname = '[Your Service Request Issue Type]' 
    AND i.created >= '[YYYY-MM-DD]'
),
change_history AS (
    SELECT 
        cg.issueid AS issue_id,
        cg.created AS change_timestamp,
        ci.field AS changed_field,
        ci.oldstring AS old_value,
        ci.newstring AS new_value
    FROM changegroup cg
    JOIN changeitem ci ON cg.id = ci.groupid
    WHERE ci.fieldtype = 'jira' AND ci.field IN ('status', 'assignee', 'resolution')
)
SELECT
    ib.ServiceRequestId,
    'Service Request Created' AS ActivityName,
    ib.creation_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Request Triaged' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.new_value = '[Status for Triage]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Request Assigned' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'assignee' AND ch.new_value IS NOT NULL

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Information Requested' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.new_value = '[Waiting for Customer Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Information Provided' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.old_value = '[Waiting for Customer Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Vendor Engagement Started' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.new_value = '[Waiting for Vendor Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Vendor Engagement Ended' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.old_value = '[Waiting for Vendor Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Solution Implemented' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.new_value = '[Solution Implemented Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Resolution Proposed' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.new_value = '[Pending Customer Acceptance Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Request Reopened' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'resolution' AND ch.new_value IS NULL AND ch.old_value IS NOT NULL

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Resolution Confirmed' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.old_value = '[Pending Customer Acceptance Status]' AND ch.new_value = '[Resolved Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Service Request Resolved' AS ActivityName,
    ib.resolution_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
WHERE ib.resolution_timestamp IS NOT NULL

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Service Request Closed' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.new_value = '[Closed Status]'
ORDER BY 1, 3;

Kroki

Wymagania wstępne i konfiguracja: Upewnijcie się, że na komputerze jest zainstalowany Python 3.6 lub nowszy. Zainstalujcie wymagane biblioteki Pythona, uruchamiając w terminalu polecenie: pip install requests pandas.
Utwórzcie token API Jira: Zalogujcie się na konto Jira Cloud. Przejdźcie do ustawień profilu, wybierzcie „Ustawienia konta”, a następnie otwórzcie kartę „Bezpieczeństwo” i utwórzcie token API. Zapiszcie go w bezpiecznym miejscu, ponieważ będzie używany do uwierzytelniania.
Znajdźcie identyfikatory pól niestandardowych: Wiele atrybutów Jira, takich jak „Request Type” czy „SLA Due Date”, to pola niestandardowe. Aby znaleźć ich identyfikatory, przejdźcie do „Ustawienia” > „Zgłoszenia” > „Pola niestandardowe”. Wyszukajcie odpowiednie pole, kliknijcie trzy kropki „...” > „Wyświetl informacje o polu”. Identyfikator znajduje się w adresie URL, na przykład customFieldId=10021. Zapiszcie te identyfikatory do konfiguracji skryptu.
Skonfigurujcie skrypt Python: Otwórzcie podany skrypt Python w edytorze tekstu. Uzupełnijcie zmienne konfiguracyjne na początku pliku, w tym JIRA_URL, JIRA_EMAIL, JIRA_API_TOKEN, zapytanie jql_query wybierające zgłoszenia serwisowe oraz znalezione wcześniej identyfikatory CUSTOM_FIELD_IDS.
Przypiszcie statusy Jira do działań: Dokładnie sprawdźcie słownik STATUS_ACTIVITY_MAP w skrypcie. Zaktualizujcie mapowanie zgodnie z workflow Jira Service Management. Klucze muszą dokładnie odpowiadać nazwom statusów w Jira, na przykład „Waiting for customer”, a wartości nazwom działań wymaganym w dzienniku zdarzeń, na przykład „Poproszono o informacje”.
Uruchomcie skrypt pobierający dane: Otwórzcie terminal lub wiersz polecenia, przejdźcie do katalogu, w którym zapisano skrypt, i uruchomcie go poleceniem: python jira_extraction_script.py. Skrypt połączy się z Jira API, pobierze dane zgłoszeń, przetworzy je i wyświetli postęp w konsoli.
Sprawdźcie plik wynikowy: Po zakończeniu skrypt utworzy w tym samym katalogu plik CSV o nazwie jira_event_log.csv. Otwórzcie go w arkuszu kalkulacyjnym i sprawdźcie zawartość. Upewnijcie się, że wszystkie kolumny są obecne i zawierają oczekiwane dane.
Przygotujcie dane do przesłania do ProcessMind: Sprawdźcie, czy nagłówki kolumn w pliku CSV dokładnie odpowiadają wymaganiom: ServiceRequestId, ActivityName, EventTime, SourceSystem, LastDataUpdate, Assignee, RequestPriority, RequestStatus, RequestType i SlaDueDate. Plik jest gotowy do przesłania do ProcessMind.

Konfiguracja

Uwierzytelnianie Jira: Skrypt wymaga adresu URL domeny Jira, adresu e-mail powiązanego z kontem Jira oraz osobistego tokenu API zapewniającego bezpieczny dostęp.
Zapytanie JQL (jql_query): To podstawowy filtr pobierania danych. Należy precyzyjnie określić zapytanie JQL, aby wybrać właściwe zgłoszenia. Zalecamy filtrowanie według project, issuetype i zakresu dat z użyciem createdDate, aby kontrolować ilość danych, na przykład project = 'SERVICEDESK' AND issuetype = 'Service Request' AND createdDate >= '-6m'.
Mapowanie statusów na działania (STATUS_ACTIVITY_MAP): Ten słownik służy do prawidłowego przekształcania zmian statusów Jira w działania procesu. Dostosujcie mapowanie do workflow Jira używanego w organizacji. Statusy, których nie ma na liście, zostaną pominięte.
Identyfikatory pól niestandardowych (CUSTOM_FIELD_IDS): Aby pobrać dane z pól niestandardowych, takich jak „Request Type” lub „SLA Due Date”, należy podać ich unikatowe identyfikatory systemowe, na przykład customfield_10021. Bez poprawnej konfiguracji atrybuty nie zostaną wypełnione.
Zakres dat i wydajność: Przy pierwszym pobieraniu zaleca się użycie zakresu JQL obejmującego 3–6 miesięcy, aby zachować sprawną obsługę danych. Pobieranie danych z kilku lat może trwać długo ze względu na stronicowanie API i limity liczby żądań.

Przykładowe zapytanie python

import os
import requests
import pandas as pd
from datetime import datetime, timezone

class=class="hl-string">"hl-comment"># --- CONFIGURATION --- 
class=class="hl-string">"hl-comment"># Replace with your Jira instance details
JIRA_URL = class="hl-string">"https://your-domain.atlassian.net"
JIRA_EMAIL = class="hl-string">"your-email@example.com"
JIRA_API_TOKEN = os.environ.get(class="hl-string">"JIRA_API_TOKEN", class="hl-string">"YOUR_JIRA_API_TOKEN") class=class="hl-string">"hl-comment"># Best practice: use environment variables

class=class="hl-string">"hl-comment"># JQL query to fetch service request issues. 
class=class="hl-string">"hl-comment"># Recommended: Filter by project, issuetype, and a date range.
jql_query = class="hl-string">"project = 'SD' AND issuetype = 'Service Request' AND created >= '-6m' ORDER BY created DESC"

class=class="hl-string">"hl-comment"># Map your specific Jira status names to the desired activity names.
class=class="hl-string">"hl-comment"># This is CRITICAL for capturing the correct process flow.
STATUS_ACTIVITY_MAP = {
    class="hl-string">'In Progress': class="hl-string">'Request Triaged',
    class="hl-string">'Waiting for customer': class="hl-string">'Information Requested',
    class="hl-string">'Waiting for support': class="hl-string">'Information Provided',
    class="hl-string">'Waiting for vendor': class="hl-string">'Vendor Engagement Started',
    class="hl-string">'Vendor Responded': class="hl-string">'Vendor Engagement Ended',
    class="hl-string">'Pending Review': class="hl-string">'Solution Implemented',
    class="hl-string">'Pending Customer Acceptance': class="hl-string">'Resolution Proposed',
    class="hl-string">'Reopened': class="hl-string">'Request Reopened',
    class="hl-string">'Resolved': class="hl-string">'Resolution Confirmed', class=class="hl-string">"hl-comment"># Or could be class="hl-string">'Solution Implemented' depending on workflow
    class="hl-string">'Closed': class="hl-string">'Service Request Closed'
}

class=class="hl-string">"hl-comment"># Map desired attributes to their custom field IDs in Jira.
class=class="hl-string">"hl-comment"># Find these IDs in your Jira instance under Settings > Issues > Custom Fields.
CUSTOM_FIELD_IDS = {
    class="hl-string">'RequestType': class="hl-string">'[customfield_10021]', class=class="hl-string">"hl-comment"># Example ID for Request Type
    class="hl-string">'SlaDueDate': class="hl-string">'[customfield_10030]'    class=class="hl-string">"hl-comment"># Example ID for SLA Due Date
}

class=class="hl-string">"hl-comment"># --- SCRIPT LOGIC --- 
def fetch_jira_issues(url, email, token, jql):
    class="hl-string">"""Fetches all issues from Jira matching the JQL query, handling pagination."""
    headers = {
        class="hl-string">"Accept": class="hl-string">"application/json",
        class="hl-string">"Content-Type": class="hl-string">"application/json"
    }
    auth = (email, token)
    
    issues = []
    start_at = 0
    max_results = 50
    total = -1

    print(fclass="hl-string">"Fetching issues from Jira with JQL: {jql}")
    while total == -1 or start_at < total:
        api_url = fclass="hl-string">"{url}/rest/api/3/search"
        params = {
            class="hl-string">'jql': jql,
            class="hl-string">'startAt': start_at,
            class="hl-string">'maxResults': max_results,
            class="hl-string">'expand': class="hl-string">'changelog'
        }
        
        response = requests.get(api_url, headers=headers, params=params, auth=auth)
        response.raise_for_status() class=class="hl-string">"hl-comment"># Exit if there is an error
        data = response.json()
        
        if total == -1:
            total = data[class="hl-string">'total']
            print(fclass="hl-string">"Found {total} total issues to process.")

        page_issues = data.get(class="hl-string">'issues', [])
        issues.extend(page_issues)
        start_at += len(page_issues)
        print(fclass="hl-string">"Fetched {len(issues)} / {total} issues...")

        if len(page_issues) == 0:
            break

    return issues

def process_issues_to_event_log(issues):
    class="hl-string">"""Processes raw issue data into a structured event log."""
    event_log = []
    now_utc = datetime.now(timezone.utc).isoformat()
    source_system = class="hl-string">"Jira Service Management"

    for issue in issues:
        case_id = issue[class="hl-string">'key']
        fields = issue.get(class="hl-string">'fields', {})
        changelog = issue.get(class="hl-string">'changelog', {}).get(class="hl-string">'histories', [])
        
        class=class="hl-string">"hl-comment"># Helper to get nested field values safely
        def get_field_value(field_data, key):
            return field_data.get(key)
        
        def get_custom_field_value(field_data, custom_field_id):
            custom_field = field_data.get(custom_field_id)
            if isinstance(custom_field, dict):
                return custom_field.get(class="hl-string">'value')
            return custom_field

        class=class="hl-string">"hl-comment"># --- Extract common attributes for all events of this case ---
        assignee = get_field_value(fields.get(class="hl-string">'assignee', {}), class="hl-string">'displayName')
        priority = get_field_value(fields.get(class="hl-string">'priority', {}), class="hl-string">'name')
        status = get_field_value(fields.get(class="hl-string">'status', {}), class="hl-string">'name')
        request_type = get_custom_field_value(fields, CUSTOM_FIELD_IDS[class="hl-string">'RequestType'])
        sla_due_date = get_custom_field_value(fields, CUSTOM_FIELD_IDS[class="hl-string">'SlaDueDate'])

        common_attributes = {
            class="hl-string">'ServiceRequestId': case_id,
            class="hl-string">'SourceSystem': source_system,
            class="hl-string">'LastDataUpdate': now_utc,
            class="hl-string">'Assignee': assignee,
            class="hl-string">'RequestPriority': priority,
            class="hl-string">'RequestStatus': status,
            class="hl-string">'RequestType': request_type,
            class="hl-string">'SlaDueDate': sla_due_date
        }

        class=class="hl-string">"hl-comment"># 1. Activity: Service Request Created
        event_log.append({
            **common_attributes,
            class="hl-string">'ActivityName': class="hl-string">'Service Request Created',
            class="hl-string">'EventTime': fields[class="hl-string">'created']
        })

        class=class="hl-string">"hl-comment"># 2. Activity: Service Request Resolved
        if fields.get(class="hl-string">'resolutiondate'):
            event_log.append({
                **common_attributes,
                class="hl-string">'ActivityName': class="hl-string">'Service Request Resolved',
                class="hl-string">'EventTime': fields[class="hl-string">'resolutiondate']
            })

        class=class="hl-string">"hl-comment"># 3. Process changelog for all other activities
        for history in changelog:
            created_time = history[class="hl-string">'created']
            for item in history[class="hl-string">'items']:
                class=class="hl-string">"hl-comment"># Activity: Request Assigned
                if item[class="hl-string">'field'].lower() == class="hl-string">'assignee':
                    event_log.append({
                        **common_attributes,
                        class="hl-string">'ActivityName': class="hl-string">'Request Assigned',
                        class="hl-string">'EventTime': created_time,
                        class="hl-string">'Assignee': item.get(class="hl-string">'toString') class=class="hl-string">"hl-comment"># Use the new assignee for this event
                    })
                
                class=class="hl-string">"hl-comment"># Activities based on status changes
                if item[class="hl-string">'field'].lower() == class="hl-string">'status':
                    to_status = item.get(class="hl-string">'toString')
                    if to_status in STATUS_ACTIVITY_MAP:
                        activity = STATUS_ACTIVITY_MAP[to_status]
                        event_log.append({
                            **common_attributes,
                            class="hl-string">'ActivityName': activity,
                            class="hl-string">'EventTime': created_time,
                            class="hl-string">'RequestStatus': to_status class=class="hl-string">"hl-comment"># Use the new status for this event
                        })

    return event_log

if __name__ == class="hl-string">"__main__":
    try:
        issues_data = fetch_jira_issues(JIRA_URL, JIRA_EMAIL, JIRA_API_TOKEN, jql_query)
        if issues_data:
            event_log_data = process_issues_to_event_log(issues_data)
            df = pd.DataFrame(event_log_data)

            class=class="hl-string">"hl-comment"># Reorder and format columns for final output
            column_order = [
                class="hl-string">'ServiceRequestId', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
                class="hl-string">'Assignee', class="hl-string">'RequestPriority', class="hl-string">'RequestStatus', class="hl-string">'RequestType', class="hl-string">'SlaDueDate'
            ]
            df = df[column_order]
            df[class="hl-string">'EventTime'] = pd.to_datetime(df[class="hl-string">'EventTime']).dt.strftime(class="hl-string">'%Y-%m-%d %H:%M:%S')

            output_filename = class="hl-string">'jira_event_log.csv'
            df.to_csv(output_filename, index=False)
            print(fclass="hl-string">"\nSuccessfully extracted {len(df)} events to {output_filename}")
        else:
            print(class="hl-string">"No issues found for the given JQL query.")

    except requests.exceptions.HTTPError as e:
        print(fclass="hl-string">"HTTP Error: {e.response.status_code} - {e.response.text}")
    except Exception as e:
        print(fclass="hl-string">"An unexpected error occurred: {e}")

Gotowi do rozpoczęcia?

Skorzystajcie z tego szablonu, aby rozpocząć process mining i znaleźć możliwości usprawnienia obsługi zgłoszeń serwisowych. Zacznijcie optymalizować operacje już dziś.

Wróć do przewodnika ulepszania procesów

Pobierz szablon

Już teraz usprawnijcie obsługę zgłoszeń serwisowych w Jira

Zautomatyzujcie 70% procesu i skróćcie czas realizacji zgłoszeń. Zwiększcie efektywność już dziś!

Rozpocznijcie okres próbny

Nie trzeba podawać danych karty płatniczej. Konfiguracja zajmuje kilka minut.

Szablon danych do analizy obsługi zgłoszeń serwisowych

Szablon danych do analizy obsługi zgłoszeń serwisowych

Atrybuty obsługi zgłoszeń serwisowych

Działania w procesie obsługi zgłoszeń serwisowych

Instrukcje pobierania danych

Wbudowany eksport CSV/XML w Jira Service Management

Kroki

Konfiguracja

Przykładowe zapytanie config

Bezpośrednie zapytanie do bazy danych Jira Server/Data Center

Kroki

Konfiguracja

Przykładowe zapytanie sql

Pobieranie danych skryptem Python przez Jira Cloud REST API

Kroki

Konfiguracja

Przykładowe zapytanie python

Gotowi do rozpoczęcia?

Już teraz usprawnijcie obsługę zgłoszeń serwisowych w Jira