> Průběžné zlepšování procesů > Správa problémů > Jira Service Management > Datová šablona

Šablona dat pro správu problémů

Jira Service Management

Atributy správy problémů(20) Aktivity správy problémů(14) Návody k extrakci dat(2)

Šablona dat pro správu problémů

Tato šablona vám pomůže analyzovat workflow správy IT služeb. Ukazuje, které údaje a milníky v Jira Service Management je vhodné sledovat. Najdete v ní přehled atributů a aktivit potřebných k tomu, abyste viděli, jak tým řeší problémy a hledá jejich hlavní příčiny. Doporučení využijte při přípravě dat pro process mining, abyste z analýzy získali konkrétní podklady pro zlepšení.

Doporučené atributy pro podrobnou analýzu
Milníky, které zaznamenat do záznamu událostí
Technické pokyny k extrakci dat

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 problémů

Pro podrobnou analýzu životního cyklu správy problémů doporučujeme do záznamu událostí zahrnout tato datová pole.

5 Povinné 5 Doporučené 10 Volitelné

	Název	Popis
	Aktivita ActivityName	Konkrétní úkon nebo změna stavu záznamu o problému.
Popis Tento atribut zachycuje název události nebo přechodu stavu v životním cyklu řízení problému. Příklady: „Problém zaznamenán“, „Stav změněn na Prošetřuje se“ nebo „Určena hlavní příčina“. Je nezbytný pro mapování průběhu procesu a určení pořadí kroků potřebných k vyřešení problému. V process mining tyto činnosti tvoří uzly mapy procesu. Proč je to důležité Určuje jednotlivé kroky v mapě procesu a umožňuje analyzovat varianty procesu. Kde data získat Jira Changelog (History) nebo přechody stavů požadavku Příklady Záznam o problému vytvořenZahájení prošetřováníUrčení hlavní příčinyAktualizace náhradního řešeníZáznam o problému uzavřen
	Časové razítko EventTimestamp	Přesné datum a čas, kdy k činnosti došlo.
Popis Tento atribut zaznamenává přesný okamžik, kdy činnost proběhla. Slouží k seřazení událostí podle času a výpočtu doby mezi jednotlivými kroky. Přesná časová razítka jsou nezbytná pro výpočet doby průchodu, například od události „Problém zaznamenán“ po „Určena hlavní příčina“, i pro analýzu průchodnosti v čase. Proč je to důležité Umožňuje vypočítat všechny časové KPI a správně seřadit události. Kde data získat Datum vytvoření v Jira Changelog nebo datum vytvoření požadavku Příklady 2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:20:00Z
	Poslední aktualizace dat LastDataUpdate	Časové razítko, kdy byla data extrahována nebo naposledy obnovena.
Popis Udává, kdy byla datová sada naposledy synchronizována s živým prostředím Jira Service Management. Analytici tak vědí, jak aktuální data jsou. Slouží k ověření, zda analýza zachycuje nejnovější stav procesu, a k odhalení případného zpoždění dat. Proč je to důležité Zajišťuje aktuálnost dat a pomáhá důvěřovat výsledkům analýzy. Kde data získat Časové razítko ETL Příklady 2023-11-01T12:00:00Z2023-11-02T00:00:00Z
	Záznam o problému ProblemKey	Jedinečný identifikátor přiřazený záznamu o problému v Jira Service Management.
Popis Tento atribut slouží jako hlavní identifikátor případu pro analýzu process mining. Jde o jedinečný klíč, například PM-1001, který Jira Service Management vytvoří při založení nového záznamu o problému. Podle tohoto atributu se všechny související činnosti, změny stavu a aktualizace seskupí do jedné instance procesu od začátku do konce. Analýza umožňuje zobrazit celý životní cyklus problému, od prvního odhalení přes prošetřování až po konečné uzavření. Proč je to důležité Jde o základní klíč potřebný k rekonstrukci průběhu procesu a sledování konkrétních záznamů o problémech. Kde data získat Tabulka požadavků, pole „Key“ nebo „Issue Key“ Příklady PM-1023PM-4099PRB-3321PM-5001
	Zdrojový systém SourceSystem	Název systému, ze kterého data pocházejí.
Popis Určuje softwarový systém, ze kterého byla data o procesu získána. V tomto případě je hodnotou vždy „Jira Service Management“. Tento atribut se hodí zejména v prostředí s více systémy, kde pomáhá rozlišit zdroje dat. V tomto konkrétním zobrazení slouží především jako neměnný identifikátor původu dat. Proč je to důležité Uvádí původ dat, zejména při jejich spojování s dalšími daty z oblasti IT Service Management. Kde data získat Pevně zadaná hodnota nebo konfigurace systému Příklady Jira Service ManagementJira CloudJSM-Prod
	Kategorie hlavní příčiny RootCauseCategory	Klasifikace příčiny, která problém vyvolala.
Popis Zařazuje technickou nebo procesní chybu, která problém způsobila, například „Chyba softwaru“, „Lidská chyba“ nebo „Porucha hardwaru“. V Jira Service Management jde často o vlastní pole. Tento atribut podporuje dashboard „Rozložení kategorií hlavních příčin“ a pomáhá rozhodovat, kam investovat do infrastruktury nebo školení, aby se problém neopakoval. Proč je to důležité Pomáhá odhalovat systémové problémy a plánovat preventivní opatření. Kde data získat Vlastní pole „Root Cause“ nebo „Root Cause Category“ Příklady Chyba softwaruChyba konfiguraceProblém s kapacitouProblém na straně dodavatele
	Priorita Priority	Úroveň závažnosti přiřazená záznamu problému.
Popis Udává naléhavost a dopad problému, obvykle v rozsahu od „Nízká“ po „Kritická“. Toto pole slouží k rozdělení analýzy a ověření, zda jsou problémy s vysokou prioritou řešeny v rámci cílů SLA. Analýza tohoto atributu pomáhá v dashboardu „Shoda s SLA a vývoj cílů“ ověřit, zda jsou kritická obchodní rizika správně upřednostňována. Proč je to důležité Umožňuje porovnat výkonnost procesu podle důležitosti pro provoz. Kde data získat Pole požadavku „Priority“ Příklady NejvyššíVysokáStředníNízká
	Přiřazená skupina podpory SupportGroup	Technický tým nebo skupina, která má aktuálně na starosti šetření problému.
