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

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

BMC Helix ITSM

Attributs de gestion des incidents(21) Activités de gestion des incidents(14) Guides d’extraction(3)

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

Ce modèle vous guide dans la collecte des données essentielles à l’optimisation de votre processus de gestion des incidents. Il présente les attributs et les activités à suivre, ainsi que des conseils pratiques pour extraire ces données. Servez-vous de cette ressource pour préparer vos données plus simplement et commencer plus rapidement l’analyse de vos processus.

Attributs recommandés à collecter
Activités clés à suivre dans votre processus
Conseils pour extraire les données de votre système

Vous découvrez les journaux d’événements ? Découvrez comment créer un journal d’événements pour le Process Mining.

Télécharger le modèle

Attributs de gestion des incidents

Voici les champs de données recommandés à inclure dans votre journal d’événements pour analyser en détail votre processus de gestion des incidents.

3 Obligatoire 8 Recommandé 10 Facultatif

	Nom	Description
	ID de l’incident IncidentId	Identifiant unique de chaque fiche d’incident.
Description L’identifiant de l’incident est la clé principale de chaque incident. Il permet de l’identifier de sa création à sa clôture et relie toutes les activités, tous les journaux et tous les changements associés, pour donner une vue complète de son cycle de vie. En process mining, cet attribut est fondamental, car il définit le cas. Chaque événement portant le même identifiant d’incident est considéré comme faisant partie de la même instance de processus. Cela permet de reconstituer et d’analyser le traitement de chaque incident. Pourquoi est-ce important ? Cet identifiant de cas essentiel relie tous les événements du cycle de vie d’un incident et rend possible l’analyse du processus de bout en bout. Où trouver ces données Il s’agit du champ « Incident Number » (ID de champ : 1000000161) du formulaire « HPD:Help Desk ». Exemples INC000001234567INC000002345678INC000003456789
	Horodatage de l’événement EventTimestamp	Date et heure exactes auxquelles l’activité s’est produite.
Description Cet horodatage indique quand un événement précis du cycle de vie de l’incident s’est produit. Il fournit l’ordre chronologique nécessaire pour reconstituer le flux du processus à partir des données brutes. L’horodatage de l’événement est indispensable à toutes les analyses temporelles : calcul des temps de cycle entre les activités, repérage des goulots d’étranglement où les incidents restent longtemps en attente et mesure des délais de résolution globaux. Il constitue la base chronologique de l’analyse du processus. Pourquoi est-ce important ? Cet horodatage établit l’ordre chronologique des événements, indispensable pour calculer les durées, repérer les goulots d’étranglement et comprendre le déroulement du processus. Où trouver ces données Le champ « Last Modified Date » (ID de champ : 6) ou des champs de date spécifiques du formulaire « HPD:Help Desk ». Pour les événements historiques, l’horodatage provient du champ correspondant du journal d’audit. Exemples 2023-10-26T10:00:00Z2023-10-26T10:15:32Z2023-10-27T14:22:05Z
	Nom de l’activité ActivityName	Nom de l’événement ou de la tâche qui s’est produit à une étape précise du cycle de vie de l’incident.
Description Cet attribut décrit l’activité réalisée à un moment précis du traitement d’un incident, par exemple « Incident signalé », « Groupe attribué » ou « Incident résolu ». Ces activités constituent les éléments de base de la cartographie du processus. L’analyse de leur séquence et de leur fréquence révèle le flux réel du processus, fait ressortir les parcours courants et met en évidence les écarts par rapport à la procédure standard. Elle est essentielle pour comprendre les mesures prises afin de résoudre un incident. Pourquoi est-ce important ? Les activités définissent les étapes de la cartographie du processus et permettent de visualiser et d’analyser le flux de travail de gestion des incidents. Où trouver ces données Généralement déduit des modifications des champs « Status » (ID de champ : 7) et « Status_Reason » du formulaire « HPD:Help Desk », ou du formulaire « HPD:Help Desk Audit Log ». Exemples Incident signaléGroupe attribuéRésolution mise en œuvreIncident clôturé
	Catégorie d’incident IncidentCategory	La classification de l’incident, souvent organisée en plusieurs niveaux.
Description La catégorisation des incidents permet de les classer de manière structurée, généralement selon une hiérarchie à plusieurs niveaux (par exemple : niveau 1, matériel ; niveau 2, ordinateur portable ; niveau 3, batterie). Ces données sont essentielles pour l’acheminement, le reporting et l’analyse des tendances. En Process Mining, la catégorisation permet d’analyser séparément les différents types d’incidents. Elle alimente le Dashboard de précision de la catégorisation des incidents, qui compare les catégories initiales et finales, et aide à repérer les tendances dans le Dashboard des tendances des causes racines. Pourquoi est-ce important ? La catégorisation permet d’acheminer correctement les incidents, d’analyser les tendances et de comparer les performances selon leur type. Où trouver ces données Il s’agit des champs « Operational Categorization Tier 1/2/3 » dans le formulaire « HPD:Help Desk ». Exemples Matériel > Ordinateur portable > BatterieLogiciel > Application d’entreprise > Erreur de connexionRéseau > Connectivité > Wi-Fi
	Groupe affecté AssignedGroup	Le groupe d’assistance chargé de traiter l’incident.
Description Cet attribut indique l’équipe ou le service auquel l’incident est affecté, par exemple « Centre de services », « Équipe réseau » ou « Administrateurs de bases de données ». Le suivi des affectations permet de comprendre comment le travail circule entre les équipes. Cet attribut sert à analyser les transferts entre équipes, à repérer les goulots d’étranglement liés à certains groupes et à mesurer le taux de réaffectation des incidents. Il permet de visualiser le parcours d’un incident dans l’organisation et de repérer les problèmes d’acheminement ou les lacunes dans le partage des connaissances. Pourquoi est-ce important ? Le suivi du groupe affecté permet d’analyser les transferts, de repérer les boucles de réaffectation et d’identifier les goulots d’étranglement au sein de certaines équipes. Où trouver ces données Il s’agit du champ « Assigned Group » (ID du champ : 1000000217) dans le formulaire « HPD:Help Desk ». Exemples Centre de servicesOpérations réseauAssistance applicative, niveau 2Services d’infrastructure
	Incident rouvert IsReopened	Indique si un incident a été rouvert après avoir été marqué comme « Resolved ».
Description Cet attribut booléen prend la valeur true si le statut d’un incident repasse à un état actif, comme « In Progress », après avoir été marqué comme « Resolved ». Cela indique que la première correction n’était pas efficace ou complète. Cet attribut mesure directement les reprises et sert à calculer le taux de reprise des incidents. L’analyse des incidents rouverts permet de repérer les corrections de mauvaise qualité, les tests insuffisants ou les problèmes récurrents qui n’ont pas été correctement traités. Elle alimente le Dashboard des reprises et des parcours d’escalade. Pourquoi est-ce important ? Cet attribut mesure directement les reprises et la qualité des résolutions. Un taux élevé de réouverture signale des corrections inefficaces et des faiblesses dans le processus. Où trouver ces données Calculé à partir de la séquence d’activités d’un incident. Si une activité « Incident Reopened », ou équivalente, survient après une activité « Resolution Implemented », l’indicateur prend la valeur true. Exemples truefalse
	Personne affectée Assignee	La personne chargée de traiter l’incident.
Description La personne affectée est l’agent d’assistance ou le technicien chargé de l’incident à un moment donné. Cet attribut fournit un niveau de détail plus précis que le groupe affecté. L’analyse des performances par personne affectée peut aider à repérer les personnes les plus performantes, celles qui auraient besoin d’une formation complémentaire et les déséquilibres dans la répartition de la charge de travail. Elle permet également de retracer précisément les actions menées par chaque personne lors du traitement d’un incident complexe. Pourquoi est-ce important ? Cet attribut détaille la répartition de la charge de travail et les performances individuelles. Il aide à repérer les personnes les plus performantes et celles qui ont besoin d’assistance. Où trouver ces données Il s’agit du champ « Assignee » (ID du champ : 1000000218) dans le formulaire « HPD:Help Desk ». Exemples Bob SmithAlice JohnsonCharlie Brown
	Priorité Priority	Niveau de priorité attribué à l’incident, qui détermine l’urgence de son traitement.
Description La priorité est généralement déterminée en fonction de l’impact et de l’urgence. Elle définit l’ordre et la rapidité de résolution des incidents. Les valeurs courantes vont de « Critique » à « Faible ». En process mining, l’analyse des incidents par priorité est essentielle pour évaluer la performance. Elle permet de répondre à des questions telles que : « Respectons-nous les SLA pour les incidents hautement prioritaires ? » et « Les incidents peu prioritaires subissent-ils des retards plus longs ? ». Le filtrage par priorité permet de concentrer l’analyse sur les problèmes les plus importants pour l’organisation. Pourquoi est-ce important ? Cet attribut est essentiel pour segmenter les analyses, traiter plus rapidement les incidents prioritaires et respecter les objectifs de niveau de service qui leur sont associés. Où trouver ces données Il s’agit du champ « Priority » (ID du champ : 1000000164) dans le formulaire « HPD:Help Desk ». Exemples CritiqueÉlevéeMoyenneFaible
	Service Service	Le service métier ou technique touché par l’incident.
Description Cet attribut associe un incident à un service précis défini dans la base de données de gestion des configurations (CMDB), par exemple « Service de messagerie », « Accès VPN » ou « SAP Finance ». Cette association est essentielle pour comprendre les conséquences des incidents sur l’activité. L’analyse par service permet de repérer ceux qui génèrent un grand nombre d’incidents, de mettre en évidence les problèmes récurrents liés à certaines technologies et de suivre les tendances dans le cadre de la gestion des problèmes. Pourquoi est-ce important ? Associer les incidents aux services métier est essentiel pour analyser leur impact et repérer les services les plus souvent touchés par des problèmes. Où trouver ces données Il s’agit du champ « ServiceCI », ou d’un champ similaire représentant l’élément de configuration (CI) concerné dans le formulaire « HPD:Help Desk ». Exemples Messagerie d’entrepriseSAP ERPVPN d’accès à distancePortail des ressources humaines
	SLA dépassé IsSlaBreached	Indique si l’incident a été résolu après la date cible de son SLA.
Description Cet attribut booléen prend la valeur true si le délai de résolution de l’incident a dépassé le délai défini par son SLA. Il indique clairement, pour chaque incident, si les objectifs de niveau de service ont été respectés. Cet indicateur est essentiel à la création du Dashboard de suivi des performances du SLA des incidents et au calcul de l’indicateur de taux de conformité au SLA des incidents. Il simplifie l’analyse en permettant de filtrer et de regrouper directement les incidents qui n’ont pas respecté les objectifs de niveau de service, afin d’examiner les causes des dépassements. Pourquoi est-ce important ? Cet indicateur simplifie l’analyse du respect des SLA : vous pouvez filtrer les incidents dont le délai a été dépassé et en examiner les causes racines. Où trouver ces données Calculé en comparant l’horodatage de l’événement « Incident Resolved » à la valeur « SlaTargetDate ». Si l’horodatage de résolution est postérieur à la date cible, l’indicateur prend la valeur true. Exemples truefalse
	Statut de l’incident IncidentStatus	Statut actuel ou historique de l’incident au moment de l’événement.
Description Cet attribut indique l’état de l’incident, par exemple « New », « In Progress », « Pending », « Resolved » ou « Closed ». Il donne un aperçu de l’étape à laquelle se trouve l’incident dans son cycle de vie. L’analyse des changements de statut est fondamentale pour comprendre le processus de gestion des incidents. Elle permet de définir les activités, de mesurer le temps passé dans différents états, par exemple la durée pendant laquelle les incidents restent « Pending », et de repérer les incidents bloqués ou inactifs. Pourquoi est-ce important ? Le suivi des changements de statut est essentiel pour comprendre l’avancement d’un incident et mesurer le temps passé dans certains états, comme « Pending » ou « In Progress ». Où trouver ces données Il s’agit du champ « Status » (ID de champ : 7) du formulaire « HPD:Help Desk ». Exemples NouveauAttribuéEn coursEn attenteRésoluClôturé
	Canal Channel	Le moyen utilisé pour signaler l’incident.
