> 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 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 vous 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ésente les principaux attributs à collecter, les activités à suivre et explique comment extraire ces informations de votre système. Utilisez cette ressource pour préparer vos données et mieux comprendre vos opérations.

Attributs recommandés pour une analyse complète
Activités clés à suivre pour découvrir vos processus
Guide 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 des demandes de service

Voici les champs de données recommandés à inclure dans votre journal d’événements pour analyser en détail 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 qui s’est produit au cours du cycle de vie de la demande de service.
Description Cet attribut décrit l’action ou le changement de statut qui s’est produit à un moment donné pour une demande de service. Exemples : « Demande créée », « Demande affectée », « Solution mise en œuvre » et « Demande clôturé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 visualiser les cartes de processus, de repérer les goulots d’étranglement et de détecter les écarts par rapport au flux de travail standard, autant d’éléments essentiels pour comprendre l’efficacité et la conformité du processus. Pourquoi est-ce important ? Cet attribut définit les étapes du processus. Il permet de visualiser la carte du processus et d’analyser les schémas du flux de travail ainsi que les écarts. Où trouver ces données Cet attribut est généralement déduit de l’historique des changements de statut d’un ticket Jira. Chaque entrée du journal des modifications du champ de statut correspond à une activité. Exemples Demande trié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 s’est produit.
Description L’heure de début, ou horodatage de l’événement, indique le moment exact où une activité a eu lieu. Elle fournit le contexte temporel nécessaire à toute analyse de Process Mining. Cet horodatage sert à ordonner les événements, à calculer les intervalles entre les activités et le temps de cycle total des cas, ainsi qu’à comparer les performances du processus aux objectifs temporels, comme les SLA. Sans horodatages exacts, il est impossible de comprendre le déroulement du processus, de repérer les retards ou de mesurer l’efficacité. Pourquoi est-ce important ? Cet horodatage est indispensable pour ordonner les événements, calculer les durées et les temps de cycle, et repérer les goulots d’étranglement du processus. Où trouver ces données Il s’agit de l’horodatage associé à chaque changement de statut dans le journal des modifications du ticket Jira. L’heure de création du ticket figure dans le champ « created ». Exemples 2023-10-26T10:00:00Z2023-10-26T10:15:32Z2023-10-27T14:20:05Z
	Identifiant de la demande de service ServiceRequestId	Identifiant unique de chaque demande de service, qui sert de clé principale pour tous les événements associés.
Description L’identifiant de la demande de service, souvent appelé clé du ticket dans Jira, distingue chaque demande soumise par un utilisateur ou un système. Il constitue le fil conducteur qui relie tous les événements, de l’enregistrement initial à la clôture, et permet d’analyser le parcours complet de chaque demande. En Process Mining, cet identifiant est indispensable pour relier les événements à un même cas. Il garantit que chaque activité, changement de statut et horodatage est associé à la demande correspondante, afin de reconstituer une instance de processus cohérente pour l’analyse. Pourquoi est-ce important ? Cet identifiant est la clé qui relie toutes les activités associées au sein d’un même processus de bout en bout et rend l’analyse du processus possible. Où trouver ces données Il s’agit du champ « key » d’un ticket dans Jira Service Management. Exemples SR-2023-001IT-45892HELP-105
	Dernière mise à jour des données LastDataUpdate	Horodatage indiquant la date de la dernière actualisation des données depuis le système source.
