Votre modèle de données pour la gestion du changement

Cet attribut enregistre le nom de l'activité qui a eu lieu à un moment précis pour une demande de changement. Ces activités sont dérivées des transitions de statut, des étapes de workflow ou d'entrées de journal spécifiques au sein de 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 est au cœur du Process Mining. Elle permet la découverte des flux de processus réels, l'identification des goulots d'étranglement entre les étapes et l'analyse des variantes de processus par rapport à la procédure opérationnelle 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érivé de l'historique du ticket Jira, spécifiquement des transitions de statut ou des mises à jour de champs personnalisés qui représentent des jalons de processus.

L'Heure de Début, ou timestamp d'événement, marque la date et l'heure précises auxquelles une activité a été enregistrée pour une demande de changement. Chaque activité dans l'event log, de la création à la clôture, a un timestamp associé.

Cet attribut est critique pour toutes les analyses basées sur le temps en Process Mining. Il est utilisé pour calculer les temps de cycle, les durées entre les activités, les temps d'attente et pour déterminer la séquence des événements. Il constitue la base pour le suivi des performances, les calculs de conformité aux SLA et l'identification des goulots d'étranglement.

Ce timestamp est le fondement de toutes les analyses de performance et de durée, permettant le calcul des temps de cycle et l'identification des retards.

Le timestamp 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'ID de la demande de changement est la clé primaire qui identifie de manière unique chaque initiative de changement au sein de Jira Service Management. Il sert d'identifiant de cas pour le Process Mining, liant tous les événements, changements de statut et mises à jour dans une vue de processus cohérente de bout en bout.

En analyse, cet ID permet la reconstruction du cycle de vie complet de chaque changement. Il est essentiel pour le suivi des changements individuels à travers diverses étapes comme l'évaluation des risques, l'approbation, l'implémentation et la revue. Tous les indicateurs, KPI et dashboards s'appuient sur cet attribut pour agréger et corréler correctement les données d'événement pour un changement spécifique.

C'est l'identifiant de cas fondamental, permettant de tracer le parcours complet d'une demande de changement et d'analyser sa performance.

C'est la clé de ticket Jira standard, trouvée dans le champ key pour les tickets de type demande de changement.

Cet attribut enregistre la date et l'heure de la dernière extraction des données du système source. Il représente la fraîcheur des données au sein de l'outil de Process Mining.

L'analyse de cet attribut aide les utilisateurs à comprendre à quel point les données du processus sont actuelles, ce qui est important pour les dashboards opérationnels et la surveillance en temps réel. Il fournit un contexte pour l'analyse, garantissant que les décisions ne sont pas prises sur des données obsolètes.

Indique la fraîcheur des données, garantissant que les analyses sont pertinentes et basées sur des informations à jour.

Ceci est un champ de métadonnées renseigné par l'outil d'extraction de données au moment de la récupération des données.

Cet attribut spécifie le système source d'où proviennent les données du processus. Dans ce contexte, la valeur est constamment 'Jira Service Management'.

Dans un contexte d'entreprise plus large où les données pourraient être fusionnées à partir de plusieurs systèmes, ce champ est crucial pour la lignée des données, le dépannage et la compréhension des variations de processus spécifiques au système. Il assure la clarté sur l'origine des données analysées.

Fournit une provenance claire des données, essentielle lors de la combinaison de données provenant de plusieurs systèmes ou à des fins d'audit.

Ceci est une valeur statique ajoutée lors de l'extraction des données pour étiqueter l'origine de l'ensemble de données.

Cet attribut stocke la date à laquelle la demande de changement doit être complétée pour respecter son SLA. C'est la référence par rapport à laquelle le temps d'achèvement réel est mesuré.

Cette date est fondamentale pour le suivi de la performance par rapport aux engagements. Elle est la base du dashboard 'Change SLA Performance Monitor' et du KPI 'Change SLA Adherence Rate'. En comparant la date de résolution réelle avec cette cible, les organisations peuvent mesurer l'efficacité de leur prestation de services.

