> Amélioration continue des processus > Modèle de données : Problèmes > Jira Service Management > Modèle de données

Votre modèle de données pour la gestion des problèmes

Jira Service Management

Attributs de gestion des problèmes(20) Activités de gestion des problèmes(14) Guides d’extraction(2)

Votre modèle de données pour la gestion des problèmes

Ce modèle vous guide dans l’analyse de vos flux de travail de gestion des services informatiques. Il recense les données essentielles et les étapes clés du processus dans Jira Service Management. Vous y trouverez les attributs et les activités nécessaires pour comprendre comment votre équipe traite les problèmes sous-jacents et en recherche les causes profondes. Suivez ces recommandations pour simplifier la collecte des données et obtenir des analyses concrètes grâce à vos initiatives de Process Mining.

Attributs recommandés pour une analyse approfondie
Étapes clés du processus à consigner dans votre journal d’événements
Conseils techniques pour l’extraction des données

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 problèmes

Voici les champs de données recommandés pour votre journal d’événements afin d’analyser l’ensemble du cycle de gestion des problèmes.

5 Obligatoire 5 Recommandé 10 Facultatif

	Nom	Description
	Activité ActivityName	Action précise ou changement de statut concernant l’enregistrement de problème.
Description Cet attribut indique le nom de l’événement ou de la transition d’état survenu au cours du cycle de gestion des problèmes. Exemples : « Problème consigné », « Statut passé à En cours d’investigation » ou « Cause profonde identifiée ». Il est indispensable pour cartographier le flux du processus et repérer l’ordre des étapes suivies pour résoudre un problème. Dans le Process Mining, ces activités constituent les nœuds de la carte du processus. Pourquoi est-ce important ? Définit les étapes de la carte du processus et permet d’analyser les variantes du processus. Où trouver ces données Journal des modifications Jira (historique) ou transitions de statut du ticket Exemples Enregistrement de problème crééInvestigation commencéeCause profonde identifiéeSolution de contournement mise à jourEnregistrement de problème clôturé
	Dernière mise à jour des données LastDataUpdate	Horodatage de l’extraction ou de la dernière actualisation des données.
Description Indique la date de la dernière synchronisation du jeu de données avec l’environnement Jira Service Management en production. Les analystes peuvent ainsi vérifier l’actualité des données. Cette information permet de confirmer que l’analyse reflète l’état le plus récent du processus et de repérer d’éventuels retards dans la mise à disposition des données. Pourquoi est-ce important ? Garantit l’actualité des données et aide à se fier aux résultats de l’analyse. Où trouver ces données Horodatage ETL Exemples 2023-11-01T12:00:00Z2023-11-02T00:00:00Z
	Enregistrement de problème ProblemKey	Identifiant unique attribué à l’enregistrement de problème dans Jira Service Management.
Description Cet attribut sert d’identifiant central du cas pour l’analyse de Process Mining. Il correspond à la clé unique, par exemple PM-1001, générée par Jira Service Management lors de la création d’un enregistrement de problème. Il permet de regrouper toutes les activités, les modifications de statut et les mises à jour associées dans une seule instance de processus de bout en bout. Son analyse permet de visualiser le cycle de vie complet d’un problème, de sa détection initiale à sa clôture, en passant par l’investigation. Pourquoi est-ce important ? C’est la clé indispensable pour reconstituer le flux du processus et suivre des enregistrements de problème précis. Où trouver ces données Table des tickets, champ « Key » ou « Issue Key » Exemples PM-1023PM-4099PRB-3321PM-5001
	Horodatage EventTimestamp	Date et heure exactes auxquelles l’activité a eu lieu.
Description Cet attribut consigne le moment précis où une activité s’est produite. Il sert à ordonner les événements chronologiquement et à calculer la durée entre les étapes. Des horodatages exacts sont indispensables au calcul des temps de cycle, par exemple entre « Problème consigné » et « Cause profonde identifiée », ainsi qu’à l’analyse du débit au fil du temps. Pourquoi est-ce important ? Permet de calculer tous les indicateurs clés de performance liés au temps et d’ordonner correctement les événements. Où trouver ces données Date de création dans le journal des modifications Jira ou date de création du ticket Exemples 2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:20:00Z
	Système source SourceSystem	Nom du système d’où proviennent les données.
Description Identifie le système logiciel depuis lequel les données du processus ont été extraites. Dans ce contexte, la valeur est toujours « Jira Service Management ». Cet attribut est particulièrement utile dans les environnements qui regroupent plusieurs systèmes, car il permet de distinguer les sources de données. Dans cette vue, il sert principalement d’identifiant statique pour retracer leur origine. Pourquoi est-ce important ? Précise l’origine des données, notamment lorsqu’elles sont regroupées avec d’autres données de gestion des services informatiques. Où trouver ces données Valeur codée en dur ou configuration système Exemples Jira Service ManagementJira CloudJSM-Prod
	Catégorie de cause racine RootCauseCategory	Classification de la cause sous-jacente du problème.
Description Classe la défaillance technique ou liée au processus à l’origine du problème, par exemple « Bug logiciel », « Erreur humaine » ou « Défaillance matérielle ». Il s’agit souvent d’un champ personnalisé dans Jira Service Management. Cet attribut alimente le Dashboard « Répartition des catégories de causes racines » et aide à décider où investir dans l’infrastructure ou la formation pour éviter que le problème ne se reproduise. Pourquoi est-ce important ? Essentiel pour repérer les problèmes systémiques et orienter les mesures de prévention. Où trouver ces données Champ personnalisé « Root Cause » ou « Root Cause Category » Exemples Bug logicielErreur de configurationProblème de capacitéProblème lié au fournisseur
	Groupe d’assistance affecté SupportGroup	Équipe ou groupe technique actuellement chargé d’examiner le problème.
Description Identifie l’équipe chargée de l’enregistrement du problème au moment de l’événement. Dans Jira Service Management, cette information correspond souvent au champ « Component » ou à un champ personnalisé tel que « Support Group ». Cet attribut est essentiel au Dashboard « Goulots d’étranglement lors des transferts entre groupes d’assistance » : il permet de visualiser les transferts de problèmes entre équipes et de repérer celles où ils restent le plus longtemps. Pourquoi est-ce important ? Essentiel pour analyser les processus par équipe et repérer les difficultés de coordination entre équipes. Où trouver ces données Champ de la demande « Component » ou champ personnalisé « Support Group » Exemples Administration des bases de donnéesExploitation réseauAssistance applicative de niveau 2
	Priorité Priority	Niveau de criticité attribué à l’enregistrement du problème.
