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

BMC Helix ITSM
Votre template de données pour la gestion des problèmes

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

Ce template offre une structure complète pour analyser vos workflows d'enquête sur les causes profondes au sein de BMC Helix ITSM. Il présente les attributs et activités de processus essentiels nécessaires pour construire un journal d'événements (Event Log) détaillé, ainsi que des conseils d'extraction pratiques. En suivant ce guide, vous pouvez identifier les goulots d'étranglement cachés et fluidifier votre cheminement vers la résolution permanente des incidents.
  • Champs de données essentiels pour l'analyse des causes profondes
  • Jalons de processus standardisés pour le suivi
  • Guide d'extraction spécifique pour BMC Helix ITSM
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 tableau contient les champs de données recommandés nécessaires pour alimenter votre journal d'événements (Event Log) pour une analyse approfondie du cycle de vie de votre gestion des problèmes.
5 Obligatoire 9 Recommandé 5 Facultatif
Nom Description
Activité
Activity
La tâche spécifique ou l'événement de changement de statut qui s'est produit.
Description

Cet attribut représente l'étape spécifique effectuée dans le cycle de vie de la gestion des problèmes, telle que « Problem Record Logged », « Root Cause Identified » ou « Solution Database Updated ». Dans BMC Helix, celles-ci sont souvent dérivées de l'historique de statut, des journaux d'audit (Audit Logs) ou des horodatages de transactions spécifiques au sein du module d'enquête sur les problèmes.

Cet attribut est le cœur de la découverte de processus. En analysant la séquence de ces activités, l'outil de Process Mining construit la carte des processus, révélant le flux de travail réel par rapport au processus conçu. Il met en évidence les boucles, les reprises de travail et les déviations par rapport à la procédure opérationnelle standard.

Des noms d'activités précis sont cruciaux pour comprendre ce qui s'est réellement passé pendant le cycle de vie. Ces données permettent de mesurer les temps de transition entre des étapes spécifiques, comme le temps écoulé entre l'identification d'une cause profonde et l'initiation d'une demande de changement.

Pourquoi c'est important

Il définit les nœuds dans la carte des processus et permet la visualisation du workflow.

Où obtenir

Dérivé de l'historique de statut PBM:Problem Investigation ou de PBM:AuditLogSystem

Exemples
Enregistrement de problème journaliséAffecté au Groupe de SupportInvestigation commencéeCause profonde identifiée
Enregistrement de problème
ProblemRecord
L'identifiant unique du cas d'enquête de problème.
Description

Cet attribut sert d'identifiant central pour le processus de gestion des problèmes. Dans BMC Helix ITSM, il s'agit généralement du champ « Problem ID » (par exemple, PBI00000012345) trouvé sur le formulaire PBM:Problem Investigation. Il relie toutes les activités associées, de l'enregistrement initial du problème à la clôture finale et à l'examen post-implémentation.

Dans l'analyse de Process Mining, cet attribut est utilisé pour regrouper des événements individuels en une seule instance de processus. Il permet aux analystes de visualiser le parcours de bout en bout d'une enquête de problème spécifique. Sans cet identifiant, il serait impossible de corréler la séquence des actions entreprises par les différents groupes de support et coordinateurs.

Ce champ fonctionne comme la clé primaire du journal d'événements (Event Log) et est essentiel pour toutes les agrégations au niveau du cas, comme le calcul du temps de cycle total par problème ou le décompte du nombre de problèmes par niveau de priorité.

Pourquoi c'est important

C'est la clé fondamentale requise pour construire la vue du processus et suivre le cycle de vie des problèmes spécifiques.

Où obtenir

PBM:Problem Investigation form, field 'Problem ID'

Exemples
PBI00000004512PBI00000004513PBI00000004514
Heure de l'événement
EventTime
L'horodatage de l'activité spécifique.
Description

Cet attribut enregistre la date et l'heure exactes auxquelles une activité a eu lieu. Dans BMC Helix ITSM, cela correspond à des champs tels que « Submit Date », « Last Modified Date » ou des horodatages spécifiques enregistrés dans les tables d'historique correspondant aux changements de statut.

En analyse, cet attribut est utilisé pour séquencer les événements chronologiquement et calculer les durées. Il permet la mesure des temps de cycle entre deux points quelconques du processus, tels que le « Investigation Cycle Time » ou le « Workaround Publication Lead Time ».

