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

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

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

Ce modèle fournit un plan détaillé pour analyser le cycle de vie de la gestion des problèmes ITIL dans ServiceNow. Vous y trouverez les attributs à recueillir, les activités importantes à suivre et les instructions d’extraction des données, étape par étape. Cette structure vous donne la visibilité nécessaire pour réduire le délai moyen de résolution et éviter que les incidents ne se reproduisent.
  • Attributs recommandés pour l’analyse des causes racines
  • Étapes clés et activités du processus
  • Guide d’extraction des données de ServiceNow, étape par étape
Vous découvrez les journaux d’événements ? Découvrez comment créer un journal d’événements pour le Process Mining.

Attributs de gestion des problèmes

Voici les champs recommandés à inclure dans votre journal d’événements pour analyser en détail votre processus de gestion des problèmes ITIL.
5 Obligatoire 7 Recommandé 9 Facultatif
Nom Description
Activité
Activity
Événement ou action précis effectué sur l’enregistrement du problème.
Description

Représente les différentes étapes ou les changements d’état qui surviennent au cours du cycle de vie d’un enregistrement de problème. Exemples : « Enregistrement du problème créé », « Cause profonde identifiée » ou « Affecté au groupe d’assistance ». Cet attribut sert à construire la cartographie du processus et à visualiser la séquence des événements.

Pourquoi est-ce important ?

Il définit les nœuds de la cartographie du processus et permet de visualiser le flux de travail ainsi que les variantes du processus.

Où trouver ces données

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 passé à Clôturé
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 dans ServiceNow (par exemple, PRB000123). Cet identifiant relie toutes les activités du processus, de la création initiale à la clôture, en passant par l’analyse des causes profondes. Dans une analyse de Process Mining, il sert d’ID de cas et permet de reconstituer le parcours complet de résolution du problème.

Pourquoi est-ce important ?

Il s’agit de la clé principale qui permet de distinguer les cas et de regrouper les événements associés dans le graphe du processus.

Où trouver ces données

Table ServiceNow « problem », champ « number »

Exemples
PRB004512PRB009823PRB001122
Horodatage de l’événement
EventTime
Date et heure précises auxquelles une activité a eu lieu.
Description

Enregistre l’horodatage précis auquel une modification ou une action a été consignée dans le système. Cette information est essentielle pour ordonner les activités chronologiquement et calculer des durées, comme les temps de cycle et les délais entre les étapes du processus.

Pourquoi est-ce important ?

Indispensable pour ordonner les événements et calculer tous les KPI liés au temps.

Où trouver ces données

Champ ServiceNow « sys_created_on » 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
Horodatage de l’extraction ou de la dernière actualisation des données.
Description

Indique la fraîcheur du jeu de données utilisé pour l’analyse. Les analystes peuvent ainsi savoir s’ils consultent des données en temps réel ou un instantané historique, ce qui est essentiel pour interpréter correctement l’état des dossiers ouverts.

Pourquoi est-ce important ?

Permet de connaître la fraîcheur des données pour produire des rapports opérationnels fiables.

Où trouver ces données

Heure système au moment de l’exécution de l’ETL

Exemples
2023-11-01T12:00:00Z
Système source
SourceSystem
Nom du système d’où proviennent les données.
Description

Identifie l’instance ou l’environnement ServiceNow précis dont les données de gestion des problèmes ont été extraites. Cet attribut est particulièrement utile dans les environnements comportant plusieurs systèmes : il permet de suivre la provenance des données et de tenir compte des particularités de chaque système dans l’analyse.

Pourquoi est-ce important ?

Précise l’origine des données, notamment lors de la fusion de données provenant de plusieurs outils ITSM.

Où trouver ces données

Renseigné en dur lors de l’extraction (par exemple, « ServiceNow Production »)

Exemples
ServiceNow ProdServiceNow EMEA
Catégorie de la cause profonde
RootCauseCategory
Classification de la cause profonde identifiée.
Description

