> Amélioration Continue des Processusus > Gestion des incidents > ServiceNow Gestion des problèmes > Template de données

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

ServiceNow - Gestion des problèmes

← Retour au Guide d'amélioration

Attributs de gestion des incidents (19) Activités de gestion des incidents (13) Guides d'extraction (2)

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

Ce modèle fournit un guide détaillé pour la collecte des données nécessaires à l'analyse et à l'optimisation de votre processus de gestion des incidents. Il décrit les attributs de données essentiels à collecter, les activités clés à suivre, et des conseils pratiques sur la manière d'extraire ces informations de votre système source. Utilisez cette ressource pour générer un journal d'événements fiable pour une analyse et une amélioration approfondies des processus.

Attributs recommandés à collecter
Activités clés à suivre
Guide d'extraction pour ServiceNow Incident Management

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

Télécharger le modèle

Attributs de gestion des incidents

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

5 Obligatoire 4 Recommandé 10 Facultatif

	Nom	Descriptionn
	Heure de l'événement EventTime	L'horodatage précis indiquant quand l'activité s'est produite.
Descriptionn L'horodatage de l'événement, souvent appelé horodatage, enregistre la date et l'heure exactes auxquelles une activité a été accomplie ou un changement de statut s'est produit. Dans ServiceNow, cela est généralement capturé dans le champ sys_updated_on pour chaque modification enregistrée dans le piste d'audit. Cet attribut est indispensable pour séquencer correctement les événements et pour toute analyse basée sur le temps. Il est utilisé pour calculer les temps de cycle, les temps d'attente et les durées entre les activités, qui sont fondamentaux pour identifier les points de blocage, mesurer les performances par rapport aux SLA et comprendre l'efficacité des processus. La précision de ces horodatages est indispensable pour la validité de toute métrique basée sur la durée. Pourquoi est-ce important ? : Cet horodatage ordonne toutes les activités chronologiquement et permet le calcul de toutes les métriques basées sur la durée, telles que les temps de cycle et les points de blocage. Source des données : Table sys_audit de ServiceNow, champ sys_created_on ou le 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 d'incident IncidentId	L'identifiant unique pour chaque enregistrement d'incident, servant de clé primaire pour le suivi de l'intégralité du cycle de vie.
Descriptionn L'ID d'incident est le numéro de référence unique attribué à chaque incident signalé dans ServiceNow. Il agit comme l'identifiant de dossier principal qui relie toutes les activités, mises à jour et communications connexes, depuis la création d'un incident jusqu'à sa clôture. Dans l'analyse par Process Mining, cet ID est clé. Il permet à l'outil d'assembler la séquence des événements pour chaque cas individuel, constituant la base pour la découverte de cartes de processus, l'analyse des variantes et le calcul des durées complet. Sans un ID d'incident unique pour chaque cas, il serait impossible de tracer le parcours d'un incident tout au long du processus de résolution. Pourquoi est-ce important ? : C'est l'identifiant de cas principal qui relie tous les événements du cycle de vie d'un incident, permettant l'analyse de processus complet. Source des données : Table incident de ServiceNow, champ number. Exemples INC0010001INC0010045INC0010239
	Nom de l'activité ActivityName	Le nom de l'événement ou de la tâche spécifique qui s'est produit à un moment donné du cycle de vie de l'incident.
Descriptionn Le nom de l'activité décrit une étape spécifique ou un changement de statut dans le processus de gestion des incidents, tels que 'Incident créé', 'Affecté à l'agent' ou 'Incident clos'. Ces données sont généralement dérivées des modifications apportées aux champs clés de l'incident comme État ou Groupe d'affectation, ou d'entrées de journal spécifiques. Cet attribut est impératif pour construire la cartographie des processus. Il définit les nœuds du graphe de processus, permettant aux analystes de visualiser le flux des incidents, d'identifier les parcours courants, de identifier les points de blocage entre les activités et d'analyser les variantes de processus. La granularité et la précision de ces noms d'activités ont un impact direct sur la qualité de l'analyse des processus. Pourquoi est-ce important ? : Il définit les étapes de la cartographie des processus, ce qui sert de base à toute analyse et visualisation en Process Mining. Source des données : Il s'agit d'un attribut dérivé, généralement généré par la logique de transformation des données basée sur les modifications des champs comme state, assignment_group et assigned_to dans les tables sys_audit ou incident. Exemples Incident crééGroupe d'affectation changéRésolution ProposéeIncident fermé
	Dernière mise à jour des données LastDataUpdate	L'horodatage indiquant la dernière actualisation des données de cet enregistrement depuis le système source.
