Šablona dat pro správu incidentů

Jira Service Management
Šablona dat pro správu incidentů

Šablona dat pro správu incidentů

Tato šablona vám pomůže systematicky shromáždit data potřebná k analýze procesu správy incidentů. Najdete v ní přehled atributů, které je vhodné sbírat, a aktivit, které je třeba sledovat, i praktický návod, jak data získat ze zdrojového systému. Budete tak mít vše potřebné pro zahájení zlepšování workflow při řešení incidentů.
  • Doporučené atributy ke sběru
  • Aktivity, které je vhodné sledovat
  • 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.

Atributy správy incidentů

Toto jsou doporučená datová pole pro záznam událostí, která umožní důkladnou analýzu procesu správy incidentů.
5 Povinné 6 Doporučené 12 Volitelné
Název Popis
Aktivita
ActivityName
Název konkrétní události nebo změny stavu, ke které u incidentu došlo.
Popis

Aktivita představuje jednotlivý krok nebo událost v životním cyklu správy incidentu, například „Incident vytvořen“, „Incident přiřazen“ nebo „Navrženo řešení“. Obvykle vychází ze změn stavu nebo konkrétních aktualizací zaznamenaných v historii či protokolu změn požadavku v Jira. Analýza pořadí a délky těchto aktivit je hlavním cílem process mining. Odhaluje skutečný průběh procesu, úzká místa a odchylky.

Proč je to důležité

Aktivity tvoří základ procesní mapy a umožňují zobrazit a analyzovat životní cyklus incidentu.

Kde data získat

Vychází z historie požadavku v Jira a údajů v protokolu změn. Zachycují změny stavu a aktualizace důležitých polí.

Příklady
Incident přiřazenŠetření zahájenoIncident vyřešen
Čas zahájení
EventTimestamp
Přesné datum a čas, kdy k aktivitě došlo.
Popis

Tento atribut zaznamenává časové razítko každé aktivity v životním cyklu incidentu. Je nezbytný pro výpočet délky jednotlivých kroků, celkové doby průchodu procesem a čekání mezi kroky. Přesná časová razítka umožňují podrobnou analýzu výkonu, sledování SLA a hledání úzkých míst. Od těchto údajů se odvozují všechny metriky výkonu, například doba vyřešení a délka diagnostiky.

Proč je to důležité

Časová razítka jsou nezbytná pro výpočet časových metrik, pochopení délky procesu a odhalení úzkých míst.

Kde data získat

Jde o datum „created“ u každého záznamu v protokolu změn nebo historii požadavku v Jira.

Příklady
2023-10-26T10:00:00Z2023-10-26T10:05:14Z2023-10-27T14:30:00Z
ID incidentu
IncidentId
Jedinečný identifikátor každého incidentu v Jira Service Management.
Popis

ID incidentu, v Jira často označované jako Issue Key, je jedinečný identifikátor každého nahlášeného incidentu. Propojuje všechny související aktivity, komentáře a změny stavu od vytvoření až po uzavření. V process mining je toto ID nezbytné k rekonstrukci celého životního cyklu každého incidentu a analýze procesu od začátku do konce.

Proč je to důležité

Tento hlavní identifikátor propojuje všechny související události do jednoho případu a tvoří základ každé analýzy process mining.

Kde data získat

Jde o standardní pole „Key“ pro požadavek v Jira Service Management (například „ITSM-123“).

Příklady
INC-10234HELPDESK-5678OPS-9901
Poslední aktualizace dat
LastDataUpdate
Časové razítko poslední aktualizace dat ze zdrojového systému.
Popis

Tento atribut zaznamenává, kdy byla datová sada naposledy aktualizována. Při analýze procesu tak máte přehled o aktuálnosti dat. To je důležité zejména u dashboardů pro průběžné sledování, kde jsou aktuální informace potřebné pro včasná rozhodnutí. Hodnota bývá stejná pro všechny události v rámci jedné dávky získaných dat.

Proč je to důležité

Informuje uživatele o aktuálnosti dat, která je důležitá pro relevanci a přesnost analýzy.

