> Amélioration continue des processus > Gestion des incidents > BMC Helix > Modèle de données

Template de données : Gestion des Incidents

BMC Helix

Attributs de gestion des incidents (19) Activités de gestion des incidents (14) Guides d'extraction (2)

Votre Template de Données de Gestion des Incidents

Ce Template offre une feuille de route claire pour la collecte des données essentielles nécessaires à l'analyse et à l'optimisation de votre processus de Gestion des Incidents dans Bmc Helix. Il décrit les Attributs et activités clés à suivre, ainsi que des conseils pratiques sur l'extraction des données. En suivant ce Template, vous assurerez une base complète et précise pour la découverte et l'amélioration des processus.

Attributs recommandés à collecter
Activités clés à suivre
Guide d'extraction pour BMC Helix

Nouveau dans les journaux d'événements ? Apprenez comment créer un journal d'événements Process Mining.

Télécharger le modèle

Attributs de gestion des incidents

Ce sont les champs de données recommandés à inclure dans votre Event Log pour une analyse complète de votre processus de gestion des incidents.

5 Obligatoire 7 Recommandé 7 Facultatif

	Nom	Description
	Activité ActivityName	Le nom de l'action ou de l'événement spécifique qui s'est produit à un moment donné du cycle de vie de l'incident.
Description Le Nom de l'Activité décrit une étape du processus de Gestion des Incidents, telle que 'Incident Catégorisé', 'Attribué au Groupe de Support' ou 'Incident Résolu'. Ces activités forment les nœuds de la carte des processus découverte. L'analyse de la séquence et de la fréquence de ces activités est essentielle au Process Mining. Elle aide à découvrir le flux de processus réel, à identifier les goulots d'étranglement entre les étapes, à détecter les déviations par rapport à la procédure opérationnelle standard et à mesurer la durée des étapes spécifiques au sein du cycle de vie de l'incident. Pourquoi c'est important Cet attribut définit les étapes du processus, permettant la visualisation de la carte de processus et l'analyse des flux, des goulots d'étranglement et des déviations. Où obtenir Généralement dérivées des changements de statut, des journaux d'audit ou des enregistrements d'événements spécifiques associés à l'incident dans le 'HPD:HelpDesk_AuditLogSystem' ou des tables d'audit similaires. Exemples Incident signaléAssigné au groupe de supportEnquête initiéeIncident résoluIncident fermé
	Heure de début EventTimestamp	La date et l'heure précises auxquelles une activité ou un événement spécifique s'est produit pour un incident.
Description L'Horodatage d'Événement enregistre le moment où chaque activité a eu lieu. Ces données temporelles sont essentielles pour ordonner les événements chronologiquement et construire le flux de processus avec précision. Dans l'analyse, les horodatages sont utilisés pour calculer les durées entre les activités, mesurer le temps de cycle total des incidents, et identifier les retards ou les temps d'attente dans le processus. Comparer les horodatages aux accords de niveau de service (SLA) est également essentiel pour le suivi des performances et les vérifications de conformité. Pourquoi c'est important Les timestamps fournissent l'ordre chronologique des événements et sont essentiels pour toutes les analyses basées sur le temps, y compris la mesure des performances, l'identification des goulots d'étranglement et la Conformité aux SLA. Où obtenir Ces informations se trouvent dans les tables du journal d'audit, telles que « HPD:HelpDesk_AuditLogSystem », correspondant à chaque action enregistrée ou changement de statut. Exemples 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:45:00Z
	ID d'incident IncidentId	L'identifiant unique de chaque incident signalé, servant de clé primaire pour le suivi du cycle de vie de l'incident.
Description L'ID d'Incident est la pierre angulaire de l'analyse de la Gestion des Incidents. Il identifie de manière unique chaque cas, permettant l'agrégation de tous les événements connexes, changements de statut et activités en une seule instance de processus cohésive. En Process Mining, cet ID relie chaque étape, de 'Incident signalé' à 'Incident fermé', offrant une vue de bout en bout complète du parcours de l'incident. Il est essentiel pour calculer des métriques au niveau du cas telles que le temps de résolution total, le nombre de réaffectations et l'identification des variantes de processus. Pourquoi c'est important Cet attribut est l'identifiant de cas fondamental, permettant de retracer l'intégralité du cycle de vie d'un incident et d'analyser son flux à travers le processus de gestion. Où obtenir Il s'agit d'un champ principal dans le module ou formulaire de gestion des incidents primaire, souvent étiqueté « Incident Number » ou « Incident ID ». Exemples INC000012345678INC000009876543INC000011223344
	Dernière mise à jour des données LastDataUpdate	L'horodatage indiquant la dernière mise à jour des données pour cet enregistrement depuis le système source.
Description Cet attribut fournit l'horodatage de la plus récente extraction de données. C'est un champ de métadonnées essentiel pour comprendre la fraîcheur des données analysées. Savoir quand les données ont été mises à jour pour la dernière fois aide les analystes et les utilisateurs métier à faire confiance aux informations dérivées de l'outil de Process Mining. Cela confirme si l'analyse reflète l'état le plus actuel des opérations ou si elle est basée sur des données plus anciennes. Pourquoi c'est important Assure la transparence concernant la fraîcheur des données, ce qui est crucial pour prendre des décisions métier opportunes et précises basées sur l'analyse des processus. Où obtenir Ce timestamp est généré et ajouté pendant le processus d'extraction, de transformation et de chargement des données (ETL). Exemples 2023-11-01T02:00:00Z2023-11-02T02:00:00Z
	Système source SourceSystem	Le système depuis lequel les données de l'incident ont été extraites.
Description Cet attribut identifie l'origine des données, ce qui est crucial dans les environnements où les données de plusieurs systèmes sont consolidées pour l'analyse. Il aide à assurer la traçabilité des données et fournit un contexte pour la structure et le contenu des données. Pour Bmc Helix, il s'agirait typiquement d'une valeur statique identifiant l'instance ou l'environnement spécifique, par exemple 'BmcHelix_Production'. Il est utile pour filtrer et segmenter les données si plusieurs systèmes sources devaient être intégrés. Pourquoi c'est important Fournit une traçabilité et un contexte pour l'origine des données, ce qui est important pour la gouvernance des données et le dépannage dans les environnements multisystèmes. Où obtenir Il s'agit typiquement d'une valeur statique ajoutée pendant le processus d'extraction, de transformation et de chargement des données (ETL) pour identifier la source de données. Exemples BmcHelixBmcHelix_Prod_EUITSM_Platform_A
	Agent assigné AssignedAgent	L'agent de support individuel chargé de gérer l'incident.
Description L'Agent Assigné est la personne chargée de l'incident à un moment donné. Cela offre un niveau de détail plus granulaire que le groupe de support, permettant l'analyse de la performance individuelle et de la charge de travail. Cet attribut est essentiel pour le dashboard 'Team Workload Distribution' et le KPI 'Activity Volume per Agent StdDev'. En analysant le volume et les types d'incidents gérés par chaque agent, les managers peuvent identifier les individus surchargés, assurer une répartition équitable de la charge de travail et déceler des opportunités de coaching. Pourquoi c'est important Permet une analyse granulaire de la charge de travail et des performances individuelles, aidant à optimiser l'allocation des ressources et à identifier les meilleurs éléments ou ceux ayant besoin de soutien. Où obtenir Un champ standard sur le formulaire 'HPD:Help Desk', communément nommé 'Assignee'. Exemples Alice SmithBob JohnsonCharlie Brown
	Catégorie d'incident IncidentCategory	La classification de l'incident, généralement organisée en structure hiérarchique.
Description La catégorie d’incident offre un moyen structuré de classer les incidents selon le service, le composant ou le type de problème concerné, par exemple « Matériel », « Logiciel » ou « Réseau ». Cette catégorisation est essentielle pour orienter les incidents vers la bonne équipe et analyser ensuite les tendances des incidents. Le dashboard 'Incident Categorization Accuracy' s’appuie sur cet attribut, en comparant souvent sa valeur initiale à sa valeur à la résolution pour mesurer la qualité du tri initial. Une catégorisation fiable aide à identifier les problèmes récurrents et permet une gestion des problèmes plus efficace. Pourquoi c'est important Une catégorisation appropriée est vitale pour un routage efficace, l'analyse des tendances et l'évaluation de l'exactitude du diagnostic initial. Où obtenir Ce sont des champs standards sur le formulaire 'HPD:Help Desk', souvent un ensemble de champs en cascade tels que 'Catégorisation Niveau 1', 'Catégorisation Niveau 2', etc. Exemples Software > Enterprise Apps > ERPMatériel > Ordinateur portable > ClavierRéseau > Connectivité > Wi-Fi
	Gravité Severity	La mesure de l'impact commercial de l'incident.
