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

Šablona dat pro správu požadavků na služby

BMC Helix ITSM

Atributy správy požadavků na služby(20) Aktivity při správě požadavků na služby(14) Návody k získání dat(3)

Šablona dat pro správu požadavků na služby

Šablona přehledně uvádí základní datové atributy, které je třeba shromažďovat, a důležité aktivity, které je třeba sledovat v procesu správy požadavků na služby. Obsahuje také praktické pokyny, jak tato data efektivně získat z BMC Helix ITSM. Usnadněte si přípravu dat a začněte s process miningem na základě jasného postupu.

Doporučené atributy ke sběru
Důležité aktivity ke sledování
Pokyny k získání dat z BMC Helix ITSM

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 správy požadavků na služby

Tato datová pole jsou nezbytná pro vytvoření úplného záznamu událostí a podrobnou analýzu procesu správy požadavků na služby.

5 Povinné 6 Doporučené 9 Volitelné

	Název	Popis
	Aktivita ActivityName	Název konkrétní události nebo úkolu, který nastal v určitém okamžiku životního cyklu servisního požadavku.
Popis Tento atribut popisuje konkrétní krok nebo změnu stavu v procesu vyřizování servisního požadavku, například „Požadavek se kontroluje“, „Probíhá vyřizování“ nebo „Servisní požadavek vyřešen“. Každá činnost představuje jednu událost v průběhu požadavku. Analýza pořadí a četnosti činností je základem process mining. Umožňuje objevit mapy procesů, identifikovat úzká místa a analyzovat varianty procesu. Pro zlepšování procesů je důležité vědět, které činnosti probíhají, v jakém pořadí a jak často. Proč je to důležité Činnosti tvoří základní prvky mapy procesu. Jejich sledování umožňuje vizualizovat a analyzovat tok procesu a ukazuje, jak práce skutečně probíhá. Kde data získat Tento údaj se obvykle odvozuje ze změn polí „Status“ a „Status Reason“ ve formuláři „SRM:Request“ nebo z protokolů souvisejících aplikací pro vyřízení, například Incident nebo Work Order. Příklady Požadavek čeká na schváleníProbíhá vyřizováníServisní požadavek vyřešenServisní požadavek uzavřen
	Čas zahájení EventStartTime	Časové razítko označující, kdy konkrétní činnost nebo událost začala.
Popis Tento atribut zaznamenává přesné datum a čas zahájení činnosti. Každá událost v záznamu, od prvního odeslání až po závěrečné uzavření, musí mít čas zahájení, aby bylo možné určit chronologické pořadí procesu. Toto časové razítko je nezbytné pro veškerou časovou analýzu v process mining. Používá se k výpočtu doby průchodu procesem, trvání činností a čekání mezi kroky i ke kontrole plnění SLA. Pomáhá odhalit úzká místa a analyzovat výkonnost procesu v čase. Proč je to důležité Čas zahájení určuje chronologické pořadí událostí. To je nezbytné pro výpočet doby trvání procesu, odhalení prodlev a pochopení jeho časového průběhu. Kde data získat Odpovídá časovým razítkům v auditních protokolech nebo tabulkách historie stavů souvisejících s formulářem „SRM:Request“. U první události může jít například o pole „Submit Date“. Příklady 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:00Z
	ID servisního požadavku ServiceRequestId	Jedinečný identifikátor každého servisního požadavku, který slouží jako primární klíč pro sledování celého životního cyklu.
Popis ID servisního požadavku jednoznačně identifikuje každý jednotlivý požadavek odeslaný uživatelem nebo systémem. Propojuje všechny navazující události od prvního zaznamenání až po závěrečné uzavření a umožňuje analyzovat celý průběh každého požadavku. V process mining je toto ID nezbytné pro rekonstrukci posloupnosti činností v každém případu. Nástroj podle něj seskupí související události, například „Servisní požadavek odeslán“, „Požadavek přiřazen“ a „Servisní požadavek uzavřen“, do jedné instance procesu. Na tomto základě pak probíhá veškerá analýza procesu. Proč je to důležité Jde o základní identifikátor případu. Bez něj nelze sledovat celý průběh servisního požadavku, a není proto možné proces objevit ani analyzovat. Kde data získat Ve formuláři „SRM:Request“ v BMC Helix ITSM jde obvykle o pole „InstanceId“ nebo „Request Number“. Příklady SR000010572931SR000010572932SR000010572933
	Poslední aktualizace dat LastDataUpdate	Časové razítko poslední aktualizace dat pro tento proces ze zdrojového systému.
Popis Tento atribut uvádí datum a čas poslední extrakce dat z BMC Helix ITSM. Uživatelé tak vědí, jak aktuální data analyzují a jaké období analýza pokrývá. Jde o důležitý metadatový atribut každého dashboardu nebo analýzy process mining. Uživatelé díky němu poznají, zda se poznatky opírají o téměř aktuální data, nebo o historický snímek. To má vliv na platnost a relevanci závěrů. Proč je to důležité Uživatelé díky němu vědí, jak aktuální data jsou. To je důležité při rozhodování na základě nejnovějších dostupných informací o výkonnosti procesu. Kde data získat Toto časové razítko se vytváří a přidává při extrakci a načítání dat. Příklady 2024-05-21T08:00:00Z
	Zdrojový systém SourceSystem	Určuje systém, ze kterého byla data extrahována.
Popis Tento atribut určuje původ procesních dat. V tomto pohledu by měl mít pevně nastavenou hodnotu „BMC Helix ITSM“, která označuje, že všechna data o servisních požadavcích pocházejí z tohoto systému. V prostředí s více propojenými systémy je toto pole důležité pro pochopení původu dat a jejich rozdělení podle zdroje. Zajišťuje přehlednost a dohledatelnost, zejména při slučování dat z různých platforem. Proč je to důležité Informace o původu dat jsou důležité pro správu dat, dohledatelnost a řešení problémů v prostředí s více systémy. Kde data získat Jde o statickou hodnotu přidanou při extrakci a transformaci dat, nikoli o pole přímo v BMC Helix ITSM. Příklady BMC Helix ITSM
	Čas ukončení EventEndTime	Časové razítko označující, kdy byla konkrétní činnost nebo událost dokončena.
Popis Čas ukončení označuje konec činnosti. Mnohé činnosti v systémech ITSM představují okamžitou změnu stavu, jiné však mají měřitelnou dobu trvání. Čas ukončení umožňuje tuto dobu přesně vypočítat. Při analýze se čas ukončení používá spolu s časem zahájení k výpočtu doby zpracování jednotlivých činností. Pomáhá určit, které konkrétní úkoly, nejen čekání mezi nimi, zabírají v procesu nejvíce času. Proč je to důležité Umožňuje vypočítat dobu zpracování činností. To je důležité pro odhalení neefektivních kroků a zjištění, čemu pracovníci věnují svůj čas. Kde data získat Tento údaj lze odvodit. Čas ukončení jedné činnosti často odpovídá času zahájení následující činnosti v témže případu. U poslední činnosti jde o čas vyřešení nebo uzavření. Příklady 2023-10-26T10:05:15Z2023-10-26T11:45:10Z2023-10-28T09:00:00Z
	Priorita Priority	Úroveň priority přiřazená servisnímu požadavku, která vyjadřuje jeho dopad na provoz a naléhavost.
Popis Priorita určuje pořadí a rychlost vyřizování požadavků. Mezi běžné hodnoty patří „Kritická“, „Vysoká“, „Střední“ a „Nízká“. Při jejím stanovení se obvykle zohledňuje dopad požadavku na provoz a jeho naléhavost. Analýza podle priority ukazuje, zda se požadavky s vysokou prioritou vyřizují rychleji než požadavky s nízkou prioritou. Jde o důležitou dimenzi dashboardů doby vyřízení a plnění SLA. Pomáhá zajistit, aby byly zdroje přidělovány podle nejdůležitějších potřeb organizace. Proč je to důležité Pomáhá posoudit, zda proces správně určuje pořadí práce a dodržuje očekávané úrovně služeb u požadavků s různým dopadem na provoz. Kde data získat Jde o pole „Priority“ ve formuláři „SRM:Request“. Příklady KritickáVysokáStředníNízká
	Přiřazený pracovník AssignedAgent	Uživatel, který je aktuálně pověřen vyřízením servisního požadavku.
