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

Votre modèle de données pour la gestion des demandes de service

Jira Service Management

Attributs de la gestion des demandes de service (17) Activités de gestion des demandes de service (13) Guides d'extraction (3)

Votre modèle de données pour la gestion des demandes de service

Ce modèle propose une méthode structurée pour recueillir les données essentielles à l’analyse de vos processus de gestion des demandes de service. Il précise les attributs importants à collecter, les activités clés à suivre et fournit des indications sur l’extraction de ces informations depuis votre système. Utilisez cette ressource pour simplifier la préparation de vos données et obtenir des analyses plus détaillées de vos opérations.

Attributs recommandés pour une analyse complète
Activités clés à suivre pour découvrir le processus
Guide d'extraction pour Jira Service Management

Vous découvrez les journaux d’événements ? En savoir plus sur la création d’un journal d’événements pour le Process Mining.

Télécharger le modèle

Attributs de la gestion des demandes de service

Voici les champs de données recommandés à inclure dans votre journal d’événements pour analyser de manière complète la gestion des demandes de service.

5 Obligatoire 5 Recommandé 7 Facultatif

	Nom	Description
	Activité ActivityName	Nom de l'événement ou de la tâche spécifique survenu au cours du cycle de vie de la demande de service.
Description Cet attribut décrit l’action précise ou la transition de statut qui s’est produite à un moment donné pour une demande de service. Exemples : « Request Created », « Request Assigned », « Solution Implemented » et « Request Closed ». 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 visualiser les cartes de processus, d’identifier les goulots d’étranglement et de détecter les écarts par rapport au flux de travail standard, ce qui est essentiel pour comprendre l’efficacité et la conformité des processus. Pourquoi c’est important Il définit les étapes du processus, ce qui permet de visualiser la carte du processus et d’analyser les schémas ainsi que les écarts du flux de travail. Où les obtenir Généralement dérivée de l'historique des transitions de « status » d'un problème Jira. Chaque entrée du journal des modifications du problème concernant le champ de statut représente une activité. Exemples Demande qualifiéeInformations demandéesSolution mise en œuvreDemande de service clôturée
	Heure de début EventTime	Date et heure précises auxquelles une activité ou un événement spécifique s'est produit.
Description L'heure de début, ou horodatage de l'événement, enregistre le moment exact où une activité s'est produite. Il s'agit d'un élément essentiel de toute analyse en Process Mining, car il fournit le contexte temporel de l'ensemble du processus. Cet horodatage sert à ordonner les événements, à calculer la durée entre les activités, à mesurer la durée totale du cycle d'un cas et à analyser la performance du processus par rapport à des objectifs temporels tels que les SLA. Sans horodatages précis, il est impossible de comprendre le déroulement du processus, d'identifier les retards ou de mesurer l'efficacité. Pourquoi c’est important Cet horodatage est essentiel pour ordonner les événements, calculer les durées et les temps de cycle, et identifier les goulots d'étranglement du processus. Où les obtenir Il s'agit de l'horodatage associé à chaque transition de statut dans le journal des modifications du problème Jira. L'heure de création du problème correspond au champ « created ». Exemples 2023-10-26T10:00:00Z2023-10-26T10:15:32Z2023-10-27T14:20:05Z
	Identifiant de demande de service ServiceRequestId	Identifiant unique de chaque demande de service, utilisé comme clé primaire pour tous les événements associés.
Description L'identifiant de demande de service, souvent appelé Issue Key dans Jira, identifie de manière unique chaque demande de service soumise par un utilisateur ou un système. Il constitue le fil conducteur reliant tous les événements ultérieurs, de l'enregistrement initial à la clôture définitive, et permet d'analyser intégralement le parcours de chaque demande de service. Dans le Process Mining, cet identifiant est essentiel pour la corrélation des cas. Il garantit que chaque activité, changement de statut et horodatage est correctement associé à la demande concernée, afin de constituer une instance de processus cohérente pour l'analyse. Pourquoi c’est important Cet identifiant est l'identifiant de cas fondamental qui relie toutes les activités associées au sein d'un même flux de processus de bout en bout, rendant l'analyse des processus possible. Où les obtenir Il s'agit du champ « key » d'un problème dans Jira Service Management. Exemples SR-2023-001IT-45892HELP-105
	Dernière mise à jour des données LastDataUpdate	Horodatage indiquant la date et l'heure de la dernière actualisation des données depuis le système source.
Description Cet attribut enregistre la date et l'heure de l'extraction de données la plus récente depuis Jira Service Management. Il fournit un contexte important sur l'actualité de l'analyse et des données présentées dans les Dashboards et les KPI. Dans toute analyse, il est essentiel de connaître l'actualité des données pour prendre des décisions éclairées. Cet horodatage aide les utilisateurs à déterminer s'ils consultent des informations en temps réel ou un instantané antérieur, ce qui influe sur la pertinence des résultats. Pourquoi c’est important Indique l'actualité des données et garantit que les analyses reposent sur des informations à jour. Où les obtenir Il s'agit d'un champ de métadonnées généré et enregistré par l'outil ou le script d'extraction des données à la fin de son exécution. Exemples 2023-10-27T02:00:00Z2023-10-28T02:00:00Z
	Système source SourceSystem	Système depuis lequel les données des demandes de service ont été extraites.
Description Cet attribut identifie l'origine des données, qui est ici Jira Service Management. Cela peut sembler secondaire lors de l'analyse de données provenant d'une seule source, mais devient essentiel lorsque des données de processus issues de plusieurs systèmes sont fusionnées. Pour l'analyse, il facilite le suivi de la traçabilité des données et le contrôle de leur qualité. Il permet également de filtrer et de comparer des processus susceptibles de s'étendre sur plusieurs plateformes logicielles ou d'interagir avec elles. Pourquoi c’est important Identifie l'origine des données, ce qui est essentiel pour la gouvernance des données et la combinaison de données de processus provenant de plusieurs systèmes d'entreprise. Où les obtenir Il s'agit généralement d'une valeur statique ajoutée lors de l'extraction et de la transformation des données afin d'indiquer l'origine du jeu de données. Exemples Jira Service ManagementJiraSM
	Date d'échéance du SLA SlaDueDate	Date et heure cibles auxquelles la demande de service doit être résolue conformément à son SLA.
