Šablona dat pro řízení změn
Šablona dat pro řízení změn
- 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
Atributy řízení změn
| 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
|
|||
Aktivity v řízení změn
| 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
|
|||
Návody k extrakci dat
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.
Bez platební karty, nastavení zabere jen několik minut.