Kde data získat

Jde o časové razítko spuštění získávání dat, které se doplňuje při jejich transformaci.

Příklady
2023-10-27T08:00:00Z2023-10-28T08:00:00Z
Zdrojový systém
SourceSystem
Systém, ze kterého byla data získána.
Popis

Tento atribut označuje původ dat, v tomto případě Jira Service Management. Hodí se zejména v prostředí, kde se pro celkový pohled na proces kombinují data z více systémů. Uvedení zdrojového systému zajišťuje přehled o původu dat a pomáhá při hledání problémů s jejich kvalitou nebo získáváním. V tomto modelu bude hodnota neměnná.

Proč je to důležité

Poskytuje důležitý kontext o původu dat a zajišťuje jejich přehlednost a dohledatelnost, zejména při analýze více systémů.

Kde data získat

Jde o neměnnou hodnotu, kterou je třeba doplnit při získávání dat.

Příklady
Jira Service ManagementJira Cloud
Datum vyřešení
ResolutionDate
Datum a čas, kdy byl incident označen jako vyřešený.
Popis

Tento atribut zaznamenává časové razítko prvního přechodu incidentu do stavu vyřešeno. Označuje konec aktivní práce a slouží jako koncový bod pro výpočet doby vyřešení. Porovnáním data vyřešení s datem vytvoření získáte základní ukazatel efektivity procesu. Tento údaj se používá také při vyhodnocování plnění SLA.

Proč je to důležité

Označuje konec řešení incidentu a umožňuje vypočítat celkovou dobu průchodu procesem i plnění SLA.

Kde data získat

Standardní pole „Resolved“ u požadavku v Jira.

Příklady
2023-10-28T11:20:30Z2023-11-02T10:00:00Z
Datum vytvoření
CreatedDate
Datum a čas, kdy byl incident poprvé vytvořen v systému.
Popis

Tento atribut označuje oficiální začátek životního cyklu incidentu. Jde o výchozí časový údaj pro výpočet celkových metrik, například doby vyřešení. Datum vytvoření je pro každý incident neměnné a v analýze process mining slouží jako začátek celého případu.

Proč je to důležité

Slouží jako výchozí bod pro výpočet celkové doby průchodu procesem a měření SLA.

Kde data získat

Standardní pole „Created“ u požadavku v Jira.

Příklady
2023-10-26T09:58:12Z2023-11-01T15:20:05Z
Priorita
Priority
Úroveň priority přiřazená incidentu, která vyjadřuje naléhavost jeho vyřešení.
Popis

Priorita určuje, jak rychle je třeba incident řešit. Obvykle vychází z dopadu a naléhavosti a přímo ovlivňuje cíle SLA. Analýza incidentů podle priority ukáže, zda se incidenty s vysokou prioritou řeší rychleji než incidenty s nízkou prioritou a zda se priority uplatňují jednotně. Jde o důležitý ukazatel pro filtrování a porovnávání výkonu procesu.

Proč je to důležité

Nezbytné pro analýzu plnění SLA a ověření, zda jsou zdroje správně přiděleny incidentům s největším dopadem.

Kde data získat

Standardní pole „Priority“ u požadavku v Jira.

Příklady
NejvyššíVysokáStředníNízká
Řešitel
Assignee
Uživatel, kterému je aktuálně přiděleno řešení incidentu.
Popis

Řešitel je pracovník podpory nebo jiný uživatel odpovědný za incident v daném okamžiku. Sledování změn řešitele je důležité pro analýzu předávání práce, rozložení pracovní zátěže a zapojení jednotlivých osob do konkrétních kroků procesu. Tento atribut pomáhá odpovědět na otázky týkající se výkonu jednotlivců a rozdělení zdrojů v týmech podpory.

Proč je to důležité

Pomáhá sledovat pracovní zátěž jednotlivců, hledat úzká místa spojená s konkrétními pracovníky podpory a analyzovat vliv předávání práce na dobu vyřešení.

Kde data získat

Standardní pole „Assignee“ u požadavku v Jira.