Description Cet attribut indique comment l’incident a été signalé : par téléphone, par e-mail, via un portail en libre-service ou en personne, par exemple. Il précise par quel canal l’incident est entré dans le processus d’assistance. L’analyse des incidents par canal peut révéler les moyens de signalement les plus efficaces et ceux qui génèrent des incidents plus ou moins faciles à résoudre. Elle peut aussi orienter les investissements dans l’automatisation ou la formation des utilisateurs, par exemple en encourageant l’utilisation d’un portail en libre-service qui recueille des informations initiales plus complètes. Pourquoi est-ce important ? Connaître le canal de signalement permet de comparer l’efficacité des différents modes de prise en charge et d’orienter les investissements dans le libre-service ou l’automatisation. Où trouver ces données Il s’agit du champ « Reported Source » (ID du champ : 1000000215) dans le formulaire « HPD:Help Desk ». Exemples E-mailTéléphoneLibre-serviceSaisie directe
	Cause racine RootCause	La raison sous-jacente ou la cause profonde de l’incident.
Description La cause racine est le problème fondamental qui, s’il était corrigé, empêcherait l’incident de se reproduire. Elle est souvent déterminée dans le cadre de l’analyse d’un problème associé. Même si la cause racine n’est pas documentée pour tous les incidents, son analyse est essentielle à la gestion proactive des problèmes. Cet attribut alimente l’indicateur de taux d’identification des causes racines et permet de créer des Dashboards qui suivent les tendances des problèmes récurrents, afin d’orienter la mise en place de solutions définitives. Pourquoi est-ce important ? Identifier la cause racine est essentiel à la gestion des problèmes et aux analyses visant à réduire le nombre d’incidents récurrents. Où trouver ces données Cette information peut figurer dans un champ « Root Cause » dédié à l’incident ou, plus souvent, dans un formulaire associé « PBI:Problem Investigation ». Exemples Espace disque insuffisant sur le serveurErreur de configuration réseauBug logiciel dans la version 2.1Certificat de sécurité expiré
	Code de clôture CloseCode	Le code sélectionné à la clôture de l’incident indique le résultat de sa résolution.
Description Le code de clôture résume de manière structurée la façon dont l’incident a été résolu. Il peut s’agir, par exemple, de « Résolu par l’utilisateur », « Aucun problème détecté », « Incident en double » ou « Correctif définitif appliqué ». Cet attribut permet d’analyser l’efficacité et les résultats des résolutions. Il aide à repérer les incidents clôturés sans véritable correctif ou les catégories dans lesquelles les utilisateurs résolvent souvent eux-mêmes leurs problèmes. Ces constats peuvent indiquer qu’il serait utile de créer des articles de base de connaissances ou des outils en libre-service. Pourquoi est-ce important ? Cet attribut fournit des données structurées sur les résultats des résolutions. Il permet d’en évaluer l’efficacité et de repérer les tendances dans la clôture des incidents. Où trouver ces données Ce champ figure généralement dans les informations de résolution ou de clôture du formulaire « HPD:Help Desk ». Exemples Résolu à distanceProblème en doubleErreur de l’utilisateurAucune action requise
	Date cible du SLA SlaTargetDate	Date et heure auxquelles l’incident doit être résolu selon son SLA.
Description Cet attribut indique l’échéance de résolution de l’incident, définie par l’accord de niveau de service (SLA) applicable. Elle est calculée en fonction de la priorité de l’incident et des heures de service définies. Cet horodatage sert de référence pour mesurer le délai réel de résolution. Il est essentiel au calcul de l’indicateur de taux de conformité au SLA des incidents et à la création de Dashboards présentant les performances du SLA. Il permet de surveiller de manière proactive les incidents dont l’échéance approche. Pourquoi est-ce important ? Cette échéance sert de référence pour mesurer le respect du SLA. Elle permet de déterminer si l’incident a été résolu à temps ou si le délai prévu a été dépassé. Où trouver ces données Ces données sont généralement stockées dans le formulaire « SLM:Measurement » et associées à l’incident. Elles ne figurent pas directement dans le formulaire « HPD:Help Desk ». Exemples 2023-10-26T14:00:00Z2023-10-27T09:00:00Z2023-11-01T17:00:00Z
	Déclarant Submitter	La personne qui a signalé l’incident au départ.
Description Le déclarant est l’utilisateur final ou le client qui a rencontré le problème et l’a signalé. Il ne s’agit pas de la personne affectée, qui traite l’incident. L’analyse des données par déclarant ou par service peut aider à repérer les groupes d’utilisateurs qui auraient besoin d’une formation complémentaire ou qui sont touchés par un type de problème particulier. Elle offre une perspective centrée sur le client du processus de gestion des incidents. Pourquoi est-ce important ? Cet attribut identifie la personne qui a signalé le problème. Il permet d’analyser les tendances selon le service, le lieu ou le rôle des utilisateurs. Où trouver ces données Cette information figure dans le champ « Submitter » ou dans les champs relatifs aux coordonnées du client du formulaire « HPD:Help Desk ». Exemples John DoeJane SmithPeter Jones
	Dernière mise à jour des données LastDataUpdate	Horodatage indiquant la dernière actualisation des données de cet événement depuis le système source.
Description Cet attribut enregistre la date et l’heure de la dernière extraction des données. Il indique leur fraîcheur, un élément important pour savoir si les analyses du processus reflètent la situation actuelle. Connaître la date de la dernière mise à jour est essentiel pour les rapports et les Dashboards : les utilisateurs peuvent ainsi savoir de quand datent les données et comprendre si les activités les plus récentes des incidents y figurent. Pourquoi est-ce important ? Indique la fraîcheur des données, afin que les utilisateurs sachent dans quelle mesure l’analyse du processus et les résultats qui en découlent sont à jour. Où trouver ces données Cette valeur est généralement générée et ajoutée à l’ensemble de données lors du processus d’extraction (ETL). Exemples 2023-11-01T02:00:00Z2023-11-02T02:00:00Z2023-11-03T02:00:00Z
	Description de la résolution Resolution	Description en texte libre des étapes suivies pour résoudre l’incident.
Description Ce champ contient un compte rendu détaillé, rédigé par une personne, de la résolution finale. Il explique les mesures prises pour corriger le problème et rétablir le service pour l’utilisateur. Bien que ces données ne soient pas structurées, des techniques d’analyse de texte peuvent servir à repérer les méthodes de résolution courantes, à extraire des mots-clés liés à certains problèmes ou à compléter l’analyse des causes racines. Elles apportent un contexte qualitatif souvent absent des champs structurés. Pourquoi est-ce important ? Ce champ apporte des précisions qualitatives sur la résolution. L’analyse de texte peut révéler des tendances qui ne ressortent pas des données structurées. Où trouver ces données Il s’agit du champ « Resolution » (ID du champ : 1000000156) dans le formulaire « HPD:Help Desk ». Exemples Le mot de passe de l’utilisateur a été réinitialisé via Active Directory.Le cache et les cookies du navigateur ont été effacés, ce qui a résolu le problème de connexion.Le commutateur réseau de la salle de brassage 3B a été redémarré.
	Impact Impact	Mesure des effets de l’incident sur les processus métier.
Description L’impact mesure l’ampleur des conséquences négatives d’un incident sur l’activité. Il est souvent évalué sur une échelle, par exemple : « Étendu/généralisé », « Important/majeur », « Modéré/limité » ou « Mineur/localisé ». Combiné à l’urgence, l’impact détermine la priorité de l’incident. L’analyse par impact permet de comprendre quels incidents perturbent le plus l’activité, quelle que soit leur complexité technique. Elle est essentielle pour définir les priorités d’amélioration des processus. Pourquoi est-ce important ? Cet attribut permet d’évaluer la gravité d’un incident pour l’activité. Il contribue à déterminer sa priorité et à concentrer l’analyse sur les problèmes ayant le plus d’impact. Où trouver ces données Il s’agit du champ « Impact » (ID du champ : 1000000163) dans le formulaire « HPD:Help Desk ». Exemples 1-Étendu/généralisé2-Important/majeur3-Modéré/limité4-Mineur/localisé
	Nombre de réaffectations ReassignmentCount	Nombre total de fois où l’incident a été réaffecté à un autre groupe.
Description Cette métrique compte le nombre de changements du champ « AssignedGroup » au cours du cycle de vie de l’incident. Un nombre élevé peut signaler un problème d’acheminement initial, un faible taux de résolution dès le premier contact ou un incident complexe nécessitant l’intervention de plusieurs équipes. Cet attribut contribue directement au calcul de l’indicateur de taux de réaffectation des incidents et alimente le Dashboard d’analyse des cycles de réaffectation des incidents. Il permet de quantifier les allers-retours entre équipes, qui entraînent des retards importants et une baisse d’efficacité du processus. Pourquoi est-ce important ? Cet attribut quantifie les problèmes d’acheminement et les transferts inefficaces. Il aide à repérer les incidents pris dans des boucles de réaffectation entre équipes. Où trouver ces données Calculé en comptant le nombre de changements de la valeur « AssignedGroup » pour un ID d’incident donné dans le journal d’événements. Exemples 0135
	Système source SourceSystem	Système depuis lequel les données d’incident ont été extraites.
Description Cet attribut indique l’origine des données, ce qui est particulièrement utile dans les environnements qui utilisent plusieurs outils ITSM ou des systèmes intégrés. Il confirme que les données proviennent de la source attendue, par exemple d’une instance précise de BMC Helix ITSM. Dans le cadre de l’analyse, il permet de distinguer les processus ou les caractéristiques des données susceptibles de varier entre les systèmes de production, de développement ou hérités, et d’assurer une traçabilité claire et fiable des données. Pourquoi est-ce important ? Indique l’origine des données, ce qui est essentiel pour les valider et gérer les analyses portant sur plusieurs systèmes intégrés. Où trouver ces données Il s’agit généralement d’une valeur statique ajoutée lors du processus d’extraction, de transformation et de chargement des données (ETL). Exemples BMCHelixITSM_ProdITSM-EU-InstanceServiceManagement-APAC

Obligatoire Recommandé Facultatif

Activités de gestion des incidents

Voici les principales étapes et les jalons à consigner dans votre journal d’événements pour découvrir précisément le processus et en visualiser le déroulement.

5 Recommandé 9 Facultatif

	Activité	Description
	Début de l’investigation	Indique qu’un agent d’assistance a commencé à traiter activement l’incident. Cette activité est généralement déduite du passage du statut « Assigned » à « In Progress ».
Pourquoi est-ce important ? Cette étape marque le passage de l’attente dans une file à un diagnostic actif. L’analyse du délai avant le début de l’investigation permet de repérer les goulots d’étranglement liés aux ressources et d’alimenter le Dashboard « Goulots d’étranglement du diagnostic et de l’investigation ». Où trouver ces données Déduit d’un changement de statut dans le formulaire « HPD:Help Desk ». L’événement est déclenché lorsque le champ « Status » passe à « In Progress » ; l’horodatage provient du journal d’audit. Données à recueillir Déduit du passage au statut « In Progress » dans HPD:HelpDesk_AuditLogSystem. Type d’événement inferred
	Groupe attribué	Cette activité marque la première affectation de l’incident à un groupe d’assistance chargé de l’examiner. Elle est déduite du premier renseignement du champ « Assigned Group » après la création de l’incident.
Pourquoi est-ce important ? Cette étape clé marque le début du traitement actif. Le suivi du délai avant la première affectation est essentiel pour évaluer les temps de réponse et l’efficacité de l’orientation initiale. Où trouver ces données Déduit du journal d’audit (« HPD:HelpDesk_AuditLogSystem ») du formulaire « HPD:Help Desk », qui enregistre le premier renseignement du champ « Assigned Group ». Données à recueillir À partir de l’horodatage du premier renseignement du champ « Assigned Group ». Type d’événement inferred
	Incident clôturé	Cette activité finale marque la clôture officielle de la fiche d’incident, après confirmation de la résolution ou à l’issue d’une période d’attente. Elle est enregistrée lorsque le statut passe à « Closed ».
Pourquoi est-ce important ? Il s’agit de l’événement de fin définitif du cycle de vie de l’incident. Le délai entre « Resolved » et « Closed » correspond à la période de confirmation par l’utilisateur et de clôture administrative. Où trouver ces données Cet événement correspond au passage du champ « Status » à « Closed » dans le formulaire « HPD:Help Desk ». L’horodatage est enregistré dans le champ « Closed Date » et dans le journal d’audit. Données à recueillir À partir de l’horodatage du champ « Closed Date » ou du passage au statut « Closed ». Type d’événement inferred
	Incident résolu	Cette activité marque la résolution officielle de l’incident du point de vue du centre de services, avant sa clôture définitive. Elle est enregistrée lorsque le statut de l’incident passe à « Resolved ».