Description Cet attribut indique la date et l’heure de la dernière extraction des données depuis Jira Service Management. Il permet de savoir si les analyses, les Dashboards et les KPI reposent sur des données récentes. Pour prendre des décisions éclairées, il est essentiel de connaître la date des données utilisées. Cet horodatage aide à déterminer si les informations sont en temps réel ou correspondent à un instantané antérieur, ce qui influe sur la pertinence des conclusions. Pourquoi est-ce important ? Indique si les données sont à jour, afin que les analyses reposent sur des informations récentes. Où trouver ces données Il s’agit d’un champ de métadonnées généré et enregistré par l’outil ou le script d’extraction à 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 indique l’origine des données, ici Jira Service Management. Cette information peut sembler secondaire lorsque l’analyse porte sur une seule source, mais elle devient essentielle lorsque les données de processus proviennent de plusieurs systèmes. Elle permet de retracer la provenance des données et d’en vérifier la qualité. Elle sert également à filtrer et à comparer des processus qui couvrent plusieurs plateformes logicielles ou interagissent avec elles. Pourquoi est-ce important ? Indique l’origine des données, une information essentielle pour leur gouvernance et pour combiner des données de processus issues de plusieurs systèmes d’entreprise. Où trouver ces données Il s’agit généralement d’une valeur statique ajoutée lors de l’extraction et de la transformation des données pour en indiquer l’origine. Exemples Jira Service ManagementJiraSM
	Date d’échéance du SLA SlaDueDate	Date et heure limites 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 indique la date limite de résolution d’une demande. Elle dépend de la priorité et du type de demande, ainsi que des règles de SLA configurées dans Jira Service Management. Cet attribut est essentiel pour le Dashboard « Performance des SLA des demandes de service » et l’indicateur « Taux de respect des SLA ». En comparant le délai réel de résolution à cette é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 est-ce important ? Cette échéance sert de référence pour mesurer les performances. Elle permet de calculer le respect des SLA et aide à prioriser le travail. Où trouver ces données Les informations relatives aux SLA sont gérées dans Jira Service Management et accessibles via l’API. Elles sont souvent stockées 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 urgence et son incidence sur l’activité. Cette classification détermine l’ordre de traitement des demandes et définit souvent les délais de résolution visés ainsi que les SLA applicables. Dans l’analyse des processus, la priorité est un axe de segmentation important. Elle permet de comparer les temps de cycle et le respect des SLA selon le niveau de priorité, afin de vérifier que les demandes prioritaires sont traitées plus rapidement et dans les délais prévus. Cette analyse permet aussi d’évaluer l’efficacité du système de priorisation. Pourquoi est-ce important ? Permet de segmenter l’analyse pour vérifier que les demandes prioritaires sont traitées plus rapidement et respectent des niveaux de service plus stricts. Où trouver ces données Il correspond au champ « priority » d’un ticket 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, à mesure que celle-ci passe d’un agent ou d’une équipe à l’autre. Cet attribut est essentiel pour analyser la charge de travail, mesurer les performances et gérer les ressources. Il permet de filtrer le processus par agent, de comparer les délais de résolution et de repérer les besoins de formation ou les déséquilibres de charge susceptibles de créer des goulots d’étranglement. Pourquoi est-ce important ? Cet attribut est essentiel pour analyser la charge de travail des agents, mesurer les performances individuelles et comprendre la répartition des ressources. Où trouver ces données Il correspond au champ « assignee » d’un ticket Jira. Exemples Alice JohnsonBob WilliamsNon attribué
	Statut de la demande RequestStatus	Statut actuel de la demande de service au cours de son cycle de vie.
Description Cet attribut indique l’état actuel d’une demande de service, par exemple « Open », « In Progress », « Waiting for Customer » ou « Resolved ». Il donne un aperçu de l’avancement de la demande à un instant donné. Le journal des activités retrace le déroulement passé, tandis que le statut actuel permet d’analyser le travail en cours et de repérer les demandes bloquées. Par exemple, l’analyse peut porter sur les demandes restées anormalement longtemps au statut « Waiting for Vendor », ce qui met en évidence les dépendances externes et les retards. Pourquoi est-ce important ? Donne un aperçu de l’état actuel de chaque cas, pour analyser le travail en cours et repérer les demandes bloquées ou en attente depuis longtemps. Où trouver ces données Il s’agit du champ « status » d’un ticket Jira. Exemples OuvertEn coursEn attente du clientRésolu
	Type de demande RequestType	Catégorie de la demande de service, par exemple « Demande d’accès » ou « Problème matériel ».
