Šablona dat pro řízení změn

ServiceNow
Šablona dat pro řízení změn

Šablona dat pro řízení změn

Tato šablona nabízí strukturovaný postup pro shromáždění dat potřebných k process mining analýze workflow řízení změn. Uvádí doporučené atributy a aktivity, které je vhodné sledovat, a praktické pokyny k extrakci dat. Připravte si s její pomocí data pro podrobnou analýzu a zlepšování procesů.
  • Doporučené atributy ke shromáždění
  • Aktivity, které je třeba sledovat pro přesné zjištění průběhu procesu
  • Pokyny k extrakci dat ze ServiceNow
Pracujete se záznamy událostí poprvé? Přečtěte si, jak vytvořit záznam událostí pro process mining.

Atributy řízení změn

Toto jsou doporučená datová pole, která je vhodné zahrnout do záznamu událostí pro podrobnou analýzu procesu řízení změn.
3 Povinné 7 Doporučené 9 Volitelné
Název Popis
Čas události
EventTime
Přesné časové razítko okamžiku, kdy došlo ke konkrétní aktivitě nebo události.
Popis

Čas události zaznamenává přesné datum a čas provedení aktivity nebo změny stavu. Toto časové razítko je nezbytné pro chronologické seřazení událostí i pro veškerou analýzu délky trvání.

V process mining tento atribut umožňuje vypočítat dobu průchodu, dobu zpracování a čekání mezi aktivitami. Je nezbytný pro dashboardy zaměřené na výkonnost, například pro analýzu doby schválení změny a celkového průběhu procesu změny. Přesná časová razítka jsou základem pro odhalování zdržení a měření efektivity procesu vůči SLA.

Proč je to důležité

Toto časové razítko je nezbytné pro správné seřazení událostí a výpočet všech časových metrik, včetně doby průchodu, délky trvání a dodržení SLA.

Kde data získat

Tabulka ServiceNow: sys_audit, pole: sys_created_on. Obsahuje časové razítko každé zaznamenané změny.

Příklady
2023-10-26T10:00:00Z2023-10-26T11:30:15Z2023-10-27T14:05:00Z
ID požadavku na změnu
ChangeRequestNumber
Jedinečný identifikátor požadavku na změnu, který slouží jako hlavní ID případu pro seskupení všech souvisejících událostí.
Popis

ID požadavku na změnu je základem analýzy procesu řízení změn. Každý požadavek dostane jedinečné číslo, například „CHG0030001“, které propojuje všechny související aktivity, schválení a úkoly.

V process mining se tento atribut používá k rekonstrukci celého průběhu každé jednotlivé změny. Analytici mohou sledovat její životní cyklus od vytvoření až po uzavření a získat ucelený přehled o tom, jak změna prochází systémem. Seskupení procesů podle tohoto ID je nezbytné pro výpočet doby průchodu, odhalení opakovaných cyklů přepracování a pochopení variant procesu.

Proč je to důležité

Toto ID je nezbytné pro sledování celého životního cyklu změny a umožňuje u každého požadavku analyzovat tok procesu, jeho délku i dodržení pravidel.

Kde data získat

Tabulka ServiceNow: change_request, pole: number

Příklady
CHG0030001CHG0030045CHG0030112
Název aktivity
ActivityName
Název konkrétní události nebo úkolu, který proběhl v procesu řízení změn.
Popis

Název aktivity popisuje jednotlivý krok nebo změnu stavu v životním cyklu požadavku na změnu. Příklady: „Změna čeká na posouzení“, „Vyžádáno schválení“ a „Změna realizována“. Tyto aktivity tvoří uzly objevené procesní mapy.

Analýza aktivit umožňuje podrobně prozkoumat tok procesu. Sledováním jejich pořadí a četnosti mohou organizace odhalit obvyklé cesty, odchylky od standardního postupu i úzká místa, kde se změny často zastaví. To je základem vizualizace procesu a výpočtu metrik, jako je doba přechodu mezi jednotlivými kroky.

Proč je to důležité

