> Průběžné zlepšování procesů > Správa servisních požadavků > Jira Service Management > Datová šablona

Šablona dat pro správu servisních požadavků

Jira Service Management

Atributy správy servisních požadavků(17) Aktivity při správě servisních požadavků(13) Návody na získání dat(3)

Šablona dat pro správu servisních požadavků

Tato šablona nabízí přehledný postup, jak shromáždit potřebná data pro analýzu procesů správy servisních požadavků. Uvádí, které atributy sbírat a které důležité aktivity sledovat, a vysvětluje, jak data ze systému získat. Pomůže vám připravit data a lépe porozumět provozu.

Doporučené atributy pro podrobnou analýzu
Důležité aktivity pro mapování procesů
Návod na získání dat z Jira Service Management

Pracujete se záznamy událostí poprvé? Přečtěte si, jak vytvořit záznam událostí pro process mining.

Stáhnout šablonu

Atributy správy servisních požadavků

Toto jsou doporučená datová pole, která zahrňte do záznamu událostí pro podrobnou analýzu správy servisních požadavků.

5 Povinné 5 Doporučené 7 Volitelné

	Název	Popis
	Aktivita ActivityName	Název konkrétní události nebo úkolu, ke kterému došlo během životního cyklu požadavku na službu.
Popis Tento atribut popisuje konkrétní akci nebo změnu stavu, ke které u požadavku na službu došlo v určitém okamžiku. Příklady: „Požadavek vytvořen“, „Požadavek přiřazen“, „Řešení implementováno“ a „Požadavek uzavřen“. Analýza pořadí a četnosti těchto aktivit je základem process mining. Umožňuje zobrazit mapy procesů, najít úzká místa a odhalit odchylky od standardního workflow. To je důležité pro pochopení efektivity procesu a dodržování pravidel. Proč je to důležité Určuje jednotlivé kroky procesu, umožňuje zobrazit mapu procesu a analyzovat vzorce workflow i odchylky. Kde data získat Obvykle se odvozuje z historie změn stavu požadavku v Jira. Každý záznam změny pole stavu v changelogu požadavku představuje jednu aktivitu. Příklady Požadavek roztříděnVyžádány informaceŘešení provedenoPožadavek na službu uzavřen
	Čas zahájení EventTime	Přesné datum a čas, kdy došlo ke konkrétní aktivitě nebo události.
Popis Čas zahájení neboli časové razítko události zaznamenává přesný okamžik, kdy k aktivitě došlo. Pro analýzu process mining je zásadní, protože poskytuje časový kontext celého procesu. Časové razítko slouží k seřazení událostí, výpočtu doby mezi aktivitami a celkové doby průchodu případu i k porovnání výkonu procesu s časovými cíli, například SLA. Bez přesných časových razítek nelze pochopit průběh procesu, najít zpoždění ani měřit efektivitu. Proč je to důležité Toto časové razítko je nezbytné pro řazení událostí, výpočet dob trvání a průchodu procesem i hledání úzkých míst. Kde data získat Jde o časové razítko přiřazené každé změně stavu v changelogu požadavku Jira. Čas vytvoření požadavku je uveden v poli „created“. Příklady 2023-10-26T10:00:00Z2023-10-26T10:15:32Z2023-10-27T14:20:05Z
	ID požadavku na službu ServiceRequestId	Jedinečný identifikátor každého požadavku na službu, který slouží jako primární klíč pro všechny související události.
Popis ID požadavku na službu, v Jira často označované jako Issue Key, jednoznačně identifikuje každý jednotlivý požadavek odeslaný uživatelem nebo systémem. Propojuje všechny následující události od prvního zaznamenání až po konečné uzavření a umožňuje analyzovat celý průběh každého požadavku. V process mining je toto ID nezbytné pro přiřazení událostí ke konkrétním případům. Zajišťuje, že každá aktivita, změna stavu a časové razítko jsou správně přiřazeny ke konkrétnímu požadavku. Díky tomu vzniká souvislá instance procesu, kterou lze analyzovat. Proč je to důležité Toto ID je základním identifikátorem případu. Propojuje všechny související aktivity do jednoho průběhu procesu od začátku do konce a umožňuje jeho analýzu. Kde data získat Jde o pole „key“ požadavku v Jira Service Management. Příklady SR-2023-001IT-45892HELP-105
	Poslední aktualizace dat LastDataUpdate	Časové razítko označující, kdy byla data naposledy obnovena ze zdrojového systému.
Popis Tento atribut zaznamenává datum a čas poslední extrakce dat z Jira Service Management. Poskytuje důležitý kontext pro posouzení aktuálnosti analýzy i dat v dashboardech a KPI. Při rozhodování je důležité vědět, jak aktuální data jsou. Časové razítko uživatelům ukazuje, zda pracují s aktuálními informacemi, nebo se snímkem z dřívějšího okamžiku. To ovlivňuje relevanci zjištění. Proč je to důležité Ukazuje aktuálnost dat a pomáhá zajistit, aby analýza vycházela z nejnovějších informací. Kde data získat Jde o pole metadat, které nástroj nebo skript pro extrakci dat vytvoří a uloží po dokončení běhu. Příklady 2023-10-27T02:00:00Z2023-10-28T02:00:00Z
	Zdrojový systém SourceSystem	Systém, ze kterého byla data o požadavcích na službu získána.
