> Amélioration continue des processus > Gestion des demandes de service > Ivanti Service Manager > Modèle de données

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

Ivanti Service Manager

Attributs de la 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 complet pour recueillir les données essentielles nécessaires à un Process Mining efficace de votre gestion des demandes de service. Il présente les attributs importants à collecter, les activités clés à suivre et des conseils pratiques pour extraire ces informations de votre système. Utilisez cette ressource pour constituer un journal d’événements fiable destiné à votre analyse.

Attributs recommandés pour une analyse complète
Activités clés à suivre pour découvrir le processus
Conseils pour extraire les données de votre système source

Vous découvrez les journaux d’événements ? En savoir plus sur la création d’un journal d’événements pour le Process Mining.

Télécharger le modèle

Attributs de la gestion des demandes de service

Voici les champs de données recommandés à inclure dans votre journal d’événements pour analyser de manière complète votre processus de gestion des demandes de service.

5 Obligatoire 9 Recommandé 7 Facultatif

	Nom	Description
	Heure de l’événement EventTime	L’horodatage indiquant le moment où une activité ou un événement précis s’est produit.
Description Event Time, également appelé heure de début, correspond à la date et à l’heure précises auxquelles une activité a été enregistrée dans le système. Cet horodatage est essentiel pour ordonner correctement les événements et constitue la base de toutes les analyses temporelles de process mining, notamment le calcul des temps de cycle, des temps d’attente et de la durée des activités. Pourquoi c’est important Cet horodatage est essentiel pour classer les événements par ordre chronologique et calculer tous les indicateurs fondés sur la durée, qui sont indispensables à l’analyse des performances. Où les obtenir Cet élément se trouve dans les journaux d’audit, les entrées de journal, par exemple Journal.CreatedDateTime, ou les enregistrements de changement de statut associés à la demande de service. Exemples 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:00Z
	Identifiant de la demande de service ServiceRequestID	L’identifiant unique de chaque demande de service.
Description Le Service Request ID identifie de manière unique chaque demande de service soumise par un utilisateur ou un système. Il constitue le fil conducteur central reliant tous les événements ultérieurs, de l’enregistrement initial à la clôture finale, et permet d’analyser intégralement le parcours de chaque demande de service. Pourquoi c’est important Il s’agit de l’identifiant de cas essentiel qui relie toutes les activités associées au sein d’une même instance de processus et permet une analyse de bout en bout. Où les obtenir Il s’agit de la clé primaire de l’objet métier Service Request, souvent présente sous le nom ServiceReqNumber dans la table ServiceReq. Exemples SR-0012345SR-0012346SR-0012347
	Nom de l’activité ActivityName	Le nom de l’événement ou de la tâche survenu à un moment précis du cycle de vie de la demande de service.
Description Cet attribut décrit une étape précise ou un changement de statut dans le processus de demande de service, comme « Request Submitted for Approval » ou « Service Request Resolved ». L’analyse de la séquence et de la fréquence des activités est fondamentale pour comprendre le flux du processus, identifier les goulots d’étranglement et détecter les écarts par rapport à la procédure standard. Pourquoi c’est important Il définit les étapes de la carte de processus et permet de visualiser et d’analyser le flux du processus, notamment pour identifier les reprises, les goulots d’étranglement et les écarts. Où les obtenir Cet attribut est généralement dérivé des changements de statut, des entrées de journal ou des descriptions d’événements du journal d’audit dans Ivanti Service Manager. Exemples Demande de service crééeDemande approuvéeDemande de service résolueDemande de service clôturée
	Dernière mise à jour des données LastDataUpdate	L’horodatage de l’actualisation la plus récente des données provenant du système source.
Description Cet attribut indique la date et l’heure de la dernière extraction des données depuis Ivanti Service Manager. Il précise l’actualité des données analysées, afin que les utilisateurs connaissent la période couverte par l’analyse et sachent quand la prochaine mise à jour est prévue. Pourquoi c’est important Il informe les utilisateurs de la fraîcheur des données, un élément essentiel pour prendre des décisions fondées sur les informations les plus récentes disponibles concernant les performances des processus. Où les obtenir Cette valeur est générée et ajoutée au jeu 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 depuis lequel les données ont été extraites.
Description Cet attribut identifie l’origine des données du processus. Dans cette vue, sa valeur est constante et indique que toutes les données proviennent d’Ivanti Service Manager. Cette information est importante dans les environnements où les données peuvent être fusionnées à partir de plusieurs systèmes, car elle garantit une traçabilité et un contexte clairs. Pourquoi c’est important Il fournit un contexte essentiel sur la provenance des données et garantit que les analyses sont correctement attribuées au système source concerné, en particulier dans les environnements multisystèmes. Où les obtenir Il s’agit généralement d’une valeur statique ajoutée lors de l’extraction des données pour identifier l’origine du jeu de données. Exemples Ivanti Service Manager
	Agent affecté AssignedAgent	Utilisateur ou agent chargé de la demande de service.
