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

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

Jira Service Management

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

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

Ce modèle constitue une feuille de route complète pour analyser vos flux de travail de gestion des services informatiques. Il identifie les points de données essentiels et les étapes clés du processus dans Jira Service Management. Vous y trouverez une vue structurée des attributs et des activités nécessaires pour comprendre précisément comment votre équipe traite les problèmes sous-jacents et analyse leurs causes profondes. Utilisez ces recommandations pour simplifier la collecte de vos données et garantir que vos initiatives de Process Mining produisent des analyses concrètes.

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

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

Télécharger le modèle

Attributs de la gestion des problèmes

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

5 Obligatoire 5 Recommandé 10 Facultatif

	Nom	Description
	Activité ActivityName	Action précise ou changement de statut intervenu pour l’enregistrement de problème.
Description Cet attribut enregistre le nom de l’événement ou de la transition d’état intervenant au cours du cycle de vie de la Gestion des problèmes. Exemples : « Problem Logged », « Status Changed to Investigating » ou « Root Cause Identified ». Il est indispensable pour cartographier le flux du processus et identifier la séquence 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 c’est important Définit les étapes de la carte du processus et permet d’analyser les variantes du processus. Où les obtenir Jira Changelog (History) 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 fermé
	Dernière mise à jour des données LastDataUpdate	Horodatage de l’extraction des données ou de leur dernière actualisation.
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 connaître l’actualité des données. Il sert à vérifier que l’analyse reflète l’état le plus récent du processus et à repérer d’éventuels problèmes de latence des données. Pourquoi c’est important Garantit l’actualité des données et contribue à la fiabilité des résultats de l’analyse. Où les obtenir 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 représente la clé unique, par exemple PM-1001, générée par Jira Service Management lors de la création d’un nouvel enregistrement de problème. Il sert à regrouper toutes les activités, les modifications de statut et les mises à jour associées au sein d’une même instance de processus de bout en bout. L’analyse de cet attribut permet de visualiser l’intégralité du cycle de vie d’un problème, de sa détection initiale à sa clôture définitive, en passant par l’investigation. Pourquoi c’est important Il s’agit de la clé fondamentale nécessaire pour reconstituer le flux du processus et suivre des enregistrements de problèmes précis. Où les obtenir Table des tickets, champ « Key » ou « Issue Key » Exemples PM-1023PM-4099PRB-3321PM-5001
	Horodatage EventTimestamp	Date et heure exactes auxquelles l’activité s’est produite.
Description Cet attribut enregistre le moment précis où une activité a eu lieu. Il sert à ordonner les événements chronologiquement et à calculer les durées entre les étapes. Des horodatages précis sont indispensables pour calculer les temps de cycle, par exemple le délai entre « Problem Logged » et « Root Cause Identified », ainsi que pour analyser le débit au fil du temps. Pourquoi c’est important Permet de calculer tous les KPI fondés sur le temps et d’ordonner correctement les événements. Où les obtenir Date de création du Jira Changelog 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 à l’origine des 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 multisystèmes pour distinguer les sources de données. Dans cette vue précise, il sert principalement d’identifiant statique pour assurer la traçabilité des données. Pourquoi c’est important Fournit le contexte sur l’origine des données, notamment lors de leur rapprochement avec d’autres données d’IT Service Management. Où les obtenir 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 Catégorise la défaillance technique ou du processus à l’origine du problème, par exemple « Software Bug », « Human Error » ou « Hardware Failure ». Il s’agit souvent d’un champ personnalisé dans Jira Service Management. Cet attribut alimente le Dashboard « Root Cause Category Distribution » et aide à prendre des décisions stratégiques sur les investissements à consacrer aux infrastructures ou à la formation pour éviter la récurrence du problème. Pourquoi c’est important Essentiel pour identifier les problèmes systémiques et orienter les mesures préventives. Où les obtenir Champ personnalisé « Root Cause » ou « Root Cause Category » Exemples Bug logicielErreur de configurationProblème de capacitéProblème lié au fournisseur
	Groupe de Support assigné SupportGroup	Équipe ou groupe technique actuellement chargé d’examiner le problème.