Classe la cause sous-jacente du problème, par exemple un bogue logiciel, une erreur humaine ou une panne matérielle. Cet attribut alimente le Dashboard « Précision de la catégorisation des causes profondes » et aide à repérer les défaillances systémiques.

Pourquoi est-ce important ?

Permet d’analyser les schémas de défaillance afin de définir des améliorations stratégiques.

Où trouver ces données

Table ServiceNow « problem », champ « rca_category » ou « u_root_cause_category »

Exemples
Défaut logicielErreur de configurationProblème lié au fournisseur
État du problème
ProblemState
État de l’enregistrement du problème au cours de son cycle de vie.
Description

Indique l’étape actuelle de l’enregistrement du problème, par exemple Ouvert, Analyse des causes profondes, Correction en cours ou Clôturé. Cet attribut permet principalement de filtrer et de comprendre la composition du backlog dans le Dashboard « Analyse de l’ancienneté des enregistrements de problèmes ».

Pourquoi est-ce important ?

Indicateur d’état principal pour filtrer les cas ouverts et clôturés.

Où trouver ces données

Table ServiceNow « problem », champ « state »

Exemples
NouveauÉvaluerAnalyse des causes profondesRésolu
Groupe d’assistance
AssignmentGroup
Équipe technique chargée de résoudre le problème.
Description

Désigne le groupe ou l’équipe d’assistance actuellement chargé du problème. Cet attribut est essentiel au Dashboard « Analyse des réaffectations entre groupes d’assistance » : il permet de suivre les transferts entre équipes et de repérer les silos organisationnels.

Pourquoi est-ce important ?

Essentiel pour repérer les goulots d’étranglement entre services et analyser l’efficacité des transferts.

Où trouver ces données

Table ServiceNow « problem », champ « assignment_group »

Exemples
Opérations réseauAdministrateurs de bases de donnéesCentre de services
Nombre d’incidents associés
RelatedIncidentCount
Nombre d’incidents liés à cet enregistrement de problème.
Description

Mesure l’impact du problème en comptant les incidents qui lui sont associés. Les valeurs élevées, en particulier pour les erreurs connues, alimentent le Dashboard « Erreurs connues et récurrence des incidents ».

Pourquoi est-ce important ?

Mesure l’ampleur de l’impact du problème sur les utilisateurs.

Où trouver ces données

Table ServiceNow « problem », champ « related_incidents » (le nom du champ peut varier) ou nombre d’enregistrements associés

Exemples
1501200
Nombre de réaffectations
ReassignmentCount
Nombre de fois où le problème a été réaffecté d’un groupe à un autre.
Description

Compteur du nombre de changements de groupe d’affectation. Il alimente directement le KPI « Nombre de réaffectations d’un enregistrement de problème » et aide à repérer les allers-retours entre équipes.

Pourquoi est-ce important ?

Indicateur direct des frictions dans le processus et du manque de clarté des responsabilités.

Où trouver ces données

Table ServiceNow « problem », champ « reassignment_count »

Exemples
0312
Priorité
Priority
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 son impact et de son urgence. Cet attribut permet de segmenter l’analyse selon le niveau de criticité et alimente le Dashboard « Suivi des violations de SLA et des priorités ».

Pourquoi est-ce important ?

Permet de segmenter les performances du processus selon l’importance du problème pour l’activité.

Où trouver ces données

Table ServiceNow « problem », champ « priority »

Exemples
1 - Critique2 - Élevée3 - Modérée
Utilisateur affecté
AssignedTo
Personne précise chargée de traiter le problème.
Description

Identifie l’utilisateur actuellement responsable de l’enregistrement du problème. L’analyse de cet attribut permet de comprendre la répartition de la charge de travail, les performances individuelles et les éventuels goulots d’étranglement au niveau des ressources.

Pourquoi est-ce important ?

Utile pour analyser l’efficacité des ressources et la charge de travail de chacun.

Où trouver ces données

Table ServiceNow « problem », champ « assigned_to »

Exemples
Alice SmithBob JonesAdministrateur système
Date d’échéance du SLA
SlaDueDate
Date et heure limites de résolution du problème, conformément au SLA.
Description

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 « Suivi des violations de SLA et des priorités » et au calcul des taux de conformité.