Description Indique l’urgence et l’impact du problème, généralement selon une échelle allant de « Faible » à « Critique ». Ce champ permet de segmenter l’analyse et de vérifier que les problèmes prioritaires sont résolus dans les délais prévus par les SLA. L’analyse de cet attribut dans le Dashboard « Respect des SLA et tendances des objectifs » permet de vérifier si les risques critiques pour l’activité sont correctement traités en priorité. Pourquoi est-ce important ? Permet de segmenter les performances du processus selon la criticité pour l’activité. Où trouver ces données Champ de la demande « Priority » Exemples La plus élevéeÉlevéeMoyenneFaible
	Résumé du problème ProblemSummary	Brève description ou titre de l’enregistrement du problème.
Description Contient le résumé de l’enregistrement du problème. Bien qu’il s’agisse principalement d’un texte, il fournit aux analystes un contexte utile lorsqu’ils examinent des cas individuels dans l’outil de Process Mining. Il permet d’effectuer des recherches par mot-clé et d’analyser qualitativement les types de problèmes enregistrés. Pourquoi est-ce important ? Fournit un contexte lisible pour l’identifiant du cas. Où trouver ces données Champ de la demande « Summary » Exemples Délai d’attente dépassé pour la connexion à la base de données dans la région UEPic de latence du service de messagerieFile d’attente du traitement des commandes bloquée
	Utilisateur UserKey	Identifiant unique ou nom de l’utilisateur ayant effectué l’activité.
Description Indique l’identité de la personne ou du compte système responsable de l’activité concernée. Il peut s’agir de l’« Assignee » qui a mis à jour l’enregistrement ou de l’« Author » d’un changement de statut. Ces données servent à analyser l’utilisation des ressources, à repérer les goulots d’étranglement lors des transferts entre utilisateurs et à clarifier les responsabilités dans le processus de gestion des problèmes. Pourquoi est-ce important ? Essentiel pour analyser les transferts, la séparation des tâches et la charge de travail des ressources. Où trouver ces données Champ Jira « author » dans le journal des modifications ou champ « assignee » de la demande Exemples j.smithsystem_automationm.doe
	A été rouvert IsReopened	Indicateur signalant si le problème a été rouvert après sa clôture.
Description Indicateur booléen défini sur « vrai » si l’enregistrement du problème est passé de l’état fermé à l’état ouvert. Il permet d’analyser le « Taux de réouverture des problèmes ». Un taux élevé de réouverture peut révéler des problèmes de qualité des corrections définitives ou des procédures de vérification insuffisantes. Pourquoi est-ce important ? Indicateur de la qualité et de l’efficacité des corrections. Où trouver ces données Déduit des changements de statut Exemples truefalse
	Code de résolution ResolutionCode	Code indiquant comment le problème a été résolu.
Description Précise le résultat final de l’enregistrement du problème, par exemple « Corrigé », « Ne sera pas corrigé », « Doublon » ou « Impossible à reproduire ». Ce code permet de distinguer les problèmes résolus des problèmes clôturés pour des raisons administratives et de garantir l’exactitude des indicateurs clés de performance, comme le « Délai moyen avant l’identification de la cause racine ». Pourquoi est-ce important ? Permet de distinguer les corrections efficaces des clôtures administratives. Où trouver ces données Champ de la demande « Resolution » Exemples TerminéNe sera pas traitéDoublonImpossible à reproduire
	Date de création CreatedDate	Date de création de l’enregistrement du problème.
Description Horodatage de la première consignation du problème dans le système. L’horodatage de l’événement indique le moment de l’activité, tandis que cet attribut sert souvent à filtrer les données à un niveau général, par exemple pour afficher tous les problèmes créés au premier trimestre. Il sert de date de référence pour l’analyse de l’ancienneté. Pourquoi est-ce important ? Date de référence pour l’analyse de l’ancienneté et du volume des signalements. Où trouver ces données Champ de la demande « Created » Exemples 2023-01-012023-06-15
	Déclarant ReporterName	Utilisateur ayant initialement enregistré le problème.
Description Identifie la personne qui a créé l’enregistrement du problème. Il ne s’agit pas nécessairement de la personne à qui le problème est attribué. L’analyse des déclarants aide à comprendre où les problèmes sont détectés, par exemple par les agents du centre de services ou les administrateurs système. Cette information complète l’analyse de la détection proactive ou réactive. Pourquoi est-ce important ? Identifie l’origine du signalement du problème. Où trouver ces données Champ de la demande « Reporter » Exemples service_surveillanceresponsable_assistanceadministrateur_reseau
	Demande de changement liée LinkedChangeRequest	Identifiant de la demande de changement liée à ce problème.
Description Enregistre l’ID de la demande de changement (RFC) créée pour mettre en œuvre la correction définitive. Ce lien est essentiel au Dashboard « Délai de lancement des demandes de changement ». Il relie le processus de gestion des problèmes à celui de la gestion du changement et permet d’analyser les deux processus conjointement. Pourquoi est-ce important ? Relie l’investigation à la résolution dans le processus de gestion du changement. Où trouver ces données Liens de la demande dont le type est « is fixed by » ou équivalent Exemples CR-404CHG-1099CR-5512
	État de dépassement du SLA SlaBreachStatus	Indique si le délai prévu par le contrat de niveau de service a été dépassé pour le problème.
Description Champ booléen ou de statut indiquant si le délai de résolution a dépassé l’objectif convenu. Cette information est utilisée dans le Dashboard « Respect des SLA et tendances des objectifs ». Elle met en évidence les cas susceptibles d’exposer l’organisation à des risques de non-conformité ou à des pénalités. Pourquoi est-ce important ? Essentiel au suivi de la conformité et des performances. Où trouver ces données Logique du champ SLA de Jira Service Management Exemples RespectéDépasséEn pause
	Nombre d’incidents liés LinkedIncidentCount	Nombre d’incidents liés à cet enregistrement de problème.
Description Nombre de tickets d’incident associés à l’enregistrement du problème. Cet attribut quantifie l’impact du problème sur les utilisateurs. Il est utilisé dans l’indicateur clé de performance « Nombre d’incidents liés à un problème » pour donner la priorité aux problèmes qui génèrent le plus grand nombre de tickets d’assistance. Pourquoi est-ce important ? Quantifie l’impact sur l’activité en fonction du nombre d’incidents. Où trouver ces données Nombre de liens dans la table « issuelinks » dont le type est « Problem/Incident » Exemples 011550
	Revue après mise en œuvre réalisée ReviewStatus	Indique si une revue après mise en production (PIR) a été effectuée.