Description La sévérité détermine l'ampleur de l'impact d'un incident sur les opérations commerciales. Elle constitue une information essentielle, au même titre que l'urgence, pour déterminer la priorité de l'incident et les SLA associés. L'analyse des incidents selon leur sévérité permet de mieux comprendre la performance des processus face aux problèmes les plus critiques. Elle est utilisée dans des dashboards comme le 'Critical SLA Breach Overview' pour catégoriser et se concentrer sur les incidents qui présentent le risque le plus élevé pour l'entreprise. Pourquoi c'est important La sévérité aide à quantifier l'impact commercial des incidents, permettant une analyse axée sur l'atténuation des risques opérationnels les plus significatifs. Où obtenir Consultez la documentation BMC Helix. Il s'agit souvent d'un champ standard du formulaire d'incident, éventuellement nommé 'Impact' ou 'Severity'. Exemples 1-Extensive/Widespread2-Significant/Large3-Moderate/Limited4-Minor/Localized
	Groupe de support assigné AssignedSupportGroup	L'équipe ou le groupe de support responsable du traitement de l'incident.
Description Cet attribut identifie l'équipe assignée à un incident. À mesure qu'un incident progresse, il peut être réaffecté à différents groupes de support, tels que le Service Desk, l'équipe réseau ou le support applicatif. Le suivi des changements de cet attribut est fondamental pour le dashboard 'Analyse des réaffectations d'incidents'. Il permet de visualiser les transferts entre équipes, de mesurer le nombre de transferts par incident et d'identifier les goulots d'étranglement ou les lacunes de connaissances qui entraînent des réaffectations excessives. Il permet également l'analyse de la répartition de la charge de travail entre les équipes. Pourquoi c'est important Cet attribut est essentiel pour analyser la performance des équipes, la répartition de la charge de travail et l'efficacité du routage et des transferts d'incidents. Où obtenir Un champ standard sur le formulaire 'HPD:Help Desk', généralement nommé 'Assigned Group'. Exemples Service DeskOpérations RéseauAdministration de Bases de DonnéesSupport applicatif de niveau 2
	Priorité Priority	Le niveau de priorité de l'incident, qui détermine la vitesse de résolution requise.
Description La priorité est un attribut clé qui dicte l'urgence d'un incident. Elle est souvent dérivée de l'impact et de l'urgence de l'incident et est utilisée pour allouer des ressources et définir les objectifs de Service Level Agreement (SLA). Dans l'analyse par process mining, la priorité est utilisée pour segmenter les incidents afin de comparer les flux de processus des cas de haute priorité et de faible priorité. Cela aide à vérifier si les incidents critiques sont réellement traités plus rapidement et à identifier toute déviation dans leurs chemins de processus, ce qui est essentiel pour le dashboard 'Performance des Incidents à Haute Priorité' et les KPI associés. Pourquoi c'est important Cet attribut est essentiel pour segmenter l'analyse afin de garantir que les incidents de haute urgence sont traités conformément aux procédures et aux SLA définis. Où obtenir Un champ standard sur le formulaire 'HPD:Help Desk', généralement nommé 'Priority'. Exemples CritiqueÉlevéMoyenFaible
	Statut d'incident IncidentStatus	L'état actuel ou historique de l'incident au sein de son cycle de vie, tel que 'Nouveau', 'En Cours' ou 'Fermé'.
Description Le Statut de l'Incident indique l'étape d'un incident à un moment donné. Il est souvent la source pour générer le journal des activités, où un changement de statut correspond à une étape de processus. L'analyse du statut permet de filtrer les incidents par leur état actuel, de comprendre combien de temps est passé dans différents statuts et d'identifier les incidents bloqués. Par exemple, un dashboard pourrait mettre en évidence les incidents qui sont restés dans un statut 'En Attente' pendant une période anormalement longue. Pourquoi c'est important Il fournit une vue instantanée de la progression d’un incident et est essentiel pour repérer les incidents bloqués et analyser le temps passé aux différentes étapes. Où obtenir Un champ essentiel sur le formulaire d'incident principal, généralement 'HPD:Help Desk'. Le champ est souvent nommé 'Status'. Exemples NouveauAssignéEn coursEn attenteRésoluClôturé
	Statut SLA SLAStatus	Indique si l’incident est conforme aux objectifs du SLA ou s’il est en dépassement.
Description Le Statut SLA offre un indicateur clair de la performance des services pour chaque incident. Il affiche généralement des états tels que 'Dans la cible', 'Avertissement' ou 'Dépassé'. Il s'agit souvent d'un champ calculé dynamiquement au sein de Bmc Helix. Cet attribut est essentiel pour le dashboard 'Vue d'ensemble des violations SLA critiques' et l'indicateur clé de performance (KPI) 'Taux de violation SLA d'incidents critiques'. Il permet d'identifier et de prioriser immédiatement les incidents qui ne respectent pas les engagements de service, facilitant ainsi une analyse ciblée des causes des retards. Pourquoi c'est important Mesure directement la performance par rapport aux engagements et est fondamental pour le suivi de la conformité et l'identification des processus qui causent les ruptures de SLA. Où obtenir Il s'agit souvent d'un champ calculé au sein de Bmc Helix, dérivé de la priorité et de l'âge de l'incident. Le statut peut être stocké dans un module de gestion des SLA connexe. Exemples Dans les Limites CiblesAvertissementDépassé
	Canal Channel	La méthode ou le canal par lequel l'incident a été signalé.
Description L'attribut Canal spécifie la manière dont un incident a été initié, par exemple, via un appel téléphonique, un e-mail, un portail en libre-service ou une surveillance automatisée. L'analyse du processus par canal peut révéler d'importantes différences dans les temps de résolution ou les chemins de processus. Par exemple, les incidents signalés via le portail en libre-service pourraient être résolus plus rapidement grâce à une meilleure qualité des données initiales. Cette analyse peut éclairer les décisions concernant les canaux à promouvoir ou à améliorer. Pourquoi c'est important Permet de comprendre comment le mode de signalement influe sur le cycle de vie des incidents, et de repérer des pistes pour optimiser certains canaux et gagner en efficacité. Où obtenir Un champ standard sur le formulaire 'HPD:Help Desk', souvent nommé 'Reported Source'. Exemples E-mailTéléphonePortail en libre-serviceSurveillance du système
	Code de Résolution ResolutionCode	Un code ou une catégorie indiquant comment l'incident a été finalement résolu.
Description Le Code de Résolution saisit le résultat final ou la nature de la solution appliquée à un incident. Ces données structurées sont précieuses pour l'analyse des causes profondes et la compréhension des types de solutions les plus fréquemment requis. Dans l'analyse, cet attribut peut être comparé à l'IncidentCategory initial pour évaluer la précision de la catégorisation. Il fournit également des informations sur les correctifs courants, aidant à construire une base de connaissances ou à identifier les domaines où l'automatisation pourrait être appliquée. Pourquoi c'est important Fournit des données structurées sur les résultats des incidents, soutenant l'analyse des causes profondes et l'amélioration de la gestion des connaissances et de l'automatisation. Où obtenir Consultez la documentation BMC Helix. Ce champ se trouve généralement dans l'onglet ou la section de résolution du formulaire d'incident. Exemples Erreur Utilisateur - Formation DispenséeCorrectif Logiciel AppliquéMatériel remplacéAucun Défaut Trouvé
	Durée de la Résolution ResolutionDuration	Le temps total écoulé entre le premier signalement d'un incident et sa résolution.
Description Cette mesure quantifie la durée entre l'activité « Incident Reported » et l'activité « Incident Resolved ». C'est un indicateur clé de performance (KPI) pour l'efficacité de l'ensemble du processus de gestion des incidents. Cet attribut calculé constitue la base du KPI « Average Incident Resolution Time » et du dashboard « Incident Resolution Cycle Time ». L'analyse de cette durée selon différentes catégories d'incidents, priorités ou équipes aide à identifier les sources systémiques de délai et à mesurer l'impact des initiatives d'amélioration des processus. Pourquoi c'est important Il s'agit d'une mesure principale de l'efficacité des processus et de l'expérience client, reflétant directement le temps nécessaire pour rétablir le service aux utilisateurs. Où obtenir Calculé lors de la transformation des données en déterminant la différence de temps entre le timestamp de l'activité 'Incident Resolved' et l'activité 'Incident Reported' pour chaque case. Exemples 25920000086400000604800000
	Est rouvert IsReopened	Un indicateur qui indique si un incident a été rouvert après avoir été résolu.
