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

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 être associée à un horodatage afin d’établir l’ordre 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 total de résolution de l’incident. L’analyse des horodatages aide les organisations à repérer les goulots d’étranglement, à mesurer le respect des SLA et à suivre l’évolution des performances du processus. Elle constitue la base du calcul d’indicateurs clés comme le délai moyen de résolution.

Il établit l’ordre chronologique des événements, indispensable pour calculer les durées, repérer les goulots d’étranglement et analyser l’évolution des performances du processus.

Disponible dans les journaux d’événements, les tables d’historique d’audit ou les champs « dernière modification » et « date de création » des enregistrements associés.

L’ID de l’incident est un code alphanumérique unique qui le distingue de tous les autres incidents du système. Il est généré à la création de l’incident et reste inchangé jusqu’à son archivage définitif ou sa suppression.

En Process Mining, l’ID de l’incident est la clé de l’analyse et sert d’ID de cas. Il permet au logiciel de rassembler les événements, changements de statut et activités associés dans une seule instance de processus. En regroupant tous les événements sous un même ID d’incident, les analystes peuvent reconstituer avec précision le parcours de bout en bout de chaque incident, de son signalement initial à sa résolution et à sa clôture.

Cet identifiant est indispensable pour relier les activités et événements associés et reconstituer le cycle de vie complet de l’incident en Process Mining.

Il s’agit de la clé principale d’un incident. Elle se trouve généralement dans l’en-tête ou l’enregistrement principal de chaque table ou objet d’incident.

Le nom de l’activité décrit une étape ou une tâche distincte du processus de gestion des incidents. Ces activités constituent les éléments de base de la cartographie du processus. Elles peuvent correspondre à des événements système automatisés, comme « Dépassement du SLA détecté », ou à des actions manuelles, comme « Agent affecté » ou « Solution de contournement fournie ».

En Process Mining, cet attribut est fondamental. Il définit les nœuds du graphe du processus et permet aux analystes de visualiser le flux de travail, de repérer les parcours fréquents, de détecter les goulots d’étranglement et d’analyser les écarts par rapport à la procédure standard. La précision et la clarté des noms d’activité influent directement sur la qualité et le niveau de détail des analyses.

Cet attribut définit les étapes du processus et permet de visualiser et d’analyser le déroulement du cycle de vie de l’incident.

Souvent établi à partir d’une combinaison de journaux d’événements, de pistes d’audit, d’enregistrements des changements de statut ou de champs de description des tâches dans le système de gestion des incidents.

L’horodatage de la dernière mise à jour des données indique quand celles-ci ont été extraites ou synchronisées pour la dernière fois depuis le système source. Ce champ de métadonnées renseigne sur leur fraîcheur.

En Process Mining, cet attribut permet de savoir si les analyses sont à jour. Il indique si les utilisateurs consultent des informations en temps réel ou un instantané antérieur. Ce contexte est essentiel au suivi opérationnel et permet de fonder les décisions sur des données actuelles et pertinentes.

Il indique si les données sont à jour et permet aux analystes de savoir à quel point leur analyse du processus est récente.

Cette valeur est généralement générée et ajoutée à chaque enregistrement lors du processus d’extraction et de transformation des données (ETL).

L’attribut Système source indique l’origine des données. Dans les environnements qui utilisent plusieurs outils ITSM ou des systèmes intégrés, ce champ permet de distinguer les enregistrements provenant de différentes sources.

Cet attribut n’intervient pas directement dans la représentation du processus, mais il est utile pour la validation et la gouvernance des données. Il aide les analystes à retrouver leur origine, à comprendre les écarts éventuels entre les systèmes et à segmenter l’analyse. Par exemple, il est 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, comme ServiceNow et Jira.

Il précise l’origine des données, une information importante pour leur validation, la résolution des problèmes et les analyses comparatives dans les environnements multi-systèmes.

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.

L’agent affecté désigne la personne chargée de traiter un incident. Le groupe affecté indique l’équipe responsable, tandis que l’agent est la personne qui intervient pour le résoudre.

Cet attribut permet d’analyser plus finement les performances et la charge de travail. En suivant les affectations au niveau individuel, les responsables peuvent évaluer la productivité, repérer les besoins de formation et veiller à une répartition équilibrée du travail. En Process Mining, il peut révéler des schémas complexes de réaffectation qui ne sont pas visibles au niveau des groupes et aider à comprendre la contribution de chacun aux délais de résolution.

Il permet d’analyser en détail la charge de travail, les performances et les réaffectations de chaque personne au sein des équipes ou entre elles.

Ce champ figure dans la fiche principale de l’incident. Il est mis à jour lorsqu’un agent prend en charge l’incident ou qu’il lui est affecté.