Description Indique si l’activité ou l’indicateur « Revue après mise en production » figure dans le cas. Cette information est essentielle au Dashboard « Conformité des revues après mise en production ». Elle permet de vérifier que l’organisation respecte ses exigences de gouvernance en matière d’amélioration continue. Pourquoi est-ce important ? Indicateur de conformité lié à l’apprentissage organisationnel. Où trouver ces données Champ personnalisé « PIR Status » ou présence de l’activité « PIR » Exemples TerminéEn attenteNon requis
	Solution de contournement disponible WorkaroundDetails	Indique si une solution de contournement a été documentée pour le problème.
Description Indique si une solution de contournement temporaire a été rédigée ou publiée. Cette information permet de suivre le « Délai de publication des solutions de contournement ». Son analyse aide à déterminer à quelle vitesse l’équipe peut rétablir la stabilité du service, avant même qu’une correction définitive soit trouvée. Pourquoi est-ce important ? Essentiel pour mesurer la rapidité de mise à disposition d’une solution provisoire pour l’activité. Où trouver ces données Champ personnalisé « Workaround » Exemples Redémarrer le serviceVider le cache du navigateurAucune solution indiquée
	Source de détection DetectionSource	Mode de détection du problème, par exemple de manière proactive ou réactive.
Description Indique l’origine de la détection du problème. Parmi les valeurs courantes : « Surveillance proactive », « Incident signalé au centre de services » ou « Notification du fournisseur ». Cet attribut est utilisé dans le Dashboard « Détection proactive ou réactive » pour mesurer la maturité du processus de gestion des problèmes. Pourquoi est-ce important ? Mesure la maturité du processus et l’efficacité des systèmes de surveillance. Où trouver ces données Champ personnalisé « Source » ou « Detection Source » Exemples Surveillance proactiveEscalade d’un incidentNotification du fournisseur

Obligatoire Recommandé Facultatif

Activités de gestion des problèmes

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

8 Recommandé 6 Facultatif

	Activité	Description
	Affecté à un groupe d’assistance	Affectation de l’enregistrement de problème à une équipe technique ou à un groupe d’assistance. Elle est suivie au moyen des modifications du champ personnalisé « Support Group » ou du champ « Assignee » si les groupes ne sont pas utilisés.
Pourquoi est-ce important ? Indispensable pour analyser les passages de relais et les goulots d’étranglement entre les équipes. Un taux élevé de transferts peut révéler des problèmes d’acheminement. Où trouver ces données Historique du ticket Jira : modification du champ « Support Group » ou « Assignee » Données à recueillir Enregistré lorsque le champ d’affectation est modifié Type d’événement explicit
	Cause profonde identifiée	Moment où la cause sous-jacente est officiellement consignée. Il est déduit du passage au statut « Root Cause Identified » ou du renseignement du champ « Root Cause ».
Pourquoi est-ce important ? Étape majeure qui marque la fin de l’investigation. Indispensable au calcul du « Délai moyen d’identification de la cause profonde ». Où trouver ces données Historique du ticket Jira : statut passé à « Root Cause Identified » OU champ « Root Cause » renseigné Données à recueillir Comparer le champ de statut ou vérifier si le champ est renseigné Type d’événement inferred
	Enregistrement de problème clôturé	Fin du cycle de vie du problème. Elle est explicitement enregistrée lorsque le statut passe à « Closed ».
Pourquoi est-ce important ? Fin définitive de l’instance du processus. Nécessaire au calcul du temps de cycle total et du taux de clôture. Où trouver ces données Historique du ticket Jira : statut passé à « Closed » Données à recueillir Enregistré lorsque le statut passe à Closed Type d’événement explicit
	Enregistrement de problème créé	Événement initial correspondant à la création du ticket de problème dans le système. L’historique du ticket enregistre explicitement l’horodatage de création.
Pourquoi est-ce important ? Marque le début du cycle de gestion des problèmes et permet d’analyser les volumes. Indispensable au calcul du débit et des taux de prise en charge. Où trouver ces données Table des tickets Jira : horodatage de la date de création ou onglet Historique : événement de création du ticket Données à recueillir Enregistré lors de la validation de la transaction de création du ticket Type d’événement explicit
	Incident associé au problème	Association d’un ticket d’incident lié à l’enregistrement de problème. Cette opération est consignée dans la table des liens entre tickets ou dans l’historique.
Pourquoi est-ce important ? Détermine l’impact et la portée du problème. Indispensable à l’indicateur clé de performance « Profondeur du lien entre incident et problème » et à la priorisation selon les répercussions sur l’activité. Où trouver ces données Liens entre tickets Jira : lien créé de type « causes » ou « relates to » Données à recueillir Enregistré lors de la création d’un lien entre tickets Type d’événement explicit
	Investigation commencée	Passage du statut du problème à un état d’investigation actif, par exemple « Under Investigation » ou « In Progress ». Cette étape marque le début du travail actif.
Pourquoi est-ce important ? Lance le calcul du temps de cycle de l’investigation. Permet de distinguer le temps d’attente dans le backlog du temps consacré à l’analyse. Où trouver ces données Historique du ticket Jira : statut passé à « Under Investigation » ou « In Progress » Données à recueillir Comparer les mises à jour du champ de statut Type d’événement inferred
	Résolution vérifiée	Confirmation que le correctif a bien résolu le problème. Elle est déduite du passage au statut « Resolved » ou à un état spécifique « Verified ».
Pourquoi est-ce important ? Point de contrôle qualité qui confirme le bon fonctionnement du correctif. Les retards à cette étape peuvent révéler des goulots d’étranglement dans les tests ou la validation par les utilisateurs. Où trouver ces données Historique du ticket Jira : statut passé à « Resolved » ou « Verified » Données à recueillir Comparer les mises à jour du champ de statut Type d’événement inferred
	Solution de contournement mise à jour	Renseignement ou mise à jour du champ texte « Workaround ». Cet événement indique qu’une solution temporaire a été documentée.
