> Průběžné zlepšování procesů > Správa servisních požadavků > ServiceNow > Datová šablona

Šablona dat pro správu servisních požadavků

ServiceNow

Atributy řízení servisních požadavků(21) Aktivity v řízení servisních požadavků(14) Návody k získání dat(3)

Šablona dat pro správu servisních požadavků

Tato datová šablona vám usnadní začátek s process mining v oblasti správy servisních požadavků. Najdete v ní přehled atributů, které je třeba shromáždit, důležitých činností, které je vhodné sledovat, a praktický návod k extrakci dat ze ServiceNow. Díky šabloně získáte potřebná data pro přesnou analýzu a účinné zlepšování procesů.

Doporučené atributy ke shromáždění
Důležité činnosti pro zjištění průběhu procesu
Postup extrakce dat krok za krokem

Pracujete se záznamy událostí poprvé? Přečtěte si, jak vytvořit záznam událostí pro process mining.

Stáhnout šablonu

Atributy řízení servisních požadavků

Doporučená datová pole, která zahrňte do záznamu událostí, abyste mohli důkladně analyzovat proces řízení servisních požadavků.

5 Povinné 6 Doporučené 10 Volitelné

	Název	Popis
	Aktivita ActivityName	Název konkrétní události nebo úkolu, ke kterému došlo během životního cyklu servisního požadavku.
Popis Atribut Činnost zaznamenává název každého kroku nebo změny stavu v procesu vyřizování servisního požadavku. Může jít například o události „Vytvoření požadavku“, „Schválení požadavku“, „Přiřazení pracovníkovi“ nebo „Uzavření požadavku“. Analýza těchto činností umožňuje zobrazit průběh procesu, určit obvyklé cesty a odhalit odchylky od standardního postupu. Je základem pro pochopení toho, jak vyřizování požadavků skutečně probíhá. Proč je to důležité Jde o povinný atribut, který určuje kroky v procesní mapě. Je nezbytný pro veškerou analýzu procesů, včetně odhalování úzkých míst, opakované práce a problémů se shodou. Kde data získat Odvozuje se ze změn polí „State“ nebo „Stage“ v tabulkách, jako jsou „sc_request“ a „sc_req_item“, případně z auditní stopy (sys_audit). Příklady Vytvoření servisního požadavkuPřiřazení požadavku skupiněVyřešení servisního požadavkuVyžádání informací od uživatele
	Čas zahájení EventTime	Časové razítko označující, kdy činnost nebo událost začala.
Popis Tento atribut zaznamenává přesné datum a čas každé činnosti v procesu vyřizování servisního požadavku. Poskytuje chronologické pořadí událostí potřebné k vytvoření procesní mapy a časové analýze. Přesná časová razítka jsou nezbytná pro výpočet doby průchodu, čekání a zpracování. Pomáhají odhalit úzká místa, porušení SLA a vývoj výkonnosti v čase. Proč je to důležité Toto povinné časové razítko slouží ke správnému seřazení událostí. Je základem veškeré analýzy výkonnosti a doby trvání, včetně výpočtu doby průchodu a odhalování úzkých míst. Kde data získat Obvykle se nachází v polích „sys_updated_on“ nebo „sys_created_on“ příslušných tabulek ServiceNow, například sc_request a sc_task, případně v auditní stopě (sys_audit). Příklady 2023-04-15T10:00:00Z2023-04-15T11:30:15Z2023-04-16T09:05:45Z
	ID servisního požadavku ServiceRequestID	Jedinečný identifikátor každého záznamu servisního požadavku.
Popis ID servisního požadavku je primární klíč, který jednoznačně identifikuje každý servisní požadavek zadaný uživatelem nebo systémem. Propojuje všechny navazující události, od prvotního zaznamenání až po definitivní uzavření. V process mining je tento identifikátor nezbytný k rekonstrukci průběhu každého jednotlivého požadavku a analýze jeho životního cyklu. Proč je to důležité Jde o povinné ID případu. Propojuje všechny související činnosti do jedné instance procesu a umožňuje analyzovat průběh procesu, jeho varianty a dobu průchodu. Kde data získat Tabulka ServiceNow Request [sc_request], pole „number“. Příklady REQ0010001REQ0010025REQ0010112
	Poslední aktualizace dat LastDataUpdate	Časové razítko posledního obnovení nebo extrakce dat.
Popis Tento atribut uvádí datum a čas poslední extrakce dat ze zdrojového systému a jejich načtení do nástroje process mining. Informuje o aktuálnosti analyzovaných dat. Analytici podle něj zjistí, zda pracují s nejnovějšími daty. To je důležité pro provozní monitoring a rozhodování v reálném čase. Pomáhá také stanovit, jak aktuální jsou získané poznatky. Proč je to důležité Uživatelé vědí, jak aktuální jsou data. Mohou tak analýze důvěřovat a rozhodovat se včas na základě dat. Kde data získat Jde o pole metadat doplněné při načítání dat, které obsahuje časové razítko dokončení úlohy ETL. Příklady 2023-10-27T04:00:00Z
	Zdrojový systém SourceSystem	Systém, ze kterého data pocházejí.
Popis Tento atribut určuje zdrojový systém dat, v tomto případě ServiceNow. Hodí se v prostředích, kde se pro celkový pohled na proces spojují data z více systémů. Při analýze dat z jednoho zdroje poskytuje důležitý kontext a pomáhá se správou dat. Uživatelé díky němu vždy vědí, odkud analyzovaná data pocházejí. Proč je to důležité Poskytuje důležitá metadata pro správu dat, sledovatelnost a kontext, zejména při spojování dat z více podnikových systémů. Kde data získat Obvykle jde o statickou hodnotu, která se doplní při extrakci a transformaci dat. Příklady ServiceNow
	Dodrženo SLA MadeSLA	Logická hodnota označující, zda byl servisní požadavek vyřešen v rámci sjednané úrovně služeb.
Popis Tento atribut udává, zda byl servisní požadavek vyřešen v rámci stanovené doby podle SLA (Service Level Agreement). Jde o důležitý ukazatel výsledku, který přímo měří plnění závazků v oblasti služeb. Analýza tohoto příznaku umožňuje vypočítat KPI míry dodržení SLA. Lze jej použít jako dimenzi pro porovnání průběhu požadavků, u nichž bylo SLA dodrženo, s požadavky, u nichž došlo k jeho porušení. Analýza odhalí opakující se vzorce nebo činnosti, které vedou k nedodržení SLA. To je důležité pro včasné sledování rizik a průběžné zlepšování služeb. Proč je to důležité Přímo měří plnění závazků v oblasti služeb. Porovnáním případů, které SLA splnily, s těmi, které ho nesplnily, můžete hledat příčiny jeho porušení. Kde data získat Tabulka ServiceNow Task SLA [task_sla], pole 'has_breached'. Hodnotu je třeba převrátit, například MadeSLA = NOT has_breached. Příklady truefalse
	Kategorie Category	Hlavní klasifikace servisního požadavku, například hardware nebo software.
Popis Kategorie poskytuje základní klasifikaci servisního požadavku. Obvykle slouží k předání požadavku správnému týmu a k přehledu o typech podávaných požadavků. V process mining slouží k filtrování a analýze podle dimenzí. Analytici mohou porovnávat průběh procesu, dobu zpracování a míru automatizace u různých typů požadavků. Odhalí tak rozdíly, které v souhrnných datech nemusí být vidět. Proces u požadavku na hardware se například může výrazně lišit od procesu u požadavku na software. Proč je to důležité Umožňuje rozdělit procesy podle typu služby a porovnávat je. Snáze tak odhalíte problémy a příležitosti ke zlepšení specifické pro jednotlivé kategorie. Kde data získat Tabulka ServiceNow Request Item [sc_req_item], obvykle prostřednictvím kategorie související položky katalogu [sc_cat_item]. Příklady HardwareSoftwarePožadavek na přístupSíť
	Priorita Priority	Úroveň priority servisního požadavku, která ovlivňuje jeho naléhavost.
Popis Priorita určuje relativní důležitost a naléhavost servisního požadavku. Obvykle se stanovuje podle dopadu a naléhavosti a pracovníkům pomáhá rozhodnout, které požadavky vyřídit jako první. Analýza podle priority ukáže, zda se požadavky s vysokou prioritou vyřizují rychleji než požadavky s nízkou prioritou. Filtrováním dashboardů můžete ověřit, zda jsou u kritických požadavků dodržována SLA, a posoudit, zda systém prioritizace funguje. Proč je to důležité Umožňuje rozdělit požadavky do skupin a ověřit, zda se položky s vysokou prioritou vyřizují rychleji. Je důležitá pro analýzu SLA a přidělování zdrojů. Kde data získat Tabulka ServiceNow Request [sc_request] nebo Request Item [sc_req_item], pole „priority“. Příklady 1 - Kritická2 - Vysoká3 - Střední4 - Nízká
	Přiřazeno uživateli AssignedTo	Uživatel odpovědný za práci na servisním požadavku v daném okamžiku.
