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

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

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

Ce template sert de feuille de route complète pour l'analyse de vos workflows de gestion des services IT en identifiant les données clés et les jalons de processus dans Jira Service Management. Il offre une vue d'ensemble structurée des attributs et activités nécessaires pour obtenir une visibilité totale sur la manière dont votre équipe gère les problèmes sous-jacents et l'analyse des causes premières. Utilisez ces directives pour simplifier votre collecte de données et vous assurer que vos initiatives de process mining génèrent des perspectives concrètes.
  • Attributs recommandés pour une analyse détaillée
  • Jalons de processus à capturer dans votre journal d'événements
  • Guide technique pour l'extraction de données
Vous découvrez les journaux d'événements ? Apprenez comment créer un journal d'événements Process Mining.

Attributs de gestion des problèmes

Ce sont les champs de données recommandés à inclure dans votre journal d'événements pour une analyse complète de votre cycle de vie de gestion des problèmes.
5 Obligatoire 5 Recommandé 10 Facultatif
Nom Descriptionn
Activité
ActivityName
L'action spécifique ou le changement de statut qui s'est produit pour l'enregistrement de problème.
Descriptionn

Cet attribut capture le nom de l'événement ou de la transition d'état se produisant dans le cycle de vie de gestion des problèmes. Les exemples incluent 'Problème enregistré', 'Statut changé en En investigation', ou 'Cause première identifiée'.

Il est indispensable pour cartographier le flux de processus et identifier la séquence des étapes prises pour résoudre un problème. En process mining, ces activités forment les nœuds de la carte de processus.

Pourquoi est-ce important ? :

Définit les étapes de la cartographie des processus et permet l'analyse des variantes de processus.

Source des données :

Jira Changelog (Historique) ou transitions de statut de problème

Exemples
Enregistrement de Problème CrééEnquête initiéeCause profonde identifiéeSolution de contournement mise à jourEnregistrement de problème clôturé
Dernière mise à jour des données
LastDataUpdate
L'horodatage de l'extraction ou de la dernière actualisation des données.
Descriptionn

Indique la dernière synchronisation de l'jeu de données avec l'environnement Jira Service Management en direct. Cela garantit que les analystes comprennent la la réactualisation des données.

Il est utilisé pour valider que l'analyse reflète l'état le plus actuel du processus et pour identifier les problèmes potentiels de latence des données.

Pourquoi est-ce important ? :

Assure la la réactualisation des données et aide à la confiance dans les résultats de l'analyse.

Source des données :

ETL Horodatage

Exemples
2023-11-01T12:00:00Z2023-11-02T00:00:00Z
Enregistrement de problème
ProblemKey
L'identifiant unique attribué à l'enregistrement de problème dans Jira Service Management.
Descriptionn

Cet attribut sert d'ID de cas pour l'analyse de processus 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 est utilisé pour regrouper toutes les activités, changements de statut et mises à jour liés en une seule instance de processus complet. L'analyse de cet attribut facilite la visualisation du cycle de vie complet d'un problème, de la détection initiale à la clôture finale, en passant par l'investigation.

Pourquoi est-ce important ? :

C'est l'élément clé requise pour reconstruire le flux de processus et suivre des enregistrements de problèmes spécifiques.

Source des données :

Table des problèmes, champ 'Clé' ou 'Clé du problème'

Exemples
PM-1023PM-4099PRB-3321PM-5001
Horodatage
EventTimestamp
La date et l'heure exactes de l'activité.
Descriptionn

Cet attribut enregistre le moment précis où une activité a eu lieu. Il est utilisé pour séquencer les événements chronologiquement et calculer les durées entre les étapes.

Des horodatages précis sont essentiels pour calculer les temps de cycle, tels que le temps entre 'Problème enregistré' et 'Cause première identifiée', et pour analyser le débit au fil du temps.

Pourquoi est-ce important ? :

