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

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

Ivanti Service Manager

Atributy správy servisních požadavků(21) Aktivity správy servisních požadavků(14) Návody k exportu dat(2)

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

Tato šablona vám pomůže shromáždit data potřebná pro účinný process mining správy servisních požadavků. Uvádí důležité atributy, které je třeba zahrnout, aktivity, které je vhodné sledovat, i praktický postup, jak data získat ze systému. Využijte ji k sestavení kvalitního záznamu událostí pro analýzu.

Doporučené atributy pro podrobnou analýzu
Důležité aktivity pro zjištění průběhu procesu
Postup exportu dat ze zdrojového systému

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 servisních požadavků

Toto jsou doporučená datová pole pro záznam událostí, který umožní podrobně analyzovat proces správy servisních požadavků.

5 Povinné 9 Doporučené 7 Volitelné

	Název	Popis
	Čas události EventTime	Časové razítko určující, kdy došlo ke konkrétní činnosti nebo události.
Popis Čas události, označovaný také jako čas zahájení, je přesné datum a čas, kdy byla činnost zaznamenána v systému. Toto časové razítko je důležité pro správné seřazení událostí a tvoří základ časové analýzy process mining, například výpočtu doby průchodu procesem, čekání a trvání jednotlivých činností. Proč je to důležité Toto časové razítko je nezbytné pro chronologické seřazení událostí a výpočet všech ukazatelů založených na době trvání, které jsou důležité pro analýzu výkonnosti. Kde data získat Najdete ho v auditních protokolech, záznamech v deníku, například v poli Journal.CreatedDateTime, nebo v záznamech o změnách stavu spojených se servisním požadavkem. 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.
Popis ID servisního požadavku jednoznačně označuje 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 konečné uzavření a umožňuje analyzovat celý průběh každého požadavku. Proč je to důležité Jde o základní identifikátor případu, který propojuje všechny související činnosti do jedné instance procesu a umožňuje analyzovat proces od začátku do konce. Kde data získat Jde o primární klíč obchodního objektu Service Request, který v tabulce ServiceReq často najdete pod názvem ServiceReqNumber. Příklady SR-0012345SR-0012346SR-0012347
	Název činnosti ActivityName	Název události nebo úkolu, ke kterému došlo 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 servisního požadavku, například „Odeslání požadavku ke schválení“ nebo „Vyřešení servisního požadavku“. Analýza pořadí a četnosti činností je základem pro pochopení průběhu procesu, hledání úzkých míst a odhalování odchylek od standardního postupu. Proč je to důležité Určuje kroky v mapě procesu a umožňuje zobrazit a analyzovat jeho průběh, včetně opakované práce, úzkých míst a odchylek. Kde data získat Obvykle se odvozuje ze změn stavů, záznamů v deníku nebo popisů událostí v auditním protokolu Ivanti Service Manager. Příklady Vytvoření servisního požadavkuSchválení požadavkuVyřešení servisního požadavkuUzavření servisního požadavku
	Poslední aktualizace dat LastDataUpdate	Časové razítko poslední aktualizace dat ze zdrojového systému.
Popis Tento atribut uvádí datum a čas posledního získání dat z Ivanti Service Manager. Informuje o aktuálnosti analyzovaných dat, takže uživatelé vědí, jaké období analýza pokrývá a kdy mohou očekávat další aktualizaci. Proč je to důležité Informuje uživatele o aktuálnosti dat, která je důležitá při rozhodování na základě nejnovějších dostupných údajů o výkonnosti procesu. Kde data získat Tato hodnota se vytvoří a přidá do datové sady při získání dat. Příklady 2024-05-20T12:00:00Z2024-05-21T12:00:00Z
	Zdrojový systém SourceSystem	Systém, ze kterého byla data získána.
Popis Tento atribut označuje původ procesních dat. V tomto pohledu bude jeho hodnota vždy stejná, protože všechna data pocházejí z Ivanti Service Manager. Je důležitý v prostředích, kde se mohou spojovat data z více systémů, protože pomáhá určit jejich původ a kontext. Proč je to důležité Poskytuje důležitý kontext o původu dat a zajišťuje, že jsou výsledky správně přiřazeny konkrétnímu zdrojovému systému, zejména v prostředí s více systémy. Kde data získat Obvykle jde o statickou hodnotu, která se přidá při získávání dat a označuje jejich zdroj. Příklady Ivanti Service Manager
	Čas ukončení události EventEndTime	Časové razítko označující dokončení aktivity.
Popis Čas ukončení události označuje dokončení aktivity. Doba mezi časem události (začátkem) a jejím ukončením představuje dobu zpracování dané aktivity. Díky tomu lze určit, které kroky procesu trvají nejdéle, a odhalit neefektivní postupy a možnosti zlepšení. Proč je to důležité Umožňuje vypočítat dobu trvání jednotlivých aktivit, což je nezbytné pro odhalení úzkých míst procesu a dlouho probíhajících úkolů. Kde data získat Nemusí být k dispozici jako samostatné pole. Často se za něj považuje čas zahájení následující aktivity ve stejné instanci procesu. Příklady 2023-10-26T10:05:00Z2023-10-26T11:45:00Z2023-10-28T09:00:00Z
	Časové razítko vyřešení ResolutionDateTime	Datum a čas, kdy byl požadavek na službu oficiálně vyřešen.
Popis Jde o atribut na úrovni případu, který označuje konečný čas dodání služby nebo vyřešení problému, ještě před formálním uzavřením požadavku. Toto časové razítko slouží jako hlavní koncový bod pro výpočet celkové doby průchodu požadavku na službu. Je důležité pro měření celkové efektivity procesu a plnění SLA. Proč je to důležité Určuje konec období, za které se počítá doba průchodu hlavním procesem. Ta je důležitým ukazatelem efektivity poskytování služeb. Kde data získat Konkrétní pole s časovým razítkem v objektu Service Request, často nazvané „ResolvedDateTime“ nebo podobně. Příklady 2023-10-28T10:15:00Z2023-10-29T11:00:00Z2023-11-01T16:30:00Z
	Priorita Priority	Úroveň priority přiřazená požadavku na službu.
Popis Priorita vyjadřuje naléhavost požadavku na službu, obvykle na škále „Nízká“, „Střední“, „Vysoká“ a „Kritická“. Tento atribut pomáhá vyhodnotit, zda proces skutečně urychluje vyřizování požadavků s vysokou prioritou. Analýza často porovnává dobu průchodu a plnění SLA u různých úrovní priority, aby ověřila, zda pravidla pro určování priorit fungují podle očekávání. Proč je to důležité Pomáhá posoudit účinnost strategie určování priorit a ověřit, zda se požadavky s vysokou prioritou vyřizují rychleji než požadavky s nízkou prioritou. Kde data získat Standardní pole objektu Service Request, obvykle nazvané „Priority“. Příklady 1 - Kritická2 - Vysoká3 - Střední4 - Nízká
	Přiřazený pracovník AssignedAgent	Konkrétní uživatel nebo pracovník podpory přiřazený k požadavku na službu.