Popis Určuje tým odpovědný za záznam problému v okamžiku události. V Jira Service Management se tato hodnota často mapuje na pole „Component“ nebo na vlastní pole, například „Support Group“. Tento atribut je důležitý pro dashboard „Předávání mezi skupinami podpory“, který analytikům ukazuje, jak se problémy přesouvají mezi týmy a kde zůstávají nejdéle. Proč je to důležité Nezbytné pro analýzu procesů v organizaci a odhalení problémů při spolupráci týmů. Kde data získat Pole požadavku „Component“ nebo vlastní pole „Support Group“ Příklady Správa databázíProvoz sítěPodpora aplikací, úroveň 2
	Shrnutí problému ProblemSummary	Stručný popis nebo název záznamu problému.
Popis Obsahuje stručné shrnutí záznamu problému. Jde především o textové pole, které analytikům poskytuje kontext při kontrole jednotlivých případů v nástroji process mining. Umožňuje vyhledávat podle klíčových slov a kvalitativně analyzovat typy zaznamenaných problémů. Proč je to důležité Poskytuje srozumitelný kontext k identifikátoru případu. Kde data získat Pole požadavku „Summary“ Příklady Vypršel časový limit připojení k databázi v oblasti EUNáhlé zvýšení latence e-mailové službyFronta zpracování objednávek se zasekla
	Uživatel UserKey	Jedinečný identifikátor nebo jméno uživatele, který provedl danou aktivitu.
Popis Zaznamenává osobu nebo systémový účet odpovědný za provedení konkrétní aktivity. Může jít například o „Přiřazeného uživatele“, který aktualizoval záznam, nebo o „Autora“ změny stavu. Tyto údaje slouží k analýze využití zdrojů, odhalení předávání práce mezi uživateli, která vytvářejí úzká místa, a zajištění odpovědnosti v procesu správy problémů. Proč je to důležité Důležité pro analýzu předávání práce, oddělení povinností a vytížení zdrojů. Kde data získat Pole Jira „author“ v changelogu nebo pole „assignee“ u požadavku Příklady j.smithsystem_automationm.doe
	Byl znovu otevřen IsReopened	Příznak udávající, zda byl problém po uzavření znovu otevřen.
Popis Logický příznak, který se nastaví na true, pokud se záznam problému změnil z uzavřeného stavu zpět na otevřený. Slouží k analýze „Míra opětovného otevření problémů“. Vysoká míra opětovného otevření může ukazovat na nedostatečnou kvalitu trvalých oprav nebo na nedostatečné ověřovací postupy. Proč je to důležité Ukazatel kvality a účinnosti oprav. Kde data získat Odvozeno ze změn stavu Příklady truefalse
	Datum vytvoření CreatedDate	Datum vytvoření záznamu problému.
Popis Časové razítko, kdy byl problém poprvé zaznamenán v systému. Časové razítko události zachycuje čas jednotlivých aktivit, zatímco tento atribut se často používá k filtrování na vyšší úrovni, například „Zobrazit všechny problémy vytvořené v 1. čtvrtletí“. Slouží jako výchozí datum pro analýzu stáří případů. Proč je to důležité Výchozí datum pro analýzu stáří případů a počtu nových záznamů. Kde data získat Pole požadavku „Created“ Příklady 2023-01-012023-06-15
	Je k dispozici náhradní řešení WorkaroundDetails	Udává, zda je pro problém zdokumentováno náhradní řešení.
Popis Zaznamenává, zda existuje nebo bylo zveřejněno dočasné náhradní řešení. Organizace tak může sledovat „Rychlost zveřejnění náhradního řešení“. Analýza tohoto pole ukazuje, jak rychle tým dokáže obnovit stabilitu služby, ještě než najde trvalou opravu. Proč je to důležité Pomáhá měřit, jak rychle se provozu poskytne dočasná úleva. Kde data získat Vlastní pole „Workaround“ Příklady Restartovat službuVymazat mezipaměť prohlížečeNení uvedeno
	Kód řešení ResolutionCode	Kód označující způsob vyřešení problému.
Popis Určuje konečný výsledek záznamu problému, například „Opraveno“, „Nebude opraveno“, „Duplicitní“ nebo „Nelze reprodukovat“. Slouží k odlišení úspěšně vyřešených problémů od těch, které byly uzavřeny z administrativních důvodů. Díky tomu jsou výpočty KPI, například „Průměrná doba do zjištění hlavní příčiny“, přesnější. Proč je to důležité Rozlišuje účinné opravy od administrativního uzavření. Kde data získat Pole požadavku „Resolution“ Příklady HotovoNebude provedenoDuplicitníNelze reprodukovat
	Oznamovatel ReporterName	Uživatel, který původně zaznamenal problém.
Popis Určuje osobu, která vytvořila záznam problému. Nejde o přiřazeného uživatele. Analýza oznamovatelů pomáhá zjistit, kde se problémy odhalují, například zda je zaznamenávají pracovníci service desku, nebo správci systémů. Doplňuje analýzu „Proaktivní a reaktivní zjišťování“. Proč je to důležité Určuje zdroj nahlášení problému. Kde data získat Pole požadavku „Reporter“ Příklady monitoring_servicehelpdesk_leadnetwork_admin
	Počet propojených incidentů LinkedIncidentCount	Počet incidentů propojených s tímto záznamem problému.
Popis Počet požadavků typu incident propojených se záznamem problému. Tento atribut vyjadřuje dopad problému na uživatele. Používá se v KPI „Hloubka propojení incidentů s problémy“ k určení priority problémů, které vedou k největšímu počtu požadavků na podporu. Proč je to důležité Vyjadřuje dopad na provoz podle počtu incidentů. Kde data získat Počet propojení v tabulce „issuelinks“, kde je typ „Problem/Incident“ Příklady 011550
	Propojený požadavek na změnu LinkedChangeRequest	Identifikátor požadavku na změnu propojeného s tímto problémem.