Permet le calcul de tous les KPI basés sur le temps et le bon ordre des événements.

Source des données :

Date de création du Jira Changelog ou date de création du problème

Exemples
2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:20:00Z
Système source
SourceSystem
Le nom du système d'où proviennent les données.
Descriptionn

Identifie le système logiciel à partir duquel les données du processus ont été extraites. Dans ce contexte, la valeur est constamment 'Jira Service Management'.

Cet attribut est particulièrement utile dans les environnements multi-systèmes pour distinguer les sources de données, bien que pour cette vue spécifique, il serve principalement d'identifiant statique pour la traçabilité des données.

Pourquoi est-ce important ? :

Fournit le contexte de l'origine des données, en particulier lors de la fusion avec d'autres données de gestion des services informatiques.

Source des données :

Configuration codée en dur ou système

Exemples
Jira Service ManagementJira CloudJSM-Prod
Catégorie de cause profonde
RootCauseCategory
La classification de la cause sous-jacente du problème.
Descriptionn

Catégorise la défaillance technique ou de processus qui a causé le problème, telle que « Bug logiciel », « Erreur humaine » ou « Défaillance matérielle ». Il s'agit souvent d'un champ personnalisé dans Jira Service Management.

Cet attribut soutient le tableau de bord « Distribution des catégories de causes profondes », permettant des décisions stratégiques sur les investissements en infrastructure ou en formation pour prévenir les récurrences.

Pourquoi est-ce important ? :

Clé pour identifier les problèmes systémiques et orienter les mesures préventives.

Source des données :

Champ personnalisé 'Cause profonde' ou 'Catégorie de cause profonde'

Exemples
Bogue logicielErreur de configurationProblème de capacitéProblème fournisseur
Groupe de support assigné
SupportGroup
L'équipe technique ou le groupe actuellement affecté à l'investigation du problème.
Descriptionn

Identifie l'équipe spécifique responsable de l'enregistrement de problème au moment de l'événement. Dans Jira Service Management, cela est souvent associé à 'Composant' ou à un champ personnalisé comme 'Groupe de support'.

Cet attribut est indispensable à le tableau de bord « Goulots d'étranglement des transferts entre groupes de support », permettant aux analystes de visualiser comment les problèmes se déplacent entre les équipes et où ils restent le plus longtemps.

Pourquoi est-ce important ? :

Primordial pour le process mining organisationnel et l'identification des frictions inter-équipes.

Source des données :

Champ 'Composant' du problème ou champ personnalisé 'Groupe de support'

Exemples
Administration de Bases de `Données`Opérations réseauSupport applicatif niveau 2
Priorité
Priority
Le niveau de criticité attribué à l'enregistrement de problème.
Descriptionn

Indique l'urgence et l'impact du problème, allant typiquement de « Faible » à « Critique ». Ce champ est utilisé pour segmenter l'analyse et s'assurer que les problèmes de haute priorité sont résolus dans les objectifs SLA.

L'analyse de cet attribut aide dans le tableau de bord « Conformité SLA et Tendances des Objectifs » à vérifier si les risques métier critiques sont correctement priorisés.

Pourquoi est-ce important ? :

Permet la segmentation de la performance des processus par criticité métier.

Source des données :

Champ 'Priorité' du problème

Exemples
La plus élevéeÉlevéMoyenFaible
Résumé du problème
ProblemSummary
La description textuelle courte ou le titre de l'enregistrement de problème.
Descriptionn

Contient le résumé principal (headline) de l'enregistrement de problème. Bien que principalement basé sur du texte, il fournit un contexte aux analystes qui examinent les cas individuels dans l'outil de process mining.

Il permet la recherche par mots-clés et l'analyse qualitative des types de problèmes enregistrés.

Pourquoi est-ce important ? :

Fournit un contexte compréhensible par l'utilisateur pour l'identifiant de cas.

Source des données :