Description Cet attribut calculé est un drapeau booléen qui est vrai si un incident a une activité 'Incident rouvert' dans son historique. Un taux élevé d'incidents rouverts peut signaler des problèmes liés à la qualité des résolutions ou à la fermeture prématurée des tickets. Ce drapeau est utilisé directement dans le calcul du KPI 'Taux de réouverture d'incidents' et pour le dashboard 'Tendance du taux de réouverture d'incidents'. Il permet aux analystes de filtrer et d'examiner facilement les incidents rouverts pour comprendre les causes profondes, telles que des correctifs incomplets ou une mauvaise communication avec l'utilisateur. Pourquoi c'est important Ce drapeau mesure directement la qualité de la résolution et la satisfaction client, mettant en évidence les cas où le correctif initial n'était pas efficace. Où obtenir Il s'agit d'un champ calculé, dérivé lors de la transformation des données en vérifiant si le journal d'événements d'un incident contient une activité « Reopened » ou une transition de statut. Exemples truefaux
	Nombre de Réaffectations ReassignmentCount	Le nombre total de fois où un incident a été transféré entre différents groupes de support.
Description Cet attribut calculé compte le nombre de fois où le champ 'AssignedSupportGroup' a changé au cours du cycle de vie d'un incident. Un nombre élevé de réaffectations, souvent appelé 'ping-pong de tickets', indique des inefficacités de processus, telles qu'un acheminement initial incorrect ou des lacunes de connaissances au sein des équipes de support. Cette métrique est au cœur du KPI 'Nombre moyen de réaffectations par incident' et du dashboard 'Analyse des réaffectations d'incidents'. Le suivi de ce compte aide à identifier les opportunités d'améliorer les taux de résolution dès le premier appel et de rationaliser le processus d'acheminement, réduisant ainsi le temps de résolution. Pourquoi c'est important Quantifie l'inefficacité et la friction des processus, mettant en évidence les incidents qui souffrent d'être transmis entre les équipes, ce qui retarde la résolution. Où obtenir Calculé lors de la transformation des données en comptant le nombre de valeurs distinctes ou de changements dans le champ 'AssignedSupportGroup' sur le cycle de vie de chaque incident. Exemples 0135
	Service métier BusinessService	Le service métier ou l'application affectée par l'incident.
Description Cet attribut lie un incident à un service métier spécifique défini dans la Base de Données de Gestion de Configuration (CMDB), tel que le 'Service de messagerie' ou le 'Système ERP'. L'analyse des incidents par service métier affecté est cruciale pour comprendre l'impact sur l'organisation. Elle aide à prioriser les efforts de gestion des problèmes sur les services qui génèrent le plus d'incidents ou subissent le plus de temps d'arrêt. Cette vue est essentielle pour rendre compte de la performance de l'IT d'un point de vue orienté métier. Pourquoi c'est important Connecte les incidents techniques à leur impact métier, permettant une analyse qui priorise le travail en fonction de ce qui est le plus critique pour l'organisation. Où obtenir Il s'agit d'un champ Élément de Configuration (CI) sur le formulaire d'incident, qui est lié à la CMDB. Le champ peut être étiqueté « Service » ou « CI ». Exemples Service de messagerie d'entrepriseSAP ERP FinancialsGestion de la Relation Client
	SLA est enfreint IsSlaBreached	Un indicateur booléen indiquant si le temps de résolution de l'incident a dépassé la cible de SLA.
Description Il s'agit d'un indicateur simplifié dérivé de l'attribut « SLAStatus », où « true » indique que le SLA n'a pas été respecté. Cela fournit un résultat clair et binaire pour faciliter le filtrage et l'agrégation. Cet attribut est utilisé pour calculer le KPI « Critical Incident SLA Breach Rate ». Il permet une segmentation directe de tous les incidents en deux groupes : ceux ayant enfreint le SLA et ceux l'ayant respecté, afin d'analyser les caractéristiques du processus les plus courantes parmi les incidents qui ne parviennent pas à atteindre les objectifs de service. Pourquoi c'est important Fournit un résultat simple et binaire pour la conformité au SLA, ce qui facilite le calcul des taux de violation et l'analyse des chemins courants des cas non conformes. Où obtenir Dérivé de l'attribut 'SLAStatus' lors de la transformation des données. Si 'SLAStatus' est 'Breached', cet indicateur est défini sur true. Exemples truefaux

Obligatoire Recommandé Facultatif

Activités de gestion des incidents

Ce sont les étapes clés du processus et les jalons à capturer dans votre Event Log pour une découverte et une analyse précises des processus.

6 Recommandé 8 Facultatif

	Activité	Description
	Assigné au groupe de support	Cette activité signifie l'affectation initiale de l'incident à un groupe de support spécifique pour enquête et résolution. Elle représente le premier transfert du service desk vers une équipe technique.
Pourquoi c'est important Il s'agit d'un jalon critique pour suivre les taux de résolution au premier contact et les temps de réponse initiaux. Cela aide à identifier les délais dans l'acheminement de l'incident à la bonne équipe. Où obtenir Capturé en suivant la première saisie du champ 'Assigned Group' dans l'historique d'audit de l'incident (HPD:HelpDesk_AuditLogSystem). Capture Déduit de la première modification enregistrée du champ 'Assigned Group' dans les journaux d’audit. Type d'événement inferred
	Incident fermé	L'activité finale du cycle de vie, où l'enregistrement de l'incident est formellement fermé et devient un enregistrement historique en lecture seule. Cela se produit souvent automatiquement après une période définie dans l'état 'Résolu'.
Pourquoi c'est important Cette activité marque la fin définitive du processus. Le temps entre 'Résolu' et 'Fermé' peut mettre en évidence des retards dans les processus administratifs ou les délais de confirmation utilisateur. Où obtenir Il s'agit d'un événement distinct déduit de l'horodatage lorsque le champ « Status » est mis à jour à « Closed ». Ceci est suivi dans l'historique d'audit. Capture Filtrez les journaux d'audit pour le changement de statut à 'Closed'. Type d'événement inferred
	Incident résolu	Indique qu’une résolution a été mise en œuvre et que le service a été rétabli pour l’utilisateur. C’est une étape clé, généralement matérialisée par un changement d’état vers 'Resolved'.
Pourquoi c'est important Il s'agit d'un jalon principal pour mesurer le temps de résolution essentiel. Il marque la fin de la phase de travail active et lance souvent le compte à rebours pour la confirmation utilisateur ou les procédures de clôture automatique. Où obtenir Il s'agit d'un événement distinct déduit de l'horodatage lorsque le champ « Status » est mis à jour à « Resolved ». Ce changement est enregistré dans l'historique d'audit. Capture Filtrez les journaux d'audit pour le changement de statut à 'Resolved'. Type d'événement inferred
	Incident signalé	Marque la création d'un nouvel enregistrement d'incident dans le système. C'est le point de départ du cycle de vie de l'incident, généralement déclenché par une soumission de l'utilisateur via un portail, un e-mail ou par un agent de service desk créant manuellement le ticket.
Pourquoi c'est important Cette activité est l'événement de départ principal du processus. L'analyse du temps entre cet événement et la résolution est fondamentale pour mesurer la durée globale du cycle de vie des incidents et identifier les retards en amont. Où obtenir Il s'agit d'un événement de création explicite capturé à partir de l'horodatage « Submit Date » ou « Reported Date » sur le formulaire HPD:Help Desk. C'est l'un des événements les plus fiables et fondamentaux du système. Capture Capturé à partir du timestamp de création de l'enregistrement d'incident dans la table HPD:Help Desk. Type d'événement explicit
	Résolution Identifiée	Représente le moment où un agent de support a trouvé une solution et l'a documentée dans l'enregistrement d'incident. L'incident est maintenant prêt à passer à un état 'Résolu'.
Pourquoi c'est important Ce jalon marque la fin de la phase d'investigation technique. La durée entre ce point et la clôture peut révéler des goulots d'étranglement dans les processus de communication, de vérification et administratifs. Où obtenir Ceci est souvent déduit de l'horodatage lorsque les détails de résolution sont saisis et enregistrés, juste avant que le statut ne soit modifié en « Resolved ». Capture Utilisez le timestamp de la dernière modification avant que le statut ne passe à « Résolu ». Type d'événement inferred
	Solution de contournement Mise en Œuvre	Signifie qu'une solution temporaire a été fournie à l'utilisateur, rétablissant la fonctionnalité du service pendant qu'une solution permanente est en cours de développement. Ceci est souvent enregistré en définissant un indicateur ou un statut spécifique.
