Modèle de données : Gestion des incidents

BMC Helix ITSM
Modèle de données : Gestion des incidents

Votre modèle de données de gestion des incidents

Ce modèle fournit un guide complet pour la collecte des données essentielles nécessaires à l'optimisation de votre processus de gestion des incidents. Il décrit les attributs et activités cruciaux à suivre, ainsi que des conseils pratiques sur la manière d'extraire ces données. Utilisez cette ressource pour rationaliser votre préparation des données et accélérer votre parcours d'analyse de processus.
  • Attributs recommandés à collecter
  • Activités clés à suivre pour votre processus
  • Guide d'extraction pour votre système de données
Nouveau dans les journaux d'événements ? Apprenez comment créer un journal d'événements Process Mining.

Attributs de Gestion des Incidents

Ce sont les champs de données recommandés à inclure dans votre event log pour une analyse approfondie de votre processus de gestion des incidents.
3 Obligatoire 9 Recommandé 10 Facultatif
Nom Description
ID d'Incident
IncidentId
L'identifiant unique pour chaque enregistrement d'incident.
Description

L'Incident ID sert de clé primaire pour chaque incident, l'identifiant de manière unique de sa création à sa clôture. Il relie toutes les activités, les logs et les changements connexes, offrant une vue complète de bout en bout du cycle de vie de l'incident.

En Process Mining, cet attribut est fondamental car il définit le cas. Chaque événement avec le même Incident ID est considéré comme faisant partie de la même instance de processus, permettant la reconstruction et l'analyse de la manière dont les incidents individuels sont traités.

Pourquoi c'est important

Il s'agit de l'identifiant de cas essentiel qui relie tous les événements du cycle de vie d'un incident, rendant possible une analyse de bout en bout du processus.

Où obtenir

Il s'agit du champ 'Incident Number' (ID de champ : 1000000161) dans le formulaire 'HPD:Help Desk'.

Exemples
INC000001234567INC000002345678INC000003456789
Nom de l'activité
ActivityName
Le nom de l'événement ou de la tâche spécifique qui a eu lieu au cours du cycle de vie de l'incident.
Description

Cet attribut décrit l'activité qui a été réalisée à un moment précis pour un incident, telle que 'Incident signalé', 'Groupe assigné' ou 'Incident résolu'. Ces activités sont les éléments constitutifs de la carte des processus.

L'analyse de la séquence et de la fréquence de ces activités révèle le flux de processus réel, identifie les chemins courants et met en évidence les écarts par rapport à la procédure standard. Il est crucial pour comprendre quelles actions sont entreprises pour résoudre un incident.

Pourquoi c'est important

Les activités définissent les étapes de la cartographie des processus, permettant la visualisation et l'analyse du workflow de gestion des incidents.

Où obtenir

Généralement dérivé des changements dans les champs 'Status' (ID de champ: 7) et 'Status_Reason' du formulaire 'HPD:Help Desk', ou du formulaire 'HPD:Help Desk Audit Log'.

Exemples
Incident SignaléGroupe assignéRésolution mise en œuvreIncident Clos
Timestamp de l'événement
EventTimestamp
La date et l'heure exactes de l'activité.
Description

Cet horodatage enregistre le moment où un événement spécifique s'est produit dans le cycle de vie de l'incident. Il fournit l'ordre chronologique nécessaire pour reconstruire le flux de processus à partir des données brutes.

L'horodatage d'événement est essentiel pour toutes les analyses basées sur le temps, y compris le calcul des temps de cycle entre les activités, l'identification des goulots d'étranglement où les incidents attendent de longues périodes, et la mesure des temps de résolution globaux. Il constitue l'épine dorsale temporelle de l'analyse des processus.

Pourquoi c'est important

Cet horodatage fournit l'ordre chronologique des événements, ce qui est essentiel pour calculer les durées, identifier les goulots d'étranglement et comprendre la chronologie du processus.

Où obtenir

La 'Date de dernière modification' (ID du champ : 6) ou des champs de date spécifiques du formulaire 'HPD:Help Desk'. Pour les événements historiques, cela provient du champ timestamp du journal d'audit.

Exemples
2023-10-26T10:00:00Z2023-10-26T10:15:32Z2023-10-27T14:22:05Z
Catégorie d'Incident
IncidentCategory
La classification de l'incident, souvent structurée par niveaux.
Description

La catégorisation des incidents offre une méthode structurée pour classer les incidents, généralement à l'aide d'une hiérarchie à plusieurs niveaux (par exemple, Niveau 1 : Matériel, Niveau 2 : Ordinateur portable, Niveau 3 : Batterie). Ces données sont essentielles pour l'acheminement, le reporting et l'analyse des tendances.