Popis Ukládá ID požadavku na změnu (RFC) vytvořeného za účelem zavedení trvalé opravy. Toto propojení je důležité pro dashboard „Prodleva při zahájení požadavku na změnu“. Propojuje proces správy problémů s procesem řízení změn a umožňuje analyzovat oba procesy společně. Proč je to důležité Propojuje šetření problému s jeho nápravou v procesu řízení změn. Kde data získat Propojení požadavků, jejichž typ je „is fixed by“ nebo podobný Příklady CR-404CHG-1099CR-5512
	Provedena kontrola po zavedení změny ReviewStatus	Udává, zda proběhla kontrola po zavedení změny (PIR).
Popis Sleduje, zda je u případu zaznamenána aktivita nebo příznak „Kontrola po zavedení změny“. Je nezbytný pro dashboard „Shoda s požadavky na kontrolu po zavedení změny“. Pomáhá ověřit, zda organizace dodržuje požadavky na řízení a průběžné zlepšování. Proč je to důležité Metrika shody, která podporuje učení v organizaci. Kde data získat Vlastní pole „PIR Status“ nebo existence aktivity „PIR“ Příklady DokončenoČeká na vyřízeníNení vyžadováno
	Stav porušení SLA SlaBreachStatus	Udává, zda záznam problému překročil sjednanou úroveň služeb.
Popis Logické nebo stavové pole, které udává, zda doba řešení překročila sjednaný cíl. Pomáhá v dashboardu „Shoda s SLA a vývoj cílů“. Upozorňuje na případy, které mohou organizaci vystavit riziku nedodržení požadavků nebo sankcí. Proč je to důležité Důležité pro sledování shody a výkonnosti. Kde data získat Logika polí SLA v Jira Service Management Příklady SplněnoPřekročenoPozastaveno
	Zdroj zjištění DetectionSource	Jak byl problém zjištěn, například proaktivně nebo reaktivně.
Popis Udává, jak byl problém odhalen. Mezi běžné hodnoty patří „Proaktivní monitorování“, „Incident na service desku“ nebo „Oznámení dodavatele“. Tento atribut se používá v dashboardu „Proaktivní a reaktivní zjišťování“ k měření vyspělosti procesu správy problémů. Proč je to důležité Měří vyspělost procesu a účinnost monitorovacích systémů. Kde data získat Vlastní pole „Source“ nebo „Detection Source“ Příklady Proaktivní monitorováníEskalace incidentuOznámení dodavatele

Povinné Doporučené Volitelné

Aktivity správy problémů

Pro přesné zjištění průběhu řešení zaznamenejte do záznamu událostí tyto kroky a milníky.

8 Doporučené 6 Volitelné

	Aktivita	Popis
	Aktualizace náhradního řešení	Vyplnění nebo aktualizace textového pole „Workaround“. Událost označuje zdokumentování dočasné opravy.
Proč je to důležité Měří, jak rychle se firmě poskytne úleva od problému. Je důležité pro KPI „Doba do zpřístupnění náhradního řešení“. Kde data získat Historie požadavku Jira: změna pole „Workaround“ (není prázdné) Zachycení Zaznamená se při úpravě pole Workaround Typ události explicit
	Incident propojen s problémem	Propojení souvisejícího požadavku Incident se záznamem Problem. Zachytí se v tabulce propojení požadavků nebo v historii.
Proč je to důležité Určuje dopad a rozsah problému. Je nezbytné pro KPI „Hloubka propojení incidentů s problémy“ a stanovení priorit podle dopadu na firmu. Kde data získat Propojení požadavků Jira: vytvořeno propojení typu „causes“ nebo „relates to“ Zachycení Zaznamená se při vytvoření propojení mezi požadavky Typ události explicit
	Ověření vyřešení problému	Potvrzení, že oprava problém skutečně vyřešila. Odvozuje se z přechodu stavu na „Resolved“ nebo na konkrétní stav „Verified“.
Proč je to důležité Kontrolní bod, který ověřuje funkčnost opravy. Průtahy v této fázi mohou ukazovat na úzká místa při testování nebo schvalování uživatelem. Kde data získat Historie požadavku Jira: stav se změnil na „Resolved“ nebo „Verified“ Zachycení Porovnejte aktualizace pole stavu Typ události inferred
	Přiřazení skupině podpory	Přiřazení záznamu o problému konkrétnímu technickému týmu nebo skupině podpory. Sleduje se změna vlastního pole „Support Group“, případně pole „Assignee“, pokud se skupiny nepoužívají.
Proč je to důležité Důležité pro analýzu předávání práce a úzkých míst mezi týmy. Časté předávání může ukazovat na neefektivní směrování požadavků. Kde data získat Historie požadavku Jira: změna pole „Support Group“ nebo „Assignee“ Zachycení Zaznamená se při změně pole přiřazení Typ události explicit
	Určení hlavní příčiny	Okamžik, kdy je formálně zaznamenána hlavní příčina. Lze jej odvodit ze změny stavu na „Root Cause Identified“ nebo z vyplnění pole „Root Cause“.
Proč je to důležité Důležitý milník, který ukončuje fázi prošetřování. Je nezbytný pro výpočet KPI „Průměrná doba do odhalení hlavní příčiny“. Kde data získat Historie požadavku Jira: stav se změnil na „Root Cause Identified“ NEBO bylo vyplněno pole „Root Cause“ Zachycení Porovnejte pole stavu nebo ověřte, zda je pole vyplněné Typ události inferred
	Zahájení prošetřování	Změna stavu problému na stav aktivního prošetřování, například „Under Investigation“ nebo „In Progress“. Označuje začátek aktivní práce na problému.
Proč je to důležité Spouští měření doby prošetřování. Pomáhá odlišit čekání ve frontě od skutečné aktivní analýzy. Kde data získat Historie požadavku Jira: stav se změnil na „Under Investigation“ nebo „In Progress“ Zachycení Porovnejte aktualizace pole stavu Typ události inferred
	Záznam o problému uzavřen	Ukončení životního cyklu problému. Zachytí se při změně stavu na „Closed“.
Proč je to důležité Konečný bod instance procesu. Je nezbytný pro výpočet celkové doby průchodu a míry uzavření. Kde data získat Historie požadavku Jira: stav se změnil na „Closed“ Zachycení Zaznamená se při přechodu stavu na Closed Typ události explicit
	Záznam o problému vytvořen	První událost, při které se v systému vytvoří požadavek Problem. V historii požadavku je zaznamenána jako čas vytvoření.