Description Identifie l’équipe responsable de l’enregistrement du problème au moment de l’événement. Dans Jira Service Management, cet attribut est souvent associé à « Component » ou à un champ personnalisé tel que « Support Group ». Cet attribut est essentiel au Dashboard « Support Group Handover Bottlenecks », qui permet aux analystes de visualiser les transferts de problèmes entre les équipes et de repérer les équipes auprès desquelles les problèmes restent le plus longtemps. Pourquoi c’est important Essentiel pour l’analyse organisationnelle et l’identification des difficultés entre équipes. Où les obtenir Champ de demande « Component » ou champ personnalisé « Support Group » Exemples Administration des bases de donnéesOpérations réseauSupport applicatif 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 « Low » à « Critical ». Ce champ sert à segmenter l’analyse et à vérifier que les problèmes prioritaires sont résolus dans les délais prévus par le SLA. L’analyse de cet attribut alimente le Dashboard « SLA Compliance and Target Trends », afin de vérifier que les risques importants pour l’entreprise sont correctement priorisés. Pourquoi c’est important Permet de segmenter la performance du processus selon la criticité métier. Où les obtenir Champ de demande « Priority » Exemples Très élevéeÉlevéeMoyenneFaible
	Résumé du problème ProblemSummary	Description courte ou titre de l’enregistrement du problème.
Description Contient le résumé principal de l’enregistrement du problème. Bien qu’il s’agisse principalement d’un champ textuel, il fournit aux analystes le contexte nécessaire à l’examen de cas individuels dans l’outil de Process Mining. Il permet d’effectuer des recherches par mots-clés et une analyse qualitative des types de problèmes enregistrés. Pourquoi c’est important Fournit un contexte lisible pour l’identifiant du cas. Où les obtenir Champ de demande « Summary » Exemples Délai d'attente de connexion à la base de données dans la région UEPic de latence du service de messagerieFile d'attente de traitement des commandes bloquée
	Utilisateur UserKey	Identifiant unique ou nom de l’utilisateur ayant réalisé l’activité.
Description Enregistre l’identité de la personne ou du compte système responsable de l’exécution de l’activité concernée. Il peut s’agir de l’« Assignee » qui met à jour l’enregistrement ou de l’« Author » d’une modification de statut. Ces données servent à analyser l’utilisation des ressources, à identifier les goulots d’étranglement lors des transferts entre utilisateurs et à garantir la répartition des responsabilités dans le processus de gestion des problèmes. Pourquoi c’est important Essentiel pour analyser les transferts, la séparation des tâches et la charge de travail des Ressources. Où les obtenir Champ « author » de Jira dans le changelog ou champ « assignee » de la demande Exemples j.smithsystem_automationm.doe
	A été rouvert IsReopened	Indicateur précisant si le problème a été rouvert après sa clôture.
Description Indicateur booléen défini sur true lorsque l’enregistrement du problème passe d’un état fermé à un état ouvert. Il alimente l’analyse « Problem Reopened Rate Analysis ». 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 c’est important Indicateur de qualité de l’efficacité des corrections. Où les obtenir Dérivé des transitions de statut Exemples truefalse
	Code de résolution ResolutionCode	Code indiquant la manière dont le problème a été résolu.
Description Précise le résultat final de l’enregistrement du problème, par exemple « Fixed », « Won’t Fix », « Duplicate » ou « Cannot Reproduce ». Il sert à distinguer les problèmes effectivement résolus de ceux qui ont été clôturés pour des raisons administratives, afin de garantir l’exactitude des KPI tels que « Mean Time to Root Cause ». Pourquoi c’est important Distingue les corrections efficaces des clôtures administratives. Où les obtenir Champ de 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 correspondant à la première consignation du problème dans le système. Alors que l’horodatage de l’événement sert à suivre le moment de l’activité, cet attribut est souvent utilisé pour les filtres de haut niveau, par exemple « Afficher tous les problèmes créés au premier trimestre ». Il constitue le point de référence de l’analyse de l’ancienneté. Pourquoi c’est important Date de référence pour l’analyse de l’ancienneté et du volume des demandes entrantes. Où les obtenir Champ de 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. Elle se distingue de la personne assignée. L’analyse des déclarants aide à comprendre où les problèmes sont détectés, par exemple par les agents du Service Desk ou les administrateurs système. Elle apporte un contexte supplémentaire à l’analyse « Proactive vs Reactive ». Pourquoi c’est important Identifie la source de la prise en charge du problème. Où les obtenir Champ de demande « Reporter » Exemples monitoring_servicehelpdesk_leadnetwork_admin
	Demande de changement liée LinkedChangeRequest	Identifiant de la demande de changement liée à ce problème.