En process mining, la catégorisation est utilisée pour analyser différents types d'incidents séparément. Elle soutient le dashboard 'Précision de la Catégorisation des Incidents' en comparant les catégories initiales et finales et aide à identifier les tendances pour le dashboard 'Tendances des Causes Profondes'.

Pourquoi c'est important

La catégorisation permet un routage précis, l'analyse des tendances et la comparaison des performances entre différents types d'incidents.

Où obtenir

Ce sont les champs 'Catégorisation Opérationnelle Niveau 1/2/3' du formulaire 'HPD:Help Desk'.

Exemples
Matériel > Ordinateur portable > BatterieLogiciel > Application d'entreprise > Erreur de connexionRéseau > Connectivité > Wi-Fi
Est Réouvert
IsReopened
Un indicateur indiquant si un incident a été rouvert après être passé au statut 'Résolu'.
Description

Cet attribut booléen est vrai si le statut d'un incident est revenu à un état actif (comme 'In Progress') après avoir été marqué comme 'Resolved'. Cela indique que la correction initiale n'était ni efficace ni complète.

Il s'agit d'une mesure directe du retravail et est utilisé pour calculer le KPI 'Taux de Retravail des Incidents'. L'analyse des incidents rouverts aide à identifier les corrections de mauvaise qualité, les tests insuffisants ou les problèmes récurrents qui n'ont pas été correctement traités, ce qui soutient le dashboard des Chemins de Retravail et d'Escalade.

Pourquoi c'est important

Mesure directement le remaniement et la qualité des résolutions. Un taux de réouverture élevé indique des correctifs inefficaces et des faiblesses de processus.

Où obtenir

Calculé en analysant la séquence d'activités pour un incident. Si une activité « Incident Rouvert » ou similaire apparaît après une activité « Résolution Implémentée », cet indicateur est défini sur vrai.

Exemples
truefaux
Groupe Affecté
AssignedGroup
Le groupe de support responsable du traitement de l'incident.
Description

Cet attribut identifie l'équipe ou le service assigné à l'incident, tels que 'Service Desk', 'Network Team' ou 'Database Administrators'. Le suivi des affectations est essentiel pour comprendre le flux de travail entre les équipes.

Cet attribut est utilisé pour analyser les transferts inter-équipes, identifier les bottlenecks causés par des groupes spécifiques et mesurer le Taux de Réaffectation des Incidents. Il aide à visualiser le parcours d'un incident au sein de l'organisation et met en évidence les zones présentant un routage inefficace ou des lacunes en matière de connaissances.

Pourquoi c'est important

Le suivi du groupe assigné aide à analyser les transferts, à identifier les boucles de réaffectation et à localiser les goulots d'étranglement au sein d'équipes spécifiques.

Où obtenir

Il s'agit du champ 'Assigned Group' (ID de champ : 1000000217) dans le formulaire 'HPD:Help Desk'.

Exemples
Service DeskOpérations RéseauSupport applicatif de niveau 2Services d'Infrastructure
Priorité
Priority
Le niveau de priorité attribué à l'incident, déterminant l'urgence de son traitement.
Description

La priorité est généralement déterminée par la combinaison de l'impact et de l'urgence, et elle dicte l'ordre et la rapidité de résolution des incidents. Les valeurs courantes vont de « Critique » à « Faible ».

En Process Mining, l'analyse des incidents par priorité est cruciale pour l'analyse des performances. Elle permet de répondre à des questions telles que : « Respectons-nous les SLA pour les incidents à priorité élevée ? » et « Les incidents à faible priorité subissent-ils des délais plus importants ? ». Le filtrage par priorité assure une analyse ciblée des problèmes métier les plus critiques.

Pourquoi c'est important

Cet attribut est essentiel pour segmenter l'analyse afin de garantir que les incidents à haute priorité sont traités plus rapidement et respectent leurs objectifs de niveau de service spécifiques.

Où obtenir

Il s'agit du champ 'Priority' (ID de champ : 1000000164) dans le formulaire 'HPD:Help Desk'.

Exemples
CritiqueÉlevéMoyenFaible
Responsable assigné
Assignee
L'utilisateur individuel chargé de travailler sur l'incident.
Description

L'Assigné est l'agent de support ou le technicien spécifique responsable de l'incident à un moment donné. Cela offre un niveau de détail plus granulaire que le Groupe assigné.

