> Amélioration continue des processus > Gestion du changement > ServiceNow > Modèle de données

Votre modèle de données pour la gestion du changement

ServiceNow

Attributs de gestion du changement(19) Activités de gestion du changement(13) Guides d’extraction(3)

Votre modèle de données pour la gestion du changement

Ce modèle propose une méthode structurée pour recueillir les données essentielles à l’analyse de votre flux de travail de gestion du changement avec le Process Mining. Il présente les attributs et les activités recommandés, ainsi que des conseils pratiques pour extraire les données. Utilisez cette ressource pour préparer vos données à une analyse complète et à l’optimisation du processus.

Attributs recommandés à recueillir
Activités clés à suivre pour découvrir le processus avec précision
Conseils pour extraire les données de ServiceNow

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

Télécharger le modèle

Attributs de gestion du changement

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

3 Obligatoire 7 Recommandé 9 Facultatif

	Nom	Description
	Heure de l’événement EventTime	Horodatage précis auquel une activité ou un événement donné s’est produit.
Description L’heure de l’événement indique la date et l’heure exactes auxquelles une activité a été réalisée ou une modification de statut enregistrée. Cet horodatage est indispensable pour classer les événements par ordre chronologique et effectuer toute analyse de durée. En Process Mining, cet attribut permet de calculer les temps de cycle, les durées de traitement et les temps d’attente entre les activités. Il est essentiel aux Dashboards qui analysent les performances, comme « Temps de cycle d’approbation des changements » et « Flux de bout en bout du processus de changement ». Des horodatages exacts sont indispensables pour repérer les retards et mesurer l’efficacité du processus au regard des SLA. Pourquoi est-ce important ? Cet horodatage permet de remettre les événements dans le bon ordre et de calculer toutes les métriques temporelles, notamment les temps de cycle, les durées et le respect des SLA. Où trouver ces données Table ServiceNow : sys_audit, champ : sys_created_on. Cet horodatage indique la date et l’heure de chaque modification enregistrée. Exemples 2023-10-26T10:00:00Z2023-10-26T11:30:15Z2023-10-27T14:05:00Z
	Identifiant de la demande de changement ChangeRequestNumber	Identifiant unique d’une demande de changement, utilisé comme ID de cas principal pour regrouper tous les événements associés.
Description L’identifiant de la demande de changement est au cœur de l’analyse du processus de gestion du changement. Ce numéro unique attribué à chaque demande, par exemple « CHG0030001 », relie toutes les activités, approbations et tâches associées. En Process Mining, cet attribut sert à reconstituer le parcours complet de chaque changement. Les analystes peuvent ainsi suivre son cycle de vie, de la création à la clôture, et comprendre comment il progresse dans le système. Le regroupement des processus par identifiant est indispensable pour calculer les temps de cycle, repérer les boucles de reprise et comprendre les variantes du processus. Pourquoi est-ce important ? Cet identifiant permet de suivre l’ensemble du cycle de vie d’un changement et d’analyser intégralement le flux du processus, sa durée et sa conformité pour chaque demande. Où trouver ces données Table ServiceNow : change_request, champ : number Exemples CHG0030001CHG0030045CHG0030112
	Nom de l’activité ActivityName	Nom d’un événement ou d’une tâche précise survenu dans le processus de gestion du changement.
Description Le nom de l’activité désigne une étape distincte ou une modification d’état dans le cycle de vie d’une demande de changement. Exemples : « Changement en attente d’évaluation », « Approbation demandée » et « Changement mis en œuvre ». Ces activités constituent les nœuds de la carte de processus découverte. L’analyse de ces activités permet d’examiner le flux du processus en détail. En suivant leur séquence et leur fréquence, les organisations peuvent repérer les parcours courants, les écarts par rapport au processus standard et les goulots d’étranglement où les changements restent souvent bloqués. Cette analyse est essentielle pour visualiser le processus et calculer des métriques comme le temps de transition entre les étapes. Pourquoi est-ce important ? Cet attribut constitue la structure de base de la carte de processus. Il permet de visualiser le flux du processus, de repérer les goulots d’étranglement et d’analyser les écarts. Où trouver ces données Déduit des modifications du champ « state » ou d’autres champs de statut importants de la table « change_request », souvent enregistrées dans la table « sys_audit ». Exemples Changement approuvéMise en œuvre commencéeChangement clôturéChangement annulé
	Élément de configuration ConfigurationItem	Composant informatique, service ou système concerné par le changement.
Description L’élément de configuration (CI) est l’actif de la base de données de gestion des configurations (CMDB) concerné par le changement. Il peut s’agir d’un serveur, d’une application logicielle, d’un équipement réseau ou d’un service métier. Cet attribut apporte un contexte essentiel au changement. En Process Mining, il permet de segmenter l’analyse selon le type d’actif modifié. Par exemple, le Dashboard « Analyse de la durée des tests de changement » s’appuie sur cet attribut pour comparer les durées de test de différentes applications ou de différents systèmes et repérer les éléments de configuration associés aux cycles de test les plus longs. Pourquoi est-ce important ? Apporte un contexte métier essentiel et permet de filtrer l’analyse selon l’application, le service ou le système concerné afin de repérer les problèmes propres à chaque composant. Où trouver ces données Table ServiceNow : change_request, champ : cmdb_ci Exemples SAP ERPOracle Database 19cService de messagerieWebServer-01
	État du changement ChangeState	État actuel ou historique de la demande de changement, par exemple « Assess », « Authorize », « Implement » ou « Closed ».
Description L’attribut « État du changement » indique le statut d’une demande de changement à un moment donné. Il donne une vue d’ensemble de l’étape du cycle de vie à laquelle se trouve le changement. Contrairement à l’activité, qui désigne un événement précis, l’état correspond à la situation résultant de cet événement. Dans le cadre de l’analyse, cet attribut sert à classer les cas et à comprendre leur issue. Il permet notamment de filtrer les changements, par exemple pour analyser uniquement ceux à l’état « Closed » ou examiner pourquoi de nombreux changements restent bloqués à l’état « Authorize ». Il contribue directement au calcul d’indicateurs comme le taux d’échec des changements, lorsqu’un état « Failed » existe. Pourquoi est-ce important ? Donne un aperçu du statut de la demande de changement et permet d’analyser les résultats, de filtrer les cas et de repérer les changements bloqués. Où trouver ces données Table ServiceNow : change_request, champ : state Exemples ÉvaluerAutoriserPlanifiéMettre en œuvreExaminerClôturéAnnulé
	Groupe d’affectation AssignmentGroup	Équipe ou groupe responsable de la demande de changement.
Description Le groupe d’affectation indique quelle équipe est actuellement responsable de la demande de changement, par exemple « Approbation du CAB », « Ingénierie réseau » ou « Administrateurs de bases de données ». Cet attribut est essentiel pour analyser les performances du processus dans les différents domaines fonctionnels. Il permet de mesurer l’efficacité des équipes, de repérer les goulots d’étranglement au sein de groupes précis et d’évaluer l’efficacité des transmissions entre équipes. Des Dashboards comme « Efficacité des transmissions entre équipes » et « Débit de mise en œuvre des changements » s’appuient largement sur ces données pour repérer les retards liés aux dépendances entre équipes. Pourquoi est-ce important ? Permet d’analyser les performances par équipe, de repérer les goulots d’étranglement propres à chaque groupe et de mesurer l’efficacité des transmissions entre domaines fonctionnels. Où trouver ces données Table ServiceNow : change_request, champ : assignment_group Exemples Approbation du CABÉquipe réseauAssistance serveurAdministrateurs de bases de données
	Heure de fin EndTime	Horodatage de la fin d’une activité. Il est souvent déduit de l’heure de début de l’activité suivante.
Description L’heure de fin indique le moment où une activité s’achève. Les systèmes sources enregistrent souvent le début d’un événement, mais sa fin doit fréquemment être déduite. Elle correspond généralement à l’horodatage de l’activité suivante dans la séquence du même cas. Cet attribut est indispensable pour calculer la durée de chaque activité, appelée durée de traitement. Savoir combien de temps prend chaque étape permet de repérer les goulots d’étranglement et les inefficacités du processus. Pour la dernière activité d’un cas, l’heure de fin est identique à l’heure de début. Pourquoi est-ce important ? Permet de calculer la durée de traitement des activités, afin de repérer les goulots d’étranglement et de mesurer la durée de certaines étapes du processus. Où trouver ces données Cet attribut est généralement calculé lors de la transformation des données, à partir de StartTime de l’événement suivant pour le même CaseId. Exemples 2023-10-26T10:05:12Z2023-10-26T11:45:00Z2023-10-27T15:00:00Z
	Niveau de risque RiskLevel	Niveau de risque évalué pour le changement, par exemple « Élevé », « Modéré » ou « Faible ».
