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

ServiceNow - Gestion des problèmes
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 complet pour analyser le `cycle de vie` de votre `gestion des problèmes` ITIL dans ServiceNow. Vous y trouverez les `attributs` nécessaires à collecter, les activités critiques à suivre et un guide d'extraction étape par étape pour votre projet de données. Cette structure vous assure la visibilité nécessaire pour réduire le temps moyen de résolution et éliminer les incidents récurrents.
  • `Attributs` recommandés pour l'analyse des causes profondes
  • Jalons et activités clés du processus
  • Guide d'extraction ServiceNow étape par étape
Vous découvrez les journaux d'événements ? Apprenez comment créer un journal d'événements Process Mining.

Attributs de gestion des problèmes

Ce sont les champs de données recommandés à inclure dans votre `journal d'événements` pour une analyse complète de votre `processus de gestion des problèmes` ITIL.
5 Obligatoire 7 Recommandé 9 Facultatif
Nom Descriptionn
Activité
Activity
L'événement ou l'action spécifique effectuéee sur le dossier de problème.
Descriptionn

Représente les étapes distinctes ou les changements de statut qui se produisent pendant le cycle de vie d'un enregistrement de problème. Par exemple : 'Enregistrement de problème créé', 'Cause profonde identifiée' ou 'Attribué au groupe de support'. Cet attribut est impératif pour construire la carte de processus et visualiser la séquence des événements.

Pourquoi est-ce important ? :

Il définit les nœuds de la carte de processus, pour visualiser des workflows et des variantes de processus.

Source des données :

Dérivé des tables 'sys_audit', 'sys_history_line' ou des changements d'état dans la table 'problem'

Exemples
Enregistrement de Problème CrééAnalyse terminéeÉtat changé à Clôturé
Enregistrement de problème
ProblemNumber
L'identifiant unique de l'enregistrement de problème.
Descriptionn

La clé alphanumérique unique attribuée à un enregistrement de problème spécifique dans ServiceNow (par exemple, PRB000123). Cet identifiant sert de élément central reliant toutes les activités du processus, de l'enregistrement initial à l'analyse de la cause profonde jusqu'à la clôture finale. Dans l'analyse de Process Mining, cet attribut fonctionne comme l'ID de cas, permettant la reconstruction du parcours de résolution de problème complet.

Pourquoi est-ce important ? :

C'est la clé primaire pour différencier les cas uniques et regrouper les événements connexes dans le graphique de processus.

Source des données :

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.
Descriptionn

Enregistre le horodatage spécifique lorsqu'un changement ou une action a été loggué dans le système. Ce point de données est indispensable pour ordonner les activités chronologiquement et calculer les métriques de durée telles que les temps de cycle et les délais entre les étapes du processus.

Pourquoi est-ce important ? :

Primordial pour ordonner les événements et calculer tous les KPI basés sur le temps.

Source des données :

Champ 'sys_created_on' de ServiceNow dans les tables d'audit/historique

Exemples
2023-10-12T08:30:00Z2023-10-12T14:45:12Z
Dernière mise à jour des données
LastDataUpdate
L'horodatage de l'extraction ou de la dernière actualisation des données.
Descriptionn

Indique la fraîcheur du jeu de données utilisé pour l'analyse. Cela aide les analystes à comprendre s'ils examinent des données en temps réel ou un instantané historique, ce qui est impératif pour interpréter correctement les statuts des cas ouverts.

Pourquoi est-ce important ? :

Garantit que les utilisateurs savent à quel point les données sont à jour pour un reporting opérationnel précis.

Source des données :

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

Exemples
2023-11-01T12:00:00Z
Système source
SourceSystem
Le nom du système d'où proviennent les données.
Descriptionn

Identifie l'instance ou l'environnement ServiceNow spécifique à partir duquel les données de gestion des problèmes ont été extraites. C'est particulièrement utile dans les environnements multi-systèmes pour suivre la traçabilité des données et gérer les nuances spécifiques au système dans l'analyse.

Pourquoi est-ce important ? :

Fournit un contexte pour l'origine des données, en particulier lors de la fusion de données provenant de plusieurs outils ITSM.

Source des données :

Codé en dur lors de l'extraction (par exemple, 'ServiceNow Production')

Exemples
ServiceNow ProdServiceNow EMEA
Catégorie de cause profonde
RootCauseCategory
La classification de la cause profonde identifiée.
Descriptionn

