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

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

ServiceNow

Attributs de la gestion des demandes de service (21) Activités de gestion des demandes de service (14) Guides d’extraction (3)

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

Ce modèle de données complet est conçu pour simplifier votre démarche de Process Mining appliquée à la gestion des demandes de service. Il fournit des indications claires sur les attributs essentiels à collecter, les activités importantes à suivre et les modalités d’extraction adaptées à ServiceNow. En utilisant ce modèle, vous vous assurez de recueillir toutes les données nécessaires à une analyse précise et à une optimisation efficace.

Attributs recommandés à collecter
Activités essentielles à suivre pour découvrir le processus
Guide d’extraction des données, étape par étape

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

Télécharger le modèle

Attributs de la gestion des demandes de service

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

5 Obligatoire 6 Recommandé 10 Facultatif

	Nom	Description
	Activité ActivityName	Nom de l’événement ou de la tâche spécifique survenu au cours du cycle de vie de la demande de service.
Description L’attribut Activity enregistre le nom de chaque étape ou changement d’état du processus de demande de service. Il peut s’agir d’événements tels que « Request Created », « Request Approved », « Assigned to Agent » ou « Request Closed ». L’analyse de ces activités permet de visualiser le flux du processus, d’identifier les parcours courants et de détecter les écarts par rapport à la procédure standard. Elle constitue la base nécessaire pour comprendre ce qui se passe réellement pendant le traitement des demandes. Pourquoi c’est important Il s’agit d’un attribut obligatoire qui définit les étapes de la cartographie du processus. Il est fondamental pour toutes les analyses de processus, notamment l’identification des goulots d’étranglement, des boucles de reprise et des problèmes de Conformité. Où les obtenir Dérivé des changements apportés aux champs « State » ou « Stage » dans des tables telles que « sc_request » ou « sc_req_item », ou de la piste d’audit (sys_audit). Exemples Demande de service crééeDemande affectée à un groupeDemande de service résolueInformations demandées à l’utilisateur
	Heure de début EventTime	Horodatage indiquant le début d’une activité ou d’un événement.
Description Cet attribut capture la date et l’heure exactes auxquelles chaque activité du processus de demande de service s’est produite. Il fournit la séquence chronologique des événements nécessaire à la création de la cartographie du processus et à toute analyse fondée sur le temps. Des horodatages précis sont indispensables pour calculer les temps de cycle, les temps d’attente et les durées de traitement. Ces données permettent d’identifier les goulots d’étranglement, les violations de SLA et les tendances de performance au fil du temps. Pourquoi c’est important Il s’agit d’un horodatage obligatoire pour classer correctement les événements. Il constitue la base de toutes les analyses de performance et de durée, notamment le temps de cycle et l’identification des goulots d’étranglement. Où les obtenir Se trouve généralement dans les champs « sys_updated_on » ou « sys_created_on » des tables ServiceNow concernées, par exemple sc_request et sc_task, ou dans la piste d’audit (sys_audit). Exemples 2023-04-15T10:00:00Z2023-04-15T11:30:15Z2023-04-16T09:05:45Z
	Identifiant de la demande de service ServiceRequestID	Identifiant unique de chaque enregistrement de demande de service.
Description L’identifiant de la demande de service est la clé primaire qui identifie de manière unique chaque demande de service soumise par un utilisateur ou un système. Il constitue le fil conducteur central reliant tous les événements ultérieurs, de l’enregistrement initial à la clôture définitive. Dans le Process Mining, cet identifiant est essentiel pour reconstituer le parcours de bout en bout de chaque demande et analyser intégralement son cycle de vie. Pourquoi c’est important Il s’agit du Case ID obligatoire. Il relie toutes les activités associées au sein d’une même instance de processus, ce qui permet d’analyser les flux, les variations et les temps de cycle. Où les obtenir Table ServiceNow Request [sc_request], champ « number ». Exemples REQ0010001REQ0010025REQ0010112
	Dernière mise à jour des données LastDataUpdate	Horodatage de l’actualisation ou de l’extraction la plus récente des données.
Description Cet attribut indique la date et l’heure auxquelles les données ont été extraites pour la dernière fois du système source, puis chargées dans l’outil de Process Mining. Il garantit la transparence sur l’actualité des données analysées. Les analystes utilisent ces informations pour vérifier qu’ils consultent les données les plus récentes, ce qui est essentiel au suivi opérationnel et à la prise de décision en temps réel. Elles permettent également de définir clairement le degré de fraîcheur des analyses. Pourquoi c’est important Permet aux utilisateurs de connaître l’actualité des données, un élément essentiel pour faire confiance à l’analyse et prendre rapidement des décisions fondées sur les données. Où les obtenir Il s’agit d’un champ de métadonnées ajouté lors de l’ingestion des données, qui reflète l’horodatage de la fin du traitement ETL. Exemples 2023-10-27T04:00:00Z
	Système source SourceSystem	Système à l’origine des données.
Description Cet attribut identifie le système source des données, qui est ici ServiceNow. Il est utile dans les environnements où les données de plusieurs systèmes sont regroupées pour obtenir une vue globale du processus. Dans le cadre d’une analyse fondée sur une seule source, cet attribut fournit un contexte important et contribue à la gouvernance et à la gestion des données. Il permet à chaque utilisateur de connaître l’origine des données analysées. Pourquoi c’est important Fournit les métadonnées essentielles à la gouvernance, à la traçabilité et au contexte des données, notamment lorsque des données provenant de plusieurs systèmes d’entreprise sont combinées. Où les obtenir Il s’agit généralement d’une valeur statique ajoutée lors de l’extraction et de la transformation des données. Exemples ServiceNow
	Affecté à AssignedTo	Utilisateur chargé de traiter la demande de service à un moment donné.
Description Cet attribut identifie l’agent ou le technicien précisément affecté à la demande de service. Il évolue lorsque la demande est transférée entre différentes personnes. L’analyse du champ « Assigned To » est essentielle pour comprendre la répartition de la charge, la performance individuelle et l’incidence des transferts sur les délais de résolution. Elle permet d’évaluer l’utilisation des ressources et d’identifier les besoins de formation ou de clarification des processus afin de réduire les réaffectations. Pourquoi c’est important Permet d’analyser la charge de travail, la performance et les transferts entre agents. Il est essentiel à la gestion des ressources et à l’identification des goulots d’étranglement liés à certaines personnes. Où les obtenir Tables ServiceNow Request Item [sc_req_item] ou Catalog Task [sc_task], champ « assigned_to ». Exemples Beth AnglinDavid LooHoward Johnson
	Catégorie Category	Classification principale de la demande de service, par exemple Hardware ou Software.
Description La catégorie fournit une classification générale de la demande de service. Elle sert généralement à orienter la demande vers l’équipe appropriée et à établir des rapports sur les types de demandes soumises. Dans le Process Mining, la catégorie constitue un outil puissant de filtrage et d’analyse par dimension. Elle permet aux analystes de comparer les flux, les temps de cycle et les taux d’automatisation pour différents types de demandes, afin de révéler des variations qui pourraient rester invisibles à un niveau agrégé. Par exemple, le processus d’une demande « Hardware » peut être fondamentalement différent de celui d’une demande « Software ». Pourquoi c’est important Permet de segmenter et de comparer efficacement les processus selon les différents types de services, afin d’identifier les problèmes et les possibilités d’amélioration propres à chaque catégorie. Où les obtenir Table ServiceNow Request Item [sc_req_item], généralement via la catégorie de l’élément de catalogue associé [sc_cat_item]. Exemples MatérielLogicielDemande d’accèsRéseau
	État State	Statut opérationnel actuel de la demande de service.
Description L’attribut State indique l’étape actuelle de la demande de service dans son cycle de vie, par exemple « Open », « Work in Progress », « Pending » ou « Closed ». Les changements de ce champ servent souvent à générer les activités de la cartographie du processus. L’analyse de l’état est essentielle pour comprendre le temps passé par les demandes dans certains statuts, notamment les états d’attente ou de suspension. Elle aide à identifier les files et les retards, comme le temps passé en « Awaiting User Information », qui constitue une cause fréquente d’allongement des temps de cycle. Pourquoi c’est important Fournit une visibilité sur l’état de la demande à tout moment et permet d’analyser les temps d’attente, les files ainsi que la durée des différentes étapes du processus. Où les obtenir Tables ServiceNow Request [sc_request] ou Request Item [sc_req_item], champ « state » ou « stage ». Exemples OuvertEn cours de traitementEn attente d’informations de l’utilisateurClôturé, terminé
	Groupe d’affectation AssignmentGroup	Équipe ou groupe chargé de traiter la demande de service.