Description L’agent affecté est la personne précisément responsable du traitement de la demande de service. Cet attribut permet une analyse individuelle, utile pour le suivi des performances, l’équilibrage de la charge et l’identification des besoins de formation. Le suivi des réaffectations entre agents est essentiel pour calculer des KPI tels que « Nombre moyen de réaffectations par demande » et comprendre les inefficacités du processus. Pourquoi c’est important Il permet d’analyser la charge de travail, les performances individuelles et les schémas de réaffectation, qui peuvent révéler des problèmes de formation, de compétences ou d’orientation initiale. Où les obtenir Il se trouve généralement dans un champ tel que « Owner » de l’objet Service Request. Sa valeur peut changer à chaque réaffectation et doit être suivie dans l’Event Log. Exemples Alice JohnsonBob WilliamsCharlie BrownDiana Prince
	Échéance du SLA SLADeadline	Horodatage avant lequel la demande de service est censée être résolue.
Description L’échéance du SLA correspond à la date et à l’heure calculées auxquelles une demande de service doit être résolue pour respecter son accord de niveau de service. Cette cible est généralement déterminée en fonction de facteurs tels que la priorité et le type de demande. La comparaison entre l’heure réelle de résolution et cette échéance sert de base à la mesure du respect des SLA. Pourquoi c’est important Elle constitue la référence utilisée pour mesurer les performances réelles. Elle permet notamment de calculer les taux de respect des SLA et d’identifier les demandes à risque. Où les obtenir Il s’agit souvent d’un champ calculé dans Ivanti, stocké dans des champs liés à l’accord de niveau de service ou à l’offre, tels que « ResolutionTargetDateTime ». Exemples 2023-10-27T17:00:00Z2023-10-28T09:00:00Z2023-11-02T12:00:00Z
	Équipe affectée AssignedTeam	Équipe ou groupe de support actuellement chargé de traiter la demande de service.
Description 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é auprès de chacune d’elles et du volume de demandes traité par les différentes équipes est essentielle pour comprendre la répartition de la charge, identifier les goulots d’étranglement et évaluer les performances des équipes. Elle contribue directement aux Dashboards consacrés au respect des SLA et à la charge de travail des agents. Pourquoi c’est important Suit les responsabilités et les transferts, afin d’analyser les retards entre équipes, l’équilibre de la charge et les équipes qui constituent des goulots d’étranglement dans le processus. Où les obtenir Ces informations sont généralement stockées dans un champ tel que « OwnerTeam » de l’objet Service Request, ou dans des enregistrements d’affectation associés. Exemples Centre de services informatiquesOpérations réseauSupport RHGestion des installations
	Heure de fin de l’événement EventEndTime	Horodatage indiquant le moment où une activité a été terminée.
Description L’heure de fin de l’événement marque l’achèvement d’une activité. La durée entre l’heure de l’événement, qui correspond au début, et l’heure de fin de l’événement représente le temps de traitement de cette activité. Elle est essentielle pour identifier les étapes du processus qui prennent le plus de temps, et ainsi repérer les inefficacités et les possibilités d’amélioration. Pourquoi c’est important Cet attribut permet de calculer la durée de chaque activité, ce qui est essentiel pour identifier les goulots d’étranglement et les tâches dont l’exécution est longue. Où les obtenir Ce champ peut ne pas exister en tant que champ distinct. Il correspond souvent à 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	Date et heure auxquelles la demande de service a été officiellement résolue.
Description Il s’agit d’un attribut au niveau du cas qui indique l’horodatage final auquel le service a été fourni ou le problème corrigé, avant la fermeture officielle de la demande. Cet horodatage constitue le point de terminaison principal pour calculer le délai de traitement de bout en bout d’une demande de service. Il est essentiel pour mesurer l’efficacité globale du processus et le respect des SLA. Pourquoi c’est important Il définit le point final du calcul du délai du cycle principal du processus, un indicateur clé de l’efficacité de la prestation de services. Où les obtenir Champ d’horodatage spécifique de l’objet Service Request, souvent nommé « ResolvedDateTime » ou de manière similaire. Exemples 2023-10-28T10:15:00Z2023-10-29T11:00:00Z2023-11-01T16:30:00Z
	Priorité Priority	Niveau de priorité attribué à la demande de service.
Description La priorité indique le degré d’urgence d’une demande de service, généralement selon une échelle telle que « Faible », « Moyenne », « Élevée » ou « Critique ». Cet attribut est fondamental pour évaluer si le processus traite effectivement les demandes prioritaires en accéléré. L’analyse consiste souvent à comparer les délais de traitement et le respect des SLA selon les différents niveaux de priorité, afin de vérifier que les règles de priorisation fonctionnent comme prévu. Pourquoi c’est important Elle est essentielle pour évaluer l’efficacité de la stratégie de priorisation et vérifier que les demandes hautement prioritaires sont résolues plus rapidement que les demandes faiblement prioritaires. Où les obtenir Champ standard de l’objet Service Request, généralement nommé « Priority ». Exemples 1 - Critique2 - Élevée3 - Moyenne4 - Faible
	Statut de la demande de service ServiceRequestStatus	Statut de la demande de service au moment de l’événement.