Proč je to důležité Označuje začátek životního cyklu řízení problému a umožňuje sledovat počet případů. Je nezbytný pro výpočet průchodnosti a počtu nově přijatých případů. Kde data získat Tabulka požadavků Jira: časové razítko Created Date nebo karta History: událost Issue Created Zachycení Zaznamená se při potvrzení vytvoření požadavku v systému Typ události explicit
	Kontrola po zavedení změny	Provedení kontroly po zavedení opravy. Zachytí se změnou stavu na „In Review“ nebo aktualizací polí určených pro PIR.
Proč je to důležité Kontrola shody, která ověřuje, zda byly zaznamenány získané poznatky. Podporuje analýzu „Dodržování kontrol po zavedení změny“. Kde data získat Historie požadavku Jira: stav se změnil na „In Review“ NEBO bylo aktualizováno pole „PIR Notes“ Zachycení Porovnejte změny pole stavu nebo polí PIR Typ události inferred
	Porušení SLA	Událost označující, že doba řešení problému překročila stanovenou lhůtu SLA. Vypočítá se porovnáním cílového data SLA s datem vyřešení.
Proč je to důležité Důležité pro reportování shody. Pomáhá zjistit, u kterých priorit nebo kategorií se cíle nejčastěji nedaří plnit. Kde data získat Protokoly SLA v Jira Service Management: „Time to Resolution“ > cílová hodnota, případně vypočítaná hodnota Zachycení Odvoďte z údajů v poli SLA nebo porovnejte Due Date s Resolution Date Typ události calculated
	Propojení požadavku na změnu	Propojení požadavku na změnu (RFC) se záznamem Problem. Označuje zahájení procesu trvalé opravy.
Proč je to důležité Měří prodlevu mezi určením příčiny a zahájením nápravy. Podporuje analýzu KPI „Prodleva při přechodu k řízení změn“. Kde data získat Propojení požadavků Jira: vytvořeno propojení typu „is fixed by“ nebo propojení s požadavkem typu „Change“ Zachycení Zaznamená se při vytvoření propojení s požadavkem typu Change Typ události explicit
	Provedení trvalé opravy	Přechod, který označuje zavedení řešení. Obvykle se odvozuje ze změny stavu na „Implementing“ nebo „Fixed“.
Proč je to důležité Označuje konec technických prací na nápravě. Používá se k měření doby zavedení opravy. Kde data získat Historie požadavku Jira: stav se změnil na „Implemented“, „Pending Verification“ nebo „Fixed“ Zachycení Porovnejte aktualizace pole stavu Typ události inferred
	Změna priority problému	Změna pole Priority v záznamu o problému. Zachytí se sledováním změn pole „Priority“ na kartě History.
Proč je to důležité Označuje zvýšení nebo snížení priority problému. Analýza pomáhá ověřit přesnost počátečního třídění a zjistit, jak dlouho zůstávají nevyřešené případy s vysokou prioritou. Kde data získat Historie požadavku Jira: pole „Priority“ se změnilo z původní hodnoty na novou hodnotu Zachycení Zaznamená se při aktualizaci pole Priority Typ události explicit
	Znovuotevření problému	Přechod problému ze stavu „Resolved“ nebo „Closed“ zpět do aktivního stavu. Označuje neúspěšnou opravu nebo zamítnuté řešení.
Proč je to důležité Základní ukazatel kvality. Časté znovuotevírání může ukazovat na nedostatečnou analýzu hlavní příčiny nebo testování. Kde data získat Historie požadavku Jira: stav se změnil z „Closed“/„Resolved“ na „Open“/„In Progress“ Zachycení Porovnejte posloupnost hodnot pole stavu Typ události inferred

Doporučené Volitelné

Návody k extrakci dat

Jak získat data z Jira Service Management

Kroky

Přihlaste se ve webovém prohlížeči ke své instanci Jira Service Management pomocí účtu, který má pro projekt Problem Management oprávnění „Browse Projects“.
V horní nabídce vyberte Filters a kliknutím na Advanced Issue Search otevřete Issue Navigator.
Přepněte režim vyhledávání na JQL (Jira Query Language), pokud už není vybraný.
Do pole zadejte konkrétní dotaz JQL uvedený níže v části Query, který vyfiltruje záznamy problémů (například project = 'Problem Management'). Zkontrolujte, že časové období odpovídá limitům exportu systému.
Kliknutím na Search ověřte, že seznam obsahuje očekávané záznamy problémů.
V pravém horním rohu Issue Navigator najděte tlačítko Export.
V rozbalovací nabídce vyberte Export XML. Nevybírejte CSV, protože standardní export CSV obsahuje pouze aktuální stav, nikoli historické záznamy změn potřebné pro process mining.
Uložte vytvořený soubor XML (například jira_export.xml) do místní složky, ke které má přístup prostředí pro zpracování dat.
Připravte prostředí Python a nainstalujte potřebnou knihovnu pandas, pokud ji ještě nemáte.
Spusťte skript Python uvedený v části Query a ověřte, že proměnná s cestou k souboru odpovídá umístění uloženého souboru XML.
Skript zpracuje strukturu RSS/XML a získá časové razítko 'Created', položky 'History' se změnami stavu, priority a přiřazení a také 'Issue Links' se souvisejícími incidenty.
Skript vypočítá překročení SLA porovnáním data vyřešení s termínem a vytvoří formátovaný záznam událostí CSV připravený pro ProcessMind.

Konfigurace

Formát exportu: Použijte export XML (RSS), nikoli CSV. Formát XML obsahuje značky <history> a <issuelinks>, které jsou nezbytné pro rekonstrukci průběhu procesu.
Limit řádků: Standardní exporty Jira jsou často omezené na 1 000 problémů na jeden export. U větších datových sad rozdělte extrakci do více exportů a upravte časové období v JQL (například created >= '2023-01-01' AND created < '2023-02-01').
Filtr JQL: Ověřte, že klíč project odpovídá identifikátoru vašeho projektu Problem Management (například PROB, PM).
Časové pásmo systému: Ověřte, že profil uživatele provádějícího export používá stejné časové pásmo jako systém. Zajistíte tak konzistentní časová razítka.
Oprávnění k polím: Uživatel musí mít oprávnění zobrazit historii změn a propojené problémy, aby bylo možné zachytit přechody mezi stavy a odkazy na incidenty.
Vlastní pole: Pokud jsou 'Root Cause' nebo 'Workaround' vlastní pole, upravte logiku párování názvů polí ve skriptu podle konkrétních názvů ve vaší instanci Jira.

