Votre modèle de données de gestion des incidents
Votre modèle de données de gestion des incidents
- Attributs recommandés à collecter
- Activités clés à suivre
- Guide d'extraction pour Jira Service Management
Attributs de gestion des incidents
| Nom | Descriptionn | ||
|---|---|---|---|
|
Activité
ActivityName
|
Le nom de l'événement ou du changement de statut spécifique survenu pour l'incident. | ||
|
Descriptionn
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 points de blocage et les écarts.
Pourquoi est-ce important ? :
Les activités constituent l'pilier central de la cartographie des processus, pour visualiser et l'analyse du cycle de vie des incidents.
Source des données :
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é. | ||
|
Descriptionn
Cet attribut enregistre l'horodatage pour chaque activité du cycle de vie de l'incident. Il est impératif pour le calcul des durées, des temps de cycle et des temps d'attente entre les différentes étapes du processus. Des horodatages précis permettent une analyse détaillée des performances, le suivi des SLA et l'identification des points de blocage. 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 horodatages.
Pourquoi est-ce important ? :
Les horodatages sont essentiels pour calculer toutes les métriques temporelles, comprendre la durée des processus et identifier les points de blocage de performance.
Source des données :
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 d'incident
IncidentId
|
L'identifiant unique pour chaque ticket d'incident dans Jira Service Management. | ||
|
Descriptionn
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 indispensable pour reconstituer le cycle de vie complet de chaque incident individuel, permettant une analyse complète de l'ensemble du processus.
Pourquoi est-ce important ? :
C'est l'identifiant principal utilisé pour corréler tous les événements liés en un seul dossier, constituant le fondement de toute analyse Process Mining.
Source des données :
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
|
L'horodatage indiquant la dernière fois que les données ont été actualisées à partir du système source. | ||
|
Descriptionn
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 la réactualisation 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 événements au sein d'un même lot d'extraction de données.
Pourquoi est-ce important ? :
Informe les utilisateurs de la réactualisation des données, ce qui est impératif pour la pertinence et la précision de l'analyse.
Source des données :
Il s'agit du horodatage 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. | ||
|
Descriptionn
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 d'ensemble complète des processus. Spécifier le système source assure la clarté de la traçabilité 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 est-ce important ? :
Offre un contexte essentiel sur l'origine des données, garantissant clarté et traçabilité, surtout dans les analyses multi-systèmes.
Source des données :
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. | ||
|
Descriptionn
Cet attribut marque le début officiel du cycle de vie de l'incident. C'est l'horodatage 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 cas dans l'analyse Process Mining.
Pourquoi est-ce important ? :
Sert de point de départ pour tous les calculs de temps de cycle complet et les mesures de SLA.
Source des données :
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. | ||
|
Descriptionn
Cet attribut enregistre l'horodatage 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'efficacité du processus. C'est également un composant clé pour déterminer la conformité aux SLA.
Pourquoi est-ce important ? :
Marque la fin du processus de résolution, permettant le calcul du temps de cycle total et de la performance SLA.
Source des données :
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. | ||
|
Descriptionn
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 indispensablele pour comprendre les escalades de processus et les transferts. Elle permet de mesurer la performance de l'équipe, d'identifier les points de blocage au niveau de l'équipe et d'analyser les dépendances inter-équipes.
Pourquoi est-ce important ? :
Primordial 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.
Source des données :
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. | ||
|
Descriptionn
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é « what-if » la priorisation est appliquée de manière cohérente. C'est une dimension majeure pour filtrer et comparer la performance des processus.
Pourquoi est-ce important ? :
Primordial pour l'analyse de la performance des SLA et la vérification de la bonne allocation des ressources aux incidents les plus critiques.
Source des données :
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. | ||
|
Descriptionn
Le Responsable est l'agent ou l'utilisateur individuel en charge de l'incident à un moment donné. Le suivi des changements d'assignation est impératif 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 danss équipes de support.
Pourquoi est-ce important ? :
Aide à suivre la charge de travail individuelle, à identifier les points de blocage liés à des agents spécifiques, et à analyser l'impact des transferts sur le temps de résolution.
Source des données :
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. | ||
|
Descriptionn
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 clée pour identifier les points de blocage et comprendre où les incidents passent le plus de temps.
Pourquoi est-ce 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.
Source des données :
Le champ standard 'Statut' d'un ticket Jira.
Exemples
En coursEn attente du clientRésoluClôturé
|
|||
|
Catégorie de cause profonde
RootCauseCategory
|
La classification de la cause première sous-jacente de l'incident. | ||
|
Descriptionn
Cet attribut saisit la raison clée 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 indispensable 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 est-ce important ? :
Facilite l'analyse des causes profondes, contribuant à passer d'une approche réactive à proactive en identifiant et en traitant les sources des incidents.
Source des données :
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. | ||
|
Descriptionn
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 est-ce 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.
Source des données :
Le champ standard 'Composants' d'un ticket Jira.
Exemples
Service d'authentificationTableau de Bord de RapportsApplication mobile
|
|||
|
Déclarant
Reporter
|
L'utilisateur qui a initialement créé ou signalé l'incident. | ||
|
Descriptionn
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 est-ce 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.
Source des données :
Le champ standard 'Déclarant' d'un ticket Jira.
Exemples
Alice JohnsonBob Williamsmonitoring-tool@example.com
|
|||
|
Est un reprises
IsRework
|
Un indicateur signalant si l'incident a fait l'objet d'une reprise, telle que sa réouverture. | ||
|
Descriptionn
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 (boucles de reprises) 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 est-ce 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.
Source des données :
Calculé en détectant des séquences spécifiques de transitions de statut dans l'Journal d'événements, telles que 'Resolved' -> 'Reopened'.
Exemples
truefaux
|
|||
|
Gravité
Severity
|
La mesure de l'impact métier de l'incident. | ||
|
Descriptionn
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 précise.
Pourquoi est-ce 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.
Source des données :
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. | ||
|
Descriptionn
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 est-ce 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.
Source des données :
Ces informationsns sont stockées dans la section 'Liens d'incident' (Issue Links) d'un problème Jira.
Exemples
PROB-123PROB-456Aucun
|
|||
|
Manquement au SLA
SlaBreach
|
Un indicateur précisant si le temps de résolution de l'incident a dépassé l'objectif de SLA. | ||
|
Descriptionn
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 tableau de bord de suivi de la performance des SLA.
Pourquoi est-ce 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.
Source des données :
Calculé comme ('IncidentResolutionCycleTime' > 'TimeToResolutionTarget').
Exemples
truefaux
|
|||
|
Nombre de transferts
HandoffCount
|
Le nombre de fois où l'incident a été réassigné à un groupe ou un utilisateur différent. | ||
|
Descriptionn
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 est-ce 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.
Source des données :
Calculé en comptant le nombre de modifications apportées aux champs 'Assignee' ou 'AssignmentGroup' dans l'historique des modifications de l'incident.
Exemples
015
|
|||
|
Objectif de Temps de Résolution
TimeToResolutionTarget
|
La durée cible de SLA pour la résolution de l'incident. | ||
|
Descriptionn
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 clée pour tout tableau de bord de suivi de la performance des SLA.
Pourquoi est-ce 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.
Source des données :
Ceci est dérivé de la configuration SLA dans 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. | ||
|
Descriptionn
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 est-ce 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.
Source des données :
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. | ||
|
Descriptionn
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 impératif 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 est-ce 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.
Source des données :
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. | ||
|
Descriptionn
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 « what-if »gnalent les problèmes, contribuant à améliorer la conception du portail et les offres de services.
Pourquoi est-ce important ? :
Offre une vision orientée client des catégories d'incidents, utile pour analyser la demande et améliorer l'expérience client.
Source des données :
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
|
|||
Activités de gestion des incidents
| Activité | Descriptionn | ||
|---|---|---|---|
|
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 est-ce important ? :
L'isolation de ce temps de 'on-hold' est indispensablele 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.
Source des données :
Déduit de l'historique des changements de statut de l'incident. L'événement correspond au horodatage 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 est-ce 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.
Source des données :
Déduit de l'historique des changements de statut de l'incident. L'horodatage 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 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 est-ce important ? :
C'est l'event de démarrage principal pour le processus. L'analyse du temps entre cette activité et la résolution est clée pour mesurer le temps de cycle global et le respect des SLA.
Source des données :
Il s'agit d'un event explicite capturé à partir du horodatage '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 fermé
|
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 est-ce 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.
Source des données :
Déduit de l'historique des changements de statut de l'incident. L'événement correspond au horodatage 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 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 est-ce important ? :
Le suivi des réaffectations est impératif 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.
Source des données :
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 est-ce 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).
Source des données :
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 est-ce 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.
Source des données :
Déduit de l'historique des changements de statut de l'incident. L'horodatage 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 est-ce 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.
Source des données :
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 est-ce 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.
Source des données :
Il s'agit d'un event explicite. Jira stocke chaque commentaire avec un horodatage 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 est-ce 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 points de blocage danss équipes spécialisées et à analyser les schémas d'escalade.
Source des données :
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 est-ce 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.
Source des données :
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 est-ce 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.
Source des données :
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 est-ce 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.
Source des données :
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 est-ce important ? :
Le suivi de ce lien est indispensable pour comprendre l'efficacité avec laquelle l'organisation passe de l'atténuation des incidents à l'analyse des causes profondes et à la prévention.
Source des données :
Il s'agit d'un event explicite enregistré dans l'historique des liens du problème. Chaque création de lien a un horodatage 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 est-ce 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.
Source des données :
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
|
|||