Popis Tento atribut určuje konkrétního pracovníka IT nebo podpory, který v daném okamžiku odpovídá za požadavek. Změny tohoto pole během životního cyklu požadavku označují předání nebo změnu přiřazení. Atribut je důležitý pro analýzu výkonu pracovníků a jejich vytížení. Umožňuje sledovat, kolik požadavků každý pracovník vyřizuje, jaká je jejich průměrná doba vyřízení a jak často se mění přiřazení. Tyto údaje pomáhají při správě zdrojů a odhalování potřeb školení. Proč je to důležité Sledování přiřazeného pracovníka je důležité pro analýzu předávání požadavků, měření individuálního výkonu a pochopení rozložení práce v týmu podpory. Kde data získat Odpovídá poli „Assignee“ nebo „Assigned To“ v záznamu pro vyřízení, například Work Order nebo Incident, který souvisí se servisním požadavkem. Příklady Bob SmithAlice JohnsonCharlie Brown
	Přiřazený tým AssignedTeam	Skupina podpory nebo tým, kterému je servisní požadavek aktuálně přiřazen.
Popis Tento atribut označuje funkční skupinu odpovědnou za vyřízení požadavku, například „Podpora uživatelů“, „Síťový tým“ nebo „Správa databází“. Změna hodnoty znamená předání odpovědnosti mezi týmy. Analýza podle přiřazeného týmu pomáhá odhalit úzká místa na úrovni týmů, sledovat předávání práce mezi týmy a porovnávat efektivitu jednotlivých skupin podpory. Atribut je důležitý pro dashboardy Přepracování a přeřazení požadavků a Efektivita třídění požadavků. Ukazuje, jak se práce v organizaci předává. Proč je to důležité Umožňuje analyzovat tok procesu mezi různými funkčními skupinami, odhalovat neefektivní směrování a měřit výkonnost jednotlivých týmů. Kde data získat Odpovídá poli „Assigned Group“ v záznamu o vyřízení, například Work Order nebo Incident, který souvisí s požadavkem na službu. Příklady Servisní podporaPodpora infrastrukturyPodpora aplikací, 2. úroveň
	Stav požadavku RequestStatus	Stav servisního požadavku v okamžiku události, například „In Progress“, „Pending“ nebo „Closed“.
Popis Tento atribut zachycuje stav servisního požadavku v různých fázích jeho životního cyklu. Poskytuje kontext ke každé činnosti a často se z něj odvozuje samotný atribut „Činnost“. Analýza podle stavu ukazuje, kolik času požadavky stráví v určitých stavech, například „Pending Customer“ nebo „Waiting for Approval“. Pomáhá tak odhalit úzká místa a prodlevy způsobené externími závislostmi nebo interními frontami. Přímo podporuje dashboard pro identifikaci úzkých míst. Proč je to důležité Poskytuje přehled o stavu požadavku a umožňuje porovnat dobu strávenou čekáním s dobou aktivního zpracování. To je důležité pro odhalení úzkých míst. Kde data získat Jde o pole „Status“ ve formuláři „SRM:Request“. Historické hodnoty najdete v auditním protokolu. Příklady PlánováníProbíháČekáVyřešenoUzavřeno
	Typ služby ServiceType	Kategorie nebo typ služby, o kterou uživatel žádá.
Popis Typ služby určuje povahu požadavku, například „Žádost o nový software“, „Obnovení hesla“ nebo „Nástup nového zaměstnance“. Jde o základní dimenzi pro filtrování a členění procesních dat. Při analýze procesů se tento atribut používá k porovnání výkonnosti různých typů požadavků. Pomáhá odpovědět například na otázky: „Které typy služeb se vyřizují nejdéle?“ nebo „U kterých typů se nejčastěji opakují kroky?“ Je důležitý pro dashboardy doby vyřízení a plnění SLA. Proč je to důležité Umožňuje rozdělit servisní požadavky do skupin, porovnat průběh procesů, odhalit problémy typické pro určité služby a lépe zacílit zlepšování. Kde data získat Tento údaj se často nachází v poli „Title“ nebo v poli pro kategorizaci ve formuláři „SRM:Request“. Odvozuje se od služby vybrané v katalogu. Příklady Požadavek na nový hardwarePožadavek na přístup k softwaruNastavení přístupu k VPN
	Byl požadavek eskalován IsEscalated	Logická hodnota označující, zda byl požadavek na službu eskalován.
Popis Tento příznak má hodnotu true, pokud byl požadavek na službu eskalován na jinou funkční nebo hierarchickou úroveň. K eskalaci obvykle dochází, když se požadavek nevyřizuje podle očekávání, hrozí nedodržení SLA nebo je ke schválení či provedení potřeba vyšší pravomoc. Atribut podporuje dashboard Analýza efektivity eskalací požadavků. Umožňuje filtrovat a analyzovat průběh eskalovaných požadavků, zjistit, co eskalaci spouští, jak dlouho trvá následné vyřízení a jak účinný je proces eskalace. Proč je to důležité Umožňuje oddělit a analyzovat požadavky, které vyžadovaly eskalaci. Pomáhá tak odhalit slabá místa standardního procesu nebo příčiny složitých problémů. Kde data získat Tento údaj obvykle není uložen v jediném poli. Odvozuje se z konkrétních aktivit souvisejících s eskalací v auditním protokolu nebo ze změn priority či přiřazení podle pravidel eskalace. Příklady truefalse
	Byla překročena lhůta SLA IsSlaBreached	Logická hodnota označující, zda byl požadavek na službu vyřízen po cílovém termínu SLA.
Popis Tento vypočítaný příznak má hodnotu true, pokud je časové razítko konečného vyřízení požadavku na službu pozdější než jeho „Cílový termín SLA“. Pro každý požadavek tak jednoduše ukazuje, zda bylo SLA splněno. Atribut je nezbytný pro dashboard Přehled plnění SLA a KPI Míra dodržení SLA. Umožňuje snadno vypočítat celkovou míru plnění a filtrovat požadavky s překročenou lhůtou. Porovnáním jejich průběhu s požadavky, u kterých bylo SLA dodrženo, lze hledat příčiny nedodržení. Proč je to důležité Zjednodušuje analýzu plnění SLA. Porovnání časových razítek převádí na jednoduchou logickou hodnotu, podle které lze snadno měřit a zobrazovat míru plnění. Kde data získat Jde o vypočítané pole. Logika: IF 'Resolution Timestamp' > 'SlaTargetDate' THEN true ELSE false. Příklady truefalse
	Bylo nutné přepracování IsRework	Logická hodnota označující, zda se požadavek na službu musel přepracovat, například vrátit do předchozí fáze.
Popis Tento příznak označuje požadavky na službu, u kterých se proces opakoval nebo vyžadoval přepracování. Například návrat požadavku z fáze „Probíhá vyřízení“ do fáze „Kontrola požadavku“ se považuje za přepracování. Přesná definice závisí na logice daného procesu. Atribut přímo podporuje dashboard Analýza přepracování a přeřazení požadavků a KPI Míra přepracování požadavků. Umožňuje měřit četnost přepracování a analyzovat jeho běžné příčiny, například nesprávné počáteční posouzení nebo neúplné informace, které vedou k neefektivnímu procesu. Proč je to důležité Označuje případy, které se odchylují od obvyklého průběhu, a pomáhá tak měřit neefektivitu procesu a hledat příčiny opakovaných kroků a práce navíc. Kde data získat Jde o vypočítaný atribut odvozený z pořadí aktivit v záznamu událostí. Je třeba nastavit logiku, která rozpozná návrat k předchozím krokům procesu. Příklady truefalse
	Cílový termín SLA SlaTargetDate	Datum a čas, do kterého má být požadavek na službu podle dohody o úrovni služeb (SLA) vyřízen.