Champ 'Résumé' du problème

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
L'identifiant unique ou le nom de l'utilisateur qui a effectué l'activité.
Descriptionn

Capture l'identité de la personne ou du compte système responsable de l'exécution de l'activité spécifique. Il peut s'agir de l'« Assigné » mettant à jour l'enregistrement ou de l'« Auteur » d'un changement de statut.

Ces données sont utilisées pour analyser l'utilisation des ressources, identifier les points de blocage (points de blocage) de transfert entre les utilisateurs et garantir la responsabilité au sein du processus de gestion des problèmes.

Pourquoi est-ce important ? :

Critique pour l'analyse des transferts, de la ségrégation des tâches et de la charge de travail des ressources.

Source des données :

Champ 'auteur' de Jira dans le journal des modifications ou champ 'assigné' sur le problème

Exemples
j.smithsystem_automatisationm.doe
Code de Résolution
ResolutionCode
Le code indiquant comment le problème a été résolu.
Descriptionn

Spécifie l'issue finale de l'enregistrement de problème, telle que 'Corrigé', 'Ne sera pas corrigé', 'Doublon' ou 'Non reproductible'.

Ceci est utilisé pour filtrer les problèmes résolus avec succès de ceux fermés pour des raisons administratives, garantissant que les calculs de KPI comme le 'Temps moyen jusqu'à la cause première' sont précis.

Pourquoi est-ce important ? :

Distingue les correctifs efficaces des clôtures administratives.

Source des données :

Champ 'Résolution' du problème

Exemples
TerminéRefuséDoublonImpossible de reproduire
Date de création
CreatedDate
La date de création de l'enregistrement de problème.
Descriptionn

L'horodatage lorsque le problème a été enregistré pour la première fois dans le système. Bien que l'horodatage de l'événement gère le timing des activités, cet attribut spécifique est souvent utilisé pour un filtrage de haut niveau (par exemple, 'Montrez-moi tous les problèmes créés au T1').

Il sert de point d'ancrage pour l'analyse du vieillissement.

Pourquoi est-ce important ? :

Date de référence pour l'analyse de l'ancienneté et du volume d'admission.

Source des données :

Champ 'Créé' du problème

Exemples
2023-01-012023-06-15
Déclarant
ReporterName
L'utilisateur qui a initialement enregistré le problème.
Descriptionn

Identifie l'individu qui a créé l'enregistrement de problème. C'est distinct de l'assigné. L'analyse des reporters aide à comprendre où les problèmes sont détectés (par exemple, Agents du Centre de services vs Administrateurs Système).

Cela ajoute du contexte à l'analyse « Proactif vs Réactif ».

Pourquoi est-ce important ? :

Identifie la source d'admission des problèmes.

Source des données :

Champ 'Reporter' du problème

Exemples
monitoring_servicehelpdesk_leadnetwork_admin
Demande de changement liée
LinkedChangeRequest
L'identifiant de la demande de changement liée à ce problème.
Descriptionn

Stocke l'ID de la demande de changement (RFC) créée pour implémenter le correctif permanent. Ce lien est indispensable à le tableau de bord 'Délai d'initiation de la demande de changement'.

Il connecte le processus de gestion des problèmes à la gestion du changement, permettant une analyse inter-processus.

Pourquoi est-ce important ? :

Connecte l'investigation à la remédiation dans le processus de gestion des changements.

Source des données :

Liens de problème où le type est 'est résolu par' ou similaire

Exemples
CR-404CHG-1099CR-5512
Incident rouvert
IsReopened
Indicateur signalant si le problème a été rouvert après sa clôture.
Descriptionn

Un indicateur booléen (flag) défini à vrai si l'enregistrement de problème est passé d'un état fermé à un état ouvert. Ceci soutient l'« Analyse du taux de réouverture des problèmes ».

Des taux de réouverture élevés indiquent des problèmes de qualité avec les correctifs permanents ou des procédures de vérification insuffisantes.