Descriptionn Cet attribut consigne la date et l'heure de la dernière extraction ou mise à jour des données de ServiceNow. Il s'agit d'un champ de métadonnées qui reflète la la réactualisation des données analysées, et non un événement du processus lui-même. Cette information est indispensablele pour comprendre la pertinence temporelle de l'analyse. Elle indique aux utilisateurs si les données sont à jour, ce qui est important pour les dashboards opérationnels et pour prendre des décisions basées sur des événements récents. Elle aide à gérer les attentes concernant la pertinence et la récence des données. Pourquoi est-ce important ? : Il informe les utilisateurs de la la réactualisation des données, ce qui est impératif pour la pertinence et la précision de l'analyse. Source des données : Cet horodatage est généré et renseigné par l'outil ou le processus d'extraction des données au moment du chargement des données. Exemples 2023-10-27T02:00:00Z2023-10-28T02:00:00Z
	Système source SourceSystem	Le système à partir duquel ces données ont été extraites.
Descriptionn Cet attribut identifie l'origine des données d'incident, qui est ici ServiceNow Incident 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ù des données provenant de plusieurs systèmes peuvent être combinées pour l'analyse, ce champ est indispensable pour la traçabilité et la ségrégation des données. Il garantit que les métriques 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 est-ce important ? : Il fournit un contexte essentiel sur l'origine des données, garantissant la traçabilité des données et permettant une interprétation correcte dans les environnements multi-systèmes. Source des données : Il s'agit généralement d'une valeur statique ajoutée lors du processus d'extraction des données. Exemples ServiceNow - Gestion des problèmesServiceNow
	Attribué à AssignedTo	L'utilisateur individuel ou l'agent actuellement affecté à l'incident.
Descriptionn Cet attribut identifie l'agent de support spécifique responsable de l'incident à un moment donné. Cette information est indispensablele pour comprendre la répartition de la charge de travail, la performance des agents et les transferts entre individus. Dans l'analyse, 'Assigned To' aide à visualiser l'allocation des ressources et à identifier les agents surchargés. Il est également utilisé dans le tableau de bord « Transferts et réaffectations » pour suivre le nombre de fois qu'un incident change de responsable, ce qui peut être un indicateur d'inefficacité ou de lacunes de connaissances. L'analyse des temps de résolution par agent peut également mettre en évidence les plus performants ou ceux qui ont besoin d'une formation complémentaire. Pourquoi est-ce important ? : Il permet d'analyser la charge de travail des agents, leurs performances et les transferts individuels, éléments clés pour comprendre l'efficacité des ressources. Source des données : Table incident de ServiceNow, champ assigned_to. Exemples Beth AnglinDavid LooHoward Johnson
	État de l'incident IncidentState	Le statut actuel de l'incident dans son cycle de vie.
Descriptionn L'État de l'incident indique la phase actuelle de l'incident, telle que 'Nouveau', 'En cours', 'En attente' ou 'Résolu'. Les changements d'État sont souvent la source principale pour générer des activités dans le journal d'événements pour le Process Mining. L'analyse du temps passé dans chaque état est un moyen puissant d'identifier les points de blocage. Par exemple, une longue durée dans l'état 'En attente' peut indiquer des dépendances vis-à-vis de facteurs externes ou d'utilisateurs. La séquence des changements d'état constitue également la base de la cartographie des processus, montrant comment les incidents progressent vers la résolution. Pourquoi est-ce important ? : Il suit la progression de l'incident et est indispensable pour analyser le temps passé dans les différentes étapes et identifier les points de blocage du processus. Source des données : Table incident de ServiceNow, champ incident_state ou state. Exemples NouveauEn coursEn attente d'informations utilisateurRésoluClôturé
	Groupe d'assignation AssignmentGroup	L'équipe de support ou le groupe responsable de la gestion de l'incident.
Descriptionn Le Groupe d'affectation représente l'équipe d'agents chargée de résoudre l'incident. Les incidents sont souvent acheminés entre différents groupes, par exemple d'un centre d'assistance de Niveau 1 à une équipe réseau spécialisée de Niveau 2. Cet attribut est indispensable pour analyser les transferts inter-équipes et identifier les points de blocage systémiques. Le tableau de bord 'Taux de transfert et de réaffectation' s'appuie fortement sur ces données pour montrer quelles équipes sont fréquemment impliquées dans les transferts. Il permet également des comparaisons de performance entre différents groupes de support et aide à comprendre où se situe l'expertise en matière de résolution dans l'organisation. Pourquoi est-ce important ? : Il permet de suivre l'équipe responsable, ce qui permet l'analyse de la performance de l'équipe, de la charge de travail et des transferts entre groupes. Source des données : Table incident de ServiceNow, champ assignment_group. Exemples Centre de servicesSupport RéseauAdministrateurs de bases de données
	Priorité Priority	Le niveau de priorité de l'incident, qui dicte l'urgence de la réponse requise.
