> Amélioration Continue des Processusus > Gestion des demandes de service > ServiceNow > Template de données

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

ServiceNow

Attributs de 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 projet de process mining pour la Gestion des demandes de service. Il fournit des conseils clairs sur les attributs essentiels à collecter, les activités critiques à suivre et des directives d'extraction pratiques spécifiques à ServiceNow. L'utilisation de ce template vous garantira de capturer toutes les données nécessaires pour une analyse précise et une optimisation efficace.

Attributs recommandés à collecter
Activités clés à suivre pour la découverte de processus
Guide d'extraction des données étape par étape

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

Télécharger le modèle

Attributs de gestion des demandes de service

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

5 Obligatoire 6 Recommandé 10 Facultatif

	Nom	Descriptionn
	Activité ActivityName	Le nom de l'événement ou de la tâche spécifique survenue au cours du cycle de vie de la demande de service.
Descriptionn L'attribut Activité enregistre le nom de chaque étape ou changement de statut dans le processus de demande de service. Cela peut inclure des événements comme 'Demande créée', 'Demande approuvée', 'Attribuée à l'agent' ou 'Demande clôturée'. L'analyse de ces activités facilite la visualisation du flux de processus, l'identification des chemins courants et la détection des écarts par rapport à la procédure standard. C'est le fondement pour comprendre ce qui se passe réellement pendant le processus de réalisation de la demande. Pourquoi est-ce important ? : C'est un attribut obligatoire qui définit les étapes de la carte de processus. Il est indispensable pour toutes les analyses de processus, y compris la découverte des points de blocage, des boucles de retravail et des problèmes de conformité. Source des données : Dérivé des changements dans les champs 'État' ou 'Étape' des tables comme 'sc_request' ou 'sc_req_item', ou du journal 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	L'horodatage indiquant le début d'une activité ou d'un événement.
Descriptionn Cet attribut enregistre la date et l'heure exactes auxquelles chaque activité au sein du processus de demande de service s'est produite. Il fournit la séquence chronologique des événements nécessaire à la construction de la carte de processus et à toute analyse basée sur le temps. Des horodatages précis sont essentiels à calculer les temps de cycle, les temps d'attente et les durées de traitement. Ces données permettent l'identification des points de blocage, des violations de SLA et des tendances de performance au fil du temps. Pourquoi est-ce important ? : C'est un horodatage obligatoire pour ordonner correctement les événements. Il est la base de toutes les analyses de performance et de durée, y compris le temps de cycle et l'identification des points de blocage. Source des données : Généralement disponible dans les champs 'sys_updated_on' ou 'sys_created_on' des tables ServiceNow pertinentes (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
	ID de demande de service ServiceRequestID	L'identifiant unique pour chaque enregistrement de demande de service.
Descriptionn L'ID 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 sert de élément central reliant tous les événements ultérieurs, de l'enregistrement initial à la clôture finale. En process mining, cet ID est indispensable pour reconstituer le parcours complet de chaque demande, pour une analyse complète de son cycle de vie. Pourquoi est-ce important ? : C'est l'ID de cas obligatoire. Il connecte toutes les activités liées en une seule instance de processus, permettant l'analyse des flux de processus, des variations et des temps de cycle. Source des données : Table ServiceNow Request [sc_request], champ 'number'. Exemples REQ0010001REQ0010025REQ0010112
	Dernière mise à jour des données LastDataUpdate	L'horodatage de la plus récente actualisation ou extraction des données.
Descriptionn Cet attribut indique la date et l'heure de la dernière extraction des données du système source et de leur chargement dans l'outil de process mining. Il offre une transparence sur la la réactualisation des données analysées. Les analystes utilisent cette information pour comprendre s'ils examinent les données les plus récentes, ce qui est impératif pour le suivi opérationnel et la prise de décision en temps réel. Cela aide à définir les attentes concernant la récence des insights. Pourquoi est-ce important ? : Garantit que les utilisateurs sont conscients de la la réactualisation des données, ce qui est impératif pour faire confiance à l'analyse et prendre des décisions opportunes et basées sur les données. Source des données : C'est un champ de métadonnées ajouté pendant le processus d'ingestion des données, reflétant l'horodatage de l'achèvement du job ETL. Exemples 2023-10-27T04:00:00Z
	Système source SourceSystem	Le système d'où proviennent les données.
Descriptionn Cet attribut identifie le système source des données, qui dans ce cas est ServiceNow. Il est utile dans les environnements où les données de plusieurs systèmes sont fusionnées pour une vue d'ensemble complète du processus. Pour une analyse à source unique, cet attribut fournit un contexte important et aide à la gouvernance et à la gestion des données. Il garantit que tout utilisateur comprend l'origine des données qu'il analyse. Pourquoi est-ce important ? : Fournit des métadonnées essentielles pour la gouvernance des données, la traçabilité et le contexte, en particulier lors de la combinaison de données provenant de plusieurs systèmes d'entreprise. Source des données : Il s'agit généralement d'une valeur statique ajoutée pendant le processus d'extraction et de transformation des données. Exemples ServiceNow
	Attribué à AssignedTo	L'utilisateur individuel responsable du traitement de la demande de service à un moment donné.
Descriptionn Cet attribut identifie l'agent ou le technicien spécifique assigné à la demande de service. Il change au fur et à mesure que la demande est transférée entre différentes personnes. L'analyse du champ 'Assigned To' est indispensablele pour comprendre la répartition de la charge de travail, la performance individuelle et l'impact des passations sur les temps de résolution. Elle aide à répondre aux questions sur l'utilisation des ressources et identifie les opportunités de formation ou de clarification des processus pour réduire les réaffectations. Pourquoi est-ce important ? : Permet l'analyse de la charge de travail des agents, des performances et des transferts. Il est indispensable pour la gestion des ressources et l'identification des points de blocage liés à des individus spécifiques. Source des 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	La classification principale de la demande de service, telle que Matériel ou Logiciel.
Descriptionn La catégorie fournit une classification de haut niveau de la demande de service. Elle est généralement utilisée pour acheminer la demande vers la bonne équipe et pour rendre compte des types de demandes soumises. Dans le Process Mining, la Catégorie est un outil puissant pour le filtrage et l'analyse basée sur les dimensions. Elle permet aux analystes de comparer les flux de processus, les temps de cycle et les taux d'automatisation pour différents types de demandes, révélant des variations qui pourraient ne pas être visibles au niveau agrégé. Par exemple, le processus pour une demande de 'Matériel' peut être cléement différent de celui d'une demande de 'Logiciel'. Pourquoi est-ce important ? : Permet une segmentation et une comparaison puissantes des processus entre différents types de services, aidant à identifier les problèmes spécifiques à une catégorie et les opportunités d'amélioration. Source des données : Table ServiceNow Request Item [sc_req_item], généralement via la catégorie de l'élément de catalogue [sc_cat_item] associé. Exemples HardwareLogicielDemande d'accèsRéseau
	État State	Le statut opérationnel actuel de la demande de service.
Descriptionn L'attribut État indique l'étape actuelle de la demande de service dans son cycle de vie, comme 'Ouvert', 'En cours', 'En attente' ou 'Fermé'. Les changements dans ce champ sont souvent utilisés pour générer les activités de la carte de processus. L'analyse de l'État est indispensablele pour comprendre combien de temps les demandes passent dans des statuts spécifiques, en particulier les états d'attente ou en suspens. Elle aide à identifier les files d'attente et les retards, tels que le temps passé 'En attente d'informations de l'utilisateur', qui est une source courante de temps de cycle prolongés. Pourquoi est-ce important ? : Fournit des informations sur le statut de la demande à tout moment, permettant l'analyse des temps d'attente, des files d'attente et de la durée des étapes spécifiques du processus. Source des données : Tables ServiceNow Request [sc_request] ou Request Item [sc_req_item], champ 'state' ou 'stage'. Exemples OuvertTravail en CoursEn attente d'informations utilisateurClôturé complet
	Groupe d'assignation AssignmentGroup	L'équipe ou le groupe responsable du traitement de la demande de service.
Descriptionn Le Groupe d'assignation représente l'équipe, telle que 'Centre de services', 'Opérations Réseau' ou 'Administration de Base de Données', qui est responsable d'une demande de service à une étape particulière. C'est un attribut clé pour analyser le flux de processus entre différentes zones fonctionnelles. En suivant les changements dans le Groupe d'assignation, les organisations peuvent visualiser les passations entre équipes, mesurer les temps d'attente dans le backlog de chaque groupe et identifier les dépendances ou retards inter-équipes. Ceci est impératif pour optimiser la collaboration interfonctionnelle. Pourquoi est-ce important ? : Suit la distribution du travail entre les équipes, met en évidence les passations inter-équipes et aide à identifier les points de blocage ou les problèmes de performance spécifiques à l'équipe. Source des données : Tables ServiceNow Request Item [sc_req_item] ou Catalog Task [sc_task], champ 'assignment_group'. Exemples Centre de servicesSupport IT N2Provisionnement matériel
	Priorité Priority	Le niveau de priorité de la demande de service, qui influence son urgence.
Descriptionn La priorité est une classification qui détermine l'importance relative et l'urgence d'une demande de service. Elle est souvent déterminée par une combinaison d'impact et d'urgence et est utilisée pour guider les agents sur les demandes à traiter en premier. L'analyse des données par priorité est indispensablele pour comprendre si les demandes à haute priorité sont traitées plus rapidement que celles à basse priorité. Elle permet de filtrer les dashboards pour vérifier si les SLA sont respectés pour les demandes critiques et aide à identifier si le système de priorisation est efficace. Pourquoi est-ce important ? : Permet la segmentation des demandes pour vérifier que les éléments à haute priorité sont traités plus rapidement. C'est indispensable pour l'analyse des SLA et l'allocation des ressources. Source des 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	Un indicateur booléen signalant si la demande de service a été résolue dans le respect de son accord de niveau de service (SLA).
Descriptionn Cet attribut indique si la demande de service a respecté son accord de niveau de service (SLA) défini pour le temps de résolution. C'est une métrique de résultat critique qui mesure directement la performance du service par rapport aux engagements. L'analyse de ce flag aide à quantifier le KPI du Taux de Conformité aux SLA. Il peut être utilisé comme dimension pour comparer les chemins de processus des demandes conformes aux demandes non conformes, révélant des schémas ou activités courants qui contribuent aux échecs SLA. Ceci est indispensable pour la surveillance proactive des risques et l'amélioration continue du service. Pourquoi est-ce important ? : Mesure directement la performance par rapport aux engagements de service et permet une analyse des causes profondes des violations de SLA en comparant les cas conformes et non conformes. Source des données : Table ServiceNow Task SLA [task_sla], champ 'has_breached'. La valeur doit être inversée (par exemple, MadeSLA = NOT has_breached). Exemples truefaux
	Canal ContactType	La méthode utilisée par le demandeur pour soumettre la demande de service.
Descriptionn Le Type de contact, ou canal, spécifie comment la demande de service a été initiée. Les canaux courants incluent le portail de service, l'e-mail, l'appel téléphonique ou l'alerte automatisée. Comprendre le canal est important pour analyser les variations de processus qui peuvent être influencées par la méthode de soumission. Par exemple, les demandes soumises via le portail peuvent être plus structurées et automatisées, conduisant à des temps de traitement plus rapides par rapport à celles soumises par e-mail. Cette analyse aide à promouvoir des canaux plus efficaces. Pourquoi est-ce important ? : Aide à identifier l'impact des différents canaux de soumission sur l'efficacité des processus, les niveaux d'automatisation et les temps de cycle globaux, orientant les efforts d'optimisation des interactions utilisateur. Source des données : Tables ServiceNow Request [sc_request] ou Interaction [interaction]. Le champ est souvent nommé 'contact_type'. Exemples PortailE-mailTéléphoneSelf-service
	Code de Résolution ResolutionCode	Un code qui catégorise la résolution finale de la demande de service.
Descriptionn Le Code de résolution est une classification structurée de la manière dont une demande de service a été finalement résolue. Les exemples incluent 'Réalisé par l'automatisation', 'Erreur de l'utilisateur' ou 'N'est plus requis'. Cet attribut est indispensable à le tableau de bord d'analyse des causes profondes des retards. En corrélant les codes de résolution avec des temps de cycle longs ou des taux de retouches élevés, les analystes peuvent identifier les problèmes systémiques. Par exemple, si les demandes avec le code 'Informations incomplètes' sont systématiquement lentes, cela indique un problème dans l'étape initiale de collecte des données. Pourquoi est-ce important ? : Fournit des données structurées sur les résultats de résolution, permettant l'analyse des causes profondes des retards de processus, des retouches et d'autres inefficacités. Source des données : Table ServiceNow Request Item [sc_req_item] ou une table de tâches associée, le champ est couramment 'close_code' ou 'resolution_code'. Exemples Résolu (définitivement)Non Résolu (Non Reproductible)Demande satisfaiteAnnulé par l'utilisateur
	Délai de traitement global CaseCycleTime	Le temps total écoulé entre la création et la clôture finale d'une demande de service.
Descriptionn Le temps de cycle du dossier est une métrique calculée qui mesure la durée totale d'une demande de service, de l'horodatage du tout premier événement à l'horodatage du tout dernier événement. Il représente le temps de traitement complet complet du point de vue du client. Il s'agit d'un indicateur clé de performance (KPI) principal pour l'efficacité globale du processus. Il est utilisé dans les dashboards de haut niveau pour surveiller les performances par rapport aux objectifs et pour analyser les tendances au fil du temps. Il peut être segmenté par des dimensions comme la Catégorie ou la Priorité pour identifier quels types de demandes prennent le plus de temps. Pourquoi est-ce important ? : C'est un KPI clé qui mesure la performance du processus complet. Il est indispensable pour le suivi de haut niveau, le benchmarking et l'identification des domaines d'amélioration. Source des données : Calculé en soustrayant le 'Heure de début' minimale du 'Heure de fin' maximale pour chaque `ID_Demande_Service` unique. Exemples 2 10:30:000 04:15:2210 00:05:00
	Est Automatisé IsAutomated	Un indicateur qui signale si une activité a été réalisée par un système ou une automatisation.
Descriptionn Cet attribut booléen distingue les activités effectuées manuellement par un agent humain de celles exécutées par un système automatisé, tel qu'un workflow ou une intégration. Par exemple, une 'Approbation demandée' peut être automatisée, tandis qu'une 'Demande assignée à l'agent' peut être manuelle. L'analyse de cet attribut est indispensablele pour mesurer et augmenter le niveau d'automatisation dans le processus de demande de service. Elle aide à identifier les tâches manuelles les plus chronophages et qui pourraient être candidates à une future automatisation, améliorant ainsi l'efficacité et réduisant les coûts. Pourquoi est-ce important ? : Permet la mesure des taux d'automatisation et aide à identifier les opportunités d'automatisation des tâches manuelles, conduisant à une efficacité accrue et à une réduction des coûts opérationnels. Source des données : Dérivé en vérifiant si l'utilisateur qui a effectué une action (par exemple, 'sys_updated_by') est un utilisateur système ou d'intégration désigné. Exemples truefaux
	Est un reprises IsRework	Un indicateur calculé signalant si une activité est une répétition d'une activité précédente dans le même dossier.
Descriptionn Cet indicateur booléen est calculé pour identifier les boucles de retravail au sein d'une demande de service. Il est marqué comme 'vrai' si la même activité s'est déjà produite plus tôt dans le même cas, par exemple, si une demande est attribuée deux fois à la même équipe, ou si des informations sont demandées à l'utilisateur plusieurs fois. Cet attribut est indispensable pour le tableau de bord des Passations d'agents et des Incidents de retouches et le KPI du Taux de re-traitements des demandes. Il facilite la visualisation et la quantification directes des boucles inefficaces dans le processus, qui sont souvent cachées dans les données agrégées. Pourquoi est-ce important ? : Signale et quantifie directement les reprises de processus, permettant d'analyser les causes et les impacts des boucles inefficaces qui augmentent les coûts et les temps de cycle. Source des données : Calculé lors de la transformation des données en vérifiant les occurrences précédentes du même nom d'activité dans le même dossier. Exemples fauxtrue
	Est une résolution au premier contact IsFirstPassResolution	Un indicateur signalant si la demande a été résolue dès la première tentative, sans aucune réouverture.
Descriptionn Cet attribut calculé est un indicateur booléen qui est 'vrai' uniquement si la demande de service a été résolue et clôturée sans jamais être rouverte. C'est un indicateur clé de la qualité et de l'efficacité de la résolution fournie par le service d'assistance. Cette métrique contribue directement au le KPI du Taux de résolution au premier contact. Un taux élevé est souhaitable car il indique l'efficacité et un service de haute qualité, conduisant à une meilleure satisfaction client. L'analyse des attributs des cas qui échouent à la résolution au premier contact peut révéler des causes profondes comme une formation insuffisante, une mauvaise documentation ou un diagnostic initial incorrect. Pourquoi est-ce important ? : Mesure la qualité et l'efficacité du processus de résolution. Un faible taux de résolution au premier contact indique des problèmes sous-jacents qui entraînent des retouches et la frustration des clients. Source des données : Calculé au niveau du dossier. Un dossier est considéré comme une résolution au premier passage si son 'Compteur de réouvertures' est à zéro. Exemples truefaux
	Heure de fin EndTime	Le 'horodatage' indiquant quand une activité ou un 'event' a été terminé.
Descriptionn L'Heure de fin marque la conclusion d'une activité. C'est l'horodatage de l'activité suivante dans la séquence, clôturant ainsi la durée de l'actuelle. Cet attribut est indispensable pour calculer le temps que prend 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 les temps d'attente. Ceci est indispensable pour identifier les points de blocage, mesurer l'efficacité des ressources et surveiller les performances par rapport aux objectifs basés sur le temps. Pourquoi est-ce important ? : Cet attribut est nécessaire pour calculer la durée de chaque activité, qui est un composant essentiel de l'analyse des performances, de l'identification des points de blocage et des études d'utilisation des ressources. Source des données : C'est un attribut dérivé, calculé en prenant le '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	Le nombre de fois qu'une demande de service a été rouverte après avoir été résolue.
Descriptionn Cet attribut est un compteur qui suit le nombre de fois qu'une demande de service est passée d'un état résolu ou fermé à un état ouvert ou en cours. Un nombre supérieur à zéro indique que la résolution initiale n'a pas été couronnée de succès. Cette métrique est un indicateur direct de retouches et est un composant clé du KPI du Taux de résolution au premier contact. Des nombres élevés de réouvertures suggèrent des problèmes de qualité de résolution, une réalisation incomplète ou une incompréhension des besoins de l'utilisateur, ce qui entraîne une inefficacité des processus et une insatisfaction de l'utilisateur. Pourquoi est-ce important ? : Quantifie les retouches et la qualité de la résolution. Un nombre élevé de réouvertures indique des inefficacités, de faibles taux de résolution au premier contact et une diminution de la satisfaction client. Source des données : Tables ServiceNow Request [sc_request] ou Request Item [sc_req_item], champ 'reopen_count'. Exemples 012
	Ouvert par OpenedBy	L'individu qui a initialement soumis la demande de service.
Descriptionn Cet attribut identifie l'utilisateur qui a créé la demande de service. Bien que souvent la même personne que celle affectée par la demande, il peut aussi s'agir d'un gestionnaire, d'un délégué ou d'un système automatisé. L'analyse des demandes par l'utilisateur 'Ouvert par' ou leur département aide à identifier des schémas, comme un groupe spécifique d'utilisateurs qui soumettent fréquemment des demandes complexes ou problématiques. Cela peut éclairer des formations ciblées ou souligner le besoin de meilleurs articles de base de connaissances pour encourager le self-service. Pourquoi est-ce important ? : Aide à analyser les modèles de demandes par utilisateur, département ou rôle, ce qui peut éclairer les initiatives de formation et les améliorations de processus ciblées. Source des données : Table ServiceNow Request [sc_request], champ 'opened_by'. Exemples Abel TuterFred LuddyDon Goodliffe
	Score de satisfaction SatisfactionScore	Le score de satisfaction client fourni par le demandeur lors de la clôture.
Descriptionn Cet attribut capture le score de satisfaction, souvent sur une échelle de 1 à 5, soumis par l'utilisateur final après la résolution de sa demande de service. C'est une mesure directe de la qualité perçue du service. Ces données sont indispensables pour le tableau de bord d'analyse d'impact sur la satisfaction client. Elles permettent une corrélation directe entre les métriques de processus, comme le temps de cycle, les retouches et les passations, et l'expérience client finale. Cela aide à prouver la justification commerciale des améliorations de processus en liant l'efficacité opérationnelle aux résultats client. Pourquoi est-ce important ? : Relie directement les métriques de performance des processus aux résultats pour les clients, aidant à quantifier l'impact des inefficacités des processus sur l'expérience utilisateur. Source des données : Généralement disponible dans une table Survey [asmt_assessment_instance] liée, qui est elle-même liée à la demande originale. Exemples 5431

Obligatoire Recommandé Facultatif

Activités de gestion des demandes de service

Ce sont les étapes clés du processus et les jalons à enregistrer dans votre journal d'événements pour une découverte précise des processus et l'identification des points de blocage.

6 Recommandé 8 Facultatif

	Activité	Descriptionn
	Demande approuvée	Cette activité signifie que la demande a été officiellement approuvée et peut passer à l'étape de réalisation. Elle est capturée lorsqu'un approbateur marque l'enregistrement d'approbation associé comme 'approuvé'.
Pourquoi est-ce important ? : Cette étape clé marque la transition de la phase d'approbation à la phase de réalisation. L'analyse du temps nécessaire pour atteindre cette étape est indispensablele pour comprendre les retards avant la réalisation. Source des données : Inférent du champ d'état de l'enregistrement sysapproval_approver lié passant à 'approved', ce qui déclenche ensuite un changement d'état sur le sc_req_item. Capture Identifier l'horodatage lorsque sysapproval_approver.state passe à 'approved'. Type d'événement inferred
	Demande assignée à l'agent	Cette activité se produit lorsqu'un agent individuel spécifique est assigné pour travailler sur la demande de service. Elle est capturée en surveillant les changements apportés au champ 'Assigned to' de la demande ou de ses tâches de réalisation.
Pourquoi est-ce important ? : Ceci est impératif pour mesurer les passations, calculer les charges de travail spécifiques aux agents et analyser les temps d'attente avant qu'un individu ne commence à travailler sur une demande. Source des données : Inférent d'un changement dans le champ assigned_to de la table sc_req_item ou sc_task. L'historique des changements est enregistré dans la table sys_audit. Capture Suivre les modifications du champ assigned_to dans sys_audit. Type d'événement inferred
	Demande de service créée	Cette activité marque le début du cycle de vie de la demande de service, enregistrée lorsqu'un utilisateur soumet une demande via le catalogue de services. Le système capture ceci comme l'événement de création d'un nouvel enregistrement dans la table sc_req_item (Élément demandé).
Pourquoi est-ce important ? : C'est 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 et les modèles de soumission. Source des données : C'est un événement explicite capturé à partir du horodatage de création (champ sys_created_on) de l'enregistrement dans la table sc_req_item. Capture Utilisez l'horodatage `sys_created_on` de l'enregistrement `sc_req_item`. Type d'événement explicit
	Demande de service fermée	Marque la fin finale et définitive du cycle de vie de la demande de service. Cela se produit généralement automatiquement après une période définie dans l'état 'Resolved', pendant laquelle l'utilisateur peut rouvrir la demande.
Pourquoi est-ce important ? : Ceci est l'événement de fin principal réussi pour le processus. Le temps entre 'Resolved' et 'Closed' peut également être analysé pour comprendre les politiques de clôture automatique. Source des données : Inférent de la mise à jour du champ d'état sc_req_item vers un état final fermé, tel que 'Closed Complete'. Ceci est enregistré dans la table sys_audit. Capture Identifier l'horodatage lorsque `sc_req_item.state` passe à 'Fermé Complet'. Type d'événement inferred
	Demande de service résolue	Cette activité indique que l'agent de réalisation a terminé le travail et fourni une solution. Elle est enregistrée lorsque l'état de la demande est mis à jour vers 'Resolved' ou un statut similaire.
Pourquoi est-ce important ? : C'est une étape clé qui arrête généralement le chronomètre du SLA. Elle marque la fin du travail de réalisation actif et est un composant clé du calcul du temps de résolution total. Source des données : Inférent de la mise à jour du champ d'état sc_req_item vers 'Resolved' ou un état terminal similaire avant la clôture finale. Le changement est suivi dans la table sys_audit. Capture Identifier l'horodatage lorsque `sc_req_item.state` passe à 'Résolu'. Type d'événement inferred
	Informations demandées à l'utilisateur	Se produit lorsque l'agent de réalisation a besoin de plus d'informations de la part du demandeur initial pour progresser. Ceci est généralement inféré lorsque l'état de la demande est modifié pour une valeur comme 'Awaiting User Info'.
Pourquoi est-ce important ? : Cette activité est indispensablele pour le tableau de bord 'Analyse des retards d'information du demandeur', aidant à quantifier le temps perdu en attente d'une saisie externe de l'utilisateur. Source des données : Inférent du champ d'état sc_req_item passant à un statut désigné 'en attente d'informations'. Le changement est enregistré dans la table sys_audit. Capture Identifier l'horodatage lorsque `sc_req_item.state` passe à 'En attente d'informations utilisateur'. Type d'événement inferred
	Approbation demandée	Représente le point où une demande de service est soumise à l'approbation d'un gestionnaire ou d'un autre approbateur désigné. Ceci est généralement inféré lorsque l'état de la demande passe à 'En attente d'approbation' ou un statut similaire.
Pourquoi est-ce important ? : Le suivi des approbations aide à identifier les points de blocage dans le processus d'approbation et mesure le temps d'attente des demandes d'autorisation avant que la réalisation ne puisse commencer. Source des données : Inférent du champ d'état sc_req_item passant à une valeur d'approbation en attente, ou par la création d'un enregistrement correspondant dans la table sysapproval_approver. Les changements sont enregistrés dans la table sys_audit. Capture Identifier l'horodatage lorsque `sc_req_item.state` passe à 'En attente d'approbation'. Type d'événement inferred
	Demande affectée à un groupe	Indique que la demande de service a été attribuée à une équipe ou un groupe de réalisation spécifique. Cet événement est inféré en détectant un changement dans le champ du groupe d'assignation sur l'élément de demande ou ses tâches associées.
Pourquoi est-ce important ? : Le suivi des attributions de groupe aide à analyser la répartition de la charge de travail entre les équipes et à identifier les retards avant qu'une demande ne soit acheminée vers les bons exécutants. Source des données : Inférent d'un changement dans le champ assignment_group de la table sc_req_item ou sc_task. L'historique des changements est enregistré dans la table sys_audit. Capture Suivre les modifications du champ assignment_group dans sys_audit. Type d'événement inferred
	Demande annulée	Cette activité sert d'état terminal pour les demandes annulées avant leur achèvement, soit par l'utilisateur, soit par un agent. Elle est capturée lorsque l'état de la demande est défini sur 'Annulée' ou 'Fermée annulée'.
Pourquoi est-ce important ? : Ceci est un événement de fin clé non concluant. L'analyse des raisons pour lesquelles les demandes sont annulées peut fournir des insights sur les besoins des utilisateurs, les inefficacités des processus ou les changements de priorités commerciales. Source des données : Inférent de la mise à jour du champ d'état sc_req_item vers un état final annulé, comme 'Closed Cancelled'. Le changement est enregistré dans la table sys_audit. Capture Identifier l'horodatage lorsque `sc_req_item.state` passe à 'Annulé'. Type d'événement inferred
	Demande rejetée	Cette activité représente le résultat où une demande est formellement rejetée pendant la phase d'approbation. C'est un chemin alternatif de clôture et elle est capturée lorsqu'un approbateur marque la demande comme 'rejetée'.
Pourquoi est-ce important ? : Le suivi des rejets aide à identifier les demandes invalides ou mal dirigées, les problèmes liés au processus de soumission des demandes, et sert de voie d'exception importante pour l'analyse. Source des données : Inférent du champ d'état de l'enregistrement sysapproval_approver lié passant à 'rejected'. Cela place généralement le sc_req_item parent dans un état fermé et incomplet. Capture Identifier l'horodatage lorsque sysapproval_approver.state passe à 'rejected'. Type d'événement inferred
	Demande rouverte	Cette activité capture les cas où une demande prélèvement.cédemment marquée comme résolue est de nouveau mise à l'état ouvert. Ceci est inféré d'un changement d'état de 'Resolved' à 'Work in Progress' ou similaire.
Pourquoi est-ce important ? : C'est une mesure directe des retouches et est indispensablele pour calculer le KPI du 'Taux de résolution au premier contact'. Des chiffres élevés indiquent une mauvaise qualité de solution ou une résolution incomplète. Source des données : Inférent d'un changement dans le champ d'état sc_req_item, passant d'un état résolu ou fermé à un état ouvert, en cours. Ce changement est enregistré dans sys_audit. Capture Détecter le changement d'état de « Résolu » à « En cours » dans `sys_audit`. Type d'événement inferred
	Fournisseur externe engagé	Représente la passation d'une demande de service ou d'une de ses tâches à un fournisseur tiers externe pour exécution. Ceci peut être inféré de l'assignation à un groupe spécifique de fournisseur ou d'un flag sur la demande.
Pourquoi est-ce important ? : Cette activité permet l'analyse de la performance des fournisseurs et son impact sur le cycle de vie global de la demande, ce qui est impératif pour le tableau de bord 'Cycle d'engagement des fournisseurs externes'. Source des données : Ceci est généralement inféré. Cela pourrait être basé sur l'attribution du assignment_group à un groupe de fournisseur ou sur l'activation d'un champ flag spécifique sur l'enregistrement sc_req_item ou sc_task. Capture Identifier le changement de `assignment_group` vers un groupe de fournisseurs 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 inférée lorsque la demande sort d'un état 'En attente d'informations de l'utilisateur' pour revenir à un état actif comme 'En cours'.
Pourquoi est-ce important ? : Associée à 'Information demandée à l'utilisateur', cette activité permet une mesure précise des retards induits par l'utilisateur et aide à évaluer l'efficacité du processus de communication. Source des données : Inférent du champ d'état sc_req_item passant d'un statut 'en attente d'informations' à un statut actif. Ceci est souvent déclenché par l'ajout d'un commentaire ou la réponse à un e-mail par l'utilisateur. Capture Identifier l'horodatage lorsque l'état passe de « En attente d'informations utilisateur » à « En cours ». Type d'événement inferred
	Tâche d'exécution créée	Représente la création d'un élément de travail ou d'une tâche spécifique nécessaire pour répondre à la demande de service. Ceci est un événement explicite enregistré lorsqu'un nouvel enregistrement est créé dans la table Catalog Task.
Pourquoi est-ce important ? : Pour les demandes complexes, l'analyse de la création et de l'achèvement des tâches individuelles offre une vue plus granulairesre du processus d'exécution et des points de blocage. Source des données : C'est un événement explicite capturé à partir du horodatage de création (champ sys_created_on) d'un enregistrement dans la table sc_task qui est lié au sc_req_item. Capture 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 de ServiceNow

Étapes

Comprendre l'approche multi-exportation : En raison de la nature du modèle de données de ServiceNow, une seule exportation ne peut pas capturer tous les événements requis. Vous devez effectuer plusieurs exportations à partir de différentes tables, puis combiner les données en externe. Les tables principales sont Élément de demande (sc_req_item), Approbation (sysapproval_approver), Tâche de catalogue (sc_task) et Audit (sys_audit).
Exportation 1 : Données de base des demandes de service : Accédez à la table Élément de demande en tapant sc_req_item.list dans le navigateur de filtre. Appliquez un filtre pour la plage de dates 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. Faites un clic droit sur n'importe quel en-tête de colonne, choisissez Export, et sélectionnez CSV ou XLSX.
Exportation 2 : Décisions d'approbation : Accédez à la table Approbation en tapant sysapproval_approver.list. Filtrez la liste pour n'afficher que les enregistrements liés aux demandes de service : [Source table] [is] [sc_req_item] ET [Created] [on] [Last 6 months]. Ajoutez des colonnes comme Approving.Number, State, Sys Created On et Sys Updated On. Exportez la liste filtrée.
Exportation 3 : Création de tâche d'exécution : Accédez à la table Tâche de catalogue en tapant sc_task.list. Filtrez la liste pour la lier aux demandes de votre 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.
Exportation 4 : Historique détaillé des activités : Accédez à la table Audit en utilisant sys_audit.list. Cette table contient les modifications historiques des 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.
Combiner et transformer les données : Utilisez un outil comme Microsoft Excel, Python avec pandas, ou un outil de prélèvement.paration de données dédié 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 votre fichier combiné, créez les colonnes requises : ID_Demande_Service, Nom_Activité et Heure_Événement.
Mapper les données brutes aux activités : Créez une nouvelle ligne pour chaque activité distincte. Par exemple :
- Pour Création_Demande_Service, utilisez le Sys Created On de l'exportation sc_req_item.
- Pour Demande_Approuvée, utilisez le Sys Updated On de l'exportation sysapproval_approver où l'État est passé à 'approved'.
- Pour Demande_Attribuée_au_Groupe, trouvez la ligne dans l'exportation sys_audit où Field name est assignment_group et utilisez le Sys Created On de cet enregistrement d'audit comme (EventTime).
Remplir les colonnes d'attributs : Remplissez les attributs Attribué_à, Groupe_Attribution, Priorité, État, Catégorie et SLA_Respecté 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 Système_Source avec une valeur statique comme 'ServiceNow' et Dernière_Mise_à_Jour_Données avec l'horodatage de l'extraction.
Finaliser et exporter : Enregistrez les données finales transformées et combinées en un seul fichier CSV, en vous assurant que les en-têtes de colonne correspondent aux exigences d'importation.

Configuration

Tables cibles : L'extraction nécessite des données provenant de plusieurs tables :
- sc_req_item : Contient les enregistrements principaux des demandes de service (Requested Item).
- sysapproval_approver : Stocke les enregistrements d'approbation liés aux demandes.
- sc_task : Contient les tâches d'exécution individuelles générées pour une demande.
- sys_audit : Fournit un historique détaillé des modifications de champs, essentiel pour suivre les attributions et les transitions d'état.
Filtrage par plage de dates : Il est impératif d'appliquer un filtre de plage de dates cohérent, tel que Created on Last 6 months, à toutes les exportations pour garantir l'intégrité des données. Une période de 3 à 6 mois est recommandée pour équilibrer volume et pertinence des informations.
Filtres clés : Au-delà de la plage de dates, utilisez des filtres tels que Source table is sc_req_item sur la table d'approbation et Table name is sc_req_item sur la table d'audit pour isoler les enregistrements pertinents.
Colonnes essentielles : Assurez-vous d'exporter les identifiants clés comme Number et Sys ID (clé du document dans l'audit) pour joindre les jeux de données. Les horodatages tels que Sys Created On, Sys Updated On, Resolved et Closed sont fondamentaux pour créer le journal d'événements (journal d'événements).
Prérequis : Un compte utilisateur ServiceNow avec au moins le rôle itil est nécessaire pour accéder à la plupart des tables requises. L'exportation depuis la table sys_audit peut nécessiter le rôle admin ou un rôle spécialisé en raison de sa taille et de sa sensibilité.

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éparez l'environnement Python : Assurez-vous d'avoir Python 3.6 ou une version plus récente installée. Installez les bibliothèques nécessaires à l'aide de pip : pip install requests pandas.
Configurez les paramètres du script : Ouvrez le script Python dans un éditeur. Localisez la section de configuration en haut du script. Saisissez l'URL de votre instance ServiceNow (par exemple, https://votre-instance.service-now.com), un nom d'utilisateur et un mot de passe pour un compte de service avec les autorisations de lecture appropriées sur les tables requises.
Définissez la plage de dates d'extraction : Définissez les dates de début et de fin pour l'extraction des données en modifiant les variables start_date et end_date. Il est recommandé de commencer par une plage de dates plus petite, par exemple 3 mois, pour tester le script et vérifier les performances.
Examinez les noms des tables et des champs : Le script utilise des noms de tables ServiceNow standard comme sc_req_item, sys_audit et sc_task. Vérifiez que ces noms de tables et de champs correspondent à votre configuration ServiceNow. Ajustez-les dans le script si votre instance utilise des tables ou des champs personnalisés.
Exécutez le script Python : Exécutez le script à partir de votre ligne de commande ou terminal en utilisant la commande : python nom_de_votre_script.py. Le script se connectera à l'API ServiceNow, récupérera les données pour chaque activité spécifiée et affichera les messages de progression dans la console.
Gérez la pagination de l'API : Le script inclut une fonction pour gérer automatiquement la pagination. Il effectuera plusieurs appels API si le nombre d'enregistrements dépasse la limite de page (sysparm_limit) jusqu'à ce que toutes les données de la plage de dates spécifiée soient récupérées.
Transformez et combinez 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 mappe au schéma du journal d'événements (ID_Demande_Service, Nom_Activité, Heure_Événement, etc.) et les combine en un seul jeu de données unifié.
Générez le fichier du journal d'événements : Une fois le script terminé, il enregistrera le journal d'événements final sous forme de fichier CSV nommé servicenow_servicerequest_eventlog.csv dans le même répertoire où le script a été exécuté.
Préparez le téléchargement : Ouvrez le fichier CSV généré dans un programme de feuille de calcul pour vérifier l'exhaustivité et la justesse des données. Assurez-vous que les en-têtes de colonne correspondent au schéma ProcessMind requis avant de le télécharger.