Des horodatages précis sont essentiels pour identifier les goulots d'étranglement. En calculant la différence de temps entre des événements consécutifs, les analystes peuvent identifier exactement où se produisent les retards, que ce soit pendant l'attribution initiale ou la phase de révision finale.

Pourquoi c'est important

Il permet le calcul de tous les KPI basés sur la durée et le séquencement des événements.

Où obtenir

Tables d'historique ou journaux d'audit associés à PBM:Problem Investigation

Exemples
2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:20:10Z
Dernière mise à jour des données
LastDataUpdate
L'horodatage de l'extraction ou de la dernière actualisation des données.
Description

Cet attribut indique la dernière fois que les données ont été chargées dans l'application de Process Mining. Il garantit que les analystes sont conscients de la fraîcheur des données qu'ils consultent. Il est généralement généré par le script d'extraction ou l'outil de pipeline de données.

En analyse, cela permet d'éviter les décisions basées sur des données obsolètes. Par exemple, si un manager consulte les « Open Problem Records », savoir que les données ont été mises à jour il y a une heure plutôt qu'il y a une semaine change considérablement l'interprétation de la charge de travail actuelle.

Il est également utilisé pour les chargements de données incrémentiels. En suivant l'heure de la dernière mise à jour, le processus ETL peut récupérer uniquement les enregistrements qui ont changé depuis l'extraction précédente, optimisant ainsi les performances et réduisant la charge du système.

Pourquoi c'est important

Il assure la fraîcheur des données et facilite les stratégies de chargement de données incrémentiel.

Où obtenir

Heure du système au moment de l'extraction

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

Cet attribut identifie le système logiciel à partir duquel les données de processus ont été extraites, dans ce cas, « BMC Helix ITSM ». Il est particulièrement important dans les environnements multi-systèmes où le Process Mining pourrait agréger les données de divers outils ITSM, de développement ou de fournisseurs externes.

En analyse, ce champ sert de balise de métadonnées qui valide l'origine de l'enregistrement. Si la vue de Process Mining combine des données de BMC Helix pour la gestion des problèmes et un système distinct pour le développement logiciel (par exemple, Jira), cet attribut aide à segmenter l'analyse par l'outil d'origine.

Il facilite également le dépannage technique. Si des problèmes de qualité des données surviennent, connaître le système source permet aux ingénieurs de données de remonter le problème jusqu'à la routine d'extraction spécifique ou à la base de données source.

Pourquoi c'est important

Il offre une traçabilité et un contexte, notamment dans les vues de processus multi-systèmes.

Où obtenir

Codé en dur pendant le processus d'extraction

Exemples
BMC Helix ITSMRemedy OnDemandBMC ITSM Prod
Catégorie de Cause Racine
RootCauseCategory
La classification de la cause sous-jacente du problème.
Description

Cet attribut contient la catégorie sélectionnée lorsque la cause profonde est identifiée (par exemple, « Software Error », « Hardware Failure », « Process Gap »). Dans BMC Helix, elle est généralement sélectionnée à partir des menus « Root Cause » ou « Generic Categorization ».

Cet attribut est essentiel pour la vue « Fix Effectiveness and Quality ». Il permet à l'organisation de corréler des types spécifiques de causes profondes avec les taux de reprise ou les longs délais d'enquête. Par exemple, il pourrait révéler que les problèmes de « Software Error » prennent systématiquement deux fois plus de temps à résoudre que les problèmes de « Hardware Failure ».

Il est également utilisé pour calculer le « Root Cause Categorization Rate ». Un pourcentage élevé de valeurs « Unknown » ou « Other » dans ce champ suggère un besoin d'une meilleure formation technique ou d'options de catégorisation plus granulaires.

Pourquoi c'est important

Il permet l'analyse des tendances des problèmes systémiques et soutient une gestion proactive des problèmes.

Où obtenir

PBM : Formulaire d'investigation de problème, champs de l'onglet « Cause racine » ou de catégorisation

Exemples
Module logicielInfrastructure réseauErreur humaine
CI de service
ServiceCI
Le service métier principal ou l'élément de configuration affecté.
Description

Cet attribut identifie l'élément de configuration de service (CI) lié au problème, tel que « Email Service », « SAP ERP » ou « Wi-Fi Network ». Dans BMC Helix, il s'agit souvent du champ « Service+ » ou de la relation CI principale.