Description La date d'échéance du SLA est un horodatage calculé qui représente la date limite de résolution d'une demande. Elle est déterminée par la priorité et le type de la demande, ainsi que par les règles de l'accord de niveau de service (SLA) configurées dans Jira Service Management. Cet attribut est fondamental pour le Dashboard « Performance des SLA des demandes de service » et le KPI « Taux de respect des SLA ». En comparant le délai de résolution réel à cette date d'échéance, le système peut déterminer si chaque demande a été traitée à temps, en retard ou risque de dépasser son SLA. Pourquoi c’est important Il s'agit de la référence utilisée pour mesurer la performance. Elle contribue directement au calcul de la conformité aux SLA et aide à prioriser le travail. Où les obtenir Les informations relatives aux SLA sont gérées par Jira Service Management et accessibles via l'API, souvent dans des champs personnalisés mis à jour dynamiquement. Exemples 2023-10-28T16:00:00Z2023-11-01T09:00:00Z
	Priorité de la demande RequestPriority	Niveau de priorité attribué à la demande de service, par exemple Faible, Moyenne, Élevée ou Critique.
Description La priorité de la demande indique son degré d'urgence et son impact sur l'activité. Cette classification détermine l'ordre de traitement des demandes et fixe souvent les délais de résolution cibles ainsi que les SLA. Dans l'analyse des processus, la priorité constitue une dimension essentielle de segmentation. Elle permet de comparer les temps de cycle et le respect des SLA selon les niveaux de priorité, afin de vérifier que les demandes prioritaires sont effectivement traitées plus rapidement et atteignent leurs objectifs. Elle contribue ainsi à évaluer l'efficacité du système de priorisation. Pourquoi c’est important Permet de segmenter l'analyse afin de vérifier que les demandes prioritaires sont traitées plus rapidement et respectent des niveaux de service plus exigeants. Où les obtenir Cela correspond au champ « priority » d'un problème Jira. Exemples La plus élevéeÉlevéeMoyenneFaible
	Responsable Assignee	Utilisateur ou agent actuellement chargé de traiter la demande de service.
Description Le responsable est la personne chargée de la prochaine action ou de la résolution de la demande de service. La valeur de cet attribut peut changer plusieurs fois au cours du cycle de vie de la demande, lorsque celle-ci est transmise entre différents agents ou équipes. Cet attribut est essentiel pour analyser la charge de travail, mesurer la performance et gérer les Ressources. Il permet de filtrer le processus par agent, de comparer les délais de résolution entre les personnes et d'identifier d'éventuels besoins de formation ou déséquilibres de charge à l'origine de goulots d'étranglement. Pourquoi c’est important Cet attribut est essentiel pour analyser la charge de travail des agents, mesurer la performance individuelle et comprendre l'affectation des Ressources. Où les obtenir Cela correspond au champ « assignee » d'un problème Jira. Exemples Alice JohnsonBob WilliamsNon attribué
	Statut de la demande RequestStatus	Statut actuel de la demande de service dans son cycle de vie.
Description Cet attribut représente l'état actuel d'une demande de service, par exemple « Open », « In Progress », « Waiting for Customer » ou « Resolved ». Il fournit un instantané de la situation de la demande à un moment donné. Alors que le journal des activités présente le déroulement historique, le statut actuel est utile pour analyser la charge de travail en cours et identifier les éléments bloqués. L'analyse peut, par exemple, se concentrer sur les demandes restées exceptionnellement longtemps au statut « Waiting for Vendor », afin de mettre en évidence les dépendances externes et les retards. Pourquoi c’est important Fournit un instantané de l'état actuel de chaque cas, permettant d'analyser le travail en cours et d'identifier les demandes bloquées ou anciennes. Où les obtenir Il s'agit du champ « status » d'un problème Jira. Exemples OuvertEn coursEn attente du clientRésolu
	Type de demande RequestType	Classification de la demande de service, par exemple « Demande d'accès » ou « Problème matériel ».
Description Le type de demande classe la demande de service selon sa nature. Il s’agit d’une dimension fondamentale pour l’analyse, car les différents types de demandes suivent souvent des processus de résolution distincts et présentent des SLA ainsi que des besoins en ressources différents. En segmentant l’analyse du processus par type de demande, les organisations peuvent adapter les améliorations à des flux de travail précis. Par exemple, le goulot d’étranglement d’une demande de « Password Reset » sera très différent de celui d’une demande de « New Server Provisioning ». Cet attribut est essentiel pour créer des Dashboards pertinents, comme « Resolution Quality by Category ». Pourquoi c’est important Cet attribut est essentiel pour comparer les processus, les charges de travail et la performance entre différentes catégories de demandes de service. Où les obtenir Cela correspond souvent au champ « issuetype » dans Jira ou à un champ personnalisé « Request Type » dans Jira Service Management. Exemples Demander un nouveau compteObtenir de l’aide informatiqueIntégrer un nouvel employé
	A été rouvert IsReopened	Indicateur booléen précisant si une demande de service a été rouverte après sa résolution.
Description Cet attribut calculé est un indicateur vrai/faux défini sur true lorsqu’un flux de travail de demande comprend l’activité « Request Reopened ». Il est obtenu en analysant la séquence des activités de chaque cas. Cet indicateur est essentiel pour calculer le KPI « Service Request Reopen Rate » et alimenter le Dashboard « Reopened Service Request Volume ». Un taux élevé de réouverture indique souvent une qualité insuffisante de la résolution dès le premier traitement, ce qui entraîne des reprises et une baisse de la satisfaction des clients. L’analyse des types de demandes ou des résolutions associés à cet indicateur permet de localiser les domaines à améliorer. Pourquoi c’est important Mesure directement les reprises et la qualité de la résolution dès la première intervention, deux indicateurs importants de l'efficacité du processus et de la satisfaction client. Où les obtenir Calculé lors de la transformation des données en vérifiant si la séquence des activités d'un cas contient une transition « Reopened » après une transition « Resolved ». Exemples truefalse
	Canal Channel	Méthode de soumission utilisée pour créer la demande de service, par exemple e-mail, portail ou API.
Description L'attribut Canal identifie la manière dont une demande de service est entrée dans le système. Les canaux courants dans Jira Service Management comprennent le portail client, l'e-mail ou la création directe par un agent. L'analyse du processus par canal est importante pour comprendre le comportement des utilisateurs et optimiser la prestation de services. Elle peut révéler que les demandes provenant de certains canaux prennent plus de temps à résoudre ou nécessitent davantage de précisions, ce qui peut indiquer la nécessité d'améliorer les formulaires du portail ou les règles d'analyse des e-mails. Elle contribue au Dashboard « Tendances du débit des demandes de service ». Pourquoi c’est important Aide à déterminer si le canal de soumission influe sur les délais de résolution, la clarté des demandes ou l'efficacité globale du processus. Où les obtenir Ces informations sont disponibles dans Jira Service Management via le champ « Request channel type ». Elles peuvent nécessiter un accès spécifique à l'API ou être stockées dans un champ personnalisé. Exemples PortailE-mailAPI
	Déclarant Reporter	Utilisateur ayant initialement créé ou signalé la demande de service.
