> Amélioration continue des processus > Gestion du changement > Jira Service Management > Modèle de données

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

Jira Service Management

Attributs de gestion du changement(19) Activités de gestion du changement(13) Guides d’extraction(3)

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

Ce modèle vous guide dans la collecte des données nécessaires à l’analyse de votre processus de gestion du changement. Il présente les attributs essentiels, les principales activités à suivre et des conseils pratiques pour extraire vos données de Jira Service Management. Utilisez cette ressource pour créer un journal d’événements précis et mieux comprendre votre processus de changement.

Attributs recommandés à collecter
Activités clés à suivre dans votre processus
Conseils d’extraction pour Jira Service Management

Vous découvrez les journaux d’événements ? Découvrez comment créer un journal d’événements pour le Process Mining.

Télécharger le modèle

Attributs de gestion du changement

Voici les champs de données recommandés pour votre journal d’événements afin d’analyser votre processus de gestion du changement de manière complète.

5 Obligatoire 7 Recommandé 7 Facultatif

	Nom	Description
	Activité ActivityName	Nom d’un événement métier ou d’une tâche précise survenu dans le cadre du processus de Gestion du changement.
Description Cet attribut indique le nom de l’activité réalisée à un moment précis dans le cadre d’une demande de changement. Les activités sont déduites des changements d’état, des étapes du flux de travail ou des entrées de journal spécifiques dans Jira, comme « Demande de changement soumise pour examen » ou « Mise en œuvre commencée ». L’analyse de l’ordre et de la fréquence de ces activités est au cœur du Process Mining. Elle permet de découvrir les flux réels du processus, de repérer les goulots d’étranglement entre les étapes et de comparer les variantes du processus à la procédure opérationnelle standard. Pourquoi est-ce important ? Cet attribut définit les étapes du processus. Il est indispensable pour découvrir les cartes de processus, analyser les variantes et repérer les goulots d’étranglement. Où trouver ces données Cet attribut est généralement extrait de l’historique de la demande Jira, notamment des changements d’état ou des mises à jour de champs personnalisés correspondant à des étapes clés du processus. Exemples Demande de changement approuvéeÉvaluation des risques effectuéeChangement mis en œuvreRevue après mise en œuvre terminée
	Heure de début EventTime	Horodatage précis indiquant le moment où une activité ou un événement a eu lieu.
Description 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 à toutes les analyses temporelles en Process Mining. Il sert à calculer les temps de cycle, les durées entre les activités et les temps d’attente, ainsi qu’à déterminer l’ordre 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. Pourquoi est-ce important ? Cet horodatage est à la base de toutes les analyses de performance et de durée. Il permet de calculer les temps de cycle et de repérer les retards. Où trouver ces données Horodatage de chaque entrée du journal d’historique de la demande Jira. Pour l’événement de création, il s’agit du champ `created`. Exemples 2023-10-26T10:00:00Z2023-11-01T14:35:10Z2023-11-05T09:00:00Z
	Identifiant de la demande de changement ChangeRequestId	Identifiant unique d’un cas de demande de changement, qui regroupe toutes les activités associées, de la création à la clôture.
Description L’identifiant de la demande de changement est la clé principale qui distingue 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 reconstituer le processus de bout en bout. Lors de l’analyse, cet identifiant permet de reconstituer le cycle de vie complet de chaque changement. Il est indispensable pour suivre les changements à travers les différentes étapes, de 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 regrouper et mettre en relation correctement les données d’événements propres à chaque changement. Pourquoi est-ce important ? Cet identifiant de cas fondamental permet de retracer le parcours complet d’une demande de changement et d’en analyser les performances. Où trouver ces données Il s’agit de la clé standard d’une demande Jira, disponible dans le champ `key` pour les demandes de type Change. Exemples ITSM-1024CHG-2023-001CR-5921
	Dernière mise à jour des données LastDataUpdate	Horodatage indiquant la dernière actualisation ou extraction des données de cet enregistrement.
Description Cet attribut indique la date et l’heure de la dernière extraction des données depuis le système source. Il renseigne sur leur fraîcheur dans l’outil de Process Mining. Son analyse permet de savoir si les données du processus sont à jour, ce qui est important pour les Dashboards opérationnels et le suivi en temps réel. Elle fournit un contexte utile à l’analyse et évite de prendre des décisions à partir de données obsolètes. Pourquoi est-ce important ? Indique si les données sont à jour, afin que les analyses restent pertinentes et s’appuient sur des informations récentes. Où trouver ces données Il s’agit d’un champ de métadonnées renseigné par l’outil d’extraction au moment de la récupération des données. Exemples 2024-01-15T02:00:00Z2024-01-16T02:00:00Z
	Système source SourceSystem	Indique le système depuis lequel les données de Gestion du changement ont été extraites.
Description Cet attribut indique le système source des données du processus. Dans ce contexte, sa valeur est toujours « Jira Service Management ». À l’échelle d’une entreprise, lorsque des données provenant de plusieurs systèmes sont regroupées, ce champ est essentiel pour suivre leur provenance, résoudre les problèmes et comprendre les variations propres à chaque système. Il permet de connaître clairement l’origine des données analysées. Pourquoi est-ce important ? Cet attribut indique clairement la provenance des données, ce qui est essentiel pour regrouper des données provenant de plusieurs systèmes ou réaliser un audit. Où trouver ces données Il s’agit d’une valeur statique ajoutée lors de l’extraction des données pour en indiquer l’origine. Exemples Jira Service Management
	Date d’achèvement cible TargetCompletionDate	La date prévue ou l’échéance définie par l’accord de niveau de service (SLA) pour terminer la demande de changement.
Description Cet attribut indique la date à laquelle la demande de changement doit être terminée pour respecter son SLA. Elle sert de référence pour mesurer le délai réel d’achèvement. Cette date est essentielle au suivi du respect des engagements. Elle sert de base au Dashboard « Suivi des performances du SLA des changements » et à l’indicateur « Taux de respect du SLA des changements ». En comparant la date réelle de résolution à la date cible, les organisations peuvent mesurer l’efficacité de leurs services. Pourquoi est-ce important ? Il s’agit de la principale donnée utilisée pour calculer le respect du SLA et repérer les changements susceptibles de dépasser leur échéance. Où trouver ces données 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. Exemples 2023-11-15T17:00:00Z2023-12-01T23:59:59Z2024-01-10T09:00:00Z
	État du changement ChangeRequestStatus	État actuel ou historique de la demande de changement au moment de l’événement.
Description Cet attribut indique l’état de la demande de changement, par exemple « En attente d’approbation », « En cours » ou « Clôturé ». Dans Jira, le champ de statut est au cœur du moteur de flux de travail, et ses changements déterminent en grande partie le déroulement du processus. L’analyse du statut permet de suivre l’avancement des changements en cours et de comprendre l’issue de ceux qui sont terminés, par exemple « Clôturé : réussi » ou « Clôturé : échec ». Elle est essentielle pour créer des Dashboards de débit et analyser les boucles de reprise, lorsqu’un statut revient à une étape précédente. Pourquoi est-ce important ? Cet attribut donne une vue claire de l’avancement et de l’issue d’une demande de changement, deux éléments importants pour analyser le débit et les reprises. Où trouver ces données 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. Exemples PlanificationEn attente d’approbationMise en œuvreClôturéAnnulé
	Niveau de risque RiskLevel	Le niveau de risque évalué pour le changement, par exemple faible, moyen ou élevé.