C'est le point de données primaire pour calculer la conformité aux SLA et identifier les changements qui risquent de ne pas respecter leurs échéances.

Ceci est souvent le champ duedate dans Jira ou une valeur provenant d'une métrique SLA configurée dans Jira Service Management.

Ceci est une métrique calculée qui mesure le temps écoulé entre l'activité 'Change Submitted For Review' et l'activité 'Change Request Approved'. Elle isole la phase d'approbation du cycle de vie du changement pour une analyse ciblée.

Cette métrique supporte directement le dashboard 'Change Approval Cycle Time' et le KPI correspondant. Elle est utilisée pour identifier les goulots d'étranglement dans le processus d'approbation, qu'ils soient liés à des groupes d'approbation spécifiques, des types de changement ou des niveaux de risque. Réduire ce temps peut accélérer considérablement le processus global de livraison des changements.

Mesure directement l'efficacité de la phase d'approbation, aidant à identifier et à traiter les retards dans l'autorisation des changements.

Calculé en soustrayant le timestamp de 'Changement Soumis Pour Révision' du timestamp de 'Demande de Changement Approuvée' pour un ID de Demande de Changement donné.

Le Niveau de Risque est une évaluation obligatoire dans la plupart des processus de gestion du changement, catégorisant l'impact négatif potentiel d'un changement. Le niveau est déterminé pendant la phase d'évaluation des risques et influence souvent le workflow d'approbation requis.

En Process Mining, cet attribut est critique pour l'analyse basée sur les risques. Il supporte le dashboard 'Risk Assessment Accuracy & Outcome' en corrélant le risque initial avec le résultat réel. C'est également la dimension primaire pour le KPI 'Change Failure Rate by Risk Level', aidant à évaluer si les changements à haut risque sont gérés efficacement.

Permet d'analyser si les contrôles de processus et les workflows d'approbation sont efficaces pour différents profils de risque, et aide à corréler le risque avec les taux d'échec de changement.

Ceci est généralement un champ personnalisé dans Jira Service Management. Les noms courants incluent 'Risk Level' ou 'Impact'.

Le champ Priorité aide les équipes à déterminer l'ordre dans lequel traiter les demandes de changement. Il reflète une combinaison d'impact et d'urgence et guide la planification et l'allocation des ressources.

L'analyse de la priorité permet des comparaisons de performance entre les changements de haute et de basse priorité. Par exemple, on peut vérifier si les changements à haute priorité ont réellement des temps de cycle plus courts ou s'ils restent bloqués dans les mêmes goulots d'étranglement que les autres changements. Cela est précieux pour optimiser l'orientation des ressources et répondre aux attentes métier.

Permet l'analyse de la performance des processus basée sur la priorité métier, garantissant que les changements critiques sont accélérés comme prévu.

C'est le champ priority standard sur un ticket Jira.

L'Assigné est l'utilisateur individuel responsable de l'étape ou de l'activité en cours dans le workflow de gestion du changement. L'assigné peut changer plusieurs fois tout au long du cycle de vie d'une demande de changement lorsqu'elle passe entre différentes personnes et équipes.

Cet attribut est utilisé pour analyser la répartition de la charge de travail, identifier les goulots d'étranglement spécifiques aux utilisateurs et comprendre l'allocation des ressources. Le dashboard 'Change Team Activity Workload' s'appuie sur ces données pour montrer quels individus ou groupes gèrent le plus d'activités.

Cela aide à analyser la performance des ressources et la répartition de la charge de travail, identifiant les goulots d'étranglement individuels ou d'équipe.

C'est le champ assignee standard sur un ticket Jira.

Cet attribut indique le statut de la demande de changement, tel que 'Awaiting Approval', 'In Progress' ou 'Closed'. Le champ de statut dans Jira est fondamental pour son moteur de workflow, et les changements à ce champ sont les principaux moteurs du flux de 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'. C'est essentiel pour construire des dashboards de débit et analyser les boucles de reprise où un statut revient à un état antérieur.