Příklady
John SmithEmily JonesServiceDeskAgent1
Skupina řešitelů
AssignmentGroup
Tým nebo skupina odpovědná za řešení incidentu.
Popis

Skupina řešitelů označuje tým, kterému je incident přidělen. Může jít o úroveň podpory, například „L1 Helpdesk“, specializovaný tým, jako je „Network Operations“, nebo vývojový tým. Analýza předávání incidentů mezi skupinami pomáhá pochopit eskalace a předávání práce. Umožňuje měřit výkon týmů, hledat úzká místa na úrovni týmů a analyzovat jejich vzájemné závislosti.

Proč je to důležité

Důležité pro analýzu výkonu týmů, průchodnosti a předávání práce mezi různými úrovněmi podpory nebo specializovanými skupinami.

Kde data získat

V Jira se obvykle nastavuje jako vlastní pole, například „Team“ nebo „Assignment Group“. Někdy lze hodnotu odvodit z komponent Jira nebo projektových rolí.

Příklady
Podpora 1. úrovněTým infrastrukturySprávci databází
Stav
Status
Aktuální fáze incidentu v jeho životním cyklu.
Popis

Pole Status označuje aktuální stav incidentu v definovaném workflow, například „Open“, „In Progress“, „Pending Customer“ nebo „Resolved“. Změny stavu jsou hlavním zdrojem záznamu aktivit pro process mining. Analýza času stráveného v jednotlivých stavech je základem pro hledání úzkých míst a zjištění, kde incidenty tráví nejvíce času.

Proč je to důležité

Přímo ukazuje průběh incidentu a je hlavním zdrojem informací pro určení kroků procesu a čekacích dob.

Kde data získat

Standardní pole „Status“ u požadavku v Jira.

Příklady
ProbíháČeká se na zákazníkaVyřešenoUzavřeno
Cílová doba vyřešení
TimeToResolutionTarget
Cílová doba SLA pro vyřešení incidentu.
Popis

Tento atribut určuje maximální očekávanou dobu, za kterou má být incident dané priority nebo typu vyřešen. Skutečná doba vyřešení se s touto hodnotou porovnává při vyhodnocování plnění SLA. Hodnota se obvykle nastavuje dynamicky podle pravidel, která zohledňují například prioritu, závažnost nebo typ požadavku. Je nezbytná pro dashboard ke sledování plnění SLA.

Proč je to důležité

Poskytuje referenční hodnotu pro měření plnění SLA a tvoří základ KPI míry překročení SLA u incidentů.

Kde data získat

Odvozuje se z konfigurace SLA v Jira Service Management. Je třeba určit konkrétní cíl, například „Time to resolution“.

Příklady
4 h8 h3 d
ID propojeného problému
LinkedProblemId
Identifikátor tiketu problému propojeného s tímto incidentem.
Popis

Incidenty, které jsou příznakem hlubšího problému, se často propojují s tiketem typu Problem. Toto pole uchovává ID souvisejícího problému. Analýza těchto vazeb pomáhá pochopit vztah mezi incidenty a problémy, měřit účinnost jejich správy a hledat opakující se incidenty, které vyžadují trvalou opravu.

Proč je to důležité

Propojuje incidenty s problémy, které jsou jejich příčinou. Díky tomu lze analyzovat, jak účinně organizace řeší hlavní příčiny a předchází dalším incidentům.

Kde data získat

Tyto informace jsou uloženy v části „Issue Links“ požadavku v Jira.

Příklady
PROB-123PROB-456Žádný
Jde o opakované řešení
IsRework
Příznak, který označuje, zda se incident znovu řešil, například po opětovném otevření.
Popis

Tento vypočítaný logický atribut označuje incidenty, které se vrátily do předchozí fáze procesu. Nejčastěji jde o incidenty znovu otevřené po vyřešení. Opakované řešení je významným zdrojem neefektivity a nespokojenosti zákazníků. Příznak umožňuje snadno vyčíslit míru opakovaného řešení a zaměřit analýzu na důvody, proč se incidenty nedaří vyřešit napoprvé.

Proč je to důležité

