> 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 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 vous guide dans la collecte des données nécessaires au Process Mining de votre gestion des demandes de service. Il présente les principaux attributs à recueillir, les activités à suivre et des conseils pratiques pour extraire ces informations de votre système. Appuyez-vous sur cette ressource pour constituer un journal d’événements adapté à 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 ? Découvrez comment créer un journal d’événements pour le Process Mining.

Télécharger le modèle

Attributs de gestion des demandes de service

Voici les champs de données recommandés à inclure dans votre journal d’événements pour analyser en détail le processus de gestion des demandes de service.

5 Obligatoire 9 Recommandé 7 Facultatif

	Nom	Description
	Heure de l’événement EventTime	Horodatage indiquant le moment où une activité ou un événement précis s’est produit.
Description L’heure de l’événement, également appelée 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 indispensable pour remettre les événements dans le bon ordre et sert de base à toutes les analyses temporelles du process mining, notamment au calcul des temps de cycle, des temps d’attente et de la durée des activités. Pourquoi est-ce important ? Cet horodatage est indispensable pour ordonner les événements chronologiquement et calculer tous les indicateurs de durée, essentiels à l’analyse des performances. Où trouver ces données Cet horodatage figure dans les journaux d’audit, les entrées du 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	Identifiant unique de chaque demande de service.
Description L’identifiant de la demande de service distingue chaque demande soumise par un utilisateur ou un système. Il sert de fil conducteur entre tous les événements, de l’enregistrement initial à la clôture, et permet d’analyser le parcours complet de chaque demande. Pourquoi est-ce important ? Cet identifiant de cas essentiel 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ù trouver ces données Il s’agit de la clé primaire de l’objet métier Service Request, souvent nommée ServiceReqNumber dans la table ServiceReq. Exemples SR-0012345SR-0012346SR-0012347
	Nom de l’activité ActivityName	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 l’ordre et de la fréquence des activités est essentielle pour comprendre le flux du processus, repérer les goulots d’étranglement et détecter les écarts par rapport à la procédure standard. Pourquoi est-ce important ? Il définit les étapes de la carte de processus et permet de visualiser et d’analyser le flux, notamment pour repérer les reprises, les goulots d’étranglement et les écarts. Où trouver ces données Cet attribut est généralement établi à partir des changements de statut, des entrées du journal ou des descriptions d’événements du journal d’audit d’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	Horodatage de la dernière actualisation des données depuis le 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 renseigne sur leur fraîcheur et permet de connaître la période couverte par l’analyse ainsi que la date prévue de la prochaine mise à jour. Pourquoi est-ce important ? Il indique si les données sont à jour, une information essentielle pour prendre des décisions à partir des informations les plus récentes sur les performances du processus. Où trouver ces données Cette valeur est générée et ajoutée au jeu de données au moment de l’extraction. Exemples 2024-05-20T12:00:00Z2024-05-21T12:00:00Z
	Système source SourceSystem	Système d’où proviennent les données extraites.
Description Cet attribut indique l’origine des données du processus. Dans cette vue, sa valeur reste constante : toutes les données proviennent d’Ivanti Service Manager. Cette information est importante lorsque les données sont réunies depuis plusieurs systèmes, car elle permet d’en connaître clairement la provenance et le contexte. Pourquoi est-ce important ? Il précise la provenance des données et garantit que les analyses sont attribuées au bon système source, en particulier dans les environnements qui en utilisent plusieurs. Où trouver ces données Il s’agit généralement d’une valeur statique ajoutée lors de l’extraction pour indiquer l’origine du jeu de données. Exemples Ivanti Service Manager
	Agent affecté AssignedAgent	L’utilisateur ou l’agent chargé de traiter la demande de service.