Description Le groupe d’affectation représente l’équipe, par exemple « Service Desk », « Network Operations » ou « Database Administration », responsable d’une demande de service à une étape donnée. Il s’agit d’un attribut essentiel pour analyser le flux du processus entre les différents domaines fonctionnels. En suivant les changements du groupe d’affectation, les organisations peuvent visualiser les transferts entre équipes, mesurer les temps d’attente dans la file de chaque groupe et identifier les dépendances ou les retards entre équipes. Cette analyse est essentielle pour optimiser la collaboration entre les fonctions. Pourquoi c’est important Suit la répartition du travail entre les équipes, met en évidence les transferts interéquipes et aide à identifier les goulots d’étranglement ou les problèmes de performance propres à chaque équipe. Où les obtenir Tables ServiceNow Request Item [sc_req_item] ou Catalog Task [sc_task], champ « assignment_group ». Exemples Centre de servicesSupport informatique, niveau 2Mise à disposition du matériel
	Priorité Priority	Niveau de priorité de la demande de service, qui détermine son degré d’urgence.
Description La priorité est une classification qui détermine l’importance relative et l’urgence d’une demande de service. Elle est souvent définie à partir d’une combinaison de l’impact et de l’urgence, puis utilisée pour indiquer aux agents les demandes à traiter en premier. L’analyse des données par priorité est essentielle pour vérifier que les demandes prioritaires sont traitées plus rapidement que les autres. Elle permet de filtrer les Dashboards afin de contrôler le respect des SLA pour les demandes critiques et d’évaluer l’efficacité du système de priorisation. Pourquoi c’est important Permet de segmenter les demandes afin de vérifier que les éléments prioritaires sont traités plus rapidement. Cet attribut est essentiel à l’analyse des SLA et à l’allocation des ressources. Où les obtenir Tables ServiceNow Request [sc_request] ou Request Item [sc_req_item], champ « priority ». Exemples 1 - Critique2 - Élevée3 - Modérée4 - Faible
	SLA respecté MadeSLA	Indicateur booléen précisant si la demande de service a été résolue dans le délai prévu par son accord de niveau de service.
Description Cet attribut indique si la demande de service a respecté l’accord de niveau de service (SLA) défini pour son délai de résolution. Il s’agit d’un indicateur de résultat essentiel, qui mesure directement la performance du service par rapport aux engagements pris. L’analyse de cet indicateur permet de quantifier le KPI de taux de respect des SLA. Il peut servir de dimension pour comparer les parcours des demandes conformes à ceux des demandes ayant dépassé leur SLA, et ainsi révéler les activités ou les schémas fréquemment associés aux échecs. Cette analyse est essentielle au suivi préventif des risques et à l’amélioration continue du service. Pourquoi c’est important Mesure directement la performance par rapport aux engagements de service et permet d’analyser les causes profondes des violations de SLA en comparant les cas conformes et non conformes. Où les obtenir Table ServiceNow Task SLA [task_sla], champ « has_breached ». La valeur doit être inversée, par exemple MadeSLA = NOT has_breached. Exemples truefalse
	Canal ContactType	Méthode utilisée par le demandeur pour soumettre la demande de service.
Description Le type de contact, ou canal, indique comment la demande de service a été initiée. Les canaux courants comprennent le portail de services, l’e-mail, l’appel téléphonique ou l’alerte automatisée. Comprendre le canal est important pour analyser les variations du processus susceptibles d’être liées au mode de soumission. Par exemple, les demandes envoyées via le portail peuvent être plus structurées et davantage automatisées, ce qui réduit les délais de traitement par rapport aux demandes envoyées par e-mail. Cette analyse contribue à privilégier les canaux les plus efficaces. Pourquoi c’est important Permet d’identifier l’impact des différents canaux de soumission sur l’efficacité du processus, le niveau d’automatisation et les délais de bout en bout, afin d’orienter les efforts d’optimisation des interactions avec les utilisateurs. Où les obtenir Tables ServiceNow Request [sc_request] ou Interaction [interaction]. Le champ est souvent nommé « contact_type ». Exemples PortailE-mailTéléphoneLibre-service
	Code de résolution ResolutionCode	Code qui catégorise la résolution finale de la demande de service.
Description Le code de résolution fournit une classification structurée de la manière dont une demande de service a finalement été résolue. Exemples : « Fulfilled by Automation », « User Error » ou « No Longer Required ». Cet attribut est essentiel au Dashboard Root Cause Analysis for Delays. En mettant en relation les codes de résolution avec les délais de traitement élevés ou les taux de reprise importants, les analystes peuvent identifier les problèmes systémiques. Par exemple, si les demandes portant le code « Incomplete Information » sont systématiquement lentes, cela peut indiquer un problème lors de la collecte initiale des données. Pourquoi c’est important Fournit des données structurées sur les résultats des résolutions et permet d’analyser les causes profondes des retards, des reprises et des autres inefficacités du processus. Où les obtenir ServiceNow Request Item [sc_req_item] ou table de tâches associée, le champ étant généralement « close_code » ou « resolution_code ». Exemples Résolu (définitivement)Non résolu (non reproductible)Demande satisfaiteAnnulé par l’utilisateur
	Délai de traitement du dossier CaseCycleTime	Temps total écoulé entre la création et la clôture définitive d’une demande de service.
Description Le délai de traitement du dossier est une métrique calculée qui mesure la durée totale d’une demande de service, depuis l’horodatage du tout premier événement jusqu’à celui du tout dernier événement. Il représente le délai complet de traitement de bout en bout du point de vue du client. Il s’agit d’un indicateur clé de performance (KPI) majeur de l’efficacité globale du processus. Il est utilisé dans les Dashboards de haut niveau pour suivre les performances par rapport aux objectifs et analyser les tendances dans le temps. Il peut être ventilé selon des dimensions telles que la catégorie ou la priorité afin d’identifier les types de demandes qui prennent le plus de temps. Pourquoi c’est important Ce KPI important mesure la performance du processus de bout en bout. Il est essentiel pour le suivi de haut niveau, la comparaison des performances et l’identification des axes d’amélioration. Où les obtenir Calculé en soustrayant le « StartTime » minimum du « EndTime » maximum pour chaque « ServiceRequestID » unique. Exemples 2 10:30:000 04:15:2210 00:05:00
	Est automatisé IsAutomated	Indicateur précisant si une activité a été exécutée par un système ou une automatisation.
Description Cet attribut booléen distingue les activités effectuées manuellement par un agent de celles exécutées par un système automatisé, tel qu’un flux de travail ou une intégration. Par exemple, « Approval Requested » peut être automatisé, tandis que « Request Assigned to Agent » peut être manuel. L’analyse de cet attribut est essentielle pour mesurer et accroître le niveau d’automatisation du processus de gestion des demandes de service. Elle permet d’identifier les tâches manuelles qui prennent le plus de temps et qui pourraient être automatisées à l’avenir, afin d’améliorer l’efficacité et de réduire les coûts. Pourquoi c’est important Permet de mesurer les taux d’automatisation et d’identifier les possibilités d’automatiser les tâches manuelles, ce qui améliore l’efficacité et réduit les coûts opérationnels. Où les obtenir Déduit en vérifiant si l’utilisateur ayant exécuté une action, par exemple « sys_updated_by », est un utilisateur système ou d’intégration désigné. Exemples truefalse
	Est une reprise IsRework	Indicateur calculé précisant si une activité constitue une répétition d’une activité précédente dans le même dossier.
Description Cet indicateur booléen est calculé pour identifier les boucles de reprise au sein d’une demande de service. Il prend la valeur « true » si la même activité a déjà eu lieu plus tôt dans le même dossier, par exemple lorsqu’une demande est affectée deux fois à la même équipe ou lorsque des informations sont demandées plusieurs fois à l’utilisateur. Cet attribut est essentiel au Dashboard Agent Handoffs and Rework Incidents et au KPI Request Rework Rate. Il permet de visualiser et de quantifier directement les boucles inefficaces du processus, souvent invisibles dans les données agrégées. Pourquoi c’est important Signale et quantifie directement les reprises dans le processus, ce qui permet d’analyser les causes et les effets des boucles inefficaces qui augmentent les coûts et les délais de traitement. Où les obtenir Calculé lors de la transformation des données en recherchant les occurrences précédentes du même nom d’activité dans le même dossier. Exemples falsetrue
	Est une résolution dès la première intervention IsFirstPassResolution	Indicateur précisant si la demande a été résolue dès la première tentative, sans aucune réouverture.