Description Le déclarant est la personne, souvent un utilisateur final ou un client, qui a soumis la demande de service. Cet attribut identifie la partie prenante à l'origine du processus. Dans l'analyse, le déclarant peut servir à comprendre les habitudes de demande de différents utilisateurs, services ou segments de clientèle. Il permet de répondre à des questions telles que « Quels services soumettent le plus de demandes ? » ou « Certains utilisateurs rencontrent-ils régulièrement les mêmes problèmes ? ». Ces informations sont utiles pour la Gestion des problèmes proactive et l'amélioration de la formation des utilisateurs. Pourquoi c’est important Identifie l'auteur de la demande et permet d'analyser les volumes et les types de demandes par utilisateur, service ou client. Où les obtenir Cela correspond au champ « reporter » d'un problème Jira. Exemples Charles DarwinMarie CurieIsaac Newton
	Équipe affectée AssignedTeam	Équipe ou groupe chargé de traiter la demande de service.
Description Cet attribut indique l'équipe affectée à une demande. Il correspond souvent à un regroupement de niveau supérieur à celui du responsable individuel. Il est utile pour analyser la performance au niveau de l'équipe, par exemple en comparant l'équipe de support de premier niveau à l'équipe des opérations réseau. Cette dimension est essentielle pour des Dashboards tels que « Charge de travail des agents et indicateurs de résolution ». Elle permet d'agréger les indicateurs de performance au niveau de l'équipe, de faciliter les comparaisons équitables et de comprendre la contribution des différentes équipes à la prestation globale de services. Pourquoi c’est important Permet d'analyser la performance et d'équilibrer la charge de travail au niveau d'une équipe ou d'un service, plutôt que par agent individuel uniquement. Où les obtenir Il peut s'agir d'un champ personnalisé dans Jira, par exemple « Team », ou d'une valeur dérivée des attributs du profil utilisateur du responsable. Exemples Support informatique, niveau 1Équipe infrastructureSupport applicatif
	État du SLA SlaState	Indique si la demande de service respecte son SLA, l'a dépassé ou se trouve encore dans le délai défini.
Description L'état du SLA est un attribut calculé qui catégorise chaque demande de service selon sa performance par rapport à l'échéance de son SLA. Les valeurs possibles comprennent « Met », « Breached » ou « In Progress ». Il est déterminé en comparant l'horodatage de résolution à « SlaDueDate ». Il s'agit de l'attribut central du Dashboard « Performance des SLA des demandes de service » et il sert à calculer le KPI « Taux de respect des SLA ». Il fournit une vue claire et immédiate de la conformité aux niveaux de service, essentielle pour le reporting, la gestion des contrats et le maintien de la qualité de service. Pourquoi c’est important Fournit un indicateur clair et immédiat de la performance des SLA, une mesure importante de la qualité de service et de la conformité contractuelle. Où les obtenir Calculé lors de la transformation des données. Si l'heure de résolution est antérieure à « SlaDueDate », l'état est « Met » ; sinon, il est « Breached ». Exemples RespectéEn infractionEn cours
	Organisation Organization	Organisation cliente ou service interne auquel appartient le déclarant.
Description Cet attribut regroupe les déclarants par organisation ou par service. Jira Service Management dispose d'une fonctionnalité intégrée « Organizations » qui permet aux agents de gérer les demandes de plusieurs clients ou équipes internes. L'analyse par organisation fournit un contexte métier précieux. Elle peut aider à identifier les clients ou services qui mobilisent le plus de Ressources de support, à déterminer si certains groupes rencontrent des problèmes récurrents et à vérifier que les SLA sont respectés de manière constante dans les différentes unités opérationnelles. Pourquoi c’est important Facilite l'analyse de la demande de services et de la performance par client ou service interne, en fournissant des informations importantes pour l'activité. Où les obtenir Ces données proviennent du champ « Organizations » associé à la demande de service dans Jira Service Management. Exemples Acme CorporationService financierGlobal Tech Inc.
	Résolution Resolution	Résultat final ou conclusion d'une demande de service résolue.
Description Le champ Resolution indique la raison pour laquelle une demande de service a été clôturée. Les valeurs courantes comprennent « Done », « Won't Do », « Duplicate » ou « Cannot Reproduce ». Il fournit des informations sur la clôture qui vont au-delà des seuls statuts « Resolved » ou « Closed ». L'analyse des résolutions aide à comprendre la qualité et la nature des résultats. Par exemple, un nombre élevé de résolutions « Duplicate » peut signaler un problème dans le processus de soumission des demandes, tandis que le suivi des résolutions qui entraînent la réouverture de demandes peut mettre en évidence des solutions inefficaces. Pourquoi c’est important Fournit un contexte sur le résultat d'une demande, afin d'analyser la qualité de la résolution et d'identifier les tendances expliquant la clôture des demandes. Où les obtenir Cela correspond au champ « resolution » d'un problème Jira, généralement renseigné lorsque le problème passe dans une catégorie de statut « done ». Exemples TerminéNe sera pas traitéDoublonCorrigé

Obligatoire Recommandé Facultatif

Activités de gestion des demandes de service

Voici les principales étapes du processus et les jalons à enregistrer dans votre journal d’événements pour découvrir et optimiser précisément le processus.

5 Recommandé 8 Facultatif

	Activité	Description
	Demande attribuée	Cette activité se produit lorsqu’une demande de service est assignée à un agent ou à une équipe précise pour être résolue. Jira suit explicitement les changements du champ « Assignee », ce qui fournit un horodatage clair de l’assignation.
Pourquoi c’est important Il s’agit d’une étape importante pour mesurer le délai entre le triage et l’assignation, ainsi que la répartition de la charge de travail des agents. Elle marque le passage de la mise en file d’attente à la prise en charge active. Où les obtenir Capturée dans l’historique de l’élément en recherchant la première occurrence où le champ « Assignee » est renseigné ou modifié après une période sans assignation. Collecte Utilisez l’horodatage de la première modification du champ « Assignee » dans l’historique de l’élément. Type d’événement explicit
	Demande de service clôturée	Cette activité représente la clôture administrative finale de la demande de service, qui intervient souvent automatiquement après une période définie dans l’état « Resolved ». Elle constitue le point terminal du cycle de vie de l’élément dans Jira.
Pourquoi c’est important Il s’agit de l’événement de fin définitif du processus. Le temps écoulé entre « Resolved » et « Closed » peut être analysé pour comprendre la charge administrative ou les règles de clôture automatique. Où les obtenir Déduite de l’historique de l’élément. L’horodatage correspond au dernier changement de statut vers « Closed » ou un statut terminal équivalent. Collecte Identifiez l’horodatage du dernier changement de statut vers « Closed ». Type d’événement inferred
	Demande de service créée	Cette activité marque le début du cycle de vie d’une demande de service, lorsqu’un utilisateur soumet officiellement une demande via un portail, un e-mail ou un autre canal. Cet événement est enregistré explicitement dans Jira lorsqu’un nouvel élément de type « Service Request » est créé, avec son horodatage de création.
