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 profondes
- Jalons et activités clés du processus
- Guide d'extraction ServiceNow étape par étape
Attributs de gestion des problèmes
| 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
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
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
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
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'
Pourquoi est-ce important ? :
L'indicateur de
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
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
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
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
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
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
|
|||
Activités de gestion des problèmes
| 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
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
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
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
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
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
|
|||