Descriptionn La priorité est un champ clé dans ServiceNow qui détermine l'ordre et la rapidité de traitement d'un incident. Elle est généralement dérivée de l'impact et de l'urgence de l'incident, et elle influence directement les objectifs de SLA. Cet attribut est indispensable pour la segmentation et l'analyse de la performance. Le tableau de bord 'Aperçu de la conformité aux SLA' utilise la priorité pour évaluer si les incidents de haute priorité sont résolus dans les délais impartis. L'analyse des temps de cycle par priorité aide à confirmer que les incidents critiques sont effectivement traités plus rapidement que ceux de moindre importance. C'est une dimension essentielle pour presque tous les KPI et dashboards. Pourquoi est-ce important ? : Il permet de segmenter les incidents par importance métier, ce qui est impératif pour le suivi de la conformité aux SLA et l'allocation des ressources. Source des données : Table incident de ServiceNow, champ priority. Exemples 1 - Critique2 - Élevée3 - Modérée4 - Faible
	Appelant CallerId	L'utilisateur qui a initialement signalé l'incident.
Descriptionn Le Demandeur identifie l'utilisateur final ou le client affecté par l'incident et qui l'a signalé. Cette information fournit un contexte sur les personnes impactées par les interruptions de service. Bien que n'étant pas toujours au centre du flux de processus lui-même, l'analyse des incidents par demandeur peut révéler si des individus ou des départements spécifiques sont affectés de manière disproportionnée par des problèmes. Cela peut indiquer des besoins de formation ou des problèmes environnementaux localisés. Cela fournit également un lien direct avec le client pour les enquêtes de satisfaction et la communication. Pourquoi est-ce important ? : Il identifie l'utilisateur concerné, permettant une analyse par service ou par individu et fournissant un contexte pour la communication avec l'utilisateur. Source des données : Table incident de ServiceNow, champ caller_id. Exemples Abel TuterCarolina PashDon Goodliffe
	Catégorie Category	La classification de haut niveau de l'incident, telle que Matériel, Logiciel ou Réseau.
Descriptionn La Catégorie fournit une classification générale de la nature d'un incident. Ceci, souvent en combinaison avec une sous-catégorie, aide à acheminer l'incident vers l'équipe de support appropriée et est utilisé pour les rapports et l'analyse des tendances. Pour le Process Mining, cet attribut est impératif pour les dashboards 'Précision de la catégorisation des incidents' et 'Volume des 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 de triage initial. Filtrer la cartographie des processus par catégorie peut également révéler si certains types d'incidents suivent des chemins de résolution différents ou subissent des points de blocage uniques. Pourquoi est-ce important ? : Il permet d'analyser les types d'incidents, aide à mesurer la précision de la catégorisation et est indispensable pour l'acheminement et l'analyse des tendances. Source des données : Table incident de ServiceNow, champ category. Exemples HardwareLogicielRéseauBase de données
	Code de Résolution ResolutionCode	Un code indiquant le mode de résolution final de l'incident.
Descriptionn Le Code de résolution spécifie la nature de la solution appliquée, par exemple, si l'incident a été résolu par un utilisateur, suite à une erreur connue, ou si une solution de contournement a été apportée. Ce champ est généralement rempli par l'agent lors de la clôture de l'incident. Cet attribut contribue directement au le tableau de bord 'Efficacité des types de résolution'. Il permet l'analyse du nombre d'incidents clos avec des correctifs permanents par rapport aux solutions de contournement temporaires, ce qui est un indicateur clé de la qualité de service et de la stabilité à long terme. Un taux élevé de solutions de contournement pourrait suggérer que les problèmes sous-jacents ne sont pas traités de manière adéquate. Pourquoi est-ce important ? : Il clarifie la méthode de résolution, permettant l'analyse des correctifs permanents par rapport aux solutions de contournement temporaires et soutenant l'analyse des causes profondes. Source des données : Table incident de ServiceNow, champ close_code ou un champ de code de résolution personnalisé. 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 est censé être résolu conformément à son SLA.
Descriptionn La Date d'échéance SLA est un horodatage calculé qui représente la date limite de résolution d'un incident. Cette date est déterminée par l'Accord de niveau de service (SLA) associé aux caractéristiques de l'incident, telles que sa priorité. Cet attribut est indispensable pour le tableau de bord 'Vue d'ensemble de la conformité SLA' et le KPI 'Taux de non-respect SLA des incidents critiques'. Il sert de référence par rapport à laquelle le délai de résolution réel est comparé. L'analyse des incidents proches de leur date d'échéance SLA peut aider à l'escalade proactive et à la priorisation. Pourquoi est-ce important ? : Il définit l'objectif de résolution, permettant de mesurer la conformité aux SLA et d'identifier les incidents risquant de ne pas atteindre leurs objectifs. Source des données : Cette valeur se trouve généralement dans la table task_sla, qui est liée à la table incident. Le champ planned_end_time est l'horodatage pertinent. Exemples 2023-05-20T17:00:00Z2023-06-01T09:00:00Z
	Élément de configuration ConfigurationItem	Le composant IT, service ou actif spécifique affecté par l'incident.
