Modèle de données : Gestion des incidents

Jira Service Management
Modèle de données : Gestion des incidents

Votre template de données de gestion des incidents

Ce template offre une approche structurée pour la collecte des données essentielles à l'analyse de votre processus de gestion des incidents. Il décrit les attributs cruciaux à collecter, les activités clés à suivre et fournit des conseils pratiques pour extraire ces informations de votre système source. Cela garantit que vous disposez de tous les composants nécessaires pour commencer à optimiser vos workflows de résolution d'incidents.
  • Attributs recommandés à collecter
  • Activités clés à suivre
  • Guide d'extraction pour Jira Service Management
Nouveau dans les journaux d'événements ? Apprenez comment créer un journal d'événements Process Mining.

Attributs de gestion des incidents

Ce sont les champs de données recommandés à inclure dans votre journal d'événements pour une analyse complète de votre processus de gestion des incidents.
5 Obligatoire 7 Recommandé 12 Facultatif
Nom Description
Activité
ActivityName
Le nom de l'événement ou du changement de statut spécifique survenu pour l'incident.
Description

L'Activité représente une étape ou un événement distinct dans le cycle de vie de la gestion des incidents, tels que 'Incident Créé', 'Incident Attribué' ou 'Résolution Proposée'. Elles sont généralement dérivées des transitions de statut ou des événements de mise à jour spécifiques enregistrés dans l'historique ou le journal de modifications du ticket Jira. L'analyse de la séquence et de la durée de ces activités est l'objectif principal du Process Mining, révélant le flux de processus réel, les goulots d'étranglement et les écarts.

Pourquoi c'est important

Les activités constituent l'épine dorsale de la carte des processus, permettant la visualisation et l'analyse du cycle de vie des incidents.

Où obtenir

Dérivé de l'historique des incidents Jira et du journal des modifications, qui enregistre les transitions de statut et les mises à jour des champs clés.

Exemples
Incident assignéEnquête initiéeIncident résolu
Heure de début
EventTimestamp
La date et l'heure exactes de l'activité.
Description

Cet attribut enregistre le timestamp pour chaque activité du cycle de vie de l'incident. Il est crucial pour le calcul des durées, des temps de cycle et des temps d'attente entre les différentes étapes du processus. Des timestamps précis permettent une analyse détaillée des performances, le suivi des SLA et l'identification des bottlenecks. Toutes les métriques de performance, telles que le temps de résolution et la durée de diagnostic, sont dérivées de ces timestamps.

Pourquoi c'est important

Les timestamps sont essentiels pour calculer toutes les métriques basées sur le temps, comprendre la durée des processus et découvrir les bottlenecks de performance.

Où obtenir

Il s'agit de la date 'créée' (created) associée à chaque entrée dans le journal de modifications (changelog) ou l'historique du problème Jira.

Exemples
2023-10-26T10:00:00Z2023-10-26T10:05:14Z2023-10-27T14:30:00Z
ID de l'incident
IncidentId
L'identifiant unique pour chaque ticket d'incident dans Jira Service Management.
Description

L'ID d'Incident, souvent appelé Clé d'Incident dans Jira, sert d'identifiant unique principal pour chaque incident signalé. Il relie toutes les activités, commentaires et changements de statut associés, du moment de la création à la clôture finale. En Process Mining, cet ID est essentiel pour reconstituer le cycle de vie de bout en bout de chaque incident individuel, permettant une analyse exhaustive de l'ensemble du processus.

Pourquoi c'est important

C'est l'identifiant principal utilisé pour corréler tous les events liés en un seul case, constituant le fondement de toute analyse Process Mining.

Où obtenir

Il s'agit du champ 'Clé' (Key) standard pour un problème dans Jira Service Management (par exemple, 'ITSM-123').

Exemples
INC-10234HELPDESK-5678OPS-9901
Dernière mise à jour des données
LastDataUpdate
Le timestamp indiquant la dernière fois que les données ont été actualisées à partir du système source.
Description

Cet attribut enregistre la date de la dernière mise à jour de l'ensemble de données. Il offre un contexte essentiel à quiconque analyse le processus, en garantissant qu'il connaît la fraîcheur des données. Ceci est particulièrement important pour les dashboards de surveillance continue où des informations à jour sont cruciales pour prendre des décisions opportunes. La valeur est généralement la même pour tous les events au sein d'un même lot d'extraction de données.