Description Cet attribut calculé est un indicateur booléen qui prend la valeur « true » uniquement si la demande de service a été résolue et fermée sans jamais être rouverte. Il constitue un indicateur essentiel de la qualité et de l’efficacité de la résolution fournie par le service desk. Cette métrique contribue directement au KPI First-Pass Resolution Rate. Un taux élevé est souhaitable, car il traduit une prise en charge efficace et de qualité, qui améliore la satisfaction client. L’analyse des attributs des dossiers qui ne sont pas résolus dès la première intervention peut révéler des causes profondes telles qu’une formation insuffisante, une documentation inadaptée ou un diagnostic initial erroné. Pourquoi c’est important Mesure la qualité et l’efficacité du processus de résolution. Un faible taux de résolution dès la première intervention révèle des problèmes sous-jacents qui entraînent des reprises et la frustration des clients. Où les obtenir Calculé au niveau du dossier. Un dossier est considéré comme résolu dès la première intervention si sa valeur « ReopenCount » est égale à zéro. Exemples truefalse
	Heure de fin EndTime	Horodatage indiquant la fin d’une activité ou d’un événement.
Description L’heure de fin marque la conclusion d’une activité. Elle correspond à l’horodatage de l’activité suivante dans la séquence et clôt ainsi la durée de l’activité en cours. Cet attribut est essentiel pour calculer le temps nécessaire à chaque étape du processus. En comparant l’heure de début et l’heure de fin d’une activité, les analystes peuvent calculer les temps de traitement et d’attente. Cette comparaison est fondamentale pour identifier les goulots d’étranglement, mesurer l’efficacité des ressources et suivre la performance par rapport aux objectifs temporels. Pourquoi c’est important Cet attribut est nécessaire pour calculer la durée de chaque activité, un élément central de l’analyse de performance, de l’identification des goulots d’étranglement et de l’étude de l’utilisation des ressources. Où les obtenir Il s’agit d’un attribut dérivé, calculé à partir de l’heure de début (« StartTime ») de l’événement suivant dans le cas. Exemples 2023-04-15T10:05:10Z2023-04-15T11:45:00Z2023-04-16T09:15:30Z
	Nombre de réouvertures ReopenCount	Nombre de fois où une demande de service a été rouverte après sa résolution.
Description Cet attribut est un compteur qui indique combien de fois une demande de service est passée d’un état résolu ou fermé à un état ouvert ou en cours. Une valeur supérieure à zéro indique que la résolution initiale n’a pas abouti. Cette métrique mesure directement les reprises et constitue un élément essentiel du KPI First-Pass Resolution Rate. Un nombre élevé de réouvertures peut révéler des problèmes de qualité de la résolution, une prise en charge incomplète ou une mauvaise compréhension des besoins de l’utilisateur. Ces facteurs réduisent l’efficacité du processus et la satisfaction des utilisateurs. Pourquoi c’est important Quantifie les reprises et la qualité de la résolution. Un nombre élevé de réouvertures révèle des inefficacités, un faible taux de résolution dès la première intervention et une baisse de la satisfaction client. Où les obtenir Tables ServiceNow Request [sc_request] ou Request Item [sc_req_item], champ « reopen_count ». Exemples 012
	Ouvert par OpenedBy	Personne ayant soumis initialement la demande de service.
Description Cet attribut identifie l’utilisateur qui a créé la demande de service. Il s’agit souvent de la personne concernée par la demande, mais il peut également s’agir d’un responsable, d’un délégataire ou d’un système automatisé. L’analyse des demandes par utilisateur « Ouvert par » ou par service permet d’identifier certains schémas, par exemple un groupe d’utilisateurs qui soumet fréquemment des demandes complexes ou problématiques. Ces résultats peuvent orienter des formations ciblées ou mettre en évidence la nécessité d’améliorer les articles de la base de connaissances afin d’encourager le self-service. Pourquoi c’est important Aide à analyser les schémas de demandes par utilisateur, service ou rôle, afin d’orienter les initiatives de formation et les améliorations ciblées des processus. Où les obtenir Table ServiceNow Request [sc_request], champ « opened_by ». Exemples Abel TuterFred LuddyDon Goodliffe
	Score de satisfaction SatisfactionScore	Évaluation de la satisfaction client fournie par le demandeur à la clôture.
Description Cet attribut enregistre le score de satisfaction, souvent établi sur une échelle de 1 à 5, transmis par l’utilisateur final après la résolution de sa demande de service. Il mesure directement la qualité perçue du service. Ces données sont essentielles au Dashboard Customer Satisfaction Impact Analysis. Elles permettent de mettre directement en relation les métriques du processus, telles que le délai de traitement, les reprises et les transferts, avec l’expérience client finale. Vous pouvez ainsi étayer la pertinence économique des améliorations de processus en reliant l’efficacité opérationnelle aux résultats obtenus pour les clients. Pourquoi c’est important Relie directement les métriques de performance du processus aux résultats obtenus pour les clients et permet de quantifier l’impact des inefficacités sur l’expérience utilisateur. Où les obtenir Se trouve généralement dans une table Survey associée [asmt_assessment_instance], liée à la demande initiale. Exemples 5431

Obligatoire Recommandé Facultatif

Activités de gestion des demandes de service

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

6 Recommandé 8 Facultatif

	Activité	Description
	Demande affectée à un agent	Cette activité se produit lorsqu’un agent donné est chargé de traiter la demande de service. Elle est capturée en surveillant les changements du champ « Assigned to » de la demande ou de ses tâches de traitement.
Pourquoi c’est important Elle est essentielle pour mesurer les transferts, calculer la charge de travail propre à chaque agent et analyser le temps d’attente avant qu’une personne ne commence à traiter une demande. Où les obtenir Cet événement est déduit d’un changement du champ assigned_to dans la table sc_req_item ou sc_task. L’historique des changements est consigné dans la table sys_audit. Collecte Suivez les changements du champ assigned_to dans sys_audit. Type d’événement inferred
	Demande approuvée	Cette activité indique que la demande a été officiellement approuvée et peut passer à l’étape de traitement. Elle est capturée lorsqu’un approbateur marque l’enregistrement d’approbation associé comme « approved ».
Pourquoi c’est important Cette étape importante marque la transition entre la phase d’approbation et la phase de traitement. L’analyse du temps nécessaire pour l’atteindre est essentielle pour comprendre les retards précédant le traitement. Où les obtenir Cet événement est déduit du changement du champ d’état de l’enregistrement sysapproval_approver associé vers « approved », ce qui déclenche ensuite un changement d’état sur sc_req_item. Collecte Identifiez l’horodatage auquel sysapproval_approver.state devient « approved ». Type d’événement inferred
	Demande de service clôturée	Marque la fin définitive du cycle de vie de la demande de service. Cette étape se produit généralement automatiquement après une durée déterminée passée à l’état « Resolved », pendant laquelle l’utilisateur peut rouvrir la demande.
Pourquoi c’est important Il s’agit de l’événement de fin réussi principal du processus. Le délai entre « Resolved » et « Closed » peut également être analysé afin de comprendre les politiques de fermeture automatique. Où les obtenir Cet événement est déduit lorsque le champ d’état de sc_req_item est mis à jour vers un état final fermé, tel que « Closed Complete ». Il est consigné dans la table sys_audit. Collecte Identifiez l’horodatage auquel sc_req_item.state passe à « Closed Complete ». Type d’événement inferred
	Demande de service créée	Cette activité marque le début du cycle de vie d’une demande de service. Elle est enregistrée lorsqu’un utilisateur soumet une demande via le catalogue de services. Le système la capture comme l’événement de création d’un nouvel enregistrement dans la table sc_req_item (Requested Item).
Pourquoi c’est important Il s’agit de l’événement de début principal du processus. Il est indispensable pour calculer le temps de cycle global et analyser les volumes de demandes ainsi que les habitudes de soumission. Où les obtenir Il s’agit d’un événement explicite capturé à partir de l’horodatage de création (champ sys_created_on) de l’enregistrement dans la table sc_req_item. Collecte Utilisez l’horodatage sys_created_on de l’enregistrement sc_req_item. Type d’événement explicit
	Demande de service résolue	Cette activité indique que l’agent chargé du traitement a terminé son travail et fourni une solution. Elle est capturée lorsque l’état de la demande est mis à jour vers « Resolved » ou un statut similaire.
Pourquoi c’est important Il s’agit d’une étape importante qui arrête généralement le décompte du SLA. Elle marque la fin du traitement actif et constitue un élément essentiel du calcul du délai total de résolution. Où les obtenir Cet événement est déduit lorsque le champ d’état de sc_req_item est mis à jour vers « Resolved » ou un autre état final similaire, avant la fermeture définitive. Le changement est suivi dans la table sys_audit. Collecte Identifiez l’horodatage auquel sc_req_item.state passe à « Resolved ». Type d’événement inferred
	Informations demandées à l’utilisateur	Cette activité se produit lorsque l’agent chargé du traitement a besoin d’informations supplémentaires de la part du demandeur initial pour poursuivre. Elle est généralement déduite lorsque l’état de la demande passe à une valeur telle que « Awaiting User Info ».