Popis Cílový termín SLA je vypočítané časové razítko, které určuje lhůtu pro vyřízení požadavku na službu. Vychází z pravidel dohody o úrovni služeb, která často zohledňují například prioritu a typ požadavku. Tento atribut je základem dashboardu Přehled plnění SLA. Slouží jako měřítko pro porovnání se skutečnou dobou vyřízení. Porovnáním hodnoty „EventEndTime“ u poslední aktivity vyřízení s cílovým termínem lze zjistit, zda byl závazek vůči zákazníkovi splněn. Proč je to důležité Jde o hlavní měřítko výkonnosti služeb vzhledem k přijatým závazkům. Je proto nezbytné pro sledování a vykazování plnění SLA. Kde data získat Toto datum vypočítává a ukládá modul Service Level Management (SLM). Najdete ho v souvisejících formulářích SLM propojených s požadavkem na službu. Příklady 2023-10-28T17:00:00Z2023-11-01T09:00:00Z2023-10-27T12:00:00Z
	Kanál podání SubmissionChannel	Způsob nebo kanál, kterým byl požadavek na službu podán.
Popis Tento atribut zaznamenává, jak byl požadavek na službu podán, například přes samoobslužný portál, e-mailem, telefonicky na servisní podporu nebo automatickým systémovým upozorněním. Různé kanály mohou vést k odlišným variantám procesu a době vyřízení. Analýza procesu podle kanálu podání může odhalit neefektivní postupy nebo osvědčené způsoby příjmu požadavků. Požadavky zadané přes samoobslužný portál se například mohou vyřídit rychleji díky kvalitnějším údajům při zadání. U požadavků z e-mailu může být naopak potřeba více ručního třídění. Proč je to důležité Pomáhá zjistit, jak způsob podání ovlivňuje efektivitu procesu, kvalitu dat a celkovou dobu vyřízení. Díky tomu můžete cíleně zlepšovat konkrétní kanály. Kde data získat Tuto hodnotu lze často odvodit z polí, jako jsou „Client Type“ nebo „Reported Source“, ve formuláři „SRM:Request“ nebo v souvisejících požadavcích na vyřízení. Příklady Samoobslužný portálE-mailTelefonVygenerováno systémem
	Kategorie řešení ResolutionCategory	Klasifikace řešení použitého k vyřízení požadavku.
Popis Tento atribut strukturovaně klasifikuje způsob vyřízení požadavku, například „Oprava softwaru“, „Školení uživatele“ nebo „Oprava dat“. Na rozdíl od obecného kódu uzavření popisuje povahu řešení. Atribut je důležitý pro dashboard Přesnost kategorie řešení, kde lze kategorii porovnat s původním typem služby a ověřit jejich soulad. Analýza kategorií řešení pomáhá odhalovat opakující se problémy a plánovat jejich prevenci. Pokud se například mnoho požadavků řeší školením uživatelů, může být vhodné školení nabídnout proaktivně. Proč je to důležité Ukazuje, jaká řešení se používají, a pomáhá odhalit opakující se problémy i příležitosti k jejich prevenci nebo ke školení uživatelů. Kde data získat Tento údaj je součástí polí pro provozní a produktovou klasifikaci v požadavku na vyřízení. Často se označuje jako „Resolution Category“. Příklady Správa účtůPorucha hardwaruAktualizace softwaruInformace dodány
	Kód uzavření CloseCode	Kód označující konečný výsledek nebo důvod uzavření požadavku na službu.
Popis Kód uzavření poskytuje jednotný způsob klasifikace výsledku vyřízení požadavku na službu. Příklady: „Vyřešeno servisní podporou“, „Zrušeno uživatelem“ nebo „Duplicitní požadavek“. Analýza kódů uzavření pomáhá porozumět obvyklým výsledkům požadavků. Může upozornit například na vysoký počet požadavků zrušených uživateli, což může znamenat, že proces trvá příliš dlouho. Velký počet duplicit může zase poukazovat na problém v systému nebo komunikaci. Tento atribut podporuje dashboard Přesnost kategorie řešení. Proč je to důležité Poskytuje strukturované údaje o výsledcích požadavků. Díky nim lze analyzovat účinnost řešení i důvody nedokončení nebo zrušení. Kde data získat Tento údaj se obvykle nachází v poli „Resolution“ nebo „Closure Code“ v požadavku na vyřízení, který souvisí s požadavkem na službu. Příklady Úspěšně vyřízenoZrušeno uživatelemJiž není potřebaAutomatické vyřešení
	Oddělení žadatele RequestorDepartment	Obchodní oddělení nebo útvar uživatele, který požadavek podal.
Popis Tento atribut označuje organizační oddělení osoby, která žádá o službu, například „Finance“, „Lidské zdroje“ nebo „IT“. Údaj se obvykle přebírá z uživatelského profilu v systému. Analýza procesu podle oddělení pomáhá odhalit specifické potřeby a vzorce požadavků jednotlivých oddělení i možnosti cíleného školení nebo zlepšení služeb. Můžete například zjistit, zda oddělení financí čeká na vyřízení požadavků déle. Proč je to důležité Umožňuje analyzovat využívání služeb a výkonnost procesu podle obchodních útvarů a odhalit problémy nebo trendy specifické pro jednotlivá oddělení. Kde data získat Tento údaj se obvykle získává z profilu uživatele uvedeného v poli „Requested For“ ve formuláři „SRM:Request“. Příklady FinanceProdejLidské zdrojeInformační technologie
	Počet předání HandoffCount	Celkový počet případů, kdy byl požadavek na službu přeřazen mezi různými pracovníky nebo týmy.
Popis Tato vypočítaná metrika počítá, kolikrát se u jednoho požadavku na službu změnila hodnota „AssignedAgent“ nebo „AssignedTeam“. Vysoký počet předání může znamenat roztříštěný proces, nízkou míru vyřešení při prvním kontaktu nebo neefektivní směrování. Atribut je základem KPI Průměrný počet předání mezi pracovníky na požadavek a používá se v dashboardu Přepracování a přeřazení požadavků. Analýza případů s vysokým počtem předání může ukázat, kde zlepšit třídění požadavků, zajistit lepší školení nebo zjednodušit vyřizování. Tím lze zkrátit prodlevy a zvýšit spokojenost zákazníků. Proč je to důležité Měří roztříštěnost procesu a náklady na komunikaci. Vysoký počet předání často souvisí s delší dobou vyřízení a nižší efektivitou procesu. Kde data získat Jde o vypočítanou metriku. Pro každé jedinečné ID požadavku na službu se spočítají různé hodnoty atributu „AssignedAgent“ nebo „AssignedTeam“. Příklady 0135

Povinné Doporučené Volitelné

Aktivity při správě požadavků na služby

Tyto důležité kroky procesu a milníky zaznamenávejte do záznamu událostí. Zajistíte tak přesné zjištění a vizualizaci procesu.

6 Doporučené 8 Volitelné

	Aktivita	Popis
	Požadavek přiřazen	Servisní požadavek byl přiřazen konkrétnímu pracovníkovi nebo týmu odpovědnému za jeho vyřízení. Tím končí fáze třídění.
Proč je to důležité Tento milník je důležitý pro měření doby třídění a analýzu vytížení pracovníků. Časté změny přiřazení mohou ukazovat na problémy se směrováním požadavků nebo nedostatek potřebných dovedností. Kde data získat Událost lze zaznamenat přímo z auditního protokolu polí „Assigned Group“ nebo „Assignee“ ve formuláři SRM:Request nebo v souvisejících formulářích pro vyřízení, například WOI:WorkOrder. Zachycení Časové razítko z auditního protokolu, které ukazuje, kdy bylo do pole „Assignee“ poprvé zadáno neprázdné pole. Typ události explicit
	Probíhá vyřizování	Přiřazený pracovník nebo tým začal na vyřízení servisního požadavku aktivně pracovat. Požadavek tak přešel z fronty do aktivního zpracování.
Proč je to důležité Tímto okamžikem začíná práce na vyřízení, která přináší hodnotu. Analýza doby strávené v této fázi pomáhá porozumět produktivitě zdrojů a náročnosti vyřízení. Kde data získat Událost se odvozuje ze změny stavu ve formuláři SRM:Request na „In Progress“. Zachycení Časové razítko aktualizace, při které se pole „Status“ ve formuláři SRM:Request změní na „In Progress“. Typ události inferred
	Servisní požadavek odeslán	Tato činnost označuje vytvoření a odeslání nového servisního požadavku uživatelem. Zaznamená se při vytvoření nového záznamu ve formuláři SRM:Request s počátečním stavem, obvykle „Submitted“.