Description Cet attribut indique l’état de la demande de service, par exemple « Logged », « In Progress », « Pending », « Resolved » ou « Closed ». Les changements d’état définissent souvent les activités du journal de processus. L’analyse du temps passé dans chaque état peut révéler des goulots d’étranglement, par exemple lorsque les demandes restent trop longtemps à l’état « Pending ». Pourquoi c’est important Il fournit un instantané de l’état de la demande à un moment donné, ce qui est essentiel pour calculer le temps passé dans certains états et identifier les blocages du processus. Où les obtenir Champ standard de l’objet Service Request, généralement nommé « Status ». Exemples EnregistréActifEn attente du clientTraitéClôturé
	Statut du SLA SLAStatus	Indique si la demande de service a été résolue dans le délai prévu par son SLA.
Description Il s’agit d’un attribut dérivé qui indique pour chaque demande de service si le SLA a été « Respecté » ou « Dépassé », en fonction du délai de résolution par rapport à l’échéance du SLA. Il constitue la base du Dashboard « Performance du respect des SLA » et du KPI « Taux de respect de l’accord de niveau de service ». La logique compare « ResolutionDateTime » à « SLADeadline » pour chaque cas. Pourquoi c’est important Il mesure directement les performances par rapport aux engagements de service, ce qui est essentiel pour évaluer la qualité du service et préserver la confiance des utilisateurs. Où les obtenir Il est calculé en comparant « ResolutionDateTime » à « SLADeadline ». Si ResolutionDateTime <= SLADeadline, le statut est « Respecté » ; sinon, il est « Dépassé ». Exemples RespectéNon respecté
	Type de demande de service ServiceRequestType	Classification ou catégorie de la demande de service.
Description Cet attribut catégorise la demande de service, par exemple « Demande de matériel », « Installation de logiciel » ou « Réinitialisation du mot de passe ». Il constitue une dimension essentielle de l’analyse, car il permet aux équipes de comparer les performances du processus, les délais de traitement et le respect des SLA selon les différents types de services. La compréhension de ces écarts aide à adapter les améliorations du processus et à affecter les ressources plus efficacement. Pourquoi c’est important La segmentation du processus par type de demande permet de mener des analyses ciblées et de déterminer si certains types de demandes sont davantage sujets aux retards, aux reprises ou aux violations de SLA. Où les obtenir Il s’agit probablement d’un champ de l’objet métier Service Request, souvent nommé « Service » ou « Category ». Consultez la documentation d’Ivanti Service Manager pour connaître les noms de champs spécifiques, tels que « SvcReqTmplLink_Category ». Exemples Demande de nouveau matérielAccès à un logicielModification d'un compteDemande d'information
	Canal Channel	Méthode ou canal par lequel la demande de service a été soumise.
Description Le canal indique comment la demande de service a été créée, par exemple via le portail en libre-service, par e-mail, par téléphone ou automatiquement par un autre système. L’analyse du volume de demandes et des délais de résolution par canal permet de déterminer quels canaux sont les plus efficaces et lesquels nécessitent une amélioration du processus ou une formation des utilisateurs. Pourquoi c’est important Il aide à comprendre le comportement des utilisateurs et l’efficacité des canaux, afin d’éclairer les décisions relatives à la stratégie de prestation de services et aux possibilités d’automatisation. Où les obtenir Cette information est souvent stockée dans un champ de type « Source » ou « CreatedBy » de l’objet Service Request. Exemples Libre-serviceE-mailTéléphoneSaisie directe
	Catégorie de résolution ResolutionCategory	Classification de la résolution apportée à la demande de service.
Description La catégorie de résolution fournit une méthode structurée pour classer la manière dont une demande de service a finalement été résolue. Il s’agit souvent d’une classification hiérarchique, par exemple « Catégorie » et « Sous-catégorie », qui facilite l’analyse des causes racines et le suivi des tendances. Elle peut notamment faire ressortir des problèmes récurrents ou des types courants d’actions de traitement, qui serviront à améliorer les services ou à créer des articles pour la base de connaissances. Pourquoi c’est important Elle fournit des informations sur la nature des résolutions et aide à identifier les problèmes fréquents, les possibilités d’amélioration des services et les candidats à l’automatisation. Où les obtenir Elle est souvent stockée dans des champs de catégorisation renseignés lors de la résolution, tels que « ResolutionCategory » ou un champ personnalisé de code de clôture. Exemples Formation de l'utilisateur requiseLogiciel déployéMatériel réparéAccès accordé
	Indicateur de reprise IsRework	Indicateur booléen précisant si la demande de service a comporté des activités de reprise.