Pourquoi c'est important

Informe les utilisateurs de l'actualité des données, ce qui est crucial pour la pertinence et la précision de l'analyse.

Où obtenir

Il s'agit du timestamp de l'exécution de l'extraction de données, ajouté pendant le processus de transformation de données.

Exemples
2023-10-27T08:00:00Z2023-10-28T08:00:00Z
Système source
SourceSystem
Le système d'où les données ont été extraites.
Description

Cet attribut identifie l'origine des données, qui, dans ce cas, est Jira Service Management. Il est particulièrement utile dans les environnements où des données provenant de plusieurs systèmes sont combinées pour offrir une vue holistique des processus. Spécifier le système source assure la clarté de la lignée des données et aide à diagnostiquer les problèmes de qualité ou d'extraction des données. Pour ce modèle, la valeur serait statique.

Pourquoi c'est important

Offre un contexte essentiel sur l'origine des données, garantissant clarté et traçabilité, surtout dans les analyses multi-systèmes.

Où obtenir

Il s'agit d'une valeur statique qui doit être ajoutée lors du processus d'extraction de données.

Exemples
Jira Service ManagementJira Cloud
Date de création
CreatedDate
La date et l'heure de la création initiale de l'incident dans le système.
Description

Cet attribut marque le début officiel du cycle de vie de l'incident. C'est le timestamp de référence à partir duquel les métriques globales, comme le temps de résolution total, sont calculées. La date de création est une valeur statique pour chaque incident et sert de point de départ pour l'ensemble du case dans l'analyse Process Mining.

Pourquoi c'est important

Sert de point de départ pour tous les calculs de temps de cycle de bout en bout et les mesures de SLA.

Où obtenir

Le champ standard 'Créé' d'un ticket Jira.

Exemples
2023-10-26T09:58:12Z2023-11-01T15:20:05Z
Date de résolution
ResolutionDate
La date et l'heure auxquelles l'incident a été marqué comme résolu.
Description

Cet attribut enregistre le timestamp lorsque l'incident a été déplacé pour la première fois vers un statut résolu. Il marque la fin de la phase de travail active et constitue le point final pour le calcul du Temps de Résolution. La comparaison de la date de résolution avec la date de création fournit la mesure principale de l'efficience du processus. C'est également un composant clé pour déterminer la conformité aux SLA.

Pourquoi c'est important

Marque la fin du processus de résolution, permettant le calcul du temps de cycle total et de la performance SLA.

Où obtenir

Le champ standard 'Résolu' d'un ticket Jira.

Exemples
2023-10-28T11:20:30Z2023-11-02T10:00:00Z
Groupe d'assignation
AssignmentGroup
L'équipe ou le groupe responsable de la gestion de l'incident.
Description

Le Groupe d'Assignation représente l'équipe chargée de l'incident. Il peut s'agir d'un niveau de support comme le 'Helpdesk N1', d'une équipe spécialisée telle que les 'Opérations Réseau' ou d'une équipe de développement. L'analyse des transitions entre les groupes d'assignation est essentielle pour comprendre les escalades de processus et les transferts. Elle permet de mesurer la performance de l'équipe, d'identifier les goulots d'étranglement au niveau de l'équipe et d'analyser les dépendances inter-équipes.

Pourquoi c'est important

Crucial pour analyser la performance des équipes, le débit et le flux de travail entre les différents niveaux de support ou groupes spécialisés.

Où obtenir

Cela est souvent implémenté comme un champ personnalisé dans Jira, tel que 'Équipe' ou 'Groupe d'affectation'. Il peut parfois être dérivé des Composants Jira ou des Rôles de projet.

Exemples
Support de Niveau 1Équipe d'InfrastructureAdministrateurs de bases de données
Priorité
Priority
Le niveau de priorité assigné à l'incident, indiquant l'urgence de sa résolution.
Description

La Priorité détermine la rapidité requise pour traiter un incident. C'est souvent une combinaison d'impact et d'urgence, influençant directement les objectifs SLA. L'analyse des incidents par priorité aide à comprendre si les incidents de haute priorité sont traités plus rapidement que ceux de faible priorité et si la priorisation est appliquée de manière cohérente. C'est une dimension critique pour filtrer et comparer la performance des processus.

