> Amélioration Continue des Processusus > Gestion des demandes de service > Ivanti Service Manager > Template de données

Votre modèle de données pour la gestion des demandes de service

Ivanti Service Manager

← Retour au Guide d'amélioration

Attributs de gestion des demandes de service (21) Activités de gestion des demandes de service (14) Guides d'extraction (2)

Votre modèle de données pour la gestion des demandes de service

Ce modèle fournit un guide détaillé pour la collecte des données essentielles requises pour un process mining efficace de votre gestion des demandes de service. Il décrit les attributs essentiels à recueillir, les activités clés à suivre et inclut des conseils pratiques sur l'extraction de ces informations de votre système. Utilisez cette ressource pour générer un journal d'événements fiable pour votre analyse.

Attributs recommandés pour une analyse détaillée
Activités clés à suivre pour la découverte de processus
Conseils sur l'extraction de données de votre système source

Vous découvrez les journaux d'événements ? Apprenez comment créer un journal d'événements Process Mining.

Télécharger le modèle

Attributs de gestion des demandes de service

Ce sont les champs de données recommandés à inclure dans votre journal d'événements pour une analyse complète de votre processus de gestion des demandes de service.

5 Obligatoire 9 Recommandé 7 Facultatif

	Nom	Descriptionn
	Heure de l'événement EventTime	L'horodatage indiquant quand une activité ou un événement spécifique s'est produit.
Descriptionn L'heure de l'événement, également connue sous le nom d'heure de début, est la date et l'heure précises auxquelles une activité a été enregistrée dans le système. Cet horodatage est indispensable pour séquencer correctement les événements et sert de base à toute analyse de processus mining basée sur le temps, telle que le calcul des temps de cycle, des temps d'attente et des durées d'activité. Pourquoi est-ce important ? : Cet horodatage est indispensable pour ordonner les événements chronologiquement et calculer toutes les métriques basées sur la durée, qui sont essentielles pour l'analyse de performance. Source des données : Trouvé dans les journaux d'audit, les entrées de journal (par exemple, Journal.CreatedDateTime) ou les enregistrements de changement de statut associés à la requête de service. Exemples 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:00Z
	ID de demande de service ServiceRequestID	L'identifiant unique pour chaque demande de service.
Descriptionn L'ID de Demande de Service identifie de manière unique chaque demande de service soumise par un utilisateur ou un système. Il sert de élément central reliant tous les événements ultérieurs, de l'enregistrement initial à la clôture finale, pour une analyse complète et complet du parcours de chaque demande de service. Pourquoi est-ce important ? : C'est l'identifiant de cas clé qui relie toutes les activités associées en une seule instance de processus, permettant une analyse de processus complet. Source des données : C'est la clé primaire de l'objet métier Demande de Service, souvent trouvée sous le nom ServiceReqNumber dans la table ServiceReq. Exemples SR-001, 2, 3, 45SR-001, 2, 3, 46SR-001, 2, 3, 47
	Nom de l'activité ActivityName	Le nom de l'événement ou de la tâche qui s'est produite à un moment spécifique du cycle de vie de la demande de service.
Descriptionn Cet attribut décrit une étape spécifique ou un changement de statut au sein du processus de demande de service, tel que « Demande soumise pour approbation » ou « Demande de service résolue ». L'analyse de la séquence et de la fréquence des activités est clée pour comprendre le flux du processus, identifier les points de blocage et découvrir les écarts par rapport à la procédure standard. Pourquoi est-ce important ? : Il définit les étapes de la carte de processus, pour visualiser et l'analyse du flux de processus, y compris l'identification des retouches, des points de blocage et des écarts. Source des données : Généralement dérivé des changements de statut, des entrées de journal ou des descriptions d'événements du journal d'audit au sein d'Ivanti Service Manager. Exemples Demande de service crééeDemande approuvéeDemande de service résolueDemande de service fermée
	Dernière mise à jour des données LastDataUpdate	L'horodatage de la dernière actualisation des données depuis le système source.
Descriptionn Cet attribut indique la date et l'heure de la dernière extraction des données d'Ivanti Service Manager. Il fournit un contexte sur la la réactualisation des données analysées, garantissant que les utilisateurs sont conscients de la période couverte par l'analyse et quand la prochaine mise à jour peut être attendue. Pourquoi est-ce important ? : Informe les utilisateurs sur la pertinence des données, ce qui est indispensable pour prendre des décisions basées sur les informations de performance de processus les plus récentes disponibles. Source des données : Cette valeur est générée et estampillée sur l'ensemble de données au moment de l'extraction des données. Exemples 2024-05-20T12:00:00Z2024-05-21T12:00:00Z
	Système source SourceSystem	Le système d'où les données ont été extraites.
Descriptionn Cet attribut identifie l'origine des données du processus. Pour cette vue, la valeur sera constante, indiquant que toutes les données proviennent d'Ivanti Service Manager. Ceci est important dans les environnements où les données peuvent être fusionnées à partir de plusieurs systèmes, assurant une traçabilité des données et un contexte clairs. Pourquoi est-ce important ? : Il fournit un contexte essentiel sur la provenance des données, garantissant que les analyses sont correctement attribuées au système source spécifique, en particulier dans les environnements multi-systèmes. Source des données : Il s'agit généralement d'une valeur statique ajoutée lors du processus d'extraction des données pour étiqueter l'origine de l'ensemble de données. Exemples Ivanti Service Manager
	Agent assigné AssignedAgent	L'utilisateur individuel ou l'agent assigné à la demande de service.