Popis Tento atribut určuje konkrétního pracovníka nebo technika přiřazeného k servisnímu požadavku. Mění se při předání požadavku jiné osobě. Analýza pole „Assigned To“ je důležitá pro pochopení rozložení práce, výkonu jednotlivých pracovníků a vlivu předávání na dobu vyřešení. Pomáhá posoudit využití zdrojů a odhalit možnosti školení nebo zpřesnění postupů, které omezí změny přiřazení. Proč je to důležité Umožňuje analyzovat vytížení a výkon pracovníků i předávání práce. Je důležitý pro správu zdrojů a odhalování úzkých míst spojených s konkrétními osobami. Kde data získat Tabulky ServiceNow Request Item [sc_req_item] nebo Catalog Task [sc_task], pole 'assigned_to'. Příklady Beth AnglinDavid LooHoward Johnson
	Skupina přiřazení AssignmentGroup	Tým nebo skupina odpovědná za vyřízení servisního požadavku.
Popis Skupina přiřazení označuje tým, například „Service Desk“, „Network Operations“ nebo „Database Administration“, který v dané fázi odpovídá za servisní požadavek. Tento atribut je důležitý pro analýzu průchodu procesu mezi různými oblastmi. Sledování změn skupiny přiřazení umožňuje zobrazit předávání práce mezi týmy, měřit dobu čekání ve frontě každé skupiny a odhalit závislosti nebo prodlevy mezi týmy. To pomáhá zlepšit spolupráci napříč odděleními. Proč je to důležité Sleduje rozložení práce mezi týmy, ukazuje předávání mezi nimi a pomáhá odhalit úzká místa nebo problémy s výkonem konkrétních týmů. Kde data získat Tabulky ServiceNow Request Item [sc_req_item] nebo Catalog Task [sc_task], pole 'assignment_group'. Příklady Servisní centrumPodpora IT L2Příprava hardwaru
	Stav State	Aktuální provozní stav servisního požadavku.
Popis Atribut Stav označuje aktuální fázi životního cyklu servisního požadavku, například „Open“, „Work in Progress“, „Pending“ nebo „Closed“. Změny tohoto pole se často používají k vytvoření činností v procesní mapě. Analýza stavu je důležitá pro zjištění, kolik času požadavky tráví v jednotlivých stavech, zejména při čekání. Pomáhá odhalit fronty a prodlevy, například čekání na informace od uživatele, které často prodlužuje dobu průchodu. Proč je to důležité Ukazuje stav požadavku v libovolném okamžiku a umožňuje analyzovat čekání, fronty i dobu trvání jednotlivých fází procesu. Kde data získat Tabulka ServiceNow Request [sc_request] nebo Request Item [sc_req_item], pole „state“ nebo „stage“. Příklady OtevřenoProbíháČeká se na informace od uživateleUzavřeno, vyřešeno
	Automatizováno IsAutomated	Příznak označující, zda činnost provedl systém nebo automatizace.
Popis Tento logický atribut rozlišuje mezi činnostmi, které provedl pracovník, a činnostmi vykonanými automatizovaným systémem, například workflow nebo integrací. „Vyžádání schválení“ může být například automatizované, zatímco „Přiřazení požadavku pracovníkovi“ může provádět člověk. Analýza tohoto atributu je důležitá pro měření a zvyšování míry automatizace procesu vyřizování servisních požadavků. Pomáhá určit, které manuální úkoly zaberou nejvíce času a mohly by se v budoucnu automatizovat. Tím lze zvýšit efektivitu a snížit náklady. Proč je to důležité Umožňuje měřit míru automatizace a hledat příležitosti k automatizaci manuálních úkolů. Výsledkem může být vyšší efektivita a nižší provozní náklady. Kde data získat Odvozuje se podle toho, zda uživatel, který akci provedl (například 'sys_updated_by'), patří mezi určené systémové nebo integrační uživatele. Příklady truefalse
	Čas ukončení EndTime	Časové razítko označující, kdy byla činnost nebo událost dokončena.
Popis Čas ukončení označuje konec činnosti. Jde o časové razítko následující činnosti v pořadí, které tím uzavírá dobu trvání aktuální činnosti. Tento atribut je nezbytný pro výpočet doby jednotlivých kroků procesu. Porovnáním času zahájení a ukončení činnosti analytici vypočítají dobu zpracování i čekání. To je základem pro odhalování úzkých míst, měření efektivity využití zdrojů a sledování výkonnosti podle časových cílů. Proč je to důležité Tento atribut je nutný k výpočtu doby trvání jednotlivých činností. Ta je základem analýzy výkonnosti, odhalování úzkých míst a vyhodnocování využití zdrojů. Kde data získat Jde o odvozený atribut vypočítaný z hodnoty „StartTime“ následující události v daném případu. Příklady 2023-04-15T10:05:10Z2023-04-15T11:45:00Z2023-04-16T09:15:30Z
	Doba zpracování případu CaseCycleTime	Celková doba od vytvoření servisního požadavku do jeho konečného uzavření.
Popis Doba zpracování případu je vypočítaný ukazatel, který měří celkovou dobu trvání servisního požadavku od časového razítka první události po časové razítko poslední události. Vyjadřuje celkovou dobu zpracování od začátku do konce z pohledu zákazníka. Jde o hlavní KPI celkové efektivity procesu. V souhrnných dashboardech slouží ke sledování plnění cílů a vývoje v čase. Lze jej rozdělit podle kategorií, priority a dalších dimenzí a zjistit, které typy požadavků se vyřizují nejdéle. Proč je to důležité Toto KPI měří výkonnost procesu od začátku do konce. Je důležité pro souhrnné sledování, porovnávání výsledků a hledání oblastí ke zlepšení. Kde data získat Vypočítá se odečtením nejnižší hodnoty 'StartTime' od nejvyšší hodnoty 'EndTime' pro každé jedinečné 'ServiceRequestID'. Příklady 2 10:30:000 04:15:2210 00:05:00
	Hodnocení spokojenosti SatisfactionScore	Hodnocení spokojenosti zákazníka, které žadatel zadal po uzavření požadavku.
Popis Tento atribut zachycuje hodnocení spokojenosti, často na škále od 1 do 5, které koncový uživatel zadá po vyřešení servisního požadavku. Jde o přímé měřítko vnímané kvality služby. Tyto údaje jsou důležité pro dashboard analýzy vlivu na spokojenost zákazníků. Umožňují přímo porovnat ukazatele procesu, například dobu zpracování, opakovanou práci a předávání mezi týmy, s výslednou zkušeností zákazníka. Snáze tak doložíte přínos zlepšení procesů a propojíte provozní efektivitu s výsledky pro zákazníky. Proč je to důležité Propojuje ukazatele výkonnosti procesu s výsledky pro zákazníky. Pomáhá vyčíslit, jak neefektivní procesy ovlivňují zkušenost uživatelů. Kde data získat Obvykle se nachází v související tabulce Survey [asmt_assessment_instance], která je propojena s původním požadavkem. Příklady 5431
	Kanál ContactType	Způsob, kterým žadatel podal servisní požadavek.
Popis Typ kontaktu neboli kanál určuje, jak byl servisní požadavek podán. Mezi běžné kanály patří servisní portál, e-mail, telefonát nebo automatické upozornění. Znalost kanálu je důležitá při analýze rozdílů v procesu, které mohou souviset se způsobem podání. Požadavky zadané přes portál mohou mít například jednotnější strukturu a být více automatizované, takže se zpracují rychleji než požadavky zaslané e-mailem. Analýza pomáhá podporovat efektivnější kanály. Proč je to důležité Pomáhá zjistit, jak různé kanály podání ovlivňují efektivitu procesu, míru automatizace a celkovou dobu zpracování. Na základě těchto poznatků můžete zlepšit způsob, jakým uživatelé zadávají požadavky. Kde data získat Tabulky ServiceNow Request [sc_request] nebo Interaction [interaction]. Pole se často jmenuje 'contact_type'. Příklady PortálE-mailTelefonSamoobsluha
	Kód řešení ResolutionCode	Kód, který označuje konečný způsob vyřešení servisního požadavku.