Pourquoi est-ce important ? :

Indicateur de qualité de l'efficacité des correctifs.

Source des données :

Dérivé des transitions de statut

Exemples
truefaux
Nombre d'incidents liés
LinkedIncidentCount
Le nombre d'incidents liés à cet enregistrement de problème.
Descriptionn

Un décompte des tickets d'incidents associés à l'enregistrement de problème. Cet attribut quantifie l'impact du problème sur la base d'utilisateurs.

Il est utilisé dans l'indicateur clé de performance (KPI) « Profondeur du lien Incident-Problème » pour prioriser les problèmes qui génèrent le plus grand volume de tickets de support.

Pourquoi est-ce important ? :

Quantifie l'impact métier basé sur le volume d'incidents.

Source des données :

Nombre de liens dans la table 'issuelinks' où le type est 'Problème/Incident'

Exemples
011550
Revue post-implémentation effectuée
ReviewStatus
Indique si une revue post-implémentation (PIR) a été effectuée.
Descriptionn

Vérifie si l'activité ou l'indicateur 'Revue post-implémentation' est présent sur le cas. Ceci est indispensable pour le tableau de bord 'Conformité de la Revue post-implémentation'.

Il garantit que l'organisation respecte les exigences de gouvernance pour l'amélioration continue.

Pourquoi est-ce important ? :

Métrique de conformité pour l'apprentissage organisationnel.

Source des données :

Champ personnalisé 'Statut PIR' ou existence 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.
Descriptionn

Capture si un texte de solution de contournement temporaire existe ou a été publié. Cela permet à l'organisation de suivre la « Vitesse de publication de la solution de contournement ».

L'analyse de ce champ aide à déterminer la rapidité avec laquelle l'équipe peut restaurer la stabilité du service, même avant qu'un correctif permanent ne soit trouvé.

Pourquoi est-ce important ? :

Clé pour mesurer la rapidité du soulagement provisoire fourni à l'entreprise.

Source des données :

Champ personnalisé 'Solution de contournement'

Exemples
Redémarrer le serviceVider le cache du navigateurAucun fourni
Source de détection
DetectionSource
Comment le problème a été identifié (par exemple, Proactif, Réactif).
Descriptionn

Indique l'origine de l'identification du problème. Les valeurs courantes incluent « Surveillance proactive », « Incident du Centre de services » ou « Notification du fournisseur ».

Cet attribut est utilisé dans le tableau de bord « Identification proactive vs réactive » pour mesurer la maturité du processus de gestion des problèmes.

Pourquoi est-ce important ? :

Mesure la maturité des processus et l'efficacité des systèmes de surveillance.

Source des données :

Champ personnalisé 'Source' ou 'Source de détection'

Exemples
Surveillance proactiveEscalade d'incidentNotification fournisseur
Statut de violation SLA
SlaBreachStatus
Indique si l'enregistrement de problème a dépassé son accord de niveau de service (SLA).
Descriptionn

Un champ booléen ou de statut indiquant si le temps de résolution a dépassé l'objectif convenu. Cela est utile pour le tableau de bord « Conformité SLA et Tendances des Objectifs ».

Il met en évidence les cas qui exposent l'organisation à des risques de conformité ou à des pénalités.

Pourquoi est-ce important ? :

Critique pour la conformité et le suivi des performances.

Source des données :

Logique du champ SLA de Jira Service Management

Exemples
AtteintDépasséMis en Pause
Obligatoire Recommandé Facultatif

Activités de gestion des problèmes

Ce sont les étapes de processus et les jalons clés à capturer dans votre journal d'événements pour une découverte précise de vos workflows de résolution.
8 Recommandé 6 Facultatif
Activité Descriptionn
Affecté au Groupe de Support
L'affectation de l'enregistrement de problème à une équipe technique ou à un groupe de support spécifique. Ceci est suivi via les changements apportés au champ personnalisé 'Support Group' ou au champ 'Assignee' si les groupes ne sont pas utilisés.
Pourquoi est-ce important ? :