Description Dans la plupart des processus de gestion du changement, le niveau de risque fait l’objet d’une évaluation obligatoire. Il indique l’impact négatif potentiel d’un changement. Déterminé lors de l’évaluation des risques, il influe souvent sur le circuit d’approbation requis. En Process Mining, cet attribut est essentiel à l’analyse des risques. Il alimente le Dashboard « Précision et résultats de l’évaluation des risques », qui met en relation le risque initial et l’issue réelle. Il constitue également la principale dimension de l’indicateur « Taux d’échec des changements par niveau de risque », qui permet d’évaluer la gestion des changements à risque élevé. Pourquoi est-ce important ? Il permet de vérifier si les contrôles du processus et les circuits d’approbation sont adaptés aux différents profils de risque, et de mettre en relation le niveau de risque et le taux d’échec des changements. Où trouver ces données Il s’agit généralement d’un champ personnalisé dans Jira Service Management. Les noms courants sont « Niveau de risque » et « Impact ». Exemples FaibleMoyenÉlevéCritique
	Priorité Priority	Le niveau de priorité attribué à la demande de changement, qui indique son importance pour l’entreprise.
Description Le champ de priorité aide les équipes à déterminer dans quel ordre traiter les demandes de changement. Il reflète une combinaison de l’impact et de l’urgence, et guide la planification ainsi que l’affectation des ressources. L’analyse des priorités permet de comparer les performances des changements prioritaires et moins prioritaires. Vous pouvez, par exemple, vérifier si les changements prioritaires ont réellement des temps de cycle plus courts ou s’ils rencontrent les mêmes goulots d’étranglement que les autres. Ces informations aident à mieux répartir les ressources et à répondre aux attentes de l’entreprise. Pourquoi est-ce important ? Il permet d’analyser la performance du processus selon les priorités de l’entreprise et de vérifier que les changements critiques sont traités plus rapidement, comme prévu. Où trouver ces données Il s’agit du champ standard `priority` d’une demande Jira. Exemples La plus élevéeÉlevéMoyenFaible
	Responsable Assignee	L’utilisateur actuellement chargé de traiter la demande de changement.
Description Le responsable est l’utilisateur chargé de l’étape ou de l’activité en cours dans le flux de travail de gestion du changement. Il peut changer plusieurs fois au cours du cycle de vie d’une demande, à mesure que celle-ci passe entre différentes personnes et équipes. Cet attribut sert à analyser la répartition de la charge de travail, à repérer les goulots d’étranglement propres à certains utilisateurs et à comprendre l’affectation des ressources. Le Dashboard « Charge de travail des activités de l’équipe de changement » s’appuie sur ces données pour montrer quelles personnes ou quels groupes traitent le plus d’activités. Pourquoi est-ce important ? Il permet d’analyser la performance des ressources et la répartition de la charge de travail, ainsi que de repérer les goulots d’étranglement au niveau des personnes ou des équipes. Où trouver ces données Il s’agit du champ standard `assignee` d’une demande Jira. Exemples Alice JohnsonBob WilliamsCharlie Brown
	Statut du SLA SLAStatus	Indique si la demande de changement a été terminée avant la date d’achèvement cible.
Description Cet attribut calculé compare la date réelle de résolution d’une demande de changement à sa « Date d’achèvement cible ». Il renvoie un statut simple, par exemple « Respecté » ou « Dépassé ». Il fournit un indicateur clair et immédiat des performances dans le Dashboard « Suivi des performances du SLA des changements ». Il simplifie la création d’indicateurs tels que le « Taux de respect du SLA des changements », car le statut est calculé pour chaque cas. Vous pouvez ensuite filtrer et agréger facilement les résultats pour repérer les types de changement, les équipes ou les services les plus souvent associés aux dépassements de SLA. Pourquoi est-ce important ? Il indique clairement, pour chaque cas, si le SLA a été respecté ou non, ce qui simplifie le suivi et l’analyse de son respect. Où trouver ces données Cet attribut est calculé en comparant l’horodatage de l’activité finale « Changement clôturé » à l’attribut `TargetCompletionDate`. Exemples RespectéDépassé
	Type de changement ChangeRequestType	La catégorie du changement, par exemple standard, normal ou urgent.
Description Le type de changement classe la demande selon sa nature, son urgence et son impact. Les types courants comprennent « Standard » pour les changements préapprouvés à faible risque, « Normal » pour les changements courants nécessitant une approbation complète et « Urgent » pour les changements qui doivent être réalisés rapidement afin de résoudre des incidents. Cet attribut est essentiel à l’analyse des processus, car les différents types de changement suivent souvent des parcours distincts et sont soumis à des SLA différents. Il sert à calculer l’indicateur « Taux de changements urgents » et à filtrer les Dashboards pour comparer les performances et les risques associés à chaque type. Pourquoi est-ce important ? Il permet de segmenter le processus et d’analyser différents flux de travail, par exemple les changements standard et urgents, qui présentent des attentes de performance et des risques distincts. Où trouver ces données Il s’agit généralement d’un champ personnalisé dans les projets Jira Service Management. Son nom peut varier, mais il est souvent intitulé « Type de changement ». Exemples StandardNormalUrgent
	Déclarant Reporter	L’utilisateur qui a créé ou soumis la demande de changement.
Description 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 lance le changement pour le compte d’une équipe. L’analyse des déclarants peut aider à déterminer quels services, équipes ou utilisateurs lancent le plus de changements. Elle permet de repérer les tendances parmi les sources de demandes et de proposer des retours ou des formations aux groupes qui soumettent souvent des demandes incomplètes ou de qualité insuffisante. Pourquoi est-ce important ? Il aide à identifier l’origine des demandes de changement et à améliorer la qualité des informations fournies lors de leur soumission. Où trouver ces données Il s’agit du champ standard `reporter` d’une demande Jira. Exemples David MillerEva GreenFrank Wright
	Équipe Team	L’équipe ou le groupe chargé de la demande de changement ou d’une activité précise.
Description Cet attribut identifie l’équipe chargée du changement. Jira dispose d’un champ « Responsable » pour les personnes, mais un champ « Équipe » sert souvent à affecter le travail à un groupe fonctionnel, comme « Exploitation réseau » ou « Administration des bases de données ». Cet attribut est essentiel au Dashboard « Charge de travail des activités de l’équipe de changement ». Il permet d’analyser les performances et les goulots d’étranglement à l’échelle d’une équipe, plutôt qu’au niveau individuel, ce qui est souvent plus utile pour planifier et gérer les ressources. Pourquoi est-ce important ? Il facilite l’analyse de la charge de travail et des performances à l’échelle d’une équipe ou d’un service, et met en évidence les goulots d’étranglement systémiques. Où trouver ces données Il s’agit généralement d’un champ personnalisé dans Jira, car aucun champ « Équipe » n’est fourni par défaut. Il peut être de type « Sélecteur de groupe » ou prendre la forme d’une simple liste de sélection. Exemples Équipe infrastructureServices centrauxAssistance applicative
	Incident après mise en œuvre PostImplementationIssue	Indique si un incident ou un problème a été associé à ce changement après sa mise en œuvre.
