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

Cet attribut enregistre le nom de l’activité réalisée à un moment précis pour une demande de changement. Ces activités sont déduites des transitions de statut, des étapes du flux de travail ou de certaines entrées de journal dans Jira, telles que « Change Submitted For Review » ou « Implementation Started ».

L’analyse de la séquence et de la fréquence de ces activités constitue le cœur du Process Mining. Elle permet de découvrir les flux réels du processus, d’identifier les goulots d’étranglement entre les étapes et d’analyser les variantes du processus par rapport à la procédure standard.

Il définit les étapes du processus, ce qui est essentiel pour découvrir les cartes de processus, analyser les variantes et identifier les goulots d’étranglement.

Généralement déduit de l’historique de la demande Jira, notamment des transitions d’état ou des mises à jour de champs personnalisés représentant des jalons du processus.

L’heure de début, ou horodatage de l’événement, indique la date et l’heure précises auxquelles une activité a été enregistrée pour une demande de changement. Chaque activité du journal d’événements, de la création à la clôture, est associée à un horodatage.

Cet attribut est essentiel pour toutes les analyses temporelles du Process Mining. Il sert à calculer les durées de cycle, les délais entre les activités et les temps d’attente, ainsi qu’à déterminer la séquence des événements. Il constitue la base du suivi des performances, du calcul du respect des SLA et de l’identification des goulots d’étranglement.

Cet horodatage constitue la base de toutes les analyses de performance et de durée. Il permet de calculer les temps de cycle et d’identifier les retards.

L’horodatage de chaque entrée dans le journal d’historique des tickets Jira. Pour l’événement de création, il s’agit du champ created.

L’identifiant de la demande de changement est la clé primaire qui identifie de manière unique chaque initiative de changement dans Jira Service Management. Il sert d’identifiant de cas pour le Process Mining et relie tous les événements, changements d’état et mises à jour afin de fournir une vue cohérente du processus de bout en bout.

Lors de l’analyse, cet identifiant permet de reconstituer le cycle de vie complet de chaque changement. Il est essentiel pour suivre les changements individuels à travers différentes étapes, comme l’évaluation des risques, l’approbation, la mise en œuvre et la revue. Toutes les métriques, tous les KPI et tous les Dashboards s’appuient sur cet attribut pour agréger et corréler correctement les données d’événements associées à un changement donné.

Il s’agit de l’identifiant de cas fondamental, qui permet de retracer l’intégralité du parcours d’une demande de changement et d’en analyser les performances.

Il s’agit de la clé standard de la demande Jira, présente dans le champ key pour les demandes de type Change.

Cet attribut enregistre la date et l’heure auxquelles les données ont été extraites pour la dernière fois du système source. Il indique le niveau d’actualité des données dans l’outil de Process Mining.

L’analyse de cet attribut aide à comprendre dans quelle mesure les données du processus sont à jour, ce qui est important pour les Dashboards opérationnels et la surveillance en temps réel. Elle fournit le contexte nécessaire à l’analyse et garantit que les décisions ne reposent pas sur des données obsolètes.

Indique le niveau d’actualité des données afin de garantir que les analyses restent pertinentes et reposent sur des informations à jour.

Il s’agit d’un champ de métadonnées renseigné par l’outil d’extraction au moment de l’extraction des données.

Cet attribut indique le système source dans lequel les données du processus ont été générées. Dans ce contexte, sa valeur est toujours « Jira Service Management ».

Dans un contexte d’entreprise plus large, où les données peuvent être regroupées à partir de plusieurs systèmes, ce champ est essentiel pour assurer la traçabilité des données, résoudre les problèmes et comprendre les variations du processus propres à chaque système. Il garantit la clarté de l’origine des données analysées.

Fournit une traçabilité claire des données, indispensable lors de la combinaison de données provenant de plusieurs systèmes ou à des fins d’audit.

Il s’agit d’une valeur statique ajoutée lors de l’extraction des données afin d’indiquer l’origine du jeu de données.