Pourquoi est-ce important ? Mesure le délai avant la mise en place d’une mesure de secours pour l’activité. Indispensable à l’indicateur clé de performance « Délai de mise à disposition d’une solution de contournement ». Où trouver ces données Historique du ticket Jira : champ « Workaround » modifié (valeur non nulle) Données à recueillir Enregistré lorsque le champ Workaround est modifié Type d’événement explicit
	Correctif définitif appliqué	Transition indiquant que la solution a été mise en œuvre. Elle est généralement déduite du passage au statut « Implementing » ou « Fixed ».
Pourquoi est-ce important ? Marque la fin des travaux de correction technique. Sert à mesurer le temps de cycle de mise en œuvre. Où trouver ces données Historique du ticket Jira : statut passé à « Implemented », « Pending Verification » ou « Fixed » Données à recueillir Comparer les mises à jour du champ de statut Type d’événement inferred
	Demande de changement associée	Association d’une demande de changement (RFC) à l’enregistrement de problème. Elle marque le lancement du processus de correction définitive.
Pourquoi est-ce important ? Mesure le délai entre l’identification de la cause et le début de la correction. Alimente l’indicateur clé de performance « Délai de transition vers la gestion du changement ». Où trouver ces données Liens entre tickets Jira : lien créé de type « is fixed by » ou association à un ticket de type « Change » Données à recueillir Enregistré lors de la création d’un lien vers un ticket de type Change Type d’événement explicit
	Priorité du problème modifiée	Modification du champ de priorité de l’enregistrement de problème. Elle est détectée en surveillant les changements apportés au champ « Priority » dans l’onglet Historique.
Pourquoi est-ce important ? Signale une escalade ou une désescalade du problème. L’analyse de ces changements aide à évaluer la précision du triage initial et l’ancienneté des problèmes hautement prioritaires dans le backlog. Où trouver ces données Historique du ticket Jira : champ « Priority » modifié, de l’ancienne valeur à la nouvelle valeur Données à recueillir Enregistré lors de la mise à jour du champ Priority Type d’événement explicit
	Problème rouvert	Passage d’un problème du statut « Resolved » ou « Closed » à un statut actif. Signale l’échec du correctif ou le rejet de la résolution.
Pourquoi est-ce important ? Indicateur clé de qualité. Un taux élevé de réouverture peut révéler une analyse des causes profondes ou des tests inefficaces. Où trouver ces données Historique du ticket Jira : statut passé de « Closed »/« Resolved » à « Open »/« In Progress » Données à recueillir Comparer la séquence des statuts Type d’événement inferred
	Revue après mise en œuvre	Réalisation d’une revue après l’application du correctif. Elle est enregistrée lors du passage au statut « In Review » ou de la mise à jour de champs propres à la revue après mise en œuvre (PIR).
Pourquoi est-ce important ? Activité de conformité qui garantit la consignation des enseignements tirés. Elle permet d’analyser la « Conformité des revues après mise en œuvre ». Où trouver ces données Historique du ticket Jira : statut passé à « In Review » OU champ « PIR Notes » mis à jour Données à recueillir Comparer le champ de statut ou les mises à jour des champs PIR Type d’événement inferred
	SLA dépassé	Événement indiquant que le délai de résolution du problème a dépassé l’accord de niveau de service défini. Il est calculé en comparant la date cible du SLA à la date de résolution.
Pourquoi est-ce important ? Indispensable aux rapports de conformité. Aide à repérer les priorités ou catégories qui dépassent le plus souvent les délais prévus. Où trouver ces données Journaux SLA de Jira Service Management : « Time to Resolution » > cible, ou valeur calculée Données à recueillir Déduire le dépassement des données du champ SLA ou comparer la date d’échéance à la date de résolution Type d’événement calculated

Recommandé Facultatif

Guides d’extraction

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

Étapes

Connectez-vous à votre instance Jira Service Management dans un navigateur Web avec un compte disposant des autorisations « Browse Projects » pour le projet Problem Management.
Dans la barre de menus supérieure, sélectionnez Filters, puis cliquez sur Advanced Issue Search pour ouvrir le navigateur de tickets.
Si ce n’est pas déjà fait, passez du mode de recherche Basic au mode JQL (Jira Query Language).
Saisissez la requête JQL indiquée dans la section Query ci-dessous pour isoler les enregistrements de problèmes (par exemple, project = 'Problem Management'). Vérifiez que la période sélectionnée respecte les limites d’exportation du système.
Cliquez sur Search pour vérifier que la liste de tickets contient les enregistrements de problèmes attendus.
Repérez le bouton Export dans le coin supérieur droit du navigateur de tickets.
Dans le menu déroulant, sélectionnez Export XML. Ne sélectionnez pas CSV : l’exportation CSV standard ne fournit que l’état actuel et ne contient pas l’historique des modifications nécessaire au Process Mining.
Enregistrez le fichier XML généré (par exemple, jira_export.xml) dans un répertoire local accessible depuis votre environnement de traitement.
Préparez l’environnement Python en installant la bibliothèque pandas si elle ne l’est pas déjà.
Exécutez le script Python fourni dans la section Query et vérifiez que la variable de chemin d’accès au fichier correspond à l’emplacement où vous avez enregistré le fichier XML.
Le script analyse la structure RSS/XML et extrait l’horodatage « Created », les entrées « History » relatives aux changements d’état, de priorité et d’affectation, ainsi que les « Issue Links » vers les incidents associés.
Le script calcule les dépassements de SLA en comparant les dates de résolution aux dates d’échéance, puis génère un journal d’événements CSV formaté, prêt à être importé dans ProcessMind.

Configuration

Format d’exportation : utilisez l’exportation XML (RSS), et non CSV. Le format XML contient les balises <history> et <issuelinks>, indispensables pour reconstituer le flux du processus.
Limite de lignes : les exportations standard de Jira sont souvent limitées à 1 000 tickets. Pour les jeux de données plus volumineux, répartissez l’extraction en ajustant la période JQL (par exemple, created >= '2023-01-01' AND created < '2023-02-01') et en effectuant plusieurs exportations.
Filtre JQL : vérifiez que la clé project correspond à l’identifiant de votre projet Problem Management (par exemple, PROB, PM).
Fuseau horaire du système : vérifiez que le profil utilisateur utilisé pour l’exportation correspond au fuseau horaire du système afin de garantir la cohérence des horodatages.
Autorisations sur les champs : l’utilisateur doit pouvoir consulter l’historique des modifications et les tickets associés pour récupérer les transitions et les liens vers les incidents.
Champs personnalisés : si « Root Cause » ou « Workaround » sont des champs personnalisés, vérifiez que la logique de correspondance des noms de champs dans le script correspond aux noms utilisés dans votre instance Jira.