Description Le niveau de risque correspond au résultat de l’évaluation des risques d’une demande de changement. Il mesure les conséquences négatives potentielles de la mise en œuvre du changement et aide à déterminer le niveau de contrôle et d’approbation requis. Cet attribut est essentiel au Dashboard « Harmonisation de l’évaluation des risques », qui permet de vérifier si des changements similaires reçoivent des évaluations cohérentes. L’analyse des flux de processus par niveau de risque peut également révéler si les changements à risque élevé suivent bien un parcours d’approbation et de test plus rigoureux que ceux à faible risque, un contrôle important de conformité. Pourquoi est-ce important ? Indispensable à l’analyse de la conformité et à la vérification que les changements à risque élevé font l’objet du niveau de contrôle approprié et suivent un processus plus rigoureux. Où trouver ces données Table ServiceNow : change_request, champ : risk Exemples ÉlevéModéréFaible
	Priorité Priority	Niveau de priorité de la demande de changement, déterminé par son impact et son urgence.
Description La priorité indique l’importance d’une demande de changement et détermine l’ordre dans lequel elle doit être traitée. Elle est souvent établie à partir de l’impact et de l’urgence du changement, avec des valeurs comme « Critique », « Élevée », « Modérée » et « Faible ». L’analyse par priorité permet de vérifier que les changements prioritaires sont traités plus rapidement que ceux de moindre priorité. Elle alimente le Dashboard « Performance des changements critiques », qui permet aux analystes de suivre les temps de cycle et les taux d’échec des changements les plus importants. Si les changements de faible priorité sont achevés plus vite que ceux de priorité élevée, cela peut signaler un problème de répartition des ressources ou d’exécution du processus. Pourquoi est-ce important ? Permet de vérifier si les ressources sont correctement affectées aux changements les plus importants et d’en suivre les performances séparément. Où trouver ces données Table ServiceNow : change_request, champ : priority Exemples 1 - Critique2 - Élevée3 - Modérée4 - Faible
	Type de changement ChangeType	Classification du changement, par exemple « Standard », « Normal » ou « Emergency ».
Description Le type de changement classe la demande selon sa nature, son niveau de risque et les approbations requises. Les changements standard sont préapprouvés, les changements normaux suivent le processus complet et les changements d’urgence empruntent un parcours accéléré. Cet attribut est fondamental pour l’analyse du processus, car chaque type de changement suit un modèle de processus distinct et légitime. Comparer les performances des changements normaux et des changements d’urgence peut révéler des écarts importants en matière de respect du processus et d’efficacité. Il est également utilisé dans des Dashboards comme « Harmonisation de l’évaluation des risques » pour vérifier que les changements similaires sont traités de façon cohérente. Pourquoi est-ce important ? Permet de segmenter l’analyse, car les différents types de changement suivent des flux de processus autorisés distincts et répondent à des attentes de performance qui leur sont propres. Où trouver ces données Table ServiceNow : change_request, champ : type Exemples StandardNormalUrgence
	Code de clôture CloseCode	Code indiquant le résultat à la clôture de la demande de modification, par exemple « Réussie » ou « Échec ».
Description Le code de clôture indique l’issue définitive d’une demande de modification terminée. Il précise officiellement si la modification a été mise en œuvre avec succès, si elle a rencontré des problèmes ou si elle a été annulée. Cet attribut alimente directement l’indicateur « Taux d’échec des modifications ». L’analyse de la répartition des codes de clôture permet aux organisations de mesurer le succès de leurs initiatives de changement. Filtrer la cartographie du processus pour afficher les modifications dont le code de clôture est « Échec » est une méthode efficace pour rechercher les causes profondes et repérer les schémas de processus qui conduisent à un échec. Pourquoi est-ce important ? Mesure directement le résultat d’une modification et fournit les données nécessaires au calcul du taux d’échec et à l’analyse des causes profondes des modifications qui échouent. Où trouver ces données Table ServiceNow : change_request, champ : close_code Exemples RéussieRéussie avec des problèmesÉchec / annulée
	Dernière mise à jour des données LastDataUpdate	Horodatage indiquant la dernière actualisation des données de cet enregistrement depuis le système source.
Description Cet attribut indique l’horodatage de la dernière extraction des données. Il s’agit d’un champ de métadonnées essentiel pour connaître l’actualité des données analysées. Les analystes s’en servent pour vérifier qu’ils travaillent avec des informations à jour et pour connaître leur ancienneté. Cet attribut est particulièrement important pour les Dashboards opérationnels qui suivent les performances en cours du processus : il permet de s’assurer que les décisions ne reposent pas sur des données obsolètes. Pourquoi est-ce important ? Indique si les données sont à jour, afin que les analyses et les Dashboards reposent sur des informations actuelles et pertinentes. Où trouver ces données Ce champ de métadonnées est généré lors de l’extraction et de la transformation des données (ETL). Il indique l’heure de leur extraction. Exemples 2023-11-01T02:00:00Z2023-11-02T02:00:00Z
	Est une reprise IsRework	Indicateur booléen qui vaut vrai lorsqu’une activité correspond à la répétition d’une étape précédente dans le même dossier.
Description Cet attribut calculé repère les activités qui correspondent à des reprises. Il y a reprise lorsque le processus revient à une étape déjà effectuée, par exemple lorsqu’une modification est rejetée après approbation et renvoyée pour réévaluation. Cet indicateur permet de mesurer les inefficacités du processus. Il alimente directement l’indicateur « Taux de reprises des modifications » et le Dashboard « Analyse des échecs et des reprises de modifications ». En filtrant les activités pour lesquelles « Est une reprise » vaut vrai, les analystes peuvent isoler et étudier les causes des reprises, comme une évaluation initiale incomplète ou l’évolution des exigences, puis prendre des mesures pour limiter le gaspillage. Pourquoi est-ce important ? Mesure directement les inefficacités du processus en repérant les tâches répétées, ce qui aide à identifier et à traiter les causes profondes des boucles de processus et des efforts inutiles. Où trouver ces données Calculé lors de la transformation des données, en détectant si la même activité, ou une activité antérieure dans le flux standard, a déjà eu lieu pour le CaseId concerné. Exemples truefalse
	État du SLA SlaState	État de la demande de modification au regard de son accord de niveau de service (SLA), par exemple « Dans les délais prévus », « À risque » ou « En dépassement ».
Description L’état du SLA indique si la demande de modification progresse dans les délais définis par son SLA. Cet état peut être suivi à chaque étape du processus. Cet attribut est essentiel au suivi du respect des engagements de niveau de service. Il constitue la principale source de données du Dashboard « Vue d’ensemble de la performance du SLA des modifications » et de l’indicateur « Taux de respect du SLA des modifications ». L’analyse des situations de dépassement et de leurs causes permet à l’organisation de traiter les retards systémiques et de rendre la prestation de service plus prévisible. Pourquoi est-ce important ? Mesure directement le respect des délais et permet de suivre les dépassements de SLA de manière proactive afin d’améliorer la prestation de service. Où trouver ces données Ces données peuvent provenir de la table « task_sla » de ServiceNow, qui suit les SLA associés à des tâches comme les demandes de modification, ou être calculées à partir des champs de date d’échéance. Exemples Dans les délais prévusÀ risqueEn dépassement
	Impact Impact	Effet potentiel du changement sur les opérations métier, évalué selon une échelle telle que « Élevé », « Moyen » ou « Faible ».
Description L’impact mesure les conséquences potentielles pour l’entreprise si la demande de changement n’est pas traitée correctement. Avec l’urgence, il sert à déterminer la priorité globale du changement. L’analyse par impact permet de vérifier que les changements touchant des services essentiels sont gérés avec le soin nécessaire. Le Dashboard « Performance des changements critiques » s’en sert pour isoler et suivre les changements ayant un impact métier élevé. Cet attribut permet aussi de vérifier la cohérence des évaluations des risques, afin que les changements à fort impact ne soient pas classés à faible risque sans justification. Pourquoi est-ce important ? Permet de hiérarchiser les changements selon leurs conséquences potentielles pour l’entreprise et de vérifier que ceux à fort impact sont gérés avec toute la diligence requise. Où trouver ces données Table ServiceNow : change_request, champ : impact Exemples 1 - Élevé2 - Moyen3 - Faible
	Système source SourceSystem	Système dont les données ont été extraites, généralement « ServiceNow ».