Pourquoi est-ce important ? Il s’agit de l’étape la plus importante pour mesurer le respect des SLA et le délai de résolution. Elle indique que le service a été rétabli pour l’utilisateur. Où trouver ces données Cet événement correspond au passage du champ « Status » à « Resolved » dans le formulaire « HPD:Help Desk ». L’horodatage est enregistré dans le champ « Last Resolved Date » et dans le journal d’audit. Données à recueillir À partir de l’horodatage du passage au statut « Resolved » dans le journal d’audit. Type d’événement inferred
	Incident signalé	Cette activité correspond à la création initiale de la fiche d’incident dans le système. Elle est déterminée à partir de l’horodatage de création de l’incident dans le formulaire principal de gestion des incidents.
Pourquoi est-ce important ? Il s’agit de l’événement de début principal du cycle de vie de l’incident. Il est indispensable pour calculer les délais de résolution globaux et comprendre le rythme d’arrivée des incidents. Où trouver ces données Cet événement correspond à la création de la fiche dans le formulaire « HPD:Help Desk ». L’horodatage provient généralement du champ « Submit Date » ou « Reported Date ». Données à recueillir À partir de l’horodatage du champ « Submit Date » du formulaire HPD:Help Desk. Type d’événement explicit
	Confirmation reçue de l’utilisateur	Indique que l’utilisateur confirme explicitement que la solution apportée a résolu son problème. Cette confirmation peut être enregistrée comme un événement distinct ou déduite de notes ou d’une action connexe dans le système avant la clôture.
Pourquoi est-ce important ? Ce suivi donne une image plus précise du processus de validation par l’utilisateur que la simple attente de la clôture automatique. Il permet de mesurer le KPI « Délai moyen de confirmation par l’utilisateur » et de repérer les lacunes de communication. Où trouver ces données Cette information peut être difficile à recueillir de manière fiable. Elle peut être déduite d’une entrée du journal de travail ou d’une mise à jour du motif de statut juste avant le passage de l’incident à « Closed ». L’analyse du formulaire « HPD:WorkLog » peut être nécessaire. Données à recueillir Déduit d’entrées précises du journal de travail ou de mises à jour du motif de statut avant la clôture. Type d’événement inferred
	En attente d’informations du client	Indique que le traitement de l’incident est suspendu dans l’attente d’informations ou d’une action de l’utilisateur. Cette activité est déduite du passage à un statut « Pending ».
Pourquoi est-ce important ? Cette activité permet de distinguer le temps de travail de l’agent du temps d’attente du client. L’analyse de la durée passée dans cet état est essentielle pour comprendre l’incidence des délais de réponse de l’utilisateur sur le délai global de résolution. Où trouver ces données Déduit du formulaire « HPD:Help Desk » lorsque le champ « Status » est mis à jour avec la valeur « Pending ». Le motif précis figure souvent dans le champ « Status_Reason ». Données à recueillir Déduit du passage au statut « Pending » dans HPD:HelpDesk_AuditLogSystem. Type d’événement inferred
	En attente de confirmation de l’utilisateur	Cette étape survient après la mise en œuvre d’une résolution, lorsque l’équipe d’assistance attend que l’utilisateur confirme que la correction fonctionne. Elle correspond souvent au statut « Resolved », qui déclenche le délai avant la clôture automatique.
Pourquoi est-ce important ? Cette activité est essentielle pour le Dashboard « Délais de confirmation et de vérification par l’utilisateur ». Elle permet de mesurer le délai entre l’application d’une correction et sa validation par l’utilisateur, qui peut prolonger artificiellement le cycle de vie de l’incident. Où trouver ces données Cette étape commence lorsque le champ « Status » du formulaire « HPD:Help Desk » passe à « Resolved ». La durée est mesurée à partir du champ « Last Resolved Date », jusqu’à ce que l’incident soit « Closed » ou « Reopened ». Données à recueillir Commence au passage au statut « Resolved » et se termine au passage au statut « Closed » ou « In Progress ». Type d’événement inferred
	Incident annulé	Cette activité correspond à l’arrêt du traitement d’un incident créé par erreur ou devenu sans objet. Elle est enregistrée lorsque le statut de l’incident passe à « Cancelled ».
Pourquoi est-ce important ? Il s’agit d’un état final, distinct d’une résolution réussie. L’analyse des incidents annulés peut révéler des problèmes liés aux canaux de création ou aux signalements en double. Où trouver ces données Déduit du formulaire « HPD:Help Desk » lorsque le champ « Status » est mis à jour avec la valeur « Cancelled ». L’horodatage est enregistré dans le journal d’audit. Données à recueillir Déduit du passage au statut « Cancelled » dans le journal d’audit. Type d’événement inferred
	Incident catégorisé	Indique que l’incident a été classé selon les catégories opérationnelles et produit, et qu’une priorité lui a été attribuée. Cette activité est généralement déduite du renseignement ou de la dernière modification des champs de catégorisation.
Pourquoi est-ce important ? Une catégorisation précise et rapide est essentielle pour orienter efficacement les incidents et produire des rapports fiables. L’analyse de cette activité permet de repérer les retards ou les erreurs lors du tri initial et d’alimenter le Dashboard « Précision de la catégorisation des incidents ». Où trouver ces données Déduit du journal d’audit (« HPD:HelpDesk_AuditLogSystem »), qui suit les modifications de champs tels que « Operational Categorization Tier 1-3 », « Product Categorization Tier 1-3 » et « Priority » dans le formulaire « HPD:Help Desk ». Données à recueillir À partir de l’horodatage de la dernière mise à jour des champs de catégorisation ou de priorité après la création. Type d’événement inferred
	Incident rouvert	Indique qu’un incident précédemment marqué comme résolu a été réactivé parce que le problème persiste. Cette activité est déduite du passage du statut « Resolved » à un état actif, comme « In Progress » ou « Assigned ».
Pourquoi est-ce important ? Cette activité mesure directement les reprises et l’efficacité des premières solutions. Un nombre élevé d’incidents rouverts indique souvent une qualité de correction insuffisante et alimente le KPI « Taux de reprise des incidents ». Où trouver ces données Déduit du journal d’audit (« HPD:HelpDesk_AuditLogSystem »), en repérant, pour un identifiant d’incident donné, le passage du champ « Status » de « Resolved » à « In Progress » ou « Assigned ». Données à recueillir Déduit du passage du statut « Resolved » à un état actif. Type d’événement inferred
	Manquement au SLA	Cet événement calculé survient lorsque le délai de résolution d’un incident dépasse l’objectif défini dans son accord de niveau de service. Il est déterminé en comparant l’horodatage de résolution à la date d’échéance du SLA.
Pourquoi est-ce important ? Cette activité est fondamentale pour le Dashboard « Vue d’ensemble de la performance du SLA des incidents » et le KPI « Taux de respect des SLA des incidents ». Elle signale directement les incidents pour lesquels les engagements de service n’ont pas été respectés. Où trouver ces données Calculé en comparant le champ « Last Resolved Date » au champ « Target Date » (date d’échéance du SLA) du formulaire « HPD:Help Desk ». Si l’incident n’est pas encore résolu, le calcul peut être effectué par rapport à l’heure actuelle. Données à recueillir Événement calculé : survient si « Last Resolved Date » > « Target Date ». Type d’événement calculated
	Résolution mise en œuvre	Cette activité indique que l’équipe d’assistance a appliqué une correction ou une solution de contournement. Elle est souvent déduite du passage de l’incident au statut « Resolved ».
Pourquoi est-ce important ? Cette étape clé indique qu’une solution a été apportée. Elle constitue un repère important pour mesurer le délai d’application d’une correction après la fin de l’investigation. Où trouver ces données Cette activité est généralement déduite du passage du champ « Status » à « Resolved » dans le formulaire « HPD:Help Desk ». L’horodatage est enregistré dans le champ « Last Resolved Date » et dans le journal d’audit. Données à recueillir À partir de l’horodatage du champ « Last Resolved Date » ou du passage au statut « Resolved ». Type d’événement inferred
	Transféré à un autre groupe	Cette activité survient lorsqu’un incident est réaffecté d’un groupe d’assistance à un autre. Elle est déduite d’une modification du champ « Assigned Group » après l’affectation initiale.
Pourquoi est-ce important ? Des transferts fréquents signalent une mauvaise orientation initiale ou des lacunes dans les connaissances. Le suivi de cette activité est essentiel pour le Dashboard « Analyse des cycles de réaffectation des incidents » et le KPI « Taux de réaffectation des incidents ». Où trouver ces données Déduit du journal d’audit (« HPD:HelpDesk_AuditLogSystem »), en repérant les modifications ultérieures du champ « Assigned Group » dans le formulaire « HPD:Help Desk » après son premier renseignement. Données à recueillir Repérer les modifications du champ « Assigned Group » après l’affectation initiale. Type d’événement inferred

Recommandé Facultatif

Guides d’extraction

Comment extraire vos données de BMC Helix ITSM

Étapes

Accédez à Smart Reporting : Connectez-vous à votre environnement BMC Helix ITSM. Dans le menu principal de l’application, sélectionnez Rapports pour ouvrir Smart Reporting.
Créez un rapport : Dans Smart Reporting, cliquez sur le bouton Créer, puis sélectionnez Rapport. Choisissez l’option Rapport avancé pour accéder à des fonctionnalités plus complexes, comme Freehand SQL.
Sélectionnez une source de données : Lorsque vous y êtes invité, choisissez votre source de données ITSM principale. Sélectionnez la vue Gestion des incidents, une couche sémantique construite à partir des formulaires d’incident principaux.
Utilisez Freehand SQL : Dans le générateur de rapports, au lieu de faire glisser des champs, ouvrez les options de la source de données et sélectionnez Freehand SQL. Un éditeur s’ouvre pour vous permettre de rédiger une requête SQL personnalisée.
Saisissez la requête SQL : Copiez la requête SQL complète fournie dans la section correspondante de ce document et collez-la dans l’éditeur Freehand SQL. Remplacez les valeurs fictives [START_DATE], [END_DATE] et [YOUR_COMPANY_NAME] par les valeurs adaptées à vos besoins.
Validez et prévisualisez les données : Utilisez la fonction de validation ou de prévisualisation de l’éditeur SQL pour vérifier la syntaxe et consulter un échantillon du résultat. Vous pourrez ainsi confirmer que la requête s’exécute correctement dans votre environnement avant de créer le rapport complet.
Mettez le rapport en forme : Une fois la requête validée, passez à la conception du rapport. Les colonnes définies dans la requête SQL seront disponibles sous forme de champs. Veillez à inclure toutes les colonnes (IncidentId, ActivityName, EventTimestamp, etc.) dans le tableau du rapport.
Appliquez des filtres au rapport (facultatif) : Le filtre principal sur les dates étant défini dans la requête SQL, vous pouvez ajouter d’autres filtres interactifs au rapport si nécessaire, par exemple sur Priority ou AssignedGroup.
Exécutez et enregistrez le rapport : Exécutez le rapport pour générer l’ensemble des données. Lorsque le résultat vous convient, enregistrez le rapport sous un nom explicite, par exemple « Journal d’événements de gestion des incidents ».
Exportez au format CSV : Lorsque les résultats du rapport s’affichent, utilisez la fonction Export. Sélectionnez CSV comme format d’exportation. Le fichier complet du journal d’événements sera téléchargé sur votre ordinateur.
Planifiez l’exportation (facultatif) : Pour poursuivre l’analyse, vous pouvez planifier l’exécution automatique du rapport. Dans les paramètres de distribution du rapport, définissez une fréquence (par exemple, quotidienne ou hebdomadaire) et choisissez un partage de fichiers ou une adresse e-mail comme destination. Vérifiez que le format sélectionné est CSV.

Configuration