Exemple de requête sql

import xml.etree.ElementTree as ET
import pandas as pd
from datetime import datetime
import io

# CONFIGURATION
# Path to the exported Jira XML file
INPUT_FILE = 'jira_export.xml'
OUTPUT_FILE = 'process_mining_event_log.csv'
SOURCE_SYSTEM = 'Jira Service Management'

# JQL USED FOR EXPORT (Reference Only)
# project = "Problem Management" AND created >= "2023-01-01" ORDER BY created DESC

def parse_jira_xml(xml_file):
    tree = ET.parse(xml_file)
    channel = tree.getroot().find('channel')
    
    events = []
    
    # Namespaces are usually not required for standard Jira RSS XML, 
    # but we handle standard tags directly.
    
    for item in channel.findall('item'):
        # 1. Extract Header Attributes
        problem_key = item.find('key').text
        summary = item.find('summary').text if item.find('summary') is not None else ''
        created_str = item.find('created').text
        resolution_date_node = item.find('resolutiondate')
        due_date_node = item.find('duedate')
        
        # Parse base timestamps
        # Jira XML format example: Wed, 4 Oct 2023 14:30:00 +0000
        fmt = '%a, %d %b %Y %H:%M:%S %z'
        created_dt = datetime.strptime(created_str, fmt)
        
        # --- ACTIVITY 1: Problem Record Created ---
        events.append({
            'ProblemKey': problem_key,
            'ActivityName': 'Problem Record Created',
            'EventTimestamp': created_dt,
            'UserKey': item.find('reporter').get('username') if item.find('reporter') is not None else None,
            'SourceSystem': SOURCE_SYSTEM,
            'ProblemSummary': summary,
            'Priority': item.find('priority').text if item.find('priority') is not None else None
        })

        # --- ACTIVITY: Incident Linked / Change Request Linked ---
        # Check <issuelinks> tag
        issue_links = item.find('issuelinks')
        if issue_links is not None:
            for linktype in issue_links.findall('issuelinktype'):
                link_name = linktype.find('name').text # e.g., 'Relates', 'Blocks', 'Caused'
                for outward in linktype.findall('outwardlinks'):
                    for issue_link in outward.findall('issuelink'):
                        linked_key = issue_link.find('issuekey').text
                        # Heuristic: Identify link type based on key pattern or link description
                        activity = None
                        if 'INC' in linked_key: # Customize for your Incident Prefix
                            activity = 'Incident Linked to Problem'
                        elif 'CHG' in linked_key: # Customize for your Change Prefix
                            activity = 'Change Request Linked'
                        
                        if activity:
                             events.append({
                                'ProblemKey': problem_key,
                                'ActivityName': activity,
                                'EventTimestamp': created_dt, # Link timestamp often not in XML, defaulting to created or requires API. fallback.
                                'UserKey': 'System',
                                'SourceSystem': SOURCE_SYSTEM,
                                'ProblemSummary': f'Linked to {linked_key}',
                                'Priority': None
                            })

        # --- PROCESS HISTORY (Status, Priority, Assignment, etc.) ---
        # Note: History is not always in standard RSS. 
        # If utilizing the 'SearchRequestView' XML, history is included inside <customfields> or specific expansion.
        # However, typically standard RSS does NOT include full history.
        # Assuming this XML export includes the Activity Stream or we rely on Custom Field dates for specific milestones.
        
        # LOGIC FOR INFERRING ACTIVITIES FROM CURRENT STATE & DATES (If History missing)
        # Or parsing <subtasks> or <comments> as proxies.
        
        # --- ACTIVITY: SLA Breached ---
        if resolution_date_node is not None and due_date_node is not None:
            res_date = datetime.strptime(resolution_date_node.text, fmt)
            due_date = datetime.strptime(due_date_node.text, fmt)
            
            if res_date > due_date:
                events.append({
                    'ProblemKey': problem_key,
                    'ActivityName': 'SLA Breached',
                    'EventTimestamp': res_date,
                    'UserKey': 'System',
                    'SourceSystem': SOURCE_SYSTEM,
                    'ProblemSummary': summary,
                    'Priority': None
                })

        # --- ACTIVITY: Problem Record Closed / Resolved ---
        if resolution_date_node is not None:
             events.append({
                'ProblemKey': problem_key,
                'ActivityName': 'Problem Record Closed',
                'EventTimestamp': datetime.strptime(resolution_date_node.text, fmt),
                'UserKey': item.find('assignee').get('username') if item.find('assignee') is not None else None,
                'SourceSystem': SOURCE_SYSTEM,
                'ProblemSummary': summary,
                'Priority': None
            })

        # --- MOCKING HISTORY PARSING IF XML HAS HISTORY PLUGIN EXTENSION ---
        # (Standard Jira RSS export is weak on history. 
        # This block assumes the existence of a custom history export or parsing comment logs for keywords).
        
        comments = item.find('comments')
        if comments:
            for comment in comments.findall('comment'):
                body = comment.text.lower()
                c_date = datetime.strptime(comment.get('created'), fmt)
                author = comment.get('author')
                
                act_name = None
                if 'root cause' in body:
                    act_name = 'Root Cause Identified'
                elif 'workaround' in body:
                    act_name = 'Workaround Updated'
                elif 'investigation' in body:
                    act_name = 'Investigation Started'
                
                if act_name:
                    events.append({
                        'ProblemKey': problem_key,
                        'ActivityName': act_name,
                        'EventTimestamp': c_date,
                        'UserKey': author,
                        'SourceSystem': SOURCE_SYSTEM,
                        'ProblemSummary': summary,
                        'Priority': None
                    })

    return pd.DataFrame(events)

# EXECUTION
try:
    df = parse_jira_xml(INPUT_FILE)
    
    # Add global extraction timestamp
    df['LastDataUpdate'] = datetime.now()
    
    # Formatting
    if not df.empty:
        df['EventTimestamp'] = pd.to_datetime(df['EventTimestamp']).dt.strftime('%Y-%m-%d %H:%M:%S')
        
        # Output
        df.to_csv(OUTPUT_FILE, index=False)
        print(f"Success: Extracted {len(df)} events to {OUTPUT_FILE}")
    else:
        print("No events found. Check XML format or JQL.")
        
except Exception as e:
    print(f"Error processing file: {str(e)}")

Étapes