Pourquoi c’est important Il s’agit de l’événement de début principal du processus. Il est essentiel pour calculer le temps de cycle global et comprendre le volume des demandes ainsi que leurs schémas d’arrivée. Où les obtenir Il s’agit d’un événement explicite enregistré dans la table d’historique des éléments. L’horodatage de l’activité correspond au champ « created » de l’élément Jira. Collecte Utilisez l’horodatage de création de l’élément depuis la table « issues » ou l’historique. Type d’événement explicit
	Demande de service résolue	Cette activité marque le moment officiel où la demande est considérée comme satisfaite et où la solution est enregistrée. Jira renseigne le champ « Resolution Date » lorsqu’un élément passe pour la première fois à un statut de la catégorie « Done ».
Pourquoi c’est important Il s’agit d’une étape de fin principale du processus, essentielle pour calculer le délai de résolution et le respect des SLA. Elle marque la fin du travail actif. Où les obtenir Il s’agit d’un événement explicite. L’horodatage correspond à la valeur du champ « Resolution Date » de l’élément Jira, renseigné lors de la première transition vers un statut de la catégorie « Done ». Collecte Utilisez le champ « resolutiondate » de l’élément Jira. Ce champ est renseigné automatiquement. Type d’événement explicit
	Résolution proposée	Dans de nombreux flux de travail de centre de services, il s’agit d’une étape distincte au cours de laquelle une solution est proposée au demandeur pour approbation. Cette étape est déduite lorsque le statut de la demande passe à un état tel que « Pending Customer Acceptance » ou « Awaiting Confirmation ».
Pourquoi c’est important Cette activité isole le temps consacré à l’attente du retour du client après la présentation d’une solution et permet de le distinguer du temps de travail interne. Où les obtenir Déduite de l’historique de l’élément, avec un horodatage correspondant au changement de statut vers un état indiquant que la solution attend la validation du client. Collecte Identifiez l’horodatage du changement de statut vers « Pending Customer Acceptance » ou un statut équivalent. Type d’événement inferred
	Début de la collaboration avec le fournisseur	Cette activité indique que la demande de service a été escaladée vers un fournisseur externe ou un tiers, ou qu’elle nécessite son intervention. Elle est déduite du passage de l’élément à un statut tel que « Waiting for vendor » ou « With Third Party ».
Pourquoi c’est important Le suivi des échanges avec les fournisseurs est essentiel pour identifier les dépendances externes et les retards qui échappent au contrôle direct du centre de services interne. Où les obtenir Déduite de l’historique de l’élément. L’horodatage correspond au moment où le statut de l’élément passe à un statut « vendor » défini. Collecte Identifiez l’horodatage auquel le champ « status » prend une valeur telle que « Waiting for Vendor ». Type d’événement inferred
	Demande qualifiée	Cette activité représente l’évaluation initiale d’une demande de service, au cours de laquelle sont déterminés sa priorité, sa catégorie et son impact. Elle est généralement déduite d’un changement de statut, par exemple lors du passage de « New » à « In Progress », ou d’un statut dédié « Triaged ».
Pourquoi c’est important L’analyse du délai de triage permet d’évaluer l’efficacité du traitement initial des demandes. Les retards à ce stade peuvent avoir un impact important sur les délais globaux de résolution et le respect des SLA. Où les obtenir Déduite de l’historique de l’élément en identifiant le premier horodatage d’un changement de statut depuis un état initial « New » ou « Open » vers un état actif tel que « In Progress ». Collecte Identifiez le premier changement de statut à partir de « New » ou d’un statut initial équivalent, selon le flux de travail du projet. Type d’événement inferred
	Demande rouverte	Cette activité enregistre les cas où une demande de service précédemment résolue revient à un état actif. Elle est déduite d’un changement de statut depuis un état résolu ou fermé vers un état ouvert ou en cours.
Pourquoi c’est important Le suivi des demandes rouvertes est essentiel pour mesurer la qualité des résolutions et le taux de résolution au premier contact. Un taux élevé de réouverture indique des solutions inefficaces ou des problèmes récurrents. Où les obtenir Déduite de l’historique de l’élément en identifiant une transition de statut depuis une catégorie « Resolved » ou « Closed » vers une catégorie « Open » ou « In Progress ». Collecte Recherchez un changement de statut depuis une catégorie « Done » vers une catégorie « To Do » ou « In Progress ». Type d’événement inferred
	Fin de la collaboration avec le fournisseur	Cette activité représente le moment où le fournisseur externe a terminé son intervention et où la demande de service revient à l’équipe interne. Elle est déduite lorsque l’élément quitte le statut « Waiting for vendor ».
Pourquoi c’est important Mesurer la durée des échanges avec les fournisseurs aide à gérer leurs performances et à comprendre l’impact des parties externes sur les délais globaux de résolution. Où les obtenir Déduite de l’historique de l’élément. L’horodatage correspond au moment où le statut passe d’un état « vendor » à un état « In Progress ». Collecte Identifiez l’horodatage auquel le champ « status » passe d’un état « vendor » à un état actif. Type d’événement inferred
	Informations demandées	Cette activité marque le moment où un agent a besoin d’informations supplémentaires du demandeur pour poursuivre la résolution. Elle est généralement déduite du passage de l’élément à un statut tel que « Waiting for customer » ou « Pending Input ».
Pourquoi c’est important Des cycles « Information Requested » fréquents ou longs peuvent révéler des demandes initiales peu claires ou une communication inefficace, et constituer une source importante de retards. Où les obtenir Déduite de l’historique de l’élément. L’horodatage correspond au moment où le statut de l’élément passe à « Waiting for customer » ou à un statut équivalent. Collecte Identifiez l’horodatage auquel le champ « status » prend une valeur indiquant que le processus est en attente du client. Type d’événement inferred
	Informations fournies	Cette activité se produit lorsque le demandeur fournit les informations nécessaires, ce qui permet à l’agent de reprendre son travail. Elle est déduite lorsque l’élément quitte le statut « Waiting for customer », souvent après l’ajout d’un commentaire par le demandeur.
Pourquoi c’est important Cette activité clôt la boucle de demande et de réponse avec le client. Le temps écoulé entre la demande et la réception des informations constitue une composante importante du temps d’attente du processus. Où les obtenir Déduite de l’historique de l’élément. L’horodatage correspond au moment où le statut passe de « Waiting for customer » à un état « In Progress ». Collecte Identifiez l’horodatage auquel le champ « status » passe d’un état d’attente à un état actif. Type d’événement inferred
	Résolution confirmée	Cette activité se produit lorsque le demandeur accepte officiellement la solution proposée, ce qui déclenche souvent une transition automatisée vers le statut « Resolved ». L’événement est généralement déduit de ce changement de statut.
