> Amélioration continue des processus > Gestion des incidents > Gestion des problèmes dans ServiceNow > Modèle de données

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

Gestion des problèmes dans ServiceNow

← Retour au guide d’amélioration

Attributs de la Gestion des incidents (19) Activités de la Gestion des incidents (13) Guides d’extraction (2)

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

Ce modèle fournit un guide complet pour recueillir les données nécessaires à l’analyse et à l’optimisation de votre processus de gestion des incidents. Il précise les attributs de données essentiels à collecter et les activités clés à suivre, tout en donnant des indications pratiques sur l’extraction de ces informations depuis votre système source. Utilisez cette ressource pour constituer un journal d’événements complet, adapté à une analyse et à une amélioration approfondies du processus.

Attributs recommandés à collecter
Activités clés à suivre
Guide d’extraction pour la Gestion des problèmes dans ServiceNow

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 incidents

Voici les champs de données recommandés à inclure dans votre journal d’événements pour réaliser une analyse complète de votre processus de Gestion des incidents.

5 Obligatoire 4 Recommandé 10 Facultatif

	Nom	Description
	Heure de l’événement EventTime	Horodatage précis indiquant le moment où l’activité s’est produite.
Description L’heure de l’événement, souvent appelée horodatage, enregistre la date et l’heure exactes auxquelles une activité a été terminée ou un changement d’état s’est produit. Dans ServiceNow, cette information est généralement enregistrée dans le champ sys_updated_on pour chaque modification consignée dans la piste d’audit. Cet attribut est essentiel pour ordonner correctement les événements et réaliser toutes les analyses fondées sur le temps. Il sert à calculer les durées de cycle, les temps d’attente et les délais entre les activités, qui sont indispensables pour identifier les goulots d’étranglement, mesurer la performance par rapport aux SLA et comprendre l’efficacité du processus. La précision de ces horodatages est déterminante pour la fiabilité de toute mesure fondée sur la durée. Pourquoi c’est important Cet horodatage ordonne chronologiquement toutes les activités et permet de calculer les indicateurs fondés sur la durée, tels que les temps de cycle et les goulots d’étranglement. Où les obtenir Table sys_audit de ServiceNow, champ sys_created_on ou champ sys_updated_on de la table incident pour le dernier état. Exemples 2023-04-15T10:05:21Z2023-04-15T11:22:00Z2023-04-16T09:00:30Z
	ID de l’incident IncidentId	Identifiant unique de chaque enregistrement d’incident, utilisé comme clé principale pour suivre l’ensemble du cycle de vie.
Description L’ID de l’incident est le numéro de référence unique attribué à chaque incident signalé dans ServiceNow. Il constitue l’identifiant principal du dossier et relie toutes les activités, mises à jour et communications associées, de la création de l’incident à sa clôture. Dans une analyse de Process Mining, cet ID est fondamental. Il permet à l’outil de reconstituer la séquence des événements pour chaque dossier, ce qui constitue la base de la découverte des cartes de processus, de l’analyse des variantes et du calcul des durées de bout en bout. Sans ID d’incident unique pour chaque dossier, il serait impossible de retracer le parcours d’un incident tout au long du processus de résolution. Pourquoi c’est important Il s’agit de l’ID de dossier essentiel qui relie tous les événements du cycle de vie d’un incident et rend possible l’analyse du processus de bout en bout. Où les obtenir Table des incidents ServiceNow, numéro de champ. Exemples INC0010001INC0010045INC0010239
	Nom de l’activité ActivityName	Nom de l’événement ou de la tâche précise survenu à un moment donné du cycle de vie de l’incident.
Description Le nom de l’activité décrit une étape précise ou un changement d’état dans le processus de Gestion des incidents, par exemple « Incident Created », « Assigned To Agent » ou « Incident Closed ». Ces données sont généralement dérivées des modifications apportées aux champs clés de l’incident, tels que « State » ou « Assignment Group », ou d’entrées spécifiques du journal. Cet attribut est essentiel pour construire la carte de processus. Il définit les nœuds du graphe de processus et permet aux analystes de visualiser le parcours des incidents, d’identifier les chemins fréquents, de repérer les goulots d’étranglement entre les activités et d’analyser les variantes du processus. Le niveau de détail et la précision des noms d’activités influencent directement la qualité de l’analyse du processus. Pourquoi c’est important Il définit les étapes de la carte de processus, qui constitue le fondement de toute analyse et visualisation en Process Mining. Où les obtenir Il s’agit d’un attribut dérivé, généralement généré par la logique de transformation des données à partir des modifications de champs tels que state, assignment_group et assigned_to dans les tables sys_audit ou incident. Exemples Incident crééGroupe d’affectation modifiéRésolution proposéeIncident clôturé
	Dernière mise à jour des données LastDataUpdate	Horodatage indiquant le moment où les données de cet enregistrement ont été actualisées pour la dernière fois à partir du système source.
Description Cet attribut enregistre la date et l’heure de la dernière extraction ou mise à jour des données depuis ServiceNow. Il s’agit d’un champ de métadonnées qui indique la fraîcheur des données analysées, et non d’un événement du processus lui-même. Cette information est essentielle pour évaluer l’actualité de l’analyse. Elle indique aux utilisateurs dans quelle mesure les données sont récentes, ce qui est important pour les Dashboards opérationnels et les décisions fondées sur les événements les plus récents. Elle aide également à définir les attentes concernant la pertinence et l’actualité des données. Pourquoi c’est important Il informe les utilisateurs de la fraîcheur des données, un élément essentiel pour garantir la pertinence et la précision de l’analyse. Où les obtenir Cet horodatage est généré et renseigné par l’outil ou le processus d’extraction des données au moment du chargement. Exemples 2023-10-27T02:00:00Z2023-10-28T02:00:00Z
	Système source SourceSystem	Système à partir duquel ces données ont été extraites.
Description Cet attribut identifie l’origine des données relatives aux incidents, qui est ici ServiceNow Problem Management. Il s’agit généralement d’une valeur statique ajoutée lors du processus d’extraction et de transformation des données. Dans les environnements où les données de plusieurs systèmes peuvent être combinées pour l’analyse, ce champ est essentiel pour assurer la traçabilité et la séparation des données. Il garantit que les indicateurs et les processus sont analysés dans le bon contexte et permet aux analystes de comparer les processus entre différents systèmes sources. Pourquoi c’est important Il fournit le contexte essentiel sur l’origine des données, garantit leur traçabilité et permet une interprétation correcte dans les environnements multisystèmes. Où les obtenir Il s’agit généralement d’une valeur statique ajoutée lors du processus d’extraction des données. Exemples Gestion des problèmes dans ServiceNowServiceNow
	Affecté à AssignedTo	Utilisateur ou agent actuellement chargé de traiter l’incident.
Description Cet attribut identifie l’agent du support précisément responsable de l’incident à un moment donné. Cette information est essentielle pour comprendre la répartition de la charge de travail, la performance des agents et les transferts entre personnes. Dans l’analyse, « Assigned To » aide à visualiser l’allocation des ressources et à repérer les agents surchargés. Il est également utilisé dans le Dashboard « Transferts et réaffectations » pour suivre le nombre de changements de responsable d’un incident, ce qui peut révéler une inefficacité ou des lacunes en matière de connaissances. L’analyse des délais de résolution par agent peut aussi mettre en évidence les meilleurs résultats ou les besoins de formation complémentaire. Pourquoi c’est important Il permet d’analyser la charge de travail, la performance et les transferts individuels des agents, des éléments essentiels pour comprendre l’efficacité des ressources. Où les obtenir Table des incidents ServiceNow, champ assigned_to. Exemples Beth AnglinDavid LooHoward Johnson
	État de l’incident IncidentState	État actuel de l’incident dans son cycle de vie.
Description L’état de l’incident indique son étape actuelle, par exemple « New », « In Progress », « On Hold » ou « Resolved ». Les changements d’état constituent souvent la principale source de génération des activités dans l’Event Log utilisé pour le Process Mining. L’analyse du temps passé dans chaque état est un moyen efficace d’identifier les goulots d’étranglement. Par exemple, une longue durée dans l’état « On Hold » peut indiquer une dépendance à des facteurs externes ou à des utilisateurs. La séquence des changements d’état constitue également la base de la carte de processus et montre comment les incidents progressent vers leur résolution. Pourquoi c’est important Il suit l’avancement de l’incident et est essentiel pour analyser le temps passé aux différentes étapes et identifier les goulots d’étranglement du processus. Où les obtenir Table des incidents ServiceNow, champ incident_state ou state. Exemples NouveauEn coursEn attente d’informations de l’utilisateurRésoluFermé
	Groupe d’affectation AssignmentGroup	Équipe ou groupe de support responsable du traitement de l’incident.