Pourquoi c'est important

Essentiel pour l'analyse de la performance des SLA et la vérification de la bonne allocation des ressources aux incidents les plus critiques.

Où obtenir

Le champ standard 'Priorité' d'un ticket Jira.

Exemples
La plus élevéeÉlevéMoyenFaible
Responsable assigné
Assignee
L'utilisateur actuellement assigné pour travailler sur l'incident.
Description

Le Responsable est l'agent ou l'utilisateur individuel en charge de l'incident à un moment donné. Le suivi des changements d'assignation est crucial pour analyser les transferts, comprendre la répartition de la charge de travail et identifier les personnes impliquées dans des étapes spécifiques du processus. Cet attribut permet de répondre aux questions sur la performance individuelle et l'allocation des ressources au sein des équipes de support.

Pourquoi c'est important

Aide à suivre la charge de travail individuelle, à identifier les goulots d'étranglement liés à des agents spécifiques, et à analyser l'impact des transferts sur le temps de résolution.

Où obtenir

Le champ standard 'Assignee' d'un ticket Jira.

Exemples
John SmithEmily JonesAgentServiceDesk1
Statut
Status
L'étape actuelle de l'incident dans son cycle de vie.
Description

Le champ Statut indique l'état actuel d'un incident au sein du workflow défini, tel que 'Ouvert', 'En Cours', 'En Attente Client' ou 'Résolu'. Les changements de statut sont la source principale pour générer le journal d'activités pour le Process Mining. L'analyse du temps passé dans chaque statut est fondamentale pour identifier les goulots d'étranglement et comprendre où les incidents passent le plus de temps.

Pourquoi c'est important

Reflète directement la progression de l'incident et est la principale source pour identifier les étapes du processus et les temps d'attente.

Où obtenir

Le champ standard 'Statut' d'un ticket Jira.

Exemples
En coursEn attente du clientRésoluClôturé
Temps de Cycle de Résolution
IncidentResolutionCycleTime
Le temps total écoulé entre la création de l'incident et sa résolution.
Description

Il s'agit d'une métrique calculée représentant la durée entre la 'CreatedDate' et la 'ResolutionDate'. C'est l'un des KPI les plus importants en gestion d'incidents, mesurant directement l'efficacité de l'ensemble du processus. L'analyse de cette métrique selon différentes dimensions comme la priorité, le groupe d'affectation ou le composant aide à identifier les facteurs ayant le plus grand impact sur la performance.

Pourquoi c'est important

Mesure directement l'efficacité de bout en bout du processus de gestion des incidents et est un KPI principal pour le suivi des performances.

Où obtenir

Calculé comme ('ResolutionDate' - 'CreatedDate').

Exemples
2h 30m1d 4h5d 1h 15m
Catégorie de Cause Racine
RootCauseCategory
La classification de la cause première sous-jacente de l'incident.
Description

Cet attribut saisit la raison fondamentale pour laquelle l'incident s'est produit, telle que 'Défaut Logiciel', 'Panne Matérielle' ou 'Erreur Utilisateur'. Il est généralement renseigné après investigation et est essentiel pour une gestion efficace des problèmes et la prévention des incidents futurs. L'analyse des catégories de causes premières aide à identifier les faiblesses systémiques et à prioriser les initiatives d'amélioration. Un taux élevé de causes premières 'Inconnues' peut signaler un besoin d'améliorer les processus d'investigation.

Pourquoi c'est important

Facilite l'analyse des causes profondes, contribuant à passer d'une approche réactive à proactive en identifiant et en traitant les sources des incidents.

Où obtenir

Il s'agit presque toujours d'un champ personnalisé dans Jira. Le nom et les options dépendent fortement de la configuration spécifique de l'organisation.

Exemples
Erreur de configurationPanne réseauBogue Logiciel
Composant
Component
Le système, l'application ou la partie de l'infrastructure affectée par l'incident.
Description