Popis Přiřazený pracovník je konkrétní osoba odpovědná za vyřízení požadavku na službu. Tento atribut umožňuje analyzovat práci jednotlivců, což se hodí při řízení výkonnosti, vyvažování pracovní zátěže a hledání příležitostí ke školení. Sledování změn přiřazení mezi pracovníky je důležité pro výpočet KPI, jako je „Průměrný počet přeřazení na požadavek“, a pro odhalování neefektivních postupů. Proč je to důležité Umožňuje analyzovat pracovní zátěž a výkonnost jednotlivců i vzorce přeřazování. Tyto údaje mohou upozornit na nedostatky ve školení, dovednostech nebo počátečním směrování požadavků. Kde data získat Obvykle jde o pole „Owner“ v objektu Service Request. Jeho hodnota se může při každém přeřazení změnit, proto je vhodné změny zaznamenávat v záznamu událostí. Příklady Alice JohnsonBob WilliamsCharlie BrownDiana Prince
	Přiřazený tým AssignedTeam	Tým nebo skupina podpory, která aktuálně vyřizuje požadavek na službu.
Popis Tento atribut určuje tým odpovědný za vyřízení požadavku na službu v daném okamžiku. Analýza předávání mezi týmy, času stráveného u jednotlivých týmů a počtu požadavků, které týmy zpracovávají, pomáhá pochopit rozložení pracovní zátěže, odhalit úzká místa a vyhodnotit výkonnost týmů. Podporuje také dashboardy zaměřené na plnění SLA a pracovní zátěž pracovníků podpory. Proč je to důležité Zaznamenává odpovědnost a předávání požadavků. Pomáhá analyzovat prodlevy mezi týmy, vyváženost pracovní zátěže a týmy, které v procesu představují úzké místo. Kde data získat Tyto údaje se obvykle ukládají do pole, jako je „OwnerTeam“ v objektu Service Request, nebo do souvisejících záznamů o přiřazení. Příklady IT podporaProvoz sítěPodpora HRSpráva budov
	Stav požadavku na službu ServiceRequestStatus	Stav požadavku na službu v okamžiku události.
Popis Tento atribut zachycuje stav požadavku na službu, například „Zaznamenán“, „Probíhá“, „Čeká“, „Vyřešen“ nebo „Uzavřen“. Změny stavu často určují jednotlivé aktivity v záznamu procesu. Analýza doby strávené v každém stavu může odhalit úzká místa, například pokud požadavky příliš dlouho čekají. Proč je to důležité Zachycuje stav požadavku v daném okamžiku. To je nezbytné pro výpočet doby strávené v jednotlivých stavech a odhalení míst, kde se proces zastavuje. Kde data získat Standardní pole objektu Service Request, obvykle nazvané „Status“. Příklady ZaznamenánAktivníČeká na zákazníkaVyřízenUzavřen
	Stav SLA SLAStatus	Udává, zda byl požadavek na službu vyřešen do termínu SLA.
Popis Jde o odvozený atribut, který každý požadavek na službu označí jako „Splněno“ nebo „Nedodrženo“ podle toho, zda byl vyřešen do termínu SLA. Je základem dashboardu „Plnění SLA“ a KPI „Míra plnění smluv o úrovni služeb“. Logika porovnává hodnoty ResolutionDateTime a SLADeadline u každého případu. Proč je to důležité Přímo měří plnění závazků vůči uživatelům. Je důležitý pro hodnocení kvality služeb a udržení důvěry uživatelů. Kde data získat Vypočítá se porovnáním hodnot „ResolutionDateTime“ a „SLADeadline“. Pokud platí ResolutionDateTime <= SLADeadline, je stav „Splněno“, jinak „Nedodrženo“. Příklady SplněnoNedodrženo
	Termín SLA SLADeadline	Časové razítko, do kterého se očekává vyřešení požadavku na službu.
Popis Termín SLA je vypočítané datum a čas, do kterého musí být požadavek na službu vyřešen, aby byly splněny podmínky smlouvy o úrovni služeb. Cíl se obvykle stanovuje podle faktorů, jako je priorita a typ požadavku. Porovnání skutečného času vyřešení s tímto termínem slouží k měření plnění SLA. Proč je to důležité Slouží jako měřítko pro porovnání skutečné výkonnosti. Podporuje výpočet míry plnění SLA a pomáhá odhalit požadavky, u kterých hrozí nedodržení termínu. Kde data získat Často jde o vypočítané pole v Ivanti, uložené v polích souvisejících se smlouvou o úrovni služeb nebo nabídkou, například „ResolutionTargetDateTime“. Příklady 2023-10-27T17:00:00Z2023-10-28T09:00:00Z2023-11-02T12:00:00Z
	Typ požadavku na službu ServiceRequestType	Klasifikace nebo kategorie požadavku na službu.
Popis Tento atribut zařazuje požadavky na službu do kategorií, například „Požadavek na hardware“, „Instalace softwaru“ nebo „Obnovení hesla“. Jde o důležitý rozměr analýzy, který týmům umožňuje porovnávat výkonnost procesu, dobu průchodu a plnění SLA u různých typů služeb. Znalost těchto rozdílů pomáhá přizpůsobit zlepšování procesů a efektivněji rozdělovat zdroje. Proč je to důležité Rozdělení procesu podle typu požadavku umožňuje cílenou analýzu a ukáže, zda se u některých typů požadavků častěji vyskytují prodlevy, opakované zpracování nebo nedodržení SLA. Kde data získat Pravděpodobně jde o pole obchodního objektu Service Request, často nazvané „Service“ nebo „Category“. Konkrétní názvy polí, například „SvcReqTmplLink_Category“, najdete v dokumentaci Ivanti Service Manager. Příklady Požadavek na nový hardwarePřístup k softwaruZměna účtuŽádost o informace
	Jde o opakované zpracování IsRework	Logická hodnota označující, zda požadavek na službu vyžadoval opakované zpracování.
Popis Tento vypočítaný příznak se nastaví na true, pokud požadavek na službu vykazuje známky opakovaného zpracování, například byl po vyřešení znovu otevřen nebo se některé aktivity opakovaly ve smyčce. Zjednodušuje výpočet KPI „Míra opakovaného zpracování požadavků na službu“ a pomáhá filtrovat neefektivní případy v dashboardech, jako jsou „Průběhy opakovaného zpracování a přeřazování“. Proč je to důležité Usnadňuje identifikaci a vyčíslení počtu požadavků, které vyžadují další, neplánovanou práci. Pomáhá tak odhalit problémy s kvalitou a efektivitou. Kde data získat Odvozuje se z dat. Logika může vycházet z toho, že atribut „ReopenCount“ je větší než nula, nebo z detekce konkrétních posloupností aktivit, například několika událostí „Assigned to Agent“. Příklady truefalse
	Kanál Channel	Způsob nebo kanál, kterým byl požadavek na službu podán.