Description Le groupe d’affectation représente l’équipe d’agents chargée de résoudre l’incident. Les incidents sont souvent orientés entre différents groupes, par exemple d’un centre de support de niveau 1 vers une équipe réseau spécialisée de niveau 2. Cet attribut est essentiel pour analyser les transferts entre équipes et identifier les goulots d’étranglement systémiques. Le Dashboard « Taux de transfert et de réaffectation » s’appuie largement sur ces données pour montrer quelles équipes interviennent fréquemment dans les transferts. Il permet également de comparer la performance des différents groupes de support et de comprendre où se situe l’expertise nécessaire à la résolution au sein de l’organisation. Pourquoi c’est important Il indique quelle équipe est responsable et permet d’analyser la performance, la charge de travail et les transferts entre groupes. Où les obtenir Table des incidents ServiceNow, champ assignment_group. Exemples Centre de servicesSupport réseauAdministrateurs de bases de données
	Priorité Priority	Niveau de priorité de l’incident, qui détermine le degré d’urgence requis pour la réponse.
Description La priorité est un champ clé de ServiceNow qui détermine l’ordre et la rapidité de traitement d’un incident. Elle est généralement calculée à partir de l’impact et de l’urgence de l’incident et influence directement les objectifs de SLA. Cet attribut est fondamental pour la segmentation et l’analyse de la performance. Le Dashboard « Vue d’ensemble de la conformité aux SLA » utilise la priorité pour vérifier que les incidents prioritaires sont résolus dans les délais prévus. L’analyse des temps de cycle par priorité permet de confirmer que les incidents critiques sont effectivement traités plus rapidement que les incidents moins importants. Il s’agit d’une dimension essentielle pour presque tous les KPI et Dashboards. Pourquoi c’est important Il permet de segmenter les incidents selon leur importance pour l’activité, ce qui est essentiel au suivi de la conformité aux SLA et à l’allocation des ressources. Où les obtenir Table des incidents ServiceNow, champ priority. Exemples 1 - Critique2 - Élevée3 - Modérée4 - Faible
	Catégorie Category	Classification générale de l’incident, par exemple Hardware, Software ou Network.
Description La catégorie fournit une classification générale de la nature de l’incident. Souvent associée à une sous-catégorie, elle aide à orienter l’incident vers l’équipe de support appropriée et sert aux rapports ainsi qu’à l’analyse des tendances. Dans le Process Mining, cet attribut est essentiel pour les Dashboards « Précision de la catégorisation des incidents » et « Volume d’incidents récurrents ». En analysant les incidents dont la catégorie est modifiée en cours de processus, les organisations peuvent identifier les problèmes liés au triage initial. Le filtrage de la carte de processus par catégorie peut également révéler si certains types d’incidents suivent des parcours de résolution différents ou rencontrent des goulots d’étranglement spécifiques. Pourquoi c’est important Il permet d’analyser les types d’incidents, de mesurer la précision de la catégorisation et de soutenir l’orientation ainsi que l’analyse des tendances. Où les obtenir Table des incidents ServiceNow, champ category. Exemples MatérielLogicielRéseauBase de données
	Code de résolution ResolutionCode	Code indiquant la manière dont l’incident a finalement été résolu.