Pourquoi c'est important Le suivi de cet indicateur permet de mesurer la rapidité du rétablissement du service, ce qui est crucial pour la satisfaction de l'utilisateur. Il distingue les solutions temporaires des résolutions permanentes dans l'analyse des processus. Où obtenir Cela peut être déduit de l'horodatage lorsque le champ 'Workaround' dans les détails de résolution de l'incident est renseigné ou lorsqu'un statut spécifique 'Solution de contournement fournie' est utilisé. Capture Utilisez le timestamp d'un changement de statut vers un état de « solution de contournement » ou lorsque les notes de résolution indiquant une solution de contournement sont enregistrées pour la première fois. Type d'événement inferred
	Confirmation Utilisateur Reçue	Représente le moment où l'utilisateur reconnaît que la solution fournie a résolu son problème. Il s'agit souvent d'une étape facultative qui peut être enregistrée via une action sur un portail ou par un agent.
Pourquoi c'est important L'analyse du taux et de la rapidité des confirmations des utilisateurs aide à évaluer l'efficacité de la communication et la qualité de la résolution. Un faible taux de confirmation pourrait entraîner un taux de réouverture plus élevé. Où obtenir Ceci est difficile à capturer directement et peut nécessiter d'être déduit. Il pourrait s'agir d'un statut spécifique comme « Resolved - Confirmed » ou d'une note ajoutée au journal de travail d'incident. Capture Nécessite une analyse système. Recherchez les entrées de journal de travail ou les changements de statut indiquant les retours d'utilisateurs. Type d'événement inferred
	Enquête initiée	Indique qu’un agent affecté a commencé à travailler activement sur l’incident. Cela se traduit souvent par un changement d’état de 'Assigned' à 'In Progress' ou un état similaire.
Pourquoi c'est important Mesurer le temps entre l'affectation et le début de l'enquête révèle les retards d'attente et aide à évaluer la réactivité des agents et la capacité de charge de travail. Où obtenir Ceci est déduit d'un changement dans le champ « Status », passant de « Assigned » à « In Progress ». L'horodatage de ce changement de statut est enregistré dans le journal d'audit. Capture Filtrez les journaux d'audit pour le premier changement de statut à 'In Progress' après une affectation. Type d'événement inferred
	Incident catégorisé	Représente la classification initiale de l'incident, incluant la définition de sa catégorie, de son type et de son élément. Cette activité est généralement effectuée par un agent de service desk de Niveau 1 peu de temps après le signalement de l'incident.
Pourquoi c'est important Le suivi de cette activité permet d'analyser la précision des classifications initiales et leur impact sur l'acheminement et la résolution. Les modifications de la catégorisation plus tard dans le processus indiquent des reprises et des lacunes potentielles en matière de connaissances. Où obtenir Déduit de la première fois où les champs de catégorisation opérationnelle et de produit ('OpCat', 'ProdCat') sont renseignés dans le journal d’audit de l’incident (HPD:HelpDesk_AuditLogSystem). Capture Identifier le premier horodatage où les champs de catégorisation sont renseignés dans le journal d’audit. Type d'événement inferred
	Incident mis en attente	Cette activité se produit lorsque la progression d'un incident est mise en pause, généralement en attente d'informations de l'utilisateur ou d'un fournisseur externe. Cela se reflète habituellement par un changement de statut vers 'En attente'.
Pourquoi c'est important Cette activité est cruciale pour calculer précisément les temps de résolution. Le temps passé en état 'En attente' doit souvent être exclu des calculs SLA pour mesurer équitablement la performance de l'équipe de support. Où obtenir Déduit d’un changement du champ 'Status' vers un état 'Pending'. Le journal d’audit enregistre l’horodatage de ce changement. Capture Filtrez les journaux d'audit pour les changements de statut vers 'Pending' ou un statut similaire en attente. Type d'événement inferred
	Incident rouvert	Se produit lorsqu'un incident précédemment résolu ou fermé est ramené à un état actif. Cela arrive généralement lorsque l'utilisateur signale que le problème a réapparu.
Pourquoi c'est important Un taux de réouverture élevé indique des problèmes avec la qualité des résolutions. Le suivi de cette boucle de retravail est essentiel pour identifier les causes profondes des correctifs inefficaces et améliorer la résolution au premier contact. Où obtenir Déduit d’un changement d’état de 'Resolved' ou 'Closed' vers un état actif comme 'In Progress' ou 'Assigned'. Cette transition est consignée dans l’historique d’audit. Capture Filtrez les journaux d'audit pour un changement de statut d'un état résolu/fermé à un état ouvert. Type d'événement inferred
	Statut en attente repris	Marque le moment où un incident en attente est réactivé. Cela se produit lorsque les informations requises sont reçues, et se traduit généralement par un changement de statut de 'En attente' (Pending) à 'En cours' (In Progress).
Pourquoi c'est important Cet événement, associé à 'Incident mis en attente', permet la mesure précise des temps d'attente. L'analyse des longs temps d'attente peut mettre en évidence des problèmes de communication avec les utilisateurs ou les tiers. Où obtenir Déduit d’un changement d’état de 'Pending' vers un état actif comme 'In Progress'. L’horodatage est disponible dans le journal d’audit. Capture Filtrez les journaux d'audit pour un changement de statut de 'Pending' à 'In Progress' ou 'Assigned'. Type d'événement inferred
	Transféré à un Autre Groupe	Représente la réaffectation d'un incident d'un groupe de support à un autre. Cela se produit généralement lorsque le groupe initial ne peut pas résoudre le problème et nécessite l'expertise d'une équipe différente.
Pourquoi c'est important Les transferts fréquents, ou le « ping-pong », sont une source majeure de retard et d'inefficience. L'analyse de ces activités aide à identifier les problèmes de routage, les lacunes en compétences et les goulots d'étranglement des processus. Où obtenir Déduit d’une modification de la valeur du champ 'Assigned Group' dans l’historique d’audit de l’incident, postérieure à l’affectation initiale. Capture Chaque modification du champ 'Assigned Group' dans le journal d'audit après la première affectation représente un transfert. Type d'événement inferred
	Violation de SLA détectée	Un événement calculé qui se produit lorsque le temps de réponse ou de résolution d'un incident dépasse les cibles définies dans son accord de niveau de service (SLA). Ce n'est pas un événement système direct.
Pourquoi c'est important Identifier les violations de SLA est essentiel pour le suivi de la conformité et la priorisation des incidents critiques. Cela permet de déterminer quelles étapes du processus contribuent le plus à ces violations. Où obtenir Cet événement est calculé en comparant l'horodatage de l'activité 'Incident résolu' (ou d'autres jalons SLA) à la 'Date de signalement' et à l'objectif SLA défini pour la priorité de cet incident. Capture Dérivé en comparant le timestamp de résolution au timestamp de début plus la durée du SLA. Type d'événement calculated

Recommandé Facultatif

Guides d'extraction

Comment récupérer vos données à partir de BMC Helix

Étapes

Obtenir l'accès à la base de données : Obtenez des identifiants en lecture seule pour la base de données SQL sous-jacente du système Bmc Helix AR (Oracle ou MS SQL Server). Vous aurez besoin du nom d'hôte du serveur, du nom de la base de données, du nom d'utilisateur et du mot de passe.
Identifier les tables clés : Connectez-vous à la base de données à l'aide d'un client comme DBeaver ou SQL Server Management Studio. Vérifiez les noms exacts des tables clés. La requête utilise des noms courants comme HPD_Help_Desk, HPD_Help_Desk_AuditLogSystem, HPD_Assignment_Log et SLM_Measurement, mais le schéma de votre système peut présenter de légères variations (par exemple, un préfixe de schéma différent comme ARADMIN).
Examiner la requête SQL : Examinez la requête SQL fournie. Elle est structurée pour extraire chacune des 14 activités requises en tant qu'événement distinct à l'aide d'une structure UNION ALL. Chaque bloc SELECT est conçu pour capturer un moment spécifique du cycle de vie de l'incident.
Configurer les paramètres de la requête : Modifiez les paramètres de la requête. Définissez la plage de dates en remplaçant '{start_date}' et '{end_date}' par votre période d'analyse souhaitée (par exemple, '2023-01-01'). Si nécessaire, filtrez pour une entreprise spécifique en remplaçant '[Your Company Name]' dans la clause WHERE du CTE BaseIncidents.
Exécuter la requête : Exécutez la requête SQL complète sur la base de données du système AR. Le temps d'exécution peut varier en fonction de la plage de dates et du volume de données d'incidents.
Inspecter les résultats : Passez brièvement en revue la sortie pour vous assurer qu'elle contient les colonnes attendues (IncidentId, ActivityName, EventTimestamp, etc.) et que les données semblent être correctement renseignées.
Exporter le journal d'événements : Exportez les résultats de la requête vers un fichier CSV. Assurez-vous que l'encodage du fichier est UTF-8 sans BOM, ce qui est le format standard pour l'ingestion par ProcessMind.
Préparer le téléchargement : Confirmez que le fichier CSV contient les bons en-têtes correspondant aux attributs définis dans la requête. Le fichier est maintenant prêt à être téléchargé sur ProcessMind en tant que journal d'événements.