Prérequis : vérifiez que Python 3.x est installé, ainsi que les bibliothèques requests et pandas. Vous aurez besoin d’un compte Jira Service Management disposant d’autorisations de lecture sur le projet concerné. Pour Jira Cloud, générez un jeton d’API dans les paramètres de votre compte Atlassian. Pour Data Center, générez un jeton d’accès personnel (PAT).
Repérez les identifiants des champs personnalisés : Jira Service Management attribue des identifiants dynamiques aux champs personnalisés (par exemple, customfield_10012 pour Support Group ou SLA). Avant de lancer l’extraction principale, utilisez un navigateur ou Postman pour interroger un enregistrement de problème précis (/rest/api/2/issue/[ISSUE-KEY]) et repérer les identifiants des champs « Support Group », « Workaround », « Root Cause » et des champs SLA.
Configurez le script : ouvrez le script Python fourni et mettez à jour le dictionnaire CONFIG. Remplacez l’URL, l’adresse e-mail de l’utilisateur et le jeton d’API. Mettez à jour le dictionnaire FIELD_MAPPING avec les noms ou les identifiants réels des champs personnalisés repérés à l’étape 2. Modifiez JQL_QUERY pour cibler votre projet (par exemple, project = PM AND issuetype = Problem).
Définissez les correspondances des états : dans le dictionnaire STATUS_MAPPING du script, associez les états de votre flux de travail Jira (par exemple, « Under Investigation », « Implementing », « Resolved ») aux noms d’activité standard de ProcessMind (par exemple, « Investigation Started », « Permanent Fix Applied »).
Lancez l’extraction : exécutez le script depuis un terminal ou un environnement de développement intégré. Le script utilise l’API de recherche Jira avec expand=changelog pour récupérer l’état actuel et l’historique complet des modifications de chaque champ.
Traitement des données : le script parcourt chaque ticket. Il crée d’abord un événement « Problem Record Created » à partir de l’horodatage de création, puis analyse l’historique des modifications. Pour chaque entrée, il vérifie si le champ modifié figure dans la liste des champs à suivre (Status, Priority, Link, etc.) et génère une ligne d’événement correspondante.
Gestion des SLA : le script tente de repérer les dépassements de SLA en recherchant les modifications des champs personnalisés liés aux SLA ou les transitions vers un état explicitement nommé « Breached ». Adaptez la logique de la fonction _parse_sla_breach si votre système utilise une automatisation spécifique pour signaler les dépassements.
Transformation des données : le script aplatit la structure JSON imbriquée dans un DataFrame Pandas tabulaire. Les horodatages sont convertis au format ISO 8601.
Exportation : le jeu de données final est exporté dans un fichier CSV nommé jira_problem_event_log.csv. Ouvrez ce fichier pour vérifier que les en-têtes de colonnes correspondent aux exigences de ProcessMind.
Importation dans ProcessMind : importez le fichier CSV dans ProcessMind. Associez ProblemKey à Case ID, ActivityName à Activity et EventTimestamp à Timestamp.

Configuration

Point de terminaison de l’API : utilise /rest/api/2/search, compatible avec Cloud et la plupart des versions de Data Center. L’API v3 est également prise en charge, mais la v2 offre généralement une meilleure compatibilité.
Pagination : le script utilise startAt et maxResults pour traiter efficacement les grands jeux de données par pages. La taille de lot par défaut est de 50.
Développement de l’historique des modifications : le paramètre expand=changelog est indispensable. Sans lui, seule l’état actuel est renvoyé et l’historique ainsi que le flux du processus sont perdus.
Filtrage JQL : la requête filtre les tickets avec issuetype = Problem. Il est fortement recommandé d’ajouter un filtre de dates (par exemple, created >= -180d) pour limiter le volume de données lors des premiers tests.
Authentification : l’authentification de base (adresse e-mail et jeton) est prise en charge pour Cloud. Pour Data Center, modifiez les en-têtes afin d’utiliser des jetons Bearer.
Correspondance des champs : une configuration précise est indispensable. Les noms internes des champs Jira « Status » et « Priority » sont standard, mais « Support Group », « Root Cause » et « SLA » sont presque toujours des champs personnalisés dotés d’identifiants uniques (par exemple, customfield_12345).

Exemple de requête python

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

class=class="hl-string">"hl-comment"># ==========================================
class=class="hl-string">"hl-comment"># CONFIGURATION
class=class="hl-string">"hl-comment"># ==========================================
CONFIG = {
    class="hl-string">"JIRA_URL": class="hl-string">"https://your-domain.atlassian.net",
    class="hl-string">"USER_EMAIL": class="hl-string">"your-email@example.com",
    class="hl-string">"API_TOKEN": class="hl-string">"your-api-token-or-pat",
    class="hl-string">"PROJECT_KEY": class="hl-string">"PM",  class=class="hl-string">"hl-comment"># Problem Management Project Key
    class="hl-string">"LOOKBACK_DAYS": class="hl-string">"180"
}

class=class="hl-string">"hl-comment"># Mappings: Key = Jira Field Name/ID, Value = Activity Name context
class=class="hl-string">"hl-comment"># You must replace class="hl-string">'customfield_XXXXX' with your actual field IDs found via API
FIELD_MAPPING = {
    class="hl-string">"priority": class="hl-string">"Problem Priority Changed",
    class="hl-string">"assignee": class="hl-string">"Assigned to Support Group", class=class="hl-string">"hl-comment"># Fallback if support group field unused
    class="hl-string">"customfield_10010": class="hl-string">"Assigned to Support Group", class=class="hl-string">"hl-comment"># Replace with Support Group Field ID
    class="hl-string">"customfield_10011": class="hl-string">"Workaround Updated",      class=class="hl-string">"hl-comment"># Replace with Workaround Field ID
    class="hl-string">"customfield_10012": class="hl-string">"Root Cause Identified",   class=class="hl-string">"hl-comment"># Replace with Root Cause Field ID
    class="hl-string">"Link": class="hl-string">"Link Event",                           class=class="hl-string">"hl-comment"># Internal name for issue links
    class="hl-string">"issuelinks": class="hl-string">"Link Event"
}