Ukázkový dotaz sql

import xml.etree.ElementTree as ET
import pandas as pd
from datetime import datetime
import io

# CONFIGURATION
# Path to the exported Jira XML file
INPUT_FILE = 'jira_export.xml'
OUTPUT_FILE = 'process_mining_event_log.csv'
SOURCE_SYSTEM = 'Jira Service Management'

# JQL USED FOR EXPORT (Reference Only)
# project = "Problem Management" AND created >= "2023-01-01" ORDER BY created DESC

def parse_jira_xml(xml_file):
    tree = ET.parse(xml_file)
    channel = tree.getroot().find('channel')
    
    events = []
    
    # Namespaces are usually not required for standard Jira RSS XML, 
    # but we handle standard tags directly.
    
    for item in channel.findall('item'):
        # 1. Extract Header Attributes
        problem_key = item.find('key').text
        summary = item.find('summary').text if item.find('summary') is not None else ''
        created_str = item.find('created').text
        resolution_date_node = item.find('resolutiondate')
        due_date_node = item.find('duedate')
        
        # Parse base timestamps
        # Jira XML format example: Wed, 4 Oct 2023 14:30:00 +0000
        fmt = '%a, %d %b %Y %H:%M:%S %z'
        created_dt = datetime.strptime(created_str, fmt)
        
        # --- ACTIVITY 1: Problem Record Created ---
        events.append({
            'ProblemKey': problem_key,
            'ActivityName': 'Problem Record Created',
            'EventTimestamp': created_dt,
            'UserKey': item.find('reporter').get('username') if item.find('reporter') is not None else None,
            'SourceSystem': SOURCE_SYSTEM,
            'ProblemSummary': summary,
            'Priority': item.find('priority').text if item.find('priority') is not None else None
        })

        # --- ACTIVITY: Incident Linked / Change Request Linked ---
        # Check <issuelinks> tag
        issue_links = item.find('issuelinks')
        if issue_links is not None:
            for linktype in issue_links.findall('issuelinktype'):
                link_name = linktype.find('name').text # e.g., 'Relates', 'Blocks', 'Caused'
                for outward in linktype.findall('outwardlinks'):
                    for issue_link in outward.findall('issuelink'):
                        linked_key = issue_link.find('issuekey').text
                        # Heuristic: Identify link type based on key pattern or link description
                        activity = None
                        if 'INC' in linked_key: # Customize for your Incident Prefix
                            activity = 'Incident Linked to Problem'
                        elif 'CHG' in linked_key: # Customize for your Change Prefix
                            activity = 'Change Request Linked'
                        
                        if activity:
                             events.append({
                                'ProblemKey': problem_key,
                                'ActivityName': activity,
                                'EventTimestamp': created_dt, # Link timestamp often not in XML, defaulting to created or requires API. fallback.
                                'UserKey': 'System',
                                'SourceSystem': SOURCE_SYSTEM,
                                'ProblemSummary': f'Linked to {linked_key}',
                                'Priority': None
                            })

        # --- PROCESS HISTORY (Status, Priority, Assignment, etc.) ---
        # Note: History is not always in standard RSS. 
        # If utilizing the 'SearchRequestView' XML, history is included inside <customfields> or specific expansion.
        # However, typically standard RSS does NOT include full history.
        # Assuming this XML export includes the Activity Stream or we rely on Custom Field dates for specific milestones.
        
        # LOGIC FOR INFERRING ACTIVITIES FROM CURRENT STATE & DATES (If History missing)
        # Or parsing <subtasks> or <comments> as proxies.
        
        # --- ACTIVITY: SLA Breached ---
        if resolution_date_node is not None and due_date_node is not None:
            res_date = datetime.strptime(resolution_date_node.text, fmt)
            due_date = datetime.strptime(due_date_node.text, fmt)
            
            if res_date > due_date:
                events.append({
                    'ProblemKey': problem_key,
                    'ActivityName': 'SLA Breached',
                    'EventTimestamp': res_date,
                    'UserKey': 'System',
                    'SourceSystem': SOURCE_SYSTEM,
                    'ProblemSummary': summary,
                    'Priority': None
                })

        # --- ACTIVITY: Problem Record Closed / Resolved ---
        if resolution_date_node is not None:
             events.append({
                'ProblemKey': problem_key,
                'ActivityName': 'Problem Record Closed',
                'EventTimestamp': datetime.strptime(resolution_date_node.text, fmt),
                'UserKey': item.find('assignee').get('username') if item.find('assignee') is not None else None,
                'SourceSystem': SOURCE_SYSTEM,
                'ProblemSummary': summary,
                'Priority': None
            })

        # --- MOCKING HISTORY PARSING IF XML HAS HISTORY PLUGIN EXTENSION ---
        # (Standard Jira RSS export is weak on history. 
        # This block assumes the existence of a custom history export or parsing comment logs for keywords).
        
        comments = item.find('comments')
        if comments:
            for comment in comments.findall('comment'):
                body = comment.text.lower()
                c_date = datetime.strptime(comment.get('created'), fmt)
                author = comment.get('author')
                
                act_name = None
                if 'root cause' in body:
                    act_name = 'Root Cause Identified'
                elif 'workaround' in body:
                    act_name = 'Workaround Updated'
                elif 'investigation' in body:
                    act_name = 'Investigation Started'
                
                if act_name:
                    events.append({
                        'ProblemKey': problem_key,
                        'ActivityName': act_name,
                        'EventTimestamp': c_date,
                        'UserKey': author,
                        'SourceSystem': SOURCE_SYSTEM,
                        'ProblemSummary': summary,
                        'Priority': None
                    })

    return pd.DataFrame(events)