Description Le type de demande classe les demandes de service selon leur nature. Il s’agit d’un axe d’analyse fondamental, car les différents types de demandes suivent souvent des processus de résolution, des SLA et des besoins en ressources distincts. En segmentant l’analyse par type de demande, les organisations peuvent adapter les améliorations à chaque flux de travail. Par exemple, le goulot d’étranglement d’une demande de réinitialisation de mot de passe sera très différent de celui d’une demande de mise à disposition d’un nouveau serveur. Cet attribut est essentiel pour créer des Dashboards pertinents, comme « Qualité de la résolution par catégorie ». Pourquoi est-ce important ? Cet attribut est essentiel pour comparer les processus, les charges de travail et les performances selon les catégories de demandes de service. Où trouver ces données Il correspond souvent au champ « issuetype » de Jira ou à un champ personnalisé « Request Type » dans Jira Service Management. Exemples Demander la création d’un compteDemander de l’aide informatiqueIntégrer un nouvel employé
	Canal Channel	Mode de soumission utilisé pour créer la demande de service, par exemple par e-mail, via le portail ou par API.
Description L’attribut Canal indique comment une demande de service est arrivée dans le système. Dans Jira Service Management, les canaux courants sont le portail client, l’e-mail ou la création directe par un agent. L’analyse du processus par canal aide à comprendre le comportement des utilisateurs et à améliorer 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. Cela peut indiquer qu’il faut améliorer les formulaires du portail ou les règles d’analyse des e-mails. Ces informations alimentent le Dashboard « Tendances du volume de demandes de service ». Pourquoi est-ce important ? Permet d’analyser si le canal de soumission influe sur les délais de résolution, la clarté des demandes ou l’efficacité globale du processus. Où trouver ces données Cette information est disponible dans Jira Service Management via le champ « Request channel type ». Elle peut nécessiter un accès spécifique à l’API ou être stockée dans un champ personnalisé. Exemples portaile-mailapi
	Déclarant Reporter	Utilisateur à l’origine de la création ou du signalement de 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. L’analyse de cet attribut permet de comprendre les tendances des demandes selon les utilisateurs, les services ou les segments de clientèle. Elle aide à 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 anticiper les problèmes et améliorer la formation des utilisateurs. Pourquoi est-ce important ? Identifie l’auteur de la demande et permet d’analyser le volume et le type des demandes par utilisateur, service ou client. Où trouver ces données Il correspond au champ « reporter » d’un ticket Jira. Exemples Charles DarwinMarie CurieIsaac Newton
	Demande rouverte IsReopened	Indicateur booléen précisant si une demande de service a été rouverte après sa résolution.
Description Cet attribut calculé prend la valeur vrai ou faux. Il prend la valeur vrai si le flux de travail d’une demande comprend l’activité « Demande rouverte ». Il est déduit de l’analyse de la séquence d’activités de chaque cas. Cet indicateur est essentiel au calcul du KPI « Taux de réouverture des demandes de service » et alimente le Dashboard « Volume de demandes de service rouvertes ». Un taux de réouverture élevé indique souvent une qualité de résolution insuffisante dès la première intervention, ce qui entraîne des reprises et une baisse de la satisfaction client. L’analyse des types de demandes ou des résolutions associés à cet indicateur permet de repérer les points à améliorer. Pourquoi est-ce important ? Mesure directement les reprises et la qualité de résolution dès la première intervention, deux indicateurs importants de l’efficacité du processus et de la satisfaction client. Où trouver ces données Calculé lors de la transformation des données en vérifiant si la séquence d’activités d’un cas comprend un changement vers « Reopened » après un passage à « Resolved ». Exemples truefalse
	Équipe affectée AssignedTeam	Équipe ou groupe chargé du traitement de la demande de service.