Description Cet attribut indique si le changement a entraîné une conséquence négative, comme un incident en production. Pour cela, la demande de changement est souvent associée à une ou plusieurs demandes d’incident dans Jira. Ces données sont essentielles au calcul des indicateurs « Taux d’incidents après mise en œuvre » et « Taux d’échec des changements ». Elles mesurent directement la qualité des changements et l’efficacité de la planification, des tests et de l’évaluation des risques. L’analyse des changements à l’origine d’incidents aide à améliorer les contrôles et à prévenir de futurs échecs. Pourquoi est-ce important ? Il mesure directement la qualité et la réussite d’un changement en indiquant s’il a entraîné des problèmes opérationnels par la suite. Où trouver ces données Cet attribut est généralement calculé en recherchant les demandes associées dans Jira, notamment les liens « est causé par » entre une demande de changement et des demandes d’incident. Exemples truefalse
	Motif du changement ChangeReason	La justification ou la raison métier à l’origine du changement proposé.
Description Cet attribut indique la raison du changement, par exemple « Mise en œuvre d’une nouvelle fonctionnalité », « Correction d’un bogue » ou « Mise à niveau de l’infrastructure ». Il apporte des précisions qui ne figurent pas nécessairement dans le résumé ou la description. L’analyse permet de mettre le motif du changement en relation avec d’autres indicateurs, comme le temps de cycle, le taux d’échec et le niveau de risque. Vous pouvez ainsi répondre à des questions telles que : « Les corrections de bogues sont-elles approuvées plus rapidement que les nouvelles fonctionnalités ? » ou « Les mises à niveau de l’infrastructure présentent-elles un taux d’échec plus élevé ? » Pourquoi est-ce important ? Il apporte le contexte métier nécessaire pour approfondir l’analyse en mettant en relation l’objectif d’un changement avec ses performances et son issue. Où trouver ces données Il s’agit généralement d’un champ personnalisé dans Jira Service Management, souvent une liste de sélection ou un champ de texte. Exemples Correctif de sécuritéMise à niveau logicielleInstallation de nouveau matériel
	Reprise IsRework	Indicateur booléen qui passe à vrai si la demande de changement a fait l’objet d’une boucle de reprise.
Description Cet attribut calculé repère 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 signale que la demande initiale était incomplète, incorrecte ou ne répondait pas aux critères requis. Cet indicateur sert de base à l’indicateur « Taux de reprise des changements » et au Dashboard « Analyse des reprises et des rejets de changements ». En repérant les cas concernés, les analystes peuvent les filtrer facilement et en rechercher les causes, comme une planification initiale insuffisante, des exigences imprécises ou une évaluation des risques incomplète. Pourquoi est-ce important ? Il met en évidence les inefficacités du processus en signalant les cas qui ont nécessité un travail supplémentaire imprévu, ce qui permet d’en rechercher les causes. Où trouver ces données Cet attribut est calculé à partir de la séquence des activités dans le journal d’événements. Une reprise est détectée lorsqu’une activité d’une étape antérieure suit une activité d’une étape ultérieure. Exemples truefalse
	Résolution Resolution	L’issue finale d’une demande de changement clôturée, qui indique comment elle a été résolue.
Description À la clôture d’une demande de changement, le champ de résolution précise son issue. Par exemple, « Terminé » indique une réussite, tandis que « Ne sera pas réalisé » ou « Doublon » correspondent à d’autres motifs de clôture. Il apporte ainsi des précisions que le seul statut « Clôturé » ne fournit pas. Cet attribut est essentiel pour analyser les taux de réussite et d’échec des changements. Par exemple, l’indicateur « Taux d’incidents après mise en œuvre » s’interprète plus facilement en filtrant les changements dont la résolution est « Échec » ou « Annulé ». Il permet de distinguer les changements mis en œuvre avec succès de ceux qui ont été annulés ou rejetés après approbation. Pourquoi est-ce important ? Il précise l’issue finale d’un changement et permet ainsi de calculer avec exactitude les taux de réussite et d’échec. Où trouver ces données Il s’agit du champ standard `resolution` dans Jira, généralement renseigné lorsqu’une demande passe dans la catégorie de statut « Terminé ». Exemples TerminéNe sera pas réaliséDoublonAnnuléAnnulé
	Service métier BusinessService	Le service métier ou l’application concerné par le changement.
Description Cet attribut associe la demande de changement à un service métier précis défini dans la base de données de gestion des configurations (CMDB), par exemple « Service de messagerie » ou « CRM client ». Il est 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 leur impact aux parties prenantes. Elle permet de voir quels services font l’objet du plus grand nombre de changements, lesquels sont les plus exposés aux risques et où se concentrent les incidents liés aux changements. Cette approche est essentielle pour gérer les changements techniques en tenant compte des enjeux métier. Pourquoi est-ce important ? Il relie les changements techniques à leurs conséquences métier et permet de hiérarchiser les priorités et d’analyser les risques selon la criticité du service concerné. Où trouver ces données Il s’agit souvent d’un champ personnalisé dans JSM, fréquemment associé à Jira Assets (anciennement Insight) ou à une autre CMDB. Exemples Site web de l’entrepriseSAP ERPWiki interne

Obligatoire Recommandé Facultatif

Activités de gestion du changement

Voici les principales étapes et les jalons à consigner dans votre journal d’événements pour découvrir avec précision votre processus de gestion du changement.

5 Recommandé 8 Facultatif

	Activité	Description
	Changement clôturé	Correspond à la clôture définitive de la demande de changement, une fois toutes les activités associées terminées. Cet événement est enregistré lorsque l’état de la demande Jira passe à un état final de résolution, comme « Clôturé » ou « Terminé ».
Pourquoi est-ce important ? C’est le principal point de fin du processus. Il sert à calculer le temps de cycle global et à mesurer le respect des SLA. Où trouver ces données L’événement est déduit de l’historique de la demande Jira en repérant l’horodatage auquel le champ « status » passe à un état final de clôture. Le champ de résolution est généralement renseigné à ce moment-là. Données à recueillir Suivez l’horodatage du passage à l’état « Clôturé » ou « Terminé ». Type d’événement inferred
	Changement en attente d’approbation	Indique que la demande de changement a passé l’examen initial et attend maintenant une décision officielle du comité consultatif des changements (CAB) ou des personnes chargées de l’approuver. Cet événement est extrait d’un changement d’état dans le flux de travail, par exemple le passage à « En attente d’approbation » ou « En attente du CAB ».
Pourquoi est-ce important ? Cette activité est essentielle pour mesurer les délais d’attente avant approbation et repérer les goulots d’étranglement au stade de la prise de décision, qui ont une incidence directe sur le KPI de temps de cycle d’approbation des changements. Où trouver ces données L’événement est déduit de l’historique de la demande Jira en repérant l’horodatage auquel le champ « status » passe à un état d’approbation, comme « En attente de l’approbation du CAB » ou « En attente d’approbation ». Données à recueillir Suivez l’horodatage du passage à l’état désigné « En attente d’approbation ». Type d’événement inferred
	Changement mis en œuvre	Cette étape importante indique que les travaux liés au changement sont terminés. Elle est enregistrée lors du passage à un état comme « Mis en œuvre » ou « En attente de vérification » dans le flux de travail Jira.
Pourquoi est-ce important ? Cette étape marque la fin de la phase de mise en œuvre et permet de calculer le délai de mise en œuvre. Elle déclenche également les activités de vérification et de revue après mise en œuvre. Où trouver ces données L’événement est déduit de l’historique de la demande Jira en repérant l’horodatage auquel le champ « status » passe à l’état « Mis en œuvre » ou « En attente de revue après mise en œuvre ». Données à recueillir Suivez l’horodatage du passage à l’état « Mis en œuvre » ou à un état équivalent. Type d’événement inferred
	Demande de changement approuvée	Cette étape importante indique que le changement a été officiellement approuvé pour mise en œuvre. Elle est presque toujours déduite du passage à un état comme « Approuvé » ou « Prêt pour mise en œuvre » dans le flux de travail Jira.
