Votre modèle de données pour la gestion des problèmes
Votre modèle de données pour la gestion des problèmes
Voici notre modèle de données générique de Process Mining pour Gestion des problèmes. Utilisez nos modèles spécifiques au système pour des directives plus précises.
Sélectionnez un système spécifique- Un cadre universel applicable à tout système de Gestion des problèmes.
- Champs de données et étapes de processus recommandés pour une analyse complète.
- Des informations clées pour démarrer efficacement votre projet de Process Mining.
Attributs de gestion des problèmes
| Nom | Descriptionn | ||
|---|---|---|---|
| Heure de l'événement EventTime | La date et l'heure exactes auxquelles une activité spécifique s'est produite. | ||
| Descriptionn Le temps d'événement, ou horodatage, fournit le contexte chronologique de chaque activité dans le cycle de vie du problème. Il est indispensable pour séquencer correctement les événements et pour calculer les durées entre les différentes étapes du processus. En Process Mining, cet attribut est utilisé pour ordonner les activités, découvrir le modèle de processus et effectuer toutes les analyses temporelles. Il est la base du calcul des indicateurs clés de performance tels que le 'Temps moyen d'investigation des causes racines' et de l'identification des retards entre les étapes, comme le transfert entre l'identification d'une cause racine et l'initiation d'une demande de changement. Pourquoi est-ce important ? : L'horodatage pour chaque activité est impératif pour ordonner les événements et calculer toutes les métriques temporelles, telles que les temps de cycle et les durées des points de blocage. Source des données : Ce Exemples 2023-04-15T10:22:05Z2023-11-20T14:05:30Z2024-01-08T09:00:11Z | |||
| ID de l'Enregistrement de Problème ProblemRecordId | L'identifiant unique d'un enregistrement de problème, qui représente une seule instance du processus de gestion des problèmes. | ||
| Descriptionn L'ID de l'enregistrement de problème sert de clé primaire pour suivre l'intégralité du cycle de vie d'un problème, de sa création à sa résolution finale. Chaque problème, qui peut être lié à plusieurs incidents, se voit attribuer un ID unique pour le distinguer de tous les autres problèmes. Dans le Process Mining, cet attribut est clé car il définit le cas, permettant à l'outil de regrouper toutes les activités liées en une seule instance de processus. L'analyse des flux de processus, l'identification des points de blocage et le calcul des durées de cas dépendent tous de l'identification correcte de chaque enregistrement de problème unique. Pourquoi est-ce important ? : C'est l'identifiant de Source des données : Cet identifiant se trouve généralement dans la table principale des problèmes ou des Exemples PRB0040332PROB-1298778103PM-5501 | |||
| Nom de l'activité ActivityName | Le nom d'un événement, d'une tâche ou d'un changement de statut spécifique survenu dans le cycle de vie de la gestion des problèmes. | ||
| Descriptionn Le Nom de l'Activité décrit une étape unique dans le processus de gestion des problèmes, telle que 'Enregistrement de Problème Créé', 'Cause Racine Identifiée' ou 'Correctif Permanent Implémenté'. Ces activités sont enregistrées chronologiquement pour reconstituer l'histoire de la manière dont un problème a été traité. Pour le Process Mining, cet attribut est indispensable pour construire la carte de processus, qui représente visuellement le flux de travail réel. L'analyse de la séquence, de la fréquence et des chemins de ces activités aide à découvrir les écarts, les points de blocage et les inefficacités dans le processus de résolution des problèmes. Pourquoi est-ce important ? : Cet Source des données : Les noms d'activité sont souvent dérivés des journaux de changement de statut, des pistes d'audit ou des tables d'événements associées à l'enregistrement de problème principal. Exemples Enquête initiéePriorité modifiéeSolution de contournement fournieEnregistrement de problème clôturé | |||
| Dernière mise à jour des données LastDataUpdate | L'horodatage indiquant la dernière extraction ou le dernier rafraîchissement des données depuis le système source. | ||
| Descriptionn Cet Dans les Pourquoi est-ce important ? : Fournit un contexte essentiel sur la la réactualisation des données, garantissant que les analyses et les dashboards sont interprétés correctement en fonction de la dernière actualisation des données. Source des données : Ce Exemples 2023-10-01T06:00:00Z2024-02-20T08:00:00Z2024-03-15T05:30:00Z | |||
| Système source SourceSystem | Le nom de l'application ou du système à partir duquel les données ont été extraites. | ||
| Descriptionn Cet Dans le contexte du Pourquoi est-ce important ? : Identifie l'origine des données, ce qui est impératif pour la validation des données et pour comparer les processus entre différents systèmes ou unités organisationnelles. Source des données : C'est généralement une valeur statique ajoutée pendant le Exemples ServiceNowJira Service ManagementBMC Helix ITSMFreshservice | |||
| Catégorie de cause profonde RootCauseCategory | La classification finale de la cause sous-jacente ayant conduit au problème. | ||
| Descriptionn Une fois l'investigation terminée, la Catégorie de cause profonde est utilisée pour classer la raison clée du problème, telle que 'Défaut Logiciel', 'Défaillance Matérielle' ou 'Erreur de Configuration'. Cette catégorisation est fondamentale pour l'amélioration stratégique. Cet attribut est l'élément central du tableau de bord 'Performance de l'Investigation des Causes Racines'. En analysant la fréquence des différentes catégories de causes racines, les organisations peuvent identifier les problèmes systémiques récurrents et prioriser les correctifs à long terme. Il aide à passer d'une résolution de problèmes réactive à une stratégie de prévention. Pourquoi est-ce important ? : C'est indispensable pour l'analyse stratégique, aidant à identifier les problèmes systémiques et les tendances des causes de problèmes à travers l'organisation. Source des données : Ces informationsns sont généralement saisies dans un champ dédié de l'enregistrement du problème, souvent rempli avant ou pendant la phase de clôture. Exemples Erreur de configurationDéfaut LogicielPanne MatérielleProblème de Formation Utilisateur | |||
| Date d'échéance du SLA SlaDueDate | La date et l'heure cibles auxquelles l'enregistrement du problème devrait être résolu conformément à l'accord de niveau de service. | ||
| Descriptionn La Date d'Échéance SLA fixe un objectif formel pour la résolution des problèmes. Cet objectif est généralement déterminé en fonction de la priorité du problème et des termes définis dans l'accord de niveau de service (SLA). Cet attribut est indispensable pour le tableau de bord 'Vue d'ensemble de la conformité SLA'. En comparant le temps de résolution réel avec la Date d'Échéance SLA, les organisations peuvent calculer les taux de réussite SLA. Le Process Mining peut ensuite décomposer cela pour identifier quelles étapes de processus ou équipes contribuent le plus aux violations de SLA. Pourquoi est-ce important ? : Définit l'objectif de résolution, constituant la base de toutes les mesures et rapports de conformité aux SLA. Source des données : Cette date est généralement calculée et stockée sur l'enregistrement du problème en fonction de son Exemples 2023-05-20T17:00:00Z2024-01-10T09:30:00Z2024-03-01T12:00:00Z | |||
| Groupe de support SupportGroup | L'équipe technique ou le département responsable de l'investigation et de la résolution du problème à un moment donné. | ||
| Descriptionn Le Groupe de Support indique l'équipe assignée au problème. Au fur et à mesure que le problème progresse, il peut être réaffecté entre différents groupes, par exemple d'une équipe de support de Niveau 2 à une équipe spécialisée en Ingénierie Réseau. Cet attribut est indispensable pour analyser la performance des équipes et les transferts inter-équipes. Le Process Mining peut mettre en évidence les retards causés par les réaffectations, mesurer le temps que les problèmes restent avec chaque groupe, et identifier quelles équipes sont les plus efficaces pour résoudre certains types de problèmes. Il supporte directement des dashboards tels que 'Analyse des Transferts de Groupe de Support'. Pourquoi est-ce important ? : Primordial pour analyser la performance de l'équipe, identifier les points de blocage causés par les transferts, et comprendre la répartition de la charge de travail entre les différentes équipes. Source des données : Ces informationsns sont généralement stockées dans l'historique des affectations ou dans la table des détails principaux de l'enregistrement du problème au sein du système ITSM. Exemples Opérations RéseauAdministration de Bases de `Données`Support Applicatif L3Équipe de Sécurité | |||
| Nombre d'incidents associés RelatedIncidentCount | Le nombre total d'enregistrements d'incidents individuels liés au problème. | ||
| Descriptionn Cet Cette métrique est un outil puissant pour la priorisation et l'analyse d'impact. En Pourquoi est-ce important ? : Quantifie l'impact commercial d'un problème, aidant à prioriser les enquêtes et à mesurer l'efficacité de la résolution. Source des données : Cette valeur est souvent un champ calculé sur l'enregistrement du problème qui compte le nombre d'enregistrements d'incidents liés. Exemples 5281501 | |||
| Nombre de Réaffectations ReassignmentCount | Le nombre de fois où l'enregistrement du problème a été réaffecté entre différents groupes de support ou individus. | ||
| Descriptionn Cette métrique compte le nombre de fois où la responsabilité d'un problème a été transférée. Un nombre élevé de réaffectations indique souvent une inefficacité du En Pourquoi est-ce important ? : Aide à quantifier l'inefficacité des processus en suivant les transferts excessifs, qui indiquent souvent un routage incorrect, des lacunes de connaissances ou des responsabilités peu claires. Source des données : Il s'agit souvent d'un champ de compteur qui est incrémenté sur l'enregistrement du problème à chaque changement d'affectation. Il peut également être calculé à partir du Exemples 0135 | |||
| Priorité Priority | Le niveau de priorité attribué au problème, qui dicte l'urgence de l'investigation et de la résolution. | ||
| Descriptionn La priorité est un attribut clé utilisé pour classer les problèmes en fonction de leur impact commercial et de leur urgence. Elle aide les équipes à concentrer leurs efforts sur les problèmes les plus critiques en premier lieu. Les niveaux de priorité sont souvent standardisés, tels que Critique, Élevé, Moyen et Faible. En analyse de processus, la Priorité est une dimension essentielle pour le filtrage et la comparaison. Les analystes peuvent comparer le flux de processus pour les problèmes de haute priorité par rapport à ceux de basse priorité pour voir s'ils sont traités différemment ou plus efficacement. Elle est également clée pour l'analyse de la conformité aux SLA, car les SLA sont souvent liés aux niveaux de priorité. Pourquoi est-ce important ? : Permet de segmenter l'analyse pour comparer la gestion des problèmes critiques par rapport aux problèmes de routine, et est indispensable pour mesurer le respect des SLA. Source des données : C'est un champ standard dans la table principale des enregistrements de problèmes de la plupart des plateformes ITSM. Exemples 1 - Critique2 - Élevée3 - Moyenne4 - Faible | |||
| Service affecté AffectedService | Le service métier principal, l'application ou l'élément de configuration (CI) impacté par le problème. | ||
| Descriptionn Cet Dans l'analyse par Pourquoi est-ce important ? : Fournit un contexte métier en liant les problèmes techniques aux services qu'ils impactent, permettant une priorisation basée sur la criticité pour l'entreprise. Source des données : Ceci est généralement lié à une base de données de gestion de configuration (CMDB) et stocké dans un champ « Élément de configuration » ou « Service » sur l'enregistrement du problème. Exemples Services de Courriel et de CollaborationSAP ERP FinancialsVPN d'entrepriseSite Web Principal du Client | |||
| SLA Non Respecté SlaBreached | Un indicateur signalant si la résolution du problème a dépassé sa date limite SLA assignée. | ||
| Descriptionn Cet En tant que mesure de résultat direct, cet indicateur est extrêmement utile pour la création de Pourquoi est-ce important ? : Fournit un résultat clair de succès ou d'échec pour la conformité aux SLA, ce qui facilite le filtrage et l'analyse des chemins de processus qui conduisent aux non-conformités. Source des données : Il s'agit souvent d'un champ dérivé ou calculé, déterminé en comparant le Exemples truefaux | |||
| ID de demande de changement associée RelatedChangeRequestId | L'identifiant de la demande de changement initiée pour mettre en œuvre le correctif permanent du problème. | ||
| Descriptionn Cet L'analyse de ce lien est indispensablele pour comprendre le « Délai de transfert de la gestion des changements ». Le Pourquoi est-ce important ? : Lie le problème à sa solution dans la gestion des changements, permettant l'analyse des retards de transfert et du cycle de vie de résolution complet. Source des données : C'est généralement un champ de référence sur l'enregistrement du problème qui renvoie à l'enregistrement correspondant dans le système ou le module de gestion des changements. Exemples CHG0030219CR-8812CHANGE-401 | |||
| Solution de contournement fournie WorkaroundProvided | Un indicateur signalant si une solution de contournement temporaire a été identifiée et communiquée pour le problème. | ||
| Descriptionn Cet C'est un Pourquoi est-ce important ? : Indique si le service a été temporairement restauré, permettant d'analyser la rapidité avec laquelle l'équipe peut atténuer l'impact commercial. Source des données : Il peut s'agir d'un indicateur booléen ('WorkaroundPublished') ou être dérivé de la présence de texte dans un champ de détails de solution de contournement. Exemples truefaux | |||
| Statut du Problème ProblemStatus | L'état actuel du cycle de vie de l'enregistrement du problème, tel que Ouvert, En Investigation ou Fermé. | ||
| Descriptionn Le statut du problème indique l'étape actuelle du problème dans son workflow. Il fournit un aperçu de l'endroit où se trouve le problème à un moment donné, de l'enregistrement initial à la résolution finale. Bien que le Nom de l'Activité capture l'événement de changement de statut, le Statut du Problème lui-même est utile pour analyser le backlog actuel. Il permet de créer des dashboards qui montrent le nombre de problèmes ouverts dans chaque état, aidant à gérer les charges de travail et à identifier les enregistrements qui sont bloqués dans une phase particulière pendant trop longtemps. Pourquoi est-ce important ? : Indique l'étape actuelle d'un problème, ce qui est indispensable pour l'analyse du backlog et l'identification des problèmes bloqués dans une phase spécifique. Source des données : C'est un champ standard sur la table principale des enregistrements de problèmes qui est mis à jour au fur et à mesure que le problème évolue dans son cycle de vie. Exemples OuvertAnalyse des causes profondesEn Attente de ChangementRésoluClôturé | |||
| Utilisateur assigné AssignedUser | L'utilisateur ou le coordinateur individuel actuellement affecté à la gestion de l'enregistrement du problème. | ||
| Descriptionn Cet L'analyse par utilisateur assigné peut aider à comprendre les charges de travail individuelles, la performance et les besoins en formation. Elle peut mettre en évidence si certaines personnes deviennent des Pourquoi est-ce important ? : Permet l'analyse de la charge de travail et de la performance individuelle, aidant à identifier les collaborateurs les plus performants ou les individus pouvant nécessiter un soutien ou une formation supplémentaire. Source des données : Ce champ se trouve généralement dans la table principale des enregistrements de problème, souvent étiqueté comme « Assignee », « Assigned To » ou « Coordinator ». Exemples Alice JohnsonajohnsonBob Smithbsmith | |||
Activités de gestion des problèmes
| Activité | Descriptionn | ||
|---|---|---|---|
| Cause profonde identifiée | Cette activité marque l'étape où la cause sous-jacente du problème a été diagnostiquée et documentée avec succès. Elle représente l'achèvement de la phase d'enquête. | ||
| Pourquoi est-ce important ? : C'est un jalon essentiel pour mesurer l'efficacité du diagnostic. La durée entre le début de l'enquête et l'identification de la cause première est un indicateur clé de performance pour l'analyse des problèmes. Source des données : Ceci est souvent déduit d'un changement de statut vers « Cause Première Identifiée » ou capturé lorsqu'un champ « Cause Première » est renseigné pour la première fois. Capture Capturez l'horodatage d'un changement de statut ou la première mise à jour d'un champ texte de 'Cause Racine'. Type d'événement inferred | |||
| Correctif Permanent Implémenté | Cet `event` indique que la solution technique permanente, souvent gérée via une demande de changement, a été déployée avec succès. Il marque l'achèvement des travaux de remédiation. | ||
| Pourquoi est-ce important ? : Cette activité conclut la phase de mise en œuvre de la solution. Le temps écoulé entre l'initiation du changement et ce point mesure l'efficacité du processus de gestion des changements dans la résolution des problèmes. Source des données : Ceci est généralement déduit du statut de l'enregistrement du problème passant à « Résolu » ou « Solution Implémentée », souvent déclenché par la clôture de la demande de changement liée. Capture Déduisez d'un changement de statut de problème à 'Résolu', ou du horodatage de complétion de l'enregistrement de changement associé. Type d'événement inferred | |||
| Demande de changement initiée | Cet `event` capture la création ou le lien d'une demande de changement formelle à l'enregistrement du problème. Il signifie le transfert du `process` de gestion des problèmes au `process` de gestion des changements pour la mise en œuvre d'une correction permanente. | ||
| Pourquoi est-ce important ? : Cette activité est indispensablele pour analyser le délai entre le diagnostic d'un problème et le début de sa résolution. Elle aide à identifier les Source des données : C'est généralement un Capture Identifiez l'événement où un enregistrement de changement est lié à l'enregistrement de problème. Type d'événement explicit | |||
| Enquête initiée | Cet `event` marque la transition de l'enregistrement du problème d'un état nouveau ou en attente à un état d'enquête active. Il indique qu'un analyste a formellement commencé à travailler sur le diagnostic du problème. | ||
| Pourquoi est-ce important ? : Cette activité aide à mesurer le temps de réponse initial et la vitesse de traitement du backlog. La durée entre la création et le début de l'enquête est un indicateur clé de la réactivité de l'équipe. Source des données : Ceci est souvent déduit d'un changement de statut dans l'historique de l'enregistrement, tel que le passage de « Nouveau » à « En cours » ou « Enquête en cours ». Capture Capturez l'horodatage lorsque le statut passe pour la première fois à un état d'investigation active. Type d'événement inferred | |||
| Enregistrement de problème clôturé | C'est l'activité finale du cycle de vie, signifiant que l'enregistrement du problème est clôturé administrativement et qu'aucune autre action n'est attendue. Le `case` est considéré comme complet et archivé. | ||
| Pourquoi est-ce important ? : Cette activité représente le point de terminaison principal pour la plupart des instances de Source des données : C'est presque toujours un Capture Utilisez le Type d'événement explicit | |||
| Enregistrement de Problème Créé | C'est la création initiale d'un enregistrement de problème. Elle marque le début formel du `process` de gestion des problèmes et établit le `horodatage` de référence pour toutes les analyses subséquentes. | ||
| Pourquoi est-ce important ? : Cette activité est le point de départ principal pour chaque instance de Source des données : Ceci est généralement capturé à partir du Capture Utilisez le Type d'événement explicit | |||
| Solution de contournement fournie | Cet `event` signifie qu'une solution temporaire ou de contournement a été documentée et mise à disposition. Cette action aide à atténuer l'impact sur les utilisateurs finaux pendant qu'une correction permanente est développée. | ||
| Pourquoi est-ce important ? : Le temps nécessaire pour fournir une solution de contournement est un KPI clé pour mesurer la capacité de l'équipe à restaurer rapidement le service. Cette activité aide à analyser la vitesse et l'efficacité des solutions temporaires. Source des données : Cela peut être capturé par le premier Capture Détectez la première population d'un champ de solution de contournement ou un événement de publication associé. Type d'événement explicit | |||
| En Attente de Mise en Œuvre du Changement | Cette activité représente un état où l'enregistrement du problème est en attente, dans l'attente de l'achèvement d'une demande de changement associée. L'équipe en charge du problème attend que l'équipe de changement déploie la correction. | ||
| Pourquoi est-ce important ? : Isoler cette période d'attente aide à mesurer précisément le temps passé dans le processus de gestion des changements par rapport au processus de gestion des problèmes, améliorant ainsi la responsabilisation. Source des données : Ceci est généralement déduit d'un changement de statut vers un état « Changement en attente » ou « Correction en cours » dans l'historique de l'enregistrement du problème. Capture Capturez l'horodatage lorsque le statut de l'enregistrement du problème change pour indiquer qu'il est en attente d'une modification. Type d'événement inferred | |||
| Enregistrement de problème annulé | Cette activité représente la clôture d'un enregistrement de problème avant qu'une résolution ne soit atteinte. Cela peut se produire si l'enregistrement a été créé par erreur, est un doublon ou n'est plus pertinent. | ||
| Pourquoi est-ce important ? : L'analyse des annulations aide à comprendre la qualité des enregistrements de problèmes entrants. Un taux d'annulation élevé peut suggérer un besoin d'amélioration de la formation ou des critères de qualification. Source des données : Ceci est capturé à partir d'un changement de statut vers « Annulé », « Rejeté » ou « Retiré » dans l'historique de l'enregistrement. Capture Identifiez l'horodatage lorsque le statut passe à un état d'annulation terminale. Type d'événement explicit | |||
| Enregistrement de Problème Rouvert | Cette activité se produit lorsqu'un enregistrement de problème précédemment résolu ou fermé est ramené à un état actif. Cela indique généralement que la correction mise en œuvre a échoué ou que le problème a réapparu. | ||
| Pourquoi est-ce important ? : Un taux de réouverture élevé est un indicateur clé d'une mauvaise qualité de résolution. Le suivi de cette activité est indispensable pour mesurer les taux de résolution au premier contact et identifier les solutions inefficaces. Source des données : Cet Capture Identifiez les changements de statut de 'Résolu' ou 'Fermé' vers un état actif comme 'Ouvert'. Type d'événement explicit | |||
| Groupe de support assigné | Cette activité représente l'affectation ou la réaffectation de l'enregistrement du problème à un groupe ou une équipe de support spécifique. Elle saisit le transfert de propriété et de responsabilité pour l'enquête. | ||
| Pourquoi est-ce important ? : Le suivi des affectations est indispensable pour analyser les délais de transfert, identifier les Source des données : Ces informationsns se trouvent généralement dans un journal d' Capture Identifiez tous les changements apportés au champ du groupe d'affectation dans le journal d'historique de l'enregistrement. Type d'événement explicit | |||
| Priorité modifiée | Cette activité capture toute mise à jour de la priorité, de l'impact ou de l'urgence de l'enregistrement du problème après sa création initiale. Elle reflète une réévaluation de l'importance commerciale du problème. | ||
| Pourquoi est-ce important ? : L'analyse des changements de priorité permet d'identifier les problèmes fréquemment escaladés ou dé-escaladés, ce qui peut impacter l'allocation des ressources et la conformité aux SLA. Source des données : Ceci est généralement enregistré dans un journal d' Capture Suivez toutes les mises à jour du champ « Priorité » dans l'historique des changements de l'enregistrement. Type d'événement explicit | |||
| Résolution vérifiée | Cette activité représente la confirmation que la correction mise en œuvre a résolu efficacement le problème sous-jacent et que le service normal a été restauré. C'est l'étape de validation finale avant la clôture. | ||
| Pourquoi est-ce important ? : Cette étape fournit un contrôle qualité de la résolution. L'analyse du temps nécessaire à la vérification peut mettre en évidence les retards dans la confirmation du succès d'une correction. Source des données : Il peut s'agir d'un statut explicite comme « Vérification » ou être déduit de la transition vers un état « Résolu » ou « Résolu ». Capture Capturez l'horodatage lorsque le statut passe à un état indiquant que le correctif a été confirmé. Type d'événement inferred | |||
| Revue post-implémentation effectuée | Cet `event` marque l'achèvement d'une revue post-implémentation (PIR). Ce `process` de revue formel analyse la gestion du problème pour identifier les leçons apprises et les améliorations de `process`. | ||
| Pourquoi est-ce important ? : Le suivi de l'achèvement des PIR est important pour la Source des données : Ceci est souvent capturé par l'achèvement d'une sous-tâche PIR, un changement de statut vers « Revue Complète », ou le renseignement d'un champ de date d'achèvement PIR. Capture Identifiez l'achèvement d'une tâche liée au PIR ou une mise à jour de statut spécifique. Type d'événement explicit | |||
| Violation de SLA détectée | Cet `event` signifie que le temps nécessaire pour atteindre un jalon de résolution ou de réponse a dépassé la cible de l'accord de niveau de service (SLA) prédéfini. C'est un `event` généré ou calculé par le système. | ||
| Pourquoi est-ce important ? : Le suivi des violations de SLA est indispensable pour la gestion de la performance et les rapports de Source des données : Il peut s'agir d'un indicateur spécifique ou d'un Capture Calculez en comparant les horodatages de résolution ou de réponse aux horodatages cibles des SLA, ou capturez un événement de non-conformité généré par le système. Type d'événement calculated | |||
Guides d'extraction
Les méthodes d'extraction varient selon le système. Pour des instructions détaillées,