Tvoří základ procesní mapy. Umožňuje zobrazit tok procesu, odhalit úzká místa a analyzovat odchylky.

Kde data získat

Odvozuje se od změn pole „state“ nebo jiných důležitých polí se stavem v tabulce „change_request“. Tyto změny se často zaznamenávají v tabulce „sys_audit“.

Příklady
Změna schválenaZahájena realizaceZměna uzavřenaZměna zrušena
Čas ukončení
EndTime
Časové razítko okamžiku, kdy aktivita skončila. Často se odvozuje od času zahájení následující aktivity.
Popis

Čas ukončení označuje dokončení aktivity. Zdrojové systémy často zaznamenávají začátek události, takže čas ukončení se obvykle odvozuje. Nejčastěji se vypočítá jako časové razítko následující aktivity ve stejném případu.

Tento atribut je nezbytný pro výpočet délky jednotlivých aktivit, tedy doby zpracování. Znalost délky každého kroku pomáhá odhalovat úzká místa a neefektivní postupy. U poslední aktivity případu se čas ukončení rovná času zahájení.

Proč je to důležité

Umožňuje vypočítat dobu zpracování aktivity, což je důležité pro odhalování úzkých míst a měření délky jednotlivých kroků procesu.

Kde data získat

Tento atribut se obvykle vypočítá při transformaci dat. Použije se StartTime následující události se stejným CaseId.

Příklady
2023-10-26T10:05:12Z2023-10-26T11:45:00Z2023-10-27T15:00:00Z
Konfigurační položka
ConfigurationItem
Konkrétní IT komponenta, služba nebo systém, kterého se změna týká.
Popis

Konfigurační položka (CI) je aktivum z databáze správy konfigurací (CMDB), kterého se změna dotkne. Může jít o server, softwarovou aplikaci, síťové zařízení nebo podnikovou službu.

Tento atribut poskytuje důležitý kontext. V process mining umožňuje rozdělit analýzu podle typu měněného aktiva. Dashboard „Change Testing Duration Analysis“ například využívá tento atribut k porovnání délky testování různých aplikací a systémů a pomáhá zjistit, které CI souvisejí s delšími testovacími cykly.

Proč je to důležité

Poskytuje důležitý kontext pro analýzu. Umožňuje filtrovat data podle dotčené aplikace, služby nebo systému a odhalit problémy konkrétních komponent.

Kde data získat

Tabulka ServiceNow: change_request, pole: cmdb_ci

Příklady
SAP ERPOracle Database 19cE-mailová službaWebServer-01
Priorita
Priority
Úroveň priority požadavku na změnu určená podle jeho dopadu a naléhavosti.
Popis

Priorita vyjadřuje důležitost požadavku na změnu a určuje pořadí, v jakém se má řešit. Často se odvozuje od dopadu a naléhavosti změny. Hodnoty mohou být například „Critical“, „High“, „Moderate“ a „Low“.

Analýza podle priority pomáhá zajistit, aby se změny s vysokou prioritou zpracovávaly rychleji než změny s nízkou prioritou. Podporuje dashboard „Critical Change Performance“, který analytikům umožňuje sledovat dobu průchodu a míru selhání nejdůležitějších změn. Pokud se změny s nízkou prioritou dokončují rychleji než změny s vysokou prioritou, může to ukazovat na problém s přidělováním zdrojů nebo prováděním procesu.

Proč je to důležité

Pomáhá ověřit, zda jsou zdroje správně přiděleny na nejdůležitější změny, a umožňuje samostatně sledovat jejich výkonnost.

Kde data získat

Tabulka ServiceNow: change_request, pole: priority

Příklady
1 - Kritická2 - Vysoká3 - Střední4 - Nízká
Skupina přiřazení
AssignmentGroup
Tým nebo skupina odpovědná za požadavek na změnu.
Popis

Skupina přiřazení označuje tým, který právě odpovídá za požadavek na změnu, například „CAB Approval“, „Network Engineering“ nebo „Database Administrators“. Jde o důležitý rozměr analýzy výkonnosti napříč různými oblastmi provozu.