Description Cet attribut indique l’origine des données du processus. Dans ce cas, il s’agit normalement de ServiceNow. Il reste essentiel à la gouvernance des données et aux situations où des données provenant de plusieurs systèmes sont regroupées. Dans le cadre de l’analyse, il permet de retracer clairement l’origine des données et d’en vérifier la source. Pour les organisations qui utilisent plusieurs outils ITSM ou des systèmes intégrés, cet attribut permet de filtrer et de comparer les processus entre différentes plateformes. Pourquoi est-ce important ? Cet attribut assure la traçabilité de l’origine des données du processus, un élément essentiel à la gouvernance des données et à l’analyse de plusieurs systèmes. Où trouver ces données Il s’agit généralement d’une valeur statique ajoutée lors de l’extraction et de la transformation des données (ETL). Exemples ServiceNowServiceNow_PRODSNOW_ITSM
	Temps de cycle CycleTime	Durée totale entre la création et la clôture d’une demande de modification.
Description Le temps de cycle est une métrique calculée à l’échelle du dossier, qui mesure la durée totale du cycle de vie d’une demande de modification. Il correspond à l’écart entre l’horodatage du premier événement et celui du dernier événement pour une demande donnée. Cet indicateur clé permet de mesurer la vitesse globale du processus. Le Dashboard « Flux de bout en bout du processus de modification » l’utilise pour présenter une vue d’ensemble de la performance du processus. L’analyse des tendances du temps de cycle et leur comparaison selon différents critères, comme le type de modification ou la priorité, aident les organisations à repérer des pistes d’amélioration stratégique. Pourquoi est-ce important ? Mesure la durée totale du processus de modification et fournit un indicateur clé de sa vitesse et de son efficacité globales. Où trouver ces données Calculé à l’échelle du dossier lors de l’analyse des données, en soustrayant le StartTime minimum du StartTime maximum pour chaque CaseId. Exemples 60480012096002592000
	Urgence Urgency	La rapidité avec laquelle une modification doit être résolue, évaluée sur une échelle telle que élevée, moyenne ou faible.
Description L’urgence indique dans quel délai une modification doit être mise en œuvre. Elle reflète la contrainte de temps associée à la demande du point de vue de l’activité. Avec l’impact, elle sert à calculer la priorité globale. La priorité est le principal champ d’analyse, mais l’urgence apporte un éclairage complémentaire. Elle permet d’examiner pourquoi certaines modifications sont considérées comme urgentes et si le processus les prend en charge efficacement sans compromettre la stabilité. Elle aide à déterminer si l’organisation doit trop souvent fonctionner en mode réactif, avec un niveau d’urgence élevé. Pourquoi est-ce important ? Précise le degré d’urgence d’une modification et permet d’évaluer si le processus traite efficacement les demandes soumises à des contraintes de temps. Où trouver ces données Table ServiceNow : change_request, champ : urgency Exemples 1 - Élevé2 - Moyen3 - Faible
	Utilisateur affecté AssignedToUser	Personne responsable de la demande de changement à un moment donné.
Description Cet attribut identifie la personne chargée de traiter la demande de changement. Cette affectation peut changer plusieurs fois au cours du cycle de vie, à mesure que la demande passe d’une étape ou d’une équipe à l’autre. L’analyse par utilisateur permet de comprendre la répartition de la charge de travail et les performances individuelles, ainsi que de repérer les besoins de formation. Elle est également utile pour analyser les transmissions, notamment lorsqu’elle est associée au groupe d’affectation, afin d’évaluer l’efficacité du transfert du travail entre les personnes. Pourquoi est-ce important ? Permet de suivre la charge de travail et les performances de chaque utilisateur, et d’analyser les retards lors du transfert du travail entre les ressources. Où trouver ces données Table ServiceNow : change_request, champ : assigned_to Exemples Beth AnglinDavid LooAbel Tuter

Obligatoire Recommandé Facultatif

Activités de gestion du changement

Voici les principales étapes et les jalons du processus à consigner dans votre journal d’événements pour découvrir avec précision le processus de gestion du changement.

7 Recommandé 6 Facultatif

	Activité	Description
	Changement annulé	La demande de changement a été retirée ou abandonnée avant la fin de sa mise en œuvre. Cet état final alternatif est enregistré lorsque l’état passe à « Canceled ».
Pourquoi est-ce important ? L’analyse des changements annulés peut révéler des inefficacités dans le processus, par exemple des demandes créées inutilement ou bloquées trop longtemps en attente d’approbation, au point de devenir obsolètes. Où trouver ces données L’activité est déduite du passage du champ « state » de la table change_request à « Canceled ». L’horodatage provient du journal d’audit de cette modification d’état. Données à recueillir Enregistrez l’horodatage auquel le champ « state » passe à « Canceled ». Type d’événement inferred
	Changement approuvé	La demande de changement a reçu toutes les autorisations nécessaires pour passer à la planification et à la mise en œuvre. Cette étape importante est enregistrée lorsque l’approbation finale est accordée et que le champ « approval » passe à « approved ».
Pourquoi est-ce important ? Cette étape marque la fin de la phase d’approbation. Elle est indispensable pour mesurer les temps de cycle d’approbation et repérer les goulots d’étranglement dans la prise de décision. Où trouver ces données L’activité est déduite du passage du champ « approval » de la table change_request à « approved ». L’horodatage provient de l’historique d’audit de cette modification. Données à recueillir Enregistrez l’horodatage auquel le champ « approval » passe à « approved ». Type d’événement inferred
	Changement clôturé	La demande de changement a été menée à bien et examinée. Elle est désormais considérée comme terminée. Il s’agit de l’issue positive principale du processus, enregistrée lorsque l’état du changement passe à « Closed ».
Pourquoi est-ce important ? Cette activité marque la fin du cycle de vie du changement. Elle constitue l’événement de fin utilisé pour mesurer la durée totale du processus et le respect des SLA. Où trouver ces données L’activité est déduite du passage du champ « state » de la table change_request à « Closed ». L’horodatage provient de l’historique d’audit de cette modification d’état finale. Données à recueillir Enregistrez l’horodatage auquel le champ « state » passe à « Closed ». Type d’événement inferred
	Changement mis en œuvre	La mise en œuvre est terminée. Le changement peut maintenant être examiné, vérifié ou testé. Cette activité est déduite du passage de l’état de la demande de « Implement » à « Review ».
Pourquoi est-ce important ? Cette étape importante marque la fin de la phase de mise en œuvre. Elle permet notamment de calculer les indicateurs « Taux d’échec des changements » et « Taux de reprise des changements ». Où trouver ces données L’activité est déduite du passage de l’état « Implement » à un état ultérieur, comme « Review ». L’horodatage provient de l’historique d’audit du champ « state » dans la table change_request. Données à recueillir Repérez le passage du champ « state » de « Implement » à « Review ». Type d’événement inferred
	Changement planifié	Une date de début et une date de fin prévisionnelles ont été attribuées au changement approuvé, qui figure désormais au calendrier de mise en œuvre. Cette étape est déduite du passage de l’état de la demande à « Scheduled ».
Pourquoi est-ce important ? Cette activité marque la transition entre les étapes de planification et d’approbation et la phase de mise en œuvre. Le temps passé dans cet état peut révéler des retards entre l’approbation et le début des travaux. Où trouver ces données L’activité est déduite du passage du champ « state » de la table change_request à « Scheduled ». L’horodatage provient de l’entrée correspondante dans le journal d’audit. Données à recueillir Suivez dans l’historique d’audit de la table change_request les modifications du champ state vers « Scheduled ». Type d’événement inferred
	Demande de changement créée	Cette activité correspond à la création d’un nouvel enregistrement de demande de changement dans le système. Elle marque le début officiel du processus de gestion du changement et est enregistrée lors de l’ajout d’une nouvelle entrée dans la table change_request.