Popis Tento atribut označuje původ dat, v tomto případě Jira Service Management. Při analýze dat z jediného zdroje se může zdát zbytečný, ale při spojování dat o procesech z více systémů je zásadní. Pomáhá sledovat původ dat a ověřovat jejich kvalitu. Umožňuje také filtrovat a porovnávat procesy, které probíhají v různých softwarových platformách nebo mezi nimi. Proč je to důležité Označuje původ dat, což je důležité pro správu dat i při spojování dat o procesech z více podnikových systémů. Kde data získat Obvykle jde o neměnnou hodnotu, která se přidává při extrakci a transformaci dat a označuje původ datové sady. Příklady Jira Service ManagementJiraSM
	Priorita požadavku RequestPriority	Úroveň priority požadavku na službu, například nízká, střední, vysoká nebo kritická.
Popis Priorita požadavku vyjadřuje jeho naléhavost a dopad na provoz. Určuje pořadí, v jakém se požadavky řeší, a často také cílovou dobu vyřešení a SLA. Při analýze procesu slouží priorita jako důležitý rozměr pro segmentaci. Umožňuje porovnávat dobu průchodu a plnění SLA u různých úrovní priority a ověřit, zda se požadavky s vysokou prioritou skutečně řeší rychleji a v požadovaném termínu. Tím lze posoudit účinnost systému určování priorit. Proč je to důležité Umožňuje rozdělit analýzu podle priority a ověřit, zda se požadavky s vysokou prioritou řeší rychleji a splňují přísnější úrovně služeb. Kde data získat Odpovídá poli „priority“ u požadavku v Jira. Příklady NejvyššíVysokáStředníNízká
	Řešitel Assignee	Uživatel nebo pracovník podpory, kterému je aktuálně přiřazena práce na požadavku.
Popis Řešitel odpovídá za další krok nebo vyřešení požadavku na službu. Během životního cyklu požadavku se může měnit, když se práce předává mezi pracovníky nebo týmy. Tento atribut je důležitý pro analýzu pracovní zátěže, měření výkonu a správu zdrojů. Umožňuje filtrovat proces podle pracovníka podpory, porovnávat dobu vyřešení mezi jednotlivými pracovníky a hledat potřeby školení nebo nerovnoměrné rozložení práce, které způsobuje úzká místa. Proč je to důležité Tento atribut je důležitý pro analýzu pracovní zátěže pracovníků podpory, měření jejich výkonu a pochopení rozdělení zdrojů. Kde data získat Odpovídá poli „assignee“ u požadavku v Jira. Příklady Alice JohnsonBob WilliamsNepřiřazeno
	Stav požadavku RequestStatus	Aktuální stav požadavku na službu v průběhu jeho životního cyklu.
Popis Tento atribut označuje aktuální stav požadavku na službu, například „Open“, „In Progress“, „Waiting for Customer“ nebo „Resolved“. Ukazuje, v jaké fázi se požadavek právě nachází. Záznam aktivit zachycuje průběh v čase, zatímco aktuální stav pomáhá analyzovat rozpracovanou práci a hledat požadavky, které se zasekly. Analýza se může například zaměřit na požadavky, které jsou neobvykle dlouho ve stavu „Waiting for Vendor“, a odhalit tak závislosti na externích stranách a zpoždění. Proč je to důležité Poskytuje aktuální přehled o každém případu, umožňuje analyzovat rozpracovanou práci a hledat nevyřízené nebo dlouho otevřené požadavky. Kde data získat Jde o pole „status“ u požadavku v Jira. Příklady OtevřenýProbíháČeká se na zákazníkaVyřešeno
	Termín SLA SlaDueDate	Cílové datum a čas, do kterého má být požadavek na službu vyřešen podle SLA.
Popis Termín SLA je vypočítané časové razítko, které označuje lhůtu pro vyřešení požadavku. Určuje se podle priority a typu požadavku a pravidel Service Level Agreement (SLA) nastavených v Jira Service Management. Tento atribut je základem dashboardu „Výkon SLA u požadavků na službu“ a KPI „Míra plnění SLA“. Porovnáním skutečné doby vyřešení s termínem systém zjistí, zda byl každý požadavek vyřízen včas, po termínu, nebo zda mu hrozí nesplnění SLA. Proč je to důležité Slouží jako měřítko výkonu. Přímo podporuje výpočet plnění SLA a pomáhá určovat priority práce. Kde data získat Informace o SLA spravuje Jira Service Management. Jsou dostupné přes API a často se ukládají do vlastních polí, která se průběžně aktualizují. Příklady 2023-10-28T16:00:00Z2023-11-01T09:00:00Z
	Typ požadavku RequestType	Kategorie požadavku na službu, například „Žádost o přístup“ nebo „Problém s hardwarem“.