Popis Kód řešení strukturovaně označuje, jak byl servisní požadavek nakonec vyřešen. Příklady: „Vyřízeno automatizací“, „Chyba uživatele“ nebo „Již není potřeba“. Tento atribut je důležitý pro dashboard analýzy příčin zpoždění. Pokud kódy řešení porovnáte s dlouhou dobou zpracování nebo častou opakovanou prací, můžete odhalit systémové problémy. Jestliže se například požadavky s kódem „Neúplné informace“ pravidelně zpracovávají dlouho, může být problém už při prvotním sběru údajů. Proč je to důležité Poskytuje strukturované údaje o výsledku řešení. Pomáhá hledat příčiny zpoždění, opakované práce a dalších neefektivit v procesu. Kde data získat Tabulka ServiceNow Request Item [sc_req_item] nebo související tabulka úkolů, pole se obvykle jmenuje 'close_code' nebo 'resolution_code'. Příklady Vyřešeno (trvale)Nevyřešeno (nelze zopakovat)Požadavek vyřízenZrušeno uživatelem
	Opakovaná práce IsRework	Vypočítaný příznak označující, zda se činnost v daném případu opakuje.
Popis Tento logický příznak se vypočítává pro identifikaci opakovaných cyklů v rámci servisního požadavku. Má hodnotu 'true', pokud se stejná činnost v daném případu již vyskytla. Může jít například o opakované přiřazení požadavku stejnému týmu nebo o opakované vyžádání informací od uživatele. Tento atribut je důležitý pro dashboard předávání mezi pracovníky a opakované práce i pro KPI míry opakované práce na požadavcích. Umožňuje přímo zobrazit a vyčíslit neefektivní opakující se cykly, které v souhrnných datech často zůstávají skryté. Proč je to důležité Přímo označuje a vyčísluje opakovanou práci v procesu. Můžete tak analyzovat příčiny a dopady neefektivních cyklů, které zvyšují náklady a prodlužují dobu zpracování. Kde data získat Vypočítá se při transformaci dat kontrolou, zda se v rámci stejného případu již vyskytl stejný název činnosti. Příklady falsetrue
	Počet opětovných otevření ReopenCount	Počet případů, kdy byl servisní požadavek po vyřešení znovu otevřen.
Popis Tento atribut zaznamenává, kolikrát se servisní požadavek po vyřešení nebo uzavření vrátil do stavu otevřeno nebo probíhá. Hodnota vyšší než nula znamená, že původní řešení nebylo úspěšné. Ukazatel přímo vypovídá o opakované práci a je důležitou součástí KPI míry vyřešení na první pokus. Časté opětovné otevírání může ukazovat na nízkou kvalitu řešení, neúplné vyřízení nebo nepochopení potřeb uživatele. To vše snižuje efektivitu procesu a spokojenost uživatelů. Proč je to důležité Vyjadřuje rozsah opakované práce a kvalitu řešení. Vysoký počet opětovných otevření upozorňuje na neefektivitu, nízkou úspěšnost vyřešení napoprvé a klesající spokojenost zákazníků. Kde data získat Tabulky ServiceNow Request [sc_request] nebo Request Item [sc_req_item], pole 'reopen_count'. Příklady 012
	Vyřešeno na první pokus IsFirstPassResolution	Příznak označující, zda byl požadavek vyřešen napoprvé a nebyl znovu otevřen.
Popis Tento vypočítaný atribut je logický příznak s hodnotou 'true' pouze tehdy, pokud byl servisní požadavek vyřešen a uzavřen, aniž by byl znovu otevřen. Vypovídá o kvalitě a účinnosti řešení poskytnutého servisním oddělením. Tento ukazatel přímo podporuje KPI míry vyřešení na první pokus. Vysoká hodnota je žádoucí, protože svědčí o efektivní a kvalitní službě a vede k vyšší spokojenosti zákazníků. Analýza případů, které se napoprvé vyřešit nepodařilo, může odhalit příčiny, jako je nedostatečné školení, nekvalitní dokumentace nebo chybná prvotní diagnóza. Proč je to důležité Měří kvalitu a efektivitu procesu řešení. Nízká míra vyřešení na první pokus ukazuje na problémy, které vedou k opakované práci a nespokojenosti zákazníků. Kde data získat Vypočítává se na úrovni případu. Případ se považuje za vyřešený na první pokus, pokud je jeho 'ReopenCount' roven nule. Příklady truefalse
	Zadal OpenedBy	Osoba, která servisní požadavek původně podala.
Popis Tento atribut označuje uživatele, který servisní požadavek vytvořil. Často jde o osobu, které se požadavek týká, ale může to být také vedoucí, zástupce nebo automatizovaný systém. Analýza požadavků podle uživatele, který je zadal, nebo podle jeho oddělení pomáhá odhalit opakující se vzorce. Může například ukázat skupinu uživatelů, která často podává složité nebo problematické požadavky. Tyto poznatky lze využít při cíleném školení nebo při přípravě lepších článků znalostní báze, které podpoří samoobsluhu. Proč je to důležité Pomáhá analyzovat požadavky podle uživatele, oddělení nebo role. Výsledky mohou posloužit při plánování školení a cíleném zlepšování procesů. Kde data získat Tabulka ServiceNow Request [sc_request], pole 'opened_by'. Příklady Abel TuterFred LuddyDon Goodliffe

Povinné Doporučené Volitelné

Aktivity v řízení servisních požadavků

Zachyťte tyto důležité kroky a milníky v záznamu událostí, abyste mohli přesně zjistit, jak proces probíhá, a odhalit úzká místa.

6 Doporučené 8 Volitelné

	Aktivita	Popis
	Přiřazení požadavku pracovníkovi	Tato činnost nastane, když je k vyřízení servisního požadavku přiřazen konkrétní pracovník. Zaznamená se sledováním změn pole „Assigned to“ u požadavku nebo souvisejících úkolů.
Proč je to důležité Tento údaj je důležitý pro měření předávání práce, výpočet vytížení jednotlivých pracovníků a analýzu čekání ve frontě před zahájením práce na požadavku. Kde data získat Událost se odvozuje ze změny pole assigned_to v tabulce sc_req_item nebo sc_task. Historie změn se zaznamenává v tabulce sys_audit. Zachycení Sledujte změny pole assigned_to v tabulce sys_audit. Typ události inferred
	Schválení požadavku	Tato činnost označuje, že požadavek byl oficiálně schválen a může pokračovat k vyřízení. Zaznamená se, když schvalovatel označí související záznam o schválení jako „approved“.
Proč je to důležité Tento důležitý milník označuje přechod ze schvalování k vyřízení. Doba do jeho dosažení pomáhá odhalit prodlevy před zahájením vyřízení. Kde data získat Událost se odvozuje ze změny pole state v souvisejícím záznamu sysapproval_approver na „approved“. Ta následně vyvolá změnu stavu v záznamu sc_req_item. Zachycení Určete časové razítko, kdy se sysapproval_approver.state změní na „approved“. Typ události inferred
	Uzavření servisního požadavku	Označuje definitivní konec životního cyklu servisního požadavku. Obvykle nastane automaticky po uplynutí stanovené doby ve stavu „Resolved“, během níž může uživatel požadavek znovu otevřít.
Proč je to důležité Jde o hlavní úspěšnou koncovou událost procesu. Analýza doby mezi stavy „Resolved“ a „Closed“ také pomáhá vyhodnotit pravidla automatického uzavírání. Kde data získat Událost se odvozuje ze změny pole state v záznamu sc_req_item na konečný uzavřený stav, například „Closed Complete“. Změna se zaznamenává v tabulce sys_audit. Zachycení Určete časové razítko, kdy se sc_req_item.state změní na „Closed Complete“. Typ události inferred
	Vyřešení servisního požadavku	Tato činnost označuje dokončení práce pracovníkem a předání řešení. Zaznamená se, když se stav požadavku změní na „Resolved“ nebo podobný stav.
Proč je to důležité Jde o důležitý milník, který obvykle zastaví měření SLA. Označuje konec aktivního vyřizování a je podstatný pro výpočet celkové doby vyřešení. Kde data získat Událost se odvozuje ze změny pole state v záznamu sc_req_item na „Resolved“ nebo podobný konečný stav před definitivním uzavřením. Změna se zaznamenává v tabulce sys_audit. Zachycení Určete časové razítko, kdy se sc_req_item.state změní na „Resolved“. Typ události inferred
	Vytvoření servisního požadavku	Tato činnost zahajuje životní cyklus servisního požadavku. Zaznamená se, když uživatel odešle požadavek prostřednictvím katalogu služeb. Systém ji eviduje jako vytvoření nového záznamu v tabulce sc_req_item (Requested Item).
Proč je to důležité Jde o hlavní počáteční událost procesu. Je nezbytná pro výpočet celkové doby průchodu procesem a analýzu počtu i způsobu zadávání požadavků. Kde data získat Jde o explicitní událost zaznamenanou podle časového razítka vytvoření záznamu (pole sys_created_on) v tabulce sc_req_item. Zachycení Použijte časové razítko sys_created_on ze záznamu sc_req_item. Typ události explicit
	Vyžádání informací od uživatele	Událost nastane, když pracovník zajišťující vyřízení potřebuje od původního žadatele další informace. Obvykle se odvozuje ze změny stavu požadavku na hodnotu jako „Awaiting User Info“.
