Votre modèle de données de Gestion du changement

ServiceNow
Votre modèle de données de Gestion du changement

Votre modèle de données de Gestion du changement

Ce modèle propose une méthode structurée pour recueillir les données essentielles à un Process Mining efficace de votre flux de travail de Gestion du changement. Il présente les attributs et les activités recommandés à suivre, ainsi que des conseils pratiques pour extraire les données. Utilisez cette ressource pour préparer vos données en vue d’une analyse complète et d’une optimisation du processus.
  • Attributs recommandés à collecter
  • Activités clés à suivre pour une découverte précise du processus
  • Conseils pour extraire les données de ServiceNow
Vous découvrez les journaux d’événements ? En savoir plus sur la création d’un journal d’événements pour le Process Mining.

Attributs de la Gestion du changement

Voici les champs de données recommandés à inclure dans votre journal d’événements pour analyser votre processus de Gestion du changement de manière complète.
3 Obligatoire 7 Recommandé 9 Facultatif
Nom Description
Heure de l’événement
EventTime
Horodatage précis auquel une activité ou un événement spécifique s’est produit.
Description

L’heure de l’événement enregistre la date et l’heure exactes auxquelles une activité a été réalisée ou une modification de statut enregistrée. Cet horodatage est essentiel pour classer les événements dans l’ordre chronologique et pour toutes les analyses fondées sur la durée.

Dans le Process Mining, cet attribut permet de calculer les délais de cycle, les temps de traitement et les temps d’attente entre les activités. Il est indispensable aux Dashboards qui analysent la performance, tels que « Change Approval Cycle Time » et « End-to-End Change Process Flow ». Des horodatages précis sont indispensables pour identifier les retards et mesurer l’efficacité du processus au regard des SLA.

Pourquoi c’est important

Cet horodatage est essentiel pour ordonner correctement les événements et calculer tous les indicateurs temporels, notamment les délais de cycle, les durées et le respect des SLA.

Où les obtenir

Table ServiceNow : sys_audit, champ : sys_created_on. Ce champ fournit l’horodatage 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 identifiant principal du cas pour regrouper tous les événements associés.
Description

L’identifiant de la demande de changement constitue la base de l’analyse du processus de Gestion du changement. Il s’agit d’un numéro unique attribué à chaque demande, tel que « CHG0030001 », qui relie l’ensemble des activités, approbations et tâches.

Dans le Process Mining, cet attribut sert à reconstituer le parcours de bout en bout de chaque changement. Il permet aux analystes de suivre l’intégralité du cycle de vie, de la création à la clôture, et d’obtenir une vision cohérente de la progression de chaque changement dans le système. Le regroupement des processus selon cet identifiant est essentiel pour calculer les délais de cycle, identifier les boucles de reprise et comprendre les variantes du processus.

Pourquoi c’est important

Cet identifiant est essentiel pour suivre l’intégralité du cycle de vie d’un changement et analyser complètement le flux du processus, sa durée et sa conformité pour chaque demande.

Où les obtenir

Table ServiceNow : change_request, champ : number

Exemples
CHG0030001CHG0030045CHG0030112
Nom de l’activité
ActivityName
Nom d’un événement ou d’une tâche spécifique survenu dans le processus de Gestion du changement.
Description

Le nom de l’activité décrit une étape distincte ou une modification d’état dans le cycle de vie d’une demande de changement. Parmi les exemples figurent « Change Awaiting Assessment », « Approval Requested » et « Change Implemented ». Ces activités constituent les nœuds de la carte de processus découverte.

L’analyse de ces activités permet d’examiner en détail le flux du processus. En suivant leur séquence et leur fréquence, les organisations peuvent identifier les parcours courants, les écarts par rapport au processus standard et les goulots d’étranglement où les changements restent fréquemment bloqués. Cet attribut est fondamental pour visualiser le processus et calculer des indicateurs tels que les délais de transition entre les étapes.

Pourquoi c’est important

Il constitue l’ossature de la carte de processus, en permettant de visualiser le flux du processus, d’identifier les goulots d’étranglement et d’analyser les écarts.

Où les obtenir