Popis Typ požadavku určuje kategorii požadavku na službu podle jeho povahy. Jde o základní rozměr analýzy, protože různé typy požadavků mají často odlišný postup řešení, SLA i nároky na zdroje. Rozdělení analýzy procesu podle typu požadavku umožňuje přizpůsobit zlepšování konkrétním workflow. Úzké místo u požadavku „Obnovení hesla“ bude například jiné než u požadavku „Zřízení nového serveru“. Tento atribut je důležitý pro tvorbu relevantních dashboardů, například „Kvalita řešení podle kategorie“. Proč je to důležité Tento atribut je nezbytný pro porovnání procesů, pracovní zátěže a výkonu u různých kategorií požadavků na službu. Kde data získat Často odpovídá poli „issuetype“ v Jira nebo vlastnímu poli „Request Type“ v Jira Service Management. Příklady Požádat o nový účetPožádat o pomoc ITZařadit nového zaměstnance
	Kanál Channel	Způsob odeslání požadavku na službu, například e-mail, portál nebo API.
Popis Atribut Kanál označuje, jak se požadavek na službu dostal do systému. Mezi běžné kanály v Jira Service Management patří zákaznický portál, e-mail nebo přímé vytvoření pracovníkem podpory. Analýza procesu podle kanálu pomáhá pochopit chování uživatelů a zlepšit poskytování služeb. Může ukázat, zda vyřízení požadavků z některých kanálů trvá déle nebo vyžaduje více upřesnění. To může znamenat, že je třeba upravit formuláře na portálu nebo pravidla pro zpracování e-mailů. Tento atribut podporuje dashboard „Trendy průchodnosti požadavků na službu“. Proč je to důležité Pomáhá zjistit, zda kanál odeslání ovlivňuje dobu vyřešení, srozumitelnost požadavků nebo celkovou efektivitu procesu. Kde data získat Tyto informace jsou v Jira Service Management dostupné v poli „Request channel type“. Může být potřeba zvláštní přístup k API nebo mohou být uloženy ve vlastním poli. Příklady portále-mailapi
	Organizace Organization	Zákaznická organizace nebo interní oddělení, do kterého zadavatel patří.
Popis Tento atribut seskupuje zadavatele podle organizací nebo oddělení. Jira Service Management obsahuje funkci „Organizations“, která pracovníkům podpory umožňuje spravovat požadavky od více zákazníků nebo interních týmů. Analýza podle organizace poskytuje důležitý obchodní kontext. Pomáhá zjistit, kteří zákazníci nebo oddělení využívají nejvíce zdrojů podpory, zda se některé skupiny opakovaně potýkají s problémy a zda se SLA důsledně plní napříč různými částmi organizace. Proč je to důležité Umožňuje analyzovat poptávku po službách a výkon podle zákazníka nebo interního oddělení a poskytuje důležité obchodní informace. Kde data získat Tato data pocházejí z pole „Organizations“ přiřazeného k požadavku na službu v Jira Service Management. Příklady Acme CorporationFinanční odděleníGlobal Tech Inc.
	Přiřazený tým AssignedTeam	Tým nebo skupina odpovědná za vyřízení požadavku na službu.
Popis Tento atribut označuje tým přiřazený k požadavku. Obvykle jde o širší skupinu než jednotlivý řešitel. Umožňuje například porovnat výkon týmu podpory první úrovně s týmem síťového provozu. Tento rozměr je důležitý pro dashboardy, jako je „Pracovní zátěž pracovníků podpory a metriky řešení“. Umožňuje souhrnně sledovat výkon na úrovni týmu, spravedlivě jej porovnávat a pochopit, jak jednotlivé týmy přispívají k celkovému poskytování služeb. Proč je to důležité Umožňuje analyzovat výkon a vyrovnávat pracovní zátěž na úrovni týmu nebo oddělení, nejen jednotlivých pracovníků podpory. Kde data získat Může jít o vlastní pole v Jira, například „Team“, nebo lze tým odvodit z atributů profilu řešitele. Příklady Podpora IT, 1. úroveňTým infrastrukturyPodpora aplikací
	Stav SLA SlaState	Označuje, zda požadavek na službu splnil SLA, překročil jeho lhůtu, nebo je stále v rámci stanoveného SLA.
Popis Stav SLA je vypočítaný atribut, který zařazuje každý požadavek na službu podle toho, jak si vede vůči termínu SLA. Možné hodnoty jsou „Splněno“, „Překročeno“ nebo „Probíhá“. Určuje se porovnáním časového razítka vyřešení s hodnotou „SlaDueDate“. Jde o hlavní atribut dashboardu „Výkon SLA u požadavků na službu“ a používá se k výpočtu KPI „Míra plnění SLA“. Poskytuje přehledný okamžitý ukazatel plnění úrovně služeb, který je důležitý pro reporting, správu smluv a udržení kvality služeb. Proč je to důležité Poskytuje přehledný a okamžitý ukazatel plnění SLA, které je důležitým měřítkem kvality služeb a dodržování smluvních podmínek. Kde data získat Vypočítá se při transformaci dat. Pokud je požadavek vyřešen před termínem „SlaDueDate“, stav je „Splněno“, jinak „Překročeno“. Příklady SplněnoPřekročenoProbíhá
	Výsledek řešení Resolution	Konečný výsledek nebo závěr vyřešeného požadavku na službu.