# EXECUTION
try:
    df = parse_jira_xml(INPUT_FILE)
    
    # Add global extraction timestamp
    df['LastDataUpdate'] = datetime.now()
    
    # Formatting
    if not df.empty:
        df['EventTimestamp'] = pd.to_datetime(df['EventTimestamp']).dt.strftime('%Y-%m-%d %H:%M:%S')
        
        # Output
        df.to_csv(OUTPUT_FILE, index=False)
        print(f"Success: Extracted {len(df)} events to {OUTPUT_FILE}")
    else:
        print("No events found. Check XML format or JQL.")
        
except Exception as e:
    print(f"Error processing file: {str(e)}")

Kroky

Příprava prostředí: Nainstalujte Python 3.x a knihovny requests a pandas. Budete potřebovat účet Jira Service Management s oprávněním ke čtení příslušného projektu. Pro Jira Cloud vytvořte API token v nastavení účtu Atlassian. Pro Data Center vytvořte osobní přístupový token (PAT).
Zjištění ID vlastních polí: Jira Service Management používá pro vlastní pole dynamická ID (například customfield_10012 pro Support Group nebo SLA). Před spuštěním hlavní extrakce použijte prohlížeč nebo Postman a načtěte jeden konkrétní problém pomocí /rest/api/2/issue/[ISSUE-KEY]. Zjistěte ID polí 'Support Group', 'Workaround', 'Root Cause' a polí SLA.
Nastavení skriptu: Otevřete dodaný skript Python a upravte slovník CONFIG. Zadejte URL, e-mail uživatele a API token. Ve slovníku FIELD_MAPPING nastavte skutečné názvy nebo ID vlastních polí zjištěné v kroku 2. Upravte JQL_QUERY tak, aby zahrnoval váš konkrétní projekt (například project = PM AND issuetype = Problem).
Mapování stavů: Ve slovníku STATUS_MAPPING ve skriptu namapujte konkrétní stavy workflow Jira (například 'Under Investigation', 'Implementing', 'Resolved') na standardní názvy aktivit ProcessMind (například 'Investigation Started', 'Permanent Fix Applied').
Spuštění extrakce: Spusťte skript v terminálu nebo vývojovém prostředí. Skript pomocí Jira Search API s parametrem expand=changelog získá aktuální stav i úplnou historii změn všech polí.
Zpracování dat: Skript projde všechny problémy. Nejprve vytvoří událost 'Problem Record Created' podle časového razítka vytvoření. Poté zpracuje historii změn. U každé položky ověří, zda se změněné pole nachází v seznamu sledovaných polí (Status, Priority, Link a další), a vytvoří odpovídající řádek události.
Zpracování SLA: Skript se pokusí zjistit překročení SLA podle změn vlastních polí souvisejících se SLA nebo přechodů do stavu výslovně označeného jako 'Breached'. Pokud váš systém používá konkrétní automatizaci k označování překročení, upravte funkci _parse_sla_breach.
Transformace dat: Skript převede vnořenou strukturu JSON do tabulky Pandas DataFrame. Časová razítka převede do formátu ISO 8601.
Export: Výsledná datová sada se exportuje do souboru CSV jira_problem_event_log.csv. Otevřete soubor a ověřte, že názvy sloupců odpovídají požadavkům ProcessMind.
Nahrání do ProcessMind: Importujte soubor CSV do ProcessMind. Namapujte ProblemKey jako ID případu, ActivityName jako aktivitu a EventTimestamp jako časové razítko.

Konfigurace

Koncový bod API: Používá /rest/api/2/search, který je kompatibilní s Jira Cloud a většinou verzí Data Center. Podporováno je také API v3, ale v2 obvykle nabízí širší kompatibilitu.
Stránkování: Skript zpracovává rozsáhlé datové sady po částech pomocí startAt a maxResults. Výchozí velikost dávky je 50.
Načtení historie změn: Parametr expand=changelog je nezbytný. Bez něj se vrátí pouze aktuální stav a historie i průběh procesu se ztratí.
Filtrování JQL: Dotaz filtruje podle issuetype = Problem. Při prvním testování doporučujeme přidat filtr časového období (například created >= -180d), abyste omezili objem dat.
Ověření totožnosti: Pro Cloud je podporováno základní ověření pomocí e-mailu a tokenu. Pro Data Center upravte hlavičky tak, aby používaly tokeny Bearer.
Mapování polí: Je nutné správně nastavit mapování. Interní názvy polí Jira pro 'Status' a 'Priority' jsou standardní, ale 'Support Group', 'Root Cause' a 'SLA' jsou téměř vždy vlastní pole s jedinečnými ID (například customfield_12345).

Ukázkový dotaz python

import requests
import pandas as pd
import json
from datetime import datetime
import base64

class=class="hl-string">"hl-comment"># ==========================================
class=class="hl-string">"hl-comment"># CONFIGURATION
class=class="hl-string">"hl-comment"># ==========================================
CONFIG = {
    class="hl-string">"JIRA_URL": class="hl-string">"https://your-domain.atlassian.net",
    class="hl-string">"USER_EMAIL": class="hl-string">"your-email@example.com",
    class="hl-string">"API_TOKEN": class="hl-string">"your-api-token-or-pat",
    class="hl-string">"PROJECT_KEY": class="hl-string">"PM",  class=class="hl-string">"hl-comment"># Problem Management Project Key
    class="hl-string">"LOOKBACK_DAYS": class="hl-string">"180"
}

class=class="hl-string">"hl-comment"># Mappings: Key = Jira Field Name/ID, Value = Activity Name context
class=class="hl-string">"hl-comment"># You must replace class="hl-string">'customfield_XXXXX' with your actual field IDs found via API
FIELD_MAPPING = {
    class="hl-string">"priority": class="hl-string">"Problem Priority Changed",
    class="hl-string">"assignee": class="hl-string">"Assigned to Support Group", class=class="hl-string">"hl-comment"># Fallback if support group field unused
    class="hl-string">"customfield_10010": class="hl-string">"Assigned to Support Group", class=class="hl-string">"hl-comment"># Replace with Support Group Field ID
    class="hl-string">"customfield_10011": class="hl-string">"Workaround Updated",      class=class="hl-string">"hl-comment"># Replace with Workaround Field ID
    class="hl-string">"customfield_10012": class="hl-string">"Root Cause Identified",   class=class="hl-string">"hl-comment"># Replace with Root Cause Field ID
    class="hl-string">"Link": class="hl-string">"Link Event",                           class=class="hl-string">"hl-comment"># Internal name for issue links
    class="hl-string">"issuelinks": class="hl-string">"Link Event"
}