Tento atribut slouží k měření efektivity týmů, odhalování úzkých míst v konkrétních skupinách a analýze předávání práce mezi týmy. Dashboardy jako „Cross-Functional Handoff Efficiency“ a „Change Implementation Throughput“ tato data využívají k určení zdržení způsobených závislostmi mezi týmy.

Proč je to důležité

Umožňuje analyzovat výkonnost týmů, odhalovat úzká místa v jednotlivých skupinách a měřit efektivitu předávání práce mezi různými oblastmi provozu.

Kde data získat

Tabulka ServiceNow: change_request, pole: assignment_group

Příklady
Schválení CABSíťový týmPodpora serverůSprávci databází
Stav změny
ChangeState
Aktuální nebo historický stav požadavku na změnu, například „Assess“, „Authorize“, „Implement“ nebo „Closed“.
Popis

Atribut Stav změny označuje stav požadavku na změnu v určitém okamžiku. Poskytuje obecný přehled o tom, v jaké fázi životního cyklu se změna nachází. Na rozdíl od aktivity, která označuje konkrétní událost, stav vyjadřuje situaci po této události.

Při analýze se stav změny používá ke kategorizaci případů a pochopení jejich výsledků. Pomáhá filtrovat změny, například analyzovat pouze změny ve stavu „Closed“ nebo zjistit, proč jich mnoho uvízlo ve stavu „Authorize“. Pokud existuje stav „Failed“, přímo podporuje KPI, jako je Change Failure Rate.

Proč je to důležité

Poskytuje přehled o stavu požadavku na změnu a umožňuje analyzovat výsledky, filtrovat případy a odhalovat změny, které se zastavily.

Kde data získat

Tabulka ServiceNow: change_request, pole: state

Příklady
PosouzeníAutorizaceNaplánovánoRealizaceKontrolaUzavřenoZrušeno
Typ změny
ChangeType
Klasifikace změny, například „Standard“, „Normal“ nebo „Emergency“.
Popis

Typ změny kategorizuje požadavek podle jeho povahy, rizika a požadavků na schválení. Standardní změny jsou předem schválené, běžné změny procházejí celým procesem a nouzové změny se vyřizují zrychleným postupem.

Jde o základní rozměr analýzy procesu, protože pro různé typy změn platí odlišné a oprávněné modely procesu. Porovnání běžných a nouzových změn může odhalit důležité informace o dodržování postupu a efektivitě. Tento atribut se používá také v dashboardech, jako je „Risk Assessment Standardization“, které ověřují, zda se s podobnými změnami zachází jednotně.

Proč je to důležité

Umožňuje rozdělit analýzu podle typu změny. Různé typy se řídí odlišnými schválenými postupy a mají jiné očekávané výsledky.

Kde data získat

Tabulka ServiceNow: change_request, pole: type

Příklady
StandardníBěžnáNouzová
Úroveň rizika
RiskLevel
Vyhodnocená úroveň rizika změny, například „High“, „Moderate“ nebo „Low“.
Popis

Úroveň rizika je výsledkem posouzení rizik požadavku na změnu. Vyjadřuje možné nepříznivé důsledky realizace změny a pomáhá určit potřebnou míru kontroly a schvalování.

Tento atribut je důležitý pro dashboard „Risk Assessment Standardization“, který ověřuje, zda podobné změny dostávají stejné hodnocení rizika. Analýza toků procesu podle úrovně rizika také ukáže, zda změny s vysokým rizikem procházejí důkladnějším schvalováním a testováním než změny s nízkým rizikem. Jde o důležitou kontrolu dodržování pravidel.

Proč je to důležité

Nezbytný pro analýzu dodržování pravidel a ověření, že se změnám s vysokým rizikem věnuje odpovídající pozornost a procházejí důkladnějším postupem.

Kde data získat

Tabulka ServiceNow: change_request, pole: risk

Příklady
VysokáStředníNízká
Doba průchodu
CycleTime
Celková doba od vytvoření požadavku na změnu do jeho uzavření.
Popis

