Votre modèle de données pour la gestion des problèmes
Votre modèle de données pour la gestion des problèmes
- 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
Attributs de gestion des problèmes
| 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
|
|||
Activités de gestion des problèmes
| 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
|
|||
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 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
Aucune carte bancaire requise. Configuration en quelques minutes.