Prérequis : Vous devez disposer d’un compte BMC Helix autorisé à accéder à Smart Reporting, à créer des rapports, à utiliser Freehand SQL et à interroger la source de données Gestion des incidents.
Type de rapport : Un Rapport avancé utilisant la fonctionnalité Freehand SQL est nécessaire pour construire la structure du journal d’événements à l’aide d’instructions UNION ALL.
Vue de la source de données : Utilisez la vue standard Gestion des incidents, basée sur le formulaire HPD:Help Desk et ses jointures associées.
Filtrage par période : Il est essentiel de définir une période pour maîtriser les performances. La requête fournie contient les valeurs fictives [START_DATE] et [END_DATE]. Nous recommandons d’extraire 3 à 6 mois de données pour obtenir une analyse pertinente sans surcharger le système.
Filtre sur l’entreprise : La requête contient la valeur fictive [YOUR_COMPANY_NAME] pour limiter les données à une entreprise opérationnelle précise. Si votre environnement est multi-tenant, ce filtre est indispensable pour obtenir des rapports exacts.
Considérations relatives aux performances : La requête du journal d’événements est complexe et joint plusieurs tables. Son exécution sur de grands volumes de données peut mobiliser d’importantes ressources système. Planifiez toujours les exportations volumineuses en dehors des heures de pointe.

Exemple de requête sql

SELECT
  hpd."Incident Number" AS "IncidentId",
  'Incident Reported' AS "ActivityName",
  hpd."Submit Date" AS "EventTimestamp",
  hpd."Status" AS "IncidentStatus",
  hpd."Priority" AS "Priority",
  hpd."Assigned Group" AS "AssignedGroup",
  hpd."Assignee" AS "Assignee",
  hpd."ServiceCI" AS "Service",
  CONCAT(CONCAT(hpd."Operational Categ Tier 1", '/'), CONCAT(hpd."Operational Categ Tier 2", CONCAT('/', hpd."Operational Categ Tier 3"))) AS "IncidentCategory",
  (CASE WHEN hpd."Last Resolved Date" IS NOT NULL THEN (hpd."Last Resolved Date" - hpd."Submit Date") * 86400 ELSE NULL END) AS "IncidentResolutionTime",
  (CASE WHEN hpd."SLM Status" = 'Service Target Breached' THEN 'Yes' ELSE 'No' END) AS "IsSlaBreached",
  (CASE WHEN hpd."Re-Opened Date" IS NOT NULL THEN 'Yes' ELSE 'No' END) AS "IsReopened"
FROM HPD_Help_Desk hpd
WHERE hpd."Submit Date" >= '[START_DATE]' AND hpd."Submit Date" < '[END_DATE]' AND hpd.Company = '[YOUR_COMPANY_NAME]'

UNION ALL

SELECT
  hpd."Incident Number" AS "IncidentId",
  'Incident Categorized' AS "ActivityName",
  hpd."Last Modified Date" AS "EventTimestamp",
  hpd."Status" AS "IncidentStatus",
  hpd."Priority" AS "Priority",
  hpd."Assigned Group" AS "AssignedGroup",
  hpd."Assignee" AS "Assignee",
  hpd."ServiceCI" AS "Service",
  CONCAT(CONCAT(hpd."Operational Categ Tier 1", '/'), CONCAT(hpd."Operational Categ Tier 2", CONCAT('/', hpd."Operational Categ Tier 3"))) AS "IncidentCategory",
  (CASE WHEN hpd."Last Resolved Date" IS NOT NULL THEN (hpd."Last Resolved Date" - hpd."Submit Date") * 86400 ELSE NULL END) AS "IncidentResolutionTime",
  (CASE WHEN hpd."SLM Status" = 'Service Target Breached' THEN 'Yes' ELSE 'No' END) AS "IsSlaBreached",
  (CASE WHEN hpd."Re-Opened Date" IS NOT NULL THEN 'Yes' ELSE 'No' END) AS "IsReopened"
FROM HPD_Help_Desk hpd
WHERE hpd."First Assigned Date" IS NOT NULL AND hpd."Operational Categ Tier 1" IS NOT NULL AND hpd."Submit Date" >= '[START_DATE]' AND hpd."Submit Date" < '[END_DATE]' AND hpd.Company = '[YOUR_COMPANY_NAME]'

UNION ALL

SELECT 
  hpd."Incident Number" AS "IncidentId",
  'Group Assigned' AS "ActivityName",
  hpd."First Assigned Date" AS "EventTimestamp",
  hpd."Status" AS "IncidentStatus",
  hpd."Priority" AS "Priority",
  hpd."Assigned Group" AS "AssignedGroup",
  hpd."Assignee" AS "Assignee",
  hpd."ServiceCI" AS "Service",
  CONCAT(CONCAT(hpd."Operational Categ Tier 1", '/'), CONCAT(hpd."Operational Categ Tier 2", CONCAT('/', hpd."Operational Categ Tier 3"))) AS "IncidentCategory",
  (CASE WHEN hpd."Last Resolved Date" IS NOT NULL THEN (hpd."Last Resolved Date" - hpd."Submit Date") * 86400 ELSE NULL END) AS "IncidentResolutionTime",
  (CASE WHEN hpd."SLM Status" = 'Service Target Breached' THEN 'Yes' ELSE 'No' END) AS "IsSlaBreached",
  (CASE WHEN hpd."Re-Opened Date" IS NOT NULL THEN 'Yes' ELSE 'No' END) AS "IsReopened"
FROM HPD_Help_Desk hpd
WHERE hpd."First Assigned Date" IS NOT NULL AND hpd."Submit Date" >= '[START_DATE]' AND hpd."Submit Date" < '[END_DATE]' AND hpd.Company = '[YOUR_COMPANY_NAME]'

UNION ALL

SELECT
  hpd."Incident Number" AS "IncidentId",
  aud."New_Value" AS "ActivityName",
  aud."Audit_Date" AS "EventTimestamp",
  aud."New_Value" AS "IncidentStatus",
  hpd."Priority" AS "Priority",
  hpd."Assigned Group" AS "AssignedGroup",
  hpd."Assignee" AS "Assignee",
  hpd."ServiceCI" AS "Service",
  CONCAT(CONCAT(hpd."Operational Categ Tier 1", '/'), CONCAT(hpd."Operational Categ Tier 2", CONCAT('/', hpd."Operational Categ Tier 3"))) AS "IncidentCategory",
  (CASE WHEN hpd."Last Resolved Date" IS NOT NULL THEN (hpd."Last Resolved Date" - hpd."Submit Date") * 86400 ELSE NULL END) AS "IncidentResolutionTime",
  (CASE WHEN hpd."SLM Status" = 'Service Target Breached' THEN 'Yes' ELSE 'No' END) AS "IsSlaBreached",
  (CASE WHEN hpd."Re-Opened Date" IS NOT NULL THEN 'Yes' ELSE 'No' END) AS "IsReopened"
FROM HPD_Help_Desk hpd
JOIN HPD_HelpDesk_AuditLogSystem aud ON hpd."Incident Number" = aud."Original_Request_ID"
WHERE aud."Fields_Changed" LIKE '%Status%' AND aud.New_Value IN ('In Progress', 'Pending')
  AND hpd."Submit Date" >= '[START_DATE]' AND hpd."Submit Date" < '[END_DATE]' AND hpd.Company = '[YOUR_COMPANY_NAME]'
  AND aud.New_Value = 'In Progress' AND aud."Audit_Date" = (SELECT MIN(a2."Audit_Date") FROM HPD_HelpDesk_AuditLogSystem a2 WHERE a2."Original_Request_ID" = hpd."Incident Number" AND a2."New_Value" = 'In Progress' AND a2."Fields_Changed" LIKE '%Status%')

UNION ALL

SELECT
  hpd."Incident Number" AS "IncidentId",
  'Transferred To Another Group' AS "ActivityName",
  aud."Audit_Date" AS "EventTimestamp",
  hpd."Status" AS "IncidentStatus",
  hpd."Priority" AS "Priority",
  aud."New_Value" AS "AssignedGroup",
  hpd."Assignee" AS "Assignee",
  hpd."ServiceCI" AS "Service",
  CONCAT(CONCAT(hpd."Operational Categ Tier 1", '/'), CONCAT(hpd."Operational Categ Tier 2", CONCAT('/', hpd."Operational Categ Tier 3"))) AS "IncidentCategory",
  (CASE WHEN hpd."Last Resolved Date" IS NOT NULL THEN (hpd."Last Resolved Date" - hpd."Submit Date") * 86400 ELSE NULL END) AS "IncidentResolutionTime",
  (CASE WHEN hpd."SLM Status" = 'Service Target Breached' THEN 'Yes' ELSE 'No' END) AS "IsSlaBreached",
  (CASE WHEN hpd."Re-Opened Date" IS NOT NULL THEN 'Yes' ELSE 'No' END) AS "IsReopened"
FROM HPD_Help_Desk hpd
JOIN HPD_HelpDesk_AuditLogSystem aud ON hpd."Incident Number" = aud."Original_Request_ID"
WHERE aud."Fields_Changed" LIKE '%Assigned Group%' AND aud."Audit_Date" > hpd."First Assigned Date"
  AND hpd."Submit Date" >= '[START_DATE]' AND hpd."Submit Date" < '[END_DATE]' AND hpd.Company = '[YOUR_COMPANY_NAME]'

UNION ALL

SELECT
  hpd."Incident Number" AS "IncidentId",
  'Pending Customer Input' AS "ActivityName",
  aud."Audit_Date" AS "EventTimestamp",
  'Pending' AS "IncidentStatus",
  hpd."Priority" AS "Priority",
  hpd."Assigned Group" AS "AssignedGroup",
  hpd."Assignee" AS "Assignee",
  hpd."ServiceCI" AS "Service",
  CONCAT(CONCAT(hpd."Operational Categ Tier 1", '/'), CONCAT(hpd."Operational Categ Tier 2", CONCAT('/', hpd."Operational Categ Tier 3"))) AS "IncidentCategory",
  (CASE WHEN hpd."Last Resolved Date" IS NOT NULL THEN (hpd."Last Resolved Date" - hpd."Submit Date") * 86400 ELSE NULL END) AS "IncidentResolutionTime",
  (CASE WHEN hpd."SLM Status" = 'Service Target Breached' THEN 'Yes' ELSE 'No' END) AS "IsSlaBreached",
  (CASE WHEN hpd."Re-Opened Date" IS NOT NULL THEN 'Yes' ELSE 'No' END) AS "IsReopened"
FROM HPD_Help_Desk hpd
JOIN HPD_HelpDesk_AuditLogSystem aud ON hpd."Incident Number" = aud."Original_Request_ID"
WHERE aud."Fields_Changed" LIKE '%Status%' AND aud."New_Value" = 'Pending'
  AND hpd."Submit Date" >= '[START_DATE]' AND hpd."Submit Date" < '[END_DATE]' AND hpd.Company = '[YOUR_COMPANY_NAME]'

UNION ALL

SELECT
  hpd."Incident Number" AS "IncidentId",
  'Resolution Implemented' AS "ActivityName",
  hpd."Last Resolved Date" AS "EventTimestamp",
  'Resolved' AS "IncidentStatus",
  hpd."Priority" AS "Priority",
  hpd."Assigned Group" AS "AssignedGroup",
  hpd."Assignee" AS "Assignee",
  hpd."ServiceCI" AS "Service",
  CONCAT(CONCAT(hpd."Operational Categ Tier 1", '/'), CONCAT(hpd."Operational Categ Tier 2", CONCAT('/', hpd."Operational Categ Tier 3"))) AS "IncidentCategory",
  (CASE WHEN hpd."Last Resolved Date" IS NOT NULL THEN (hpd."Last Resolved Date" - hpd."Submit Date") * 86400 ELSE NULL END) AS "IncidentResolutionTime",
  (CASE WHEN hpd."SLM Status" = 'Service Target Breached' THEN 'Yes' ELSE 'No' END) AS "IsSlaBreached",
  (CASE WHEN hpd."Re-Opened Date" IS NOT NULL THEN 'Yes' ELSE 'No' END) AS "IsReopened"
FROM HPD_Help_Desk hpd
WHERE hpd."Last Resolved Date" IS NOT NULL AND hpd."Submit Date" >= '[START_DATE]' AND hpd."Submit Date" < '[END_DATE]' AND hpd.Company = '[YOUR_COMPANY_NAME]'

UNION ALL

SELECT
  hpd."Incident Number" AS "IncidentId",
  'Awaiting User Confirmation' AS "ActivityName",
  hpd."Last Resolved Date" AS "EventTimestamp",
  'Resolved' AS "IncidentStatus",
  hpd."Priority" AS "Priority",
  hpd."Assigned Group" AS "AssignedGroup",
  hpd."Assignee" AS "Assignee",
  hpd."ServiceCI" AS "Service",
  CONCAT(CONCAT(hpd."Operational Categ Tier 1", '/'), CONCAT(hpd."Operational Categ Tier 2", CONCAT('/', hpd."Operational Categ Tier 3"))) AS "IncidentCategory",
  (CASE WHEN hpd."Last Resolved Date" IS NOT NULL THEN (hpd."Last Resolved Date" - hpd."Submit Date") * 86400 ELSE NULL END) AS "IncidentResolutionTime",
  (CASE WHEN hpd."SLM Status" = 'Service Target Breached' THEN 'Yes' ELSE 'No' END) AS "IsSlaBreached",
  (CASE WHEN hpd."Re-Opened Date" IS NOT NULL THEN 'Yes' ELSE 'No' END) AS "IsReopened"
