Modèle de données : Gestion des incidents
Votre modèle de données de gestion des incidents
- Attributs recommandés à collecter
- Activités clés à suivre pour votre processus
- Guide d'extraction pour votre système de données
Attributs de Gestion des Incidents
| 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
|
|||
Activités de Gestion des Incidents
| 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
|
|||