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
- Instructions d’extraction depuis Ivanti Cherwell
Attributs de gestion du changement
| Nom | Description | ||
|---|---|---|---|
|
Heure de l'événement
EventTime
|
Horodatage indiquant le moment où une activité ou un événement précis s'est produit pour la demande de modification. | ||
|
Description
L'heure de l'événement, également appelée horodatage, enregistre la date et l'heure exactes auxquelles une activité a eu lieu. Ces données temporelles sont essentielles pour classer les événements par ordre chronologique et constituent la base de toutes les analyses temporelles de Process Mining. Cet attribut sert à calculer les durées entre les activités, à mesurer les délais globaux des cas et à identifier les temps d'attente ou les retards du processus. Il est indispensable à la création de Dashboards qui suivent la performance par rapport à des objectifs temporels, tels que le délai d'approbation des modifications.
Pourquoi c’est important
Cet horodatage constitue la base de toutes les analyses de performance et de durée. Il permet de calculer les temps de cycle, d’identifier les goulots d’étranglement et de surveiller les SLA.
Où les obtenir
Généralement présent dans les journaux de changements de statut, les pistes d'audit ou les horodatages des entrées de journal associés à l'objet Change Request dans Ivanti Cherwell.
Exemples
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z
|
|||
|
Identifiant de la demande de modification
ChangeRequestId
|
Identifiant unique d'une demande de modification, regroupant toutes les activités associées, de l'initiation à la clôture. | ||
|
Description
L’identifiant de la demande de changement est la clé primaire qui identifie de manière unique chaque initiative de changement tout au long de son cycle de vie. Il sert d’identifiant du cas dans le Process Mining et relie tous les événements, tels que la soumission, l’évaluation, l’approbation et la mise en œuvre, au sein d’une même instance de processus cohérente. L’analyse des données à partir de l’identifiant de la demande de changement offre une vue complète de bout en bout du processus de Gestion du changement. Elle permet de suivre chaque changement, de calculer les temps de cycle totaux et d’identifier les écarts ou les goulots d’étranglement propres à chaque demande.
Pourquoi c’est important
Il s'agit de l'identifiant de cas essentiel qui relie tous les événements associés, permettant de retracer l'intégralité du parcours d'une demande de modification et d'en analyser la performance.
Où les obtenir
Il s'agit généralement de l'identifiant principal de l'objet métier Change Request dans Ivanti Cherwell.
Exemples
CR-105421CR-105422CR-105423
|
|||
|
Nom de l'activité
ActivityName
|
Nom de l'événement ou de la tâche spécifique survenu à un moment donné du processus de gestion du changement. | ||
|
Description
Le nom de l'activité décrit une étape ou un jalon précis du cycle de vie d'une demande de modification, tel que « Change Submitted For Assessment » ou « Change Approved by CAB ». Ces activités constituent les nœuds de la carte de processus découverte. Dans l'analyse, cet attribut est fondamental pour visualiser le flux du processus, identifier la séquence des événements et détecter les écarts par rapport à la procédure standard. Il sert à calculer les délais de transition entre les activités et à comprendre où se produisent les retards.
Pourquoi c’est important
Cet attribut est essentiel pour découvrir et visualiser le flux réel du processus, et ainsi identifier les goulots d’étranglement, les boucles de reprises et les parcours non conformes.
Où les obtenir
Généré à partir des changements de statut, des entrées de journal ou des journaux d'événements spécifiques associés à l'objet Change Request dans Ivanti Cherwell.
Exemples
Demande de changement soumise pour évaluationChangement en attente d’approbationModification mise en œuvre
|
|||
|
Dernière mise à jour des données
LastDataUpdate
|
Horodatage indiquant le moment où les données de cet événement ont été extraites ou actualisées pour la dernière fois depuis le système source. | ||
|
Description
Cet attribut enregistre la date et l'heure auxquelles les données ont été extraites pour la dernière fois d'Ivanti Cherwell. Il ne représente pas un événement du processus lui-même, mais des métadonnées relatives à l'actualité des données. Il est important que les utilisateurs des Dashboards sachent dans quelle mesure l'analyse est à jour. Il contribue à la gestion des calendriers d'actualisation et garantit que les décisions reposent sur des données dont l'ancienneté est connue.
Pourquoi c’est important
Indique l'actualité des données, un élément essentiel pour que les utilisateurs puissent se fier à l'analyse et comprendre sa pertinence au regard de la situation opérationnelle actuelle.
Où les obtenir
Cet horodatage est généré et apposé sur chaque enregistrement lors du processus d'extraction, de transformation et de chargement (ETL) des données.
Exemples
2024-05-21T02:00:00Z
|
|||
|
Système source
SourceSystem
|
Système de référence depuis lequel les données ont été extraites. Dans cette vue, il s'agit de « Ivanti Cherwell ». | ||
|
Description
Cet attribut identifie le système à l'origine des données d'événements. Dans les environnements hétérogènes, il aide à distinguer les données provenant de différentes sources. Pour ce modèle de données, sa valeur est constante et indique que les données proviennent d'Ivanti Cherwell. Même s'il peut sembler statique dans un modèle à source unique, il est essentiel à la gouvernance des données, à la traçabilité et aux futures intégrations avec d'autres systèmes. Il garantit la clarté de la provenance des données et contribue à la gestion de leur qualité.
Pourquoi c’est important
Fournit un contexte essentiel sur l'origine des données, indispensable à la gouvernance des données, au dépannage et à la traçabilité.
Où les obtenir
Il s'agit généralement d'une valeur statique ajoutée lors de l'extraction et de la transformation des données afin d'indiquer l'origine du jeu de données.
Exemples
Ivanti Cherwell
|
|||
|
Date cible d'achèvement
TargetCompletionDate
|
Date limite planifiée ou convenue pour l'achèvement de la mise en œuvre de la modification. | ||
|
Description
La date cible d'achèvement correspond à la date et à l'heure auxquelles la modification doit être entièrement mise en œuvre et vérifiée. Elle fait souvent partie d'un accord de niveau de service (SLA) et sert de référence principale pour mesurer la performance. Cet attribut est essentiel au suivi du respect des délais. Il est comparé à la date réelle d'achèvement pour calculer les KPI du taux d'achèvement des modifications dans les délais et du respect des SLA des modifications. Il aide à identifier en amont les modifications susceptibles de ne pas atteindre leurs objectifs.
Pourquoi c’est important
Fournit la référence nécessaire pour mesurer la performance dans les délais et le respect des SLA, deux indicateurs importants de l'efficacité et de la fiabilité du processus.
Où les obtenir
Il s'agit généralement d'un champ de date précis de l'objet Change Request, souvent intitulé « Target Date », « Due Date » ou « SLA Target ».
Exemples
2023-11-15T17:00:00Z2023-12-01T23:59:59Z2024-01-10T12:00:00Z
|
|||
|
Équipe responsable de la modification
ChangeTeam
|
Équipe ou groupe actuellement responsable de la demande de modification. | ||
|
Description
L'équipe responsable de la modification est le groupe ou le service auquel la demande est attribuée. Comme le responsable individuel, elle peut changer au cours du processus, ce qui indique un transfert de responsabilité entre équipes, par exemple du service desk vers une équipe d'ingénierie réseau. Cet attribut est essentiel pour analyser les transferts entre équipes et identifier les retards systémiques causés par certaines équipes. Il permet de déterminer quelles équipes sont surchargées ou à quels endroits surviennent des ruptures de communication, et alimente directement l'analyse « Transferts et utilisation des ressources liés aux modifications ».
Pourquoi c’est important
Identifie la responsabilité au niveau de l’équipe, ce qui est essentiel pour analyser les goulots d’étranglement du processus, mesurer les performances des équipes et comprendre les retards liés aux transferts entre groupes.
Où les obtenir
Ces informations sont généralement stockées dans le champ « Owned By Team » ou dans un champ similaire d'affectation à un groupe sur l'objet Change Request.
Exemples
Exploitation du réseauAdministration des bases de donnéesSupport applicatif
|
|||
|
Niveau de risque de la modification
ChangeRiskLevel
|
Niveau de risque évalué associé à la modification, par exemple « Low », « Medium » ou « High ». | ||
|
Description
Le niveau de risque de la modification est une classification attribuée pendant la phase d'évaluation afin de quantifier l'impact négatif potentiel d'une modification. Cette évaluation influence souvent le processus d'approbation et le niveau d'examen requis. Dans le Process Mining, cet attribut sert à analyser la cohérence des évaluations des risques et à mettre en relation le niveau de risque avec le comportement du processus. Il permet par exemple de vérifier si les modifications à haut risque suivent un parcours d'approbation plus rigoureux ou si leur mise en œuvre prend davantage de temps. Il alimente directement le Dashboard « Cohérence de l'évaluation des risques liés aux modifications ».
Pourquoi c’est important
Permet d'analyser l'incidence du risque sur le flux du processus, les cycles d'approbation et les taux de réussite, afin de garantir que les modifications à haut risque font l'objet d'un examen approprié.
Où les obtenir
Cette valeur est stockée dans un champ « Risk Level » ou similaire de l'objet Change Request, généralement renseigné lors de l'activité d'évaluation des risques.
Exemples
FaibleMoyenneÉlevéeCritique
|
|||
|
Responsable de la modification
ChangeOwner
|
Utilisateur ou personne actuellement responsable de la demande de modification. | ||
|
Description
Le responsable du changement est la personne affectée à la demande de changement et qui en assume la responsabilité à une étape donnée. Cet attribut change souvent au fil du cycle de vie de la demande, ce qui indique un transfert entre personnes. L’analyse du responsable du changement aide à comprendre la charge de travail des ressources et à identifier les goulots d’étranglement liés à certaines personnes. Elle est également fondamentale pour analyser les transferts, qui peuvent constituer une source importante de retards. Cet attribut alimente le Dashboard « Transferts de changements et utilisation des ressources ».
Pourquoi c’est important
Suit la responsabilité individuelle et permet d’analyser la répartition de la charge de travail, la fréquence des transferts et les goulots d’étranglement propres aux ressources.
Où les obtenir
Il s'agit généralement du champ « Owned By » ou « Assigned To » de l'objet métier Change Request.
Exemples
Alice JohnsonBob WilliamsCharlie Brown
|
|||
|
Statut de la modification
ChangeStatus
|
Statut actuel ou final de la demande de modification, par exemple « Closed », « Rejected » ou « In Progress ». | ||
|
Description
Le statut de la modification indique l'état d'une demande à un moment donné ou son résultat final. Il s'agit d'un attribut essentiel pour comprendre la résolution des cas et identifier les exceptions. Dans l'analyse des processus, cet attribut sert à filtrer certains résultats, par exemple pour analyser uniquement les modifications rejetées ou annulées. Il alimente des KPI tels que le taux de rejet des demandes de modification et est indispensable pour évaluer la santé et l'efficacité globales du processus de gestion du changement.
Pourquoi c’est important
Définit le résultat d'une demande de modification et permet d'analyser les taux de rejet et d'achèvement ainsi que la répartition des cas ouverts et clôturés.
Où les obtenir
Correspond au champ « Status » de l'objet métier Change Request dans Ivanti Cherwell.
Exemples
ApprouvéRejetéClôturéAnnuléEn attente d'approbation
|
|||
|
Type de modification
ChangeType
|
Classification de la modification, par exemple « Standard », « Normal » ou « Emergency ». | ||
|
Description
Le type de modification catégorise la demande en fonction de sa nature, de son urgence et de son impact. Les types courants comprennent Standard, préapprouvée et à faible risque, Normal, nécessitant une évaluation et une approbation complètes, et Emergency, nécessitant une mise en œuvre immédiate. Cet attribut permet de comparer les performances du processus entre différentes catégories. Il peut notamment servir à déterminer si les modifications urgentes suivent un parcours différent et plus rapide, ou si les modifications standard sont réellement traitées avec un minimum de friction. Il est essentiel au Dashboard « Performance des types de modifications problématiques ».
Pourquoi c’est important
Segmenter le processus selon le type de changement est essentiel pour comparer les performances et déterminer si certaines catégories, comme « Urgence », provoquent des goulots d’étranglement ou des écarts.
Où les obtenir
Correspond à un champ de classification, probablement nommé « Change Type » ou « Category », dans l'objet métier Change Request.
Exemples
StandardNormaleUrgence
|
|||
|
Achèvement dans les délais
IsOnTimeCompletion
|
Indicateur calculé qui vaut vrai si la modification a été terminée à la date cible ou avant celle-ci. | ||
|
Description
Il s'agit d'un attribut booléen calculé en comparant « ActualCompletionDate » et « TargetCompletionDate ». Il simplifie l'analyse en fournissant un indicateur binaire clair de la performance dans les délais pour chaque demande de modification. Cet indicateur sert de base au calcul du KPI du taux d'achèvement des modifications dans les délais. Il peut être utilisé comme filtre dans les Dashboards afin d'isoler et d'analyser facilement les modifications en retard et d'identifier les causes profondes récurrentes des retards.
Pourquoi c’est important
Simplifie l'analyse de la performance en fournissant un résultat clair de réussite ou d'échec quant au respect des délais, et alimente directement les KPI d'achèvement dans les délais.
Où les obtenir
Cet attribut n'est pas présent dans le système source. Il est calculé lors de la transformation des données en comparant « ActualCompletionDate » <= « TargetCompletionDate ».
Exemples
truefalse
|
|||
|
Auteur de la demande de modification
ChangeSubmitter
|
Utilisateur ayant initialement créé ou soumis la demande de modification. | ||
|
Description
Cet attribut identifie la personne à l'origine de la demande de modification. Il peut être différent du responsable de la modification, qui en assume la responsabilité lors d'une étape ultérieure du processus. L'analyse de l'auteur de la demande peut révéler des tendances liées à la qualité des demandes. Elle peut par exemple montrer que certaines personnes ou équipes soumettent fréquemment des demandes incomplètes, entraînant des rejets ou des reprises. Ces résultats peuvent servir à proposer des formations ciblées et à améliorer la qualité globale des soumissions.
Pourquoi c’est important
Permet de retracer l'origine des demandes de modification, d'analyser la qualité des soumissions par personne ou par équipe et d'identifier les besoins de formation.
Où les obtenir
Il s'agit généralement du champ « Created By » ou « Requested By » de l'objet Change Request.
Exemples
Susan MillerDavid ChenMaria Garcia
|
|||
|
Date réelle d'achèvement
ActualCompletionDate
|
Date et heure auxquelles la modification a effectivement été mise en œuvre et vérifiée comme terminée. | ||
|
Description
La date réelle d'achèvement marque le moment où les travaux de mise en œuvre de la demande de modification sont terminés. Il s'agit d'un jalon important, comparé à la date limite planifiée pour mesurer la performance. Cet attribut est utilisé avec la date cible d'achèvement pour déterminer si la modification a été terminée dans les délais. Il constitue une donnée fondamentale pour calculer le KPI du taux d'achèvement des modifications dans les délais et analyser les causes des retards pendant la phase de mise en œuvre.
Pourquoi c’est important
Enregistre l'heure réelle d'achèvement, nécessaire pour calculer les taux de livraison dans les délais et analyser l'ampleur des retards.
Où les obtenir
Cette date est souvent enregistrée lorsque le statut de la demande passe à « Implemented » ou « Completed ». Elle peut provenir d'un champ dédié ou être déduite de l'horodatage de ce changement de statut.
Exemples
2023-11-14T16:30:00Z2023-12-03T10:00:00Z2024-01-10T11:45:00Z
|
|||
|
Délai du cycle de mise en œuvre
ImplementationCycleTime
|
Durée calculée entre le début et l'achèvement de la mise en œuvre d'une modification. | ||
|
Description
Cette mesure quantifie le temps nécessaire à la phase de mise en œuvre de la modification. Elle est calculée comme la durée entre les activités « Change Implementation Started » et « Change Implemented ». Cet attribut sert à calculer le KPI du délai moyen de mise en œuvre des modifications et alimente le Dashboard « Flux et retards de mise en œuvre des modifications ». Il permet de distinguer les retards de planification des retards d'exécution, afin que les équipes concentrent leurs efforts d'amélioration sur les travaux techniques de mise en œuvre.
Pourquoi c’est important
Isole les performances de la phase de mise en œuvre proprement dite et aide à identifier les goulots d’étranglement techniques ou liés aux ressources, indépendamment des retards d’approbation.
Où les obtenir
Calculé dans l'outil de Process Mining ou lors de la transformation des données, en déterminant l'écart entre les horodatages des événements de début et de fin de la mise en œuvre.
Exemples
4 heures 15 minutes1 jour 2 heures30 minutes
|
|||
|
Motif du rejet
ChangeRejectionReason
|
Description textuelle ou catégorie expliquant pourquoi une demande de modification a été rejetée. | ||
|
Description
Lorsqu'une demande de modification est rejetée, cet attribut enregistre le motif fourni par l'approbateur. Il peut s'agir d'une valeur sélectionnée dans une liste prédéfinie ou d'une explication en texte libre. Ces informations sont essentielles au Dashboard « Analyse des demandes de modification rejetées ». En catégorisant et en analysant les motifs de rejet, les organisations peuvent identifier les problèmes récurrents des demandes, tels que des informations incomplètes, une évaluation des risques insuffisante ou des conflits métier. Ces analyses peuvent servir à améliorer la qualité des futures demandes de modification.
Pourquoi c’est important
Fournit une visibilité directe sur les raisons des échecs et permet d'améliorer de manière ciblée les processus de soumission et d'évaluation afin de réduire le taux global de rejet.
Où les obtenir
Ces données sont souvent enregistrées dans un champ dédié « Rejection Reason » ou dans un champ de notes renseigné lorsque le statut passe à « Rejected ».
Exemples
Détails insuffisants dans le plan de mise en œuvreÉvaluation des risques incomplèteConflits avec d'autres changements planifiés
|
|||
|
Priorité de la modification
ChangePriority
|
Niveau de priorité de la demande de modification, indiquant son urgence et son impact métier. | ||
|
Description
La priorité du changement est une classification déterminée en combinant son urgence et son impact. Elle aide les équipes à hiérarchiser leur travail et à affecter efficacement les ressources, afin que les changements les plus importants soient traités en premier. Dans l’analyse, la priorité permet de vérifier si les changements prioritaires sont traités plus rapidement que les changements moins prioritaires. Tout écart par rapport à cette attente peut révéler des inefficacités ou des goulots d’étranglement dans la hiérarchisation ou l’exécution du processus.
Pourquoi c’est important
Aide à vérifier si le processus donne correctement la priorité aux modifications à fort impact et si celles-ci sont effectivement accélérées comme prévu.
Où les obtenir
Il s'agit généralement d'un champ nommé « Priority » dans l'objet Change Request. Sa valeur peut être définie manuellement ou calculée à partir des champs d'impact et d'urgence.
Exemples
1 - Critique2 - Élevée3 - Moyenne4 - Faible
|
|||
|
Service affecté
ServiceAffected
|
Service métier principal ou élément de configuration (CI) affecté par la modification. | ||
|
Description
Cet attribut identifie le principal service informatique, l'application ou l'élément d'infrastructure visé par la demande de modification. Il relie le processus de gestion du changement à l'environnement plus large de la gestion des services informatiques. L'analyse par service affecté est essentielle au KPI « Principaux types de modifications problématiques », car elle permet d'identifier les services qui font le plus souvent l'objet de modifications et ceux qui sont associés à des taux de rejet ou à des retards élevés. Elle fournit aux responsables de services des éléments utiles pour améliorer la stabilité et gérer la dette technique.
Pourquoi c’est important
Relie les modifications à des services métier précis et permet d'identifier les services les plus instables ou ceux qui génèrent le plus de modifications problématiques.
Où les obtenir
Cet attribut est généralement lié depuis la base de données de gestion des configurations (CMDB) et stocké dans un champ « Primary CI » ou « Service » de l'objet Change Request.
Exemples
Service de messagerie (Exchange)Système ERP (SAP)Commutateur réseau central (CISCO-4500X)
|
|||
|
Unité opérationnelle
BusinessUnit
|
Unité opérationnelle ou service ayant demandé la modification ou qui en bénéficiera. | ||
|
Description
Cet attribut associe la demande de modification à une partie précise de l'organisation, comme « Finance », « Marketing » ou « Operations ». Il apporte un contexte métier à un processus par ailleurs technique. L'analyse par unité opérationnelle permet de comprendre d'où provient la demande de modification. Elle peut contribuer aux modèles de refacturation, à l'évaluation de l'impact des changements informatiques sur les différentes fonctions métier et à l'identification des unités dont les modifications sont plus complexes ou plus souvent retardées.
Pourquoi c’est important
Fournit un contexte métier et permet d'analyser la demande de modifications, leur impact et leur performance du point de vue de l'organisation.
Où les obtenir
Il peut s'agir d'un champ de l'objet Change Request ou d'une valeur héritée du profil utilisateur du demandeur.
Exemples
FinanceRessources humainesVentes et marketingOpérations
|
|||
Activités de gestion du changement
| Activité | Description | ||
|---|---|---|---|
|
Demande de changement créée
|
Cette activité marque le lancement d’une nouvelle demande de changement dans le système. Elle est généralement enregistrée lorsqu’un nouvel enregistrement est créé dans l’objet métier Change Request, ce qui établit le point de départ de l’ensemble du processus. | ||
|
Pourquoi c’est important
Il s’agit du principal événement de début du processus. L’analyse du délai entre cette activité et les suivantes révèle la durée totale du cycle de vie et aide à identifier les retards en amont.
Où les obtenir
Cet événement est enregistré à partir de l’horodatage de création de l’enregistrement Change Request. Dans Ivanti Cherwell, cette information est généralement stockée dans le champ « CreatedDateTime » de l’objet métier Change Request.
Collecte
Enregistré directement à partir de l’horodatage de création de l’enregistrement.
Type d’événement
explicit
|
|||
|
Impact et risques évalués
|
Cette activité indique que l’analyse des risques et de l’impact de la demande de changement est terminée. Elle est généralement déduite lorsque l’état de la demande passe à un état indiquant qu’elle est prête à être approuvée, tel que « Awaiting Approval ». | ||
|
Pourquoi c’est important
Le suivi de cette activité permet de mesurer la durée de la phase d’évaluation et de vérifier que l’analyse des risques est systématiquement réalisée avant l’approbation, ce qui contribue à l’indicateur KPI de respect de l’évaluation des risques.
Où les obtenir
Déduit de l’historique de l’objet Change Request. L’événement est enregistré à l’horodatage auquel le champ « Status » passe de « Assessing » à un état tel que « Awaiting CAB Approval ».
Collecte
Déduit du passage à l’état « Awaiting CAB Approval ».
Type d’événement
inferred
|
|||
|
Modification approuvée par le CAB
|
Jalon essentiel au cours duquel le Change Advisory Board (CAB) ou l'autorité désignée approuve la mise en œuvre de la modification. Cette étape est déduite lorsque le statut de la demande de modification est mis à jour sur « Approved ». | ||
|
Pourquoi c’est important
Cette activité constitue le point final de mesure du délai d'approbation. Elle débloque le processus, permettant de commencer la planification et la mise en œuvre, et joue un rôle essentiel dans le KPI du délai d'approbation des modifications.
Où les obtenir
Déduit de l'historique d'audit de l'objet Change Request, en particulier de l'horodatage correspondant au passage du champ « Status » à « Approved ».
Collecte
Déduit du changement de statut vers « Approved ».
Type d’événement
inferred
|
|||
|
Modification clôturée
|
Cette activité constitue le point final réussi du processus de gestion du changement. Elle est capturée lorsque le statut de la demande passe à « Closed », ce qui indique que tous les travaux sont terminés. | ||
|
Pourquoi c’est important
En tant que principal point de réussite, cette activité est essentielle au calcul du délai de bout en bout des modifications menées à bien. Elle confirme que toutes les étapes du processus sont terminées.
Où les obtenir
Cette étape est déduite de l'horodatage du changement de statut final vers « Closed » dans l'historique d'audit de l'objet Change Request.
Collecte
Déduit du changement de statut final vers « Closed ».
Type d’événement
inferred
|
|||
|
Modification mise en œuvre
|
Ce jalon indique que les travaux techniques liés à la modification sont terminés. Il est capturé lorsque le statut de la demande passe à « Implemented » ou à un état similaire, dans l'attente de la vérification. | ||
|
Pourquoi c’est important
Il s'agit d'un jalon de réussite essentiel et d'une donnée importante pour les KPI du taux d'achèvement des modifications dans les délais et du délai moyen de mise en œuvre des modifications. Il marque la fin de la phase d'exécution.
Où les obtenir
Déduit du journal d'audit de l'objet Change Request, à partir de l'horodatage du changement de statut vers « Implemented » ou « Pending Verification ».
Collecte
Déduit du changement de statut vers « Implemented ».
Type d’événement
inferred
|
|||
|
Modification planifiée
|
Cette activité marque le moment où la date et l'heure de mise en œuvre de la modification sont officiellement confirmées et enregistrées. Elle est capturée lorsque le statut passe à « Scheduled ». | ||
|
Pourquoi c’est important
Il s'agit d'un jalon d'engagement important. La modification passe ainsi du stade de concept approuvé à celui d'action planifiée, ce qui constitue un préalable à sa mise en œuvre.
Où les obtenir
Déduit de l'historique de l'objet Change Request, en capturant l'horodatage correspondant à la mise à jour du champ « Status » sur « Scheduled ».
Collecte
Déduit du changement de statut vers « Scheduled ».
Type d’événement
inferred
|
|||
|
Revue postérieure à la mise en œuvre effectuée
|
Cette activité indique qu'une revue formelle de la modification terminée a été réalisée afin d'en évaluer la réussite et de consigner les enseignements tirés. Elle est souvent déduite d'un changement de statut vers « Post Implementation Review ». | ||
|
Pourquoi c’est important
Son suivi permet de boucler la boucle de retour d'expérience sur les modifications. Il est essentiel à l'amélioration continue et alimente directement le KPI du taux de revues postérieures à la mise en œuvre.
Où les obtenir
Déduit de l'historique d'audit de l'objet Change Request, en capturant l'horodatage correspondant au passage du champ « Status » à un état tel que « Post Implementation Review ».
Collecte
Déduit du changement de statut vers « Post Implementation Review ».
Type d’événement
inferred
|
|||
|
Changement en attente d’approbation
|
Cette activité représente la période pendant laquelle une demande de changement attend officiellement la décision du Change Advisory Board, ou CAB, ou d’une autre autorité d’approbation. Elle est déduite d’un état tel que « Pending Approval » ou « Awaiting CAB ». | ||
|
Pourquoi c’est important
Il s’agit d’une activité d’attente importante. L’analyse de sa durée aide à repérer les goulots d’étranglement du flux d’approbation, qui constitue une source fréquente de retards dans la Gestion du changement.
Où les obtenir
Enregistré à partir de l’horodatage auquel le champ « Status » de l’objet métier Change Request est mis à jour avec la valeur « Pending Approval » ou une valeur équivalente.
Collecte
Identifié par l’entrée dans l’état « Pending Approval ».
Type d’événement
inferred
|
|||
|
Demande de changement soumise pour évaluation
|
Cette activité représente la soumission officielle d’une demande de changement nouvellement créée pour une première évaluation. Elle est généralement déduite lorsque l’état de la demande passe de « New » ou « Draft » à un état tel que « Assessing ». | ||
|
Pourquoi c’est important
Cette activité marque le début du processus formel de changement après la saisie initiale des données. Le délai entre la création et la soumission peut révéler des besoins de formation des utilisateurs ou des points de friction dans le processus.
Où les obtenir
Déduit du journal d’audit ou de l’historique de l’objet Change Request, en identifiant l’horodatage auquel le champ « Status » prend une valeur telle que « Assessing » ou « Submitted ».
Collecte
Déduit du changement d’état de « New » à « Assessing ».
Type d’événement
inferred
|
|||
|
Mise en œuvre de la modification commencée
|
Représente le début de l'exécution technique de la modification. Cette étape est généralement déduite lorsque le statut de la demande passe à « In Progress » ou « Implementing ». | ||
|
Pourquoi c’est important
Cette activité marque le début de la fenêtre de mise en œuvre. Le délai entre cette étape et « Change Implemented » correspond à la durée réelle de mise en œuvre, un élément essentiel du délai global du processus.
Où les obtenir
Déduit de l'historique d'audit de l'objet Change Request. Il s'agit de l'horodatage correspondant à la mise à jour du champ « Status » vers une valeur telle que « In Progress » ou « Implementing ».
Collecte
Déduit du changement de statut vers « In Progress ».
Type d’événement
inferred
|
|||
|
Modification annulée
|
Représente un état final dans lequel une demande de modification approuvée ou en cours est retirée avant son achèvement. Cet événement est capturé lorsque le statut passe à « Cancelled ». | ||
|
Pourquoi c’est important
Il s'agit d'un point final alternatif du processus. L'analyse des raisons et du moment des annulations peut révéler des problèmes de planification, d'affectation des ressources ou d'évolution des priorités métier.
Où les obtenir
Déduit de l'historique d'audit, en capturant l'horodatage correspondant à la mise à jour du champ « Status » de l'objet Change Request sur « Cancelled ».
Collecte
Déduit du changement de statut vers « Cancelled ».
Type d’événement
inferred
|
|||
|
Modification rejetée
|
Cette activité représente la décision finale de rejeter la demande de modification pendant la phase d'approbation. Elle est enregistrée lorsque le statut de la demande de modification est défini sur « Rejected ». | ||
|
Pourquoi c’est important
Il s'agit d'un point d'échec critique. L'analyse des modifications rejetées et de leurs motifs contribue à améliorer la qualité des demandes initiales et alimente le KPI du taux de rejet des demandes de modification.
Où les obtenir
Déduit de l'horodatage correspondant à la mise à jour du champ « Status » de l'objet Change Request sur « Rejected » dans l'historique d'audit.
Collecte
Déduit du changement de statut vers « Rejected ».
Type d’événement
inferred
|
|||
|
Plan de mise en œuvre élaboré
|
Marque l'achèvement de la planification détaillée de la modification, notamment la définition des tâches, des ressources et des plans de retour arrière. Cette étape est souvent déduite lorsque la modification passe de « Approved » à « Scheduled ». | ||
|
Pourquoi c’est important
La durée de cette activité révèle l'efficacité de la phase de planification de la modification. Les retards à ce stade peuvent affecter le calendrier global, même après l'approbation.
Où les obtenir
Cette étape peut être déduite de l'horodatage du changement de statut de « Approved » à « Scheduled ». Elle peut également être associée au renseignement de certains champs de planification.
Collecte
Déduit du changement de statut de « Approved » à « Scheduled ».
Type d’événement
inferred
|
|||
|
Vérification de la modification effectuée
|
Représente la phase de test et de validation destinée à confirmer que la modification a réussi et n'a entraîné aucun effet indésirable. Cette étape est déduite d'un changement de statut vers « Verification » ou « Testing ». | ||
|
Pourquoi c’est important
L'analyse de la fréquence et de la durée de cette activité permet de vérifier que les étapes d'assurance qualité ne sont pas omises. Il s'agit d'une étape essentielle pour prévenir les incidents causés par les modifications.
Où les obtenir
Capturé à partir de l'horodatage d'un changement de statut de l'objet Change Request, par exemple lors du passage à « Verification » ou « User Acceptance Testing ».
Collecte
Déduit du changement de statut vers « Verification ».
Type d’événement
inferred
|
|||
Guides d’extraction
Prêt à commencer ?
Utilisez ce modèle pour lancer rapidement l’analyse de votre processus de Gestion du changement et obtenir des améliorations significatives. Commencez dès aujourd’hui à optimiser vos mises à jour et à les rendre plus efficaces.
Atteignez 95 % de changements réussis : optimisez Ivanti Cherwell dès maintenant
Éliminez les goulots d’étranglement, réduisez les risques et atteignez un taux de réussite des changements de 95 %.
Aucune carte bancaire requise. Commencez immédiatement.