Il offre une vue claire de l'avancement et du résultat final d'une demande de changement, ce qui est crucial pour l'analyse du débit et du retravail.

C'est le champ status standard d'un ticket Jira. Les statuts disponibles sont définis dans la configuration du workflow du projet.

Ceci est un attribut calculé qui compare la date de résolution réelle d'une demande de changement avec sa 'Target Completion Date'. Le résultat est un statut simple, tel que 'Met' ou 'Breached'.

Cela fournit un indicateur de performance clair et d'un coup d'œil pour le dashboard 'Change SLA Performance Monitor'. Il simplifie la création de KPI comme 'Change SLA Adherence Rate' en pré-calculant le statut pour chaque cas. Cela permet un filtrage et une agrégation faciles pour voir quels types de changements, équipes ou services sont le plus souvent associés à des violations de SLA.

Fournit un résultat clair et binaire pour la performance des SLA sur chaque cas, simplifiant le reporting et l'analyse de la conformité aux SLA.

Calculé en comparant le timestamp de l'activité finale 'Changement Fermé' avec l'attribut 'TargetCompletionDate'.

Le type de changement catégorise la demande de changement en fonction de sa nature, de son urgence et de son impact. Les types courants incluent 'Standard' pour les changements pré-approuvés à faible risque, 'Normal' pour les changements de routine nécessitant une approbation complète, et 'Emergency' pour les changements urgents visant à corriger des incidents.

Cet attribut est essentiel pour l'analyse des processus car les différents types de changement suivent souvent des parcours de processus différents et ont des SLA différents. Il est utilisé pour calculer le KPI du 'Emergency Change Rate' et pour filtrer les dashboards afin de comparer la performance et le risque associés à chaque type.

Il permet la segmentation du processus pour analyser différents workflows, tels que les changements standards versus les changements d'urgence, qui ont des attentes de performance et des risques uniques.

Ceci est généralement un champ personnalisé dans les projets Jira Service Management. Le nom du champ peut varier mais est souvent appelé 'Change Type'.

Le Reporter est l'individu qui a créé le ticket de demande de changement dans Jira. C'est souvent le propriétaire du changement ou quelqu'un qui initie le changement au nom d'une équipe.

L'analyse du reporter peut aider à identifier quels départements, équipes ou individus initient le plus de changements. Elle peut être utilisée pour repérer les tendances dans les sources de changement et fournir des retours ou des formations aux groupes qui soumettent fréquemment des demandes de changement incomplètes ou de faible qualité.

Aide à identifier les sources des demandes de changement, qui peuvent être analysées pour améliorer la qualité des soumissions initiales.

C'est le champ reporter standard sur un ticket Jira.

Cet attribut identifie l'équipe assignée pour travailler sur le changement. Alors que Jira dispose d'un champ 'Assignee' pour les individus, un champ 'Team' est souvent utilisé pour assigner le travail à un groupe fonctionnel, tel que 'Network Operations' ou 'Database Administrators'.

Ceci est crucial pour le dashboard 'Change Team Activity Workload'. Il permet l'analyse des performances et des goulots d'étranglement au niveau de l'équipe, plutôt qu'au niveau individuel seulement, ce qui est souvent plus utile pour la planification et la gestion des ressources.

Facilite l'analyse de la charge de travail et des performances au niveau de l'équipe ou du département, en mettant en évidence les goulots d'étranglement systémiques.

Ceci est généralement un champ personnalisé dans Jira, car il n'existe pas de champ 'Team' standard. Il peut être de type 'Group Picker' ou une simple liste de sélection.

Cet attribut calculé identifie les demandes de changement qui ont été renvoyées à une étape précédente pour modifications, par exemple, passant de 'Awaiting Approval' à 'Planning'. Cela signale que la soumission initiale était incomplète, incorrecte ou ne répondait pas aux critères nécessaires.