Description Cet attribut indique l’équipe affectée à une demande. Il correspond souvent à un niveau de regroupement supérieur à celui du responsable individuel. Il permet d’analyser les performances par équipe, par exemple en comparant l’équipe d’assistance de premier niveau à l’équipe des opérations réseau. Cette dimension est utile pour des Dashboards comme « Charge de travail des agents et indicateurs de résolution ». Elle permet d’agréger les indicateurs de performance par équipe, de comparer les résultats équitablement et de comprendre la contribution de chaque équipe à la prestation globale des services. Pourquoi est-ce important ? Permet d’analyser les performances et de répartir la charge de travail par équipe ou par service, plutôt que par agent uniquement. Où trouver ces données Il peut s’agir d’un champ personnalisé dans Jira, par exemple « Team », ou d’une valeur déduite des attributs du profil utilisateur du responsable. Exemples Assistance informatique, niveau 1Équipe infrastructureAssistance applicative
	É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 prévu.
Description L’état du SLA est un attribut calculé qui classe chaque demande de service selon le respect de son échéance. Les valeurs possibles comprennent « Respecté », « Dépassé » ou « En cours ». Il est déterminé en comparant l’horodatage de résolution à « SlaDueDate ». Cet attribut est au cœur du Dashboard « Performance des SLA des demandes de service » et sert au calcul du KPI « Taux de respect des SLA ». Il donne une vue immédiate et claire du respect des niveaux de service, essentielle au reporting, à la gestion des contrats et au maintien de la qualité de service. Pourquoi est-ce important ? Indique clairement et immédiatement la performance des SLA, un indicateur important de la qualité de service et du respect des engagements contractuels. Où trouver ces données Calculé lors de la transformation des données. Si le délai de résolution est antérieur à « SlaDueDate », l’état est « Respecté » ; sinon, il est « Dépassé ». Exemples RespectéDépasséEn 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 propose 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 apporte un contexte métier utile. Elle peut aider à déterminer quels clients ou services mobilisent le plus de ressources d’assistance, si certains groupes rencontrent régulièrement les mêmes problèmes et si les SLA sont respectés de manière constante dans les différentes unités opérationnelles. Pourquoi est-ce important ? Permet d’analyser la demande de services et les performances par client ou service interne, et apporte un éclairage utile sur l’activité. Où trouver ces données 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 de résolution indique pourquoi une demande de service a été clôturée. Les valeurs courantes comprennent « Done », « Won’t Do », « Duplicate » ou « Cannot Reproduce ». Il apporte des précisions sur la clôture, au-delà du simple statut « 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 révéler un problème dans le processus de soumission des demandes. Le suivi des résolutions qui entraînent la réouverture de demandes peut également mettre en évidence des solutions inefficaces. Pourquoi est-ce important ? Précise le résultat d’une demande et aide à évaluer la qualité des résolutions ainsi qu’à repérer les tendances expliquant la clôture des demandes. Où trouver ces données Il correspond au champ « resolution » d’un ticket Jira, généralement renseigné lorsque le ticket passe à un statut de la catégorie « done ». Exemples TerminéNe sera pas traitéDoublonCorrigé

Obligatoire Recommandé Facultatif

Activités de gestion des demandes de service

Voici les principales étapes et les jalons à consigner dans votre journal d’événements pour découvrir et optimiser vos processus avec précision.

5 Recommandé 8 Facultatif

	Activité	Description
	Demande attribuée	Cette activité a lieu lorsqu’une demande de service est attribuée à un agent ou à une équipe pour résolution. Jira suit explicitement les changements du champ « Assignee » et indique ainsi clairement l’horodatage de l’attribution.
Pourquoi est-ce important ? Cette étape clé permet de mesurer le délai entre le triage et l’attribution, ainsi que la répartition de la charge de travail entre les agents. Elle marque le passage de la mise en file d’attente au traitement actif. Où trouver ces données Repérez dans l’historique de la demande la première fois où le champ « Assignee » est renseigné ou modifié après avoir été vide. Données à recueillir Utilisez l’horodatage du premier changement du champ « Assignee » dans l’historique de la demande. Type d’événement explicit
	Demande de service clôturée	Correspond à la clôture administrative définitive de la demande de service, qui intervient souvent automatiquement après une période définie à l’état « Resolved ». C’est le point final du cycle de vie du ticket dans Jira.