Pourquoi est-ce important ? Il s’agit de l’événement de début principal du processus. Le temps écoulé entre cette activité et les suivantes révèle la durée totale du processus et aide à repérer les retards dès les premières étapes. Où trouver ces données Cet événement correspond à l’horodatage de création de l’enregistrement (sys_created_on) dans la table change_request de ServiceNow. Données à recueillir Utilisez l’horodatage sys_created_on de la table change_request. Type d’événement explicit
	Risques et impacts évalués	Cette activité marque la fin de l’analyse des risques et des impacts de la demande de changement. C’est une étape importante avant la demande d’approbation. Elle est souvent déduite du passage de l’état « Assess » à « Authorize » ou « Awaiting Approval ».
Pourquoi est-ce important ? Le suivi de la durée de la phase d’évaluation est essentiel pour l’indicateur « Temps de cycle moyen de l’évaluation des risques ». Il permet d’harmoniser le processus d’évaluation et de repérer les analyses qui prennent trop de temps. Où trouver ces données L’activité est déduite du passage du champ « state » de la table change_request de « Assess » à « Authorize ». L’horodatage de l’événement provient du journal d’audit de cette modification d’état. Données à recueillir Repérez le passage du champ « state » de « Assess » à un état ultérieur, comme « Authorize ». Type d’événement inferred
	Approbation demandée	Cette activité indique que la demande de changement a été officiellement soumise pour approbation, généralement à un responsable ou à un comité consultatif des changements (CAB). L’événement est enregistré lorsque le statut d’approbation de la demande passe à « requested ».
Pourquoi est-ce important ? Cette étape marque le début du cycle d’approbation. Le temps écoulé entre cet événement et « Changement approuvé » permet de calculer directement l’indicateur « Temps moyen d’approbation des changements ». Où trouver ces données L’activité est déduite du passage du champ « approval » de la table change_request à « requested ». L’horodatage de cette modification est enregistré dans la table sys_audit. Données à recueillir Horodatage du passage du champ « approval » de la table change_request à « requested ». Type d’événement inferred
	Changement en attente d’évaluation	La demande de changement a été soumise et attend maintenant une évaluation technique et métier. Cette étape est généralement déduite du passage de l’état de la demande à « Assess » ou à un statut similaire, ce qui indique qu’elle n’est plus à l’état de brouillon.
Pourquoi est-ce important ? Cette activité permet de mesurer le délai initial de transmission entre le demandeur et l’équipe d’évaluation. Un retard à cette étape peut signaler des problèmes de qualité des données initiales ou un manque de ressources pour l’évaluation. Où trouver ces données L’activité est déduite d’une modification du champ « state » dans la table change_request, généralement vers la valeur « Assess ». L’horodatage provient de l’historique d’audit (sys_audit) de cette modification. Données à recueillir Suivez dans l’historique d’audit de la table change_request les modifications du champ state vers « Assess ». Type d’événement inferred
	Changement rejeté	La demande de changement a été refusée par un approbateur ou par le CAB. Cette activité constitue un état final pour la demande, sauf si celle-ci est retravaillée puis soumise à nouveau. Elle est enregistrée lorsque le champ « approval » passe à « rejected ».
Pourquoi est-ce important ? Le suivi des rejets permet de repérer les motifs fréquents de refus, comme des informations incomplètes ou un risque élevé. Cette analyse peut améliorer la qualité des futures demandes de changement. Où trouver ces données L’activité est déduite du passage du champ « approval » de la table change_request à « rejected ». L’horodatage provient de l’historique d’audit. Données à recueillir Enregistrez l’horodatage auquel le champ « approval » passe à « rejected ». Type d’événement inferred
	Changement rouvert	Après avoir atteint une étape ultérieure, la demande de changement est revenue à un état précédent, comme « Implement » ou « Assess ». Cet événement, déduit d’une transition non linéaire entre états, signale une reprise.
Pourquoi est-ce important ? Cette activité permet de repérer les boucles de reprise et de calculer le « Taux de reprise des changements ». Des réouvertures fréquentes peuvent révéler des problèmes de qualité de mise en œuvre, de tests ou de planification. Où trouver ces données L’activité est déduite de l’analyse de la séquence des modifications d’état dans l’historique d’audit de la table change_request. Le passage d’un état ultérieur, par exemple « Review », à un état antérieur, comme « Implement », indique une réouverture. Données à recueillir Repérez dans l’historique du champ « state » une transition non séquentielle vers un état antérieur. Type d’événement inferred
	Examen en cours	Un examen après mise en œuvre (PIR) est en cours afin de vérifier si le changement a réussi et atteint ses objectifs. Cette activité est enregistrée lorsque l’état de la demande passe à « Review ».
Pourquoi est-ce important ? L’analyse de la durée de la phase d’examen permet de repérer les retards dans la validation des résultats du changement. Elle met également en évidence les changements non conformes pour lesquels cette étape a été omise. Où trouver ces données L’activité est déduite du passage du champ « state » de la table change_request à « Review ». L’horodatage provient du journal d’audit de cette modification d’état. Données à recueillir Relevez dans l’historique d’audit de la demande de changement l’horodatage du passage de l’état à « Review ». Type d’événement inferred
	Mise en œuvre commencée	La mise en œuvre du changement a commencé. Cette activité est enregistrée lorsque l’état de la demande passe à « Implement », marquant la transition entre la planification et l’exécution.
Pourquoi est-ce important ? Cette activité marque le début des travaux de mise en œuvre. Elle sert de point de départ au calcul de l’indicateur « Durée moyenne de mise en œuvre » et à l’analyse de l’efficacité des équipes. Où trouver ces données L’activité est déduite du passage du champ « state » de la table change_request à « Implement ». L’horodatage provient du journal d’audit de cette transition d’état. Données à recueillir Relevez dans l’historique d’audit de la demande de changement l’horodatage du passage de l’état à « Implement ». Type d’événement inferred

Recommandé Facultatif

Guides d’extraction

Comment extraire vos données de ServiceNow

Étapes

Connectez-vous à votre instance ServiceNow avec un compte utilisateur disposant au minimum du rôle itil ou d’autorisations de lecture équivalentes pour le module de gestion du changement.
Exportez les données principales des demandes de modification : accédez à Modification > Toutes pour afficher la liste des demandes de modification. Utilisez l’icône en forme d’entonnoir pour filtrer la période souhaitée, par exemple Créé au cours des 3 derniers mois.
Configurez les colonnes à exporter : cliquez avec le bouton droit sur l’en-tête d’une colonne, puis sélectionnez Configurer > Disposition de la liste. Ajoutez les colonnes suivantes à la liste « Sélectionné » : Nombre, sys_created_on, sys_updated_on, state, assignment_group, type, priority, risk et cmdb_ci. Cliquez sur Enregistrer.
Exportez les données des demandes de modification : une fois la vue en liste filtrée et configurée, cliquez de nouveau avec le bouton droit sur l’en-tête d’une colonne, accédez à Exporter, puis sélectionnez CSV. Le système prépare le fichier à télécharger. Celui-ci contient les données nécessaires aux activités fondées sur les états.
Exportez les données d’approbation : dans le filtre de navigation, saisissez sysapproval_approver.list et appuyez sur Entrée. La vue en liste de toutes les approbations s’ouvre.
Filtrez et exportez les approbations : utilisez l’entonnoir pour afficher uniquement les approbations liées aux modifications. Définissez le filtre sur La table source est change_request ET Créé au cours des 3 derniers mois. Configurez la disposition de la liste pour inclure des colonnes telles que Approbateur, État, Créé, Mis à jour et ID du document (qui contient le numéro de la demande de modification). Exportez cette liste dans un fichier CSV distinct.
Combinez et transformez les données : cette opération manuelle nécessite un tableur ou un script simple. Ouvrez les deux fichiers CSV. L’objectif est de créer un seul journal d’événements, avec une ligne par activité.
Associez les changements d’état des demandes de modification : dans le fichier des demandes de modification, créez une ligne pour chaque transition d’état. Par exemple :
- Demande de modification créée : utilisez l’horodatage sys_created_on.
- Modification en attente d’évaluation : utilisez sys_updated_on lorsque le champ state prend pour la première fois la valeur Assess.
- Mise en œuvre commencée : utilisez sys_updated_on lorsque le champ state prend pour la première fois la valeur Implement.
- Pour toutes les autres activités fondées sur l’état (Modification planifiée, Modification mise en œuvre, Examen en cours, Modification clôturée, Modification annulée), utilisez l’horodatage sys_updated_on correspondant au changement du champ state vers la valeur appropriée.
Associez les événements d’approbation : dans le fichier des approbations, reliez les données au fichier principal des demandes de modification à l’aide du numéro de la demande (ID du document).
- Approbation demandée : utilisez l’horodatage Créé de l’enregistrement d’approbation dont l’État est requested.
- Modification approuvée : utilisez l’horodatage Mis à jour du dernier enregistrement d’approbation qui fait passer la modification à l’état approved.
- Modification rejetée : utilisez l’horodatage Mis à jour de l’enregistrement d’approbation dont l’État devient rejected.
Assemblez le journal d’événements final : regroupez toutes les lignes créées aux étapes précédentes dans un seul tableau. Vérifiez que les colonnes portent les noms requis : ChangeRequestNumber, ActivityName, EventTime et les autres attributs recommandés.
Enregistrez et importez le fichier : enregistrez les données combinées et mises en forme dans un seul fichier CSV, prêt à être importé dans un outil de Process Mining.