Proč je to důležité Jde o začátek každého případu servisního požadavku. Tento bod je nezbytný pro měření celkové doby vyřízení a analýzu počtu přijatých požadavků. Kde data získat Událost se odvozuje z časového razítka vytvoření a počátečního stavu záznamu ve formuláři SRM:Request, například „Submitted“. Zachycení Určete časové razítko vytvoření nového servisního požadavku podle jeho ID ve formuláři SRM:Request, pokud je jeho stav „Submitted“. Typ události inferred
	Servisní požadavek uzavřen	Servisní požadavek je formálně uzavřen a převeden do archivního stavu pouze pro čtení. K tomu dochází po vyřešení a uplynutí případné lhůty pro potvrzení.
Proč je to důležité Tato činnost představuje definitivní konec procesu. Doba mezi stavy „Resolved“ a „Closed“ může odhalit neefektivitu při uzavírání požadavků. Kde data získat Událost se odvozuje z poslední změny stavu ve formuláři SRM:Request na „Closed“. Zachycení Časové razítko aktualizace, při které se pole „Status“ ve formuláři SRM:Request změní na „Closed“. Typ události inferred
	Servisní požadavek vyřešen	Servisní požadavek byl vyřízen a žadatel byl o výsledku informován. Požadavek čeká na závěrečné potvrzení, případně se po uplynutí stanovené doby automaticky uzavře.
Proč je to důležité Tento důležitý milník označuje konec cyklu poskytování služby. Je hlavním bodem pro měření doby vyřízení a plnění SLA. Kde data získat Událost se odvozuje ze změny stavu ve formuláři SRM:Request na „Resolved“ nebo „Completed“. Zachycení Časové razítko aktualizace, při které se pole „Status“ ve formuláři SRM:Request změní na „Resolved“ nebo „Completed“. Typ události inferred
	Servisní požadavek zrušen	Žadatel nebo servisní oddělení stáhlo servisní požadavek před dokončením jeho vyřízení. Jde o konečný stav požadavku.
Proč je to důležité Sledování zrušených požadavků pomáhá odhalit opakující se příčiny, například chybně zadané požadavky nebo služby, které už nejsou potřeba. Tyto poznatky mohou pomoci zlepšit katalog služeb. Kde data získat Událost se odvozuje ze změny stavu ve formuláři SRM:Request na „Canceled“. Zachycení Časové razítko aktualizace, při které se pole „Status“ ve formuláři SRM:Request změní na „Canceled“. Typ události inferred
	Od uživatele se vyžadují další informace	Pracovník odpovědný za vyřízení potřebuje od žadatele další informace, aby mohl pokračovat. Požadavek se obvykle převede do stavu „Pending“.
Proč je to důležité Tato činnost je důležitá pro výpočet „Doby čekání na externí informace“ a zjištění, jak často se požadavky pozastaví kvůli neúplným informacím. Kde data získat Událost se odvozuje ze změny stavu ve formuláři SRM:Request na „Pending“ s důvodem, jako je „Customer Hold“ nebo „Awaiting Information“. Zachycení Časové razítko změny stavu na „Pending“ spolu s konkrétním důvodem stavu. Typ události inferred
	Požadavek čeká na schválení	Servisní požadavek byl předán určenému schvalovateli nebo skupině schvalovatelů a čeká na rozhodnutí. Vyřizování může začít až po schválení. Tento krok se často týká požadavků na nákup nebo přístupová oprávnění.
Proč je to důležité Tato činnost odděluje prodlevy spojené se schvalováním. Můžete tak analyzovat dobu schvalování a odhalit úzká místa ve schvalovacím řetězci. Kde data získat Událost se odvozuje ze změny stavu ve formuláři SRM:Request na hodnotu jako „Waiting Approval“. Zachycení Časové razítko aktualizace, při které se pole „Status“ ve formuláři SRM:Request změní na „Waiting Approval“. Typ události inferred
	Požadavek schválen	Oprávněná osoba formálně schválila servisní požadavek a proces vyřízení může pokračovat. Této události obvykle předchází stav „Waiting for Approval“.
Proč je to důležité Tato událost označuje konec dílčího procesu schvalování. Je důležitým milníkem pro měření délky schvalování a jeho vlivu na celkovou dobu vyřízení. Kde data získat Událost se odvozuje ze změny stavu ve formuláři SRM:Request z „Waiting Approval“ na následující stav, například „Planning“ nebo „In Progress“. Samotné rozhodnutí o schválení se zaznamenává v souvisejících schvalovacích formulářích. Zachycení Časové razítko změny stavu z „Waiting Approval“ po kladném rozhodnutí o schválení. Typ události inferred
	Požadavek se kontroluje	Servisní oddělení provádí prvotní kontrolu a třídění požadavku, aby určilo jeho povahu, prioritu a tým, který jej vyřídí. Tato fáze se obvykle zaznamená změnou stavu požadavku.
Proč je to důležité Sledováním této činnosti změříte efektivitu třídění a odhalíte prodlevy mezi odesláním požadavku a jeho přiřazením. To je důležité pro KPI „Průměrná doba třídění“. Kde data získat Událost se odvozuje ze změny stavu ve formuláři SRM:Request na hodnotu jako „In Review“ nebo „Planning“. Zachycení Časové razítko aktualizace, při které se pole „Status“ ve formuláři SRM:Request změní na „In Review“. Typ události inferred
	Požadavek zamítnut	Servisní požadavek byl zamítnut během schvalování. Jde o konečný stav, který zastaví proces ještě před zahájením vyřizování.
Proč je to důležité Analýza zamítnutých požadavků může odhalit problémy se zdůvodněním požadavků, kritérii způsobilosti nebo pravidly schvalování. Kde data získat Událost se odvozuje ze změny stavu ve formuláři SRM:Request na „Rejected“. Zachycení Časové razítko aktualizace, při které se pole „Status“ ve formuláři SRM:Request změní na „Rejected“. Typ události inferred
	Řešení zavedeno	Pracovník dokončil technické práce potřebné k vyřízení servisního požadavku. Požadavek nyní čeká na potvrzení uživatelem, než bude formálně vyřešen.
Proč je to důležité Tato činnost odděluje dokončení technických prací od formálního vyřešení požadavku. Pomáhá odhalit prodlevy mezi dokončením práce a potvrzením uživatele. Kde data získat Událost lze odvodit ze změny stavu v navazujícím záznamu pro vyřízení, například ze změny stavu Work Order na „Completed“, ke které dojde před označením nadřazeného SRM:Request jako „Resolved“. Zachycení Časové razítko, kdy je navazující záznam, například Work Order nebo Incident, propojený se SRM:Request označen jako dokončený. Typ události inferred
	Uživatel potvrdil vyřešení	Žadatel výslovně potvrdil, že služba byla poskytnuta k jeho spokojenosti a požadavek je vyřešen. Toto potvrzení často spustí závěrečné uzavření požadavku.
Proč je to důležité Tato událost jasně ukazuje spokojenost zákazníka a formálně uzavírá interakci. Odlišuje vyřešení požadavku od přijetí výsledku zákazníkem. Kde data získat Událost může být zaznamenána v pracovních protokolech SRM:Request nebo v poznámkách k aktivitám, pokud uživatel potvrdí vyřešení přes portál nebo e-mail. Nemusí mít vždy podobu samostatného stavu. Zachycení Prohledejte pracovní protokoly (SRM:WorkInfo) a vyhledejte záznamy o potvrzení uživatelem nebo dokončení průzkumu. Typ události explicit
	Vyřizování požadavku pokračuje	Servisní požadavek byl převeden ze stavu čekání nebo pozastavení, obvykle poté, co uživatel dodal požadované informace. Pracovník odpovědný za vyřízení pokračuje v práci na požadavku.
Proč je to důležité Tímto okamžikem končí čekání. Můžete přesně měřit dobu čekání na externí informace a její vliv na plnění SLA. Kde data získat Událost se odvozuje ze změny stavu SRM:Request z „Pending“ zpět na „In Progress“. Zachycení Časové razítko aktualizace, při které se pole „Status“ ve formuláři SRM:Request změní z „Pending“ na „In Progress“. Typ události inferred

Doporučené Volitelné

Návody k získání dat

