Votre modèle de données de gestion des incidents
Votre modèle de données de gestion des incidents
Voici notre modèle générique de données pour le Process Mining appliqué à Gestion des incidents. Utilisez nos modèles propres à chaque système pour obtenir des recommandations plus précises.
Sélectionner un système précis- 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 pour extraire les données, avec des exemples propres à chaque système
Attributs de la Gestion des incidents
| Nom | Description | ||
|---|---|---|---|
| Horodatage de l’événement EventTimestamp | Date et heure précises auxquelles une activité ou un événement donné s’est produit pour un incident. | ||
| Description L’horodatage de l’événement indique le moment exact où une activité a eu lieu. Chaque activité du cycle de vie d’un incident doit disposer d’un horodatage correspondant afin d’établir une séquence chronologique des événements. Cet attribut est essentiel à toute analyse de processus fondée sur le temps. Il permet de calculer les temps de cycle entre les activités, la durée de certaines étapes et le délai global de résolution d’un incident. En analysant les horodatages, les organisations peuvent identifier les goulots d’étranglement, mesurer le respect des SLA et comprendre l’évolution des performances du processus au fil du temps. Il constitue la base du calcul d’indicateurs clés tels que le temps moyen de résolution. Pourquoi c’est important Il fournit l’ordre chronologique des événements, indispensable pour calculer les durées, identifier les goulots d’étranglement et analyser les performances du processus au fil du temps. Où les obtenir Présent dans les journaux d’événements, les tables d’historique d’audit ou sous la forme d’une date de dernière modification ou de création sur certains enregistrements associés. Exemples 2023-10-26T10:00:00Z2024-01-15T14:35:10Z2023-11-01T09:12:45Z | |||
| ID de l’incident IncidentId | Identifiant unique attribué à chaque incident. Cet ID sert de clé primaire pour suivre un incident pendant tout son cycle de vie. | ||
| Description L’ID de l’incident est un code alphanumérique unique qui distingue un incident de tous les autres dans le système. Il est généré lors de la création d’un nouvel incident et reste inchangé jusqu’à l’archivage ou la suppression définitive de l’incident. Dans le Process Mining, l’ID de l’incident constitue la base de l’analyse et sert de Case ID. Il permet au logiciel de regrouper tous les événements, changements de statut et activités associés au sein d’une même instance de processus. En regroupant tous les événements sous un ID d’incident commun, les analystes peuvent cartographier précisément le parcours de bout en bout de chaque incident, de son signalement initial à sa résolution et à sa clôture définitives. Pourquoi c’est important Il est essentiel pour relier toutes les activités et tous les événements associés afin de reconstituer le cycle de vie complet de l’incident dans le cadre du Process Mining. Où les obtenir Il s’agit de la clé primaire d’un incident. Elle se trouve généralement dans l’en-tête ou l’enregistrement principal de chaque table ou objet d’incidents. Exemples INC0010032TICKET-84321789456123 | |||
| Nom de l’activité ActivityName | Nom d’une activité métier, d’un événement ou d’un changement de statut précis survenu au cours du cycle de vie de l’incident. | ||
| Description Le nom de l’activité décrit une étape ou une tâche distincte réalisée dans le cadre du processus de gestion des incidents. Ces activités constituent les éléments de base de la carte du processus et peuvent inclure des événements système automatisés, comme « SLA Breach Detected », ou des actions manuelles, comme « Agent Assigned » ou « Workaround Provided ». Pour l’analyse en Process Mining, cet attribut est fondamental. Il définit les nœuds du graphe du processus, ce qui permet aux analystes de visualiser le flux de travail, d’identifier les parcours fréquents, de repérer les goulots d’étranglement et d’analyser les écarts par rapport à la procédure standard. Le niveau de détail et la clarté des noms d’activités influencent directement la qualité et la profondeur des analyses obtenues. Pourquoi c’est important Cet attribut définit les étapes du processus et permet de visualiser et d’analyser le flux du cycle de vie de l’incident. Où les 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 des tâches dans le système de gestion des incidents. Exemples Incident crééGroupe affectéIncident résoluStatut passé à « Pending » | |||
| Dernière mise à jour des données LastDataUpdate | Horodatage indiquant la dernière actualisation des données de cet enregistrement depuis le système source. | ||
| Description L’horodatage de la dernière mise à jour des données indique à quel moment les données ont été extraites ou synchronisées pour la dernière fois depuis le système source. Il s’agit d’un champ de métadonnées qui renseigne sur l’actualité des données analysées. Dans une analyse en Process Mining, cet attribut est important pour évaluer l’actualité des analyses produites. Il permet de savoir si les informations consultées sont en temps réel ou correspondent à un instantané antérieur. Ce contexte est essentiel pour le suivi opérationnel et pour garantir que les décisions reposent sur des données actuelles et pertinentes. Pourquoi c’est important Il indique l’actualité des données et permet aux analystes de comprendre dans quelle mesure leur analyse du processus reflète la situation présente. Où les obtenir Cette valeur est généralement générée et apposée sur chaque enregistrement lors du 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 | Nom ou identifiant du système depuis lequel les données des incidents ont été extraites. | ||
| Description L’attribut Système source identifie l’origine des données. Dans les environnements qui utilisent plusieurs outils ITSM ou systèmes intégrés, ce champ permet de distinguer les enregistrements provenant de sources différentes. Bien qu’il ne soit pas utilisé directement pour dessiner la cartographie du processus, cet attribut est utile pour la validation et la gouvernance des données. Il aide les analystes à retracer les données jusqu’à leur origine, à comprendre les éventuelles divergences entre les systèmes et à segmenter l’analyse. Il est par exemple possible de comparer, au sein d’une même organisation, les processus de gestion des incidents mis en œuvre dans deux systèmes différents, tels que ServiceNow et Jira. Pourquoi c’est important Il fournit le contexte sur l’origine des données, essentiel pour leur validation, le dépannage et les analyses comparatives dans les environnements multisystèmes. Où les obtenir Il s’agit souvent d’une valeur statique ajoutée lors de l’extraction des données ou d’un champ disponible dans les tables du système source. Exemples ServiceNowJira Service ManagementBMC HelixZendesk | |||
| Agent attribué AssignedAgent | Agent de support ou utilisateur chargé du traitement de l’incident. | ||
| Description L’agent attribué identifie la personne responsable d’un incident. Alors que le groupe attribué désigne l’équipe, l’agent est l’intervenant qui travaille à la résolution. Cet attribut permet une analyse plus détaillée des performances et de la charge de travail. Le suivi des attributions au niveau de l’agent aide les responsables à évaluer la productivité individuelle, à repérer les besoins de formation et à équilibrer la répartition du travail. Dans le Process Mining, il peut révéler des schémas complexes de réattribution qui resteraient invisibles au niveau du groupe et contribuer à comprendre la contribution de chaque personne aux délais de résolution. Pourquoi c’est important Il permet d’analyser en détail la charge de travail individuelle, les performances et les schémas de réattribution au sein des équipes ou entre elles. Où les obtenir Présent dans l’enregistrement principal de l’incident, ce champ est mis à jour lorsqu’un agent prend la responsabilité de l’incident ou se le voit attribuer. Exemples John SmithJane Doeagent.12345Emily Jones | |||
| Canal de signalement ReportingChannel | Méthode ou canal par lequel l’incident a été signalé, par exemple e-mail, téléphone ou portail en libre-service. | ||
| Description Le canal de signalement indique l’origine de la demande d’assistance. Cet attribut permet de suivre la manière dont les utilisateurs sollicitent le support, qu’il s’agisse de moyens de contact directs, comme les appels téléphoniques, ou de moyens automatisés, comme les alertes de supervision système. L’analyse du processus selon le canal de signalement peut révéler des écarts importants d’efficacité. Par exemple, les incidents signalés via un portail en libre-service peuvent être résolus plus rapidement, car ils contiennent souvent dès le départ des informations plus structurées. Cette analyse aide les organisations à optimiser leurs canaux de support et à encourager l’utilisation des méthodes les plus efficaces. Pourquoi c’est important Il aide à analyser l’efficacité et les parcours de résolution des incidents selon leur origine, afin d’éclairer la stratégie de canaux et l’allocation des ressources. Où les obtenir Ces informations sont généralement enregistrées automatiquement ou sélectionnées par l’agent lors de la création de l’incident. Exemples E-mailTéléphonePortail libre-serviceAlerte système | |||
| Catégorie de l’incident IncidentCategory | Classification de l’incident, souvent organisée selon une structure hiérarchique, par exemple Matériel > Ordinateur portable > Batterie. | ||
| Description La catégorie de l’incident fournit une méthode structurée pour classer les incidents selon leur nature. Il s’agit généralement d’un champ hiérarchique permettant d’affiner progressivement la classification et d’organiser les incidents en groupes logiques pour les rapports et les analyses. La catégorisation est essentielle pour l’analyse des causes racines et des tendances. En analysant les cartographies de processus filtrées par catégorie, les organisations peuvent repérer les problèmes récurrents et les schémas associés à certains types d’incidents. Par exemple, le processus de résolution d’un incident « Logiciel » peut ê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 Il est essentiel pour l’analyse des causes racines, l’identification des tendances liées aux incidents récurrents et la compréhension du traitement des différents types de problèmes. Où les obtenir Il s’agit d’un ensemble de champs standard, souvent obligatoires, de l’enregistrement de l’incident, utilisés pour la classification. Exemples Logiciel | Application | Problème de connexionMatériel | Imprimante | Ne répond pasRéseau | Wi-Fi | Connexion lente | |||
| Gravité Severity | Mesure de l’impact métier de l’incident, indiquant dans quelle mesure il affecte les utilisateurs ou les services. | ||
| Description La gravité définit le niveau d’impact d’un incident sur l’activité. Elle répond à la question de savoir à quel point le problème est sérieux, indépendamment de son urgence. Par exemple, une panne généralisée serait un incident de gravité élevée, tandis qu’un défaut esthétique mineur serait de faible gravité. L’analyse des incidents par gravité aide les organisations à comprendre quels types de problèmes provoquent les perturbations les plus importantes. Le Process Mining peut révéler si les incidents de gravité élevée suivent un parcours de résolution différent et mieux optimisé. Cet attribut est essentiel pour l’analyse de la cause racine et pour prioriser les ressources de Gestion des problèmes afin d’éviter la récurrence des incidents les plus graves. Pourquoi c’est important Il permet de segmenter les incidents afin de déterminer si les problèmes à fort impact sont résolus différemment ou plus efficacement que ceux à faible impact. Où les obtenir Champ standard de l’enregistrement de l’incident, souvent utilisé avec l’urgence pour déterminer la priorité. Exemples 1 - Élevée2 - Moyenne3 - FaibleCritique | |||
| Groupe attribué AssignedGroup | Équipe de support, file d’attente ou groupe actuellement responsable du traitement de l’incident. | ||
| Description Le groupe affecté indique quelle équipe est responsable de l’incident à un moment donné. Les incidents sont souvent orientés vers différents groupes, comme le Centre de services de niveau 1, l’équipe Réseau de niveau 2 ou l’équipe d’assistance applicative de niveau 3. Cet attribut est essentiel à l’analyse des transferts et de la charge de travail. Le Process Mining peut utiliser ces données pour visualiser le flux des incidents entre les équipes, mesurer le temps passé dans la file de chaque équipe et identifier les goulots d’étranglement causés par des réaffectations fréquentes. Il aide à répondre aux questions relatives à l’efficacité des équipes et à leur collaboration, et constitue la base du Dashboard d’analyse des transferts et des réaffectations. Pourquoi c’est important Il est essentiel pour analyser les passages de relais entre les équipes, mesurer les temps d’attente dans les files et comprendre les performances et la répartition de la charge propres à chaque équipe. Où les obtenir Ces informations sont généralement stockées dans l’enregistrement de l’incident et mises à jour chaque fois que l’incident est attribué à une nouvelle équipe. Exemples Centre de servicesOpérations réseauAdministration des bases de donnéesSupport applicatif niveau 2 | |||
| Méthode de résolution ResolutionMethod | Code, catégorie ou description indiquant la manière dont l’incident a finalement été résolu. | ||
| Description La méthode de résolution décrit le résultat de l’incident et la manière dont il a été résolu. Il peut s’agir d’un code standardisé ou d’une description en texte libre des actions réalisées. Exemples : « Formation de l’utilisateur », « Correctif logiciel appliqué », « Aucun défaut constaté » ou « Incident en double ». Cet attribut fournit un contexte important sur la fin du processus. Dans le Process Mining, l’analyse des incidents par méthode de résolution aide à évaluer l’efficacité des différentes solutions. Elle peut mettre en évidence les cas clôturés sans véritable correctif ou révéler des schémas de résolution fréquents pour certaines catégories d’incidents. Ces informations peuvent ensuite servir à constituer une base de connaissances et à améliorer le taux de résolution au premier contact. Pourquoi c’est important Il permet de comprendre comment les problèmes sont résolus, ce qui est essentiel pour repérer les possibilités d’automatisation, améliorer la base de connaissances et orienter la formation. Où les obtenir Il s’agit généralement d’un champ renseigné par l’agent de support lorsqu’il fait passer l’incident au statut « Résolu » ou « Fermé ». Exemples Résolu par le centre de servicesAucune défaillance constatéeDoublonMise à jour logicielle déployée | |||
| Priorité Priority | Niveau de priorité attribué à l’incident, qui détermine son degré d’urgence et l’ordre de résolution. | ||
| Description La priorité est un attribut essentiel pour déterminer l’importance relative d’un incident et la rapidité de réponse requise. Elle est souvent calculée à partir de l’impact et de l’urgence de l’incident. Les niveaux vont généralement de critique à faible. Dans le Process Mining, l’analyse des incidents par priorité permet de mieux comprendre la manière dont le processus traite les différents niveaux d’urgence. Les analystes peuvent comparer les délais de résolution des incidents prioritaires et non prioritaires afin de vérifier le respect des SLA et l’efficacité de l’allocation des ressources. Elle permet notamment de répondre à la question suivante : « Nos incidents les plus critiques sont-ils réellement traités en priorité ? » Pourquoi c’est important Il permet d’analyser les performances du processus selon différents niveaux d’urgence et de vérifier que les incidents critiques sont traités plus rapidement que les incidents non critiques. Où les obtenir Disponible comme champ standard de l’enregistrement principal de l’incident. Il peut être défini manuellement ou calculé automatiquement à partir de l’impact et de l’urgence. Exemples 1 - Critique2 - Élevée3 - Moyenne4 - Faible | |||
| Statut de l’incident IncidentStatus | État actuel ou historique de l’incident au cours de son cycle de vie, par exemple « Nouveau », « En cours » ou « Fermé ». | ||
| Description Le statut de l’incident indique l’étape à laquelle se trouve un incident à un moment donné. Il fournit une vue d’ensemble de sa progression dans le processus de résolution. Les statuts courants sont notamment nouveau, affecté, 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 de la carte du processus. L’analyse du temps passé dans chaque statut aide à identifier les goulots d’étranglement, par exemple les incidents qui restent longtemps à l’état « Pending ». Elle sert également à calculer le stock d’incidents ouverts et à suivre l’avancement de leur résolution. Pourquoi c’est important Il est essentiel pour comprendre l’avancement de l’incident et sert souvent à générer les activités de la cartographie du processus. L’analyse du temps passé dans chaque statut aide à localiser les retards. Où les obtenir Généralement disponible comme champ principal de l’enregistrement de l’incident ou dans son journal d’historique. Exemples NouveauEn coursEn attente du clientRésoluFermé | |||
| Demandeur Requester | Utilisateur, employé ou système ayant signalé l’incident initialement. | ||
| Description Le demandeur est la personne qui rencontre le problème et a déclenché le signalement de l’incident. Il peut s’agir d’un employé interne ou d’un client externe. Cet attribut peut également contenir le service ou l’organisation du demandeur. L’analyse des incidents par demandeur ou par service du demandeur aide à déterminer si certains groupes d’utilisateurs rencontrent davantage de problèmes que d’autres. Elle peut révéler des besoins de formation ou des problèmes propres à un environnement local. Dans le Process Mining, elle permet d’adopter une approche centrée sur l’utilisateur et de mieux comprendre l’expérience de différents groupes d’utilisateurs. Pourquoi c’est important Il permet une analyse centrée sur l’utilisateur et aide à déterminer si certains utilisateurs, services ou sites génèrent un nombre disproportionné d’incidents. Où les obtenir Champ standard de l’enregistrement de l’incident, généralement renseigné avec l’utilisateur qui a créé le ticket ou au nom duquel il a été créé. Exemples Alice JohnsonService commercialb.williamsClient-XYZ Corp | |||
| Nombre de réattributions ReassignmentCount | Nombre total de fois où l’incident a été réattribué à un autre agent ou groupe. | ||
| Description Le nombre de réattributions est un indicateur qui comptabilise les passages de relais subis par un incident au cours de son cycle de vie. Un nombre élevé révèle souvent une inefficacité, un routage initial incorrect ou un manque de connaissances au sein des équipes de support. Cet attribut est particulièrement utile pour l’analyse en Process Mining. Même si le Process Mining permet de visualiser les réattributions, disposer d’un compteur précalculé facilite le filtrage et le suivi des KPI. Il est utilisé directement dans le Dashboard d’analyse des passages de relais et des réattributions et aide à repérer les situations de « ping-pong », lorsque les tickets sont transmis d’une équipe à l’autre, ce qui allonge les délais de résolution et augmente l’insatisfaction des utilisateurs. Pourquoi c’est important Cet indicateur quantifie directement l’inefficacité du processus. Un nombre élevé est souvent associé à des délais de résolution plus longs et révèle des problèmes de routage ou de compétences des équipes. Où les obtenir Souvent disponible comme compteur standard dans l’enregistrement de l’incident. À défaut, il peut être calculé en comptant les changements d’attribution dans le journal d’audit de l’incident. Exemples 0135 | |||
| Service affecté AffectedService | Service métier, application ou élément de configuration (CI) affecté par l’incident. | ||
| Description Le service affecté relie un incident à un composant précis de l’infrastructure informatique, tel qu’une application métier, un serveur ou un équipement réseau. Il est souvent associé à une base de données de gestion de configuration (CMDB). Cet attribut fournit un contexte métier important sur l’incident. Dans le Process Mining, il permet d’analyser la fiabilité de services ou d’actifs précis. Les organisations peuvent identifier les services qui génèrent le plus d’incidents, analyser leurs processus de résolution et prioriser les efforts de Gestion des problèmes afin d’améliorer la stabilité des services métier essentiels. Il constitue un élément clé pour comprendre l’impact global des incidents informatiques sur l’activité. Pourquoi c’est important Il relie les incidents à des services métier ou à des composants informatiques précis et permet d’analyser les services les plus sujets aux problèmes ainsi que leur impact. Où les obtenir Généralement lié depuis une base de données de gestion de configuration (CMDB) ou sélectionné dans une liste du catalogue de services sur le formulaire d’incident. Exemples Services de messagerieSAP ERP FinancialsVPN d'entrepriseSRV-SQL-01 | |||
| Statut du SLA SlaStatus | Indique si l’incident respecte les objectifs de son accord de niveau de service (SLA), s’il risque de les dépasser ou s’il les a déjà dépassés. | ||
| Description Le statut du SLA fournit un aperçu de la performance d’un incident par rapport à des objectifs de délai prédéfinis, tels que le délai de réponse ou de résolution. Les statuts courants sont notamment « En cours », « À risque » et « Dépassé ». Cet attribut mesure directement la qualité du service et constitue une donnée essentielle du Dashboard de suivi des performances des SLA. Dans le Process Mining, il permet de comparer les parcours des incidents ayant dépassé leur SLA à ceux qui l’ont respecté. Cette comparaison aide à identifier les activités, retards ou boucles de reprise qui sont à l’origine des échecs de SLA et à cibler les améliorations du processus. Pourquoi c’est important Il mesure directement la performance par rapport aux objectifs. L’analyse des incidents ayant dépassé leur SLA aide à repérer les défaillances du processus qui dégradent la qualité du service. Où les obtenir Il s’agit généralement d’un champ calculé dans l’outil ITSM, mis à jour dynamiquement selon la priorité et l’ancienneté de l’incident ainsi que les règles de SLA définies. Exemples En coursEn pauseSLA dépasséÀ risque | |||
Activités de la Gestion des incidents
| Activité | Description | ||
|---|---|---|---|
| Début de l’investigation | Indique qu’un agent affecté a commencé à travailler activement sur l’incident. Cela se traduit souvent par le passage du statut « Assigned » ou « New » au statut « In Progress ». | ||
| Pourquoi c’est important Ce jalon marque la fin du temps d’attente initial dans la file et le début du travail actif. Mesurer le délai jusqu’à cette activité aide à comprendre la capacité des agents et les retards de réponse. Où les obtenir Cet événement est généralement déduit d’un changement de statut dans le journal d’historique de l’incident. Collecte Identifiez l’horodatage auquel le statut de l’incident passe pour la première fois à « In Progress », « Work in Progress » ou à un état actif similaire. Type d’événement inferred | |||
| Groupe affecté | Indique l’affectation initiale de l’incident à un groupe ou une équipe d’assistance précis pour investigation. Il s’agit du premier transfert officiel et du début du flux de résolution. | ||
| Pourquoi c’est important Il s’agit d’une étape de routage essentielle. Les retards d’affectation ou un routage incorrect peuvent allonger considérablement les délais de résolution et entraîner des transferts inutiles entre les équipes. Où les obtenir Cet événement est déduit du journal d’audit en recherchant la première occurrence où un champ « Assignment Group » ou « Support Team » est renseigné. Collecte Identifiez l’horodatage du premier renseignement du champ « Assignment Group » dans l’historique de l’incident. Type d’événement inferred | |||
| Incident créé | Cette activité marque la création officielle d’un enregistrement d’incident dans le système. Elle constitue le début définitif du cycle de vie de l’incident et enregistre le signalement initial transmis par un utilisateur ou un outil de supervision. | ||
| Pourquoi c’est important Il s’agit du principal événement de début du processus. L’analyse du temps écoulé entre la création et les autres jalons est fondamentale pour mesurer le délai global de résolution et identifier les retards en amont. Où les obtenir Cet événement est généralement capturé à partir de l’horodatage de création de la table principale des incidents ou des tickets dans le système source. Collecte Utilisez l’horodatage « create_date » ou « submitted_on » de l’enregistrement principal de l’incident. Type d’événement explicit | |||
| Incident fermé | Dernière activité du cycle de vie, au cours de laquelle la fiche de l’incident est officiellement fermée et devient un enregistrement historique en lecture seule. Cette étape intervient souvent automatiquement après une période définie à l’état « Résolu ». | ||
| Pourquoi c’est important Cette étape marque la fin absolue du cycle de vie de l’incident. L’analyse de la durée totale entre la création et la clôture fournit une vue complète de la durée du processus, y compris les éventuelles périodes administratives suivant la résolution. Où les obtenir Enregistré à partir d’une modification explicite du statut sur « Fermé » dans l’historique de l’incident, qui fournit un horodatage final. Collecte Utilisez l’horodatage du journal d’audit lorsque le statut de l’incident est mis à jour sur « 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. Il s’agit d’une étape importante qui arrête généralement le décompte du délai de résolution du SLA. | ||
| Pourquoi c’est important Il s’agit d’un point de référence essentiel pour mesurer le délai de résolution. La période entre cette étape et la clôture définitive est importante pour analyser les délais de confirmation par l’utilisateur ou les règles de clôture automatique. Où les obtenir Il s’agit presque toujours d’un événement explicite enregistré lorsqu’un agent modifie le statut de l’incident pour le définir sur « Résolu » ou « Solutionné ». Collecte Utilisez l’horodatage du journal d’audit lorsque le statut de l’incident est mis à jour sur « Résolu ». Type d’événement explicit | |||
| Incident rouvert | Se produit lorsqu’un incident précédemment résolu repasse à l’état actif. Cela arrive généralement lorsque l’utilisateur signale que le problème s’est reproduit ou que la solution fournie n’était pas efficace. | ||
| Pourquoi c’est important Un taux élevé de réouverture peut révéler des problèmes liés à la qualité de la résolution, à une analyse incomplète de la cause racine ou à une clôture prématurée. Il s’agit d’un indicateur important pour analyser les reprises. Où les obtenir Déduit de l’historique des statuts lorsqu’un incident passe de « Résolu » ou « Fermé » à un état actif tel que « En cours ». Collecte Détectez le passage d’un état résolu à un état ouvert et enregistrez l’horodatage de cette modification. Type d’événement inferred | |||
| Violation de SLA détectée | Événement calculé qui se produit lorsque le délai nécessaire pour répondre à un incident ou le résoudre dépasse les objectifs définis dans son accord de niveau de service (SLA). Il ne s’agit pas d’une action manuelle de l’utilisateur, mais du résultat d’un délai écoulé. | ||
| Pourquoi c’est important Les violations de SLA constituent un indicateur clé de performance (KPI) majeur. Analyser le moment et les raisons de leur apparition est essentiel pour améliorer la prestation de services et respecter les obligations contractuelles. Où les obtenir Cet événement n’apparaît pas directement dans les journaux. Il est calculé en comparant les horodatages des événements aux échéances cibles du SLA enregistrées dans la fiche de l’incident. Collecte Comparez l’horodatage de résolution à la « SLA Due Date ». Si la résolution est postérieure, créez un événement de violation à l’horodatage de l’échéance du SLA. Type d’événement calculated | |||
| Agent affecté | Cette activité marque le moment où un agent précis prend en charge l’incident ou en devient responsable. Elle représente le passage d’une responsabilité au niveau de l’équipe à une responsabilité individuelle. | ||
| Pourquoi c’est important Le suivi de l’affectation des agents aide à analyser les charges de travail individuelles et la performance, ainsi qu’à identifier les goulots d’étranglement où les incidents attendent la disponibilité d’un agent. Où les obtenir Capturé en suivant les modifications apportées au champ « Assignee » ou « Assigned To » dans le journal d’audit de l’incident. Collecte Utilisez l’horodatage du journal d’audit correspondant au premier renseignement du champ « Assignee » ou à son changement pour un nouvel utilisateur. Type d’événement explicit | |||
| Incident catégorisé | Représente la classification de l’incident, notamment la définition de sa catégorie, de son type et de son élément. Il s’agit d’une étape de triage essentielle qui permet d’orienter 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é aide à évaluer la qualité du triage initial et son impact sur l’efficacité de la résolution. Où les 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 où les champs liés à la catégorisation sont renseignés. Collecte Détectez la première mise à jour de champs tels que « Category », « Subcategory » ou « Configuration Item » 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é détermine les délais cibles de réponse et de résolution conformément aux accords de niveau de service (SLA). | ||
| Pourquoi c’est important La priorisation influence directement l’affectation des ressources et l’ordre de traitement des incidents. L’analyse de cette étape permet de vérifier que les incidents critiques sont traités en premier et que les SLA sont respectés. Où les obtenir Cet événement est capturé en surveillant les modifications apportées au champ « Priority » ou « Severity » dans la piste d’audit. Collecte Utilisez l’horodatage du journal d’audit associé à la mise à jour du champ « Priority ». 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 intervient souvent lorsque l’équipe initiale ne peut pas résoudre le problème et qu’une expertise différente est nécessaire. | ||
| Pourquoi c’est important Des réaffectations fréquentes indiquent fortement une inefficacité du processus, un routage initial incorrect ou des lacunes dans les connaissances de l’équipe. L’analyse de ces transferts est essentielle pour optimiser le parcours de résolution. Où les obtenir Déduit du journal d’audit en détectant toute modification du champ « Assignment Group » ou « Assignee » après l’affectation initiale. Collecte Créez un nouvel événement pour chaque modification du champ « Assignment Group » après son premier renseignement. Type d’événement inferred | |||
| Reprise du travail | Marque le moment où un incident mis en attente est réactivé. Cela se produit généralement lorsque les informations requises sont reçues et que l’agent de support peut reprendre son travail. | ||
| Pourquoi c’est important Cette activité est essentielle pour mesurer précisément la durée des attentes externes. Le temps écoulé entre « Pending » et « Resumed » indique la durée pendant laquelle le processus a été interrompu par des facteurs externes. Où les obtenir Déduit de l’historique des statuts de l’incident lorsque celui-ci passe de l’état « Pending » à l’état « In Progress » ou à un autre état actif. Collecte Capturez l’horodatage auquel le statut de l’incident passe d’un état « pending » à un état actif. Type d’événement inferred | |||
| Solution de contournement fournie | Indique qu’une solution temporaire a été communiquée à l’utilisateur afin de rétablir le fonctionnement du service. Elle limite l’impact sur l’activité pendant l’élaboration d’une correction définitive. | ||
| Pourquoi c’est important La fourniture d’une solution de contournement est une étape importante de la Gestion des incidents majeurs. Elle permet de suivre séparément le délai de réduction de l’impact et le délai de résolution définitive. Où les obtenir Il peut s’agir d’un statut ou d’un indicateur explicite, mais cet événement est souvent déduit des notes des agents ou des journaux de communication à l’aide d’une analyse par mots-clés. Collecte Identifiez-le à l’aide d’un statut précis tel que « Workaround Provided » ou en recherchant des mots-clés comme « workaround » ou « temporary fix » dans les commentaires des agents. Type d’événement inferred | |||
| Statut passé à « Pending » | Se produit lorsque l’avancement d’un incident est suspendu, généralement dans l’attente d’informations de l’utilisateur, d’un fournisseur ou d’une autre dépendance externe. Cet état suspend généralement le décompte du SLA. | ||
| Pourquoi c’est important L’analyse du temps passé dans un é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 indicateurs de délai de résolution. Où les obtenir Déduit de l’historique des statuts de l’incident lorsque celui-ci passe à l’état « Pending », « On Hold » ou « Awaiting User ». Collecte Capturez l’horodatage à chaque changement du statut de l’incident vers un état « pending » désigné. Type d’événement inferred | |||
Guides d’extraction
Les méthodes d’extraction varient selon le système. Pour obtenir des instructions détaillées,
Prêt à commencer ?
Commencez dès aujourd’hui à transformer votre processus de gestion des incidents. Choisissez ci-dessous un guide d’extraction propre à votre système ou utilisez ce modèle générique pour commencer à constituer votre journal d’événements et réaliser des analyses puissantes de vos processus.
Résolvez les incidents plus rapidement, commencez votre transformation dès maintenant
Repérez les goulots d’étranglement, réduisez les temps d’arrêt et améliorez l’efficacité de vos équipes.
Aucune carte bancaire requise, configuration en 5 minutes