Descriptionn L'agent assigné est la personne spécifique responsable du traitement de la demande de service. Cet attribut permet une analyse au niveau individuel, utile pour la gestion de la performance, l'équilibrage de la charge de travail et l'identification des opportunités de formation. Le suivi des réaffectations entre agents est indispensable pour calculer des KPI comme le « Nombre moyen de réaffectations par demande » et comprendre les inefficacités du processus. Pourquoi est-ce important ? : Permet l'analyse de la charge de travail individuelle, des performances et des modèles de réaffectation, ce qui peut indiquer des problèmes de formation, de compétences ou de routage initial. Source des données : Généralement disponible dans un champ comme « Owner » sur l'objet Demande de Service. Cela peut changer à chaque réaffectation et doit être suivi dans le journal d'événements. Exemples Alice JohnsonBob WilliamsCharlie BrownDiana Prince
	Date limite SLA SLADeadline	L'horodatage auquel la demande de service est censée être résolue.
Descriptionn La Date Limite SLA est la date et l'heure calculées auxquelles une demande de service doit être résolue pour respecter son accord de niveau de service. Cet objectif est généralement déterminé en fonction de facteurs tels que la priorité et le type de la demande. La comparaison du temps de résolution réel avec cette date limite est la base de la mesure de l'respect des SLA. Pourquoi est-ce important ? : Il s'agit du critère par rapport auquel la performance réelle est mesurée, soutenant directement le calcul des taux de conformité aux SLA et l'identification des requêtes à risque. Source des données : Il s'agit souvent d'un champ calculé au sein d'Ivanti, stocké dans des champs liés à l'accord de niveau de service ou à l'Offre, tel que « ResolutionTargetDateTime ». Exemples 2023-10-27T17:00:00Z2023-10-28T09:00:00Z2023-11-02T12:00:00Z
	Équipe assignée AssignedTeam	L'équipe ou le groupe de support actuellement assigné pour gérer la demande de service.
Descriptionn Cet attribut identifie l'équipe responsable du traitement de la demande de service à un moment donné. L'analyse des transferts entre équipes, du temps passé avec chaque équipe et du volume de demandes traitées par différentes équipes est indispensablele pour comprendre la répartition de la charge de travail, identifier les points de blocage et évaluer les performances de l'équipe. Il prend directement en charge les dashboards liés au respect des SLA et à la charge de travail des agents. Pourquoi est-ce important ? : Suit les responsabilités et les transferts, aidant à analyser les retards inter-équipes, l'équilibre de la charge de travail et quelles équipes sont des points de blocage dans le processus. Source des données : Cette information est généralement stockée dans un champ comme « OwnerTeam » sur l'objet Demande de Service ou dans des enregistrements d'affectation connexes. Exemples Centre de services ITOpérations RéseauSupport RHGestion des installations
	Heure de fin de l'événement EventEndTime	L'horodatage indiquant quand une activité a été achevée.
Descriptionn L'Heure de Fin de l'Événement marque la fin d'une activité. La durée entre l'Heure de l'Événement (début) et l'Heure de Fin de l'Événement représente le temps de traitement de cette activité spécifique. Ceci est impératif pour identifier les étapes du processus qui prennent le plus de temps, aidant à repérer les inefficacités et les domaines à améliorer. Pourquoi est-ce important ? : Il permet le calcul des durées d'activités individuelles, ce qui est indispensable pour identifier les points de blocage du processus et les tâches à exécution longue. Source des données : Il peut ne pas exister en tant que champ distinct. Souvent, il s'agit de l'heure de début de l'activité suivante dans la séquence pour le même cas. Exemples 2023-10-26T10:05:00Z2023-10-26T11:45:00Z2023-10-28T09:00:00Z
	Horodatage de Résolution ResolutionDateTime	La date et l'heure auxquelles la demande de service a été officiellement résolue.
Descriptionn Il s'agit d'un attribut au niveau du cas marquant l'horodatage final lorsque le service a été livré ou le problème résolu, avant que la demande ne soit officiellement clôturée. Cet horodatage est le point final principal pour le calcul du temps de cycle complet d'une demande de service. C'est un élément clé pour mesurer l'efficacité globale du processus et l'respect des SLA. Pourquoi est-ce important ? : Définit le point final pour le calcul du temps de cycle du processus principal, un indicateur clé de performance pour l'efficacité de la prestation de services. Source des données : Un champ d'horodatage spécifique sur l'objet Requête de Service, souvent nommé 'ResolvedDateTime' ou similaire. Exemples 2023-10-28T10:15:00Z2023-10-29T11:00:00Z2023-11-01T16:30:00Z
	Priorité Priority	Le niveau de priorité attribué à la demande de service.