Pourquoi est-ce important ? Cet événement marque la fin du cycle d’approbation et le début de la phase de mise en œuvre. Il est indispensable pour mesurer les temps de cycle d’approbation et suivre les changements non autorisés. Où trouver ces données L’événement est déduit de l’historique de la demande Jira en repérant l’horodatage auquel le champ « status » passe à l’état « Approuvé ». Données à recueillir Suivez l’horodatage du passage à l’état « Approuvé » ou « Prêt à mettre en œuvre ». Type d’événement inferred
	Demande de changement créée	Correspond à la création initiale d’un ticket de demande de changement dans Jira Service Management. Cet événement est enregistré avec un horodatage de création lorsque la première version d’une nouvelle demande de type « Change » est enregistrée.
Pourquoi est-ce important ? C’est le point de départ de toutes les demandes de changement. Il est essentiel pour mesurer le délai global et analyser l’évolution du volume de changements entrants. Où trouver ces données L’événement est extrait de l’horodatage « created » de l’objet Jira. Ce champ système standard est disponible pour chaque demande et peut être récupéré dans l’historique de la demande ou via l’API. Données à recueillir Utilisez l’horodatage du champ « created » de la demande Jira. Type d’événement explicit
	Changement annulé	Correspond à l’arrêt d’une demande de changement avant sa mise en œuvre ou son achèvement. Cet événement est enregistré lorsque l’état de la demande Jira passe à un état final comme « Annulé » ou « Retiré ».
Pourquoi est-ce important ? Ce point de fin alternatif permet d’analyser les raisons de l’abandon des changements. Un taux d’annulation élevé peut révéler une planification initiale insuffisante ou une évolution des priorités métier. Où trouver ces données L’événement est déduit de l’historique de la demande Jira en repérant l’horodatage auquel le champ « status » passe à l’état « Annulé » et qu’une résolution correspondante est définie. Données à recueillir Suivez l’horodatage du passage à l’état « Annulé » ou « Retiré ». Type d’événement inferred
	Changement planifié	Indique qu’une plage précise a été attribuée à la mise en œuvre du changement approuvé. Cet événement est déduit du renseignement ou de la mise à jour des champs « Date de début prévue » et « Date de fin prévue » dans la demande Jira.
Pourquoi est-ce important ? Cette activité donne de la visibilité sur la planification des changements. Elle facilite la gestion des ressources et l’évaluation du délai entre l’approbation et la mise en œuvre prévue. Où trouver ces données L’événement est déduit de l’historique de la demande Jira en relevant l’horodatage auquel des champs de date comme « Date de début prévue » ou « Fenêtre de changement » sont renseignés. Données à recueillir Suivez l’horodatage auquel le champ « Date de début prévue » est renseigné. Type d’événement inferred
	Demande de changement refusée	Correspond au refus officiel d’une demande de changement, qui est généralement renvoyée à la personne à l’origine de la demande pour obtenir des informations complémentaires, ou annulée. Cet événement est enregistré lors du passage à l’état « Refusé » ou « Informations complémentaires requises » dans le flux de travail Jira.
Pourquoi est-ce important ? Le suivi des refus est essentiel pour analyser le taux de reprises des changements. Si cette activité est fréquente, cela peut indiquer que les demandes initiales ne sont pas suffisamment complètes ou précises. Où trouver ces données L’événement est déduit de l’historique de la demande Jira en repérant l’horodatage auquel le champ « status » passe à l’état « Refusé » ou à un état final équivalent. Données à recueillir Suivez l’horodatage du passage à l’état « Refusé » ou « Rejeté ». Type d’événement inferred
	Demande de changement soumise pour examen	Indique que les informations initiales de la demande de changement sont complètes et que celle-ci a été officiellement soumise pour évaluation. Cet événement est généralement déduit d’un changement d’état dans le flux de travail Jira, par exemple de « Brouillon » à « En attente d’examen ».
Pourquoi est-ce important ? Cette activité marque le début du cycle d’approbation. Mesurer le délai entre cette étape et l’approbation est essentiel pour calculer les KPI de temps de cycle d’approbation et repérer les goulots d’étranglement en début de processus. Où trouver ces données L’événement est déduit de l’historique de la demande Jira en repérant l’horodatage auquel le champ « status » passe à un état d’examen, comme « En attente d’examen » ou « En attente d’évaluation ». Données à recueillir Suivez l’horodatage du passage à l’état « En attente d’examen », « Soumis » ou à un état équivalent. Type d’événement inferred
	Évaluation des risques effectuée	Correspond à la fin de l’analyse des risques et des impacts du changement proposé. Cet événement est souvent déduit de l’historique de la demande lorsque des champs personnalisés liés aux risques, comme « Niveau de risque » ou « Impact », sont renseignés ou mis à jour.
Pourquoi est-ce important ? L’analyse de cette activité permet d’évaluer la précision des évaluations des risques et de vérifier le respect des règles de gestion du changement. Elle est indispensable au calcul des KPI fondés sur les risques, comme le taux d’échec des changements par niveau de risque. Où trouver ces données L’événement est déduit de l’historique de la demande Jira en relevant l’horodatage auquel des champs comme « Niveau de risque », « Impact » ou « Urgence » sont renseignés ou modifiés pour la première fois. Données à recueillir Suivez l’horodatage du premier renseignement de champs comme « Niveau de risque » ou « Impact ». Type d’événement inferred
	Mise en œuvre commencée	Marque le début de la mise en œuvre technique du changement approuvé. Cet événement est généralement enregistré lors du passage de l’état « Approuvé » ou « Planifié » à « En cours » ou « Mise en œuvre » dans Jira.
Pourquoi est-ce important ? Cette activité marque le début du calcul du délai moyen de mise en œuvre et aide à repérer les goulots d’étranglement pendant la phase d’exécution. Où trouver ces données L’événement est déduit de l’historique de la demande Jira en repérant l’horodatage auquel le champ « status » passe à un état de mise en œuvre active, comme « En cours ». Données à recueillir Suivez l’horodatage du passage à l’état « En cours » ou « Mise en œuvre ». Type d’événement inferred
	Revue après mise en œuvre terminée	Indique que la revue officielle visant à évaluer la réussite du changement et à en tirer des enseignements est terminée. Cet événement est généralement enregistré lors d’un changement d’état dans le flux de travail, par exemple du passage de « Revue après mise en œuvre » à « Vérifié ».
Pourquoi est-ce important ? Cette activité est essentielle à l’amélioration du processus. Mesurer le temps de cycle de la revue permet de s’assurer que les enseignements sont recueillis rapidement. Où trouver ces données L’événement est déduit de l’historique de la demande Jira en repérant l’horodatage auquel le champ « status » quitte l’état « Revue après mise en œuvre ». Données à recueillir Suivez l’horodatage du passage de l’état « PIR » à l’état suivant. Type d’événement inferred
	Tests effectués	Correspond à la fin des tests réalisés après la mise en œuvre pour valider le changement. Cet événement peut être associé à un état distinct, comme « En cours de test », ou déduit des commentaires ou des mises à jour de l’équipe d’assurance qualité après l’événement « Changement mis en œuvre ».