Jak získat data z BMC Helix ITSM

Kroky

Otevřete Smart Reporting: Přihlaste se do prostředí BMC Helix ITSM. Přejděte do části pro tvorbu přehledů a spusťte Smart Reporting. Podle verze se tato část může jmenovat „Reports“ nebo „Smart Reporting“.
Vytvořte nový přehled: V rozhraní Smart Reporting vyberte možnost vytvořit nový přehled. Jako typ zvolte „Report“.
Vyberte zdroj dat a pohled: Zobrazí se výzva k výběru zdroje dat. Zvolte hlavní zdroj dat AR System. Jako pohled vyhledejte a vyberte Service Request, který obvykle vychází z formuláře SRM:Request.
Přidejte další formuláře (spojení): Chcete-li zachytit celý životní cyklus, spojte hlavní formulář SRM:Request se souvisejícími formuláři. Na kartě „Data“ přidejte tato spojení:
- SRM:WorkInfo (podle SR ID+ = Request Number) pro podrobnosti o vyřizování a pracovních záznamech.
- AP:Signature (podle Request = SRInstanceID) pro události související se schvalováním, například schválení a zamítnutí. Možná bude nutné vytvořit vlastní spojení.
Určete sloupce přehledu: Přetáhněte požadovaná pole ze spojených formulářů do oblasti „Columns“. Z formuláře SRM:Request přidejte například Request Number, Submit Date, Status, Description, Priority, Assigned To a Assigned Group a také související pole ze spojených formulářů.
Vytvořte vypočítaná pole pro aktivity: Základem tohoto postupu je vytvořit sadu vypočítaných polí, která budou představovat časová razítka jednotlivých aktivit. Na kartě „Data“ vytvořte pro každou aktivitu nové vypočítané pole. Například:
- Čas zadání: Použijte přímo pole Submit Date.
- Čas schválení: Použijte pole Signature Date z formuláře AP:Signature.
- Čas zahájení práce: Použijte MIN(Submit Date) z formuláře SRM:WorkInfo, seskupené podle čísla požadavku.
Připravte přehled pro spojení záznamů: Smart Reporting nemá jednoduché tlačítko „UNION ALL“ jako SQL. Místo toho vytvořte jeden přehled a pomocí pokročilých funkcí nebo poddotazů data převeďte. Běžným postupem je vytvořit několik vypočítaných sloupců, po jednom pro časové razítko každé aktivity. Při závěrečném exportu pak tyto sloupce převedete na samostatné řádky pro jednotlivé aktivity.
Nastavte filtry: Omezte rozsah dat a zrychlete zpracování pomocí filtrů. Minimálně filtrujte podle pole Submit Date ve formuláři SRM:Request a vyberte konkrétní období. Pokud používáte prostředí s více tenanty, přidejte také filtr „Company“.
Spusťte přehled a zkontrolujte data: Spusťte přehled a ověřte, že se data načítají správně. Zkontrolujte spojení, vyplněné sloupce a to, zda vypočítaná pole vracejí očekávaná časová razítka.
Exportujte přehled: Po ověření přehled exportujte. Zvolte formát CSV nebo Microsoft Excel, protože data z těchto formátů lze snadno připravit pro import do nástrojů process mining.
Upravte data po exportu: Po exportu převeďte data ze širokého formátu (jeden řádek na servisní požadavek a mnoho sloupců s časovými razítky) do dlouhého formátu (jeden řádek na aktivitu). Pomocí skriptu, například v Pythonu nebo PowerShellu, nebo nástroje Excel Power Query převeďte sloupce s časovými razítky na dva sloupce: ActivityName a EventStartTime. Tento krok je nezbytný pro vytvoření požadované struktury záznamu událostí.

Konfigurace

Předpoklady: Potřebujete uživatelský účet s oprávněním vytvářet a spouštět přehledy v BMC Helix ITSM, konkrétně v nástroji Smart Reporting. Dále potřebujete oprávnění ke čtení dat z formulářů SRM:Request, SRM:WorkInfo a AP:Signature.
Hlavní formuláře: Přehled vytvoříte spojením těchto základních formulářů:
- SRM:Request: Hlavní formulář s podrobnostmi o servisním požadavku.
- SRM:WorkInfo: Obsahuje pracovní záznamy, z nichž lze odvodit aktivity při vyřizování požadavku.
- AP:Signature: Obsahuje záznamy o schválení, které jsou nezbytné pro sledování souvisejících aktivit.
Filtr období: Vždy nastavte filtr období pro pole SRM:Request.Submit Date. Doporučujeme vybrat data za 3 až 6 měsíců. Získáte tak reprezentativní vzorek a zároveň zachováte dobrou rychlost zpracování přehledu.
Důležité filtry: Kromě období filtrujte také podle pole Company, abyste oddělili data konkrétní obchodní jednotky. Můžete také vyloučit typy požadavků nebo stavy, které pro analýzu procesu nejsou relevantní, například „Draft“.
Výkon: Přehledy, které spojují více formulářů za delší období, se mohou generovat pomalu. U velkých objemů dat doporučujeme naplánovat jejich spuštění mimo špičku. Pokud dochází k překročení časového limitu, rozdělte extrakci na menší měsíční části.

Ukázkový dotaz sql

/*
This is a conceptual SQL query representing the logic you would build in the BMC Helix ITSM Smart Reporting UI.
Smart Reporting uses a graphical interface, so you will create this structure by joining forms and creating calculated fields that correspond to each SELECT block below.
The final step of unpivoting data from columns to rows must be done after exporting the report.
*/

-- 1. Service Request Submitted
SELECT
  'Service Request Submitted' AS "ActivityName",
  req."Request Number" AS "ServiceRequestId",
  req."Submit Date" AS "EventStartTime",
  NULL AS "EventEndTime",
  req."Status" AS "RequestStatus",
  req."Title" AS "ServiceType", -- Or another field representing the service
  req."Priority" AS "Priority",
  req."ASG_Assignee" AS "AssignedAgent",
  req."Assigned Group" AS "AssignedTeam",
  'BMC Helix ITSM' AS "SourceSystem",
  GETDATE() AS "LastDataUpdate"
FROM "SRM:Request" AS req
WHERE req."Submit Date" BETWEEN '[START_DATE]' AND '[END_DATE]'

UNION ALL

-- 2, 3, 4, 14: Approval Steps (Waiting, Approved, Rejected)
SELECT
  CASE sig."Outcome" WHEN 'Approved' THEN 'Request Approved' WHEN 'Rejected' THEN 'Request Rejected' ELSE 'Request Waiting for Approval' END AS "ActivityName",
  req."Request Number" AS "ServiceRequestId",
  sig."Signature Date" AS "EventStartTime",
  NULL AS "EventEndTime",
  req."Status" AS "RequestStatus",
  req."Title" AS "ServiceType",
  req."Priority" AS "Priority",
  req."ASG_Assignee" AS "AssignedAgent",
  req."Assigned Group" AS "AssignedTeam",
  'BMC Helix ITSM' AS "SourceSystem",
  GETDATE() AS "LastDataUpdate"
FROM "SRM:Request" AS req
JOIN "AP:Signature" AS sig ON req."InstanceId" = sig."Request"
WHERE req."Submit Date" BETWEEN '[START_DATE]' AND '[END_DATE]'

UNION ALL

-- 5. Request Assigned (based on first Work Info entry)
SELECT
  'Request Assigned' AS "ActivityName",
  wi."Request Number" AS "ServiceRequestId",
  MIN(wi."Submit Date") AS "EventStartTime",
  NULL AS "EventEndTime",
  req."Status" AS "RequestStatus",
  req."Title" AS "ServiceType",
  req."Priority" AS "Priority",
  req."ASG_Assignee" AS "AssignedAgent",
  req."Assigned Group" AS "AssignedTeam",
  'BMC Helix ITSM' AS "SourceSystem",
  GETDATE() AS "LastDataUpdate"
FROM "SRM:WorkInfo" AS wi
JOIN "SRM:Request" AS req ON wi."Request Number" = req."Request Number"
WHERE req."Submit Date" BETWEEN '[START_DATE]' AND '[END_DATE]'
GROUP BY wi."Request Number", req."Status", req."Title", req."Priority", req."ASG_Assignee", req."Assigned Group"