Description L’agent affecté est la personne chargée de traiter la demande de service. Cet attribut permet d’analyser les activités à l’échelle individuelle, notamment pour évaluer les performances, équilibrer la charge de travail et repérer les besoins de formation. Le suivi des réaffectations entre agents est essentiel pour calculer des indicateurs comme le « nombre moyen de réaffectations par demande » et comprendre les inefficacités du processus. Pourquoi est-ce important ? Il permet d’analyser la charge de travail et les performances de chaque agent, ainsi que les schémas de réaffectation, qui peuvent révéler des problèmes de formation, de compétences ou d’orientation initiale. Où trouver ces données Cette information figure généralement dans un champ tel que « Owner » de l’objet Service Request. Elle peut changer à chaque réaffectation et doit être suivie dans le journal d’événements. Exemples Alice JohnsonBob WilliamsCharlie BrownDiana Prince
	Échéance du SLA SLADeadline	L’horodatage auquel la demande de service doit ê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 échéance 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 permet de mesurer le respect du SLA. Pourquoi est-ce important ? Elle sert de référence pour mesurer les performances réelles, calculer le taux de respect des SLA et repérer les demandes susceptibles de dépasser leur échéance. Où trouver ces données 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, comme « ResolutionTargetDateTime ». Exemples 2023-10-27T17:00:00Z2023-10-28T09:00:00Z2023-11-02T12:00:00Z
	Équipe affectée AssignedTeam	L’équipe ou le groupe d’assistance actuellement chargé de traiter la demande de service.
Description Cet attribut indique quelle équipe est chargée de traiter la demande de service à un moment donné. L’analyse des transferts entre équipes, du temps passé par chaque équipe et du volume de demandes traité par chacune permet de comprendre la répartition de la charge de travail, de repérer les goulots d’étranglement et d’évaluer les performances des équipes. Ces informations alimentent directement les Dashboards consacrés au respect des SLA et à la charge de travail des agents. Pourquoi est-ce important ? Il permet de suivre les responsabilités et les transferts, afin d’analyser les retards entre équipes, l’équilibre de la charge de travail et les équipes qui constituent des goulots d’étranglement. Où trouver ces données Cette information est généralement stockée dans un champ tel que « OwnerTeam » de l’objet Service Request ou dans des enregistrements d’affectation associés. Exemples Centre de services informatiqueExploitation du réseauAssistance RHGestion des installations
	Heure de fin de l’événement EventEndTime	L’horodatage qui indique quand une activité a été terminée.
Description 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 son heure de fin correspond au temps de traitement de cette activité. Cette mesure permet de repérer les étapes qui prennent le plus de temps et de cibler les inefficacités et les pistes d’amélioration. Pourquoi est-ce important ? Elle permet de calculer la durée de chaque activité, une mesure essentielle pour repérer les goulots d’étranglement et les tâches qui s’éternisent. Où trouver ces données Ce champ peut ne pas exister en tant que tel. Il correspond souvent à l’heure de début de l’activité suivante dans la séquence, pour le même dossier. 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.
Description Cet attribut, défini au niveau du dossier, indique l’horodatage final auquel le service a été fourni ou le problème résolu, avant la clôture officielle de la demande. Il constitue le point de référence principal pour calculer le temps de cycle 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 est-ce important ? Il définit le point final utilisé pour calculer le temps de cycle du processus principal, un indicateur clé de l’efficacité de la prestation de services. Où trouver ces données Champ d’horodatage spécifique de l’objet Service Request, souvent nommé « ResolvedDateTime » ou équivalent. 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.
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 » et « Critique ». Cet attribut est essentiel pour vérifier si le processus traite plus rapidement les demandes prioritaires. L’analyse compare souvent les temps de cycle et le respect des SLA selon le niveau de priorité, afin de s’assurer que les règles de priorisation sont appliquées comme prévu. Pourquoi est-ce important ? Cet attribut permet d’évaluer l’efficacité de la stratégie de priorisation et de vérifier que les demandes prioritaires sont résolues plus rapidement que les demandes de faible priorité. Où trouver ces données 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	Le 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 « Enregistrée », « En cours », « En attente », « Résolue » ou « Clôturée ». Les changements de statut définissent souvent les activités du journal de processus. L’analyse du temps passé dans chaque statut peut révéler des goulots d’étranglement, par exemple lorsque les demandes restent trop longtemps « En attente ». Pourquoi est-ce important ? Il donne un aperçu de l’état de la demande à un moment donné. Cette information est essentielle pour calculer le temps passé dans chaque état et repérer les blocages du processus. Où trouver ces données Champ standard de l’objet Service Request, généralement nommé « Status ». Exemples EnregistréeActifEn attente du clientSatisfaiteClôturée
	Statut du SLA SLAStatus	Indique si la demande de service a été résolue avant l’échéance de son SLA.