Pourquoi c’est important Cette étape valide l’efficacité de la solution et déclenche l’arrêt du compteur SLA. Elle aide à mesurer le temps nécessaire aux clients pour confirmer la résolution. Où les obtenir Déduite de l’historique de l’élément. L’horodatage correspond au passage du statut de « Pending Customer Acceptance » à « Resolved » ou « Closed ». Collecte Identifiez l’horodatage du changement de statut de « Pending Customer Acceptance » vers un statut « Resolved » ou « Closed ». Type d’événement inferred
	Solution mise en œuvre	Cette activité indique que l’agent a effectué les actions nécessaires ou élaboré une solution pour traiter la demande de service. Elle est souvent déduite d’un changement de statut vers « Pending Review » ou directement vers « Resolved ».
Pourquoi c’est important Cette étape marque l’achèvement du travail de résolution principal. Le temps qui la précède représente souvent la partie du processus qui apporte le plus de valeur. Où les obtenir Déduite de l’historique de l’élément, avec pour horodatage celui du changement de statut vers « Resolved », « Pending Acceptance » ou un statut similaire précédant la clôture. Collecte Identifiez l’horodatage auquel le champ « status » prend une valeur indiquant que le travail est terminé. Type d’événement inferred

Recommandé Facultatif

Guides d'extraction

Comment récupérer vos données depuis Jira Service Management

Étapes

Connectez-vous à votre instance Jira Service Management et ouvrez le menu principal.
Sélectionnez Filtres, puis Recherche avancée de demandes. Le navigateur de demandes s'ouvre et vous permet de créer des requêtes.
Dans la barre de recherche, saisissez la requête JQL fournie dans la section Requête afin de filtrer les demandes de service à analyser. Adaptez la clé du projet et la période si nécessaire.
Cliquez sur le bouton Rechercher pour exécuter la requête. Vérifiez la liste des demandes retournées afin de vous assurer qu'il s'agit du bon jeu de données.
Dans l'angle supérieur droit de la page de résultats, cliquez sur l'icône Exporter, qui ressemble généralement à une boîte avec une flèche sortante.
Dans le menu déroulant, sélectionnez XML. Ce format est indispensable, car l'export CSV standard ne contient pas l'historique détaillé des modifications nécessaire à la création d'un journal d'événements complet.
Enregistrez le fichier XML téléchargé sur votre système local. Il contient toutes les demandes correspondant à votre requête, avec leur historique complet des modifications intégré à chaque demande.
Comme le fichier XML exporté n'est pas au format d'un journal d'événements, une étape de post-traitement est nécessaire. Utilisez un script, par exemple en Python, PowerShell ou dans un autre langage, pour analyser le fichier XML.
Le script doit parcourir chaque demande et créer un événement « Service Request Created » à partir de l'horodatage de création. Il doit ensuite analyser l'historique des modifications de chaque demande afin d'identifier les changements des champs « status » et « assignee » correspondant aux activités requises. Une nouvelle ligne doit être créée pour chaque changement identifié.
Le script doit transformer ces données en un fichier CSV plat, avec les colonnes ServiceRequestId, ActivityName, EventTime et tous les autres attributs requis et recommandés.
Le résultat final du script constitue le journal d'événements. Enregistrez ce fichier CSV et préparez-le pour son importation dans l'outil de Process Mining.

Configuration

Filtre de projet JQL : Utilisez project = "[Your JSM Project Key]" pour cibler le projet de gestion des services concerné. Remplacez l'espace réservé par la clé de votre projet, par exemple « JSM » ou « HELPDESK ».
Filtre de type de demande JQL : Utilisez issuetype = "Service Request" ou le nom exact du type de demande utilisé pour les demandes de service dans votre configuration.
Période : Il est vivement recommandé de filtrer une période précise afin de maîtriser la taille de l'export. Utilisez une clause telle que created >= "YYYY-MM-DD" AND created <= "YYYY-MM-DD". Une période de 3 à 6 mois constitue souvent un bon point de départ.
Format d'export : Vous devez sélectionner XML pour l'export. Le format CSV ne contient pas les données de l'historique des modifications nécessaires à la création du journal d'événements.
Autorisations Jira : L'utilisateur qui effectue l'export doit disposer de l'autorisation « Browse Projects » pour le projet Jira indiqué, afin de pouvoir consulter et exporter les demandes.
Volume de données : L'interface Jira limite souvent l'export à 1 000 demandes à la fois. Si votre requête renvoie davantage de résultats, exportez les données par lots plus petits en réduisant la période de chaque export.

a Exemple de requête config

project = "JSM" AND issuetype = "Service Request" AND created >= "2023-01-01" AND created <= "2023-12-31" ORDER BY created ASC

Étapes

Obtenir l'accès à la base de données : Obtenez des identifiants en lecture seule ainsi que les informations de connexion, notamment le nom d'hôte, le port et le nom de la base de données SQL utilisée par l'instance Jira. L'aide d'un administrateur de bases de données ou de votre service informatique est généralement nécessaire.
Identifier le schéma Jira : Connectez-vous à la base de données avec un client SQL tel que DBeaver, SQuirreL SQL ou SQL Server Management Studio. Familiarisez-vous avec les tables principales : jiraissue pour les données de base des demandes, changegroup pour l'historique des modifications, changeitem pour le détail de chaque modification, project pour les informations sur les projets, issuetype et priority.
Repérer les identifiants des champs personnalisés : Des attributs tels que RequestType et SlaDueDate sont souvent des champs personnalisés. Identifiez leurs identifiants en interrogeant la table customfield : SELECT id, cfname FROM customfield WHERE cfname IN ('[Your Request Type Field Name]', '[Your SLA Field Name]');. Notez ces identifiants pour les utiliser dans la requête principale.
Personnaliser la requête SQL : Copiez le script SQL fourni dans votre client SQL. Remplacez soigneusement toutes les valeurs d'espace réservé, placées entre crochets, par les valeurs réelles de votre configuration Jira. Cela concerne notamment les clés de projet, les noms de types de demandes, les noms de statuts et les identifiants des champs personnalisés.
Définir la période : Repérez la clause WHERE i.created >= '[YYYY-MM-DD]' dans la partie initiale issue_base de la requête. Modifiez la date pour définir la période d'extraction.
Exécuter la requête : Lancez le script SQL modifié. La requête est conçue pour fonctionner avec les bases SQL courantes, notamment PostgreSQL, SQL Server et MySQL. Sur les instances Jira volumineuses, son exécution peut prendre plusieurs minutes.
Vérifier les résultats : Une fois la requête terminée, examinez brièvement le résultat pour vérifier qu'il contient des lignes et que les colonnes telles que ServiceRequestId, ActivityName et EventTime sont renseignées comme prévu.
Exporter les données : Exportez l'ensemble des résultats depuis votre client SQL vers un fichier CSV. Donnez-lui un nom explicite, par exemple jira_servicerequest_eventlog.csv.
Préparer l'importation : Ouvrez le fichier CSV et vérifiez que les en-têtes correspondent exactement aux noms d'attributs requis, par exemple ServiceRequestId, ActivityName et EventTime. Enregistrez le fichier au format UTF-8 pour assurer sa compatibilité avec ProcessMind.