Configuration

Database Credentials : Un utilisateur de base de données en lecture seule est nécessaire afin d'éviter toute modification accidentelle des données de production. L'accès doit être accordé au schéma AR System, qui contient des tables comme HPD_Help_Desk.
Table and Schema Names : La requête fournie suppose un schéma Bmc Helix standard. Vous devrez peut-être ajuster les préfixes de table (par exemple, dbo.HPD_Help_Desk) ou les noms de table en fonction de votre implémentation spécifique.
Date Range : Il est crucial de filtrer la requête sur une plage de dates spécifique afin de gérer le volume de données et d'assurer une exécution efficace. Une période de 3 à 6 mois de données est généralement recommandée pour une analyse initiale. Cette configuration se fait dans la clause WHERE de l'expression de table commune BaseIncidents.
Company Filter : Pour les environnements Bmc Helix multi-locataires, le filtrage par le champ 'Company' est essentiel pour isoler les données d'une seule unité commerciale. Ce filtre se trouve également dans le CTE BaseIncidents.
Status Mappings : La requête utilise une instruction CASE afin de mapper les codes de statut numériques à des noms lisibles par l'homme (par exemple, 4 = 'Resolved'). Vérifiez que ces mappages correspondent aux valeurs d'énumération de statut configurées dans votre système.
Performance Considerations : Les requêtes directes à la base de données, en particulier celles impliquant de grandes tables d'audit et de journaux, peuvent être gourmandes en ressources. Il est fortement recommandé d'effectuer les extractions importantes pendant les heures creuses afin de minimiser tout impact potentiel sur l'application en direct.

a Exemple de requête sql

WITH BaseIncidents AS (
    SELECT 
        hpd.Incident_Number AS IncidentId,
        hpd.Submit_Date,
        hpd.Last_Resolved_Date,
        hpd.Closed_Date,
        hpd.Company,
        hpd.Description,
        hpd.Categorization_Tier_1, 
        hpd.Categorization_Tier_2, 
        hpd.Categorization_Tier_3,
        hpd.Priority,
        hpd.Urgency AS Severity, -- Using Urgency as Severity is a common practice
        hpd.Assigned_Group,
        hpd.Assignee,
        hpd.Status
    FROM HPD_Help_Desk hpd
    WHERE hpd.Submit_Date >= '{start_date}' AND hpd.Submit_Date < '{end_date}'
    -- Optional: Filter by a specific company if needed
    -- AND hpd.Company = '[Your Company Name]'
)
-- 1. Incident Reported
SELECT 
    bi.IncidentId AS IncidentId,
    'Incident Reported' AS ActivityName,
    DATEADD(s, bi.Submit_Date, '1970-01-01') AS EventTimestamp,
    'Bmc Helix' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    'New' AS IncidentStatus,
    bi.Priority,
    bi.Severity,
    bi.Assigned_Group AS AssignedSupportGroup,
    bi.Assignee AS AssignedAgent,
    bi.Categorization_Tier_1 + ' / ' + bi.Categorization_Tier_2 + ' / ' + bi.Categorization_Tier_3 AS IncidentCategory,
    NULL AS SLAStatus
FROM BaseIncidents bi
UNION ALL
-- 2. Incident Categorized (approximated at submission time)
SELECT 
    bi.IncidentId AS IncidentId,
    'Incident Categorized' AS ActivityName,
    DATEADD(s, bi.Submit_Date + 1, '1970-01-01') AS EventTimestamp, -- Adding 1 second to ensure order
    'Bmc Helix' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    'New' AS IncidentStatus,
    bi.Priority,
    bi.Severity,
    bi.Assigned_Group AS AssignedSupportGroup,
    bi.Assignee AS AssignedAgent,
    bi.Categorization_Tier_1 + ' / ' + bi.Categorization_Tier_2 + ' / ' + bi.Categorization_Tier_3 AS IncidentCategory,
    NULL AS SLAStatus
FROM BaseIncidents bi
UNION ALL
-- 3. Assigned to Support Group (first assignment)
SELECT
    log.Incident_Number,
    'Assigned to Support Group' AS ActivityName,
    DATEADD(s, log.Assignment_Date, '1970-01-01') AS EventTimestamp,
    'Bmc Helix' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    'Assigned' AS IncidentStatus,
    bi.Priority,
    bi.Severity,
    log.Assigned_Group AS AssignedSupportGroup,
    log.Assignee AS AssignedAgent,
    bi.Categorization_Tier_1 + ' / ' + bi.Categorization_Tier_2 + ' / ' + bi.Categorization_Tier_3 AS IncidentCategory,
    NULL AS SLAStatus
FROM HPD_Assignment_Log log
JOIN BaseIncidents bi ON log.Incident_Number = bi.IncidentId
WHERE log.Request_Type = 'Assignee'
AND log.Assignment_Date = (SELECT MIN(sub.Assignment_Date) FROM HPD_Assignment_Log sub WHERE sub.Incident_Number = log.Incident_Number AND sub.Request_Type = 'Assignee')
UNION ALL
-- 4. Investigation Started (Status moves to 'In Progress')
SELECT 
    bi.IncidentId,
    'Investigation Started' AS ActivityName,
    DATEADD(s, al.Log_Date, '1970-01-01') AS EventTimestamp,
    'Bmc Helix' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    'In Progress' AS IncidentStatus,
    bi.Priority,
    bi.Severity,
    bi.Assigned_Group AS AssignedSupportGroup,
    bi.Assignee AS AssignedAgent,
    bi.Categorization_Tier_1 + ' / ' + bi.Categorization_Tier_2 + ' / ' + bi.Categorization_Tier_3 AS IncidentCategory,
    NULL AS SLAStatus
FROM HPD_Help_Desk_AuditLogSystem al
JOIN BaseIncidents bi ON al.Original_Request_ID = bi.IncidentId
WHERE al.Fields_Changed LIKE '%Status%' AND al.New_Value_of_Field = '2' -- 2 = In Progress
AND al.Log_Date = (SELECT MIN(sub.Log_Date) FROM HPD_Help_Desk_AuditLogSystem sub WHERE sub.Original_Request_ID = al.Original_Request_ID AND sub.Fields_Changed LIKE '%Status%' AND sub.New_Value_of_Field = '2')
UNION ALL
-- 5. Transferred to Another Group (subsequent assignments)
SELECT
    log.Incident_Number,
    'Transferred to Another Group' AS ActivityName,
    DATEADD(s, log.Assignment_Date, '1970-01-01') AS EventTimestamp,
    'Bmc Helix' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    'Assigned' AS IncidentStatus,
    bi.Priority,
    bi.Severity,
    log.Assigned_Group AS AssignedSupportGroup,
    log.Assignee AS AssignedAgent,
    bi.Categorization_Tier_1 + ' / ' + bi.Categorization_Tier_2 + ' / ' + bi.Categorization_Tier_3 AS IncidentCategory,
    NULL AS SLAStatus
FROM HPD_Assignment_Log log
JOIN BaseIncidents bi ON log.Incident_Number = bi.IncidentId
WHERE log.Request_Type = 'Assignee'
AND log.Assignment_Date > (SELECT MIN(sub.Assignment_Date) FROM HPD_Assignment_Log sub WHERE sub.Incident_Number = log.Incident_Number AND sub.Request_Type = 'Assignee')
UNION ALL
-- 6. Workaround Implemented (Using status reason as an indicator, may need adjustment)
SELECT 
    bi.IncidentId,
    'Workaround Implemented' AS ActivityName,
    DATEADD(s, al.Log_Date, '1970-01-01') AS EventTimestamp,
    'Bmc Helix' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    'Pending' AS IncidentStatus, -- Often associated with a Pending status
    bi.Priority,
    bi.Severity,
    bi.Assigned_Group AS AssignedSupportGroup,
    bi.Assignee AS AssignedAgent,
    bi.Categorization_Tier_1 + ' / ' + bi.Categorization_Tier_2 + ' / ' + bi.Categorization_Tier_3 AS IncidentCategory,
    NULL AS SLAStatus