Pourquoi c’est important Cette activité est essentielle pour le Dashboard « Requestor Information Delay Analysis », qui permet de quantifier le temps perdu dans l’attente d’informations externes fournies par l’utilisateur. Où les obtenir Cet événement est déduit du changement du champ d’état de sc_req_item vers un statut désigné comme « awaiting information ». Le changement est consigné dans la table sys_audit. Collecte Identifiez l’horodatage auquel sc_req_item.state passe à « Awaiting User Info ». Type d’événement inferred
	Approbation demandée	Représente le moment où une demande de service est soumise à l’approbation d’un responsable ou d’un autre approbateur désigné. Cet événement est généralement déduit lorsque l’état de la demande passe à « Pending Approval » ou à un statut similaire.
Pourquoi c’est important Le suivi des approbations permet d’identifier les goulots d’étranglement du processus d’approbation et de mesurer le temps pendant lequel les demandes attendent une autorisation avant le début de leur traitement. Où les obtenir Cet événement est déduit du changement du champ d’état de sc_req_item vers une valeur indiquant une approbation en attente, ou de la création d’un enregistrement correspondant dans la table sysapproval_approver. Les changements sont consignés dans la table sys_audit. Collecte Identifiez l’horodatage auquel sc_req_item.state passe à « Pending Approval ». Type d’événement inferred
	Demande affectée à un groupe	Indique que la demande de service a été affectée à une équipe ou à un groupe de traitement spécifique. Cet événement est déduit de la détection d’un changement dans le champ du groupe d’affectation de l’élément de demande ou de ses tâches associées.
Pourquoi c’est important Le suivi des affectations aux groupes permet d’analyser la répartition de la charge entre les équipes et d’identifier les retards avant qu’une demande ne soit orientée vers les personnes chargées de son traitement. Où les obtenir Cet événement est déduit d’un changement du champ assignment_group dans la table sc_req_item ou sc_task. L’historique des changements est consigné dans la table sys_audit. Collecte Suivez les changements du champ assignment_group dans sys_audit. Type d’événement inferred
	Demande annulée	Cette activité constitue un état final pour les demandes annulées avant leur achèvement, par l’utilisateur ou par un agent. Elle est capturée lorsque l’état de la demande passe à « Cancelled » ou « Closed Cancelled ».
Pourquoi c’est important Il s’agit d’un événement de fin non réussi important. L’analyse des raisons d’annulation peut fournir des informations sur les besoins des utilisateurs, les inefficacités du processus ou l’évolution des priorités métier. Où les obtenir Cet événement est déduit lorsque le champ d’état de sc_req_item est mis à jour vers un état final annulé, tel que « Closed Cancelled ». Le changement est consigné dans la table sys_audit. Collecte Identifiez l’horodatage auquel sc_req_item.state passe à « Cancelled ». Type d’événement inferred
	Demande rejetée	Cette activité représente le cas où une demande est officiellement rejetée pendant la phase d’approbation. Il s’agit d’un parcours alternatif vers la clôture, capturé lorsqu’un approbateur marque la demande comme « rejected ».
Pourquoi c’est important Le suivi des rejets permet d’identifier les demandes non valides ou mal orientées, les problèmes liés à la soumission des demandes et les parcours d’exception importants pour l’analyse. Où les obtenir Cet événement est déduit du changement du champ d’état de l’enregistrement sysapproval_approver associé vers « rejected ». Il entraîne généralement le passage de sc_req_item à un état fermé et incomplet. Collecte Identifiez l’horodatage auquel sysapproval_approver.state devient « rejected ». Type d’événement inferred
	Demande rouverte	Cette activité capture les cas où une demande précédemment marquée comme résolue repasse à l’état ouvert. Elle est déduite d’un changement d’état de « Resolved » vers « Work in Progress » ou un statut similaire.
Pourquoi c’est important Il s’agit d’une mesure directe des reprises, essentielle au calcul du KPI « First-Pass Resolution Rate ». Un nombre élevé indique une qualité de solution insuffisante ou une résolution incomplète. Où les obtenir Cet événement est déduit d’un changement du champ d’état de sc_req_item, qui passe d’un état résolu ou fermé à un état ouvert ou en cours de traitement. Ce changement est consigné dans sys_audit. Collecte Détectez dans sys_audit le changement d’état de « Resolved » à « Work in Progress ». Type d’événement inferred
	Fournisseur externe mobilisé	Représente le transfert d’une demande de service ou de l’une de ses tâches à un fournisseur externe tiers pour traitement. Cet événement peut être déduit d’une affectation à un groupe propre au fournisseur ou de l’activation d’un indicateur sur la demande.
Pourquoi c’est important Cette activité permet d’analyser les performances du fournisseur et leur incidence sur le cycle de vie global de la demande. Elle est essentielle pour le Dashboard « External Vendor Engagement Cycle ». Où les obtenir Cet événement est généralement déduit. Il peut être fondé sur l’affectation du champ assignment_group au groupe d’un fournisseur ou sur l’activation d’un champ indicateur spécifique dans l’enregistrement sc_req_item ou sc_task. Collecte Identifiez le changement de assignment_group vers un groupe de fournisseur connu. Type d’événement inferred
	Informations fournies par l’utilisateur	Cette activité marque le moment où le demandeur a fourni les informations nécessaires. Elle est déduite lorsque la demande quitte l’état « Awaiting User Info » pour revenir à un état actif tel que « Work in Progress ».
Pourquoi c’est important Associée à l’activité « Informations demandées à l’utilisateur », elle permet de mesurer précisément les retards imputables à l’utilisateur et d’évaluer l’efficacité du processus de communication. Où les obtenir Cet événement est déduit du changement du champ d’état de sc_req_item, qui passe d’un statut « awaiting information » à un statut actif. Il est souvent déclenché lorsque l’utilisateur ajoute un commentaire ou répond à un e-mail. Collecte Identifiez l’horodatage auquel l’état passe de « Awaiting User Info » à « Work in Progress ». Type d’événement inferred
	Tâche de traitement créée	Représente la création d’un élément de travail ou d’une tâche spécifique nécessaire au traitement de la demande de service. Il s’agit d’un événement explicite enregistré lors de la création d’un nouvel enregistrement dans la table Catalog Task.
Pourquoi c’est important Pour les demandes complexes, l’analyse de la création et de l’achèvement des tâches individuelles fournit une vue plus détaillée du processus de traitement et des points où surviennent les retards. Où les obtenir Il s’agit d’un événement explicite capturé à partir de l’horodatage de création (champ sys_created_on) d’un enregistrement de la table sc_task lié à sc_req_item. Collecte Utilisez l’horodatage sys_created_on des enregistrements sc_task. Type d’événement explicit

Recommandé Facultatif

Guides d’extraction

Comment récupérer vos données depuis ServiceNow

Étapes

Comprendre l’approche multi-export : en raison de la structure des données de ServiceNow, un seul export ne peut pas contenir tous les événements nécessaires. Vous devez effectuer plusieurs exports depuis différentes tables, puis regrouper les données en dehors de ServiceNow. Les principales tables sont Requested Item (sc_req_item), Approval (sysapproval_approver), Catalog Task (sc_task) et Audit (sys_audit).
Export 1 : données principales des demandes de service : accédez à la table Requested Item en saisissant sc_req_item.list dans le navigateur de filtres. Appliquez un filtre sur la période souhaitée, par exemple [Created] [on] [Last 6 months]. Ajoutez des colonnes telles que Number, Sys Created On, Resolved, Closed, State, Assignment group, Assigned to, Priority et Made SLA. Cliquez avec le bouton droit sur un en-tête de colonne, choisissez Export, puis sélectionnez CSV ou XLSX.
Export 2 : décisions d’approbation : accédez à la table Approval en saisissant sysapproval_approver.list. Filtrez la liste pour afficher uniquement les enregistrements liés aux demandes de service : [Source table] [is] [sc_req_item] ET [Created] [on] [Last 6 months]. Ajoutez des colonnes telles que Approving.Number, State, Sys Created On et Sys Updated On. Exportez la liste filtrée.
Export 3 : création des tâches de traitement : accédez à la table Catalog Task en saisissant sc_task.list. Filtrez la liste afin de la relier aux demandes de la période choisie, par exemple [Request Item.Created] [on] [Last 6 months]. Ajoutez les colonnes Request Item.Number, Sys Created On, State, Assignment group et Assigned to. Exportez les données.
Export 4 : historique détaillé des activités : accédez à la table Audit à l’aide de sys_audit.list. Cette table contient l’historique des modifications de champs. Créez un filtre pour [Table name] [is] [sc_req_item] ET [Created] [on] [Last 6 months] ET [Field name] [is one of] [state, assignment_group, assigned_to]. Ajoutez les colonnes Document key, Field name, Old value, New value et Sys Created On. Exportez ces données. Notez que l’accès à cette table peut nécessiter des autorisations élevées.
Regrouper et transformer les données : utilisez un outil tel que Microsoft Excel, Python avec pandas ou un outil dédié de préparation des données pour fusionner les quatre fichiers exportés. Utilisez le numéro de demande de service ou le Sys ID comme clé commune pour joindre les données.
Créer la structure du journal d’événements : dans le fichier regroupé, créez les colonnes requises : ServiceRequestID, ActivityName et EventTime.
Associer les données brutes aux activités : créez une nouvelle ligne pour chaque activité distincte. Par exemple :
- Pour Service Request Created, utilisez Sys Created On de l’export sc_req_item.
- Pour Request Approved, utilisez Sys Updated On de l’export sysapproval_approver lorsque State passe à « approved ».
- Pour Request Assigned to Group, recherchez dans l’export sys_audit la ligne où Field name vaut assignment_group, puis utilisez Sys Created On de cet enregistrement d’audit comme EventTime.
Renseigner les colonnes d’attributs : renseignez les attributs AssignedTo, AssignmentGroup, Priority, State, Category et MadeSLA pour chaque ligne d’activité. Les valeurs doivent refléter l’état de la demande au moment de l’événement.
Ajouter les colonnes de métadonnées : ajoutez SourceSystem avec une valeur statique telle que « ServiceNow » et LastDataUpdate avec l’horodatage de l’extraction.
Finaliser et exporter : enregistrez les données finales transformées et regroupées dans un fichier CSV unique, en veillant à ce que les en-têtes de colonnes correspondent aux exigences d’importation.