L'analyse des performances par assigné peut aider à identifier les agents les plus performants, ceux qui nécessitent une formation supplémentaire et les déséquilibres dans la répartition de la charge de travail. Elle est également utilisée pour retracer la séquence exacte des actions entreprises par les individus travaillant sur un incident complexe.

Pourquoi c'est important

Offre une vue granulaire de la répartition de la charge de travail et de la performance individuelle, et aide à identifier les agents les plus performants ou ceux nécessitant un soutien.

Où obtenir

Il s'agit du champ 'Assignee' (ID de champ : 1000000218) dans le formulaire 'HPD:Help Desk'.

Exemples
Bob SmithAlice JohnsonCharlie Brown
Service
Service
Le service métier ou technique affecté par l'incident.
Description

Cet attribut lie un incident à un service spécifique défini dans la base de données de gestion de la configuration (CMDB), tels que 'Email Service', 'VPN Access' ou 'SAP Financials'.

Ce lien est crucial pour comprendre l'impact commercial des incidents. L'analyse des incidents par service permet d'identifier les services problématiques qui génèrent un volume élevé d'incidents, met en évidence les problèmes récurrents liés à des technologies spécifiques et soutient l'analyse des tendances pour la gestion des problèmes.

Pourquoi c'est important

Connecter les incidents aux services métier est crucial pour l'analyse d'impact et l'identification des services les plus sujets aux problèmes.

Où obtenir

Il s'agit du champ 'ServiceCI' ou d'un champ similaire représentant l'élément de configuration (CI) affecté dans le formulaire 'HPD:Help Desk'.

Exemples
E-mail d'entrepriseSAP ERPVPN d'accès à distancePortail des Ressources Humaines
SLA Non Respecté
IsSlaBreached
Un indicateur indiquant si l'incident a été résolu après sa date cible de SLA.
Description

Cet attribut booléen est vrai si le temps de résolution d'un incident a dépassé le SLA défini. Il fournit un résultat clair et binaire quant à la performance SLA de chaque incident.

Ce drapeau est essentiel pour créer le dashboard de Vue d'ensemble de la Performance SLA des Incidents et pour calculer le KPI 'Taux de Conformité SLA des Incidents'. Il simplifie l'analyse en permettant le filtrage et l'agrégation directs de tous les incidents qui n'ont pas atteint leurs objectifs de niveau de service, ce qui facilite l'étude des raisons des non-conformités.

Pourquoi c'est important

Ce drapeau simplifie l'analyse de la conformité au SLA, facilitant ainsi le filtrage de tous les incidents non conformes et l'investigation des causes profondes.

Où obtenir

Calculé en comparant le timestamp de l'événement « Incident Résolu » à la « DateCibleSLA ». Si le timestamp de résolution est postérieur à la date cible, cet indicateur est vrai.

Exemples
truefaux
Statut de l'Incident
IncidentStatus
Le statut actuel ou historique de l'incident au moment de l'événement.
Description

Cet attribut indique l'état de l'incident, tels que 'New', 'In Progress', 'Pending', 'Resolved' ou 'Closed'. Il offre un aperçu de l'état de l'incident au sein de son cycle de vie.

L'analyse des changements de statut est fondamentale pour comprendre le processus de gestion des incidents. Elle est utilisée pour définir les activités, mesurer le temps passé dans différents états (par exemple, combien de temps les incidents restent en statut 'Pending') et identifier les incidents potentiellement bloqués ou inactifs.

Pourquoi c'est important

Le suivi des changements de statut est essentiel pour comprendre la progression de l'incident et mesurer le temps qu'il passe dans des états spécifiques comme 'Pending' ou 'In Progress'.

Où obtenir

Il s'agit du champ 'Status' (ID de champ : 7) dans le formulaire 'HPD:Help Desk'.

Exemples
NouveauAssignéEn coursEn AttenteRésoluClôturé
Temps de Résolution d'Incident
IncidentResolutionTime
Le temps total écoulé entre le premier signalement d'un incident et sa résolution.
Description

Il s'agit d'une métrique calculée représentant la durée entre les activités 'Incident Reported' et 'Incident Resolved'. C'est l'un des KPI les plus courants et importants en gestion des incidents.

Cette métrique mesure directement l'efficacité du processus de résolution. En Process Mining, il est utilisé comme indicateur de performance principal, analysé à travers différentes catégories d'incidents, priorités et équipes pour identifier les domaines d'amélioration et suivre l'impact des changements de processus au fil du temps.

Pourquoi c'est important

C'est un KPI critique qui mesure l'efficacité de bout en bout du processus de gestion des incidents, impactant directement la satisfaction de l'utilisateur.