Popis Pole Resolution uvádí, proč byl požadavek na službu uzavřen. Mezi běžné hodnoty patří „Done“, „Won't Do“, „Duplicate“ nebo „Cannot Reproduce“. Poskytuje podrobnosti o uzavření nad rámec samotného stavu „Resolved“ nebo „Closed“. Analýza výsledků řešení pomáhá pochopit jejich kvalitu a povahu. Vysoký počet požadavků uzavřených jako „Duplicate“ může například upozornit na problém s procesem zadávání požadavků. Sledování výsledků, po kterých se požadavky znovu otevírají, zase může odhalit neúčinná řešení. Proč je to důležité Poskytuje kontext o výsledku požadavku a pomáhá analyzovat kvalitu řešení i hledat souvislosti v důvodech uzavření požadavků. Kde data získat Odpovídá poli „resolution“ u požadavku v Jira. Obvykle se nastaví při přechodu požadavku do stavu z kategorie „done“. Příklady HotovoNebude provedenoDuplicitníOpraveno
	Zadavatel Reporter	Uživatel, který požadavek na službu původně vytvořil nebo nahlásil.
Popis Zadavatel je osoba, často koncový uživatel nebo zákazník, která odeslala požadavek na službu. Tento atribut označuje účastníka, který proces zahájil. Při analýze lze podle zadavatele sledovat vzorce požadavků různých uživatelů, oddělení nebo skupin zákazníků. Pomáhá odpovědět například na otázky: „Která oddělení zadávají nejvíce požadavků?“ nebo „Potýkají se někteří uživatelé opakovaně se stejnými problémy?“ Tyto informace pomáhají předcházet problémům a zlepšovat školení uživatelů. Proč je to důležité Označuje, kdo požadavek zadal, a umožňuje analyzovat počet a typy požadavků podle uživatele, oddělení nebo zákazníka. Kde data získat Odpovídá poli „reporter“ u požadavku v Jira. Příklady Charles DarwinMarie CurieIsaac Newton
	Znovu otevřen IsReopened	Logická hodnota, která označuje, zda byl požadavek na službu po vyřešení znovu otevřen.
Popis Tento vypočítaný atribut má hodnotu true nebo false. Nastaví se na true, pokud workflow požadavku obsahuje aktivitu „Request Reopened“. Hodnota se odvozuje z analýzy pořadí aktivit u každého případu. Tento příznak je nezbytný pro výpočet KPI „Míra opětovného otevření požadavků na službu“ a pro dashboard „Počet znovu otevřených požadavků na službu“. Vysoká míra opětovného otevření často ukazuje na nízkou kvalitu vyřešení napoprvé, což vede k opakované práci a nižší spokojenosti zákazníků. Analýza typů požadavků a výsledků řešení spojených s tímto příznakem může ukázat, kde je prostor pro zlepšení. Proč je to důležité Přímo měří opakovanou práci a kvalitu vyřešení napoprvé, což jsou důležité ukazatele účinnosti procesu a spokojenosti zákazníků. Kde data získat Vypočítá se při transformaci dat kontrolou, zda pořadí aktivit případu obsahuje přechod do stavu „Reopened“ po přechodu do stavu „Resolved“. Příklady truefalse

Povinné Doporučené Volitelné

Aktivity při správě servisních požadavků

Toto jsou důležité kroky a milníky procesu, které zaznamenejte do záznamu událostí pro přesné mapování a zlepšování procesů.

5 Doporučené 8 Volitelné

	Aktivita	Popis
	Požadavek na službu uzavřen	Označuje konečné administrativní uzavření požadavku na službu, ke kterému často dojde automaticky po uplynutí stanovené doby ve stavu „Resolved“. Jde o konečný bod životního cyklu požadavku v Jira.
Proč je to důležité Jde o definitivní koncovou událost procesu. Dobu mezi stavy „Resolved“ a „Closed“ lze analyzovat a zjistit tak administrativní režii nebo pravidla automatického uzavírání. Kde data získat Odvozuje se z historie požadavku. Časové razítko odpovídá poslední změně stavu na „Closed“ nebo na jiný ekvivalentní konečný stav. Zachycení Určete časové razítko poslední změny na stav „Closed“. Typ události inferred
	Požadavek na službu vyřešen	Označuje přesný okamžik, kdy se požadavek považuje za vyřízený a řešení je zaznamenáno. Jira vyplní pole „Resolution Date“, když se požadavek poprvé dostane do stavu z kategorie „Done“.
Proč je to důležité Jde o hlavní koncový milník procesu, který je zásadní pro výpočet doby vyřešení a plnění SLA. Označuje konec aktivní práce. Kde data získat Jde o explicitní událost. Časové razítko odpovídá hodnotě v poli „Resolution Date“ požadavku v Jira, které se nastaví při prvním přechodu do stavu z kategorie „Done“. Zachycení Použijte pole „resolutiondate“ z požadavku v Jira. Vyplňuje se automaticky. Typ události explicit
	Požadavek přiřazen	K této činnosti dochází, když je servisní požadavek přiřazen konkrétnímu agentovi nebo týmu k vyřešení. Jira výslovně sleduje změny pole „Assignee“, takže je k dispozici přesné časové razítko přiřazení.
