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

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

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

Ce modèle fournit une structure complète pour analyser vos flux de travail d’investigation des causes profondes dans BMC Helix ITSM. Il décrit les attributs essentiels et les activités de processus nécessaires à la création d’un journal d’événements détaillé, ainsi que des indications pratiques pour l’extraction. En suivant ce guide, vous pouvez identifier les goulots d’étranglement cachés et accélérer votre parcours vers la résolution définitive des incidents.
  • 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
Vous découvrez les journaux d’événements ? En savoir plus sur la création d’un journal d’événements pour le Process Mining.

Attributs de la gestion des problèmes

Ce tableau contient les champs de données recommandés pour alimenter votre journal d’événements et analyser en détail le cycle de vie de votre gestion des problèmes.
5 Obligatoire 9 Recommandé 5 Facultatif
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é
Obligatoire Recommandé Facultatif

Activités de gestion des problèmes

Voici les étapes fondamentales du processus et les changements de statut à suivre pour obtenir une visibilité complète sur les phases d’analyse et de résolution.
9 Recommandé 4 Facultatif
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
Recommandé Facultatif

Guides d’extraction

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

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.

Démarrer l’essai gratuit

Aucune carte bancaire requise. Configuration en quelques minutes.