Dérivé des modifications du champ « state » ou d’autres champs de statut clés 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 précis 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) qui sera affecté 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 fournit un contexte essentiel sur le changement. Dans le Process Mining, il permet de segmenter l’analyse selon le type d’actif modifié. Par exemple, le Dashboard « Change Testing Duration Analysis » utilise cet attribut pour comparer les durées de test de différentes applications ou systèmes et identifier les éléments de configuration associés aux cycles de test les plus longs.

Pourquoi c’est important

Il fournit un contexte métier essentiel et permet de filtrer l’analyse selon l’application, le service ou le système concerné afin d’identifier les problèmes propres à chaque composant.

Où les obtenir

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, tel que « Assess », « Authorize », « Implement » ou « Closed ».
Description

L’attribut État du changement représente le statut d’une demande de changement à un moment donné. Il fournit une vue synthétique de la position du changement dans son cycle de vie. Contrairement à l’activité, qui représente un événement précis, l’état correspond à la situation résultant de cet événement.

Dans l’analyse, l’état du changement sert à catégoriser les cas et à comprendre leurs résultats. Il est essentiel pour filtrer les changements, par exemple afin d’analyser uniquement les changements « Closed » ou d’examiner pourquoi de nombreuses demandes restent bloquées à l’état « Authorize ». Il contribue directement à des KPI tels que « Change Failure Rate » lorsqu’un état « Failed » existe.

Pourquoi c’est important

Il fournit une vue instantanée du statut de la demande de changement, ce qui permet d’analyser les résultats, de filtrer les cas et d’identifier les changements bloqués.

Où les obtenir

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 « CAB Approval », « Network Engineering » ou « Database Administrators ». Il s’agit d’une dimension essentielle pour analyser la performance du processus dans les différents domaines fonctionnels.

Cet attribut sert à mesurer l’efficacité au niveau de l’équipe, à identifier les goulots d’étranglement propres à certains groupes et à analyser l’efficacité des transmissions entre équipes. Des Dashboards tels que « Cross-Functional Handoff Efficiency » et « Change Implementation Throughput » s’appuient largement sur ces données pour localiser les retards liés aux dépendances entre équipes.

Pourquoi c’est important

Il permet d’analyser la performance par équipe, de mettre en évidence les goulots d’étranglement propres à certains groupes et de mesurer l’efficacité des transmissions entre différents domaines fonctionnels.

Où les obtenir

Table ServiceNow : change_request, champ : assignment_group

Exemples
Approbation du CABÉquipe réseauSupport serveursAdministrateurs de bases de données
Heure de fin
EndTime
Horodatage auquel une activité s’est terminée. Il est souvent déduit de l’heure de début de l’activité suivante.
Description

L’heure de fin marque l’achèvement d’une activité. Les systèmes sources enregistrent souvent le début d’un événement, tandis que l’heure de 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 essentiel pour calculer la durée de chaque activité, appelée temps de traitement. Comprendre la durée de chaque étape est fondamental pour identifier 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 c’est important

Il permet de calculer le temps de traitement des activités, ce qui est essentiel pour identifier les goulots d’étranglement et mesurer la durée d’étapes précises du processus.

Où les obtenir

Cet attribut est généralement calculé lors de la transformation des données en utilisant le 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é du changement, par exemple « High », « Moderate » ou « Low ».
Description

Le niveau de risque est le résultat du processus d’évaluation des risques d’une demande de changement. Il quantifie les conséquences négatives potentielles de la mise en œuvre du changement et contribue à déterminer le niveau de contrôle et d’approbation requis.

Cet attribut est essentiel au Dashboard « Risk Assessment Standardization », qui permet de vérifier que des changements similaires reçoivent des niveaux de risque cohérents. L’analyse des flux de processus par niveau de risque peut également révéler si les changements à risque élevé suivent correctement un parcours d’approbation et de test plus rigoureux que les changements à faible risque, ce qui constitue un contrôle important de conformité.

Pourquoi c’est important

Il est essentiel pour l’analyse de la conformité et pour vérifier que les changements à risque élevé font l’objet du niveau de contrôle approprié et suivent un processus plus rigoureux.

Où les obtenir

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 calculée à partir de l’impact et de l’urgence du changement, avec des valeurs telles que « Critical », « High », « Moderate » et « Low ».