FROM HPD_Help_Desk hpd
WHERE hpd."Status" = 'Resolved' AND hpd."Last Resolved Date" IS NOT NULL AND hpd."Submit Date" >= '[START_DATE]' AND hpd."Submit Date" < '[END_DATE]' AND hpd.Company = '[YOUR_COMPANY_NAME]'

UNION ALL

SELECT
  hpd."Incident Number" AS "IncidentId",
  'Incident Reopened' AS "ActivityName",
  hpd."Re-Opened Date" AS "EventTimestamp",
  hpd."Status" AS "IncidentStatus",
  hpd."Priority" AS "Priority",
  hpd."Assigned Group" AS "AssignedGroup",
  hpd."Assignee" AS "Assignee",
  hpd."ServiceCI" AS "Service",
  CONCAT(CONCAT(hpd."Operational Categ Tier 1", '/'), CONCAT(hpd."Operational Categ Tier 2", CONCAT('/', hpd."Operational Categ Tier 3"))) AS "IncidentCategory",
  (CASE WHEN hpd."Last Resolved Date" IS NOT NULL THEN (hpd."Last Resolved Date" - hpd."Submit Date") * 86400 ELSE NULL END) AS "IncidentResolutionTime",
  (CASE WHEN hpd."SLM Status" = 'Service Target Breached' THEN 'Yes' ELSE 'No' END) AS "IsSlaBreached",
  'Yes' AS "IsReopened"
FROM HPD_Help_Desk hpd
WHERE hpd."Re-Opened Date" IS NOT NULL AND hpd."Submit Date" >= '[START_DATE]' AND hpd."Submit Date" < '[END_DATE]' AND hpd.Company = '[YOUR_COMPANY_NAME]'

UNION ALL

SELECT
  hpd."Incident Number" AS "IncidentId",
  'Incident Resolved' AS "ActivityName",
  hpd."Last Resolved Date" AS "EventTimestamp",
  'Resolved' AS "IncidentStatus",
  hpd."Priority" AS "Priority",
  hpd."Assigned Group" AS "AssignedGroup",
  hpd."Assignee" AS "Assignee",
  hpd."ServiceCI" AS "Service",
  CONCAT(CONCAT(hpd."Operational Categ Tier 1", '/'), CONCAT(hpd."Operational Categ Tier 2", CONCAT('/', hpd."Operational Categ Tier 3"))) AS "IncidentCategory",
  (CASE WHEN hpd."Last Resolved Date" IS NOT NULL THEN (hpd."Last Resolved Date" - hpd."Submit Date") * 86400 ELSE NULL END) AS "IncidentResolutionTime",
  (CASE WHEN hpd."SLM Status" = 'Service Target Breached' THEN 'Yes' ELSE 'No' END) AS "IsSlaBreached",
  (CASE WHEN hpd."Re-Opened Date" IS NOT NULL THEN 'Yes' ELSE 'No' END) AS "IsReopened"
FROM HPD_Help_Desk hpd
WHERE hpd."Status" >= 'Resolved' AND hpd."Last Resolved Date" IS NOT NULL AND hpd."Submit Date" >= '[START_DATE]' AND hpd."Submit Date" < '[END_DATE]' AND hpd.Company = '[YOUR_COMPANY_NAME]'

UNION ALL

SELECT
  hpd."Incident Number" AS "IncidentId",
  'User Confirmation Received' AS "ActivityName",
  hpd."Closed Date" AS "EventTimestamp",
  'Closed' AS "IncidentStatus",
  hpd."Priority" AS "Priority",
  hpd."Assigned Group" AS "AssignedGroup",
  hpd."Assignee" AS "Assignee",
  hpd."ServiceCI" AS "Service",
  CONCAT(CONCAT(hpd."Operational Categ Tier 1", '/'), CONCAT(hpd."Operational Categ Tier 2", CONCAT('/', hpd."Operational Categ Tier 3"))) AS "IncidentCategory",
  (CASE WHEN hpd."Last Resolved Date" IS NOT NULL THEN (hpd."Last Resolved Date" - hpd."Submit Date") * 86400 ELSE NULL END) AS "IncidentResolutionTime",
  (CASE WHEN hpd."SLM Status" = 'Service Target Breached' THEN 'Yes' ELSE 'No' END) AS "IsSlaBreached",
  (CASE WHEN hpd."Re-Opened Date" IS NOT NULL THEN 'Yes' ELSE 'No' END) AS "IsReopened"
FROM HPD_Help_Desk hpd
WHERE hpd."Status" = 'Closed' AND hpd."Submit Date" >= '[START_DATE]' AND hpd."Submit Date" < '[END_DATE]' AND hpd.Company = '[YOUR_COMPANY_NAME]'

UNION ALL

SELECT
  hpd."Incident Number" AS "IncidentId",
  'SLA Breach' AS "ActivityName",
  hpd."Estimated Resolution Date" AS "EventTimestamp", -- Represents the SLA due date
  hpd."Status" AS "IncidentStatus",
  hpd."Priority" AS "Priority",
  hpd."Assigned Group" AS "AssignedGroup",
  hpd."Assignee" AS "Assignee",
  hpd."ServiceCI" AS "Service",
  CONCAT(CONCAT(hpd."Operational Categ Tier 1", '/'), CONCAT(hpd."Operational Categ Tier 2", CONCAT('/', hpd."Operational Categ Tier 3"))) AS "IncidentCategory",
  (CASE WHEN hpd."Last Resolved Date" IS NOT NULL THEN (hpd."Last Resolved Date" - hpd."Submit Date") * 86400 ELSE NULL END) AS "IncidentResolutionTime",
  'Yes' AS "IsSlaBreached",
  (CASE WHEN hpd."Re-Opened Date" IS NOT NULL THEN 'Yes' ELSE 'No' END) AS "IsReopened"
FROM HPD_Help_Desk hpd
WHERE hpd."SLM Status" = 'Service Target Breached' AND hpd."Submit Date" >= '[START_DATE]' AND hpd."Submit Date" < '[END_DATE]' AND hpd.Company = '[YOUR_COMPANY_NAME]'

UNION ALL

SELECT
  hpd."Incident Number" AS "IncidentId",
  'Incident Cancelled' AS "ActivityName",
  hpd."Last Modified Date" AS "EventTimestamp",
  'Cancelled' AS "IncidentStatus",
  hpd."Priority" AS "Priority",
  hpd."Assigned Group" AS "AssignedGroup",
  hpd."Assignee" AS "Assignee",
  hpd."ServiceCI" AS "Service",
  CONCAT(CONCAT(hpd."Operational Categ Tier 1", '/'), CONCAT(hpd."Operational Categ Tier 2", CONCAT('/', hpd."Operational Categ Tier 3"))) AS "IncidentCategory",
  (CASE WHEN hpd."Last Resolved Date" IS NOT NULL THEN (hpd."Last Resolved Date" - hpd."Submit Date") * 86400 ELSE NULL END) AS "IncidentResolutionTime",
  (CASE WHEN hpd."SLM Status" = 'Service Target Breached' THEN 'Yes' ELSE 'No' END) AS "IsSlaBreached",
  (CASE WHEN hpd."Re-Opened Date" IS NOT NULL THEN 'Yes' ELSE 'No' END) AS "IsReopened"
FROM HPD_Help_Desk hpd
WHERE hpd."Status" = 'Cancelled' AND hpd."Submit Date" >= '[START_DATE]' AND hpd."Submit Date" < '[END_DATE]' AND hpd.Company = '[YOUR_COMPANY_NAME]'

UNION ALL

SELECT
  hpd."Incident Number" AS "IncidentId",
  'Incident Closed' AS "ActivityName",
  hpd."Closed Date" AS "EventTimestamp",
  'Closed' AS "IncidentStatus",
  hpd."Priority" AS "Priority",
  hpd."Assigned Group" AS "AssignedGroup",
  hpd."Assignee" AS "Assignee",
  hpd."ServiceCI" AS "Service",
  CONCAT(CONCAT(hpd."Operational Categ Tier 1", '/'), CONCAT(hpd."Operational Categ Tier 2", CONCAT('/', hpd."Operational Categ Tier 3"))) AS "IncidentCategory",
  (CASE WHEN hpd."Last Resolved Date" IS NOT NULL THEN (hpd."Last Resolved Date" - hpd."Submit Date") * 86400 ELSE NULL END) AS "IncidentResolutionTime",
  (CASE WHEN hpd."SLM Status" = 'Service Target Breached' THEN 'Yes' ELSE 'No' END) AS "IsSlaBreached",
  (CASE WHEN hpd."Re-Opened Date" IS NOT NULL THEN 'Yes' ELSE 'No' END) AS "IsReopened"
FROM HPD_Help_Desk hpd
WHERE hpd."Status" = 'Closed' AND hpd."Submit Date" >= '[START_DATE]' AND hpd."Submit Date" < '[END_DATE]' AND hpd.Company = '[YOUR_COMPANY_NAME]'

Étapes

Repérez les identifiants de connexion et le schéma de la base de données : Obtenez des identifiants en lecture seule pour la base de données sous-jacente de BMC Helix ITSM AR System (par exemple, SQL Server ou Oracle). Vous devez également repérer le schéma et les noms de tables correspondant au formulaire de gestion des incidents (HPD:Help Desk) et à son journal d’audit. La table principale porte souvent un nom tel que T<form_id> (par exemple, T1234), et le journal d’audit s’appelle généralement H<form_id> ou [form_name]_AuditLogSystem.
Connectez-vous à la base de données : Utilisez un client SQL standard, tel que DBeaver, SQL Server Management Studio (SSMS) ou Oracle SQL Developer, pour vous connecter à la base de données avec les identifiants obtenus à l’étape précédente.
Vérifiez et personnalisez la requête SQL : Copiez la requête SQL fournie dans votre client. Vérifiez attentivement les valeurs fictives et remplacez-les par les valeurs correspondant à votre environnement :
- [Your_HPD_Help_Desk_Table] : Remplacez cette valeur par le nom réel de la table correspondant au formulaire HPD:Help Desk.
- [Your_HPD_Help_Desk_Audit_Table] : Remplacez cette valeur par le nom réel de la table du journal d’audit associé au formulaire HPD:Help Desk.
- 'YYYY-MM-DD' et 'YYYY-MM-DD' : Indiquez les dates de début et de fin de la période d’extraction.
Gérez la conversion des horodatages : La requête fournie utilise DATEADD(s, [TimestampColumn], '1970-01-01'), une fonction propre à SQL Server qui convertit les horodatages Unix. Si vous utilisez Oracle ou une autre base de données, vous devez adapter cette fonction. Dans Oracle, l’équivalent est TO_DATE('1970-01-01', 'YYYY-MM-DD') + ( [TimestampColumn] / 86400 ).
Exécutez la requête : Lancez la requête modifiée sur la base de données. Selon la période choisie et le volume de données sur les incidents, l’opération peut prendre plusieurs minutes.
Vérifiez les résultats : Une fois la requête terminée, examinez rapidement le résultat. Vérifiez que les colonnes IncidentId, ActivityName et EventTimestamp contiennent les valeurs attendues. Assurez-vous que plusieurs types d’activités apparaissent afin de confirmer le bon fonctionnement des instructions UNION ALL.
Exportez les données au format CSV : Exportez l’ensemble des résultats depuis votre client SQL dans un fichier CSV. Vérifiez que le fichier utilise l’encodage UTF-8 et comporte une ligne d’en-tête avec les noms des colonnes.
Préparez l’importation : Avant d’importer le fichier dans un outil de Process Mining, vérifiez que la colonne EventTimestamp utilise un format cohérent (par exemple, YYYY-MM-DD HH:MI:SS). Si la requête SQL s’est exécutée correctement, aucune autre transformation des données ne devrait être nécessaire.

Configuration