Configuration

Tables principales : les données essentielles proviennent de deux tables : change_request, qui contient les détails des modifications et leurs transitions d’état, et sysapproval_approver, qui contient les événements liés aux approbations.
Filtre de période : appliquez le même filtre de dates à tous les exports, généralement en fonction de la date de création (sys_created_on). Pour une première analyse, une période de 3 à 6 mois est recommandée.
Modèle d’état : la logique d’extraction dépend fortement du modèle d’état des demandes de modification propre à votre organisation dans ServiceNow. Les états standard sont « Évaluer », « Autoriser », « Planifié », « Mettre en œuvre », « Réviser », « Clôturé » et « Annulé ». Vérifiez qu’ils correspondent à votre configuration.
Autorisations requises : les utilisateurs qui effectuent l’export doivent disposer au minimum du rôle itil ou d’un rôle personnalisé leur donnant accès en lecture aux tables change_request et sysapproval_approver.
Format d’export : exportez toujours les données au format CSV pour en faciliter la manipulation et la fusion. Le format XLS peut être soumis à des limites de lignes et modifier les formats de date.

Exemple de requête config

This method uses the ServiceNow UI for filtering and exporting, not a direct script. The configuration below outlines the filters and columns for each required export.

**Export 1: Change Request Data**
*   **Navigate to Table**: `change_request.list`
*   **Filter Conditions**:
    *   `Created` `on` `Last 3 months` (or your desired date range)
    *   AND `Type` `is one of` `Normal, Standard, Emergency` (as needed)
*   **Columns to Select/Export**:
    *   `number` (maps to ChangeRequestNumber)
    *   `sys_created_on` (used for 'Change Request Created' EventTime)
    *   `sys_updated_on` (used as EventTime for most state changes)
    *   `state` (maps to ChangeState)
    *   `assignment_group` (maps to AssignmentGroup)
    *   `type` (maps to ChangeType)
    *   `priority` (maps to Priority)
    *   `risk` (maps to RiskLevel)
    *   `cmdb_ci` (maps to ConfigurationItem)

**Export 2: Approval Data**
*   **Navigate to Table**: `sysapproval_approver.list`
*   **Filter Conditions**:
    *   `Source table` `is` `change_request`
    *   AND `Created` `on` `Last 3 months` (or your desired date range)
*   **Columns to Select/Export**:
    *   `document_id` (used to link to the Change Request Number)
    *   `state` (approval state: requested, approved, rejected)
    *   `sys_created_on` (used for 'Approval Requested' EventTime)
    *   `sys_updated_on` (used for 'Change Approved'/'Change Rejected' EventTime)

**Post-Export Transformation Logic (to be performed in a spreadsheet or script)**:

For each unique Change Request Number, create the following rows based on the data from the exported files. Timestamps should be from `sys_updated_on` unless specified otherwise.

1.  `ActivityName`: 'Change Request Created', `EventTime`: `sys_created_on` from change_request export.
2.  `ActivityName`: 'Change Awaiting Assessment', `EventTime`: Timestamp when `state` becomes 'Assess'.
3.  `ActivityName`: 'Risk And Impact Assessed', `EventTime`: Timestamp when `state` changes from 'Assess' to 'Authorize'.
4.  `ActivityName`: 'Approval Requested', `EventTime`: `sys_created_on` from sysapproval_approver export where approval `state` is 'requested'.
5.  `ActivityName`: 'Change Approved', `EventTime`: `sys_updated_on` from sysapproval_approver export when final approval `state` becomes 'approved'.
6.  `ActivityName`: 'Change Rejected', `EventTime`: `sys_updated_on` from sysapproval_approver export when approval `state` becomes 'rejected'.
7.  `ActivityName`: 'Change Scheduled', `EventTime`: Timestamp when `state` becomes 'Scheduled'.
8.  `ActivityName`: 'Implementation Started', `EventTime`: Timestamp when `state` becomes 'Implement'.
9.  `ActivityName`: 'Change Implemented', `EventTime`: Timestamp when `state` changes from 'Implement' to 'Review'.
10. `ActivityName`: 'Review In Progress', `EventTime`: Timestamp when `state` becomes 'Review'.
11. `ActivityName`: 'Change Reopened', `EventTime`: Inferred from a non-linear state change (e.g., 'Review' back to 'Implement'). This is difficult to capture with this method and often requires manual inspection or analysis of audit data.
12. `ActivityName`: 'Change Closed', `EventTime`: Timestamp when `state` becomes 'Closed'.
13. `ActivityName`: 'Change Canceled', `EventTime`: Timestamp when `state` becomes 'Canceled'.

Étapes

Prérequis et authentification : vérifiez que vous disposez d’un compte utilisateur ServiceNow avec les rôles itil et rest_service. Ces rôles donnent les autorisations nécessaires pour lire les données des demandes de modification et utiliser l’API REST. Créez des identifiants pour ce compte, soit avec l’authentification de base (nom d’utilisateur et mot de passe), soit en configurant un client OAuth 2.0 pour un accès programmatique plus sécurisé.
Repérez votre instance ServiceNow : déterminez l’URL de votre instance ServiceNow, qui suit généralement le format https://[your-instance].service-now.com.
Préparez l’environnement d’extraction : configurez un environnement de script, par exemple Node.js ou Python, pour exécuter des scripts qui envoient des appels à l’API REST. L’exemple de requête fourni utilise JavaScript dans un environnement Node.js.
Récupérez les données initiales (demandes de modification) : commencez par interroger la table change_request. Utilisez le paramètre d’URL sysparm_query pour filtrer les demandes créées pendant la période d’analyse souhaitée (par exemple, sys_created_onBETWEENjavascript:gs.dateGenerate('YYYY-MM-DD','start')@javascript:gs.dateGenerate('YYYY-MM-DD','end')). Cet appel initial récupère les données de base de chaque dossier, notamment sys_id, number et l’horodatage de l’événement « Demande de modification créée » (sys_created_on).
Récupérez l’historique d’audit : pour chaque sys_id obtenu à l’étape précédente, appelez ensuite la table sys_audit via l’API. Filtrez les enregistrements d’audit pour lesquels tablename est « change_request » et documentkey correspond au sys_id de la demande de modification. Vous obtenez ainsi l’historique complet des changements de champs pour chaque dossier.
Traitez les données d’audit pour repérer les activités : parcourez les enregistrements sys_audit de chaque demande de modification. Votre script doit repérer les changements correspondant à des activités du processus. Par exemple, un enregistrement dont fieldname est « state » et newvalue est « Planifié » correspond à l’activité « Modification planifiée ». L’horodatage sys_created_on de l’enregistrement d’audit devient la valeur de EventTime.
Repérez les activités « Rouverte » : pour capturer les événements de réouverture, définissez la séquence standard des états (par exemple, Évaluer -> Autoriser -> Planifié -> Mettre en œuvre -> Réviser -> Clôturé). Comparez l’ordre des valeurs oldvalue et newvalue pour chaque changement d’état. Si le nouvel état précède l’ancien dans la séquence définie, créez une activité « Modification rouverte ».
Combinez et associez les données : regroupez les données de la table change_request (pour l’événement de création) et les données sys_audit traitées dans une liste unique. Associez les noms de champs ServiceNow aux noms de colonnes requis pour le journal d’événements, par exemple number à ChangeRequestNumber, sys_created_on à EventTime et le nom d’événement calculé à ActivityName.
Structurez le journal d’événements : mettez les données combinées en forme dans un journal d’événements structuré. Chaque ligne doit représenter une activité et contenir au minimum ChangeRequestNumber, ActivityName et EventTime.
Exportez au format CSV : enregistrez le journal d’événements final dans un fichier CSV. Vérifiez que le fichier comporte une ligne d’en-tête et utilise l’encodage UTF-8 pour être compatible avec ProcessMind lors de l’import et de l’analyse.