Proč je to důležité Tato činnost je důležitá pro dashboard „Requestor Information Delay Analysis“, který pomáhá vyčíslit čas ztracený čekáním na informace od uživatele. Kde data získat Událost se odvozuje ze změny pole state v záznamu sc_req_item na určený stav čekání na informace. Změna se zaznamenává v tabulce sys_audit. Zachycení Určete časové razítko, kdy se sc_req_item.state změní na „Awaiting User Info“. Typ události inferred
	Doplnění informací uživatelem	Tato činnost označuje okamžik, kdy žadatel dodá potřebné informace. Odvozuje se z přechodu požadavku ze stavu „Awaiting User Info“ zpět do aktivního stavu, například „Work in Progress“.
Proč je to důležité Ve spojení s činností „Vyžádání informací od uživatele“ umožňuje přesně měřit prodlevy způsobené čekáním na uživatele a vyhodnocovat efektivitu komunikace. Kde data získat Událost se odvozuje ze změny pole state v záznamu sc_req_item ze stavu čekání na informace na aktivní stav. Často ji vyvolá komentář uživatele nebo odpověď na e-mail. Zachycení Určete časové razítko, kdy se stav změní z „Awaiting User Info“ na „Work in Progress“. Typ události inferred
	Přiřazení požadavku skupině	Označuje přiřazení servisního požadavku konkrétnímu týmu nebo skupině, která jej vyřídí. Událost se odvozuje ze změny pole assignment group u požadavku nebo souvisejících úkolů.
Proč je to důležité Sledování přiřazení skupinám pomáhá analyzovat rozložení práce mezi týmy a odhalit prodlevy před předáním požadavku správnému týmu. Kde data získat Událost se odvozuje ze změny pole assignment_group v tabulce sc_req_item nebo sc_task. Historie změn se zaznamenává v tabulce sys_audit. Zachycení Sledujte změny pole assignment_group v tabulce sys_audit. Typ události inferred
	Vytvoření úkolu k vyřízení	Označuje vytvoření konkrétní pracovní položky nebo úkolu potřebného k vyřízení servisního požadavku. Událost se zaznamená při vytvoření nového záznamu v tabulce Catalog Task.
Proč je to důležité U složitých požadavků poskytuje analýza vytváření a dokončování jednotlivých úkolů podrobnější pohled na vyřizování a místa, kde vznikají prodlevy. Kde data získat Jde o explicitní událost zaznamenanou podle časového razítka vytvoření (pole sys_created_on) záznamu v tabulce sc_task, který je propojený se záznamem sc_req_item. Zachycení Použijte časové razítko sys_created_on ze záznamů sc_task. Typ události explicit
	Žádost o schválení	Označuje okamžik, kdy je servisní požadavek předán ke schválení nadřízenému nebo jinému určenému schvalovateli. Obvykle se odvozuje ze změny stavu požadavku na „Pending Approval“ nebo podobný stav.
Proč je to důležité Sledování schvalování pomáhá odhalit úzká místa ve schvalovacím procesu a měřit, jak dlouho požadavky čekají na schválení, než může začít jejich vyřízení. Kde data získat Událost se odvozuje ze změny pole state v záznamu sc_req_item na hodnotu čekající na schválení nebo z vytvoření odpovídajícího záznamu v tabulce sysapproval_approver. Změny se zaznamenávají v tabulce sys_audit. Zachycení Určete časové razítko, kdy se sc_req_item.state změní na „Pending Approval“. Typ události inferred
	Zamítnutí požadavku	Tato činnost označuje formální zamítnutí požadavku během schvalování. Jde o alternativní cestu k uzavření a zaznamená se, když schvalovatel označí požadavek jako „rejected“.
Proč je to důležité Sledování zamítnutí pomáhá odhalit neplatné nebo nesprávně směrované požadavky i problémy s jejich zadáváním. Zároveň jde o důležitou výjimečnou cestu, kterou lze analyzovat. Kde data získat Událost se odvozuje ze změny pole state v souvisejícím záznamu sysapproval_approver na „rejected“. Tím se obvykle nadřazený záznam sc_req_item nastaví na uzavřený, neúplný stav. Zachycení Určete časové razítko, kdy se sysapproval_approver.state změní na „rejected“. Typ události inferred
	Zapojení externího dodavatele	Označuje předání servisního požadavku nebo některého z jeho úkolů externímu dodavateli k vyřízení. Událost lze odvodit z přiřazení skupině dodavatele nebo z příznaku v požadavku.
Proč je to důležité Tato činnost umožňuje analyzovat výkon dodavatele a jeho vliv na celkový průběh požadavku. Je důležitá pro dashboard „External Vendor Engagement Cycle“. Kde data získat Událost se obvykle odvozuje. Může vycházet z nastavení pole assignment_group na skupinu dodavatele nebo z nastavení konkrétního příznaku v záznamu sc_req_item či sc_task. Zachycení Zjistěte, kdy se assignment_group změní na známou skupinu dodavatele. Typ události inferred
	Znovuotevření požadavku	Tato činnost zachycuje případy, kdy se požadavek, který byl dříve označen jako vyřešený, vrátí do otevřeného stavu. Odvozuje se ze změny stavu z „Resolved“ zpět na „Work in Progress“ nebo podobný stav.
Proč je to důležité Jde o přímou míru opakované práce a důležitý údaj pro výpočet KPI „First-Pass Resolution Rate“. Vysoký počet znovu otevřených požadavků ukazuje na nekvalitní nebo neúplné vyřešení. Kde data získat Událost se odvozuje ze změny pole state v záznamu sc_req_item z vyřešeného nebo uzavřeného stavu zpět na otevřený stav, ve kterém se na požadavku pracuje. Změna se zaznamenává v tabulce sys_audit. Zachycení V tabulce sys_audit zjistěte změnu stavu z „Resolved“ na „Work in Progress“. Typ události inferred
	Zrušení požadavku	Tato činnost označuje konečný stav požadavku zrušeného před dokončením, ať už uživatelem, nebo pracovníkem. Zaznamená se, když se stav požadavku změní na „Cancelled“ nebo „Closed Cancelled“.
Proč je to důležité Jde o důležitou neúspěšnou koncovou událost. Analýza příčin zrušení pomáhá lépe porozumět potřebám uživatelů, neefektivitě procesu i změnám obchodních priorit. Kde data získat Událost se odvozuje ze změny pole state v záznamu sc_req_item na konečný stav zrušení, například „Closed Cancelled“. Změna se zaznamenává v tabulce sys_audit. Zachycení Určete časové razítko, kdy se sc_req_item.state změní na „Cancelled“. Typ události inferred

Doporučené Volitelné

Návody k získání dat

Jak získat data ze ServiceNow

Kroky

Seznamte se s postupem exportu z více tabulek: Vzhledem k tomu, jak je v ServiceNow navržen datový model, nelze všechny potřebné události získat jediným exportem. Data je třeba exportovat z několika tabulek a následně je spojit mimo ServiceNow. Hlavní tabulky jsou Requested Item (sc_req_item), Approval (sysapproval_approver), Catalog Task (sc_task) a Audit (sys_audit).
Export 1: Základní data servisních požadavků: Otevřete tabulku Requested Item zadáním sc_req_item.list do navigátoru filtrů. Nastavte filtr požadovaného období, například [Created] [on] [Last 6 months]. Přidejte sloupce jako Number, Sys Created On, Resolved, Closed, State, Assignment group, Assigned to, Priority a Made SLA. Klikněte pravým tlačítkem na záhlaví libovolného sloupce, vyberte Export a zvolte CSV nebo XLSX.
Export 2: Rozhodnutí o schválení: Otevřete tabulku Approval zadáním sysapproval_approver.list. Filtrujte záznamy související se servisními požadavky: [Source table] [is] [sc_req_item] AND [Created] [on] [Last 6 months]. Přidejte sloupce jako Approving.Number, State, Sys Created On a Sys Updated On. Exportujte vyfiltrovaný seznam.
Export 3: Vytvoření úkolů k vyřízení: Otevřete tabulku Catalog Task zadáním sc_task.list. Nastavte filtr, který propojí úkoly s požadavky z vybraného období, například [Request Item.Created] [on] [Last 6 months]. Přidejte sloupce Request Item.Number, Sys Created On, State, Assignment group a Assigned to. Exportujte data.
Export 4: Podrobná historie aktivit: Otevřete tabulku Audit pomocí sys_audit.list. Obsahuje historii změn polí. Nastavte filtr [Table name] [is] [sc_req_item] AND [Created] [on] [Last 6 months] AND [Field name] [is one of] [state, assignment_group, assigned_to]. Přidejte sloupce Document key, Field name, Old value, New value a Sys Created On. Exportujte data. Přístup k této tabulce může vyžadovat rozšířená oprávnění.
Spojte a transformujte data: Pomocí nástroje, jako je Microsoft Excel, Python s knihovnou pandas nebo specializovaný nástroj pro přípravu dat, spojte čtyři exportované soubory. Jako společný klíč použijte číslo servisního požadavku nebo Sys ID.
Vytvořte strukturu záznamu událostí: Ve spojeném souboru vytvořte požadované sloupce: ServiceRequestID, ActivityName a EventTime.
Namapujte zdrojová data na aktivity: Pro každou jedinečnou aktivitu vytvořte nový řádek. Například:
- U aktivity Service Request Created použijte hodnotu Sys Created On z exportu sc_req_item.
- U aktivity Request Approved použijte hodnotu Sys Updated On z exportu sysapproval_approver, kde se State změnil na 'approved'.
- U aktivity Request Assigned to Group vyhledejte v exportu sys_audit řádek, kde má Field name hodnotu assignment_group, a jako EventTime použijte hodnotu Sys Created On z tohoto záznamu auditu.
Vyplňte sloupce s atributy: U každého řádku aktivity vyplňte atributy AssignedTo, AssignmentGroup, Priority, State, Category a MadeSLA. Hodnoty musí odpovídat stavu požadavku v okamžiku události.
Přidejte sloupce s metadaty: Přidejte SourceSystem se statickou hodnotou, například 'ServiceNow', a LastDataUpdate s časovým razítkem okamžiku extrakce.
Dokončete export: Uložte výsledná transformovaná a spojená data do jednoho souboru CSV. Zkontrolujte, že názvy sloupců odpovídají požadavkům na import.