Configuration

Tables cibles : l’extraction nécessite des données provenant de plusieurs tables :
- sc_req_item : contient les principaux enregistrements de demandes de service (Requested Item).
- sysapproval_approver : stocke les enregistrements d’approbation associés aux demandes.
- sc_task : contient les différentes tâches de traitement générées pour une demande.
- sys_audit : fournit un historique détaillé des modifications de champs, indispensable pour suivre les affectations et les changements d’état.
Filtrage par période : il est essentiel d’appliquer une période cohérente, par exemple Created on Last 6 months, à tous les exports afin de préserver l’intégrité des données. Une période de trois à six mois est recommandée pour trouver un équilibre entre volume et pertinence des analyses.
Filtres clés : en plus de la période, utilisez des filtres tels que Source table is sc_req_item dans la table des approbations et Table name is sc_req_item dans la table d’audit pour isoler les enregistrements pertinents.
Colonnes essentielles : veillez à exporter les identifiants clés tels que Nombre et Sys ID (Document key dans l’audit) afin de relier les jeux de données. Les horodatages tels que Sys Created On, Sys Updated On, Résolu et Fermé sont indispensables à la création du journal d’événements.
Prérequis : un compte utilisateur ServiceNow disposant au minimum du rôle itil est nécessaire pour accéder à la plupart des tables requises. L’export de la table sys_audit peut nécessiter le rôle admin ou un rôle spécialisé, en raison de son volume et de la sensibilité des données.

a Exemple de requête config

This method uses the ServiceNow user interface for filtering and exporting, so there is no single script. The configuration consists of setting filters and choosing columns for multiple list views.

**Configuration for Export 1: Requested Items**
*   **Table**: `sc_req_item`
*   **Filter Conditions**:
    1. `[Created] [on] [Last 6 months]`
    2. `[Active] [is one of] [true, false]` (Or adjust based on process scope)
*   **Columns to Add**: `Number`, `Sys ID`, `Sys Created On`, `Resolved`, `Closed`, `State`, `Stage`, `Assignment group`, `Assigned to`, `Priority`, `Category`, `Made SLA`

**Configuration for Export 2: Approvals**
*   **Table**: `sysapproval_approver`
*   **Filter Conditions**:
    1. `[Source table] [is] [sc_req_item]`
    2. `[Created] [on] [Last 6 months]`
*   **Columns to Add**: `Approving`, `Approving.Number`, `State`, `Sys Created On`, `Sys Updated On`

**Configuration for Export 3: Catalog Tasks**
*   **Table**: `sc_task`
*   **Filter Conditions**:
    1. `[Request Item.Created] [on] [Last 6 months]`
*   **Columns to Add**: `Request Item`, `Request Item.Number`, `Sys Created On`, `Sys Updated On`, `State`, `Assignment group`, `Assigned to`

**Configuration for Export 4: Audit History**
*   **Table**: `sys_audit`
*   **Filter Conditions**:
    1. `[Table name] [is] [sc_req_item]`
    2. `[Created] [on] [Last 6 months]`
    3. `[Field name] [is one of] [state, assignment_group, assigned_to]`
*   **Columns to Add**: `Document key`, `Table name`, `Field name`, `Old value`, `New value`, `Sys Created On`

Étapes

Préparer l’environnement Python : vérifiez que Python 3.6 ou une version ultérieure est installé. Installez les bibliothèques nécessaires avec pip : pip install requests pandas.
Configurer les paramètres du script : ouvrez le script Python dans un éditeur. Repérez la section de configuration en haut du script. Saisissez l’URL de votre instance ServiceNow, par exemple https://your-instance.service-now.com, ainsi qu’un nom d’utilisateur et un mot de passe pour un compte de service disposant des autorisations de lecture nécessaires sur les tables concernées.
Définir la période d’extraction : définissez les dates de début et de fin de l’extraction en modifiant les variables start_date et end_date. Il est recommandé de commencer par une période plus courte, par exemple trois mois, afin de tester le script et d’en vérifier les performances.
Vérifier les noms des tables et des champs : le script utilise des noms de tables ServiceNow standard tels que sc_req_item, sys_audit et sc_task. Vérifiez que ces noms de tables et de champs correspondent à votre configuration ServiceNow. Modifiez-les dans le script si votre instance utilise des tables ou des champs personnalisés.
Exécuter le script Python : lancez le script depuis la ligne de commande ou le terminal avec la commande python your_script_name.py. Le script se connectera à l’API ServiceNow, récupérera les données correspondant à chaque activité indiquée et affichera des messages de progression dans la console.
Gérer la pagination de l’API : le script inclut une fonction qui gère automatiquement la pagination. Il effectue plusieurs appels d’API lorsque le nombre d’enregistrements dépasse la limite de page (sysparm_limit), jusqu’à récupérer toutes les données de la période définie.
Transformer et regrouper les données : le script traite la réponse JSON brute de l’API pour chaque type d’activité. Il extrait les champs requis, les associe au schéma du journal d’événements (ServiceRequestID, ActivityName, EventTime, etc.), puis les regroupe dans un jeu de données unifié.
Générer le fichier du journal d’événements : une fois l’exécution terminée, le script enregistre le journal d’événements final dans un fichier CSV nommé servicenow_servicerequest_eventlog.csv, dans le même répertoire que celui depuis lequel le script a été exécuté.
Préparer l’importation : ouvrez le fichier CSV généré dans un tableur afin de vérifier que les données sont complètes et correctes. Vérifiez que les en-têtes de colonnes correspondent au schéma ProcessMind requis avant l’importation.

Configuration

URL de l’instance ServiceNow : URL de base de votre instance ServiceNow, par exemple https://your-instance.service-now.com.
Authentification : un nom d’utilisateur et un mot de passe de compte de service disposant d’un accès en lecture aux tables sc_req_item, sys_audit, sysapproval_approver et sc_task sont requis.
Période : définissez les variables start_date et end_date dans le script afin de délimiter la période d’extraction. Une période de 3 à 6 mois est recommandée pour une première analyse.
Limite de page (sysparm_limit) : le script définit le nombre maximal d’enregistrements renvoyés par appel d’API. La valeur par défaut est 1 000, ce qui convient à la plupart des instances. Vous pouvez l’ajuster en fonction des performances du système et des limites de débit de l’API.
Filtres de requête (sysparm_query) : le script utilise des filtres de date (sys_created_on>=...) pour limiter l’extraction. Vous pouvez ajouter d’autres filtres à la chaîne de requête, par exemple un filtre sur un élément de catalogue ou un groupe d’affectation précis, afin de réduire le volume de données (active=true^category=hardware).
Valeurs d’affichage : le paramètre sysparm_display_value=true permet de récupérer les noms lisibles des champs de référence plutôt que leurs valeurs internes sys_id. Ce paramètre est essentiel pour des attributs tels que AssignmentGroup et AssignedTo.

a Exemple de requête python

import requests
import pandas as pd
import datetime

class=class="hl-string">"hl-comment"># --- Configuration ---
SN_INSTANCE = class="hl-string">'https://[your-instance].service-now.com'
SN_USER = class="hl-string">'[your-username]'
SN_PASSWORD = class="hl-string">'[your-password]'

class=class="hl-string">"hl-comment"># Date range for the extraction (YYYY-MM-DD)
start_date = class="hl-string">'[YYYY-MM-DD]'
end_date = class="hl-string">'[YYYY-MM-DD]'

class=class="hl-string">"hl-comment"># --- End Configuration ---