Catégorise la raison sous-jacente du problème, telle que l'Erreur logicielle, l'Erreur humaine ou la Défaillance matérielle. Cet attribut alimente le tableau de bord 'Précision de la Catégorisation des Causes Fondamentales' et aide à identifier les schémas de défaillance systémique.

Pourquoi est-ce important ? :

Permet l'analyse des schémas de défaillance pour orienter les améliorations stratégiques.

Source des données :

Table ServiceNow 'problem', 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 de problème.
Descriptionn

Reflète le stade actuel de l'enregistrement de problème, tel que Ouvert, Analyse des causes profondes, Correction en cours ou Fermé. C'est un facteur principal pour filtrer et comprendre la composition de l'arriéré dans l'Analyse du vieillissement des enregistrements de problèmes anciens.

Pourquoi est-ce important ? :

L'indicateur de statut principal utilisé pour filtrer les cas ouverts par rapport aux cas fermés.

Source des données :

Table ServiceNow 'problem', champ 'state'

Exemples
NouveauÉvaluerAnalyse des causes profondesRésolu
Groupe de support
AssignmentGroup
L'équipe technique responsable de la résolution du problème.
Descriptionn

Désigne le groupe de support ou l'équipe spécifique actuellement affecté au problème. Cet attribut est indispensable à le tableau de bord 'Analyse des Réaffectations des Groupes de Support' afin de suivre les transferts entre les équipes et d'identifier les silos organisationnels.

Pourquoi est-ce important ? :

Primordial pour identifier les points de blocage interservices et analyser l'efficacité des transferts.

Source des 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
Le nombre d'incidents liés à cet enregistrement de problème.
Descriptionn

Quantifie l'impact du problème en comptant le nombre d'incidents qui y sont associés. Des chiffres élevés dans ce champ, en particulier pour les Erreurs connues, alimentent le tableau de bord 'Erreurs connues et récurrence des incidents'.

Pourquoi est-ce important ? :

Mesure l'ampleur de l'impact utilisateur causé par le problème.

Source des données :

Table ServiceNow 'problem', champ 'related_incidents' (le nom du champ varie) ou nombre d'enregistrements liés

Exemples
1501200
Nombre de Réaffectations
ReassignmentCount
Le nombre de fois où le problème a été réaffecté entre les groupes.
Descriptionn

Un compteur qui suit la fréquence de changement du groupe d'affectation. C'est la source directe pour le KPI 'Nombre de réaffectations d'enregistrements de problèmes' et aide à identifier les effets de 'ping-pong' où les tickets rebondissent entre les équipes.

Pourquoi est-ce important ? :

Indicateur direct de friction de processus et de manque de propriété claire.

Source des données :

Table ServiceNow 'problem', champ 'reassignment_count'

Exemples
0312
Priorité
Priority
Le niveau de priorité attribué à l'enregistrement de problème.
Descriptionn

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 la segmentation de l'analyse par criticité, soutenant le tableau de bord 'Surveillance des non-conformités SLA et des priorités'.

Pourquoi est-ce important ? :

Permet la segmentation de la performance des processus par criticité métier.

Source des données :

Table ServiceNow 'problem', champ 'priority'

Exemples
1 - Critique2 - Élevée3 - Modérée
Utilisateur assigné
AssignedTo
L'individu spécifique assigné à travailler sur le problème.
Descriptionn

Identifie l'utilisateur actuellement responsable de l'enregistrement de problème. L'analyse de cet attribut aide à comprendre la distribution de la charge de travail, la performance individuelle et les points de blocage potentiels au niveau des ressources.

Pourquoi est-ce important ? :

Clé pour l'analyse de l'efficacité des ressources et de la charge de travail individuelle.

Source des données :

Table ServiceNow 'problem', champ 'assigned_to'

Exemples
Alice SmithBob JonesAdministrateur système
Date d'échéance du SLA
SlaDueDate
La date/heure cible pour la résolution du problème selon le SLA.
Descriptionn

Le horodatage indiquant quand le problème doit être résolu pour respecter les accords de niveau de service. C'est la base de référence pour le tableau de bord 'Surveillance des violations de SLA et des priorités' et le calcul des taux de conformité.

Pourquoi est-ce important ? :

Base de référence pour le calcul de l'état de non-respect du SLA.

Source des données :

Table ServiceNow 'task_sla' liée au problème

Exemples
2023-12-31T17:00:00Z
Durée d'attente
PendingDuration
Temps total passé par le problème en état suspendu ou en attente.
Descriptionn