Označuje incidenty, které vyžadují opakovanou práci, a pomáhá odhalovat problémy s kvalitou a neefektivitu procesu.

Kde data získat

Vypočítá se vyhledáním konkrétních posloupností změn stavu v záznamu událostí, například „Resolved“ -> „Reopened“.

Příklady
truefalse
Kategorie hlavní příčiny
RootCauseCategory
Klasifikace základní příčiny incidentu.
Popis

Tento atribut zachycuje základní důvod vzniku incidentu, například „Chyba konfigurace“, „Porucha hardwaru“ nebo „Chyba uživatele“. Obvykle se vyplňuje po prošetření incidentu a je důležitý pro efektivní správu problémů i prevenci dalších incidentů. Analýza kategorií hlavních příčin pomáhá odhalit systémové nedostatky a určit priority zlepšování. Vysoký podíl neznámých příčin může ukazovat na potřebu zlepšit postupy při prošetřování.

Proč je to důležité

Umožňuje analyzovat hlavní příčiny a přejít od reaktivního přístupu k prevenci tím, že pomáhá odhalovat a řešit zdroje incidentů.

Kde data získat

Téměř vždy jde o vlastní pole v Jira. Název i dostupné hodnoty závisí na konkrétní konfiguraci organizace.

Příklady
Chyba konfiguraceVýpadek sítěChyba softwaru
Komponenta
Component
Systém, aplikace nebo část infrastruktury zasažená incidentem.
Popis

Komponenty jsou části projektu Jira, které slouží k rozdělení požadavků do menších skupin, například „User Interface“, „Database“ nebo „API“. Analýza incidentů podle komponent pomáhá určit, které části systému jsou nejčastěji zdrojem problémů. Tyto informace jsou užitečné při hledání hlavní příčiny a plánování zlepšení služby nebo omezení technického dluhu.

Proč je to důležité

Umožňuje filtrovat a analyzovat incidenty podle zasaženého produktu nebo části systému a hledat oblasti s častými technickými problémy.

Kde data získat

Standardní pole „Components“ u požadavku v Jira.

Příklady
Služba ověřováníDashboard pro reportingMobilní aplikace
Oznamovatel
Reporter
Uživatel, který incident původně vytvořil nebo nahlásil.
Popis

Oznamovatel je osoba, často koncový uživatel, případně jiný systém, který incident poprvé zaznamenal. Analýza incidentů podle oznamovatele může pomoci určit uživatele nebo oddělení, u kterých se problémy objevují často. Pomáhá také pochopit průběh komunikace, zejména při analýze aktivit jako „Čeká se na zákazníka“ a „Zákazník odpověděl“.

Proč je to důležité

Pomáhá analyzovat zdroje incidentů, hledat vzorce spojené s konkrétními uživateli nebo odděleními a zjišťovat příčiny prodlev v komunikaci se zákazníky.

Kde data získat

Standardní pole „Reporter“ u požadavku v Jira.

Příklady
Alice JohnsonBob Williamsmonitoring-tool@example.com
Počet předání
HandoffCount
Počet případů, kdy byl incident přeřazen jiné skupině nebo uživateli.
Popis

Tato vypočítaná metrika počítá, kolikrát se během životního cyklu incidentu změnilo pole „Assignee“ nebo „AssignmentGroup“. Vysoký počet předání často ukazuje na neefektivní proces, nízkou úspěšnost vyřešení při prvním kontaktu nebo nedostatek znalostí, což prodlužuje dobu vyřešení. Analýza tohoto KPI pomáhá zjednodušit přidělování práce a zlepšit spolupráci týmů.

Proč je to důležité

Vyjadřuje zdržení a neefektivitu způsobenou přeřazováním a pomáhá hledat příležitosti ke zlepšení procesu.

Kde data získat

Vypočítá se spočítáním změn pole „Assignee“ nebo „AssignmentGroup“ v protokolu změn požadavku.

Příklady
015
Překročení SLA
SlaBreach
Příznak, který určuje, zda doba vyřešení incidentu překročila cílovou hodnotu SLA.
Popis

