> 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 vous guide dans la collecte des données nécessaires à l’analyse et à l’optimisation de votre processus de Gestion des incidents. Il présente les attributs à recueillir, les activités à suivre et des conseils pratiques pour extraire ces informations de votre système source. Utilisez cette ressource pour constituer un journal d’événements adapté à une analyse approfondie et à l’amélioration de vos processus.

Attributs recommandés à recueillir
Activités à suivre
Conseils d’extraction pour la Gestion des problèmes dans ServiceNow

Vous découvrez les journaux d’événements ? Découvrez comment créer un journal d’événements pour le Process Mining.

Télécharger le modèle

Attributs de la Gestion des incidents

Voici les champs de données recommandés pour votre journal d’événements afin d’analyser en détail 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é a eu lieu.
Description L’heure de l’événement, souvent appelée horodatage, indique la date et l’heure exactes auxquelles une activité a été terminée ou un changement d’état s’est produit. Dans ServiceNow, elle 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 effectuer toute analyse temporelle. Il sert à calculer les temps de cycle, les temps d’attente en file et les durées entre les activités, autant d’éléments nécessaires pour repérer les goulots d’étranglement, mesurer les résultats au regard des SLA et comprendre l’efficacité du processus. La précision des horodatages est déterminante pour la fiabilité des indicateurs de durée. Pourquoi est-ce important ? Cet horodatage ordonne les activités dans le temps et permet de calculer tous les indicateurs fondés sur la durée, comme les temps de cycle et les goulots d’étranglement. Où trouver ces données 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 de son 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 sert d’identifiant central pour relier toutes les activités, mises à jour et communications associées, de la création de l’incident à sa clôture. Cet ID est indispensable à l’analyse en Process Mining. Il permet à l’outil de reconstituer la séquence d’événements de chaque cas, base nécessaire à la découverte des cartes de processus, à l’analyse des variantes et au calcul des durées de bout en bout. Sans identifiant unique pour chaque incident, il serait impossible de suivre son parcours jusqu’à sa résolution. Pourquoi est-ce important ? Cet ID de cas essentiel relie tous les événements du cycle de vie d’un incident et rend possible l’analyse du processus de bout en bout. Où trouver ces données Table des incidents ServiceNow, champ number. Exemples INC0010001INC0010045INC0010239
	Nom de l’activité ActivityName	Nom de l’événement ou de la tâche qui s’est produit à 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éduites des modifications de champs clés de l’incident, comme « State » ou « Assignment Group », ou d’entrées spécifiques du journal. Cet attribut est indispensable à la création de la carte du processus. Il définit les nœuds du graphe du processus et permet aux analystes de visualiser le parcours des incidents, de repérer les chemins fréquents, de découvrir les goulots d’étranglement entre les activités et d’analyser les variantes du processus. La précision et le niveau de détail des noms d’activité ont une incidence directe sur la qualité de l’analyse. Pourquoi est-ce important ? Il définit les étapes de la carte du processus, qui sert de base à l’analyse et à la visualisation en Process Mining. Où trouver ces données Cet attribut est dérivé. Il est 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 la dernière actualisation des données de cet enregistrement depuis le 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 l’actualité des données analysées, et non d’un événement du processus. Cette information permet de savoir si l’analyse repose sur des données récentes. Elle indique aux utilisateurs la date de mise à jour des données, un élément important pour les Dashboards opérationnels et les décisions fondées sur les événements récents. Elle aide ainsi à évaluer la pertinence et l’actualité des données. Pourquoi est-ce important ? Il indique aux utilisateurs si les données sont à jour, ce qui influe sur la pertinence et la précision de l’analyse. Où trouver ces données Cet horodatage est généré et renseigné par l’outil ou le processus d’extraction au moment du chargement des données. Exemples 2023-10-27T02:00:00Z2023-10-28T02:00:00Z
	Système source SourceSystem	Système depuis lequel ces données ont été extraites.