Configuration

Points de terminaison de l’API : les principales tables interrogées sont change_request et sys_audit. Les points de terminaison de l’API sont :
- https://[your-instance].service-now.com/api/now/table/change_request
- https://[your-instance].service-now.com/api/now/table/sys_audit
Authentification : le script utilise l’authentification de base pour simplifier la procédure. Dans un environnement de production, il est fortement recommandé d’utiliser OAuth 2.0 pour renforcer la sécurité. Si vous utilisez OAuth, le script doit être adapté pour gérer la récupération et le renouvellement des jetons.
Filtrage par période : il est essentiel d’appliquer un filtre de dates à la requête initiale sur la table change_request afin de limiter le volume de données. Une période de 3 à 12 mois est courante pour l’analyse par Process Mining. Exemple de filtre : sysparm_query=sys_created_on>=2023-01-01 00:00:00.
Sélection des champs (sysparm_fields) : pour améliorer les performances de l’API et réduire le trafic réseau, utilisez le paramètre sysparm_fields afin de ne demander que les colonnes nécessaires. Pour change_request, sélectionnez notamment sys_id, number, sys_created_on, assignment_group, type, priority, risk et cmdb_ci.
Gestion de la pagination : pour les grands jeux de données, ServiceNow renvoie les enregistrements par pages. Le script doit gérer la pagination à l’aide des paramètres sysparm_limit et sysparm_offset, en parcourant les pages jusqu’à la récupération de tous les enregistrements correspondant à la requête.
Prérequis pour la table d’audit : cette méthode repose entièrement sur la table sys_audit. Vérifiez que l’audit est activé pour la table change_request, notamment pour les champs state, approval et active, dont l’historique est nécessaire à la création du journal d’événements.

Exemple de requête javascript

const axios = require('axios');
const fs = require('fs');

// --- Configuration ---
const SN_INSTANCE = '[your-instance].service-now.com';
const SN_USER = '[your_username]';
const SN_PASSWORD = '[your_password]';
const START_DATE = '2023-01-01 00:00:00'; // Start date for changes to extract
const END_DATE = '2023-12-31 23:59:59';   // End date for changes to extract
const OUTPUT_FILE = 'servicenow_change_management_log.csv';

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

// Maps ServiceNow integer state values to human-readable names. Configure based on your system.
const STATE_MAP = {
    '-5': 'Draft',
    '-4': 'Assess',
    '-3': 'Authorize',
    '-2': 'Scheduled',
    '-1': 'Implement',
    '0': 'Review',
    '3': 'Closed',
    '4': 'Canceled',
    // Add any custom state values here
};

// Defines the standard process flow for detecting 'Reopened' events
const STATE_SEQUENCE = { 'Assess': 1, 'Authorize': 2, 'Scheduled': 3, 'Implement': 4, 'Review': 5, 'Closed': 6 };

// Function to fetch data with pagination
async function fetchAllRecords(table, query, fields) {
    let offset = 0;
    const limit = 1000;
    let allRecords = [];
    let hasMore = true;

    while (hasMore) {
        console.log(`Fetching ${table} records, offset: ${offset}`);
        const url = `https://${SN_INSTANCE}/api/now/table/${table}`;
        try {
            const response = await axios.get(url, {
                auth,
                params: {
                    sysparm_query: `${query}^sysparm_offset=${offset}^sysparm_limit=${limit}`,
                    sysparm_display_value: 'false', // Get raw values for mapping
                    sysparm_exclude_reference_link: true,
                    sysparm_fields: fields
                }
            });
            const records = response.data.result;
            if (records.length > 0) {
                allRecords = allRecords.concat(records);
                offset += limit;
            } else {
                hasMore = false;
            }
        } catch (error) {
            console.error(`Error fetching from ${table}:`, error.response ? error.response.data : error.message);
            hasMore = false;
        }
    }
    return allRecords;
}

// Main extraction function
async function extractChangeLog() {
    const eventLog = [];

    // 1. Get all change requests in the date range
    const changeQuery = `sys_created_on>=${START_DATE}^sys_created_on<=${END_DATE}`;
    const changeFields = 'sys_id,number,sys_created_on,assignment_group,type,priority,risk,cmdb_ci,state';
    const changes = await fetchAllRecords('change_request', changeQuery, changeFields);

    for (const change of changes) {
        // Activity: Change Request Created
        eventLog.push({
            ChangeRequestNumber: change.number,
            ActivityName: 'Change Request Created',
            EventTime: change.sys_created_on,
            ChangeState: STATE_MAP[change.state] || 'Unknown',
            AssignmentGroup: change.assignment_group,
            ChangeType: change.type,
            Priority: change.priority,
            RiskLevel: change.risk,
            ConfigurationItem: change.cmdb_ci
        });

        // 2. Get audit history for this change
        const auditQuery = `documentkey=${change.sys_id}^tablename=change_request^fieldnameINstate,approval`;
        const auditFields = 'sys_created_on,fieldname,oldvalue,newvalue';
        const auditRecords = await fetchAllRecords('sys_audit', auditQuery, auditFields);

        for (const audit of auditRecords) {
            let activityName = null;

            if (audit.fieldname === 'state') {
                const oldStateName = STATE_MAP[audit.oldvalue] || audit.oldvalue;
                const newStateName = STATE_MAP[audit.newvalue] || audit.newvalue;

                switch (newStateName) {
                    case 'Assess': activityName = 'Change Awaiting Assessment'; break;
                    case 'Authorize': activityName = 'Risk And Impact Assessed'; break;
                    case 'Scheduled': activityName = 'Change Scheduled'; break;
                    case 'Implement': activityName = 'Implementation Started'; break;
                    case 'Review':
                        // Per requirements, create two distinct events for the same timestamp
                        eventLog.push({ ...change, ActivityName: 'Change Implemented', EventTime: audit.sys_created_on, ChangeState: newStateName });
                        eventLog.push({ ...change, ActivityName: 'Review In Progress', EventTime: audit.sys_created_on, ChangeState: newStateName });
                        continue; // Skip the generic push at the end
                    case 'Closed': activityName = 'Change Closed'; break;
                    case 'Canceled': activityName = 'Change Canceled'; break;
                }
                // Check for 'Reopened' event
                if (STATE_SEQUENCE[oldStateName] && STATE_SEQUENCE[newStateName] && STATE_SEQUENCE[newStateName] < STATE_SEQUENCE[oldStateName]) {
                    eventLog.push({ ...change, ActivityName: 'Change Reopened', EventTime: audit.sys_created_on, ChangeState: newStateName });
                }

            } else if (audit.fieldname === 'approval') {
                if (audit.newvalue === 'requested') activityName = 'Approval Requested';
                if (audit.newvalue === 'approved') activityName = 'Change Approved';
                if (audit.newvalue === 'rejected') activityName = 'Change Rejected';
            }

            if (activityName) {
                eventLog.push({
                    ChangeRequestNumber: change.number,
                    ActivityName: activityName,
                    EventTime: audit.sys_created_on,
                    ChangeState: STATE_MAP[change.state] || 'Unknown', // Use the final state of the change for context
                    AssignmentGroup: change.assignment_group,
                    ChangeType: change.type,
                    Priority: change.priority,
                    RiskLevel: change.risk,
                    ConfigurationItem: change.cmdb_ci
                });
            }
        }
    }

    // 3. Convert to CSV and save
    if (eventLog.length > 0) {
        const header = Object.keys(eventLog[0]).join(',');
        const rows = eventLog.map(row => Object.values(row).map(val => `"${val || ''}"`).join(','));
        fs.writeFileSync(OUTPUT_FILE, `${header}\n${rows.join('\n')}`);
        console.log(`Extraction complete. Saved ${eventLog.length} events to ${OUTPUT_FILE}`);
    } else {
        console.log('No events found for the specified criteria.');
    }
}

extractChangeLog();

Étapes

