Votre modèle de données de gestion des problèmes
Votre modèle de données de gestion des problèmes
- Attributs recommandés pour l’analyse des causes racines
- Principales étapes et activités du processus
- Instructions détaillées pour l’extraction depuis ServiceNow
Attributs de la gestion des problèmes
| Nom | Description | ||
|---|---|---|---|
|
Activité
Activity
|
Événement ou action précis réalisé sur l’enregistrement de problème. | ||
|
Description
Représente les différentes étapes ou évolutions de statut qui surviennent au cours du cycle de vie d’un enregistrement de problème. Exemples : « Problem Record Created », « Root Cause Identified » ou « Assigned to Support Group ». Cet attribut est essentiel pour construire la carte du processus et visualiser la séquence des événements.
Pourquoi c’est important
Il définit les nœuds de la carte des processus et permet de visualiser le flux de travail ainsi que les variantes du processus.
Où les obtenir
Dérivé des tables « sys_audit » et « sys_history_line », ou des changements d’état dans la table « problem »
Exemples
Enregistrement de problème crééAnalyse terminéeÉtat modifié en « Fermé »
|
|||
|
Enregistrement de problème
ProblemNumber
|
Identifiant unique de l’enregistrement de problème. | ||
|
Description
Clé alphanumérique unique attribuée à un enregistrement de problème précis dans ServiceNow, par exemple PRB000123. Cet identifiant constitue le fil conducteur central reliant toutes les activités du processus, de la consignation initiale à l’analyse de la cause racine, puis à la clôture finale. Dans une analyse de Process Mining, cet attribut sert de Case ID et permet de reconstituer le parcours de bout en bout de la résolution du problème.
Pourquoi c’est important
Il s’agit de la clé primaire qui permet de distinguer les cas uniques et de regrouper les événements associés dans le graphe du processus.
Où les obtenir
Table ServiceNow « problem », champ « number »
Exemples
PRB004512PRB009823PRB001122
|
|||
|
Horodatage de l’événement
EventTime
|
La date et l’heure exactes auxquelles une activité s’est produite. | ||
|
Description
Enregistre l’horodatage précis auquel une modification ou une action a été consignée dans le système. Ces données sont fondamentales pour classer les activités par ordre chronologique et calculer des indicateurs de durée, tels que les temps de cycle et les délais entre les étapes du processus.
Pourquoi c’est important
Essentiel pour ordonner les événements et calculer tous les KPI fondés sur le temps.
Où les obtenir
Champ « sys_created_on » de ServiceNow dans les tables d’audit et d’historique
Exemples
2023-10-12T08:30:00Z2023-10-12T14:45:12Z
|
|||
|
Dernière mise à jour des données
LastDataUpdate
|
L’horodatage auquel les données ont été extraites ou actualisées pour la dernière fois. | ||
|
Description
Indique l’actualité du jeu de données utilisé pour l’analyse. Il permet aux analystes de savoir s’ils examinent des données en temps réel ou un instantané historique, ce qui est essentiel pour interpréter correctement le statut des dossiers ouverts.
Pourquoi c’est important
Permet aux utilisateurs de connaître la fraîcheur des données afin d’établir des rapports opérationnels fiables.
Où les obtenir
Heure système au moment de l’exécution de l’ETL
Exemples
2023-11-01T12:00:00Z
|
|||
|
Système source
SourceSystem
|
Le nom du système à l’origine des données. | ||
|
Description
Identifie l’instance ou l’environnement ServiceNow précis à partir duquel les données de Gestion des problèmes ont été extraites. Cet attribut est particulièrement utile dans les environnements multisystèmes pour assurer la traçabilité des données et tenir compte des spécificités de chaque système lors de l’analyse.
Pourquoi c’est important
Fournit le contexte sur l’origine des données, notamment lors de la fusion de données provenant de plusieurs outils ITSM.
Où les obtenir
Défini en dur lors de l’extraction, par exemple « ServiceNow Production »
Exemples
ServiceNow ProductionServiceNow EMEA
|
|||
|
Catégorie de cause racine
RootCauseCategory
|
La classification de la cause racine identifiée. | ||
|
Description
Classe la raison sous-jacente du problème, par exemple Software Bug, Human Error ou Hardware Failure. Cet attribut alimente le Dashboard « Root Cause Categorization Accuracy » et aide à identifier les schémas de défaillance systémiques.
Pourquoi c’est important
Permet d’analyser les schémas de défaillance afin de définir des améliorations stratégiques.
Où les obtenir
Table « problem » de ServiceNow, champ « rca_category » ou « u_root_cause_category »
Exemples
Défaut logicielErreur de configurationProblème fournisseur
|
|||
|
État du problème
ProblemState
|
Le statut du cycle de vie de l’enregistrement du problème. | ||
|
Description
Reflète l’étape actuelle de l’enregistrement du problème, par exemple Open, Root Cause Analysis, Fix in Progress ou Closed. Il constitue un critère principal pour filtrer et comprendre la composition du backlog dans le Dashboard « Aged Problem Record Aging Analysis ».
Pourquoi c’est important
Indicateur de statut principal utilisé pour filtrer les dossiers ouverts et fermés.
Où les obtenir
Table « problem » de ServiceNow, champ « state »
Exemples
NouveauÉvaluerAnalyse des causes racinesRésolu
|
|||
|
Groupe de support
AssignmentGroup
|
L’équipe technique responsable de la résolution du problème. | ||
|
Description
Désigne le groupe de support ou l’équipe actuellement affecté au problème. Cet attribut est essentiel au Dashboard « Support Group Reassignment Analysis », qui permet de suivre les transferts entre équipes et d’identifier les silos organisationnels.
Pourquoi c’est important
Essentiel pour identifier les goulots d’étranglement entre les services et analyser l’efficacité des transferts.
Où les obtenir
Table « problem » de ServiceNow, champ « assignment_group »
Exemples
Opérations réseauAdministrateurs de bases de donnéesCentre de services
|
|||
|
Nombre d’incidents associés
RelatedIncidentCount
|
Le nombre d’incidents liés à cet enregistrement de problème. | ||
|
Description
Quantifie l’impact du problème en comptant le nombre d’incidents qui lui sont associés. Les valeurs élevées dans ce champ, notamment pour les erreurs connues, alimentent le Dashboard « Known Error and Incident Recurrence ».
Pourquoi c’est important
Mesure l’ampleur de l’impact du problème sur les utilisateurs.
Où les obtenir
Table « problem » de ServiceNow, champ « related_incidents » (le nom du champ peut varier) ou nombre d’enregistrements associés
Exemples
1501200
|
|||
|
Nombre de réaffectations
ReassignmentCount
|
Le nombre de fois où le problème a été réaffecté entre différents groupes. | ||
|
Description
Compteur indiquant la fréquence à laquelle le groupe d’affectation a changé. Il constitue la source directe du KPI « Problem Record Reassignment Count » et aide à repérer les effets de « ping-pong », lorsque les tickets passent d’une équipe à l’autre.
Pourquoi c’est important
Indicateur direct des frictions du processus et de l’absence de responsabilité clairement définie.
Où les obtenir
Table « problem » de ServiceNow, champ « reassignment_count »
Exemples
0312
|
|||
|
Priorité
Priority
|
Le niveau de priorité attribué à l’enregistrement du problème. | ||
|
Description
Indique l’importance et l’urgence du problème, généralement calculées à partir de l’impact et de l’urgence. Cet attribut permet de segmenter l’analyse selon le niveau de criticité et alimente le Dashboard « SLA Breach and Priority Monitoring ».
Pourquoi c’est important
Permet de segmenter la performance du processus selon la criticité métier.
Où les obtenir
Table « problem » de ServiceNow, champ « priority »
Exemples
1 - Critique2 - Élevée3 - Modéré
|
|||
|
Utilisateur affecté
AssignedTo
|
La personne précisément chargée de traiter le problème. | ||
|
Description
Identifie l’utilisateur actuellement responsable de l’enregistrement du problème. L’analyse de cet attribut aide à comprendre la répartition de la charge de travail, la performance individuelle et les éventuels goulots d’étranglement au niveau des ressources.
Pourquoi c’est important
Essentiel pour analyser l’efficacité des ressources et la charge de travail individuelle.
Où les obtenir
Table « problem » de ServiceNow, champ « assigned_to »
Exemples
Alice SmithBob JonesAdministrateur système
|
|||
|
Date d’échéance de l’SLA
SlaDueDate
|
La date et l’heure cibles de résolution du problème conformément à l’SLA. | ||
|
Description
L’horodatage indiquant la date limite à laquelle le problème doit être résolu pour respecter les accords de niveau de service. Il sert de référence au Dashboard « SLA Breach and Priority Monitoring » et au calcul des taux de conformité.
Pourquoi c’est important
Référence pour calculer le statut de non-respect de l’SLA.
Où les obtenir
Table « task_sla » de ServiceNow associée au problème
Exemples
2023-12-31T17:00:00Z
|
|||
|
Durée d’attente
PendingDuration
|
Temps total passé par le problème dans un état suspendu ou en attente. | ||
|
Description
Cumul du temps passé dans des statuts tels que « Pending Vendor » ou « On Hold ». Cet indicateur est utilisé pour l’analyse « Pending State and Wait Time Analysis », afin de distinguer le temps de traitement interne des délais externes.
Pourquoi c’est important
Distingue les inefficacités de l’équipe des dépendances externes.
Où les obtenir
Calculé comme suit : somme de la durée des intervalles pour lesquels State = Pending/On Hold
Exemples
5 jours0 minute
|
|||
|
Élément de configuration
ConfigurationItem
|
L’actif ou le service précis affecté par le problème. | ||
|
Description
Identifie l’élément de configuration (CI) associé à l’enregistrement du problème. Son analyse permet de mettre en relation les problèmes avec des composants matériels, logiciels ou des services précis, et contribue au Dashboard « Root Cause Categorization Accuracy ».
Pourquoi c’est important
Relie les problèmes du processus à des actifs physiques ou logiques précis.
Où les obtenir
Table « problem » de ServiceNow, champ « cmdb_ci »
Exemples
Serveur SAP ERP 01Service de messagerie ExchangeBase de données Oracle de production
|
|||
|
Est une erreur connue
IsKnownError
|
Indicateur précisant si le problème est classé comme une erreur connue. | ||
|
Description
Indique si l’enregistrement du problème a été converti en erreur connue ou identifié comme tel. Cet attribut est essentiel à l’analyse « Known Error and Incident Recurrence », qui permet d’évaluer l’efficacité du processus de gestion des connaissances.
Pourquoi c’est important
Distingue les investigations en cours des défauts acceptés faisant l’objet de solutions de contournement.
Où les obtenir
Table « problem » de ServiceNow, champ « known_error »
Exemples
truefalse
|
|||
|
Numéro de demande de changement
ChangeRequestNumber
|
L’identifiant de la demande de changement créée pour corriger le problème. | ||
|
Description
Relie l’enregistrement du problème à un enregistrement de Gestion du changement (RFC). Cette relation est essentielle au Dashboard « Change Request Transition Efficiency », qui mesure la rapidité du transfert entre le diagnostic du problème et l’exécution de la modification de l’infrastructure.
Pourquoi c’est important
Suit la transition de la Gestion des problèmes vers la Gestion du changement.
Où les obtenir
Table « problem » de ServiceNow, champ « rfc »
Exemples
CHG003001CHG004552
|
|||
|
Résultat de la PIR
PostImplementationReviewResult
|
Le résultat ou le statut d’achèvement de la Post-Implementation Review. | ||
|
Description
Enregistre le résultat ou le statut de la PIR, par exemple Completed, Not Required ou Pending. Cet attribut est nécessaire au Dashboard « Post-Implementation Review Compliance » afin de vérifier que les problèmes majeurs font bien l’objet d’une revue.
Pourquoi c’est important
Indicateur de contrôle qualité qui garantit que les enseignements sont tirés des incidents majeurs.
Où les obtenir
Table « problem » de ServiceNow, champ « pir_state » ou champ personnalisé similaire
Exemples
TerminéDérogation accordéeEn attente
|
|||
|
Service métier
BusinessService
|
Le service métier de haut niveau affecté par le problème. | ||
|
Description
Représente le service destiné aux utilisateurs métier, par exemple « Payroll Service » ou « Customer Portal », plutôt que le composant technique. Il fournit une vue centrée sur l’activité pour les rapports destinés aux parties prenantes.
Pourquoi c’est important
Relie les problèmes techniques aux chaînes de valeur métier.
Où les obtenir
Table « problem » de ServiceNow, champ « business_service »
Exemples
Services bancaires en ligneMessagerie interne
|
|||
|
Solution de contournement publiée
WorkaroundPublished
|
Indique si une solution de contournement a été documentée et partagée. | ||
|
Description
Indicateur booléen ou de statut précisant si une correction temporaire a été identifiée et publiée dans la base de connaissances ou la base des erreurs connues. Il alimente le Dashboard « Workaround Publication Performance ».
Pourquoi c’est important
Essentiel pour mesurer la rapidité avec laquelle l’impact métier est réduit avant la mise en place d’une correction définitive.
Où les obtenir
Table « problem » de ServiceNow, champ « work_around » (présence de texte) ou statut spécifique
Exemples
truefalse
|
|||
|
Temps de conception de la solution
SolutionDraftingTime
|
Temps écoulé entre l’identification de la cause racine et la proposition d’une solution. | ||
|
Description
Suit la durée de la phase de conception au cours de laquelle une correction est élaborée après identification de la cause. Cet indicateur alimente le Dashboard « Solution Drafting and Fix Application ».
Pourquoi c’est important
Isole la performance de la phase de conception de la correction.
Où les obtenir
Calculé comme suit : horodatage de « Proposed Solution Drafted » moins « Root Cause Identified »
Exemples
2 jours4 heures
|
|||
Activités de gestion des problèmes
| Activité | Description | ||
|---|---|---|---|
|
Affecté à un groupe de support
|
Orientation de l’enregistrement de problème vers une équipe technique précise pour investigation. Cette activité suit le transfert de responsabilité et est essentielle à l’analyse des passages de relais. | ||
|
Pourquoi c’est important
Essentiel pour le Dashboard d’analyse des réaffectations de groupes d’assistance, afin d’identifier les effets de ping-pong et les goulots d’étranglement entre les équipes.
Où les obtenir
Table ServiceNow « sys_audit » ou « sys_history_line » qui suit les modifications du champ « assignment_group ».
Collecte
Comparer le champ d’état avant et après
Type d’événement
inferred
|
|||
|
Cause racine identifiée
|
Moment où les codes « Root Cause » sont renseignés ou où l’état passe à « Fix in Progress ». Il représente le diagnostic réussi du problème. | ||
|
Pourquoi c’est important
Permet de calculer le délai moyen d’identification de la cause racine et alimente le Dashboard Root Cause Investigation Cycle Time. Il s’agit d’une étape majeure du processus.
Où les obtenir
Table ServiceNow « sys_audit » qui suit les modifications du champ de catégorie « root_cause » ou le passage à l’état « Fix in Progress ».
Collecte
Comparer le champ d’état avant et après
Type d’événement
inferred
|
|||
|
Correction définitive appliquée
|
Moment où le problème est marqué comme résolu, souvent après la clôture de la Change Request associée. Il indique que le travail technique est terminé. | ||
|
Pourquoi c’est important
Détermine la fin du cycle de correction active. Sert à calculer le délai total de résolution par rapport au SLA.
Où les obtenir
Table ServiceNow « sys_audit », transition du champ « state » vers « Resolved », généralement la valeur 106.
Collecte
Comparer le champ d’état avant et après
Type d’événement
inferred
|
|||
|
Demande de changement lancée
|
Association d’une Change Request (RFC) à l’enregistrement de problème. Elle indique le transfert de la Gestion des problèmes vers la Gestion du changement pour la mise en œuvre. | ||
|
Pourquoi c’est important
Indispensable au Dashboard Change Request Transition Efficiency. Il identifie les retards entre la découverte d’une correction et le lancement du processus de changement.
Où les obtenir
Table ServiceNow « sys_audit » qui suit le renseignement du champ de référence « rfc » dans la table « problem ».
Collecte
Consigné lors de l’exécution de la transaction Create Normal Change
Type d’événement
explicit
|
|||
|
Enregistrement de problème clôturé
|
Dernier événement du cycle de vie, au cours duquel l’enregistrement devient inactif. Aucun travail supplémentaire n’est attendu. | ||
|
Pourquoi c’est important
Point final définitif de l’instance du processus. Nécessaire au calcul de la durée totale du cycle.
Où les obtenir
Table ServiceNow « problem », champ « closed_at » ou transition du champ « state » vers « Closed ».
Collecte
Consigné lors de l’exécution de la transaction Close Problem
Type d’événement
explicit
|
|||
|
Enregistrement de problème créé
|
Création initiale d’un enregistrement de problème dans le système ServiceNow. Elle marque le début du cycle de vie de la Gestion des problèmes et définit l’horodatage de référence pour les indicateurs d’ancienneté. | ||
|
Pourquoi c’est important
Définit l’heure de début de tous les calculs de durée de cycle et des mesures de SLA. Il s’agit du principal point de référence pour identifier le volume des nouvelles investigations de problèmes.
Où les obtenir
Table ServiceNow « problem », champ « sys_created_on ».
Collecte
Consigné lors de l’exécution de la transaction New Record
Type d’événement
explicit
|
|||
|
Investigation commencée
|
Transition de l’état de l’enregistrement de problème de « New » vers « Assess » ou « Root Cause Analysis ». Elle indique qu’un analyste a commencé à travailler activement sur le problème. | ||
|
Pourquoi c’est important
Marque la fin du temps d’attente initial dans la file et le début de la phase d’investigation active, ce qui permet l’analyse des états en attente.
Où les obtenir
Table ServiceNow « sys_audit » qui suit les modifications du champ « state », par exemple le passage à la valeur 102 ou 103 selon la configuration.
Collecte
Comparer le champ d’état avant et après
Type d’événement
inferred
|
|||
|
Solution de contournement identifiée
|
Saisie de texte dans le champ « Workaround » de l’enregistrement de problème. Elle indique le moment où une solution temporaire est documentée par l’analyste. | ||
|
Pourquoi c’est important
Alimente le Dashboard Workaround Publication Performance en indiquant à quel moment la solution technique a été connue pour la première fois.
Où les obtenir
Table ServiceNow « sys_audit » dans laquelle « fieldname » correspond à « workaround ».
Collecte
Comparer le champ d’état avant et après
Type d’événement
inferred
|
|||
|
État passé à Fix in Progress
|
L’enregistrement passe à un état indiquant qu’une correction est en cours de développement ou de déploiement, souvent dans l’attente de la Gestion du changement. | ||
|
Pourquoi c’est important
Distingue le temps consacré à l’investigation du temps d’attente d’un changement, ce qui affine l’analyse des goulots d’étranglement.
Où les obtenir
Table ServiceNow « sys_audit », transition du champ « state » vers « Fix in Progress », généralement la valeur 104.
Collecte
Comparer le champ d’état avant et après
Type d’événement
inferred
|
|||
|
Évaluation rejetée
|
L’enregistrement de problème revient à un état antérieur ou est annulé pendant la phase d’évaluation, car il ne correspondait pas à un problème valide. | ||
|
Pourquoi c’est important
Identifie les activités sans valeur ajoutée du processus, lorsque des incidents sont classés à tort comme des problèmes.
Où les obtenir
Table ServiceNow « sys_audit », transition du champ « state » vers « Closed/Cancelled » ou « New » depuis « Assess ».
Collecte
Comparer le champ d’état avant et après
Type d’événement
inferred
|
|||
|
Résolution vérifiée
|
Étape de validation au cours de laquelle l’efficacité de la résolution est confirmée. Selon le niveau de maturité du processus, elle peut correspondre à un état précis ou à une case à cocher. | ||
|
Pourquoi c’est important
Garantit le contrôle qualité avant la clôture. Le contournement de cette étape permet d’analyser les écarts au processus.
Où les obtenir
Table ServiceNow « sys_audit ». Il peut s’agir d’un changement d’état, de « Resolved » à « Closed », ou d’un champ spécifique « u_resolution_verified » s’il est configuré.
Collecte
Comparer le champ d’état avant et après
Type d’événement
inferred
|
|||
|
Revue post-implémentation terminée
|
Achèvement de la tâche PIR ou activation d’un indicateur PIR. Cela confirme qu’une analyse rétrospective a été réalisée pour les problèmes importants. | ||
|
Pourquoi c’est important
Alimente directement le Dashboard Post-Implementation Review Compliance. L’absence de cette activité pour les problèmes hautement prioritaires indique un défaut de conformité.
Où les obtenir
Clôture dans la table ServiceNow « problem_task » d’une tâche de type PIR, ou modification du champ « pir_state » dans la table « problem ».
Collecte
Déduire en comparant le champ X au champ Y
Type d’événement
inferred
|
|||
|
Solution de contournement publiée
|
Exécution de l’action « Communicate Workaround », qui transmet la solution de contournement aux incidents associés ou crée un article Known Error. Cette activité se distingue de la simple saisie de la solution de contournement. | ||
|
Pourquoi c’est important
Essentiel pour mesurer la rapidité du partage des connaissances. Les retards à cette étape ont un effet direct sur le volume d’incidents récurrents.
Où les obtenir
Table ServiceNow « sys_journal_field » ou journaux d’actions d’interface spécifiques. L’événement peut également être déduit de la création d’un enregistrement « kb_knowledge » de type « Known Error ».
Collecte
Consigné lors de l’exécution de la transaction Communicate Workaround
Type d’événement
explicit
|
|||
|
Solution proposée rédigée
|
Saisie de données dans les champs « Fix Notes » ou « Resolution Code ». Elle indique que l’analyste est passé de la compréhension de la cause à la conception de la correction définitive. | ||
|
Pourquoi c’est important
Alimente le Dashboard Solution Drafting and Fix Application en isolant la durée de la phase de conception.
Où les obtenir
Table ServiceNow « sys_audit » qui suit les mises à jour du champ « fix_notes ».
Collecte
Comparer le champ d’état avant et après
Type d’événement
inferred
|
|||
Guides d’extraction
Prêt à commencer ?
Téléchargez le modèle complet et commencez dès aujourd’hui à transformer vos données de gestion des problèmes en analyses concrètes. Notre équipe vous accompagne à chaque étape de votre parcours de Process Mining.
Optimisez dès maintenant la Gestion des problèmes pour accélérer les résolutions
Réduisez de 30 % la durée de vos cycles d’investigation grâce au Process Mining
Aucune carte bancaire requise. Configuration en quelques minutes.