Description Cet attribut indique l’origine des données sur les incidents, ici la Gestion des problèmes ServiceNow. Il s’agit généralement d’une valeur statique ajoutée lors de l’extraction et de la transformation des données. Lorsque l’analyse combine des données provenant de plusieurs systèmes, ce champ est essentiel pour assurer la traçabilité et distinguer les sources. Il permet d’analyser les indicateurs et les processus dans le bon contexte, ainsi que de comparer les processus entre différents systèmes sources. Pourquoi est-ce important ? Il précise l’origine des données, assure leur traçabilité et permet de les interpréter correctement dans un environnement composé de plusieurs systèmes. Où trouver ces données Il s’agit généralement d’une valeur statique ajoutée lors de l’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 d’assistance chargé de l’incident à un moment donné. Il est essentiel pour comprendre la répartition de la charge de travail, les résultats des agents et les transferts entre personnes. L’analyse du champ « Affecté à » permet de visualiser la répartition des ressources et de repérer les agents surchargés. Le Dashboard « Transferts et réaffectations » s’appuie également sur ce champ pour suivre le nombre de changements de responsable d’un incident, qui peuvent signaler une inefficacité ou des lacunes dans les 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. Pourquoi est-ce important ? Il permet d’analyser la charge de travail et les résultats des agents, ainsi que les transferts entre personnes, pour mieux comprendre l’efficacité de l’utilisation des ressources. Où trouver ces données 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 d’activités dans le journal d’événements utilisé pour le Process Mining. Analyser le temps passé dans chaque état est un moyen efficace de repérer les goulots d’étranglement. Par exemple, une longue période à l’état « On Hold » peut signaler une dépendance à des facteurs externes ou à des utilisateurs. La séquence des changements d’état constitue également la base de la carte du processus et montre comment les incidents progressent vers leur résolution. Pourquoi est-ce important ? Il permet de suivre l’avancement de l’incident, d’analyser le temps passé à chaque étape et de repérer les goulots d’étranglement du processus. Où trouver ces données Table des incidents ServiceNow, champ incident_state ou state. Exemples NouveauEn coursEn attente d’informations de l’utilisateurRésoluClôturé
	Groupe d’affectation AssignmentGroup	Équipe ou groupe d’assistance chargé de traiter l’incident.
Description Le groupe d’affectation désigne l’équipe d’agents chargée de résoudre l’incident. Celui-ci peut être transféré entre plusieurs groupes, par exemple d’un service d’assistance de niveau 1 à une équipe réseau spécialisée de niveau 2. Cet attribut est essentiel pour analyser les transferts entre équipes et repérer les goulots d’étranglement systémiques. Le Dashboard « Taux de transferts et de réaffectations » s’appuie largement sur ces données pour montrer quelles équipes interviennent fréquemment dans les transferts. Il permet aussi de comparer les résultats des groupes d’assistance et de comprendre où se trouvent les compétences nécessaires à la résolution au sein de l’organisation. Pourquoi est-ce important ? Il indique quelle équipe est responsable et permet d’analyser ses résultats, sa charge de travail et les transferts entre groupes. Où trouver ces données Table des incidents ServiceNow, champ assignment_group. Exemples Centre de servicesAssistance réseauAdministrateurs de bases de données
	Priorité Priority	Niveau de priorité de l’incident, qui détermine le degré d’urgence de la réponse requise.