Tento vypočítaný logický atribut určuje, zda incident překročil SLA „Time to Resolution“. Nabývá hodnoty true, pokud je „IncidentResolutionCycleTime“ vyšší než „TimeToResolutionTarget“. Příznak usnadňuje analýzu a vizualizaci. Umožňuje snadno filtrovat a agregovat data pro výpočet KPI míry překročení SLA. Jde o hlavní ukazatel výkonu pro dashboard sledování plnění SLA.

Proč je to důležité

Poskytuje jednoznačný výsledek plnění SLA, usnadňuje výpočet míry překročení a pomáhá určit problémové oblasti.

Kde data získat

Vypočítá se jako („IncidentResolutionCycleTime“ > „TimeToResolutionTarget“).

Příklady
truefalse
Řešení
Resolution
Konečný výsledek nebo důvod vyřešení incidentu.
Popis

Pole Resolution vysvětluje, proč byl incident označen jako vyřešený. Mezi běžné hodnoty patří „Fixed“, „Duplicate“, „Won't Do“ nebo „Cannot Reproduce“. Analýza četnosti jednotlivých typů řešení může ukázat kvalitu příchozích hlášení a účinnost řešení incidentů. Například vysoký počet případů označených jako „Duplicate“ může poukazovat na problém při vytváření incidentů nebo jejich prvotním posouzení.

Proč je to důležité

Doplňuje kontext výsledku incidentu, pomáhá třídit způsoby řešení a hledat trendy v uzavírání incidentů.

Kde data získat

Standardní pole „Resolution“ u požadavku v Jira. Obvykle se vyplní při přechodu požadavku do kategorie stavu „Done“.

Příklady
HotovoOpravenoDuplicitníNebude opraveno
Typ požadavku
IssueType
Typ požadavku, například incident, servisní požadavek nebo problém.
Popis

Jira pomocí typů požadavků rozlišuje různé druhy práce. Při správě incidentů je hlavním typem „Incident“, ale relevantní mohou být i jiné typy, například „Sub-task“. Tento atribut umožňuje filtrovat datovou sadu pouze na incidenty a zaměřit analýzu process mining na správný proces.

Proč je to důležité

Zajišťuje, že se analýza zaměřuje na incidenty a odděluje je od jiných typů práce, jako jsou servisní požadavky nebo změny.

Kde data získat

Standardní pole „Issue Type“ u požadavku v Jira.

Příklady
IncidentIT podporaChyba v softwaru
Typ požadavku zákazníka
CustomerRequestType
Konkrétní typ požadavku, který zákazník odeslal prostřednictvím servisního portálu.
Popis

Toto pole třídí požadavky z pohledu zákazníka podle nabídky na portálu Jira Service Management, například „Nahlásit problém se systémem“. Poskytuje srozumitelné označení incidentu, které se může lišit od interního pole „Issue Type“. Analýza tohoto atributu ukazuje, jak zákazníci vnímají a nahlašují problémy, a pomáhá zlepšit podobu portálu i nabídku služeb.

Proč je to důležité

Nabízí pohled na kategorie incidentů z perspektivy zákazníka. Hodí se pro analýzu poptávky a zlepšování zákaznické zkušenosti.

Kde data získat

Pole „Customer Request Type“, které je specifické pro projekty Jira Service Management.

Příklady
Získat IT podporu > Nahlásit problém se systémemE-mail > Žádost o přístup
Závažnost
Severity
Míra dopadu incidentu na provoz organizace.
Popis

Závažnost vyjadřuje dopad incidentu na provoz organizace, od potíží jednoho uživatele až po výpadek kritického systému. Priorita určuje pořadí řešení, zatímco závažnost ukazuje celkový dopad na organizaci. Analýza podle závažnosti pomáhá vyhodnotit průběh incidentů s největším dopadem. Často se kombinuje s prioritou, aby analýza lépe zohlednila různé situace.

Proč je to důležité

Ukazuje dopad na provoz organizace a umožňuje zaměřit analýzu na incidenty s nejzávažnějšími následky.

Kde data získat