Où obtenir

Calculé en soustrayant le timestamp du premier événement du timestamp de l'événement « Incident Résolu » pour chaque identifiant d'incident.

Exemples
2592003600864000
Canal
Channel
La méthode utilisée pour signaler l'incident.
Description

Cet attribut spécifie comment l'incident a été soumis, par exemple, via un appel téléphonique, un courriel, un self-service portal ou une demande directe. Il indique le point d'entrée de l'incident dans le processus de support.

L'analyse des incidents par canal peut révéler quels canaux sont les plus efficaces ou lesquels génèrent des incidents plus faciles ou plus difficiles à résoudre. Elle peut également éclairer les décisions concernant les investissements en automatisation ou en formation des utilisateurs, par exemple, en promouvant l'utilisation d'un self-service portal qui collecte de meilleures données initiales.

Pourquoi c'est important

Comprendre le canal de soumission aide à analyser l'efficacité des différentes méthodes d'acquisition et peut orienter les investissements dans le self-service ou l'automatisation.

Où obtenir

Il s'agit du champ 'Reported Source' (ID de champ : 1000000215) dans le formulaire 'HPD:Help Desk'.

Exemples
E-mailTéléphoneLibre-serviceSaisie directe
Cause profonde
RootCause
La raison sous-jacente ou la cause ultime de l'incident.
Description

La Cause première est le problème fondamental qui, s'il était résolu, empêcherait l'incident de se reproduire. Elle est souvent identifiée dans le cadre d'un processus d'investigation de problème connexe.

Bien que tous les incidents n'aient pas une cause première documentée, l'analyse de cet attribut est essentielle pour une gestion proactive des problèmes. Elle soutient le KPI 'Taux d'identification des causes premières' et aide à créer des dashboards qui suivent les tendances des problèmes récurrents, orientant les efforts vers la mise en œuvre de solutions permanentes.

Pourquoi c'est important

L'identification de la cause profonde est essentielle pour la gestion des problèmes et pour les analyses visant à réduire le volume d'incidents récurrents.

Où obtenir

Ces informations pourraient se trouver dans un champ dédié 'Root Cause' de l'incident ou, plus couramment, sur un formulaire 'PBI:Problem Investigation' lié.

Exemples
Espace disque insuffisant sur le serveurErreur de configuration réseauBogue logiciel dans la version 2.1Certificat de sécurité expiré
Code de clôture
CloseCode
Le code sélectionné lors de la clôture d'un incident, indiquant le résultat de la résolution.
Description

Le Code de clôture fournit un résumé structuré de la manière dont un incident a été résolu. Les exemples incluent 'Résolu par l'utilisateur', 'Aucune anomalie trouvée', 'Incident en double' ou 'Correction permanente appliquée'.

Cet attribut est précieux pour analyser l'efficacité et les résultats de la résolution. Il peut aider à identifier les incidents clôturés sans véritable correctif ou à mettre en évidence les catégories où les utilisateurs résolvent fréquemment leurs propres problèmes, ce qui pourrait indiquer des opportunités d'amélioration des articles de base de connaissances ou des outils en self-service.

Pourquoi c'est important

Fournit des données structurées sur les résultats de résolution, et aide à analyser l'efficacité des correctifs et à identifier les tendances de clôture des incidents.

Où obtenir

Ceci fait généralement partie des informations de résolution ou de clôture sur le formulaire 'HPD:Help Desk'.

Exemples
Résolu à distanceIncident en doubleErreur utilisateurAucune Action Requise
Date cible SLA
SlaTargetDate
La date et l'heure auxquelles l'incident est censé être résolu selon son SLA.
Description

Cet attribut enregistre la date limite de résolution d'un incident telle que définie par le Service Level Agreement (SLA) applicable. Il est calculé en fonction de la priorité de l'incident et des heures de service définies.

Ce timestamp est la référence par rapport à laquelle le temps de résolution réel est mesuré. Il est essentiel pour calculer l'indicateur clé de performance (KPI) 'Taux de Conformité SLA des Incidents' et pour créer des dashboards qui visualisent la performance des SLA. Il permet un suivi proactif des incidents approchant leur date limite.

Pourquoi c'est important

C'est la référence pour mesurer la conformité au SLA. Il permet de calculer si un incident a été résolu à temps ou s'il a enfreint son accord.

Où obtenir

Ces données sont généralement stockées dans le formulaire 'SLM:Measurement' et liées à l'incident. Ce n'est pas un champ direct sur 'HPD:Help Desk'.

