Votre template de données de gestion des problèmes

Gestion des problèmes ServiceNow
Votre `template de données` de `gestion des problèmes`

Votre template de données de gestion des problèmes

Ce `template` fournit un plan complet pour analyser le `cycle de vie` de votre `gestion des problèmes` ITIL au sein de 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
Nouveau dans 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é 10 Facultatif
Nom Description
Activité
Activity
L'`événement` ou l'action spécifique effectué sur l'enregistrement de problème.
Description

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

Pourquoi c'est important

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

Où obtenir

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

La clé alphanumérique unique attribuée à un enregistrement de problème spécifique au sein de ServiceNow (par exemple, PRB000123). Cet identifiant sert de fil conducteur 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 de bout en bout.

Pourquoi c'est important

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

Où obtenir

Table ServiceNow 'problem', champ 'number'

Exemples
PRB004512PRB009823PRB001122
Timestamp de l'événement
EventTime
La date et l'heure exactes auxquelles une activité s'est produite.
Description

Enregistre le timestamp spécifique lorsqu'un changement ou une action a été loggué dans le système. Ce point de données est fondamental 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 c'est important

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

Où obtenir

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

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 crucial pour interpréter correctement les statuts des cas ouverts.

Pourquoi c'est important

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

Où obtenir

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

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 lignée des données et gérer les nuances spécifiques au système dans l'analyse.

Pourquoi c'est important

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

Où obtenir

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

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

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 c'est important

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

Où obtenir

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

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 c'est important

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

Où obtenir

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

Désigne le groupe de support ou l'équipe spécifique actuellement affecté au problème. Cet attribut est vital pour 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 c'est important

Crucial pour identifier les goulots d'étranglement entre les départements et analyser l'efficacité des transferts.

Où obtenir

Table ServiceNow 'problem', champ 'assignment_group'

Exemples
Opérations RéseauAdministrateurs de bases de donnéesService Desk
Nombre d'incidents lié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 y sont associés. Des chiffres élevés dans ce champ, en particulier pour les Erreurs connues, alimentent le dashboard 'Erreurs connues et récurrence des incidents'.

Pourquoi c'est important

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

Où obtenir

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

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 c'est important

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

Où obtenir

Table ServiceNow 'problem', champ 'reassignment_count'

Exemples
0312
Priorité
Priority
Le niveau de priorité attribué à l'enregistrement de 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 la segmentation de l'analyse par criticité, soutenant le tableau de bord 'Surveillance des non-conformités SLA et des priorités'.

Pourquoi c'est important

Permet la segmentation des performances des processus par criticité métier.

Où obtenir

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

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 goulots d'étranglement potentiels au niveau des ressources.

Pourquoi c'est important

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

Où obtenir

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

Le timestamp 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 dashboard 'Surveillance des violations de SLA et des priorités' et le calcul des taux de conformité.

Pourquoi c'est important

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

Où obtenir

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

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 c'est important

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

Où obtenir

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

Exemples
5 jours0 minutes
Durée RCA
RootCauseAnalysisDuration
Temps écoulé entre la création du problème et l'identification de la cause profonde.
Description

Une durée calculée mesurant l'efficacité de la phase d'investigation. Cela soutient directement l'indicateur clé de performance (KPI) 'Délai Moyen d'Identification de la Cause Fondamentale' et aide à identifier les lacunes en compétences techniques ou les problèmes de complexité.

Pourquoi c'est important

Métrique clé d'efficacité pour la phase d'investigation.

Où obtenir

Calculé : Horodatage de l'activité 'Cause Fondamentale Identifiée' moins l'heure de 'Création de l'Enregistrement de Problème'

Exemples
3 jours 4 heures12 heures
Élément de configuration
ConfigurationItem
L'actif ou le service spécifique affecté par le problème.
Description

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 c'est important

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

Où obtenir

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

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

Pourquoi c'est important

Distingue les investigations actives des défauts acceptés avec des solutions de contournement.

Où obtenir

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

Lie l'enregistrement de problème à un enregistrement de Gestion des Changements (RFC). Cette connexion est vitale 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 c'est important

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

Où obtenir

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

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

Pourquoi c'est important

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

Où obtenir

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

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 c'est important

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

Où obtenir

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

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 c'est important

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

Où obtenir

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 la proposition d'une solution.
Description

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

Pourquoi c'est important

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

Où obtenir

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é Description
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 critique pour l'analyse des transferts.
Pourquoi c'est important

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

Où obtenir

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 c'est 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.

Où obtenir

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 c'est important

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

Où obtenir

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 des changements` pour l'implémentation.
Pourquoi c'est important

Vital pour le dashboard 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.

Où obtenir

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

Capture

Enregistré 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 c'est important

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

Où obtenir

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

Capture

Enregistré 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 `timestamp` de référence pour les métriques de vieillissement.
Pourquoi c'est 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 investigations de problèmes entrants.

Où obtenir

Table ServiceNow 'problem', champ 'sys_created_on'.

Capture

Enregistré 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 c'est 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.

Où obtenir

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 c'est important

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

Où obtenir

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 des changements`).
Pourquoi c'est important

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

Où obtenir

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 c'est important

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

Où obtenir

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 c'est important

Soutient directement 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é.

Où obtenir

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 c'est important

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

Où obtenir

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 c'est important

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

Où obtenir

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

Enregistré 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 c'est important

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

Où obtenir

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 Problem Management`