Doba průchodu je metrika na úrovni případu, která měří celkovou délku životního cyklu požadavku na změnu. Vypočítá se jako rozdíl mezi časovým razítkem první a poslední události daného požadavku.

Jde o důležitý KPI pro měření celkové rychlosti procesu. Dashboard „Průběh procesu změny od začátku do konce“ poskytuje pomocí této metriky souhrnný pohled na výkonnost procesu. Sledování trendů doby průchodu a jejich porovnání podle typu změny nebo priority pomáhá najít možnosti, jak proces cíleně zlepšit.

Proč je to důležité

Měří celkovou dobu průchodu procesem změny a slouží jako ukazatel jeho rychlosti a efektivity.

Kde data získat

Vypočítá se při analýze dat na úrovni případu: od maximální hodnoty StartTime se odečte minimální hodnota StartTime pro každé CaseId.

Příklady
60480012096002592000
Dopad
Impact
Možný vliv změny na provoz organizace, hodnocený například jako vysoký, střední nebo nízký.
Popis

Dopad vyjadřuje možné důsledky pro organizaci, pokud nebude požadavek na změnu správně vyřízen. Spolu s naléhavostí slouží jako podklad pro určení celkové priority změny.

Analýza podle dopadu pomáhá zajistit, aby se změny ovlivňující důležité služby řídily s odpovídající péčí. Dashboard „Critical Change Performance“ tento atribut využívá k oddělenému sledování změn s velkým dopadem na provoz organizace. Slouží také k ověření jednotnosti posuzování rizik a pomáhá zajistit, aby změny s velkým dopadem nebyly bez odůvodnění označeny jako nízkorizikové.

Proč je to důležité

Pomáhá určovat prioritu změn podle jejich možného dopadu na organizaci a ověřovat, zda se změnám s velkým dopadem věnuje náležitá pozornost.

Kde data získat

Tabulka ServiceNow: change_request, pole: impact

Příklady
1 - Vysoký2 - Střední3 - Nízký
Je opakovaná práce
IsRework
Logická hodnota, která je nastavena na true, pokud aktivita představuje opakování předchozího kroku v rámci stejného případu.
Popis

Tento vypočítaný atribut označuje aktivity, při kterých se práce opakuje. K opakování dochází, když se proces vrátí k již dokončenému kroku, například když je změna po schválení zamítnuta a vrácena k novému posouzení.

Tento příznak umožňuje vyčíslit neefektivitu procesu. Přímo se používá v KPI „Míra opakované práce při změnách“ a v dashboardu „Analýza neúspěšných změn a opakované práce“. Vyfiltrujte aktivity, u kterých má položka „Je opakovaná práce“ hodnotu true, a zjistěte příčiny opakování, například neúplné počáteční posouzení nebo změny požadavků. Poté můžete přijmout opatření ke snížení plýtvání.

Proč je to důležité

Vyčísluje neefektivitu procesu tím, že označuje opakovanou práci. Pomáhá tak odhalit a řešit příčiny opakovaných smyček a zbytečného úsilí.

Kde data získat

Vypočítá se při transformaci dat. Zjišťuje se, zda se stejná aktivita nebo některá předchozí aktivita ve standardním toku již vyskytla pro dané CaseId.

Příklady
truefalse
Kód uzavření
CloseCode
Kód označující výsledek uzavřeného požadavku na změnu, například „Úspěšná“ nebo „Neúspěšná“.
Popis

Kód uzavření zaznamenává konečný výsledek dokončeného požadavku na změnu. Uvádí, zda byla změna úspěšně provedena, zda se při ní vyskytly problémy, nebo zda byla vrácena zpět.

Tento atribut přímo vstupuje do KPI „Míra neúspěšných změn“. Rozdělení kódů uzavření ukazuje, jak úspěšné jsou změnové iniciativy. Pokud v mapě procesů vyfiltrujete změny s kódem uzavření „Neúspěšná“, můžete hledat společné vzorce, které vedou k neúspěchu.

Proč je to důležité