Agrège le temps passé dans des statuts comme 'En attente fournisseur' ou 'En suspens'. Cette métrique est utilisée pour l''Analyse des états en attente et des temps d'attente' afin de séparer le temps de traitement interne des retards externes.

Pourquoi est-ce important ? :

Différencie l'inefficacité de l'équipe des dépendances externes.

Source des données :

Calculé : Somme de la durée des intervalles où État = En attente/En suspens

Exemples
5 jours0 minutes
Élément de configuration
ConfigurationItem
L'actif ou le service spécifique affecté par le problème.
Descriptionn

Identifie l'Élément de Configuration (CI) lié à l'enregistrement de problème. L'analyse de ceci aide à corréler les problèmes avec des matériels, logiciels ou services spécifiques, soutenant le tableau de bord 'Précision de la Catégorisation des Causes Fondamentales'.

Pourquoi est-ce important ? :

Lie les problèmes de processus à des actifs physiques ou logiques spécifiques.

Source des données :

Table ServiceNow 'problem', champ 'cmdb_ci'

Exemples
Serveur SAP ERP 01Service de messagerie ExchangeOracle DB Prod
Est une erreur connue
IsKnownError
Indicateur indiquant si le problème est classifié comme Erreur Connue.
Descriptionn

Identifie si l'enregistrement de problème a été converti ou marqué comme Erreur Connue. C'est indispensable pour l'analyse 'Erreurs Connues et Récurrence des Incidents' afin de voir si le processus de gestion des connaissances est efficace.

Pourquoi est-ce important ? :

Distingue les enquêtes actives des défauts acceptés avec des solutions de contournement.

Source des données :

Table ServiceNow 'problem', champ 'known_error'

Exemples
truefaux
Numéro de demande de changement
ChangeRequestNumber
L'identifiant de la demande de changement initiée pour corriger le problème.
Descriptionn

Lie l'enregistrement de problème à un enregistrement de Gestion du changement (RFC). Cette connexion est fondamentale pour le tableau de bord 'Efficacité de la Transition des Demandes de Changement' afin de mesurer la vitesse de transfert entre le diagnostic des problèmes et l'exécution des changements d'infrastructure.

Pourquoi est-ce important ? :

Suit la transition de la gestion des problèmes à la gestion des changements.

Source des données :

Table ServiceNow 'problem', champ 'rfc'

Exemples
CHG003001CHG004552
Résultat du PIR
PostImplementationReviewResult
Le résultat ou le `statut` de complétion de l'Examen post-implémentation.
Descriptionn

Stocke le résultat ou le statut du PIR (par exemple, Terminé, Non requis, En attente). Cet attribut est nécessaire pour le tableau de bord de conformité des examens post-implémentation afin de garantir que les problèmes majeurs sont examinés.

Pourquoi est-ce important ? :

Métrique de contrôle qualité garantissant l'apprentissage des incidents majeurs.

Source des données :

Table ServiceNow 'problem', champ 'pir_state' ou champ personnalisé similaire

Exemples
TerminéExonéréEn attente
Service métier
BusinessService
Le service métier de haut niveau impacté par le problème.
Descriptionn

Représente le service orienté métier (par exemple, 'Service de paie', 'Portail client') plutôt que le composant technique. Cela offre une vue axée sur l'entreprise pour le reporting aux parties prenantes.

Pourquoi est-ce important ? :

Connecte les problèmes techniques aux flux de valeur métier.

Source des données :

Table ServiceNow 'problem', champ 'business_service'

Exemples
Banque en ligneEmail interne
Solution de contournement publiée
WorkaroundPublished
Indique si une solution de contournement a été documentée et partagée.
Descriptionn

Un indicateur booléen ou d'état indiquant si une solution de contournement temporaire a été identifiée et publiée dans la Base de connaissances ou la Base d'erreurs connues. Cela soutient le tableau de bord 'Performance de publication des solutions de contournement'.

Pourquoi est-ce important ? :

Critique pour mesurer la rapidité avec laquelle l'impact commercial est atténué avant une correction finale.

Source des données :

Table ServiceNow 'problem', champ 'work_around' (présence de texte) ou statut spécifique

Exemples
truefaux
Temps de rédaction de la solution
SolutionDraftingTime
Temps entre l'identification de la cause profonde et lÀ proposition d'une solution.
Descriptionn

Suit la durée de la phase de conception où une correction est développée une fois la cause connue. Ceci soutient le tableau de bord 'Rédaction de la solution et application de la correction'.