Le canal de signalement indique par quel moyen l’incident a été soumis. Cet attribut permet de suivre la manière dont les utilisateurs sollicitent l’assistance, que ce soit par un contact direct, comme un appel téléphonique, ou par un moyen automatisé, comme une alerte de surveillance système.

L’analyse du processus selon le canal de signalement peut révéler des différences importantes d’efficacité. Par exemple, les incidents signalés via un portail libre-service peuvent être résolus plus rapidement, car les informations fournies sont souvent mieux structurées dès le départ. Cette analyse aide les organisations à optimiser leurs canaux d’assistance et à encourager l’utilisation des méthodes les plus efficaces.

Il permet d’analyser l’efficacité et les parcours de résolution des incidents selon leur origine, afin d’orienter la stratégie de gestion des canaux et la répartition des ressources.

Cette information est généralement enregistrée automatiquement ou sélectionnée par l’agent lors de la création de l’incident.

La catégorie de l’incident permet de le classer selon sa nature. Il s’agit généralement d’un champ hiérarchique qui permet d’affiner progressivement la classification et de regrouper les incidents de manière cohérente pour faciliter les rapports et les analyses.

La catégorisation est essentielle à l’analyse des causes profondes et des tendances. En examinant 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 comme la précision de la catégorisation initiale et le taux d’incidents récurrents.

Cet attribut est essentiel pour analyser les causes profondes, repérer les tendances parmi les incidents récurrents et comprendre le traitement des différents types de problèmes.

Il s’agit d’un ensemble de champs standard, souvent obligatoires, de la fiche d’incident, utilisés pour la classification.

La gravité indique l’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 touchant l’ensemble du système est un incident de gravité élevée, tandis qu’un défaut esthétique mineur est de faible gravité.

L’analyse des incidents par gravité aide les organisations à comprendre quels types de problèmes perturbent le plus leur activité. Le Process Mining peut révéler si les incidents graves suivent un parcours de résolution différent et plus direct. Cet attribut est important pour l’analyse des causes profondes et la répartition des ressources consacrées à la gestion préventive des problèmes, afin d’éviter la réapparition des incidents les plus graves.

Il permet de segmenter les incidents et de déterminer si les problèmes à fort impact sont résolus différemment ou plus efficacement que ceux à faible impact.

Champ standard de la fiche d’incident, souvent utilisé avec l’urgence pour déterminer la priorité.

Le groupe affecté indique quelle équipe est responsable de l’incident à un moment donné. Les incidents sont souvent transférés entre différents groupes, par exemple le Centre de services de niveau 1, une équipe réseau de niveau 2 ou une é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 s’appuyer sur ces données pour représenter les transferts d’incidents entre équipes, mesurer le temps passé dans la file de chaque équipe et repérer les goulots d’étranglement dus aux réaffectations fréquentes. Il aide à évaluer l’efficacité et la collaboration des équipes, et constitue la base du Dashboard d’analyse des transferts et des réaffectations.

Il est essentiel pour analyser les transferts entre équipes, mesurer les temps d’attente dans les files et comprendre les performances et la répartition de la charge de travail propres à chaque équipe.

Cette information est généralement enregistrée dans la fiche de l’incident et mise à jour chaque fois que celui-ci est affecté à une nouvelle équipe.

La méthode de résolution décrit le résultat obtenu et la manière dont l’incident a été résolu. Il peut s’agir d’un code standardisé ou d’une description libre des actions menées. Exemples : « Conseils à l’utilisateur », « Correctif logiciel appliqué », « Aucun défaut constaté » ou « Incident en double ».

Cet attribut apporte un contexte important sur l’issue du processus. En Process Mining, l’analyse des incidents selon leur 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 faire ressortir les méthodes courantes pour certaines catégories d’incidents. Ces informations peuvent ensuite servir à constituer une base de connaissances et à améliorer le taux de résolution dès le premier contact.

Il permet de comprendre comment les problèmes sont résolus et de repérer les possibilités d’automatisation, d’amélioration de la base de connaissances et de formation.

Il s’agit généralement d’un champ renseigné par l’agent d’assistance lorsqu’il fait passer l’incident au statut « Résolu » ou « Clos ».

La priorité est un attribut clé pour déterminer l’importance relative d’un incident et la rapidité de réponse requise. Elle est souvent établie à partir 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 de mieux comprendre comment le processus traite les différents degrés d’urgence. Les analystes peuvent comparer les délais de résolution des incidents prioritaires et moins prioritaires afin de vérifier le respect des SLA et la répartition des ressources. Ils peuvent ainsi répondre à des questions comme : « Les incidents les plus critiques sont-ils réellement traités en premier ? »

Il permet d’analyser les performances du processus selon le degré d’urgence et de vérifier si les incidents critiques sont traités plus rapidement que les autres.