class=class="hl-string">"hl-comment"># Map Jira Workflow Statuses to Standard Activities
class=class="hl-string">"hl-comment"># Update the keys (left side) to match your actual Jira Status names
STATUS_MAPPING = {
    class="hl-string">"Under Investigation": class="hl-string">"Investigation Started",
    class="hl-string">"In Progress": class="hl-string">"Investigation Started",
    class="hl-string">"Root Cause Identified": class="hl-string">"Root Cause Identified",
    class="hl-string">"Implementing": class="hl-string">"Permanent Fix Applied",
    class="hl-string">"Fixed": class="hl-string">"Permanent Fix Applied",
    class="hl-string">"Resolved": class="hl-string">"Resolution Verified",
    class="hl-string">"Verified": class="hl-string">"Resolution Verified",
    class="hl-string">"In Review": class="hl-string">"Post Implementation Review",
    class="hl-string">"Closed": class="hl-string">"Problem Record Closed",
    class="hl-string">"Breached": class="hl-string">"SLA Breached" class=class="hl-string">"hl-comment"># Only if you have a specific status for this
}

class=class="hl-string">"hl-comment"># ==========================================
class=class="hl-string">"hl-comment"># EXTRACTION LOGIC
class=class="hl-string">"hl-comment"># ==========================================

def get_auth_header():
    class=class="hl-string">"hl-comment"># For Cloud (Basic Auth)
    creds = fclass="hl-string">"{CONFIG['USER_EMAIL']}:{CONFIG['API_TOKEN']}"
    encoded = base64.b64encode(creds.encode()).decode()
    return {class="hl-string">"Authorization": fclass="hl-string">"Basic {encoded}", class="hl-string">"Content-Type": class="hl-string">"application/json"}
    class=class="hl-string">"hl-comment"># For Data Center (PAT), uncomment below:
    class=class="hl-string">"hl-comment"># return {class="hl-string">"Authorization": fclass="hl-string">"Bearer {CONFIG['API_TOKEN']}", class="hl-string">"Content-Type": class="hl-string">"application/json"}

def fetch_issues():
    url = fclass="hl-string">"{CONFIG['JIRA_URL']}/rest/api/2/search"
    jql = fclass="hl-string">"project = {CONFIG['PROJECT_KEY']} AND issuetype = Problem AND created >= -{CONFIG['LOOKBACK_DAYS']}d"
    
    all_issues = []
    start_at = 0
    max_results = 50
    
    while True:
        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"
        }
        
        try:
            response = requests.get(url, headers=get_auth_header(), params=params)
            response.raise_for_status()
            data = response.json()
        except Exception as e:
            print(fclass="hl-string">"API Error: {e}")
            break
            
        issues = data.get(class="hl-string">"issues", [])
        if not issues:
            break
            
        all_issues.extend(issues)
        start_at += max_results
        print(fclass="hl-string">"Fetched {len(all_issues)} issues so far...")
        
    return all_issues