UNION ALL

-- 6, 7, 8, 9: Fulfillment Steps from Work Logs
SELECT
  CASE 
    WHEN wi."Work Log Type" = 'General Information' AND wi.Description LIKE '%Fulfillment In Progress%' THEN 'Fulfillment In Progress'
    WHEN wi."Work Log Type" = 'Customer Communication' AND wi.Description LIKE '%Information Requested%' THEN 'Information Requested from User'
    WHEN wi."Work Log Type" = 'General Information' AND wi.Description LIKE '%Request Resumed%' THEN 'Request Resumed'
    WHEN wi."Work Log Type" = 'Resolution Communications' THEN 'Solution Implemented'
    ELSE NULL 
  END AS "ActivityName",
  wi."Request Number" AS "ServiceRequestId",
  wi."Submit Date" AS "EventStartTime",
  NULL AS "EventEndTime",
  req."Status" AS "RequestStatus",
  req."Title" AS "ServiceType",
  req."Priority" AS "Priority",
  req."ASG_Assignee" AS "AssignedAgent",
  req."Assigned Group" AS "AssignedTeam",
  'BMC Helix ITSM' AS "SourceSystem",
  GETDATE() AS "LastDataUpdate"
FROM "SRM:WorkInfo" AS wi
JOIN "SRM:Request" AS req ON wi."Request Number" = req."Request Number"
WHERE req."Submit Date" BETWEEN '[START_DATE]' AND '[END_DATE]'
  AND wi."Work Log Type" IN ('General Information', 'Customer Communication', 'Resolution Communications')

UNION ALL

-- 10, 11, 12, 13: Terminal Statuses (Resolved, Confirmed, Closed, Canceled)
SELECT
  CASE req."Status"
    WHEN 'Resolved' THEN 'Service Request Resolved'
    WHEN 'Closed' AND req."Status_Reason" = 'Confirmed' THEN 'Resolution Confirmed by User'
    WHEN 'Closed' THEN 'Service Request Closed'
    WHEN 'Cancelled' THEN 'Service Request Canceled'
    ELSE NULL
  END AS "ActivityName",
  req."Request Number" AS "ServiceRequestId",
  req."Last Modified Date" AS "EventStartTime", -- This is an approximation of when the status change occurred
  NULL AS "EventEndTime",
  req."Status" AS "RequestStatus",
  req."Title" AS "ServiceType",
  req."Priority" AS "Priority",
  req."ASG_Assignee" AS "AssignedAgent",
  req."Assigned Group" AS "AssignedTeam",
  'BMC Helix ITSM' AS "SourceSystem",
  GETDATE() AS "LastDataUpdate"
FROM "SRM:Request" AS req
WHERE req."Submit Date" BETWEEN '[START_DATE]' AND '[END_DATE]'
  AND req."Status" IN ('Resolved', 'Closed', 'Cancelled')

Kroky

Předpoklady: Připravte si databázového klienta, například DBeaver, SQL Server Management Studio nebo Oracle SQL Developer, a přihlašovací údaje s oprávněním pouze ke čtení databáze BMC Helix AR System.
Připojte se k databázi: Pomocí databázového klienta se připojte k serveru databáze AR System.
Připravte dotaz: Zkopírujte celý SQL dotaz z části „Query“ tohoto dokumentu do editoru dotazů v databázovém klientovi.
Nastavte parametry: Najděte v dotazu zástupné hodnoty. Nahraďte :start_date a :end_date požadovaným obdobím extrakce, například hodnotami '2023-01-01' a '2023-12-31'. Pokud chcete filtrovat podle konkrétní společnosti, nahraďte :company_name jejím názvem.
Spusťte dotaz: Spusťte upravený SQL dotaz. Podle zvoleného období a velikosti systému může jeho zpracování trvat několik minut.
Zkontrolujte výsledky: Po dokončení dotazu se zobrazí výsledná sada obsahující záznam událostí. Krátce zkontrolujte, zda jsou data správně načtená a obsahují očekávané sloupce a aktivity.
Zkontrolujte časová razítka: Ověřte, že jsou všechna pole s časovými razítky, zejména EventStartTime, EventEndTime a LastDataUpdate, ve stejném formátu, například 'YYYY-MM-DD HH:MI:SS'. Pokud databáze vrací jiný formát, upravte podle potřeby v dotazu funkce TO_CHAR nebo CONVERT.
Exportujte data: Pomocí funkce exportu v databázovém klientovi uložte celou výslednou sadu jako soubor CSV. Zvolte kódování UTF-8, aby byl soubor kompatibilní.
Připravte soubor k nahrání: Pojmenujte soubor výstižně, například servicerequest_eventlog.csv. Nyní jej můžete nahrát do platformy ProcessMind.

Konfigurace

Přihlašovací údaje k databázi: Potřebujete uživatelský účet s oprávněním pouze ke čtení databáze AR System. Předejdete tak nechtěným změnám dat a dodržíte zásady zabezpečení.
Filtr období: Dotaz obsahuje zástupné hodnoty :start_date a :end_date. Nastavte konkrétní a přiměřené období, obvykle 3 až 12 měsíců, abyste udrželi objem dat i dobu zpracování dotazu pod kontrolou. Filtr se použije na datum zadání servisního požadavku v poli Submit_Date.
Filtr společnosti: Zástupná hodnota :company_name slouží k filtrování požadavků podle konkrétní provozní společnosti. Pokud chcete získat data všech společností, můžete odstranit řádek AND req.Company = :company_name nebo použít zástupnou hodnotu, pokud ji systém podporuje.
Hodnoty stavů: Dotaz používá standardní celočíselné hodnoty stavů BMC Helix ITSM, například Submitted = 0, In Review = 1. Váš systém může používat vlastní stavy nebo jiné číselné hodnoty. Ověřte je ve formuláři SYS:Status nebo v Developer Studio a podle potřeby upravte klauzule WHERE v dotazu.
Výkon: Přímé dotazy nad rozsáhlými tabulkami, jako jsou SRM_Request a jejich auditní záznamy, mohou výrazně zatěžovat zdroje. Extrakci naplánujte mimo špičku, abyste omezili dopad na výkon systému.

Ukázkový dotaz sql

WITH ServiceRequests AS (
  SELECT
    req.Request_Number AS ServiceRequestId,
    req.Submit_Date AS SubmitDate,
    req.Status AS CurrentStatus,
    req.Description AS ServiceType,
    req.Priority AS Priority,
    req.Assignee AS AssignedAgent,
    req.Assigned_Group AS AssignedTeam,
    req.Company,
    req.InstanceId
  FROM
    SRM_Request req
  WHERE
    req.Submit_Date BETWEEN TO_TIMESTAMP(:start_date, 'YYYY-MM-DD') AND TO_TIMESTAMP(:end_date, 'YYYY-MM-DD')
    AND req.Company = :company_name
)
-- 1. Service Request Submitted
SELECT
  sr.ServiceRequestId AS "ServiceRequestId",
  'Service Request Submitted' AS "ActivityName",
  sr.SubmitDate AS "EventStartTime",
  sr.SubmitDate AS "EventEndTime",
  'Submitted' AS "RequestStatus",
  sr.ServiceType AS "ServiceType",
  sr.Priority AS "Priority",
  sr.AssignedAgent AS "AssignedAgent",
  sr.AssignedTeam AS "AssignedTeam",
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
UNION ALL
-- 2. Request In Review
SELECT
  sr.ServiceRequestId,
  'Request In Review' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'In Review' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%In Review%'
UNION ALL
-- 3. Request Waiting for Approval
SELECT
  sr.ServiceRequestId,
  'Request Waiting for Approval' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Waiting Approval' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Waiting Approval%'
UNION ALL
-- 4. Request Approved
SELECT
  sr.ServiceRequestId,
  'Request Approved' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Approved' AS "RequestStatus", -- This status might vary, often transitions to Planning or Assigned
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Planning%' AND audit.Old_Values LIKE '%Waiting Approval%'
UNION ALL
-- 5. Request Assigned
SELECT
  sr.ServiceRequestId,
  'Request Assigned' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Assigned' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Assigned_Group%' AND audit.New_Values IS NOT NULL