Les composants sont des sous-sections d'un projet Jira servant à regrouper les incidents en sous-ensembles, tels que 'User Interface', 'Database' ou 'API'. L'analyse des incidents par composant aide à identifier les éléments d'un système les plus sujets aux problèmes. Cette information est précieuse pour l'analyse des causes profondes et peut orienter les efforts d'amélioration du service ou de réduction de la dette technique.

Pourquoi c'est important

Permet le filtrage et l'analyse en fonction du produit ou de la zone système spécifique affectée, contribuant à identifier les points névralgiques technologiques.

Où obtenir

Le champ standard 'Composants' d'un ticket Jira.

Exemples
Service d'authentificationTableau de Bord de RapportsMobile App
Déclarant
Reporter
L'utilisateur qui a initialement créé ou signalé l'incident.
Description

Le Déclarant est la personne, souvent un utilisateur final ou un autre système, qui a initialement signalé l'incident. L'analyse des incidents par déclarant peut aider à identifier les utilisateurs ou les départements qui rencontrent fréquemment des problèmes. Elle peut également être utilisée pour comprendre les schémas de communication, en particulier lors de l'analyse d'activités comme 'En Attente du Client' et 'Client a Répondu'.

Pourquoi c'est important

Aide à analyser les sources des incidents, à identifier des schémas liés à des utilisateurs ou départements spécifiques, et à comprendre les retards d'interaction client.

Où obtenir

Le champ standard 'Déclarant' d'un ticket Jira.

Exemples
Alice JohnsonBob Williamsmonitoring-tool@example.com
Est un retravail
IsRework
Un indicateur signalant si l'incident a fait l'objet d'une reprise, telle que sa réouverture.
Description

Cet attribut booléen calculé identifie les incidents qui ont été renvoyés à une étape précédente du processus, le plus souvent en étant rouverts après avoir été résolus. Les boucles de reprise (rework loops) sont une source significative d'inefficacité et d'insatisfaction client. Ce drapeau permet une quantification facile du taux de reprise et aide à concentrer l'analyse sur les raisons pour lesquelles les incidents ne sont pas résolus correctement du premier coup.

Pourquoi c'est important

Met en évidence les problèmes de qualité des processus et les inefficacités en signalant les incidents qui nécessitent des travaux répétés, soutenant directement l'analyse des reprises.

Où obtenir

Calculé en détectant des séquences spécifiques de transitions de statut dans l'Event Log, telles que 'Resolved' -> 'Reopened'.

Exemples
truefaux
Gravité
Severity
La mesure de l'impact métier de l'incident.
Description

La gravité définit l'ampleur de l'impact d'un incident sur l'entreprise, de l'affectation d'un seul utilisateur à une panne critique du système. Alors que la Priorité dicte l'ordre de travail, la Gravité informe de l'impact global sur l'activité. L'analyse par gravité aide à comprendre la performance du processus pour les incidents les plus importants pour l'entreprise et est souvent utilisée en combinaison avec la Priorité pour une analyse plus nuancée.

Pourquoi c'est important

Fournit une vue de l'impact métier, permettant une analyse axée sur les incidents les plus préjudiciables aux opérations de l'entreprise.

Où obtenir

Généralement un champ personnalisé dans Jira, car ce n'est pas un champ système standard. Consultez la configuration du projet Jira Service Management.

Exemples
CritiqueMajeurMineurTrivial
ID du problème lié
LinkedProblemId
L'identifiant d'un ticket de problème lié à cet incident.
Description

Les incidents qui sont les symptômes d'un problème sous-jacent plus vaste sont souvent liés à un ticket 'Problème'. Ce champ stocke l'ID de ce problème associé. L'analyse de ces liens aide à comprendre la relation entre les incidents et les problèmes, à mesurer l'efficacité du processus de gestion des problèmes et à identifier les incidents récurrents nécessitant une solution permanente.

Pourquoi c'est important

Relie les incidents aux problèmes sous-jacents, ce qui permet d'analyser l'efficacité avec laquelle l'organisation traite les causes profondes pour prévenir les incidents futurs.

Où obtenir

Ces informations sont stockées dans la section 'Liens d'incident' (Issue Links) d'un problème Jira.

Exemples
PROB-123PROB-456Aucun
Nombre de transferts
HandoffCount
Le nombre de fois où l'incident a été réassigné à un groupe ou un utilisateur différent.
Description