Proč je to důležité Tento milník je důležitý pro měření doby od roztřídění po přiřazení a sledování rozložení pracovní zátěže agentů. Označuje přechod od čekání ve frontě k aktivnímu zpracování. Kde data získat Zaznamená se z historie požadavku. Vyhledejte první případ, kdy bylo pole „Assignee“ vyplněno nebo změněno z nepřiřazené hodnoty. Zachycení Použijte časové razítko první změny pole „Assignee“ v historii požadavku. Typ události explicit
	Řešení navrženo	V mnoha workflow servisního oddělení jde o samostatný krok, při kterém je žadateli předloženo řešení ke schválení. Odvozuje se ze změny stavu požadavku na hodnotu, jako je „Čeká na přijetí zákazníkem“ nebo „Čeká na potvrzení“.
Proč je to důležité Tato činnost odděluje dobu čekání na reakci zákazníka po předložení řešení od času věnovaného interní práci. Kde data získat Odvozuje se z historie požadavku. Zaznamená se časové razítko změny stavu na hodnotu označující, že řešení čeká na potvrzení zákazníkem. Zachycení Určete časové razítko změny stavu na „Čeká na přijetí zákazníkem“ nebo odpovídající hodnotu. Typ události inferred
	Servisní požadavek vytvořen	Tato činnost označuje začátek životního cyklu servisního požadavku. Uživatel odešle požadavek prostřednictvím portálu, e-mailu nebo jiného kanálu. V Jira se tato událost zaznamená při vytvoření nového požadavku typu „Servisní požadavek“ spolu s časovým razítkem vytvoření.
Proč je to důležité Jde o hlavní počáteční událost procesu. Je nezbytná pro výpočet celkové doby průchodu procesem a pochopení objemu i četnosti příchozích požadavků. Kde data získat Jde o výslovně zaznamenanou událost v tabulce historie požadavku. Čas činnosti odpovídá poli „created“ v požadavku Jira. Zachycení Použijte časové razítko vytvoření požadavku z tabulky „issues“ nebo z historie. Typ události explicit
	Informace doplněny	K této události dochází, když žadatel poskytne potřebné informace a agent může pokračovat v práci. Odvozuje se z přechodu požadavku ze stavu „Čeká na zákazníka“, často poté, co žadatel přidá komentář.
Proč je to důležité Tato činnost uzavírá cyklus žádosti o informace a odpovědi zákazníka. Doba mezi vyžádáním a obdržením informací tvoří důležitou část čekání v procesu. Kde data získat Odvozuje se z historie požadavku. Časové razítko odpovídá okamžiku, kdy se stav změní z „Čeká na zákazníka“ zpět na „Probíhá“. Zachycení Určete časové razítko, kdy se pole „status“ změní z čekajícího stavu zpět na aktivní stav. Typ události inferred
	Požadavek roztříděn	Označuje počáteční posouzení servisního požadavku, při kterém se určí jeho priorita, kategorie a dopad. Tato činnost se obvykle odvozuje ze změny stavu, například z „Nový“ na „Probíhá“, nebo z přechodu do vyhrazeného stavu „Roztříděno“.
Proč je to důležité Analýza doby potřebné k roztřídění pomáhá vyhodnotit efektivitu počátečního zpracování požadavků. Zpoždění v této fázi mohou výrazně prodloužit celkovou dobu vyřízení a zhoršit plnění SLA. Kde data získat Odvozuje se z historie požadavku. Určí se první časové razítko změny stavu z počátečního stavu „Nový“ nebo „Otevřený“ na aktivní stav, například „Probíhá“. Zachycení Podle workflow projektu určete první změnu stavu z „Nový“ nebo jiného odpovídajícího počátečního stavu. Typ události inferred
	Požadavek znovu otevřen	Tato činnost zachycuje případy, kdy se dříve vyřešený servisní požadavek vrátí do aktivního stavu. Odvozuje se ze změny stavu z vyřešeného nebo uzavřeného na otevřený nebo probíhající.
Proč je to důležité Sledování znovuotevřených požadavků je důležité pro měření kvality řešení a míry vyřešení při prvním kontaktu. Vysoký podíl znovuotevřených požadavků ukazuje na neúčinná řešení nebo opakující se problémy. Kde data získat Odvozuje se z historie požadavku. Vyhledejte přechod ze stavu kategorie „Vyřešeno“ nebo „Uzavřeno“ do stavu kategorie „Otevřeno“ nebo „Probíhá“. Zachycení Vyhledejte změnu stavu z kategorie „Hotovo“ do kategorie „K vyřízení“ nebo „Probíhá“. Typ události inferred
	Řešení potvrzeno	K této události dochází, když žadatel formálně přijme navržené řešení. Často se tím automaticky změní stav na „Vyřešeno“. Událost se obvykle odvozuje z této změny stavu.
Proč je to důležité Tento milník potvrzuje účinnost řešení a zastavuje měření času SLA. Pomáhá zjistit, jak dlouho zákazníkům trvá potvrzení vyřešení. Kde data získat Odvozuje se z historie požadavku. Časové razítko odpovídá změně stavu z „Čeká na přijetí zákazníkem“ na „Vyřešeno“ nebo „Uzavřeno“. Zachycení Určete časové razítko změny stavu z „Pending Customer Acceptance“ na stav „Resolved“ nebo „Closed“. Typ události inferred
	Řešení provedeno	Označuje, že agent provedl potřebné kroky nebo připravil řešení servisního požadavku. Obvykle se odvozuje ze změny stavu na „Čeká na kontrolu“ nebo přímo na „Vyřešeno“.