UNION ALL
-- 6. Fulfillment In Progress
SELECT
  sr.ServiceRequestId,
  'Fulfillment In Progress' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'In Progress' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%In Progress%'
UNION ALL
-- 7. Information Requested from User
SELECT
  sr.ServiceRequestId,
  'Information Requested from User' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Pending' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Pending%'
UNION ALL
-- 8. Request Resumed
SELECT
  sr.ServiceRequestId,
  'Request Resumed' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'In Progress' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%In Progress%' AND audit.Old_Values LIKE '%Pending%'
UNION ALL
-- 9. Solution Implemented
SELECT
  sr.ServiceRequestId,
  'Solution Implemented' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Completed' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Completed%'
UNION ALL
-- 10. Service Request Resolved
SELECT
  sr.ServiceRequestId,
  'Service Request Resolved' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Resolved' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Resolved%'
UNION ALL
-- 11. Resolution Confirmed by User
SELECT
  sr.ServiceRequestId,
  'Resolution Confirmed by User' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Closed' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Closed%' AND audit.Old_Values LIKE '%Resolved%'
UNION ALL
-- 12. Service Request Closed
SELECT
  sr.ServiceRequestId,
  'Service Request Closed' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Closed' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Closed%'
UNION ALL
-- 13. Service Request Canceled
SELECT
  sr.ServiceRequestId,
  'Service Request Canceled' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Cancelled' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Cancelled%'
UNION ALL
-- 14. Request Rejected
SELECT
  sr.ServiceRequestId,
  'Request Rejected' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Rejected' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Rejected%';

Kroky

Předpoklady: Ověřte, že máte nainstalovaný Python 3.6 nebo novější. Nainstalujte knihovnu requests, která je potřebná pro volání HTTP API. V terminálu nebo příkazovém řádku spusťte pip install requests.
Získejte přihlašovací údaje k API: Vytvořte nebo získejte přihlašovací údaje pro vyhrazený servisní účet v BMC Helix ITSM. Účet musí mít alespoň oprávnění pouze ke čtení formuláře SRM:Request a příslušného formuláře auditního protokolu, který se často jmenuje SRM:Request_AuditLog nebo podobně. Poznamenejte si uživatelské jméno, heslo a základní URL vaší instance BMC Helix, například https://[your-company].bmc.com.
Nastavte Python skript: Uložte dodaný Python skript do souboru, například extract_servicerequests.py. Upravte jej a vyplňte zástupné proměnné na začátku: BASE_URL, USERNAME, PASSWORD a AUDIT_FORM_NAME. Slovník STATUS_ACTIVITY_MAP upravte podle stavů používaných ve workflow servisních požadavků ve vaší organizaci.
Nastavte období extrakce: Upravte proměnné START_DATE a END_DATE ve skriptu. Určují období extrakce podle data zadání servisního požadavku. Při prvním testu zvolte krátké období, například jeden den.
Spusťte skript: Spusťte skript v terminálu příkazem python extract_servicerequests.py. Skript se nejprve ověří vůči API a získá token.
Načtěte počáteční data: Skript se dotáže formuláře SRM:Request a načte seznam všech servisních požadavků vytvořených ve zvoleném období. Získá ID případu a související neměnné atributy, například prioritu a typ služby.
Načtěte historii událostí: Skript postupně zpracuje ID servisních požadavků získaná v předchozím kroku. Pro každé ID zavolá nakonfigurovaný formulář auditního protokolu a načte podrobnou historii změn stavu daného požadavku.
Převeďte data na záznam událostí: U každého záznamu z auditního protokolu skript pomocí STATUS_ACTIVITY_MAP přiřadí změně stavu standardní název aktivity. Pro každou namapovanou aktivitu vytvoří řádek s ID servisního požadavku, názvem aktivity a časovým razítkem změny.
Vytvořte událost zadání: Skript také pro každý požadavek vytvoří počáteční aktivitu „Service Request Submitted“ a použije k tomu pole Submit Date z hlavního formuláře SRM:Request.
Exportujte do CSV: Po zpracování všech servisních požadavků a jejich historie skript spojí vytvořené řádky do jednoho seznamu a uloží je do souboru CSV servicerequest_event_log.csv. Soubor je připravený k nahrání do nástroje process mining.

Konfigurace

Koncové body API: Skript používá především dva koncové body API. Ověření probíhá přes api/jwt/login. Data se načítají z arsys/v1/entry/SRM:Request pro seznam případů a z arsys/v1/entry/[AUDIT_FORM_NAME] pro historii událostí.
Oprávnění servisního účtu: Potřebujete vyhrazený servisní účet s oprávněním ke čtení formuláře SRM:Request a systémového formuláře auditního protokolu. Použití servisního účtu je důležité z hlediska zabezpečení a dohledatelnosti.
Filtr období: Skript filtruje servisní požadavky podle pole Submit Date. Pro spolehlivý výkon doporučujeme načítat data po zvládnutelných dávkách, například za 3 až 6 měsíců.
Mapování stavů na aktivity: Slovník STATUS_ACTIVITY_MAP ve skriptu tvoří základ převodu dat. Pečlivě jej nastavte podle vlastních stavů ve vaší organizaci a namapujte je na požadované názvy aktivit. Stavy, které ve workflow nejsou uvedené ve slovníku, budou ignorovány.
Formulář auditního protokolu: Možnost načíst podrobné aktivity závisí na tom, zda lze dotazovat auditní protokol. Ve svém prostředí zjistěte správný název formuláře, který uchovává historii změn stavů servisních požadavků, a podle toho upravte proměnnou AUDIT_FORM_NAME.
Stránkování: Skript automaticky zpracovává stránkování API, aby načetl všechny záznamy. Parametr limit v volání API je nastaven na 1 000 záznamů na požadavek, což vyvažuje rychlost zpracování a využití paměti.

Ukázkový dotaz python

import requests
import json
import csv
import datetime

class=class="hl-string">"hl-comment"># --- Configuration Settings --- #
class=class="hl-string">"hl-comment"># Replace with your BMC Helix environment details
BASE_URL = class="hl-string">"https://[your-company].bmc.com"
USERNAME = class="hl-string">"[your-service-account-username]"
PASSWORD = class="hl-string">"[your-service-account-password]"
class=class="hl-string">"hl-comment"># This is a placeholder; you must identify the correct audit form for SRM:Request in your system
AUDIT_FORM_NAME = class="hl-string">"SRM:Request_AuditLog"

class=class="hl-string">"hl-comment"># Date range for the extraction (YYYY-MM-DD format)
START_DATE = class="hl-string">"2023-01-01"
END_DATE = class="hl-string">"2023-03-31"

class=class="hl-string">"hl-comment"># --- Status to Activity Mapping --- #
class=class="hl-string">"hl-comment"># CRITICAL: Customize this map to match your system's status values
STATUS_ACTIVITY_MAP = {
    class="hl-string">"In Review": class="hl-string">"Request In Review",
    class="hl-string">"Waiting for Approval": class="hl-string">"Request Waiting for Approval",
    class="hl-string">"Approved": class="hl-string">"Request Approved",
    class="hl-string">"Assigned": class="hl-string">"Request Assigned",
    class="hl-string">"In Progress": class="hl-string">"Fulfillment In Progress",
    class="hl-string">"Pending": class="hl-string">"Information Requested from User", class=class="hl-string">"hl-comment"># This is a simplification; may need refinement
    class="hl-string">"Completed": class="hl-string">"Service Request Resolved",
    class="hl-string">"Closed": class="hl-string">"Service Request Closed",
    class="hl-string">"Cancelled": class="hl-string">"Service Request Canceled",
    class="hl-string">"Rejected": class="hl-string">"Request Rejected"
    class=class="hl-string">"hl-comment"># Add other custom statuses as needed
}

class=class="hl-string">"hl-comment"># Map specific status transitions for more granular activities
TRANSITION_ACTIVITY_MAP = {
    (class="hl-string">'Pending', class="hl-string">'In Progress'): class="hl-string">'Request Resumed'
    class=class="hl-string">"hl-comment"># You can add other specific transitions here
}