Pourquoi est-ce important ?

Référence pour déterminer si un SLA a été dépassé.

Où trouver ces données

Table ServiceNow « task_sla » associée au problème

Exemples
2023-12-31T17:00:00Z
Durée en attente
PendingDuration
Durée totale pendant laquelle le problème est resté suspendu ou en attente.
Description

Cumule le temps passé dans des états tels que « En attente du fournisseur » ou « Suspendu ». Cette métrique alimente l’analyse « État en attente et temps d’attente » et permet de distinguer le temps de traitement interne des retards externes.

Pourquoi est-ce important ?

Permet de distinguer les difficultés de l’équipe des dépendances externes.

Où trouver ces données

Calcul : somme des durées des intervalles où l’état est « En attente » ou « Suspendu »

Exemples
5 jours0 minute
Élément de configuration
ConfigurationItem
Ressource ou 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 relier les problèmes à du matériel, des logiciels ou des services précis et alimente le Dashboard « Précision de la catégorisation des causes profondes ».

Pourquoi est-ce important ?

Relie les problèmes de processus à des ressources physiques ou logiques précises.

Où trouver ces données

Table ServiceNow « problem », champ « cmdb_ci »

Exemples
Serveur SAP ERP 01Service de messagerie ExchangeOracle DB Prod
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 marqué comme tel. Cet attribut est essentiel à l’analyse « Erreurs connues et récurrence des incidents », qui permet d’évaluer l’efficacité du processus de gestion des connaissances.

Pourquoi est-ce important ?

Permet de distinguer les investigations en cours des défauts acceptés pour lesquels une solution de contournement existe.

Où trouver ces données

Table ServiceNow « problem », champ « known_error »

Exemples
truefalse
Numéro de demande de changement
ChangeRequestNumber
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). Ce lien est essentiel au Dashboard « Efficacité de la transition vers une demande de changement », qui mesure la rapidité du transfert entre le diagnostic du problème et la mise en œuvre du changement d’infrastructure.

Pourquoi est-ce important ?

Suit la transition de la gestion des problèmes vers la gestion du changement.

Où trouver ces données

Table ServiceNow « problem », champ « rfc »

Exemples
CHG003001CHG004552
Résultat de la revue après mise en œuvre
PostImplementationReviewResult
Résultat ou état d’avancement de la revue après mise en œuvre.
Description

Enregistre le résultat ou l’état de la revue après mise en œuvre (par exemple, Terminée, Non requise ou En attente). Cet attribut est nécessaire au Dashboard « Conformité des revues après mise en œuvre » pour vérifier que les problèmes majeurs font bien l’objet d’une revue.

Pourquoi est-ce important ?

Indicateur de contrôle qualité qui permet de vérifier que les enseignements des incidents majeurs sont pris en compte.

Où trouver ces données

Table ServiceNow « problem », champ « pir_state » ou champ personnalisé équivalent

Exemples
TerminéeDispenséeEn attente
Service métier
BusinessService
Service métier de haut niveau affecté par le problème.
Description

Désigne le service destiné aux utilisateurs métier (par exemple, « Service de paie » ou « Portail client »), plutôt que le composant technique. Il offre ainsi aux parties prenantes une vue centrée sur l’activité.

Pourquoi est-ce important ?

Relie les problèmes techniques aux chaînes de valeur de l’entreprise.

Où trouver ces données

Table ServiceNow « problem », 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 d’état précisant si une solution temporaire a été trouvée et publiée dans la base de connaissances ou la base des erreurs connues. Il alimente le Dashboard « Performance de publication des solutions de contournement ».

Pourquoi est-ce important ?

Essentiel pour mesurer la rapidité avec laquelle l’impact sur l’activité est atténué avant la mise en place d’une correction définitive.

Où trouver ces données

Table ServiceNow « problem », champ « work_around » (présence d’un texte) ou état spécifique

Exemples
truefalse
Temps de rédaction de la solution
SolutionDraftingTime
Temps écoulé entre l’identification de la cause profonde et la proposition d’une solution.
Description