Pourquoi est-ce important ? :

Isole la performance de la phase de 'conception de la correction'.

Source des données :

Calculé : Horodatage de 'Solution Proposée Rédigée' moins 'Cause Fondamentale Identifiée'

Exemples
2 jours4 heures
Obligatoire Recommandé Facultatif

Activités de gestion des problèmes

Ce sont les étapes clés du `processus` et les jalons du `cycle de vie` à capturer dans votre `journal d'événements` pour une découverte précise de vos `workflows` de problèmes.
8 Recommandé 6 Facultatif
Activité Descriptionn
Affecté au Groupe de Support
Le routage de l'enregistrement de problème vers une équipe technique spécifique pour enquête. Cette activité suit le `flux` de propriété et est indispensable pour l'analyse des transferts.
Pourquoi est-ce important ? :

Primordial pour le tableau de bord 'Analyse des Réaffectations des Groupes de Support' afin d'identifier les effets de ping-pong et les points de blocage entre les équipes.

Source des données :

Table ServiceNow 'sys_audit' ou 'sys_history_line' suivant les modifications du champ 'assignment_group'.

Capture

Comparer le champ de statut avant/après

Type d'événement inferred
Cause profonde identifiée
Le point où les codes de 'Cause profonde' sont renseignés ou l'état passe à 'Correction en cours'. Cela représente le diagnostic réussi du problème.
Pourquoi est-ce important ? :

Calcule le Délai Moyen d'Identification de la Cause Fondamentale et soutient le tableau de bord 'Temps de Cycle d'Investigation de la Cause Fondamentale'. C'est un jalon majeur du processus.

Source des données :

Table ServiceNow 'sys_audit' suivant les modifications du champ de catégorie 'root_cause' ou la transition vers l'état 'Fix in Progress'.

Capture

Comparer le champ de statut avant/après

Type d'événement inferred
Correction permanente appliquée
Le moment où le problème est marqué comme Résolu, souvent déclenché par la clôture de la `demande de changement` associée. Cela indique que le travail technique est terminé.
Pourquoi est-ce important ? :

Détermine la fin du cycle de correction actif. Utilisé pour calculer le temps de résolution total par rapport au SLA.

Source des données :

Table ServiceNow 'sys_audit', transition du champ 'state' vers 'Resolved' (valeur 106 typique).

Capture

Comparer le champ de statut avant/après

Type d'événement inferred
Demande de changement initiée
L'association d'une `Demande de changement` (RFC) à l'`Enregistrement de problème`. Cela signifie le transfert de la Gestion des problèmes à la `Gestion du changement` pour l'implémentation.
Pourquoi est-ce important ? :

Vital pour le tableau de bord d'efficacité de la transition des demandes de changement. Identifie les retards entre la découverte d'une correction et le démarrage du processus de changement.

Source des données :

Table ServiceNow 'sys_audit' suivant le remplissage du champ de référence 'rfc' sur la table 'problem'.

Capture

Comptabilisé lorsque la transaction Créer un changement normal est exécutée

Type d'événement explicit
Enregistrement de problème clôturé
L'`événement` final du `cycle de vie` où l'enregistrement devient inactif. Aucun autre travail n'est attendu.
Pourquoi est-ce important ? :

Le point final définitif de l'instance de processus. Requis pour le calcul du temps de cycle total.

Source des données :

Table ServiceNow 'problem', champ 'closed_at' ou transition d'état vers 'Closed'.

Capture

Comptabilisé lorsque la transaction Fermer le problème est exécutée

Type d'événement explicit
Enregistrement de Problème Créé
La création initiale d'un enregistrement de problème dans le système ServiceNow. Cela marque le début du `cycle de vie` de la `gestion des problèmes` et définit le `horodatage` de référence pour les métriques de vieillissement.
Pourquoi est-ce important ? :

Établit l'heure de début pour tous les calculs de temps de cycle et les mesures de SLA. C'est l'ancre principale pour identifier le volume des enquêtes de problèmes entrants.

Source des données :

Table ServiceNow 'problem', champ 'sys_created_on'.

Capture

Comptabilisé lorsque la transaction Nouvel enregistrement est exécutée

Type d'événement explicit
Investigation commencée
La transition de l'état de l'enregistrement de problème de 'New' à 'Assess' ou 'Root Cause Analysis'. Cela signifie qu'un analyste a activement commencé à travailler sur le problème.
Pourquoi est-ce important ? :