Pourquoi est-ce important ? Il s’agit de l’événement de fin définitif du processus. L’intervalle entre « Resolved » et « Closed » permet d’analyser la charge administrative ou les règles de clôture automatique. Où trouver ces données Déduit de l’historique du ticket. L’horodatage correspond au dernier changement de statut vers « Closed » ou vers un statut final équivalent. Données à recueillir Repérer l’horodatage du dernier changement vers un statut « 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 la soumet officiellement par l’intermédiaire d’un portail, par e-mail ou par un autre canal. Dans Jira, cet événement est enregistré explicitement à la création d’une nouvelle demande de type « Service Request », avec son horodatage.
Pourquoi est-ce 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 leur rythme d’arrivée. Où trouver ces données Cet événement est enregistré explicitement dans la table d’historique des demandes. L’horodatage de l’activité correspond au champ « created » de la demande Jira. Données à recueillir Utilisez l’horodatage de création de la demande dans la table « issues » ou dans l’historique. Type d’événement explicit
	Demande de service résolue	Indique le moment précis où la demande est considérée comme satisfaite et où la solution est consignée. Jira renseigne le champ « Resolution Date » lorsqu’un ticket passe pour la première fois à un statut de la catégorie « Done ».
Pourquoi est-ce important ? Il s’agit d’une étape finale majeure du processus, essentielle au calcul du délai de résolution et au suivi du respect des SLA. Elle marque la fin du travail actif. Où trouver ces données Il s’agit d’un événement explicite. L’horodatage correspond à la valeur du champ « Resolution Date » du ticket Jira, renseigné lors du premier passage à un statut de la catégorie « Done ». Données à recueillir Utilisez le champ « resolutiondate » du ticket 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, cette étape distincte consiste à soumettre une solution au demandeur pour approbation. Elle est déduite du passage de la demande à un statut comme « Pending Customer Acceptance » ou « Awaiting Confirmation ».
Pourquoi est-ce important ? Cette activité permet d’isoler le temps d’attente des commentaires du client après la présentation d’une solution et de le distinguer du temps de travail interne. Où trouver ces données Déduisez cette activité de l’historique de la demande. Son horodatage correspond au moment où le statut indique que la solution attend la validation du client. Données à recueillir Repérez l’horodatage du changement de statut vers « Pending Customer Acceptance » ou un statut équivalent. Type d’événement inferred
	Demande rouverte	Cette activité enregistre les cas où une demande de service précédemment résolue repasse à un statut actif. Elle est déduite d’un changement de statut, d’un statut résolu ou fermé vers un statut ouvert ou en cours.
Pourquoi est-ce 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 de réouverture élevé indique des solutions inefficaces ou des problèmes récurrents. Où trouver ces données Déduisez cette activité de l’historique de la demande en repérant le passage d’un statut de la catégorie « Resolved » ou « Closed » à un statut de la catégorie « Open » ou « In Progress ». Données à recueillir Repérez le passage d’un statut de la catégorie « Done » à un statut de la catégorie « To Do » ou « In Progress ». Type d’événement inferred
	Demande triée	Cette activité correspond à l’évaluation initiale d’une demande de service, au cours de laquelle sa priorité, sa catégorie et son incidence sont déterminées. Elle est généralement déduite d’un changement de statut, par exemple de « New » à « In Progress », ou du passage à un statut dédié « Triaged ».