Obvykle jde o vlastní pole v Jira, protože nepatří mezi standardní systémová pole. Podrobnosti najdete v konfiguraci projektu Jira Service Management.

Příklady
KritickáZávažnáMenšíZanedbatelná
Povinné Doporučené Volitelné

Aktivity při správě incidentů

Toto jsou důležité kroky a milníky procesu, které je třeba zaznamenat do záznamu událostí, aby bylo možné přesně odhalit a analyzovat workflow řešení incidentů.
7 Doporučené 8 Volitelné
Aktivita Popis
Čeká se na zákazníka
Označuje okamžik, kdy tým podpory čeká na informace nebo akci od zákazníka. Událost se odvozuje od změny stavu na vyhrazený stav čekání, například „Waiting for customer“.
Proč je to důležité

Oddělení této doby čekání je důležité pro přesné měření SLA, protože se často nezapočítává do doby řešení. Pomáhá také analyzovat prodlevy v odpovědích zákazníků.

Kde data získat

Událost se odvozuje z historie změn stavu požadavku. Odpovídá časovému razítku okamžiku, kdy se stav změní na „Waiting for customer“ nebo podobný stav.

Zachycení

Zjistěte časové razítko změny stavu na „Waiting for customer“.

Typ události inferred
Incident uzavřen
Označuje konečné administrativní uzavření požadavku na incident po jeho vyřešení a ověření. Událost se odvozuje od změny stavu na „Closed“.
Proč je to důležité

Jde o závěrečnou událost procesu. Analýza doby mezi stavy „Resolved“ a „Closed“ může odhalit prodlevy při administrativním dokončení nebo čekání na potvrzení od uživatele.

Kde data získat

Událost se odvozuje z historie změn stavu požadavku. Odpovídá časovému razítku okamžiku, kdy se stav změní na konečný stav „Closed“.

Zachycení

Zjistěte časové razítko změny stavu na „Closed“.

Typ události inferred
Incident vyřešen
Tato činnost potvrzuje, že incident byl úspěšně vyřešen a služba obnovena. Často se shoduje se změnou stavu na „Resolved“.
Proč je to důležité

Jde o hlavní milník úspěšného dokončení procesu. Doba do tohoto okamžiku je nejčastěji sledovaným KPI a označuje dobu do vyřešení (TTR).

Kde data získat

Událost se odvozuje od změny stavu na „Resolved“. V mnoha workflow jde o stejnou událost jako „Řešení navrženo“ a označuje hlavní okamžik vyřešení.

Zachycení

Zjistěte časové razítko změny stavu na „Resolved“.

Typ události inferred
Incident vytvořen
Označuje oficiální začátek životního cyklu incidentu, kdy je odesláno hlášení a v Jira vznikne nový požadavek. Tato událost se zaznamená při vytvoření nového požadavku typu „Incident“ v systému.
Proč je to důležité

Jde o hlavní počáteční událost procesu. Doba od této činnosti do vyřešení je základním ukazatelem pro měření celkové doby průchodu procesem a dodržování SLA.

Kde data získat

Jde o výslovně zaznamenanou událost, která vychází z časového razítka pole „created“ incidentu v Jira. Událost vytvoření požadavku se zaznamená do jeho historie.

Zachycení

Použijte časové razítko vytvoření požadavku.

Typ události explicit
Incident znovu přiřazen
K této události dochází, když se incident po prvním přiřazení převede od jednoho uživatele podpory nebo skupiny k jinému. Událost se odvozuje od každé změny pole „Assignee“ nebo „Assigned Group“.
Proč je to důležité

Sledování opětovného přiřazení je důležité pro analýzu předávání. Časté změny přiřazení obvykle ukazují na neefektivní postup, nedostatek znalostí nebo chybné počáteční směrování, což prodlužuje dobu řešení.

Kde data získat

Událost se odvozuje z historie požadavku. Zaznamenejte každou změnu pole „Assignee“ po jeho prvním vyplnění. Každá změna představuje nové přiřazení.

Zachycení

Po prvním přiřazení zjistěte další změny pole „Assignee“.