def query_servicenow_table(table, query, fields):
    class="hl-string">"""Queries a ServiceNow table with pagination."""
    all_records = []
    offset = 0
    limit = 1000
    
    headers = {class="hl-string">"Accept": class="hl-string">"application/json"}
    url = fclass="hl-string">"{SN_INSTANCE}/api/now/table/{table}"
    
    while True:
        params = {
            class="hl-string">'sysparm_query': query,
            class="hl-string">'sysparm_fields': class="hl-string">','.join(fields),
            class="hl-string">'sysparm_limit': limit,
            class="hl-string">'sysparm_offset': offset,
            class="hl-string">'sysparm_display_value': class="hl-string">'true',
            class="hl-string">'sysparm_exclude_reference_link': class="hl-string">'true'
        }
        
        print(fclass="hl-string">"Querying {table} with offset {offset}...")
        response = requests.get(url, auth=(SN_USER, SN_PASSWORD), headers=headers, params=params)
        response.raise_for_status() class=class="hl-string">"hl-comment"># Raise an exception for bad status codes
        
        records = response.json().get(class="hl-string">'result', [])
        if not records:
            break
        all_records.extend(records)
        offset += limit
        
    return all_records

def main():
    class="hl-string">"""Main function to extract, transform, and save the event log."""
    all_events = []
    source_system = class="hl-string">'ServiceNow'
    last_data_update = datetime.datetime.now().isoformat()

    class=class="hl-string">"hl-comment"># Define common attributes to fetch for context
    context_fields = [class="hl-string">'number', class="hl-string">'assignment_group', class="hl-string">'assigned_to', class="hl-string">'priority', class="hl-string">'state', class="hl-string">'cat_item.category', class="hl-string">'made_sla']

    class=class="hl-string">"hl-comment"># 1. Service Request Created
    query = fclass="hl-string">'sys_created_on>={start_date} 00:00:00^sys_created_on<={end_date} 23:59:59'
    fields = [class="hl-string">'sys_created_on'] + context_fields
    req_items = query_servicenow_table(class="hl-string">'sc_req_item', query, fields)
    for item in req_items:
        all_events.append({
            class="hl-string">'ServiceRequestID': item[class="hl-string">'number'],
            class="hl-string">'ActivityName': class="hl-string">'Service Request Created',
            class="hl-string">'EventTime': item[class="hl-string">'sys_created_on'],
            class="hl-string">'AssignedTo': item.get(class="hl-string">'assigned_to'),
            class="hl-string">'AssignmentGroup': item.get(class="hl-string">'assignment_group'),
            class="hl-string">'Priority': item.get(class="hl-string">'priority'),
            class="hl-string">'State': item.get(class="hl-string">'state'),
            class="hl-string">'Category': item.get(class="hl-string">'cat_item.category'),
            class="hl-string">'MadeSLA': item.get(class="hl-string">'made_sla')
        })

    class=class="hl-string">"hl-comment"># Get a list of relevant document keys (sys_id of sc_req_item)
    doc_keys_query = fclass="hl-string">'tablename=sc_req_item^sys_created_on>={start_date} 00:00:00^sys_created_on<={end_date} 23:59:59'
    audit_records = query_servicenow_table(class="hl-string">'sys_audit', doc_keys_query, [class="hl-string">'documentkey'])
    relevant_doc_keys = list(set([rec[class="hl-string">'documentkey'] for rec in audit_records]))
    
    class=class="hl-string">"hl-comment"># Query audit and other tables in batches to avoid long URLs
    batch_size = 50
    for i in range(0, len(relevant_doc_keys), batch_size):
        key_batch = relevant_doc_keys[i:i+batch_size]
        key_batch_str = class="hl-string">','.join(key_batch)

        class=class="hl-string">"hl-comment"># 2-14. Activities from sys_audit, sysapproval_approver, sc_task
        class=class="hl-string">"hl-comment"># Fetch sc_req_item details for context
        ritm_context = {ritm[class="hl-string">'sys_id']: ritm for ritm in query_servicenow_table(class="hl-string">'sc_req_item', fclass="hl-string">'sys_idIN{key_batch_str}', [class="hl-string">'sys_id'] + context_fields)}

        class=class="hl-string">"hl-comment"># Activities based on state changes and field updates from sys_audit
        audit_query = fclass="hl-string">'documentkeyIN{key_batch_str}^fieldnameINassignment_group,assigned_to,state'
        audit_log = query_servicenow_table(class="hl-string">'sys_audit', audit_query, [class="hl-string">'documentkey', class="hl-string">'sys_created_on', class="hl-string">'fieldname', class="hl-string">'newvalue', class="hl-string">'oldvalue'])
        for log in audit_log:
            context = ritm_context.get(log[class="hl-string">'documentkey'], {})
            if not context:
                continue

            event = {
                class="hl-string">'ServiceRequestID': context.get(class="hl-string">'number'),
                class="hl-string">'EventTime': log[class="hl-string">'sys_created_on'],
                class="hl-string">'AssignedTo': context.get(class="hl-string">'assigned_to'),
                class="hl-string">'AssignmentGroup': context.get(class="hl-string">'assignment_group'),
                class="hl-string">'Priority': context.get(class="hl-string">'priority'),
                class="hl-string">'State': context.get(class="hl-string">'state'),
                class="hl-string">'Category': context.get(class="hl-string">'cat_item.category'),
                class="hl-string">'MadeSLA': context.get(class="hl-string">'made_sla'),
            }
            activity = None
            class=class="hl-string">"hl-comment"># Map audit entries to activities
            if log[class="hl-string">'fieldname'] == class="hl-string">'assignment_group' and log[class="hl-string">'newvalue']:
                activity = class="hl-string">'Request Assigned to Group'
                event[class="hl-string">'AssignmentGroup'] = log[class="hl-string">'newvalue']
            elif log[class="hl-string">'fieldname'] == class="hl-string">'assigned_to' and log[class="hl-string">'newvalue']:
                activity = class="hl-string">'Request Assigned to Agent'
                event[class="hl-string">'AssignedTo'] = log[class="hl-string">'newvalue']
            elif log[class="hl-string">'fieldname'] == class="hl-string">'state':
                class=class="hl-string">"hl-comment"># Define state mappings, may need customization
                state_map = {
                    class="hl-string">'Awaiting User Info': class="hl-string">'Information Requested from User',
                    class="hl-string">'Resolved': class="hl-string">'Service Request Resolved',
                    class="hl-string">'Closed Complete': class="hl-string">'Service Request Closed',
                    class="hl-string">'Closed Cancelled': class="hl-string">'Request Cancelled'
                }
                if log[class="hl-string">'newvalue'] in state_map:
                    activity = state_map[log[class="hl-string">'newvalue']]
                elif log[class="hl-string">'oldvalue'] == class="hl-string">'Awaiting User Info':
                    activity = class="hl-string">'Information Provided by User'
                elif log[class="hl-string">'oldvalue'] == class="hl-string">'Resolved':
                    activity = class="hl-string">'Request Reopened'
                class=class="hl-string">"hl-comment"># For class="hl-string">'Approval Requested', class="hl-string">'External Vendor Engaged' - more complex logic might be needed
                class=class="hl-string">"hl-comment"># This is a common inference. Adjust if you have a specific state.
                if log[class="hl-string">'newvalue'] == class="hl-string">'Pending Approval':
                     activity = class="hl-string">'Approval Requested'

            if activity:
                event[class="hl-string">'ActivityName'] = activity
                all_events.append(event)

        class=class="hl-string">"hl-comment"># Approval Activities
        approval_query = fclass="hl-string">'sysapprovalIN{key_batch_str}'
        approvals = query_servicenow_table(class="hl-string">'sysapproval_approver', approval_query, [class="hl-string">'sysapproval', class="hl-string">'sys_updated_on', class="hl-string">'state'])
        for appr in approvals:
            context = ritm_context.get(appr[class="hl-string">'sysapproval'], {})
            if not context: continue
            activity = None
            if appr[class="hl-string">'state'] == class="hl-string">'approved':
                activity = class="hl-string">'Request Approved'
            elif appr[class="hl-string">'state'] == class="hl-string">'rejected':
                activity = class="hl-string">'Request Rejected'
            if activity:
                all_events.append({
                    class="hl-string">'ServiceRequestID': context.get(class="hl-string">'number'),
                    class="hl-string">'ActivityName': activity,
                    class="hl-string">'EventTime': appr[class="hl-string">'sys_updated_on'],
                    class="hl-string">'AssignedTo': context.get(class="hl-string">'assigned_to'), class="hl-string">'AssignmentGroup': context.get(class="hl-string">'assignment_group'), class="hl-string">'Priority': context.get(class="hl-string">'priority'), class="hl-string">'State': context.get(class="hl-string">'state'), class="hl-string">'Category': context.get(class="hl-string">'cat_item.category'), class="hl-string">'MadeSLA': context.get(class="hl-string">'made_sla')
                })

        class=class="hl-string">"hl-comment"># Fulfillment Task Creation
        task_query = fclass="hl-string">'request_itemIN{key_batch_str}'
        tasks = query_servicenow_table(class="hl-string">'sc_task', task_query, [class="hl-string">'request_item', class="hl-string">'sys_created_on', class="hl-string">'number'])
        for task in tasks:
            context = ritm_context.get(task[class="hl-string">'request_item'], {})
            if not context: continue
            all_events.append({
                class="hl-string">'ServiceRequestID': context.get(class="hl-string">'number'),
                class="hl-string">'ActivityName': fclass="hl-string">'Fulfillment Task Created - {task["number"]}',
                class="hl-string">'EventTime': task[class="hl-string">'sys_created_on'],
                class="hl-string">'AssignedTo': context.get(class="hl-string">'assigned_to'), class="hl-string">'AssignmentGroup': context.get(class="hl-string">'assignment_group'), class="hl-string">'Priority': context.get(class="hl-string">'priority'), class="hl-string">'State': context.get(class="hl-string">'state'), class="hl-string">'Category': context.get(class="hl-string">'cat_item.category'), class="hl-string">'MadeSLA': context.get(class="hl-string">'made_sla')
            })

    class=class="hl-string">"hl-comment"># Post-processing and saving
    if not all_events:
        print(class="hl-string">"No events found for the given criteria.")
        return

    df = pd.DataFrame(all_events)
    df[class="hl-string">'SourceSystem'] = source_system
    df[class="hl-string">'LastDataUpdate'] = last_data_update
    
    class=class="hl-string">"hl-comment"># Reorder columns to match schema
    final_cols = [class="hl-string">'ServiceRequestID', 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">'State', class="hl-string">'Category', class="hl-string">'MadeSLA']
    df = df[final_cols]
    
    df.sort_values(by=[class="hl-string">'ServiceRequestID', class="hl-string">'EventTime'], inplace=True)
    df.to_csv(class="hl-string">'servicenow_servicerequest_eventlog.csv', index=False)
    print(class="hl-string">"Extraction complete. File saved to servicenow_servicerequest_eventlog.csv")

if __name__ == class="hl-string">'__main__':
    main()

Étapes

Configurer l’utilisateur de l’API ServiceNow : créez un utilisateur dédié dans votre instance ServiceNow pour cette intégration. Attribuez-lui les rôles rest_service et itil. Vérifiez qu’il dispose des autorisations de lecture (ACL) sur les tables suivantes : Requested Item (sc_req_item), Catalog Task (sc_task), Approval (sysapproval_approver) et Audit (sys_audit).
Préparer votre environnement de développement : installez Node.js sur la machine utilisée pour l’extraction. Initialisez ensuite un nouveau projet Node.js et installez la bibliothèque axios pour effectuer les requêtes HTTP, ainsi que fast-csv pour écrire le fichier de sortie, en exécutant npm install axios fast-csv dans votre terminal.
Configurer le script d’extraction : copiez le code JavaScript fourni dans un fichier, par exemple extract.js. Remplacez les valeurs fictives situées en haut du script par l’URL de votre instance ServiceNow, votre nom d’utilisateur API et votre mot de passe.
Définir la période et les filtres : modifiez les variables startDate et endDate dans le script afin de définir la période d’extraction. Vous pouvez également ajouter des filtres aux chaînes sysparm_query de chaque activité pour restreindre le périmètre, par exemple en filtrant selon un élément de catalogue ou un groupe d’affectation précis.
Comprendre les appels API : le script effectue des appels API distincts pour chacune des 14 activités requises. Les événements tels que la création sont interrogés directement dans leurs tables sources (sc_req_item, sc_task), tandis que les changements de statut et les affectations sont récupérés dans la table sys_audit, en recherchant les mises à jour de champs correspondantes.
Exécuter le script : lancez le script depuis votre terminal à l’aide de la commande node extract.js. Le script se connecte à la Table API de ServiceNow, récupère les données de chaque activité et gère automatiquement la pagination.
Traiter les données : au fur et à mesure de leur récupération, le script transforme la réponse JSON de ServiceNow en un format de journal d’événements standardisé, en associant les champs à des colonnes telles que ServiceRequestID, ActivityName et EventTime.
Regrouper et consolider les résultats : le script rassemble les résultats de tous les appels API individuels dans un tableau unique représentant l’intégralité du journal d’événements.
Générer le fichier de sortie : une fois toutes les données récupérées et traitées, le script utilise la bibliothèque fast-csv pour écrire le journal d’événements consolidé dans un fichier nommé servicenow_event_log.csv, situé dans le même répertoire.
Préparer le chargement : le fichier CSV généré contient les colonnes requises pour le Process Mining. Aucun formatage supplémentaire n’est nécessaire avant son chargement dans la plateforme ProcessMind.

Configuration

URL de l’instance ServiceNow : l’URL de base de votre environnement ServiceNow, par exemple https://your-instance.service-now.com.
Identifiants API : un nom d’utilisateur et un mot de passe valides pour un utilisateur ServiceNow disposant des rôles et autorisations de lecture nécessaires (rest_service, itil).
Période : nous vous recommandons d’extraire les données sur une période de 3 à 6 mois afin d’obtenir un échantillon représentatif. Cette période est définie dans le script à l’aide des variables startDate et endDate, appliquées aux champs d’horodatage appropriés dans les requêtes API.
sysparm_query : il s’agit du principal paramètre d’URL utilisé pour filtrer les enregistrements. Le script l’utilise largement pour isoler certains événements, par exemple les enregistrements créés pendant une période donnée ou les entrées d’audit indiquant un changement d’état de « Resolved » à « Work in Progress ».
sysparm_fields : ce paramètre précise les colonnes à renvoyer dans l’appel API. Son utilisation améliore sensiblement les performances en réduisant le volume de données transférées. Le script préconfigure les champs nécessaires pour chaque requête.
Limite de pagination (sysparm_limit) : le script est configuré pour récupérer les enregistrements par lots de 1 000. Cette valeur peut être ajustée, mais il est recommandé de rester en dessous de la limite maximale de ServiceNow, généralement fixée à 10 000, afin de garantir la stabilité.

a Exemple de requête javascript

const axios = require('axios');
const fs = require('fs');
const { format, writeToStream } = require('@fast-csv/format');

// --- Configuration ---
const SN_INSTANCE = 'https://YOUR_INSTANCE.service-now.com';
const SN_USER = 'YOUR_API_USER';
const SN_PASSWORD = 'YOUR_API_PASSWORD';
const BATCH_SIZE = 1000;

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

const auth = { username: SN_USER, password: SN_PASSWORD };

// --- Helper Function for Paginated API Calls ---
async function fetchAllRecords(table, query, fields, processFunction) {
    let offset = 0;
    let hasMore = true;
    let allEvents = [];

    console.log(`Starting fetch for table: ${table}`);

    while (hasMore) {
        try {
            const response = await axios.get(`${SN_INSTANCE}/api/now/table/${table}`, {
                auth,
                params: {
                    sysparm_query: query,
                    sysparm_fields: fields,
                    sysparm_limit: BATCH_SIZE,
                    sysparm_offset: offset,
                    sysparm_display_value: 'true', // Get display values for reference fields
                    sysparm_exclude_reference_link: true
                }
            });

            const records = response.data.result;
            if (records.length > 0) {
                console.log(`Fetched ${records.length} records from ${table} with offset ${offset}`);
                const processedEvents = records.map(processFunction);
                allEvents.push(...processedEvents);
                offset += BATCH_SIZE;
            } else {
                hasMore = false;
            }
        } catch (error) {
            console.error(`Error fetching data from ${table}:`, error.response ? error.response.statusText : error.message);
            hasMore = false; // Stop on error
        }
    }
    return allEvents;
}

// --- Main Extraction Logic ---
async function extractServiceRequestData() {
    let finalEventLog = [];
    const now = new Date().toISOString();

    // 1. Service Request Created
    const createdEvents = await fetchAllRecords(
        'sc_req_item',
        `sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'number,sys_created_on,assigned_to,assignment_group,priority,state,cat_item.category,made_sla',
        (r) => ({
            ServiceRequestID: r.number,
            ActivityName: 'Service Request Created',
            EventTime: r.sys_created_on,
            SourceSystem: 'ServiceNow',
            LastDataUpdate: now,
            AssignedTo: r.assigned_to,
            AssignmentGroup: r.assignment_group,
            Priority: r.priority,
            State: r.state,
            Category: r['cat_item.category'],
            MadeSLA: r.made_sla
        })
    );
    finalEventLog.push(...createdEvents);

    // 2. Approval Requested
    const approvalRequestedEvents = await fetchAllRecords(
        'sysapproval_approver',
        `sysapproval.sys_class_name=sc_req_item^state=requested^sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'sysapproval,sys_created_on',
        (r) => ({
            ServiceRequestID: r.sysapproval,
            ActivityName: 'Approval Requested',
            EventTime: r.sys_created_on,
            SourceSystem: 'ServiceNow',
            LastDataUpdate: now,
            AssignedTo: null, AssignmentGroup: null, Priority: null, State: 'Pending Approval', Category: null, MadeSLA: null
        })
    );
    finalEventLog.push(...approvalRequestedEvents);

    // Function to process audit records
    const processAuditRecord = (activityName) => (r) => ({
        ServiceRequestID: r['documentkey.number'],
        ActivityName: activityName,
        EventTime: r.sys_created_on,
        SourceSystem: 'ServiceNow',
        LastDataUpdate: now,
        AssignedTo: activityName === 'Request Assigned to Agent' ? r.newvalue : null,
        AssignmentGroup: activityName === 'Request Assigned to Group' ? r.newvalue : null,
        Priority: null, 
        State: ['Service Request Resolved', 'Service Request Closed', 'Request Cancelled', 'Request Reopened', 'Information Requested from User', 'Information Provided by User'].includes(activityName) ? r.newvalue : null,
        Category: null, 
        MadeSLA: null
    });
    
    // 3. Request Approved
    const approvedEvents = await fetchAllRecords(
        'sys_audit',
        `tablename=sysapproval_approver^fieldname=state^newvalue=approved^sys_created_on>=${startDate}^sys_created_on<=${endDate}^documentkey.sysapproval.sys_class_name=sc_req_item`,
        'documentkey.sysapproval.number,sys_created_on',
        (r) => ({ ServiceRequestID: r['documentkey.sysapproval.number'], ActivityName: 'Request Approved', EventTime: r.sys_created_on, SourceSystem: 'ServiceNow', LastDataUpdate: now, AssignedTo: null, AssignmentGroup: null, Priority: null, State: 'Approved', Category: null, MadeSLA: null })
    );
    finalEventLog.push(...approvedEvents);

    // 4. Request Assigned to Group
    const assignedGroupEvents = await fetchAllRecords(
        'sys_audit',
        `tablename=sc_req_item^fieldname=assignment_group^sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'documentkey.number,sys_created_on,newvalue',
        processAuditRecord('Request Assigned to Group')
    );
    finalEventLog.push(...assignedGroupEvents);

    // 5. Request Assigned to Agent
    const assignedAgentEvents = await fetchAllRecords(
        'sys_audit',
        `tablename=sc_req_item^fieldname=assigned_to^sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'documentkey.number,sys_created_on,newvalue',
        processAuditRecord('Request Assigned to Agent')
    );
    finalEventLog.push(...assignedAgentEvents);

    // 6. Fulfillment Task Created
    const taskCreatedEvents = await fetchAllRecords(
        'sc_task',
        `request_item.sys_class_name=sc_req_item^sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'request_item.number,sys_created_on',
        (r) => ({ ServiceRequestID: r['request_item.number'], ActivityName: 'Fulfillment Task Created', EventTime: r.sys_created_on, SourceSystem: 'ServiceNow', LastDataUpdate: now, AssignedTo: null, AssignmentGroup: null, Priority: null, State: null, Category: null, MadeSLA: null })
    );
    finalEventLog.push(...taskCreatedEvents);

    // 7. Information Requested from User
    const infoRequestedEvents = await fetchAllRecords(
        'sys_audit',
        `tablename=sc_req_item^fieldname=state^newvalue=Awaiting User Info^sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'documentkey.number,sys_created_on,newvalue',
        processAuditRecord('Information Requested from User')
    );
    finalEventLog.push(...infoRequestedEvents);

    // 8. Information Provided by User
    const infoProvidedEvents = await fetchAllRecords(
        'sys_audit',
        `tablename=sc_req_item^fieldname=state^oldvalue=Awaiting User Info^sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'documentkey.number,sys_created_on,newvalue',
        processAuditRecord('Information Provided by User')
    );
    finalEventLog.push(...infoProvidedEvents);

    // 9. External Vendor Engaged (Note: requires a specific vendor group name)
    const vendorEngagedEvents = await fetchAllRecords(
        'sys_audit',
        `tablename=sc_req_item^fieldname=assignment_group^newvalue=[Your Vendor Assignment Group Name]^sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'documentkey.number,sys_created_on,newvalue',
        processAuditRecord('External Vendor Engaged')
    );
    finalEventLog.push(...vendorEngagedEvents);

    // 10. Request Reopened
    const reopenedEvents = await fetchAllRecords(
        'sys_audit',
        `tablename=sc_req_item^fieldname=state^oldvalue=Resolved^newvalue=Work in Progress^sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'documentkey.number,sys_created_on,newvalue',
        processAuditRecord('Request Reopened')
    );
    finalEventLog.push(...reopenedEvents);

    // 11. Service Request Resolved
    const resolvedEvents = await fetchAllRecords(
        'sys_audit',
        `tablename=sc_req_item^fieldname=state^newvalue=Resolved^sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'documentkey.number,sys_created_on,newvalue',
        processAuditRecord('Service Request Resolved')
    );
    finalEventLog.push(...resolvedEvents);

    // 12. Service Request Closed
    const closedEvents = await fetchAllRecords(
        'sys_audit',
        `tablename=sc_req_item^fieldname=state^newvalueINClosed Complete,Closed Incomplete,Closed Skipped^sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'documentkey.number,sys_created_on,newvalue',
        processAuditRecord('Service Request Closed')
    );
    finalEventLog.push(...closedEvents);

    // 13. Request Rejected
    const rejectedEvents = await fetchAllRecords(
        'sys_audit',
        `tablename=sysapproval_approver^fieldname=state^newvalue=rejected^sys_created_on>=${startDate}^sys_created_on<=${endDate}^documentkey.sysapproval.sys_class_name=sc_req_item`,
        'documentkey.sysapproval.number,sys_created_on',
        (r) => ({ ServiceRequestID: r['documentkey.sysapproval.number'], ActivityName: 'Request Rejected', EventTime: r.sys_created_on, SourceSystem: 'ServiceNow', LastDataUpdate: now, AssignedTo: null, AssignmentGroup: null, Priority: null, State: 'Rejected', Category: null, MadeSLA: null })
    );
    finalEventLog.push(...rejectedEvents);

    // 14. Request Cancelled
    const cancelledEvents = await fetchAllRecords(
        'sys_audit',
        `tablename=sc_req_item^fieldname=state^newvalue=Cancelled^sys_created_on>=${startDate}^sys_created_on<=${endDate}`,
        'documentkey.number,sys_created_on,newvalue',
        processAuditRecord('Request Cancelled')
    );
    finalEventLog.push(...cancelledEvents);

    // --- Write to CSV ---
    const csvStream = format({ headers: true });
    const writableStream = fs.createWriteStream('servicenow_event_log.csv');

    writableStream.on('finish', () => {
        console.log('CSV file written successfully.');
    });

    csvStream.pipe(writableStream);
    finalEventLog.sort((a, b) => new Date(a.EventTime) - new Date(b.EventTime)); // Sort events chronologically
    finalEventLog.forEach(row => csvStream.write(row));
    csvStream.end();
}

extractServiceRequestData();

Prêt à commencer ?

Utilisez ce modèle pour lancer votre initiative de Process Mining et réaliser des gains d’efficacité significatifs dans la gestion des demandes de service. Commencez dès aujourd’hui à optimiser vos flux de travail afin d’accélérer les résolutions et d’améliorer la satisfaction des clients.

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

Transformez la gestion des demandes de service : passez à l’action

Atteignez 70 % d’automatisation et accélérez la résolution des demandes de service.

Démarrer l’essai gratuit

Aucune carte bancaire requise. Configuration en quelques minutes.

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

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

Attributs de la gestion des demandes de service

Activités de gestion des demandes de service

Guides d’extraction

Rapport ServiceNow et export de listes au format CSV/XLSX

Étapes

Configuration

a Exemple de requête config

Script Python utilisant Requests pour l’extraction via l’API Table

Étapes

Configuration

a Exemple de requête python

Extraction de données via l’API REST Table de ServiceNow

Étapes

Configuration

a Exemple de requête javascript

Prêt à commencer ?

Transformez la gestion des demandes de service : passez à l’action

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

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

Attributs de la gestion des demandes de service

Activités de gestion des demandes de service

Guides d’extraction

Rapport ServiceNow et export de listes au format CSV/XLSX

Étapes

Configuration

a Exemple de requête config

Script Python utilisant Requests pour l’extraction via l’API Table

Étapes

Configuration

a Exemple de requête python

Extraction de données via l’API REST Table de ServiceNow

Étapes

Configuration

a Exemple de requête javascript

Prêt à commencer ?

Transformez la gestion des demandes de service : passez à l’action

Nous attachons de l’importance à votre confidentialité