Description Stocke l’identifiant de la Change Request (RFC) créée pour mettre en œuvre la correction définitive. Ce lien est essentiel au Dashboard « Change Request Initiation Lag ». Il relie le processus de Gestion des problèmes à celui de Gestion du changement et permet une analyse interprocessus. Pourquoi c’est important Relie l’analyse à la remédiation dans le processus de Gestion du changement. Où les obtenir Liens de demande dont le type est « is fixed by » ou équivalent Exemples CR-404CHG-1099CR-5512
	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 le KPI « Incident to Problem Linkage Depth » pour prioriser les problèmes qui génèrent le plus grand nombre de tickets de Support. Pourquoi c’est important Quantifie l’impact métier à partir du volume d’incidents. Où les obtenir Nombre de liens dans la table « issuelinks » dont le type est « Problem/Incident » Exemples 011550
	PIR réalisée ReviewStatus	Indique si une Post Implementation Review (PIR) a été réalisée.
Description Suit la présence de l’activité ou de l’indicateur « Post Implementation Review » dans le cas. Cet élément est essentiel au Dashboard « Post Implementation Review Compliance ». Il permet de vérifier que l’organisation respecte ses exigences de gouvernance en matière d’amélioration continue. Pourquoi c’est important Indicateur de Conformité pour l’apprentissage organisationnel. Où les obtenir 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 le texte d’une solution de contournement temporaire existe ou a été publié. L’organisation peut ainsi suivre la « Workaround Publication Speed ». L’analyse de ce champ aide à déterminer à quelle vitesse l’équipe peut rétablir la stabilité du service, même avant la mise en place d’une correction définitive. Pourquoi c’est important Essentiel pour mesurer la rapidité du soulagement temporaire apporté à l’entreprise. Où les obtenir Champ personnalisé « Workaround » Exemples Redémarrer le serviceVider le cache du navigateurAucune information fournie
	Source de détection DetectionSource	Méthode d’identification du problème, par exemple proactive ou réactive.
Description Indique l’origine de l’identification du problème. Les valeurs courantes incluent « Proactive Monitoring », « Service Desk Incident » ou « Vendor Notification ». Cet attribut est utilisé dans le Dashboard « Proactive vs Reactive Identification » pour mesurer la maturité du processus de Gestion des problèmes. Pourquoi c’est important Mesure la maturité du processus et l’efficacité des systèmes de surveillance. Où les obtenir Champ personnalisé « Source » ou « Detection Source » Exemples Surveillance proactiveEscalade d'incidentNotification du fournisseur
	Statut de dépassement du SLA SlaBreachStatus	Indique si l’enregistrement du problème a dépassé les engagements de niveau de service.
Description Champ booléen ou de statut indiquant si le délai de résolution a dépassé l’objectif convenu. Il contribue au Dashboard « SLA Compliance and Target Trends ». Il met en évidence les cas susceptibles d’exposer l’organisation à des risques de non-conformité ou à des pénalités. Pourquoi c’est important Essentiel pour le suivi de la Conformité et de la performance. Où les obtenir Logique du champ SLA de Jira Service Management Exemples RespectéEn dépassementEn pause

Obligatoire Recommandé Facultatif

Activités de gestion des problèmes

Voici les principales étapes du processus et les jalons à enregistrer dans votre journal d’événements pour découvrir précisément vos flux de travail de résolution.

8 Recommandé 6 Facultatif

	Activité	Description
	Affecté à un groupe de support	Affectation de l’enregistrement de problème à une équipe technique ou à un groupe de support précis. Elle est suivie au moyen des modifications du champ personnalisé « Support Group » ou du champ « Assignee » lorsque les groupes ne sont pas utilisés.