L’analyse par priorité est essentielle pour vérifier que les changements prioritaires sont traités plus rapidement que les changements de faible priorité. Elle alimente le Dashboard « Critical Change Performance » en permettant aux analystes de suivre les délais de cycle et les taux d’échec des changements les plus importants. Si des changements de faible priorité sont achevés plus rapidement que des changements prioritaires, cela peut révéler un problème d’allocation des ressources ou d’exécution du processus.

Pourquoi c’est important

Cet attribut est essentiel pour vérifier que les ressources sont correctement affectées aux changements les plus importants et pour suivre séparément leur performance.

Où les obtenir

Table ServiceNow : change_request, champ : priority

Exemples
1 - Critique2 - Élevé3 - Modéré4 - Faible
Type de changement
ChangeType
Classification du changement, par exemple « Standard », « Normal » ou « Emergency ».
Description

Le type de changement catégorise la demande selon sa nature, son niveau de risque et ses exigences d’approbation. Les changements standard sont préapprouvés, les changements normaux suivent le processus complet et les changements urgents empruntent un parcours accéléré.

Il s’agit d’une dimension fondamentale pour l’analyse des processus, car chaque type de changement possède un modèle de processus autorisé qui lui est propre. La comparaison de la performance des changements normaux et urgents peut révéler des écarts importants en matière de respect du processus et d’efficacité. Cet attribut est également utilisé dans des Dashboards tels que « Risk Assessment Standardization » afin de garantir un traitement cohérent des changements similaires.

Pourquoi c’est important

Il 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 spécifiques.

Où les obtenir

Table ServiceNow : change_request, champ : type

Exemples
StandardNormalUrgence
Code de clôture
CloseCode
Code indiquant le résultat obtenu lors de la clôture de la demande de changement, par exemple « Successful » ou « Unsuccessful ».
Description

Le code de clôture fournit le résultat final d’une demande de changement terminée. Il indique officiellement si le changement a été mis en œuvre avec succès, avec des problèmes, ou s’il a été restauré.

Cet attribut alimente directement le KPI « Change Failure Rate ». En analysant la répartition des codes de clôture, les organisations peuvent quantifier la réussite de leurs initiatives de changement. Le filtrage de la carte de processus sur les changements dont le code de clôture est « Unsuccessful » constitue une méthode efficace d’analyse des causes profondes, car il révèle les schémas de processus fréquemment associés aux échecs.

Pourquoi c’est important

Il mesure directement le résultat d’un changement et fournit les données nécessaires au calcul du taux d’échec des changements ainsi qu’à l’analyse des causes profondes des échecs.

Où les obtenir

Table ServiceNow : change_request, champ : close_code

Exemples
RéussiRéussi avec des problèmesÉchec / Annulé et restauré
Dernière mise à jour des données
LastDataUpdate
Horodatage indiquant le moment où les données de cet enregistrement ont été actualisées pour la dernière fois depuis le système source.
Description

Cet attribut fournit l’horodatage de la dernière extraction des données. Il s’agit d’un champ de métadonnées essentiel pour évaluer l’actualité des données analysées.

Les analystes utilisent cet horodatage pour vérifier qu’ils travaillent avec des informations à jour et connaître leur ancienneté. Il est particulièrement important pour les Dashboards opérationnels qui suivent la performance actuelle des processus, afin que les décisions ne reposent pas sur des données obsolètes.

Pourquoi c’est important

Il indique l’actualité des données et garantit que les analyses et les Dashboards reposent sur des informations actuelles et pertinentes.

Où les obtenir

Il s’agit d’un champ de métadonnées généré lors du processus d’extraction et de transformation des données (ETL), qui indique le moment de leur extraction.

Exemples
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
Est une reprise
IsRework
Indicateur booléen égal à true lorsqu’une activité correspond à la répétition d’une étape précédente dans le même cas.
Description

Cet attribut calculé identifie les activités qui constituent une reprise. Une reprise se produit lorsque le processus doit revenir à une étape déjà terminée, par exemple lorsqu’un changement est rejeté après approbation et renvoyé pour une nouvelle évaluation.

Cet indicateur est essentiel pour quantifier l’inefficacité du processus. Il contribue directement au KPI « Change Rework Rate » et au Dashboard « Change Failure and Rework Analysis ». En filtrant les activités pour lesquelles « Is Rework » vaut true, les analystes peuvent isoler et étudier les causes des reprises, telles que des évaluations initiales incomplètes ou l’évolution des exigences, puis prendre des mesures pour réduire les efforts inutiles.

