> 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 vous aide à démarrer le Process Mining appliqué à la gestion des demandes de service. Il précise les attributs essentiels à recueillir, les activités importantes à suivre et les modalités d’extraction propres à ServiceNow. En vous appuyant sur ce modèle, vous pourrez réunir les données nécessaires à une analyse précise et à l’amélioration du processus.

Attributs recommandés à recueillir
Activités clés à suivre pour découvrir le processus
Guide étape par étape pour extraire les données

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 demandes de service

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

5 Obligatoire 6 Recommandé 10 Facultatif

	Nom	Description
	Activité ActivityName	Nom de l’événement ou de la tâche survenu dans le cycle de vie de la demande de service.
Description L’attribut Activité 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 « Demande créée », « Demande approuvée », « Affectée à un agent » ou « Demande clôturée ». L’analyse de ces activités permet de visualiser le flux du processus, de repérer les parcours courants et de détecter les écarts par rapport à la procédure standard. Elle constitue le point de départ pour comprendre le déroulement réel du traitement des demandes. Pourquoi est-ce important ? Cet attribut obligatoire définit les étapes de la cartographie du processus. Il est indispensable pour toutes les analyses, notamment pour repérer les goulots d’étranglement, les boucles de reprise et les problèmes de conformité. Où trouver ces données 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 enregistre la date et l’heure exactes de chaque activité du processus de demande de service. Il fournit l’ordre chronologique des événements nécessaire à la création de la cartographie du processus et à toute analyse temporelle. 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 de repérer les goulots d’étranglement, les manquements aux SLA et les tendances de performance au fil du temps. Pourquoi est-ce important ? Cet horodatage obligatoire permet de remettre les événements dans le bon ordre. Il sert de base à toutes les analyses de performance et de durée, notamment au calcul du temps de cycle et à l’identification des goulots d’étranglement. Où trouver ces données Généralement présent dans les champs « sys_updated_on » ou « sys_created_on » des tables ServiceNow concernées (par exemple, sc_request, 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 distingue chaque demande soumise par un utilisateur ou un système. Il relie tous les événements qui suivent, de l’enregistrement initial à la clôture définitive. En Process Mining, cet identifiant est indispensable pour reconstituer le parcours complet de chaque demande et analyser l’ensemble de son cycle de vie. Pourquoi est-ce important ? Il s’agit de l’ID de cas obligatoire. Il relie toutes les activités associées au sein d’une même instance de processus et permet d’analyser les flux, les variations et les temps de cycle. Où trouver ces données Table ServiceNow Request [sc_request], champ « number ». Exemples REQ0010001REQ0010025REQ0010112
	Dernière mise à jour des données LastDataUpdate	Horodatage de la dernière actualisation ou extraction des données.
Description Cet attribut indique la date et l’heure de la dernière extraction des données depuis le système source et de leur chargement dans l’outil de Process Mining. Il permet de connaître l’actualité des données analysées. Les analystes s’en servent 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. Cette information permet aussi de savoir à quelle date remontent les résultats de l’analyse. Pourquoi est-ce important ? Permet aux utilisateurs de connaître l’actualité des données, un élément essentiel pour se fier à l’analyse et prendre des décisions éclairées au bon moment. Où trouver ces données Ce champ de métadonnées est ajouté lors de l’ingestion des données. Il indique l’horodatage de fin du traitement ETL. Exemples 2023-10-27T04:00:00Z
	Système source SourceSystem	Système d’origine des données.
Description Cet attribut identifie le système d’origine des données, ici ServiceNow. Il est utile lorsque des données provenant de plusieurs systèmes sont réunies pour obtenir une vue d’ensemble du processus. Dans une analyse portant sur une seule source, cet attribut apporte un contexte important et facilite la gouvernance et la gestion des données. Il permet à chacun de connaître l’origine des données analysées. Pourquoi est-ce important ? Fournit des métadonnées essentielles à la gouvernance des données, à la traçabilité et à la compréhension du contexte, en particulier lorsque des données issues de plusieurs systèmes d’entreprise sont réunies. Où trouver ces données 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 chargé de la demande de service. Sa valeur change lorsque la demande est transférée d’une personne à une autre. L’analyse du champ « Assigned To » est essentielle pour comprendre la répartition de la charge de travail, les performances individuelles et l’incidence des transferts sur les délais de résolution. Elle aide à évaluer l’utilisation des ressources et à repérer les besoins de formation ou de clarification du processus afin de réduire les réaffectations. Pourquoi est-ce important ? Permet d’analyser la charge de travail des agents, leurs performances et les transferts. Cet attribut est essentiel à la gestion des ressources et à l’identification des goulots d’étranglement liés à certaines personnes. Où trouver ces données 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 matériel ou logiciel.
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 compétente et à établir des rapports sur les types de demandes reçues. En Process Mining, la catégorie permet de filtrer les données et de les analyser selon différentes dimensions. Les analystes peuvent ainsi comparer les flux de processus, les temps de cycle et les taux d’automatisation pour différents types de demandes, et repérer des écarts qui ne seraient pas visibles dans une vue d’ensemble. Par exemple, le traitement d’une demande de matériel peut être très différent de celui d’une demande de logiciel. Pourquoi est-ce important ? Permet de segmenter et de comparer les processus selon les types de service, afin de repérer les problèmes propres à chaque catégorie et les possibilités d’amélioration. Où trouver ces données 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 État indique l’étape actuelle du cycle de vie de la demande de service, 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. Elle permet de repérer les files d’attente et les retards, comme le temps passé à « Awaiting User Information », une cause fréquente d’allongement du temps de cycle. Pourquoi est-ce important ? Indique le statut de la demande à tout moment et permet d’analyser les temps d’attente, les files d’attente et la durée des différentes étapes du processus. Où trouver ces données Tables ServiceNow Request [sc_request] ou Request Item [sc_req_item], champ « state » ou « stage ». Exemples OuvertEn coursEn 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 désigne l’équipe, par exemple « Centre de services », « Opérations réseau » ou « Administration des bases de données », chargée d’une demande de service à une étape donnée. Cet attribut est essentiel pour analyser le flux du processus entre les différentes fonctions. En suivant les changements de groupe d’affectation, les organisations peuvent visualiser les transferts entre équipes, mesurer les temps d’attente dans la file de chaque groupe et repérer les dépendances ou les retards entre équipes. Ces informations aident à améliorer la collaboration entre les fonctions. Pourquoi est-ce important ? Suit la répartition du travail entre les équipes, met en évidence les transferts et aide à repérer les goulots d’étranglement ou les problèmes de performance propres à chaque équipe. Où trouver ces données Tables ServiceNow Request Item [sc_req_item] ou Catalog Task [sc_task], champ « assignment_group ». Exemples Centre de servicesAssistance 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é classe les demandes de service selon leur importance et leur urgence relatives. Elle est souvent déterminée en combinant l’impact et l’urgence, et aide les agents à décider quelles demandes traiter en premier. L’analyse des données par priorité permet de vérifier si les demandes prioritaires sont traitées plus rapidement que les autres. Elle permet de filtrer les Dashboards pour vérifier le respect des SLA pour les demandes critiques et d’évaluer l’efficacité du système de priorisation. Pourquoi est-ce important ? Permet de segmenter les demandes et de vérifier si les plus prioritaires sont traitées plus rapidement. Cet attribut est essentiel à l’analyse des SLA et à la répartition des ressources. Où trouver ces données 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é le délai de résolution défini dans l’accord de niveau de service (SLA). Il s’agit d’un indicateur de résultat important, qui mesure directement la qualité du service au regard des engagements pris. L’analyse de cet indicateur permet de calculer le taux de respect des SLA. Il peut servir de dimension pour comparer les parcours des demandes conformes à ceux des demandes ayant dépassé le délai, et ainsi faire ressortir les activités ou les schémas fréquemment associés au non-respect des SLA. Cette analyse contribue à la surveillance proactive des risques et à l’amélioration continue du service. Pourquoi est-ce important ? Mesure directement le respect des engagements de service et permet d’analyser les causes des dépassements de SLA en comparant les demandes conformes et non conformes. Où trouver ces données Table ServiceNow Task SLA [task_sla], champ 'has_breached'. La valeur doit être inversée (par exemple, MadeSLA = NOT has_breached). Exemples truefalse
	Automatisé IsAutomated	Indicateur précisant si une activité a été effectuée par un système ou par un mécanisme d’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é, par exemple un flux de travail ou une intégration. Ainsi, « Demande d’approbation » peut être automatisée, tandis que « Demande attribuée à un agent » peut être effectuée manuellement. L’analyse de cet attribut est essentielle pour mesurer et accroître le degré d’automatisation du processus de demande de service. Elle permet de repérer les tâches manuelles les plus longues et susceptibles d’être automatisées à l’avenir, afin d’améliorer l’efficacité et de réduire les coûts. Pourquoi est-ce important ? Permet de mesurer le taux d’automatisation et de repérer les tâches manuelles qui pourraient être automatisées, pour gagner en efficacité et réduire les coûts opérationnels. Où trouver ces données Déterminé en vérifiant si l’utilisateur ayant effectué une action (par exemple, 'sys_updated_by') est un utilisateur système ou d’intégration désigné. Exemples truefalse
	Canal ContactType	Mode utilisé par le demandeur pour soumettre sa demande de service.
Description Le type de contact, ou canal, indique comment la demande de service a été soumise. Les canaux courants sont le portail de services, le courriel, le téléphone ou une alerte automatisée. La prise en compte du canal est importante pour analyser les variations du processus susceptibles de dépendre du mode de soumission. Par exemple, les demandes envoyées par le portail sont parfois plus structurées et davantage automatisées, ce qui peut accélérer leur traitement par rapport aux demandes reçues par courriel. Cette analyse aide à privilégier les canaux les plus efficaces. Pourquoi est-ce important ? Permet de déterminer comment les différents canaux de soumission influent sur l’efficacité du processus, le degré d’automatisation et les temps de cycle, afin d’orienter l’amélioration des interactions avec les utilisateurs. Où trouver ces données Tables ServiceNow Request [sc_request] ou Interaction [interaction]. Le champ est souvent nommé 'contact_type'. Exemples PortailCourrielTéléphoneLibre-service
	Code de résolution ResolutionCode	Code qui classe le résultat final du traitement de la demande de service.
Description Le code de résolution classe de manière structurée la façon dont une demande de service a finalement été traitée. Il peut s’agir, par exemple, de « Résolu par automatisation », « Erreur de l’utilisateur » ou « Demande devenue inutile ». Cet attribut est essentiel au Dashboard d’analyse des causes des retards. En mettant en relation les codes de résolution avec les temps de cycle longs ou les taux de reprise élevés, les analystes peuvent repérer des problèmes systémiques. Par exemple, si les demandes portant le code « Informations incomplètes » sont systématiquement traitées lentement, cela peut révéler un problème lors de la collecte initiale des données. Pourquoi est-ce important ? Fournit des données structurées sur les résultats des résolutions, ce qui permet d’analyser les causes des retards, des reprises et d’autres inefficacités du processus. Où trouver ces données Table ServiceNow Request Item [sc_req_item] ou table de tâches associée, champ généralement nommé 'close_code' ou 'resolution_code'. Exemples Résolu (définitivement)Non résolu (non reproductible)Demande satisfaiteAnnulée par l’utilisateur
	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 détermine ainsi la durée de l’activité en cours. Cet attribut est indispensable 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 durées de traitement et d’attente. Ces mesures sont essentielles pour repérer les goulots d’étranglement, évaluer l’efficacité des ressources et suivre les performances par rapport aux objectifs de durée. Pourquoi est-ce important ? Cet attribut est nécessaire pour calculer la durée de chaque activité, un élément central de l’analyse des performances, de l’identification des goulots d’étranglement et de l’étude de l’utilisation des ressources. Où trouver ces données Cet attribut est 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 compte le nombre de fois où une demande de service est passée d’un état résolu ou clôturé à un état ouvert ou en cours. Un nombre supérieur à zéro indique que la résolution initiale n’a pas abouti. Cet indicateur mesure directement les reprises et contribue au calcul du taux de résolution dès la première intervention. Un nombre élevé de réouvertures peut révéler une résolution de mauvaise qualité, une demande satisfaite de façon incomplète ou une mauvaise compréhension des besoins de l’utilisateur. Ces situations nuisent à l’efficacité du processus et à la satisfaction des utilisateurs. Pourquoi est-ce important ? Quantifie les reprises et la qualité des résolutions. Un nombre élevé de réouvertures signale des inefficacités, un faible taux de résolution dès la première intervention et une baisse de la satisfaction client. Où trouver ces données Tables ServiceNow Request [sc_request] ou Request Item [sc_req_item], champ 'reopen_count'. Exemples 012
	Ouvert par OpenedBy	Personne ayant soumis la demande de service initialement.
Description Cet attribut identifie l’utilisateur qui a créé la demande de service. Il s’agit souvent de la personne concernée, mais la demande peut aussi être créée par un responsable, un délégué ou un système automatisé. L’analyse des demandes par utilisateur ou par service permet de repérer des tendances, par exemple un groupe d’utilisateurs qui soumet fréquemment des demandes complexes ou problématiques. Ces constats peuvent orienter des formations ciblées ou montrer qu’il serait utile d’améliorer les articles de la base de connaissances pour encourager le libre-service. Pourquoi est-ce important ? Permet d’analyser les demandes par utilisateur, service ou rôle, afin d’orienter les formations et les améliorations ciblées du processus. Où trouver ces données Table ServiceNow Request [sc_request], champ 'opened_by'. Exemples Abel TuterFred LuddyDon Goodliffe
	Reprise IsRework	Indicateur calculé précisant si une activité répète une activité antérieure dans le même dossier.
Description Cet indicateur booléen est calculé pour repérer les boucles de reprise dans une demande de service. Sa valeur est 'true' si la même activité a déjà eu lieu dans le dossier, par exemple si une demande est attribuée deux fois à la même équipe ou si des informations sont demandées plusieurs fois à l’utilisateur. Cet attribut est essentiel au Dashboard sur les transferts entre agents et les reprises, ainsi qu’au calcul du taux de reprise des demandes. Il permet de visualiser et de quantifier directement les boucles inefficaces du processus, souvent invisibles dans les données agrégées. Pourquoi est-ce important ? Repère 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 temps de cycle. Où trouver ces données Calculé lors de la transformation des données, en recherchant les occurrences antérieures du même nom d’activité dans le même dossier. Exemples falsetrue
	Résolu dès la première intervention IsFirstPassResolution	Indicateur précisant si la demande a été résolue dès la première tentative, sans réouverture.
Description Cet attribut calculé est un indicateur booléen dont la valeur est 'true' uniquement si la demande de service a été résolue et clôturée sans jamais être rouverte. Il renseigne sur la qualité et l’efficacité de la résolution fournie par le centre de services. Cet indicateur contribue directement au calcul du taux de résolution dès la première intervention. Un taux élevé est souhaitable : il témoigne d’un service efficace et de qualité, et contribue à la satisfaction client. L’analyse des caractéristiques des dossiers qui ne sont pas résolus dès la première intervention peut révéler des causes profondes, comme une formation insuffisante, une documentation lacunaire ou un diagnostic initial erroné. Pourquoi est-ce important ? Mesure la qualité et l’efficacité du processus de résolution. Un faible taux de résolution dès la première intervention signale des problèmes sous-jacents qui entraînent des reprises et mécontentent les clients. Où trouver ces données 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
	Score de satisfaction SatisfactionScore	Note de satisfaction communiquée par le demandeur à la clôture de la demande.
Description Cet attribut enregistre le score de satisfaction, souvent sur une échelle de 1 à 5, communiqué 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 d’analyse de l’impact sur la satisfaction client. Elles permettent de mettre en relation des indicateurs du processus, comme le temps de cycle, les reprises et les transferts, avec l’expérience client finale. Vous pouvez ainsi étayer l’analyse de rentabilité des améliorations en reliant l’efficacité opérationnelle aux résultats pour les clients. Pourquoi est-ce important ? Relie directement les indicateurs de performance du processus aux résultats pour les clients et aide à mesurer l’effet des inefficacités sur l’expérience utilisateur. Où trouver ces données Généralement dans une table Survey associée [asmt_assessment_instance], liée à la demande d’origine. Exemples 5431
	Temps de cycle du dossier CaseCycleTime	Durée totale entre la création et la clôture définitive d’une demande de service.
Description Le temps de cycle du dossier est un indicateur calculé qui mesure la durée totale d’une demande de service, de l’horodatage du tout premier événement à celui du tout dernier. Il représente le temps de traitement complet, de bout en bout, du point de vue du client. Cet indicateur clé de performance (KPI) sert à évaluer l’efficacité globale du processus. Il figure dans les Dashboards de synthèse pour suivre les résultats par rapport aux objectifs et analyser leur évolution. Vous pouvez également ventiler les résultats selon des dimensions comme la catégorie ou la priorité afin de repérer les demandes qui prennent le plus de temps. Pourquoi est-ce important ? Cet indicateur clé de performance mesure le processus de bout en bout. Il est essentiel au suivi global, à la comparaison des résultats et au repérage des axes d’amélioration. Où trouver ces données Calculé en soustrayant le 'StartTime' minimum du 'EndTime' maximum pour chaque 'ServiceRequestID' unique. Exemples 2 10:30:000 04:15:2210 00:05:00

Obligatoire Recommandé Facultatif

Activités de gestion des demandes de service

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

6 Recommandé 8 Facultatif

	Activité	Description
	Demande affectée à un agent	Cette activité a lieu lorsqu’un agent précis est chargé de traiter la demande de service. Elle est enregistrée en surveillant les changements du champ « Assigned to » de la demande ou de ses tâches de traitement.
Pourquoi est-ce important ? Cette information est essentielle pour mesurer les transferts, calculer la charge de travail de chaque agent et analyser le temps passé en file d’attente avant qu’une personne ne commence à traiter la demande. Où trouver ces données 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. Données à recueillir 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 enregistrée lorsqu’un approbateur marque l’enregistrement d’approbation associé comme « approved ».
Pourquoi est-ce important ? Cette étape importante marque le passage de la phase d’approbation à celle du traitement. L’analyse du temps nécessaire pour l’atteindre est essentielle pour comprendre les retards qui surviennent avant le traitement. Où trouver ces données Cet événement est déduit du passage du champ d’état de l’enregistrement sysapproval_approver associé à « approved », ce qui entraîne ensuite un changement d’état de sc_req_item. Données à recueillir Repérez l’horodatage auquel sysapproval_approver.state passe à « 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 clôture intervient généralement automatiquement après une période définie à l’état « Resolved », pendant laquelle l’utilisateur peut rouvrir la demande.
Pourquoi est-ce important ? Il s’agit de l’événement de fin principal en cas de réussite du processus. Le temps écoulé entre « Resolved » et « Closed » peut également être analysé pour comprendre les règles de clôture automatique. Où trouver ces données Cet événement est déduit du passage du champ d’état de sc_req_item à un état final de clôture, tel que « Closed Complete ». Il est consigné dans la table sys_audit. Données à recueillir Repérez 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 dans le catalogue de services. Le système consigne alors la création d’un nouvel enregistrement dans la table sc_req_item (Requested Item).
Pourquoi est-ce 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 le volume des demandes ainsi que les habitudes de soumission. Où trouver ces données Il s’agit d’un événement explicite, enregistré à partir de l’horodatage de création (champ sys_created_on) de l’enregistrement dans la table sc_req_item. Données à recueillir 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é le travail et apporté une solution. Elle est enregistrée lorsque l’état de la demande passe à « Resolved » ou à un statut similaire.
Pourquoi est-ce important ? Cette étape importante arrête généralement le décompte du SLA. Elle marque la fin du traitement actif et entre dans le calcul du délai total de résolution. Où trouver ces données Cet événement est déduit du passage du champ d’état de sc_req_item à « Resolved » ou à un état final similaire, avant la clôture définitive. Le changement est suivi dans la table sys_audit. Données à recueillir Repérez l’horodatage auquel sc_req_item.state passe à « Resolved ». Type d’événement inferred
	Informations demandées à l’utilisateur	Cette activité a lieu lorsque l’agent chargé du traitement a besoin d’informations supplémentaires de la part de la personne à l’origine de la demande. Elle est généralement déduite du passage de l’état de la demande à une valeur telle que « Awaiting User Info ».
Pourquoi est-ce important ? Cette activité est essentielle au Dashboard « Requestor Information Delay Analysis », qui permet de mesurer le temps perdu dans l’attente d’informations de l’utilisateur. Où trouver ces données Cet événement est déduit du passage du champ d’état de sc_req_item à un statut indiquant que des informations sont attendues. Le changement est consigné dans la table sys_audit. Données à recueillir Repérez l’horodatage auquel sc_req_item.state passe à « Awaiting User Info ». Type d’événement inferred
	Approbation demandée	Indique le moment où une demande de service est soumise à l’approbation d’un responsable ou d’une autre personne désignée. Cet événement est généralement déduit du passage de l’état de la demande à « Pending Approval » ou à un statut similaire.
Pourquoi est-ce important ? Le suivi des approbations permet de repérer les goulots d’étranglement dans le processus d’approbation et de mesurer le temps d’attente avant que l’autorisation ne permette de commencer le traitement de la demande. Où trouver ces données Cet événement est déduit du passage du champ d’état de sc_req_item à 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. Données à recueillir Repérez 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 chargé de son traitement. 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 des tâches associées.
Pourquoi est-ce important ? Le suivi des affectations aux groupes permet d’analyser la répartition de la charge de travail entre les équipes et de repérer les retards avant que la demande ne soit acheminée vers les personnes chargées de son traitement. Où trouver ces données 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. Données à recueillir Suivez les changements du champ assignment_group dans sys_audit. Type d’événement inferred
	Demande annulée	Cette activité marque l’état final des demandes annulées avant leur achèvement, par l’utilisateur ou par un agent. Elle est enregistrée lorsque l’état de la demande passe à « Cancelled » ou à « Closed Cancelled ».
Pourquoi est-ce important ? Il s’agit d’un événement de fin indiquant un échec. L’analyse des raisons d’annulation peut éclairer les besoins des utilisateurs, les inefficacités du processus ou l’évolution des priorités de l’entreprise. Où trouver ces données Cet événement est déduit du passage du champ d’état de sc_req_item à un état final d’annulation, tel que « Closed Cancelled ». Le changement est consigné dans la table sys_audit. Données à recueillir Repérez l’horodatage auquel sc_req_item.state passe à « Cancelled ». Type d’événement inferred
	Demande rejetée	Cette activité correspond au rejet officiel d’une demande pendant la phase d’approbation. Il s’agit d’un autre parcours menant à la clôture. L’événement est enregistré lorsqu’un approbateur marque la demande comme « rejected ».
Pourquoi est-ce important ? Le suivi des rejets permet de repérer les demandes non valides ou mal orientées, les problèmes liés à leur soumission et les parcours d’exception à prendre en compte dans l’analyse. Où trouver ces données Cet événement est déduit du passage du champ d’état de l’enregistrement sysapproval_approver associé à « rejected ». Cela entraîne généralement le passage de l’enregistrement parent sc_req_item à un état fermé et incomplet. Données à recueillir Repérez l’horodatage auquel sysapproval_approver.state passe à « rejected ». Type d’événement inferred
	Demande rouverte	Cette activité recense les cas où une demande précédemment marquée comme résolue repasse à un état ouvert. Elle est déduite du passage de l’état « Resolved » à « Work in Progress » ou à un statut similaire.
Pourquoi est-ce important ? Il s’agit d’une mesure directe des reprises, essentielle au calcul de l’indicateur « First-Pass Resolution Rate ». Un nombre élevé peut signaler une solution de mauvaise qualité ou une résolution incomplète. Où trouver ces données 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. Ce changement est consigné dans sys_audit. Données à recueillir Repérez dans sys_audit le passage de l’état « Resolved » à « Work in Progress ». Type d’événement inferred
	Informations fournies par l’utilisateur	Cette activité marque le moment où la personne à l’origine de la demande a fourni les informations nécessaires. Elle est déduite du passage de la demande d’un état « Awaiting User Info » à un état actif tel que « Work in Progress ».
Pourquoi est-ce important ? Associée à l’activité « Informations demandées à l’utilisateur », cette activité permet de mesurer précisément les retards liés à l’attente de l’utilisateur et d’évaluer l’efficacité des échanges. Où trouver ces données Cet événement est déduit du passage du champ d’état de sc_req_item d’un statut indiquant que des informations sont attendues à un statut actif. Il est souvent déclenché lorsque l’utilisateur ajoute un commentaire ou répond à un e-mail. Données à recueillir Repérez l’horodatage auquel l’état passe de « Awaiting User Info » à « Work in Progress ». Type d’événement inferred
	Prestataire externe sollicité	Indique le transfert d’une demande de service ou de l’une de ses tâches à un prestataire externe chargé du traitement. Cet événement peut être déduit de l’affectation à un groupe associé à un prestataire ou d’un indicateur présent sur la demande.
Pourquoi est-ce important ? Cette activité permet d’analyser les performances du prestataire et leur incidence sur le cycle de vie global de la demande. Elle est essentielle au Dashboard « External Vendor Engagement Cycle ». Où trouver ces données Cet événement est généralement déduit. Il peut être associé à l’affectation du champ assignment_group au groupe d’un prestataire ou à l’activation d’un indicateur précis dans l’enregistrement sc_req_item ou sc_task. Données à recueillir Repérez le changement du champ assignment_group vers un groupe de prestataire connu. Type d’événement inferred
	Tâche de traitement créée	Indique la création d’un élément de travail ou d’une tâche 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 est-ce important ? Pour les demandes complexes, l’analyse de la création et de l’achèvement de chaque tâche donne une vue plus détaillée du processus de traitement et des endroits où des retards surviennent. Où trouver ces données Il s’agit d’un événement explicite, enregistré à partir de l’horodatage de création (champ sys_created_on) d’un enregistrement de la table sc_task lié à sc_req_item. Données à recueillir Utilisez l’horodatage sys_created_on des enregistrements sc_task. Type d’événement explicit

Recommandé Facultatif

Guides d’extraction

Comment extraire vos données de ServiceNow

Étapes

Comprendre l’approche multi-export : En raison de la structure des données de ServiceNow, un seul export ne permet pas de récupérer tous les événements nécessaires. Vous devez effectuer plusieurs exports à partir de tables différentes, puis regrouper les données à l’extérieur 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 correspondant à la période souhaitée, par exemple [Created] [on] [Last 6 months]. Ajoutez des colonnes telles que Nombre, Sys Created On, Resolved, Closed, State, Assignment group, Assigned to, Priority et Made SLA. Faites un clic droit sur l’en-tête d’une 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] AND [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 pour 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 avec [Table name] [is] [sc_req_item] AND [Created] [on] [Last 6 months] AND [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 des autorisations élevées peuvent être nécessaires pour accéder à cette table.
Regrouper et transformer les données : Utilisez un outil comme Microsoft Excel, Python avec pandas ou un outil dédié à la 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 relier 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 ligne pour chaque activité distincte. Par exemple :
- Pour Service Request Created, utilisez la valeur Sys Created On de l’export sc_req_item.
- Pour Request Approved, utilisez la valeur Sys Updated On de l’export sysapproval_approver lorsque State passe à « approved ».
- Pour Request Assigned to Group, repérez dans l’export sys_audit la ligne où Field name est assignment_group, puis utilisez la valeur 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 correspondre à l’état de la demande au moment de l’événement.
Ajouter les colonnes de métadonnées : Ajoutez SourceSystem avec une valeur fixe telle que « ServiceNow » et LastDataUpdate avec l’horodatage de l’extraction.
Finaliser et exporter : Enregistrez les données 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 à utiliser : 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 : contient 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 l’historique détaillé des modifications de champs, indispensable pour suivre les affectations et les changements d’état.
Filtrage par période : Appliquez le même filtre de période à tous les exports, par exemple Created on Last 6 months, afin de préserver l’intégrité des données. Une période de 3 à 6 mois est recommandée pour obtenir un bon équilibre entre volume et informations utiles.
Filtres essentiels : 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 indispensables : Veillez à exporter les identifiants clés, comme Nombre et Sys ID (document key dans la table d’audit), pour relier les jeux de données. Les horodatages Sys Created On, Sys Updated On, Résolu et Fermé sont essentiels à la création du journal d’événements.
Prérequis : Pour accéder à la plupart des tables nécessaires, vous devez disposer d’un compte ServiceNow doté au minimum du rôle itil. 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.

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 fichier. Saisissez l’URL de votre instance ServiceNow (par exemple, https://your-instance.service-now.com), ainsi que le nom d’utilisateur et le mot de passe d’un compte de service disposant des autorisations de lecture requises sur les tables concernées.
Définir la période d’extraction : Modifiez les variables start_date et end_date pour définir les dates de début et de fin de l’extraction. 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 les noms de tables ServiceNow standard, tels que sc_req_item, sys_audit et sc_task. Vérifiez qu’ils correspondent à la configuration de votre instance. Si celle-ci utilise des tables ou des champs personnalisés, adaptez le script en conséquence.
Exécuter le script Python : Lancez le script depuis la ligne de commande ou le terminal avec la commande python your_script_name.py. Il se connectera à l’API ServiceNow, récupérera les données correspondant à chaque activité indiquée et affichera l’avancement dans la console.
Gérer la pagination de l’API : Le script comprend une fonction qui gère automatiquement la pagination. Si le nombre d’enregistrements dépasse la limite par page (sysparm_limit), il effectuera plusieurs appels à l’API 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 unique.
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 répertoire depuis lequel le script a été lancé.
Préparer l’importation : Ouvrez le fichier CSV généré dans un tableur pour vérifier que les données sont complètes et exactes. Avant l’importation, vérifiez que les en-têtes de colonnes correspondent au schéma ProcessMind requis.

Configuration

URL de l’instance ServiceNow : URL de base de votre instance ServiceNow (par exemple, https://your-instance.service-now.com).
Authentification : Vous devez disposer du nom d’utilisateur et du mot de passe d’un compte de service ayant un accès en lecture aux tables sc_req_item, sys_audit, sysapproval_approver et sc_task.
Période : Définissez les variables start_date et end_date du script pour délimiter la période d’extraction. Une période de 3 à 6 mois est recommandée pour une première analyse.
Limite de résultats (sysparm_limit) : Le script limite le nombre d’enregistrements renvoyés par appel à l’API. La valeur par défaut est de 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 pour sélectionner un élément de catalogue ou un groupe d’affectation précis, afin de réduire le volume de données (par exemple, active=true^category=hardware).
Valeurs affichées : Le paramètre sysparm_display_value=true permet de récupérer les noms lisibles des champs de référence au lieu de leurs valeurs internes sys_id. Il est essentiel pour des attributs tels que AssignmentGroup et AssignedTo.

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 un utilisateur API ServiceNow : Créez un utilisateur dédié à cette intégration dans votre instance ServiceNow. 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 les bibliothèques axios, pour effectuer des requêtes HTTP, et 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 de remplacement 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 du script pour définir la période d’extraction. Vous pouvez également ajouter des filtres aux chaînes sysparm_query de chaque activité pour réduire le périmètre, par exemple en sélectionnant 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 de création sont interrogés directement dans leurs tables sources (sc_req_item, sc_task), tandis que les changements d’état et les affectations sont récupérés dans la table sys_audit à partir des mises à jour de champs correspondantes.
Exécuter le script : Lancez le script depuis votre terminal avec la commande node extract.js. Il se connectera à l’API Table de ServiceNow, récupérera les données de chaque activité et gérera automatiquement la pagination.
Traiter les données : À mesure qu’elles sont récupérées, le script transforme les réponses JSON de ServiceNow en un format standard de journal d’événements et associe les champs aux colonnes ServiceRequestID, ActivityName et EventTime.
Regrouper et consolider les résultats : Le script rassemble les résultats de tous les appels API dans un tableau unique représentant l’ensemble du journal d’événements.
Générer le fichier de sortie : Une fois 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, dans le même répertoire.
Préparer l’importation : Le fichier CSV généré comporte les colonnes requises pour le Process Mining. Aucune autre mise en forme n’est nécessaire avant son importation dans la plateforme ProcessMind.

Configuration

URL de l’instance ServiceNow : URL de base de votre environnement ServiceNow, par exemple https://your-instance.service-now.com.
Identifiants API : Nom d’utilisateur et mot de passe valides pour un utilisateur ServiceNow disposant des autorisations de lecture et des rôles requis (rest_service, itil).
Période : Nous recommandons d’extraire les données sur une période de 3 à 6 mois afin d’obtenir un jeu de données représentatif. Définissez cette période dans le script à l’aide des variables startDate et endDate, qui sont appliquées aux champs d’horodatage concernés dans les requêtes API.
sysparm_query : Ce paramètre d’URL sert principalement à filtrer les enregistrements. Le script l’utilise largement pour isoler des événements précis, par exemple les enregistrements créés pendant une période donnée ou les enregistrements d’audit indiquant un changement d’état de « Resolved » à « Work in Progress ».
sysparm_fields : Ce paramètre indique les colonnes à renvoyer lors d’un appel API. Son utilisation améliore nettement 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 récupère les enregistrements par lots de 1 000. Vous pouvez modifier cette valeur, mais il est recommandé de ne pas dépasser la limite maximale de ServiceNow, généralement de 10 000, afin de préserver la stabilité.

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 améliorer l’efficacité de la gestion des demandes de service. Commencez dès aujourd’hui à optimiser vos flux de travail pour résoudre les demandes plus rapidement et améliorer la satisfaction client.

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

Rapports ServiceNow et export des listes au format CSV/XLSX

Étapes

Configuration

Exemple de requête config

Script Python utilisant Requests pour extraire les données via l’API Table

Étapes

Configuration

Exemple de requête python

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

Étapes

Configuration

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

Rapports ServiceNow et export des listes au format CSV/XLSX

Étapes

Configuration

Exemple de requête config

Script Python utilisant Requests pour extraire les données via l’API Table

Étapes

Configuration

Exemple de requête python

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

Étapes

Configuration

Exemple de requête javascript

Prêt à commencer ?

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

Prêt à commencer ?

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