En analyse, cela permet la segmentation des enregistrements de problèmes par produit ou service. Cela aide la direction informatique à comprendre quels services sont les plus fragiles et génèrent le plus d'enquêtes de problèmes. Cela alimente le dashboard « Throughput and Priority Volume » en ajoutant une dimension produit.

La corrélation de cet attribut avec le « Investigation Cycle Time » peut montrer si certains services complexes (comme un système bancaire central) nécessitent intrinsèquement des périodes d'enquête plus longues par rapport aux services courants (comme l'impression).

Pourquoi c'est important

Il relie la performance du processus à des produits ou services métier spécifiques.

Où obtenir

PBM:Problem Investigation form, field 'ServiceCI' or 'CI Name'

Exemples
Service de messagerieSystème de paieVPN d'entreprise
Coordinateur des problèmes
ProblemCoordinator
L'utilisateur individuel assigné pour coordonner l'enquête.
Description

Cet attribut nomme la personne spécifique responsable de l'enregistrement de problème. Dans BMC Helix ITSM, il s'agit du champ « Problem Coordinator ». Cette personne est propriétaire du cycle de vie du problème même si des tâches sont déléguées à d'autres.

Cet attribut prend en charge le dashboard « Support Group Workload Distribution ». Il aide les managers à identifier si des individus spécifiques sont surchargés d'enquêtes tandis que d'autres ont de la capacité. Il permet également une analyse des performances au niveau individuel, aidant à identifier les besoins en formation ou les collaborateurs très performants.

Dans le Process Mining, ce champ agit comme un attribut de ressource. Il aide à visualiser comment le travail circule entre les individus et peut mettre en évidence des points de défaillance uniques où un processus repose trop fortement sur un expert spécifique.

Pourquoi c'est important

Il permet l'analyse des ressources et l'équilibrage de la charge de travail au niveau individuel.

Où obtenir

PBM:Problem Investigation form, field 'Problem Coordinator'

Exemples
John DoeJane SmithAdministrateur Système
Date d'échéance du `SLA`
SLADueDate
La date et l'heure cibles auxquelles le problème doit être résolu.
Description

Cet attribut contient la date limite de résolution du problème basée sur l'accord de niveau de service. Dans BMC Helix, il s'agit souvent du champ « Target Resolution Date » ou d'un horodatage de jalon SLA calculé.

Cet attribut est la base du dashboard « SLA Compliance and Breach Trends ». En comparant cet horodatage avec celui de l'activité « Resolution Verified », le système calcule si le SLA a été respecté ou enfreint.

La visualisation de cette date permet aux analystes de voir à quel point l'équipe est juste dans ses délais. Résolvent-ils les problèmes des jours à l'avance, ou terminent-ils systématiquement quelques minutes avant la violation ? Cette information oriente la planification des capacités.

Pourquoi c'est important

C'est le point de référence pour le calcul de toutes les métriques de conformité et de ponctualité.

Où obtenir

PBM:Problem Investigation form, 'Target Resolution Date' field

Exemples
2023-12-01T17:00:00Z2023-12-02T09:00:00Z
Déclencheur d'investigation
InvestigationDriver
La raison pour laquelle l'enquête sur le problème a été initiée.
Description

Cet attribut classe le déclencheur de l'enregistrement de problème, tel que « Incident Volume », « Major Incident », « Vendor Notification » ou « Proactive Trend Analysis ». Dans BMC Helix, il s'agit du champ « Investigation Driver ».