Popis Kanál označuje, jak byl požadavek na službu vytvořen, například prostřednictvím samoobslužného portálu, e-mailem, telefonicky nebo automaticky jiným systémem. Analýza počtu požadavků a doby jejich vyřešení podle kanálu ukáže, které kanály jsou nejefektivnější a kde může být potřeba upravit proces nebo proškolit uživatele. Proč je to důležité Pomáhá porozumět chování uživatelů a efektivitě jednotlivých kanálů. Tyto poznatky mohou podpořit rozhodování o způsobu poskytování služeb a možnostech automatizace. Kde data získat Obvykle se ukládá do pole typu „Source“ nebo „CreatedBy“ v objektu Service Request. Příklady SamoobsluhaE-mailTelefonPřímé zadání
	Kategorie vyřešení ResolutionCategory	Klasifikace způsobu vyřešení požadavku na službu.
Popis Kategorie vyřešení poskytuje strukturovaný způsob, jak klasifikovat konečný způsob vyřízení požadavku na službu. Často jde o hierarchickou klasifikaci, například kategorie a podkategorie, která pomáhá při analýze hlavních příčin a sledování trendů. Může například odhalit opakující se problémy nebo běžné způsoby vyřízení. Tyto poznatky lze využít ke zlepšení služeb nebo tvorbě článků znalostní báze. Proč je to důležité Ukazuje, jaké typy řešení se používají. Pomáhá odhalit časté problémy, možnosti zlepšení služeb i případy vhodné k automatizaci. Kde data získat Často se ukládá do klasifikačních polí vyplňovaných při vyřešení, například „ResolutionCategory“ nebo do vlastního pole s kódem uzavření. Příklady Je potřeba proškolit uživateleSoftware byl nasazenHardware byl opravenPřístup byl udělen
	Název dodavatele VendorName	Název externího dodavatele, který se podílel na vyřešení požadavku.
Popis Tento atribut určuje externího dodavatele, který pomáhá s vyřízením požadavku na službu nebo jej zajišťuje. Je nezbytný pro dashboard „Doba činnosti externích dodavatelů“, který umožňuje měřit a porovnávat výkonnost jednotlivých dodavatelů. Sledování těchto údajů pomáhá řídit vztahy s dodavateli a odhalovat úzká místa způsobená závislostí na externích stranách. Proč je to důležité Umožňuje analyzovat výkonnost externích dodavatelů a jejich vliv na celkovou dobu vyřešení požadavků na službu. Podporuje tak řízení dodavatelů. Kde data získat Může jít o pole v objektu úkolu souvisejícím s požadavkem na službu nebo o konkrétní pole přímo v objektu Service Request, pokud je přiřazen dodavatel. Příklady Dell SupportOracle ConsultingMicrosoft Premiernull
	Oddělení žadatele RequestorDepartment	Obchodní oddělení uživatele, který podal požadavek na službu.
Popis Tento atribut určuje oddělení zaměstnance nebo systému, který požadavek na službu zadal, například „Prodej“, „Finance“ nebo „Lidské zdroje“. Umožňuje analyzovat kvalitu služeb a poptávku v různých částech organizace. Může například ukázat, zda některá oddělení čekají na vyřešení déle nebo zadávají více požadavků. Proč je to důležité Umožňuje analyzovat využívání a kvalitu služeb podle organizační jednotky a odhalit problémy nebo trendy týkající se konkrétních oddělení. Kde data získat Tyto údaje se obvykle přebírají z uživatelského profilu žadatele propojeného s požadavkem na službu. Může jít o pole „Department“ v objektu Profile.Employee. Příklady FinanceProdejMarketingInformační technologie
	Počet opětovných otevření ReopenCount	Počet případů, kdy byl vyřešený požadavek na službu znovu otevřen.
Popis Tento atribut se zvýší pokaždé, když se požadavek na službu přesune ze stavu „Vyřešen“ nebo „Uzavřen“ zpět do stavu „Aktivní“. Vysoký počet opětovných otevření často ukazuje na nízkou kvalitu vyřešení napoprvé, neúplné řešení nebo opakující se problémy. Přímo podporuje KPI „Míra opakovaného zpracování požadavků na službu“. Proč je to důležité Přímo měří opakované zpracování a slouží jako důležitý ukazatel kvality vyřešení. Vysoký počet naznačuje, že původní řešení nebylo účinné. Kde data získat Obvykle jde o čítač v objektu Service Request, který se zvýší podle obchodního pravidla při odpovídající změně stavu. Může se jmenovat „ReopenCounter“. Příklady 0123
	Počet přiřazení AssignmentCount	Celkový počet přiřazení a přeřazení požadavku na službu.
Popis Tato vypočítaná metrika počítá počet aktivit souvisejících s přiřazením, například „Přiřazeno týmu“ nebo „Přiřazeno pracovníkovi“, u každého požadavku na službu. Vysoký počet přeřazení, někdy označovaný jako „ping-pong požadavků“, ukazuje na neefektivní směrování, nízkou úspěšnost vyřešení při prvním kontaktu nebo nejasné odpovědnosti týmů. Tento atribut je nezbytný pro KPI „Průměrný počet přeřazení na požadavek“. Proč je to důležité Vyčísluje neefektivní předávání a problémy se směrováním. Vysoký počet často souvisí s delší dobou vyřešení a nespokojeností uživatelů. Kde data získat Vypočítá se při přípravě dat spočítáním výskytů aktivit souvisejících s přiřazením pro každou jedinečnou hodnotu ServiceRequestID. Příklady 12345

Povinné Doporučené Volitelné

Aktivity správy servisních požadavků

Toto jsou důležité kroky a milníky procesu, které je třeba zaznamenat pro přesné zmapování a analýzu procesu.

5 Doporučené 9 Volitelné

	Aktivita	Popis
	Přiřazení požadavku pracovníkovi	Konkrétní pracovník převezme odpovědnost za servisní požadavek. Událost se obvykle odvozuje od prvního vyplnění nebo změny pole „Owner“, které označuje konkrétního pracovníka.
Proč je to důležité Tím končí počáteční čekání ve frontě. Měření doby do této činnosti pomáhá odhalit problémy s rozdělením zdrojů a poskytuje podklady pro dashboard Pracovní zátěž pracovníků. Kde data získat Událost se odvozuje z vyplnění nebo změny pole „Owner“ v záznamu Service Request, jak je zachyceno v historii auditu. Zachycení První časové razítko, kdy je po vytvoření požadavku nebo přiřazení týmu v poli „Owner“ uvedeno jméno pracovníka. Typ události inferred
	Přiřazení požadavku týmu	Servisní požadavek je přiřazen konkrétnímu týmu podpory k vyřízení. Událost se zaznamená při vyplnění nebo změně pole „OwnerTeam“ v záznamu Service Request.