Exemples
2023-10-26T14:00:00Z2023-10-27T09:00:00Z2023-11-01T17:00:00Z
Demandeur
Submitter
La personne qui a initialement signalé l'incident.
Description

Le Demandeur est l'utilisateur final ou le client qui a rencontré le problème et l'a signalé. Ceci est distinct de l'assigné, qui travaille sur l'incident.

L'analyse des données par demandeur ou par département peut aider à identifier des groupes d'utilisateurs spécifiques qui pourraient nécessiter une formation supplémentaire ou des groupes affectés par un type de problème particulier. Cela offre une vue centrée sur le client du processus de gestion des incidents.

Pourquoi c'est important

Identifie l'utilisateur qui a signalé le problème, permettant une analyse basée sur le département, l'emplacement ou le rôle de l'utilisateur afin de déceler des tendances spécifiques à celui-ci.

Où obtenir

Ces informations sont capturées dans le champ 'Submitter' ou dans les champs liés aux informations du client sur le formulaire 'HPD:Help Desk'.

Exemples
John DoeJane SmithPeter Jones
Dernière mise à jour des données
LastDataUpdate
L'horodatage indiquant la dernière actualisation des données de cet événement à partir du système source.
Description

Cet attribut enregistre la date et l'heure de la dernière extraction de données. Il fournit un contexte sur la fraîcheur des données analysées, ce qui est important pour comprendre l'actualité des aperçus de processus.

Connaître l'heure de la dernière mise à jour est vital pour le reporting et les dashboards, car cela informe les utilisateurs de l'actualité des données et aide à gérer les attentes quant à l'intégration des toutes dernières activités d'incident.

Pourquoi c'est important

Indique la fraîcheur des données, garantissant aux utilisateurs de comprendre l'actualité de l'analyse des processus et des informations qui en découlent.

Où obtenir

Cette valeur est généralement générée et apposée sur l'ensemble de données lors du processus d'extraction de données (ETL).

Exemples
2023-11-01T02:00:00Z2023-11-02T02:00:00Z2023-11-03T02:00:00Z
Description de la résolution
Resolution
Une description en texte libre des étapes prises pour résoudre l'incident.
Description

Ce champ contient le résumé détaillé, rédigé par un humain, de la résolution finale. Il explique ce qui a été fait pour résoudre le problème et rétablir le service à l'utilisateur.

Bien que non structurées, ces données textuelles peuvent être analysées à l'aide de techniques d'exploration de texte pour identifier les modèles de résolution courants, extraire les mots-clés liés à des problèmes spécifiques ou compléter l'analyse des causes profondes. Il fournit un contexte qualitatif qui manque souvent aux champs de données structurées.

Pourquoi c'est important

Offre des détails qualitatifs sur la résolution, qui peuvent être utilisés dans le Text Mining pour trouver des modèles non visibles dans les données structurées.

Où obtenir

Il s'agit du champ 'Resolution' (ID de champ : 1000000156) dans le formulaire 'HPD:Help Desk'.

Exemples
Le mot de passe de l'utilisateur a été réinitialisé via Active Directory.Cache et cookies effacés dans le navigateur, ce qui a résolu le problème de connexion.Commutateur réseau redémarré dans le placard IDF 3B.
Impact
Impact
La mesure de l'effet de l'incident sur les processus métier.
Description

L'impact évalue l'étendue de l'effet négatif d'un incident sur l'entreprise. Il est souvent défini sur une échelle, telle que 'Étendue/Généralisée', 'Significative/Importante', 'Modérée/Limitée' ou 'Mineure/Localisée'.

Combiné à l'Urgence, l'Impact détermine la Priorité de l'incident. L'analyse par impact permet de comprendre quels incidents causent la plus grande perturbation commerciale, quelle que soit leur complexité technique. C'est un élément clé pour prioriser les efforts d'amélioration des processus.

Pourquoi c'est important

Aide à quantifier la gravité métier d'un incident, ce qui est un élément clé pour déterminer la priorité et concentrer l'analyse sur les problèmes à fort impact.

Où obtenir

Il s'agit du champ 'Impact' (ID de champ : 1000000163) dans le formulaire 'HPD:Help Desk'.

Exemples
1-Étendue/Généralisée2-Significatif/Large3-Modéré/Limité4-Mineur/Localisé
Nombre de réaffectations
ReassignmentCount
Le nombre total de fois qu'un incident a été réaffecté à un groupe différent.
Description

Cette métrique compte le nombre de fois où le champ 'AssignedGroup' a changé au cours du cycle de vie de l'incident. Un nombre élevé suggère des problèmes de routage initial, un manque de résolution au premier contact ou des problèmes complexes nécessitant l'intervention de plusieurs équipes.