Mesure la durée de la phase de conception, pendant laquelle une correction est élaborée après l’identification de la cause. Cette métrique alimente le Dashboard « Rédaction de la solution et application de la correction ».

Pourquoi est-ce important ?

Mesure les performances de la phase de conception de la correction.

Où trouver ces données

Calcul : horodatage de « Proposition de solution rédigée » moins celui de « Cause profonde identifiée »

Exemples
2 jours4 heures
Obligatoire Recommandé Facultatif

Activités de gestion des problèmes

Voici les étapes du processus et les jalons du cycle de vie à enregistrer dans votre journal d’événements pour découvrir avec précision vos flux de travail de gestion des problèmes.
8 Recommandé 6 Facultatif
Activité Description
Affecté à un groupe d’assistance
Affectation de l’enregistrement de problème à une équipe technique précise pour investigation. Cette activité suit le transfert des responsabilités et est essentielle à l’analyse des transferts entre équipes.
Pourquoi est-ce important ?

Indispensable au Dashboard d’analyse des réaffectations entre groupes d’assistance, qui permet de repérer les allers-retours et les goulots d’étranglement entre équipes.

Où trouver ces données

Table ServiceNow « sys_audit » ou « sys_history_line », qui suit les changements du champ « assignment_group ».

Données à recueillir

Comparer la valeur du 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 marque la réussite du diagnostic du problème.
Pourquoi est-ce important ?

Permet de calculer le délai moyen d’identification de la cause racine et d’alimenter le Dashboard de suivi du temps de cycle des investigations. Il s’agit d’une étape majeure du processus.

Où trouver ces données

Table ServiceNow « sys_audit », qui suit les changements du champ de catégorie « root_cause » ou le passage à l’état « Fix in Progress ».

Données à recueillir

Comparer la valeur du 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 demande de changement associée. Il indique que les travaux techniques sont terminés.
Pourquoi est-ce important ?

Détermine la fin du cycle de correction active. Sert à calculer le délai total de résolution par rapport au SLA.

Où trouver ces données

Table ServiceNow « sys_audit », champ « state » passé à « Resolved » (valeur généralement égale à 106).

Données à recueillir

Comparer la valeur du champ d’état avant et après

Type d’événement inferred
Début de l’investigation
Passage de l’état de l’enregistrement de problème de « New » à « Assess » ou « Root Cause Analysis ». Il indique qu’un analyste a commencé à traiter activement le problème.
Pourquoi est-ce important ?

Marque la fin de l’attente initiale dans la file et le début de l’investigation active, et permet d’analyser les états d’attente.

Où trouver ces données

Table ServiceNow « sys_audit », qui suit les changements du champ « state » (par exemple, passage à la valeur 102 ou 103 selon la configuration).

Données à recueillir

Comparer la valeur du champ d’état avant et après

Type d’événement inferred
Demande de changement lancée
Association d’une demande de changement (RFC) à l’enregistrement de problème. Elle marque le transfert de la Gestion des problèmes à la Gestion du changement pour la mise en œuvre.
Pourquoi est-ce important ?

Essentiel au Dashboard de suivi de l’efficacité du passage aux demandes de changement. Il met en évidence les délais entre l’identification d’une correction et le lancement du processus de changement.

Où trouver ces données

Table ServiceNow « sys_audit », qui suit le renseignement du champ de référence « rfc » dans la table « problem ».

Données à recueillir

Enregistré 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, lorsque l’enregistrement devient inactif. Aucun autre travail n’est prévu.
Pourquoi est-ce important ?

Marque la fin définitive de l’instance du processus. Nécessaire au calcul du temps de cycle total.

Où trouver ces données

Table ServiceNow « problem », champ « closed_at » ou champ « state » passé à « Closed ».

Données à recueillir

Enregistré 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 ServiceNow. Elle marque le début du cycle de vie du problème et fournit l’horodatage de référence pour les mesures d’ancienneté.
Pourquoi est-ce important ?