class=class="hl-string">"hl-comment"># Map Jira Workflow Statuses to Standard Activities
class=class="hl-string">"hl-comment"># Update the keys (left side) to match your actual Jira Status names
STATUS_MAPPING = {
    class="hl-string">"Under Investigation": class="hl-string">"Investigation Started",
    class="hl-string">"In Progress": class="hl-string">"Investigation Started",
    class="hl-string">"Root Cause Identified": class="hl-string">"Root Cause Identified",
    class="hl-string">"Implementing": class="hl-string">"Permanent Fix Applied",
    class="hl-string">"Fixed": class="hl-string">"Permanent Fix Applied",
    class="hl-string">"Resolved": class="hl-string">"Resolution Verified",
    class="hl-string">"Verified": class="hl-string">"Resolution Verified",
    class="hl-string">"In Review": class="hl-string">"Post Implementation Review",
    class="hl-string">"Closed": class="hl-string">"Problem Record Closed",
    class="hl-string">"Breached": class="hl-string">"SLA Breached" class=class="hl-string">"hl-comment"># Only if you have a specific status for this
}

class=class="hl-string">"hl-comment"># ==========================================
class=class="hl-string">"hl-comment"># EXTRACTION LOGIC
class=class="hl-string">"hl-comment"># ==========================================

def get_auth_header():
    class=class="hl-string">"hl-comment"># For Cloud (Basic Auth)
    creds = fclass="hl-string">"{CONFIG['USER_EMAIL']}:{CONFIG['API_TOKEN']}"
    encoded = base64.b64encode(creds.encode()).decode()
    return {class="hl-string">"Authorization": fclass="hl-string">"Basic {encoded}", class="hl-string">"Content-Type": class="hl-string">"application/json"}
    class=class="hl-string">"hl-comment"># For Data Center (PAT), uncomment below:
    class=class="hl-string">"hl-comment"># return {class="hl-string">"Authorization": fclass="hl-string">"Bearer {CONFIG['API_TOKEN']}", class="hl-string">"Content-Type": class="hl-string">"application/json"}

def fetch_issues():
    url = fclass="hl-string">"{CONFIG['JIRA_URL']}/rest/api/2/search"
    jql = fclass="hl-string">"project = {CONFIG['PROJECT_KEY']} AND issuetype = Problem AND created >= -{CONFIG['LOOKBACK_DAYS']}d"
    
    all_issues = []
    start_at = 0
    max_results = 50
    
    while True:
        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"
        }
        
        try:
            response = requests.get(url, headers=get_auth_header(), params=params)
            response.raise_for_status()
            data = response.json()
        except Exception as e:
            print(fclass="hl-string">"API Error: {e}")
            break
            
        issues = data.get(class="hl-string">"issues", [])
        if not issues:
            break
            
        all_issues.extend(issues)
        start_at += max_results
        print(fclass="hl-string">"Fetched {len(all_issues)} issues so far...")
        
    return all_issues