Proč je to důležité Tento milník označuje dokončení hlavní práce na řešení. Doba do této činnosti obvykle představuje hlavní část procesu, která přináší hodnotu. Kde data získat Odvozuje se z historie požadavku. Odpovídá časovému razítku změny stavu na „Vyřešeno“, „Čeká na přijetí“ nebo podobný stav před uzavřením. Zachycení Určete časové razítko, kdy se pole „status“ změní na hodnotu označující dokončení práce. Typ události inferred
	Vyžádány informace	Označuje okamžik, kdy agent potřebuje od žadatele další informace, aby mohl pokračovat v řešení. Obvykle se odvozuje z přechodu požadavku do stavu, jako je „Čeká na zákazníka“ nebo „Čeká na doplnění“.
Proč je to důležité Časté nebo dlouhé cykly „Vyžádány informace“ mohou ukazovat na nejasné původní zadání nebo neefektivní komunikaci a být významným zdrojem zpoždění. Kde data získat Odvozuje se z historie požadavku. Časové razítko odpovídá okamžiku, kdy se stav požadavku změní na „Čeká na zákazníka“ nebo jiný odpovídající stav. Zachycení Určete časové razítko, kdy se pole „status“ změní na hodnotu označující, že proces čeká na zákazníka. Typ události inferred
	Zapojení dodavatele ukončeno	Označuje okamžik, kdy externí dodavatel dokončí svou práci a servisní požadavek se vrátí internímu týmu. Odvozuje se z přechodu požadavku ze stavu „Čeká na dodavatele“.
Proč je to důležité Měření doby zapojení dodavatele pomáhá vyhodnocovat jeho výkonnost a pochopit, jak externí strany ovlivňují celkovou dobu vyřízení. Kde data získat Odvozuje se z historie požadavku. Časové razítko odpovídá okamžiku, kdy se stav změní ze stavu pro dodavatele zpět na „Probíhá“. Zachycení Určete časové razítko, kdy se pole „status“ změní ze stavu pro dodavatele zpět na aktivní stav. Typ události inferred
	Zapojení dodavatele zahájeno	Tato činnost označuje, že servisní požadavek byl předán externímu dodavateli nebo že je potřeba jeho zásah. Odvozuje se z přechodu požadavku do stavu, jako je „Čeká na dodavatele“ nebo „U třetí strany“.
Proč je to důležité Sledování zapojení dodavatelů je důležité pro odhalení externích závislostí a zpoždění, která interní servisní tým nemůže přímo ovlivnit. Kde data získat Odvozuje se z historie požadavku. Časové razítko odpovídá okamžiku, kdy se stav požadavku změní na určený stav pro dodavatele. Zachycení Určete časové razítko, kdy se pole „status“ změní na hodnotu, jako je „Čeká na dodavatele“. Typ události inferred

Doporučené Volitelné

Návody na získání dat

Jak získat data z Jira Service Management

Kroky

Přihlaste se do své instance Jira Service Management a přejděte do hlavní nabídky.
Vyberte Filters a potom Advanced issue search. Otevře se Issue Navigator, kde můžete sestavovat dotazy.
Do vyhledávacího pole zadejte dotaz JQL (Jira Query Language) uvedený v části Query. Odfiltrujete tak servisní požadavky, které chcete analyzovat. Podle potřeby upravte klíč projektu a časové období.
Kliknutím na tlačítko Search spusťte dotaz. Zkontrolujte vrácené požadavky a ověřte, že jde o správná data.
V pravém horním rohu stránky s výsledky klikněte na ikonu Export. Obvykle vypadá jako rámeček se šipkou směřující ven.
V rozbalovací nabídce vyberte XML. Použijte XML, protože standardní export CSV neobsahuje podrobnou historii změn potřebnou k vytvoření úplného záznamu událostí.
Uložte stažený soubor XML do svého počítače. Obsahuje všechny požadavky z dotazu včetně úplné historie změn vložené do dat každého požadavku.
Exportovaný soubor XML není ve formátu záznamu událostí, proto je nutné data následně zpracovat. Pomocí skriptu, například v Pythonu, PowerShellu nebo jiném jazyce, soubor XML zpracujte.
Skript musí projít každý požadavek v souboru a z časového razítka vytvoření vytvořit událost „Servisní požadavek vytvořen“. Poté musí zpracovat historii změn každého požadavku a najít změny polí „status“ a „assignee“, které odpovídají požadovaným aktivitám. Pro každou nalezenou změnu vytvořte nový řádek.
Skript převede data do plochého souboru CSV se sloupci ServiceRequestId, ActivityName, EventTime a všemi dalšími požadovanými a doporučenými atributy.
Výsledkem skriptu bude záznam událostí. Uložte soubor CSV a připravte ho k nahrání do nástroje process mining.

Konfigurace