Descriptionn L'Élément de configuration (CI) est l'actif de la base de données de gestion de la configuration (CMDB) qui est affecté par l'incident. Cela peut être un serveur, une application, un ordinateur portable ou un périphérique réseau. L'analyse des incidents par CI est extrêmement précieuse pour identifier les actifs ou services peu fiables. Elle aide à déterminer quelles parties de l'infrastructure informatique génèrent le plus d'incidents, ce qui peut guider les investissements en mises à niveau ou en 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 d'autres. Pourquoi est-ce important ? : Il identifie l'actif concerné, aidant à localiser les composants problématiques dans l'infrastructure informatique et à concentrer les efforts d'amélioration. Source des données : Table incident de ServiceNow, champ cmdb_ci. Exemples Production SAP ERPServeur Oracle DB 05Service de messagerie
	Gravité Severity	Le niveau d'impact commercial causé par l'incident.
Descriptionn La gravité définit l'ampleur de l'impact d'un incident sur les opérations commerciales. Avec l'urgence, elle est souvent utilisée pour calculer automatiquement la priorité de l'incident. En analyse, la gravité est une dimension clé pour le tableau de bord 'Aperçu de la conformité aux SLA'. Elle aide les organisations à comprendre si elles respectent les niveaux de service pour les incidents les plus perturbateurs. Elle offre une vue de la performance centrée sur l'entreprise, complétant la vue opérationnelle fournie par la priorité. Pourquoi est-ce important ? : Il mesure l'impact métier d'un incident, offrant une dimension cruciale pour prioriser les efforts et analyser la performance relative aux problèmes critiques. Source des données : Table incident de ServiceNow, champ severity. Exemples 1 - Élevée2 - Moyenne3 - Faible
	ID du problème ProblemId	L'identifiant de l'enregistrement de problème associé si l'incident est lié à un problème plus vaste.
Descriptionn L'ID de problème relie un incident à un enregistrement correspondant dans le module de Gestion des problèmes. Cela se produit lorsqu'un incident est identifié comme un symptôme d'un problème sous-jacent plus vaste qui affecte plusieurs utilisateurs ou services. Cette association est indispensablele pour le tableau de bord 'Volume des incidents récurrents' et le KPI 'Taux d'incidents récurrents'. Elle permet aux analystes de regrouper les incidents qui découlent de la même cause racine, de mesurer l'impact total 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 réactif. Pourquoi est-ce important ? : Il relie les incidents à une cause profonde, ce qui est indispensable pour analyser les problèmes récurrents et mesurer l'impact de la gestion des problèmes. Source des données : Table incident de ServiceNow, champ problem_id. Exemples PRB0040001PRB0040015PRB0040102
	Incident rouvert IsReopened	Un indicateur signalant si un incident a été rouvert après avoir été résolu.
Descriptionn Cet indicateur booléen est mis à vrai si l'état d'un incident a été ramené à un état actif (par exemple, 'En cours') après avoir atteint un état 'Résolu' ou 'Fermé'. Cela est généralement identifié en recherchant une activité 'Incident rouvert' dans le journal d'événements. Les incidents rouverts sont un indicateur fort de résolutions incomplètes ou inefficaces. L'analyse de ces cas aide à identifier les clôtures prématurées ou les problèmes récurrents qui n'ont pas été correctement corrigés la première fois. Un taux élevé de réouverture peut avoir un impact négatif sur la satisfaction des utilisateurs et la productivité de l'équipe, ce qui en fait une métrique clé pour le contrôle qualité. Pourquoi est-ce important ? : Cet indicateur identifie les échecs dans le processus de résolution, en mettant en évidence les incidents qui ont nécessité un travail supplémentaire après avoir été considérés comme résolus. Source des données : Calculé en vérifiant la séquence des activités pour chaque incident afin de déterminer si un état 'open' suit un état 'resolved'. Exemples truefaux
	Nombre de Réaffectations ReassignmentCount	Le nombre de fois que l'incident a été réaffecté à un groupe ou à un agent différent.
Descriptionn Ce champ enregistre le nombre total de fois qu'un incident a été transféré entre différents groupes d'affectation. C'est une mesure directe de la friction du processus et il est souvent utilisé comme indicateur clé de performance. Cet attribut est le principal moteur du tableau de bord 'Taux de transfert et de réaffectation' et du KPI 'Nombre moyen de transferts par incident'. Un nombre élevé de réaffectations indique souvent des problèmes tels qu'un routage initial incorrect, un manque de compétences à un niveau de support, ou une responsabilité de processus mal définie. La réduction de ce nombre est un objectif commun pour les initiatives d'amélioration des processus, car elle conduit généralement à des temps de résolution plus rapides. Pourquoi est-ce important ? : Il mesure directement les transferts de processus, un indicateur clé d'inefficacité, de routage incorrect et d'opportunités d'amélioration. Source des données : Table incident de ServiceNow, champ reassignment_count. Exemples 0135
	SLA dépassé IsSlaBreached	Un indicateur signalant si la résolution de l'incident a dépassé la date d'échéance de son SLA.