Prérequis : vérifiez que Python 3.6 ou une version ultérieure est installé sur votre système. Installez les bibliothèques Python nécessaires en exécutant pip install requests pandas dans l’invite de commandes ou le terminal.
Configurez un utilisateur API ServiceNow : dans ServiceNow, créez un compte de service dédié à cette extraction. Attribuez-lui au minimum le rôle itil, qui donne un accès en lecture à la table change_request. Pour accéder aux données historiques, l’utilisateur doit également disposer d’un accès en lecture aux tables sys_audit et sysapproval_approver. Si nécessaire, attribuez-lui le rôle rest_api_explorer pour faciliter les tests.
Configurez le script Python : téléchargez le script Python fourni. Ouvrez le fichier et remplacez les variables fictives en haut du script : SERVICENOW_INSTANCE, SERVICENOW_USER et SERVICENOW_PASSWORD, par l’URL de votre instance et les identifiants de l’utilisateur créé à l’étape précédente.
Définissez les paramètres d’extraction : modifiez la variable sysparm_query dans le script pour définir la période et le périmètre de l’extraction. Elle est déjà configurée pour récupérer les demandes de modification mises à jour au cours des 180 derniers jours. Vous pouvez ajuster la période ou ajouter d’autres filtres, comme active=true ou des codes d’entreprise spécifiques, pour réduire le nombre de résultats.
Exécutez le script : lancez le script depuis votre terminal avec la commande python your_script_name.py. Le script se connecte à l’API REST de ServiceNow, s’authentifie, puis récupère les demandes de modification, leurs changements d’état et leur historique d’approbation.
Gérez la pagination : le script gère automatiquement la pagination en effectuant plusieurs appels à l’API lorsque le nombre d’enregistrements dépasse la limite par page définie par ServiceNow. Il affiche la progression dans la console.
Transformez les données : le script traite en mémoire les réponses brutes de l’API. Il repère les événements clés, comme la création, les transitions d’état et les approbations. Il associe ensuite ces événements système aux valeurs ActivityName compréhensibles requises dans le journal d’événements, par exemple « Modification en attente d’évaluation » ou « Modification approuvée ».
Regroupez le journal d’événements : tous les événements sont réunis dans un DataFrame pandas structuré. Celui-ci contient les attributs requis et recommandés pour chaque événement et constitue une chronologie complète de chaque demande de modification.
Vérifiez le résultat : une fois le script exécuté, il crée dans le même répertoire un fichier CSV nommé servicenow_change_management_log.csv. Ouvrez-le pour vérifier les données extraites.
Préparez l’import : le fichier CSV généré respecte les spécifications du journal d’événements de ProcessMind. Aucune autre mise en forme n’est nécessaire. Le fichier est prêt à être importé.

Configuration

Authentification : le script utilise l’authentification de base avec un nom d’utilisateur et un mot de passe. Pour renforcer la sécurité, vous pouvez modifier le script afin qu’il utilise OAuth 2.0, également pris en charge par ServiceNow.
Points de terminaison ServiceNow : le script utilise principalement trois points de terminaison de l’API REST : /api/now/table/change_request pour les données principales des modifications, /api/now/table/sys_audit pour l’historique des changements de champs, notamment le champ « state », et /api/now/table/sysapproval_approver pour les événements d’approbation et de rejet.
Filtrage par période : la période est définie par le paramètre sysparm_query de la requête API adressée à la table change_request. Il est recommandé d’extraire les données sur une période de 3 à 6 mois afin de trouver un équilibre entre le niveau de détail et les performances. Une requête telle que sys_updated_on>=javascript:gs.daysAgo(180) constitue un bon point de départ.
Limitation du nombre d’enregistrements : le script récupère les enregistrements par lots à l’aide du paramètre sysparm_limit, afin de ne pas surcharger l’API. La fonction get_all_records gère automatiquement les boucles et les décalages.
Prérequis : un compte utilisateur ServiceNow disposant au minimum du rôle itil est nécessaire. L’accès en lecture aux tables sys_audit et sysapproval_approver est également requis. Si votre instance ServiceNow utilise des rôles personnalisés, vérifiez que l’utilisateur peut lire tous les champs extraits de ces tables.
Performances : les requêtes adressées à la table sys_audit peuvent solliciter fortement votre instance ServiceNow. Il est conseillé d’effectuer les extractions volumineuses en dehors des heures de pointe et d’appliquer des filtres de dates stricts pour limiter leur impact sur les performances.

Exemple de requête python

import requests
import pandas as pd
import getpass
from datetime import datetime

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Enter your ServiceNow instance URL, for example, https://your-instance.service-now.com
SERVICENOW_INSTANCE = class="hl-string">"[Your ServiceNow Instance URL]"
SERVICENOW_USER = class="hl-string">"[Your ServiceNow API Username]"
class=class="hl-string">"hl-comment"># It is recommended to use a secure method for password management, such as environment variables or a secrets manager.
SERVICENOW_PASSWORD = getpass.getpass(class="hl-string">"Enter ServiceNow Password: ")

class=class="hl-string">"hl-comment"># --- State and Approval Mapping ---
class=class="hl-string">"hl-comment"># Maps ServiceNow integer state values to human-readable activity names
STATE_MAP = {
    class="hl-string">'-4': class="hl-string">'Change Awaiting Assessment',
    class="hl-string">'-3': class="hl-string">'Risk And Impact Assessed', class=class="hl-string">"hl-comment"># Mapped from leaving Assess state
    class="hl-string">'-2': class="hl-string">'Change Scheduled',
    class="hl-string">'-1': class="hl-string">'Implementation Started',
    class="hl-string">'0': class="hl-string">'Review In Progress',
    class="hl-string">'3': class="hl-string">'Change Closed',
    class="hl-string">'4': class="hl-string">'Change Canceled'
}

class=class="hl-string">"hl-comment"># Function to handle pagination and fetch all records from an endpoint
def get_all_records(endpoint, query_params):
    records = []
    offset = 0
    limit = 1000
    while True:
        query_params[class="hl-string">'sysparm_offset'] = str(offset)
        query_params[class="hl-string">'sysparm_limit'] = str(limit)
        response = requests.get(endpoint, auth=(SERVICENOW_USER, SERVICENOW_PASSWORD), params=query_params)
        response.raise_for_status()
        data = response.json().get(class="hl-string">'result', [])
        if not data:
            break
        records.extend(data)
        offset += limit
        print(fclass="hl-string">"Fetched {len(records)} records from {endpoint.split('/')[-1]}...")
    return records