FROM HPD_Help_Desk_AuditLogSystem al
JOIN BaseIncidents bi ON al.Original_Request_ID = bi.IncidentId
WHERE al.Fields_Changed LIKE '%Status_Reason%' AND al.New_Value_of_Field LIKE '%Workaround%'
UNION ALL
-- 7. Incident Put On Hold (Status moves to 'Pending')
SELECT 
    bi.IncidentId,
    'Incident Put On Hold' AS ActivityName,
    DATEADD(s, al.Log_Date, '1970-01-01') AS EventTimestamp,
    'Bmc Helix' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    'Pending' AS IncidentStatus,
    bi.Priority,
    bi.Severity,
    bi.Assigned_Group AS AssignedSupportGroup,
    bi.Assignee AS AssignedAgent,
    bi.Categorization_Tier_1 + ' / ' + bi.Categorization_Tier_2 + ' / ' + bi.Categorization_Tier_3 AS IncidentCategory,
    NULL AS SLAStatus
FROM HPD_Help_Desk_AuditLogSystem al
JOIN BaseIncidents bi ON al.Original_Request_ID = bi.IncidentId
WHERE al.Fields_Changed LIKE '%Status%' AND al.New_Value_of_Field = '3' -- 3 = Pending
UNION ALL
-- 8. Pending Status Resumed (Status moves from 'Pending' back to 'In Progress')
SELECT 
    bi.IncidentId,
    'Pending Status Resumed' AS ActivityName,
    DATEADD(s, al.Log_Date, '1970-01-01') AS EventTimestamp,
    'Bmc Helix' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    'In Progress' AS IncidentStatus,
    bi.Priority,
    bi.Severity,
    bi.Assigned_Group AS AssignedSupportGroup,
    bi.Assignee AS AssignedAgent,
    bi.Categorization_Tier_1 + ' / ' + bi.Categorization_Tier_2 + ' / ' + bi.Categorization_Tier_3 AS IncidentCategory,
    NULL AS SLAStatus
FROM HPD_Help_Desk_AuditLogSystem al
JOIN BaseIncidents bi ON al.Original_Request_ID = bi.IncidentId
WHERE al.Fields_Changed LIKE '%Status%' AND al.New_Value_of_Field = '2' AND al.Old_Value_of_Field = '3' -- 2 = In Progress, 3 = Pending
UNION ALL
-- 9. Resolution Identified (Using Last_Resolved_Date)
SELECT 
    bi.IncidentId,
    'Resolution Identified' AS ActivityName,
    DATEADD(s, bi.Last_Resolved_Date, '1970-01-01') AS EventTimestamp,
    'Bmc Helix' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    'Resolved' AS IncidentStatus,
    bi.Priority,
    bi.Severity,
    bi.Assigned_Group AS AssignedSupportGroup,
    bi.Assignee AS AssignedAgent,
    bi.Categorization_Tier_1 + ' / ' + bi.Categorization_Tier_2 + ' / ' + bi.Categorization_Tier_3 AS IncidentCategory,
    NULL AS SLAStatus
FROM BaseIncidents bi
WHERE bi.Last_Resolved_Date IS NOT NULL
UNION ALL
-- 10. Incident Resolved (Status moves to 'Resolved')
SELECT 
    bi.IncidentId,
    'Incident Resolved' AS ActivityName,
    DATEADD(s, bi.Last_Resolved_Date, '1970-01-01') AS EventTimestamp,
    'Bmc Helix' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    'Resolved' AS IncidentStatus,
    bi.Priority,
    bi.Severity,
    bi.Assigned_Group AS AssignedSupportGroup,
    bi.Assignee AS AssignedAgent,
    bi.Categorization_Tier_1 + ' / ' + bi.Categorization_Tier_2 + ' / ' + bi.Categorization_Tier_3 AS IncidentCategory,
    NULL AS SLAStatus
FROM BaseIncidents bi
WHERE bi.Last_Resolved_Date IS NOT NULL
UNION ALL
-- 11. User Confirmation Received (Approximated as Closed Date)
SELECT 
    bi.IncidentId,
    'User Confirmation Received' AS ActivityName,
    DATEADD(s, bi.Closed_Date - 1, '1970-01-01') AS EventTimestamp, -- 1 second before closure
    'Bmc Helix' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    'Closed' AS IncidentStatus,
    bi.Priority,
    bi.Severity,
    bi.Assigned_Group AS AssignedSupportGroup,
    bi.Assignee AS AssignedAgent,
    bi.Categorization_Tier_1 + ' / ' + bi.Categorization_Tier_2 + ' / ' + bi.Categorization_Tier_3 AS IncidentCategory,
    NULL AS SLAStatus
FROM BaseIncidents bi
WHERE bi.Closed_Date IS NOT NULL AND bi.Last_Resolved_Date IS NOT NULL AND bi.Status = 5
UNION ALL
-- 12. Incident Reopened
SELECT 
    bi.IncidentId,
    'Incident Reopened' AS ActivityName,
    DATEADD(s, al.Log_Date, '1970-01-01') AS EventTimestamp,
    'Bmc Helix' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    'In Progress' AS IncidentStatus,
    bi.Priority,
    bi.Severity,
    bi.Assigned_Group AS AssignedSupportGroup,
    bi.Assignee AS AssignedAgent,
    bi.Categorization_Tier_1 + ' / ' + bi.Categorization_Tier_2 + ' / ' + bi.Categorization_Tier_3 AS IncidentCategory,
    NULL AS SLAStatus
FROM HPD_Help_Desk_AuditLogSystem al
JOIN BaseIncidents bi ON al.Original_Request_ID = bi.IncidentId
WHERE al.Fields_Changed LIKE '%Status%' AND al.New_Value_of_Field IN ('1', '2') AND al.Old_Value_of_Field IN ('4', '5') -- From Resolved/Closed to Assigned/In Progress
UNION ALL
-- 13. SLA Breach Detected
SELECT 
    bi.IncidentId,
    'SLA Breach Detected' AS ActivityName,
    DATEADD(s, slm.OverallStopTime, '1970-01-01') AS EventTimestamp,
    'Bmc Helix' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    CASE bi.Status WHEN 4 THEN 'Resolved' WHEN 5 THEN 'Closed' ELSE 'In Progress' END AS IncidentStatus,
    bi.Priority,
    bi.Severity,
    bi.Assigned_Group AS AssignedSupportGroup,
    bi.Assignee AS AssignedAgent,
    bi.Categorization_Tier_1 + ' / ' + bi.Categorization_Tier_2 + ' / ' + bi.Categorization_Tier_3 AS IncidentCategory,
    'Breached' AS SLAStatus
FROM SLM_Measurement slm
JOIN BaseIncidents bi ON slm.ApplicationUserFriendlyID = bi.IncidentId
WHERE slm.GoalStatus = 4 -- 4 = Missed
UNION ALL
-- 14. Incident Closed
SELECT 
    bi.IncidentId,
    'Incident Closed' AS ActivityName,
    DATEADD(s, bi.Closed_Date, '1970-01-01') AS EventTimestamp,
    'Bmc Helix' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    'Closed' AS IncidentStatus,
    bi.Priority,
    bi.Severity,
    bi.Assigned_Group AS AssignedSupportGroup,
    bi.Assignee AS AssignedAgent,
    bi.Categorization_Tier_1 + ' / ' + bi.Categorization_Tier_2 + ' / ' + bi.Categorization_Tier_3 AS IncidentCategory,
    NULL AS SLAStatus
FROM BaseIncidents bi
WHERE bi.Closed_Date IS NOT NULL AND bi.Status = 5
ORDER BY IncidentId, EventTimestamp;

Étapes