Pourquoi est-ce important ? L’analyse de la durée et des résultats des tests permet d’évaluer la qualité des mises en œuvre et l’efficacité du processus de test. Ces informations contribuent au calcul du taux de problèmes après mise en œuvre. Où trouver ces données Cet événement peut être déduit du passage à l’état « Tests en cours » ou « En cours de test », ou de l’analyse des commentaires et des changements de personne responsable dans l’historique de la demande après la mise en œuvre. Données à recueillir Suivez l’horodatage du passage à l’état « En cours de test » ou utilisez les commentaires. Type d’événement inferred

Recommandé Facultatif

Guides d’extraction

Comment extraire vos données de Jira Service Management

Étapes

Ouvrez le navigateur de demandes Jira : Connectez-vous à votre instance Jira Service Management. Dans la barre de navigation principale, sélectionnez « Issues », puis « Search for issues » pour ouvrir le navigateur de demandes.
Passez à la recherche JQL : Si vous utilisez le mode de recherche « Basic », passez en mode avancé en cliquant sur « JQL » (ou « Advanced » dans certaines versions). Vous pourrez alors saisir une requête personnalisée en Jira Query Language (JQL).
Filtrez les demandes de changement : Saisissez dans la barre de recherche la requête JQL indiquée dans la section « query » de ce document. Remplacez les valeurs fictives par la clé de votre projet, le nom du type de demande correspondant aux changements et la période souhaitée.
Lancez la recherche et exportez les données : Exécutez la recherche. Lorsque la liste des demandes de changement s’affiche, repérez le bouton « Export », généralement situé en haut à droite. Sélectionnez « Export Excel CSV (all fields) ». Ce format est indispensable, car il inclut l’historique détaillé des demandes nécessaire pour reconstituer le déroulement du processus.
Chargez le fichier CSV pour le transformer : Ouvrez le fichier CSV téléchargé avec un outil de préparation des données, comme Power Query, un script Python utilisant la bibliothèque pandas ou un autre outil ETL. L’export brut contient une ligne par demande, mais aussi des colonnes avec des données historiques.
Structurez les données de base : Pour chaque ligne du fichier source, créez l’événement initial « Change Request Created ». Utilisez « Issue key » comme ChangeRequestId, définissez ActivityName sur « Change Request Created » et renseignez EventTime à partir de la colonne « Created ».
Décomposez l’historique des statuts : Repérez les colonnes qui contiennent l’historique des transitions de statut. Chaque changement de statut correspond à un événement. Pour chaque demande de changement, créez une ligne pour chaque transition pertinente, par exemple de « Draft » à « Pending Review » ou de « Pending Approval » à « Approved ». Associez ces transitions à la valeur correspondante de ActivityName, par exemple « Change Submitted For Review », « Change Awaiting Approval » ou « Change Request Approved ». L’horodatage de la transition devient la valeur de EventTime.
Décomposez l’historique des mises à jour de champs : Certaines activités sont déduites des mises à jour de champs plutôt que des changements de statut. Traitez l’historique de champs tels que « Risk Level », « Planned start date » et « Planned end date ». Créez des lignes pour les événements « Risk Assessment Performed » et « Change Scheduled », en utilisant l’horodatage de la première saisie ou mise à jour de ces champs.
Associez et complétez les attributs : Pour chaque ligne d’événement créée, associez les champs Jira correspondants aux attributs requis, tels que ChangeRequestStatus, ChangeRequestType, Assignee et Priority. Utilisez la valeur qui était en vigueur au moment de l’événement.
Ajoutez les colonnes de métadonnées : Ajoutez une colonne nommée SourceSystem et attribuez-lui la valeur fixe « Jira Service Management ». Ajoutez une colonne LastDataUpdate et renseignez-la avec l’horodatage de l’extraction.
Calculez les métriques dérivées : Une fois le journal d’événements complet créé, calculez les attributs qui nécessitent plusieurs points de données, comme ApprovalCycleTime. Pour cela, calculez, pour chaque ChangeRequestId, le temps écoulé entre les événements « Change Submitted For Review » et « Change Request Approved ».
Finalisez les données et exportez-les : Vérifiez que le tableau final contient les colonnes requises : ChangeRequestId, ActivityName et EventTime. Supprimez les colonnes intermédiaires ou sources. Enregistrez les données transformées dans un fichier CSV encodé en UTF-8, puis importez-le dans l’outil de Process Mining.

Configuration

Filtre JQL : La requête JQL est le principal moyen de sélectionner le jeu de données approprié. Les filtres essentiels comprennent project, issuetype et une période définie à partir du champ created.
Période : Il est recommandé de commencer par une période de 3 à 6 mois afin d’obtenir un jeu de données représentatif sans nuire aux performances. Exemple : created >= "-180d".
Type de demande : Vous devez indiquer le nom exact du type de demande utilisé pour la gestion du changement dans votre instance Jira, par exemple issuetype = "Change" ou issuetype = "Change Request".
Format d’exportation : Utilisez toujours « Export Excel CSV (all fields) ». Cette option inclut tous les champs personnalisés et, surtout, l’historique complet des changements de statut et de champs. Un export limité à certains champs ne contiendra pas les données nécessaires à la création du journal d’événements.
Autorisations Jira : La personne qui effectue l’exportation doit disposer de l’autorisation « Browse Projects » pour le projet concerné, ainsi que des autorisations nécessaires pour consulter tous les champs pertinents des demandes.
Identification des champs personnalisés : Avant la transformation, repérez les noms exacts des champs personnalisés de votre instance Jira correspondant aux attributs du processus, comme « Risk Level », « Planned start date » et « Change Type ».

Exemple de requête config

project = "[Your_Project_Key]" AND issuetype = "Change" AND created >= "[Start_Date_YYYY-MM-DD]" AND created <= "[End_Date_YYYY-MM-DD]" ORDER BY created ASC

Étapes

Établissez la connexion à la base de données : Obtenez des identifiants en lecture seule pour la base de données sous-jacente de Jira Server ou Data Center, qui peut être PostgreSQL, MySQL, SQL Server ou Oracle. Connectez-vous à la base avec un client SQL standard, comme DBeaver, SQL Developer ou pgAdmin.
Repérez la configuration Jira : Avant d’exécuter la requête, identifiez les noms utilisés dans la configuration de votre Jira Service Management. Connectez-vous à Jira et ouvrez votre projet de gestion du changement. Notez les éléments suivants :
- Clé du projet : l’identifiant court de votre projet, par exemple « CSM ».
- Nom du type de demande : le nom exact des demandes de changement, généralement « Change ».
- Statuts du flux de travail : les noms de chaque statut de votre flux de travail de gestion du changement, comme « Pending Review », « Pending Approval », « In Progress » ou « Closed ».
- Noms des champs personnalisés : les noms des champs personnalisés utilisés pour « Change Type », « Risk Level », « Planned start date » et « Planned end date ».
Personnalisez la requête SQL : Ouvrez la requête SQL fournie dans votre client SQL. Remplacez les valeurs fictives par les informations recueillies à l’étape précédente. Les principales valeurs à modifier sont [Your_JSM_Project_Key], [Your Change Type Field Name], [Your Risk Level Field Name], [Your Planned Start Date Field Name], [Your Planned End Date Field Name], ainsi que tous les noms de statut dans les clauses WHERE.
Définissez la période : Repérez la ligne AND i.created >= '[YYYY-MM-DD]' dans l’expression de table commune (CTE) initiale. Modifiez la date pour définir le début de la période d’extraction. Cette étape limite le volume de données et améliore les performances de la requête.
Exécutez la requête : Lancez la requête SQL modifiée sur la base de données Jira. Selon la taille de votre instance Jira et la période sélectionnée, l’opération peut prendre plusieurs minutes.
Vérifiez les résultats : Une fois la requête terminée, examinez brièvement les résultats dans votre client SQL. Vérifiez que des lignes sont renvoyées et que les colonnes telles que ChangeRequestId, ActivityName et EventTime sont renseignées comme prévu.
Exportez les données au format CSV : Exportez l’ensemble des résultats depuis votre client SQL dans un fichier CSV. Dans les paramètres d’exportation, incluez les en-têtes de colonnes, utilisez la virgule comme séparateur et sélectionnez l’encodage UTF-8.
Préparez l’importation : Donnez au fichier un nom explicite, par exemple jira_change_management_log.csv. Il est maintenant prêt à être importé dans un outil de Process Mining pour analyse.