def main():
    print(class="hl-string">"Starting ServiceNow Change Management data extraction...")
    event_log = []

    class=class="hl-string">"hl-comment"># 1. Fetch Change Request base data
    print(class="hl-string">"\nStep 1: Fetching core Change Request data...")
    cr_endpoint = fclass="hl-string">"{SERVICENOW_INSTANCE}/api/now/table/change_request"
    cr_params = {
        class="hl-string">'sysparm_display_value': class="hl-string">'true',
        class="hl-string">'sysparm_fields': class="hl-string">'number,sys_id,sys_created_on,sys_updated_on,state,assignment_group,type,priority,risk,cmdb_ci',
        class="hl-string">'sysparm_query': class="hl-string">'sys_updated_on>=javascript:gs.daysAgo(180)' class=class="hl-string">"hl-comment"># Adjust date range as needed
    }
    change_requests = get_all_records(cr_endpoint, cr_params)
    
    if not change_requests:
        print(class="hl-string">"No change requests found for the specified period. Exiting.")
        return

    cr_sys_ids = [cr[class="hl-string">'sys_id'] for cr in change_requests]
    cr_map = {cr[class="hl-string">'sys_id']: cr for cr in change_requests}
    cr_id_query_part = class="hl-string">'^documentkeyIN' + class="hl-string">','.join(cr_sys_ids)

    class=class="hl-string">"hl-comment"># 2. Fetch all relevant Audit (sys_audit) records for state changes
    print(class="hl-string">"\nStep 2: Fetching audit history for state changes...")
    audit_endpoint = fclass="hl-string">"{SERVICENOW_INSTANCE}/api/now/table/sys_audit"
    audit_params = {
        class="hl-string">'sysparm_display_value': class="hl-string">'false', class=class="hl-string">"hl-comment"># We need the integer state values
        class="hl-string">'sysparm_fields': class="hl-string">'documentkey,sys_created_on,oldvalue,newvalue',
        class="hl-string">'sysparm_query': fclass="hl-string">'tablename=change_request^fieldname=state^{cr_id_query_part}'
    }
    audit_records = get_all_records(audit_endpoint, audit_params)

    class=class="hl-string">"hl-comment"># 3. Fetch all relevant Approval (sysapproval_approver) records
    print(class="hl-string">"\nStep 3: Fetching approval history...")
    approval_endpoint = fclass="hl-string">"{SERVICENOW_INSTANCE}/api/now/table/sysapproval_approver"
    approval_params = {
        class="hl-string">'sysparm_display_value': class="hl-string">'true',
        class="hl-string">'sysparm_fields': class="hl-string">'sysapproval,sys_created_on,sys_updated_on,state',
        class="hl-string">'sysparm_query': fclass="hl-string">'sysapprovalIN' + class="hl-string">','.join(cr_sys_ids)
    }
    approval_records = get_all_records(approval_endpoint, approval_params)

    print(class="hl-string">"\nStep 4: Transforming data into event log format...")
    class=class="hl-string">"hl-comment"># Process each change request to build the event log
    for cr_id, cr_data in cr_map.items():
        base_attributes = {
            class="hl-string">'ChangeRequestNumber': cr_data.get(class="hl-string">'number'),
            class="hl-string">'ChangeState': cr_data.get(class="hl-string">'state'),
            class="hl-string">'AssignmentGroup': cr_data.get(class="hl-string">'assignment_group'),
            class="hl-string">'ChangeType': cr_data.get(class="hl-string">'type'),
            class="hl-string">'Priority': cr_data.get(class="hl-string">'priority'),
            class="hl-string">'RiskLevel': cr_data.get(class="hl-string">'risk'),
            class="hl-string">'ConfigurationItem': cr_data.get(class="hl-string">'cmdb_ci')
        }

        class=class="hl-string">"hl-comment"># Event: Change Request Created
        event_log.append({
            **base_attributes,
            class="hl-string">'ActivityName': class="hl-string">'Change Request Created',
            class="hl-string">'EventTime': cr_data.get(class="hl-string">'sys_created_on'),
            class="hl-string">'EndTime': None
        })
        
        class=class="hl-string">"hl-comment"># Events from Audit History (State Changes)
        cr_audit_records = sorted([r for r in audit_records if r[class="hl-string">'documentkey'] == cr_id], key=lambda x: x[class="hl-string">'sys_created_on'])
        
        last_state = None
        for audit in cr_audit_records:
            new_state = audit[class="hl-string">'newvalue']
            old_state = audit[class="hl-string">'oldvalue']
            event_time = audit[class="hl-string">'sys_created_on']

            class=class="hl-string">"hl-comment"># Activity: Risk and Impact Assessed (when moving out of Assess state)
            if old_state == class="hl-string">'-4': class=class="hl-string">"hl-comment"># Assess
                 event_log.append({
                    **base_attributes,
                    class="hl-string">'ActivityName': class="hl-string">'Risk And Impact Assessed',
                    class="hl-string">'EventTime': event_time,
                    class="hl-string">'EndTime': None
                })

            class=class="hl-string">"hl-comment"># Map new state to activity
            if new_state in STATE_MAP:
                event_log.append({
                    **base_attributes,
                    class="hl-string">'ActivityName': STATE_MAP[new_state],
                    class="hl-string">'EventTime': event_time,
                    class="hl-string">'EndTime': None
                })
            
            class=class="hl-string">"hl-comment"># Activity: Change Reopened (non-linear transition, e.g., Review (0) -> Implement (-1))
            if old_state and new_state and int(old_state) > int(new_state):
                class=class="hl-string">"hl-comment"># Basic check for moving to a numerically lower state, indicating rework
                if not (old_state == class="hl-string">'3' and new_state == class="hl-string">'0'): class=class="hl-string">"hl-comment"># Exclude closed to review which might be valid
                    event_log.append({
                        **base_attributes,
                        class="hl-string">'ActivityName': class="hl-string">'Change Reopened',
                        class="hl-string">'EventTime': event_time,
                        class="hl-string">'EndTime': None
                    })
            last_state = new_state

        class=class="hl-string">"hl-comment"># Events from Approval History
        cr_approval_records = sorted([r for r in approval_records if r[class="hl-string">'sysapproval'][class="hl-string">'value'] == cr_id], key=lambda x: x[class="hl-string">'sys_created_on'])
        for approval in cr_approval_records:
            class=class="hl-string">"hl-comment"># Activity: Approval Requested
            event_log.append({
                **base_attributes,
                class="hl-string">'ActivityName': class="hl-string">'Approval Requested',
                class="hl-string">'EventTime': approval[class="hl-string">'sys_created_on'],
                class="hl-string">'EndTime': None
            })

            class=class="hl-string">"hl-comment"># Activity: Change Approved or Rejected
            if approval[class="hl-string">'state'] == class="hl-string">'Approved':
                event_log.append({
                    **base_attributes,
                    class="hl-string">'ActivityName': class="hl-string">'Change Approved',
                    class="hl-string">'EventTime': approval[class="hl-string">'sys_updated_on'],
                    class="hl-string">'EndTime': None
                })
            elif approval[class="hl-string">'state'] == class="hl-string">'Rejected':
                event_log.append({
                    **base_attributes,
                    class="hl-string">'ActivityName': class="hl-string">'Change Rejected',
                    class="hl-string">'EventTime': approval[class="hl-string">'sys_updated_on'],
                    class="hl-string">'EndTime': None
                })

    print(fclass="hl-string">"Transformation complete. Total events created: {len(event_log)}")

    class=class="hl-string">"hl-comment"># 5. Create and Save DataFrame
    if not event_log:
        print(class="hl-string">"No events were generated. The output file will be empty.")
        return

    print(class="hl-string">"\nStep 5: Saving event log to CSV file...")
    df = pd.DataFrame(event_log)
    df[class="hl-string">'EventTime'] = pd.to_datetime(df[class="hl-string">'EventTime'])
    df = df.sort_values(by=[class="hl-string">'ChangeRequestNumber', class="hl-string">'EventTime'])

    class=class="hl-string">"hl-comment"># Calculate EndTime as the start of the next event for the same case
    df[class="hl-string">'EndTime'] = df.groupby(class="hl-string">'ChangeRequestNumber')[class="hl-string">'EventTime'].shift(-1)
    
    class=class="hl-string">"hl-comment"># Reorder columns for clarity
    column_order = [
        class="hl-string">'ChangeRequestNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'EndTime', class="hl-string">'ChangeState',
        class="hl-string">'AssignmentGroup', class="hl-string">'ChangeType', class="hl-string">'Priority', class="hl-string">'RiskLevel', class="hl-string">'ConfigurationItem'
    ]
    df = df[column_order]

    output_filename = class="hl-string">'servicenow_change_management_log.csv'
    df.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%d %H:%M:%S')
    print(fclass="hl-string">"Successfully saved event log to {output_filename}")

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

Prêt à commencer ?

Utilisez ce modèle pour préparer vos données et mieux comprendre votre processus de gestion du changement dans ServiceNow. Commencez dès aujourd’hui à améliorer son efficacité.

Retour au guide d’amélioration

Télécharger le modèle

Évitez les échecs de modification et améliorez dès maintenant vos résultats dans ServiceNow !

Repérez les goulots d’étranglement pour atteindre facilement un taux de réussite des modifications de 95 %.

Démarrer l’essai gratuit

Aucune carte bancaire requise. Configuration en quelques minutes.

Votre modèle de données pour la gestion du changement

Votre modèle de données pour la gestion du changement

Attributs de gestion du changement

Activités de gestion du changement

Guides d’extraction

Export de la vue en liste ServiceNow au format CSV/XLS

Étapes

Configuration

Exemple de requête config

Extraction via l’API Table de ServiceNow à l’aide de requêtes REST

Étapes

Configuration

Exemple de requête javascript

Extraction avec un script Python via l’API REST de ServiceNow

Étapes

Configuration

Exemple de requête python

Prêt à commencer ?

Évitez les échecs de modification et améliorez dès maintenant vos résultats dans ServiceNow !

Votre modèle de données pour la gestion du changement

Votre modèle de données pour la gestion du changement

Attributs de gestion du changement

Activités de gestion du changement

Guides d’extraction

Export de la vue en liste ServiceNow au format CSV/XLS

Étapes

Configuration

Exemple de requête config

Extraction via l’API Table de ServiceNow à l’aide de requêtes REST

Étapes

Configuration

Exemple de requête javascript

Extraction avec un script Python via l’API REST de ServiceNow

Étapes

Configuration

Exemple de requête python

Prêt à commencer ?

Évitez les échecs de modification et améliorez dès maintenant vos résultats dans ServiceNow !

Prêt à commencer ?

Évitez les échecs de modification et améliorez dès maintenant vos résultats dans ServiceNow !