Description Cet attribut calculé indique pour chaque demande de service si le SLA a été « Respecté » ou « Dépassé », selon que le délai de résolution a été respecté ou non. Il constitue la base du Dashboard « Performances de respect des SLA » et de l’indicateur « Taux de respect des accords de niveau de service ». La logique compare ResolutionDateTime à SLADeadline pour chaque dossier. Pourquoi est-ce important ? Il mesure directement le respect des engagements de service, un élément essentiel pour évaluer la qualité du service et préserver la confiance des utilisateurs. Où trouver ces données Le statut est calculé en comparant « ResolutionDateTime » à « SLADeadline ». Si ResolutionDateTime <= SLADeadline, le statut est « Respecté » ; sinon, il est « Dépassé ». Exemples RespectéDépassé
	Type de demande de service ServiceRequestType	La classification ou la catégorie de la demande de service.
Description Cet attribut classe les demandes de service, par exemple « Demande de matériel », « Installation de logiciel » ou « Réinitialisation de mot de passe ». Il constitue un axe d’analyse important pour comparer les performances des processus, les temps de cycle et le respect des SLA selon le type de service. Comprendre ces différences aide à adapter les améliorations des processus et à mieux répartir les ressources. Pourquoi est-ce important ? L’analyse du processus par type de demande permet de repérer si certaines demandes sont davantage sujettes aux retards, aux reprises ou aux dépassements de SLA. Où trouver ces données 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 précis, comme « SvcReqTmplLink_Category ». Exemples Nouvelle demande de matérielAccès à un logicielModification de compteDemande de renseignements
	Canal Channel	La méthode ou le canal utilisé pour soumettre la demande de service.
Description Le canal indique comment la demande de service a été créée, par exemple via le portail libre-service, par e-mail ou 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 lesquels sont les plus efficaces et lesquels nécessitent des améliorations du processus ou une formation des utilisateurs. Pourquoi est-ce important ? Il aide à comprendre le comportement des utilisateurs et l’efficacité des canaux, afin d’orienter les décisions sur la stratégie de prestation de services et les possibilités d’automatisation. Où trouver ces données Cette information est souvent stockée dans un champ de l’objet Service Request, tel que « Source » ou « CreatedBy ». Exemples Libre-serviceE-mailTéléphoneSaisie directe
	Catégorie de résolution ResolutionCategory	La classification de la solution apportée à la demande de service.
Description La catégorie de résolution permet de classer de manière structurée la façon dont une demande de service a été résolue. Cette classification est souvent hiérarchique, par exemple avec une catégorie et une sous-catégorie, et facilite l’analyse des causes profondes ainsi que le suivi des tendances. Elle peut notamment faire ressortir des problèmes récurrents ou des types courants d’interventions, qui pourront servir à améliorer les services ou à créer des articles dans la base de connaissances. Pourquoi est-ce important ? Elle permet de comprendre la nature des résolutions et de repérer les problèmes fréquents, les possibilités d’amélioration des services et les tâches susceptibles d’être automatisées. Où trouver ces données Cette information est souvent stockée dans des champs de catégorisation renseignés lors de la résolution, comme « 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é
	Nom du fournisseur VendorName	Le nom du fournisseur externe qui a participé à la résolution de la demande.
Description Cet attribut identifie le fournisseur tiers chargé d’aider à traiter une demande de service ou de la prendre en charge. Il est essentiel au Dashboard « Durée des activités des fournisseurs externes », qui permet de mesurer et de comparer les performances des différents fournisseurs. Son suivi facilite la gestion des relations avec les fournisseurs et aide à repérer les goulots d’étranglement liés à des dépendances externes. Pourquoi est-ce important ? Il permet d’analyser les performances des tiers et leur incidence sur les délais globaux de résolution des demandes de service, afin d’appuyer la gestion des fournisseurs. Où trouver ces données Cette information peut figurer dans un champ d’un objet Task associé à la demande de service, ou dans un champ spécifique de la demande elle-même si un fournisseur lui est affecté. Exemples Assistance DellConseil OracleMicrosoft Premiernull
	Nombre d’affectations AssignmentCount	Le nombre total de fois où une demande de service a été affectée ou réaffectée.