Přímo měří výsledek změny a poskytuje hlavní údaje pro výpočet míry neúspěšných změn i analýzu jejich příčin.

Kde data získat

Tabulka ServiceNow: change_request, pole: close_code

Příklady
ÚspěšnáÚspěšná s problémyNeúspěšná / vrácená zpět
Naléhavost
Urgency
Rychlost, s jakou je třeba změnu vyřešit, vyjádřená například jako vysoká, střední nebo nízká.
Popis

Naléhavost určuje, jak rychle je třeba změnu provést. Vyjadřuje časovou citlivost požadavku z pohledu provozu. Spolu s dopadem se používá k výpočtu celkové priority.

Pro analýzu je hlavním údajem priorita, naléhavost však poskytuje další kontext. Pomáhá zjistit, proč jsou některé změny označené jako naléhavé a zda je proces dokáže účinně zpracovat, aniž by byla ohrožena stabilita. Ukazuje také, zda organizace příliš často řeší požadavky v reaktivním režimu s vysokou naléhavostí.

Proč je to důležité

Poskytuje kontext o časové citlivosti změny a pomáhá posoudit, zda proces účinně zvládá časově kritické požadavky.

Kde data získat

Tabulka ServiceNow: change_request, pole: urgency

Příklady
1 - Vysoký2 - Střední3 - Nízký
Poslední aktualizace dat
LastDataUpdate
Časové razítko označující, kdy byla data tohoto záznamu naposledy aktualizována ze zdrojového systému.
Popis

Tento atribut obsahuje časové razítko poslední extrakce dat. Jde o metadata důležitá pro posouzení aktuálnosti analyzovaných dat.

Analytici podle tohoto časového razítka ověří, že pracují s aktuálními informacemi, a zjistí, jak jsou data stará. Je zvlášť důležité pro provozní dashboardy, které sledují průběžnou výkonnost procesu. Pomáhá zajistit, aby se rozhodnutí neopírala o zastaralá data.

Proč je to důležité

Ukazuje aktuálnost dat a pomáhá zajistit, aby analýzy i dashboardy vycházely z platných a relevantních informací.

Kde data získat

Toto pole metadat vzniká při extrakci a transformaci dat (ETL) a označuje čas jejich načtení.

Příklady
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
Přiřazený uživatel
AssignedToUser
Uživatel odpovědný za požadavek na změnu v určitém okamžiku.
Popis

Tento atribut určuje konkrétní osobu přiřazenou k práci na požadavku na změnu. Během životního cyklu se může několikrát změnit, když požadavek přechází mezi různými fázemi a týmy.

Analýza podle uživatele pomáhá pochopit rozložení pracovní zátěže a výkon jednotlivců i určit potřeby školení. Je důležitá také pro analýzu předávání práce. V kombinaci se skupinou přiřazení ukáže, jak efektivně se práce předává mezi jednotlivými uživateli.

Proč je to důležité

Pomáhá sledovat pracovní zátěž a výkon jednotlivých uživatelů a analyzovat zdržení při předávání práce mezi různými zdroji.

Kde data získat

Tabulka ServiceNow: change_request, pole: assigned_to

Příklady
Beth AnglinDavid LooAbel Tuter
Stav SLA
SlaState
Stav požadavku na změnu vzhledem k jeho dohodě o úrovni služeb (SLA), například „V termínu“, „Ohroženo“ nebo „Po termínu“.
Popis

Stav SLA ukazuje, zda požadavek na změnu postupuje v časových limitech stanovených dohodou SLA. Tento stav lze sledovat v každé fázi procesu.

Atribut je důležitý pro sledování plnění závazků týkajících se úrovně služeb. Je hlavním zdrojem dat pro dashboard „Přehled plnění SLA u změn“ a KPI „Míra dodržení SLA u změn“. Analýza míst a příčin nedodržení SLA pomáhá řešit systémová zpoždění a lépe předvídat poskytování služeb.

Proč je to důležité

Přímo měří plnění termínů. Umožňuje průběžně sledovat a analyzovat nedodržení SLA a zlepšovat poskytování služeb.