Konfigurace

Cílové tabulky: Extrakce vyžaduje data z několika tabulek:
- sc_req_item: Obsahuje hlavní záznamy servisních požadavků (Requested Item).
- sysapproval_approver: Uchovává záznamy o schválení požadavků.
- sc_task: Obsahuje jednotlivé úkoly pro vyřízení požadavku.
- sys_audit: Poskytuje podrobnou historii změn polí, která je nezbytná pro sledování přiřazení a změn stavu.
Filtrování podle období: Ve všech exportech je nutné použít stejné období, například Created on Last 6 months, aby byla data konzistentní. Doporučujeme období 3 až 6 měsíců, které nabízí vhodný poměr mezi objemem dat a množstvím poznatků.
Důležité filtry: Kromě období použijte v tabulce schválení filtr Source table is sc_req_item a v tabulce auditu Table name is sc_req_item, abyste vybrali relevantní záznamy.
Nezbytné sloupce: Exportujte identifikátory, jako jsou Number a Sys ID (v auditu Document key), abyste mohli datové sady propojit. Časová razítka Sys Created On, Sys Updated On, Resolved a Closed jsou základem pro vytvoření záznamu událostí.
Předpoklady: Pro přístup k většině potřebných tabulek potřebujete účet ServiceNow alespoň s rolí itil. Export z tabulky sys_audit může vzhledem k jejímu objemu a citlivosti vyžadovat roli admin nebo jinou specializovanou roli.

Ukázkový dotaz config

This method uses the ServiceNow user interface for filtering and exporting, so there is no single script. The configuration consists of setting filters and choosing columns for multiple list views.

**Configuration for Export 1: Requested Items**
*   **Table**: `sc_req_item`
*   **Filter Conditions**:
    1. `[Created] [on] [Last 6 months]`
    2. `[Active] [is one of] [true, false]` (Or adjust based on process scope)
*   **Columns to Add**: `Number`, `Sys ID`, `Sys Created On`, `Resolved`, `Closed`, `State`, `Stage`, `Assignment group`, `Assigned to`, `Priority`, `Category`, `Made SLA`

**Configuration for Export 2: Approvals**
*   **Table**: `sysapproval_approver`
*   **Filter Conditions**:
    1. `[Source table] [is] [sc_req_item]`
    2. `[Created] [on] [Last 6 months]`
*   **Columns to Add**: `Approving`, `Approving.Number`, `State`, `Sys Created On`, `Sys Updated On`

**Configuration for Export 3: Catalog Tasks**
*   **Table**: `sc_task`
*   **Filter Conditions**:
    1. `[Request Item.Created] [on] [Last 6 months]`
*   **Columns to Add**: `Request Item`, `Request Item.Number`, `Sys Created On`, `Sys Updated On`, `State`, `Assignment group`, `Assigned to`

**Configuration for Export 4: Audit History**
*   **Table**: `sys_audit`
*   **Filter Conditions**:
    1. `[Table name] [is] [sc_req_item]`
    2. `[Created] [on] [Last 6 months]`
    3. `[Field name] [is one of] [state, assignment_group, assigned_to]`
*   **Columns to Add**: `Document key`, `Table name`, `Field name`, `Old value`, `New value`, `Sys Created On`

Kroky

Připravte prostředí Pythonu: Ověřte, že máte nainstalovaný Python 3.6 nebo novější. Pomocí pip nainstalujte potřebné knihovny: pip install requests pandas.
Nastavte parametry skriptu: Otevřete skript Pythonu v editoru. V horní části najděte sekci s nastavením. Zadejte URL instance ServiceNow, například https://your-instance.service-now.com, uživatelské jméno a heslo servisního účtu s potřebnými oprávněními ke čtení požadovaných tabulek.
Nastavte období extrakce: Upravte proměnné start_date a end_date a určete počáteční a koncové datum extrakce dat. Doporučujeme začít kratším obdobím, například 3 měsíci, otestovat skript a ověřit jeho výkon.
Zkontrolujte názvy tabulek a polí: Skript používá standardní názvy tabulek ServiceNow, například sc_req_item, sys_audit a sc_task. Ověřte, že názvy tabulek a polí odpovídají vaší konfiguraci ServiceNow. Pokud instance používá vlastní tabulky nebo pole, upravte je ve skriptu.
Spusťte skript Pythonu: Spusťte skript z příkazového řádku nebo terminálu příkazem python your_script_name.py. Skript se připojí k API ServiceNow, načte data pro každou zadanou aktivitu a v konzoli zobrazí průběh.
Zpracujte stránkování API: Skript obsahuje funkci, která stránkování zpracuje automaticky. Pokud počet záznamů překročí limit stránky (sysparm_limit), odešle další volání API, dokud nenačte všechna data ze zadaného období.
Transformujte a spojte data: Skript zpracuje surovou odpověď JSON z API pro každý typ aktivity. Vybere potřebná pole, namapuje je na schéma záznamu událostí (ServiceRequestID, ActivityName, EventTime atd.) a spojí je do jedné datové sady.
Vytvořte soubor záznamu událostí: Po dokončení skript uloží výsledný záznam událostí do souboru CSV servicenow_servicerequest_eventlog.csv ve stejné složce, ze které byl spuštěn.
Připravte data k nahrání: Otevřete vytvořený soubor CSV v tabulkovém procesoru a zkontrolujte úplnost a správnost dat. Před nahráním ověřte, že názvy sloupců odpovídají požadovanému schématu ProcessMind.

Konfigurace

URL instance ServiceNow: Základní URL vaší instance ServiceNow, například https://your-instance.service-now.com.
Ověření: Potřebujete uživatelské jméno a heslo servisního účtu s přístupem ke čtení tabulek sc_req_item, sys_audit, sysapproval_approver a sc_task.
Období: Proměnnými start_date a end_date ve skriptu nastavte časové období extrakce. Pro první analýzu doporučujeme 3 až 6 měsíců.
Limit stránky (sysparm_limit): Skript omezuje počet záznamů vrácených v jednom volání API. Výchozí hodnota je 1000, což je bezpečná volba pro většinu instancí. Podle výkonu systému a limitů API ji můžete upravit.
Filtry dotazu (sysparm_query): Skript omezuje načítaná data pomocí filtrů podle data (sys_created_on>=...). Do řetězce dotazu můžete přidat další filtry, například konkrétní katalogovou položku nebo skupinu přiřazení, a snížit tak objem dat (active=true^category=hardware).
Zobrazované hodnoty: Parametr sysparm_display_value=true načítá pro referenční pole čitelné názvy místo interních hodnot sys_id. To je důležité například u atributů AssignmentGroup a AssignedTo.

Ukázkový dotaz python

import requests
import pandas as pd
import datetime

class=class="hl-string">"hl-comment"># --- Configuration ---
SN_INSTANCE = class="hl-string">'https://[your-instance].service-now.com'
SN_USER = class="hl-string">'[your-username]'
SN_PASSWORD = class="hl-string">'[your-password]'

