Votre template de données pour la gestion des problèmes
Votre template de données pour la gestion des problèmes
- 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
Attributs de gestion des problèmes
| 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
|
|||
Activités de gestion des problèmes
| 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
|
|||