Configuration

Accès à la base de données : Un compte utilisateur en lecture seule pour la base de données de production Jira est nécessaire. L’accès direct à la base de données est possible uniquement avec Jira Server et Jira Data Center, et non avec Jira Cloud.
Clé du projet Jira : La requête doit être configurée avec la clé précise de votre projet Jira Service Management. Indiquez-la dans la clause p.pkey IN ('[Your_JSM_Project_Key]').
Type de demande pour les changements : La requête suppose que le type de demande de changement s’appelle « Change ». Si votre configuration utilise un autre nom, modifiez le filtre issuetype.pname = 'Change'.
Association des statuts du flux de travail : La précision du journal d’événements dépend entièrement de l’association correcte des noms de statut dans les clauses WHERE avec les statuts réellement utilisés dans le flux de travail de votre projet. Vérifiez soigneusement chaque chaîne 'Status Name' et mettez-la à jour.
Association des champs personnalisés : La requête s’appuie sur les noms des champs personnalisés pour suivre certaines activités (« Risk Assessment Performed », « Change Scheduled ») et certains attributs. Vérifiez les noms, comme '[Your Risk Level Field Name]', et adaptez-les à votre configuration Jira.
Période : Il est vivement recommandé de commencer par une période limitée, par exemple de 3 à 6 mois (i.created >= '[YYYY-MM-DD]'), afin de maîtriser le volume de données et de préserver les performances de la requête. L’extraction de plusieurs années de données peut être très lente.
Performances : Sur les instances Jira qui comptent des millions de demandes, l’exécution de cette requête peut affecter les performances de la base de données. Il est préférable de la lancer en dehors des heures de pointe. Appliquez le filtre de période pour limiter le périmètre de l’extraction.

Exemple de requête sql

WITH ChangeRequestAttributes AS (
    SELECT
        i.id AS issueid,
        i.pkey AS ChangeRequestId,
        i.created,
        i.duedate AS TargetCompletionDate,
        istat.pname AS ChangeRequestStatus,
        u.display_name AS Assignee,
        prio.pname AS Priority,
        ct.customvalue AS ChangeRequestType,
        rl.customvalue AS RiskLevel
    FROM
        jiraissue i
    JOIN
        project p ON i.project = p.id
    LEFT JOIN
        issuestatus istat ON i.issuestatus = istat.id
    LEFT JOIN
        priority prio ON i.priority = prio.id
    LEFT JOIN
        app_user au ON i.assignee = au.user_key
    LEFT JOIN
        cwd_user u ON au.lower_user_name = u.lower_user_name
    LEFT JOIN (
        SELECT cfv.issue, cfo.customvalue
        FROM customfieldvalue cfv
        JOIN customfield cf ON cfv.customfield = cf.id
        JOIN customfieldoption cfo ON cfv.stringvalue = cfo.id
        WHERE cf.cfname = '[Your Change Type Field Name]'
    ) ct ON i.id = ct.issue
    LEFT JOIN (
        SELECT cfv.issue, cfo.customvalue
        FROM customfieldvalue cfv
        JOIN customfield cf ON cfv.customfield = cf.id
        JOIN customfieldoption cfo ON cfv.stringvalue = cfo.id
        WHERE cf.cfname = '[Your Risk Level Field Name]'
    ) rl ON i.id = rl.issue
    WHERE
        p.pkey IN ('[Your_JSM_Project_Key]')
        AND i.issuetype = (SELECT id FROM issuetype WHERE pname = 'Change')
        AND i.created >= '[YYYY-MM-DD]'
)
-- 1. Change Request Created
SELECT
    cra.ChangeRequestId,
    'Change Request Created' AS ActivityName,
    cra.created AS EventTime,
    'Jira Service Management DB' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    cra.ChangeRequestStatus,
    cra.ChangeRequestType,
    cra.Assignee,
    cra.RiskLevel,
    cra.Priority,
    cra.TargetCompletionDate,
    NULL AS ApprovalCycleTime,
    NULL AS SLAStatus
FROM
    ChangeRequestAttributes cra

UNION ALL

-- All subsequent events from issue history
SELECT
    cra.ChangeRequestId,
    CASE 
        WHEN ci.field = 'status' AND ci.newstring = 'Pending Review' THEN 'Change Submitted For Review'
        WHEN ci.field = 'status' AND ci.newstring = 'Pending Approval' THEN 'Change Awaiting Approval'
        WHEN ci.field = 'status' AND ci.newstring = 'Approved' THEN 'Change Request Approved'
        WHEN ci.field = 'status' AND ci.newstring = 'Rejected' THEN 'Change Request Rejected'
        WHEN ci.field = 'status' AND ci.newstring = 'In Progress' THEN 'Implementation Started'
        WHEN ci.field = 'status' AND ci.newstring = 'Implemented' THEN 'Change Implemented'
        WHEN ci.field = 'status' AND ci.newstring = 'In Testing' THEN 'Testing Performed'
        WHEN ci.field = 'status' AND ci.newstring = 'Verified' AND ci.oldstring = 'Post-Implementation Review' THEN 'Post-Implementation Review Done'
        WHEN ci.field = 'status' AND ci.newstring = 'Closed' THEN 'Change Closed'
        WHEN ci.field = 'status' AND ci.newstring = 'Canceled' THEN 'Change Canceled'
        WHEN ci.field = (SELECT id FROM customfield WHERE cfname = '[Your Risk Level Field Name]') AND ci.oldvalue IS NULL THEN 'Risk Assessment Performed'
        WHEN ci.field = (SELECT id FROM customfield WHERE cfname = '[Your Planned Start Date Field Name]') AND ci.oldvalue IS NULL THEN 'Change Scheduled'
    END AS ActivityName,
    cg.created AS EventTime,
    'Jira Service Management DB' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    cra.ChangeRequestStatus,
    cra.ChangeRequestType,
    cra.Assignee,
    cra.RiskLevel,
    cra.Priority,
    cra.TargetCompletionDate,
    NULL AS ApprovalCycleTime,
    NULL AS SLAStatus
FROM
    changegroup cg
JOIN
    changeitem ci ON cg.id = ci.groupid
JOIN
    ChangeRequestAttributes cra ON cg.issueid = cra.issueid