Proč je to důležité Tato událost je důležitá pro analýzu výkonnosti týmů, rozložení pracovní zátěže a doby předávání mezi týmy. Pomáhá zjistit, které týmy představují v procesu úzké místo. Kde data získat Událost se sleduje podle změn pole „OwnerTeam“ v historii auditu nebo deníku servisního požadavku. Zachycení Událost aktualizace pole „OwnerTeam“, která se obvykle zaznamenává do auditní stopy. Typ události explicit
	Uzavření servisního požadavku	Servisní požadavek je oficiálně uzavřen a nelze u něj provádět další kroky. K uzavření často dojde automaticky po uplynutí stanovené doby ve stavu „Vyřešeno“. Jde o konec životního cyklu požadavku.
Proč je to důležité Tato činnost představuje definitivní konec procesu. Doba mezi stavy „Vyřešeno“ a „Uzavřeno“ může odhalit prodlevy při potvrzování nebo v automatizovaných systémových procesech. Kde data získat Událost se odvozuje ze změny pole „Status“ v záznamu Service Request na „Uzavřeno“ a souvisejícího časového razítka. Zachycení Zjištění změny pole „Status“ na „Uzavřeno“ z historie auditu. Typ události inferred
	Vyřešení servisního požadavku	Servisní požadavek je považován za vyřešený a uživatel obdržel řešení. Jde o hlavní milník, který se zaznamená změnou stavu na „Vyřešeno“. Tato změna často zastaví měření SLA.
Proč je to důležité Jde o důležitý koncový bod pro měření doby vyřízení a dodržování SLA. Doba od vytvoření požadavku do této činnosti je hlavním KPI výkonnosti procesu. Kde data získat Událost se odvozuje ze změny pole „Status“ v záznamu Service Request na „Vyřešeno“ a souvisejícího časového razítka. Zachycení Zjištění změny pole „Status“ na „Vyřešeno“ z historie auditu. Typ události inferred
	Vytvoření servisního požadavku	Tato činnost označuje začátek životního cyklu servisního požadavku. Nový požadavek je formálně odeslán a zaznamenán v Ivanti. Událost se zachytí při vytvoření nového záznamu v obchodním objektu Service Request, kterému systém přiřadí jedinečné ID servisního požadavku.
Proč je to důležité Jde o hlavní počáteční událost procesu. Doba od tohoto okamžiku do vyřešení požadavku je základem pro měření celkové doby průchodu procesem a jeho efektivity. Kde data získat Událost se zaznamená podle časového razítka vytvoření záznamu Service Request, například z pole CreatedDateTime v obchodním objektu ServiceReq. Zachycení Událost vytvoření záznamu v tabulce ServiceReq, určená podle časového razítka vytvoření. Typ události explicit
	Odeslání požadavku ke schválení	Servisní požadavek byl odeslán ke schválení, které je nutné před jeho vyřízením. Událost se obvykle odvozuje ze změny stavu požadavku na „Odesláno“ nebo „Čeká na schválení“, která často spustí workflow schvalování.
Proč je to důležité Sledování této činnosti pomáhá odhalit prodlevy ve fázi schvalování. Dlouhé čekání může představovat významné úzké místo, které prodlužuje celkovou dobu vyřízení a snižuje spokojenost uživatelů. Kde data získat Událost se odvozuje ze změny stavu záznamu Service Request, například na „Odesláno“ nebo „Čeká na schválení“. Zdrojem mohou být také obchodní objekty FRS_Approval nebo FRS_ApprovalVoteTracking. Zachycení Změna pole „Status“ v záznamu Service Request na stav čekání na schválení. Typ události inferred
	Opětovné otevření servisního požadavku	Dříve vyřešený servisní požadavek byl znovu aktivován, protože problém přetrvává nebo uživatel nebyl s řešením spokojen. Událost se zaznamená, když se stav změní z „Vyřešeno“ zpět na aktivní stav, například „Aktivní“ nebo „Přiřazeno“.
Proč je to důležité Tato činnost přímo ukazuje na opakovanou práci a nízkou úspěšnost vyřešení napoprvé. Analýza opětovně otevřených požadavků pomáhá odhalit slabá místa procesu a zlepšit KPI míry opakované práce u servisních požadavků. Kde data získat Událost se odvozuje z historie auditu, když se pole „Status“ změní ze stavu „Vyřešeno“ nebo „Uzavřeno“ na aktivní stav. Zachycení Změna stavu z konečného („Vyřešeno“, „Uzavřeno“) na otevřený („Aktivní“, „Přiřazeno“). Typ události inferred
	Poskytnutí informací uživatelem	Žadatel poskytl potřebné informace a pracovník může pokračovat v práci. Událost se zaznamená, když požadavek přejde ze stavu „Čeká na zákazníka“ zpět do aktivního stavu.
Proč je to důležité Tato událost uzavírá cyklus vyžádání informací. Doba mezi jejich vyžádáním a obdržením je důležitou součástí prodlev v procesu a opakované práce. Kde data získat Událost se odvozuje, když se pole „Status“ v záznamu Service Request změní ze stavu „Čeká na zákazníka“ na aktivní stav, například „Aktivní“ nebo „Probíhá“. Zachycení Zjištění změny stavu z čekání na uživatele na aktivní stav. Typ události inferred
	Schválení požadavku	Servisní požadavek získal všechna potřebná schválení a může pokračovat k vyřízení. Událost se zaznamená po úspěšném dokončení workflow schvalování, kdy se změní stav požadavku.
Proč je to důležité Tato činnost označuje důležitý milník: končí fáze schvalování a začíná vyřizování. Umožňuje měřit efektivitu samotného schvalovacího procesu. Kde data získat Událost se odvozuje ze změny stavu z „Čeká na schválení“ na „Schváleno“ nebo „Vyřízeno“. Může být také zaznamenána jako samostatná událost v obchodním objektu FRS_Approval. Zachycení Změna pole „Status“ v záznamu Service Request ze stavu čekání na schválení na aktivní stav. Typ události inferred
	Vyřízení servisního požadavku	Pracovník nebo systém dokončil všechny úkoly potřebné k vyřízení servisního požadavku. Událost se zaznamená při změně stavu na „Vyřízeno“, která často předchází konečnému stavu „Vyřešeno“.
Proč je to důležité Tento milník označuje dokončení technické nebo procesní práce. Je důležitý pro měření doby aktivního vyřizování před závěrečným potvrzením a uzavřením. Kde data získat Událost se odvozuje ze změny pole „Status“ v záznamu Service Request na „Vyřízeno“. Zachycení Změna pole „Status“ na „Vyřízeno“ zjištěná z historie záznamu. Typ události inferred
	Vyžádání informací od uživatele	Přiřazený pracovník potřebuje od žadatele další informace, aby mohl pokračovat ve vyřizování. Událost se zaznamená při změně stavu požadavku například na „Čeká na zákazníka“.