Disponible dans un champ standard de la fiche principale de l’incident. La priorité peut être définie manuellement ou calculée automatiquement à partir de l’impact et de l’urgence.

Le statut de l’incident indique à quelle étape il se trouve à un moment donné. Il donne une vue d’ensemble de son avancement vers la résolution. Les statuts courants sont notamment : nouveau, affecté, en cours de traitement, en attente, résolu et clos.

Cet attribut est fondamental pour l’analyse des processus, car les changements de statut définissent souvent les activités représentées dans la cartographie du processus. L’analyse du temps passé dans chaque statut permet de repérer les retards, par exemple lorsqu’un incident reste longtemps « En attente ». Le statut sert également à calculer le nombre d’incidents ouverts en attente de traitement et à suivre leur progression vers la résolution.

Il permet de suivre 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 à repérer les retards.

Généralement disponible dans un champ principal de la fiche de l’incident ou dans son journal d’historique.

Le demandeur est la personne qui rencontre le problème et a signalé l’incident. Il peut s’agir d’un employé interne ou d’un client externe. Cet attribut peut également indiquer le service ou l’organisation du demandeur.

L’analyse des incidents par demandeur ou par service permet de repérer les groupes d’utilisateurs qui rencontrent davantage de problèmes. Cela peut révéler des besoins de formation ou des problèmes liés à un environnement local. En Process Mining, cet attribut permet d’analyser le processus d’assistance du point de vue des utilisateurs et de comprendre l’expérience de différents groupes.

Il permet d’analyser le processus du point de vue des utilisateurs et de repérer si certains utilisateurs, services ou sites génèrent une part disproportionnée des incidents.

Champ standard de la fiche d’incident, généralement renseigné avec le nom de l’utilisateur qui a créé le ticket ou pour le compte duquel il a été créé.

L’état du SLA donne un aperçu du respect, par un incident, des délais définis, par exemple le délai de réponse ou de résolution. Les états courants sont « En cours », « À risque » ou « Non respecté ».

Cet attribut mesure directement la qualité du service et constitue une donnée essentielle du Dashboard Vue d’ensemble de la performance du SLA. Le Process Mining permet de comparer les flux de travail des incidents qui respectent le SLA à ceux des incidents qui ne le respectent pas. Vous pouvez ainsi repérer les activités, les retards ou les boucles de reprise qui sont à l’origine des manquements et cibler les améliorations à apporter au processus.

Il mesure directement le respect des objectifs. L’analyse des incidents pour lesquels le SLA n’a pas été respecté permet de repérer les défaillances du processus qui nuisent à la qualité du service.

Il s’agit généralement d’un champ calculé dans l’outil ITSM, mis à jour automatiquement en fonction de la priorité et de l’ancienneté de l’incident, ainsi que des règles de SLA définies.

Le nombre de réaffectations indique combien de fois un incident a été transféré au cours de son cycle de vie. Un nombre élevé peut révéler un manque d’efficacité, une mauvaise orientation initiale ou des lacunes dans les connaissances des équipes d’assistance.

Cet attribut est utile à l’analyse en Process Mining. Le Process Mining permet de visualiser les réaffectations, mais disposer d’un décompte préétabli facilite le filtrage et le suivi des KPI. Il est utilisé directement dans le Dashboard d’analyse des transferts et des réaffectations et aide à repérer les situations de « ping-pong », où les tickets circulent entre les équipes, ce qui allonge les délais de résolution et frustre les utilisateurs.

Cette métrique quantifie directement le manque d’efficacité du processus. Un nombre élevé de réaffectations est souvent associé à des délais de résolution plus longs et peut révéler des problèmes d’orientation ou de compétences au sein des équipes.

Souvent disponible sous la forme d’un compteur standard dans la fiche de l’incident. À défaut, il peut être calculé en comptant les changements d’affectation dans le journal d’audit de l’incident.

Le service affecté relie un incident à un composant précis de l’infrastructure informatique, comme une application métier, un serveur ou un équipement réseau. Il est souvent associé à une base de données de gestion des configurations (CMDB).

Cet attribut apporte un contexte métier important à l’incident. En Process Mining, il permet d’analyser la fiabilité de services ou d’actifs précis. Les organisations peuvent repérer les services qui génèrent le plus d’incidents, analyser leurs parcours de résolution et prioriser la gestion des problèmes afin d’améliorer la stabilité des services métier essentiels. Il aide à comprendre plus largement l’impact des incidents informatiques sur l’activité.

Il relie les incidents à des services métier ou à des composants informatiques précis, ce qui permet de déterminer quels services sont les plus sujets aux problèmes et d’en mesurer l’impact.

Généralement associé à une base de données de gestion des configurations (CMDB) ou sélectionné dans la liste du catalogue de services du formulaire d’incident.