Cet attribut prend directement en charge l'ICP 'Incident Reassignment Rate' et le dashboard 'Incident Reassignment Cycle Analysis'. Il aide à quantifier l'effet 'ping-pong' où les tickets sont transférés d'une équipe à l'autre, entraînant des retards significatifs et une inefficacité des processus.

Pourquoi c'est important

Quantifie les acheminements et transferts inefficaces, et aide à identifier les incidents qui restent bloqués dans des boucles de réaffectation entre équipes.

Où obtenir

Calculé en comptant le nombre de fois où la valeur de « GroupeAffecté » change pour un identifiant d'incident donné dans le journal d'événements.

Exemples
0135
Système source
SourceSystem
Le système dont les données de l'incident ont été extraites.
Description

Cet attribut identifie l'origine des données, ce qui est particulièrement utile dans les environnements dotés de plusieurs outils ITSM ou de systèmes intégrés. Il confirme que les données proviennent de la source attendue, telle qu'une instance spécifique de BMC Helix ITSM.

En analyse, il aide à différencier les processus ou les caractéristiques des données qui pourraient varier entre les systèmes de production, de développement ou hérités, garantissant que la data lineage est claire et fiable.

Pourquoi c'est important

Identifie l'origine des données, élément crucial pour leur validation et pour la gestion des analyses à travers plusieurs systèmes intégrés.

Où obtenir

Il s'agit généralement d'une valeur statique ajoutée lors du processus d'extraction, transformation et chargement (ETL) des données.

Exemples
BMCHelixITSM_ProdITSM-EU-InstanceServiceManagement-APAC
Obligatoire Recommandé Facultatif

Activités de Gestion des Incidents

Ce sont les étapes clés du processus et les jalons à capturer dans votre event log pour une découverte de processus précise et une visualisation des flux.
5 Recommandé 9 Facultatif
Activité Description
Groupe assigné
Cette activité marque l'affectation initiale de l'incident à un groupe de support spécifique pour enquête. Elle est déduite de la première fois que le champ 'Groupe assigné' est renseigné après la création de l'incident.
Pourquoi c'est important

C'est un jalon clé qui marque le début du travail actif. Le suivi du temps jusqu'à la première affectation est crucial pour évaluer les temps de réponse et l'efficacité du routage initial.

Où obtenir

Déduit du journal d'audit (« HPD:HelpDesk_AuditLogSystem ») pour le formulaire « HPD:Help Desk », enregistrant le premier renseignement du champ « Groupe Assigné ».

Capture

À partir de l'horodatage lorsque le champ 'Groupe assigné' est renseigné pour la première fois.

Type d'événement inferred
Incident Clos
C'est l'activité finale, marquant la clôture formelle du dossier d'incident une fois la résolution confirmée ou une période de confirmation écoulée. Elle est capturée lorsque le statut est défini sur 'Closed'.
Pourquoi c'est important

C'est l'événement de fin définitif pour le cycle de vie de l'incident. Le temps entre 'Resolved' et 'Closed' représente la période de confirmation de l'utilisateur et de clôture administrative.

Où obtenir

Cet événement correspond à la mise à jour du champ 'Status' du formulaire 'HPD:Help Desk' à 'Closed'. Le timestamp est enregistré dans le champ 'Closed Date' et le journal d'audit.

Capture

À partir de l'horodatage 'Date de clôture' ou du changement de statut à 'Clôturé'.

Type d'événement inferred
Incident Résolu
Cette activité marque la résolution officielle de l'incident du point de vue du service desk, avant la clôture finale. Elle est capturée lorsque le statut de l'incident est défini sur 'Résolu'.
Pourquoi c'est important

C'est le jalon le plus important pour mesurer la conformité SLA et le temps de résolution. Il signifie que le service a été restauré pour l'utilisateur.

Où obtenir

Cet événement correspond à la mise à jour du champ 'Status' du formulaire 'HPD:Help Desk' à 'Resolved'. Le timestamp est capturé dans le champ 'Last Resolved Date' et le journal d'audit.

Capture

À partir de l'horodatage du changement de statut à 'Résolu' dans le journal d'audit.

Type d'événement inferred
Incident Signalé
Cette activité marque la création initiale de l'enregistrement d'incident dans le système. Elle est capturée explicitement à partir du timestamp de création de l'incident dans le formulaire principal de gestion des incidents.
Pourquoi c'est important

C'est l'événement de départ principal du cycle de vie de l'incident. Il est essentiel pour calculer les temps de résolution globaux et comprendre les taux d'arrivée des incidents.