Descriptionn Il s'agit d'un attribut booléen calculé qui signale les incidents ayant enfreint leur accord de niveau de service. Il est dérivé en comparant l'horodatage de résolution réel avec la 'Date d'échéance SLA'. Si le temps de résolution est postérieur à la date d'échéance, l'indicateur est mis à vrai. Cet attribut est la base du tableau de bord 'Vue d'ensemble de la conformité SLA' et des KPI associés. Il simplifie l'analyse en convertissant une comparaison temporelle complexe en une simple dimension vrai/faux, ce qui facilite le filtrage de tous les incidents en infraction et l'analyse de leurs caractéristiques communes, telles que la catégorie, le groupe d'affectation ou la priorité. Pourquoi est-ce important ? : Il simplifie l'analyse de la conformité aux SLA, permettant un filtrage facile et une analyse détaillée de tous les incidents qui n'ont pas atteint leurs objectifs. Source des données : Calculé en comparant l'horodatage 'Resolved At' avec l'horodatage 'SlaDueDate'. (Resolved At > SlaDueDate). Exemples truefaux

Obligatoire Recommandé Facultatif

Activités de gestion des incidents

Voici les étapes clés du processus et les jalons à capturer dans votre journal d'événements pour une découverte et une optimisation précises des processus.

6 Recommandé 7 Facultatif

	Activité	Descriptionn
	Groupe d'affectation changé	Représente un transfert où un incident est déplacé d'un groupe de support à un autre. Ceci est capturé en observant les changements ultérieurs du champ assignment_group après son attribution initiale.
Pourquoi est-ce important ? : Les réaffectations fréquentes peuvent indiquer un routage initial incorrect, une complexité de processus ou des lacunes en matière de connaissances. Cette activité est indispensablele pour mesurer le KPI ('KPI') « Nombre moyen de transferts par incident ». Source des données : Déduit de la table 'sys_audit' en suivant tout changement apporté au champ 'assignment_group' après l'affectation initiale. Capture Identifiez chaque modification horodatée (horodatageed) du champ 'assignment_group' dans le journal d'audit. Type d'événement inferred
	Incident assigné à un groupe	Cette activité se produit lorsqu'un incident est affecté à un groupe de support spécifique pour traitement. C'est une étape clé du processus d'acheminement et elle est capturée en observant les modifications apportées au champ du groupe d'affectation.
Pourquoi est-ce important ? : Le suivi des affectations est indispensable pour analyser les transferts, les temps d'attente pour chaque groupe, et identifier les inefficacités de routage ou les points de blocage. Source des données : Déduit de la table 'sys_audit' en suivant le moment où le champ 'assignment_group' de la table 'incident' est renseigné ou modifié. Capture Utilisez l'horodatage du journal d'audit pour les modifications du champ assignment_group. Type d'événement inferred
	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 à l'aide de l'horodatage de création de l'enregistrement d'incident.
Pourquoi est-ce important ? : C'est l'événement de début principal du processus. L'analyse du temps écoulé entre cette activité et la résolution est clée pour mesurer le temps de cycle global et la conformité aux SLA. Source des données : L'horodatage sys_created_on de la table incident sert de horodatage de l'événement explicite pour cette activité. Capture Utilisez l'horodatage sys_created_on de l'enregistrement d'incident. Type d'événement explicit
	Incident fermé	C'est l'activité finale du cycle de vie, signifiant que l'incident est entièrement résolu, confirmé et qu'aucune action supplémentaire n'est requise. L'événement est capturé explicitement via l'horodatage de clôture.
Pourquoi est-ce important ? : En tant qu'event de fin définitif, cette activité est indispensablele pour calculer la durée totale du cycle de vie des incidents et analyser le temps nécessaire au traitement post-résolution. Source des données : L'horodatage closed_at de la table incident sert de horodatage de l'événement explicite. Il est généralement défini lorsque le champ state passe à Closed. Capture Utilisez l'horodatage closed_at de l'enregistrement d'incident. Type d'événement explicit
	Résolution Proposée	Marque le moment où un agent de support a mis en œuvre un correctif et a fait passer l'incident à l'état « Résolu ». Il s'agit d'une étape clé précédant la clôture finale.
Pourquoi est-ce important ? : Cette activité marque la fin du travail actif et le début de la phase de confirmation. Le temps écoulé entre cette étape et la 'Fermeture de l'incident' peut révéler des retards dans la confirmation ou la vérification par l'utilisateur. Source des données : Déduit de la table 'sys_audit' lorsque le champ 'state' de la table 'incident' passe à « Résolu ». L'horodatage 'resolved_at' est souvent renseigné à ce moment-là. Capture Utilisez l'horodatage lorsque le champ state devient Resolved ou l’horodatage resolved_at. Type d'événement inferred
	Travail commencé	Indique qu'un agent a commencé à enquêter activement ou à travailler sur l'incident. Cela est généralement déduit lorsque l'état de l'incident passe de « Nouveau » ou « Attribué » à un état actif comme « En cours ».