Description Dans ServiceNow, la priorité est un champ clé qui détermine l’ordre et la rapidité de traitement d’un incident. Elle est généralement calculée à partir de son impact et de son urgence, et influe directement sur les objectifs des SLA. Cet attribut est essentiel à la segmentation et à l’analyse des résultats. Le Dashboard « Vue d’ensemble de la conformité aux SLA » utilise la priorité pour vérifier si 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 bien traités plus rapidement que les incidents moins importants. La priorité est une dimension essentielle de presque tous les indicateurs et Dashboards. Pourquoi est-ce important ? Il permet de classer les incidents selon leur importance pour l’activité, un élément essentiel au suivi de la conformité aux SLA et à la répartition des ressources. Où trouver ces données 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 matériel, logiciel ou réseau.
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 à acheminer l’incident vers le bon groupe d’assistance et sert aux rapports et à l’analyse des tendances. Dans le cadre du Process Mining, cet attribut est essentiel aux Dashboards « Précision de la catégorisation des incidents » et « Volume des incidents récurrents ». L’analyse des incidents dont la catégorie change en cours de traitement peut révéler des problèmes lors du triage initial. Le filtrage de la carte du processus par catégorie peut aussi montrer si certains types d’incidents suivent des parcours de résolution différents ou rencontrent des goulots d’étranglement particuliers. Pourquoi est-ce important ? Il permet d’analyser les types d’incidents, de mesurer la précision de leur catégorisation et d’étudier leur acheminement ainsi que les tendances. Où trouver ces données Table des incidents ServiceNow, champ category. Exemples MatérielLogicielRéseauBase de données
	Code de résolution ResolutionCode	Code indiquant comment l’incident a finalement été résolu.
Description Le code de résolution précise la nature de la solution appliquée : l’incident a-t-il été résolu par un utilisateur, par la correction d’une erreur connue ou au moyen d’une solution de contournement ? L’agent renseigne généralement ce champ à la clôture de l’incident. Cet attribut alimente directement le Dashboard « Efficacité des types de résolution ». Il permet de comparer le nombre d’incidents clôturés après une correction définitive à celui des incidents ayant fait l’objet d’une solution temporaire. Cette comparaison constitue un indicateur important de la qualité du service et de sa stabilité à long terme. Un recours fréquent aux solutions de contournement peut révéler que les problèmes sous-jacents ne sont pas traités correctement. Pourquoi est-ce important ? Il précise la méthode de résolution et permet de comparer les corrections définitives aux solutions temporaires, tout en contribuant à l’analyse des causes profondes. Où trouver ces données Table des incidents ServiceNow, champ close_code ou 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
	Déclarant CallerId	Utilisateur ayant signalé l’incident au départ.
Description Le déclarant est l’utilisateur final ou le client touché par l’incident et qui l’a signalé. Cette information précise qui subit les perturbations du service. Même si cette dimension n’est pas toujours au cœur du déroulement du processus, l’analyse des incidents par déclarant peut révéler que certaines personnes ou certains services sont touchés de façon disproportionnée. Cela peut indiquer un besoin de formation ou un problème localisé dans l’environnement de travail. Elle permet aussi de contacter directement le client pour recueillir son avis et communiquer avec lui. Pourquoi est-ce important ? Il identifie l’utilisateur concerné, permet une analyse par service ou par personne et fournit un contexte utile pour communiquer avec les utilisateurs. Où trouver ces données Table des incidents ServiceNow, champ caller_id. Exemples Abel TuterCarolina PashDon Goodliffe
	Dépassement du SLA IsSlaBreached	Indicateur précisant si la résolution de l’incident a dépassé l’échéance du SLA.
Description Cet attribut booléen calculé indique si un incident a dépassé son accord de niveau de service. Il est obtenu en comparant l’horodatage réel de résolution à l’« Échéance du SLA ». Si la résolution intervient après cette échéance, l’indicateur prend la valeur true. Cet attribut est à la base du Dashboard « Vue d’ensemble de la conformité aux SLA » et des indicateurs associés. Il simplifie l’analyse en ramenant une comparaison complexe de dates et d’heures à une dimension simple, vrai ou faux. Vous pouvez ainsi filtrer facilement les incidents ayant dépassé leur échéance et en étudier les caractéristiques communes, comme la catégorie, le groupe d’affectation ou la priorité. Pourquoi est-ce 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ù trouver ces données Calculé en comparant l’horodatage « Resolved At » à l’horodatage « SlaDueDate ». (Resolved At > SlaDueDate). Exemples truefalse
	Échéance du SLA SlaDueDate	Date et heure auxquelles l’incident doit être résolu selon son SLA.