Description Cette métrique calculée compte, pour chaque demande de service, les activités liées à une affectation, par exemple « Affectée à une équipe » ou « Affectée à un agent ». Un nombre élevé de réaffectations, parfois appelé « ping-pong de tickets », révèle des problèmes d’orientation, l’absence de résolution dès le premier contact ou un manque de clarté dans la répartition des responsabilités entre équipes. Cet attribut est essentiel au calcul de l’indicateur « Nombre moyen de réaffectations par demande ». Pourquoi est-ce important ? Il quantifie les transferts inefficaces et les problèmes d’orientation. Un nombre élevé indique souvent des délais de résolution prolongés et une frustration des utilisateurs. Où trouver ces données Cette valeur est calculée lors de la préparation des données, en comptant les occurrences d’activités liées aux affectations pour chaque ServiceRequestID unique. Exemples 12345
	Nombre de réouvertures ReopenCount	Le 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 « Clôturée » à l’état « Actif ». Un nombre élevé de réouvertures indique souvent une résolution initiale de mauvaise qualité, une solution incomplète ou un problème récurrent. Cet attribut contribue directement au calcul de l’indicateur « Taux de reprises des demandes de service ». Pourquoi est-ce important ? Il mesure directement les reprises et constitue un indicateur clé de la qualité des résolutions. Un nombre élevé suggère que la première solution n’a pas été efficace. Où trouver ces données 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
	Reprise IsRework	Indicateur booléen précisant si la demande de service a donné lieu à des reprises.
Description Cet indicateur calculé prend la valeur true si une demande de service présente des signes de reprise, par exemple si elle est rouverte après sa résolution ou si certaines activités sont répétées en boucle. Il simplifie le calcul de l’indicateur « Taux de reprises des demandes de service » et permet de filtrer les instances de processus inefficaces dans des Dashboards comme « Flux de reprises et de réaffectations ». Pourquoi est-ce important ? Il permet de repérer et de quantifier facilement les demandes qui nécessitent un travail supplémentaire imprévu, et met en évidence les problèmes de qualité et d’efficacité. Où trouver ces données Cet indicateur est calculé à partir des données. La logique peut s’appuyer sur la valeur de l’attribut « ReopenCount », si elle est supérieure à zéro, ou détecter des séquences d’activités précises, comme plusieurs événements « Assigned to Agent ». Exemples truefalse
	Service du demandeur RequestorDepartment	Le service de l’organisation auquel appartient l’utilisateur qui a soumis la demande de service.
Description Cet attribut indique le service de l’employé ou du système à l’origine de la demande de service, par exemple « Ventes », « Finance » ou « Ressources humaines ». Il permet d’analyser la qualité et la demande de services dans les différentes entités de l’organisation. Vous pouvez ainsi repérer les services qui connaissent des délais de résolution plus longs ou soumettent davantage de demandes. Pourquoi est-ce important ? Il permet d’analyser la consommation et la qualité des services par unité opérationnelle, et de repérer les problèmes ou tendances propres à certains services. Où trouver ces données Cette information provient généralement du profil utilisateur du demandeur, associé à la demande de service. 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 et jalons essentiels à consigner 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 du premier renseignement ou de la première mise à jour du champ « Owner », qui désigne l’agent responsable.
Pourquoi est-ce important ? Cette étape marque la fin de l’attente initiale ou du temps passé en file d’attente. Mesurer le délai qui la précède aide à repérer les problèmes de répartition des ressources et alimente le Dashboard de charge de travail des agents. Où trouver ces données Cet événement est déduit du renseignement ou de la modification du champ « Owner » dans l’enregistrement Service Request, comme le montre l’historique d’audit. Données à recueillir Le premier horodatage auquel le champ « Owner » est renseigné avec le nom d’un agent, après la création de la demande ou son affectation à une équipe. Type d’événement inferred
	Demande affectée à une équipe	La demande de service est affectée à une équipe d’assistance précise. Cette affectation est repérée lorsque le champ « OwnerTeam » de l’enregistrement Service Request est renseigné ou modifié.