Prérequis : Vous devez disposer d’un accès utilisateur en lecture seule à la base de données de l’application BMC Helix ITSM. Vous devez également connaître les noms exacts des tables correspondant au formulaire HPD:Help Desk et à son journal d’audit, qui peuvent varier selon l’installation du système.
Filtrage par période : La requête contient une clause WHERE dans la CTE BaseIncidents pour filtrer les données selon Submit_Date. Il est fortement recommandé de commencer par une période limitée, par exemple 3 à 6 mois, afin de maîtriser les performances de la requête et le volume de données. Exemple : WHERE hpd.Submit_Date >= '2023-01-01' AND hpd.Submit_Date < '2023-07-01'.
Filtrage par entreprise : Si votre instance ITSM est multi-tenant, ajoutez dans la clause WHERE de la CTE BaseIncidents un filtre correspondant à l’entreprise à analyser (par exemple, AND hpd.Company = '[Your Company Name]').
Considérations relatives aux performances : Les requêtes directes sur la base de données, en particulier celles qui joignent de grandes tables de journaux d’audit et comportent plusieurs opérations UNION ALL, peuvent mobiliser beaucoup de ressources. Il est recommandé d’effectuer les extractions volumineuses en dehors des heures de pointe pour éviter de nuire aux performances du système.
Conversion des horodatages : La requête suppose que les horodatages sont stockés au format Unix (nombre de secondes écoulées depuis le 1970-01-01). Vérifiez que c’est bien le cas dans votre système et que la fonction de conversion utilisée dans la requête est adaptée à votre base de données (par exemple, SQL Server ou Oracle).

Exemple de requête sql

WITH BaseIncidents AS (
    -- Select the base set of incidents within the desired date range
    SELECT
        hpd.Incident_Number AS IncidentId,
        hpd.Status AS FinalStatus,
        hpd.Priority,
        hpd.Assigned_Group AS FinalAssignedGroup,
        hpd.Assignee AS FinalAssignee,
        hpd.Service_CI AS Service,
        hpd.Categorization_Tier_1 + ' | ' + hpd.Categorization_Tier_2 + ' | ' + hpd.Categorization_Tier_3 AS IncidentCategory,
        DATEDIFF(SECOND, hpd.Submit_Date, hpd.Last_Resolved_Date) AS IncidentResolutionTime,
        CASE WHEN hpd.Last_Resolved_Date > hpd.Target_Date THEN 'true' ELSE 'false' END AS IsSlaBreached,
        hpd.Submit_Date,
        hpd.Last_Resolved_Date,
        hpd.Closed_Date,
        hpd.Target_Date,
        hpd.Entry_ID -- Required for joining with the audit log
    FROM [Your_HPD_Help_Desk_Table] hpd
    WHERE hpd.Submit_Date BETWEEN '[START_DATE_YYYY-MM-DD]' AND '[END_DATE_YYYY-MM-DD]'
),
AuditChanges AS (
    -- Process the audit log to identify key changes in Status and Assigned Group
    SELECT 
        audit.Entry_ID,
        audit.Log_Key_Value,
        audit.Fields_Changed,
        DATEADD(s, audit.Log_Key_Value, '1970-01-01') AS EventTimestamp,
        LAG(audit.Fields_Changed, 1, '') OVER (PARTITION BY audit.Entry_ID, SUBSTRING(audit.Fields_Changed, 1, 8) ORDER BY audit.Log_Key_Value) AS Previous_Value
    FROM [Your_HPD_Help_Desk_Audit_Table] audit
    WHERE 
        -- Field ID 7 is for Status, Field ID 1000000217 is for Assigned Group
        (SUBSTRING(audit.Fields_Changed, 1, 8) = '7       ' OR SUBSTRING(audit.Fields_Changed, 1, 8) = '1000000217')
        AND audit.Entry_ID IN (SELECT Entry_ID FROM BaseIncidents)
),
ReopenedFlag AS (
    -- Identify incidents that have been reopened
    SELECT DISTINCT Entry_ID, 'true' AS IsReopened
    FROM AuditChanges
    WHERE 
        SUBSTRING(Fields_Changed, 1, 8) = '7       ' -- Status field
        AND CHARINDEX('Resolved', Previous_Value) > 0
        AND CHARINDEX('Resolved', Fields_Changed) = 0
)
-- Combine all activities into a single event log
SELECT
    b.IncidentId,
    'Incident Reported' AS ActivityName,
    b.Submit_Date AS EventTimestamp,
    'New' AS IncidentStatus,
    b.Priority,
    b.FinalAssignedGroup AS AssignedGroup,
    b.FinalAssignee AS Assignee,
    b.Service,
    b.IncidentCategory,
    b.IncidentResolutionTime,
    b.IsSlaBreached,
    ISNULL(rf.IsReopened, 'false') AS IsReopened
FROM BaseIncidents b
LEFT JOIN ReopenedFlag rf ON b.Entry_ID = rf.Entry_ID

UNION ALL

SELECT
    b.IncidentId,
    'Incident Categorized' AS ActivityName,
    a.EventTimestamp,
    'Assigned' AS IncidentStatus, -- Inferred status at time of categorization/assignment
    b.Priority,
    LTRIM(RTRIM(SUBSTRING(a.Fields_Changed, 9, 255))) AS AssignedGroup,
    b.FinalAssignee AS Assignee,
    b.Service,
    b.IncidentCategory,
    b.IncidentResolutionTime,
    b.IsSlaBreached,
    ISNULL(rf.IsReopened, 'false') AS IsReopened
FROM BaseIncidents b
JOIN (
    -- Find the first assignment event, used as a proxy for categorization
    SELECT Entry_ID, MIN(EventTimestamp) AS FirstAssignmentTime
    FROM AuditChanges
    WHERE SUBSTRING(Fields_Changed, 1, 8) = '1000000217'
    GROUP BY Entry_ID
) first_assign ON b.Entry_ID = first_assign.Entry_ID
JOIN AuditChanges a ON b.Entry_ID = a.Entry_ID AND a.EventTimestamp = first_assign.FirstAssignmentTime AND SUBSTRING(a.Fields_Changed, 1, 8) = '1000000217'
LEFT JOIN ReopenedFlag rf ON b.Entry_ID = rf.Entry_ID

UNION ALL

SELECT
    b.IncidentId,
    'Group Assigned' AS ActivityName,
    a.EventTimestamp,
    'Assigned' AS IncidentStatus,
    b.Priority,
    LTRIM(RTRIM(SUBSTRING(a.Fields_Changed, 9, 255))) AS AssignedGroup,
    b.FinalAssignee AS Assignee,
    b.Service,
    b.IncidentCategory,
    b.IncidentResolutionTime,
    b.IsSlaBreached,
    ISNULL(rf.IsReopened, 'false') AS IsReopened
FROM BaseIncidents b
JOIN AuditChanges a ON b.Entry_ID = a.Entry_ID
WHERE SUBSTRING(a.Fields_Changed, 1, 8) = '1000000217' AND a.Previous_Value = ''
LEFT JOIN ReopenedFlag rf ON b.Entry_ID = rf.Entry_ID

UNION ALL

SELECT
    b.IncidentId,
    'Investigation Initiated' AS ActivityName,
    a.EventTimestamp,
    'In Progress' AS IncidentStatus,
    b.Priority,
    b.FinalAssignedGroup AS AssignedGroup,
    b.FinalAssignee AS Assignee,
    b.Service,
    b.IncidentCategory,
    b.IncidentResolutionTime,
    b.IsSlaBreached,
    ISNULL(rf.IsReopened, 'false') AS IsReopened
FROM BaseIncidents b
JOIN AuditChanges a ON b.Entry_ID = a.Entry_ID
WHERE 
    SUBSTRING(a.Fields_Changed, 1, 8) = '7       '
    AND CHARINDEX('Assigned', a.Previous_Value) > 0
    AND CHARINDEX('In Progress', a.Fields_Changed) > 0
LEFT JOIN ReopenedFlag rf ON b.Entry_ID = rf.Entry_ID

UNION ALL

SELECT
    b.IncidentId,
    'Transferred To Another Group' AS ActivityName,
    a.EventTimestamp,
    'Assigned' AS IncidentStatus,
    b.Priority,
    LTRIM(RTRIM(SUBSTRING(a.Fields_Changed, 9, 255))) AS AssignedGroup,
    b.FinalAssignee AS Assignee,
    b.Service,
    b.IncidentCategory,
    b.IncidentResolutionTime,
    b.IsSlaBreached,
    ISNULL(rf.IsReopened, 'false') AS IsReopened
FROM BaseIncidents b
JOIN AuditChanges a ON b.Entry_ID = a.Entry_ID
WHERE SUBSTRING(a.Fields_Changed, 1, 8) = '1000000217' AND a.Previous_Value <> ''
LEFT JOIN ReopenedFlag rf ON b.Entry_ID = rf.Entry_ID

UNION ALL

SELECT
    b.IncidentId,
    'Pending Customer Input' AS ActivityName,
    a.EventTimestamp,
    'Pending' AS IncidentStatus,
    b.Priority,
    b.FinalAssignedGroup AS AssignedGroup,
    b.FinalAssignee AS Assignee,
    b.Service,
    b.IncidentCategory,
    b.IncidentResolutionTime,
    b.IsSlaBreached,
    ISNULL(rf.IsReopened, 'false') AS IsReopened
FROM BaseIncidents b
JOIN AuditChanges a ON b.Entry_ID = a.Entry_ID
WHERE SUBSTRING(a.Fields_Changed, 1, 8) = '7       ' AND CHARINDEX('Pending', a.Fields_Changed) > 0
LEFT JOIN ReopenedFlag rf ON b.Entry_ID = rf.Entry_ID

UNION ALL

-- Capturing this as 'Resolution Implemented' based on status change
SELECT
    b.IncidentId,
    'Resolution Implemented' AS ActivityName,
    a.EventTimestamp,
    'Resolved' AS IncidentStatus,
    b.Priority,
    b.FinalAssignedGroup AS AssignedGroup,
    b.FinalAssignee AS Assignee,
    b.Service,
    b.IncidentCategory,
    b.IncidentResolutionTime,
    b.IsSlaBreached,
    ISNULL(rf.IsReopened, 'false') AS IsReopened
FROM BaseIncidents b
JOIN AuditChanges a ON b.Entry_ID = a.Entry_ID
WHERE SUBSTRING(a.Fields_Changed, 1, 8) = '7       ' AND CHARINDEX('Resolved', a.Fields_Changed) > 0
LEFT JOIN ReopenedFlag rf ON b.Entry_ID = rf.Entry_ID

UNION ALL

-- Capturing 'Awaiting User Confirmation' from the same status change event
SELECT
    b.IncidentId,
    'Awaiting User Confirmation' AS ActivityName,
    a.EventTimestamp,
    'Resolved' AS IncidentStatus,
    b.Priority,
    b.FinalAssignedGroup AS AssignedGroup,
    b.FinalAssignee AS Assignee,
    b.Service,
    b.IncidentCategory,
    b.IncidentResolutionTime,
    b.IsSlaBreached,
    ISNULL(rf.IsReopened, 'false') AS IsReopened
FROM BaseIncidents b
JOIN AuditChanges a ON b.Entry_ID = a.Entry_ID
WHERE SUBSTRING(a.Fields_Changed, 1, 8) = '7       ' AND CHARINDEX('Resolved', a.Fields_Changed) > 0
LEFT JOIN ReopenedFlag rf ON b.Entry_ID = rf.Entry_ID

UNION ALL

SELECT
    b.IncidentId,
    'Incident Reopened' AS ActivityName,
    a.EventTimestamp,
    LTRIM(RTRIM(SUBSTRING(a.Fields_Changed, 9, 255))) AS IncidentStatus,
    b.Priority,
    b.FinalAssignedGroup AS AssignedGroup,
    b.FinalAssignee AS Assignee,
    b.Service,
    b.IncidentCategory,
    b.IncidentResolutionTime,
    b.IsSlaBreached,
    'true' AS IsReopened
FROM BaseIncidents b
JOIN AuditChanges a ON b.Entry_ID = a.Entry_ID
WHERE 
    SUBSTRING(a.Fields_Changed, 1, 8) = '7       ' 
    AND CHARINDEX('Resolved', a.Previous_Value) > 0 
    AND CHARINDEX('Resolved', a.Fields_Changed) = 0
LEFT JOIN ReopenedFlag rf ON b.Entry_ID = rf.Entry_ID

UNION ALL