Pourquoi est-ce important ? : Cette étape marque la fin du temps d'attente initial et le début des efforts de résolution concrets. Mesurer le temps avant le début du travail est indispensable pour l'analyse des points de blocage. Source des données : Déduit de la table 'sys_audit' en identifiant le moment où le champ 'state' de la table 'incident' passe à une valeur représentant un travail actif, telle que « En cours ». Capture Identifiez l'horodatage lorsque le champ 'state' passe à 'In Progress' ou une valeur similaire. Type d'événement inferred
	Commentaire de support ajouté	Un agent de support ajoute une note de travail ou un commentaire visible par l'utilisateur. C'est un événement explicite enregistré dans le flux d'activité de l'incident.
Pourquoi est-ce important ? : Assure le suivi des efforts de communication et d'investigation de l'équipe de support. L'analyse de la fréquence et de la temporalité de ces commentaires offre un aperçu précieux du processus d'enquête. Source des données : Capturé à partir de la table 'sys_journal_field', qui enregistre les entrées pour les champs 'work_notes' et 'comments' sur la table 'incident'. Capture Utilisez l'horodatage de création des entrées de journal où 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 que l'utilisateur confirme que la résolution proposée a été réussie. Ceci est généralement déduit d'un état spécifique comme 'En attente d'informations utilisateur' après avoir été résolu.
Pourquoi est-ce important ? : Cet état peut constituer un goulot d'étranglement significatif si les utilisateurs tardent à répondre. Mesurer le temps passé dans cette activité aide à identifier les lacunes de communication et les opportunités d'automatisation de la clôture. Source des données : Déduit de la table 'sys_audit' en identifiant un changement vers un état en attente spécifique après la résolution. Le nom de l'état peut être personnalisé, tel que « En attente de l'appelant ». Capture Identifiez l'horodatage lorsque l'état ('state') change pour une valeur indiquant une attente d'entrée utilisateur. Type d'événement inferred
	Incident assigné à un agent	Représente le moment où un agent spécifique au sein d'un groupe de support prend en charge l'incident. Ceci est capturé en surveillant les modifications du champ assigned_to.
Pourquoi est-ce important ? : Cela offre une vue granulaire de la charge de travail des agents et de la résolution au premier contact. Cela aide à déterminer combien de temps les incidents attendent qu'un individu commence le travail après avoir été affectés à un groupe. Source des données : Déduit de la table 'sys_audit' en suivant le moment où le champ 'assigned_to' de la table 'incident' est renseigné ou modifié. Capture Utilisez l'horodatage du journal d'audit pour les modifications du champ assigned_to. Type d'événement inferred
	Incident catégorisé	Représente la classification initiale de l'incident, où des champs comme Category, Subcategory et Priority sont définis. 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 est-ce important ? : Une catégorisation précise est indispensablele pour un acheminement et une priorisation corrects. Le suivi de cette activité aide à analyser les taux de recatégorisation et leur impact sur le temps de résolution. Source des données : Déduit de la table 'sys_audit' en identifiant le premier changement apporté à des champs tels que 'category', 'subcategory' ou 'priority' pour un incident donné. Capture 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 est augmentée, nécessitant souvent une réponse plus rapide ou des ressources différentes. Cela est déduit en détectant un changement à la hausse de la valeur du champ 'priority'.
Pourquoi est-ce important ? : Les escalades indiquent souvent qu'un incident est plus grave qu'initialement perçu ou qu'il approche d'un manquement au SLA. L'analyse de ces événements aide à comprendre les exceptions de processus. Source des données : Déduit de la table 'sys_audit' en identifiant un changement du champ 'priority' vers une valeur de priorité plus élevée. Capture Détecter quand la valeur du champ 'priority' augmente (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 formellement associé à un dossier de problème, ce qui indique qu'il fait partie d'une problématique sous-jacente plus vaste. Cela est déduit lorsque le champ 'problem_id' du dossier d'incident est renseigné.
Pourquoi est-ce important ? : Le lien vers un problème est une étape critique pour passer de la correction réactive des incidents à l'analyse proactive des causes profondes. Il alimente le tableau de bord « Volume d'incidents récurrents ». Source des données : Déduit en détectant le moment où le champ de référence 'problem_id' de la table 'incident' est renseigné avec une valeur. Capture Identifiez l'horodatage du journal d'audit lorsque 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 avoir été marqué comme résolu. Cela est déduit lorsque l'état de l'incident passe de « Résolu » à un état actif comme « En cours ».
Pourquoi est-ce important ? : Les incidents rouverts indiquent des résolutions échouées et représentent des retouches. Suivre cette activité est indispensable à mesurer la qualité de la résolution et les taux de résolution au premier contact. Source des données : Déduit de la table 'sys_audit' en détectant une transition du champ 'state' de « Résolu » vers un état actif comme « En cours » ou « Attribué ». Capture Identifiez l'horodatage lorsque l'état ('state') passe de 'Resolved' à une valeur active. Type d'événement inferred