Pourquoi c’est important

Il quantifie directement l’inefficacité du processus en signalant les travaux répétés, ce qui aide à identifier et à traiter les causes profondes des boucles de processus et des efforts inutiles.

Où les obtenir

Calculé lors de la transformation des données en détectant si la même activité, ou une activité antérieure du flux standard, s’est déjà produite pour le CaseId concerné.

Exemples
truefalse
État du SLA
SlaState
Le statut de la demande de changement par rapport à son accord de niveau de service (SLA), par exemple « Dans les délais », « À risque » ou « En dépassement ».
Description

L'état du SLA indique si la demande de changement progresse dans les délais définis par son SLA. Ce statut peut être suivi à chaque étape du processus.

Cet attribut est essentiel pour contrôler le respect des engagements de niveau de service. Il constitue la principale source de données du Dashboard « Vue d'ensemble des performances des SLA de changement » et du KPI « Taux de respect des SLA de changement ». L'analyse des situations dans lesquelles les SLA sont dépassés, ainsi que de leurs causes, permet à l'organisation de traiter les retards systémiques et d'améliorer la prévisibilité de la prestation de services.

Pourquoi c’est important

Fournit une mesure directe des performances par rapport aux échéances, afin de surveiller de manière proactive les dépassements de SLA et de les analyser pour améliorer la prestation de services.

Où les obtenir

Ces données peuvent provenir de la table « task_sla » dans ServiceNow, qui suit les SLA associés à des tâches telles que les demandes de changement, ou être calculées à partir des champs de date d'échéance.

Exemples
Dans les délaisÀ risqueDélai dépassé
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 l’effet potentiel sur l’entreprise si la demande de changement n’est pas traitée correctement. Avec l’urgence, il constitue un élément essentiel pour déterminer la priorité globale du changement.

L’analyse par impact permet de vérifier que les changements affectant des services essentiels sont gérés avec le niveau d’attention approprié. Elle est utilisée dans le Dashboard « Critical Change Performance » pour isoler et suivre les changements ayant un impact métier élevé. Elle sert également à vérifier la cohérence de l’évaluation des risques, afin que les changements à fort impact ne reçoivent pas un niveau de risque faible sans justification.

Pourquoi c’est important

Il aide à prioriser les changements selon leur effet potentiel sur l’activité et permet de vérifier que les changements à fort impact sont gérés avec la diligence requise.

Où les obtenir

Table ServiceNow : change_request, champ : impact

Exemples
1 - Élevé2 - Moyen3 - Faible
Système source
SourceSystem
Système depuis lequel les données ont été extraites, généralement « ServiceNow ».
Description

Cet attribut identifie l’origine des données du processus. Dans ce cas, il devrait s’agir de ServiceNow, mais ce champ est essentiel pour la gouvernance des données et dans les scénarios où des données provenant de plusieurs systèmes sont regroupées.

Dans l’analyse, il garantit la traçabilité de l’origine des données et facilite leur validation. 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 c’est important

Il assure une traçabilité claire des données en documentant leur origine, ce qui est essentiel pour la gouvernance des données et l’analyse de plusieurs systèmes.

Où les obtenir

Il s’agit généralement d’une valeur statique ajoutée lors du processus d’extraction et de transformation des données (ETL).

Exemples
ServiceNowServiceNow_PRODSNOW_ITSM
Temps de cycle
CycleTime
Durée totale écoulée entre la création et la clôture d'une demande de changement.
Description

Le temps de cycle est une métrique au niveau du dossier qui mesure la durée totale du cycle de vie d'une demande de changement. Il est calculé comme la différence entre l'horodatage du tout premier événement et celui du tout dernier événement pour une demande de changement donnée.

Il s'agit d'un KPI essentiel pour mesurer la vitesse globale du processus. Il est utilisé dans le Dashboard « Flux de bout en bout du processus de changement » afin de fournir une vue d'ensemble des performances du processus. L'analyse des tendances du temps de cycle et leur comparaison selon différentes dimensions, telles que le type de changement ou la priorité, aide les organisations à repérer des possibilités d'amélioration stratégique du processus.