Critique pour analyser les transferts et les points de blocage (points de blocage) entre les équipes. Des taux de transfert élevés peuvent indiquer des inefficacités de routage.

Source des données :

Historique du problème Jira : Le champ 'Groupe de support' ou 'Assigné' a changé

Capture

Comptabilisé lorsque le champ d'assignation change

Type d'événement explicit
Cause profonde identifiée
Le point où la cause sous-jacente est formellement enregistrée. Ceci est déduit d'un changement de statut vers 'Cause première identifiée' ou du remplissage du champ 'Cause première'.
Pourquoi est-ce important ? :

Une étape majeure qui met fin à la phase d'enquête. Primordial pour le calcul du « Temps moyen de découverte de la cause profonde ».

Source des données :

Historique du problème Jira : Le statut est passé à 'Cause profonde identifiée' OU le champ 'Cause profonde' a été rempli

Capture

Comparer le champ de statut ou vérifier le remplissage du champ

Type d'événement inferred
Enquête initiée
La transition du statut du problème vers un état d'investigation active (par exemple, 'Sous investigation' ou 'En cours'). Cela marque le début de la phase de travail active.
Pourquoi est-ce important ? :

Déclenche le chronomètre pour le temps de cycle d'investigation. Aide à distinguer le temps d'attente du backlog de l'analyse active réelle.

Source des données :

Historique du problème Jira : Le statut est passé à 'Sous investigation' ou 'En cours'

Capture

Comparer les mises à jour des champs de statut

Type d'événement inferred
Enregistrement de problème clôturé
La clôture finale du cycle de vie du problème. Capturée explicitement lorsque le statut passe à 'Fermé'.
Pourquoi est-ce important ? :

La fin définitive de l'instance de processus. Nécessaire pour le calcul du temps de cycle total et des taux de clôture.

Source des données :

Historique du problème Jira : Le statut est passé à 'Fermé'

Capture

Comptabilisé lorsque le statut passe à 'Fermé'

Type d'événement explicit
Enregistrement de Problème Créé
L'événement initial où le ticket de problème est créé dans le système. Ceci est explicitement capturé dans l'historique du ticket comme l'horodatage de création.
Pourquoi est-ce important ? :

Marque le début du cycle de vie de la gestion des problèmes et permet l'analyse des volumes. Primordial pour calculer le débit et les taux d'admission.

Source des données :

Table de problème Jira : Horodatage de la date de création ou Onglet Historique : Événement de création de problème

Capture

Comptabilisé lorsque la transaction de création de problème est validée

Type d'événement explicit
Incident lié au problème
L'action de lier un ticket d'incident connexe à l'enregistrement de problème. Ceci est capturé dans la table des liens de tickets ou l'historique.
Pourquoi est-ce important ? :

Détermine l'impact et la portée du problème. Primordial pour le KPI « Profondeur du lien Incident-Problème » et pour la priorisation basée sur l'impact métier.

Source des données :

Liens de problème Jira : Lien créé avec le type 'cause' ou 'est lié à'

Capture

Comptabilisé lorsqu'un lien de problème est créé

Type d'événement explicit
Résolution vérifiée
La confirmation que le correctif a effectivement résolu le problème. Déduit d'une transition de statut vers 'Résolu' ou un état 'Vérifié' spécifique.
Pourquoi est-ce important ? :

Porte de qualité garantissant le bon fonctionnement du correctif. Des retards ici indiquent des points de blocage dans les tests ou l'acceptation utilisateur.

Source des données :

Historique du problème Jira : Le statut est passé à 'Résolu' ou 'Vérifié'

Capture

Comparer les mises à jour des champs de statut