def parse_activity(issue):
    events = []
    
    class=class="hl-string">"hl-comment"># Basic Issue Data
    key = issue[class="hl-string">"key"]
    fields = issue[class="hl-string">"fields"]
    summary = fields.get(class="hl-string">"summary", class="hl-string">"")
    class=class="hl-string">"hl-comment"># Current values (for attributes)
    current_priority = fields.get(class="hl-string">"priority", {}).get(class="hl-string">"name", class="hl-string">"")
    current_assignee = fields.get(class="hl-string">"assignee", {}).get(class="hl-string">"displayName") if fields.get(class="hl-string">"assignee") else class="hl-string">"Unassigned"
    
    class=class="hl-string">"hl-comment"># 1. Problem Record Created
    created_time = fields[class="hl-string">"created"]
    events.append({
        class="hl-string">"ProblemKey": key,
        class="hl-string">"ActivityName": class="hl-string">"Problem Record Created",
        class="hl-string">"EventTimestamp": created_time,
        class="hl-string">"UserKey": fields.get(class="hl-string">"creator", {}).get(class="hl-string">"displayName", class="hl-string">"System"),
        class="hl-string">"SupportGroup": current_assignee,
        class="hl-string">"Priority": current_priority,
        class="hl-string">"ProblemSummary": summary,
        class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
    })

    class=class="hl-string">"hl-comment"># Process Changelog
    changelog = issue.get(class="hl-string">"changelog", {}).get(class="hl-string">"histories", [])
    
    for history in changelog:
        timestamp = history[class="hl-string">"created"]
        user = history.get(class="hl-string">"author", {}).get(class="hl-string">"displayName", class="hl-string">"Unknown")
        
        for item in history[class="hl-string">"items"]:
            field = item.get(class="hl-string">"field")
            field_id = item.get(class="hl-string">"fieldId", class="hl-string">"")
            from_str = item.get(class="hl-string">"fromString", class="hl-string">"")
            to_str = item.get(class="hl-string">"toString", class="hl-string">"")
            
            class=class="hl-string">"hl-comment"># 2, 5, 7, 9, 10, 11, 13, 14. Status Changes
            if field == class="hl-string">"status":
                activity = STATUS_MAPPING.get(to_str)
                
                class=class="hl-string">"hl-comment"># Handle Reopened logic explicitly
                if to_str in [class="hl-string">"Open", class="hl-string">"Reopened"] and from_str in [class="hl-string">"Resolved", class="hl-string">"Closed"]:
                    activity = class="hl-string">"Problem Reopened"
                
                if activity:
                    events.append({
                        class="hl-string">"ProblemKey": key,
                        class="hl-string">"ActivityName": activity,
                        class="hl-string">"EventTimestamp": timestamp,
                        class="hl-string">"UserKey": user,
                        class="hl-string">"SupportGroup": current_assignee,
                        class="hl-string">"Priority": current_priority,
                        class="hl-string">"ProblemSummary": summary,
                        class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                    })

            class=class="hl-string">"hl-comment"># 2. Priority Changed
            elif field == class="hl-string">"priority":
                events.append({
                    class="hl-string">"ProblemKey": key,
                    class="hl-string">"ActivityName": class="hl-string">"Problem Priority Changed",
                    class="hl-string">"EventTimestamp": timestamp,
                    class="hl-string">"UserKey": user,
                    class="hl-string">"SupportGroup": current_assignee,
                    class="hl-string">"Priority": to_str,
                    class="hl-string">"ProblemSummary": summary,
                    class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                })

            class=class="hl-string">"hl-comment"># 3. Assigned to Support Group (via custom field or Assignee)
            elif field_id == class="hl-string">"customfield_10010" or field == class="hl-string">"assignee":
                events.append({
                    class="hl-string">"ProblemKey": key,
                    class="hl-string">"ActivityName": class="hl-string">"Assigned to Support Group",
                    class="hl-string">"EventTimestamp": timestamp,
                    class="hl-string">"UserKey": user,
                    class="hl-string">"SupportGroup": to_str,
                    class="hl-string">"Priority": current_priority,
                    class="hl-string">"ProblemSummary": summary,
                    class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                })

            class=class="hl-string">"hl-comment"># 6. Workaround Updated
            elif field_id == class="hl-string">"customfield_10011":
                if to_str: class=class="hl-string">"hl-comment"># Only if value is added/changed to something
                    events.append({
                        class="hl-string">"ProblemKey": key,
                        class="hl-string">"ActivityName": class="hl-string">"Workaround Updated",
                        class="hl-string">"EventTimestamp": timestamp,
                        class="hl-string">"UserKey": user,
                        class="hl-string">"SupportGroup": current_assignee,
                        class="hl-string">"Priority": current_priority,
                        class="hl-string">"ProblemSummary": summary,
                        class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                    })

            class=class="hl-string">"hl-comment"># 7. Root Cause Identified (via Field Population)
            elif field_id == class="hl-string">"customfield_10012":
                if to_str:
                    events.append({
                        class="hl-string">"ProblemKey": key,
                        class="hl-string">"ActivityName": class="hl-string">"Root Cause Identified",
                        class="hl-string">"EventTimestamp": timestamp,
                        class="hl-string">"UserKey": user,
                        class="hl-string">"SupportGroup": current_assignee,
                        class="hl-string">"Priority": current_priority,
                        class="hl-string">"ProblemSummary": summary,
                        class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                    })

            class=class="hl-string">"hl-comment"># 4 & 8. Links (Incident Linked / Change Request Linked)
            elif field == class="hl-string">"Link":
                class=class="hl-string">"hl-comment"># This requires heuristic checking of the linked key or link type
                class=class="hl-string">"hl-comment"># Assuming standard keys: INC-xxxx for Incident, CHG-xxxx or CR-xxxx for Change
                if class="hl-string">"INC-" in to_str or class="hl-string">"Incident" in to_str:
                     events.append({
                        class="hl-string">"ProblemKey": key,
                        class="hl-string">"ActivityName": class="hl-string">"Incident Linked",
                        class="hl-string">"EventTimestamp": timestamp,
                        class="hl-string">"UserKey": user,
                        class="hl-string">"SupportGroup": current_assignee,
                        class="hl-string">"Priority": current_priority,
                        class="hl-string">"ProblemSummary": summary,
                        class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                    })
                elif class="hl-string">"CHG-" in to_str or class="hl-string">"CR-" in to_str or class="hl-string">"Change" in to_str:
                     events.append({
                        class="hl-string">"ProblemKey": key,
                        class="hl-string">"ActivityName": class="hl-string">"Change Request Linked",
                        class="hl-string">"EventTimestamp": timestamp,
                        class="hl-string">"UserKey": user,
                        class="hl-string">"SupportGroup": current_assignee,
                        class="hl-string">"Priority": current_priority,
                        class="hl-string">"ProblemSummary": summary,
                        class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                    })
            
            class=class="hl-string">"hl-comment"># 12. SLA Breached (Detection Logic)
            class=class="hl-string">"hl-comment"># Detection depends heavily on plugins. Common method: check for SLA status field change
            elif class="hl-string">"SLA" in field or class="hl-string">"Time to Resolution" in field:
                if class="hl-string">"breach" in to_str.lower() or class="hl-string">"fail" in to_str.lower():
                    events.append({
                        class="hl-string">"ProblemKey": key,
                        class="hl-string">"ActivityName": class="hl-string">"SLA Breached",
                        class="hl-string">"EventTimestamp": timestamp,
                        class="hl-string">"UserKey": user,
                        class="hl-string">"SupportGroup": current_assignee,
                        class="hl-string">"Priority": current_priority,
                        class="hl-string">"ProblemSummary": summary,
                        class="hl-string">"SourceSystem": class="hl-string">"Jira Service Management"
                    })

    return events

class=class="hl-string">"hl-comment"># ==========================================
class=class="hl-string">"hl-comment"># MAIN EXECUTION
class=class="hl-string">"hl-comment"># ==========================================
if __name__ == class="hl-string">"__main__":
    print(class="hl-string">"Starting extraction...")
    issues = fetch_issues()
    
    all_events = []
    for issue in issues:
        all_events.extend(parse_activity(issue))
        
    df = pd.DataFrame(all_events)
    
    class=class="hl-string">"hl-comment"># Add LastDataUpdate
    df[class="hl-string">"LastDataUpdate"] = datetime.now().isoformat()
    
    class=class="hl-string">"hl-comment"># Export
    filename = class="hl-string">"jira_problem_event_log.csv"
    df.to_csv(filename, index=False)
    print(fclass="hl-string">"Extraction complete. Saved {len(df)} rows to {filename}")

Prêt à commencer ?

Transformez dès aujourd’hui les données de gestion des problèmes en analyses concrètes. Téléchargez le guide ou contactez notre équipe d’assistance pour commencer votre parcours de Process Mining.

Retour au guide d’amélioration

Télécharger le modèle

Optimisez dès aujourd’hui votre processus de gestion des problèmes

Réduisez les temps de cycle de 30 % et stabilisez votre environnement informatique.

Démarrez l’essai gratuit

Aucune carte bancaire requise. Configuration en quelques minutes.

Votre modèle de données pour la gestion des problèmes

Votre modèle de données pour la gestion des problèmes

Attributs de gestion des problèmes

Activités de gestion des problèmes

Guides d’extraction

Export depuis le navigateur de tickets de Jira Service Management

Étapes

Configuration

Exemple de requête sql

Extraction avec Python via l’API REST Jira et l’historique des modifications

Étapes

Configuration

Exemple de requête python

Prêt à commencer ?

Optimisez dès aujourd’hui votre processus de gestion des problèmes

Votre modèle de données pour la gestion des problèmes

Votre modèle de données pour la gestion des problèmes

Attributs de gestion des problèmes

Activités de gestion des problèmes

Guides d’extraction

Export depuis le navigateur de tickets de Jira Service Management

Étapes

Configuration

Exemple de requête sql

Extraction avec Python via l’API REST Jira et l’historique des modifications

Étapes

Configuration

Exemple de requête python

Prêt à commencer ?

Optimisez dès aujourd’hui votre processus de gestion des problèmes

Prêt à commencer ?