Cet attribut enregistre la date à laquelle la demande de changement doit être terminée pour respecter son SLA. Elle constitue la référence par rapport à laquelle le délai réel d’achèvement est mesuré.

Cette date est fondamentale pour suivre la performance par rapport aux engagements. Elle sert de base au Dashboard « Suivi de la performance des SLA de changement » et au KPI « Taux de respect des SLA de changement ». En comparant la date réelle de résolution à cette date cible, les organisations peuvent mesurer l’efficacité de leur prestation de services.

Il s’agit du principal point de données utilisé pour calculer le respect des SLA et identifier les changements susceptibles de dépasser leur date limite.

Il s’agit souvent du champ duedate dans Jira ou d’une valeur issue d’une métrique SLA configurée dans Jira Service Management.

Le niveau de risque constitue une évaluation obligatoire dans la plupart des processus de Gestion du changement. Il catégorise l’impact négatif potentiel d’un changement. Le niveau est déterminé pendant la phase d’évaluation des risques et influence souvent le flux de travail d’approbation requis.

Dans le Process Mining, cet attribut est essentiel à l’analyse fondée sur les risques. Il alimente le Dashboard « Risk Assessment Accuracy & Outcome » en mettant en relation le risque initial et le résultat réel. Il constitue également la dimension principale du KPI « Change Failure Rate by Risk Level », qui aide à évaluer l’efficacité de la gestion des changements à haut risque.

Permet d’analyser l’efficacité des contrôles du processus et des flux de travail d’approbation selon les profils de risque, et de mettre en relation le risque et les taux d’échec des changements.

Il s’agit généralement d’un champ personnalisé dans Jira Service Management. Les noms courants sont « Risk Level » ou « Impact ».

Le champ Priorité aide les équipes à déterminer l’ordre de traitement des demandes de changement. Il reflète une combinaison de l’impact et de l’urgence, et guide la planification ainsi que l’allocation des Ressources.

L’analyse de la priorité permet de comparer la performance des changements hautement prioritaires et des changements moins prioritaires. Vous pouvez notamment vérifier si les changements prioritaires ont réellement des temps de cycle plus courts ou s’ils se heurtent aux mêmes goulots d’étranglement que les autres changements. Cette analyse est utile pour mieux orienter les Ressources et répondre aux attentes de l’entreprise.

Permet d’analyser la performance du processus en fonction de la priorité métier et de vérifier que les changements essentiels sont traités plus rapidement, comme prévu.

Il s’agit du champ standard priority d’un ticket Jira.

L’Assignee est l’utilisateur chargé de l’étape ou de l’activité en cours dans le flux de travail de Gestion du changement. Cette personne peut changer plusieurs fois au cours du cycle de vie d’une demande de changement, lorsque celle-ci passe d’une personne ou d’une équipe à une autre.

Cet attribut sert à analyser la répartition de la charge de travail, à identifier les goulots d’étranglement propres à certains utilisateurs et à comprendre l’affectation des ressources. Le Dashboard « Change Team Activity Workload » s’appuie sur ces données pour montrer quelles personnes ou quels groupes traitent le plus d’activités.

Aide à analyser la performance des Ressources et la répartition de la charge de travail, tout en identifiant les goulots d’étranglement individuels ou liés aux équipes.

Il s’agit du champ standard assignee d’un ticket Jira.

Cet attribut indique le statut de la demande de changement, par exemple « Awaiting Approval », « In Progress » ou « Closed ». Le champ de statut de Jira est essentiel au moteur de flux de travail, et les modifications apportées à ce champ déterminent en grande partie le déroulement du processus.

L’analyse du statut permet de suivre l’avancement des changements actifs et de comprendre les résultats des changements terminés, par exemple « Closed - Successful » par rapport à « Closed - Failed ». Elle est essentielle pour créer des Dashboards de débit et analyser les boucles de reprise lorsqu’un statut revient à un état antérieur.

Fournit une vision claire de l’avancement et du résultat final d’une demande de changement, ce qui est essentiel pour analyser le débit et les reprises.