Cette métrique calculée compte le nombre de fois où les champs 'Assignee' ou 'AssignmentGroup' ont changé au cours du cycle de vie de l'incident. Un nombre élevé de transferts (handoffs) indique souvent une inefficacité des processus, un manque de résolution au premier contact ou des lacunes de connaissances, entraînant des temps de résolution plus longs. L'analyse de ce KPI aide à rationaliser le processus d'affectation et à améliorer la collaboration d'équipe.

Pourquoi c'est important

Quantifie la friction et l'inefficacité des processus causées par les réaffectations, aidant à identifier les opportunités d'amélioration des processus.

Où obtenir

Calculé en comptant le nombre de modifications apportées aux champs 'Assignee' ou 'AssignmentGroup' dans l'historique des modifications de l'incident.

Exemples
015
Non-Respect du SLA
SlaBreach
Un indicateur précisant si le temps de résolution de l'incident a dépassé l'objectif de SLA.
Description

Cet attribut booléen calculé indique si un incident a dépassé son SLA de 'Temps de résolution'. Il est vrai si l''IncidentResolutionCycleTime' est supérieur au 'TimeToResolutionTarget'. Ce drapeau simplifie l'analyse et la visualisation, permettant un filtrage et une agrégation faciles pour calculer le KPI global du taux de non-conformité SLA (SLA Breach Rate). C'est la mesure de résultat clé pour le dashboard de suivi de la performance des SLA.

Pourquoi c'est important

Fournit un résultat binaire clair pour la performance SLA, simplifiant le calcul des taux de violation et l'identification des zones problématiques.

Où obtenir

Calculé comme ('IncidentResolutionCycleTime' > 'TimeToResolutionTarget').

Exemples
truefaux
Objectif de Temps de Résolution
TimeToResolutionTarget
La durée cible de SLA pour la résolution de l'incident.
Description

Cet attribut définit la durée maximale prévue pour la résolution d'un incident d'une certaine priorité ou d'un certain type. Il sert de référence pour mesurer le temps de résolution réel et déterminer la conformité aux SLA. Cette valeur est généralement définie dynamiquement selon des règles qui tiennent compte de facteurs tels que la priorité, la gravité ou le type de problème. Elle est fondamentale pour tout dashboard de suivi de la performance des SLA.

Pourquoi c'est important

Établit la référence pour mesurer la conformité aux SLA, servant de base au KPI de Taux de Non-Respect des SLA d'Incidents.

Où obtenir

Ceci est dérivé de la configuration SLA au sein de Jira Service Management. L'objectif spécifique (par exemple, 'Temps de résolution') doit être identifié.

Exemples
4h8h3d
Résolution
Resolution
Le résultat final ou la raison de la résolution de l'incident.
Description

Le champ Résolution explique pourquoi un incident est passé à l'état résolu. Les résolutions courantes incluent 'Corrigé', 'Duplicata', 'Ne sera pas fait' ou 'Non reproductible'. L'analyse de la distribution des types de résolution peut fournir des informations sur la qualité des rapports entrants et l'efficacité du processus de résolution. Par exemple, un nombre élevé de résolutions 'Duplicata' peut indiquer un problème lors de l'étape de création ou de triage de l'incident.

Pourquoi c'est important

Donne du contexte au résultat d'un incident, aidant à catégoriser les résolutions et à identifier les tendances dans la manière dont les incidents sont clôturés.

Où obtenir

Le champ standard 'Résolution' d'un ticket Jira. Ce champ est généralement défini lorsqu'un ticket est passé à une catégorie de statut 'Terminé'.

Exemples
TerminéCorrigéDoublonNe sera pas corrigé
Type d'Incident
IssueType
Le type de ticket, tel qu'un Incident, une Demande de Service ou un Problème.
Description

Jira utilise des Types d'incidents pour distinguer les différentes catégories de tâches. Dans un contexte de gestion des incidents, le type principal est 'Incident', mais d'autres comme 'Sous-tâche' peuvent également être pertinents. Cet attribut est crucial pour filtrer le jeu de données afin d'inclure uniquement les incidents, garantissant que l'analyse par process mining se concentre sur le processus correct.

Pourquoi c'est important