Kde data získat

Údaje lze získat z tabulky ServiceNow task_sla, která sleduje SLA související s úkoly, jako jsou požadavky na změnu. Stav lze také vypočítat z polí s termínem splnění.

Příklady
V termínuOhroženoPo termínu
Zdrojový systém
SourceSystem
Systém, ze kterého byla data získána, obvykle ServiceNow.
Popis

Tento atribut určuje původ procesních dat. V tomto případě se očekává hodnota ServiceNow. Jde však o důležité pole pro správu dat i pro situace, kdy se spojují data z více systémů.

Při analýze pomáhá ověřit původ dat a zajistit jeho dohledatelnost. Organizacím, které používají více nástrojů ITSM nebo propojených systémů, umožňuje filtrovat a porovnávat procesy napříč platformami.

Proč je to důležité

Zajišťuje dohledatelnost původu procesních dat, což je důležité pro správu dat i analýzu napříč více systémy.

Kde data získat

Obvykle jde o neměnnou hodnotu přidanou při extrakci a transformaci dat (ETL).

Příklady
ServiceNowServiceNow_PRODSNOW_ITSM
Povinné Doporučené Volitelné

Aktivity v řízení změn

Toto jsou důležité kroky a milníky procesu, které je vhodné zaznamenat do záznamu událostí pro přesné zjištění průběhu řízení změn.
7 Doporučené 6 Volitelné
Aktivita Popis
Požadavek na změnu vytvořen
Tato aktivita označuje vytvoření nového záznamu požadavku na změnu v systému. Jde o oficiální začátek procesu řízení změn. Zachytí se při vložení nového záznamu do tabulky change_request.
Proč je to důležité

Jde o hlavní počáteční událost procesu. Analýza času od této aktivity k dalším aktivitám ukáže celkovou dobu průchodu procesem a pomůže odhalit zdržení hned na jeho začátku.

Kde data získat

Tato událost odpovídá časovému razítku vytvoření záznamu (sys_created_on) v tabulce change_request systému ServiceNow.

Zachycení

Použijte časové razítko sys_created_on z tabulky change_request.

Typ události explicit
Rizika a dopady posouzeny
Označuje dokončení analýzy rizik a dopadů požadavku na změnu. Jde o důležitý milník před žádostí o schválení. Obvykle se odvozuje od přechodu změny ze stavu „Assess“ do stavu „Authorize“ nebo „Awaiting Approval“.
Proč je to důležité

Sledování délky fáze posouzení je důležité pro KPI „Avg. Risk Assessment Cycle Time“. Pomáhá sjednotit postup posuzování a odhalit, kde analýzy trvají příliš dlouho.

Kde data získat

Aktivita se odvozuje od změny pole „state“ v tabulce change_request z hodnoty „Assess“ na „Authorize“. Čas události se přebírá z auditního záznamu této změny stavu.

Zachycení

Zjistěte, kdy se pole „state“ změní z hodnoty „Assess“ na některý z následujících stavů, například „Authorize“.

Typ události inferred
Změna naplánována
Schválené změně byl přiřazen plánovaný začátek a konec a je zařazena do kalendáře realizace. Aktivita se odvozuje od změny stavu požadavku na „Scheduled“.
Proč je to důležité

Tato aktivita odděluje fázi plánování a schvalování od samotné realizace. Doba strávená v tomto stavu může ukázat zdržení mezi schválením a zahájením práce.

Kde data získat

Aktivita se odvozuje od změny pole „state“ v tabulce change_request na hodnotu „Scheduled“. Časové razítko se přebírá z odpovídajícího záznamu auditu.

Zachycení

V historii auditu tabulky change_request sledujte změny pole state na hodnotu „Scheduled“.

Typ události inferred
Změna realizována
Realizace změny je dokončena a změna je připravena ke kontrole, ověření nebo testování. Aktivita se odvozuje od přechodu požadavku na změnu ze stavu „Implement“ do stavu „Review“.
Proč je to důležité