Descriptionn La priorité indique l'urgence d'une requête de service, généralement sur une échelle comme 'Faible', 'Moyenne', 'Élevée', 'Critique'. Cet attribut est indispensable pour évaluer si le processus accélère efficacement les requêtes de haute priorité. L'analyse implique souvent la comparaison des temps de cycle et de la conformité aux SLA entre les différents niveaux de priorité afin de s'assurer que les règles de priorisation fonctionnent comme prévu. Pourquoi est-ce important ? : Primordial pour évaluer l'efficacité de la stratégie de priorisation et garantir que les requêtes à haute priorité sont résolues plus rapidement que celles à faible priorité. Source des données : Un champ standard sur l'objet Requête de Service, généralement nommé 'Priority'. Exemples 1 - Critique2 - Élevée3 - Moyenne4 - Faible
	Statut de la Demande de Service ServiceRequestStatus	Le statut de la demande de service au moment de l'événement.
Descriptionn Cet attribut capture l'état de la demande de service, tel que « Comptabilisée », « En cours », « En attente », « Résolue » ou « Clôturée ». Les changements de statut définissent souvent les activités dans le journal de processus. L'analyse du temps passé dans chaque statut peut révéler des points de blocage, par exemple, si les demandes passent trop de temps dans un état « En attente ». Pourquoi est-ce important ? : Fournit un aperçu de l'état de la requête à un instant donné, ce qui est indispensable pour calculer le temps passé dans des états spécifiques et identifier les blocages de processus. Source des données : Un champ standard sur l'objet Requête de Service, communément appelé 'Status'. Exemples ComptabiliséActifEn attente du clientExécutéeClôturé
	Statut SLA SLAStatus	Indique si la requête de service a été résolue dans les délais de son SLA.
Descriptionn Il s'agit d'un attribut dérivé qui marque chaque demande de service comme « Respecté » ou « Violé » en fonction de son temps de résolution par rapport à sa date limite SLA. C'est le fondement du tableau de bord « Performance de Respect des SLA » et du KPI « Taux de Respect des Accords de Niveau de Service ». La logique compare le ResolutionDateTime avec le SLADeadline pour chaque cas. Pourquoi est-ce important ? : Mesure directement la performance par rapport aux engagements de service, ce qui est indispensable pour évaluer la qualité du service et maintenir la confiance des utilisateurs. Source des données : Calculé en comparant 'ResolutionDateTime' à 'SLADeadline'. Si ResolutionDateTime <= SLADeadline, le statut est 'Met' ; sinon, il est 'Breached'. Exemples AtteintDépassé
	Type de demande de service ServiceRequestType	La classification ou catégorie de la demande de service.
Descriptionn Cet attribut catégorise la demande de service, par exemple, « Demande de matériel », « Installation de logiciel » ou « Réinitialisation de mot de passe ». C'est une dimension majeure pour l'analyse, permettant aux équipes de comparer les performances des processus, les temps de cycle et le respect des SLA entre différents types de services. Comprendre ces différences aide à adapter les améliorations de processus et à allouer les ressources plus efficacement. Pourquoi est-ce important ? : La segmentation du processus par type de demande permet une analyse ciblée, révélant si certains types de demandes sont plus sujets aux retards, aux retouches ou aux ruptures de SLA. Source des données : Probablement un champ sur l'objet métier de requête de service, souvent nommé 'Service' ou 'Category'. Consultez la documentation d'Ivanti Service Manager pour les noms de champs spécifiques comme 'SvcReqTmplLink_Category'. Exemples Nouvelle demande de matérielAccès logicielModification de compteDemande d'information
	Canal Channel	La méthode ou le canal par lequel la demande de service a été soumise.
Descriptionn Le canal indique comment la demande de service a été créée, par exemple, via le portail libre-service, par e-mail, par téléphone, ou automatiquement par un autre système. L'analyse des volumes de demandes et des temps de résolution par canal peut fournir des informations sur les canaux les plus efficaces et ceux qui pourraient nécessiter des améliorations de processus ou une formation des utilisateurs. Pourquoi est-ce important ? : Aide à comprendre le comportement des utilisateurs et l'efficacité des canaux, ce qui peut éclairer les décisions concernant la stratégie de prestation de services et les opportunités d'automatisation. Source des données : Ceci est souvent stocké dans un champ de type « Source » ou « Créé par » sur l'objet Demande de Service. Exemples Libre-serviceE-mailTéléphoneSaisie directe
	Catégorie de résolution ResolutionCategory	Une classification de la résolution fournie pour la requête de service.
Descriptionn La Catégorie de Résolution offre un moyen structuré de classer la manière dont une demande de service a été finalement résolue. Il s'agit souvent d'une classification hiérarchique (par exemple, Catégorie, Sous-catégorie) qui aide à l'analyse des causes profondes et à la création de rapports de tendances. Par exemple, elle peut mettre en évidence des problèmes récurrents ou des types d'actions de réalisation courants, qui peuvent être utilisés pour améliorer les services ou créer des articles de base de connaissances. Pourquoi est-ce important ? : Fournit des informations sur la nature des résolutions, aidant à identifier les problèmes courants, les opportunités d'amélioration des services et les candidats à l'automatisation. Source des données : Souvent stocké dans des champs de catégorisation renseignés lors de la résolution, tels que 'ResolutionCategory' ou un champ de code de clôture personnalisé. Exemples Formation Utilisateur RequiseLogiciel DéployéMatériel réparéAccès accordé
	Est un reprises IsRework	Un indicateur booléen indiquant si la requête de service a impliqué des activités de reprises.
