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 profondes
- Jalons de processus standardisés à suivre
- Conseils d’extraction propres à BMC Helix ITSM
Attributs de gestion des problèmes
| Nom | Description | ||
|---|---|---|---|
|
Activité
Activity
|
La tâche précise ou le changement de statut qui s’est produit. | ||
|
Description
Cet attribut désigne l’étape précise du cycle de gestion des problèmes, par exemple « Dossier de problème enregistré », « Cause racine identifiée » ou « Base de solutions mise à jour ». Dans BMC Helix, ces informations sont souvent déduites de l’historique des statuts, des journaux d’audit ou des horodatages de transaction du module Problem Investigation. Cet attribut est au cœur de la découverte des processus. En analysant la séquence des activités, l’outil de Process Mining construit la carte du processus et révèle le déroulement réel du travail par rapport au processus prévu. Il met en évidence les boucles, les reprises et les écarts par rapport à la procédure standard. Des noms d’activité 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 entre des étapes précises, par exemple entre l’identification d’une cause racine et le lancement d’une demande de changement.
Pourquoi est-ce important ?
Il définit les nœuds de la carte du processus et permet de visualiser le flux de travail.
Où trouver ces données
Déduit de l’historique des statuts PBM:Problem Investigation ou de PBM:AuditLogSystem
Exemples
Dossier de problème enregistréAffecté à un groupe d’assistanceDébut de l’investigationCause racine identifiée
|
|||
|
Dossier de problème
ProblemRecord
|
Identifiant unique du dossier d’investigation du problème. | ||
|
Description
Cet attribut sert d’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) du formulaire PBM:Problem Investigation. Il relie toutes les activités associées, de l’enregistrement initial du problème à sa clôture définitive et à la revue après mise en œuvre. Dans une analyse de Process Mining, cet attribut sert à regrouper les événements individuels au sein d’une même instance de processus. Les analystes peuvent ainsi visualiser le parcours complet d’une investigation donnée. Sans cet identifiant, il serait impossible de relier les actions successives menées par différentes équipes d’assistance et différents coordinateurs. Ce champ constitue la clé primaire du journal d’événements et est indispensable à toutes les agrégations par dossier, par exemple pour calculer le temps de cycle total par problème ou compter les problèmes par niveau de priorité.
Pourquoi est-ce important ?
C’est la clé fondamentale nécessaire pour construire la vue du processus et suivre le cycle de vie de problèmes précis.
Où trouver ces données
Formulaire PBM:Problem Investigation, champ « Problem ID »
Exemples
PBI00000004512PBI00000004513PBI00000004514
|
|||
|
Heure de l’événement
EventTime
|
Horodatage de l’activité concernée. | ||
|
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 » ou « Last Modified Date », ou aux horodatages consignés dans les tables d’historique lors des changements de statut. Lors de l’analyse, cet attribut sert à ordonner les événements chronologiquement et à calculer les durées. Il permet de mesurer les temps de cycle entre deux étapes du processus, par exemple le « Temps de cycle de l’investigation » ou le « Délai de publication de la solution de contournement ». Des horodatages précis sont indispensables pour repérer les goulots d’étranglement. En calculant le délai entre des événements successifs, les analystes peuvent déterminer exactement où se produisent les retards, qu’il s’agisse de l’affectation initiale ou de la phase de revue finale.
Pourquoi est-ce important ?
Il permet de calculer tous les indicateurs fondés sur une durée et d’ordonner les événements.
Où trouver ces données
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 de l’extraction ou de la dernière actualisation des données. | ||
|
Description
Cet attribut indique la date du dernier chargement des données dans l’application de Process Mining. Les analystes peuvent ainsi connaître leur degré d’actualité. Il est généralement généré par le script d’extraction ou l’outil de pipeline de données. Lors de l’analyse, il évite de prendre des décisions à partir de données obsolètes. Par exemple, si un responsable consulte les « Dossiers de problème ouverts », 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. Cet attribut sert également aux chargements incrémentiels. En suivant l’heure de la dernière mise à jour, le processus ETL peut récupérer uniquement les dossiers modifiés depuis l’extraction précédente, ce qui optimise les performances et réduit la charge du système.
Pourquoi est-ce important ?
Il garantit l’actualité des données et facilite les stratégies de chargement incrémentiel.
Où trouver ces données
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 dont les données de processus ont été extraites, en l’occurrence « BMC Helix ITSM ». Il est particulièrement important dans les environnements qui utilisent plusieurs systèmes et où le Process Mining peut agréger des données provenant de différents outils ITSM, de développement ou de fournisseurs externes. Lors de l’analyse, ce champ sert de métadonnée pour vérifier l’origine du dossier. Si la vue du processus combine des données de BMC Helix pour la gestion des problèmes et celles d’un système distinct de développement logiciel, comme Jira, cet attribut permet de segmenter l’analyse selon l’outil source. Il facilite également le diagnostic technique. En cas de problème de qualité des données, connaître le 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 est-ce important ?
Il assure la traçabilité et fournit le contexte, notamment dans les vues de processus couvrant plusieurs systèmes.
Où trouver ces données
Renseigné en dur lors de l’extraction
Exemples
BMC Helix ITSMRemedy OnDemandBMC ITSM Prod
|
|||
|
Catégorie de la 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 « Erreur logicielle », « Défaillance matérielle » ou « Lacune dans le processus ». Dans BMC Helix, cette valeur est généralement sélectionnée dans les menus « Root Cause » ou « Generic Categorization ». Cet attribut est essentiel à la vue « Efficacité et qualité des corrections ». Il permet à l’organisation de mettre en relation certains types de causes racines avec les taux de reprises ou les longues durées d’investigation. Il peut, par exemple, révéler que les problèmes liés à une « Erreur logicielle » prennent systématiquement deux fois plus de temps à résoudre que ceux dus à une « Défaillance matérielle ». Il sert également à calculer le « Taux de catégorisation des causes racines ». Une forte proportion de valeurs « Inconnu » ou « Autre » dans ce champ indique qu’il pourrait être nécessaire de renforcer la formation technique ou de proposer des catégories plus précises.
Pourquoi est-ce important ?
Il permet d’analyser les tendances des problèmes systémiques et contribue à une gestion proactive des problèmes.
Où trouver ces données
Formulaire PBM:Problem Investigation, champs de l’onglet « Root Cause » ou de catégorisation
Exemples
Module logicielInfrastructure réseauErreur humaine
|
|||
|
Coordinateur de problèmes
ProblemCoordinator
|
Personne chargée de coordonner l’investigation. | ||
|
Description
Cet attribut désigne la personne responsable du dossier de problème. Dans BMC Helix ITSM, il correspond au champ « Problem Coordinator ». Cette personne est responsable du cycle de vie du problème, même si certaines tâches sont déléguées. Cet attribut contribue au Dashboard « Répartition de la charge de travail par groupe d’assistance ». Il aide les responsables à repérer les personnes qui gèrent trop d’investigations et celles qui disposent encore de capacité. Il permet également d’analyser les performances individuelles et de déterminer les besoins de formation ou de repérer les personnes les plus performantes. Dans le Process Mining, ce champ constitue un attribut de ressource. Il permet de visualiser la circulation du travail entre les personnes et peut révéler des points de défaillance uniques, lorsqu’un processus dépend trop fortement d’un spécialiste.
Pourquoi est-ce important ?
Il permet d’analyser les ressources et d’équilibrer la charge de travail à l’échelle individuelle.
Où trouver ces données
Formulaire PBM:Problem Investigation, champ « Problem Coordinator »
Exemples
Jean DupontJeanne MartinAdministrateur système
|
|||
|
Date limite de résolution du SLA
SLADueDate
|
La date et l’heure auxquelles le problème doit être résolu au plus tard. | ||
|
Description
Cet attribut indique l’échéance de résolution du problème, définie par l’accord de niveau de service. Dans BMC Helix, il correspond souvent à la « Target Resolution Date » ou à l’horodatage d’une étape calculée du SLA. Il sert de référence au Dashboard « Respect des SLA et tendances des dépassements ». En comparant cet horodatage à celui de l’activité « Résolution vérifiée », le système détermine si le SLA a été respecté ou dépassé. La visualisation de cette date permet aux analystes de voir si l’équipe termine largement avant l’échéance ou juste quelques minutes avant le dépassement. Cette information contribue à la planification des capacités.
Pourquoi est-ce important ?
Il sert de référence pour calculer les indicateurs de conformité et de respect des délais.
Où trouver ces données
PBM:Problem Investigation form, champ « Target Resolution Date »
Exemples
2023-12-01T17:00:00Z2023-12-02T09:00:00Z
|
|||
|
Élément de configuration du service
ServiceCI
|
Service métier principal ou élément de configuration concerné. | ||
|
Description
Cet attribut identifie l’élément de configuration du service (CI) associé au problème, par exemple « Service de messagerie », « SAP ERP » ou « Réseau Wi-Fi ». Dans BMC Helix, il correspond souvent au champ « Service+ » ou à la relation avec le CI principal. Lors de l’analyse, il permet de segmenter les dossiers de problème par produit ou service. Les responsables informatiques peuvent ainsi déterminer quels services sont les plus fragiles et génèrent le plus d’investigations. Cet attribut ajoute une dimension produit au Dashboard « Volume et répartition des priorités ». La mise en relation de cet attribut avec le « Temps de cycle de l’investigation » peut révéler 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 est-ce important ?
Il relie les performances du processus à des produits ou services précis de l’entreprise.
Où trouver ces données
Formulaire PBM:Problem Investigation, champ « ServiceCI » ou « CI Name »
Exemples
Service de messagerieSystème de paieVPN d’entreprise
|
|||
|
Groupe d’assistance
SupportGroup
|
Équipe technique actuellement chargée de l’investigation du problème. | ||
|
Description
Cet attribut indique le groupe d’assistance précis, par exemple « Administration des serveurs » ou « Assistance bases de données », responsable du dossier de problème au moment de l’événement. Dans BMC Helix, il correspond au champ « Assigned Group ». Cet attribut est essentiel aux Dashboards « Répartition de la charge de travail par groupe d’assistance » et « Analyse des réaffectations entre groupes d’assistance ». Les analystes peuvent filtrer la carte du processus par équipe et repérer les groupes qui traitent le plus de dossiers ainsi que ceux qui constituent des goulots d’étranglement dans le processus d’investigation. L’analyse des transferts entre groupes d’assistance permet de repérer les renvois d’un service à l’autre, lorsqu’un ticket passe d’une équipe à l’autre sans être résolu. Cela révèle souvent un manque de clarté dans la répartition des responsabilités ou une gestion des connaissances insuffisante au sein de l’organisation.
Pourquoi est-ce important ?
Il permet d’analyser l’organisation et de repérer les goulots d’étranglement à l’échelle des équipes.
Où trouver ces données
Formulaire PBM:Problem Investigation, champ « Assigned Group »
Exemples
Centre de services, niveau 1Assistance du back-officeAdministration réseau
|
|||
|
Motif de l’investigation
InvestigationDriver
|
Raison du lancement de l’investigation du problème. | ||
|
Description
Cet attribut classe le déclencheur du dossier de problème, par exemple « Volume d’incidents », « Incident majeur », « Notification du fournisseur » ou « Analyse proactive des tendances ». Dans BMC Helix, il correspond au champ « Investigation Driver ». Cet attribut contribue au Dashboard « Tendances de détection proactive ». Il permet à l’organisation de mesurer le passage d’une gestion réactive des incidents à une gestion proactive des problèmes, qui consiste à repérer les risques avant qu’ils ne se concrétisent. L’analyse des flux de processus selon le « Motif de l’investigation » peut révéler des comportements différents. Par exemple, les problèmes détectés de manière proactive peuvent rester plus longtemps dans la file d’attente, car ils ne provoquent pas de panne immédiate, tandis que ceux liés à un « Incident majeur » sont traités en priorité.
Pourquoi est-ce important ?
Il distingue le travail réactif du travail proactif, un indicateur important du niveau de maturité.
Où trouver ces données
Formulaire PBM:Problem Investigation, champ « Investigation Driver »
Exemples
RéactifProactifIncidents récurrents
|
|||
|
Nombre d’incidents associés
RelatedIncidentCount
|
Nombre d’incidents liés à cet enregistrement de problème. | ||
|
Description
Cet attribut mesure 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 l’indicateur « Densité des liens entre incidents ». Un nombre élevé signale un problème à fort impact qui génère une charge importante pour le centre de services. Le croiser avec la « Priorité » permet de vérifier que les problèmes qui touchent le plus d’incidents sont bien traités comme critiques. Il aide également à établir les priorités du backlog. Un problème associé à 500 incidents devrait probablement passer avant un problème « Critique » lié à un seul incident, car sa résolution libérerait davantage de capacité au centre de services.
Pourquoi est-ce important ?
Il mesure l’impact opérationnel du problème et les difficultés qu’il entraîne pour les utilisateurs.
Où trouver ces données
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é du dossier de problème, par exemple Critique, Élevée, Moyenne ou Faible. Dans BMC Helix, il s’agit généralement d’un champ calculé à partir des valeurs d’impact et d’urgence. Lors de l’analyse, cet attribut sert au Dashboard « Volume et répartition des priorités ». Les organisations peuvent ainsi vérifier si les ressources sont affectées en fonction des besoins de l’entreprise. En principe, les problèmes de priorité « Critique » devraient être affectés plus rapidement et présenter un temps de cycle global plus court que ceux de priorité « Faible ». Le filtrage par priorité aide à cibler les efforts d’amélioration. Un goulot d’étranglement dans un processus de priorité « Faible » peut être acceptable, mais le même retard dans un processus de priorité « Critique » représente un risque important pour la continuité des activités et le respect des SLA.
Pourquoi est-ce important ?
Il segmente l’analyse selon le niveau de criticité pour l’entreprise et contribue à l’analyse des SLA.
Où trouver ces données
Formulaire PBM:Problem Investigation, champ « Priority »
Exemples
CritiqueÉlevéeMoyenneFaible
|
|||
|
SLA dépassé
IsSLABreached
|
Indique 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 a dépassé son accord de niveau de service. Il est calculé en comparant l’horodatage de l’activité « Résolution vérifiée » à la « Date limite de résolution du SLA », ou extrait directement du statut SLM. Cet attribut est essentiel au Dashboard « Respect des SLA et tendances des dépassements ». Il permet de répartir simplement les processus entre conformes et non conformes. Il devient ainsi facile d’isoler les caractéristiques des processus qui n’aboutissent pas, par exemple : « Les cas ayant dépassé le SLA concernent-ils toujours le groupe d’assistance X ? » Il constitue un filtre important pour analyser les causes racines des échecs de processus. Les analystes peuvent filtrer les cas où « IsSLABreached = True », puis examiner la carte du processus pour repérer où le temps a été perdu, par exemple dans l’attente prolongée d’une approbation du fournisseur.
Pourquoi est-ce important ?
Il simplifie le suivi de la conformité et l’analyse des échecs.
Où trouver ces données
Formulaire SLM:Measurement ou valeur calculée
Exemples
truefalse
|
|||
|
ID de demande de changement associée
RelatedChangeRequestId
|
Identifiant de la demande de changement créée pour résoudre le problème. | ||
|
Description
Cet attribut contient l’ID de la demande de changement (par exemple, CRQ0000...) liée à l’enregistrement du problème. Il marque le passage de l’investigation à la mise en œuvre d’une solution permanente. Cet attribut est nécessaire à l’indicateur « Délai entre l’identification de la cause racine et le lancement du changement ». Il permet à l’outil de Process Mining de mesurer le temps écoulé entre la découverte de la cause racine et le démarrage du processus de changement. Cette étape de transfert est souvent un moment où le processus perd de son élan. Il permet aussi de vérifier que le processus est complet. Un problème clôturé avec le statut « Terminé », mais sans demande de changement associée ni solution de contournement, peut révéler un écart au processus : la cause racine a été trouvée, mais le problème n’a pas été réellement corrigé.
Pourquoi est-ce important ?
Il relie le processus de gestion des problèmes à celui de gestion du changement.
Où trouver ces données
PBM:Investigation Associations ou onglet Relationship
Exemples
CRQ00000021345CRQ00000021346
|
|||
|
Nombre de réaffectations
ReassignmentCount
|
Nombre total de changements de groupe d’assistance. | ||
|
Description
Cet attribut compte le nombre d’occurrences de l’activité « Affecté au groupe d’assistance » pour un même cas. Il mesure directement les frictions du processus et l’efficacité de l’acheminement. Cet attribut alimente le graphique « Analyse des réaffectations entre groupes d’assistance ». Des valeurs élevées, signe d’allers-retours entre équipes, indiquent que le triage initial ne fonctionne pas ou que la responsabilité des problèmes complexes n’est pas clairement définie. C’est un indicateur précurseur d’une hausse du temps de cycle. Les responsables s’en servent pour repérer les besoins de formation. Si le centre de services réaffecte systématiquement les problèmes de « Base de données » au groupe « Réseau », qui les renvoie ensuite au groupe « Base de données », le nombre de réaffectations augmente. Cela met en évidence le besoin d’améliorer les procédures de diagnostic initial.
Pourquoi est-ce important ?
Il met en évidence les tâches inutiles, les frictions et le manque de responsabilité clairement définie dans le processus.
Où trouver ces données
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 indique la zone géographique (par exemple, « Amérique du Nord » ou « EMEA ») où le problème est apparu ou est pris en charge. Dans BMC Helix, cette information figure souvent dans les champs « Région » ou « Site » associés au demandeur ou à l’actif concerné. Dans le cadre de l’analyse, cet attribut permet de segmenter les données par zone géographique. Il aide à repérer les régions où le volume de problèmes est plus élevé ou les délais de résolution plus longs. Ces écarts peuvent révéler des différences dans les effectifs de l’assistance ou la qualité des infrastructures selon les sites. Il est utile aux organisations internationales qui souhaitent assurer une prestation de services cohérente. Si le « temps de cycle de l’investigation » est deux fois plus long en « APAC » qu’en « NAM », cela peut conduire à examiner la répartition des ressources ou le respect des processus dans cette région.
Pourquoi est-ce important ?
Permet de comparer les performances des processus selon les zones géographiques.
Où trouver ces données
PBM:Problem Investigation form, champ « Region »
Exemples
AmériquesEMEAAPAC
|
|||
|
Statut de la solution de contournement
WorkaroundStatus
|
Indique si une solution de contournement valide a été trouvé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’un champ de statut. Dans BMC Helix, sa valeur est souvent déduite de la présence de texte dans le champ « Workaround » ou d’un indicateur de statut spécifique. Cet attribut est essentiel au Dashboard « Publication des solutions de contournement ». Il permet d’évaluer dans quelle mesure l’équipe limite l’impact pendant qu’elle recherche la cause racine. Une vue du processus filtrée sur « Aucune solution de contournement » met en évidence les cas où l’activité est pleinement affectée pendant l’investigation. Il contribue également aux audits qualité. Clôturer un problème sans solution permanente (demande de changement) ET sans solution de contournement constitue généralement un écart au processus qui doit être examiné.
Pourquoi est-ce important ?
Il mesure l’efficacité des mesures prises pour limiter l’impact pendant l’investigation.
Où trouver ces données
PBM:Problem Investigation form, vérification du contenu du champ « Workaround »
Exemples
ActifAucunRetiré
|
|||
|
Temps de cycle de l’investigation
InvestigationCycleTime
|
Durée entre le début de l’investigation et l’identification de la cause racine. | ||
|
Description
Cet attribut de durée calculée mesure le temps écoulé entre l’activité « Début de l’investigation » et l’activité « Cause racine identifiée ». Il correspond au temps consacré à l’investigation dans le processus de gestion des problèmes. Cet indicateur alimente le Dashboard « Temps de cycle de l’investigation de la cause racine ». Il aide les responsables à comprendre la complexité technique des problèmes et l’efficacité des équipes d’investigation. Des durées anormalement courtes peuvent indiquer que le diagnostic repose sur des suppositions, tandis que des durées très longues peuvent signaler une investigation à l’arrêt. En comparant cet indicateur entre les groupes d’assistance et les niveaux de priorité, l’organisation peut déterminer quelles équipes ont besoin de meilleurs outils, de formation ou de l’assistance de fournisseurs pour diagnostiquer les problèmes plus rapidement.
Pourquoi est-ce important ?
Il s’agit du principal indicateur d’efficacité de la phase d’investigation technique.
Où trouver ces données
Calculé à partir des horodatages des activités
Exemples
4500000120000
|
|||
Activités de gestion des problèmes
| Activité | Description | ||
|---|---|---|---|
|
Affecté à un groupe d’assistance
|
Affectation du dossier de problème à une équipe technique précise. L’événement est enregistré en surveillant les modifications du champ « Assigned Group ». | ||
|
Pourquoi est-ce important ?
Indispensable pour mesurer les transferts, les renvois d’un service à l’autre et l’indicateur « Délai moyen avant affectation initiale ».
Où trouver ces données
Formulaire PBM:Problem Investigation, historique du champ « Assigned Group » ou journal d’audit.
Données à recueillir
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ù le dossier de problème passe à un état indiquant que la cause est connue. Cet événement est déduit lorsque le champ Status passe à « Root Cause Identified ». | ||
|
Pourquoi est-ce important ?
Étape essentielle du Dashboard « Temps de cycle de l’analyse de la cause racine ». Elle marque le passage de l’analyse à la recherche d’une solution.
Où trouver ces données
Formulaire PBM:Problem Investigation, champ « Status » = « Root Cause Identified ».
Données à recueillir
Comparer le champ Status pour repérer le passage à Root Cause Identified
Type d’événement
inferred
|
|||
|
Début de l’investigation
|
Passage du dossier de problème à une phase d’analyse active. Cet événement est déduit lorsque le champ Status passe à « Under Investigation ». | ||
|
Pourquoi est-ce important ?
Marque le début de la phase de travail proprement dite et permet de calculer l’indicateur « Temps de cycle de l’investigation ».
Où trouver ces données
Formulaire PBM:Problem Investigation, champ « Status » = « Under Investigation ».
Données à recueillir
Comparer le champ Status pour repérer le passage à Under Investigation
Type d’événement
inferred
|
|||
|
Demande de changement lancée
|
Association d’une demande de changement d’infrastructure à l’investigation du problème. Cet événement marque le début de la phase de mise en œuvre. | ||
|
Pourquoi est-ce important ?
Indispensable pour calculer l’indicateur « Délai entre la cause racine et le changement » et repérer les cloisonnements entre les processus de gestion des problèmes et de gestion du changement.
Où trouver ces données
Table PBM:Investigation_Associations ou renseignement du champ « Infrastructure Change ID ».
Données à recueillir
Enregistré lors de la création de l’association dans PBM:Investigation_Associations
Type d’événement
explicit
|
|||
|
Dossier de problème annulé
|
Fin du traitement d’un dossier de problème avant sa résolution. L’événement est enregistré lorsque le statut passe à « Cancelled » ou « Rejected ». | ||
|
Pourquoi est-ce important ?
Permet de repérer les efforts inutiles ou les doublons justifiés. Correspond à une autre issue possible du processus.
Où trouver ces données
Formulaire PBM:Problem Investigation, champ « Status » = « Cancelled » ou « Rejected ».
Données à recueillir
Comparer le champ Status pour repérer le passage à Cancelled
Type d’événement
inferred
|
|||
|
Dossier de problème clôturé
|
Clôture administrative définitive du dossier de problème. Cet événement met fin à l’instance de processus. | ||
|
Pourquoi est-ce important ?
Événement de fin standard. Nécessaire à l’analyse complète du temps de cycle et au calcul de la « Densité des liens avec les incidents ».
Où trouver ces données
Formulaire PBM:Problem Investigation, champ « Status » = « Closed ».
Données à recueillir
Comparer le champ Status pour repérer le passage à Closed
Type d’événement
inferred
|
|||
|
Dossier de problème enregistré
|
Création initiale d’un dossier d’investigation de problème dans le système. Cet événement est enregistré explicitement lorsqu’une nouvelle entrée est sauvegardée dans le formulaire PBM:Problem Investigation. | ||
|
Pourquoi est-ce important ?
Marque le début de l’instance de processus. Cet événement est essentiel pour calculer le temps de cycle global et les indicateurs de délai de première réponse.
Où trouver ces données
Formulaire PBM:Problem Investigation, horodatage « Submit Date » ou journal de création avec « Status » = « Brouillon ».
Données à recueillir
Enregistré lors de la création d’un dossier PBM:Problem Investigation
Type d’événement
explicit
|
|||
|
Résolution vérifiée
|
Moment où la réussite de la solution durable est confirmée. Cet événement est déduit lorsque le champ Status passe à « Solution Implemented » ou « Completed ». | ||
|
Pourquoi est-ce important ?
Utilisé pour calculer le « Taux de respect des SLA des problèmes ». Confirme la fin du travail technique.
Où trouver ces données
Formulaire PBM:Problem Investigation, champ « Status » = « Solution Implemented » ou « Completed ».
Données à recueillir
Comparer le champ Status pour repérer le passage à Solution Implemented
Type d’événement
inferred
|
|||
|
Solution de contournement définie
|
Saisie ou mise à jour du texte dans le champ Workaround du dossier de problème. Cet événement indique qu’une solution temporaire a été documentée. | ||
|
Pourquoi est-ce important ?
Permet de calculer l’indicateur « Délai de publication de la solution de contournement » et signale l’atténuation de l’impact de l’incident.
Où trouver ces données
Formulaire PBM:Problem Investigation, modifications du champ texte « Workaround ».
Données à recueillir
Comparer le contenu du champ « Workaround » pour repérer les mises à jour non nulles
Type d’événement
inferred
|
|||
|
Base de solutions mise à jour
|
Passage du dossier à l’état « Solution Database », indiquant qu’une solution durable a été proposée ou identifiée. | ||
|
Pourquoi est-ce important ?
Suit l’avancement de la définition de la solution avant sa mise en œuvre.
Où trouver ces données
Formulaire PBM:Problem Investigation, champ « Status » = « Solution Database ».
Données à recueillir
Comparer le champ Status pour repérer le passage à Solution Database
Type d’événement
inferred
|
|||
|
Coordinateur réaffecté
|
Changement de coordinateur du problème au sein d’un groupe d’assistance. L’événement est enregistré en surveillant le champ « Problem Coordinator ». | ||
|
Pourquoi est-ce important ?
Permet d’analyser la répartition de la charge de travail et les goulots d’étranglement liés aux ressources individuelles.
Où trouver ces données
Formulaire PBM:Problem Investigation, historique du champ « Problem Coordinator ».
Données à recueillir
Comparer la valeur du champ « Problem Coordinator » avant et après la mise à jour
Type d’événement
inferred
|
|||
|
Erreur connue enregistrée
|
Création d’un dossier d’erreur connue associé à l’investigation du problème. Il s’agit d’un événement de création d’un dossier lié. | ||
|
Pourquoi est-ce important ?
Indique que le problème a été formalisé afin d’en faciliter la communication et le suivi à long terme.
Où trouver ces données
Création d’un dossier dans PBM:Known Error associé à l’identifiant PBM:Problem Investigation.
Données à recueillir
Enregistré lors de la création d’un dossier PBM:Known Error
Type d’événement
explicit
|
|||
|
Revue après mise en œuvre effectuée
|
Fin de la phase PIR. L’événement est enregistré lors du passage à un état autre qu’un état PIR ou à la clôture d’une Task PIR associée. | ||
|
Pourquoi est-ce important ?
Contribue directement au suivi de la « Conformité des revues après mise en œuvre » et aux audits de qualité des processus.
Où trouver ces données
Formulaire PBM:Problem Investigation, indicateur « PIR Required » ou clôture d’une Task associée de type « PIR ».
Données à recueillir
Déduit de la fin de l’état PIR ou de la clôture d’une Task PIR
Type d’événement
inferred
|
|||
Guides d’extraction
Prêt à commencer ?
Appliquez dès aujourd’hui ce modèle à vos données BMC Helix ITSM pour améliorer la stabilité de vos services. Notre équipe peut vous aider si vous avez des questions sur la configuration.
Éliminez dès aujourd’hui les goulots d’étranglement de la gestion des problèmes
Réduisez les temps de cycle de 30 % et améliorez la stabilité des services.
Aucune carte bancaire requise. Configuration en quelques minutes.