Votre modèle de données pour la gestion des incidents
Votre modèle de données pour la gestion des incidents
- Attributs recommandés à recueillir
- Activités clés à suivre
- Guide d’extraction pour Jira Service Management
Attributs de gestion des incidents
| Nom | Description | ||
|---|---|---|---|
|
Activité
ActivityName
|
Nom de l’événement ou du changement de statut survenu pour l’incident. | ||
|
Description
L’activité correspond à une étape ou à un événement distinct du cycle de vie de la gestion des incidents, comme « Incident créé », « Incident attribué » ou « Résolution proposée ». Elle est généralement déduite des changements de statut ou des mises à jour consignées dans l’historique ou le journal des modifications du ticket Jira. L’analyse de l’ordre et de la durée de ces activités est au cœur du Process Mining : elle révèle le déroulement réel du processus, ses goulots d’étranglement et ses écarts.
Pourquoi est-ce important ?
Les activités constituent la base de la cartographie du processus et permettent de visualiser et d’analyser le cycle de vie des incidents.
Où trouver ces données
Dérivé de l’historique et du journal des modifications du ticket Jira, cet attribut recense les changements de statut et les mises à jour des principaux champs.
Exemples
Incident assignéDébut de l’enquêteIncident résolu
|
|||
|
Heure de début
EventTimestamp
|
Date et heure exactes auxquelles l’activité a eu lieu. | ||
|
Description
Cet attribut enregistre l’horodatage de chaque activité du cycle de vie de l’incident. Il permet de calculer les durées, les temps de cycle et les temps d’attente entre les différentes étapes du processus. Des horodatages précis rendent possibles une analyse détaillée des performances, le suivi des SLA et l’identification des goulots d’étranglement. Toutes les métriques de performance, comme le délai de résolution et la durée du diagnostic, sont calculées à partir de ces horodatages.
Pourquoi est-ce important ?
Les horodatages sont indispensables au calcul des métriques temporelles, à l’analyse de la durée du processus et à la détection des goulots d’étranglement.
Où trouver ces données
Il s’agit de la date de création associée à chaque entrée de l’historique ou du journal des modifications du ticket Jira.
Exemples
2023-10-26T10:00:00Z2023-10-26T10:05:14Z2023-10-27T14:30:00Z
|
|||
|
Identifiant de l’incident
IncidentId
|
Identifiant unique de chaque ticket d’incident dans Jira Service Management. | ||
|
Description
L’identifiant de l’incident, souvent appelé clé de ticket dans Jira, est l’identifiant unique principal de chaque incident signalé. Il relie toutes les activités, tous les commentaires et tous les changements de statut associés, de la création à la clôture définitive. En Process Mining, cet identifiant est indispensable pour reconstituer le cycle de vie complet de chaque incident et analyser l’ensemble du processus.
Pourquoi est-ce important ?
Cet identifiant central permet de regrouper tous les événements associés dans un même dossier. Il constitue la base de toute analyse en Process Mining.
Où trouver ces données
Il s’agit du champ standard « Key » d’un ticket dans Jira Service Management (par exemple, « ITSM-123 »).
Exemples
INC-10234HELPDESK-5678OPS-9901
|
|||
|
Dernière mise à jour des données
LastDataUpdate
|
Horodatage de la dernière actualisation des données depuis le système source. | ||
|
Description
Cet attribut indique la date de la dernière mise à jour du jeu de données. Il permet aux personnes qui analysent le processus de savoir si les données sont récentes. C’est particulièrement important pour les Dashboards de suivi continu, qui nécessitent des informations à jour pour prendre des décisions en temps utile. En général, cette valeur est identique pour tous les événements d’un même lot d’extraction.
Pourquoi est-ce important ?
Indique si les données sont à jour, un élément important pour garantir la pertinence et la précision de l’analyse.
Où trouver ces données
Il s’agit de l’horodatage de l’extraction des données, ajouté lors de leur transformation.
Exemples
2023-10-27T08:00:00Z2023-10-28T08:00:00Z
|
|||
|
Système source
SourceSystem
|
Système d’où proviennent les données extraites. | ||
|
Description
Cet attribut indique l’origine des données, ici Jira Service Management. Il est particulièrement utile lorsque l’analyse combine des données issues de plusieurs systèmes. La précision du système source garantit la traçabilité des données et facilite le diagnostic des problèmes de qualité ou d’extraction. Dans ce modèle, la valeur est fixe.
Pourquoi est-ce important ?
Cet attribut précise l’origine des données et en garantit la traçabilité, notamment lors d’analyses portant sur plusieurs systèmes.
Où trouver ces données
Cette valeur fixe doit être ajoutée lors de l’extraction des données.
Exemples
Jira Service ManagementJira Cloud
|
|||
|
Date de création
CreatedDate
|
Date et heure de 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. Il fournit l’horodatage de référence pour calculer les métriques globales, comme le délai total de résolution. La date de création reste fixe pour chaque incident et sert de point de départ à l’analyse de l’ensemble du dossier en Process Mining.
Pourquoi est-ce important ?
Sert de point de départ au calcul des temps de cycle de bout en bout et au suivi des SLA.
Où trouver ces données
Champ standard « Created » d’un ticket Jira.
Exemples
2023-10-26T09:58:12Z2023-11-01T15:20:05Z
|
|||
|
Date de résolution
ResolutionDate
|
Date et heure auxquelles l’incident a été marqué comme résolu. | ||
|
Description
Cet attribut enregistre l’horodatage du premier passage de l’incident à un statut de résolution. Il marque la fin de la phase de traitement actif et sert de point final au calcul du délai de résolution. La comparaison entre la date de résolution et la date de création fournit la principale mesure de l’efficacité du processus. Elle contribue également à déterminer le respect des SLA.
Pourquoi est-ce important ?
Marque la fin du processus de résolution et permet de calculer le temps de cycle total ainsi que les performances des SLA.
Où trouver ces données
Champ standard « Resolved » d’un ticket Jira.
Exemples
2023-10-28T11:20:30Z2023-11-02T10:00:00Z
|
|||
|
Groupe d’affectation
AssignmentGroup
|
Équipe ou groupe chargé du traitement de l’incident. | ||
|
Description
Le groupe d’affectation désigne l’équipe chargée de l’incident. Il peut s’agir d’un niveau d’assistance, comme « Assistance niveau 1 », d’une équipe spécialisée, comme « Exploitation réseau », ou d’une équipe de développement. L’analyse des changements de groupe d’affectation permet de comprendre les escalades et les transferts dans le processus. Elle sert à mesurer les performances des équipes, à repérer les goulots d’étranglement à leur niveau et à analyser les dépendances entre équipes.
Pourquoi est-ce important ?
Indispensable pour analyser les performances des équipes, le volume de traitement et la circulation du travail entre les différents niveaux d’assistance ou groupes spécialisés.
Où trouver ces données
Ce champ personnalisé dans Jira est souvent nommé « Team » ou « Assignment Group ». Il peut parfois être déduit des composants Jira ou des rôles du projet.
Exemples
Assistance niveau 1Équipe infrastructureAdministrateurs de bases de données
|
|||
|
Priorité
Priority
|
Niveau de priorité attribué à l’incident, qui indique le degré d’urgence de sa résolution. | ||
|
Description
La priorité détermine la rapidité avec laquelle un incident doit être traité. Elle combine souvent l’impact et l’urgence et influe directement sur les objectifs de SLA. L’analyse des incidents par priorité permet de vérifier si les incidents prioritaires sont traités plus rapidement que les autres et si les règles de priorisation sont appliquées de façon cohérente. C’est un critère essentiel pour filtrer et comparer les performances du processus.
Pourquoi est-ce important ?
Indispensable à l’analyse des performances des SLA et à la vérification de l’affectation des ressources aux incidents les plus importants.
Où trouver ces données
Champ standard « Priority » d’un ticket Jira.
Exemples
La plus élevéeÉlevéeMoyenneFaible
|
|||
|
Responsable
Assignee
|
Utilisateur actuellement chargé du traitement de l’incident. | ||
|
Description
Le responsable est l’agent ou l’utilisateur chargé de l’incident à un moment donné. Le suivi des changements de responsable permet d’analyser les transferts, de comprendre la répartition de la charge de travail et de déterminer qui intervient à chaque étape du processus. Cet attribut aide à répondre aux questions sur les performances individuelles et l’affectation des ressources au sein des équipes d’assistance.
Pourquoi est-ce important ?
Permet de suivre la charge de travail de chacun, de repérer les goulots d’étranglement liés à certains agents et d’analyser l’effet des transferts sur le délai de résolution.
Où trouver ces données
Champ standard « Assignee » d’un ticket Jira.
Exemples
John SmithEmily JonesAgentAssistance1
|
|||
|
Statut
Status
|
Étape actuelle du cycle de vie de l’incident. | ||
|
Description
Le champ de statut indique l’état actuel de l’incident dans le flux de travail défini, par exemple « Open », « In Progress », « Pending Customer » ou « Resolved ». Les changements de statut constituent la principale source utilisée pour générer le journal d’activités en Process Mining. L’analyse du temps passé dans chaque statut est essentielle pour repérer les goulots d’étranglement et comprendre à quelles étapes les incidents prennent le plus de temps.
Pourquoi est-ce important ?
Reflète directement l’avancement de l’incident et constitue la principale source pour repérer les étapes du processus et les temps d’attente.
Où trouver ces données
Champ standard « Status » d’un ticket Jira.
Exemples
En coursEn attente du clientRésoluFermé
|
|||
|
Catégorie de cause profonde
RootCauseCategory
|
Classification de la cause profonde de l’incident. | ||
|
Description
Cet attribut indique la raison fondamentale de l’incident, par exemple « Défaut logiciel », « Panne matérielle » ou « Erreur utilisateur ». Il est généralement renseigné après l’investigation et joue un rôle essentiel dans la gestion des problèmes et la prévention de futurs incidents. L’analyse des catégories de causes profondes permet de repérer les faiblesses systémiques et de définir les priorités d’amélioration. Une forte proportion de causes profondes « Inconnues » peut signaler la nécessité d’améliorer les procédures d’investigation.
Pourquoi est-ce important ?
Permet d’analyser les causes profondes et de passer d’une approche réactive à une approche préventive, en repérant et en traitant les sources des incidents.
Où trouver ces données
Il s’agit presque toujours d’un champ personnalisé dans Jira. Son nom et ses options dépendent fortement de la configuration propre à l’organisation.
Exemples
Erreur de configurationPanne réseauAnomalie logicielle
|
|||
|
Comporte des reprises
IsRework
|
Indique si l’incident a fait l’objet de reprises, par exemple s’il a été rouvert. | ||
|
Description
Cet attribut booléen calculé identifie les incidents renvoyés à une étape antérieure du processus, le plus souvent parce qu’ils ont été rouverts après leur résolution. Les boucles de reprise sont une source importante d’inefficacité et d’insatisfaction des clients. Cet indicateur permet de calculer facilement le taux de reprises et d’orienter l’analyse vers les raisons pour lesquelles les incidents ne sont pas résolus correctement dès la première fois.
Pourquoi est-ce important ?
Met en évidence les problèmes de qualité et les inefficacités du processus en signalant les incidents qui nécessitent des reprises, ce qui facilite directement leur analyse.
Où trouver ces données
Calculé en détectant des séquences précises de changements de statut dans le journal d’événements, par exemple « Resolved » -> « Reopened ».
Exemples
truefalse
|
|||
|
Composant
Component
|
Système, application ou partie de l’infrastructure touché par l’incident. | ||
|
Description
Les composants sont des sous-parties d’un projet Jira qui servent à regrouper les tickets, par exemple « Interface utilisateur », « Base de données » ou « API ». L’analyse des incidents par composant permet de repérer les parties d’un système les plus sujettes aux problèmes. Ces informations sont utiles à l’analyse des causes profondes et peuvent orienter les efforts d’amélioration du service ou de réduction de la dette technique.
Pourquoi est-ce important ?
Permet de filtrer et d’analyser les incidents selon le produit ou la partie du système touché, afin de repérer les points sensibles de l’environnement technologique.
Où trouver ces données
Champ standard « Components » d’un ticket Jira.
Exemples
Service d’authentificationDashboard de reportingApplication mobile
|
|||
|
Déclarant
Reporter
|
Utilisateur ayant créé ou signalé l’incident initialement. | ||
|
Description
Le déclarant est la personne, souvent un utilisateur final, ou un autre système qui a signalé l’incident en premier. L’analyse des incidents par déclarant peut aider à repérer les utilisateurs ou les services qui rencontrent fréquemment des problèmes. Elle permet aussi d’étudier les échanges, notamment lors d’activités comme « En attente du client » et « Réponse du client reçue ».
Pourquoi est-ce important ?
Permet d’analyser l’origine des incidents, de repérer les tendances liées à certains utilisateurs ou services et de comprendre les délais de réponse des clients.
Où trouver ces données
Champ standard « Reporter » d’un ticket Jira.
Exemples
Alice JohnsonBob Williamsmonitoring-tool@example.com
|
|||
|
Délai cible de résolution
TimeToResolutionTarget
|
Durée cible du SLA pour résoudre l’incident. | ||
|
Description
Cet attribut définit le délai maximal prévu pour résoudre un incident d’une priorité ou d’un type donné. Il sert de référence pour comparer le délai de résolution réel et déterminer si le SLA est respecté. Cette valeur est généralement définie de façon dynamique selon des règles qui tiennent compte de facteurs comme la priorité, la gravité ou le type de ticket. Elle est indispensable au suivi des performances des SLA dans un Dashboard.
Pourquoi est-ce important ?
Fournit la référence nécessaire pour mesurer le respect des SLA et calculer l’indicateur de taux de dépassement des SLA pour les incidents.
Où trouver ces données
Cette valeur est définie dans la configuration des SLA de Jira Service Management. Il faut identifier l’objectif concerné, par exemple « Délai de résolution ».
Exemples
4 h8 h3 j
|
|||
|
Dépassement du SLA
SlaBreach
|
Indique si le délai de résolution de l’incident a dépassé l’objectif du SLA. | ||
|
Description
Cet attribut booléen calculé indique si le délai de résolution de l’incident a dépassé le SLA « Délai de résolution ». Il vaut vrai si « IncidentResolutionCycleTime » est supérieur à « TimeToResolutionTarget ». Ce marqueur simplifie l’analyse et la visualisation : il permet de filtrer et d’agréger facilement les données pour calculer le taux global de dépassement des SLA. C’est la mesure de résultat principale du Dashboard de suivi des performances des SLA.
Pourquoi est-ce important ?
Fournit un résultat binaire clair pour évaluer les performances des SLA, calculer facilement les taux de dépassement et repérer les problèmes.
Où trouver ces données
Calculé comme suit : (« IncidentResolutionCycleTime » > « TimeToResolutionTarget »).
Exemples
truefalse
|
|||
|
Gravité
Severity
|
Mesure de l’impact de l’incident sur l’activité. | ||
|
Description
La gravité indique l’ampleur de l’impact d’un incident sur l’activité, depuis le problème touchant un seul utilisateur jusqu’à l’interruption d’un système critique. La priorité détermine l’ordre de traitement, tandis que la gravité renseigne sur l’impact global pour l’organisation. L’analyse par niveau de gravité permet d’évaluer le traitement des incidents les plus importants pour l’activité. Elle est souvent combinée à la priorité pour affiner l’analyse.
Pourquoi est-ce important ?
Donne une vision de l’impact sur l’activité et permet de centrer l’analyse sur les incidents qui perturbent le plus les opérations.
Où trouver ces données
Il s’agit généralement d’un champ personnalisé dans Jira, car il ne fait pas partie des champs standard du système. Consultez la configuration du projet Jira Service Management.
Exemples
CritiqueMajeureMineureNégligeable
|
|||
|
Identifiant du problème associé
LinkedProblemId
|
Identifiant du ticket de problème associé à cet incident. | ||
|
Description
Les incidents qui sont les symptômes d’un problème sous-jacent plus vaste sont souvent associés à un ticket de problème. Ce champ contient l’identifiant du problème correspondant. L’analyse de ces liens aide à comprendre les relations entre incidents et problèmes, à mesurer l’efficacité du processus de gestion des problèmes et à repérer les incidents récurrents qui nécessitent un correctif définitif.
Pourquoi est-ce important ?
Relie les incidents aux problèmes sous-jacents et permet d’analyser l’efficacité avec laquelle l’organisation traite les causes profondes pour prévenir de futurs incidents.
Où trouver ces données
Ces informations figurent dans la section « Issue Links » d’un ticket Jira.
Exemples
PROB-123PROB-456Aucun
|
|||
|
Nombre de transferts
HandoffCount
|
Nombre de réattributions de l’incident à un autre groupe ou utilisateur. | ||
|
Description
Cette métrique calculée compte le nombre de changements des champs « Assignee » ou « AssignmentGroup » au cours du cycle de vie de l’incident. Un nombre élevé de transferts peut révéler un processus inefficace, un faible taux de résolution dès le premier contact ou des lacunes dans les connaissances, et entraîner des délais de résolution plus longs. L’analyse de cet indicateur aide à améliorer le processus d’attribution et la collaboration entre les équipes.
Pourquoi est-ce important ?
Mesure les frictions et les inefficacités liées aux réattributions et aide à repérer les possibilités d’amélioration du processus.
Où trouver ces données
Calculé en comptant le nombre de modifications apportées au champ « Assignee » ou « AssignmentGroup » dans l’historique des modifications du ticket.
Exemples
015
|
|||
|
Résolution
Resolution
|
Résultat final ou motif de résolution de l’incident. | ||
|
Description
Le champ de résolution précise pourquoi un incident a été marqué comme résolu. Les valeurs courantes sont « Fixed », « Duplicate », « Won’t Do » ou « Cannot Reproduce ». L’analyse de la répartition des types de résolution renseigne sur la qualité des signalements et l’efficacité du processus de résolution. Par exemple, un grand nombre de résolutions « Duplicate » peut révéler un problème lors de la création ou du triage des incidents.
Pourquoi est-ce important ?
Précise l’issue de l’incident, aide à catégoriser les résolutions et fait ressortir les tendances dans la clôture des incidents.
Où trouver ces données
Champ standard « Resolution » d’un ticket Jira. Il est généralement renseigné lorsque le ticket passe dans une catégorie de statut « Done ».
Exemples
TerminéCorrigéDoublonNe sera pas corrigé
|
|||
|
Type de demande du client
CustomerRequestType
|
Type précis de demande envoyée par le client via le portail de services. | ||
|
Description
Ce champ classe les demandes du point de vue du client, telles qu’elles sont présentées sur le portail Jira Service Management (par exemple, « Signaler un problème système »). Il propose une catégorisation compréhensible par les utilisateurs, qui peut différer du type de ticket interne. Son analyse permet de mieux comprendre la façon dont les clients perçoivent et signalent les problèmes, et d’améliorer la conception du portail et les services proposés.
Pourquoi est-ce important ?
Présente les catégories d’incidents du point de vue du client, ce qui aide à analyser la demande et à améliorer son expérience.
Où trouver ces données
Champ « Customer Request Type », propre aux projets Jira Service Management.
Exemples
Obtenir de l’aide informatique > Signaler un problème systèmeE-mail > Demande d’accès
|
|||
|
Type de ticket
IssueType
|
Type de ticket, par exemple incident, demande de service ou problème. | ||
|
Description
Jira utilise les types de ticket pour distinguer les différentes catégories de tâches. Dans le cadre de la gestion des incidents, le type principal est « Incident », mais d’autres types, comme « Sous-tâche », peuvent aussi être pertinents. Cet attribut permet de filtrer le jeu de données pour ne conserver que les incidents et de centrer l’analyse en Process Mining sur le bon processus.
Pourquoi est-ce important ?
Permet de limiter l’analyse aux incidents et de les distinguer des autres types de travail, comme les demandes de service ou les changements.
Où trouver ces données
Champ standard « Issue Type » d’un ticket Jira.
Exemples
IncidentAssistance informatiqueAnomalie
|
|||
Activités de gestion des incidents
| Activité | Description | ||
|---|---|---|---|
|
Début de l’enquête
|
Indique qu’un agent assigné a commencé à diagnostiquer activement l’incident. Cette étape est généralement déduite du passage du ticket d’incident de l’état « Open » ou « New » à « In Progress ». | ||
|
Pourquoi est-ce important ?
Cette étape importante marque le début des efforts actifs de résolution. Mesurer le délai qui la précède aide à repérer les retards initiaux dans les files d’attente et les problèmes de disponibilité des ressources.
Où trouver ces données
Cette étape est déduite de l’historique des changements d’état du ticket. L’horodatage de l’événement correspond au passage à un état indiquant que le travail a commencé, par exemple « In Progress ».
Données à recueillir
Repérez l’horodatage du passage à l’état « In Progress ».
Type d’événement
inferred
|
|||
|
En attente du client
|
Indique que l’équipe d’assistance attend une information ou une action du client. Cet événement est déduit du passage à un état d’attente dédié, tel que « Waiting for customer ». | ||
|
Pourquoi est-ce important ?
Il est essentiel d’isoler cette période de suspension pour mesurer précisément les SLA, car elle est souvent exclue du calcul du délai de résolution. Cela permet d’analyser les retards de réponse des clients.
Où trouver ces données
Cet événement est déduit de l’historique des changements d’état du ticket. Son horodatage correspond au passage à l’état « Waiting for customer » ou à un état similaire.
Données à recueillir
Repérez l’horodatage du passage à l’état « Waiting for customer ».
Type d’événement
inferred
|
|||
|
Incident clôturé
|
Correspond à la clôture administrative définitive du ticket d’incident, après résolution et vérification. Cet événement est déduit du passage à l’état « Closed ». | ||
|
Pourquoi est-ce important ?
Il s’agit de l’événement final du processus. L’analyse du délai entre « Resolved » et « Closed » peut révéler des retards dans les tâches administratives de clôture ou dans la confirmation par l’utilisateur.
Où trouver ces données
Déduit de l’historique des changements de statut du ticket. L’événement correspond à l’horodatage du passage au statut final « Closed ».
Données à recueillir
Repérez l’horodatage du passage au statut « Closed ».
Type d’événement
inferred
|
|||
|
Incident créé
|
Marque le début officiel du cycle de vie de l’incident, lorsqu’un signalement est soumis et qu’un nouveau ticket est créé dans Jira. Cet événement est enregistré explicitement à la création d’un nouveau ticket de type « Incident » dans le système. | ||
|
Pourquoi est-ce important ?
Il s’agit de l’événement de début principal du processus. Analyser le délai entre cette activité et la résolution est essentiel pour mesurer le temps de cycle global et le respect des SLA.
Où trouver ces données
Cet événement explicite est extrait de l’horodatage de création du ticket d’incident dans Jira. La création du ticket est consignée dans son historique.
Données à recueillir
Utilisez l’horodatage de création du ticket.
Type d’événement
explicit
|
|||
|
Incident réassigné
|
Cet événement survient lorsqu’un incident est transféré à un autre agent ou groupe après son assignation initiale. Il est déduit de toute modification du champ « Assignee » ou « Assigned Group ». | ||
|
Pourquoi est-ce important ?
Le suivi des réassignations est essentiel pour analyser les transferts. Un nombre élevé de réassignations révèle souvent des inefficacités dans le processus, des lacunes dans les connaissances ou une mauvaise orientation initiale, qui retardent la résolution.
Où trouver ces données
Cet événement est déduit de l’historique du ticket en repérant toute mise à jour du champ « Assignee » après son premier renseignement. Chaque modification constitue un événement de réassignation.
Données à recueillir
Repérez les modifications ultérieures du champ « Assignee » après l’assignation initiale.
Type d’événement
inferred
|
|||
|
Incident résolu
|
Cette activité confirme que l’incident a été résolu et que le service est rétabli. Elle coïncide souvent avec le passage à l’état « Resolved ». | ||
|
Pourquoi est-ce important ?
Il s’agit de la principale étape de réussite du processus. Le délai jusqu’à cette étape est l’indicateur clé le plus courant : le délai de résolution (TTR).
Où trouver ces données
Cet événement est déduit du passage à l’état « Resolved ». Dans de nombreux flux de travail, il correspond à l’événement « Résolution proposée » et marque le point principal de résolution.
Données à recueillir
Repérez l’horodatage du passage à l’état « Resolved ».
Type d’événement
inferred
|
|||
|
Résolution proposée
|
Cette activité indique qu’une solution a été trouvée et mise en œuvre, et que l’incident attend une confirmation ou une validation finale. Elle est déduite du passage à l’état « Resolved ». | ||
|
Pourquoi est-ce important ?
Cette étape importante marque la fin du travail actif de l’équipe d’assistance. C’est souvent à ce moment que le décompte du SLA s’arrête.
Où trouver ces données
Cet événement est déduit de l’historique des changements d’état du ticket. Son horodatage correspond au passage à l’état « Resolved » ou à un état équivalent.
Données à recueillir
Repérez l’horodatage du passage à l’état « Resolved ».
Type d’événement
inferred
|
|||
|
Commentaire ajouté
|
Correspond à toute communication ou prise de notes lorsqu’un utilisateur ajoute un commentaire au ticket d’incident. Cet événement explicite est enregistré à chaque publication d’un commentaire. | ||
|
Pourquoi est-ce important ?
L’analyse de la fréquence des commentaires peut éclairer les pratiques de communication, l’efficacité de la collaboration et la complexité des incidents. Elle peut aussi mettre en évidence les incidents qui nécessitent trop d’échanges.
Où trouver ces données
Il s’agit d’un événement explicite. Jira conserve chaque commentaire avec son horodatage et son auteur, dans l’historique des commentaires du ticket ou via l’API.
Données à recueillir
Utilisez l’horodatage de chaque commentaire ajouté au ticket.
Type d’événement
explicit
|
|||
|
Incident assigné
|
Cette activité correspond à l’assignation initiale de l’incident à un agent ou à un groupe d’assistance. Elle est enregistrée en repérant la première fois où le champ « Assignee » ou « Assigned Group » est renseigné. | ||
|
Pourquoi est-ce important ?
Cette mesure porte sur le délai de première réponse et d’assignation, qui constitue un élément important des indicateurs SLA. Elle aide à repérer les retards avant le début de l’enquête.
Où trouver ces données
Cette étape est déduite de l’historique du ticket en repérant la première modification du champ « Assignee » dont la valeur précédente était « Unassigned ».
Données à recueillir
Repérez la première mise à jour du champ « Assignee » dans l’historique du ticket.
Type d’événement
inferred
|
|||
|
Incident priorisé
|
Correspond à la définition de la priorité ou de la gravité de l’incident, qui détermine son urgence et son impact sur l’activité. Cette étape est généralement déduite du premier renseignement ou de la première mise à jour des champs « Priority » ou « Severity » après la création du ticket. | ||
|
Pourquoi est-ce important ?
Le suivi de la priorisation permet de vérifier si les incidents sont évalués rapidement et de manière cohérente. Un retard à cette étape peut avoir des conséquences directes sur le calcul des SLA et la répartition des ressources.
Où trouver ces données
Cette étape est déduite de l’historique du ticket, qui consigne les modifications de tous les champs. Recherchez la première mise à jour du champ « Priority » ou d’un champ personnalisé « Severity » après la création du ticket.
Données à recueillir
Repérez la première modification du champ « Priority » dans l’historique du ticket.
Type d’événement
inferred
|
|||
|
Incident rouvert
|
Correspond à la réactivation d’un incident précédemment résolu, parce que le problème s’est reproduit ou que la correction était inefficace. Cet événement est déduit du passage de l’état « Resolved » ou « Closed » à un état ouvert. | ||
|
Pourquoi est-ce important ?
Les incidents rouverts mesurent directement la qualité de la résolution et constituent un indicateur majeur des reprises. Leur analyse aide à repérer les clôtures prématurées et les solutions inefficaces.
Où trouver ces données
Cet événement est déduit de l’historique des changements d’état du ticket. Il est consigné lorsque le ticket passe d’un état final, tel que « Resolved » ou « Closed », à « Open » ou « In Progress ».
Données à recueillir
Repérez le passage de l’état « Resolved » ou « Closed » à un état ouvert.
Type d’événement
inferred
|
|||
|
Lié à un ticket de problème
|
Cet événement survient lorsqu’un incident est lié à un ticket de type « Problem » pour analyser sa cause première. Il est enregistré explicitement à la création d’un lien « relates to » ou « caused by » vers un ticket de type « Problem ». | ||
|
Pourquoi est-ce important ?
Le suivi de ce lien est essentiel pour comprendre dans quelle mesure l’organisation passe efficacement de l’atténuation de l’incident à l’analyse des causes premières et à la prévention.
Où trouver ces données
Il s’agit d’un événement explicite consigné dans l’historique des liens du ticket. Chaque création de lien est horodatée et peut être filtrée pour les liens vers des tickets de type « Problem ».
Données à recueillir
Utilisez l’horodatage de création d’un lien vers un ticket de type « Problem ».
Type d’événement
explicit
|
|||
|
Réponse du client reçue
|
Indique que le client a fourni les informations demandées et que l’incident peut être traité à nouveau. Cet événement est déduit du passage de l’état « Waiting for customer » à un état actif. | ||
|
Pourquoi est-ce important ?
Cette activité marque la fin d’un délai imputable au client. L’analyse du temps écoulé entre « En attente du client » et cet événement révèle le délai moyen de réponse des clients.
Où trouver ces données
Cet événement est déduit de l’historique des changements d’état du ticket. Il survient lorsque le ticket passe de « Waiting for customer » à un état tel que « In Progress », souvent après l’ajout d’un commentaire par le client.
Données à recueillir
Repérez le passage de l’état « Waiting for customer » à « In Progress ».
Type d’événement
inferred
|
|||
|
Solution de contournement fournie
|
Correspond à la mise en place d’une solution temporaire pour rétablir le service pendant l’élaboration d’une solution définitive. Cet événement peut être déduit d’un changement d’état ou d’un commentaire précis. | ||
|
Pourquoi est-ce important ?
Le délai de mise en place d’une solution de contournement est un indicateur clé de la rapidité de rétablissement du service. Il permet de distinguer une mesure temporaire d’atténuation d’une résolution définitive.
Où trouver ces données
Cet événement est souvent déduit. Il peut correspondre au passage à l’état « Workaround Provided » ou à l’ajout d’un commentaire public contenant des mots-clés précis, comme « workaround ».
Données à recueillir
Repérez un changement d’état précis ou un mot-clé dans un commentaire.
Type d’événement
inferred
|
|||
|
Transféré à une équipe spécialisée
|
Indique que l’incident a été transmis à une équipe spécialisée, par exemple l’assistance de niveau 2 ou l’équipe de développement, pour une prise en charge avancée. Cet événement est déduit d’une modification du champ personnalisé « Support Team » ou d’une réassignation précise. | ||
|
Pourquoi est-ce important ?
Cet indicateur met en évidence les incidents qui nécessitent des compétences spécialisées et suit les transferts entre les différents niveaux d’assistance. Il aide à repérer les goulots d’étranglement au sein des équipes spécialisées et à analyser les pratiques d’escalade.
Où trouver ces données
Cet événement est déduit de l’historique du ticket en suivant les modifications d’un champ personnalisé qui indique l’équipe assignée, ou en repérant une modification du champ « Assignee » vers un membre d’une équipe spécialisée connue.
Données à recueillir
Repérez une modification du champ personnalisé « Assigned Team » ou une modification précise du champ « Assignee ».
Type d’événement
inferred
|
|||
Guides d’extraction
Prêt à commencer ?
Utilisez ce modèle de données pour améliorer la gestion de vos incidents, repérer les inefficacités et réduire les délais de résolution. Commencez dès aujourd’hui à optimiser votre processus.
Optimisez la gestion des incidents et résolvez-les plus rapidement
Réduisez le MTTR de 35 % et améliorez la satisfaction des utilisateurs grâce à des processus optimisés.
Aucune carte bancaire requise • Configuration en 5 minutes