Pourquoi est-ce important ? Cet événement est important pour analyser les performances des équipes, la répartition de la charge de travail et les délais de transfert entre équipes. Il aide à repérer les équipes qui constituent des goulots d’étranglement. Où trouver ces données L’événement est repéré à partir des modifications du champ « OwnerTeam » dans l’historique d’audit ou le journal de la demande de service. Données à recueillir Un événement de mise à jour du champ « OwnerTeam », généralement consigné 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 autre action ne peut être entreprise. La clôture intervient souvent automatiquement après une durée définie au statut « Resolved » et marque la fin du cycle de vie.
Pourquoi est-ce important ? Cette activité marque la fin définitive du processus. Le délai entre « Resolved » et « Closed » peut révéler des retards de confirmation ou liés aux traitements automatiques du système. Où trouver ces données Cet événement est déduit du passage du champ « Status » de l’enregistrement Service Request à « Closed », ainsi que de l’horodatage correspondant. Données à recueillir Détection, dans l’historique d’audit, du passage du champ « Status » à « Closed ». 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é à la création d’un nouvel enregistrement dans l’objet métier Service Request, qui génère un identifiant unique.
Pourquoi est-ce important ? Il s’agit de l’événement de début principal du processus. Mesurer le temps écoulé entre ce point et la résolution est essentiel pour calculer le temps de cycle global et évaluer l’efficacité du processus. Où trouver ces données Cet événement est repéré à partir de l’horodatage de création de l’enregistrement Service Request, par exemple le champ CreatedDateTime de l’objet métier ServiceReq. Données à recueillir 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é communiquée à l’utilisateur. Cette étape importante est repérée lorsque le statut passe à « Resolved », ce qui arrête souvent le décompte du SLA.
Pourquoi est-ce important ? Cette étape marque la fin du délai de résolution et permet d’évaluer le respect du SLA. Le temps écoulé entre la création de la demande et cette activité constitue un indicateur clé de la performance du processus. Où trouver ces données Cet événement est déduit du passage du champ « Status » de l’enregistrement Service Request à « Resolved », ainsi que de l’horodatage correspondant. Données à recueillir Détection, dans l’historique d’audit, du passage du champ « Status » à « Resolved ». Type d’événement inferred
	Demande approuvée	La demande de service a reçu toutes les approbations nécessaires et peut passer à l’étape de traitement. Cet événement est enregistré lorsque le flux de travail d’approbation se termine avec succès et que le statut de la demande change.
Pourquoi est-ce important ? Cette activité marque une étape importante : la phase d’approbation est terminée et le traitement peut commencer. Elle permet de mesurer l’efficacité du processus d’approbation. Où trouver ces données Cet événement est déduit du passage du statut de « Waiting for Approval » à « Approved » ou « Fulfilled ». Il peut également être enregistré explicitement dans l’objet métier FRS_Approval. Données à recueillir Le champ « Status » de l’enregistrement Service Request passe d’un statut d’approbation à un statut actif. Type d’événement inferred
	Demande de service annulée	L’utilisateur ou un agent a annulé la demande de service avant sa résolution. Cet état final alternatif est repéré lorsque le statut passe à « Cancelled » ou « Withdrawn ».
Pourquoi est-ce important ? Cette activité correspond à une fin de processus inhabituelle. L’analyse des motifs d’annulation peut révéler des problèmes dans le processus de demande ou une évolution des besoins des utilisateurs. Où trouver ces données Cet événement est déduit du passage du champ « Status » de l’enregistrement Service Request à « Cancelled ». Données à recueillir Détection, dans l’historique d’audit, du passage du champ « Status » à « Cancelled ». 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 repéré lorsque le statut passe de « Resolved » à un statut actif comme « Active » ou « Assigned ».
Pourquoi est-ce important ? Cette activité indique directement une reprise et une résolution insuffisante dès la première intervention. L’analyse des réouvertures aide à repérer les faiblesses du processus et à améliorer l’indicateur de taux de reprise des demandes de service. Où trouver ces données Cet événement est déduit de l’historique d’audit lorsque le champ « Status » passe de « Resolved » ou « Closed » à un statut actif. Données à recueillir Le statut passe d’un état final (« Resolved », « Closed ») à un état ouvert (« Active », « Assigned »). Type d’événement inferred
	Demande de service traitée	L’agent ou le système a terminé toutes les tâches nécessaires au traitement de la demande de service. Cet événement est repéré lorsque le statut passe à « Fulfilled », souvent avant le statut final « Resolved ».