Configuration

Prérequis : un accès direct en lecture seule à la base de données de production ou à la réplique Jira est requis. L’accès standard à l’application ne suffit pas. Vous devez également bien connaître le flux de travail de votre projet Service Desk, notamment les noms exacts des statuts, des types de demandes et des champs personnalisés.
Filtres principaux de la requête : la requête doit être configurée pour cibler le bon jeu de données. Portez une attention particulière aux clauses WHERE suivantes :
- p.pkey IN ('[Your Project Key]') : il s’agit du filtre le plus important. Il limite les données à un ou plusieurs projets Jira Service Management précis.
- it.pname = '[Your Service Request Issue Type]' : ce filtre garantit que vous extrayez uniquement les demandes de service, et non les incidents, les problèmes ou d’autres types de demandes.
- i.created >= '[YYYY-MM-DD]' : ce filtre définit la date de début de l’extraction. Pour une première analyse, il est recommandé d’utiliser une période couvrant les 3 à 6 derniers mois.
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 statuts Jira dans la requête. Vous devez remplacer les espaces réservés tels que [Status for Triage], [Waiting for Customer Status] et [Resolved Status] par les noms utilisés dans votre flux de travail.
Considérations relatives aux performances : l’exécution directe de cette requête sur une base Jira volumineuse et active peut consommer beaucoup de ressources et nuire aux performances de l’application pour les utilisateurs. Il est vivement recommandé d’effectuer l’extraction sur une base de données réplique en lecture seule ou en dehors des heures de pointe.

a Exemple de requête sql

