Votre modèle de données pour la gestion des problèmes
Votre modèle de données pour la gestion des problèmes
- Champs de données essentiels à l’analyse des causes racines
- Jalons de processus standardisés pour le suivi
- Instructions d’extraction spécifiques à BMC Helix ITSM
Attributs de la gestion des problèmes
| Nom | Description | ||
|---|---|---|---|
|
Activité
Activity
|
Tâche précise ou événement de changement de statut qui s’est produit. | ||
|
Description
Cet attribut représente l’étape précise réalisée dans le cycle de vie de la Gestion des problèmes, par exemple « Problem Record Logged », « Root Cause Identified » ou « Solution Database Updated ». Dans BMC Helix, ces valeurs sont souvent dérivées de l’historique des statuts, des journaux d’audit ou des horodatages de transactions spécifiques du module Problem Investigation. Cet attribut est au cœur de la découverte des processus. En analysant la séquence de ces activités, l’outil de Process Mining construit la cartographie du processus et révèle le déroulement réel du travail par rapport au processus conçu. Il met en évidence les boucles, les reprises et les écarts par rapport aux procédures opérationnelles standard. Des noms d’activités précis sont essentiels pour comprendre ce qui s’est réellement passé au cours du cycle de vie. Ces données permettent de mesurer les délais de transition entre des étapes précises, par exemple le temps écoulé entre l’identification d’une cause racine et l’initiation d’une demande de changement.
Pourquoi c’est important
Il définit les nœuds de la carte du processus et permet de visualiser le flux de travail.
Où les obtenir
Dérivé de l’historique des statuts PBM:Problem Investigation ou de PBM:AuditLogSystem
Exemples
Enregistrement du Problem RecordAffectation à un groupe de supportInvestigation commencéeCause racine identifiée
|
|||
|
Enregistrement du problème
ProblemRecord
|
Identifiant unique du dossier d’investigation du problème. | ||
|
Description
Cet attribut constitue l’identifiant central du dossier 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) présent dans le formulaire PBM:Problem Investigation. Il relie toutes les activités associées, de l’enregistrement initial du problème à sa clôture finale et à la revue post-mise en œuvre. Dans l’analyse Process Mining, cet attribut sert à regrouper les événements individuels au sein d’une même instance de processus. Il permet aux analystes de visualiser le parcours complet d’une investigation donnée. Sans cet identifiant, il serait impossible de mettre en relation la séquence d’actions réalisées par différents groupes de support et coordinateurs. Ce champ joue le rôle de clé primaire du journal d’événements. Il est indispensable pour toutes les agrégations au niveau du dossier, notamment le calcul de la durée totale du cycle par problème ou le décompte des problèmes par niveau de priorité.
Pourquoi c’est important
Il s’agit de la clé fondamentale nécessaire pour construire la vue du processus et suivre le cycle de vie de problèmes précis.
Où les obtenir
Formulaire PBM:Problem Investigation, champ « Problem ID »
Exemples
PBI00000004512PBI00000004513PBI00000004514
|
|||
|
Heure de l’événement
EventTime
|
Horodatage auquel l’activité précise s’est produite. | ||
|
Description
Cet attribut enregistre la date et l’heure exactes auxquelles une activité a eu lieu. Dans BMC Helix ITSM, il correspond à des champs tels que « Submit Date », « Last Modified Date » ou aux horodatages spécifiques enregistrés dans les tables d’historique lors des changements de statut. Dans l’analyse, cet attribut sert à ordonner les événements chronologiquement et à calculer les durées. Il permet de mesurer les durées de cycle entre deux points quelconques du processus, comme « Investigation Cycle Time » ou « Workaround Publication Lead Time ». Des horodatages précis sont indispensables pour identifier les goulots d’étranglement. En calculant l’écart entre des événements consécutifs, les analystes peuvent localiser précisément les retards, qu’ils surviennent lors de l’affectation initiale ou de la phase de revue finale.
Pourquoi c’est important
Il permet de calculer tous les KPI fondés sur la durée et d’ordonner les événements.
Où les 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
|
Horodatage auquel les données ont été extraites ou actualisées pour la dernière fois. | ||
|
Description
Cet attribut indique la date du dernier chargement des données dans l’application de Process Mining. Il permet aux analystes de connaître l’actualité des données consultées. Il est généralement généré par le script d’extraction ou l’outil de pipeline de données. Dans l’analyse, il contribue à éviter les décisions fondées sur des données obsolètes. Par exemple, pour un responsable qui 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 modifie considérablement l’interprétation de la charge actuelle. Il est également utilisé pour les chargements incrémentiels. En suivant l’heure de la dernière mise à jour, le processus ETL peut récupérer uniquement les enregistrements modifiés depuis l’extraction précédente, ce qui améliore les performances et réduit la charge du système.
Pourquoi c’est important
Il garantit l’actualité des données et contribue aux stratégies de chargement incrémentiel.
Où les obtenir
Heure système au moment de l’extraction
Exemples
2023-11-01T00:00:00Z2023-11-01T12:00:00Z
|
|||
|
Système source
SourceSystem
|
Système d’origine des données. | ||
|
Description
Cet attribut identifie le système logiciel depuis lequel les données de processus ont été extraites, en l’occurrence « BMC Helix ITSM ». Il est particulièrement important dans les environnements multisystèmes où le Process Mining peut agréger des données provenant de différents outils ITSM, de développement ou de fournisseurs externes. Dans l’analyse, ce champ sert de métadonnée permettant de valider l’origine de l’enregistrement. Si la vue Process Mining combine des données de BMC Helix pour la Gestion des problèmes et celles d’un autre système de développement logiciel, par exemple Jira, cet attribut aide à segmenter l’analyse selon l’outil d’origine. Il facilite également le diagnostic technique. En cas de problème de qualité des données, la connaissance du système source permet aux ingénieurs de données de remonter jusqu’à la routine d’extraction ou à la base de données concernée.
Pourquoi c’est important
Il assure la traçabilité et fournit le contexte nécessaire, notamment dans les vues de processus multisystèmes.
Où les obtenir
Renseigné en dur lors de l’extraction
Exemples
BMC Helix ITSMRemedy OnDemandBMC ITSM Production
|
|||
|
Catégorie de cause racine
RootCauseCategory
|
Classification de la cause sous-jacente du problème. | ||
|
Description
Cet attribut contient la catégorie sélectionnée lors de l’identification de la cause racine, par exemple « Software Error », « Hardware Failure » ou « Process Gap ». Dans BMC Helix, elle est généralement sélectionnée dans les menus « Root Cause » ou « Generic Categorization ». Cet attribut est essentiel pour la vue « Fix Effectiveness and Quality ». Il permet à l’organisation de mettre en relation certains types de causes racines avec les taux de reprise ou les longues durées d’investigation. Il peut par exemple révéler que les problèmes « Software Error » prennent systématiquement deux fois plus de temps à résoudre que les problèmes « Hardware Failure ». Il sert également à calculer le « Root Cause Categorization Rate ». Un pourcentage élevé de valeurs « Unknown » ou « Other » dans ce champ peut indiquer un besoin de formation technique supplémentaire ou d’options de catégorisation plus précises.
Pourquoi c’est important
Il permet d’analyser les tendances des problèmes systémiques et contribue à une Gestion des problèmes proactive.
Où les obtenir
Formulaire PBM:Problem Investigation, champs des onglets « Root Cause » ou de catégorisation
Exemples
Module logicielInfrastructure réseauErreur humaine
|
|||
|
CI de service
ServiceCI
|
Service métier principal ou élément de configuration concerné. | ||
|
Description
Cet attribut identifie le Service Configuration Item (CI) associé au problème, par exemple « Email Service », « SAP ERP » ou « Wi-Fi Network ». Dans BMC Helix, il correspond souvent au champ « Service+ » ou à la relation avec le CI principal. Dans l’analyse, il permet de segmenter les enregistrements de problèmes par produit ou par service. Il aide les responsables informatiques à comprendre quels services sont les plus fragiles et génèrent le plus d’investigations. Il alimente le Dashboard « Throughput and Priority Volume » en ajoutant une dimension produit. La mise en relation de cet attribut avec « Investigation Cycle Time » peut montrer si certains services complexes, comme un système bancaire central, nécessitent intrinsèquement des investigations plus longues que des services courants, comme l’impression.
Pourquoi c’est important
Il relie la performance du processus à des produits ou services métier précis.
Où les obtenir
Formulaire PBM:Problem Investigation, champ « ServiceCI » ou « CI Name »
Exemples
Service de messagerieSystème de paieVPN d'entreprise
|
|||
|
Coordinateur des problèmes
ProblemCoordinator
|
Utilisateur chargé de coordonner l’investigation. | ||
|
Description
Cet attribut désigne la personne responsable de l’enregistrement du problème. Dans BMC Helix ITSM, il correspond au champ « Problem Coordinator ». Cette personne assure le suivi du cycle de vie du problème, même si certaines tâches sont déléguées à d’autres intervenants. Cet attribut contribue au Dashboard « Support Group Workload Distribution ». Il aide les responsables à déterminer si certaines personnes sont surchargées d’investigations tandis que d’autres disposent de capacités disponibles. Il permet également d’analyser les performances individuelles et d’identifier les besoins de formation ou les collaborateurs les plus performants. Dans le Process Mining, ce champ constitue un attribut de ressource. Il permet de visualiser la circulation du travail entre les personnes et peut mettre en évidence des points uniques de défaillance lorsqu’un processus dépend trop fortement d’un expert donné.
Pourquoi c’est important
Il permet d’analyser les ressources et d’équilibrer la charge de travail au niveau individuel.
Où les obtenir
Formulaire PBM:Problem Investigation, champ « Problem Coordinator »
Exemples
John DoeJane SmithAdministrateur système
|
|||
|
Date d’échéance du SLA
SLADueDate
|
Date et heure cibles auxquelles le problème doit être résolu. | ||
|
Description
Cet attribut contient l’échéance de résolution du problème, définie par l’accord de niveau de service. Dans BMC Helix, il correspond souvent au champ « Target Resolution Date » ou à l’horodatage calculé d’un jalon SLA. Cet attribut sert de référence au Dashboard « SLA Compliance and Breach Trends ». En comparant cet horodatage à celui de l’activité « Resolution Verified », le système détermine si le SLA a été respecté ou dépassé. La visualisation de cette date permet aux analystes de voir avec quelle marge l’équipe résout les problèmes. Les résout-elle plusieurs jours à l’avance ou termine-t-elle systématiquement quelques minutes avant le dépassement ? Cette analyse contribue à la planification des capacités.
Pourquoi c’est important
Il constitue la référence pour calculer tous les indicateurs de conformité et de respect des délais.
Où les obtenir
Formulaire PBM:Problem Investigation, champ « Target Resolution Date »
Exemples
2023-12-01T17:00:00Z2023-12-02T09:00:00Z
|
|||
|
Groupe de support
SupportGroup
|
Équipe technique actuellement chargée de l’investigation du problème. | ||
|
Description
Cet attribut représente le groupe de support précis, par exemple « Server Admin » ou « Database Support », responsable de l’enregistrement du problème au moment de l’événement. Dans BMC Helix, il correspond au 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 cartographie du processus par équipe, afin d’identifier les groupes qui traitent le plus grand volume et ceux qui constituent des goulots d’étranglement dans le processus d’investigation. L’analyse des transferts entre groupes de support permet d’identifier les comportements d’allers-retours, lorsqu’un ticket passe d’une équipe à l’autre sans être résolu. Cela révèle souvent des responsabilités mal définies ou une gestion des connaissances insuffisante au sein de l’organisation.
Pourquoi c’est important
Il permet d’analyser l’organisation et de détecter les goulots d’étranglement au niveau des équipes.
Où les obtenir
Formulaire PBM:Problem Investigation, champ « Assigned Group »
Exemples
Centre de services, niveau 1Support du back-officeAdministration réseau
|
|||
|
Motif de l’investigation
InvestigationDriver
|
Raison pour laquelle l’investigation du problème a été initiée. | ||
|
Description
Cet attribut classe le déclencheur de l’enregistrement du problème, par exemple « Incident Volume », « Major Incident », « Vendor Notification » ou « Proactive Trend Analysis ». Dans BMC Helix, il correspond au champ « Investigation Driver ». Cet attribut contribue au Dashboard « Proactive Identification Trends ». Il permet à l’organisation de mesurer le passage d’une gestion réactive des incidents à une Gestion des problèmes proactive, qui consiste à identifier les risques avant leur manifestation. L’analyse des flux de processus selon le « Investigation Driver » peut révéler des comportements différents. Par exemple, les problèmes « Proactive » peuvent rester plus longtemps dans la file d’attente parce qu’ils ne provoquent pas d’interruption immédiate, tandis que les problèmes déclenchés par un « Major Incident » sont traités en priorité.
Pourquoi c’est important
Il distingue le travail réactif du travail proactif, un indicateur important de maturité.
Où les obtenir
Formulaire PBM:Problem Investigation, champ « Investigation Driver »
Exemples
RéactifProactifIncidents récurrents
|
|||
|
Nombre d’incidents associés
RelatedIncidentCount
|
Nombre d’incidents associé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 du nombre d’enregistrements du formulaire HPD:Help Desk 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 une charge importante pour le service desk. Sa mise en relation avec la « Priority » permet de vérifier que les problèmes à fort volume sont effectivement traités comme des problèmes critiques. Il contribue également à hiérarchiser le backlog. Un Problem Record associé à 500 incidents devrait probablement être priorisé par rapport à un problème « Critical » associé à un seul incident, car sa résolution libérerait davantage de capacité au service desk.
Pourquoi c’est important
Il quantifie l’impact opérationnel et les difficultés rencontrées par les utilisateurs en lien avec le problème.
Où les obtenir
Calculé en comptant les lignes associées dans HPD:Associations ou HPD:Help Desk
Exemples
15120
|
|||
|
Priorité
Priority
|
Priorité calculée du problème en fonction de son impact et de son urgence. | ||
|
Description
Cet attribut indique le niveau de priorité de l’enregistrement du problème, par exemple Critical, High, Medium ou Low. Dans BMC Helix, il s’agit généralement d’un champ calculé à partir des sélections Impact et Urgency. Dans l’analyse, il est utilisé pour le Dashboard « Throughput and Priority Volume ». Il permet aux organisations de vérifier que les ressources sont correctement alignées sur les besoins de l’entreprise. En théorie, les problèmes Critical devraient être affectés plus rapidement et présenter une durée globale de cycle plus courte que les problèmes de priorité Low. Le filtrage par priorité aide à cibler les efforts d’amélioration. Un goulot d’étranglement dans un processus de priorité Low peut être acceptable, mais le même délai dans un processus Critical représente un risque important pour la continuité d’activité et le respect des SLA.
Pourquoi c’est important
Il segmente l’analyse selon la criticité métier et contribue à l’analyse des SLA.
Où les obtenir
Formulaire PBM:Problem Investigation, champ « Priority »
Exemples
CritiqueÉlevéeMoyenneFaible
|
|||
|
SLA non respecté
IsSLABreached
|
Indicateur précisant si la résolution du problème a dépassé le délai autorisé. | ||
|
Description
Cet attribut booléen indique si l’enregistrement du problème n’a pas respecté 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 au Dashboard « SLA Compliance and Breach Trends ». Il permet de segmenter simplement le processus en deux catégories : conforme et non conforme. Il devient ainsi facile d’isoler les caractéristiques des processus en échec, par exemple : « Les cas en infraction impliquent-ils toujours le Support Group X ? » Il sert de filtre principal pour l’analyse des causes racines des échecs du processus. Les analystes peuvent filtrer sur « IsSLABreached = True », puis examiner la cartographie du processus afin de déterminer où le temps a été perdu, par exemple lors de longues attentes liées à l’approbation d’un fournisseur.
Pourquoi c’est important
Simplifie les rapports de Conformité et l’analyse des échecs.
Où les obtenir
Formulaire SLM:Measurement ou calculé
Exemples
truefalse
|
|||
|
Durée du cycle d’investigation
InvestigationCycleTime
|
Durée entre le début de l’investigation et l’identification de la cause racine. | ||
|
Description
Il s’agit d’un attribut de durée calculé qui mesure le temps écoulé entre l’activité « Investigation Commenced » et l’activité « Root Cause Identified ». Il représente le temps consacré à la création de valeur au cœur du processus de Gestion des problèmes. Cette mesure alimente le Dashboard « Root Cause Investigation Cycle Time ». Elle aide les responsables à comprendre la complexité technique des problèmes et l’efficacité des équipes d’investigation. Des anomalies, par exemple des durées extrêmement courtes, peuvent indiquer une simple supposition, tandis que des durées très longues signalent une investigation bloquée. En comparant cette mesure entre les « Support Groups » et les « Priorities », l’organisation peut identifier les équipes qui ont besoin de meilleurs outils, d’une formation complémentaire ou du soutien d’un fournisseur pour diagnostiquer les problèmes plus rapidement.
Pourquoi c’est important
Il s’agit de la principale mesure d’efficacité de la phase d’investigation technique.
Où les obtenir
Calculé à partir des horodatages des activités
Exemples
4500000120000
|
|||
|
Identifiant de la demande de changement associée
RelatedChangeRequestId
|
Identifiant de la demande de changement initiée pour corriger le problème. | ||
|
Description
Cet attribut contient l’identifiant de la Change Request, par exemple CRQ0000..., associée à l’enregistrement du problème. Il représente le passage de l’investigation à la mise en œuvre d’une correction définitive. Cet attribut est nécessaire au KPI « Root Cause to Change Lead Time ». Il permet à l’outil de Process Mining de mesurer le délai entre l’identification de la cause racine et le début du processus de changement. Il s’agit d’un point de transfert courant où la dynamique peut se perdre. Il aide également à vérifier la « process completeness ». Un Problem Record clôturé avec le statut « Completed », mais sans demande de changement associée ni solution de contournement, peut indiquer une violation du processus : la cause racine a été identifiée, mais n’a jamais été réellement corrigée.
Pourquoi c’est important
Il relie le processus de Gestion des problèmes au processus de Gestion du changement.
Où les obtenir
PBM:Investigation Associations ou onglet Relationship
Exemples
CRQ00000021345CRQ00000021346
|
|||
|
Nombre de réaffectations
ReassignmentCount
|
Nombre total de changements de groupe de support. | ||
|
Description
Cet attribut compte le nombre d’occurrences de l’activité « Assigned to Support Group » pour un même cas. Il mesure directement les frictions du processus et l’efficacité du routage. Cet attribut alimente le graphique « Support Group Reassignment Analysis ». Des valeurs élevées, correspondant à des transferts successifs entre équipes, indiquent que le triage initial échoue ou qu’aucune équipe n’est clairement responsable des problèmes complexes. Il constitue un indicateur précoce d’une augmentation de la durée du cycle. Les responsables l’utilisent pour identifier les besoins de formation. Si le Service Desk réaffecte systématiquement les problèmes « Database » à « Network », puis que « Network » les renvoie à « Database », le nombre de réaffectations augmente fortement, ce qui met en évidence la nécessité d’améliorer les scripts de diagnostic initial.
Pourquoi c’est important
Identifie les gaspillages, les frictions et l’absence de responsabilité dans le processus.
Où les obtenir
Calculé à partir de l’historique des activités
Exemples
015
|
|||
|
Région
Region
|
Région géographique associée au problème. | ||
|
Description
Cet attribut précise la zone géographique, par exemple « North America » ou « EMEA », où le problème est apparu ou est pris en charge. Dans BMC Helix, il se trouve souvent dans les champs « Region » ou « Site » associés au demandeur ou à l’actif concerné. Dans l’analyse, il permet une segmentation géographique. Il aide à déterminer si certaines régions connaissent un volume de problèmes plus élevé ou des délais de résolution plus longs. Il peut mettre en évidence des écarts de dotation en personnel de support ou de qualité d’infrastructure entre différents sites. Il est particulièrement utile aux organisations internationales qui souhaitent garantir une prestation de services homogène. Si l’« Investigation Cycle Time » dans « APAC » est deux fois supérieur à celui de « NAM », cela peut conduire à examiner l’allocation des ressources ou le respect du processus dans cette région.
Pourquoi c’est important
Il permet de comparer géographiquement la performance des processus.
Où les obtenir
Formulaire PBM:Problem Investigation, champ « Region »
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’une simple valeur booléenne (Has Workaround) ou d’une chaîne indiquant un statut. Dans BMC Helix, il est souvent déduit de la présence de texte dans le champ « Workaround » ou d’un indicateur de statut spécifique. Cet attribut est essentiel au Dashboard « Workaround Publication Performance ». Il permet d’évaluer l’efficacité avec laquelle l’équipe atténue l’impact tout en recherchant la cause racine. Une vue du processus filtrée sur « No Workaround » met en évidence les cas dans lesquels l’activité est fortement perturbée pendant l’investigation. Il contribue également aux audits qualité. Clôturer un enregistrement de problème sans correctif permanent (Change Request) ET sans solution de contournement constitue généralement un échec du processus qui doit faire l’objet d’un examen.
Pourquoi c’est important
Mesure l’efficacité de l’atténuation de l’impact pendant l’investigation.
Où les obtenir
Formulaire PBM:Problem Investigation, vérification du contenu du champ « Workaround »
Exemples
ActifAucunRetiré
|
|||
Activités de gestion des problèmes
| Activité | Description | ||
|---|---|---|---|
|
Affectation à un groupe de support
|
Affectation de l’enregistrement du problème à une équipe technique précise. Cet événement est capturé en surveillant les modifications du champ « Assigned Group ». | ||
|
Pourquoi c’est important
Essentiel pour mesurer les transferts, les effets d’allers-retours et le KPI « Mean Time to Initial Assignment ».
Où les obtenir
Formulaire PBM:Problem Investigation, historique du champ « Assigned Group » ou journal d’audit.
Collecte
Comparer la valeur du champ « Assigned Group » avant et après la mise à jour
Type d’événement
inferred
|
|||
|
Cause racine identifiée
|
Moment où l’enregistrement du problème passe à un état indiquant que la cause est connue. Cet événement est déduit lorsque le Status passe à « Root Cause Identified ». | ||
|
Pourquoi c’est important
Jalon essentiel du Dashboard « Root Cause Investigation Cycle Time ». Il marque le passage de l’analyse à la définition de la solution.
Où les obtenir
Formulaire PBM:Problem Investigation, champ « Status » = « Root Cause Identified ».
Collecte
Comparer le champ Status pour détecter le passage à Root Cause Identified
Type d’événement
inferred
|
|||
|
Demande de changement initiée
|
Association d’une Infrastructure Change Request à l’investigation du problème. Cet événement marque le début de la phase de mise en œuvre. | ||
|
Pourquoi c’est important
Essentiel pour le KPI « Root Cause to Change Lead Time » et l’identification des silos entre les processus Problem et Change.
Où les obtenir
Table PBM:Investigation_Associations ou renseignement du champ « Infrastructure Change ID ».
Collecte
Enregistré lors de la création de l’association dans PBM:Investigation_Associations
Type d’événement
explicit
|
|||
|
Enregistrement du Problem Record
|
Création initiale d’un enregistrement Problem Investigation 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. Cet événement est essentiel pour calculer les durées globales de cycle et les indicateurs de réponse initiale.
Où les obtenir
Formulaire PBM:Problem Investigation, horodatage « Submit Date » ou journal de création avec « Status » = « Draft ».
Collecte
Enregistré lors de la création de l’enregistrement PBM:Problem Investigation
Type d’événement
explicit
|
|||
|
Investigation commencée
|
Passage de l’enregistrement du problème à une phase d’analyse active. Cet événement est déduit lorsque le champ Status passe à « Under Investigation ». | ||
|
Pourquoi c’est important
Marque le début de la phase de travail effective et contribue au KPI « Investigation Cycle Time ».
Où les obtenir
Formulaire PBM:Problem Investigation, champ « Status » = « Under Investigation ».
Collecte
Comparer le champ Status pour détecter le passage à Under Investigation
Type d’événement
inferred
|
|||
|
Problem Record annulé
|
Fin de l’enregistrement du problème avant sa résolution. Cet événement est capturé lorsque le statut devient « Cancelled » ou « Rejected ». | ||
|
Pourquoi c’est important
Permet d’identifier les efforts inutiles ou les doublons justifiés. Représente un point de fin alternatif.
Où les obtenir
Formulaire PBM:Problem Investigation, champ « Status » = « Cancelled » ou « Rejected ».
Collecte
Comparer le champ Status pour détecter le passage à Cancelled
Type d’événement
inferred
|
|||
|
Problem Record clôturé
|
Clôture administrative finale de l’enregistrement du problème. Cet événement met fin à l’instance de processus. | ||
|
Pourquoi c’est important
Événement de fin standard. Nécessaire pour analyser la durée complète du cycle et calculer l’« Incident Linkage Density ».
Où les obtenir
Formulaire PBM:Problem Investigation, champ « Status » = « Closed ».
Collecte
Comparer le champ Status pour détecter le passage à Closed
Type d’événement
inferred
|
|||
|
Résolution vérifiée
|
Moment où la correction définitive est confirmée comme efficace. Cet événement est déduit lorsque le Status passe à « Solution Implemented » ou « Completed ». | ||
|
Pourquoi c’est important
Utilisé pour le « Problem SLA Adherence Rate ». Confirme que le travail technique est terminé.
Où les obtenir
Formulaire PBM:Problem Investigation, champ « Status » = « Solution Implemented » ou « Completed ».
Collecte
Comparer le champ Status pour détecter le passage à Solution Implemented
Type d’événement
inferred
|
|||
|
Solution de contournement définie
|
Saisie ou mise à jour de texte dans le champ Workaround de l’enregistrement du problème. Cet événement indique qu’une solution temporaire a été documentée. | ||
|
Pourquoi c’est important
Contribue au KPI « Workaround Publication Lead Time » et indique que l’impact de l’incident est atténué.
Où les obtenir
Formulaire PBM:Problem Investigation, modifications du champ texte « Workaround ».
Collecte
Comparer le contenu du champ « Workaround » pour détecter les mises à jour non nulles
Type d’événement
inferred
|
|||
|
Base de solutions mise à jour
|
Passage de l’enregistrement à l’état « Solution Database », indiquant qu’une correction définitive a été proposée ou identifiée. | ||
|
Pourquoi c’est important
Suit l’avancement de la définition de la solution avant sa mise en œuvre.
Où les obtenir
Formulaire PBM:Problem Investigation, champ « Status » = « Solution Database ».
Collecte
Comparer le champ Status pour détecter le passage à Solution Database
Type d’événement
inferred
|
|||
|
Coordinateur réaffecté
|
Changement de la personne chargée de coordonner le problème au sein d’un groupe de support. Cet événement est capturé en surveillant le champ « Problem Coordinator ». | ||
|
Pourquoi c’est important
Contribue à analyser la répartition de la charge de travail et les goulots d’étranglement liés aux ressources individuelles.
Où les obtenir
Formulaire PBM:Problem Investigation, historique du champ « Problem Coordinator ».
Collecte
Comparer la valeur du champ « Problem Coordinator » avant et après la mise à jour
Type d’événement
inferred
|
|||
|
Known Error promu
|
Création d’un enregistrement Known Error associé à l’investigation du problème. Il s’agit d’un événement de création d’un enregistrement associé. | ||
|
Pourquoi c’est important
Indique la formalisation du problème pour faciliter sa communication et son suivi à long terme.
Où les obtenir
Création d’un enregistrement dans PBM:Known Error associé à l’identifiant PBM:Problem Investigation.
Collecte
Enregistré lors de la création de l’enregistrement PBM:Known Error
Type d’événement
explicit
|
|||
|
Revue post-mise en œuvre réalisée
|
Achèvement de la phase PIR. Cet événement est capturé par une transition de statut sortant d’un état PIR ou par la clôture d’une Task PIR associée. | ||
|
Pourquoi c’est important
Contribue directement à la « Post Implementation Review Compliance » et aux audits de qualité des processus.
Où les obtenir
Formulaire PBM:Problem Investigation, indicateur « PIR Required » ou achèvement d’une Task associée de type « PIR ».
Collecte
Déduit de l’achèvement du statut PIR ou de la clôture de la Task PIR
Type d’événement
inferred
|
|||
Guides d’extraction
Prêt à commencer ?
Améliorez la stabilité de vos services en appliquant dès aujourd’hui ce modèle à vos données BMC Helix ITSM. Notre équipe est à votre disposition pour répondre à vos questions sur la configuration.
Éliminez dès aujourd’hui les goulots d’étranglement de la Gestion des problèmes
Réduisez la durée des cycles de 30 % et améliorez la stabilité de vos services.
Aucune carte bancaire requise. Configuration en quelques minutes.