Il s’agit du champ standard status d’une demande Jira. Les statuts disponibles sont définis dans la configuration du flux de travail du projet.

Cet attribut calculé compare la date réelle de résolution d’une demande de changement à sa « Date cible d’achèvement ». Le résultat est un statut simple, tel que « Respecté » ou « Dépassé ».

Il fournit un indicateur clair et immédiat de la performance pour le Dashboard « Suivi de la performance des SLA de changement ». Il simplifie la création de KPI tels que le « Taux de respect des SLA de changement » en calculant au préalable le statut de chaque cas. Vous pouvez ainsi filtrer et agréger facilement les données pour déterminer quels types de changement, quelles équipes ou quels services sont le plus souvent associés à des dépassements de SLA.

Fournit un résultat binaire clair sur la performance du SLA pour chaque cas, ce qui simplifie le reporting et l’analyse du respect des SLA.

Calculé en comparant l’horodatage de l’activité finale « Change Closed » à l’attribut « TargetCompletionDate ».

Le type de changement catégorise la demande selon sa nature, son urgence et son impact. Les types courants comprennent « Standard » pour les changements préapprouvés et présentant peu de risques, « Normal » pour les changements courants nécessitant une approbation complète, et « Urgent » pour les changements nécessaires à la résolution rapide d’incidents.

Cet attribut est essentiel à l’analyse du processus, car les différents types de changement suivent souvent des parcours distincts et sont associés à des SLA différents. Il sert à calculer le KPI « Taux de changements urgents » et à filtrer les Dashboards afin de comparer la performance et le risque associés à chaque type.

Il permet de segmenter le processus afin d’analyser différents flux de travail, par exemple les changements standard et les changements urgents, qui présentent des attentes en matière de performance et des risques spécifiques.

Il s’agit généralement d’un champ personnalisé dans les projets Jira Service Management. Son nom peut varier, mais il est souvent appelé « Change Type ».

Le déclarant est la personne qui a créé la demande de changement dans Jira. Il s’agit souvent du responsable du changement ou d’une personne qui l’initie au nom d’une équipe.

L’analyse du déclarant peut aider à identifier les services, équipes ou personnes à l’origine du plus grand nombre de changements. Elle peut également servir à repérer les tendances liées aux sources des changements et à proposer un accompagnement ou une formation aux groupes qui soumettent fréquemment des demandes incomplètes ou de qualité insuffisante.

Aide à identifier l’origine des demandes de changement, afin d’améliorer la qualité des soumissions initiales.

Il s’agit du champ standard reporter d’un ticket Jira.

Cet attribut identifie l’équipe chargée de traiter le changement. Jira dispose d’un champ « Assignee » pour les personnes, mais un champ « Team » est souvent utilisé pour attribuer le travail à un groupe fonctionnel, tel que « Network Operations » ou « Database Administrators ».

Il est essentiel au Dashboard « Charge de travail des activités de l’équipe de changement ». Il permet d’analyser la performance et les goulots d’étranglement au niveau de l’équipe, plutôt qu’au seul niveau individuel, ce qui est souvent plus utile pour planifier et gérer les Ressources.

Facilite l’analyse de la charge de travail et de la performance au niveau de l’équipe ou du service, en mettant en évidence les goulots d’étranglement systémiques.

Il s’agit généralement d’un champ personnalisé dans Jira, car aucun champ standard « Team » n’existe. Il peut être de type « Group Picker » ou prendre la forme d’une simple liste de sélection.

Cet attribut calculé identifie les demandes de changement renvoyées à une étape précédente pour être modifiées, par exemple lorsqu’elles passent de « En attente d’approbation » à « Planification ». Il indique que la soumission initiale était incomplète, incorrecte ou ne répondait pas aux critères requis.

Cet indicateur sert de base au KPI « Taux de reprise des changements » et au Dashboard « Analyse des reprises et des rejets de changements ». En identifiant les cas de reprise, les analystes peuvent facilement les filtrer et rechercher leurs causes profondes, telles qu’une planification initiale insuffisante, des exigences peu claires ou une évaluation des risques incomplète.