Typ události inferred
Řešení navrženo
Tato činnost označuje, že bylo nalezeno a zavedeno řešení a incident čeká na potvrzení nebo závěrečné ověření. Odvozuje se od změny stavu na „Resolved“.
Proč je to důležité

Jde o důležitý milník, který označuje konec aktivní práce týmu podpory. Často se při této události zastaví měření SLA.

Kde data získat

Událost se odvozuje z historie změn stavu požadavku. Časové razítko odpovídá okamžiku, kdy se stav změní na „Resolved“ nebo ekvivalentní stav.

Zachycení

Zjistěte časové razítko změny stavu na „Resolved“.

Typ události inferred
Šetření zahájeno
Označuje, že přiřazený uživatel podpory začal aktivně diagnostikovat incident. Obvykle se odvozuje ze změny stavu požadavku z „Open“ nebo „New“ na „In Progress“.
Proč je to důležité

Tento důležitý milník označuje začátek aktivního řešení. Doba do této činnosti pomáhá odhalit počáteční čekání ve frontě a nedostupnost zdrojů.

Kde data získat

Událost se odvozuje z historie změn stavu požadavku. Časové razítko události odpovídá okamžiku, kdy se stav změní na stav označující aktivní práci, například „In Progress“.

Zachycení

Zjistěte časové razítko změny stavu na „In Progress“.

Typ události inferred
Incident přiřazen
Tato činnost označuje první přiřazení incidentu uživateli podpory nebo skupině, která ho bude řešit. Zaznamená se při prvním vyplnění pole „Assignee“ nebo „Assigned Group“.
Proč je to důležité

Měří dobu do první reakce a přiřazení, která je důležitou součástí ukazatelů SLA. Pomáhá odhalit prodlevy před zahájením aktivního šetření.

Kde data získat

Událost se odvozuje z historie požadavku. Vyhledejte první změnu pole „Assignee“, jehož předchozí hodnota byla „Unassigned“.

Zachycení

V historii požadavku zjistěte první aktualizaci pole „Assignee“.

Typ události inferred
Incident znovu otevřen
Označuje situaci, kdy se dříve vyřešený incident znovu aktivuje, protože se problém opakoval nebo oprava nebyla účinná. Událost se odvozuje od změny stavu z „Resolved“ nebo „Closed“ zpět na otevřený stav.
Proč je to důležité

Opětovně otevřené incidenty přímo vypovídají o kvalitě řešení a jsou hlavním ukazatelem opakované práce. Analýza těchto událostí pomáhá odhalit předčasná uzavření a neúčinná řešení.

Kde data získat

Událost se odvozuje z historie změn stavu požadavku. Zaznamená se, když se stav změní z konečného stavu, například „Resolved“ nebo „Closed“, zpět na „Open“ nebo „In Progress“.

Zachycení

Zjistěte změnu stavu z „Resolved“ nebo „Closed“ na otevřený stav.

Typ události inferred
Komentář přidán
Označuje událost, při které uživatel přidá komentář k požadavku na incident, například sdělení nebo poznámku. Jde o výslovně zaznamenanou událost, která se uloží při každém přidání komentáře.
Proč je to důležité

Analýza četnosti komentářů může ukázat vzorce komunikace, efektivitu spolupráce i složitost incidentu. Pomáhá odhalit incidenty, které vyžadují nadměrnou komunikaci.

Kde data získat

Jde o výslovně zaznamenanou událost. Jira ukládá každý komentář s časovým razítkem a jménem autora. Údaje jsou dostupné v historii komentářů požadavku nebo prostřednictvím API.

Zachycení

Použijte časové razítko každého komentáře přidaného k požadavku.

Typ události explicit
Náhradní řešení poskytnuto
Označuje zavedení dočasné opravy, která obnoví službu, než bude připraveno trvalé řešení. Událost lze odvodit ze změny stavu nebo konkrétního komentáře.
Proč je to důležité

Doba do poskytnutí náhradního řešení je důležitým ukazatelem rychlosti obnovy služby. Pomáhá rozlišit dočasné zmírnění dopadu od trvalého vyřešení.

Kde data získat