class=class="hl-string">"hl-comment"># Date range for the extraction (YYYY-MM-DD)
start_date = class="hl-string">'[YYYY-MM-DD]'
end_date = class="hl-string">'[YYYY-MM-DD]'

class=class="hl-string">"hl-comment"># --- End Configuration ---

def query_servicenow_table(table, query, fields):
    class="hl-string">"""Queries a ServiceNow table with pagination."""
    all_records = []
    offset = 0
    limit = 1000
    
    headers = {class="hl-string">"Accept": class="hl-string">"application/json"}
    url = fclass="hl-string">"{SN_INSTANCE}/api/now/table/{table}"
    
    while True:
        params = {
            class="hl-string">'sysparm_query': query,
            class="hl-string">'sysparm_fields': class="hl-string">','.join(fields),
            class="hl-string">'sysparm_limit': limit,
            class="hl-string">'sysparm_offset': offset,
            class="hl-string">'sysparm_display_value': class="hl-string">'true',
            class="hl-string">'sysparm_exclude_reference_link': class="hl-string">'true'
        }
        
        print(fclass="hl-string">"Querying {table} with offset {offset}...")
        response = requests.get(url, auth=(SN_USER, SN_PASSWORD), headers=headers, params=params)
        response.raise_for_status() class=class="hl-string">"hl-comment"># Raise an exception for bad status codes
        
        records = response.json().get(class="hl-string">'result', [])
        if not records:
            break
        all_records.extend(records)
        offset += limit
        
    return all_records