Filtr projektu JQL: Pomocí project = "[Your JSM Project Key]" vyberte konkrétní projekt správy služeb. Zástupný text nahraďte klíčem svého projektu, například „JSM“ nebo „HELPDESK“.
Filtr typu požadavku JQL: Použijte issuetype = "Service Request" nebo konkrétní název typu požadavku, který používáte ve své konfiguraci.
Časové období: Doporučujeme omezit export na konkrétní období, aby soubor nebyl příliš velký. Použijte například podmínku created >= "YYYY-MM-DD" AND created <= "YYYY-MM-DD". Dobrým výchozím obdobím bývají 3 až 6 měsíců.
Formát exportu: Pro export musíte vybrat XML. Formát CSV neobsahuje data z historie změn potřebná k vytvoření záznamu událostí.
Oprávnění v Jira: Uživatel, který export provádí, musí mít v daném projektu Jira oprávnění „Browse Projects“, aby mohl požadavky zobrazit a exportovat.
Objem dat: Výchozí export přes rozhraní Jira je často omezen na 1 000 požadavků najednou. Pokud dotaz vrátí více výsledků, exportujte data po menších dávkách a pro každý export zkraťte časové období.

Ukázkový dotaz config

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

Kroky

Získejte přístup k databázi: Získejte přihlašovací údaje pouze pro čtení a údaje pro připojení k databázi SQL, která slouží jako backend instance Jira. Budete potřebovat název hostitele, port a název databáze. S tím vám obvykle pomůže správce databáze nebo IT oddělení.
Seznamte se se schématem Jira: Připojte se k databázi pomocí klienta SQL, například DBeaver, SQuirreL SQL nebo SQL Server Management Studio. Seznamte se s důležitými tabulkami: jiraissue (základní data požadavků), changegroup (historie změn), changeitem (podrobnosti jednotlivých změn), project (údaje o projektu), issuetype a priority.
Zjistěte ID vlastních polí: Atributy jako RequestType a SlaDueDate bývají vlastní pole. Jejich ID zjistíte dotazem na tabulku customfield: SELECT id, cfname FROM customfield WHERE cfname IN ('[Your Request Type Field Name]', '[Your SLA Field Name]');. Poznamenejte si ID pro hlavní dotaz.
Upravte dotaz SQL: Zkopírujte dodaný skript SQL do klienta SQL. Pečlivě nahraďte všechny zástupné hodnoty v hranatých závorkách skutečnými hodnotami z konfigurace Jira. Patří sem klíče projektů, názvy typů požadavků, názvy stavů a ID vlastních polí.
Nastavte časové období: V úvodní části dotazu issue_base najděte podmínku WHERE i.created >= '[YYYY-MM-DD]'. Upravte datum a určete období, ze kterého chcete data získat.
Spusťte dotaz: Spusťte upravený skript SQL. Dotaz je určen pro běžné databáze SQL, například PostgreSQL, SQL Server a MySQL. Ve velkých instancích Jira může jeho dokončení trvat několik minut.
Zkontrolujte výsledky: Po dokončení dotazu krátce ověřte, že obsahuje řádky a že sloupce jako ServiceRequestId, ActivityName a EventTime mají očekávané hodnoty.
Exportujte data: Exportujte celou sadu výsledků z klienta SQL do souboru CSV. Zvolte výstižný název, například jira_servicerequest_eventlog.csv.
Připravte data k nahrání: Otevřete soubor CSV a ověřte, že názvy sloupců přesně odpovídají požadovaným názvům atributů, například ServiceRequestId, ActivityName a EventTime. Kvůli kompatibilitě s ProcessMind uložte soubor v kódování UTF-8.

Konfigurace

Předpoklady: Potřebujete přímý přístup pouze pro čtení k produkční databázi Jira nebo její replice. Běžný přístup do aplikace nestačí. Musíte také dobře znát workflow konkrétního projektu Service Desk, včetně přesných názvů stavů, typů požadavků a vlastních polí.
Důležité filtry dotazu: Dotaz musí být nastaven tak, aby vybíral správná data. Věnujte pozornost těmto podmínkám WHERE:
- p.pkey IN ('[Your Project Key]'): Jde o nejdůležitější filtr. Omezuje data na jeden nebo více konkrétních projektů Jira Service Management.
- it.pname = '[Your Service Request Issue Type]': Zajistí, že získáte pouze servisní požadavky, nikoli incidenty, problémy nebo jiné typy požadavků.
- i.created >= '[YYYY-MM-DD]': Určuje počáteční datum získávání dat. Pro první analýzu doporučujeme období posledních 3 až 6 měsíců.
Mapování stavů workflow: Přesnost záznamu událostí závisí na správném mapování názvů stavů Jira v dotazu. Zástupné hodnoty jako [Status for Triage], [Waiting for Customer Status] a [Resolved Status] nahraďte názvy používanými ve vašem workflow.
Dopad na výkon: Spuštění dotazu přímo nad velkou a aktivně používanou databází Jira může spotřebovat značné množství zdrojů a ovlivnit výkon aplikace. Doporučujeme spouštět získávání dat nad replikou určenou ke čtení nebo mimo špičku.

Ukázkový dotaz 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;

Kroky