WHERE
    (
        ci.fieldtype = 'jira' AND ci.field = 'status' AND ci.newstring IN (
            'Pending Review', 'Pending Approval', 'Approved', 'Rejected', 
            'In Progress', 'Implemented', 'In Testing', 'Verified', 'Closed', 'Canceled'
        )
    )
    OR
    (
        ci.fieldtype = 'custom' AND ci.fieldid IN (
            (SELECT id FROM customfield WHERE cfname = '[Your Risk Level Field Name]'),
            (SELECT id FROM customfield WHERE cfname = '[Your Planned Start Date Field Name]')
        ) AND ci.oldvalue IS NULL
    )
ORDER BY
    ChangeRequestId, EventTime;

Étapes

Préparez l’environnement Python : Vérifiez que Python 3.6 ou une version ultérieure est installé. Installez les bibliothèques nécessaires, requests pour les appels API et pandas pour la manipulation des données, en exécutant la commande pip install requests pandas.
Générez un jeton API Jira : Connectez-vous à votre compte Jira. Ouvrez les paramètres de votre profil, sélectionnez « Account settings », puis l’onglet « Security » et cliquez sur « Create and manage API tokens ». Créez un jeton et copiez-le en lieu sûr. Ce jeton servira de mot de passe pour l’authentification à l’API.
Configurez le script Python : Ouvrez le script Python fourni dans un éditeur. Remplacez les valeurs fictives de JIRA_URL, JIRA_EMAIL et JIRA_API_TOKEN par l’URL de votre instance Jira, votre adresse e-mail et le jeton API que vous avez généré.
Personnalisez la requête JQL : Modifiez la variable JQL_QUERY dans le script pour cibler le bon projet Jira Service Management et le bon type de demande. Par exemple, remplacez project = "CSM" par la clé de votre projet. Ajustez la période de la requête pour limiter l’extraction et améliorer les performances.
Associez les champs personnalisés et les statuts : Vérifiez les dictionnaires STATUS_TO_ACTIVITY_MAPPING et FIELD_TO_ACTIVITY_MAPPING dans le script. Mettez à jour les noms de statut Jira (par exemple, « Pending Approval ») et les noms des champs personnalisés (par exemple, « Risk Level ») pour qu’ils correspondent exactement à ceux de votre flux de travail Jira. Consultez la page d’administration des champs personnalisés Jira pour trouver les identifiants corrects des champs, comme customfield_10050.
Exécutez le script : Lancez le script depuis votre terminal avec la commande python your_script_name.py. Il se connectera à l’API Jira, récupérera les demandes de changement et traitera leur historique.
Suivez l’exécution du script : Des messages de progression s’afficheront dans la console et indiqueront le nombre de demandes récupérées et traitées. Le traitement de grands jeux de données peut prendre beaucoup de temps.
Vérifiez le résultat : Une fois le script terminé, il crée un fichier CSV nommé jira_change_management_event_log.csv dans le même répertoire. Ce fichier contient le journal d’événements extrait.
Préparez l’importation : Ouvrez le fichier CSV dans un tableur pour vérifier que les données sont correctement structurées et que les colonnes telles que ChangeRequestId, ActivityName et EventTime sont présentes. Le fichier est alors prêt à être importé dans un outil de Process Mining.

Configuration

Requête JQL : La variable JQL_QUERY est le principal filtre d’extraction. Elle doit au minimum préciser project, issuetype = 'Change' et une période pour le champ created (par exemple, created >= -180d pour les 180 derniers jours). Il est essentiel de limiter la période pour maîtriser le volume de données.
Association des statuts et des champs : La précision du script dépend entièrement des dictionnaires STATUS_TO_ACTIVITY_MAPPING et FIELD_TO_ACTIVITY_MAPPING. Configurez-les pour qu’ils correspondent exactement aux statuts du flux de travail Jira de votre organisation et aux noms de ses champs personnalisés, afin de générer les bonnes activités.
Identifiants API : Le script nécessite des valeurs valides pour JIRA_URL, JIRA_EMAIL et JIRA_API_TOKEN. Le compte associé au jeton doit disposer d’autorisations de lecture sur le projet indiqué et tous les champs pertinents.
Pagination des données : Le script utilise le paramètre maxResults (défini sur 100) pour récupérer les demandes par lots, ou pages, depuis l’API. Cette méthode permet d’extraire de grands volumes de demandes sans dépasser le délai d’attente.
Développement de l’historique des changements : Le paramètre expand=changelog de la requête API est essentiel. Il demande à Jira d’inclure l’historique complet des changements de champs pour chaque demande, qui constitue la source de la plupart des activités.

Exemple de requête python

import requests
import json
import pandas as pd
from datetime import datetime

class=class="hl-string">"hl-comment"># --- Configuration Settings --- #
class=class="hl-string">"hl-comment"># Replace with your Jira instance details
JIRA_URL = class="hl-string">"https://[your-domain].atlassian.net"
JIRA_EMAIL = class="hl-string">"[your-email@example.com]"
JIRA_API_TOKEN = class="hl-string">"[your_jira_api_token]"

class=class="hl-string">"hl-comment"># JQL to select Change Management issues. Itclass="hl-string">'s recommended to add a date filter, e.g., 'AND created >= -180d'
JQL_QUERY = class="hl-string">'project = "CSM" AND issuetype = "Change" ORDER BY created DESC'

class=class="hl-string">"hl-comment"># --- Mappings - CRITICAL: Customize these to match your Jira workflow --- #
class=class="hl-string">"hl-comment"># Map Jira status names to standardized Activity Names
STATUS_TO_ACTIVITY_MAPPING = {
    class="hl-string">'Pending Review': class="hl-string">'Change Submitted For Review',
    class="hl-string">'Pending Approval': class="hl-string">'Change Awaiting Approval',
    class="hl-string">'Approved': class="hl-string">'Change Request Approved',
    class="hl-string">'Rejected': class="hl-string">'Change Request Rejected',
    class="hl-string">'In Progress': class="hl-string">'Implementation Started',
    class="hl-string">'Implemented': class="hl-string">'Change Implemented',
    class="hl-string">'Post-Implementation Review': class="hl-string">'Post-Implementation Review Done',
    class="hl-string">'Closed': class="hl-string">'Change Closed',
    class="hl-string">'Canceled': class="hl-string">'Change Canceled',
    class=class="hl-string">"hl-comment"># Add other custom statuses from your workflow
}

class=class="hl-string">"hl-comment"># Map Jira field updates to standardized Activity Names
class=class="hl-string">"hl-comment"># Use field names as they appear in the API changelog. Custom fields might have different names.
FIELD_TO_ACTIVITY_MAPPING = {
    class="hl-string">'Risk Level': class="hl-string">'Risk Assessment Performed',
    class="hl-string">'Planned start date': class="hl-string">'Change Scheduled',
    class="hl-string">'Testing Status': class="hl-string">'Testing Performed', class=class="hl-string">"hl-comment"># Example for a custom class="hl-string">'Testing Status' field
}
class=class="hl-string">"hl-comment"># --- End of Configuration --- #

def get_issues(auth):
    class="hl-string">"""Paginates through JQL results to fetch all issues."""
    all_issues = []
    start_at = 0
    max_results = 100

    while True:
        api_endpoint = fclass="hl-string">"{JIRA_URL}/rest/api/3/search"
        params = {
            class="hl-string">'jql': JQL_QUERY,
            class="hl-string">'startAt': start_at,
            class="hl-string">'maxResults': max_results,
            class="hl-string">'fields': class="hl-string">'*all',
            class="hl-string">'expand': class="hl-string">'changelog'
        }
        try:
            response = requests.get(api_endpoint, auth=auth, params=params, headers={class="hl-string">'Accept': class="hl-string">'application/json'})
            response.raise_for_status() class=class="hl-string">"hl-comment"># Raises an error for bad responses (4xx or 5xx)
            data = response.json()
            issues = data.get(class="hl-string">'issues', [])
            all_issues.extend(issues)

            print(fclass="hl-string">"Fetched {len(issues)} issues, total so far: {len(all_issues)}")

            if len(issues) < max_results:
                break class=class="hl-string">"hl-comment"># Exit loop if this is the last page
            start_at += len(issues)
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching issues: {e}")
            break

    return all_issues