Tato událost se často odvozuje nepřímo. Může jít o změnu stavu na „Workaround Provided“ nebo o přidání veřejného komentáře obsahujícího konkrétní výraz, například „workaround“.

Zachycení

Zjistěte konkrétní změnu stavu nebo klíčové slovo v komentáři.

Typ události inferred
Předáno specializovanému týmu
Označuje eskalaci incidentu ke specializovanému týmu, například na podporu druhé úrovně nebo do vývoje, který poskytne pokročilou podporu. Událost se odvozuje od změny vlastního pole „Support Team“ nebo od konkrétního opětovného přiřazení.
Proč je to důležité

Ukazuje incidenty, které vyžadují specializované znalosti, a sleduje předávání mezi různými úrovněmi podpory. Pomáhá odhalit úzká místa ve specializovaných týmech a analyzovat vzorce eskalací.

Kde data získat

Událost se odvozuje z historie požadavku. Sledujte změny vlastního pole označujícího přiřazený tým nebo změnu pole „Assignee“ na člena známé specializované skupiny.

Zachycení

Zjistěte změnu vlastního pole „Assigned Team“ nebo konkrétní změny přiřazeného uživatele.

Typ události inferred
Priorita incidentu určena
Označuje nastavení priority nebo závažnosti incidentu, které určuje jeho naléhavost a dopad na provoz. Obvykle se odvozuje od prvního vyplnění nebo změny polí „Priority“ či „Severity“ po vytvoření incidentu.
Proč je to důležité

Sledování určování priorit pomáhá zjistit, zda se incidenty posuzují včas a jednotně. Prodleva v tomto kroku může přímo ovlivnit výpočty SLA i rozdělení zdrojů.

Kde data získat

Událost se odvozuje z historie požadavku, která zaznamenává změny všech polí. Po vytvoření požadavku vyhledejte první změnu pole „Priority“ nebo vlastního pole „Severity“.

Zachycení

V historii požadavku zjistěte první změnu pole „Priority“.

Typ události inferred
Propojeno s požadavkem typu Problem
K této události dochází, když se incident propojí s požadavkem typu „Problem“ kvůli analýze příčin. Jde o výslovně zaznamenanou událost, která nastane při vytvoření vazby „relates to“ nebo „caused by“ na požadavek typu Problem.
Proč je to důležité

Sledování tohoto propojení je důležité pro pochopení toho, jak účinně organizace přechází od zmírnění dopadu incidentu k analýze příčin a prevenci.

Kde data získat

Jde o výslovně zaznamenanou událost v historii propojení požadavku. Každé vytvoření propojení má časové razítko a lze vyfiltrovat propojení s požadavky typu „Problem“.

Zachycení

Použijte časové razítko vytvoření propojení s požadavkem typu „Problem“.

Typ události explicit
Zákazník odpověděl
Označuje, že zákazník poskytl požadované informace a incident může pokračovat. Událost se odvozuje od změny stavu z „Waiting for customer“ zpět na aktivní stav.
Proč je to důležité

Tato činnost označuje konec prodlevy způsobené čekáním na zákazníka. Analýza doby mezi událostmi „Čeká se na zákazníka“ a touto událostí ukáže průměrnou dobu odpovědi zákazníka.

Kde data získat

Událost se odvozuje z historie změn stavu požadavku. Nastane, když se stav změní z „Waiting for customer“ na stav jako „In Progress“. Změnu často vyvolá komentář zákazníka.

Zachycení

Zjistěte změnu stavu z „Waiting for customer“ na „In Progress“.

Typ události inferred
Doporučené Volitelné

Návody na získání dat

Jak získat data z Jira Service Management

Chcete začít?

Využijte tuto šablonu dat ke zlepšení správy incidentů, odhalení neefektivity a zkrácení doby řešení. Začněte zlepšovat svůj proces ještě dnes.

Zlepšete správu incidentů a vyřešte je rychleji

Zkraťte MTTR o 35 % a zvyšte spokojenost uživatelů díky efektivnějším procesům.

Spustit zkušební verzi

Bez platební karty • Nastavení za 5 minut