def main():
    class="hl-string">"""Main function to extract, transform, and save the event log."""
    all_events = []
    source_system = class="hl-string">'ServiceNow'
    last_data_update = datetime.datetime.now().isoformat()

    class=class="hl-string">"hl-comment"># Define common attributes to fetch for context
    context_fields = [class="hl-string">'number', class="hl-string">'assignment_group', class="hl-string">'assigned_to', class="hl-string">'priority', class="hl-string">'state', class="hl-string">'cat_item.category', class="hl-string">'made_sla']

    class=class="hl-string">"hl-comment"># 1. Service Request Created
    query = fclass="hl-string">'sys_created_on>={start_date} 00:00:00^sys_created_on<={end_date} 23:59:59'
    fields = [class="hl-string">'sys_created_on'] + context_fields
    req_items = query_servicenow_table(class="hl-string">'sc_req_item', query, fields)
    for item in req_items:
        all_events.append({
            class="hl-string">'ServiceRequestID': item[class="hl-string">'number'],
            class="hl-string">'ActivityName': class="hl-string">'Service Request Created',
            class="hl-string">'EventTime': item[class="hl-string">'sys_created_on'],
            class="hl-string">'AssignedTo': item.get(class="hl-string">'assigned_to'),
            class="hl-string">'AssignmentGroup': item.get(class="hl-string">'assignment_group'),
            class="hl-string">'Priority': item.get(class="hl-string">'priority'),
            class="hl-string">'State': item.get(class="hl-string">'state'),
            class="hl-string">'Category': item.get(class="hl-string">'cat_item.category'),
            class="hl-string">'MadeSLA': item.get(class="hl-string">'made_sla')
        })

    class=class="hl-string">"hl-comment"># Get a list of relevant document keys (sys_id of sc_req_item)
    doc_keys_query = fclass="hl-string">'tablename=sc_req_item^sys_created_on>={start_date} 00:00:00^sys_created_on<={end_date} 23:59:59'
    audit_records = query_servicenow_table(class="hl-string">'sys_audit', doc_keys_query, [class="hl-string">'documentkey'])
    relevant_doc_keys = list(set([rec[class="hl-string">'documentkey'] for rec in audit_records]))
    
    class=class="hl-string">"hl-comment"># Query audit and other tables in batches to avoid long URLs
    batch_size = 50
    for i in range(0, len(relevant_doc_keys), batch_size):
        key_batch = relevant_doc_keys[i:i+batch_size]
        key_batch_str = class="hl-string">','.join(key_batch)

        class=class="hl-string">"hl-comment"># 2-14. Activities from sys_audit, sysapproval_approver, sc_task
        class=class="hl-string">"hl-comment"># Fetch sc_req_item details for context
        ritm_context = {ritm[class="hl-string">'sys_id']: ritm for ritm in query_servicenow_table(class="hl-string">'sc_req_item', fclass="hl-string">'sys_idIN{key_batch_str}', [class="hl-string">'sys_id'] + context_fields)}

        class=class="hl-string">"hl-comment"># Activities based on state changes and field updates from sys_audit
        audit_query = fclass="hl-string">'documentkeyIN{key_batch_str}^fieldnameINassignment_group,assigned_to,state'
        audit_log = query_servicenow_table(class="hl-string">'sys_audit', audit_query, [class="hl-string">'documentkey', class="hl-string">'sys_created_on', class="hl-string">'fieldname', class="hl-string">'newvalue', class="hl-string">'oldvalue'])
        for log in audit_log:
            context = ritm_context.get(log[class="hl-string">'documentkey'], {})
            if not context:
                continue

            event = {
                class="hl-string">'ServiceRequestID': context.get(class="hl-string">'number'),
                class="hl-string">'EventTime': log[class="hl-string">'sys_created_on'],
                class="hl-string">'AssignedTo': context.get(class="hl-string">'assigned_to'),
                class="hl-string">'AssignmentGroup': context.get(class="hl-string">'assignment_group'),
                class="hl-string">'Priority': context.get(class="hl-string">'priority'),
                class="hl-string">'State': context.get(class="hl-string">'state'),
                class="hl-string">'Category': context.get(class="hl-string">'cat_item.category'),
                class="hl-string">'MadeSLA': context.get(class="hl-string">'made_sla'),
            }
            activity = None
            class=class="hl-string">"hl-comment"># Map audit entries to activities
            if log[class="hl-string">'fieldname'] == class="hl-string">'assignment_group' and log[class="hl-string">'newvalue']:
                activity = class="hl-string">'Request Assigned to Group'
                event[class="hl-string">'AssignmentGroup'] = log[class="hl-string">'newvalue']
            elif log[class="hl-string">'fieldname'] == class="hl-string">'assigned_to' and log[class="hl-string">'newvalue']:
                activity = class="hl-string">'Request Assigned to Agent'
                event[class="hl-string">'AssignedTo'] = log[class="hl-string">'newvalue']
            elif log[class="hl-string">'fieldname'] == class="hl-string">'state':
                class=class="hl-string">"hl-comment"># Define state mappings, may need customization
                state_map = {
                    class="hl-string">'Awaiting User Info': class="hl-string">'Information Requested from User',
                    class="hl-string">'Resolved': class="hl-string">'Service Request Resolved',
                    class="hl-string">'Closed Complete': class="hl-string">'Service Request Closed',
                    class="hl-string">'Closed Cancelled': class="hl-string">'Request Cancelled'
                }
                if log[class="hl-string">'newvalue'] in state_map:
                    activity = state_map[log[class="hl-string">'newvalue']]
                elif log[class="hl-string">'oldvalue'] == class="hl-string">'Awaiting User Info':
                    activity = class="hl-string">'Information Provided by User'
                elif log[class="hl-string">'oldvalue'] == class="hl-string">'Resolved':
                    activity = class="hl-string">'Request Reopened'
                class=class="hl-string">"hl-comment"># For class="hl-string">'Approval Requested', class="hl-string">'External Vendor Engaged' - more complex logic might be needed
                class=class="hl-string">"hl-comment"># This is a common inference. Adjust if you have a specific state.
                if log[class="hl-string">'newvalue'] == class="hl-string">'Pending Approval':
                     activity = class="hl-string">'Approval Requested'

            if activity:
                event[class="hl-string">'ActivityName'] = activity
                all_events.append(event)

        class=class="hl-string">"hl-comment"># Approval Activities
        approval_query = fclass="hl-string">'sysapprovalIN{key_batch_str}'
        approvals = query_servicenow_table(class="hl-string">'sysapproval_approver', approval_query, [class="hl-string">'sysapproval', class="hl-string">'sys_updated_on', class="hl-string">'state'])
        for appr in approvals:
            context = ritm_context.get(appr[class="hl-string">'sysapproval'], {})
            if not context: continue
            activity = None
            if appr[class="hl-string">'state'] == class="hl-string">'approved':
                activity = class="hl-string">'Request Approved'
            elif appr[class="hl-string">'state'] == class="hl-string">'rejected':
                activity = class="hl-string">'Request Rejected'
            if activity:
                all_events.append({
                    class="hl-string">'ServiceRequestID': context.get(class="hl-string">'number'),
                    class="hl-string">'ActivityName': activity,
                    class="hl-string">'EventTime': appr[class="hl-string">'sys_updated_on'],
                    class="hl-string">'AssignedTo': context.get(class="hl-string">'assigned_to'), class="hl-string">'AssignmentGroup': context.get(class="hl-string">'assignment_group'), class="hl-string">'Priority': context.get(class="hl-string">'priority'), class="hl-string">'State': context.get(class="hl-string">'state'), class="hl-string">'Category': context.get(class="hl-string">'cat_item.category'), class="hl-string">'MadeSLA': context.get(class="hl-string">'made_sla')
                })

        class=class="hl-string">"hl-comment"># Fulfillment Task Creation
        task_query = fclass="hl-string">'request_itemIN{key_batch_str}'
        tasks = query_servicenow_table(class="hl-string">'sc_task', task_query, [class="hl-string">'request_item', class="hl-string">'sys_created_on', class="hl-string">'number'])
        for task in tasks:
            context = ritm_context.get(task[class="hl-string">'request_item'], {})
            if not context: continue
            all_events.append({
                class="hl-string">'ServiceRequestID': context.get(class="hl-string">'number'),
                class="hl-string">'ActivityName': fclass="hl-string">'Fulfillment Task Created - {task["number"]}',
                class="hl-string">'EventTime': task[class="hl-string">'sys_created_on'],
                class="hl-string">'AssignedTo': context.get(class="hl-string">'assigned_to'), class="hl-string">'AssignmentGroup': context.get(class="hl-string">'assignment_group'), class="hl-string">'Priority': context.get(class="hl-string">'priority'), class="hl-string">'State': context.get(class="hl-string">'state'), class="hl-string">'Category': context.get(class="hl-string">'cat_item.category'), class="hl-string">'MadeSLA': context.get(class="hl-string">'made_sla')
            })

    class=class="hl-string">"hl-comment"># Post-processing and saving
    if not all_events:
        print(class="hl-string">"No events found for the given criteria.")
        return

    df = pd.DataFrame(all_events)
    df[class="hl-string">'SourceSystem'] = source_system
    df[class="hl-string">'LastDataUpdate'] = last_data_update
    
    class=class="hl-string">"hl-comment"># Reorder columns to match schema
    final_cols = [class="hl-string">'ServiceRequestID', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate', class="hl-string">'AssignedTo', class="hl-string">'AssignmentGroup', class="hl-string">'Priority', class="hl-string">'State', class="hl-string">'Category', class="hl-string">'MadeSLA']
    df = df[final_cols]
    
    df.sort_values(by=[class="hl-string">'ServiceRequestID', class="hl-string">'EventTime'], inplace=True)
    df.to_csv(class="hl-string">'servicenow_servicerequest_eventlog.csv', index=False)
    print(class="hl-string">"Extraction complete. File saved to servicenow_servicerequest_eventlog.csv")

if __name__ == class="hl-string">'__main__':
    main()

Kroky

Vytvořte uživatele API pro ServiceNow: Ve své instanci ServiceNow vytvořte samostatného uživatele pro tuto integraci. Přiřaďte mu role rest_service a itil. Ověřte, že má oprávnění ke čtení (ACL) následujících tabulek: Requested Item (sc_req_item), Catalog Task (sc_task), Approval (sysapproval_approver) a Audit (sys_audit).
Připravte vývojové prostředí: Na počítač, který použijete k extrakci, nainstalujte Node.js. Poté inicializujte nový projekt Node.js a nainstalujte knihovny axios pro odesílání HTTP požadavků a fast-csv pro zápis výstupního souboru. V terminálu spusťte npm install axios fast-csv.
Nakonfigurujte skript pro extrakci: Zkopírujte poskytnutý kód JavaScriptu do souboru, například extract.js. Doplňte zástupné hodnoty v horní části skriptu: URL instance ServiceNow, uživatelské jméno API a heslo.
Nastavte období a filtry: Upravte proměnné startDate a endDate ve skriptu a vymezte tak období extrakce. Do řetězců sysparm_query pro jednotlivé aktivity můžete přidat další filtry, které zúží rozsah, například na konkrétní položku katalogu nebo skupinu přiřazení.
Seznamte se s voláním API: Skript provádí samostatná volání API pro každou ze 14 požadovaných aktivit. Události, jako je vytvoření, získává přímo ze zdrojových tabulek (sc_req_item, sc_task). Změny stavu a přiřazení zjišťuje dotazem na konkrétní změny polí v tabulce sys_audit.
Spusťte skript: V terminálu spusťte příkaz node extract.js. Skript se připojí k Table API ServiceNow, načte data pro jednotlivé aktivity a automaticky zpracuje stránkování.
Zpracujte data: Při načítání skript převede odpověď JSON ze ServiceNow do standardizovaného formátu záznamu událostí a namapuje pole na sloupce, jako jsou ServiceRequestID, ActivityName a EventTime.
Spojte výsledky: Skript shromáždí výsledky všech jednotlivých volání API do jednoho pole, které představuje úplný záznam událostí.
Vytvořte výstupní soubor: Po načtení a zpracování všech dat zapíše skript pomocí knihovny fast-csv spojený záznam událostí do souboru servicenow_event_log.csv ve stejné složce.
Připravte soubor k nahrání: Vytvořený soubor CSV obsahuje požadované sloupce pro process mining. Před nahráním na platformu ProcessMind není třeba provádět další úpravy formátu.

Konfigurace

URL instance ServiceNow: Základní URL vašeho prostředí ServiceNow, například https://your-instance.service-now.com.
Přihlašovací údaje API: Platné uživatelské jméno a heslo uživatele ServiceNow s potřebnými oprávněními ke čtení a rolemi (rest_service, itil).
Období: Doporučujeme extrahovat data za 3 až 6 měsíců, abyste získali reprezentativní datovou sadu. Období nastavte ve skriptu pomocí proměnných startDate a endDate. Použijí se pro příslušná časová pole v dotazech API.
sysparm_query: Hlavní parametr URL pro filtrování záznamů. Skript jej používá k výběru konkrétních událostí, například záznamů vytvořených v určitém období nebo záznamů auditu, které zachycují změnu stavu z 'Resolved' na 'Work in Progress'.
sysparm_fields: Tento parametr určuje, které sloupce má volání API vrátit. Jeho použitím výrazně zlepšíte výkon, protože se přenese méně dat. Skript potřebná pole pro každý dotaz nastavuje předem.
Limit stránkování (sysparm_limit): Skript načítá záznamy po dávkách po 1000. Tuto hodnotu lze upravit, ale kvůli stabilitě doporučujeme nepřekračovat maximum ServiceNow, které obvykle činí 10 000.

Ukázkový dotaz javascript

const axios = require('axios');
const fs = require('fs');
const { format, writeToStream } = require('@fast-csv/format');

// --- Configuration ---
const SN_INSTANCE = 'https://YOUR_INSTANCE.service-now.com';
const SN_USER = 'YOUR_API_USER';
const SN_PASSWORD = 'YOUR_API_PASSWORD';
const BATCH_SIZE = 1000;

// Define the date range for the extraction
const startDate = '2023-01-01 00:00:00';
const endDate = '2023-12-31 23:59:59';

const auth = { username: SN_USER, password: SN_PASSWORD };

// --- Helper Function for Paginated API Calls ---
async function fetchAllRecords(table, query, fields, processFunction) {
    let offset = 0;
    let hasMore = true;
    let allEvents = [];

    console.log(`Starting fetch for table: ${table}`);

    while (hasMore) {
        try {
            const response = await axios.get(`${SN_INSTANCE}/api/now/table/${table}`, {
                auth,
                params: {
                    sysparm_query: query,
                    sysparm_fields: fields,
                    sysparm_limit: BATCH_SIZE,
                    sysparm_offset: offset,
                    sysparm_display_value: 'true', // Get display values for reference fields
                    sysparm_exclude_reference_link: true
                }
            });

            const records = response.data.result;
            if (records.length > 0) {
                console.log(`Fetched ${records.length} records from ${table} with offset ${offset}`);
                const processedEvents = records.map(processFunction);
                allEvents.push(...processedEvents);
                offset += BATCH_SIZE;
            } else {
                hasMore = false;
            }
        } catch (error) {
            console.error(`Error fetching data from ${table}:`, error.response ? error.response.statusText : error.message);
            hasMore = false; // Stop on error
        }
    }
    return allEvents;
}

// --- Main Extraction Logic ---
async function extractServiceRequestData() {
    let finalEventLog = [];
    const now = new Date().toISOString();

    // 1. Service Request Created
    const createdEvents = await fetchAllRecords(
        'sc_req_item',
        `sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'number,sys_created_on,assigned_to,assignment_group,priority,state,cat_item.category,made_sla',
        (r) => ({
            ServiceRequestID: r.number,
            ActivityName: 'Service Request Created',
            EventTime: r.sys_created_on,
            SourceSystem: 'ServiceNow',
            LastDataUpdate: now,
            AssignedTo: r.assigned_to,
            AssignmentGroup: r.assignment_group,
            Priority: r.priority,
            State: r.state,
            Category: r['cat_item.category'],
            MadeSLA: r.made_sla
        })
    );
    finalEventLog.push(...createdEvents);

    // 2. Approval Requested
    const approvalRequestedEvents = await fetchAllRecords(
        'sysapproval_approver',
        `sysapproval.sys_class_name=sc_req_item^state=requested^sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'sysapproval,sys_created_on',
        (r) => ({
            ServiceRequestID: r.sysapproval,
            ActivityName: 'Approval Requested',
            EventTime: r.sys_created_on,
            SourceSystem: 'ServiceNow',
            LastDataUpdate: now,
            AssignedTo: null, AssignmentGroup: null, Priority: null, State: 'Pending Approval', Category: null, MadeSLA: null
        })
    );
    finalEventLog.push(...approvalRequestedEvents);

    // Function to process audit records
    const processAuditRecord = (activityName) => (r) => ({
        ServiceRequestID: r['documentkey.number'],
        ActivityName: activityName,
        EventTime: r.sys_created_on,
        SourceSystem: 'ServiceNow',
        LastDataUpdate: now,
        AssignedTo: activityName === 'Request Assigned to Agent' ? r.newvalue : null,
        AssignmentGroup: activityName === 'Request Assigned to Group' ? r.newvalue : null,
        Priority: null, 
        State: ['Service Request Resolved', 'Service Request Closed', 'Request Cancelled', 'Request Reopened', 'Information Requested from User', 'Information Provided by User'].includes(activityName) ? r.newvalue : null,
        Category: null, 
        MadeSLA: null
    });
    
    // 3. Request Approved
    const approvedEvents = await fetchAllRecords(
        'sys_audit',
        `tablename=sysapproval_approver^fieldname=state^newvalue=approved^sys_created_on>=${startDate}^sys_created_on<=${endDate}^documentkey.sysapproval.sys_class_name=sc_req_item`,
        'documentkey.sysapproval.number,sys_created_on',
        (r) => ({ ServiceRequestID: r['documentkey.sysapproval.number'], ActivityName: 'Request Approved', EventTime: r.sys_created_on, SourceSystem: 'ServiceNow', LastDataUpdate: now, AssignedTo: null, AssignmentGroup: null, Priority: null, State: 'Approved', Category: null, MadeSLA: null })
    );
    finalEventLog.push(...approvedEvents);

    // 4. Request Assigned to Group
    const assignedGroupEvents = await fetchAllRecords(
        'sys_audit',
        `tablename=sc_req_item^fieldname=assignment_group^sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'documentkey.number,sys_created_on,newvalue',
        processAuditRecord('Request Assigned to Group')
    );
    finalEventLog.push(...assignedGroupEvents);

    // 5. Request Assigned to Agent
    const assignedAgentEvents = await fetchAllRecords(
        'sys_audit',
        `tablename=sc_req_item^fieldname=assigned_to^sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'documentkey.number,sys_created_on,newvalue',
        processAuditRecord('Request Assigned to Agent')
    );
    finalEventLog.push(...assignedAgentEvents);

    // 6. Fulfillment Task Created
    const taskCreatedEvents = await fetchAllRecords(
        'sc_task',
        `request_item.sys_class_name=sc_req_item^sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'request_item.number,sys_created_on',
        (r) => ({ ServiceRequestID: r['request_item.number'], ActivityName: 'Fulfillment Task Created', EventTime: r.sys_created_on, SourceSystem: 'ServiceNow', LastDataUpdate: now, AssignedTo: null, AssignmentGroup: null, Priority: null, State: null, Category: null, MadeSLA: null })
    );
    finalEventLog.push(...taskCreatedEvents);

    // 7. Information Requested from User
    const infoRequestedEvents = await fetchAllRecords(
        'sys_audit',
        `tablename=sc_req_item^fieldname=state^newvalue=Awaiting User Info^sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'documentkey.number,sys_created_on,newvalue',
        processAuditRecord('Information Requested from User')
    );
    finalEventLog.push(...infoRequestedEvents);

    // 8. Information Provided by User
    const infoProvidedEvents = await fetchAllRecords(
        'sys_audit',
        `tablename=sc_req_item^fieldname=state^oldvalue=Awaiting User Info^sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'documentkey.number,sys_created_on,newvalue',
        processAuditRecord('Information Provided by User')
    );
    finalEventLog.push(...infoProvidedEvents);

    // 9. External Vendor Engaged (Note: requires a specific vendor group name)
    const vendorEngagedEvents = await fetchAllRecords(
        'sys_audit',
        `tablename=sc_req_item^fieldname=assignment_group^newvalue=[Your Vendor Assignment Group Name]^sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'documentkey.number,sys_created_on,newvalue',
        processAuditRecord('External Vendor Engaged')
    );
    finalEventLog.push(...vendorEngagedEvents);

    // 10. Request Reopened
    const reopenedEvents = await fetchAllRecords(
        'sys_audit',
        `tablename=sc_req_item^fieldname=state^oldvalue=Resolved^newvalue=Work in Progress^sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'documentkey.number,sys_created_on,newvalue',
        processAuditRecord('Request Reopened')
    );
    finalEventLog.push(...reopenedEvents);

    // 11. Service Request Resolved
    const resolvedEvents = await fetchAllRecords(
        'sys_audit',
        `tablename=sc_req_item^fieldname=state^newvalue=Resolved^sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'documentkey.number,sys_created_on,newvalue',
        processAuditRecord('Service Request Resolved')
    );
    finalEventLog.push(...resolvedEvents);

    // 12. Service Request Closed
    const closedEvents = await fetchAllRecords(
        'sys_audit',
        `tablename=sc_req_item^fieldname=state^newvalueINClosed Complete,Closed Incomplete,Closed Skipped^sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'documentkey.number,sys_created_on,newvalue',
        processAuditRecord('Service Request Closed')
    );
    finalEventLog.push(...closedEvents);

    // 13. Request Rejected
    const rejectedEvents = await fetchAllRecords(
        'sys_audit',
        `tablename=sysapproval_approver^fieldname=state^newvalue=rejected^sys_created_on>=${startDate}^sys_created_on<=${endDate}^documentkey.sysapproval.sys_class_name=sc_req_item`,
        'documentkey.sysapproval.number,sys_created_on',
        (r) => ({ ServiceRequestID: r['documentkey.sysapproval.number'], ActivityName: 'Request Rejected', EventTime: r.sys_created_on, SourceSystem: 'ServiceNow', LastDataUpdate: now, AssignedTo: null, AssignmentGroup: null, Priority: null, State: 'Rejected', Category: null, MadeSLA: null })
    );
    finalEventLog.push(...rejectedEvents);

    // 14. Request Cancelled
    const cancelledEvents = await fetchAllRecords(
        'sys_audit',
        `tablename=sc_req_item^fieldname=state^newvalue=Cancelled^sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'documentkey.number,sys_created_on,newvalue',
        processAuditRecord('Request Cancelled')
    );
    finalEventLog.push(...cancelledEvents);

    // --- Write to CSV ---
    const csvStream = format({ headers: true });
    const writableStream = fs.createWriteStream('servicenow_event_log.csv');

    writableStream.on('finish', () => {
        console.log('CSV file written successfully.');
    });

    csvStream.pipe(writableStream);
    finalEventLog.sort((a, b) => new Date(a.EventTime) - new Date(b.EventTime)); // Sort events chronologically
    finalEventLog.forEach(row => csvStream.write(row));
    csvStream.end();
}

extractServiceRequestData();

Chcete začít?

Využijte tuto šablonu jako výchozí bod pro process mining a najděte možnosti, jak zefektivnit řízení servisních požadavků. Začněte zlepšovat workflow ještě dnes, zkraťte dobu řešení a zvyšte spokojenost zákazníků.

Zpět na průvodce zlepšováním

Stáhnout šablonu

Zlepšete řízení servisních požadavků

Dosáhněte 70% automatizace a rychlejšího vyřizování servisních požadavků.

Spustit zkušební verzi zdarma

Platební kartu nepotřebujete. Nastavení zabere jen několik minut.

Šablona dat pro správu servisních požadavků

Šablona dat pro správu servisních požadavků

Atributy řízení servisních požadavků

Aktivity v řízení servisních požadavků

Návody k získání dat

Export sestav a seznamů ze ServiceNow do CSV/XLSX

Kroky

Konfigurace

Ukázkový dotaz config

Extrakce z Table API pomocí Pythonu a knihovny Requests

Kroky

Konfigurace

Ukázkový dotaz python

Extrakce dat přes REST Table API ServiceNow

Kroky

Konfigurace

Ukázkový dotaz javascript

Chcete začít?

Zlepšete řízení servisních požadavků