Pourquoi c’est important

Mesure la durée de bout en bout du processus de changement et fournit un indicateur clé de sa vitesse et de son efficacité globales.

Où les obtenir

Calculé au niveau du dossier lors de l'analyse des données, en soustrayant le StartTime minimal du StartTime maximal pour chaque CaseId.

Exemples
60480012096002592000
Urgence
Urgency
Vitesse à laquelle un changement doit être traité, évaluée selon une échelle telle que Élevée, Moyenne ou Faible.
Description

L’urgence définit la rapidité avec laquelle un changement doit être mis en œuvre. Elle reflète la sensibilité temporelle de la demande du point de vue métier. Avec l’impact, elle sert à calculer la priorité globale.

La priorité est le principal champ utilisé pour l’analyse, mais l’urgence apporte un contexte complémentaire. Elle peut servir à examiner pourquoi certains changements sont qualifiés d’urgents et si le processus les traite efficacement sans compromettre la stabilité. Elle permet notamment de déterminer si l’organisation fonctionne trop souvent dans un mode réactif caractérisé par un niveau d’urgence élevé.

Pourquoi c’est important

Il précise la sensibilité temporelle d’un changement et permet d’analyser la capacité du processus à traiter efficacement les demandes urgentes.

Où les obtenir

Table ServiceNow : change_request, champ : urgency

Exemples
1 - Élevé2 - Moyen3 - Faible
Utilisateur assigné
AssignedToUser
Utilisateur responsable de la demande de changement à un moment donné.
Description

Cet attribut identifie la personne chargée de travailler sur la demande de changement. Cette personne peut changer plusieurs fois au cours du cycle de vie, lorsque la demande passe entre différentes étapes et équipes.

L’analyse par utilisateur permet de comprendre la répartition de la charge de travail, la performance individuelle et les besoins de formation. Elle est également essentielle 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 c’est important

Il permet de suivre la charge de travail et la performance de chaque utilisateur, et il est essentiel pour analyser les retards de transmission entre différentes ressources.

Où les obtenir

Table ServiceNow : change_request, champ : assigned_to

Exemples
Beth AnglinDavid LooAbel Tuter
Obligatoire Recommandé Facultatif

Activités de la Gestion du changement

Voici les principales étapes et les jalons à enregistrer dans votre journal d’événements pour reconstituer précisément votre processus de Gestion du changement.
7 Recommandé 6 Facultatif
Activité Description
Changement annulé
La demande de changement a été retirée ou interrompue avant la fin de sa mise en œuvre. Il s’agit d’un état de fin alternatif, enregistré lorsque l’état passe à « Canceled ».
Pourquoi c’est important

L’analyse des changements annulés peut révéler des inefficacités, par exemple des demandes créées inutilement ou restées trop longtemps en attente d’approbation avant de devenir obsolètes.

Où les obtenir

Déduit du champ « state » de la table change_request, qui est défini sur « Canceled ». L’horodatage est extrait du journal d’audit associé à cette modification d’état.

Collecte

Enregistrez l’horodatage au moment où le champ « state » est mis à jour avec la valeur « Canceled ».

Type d’événement inferred
Changement approuvé
La demande de changement a reçu toutes les autorisations nécessaires pour passer aux phases de planification et de mise en œuvre. Il s’agit d’une étape importante, enregistrée lorsque l’approbation finale est accordée et que le champ « approval » passe à « approved ».
Pourquoi c’est important

Cette étape clôt la phase d’approbation. Elle est essentielle pour mesurer les délais du cycle d’approbation et identifier les goulots d’étranglement dans le processus décisionnel.

Où les obtenir

Déduit de la modification du champ « approval » de la table change_request, qui passe à « approved ». L’horodatage est extrait de l’historique d’audit correspondant à cette modification.

Collecte

Enregistrez l’horodatage au moment où le champ « approval » passe à « approved ».

Type d’événement inferred
Changement clôturé
La demande de changement a été menée à bien, examinée et est désormais considérée comme terminée. Il s’agit du principal point de sortie réussi du processus, enregistré lorsque l’état du changement passe à « Closed ».
Pourquoi c’est important