Descriptionn Ce drapeau calculé est défini sur vrai si une demande de service présente des signes de reprises, comme une réouverture après résolution ou la répétition de certaines activités en boucle. Il simplifie le calcul du KPI « Taux de Retravail des Demandes de Service » et aide à filtrer les instances de processus inefficaces dans les dashboards comme « Flux de Retravail et de Réaffectation ». Pourquoi est-ce important ? : Aide à identifier et à quantifier facilement le volume de requêtes nécessitant un effort supplémentaire et imprévu, mettant en évidence les problèmes de qualité et d'efficacité. Source des données : Dérivé des données. La logique peut être basée sur l'attribut 'ReopenCount' supérieur à zéro ou par la détection de séquences d'activités spécifiques, comme plusieurs événements 'Assigned to Agent'. Exemples truefaux
	Nom du fournisseur VendorName	Le nom du fournisseur externe impliqué dans la résolution de la demande.
Descriptionn Cet attribut identifie le fournisseur tiers engagé pour aider ou compléter une demande de service. Il est indispensable pour le tableau de bord « Durée d'activité des fournisseurs externes », car il permet de mesurer et de comparer les performances des différents fournisseurs. Le suivi de cet attribut aide à gérer les relations avec les fournisseurs et à identifier les points de blocage causés par des dépendances externes. Pourquoi est-ce important ? : Permet l'analyse des performances des tiers et de leur impact sur les temps de résolution globaux des requêtes de service, soutenant la gestion des fournisseurs. Source des données : Il pourrait s'agir d'un champ sur un objet tâche associé à la demande de service, ou d'un champ spécifique sur la Demande de Service elle-même si un fournisseur est assigné. Exemples Support DellOracle ConsultingMicrosoft Premiernull
	Nombre d'affectations AssignmentCount	Le nombre total de fois qu'une demande de service a été attribuée ou réaffectée.
Descriptionn Cette métrique calculée compte le nombre d'activités liées à l'affectation (par exemple, « Attribué à l'équipe », « Attribué à l'agent ») pour chaque demande de service. Un nombre élevé de réaffectations, souvent appelé « ping-pong de tickets », indique des inefficacités dans l'acheminement, un manque de résolution au premier contact ou des responsabilités d'équipe peu claires. Cet attribut est indispensable pour le KPI « Nombre moyen de réaffectations par demande ». Pourquoi est-ce important ? : Quantifie les transferts inefficaces et les problèmes d'acheminement. Un nombre élevé indique clairement des délais de résolution prolongés et de la frustration pour les utilisateurs. Source des données : Calculé en comptant les occurrences d'activités liées aux affectations pour chaque ServiceRequestID unique pendant la préparation des données. Exemples 12345
	Nombre de réouvertures ReopenCount	Le nombre de fois qu'une demande de service résolue a été rouverte.
Descriptionn Cet attribut est un compteur qui s'incrémente chaque fois qu'une demande de service passe d'un état « Résolu » ou « Clôturé » à un état « Actif ». Un nombre élevé de réouvertures est un indicateur fort de mauvaise qualité de résolution au premier contact, de solutions incomplètes ou de problèmes récurrents. Il supporte directement le KPI « Taux de Retravail des Demandes de Service ». Pourquoi est-ce important ? : Mesure directement les retouches et est un indicateur clé de la qualité de la résolution. Un nombre élevé suggère que la correction initiale n'était pas efficace. Source des données : Il s'agit généralement d'un champ compteur sur l'objet Demande de Service qui est incrémenté par une règle métier lorsque le statut change de manière appropriée. Il pourrait être nommé « ReopenCounter ». Exemples 0123
	Service du demandeur RequestorDepartment	Le service commercial de l'utilisateur qui a soumis la demande de service.
Descriptionn Cet attribut identifie le service de l'employé ou du système qui a initié la demande de service, tel que « Ventes », « Finance » ou « Ressources Humaines ». Il permet d'analyser la qualité et la demande de service à travers différentes parties de l'organisation. Par exemple, il peut aider à identifier si certains services connaissent des temps de résolution plus longs ou soumettent un volume de demandes plus élevé. Pourquoi est-ce important ? : Permet l'analyse de la consommation et de la qualité des services par unité commerciale, aidant à identifier les problèmes ou tendances spécifiques à un département. Source des données : Ces informationsns sont généralement récupérées à partir du profil utilisateur du demandeur, lié à la Demande de Service. Le champ pourrait être « Département » dans l'objet Profile.Employee. Exemples FinanceVentesMarketingTechnologies de l'Information

Obligatoire Recommandé Facultatif

Activités de gestion des demandes de service

Voici les étapes de processus et les jalons essentiels à capturer dans votre journal d'événements pour une découverte et une analyse précises des processus.

5 Recommandé 9 Facultatif

	Activité	Descriptionn
	Demande assignée à l'agent	Un agent spécifique prend en charge la requête de service. Cette activité est généralement inférée lorsque le champ 'Owner', qui désigne l'agent individuel, est renseigné ou mis à jour pour la première fois.