Pourquoi est-ce important ? Cette étape marque la fin du travail technique ou procédural. Elle permet de mesurer le temps de traitement actif avant la confirmation finale et la clôture. Où trouver ces données Cet événement est déduit du passage du champ « Status » de l’enregistrement Service Request à « Fulfilled ». Données à recueillir Le passage du champ « Status » à « Fulfilled », repéré dans l’historique de l’enregistrement. Type d’événement inferred
	Demande soumise pour approbation	La demande de service a été soumise aux approbateurs concernés avant son traitement. Cet événement est généralement déduit du passage du statut de la demande à « Submitted » ou « Pending Approval », qui déclenche souvent un flux de travail d’approbation.
Pourquoi est-ce important ? Le suivi de cette activité permet de repérer les retards pendant la phase d’approbation. Une attente prolongée à cette étape peut constituer un goulot d’étranglement important et allonger les délais de résolution, au détriment de la satisfaction des utilisateurs. Où trouver ces données Cet événement est déduit d’un changement de statut de l’enregistrement Service Request, probablement vers « Submitted » ou « Waiting for Approval ». Il peut également provenir des objets métier FRS_Approval ou FRS_ApprovalVoteTracking. Données à recueillir Le champ « Status » de l’enregistrement Service Request passe à un statut 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 traiter la demande. Cet événement est repéré lorsque le statut de la demande passe, par exemple, à « Waiting for Customer ».
Pourquoi est-ce important ? Cette activité met en évidence les retards dus à des informations initiales incomplètes. En suivre la fréquence et la durée est essentiel pour l’analyse de l’impact des demandes d’informations et pour repérer les possibilités d’amélioration du processus. Où trouver ces données Cet événement est déduit du passage du statut de l’enregistrement Service Request à « Waiting for Customer » ou « Pending », par exemple. Données à recueillir Détection du passage du champ « Status » à un statut indiquant que l’on attend une réponse de l’utilisateur. 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 le traitement. Cet événement est repéré lorsque la demande quitte le statut « Waiting for Customer » pour revenir à un statut actif.
Pourquoi est-ce important ? Cet événement clôt la demande d’informations. Le délai entre la demande et la réception des informations contribue aux retards du processus et aux boucles de reprise. Où trouver ces données Cet événement est déduit du passage du champ « Status » de l’enregistrement Service Request de « Waiting for Customer » à un statut actif, comme « Active » ou « In Progress ». Données à recueillir Détection du passage d’un statut indiquant que l’on attend une réponse de l’utilisateur à un statut actif. Type d’événement inferred
	Prestataire externe sollicité	Le traitement de la demande de service a été confié à un prestataire externe ou à un tiers. Cet événement est généralement repéré lorsque le statut passe à « Waiting for 3rd Party » ou à un statut similaire.
Pourquoi est-ce important ? Cette activité est essentielle pour mesurer les performances du prestataire et leur incidence sur le temps de cycle global. Elle permet d’analyser les retards qui lui sont imputables et alimente le Dashboard de durée des activités des prestataires externes. Où trouver ces données Cet événement est déduit du passage du statut de l’enregistrement Service Request à « Waiting for 3rd Party » ou « Pending Vendor », par exemple. Données à recueillir Détection du passage du champ « Status » à un statut indiquant que l’on attend une intervention du prestataire. Type d’événement inferred
	Priorité modifiée	La priorité de la demande de service a été modifiée après sa création. Cet événement est repéré dans le journal ou l’historique d’audit, qui consigne les modifications apportées aux champs.