-- Using Last_Resolved_Date for the official 'Incident Resolved' activity
SELECT
    b.IncidentId,
    'Incident Resolved' AS ActivityName,
    b.Last_Resolved_Date AS EventTimestamp,
    'Resolved' AS IncidentStatus,
    b.Priority,
    b.FinalAssignedGroup AS AssignedGroup,
    b.FinalAssignee AS Assignee,
    b.Service,
    b.IncidentCategory,
    b.IncidentResolutionTime,
    b.IsSlaBreached,
    ISNULL(rf.IsReopened, 'false') AS IsReopened
FROM BaseIncidents b
LEFT JOIN ReopenedFlag rf ON b.Entry_ID = rf.Entry_ID
WHERE b.Last_Resolved_Date IS NOT NULL

UNION ALL

-- Inferring 'User Confirmation Received' from the closure event
SELECT
    b.IncidentId,
    'User Confirmation Received' AS ActivityName,
    b.Closed_Date AS EventTimestamp,
    'Closed' AS IncidentStatus,
    b.Priority,
    b.FinalAssignedGroup AS AssignedGroup,
    b.FinalAssignee AS Assignee,
    b.Service,
    b.IncidentCategory,
    b.IncidentResolutionTime,
    b.IsSlaBreached,
    ISNULL(rf.IsReopened, 'false') AS IsReopened
FROM BaseIncidents b
LEFT JOIN ReopenedFlag rf ON b.Entry_ID = rf.Entry_ID
WHERE b.Closed_Date IS NOT NULL

UNION ALL

SELECT
    b.IncidentId,
    'SLA Breach' AS ActivityName,
    b.Target_Date AS EventTimestamp,
    b.FinalStatus AS IncidentStatus,
    b.Priority,
    b.FinalAssignedGroup AS AssignedGroup,
    b.FinalAssignee AS Assignee,
    b.Service,
    b.IncidentCategory,
    b.IncidentResolutionTime,
    'true' AS IsSlaBreached,
    ISNULL(rf.IsReopened, 'false') AS IsReopened
FROM BaseIncidents b
LEFT JOIN ReopenedFlag rf ON b.Entry_ID = rf.Entry_ID
WHERE b.IsSlaBreached = 'true' AND b.Target_Date IS NOT NULL

UNION ALL

SELECT
    b.IncidentId,
    'Incident Cancelled' AS ActivityName,
    a.EventTimestamp,
    'Cancelled' AS IncidentStatus,
    b.Priority,
    b.FinalAssignedGroup AS AssignedGroup,
    b.FinalAssignee AS Assignee,
    b.Service,
    b.IncidentCategory,
    b.IncidentResolutionTime,
    b.IsSlaBreached,
    ISNULL(rf.IsReopened, 'false') AS IsReopened
FROM BaseIncidents b
JOIN AuditChanges a ON b.Entry_ID = a.Entry_ID
WHERE SUBSTRING(a.Fields_Changed, 1, 8) = '7       ' AND CHARINDEX('Cancelled', a.Fields_Changed) > 0
LEFT JOIN ReopenedFlag rf ON b.Entry_ID = rf.Entry_ID

UNION ALL

SELECT
    b.IncidentId,
    'Incident Closed' AS ActivityName,
    b.Closed_Date AS EventTimestamp,
    'Closed' AS IncidentStatus,
    b.Priority,
    b.FinalAssignedGroup AS AssignedGroup,
    b.FinalAssignee AS Assignee,
    b.Service,
    b.IncidentCategory,
    b.IncidentResolutionTime,
    b.IsSlaBreached,
    ISNULL(rf.IsReopened, 'false') AS IsReopened
FROM BaseIncidents b
LEFT JOIN ReopenedFlag rf ON b.Entry_ID = rf.Entry_ID
WHERE b.Closed_Date IS NOT NULL;

Étapes

Prérequis et configuration de l’environnement : Vérifiez que Python 3.6 ou une version ultérieure est installé. Installez la bibliothèque requests nécessaire en exécutant pip install requests dans votre ligne de commande ou votre terminal. Obtenez les identifiants API (nom d’utilisateur et mot de passe) d’un compte BMC Helix disposant au minimum d’un accès en lecture aux formulaires « HPD:Help Desk » et « HPD:Help Desk Audit Log ».
Configurez le script Python : Copiez le script Python fourni dans un fichier, par exemple extract_incidents.py. Ouvrez le fichier et modifiez les variables de configuration en haut, notamment HELIX_HOSTNAME, HELIX_USERNAME, HELIX_PASSWORD, START_DATE, END_DATE et COMPANY_NAME, selon votre environnement et le périmètre de données souhaité.
Comprenez l’authentification : Le script commence par appeler le point de terminaison /api/jwt/login pour s’authentifier auprès de votre instance BMC Helix. Il récupère un jeton Web JSON (JWT), ensuite utilisé dans l’en-tête d’autorisation pour toutes les demandes de données.
Exécutez le script : Lancez le script depuis votre terminal avec la commande python extract_incidents.py. Le script démarre et affiche sa progression dans la console.
Récupérez les données initiales sur les incidents : Le script interroge le point de terminaison de l’API REST « HPD:Help Desk » pour obtenir la liste des incidents créés pendant la période indiquée. Il utilise la pagination (paramètres limit et offset) pour traiter efficacement un grand nombre d’incidents sans surcharger l’API.
Récupérez le journal d’audit : Pour chaque incident obtenu à l’étape précédente, le script effectue un appel API distinct au formulaire « HPD:Help Desk Audit Log ». Il récupère ainsi l’historique détaillé des modifications de chaque incident, indispensable pour repérer des activités comme les changements de statut et les réaffectations.
Déduisez les événements et appliquez la logique : Le script traite les données en mémoire. Il associe l’enregistrement principal de l’incident à son journal d’audit correspondant, puis parcourt les entrées du journal triées pour déduire les activités indiquées. Par exemple, la première apparition du champ « Assigned Group » dans le journal génère un événement « Group Assigned ». Un changement de statut de « Resolved » à « In Progress » génère un événement « Incident Reopened ».
Gérez les événements calculés : Le script calcule les événements qui ne sont pas consignés directement. L’événement « Incident Reported » est créé à partir de « Submit Date ». Le dépassement de SLA est déterminé en comparant « Last Resolved Date » à « Target Date ».
Structurez les données : Pour chaque activité repérée, le script crée un dictionnaire contenant IncidentId, ActivityName, EventTimestamp ainsi que tous les autres attributs requis et recommandés. Ces dictionnaires sont regroupés dans une seule liste.
Générez le fichier CSV : Une fois le traitement de tous les incidents et de leurs activités terminé, le script utilise la bibliothèque csv intégrée à Python pour écrire le journal d’événements final dans un fichier nommé bmc_helix_incident_log.csv. Ce fichier est créé dans le répertoire depuis lequel le script a été exécuté.
Vérifiez et importez le fichier : Ouvrez le fichier CSV généré dans un tableur et vérifiez son contenu. Assurez-vous que les colonnes et les données sont correctes. Le fichier est alors prêt à être importé dans ProcessMind pour analyse.

Configuration

HELIX_HOSTNAME : URL de base de votre environnement BMC Helix ITSM, par exemple, « https://your-company.bmc.com ».
HELIX_USERNAME : Nom d’utilisateur du compte API utilisé pour l’authentification.
HELIX_PASSWORD : Mot de passe du compte API. Dans un environnement de production, il est recommandé d’utiliser des variables d’environnement ou un outil sécurisé de gestion des secrets pour stocker les identifiants.
START_DATE / END_DATE : Période d’extraction, au format « YYYY-MM-DDTHH:MM:SS.sssZ ». Pour une première analyse, une période de 3 à 6 mois est recommandée afin d’obtenir un échantillon représentatif sans volume excessif.
COMPANY_NAME : Nom de l’entreprise dont vous souhaitez filtrer les incidents. Ce paramètre est essentiel dans un environnement multi-tenant pour délimiter correctement les données. Si ce filtre n’est pas nécessaire, vous pouvez définir la valeur sur None.
PAGE_SIZE : Nombre d’incidents à récupérer par demande API. Une valeur comprise entre 500 et 1 000 est généralement efficace, mais peut nécessiter un ajustement selon les performances de votre instance et les limites de fréquence de l’API.
Prérequis : Le script nécessite un compte utilisateur BMC Helix disposant au minimum d’un accès en lecture aux formulaires HPD:Help Desk et HPD:Help Desk Audit Log. Sans accès aux deux formulaires, l’extraction sera incomplète.

Exemple de requête python

import requests
import json
import csv
from datetime import datetime
import time

class=class="hl-string">"hl-comment"># --- Configuration Settings ---
HELIX_HOSTNAME = class="hl-string">"https://[your-helix-instance].bmc.com"
HELIX_USERNAME = class="hl-string">"[your_api_username]"
HELIX_PASSWORD = class="hl-string">"[your_api_password]"

class=class="hl-string">"hl-comment"># Date range for the query (ISO 8601 format)
START_DATE = class="hl-string">"2023-01-01T00:00:00.000Z"
END_DATE = class="hl-string">"2023-12-31T23:59:59.000Z"

class=class="hl-string">"hl-comment"># Optional: Filter by company for multi-tenant environments
COMPANY_NAME = class="hl-string">"[Your Company Name]"  class=class="hl-string">"hl-comment"># Set to None if not needed

PAGE_SIZE = 1000
OUTPUT_CSV_FILE = class="hl-string">'bmc_helix_incident_log.csv'

class=class="hl-string">"hl-comment"># --- End of Configuration ---