Proč je to důležité Tato činnost upozorňuje na prodlevy způsobené neúplnými informacemi v původním požadavku. Sledování její četnosti a doby trvání je důležité pro analýzu dopadu vyžádání informací a hledání možností zlepšení procesu. Kde data získat Událost se odvozuje ze změny stavu záznamu Service Request například na „Čeká na zákazníka“ nebo „Čeká“. Zachycení Zjištění změny pole „Status“ na určený stav čekání na uživatele. Typ události inferred
	Zapojení externího dodavatele	Vyřizování servisního požadavku bylo předáno externímu dodavateli nebo třetí straně. Událost se obvykle zaznamená při změně stavu na „Čeká na třetí stranu“ nebo podobný stav.
Proč je to důležité Tato činnost je důležitá pro měření výkonnosti dodavatelů a jejich vlivu na celkovou dobu průchodu procesem. Umožňuje analyzovat zpoždění způsobená dodavateli a poskytuje podklady pro dashboard Doba trvání činností externích dodavatelů. Kde data získat Událost se odvozuje ze změny stavu záznamu Service Request například na „Čeká na třetí stranu“ nebo „Čeká na dodavatele“. Zachycení Zjištění změny pole „Status“ na určený stav čekání na dodavatele. Typ události inferred
	Změna priority	Priorita servisního požadavku byla po jeho vytvoření změněna. Událost se zaznamená z auditního protokolu nebo historie změn jednotlivých polí.
Proč je to důležité Sledování změn priority je důležité pro přehled účinnosti určování priorit. Pomáhá zjistit, zda se eskalace řeší správně a zda byla původní priorita určena přesně. Kde data získat Jde o samostatnou událost zaznamenanou v historii auditu záznamu Service Request, která eviduje změny pole „Priority“. Zachycení Událost aktualizace pole „Priority“ zaznamenaná v auditní stopě systému. Typ události explicit
	Zrušení servisního požadavku	Uživatel nebo pracovník zrušil servisní požadavek před jeho vyřešením. Jde o alternativní konečný stav, který se zaznamená změnou stavu na „Zrušeno“ nebo „Staženo“.
Proč je to důležité Jde o ukončení procesu mimo běžný postup. Analýza důvodů zrušení požadavků může odhalit problémy v samotném procesu zadávání nebo změny potřeb uživatelů. Kde data získat Událost se odvozuje ze změny pole „Status“ v záznamu Service Request na „Zrušeno“. Zachycení Zjištění změny pole „Status“ na „Zrušeno“ z historie auditu. Typ události inferred

Doporučené Volitelné

Návody k exportu dat

Jak získat data z Ivanti Service Manageru

Kroky

Přihlaste se do Ivanti Service Manageru pod účtem s oprávněním ke čtení servisních požadavků a jejich historie změn.
V hlavní navigaci otevřete pracovní prostor Service Request.
Tento postup vyžaduje dva samostatné exporty, které následně spojíte mimo systém. První obsahuje událost vytvoření a základní atributy, druhý podrobnou historii změn.
První export (události vytvoření): Vytvořte nové uložené vyhledávání nad business objektem ServiceReq. Nastavte filtr na CreatedDateTime, abyste vybrali servisní požadavky vytvořené ve zvoleném období, například za posledních šest měsíců.
Ve vyhledávání pro vytvoření nastavte tyto sloupce: RecId, ServiceReqNumber (pro ServiceRequestID), CreatedDateTime (pro EventTime), SvcReqTmplLink_Category (pro ServiceRequestType), OwnerTeam, Owner, Priority, Status, ResolutionDateTime a TargetDateTime (pro SLADeadline).
Spusťte vyhledávání a pomocí funkce exportu v tabulce, obvykle označené ikonou disku nebo šipky, uložte data do souboru CSV. Pojmenujte ho ServiceRequests.csv.
Druhý export (události z historie změn): Vytvořte další uložené vyhledávání, tentokrát nad business objektem FRS_data_audit_history, který zaznamenává změny polí.
Omezte vyhledávání na změny související se servisními požadavky. Přidejte filtr, ve kterém se ParentObjectType rovná hodnotě 'ServiceReq'. Přidejte také filtr AuditDate pro stejné období, jaké jste zvolili předtím.
Ve vyhledávání historie změn nastavte tyto sloupce: ParentLink_RecID (pro propojení se servisním požadavkem), FieldName, OldValue, NewValue a AuditDate (pro EventTime). Exportujte data do druhého souboru CSV s názvem AuditHistory.csv.
Transformace a spojení dat: Exportované soubory CSV je třeba spojit a upravit do podoby jednoho záznamu událostí. Použijte nástroj pro přípravu dat, například Power Query v Excelu, Python nebo databázový nástroj, a proveďte následující kroky:
- Načtěte soubory ServiceRequests.csv a AuditHistory.csv.
- Ze souboru ServiceRequests.csv vytvořte pro každý požadavek událost 'Service Request Created'.
- Ze souboru AuditHistory.csv vytvořte všechny ostatní události. Hodnoty ve sloupcích FieldName a NewValue namapujte na požadované názvy aktivit. Například pokud je FieldName 'Status' a NewValue 'Resolved', nastavte ActivityName na 'Service Request Resolved'.
- Transformované události z historie změn spojte s daty servisních požadavků. Použijte ParentLink_RecID ze souboru historie a RecId ze souboru servisních požadavků. Ke každé události tak přidáte atributy případu.
- Spojte události 'Created' a události odvozené z historie změn do jedné tabulky.
Výslednou tabulku naformátujte a použijte požadované názvy sloupců: ServiceRequestID, ActivityName, EventTime, SourceSystem, LastDataUpdate a další doporučené atributy. Zajistěte jednotný formát všech časových údajů.
Uložte výsledný záznam událostí do jednoho souboru CSV, který můžete nahrát.

Konfigurace

Business objekty: Tento postup vyžaduje export ze dvou samostatných business objektů: ServiceReq obsahuje hlavní data požadavků a FRS_data_audit_history data událostí.
Filtr časového období: Pro omezení objemu dat je nezbytné použít filtr časového období u obou exportů. V objektu ServiceReq použijte pole CreatedDateTime a v objektu FRS_data_audit_history pole AuditDate. Pro první analýzu doporučujeme období 3 až 6 měsíců.
Důležité filtry historie změn:
- Nastavte filtr ParentObjectType na 'ServiceReq', abyste získali pouze změny související se servisními požadavky.
- Volitelně můžete omezit pole FieldName jen na ta, která souvisejí s procesem, například 'Status', 'Owner', 'OwnerTeam' a 'Priority'. Tím můžete výrazně zmenšit export.
Předpoklady: Potřebujete uživatelský účet v Ivanti Service Manageru s oprávněním vytvářet uložená vyhledávání a exportovat data z business objektů ServiceReq a FRS_data_audit_history.
Výkon: Tabulka FRS_data_audit_history může být velmi rozsáhlá. Export bez omezení časového období může zpomalit Ivanti nebo skončit vypršením časového limitu. V případě potřeby exportujte data po menších měsíčních nebo čtvrtletních dávkách.