Où obtenir

Cet événement correspond à la création de l'enregistrement dans le formulaire 'HPD:Help Desk'. Le timestamp est généralement tiré du champ 'Submit Date' ou 'Reported Date'.

Capture

À partir de l'horodatage 'Date de soumission' sur le formulaire HPD:Help Desk.

Type d'événement explicit
Investigation initiée
Indique qu'un agent de support a commencé à travailler activement sur l'incident. Ceci est généralement déduit d'un changement de statut de « Assigné » à « En Cours ».
Pourquoi c'est important

Ce jalon marque la transition de l'attente en file d'attente vers un diagnostic actif. L'analyse du temps passé à attendre le début de l'investigation aide à identifier les goulots d'étranglement de ressources et prend en charge le dashboard 'Diagnosis & Investigation Bottlenecks'.

Où obtenir

Déduit d'un changement de statut sur le formulaire « HPD:Help Desk ». L'événement est déclenché lorsque le champ « Statut » passe à « En Cours », l'horodatage étant enregistré à partir du journal d'audit.

Capture

Déduit d'un changement de statut à « En Cours » dans le HPD:HelpDesk_AuditLogSystem.

Type d'événement inferred
Confirmation utilisateur reçue
Représente l'utilisateur confirmant activement que la solution fournie a résolu son problème. Il peut s'agir d'un événement explicite ou déduit de notes ou d'une action système associée avant la clôture.
Pourquoi c'est important

Ce suivi fournit une image plus précise du processus de validation utilisateur que la simple attente d'une clôture automatique. Il aide à mesurer l'ICP 'Average User Confirmation Time' et à identifier les lacunes de communication.

Où obtenir

Ceci peut être difficile à saisir de manière fiable. Cela pourrait être déduit d'une entrée dans le work log ou d'une mise à jour spécifique du motif du statut juste avant que l'incident ne soit passé à 'Closed'. Cela peut nécessiter une analyse du formulaire 'HPD:WorkLog'.

Capture

Déduit d'entrées spécifiques du journal de travail ou de mises à jour du motif du statut avant la clôture.

Type d'événement inferred
En attente de confirmation de l'utilisateur
Se produit après qu'une résolution a été mise en œuvre et que l'équipe de support attend que l'utilisateur confirme que la correction est réussie. Ceci est souvent représenté par le statut « Résolu » lui-même, où le compte à rebours pour la clôture automatique commence.
Pourquoi c'est important

Cette activité est cruciale pour le dashboard 'Délais de confirmation et de vérification par l'utilisateur'. Elle aide à quantifier les délais entre la fourniture d'un correctif et l'obtention de la validation de l'utilisateur, ce qui peut prolonger artificiellement le cycle de vie de l'incident.

Où obtenir

Cet état commence lorsque le 'Status' du formulaire 'HPD:Help Desk' passe à 'Resolved'. La durée est mesurée à partir de la 'Last Resolved Date' jusqu'à ce que l'incident soit 'Closed' ou 'Reopened'.

Capture

Commence lors du changement de statut à « Résolu », se termine lors du changement de statut à « Fermé » ou « En cours ».

Type d'événement inferred
En attente de la saisie du client
Représente un point où la progression de l'incident est suspendue en attente d'informations ou d'une action de l'utilisateur. Ceci est déduit d'un changement de statut vers un état « En attente ».
Pourquoi c'est important

Cette activité aide à distinguer le temps de travail de l'agent du temps d'attente du client. L'analyse du temps passé dans cet état est cruciale pour comprendre comment les délais de réponse des utilisateurs impactent les temps de résolution globaux.

Où obtenir

Déduit du formulaire « HPD:Help Desk » lorsque le champ « Statut » passe à « En Attente ». La raison spécifique se trouve souvent dans le champ « Status_Reason ».

Capture

Déduit d'un changement de statut à « En Attente » dans le HPD:HelpDesk_AuditLogSystem.

Type d'événement inferred
Incident Annulé
Cette activité représente l'annulation d'un incident créé par erreur ou qui n'est plus pertinent. Elle est capturée lorsque le statut de l'incident est défini sur 'Annulé'.
Pourquoi c'est important

C'est un état final terminal pour un incident, distinct d'une résolution réussie. L'analyse des incidents annulés peut mettre en évidence des problèmes avec les canaux de création d'incidents ou les rapports en double.

Où obtenir

Déduit du formulaire « HPD:Help Desk » lorsque le champ « Statut » passe à « Annulé ». L'horodatage est enregistré dans le journal d'audit.