Description L’échéance du SLA est un horodatage calculé qui correspond à la date limite de résolution d’un incident. Elle est déterminée par l’accord de niveau de service (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 l’indicateur « Taux de dépassement du SLA pour les incidents critiques ». Il sert de référence pour comparer le délai de résolution réel à l’échéance prévue. L’analyse des incidents proches de cette échéance peut faciliter leur escalade et leur priorisation de manière proactive. Pourquoi est-ce important ? Il définit l’objectif de résolution et permet de mesurer le respect des SLA et de repérer les incidents susceptibles de dépasser leur échéance. Où trouver ces données Cette valeur se trouve généralement dans la table task_sla, liée à la table des incidents. L’horodatage pertinent est celui du champ planned_end_time. Exemples 2023-05-20T17:00:00Z2023-06-01T09:00:00Z
	Élément de configuration ConfigurationItem	Composant informatique, service ou actif précis concerné par l’incident.
Description L’élément de configuration (CI) est l’actif de la base de données de gestion des configurations (CMDB) concerné 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 très utile pour repérer les actifs ou les services peu fiables. Elle permet d’identifier les éléments de l’infrastructure informatique à l’origine du plus grand nombre d’incidents et d’orienter les investissements vers leur mise à niveau ou leur remplacement. En Process Mining, un filtre par CI peut révéler si les incidents liés aux applications essentielles sont traités différemment ou plus efficacement que les autres. Pourquoi est-ce important ? Il identifie l’actif concerné, aide à repérer les composants problématiques de l’infrastructure informatique et permet de cibler les améliorations. Où trouver ces données Table des incidents ServiceNow, champ cmdb_ci. Exemples Production SAP ERPServeur Oracle DB 05Service de messagerie
	Gravité Severity	Niveau d’impact de l’incident sur l’activité.
Description La gravité indique dans quelle mesure un incident perturbe les activités de l’entreprise. Avec l’urgence, elle sert souvent à calculer automatiquement la priorité de l’incident. Dans l’analyse, la gravité est une dimension importante du Dashboard « Vue d’ensemble de la conformité aux SLA ». Elle aide les organisations à vérifier si les niveaux de service sont respectés pour les incidents les plus perturbateurs. Elle apporte une perspective métier sur les performances, en complément de la perspective opérationnelle fournie par la priorité. Pourquoi est-ce important ? Elle mesure l’impact de l’incident sur l’activité et fournit une dimension importante pour hiérarchiser les interventions et analyser les incidents les plus graves. Où trouver ces données Table des incidents ServiceNow, champ severity. Exemples 1 - Élevée2 - Moyenne3 - Faible
	Identifiant du problème ProblemId	Identifiant de l’enregistrement de problème associé, si l’incident est lié à un problème plus vaste.
Description L’identifiant du problème relie un incident à l’enregistrement correspondant dans le module de Gestion des problèmes. Ce lien est créé lorsqu’un incident est reconnu comme le symptôme d’un problème sous-jacent plus vaste, qui touche plusieurs utilisateurs ou services. Ce lien est essentiel pour le Dashboard « Volume des incidents récurrents » et l’indicateur « Taux d’incidents récurrents ». Il permet aux analystes de regrouper les incidents ayant la même cause profonde, de mesurer l’impact global d’un problème et de suivre l’efficacité des efforts de résolution. Un grand nombre d’incidents liés à des problèmes peut indiquer que l’assistance intervient surtout après coup. Pourquoi est-ce 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ù trouver ces données Table des incidents ServiceNow, champ problem_id. Exemples PRB0040001PRB0040015PRB0040102
	Incident 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 si l’état d’un incident repasse à un état actif, par exemple « In Progress », après avoir été « Resolved » ou « Closed ». Cette situation est généralement détectée en recherchant l’activité « Incident Reopened » dans le journal d’événements. Les incidents rouverts signalent souvent une résolution incomplète ou inefficace. Leur analyse permet de repérer les clôtures prématurées et les problèmes récurrents qui n’ont pas été correctement résolus dès la première intervention. Un taux élevé de réouverture peut nuire à la satisfaction des utilisateurs et à la productivité des équipes. Il s’agit donc d’un indicateur important du contrôle qualité. Pourquoi est-ce important ? Cet indicateur révèle les défaillances du processus de résolution en mettant en évidence les incidents qui ont nécessité des reprises après avoir été considérés comme résolus. Où trouver ces données Calculé en vérifiant la séquence d’activités de chaque incident pour déterminer si un état « ouvert » suit un état « résolu ». Exemples truefalse
	Nombre de réaffectations ReassignmentCount	Nombre de fois où l’incident a été réaffecté à un autre groupe ou agent.
Description Ce champ comptabilise le nombre total de transferts d’un incident entre différents groupes d’affectation. Il mesure directement les frictions dans le processus et sert souvent d’indicateur de performance. Cet attribut alimente principalement le Dashboard « Transferts et taux de réaffectation » et l’indicateur « Nombre moyen de transferts par incident ». Un nombre élevé de réaffectations peut signaler une mauvaise orientation initiale, un manque de compétences à un niveau d’assistance ou une répartition des responsabilités peu claire. Réduire ce nombre est un objectif courant des initiatives d’amélioration des processus, car cela permet généralement de résoudre les incidents plus rapidement. Pourquoi est-ce important ? Cet indicateur mesure directement les transferts dans le processus. Il permet de repérer les inefficacités, les erreurs d’orientation et les possibilités d’amélioration. Où trouver ces données Table des incidents ServiceNow, champ reassignment_count. Exemples 0135

Obligatoire Recommandé Facultatif

Activités de la Gestion des incidents

Voici les principales étapes et les jalons à consigner dans votre journal d’événements pour découvrir et optimiser vos processus avec précision.

6 Recommandé 7 Facultatif

	Activité	Description
	Début du traitement	Indique qu’un agent a commencé à examiner activement l’incident ou à le traiter. Cet événement est généralement déduit du passage de l’état de l’incident de « New » ou « Assigned » à un état actif tel que « In Progress ».
Pourquoi est-ce important ? Cette étape marque la fin du temps d’attente initial 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ù trouver ces données Déduit de la table « sys_audit » en repérant le moment où le champ « state » de la table « incident » prend une valeur correspondant à un traitement actif, comme « In Progress ». Données à recueillir Repérez l’horodatage auquel le champ « state » prend la valeur « In Progress » ou une valeur similaire. Type d’événement inferred
	Groupe d’affectation modifié	Correspond au transfert d’un incident d’un groupe d’assistance à un autre. Il est repéré en observant les modifications ultérieures du champ « assignment_group », après son premier renseignement.
Pourquoi est-ce important ? Des réaffectations fréquentes peuvent révéler une erreur d’acheminement initiale, un processus complexe ou des lacunes dans les connaissances. Cette activité est essentielle au calcul de l’indicateur « Nombre moyen de transferts par incident ». Où trouver ces données Déduit de la table « sys_audit » en suivant toute modification du champ « assignment_group » après l’affectation initiale. Données à recueillir Repérez chaque modification horodatée du champ « assignment_group » dans le journal d’audit. Type d’événement inferred
	Incident affecté à un groupe	Cette activité a lieu lorsqu’un incident est affecté à un groupe d’assistance chargé de le traiter. Étape importante de l’acheminement, elle est repérée en observant les modifications du champ du groupe d’affectation.
Pourquoi est-ce 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’acheminement. Où trouver ces données Déduit de la table « sys_audit » en repérant le moment où le champ « assignment_group » de la table « incident » est renseigné ou modifié. Données à recueillir 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 : l’incident est entièrement résolu et confirmé, et aucune autre intervention n’est nécessaire. Cet événement est enregistré explicitement à l’aide de l’horodatage de clôture.
Pourquoi est-ce 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é aux opérations après résolution. Où trouver ces données L’horodatage « closed_at » de la table « incident » sert d’horodatage explicite pour l’événement. Il est généralement défini lorsque le champ « state » prend la valeur « Closed ». Données à recueillir 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, au moment où un nouvel incident est officiellement enregistré dans ServiceNow. Cet événement est identifié à partir de l’horodatage de création de l’enregistrement.
Pourquoi est-ce important ? Il s’agit de l’événement de début principal du processus. Mesurer le temps écoulé entre cette activité et la résolution est essentiel pour calculer le temps de cycle global et évaluer la conformité aux SLA. Où trouver ces données L’horodatage « sys_created_on » de la table « incident » sert d’horodatage explicite pour cet événement. Données à recueillir 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 d’assistance a appliqué une correction et fait passer l’incident à l’état « Resolved ». Cette étape importante précède la clôture définitive.
Pourquoi est-ce important ? Cette activité marque la fin du traitement actif et le début de la phase de confirmation. Le temps écoulé jusqu’à « Incident Closed » peut révéler des retards dans la confirmation de l’utilisateur ou la vérification de la résolution. Où trouver ces données 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à. Données à recueillir Utilisez l’horodatage auquel le champ « state » prend la valeur « Resolved », ou l’horodatage « resolved_at ». Type d’événement inferred
	Commentaire d’assistance ajouté	Un agent d’assistance ajoute une note de travail ou un commentaire visible par l’utilisateur. Cet événement explicite est enregistré dans le flux d’activité de l’incident.
Pourquoi est-ce important ? Cette activité suit les échanges et les démarches d’analyse de l’équipe d’assistance. La fréquence et le moment de ces commentaires renseignent sur le déroulement de l’investigation. Où trouver ces données Récupéré dans la table « sys_journal_field », qui enregistre les entrées des champs « work_notes » et « comments » de la table « incident ». Données à recueillir 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 confirmation par l’utilisateur que la résolution proposée a fonctionné. Cet état est généralement déduit d’une valeur spécifique, comme « Awaiting User Info », après la résolution.
Pourquoi est-ce important ? Cette étape peut devenir un goulot d’étranglement important si les utilisateurs tardent à répondre. Mesurer le temps passé dans cet état aide à repérer les lacunes de communication et les possibilités de clôture automatique. Où trouver ces données Déduit de la table « sys_audit » en repérant le passage à un état d’attente spécifique après la résolution. Le nom de cet état peut être personnalisé, par exemple « Awaiting Caller ». Données à recueillir Repérez l’horodatage auquel le champ « state » prend une valeur indiquant que des informations sont attendues de l’utilisateur. Type d’événement inferred
	Incident affecté à un agent	Correspond au moment où un agent précis d’un groupe d’assistance prend en charge l’incident. Cette activité est repérée en surveillant les modifications du champ « assigned_to ».
Pourquoi est-ce important ? Cette activité permet d’analyser plus finement la charge de travail des agents et la résolution dès le premier contact. Elle indique combien de temps un incident attend avant qu’une personne commence à le traiter après son affectation à un groupe. Où trouver ces données Déduit de la table « sys_audit » en repérant le moment où le champ « assigned_to » de la table « incident » est renseigné ou modifié. Données à recueillir Utilisez l’horodatage du journal d’audit correspondant aux modifications du champ « assigned_to ». Type d’événement inferred
	Incident catégorisé	Correspond à la classification initiale de l’incident, lorsque des champs comme 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 de l’incident.
Pourquoi est-ce important ? Une catégorisation précise est essentielle pour acheminer et prioriser correctement les incidents. Le suivi de cette activité permet d’analyser la fréquence des recatégorisations et leur effet sur les délais de résolution. Où trouver ces données Déduit de la table « sys_audit » en repérant la première modification de champs tels que « category », « subcategory » ou « priority » pour un incident donné. Données à recueillir Repérez 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 intervention plus rapide ou des ressources différentes. Cet événement est déduit d’une hausse de la valeur du champ « priority ».
Pourquoi est-ce important ? Une escalade indique souvent que l’incident est plus grave que prévu ou qu’un manquement aux SLA approche. L’analyse de ces événements aide à comprendre les exceptions dans le processus. Où trouver ces données Déduit de la table « sys_audit » en repérant une modification du champ « priority » vers une valeur correspondant à un degré d’urgence supérieur. Données à recueillir Repérez toute hausse 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é a lieu lorsqu’un incident est officiellement associé à un enregistrement de problème, ce qui indique qu’il relève d’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 est-ce important ? Associer un incident à un problème est une étape importante pour passer d’une résolution réactive à l’analyse proactive des causes profondes. Cette activité alimente le Dashboard « Volume des incidents récurrents ». Où trouver ces données Déduit lorsque le champ de référence « problem_id » de la table « incident » est renseigné. Données à recueillir Repérez 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 du passage de l’état « Resolved » à un état actif tel que « In Progress ».
Pourquoi est-ce important ? La réouverture d’un incident indique que la résolution a échoué et entraîne des reprises. Le suivi de cette activité est essentiel pour mesurer la qualité des résolutions et le taux de résolution dès la première intervention. Où trouver ces données Déduit de la table « sys_audit » en repérant le passage du champ « state » de « Resolved » à un état actif tel que « In Progress » ou « Assigned ». Données à recueillir Repérez 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

Configurez l’accès à ServiceNow : obtenez les identifiants d’un compte de service ServiceNow. Ce compte doit disposer des autorisations de lecture (ACL) sur la table incident, la table sys_audit et 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.
Configurez 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, nécessaire aux requêtes HTTP, en exécutant npm install axios dans votre terminal.
Préparez le script d’extraction : copiez le code JavaScript fourni dans un fichier, par exemple extract_incidents.js. Remplacez les valeurs fictives au début du script par l’URL de votre instance ServiceNow, votre nom d’utilisateur et votre mot de passe.
Définissez les paramètres d’extraction : modifiez les variables startDate et endDate dans le script pour définir la période des incidents à extraire. Pour les premiers essais, il est conseillé de choisir une période courte, par exemple une semaine, afin de vérifier les résultats.
Exécutez le script : lancez le script depuis votre terminal avec la commande node extract_incidents.js. Il commencera à récupérer les données des incidents et les journaux d’audit correspondants via l’API ServiceNow.
Suivez l’avancement du script : le script affiche sa progression dans la console, notamment le nombre d’incidents traités. Pour les grands volumes de données, l’opération peut prendre beaucoup de temps en raison du nombre de requêtes API nécessaires.
Traitez 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’historique complet des modifications. Il traite ensuite cet historique pour repérer et horodater les 13 activités requises.
Gérez les activités déduites : le script peut déduire certaines activités à partir des modifications de champs. Par exemple, il crée l’activité « Incident Escalated » lorsque la nouvelle valeur du champ priority est inférieure à l’ancienne, ce qui indique une priorité plus élevée. Il repère l’activité « Work Started » au premier changement d’état vers « In Progress ».
Structurez le journal d’événements : une fois les activités repérées, le script les met en forme dans des enregistrements du journal d’événements. Chaque enregistrement contient les colonnes requises, notamment IncidentId, ActivityName et EventTime.
Enregistrez le résultat : à la fin de l’exécution, 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 de tous les événements extraits.
Convertissez le fichier en CSV : pour importer les données dans ProcessMind, vous devrez peut-être convertir le fichier JSON final en CSV. Utilisez un outil de traitement des données courant ou un script simple pour transformer le tableau JSON en fichier CSV, en veillant à ce que les en-têtes de colonnes correspondent aux attributs requis.

Configuration

Point de terminaison de l’API : le script cible deux principaux points de terminaison 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 (nom d’utilisateur et 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 filtre les incidents selon leur date de création (sys_created_on). Les variables startDate et endDate du script définissent cette période. Pour obtenir une analyse pertinente, il est conseillé d’extraire trois à six mois de données, en commençant par une période plus courte pour les tests.
Principaux paramètres de requête :
- sysparm_query : filtre 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 des données renvoyées par 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 1 000, une pratique courante.
- sysparm_offset : s’utilise avec sysparm_limit pour récupérer les pages de résultats suivantes.
Considérations sur les performances : interroger la table sys_audit pour chaque incident sollicite fortement les ressources. Pour les très grandes instances ServiceNow, envisagez d’exécuter l’extraction en dehors des heures de pointe. Le script traite les incidents l’un après l’autre pour ne pas surcharger l’API, ce qui peut toutefois allonger la durée totale d’exécution.
Prérequis : l’exécution du script nécessite un environnement Node.js. L’utilisateur ou le compte de service qui lance l’extraction doit disposer des autorisations de lecture (ACL) nécessaires sur les tables incident et sys_audit.

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 un compte de service dédié à cette extraction dans ServiceNow. Attribuez-lui les rôles itil et rest_api_explorer pour lui donner un accès en lecture aux tables requises (incident, sys_audit, sys_journal_field).
Configurez le script : ouvrez le script Python fourni. Dans la section de configuration 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. Modifiez START_DATE et END_DATE pour définir la période d’extraction souhaitée.
Exécutez le script : lancez-le depuis la ligne de commande avec python your_script_name.py. Le script commencera à s’authentifier auprès de ServiceNow et à envoyer des requêtes à l’API.
Récupération des données : le script récupère d’abord la liste des incidents créés pendant la période indiquée dans la table incident. Il utilise ensuite leurs identifiants pour récupérer l’historique d’audit associé dans sys_audit et tous les commentaires dans sys_journal_field.
Génération du 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 de lignes distinct pour chacune. Par exemple, il repère l’événement « Incident Created » dans le champ sys_created_on et l’événement « Incident Closed » dans le champ closed_at. Pour les autres événements, il analyse le journal d’audit afin de repérer les changements d’état, les modifications de champs et les escalades.
Association des attributs : pour chaque ligne d’événement générée, le script récupère des attributs contextuels dans l’enregistrement principal de l’incident, comme AssignmentGroup, AssignedTo, Priority et IncidentState au moment de l’événement.
Consolidation des données : tous les DataFrames d’événements (un par type d’activité) sont réunis dans un DataFrame unique et complet, qui constitue le journal d’événements.
Transformation finale : le DataFrame consolidé est trié par IncidentId et EventTime afin de respecter l’ordre chronologique des événements de chaque cas. Les colonnes SourceSystem et LastDataUpdate sont ajoutées avec des valeurs fixes.
Exportation au format CSV : le journal d’événements final est enregistré sous le nom servicenow_incident_event_log.csv, dans le répertoire 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) : période d’extraction définie selon la date de création des incidents. Pour une première analyse, une période de trois à six mois est recommandée afin de trouver un équilibre entre le volume de données et la pertinence des résultats. Une période plus longue allongera sensiblement l’extraction.
Paramètres de requête de l’API (sysparm_query) : le script utilise sysparm_query pour filtrer les incidents selon leur date de création (sys_created_on). Vous pouvez ajouter des conditions pour restreindre le périmètre, par exemple active=false^company=[Your Company Sys ID] pour 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 mécanisme explicite de gestion de ces limites. Pour les très grandes instances, vous devrez peut-être ajouter des appels à time.sleep() entre les requêtes afin de ne pas dépasser les limites.
Autorisations requises : l’utilisateur indiqué doit disposer d’un accès en lecture (ACL) aux tables incident, sys_audit et sys_journal_field. Le rôle itil donne généralement cet accès, mais votre instance peut appliquer des contrôles d’accès personnalisés.

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 tout le nécessaire pour lancer votre démarche de Process Mining appliquée à la Gestion des incidents. Commencez dès aujourd’hui à améliorer la résolution de vos incidents.

Retour au guide d’amélioration

Télécharger le modèle

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

Réduisez de 35 % le temps moyen de résolution dans ServiceNow. Repérez les problèmes et améliorez la satisfaction.

Démarrez 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

Exemple de requête javascript

Extraction avec un script Python via l’API REST ServiceNow

Étapes

Configuration

Exemple de requête python

Prêt à commencer ?

Résolvez les 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

Exemple de requête javascript

Extraction avec un script Python via l’API REST ServiceNow

Étapes

Configuration

Exemple de requête python

Prêt à commencer ?

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

Prêt à commencer ?

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