Pourquoi c’est important Essentiel pour analyser les transferts et les goulots d’étranglement entre les équipes. Des taux de transfert élevés peuvent révéler des inefficacités dans l’orientation des demandes. Où les obtenir Historique Jira Issue : champ « Support Group » ou « Assignee » modifié Collecte 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 enregistrée. Il est déduit d’un changement de statut vers « Root Cause Identified » ou du renseignement du champ « Root Cause ».
Pourquoi c’est important Une étape majeure qui clôt la phase d’investigation. Indispensable pour calculer le « Mean Time to Root Cause Discovery ». Où les obtenir Historique Jira Issue : statut modifié en « Root Cause Identified » OU champ « Root Cause » renseigné Collecte Comparer le champ de statut ou vérifier que le champ est renseigné Type d’événement inferred
	Enregistrement de problème créé	L’événement initial au cours duquel le ticket de problème est créé dans le système. Il est enregistré explicitement dans l’historique du ticket avec l’horodatage de création.
Pourquoi c’est important Marque le début du cycle de vie de la Gestion des problèmes et permet d’analyser les volumes. Indispensable pour calculer le débit et les taux d’entrée. Où les obtenir Table Jira Issue : horodatage Created Date ou onglet History : événement Issue Created Collecte Enregistré lorsque la transaction de création du ticket est validée Type d’événement explicit
	Enregistrement de problème fermé	Clôture définitive du cycle de vie du problème. Elle est explicitement capturée lorsque le statut passe à « Closed ».
Pourquoi c’est important Fin définitive de l’instance du processus. Nécessaire pour calculer le temps de cycle total et les taux de clôture. Où les obtenir Historique Jira Issue : statut modifié en « Closed » Collecte Enregistré lorsque le statut passe à Closed Type d’événement explicit
	Incident lié au problème	Action consistant à lier un ticket d’incident associé à l’enregistrement de problème. Cet événement est capturé dans la table des liens entre tickets ou dans l’historique.
Pourquoi c’est important Détermine l’impact et la portée du problème. Indispensable pour l’indicateur « Incident to Problem Linkage Depth » et pour établir les priorités selon l’impact métier. Où les obtenir Liens Jira Issue : lien créé avec le type « causes » ou « relates to » Collecte Enregistré lorsqu’un lien entre tickets est créé Type d’événement explicit
	Investigation commencée	Transition du statut du problème vers un état d’investigation actif, par exemple « Under Investigation » ou « In Progress ». Elle marque le début de la phase de travail actif.
Pourquoi c’est important Lance le chronomètre du cycle d’investigation. Permet de distinguer le temps d’attente dans le backlog du temps consacré à l’analyse active. Où les obtenir Historique Jira Issue : statut modifié en « Under Investigation » ou « In Progress » Collecte Comparer les mises à jour du champ de statut Type d’événement inferred
	Résolution vérifiée	Confirmation que la correction a effectivement résolu le problème. Elle est déduite d’une transition vers le statut « Resolved » ou vers un état spécifique « Verified ».
Pourquoi c’est important Point de contrôle qualité qui garantit le bon fonctionnement du correctif. Les retards à cette étape indiquent des goulots d’étranglement lors des tests ou de la validation par les utilisateurs. Où les obtenir Historique Jira Issue : statut modifié en « Resolved » ou « Verified » Collecte 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 correction temporaire a été documentée.
Pourquoi c’est important Mesure la rapidité avec laquelle une solution est apportée à l’activité. Indispensable pour l’indicateur « Workaround Availability Lead Time ». Où les obtenir Historique Jira Issue : champ « Workaround » modifié, valeur non nulle Collecte Enregistré lorsque le champ Workaround est modifié Type d’événement explicit
	Correction définitive appliquée	Transition indiquant que la solution a été mise en œuvre. Elle est généralement déduite d’un changement de statut vers « Implementing » ou « Fixed ».
Pourquoi c’est important Marque la fin du travail de remédiation technique. Sert à mesurer le temps de cycle de mise en œuvre. Où les obtenir Historique Jira Issue : statut modifié en « Implemented », « Pending Verification » ou « Fixed » Collecte Comparer les mises à jour du champ de statut Type d’événement inferred
	Demande de changement liée	Liaison d’une Request for Change (RFC) à l’enregistrement de problème. Elle indique le lancement du processus de correction définitive.