Pourquoi est-ce important ? L’analyse du délai de triage permet d’évaluer l’efficacité du traitement initial des demandes. Les retards à cette étape peuvent allonger considérablement les délais de résolution et compromettre le respect des SLA. Où trouver ces données Déduisez cette activité de l’historique de la demande en repérant le premier horodatage où le statut passe de « New » ou « Open » à un statut actif, comme « In Progress ». Données à recueillir Repérez le premier changement de statut depuis « New » ou un statut initial équivalent, selon le flux de travail du projet. 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 la demande à un statut comme « Waiting for customer » ou « Pending Input ».
Pourquoi est-ce important ? Des cycles fréquents ou longs de demande d’informations peuvent révéler que les demandes initiales manquent de clarté ou que la communication est inefficace. Ils constituent une source importante de retards. Où trouver ces données Déduisez cette activité de l’historique de la demande. L’horodatage correspond au moment où le statut passe à « Waiting for customer » ou à un statut équivalent. Données à recueillir Repérez l’horodatage auquel le champ « status » prend une valeur indiquant que le processus est en attente d’une réponse du client. Type d’événement inferred
	Informations fournies	Cette activité a lieu lorsque le demandeur fournit les informations nécessaires et que l’agent peut reprendre le traitement. Elle est déduite du passage de la demande hors du statut « Waiting for customer », souvent après l’ajout d’un commentaire par le demandeur.
Pourquoi est-ce important ? Cette activité clôt la boucle de demande et de réponse avec le client. Le délai entre la demande d’informations et leur réception constitue une part importante du temps d’attente du processus. Où trouver ces données Déduisez cette activité de l’historique de la demande. L’horodatage correspond au moment où le statut passe de « Waiting for customer » à « In Progress ». Données à recueillir Repérez l’horodatage auquel le champ « status » passe d’un statut d’attente à un statut actif. Type d’événement inferred
	Intervention du prestataire commencée	Cette activité indique que la demande de service a été transmise à un prestataire externe ou qu’elle nécessite son intervention. Elle est déduite du passage de la demande à un statut comme « Waiting for vendor » ou « With Third Party ».
Pourquoi est-ce important ? Le suivi de l’intervention des prestataires est essentiel pour repérer les dépendances externes et les retards qui échappent au contrôle direct du centre de services interne. Où trouver ces données Déduisez cette activité de l’historique de la demande. L’horodatage correspond au moment où le statut passe à un statut désigné comme « vendor ». Données à recueillir Repérez l’horodatage auquel le champ « status » prend une valeur comme « Waiting for Vendor ». Type d’événement inferred
	Intervention du prestataire terminée	Cette activité correspond au moment où le prestataire externe a terminé son intervention et où la demande de service revient à l’équipe interne. Elle est déduite du passage de la demande hors du statut « Waiting for vendor ».
Pourquoi est-ce important ? Mesurer la durée de l’intervention des prestataires aide à évaluer leurs performances et à comprendre l’incidence des intervenants externes sur les délais de résolution globaux. Où trouver ces données Déduisez cette activité de l’historique de la demande. L’horodatage correspond au moment où le statut passe d’un statut « vendor » à « In Progress ». Données à recueillir Repérez l’horodatage auquel le champ « status » passe d’un statut « vendor » à un statut actif. Type d’événement inferred
	Résolution confirmée	Cette activité a lieu lorsque le demandeur accepte officiellement la solution proposée, ce qui déclenche souvent le passage automatique au statut « Resolved ». Elle est généralement déduite de ce changement de statut.