Recommandé Facultatif

Guides d'extraction

Comment obtenir vos données de ServiceNow Incident Management

Étapes

Configurer l'accès à ServiceNow : Obtenez les identifiants d'un compte de service dans ServiceNow. Ce compte doit disposer de permissions de lecture (ACLs) pour la table incident, la table sys_audit et tous les champs requis, y compris 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 : Assurez-vous que Node.js est installé sur la machine qui exécutera le script d'extraction. Installez la bibliothèque axios pour effectuer des 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. Remplissez les valeurs de substitution pour l'URL de votre instance ServiceNow, votre nom d'utilisateur et votre mot de passe en haut du script.
Définir les paramètres d'extraction : Ajustez les variables startDate et endDate dans le script pour définir la période d'extraction des incidents que vous souhaitez. Pour les premières exécutions, il est recommandé d'utiliser une petite plage de dates, comme une semaine, pour valider les résultats.
Exécuter le script : Exécutez le script depuis votre terminal à l'aide de la commande node extract_incidents.js. Le script commencera à récupérer les données d'incident et leurs journaux d'audit correspondants à partir de l'API ServiceNow.
Suivre la progression du script : Le script enregistrera la progression dans la console, affichant le nombre d'incidents traités. Sachez que pour les grands ensembles de données, ce processus peut prendre un temps considérable en raison du nombre d'appels API requis.
Traiter les réponses de l'API : Le script itère de manière programmatique sur chaque incident. Pour chaque incident, il interroge la table sys_audit pour 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 inférées : Le script contient une logique pour inférer les activités à partir des modifications de champ. Par exemple, 'Incident Escalated' est créé lorsque la nouvelle valeur du champ priority est inférieure (indiquant une priorité plus élevée) à son ancienne valeur. 'Work Started' est identifié par le premier changement d'état à 'In Progress'.
Structurer le journal d'événements : Lorsque les activités sont identifiées, elles sont formatées en enregistrements de journal d'événements, chaque enregistrement contenant les colonnes requises : IncidentId, (ActivityName), (EventTime) et d'autres.
Enregistrer la sortie : Une fois le script terminé, il enregistrera le journal d'événements généré sous la forme d'un fichier JSON nommé servicenow_incident_event_log.json dans le même répertoire. Ce fichier contient un tableau de tous les événements extraits.
Convertir en CSV : Pour l'importation dans ProcessMind, vous devrez peut-être convertir la sortie JSON finale en un fichier CSV. Utilisez un outil de données standard ou un script simple pour transformer le tableau JSON en un format CSV tabulaire, en vous assurant que les en-têtes de colonne correspondent aux attributs requis.

Configuration

