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

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

BMC Helix ITSM

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

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

Ce modèle fournit un guide complet pour recueillir les données essentielles à l’optimisation de votre processus de gestion des incidents. Il présente les attributs et les activités importants à suivre, ainsi que des conseils pratiques pour extraire ces données. Utilisez cette ressource pour simplifier la préparation de vos données et accélérer votre démarche d’analyse des processus.

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

Vous découvrez les journaux d’événements ? En savoir plus sur la création d’un journal d’événements pour le Process Mining.

Télécharger le modèle

Attributs de la 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
	Identifiant de l’incident IncidentId	Identifiant unique de chaque enregistrement d’incident.
Description L’Incident ID est la clé primaire de chaque incident et l’identifie de manière unique, de sa création à sa clôture. Il relie toutes les activités, tous les journaux et toutes les modifications associés, ce qui permet d’obtenir une vue complète du cycle de vie de l’incident, de bout en bout. Dans le Process Mining, cet attribut est fondamental, car il définit le cas. Chaque événement associé au même Incident ID est considéré comme faisant partie de la même instance de processus, ce qui permet de reconstituer et d’analyser le traitement de chaque incident. Pourquoi c’est important Il s’agit de l’identifiant de cas essentiel qui relie tous les événements du cycle de vie d’un incident et rend possible l’analyse du processus de bout en bout. Où les obtenir Il s’agit du champ « Incident Number » (Field ID : 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 le moment où 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 déroulement du processus à partir des données brutes. L’horodatage de l’événement est indispensable à toutes les analyses fondées sur le temps, notamment au calcul des temps de cycle entre les activités, à l’identification des goulots d’étranglement lorsque les incidents restent longtemps en attente et à la mesure des délais globaux de résolution. Il constitue la base temporelle de l’analyse du processus. Pourquoi c’est important Cet horodatage fournit l’ordre chronologique des événements, indispensable pour calculer les durées, identifier les goulots d’étranglement et comprendre la chronologie du processus. Où les obtenir Le champ « Last Modified Date » (Field ID : 6) ou les champs de date spécifiques du formulaire « HPD:Help Desk ». Pour les événements historiques, cette information provient du champ d’horodatage de l’Event Log. 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 spécifique survenu au cours du cycle de vie de l’incident.
Description Cet attribut décrit l’activité réalisée à un moment précis pour un incident, comme « Incident Reported », « Group Assigned » ou « Incident Resolved ». Ces activités constituent les éléments de base de la carte du processus. L’analyse de leur séquence et de leur fréquence révèle le déroulement réel du processus, identifie les parcours courants et met en évidence les écarts par rapport à la procédure standard. Elle est essentielle pour comprendre les actions réalisées afin de résoudre un incident. Pourquoi c’est 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ù les obtenir Généralement dérivé des modifications des champs « Status » (Field ID : 7) et « Status_Reason » du formulaire « HPD:Help Desk », ou du formulaire « HPD:Help Desk Audit Log ». Exemples Incident signaléGroupe assignéRésolution mise en œuvreIncident clôturé
	Assignataire Assignee	Utilisateur chargé de traiter l’incident.
Description L’assignataire est l’agent de support ou le technicien précisément responsable de l’incident à un moment donné. Il fournit un niveau de détail plus fin que le groupe assigné. L’analyse des performances par assignataire peut aider à identifier les agents les plus performants, ceux qui ont besoin d’une formation complémentaire et les déséquilibres dans la répartition de la charge de travail. Elle sert également à retracer la séquence exacte des actions réalisées par les personnes qui traitent un incident complexe. Pourquoi c’est important Fournit une vision détaillée de la répartition de la charge de travail et des performances individuelles, afin d’identifier les agents les plus performants ou ceux qui ont besoin d’un accompagnement. Où les obtenir Il s’agit du champ « Assignee » (Field ID : 1000000218) du formulaire « HPD:Help Desk ». Exemples Bob SmithAlice JohnsonCharlie Brown
	Catégorie de l’incident IncidentCategory	La classification de l’incident, souvent organisée selon une structure à plusieurs niveaux.
Description La catégorisation des incidents fournit une méthode structurée pour les classer, généralement au moyen d’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’orientation, le reporting et l’analyse des tendances. Dans le Process Mining, la catégorisation sert à analyser séparément les différents types d’incidents. Elle alimente le Dashboard « Précision de la catégorisation des incidents » en comparant les catégories initiales et finales, et contribue à identifier les tendances du Dashboard « Tendances des causes racines ». Pourquoi c’est important La catégorisation permet d’orienter correctement les incidents, d’analyser les tendances et de comparer les performances entre les différents types d’incidents. Où les obtenir Il s’agit des champs « Operational Categorization Tier 1/2/3 » du formulaire « HPD:Help Desk ». Exemples Matériel > Ordinateur portable > BatterieLogiciel > Application d'entreprise > Erreur de connexionRéseau > Connectivité > Wi-Fi
	Groupe assigné AssignedGroup	Groupe de support responsable du traitement de l’incident.
Description Cet attribut identifie 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 est essentiel pour comprendre la circulation du travail entre les équipes. Cet attribut sert à analyser les transferts entre équipes, à identifier les goulots d’étranglement causés par certains groupes et à mesurer le taux de réaffectation des incidents. Il aide à visualiser le parcours d’un incident dans l’organisation et met en évidence les zones où le routage est inefficace ou les connaissances insuffisantes. Pourquoi c’est important Le suivi du groupe auquel l’incident est affecté aide à analyser les transferts, à identifier les boucles de réaffectation et à localiser les goulots d’étranglement au sein de certaines équipes. Où les obtenir Il s’agit du champ « Assigned Group » (Field ID : 1000000217) du formulaire « HPD:Help Desk ». Exemples Centre de servicesOpérations réseauSupport applicatif niveau 2Services d'infrastructure
	Incident rouvert IsReopened	Un indicateur précisant si un incident a été rouvert après avoir été placé au statut « Resolved ».
Description Cet attribut booléen vaut true lorsque le statut d’un incident repasse à un état actif, tel que « In Progress », après avoir été marqué « Resolved ». Cela indique que la correction initiale n’était pas efficace ou complète. Il mesure directement le retravail et sert à calculer le KPI « Taux de retravail des incidents ». L’analyse des incidents rouverts aide à identifier 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 « Parcours de retravail et d’escalade ». Pourquoi c’est important Mesure directement le retravail et la qualité des résolutions. Un taux élevé de réouverture révèle des corrections inefficaces et des faiblesses dans le processus. Où les obtenir Calculé en analysant la séquence des activités d’un incident. Si une activité « Incident Reopened » ou similaire apparaît après une activité « Resolution Implemented », cet indicateur est défini sur true. Exemples truefalse
	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 à partir de la combinaison de l’impact et de l’urgence, et définit l’ordre ainsi que la rapidité de résolution des incidents. Les valeurs courantes vont de « Critical » à « Low ». Dans le Process Mining, l’analyse des incidents par priorité est essentielle pour évaluer les performances. Elle permet de répondre à des questions telles que « Respectons-nous les SLA des 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 métier les plus importants. Pourquoi c’est important Cet attribut est essentiel pour segmenter l’analyse, afin que les incidents hautement prioritaires soient traités plus rapidement et respectent leurs objectifs de niveau de service spécifiques. Où les obtenir Il s’agit du champ « Priority » (Field ID : 1000000164) du formulaire « HPD:Help Desk ». Exemples CritiqueÉlevéeMoyenneFaible
	Service Service	Service métier ou technique affecté par l’incident.
Description Cet attribut relie un incident à un service précis défini dans la Configuration Management Database (CMDB), comme « Email Service », « VPN Access » ou « SAP Financials ». Ce lien est essentiel pour comprendre l’impact métier des incidents. L’analyse des incidents par service permet d’identifier les services à l’origine d’un volume élevé d’incidents, de mettre en évidence les problèmes récurrents liés à certaines technologies et de soutenir l’analyse des tendances pour la Gestion des problèmes. Pourquoi c’est important Relier les incidents aux services métier est essentiel pour analyser leur impact et identifier les services les plus exposés aux problèmes. Où les obtenir Il s’agit du champ « ServiceCI » ou d’un champ similaire représentant l’élément de configuration (CI) affecté dans le formulaire « HPD:Help Desk ». Exemples Messagerie d'entrepriseSAP ERPVPN d'accès distantPortail des ressources humaines
	SLA dépassé IsSlaBreached	Un indicateur précisant si l’incident a été résolu après la date cible de son SLA.
Description Cet attribut booléen vaut true lorsque le délai de résolution de l’incident dépasse le SLA défini. Il fournit un résultat binaire clair sur la performance du SLA pour chaque incident. Cet indicateur est essentiel à la création du Dashboard « Vue d’ensemble des performances du SLA des incidents » et au calcul du KPI « Taux de conformité au SLA des incidents ». Il simplifie l’analyse en permettant de filtrer et d’agréger directement tous les incidents qui n’ont pas respecté leurs objectifs de niveau de service, afin d’étudier facilement les raisons des dépassements. Pourquoi c’est important Cet indicateur simplifie l’analyse de la conformité au SLA. Il permet de filtrer facilement tous les incidents ayant dépassé leur SLA et d’en rechercher les causes racines. Où les obtenir Calculé en comparant l’horodatage de l’événement « Incident Resolved » à « SlaTargetDate ». Si l’horodatage de résolution est postérieur à la date cible, cet indicateur vaut 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 fournit un instantané de la position de l’incident dans son cycle de vie. L’analyse des changements de statut est fondamentale pour comprendre le processus de Gestion des incidents. Elle sert à définir les activités, à mesurer le temps passé dans les différents états, par exemple la durée pendant laquelle les incidents restent « Pending », et à identifier les incidents susceptibles d’être bloqués ou inactifs. Pourquoi c’est important Le suivi des changements de statut est essentiel pour comprendre l’avancement de l’incident et mesurer le temps passé dans des états précis comme « Pending » ou « In Progress ». Où les obtenir Il s’agit du champ « Status » (Field ID : 7) du formulaire « HPD:Help Desk ». Exemples NouveauAttribuéEn coursEn attenteRésoluClôturé
	Canal Channel	La méthode utilisée pour signaler l’incident.
Description Cet attribut précise la manière dont l’incident a été soumis, par exemple par téléphone, e-mail, portail en libre-service ou directement auprès du support. Il indique le point d’entrée de l’incident dans le processus de support. L’analyse des incidents par canal peut révéler quels canaux sont les plus efficaces ou lesquels génèrent des incidents plus faciles ou plus difficiles à résoudre. Elle peut également orienter les décisions d’investissement dans l’automatisation ou la formation des utilisateurs, par exemple en encourageant l’utilisation d’un portail en libre-service qui recueille de meilleures données initiales. Pourquoi c’est important La compréhension du canal de soumission permet d’analyser l’efficacité des différentes méthodes de prise en charge et d’orienter les investissements dans le libre-service ou l’automatisation. Où les obtenir Il s’agit du champ « Reported Source » (ID de champ : 1000000215) du formulaire « HPD:Help Desk ». Exemples E-mailTéléphoneLibre-serviceSaisie directe
	Cause racine RootCause	La raison sous-jacente ou la cause ultime de l’incident.
Description La cause racine correspond au problème fondamental qui, s’il était traité, empêcherait l’incident de se reproduire. Elle est souvent identifiée dans le cadre de l’analyse d’un problème associé. Tous les incidents ne disposent pas nécessairement d’une cause racine documentée, mais l’analyse de cet attribut est essentielle à la Gestion des problèmes proactive. Elle alimente le KPI « Taux d’identification des causes racines » et contribue à créer des Dashboards qui suivent les tendances des problèmes récurrents, afin d’orienter la mise en place de solutions permanentes. Pourquoi c’est important L’identification de la cause racine est essentielle à la Gestion des problèmes et aux analyses visant à réduire le volume des incidents récurrents. Où les obtenir Cette information peut figurer dans un champ dédié « Root Cause » de l’incident ou, plus généralement, 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é lors de la clôture d’un incident, qui indique le résultat de sa résolution.
Description Le code de clôture fournit un récapitulatif structuré de la manière dont l’incident a été résolu. Parmi les exemples figurent « Résolu par l’utilisateur », « Aucune anomalie constatée », « Incident en double » ou « Correctif permanent appliqué ». Cet attribut est utile pour analyser l’efficacité et les résultats des résolutions. Il peut aider à repérer les incidents clôturés sans véritable correction ou à mettre en évidence les catégories dans lesquelles les utilisateurs résolvent fréquemment eux-mêmes leurs problèmes, ce qui peut révéler des possibilités d’amélioration des articles de la base de connaissances ou des outils en libre-service. Pourquoi c’est important Fournit des données structurées sur les résultats des résolutions, afin d’analyser l’efficacité des corrections et d’identifier les tendances liées à la clôture des incidents. Où les obtenir Ce champ fait généralement partie des informations de résolution ou de clôture du formulaire « HPD:Help Desk ». Exemples Résolu à distanceIncident en doubleErreur utilisateurAucune action requise
	Date cible du SLA SlaTargetDate	La date et l’heure auxquelles l’incident doit être résolu conformément à son SLA.
Description Cet attribut enregistre l’échéance de résolution de l’incident, telle qu’elle est 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 du KPI « Taux de conformité au SLA des incidents » et à la création de Dashboards visualisant les performances liées aux SLA. Il permet de surveiller de manière proactive les incidents qui approchent de leur échéance. Pourquoi c’est important Il s’agit de la référence utilisée pour mesurer la conformité au SLA. Elle permet de déterminer si un incident a été résolu dans les délais ou si l’accord a été dépassé. Où les obtenir Ces données sont généralement stockées dans le formulaire « SLM:Measurement » et associées à l’incident. Il ne s’agit pas d’un champ direct du 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 initialement.
Description Le déclarant est l’utilisateur final ou le client qui a rencontré le problème et l’a signalé. Il se distingue de l’agent assigné, qui traite l’incident. L’analyse des données par déclarant ou par service peut aider à identifier les groupes d’utilisateurs qui ont besoin de davantage de formation ou ceux qui sont touchés par un type de problème particulier. Elle offre une vision du processus de Gestion des incidents centrée sur le client. Pourquoi c’est important Identifie l’utilisateur qui a signalé le problème et permet d’analyser les tendances propres aux utilisateurs selon leur service, leur localisation ou leur rôle. Où les obtenir Cette information est enregistrée dans le champ « Submitter » ou dans les champs relatifs aux informations client du formulaire « HPD:Help Desk ». Exemples John DoeJane SmithPeter Jones
	Dernière mise à jour des données LastDataUpdate	Horodatage indiquant le moment où les données de cet événement ont été actualisées pour la dernière fois depuis le système source.
Description Cet attribut enregistre la date et l’heure de l’extraction de données la plus récente. Il fournit un contexte sur l’actualité des données analysées, ce qui est important pour comprendre dans quelle mesure les analyses du processus sont à jour. La connaissance de la dernière mise à jour est essentielle pour le reporting et les Dashboards, car elle informe les utilisateurs de l’actualité des données et les aide à savoir si les activités d’incident les plus récentes sont incluses. Pourquoi c’est important Indique l’actualité des données et permet aux utilisateurs de comprendre dans quelle mesure l’analyse du processus et les résultats qui en découlent sont à jour. Où les obtenir Cette valeur est généralement générée et inscrite dans le jeu de données lors du processus d’extraction des données (ETL). Exemples 2023-11-01T02:00:00Z2023-11-02T02:00:00Z2023-11-03T02:00:00Z
	Description de la résolution Resolution	Une description en texte libre des étapes suivies pour résoudre l’incident.
Description Ce champ contient le récapitulatif détaillé, rédigé par un utilisateur, 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 non structurées, ces données textuelles peuvent être analysées au moyen de techniques de text mining afin d’identifier les schémas de résolution courants, d’extraire les mots-clés associés à certains problèmes ou de compléter l’analyse des causes racines. Elles apportent un contexte qualitatif souvent absent des champs de données structurés. Pourquoi c’est important Fournit des informations qualitatives sur la résolution, qui peuvent être utilisées en text mining pour repérer des schémas invisibles dans les données structurées. Où les obtenir Il s’agit du champ « Resolution » (ID de champ : 1000000156) du 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é supprimés, ce qui a résolu le problème de connexion.Le commutateur réseau de la baie IDF 3B a été redémarré.
	Impact Impact	La mesure de l’effet de l’incident sur les processus métier.
Description L’impact évalue l’ampleur des effets négatifs d’un incident sur l’entreprise. Il est souvent défini selon une échelle telle que « Étendu/généralisé », « Important/majeur », « Modéré/limité » ou « Mineur/localisé ». Associé à 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é, indépendamment de leur complexité technique. Elle constitue un élément essentiel pour prioriser les initiatives d’amélioration des processus. Pourquoi c’est important Aide à quantifier la gravité d’un incident pour l’entreprise, un élément important pour déterminer sa priorité et concentrer l’analyse sur les problèmes à fort impact. Où les obtenir Il s’agit du champ « Impact » (ID de champ : 1000000163) du formulaire « HPD:Help Desk ». Exemples 1-Étendue importante/Généralisée2-Significative/Étendue3-Modérée/Limitée4-Mineure/Localisée
	Nombre de réaffectations ReassignmentCount	Le nombre total de fois où un incident a été réaffecté à un autre groupe.
Description Cette mesure compte le nombre de changements du champ « AssignedGroup » au cours du cycle de vie de l’incident. Un nombre élevé peut indiquer des problèmes d’orientation initiale, l’absence de résolution au premier contact ou des problèmes complexes nécessitant l’intervention de plusieurs équipes. Cet attribut alimente directement le KPI « Taux de réaffectation des incidents » et le Dashboard « Analyse du cycle des réaffectations d’incidents ». Il aide à quantifier l’effet de « ping-pong », lorsque les tickets sont transmis d’une équipe à l’autre, ce qui entraîne des retards importants et une perte d’efficacité du processus. Pourquoi c’est important Quantifie les orientations et transferts inefficaces, afin d’identifier les incidents qui restent bloqués dans des boucles de réaffectation entre équipes. Où les obtenir 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 à partir duquel les données des incidents ont été extraites.
Description Cet attribut identifie 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 BMC Helix ITSM précise. Dans l’analyse, il aide à distinguer les processus ou les caractéristiques des données susceptibles de varier entre les systèmes de production, de développement ou existants, tout en garantissant une traçabilité claire et fiable des données. Pourquoi c’est important Identifie l’origine des données, ce qui est essentiel pour leur validation et pour gérer les analyses sur plusieurs systèmes intégrés. Où les obtenir 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 la Gestion des incidents

Voici les principales étapes et les jalons du processus à enregistrer dans votre journal d’événements pour permettre une découverte précise du processus et une visualisation claire du flux.

5 Recommandé 9 Facultatif

	Activité	Description
	Groupe assigné	Cette activité marque l’affectation initiale de l’incident à un groupe de support précis pour investigation. Elle est déduite de la première occurrence où le champ « Assigned Group » est renseigné après la création de l’incident.
Pourquoi c’est important Il s’agit d’une étape clé qui 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ù les obtenir Déduit de l’Event Log (« HPD:HelpDesk_AuditLogSystem ») du formulaire « HPD:Help Desk », qui enregistre le premier renseignement du champ « Assigned Group ». Collecte À partir de l’horodatage du premier renseignement du champ « Assigned Group ». Type d’événement inferred
	Incident clôturé	Il s’agit de la dernière activité, qui marque la clôture officielle de l’enregistrement de l’incident après confirmation de la résolution ou expiration de la période de confirmation. Elle est enregistrée lorsque le statut passe à « Closed ».
Pourquoi c’est 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ù les obtenir Cet événement correspond au passage du champ « Status » du formulaire « HPD:Help Desk » à « Closed ». L’horodatage est enregistré dans le champ « Closed Date » et dans l’Event Log. Collecte À partir de l’horodatage « Closed Date » ou du changement de statut vers « 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 est défini sur « Resolved ».
Pourquoi c’est important Il s’agit de l’étape la plus importante pour mesurer la conformité aux SLA et le délai de résolution. Elle indique que le service a été rétabli pour l’utilisateur. Où les obtenir Cet événement correspond au passage du champ « Status » du formulaire « HPD:Help Desk » à « Resolved ». L’horodatage est enregistré dans le champ « Last Resolved Date » et dans l’Event Log. Collecte À partir de l’horodatage du changement de statut vers « Resolved » dans l’Event Log. Type d’événement inferred
	Incident signalé	Cette activité correspond à la création initiale de l’enregistrement de l’incident dans le système. Elle est capturée explicitement à partir de l’horodatage de création de l’incident dans le formulaire principal de Gestion des incidents.
Pourquoi c’est important Il s’agit de l’événement de début principal du cycle de vie de l’incident. Il est essentiel pour calculer les délais globaux de résolution et comprendre le rythme d’arrivée des incidents. Où les obtenir Cet événement correspond à la création de l’enregistrement dans le formulaire « HPD:Help Desk ». L’horodatage provient généralement du champ « Submit Date » ou « Reported Date ». Collecte À partir de l’horodatage « Submit Date » du formulaire HPD:Help Desk. Type d’événement explicit
	Investigation commencée	Indique qu’un agent de support a commencé à traiter activement l’incident. Cette étape est généralement déduite d’un changement de statut de « Assigned » à « In Progress ».
Pourquoi c’est important Cette étape marque le passage de l’attente dans une file à l’entrée dans la phase de diagnostic. L’analyse du temps d’attente avant le début de l’investigation aide à identifier les contraintes de ressources et alimente le Dashboard « Diagnosis & Investigation Bottlenecks ». Où les obtenir 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 étant extrait de l’Event Log. Collecte Déduit du changement de statut vers « In Progress » dans HPD:HelpDesk_AuditLogSystem. Type d’événement inferred
	Confirmation reçue de l’utilisateur	Indique que l’utilisateur confirme activement que la solution fournie a résolu son problème. Il peut s’agir d’un événement explicite ou d’une étape déduite de notes ou d’une action associée dans le système avant la clôture.
Pourquoi c’est important Le suivi de cette étape donne une vision 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 « Average User Confirmation Time » et d’identifier les lacunes de communication. Où les obtenir Cette information peut être difficile à capturer de manière fiable. Elle peut être déduite d’une entrée dans le journal de travail ou d’une mise à jour précise du motif de statut juste avant le passage de l’incident à « Closed ». L’analyse du formulaire « HPD:WorkLog » peut être nécessaire. Collecte 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	Correspond à une étape où l’avancement de l’incident est suspendu dans l’attente d’informations ou d’une action de l’utilisateur. Cette étape est déduite d’un changement de statut vers l’état « Pending ».
Pourquoi c’est important Cette activité permet de distinguer le temps de travail de l’agent du temps d’attente du client. L’analyse du temps passé 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ù les obtenir 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 ». Collecte Déduit du changement de statut vers « Pending » dans HPD:HelpDesk_AuditLogSystem. Type d’événement inferred
	En attente de confirmation de l’utilisateur	Cette étape intervient après la mise en œuvre d’une résolution, lorsque l’équipe de support attend que l’utilisateur confirme son efficacité. Elle est souvent représentée par le statut « Resolved », qui déclenche le délai avant la clôture automatique.
Pourquoi c’est important Cette activité est essentielle pour le Dashboard « User Confirmation & Verification Delays ». Elle permet de mesurer les délais entre la fourniture d’une correction et sa validation par l’utilisateur, délais qui peuvent prolonger artificiellement le cycle de vie de l’incident. Où les obtenir Cet état commence lorsque le champ « Status » du formulaire « HPD:Help Desk » passe à « Resolved ». La durée est mesurée entre « Last Resolved Date » et le moment où l’incident est soit « Closed », soit « Reopened ». Collecte Commence lors du changement de statut vers « Resolved » et se termine lors du passage à « Closed » ou « In Progress ». Type d’événement inferred
	Incident annulé	Cette activité correspond à l’arrêt d’un incident créé par erreur ou qui n’est plus pertinent. Elle est enregistrée lorsque le statut de l’incident passe à « Cancelled ».
Pourquoi c’est important Il s’agit d’un état final de l’incident, distinct d’une résolution réussie. L’analyse des incidents annulés peut mettre en évidence des problèmes liés aux canaux de création des incidents ou aux signalements en double. Où les obtenir Déduit du formulaire « HPD:Help Desk » lorsque le champ « Status » est mis à jour avec la valeur « Cancelled ». L’horodatage est enregistré dans l’Event Log. Collecte Déduit du changement de statut vers « Cancelled » dans l’Event Log. 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 étape est généralement déduite du renseignement ou de la dernière modification des champs de catégorisation.
Pourquoi c’est important Une catégorisation précise et rapide est essentielle pour assurer une orientation et un reporting efficaces. L’analyse de cette activité permet d’identifier les retards ou les erreurs lors du triage initial et alimente le Dashboard « Incident Categorization Accuracy ». Où les obtenir Déduit de l’Event Log (« 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 ». Collecte À 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	Correspond à un incident précédemment marqué comme résolu, mais réactivé parce que le problème persiste. Cette étape est déduite d’un changement de statut de « Resolved » vers un état actif tel que « In Progress » ou « Assigned ».
Pourquoi c’est important Cette activité mesure directement les reprises et l’efficacité des solutions initiales. Un volume élevé d’incidents rouverts est un indicateur important de la qualité insuffisante des corrections et alimente le KPI « Incident Rework Rate ». Où les obtenir Déduit de l’Event Log (« HPD:HelpDesk_AuditLogSystem »), en détectant pour un Incident ID donné un changement du champ « Status » de « Resolved » à « In Progress » ou « Assigned ». Collecte Déduit de la transition de statut de « Resolved » vers un état actif. Type d’événement inferred
	Résolution mise en œuvre	Cette activité indique qu’une correction ou une solution de contournement a été appliquée par l’équipe de support. Elle est souvent déduite lorsque le statut de l’incident passe à « Resolved ».
Pourquoi c’est important Il s’agit d’une étape importante qui indique qu’une solution a été fournie. Elle constitue un point de mesure essentiel pour calculer le délai d’application d’une correction après la fin de l’investigation. Où les obtenir Cette étape est généralement déduite lorsque le champ « Status » du formulaire « HPD:Help Desk » passe à « Resolved ». L’horodatage est enregistré dans le champ « Last Resolved Date » et dans l’Event Log. Collecte À partir de l’horodatage « Last Resolved Date » ou du changement de statut vers « Resolved ». Type d’événement inferred
	Transféré à un autre groupe	Cette activité se produit lorsqu’un incident est réaffecté d’un groupe de support à un autre. Elle est déduite de la détection d’une modification du champ « Assigned Group » après l’affectation initiale.
Pourquoi c’est important Des transferts fréquents indiquent une orientation initiale incorrecte ou des lacunes de connaissances. Le suivi de cette activité est essentiel pour le Dashboard « Incident Reassignment Cycle Analysis » et le KPI « Incident Reassignment Rate ». Où les obtenir Déduit de l’Event Log (« HPD:HelpDesk_AuditLogSystem »), en identifiant les modifications ultérieures du champ « Assigned Group » dans le formulaire « HPD:Help Desk » après son premier renseignement. Collecte Identifie les modifications du champ « Assigned Group » après l’affectation initiale. Type d’événement inferred
	Violation d’un SLA	Il s’agit d’un événement calculé qui se produit 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 obtenu en comparant l’horodatage de résolution à la date d’échéance du SLA.
Pourquoi c’est important Cette activité est fondamentale pour le Dashboard « Incident SLA Performance Overview » et le KPI « Incident SLA Compliance Rate ». Elle signale directement les incidents qui n’ont pas respecté les engagements de service. Où les obtenir Calculé en comparant « Last Resolved Date » à « Target Date » (« SLA Due Date ») dans le formulaire « HPD:Help Desk ». Si l’incident n’est pas encore résolu, le calcul peut être effectué par rapport à l’heure actuelle. Collecte Événement calculé : se produit si « Last Resolved Date » > « Target Date ». Type d’événement calculated

Recommandé Facultatif

Guides d’extraction

Comment récupérer vos données depuis BMC Helix ITSM

Étapes

Accéder à Smart Reporting : connectez-vous à votre environnement BMC Helix ITSM. Dans le menu principal de l’application, accédez à Rapports pour lancer Smart Reporting.
Créer un nouveau 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électionner la source de données : lorsque vous y êtes invité, choisissez votre source de données ITSM principale. Sélectionnez la vue Incident Management, qui constitue la couche sémantique construite au-dessus des formulaires d’incident principaux.
Utiliser Freehand SQL : dans le générateur de rapports, au lieu de faire glisser les champs, accédez aux options de la source de données et sélectionnez Freehand SQL. Un éditeur s’ouvre pour vous permettre d’écrire une requête SQL personnalisée.
Saisir 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. Vous devez remplacer les valeurs fictives [START_DATE], [END_DATE] et [YOUR_COMPANY_NAME] par les valeurs correspondant à vos besoins.
Valider et prévisualiser les données : utilisez la fonction de validation ou de prévisualisation de l’éditeur SQL pour vérifier les erreurs de syntaxe et afficher un échantillon du résultat. Vous vous assurez ainsi que la requête s’exécute correctement dans votre environnement avant de créer le rapport complet.
Mettre en forme le rapport : une fois la requête validée, passez à l’étape de conception du rapport. Les colonnes définies dans la requête SQL seront disponibles sous forme de champs. Vérifiez que toutes les colonnes, notamment IncidentId, ActivityName et EventTimestamp, figurent dans le tableau du rapport.
Appliquer des filtres au rapport, facultatif : même si le filtre de date principal figure dans la requête SQL, vous pouvez ajouter d’autres filtres interactifs au niveau du rapport, par exemple sur Priority ou AssignedGroup.
Exécuter et enregistrer le rapport : exécutez le rapport pour générer l’ensemble des données. Lorsque les résultats vous conviennent, enregistrez le rapport sous un nom explicite, comme « Incident Management Event Log ».
Exporter au format CSV : lorsque les résultats du rapport sont affichés, 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 local.
Planifier l’exportation, facultatif : pour assurer une analyse continue, vous pouvez planifier l’exécution automatique du rapport. Dans les paramètres de diffusion du rapport, configurez une planification, par exemple quotidienne ou hebdomadaire, et définissez comme destination un partage de fichiers ou une adresse e-mail, en veillant à sélectionner le format 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 Incident Management.
Type de rapport : Un Advanced Report utilisant la fonctionnalité Freehand SQL est nécessaire pour construire la structure de l’Event Log à l’aide d’instructions UNION ALL.
Vue de la source de données : Utilisez la vue standard Incident Management, fondé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 afin de maîtriser les performances. La requête fournie contient les valeurs fictives [START_DATE] et [END_DATE]. Nous recommandons d’extraire entre 3 et 6 mois de données pour obtenir une analyse pertinente sans surcharger le système.
Filtre par entreprise : La requête contient une valeur fictive [YOUR_COMPANY_NAME] permettant de limiter les données à une entreprise opérationnelle précise. Dans un environnement mutualisé, ce filtre est indispensable pour obtenir des rapports exacts.
Considérations relatives aux performances : La requête de l’Event Log est complexe et effectue des jointures sur plusieurs tables. Son exécution sur de grands volumes de données peut mobiliser une part importante des Ressources du système. Planifiez toujours les exportations volumineuses en dehors des heures de pointe.

a 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

Identifier 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 AR System sous-jacente de BMC Helix ITSM, par exemple SQL Server ou Oracle. Vous devez également identifier le schéma et les noms de tables correspondant au formulaire de Gestion des incidents, HPD:Help Desk, ainsi qu’à son journal d’audit. La table principale est souvent nommée T<form_id>, par exemple T1234, et le journal d’audit porte généralement le nom H<form_id> ou [form_name]_AuditLogSystem.
Se connecter à 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.
Examiner et personnaliser la requête SQL : Copiez la requête SQL fournie dans votre client. Examinez attentivement les valeurs fictives et remplacez-les par les valeurs correctes pour 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' : définissez les dates de début et de fin de la période d’extraction.
Gérer la conversion des horodatages : La requête fournie utilise DATEADD(s, [TimestampColumn], '1970-01-01'), une fonction propre à SQL Server pour convertir 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écuter la requête : Exécutez la requête modifiée sur la base de données. Selon la période sélectionnée et le volume de vos données d’incidents, l’opération peut prendre plusieurs minutes.
Contrôler les résultats : Une fois la requête terminée, examinez rapidement les résultats. Vérifiez que les colonnes IncidentId, ActivityName et EventTimestamp sont renseignées comme prévu. Assurez-vous que les activités sont variées afin de confirmer le bon fonctionnement des instructions UNION ALL.
Exporter les données au format CSV : Exportez l’ensemble des résultats depuis votre client SQL vers un fichier CSV. Vérifiez que le fichier utilise l’encodage UTF-8 et comporte une ligne d’en-tête contenant les noms de colonnes.
Préparer le chargement : Avant de charger le fichier dans un outil de Process Mining, vérifiez que la colonne EventTimestamp est formatée de manière cohérente, par exemple YYYY-MM-DD HH:MI:SS. Aucune autre transformation ne devrait être nécessaire si la requête SQL s’est exécutée correctement.

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 précis des tables correspondant au formulaire HPD:Help Desk et à son journal d’audit, car ils peuvent varier selon les installations.
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 vivement 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 mutualisée, ajoutez dans la clause WHERE de la CTE BaseIncidents un filtre correspondant à l’entreprise que vous souhaitez 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 effectuent des jointures sur de grandes tables de journaux d’audit et plusieurs opérations UNION ALL, peuvent mobiliser beaucoup de Ressources. Il est recommandé d’exécuter les extractions volumineuses en dehors des heures de pointe afin de ne pas dégrader les performances du système.
Conversion des horodatages : La requête suppose que les horodatages sont stockés au format Unix, c’est-à-dire en secondes depuis le 01/01/1970. Vérifiez que cette hypothèse est valable dans votre système et que la fonction de conversion utilisée est adaptée à votre technologie de base de données, par exemple SQL Server ou Oracle.

a 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 d’API, nom d’utilisateur et mot de passe, d’un compte BMC Helix disposant au minimum d’autorisations en lecture sur les formulaires « HPD:Help Desk » et « HPD:Help Desk Audit Log ».
Configurer 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 situées en haut, notamment HELIX_HOSTNAME, HELIX_USERNAME, HELIX_PASSWORD, START_DATE, END_DATE et COMPANY_NAME, afin de les adapter à votre environnement et au périmètre de données souhaité.
Comprendre l’authentification : Le script appelle d’abord le point de terminaison /api/jwt/login pour s’authentifier auprès de votre instance BMC Helix. Il obtient un jeton Web JSON (JWT), ensuite utilisé dans l’en-tête d’autorisation de toutes les demandes de données.
Exécuter le script : Exécutez le script depuis votre terminal à l’aide de la commande python extract_incidents.py. Le script commence son exécution et affiche sa progression dans la console.
Récupérer les données initiales des incidents : Le script interroge le point de terminaison de l’API REST « HPD:Help Desk » pour récupérer la liste de tous les incidents créés pendant la période indiquée. Il utilise la pagination, avec les paramètres limit et offset, afin de traiter efficacement un grand nombre d’incidents sans surcharger l’API.
Récupérer le journal d’audit : Pour chaque incident récupéré à l’étape précédente, le script effectue un appel API distinct vers le formulaire « HPD:Help Desk Audit Log ». Il récupère l’historique détaillé des modifications de chaque incident, indispensable pour identifier des activités telles que les changements de statut et les réaffectations.
Déduire les événements et appliquer 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 afin de déduire logiquement les activités indiquées. Par exemple, la première apparition du champ « Assigned Group » dans le journal crée un événement « Group Assigned ». Un changement de statut de « Resolved » à « In Progress » génère un événement « Incident Reopened ».
Gérer les événements calculés : Le script calcule les événements qui ne sont pas enregistrés directement. « Incident Reported » est créé à partir de « Submit Date ». « SLA Breach » est déduit en comparant « Last Resolved Date » à « Target Date ».
Structurer les données : Chaque fois qu’une activité est identifié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érer le fichier CSV : Une fois tous les incidents et leurs activités traités, le script utilise la bibliothèque csv intégrée à Python pour écrire l’Event Log final dans un fichier nommé bmc_helix_incident_log.csv. Ce fichier est créé dans le même répertoire que celui depuis lequel le script a été exécuté.
Effectuer la vérification finale et charger le fichier : Ouvrez le fichier CSV généré dans un tableur pour en vérifier le contenu. Assurez-vous que les colonnes et les données sont correctes. Le fichier est alors prêt à être chargé 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 d’API utilisé pour l’authentification.
HELIX_PASSWORD : mot de passe du compte d’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 générer un volume excessif.
COMPANY_NAME : nom de l’entreprise selon laquelle filtrer les incidents. Ce paramètre est essentiel dans les environnements mutualisés pour définir correctement le périmètre des données. Si ce filtre n’est pas nécessaire, vous pouvez lui attribuer la valeur 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 débit de l’API.
Prérequis : Le script nécessite un compte utilisateur BMC Helix disposant au minimum d’autorisations de lecture sur les formulaires HPD:Help Desk et HPD:Help Desk Audit Log. Sans accès aux deux formulaires, l’extraction sera incomplète.

a 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 vos initiatives de Process Mining et faire apparaître des analyses utiles dans vos 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

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

Réduisez le MTTR de 35 % et éliminez les violations de SLA pour améliorer la satisfaction des utilisateurs.

Démarrer l’essai gratuit

Aucune carte bancaire requise. Essai gratuit de 14 jours.

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

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

Attributs de la Gestion des incidents

Activités de la Gestion des incidents

Guides d’extraction

Exportation Smart Reporting de BMC Helix au format CSV

Étapes

Configuration

a Exemple de requête sql

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

Étapes

Configuration

a Exemple de requête sql

Extraction par script Python via l’API REST BMC Helix

Étapes

Configuration

a Exemple de requête python

Prêt à commencer ?

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

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

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

Attributs de la Gestion des incidents

Activités de la Gestion des incidents

Guides d’extraction

Exportation Smart Reporting de BMC Helix au format CSV

Étapes

Configuration

a Exemple de requête sql

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

Étapes

Configuration

a Exemple de requête sql

Extraction par script Python via l’API REST BMC Helix

Étapes

Configuration

a Exemple de requête python

Prêt à commencer ?

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

Nous attachons de l’importance à votre confidentialité