Předpoklady a nastavení: Ověřte, že máte v systému nainstalovaný Python 3.6 nebo novější. Potřebné knihovny Pythonu nainstalujte v terminálu příkazem pip install requests pandas.
Vytvořte token Jira API: Přihlaste se ke svému účtu Jira Cloud. V nastavení profilu vyberte „Account settings“, přejděte na kartu „Security“ a vytvořte token API. Token bezpečně zkopírujte, budete ho potřebovat k ověření.
Zjistěte ID vlastních polí: Mnoho atributů Jira, například „Request Type“ nebo „SLA Due Date“, jsou vlastní pole. Jejich ID najdete v nabídce „Settings“ > „Issues“ > „Custom fields“. Vyhledejte požadované pole, klikněte na tři tečky „...“ a vyberte „View field information“. ID najdete v URL, například customFieldId=10021. Poznamenejte si ho pro nastavení skriptu.
Nastavte skript Python: Otevřete dodaný skript Python v textovém editoru. Vyplňte konfigurační proměnné v horní části souboru, včetně JIRA_URL, JIRA_EMAIL, JIRA_API_TOKEN, dotazu jql_query pro výběr servisních požadavků a hodnot CUSTOM_FIELD_IDS, které jste zjistili v předchozím kroku.
Namapujte stavy Jira na aktivity: Pečlivě zkontrolujte slovník STATUS_ACTIVITY_MAP ve skriptu. Upravte mapování podle workflow Jira Service Management, které používáte. Klíče musí přesně odpovídat názvům stavů Jira, například „Waiting for customer“, a hodnoty názvům aktivit požadovaným v záznamu událostí, například „Vyžádání informací“.
Spusťte skript pro získání dat: Otevřete terminál nebo příkazový řádek, přejděte do složky, kam jste skript uložili, a spusťte příkaz python jira_extraction_script.py. Skript se připojí k Jira API, načte data o požadavcích, zpracuje je a bude v konzoli zobrazovat průběh.
Zkontrolujte výstupní soubor: Po dokončení skript vytvoří ve stejné složce soubor CSV s názvem jira_event_log.csv. Otevřete ho v tabulkovém procesoru a ověřte obsah. Zkontrolujte, že jsou přítomné všechny sloupce a mají očekávané hodnoty.
Připravte data k nahrání do ProcessMind: Ověřte, že názvy sloupců v souboru CSV přesně odpovídají požadavkům: ServiceRequestId, ActivityName, EventTime, SourceSystem, LastDataUpdate, Assignee, RequestPriority, RequestStatus, RequestType a SlaDueDate. Soubor je nyní připravený k nahrání do ProcessMind.

Konfigurace

Ověření v Jira: Skript potřebuje URL vaší domény Jira, e-mailovou adresu přiřazenou k účtu Jira a osobní token API pro bezpečný přístup.
Dotaz JQL (jql_query): Jde o hlavní filtr pro získání dat. Přesným dotazem JQL vyberte správné požadavky. Doporučujeme filtrovat podle project, issuetype a konkrétního časového období pomocí createdDate, abyste omezili objem dat, například project = 'SERVICEDESK' AND issuetype = 'Service Request' AND createdDate >= '-6m'.
Mapování stavů na aktivity (STATUS_ACTIVITY_MAP): Tento slovník je nezbytný pro správný převod změn stavů Jira na smysluplné aktivity procesu. Upravte mapování podle workflow Jira ve vaší organizaci. Stavy, které v mapování nejsou, budou ignorovány.
ID vlastních polí (CUSTOM_FIELD_IDS): Pokud chcete získat data z vlastních polí, například „Request Type“ nebo „SLA Due Date“, zadejte jejich jedinečná systémová ID, například customfield_10021. Aby se atributy správně vyplnily, musí být ID nastavena správně.
Časové období a výkon: Pro první získání dat doporučujeme v JQL nastavit období 3 až 6 měsíců, aby zpracování proběhlo v rozumném čase. Získávání dat za několik let může být pomalé kvůli stránkování API a omezení počtu požadavků.

Ukázkový dotaz 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}")

Chcete začít?

Využijte tuto šablonu jako výchozí bod pro process mining a hledejte možnosti, jak zlepšit správu servisních požadavků. Začněte zlepšovat svůj provoz ještě dnes.

Zpět na průvodce zlepšováním

Stáhnout šablonu

Zlepšete správu servisních požadavků v Jira

Dosáhněte 70% automatizace a skoncujte s pomalým vyřizováním požadavků. Zvyšte efektivitu.

Spustit zkušební verzi

Platební kartu nepotřebujete. Nastavení zabere jen několik minut.

Šablona dat pro správu servisních požadavků

Šablona dat pro správu servisních požadavků

Atributy správy servisních požadavků

Aktivity při správě servisních požadavků

Návody na získání dat

Vestavěný export CSV/XML v Jira Service Management

Kroky

Konfigurace

Ukázkový dotaz config

Přímý dotaz do databáze Jira Server/Data Center

Kroky

Konfigurace

Ukázkový dotaz sql

Získání dat skriptem Python přes Jira Cloud REST API

Kroky

Konfigurace

Ukázkový dotaz python

Chcete začít?

Zlepšete správu servisních požadavků v Jira