Description Cet indicateur calculé prend la valeur true lorsqu’une demande de service présente des signes de reprise, par exemple lorsqu’elle est rouverte après sa résolution ou lorsque certaines activités sont répétées en boucle. Il simplifie le calcul du KPI « Taux de reprise des demandes de service » et permet de filtrer les instances de processus inefficaces dans des Dashboards tels que « Flux de reprise et de réaffectation ». Pourquoi c’est important Il permet d’identifier et de quantifier facilement le volume de demandes nécessitant un effort supplémentaire et imprévu, mettant ainsi en évidence les problèmes de qualité et d’efficacité. Où les obtenir Il est dérivé des données. La logique peut reposer sur un attribut « ReopenCount » supérieur à zéro ou sur la détection de séquences d’activités spécifiques, telles que plusieurs événements « Affecté à un agent ». Exemples truefalse
	Nom du fournisseur VendorName	Nom du fournisseur externe intervenant dans la résolution de la demande.
Description Cet attribut identifie le fournisseur tiers sollicité pour aider à traiter ou à terminer une demande de service. Il est essentiel pour le Dashboard « External Vendor Activity Duration », car il permet de mesurer et de comparer les performances des différents fournisseurs. Ce suivi contribue à la gestion des relations avec les fournisseurs et à l’identification des goulots d’étranglement liés aux dépendances externes. Pourquoi c’est important Il permet d’analyser les performances des tiers et leur impact sur les délais globaux de résolution des demandes de service, au service de la gestion des fournisseurs. Où les obtenir Il peut s’agir d’un champ d’un objet de tâche associé à la demande de service, ou d’un champ spécifique de la Service Request lorsqu’un fournisseur est affecté. Exemples Dell SupportOracle ConsultingMicrosoft Premiernull
	Nombre d’affectations AssignmentCount	Nombre total de fois où une demande de service a été affectée ou réaffectée.
Description Cette mesure calculée compte le nombre d’activités liées aux affectations, par exemple « Affecté à une équipe » ou « Affecté à un agent », pour chaque demande de service. Un nombre élevé de réaffectations, souvent appelé « ping-pong des tickets », indique des inefficacités dans l’orientation, l’absence de résolution au premier contact ou un manque de clarté dans les responsabilités des équipes. Cet attribut est essentiel au KPI « Nombre moyen de réaffectations par demande ». Pourquoi c’est important Il quantifie les transferts inefficaces et les problèmes d’orientation. Un nombre élevé indique fortement des délais de résolution prolongés et la frustration des utilisateurs. Où les obtenir Il est calculé en comptant les occurrences d’activités liées aux affectations pour chaque ServiceRequestID unique lors de la préparation des données. Exemples 12345
	Nombre de réouvertures ReopenCount	Nombre de fois où une demande de service résolue a été rouverte.
Description Cet attribut est un compteur qui augmente chaque fois qu’une demande de service passe de l’état « Résolue » ou « Fermée » à l’état « Active ». Un nombre élevé de réouvertures indique fortement une qualité insuffisante de la résolution au premier contact, des solutions incomplètes ou des problèmes récurrents. Il alimente directement le KPI « Taux de reprise des demandes de service ». Pourquoi c’est important Il mesure directement les reprises et constitue un indicateur clé de la qualité de la résolution. Un nombre élevé suggère que la correction initiale n’était pas efficace. Où les obtenir Il s’agit généralement d’un champ compteur de l’objet Service Request, incrémenté par une règle métier lorsque le statut change de manière appropriée. Il peut être nommé « ReopenCounter ». Exemples 0123
	Service du demandeur RequestorDepartment	Service de l’entreprise auquel appartient l’utilisateur ayant soumis la demande de service.
Description Cet attribut identifie le service du collaborateur ou du système à l’origine de la demande de service, par exemple « Ventes », « Finance » ou « Ressources humaines ». Il permet d’analyser la qualité du service et la demande dans les différentes entités de l’organisation. Il peut notamment révéler si certains services connaissent des délais de résolution plus longs ou soumettent un volume de demandes plus élevé. Pourquoi c’est important Il permet d’analyser la consommation et la qualité des services par unité opérationnelle, afin d’identifier les problèmes ou les tendances propres à chaque service. Où les obtenir Ces informations sont généralement récupérées dans le profil utilisateur du demandeur, associé à la Service Request. Le champ peut être « Department » dans l’objet « Profile.Employee ». Exemples FinanceVentesMarketingTechnologies de l'information

Obligatoire Recommandé Facultatif

Activités de gestion des demandes de service

Voici les étapes essentielles du processus et les jalons à enregistrer dans votre journal d’événements pour découvrir et analyser précisément le processus.

5 Recommandé 9 Facultatif

	Activité	Description
	Demande affectée à un agent	Un agent précis prend en charge la demande de service. Cette activité est généralement déduite lorsque le champ « Owner », qui désigne l’agent concerné, est renseigné ou mis à jour pour la première fois.