Cette activité marque la fin réussie du cycle de vie du changement. Elle constitue l’événement de fin pour mesurer la durée du processus de bout en bout et le respect des SLA.

Où les obtenir

Déduit du champ « state » de la table change_request, qui est défini sur « Closed ». L’horodatage est extrait de l’historique d’audit correspondant à cette dernière modification d’état.

Collecte

Enregistrez l’horodatage au moment où le champ « state » est mis à jour avec la valeur « Closed ».

Type d’événement inferred
Changement mis en œuvre
Les travaux de mise en œuvre sont terminés et le changement est prêt pour examen, vérification ou test. Cette activité est déduite lorsque l’état de la demande passe de « Implement » à « Review ».
Pourquoi c’est important

Il s’agit d’une étape importante qui clôt la phase de mise en œuvre. Elle est essentielle pour calculer les KPI « Change Failure Rate » et « Change Rework Rate ».

Où les obtenir

Déduit d’une transition depuis « Implement » vers un état ultérieur tel que « Review ». L’horodatage est extrait de l’historique d’audit du champ « state » dans la table change_request.

Collecte

Identifiez le moment où le champ « state » passe de « Implement » à « Review ».

Type d’événement inferred
Changement planifié
Le changement approuvé s’est vu attribuer une date de début et une date de fin prévues. Il figure désormais officiellement au calendrier de mise en œuvre. Cette situation est déduite lorsque l’état de la demande passe à « Scheduled ».
Pourquoi c’est important

Cette activité distingue les phases de planification et d’approbation de la phase de mise en œuvre active. Le temps passé dans cet état peut révéler des retards entre l’approbation et le début des travaux.

Où les obtenir

Déduit d’une modification du champ « state » de la table change_request, qui passe à « Scheduled ». L’horodatage est extrait de l’entrée correspondante du journal d’audit.

Collecte

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é indique la création d’un nouvel enregistrement de demande de changement dans le système. Elle marque officiellement le début du processus de Gestion du changement et est enregistrée lorsqu’une nouvelle entrée est insérée dans la table change_request.
Pourquoi c’est important

Il s’agit de l’événement de début principal du processus. L’analyse du temps écoulé entre cette activité et les suivantes permet de déterminer le délai total et d’identifier les retards dès le début du processus.

Où les obtenir

Cet événement correspond à l’horodatage de création de l’enregistrement (sys_created_on) dans la table change_request de ServiceNow.

Collecte

Utilisez l’horodatage sys_created_on de la table change_request.

Type d’événement explicit
Risques et impacts évalués
Représente la fin de l’analyse des risques et des impacts de la demande de changement. Il s’agit d’une étape importante avant la demande d’approbation. Elle est souvent déduite lorsque le changement quitte l’état « Assess » pour passer à « Authorize » ou « Awaiting Approval ».
Pourquoi c’est important

Le suivi de la durée de la phase d’évaluation est essentiel pour le KPI « Avg. Risk Assessment Cycle Time ». Il contribue à standardiser le processus d’évaluation et à identifier les analyses qui prennent trop de temps.

Où les obtenir

Déduit de la transition du champ « state » de la table change_request, qui passe de « Assess » à « Authorize ». L’horodatage de l’événement est extrait du journal d’audit associé à cette modification d’état.

Collecte

Identifiez le moment où le champ « state » passe de « Assess » à un état ultérieur tel que « 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 Change Advisory Board (CAB). L’événement est enregistré lorsque le statut d’approbation de la demande passe à « requested ».
Pourquoi c’est important

Cette étape marque le début du cycle d’approbation. La mesure du temps écoulé entre cet événement et « Change Approved » permet de calculer directement le KPI « Average Change Approval Time ».

Où les obtenir

Déduit de la modification du champ « approval » de la table change_request, qui passe à « requested ». L’horodatage est enregistré dans la table sys_audit pour ce champ.

Collecte

Horodatage correspondant au moment où le champ « approval » de la table change_request passe à « requested ».

Type d’événement inferred
Changement rejeté
La demande de changement a été refusée par un approbateur ou par le CAB. Cette activité représente un état terminal pour la demande, sauf si celle-ci est retravaillée puis soumise à nouveau. Elle est enregistrée lorsque le champ « approval » passe à « rejected ».
Pourquoi c’est important