def parse_issues_to_event_log(issues):
    class="hl-string">"""Parses issues and their changelogs into a structured event log."""
    event_log = []
    source_system = class="hl-string">"Jira Service Management"
    last_data_update = datetime.utcnow().isoformat() + class="hl-string">'Z'

    for issue in issues:
        case_id = issue[class="hl-string">'key']
        fields = issue.get(class="hl-string">'fields', {})
        
        class=class="hl-string">"hl-comment"># 1. Handle class="hl-string">'Change Request Created' event
        event_log.append({
            class="hl-string">'ChangeRequestId': case_id,
            class="hl-string">'ActivityName': class="hl-string">'Change Request Created',
            class="hl-string">'EventTime': fields.get(class="hl-string">'created'),
            class="hl-string">'SourceSystem': source_system,
            class="hl-string">'LastDataUpdate': last_data_update,
            class="hl-string">'ChangeRequestStatus': fields.get(class="hl-string">'status', {}).get(class="hl-string">'name'),
            class="hl-string">'ChangeRequestType': fields.get(class="hl-string">'customfield_10037', {}).get(class="hl-string">'value'), class=class="hl-string">"hl-comment"># Example custom field ID
            class="hl-string">'Assignee': fields.get(class="hl-string">'assignee', {}).get(class="hl-string">'displayName') if fields.get(class="hl-string">'assignee') else None,
            class="hl-string">'RiskLevel': fields.get(class="hl-string">'customfield_10039', {}).get(class="hl-string">'value'), class=class="hl-string">"hl-comment"># Example custom field ID
            class="hl-string">'Priority': fields.get(class="hl-string">'priority', {}).get(class="hl-string">'name'),
            class="hl-string">'TargetCompletionDate': fields.get(class="hl-string">'duedate'),
            class="hl-string">'ApprovalCycleTime': None, class=class="hl-string">"hl-comment"># Requires post-processing to calculate
            class="hl-string">'SLAStatus': None class=class="hl-string">"hl-comment"># Requires post-processing to calculate
        })

        class=class="hl-string">"hl-comment"># 2. Parse changelog for all other events
        changelog = issue.get(class="hl-string">'changelog', {}).get(class="hl-string">'histories', [])
        for history in changelog:
            event_time = history[class="hl-string">'created']
            for item in history.get(class="hl-string">'items', []):
                activity_name = None
                class=class="hl-string">"hl-comment"># Map status changes
                if item.get(class="hl-string">'field', class="hl-string">'').lower() == class="hl-string">'status':
                    activity_name = STATUS_TO_ACTIVITY_MAPPING.get(item.get(class="hl-string">'toString'))
                class=class="hl-string">"hl-comment"># Map field updates
                elif item.get(class="hl-string">'field') in FIELD_TO_ACTIVITY_MAPPING:
                    activity_name = FIELD_TO_ACTIVITY_MAPPING.get(item.get(class="hl-string">'field'))

                if activity_name:
                    event_log.append({
                        class="hl-string">'ChangeRequestId': case_id,
                        class="hl-string">'ActivityName': activity_name,
                        class="hl-string">'EventTime': event_time,
                        class="hl-string">'SourceSystem': source_system,
                        class="hl-string">'LastDataUpdate': last_data_update,
                        class="hl-string">'ChangeRequestStatus': item.get(class="hl-string">'toString') if item.get(class="hl-string">'field', class="hl-string">'').lower() == class="hl-string">'status' else fields.get(class="hl-string">'status', {}).get(class="hl-string">'name'),
                        class="hl-string">'ChangeRequestType': fields.get(class="hl-string">'customfield_10037', {}).get(class="hl-string">'value'),
                        class="hl-string">'Assignee': fields.get(class="hl-string">'assignee', {}).get(class="hl-string">'displayName') if fields.get(class="hl-string">'assignee') else None,
                        class="hl-string">'RiskLevel': fields.get(class="hl-string">'customfield_10039', {}).get(class="hl-string">'value'),
                        class="hl-string">'Priority': fields.get(class="hl-string">'priority', {}).get(class="hl-string">'name'),
                        class="hl-string">'TargetCompletionDate': fields.get(class="hl-string">'duedate'),
                        class="hl-string">'ApprovalCycleTime': None,
                        class="hl-string">'SLAStatus': None
                    })

    return event_log

if __name__ == class="hl-string">"__main__":
    print(class="hl-string">"Starting Jira data extraction...")
    jira_auth = (JIRA_EMAIL, JIRA_API_TOKEN)
    
    issues_data = get_issues(jira_auth)
    
    if issues_data:
        print(fclass="hl-string">"\nProcessing {len(issues_data)} issues into an event log...")
        event_log_data = parse_issues_to_event_log(issues_data)
        
        class=class="hl-string">"hl-comment"># Create DataFrame and save to CSV
        df = pd.DataFrame(event_log_data)
        df_sorted = df.sort_values(by=[class="hl-string">'ChangeRequestId', class="hl-string">'EventTime'])
        
        output_filename = class="hl-string">'jira_change_management_event_log.csv'
        df_sorted.to_csv(output_filename, index=False)
        print(fclass="hl-string">"\nExtraction complete. Event log saved to {output_filename}")
    else:
        print(class="hl-string">"No issues found for the given JQL query.")

Prêt à commencer ?

Appuyez-vous sur ce modèle de données pour lancer votre démarche de Process Mining appliquée à la gestion du changement. Commencez dès aujourd’hui à transformer vos données brutes en analyses concrètes.

Retour au guide d’amélioration

Télécharger le modèle

Améliorez la gestion du changement : atteignez 95 % de réussite dès maintenant

Éliminez les changements qui échouent et atteignez facilement un taux de réussite de 95 %.

Démarrez votre essai gratuit

Aucune carte bancaire requise. Configuration en quelques minutes.

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

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

Attributs de gestion du changement

Activités de gestion du changement

Guides d’extraction

Exportation CSV intégrée des demandes Jira Service Management

Étapes

Configuration

Exemple de requête config

Requête SQL directe sur la base de données Jira Server/Data Center

Étapes

Configuration

Exemple de requête sql

Extraction par script Python via l’API REST Jira et JQL

Étapes

Configuration

Exemple de requête python

Prêt à commencer ?

Améliorez la gestion du changement : atteignez 95 % de réussite dès maintenant

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

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

Attributs de gestion du changement

Activités de gestion du changement

Guides d’extraction

Exportation CSV intégrée des demandes Jira Service Management

Étapes

Configuration

Exemple de requête config

Requête SQL directe sur la base de données Jira Server/Data Center

Étapes

Configuration

Exemple de requête sql

Extraction par script Python via l’API REST Jira et JQL

Étapes

Configuration

Exemple de requête python

Prêt à commencer ?

Améliorez la gestion du changement : atteignez 95 % de réussite dès maintenant

Prêt à commencer ?

Améliorez la gestion du changement : atteignez 95 % de réussite dès maintenant