Pourquoi c’est important Cette activité marque la fin du temps d’attente initial ou du temps passé en file d’attente. Mesurer la durée qui la précède aide à identifier les problèmes d’allocation des ressources et alimente le Dashboard Agent Workload. Où les obtenir Cet événement est déduit du renseignement ou de la modification du champ « Owner » dans l’enregistrement Service Request, comme l’indique l’historique d’audit. Collecte Le premier horodatage auquel le champ « Owner » est renseigné avec le nom d’un agent après la création ou l’affectation à une équipe. Type d’événement inferred
	Demande affectée à une équipe	La demande de service est affectée à une équipe de support précise pour traitement. Cet événement est capturé en observant le renseignement ou la modification du champ « OwnerTeam » dans l’enregistrement Service Request.
Pourquoi c’est important Cet événement est essentiel pour analyser les performances au niveau des équipes, la répartition de la charge de travail et les délais de transfert entre équipes. Il aide à identifier les équipes qui constituent des goulots d’étranglement dans le processus. Où les obtenir Cet événement est suivi à partir des modifications du champ « OwnerTeam » dans l’historique d’audit ou le journal de la demande de service. Collecte Un événement de mise à jour du champ « OwnerTeam », généralement enregistré dans une piste d’audit. Type d’événement explicit
	Demande de service clôturée	La demande de service est officiellement clôturée et aucune action supplémentaire ne peut être effectuée. Cette clôture intervient souvent automatiquement après une période définie dans l’état « Resolved » et représente la conclusion finale du cycle de vie.
Pourquoi c’est important Cette activité constitue la fin définitive du processus. Le temps écoulé entre « Resolved » et « Closed » peut mettre en évidence des retards liés à la confirmation ou aux processus automatisés du système. Où les obtenir Cet événement est déduit d’une modification du champ « Status » de l’enregistrement Service Request vers « Closed », avec l’horodatage associé. Collecte La détection de la mise à jour du champ « Status » vers « Closed » dans l’historique d’audit. Type d’événement inferred
	Demande de service créée	Cette activité marque le début du cycle de vie d’une demande de service, lorsqu’une nouvelle demande est officiellement soumise et enregistrée dans Ivanti. L’événement est capturé lorsqu’un nouvel enregistrement est créé dans l’objet métier Service Request, ce qui génère un Service Request ID unique.
Pourquoi c’est important Il s’agit de l’événement de début principal du processus. L’analyse du temps écoulé entre ce point et la résolution est fondamentale pour mesurer le temps de cycle global et l’efficacité du processus. Où les obtenir Cet événement est capturé à partir de l’horodatage de création de l’enregistrement Service Request, par exemple dans le champ CreatedDateTime de l’objet métier ServiceReq. Collecte L’événement de création de l’enregistrement dans la table ServiceReq, identifié par son horodatage de création. Type d’événement explicit
	Demande de service résolue	La demande de service est considérée comme résolue et la solution a été fournie à l’utilisateur. Il s’agit d’une étape importante, capturée par un changement de statut vers « Resolved », qui déclenche souvent l’arrêt du compteur SLA.
Pourquoi c’est important Il s’agit du point final de référence pour mesurer le délai de résolution et le respect des SLA. La durée entre la création et cette activité constitue un KPI essentiel de la performance du processus. Où les obtenir Cet événement est déduit d’une modification du champ « Status » de l’enregistrement Service Request vers « Resolved », avec l’horodatage associé. Collecte La détection de la mise à jour du champ « Status » vers « Resolved » dans 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 désormais être traitée. Cet événement est enregistré lorsque le flux de travail d’approbation se termine avec succès et que l’état de la demande est modifié.
Pourquoi c’est important Cette activité marque une étape importante, en signalant la fin de la phase d’approbation et le début du traitement. Elle permet de mesurer l’efficacité du processus d’approbation lui-même. Où les obtenir Cet événement est déduit d’un changement de statut de « Waiting for Approval » à « Approved » ou « Fulfilled ». Il peut également s’agir d’un événement explicite enregistré dans l’objet métier FRS_Approval. Collecte Une modification du champ « Status » de l’enregistrement Service Request, qui passe 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 sa résolution. Il s’agit d’un autre état final, capturé par un changement de statut vers « Cancelled » ou « Withdrawn ».
Pourquoi c’est important Cette situation correspond à une interruption non standard du processus. L’analyse des raisons d’annulation des demandes peut révéler des problèmes liés au processus de demande lui-même ou à l’évolution des besoins des utilisateurs. Où les obtenir Cet événement est déduit d’une modification du champ « Status » de l’enregistrement Service Request vers « Cancelled ». Collecte La détection de la mise à jour du champ « Status » vers « Cancelled » dans l’historique d’audit. Type d’événement inferred
	Demande de service rouverte	Une demande de service précédemment résolue a été réactivée parce que le problème persiste ou que la solution n’a pas donné satisfaction. Cet événement est capturé lorsque le statut passe de « Resolved » à un état actif tel que « Active » ou « Assigned ».
