Modèle de données : Gestion des Incidents
Votre Template de données de gestion des incidents
Ceci est notre modèle de données générique de Process Mining pour Gestion des incidents. Utilisez nos modèles spécifiques au système pour des directives plus précises.
Sélectionnez un système spécifique- Structure de données universelle pour tout système de gestion des incidents.
- Attributs et activités recommandés pour une analyse complète
- Conseils sur l'extraction des données, y compris des exemples spécifiques au système
Attributs de gestion des incidents
| Nom | Description | ||
|---|---|---|---|
ID d'incident IncidentId | L'identifiant unique attribué à chaque incident. Cet identifiant sert de clé primaire pour le suivi d'un incident tout au long de son cycle de vie. | ||
Description L'ID d'incident est un code alphanumérique unique qui distingue un incident de tous les autres au sein du système. Il est généré lors de la création d'un nouvel incident et reste constant jusqu'à ce que l'incident soit archivé ou supprimé de manière permanente. Dans le Process Mining, l'ID d'incident est la pierre angulaire de l'analyse, servant de Case ID. Il permet au logiciel d'assembler tous les événements, changements de statut et activités liés en une seule instance de processus cohérente. En regroupant tous les événements sous un ID d'incident commun, les analystes peuvent cartographier avec précision le parcours de bout en bout de chaque incident, de son rapport initial à sa résolution et sa clôture finales. Pourquoi c'est important C'est essentiel pour lier toutes les activités et tous les événements connexes afin de reconstituer le cycle de vie de bout en bout d'un incident pour le Process Mining. Où obtenir C'est la clé primaire d'un incident et elle se trouve généralement dans l'en-tête ou l'enregistrement principal de chaque table ou objet d'incident. Exemples INC0010032TICKET-84321789456123 | |||
Nom de l'activité ActivityName | Le nom d'une activité métier, d'un événement ou d'un changement de statut spécifique survenu au cours du cycle de vie de l'incident. | ||
Description Le nom d'activité décrit une étape ou une tâche distincte effectuée dans le cadre du processus de gestion des incidents. Ces activités représentent les éléments constitutifs de la carte des processus et peuvent inclure des événements système automatisés, tels que «SLA Breach Detected», ou des actions utilisateur manuelles, comme «Agent Assigned» ou «Workaround Provided». Pour l'analyse du Process Mining, cet attribut est fondamental. Il définit les nœuds du graphique de processus, permettant aux analystes de visualiser le flux de travail, d'identifier les parcours courants, de découvrir les goulots d'étranglement et d'analyser les écarts par rapport à la procédure standard. La granularité et la clarté des noms d'activité ont un impact direct sur la qualité et la profondeur des informations qui peuvent en être tirées. Pourquoi c'est important Cet attribut définit les étapes du processus, permettant la visualisation et l'analyse du flux du cycle de vie de l'incident. Où obtenir Souvent dérivé d'une combinaison de journaux d'événements, de pistes d'audit, d'enregistrements de changements de statut ou de champs de description de tâches au sein du système de gestion des incidents. Exemples Incident crééGroupe affectéIncident résoluStatut changé en En attente | |||
Timestamp de l'événement EventTimestamp | La date et l'heure précises auxquelles une activité ou un événement spécifique relatif à un incident s'est produit. | ||
Description Le timestamp d'événement marque le moment exact où une activité a eu lieu. Chaque activité du cycle de vie d'un incident devrait avoir un timestamp correspondant pour établir une séquence chronologique d'événements. Cet attribut est essentiel pour toute analyse de Process Mining basée sur le temps. Il permet le calcul des temps de cycle entre les activités, la durée des étapes spécifiques et le temps total de résolution de l'incident. En analysant les timestamps, les organisations peuvent identifier les goulots d'étranglement, mesurer le respect des SLA et comprendre comment la performance des processus évolue dans le temps. C'est le fondement du calcul d'indicateurs clés de performance comme le Temps Moyen de Résolution. Pourquoi c'est important Il fournit l'ordre chronologique des événements, ce qui est essentiel pour calculer les durées, identifier les goulots d'étranglement et analyser la performance des processus au fil du temps. Où obtenir Trouvé dans les journaux d'event, les tables d'audit, ou comme 'dernière modification' ou 'date de création' sur des enregistrements associés spécifiques. Exemples 2023-10-26T10:00:00Z2024-01-15T14:35:10Z2023-11-01T09:12:45Z | |||
Dernière mise à jour des données LastDataUpdate | L'horodatage indiquant la dernière fois que les données de cet enregistrement ont été actualisées à partir du système source. | ||
Description Le timestamp de la dernière mise à jour des données spécifie le moment où les données ont été extraites ou synchronisées le plus récemment du système source. C'est un champ de métadonnées qui reflète la fraîcheur des données analysées. Dans l'analyse de Process Mining, cet attribut est important pour comprendre la pertinence temporelle des insights générés. Il aide les utilisateurs à savoir s'ils consultent des informations en temps réel ou un instantané d'un moment antérieur. Ce contexte est vital pour le monitoring opérationnel et garantit que les décisions sont basées sur des données actuelles et pertinentes. Pourquoi c'est important Il indique la fraîcheur des données, s'assurant que les analystes comprennent l'actualité de leur analyse de processus. Où obtenir Cette valeur est généralement générée et apposée sur chaque enregistrement pendant le processus d'extraction et de transformation des données (ETL). Exemples 2023-10-26T23:59:59Z2024-01-16T04:00:10Z2023-11-02T01:05:00Z | |||
Système source SourceSystem | Le nom ou l'identifiant du système à partir duquel les données d'incident ont été extraites. | ||
Description L'attribut Système Source identifie l'origine des données. Dans des environnements comportant plusieurs outils ITSM ou systèmes intégrés, ce champ aide à distinguer les enregistrements provenant de différentes sources. Bien qu'il ne soit pas directement utilisé pour dessiner la carte des processus, cet attribut est précieux pour la validation et la gouvernance des données. Il aide les analystes à retracer les données jusqu'à leur origine, à comprendre les écarts potentiels entre les systèmes et à segmenter l'analyse. Par exemple, il est possible de comparer les processus de gestion des incidents mis en œuvre dans deux systèmes différents, tels que ServiceNow et Jira, au sein de la même organisation. Pourquoi c'est important Il fournit le contexte de l'origine des données, ce qui est crucial pour la validation des données, le dépannage et l'analyse comparative dans des environnements multi-systèmes. Où obtenir Il s'agit souvent d'une valeur statique ajoutée pendant le processus d'extraction des données ou d'un champ disponible dans les tables du système source. Exemples ServiceNowJira Service ManagementBMC HelixZendesk | |||
Agent Affecté AssignedAgent | L'agent de support ou l'utilisateur individuel chargé de gérer l'incident. | ||
Description L'agent assigné identifie la personne spécifiquement responsable d'un incident. Alors que le groupe assigné désigne l'équipe, l'agent est l'acteur individuel travaillant à la résolution. Cet attribut permet un niveau plus granulaire d'analyse des performances et de la charge de travail. En suivant les affectations au niveau de l'agent, les managers peuvent évaluer la productivité individuelle, identifier les besoins en formation et assurer une distribution équilibrée du travail. En Process Mining, il peut révéler des schémas de réaffectation complexes qui pourraient être masqués au niveau du groupe et contribue à comprendre les contributions individuelles aux délais de résolution. Pourquoi c'est important Il permet une analyse détaillée de la charge de travail individuelle, de la performance et des schémas de réaffectation au sein des équipes ou entre elles. Où obtenir Trouvé sur l'enregistrement principal de l'incident, ce champ est mis à jour lorsqu'un agent prend possession ou se voit affecter l'incident. Exemples John SmithJane Doeagent.12345Emily Jones | |||
Canal de signalement ReportingChannel | La méthode ou le canal par lequel l'incident a été signalé, notamment l'e-mail, le téléphone ou le portail self-service. | ||
Description Le canal de signalement indique la source de la soumission de l'incident. Cet attribut suit la manière dont les utilisateurs interagissent avec la fonction de support, que ce soit par des méthodes de contact directes comme les appels téléphoniques ou des méthodes automatisées comme les alertes de monitoring système. L'analyse du processus basée sur le canal de signalement peut révéler des différences importantes en termes d'efficacité. Par exemple, les incidents signalés via un portail self-service pourraient être résolus plus rapidement car ils contiennent souvent des informations plus structurées dès le départ. Cette analyse aide les organisations à optimiser leurs canaux de support et à encourager l'utilisation de méthodes plus efficaces. Pourquoi c'est important Il aide à analyser l'efficacité et les chemins de résolution des incidents en fonction de leur source, ce qui peut éclairer la stratégie de canal et l'allocation des ressources. Où obtenir Cette information est généralement capturée automatiquement ou sélectionnée par l'agent lors de la création d'un incident. Exemples E-mailTéléphonePortail Self-ServiceAlerte système | |||
Catégorie d'incident IncidentCategory | La classification de l'incident, souvent organisée selon une structure hiérarchique (par exemple, Matériel > Ordinateur portable > Batterie). | ||
Description La catégorie d'incident offre une manière structurée de classer les incidents selon leur nature. Il s'agit généralement d'un champ hiérarchique qui permet une classification progressivement plus détaillée, aidant à organiser les incidents en groupes logiques pour le reporting et l'analyse. La catégorisation est essentielle pour l'analyse des causes profondes et des tendances. En analysant les cartes de processus filtrées par catégorie, les organisations peuvent identifier les problèmes récurrents et les modèles associés à des types d'incidents spécifiques. Par exemple, le processus de résolution pour un incident 'Logiciel' pourrait être très différent de celui d'un incident 'Matériel'. Ces données alimentent des KPI tels que la précision de la catégorisation initiale et le taux d'incidents récurrents. Pourquoi c'est important C'est essentiel pour l'analyse des causes profondes, l'identification des tendances des incidents récurrents et la compréhension de la manière dont les différents types de problèmes sont traités. Où obtenir C'est un ensemble de champs standard, souvent obligatoire, dans l'enregistrement d'incident, utilisé pour la classification. Exemples Logiciel | Application | Problème de connexionMatériel | Imprimante | Ne répond pasRéseau | Wi-Fi | Connexion Lente | |||
Gravité Severity | La mesure de l'impact métier de l'incident, indiquant à quel point il affecte les utilisateurs ou les services. | ||
Description La gravité définit le niveau d'impact d'un incident sur l'entreprise. Elle répond à la question de la gravité du problème, indépendamment de son urgence. Par exemple, une panne généralisée du système serait un incident de gravité élevée, tandis qu'un bogue cosmétique mineur serait de gravité faible. L'analyse des incidents par gravité aide les organisations à comprendre quels types de problèmes causent le plus de perturbations. Le Process Mining peut révéler si les incidents de gravité élevée suivent un chemin de résolution différent et plus rationalisé. Cet attribut est crucial pour l'analyse des causes profondes et la priorisation des ressources pour une gestion proactive des problèmes afin d'éviter la récurrence des incidents les plus graves. Pourquoi c'est important Il aide à segmenter les incidents pour comprendre si les problèmes à fort impact sont résolus différemment ou plus efficacement que ceux à faible impact. Où obtenir Un champ standard sur la fiche d'incident, souvent utilisé conjointement avec l'urgence pour déterminer la priorité. Exemples 1 - Élevée2 - Moyenne3 - FaibleCritique | |||
Groupe Affecté AssignedGroup | L'équipe de support, la file d'attente ou le groupe actuellement responsable du traitement de l'incident. | ||
Description Le groupe assigné indique quelle équipe est responsable de l'incident à un moment donné. Les incidents sont souvent acheminés entre différents groupes, tels que le Service Desk de niveau 1, une équipe Réseau de niveau 2 ou une équipe de support applicatif de niveau 3. Cet attribut est essentiel pour l'analyse des transferts et de la charge de travail. Le Process Mining peut utiliser ces données pour visualiser le flux d'incidents entre les équipes, mesurer le temps passé dans la file d'attente de chaque équipe et identifier les goulots d'étranglement causés par des réaffectations fréquentes. Il aide à répondre aux questions sur l'efficacité et la collaboration des équipes, constituant la base du dashboard d'analyse des transferts et réaffectations. Pourquoi c'est important C'est essentiel pour analyser les transferts entre équipes, mesurer les temps d'attente et comprendre la performance et la distribution de la charge de travail spécifiques à chaque équipe. Où obtenir Cette information est généralement stockée dans l'enregistrement d'incident et est mise à jour chaque fois que l'incident est affecté à une nouvelle équipe. Exemples Service DeskOpérations RéseauAdministration de bases de donnéesSupport Applicatif Niveau 2 | |||
Méthode de résolution ResolutionMethod | Un code, une catégorie ou une description indiquant comment l'incident a finalement été résolu. | ||
Description La méthode de résolution décrit le résultat de l'incident et comment il a été résolu. Il peut s'agir d'un code standardisé ou d'une description en texte libre des actions entreprises. Les exemples incluent notamment 'Formation de l'utilisateur', 'Correctif logiciel appliqué', 'Aucune anomalie détectée' ou 'Incident en double'. Cet attribut fournit un contexte crucial à la fin du processus. Dans le Process Mining, l'analyse des incidents par leur méthode de résolution aide à comprendre l'efficacité des différentes solutions. Elle peut mettre en évidence les cas clôturés sans réelle correction ou identifier les schémas de résolution courants pour des catégories d'incidents spécifiques, qui peuvent ensuite être utilisés pour construire une base de connaissances et améliorer les taux de résolution au premier contact. Pourquoi c'est important Il offre un aperçu de la façon dont les problèmes sont résolus, ce qui est essentiel pour identifier les opportunités d'automatisation, d'amélioration de la base de connaissances et de formation. Où obtenir Il s'agit généralement d'un champ rempli par l'agent de support lorsqu'il fait passer un incident au statut 'Résolu' ou 'Fermé'. Exemples Résolu par le Service DeskAucun Défaut TrouvéDoublonMise à jour logicielle déployée | |||
Priorité Priority | Le niveau de priorité attribué à l'incident, lequel détermine l'urgence et l'ordre de sa résolution. | ||
Description La priorité est un attribut clé utilisé pour déterminer l'importance relative d'un incident et la vitesse de réponse requise. Elle est souvent dérivée d'une combinaison de l'impact et de l'urgence de l'incident. Les niveaux vont généralement de critique à faible. En Process Mining, l'analyse des incidents par priorité permet une compréhension plus approfondie de la manière dont le processus gère les différents niveaux d'urgence. Les analystes peuvent comparer les temps de résolution pour les incidents à haute priorité par rapport à ceux à faible priorité afin de vérifier si les SLA sont respectés et si les ressources sont allouées efficacement. Cela aide à répondre à des questions comme : « Traitons-nous réellement nos incidents les plus critiques le plus rapidement possible ? » Pourquoi c'est important Il permet l'analyse de la performance des processus pour différents niveaux d'urgence, aidant à vérifier si les incidents critiques sont traités plus rapidement que les non-critiques. Où obtenir Disponible comme champ standard sur la fiche principale de l'incident. Il peut être défini manuellement ou calculé automatiquement en fonction de l'impact et de l'urgence. Exemples 1 - Critique2 - Élevée3 - Moyenne4 - Faible | |||
Statut de l'incident IncidentStatus | L'état actuel ou historique de l'incident au sein de son cycle de vie, notamment 'Nouveau', 'En cours' ou 'Fermé'. | ||
Description Le statut de l'incident indique l'étape d'un incident à un moment précis. Il offre une vue d'ensemble de la progression de l'incident dans le processus de résolution. Les statuts courants incluent nouveau, assigné, en cours, en attente, résolu et fermé. Cet attribut est fondamental pour l'analyse des processus car les changements de statut définissent souvent les activités dans la carte de processus. L'analyse du temps passé dans chaque statut permet d'identifier les goulots d'étranglement, tels que les incidents en attente prolongée dans un état 'Pending'. Il est également utilisé pour calculer le backlog d'incidents ouverts et suivre la progression vers la résolution. Pourquoi c'est important C'est essentiel pour comprendre la progression de l'incident et est souvent utilisé pour générer des activités pour la carte des processus. L'analyse du temps passé dans chaque statut aide à localiser les retards. Où obtenir Généralement disponible comme champ principal sur l'enregistrement d'incident principal ou dans le journal d'historique de l'incident. Exemples NouveauEn coursEn Attente ClientRésoluClôturé | |||
Demandeur Requester | L'utilisateur, l'employé ou le système qui a initialement signalé l'incident. | ||
Description Le demandeur est la personne qui rencontre le problème et a initié le signalement de l'incident. Il peut s'agir d'un employé interne ou d'un client externe. L'attribut peut également capturer le département ou l'organisation du demandeur. L'analyse des incidents par demandeur ou par département du demandeur aide à identifier si des groupes d'utilisateurs spécifiques rencontrent plus de problèmes que d'autres. Cela peut indiquer des besoins en formation ou des problèmes environnementaux localisés. Dans le Process Mining, cela permet une vue centrée sur l'utilisateur du processus de support, aidant à comprendre l'expérience de différentes cohortes d'utilisateurs. Pourquoi c'est important Il permet une analyse centrée sur l'utilisateur, aidant à identifier si certains utilisateurs, départements ou emplacements génèrent un nombre disproportionné d'incidents. Où obtenir Un champ standard sur la fiche d'incident, généralement renseigné avec le nom de l'utilisateur qui a créé le ticket ou au nom de qui il a été créé. Exemples Alice JohnsonDépartement des ventesb.williamsClient-XYZ Corp | |||
Nombre de réaffectations ReassignmentCount | Le nombre total de fois où l'incident a été réaffecté à un agent ou un groupe différent. | ||
Description Le nombre de réaffectations est une métrique qui suit le nombre de transferts qu'un incident subit au cours de son cycle de vie. Un nombre élevé indique souvent une inefficacité, un routage initial incorrect ou un manque de connaissances au sein des équipes de support. C'est un attribut puissant pour l'analyse de Process Mining. Bien que le Process Mining puisse visualiser les réaffectations, le fait de disposer d'un nombre pré-calculé facilite le filtrage et la mesure des KPI. Il est utilisé directement dans le dashboard d'analyse des transferts et réaffectations et aide à identifier les scénarios de 'ping-pong' où les tickets sont échangés entre les équipes, entraînant des temps de résolution plus longs et une frustration des utilisateurs. Pourquoi c'est important Cette métrique quantifie directement l'inefficacité du processus. Des chiffres élevés sont souvent corrélés à des temps de résolution plus longs et indiquent des problèmes de routage ou de capacités des équipes. Où obtenir Souvent disponible comme champ compteur standard dans l'enregistrement d'incident. Sinon, il peut être dérivé en comptant le nombre de changements d'affectation dans le journal d'audit de l'incident. Exemples 0135 | |||
Service Affecté AffectedService | Le service métier, l'application ou l'élément de configuration (CI) affecté par l'incident. | ||
Description Le service affecté lie un incident à un composant spécifique de l'infrastructure IT, tel qu'une application métier, un serveur ou un périphérique réseau. Il est souvent lié à une base de données de gestion des configurations (CMDB). Cet attribut fournit un contexte métier critique à l'incident. En Process Mining, il permet une analyse axée sur la fiabilité de services ou d'actifs spécifiques. Les organisations peuvent identifier quels services génèrent le plus d'incidents, analyser leurs processus de résolution et prioriser les efforts de gestion des problèmes pour améliorer la stabilité des services métier critiques. C'est un élément clé pour comprendre l'impact commercial plus large des incidents IT. Pourquoi c'est important Il connecte les incidents à des services métier spécifiques ou à des composants IT, permettant d'analyser quels services sont les plus sujets aux problèmes et quel est leur impact. Où obtenir Généralement lié à une Configuration Management Database (CMDB) ou sélectionné à partir d'une liste de catalogue de services sur le formulaire d'incident. Exemples Services de messagerieSAP ERP FinancialsVPN d'entrepriseSRV-SQL-01 | |||
Statut SLA SlaStatus | Indique si l'incident respecte ses objectifs d'accord de niveau de service (SLA), est à risque ou les a enfreints. | ||
Description Le Statut SLA offre un aperçu de la performance d'un incident par rapport à des objectifs de temps prédéfinis, tels que le temps de réponse ou le temps de résolution. Les statuts courants incluent "En cours", "À risque" ou "Violé". Cet attribut est une mesure directe de la qualité du service et constitue un élément essentiel pour le tableau de bord de la Performance SLA. En Process Mining, il permet de comparer les flux de processus des incidents violés et non violés. Cela aide à identifier les activités spécifiques, les retards ou les boucles de retravail qui sont les principaux moteurs des défaillances SLA, permettant ainsi de cibler les efforts d'amélioration des processus. Pourquoi c'est important C'est une mesure directe de la performance par rapport aux objectifs. L'analyse des incidents en rupture de SLA aide à identifier les défaillances de processus qui entraînent une mauvaise prestation de service. Où obtenir Il s'agit généralement d'un champ calculé au sein de l'outil ITSM, mis à jour dynamiquement en fonction de la priorité de l'incident, de son ancienneté et des règles SLA définies. Exemples En coursMis en PauseDépasséÀ risque | |||
Activités de gestion des incidents
| Activité | Description | ||
|---|---|---|---|
Enquête initiée | Indique qu'un agent assigné a commencé à travailler activement sur l'incident. Ceci est souvent représenté par un changement de statut, passant d'un état "Assigné" ou "Nouveau" à un état "En cours". | ||
Pourquoi c'est important Ce jalon marque la fin du temps d'attente initial et le début du travail actif. Mesurer le temps jusqu'à cette activité aide à comprendre la capacité des agents et les retards de réponse. Où obtenir Ceci est généralement déduit d'un changement de statut dans le journal d'historique de l'incident. Capture Identifier l'timestamp lorsque le statut de l'incident change pour la première fois à 'En cours', 'Travail en cours' ou un état actif similaire. Type d'événement inferred | |||
Groupe affecté | Indique l'attribution initiale de l'incident à un groupe de support ou à une équipe spécifique pour investigation. Cela représente le premier transfert officiel et le début du workflow de résolution. | ||
Pourquoi c'est important C'est une étape de routage cruciale. Les retards d'affectation ou un routage incorrect peuvent augmenter considérablement les temps de résolution et provoquer des transferts inutiles entre les équipes. Où obtenir Cet événement est déduit du journal d'audit en identifiant la première instance où un champ "Groupe d'affectation" ou "Équipe de support" est renseigné. Capture Identifier l'timestamp de la première saisie du champ 'Groupe d'affectation' dans l'historique de l'incident. Type d'événement inferred | |||
Incident créé | Cette activité marque la création formelle d'un enregistrement d'incident dans le système. C'est le début définitif du cycle de vie de l'incident, capturant le rapport initial d'un utilisateur ou d'un outil de surveillance. | ||
Pourquoi c'est important C'est l'événement de début principal du processus. L'analyse du temps écoulé entre la création et les autres jalons est fondamentale pour mesurer le temps de résolution global et identifier les retards initiaux. Où obtenir Ceci est généralement capturé à partir de l'horodatage de création de la table principale d'incident ou de ticket dans le système source. Capture Utilisez le 'create_date' ou 'submitted_on' timestamp de l'enregistrement d'incident principal. Type d'événement explicit | |||
Incident fermé | La dernière activité du cycle de vie, où le dossier d'incident est officiellement clos et devient un enregistrement historique en lecture seule. Cela se produit souvent automatiquement après une période définie à l'état 'Résolu'. | ||
Pourquoi c'est important Ceci marque la fin absolue du cycle de vie de l'incident. L'analyse du temps total écoulé entre la création et la clôture offre une vue complète de la durée du processus, y compris toute période administrative post-résolution. Où obtenir Capturé à partir d'un changement de statut explicite à 'Fermé' dans l'historique de l'incident, qui fournit un timestamp final. Capture Utilisez le timestamp du journal d'audit lorsque le statut de l'incident est mis à jour à 'Fermé'. Type d'événement explicit | |||
Incident résolu | Cette activité indique qu'une résolution a été mise en œuvre et que le service est considéré comme rétabli pour l'utilisateur. C'est un jalon critique qui arrête généralement le chronomètre de résolution SLA. | ||
Pourquoi c'est important C'est un point final clé pour mesurer le temps de résolution. La période entre cette étape et la clôture finale est importante pour analyser les retards de confirmation des utilisateurs ou les politiques de clôture automatique. Où obtenir Il s'agit presque toujours d'un événement explicite, capturé lorsqu'un agent modifie le statut de l'incident en "Résolu" ou "Traité". Capture Utilisez le timestamp du journal d'audit lorsque le statut de l'incident est mis à jour à 'Résolu'. Type d'événement explicit | |||
Incident rouvert | Se produit lorsqu'un incident précédemment résolu est ramené à un état actif. Cela arrive généralement lorsque l'utilisateur signale que le problème a réapparu ou que la solution fournie n'était pas efficace. | ||
Pourquoi c'est important Un taux de réouverture élevé indique des problèmes de qualité de résolution, d'analyse incomplète des causes profondes ou de clôture prématurée. C'est une métrique critique pour l'analyse des retouches. Où obtenir Déduit de l'historique du statut lorsqu'un incident passe de "Résolu" ou "Fermé" à un état actif comme "En cours". Capture Détecter un changement de statut d'un état résolu à un état ouvert et capturer l'timestamp de ce changement. Type d'événement inferred | |||
Violation de SLA détectée | Un événement calculé qui se produit lorsque le temps de réponse ou de résolution d'un incident dépasse les objectifs définis dans son Accord de Niveau de Service (SLA). Il ne s'agit pas d'une action utilisateur manuelle, mais du résultat du temps écoulé. | ||
Pourquoi c'est important Les violations de SLA sont un indicateur clé de performance (KPI) essentiel. Analyser quand et pourquoi elles surviennent est essentiel pour améliorer la prestation de services et respecter les obligations contractuelles. Où obtenir Cet événement n'est pas directement enregistré dans les journaux, mais est calculé en comparant les horodatages des événements avec les délais cibles SLA stockés dans l'enregistrement d'incident. Capture Comparer l'timestamp de résolution avec la 'Date d'échéance SLA'. Si la résolution est postérieure, créer un event de violation au timestamp de la date d'échéance SLA. Type d'événement calculated | |||
Agent Affecté | Cette activité marque le moment où un agent spécifique prend ou se voit attribuer la responsabilité de l'incident. Elle représente la transition de la responsabilité au niveau de l'équipe à la responsabilité individuelle. | ||
Pourquoi c'est important Le suivi de l'affectation des agents aide à analyser les charges de travail individuelles, la performance et à identifier les goulets d'étranglement où les incidents attendent un agent disponible. Où obtenir Capturé en suivant les modifications du champ 'Assigné' ou 'Affecté à' dans le journal d'audit de l'incident. Capture Utilisez le timestamp du journal d'audit lorsque le champ 'Assigné' est rempli pour la première fois ou modifié pour un nouvel utilisateur. Type d'événement explicit | |||
Incident catégorisé | Représente la classification de l'incident, y compris la définition de sa catégorie, de son type et de son élément. C'est une étape de triage cruciale qui permet d'acheminer l'incident et d'appliquer les procédures de résolution appropriées. | ||
Pourquoi c'est important Une catégorisation incorrecte peut entraîner des retards, des réaffectations et des rapports faussés. L'analyse de cette activité permet d'évaluer la qualité du processus de triage initial et son impact sur l'efficacité de la résolution. Où obtenir Cet événement est généralement déduit du journal d'audit ou de la table d'historique en identifiant la première fois que des champs liés à la catégorisation sont renseignés. Capture Détecter la première mise à jour de champs tels que 'Catégorie', 'Sous-catégorie' ou 'Élément de configuration' après la création de l'incident. Type d'événement inferred | |||
Incident priorisé | Cette activité se produit lorsque la priorité de l'incident est définie, généralement en fonction de son impact et de son urgence. Le niveau de priorité dicte les temps de réponse et de résolution cibles conformément aux Accords de Niveau de Service (SLA). | ||
Pourquoi c'est important La priorisation influence directement l'allocation des ressources et l'ordre dans lequel les incidents sont traités. L'analyse de cette étape permet de garantir que les incidents critiques reçoivent une attention prioritaire et que les SLA sont respectés. Où obtenir Ceci est capturé en surveillant la piste d'audit pour les modifications apportées aux champs "Priorité" ou "Gravité". Capture Utilisez le timestamp du journal d'audit associé à la mise à jour du champ 'Priorité'. Type d'événement explicit | |||
Incident réaffecté | Représente le transfert d'un incident d'un groupe de support ou d'un agent à un autre. Ce transfert se produit souvent lorsque l'équipe initiale ne peut pas résoudre le problème et nécessite une expertise différente. | ||
Pourquoi c'est important Les réaffectations fréquentes sont un indicateur fort d'inefficacité des processus, d'un routage initial incorrect ou de lacunes dans les connaissances de l'équipe. L'analyse de ces transferts est essentielle pour rationaliser le flux de résolution. Où obtenir Déduit du journal d'audit en détectant tout changement dans le champ "Groupe d'affectation" ou "Affectataire" après l'affectation initiale. Capture Capturer un nouvel event pour chaque modification du champ 'Groupe d'affectation' après sa première saisie. Type d'événement inferred | |||
Solution de contournement fournie | Indique qu'une solution temporaire a été communiquée à l'utilisateur pour restaurer la fonctionnalité du service. Cela atténue l'impact commercial pendant qu'une solution permanente est en cours de développement. | ||
Pourquoi c'est important Fournir une solution de contournement est une étape clé dans la gestion des incidents majeurs. Cela permet de suivre le délai de mitigation séparément du délai de résolution permanente. Où obtenir Cela peut être un statut ou un indicateur explicite, mais est souvent déduit des notes d'agents ou des journaux de communication à l'aide d'une analyse par mots-clés. Capture Identifier via un statut spécifique comme 'Solution de contournement fournie' ou en recherchant des mots-clés tels que 'solution de contournement' ou 'correctif temporaire' dans les commentaires de l'agent. Type d'événement inferred | |||
Statut changé en En attente | Se produit lorsque la progression sur un incident est mise en pause, généralement en attente d'informations de l'utilisateur, d'un fournisseur ou d'une autre dépendance externe. Cet état suspend généralement le chronomètre du SLA. | ||
Pourquoi c'est important L'analyse du temps passé en état d'attente met en évidence les dépendances externes et les retards. Un temps d'attente excessif peut masquer des inefficacités internes et fausser les métriques de temps de résolution. Où obtenir Déduit de l'historique du statut de l'incident lorsqu'il passe à un statut "En attente", "En suspens" ou "En attente de l'utilisateur". Capture Capturer l'timestamp chaque fois que le statut de l'incident passe à un état 'en attente' désigné. Type d'événement inferred | |||
Travail repris | Marque le moment où un incident qui était en attente est réactivé. Cela se produit généralement lorsque les informations requises sont reçues, permettant à l'agent de support de reprendre son travail. | ||
Pourquoi c'est important Cette activité est cruciale pour mesurer avec précision la durée des attentes externes. Le temps entre "En attente" et "Repris" indique la durée pendant laquelle le processus a été bloqué en raison de facteurs externes. Où obtenir Déduit de l'historique du statut de l'incident lorsqu'il passe d'un état "En attente" à un état "En cours" ou à un autre état actif. Capture Capturer l'timestamp lorsque le statut d'un incident passe d'un état 'en attente' à un état actif. Type d'événement inferred | |||
Guides d'extraction
Les méthodes d'extraction varient selon le système. Pour des instructions détaillées,