Votre modèle de données pour la Gestion du changement
Votre modèle de données pour la Gestion du changement
- Attributs recommandés à recueillir pour une analyse approfondie
- Activités et jalons essentiels à suivre dans votre processus
- Instructions précises pour extraire les données des systèmes sources concernés
Attributs de gestion du changement
| Nom | Description | ||
|---|---|---|---|
|
Activité
ActivityName
|
Nom de l’événement ou de la tâche spécifique exécuté dans le cadre du processus de gestion des changements. | ||
|
Description
Cet attribut représente une étape ou un changement de statut unique dans le cycle de vie d’une demande de changement, par exemple « Change Request Submitted » ou « Change Request Approved ». Ces activités constituent les éléments de base de la cartographie du processus. L’analyse de la séquence et de la durée de ces activités permet d’identifier le flux du processus, de repérer les écarts par rapport à la procédure standard et de localiser les goulots d’étranglement. Les noms d’activité sont généralement dérivés des transitions de statut enregistrées dans les journaux d’audit du système.
Pourquoi c’est important
Il définit les étapes du processus et permet de visualiser et d’analyser son flux, qui constitue le cœur du Process Mining.
Où les obtenir
Dérivé des transitions de statut du formulaire « CHG:ChangeRequest_AuditLog » ou du suivi des modifications du champ « Status » dans le formulaire « CHG:Infrastructure Change ».
Exemples
Demande de changement soumiseÉvaluation des risques réaliséeDemande de changement approuvéeChangement mis en œuvre
|
|||
|
Heure de début
EventStartTime
|
Horodatage indiquant le début d’une activité ou d’un événement spécifique. | ||
|
Description
Cet attribut enregistre la date et l’heure précises auxquelles une activité s’est produite. Il permet par exemple d’enregistrer le moment où un changement a été soumis, approuvé ou clôturé. Cet horodatage est essentiel pour analyser la chronologie du processus. Il sert à calculer les temps de cycle entre les activités, à mesurer les temps d’attente, à identifier les tendances de performance au fil du temps et à déterminer la séquence des événements. Des horodatages précis sont indispensables à toute analyse de processus fondée sur le temps.
Pourquoi c’est important
Il fournit la dimension temporelle nécessaire au calcul des durées, à l’analyse des performances et à la compréhension de la séquence des événements du processus.
Où les obtenir
Issu du champ « Audit Date » du formulaire « CHG:ChangeRequest_AuditLog » ou du champ « Last Modified Date » associé à des changements de statut spécifiques.
Exemples
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:00:00Z
|
|||
|
Identifiant de la demande de changement
ChangeRequestID
|
Identifiant unique généré par le système pour une demande de changement, utilisé comme identifiant principal du dossier. | ||
|
Description
L’identifiant de la demande de changement est la clé unique qui identifie chaque initiative de changement pendant tout son cycle de vie. Il regroupe l’ensemble des activités, approbations et tâches associées, et constitue la base d’un dossier unique dans le Process Mining. L’analyse des processus à partir de cet identifiant offre une vue de bout en bout de la gestion des changements, de la demande initiale à la clôture finale. Elle est essentielle pour suivre les temps de cycle, identifier les goulots d’étranglement et comprendre les variations du processus pour chaque changement.
Pourquoi c’est important
Il s’agit de l’attribut fondamental qui relie tous les événements associés à une seule instance de processus et rend possible l’analyse de bout en bout du processus de gestion des changements.
Où les obtenir
Présent dans le champ « Infrastructure Change ID » (ID de champ 1000000182) du formulaire « CHG:Infrastructure Change ».
Exemples
CRQ0000001234567CRQ0000001234568CRQ0000001234569
|
|||
|
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 indique la date et l’heure de la dernière extraction des données depuis BMC Helix ITSM. Il ne correspond pas à l’heure de l’événement lui-même, mais au moment de l’extraction des données. Cette information est essentielle pour évaluer leur fraîcheur et gérer les cycles d’actualisation. Dans les Dashboards et les rapports, cet horodatage indique aux utilisateurs le degré d’actualité de l’analyse, ce qui est particulièrement important pour le suivi des processus en cours.
Pourquoi c’est important
Il indique l’actualité des données, un élément essentiel pour garantir que les analyses et les Dashboards reflètent l’état le plus récent du processus.
Où les obtenir
Il s’agit d’un champ de métadonnées généralement généré et renseigné par l’outil ETL ou le pipeline de données au moment de l’extraction.
Exemples
2023-11-01T02:00:00Z2023-11-02T02:00:00Z2023-11-03T02:00:00Z
|
|||
|
Système source
SourceSystem
|
Nom du système à partir duquel les données ont été extraites. | ||
|
Description
Cet attribut identifie l’origine des données du processus, qui est ici « BMC Helix ITSM ». Il contribue à la gouvernance et à la traçabilité des données, notamment dans les environnements où des données provenant de plusieurs systèmes sont combinées pour une analyse plus large. Par exemple, si les données de changement sont ensuite fusionnées avec celles d’un système financier ou de gestion de projets, ce champ permet de distinguer clairement les sources de données.
Pourquoi c’est important
Il fournit le contexte nécessaire sur l’origine des données, garantit leur traçabilité et facilite leur interprétation, notamment dans les scénarios d’analyse multi-systèmes.
Où les obtenir
Il s’agit généralement d’une valeur statique ajoutée lors du processus d’extraction, de transformation et de chargement (ETL) afin d’indiquer l’origine du jeu de données.
Exemples
BMC Helix ITSMHelix ITSM ProdBMC Remedy AR System
|
|||
|
Équipe de mise en œuvre
ImplementationTeam
|
Équipe chargée de réaliser la mise en œuvre du changement. | ||
|
Description
Cet attribut identifie le groupe technique ou opérationnel chargé d’effectuer les travaux requis par la demande de changement. Il s’agit souvent de l’« Assigned Group » pendant les phases de mise en œuvre du cycle de vie du changement. Cette information est essentielle au Dashboard « Resource Bottlenecks in Change Process ». En analysant la durée et le volume des activités pour chaque équipe de mise en œuvre, les responsables peuvent repérer les déséquilibres de charge, les lacunes en matière de compétences ou d’autres contraintes de ressources qui retardent le déploiement des changements.
Pourquoi c’est important
Il aide à identifier les goulots d’étranglement liés aux ressources pendant la phase de mise en œuvre en permettant d’analyser les performances de chaque équipe responsable.
Où les obtenir
Présent dans le champ « ASGRP » (Assigned Group) du formulaire « CHG:Infrastructure Change ».
Exemples
Exploitation des serveursAdministrateurs de bases de donnéesÉquipe SAP BasisInfrastructure cloud
|
|||
|
Groupe d’approbateurs
ApproverGroup
|
Équipe ou groupe chargé d’approuver une demande de changement à une étape donnée. | ||
|
Description
Cet attribut identifie le groupe chargé d’examiner et d’autoriser un changement. Comme un changement peut comporter plusieurs étapes d’approbation, il peut désigner différents groupes au cours du cycle de vie, par exemple une équipe d’approbation technique et un comité d’approbation métier. Cet attribut est essentiel au Dashboard « Change Approval Bottlenecks », car il permet de segmenter les délais d’approbation selon le groupe responsable. Il aide à repérer les équipes qui peuvent être surchargées ou manquer d’efficacité, et qui sont ainsi à l’origine de retards dans le processus.
Pourquoi c’est important
Il permet d’identifier les goulots d’étranglement du processus d’approbation en analysant la durée des approbations pour chaque équipe responsable.
Où les obtenir
Issu du formulaire « AP:Signature », qui gère les approbations et est associé à la demande de changement. Le groupe de l’approbateur figure dans cet enregistrement.
Exemples
Comité consultatif des changementsSécurité informatiqueIngénierie réseauDéveloppement applicatif
|
|||
|
Niveau de risque
RiskLevel
|
Évaluation du risque potentiel associé à la mise en œuvre du changement. | ||
|
Description
Le niveau de risque est une évaluation qualitative ou quantitative de la probabilité de conséquences négatives en cas de mise en œuvre du changement. Il constitue un élément essentiel du processus d’approbation, les changements présentant un risque élevé faisant l’objet d’un examen plus approfondi. Cet attribut est au cœur du Dashboard « Change Risk Profile Analysis », qui aide les parties prenantes à comprendre l’exposition globale aux risques du portefeuille de changements. Il permet également d’identifier les boucles de reprise lorsque les évaluations initiales des risques sont insuffisantes et entraînent une réévaluation ultérieure.
Pourquoi c’est important
Il fournit une dimension essentielle pour analyser la conformité et l’efficacité du processus, en contribuant à garantir que les changements présentant un risque élevé font l’objet d’un examen approprié.
Où les obtenir
Présent dans le champ « Risk Level » du formulaire « CHG:Infrastructure Change ».
Exemples
1 - Critique2 - Élevée3 - Moyenne4 - Faible5 - Planification
|
|||
|
Priorité
Priority
|
Niveau de priorité attribué à la demande de changement, indiquant son importance pour l’entreprise. | ||
|
Description
La priorité est généralement déterminée en combinant l’Impact et l’Urgence. Elle définit l’ordre et la rapidité de traitement d’une demande de changement. Une demande de priorité élevée nécessite généralement un traitement plus rapide et peut être soumise à des accords de niveau de service (SLA) plus stricts. Cet attribut est utilisé dans le Dashboard « Change SLA Performance » pour segmenter et analyser les performances selon les différents niveaux de priorité. Il permet notamment de répondre à des questions telles que « Respectons-nous nos SLA pour les changements hautement prioritaires ? » et d’éclairer les décisions d’affectation des ressources.
Pourquoi c’est important
Il permet d’analyser les performances selon l’importance pour l’entreprise, afin de garantir que les changements les plus importants sont traités efficacement et atteignent leurs objectifs.
Où les obtenir
Présent dans le champ « Priority » du formulaire « CHG:Infrastructure Change ».
Exemples
CritiqueÉlevéeMoyenneFaible
|
|||
|
Statut
Status
|
État ou phase actuelle de la demande de changement dans son cycle de vie. | ||
|
Description
Le champ Status indique l’étape exacte d’une demande de changement à un moment donné, par exemple « Draft », « Request For Authorization » ou « Completed ». Alors que les activités sont dérivées des transitions entre ces statuts, le statut lui-même est utile pour analyser la charge de travail actuelle. Cet attribut est essentiel au Dashboard « Change Throughput & Current Status », qui fournit une vue instantanée du nombre de changements présents à chaque étape du pipeline. Il aide les responsables à comprendre le travail en cours et l’affectation des ressources.
Pourquoi c’est important
Il fournit une vue en temps réel du pipeline de changements et permet d’analyser le travail en cours ainsi que l’état actuel de toutes les demandes de changement.
Où les obtenir
Présent dans le champ « Status » du formulaire « CHG:Infrastructure Change ».
Exemples
BrouillonDemande d'autorisationPlanifiéMise en œuvre en coursTerminé
|
|||
|
Type de changement
ChangeType
|
Classification du changement, par exemple Standard, Normal ou Emergency. | ||
|
Description
Cet attribut catégorise la demande de changement selon sa nature et le processus qu’elle doit suivre. Les types courants comprennent Standard (préapprouvé et à faible risque), Normal (nécessitant une évaluation et une approbation complètes) et Emergency (nécessitant un traitement accéléré en raison d’un problème urgent). L’analyse par type de changement est essentielle pour comprendre les variations du processus. Par exemple, le Dashboard « Emergency Change Volume & Impact » utilise ce champ pour suivre les changements urgents et leur effet sur la stabilité des services. Il permet également de vérifier si les différents types de changement suivent les parcours qui leur sont prescrits.
Pourquoi c’est important
Cette fonctionnalité permet de segmenter le processus afin d’analyser et de comparer différents flux de travail de changement, ce qui est essentiel pour les analyses de conformité et de performance.
Où les obtenir
Présent dans le champ « Change Type » du formulaire « CHG:Infrastructure Change ».
Exemples
StandardNormaleUrgenceAucun impact
|
|||
|
Code de clôture
CloseCode
|
Code indiquant le résultat final du changement au moment de sa clôture. | ||
|
Description
Le code de clôture fournit un motif standardisé pour la clôture d’une demande de changement, par exemple « Successful », « Successful with Issues », « Backed Out » ou « Cancelled ». Cet attribut offre une vision plus détaillée du résultat du changement que le seul statut final. L’analyse des codes de clôture peut aider à évaluer la qualité et le taux de réussite des changements mis en œuvre. Par exemple, un nombre élevé de changements « Backed Out » peut révéler des problèmes de planification ou de test et fournir un indicateur utile pour améliorer le processus.
Pourquoi c’est important
Il fournit un résultat clair et structuré pour chaque changement, permettant d’analyser les taux de réussite ainsi que les raisons des échecs ou des annulations.
Où les obtenir
Présent dans le champ « Status Reason » ou dans un champ similaire de code de clôture du formulaire « CHG:Infrastructure Change », qui devient actif lors des dernières étapes.
Exemples
RéussiRéussi avec des problèmesAnnuléAnnulé
|
|||
|
Date cible du SLA
SLATargetDate
|
Date et heure cibles auxquelles la demande de changement doit être terminée. | ||
|
Description
La date cible de l’accord de niveau de service (SLA) correspond à l’échéance de réalisation de la demande de changement, déterminée par sa priorité et son type. Elle constitue la référence par rapport à laquelle le délai réel d’achèvement est mesuré. Cet attribut est fondamental pour le Dashboard « Change SLA Performance ». En comparant l’heure réelle de clôture à cette cible, il est possible de déterminer si le changement a respecté son SLA. L’analyse des performances des SLA aide à évaluer l’efficacité globale du processus et le respect des engagements de niveau de service.
Pourquoi c’est important
Il fournit la référence nécessaire à la mesure des performances, au calcul des taux de conformité aux SLA et à l’identification des changements présentant un risque.
Où les obtenir
Ces informations sont généralement stockées dans des formulaires associés de gestion des SLA et liées à la demande de changement, souvent directement visibles dans le formulaire de changement.
Exemples
2023-11-10T17:00:00Z2023-11-15T09:00:00Z2023-12-01T17:00:00Z
|
|||
|
Demandeur du changement
ChangeSubmitter
|
Personne qui a créé et soumis la demande de changement. | ||
|
Description
Cet attribut identifie la personne à l’origine de la demande de changement. Elle est généralement enregistrée comme « Submitter » ou « Reported By » dans le système. Même s’il ne constitue pas toujours une dimension d’analyse principale, cet attribut peut aider à comprendre l’origine des demandes de changement. Par exemple, analyser si la majorité des changements provient de certains services ou rôles peut apporter des informations utiles sur les besoins de l’entreprise et les processus de planification.
Pourquoi c’est important
Il aide à identifier les personnes à l’origine des demandes de changement et peut servir à analyser les tendances de la demande ainsi que le comportement des utilisateurs dans le processus.
Où les obtenir
Présent dans le champ « Submitter » du formulaire « CHG:Infrastructure Change ».
Exemples
Allen AllbrookMary MannBob Baxter
|
|||
|
État du SLA
SLAState
|
Statut calculé de la demande de changement par rapport à sa cible SLA. | ||
|
Description
Cet attribut indique si une demande de changement terminée a respecté son accord de niveau de service (SLA), risquait de ne pas le respecter ou l’a dépassé. Il est calculé en comparant l’horodatage réel d’achèvement à « SLATargetDate ». Il s’agit de la mesure principale du Dashboard « Change SLA Performance ». Elle fournit une mesure claire et concise des performances par rapport aux engagements de service et permet d’analyser les données par priorité, type de changement ou équipe afin d’identifier les domaines où le respect des SLA est insuffisant.
Pourquoi c’est important
Il fournit une mesure directe des performances par rapport aux engagements et constitue ainsi un indicateur clé de l’efficacité du processus et de la qualité de service.
Où les obtenir
Il s’agit d’un attribut calculé lors de la transformation des données, en comparant l’horodatage de l’activité finale à « SLATargetDate ».
Exemples
Dans les délaisÀ risqueEn dépassement
|
|||
|
Heure de fin
EventEndTime
|
Horodatage indiquant la fin d’une activité ou d’un événement spécifique. | ||
|
Description
L’heure de fin marque l’achèvement d’une activité. Dans le Process Mining, elle est souvent calculée à partir de l’heure de début de l’activité suivante dans le dossier, ce qui fournit une durée précise pour l’étape précédente. Pour la toute dernière activité d’un dossier, elle peut correspondre à son heure de début ou à un horodatage de clôture spécifique. Cet attribut est essentiel pour calculer le
Pourquoi c’est important
Il permet de calculer précisément la durée des activités, ce qui est fondamental pour identifier les goulots d’étranglement et mesurer les performances du processus.
Où les obtenir
Il s’agit d’un attribut calculé, généralement dérivé lors de la transformation des données en prenant l’heure de début de l’événement suivant dans la séquence pour un dossier donné.
Exemples
2023-10-26T14:35:10Z2023-10-27T09:00:00Z2023-10-27T11:20:00Z
|
|||
|
Identifiant de l’incident associé
RelatedIncidentID
|
Identifiant de tout incident provoqué par ce changement. | ||
|
Description
Cet attribut relie une demande de changement aux incidents ultérieurs qu’elle a pu provoquer. Cette relation est essentielle pour comprendre l’impact en aval des changements sur la stabilité des services. Il s’agit de l’attribut principal nécessaire au calcul du KPI « Change-Induced Incident Rate ». En suivant ces liens, une organisation peut mesurer la qualité de son processus de changement et identifier les types de changement, les équipes ou les services associés à un taux plus élevé de problèmes après la mise en œuvre.
Pourquoi c’est important
Il mesure directement l’impact négatif des changements et fournit un KPI essentiel pour évaluer leur qualité ainsi que l’efficacité de la gestion des risques.
Où les obtenir
Cette relation est généralement établie dans le formulaire Incident (« HPD:Help Desk »), où un incident peut être relié à une demande de changement en tant que cause.
Exemples
INC000000987654INC000000987655INC000000987656
|
|||
|
Impact
Impact
|
Impact évalué du changement sur les services de l’entreprise et l’infrastructure informatique. | ||
|
Description
L’impact mesure l’effet potentiel d’un changement sur les activités, les services et les utilisateurs de l’entreprise. Avec l’Urgence, il constitue un facteur essentiel pour déterminer la Priorité de la demande de changement. Dans les analyses, l’Impact est utilisé dans le Dashboard « Change Risk Profile Analysis » afin de fournir une vue complète des conséquences potentielles du portefeuille de changements pour l’entreprise. Comprendre la répartition des changements à fort impact peut orienter les stratégies de gestion des risques et la planification des ressources.
Pourquoi c’est important
Il aide à quantifier les conséquences potentielles des changements pour l’entreprise et permet d’analyser les risques et de définir les priorités selon la gravité des effets possibles sur les services.
Où les obtenir
Présent dans le champ « Impact » du formulaire « CHG:Infrastructure Change ».
Exemples
1-Étendue/Généralisée2-Importante/Étendue3-Modérée/Limitée4-Mineure/Localisée
|
|||
|
Indicateur de changement d’urgence
IsEmergencyChange
|
Indicateur booléen qui prend la valeur true lorsque le changement est de type « Emergency ». | ||
|
Description
Cet indicateur dérivé simplifie l’analyse en fournissant un indicateur binaire clair pour les changements d’urgence. Il repose sur la valeur de l’attribut « ChangeType ». Cet attribut sert principalement à alimenter le Dashboard « Emergency Change Volume & Impact » et le KPI « Emergency Change Percentage ». Il permet de filtrer et d’agréger facilement les données relatives aux changements d’urgence, afin d’en suivre la fréquence et les tendances au fil du temps sans recourir à une logique de filtrage complexe dans l’outil d’analyse.
Pourquoi c’est important
Il simplifie l’analyse des changements d’urgence et facilite leur filtrage, la création de Dashboards et le calcul des KPI associés à ce type de changement important.
Où les obtenir
Il s’agit d’un attribut dérivé créé lors de la transformation des données. La logique est la suivante : IF « ChangeType » = « Emergency » THEN true ELSE false.
Exemples
truefalse
|
|||
|
Indicateur de reprise
IsRework
|
Indicateur précisant si une activité représente une boucle de reprise ou un retour en arrière dans le processus. | ||
|
Description
Cet attribut booléen prend la valeur true lorsqu’une demande de changement revient à une étape précédente de son cycle de vie, par exemple de « Scheduled » à « Risk Assessment ». Ces retours en arrière représentent une reprise, souvent source d’inefficacité. Cet indicateur sert à calculer le KPI « Change Rework Rate » et contribue au Dashboard « Change Rework & Assessment Efficiency ». Il permet de quantifier la fréquence des reprises et d’identifier les étapes du processus où elles se produisent le plus souvent, afin de cibler les améliorations à apporter à la planification et à l’évaluation initiales.
Pourquoi c’est important
Il identifie directement les inefficacités du processus en signalant les activités qui font partie d’une boucle de reprise et permet ainsi de cibler les efforts d’amélioration.
Où les obtenir
Il s’agit d’un attribut calculé, dérivé de l’analyse de la séquence des activités d’un dossier. Une logique appliquée lors de la transformation des données détecte les retours en arrière dans le flux du processus.
Exemples
truefalse
|
|||
|
Service affecté
AffectedService
|
Service métier ou technique affecté par le changement. | ||
|
Description
Cet attribut relie la demande de changement à un service spécifique défini dans la base de données de gestion de configuration (CMDB). Il peut s’agir d’un service métier destiné aux utilisateurs, comme « Email Services », ou d’un service technique en arrière-plan, comme « Authentication Service ». Il est utilisé dans le Dashboard « Emergency Change Volume & Impact » pour mettre en relation les changements et les services qu’ils affectent. Il permet ainsi de comprendre la stabilité des différents services et d’identifier ceux qui nécessitent fréquemment des interventions d’urgence.
Pourquoi c’est important
Il fournit un contexte métier essentiel, relie les changements techniques à leurs effets sur les services de l’entreprise et permet une analyse des processus centrée sur les services.
Où les obtenir
Issu du champ « ServiceCI » ou des relations avec les éléments de configuration (CI) associés dans le formulaire « CHG:Infrastructure Change ».
Exemples
Messagerie d'entrepriseSAP ERPGestion de la relation clientPortail bancaire en ligne
|
|||
|
Urgence
Urgency
|
Urgence du changement, qui reflète le caractère sensible au temps de sa mise en œuvre. | ||
|
Description
L’Urgence indique la rapidité avec laquelle le changement doit être mis en œuvre. Avec l’Impact, elle constitue un élément essentiel du calcul de la Priorité globale de la demande de changement. L’Urgence est un attribut important du Dashboard « Change Risk Profile Analysis », car elle renseigne sur les contraintes de temps qui pèsent sur le processus de gestion des changements. L’analyse des tendances d’urgence peut aider à identifier les problèmes sous-jacents à l’origine d’un nombre élevé de demandes sensibles au temps.
Pourquoi c’est important
Elle reflète le caractère urgent des changements et permet d’analyser la capacité du processus à traiter efficacement les demandes présentant différents niveaux de contrainte temporelle.
Où les obtenir
Présent dans le champ « Urgency » du formulaire « CHG:Infrastructure Change ».
Exemples
1-Critique2-Élevée3-Moyenne4-Faible
|
|||
Activités de gestion du changement
| Activité | Description | ||
|---|---|---|---|
|
Changement clôturé
|
Il s’agit de l’activité finale, qui marque la clôture officielle de la demande de changement dans le système. Cet événement est enregistré lorsque le statut de la demande de changement est défini sur « Closed ». | ||
|
Pourquoi c’est important
Cette activité marque la fin réussie du cycle de vie du changement. Elle est essentielle pour mesurer la durée du processus de bout en bout et le débit global.
Où les obtenir
Déduit de l’historique des changements de statut du formulaire CHG:Change, lorsque le statut passe à « Closed ».
Collecte
Identifier l’horodatage auquel le champ « Status » de CHG:Change est mis à jour sur « Closed ».
Type d’événement
inferred
|
|||
|
Changement mis en œuvre
|
Cette activité représente l’achèvement réussi des travaux de mise en œuvre du changement. Elle est généralement enregistrée lorsque le statut est mis à jour sur « Completed », avec un motif indiquant la réussite. | ||
|
Pourquoi c’est important
Il s’agit d’une étape majeure qui marque la fin de la phase de déploiement. Elle est essentielle pour calculer le KPI Change Implementation Cycle Time et analyser les incidents provoqués par les changements.
Où les obtenir
Déduit du formulaire CHG:Change lorsque « Status » est défini sur « Completed » et que « Status Reason » est « Successful ».
Collecte
Identifier l’horodatage auquel le champ « Status » de CHG:Change est mis à jour sur « Completed ».
Type d’événement
inferred
|
|||
|
Changement planifié
|
Cette activité marque le moment où le changement approuvé est officiellement planifié pour sa mise en œuvre. Cet événement est enregistré lors du passage du statut à « Scheduled » dans le système. | ||
|
Pourquoi c’est important
Il s’agit d’une étape importante qui confirme que le changement est prêt à être mis en œuvre. Elle constitue le point de départ pour mesurer les KPI Change Implementation Cycle Time et Average Implementation Wait Time.
Où les obtenir
Déduit de l’historique des changements de statut du formulaire CHG:Change, lorsque le statut passe à « Scheduled ».
Collecte
Identifier l’horodatage auquel le champ « Status » de CHG:Change est mis à jour sur « Scheduled ».
Type d’événement
inferred
|
|||
|
Demande de changement approuvée
|
Il s’agit d’une étape clé au cours de laquelle la demande de changement reçoit l’autorisation officielle d’avancer. L’événement est déduit d’un changement d’état, généralement vers « Scheduled » ou « Planning In Progress » après l’autorisation finale. | ||
|
Pourquoi c’est important
Cette étape marque la fin de la phase d’approbation et est essentielle pour mesurer les goulots d’étranglement des approbations ainsi que le KPI de délai moyen d’approbation des changements. Il s’agit d’un point de décision important du processus.
Où les obtenir
Déduit de l’historique des changements d’état du formulaire CHG:Change, plus précisément lorsque la demande quitte un état d’approbation tel que « Request For Authorization ».
Collecte
Identifiez l’horodatage auquel le champ « Status » de CHG:Change dépasse la phase d’approbation finale, par exemple lors du passage à « Scheduled ».
Type d’événement
inferred
|
|||
|
Demande de changement créée
|
Cette activité marque la création initiale d’un enregistrement de demande de changement dans le système. L’événement est enregistré à partir de l’horodatage de création de l’entrée de demande de changement dans le formulaire CHG:Change. | ||
|
Pourquoi c’est important
Il s’agit du point de départ de chaque demande de changement, indispensable pour mesurer la durée totale du cycle de vie et analyser le volume des changements entrants.
Où les obtenir
Cet événement est enregistré à partir de la « Submit Date » ou de l’horodatage de création de l’enregistrement dans le journal d’audit du formulaire CHG:Change, par exemple HPD:Help Desk Audit Log.
Collecte
Utilisez l’horodatage de création de l’enregistrement du formulaire CHG:Change.
Type d’événement
explicit
|
|||
|
Évaluation des risques réalisée
|
Cette activité indique que l’évaluation des risques du changement proposé est terminée. Elle est souvent enregistrée lorsque l’état de la demande est mis à jour ou lorsqu’une tâche spécifique d’évaluation des risques est clôturée. | ||
|
Pourquoi c’est important
Le suivi de cette activité est essentiel pour garantir le respect des politiques de Gestion du changement. Il aide à identifier les retards lors de la phase d’évaluation et à analyser le taux de reprise des changements lorsque le processus revient à cette étape.
Où les obtenir
Déduit d’un changement d’état dans le formulaire CHG:Change, par exemple lors du passage à « Request For Change », ou de l’achèvement d’une tâche associée dans le formulaire CHG:Task.
Collecte
Identifiez l’horodatage auquel une tâche « Risk Assessment » associée dans CHG:Task est marquée « Closed » ou « Completed ».
Type d’événement
inferred
|
|||
|
Tests réalisés
|
Indique que les tests ou la validation réalisés après la mise en œuvre sont terminés. Cette étape est souvent enregistrée lors de la clôture d’une tâche de test dédiée, associée à la demande de changement. | ||
|
Pourquoi c’est important
Le suivi de cette activité est essentiel pour mesurer le KPI Average Testing Cycle Time et garantir la qualité. Il permet d’identifier les goulots d’étranglement du processus de validation avant la vérification finale.
Où les obtenir
Déduit de l’achèvement d’un enregistrement de tâche de test dans le formulaire CHG:Task, associé à la demande de changement parente.
Collecte
Identifier l’horodatage auquel une tâche « Testing » ou « Validation » associée dans CHG:Task est marquée « Closed » ou « Completed ».
Type d’événement
inferred
|
|||
|
Analyse d’impact réalisée
|
Représente l’achèvement de l’analyse d’impact visant à déterminer les conséquences potentielles d’un changement. Cette étape est généralement déduite d’une mise à jour de l’état ou de la clôture d’une tâche associée. | ||
|
Pourquoi c’est important
Cette activité est essentielle pour comprendre l’efficacité de la planification et son effet sur les reprises. L’analyse de sa durée et de sa fréquence aide à améliorer la phase d’évaluation initiale.
Où les obtenir
Déduit de l’horodatage d’achèvement d’une tâche « Impact Analysis » dans le formulaire CHG:Task ou d’une transition d’état spécifique dans le formulaire CHG:Change.
Collecte
Identifiez l’horodatage auquel une tâche « Impact Analysis » associée dans CHG:Task est marquée « Closed » ou « Completed ».
Type d’événement
inferred
|
|||
|
Changement annulé
|
Représente l’annulation d’une demande de changement avant sa mise en œuvre ou son achèvement. Cette étape est enregistrée lorsque le statut de la demande de changement est mis à jour sur « Cancelled ». | ||
|
Pourquoi c’est important
Le suivi des annulations permet de comprendre pourquoi des changements sont retirés. Il peut mettre en évidence des problèmes tels qu’une planification initiale insuffisante, l’évolution des priorités ou des contraintes de ressources.
Où les obtenir
Déduit de l’historique des changements de statut du formulaire CHG:Change, lorsque le statut passe à « Cancelled ».
Collecte
Identifier l’horodatage auquel le champ « Status » de CHG:Change est mis à jour sur « Cancelled ».
Type d’événement
inferred
|
|||
|
Changement vérifié
|
Cette activité indique que les parties prenantes ont officiellement vérifié la réussite du changement après sa mise en œuvre et les tests. Elle est souvent représentée par un changement de statut avant la clôture finale. | ||
|
Pourquoi c’est important
La vérification constitue le dernier contrôle qualité avant la clôture d’un changement. Elle confirme que le changement a atteint ses objectifs et n’a pas entraîné d’effets négatifs imprévus.
Où les obtenir
Déduit d’un changement de statut dans le formulaire CHG:Change, par exemple lors du passage de « Completed » à « Verification » ou « Closed ».
Collecte
Identifier l’horodatage auquel le champ « Status » de CHG:Change passe à « Closed » après les activités de mise en œuvre.
Type d’événement
inferred
|
|||
|
Demande de changement rejetée
|
Cette activité indique que la demande de changement a été officiellement refusée par un approbateur. Elle est enregistrée par un changement d’état vers « Rejected » et représente un état terminal. | ||
|
Pourquoi c’est important
Le suivi des rejets aide à identifier les motifs du 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 l’historique des changements d’état du formulaire CHG:Change, plus précisément lors de la transition vers l’état « Rejected ».
Collecte
Identifiez l’horodatage auquel le champ « Status » de CHG:Change est mis à jour avec la valeur « Rejected ».
Type d’événement
inferred
|
|||
|
Demande de changement soumise
|
Représente la soumission officielle d’une demande de changement pour examen et autorisation. Cette étape est généralement déduite lorsque l’état de la demande passe de « Draft » à « Request For Authorization ». | ||
|
Pourquoi c’est important
Cette activité lance le processus d’approbation. Son suivi est essentiel pour mesurer le temps d’attente des demandes avant leur premier examen et analyser le KPI de délai d’approbation des changements.
Où les obtenir
Déduit de l’historique des changements d’état de la demande dans le formulaire CHG:Change, plus précisément lors de la transition vers « Request For Authorization ».
Collecte
Identifiez l’horodatage auquel le champ « Status » de CHG:Change passe de « Draft » à « Request For Authorization ».
Type d’événement
inferred
|
|||
|
Plan de mise en œuvre élaboré
|
Indique que le plan détaillé de mise en œuvre du changement a été créé et documenté. Cette étape est généralement enregistrée lorsqu’une tâche de planification associée au changement est terminée. | ||
|
Pourquoi c’est important
L’achèvement de cette activité est un préalable à la planification et à la mise en œuvre. L’analyse de sa durée aide à identifier les retards lors de la phase de planification, avant l’exécution du changement.
Où les obtenir
Déduit de l’achèvement d’un enregistrement de tâche de planification spécifique dans le formulaire CHG:Task, associé à la demande de changement parente.
Collecte
Identifier l’horodatage auquel une tâche « Implementation Planning » associée dans CHG:Task est marquée « Closed » ou « Completed ».
Type d’événement
inferred
|
|||
|
Revue postérieure à la mise en œuvre
|
Représente l’achèvement d’une revue formelle après la mise en œuvre du changement. Cette activité est généralement enregistrée lors de la clôture d’une tâche de revue postérieure à la mise en œuvre (PIR). | ||
|
Pourquoi c’est important
Cette activité est essentielle à l’apprentissage organisationnel et à l’amélioration des processus. La mesure du KPI Post-Implementation Review Rate contribue à garantir que les enseignements sont tirés des changements.
Où les obtenir
Déduit de l’achèvement d’une tâche « Post-Implementation Review » dans le formulaire CHG:Task, associée à la demande de changement parente.
Collecte
Identifier l’horodatage auquel une tâche « PIR » associée dans CHG:Task est marquée « Closed » ou « Completed ».
Type d’événement
inferred
|
|||
Guides d’extraction
Prêt à commencer ?
Commencez dès aujourd’hui à optimiser votre processus de Gestion du changement en préparant vos données à l’aide de ce modèle. Obtenez des analyses utiles et améliorez l’efficacité de vos opérations.
Optimisez dès maintenant votre Gestion du changement et évitez les interruptions
Portez votre taux de réussite des changements à 95 % et évitez les interruptions de service coûteuses.
Aucune carte bancaire requise. La configuration ne prend que quelques minutes.