API Endpoint : Le script cible deux principaux points de terminaison de l'API de table ServiceNow :
- https://[Votre instance ServiceNow].service-now.com/api/now/table/incident
- https://[Votre instance ServiceNow].service-now.com/api/now/table/sys_audit
Authentication : Le script fourni utilise l'authentification de base (username et password). Assurez-vous que les informations d'identification du compte de service sont correctes et que le compte est actif.
Filtrage par plage de dates : La requête est filtrée par la date de création de l'incident (sys_created_on). Ceci est configuré via les variables startDate et endDate dans le script. Il est recommandé d'extraire 3 à 6 mois de données pour une analyse pertinente, mais commencez par une période plus courte pour les tests.
Key Query Parameters :
- sysparm_query : Utilisé pour filtrer les enregistrements. Le script construit une chaîne de requête encodée pour filtrer les incidents par date de création.
- sysparm_fields : Spécifie les colonnes à récupérer, réduisant la taille de la charge utile de l'API et améliorant les performances.
- sysparm_limit : Gère la pagination en définissant le nombre d'enregistrements à retourner par requête. Le script utilise une limite de 1000, ce qui est une pratique courante.
- sysparm_offset : Utilisé conjointement avec sysparm_limit pour récupérer les pages de données suivantes.
Considérations relatives aux performances : L'interrogation de la table sys_audit pour chaque incident est gourmande en ressources. Pour les très grandes instances ServiceNow, envisagez d'exécuter l'extraction pendant les heures creuses. Le script traite les incidents séquentiellement pour éviter de surcharger l'API, mais cela peut prolonger la durée d'exécution totale.
Prérequis : Un environnement Node.js est requis pour exécuter le script. L'utilisateur ou le compte de service exécutant l'extraction doit disposer des permissions de lecture nécessaires (ACLs) 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 : Assurez-vous d'avoir Python 3.6+ installé sur votre système. Installez les bibliothèques nécessaires en utilisant pip : pip install requests pandas.
Configuration ServiceNow : Créez un compte de service dédié dans ServiceNow pour cette extraction. Accordez à cet utilisateur les rôles itil et rest_api_explorer pour vous assurer qu'il dispose d'un accès en lecture aux tables requises (incident, sys_audit, sys_journal_field).
Configuration du Script : Ouvrez le script Python fourni. Localisez la section de configuration en haut et remplacez les valeurs 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 fenêtre d'extraction souhaitée.
Exécution du Script : Exécutez le script depuis votre ligne de commande à l'aide de python your_script_name.py. Le script commencera à s'authentifier auprès de ServiceNow et à effectuer des appels API.
Récupération des données : Le script récupère d'abord une liste de tous les incidents créés dans la plage de dates spécifiée à partir de la table incident. Il utilise ensuite cette liste d'ID d'incidents pour récupérer tout l'historique d'audit associé de sys_audit et tous les commentaires de sys_journal_field.
Génération du journal d'événements : Le script traite les données brutes en mémoire. Il itère sur les activités prédéfinies, générant un jeu de lignes distinct pour chacune. Par exemple, il identifie l'événement 'Incident Created' à partir du champ sys_created_on et l'événement 'Incident Closed' à partir du champ closed_at. Pour les autres événements, il analyse le journal d'audit pour identifier les transitions d'état, les modifications de champ et les escalades.
Mappage des attributs : Pour chaque ligne d'événement générée, le script effectue une recherche pour l'enrichir avec des attributs contextuels de l'enregistrement d'incident principal, tels que AssignmentGroup, AssignedTo, Priority et IncidentState au moment de l'événement.
Consolidation des données : Tous les DataFrames d'événements individuels (un pour chaque type d'activité) sont combinés en un seul DataFrame de journal d'événements complet.
Transformation Finale : Le DataFrame consolidé est trié par IncidentId et (EventTime) pour garantir l'ordre chronologique correct des événements pour chaque cas. Les colonnes SourceSystem et LastDataUpdate sont ajoutées avec des valeurs statiques.
Exportation 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 où le script a été exécuté. Ce fichier est prêt à être importé dans un logiciel de Process Mining.

Configuration

ServiceNow Instance (SNOW_INSTANCE) : L'URL complète de votre instance ServiceNow, par exemple, https://yourcompany.service-now.com.
Identifiants (SNOW_USER, SNOW_PASSWORD) : Détails d'authentification pour le compte de service. Pour les environnements de production, envisagez d'utiliser l'authentification OAuth ou par token au lieu de l'authentification de base.
Plage de dates (START_DATE, END_DATE) : Définit la fenêtre temporelle pour l'extraction, basée sur la date de création de l'incident. Une plage de 3 à 6 mois est recommandée pour une analyse initiale afin d'équilibrer le volume de données et les informations. Des plages plus larges augmenteront considérablement le temps d'extraction.
API Query Parameters (sysparm_query) : Le script utilise un sysparm_query pour filtrer les incidents par leur date de création (sys_created_on). Vous pouvez ajouter d'autres conditions ici pour affiner la portée, par exemple, active=false^company=[Your Company Sys ID] pour extraire uniquement les incidents clôturés pour une entreprise spécifique.
Limitation du débit de l'API : Soyez conscient des limites de débit de l'API de ServiceNow. Le script gère la pagination mais n'inclut pas de gestion explicite des limites de débit. Pour les très grandes instances, vous devrez peut-être ajouter des appels time.sleep() entre les requêtes pour éviter de dépasser les limites.
Permissions requises : L'utilisateur spécifié doit avoir un accès en lecture (ACLs) aux tables incident, sys_audit et sys_journal_field. Le rôle itil fournit généralement cela, mais votre instance peut avoir 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}")

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

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

Attributs de gestion des incidents

Activités de gestion des incidents

Guides d'extraction

Extraction directe via l'API REST des tables ServiceNow

Étapes

Configuration

a Exemple de requête javascript

Extraction par script Python via l'API REST ServiceNow

Étapes

Configuration

a Exemple de requête python

Prêt(e) à démarrer ?

Résolvez les incidents plus rapidement : Améliorez l'efficacité de ServiceNow dès maintenant

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

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

Attributs de gestion des incidents

Activités de gestion des incidents

Guides d'extraction

Extraction directe via l'API REST des tables ServiceNow

Étapes

Configuration

a Exemple de requête javascript

Extraction par script Python via l'API REST ServiceNow

Étapes

Configuration

a Exemple de requête python

Nous respectons votre vie privée

Prêt(e) à démarrer ?

Résolvez les incidents plus rapidement : Améliorez l'efficacité de ServiceNow dès maintenant