Pourquoi est-ce important ? Cette étape confirme l’efficacité de la solution et déclenche l’arrêt du décompte du SLA. Elle permet de mesurer le temps que mettent les clients à confirmer la résolution. Où trouver ces données Déduisez cette activité de l’historique de la demande. L’horodatage correspond au passage du statut de « Pending Customer Acceptance » à « Resolved » ou « Closed ». Données à recueillir Repérer l’horodatage du changement de statut de « Pending Customer Acceptance » à 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 répondre à la demande de service. Elle est souvent déduite d’un changement de statut vers « Pending Review » ou directement vers « Resolved ».
Pourquoi est-ce important ? Cette étape marque la fin du travail principal de résolution. Le temps écoulé jusqu’à cette activité correspond souvent à la partie du processus qui apporte le plus de valeur. Où trouver ces données Déduisez cette activité de l’historique de la demande. Son horodatage correspond au changement de statut vers « Resolved », « Pending Acceptance » ou un statut similaire précédant la clôture. Données à recueillir Repérez 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 extraire vos données de 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 (Jira Query Language) fournie dans la section Requête afin de filtrer les demandes de service à analyser. Modifiez la clé du projet et la période au besoin.
Cliquez sur le bouton Rechercher pour lancer la requête. Vérifiez la liste des demandes obtenues afin de confirmer qu’il s’agit du bon jeu de données.
Dans le coin supérieur droit de la page des résultats, cliquez sur l’icône Exporter (souvent représentée par une boîte avec une flèche vers l’extérieur).
Dans le menu déroulant, sélectionnez XML. Il est essentiel d’utiliser XML, 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 ordinateur. Il contient toutes les demandes de votre requête, avec leur historique complet des modifications intégré aux données de 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 du fichier et créer un événement « Demande de service créée » à partir de l’horodatage de création. Il doit ensuite analyser l’historique des modifications de chaque demande et repérer les changements des champs « status » et « assignee » correspondant aux activités requises. Une nouvelle ligne doit être créée pour chaque changement repéré.
Le script doit convertir 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 l’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 fortement recommandé de limiter l’export à une période précise afin d’en maîtriser la taille. 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. 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 : la personne qui effectue l’export doit disposer de l’autorisation « Parcourir les projets » pour le projet Jira concerné afin de consulter et d’exporter les demandes.
Volume de données : l’interface d’export Jira est souvent limitée à 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.

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 : procurez-vous des identifiants en lecture seule et les informations de connexion (nom d’hôte, port, nom de la base de données) de la base SQL utilisée par l’instance Jira. Vous devrez généralement demander l’aide d’un administrateur de base de données ou de votre service informatique.
Repérer 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. Repérez les tables principales : jiraissue (données de base des demandes), changegroup (historique des modifications), changeitem (détail de chaque modification), project (détails des projets), issuetype et priority.
Trouver les identifiants des champs personnalisés : des attributs comme RequestType et SlaDueDate sont souvent des champs personnalisés. Recherchez leurs identifiants dans la table customfield à l’aide de la requête suivante : 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 entre crochets par les valeurs réelles de votre configuration Jira, notamment les clés de projet, les noms de types de demande, les noms de statuts et les identifiants des champs personnalisés.
Définir la période : dans la partie initiale issue_base de la requête, repérez la clause WHERE i.created >= '[YYYY-MM-DD]'. Modifiez la date pour définir la période d’extraction des données.
Exécuter la requête : lancez le script SQL modifié. La requête est conçue pour fonctionner avec les bases de données SQL courantes, comme PostgreSQL, SQL Server et MySQL. Son exécution peut prendre plusieurs minutes sur les grandes instances Jira.
Vérifier les résultats : une fois la requête terminée, vérifiez rapidement que des lignes sont renvoyées et que les colonnes telles que ServiceRequestId, ActivityName et EventTime contiennent les valeurs attendues.
Exporter les données : exportez l’ensemble des résultats de votre client SQL dans 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 de colonnes correspondent exactement aux noms d’attributs requis, par exemple ServiceRequestId, ActivityName et EventTime. Enregistrez le fichier en UTF-8 pour qu’il soit compatible avec ProcessMind.

Configuration