Assure que l'analyse est correctement ciblée sur les incidents, les distinguant des autres types de travail comme les demandes de service ou les changements.

Où obtenir

Le champ standard 'Type de demande' d'un ticket Jira.

Exemples
IncidentSupport TIBug
Type de demande client
CustomerRequestType
Le type de demande spécifique soumise par le client via le portail de services.
Description

Ce champ catégorise les demandes du point de vue du client, telles que présentées sur le portail Jira Service Management (par exemple, 'Signaler un problème système'). Il fournit une classification conviviale de l'incident, qui peut différer du 'Type de problème' interne. L'analyse de cet attribut peut offrir des aperçus sur la manière dont les clients perçoivent et signalent les problèmes, contribuant à améliorer la conception du portail et les offres de services.

Pourquoi c'est important

Offre une vision centrée sur le client des catégories d'incidents, utile pour analyser la demande et améliorer l'expérience client.

Où obtenir

Le champ 'Type de demande client', spécifique aux projets Jira Service Management.

Exemples
Obtenir de l'aide informatique > Signaler un problème systèmeEmail > Demande d'accès
Obligatoire Recommandé Facultatif

Activités de gestion des incidents

Ce sont les étapes clés du processus et les jalons à capturer dans votre journal d'événements pour une découverte et une analyse précises de vos workflows de résolution d'incidents.
7 Recommandé 8 Facultatif
Activité Description
En Attente Du Client
Marque un point où l'équipe de support est en attente d'informations ou d'actions de la part du client. Cela est déduit d'une transition de statut vers un état d'attente dédié comme 'En attente du client'.
Pourquoi c'est important

L'isolation de ce temps de 'on-hold' est cruciale pour une mesure précise des SLA, car il est souvent exclu des calculs de temps de résolution. Cela aide à analyser les retards de réponse des clients.

Où obtenir

Déduit de l'historique des changements de statut de l'incident. L'événement correspond au timestamp lorsque le statut passe à 'Waiting for customer' ou un état similaire.

Capture

Identifier l'horodatage de la transition de statut vers 'En attente du client'.

Type d'événement inferred
Enquête initiée
Indique qu'un agent assigné a commencé à travailler activement sur le diagnostic de l'incident. Cela est généralement déduit lorsque le statut de l'incident passe de 'Open' ou 'New' à 'In Progress'.
Pourquoi c'est important

Cette étape clé marque le début des efforts de résolution actifs. Mesurer le temps jusqu'à cette activité aide à identifier les retards initiaux de file d'attente et les problèmes de disponibilité des ressources.

Où obtenir

Déduit de l'historique des changements de statut de l'incident. Le timestamp de l'événement correspond au moment où le statut passe à un état représentant un travail actif, tel que 'In Progress'.

Capture

Identifier l'horodatage de la transition de statut vers 'En cours'.

Type d'événement inferred
Incident clôturé
Représente la clôture administrative finale du ticket d'incident après sa résolution et sa vérification. Cela est inféré de la transition de statut vers 'Fermé'.
Pourquoi c'est important

C'est l'event terminal du processus. L'analyse du temps entre 'Résolu' et 'Clos' peut révéler des retards dans les processus de nettoyage administratif ou de confirmation utilisateur.

Où obtenir

Déduit de l'historique des changements de statut de l'incident. L'événement correspond au timestamp lorsque le statut passe à l'état final 'Closed'.

Capture

Identifier l'horodatage de la transition de statut vers 'Fermé'.

Type d'événement inferred
Incident créé
Marque le début officiel du cycle de vie de l'incident lorsqu'un rapport d'incident est soumis et qu'un nouvel incident est créé dans Jira. Cet événement est explicitement capturé lorsqu'un nouvel incident de type 'Incident' est enregistré dans le système.
Pourquoi c'est important

C'est l'event de démarrage principal pour le processus. L'analyse du temps entre cette activité et la résolution est fondamentale pour mesurer le temps de cycle global et le respect des SLA.

Où obtenir

Il s'agit d'un event explicite capturé à partir du timestamp 'created' du problème d'incident dans Jira. L'event de création du problème est enregistré dans l'historique du problème.

Capture

Utilisez l'horodatage de création de l'incident.