Pourquoi c’est important Cette activité indique directement une reprise et une qualité insuffisante de la résolution dès le premier traitement. L’analyse des réouvertures aide à identifier les faiblesses du processus et à améliorer le KPI Service Request Rework Rate. Où les obtenir Cet événement est déduit de l’historique d’audit lorsque le champ « Status » passe de « Resolved » ou « Closed » à un statut actif. Collecte Un changement de statut, qui passe d’un état terminal (« Resolved », « Closed ») à un état ouvert (« Active », « Assigned »). Type d’événement inferred
	Demande de service traitée	Toutes les tâches nécessaires au traitement de la demande de service ont été réalisées par l’agent ou le système. Cet événement est capturé lorsque le statut passe à « Fulfilled », ce qui précède souvent le statut final « Resolved ».
Pourquoi c’est important Cette étape marque l’achèvement du travail technique ou procédural. Elle constitue un point essentiel pour mesurer le temps de traitement actif avant la confirmation finale et la clôture. Où les obtenir Cet événement est déduit d’une modification du champ « Status » de l’enregistrement Service Request vers « Fulfilled ». Collecte Une modification du champ « Status » vers « Fulfilled », détectée dans l’historique de l’enregistrement. Type d’événement inferred
	Demande soumise pour approbation	La demande de service a été soumise pour obtenir les approbations nécessaires avant son traitement. Cela est généralement déduit lorsque l’état de la demande passe à « Submitted » ou « Pending Approval », ce qui déclenche souvent un flux de travail d’approbation.
Pourquoi c’est important Le suivi de cette activité permet d’identifier les retards durant la phase d’approbation. Les temps d’attente prolongés à ce stade peuvent constituer un goulot d’étranglement important, avec un impact sur les délais globaux de résolution et la satisfaction des utilisateurs. Où les obtenir Cet événement est déduit d’un changement de statut de l’enregistrement Service Request, probablement vers un statut tel que « Submitted » ou « Waiting for Approval ». Il peut également provenir des objets métier FRS_Approval ou FRS_ApprovalVoteTracking. Collecte Une modification du champ « Status » de l’enregistrement Service Request vers un état indiquant que l’approbation est en attente. Type d’événement inferred
	Informations demandées à l’utilisateur	L’agent affecté a besoin d’informations supplémentaires de la part du demandeur pour poursuivre le traitement. Cet événement est capturé lorsque le statut de la demande passe à un état tel que « Waiting for Customer ».
Pourquoi c’est 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 essentiel pour l’analyse Information Request Impact Analysis et l’identification des possibilités d’amélioration du processus. Où les obtenir Cet événement est déduit d’un changement de statut de l’enregistrement Service Request vers un statut tel que « Waiting for Customer » ou « Pending ». Collecte La détection d’une modification du champ « Status » vers un état désigné comme « waiting on user ». Type d’événement inferred
	Informations fournies par l’utilisateur	Le demandeur a fourni les informations nécessaires, ce qui permet à l’agent de reprendre son travail. Cet événement est capturé lorsque la demande quitte le statut « Waiting for Customer » pour revenir à un état actif.
Pourquoi c’est important Cet événement clôt la boucle des demandes d’informations. Le temps écoulé entre la demande et la réception des informations constitue un élément important des retards du processus et des boucles de reprise. Où les obtenir Cet événement est déduit lorsque le champ « Status » de l’enregistrement Service Request passe de l’état « Waiting for Customer » à un état actif tel que « Active » ou « In Progress ». Collecte La détection d’un changement de statut, qui passe d’un état « waiting on user » à un état actif. Type d’événement inferred
	Prestataire externe mobilisé	Le traitement de la demande de service a été transféré à un prestataire externe ou à un tiers. Cet événement est généralement capturé lorsque le statut passe à « Waiting for 3rd Party » ou à un état similaire.
Pourquoi c’est important Cette activité est essentielle pour mesurer les performances des prestataires et leur impact sur le temps de cycle global. Elle permet d’analyser les retards qui leur sont liés et alimente le Dashboard External Vendor Activity Duration. Où les obtenir Cet événement est déduit d’un changement de statut de l’enregistrement Service Request vers un statut tel que « Waiting for 3rd Party » ou « Pending Vendor ». Collecte La détection d’une modification du champ « Status » vers un état désigné comme « waiting on vendor ». 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 capturé à partir du journal ou de l’historique d’audit qui suit les modifications au niveau des champs.
Pourquoi c’est important Le suivi des changements de priorité est essentiel pour le Prioritization Effectiveness Overview. Il permet de déterminer si les escalades sont correctement gérées et si la priorisation initiale est pertinente. Où les obtenir Il s’agit d’un événement explicite capturé dans l’historique d’audit de l’enregistrement Service Request, qui consigne les modifications du champ « Priority ». Collecte Un événement de mise à jour du champ « Priority », enregistré dans la piste d’audit du système. Type d’événement explicit