Pourquoi est-ce important ? : Ceci marque la fin du temps d'attente initial ou de la file d'attente. Mesurer la durée avant cette activité aide à identifier les problèmes d'allocation des ressources et supporte le tableau de bord de la charge de travail des agents. Source des données : Inférence de la population ou du changement du champ 'Owner' dans l'enregistrement de la requête de service, tel qu'observé dans l'historique d'audit. Capture Le premier horodatage où le champ « Propriétaire » est renseigné avec le nom d'un agent après la création ou l'attribution à une équipe. Type d'événement inferred
	Demande Attribuée à l'Équipe	La demande de service est attribuée à une équipe de support spécifique pour traitement. Cela est enregistré en observant le remplissage ou le changement du champ « OwnerTeam » dans l'enregistrement de la Demande de Service.
Pourquoi est-ce important ? : Cet événement est impératif pour analyser la performance au niveau des équipes, la distribution de la charge de travail et les temps de transfert inter-équipes. Il aide à identifier quelles équipes sont des points de blocage dans le processus. Source des données : Suivi par les modifications du champ « OwnerTeam » dans l'historique d'audit ou le journal de la Demande de Service. Capture Un événement de mise à jour du champ 'OwnerTeam', qui est généralement enregistré dans un journal d'audit. Type d'événement explicit
	Demande de service créée	Cette activité marque le début du cycle de vie de la demande de service lorsqu'une nouvelle demande est officiellement soumise et enregistrée dans Ivanti. Cet événement est capturé lors de la création d'un nouvel enregistrement dans l'objet métier Demande de Service, générant un ID de Demande de Service unique.