Pourquoi est-ce important ? Le suivi des changements de priorité est essentiel pour le Dashboard de suivi de l’efficacité de la priorisation. Il permet de vérifier si les escalades sont correctement gérées et si la priorité initiale est adaptée. Où trouver ces données Cet événement explicite est extrait de l’historique d’audit de l’enregistrement Service Request, qui consigne les modifications du champ « Priority ». Données à recueillir Un événement de mise à jour du champ « Priority », consigné 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.
Dans le panneau de navigation principal, ouvrez l’espace de travail des demandes de service.
Cette méthode nécessite deux exportations distinctes, à combiner ensuite à l’aide d’un outil externe. La première contient l’événement de création et les attributs principaux ; la seconde, l’historique détaillé des modifications.
Première exportation (événements de création) : créez une recherche enregistrée sur l’objet métier ServiceReq. Ajoutez un filtre sur CreatedDateTime pour 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 sur les créations pour inclure RecId, ServiceReqNumber (pour ServiceRequestID), CreatedDateTime (pour EventTime), SvcReqTmplLink_Category (pour ServiceRequestType), OwnerTeam, Owner, Priority, Status, ResolutionDateTime et TargetDateTime (pour SLADeadline).
Lancez la recherche, puis utilisez la fonction d’exportation de la grille, généralement représentée par une icône de disque ou de flèche, pour exporter les données dans 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 consigne les modifications des champs.
Filtrez cette recherche pour ne conserver que les modifications liées aux demandes de service. Ajoutez un filtre où ParentObjectType est égal à 'ServiceReq'. Filtrez également AuditDate sur la même période d’analyse que précédemment.
Configurez les colonnes de la recherche d’audit pour inclure ParentLink_RecID (pour établir le lien avec la demande de service), FieldName, OldValue, NewValue et AuditDate (pour EventTime). Exportez ces données dans un deuxième fichier CSV nommé AuditHistory.csv.
Transformation et combinaison des données : combinez et remodelez les fichiers CSV exportés pour obtenir un journal d’événements unique. Utilisez un outil de préparation des données, comme Power Query dans Excel, Python ou un outil de base de données, pour effectuer les opérations suivantes :
- Chargez les fichiers ServiceRequests.csv et AuditHistory.csv.
- À partir du fichier ServiceRequests.csv, générez l’événement 'Service Request Created' pour chaque demande.
- À partir du fichier AuditHistory.csv, générez tous les autres événements. Associez les valeurs des colonnes FieldName et NewValue aux noms d’activité requis. Par exemple, si FieldName vaut 'Status' et NewValue vaut 'Resolved', définissez ActivityName sur 'Service Request Resolved'.
- Reliez les événements d’audit transformés aux données des demandes de service en utilisant ParentLink_RecID du fichier d’audit et RecId du fichier des demandes. Vous ajouterez ainsi les attributs associés à chaque cas à tous les événements.
- Regroupez les événements de création et ceux issus de l’audit dans une seule table.
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. Veillez à utiliser un format cohérent pour tous les horodatages.
Enregistrez le journal d’événements final dans un seul fichier CSV, prêt à être importé.

Configuration