Type d'événement explicit
Incident réaffecté
Se produit lorsqu'un incident est transféré d'un agent ou d'un groupe à un autre après l'affectation initiale. Cet événement est déduit de tout changement dans le champ 'Assigné à' ou 'Groupe assigné'.
Pourquoi c'est important

Le suivi des réaffectations est crucial pour l'analyse des transferts (handoffs). Un nombre élevé de réaffectations indique souvent des inefficacités de processus, des lacunes de connaissances ou un routage initial incorrect, entraînant des retards de résolution.

Où obtenir

Déduit de l'historique de l'incident en détectant toute mise à jour du champ 'Assignee' après sa première population. Chaque modification constitue un événement de réaffectation.

Capture

Identifier les changements ultérieurs au champ 'Assigné' après l'affectation initiale.

Type d'événement inferred
Incident résolu
Cette activité marque la confirmation que l'incident a été résolu avec succès et que le service est rétabli. Elle coïncide souvent avec la transition vers le statut 'Résolu'.
Pourquoi c'est important

C'est la principale étape de succès dans le processus. La durée jusqu'à ce point est le KPI le plus courant, représentant le Temps de résolution (TTR).

Où obtenir

Déduit du changement de statut vers 'Resolved'. Dans de nombreux workflows, cet événement est le même que 'Resolution Proposed', représentant le point de résolution principal.

Capture

Identifier l'horodatage de la transition de statut vers 'Résolu'.

Type d'événement inferred
Résolution Proposée
Cette activité indique qu'une résolution a été identifiée et implémentée, et que l'incident est en attente de confirmation ou de validation finale. Elle est déduite de la transition de statut vers 'Résolu'.
Pourquoi c'est important

Il s'agit d'une étape majeure qui marque la fin du travail actif par l'équipe de support. C'est souvent l'event qui arrête le décompte du SLA.

Où obtenir

Déduit de l'historique des changements de statut de l'incident. Le timestamp de l'événement correspond au moment où le statut passe à 'Resolved' ou un état équivalent.

Capture

Identifier l'horodatage de la transition de statut vers 'Résolu'.

Type d'événement inferred
Client a répondu
Indique que le client a fourni les informations demandées et que l'incident peut progresser. Cela est déduit lorsque le statut passe de 'Waiting for customer' à un statut actif.
Pourquoi c'est important

Cette activité marque la fin d'un délai induit par le client. L'analyse de la durée entre 'En Attente du Client' et cet événement révèle le temps de réponse moyen du client.

Où obtenir

Déduit de l'historique des changements de statut de l'incident. L'événement se produit lorsque le statut passe de 'Waiting for customer' à un statut comme 'In Progress', souvent déclenché par l'ajout d'un commentaire par le client.

Capture

Détecte le changement de statut de 'Waiting for customer' à 'In Progress'.

Type d'événement inferred
Commentaire ajouté
Représente tout événement de communication ou de prise de notes où un utilisateur ajoute un commentaire au ticket d'incident. C'est un événement explicite capturé à chaque publication d'un commentaire.
Pourquoi c'est important

L'analyse de la fréquence des commentaires peut offrir un aperçu des modes de communication, de l'efficacité de la collaboration et de la complexité d'un incident. Elle permet de mettre en évidence les incidents nécessitant une communication excessive.

Où obtenir

Il s'agit d'un event explicite. Jira stocke chaque commentaire avec un timestamp et un auteur, disponibles via l'historique des commentaires du problème ou l'API.

Capture

Utilisez l'horodatage de chaque commentaire ajouté à l'incident.

Type d'événement explicit
Escaladé à l'équipe spécialisée
Signifie que l'incident a été escaladé à une équipe spécialisée (ex. : Niveau 2, Développement) pour un support avancé. Cela est inféré d'un changement dans un champ personnalisé 'Équipe de support' ou d'une réaffectation spécifique.
Pourquoi c'est important

Met en évidence les incidents nécessitant des connaissances spécialisées et suit le flux entre les différents niveaux de support. Cela aide à identifier les goulots d'étranglement au sein des équipes spécialisées et à analyser les schémas d'escalade.

Où obtenir

Déduit de l'historique de l'incident en suivant les modifications d'un champ personnalisé représentant l'équipe assignée ou en identifiant un changement d'assignataire ('Assignee') vers un membre d'un groupe spécialisé connu.