Définit l’heure de début de tous les calculs du temps de cycle et des mesures de SLA. C’est le principal repère pour déterminer le volume des nouvelles investigations de problème.

Où trouver ces données

Table ServiceNow « problem », champ « sys_created_on ».

Données à recueillir

Enregistré lors de l’exécution de la transaction New Record

Type d’événement explicit
Solution de contournement identifiée
Saisie de texte dans le champ « Workaround » de l’enregistrement de problème. Cet événement indique le moment où l’analyste consigne une solution provisoire.
Pourquoi est-ce important ?

Permet d’alimenter le Dashboard de suivi de la publication des solutions de contournement en indiquant à quel moment la solution technique a été identifiée.

Où trouver ces données

Table ServiceNow « sys_audit », où « fieldname » correspond à « workaround ».

Données à recueillir

Comparer la valeur du 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 est-ce important ?

Permet de distinguer le temps d’investigation active du temps d’attente d’un changement et d’affiner l’analyse des goulots d’étranglement.

Où trouver ces données

Table ServiceNow « sys_audit », champ « state » passé à « Fix in Progress » (valeur généralement égale à 104).

Données à recueillir

Comparer la valeur du 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 s’agissait pas d’un problème valide.
Pourquoi est-ce important ?

Repère les pertes liées à la transformation erronée d’incidents en problèmes.

Où trouver ces données

Table ServiceNow « sys_audit », champ « state » passé de « Assess » à « Closed/Cancelled » ou à « New ».

Données à recueillir

Comparer la valeur du champ d’état avant et après

Type d’événement inferred
Résolution vérifiée
Étape de validation qui confirme l’efficacité de la résolution. Selon le degré de maturité du processus, elle peut correspondre à un état précis ou à une case à cocher.
Pourquoi est-ce important ?

Assure le contrôle qualité avant la clôture. L’absence de cette étape permet d’analyser les écarts au processus.

Où trouver ces données

Table ServiceNow « sys_audit ». Il peut s’agir d’un changement d’état (Resolved → Closed) ou d’un champ spécifique « u_resolution_verified », s’il est configuré.

Données à recueillir

Comparer la valeur du champ d’état avant et après

Type d’événement inferred
Revue après mise en œuvre terminée
Achèvement de la tâche PIR ou activation d’un indicateur PIR. Cet événement confirme qu’une analyse rétrospective a été menée pour les problèmes majeurs.
Pourquoi est-ce important ?

Alimente directement le Dashboard de suivi de la conformité des revues après mise en œuvre. L’absence de cette activité pour les problèmes hautement prioritaires indique un défaut de conformité.

Où trouver ces données

Clôture d’un enregistrement de type PIR dans la table ServiceNow « problem_task », ou changement du champ « pir_state » dans la table « problem ».

Données à recueillir

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 sur une erreur connue. Cette action est distincte de la simple saisie de la solution.
Pourquoi est-ce important ?

Essentiel pour mesurer la rapidité du partage des connaissances. Tout retard à cette étape influe directement sur le volume d’incidents récurrents.

Où trouver ces données

Table ServiceNow « sys_journal_field » ou journaux d’actions d’interface spécifiques. L’événement peut aussi être déduit de la création d’un enregistrement « kb_knowledge » de type « Known Error ».

Données à recueillir

Enregistré 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 l’analyse de la cause à la conception d’une correction définitive.
Pourquoi est-ce important ?

Permet d’alimenter le Dashboard de suivi de la rédaction des solutions et de l’application des corrections en isolant la durée de la phase de conception.

Où trouver ces données

Table ServiceNow « sys_audit », qui suit les mises à jour du champ « fix_notes ».

Données à recueillir

Comparer la valeur du champ d’état avant et après

Type d’événement inferred
Recommandé Facultatif

Guides d’extraction

Comment extraire vos données de 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 démarche de Process Mining.

Optimisez dès maintenant la gestion des problèmes pour accélérer leur résolution

Réduisez de 30 % le temps de cycle de vos enquêtes grâce au Process Mining

Démarrez votre essai gratuit

Aucune carte bancaire requise. Configuration en quelques minutes.