Pourquoi est-ce important ? : C'est l'événement de début principal pour le processus. L'analyse du temps écoulé entre ce point et la résolution est clée pour mesurer le temps de cycle global et l'efficacité du processus. Source des données : Ceci est capturé à partir de l'horodatage de création de l'enregistrement de la Demande de Service (par exemple, le champ CreatedDateTime dans l'objet métier ServiceReq). Capture L'événement de création d'enregistrement dans la table ServiceReq, identifié par son horodatage de création. Type d'événement explicit
	Demande de service fermée	La demande de service est officiellement close et aucune autre action ne peut être entreprise. Cela se produit souvent automatiquement après une période définie dans l'état « Résolu », représentant la conclusion finale du cycle de vie.
Pourquoi est-ce important ? : Cette activité marque la fin définitive du processus. Le temps entre « Résolu » et « Clos » peut mettre en évidence des retards dans la confirmation ou les processus système automatisés. Source des données : Inférence d'un changement dans le champ 'Status' de l'enregistrement de la requête de service à 'Closed', accompagné de l'horodatage associé. Capture Détection de la mise à jour du champ 'Status' à 'Closed' à partir de l'historique d'audit. Type d'événement inferred
	Demande de service résolue	La demande de service est considérée comme résolue et la solution a été livrée à l'utilisateur. Il s'agit d'une étape clé enregistrée par un changement de statut vers « Résolu », déclenchant souvent l'arrêt du décompte du SLA.
Pourquoi est-ce important ? : Il s'agit d'un point final critique pour mesurer le temps de résolution et le respect des SLA. La durée entre la création et cette activité est un KPI essentiel pour la performance du processus. Source des données : Inférence d'un changement dans le champ 'Status' de l'enregistrement de la requête de service à 'Resolved', accompagné de l'horodatage associé. Capture Détection de la mise à jour du champ 'Status' à 'Resolved' à partir de l'historique d'audit. Type d'événement inferred
	Demande approuvée	La demande de service a reçu toutes les approbations nécessaires et peut maintenant procéder à l'exécution. Cet événement est enregistré lorsque le workflow d'approbation se termine avec succès, modifiant le statut de la demande.
Pourquoi est-ce important ? : Cette activité marque un jalon clé, signalant la fin de la phase d'approbation et le début de l'exécution. Elle permet de mesurer l'efficacité du processus d'approbation lui-même. Source des données : Inférence d'un changement de statut de 'Waiting for Approval' à 'Approved' ou 'Fulfilled'. Cela peut également être un événement explicite enregistré dans l'objet métier FRS_Approval. Capture Un changement dans le champ 'Status' de l'enregistrement de la requête de service d'un état d'approbation à un état actif. Type d'événement inferred
	Demande de Service Annulée	La demande de service a été annulée par l'utilisateur ou un agent avant la résolution. Il s'agit d'un état final alternatif enregistré par un changement de statut vers « Annulé » ou « Retiré ».
Pourquoi est-ce important ? : Ceci représente une terminaison de processus non standard. L'analyse des raisons pour lesquelles les demandes sont annulées peut révéler des problèmes avec le processus de demande lui-même ou des besoins utilisateurs changeants. Source des données : Inférence d'un changement dans le champ 'Status' de l'enregistrement de la requête de service à 'Cancelled'. Capture Détection de la mise à jour du champ 'Status' à 'Cancelled' à partir de l'historique d'audit. Type d'événement inferred
	Demande de Service Réalisée	Toutes les tâches requises pour traiter la requête de service ont été accomplies par l'agent ou le système. Ceci est capturé par un changement de statut à 'Fulfilled', qui précède souvent le statut final 'Resolved'.
Pourquoi est-ce important ? : Ce jalon marque l'achèvement du travail technique ou procédural. C'est un point clé pour mesurer le temps de traitement actif avant la confirmation et la clôture finales. Source des données : Inférence d'un changement dans le champ 'Status' de l'enregistrement de la requête de service à 'Fulfilled'. Capture Un changement du champ 'Status' à 'Fulfilled' détecté à partir de l'historique de l'enregistrement. Type d'événement inferred
	Demande de service réouverte	Une requête de service précédemment résolue a été réactivée car le problème persiste ou la solution était insatisfaisante. Ceci est capturé lorsque le statut passe de 'Resolved' à un état actif comme 'Active' ou 'Assigned'.
Pourquoi est-ce important ? : Cette activité est un indicateur direct de reprises et de mauvaise qualité de résolution au premier contact. L'analyse des événements de réouverture aide à identifier les faiblesses du processus et à améliorer l'indicateur clé de performance (KPI) du Taux de Retravail des Demandes de Service. Source des données : Inférence de l'historique d'audit lorsque le champ 'Status' passe de 'Resolved' ou 'Closed' à un statut actif. Capture Un changement de statut d'un état terminal ('Resolved', 'Closed') à un état ouvert ('Active', 'Assigned'). Type d'événement inferred
	Demande Soumise pour Approbation	La demande de service a été soumise pour les approbations nécessaires avant de pouvoir être exécutée. Cela est généralement déduit lorsque le statut de la demande passe à « Soumis » ou « En attente d'approbation », déclenchant souvent un workflow d'approbation.
Pourquoi est-ce important ? : Le suivi de cette activité aide à identifier les retards dans la phase d'approbation. Des attentes prolongées à ce stade peuvent constituer un goulot d'étranglement important, impactant les temps de résolution globaux et la satisfaction des utilisateurs. Source des données : Inférence d'un changement de statut sur l'enregistrement de la requête de service, probablement vers un statut tel que 'Submitted' ou 'Waiting for Approval'. Cela peut également provenir des objets métier FRS_Approval ou FRS_ApprovalVoteTracking. Capture Un changement dans le champ 'Status' de l'enregistrement de la requête de service vers un état en attente d'approbation. Type d'événement inferred
	Fournisseur externe engagé	L'exécution de la demande de service a été transférée à un fournisseur externe ou à un tiers. Cela est généralement enregistré par un changement de statut vers « En attente de tiers » ou un état similaire.
Pourquoi est-ce important ? : Cette activité est indispensablele pour mesurer la performance des fournisseurs et son impact sur le temps de cycle global. Elle permet d'analyser les retards liés aux fournisseurs et supporte le tableau de bord « Durée d'activité des fournisseurs externes ». Source des données : Inférence d'un changement de statut dans l'enregistrement de la requête de service vers un statut tel que 'Waiting for 3rd Party' ou 'Pending Vendor'. Capture Détection d'un changement dans le champ 'Status' vers un état désigné 'en attente du fournisseur'. Type d'événement inferred
	Informations demandées à l'utilisateur	L'agent assigné a besoin de plus d'informations du demandeur pour poursuivre l'exécution. Cela est enregistré lorsque le statut de la demande est mis à jour vers un état tel que « En attente du client ».
Pourquoi est-ce important ? : Cette activité met en évidence les retards causés par des informations initiales incomplètes. Le suivi de sa fréquence et de sa durée est indispensable pour l'analyse d'impact des demandes d'informations et l'identification des domaines d'amélioration des processus. Source des données : Inférence d'un changement de statut dans l'enregistrement de la requête de service vers un statut tel que 'Waiting for Customer' ou 'Pending'. Capture Détection d'un changement dans le champ 'Status' vers un état désigné 'en attente de l'utilisateur'. Type d'événement inferred
	Informations fournies par l'utilisateur	Le demandeur a fourni les informations nécessaires, permettant à l'agent de reprendre le travail. Ceci est enregistré lorsque la demande quitte un statut « En attente du client » pour revenir à un état actif.
Pourquoi est-ce important ? : Cet événement clôture la boucle des demandes d'informations. Le temps entre la demande et la réception d'informations est un élément critique des retards de processus et des boucles de reprise. Source des données : Inférence lorsque le champ 'Status' de la requête de service passe d'un état 'Waiting for Customer' à un état actif, comme 'Active' ou 'In Progress'. Capture Détection d'un changement de statut d'un état 'en attente de l'utilisateur' à un état actif. Type d'événement inferred
	Priorité modifiée	La priorité de la demande de service a été mise à jour après sa création initiale. Cet événement est enregistré à partir du journal d'audit ou de l'historique qui suit les modifications au niveau des champs.
Pourquoi est-ce important ? : Le suivi des changements de priorité est indispensable à l'Aperçu de l'Efficacité de la Priorisation. Il aide à déterminer si les escalades sont gérées correctement « what-if » la priorisation initiale est précise. Source des données : Il s'agit d'un événement explicite capturé à partir de l'historique d'audit de l'enregistrement de la Demande de Service, qui enregistre les modifications apportées au champ « Priorité ». Capture Un événement de mise à jour du champ 'Priority' enregistré dans le journal d'audit du système. Type d'événement explicit

Recommandé Facultatif

Guides d'extraction

Comment obtenir vos données depuis Ivanti Service Manager

Étapes

Connectez-vous à Ivanti Service Manager avec un rôle disposant d'un accès en lecture aux requêtes de service et à leur historique d'audit.
Naviguez vers l'espace de travail des requêtes de service depuis le panneau de navigation principal.
Ce processus nécessite deux exportations de données distinctes qui seront combinées en externe. La première capture l'événement de création et les attributs principaux, et la seconde capture l'historique détaillé des modifications.
Première exportation (Événements de création) : Créez une nouvelle recherche enregistrée (Saved Search) sur l'objet métier ServiceReq. Définissez un filtre pour CreatedDateTime afin de sélectionner les requêtes de service créées au cours de votre période d'analyse souhaitée, par exemple, les six derniers mois.
Configurez les colonnes pour la recherche de création afin d'inclure RecId, ServiceReqNumber (pour ServiceRequestID), CreatedDateTime (pour (EventTime)), SvcReqTmplLink_Category (pour ServiceRequestType), OwnerTeam, Owner, Priority, Status, ResolutionDateTime et TargetDateTime (pour SLADeadline).
Exécutez la recherche et utilisez la fonction d'exportation de la grille, généralement une icône ressemblant à un disque ou une flèche, pour exporter les données vers un fichier CSV. Nommez-le ServiceRequests.csv.
Deuxième exportation (Événements de l'historique d'audit) : Créez une nouvelle recherche enregistrée, cette fois sur l'objet métier FRS_data_audit_history, qui enregistre les modifications de champs.
Filtrez cette recherche pour n'inclure que les modifications liées aux requêtes de service. Ajoutez un filtre où ParentObjectType est égal à 'ServiceReq'. Ajoutez également un filtre sur AuditDate pour la même période d'analyse que celle que vous avez utilisée précédemment.
Configurez les colonnes pour la recherche d'audit afin d'inclure ParentLink_RecID (pour relier à la requête de service), FieldName, OldValue, NewValue et AuditDate (pour (EventTime)). Exportez ces données vers un second fichier CSV nommé AuditHistory.csv.
Transformation et combinaison des données : Les fichiers CSV exportés doivent être combinés et restructurés en un seul journal d'événements. Utilisez un outil de prélèvement.paration de données comme Power Query dans Excel, Python ou un outil de base de données pour effectuer les étapes suivantes :
- Chargez à la fois ServiceRequests.csv et AuditHistory.csv.
- Utilisez le fichier ServiceRequests.csv pour générer l'événement 'Service Request Created' pour chaque requête.
- Utilisez le fichier AuditHistory.csv pour générer tous les autres événements. Mappez les valeurs des colonnes FieldName et NewValue aux noms d'activités requis, par exemple, si FieldName est 'Status' et NewValue est 'Resolved', l'(ActivityName) devient 'Service Request Resolved'.
- Joignez les événements d'audit transformés aux données de la requête de service en utilisant ParentLink_RecID du fichier d'audit et RecId du fichier de la requête de service. Cela ajoute les attributs de niveau de cas à chaque événement.
- Combinez les événements 'Création' et les événements dérivés de l'audit en une seule table.
Formatez la table combinée finale avec les en-têtes de colonne requis : ServiceRequestID, (ActivityName), (EventTime), SourceSystem, LastDataUpdate et d'autres attributs recommandés. Assurez-vous que tous les horodatages sont dans un format cohérent.
Enregistrez le journal d'événements final sous forme de fichier CSV unique, prêt à être téléchargé.

Configuration

Objets métier : Cette méthode nécessite l'exportation depuis deux objets métier distincts : ServiceReq pour les données principales de la requête et FRS_data_audit_history pour les données d'événement.
Filtre de plage de dates : Il est impératif d'appliquer un filtre de plage de dates aux deux exportations pour gérer le volume de données. Utilisez le champ CreatedDateTime sur ServiceReq et le champ AuditDate sur FRS_data_audit_history. Une période de 3 à 6 mois est recommandée pour l'analyse initiale.
Filtres clés pour l'historique d'audit :
- ParentObjectType doit être filtré sur 'ServiceReq' pour vous assurer que vous n'extrayez que les changements liés aux requêtes de service.
- Vous pouvez éventuellement filtrer FieldName pour inclure uniquement les champs pertinents pour votre processus, tels que 'Status', 'Owner', 'OwnerTeam' et 'Priority', ce qui peut réduire considérablement la taille de l'exportation.
Prérequis : Un compte utilisateur dans Ivanti Service Manager avec les autorisations nécessaires pour créer des recherches enregistrées et exporter des données à partir des objets métier ServiceReq et FRS_data_audit_history est requis.
Considérations de performance : La table FRS_data_audit_history peut être très volumineuse. L'exportation de données sans filtre de date restrictif peut entraîner des problèmes de performance pour l'application Ivanti et potentiellement un timeout. Envisagez d'exporter les données par lots plus petits, mensuels ou trimestriels, si nécessaire.

a Exemple de requête config

-- 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;

Étapes

Prérequis et configuration : Assurez-vous que Python 3.6 ou une version ultérieure est installé sur votre système. Installez les bibliothèques nécessaires, requests pour les appels API et pandas pour la manipulation des données, en exécutant pip install requests pandas. Obtenez une clé API auprès de votre administrateur Ivanti Service Manager avec au moins les autorisations de lecture pour les objets métier ServiceReq et FRS_Audit_ServiceReq.
Configurer le script : Téléchargez le script Python fourni. Ouvrez le script dans un éditeur de texte ou un IDE et mettez à jour les variables de remplacement en haut : TENANT_URL, API_KEY, START_DATE et END_DATE pour qu'elles correspondent à votre environnement Ivanti et à la fenêtre d'extraction souhaitée.
Exécuter le script : Exécutez le script depuis votre ligne de commande en utilisant python your_script_name.py. Le script affichera d'abord un message indiquant qu'il se connecte et s'authentifie auprès de l'API Ivanti.
Récupérer les données de requêtes de service : Le script commence par interroger l'objet métier ServiceReq pour toutes les requêtes créées dans la plage de dates spécifiée. Il gère automatiquement la pagination de l'API pour récupérer la liste complète des requêtes, affichant les mises à jour de progression au fur et à mesure qu'il récupère chaque page de données.
Récupérer l'historique d'audit : Pour chaque requête de service récupérée, le script effectue une requête secondaire sur l'objet métier FRS_Audit_ServiceReq. Cela récupère l'historique complet des modifications de champs pour cette requête spécifique, ce qui est indispensable pour construire le journal d'événements détaillé.
Générer l'événement 'Création' : Au fur et à mesure que le script traite chaque requête de service, il crée d'abord l'événement 'Service Request Created'. L'horodatage de cet événement est tiré directement du champ CreatedDateTime de l'enregistrement de la requête de service.
Générer des événements à partir du journal d'audit : Le script parcourt ensuite les enregistrements du journal d'audit pour chaque requête de service. Il analyse chaque enregistrement pour identifier les changements dans les champs clés comme Status, OwnerTeam, Owner et Priority.
Mapper les changements aux activités : Une logique de mappage prédéfinie dans le script convertit ces changements de champs en noms d'activités spécifiques. Par exemple, un changement dans le champ Status de 'Active' à 'Resolved' est enregistré comme une activité 'Service Request Resolved'.
Construire le journal d'événements : Tous les événements générés, à la fois la création initiale et les changements ultérieurs du journal d'audit, sont compilés dans une liste structurée. Chaque événement comprend l'ID de la requête de service, le nom de l'activité, l'horodatage et d'autres attributs pertinents.
Transformation et formatage des données : La liste collectée d'événements est convertie en un DataFrame Pandas. Le script s'assure que toutes les colonnes correspondent au schéma requis pour ProcessMind, y compris ServiceRequestID, (ActivityName) et (EventTime).
Exporter au format CSV : Une fois toutes les requêtes de service et leurs historiques traités, le script enregistre le DataFrame final dans un fichier CSV nommé ivanti_servicereq_event_log.csv dans le même répertoire que celui où le script a été exécuté. Ce fichier est prêt à être téléchargé.

Configuration

URL de l'endpoint API : L'URL de base pour l'API REST de votre tenant Ivanti Service Manager. Elle doit être définie dans la variable TENANT_URL du script, par exemple, https://your-tenant.ivanti.com.
Clé API : Une clé d'API REST valide générée dans la console d'administration d'Ivanti. Cette clé doit être associée à un rôle disposant des autorisations de lecture pour les objets métier ServiceReq et FRS_Audit_ServiceReq.
Plage de dates : Le script nécessite une START_DATE et une END_DATE au format 'YYYY-MM-DD'. Pour une analyse initiale, une plage de dates de 3 à 6 mois est recommandée afin d'assurer un volume de données gérable tout en capturant suffisamment de variations de processus.
Taille de page (TOP_COUNT) : Cette variable dans le script définit le nombre d'enregistrements à récupérer par appel d'API. La valeur par défaut est de 500, ce qui représente un bon équilibre entre performance et utilisation de la mémoire. Vous pouvez l'ajuster en fonction des performances de votre serveur API.
Champs requis (SELECT_FIELDS_SR, SELECT_FIELDS_AUDIT) : Le script spécifie les champs à récupérer de l'API pour minimiser la taille de la charge utile. Assurez-vous que tous les champs nécessaires pour les attributs requis et recommandés sont inclus dans ces listes.

a Exemple de requête 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()

Votre modèle de données pour la gestion des demandes de service

Votre modèle de données pour la gestion des demandes de service

Attributs de gestion des demandes de service

Activités de gestion des demandes de service

Guides d'extraction

Recherche enregistrée Ivanti et exportation de données de grille vers CSV

Étapes

Configuration

a Exemple de requête config

Script Python utilisant l'API REST Ivanti

Étapes

Configuration

a Exemple de requête python

Prêt(e) à démarrer ?

Commencez à optimiser votre gestion des demandes de service dès aujourd'hui

Votre modèle de données pour la gestion des demandes de service

Votre modèle de données pour la gestion des demandes de service

Attributs de gestion des demandes de service

Activités de gestion des demandes de service

Guides d'extraction

Recherche enregistrée Ivanti et exportation de données de grille vers CSV

Étapes

Configuration

a Exemple de requête config

Script Python utilisant l'API REST Ivanti

Étapes

Configuration

a Exemple de requête python

Nous respectons votre vie privée

Prêt(e) à démarrer ?

Commencez à optimiser votre gestion des demandes de service dès aujourd'hui