Met en évidence l’inefficacité du processus en signalant explicitement les cas qui ont nécessité un travail supplémentaire non planifié, afin d’analyser les causes profondes des reprises.

Calculé en analysant la séquence des activités dans le journal d’événements. Une reprise est détectée lorsqu’une activité d’une étape ultérieure est suivie d’une activité d’une étape antérieure.

Cet attribut indique si le changement a entraîné un résultat négatif, tel qu’un incident en production. Cela implique souvent de relier la demande de changement à un ou plusieurs tickets d’incident dans Jira.

Ces données sont essentielles pour calculer les KPI « Taux d’incidents après mise en œuvre » et « Taux d’échec des changements ». Elles fournissent une mesure directe de la qualité des changements et de l’efficacité des processus de planification, de test et d’évaluation des risques. L’analyse des changements à l’origine d’incidents aide à améliorer les contrôles et à prévenir de futurs échecs.

Mesure directement la qualité et la réussite d’un changement en vérifiant s’il a entraîné des problèmes opérationnels ultérieurs.

Cet attribut est généralement obtenu en recherchant les tickets liés dans Jira, notamment les liens « is caused by » provenant de tickets d’incident vers un ticket de changement.

Cet attribut décrit la raison sous-jacente du changement, par exemple « Mise en œuvre d’une nouvelle fonctionnalité », « Correction d’un bug » ou « Mise à niveau de l’infrastructure ». Il fournit un contexte important au-delà du résumé ou de la description.

Dans l’analyse, le motif du changement peut être mis en relation avec d’autres indicateurs, tels que le temps de cycle, le taux d’échec et le niveau de risque. Cela permet de répondre à des questions comme : « Les changements liés à la correction de bugs sont-ils approuvés plus rapidement que ceux qui concernent la mise en œuvre de nouvelles fonctionnalités ? » ou « Les mises à niveau de l’infrastructure présentent-elles un taux d’échec plus élevé ? »

Fournit le contexte métier nécessaire à une analyse approfondie, en mettant en relation l’objectif d’un changement avec sa performance et son résultat.

Il s’agit généralement d’un champ personnalisé dans Jira Service Management, souvent une liste de sélection ou un champ texte.

Lorsqu’une demande de changement est clôturée, le champ Résolution fournit des informations précises sur le résultat. Par exemple, « Done » indique une réussite, tandis que « Won’t Do » ou « Duplicate » correspondent à d’autres motifs de clôture. Ce champ apporte davantage de contexte que le seul statut « Closed ».

Cet attribut est essentiel pour analyser les taux de réussite et d’échec des changements. Par exemple, le KPI « Taux d’incidents après mise en œuvre » peut être mieux interprété en filtrant les changements dont la résolution est « Failed » ou « Rolled Back ». Il permet de distinguer les changements correctement mis en œuvre de ceux qui ont été annulés ou rejetés après approbation.

Fournit un contexte détaillé sur le résultat final d’un changement, ce qui est essentiel pour calculer précisément les taux de réussite et d’échec.

Il s’agit du champ standard resolution dans Jira, généralement renseigné lorsqu’un ticket passe dans une catégorie de statut « Done ».

Cet attribut relie la demande de changement à un service métier précis défini dans la Configuration Management Database (CMDB), tel que « Email Service » ou « Customer CRM ». Il s’agit d’un concept essentiel pour comprendre l’impact métier d’un changement.

L’analyse des changements par service métier aide à hiérarchiser les efforts et à communiquer l’impact aux parties prenantes. Elle permet d’identifier les services qui font l’objet du plus grand nombre de changements, ceux qui présentent le plus de risques et les services où les incidents liés aux changements sont les plus concentrés. Cette analyse est indispensable pour gérer les changements techniques dans une perspective métier.

Relie les changements techniques à leur impact métier et permet de hiérarchiser les priorités et d’analyser les risques selon la criticité du service affecté.

Il s’agit souvent d’un champ personnalisé dans JSM, fréquemment lié à Jira Assets, anciennement Insight, ou à une autre CMDB.