Cet attribut prend en charge le dashboard « Proactive Identification Trends ». Il permet à l'organisation de mesurer le passage d'une gestion réactive des problèmes (répondre aux incidents) à une gestion proactive (identifier les risques avant qu'ils ne se manifestent).

L'analyse des flux de processus par « Investigation Driver » peut révéler différents comportements. Par exemple, les problèmes « Proactifs » peuvent rester plus longtemps dans la file d'attente car ils ne causent pas d'interruptions immédiates, tandis que les problèmes motivés par des « Major Incidents » sont traités en urgence.

Pourquoi c'est important

Il distingue le travail réactif du travail proactif, un indicateur clé de maturité.

Où obtenir

PBM:Problem Investigation form, field 'Investigation Driver'

Exemples
RéactifProactifIncidents récurrents
Groupe de support
SupportGroup
L'équipe technique actuellement assignée à l'enquête sur le problème.
Description

Cet attribut reflète le groupe de support spécifique (par exemple, « Server Admin », « Database Support ») responsable de l'enregistrement de problème au moment de l'événement. Dans BMC Helix, il s'agit du champ « Assigned Group ».

Cet attribut est essentiel pour les dashboards « Support Group Workload Distribution » et « Support Group Reassignment Analysis ». Il permet aux analystes de segmenter la carte de processus par équipe, révélant quels groupes gèrent le plus grand volume et lesquels sont des goulots d'étranglement dans le processus d'enquête.

L'analyse des transferts entre les groupes de support aide à identifier les comportements d'« allers-retours » (ping-pong), où un ticket rebondit entre les équipes sans résolution. Cela indique souvent des responsabilités peu claires ou une gestion des connaissances inadéquate au sein de l'organisation.

Pourquoi c'est important

Il permet l'analyse organisationnelle et la détection des goulots d'étranglement au niveau de l'équipe.

Où obtenir

PBM:Problem Investigation form, field 'Assigned Group'

Exemples
Centre de services de niveau 1Support back-officeAdministration réseau
Nombre d'incidents associés
RelatedIncidentCount
Le nombre d'incidents liés à cet enregistrement de problème.
Description

Cet attribut quantifie l'impact du problème en comptant le nombre d'incidents qui lui sont associés. Dans BMC Helix, il s'agit généralement d'un décompte d'enregistrements dans le formulaire HPD:Help Desk qui sont liés à l'enregistrement PBM.

Cet attribut alimente le KPI « Incident Linkage Density ». Un nombre élevé indique un problème à fort impact qui génère un bruit significatif pour le service d'assistance. La corrélation avec la « Priority » garantit que les problèmes à volume élevé sont réellement traités comme critiques.

Il aide également à prioriser l'arriéré. Un enregistrement de problème avec 500 incidents liés devrait probablement être priorisé par rapport à un problème « Critical » avec seulement 1 incident lié, car la résolution du premier libérera plus de capacité du service d'assistance.

Pourquoi c'est important

Il quantifie l'impact opérationnel et la gêne utilisateur associés au problème.

Où obtenir

Calculé en comptant les lignes associées dans HPD:Associations ou HPD:Help Desk

Exemples
15120
Priorité
Priority
La priorité calculée du problème basée sur l'impact et l'urgence.
Description

Cet attribut indique le niveau de priorité de l'enregistrement de problème (par exemple, « Critical », « High », « Medium », « Low »). Dans BMC Helix, il s'agit généralement d'un champ calculé dérivé des sélections d'Impact et d'Urgence.

En analyse, il est utilisé pour le dashboard « Throughput and Priority Volume ». Il permet aux organisations de vérifier si les ressources sont correctement alignées avec les besoins métier. Par exemple, les problèmes « Critical » devraient théoriquement avoir des temps d'attribution initiaux plus rapides et des temps de cycle globaux plus courts que ceux de priorité « Low ».

Le filtrage par priorité aide à cibler les efforts d'amélioration. Un goulot d'étranglement dans un processus de priorité « Low » pourrait être acceptable, mais le même délai dans un processus « Critical » représente un risque significatif pour la continuité de l'activité et la conformité SLA.

Pourquoi c'est important

Il segmente l'analyse par criticité métier et supporte l'analyse des SLA.

Où obtenir

PBM:Problem Investigation form, field 'Priority'

Exemples
CritiqueÉlevéMoyenFaible
SLA est enfreint
IsSLABreached
Un indicateur signalant si la résolution du problème a dépassé le délai autorisé.
Description

Cet attribut booléen indique si l'enregistrement de problème a enfreint son accord de niveau de service. Il est calculé en comparant l'horodatage « Resolution Verified » à la « SLA Due Date » ou extrait directement du statut SLM.

Cet attribut est essentiel pour le dashboard « SLA Compliance and Breach Trends ». Il permet une segmentation binaire simple du processus : conforme ou non conforme. Cela facilite l'isolation des caractéristiques des processus défaillants (par exemple, « Les cas non conformes impliquent-ils toujours le Groupe de Support X ? »).

Il sert de filtre principal pour l'analyse des causes profondes des échecs de processus. Les analystes peuvent filtrer les cas où « IsSLABreached = True » et ensuite examiner la carte des processus pour voir où le temps a été perdu (par exemple, de longs temps d'attente pour l'approbation du fournisseur).

Pourquoi c'est important

Il simplifie les rapports de conformité et l'analyse des défaillances.

Où obtenir

SLM : Formulaire de mesure ou calculé

Exemples
truefaux
ID de demande de changement associée
RelatedChangeRequestId
L'identifiant de la demande de changement initiée pour corriger le problème.
Description

Cet attribut contient l'ID de la demande de changement (par exemple, CRQ0000...) liée à l'enregistrement de problème. Il représente la transition de l'enquête à l'implémentation d'une correction permanente.

Cet attribut est nécessaire pour le KPI « Délai de transition de la cause profonde au changement ». Il permet à l'outil de Process Mining de mesurer le délai entre la découverte de la cause profonde et le démarrage du processus de changement. C'est un point de transfert courant où l'élan est perdu.

Il aide également à vérifier la « complétude du processus ». Un enregistrement de problème clôturé avec un statut « Completed » mais sans demande de changement associée (ou une solution de contournement) pourrait indiquer une violation de processus où la cause profonde a été trouvée mais jamais réellement corrigée.

Pourquoi c'est important

Il relie le processus de gestion des problèmes au processus de gestion des changements.

Où obtenir

PBM:Associations d'investigation ou onglet Relations

Exemples
CRQ00000021345CRQ00000021346
Nombre de Réaffectations
ReassignmentCount
Le nombre total de fois où le groupe de support a été modifié.
Description

Cet attribut compte le nombre de fois où l'activité « Assigned to Support Group » se produit pour un seul cas. C'est une mesure directe de la friction du processus et de l'efficacité du routage.

Cet attribut alimente le graphique « Support Group Reassignment Analysis ». Des valeurs élevées (allers-retours) indiquent que le triage initial échoue ou qu'il n'y a pas de propriété claire pour les problèmes complexes. C'est un indicateur précurseur d'un temps de cycle accru.

Les managers l'utilisent pour identifier les opportunités de formation. Si le Service Desk réaffecte systématiquement les problèmes « Database » à « Network » en premier, puis que « Network » les renvoie à « Database », le Reassignment Count montera en flèche, soulignant la nécessité de meilleurs scripts de diagnostic initial.

Pourquoi c'est important

Il identifie le gaspillage, les frictions et le manque de responsabilité dans le processus.

Où obtenir

Calculé à partir de l'historique des activités

Exemples
015
Région
Region
La région géographique associée au problème.
Description

Cet attribut spécifie l'emplacement géographique (par exemple, « North America », « EMEA ») où le problème est survenu ou est géré. Dans BMC Helix, on le trouve souvent dans les champs « Region » ou « Site » associés au demandeur ou à l'actif affecté.

En analyse, cela prend en charge la segmentation géographique. Cela aide à identifier si des régions spécifiques connaissent des volumes de problèmes plus élevés ou des temps de résolution plus lents. Cela peut mettre en évidence des disparités dans la dotation en personnel de support ou la qualité de l'infrastructure entre différents emplacements.

C'est précieux pour les organisations mondiales afin d'assurer une prestation de services cohérente. Si le « Investigation Cycle Time » en « APAC » est le double de celui en « NAM », cela déclenche une enquête sur l'allocation des ressources ou l'adhésion aux processus dans cette région.

Pourquoi c'est important

Il permet la comparaison géographique des performances des processus.

Où obtenir

PBM:Problem Investigation form, 'Region' field

Exemples
AmériquesEMEAAPAC
Statut de la solution de contournement
WorkaroundStatus
Indique si une solution de contournement valide a été identifiée et publiée.
Description

Cet attribut suit l'état de la solution temporaire (Workaround). Il peut s'agir d'un simple booléen (Has Workaround) ou d'une chaîne de statut. Dans BMC Helix, cela est souvent dérivé de la présence de texte dans le champ « Workaround » ou d'un indicateur de statut spécifique.

Cet attribut est essentiel pour le dashboard « Workaround Publication Performance ». Il répond à la question de l'efficacité avec laquelle l'équipe atténue l'impact tout en recherchant la cause profonde. Une vue de processus filtrée par « No Workaround » met en évidence les cas où l'entreprise subit un impact total pendant l'enquête.

Il prend également en charge les audits qualité. Clôturer un enregistrement de problème sans correction permanente (Change Request) ET sans solution de contournement (workaround) est généralement une défaillance de processus qui nécessite un examen.

Pourquoi c'est important

Il mesure l'efficacité de l'atténuation de l'impact pendant l'investigation.

Où obtenir

PBM : Formulaire d'investigation de problème, vérification du contenu du champ « Solution de contournement »

Exemples
ActifAucunRetiré
Temps de cycle d'investigation
InvestigationCycleTime
La durée entre le début de l'enquête et l'identification de la cause profonde.
Description

Il s'agit d'un attribut de durée calculée mesurant le temps entre l'activité « Investigation Commenced » et l'activité « Root Cause Identified ». Il représente le temps à valeur ajoutée essentiel du processus de gestion des problèmes.

Cette métrique alimente le dashboard « Root Cause Investigation Cycle Time ». Elle aide les managers à comprendre la complexité technique des problèmes et l'efficacité des équipes d'enquête. Les anomalies ici (par exemple, des temps extrêmement courts) pourraient indiquer des suppositions, tandis que des temps extrêmement longs indiquent des enquêtes bloquées.

En comparant cette métrique entre les « Support Groups » et les « Priorities », l'organisation peut identifier quelles équipes ont besoin de meilleurs outils, de formation ou de support fournisseur pour diagnostiquer les problèmes plus rapidement.

Pourquoi c'est important

C'est la principale métrique d'efficacité pour la phase d'investigation technique.

Où obtenir

Calculé à partir des horodatages des activités

Exemples
4500000120000
Obligatoire Recommandé Facultatif

Activités de gestion des problèmes

Ce sont les étapes fondamentales du processus et les changements de statut que vous devriez suivre pour obtenir une visibilité complète sur vos phases d'enquête et de résolution.
9 Recommandé 4 Facultatif
Activité Description
Affecté au Groupe de Support
L'attribution de l'enregistrement de problème à une équipe technique spécifique. Capturée par le suivi des changements dans le champ « Assigned Group ».
Pourquoi c'est important

Essentiel pour mesurer les transferts, les effets de ping-pong et le KPI 'Temps moyen d'affectation initiale'.

Où obtenir

Formulaire PBM:Problem Investigation, historique du champ 'Groupe assigné' ou journal d'audit.

Capture

Comparer le champ 'Groupe assigné' avant et après la mise à jour

Type d'événement inferred
Cause profonde identifiée
Le moment où l'enregistrement de problème passe à un état indiquant que la cause est connue. Déduit lorsque le statut passe à « Root Cause Identified ».
Pourquoi c'est important

Un jalon critique pour le tableau de bord 'Temps de cycle d'investigation des causes profondes'. Il signale le passage de l'analyse à la résolution.

Où obtenir

PBM:Problem Investigation form, 'Status' field = 'Root Cause Identified'.

Capture

Comparer le champ de statut pour la transition à Cause profonde identifiée

Type d'événement inferred
Demande de changement initiée
La liaison d'une demande de changement d'infrastructure à l'enquête sur le problème. Cela signale le début de la phase d'implémentation.
Pourquoi c'est important

Critique pour l'indicateur clé de performance 'Délai entre la cause profonde et le changement' et pour l'identification des silos entre les processus de gestion des problèmes et des changements.

Où obtenir

Table PBM:Investigation_Associations ou renseignement du champ 'ID de changement d'infrastructure'.

Capture

Journalisé lors de la création de l'association dans PBM:Investigation_Associations

Type d'événement explicit
Enregistrement de problème annulé
La résiliation d'un enregistrement de problème avant résolution. Capturée lorsque le statut devient « Cancelled » ou « Rejected ».
Pourquoi c'est important

Identifie les efforts gaspillés ou les doublons valides. Représente un point d'arrivée alternatif.

Où obtenir

PBM:Problem Investigation form, 'Status' field = 'Cancelled' or 'Rejected'.

Capture

Comparer le champ de statut pour la transition à Annulé

Type d'événement inferred
Enregistrement de problème clôturé
La clôture administrative finale de l'enregistrement de problème. Cet événement met fin à l'instance de processus.
Pourquoi c'est important

L'événement de fin standard. Nécessaire pour l'analyse complète du temps de cycle et le calcul de la « Densité de liaison des incidents ».

Où obtenir

PBM:Problem Investigation form, 'Status' field = 'Closed'.

Capture

Comparer le champ de statut pour la transition à Fermé

Type d'événement inferred
Enregistrement de problème journalisé
La création initiale d'un enregistrement d'enquête de problème dans le système. Cet événement est explicitement capturé lorsqu'une nouvelle entrée est enregistrée dans le formulaire PBM:Problem Investigation.
Pourquoi c'est important

Marque le début de l'instance de processus. Critique pour le calcul des temps de cycle globaux et des métriques de réponse initiales.

Où obtenir

PBM : Formulaire d'investigation de problème, horodatage « Date de soumission » ou journal de création avec « Statut » = « Brouillon »

Capture

Journalisé lors de la création de l'enregistrement PBM:Problem Investigation

Type d'événement explicit
Investigation commencée
La transition de l'enregistrement de problème vers une phase d'analyse active. Ceci est déduit lorsque le champ Statut passe à « Under Investigation ».
Pourquoi c'est important

Marque le début de la phase de travail réelle, supportant le KPI 'Temps de cycle d'investigation'.

Où obtenir

PBM:Problem Investigation form, 'Status' field = 'Under Investigation'.

Capture

Comparer le champ de statut pour la transition à En cours d'investigation

Type d'événement inferred
Résolution vérifiée
Le point où la correction permanente est confirmée comme réussie. Déduit du changement de statut à « Solution Implemented » ou « Completed ».
Pourquoi c'est important

Utilisé pour le « Taux d'adhésion aux SLA de problèmes ». Confirme que le travail technique est terminé.

Où obtenir

PBM:Problem Investigation form, 'Status' field = 'Solution Implemented' or 'Completed'.

Capture

Comparer le champ de statut pour la transition à Solution implémentée

Type d'événement inferred
Solution de contournement définie
La saisie ou la mise à jour de texte dans le champ « Workaround » de l'enregistrement de problème. Cet événement indique qu'une solution temporaire a été documentée.
Pourquoi c'est important

Soutient le KPI « Délai de publication de la solution de contournement ». Indique l'atténuation de l'impact des incidents.

Où obtenir

PBM:Problem Investigation form, changes to the 'Workaround' text field.

Capture

Comparer le contenu du champ 'Solution de contournement' pour les mises à jour non nulles

Type d'événement inferred
Base de données de solutions mise à jour
La transition de l'enregistrement vers le statut « Solution Database », indiquant qu'une correction permanente a été proposée ou identifiée.
Pourquoi c'est important

Suit la progression de la définition de la solution avant l'implémentation.

Où obtenir

PBM:Problem Investigation form, 'Status' field = 'Solution Database'.

Capture

Comparer le champ de statut pour la transition à Base de données de solutions

Type d'événement inferred
Coordinateur réaffecté
Un changement de coordinateur de problème individuel au sein d'un groupe de support. Capturé en surveillant le champ 'Coordinateur de problème'.
Pourquoi c'est important

Aide à analyser la répartition de la charge de travail et les goulots d'étranglement individuels des ressources.

Où obtenir

Formulaire PBM:Problem Investigation, historique du champ 'Coordinateur de problème'.

Capture

Comparer le champ 'Coordinateur de problème' avant et après la mise à jour

Type d'événement inferred
Erreur connue promue
La création d'un enregistrement d'erreur connue lié à l'enquête sur le problème. Il s'agit d'un événement de création d'enregistrement associé.
Pourquoi c'est important

Indique la formalisation du problème pour une communication plus large et un suivi à long terme.

Où obtenir

Création d'un enregistrement dans PBM:Known Error lié à l'ID PBM:Problem Investigation.

Capture

Journalisé lors de la création de l'enregistrement PBM:Known Error

Type d'événement explicit
Revue Post-Implémentation effectuée
L'achèvement de la phase PIR. Capturé par une transition de statut hors d'un état PIR ou la clôture d'une tâche PIR liée.
Pourquoi c'est important

Soutient directement la 'Conformité aux revues post-implémentation' et les audits de qualité des processus.

Où obtenir

PBM : Formulaire d'investigation de problème, indicateur spécifique « PIR requis » ou achèvement de la tâche liée de type « PIR »

Capture

Dérivé de l'achèvement du statut PIR ou de la clôture de la tâche PIR

Type d'événement inferred
Recommandé Facultatif

Guides d'extraction

Comment extraire vos données de gestion des problèmes de BMC Helix ITSM