Prérequis : Assurez-vous que Python 3.6+ est installé sur votre système. Vous aurez également besoin d'identifiants pour un compte utilisateur BMC Helix avec au moins un accès en lecture aux formulaires HPD:Help Desk et HPD:HelpDesk_AuditLogSystem via l'API REST.
Installer les bibliothèques Python : Ouvrez votre terminal ou invite de commande et installez les bibliothèques requests et pandas, nécessaires pour les appels API et le traitement des données. Exécutez la commande : pip install requests pandas.
Configurer le script : Enregistrez le code Python fourni dans un fichier nommé extract_incidents.py. Ouvrez ce fichier dans un éditeur et mettez à jour les variables en haut : HELIX_URL, HELIX_USER, HELIX_PASSWORD, START_DATE et END_DATE avec les détails spécifiques de votre environnement et la plage de dates souhaitée.
Authentification : Le script s'authentifie d'abord auprès de l'API BMC Helix. Il envoie une requête POST au point de terminaison /api/jwt/login avec les identifiants fournis pour obtenir un JSON Web Token (JWT). Ce jeton est ensuite inclus dans l'en-tête de toutes les requêtes de données ultérieures.
Récupérer les données d'incident : Le script interroge le formulaire HPD:Help Desk pour récupérer une liste de tous les incidents créés dans la plage de dates spécifiée. Cette requête initiale recueille les attributs principaux pour chaque incident et crée l'événement 'Incident signalé', qui est le point de départ de chaque cas.
Récupérer les données du journal d'audit : Pour chaque incident récupéré à l'étape précédente, le script effectue un deuxième appel API au formulaire HPD:HelpDesk_AuditLogSystem. Ce formulaire contient l'historique détaillé des modifications pour chaque incident, telles que les changements de statut, les réaffectations de groupe et les mises à jour de priorité.
Mapper les événements d'audit aux activités : Le script itère sur les entrées du journal d'audit pour chaque incident. Il utilise une série de vérifications logiques pour mapper les changements de champ bruts aux activités métier requises. Par exemple, un changement dans le champ Status de 'Assigned' à 'In Progress' est traduit en une activité 'Investigation lancée'.
Gérer les activités spéciales et calculées : Le script inclut une logique spécifique pour dériver des activités qui ne sont pas de simples changements de champ. 'Violation de SLA détectée' est créée en comparant la Last Resolved Date à la Target Date. 'Incident rouvert' est généré lorsque le statut passe de 'Resolved' ou 'Closed' à un état actif.
Structurer le journal d'événements : Au fur et à mesure que le script traite chaque incident et son historique d'audit, il construit une liste d'événements. Chaque événement est un dictionnaire contenant tous les attributs requis et recommandés (IncidentId, ActivityName, EventTimestamp, etc.).
Exécuter l'extraction : Exécutez le script depuis votre terminal en utilisant la commande : python extract_incidents.py. Le script affichera les mises à jour de progression sur la console au fur et à mesure qu'il récupère et traite les données.
Exporter vers CSV : Une fois le script terminé, il enregistrera le journal d'événements final sous forme de fichier CSV nommé bmc_helix_incident_event_log.csv dans le même répertoire. Ce fichier est formaté pour un téléchargement direct dans un outil de Process Mining.

Configuration

HELIX_URL : L'URL de base de votre API REST BMC Helix. Par exemple, https://[votre-tenant].onbmc.com.
HELIX_USER / HELIX_PASSWORD : Identifiants pour un compte de service ou un utilisateur disposant des autorisations d'accès à l'API pour les formulaires de gestion des incidents.
START_DATE / END_DATE : La plage de dates pour l'extraction, au format 'YYYY-MM-DD'. Il est recommandé de commencer par une plage plus petite, par exemple 3 à 6 mois, afin de gérer le volume et la durée de l'extraction.
INCIDENT_QUERY_FIELDS : Une liste de champs à récupérer du formulaire principal HPD:Help Desk. Cela peut être personnalisé pour inclure des attributs supplémentaires pertinents pour votre analyse.
PAGE_SIZE : Cette variable contrôle le nombre d'incidents récupérés par appel API afin d'éviter les délais d'attente et de gérer l'utilisation de la mémoire. Une valeur entre 500 et 1000 est généralement efficace.
q (Query Qualification) : Le script construit une chaîne de qualification de requête pour filtrer les incidents par leur Submit Date. Vous pouvez étendre cette requête pour ajouter d'autres filtres, tels que AND 'Company' = "[Votre Nom de Société]" afin de limiter la portée de l'extraction.

a Exemple de requête python

import requests
import pandas as pd
from datetime import datetime

class=class="hl-string">"hl-comment"># --- Configuration Settings --- 
class=class="hl-string">"hl-comment"># Replace with your BMC Helix environment details
HELIX_URL = class="hl-string">"https://[your-tenant].onbmc.com"
HELIX_USER = class="hl-string">"[YOUR_USERNAME]"
HELIX_PASSWORD = class="hl-string">"[YOUR_PASSWORD]"

class=class="hl-string">"hl-comment"># Define the date range for the extraction (YYYY-MM-DD)
START_DATE = class="hl-string">"[START_DATE]" class=class="hl-string">"hl-comment"># Example: class="hl-string">"2023-01-01"
END_DATE = class="hl-string">"[END_DATE]"     class=class="hl-string">"hl-comment"># Example: class="hl-string">"2023-06-30"

class=class="hl-string">"hl-comment"># Fields to retrieve from the main Incident form
INCIDENT_QUERY_FIELDS = (
    class="hl-string">"'Incident Number', 'Submitter', 'Submit Date', 'Status', 'Status_Reason', "
    class="hl-string">"'Priority', 'Urgency', 'Impact', 'Service Type', 'Assigned Group', 'Assignee', "
    class="hl-string">"'Last Resolved Date', 'Closed Date', 'Company', 'Description', 'Target Date'"
)

PAGE_SIZE = 1000

class=class="hl-string">"hl-comment"># --- Main Script --- 

def get_jwt_token(session, base_url, user, password):
    class="hl-string">"""Authenticates with the API and returns a JWT token."""
    login_url = fclass="hl-string">"{base_url}/api/jwt/login"
    auth_data = {class="hl-string">"username": user, class="hl-string">"password": password}
    try:
        response = session.post(login_url, data=auth_data, headers={class="hl-string">'Content-Type': class="hl-string">'application/x-www-form-urlencoded'})
        response.raise_for_status()
        return response.text
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Error during authentication: {e}")
        return None

def fetch_paginated_data(session, url, params):
    class="hl-string">"""Fetches all pages of data from a given endpoint."""
    all_entries = []
    start_index = 0
    while True:
        params[class="hl-string">'offset'] = start_index
        response = session.get(url, params=params)
        response.raise_for_status()
        data = response.json()
        entries = data.get(class="hl-string">'entries', [])
        all_entries.extend(entries)
        if not entries or len(entries) < params.get(class="hl-string">'limit', PAGE_SIZE):
            break
        start_index += len(entries)
    return all_entries

def map_audit_log_to_activity(log_entry, prev_values):
    class="hl-string">"""Maps audit log changes to specific activity names."""
    fields_changed = log_entry[class="hl-string">'values'].get(class="hl-string">'Fields Changed', class="hl-string">'')
    log_date = datetime.fromisoformat(log_entry[class="hl-string">'values'][class="hl-string">'Log Date'].replace(class="hl-string">'Z', class="hl-string">'+00:00')).isoformat()
    
    class=class="hl-string">"hl-comment"># Status changes
    if class="hl-string">'Status' in fields_changed:
        new_status = log_entry[class="hl-string">'values'].get(class="hl-string">'Status', class="hl-string">'')
        prev_status = prev_values.get(class="hl-string">'Status', class="hl-string">'')
        if prev_status == class="hl-string">'Assigned' and new_status == class="hl-string">'In Progress': return {class="hl-string">'ActivityName': class="hl-string">'Investigation Started', class="hl-string">'Timestamp': log_date}
        if prev_status == class="hl-string">'Pending' and new_status == class="hl-string">'In Progress': return {class="hl-string">'ActivityName': class="hl-string">'Pending Status Resumed', class="hl-string">'Timestamp': log_date}
        if new_status == class="hl-string">'Pending': return {class="hl-string">'ActivityName': class="hl-string">'Incident Put On Hold', class="hl-string">'Timestamp': log_date}
        if new_status == class="hl-string">'Resolved': return {class="hl-string">'ActivityName': class="hl-string">'Incident Resolved', class="hl-string">'Timestamp': log_date}
        if new_status == class="hl-string">'Closed': return {class="hl-string">'ActivityName': class="hl-string">'Incident Closed', class="hl-string">'Timestamp': log_date}
        if prev_status in [class="hl-string">'Resolved', class="hl-string">'Closed'] and new_status in [class="hl-string">'In Progress', class="hl-string">'Assigned']: return {class="hl-string">'ActivityName': class="hl-string">'Incident Reopened', class="hl-string">'Timestamp': log_date}
    
    class=class="hl-string">"hl-comment"># Assignment changes
    if class="hl-string">'Assigned Group' in fields_changed:
        new_group = log_entry[class="hl-string">'values'].get(class="hl-string">'Assigned Group')
        if prev_values.get(class="hl-string">'Assigned Group') is None and new_group is not None: return {class="hl-string">'ActivityName': class="hl-string">'Assigned to Support Group', class="hl-string">'Timestamp': log_date}
        if prev_values.get(class="hl-string">'Assigned Group') is not None and new_group is not None and prev_values.get(class="hl-string">'Assigned Group') != new_group:
            return {class="hl-string">'ActivityName': class="hl-string">'Transferred to Another Group', class="hl-string">'Timestamp': log_date}

    class=class="hl-string">"hl-comment"># Other specific activities
    if class="hl-string">'Service Type' in fields_changed or class="hl-string">'Categorization Tier 1' in fields_changed: return {class="hl-string">'ActivityName': class="hl-string">'Incident Categorized', class="hl-string">'Timestamp': log_date}
    if class="hl-string">'Status_Reason' in fields_changed and log_entry[class="hl-string">'values'].get(class="hl-string">'Status_Reason') == class="hl-string">'Solution Provided': return {class="hl-string">'ActivityName': class="hl-string">'Resolution Identified', class="hl-string">'Timestamp': log_date}
    if class="hl-string">'Status_Reason' in fields_changed and log_entry[class="hl-string">'values'].get(class="hl-string">'Status_Reason') == class="hl-string">'Customer Confirmation': return {class="hl-string">'ActivityName': class="hl-string">'User Confirmation Received', class="hl-string">'Timestamp': log_date}
    if class="hl-string">'z1D_WorkInfoType' in fields_changed and log_entry[class="hl-string">'values'].get(class="hl-string">'z1D_WorkInfoType') == class="hl-string">'Workaround': return {class="hl-string">'ActivityName': class="hl-string">'Workaround Implemented', class="hl-string">'Timestamp': log_date}

    return None