Tento důležitý milník uzavírá fázi realizace. Je zásadní pro výpočet KPI „Change Failure Rate“ a „Change Rework Rate“.

Kde data získat

Aktivita se odvozuje od přechodu ze stavu „Implement“ do některého z následujících stavů, například „Review“. Časové razítko se přebírá z historie auditu pole „state“ v tabulce change_request.

Zachycení

Zjistěte, kdy se pole „state“ změní z hodnoty „Implement“ na „Review“.

Typ události inferred
Změna schválena
Požadavek na změnu získal všechna potřebná schválení a může pokračovat k plánování a realizaci. Jde o důležitý milník. Zachytí se po udělení posledního schválení, kdy se pole „approval“ nastaví na hodnotu „approved“.
Proč je to důležité

Tento milník uzavírá fázi schvalování. Je nezbytný pro měření délky schvalovacího cyklu a odhalování úzkých míst v rozhodování.

Kde data získat

Aktivita se odvozuje od změny pole „approval“ v tabulce change_request na hodnotu „approved“. Časové razítko se přebírá z historie auditu této změny.

Zachycení

Zaznamenejte časové razítko okamžiku, kdy pole „approval“ nabude hodnoty „approved“.

Typ události inferred
Změna uzavřena
Požadavek na změnu byl úspěšně dokončen a zkontrolován. Nyní se považuje za uzavřený. Jde o hlavní koncový bod úspěšného procesu. Zachytí se, když se stav změny změní na „Closed“.
Proč je to důležité

Tato aktivita označuje úspěšné dokončení životního cyklu změny. Jde o koncovou událost pro měření celkové doby průchodu procesem a dodržení SLA.

Kde data získat

Aktivita se odvozuje od nastavení pole „state“ v tabulce change_request na hodnotu „Closed“. Časové razítko se přebírá z historie auditu této poslední změny stavu.

Zachycení

Zaznamenejte časové razítko okamžiku, kdy se pole „state“ aktualizuje na hodnotu „Closed“.

Typ události inferred
Změna zrušena
Požadavek na změnu byl před dokončením realizace stažen nebo přerušen. Jde o alternativní koncový stav, který se zachytí, když se stav nastaví na „Canceled“.
Proč je to důležité

Analýza zrušených změn může odhalit neefektivní postupy, například zbytečně vytvořené požadavky nebo požadavky, které příliš dlouho čekaly na schválení a mezitím zastaraly.

Kde data získat

Aktivita se odvozuje od nastavení pole „state“ v tabulce change_request na hodnotu „Canceled“. Časové razítko se přebírá z auditního záznamu této změny stavu.

Zachycení

Zaznamenejte časové razítko okamžiku, kdy se pole „state“ aktualizuje na hodnotu „Canceled“.

Typ události inferred
Probíhá kontrola
Probíhá kontrola po realizaci (PIR), která ověřuje, zda byla změna úspěšná a splnila své cíle. Aktivita se zachytí, když se stav požadavku na změnu nastaví na „Review“.
Proč je to důležité

Analýza délky fáze kontroly pomáhá odhalit zdržení při ověřování úspěšnosti změny. Ukáže také změny, u kterých se tento krok kvůli nedodržení postupu vynechává.

Kde data získat

Aktivita se odvozuje od změny pole „state“ v tabulce change_request na hodnotu „Review“. Časové razítko se přebírá z auditního záznamu této změny stavu.

Zachycení

Z historie auditu change_request zaznamenejte časové razítko změny stavu na „Review“.

Typ události inferred
Vyžádáno schválení
Tato aktivita označuje formální předložení požadavku na změnu ke schválení, obvykle manažerovi nebo výboru Change Advisory Board (CAB). Událost se zachytí, když se stav schválení požadavku nastaví na „requested“.
Proč je to důležité

Tím začíná schvalovací cyklus. Čas od této události do události „Change Approved“ přímo určuje KPI „Average Change Approval Time“.

Kde data získat