Recommandé Facultatif

Guides d'extraction

Comment extraire vos données d'Ivanti Service Manager

Étapes

Connectez-vous à Ivanti Service Manager avec un rôle disposant d'un accès en lecture aux demandes de service et à leur historique d'audit.
Accédez à l'espace de travail Service Request depuis le panneau de navigation principal.
Ce processus nécessite deux exports de données distincts, qui seront combinés ultérieurement. Le premier enregistre l'événement de création et les attributs principaux, tandis que le second contient l'historique détaillé des modifications.
Premier export (événements de création) : créez une nouvelle Saved Search sur l'objet métier ServiceReq. Définissez un filtre sur CreatedDateTime afin de sélectionner les demandes de service créées pendant la période d'analyse souhaitée, par exemple les six derniers mois.
Configurez les colonnes de la recherche de création pour 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, puis utilisez la fonction d'export de la grille, généralement représentée par une icône en forme de disque ou de flèche, pour exporter les données dans un fichier CSV. Nommez-le ServiceRequests.csv.
Second export (événements de l'historique d'audit) : créez une nouvelle Saved Search, cette fois sur l'objet métier FRS_data_audit_history, qui enregistre les modifications de champs.
Filtrez cette recherche pour ne conserver que les modifications liées aux demandes de service. Ajoutez un filtre dans lequel ParentObjectType est égal à 'ServiceReq'. Ajoutez également un filtre sur AuditDate couvrant la même période d'analyse que précédemment.
Configurez les colonnes de la recherche d'audit pour inclure ParentLink_RecID (pour relier les données à la demande de service), FieldName, OldValue, NewValue et AuditDate (pour EventTime). Exportez ces données dans 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 journal d'événements unique. Utilisez un outil de préparation des données tel que Power Query dans Excel, Python ou un outil de base de données pour effectuer les étapes suivantes :
- Chargez ServiceRequests.csv et AuditHistory.csv.
- Utilisez le fichier ServiceRequests.csv pour générer l'événement « Service Request Created » pour chaque demande.
- Utilisez le fichier AuditHistory.csv pour générer tous les autres événements. Faites correspondre les valeurs des colonnes FieldName et NewValue aux noms d'activités requis. Par exemple, si FieldName est 'Status' et NewValue est 'Resolved', définissez ActivityName sur 'Service Request Resolved'.
- Reliez les événements d'audit transformés aux données des demandes de service à l'aide de ParentLink_RecID dans le fichier d'audit et de RecId dans le fichier des demandes de service. Les attributs au niveau du dossier sont ainsi ajoutés à chaque événement.
- Combinez les événements « Created » et les événements issus de l'audit dans une table unique.
Formatez la table finale combinée avec les en-têtes de colonnes requis : ServiceRequestID, ActivityName, EventTime, SourceSystem, LastDataUpdate et les autres attributs recommandés. Vérifiez que tous les horodatages utilisent un format cohérent.
Enregistrez le journal d'événements final dans un fichier CSV unique, prêt à être importé.

Configuration

Objets métier : cette méthode nécessite un export depuis deux objets métier distincts : ServiceReq pour les données principales des demandes et FRS_data_audit_history pour les données d'événements.
Filtre sur la période : il est essentiel d'appliquer un filtre de dates aux deux exports afin de maîtriser le volume de données. Utilisez le champ CreatedDateTime sur ServiceReq et le champ AuditDate sur FRS_data_audit_history. Pour une première analyse, une période de 3 à 6 mois est recommandée.
Filtres clés de l'historique d'audit :
- ParentObjectType doit être filtré sur 'ServiceReq' afin de garantir que seules les modifications liées aux demandes de service sont extraites.
- Vous pouvez également filtrer FieldName pour ne conserver que les champs pertinents pour votre processus, tels que 'Status', 'Owner', 'OwnerTeam' et 'Priority', ce qui peut réduire considérablement la taille de l'export.
Prérequis : un compte utilisateur Ivanti Service Manager disposant des autorisations nécessaires pour créer des Saved Searches et exporter des données depuis les objets métier ServiceReq et FRS_data_audit_history est requis.
Considérations relatives aux performances : la table FRS_data_audit_history peut être très volumineuse. Un export sans filtre de dates suffisamment restrictif peut dégrader les performances de l'application Ivanti et entraîner un dépassement du délai d'attente. Si nécessaire, envisagez d'exporter les données par lots mensuels ou trimestriels plus petits.

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

Étapes