Description Le code de résolution précise la nature de la solution appliquée, par exemple si l’incident a été résolu par l’utilisateur, par la correction d’une erreur connue ou au moyen d’une solution de contournement. Ce champ est généralement renseigné par l’agent lors de la clôture de l’incident. Cet attribut alimente directement le Dashboard « Efficacité des types de résolution ». Il permet d’analyser le nombre d’incidents clôturés au moyen de corrections durables par rapport aux solutions de contournement temporaires, un indicateur important de la qualité du service et de sa stabilité à long terme. Un taux élevé de solutions de contournement peut indiquer que les problèmes sous-jacents ne sont pas traités de manière suffisante. Pourquoi c’est important Il précise la méthode de résolution, permet de comparer les corrections durables aux solutions de contournement temporaires et contribue à l’analyse des causes profondes. Où les obtenir Table des incidents ServiceNow, champ close_code ou champ personnalisé du code de résolution. Exemples Résolu (solution de contournement)Résolu (définitivement)Non résolu (annulé par l'utilisateur)Erreur connue
	Date d’échéance du SLA SlaDueDate	La date et l’heure cibles auxquelles l’incident doit être résolu conformément à son SLA.
Description La date d’échéance du SLA est un horodatage calculé qui représente la date limite de résolution d’un incident. Cette date est déterminée par le Service Level Agreement (SLA) associé aux caractéristiques de l’incident, notamment sa priorité. Cet attribut est essentiel pour le Dashboard « Vue d’ensemble de la conformité aux SLA » et le KPI « Taux de violation du SLA des incidents critiques ». Il sert de référence pour comparer le délai réel de résolution. L’analyse des incidents proches de leur date d’échéance SLA peut contribuer à une escalade et à une priorisation proactives. Pourquoi c’est important Il définit l’objectif de résolution, ce qui permet de mesurer la conformité aux SLA et d’identifier les incidents susceptibles de dépasser leur délai cible. Où les obtenir Cette valeur se trouve généralement dans la table task_sla, qui est liée à la table incident. Le champ planned_end_time contient l’horodatage concerné. Exemples 2023-05-20T17:00:00Z2023-06-01T09:00:00Z
	Demandeur CallerId	L’utilisateur qui a signalé l’incident initialement.
Description Le demandeur désigne l’utilisateur final ou le client touché par l’incident et à l’origine de son signalement. Cette information permet de comprendre qui subit les perturbations de service. Même si cet élément n’est pas toujours au cœur du flux du processus, l’analyse des incidents par demandeur peut révéler que certaines personnes ou certains services sont touchés de manière disproportionnée. Elle peut ainsi mettre en évidence des besoins de formation ou des problèmes liés à un environnement local. Elle fournit également un lien direct avec le client pour les enquêtes de satisfaction et les communications. Pourquoi c’est important Il identifie l’utilisateur concerné, ce qui permet d’analyser les incidents par service ou par personne et de disposer du contexte nécessaire aux communications avec les utilisateurs. Où les obtenir Table des incidents ServiceNow, champ caller_id. Exemples Abel TuterCarolina PashDon Goodliffe
	Élément de configuration ConfigurationItem	Composant informatique, service ou actif précis affecté par l’incident.
Description L’élément de configuration (CI) est l’actif de la base de données de gestion de configuration (CMDB) affecté par l’incident. Il peut s’agir d’un serveur, d’une application, d’un ordinateur portable ou d’un équipement réseau. L’analyse des incidents par CI est particulièrement utile pour identifier les actifs ou services peu fiables. Elle permet de repérer les éléments de l’infrastructure informatique qui génèrent le plus d’incidents et d’orienter les investissements vers des mises à niveau ou des remplacements. Dans le Process Mining, le filtrage par CI peut révéler si les incidents liés aux applications critiques sont traités différemment ou plus efficacement que les autres. Pourquoi c’est important Il identifie l’actif affecté, aide à repérer les composants problématiques de l’infrastructure informatique et permet de cibler les efforts d’amélioration. Où les obtenir Table des incidents ServiceNow, champ cmdb_ci. Exemples SAP ERP ProductionOracle DB Server 05Service de messagerie
	Gravité Severity	Niveau d’impact de l’incident sur l’activité.
Description La gravité indique dans quelle mesure un incident affecte les opérations de l’entreprise. Avec l’urgence, elle sert souvent à calculer automatiquement la priorité de l’incident. Dans l’analyse, la gravité est une dimension clé du Dashboard « Vue d’ensemble de la conformité aux SLA ». Elle aide les organisations à vérifier qu’elles respectent les niveaux de service pour les incidents les plus perturbateurs. Elle offre une vision de la performance centrée sur l’activité, en complément de la vision opérationnelle apportée par la priorité. Pourquoi c’est important Elle mesure l’impact d’un incident sur l’activité et fournit une dimension essentielle pour prioriser les efforts et analyser la performance face aux problèmes critiques. Où les obtenir Table des incidents ServiceNow, champ severity. Exemples 1 - Élevée2 - Moyenne3 - Faible
	ID du problème ProblemId	Identifiant de l’enregistrement Problem associé lorsque l’incident est lié à un problème plus vaste.
Description L’ID du problème relie un incident à l’enregistrement correspondant dans le module Problem Management. Ce lien est créé lorsqu’un incident est identifié comme le symptôme d’un problème sous-jacent plus vaste qui affecte plusieurs utilisateurs ou services. Ce rattachement est essentiel pour le Dashboard « Volume d’incidents récurrents » et le KPI « Taux d’incidents récurrents ». Il permet aux analystes de regrouper les incidents issus d’une même cause profonde, de mesurer l’impact global d’un problème et de suivre l’efficacité des efforts de résolution des problèmes. Un nombre élevé d’incidents liés à des problèmes indique un environnement de support principalement réactif. Pourquoi c’est important Il relie les incidents à une cause profonde, ce qui est essentiel pour analyser les problèmes récurrents et mesurer l’impact de la Gestion des problèmes. Où les obtenir Table des incidents ServiceNow, champ problem_id. Exemples PRB0040001PRB0040015PRB0040102
	Nombre de réaffectations ReassignmentCount	Nombre de fois où l’incident a été réaffecté à un autre groupe ou agent.
Description Ce champ suit le nombre total de transferts d’un incident entre différents groupes d’affectation. Il mesure directement les frictions du processus et sert souvent d’indicateur clé de performance. Cet attribut constitue la principale source du Dashboard « Taux de transfert et de réaffectation » et du KPI « Nombre moyen de transferts par incident ». Un nombre élevé de réaffectations indique souvent une orientation initiale incorrecte, un manque de compétences dans un niveau de support ou une responsabilité mal définie. Réduire ce nombre est un objectif courant des initiatives d’amélioration des processus, car cela permet généralement de raccourcir les délais de résolution. Pourquoi c’est important Il mesure directement les transferts dans le processus, un indicateur clé d’inefficacité, d’orientation incorrecte et de possibilités d’amélioration. Où les obtenir Table des incidents ServiceNow, champ reassignment_count. Exemples 0135
	Rouvert IsReopened	Indicateur précisant si un incident a été rouvert après sa résolution.
Description Cet indicateur booléen prend la valeur true lorsque l’état d’un incident repasse à un état actif, par exemple « En cours », après avoir atteint l’état « Résolu » ou « Clôturé ». Cette situation est généralement identifiée par la présence de l’activité « Incident rouvert » dans le journal d’événements. Les incidents rouverts signalent souvent une résolution incomplète ou inefficace. Leur analyse permet d’identifier les clôtures prématurées ou les problèmes récurrents qui n’ont pas été correctement corrigés dès la première intervention. Un taux élevé de réouverture peut nuire à la satisfaction des utilisateurs et à la productivité des équipes, ce qui en fait un indicateur important du contrôle qualité. Pourquoi c’est important Cet indicateur met en évidence les défaillances du processus de résolution et les incidents qui ont nécessité un travail supplémentaire après avoir été considérés comme résolus. Où les obtenir Calculé en vérifiant la séquence des activités de chaque incident afin de déterminer si un état « ouvert » suit un état « résolu ». Exemples truefalse
	SLA dépassé IsSlaBreached	Indicateur précisant si la résolution de l’incident a dépassé la date d’échéance de son SLA.
Description Cet attribut booléen calculé indique qu’un incident a dépassé son Service Level Agreement. Il est obtenu en comparant l’horodatage réel de résolution à la « Date d’échéance du SLA ». Si la résolution intervient après la date d’échéance, l’indicateur prend la valeur true. Cet attribut constitue la base du Dashboard « Vue d’ensemble de la conformité aux SLA » et des KPI associés. Il simplifie l’analyse en transformant une comparaison temporelle complexe en une dimension true/false. Vous pouvez ainsi filtrer facilement tous les incidents ayant dépassé leur SLA et analyser leurs caractéristiques communes, telles que la catégorie, le groupe d’affectation ou la priorité. Pourquoi c’est important Il simplifie l’analyse de la conformité aux SLA et permet de filtrer facilement les incidents qui n’ont pas respecté leurs objectifs, puis de les examiner en détail. Où les obtenir Calculé en comparant l’horodatage « Résolu le » à l’horodatage « SlaDueDate ». (Resolved At > SlaDueDate). Exemples truefalse

Obligatoire Recommandé Facultatif

Activités de la Gestion des incidents

Voici les principales étapes et les jalons du processus à enregistrer dans votre journal d’événements pour permettre une découverte précise du processus et son optimisation.

6 Recommandé 7 Facultatif

	Activité	Description
	Groupe d’affectation modifié	Représente un transfert au cours duquel un incident passe d’un groupe de support à un autre. Cet événement est capturé en observant les modifications ultérieures du champ « assignment_group », après son premier renseignement.
Pourquoi c’est important Les réaffectations fréquentes peuvent signaler une orientation initiale incorrecte, une complexité du processus ou des lacunes en matière de connaissances. Cette activité est essentielle pour mesurer le KPI « Nombre moyen de transferts par incident ». Où les obtenir Déduit de la table « sys_audit » en suivant toute modification du champ « assignment_group » après l’affectation initiale. Collecte Identifiez chaque modification horodatée du champ « assignment_group » dans le journal d’audit. Type d’événement inferred
	Incident affecté à un groupe	Cette activité se produit lorsqu’un incident est affecté à un groupe de support précis. Il s’agit d’une étape clé du processus d’orientation, capturée en observant les modifications du champ du groupe d’affectation.
Pourquoi c’est important Le suivi des affectations est essentiel pour analyser les transferts, les temps d’attente dans chaque groupe et les inefficacités ou goulots d’étranglement liés à l’orientation. Où les obtenir Déduit de la table « sys_audit » en suivant les moments où le champ « assignment_group » de la table « incident » est renseigné ou modifié. Collecte Utilisez l’horodatage du journal d’audit correspondant aux modifications du champ « assignment_group ». Type d’événement inferred
	Incident clôturé	Il s’agit de la dernière activité du cycle de vie. Elle signifie que l’incident est entièrement résolu, confirmé et qu’aucune autre action n’est nécessaire. L’événement est capturé explicitement à partir de l’horodatage de clôture.
Pourquoi c’est important En tant qu’événement de fin définitif, cette activité est essentielle pour calculer la durée totale du cycle de vie de l’incident et analyser le temps consacré au traitement après résolution. Où les obtenir L’horodatage « closed_at » de la table « incident » sert d’horodatage explicite pour l’événement. Il est généralement renseigné lorsque le champ « state » passe à « Closed ». Collecte Utilisez l’horodatage « closed_at » de l’enregistrement de l’incident. Type d’événement explicit
	Incident créé	Marque le début du cycle de vie de l’incident, lorsqu’un nouvel incident est officiellement enregistré dans ServiceNow. Cet événement est capturé explicitement à partir de l’horodatage de création de l’enregistrement de l’incident.
Pourquoi c’est important Il s’agit de l’événement de début principal du processus. L’analyse du délai entre cette activité et la résolution est fondamentale pour mesurer la durée globale du cycle et la conformité aux SLA. Où les obtenir L’horodatage « sys_created_on » de la table « incident » sert d’horodatage explicite pour cette activité. Collecte Utilisez l’horodatage « sys_created_on » de l’enregistrement de l’incident. Type d’événement explicit
	Résolution proposée	Marque le moment où un agent du support a mis en œuvre une correction et fait passer l’incident à l’état « Resolved ». Il s’agit d’une étape clé avant la clôture définitive.
Pourquoi c’est important Cette activité signale la fin du traitement actif et le début de la phase de confirmation. Le délai entre cette étape et « Incident Closed » peut révéler des retards dans la confirmation par l’utilisateur ou dans la vérification. Où les obtenir Déduit de la table « sys_audit » lorsque le champ « state » de la table « incident » passe à « Resolved ». L’horodatage « resolved_at » est souvent renseigné à ce moment-là. Collecte Utilisez l’horodatage auquel le champ « state » prend la valeur « Resolved » ou l’horodatage « resolved_at ». Type d’événement inferred
	Travail commencé	Indique qu’un agent a commencé à examiner activement l’incident ou à le traiter. Cet événement est généralement déduit lorsque l’état de l’incident passe de « New » ou « Assigned » à un état actif tel que « In Progress ».
Pourquoi c’est important Cette étape marque la fin du temps d’attente initial dans la file et le début du traitement actif. Mesurer le délai avant le début du travail est essentiel pour analyser les goulots d’étranglement. Où les obtenir Déduit de la table « sys_audit » en identifiant le moment où le champ « state » de la table « incident » prend une valeur correspondant à un traitement actif, telle que « In Progress ». Collecte Identifiez l’horodatage auquel le champ « state » prend la valeur « In Progress » ou une valeur similaire. Type d’événement inferred
	Commentaire du support ajouté	Un agent du support ajoute une note de travail ou un commentaire visible par l’utilisateur. Il s’agit d’un événement explicite enregistré dans le flux d’activité de l’incident.
Pourquoi c’est important Suit les communications et les travaux d’analyse de l’équipe de support. L’analyse de la fréquence et du moment de publication de ces commentaires apporte des informations sur le processus d’investigation. Où les obtenir Capturé à partir de la table « sys_journal_field », qui enregistre les entrées des champs « work_notes » et « comments » de la table « incident ». Collecte Utilisez l’horodatage de création des entrées du journal dont l’élément est « work_notes » ou « comments ». Type d’événement explicit
	En attente de confirmation de l’utilisateur	L’incident est en attente de la confirmation de l’utilisateur, qui doit vérifier que la résolution proposée a bien fonctionné. Cet état est généralement déduit d’un état précis tel que « Awaiting User Info » après la résolution.
Pourquoi c’est important Cet état peut devenir un goulot d’étranglement important si les utilisateurs répondent tardivement. Mesurer le temps passé dans cette activité aide à repérer les lacunes de communication et les possibilités d’automatiser la clôture. Où les obtenir Déduit de la table « sys_audit » en identifiant le passage à un état d’attente précis après la résolution. Le nom de l’état peut être personnalisé, par exemple « Awaiting Caller ». Collecte Identifiez l’horodatage auquel le champ « state » prend une valeur indiquant l’attente d’une réponse de l’utilisateur. Type d’événement inferred
	Incident affecté à un agent	Représente le moment où un agent précis d’un groupe de support prend en charge l’incident. Cette étape est capturée en surveillant les modifications du champ « assigned_to ».
Pourquoi c’est important Cette information fournit une vision détaillée de la charge de travail des agents et de la résolution dès le premier contact. Elle permet de déterminer combien de temps les incidents attendent avant qu’une personne commence à les traiter après leur affectation à un groupe. Où les obtenir Déduit de la table « sys_audit » en suivant les moments où le champ « assigned_to » de la table « incident » est renseigné ou modifié. Collecte Utilisez l’horodatage du journal d’audit correspondant aux modifications du champ « assigned_to ». Type d’événement inferred
	Incident catégorisé	Représente la classification initiale de l’incident, au cours de laquelle des champs tels que Category, Subcategory et Priority sont renseignés. Cet événement est généralement déduit de la piste d’audit lorsque ces champs sont renseignés pour la première fois ou mis à jour peu après la création.
Pourquoi c’est important Une catégorisation précise est essentielle pour assurer une orientation et une priorisation correctes. Le suivi de cette activité permet d’analyser le taux de recatégorisation et son impact sur le délai de résolution. Où les obtenir Déduit de la table « sys_audit » en identifiant la première modification apportée à des champs tels que « category », « subcategory » ou « priority » pour un incident donné. Collecte Identifiez l’horodatage de la première mise à jour des champs de classification dans le journal d’audit. Type d’événement inferred
	Incident escaladé	Se produit lorsque la priorité ou la gravité d’un incident augmente, ce qui nécessite souvent une réponse plus rapide ou des ressources différentes. Cet événement est déduit en détectant une hausse de la valeur du champ « priority ».
Pourquoi c’est important Les escalades indiquent souvent qu’un incident est plus grave qu’on ne le pensait initialement ou qu’il se rapproche d’une violation de SLA. L’analyse de ces événements aide à comprendre les exceptions du processus. Où les obtenir Déduit de la table « sys_audit » en identifiant une modification du champ « priority » vers une valeur indiquant un niveau d’urgence supérieur. Collecte Détectez toute augmentation de la valeur du champ « priority », par exemple de « 3 - Moderate » à « 2 - High ». Type d’événement inferred
	Incident lié à un problème	Cette activité se produit lorsqu’un incident est officiellement associé à un enregistrement de problème, ce qui indique qu’il s’inscrit dans un problème sous-jacent plus vaste. Elle est déduite lorsque le champ « problem_id » de l’enregistrement de l’incident est renseigné.
Pourquoi c’est important Le rattachement à un problème constitue une étape essentielle pour passer d’une résolution réactive des incidents à une analyse proactive des causes profondes. Il alimente le Dashboard « Volume d’incidents récurrents ». Où les obtenir Déduit en détectant le moment où le champ de référence « problem_id » de la table « incident » est renseigné. Collecte Identifiez dans le journal d’audit l’horodatage auquel le champ « problem_id » est renseigné. Type d’événement inferred
	Incident rouvert	Se produit lorsqu’un utilisateur signale que le problème persiste après que l’incident a été marqué comme résolu. Cet événement est déduit lorsque l’état de l’incident repasse de « Resolved » à un état actif tel que « In Progress ».
Pourquoi c’est important Les incidents rouverts indiquent que la résolution a échoué et constituent une reprise du traitement. Le suivi de cette activité est essentiel pour mesurer la qualité de la résolution et le taux de résolution dès la première intervention. Où les obtenir Déduit de la table « sys_audit » en détectant une transition du champ « state » de « Resolved » vers un état actif tel que « In Progress » ou « Assigned ». Collecte Identifiez l’horodatage auquel le champ « state » passe de « Resolved » à une valeur active. Type d’événement inferred

Recommandé Facultatif

Guides d’extraction

Comment extraire vos données de la Gestion des problèmes dans ServiceNow

Étapes

Configurer l’accès à ServiceNow : obtenez les identifiants d’un compte de service dans ServiceNow. Ce compte doit disposer des autorisations de lecture, via les ACL, sur les tables incident et sys_audit ainsi que sur tous les champs requis, notamment sys_id, number, sys_created_on, resolved_at, closed_at, assignment_group, assigned_to, priority, incident_state, state, category, subcategory, problem_id, comments et work_notes.
Configurer l’environnement Node.js : vérifiez que Node.js est installé sur la machine qui exécutera le script d’extraction. Installez la bibliothèque axios pour effectuer les requêtes HTTP en exécutant npm install axios dans votre terminal.
Préparer le script d’extraction : copiez le code JavaScript fourni dans un fichier, par exemple extract_incidents.js. Remplacez en haut du script les valeurs fictives par l’URL de votre instance ServiceNow, votre nom d’utilisateur et votre mot de passe.
Définir les paramètres d’extraction : ajustez les variables startDate et endDate dans le script afin de définir la période des incidents à extraire. Pour les premières exécutions, il est recommandé d’utiliser une période courte, par exemple une semaine, afin de valider les résultats.
Exécuter le script : lancez le script depuis votre terminal à l’aide de la commande node extract_incidents.js. Le script commence alors à récupérer les données des incidents et leurs journaux d’audit correspondants via l’API ServiceNow.
Suivre la progression du script : le script affiche la progression dans la console et indique le nombre d’incidents traités. Pour les volumes importants, cette opération peut prendre beaucoup de temps en raison du nombre de requêtes API nécessaires.
Traiter les réponses de l’API : le script parcourt chaque incident. Pour chacun, il interroge la table sys_audit afin de récupérer l’intégralité de son historique de modifications. Il traite ensuite cet historique pour identifier et horodater les 13 activités requises.
Gérer les activités déduites : le script contient une logique permettant de déduire des activités à partir des modifications de champs. Par exemple, « Incident escaladé » est créé lorsque la nouvelle valeur du champ priority est inférieure à l’ancienne, ce qui indique une priorité plus élevée. « Travail commencé » est identifié par le premier changement d’état vers « En cours ».
Structurer le journal d’événements : au fur et à mesure de l’identification des activités, celles-ci sont converties en enregistrements du journal d’événements. Chaque enregistrement contient les colonnes requises : IncidentId, ActivityName, EventTime, entre autres.
Enregistrer le résultat : une fois l’exécution terminée, le script enregistre le journal d’événements généré dans un fichier JSON nommé servicenow_incident_event_log.json, dans le même répertoire. Ce fichier contient un tableau regroupant tous les événements extraits.
Convertir au format CSV : pour importer les données dans ProcessMind, vous devrez peut-être convertir le résultat JSON final en fichier CSV. Utilisez un outil de données standard ou un script simple pour transformer le tableau JSON en fichier CSV, en veillant à ce que les en-têtes correspondent aux attributs requis.

Configuration

Point de terminaison d’API : le script cible deux points de terminaison principaux de l’API Table de ServiceNow :
- https://[Your ServiceNow Instance].service-now.com/api/now/table/incident
- https://[Your ServiceNow Instance].service-now.com/api/now/table/sys_audit
Authentification : le script fourni utilise l’authentification de base, avec un nom d’utilisateur et un mot de passe. Vérifiez que les identifiants du compte de service sont corrects et que le compte est actif.
Filtrage par période : la requête est filtrée selon la date de création de l’incident, sys_created_on. Cette période est définie par les variables startDate et endDate du script. Il est recommandé d’extraire trois à six mois de données pour obtenir une analyse pertinente, en commençant par une période plus courte pour les tests.
Principaux paramètres de requête :
- sysparm_query : permet de filtrer les enregistrements. Le script construit une chaîne de requête encodée pour filtrer les incidents selon leur date de création.
- sysparm_fields : précise les colonnes à récupérer, ce qui réduit la taille de la charge utile de l’API et améliore les performances.
- sysparm_limit : gère la pagination en définissant le nombre d’enregistrements renvoyés par requête. Le script utilise une limite de 1000, une pratique courante.
- sysparm_offset : s’utilise avec sysparm_limit pour récupérer les pages de données suivantes.
Considérations relatives aux performances : interroger la table sys_audit pour chaque incident mobilise beaucoup de ressources. Pour les instances ServiceNow très volumineuses, envisagez d’exécuter l’extraction pendant les périodes creuses. Le script traite les incidents séquentiellement afin d’éviter de surcharger l’API, mais cette méthode peut prolonger la durée totale d’exécution.
Prérequis : un environnement Node.js est nécessaire pour exécuter le script. L’utilisateur ou le compte de service qui lance l’extraction doit disposer des autorisations de lecture nécessaires, notamment des ACL, sur les tables incident et sys_audit.

a Exemple de requête javascript

const axios = require('axios');
const fs = require('fs');

// --- Configuration ---
const INSTANCE_URL = 'https://[your-instance].service-now.com';
const USERNAME = '[your-username]';
const PASSWORD = '[your-password]';

// Define the date range for the extraction
const startDate = '2023-01-01 00:00:00';
const endDate = '2023-03-31 23:59:59';

const BATCH_SIZE = 1000; // Records per API call for incidents
const SOURCE_SYSTEM = 'ServiceNow';

// --- Main Extraction Logic ---
async function extractIncidentData() {
    const auth = { username: USERNAME, password: PASSWORD };
    const allEvents = [];
    let offset = 0;
    let hasMoreRecords = true;

    console.log(`Starting extraction for incidents created between ${startDate} and ${endDate}...`);

    while (hasMoreRecords) {
        try {
            // 1. Fetch a batch of incidents
            const incidentQuery = `sys_created_on>=${startDate}^sys_created_on<=${endDate}`;
            const incidentFields = [
                'sys_id', 'number', 'sys_created_on', 'resolved_at', 'closed_at',
                'assigned_to', 'assignment_group', 'priority', 'incident_state',
                'state', 'sys_updated_on'
            ].join(',');

            console.log(`Fetching incidents, offset: ${offset}...`);
            const incidentResponse = await axios.get(`${INSTANCE_URL}/api/now/table/incident`, {
                auth,
                params: {
                    sysparm_query: incidentQuery,
                    sysparm_fields: incidentFields,
                    sysparm_limit: BATCH_SIZE,
                    sysparm_offset: offset
                }
            });

            const incidents = incidentResponse.data.result;
            if (incidents.length === 0) {
                hasMoreRecords = false;
                continue;
            }

            // 2. For each incident, fetch its audit trail and generate events
            for (const incident of incidents) {
                const lastDataUpdate = new Date().toISOString();

                // --- Explicit Events from Incident Table ---
                allEvents.push(createEvent(incident, 'Incident Created', incident.sys_created_on, lastDataUpdate));
                if (incident.resolved_at) {
                    allEvents.push(createEvent(incident, 'Resolution Proposed', incident.resolved_at, lastDataUpdate));
                }
                if (incident.closed_at) {
                    allEvents.push(createEvent(incident, 'Incident Closed', incident.closed_at, lastDataUpdate));
                }

                // --- Inferred Events from Audit Table ---
                const auditQuery = `documentkey=${incident.sys_id}`;
                const auditFields = 'sys_created_on,fieldname,oldvalue,newvalue';
                const auditResponse = await axios.get(`${INSTANCE_URL}/api/now/table/sys_audit`, {
                    auth,
                    params: { sysparm_query: auditQuery, sysparm_fields: auditFields, sysparm_display_value: 'true' }
                });

                const auditRecords = auditResponse.data.result.sort((a, b) => new Date(a.sys_created_on) - new Date(b.sys_created_on));
                
                let isCategorized = false, isGroupAssigned = false, isAgentAssigned = false, isWorkStarted = false, isProblemLinked = false, isReopened = false;
                let lastPriority = null;
                
                for (const audit of auditRecords) {
                    const eventTime = audit.sys_created_on;
                    
                    if (!isCategorized && (audit.fieldname === 'category' || audit.fieldname === 'subcategory') && audit.newvalue) {
                        allEvents.push(createEvent(incident, 'Incident Categorized', eventTime, lastDataUpdate));
                        isCategorized = true;
                    }
                    if (!isGroupAssigned && audit.fieldname === 'assignment_group' && audit.newvalue) {
                        allEvents.push(createEvent(incident, 'Incident Assigned To Group', eventTime, lastDataUpdate));
                        isGroupAssigned = true;
                    } else if (isGroupAssigned && audit.fieldname === 'assignment_group' && audit.newvalue) {
                        allEvents.push(createEvent(incident, 'Assignment Group Changed', eventTime, lastDataUpdate));
                    }
                    if (!isAgentAssigned && audit.fieldname === 'assigned_to' && audit.newvalue) {
                        allEvents.push(createEvent(incident, 'Incident Assigned To Agent', eventTime, lastDataUpdate));
                        isAgentAssigned = true;
                    }
                    if (!isWorkStarted && (audit.fieldname === 'state' || audit.fieldname === 'incident_state') && audit.newvalue.toLowerCase().includes('progress')) {
                        allEvents.push(createEvent(incident, 'Work Started', eventTime, lastDataUpdate));
                        isWorkStarted = true;
                    }
                    if ((audit.fieldname === 'comments' || audit.fieldname === 'work_notes') && audit.newvalue) {
                        allEvents.push(createEvent(incident, 'Support Comment Added', eventTime, lastDataUpdate));
                    }
                    if (audit.fieldname === 'priority') {
                         const oldPriorityVal = parseInt(audit.oldvalue.match(/\d+/), 10);
                         const newPriorityVal = parseInt(audit.newvalue.match(/\d+/), 10);
                         if (lastPriority !== null && newPriorityVal < lastPriority) {
                             allEvents.push(createEvent(incident, 'Incident Escalated', eventTime, lastDataUpdate));
                         }
                         lastPriority = newPriorityVal;
                    }
                    if (!isProblemLinked && audit.fieldname === 'problem_id' && audit.newvalue) {
                        allEvents.push(createEvent(incident, 'Incident Linked To Problem', eventTime, lastDataUpdate));
                        isProblemLinked = true;
                    }
                    if ((audit.fieldname === 'state' || audit.fieldname === 'incident_state') && audit.newvalue.toLowerCase().includes('awaiting')) {
                         allEvents.push(createEvent(incident, 'Awaiting User Confirmation', eventTime, lastDataUpdate));
                    }
                    if (!isReopened && (audit.fieldname === 'state' || audit.fieldname === 'incident_state') && (audit.oldvalue.toLowerCase().includes('resolved') || audit.oldvalue.toLowerCase().includes('closed')) && audit.newvalue.toLowerCase().includes('progress')) {
                        allEvents.push(createEvent(incident, 'Incident Reopened', eventTime, lastDataUpdate));
                        isReopened = true; 
                    }
                }
            }

            offset += BATCH_SIZE;
            console.log(`Processed ${incidents.length} incidents. Total events so far: ${allEvents.length}`);

        } catch (error) {
            console.error('An error occurred:', error.response ? error.response.data : error.message);
            hasMoreRecords = false; // Stop on error
        }
    }

    // 3. Save results to a file
    fs.writeFileSync('servicenow_incident_event_log.json', JSON.stringify(allEvents, null, 2));
    console.log(`Extraction complete. ${allEvents.length} events saved to servicenow_incident_event_log.json`);
}

// --- Helper Function to create a standard event object ---
function createEvent(incident, activityName, eventTime, lastDataUpdate) {
    return {
        IncidentId: incident.number,
        ActivityName: activityName,
        EventTime: eventTime,
        SourceSystem: SOURCE_SYSTEM,
        LastDataUpdate: lastDataUpdate,
        AssignedTo: incident.assigned_to.display_value || '',
        AssignmentGroup: incident.assignment_group.display_value || '',
        Priority: incident.priority.display_value || '',
        IncidentState: incident.incident_state.display_value || incident.state.display_value || ''
    };
}

// --- Run the script ---
extractIncidentData();

Étapes

Prérequis : vérifiez que Python 3.6 ou une version ultérieure est installé sur votre système. Installez les bibliothèques nécessaires avec pip : pip install requests pandas.
Configuration de ServiceNow : créez dans ServiceNow un compte de service dédié à cette extraction. Attribuez-lui les rôles itil et rest_api_explorer afin qu’il dispose d’un accès en lecture aux tables requises : incident, sys_audit et sys_journal_field.
Configurer le script : ouvrez le script Python fourni. Dans la section de configuration située en haut du fichier, remplacez les valeurs fictives de SNOW_INSTANCE, SNOW_USER et SNOW_PASSWORD par l’URL de votre instance ServiceNow et les identifiants du compte de service. Ajustez START_DATE et END_DATE pour définir la période d’extraction souhaitée.
Exécuter le script : lancez le script depuis la ligne de commande à l’aide de python your_script_name.py. Le script commence alors à s’authentifier auprès de ServiceNow et à effectuer les appels API.
Récupérer les données : le script récupère d’abord, dans la table incident, la liste de tous les incidents créés pendant la période indiquée. Il utilise ensuite cette liste d’identifiants d’incidents pour récupérer l’historique d’audit associé dans sys_audit ainsi que tous les commentaires dans sys_journal_field.
Générer le journal d’événements : le script traite les données brutes en mémoire. Il parcourt les activités prédéfinies et génère un ensemble distinct de lignes pour chacune d’elles. Par exemple, il identifie l’événement « Incident créé » à partir du champ sys_created_on et l’événement « Incident clôturé » à partir du champ closed_at. Pour les autres événements, il analyse le journal d’audit afin de repérer les transitions d’état, les modifications de champs et les escalades.
Mapper les attributs : pour chaque ligne d’événement générée, le script enrichit les données avec les attributs contextuels de l’enregistrement principal de l’incident, tels que AssignmentGroup, AssignedTo, Priority et IncidentState au moment de l’événement.
Consolider les données : tous les DataFrames d’événements individuels, un par type d’activité, sont regroupés dans un DataFrame unique et complet de journal d’événements.
Effectuer la transformation finale : le DataFrame consolidé est trié par IncidentId et EventTime afin de garantir l’ordre chronologique correct des événements pour chaque dossier. Les colonnes SourceSystem et LastDataUpdate sont ajoutées avec des valeurs statiques.
Exporter au format CSV : le journal d’événements final est enregistré sous le nom servicenow_incident_event_log.csv, dans le même répertoire que celui où le script a été exécuté. Le fichier est prêt à être importé dans un logiciel de Process Mining.

Configuration

Instance ServiceNow (SNOW_INSTANCE) : URL complète de votre instance ServiceNow, par exemple https://yourcompany.service-now.com.
Identifiants (SNOW_USER, SNOW_PASSWORD) : informations d’authentification du compte de service. Dans les environnements de production, envisagez d’utiliser OAuth ou une authentification par jeton plutôt que l’authentification de base.
Période (START_DATE, END_DATE) : définit la période d’extraction à partir de la date de création des incidents. Pour une première analyse, une période de trois à six mois constitue un bon compromis entre volume de données et pertinence des résultats. Des périodes plus longues augmenteront sensiblement la durée d’extraction.
Paramètres de requête API (sysparm_query) : le script utilise sysparm_query pour filtrer les incidents selon leur date de création, sys_created_on. Vous pouvez ajouter d’autres conditions pour restreindre le périmètre, par exemple active=false^company=[Your Company Sys ID], afin d’extraire uniquement les incidents clôturés d’une entreprise donnée.
Limitation du débit de l’API : tenez compte des limites de débit de l’API ServiceNow. Le script gère la pagination, mais ne prévoit pas de gestion explicite de ces limites. Pour les instances très volumineuses, vous devrez peut-être ajouter des appels à time.sleep() entre les requêtes afin d’éviter de dépasser les limites.
Autorisations requises : l’utilisateur indiqué doit disposer d’un accès en lecture, via les ACL, aux tables incident, sys_audit et sys_journal_field. Le rôle itil fournit généralement cet accès, mais votre instance peut appliquer des contrôles d’accès personnalisés.

a Exemple de requête python

import requests
import pandas as pd
from datetime import datetime
import getpass

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your ServiceNow instance URL, e.g., class="hl-string">'https://yourinstance.service-now.com'
SNOW_INSTANCE = class="hl-string">"[Your ServiceNow Instance URL]"
class=class="hl-string">"hl-comment"># Replace with your ServiceNow user. Consider using a dedicated service account.
SNOW_USER = class="hl-string">"[Your Username]"
class=class="hl-string">"hl-comment"># It's recommended to use a secure way to handle passwords, like environment variables or a secrets manager.
class=class="hl-string">"hl-comment"># getpass is used here for interactive entry to avoid hardcoding.
SNOW_PASSWORD = getpass.getpass(class="hl-string">"Enter ServiceNow Password: ")

class=class="hl-string">"hl-comment"># Define the date range for the extraction (YYYY-MM-DD format)
START_DATE = class="hl-string">"2023-01-01"
END_DATE = class="hl-string">"2023-06-30"

SOURCE_SYSTEM_NAME = class="hl-string">"ServiceNow"

class=class="hl-string">"hl-comment"># --- Helper Function for Paginated API Calls ---
def fetch_all_records(url, headers, params):
    class="hl-string">"""Fetches all records from a paginated ServiceNow API endpoint."""
    all_records = []
    offset = 0
    limit = 1000
    while True:
        params[class="hl-string">'sysparm_offset'] = offset
        params[class="hl-string">'sysparm_limit'] = limit
        response = requests.get(url, headers=headers, params=params)
        response.raise_for_status() class=class="hl-string">"hl-comment"># Raises an exception for bad status codes
        data = response.json().get(class="hl-string">'result', [])
        if not data:
            break
        all_records.extend(data)
        offset += len(data)
        print(fclass="hl-string">"Fetched {len(all_records)} records so far...")
    return all_records

class=class="hl-string">"hl-comment"># --- Main Script ---
if __name__ == class="hl-string">"__main__":
    auth = (SNOW_USER, SNOW_PASSWORD)
    headers = {class="hl-string">"Accept": class="hl-string">"application/json"}
    last_data_update = datetime.utcnow().isoformat() + class="hl-string">"Z"

    class=class="hl-string">"hl-comment"># 1. Fetch base Incident Data
    print(class="hl-string">"\n--- Fetching Incident Data ---")
    incident_url = fclass="hl-string">"{SNOW_INSTANCE}/api/now/table/incident"
    incident_query = fclass="hl-string">"sys_created_on>={START_DATE} 00:00:00^sys_created_on<={END_DATE} 23:59:59"
    incident_params = {
        class="hl-string">'sysparm_query': incident_query,
        class="hl-string">'sysparm_fields': class="hl-string">'sys_id,number,sys_created_on,closed_at,opened_at,priority,state,assignment_group,assigned_to,problem_id'
    }
    incidents_raw = fetch_all_records(incident_url, headers, auth, incident_params)
    incidents_df = pd.DataFrame(incidents_raw)
    
    if incidents_df.empty:
        print(class="hl-string">"No incidents found for the given date range. Exiting.")
        exit()

    class=class="hl-string">"hl-comment"># Map sys_id to readable values for easier processing later
    for col in [class="hl-string">'assignment_group', class="hl-string">'assigned_to', class="hl-string">'problem_id']:
        if col in incidents_df.columns:
            incidents_df[col] = incidents_df[col].apply(lambda x: x[class="hl-string">'display_value'] if isinstance(x, dict) and x else None)
            
    incident_sys_ids = class="hl-string">','.join(incidents_df[class="hl-string">'sys_id'].unique())

    class=class="hl-string">"hl-comment"># 2. Fetch Audit (sys_audit) Data for these incidents
    print(class="hl-string">"\n--- Fetching Audit Data ---")
    audit_url = fclass="hl-string">"{SNOW_INSTANCE}/api/now/table/sys_audit"
    audit_query = fclass="hl-string">"documentkeyIN{incident_sys_ids}"
    audit_params = {
        class="hl-string">'sysparm_query': audit_query,
        class="hl-string">'sysparm_fields': class="hl-string">'documentkey,sys_created_on,fieldname,oldvalue,newvalue'
    }
    audit_raw = fetch_all_records(audit_url, headers, auth, audit_params)
    audit_df = pd.DataFrame(audit_raw)
    audit_df.rename(columns={class="hl-string">'documentkey': class="hl-string">'sys_id'}, inplace=True)

    class=class="hl-string">"hl-comment"># 3. Fetch Journal (comments) Data for these incidents
    print(class="hl-string">"\n--- Fetching Journal/Comment Data ---")
    journal_url = fclass="hl-string">"{SNOW_INSTANCE}/api/now/table/sys_journal_field"
    journal_query = fclass="hl-string">"element_idIN{incident_sys_ids}^element=work_notes,comments"
    journal_params = {
        class="hl-string">'sysparm_query': journal_query,
        class="hl-string">'sysparm_fields': class="hl-string">'element_id,sys_created_on'
    }
    journal_raw = fetch_all_records(journal_url, headers, auth, journal_params)
    journal_df = pd.DataFrame(journal_raw)
    journal_df.rename(columns={class="hl-string">'element_id': class="hl-string">'sys_id'}, inplace=True)

    print(class="hl-string">"\n--- Processing Data and Generating Event Log ---")
    event_log_frames = []

    class=class="hl-string">"hl-comment"># Merge incident details into audit and journal logs for context
    incidents_context_df = incidents_df[[class="hl-string">'sys_id', class="hl-string">'number', class="hl-string">'assignment_group', class="hl-string">'assigned_to', class="hl-string">'priority', class="hl-string">'state']].copy()
    incidents_context_df.rename(columns={class="hl-string">'number': class="hl-string">'IncidentId'}, inplace=True)

    if not audit_df.empty:
        audit_df = pd.merge(audit_df, incidents_context_df, on=class="hl-string">'sys_id', how=class="hl-string">'left')
    if not journal_df.empty:
        journal_df = pd.merge(journal_df, incidents_context_df, on=class="hl-string">'sys_id', how=class="hl-string">'left')

    class=class="hl-string">"hl-comment"># Activity: Incident Created
    created_df = incidents_df[[class="hl-string">'number', class="hl-string">'sys_created_on', class="hl-string">'assignment_group', class="hl-string">'assigned_to', class="hl-string">'priority', class="hl-string">'state']].copy()
    created_df[class="hl-string">'ActivityName'] = class="hl-string">'Incident Created'
    created_df.rename(columns={class="hl-string">'number': class="hl-string">'IncidentId', class="hl-string">'sys_created_on': class="hl-string">'EventTime', class="hl-string">'assignment_group': class="hl-string">'AssignmentGroup', class="hl-string">'assigned_to': class="hl-string">'AssignedTo', class="hl-string">'priority': class="hl-string">'Priority', class="hl-string">'state': class="hl-string">'IncidentState'}, inplace=True)
    event_log_frames.append(created_df)

    class=class="hl-string">"hl-comment"># Activity: Incident Closed
    closed_df = incidents_df[incidents_df[class="hl-string">'closed_at'].notna() & (incidents_df[class="hl-string">'closed_at'] != class="hl-string">'')].copy()
    closed_df[class="hl-string">'ActivityName'] = class="hl-string">'Incident Closed'
    closed_df.rename(columns={class="hl-string">'number': class="hl-string">'IncidentId', class="hl-string">'closed_at': class="hl-string">'EventTime', class="hl-string">'assignment_group': class="hl-string">'AssignmentGroup', class="hl-string">'assigned_to': class="hl-string">'AssignedTo', class="hl-string">'priority': class="hl-string">'Priority', class="hl-string">'state': class="hl-string">'IncidentState'}, inplace=True)
    event_log_frames.append(closed_df.drop(columns=[class="hl-string">'sys_created_on']))

    class=class="hl-string">"hl-comment"># Process audit data for remaining activities
    if not audit_df.empty:
        audit_df.sort_values(by=[class="hl-string">'sys_id', class="hl-string">'sys_created_on'], inplace=True)
        
        class=class="hl-string">"hl-comment"># Activity: Incident Categorized (first change to category, subcategory, or priority)
        categorized_fields = [class="hl-string">'category', class="hl-string">'subcategory', class="hl-string">'priority']
        categorized_df = audit_df[audit_df[class="hl-string">'fieldname'].isin(categorized_fields)].copy()
        categorized_df = categorized_df.drop_duplicates(subset=[class="hl-string">'sys_id'], keep=class="hl-string">'first')
        categorized_df[class="hl-string">'ActivityName'] = class="hl-string">'Incident Categorized'
        event_log_frames.append(categorized_df)

        class=class="hl-string">"hl-comment"># Activity: Incident Assigned To Group
        assign_group_df = audit_df[(audit_df[class="hl-string">'fieldname'] == class="hl-string">'assignment_group') & (audit_df[class="hl-string">'newvalue'].notna())].copy()
        assign_group_first_df = assign_group_df.drop_duplicates(subset=[class="hl-string">'sys_id'], keep=class="hl-string">'first')
        assign_group_first_df[class="hl-string">'ActivityName'] = class="hl-string">'Incident Assigned To Group'
        event_log_frames.append(assign_group_first_df)
        
        class=class="hl-string">"hl-comment"># Activity: Assignment Group Changed (subsequent changes)
        assign_group_changed_df = assign_group_df.loc[assign_group_df.index.difference(assign_group_first_df.index)]
        assign_group_changed_df[class="hl-string">'ActivityName'] = class="hl-string">'Assignment Group Changed'
        event_log_frames.append(assign_group_changed_df)

        class=class="hl-string">"hl-comment"># Activity: Incident Assigned To Agent
        assign_agent_df = audit_df[(audit_df[class="hl-string">'fieldname'] == class="hl-string">'assigned_to') & (audit_df[class="hl-string">'newvalue'].notna())].copy()
        assign_agent_df = assign_agent_df.drop_duplicates(subset=[class="hl-string">'sys_id'], keep=class="hl-string">'first')
        assign_agent_df[class="hl-string">'ActivityName'] = class="hl-string">'Incident Assigned To Agent'
        event_log_frames.append(assign_agent_df)

        class=class="hl-string">"hl-comment"># Activity: Work Started (State changed to In Progress)
        work_started_df = audit_df[audit_df[class="hl-string">'fieldname'] == class="hl-string">'state'].copy()
        class=class="hl-string">"hl-comment"># Note: The class="hl-string">'newvalue' for state is often a numeric ID. Common value for class="hl-string">'In Progress' is class="hl-string">'2'. Adjust if needed.
        work_started_df = work_started_df[work_started_df[class="hl-string">'newvalue'].isin([class="hl-string">'2', class="hl-string">'In Progress', class="hl-string">'Work in Progress'])]
        work_started_df = work_started_df.drop_duplicates(subset=[class="hl-string">'sys_id'], keep=class="hl-string">'first')
        work_started_df[class="hl-string">'ActivityName'] = class="hl-string">'Work Started'
        event_log_frames.append(work_started_df)
        
        class=class="hl-string">"hl-comment"># Activity: Incident Escalated (Priority increases)
        priority_map = {class="hl-string">'1 - Critical': 1, class="hl-string">'2 - High': 2, class="hl-string">'3 - Moderate': 3, class="hl-string">'4 - Low': 4, class="hl-string">'5 - Planning': 5}
        escalated_df = audit_df[audit_df[class="hl-string">'fieldname'] == class="hl-string">'priority'].copy()
        escalated_df[class="hl-string">'old_priority_val'] = escalated_df[class="hl-string">'oldvalue'].map(priority_map)
        escalated_df[class="hl-string">'new_priority_val'] = escalated_df[class="hl-string">'newvalue'].map(priority_map)
        escalated_df.dropna(subset=[class="hl-string">'old_priority_val', class="hl-string">'new_priority_val'], inplace=True)
        escalated_df = escalated_df[escalated_df[class="hl-string">'new_priority_val'] < escalated_df[class="hl-string">'old_priority_val']]
        escalated_df[class="hl-string">'ActivityName'] = class="hl-string">'Incident Escalated'
        event_log_frames.append(escalated_df)
        
        class=class="hl-string">"hl-comment"># Activity: Incident Linked To Problem
        linked_problem_df = audit_df[(audit_df[class="hl-string">'fieldname'] == class="hl-string">'problem_id') & (audit_df[class="hl-string">'newvalue'].notna())].copy()
        linked_problem_df = linked_problem_df.drop_duplicates(subset=[class="hl-string">'sys_id'], keep=class="hl-string">'first')
        linked_problem_df[class="hl-string">'ActivityName'] = class="hl-string">'Incident Linked To Problem'
        event_log_frames.append(linked_problem_df)
        
        class=class="hl-string">"hl-comment"># Activity: Resolution Proposed (State changed to Resolved)
        resolved_df = audit_df[audit_df[class="hl-string">'fieldname'] == class="hl-string">'state'].copy()
        class=class="hl-string">"hl-comment"># Note: Common value for class="hl-string">'Resolved' is class="hl-string">'6'. Adjust if needed.
        resolved_df = resolved_df[resolved_df[class="hl-string">'newvalue'].isin([class="hl-string">'6', class="hl-string">'Resolved'])]
        resolved_df[class="hl-string">'ActivityName'] = class="hl-string">'Resolution Proposed'
        event_log_frames.append(resolved_df)
        
        class=class="hl-string">"hl-comment"># Activity: Awaiting User Confirmation (State changed to Awaiting User Info, after resolved)
        class=class="hl-string">"hl-comment"># This logic is complex and dependent on workflow. A simplified version is shown.
        state_changes = audit_df[audit_df[class="hl-string">'fieldname'] == class="hl-string">'state'].copy()
        state_changes[class="hl-string">'prev_state'] = state_changes.groupby(class="hl-string">'sys_id')[class="hl-string">'oldvalue'].shift(-1)
        awaiting_df = state_changes[
            (state_changes[class="hl-string">'newvalue'].isin([class="hl-string">'Awaiting User Info', class="hl-string">'3'])) & 
            (state_changes[class="hl-string">'oldvalue'].isin([class="hl-string">'Resolved', class="hl-string">'6']))
        ].copy()
        awaiting_df[class="hl-string">'ActivityName'] = class="hl-string">'Awaiting User Confirmation'
        event_log_frames.append(awaiting_df)

        class=class="hl-string">"hl-comment"># Activity: Incident Reopened
        reopened_df = audit_df[
            (audit_df[class="hl-string">'fieldname'] == class="hl-string">'state') & 
            (audit_df[class="hl-string">'oldvalue'].isin([class="hl-string">'6', class="hl-string">'7', class="hl-string">'Resolved', class="hl-string">'Closed']))
        ].copy()
        reopened_df[class="hl-string">'ActivityName'] = class="hl-string">'Incident Reopened'
        event_log_frames.append(reopened_df)
        
    class=class="hl-string">"hl-comment"># Activity: Support Comment Added
    if not journal_df.empty:
        comment_df = journal_df.copy()
        comment_df[class="hl-string">'ActivityName'] = class="hl-string">'Support Comment Added'
        event_log_frames.append(comment_df)

    class=class="hl-string">"hl-comment"># 4. Consolidate all event dataframes
    print(class="hl-string">"\n--- Consolidating Final Event Log ---")
    final_log = pd.DataFrame()
    for df in event_log_frames:
        if class="hl-string">'sys_created_on' in df.columns:
             df.rename(columns={class="hl-string">'sys_created_on': class="hl-string">'EventTime'}, inplace=True)
        if class="hl-string">'IncidentId' not in df.columns:
            continue class=class="hl-string">"hl-comment"># Skip frames that couldn't be processed
        
        common_cols = {
            class="hl-string">'IncidentId': None,
            class="hl-string">'ActivityName': None,
            class="hl-string">'EventTime': None,
            class="hl-string">'AssignedTo': None,
            class="hl-string">'AssignmentGroup': None,
            class="hl-string">'Priority': None,
            class="hl-string">'IncidentState': None
        }
        
        class=class="hl-string">"hl-comment"># Select and reorder columns, filling missing ones with None
        current_cols = {col: None for col in common_cols.keys()}
        df_subset = df[list(set(df.columns) & set(common_cols.keys()))].copy()
        final_log = pd.concat([final_log, df_subset], ignore_index=True)

    class=class="hl-string">"hl-comment"># 5. Final Cleaning and Formatting
    final_log.dropna(subset=[class="hl-string">'IncidentId', class="hl-string">'ActivityName', class="hl-string">'EventTime'], inplace=True)
    final_log[class="hl-string">'EventTime'] = pd.to_datetime(final_log[class="hl-string">'EventTime'])
    final_log.sort_values(by=[class="hl-string">'IncidentId', class="hl-string">'EventTime'], inplace=True)
    
    final_log[class="hl-string">'SourceSystem'] = SOURCE_SYSTEM_NAME
    final_log[class="hl-string">'LastDataUpdate'] = last_data_update
    
    class=class="hl-string">"hl-comment"># Reorder columns to the desired format
    final_log = final_log[[
        class="hl-string">'IncidentId', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate', 
        class="hl-string">'AssignedTo', class="hl-string">'AssignmentGroup', class="hl-string">'Priority', class="hl-string">'IncidentState'
    ]]

    class=class="hl-string">"hl-comment"># 6. Save to CSV
    output_filename = class="hl-string">'servicenow_incident_event_log.csv'
    final_log.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%S.%f')
    print(fclass="hl-string">"\nSuccessfully extracted {len(final_log)} events for {final_log['IncidentId'].nunique()} incidents.")
    print(fclass="hl-string">"Event log saved to {output_filename}")

Prêt à commencer ?

Ce modèle contient tous les éléments nécessaires pour commencer votre démarche de Process Mining appliqué à la gestion des incidents. Commencez dès aujourd’hui à transformer votre processus de résolution des incidents.

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

Résolvez vos incidents plus rapidement : améliorez dès maintenant l’efficacité de ServiceNow

Réduisez le MTTR de 35 % dans ServiceNow. Identifiez les problèmes et améliorez la satisfaction.

Démarrer l’essai gratuit

Aucune carte bancaire requise. Commencez à optimiser vos processus en quelques minutes.

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

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

Attributs de la Gestion des incidents

Activités de la Gestion des incidents

Guides d’extraction

Extraction directe via l’API REST Table de ServiceNow

Étapes

Configuration

a Exemple de requête javascript

Extraction par script Python à l’aide de l’API REST ServiceNow

Étapes

Configuration

a Exemple de requête python

Prêt à commencer ?

Résolvez vos incidents plus rapidement : améliorez dès maintenant l’efficacité de ServiceNow

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

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

Attributs de la Gestion des incidents

Activités de la Gestion des incidents

Guides d’extraction

Extraction directe via l’API REST Table de ServiceNow

Étapes

Configuration

a Exemple de requête javascript

Extraction par script Python à l’aide de l’API REST ServiceNow

Étapes

Configuration

a Exemple de requête python

Prêt à commencer ?

Résolvez vos incidents plus rapidement : améliorez dès maintenant l’efficacité de ServiceNow

Nous attachons de l’importance à votre confidentialité