if __name__ == class="hl-string">"__main__":
    event_log = []
    session = requests.Session()

    class=class="hl-string">"hl-comment"># 1. Authenticate
    print(class="hl-string">"Authenticating with BMC Helix...")
    jwt_token = get_jwt_token(session, HELIX_URL, HELIX_USER, HELIX_PASSWORD)
    if not jwt_token:
        exit()
    session.headers.update({class="hl-string">'Authorization': fclass="hl-string">'AR-JWT {jwt_token}'})

    class=class="hl-string">"hl-comment"># 2. Fetch Incidents
    print(fclass="hl-string">"Fetching incidents from {START_DATE} to {END_DATE}...")
    incident_url = fclass="hl-string">"{HELIX_URL}/api/arsys/v1/entry/HPD:Help Desk"
    qualification = fclass="hl-string">"'Submit Date' >= \"{START_DATE}T00:00:00Z\class="hl-string">" AND 'Submit Date' <= \"{END_DATE}T23:59:59Z\class="hl-string">""
    params = {class="hl-string">'q': qualification, class="hl-string">'fields': fclass="hl-string">'values({INCIDENT_QUERY_FIELDS})', class="hl-string">'limit': PAGE_SIZE}

    try:
        incidents = fetch_paginated_data(session, incident_url, params)
        print(fclass="hl-string">"Found {len(incidents)} incidents.")

        class=class="hl-string">"hl-comment"># 3. Process each incident
        for i, incident in enumerate(incidents):
            vals = incident[class="hl-string">'values']
            incident_id = vals.get(class="hl-string">'Incident Number')
            if not incident_id:
                continue
            
            print(fclass="hl-string">"Processing Incident {i+1}/{len(incidents)}: {incident_id}")

            base_attributes = {
                class="hl-string">'IncidentId': incident_id,
                class="hl-string">'SourceSystem': class="hl-string">'Bmc Helix',
                class="hl-string">'LastDataUpdate': datetime.now().isoformat(),
                class="hl-string">'Priority': vals.get(class="hl-string">'Priority'),
                class="hl-string">'Severity': vals.get(class="hl-string">'Impact'),
                class="hl-string">'IncidentCategory': vals.get(class="hl-string">'Service Type')
            }
            
            class=class="hl-string">"hl-comment"># Activity: Incident Reported
            event_log.append({
                **base_attributes,
                class="hl-string">'ActivityName': class="hl-string">'Incident Reported',
                class="hl-string">'EventTimestamp': datetime.fromisoformat(vals[class="hl-string">'Submit Date'].replace(class="hl-string">'Z', class="hl-string">'+00:00')).isoformat(),
                class="hl-string">'IncidentStatus': class="hl-string">'New',
                class="hl-string">'AssignedSupportGroup': vals.get(class="hl-string">'Assigned Group'),
                class="hl-string">'AssignedAgent': vals.get(class="hl-string">'Assignee'),
                class="hl-string">'SLAStatus': class="hl-string">'In Progress'
            })

            class=class="hl-string">"hl-comment"># 4. Fetch Audit Log
            audit_url = fclass="hl-string">"{HELIX_URL}/api/arsys/v1/entry/HPD:HelpDesk_AuditLogSystem"
            audit_params = {
                class="hl-string">'q': fclass="hl-string">"'Incident Number' = \"{incident_id}\class="hl-string">"",
                class="hl-string">'fields': class="hl-string">"values(Log Date, Fields Changed, Status, Assigned Group, Status_Reason, z1D_WorkInfoType, Service Type, Categorization Tier 1)",
                class="hl-string">'sort': class="hl-string">'Log Date.asc'
            }
            audit_logs = fetch_paginated_data(session, audit_url, audit_params)

            class=class="hl-string">"hl-comment"># 5. Map audit log to activities
            current_values = {class="hl-string">'Status': class="hl-string">'New', class="hl-string">'Assigned Group': None}
            for log in audit_logs:
                activity_info = map_audit_log_to_activity(log, current_values)
                if activity_info:
                    event_log.append({
                        **base_attributes,
                        class="hl-string">'ActivityName': activity_info[class="hl-string">'ActivityName'],
                        class="hl-string">'EventTimestamp': activity_info[class="hl-string">'Timestamp'],
                        class="hl-string">'IncidentStatus': log[class="hl-string">'values'].get(class="hl-string">'Status', current_values[class="hl-string">'Status']),
                        class="hl-string">'AssignedSupportGroup': log[class="hl-string">'values'].get(class="hl-string">'Assigned Group', current_values.get(class="hl-string">'Assigned Group')),
                        class="hl-string">'AssignedAgent': None, class=class="hl-string">"hl-comment"># Assignee not typically in audit log
                        class="hl-string">'SLAStatus': class="hl-string">'In Progress' class=class="hl-string">"hl-comment"># Simplified
                    })
                class=class="hl-string">"hl-comment"># Update current values for next iteration
                current_values[class="hl-string">'Status'] = log[class="hl-string">'values'].get(class="hl-string">'Status', current_values[class="hl-string">'Status'])
                current_values[class="hl-string">'Assigned Group'] = log[class="hl-string">'values'].get(class="hl-string">'Assigned Group', current_values.get(class="hl-string">'Assigned Group'))

            class=class="hl-string">"hl-comment"># Activity: SLA Breach Detected (Calculated)
            resolved_date_str = vals.get(class="hl-string">'Last Resolved Date')
            target_date_str = vals.get(class="hl-string">'Target Date')
            if resolved_date_str and target_date_str:
                resolved_date = datetime.fromisoformat(resolved_date_str.replace(class="hl-string">'Z', class="hl-string">'+00:00'))
                target_date = datetime.fromisoformat(target_date_str.replace(class="hl-string">'Z', class="hl-string">'+00:00'))
                if resolved_date > target_date:
                     event_log.append({
                        **base_attributes,
                        class="hl-string">'ActivityName': class="hl-string">'SLA Breach Detected',
                        class="hl-string">'EventTimestamp': target_date.isoformat(),
                        class="hl-string">'IncidentStatus': vals.get(class="hl-string">'Status'),
                        class="hl-string">'AssignedSupportGroup': vals.get(class="hl-string">'Assigned Group'),
                        class="hl-string">'AssignedAgent': vals.get(class="hl-string">'Assignee'),
                        class="hl-string">'SLAStatus': class="hl-string">'Breached'
                    })

    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"An API error occurred: {e}")
    except Exception as e:
        print(fclass="hl-string">"An unexpected error occurred: {e}")

    class=class="hl-string">"hl-comment"># 6. Export to CSV
    if event_log:
        print(class="hl-string">"Exporting event log to CSV...")
        df = pd.DataFrame(event_log)
        df = df.sort_values(by=[class="hl-string">'IncidentId', class="hl-string">'EventTimestamp'])
        df.to_csv(class="hl-string">'bmc_helix_incident_event_log.csv', index=False)
        print(class="hl-string">"Extraction complete. File 'bmc_helix_incident_event_log.csv' created.")
    else:
        print(class="hl-string">"No events were generated.")

Template de données : Gestion des Incidents

Votre Template de Données de Gestion des Incidents

Attributs de gestion des incidents

Activités de gestion des incidents

Guides d'extraction

Requête SQL directe sur la base de données AR System sous-jacente

Étapes

Configuration

a Exemple de requête sql

Extraction par script Python via l'API REST BMC Helix

Étapes

Configuration

a Exemple de requête python

Prêt(e) à démarrer ?

Optimisez la Gestion des Incidents BMC Helix Dès Aujourd'hui !