Šablona dat pro správu incidentů
Šablona dat pro správu incidentů
Toto je obecná šablona dat pro process mining pro proces Správa incidentů. Podrobnější pokyny najdete v šablonách pro konkrétní systémy.
Vyberte konkrétní systém- Univerzální struktura dat pro jakýkoli systém správy incidentů
- Doporučené atributy a činnosti pro důkladnou analýzu
- Pokyny k extrakci dat včetně příkladů pro konkrétní systémy
Atributy správy incidentů
| Název | Popis | ||
|---|---|---|---|
| Časové razítko události EventTimestamp | Přesné datum a čas, kdy u incidentu došlo ke konkrétní aktivitě nebo události. | ||
| Popis Časové razítko události označuje přesný okamžik, kdy aktivita proběhla. Každá aktivita v životním cyklu incidentu by měla mít vlastní časové razítko, aby bylo možné určit pořadí událostí. Tento atribut je nezbytný pro časovou analýzu v process mining. Umožňuje vypočítat dobu mezi aktivitami, trvání jednotlivých kroků i celkovou dobu vyřešení incidentu. Analýza časových razítek pomáhá organizacím najít úzká místa, měřit dodržování SLA a sledovat změny výkonnosti procesu v čase. Časová razítka jsou základem pro výpočet ukazatelů výkonnosti, například průměrné doby vyřešení. Proč je to důležité Určuje časové pořadí událostí, které je nezbytné pro výpočet dob trvání, hledání úzkých míst a analýzu výkonnosti procesu v čase. Kde data získat Najdete ho v záznamech událostí, tabulkách historie auditu nebo jako datum poslední změny či vytvoření konkrétních souvisejících záznamů. Příklady 2023-10-26T10:00:00Z2024-01-15T14:35:10Z2023-11-01T09:12:45Z | |||
| ID incidentu IncidentId | Jedinečný identifikátor přiřazený každému incidentu. Slouží jako primární klíč pro sledování incidentu po celý jeho životní cyklus. | ||
| Popis ID incidentu je jedinečný alfanumerický kód, který odlišuje jeden incident od ostatních v systému. Vygeneruje se při vytvoření incidentu a zůstává stejné, dokud není incident trvale archivován nebo odstraněn. V process mining slouží ID incidentu jako Case ID a základ analýzy. Software díky němu propojí související události, změny stavů a aktivity do jedné instance procesu. Když analytici seskupí události podle stejného ID incidentu, mohou přesně zmapovat celý průběh každého incidentu od prvního nahlášení až po vyřešení a uzavření. Proč je to důležité Tento identifikátor je nezbytný pro propojení souvisejících aktivit a událostí a rekonstrukci celého životního cyklu incidentu v process mining. Kde data získat Jde o primární klíč incidentu, který se obvykle nachází v záhlaví nebo hlavním záznamu každé tabulky či objektu incidentů. Příklady INC0010032TICKET-84321789456123 | |||
| Název aktivity ActivityName | Název konkrétní provozní aktivity, události nebo změny stavu, ke které došlo během životního cyklu incidentu. | ||
| Popis Název aktivity popisuje konkrétní krok nebo úkol v procesu správy incidentů. Tyto aktivity tvoří jednotlivé kroky procesní mapy. Mohou zahrnovat automatické systémové události, například „Zjištěno porušení SLA“, i ruční úkony uživatele, například „Přiřazen agent“ nebo „Poskytnuto náhradní řešení“. Tento atribut je pro analýzu v process mining zásadní. Určuje uzly v procesním grafu a umožňuje analytikům zobrazit tok práce, najít obvyklé postupy, odhalit úzká místa a analyzovat odchylky od standardního postupu. Podrobnost a srozumitelnost názvů aktivit přímo ovlivňují kvalitu a hloubku získaných poznatků. Proč je to důležité Tento atribut určuje jednotlivé kroky procesu a umožňuje zobrazit a analyzovat průběh životního cyklu incidentu. Kde data získat Často se odvozuje z kombinace záznamů událostí, auditních stop, záznamů o změnách stavu nebo polí s popisem úkolu v systému správy incidentů. Příklady Incident vytvořenPřiřazena skupinaIncident vyřešenZměna stavu na čekající | |||
| Poslední aktualizace dat LastDataUpdate | Časové razítko označující, kdy byla data tohoto záznamu naposledy obnovena ze zdrojového systému. | ||
| Popis Časové razítko Poslední aktualizace dat uvádí, kdy byla data naposledy získána nebo synchronizována ze zdrojového systému. Toto pole metadat informuje o aktuálnosti analyzovaných dat. Při analýze v process mining pomáhá tento atribut posoudit, jak aktuální jsou získané poznatky. Uživatelé díky němu vědí, zda pracují s aktuálními informacemi, nebo se snímkem dat z dřívější doby. Tento kontext je důležitý pro provozní dohled i pro rozhodování na základě aktuálních a relevantních dat. Proč je to důležité Ukazuje aktuálnost dat, takže analytici vědí, jak současný je jejich pohled na proces. Kde data získat Tato hodnota se obvykle vytvoří a zapíše do každého záznamu při extrakci a transformaci dat (ETL). Příklady 2023-10-26T23:59:59Z2024-01-16T04:00:10Z2023-11-02T01:05:00Z | |||
| Zdrojový systém SourceSystem | Název nebo identifikátor systému, ze kterého byla data o incidentech získána. | ||
| Popis Atribut Zdrojový systém označuje původ dat. V prostředí s více nástroji ITSM nebo integrovanými systémy pomáhá rozlišit záznamy z různých zdrojů. Tento atribut se přímo nepoužívá při tvorbě procesní mapy, ale pomáhá ověřovat a spravovat data. Analytici díky němu mohou dohledat původ dat, porozumět případným rozdílům mezi systémy a rozdělit analýzu podle zdroje. V jedné organizaci lze například porovnat procesy správy incidentů v systémech ServiceNow a Jira. Proč je to důležité Poskytuje kontext o původu dat, který je důležitý pro jejich ověřování, řešení problémů a porovnávání v prostředí s více systémy. Kde data získat Často jde o neměnnou hodnotu přidanou při extrakci dat nebo o pole dostupné v tabulkách zdrojového systému. Příklady ServiceNowJira Service ManagementBMC HelixZendesk | |||
| Kanál nahlášení ReportingChannel | Způsob nebo kanál, kterým byl incident nahlášen, například e-mail, telefon nebo samoobslužný portál. | ||
| Popis Kanál nahlášení označuje, odkud přišlo oznámení incidentu. Tento atribut sleduje, jak uživatelé kontaktují podporu, ať už přímo telefonicky, nebo automaticky prostřednictvím upozornění ze systémového monitoringu. Analýza procesu podle kanálu nahlášení může odhalit rozdíly v efektivitě. Incidenty nahlášené přes samoobslužný portál se například mohou vyřešit rychleji, protože už při nahlášení často obsahují strukturovanější informace. Tato analýza pomáhá organizacím optimalizovat kanály podpory a podporovat využívání účinnějších způsobů nahlášení. Proč je to důležité Pomáhá analyzovat efektivitu a postupy řešení incidentů podle jejich zdroje a poskytuje podklady pro volbu kanálů i rozdělení zdrojů. Kde data získat Tyto informace se obvykle zaznamenají automaticky nebo je agent vybere při vytvoření incidentu. Příklady E-mailTelefonSamoobslužný portálUpozornění systému | |||
| Kategorie incidentu IncidentCategory | Klasifikace incidentu, často uspořádaná do hierarchie, například Hardware > Notebook > Baterie. | ||
| Popis Kategorie incidentu umožňuje přehledně klasifikovat incidenty podle jejich povahy. Obvykle jde o hierarchické pole, které umožňuje postupně zpřesňovat klasifikaci a řadit incidenty do logických skupin pro vykazování a analýzu. Kategorizace je důležitá pro analýzu hlavních příčin a trendů. Když organizace analyzují procesní mapy filtrované podle kategorií, mohou odhalit opakující se problémy a vzorce spojené s konkrétními typy incidentů. Proces řešení incidentu typu „Software“ může například vypadat úplně jinak než u incidentu typu „Hardware“. Tato data slouží k výpočtu KPI, jako je přesnost prvotní kategorizace a míra opakovaných incidentů. Proč je to důležité Je důležitá pro analýzu hlavních příčin, hledání trendů u opakovaných incidentů a pochopení toho, jak se řeší různé typy problémů. Kde data získat Jde o standardní, často povinnou sadu polí v záznamu incidentu, která slouží ke klasifikaci. Příklady Software | Aplikace | Problém s přihlášenímHardware | Tiskárna | NereagujeSíť | Wi-Fi | Pomalé připojení | |||
| Priorita Priority | Přiřazená úroveň priority incidentu, která určuje jeho naléhavost a pořadí řešení. | ||
| Popis Priorita určuje relativní důležitost incidentu a požadovanou rychlost reakce. Často se stanovuje podle kombinace dopadu a naléhavosti incidentu. Úrovně obvykle sahají od kritické po nízkou. Analýza incidentů podle priority v process mining ukazuje, jak proces zvládá různé úrovně naléhavosti. Analytici mohou porovnat dobu řešení incidentů s vysokou a nízkou prioritou a zjistit, zda se dodržují SLA a zda jsou zdroje rozděleny účelně. Pomáhá také odpovědět na otázku, zda se nejzávažnější incidenty skutečně řeší nejrychleji. Proč je to důležité Umožňuje analyzovat výkonnost procesu při různých úrovních naléhavosti a ověřit, zda se kritické incidenty řeší rychleji než ostatní. Kde data získat Jde o standardní pole v hlavním záznamu incidentu. Může se nastavit ručně nebo vypočítat automaticky podle dopadu a naléhavosti. Příklady 1 - Kritická2 - Vysoká3 - Střední4 - Nízká | |||
| Přiřazená skupina AssignedGroup | Tým podpory, fronta nebo skupina, která právě odpovídá za řešení incidentu. | ||
| Popis Přiřazená skupina označuje tým, který v daném okamžiku odpovídá za incident. Incidenty se často předávají mezi různými skupinami, například mezi podporou první úrovně, síťovým týmem druhé úrovně a týmem podpory aplikací třetí úrovně. Tento atribut je důležitý pro analýzu předávání práce a vytížení. Process mining z těchto dat zobrazí předávání incidentů mezi týmy, změří dobu strávenou ve frontě každého týmu a odhalí úzká místa způsobená častým přeřazováním. Pomáhá odpovídat na otázky týkající se efektivity a spolupráce týmů a tvoří základ dashboardu Analýza předávání a přeřazování. Proč je to důležité Je důležitý pro analýzu předávání práce mezi týmy, měření čekání ve frontách a pochopení výkonnosti jednotlivých týmů i rozložení jejich vytížení. Kde data získat Tyto informace se obvykle ukládají do záznamu incidentu a aktualizují se při každém přiřazení incidentu novému týmu. Příklady Podpora uživatelůProvoz sítěSpráva databázíPodpora aplikací, 2. úroveň | |||
| Přiřazený agent AssignedAgent | Konkrétní pracovník podpory nebo uživatel pověřený řešením incidentu. | ||
| Popis Přiřazený agent označuje konkrétní osobu odpovědnou za incident. Přiřazená skupina určuje tým, zatímco agent je pracovník, který řešení provádí. Tento atribut umožňuje podrobnější analýzu výkonnosti a vytížení. Vedoucí mohou sledovat přiřazení jednotlivým agentům, vyhodnocovat jejich produktivitu, určovat potřeby školení a vyvažovat rozdělení práce. V process mining může odhalit složité vzorce přeřazování, které nejsou na úrovni skupin vidět, a pomáhá pochopit, jak jednotliví pracovníci ovlivňují dobu řešení. Proč je to důležité Umožňuje podrobně analyzovat vytížení a výkonnost jednotlivců i přeřazování v rámci týmů a mezi nimi. Kde data získat Toto pole najdete v hlavním záznamu incidentu. Aktualizuje se, když agent převezme odpovědnost nebo je k incidentu přiřazen. Příklady Jan NovákJana Novákováagent.12345Eva Dvořáková | |||
| Stav incidentu IncidentStatus | Aktuální nebo historický stav incidentu v jeho životním cyklu, například „Nový“, „Probíhá“ nebo „Uzavřeno“. | ||
| Popis Stav incidentu označuje fázi, ve které se incident nachází v konkrétním okamžiku. Poskytuje přehled o tom, jak daleko je řešení. Mezi běžné stavy patří nový, přiřazený, probíhající, čekající, vyřešený a uzavřený. Tento atribut je pro analýzu procesu zásadní, protože změny stavu často určují aktivity v procesní mapě. Analýza doby strávené v jednotlivých stavech pomáhá najít úzká místa, například incidenty, které dlouho čekají. Stav se používá také k výpočtu počtu otevřených incidentů a sledování postupu jejich řešení. Proč je to důležité Pomáhá sledovat průběh incidentu a často se z něj odvozují aktivity procesní mapy. Analýza doby v jednotlivých stavech odhalí prodlevy. Kde data získat Obvykle je dostupný jako hlavní pole v záznamu incidentu nebo v jeho historii. Příklady NovýProbíháČeká se na zákazníkaVyřešenoUzavřeno | |||
| Závažnost Severity | Míra dopadu incidentu na provoz, která vyjadřuje, jak výrazně ovlivňuje uživatele nebo služby. | ||
| Popis Závažnost vyjadřuje dopad incidentu na provoz. Určuje, jak vážný problém je, bez ohledu na jeho naléhavost. Například výpadek celého systému má vysokou závažnost, zatímco drobná kosmetická chyba nízkou. Analýza incidentů podle závažnosti pomáhá organizacím zjistit, které typy problémů způsobují největší narušení provozu. Process mining může ukázat, zda se incidenty s vysokou závažností řeší jiným, přímočařejším postupem. Tento atribut je důležitý při analýze hlavních příčin a při přidělování zdrojů na proaktivní správu problémů, která má předcházet opakování nejzávažnějších incidentů. Proč je to důležité Umožňuje rozdělit incidenty do skupin a zjistit, zda se problémy s velkým dopadem řeší jinak nebo účinněji než problémy s malým dopadem. Kde data získat Standardní pole v záznamu incidentu, které se často používá spolu s naléhavostí při určování priority. Příklady 1 - Vysoká2 - Střední3 - NízkáKritická | |||
| Způsob vyřešení ResolutionMethod | Kód, kategorie nebo popis způsobu, jakým byl incident nakonec vyřešen. | ||
| Popis Způsob vyřešení popisuje výsledek incidentu a postup, kterým se vyřešil. Může jít o standardizovaný kód nebo volný text popisující provedené kroky. Příklady: „Poučení uživatele“, „Nasazena softwarová oprava“, „Závada nezjištěna“ nebo „Duplicitní incident“. Tento atribut poskytuje důležitý kontext k závěru procesu. Analýza incidentů podle způsobu vyřešení v process mining pomáhá posoudit účinnost různých řešení. Může odhalit případy uzavřené bez skutečné opravy nebo běžné způsoby řešení konkrétních kategorií incidentů. Tyto poznatky lze využít při tvorbě znalostní báze a zvyšování podílu vyřešení při prvním kontaktu. Proč je to důležité Ukazuje, jak se problémy řeší, a pomáhá hledat příležitosti k automatizaci, rozvoji znalostní báze a školení. Kde data získat Obvykle jde o pole, které pracovník podpory vyplní při změně stavu incidentu na „Vyřešeno“ nebo „Uzavřeno“. Příklady Vyřešeno podporou uživatelůZávada nezjištěnaDuplicitníNasazena aktualizace softwaru | |||
| Dotčená služba AffectedService | Provozní služba, aplikace nebo konfigurační položka (CI), které incident ovlivnil. | ||
| Popis Dotčená služba propojuje incident s konkrétní součástí IT infrastruktury, například provozní aplikací, serverem nebo síťovým zařízením. Často je navázána na databázi správy konfigurací (CMDB). Tento atribut poskytuje důležitý provozní kontext. V process mining umožňuje analyzovat spolehlivost konkrétních služeb nebo prostředků. Organizace mohou zjistit, které služby vytvářejí nejvíce incidentů, analyzovat postupy jejich řešení a zaměřit správu problémů na zvýšení stability důležitých provozních služeb. Pomáhá tak pochopit širší dopad IT incidentů na provoz. Proč je to důležité Propojuje incidenty s konkrétními provozními službami nebo součástmi IT a umožňuje zjistit, které služby mají nejčastěji problémy a jaký je jejich dopad. Kde data získat Obvykle se načítá z databáze správy konfigurací (CMDB) nebo vybírá ze seznamu katalogu služeb ve formuláři incidentu. Příklady E-mailové službyFinanční systém SAP ERPFiremní VPNSRV-SQL-01 | |||
| Počet přeřazení ReassignmentCount | Celkový počet případů, kdy byl incident přeřazen jinému agentovi nebo skupině. | ||
| Popis Počet přeřazení udává, kolikrát byl incident během svého životního cyklu předán dál. Vysoký počet často ukazuje na neefektivitu, nesprávné počáteční směrování nebo nedostatečné znalosti týmů podpory. Tento atribut je užitečný pro analýzu v process mining. Process mining sice dokáže přeřazování zobrazit, ale předem vypočítaný počet usnadňuje filtrování a měření KPI. Používá se přímo v dashboardu Analýza předávání a přeřazování a pomáhá odhalit situace, kdy si týmy předávají tickety tam a zpět. To prodlužuje dobu řešení a zhoršuje zkušenost uživatelů. Proč je to důležité Tento ukazatel přímo vyčísluje neefektivitu procesu. Vysoký počet přeřazení často souvisí s delší dobou řešení a poukazuje na problémy se směrováním nebo schopnostmi týmů. Kde data získat Často je dostupný jako standardní čítač v záznamu incidentu. Pokud chybí, lze ho vypočítat spočítáním změn přiřazení v auditním protokolu incidentu. Příklady 0135 | |||
| Stav SLA SlaStatus | Udává, zda incident plní cíle smlouvy o úrovni služeb (SLA), je ohrožen jejich nesplněním, nebo je již překročil. | ||
| Popis Stav SLA zachycuje, jak si incident vede vůči předem stanoveným časovým cílům, například době do první reakce nebo vyřešení. Mezi běžné stavy patří „Probíhá“, „Hrozí nesplnění“ a „Překročeno“. Tento atribut přímo měří kvalitu služeb a slouží jako důležitý vstup pro dashboard přehledu plnění SLA. V process mining umožňuje porovnat průběh incidentů, u kterých došlo k překročení SLA, s těmi, u kterých k němu nedošlo. Díky tomu lze určit konkrétní činnosti, prodlevy nebo opakované kroky, které nejčastěji vedou k nesplnění SLA, a zaměřit zlepšování procesů na jejich příčiny. Proč je to důležité Přímo měří plnění stanovených cílů. Analýza incidentů s překročeným SLA pomáhá odhalit nedostatky v procesu, které vedou k horší kvalitě služeb. Kde data získat Obvykle jde o vypočítávané pole v nástroji ITSM, které se průběžně aktualizuje podle priority a stáří incidentu a nastavených pravidel SLA. Příklady ProbíháPozastavenoPřekročenoHrozí nesplnění | |||
| Žadatel Requester | Uživatel, zaměstnanec nebo systém, který incident původně nahlásil. | ||
| Popis Žadatel je osoba, která má problém a nahlásila incident. Může jít o interního zaměstnance nebo externího zákazníka. Atribut může obsahovat také oddělení nebo organizaci žadatele. Analýza incidentů podle žadatele nebo jeho oddělení pomáhá zjistit, zda některé skupiny uživatelů řeší více problémů než jiné. Může upozornit na potřebu školení nebo na místní problémy s prostředím. V process mining umožňuje sledovat proces podpory z pohledu uživatelů a porovnávat jejich zkušenosti. Proč je to důležité Umožňuje analyzovat proces z pohledu uživatelů a zjistit, zda někteří uživatelé, oddělení nebo lokality nevytvářejí nepřiměřeně velký počet incidentů. Kde data získat Standardní pole v záznamu incidentu. Obvykle obsahuje uživatele, který ticket vytvořil, nebo osobu, jejímž jménem byl vytvořen. Příklady Alena NovotnáObchodní odděleníb.williamsCustomer-XYZ Corp | |||
Činnosti při správě incidentů
| Aktivita | Popis | ||
|---|---|---|---|
| Incident uzavřen | Poslední aktivita v životním cyklu incidentu. Záznam se formálně uzavře a zůstane pouze pro čtení jako historický záznam. Často k tomu dojde automaticky po uplynutí stanovené doby ve stavu „Vyřešeno“. | ||
| Proč je to důležité Tímto končí životní cyklus incidentu. Celková doba od vytvoření do uzavření ukazuje délku celého procesu včetně administrativních úkonů po vyřešení. Kde data získat Událost se zaznamená při výslovné změně stavu na „Uzavřeno“ v historii incidentu, kde je uvedeno konečné časové razítko. Zachycení Použijte časové razítko z auditního protokolu, kdy se stav incidentu změnil na „Uzavřeno“. Typ události explicit | |||
| Incident vyřešen | Tato aktivita znamená, že bylo zavedeno řešení a služba by měla být pro uživatele opět dostupná. Jde o důležitý milník, kterým se obvykle zastaví měření času na vyřešení podle SLA. | ||
| Proč je to důležité Tento bod slouží jako hlavní konec pro měření doby vyřešení. Čas mezi vyřešením a konečným uzavřením je důležitý při analýze prodlev, než uživatel řešení potvrdí, nebo pravidel pro automatické uzavření. Kde data získat Tato událost se téměř vždy zaznamená, když agent změní stav incidentu na „Vyřešeno“ nebo „Opraveno“. Zachycení Použijte časové razítko z auditního protokolu, kdy se stav incidentu změnil na „Vyřešeno“. Typ události explicit | |||
| Incident vytvořen | Tato činnost označuje formální vytvoření záznamu incidentu v systému. Je začátkem životního cyklu incidentu a zachycuje první hlášení od uživatele nebo monitorovacího nástroje. | ||
| Proč je to důležité Jde o hlavní počáteční událost procesu. Analýza doby od vytvoření incidentu k dalším milníkům je základem pro měření celkové doby řešení a odhalení zpoždění na začátku procesu. Kde data získat Tato událost se obvykle určuje podle časového razítka vytvoření záznamu v hlavní tabulce incidentů nebo tiketů zdrojového systému. Zachycení Použijte časové razítko „create_date“ nebo „submitted_on“ z hlavního záznamu incidentu. Typ události explicit | |||
| Incident znovu otevřen | K této události dochází, když se dříve vyřešený incident vrátí do aktivního stavu. Obvykle se tak stane, když uživatel oznámí, že se problém opakoval nebo navržené řešení nefungovalo. | ||
| Proč je to důležité Vysoký podíl znovu otevřených incidentů může ukazovat na nízkou kvalitu řešení, neúplnou analýzu hlavní příčiny nebo předčasné uzavírání. Jde o důležitý ukazatel při analýze opakované práce. Kde data získat Událost lze odvodit z historie stavů, když se stav incidentu změní z „Vyřešeno“ nebo „Uzavřeno“ zpět na aktivní stav, například „Probíhá“. Zachycení Zjistěte změnu stavu z vyřešeného na otevřený a zaznamenejte její časové razítko. Typ události inferred | |||
| Přiřazena skupina | Označuje první přiřazení incidentu konkrétní skupině podpory nebo týmu k prošetření. Jde o první oficiální předání a začátek workflow řešení. | ||
| Proč je to důležité Jde o důležitý krok při směrování incidentu. Zpožděné nebo nesprávné přiřazení může výrazně prodloužit dobu řešení a vést ke zbytečnému předávání mezi týmy. Kde data získat Tato událost se odvozuje z auditního záznamu. Hledá se první případ, kdy je vyplněno pole „Assignment Group“ nebo „Support Team“. Zachycení V historii incidentu zjistěte časové razítko prvního vyplnění pole „Assignment Group“. Typ události inferred | |||
| Zahájeno prošetřování | Označuje, že přiřazený pracovník začal na incidentu aktivně pracovat. Obvykle se projeví změnou stavu z „Assigned“ nebo „New“ na „In Progress“. | ||
| Proč je to důležité Tento milník označuje konec počátečního čekání ve frontě a začátek aktivní práce. Měření doby do této činnosti pomáhá posoudit kapacitu pracovníků a zpoždění při reakci. Kde data získat Tato událost se obvykle odvozuje ze změny stavu v historii incidentu. Zachycení Zjistěte časové razítko první změny stavu incidentu na „In Progress“, „Work in Progress“ nebo jiný obdobný aktivní stav. Typ události inferred | |||
| Zjištěno porušení SLA | Vypočítaná událost, ke které dojde, když doba reakce na incident nebo jeho řešení překročí cíle stanovené v dohodnuté úrovni služeb (SLA). Nejde o ruční činnost uživatele, ale o výsledek uplynutí času. | ||
| Proč je to důležité Nedodržení SLA je jedním z hlavních ukazatelů výkonnosti (KPI). Analýza toho, kdy a proč k němu dochází, pomáhá zlepšovat poskytování služeb a plnit smluvní závazky. Kde data získat Tato událost není přímo zaznamenána v záznamech událostí. Vypočítá se porovnáním časových razítek událostí s cílovými termíny SLA uloženými v záznamu incidentu. Zachycení Porovnejte časové razítko vyřešení s položkou „Termín SLA“. Pokud k vyřešení došlo později, zaznamenejte porušení SLA s časovým razítkem termínu SLA. Typ události calculated | |||
| Incident přeřazen | Označuje předání incidentu jiné skupině podpory nebo jinému pracovníkovi. K tomuto předání často dochází, když původní tým nedokáže problém vyřešit a je potřeba jiná odbornost. | ||
| Proč je to důležité Časté přeřazování výrazně ukazuje na neefektivní proces, nesprávné počáteční směrování nebo nedostatečné znalosti týmu. Analýza těchto předání je důležitá pro zjednodušení průběhu řešení. Kde data získat Událost se odvozuje z auditního záznamu, kde se hledají změny pole „Assignment Group“ nebo „Assignee“ po prvním přiřazení. Zachycení Při každé změně pole „Assignment Group“ po jeho prvním vyplnění zaznamenejte novou událost. Typ události inferred | |||
| Incident zařazen do kategorie | Označuje klasifikaci incidentu, včetně nastavení jeho kategorie, typu a položky. Jde o důležitý krok prvotního posouzení, který pomáhá incident správně směrovat a zvolit vhodný postup řešení. | ||
| Proč je to důležité Nesprávná kategorizace může vést ke zpožděním, přeřazování a zkresleným reportům. Analýza této činnosti pomáhá posoudit kvalitu počátečního třídění a jeho vliv na efektivitu řešení. Kde data získat Tato událost se obvykle odvozuje z auditního záznamu nebo tabulky historie. Určí se první okamžik, kdy jsou vyplněna pole související s kategorizací. Zachycení Po vytvoření incidentu zjistěte první změnu polí, jako jsou „Category“, „Subcategory“ nebo „Configuration Item“. Typ události inferred | |||
| Incidentu nastavena priorita | Tato činnost nastává při nastavení priority incidentu, obvykle podle jeho dopadu a naléhavosti. Úroveň priority určuje cílovou dobu reakce a řešení podle dohodnutých úrovní služeb (SLA). | ||
| Proč je to důležité Priorita přímo ovlivňuje přidělování zdrojů i pořadí řešení incidentů. Analýza tohoto kroku pomáhá zajistit, aby se kritickým incidentům věnovala pozornost přednostně a aby byly dodrženy SLA. Kde data získat Tato událost se zachytí sledováním změn pole „Priority“ nebo „Severity“ v auditní stopě. Zachycení Použijte časové razítko z auditního záznamu, které odpovídá změně pole „Priority“. Typ události explicit | |||
| Poskytnuto náhradní řešení | Označuje, že uživatel dostal informaci o dočasném řešení, které obnoví funkčnost služby. Zmírní se tak dopad na provoz firmy, zatímco se připravuje trvalá oprava. | ||
| Proč je to důležité Poskytnutí náhradního řešení je důležitým krokem při správě závažných incidentů. Umožňuje samostatně sledovat dobu do zmírnění dopadu a dobu do trvalého vyřešení. Kde data získat Může jít o výslovný stav nebo příznak. Často se však událost odvozuje z poznámek pracovníků nebo záznamů komunikace pomocí vyhledávání klíčových slov. Zachycení Událost určete podle konkrétního stavu, například „Workaround Provided“, nebo vyhledáním výrazů jako „workaround“ či „temporary fix“ v komentářích pracovníků. Typ události inferred | |||
| Práce obnovena | Označuje okamžik, kdy se incident pozastavený ve stavu čekání znovu aktivuje. Obvykle k tomu dojde po obdržení potřebných informací, takže pracovník podpory může pokračovat v řešení. | ||
| Proč je to důležité Tato činnost je důležitá pro přesné měření doby čekání na externí vstupy. Doba mezi stavy „Pending“ a „Resumed“ ukazuje, jak dlouho byl proces pozastaven kvůli vnějším okolnostem. Kde data získat Událost se odvozuje z historie stavů incidentu při přechodu ze stavu „Pending“ zpět do stavu „In Progress“ nebo jiného aktivního stavu. Zachycení Zaznamenejte časové razítko změny stavu incidentu z čekajícího zpět na aktivní. Typ události inferred | |||
| Přiřazen pracovník | Tato činnost označuje okamžik, kdy konkrétní pracovník převezme nebo dostane na starost incident. Odpovědnost se tím přesouvá z úrovně týmu na konkrétní osobu. | ||
| Proč je to důležité Sledování přiřazení pracovníků pomáhá analyzovat jejich vytížení a výkonnost a odhalit úzká místa, kde incidenty čekají na dostupného pracovníka. Kde data získat Událost se zachytí sledováním změn pole „Assignee“ nebo „Assigned To“ v auditním záznamu incidentu. Zachycení Použijte časové razítko z auditního záznamu, kdy bylo pole „Assignee“ poprvé vyplněno nebo změněno na jiného uživatele. Typ události explicit | |||
| Změna stavu na čekající | Nastává, když se řešení incidentu pozastaví, obvykle kvůli čekání na informace od uživatele, dodavatele nebo jinou externí závislost. V tomto stavu se obvykle zastaví měření SLA. | ||
| Proč je to důležité Analýza doby strávené v čekajícím stavu odhalí externí závislosti a zpoždění. Dlouhé čekání může zakrýt neefektivitu uvnitř organizace a zkreslit ukazatele doby řešení. Kde data získat Událost se odvozuje z historie stavů incidentu při změně na „Pending“, „On Hold“ nebo „Awaiting User“. Zachycení Zaznamenejte časové razítko pokaždé, když se stav incidentu změní na některý z určených čekajících stavů. Typ události inferred | |||
Návody na extrakci dat
Metody extrakce se liší podle systému. Podrobný postup najdete v
Chcete začít?
Začněte zlepšovat proces správy incidentů ještě dnes. Vyberte si níže návod na extrakci dat pro konkrétní systém, nebo použijte tuto obecnou šablonu a vytvořte záznam událostí pro analýzu procesu.
Vyřešte incidenty rychleji. Začněte se změnami ještě dnes.
Najděte úzká místa, omezte výpadky a zvyšte efektivitu týmu.
Bez platební karty, nastavení za 5 minut