Configuration

URL de l'instance ServiceNow : L'URL de base de votre instance ServiceNow (par exemple, https://votre-instance.service-now.com).
Authentification : Un nom d'utilisateur et un mot de passe de compte de service avec un accès en lecture aux tables sc_req_item, sys_audit, sysapproval_approver et sc_task sont requis.
Plage de dates : Définissez les variables start_date et end_date dans le script pour définir la fenêtre temporelle d'extraction. Une période de 3 à 6 mois est recommandée pour l'analyse initiale.
Limite de page (sysparm_limit) : Le script définit une limite pour le nombre d'enregistrements renvoyés par appel API. La valeur par défaut est 1000, ce qui est une valeur sûre pour la plupart des instances. Ceci peut être ajusté 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 des données. Vous pouvez ajouter d'autres filtres à la chaîne de requête, tels que le filtrage par un élément de catalogue spécifique ou un groupe d'attribution, afin de réduire le volume de données (par exemple, active=true^category=hardware).
Valeurs d'affichage (Display Values) : Le paramètre sysparm_display_value=true est utilisé pour récupérer des noms lisibles pour les champs de référence au lieu des valeurs internes sys_id. Ceci est indispensable pour des attributs comme 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

Configurez l'utilisateur API ServiceNow : Créez un utilisateur dédié dans votre instance ServiceNow pour cette intégration. Attribuez à cet utilisateur les rôles rest_service et itil. Assurez-vous que l'utilisateur dispose des autorisations de lecture (ACL) pour les tables suivantes : Élément de demande (sc_req_item), Tâche de catalogue (sc_task), Approbation (sysapproval_approver) et Audit (sys_audit).
Préparez votre environnement de développement : Installez Node.js sur la machine que vous utiliserez pour l'extraction. Ensuite, initialisez un nouveau projet Node.js et installez la bibliothèque 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.
Configurez le script d'extraction : Copiez le code JavaScript fourni dans un fichier, par exemple, extract.js. Remplissez les valeurs de substitution en haut du script pour l'URL de votre instance ServiceNow, le nom d'utilisateur API et le mot de passe.
Définissez la plage de dates et les filtres : Modifiez les variables startDate et endDate dans le script pour définir la fenêtre temporelle d'extraction. Vous pouvez également ajouter d'autres filtres aux chaînes sysparm_query pour chaque activité afin de réduire la portée, comme le filtrage par un élément de catalogue spécifique ou un groupe d'attribution.
Comprendre les appels API : Le script est conçu pour effectuer des appels API distincts pour chacune des 14 activités requises. Les événements comme la création sont interrogés directement à partir de leurs tables sources (sc_req_item, sc_task), tandis que les changements de statut et les attributions sont capturés en interrogeant la table sys_audit pour des mises à jour de champs spécifiques.
Exécutez le script : Exécutez le script depuis votre terminal en utilisant la commande node extract.js. Le script se connectera à l'API Table de ServiceNow, récupérera les données pour chaque activité et gérera automatiquement la pagination.
Traitez les données : Au fur et à mesure que les données sont récupérées, le script transforme la réponse JSON de ServiceNow en un format de journal d'événements standardisé, mappant les champs aux colonnes comme ID_Demande_Service, Nom_Activité et Heure_Événement.
Combinez et consolidez les résultats : Le script rassemble les résultats de tous les appels API individuels dans un tableau unifié unique représentant le journal d'événements complet.
Générez 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 dans le même répertoire.
Préparez le téléchargement : Le fichier CSV généré est structuré avec les colonnes requises pour le Process Mining. Aucune mise en forme supplémentaire n'est nécessaire avant de le télécharger sur la plateforme ProcessMind.

Configuration

URL de l'instance ServiceNow : L'URL de base de votre environnement ServiceNow, par exemple, https://votre-instance.service-now.com.
Identifiants API : Un nom d'utilisateur et un mot de passe valides pour un utilisateur ServiceNow avec les autorisations et rôles de lecture nécessaires (rest_service, itil).
Plage de dates : Nous recommandons d'extraire les données sur une période de 3 à 6 mois pour garantir un jeu de données représentatif. Cette configuration est définie dans le script à l'aide des variables startDate et endDate, qui sont appliquées aux champs d'horodatage appropriés dans les requêtes API.
sysparm_query : C'est le paramètre URL principal utilisé pour filtrer les enregistrements. Le script l'utilise largement pour isoler des événements spécifiques, tels que les enregistrements créés dans une plage de dates ou les enregistrements d'audit montrant un changement d'état de « Résolu » à « En cours ».
sysparm_fields : Ce paramètre spécifie les colonnes à retourner de l'appel API. Son utilisation améliore considérablement les performances en réduisant la quantité 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 1000. Cette valeur peut être ajustée, mais il est recommandé de rester en dessous du maximum de ServiceNow (généralement 10 000) pour assurer 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();

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

Activités de gestion des demandes de service

Guides d'extraction

Exportation de rapports et listes ServiceNow vers CSV/XLSX

Étapes

Configuration

a Exemple de requête config

Script Python utilisant Requests pour l'extraction via l'API de 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(e) à démarrer ?

Transformer la Gestion des demandes de service : Agissez maintenant

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

Activités de gestion des demandes de service

Guides d'extraction

Exportation de rapports et listes ServiceNow vers CSV/XLSX

Étapes

Configuration

a Exemple de requête config

Script Python utilisant Requests pour l'extraction via l'API de 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

Nous respectons votre vie privée

Prêt(e) à démarrer ?

Transformer la Gestion des demandes de service : Agissez maintenant