Type d'événement inferred
Solution de contournement mise à jour
Le remplissage ou la mise à jour du champ texte 'Solution de contournement'. Cet événement indique qu'un correctif temporaire a été documenté.
Pourquoi est-ce important ? :

Mesure la rapidité de la fourniture d'une solution provisoire à l'entreprise. Critique pour le KPI « Délai de disponibilité de la solution de contournement ».

Source des données :

Historique du problème Jira : Le champ 'Solution de contournement' a changé (non nul)

Capture

Comptabilisé lorsque le champ 'Solution de contournement' est modifié

Type d'événement explicit
Correction permanente appliquée
La transition indiquant que la solution a été implémentée. Ceci est généralement déduit d'un changement de statut vers 'Implémentation' ou 'Corrigé'.
Pourquoi est-ce important ? :

Marque la fin du travail de remédiation technique. Utilisé pour mesurer le temps de cycle d'implémentation.

Source des données :

Historique du problème Jira : Le statut est passé à 'Implémenté', 'Vérification en attente' ou 'Corrigé'

Capture

Comparer les mises à jour des champs de statut

Type d'événement inferred
Demande de changement liée
La liaison d'une demande de changement (RFC) à l'enregistrement de problème. Cela indique l'initiation du processus de correctif permanent.
Pourquoi est-ce important ? :

Mesure le délai entre l'identification de la cause et le début de la remédiation. Soutient le KPI « Délai de transition de la gestion des changements ».

Source des données :

Liens de problème Jira : Lien créé avec le type 'est corrigé par' ou lié au type de problème 'Changement'

Capture

Comptabilisé lorsqu'un lien vers un type de problème 'Changement' est créé

Type d'événement explicit
Priorité du problème modifiée
Une mise à jour du champ 'Priorité' de l'enregistrement de problème. Ceci est capturé en surveillant l'onglet d'historique pour les changements du champ 'Priorité'.
Pourquoi est-ce important ? :

Indique une escalade ou une désescalade du problème. L'analyse de ceci aide à identifier la précision du triage initial et l'ancienneté des arriérés à haute priorité.

Source des données :

Historique du problème Jira : Le champ 'Priorité' est passé de l'ancienne valeur à la nouvelle valeur

Capture

Comptabilisé lorsque le champ 'Priorité' est mis à jour

Type d'événement explicit
Problème rouvert
La transition d'un problème d'un statut 'Résolu' ou 'Fermé' vers un statut actif. Indique un correctif échoué ou une résolution rejetée.
Pourquoi est-ce important ? :

Une métrique de qualité primaire. Des taux de réouverture élevés indiquent une analyse des causes profondes ou des tests inefficaces.

Source des données :

Historique du problème Jira : Le statut est passé de 'Fermé'/'Résolu' à 'Ouvert'/'En cours'

Capture

Comparer la séquence des champs de statut

Type d'événement inferred
Revue post-implémentation
L'exécution d'une revue après l'application du correctif. Capturée via un changement de statut vers 'En revue' ou des mises à jour des champs spécifiques au PIR.
Pourquoi est-ce important ? :

Activité de conformité garantissant la capture des leçons apprises. Soutient l'analyse de « Conformité des revues post-implémentation ».

Source des données :

Historique du problème Jira : Le statut est passé à 'En revue' OU le champ 'Notes PIR' a été mis à jour

Capture

Comparer le champ de statut ou les mises à jour du champ PIR

Type d'événement inferred
SLA Non Respecté
Un événement indiquant que le temps de résolution du problème a dépassé l'accord de niveau de service (SLA) défini. Ceci est calculé en comparant la date cible du SLA avec la date de résolution.
Pourquoi est-ce important ? :

Critique pour les rapports de conformité. Aide à identifier les priorités ou catégories qui manquent le plus souvent leurs objectifs.

Source des données :

Journaux SLA de Jira Service Management : 'Temps de résolution' > Cible, ou calculé

Capture

Déduire 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 obtenir vos données depuis Jira Service Management