Ukázkový dotaz sql

-- This script represents the transformation logic to be applied in a data preparation tool (e.g., Power Query, Python, SQL) after exporting the two CSV files from Ivanti.

-- Step 1: Define the 'Service Request Created' events from the ServiceRequests.csv export.
SELECT
    sr.ServiceReqNumber AS ServiceRequestID,
    'Service Request Created' AS ActivityName,
    sr.CreatedDateTime AS EventTime,
    'Ivanti' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    sr.SvcReqTmplLink_Category AS ServiceRequestType,
    sr.OwnerTeam AS AssignedTeam,
    sr.Owner AS AssignedAgent,
    sr.Priority,
    sr.Status AS ServiceRequestStatus,
    sr.ResolutionDateTime AS ResolutionDateTime,
    sr.TargetDateTime AS SLADeadline,
    DATEDIFF(hour, sr.CreatedDateTime, sr.ResolutionDateTime) AS CycleTime,
    CASE WHEN sr.ResolutionDateTime IS NOT NULL AND sr.ResolutionDateTime <= sr.TargetDateTime THEN 'Met' ELSE 'Breached' END AS SLAStatus,
    sr.RecId -- Internal key for joining
FROM
    ServiceRequests_Export sr -- Represents the ServiceRequests.csv file

UNION ALL

-- Step 2: Transform records from AuditHistory.csv into specific activities and join with service request attributes.
SELECT
    sr.ServiceReqNumber AS ServiceRequestID,
    CASE
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Submitted' THEN 'Request Submitted for Approval'
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Approved' THEN 'Request Approved'
        WHEN audit.FieldName = 'OwnerTeam' AND audit.OldValue IS NOT NULL THEN 'Request Assigned to Team'
        WHEN audit.FieldName = 'Owner' AND audit.OldValue IS NOT NULL THEN 'Request Assigned to Agent'
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Waiting for Customer' THEN 'Information Requested from User'
        WHEN audit.FieldName = 'Status' AND audit.OldValue = 'Waiting for Customer' THEN 'Information Provided by User'
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Waiting for 3rd Party' THEN 'External Vendor Engaged'
        WHEN audit.FieldName = 'Priority' THEN 'Priority Changed'
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Fulfilled' THEN 'Service Request Fulfilled'
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Resolved' THEN 'Service Request Resolved'
        WHEN audit.FieldName = 'Status' AND audit.OldValue IN ('Resolved', 'Closed') AND audit.NewValue NOT IN ('Resolved', 'Closed') THEN 'Service Request Reopened'
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Closed' THEN 'Service Request Closed'
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Cancelled' THEN 'Service Request Cancelled'
    END AS ActivityName,
    audit.AuditDate AS EventTime,
    'Ivanti' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    sr.SvcReqTmplLink_Category AS ServiceRequestType,
    sr.OwnerTeam AS AssignedTeam,
    sr.Owner AS AssignedAgent,
    sr.Priority,
    audit.NewValue AS ServiceRequestStatus,
    sr.ResolutionDateTime AS ResolutionDateTime,
    sr.TargetDateTime AS SLADeadline,
    NULL AS CycleTime,
    NULL AS SLAStatus,
    sr.RecId
FROM
    AuditHistory_Export audit -- Represents the AuditHistory.csv file
JOIN
    ServiceRequests_Export sr ON audit.ParentLink_RecID = sr.RecId
WHERE
    -- This filter ensures that only rows corresponding to a defined activity are included.
    CASE
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Submitted' THEN 1
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Approved' THEN 1
        WHEN audit.FieldName = 'OwnerTeam' AND audit.OldValue IS NOT NULL THEN 1
        WHEN audit.FieldName = 'Owner' AND audit.OldValue IS NOT NULL THEN 1
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Waiting for Customer' THEN 1
        WHEN audit.FieldName = 'Status' AND audit.OldValue = 'Waiting for Customer' THEN 1
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Waiting for 3rd Party' THEN 1
        WHEN audit.FieldName = 'Priority' THEN 1
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Fulfilled' THEN 1
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Resolved' THEN 1
        WHEN audit.FieldName = 'Status' AND audit.OldValue IN ('Resolved', 'Closed') AND audit.NewValue NOT IN ('Resolved', 'Closed') THEN 1
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Closed' THEN 1
        WHEN audit.FieldName = 'Status' AND audit.NewValue = 'Cancelled' THEN 1
        ELSE 0
    END = 1;

Kroky

Předpoklady a nastavení: Ověřte, že máte nainstalovaný Python 3.6 nebo novější. Nainstalujte potřebné knihovny requests pro volání API a pandas pro práci s daty příkazem pip install requests pandas. Od správce Ivanti Service Manageru si vyžádejte API klíč s oprávněním alespoň ke čtení business objektů ServiceReq a FRS_Audit_ServiceReq.
Nastavení skriptu: Stáhněte poskytnutý Python skript. Otevřete ho v textovém editoru nebo vývojovém prostředí a upravte zástupné proměnné v horní části: TENANT_URL, API_KEY, START_DATE a END_DATE podle vašeho prostředí Ivanti a požadovaného období exportu.
Spuštění skriptu: Spusťte skript z příkazového řádku příkazem python your_script_name.py. Skript nejprve vypíše zprávu o připojování k Ivanti API a ověřování.
Načtení dat servisních požadavků: Skript nejprve vyhledá v business objektu ServiceReq všechny požadavky vytvořené ve zvoleném období. Automaticky zpracuje stránkování API, aby načetl úplný seznam požadavků, a při načítání jednotlivých stránek bude vypisovat průběh.
Načtení historie změn: U každého načteného servisního požadavku skript provede další dotaz na business objekt FRS_Audit_ServiceReq. Získá tak úplnou historii změn polí daného požadavku, která je potřebná pro sestavení podrobného záznamu událostí.
Vytvoření události 'Created': Při zpracování každého servisního požadavku skript nejprve vytvoří událost 'Service Request Created'. Časové razítko převezme přímo z pole CreatedDateTime záznamu servisního požadavku.
Vytvoření událostí z auditní stopy: Skript následně projde záznamy auditní stopy každého servisního požadavku. Vyhledá změny důležitých polí, jako jsou Status, OwnerTeam, Owner a Priority.
Přiřazení změn k aktivitám: Skript pomocí předem definovaného mapování převede změny polí na konkrétní názvy aktivit. Například změnu pole Status z 'Active' na 'Resolved' zaznamená jako aktivitu 'Service Request Resolved'.
Sestavení záznamu událostí: Všechny vytvořené události, tedy počáteční vytvoření i následné změny z auditní stopy, skript spojí do strukturovaného seznamu. Každá událost obsahuje ID servisního požadavku, název aktivity, časové razítko a další relevantní atributy.
Transformace a formátování dat: Seznam událostí se převede na DataFrame knihovny Pandas. Skript zajistí, aby všechny sloupce odpovídaly požadovanému schématu ProcessMind, včetně ServiceRequestID, ActivityName a EventTime.
Export do CSV: Po zpracování všech servisních požadavků a jejich historie skript uloží výsledný DataFrame do souboru CSV ivanti_servicereq_event_log.csv ve stejné složce, ze které byl spuštěn. Soubor je připravený k nahrání.