Prérequis et configuration : vérifiez que Python 3.6 ou une version ultérieure est installé sur votre système. Installez les bibliothèques nécessaires, requests pour effectuer les appels API et pandas pour manipuler les données, en exécutant pip install requests pandas. Demandez à l'administrateur Ivanti Service Manager une clé API disposant au minimum des autorisations de lecture sur les objets métier ServiceReq et FRS_Audit_ServiceReq.
Configuration du script : téléchargez le script Python fourni. Ouvrez-le dans un éditeur de texte ou un IDE et mettez à jour les variables d'espace réservé situées en haut du fichier : TENANT_URL, API_KEY, START_DATE et END_DATE, afin qu'elles correspondent à votre environnement Ivanti et à la période d'extraction souhaitée.
Exécution du script : exécutez le script depuis la ligne de commande avec python your_script_name.py. Le script affiche d'abord un message indiquant qu'il établit la connexion et s'authentifie auprès de l'API Ivanti.
Récupération des données des demandes de service : le script interroge d'abord l'objet métier ServiceReq pour récupérer toutes les demandes créées pendant la période indiquée. Il gère automatiquement la pagination de l'API afin de récupérer la liste complète des demandes et affiche l'avancement au fur et à mesure du chargement de chaque page.
Récupération de l'historique d'audit : pour chaque demande de service récupérée, le script exécute une seconde requête sur l'objet métier FRS_Audit_ServiceReq. Celle-ci récupère l'historique complet des modifications de champs pour la demande concernée, indispensable à la création du journal d'événements détaillé.
Génération de l'événement « Created » : lors du traitement de chaque demande de service, le script crée d'abord l'événement « Service Request Created ». L'horodatage de cet événement est directement extrait du champ CreatedDateTime de l'enregistrement de la demande.
Génération des événements à partir de la piste d'audit : le script parcourt ensuite les enregistrements de la piste d'audit pour chaque demande de service. Il analyse chaque enregistrement afin d'identifier les changements apportés à des champs clés tels que Status, OwnerTeam, Owner et Priority.
Correspondance entre les changements et les activités : une logique de correspondance prédéfinie dans le script convertit ces changements de champs en noms d'activités spécifiques. Par exemple, un changement du champ Status de 'Active' à 'Resolved' est enregistré comme l'activité 'Service Request Resolved'.
Construction du journal d'événements : tous les événements générés, depuis la création initiale jusqu'aux modifications ultérieures issues de la piste d'audit, sont regroupés dans une liste structurée. Chaque événement comprend l'identifiant de la demande de service, le nom de l'activité, l'horodatage et les autres attributs pertinents.
Transformation et formatage des données : la liste d'événements collectée est convertie en DataFrame Pandas. Le script vérifie que toutes les colonnes correspondent au schéma requis par ProcessMind, notamment ServiceRequestID, ActivityName et EventTime.
Export au format CSV : une fois toutes les demandes de service et leur historique 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 depuis lequel le script a été exécuté. Ce fichier est prêt à être importé.

Configuration

URL du point de terminaison de l'API : URL de base de l'API REST du 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 : clé API REST valide générée dans la console d'administration Ivanti. Cette clé doit être associée à un rôle disposant des autorisations de lecture sur les objets métier ServiceReq et FRS_Audit_ServiceReq.
Période : le script nécessite une START_DATE et une END_DATE au format 'YYYY-MM-DD'. Pour une première analyse, une période de 3 à 6 mois est recommandée afin de conserver un volume de données raisonnable tout en couvrant suffisamment de variantes du processus.
Taille des pages (TOP_COUNT) : cette variable du script définit le nombre d'enregistrements récupérés par appel API. La valeur par défaut est 500, ce qui offre un bon compromis entre performances et consommation mémoire. Vous pouvez l'adapter aux performances de votre serveur API.
Champs requis (SELECT_FIELDS_SR, SELECT_FIELDS_AUDIT) : le script précise les champs à récupérer depuis l'API afin de limiter la taille de la charge utile. Vérifiez que tous les champs nécessaires aux attributs requis et recommandés figurent 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()

Prêt à commencer ?

Tirez le meilleur parti de votre processus de gestion des demandes de service grâce à ce modèle de données détaillé. Commencez dès aujourd'hui à optimiser vos opérations.

Retour au guide d’amélioration Télécharger le modèle

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

Mettez fin aux traitements trop lents, réduisez la frustration des utilisateurs et atteignez un taux d'automatisation de 70 %.

Démarrer l'essai gratuit

Aucune carte bancaire requise, configuration en quelques minutes.

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 la gestion des demandes de service

Activités de gestion des demandes de service

Guides d'extraction

Export des données de Saved Search et de la grille Ivanti au format CSV

Étapes

Configuration

a Exemple de requête sql

Script Python utilisant l'API REST Ivanti

Étapes

Configuration

a Exemple de requête python

Prêt à commencer ?

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

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 la gestion des demandes de service

Activités de gestion des demandes de service

Guides d'extraction

Export des données de Saved Search et de la grille Ivanti au format CSV

Étapes

Configuration

a Exemple de requête sql

Script Python utilisant l'API REST Ivanti

Étapes

Configuration

a Exemple de requête python

Prêt à commencer ?

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

Nous attachons de l’importance à votre confidentialité