def parse_activity(issue):
    events = []
    
    class=class="hl-string">"hl-comment"># Basic Issue Data
    key = issue[class="hl-string">"key"]
    fields = issue[class="hl-string">"fields"]
    summary = fields.get(class="hl-string">"summary", class="hl-string">"")
    class=class="hl-string">"hl-comment"># Current values (for attributes)
    current_priority = fields.get(class="hl-string">"priority", {}).get(class="hl-string">"name", class="hl-string">"")
    current_assignee = fields.get(class="hl-string">"assignee", {}).get(class="hl-string">"displayName") if fields.get(class="hl-string">"assignee") else class="hl-string">"Unassigned"
    
    class=class="hl-string">"hl-comment"># 1. Problem Record Created
    created_time = fields[class="hl-string">"created"]
    events.append({
        class="hl-string">"ProblemKey": key,
        class="hl-string">"ActivityName": class="hl-string">"Problem Record Created",
        class="hl-string">"EventTimestamp": created_time,
        class="hl-string">"UserKey": fields.get(class="hl-string">"creator", {}).get(class="hl-string">"displayName", class="hl-string">"System"),
        class="hl-string">"SupportGroup": current_assignee,
        class="hl-string">"Priority": current_priority,
        class="hl-string">"ProblemSummary": summary,
        class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
    })

    class=class="hl-string">"hl-comment"># Process Changelog
    changelog = issue.get(class="hl-string">"changelog", {}).get(class="hl-string">"histories", [])
    
    for history in changelog:
        timestamp = history[class="hl-string">"created"]
        user = history.get(class="hl-string">"author", {}).get(class="hl-string">"displayName", class="hl-string">"Unknown")
        
        for item in history[class="hl-string">"items"]:
            field = item.get(class="hl-string">"field")
            field_id = item.get(class="hl-string">"fieldId", class="hl-string">"")
            from_str = item.get(class="hl-string">"fromString", class="hl-string">"")
            to_str = item.get(class="hl-string">"toString", class="hl-string">"")
            
            class=class="hl-string">"hl-comment"># 2, 5, 7, 9, 10, 11, 13, 14. Status Changes
            if field == class="hl-string">"status":
                activity = STATUS_MAPPING.get(to_str)
                
                class=class="hl-string">"hl-comment"># Handle Reopened logic explicitly
                if to_str in [class="hl-string">"Open", class="hl-string">"Reopened"] and from_str in [class="hl-string">"Resolved", class="hl-string">"Closed"]:
                    activity = class="hl-string">"Problem Reopened"
                
                if activity:
                    events.append({
                        class="hl-string">"ProblemKey": key,
                        class="hl-string">"ActivityName": activity,
                        class="hl-string">"EventTimestamp": timestamp,
                        class="hl-string">"UserKey": user,
                        class="hl-string">"SupportGroup": current_assignee,
                        class="hl-string">"Priority": current_priority,
                        class="hl-string">"ProblemSummary": summary,
                        class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                    })

            class=class="hl-string">"hl-comment"># 2. Priority Changed
            elif field == class="hl-string">"priority":
                events.append({
                    class="hl-string">"ProblemKey": key,
                    class="hl-string">"ActivityName": class="hl-string">"Problem Priority Changed",
                    class="hl-string">"EventTimestamp": timestamp,
                    class="hl-string">"UserKey": user,
                    class="hl-string">"SupportGroup": current_assignee,
                    class="hl-string">"Priority": to_str,
                    class="hl-string">"ProblemSummary": summary,
                    class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                })

            class=class="hl-string">"hl-comment"># 3. Assigned to Support Group (via custom field or Assignee)
            elif field_id == class="hl-string">"customfield_10010" or field == class="hl-string">"assignee":
                events.append({
                    class="hl-string">"ProblemKey": key,
                    class="hl-string">"ActivityName": class="hl-string">"Assigned to Support Group",
                    class="hl-string">"EventTimestamp": timestamp,
                    class="hl-string">"UserKey": user,
                    class="hl-string">"SupportGroup": to_str,
                    class="hl-string">"Priority": current_priority,
                    class="hl-string">"ProblemSummary": summary,
                    class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                })

            class=class="hl-string">"hl-comment"># 6. Workaround Updated
            elif field_id == class="hl-string">"customfield_10011":
                if to_str: class=class="hl-string">"hl-comment"># Only if value is added/changed to something
                    events.append({
                        class="hl-string">"ProblemKey": key,
                        class="hl-string">"ActivityName": class="hl-string">"Workaround Updated",
                        class="hl-string">"EventTimestamp": timestamp,
                        class="hl-string">"UserKey": user,
                        class="hl-string">"SupportGroup": current_assignee,
                        class="hl-string">"Priority": current_priority,
                        class="hl-string">"ProblemSummary": summary,
                        class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                    })

            class=class="hl-string">"hl-comment"># 7. Root Cause Identified (via Field Population)
            elif field_id == class="hl-string">"customfield_10012":
                if to_str:
                    events.append({
                        class="hl-string">"ProblemKey": key,
                        class="hl-string">"ActivityName": class="hl-string">"Root Cause Identified",
                        class="hl-string">"EventTimestamp": timestamp,
                        class="hl-string">"UserKey": user,
                        class="hl-string">"SupportGroup": current_assignee,
                        class="hl-string">"Priority": current_priority,
                        class="hl-string">"ProblemSummary": summary,
                        class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                    })

            class=class="hl-string">"hl-comment"># 4 & 8. Links (Incident Linked / Change Request Linked)
            elif field == class="hl-string">"Link":
                class=class="hl-string">"hl-comment"># This requires heuristic checking of the linked key or link type
                class=class="hl-string">"hl-comment"># Assuming standard keys: INC-xxxx for Incident, CHG-xxxx or CR-xxxx for Change
                if class="hl-string">"INC-" in to_str or class="hl-string">"Incident" in to_str:
                     events.append({
                        class="hl-string">"ProblemKey": key,
                        class="hl-string">"ActivityName": class="hl-string">"Incident Linked",
                        class="hl-string">"EventTimestamp": timestamp,
                        class="hl-string">"UserKey": user,
                        class="hl-string">"SupportGroup": current_assignee,
                        class="hl-string">"Priority": current_priority,
                        class="hl-string">"ProblemSummary": summary,
                        class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                    })
                elif class="hl-string">"CHG-" in to_str or class="hl-string">"CR-" in to_str or class="hl-string">"Change" in to_str:
                     events.append({
                        class="hl-string">"ProblemKey": key,
                        class="hl-string">"ActivityName": class="hl-string">"Change Request Linked",
                        class="hl-string">"EventTimestamp": timestamp,
                        class="hl-string">"UserKey": user,
                        class="hl-string">"SupportGroup": current_assignee,
                        class="hl-string">"Priority": current_priority,
                        class="hl-string">"ProblemSummary": summary,
                        class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                    })
            
            class=class="hl-string">"hl-comment"># 12. SLA Breached (Detection Logic)
            class=class="hl-string">"hl-comment"># Detection depends heavily on plugins. Common method: check for SLA status field change
            elif class="hl-string">"SLA" in field or class="hl-string">"Time to Resolution" in field:
                if class="hl-string">"breach" in to_str.lower() or class="hl-string">"fail" in to_str.lower():
                    events.append({
                        class="hl-string">"ProblemKey": key,
                        class="hl-string">"ActivityName": class="hl-string">"SLA Breached",
                        class="hl-string">"EventTimestamp": timestamp,
                        class="hl-string">"UserKey": user,
                        class="hl-string">"SupportGroup": current_assignee,
                        class="hl-string">"Priority": current_priority,
                        class="hl-string">"ProblemSummary": summary,
                        class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                    })

    return events

class=class="hl-string">"hl-comment"># ==========================================
class=class="hl-string">"hl-comment"># MAIN EXECUTION
class=class="hl-string">"hl-comment"># ==========================================
if __name__ == class="hl-string">"__main__":
    print(class="hl-string">"Starting extraction...")
    issues = fetch_issues()
    
    all_events = []
    for issue in issues:
        all_events.extend(parse_activity(issue))
        
    df = pd.DataFrame(all_events)
    
    class=class="hl-string">"hl-comment"># Add LastDataUpdate
    df[class="hl-string">"LastDataUpdate"] = datetime.now().isoformat()
    
    class=class="hl-string">"hl-comment"># Export
    filename = class="hl-string">"jira_problem_event_log.csv"
    df.to_csv(filename, index=False)
    print(fclass="hl-string">"Extraction complete. Saved {len(df)} rows to {filename}")

Chcete začít?

Proměňte data o správě problémů v konkrétní podklady pro zlepšení. Stáhněte si průvodce nebo kontaktujte náš tým podpory a začněte s process mining.

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

Stáhnout šablonu

Zlepšete průběh správy problémů

Zkraťte dobu řešení o 30 % a stabilizujte IT prostředí.

Začněte zkušební verzi

Bez platební karty. Nastavení zvládnete během několika minut.

Šablona dat pro správu problémů

Šablona dat pro správu problémů

Atributy správy problémů

Aktivity správy problémů

Návody k extrakci dat

Export z Issue Navigator v Jira Service Management

Kroky

Konfigurace

Ukázkový dotaz sql

Extrakce dat v Pythonu přes Jira REST API včetně historie změn

Kroky

Konfigurace

Ukázkový dotaz python

Chcete začít?

Zlepšete průběh správy problémů