Pourquoi c’est important Mesure le délai entre l’identification de la cause et le début de la remédiation. Alimente l’indicateur « Change Management Transition Delay ». Où les obtenir Liens Jira Issue : lien créé avec le type « is fixed by » ou liaison avec un type de ticket « Change » Collecte Enregistré lorsqu’un lien vers un type de ticket Change est créé Type d’événement explicit
	Priorité du problème modifiée	Mise à jour du champ Priority de l’enregistrement de problème. Cet événement est capturé en surveillant, dans l’onglet History, les modifications du champ « Priority ».
Pourquoi c’est important Indique une escalade ou une désescalade du problème. Son analyse permet d’évaluer la précision du triage initial et l’ancienneté du backlog prioritaire. Où les obtenir Historique Jira Issue : champ « Priority » modifié de Old Value à New Value Collecte Enregistré lorsque le champ Priority est mis à jour Type d’événement explicit
	Problème rouvert	Transition d’un problème du statut « Resolved » ou « Closed » vers un statut actif. Elle indique une correction infructueuse ou une résolution rejetée.
Pourquoi c’est important Indicateur de qualité majeur. Un taux élevé de réouverture révèle une analyse des causes profondes ou des tests inefficaces. Où les obtenir Historique Jira Issue : statut modifié de « Closed »/« Resolved » à « Open »/« In Progress » Collecte Comparer la séquence des champs de statut Type d’événement inferred
	Revue post-déploiement	Réalisation d’une revue après l’application de la correction. Elle est capturée par un changement de statut vers « In Review » ou par la mise à jour de champs propres à la PIR.
Pourquoi c’est important Activité de conformité garantissant la consignation des enseignements tirés. Elle alimente l’analyse de la « Post Implementation Review Compliance ». Où les obtenir Historique Jira Issue : statut modifié en « In Review » OU champ « PIR Notes » mis à jour Collecte Comparer le champ de statut ou les mises à jour des champs PIR Type d’événement inferred
	SLA non respecté	É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 c’est important Indispensable pour les rapports de conformité. Permet d’identifier les priorités ou catégories qui dépassent le plus souvent les objectifs. Où les obtenir Journaux SLA de Jira Service Management : « Time to Resolution » > Target, ou valeur calculée Collecte À déduire des données du champ SLA ou en comparant Due Date et Resolution Date 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 à l’aide d’un navigateur web et d’un compte disposant de l’autorisation « Browse Projects » pour le projet Problem Management.
Dans la barre de menu supérieure, sélectionnez Filters, puis cliquez sur Advanced Issue Search pour ouvrir l’Issue Navigator.
Passez le mode de recherche à JQL (Jira Query Language), plutôt que Basic, si ce mode n’est pas déjà sélectionné.
Saisissez la requête JQL indiquée dans la section Query afin d’isoler les enregistrements Problem, par exemple project = 'Problem Management'. Vérifiez que la période respecte les limites d’export du système.
Cliquez sur Search pour vérifier que la liste des problèmes renvoie les enregistrements Problem attendus.
Repérez le bouton Export dans l’angle supérieur droit de l’interface de l’Issue Navigator.
Sélectionnez Export XML dans le menu déroulant. Ne sélectionnez pas CSV, car l’export CSV standard fournit uniquement l’état actuel et ne contient pas les journaux historiques des modifications nécessaires 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, en vérifiant que la variable du chemin d’accès correspond à l’emplacement du fichier XML enregistré.
Le script analyse la structure RSS/XML, extrait l’horodatage « Created », les entrées « History » relatives aux changements de statut, de priorité et d’affectation, ainsi que les « Issue Links » associés aux incidents.
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’export : utilisez obligatoirement l’export 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 exports standard de Jira sont souvent limités à 1 000 problèmes par export. Pour les volumes plus importants, paginez l’extraction en ajustant la période JQL, par exemple created >= '2023-01-01' AND created < '2023-02-01', puis en réalisant plusieurs exports.
Filtre JQL : vérifiez que la clé project correspond à l’identifiant de votre projet Problem Management, par exemple PROB ou PM.
Fuseau horaire du système : vérifiez que le profil utilisateur effectuant l’export utilise le même fuseau horaire que le système afin de garantir la cohérence des horodatages.
Autorisations sur les champs : l’utilisateur doit être autorisé à consulter l’historique des modifications et les problèmes liés afin d’enregistrer 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 du script correspond aux noms utilisés dans votre instance Jira.