Capture

Déduit d'un changement de statut à « Annulé » dans le journal d'audit.

Type d'événement inferred
Incident Catégorisé
Représente le point où l'incident a été classifié selon les catégorisations opérationnelles et produit, et où une priorité a été définie. Ceci est généralement déduit du remplissage ou de la dernière modification des champs de catégorisation.
Pourquoi c'est important

Une catégorisation précise et rapide est cruciale pour un routage et un reporting efficaces. L'analyse de cette activité aide à identifier les retards ou les inexactitudes dans le processus de triage initial, alimentant le tableau de bord « Précision de la Catégorisation des Incidents ».

Où obtenir

Déduit du journal d'audit (« HPD:HelpDesk_AuditLogSystem ») qui suit les changements de champs tels que « Operational Categorization Tier 1-3 », « Product Categorization Tier 1-3 » et « Priority » sur le formulaire « HPD:Help Desk ».

Capture

À partir de l'horodatage de la dernière mise à jour des champs de catégorisation ou de priorité après la création.

Type d'événement inferred
Incident Rouvert
Représente un incident qui était auparavant marqué comme résolu, mais qui a été réactivé parce que le problème persiste. Ceci est déduit d'un changement de statut de « Résolu » vers un état actif tel que « En cours » ou « Attribué ».
Pourquoi c'est important

Cette activité mesure directement le rework et l'efficacité des solutions initiales. Un volume élevé d'incidents rouverts est un indicateur clé d'une mauvaise qualité des correctifs et soutient le KPI 'Taux de rework des incidents'.

Où obtenir

Déduit du journal d'audit (« HPD:HelpDesk_AuditLogSystem ») en détectant un changement de « Statut » de « Résolu » à « En Cours » ou « Assigné » pour un ID d'incident donné.

Capture

Déduit de la transition de statut de « Résolu » vers un état actif.

Type d'événement inferred
Résolution mise en œuvre
Cette activité signifie qu'un correctif ou une solution de contournement a été appliqué par l'équipe de support. Ceci est souvent déduit lorsque le statut de l'incident passe à 'Résolu'.
Pourquoi c'est important

C'est un jalon critique indiquant qu'une solution a été livrée. C'est un point de données clé pour mesurer le temps nécessaire à l'application d'une correction une fois l'enquête terminée.

Où obtenir

C'est généralement déduit lorsque le 'Status' du formulaire 'HPD:Help Desk' passe à 'Resolved'. L'horodatage est capturé dans le champ 'Last Resolved Date' et le journal d'audit.

Capture

À partir de l'horodatage 'Date de dernière résolution' ou du changement de statut à 'Résolu'.

Type d'événement inferred
Rupture de SLA
Il s'agit d'un événement calculé qui se produit lorsque le temps de résolution d'un incident dépasse l'objectif de Service Level Agreement défini. Il est dérivé en comparant le timestamp de résolution à la date d'échéance du SLA.
Pourquoi c'est important

Cette activité est fondamentale pour le dashboard 'Aperçu des performances SLA des incidents' et le KPI 'Taux de conformité SLA des incidents'. Elle signale directement les incidents qui n'ont pas respecté les engagements de service.

Où obtenir

Calculé en comparant la « Date de Dernière Résolution » à la « Date Cible » (Date d'échéance SLA) sur le formulaire « HPD:Help Desk ». Si l'incident n'est pas encore résolu, il peut être calculé par rapport à l'heure actuelle.

Capture

Événement calculé : se produit si « Date de Dernière Résolution » > « Date Cible ».

Type d'événement calculated
Transféré à un autre groupe
Cette activité se produit lorsqu'un incident est réaffecté d'un groupe de support à un autre. Elle est déduite en détectant un changement dans le champ 'Groupe assigné' après l'affectation initiale.
Pourquoi c'est important

Les transferts fréquents indiquent un routage initial incorrect ou des lacunes de connaissances. Le suivi de cette activité est essentiel pour le tableau de bord 'Analyse du cycle de réaffectation des incidents' et l'indicateur clé de performance (KPI) 'Taux de réaffectation des incidents'.

Où obtenir

Déduit du journal d'audit (« HPD:HelpDesk_AuditLogSystem ») en identifiant les changements ultérieurs au champ « Groupe Assigné » sur le formulaire « HPD:Help Desk » après qu'il a été renseigné pour la première fois.

Capture

Identifier les modifications du champ 'Groupe assigné' après l'attribution initiale.

Type d'événement inferred
Recommandé Facultatif

Guides d'extraction

Comment obtenir vos données de BMC Helix ITSM