Konfigurace

URL koncového bodu API: Základní URL REST API vašeho tenantu Ivanti Service Manager. Nastavte ji ve skriptu v proměnné TENANT_URL, například https://your-tenant.ivanti.com.
API klíč: Platný klíč REST API vytvořený v administrační konzoli Ivanti. Musí být přiřazen k roli s oprávněním ke čtení business objektů ServiceReq a FRS_Audit_ServiceReq.
Časové období: Skript vyžaduje hodnoty START_DATE a END_DATE ve formátu 'YYYY-MM-DD'. Pro první analýzu doporučujeme období 3 až 6 měsíců, které poskytne dostatek variant procesu a zároveň udrží objem dat na zvládnutelné úrovni.
Počet záznamů na stránku (TOP_COUNT): Tato proměnná určuje počet záznamů načtených při jednom volání API. Výchozí hodnota je 500, což představuje rozumný kompromis mezi výkonem a využitím paměti. Podle výkonu vašeho API serveru ji můžete upravit.
Požadovaná pole (SELECT_FIELDS_SR, SELECT_FIELDS_AUDIT): Skript určuje, která pole se mají z API načíst, aby se omezil objem dat. Ověřte, že seznamy obsahují všechna pole potřebná pro povinné i doporučené atributy.

Ukázkový dotaz python

import requests
import pandas as pd
import datetime
import time

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your Ivanti tenant URL and API Key
TENANT_URL = class="hl-string">"https://[your-tenant.ivanti.com]"
API_KEY = class="hl-string">"[Your Ivanti REST API Key]"

class=class="hl-string">"hl-comment"># Define the date range for the extraction
START_DATE = class="hl-string">"2023-01-01"
END_DATE = class="hl-string">"2023-12-31"

class=class="hl-string">"hl-comment"># API settings
TOP_COUNT = 500
API_BO_URL = fclass="hl-string">"{TENANT_URL}/api/odata/businessobject"
HEADERS = {
    class="hl-string">"Authorization": fclass="hl-string">"rest_api_key={API_KEY}",
    class="hl-string">"Content-Type": class="hl-string">"application/json"
}

class=class="hl-string">"hl-comment"># Fields to select from the API to reduce payload size
SELECT_FIELDS_SR = class="hl-string">"RecId,ServiceReqNumber,CreatedDateTime,OwnerTeam,Owner,Priority,Status,Subject,Resolution,ResolvedDateTime,ResponseTarget,Service"
SELECT_FIELDS_AUDIT = class="hl-string">"FieldName,OldValue,NewValue,ModifiedDateTime,ParentLink_RecID"

class=class="hl-string">"hl-comment"># --- Main Extraction Logic ---
def get_paginated_data(url, params):
    class="hl-string">"""Fetches all pages of data from a given Ivanti API endpoint."""
    all_records = []
    page_url = url
    while page_url:
        try:
            response = requests.get(page_url, headers=HEADERS, params=params)
            response.raise_for_status() 
            data = response.json()
            all_records.extend(data.get(class="hl-string">'value', []))
            page_url = data.get(class="hl-string">'@odata.nextLink')
            print(fclass="hl-string">"Fetched {len(all_records)} records so far...")
            class=class="hl-string">"hl-comment"># Parameters are only needed for the first request
            params = {}
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching data: {e}")
            break
    return all_records

def map_status_change_to_activity(old_status, new_status):
    class="hl-string">"""Maps status transitions to activity names."""
    class=class="hl-string">"hl-comment"># Normalize statuses by removing spaces and converting to lower case
    old = str(old_status).lower().replace(class="hl-string">" ", class="hl-string">"") if old_status else class="hl-string">""
    new = str(new_status).lower().replace(class="hl-string">" ", class="hl-string">"") if new_status else class="hl-string">""

    if new in [class="hl-string">'submitted', class="hl-string">'pendingapproval']:
        return class="hl-string">'Request Submitted for Approval'
    if new == class="hl-string">'approved':
        return class="hl-string">'Request Approved'
    if new == class="hl-string">'waitingforcustomer':
        return class="hl-string">'Information Requested from User'
    if old == class="hl-string">'waitingforcustomer' and new not in [class="hl-string">'resolved', class="hl-string">'closed', class="hl-string">'cancelled']:
        return class="hl-string">'Information Provided by User'
    if new == class="hl-string">'waitingfor3rdparty':
        return class="hl-string">'External Vendor Engaged'
    if new == class="hl-string">'fulfilled':
        return class="hl-string">'Service Request Fulfilled'
    if new == class="hl-string">'resolved':
        return class="hl-string">'Service Request Resolved'
    if old == class="hl-string">'resolved' and new not in [class="hl-string">'closed']:
        return class="hl-string">'Service Request Reopened'
    if new == class="hl-string">'closed':
        return class="hl-string">'Service Request Closed'
    if new == class="hl-string">'cancelled':
        return class="hl-string">'Service Request Cancelled'
    return None

