Modèle de données : Gestion des incidents
Votre template 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 | 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
|
|||
Activités de gestion des incidents
| 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
|
|||