a 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éparez les prérequis : vérifiez que Python 3.x est installé avec les bibliothèques requests et pandas. Vous aurez besoin d’un compte Jira Service Management disposant des droits 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).
Identifiez les identifiants des champs personnalisés : Jira Service Management utilise des identifiants dynamiques pour les champs personnalisés, par exemple customfield_10012 pour le groupe d’assistance ou le SLA. Avant d’exécuter l’extraction principale, utilisez un navigateur ou Postman pour interroger un problème précis (/rest/api/2/issue/[ISSUE-KEY]) et identifier les identifiants des champs « Support Group », « Workaround », « Root Cause » et de vos 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 identifiés à l’étape 2. Modifiez JQL_QUERY pour cibler votre projet, par exemple project = PM AND issuetype = Problem.
Définissez les associations de statuts : dans le dictionnaire STATUS_MAPPING du script, associez les statuts propres à votre flux de travail Jira, par exemple « Under Investigation », « Implementing » et « Resolved », aux noms d’activités standard de ProcessMind, par exemple « Investigation Started » et « Permanent Fix Applied ».
Exécutez l’extraction : lancez le script depuis un terminal ou un IDE. Il utilise l’API de recherche Jira avec expand=changelog afin de récupérer l’état actuel et l’historique complet des modifications de chaque champ.
Appliquez la logique de traitement : le script parcourt chaque problème. Il crée d’abord un événement « Problem Record Created » à partir de l’horodatage de création. Il analyse ensuite l’historique des modifications. Pour chaque élément de l’historique, il vérifie si le champ modifié figure dans la liste suivie, par exemple Status, Priority ou Link, puis génère la ligne d’événement correspondante.
Gérez les SLA : le script tente d’identifier les violations de SLA en recherchant les modifications apportées aux champs personnalisés liés aux SLA ou les transitions de statut explicitement nommées « Breached ». Adaptez la logique de la fonction _parse_sla_breach si votre système utilise une automatisation spécifique pour signaler les violations.
Transformez les données : le script aplatit la structure JSON imbriquée pour créer un DataFrame Pandas tabulaire. Les horodatages sont convertis au format ISO 8601.
Exportez les données : 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.
Importez les données 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 Jira Cloud et la plupart des versions Data Center. L’API v3 est également prise en charge, mais la v2 offre généralement une compatibilité plus large.
Pagination : le script utilise startAt et maxResults pour traiter efficacement les grands volumes de données. La taille de lot par défaut est fixée à 50.
Extension Changelog : le paramètre expand=changelog est essentiel. Sans lui, seul l’état actuel est renvoyé et l’historique du processus est perdu.
Filtrage JQL : la requête filtre sur issuetype = Problem. Il est vivement recommandé d’ajouter un filtre de période, par exemple created >= -180d, afin de limiter le volume de données lors des premiers tests.
Authentification : l’authentification de base, 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 : cette configuration est essentielle. Les noms internes Jira de « Status » et « Priority » sont standard, mais « Support Group », « Root Cause » et « SLA » sont presque toujours des champs personnalisés dotés d’identifiants propres, par exemple customfield_12345.

a 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 vos 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 flux de gestion des problèmes

Réduisez de 30 % les délais de traitement et stabilisez votre environnement informatique.

Démarrer l’essai gratuit

Aucune carte bancaire requise. Configuration en quelques minutes.

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

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

Attributs de la gestion des problèmes

Activités de gestion des problèmes

Guides d’extraction

Export de l’Issue Navigator de Jira Service Management

Étapes

Configuration

a Exemple de requête sql

Extraction Python via l’API REST Jira avec Changelog

Étapes

Configuration

a Exemple de requête python

Prêt à commencer ?

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

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

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

Attributs de la gestion des problèmes

Activités de gestion des problèmes

Guides d’extraction

Export de l’Issue Navigator de Jira Service Management

Étapes

Configuration

a Exemple de requête sql

Extraction Python via l’API REST Jira avec Changelog

Étapes

Configuration

a Exemple de requête python

Prêt à commencer ?

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

Nous attachons de l’importance à votre confidentialité