def get_jwt_token(base_url, username, password):
    class="hl-string">"""Authenticates with the REST API and returns a JWT token."""
    url = fclass="hl-string">"{base_url}/api/jwt/login"
    payload = {
        class="hl-string">'username': username,
        class="hl-string">'password': password
    }
    headers = {class="hl-string">'Content-Type': class="hl-string">'application/x-www-form-urlencoded'}
    try:
        response = requests.post(url, data=payload, headers=headers)
        response.raise_for_status()
        return response.text
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Error getting JWT token: {e}")
        return None

def get_paginated_results(base_url, token, form_name, query, fields):
    class="hl-string">"""Retrieves all entries from a form, handling pagination."""
    all_entries = []
    url = fclass="hl-string">"{base_url}/api/arsys/v1/entry/{form_name}"
    headers = {
        class="hl-string">'Authorization': fclass="hl-string">'AR-JWT {token}',
        class="hl-string">'Content-Type': class="hl-string">'application/json'
    }
    params = {
        class="hl-string">'q': query,
        class="hl-string">'fields': fclass="hl-string">'values({fields})',
        class="hl-string">'limit': 1000
    }
    while True:
        try:
            response = requests.get(url, headers=headers, params=params)
            response.raise_for_status()
            data = response.json()
            all_entries.extend(data[class="hl-string">'entries'])
            class=class="hl-string">"hl-comment"># Check for next page link
            if class="hl-string">'next' in data[class="hl-string">'_links']:
                url = data[class="hl-string">'_links'][class="hl-string">'next'][class="hl-string">'href']
                params = {}
            else:
                break
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching data from {form_name}: {e}")
            break
    return all_entries

def main():
    class="hl-string">"""Main function to orchestrate the data extraction."""
    print(class="hl-string">"Starting extraction...")
    token = get_jwt_token(BASE_URL, USERNAME, PASSWORD)
    if not token:
        return

    class=class="hl-string">"hl-comment"># 1. Get all Service Requests within the date range
    print(fclass="hl-string">"Fetching service requests from {START_DATE} to {END_DATE}...")
    srm_query = fclass="hl-string">"'Submit Date' >= \"{START_DATE}T00:00:00Z\class="hl-string">" AND 'Submit Date' <= \"{END_DATE}T23:59:59Z\class="hl-string">""
    srm_fields = class="hl-string">"Request Number,Submit Date,Priority,Assignee,Assigned Group,Title"
    srm_requests = get_paginated_results(BASE_URL, token, class="hl-string">"SRM:Request", srm_query, srm_fields)
    print(fclass="hl-string">"Found {len(srm_requests)} service requests.")

    event_log = []
    current_time = datetime.datetime.utcnow().isoformat() + class="hl-string">"Z"

    class=class="hl-string">"hl-comment"># 2. For each request, get its audit history
    for i, req in enumerate(srm_requests):
        req_values = req[class="hl-string">'values']
        request_id = req_values.get(class="hl-string">'Request Number')
        if not request_id:
            continue

        print(fclass="hl-string">"Processing request {i+1}/{len(srm_requests)}: {request_id}")

        class=class="hl-string">"hl-comment"># Add class="hl-string">'Service Request Submitted' event
        event_log.append({
            class="hl-string">'ServiceRequestId': request_id,
            class="hl-string">'ActivityName': class="hl-string">'Service Request Submitted',
            class="hl-string">'EventStartTime': req_values.get(class="hl-string">'Submit Date'),
            class="hl-string">'EventEndTime': req_values.get(class="hl-string">'Submit Date'),
            class="hl-string">'RequestStatus': class="hl-string">'Submitted',
            class="hl-string">'ServiceType': req_values.get(class="hl-string">'Title'),
            class="hl-string">'Priority': req_values.get(class="hl-string">'Priority'),
            class="hl-string">'AssignedAgent': req_values.get(class="hl-string">'Assignee'),
            class="hl-string">'AssignedTeam': req_values.get(class="hl-string">'Assigned Group'),
            class="hl-string">'SourceSystem': class="hl-string">'BMC Helix ITSM',
            class="hl-string">'LastDataUpdate': current_time
        })

        class=class="hl-string">"hl-comment"># 3. Fetch audit log for status changes
        audit_query = fclass="hl-string">"'Original Request ID' = \"{request_id}\class="hl-string">" AND 'Fields Changed' LIKE \"%Status%\class="hl-string">""
        audit_fields = class="hl-string">"New Value,Old Value,Log Key 1,Create Date"
        audit_entries = get_paginated_results(BASE_URL, token, AUDIT_FORM_NAME, audit_query, audit_fields)
        
        class=class="hl-string">"hl-comment"># Sort audit entries by date to ensure correct order
        audit_entries.sort(key=lambda x: x[class="hl-string">'values'][class="hl-string">'Create Date'])

        for audit_entry in audit_entries:
            audit_values = audit_entry[class="hl-string">'values']
            class=class="hl-string">"hl-comment"># Ensure we are only processing status changes
            if class="hl-string">'Status' not in audit_values.get(class="hl-string">'Log Key 1', class="hl-string">''):
                continue

            new_status = audit_values.get(class="hl-string">'New Value')
            old_status = audit_values.get(class="hl-string">'Old Value')
            timestamp = audit_values.get(class="hl-string">'Create Date')
            activity_name = None

            class=class="hl-string">"hl-comment"># Check for specific transitions first
            if (old_status, new_status) in TRANSITION_ACTIVITY_MAP:
                activity_name = TRANSITION_ACTIVITY_MAP.get((old_status, new_status))
            class=class="hl-string">"hl-comment"># Then check for general status mappings
            elif new_status in STATUS_ACTIVITY_MAP:
                activity_name = STATUS_ACTIVITY_MAP.get(new_status)

            if activity_name:
                event_log.append({
                    class="hl-string">'ServiceRequestId': request_id,
                    class="hl-string">'ActivityName': activity_name,
                    class="hl-string">'EventStartTime': timestamp,
                    class="hl-string">'EventEndTime': timestamp,
                    class="hl-string">'RequestStatus': new_status,
                    class="hl-string">'ServiceType': req_values.get(class="hl-string">'Title'),
                    class="hl-string">'Priority': req_values.get(class="hl-string">'Priority'),
                    class="hl-string">'AssignedAgent': req_values.get(class="hl-string">'Assignee'), class=class="hl-string">"hl-comment"># Note: Assignee is static from the main request
                    class="hl-string">'AssignedTeam': req_values.get(class="hl-string">'Assigned Group'), class=class="hl-string">"hl-comment"># Note: Team is static from the main request
                    class="hl-string">'SourceSystem': class="hl-string">'BMC Helix ITSM',
                    class="hl-string">'LastDataUpdate': current_time
                })
    
    class=class="hl-string">"hl-comment"># 4. Write to CSV
    output_file = class="hl-string">'servicerequest_event_log.csv'
    print(fclass="hl-string">"Writing event log to {output_file}...")
    if event_log:
        with open(output_file, class="hl-string">'w', newline=class="hl-string">'', encoding=class="hl-string">'utf-8') as f:
            writer = csv.DictWriter(f, fieldnames=event_log[0].keys())
            writer.writeheader()
            writer.writerows(event_log)
        print(class="hl-string">"Extraction complete.")
    else:
        print(class="hl-string">"No events to write.")

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

Chcete začít?

Pomocí této šablony si usnadníte sběr dat a můžete se s jistotou pustit do process miningu. Začněte zlepšovat správu požadavků na služby ještě dnes.

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

Stáhnout šablonu

Zvyšte efektivitu správy servisních požadavků

Dosáhněte 70% automatizace, omezte pomalé vyřizování požadavků a zlepšete zkušenost uživatelů.

Spusťte zkušební verzi

Bez platební karty. Začít můžete během několika minut.

Šablona dat pro správu požadavků na služby

Šablona dat pro správu požadavků na služby

Atributy správy požadavků na služby

Aktivity při správě požadavků na služby

Návody k získání dat

Přehledy servisních požadavků v BMC Helix ITSM pomocí Smart Reporting

Kroky

Konfigurace

Ukázkový dotaz sql

Přímý dotaz SQL nad tabulkami databáze AR System

Kroky

Konfigurace

Ukázkový dotaz sql

Extrakce pomocí Python skriptu přes BMC Helix REST API

Kroky

Konfigurace

Ukázkový dotaz python

Chcete začít?

Zvyšte efektivitu správy servisních požadavků