Prérequis : vous devez disposer d’un accès direct en lecture seule à la base de données de production ou à la réplique Jira. Un accès standard à l’application ne suffit pas. Vous devez également bien connaître le flux de travail propre à votre projet Service Desk, notamment les noms exacts des statuts, des types de demande et des champs personnalisés.
Filtres principaux de la requête : configurez la requête 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]' : cette clause garantit que seules les demandes de service sont extraites, et non les incidents, les problèmes ou d’autres types de demande.
- 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é de couvrir 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. Remplacez 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.
Performances : l’exécution directe de cette requête sur une grande base de données Jira active peut consommer beaucoup de ressources et nuire aux performances de l’application pour les utilisateurs. Il est fortement recommandé d’effectuer l’extraction sur une base de données réplique en lecture seule ou en dehors des heures de pointe.

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.
Créer un jeton API Jira : connectez-vous à votre compte Jira Cloud. Ouvrez les paramètres de votre profil, sélectionnez « Paramètres du compte », puis l’onglet « Sécurité » et créez un jeton API. Copiez ce jeton et conservez-le en lieu sûr, car il servira à l’authentification.
Trouver 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 à « Paramètres » > « Demandes » > « Champs personnalisés ». Recherchez le champ voulu, cliquez sur les trois points « ... », puis sur « Afficher les informations du champ ». L’identifiant figure dans l’URL, par exemple customFieldId=10021. Notez ces identifiants pour configurer le script.
Configurer le script Python : ouvrez le script Python fourni dans un éditeur de texte. Renseignez les variables de configuration en haut du fichier, notamment JIRA_URL, JIRA_EMAIL, JIRA_API_TOKEN, la requête jql_query pour sélectionner vos demandes de service et les CUSTOM_FIELD_IDS repérés à l’étape précédente.
Associer les statuts Jira aux activités : examinez attentivement le dictionnaire STATUS_ACTIVITY_MAP du script. Mettez-le à jour pour qu’il corresponde au flux de travail Jira Service Management de votre organisation. Les clés doivent reprendre exactement les noms de vos statuts Jira, par exemple « Waiting for customer », et les valeurs doivent correspondre aux noms d’activité requis dans le journal d’événements, par exemple « Informations demandées ».
Lancer le script d’extraction : ouvrez un terminal ou une invite de commandes, accédez au répertoire où vous avez enregistré le script, puis exécutez la commande python jira_extraction_script.py. Le script se connecte à l’API Jira, récupère les données des demandes, les traite et affiche la progression dans la console.
Vérifier le fichier de sortie : à la fin de l’exécution, un fichier CSV nommé jira_event_log.csv est créé dans le même répertoire. Ouvrez-le dans un tableur pour vérifier son contenu. Assurez-vous que toutes les colonnes sont présentes et renseignées comme prévu.
Préparer l’importation dans ProcessMind : vérifiez que les en-têtes du fichier CSV correspondent exactement aux noms requis : ServiceRequestId, ActivityName, EventTime, SourceSystem, LastDataUpdate, Assignee, RequestPriority, RequestStatus, RequestType et SlaDueDate. Le fichier est alors 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 API personnel pour sécuriser l’accès.
Requête JQL (jql_query) : il s’agit du filtre principal de l’extraction. Définissez une requête JQL précise pour sélectionner les bonnes demandes. Nous vous recommandons de filtrer par project, issuetype et période à 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 permet de convertir correctement les changements de statut Jira en activités de processus pertinentes. Personnalisez-le en fonction du 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 comme « Request Type » ou « SLA Due Date », vous devez fournir leurs identifiants système uniques, par exemple customfield_10021. Configurez-les correctement pour que les attributs soient renseignés.
Période et performances : pour les premières extractions, il est recommandé de limiter la requête JQL à une période de 3 à 6 mois afin de préserver des performances acceptables. L’extraction de plusieurs années de données peut être lente en raison de la pagination de l’API et des limites de fréquence.

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 améliorer sensiblement 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 longs délais de traitement. Améliorez votre efficacité dès maintenant !

Démarrez votre 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 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

Exemple de requête config

Requête directe dans 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 Cloud

Étapes

Configuration

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 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

Exemple de requête config

Requête directe dans 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 Cloud

Étapes

Configuration

Exemple de requête python

Prêt à commencer ?

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

Prêt à commencer ?