Ce drapeau est la base du KPI 'Change Rework Rate' et du dashboard 'Change Rework and Rejection Analysis'. En signalant les cas de reprise, les analystes peuvent facilement les filtrer et enquêter sur les causes profondes, telles qu'une mauvaise planification initiale, des exigences floues ou une évaluation des risques insuffisante.

Met en évidence l'inefficacité du processus en signalant explicitement les cas qui ont nécessité un travail supplémentaire et imprévu, permettant ainsi l'analyse des causes profondes du retravail.

Calculé en analysant la séquence des activités dans le journal d'événements. Un retravail est détecté si une activité de phase ultérieure est suivie d'une activité de phase antérieure.

Cet attribut capture la raison sous-jacente du changement, telle que 'New Feature Implementation', 'Bug Fix' ou 'Infrastructure Upgrade'. Il fournit un contexte crucial au-delà du résumé ou de la description.

En analyse, la raison d'un changement peut être corrélée avec d'autres métriques comme le temps de cycle, le taux d'échec et le niveau de risque. Cela aide à répondre à des questions telles que : 'Les changements liés aux corrections de bugs sont-ils approuvés plus rapidement que les implémentations de nouvelles fonctionnalités ?' ou 'Les mises à niveau d'infrastructure ont-elles un taux d'échec plus élevé ?'.

Fournit un contexte métier qui permet une analyse plus approfondie en corrélant l'objectif d'un changement avec sa performance et son résultat.

Ceci est généralement un champ personnalisé dans Jira Service Management, souvent une liste de sélection ou un champ de texte.

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

Ces données sont essentielles pour calculer les KPI du 'Post-Implementation Issue Rate' et du 'Change Failure Rate'. Il fournit une mesure directe de la qualité du changement et de l'efficacité des processus de planification, de test et d'évaluation des risques. L'analyse des changements qui entraînent des problèmes aide à affiner les contrôles et à prévenir les défaillances futures.

Mesure directement la qualité et le succès d'un changement en suivant s'il a causé des problèmes opérationnels ultérieurs.

Ceci est généralement dérivé en vérifiant les tickets liés dans Jira, spécifiquement si un ticket de Changement a des liens 'is caused by' provenant de tickets d'Incident.

Lorsqu'une demande de changement est clôturée, le champ Résolution fournit des informations spécifiques sur le résultat. Par exemple, 'Done' indique le succès, tandis que 'Won't Do' ou 'Duplicate' fournissent d'autres raisons de clôture. Cela offre plus de contexte que le seul statut 'Closed'.

Cet attribut est essentiel pour analyser les taux de succès et d'échec des changements. Par exemple, le KPI 'Post-Implementation Issue Rate' peut être mieux compris en filtrant les changements avec une résolution 'Failed' ou 'Rolled Back'. Il aide à distinguer les changements implémentés avec succès 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 crucial pour calculer avec précision les taux de succès et d'échec.

C'est le champ resolution standard dans Jira, qui est généralement défini lorsqu'un ticket passe à une catégorie de statut 'Done'.

Cet attribut relie la demande de changement à un service métier spécifique défini dans la base de données de gestion de configuration (CMDB), tel que 'Email Service' ou 'Customer CRM'. C'est un concept clé pour comprendre l'impact métier d'un changement.

L'analyse des changements par service métier aide à prioriser les efforts et à communiquer l'impact aux parties prenantes. Elle permet d'avoir une vue sur les services qui subissent le plus de changements, ceux qui sont les plus à risque, et où les incidents liés aux changements sont concentrés. C'est vital pour gérer les changements techniques d'un point de vue orienté métier.

Connecte les changements techniques à l'impact métier, permettant la priorisation et l'analyse des risques en fonction de la criticité du service affecté.

Ceci est souvent un champ personnalisé dans JSM, fréquemment lié à Jira Assets (anciennement Insight) ou à une autre CMDB.