Aktivita se odvozuje od změny pole „approval“ v tabulce change_request na hodnotu „requested“. Časové razítko se přebírá z tabulky sys_audit pro toto pole.

Zachycení

Časové razítko okamžiku, kdy se pole „approval“ v tabulce change_request nastaví na hodnotu „requested“.

Typ události inferred
Zahájena realizace
Začala samotná realizace změny. Aktivita se zachytí, když se stav požadavku na změnu aktualizuje na „Implement“, což označuje přechod od plánování k provádění.
Proč je to důležité

Tím začíná vlastní práce na realizaci změny. Jde o výchozí bod pro měření KPI „Average Implementation Duration“ a analýzu efektivity týmu.

Kde data získat

Aktivita se odvozuje od změny pole „state“ v tabulce change_request na hodnotu „Implement“. Časové razítko se přebírá z auditního záznamu tohoto přechodu stavu.

Zachycení

Z historie auditu change_request zaznamenejte časové razítko změny stavu na „Implement“.

Typ události inferred
Změna čeká na posouzení
Požadavek na změnu byl odeslán a nyní čeká na technické a obchodní posouzení. Tato aktivita se obvykle odvozuje od změny stavu požadavku na „Assess“ nebo podobnou hodnotu, která značí, že požadavek opustil fázi návrhu.
Proč je to důležité

Tato aktivita pomáhá měřit dobu prvního předání požadavku od žadatele posuzovacímu týmu. Zdržení může ukazovat na nedostatečnou kvalitu vstupních dat nebo nedostupné zdroje pro posouzení.

Kde data získat

Aktivita se odvozuje od změny pole „state“ v tabulce change_request, obvykle na hodnotu jako „Assess“. Časové razítko se přebírá z historie auditu (sys_audit) této změny pole.

Zachycení

V historii auditu tabulky change_request sledujte změny pole state na hodnotu „Assess“.

Typ události inferred
Změna zamítnuta
Schvalovatel nebo CAB požadavek na změnu zamítl. Tato aktivita představuje konečný stav požadavku, pokud se požadavek neupraví a znovu neodešle. Zachytí se, když se pole „approval“ nastaví na hodnotu „rejected“.
Proč je to důležité

Sledování zamítnutí pomáhá odhalit časté důvody, například neúplné informace nebo vysoké riziko. Tato analýza může zlepšit kvalitu budoucích požadavků na změnu.

Kde data získat

Aktivita se odvozuje od změny pole „approval“ v tabulce change_request na hodnotu „rejected“. Časové razítko se přebírá z historie auditu.

Zachycení

Zaznamenejte časové razítko okamžiku, kdy pole „approval“ nabude hodnoty „rejected“.

Typ události inferred
Změna znovu otevřena
Požadavek na změnu se po dosažení pozdější fáze vrátil do předchozího stavu, například „Implement“ nebo „Assess“. Tato událost se odvozuje z nelineárního přechodu mezi stavy a označuje nutnost přepracování.
Proč je to důležité

Tato aktivita je důležitá pro odhalení opakovaných cyklů přepracování a výpočet KPI „Change Rework Rate“. Časté opětovné otevírání ukazuje na problémy s kvalitou realizace, testováním nebo plánováním.

Kde data získat

Aktivita se odvozuje z analýzy posloupnosti změn stavů v historii auditu change_request. Přechod z pozdějšího stavu, například „Review“, do dřívějšího stavu, například „Implement“, označuje opětovné otevření.

Zachycení

V historii pole „state“ zjistěte, zda došlo k nelineárnímu přechodu zpět.

Typ události inferred
Doporučené Volitelné

Návody k extrakci dat

Jak získat data ze ServiceNow

Chcete začít?

Pomocí této šablony připravte data a získejte přehled o procesu řízení změn v ServiceNow. Začněte zlepšovat jeho efektivitu.

Omezte neúspěšné změny a zlepšete výsledky v ServiceNow!

Snadno najděte úzká místa a dosáhněte 95% úspěšnosti změn.

Spustit zkušební verzi zdarma

Bez platební karty, nastavení zabere jen několik minut.