Le suivi des rejets permet d’identifier les motifs fréquents de refus, comme des informations incomplètes ou un niveau de risque élevé. Cette analyse peut améliorer la qualité des futures demandes de changement.

Où les obtenir

Déduit de la modification du champ « approval » dans la table change_request, qui passe à « rejected ». L’horodatage est extrait de l’historique d’audit.

Collecte

Enregistrez l’horodatage au moment où le champ « approval » passe à « rejected ».

Type d’événement inferred
Changement rouvert
La demande de changement est revenue à un état antérieur, tel que « Implement » ou « Assess », après avoir atteint une étape ultérieure. Cet événement est déduit d’une transition d’état non linéaire et indique une reprise des travaux.
Pourquoi c’est important

Cette activité est essentielle pour identifier les boucles de reprise et calculer le KPI « Change Rework Rate ». Des réouvertures fréquentes peuvent révéler des problèmes de qualité de mise en œuvre, de test ou de planification.

Où les obtenir

Déduit de l’analyse de la séquence des changements d’état dans l’historique d’audit de la table change_request. Une transition depuis un état ultérieur, par exemple « Review », vers un état antérieur, par exemple « Implement », indique une réouverture.

Collecte

Détectez une transition non séquentielle et régressive dans l’historique du champ « state ».

Type d’événement inferred
Demande de changement en attente d’évaluation
La demande de changement a été soumise et attend désormais une évaluation technique et métier. Cette situation est généralement déduite lorsque l’état de la demande passe à « Assess » ou à un statut similaire, ce qui indique qu’elle a quitté la phase de brouillon.
Pourquoi c’est important

Cette activité permet de mesurer le délai de transmission initiale entre le demandeur et l’équipe d’évaluation. Les retards à ce stade peuvent révéler des problèmes liés à la qualité des données initiales ou à la disponibilité des ressources chargées de l’évaluation.

Où les obtenir

Déduit d’une modification du champ « state » dans la table change_request, généralement vers une valeur telle que « Assess ». L’horodatage est extrait de l’historique d’audit (sys_audit) correspondant à cette modification.

Collecte

Suivez dans l’historique d’audit de la table change_request les modifications du champ state vers « Assess ».

Type d’événement inferred
Examen en cours
Un examen post-mise en œuvre (PIR) est réalisé afin de déterminer si le changement a réussi et atteint ses objectifs. L’événement est enregistré lorsque l’état de la demande passe à « Review ».
Pourquoi c’est important

L’analyse de la durée de la phase d’examen permet d’identifier les retards dans la validation de la réussite du changement. Elle met également en évidence les changements non conformes pour lesquels cette étape a été omise.

Où les obtenir

Déduit de la modification du champ « state » de la table change_request, qui passe à « Review ». L’horodatage est extrait du journal d’audit associé à cette modification d’état.

Collecte

Enregistrez l’horodatage de la transition vers l’état « Review » dans l’historique d’audit de la demande de changement.

Type d’événement inferred
Mise en œuvre commencée
Les travaux de mise en œuvre du changement ont effectivement commencé. L’événement est enregistré lorsque l’état de la demande passe à « Implement », ce qui marque la transition entre la planification et l’exécution.
Pourquoi c’est important

Cette étape marque le début des travaux pratiques de mise en œuvre. Elle constitue le point de départ pour mesurer le KPI « Average Implementation Duration » et analyser l’efficacité de l’équipe.

Où les obtenir

Déduit de la modification du champ « state » de la table change_request, qui passe à « Implement ». L’horodatage est extrait du journal d’audit associé à cette transition d’état.

Collecte

Enregistrez l’horodatage de la transition vers l’état « Implement » dans l’historique d’audit de la demande de changement.

Type d’événement inferred
Recommandé Facultatif

Guides d'extraction

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

Prêt à commencer ?

Utilisez ce modèle pour préparer vos données et obtenir des analyses de votre processus de Gestion du changement dans ServiceNow. Commencez dès aujourd’hui à optimiser son efficacité.

Éliminez les changements échoués et améliorez dès maintenant vos résultats dans ServiceNow !

Localisez les goulots d'étranglement pour atteindre facilement un taux de réussite des changements de 95 %.

Démarrer l'essai gratuit

Aucune carte bancaire requise, configuration en quelques minutes.