def get_jwt_token(session):
    class="hl-string">"""Authenticates with the BMC Helix API and returns a JWT token."""
    login_url = fclass="hl-string">"{HELIX_HOSTNAME}/api/jwt/login"
    auth_data = {class="hl-string">'username': HELIX_USERNAME, class="hl-string">'password': HELIX_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 get_all_incidents(session, token):
    class="hl-string">"""Retrieves all incident records within the specified date range."""
    all_incidents = []
    offset = 0
    url = fclass="hl-string">"{HELIX_HOSTNAME}/api/arsys/v1/entry/HPD:Help Desk"
    headers = {class="hl-string">'Authorization': fclass="hl-string">'AR-JWT {token}', class="hl-string">'Content-Type': class="hl-string">'application/json'}
    
    qualification = fclass="hl-string">"'Submit Date' >= \"{START_DATE}\class="hl-string">" AND 'Submit Date' <= \"{END_DATE}\class="hl-string">""
    if COMPANY_NAME:
        qualification += fclass="hl-string">" AND 'Company' = \"{COMPANY_NAME}\class="hl-string">""

    fields = (
        class="hl-string">"Incident Number,Submit Date,Last Resolved Date,Closed Date,Status,Priority,Assigned Group,"
        class="hl-string">"Assignee,ServiceCI,Operational Categorization Tier 1,Operational Categorization Tier 2,"
        class="hl-string">"Product Categorization Tier 1,Product Categorization Tier 2,Target Date"
    )

    while True:
        params = {class="hl-string">'q': qualification, class="hl-string">'fields': fclass="hl-string">'values({fields})', class="hl-string">'limit': PAGE_SIZE, class="hl-string">'offset': offset}
        print(fclass="hl-string">"Fetching incidents, offset: {offset}...")
        try:
            response = session.get(url, headers=headers, params=params)
            response.raise_for_status()
            data = response.json()
            entries = data.get(class="hl-string">'entries', [])
            if not entries:
                break
            all_incidents.extend(entries)
            offset += len(entries)
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching incidents: {e}")
            break
    return all_incidents

def get_audit_log(session, token, incident_id):
    class="hl-string">"""Retrieves the audit log for a single incident."""
    url = fclass="hl-string">"{HELIX_HOSTNAME}/api/arsys/v1/entry/HPD:Help Desk Audit Log"
    headers = {class="hl-string">'Authorization': fclass="hl-string">'AR-JWT {token}', class="hl-string">'Content-Type': class="hl-string">'application/json'}
    qualification = fclass="hl-string">"'Incident Number' = \"{incident_id}\class="hl-string">""
    fields = class="hl-string">"Log,Fields Changed,Log Key,Audit Date"
    params = {class="hl-string">'q': qualification, class="hl-string">'fields': fclass="hl-string">'values({fields})'}
    try:
        response = session.get(url, headers=headers, params=params)
        response.raise_for_status()
        data = response.json()
        return sorted(data.get(class="hl-string">'entries', []), key=lambda x: x[class="hl-string">'values'][class="hl-string">'Audit Date'])
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Error fetching audit log for {incident_id}: {e}")
        return []

def parse_timestamp(ts):
    if not ts: return None
    try:
        return datetime.strptime(ts, class="hl-string">'%Y-%m-%dT%H:%M:%S.%f%z').strftime(class="hl-string">'%Y-%m-%d %H:%M:%S')
    except ValueError:
        try:
            return datetime.strptime(ts, class="hl-string">'%Y-%m-%dT%H:%M:%S%z').strftime(class="hl-string">'%Y-%m-%d %H:%M:%S')
        except ValueError:
            return ts

def main():
    event_log = []
    with requests.Session() as session:
        token = get_jwt_token(session)
        if not token:
            return

        incidents = get_all_incidents(session, token)
        total = len(incidents)
        print(fclass="hl-string">"Found {total} incidents to process.")

        for index, incident_entry in enumerate(incidents):
            incident = incident_entry[class="hl-string">'values']
            incident_id = incident.get(class="hl-string">'Incident Number')
            print(fclass="hl-string">"Processing incident {index + 1}/{total}: {incident_id}")

            base_attributes = {
                class="hl-string">'IncidentId': incident_id,
                class="hl-string">'Priority': incident.get(class="hl-string">'Priority'),
                class="hl-string">'Service': incident.get(class="hl-string">'ServiceCI'),
                class="hl-string">'IncidentCategory': fclass="hl-string">"{incident.get('Product Categorization Tier 1', '')} / {incident.get('Product Categorization Tier 2', '')}",
            }
            
            class=class="hl-string">"hl-comment"># 1. Incident Reported
            event_log.append({
                **base_attributes,
                class="hl-string">'ActivityName': class="hl-string">'Incident Reported',
                class="hl-string">'EventTimestamp': parse_timestamp(incident.get(class="hl-string">'Submit Date')),
                class="hl-string">'IncidentStatus': class="hl-string">'New', class=class="hl-string">"hl-comment"># Typically starts as New
                class="hl-string">'AssignedGroup': incident.get(class="hl-string">'Assigned Group'),
                class="hl-string">'Assignee': incident.get(class="hl-string">'Assignee'),
            })

            audit_entries = get_audit_log(session, token, incident_id)

            current_group = None
            last_status = class="hl-string">'New'
            is_reopened = False
            group_assigned = False

            for audit in audit_entries:
                audit_values = audit[class="hl-string">'values']
                event_ts = parse_timestamp(audit_values.get(class="hl-string">'Audit Date'))
                log_key = audit_values.get(class="hl-string">'Log Key')
                fields_changed = audit_values.get(class="hl-string">'Fields Changed', class="hl-string">'')

                class=class="hl-string">"hl-comment"># 2. Group Assigned & 3. Transferred To Another Group
                if class="hl-string">'Assigned Group' in fields_changed:
                    new_group = audit_values.get(class="hl-string">'Log').split(class="hl-string">'\n')[0]
                    if new_group and not group_assigned:
                        activity = class="hl-string">'Group Assigned'
                        group_assigned = True
                    elif new_group and new_group != current_group:
                        activity = class="hl-string">'Transferred To Another Group'
                    else:
                        continue
                    current_group = new_group
                    event_log.append({**base_attributes, class="hl-string">'ActivityName': activity, class="hl-string">'EventTimestamp': event_ts, class="hl-string">'IncidentStatus': last_status, class="hl-string">'AssignedGroup': current_group, class="hl-string">'Assignee': None})

                class=class="hl-string">"hl-comment"># Status-based activities
                if class="hl-string">'Status' in fields_changed:
                    new_status_str = audit_values.get(class="hl-string">'Log').split(class="hl-string">'\n')[0]
                    new_status_map = {
                        class="hl-string">'In Progress': class="hl-string">'Investigation Initiated',
                        class="hl-string">'Pending': class="hl-string">'Pending Customer Input',
                        class="hl-string">'Resolved': class="hl-string">'Resolution Implemented', class=class="hl-string">"hl-comment"># First event is implementation
                        class="hl-string">'Cancelled': class="hl-string">'Incident Cancelled',
                        class="hl-string">'Closed': class="hl-string">'Incident Closed' class=class="hl-string">"hl-comment"># Final closure
                    }
                    
                    if last_status == class="hl-string">'Resolved' and new_status_str in [class="hl-string">'In Progress', class="hl-string">'Assigned']:
                        is_reopened = True
                        event_log.append({**base_attributes, class="hl-string">'ActivityName': class="hl-string">'Incident Reopened', class="hl-string">'EventTimestamp': event_ts, class="hl-string">'IncidentStatus': new_status_str, class="hl-string">'AssignedGroup': current_group, class="hl-string">'Assignee': None})

                    if new_status_str in new_status_map:
                        activity = new_status_map[new_status_str]
                        event_log.append({**base_attributes, class="hl-string">'ActivityName': activity, class="hl-string">'EventTimestamp': event_ts, class="hl-string">'IncidentStatus': new_status_str, class="hl-string">'AssignedGroup': current_group, class="hl-string">'Assignee': None})
                        class=class="hl-string">"hl-comment"># Add specific Resolution/Confirmation events
                        if new_status_str == class="hl-string">'Resolved':
                             event_log.append({**base_attributes, class="hl-string">'ActivityName': class="hl-string">'Incident Resolved', class="hl-string">'EventTimestamp': event_ts, class="hl-string">'IncidentStatus': new_status_str, class="hl-string">'AssignedGroup': current_group, class="hl-string">'Assignee': None})
                             event_log.append({**base_attributes, class="hl-string">'ActivityName': class="hl-string">'Awaiting User Confirmation', class="hl-string">'EventTimestamp': event_ts, class="hl-string">'IncidentStatus': new_status_str, class="hl-string">'AssignedGroup': current_group, class="hl-string">'Assignee': None})
                    
                    last_status = new_status_str

            class=class="hl-string">"hl-comment"># 4. Incident Categorized (approximated as last categorization change before resolution)
            cat_events = [a for a in audit_entries if class="hl-string">'Operational Categorization Tier 1' in a[class="hl-string">'values'].get(class="hl-string">'Fields Changed', class="hl-string">'') or class="hl-string">'Product Categorization Tier 1' in a[class="hl-string">'values'].get(class="hl-string">'Fields Changed', class="hl-string">'')]
            if cat_events:
                last_cat_event = cat_events[-1]
                event_log.append({**base_attributes, class="hl-string">'ActivityName': class="hl-string">'Incident Categorized', class="hl-string">'EventTimestamp': parse_timestamp(last_cat_event[class="hl-string">'values'][class="hl-string">'Audit Date']), class="hl-string">'IncidentStatus': last_status, class="hl-string">'AssignedGroup': current_group, class="hl-string">'Assignee': None})

            class=class="hl-string">"hl-comment"># Add placeholder for User Confirmation Received - often not explicit
            if incident.get(class="hl-string">'Status') == class="hl-string">'Closed' and incident.get(class="hl-string">'Last Resolved Date'):
                class=class="hl-string">"hl-comment"># This is an approximation, real confirmation might be earlier
                event_log.append({**base_attributes, class="hl-string">'ActivityName': class="hl-string">'User Confirmation Received', class="hl-string">'EventTimestamp': parse_timestamp(incident.get(class="hl-string">'Closed Date')), class="hl-string">'IncidentStatus': class="hl-string">'Closed', class="hl-string">'AssignedGroup': current_group, class="hl-string">'Assignee': None})

            class=class="hl-string">"hl-comment"># 5. SLA Breach (calculated)
            is_sla_breached = False
            target_date_str = incident.get(class="hl-string">'Target Date')
            resolved_date_str = incident.get(class="hl-string">'Last Resolved Date')
            if target_date_str and resolved_date_str:
                target_dt = datetime.strptime(target_date_str, class="hl-string">'%Y-%m-%dT%H:%M:%S%z')
                resolved_dt = datetime.strptime(resolved_date_str, class="hl-string">'%Y-%m-%dT%H:%M:%S%z')
                if resolved_dt > target_dt:
                    is_sla_breached = True
                    event_log.append({**base_attributes, class="hl-string">'ActivityName': class="hl-string">'SLA Breach', class="hl-string">'EventTimestamp': parse_timestamp(target_date_str), class="hl-string">'IncidentStatus': incident.get(class="hl-string">'Status'), class="hl-string">'AssignedGroup': incident.get(class="hl-string">'Assigned Group'), class="hl-string">'Assignee': incident.get(class="hl-string">'Assignee')})

            class=class="hl-string">"hl-comment"># Final attributes update
            resolution_time = None
            if incident.get(class="hl-string">'Submit Date') and incident.get(class="hl-string">'Last Resolved Date'):
                submit_dt = datetime.strptime(incident.get(class="hl-string">'Submit Date'), class="hl-string">'%Y-%m-%dT%H:%M:%S%z')
                resolved_dt = datetime.strptime(incident.get(class="hl-string">'Last Resolved Date'), class="hl-string">'%Y-%m-%dT%H:%M:%S%z')
                resolution_time = (resolved_dt - submit_dt).total_seconds()
            
            for event in event_log:
                if event[class="hl-string">'IncidentId'] == incident_id:
                    event[class="hl-string">'IsSlaBreached'] = is_sla_breached
                    event[class="hl-string">'IsReopened'] = is_reopened
                    event[class="hl-string">'IncidentResolutionTime'] = resolution_time
            
            time.sleep(0.1) class=class="hl-string">"hl-comment"># Small delay to be kind to the API

    class=class="hl-string">"hl-comment"># Write to CSV
    if event_log:
        fieldnames = [class="hl-string">'IncidentId', class="hl-string">'ActivityName', class="hl-string">'EventTimestamp', class="hl-string">'IncidentStatus', class="hl-string">'Priority', class="hl-string">'AssignedGroup', class="hl-string">'Assignee', class="hl-string">'Service', class="hl-string">'IncidentCategory', class="hl-string">'IncidentResolutionTime', class="hl-string">'IsSlaBreached', class="hl-string">'IsReopened']
        with open(OUTPUT_CSV_FILE, class="hl-string">'w', newline=class="hl-string">'', encoding=class="hl-string">'utf-8') as f:
            writer = csv.DictWriter(f, fieldnames=fieldnames, extrasaction=class="hl-string">'ignore')
            writer.writeheader()
            writer.writerows(sorted(event_log, key=lambda x: (x[class="hl-string">'IncidentId'], x[class="hl-string">'EventTimestamp'])))
        print(fclass="hl-string">"Successfully wrote {len(event_log)} events to {OUTPUT_CSV_FILE}")
    else:
        print(class="hl-string">"No events were generated.")

if __name__ == class="hl-string">"__main__":
    main()

Prêt à commencer ?

Utilisez ce modèle pour lancer votre démarche de Process Mining et repérer des pistes d’amélioration dans les données de gestion des incidents. Commencez dès aujourd’hui à optimiser vos opérations.

Retour au guide d’amélioration

Télécharger le modèle

Réglez dès aujourd’hui les incidents récurrents dans BMC Helix ITSM !

Réduisez le MTTR de 35 % et évitez les dépassements de SLA pour améliorer la satisfaction des utilisateurs.

Démarrez votre essai gratuit

Aucune carte bancaire requise. Essai gratuit de 14 jours.

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

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

Attributs de gestion des incidents

Activités de gestion des incidents

Guides d’extraction

Exporter les rapports Smart Reporting de BMC Helix au format CSV

Étapes

Configuration

Exemple de requête sql

Requête SQL directe sur les tables d’incidents de la base de données ITSM

Étapes

Configuration

Exemple de requête sql

Extraction par script Python via l’API REST de BMC Helix

Étapes

Configuration

Exemple de requête python

Prêt à commencer ?

Réglez dès aujourd’hui les incidents récurrents dans BMC Helix ITSM !

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

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

Attributs de gestion des incidents

Activités de gestion des incidents

Guides d’extraction

Exporter les rapports Smart Reporting de BMC Helix au format CSV

Étapes

Configuration

Exemple de requête sql

Requête SQL directe sur les tables d’incidents de la base de données ITSM

Étapes

Configuration

Exemple de requête sql

Extraction par script Python via l’API REST de BMC Helix

Étapes

Configuration

Exemple de requête python

Prêt à commencer ?

Réglez dès aujourd’hui les incidents récurrents dans BMC Helix ITSM !

Prêt à commencer ?

Réglez dès aujourd’hui les incidents récurrents dans BMC Helix ITSM !