Objets métier : cette méthode nécessite d’exporter les données de deux objets métier : ServiceReq pour les données principales des demandes et FRS_data_audit_history pour les événements.
Filtre de période : il est essentiel d’appliquer un filtre de période aux deux exportations afin de maîtriser le volume de données. Utilisez le champ CreatedDateTime de ServiceReq et le champ AuditDate de FRS_data_audit_history. Pour une première analyse, une période de 3 à 6 mois est recommandée.
Filtres clés pour l’historique d’audit :
- Filtrez ParentObjectType sur 'ServiceReq' pour ne récupérer que les modifications liées aux demandes de service.
- Vous pouvez aussi filtrer FieldName afin de ne conserver que les champs utiles à votre processus, comme 'Status', 'Owner', 'OwnerTeam' et 'Priority'. Cela peut réduire considérablement la taille de l’exportation.
Prérequis : vous devez disposer d’un compte utilisateur Ivanti Service Manager autorisé à créer des recherches enregistrées et à exporter les données des objets métier ServiceReq et FRS_data_audit_history.
Performances : la table FRS_data_audit_history peut être très volumineuse. Sans filtre de période suffisamment restrictif, l’exportation peut ralentir Ivanti et entraîner un dépassement du délai d’attente. Si nécessaire, exportez les données par lots mensuels ou trimestriels.

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 les appels API et pandas pour la manipulation des données, en exécutant pip install requests pandas. Demandez à l’administrateur Ivanti Service Manager une clé API disposant au minimum d’autorisations en lecture sur les objets métier ServiceReq et FRS_Audit_ServiceReq.
Configurer le script : téléchargez le script Python fourni. Ouvrez-le dans un éditeur de texte ou un IDE, puis remplacez les valeurs fictives en haut du fichier par les paramètres de votre environnement Ivanti et de la période d’extraction souhaitée : TENANT_URL, API_KEY, START_DATE et END_DATE.
Exécuter le script : lancez-le depuis la ligne de commande avec python your_script_name.py. Le script affiche d’abord un message indiquant qu’il se connecte à l’API Ivanti et s’y authentifie.
Récupérer les 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 spécifiée. Il gère automatiquement la pagination de l’API afin de récupérer la liste complète et affiche l’avancement à mesure qu’il traite chaque page.
Récupérer l’historique d’audit : pour chaque demande de service récupérée, le script lance une deuxième requête sur l’objet métier FRS_Audit_ServiceReq. Il obtient ainsi l’historique complet des modifications de champs pour cette demande, indispensable à la création d’un journal d’événements détaillé.
Générer l’événement 'Created' : lors du traitement de chaque demande, le script commence par créer l’événement 'Service Request Created'. Son horodatage provient directement du champ CreatedDateTime de l’enregistrement de la demande.
Générer les événements à partir de la piste d’audit : le script parcourt ensuite les enregistrements de la piste d’audit de chaque demande. Il repère les modifications apportées à des champs clés comme Status, OwnerTeam, Owner et Priority.
Associer les modifications aux activités : une logique d’association prédéfinie dans le script convertit ces modifications de champs en noms d’activité précis. Par exemple, une modification du champ Status, de 'Active' à 'Resolved', est consignée comme une activité 'Service Request Resolved'.
Constituer le journal d’événements : tous les événements générés, de la création initiale 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 recueillis est convertie en DataFrame Pandas. Le script vérifie que les colonnes correspondent au schéma requis par ProcessMind, notamment ServiceRequestID, ActivityName et EventTime.
Exporter 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 répertoire 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 de votre environnement Ivanti Service Manager. Renseignez-la 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. Elle doit être associée à un rôle autorisé à lire les objets métier ServiceReq et FRS_Audit_ServiceReq.
Période : le script nécessite des valeurs START_DATE et 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 définit le nombre d’enregistrements récupérés par appel API. La valeur par défaut est 500, un bon compromis entre performances 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 précise les champs à récupérer via l’API afin de limiter la taille des données transmises. Vérifiez que ces listes contiennent tous les champs nécessaires aux attributs requis et recommandés.

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 ?

Ce modèle de données détaillé vous aide à mieux comprendre votre processus de gestion des demandes de service. Commencez dès aujourd’hui à optimiser vos opérations.

Retour au guide d’amélioration

Télécharger le modèle

Optimisez dès aujourd’hui la gestion de vos demandes de service

Réduisez les retards de traitement, la frustration des utilisateurs et atteignez un taux d’automatisation de 70 %.

Démarrez 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 gestion des demandes de service

Activités de gestion des demandes de service

Guides d’extraction

Exportation au format CSV des recherches enregistrées et des données de grille Ivanti

Étapes

Configuration

Exemple de requête sql

Script Python utilisant l’API REST Ivanti

Étapes

Configuration

Exemple de requête python

Prêt à commencer ?

Optimisez dès aujourd’hui la gestion de vos 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 gestion des demandes de service

Activités de gestion des demandes de service

Guides d’extraction

Exportation au format CSV des recherches enregistrées et des données de grille Ivanti

Étapes

Configuration

Exemple de requête sql

Script Python utilisant l’API REST Ivanti

Étapes

Configuration

Exemple de requête python

Prêt à commencer ?

Optimisez dès aujourd’hui la gestion de vos demandes de service

Prêt à commencer ?