Marque la fin du temps d'attente initial en file d'attente et le début de la phase d'investigation active, soutenant l'analyse des États en attente.

Source des données :

Table ServiceNow 'sys_audit' suivant les modifications du champ 'state' (par exemple, valeur passant à 102 ou 103 selon la configuration).

Capture

Comparer le champ de statut avant/après

Type d'événement inferred
Solution de contournement identifiée
L'action de saisir du texte dans le champ 'Workaround' de l'enregistrement de problème. Cela capture le moment où une solution temporaire est documentée par l'analyste.
Pourquoi est-ce important ? :

Soutient le tableau de bord de performance de publication des solutions de contournement en établissant le moment où la solution technique a été connue pour la première fois.

Source des données :

Table ServiceNow 'sys_audit' où 'fieldname' est 'workaround'.

Capture

Comparer le champ de statut avant/après

Type d'événement inferred
État changé à Correction en cours
L'enregistrement passe à un état indiquant qu'une correction est en cours de développement ou de déploiement (souvent en attente de la `Gestion du changement`).
Pourquoi est-ce important ? :

Différencie le temps d'investigation actif du temps 'en attente de changement', affinant ainsi l'analyse des points de blocage.

Source des données :

Table ServiceNow 'sys_audit', transition du champ 'state' vers 'Fix in Progress' (valeur 104 typique).

Capture

Comparer le champ de statut avant/après

Type d'événement inferred
Évaluation rejetée
L'enregistrement de problème est renvoyé à un état antérieur ou annulé pendant la phase d'évaluation car il ne s'agissait pas d'un problème valide.
Pourquoi est-ce important ? :

Identifie le gaspillage dans le processus où les incidents sont incorrectement promus en problèmes.

Source des données :

Table ServiceNow 'sys_audit', transition du champ 'state' vers 'Closed/Cancelled' ou 'New' depuis 'Assess'.

Capture

Comparer le champ de statut avant/après

Type d'événement inferred
Examen post-implémentation terminé
La complétion de la tâche PIR ou le réglage d'un indicateur PIR. Cela confirme qu'une analyse rétrospective a été effectuée pour les problèmes majeurs.
Pourquoi est-ce important ? :

Facilite le tableau de bord 'Conformité des Revues Post-Implémentation'. L'absence de cette activité sur les problèmes de haute priorité indique un échec de conformité.

Source des données :

Fermeture de la table ServiceNow 'problem_task' (type=PIR), ou changement du champ 'pir_state' de la table 'problem'.

Capture

Dériver en comparant le champ X à Y

Type d'événement inferred
Résolution vérifiée
Une étape de validation où l'efficacité de la résolution est confirmée. Il peut s'agir d'un état spécifique ou d'une case à cocher selon la maturité du processus.
Pourquoi est-ce important ? :

Assure le contrôle qualité avant la clôture. Contourner cette étape permet l'analyse des Écarts de Processus.

Source des données :

Table ServiceNow 'sys_audit'. Peut être un changement d'état (Resolved -> Closed) ou un champ spécifique 'u_resolution_verified' si configuré.

Capture

Comparer le champ de statut avant/après

Type d'événement inferred
Solution de contournement publiée
L'exécution de l'action 'Communicate Workaround', qui pousse la solution de contournement vers les incidents liés ou crée un article 'Known Error'. Ceci est distinct de la simple saisie de la solution de contournement.
Pourquoi est-ce important ? :

Critique pour mesurer la vitesse de partage des connaissances. Les retards ici impactent directement le volume des incidents récurrents.

Source des données :

Champ 'sys_journal_field' de ServiceNow ou logs spécifiques d'actions UI ; peut également être déduit si un enregistrement 'kb_knowledge' de type 'Known Error' est créé.

Capture

Comptabilisé lorsque la transaction Communiquer la solution de contournement est exécutée

Type d'événement explicit
Solution proposée rédigée
La saisie de données dans les champs 'Fix Notes' ou 'Resolution Code'. Indique que l'analyste est passé de la compréhension de la cause à la conception de la correction permanente.
Pourquoi est-ce important ? :

Soutient le tableau de bord de rédaction de la solution et d'application de la correction en isolant la durée de la phase de conception.

Source des données :

Table ServiceNow 'sys_audit' suivant les mises à jour du champ 'fix_notes'.

Capture

Comparer le champ de statut avant/après

Type d'événement inferred
Recommandé Facultatif

Guides d'extraction

Comment obtenir vos données de ServiceNow Incident Management