def main():
    class="hl-string">"""Main function to orchestrate the extraction process."""
    print(class="hl-string">"Starting Ivanti Service Request extraction...")

    class=class="hl-string">"hl-comment"># 1. Fetch all Service Requests within the date range
    sr_url = fclass="hl-string">"{API_BO_URL}/ServiceReqs"
    sr_filter = fclass="hl-string">"CreatedDateTime ge {START_DATE}T00:00:00Z and CreatedDateTime le {END_DATE}T23:59:59Z"
    sr_params = {
        class="hl-string">"$filter": sr_filter,
        class="hl-string">"$select": SELECT_FIELDS_SR,
        class="hl-string">"$top": TOP_COUNT
    }
    print(fclass="hl-string">"Fetching Service Requests from {START_DATE} to {END_DATE}...")
    service_requests = get_paginated_data(sr_url, sr_params)

    if not service_requests:
        print(class="hl-string">"No service requests found for the given date range.")
        return

    print(fclass="hl-string">"Found {len(service_requests)} service requests. Now fetching audit histories...")

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

    class=class="hl-string">"hl-comment"># 2. For each Service Request, fetch its audit history and build events
    for i, sr in enumerate(service_requests):
        print(fclass="hl-string">"Processing SR {i+1}/{len(service_requests)}: {sr.get('ServiceReqNumber')}")
        sr_id = sr.get(class="hl-string">'RecId')
        sr_number = sr.get(class="hl-string">'ServiceReqNumber')
        
        class=class="hl-string">"hl-comment"># Event: Service Request Created
        event_log.append({
            class="hl-string">'ServiceRequestID': sr_number,
            class="hl-string">'ActivityName': class="hl-string">'Service Request Created',
            class="hl-string">'EventTime': sr.get(class="hl-string">'CreatedDateTime'),
            class="hl-string">'SourceSystem': class="hl-string">'Ivanti Service Manager',
            class="hl-string">'LastDataUpdate': current_time,
            class="hl-string">'EventEndTime': None,
            class="hl-string">'ServiceRequestType': sr.get(class="hl-string">'Service'),
            class="hl-string">'AssignedTeam': sr.get(class="hl-string">'OwnerTeam'),
            class="hl-string">'AssignedAgent': sr.get(class="hl-string">'Owner'),
            class="hl-string">'Priority': sr.get(class="hl-string">'Priority'),
            class="hl-string">'ServiceRequestStatus': sr.get(class="hl-string">'Status'),
            class="hl-string">'ResolutionDateTime': sr.get(class="hl-string">'ResolvedDateTime'),
            class="hl-string">'SLADeadline': sr.get(class="hl-string">'ResponseTarget'),
            class="hl-string">'CycleTime': None, class=class="hl-string">"hl-comment"># To be calculated later if needed
            class="hl-string">'SLAStatus': None class=class="hl-string">"hl-comment"># To be calculated later if needed
        })

        class=class="hl-string">"hl-comment"># Fetch audit history for this SR
        audit_url = fclass="hl-string">"{API_BO_URL}/FRS_Audit_ServiceReqs"
        audit_params = {
            class="hl-string">"$filter": fclass="hl-string">"ParentLink_RecID eq '{sr_id}'",
            class="hl-string">"$select": SELECT_FIELDS_AUDIT,
            class="hl-string">"$orderby": class="hl-string">"ModifiedDateTime asc"
        }
        audit_history = get_paginated_data(audit_url, audit_params)

        if not audit_history:
            continue

        class=class="hl-string">"hl-comment"># Process audit history to create events
        for audit_entry in audit_history:
            field_name = audit_entry.get(class="hl-string">'FieldName')
            event_time = audit_entry.get(class="hl-string">'ModifiedDateTime')
            old_value = audit_entry.get(class="hl-string">'OldValue')
            new_value = audit_entry.get(class="hl-string">'NewValue')
            activity_name = None
            current_team = None
            current_agent = None
            current_priority = None
            current_status = None

            if field_name == class="hl-string">'Status':
                activity_name = map_status_change_to_activity(old_value, new_value)
                current_status = new_value
            elif field_name == class="hl-string">'OwnerTeam' and new_value:
                activity_name = class="hl-string">'Request Assigned to Team'
                current_team = new_value
            elif field_name == class="hl-string">'Owner' and new_value:
                activity_name = class="hl-string">'Request Assigned to Agent'
                current_agent = new_value
            elif field_name == class="hl-string">'Priority' and old_value is not None:
                activity_name = class="hl-string">'Priority Changed'
                current_priority = new_value

            if activity_name:
                event_log.append({
                    class="hl-string">'ServiceRequestID': sr_number,
                    class="hl-string">'ActivityName': activity_name,
                    class="hl-string">'EventTime': event_time,
                    class="hl-string">'SourceSystem': class="hl-string">'Ivanti Service Manager',
                    class="hl-string">'LastDataUpdate': current_time,
                    class="hl-string">'EventEndTime': None,
                    class="hl-string">'ServiceRequestType': sr.get(class="hl-string">'Service'),
                    class="hl-string">'AssignedTeam': current_team or sr.get(class="hl-string">'OwnerTeam'), class=class="hl-string">"hl-comment"># Use current if changed, else original
                    class="hl-string">'AssignedAgent': current_agent or sr.get(class="hl-string">'Owner'),
                    class="hl-string">'Priority': current_priority or sr.get(class="hl-string">'Priority'),
                    class="hl-string">'ServiceRequestStatus': current_status or sr.get(class="hl-string">'Status'),
                    class="hl-string">'ResolutionDateTime': sr.get(class="hl-string">'ResolvedDateTime'),
                    class="hl-string">'SLADeadline': sr.get(class="hl-string">'ResponseTarget'),
                    class="hl-string">'CycleTime': None,
                    class="hl-string">'SLAStatus': None
                })

    class=class="hl-string">"hl-comment"># 3. Create DataFrame and save to CSV
    if not event_log:
        print(class="hl-string">"No events were generated.")
        return

    print(class="hl-string">"Extraction complete. Creating CSV file...")
    df = pd.DataFrame(event_log)
    class=class="hl-string">"hl-comment"># Ensure chronological order
    df[class="hl-string">'EventTime'] = pd.to_datetime(df[class="hl-string">'EventTime'])
    df = df.sort_values(by=[class="hl-string">'ServiceRequestID', class="hl-string">'EventTime'], ascending=[True, True])
    
    class=class="hl-string">"hl-comment"># Forward fill key attributes to provide context for each event
    df[class="hl-string">'AssignedTeam'] = df.groupby(class="hl-string">'ServiceRequestID')[class="hl-string">'AssignedTeam'].fillna(method=class="hl-string">'ffill')
    df[class="hl-string">'AssignedAgent'] = df.groupby(class="hl-string">'ServiceRequestID')[class="hl-string">'AssignedAgent'].fillna(method=class="hl-string">'ffill')
    df[class="hl-string">'Priority'] = df.groupby(class="hl-string">'ServiceRequestID')[class="hl-string">'Priority'].fillna(method=class="hl-string">'ffill')
    df[class="hl-string">'ServiceRequestStatus'] = df.groupby(class="hl-string">'ServiceRequestID')[class="hl-string">'ServiceRequestStatus'].fillna(method=class="hl-string">'ffill')

    output_filename = class="hl-string">'ivanti_servicereq_event_log.csv'
    df.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%SZ')
    print(fclass="hl-string">"Event log saved successfully to {output_filename}")

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

Chcete začít?

Využijte tuto podrobnou šablonu dat a zlepšete správu servisních požadavků. Začněte optimalizovat provoz ještě dnes.

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

Stáhnout šablonu

Začněte zlepšovat správu servisních požadavků ještě dnes

Zkraťte vyřizování požadavků, snižte frustraci uživatelů a dosáhněte 70% míry automatizace.

Spustit zkušební verzi zdarma

Bez platební karty, 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 správy servisních požadavků

Aktivity správy servisních požadavků

Návody k exportu dat

Export dat z Ivanti do CSV pomocí uloženého vyhledávání a tabulky

Kroky

Konfigurace

Ukázkový dotaz sql

Python skript využívající Ivanti REST API

Kroky

Konfigurace

Ukázkový dotaz python

Chcete začít?

Začněte zlepšovat správu servisních požadavků ještě dnes