WITH issue_base AS (
    SELECT 
        i.id AS issue_id,
        i.issuenum,
        i.project AS project_id,
        p.pkey || '-' || i.issuenum AS ServiceRequestId,
        i.created AS creation_timestamp,
        i.resolutiondate AS resolution_timestamp,
        u.display_name AS Assignee,
        pr.pname AS RequestPriority,
        s.pname AS RequestStatus,
        it.pname AS IssueTypeName, 
        cf_type.stringvalue AS RequestType,
        cf_sla.datevalue AS SlaDueDate
    FROM jiraissue i
    JOIN project p ON i.project = p.id
    LEFT JOIN issuetype it ON i.issuetype = it.id
    LEFT JOIN issuestatus s ON i.issuestatus = s.id
    LEFT JOIN priority pr ON i.priority = pr.id
    LEFT JOIN app_user u ON i.assignee = u.user_key
    LEFT JOIN customfieldvalue cf_type ON i.id = cf_type.issue AND cf_type.customfield = [Your Request Type Custom Field ID]
    LEFT JOIN customfieldvalue cf_sla ON i.id = cf_sla.issue AND cf_sla.customfield = [Your SLA Due Date Custom Field ID]
    WHERE p.pkey IN ('[Your Project Key]') 
    AND it.pname = '[Your Service Request Issue Type]' 
    AND i.created >= '[YYYY-MM-DD]'
),
change_history AS (
    SELECT 
        cg.issueid AS issue_id,
        cg.created AS change_timestamp,
        ci.field AS changed_field,
        ci.oldstring AS old_value,
        ci.newstring AS new_value
    FROM changegroup cg
    JOIN changeitem ci ON cg.id = ci.groupid
    WHERE ci.fieldtype = 'jira' AND ci.field IN ('status', 'assignee', 'resolution')
)
SELECT
    ib.ServiceRequestId,
    'Service Request Created' AS ActivityName,
    ib.creation_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Request Triaged' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.new_value = '[Status for Triage]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Request Assigned' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'assignee' AND ch.new_value IS NOT NULL

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Information Requested' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.new_value = '[Waiting for Customer Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Information Provided' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.old_value = '[Waiting for Customer Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Vendor Engagement Started' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.new_value = '[Waiting for Vendor Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Vendor Engagement Ended' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.old_value = '[Waiting for Vendor Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Solution Implemented' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.new_value = '[Solution Implemented Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Resolution Proposed' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.new_value = '[Pending Customer Acceptance Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Request Reopened' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'resolution' AND ch.new_value IS NULL AND ch.old_value IS NOT NULL

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Resolution Confirmed' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.old_value = '[Pending Customer Acceptance Status]' AND ch.new_value = '[Resolved Status]'

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Service Request Resolved' AS ActivityName,
    ib.resolution_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
WHERE ib.resolution_timestamp IS NOT NULL

UNION ALL

SELECT
    ib.ServiceRequestId,
    'Service Request Closed' AS ActivityName,
    ch.change_timestamp AS EventTime,
    'Jira' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    ib.Assignee,
    ib.RequestPriority,
    ib.RequestStatus,
    ib.RequestType,
    ib.SlaDueDate
FROM issue_base ib
JOIN change_history ch ON ib.issue_id = ch.issue_id
WHERE ch.changed_field = 'status' AND ch.new_value = '[Closed Status]'
ORDER BY 1, 3;

Étapes

Prérequis et configuration : vérifiez que Python 3.6 ou une version ultérieure est installé sur votre système. Installez les bibliothèques Python nécessaires en exécutant la commande suivante dans votre terminal : pip install requests pandas.
Générez un jeton d’API Jira : connectez-vous à votre compte Jira Cloud. Ouvrez les paramètres de votre profil, sélectionnez « Account settings », puis accédez à l’onglet « Security » et créez un jeton d’API. Copiez ce jeton dans un emplacement sécurisé, car il sera utilisé pour l’authentification.
Identifiez les identifiants des champs personnalisés : de nombreux attributs Jira, comme « Request Type » ou « SLA Due Date », sont des champs personnalisés. Pour trouver leurs identifiants, accédez à « Settings » > « Issues » > « Custom fields ». Recherchez le champ souhaité, cliquez sur les trois points « ... », puis sélectionnez « View field information ». L’identifiant figure dans l’URL, par exemple customFieldId=10021. Notez ces identifiants pour configurer le script.
Configurez le script Python : ouvrez le script Python fourni dans un éditeur de texte. Renseignez les variables de configuration situées en haut du fichier, notamment JIRA_URL, JIRA_EMAIL, JIRA_API_TOKEN, la requête jql_query permettant de sélectionner vos demandes de service et les CUSTOM_FIELD_IDS identifiés à l’étape précédente.
Associez les statuts Jira aux activités : examinez attentivement le dictionnaire STATUS_ACTIVITY_MAP du script. Vous devez mettre à jour cette association pour qu’elle corresponde à votre flux de travail Jira Service Management. Les clés doivent reprendre les noms exacts de vos statuts Jira, par exemple « Waiting for customer », et les valeurs doivent correspondre aux noms d’activités requis dans le journal d’événements, par exemple « Information Requested ».
Exécutez le script d’extraction : ouvrez un terminal ou une invite de commandes, accédez au répertoire dans lequel vous avez enregistré le script, puis exécutez-le avec la commande suivante : python jira_extraction_script.py. Le script se connectera à l’API Jira, récupérera les données des demandes, les traitera et affichera l’avancement dans la console.
Vérifiez le fichier de sortie : une fois le script terminé, il génère un fichier CSV nommé jira_event_log.csv dans le même répertoire. Ouvrez ce fichier dans un tableur pour en vérifier le contenu. Assurez-vous que toutes les colonnes sont présentes et renseignées comme prévu.
Préparez l’importation dans ProcessMind : vérifiez que les en-têtes de colonnes du fichier CSV correspondent exactement aux exigences suivantes : ServiceRequestId, ActivityName, EventTime, SourceSystem, LastDataUpdate, Assignee, RequestPriority, RequestStatus, RequestType et SlaDueDate. Le fichier est désormais prêt à être importé dans ProcessMind.

Configuration

Authentification Jira : le script nécessite l’URL de votre domaine Jira, l’adresse e-mail associée à votre compte Jira et un jeton d’API personnel pour sécuriser l’accès.
Requête JQL (jql_query) : il s’agit du filtre principal de votre extraction. Il est essentiel de définir une requête JQL précise pour sélectionner les bonnes demandes. Nous vous recommandons de filtrer par project, issuetype et une période précise à l’aide de createdDate, afin de maîtriser le volume de données, par exemple project = 'SERVICEDESK' AND issuetype = 'Service Request' AND createdDate >= '-6m'.
Association des statuts aux activités (STATUS_ACTIVITY_MAP) : ce dictionnaire est essentiel pour convertir correctement les changements de statut Jira en activités de processus pertinentes. Vous devez personnaliser cette association pour refléter le flux de travail Jira propre à votre organisation. Tout statut absent de cette association sera ignoré.
Identifiants des champs personnalisés (CUSTOM_FIELD_IDS) : pour extraire les données de champs personnalisés tels que « Request Type » ou « SLA Due Date », vous devez fournir leurs identifiants système uniques, par exemple customfield_10021. Ils doivent être configurés correctement pour que les attributs soient renseignés.
Période et performances : pour les premières extractions, il est recommandé d’utiliser une période JQL de 3 à 6 mois afin de conserver des performances maîtrisables. L’extraction de plusieurs années de données peut être lente en raison de la pagination de l’API et des limites de débit.

a Exemple de requête python

import os
import requests
import pandas as pd
from datetime import datetime, timezone

class=class="hl-string">"hl-comment"># --- CONFIGURATION --- 
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 = os.environ.get(class="hl-string">"JIRA_API_TOKEN", class="hl-string">"YOUR_JIRA_API_TOKEN") class=class="hl-string">"hl-comment"># Best practice: use environment variables

class=class="hl-string">"hl-comment"># JQL query to fetch service request issues. 
class=class="hl-string">"hl-comment"># Recommended: Filter by project, issuetype, and a date range.
jql_query = class="hl-string">"project = 'SD' AND issuetype = 'Service Request' AND created >= '-6m' ORDER BY created DESC"

class=class="hl-string">"hl-comment"># Map your specific Jira status names to the desired activity names.
class=class="hl-string">"hl-comment"># This is CRITICAL for capturing the correct process flow.
STATUS_ACTIVITY_MAP = {
    class="hl-string">'In Progress': class="hl-string">'Request Triaged',
    class="hl-string">'Waiting for customer': class="hl-string">'Information Requested',
    class="hl-string">'Waiting for support': class="hl-string">'Information Provided',
    class="hl-string">'Waiting for vendor': class="hl-string">'Vendor Engagement Started',
    class="hl-string">'Vendor Responded': class="hl-string">'Vendor Engagement Ended',
    class="hl-string">'Pending Review': class="hl-string">'Solution Implemented',
    class="hl-string">'Pending Customer Acceptance': class="hl-string">'Resolution Proposed',
    class="hl-string">'Reopened': class="hl-string">'Request Reopened',
    class="hl-string">'Resolved': class="hl-string">'Resolution Confirmed', class=class="hl-string">"hl-comment"># Or could be class="hl-string">'Solution Implemented' depending on workflow
    class="hl-string">'Closed': class="hl-string">'Service Request Closed'
}

class=class="hl-string">"hl-comment"># Map desired attributes to their custom field IDs in Jira.
class=class="hl-string">"hl-comment"># Find these IDs in your Jira instance under Settings > Issues > Custom Fields.
CUSTOM_FIELD_IDS = {
    class="hl-string">'RequestType': class="hl-string">'[customfield_10021]', class=class="hl-string">"hl-comment"># Example ID for Request Type
    class="hl-string">'SlaDueDate': class="hl-string">'[customfield_10030]'    class=class="hl-string">"hl-comment"># Example ID for SLA Due Date
}

class=class="hl-string">"hl-comment"># --- SCRIPT LOGIC --- 
def fetch_jira_issues(url, email, token, jql):
    class="hl-string">"""Fetches all issues from Jira matching the JQL query, handling pagination."""
    headers = {
        class="hl-string">"Accept": class="hl-string">"application/json",
        class="hl-string">"Content-Type": class="hl-string">"application/json"
    }
    auth = (email, token)
    
    issues = []
    start_at = 0
    max_results = 50
    total = -1

    print(fclass="hl-string">"Fetching issues from Jira with JQL: {jql}")
    while total == -1 or start_at < total:
        api_url = fclass="hl-string">"{url}/rest/api/3/search"
        params = {
            class="hl-string">'jql': jql,
            class="hl-string">'startAt': start_at,
            class="hl-string">'maxResults': max_results,
            class="hl-string">'expand': class="hl-string">'changelog'
        }
        
        response = requests.get(api_url, headers=headers, params=params, auth=auth)
        response.raise_for_status() class=class="hl-string">"hl-comment"># Exit if there is an error
        data = response.json()
        
        if total == -1:
            total = data[class="hl-string">'total']
            print(fclass="hl-string">"Found {total} total issues to process.")

        page_issues = data.get(class="hl-string">'issues', [])
        issues.extend(page_issues)
        start_at += len(page_issues)
        print(fclass="hl-string">"Fetched {len(issues)} / {total} issues...")

        if len(page_issues) == 0:
            break

    return issues

def process_issues_to_event_log(issues):
    class="hl-string">"""Processes raw issue data into a structured event log."""
    event_log = []
    now_utc = datetime.now(timezone.utc).isoformat()
    source_system = class="hl-string">"Jira Service Management"

    for issue in issues:
        case_id = issue[class="hl-string">'key']
        fields = issue.get(class="hl-string">'fields', {})
        changelog = issue.get(class="hl-string">'changelog', {}).get(class="hl-string">'histories', [])
        
        class=class="hl-string">"hl-comment"># Helper to get nested field values safely
        def get_field_value(field_data, key):
            return field_data.get(key)
        
        def get_custom_field_value(field_data, custom_field_id):
            custom_field = field_data.get(custom_field_id)
            if isinstance(custom_field, dict):
                return custom_field.get(class="hl-string">'value')
            return custom_field

        class=class="hl-string">"hl-comment"># --- Extract common attributes for all events of this case ---
        assignee = get_field_value(fields.get(class="hl-string">'assignee', {}), class="hl-string">'displayName')
        priority = get_field_value(fields.get(class="hl-string">'priority', {}), class="hl-string">'name')
        status = get_field_value(fields.get(class="hl-string">'status', {}), class="hl-string">'name')
        request_type = get_custom_field_value(fields, CUSTOM_FIELD_IDS[class="hl-string">'RequestType'])
        sla_due_date = get_custom_field_value(fields, CUSTOM_FIELD_IDS[class="hl-string">'SlaDueDate'])

        common_attributes = {
            class="hl-string">'ServiceRequestId': case_id,
            class="hl-string">'SourceSystem': source_system,
            class="hl-string">'LastDataUpdate': now_utc,
            class="hl-string">'Assignee': assignee,
            class="hl-string">'RequestPriority': priority,
            class="hl-string">'RequestStatus': status,
            class="hl-string">'RequestType': request_type,
            class="hl-string">'SlaDueDate': sla_due_date
        }

        class=class="hl-string">"hl-comment"># 1. Activity: Service Request Created
        event_log.append({
            **common_attributes,
            class="hl-string">'ActivityName': class="hl-string">'Service Request Created',
            class="hl-string">'EventTime': fields[class="hl-string">'created']
        })

        class=class="hl-string">"hl-comment"># 2. Activity: Service Request Resolved
        if fields.get(class="hl-string">'resolutiondate'):
            event_log.append({
                **common_attributes,
                class="hl-string">'ActivityName': class="hl-string">'Service Request Resolved',
                class="hl-string">'EventTime': fields[class="hl-string">'resolutiondate']
            })

        class=class="hl-string">"hl-comment"># 3. Process changelog for all other activities
        for history in changelog:
            created_time = history[class="hl-string">'created']
            for item in history[class="hl-string">'items']:
                class=class="hl-string">"hl-comment"># Activity: Request Assigned
                if item[class="hl-string">'field'].lower() == class="hl-string">'assignee':
                    event_log.append({
                        **common_attributes,
                        class="hl-string">'ActivityName': class="hl-string">'Request Assigned',
                        class="hl-string">'EventTime': created_time,
                        class="hl-string">'Assignee': item.get(class="hl-string">'toString') class=class="hl-string">"hl-comment"># Use the new assignee for this event
                    })
                
                class=class="hl-string">"hl-comment"># Activities based on status changes
                if item[class="hl-string">'field'].lower() == class="hl-string">'status':
                    to_status = item.get(class="hl-string">'toString')
                    if to_status in STATUS_ACTIVITY_MAP:
                        activity = STATUS_ACTIVITY_MAP[to_status]
                        event_log.append({
                            **common_attributes,
                            class="hl-string">'ActivityName': activity,
                            class="hl-string">'EventTime': created_time,
                            class="hl-string">'RequestStatus': to_status class=class="hl-string">"hl-comment"># Use the new status for this event
                        })

    return event_log

if __name__ == class="hl-string">"__main__":
    try:
        issues_data = fetch_jira_issues(JIRA_URL, JIRA_EMAIL, JIRA_API_TOKEN, jql_query)
        if issues_data:
            event_log_data = process_issues_to_event_log(issues_data)
            df = pd.DataFrame(event_log_data)

            class=class="hl-string">"hl-comment"># Reorder and format columns for final output
            column_order = [
                class="hl-string">'ServiceRequestId', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
                class="hl-string">'Assignee', class="hl-string">'RequestPriority', class="hl-string">'RequestStatus', class="hl-string">'RequestType', class="hl-string">'SlaDueDate'
            ]
            df = df[column_order]
            df[class="hl-string">'EventTime'] = pd.to_datetime(df[class="hl-string">'EventTime']).dt.strftime(class="hl-string">'%Y-%m-%d %H:%M:%S')

            output_filename = class="hl-string">'jira_event_log.csv'
            df.to_csv(output_filename, index=False)
            print(fclass="hl-string">"\nSuccessfully extracted {len(df)} events to {output_filename}")
        else:
            print(class="hl-string">"No issues found for the given JQL query.")

    except requests.exceptions.HTTPError as e:
        print(fclass="hl-string">"HTTP Error: {e.response.status_code} - {e.response.text}")
    except Exception as e:
        print(fclass="hl-string">"An unexpected error occurred: {e}")

Prêt à commencer ?

Utilisez ce modèle pour lancer votre démarche de Process Mining et obtenir des améliorations significatives dans la gestion de vos demandes de service. Commencez dès aujourd’hui à optimiser vos opérations.

Retour au guide d’amélioration Télécharger le modèle

Optimisez dès maintenant la gestion des demandes de service dans Jira

Atteignez 70 % d'automatisation et mettez fin aux traitements trop lents. Améliorez votre efficacité dès maintenant !

Démarrer l'essai gratuit

Aucune carte bancaire requise. La configuration ne prend que quelques minutes.

Votre modèle de données pour la gestion des demandes de service

Votre modèle de données pour la gestion des demandes de service

Attributs de la gestion des demandes de service

Activités de gestion des demandes de service

Guides d'extraction

Export CSV/XML intégré à Jira Service Management

Étapes

Configuration

a Exemple de requête config

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

Étapes

Configuration

a Exemple de requête sql

Extraction par script Python via l'API REST de Jira Cloud

Étapes

Configuration

a Exemple de requête python

Prêt à commencer ?

Optimisez dès maintenant la gestion des demandes de service dans Jira

Votre modèle de données pour la gestion des demandes de service

Votre modèle de données pour la gestion des demandes de service

Attributs de la gestion des demandes de service

Activités de gestion des demandes de service

Guides d'extraction

Export CSV/XML intégré à Jira Service Management

Étapes

Configuration

a Exemple de requête config

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

Étapes

Configuration

a Exemple de requête sql

Extraction par script Python via l'API REST de Jira Cloud

Étapes

Configuration

a Exemple de requête python

Prêt à commencer ?

Optimisez dès maintenant la gestion des demandes de service dans Jira

Nous attachons de l’importance à votre confidentialité