Capture

Détecte un changement dans un champ personnalisé pour 'Assigned Team' ou des modifications d'assignation spécifiques.

Type d'événement inferred
Incident assigné
Cette activité signifie l'assignation initiale de l'incident à un agent ou un groupe de support pour sa gestion. Elle est capturée en suivant la première fois que le champ 'Assignee' ou 'Groupe Assigné' est renseigné.
Pourquoi c'est important

Mesure le temps initial de réponse et d'affectation, un élément clé des métriques SLA. Cela aide à identifier les retards avant le début de l'enquête active.

Où obtenir

Déduit de l'historique de l'incident en identifiant le premier changement du champ 'Assignee' où la valeur précédente était 'Unassigned'.

Capture

Détecte la première mise à jour du champ 'Assignee' dans l'historique de l'incident.

Type d'événement inferred
Incident priorisé
Représente la définition de la priorité et/ou de la gravité de l'incident, qui dicte son urgence et son impact métier. Cela est généralement inféré de la première fois que les champs 'Priorité' ou 'Gravité' sont renseignés ou mis à jour après la création.
Pourquoi c'est important

Le suivi de la priorisation aide à analyser si les incidents sont évalués rapidement et de manière cohérente. Des retards à cette étape peuvent impacter directement les calculs de SLA et l'allocation des ressources.

Où obtenir

Déduit du journal d'historique de l'incident, qui suit les modifications de tous les champs. Rechercher la première mise à jour du champ 'Priority' ou d'un champ personnalisé 'Severity' après l'événement de création de l'incident.

Capture

Détecte le premier changement au champ 'Priority' dans l'historique de l'incident.

Type d'événement inferred
Incident rouvert
Représente une situation où un incident précédemment résolu est réactivé parce que le problème s'est reproduit ou que la solution était inefficace. Cela est inféré par un changement de statut de 'Résolu' ou 'Fermé' vers un statut ouvert.
Pourquoi c'est important

Les incidents rouverts sont une mesure directe de la qualité de la résolution et un indicateur principal de la reprise du travail. L'analyse de ces événements aide à identifier les clôtures prématurées et les solutions inefficaces.

Où obtenir

Déduit de l'historique des changements de statut de l'incident. L'événement est enregistré lorsque le statut passe d'un état terminal comme 'Resolved' ou 'Closed' à 'Open' ou 'In Progress'.

Capture

Détecte le changement de statut de 'Resolved' ou 'Closed' à un statut ouvert.

Type d'événement inferred
Lié au ticket de problème
Se produit lorsqu'un incident est lié à un problème pour l'analyse des causes profondes. Il s'agit d'un événement explicite capturé lorsqu'un lien 'est lié à' ou 'est causé par' est créé vers un type de problème.
Pourquoi c'est important

Le suivi de ce lien est essentiel pour comprendre l'efficacité avec laquelle l'organisation passe de l'atténuation des incidents à l'analyse des causes profondes et à la prévention.

Où obtenir

Il s'agit d'un event explicite enregistré dans l'historique des liens du problème. Chaque création de lien a un timestamp et peut être filtrée pour les liens vers le type de problème 'Problème'.

Capture

Utilisez l'horodatage de la création d'un lien vers un incident de type « Problème ».

Type d'événement explicit
Solution de contournement fournie
Représente la mise en œuvre d'une solution temporaire pour restaurer le service pendant le développement d'une solution permanente. Cela peut être inféré d'un changement de statut ou d'un commentaire spécifique.
Pourquoi c'est important

Mesurer le temps nécessaire pour fournir une solution de contournement est un indicateur clé de la vitesse de restauration du service. Cela aide à différencier une mitigation temporaire d'une résolution permanente.

Où obtenir

Cela est souvent inféré. Il pourrait s'agir d'une transition vers un statut 'Solution de contournement fournie' (Workaround Provided) ou de l'ajout d'un commentaire public contenant des mots-clés spécifiques comme 'solution de contournement'.

Capture

Identifier une transition de statut spécifique ou un mot-clé dans un commentaire.

Type d'événement inferred
Recommandé Facultatif

Guides d'extraction

Comment obtenir vos données depuis Jira Service Management