Votre modèle de données de Gestion du changement
Votre modèle de données de Gestion du changement
- 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
Attributs de la Gestion du changement
| 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
|
|||
Activités de la Gestion du changement
| 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
|
|||
Guides d'extraction
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 %.
Aucune carte bancaire requise, configuration en quelques minutes.