Šablona dat pro správu incidentů
Šablona dat pro správu incidentů
- Doporučené atributy ke sběru
- Aktivity, které je vhodné sledovat
- Návod na získání dat z Jira Service Management
Atributy správy incidentů
| 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á
|
|||
Aktivity při správě incidentů
| 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
|
|||
Návody na získání dat
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.
Bez platební karty • Nastavení za 5 minut