Votre modèle de données de gestion des problèmes

Gestion des problèmes dans ServiceNow
Votre modèle de données de gestion des problèmes

Votre modèle de données de gestion des problèmes

Ce modèle fournit un cadre complet pour analyser le cycle de vie de la gestion des problèmes ITIL dans ServiceNow. Vous y trouverez les attributs à collecter, les activités essentielles à suivre et des instructions d’extraction détaillées, étape par étape, pour votre projet de données. Cette structure vous donne la visibilité nécessaire pour réduire le délai moyen de résolution et éliminer les incidents récurrents.
  • 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
Vous découvrez les journaux d’événements ? En savoir plus sur la création d’un journal d’événements pour le Process Mining.

Attributs de la gestion des problèmes

Voici les champs de données recommandés à inclure dans votre journal d’événements pour analyser de manière complète votre processus ITIL de gestion des problèmes.
5 Obligatoire 7 Recommandé 9 Facultatif
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
Obligatoire Recommandé Facultatif

Activités de gestion des problèmes

Voici les principales étapes du processus et les jalons du cycle de vie à enregistrer dans votre journal d’événements pour découvrir précisément vos flux de travail de gestion des problèmes.
8 Recommandé 6 Facultatif
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
Recommandé Facultatif

Guides d’extraction

Comment extraire vos données de la Gestion des problèmes dans ServiceNow

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

Démarrer l’essai gratuit

Aucune carte bancaire requise. Configuration en quelques minutes.