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

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

BMC Helix ITSM

Attributs de gestion des demandes de service(20) Activités de gestion des demandes de service(14) Guides d’extraction(3)

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

Ce modèle présente les attributs de données essentiels à recueillir et les principales activités à suivre dans votre processus de gestion des demandes de service. Il fournit également des conseils pratiques pour extraire efficacement ces données de BMC Helix ITSM. Appuyez-vous sur cette ressource pour préparer vos données et lancer vos initiatives de Process Mining en toute confiance.

Attributs recommandés à recueillir
Activités clés à suivre
Conseils d’extraction pour BMC Helix ITSM

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

Télécharger le modèle

Attributs de gestion des demandes de service

Ces champs de données sont essentiels pour constituer un journal d’événements complet et analyser en détail votre processus de gestion des demandes de service.

5 Obligatoire 6 Recommandé 9 Facultatif

	Nom	Description
	Activité ActivityName	Nom de l’événement ou de la tâche qui s’est produit à un moment donné du cycle de traitement de la demande de service.
Description Cet attribut décrit une étape précise ou un changement de statut dans le processus de traitement des demandes de service, par exemple « Request In Review », « Fulfillment In Progress » ou « Service Request Resolved ». Chaque activité correspond à un événement du parcours complet d’une demande de service. L’analyse de la séquence et de la fréquence des activités est au cœur du Process Mining. Elle permet de découvrir les cartes de processus, de repérer les goulots d’étranglement et d’analyser les variantes du processus. Il est essentiel de comprendre quelles activités ont lieu, dans quel ordre et à quelle fréquence pour optimiser le processus. Pourquoi est-ce important ? Les activités constituent les éléments de base de la carte du processus. Leur suivi permet de visualiser et d’analyser le déroulement du processus, et de voir comment le travail est réellement effectué. Où trouver ces données Cet attribut est généralement déduit des changements apportés aux champs « Status » et « Status Reason » du formulaire « SRM:Request » ou des journaux des applications de traitement associées, par exemple Incident ou Work Order. Exemples Demande en attente d’approbationTraitement en coursDemande de service résolueDemande de service clôturée
	Heure de début EventStartTime	Horodatage indiquant le début d’une activité ou d’un événement précis.
Description Cet attribut enregistre la date et l’heure exactes du début d’une activité. Chaque événement du journal, de l’envoi initial à la clôture définitive, doit comporter une heure de début afin d’établir l’ordre chronologique du processus. Cet horodatage est essentiel à toute analyse du Process Mining fondée sur le temps. Il sert à calculer les temps de cycle, la durée des activités et les temps d’attente entre les étapes, ainsi qu’à vérifier le respect des SLA. Il permet de repérer les goulots d’étranglement et d’analyser les performances du processus au fil du temps. Pourquoi est-ce important ? L’heure de début établit l’ordre chronologique des événements. Elle est indispensable pour calculer la durée du processus, repérer les retards et comprendre son déroulement dans le temps. Où trouver ces données Cet attribut correspond aux champs d’horodatage des journaux d’audit ou des tables d’historique des statuts associées au formulaire « SRM:Request », par exemple « Submit Date » pour l’événement initial. Exemples 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:00Z
	Identifiant de la demande de service ServiceRequestId	Identifiant unique de chaque demande de service, utilisé comme clé principale pour suivre l’ensemble de son cycle de traitement.
Description L’identifiant de la demande de service distingue chaque demande individuelle soumise par un utilisateur ou un système. Il constitue le fil conducteur qui relie tous les événements ultérieurs, de l’enregistrement initial à la clôture définitive, et permet d’analyser le parcours complet de chaque demande. En Process Mining, cet identifiant est indispensable pour reconstituer la séquence des activités de chaque cas. Il permet à l’outil de regrouper tous les événements associés, comme « Request Submitted », « Request Assigned » et « Service Request Closed », dans une seule instance de processus. C’est la base de toute analyse du processus. Pourquoi est-ce important ? Il s’agit de l’identifiant de cas fondamental. Sans lui, il est impossible de suivre le parcours complet d’une demande de service, et donc de découvrir et d’analyser le processus. Où trouver ces données Il s’agit généralement du champ « InstanceId » ou « Request Number » du formulaire « SRM:Request » dans BMC Helix ITSM. Exemples SR000010572931SR000010572932SR000010572933
	Dernière mise à jour des données LastDataUpdate	Horodatage de la dernière actualisation des données du processus depuis le système source.
Description Cet attribut indique la date et l’heure de la dernière extraction des données de BMC Helix ITSM. Il renseigne les utilisateurs sur l’actualité des données analysées et leur permet de connaître la période couverte par l’analyse. Ces métadonnées sont essentielles à tout Dashboard ou à toute analyse de Process Mining. Elles permettent de savoir si les analyses reposent sur des données presque en temps réel ou sur un instantané historique, ce qui influe sur la validité et la pertinence des conclusions. Pourquoi est-ce important ? Cet attribut renseigne les utilisateurs sur l’actualité des données, ce qui est essentiel pour prendre des décisions à partir des informations les plus récentes sur les performances du processus. Où trouver ces données Cet horodatage est généré et ajouté lors de l’extraction et du chargement des données. Exemples 2024-05-21T08:00:00Z
	Système source SourceSystem	Indique le système d’où proviennent les données extraites.
Description Cet attribut précise l’origine des données du processus. Dans cette vue, sa valeur serait définie de manière statique sur « BMC Helix ITSM » pour indiquer que tous les événements liés aux demandes de service proviennent de ce système. Dans les environnements où plusieurs systèmes sont intégrés, ce champ est essentiel pour comprendre la provenance des données et les répartir selon leur source. Il garantit la clarté et la traçabilité, notamment lorsque des données provenant de différentes plateformes sont regroupées. Pourquoi est-ce important ? Cet attribut précise l’origine des données, ce qui est important pour leur gouvernance, leur traçabilité et le diagnostic des problèmes dans les environnements comportant plusieurs systèmes. Où trouver ces données Il s’agit d’une valeur statique ajoutée lors de l’extraction et de la transformation des données, et non d’un champ de BMC Helix ITSM. Exemples BMC Helix ITSM
	Agent affecté AssignedAgent	Utilisateur actuellement chargé du traitement de la demande de service.
Description Cet attribut désigne l’agent informatique ou le membre de l’équipe d’assistance chargé de la demande à un moment donné. Si sa valeur change au cours du traitement d’une même demande, cela indique un transfert ou une réaffectation. Cet attribut est essentiel pour analyser la performance des agents et la répartition de leur charge de travail. Il permet de suivre le nombre de demandes traitées par chaque agent, leur temps moyen de résolution et la fréquence des réaffectations. Ces données contribuent à la gestion des ressources et à l’identification des besoins de formation. Pourquoi est-ce important ? Le suivi de l’agent affecté est essentiel pour analyser les transferts, mesurer les performances individuelles et comprendre la répartition de la charge de travail au sein de l’équipe d’assistance. Où trouver ces données Cela correspond au champ « Assignee » ou « Assigned To » de l’enregistrement de traitement (par exemple, Work Order ou Incident) associé à la demande de service. Exemples Bob SmithAlice JohnsonCharlie Brown
	Équipe affectée AssignedTeam	Le groupe ou l’équipe d’assistance actuellement chargé de la demande de service.
Description Cet attribut désigne le groupe fonctionnel chargé de traiter la demande, par exemple « Help Desk », « Network Team » ou « Database Administration ». Une modification de ce champ indique un transfert de responsabilité entre équipes. L’analyse par équipe affectée permet de repérer les goulots d’étranglement au sein d’une équipe, d’étudier les transferts entre équipes et d’évaluer l’efficacité des différents groupes d’assistance. Elle est essentielle aux Dashboards « Réaffectations et reprises des demandes » et « Efficacité du triage », qui mettent en évidence la manière dont le travail est acheminé dans l’organisation. Pourquoi est-ce important ? Cet attribut permet d’analyser le flux du processus entre les différents groupes fonctionnels, de repérer les inefficacités d’acheminement et de mesurer les performances de chaque équipe. Où trouver ces données Cela correspond au champ « Assigned Group » de l’enregistrement de traitement (par exemple, Work Order ou Incident) associé à la demande de service. Exemples Centre de servicesAssistance aux infrastructuresAssistance applicative de niveau 2
	Heure de fin EventEndTime	Horodatage indiquant la fin d’une activité ou d’un événement précis.
Description L’heure de fin marque l’achèvement d’une activité. Dans les systèmes ITSM, de nombreuses activités correspondent à des changements de statut instantanés, mais certaines ont une durée mesurable. L’heure de fin permet de calculer précisément la durée de ces activités. Lors de l’analyse, l’heure de fin est utilisée avec l’heure de début pour calculer la durée de traitement de chaque activité. Vous pouvez ainsi repérer les tâches qui prennent le plus de temps, et pas seulement les temps d’attente entre les étapes. Pourquoi est-ce important ? Cet attribut permet de calculer la durée de traitement des activités, ce qui est essentiel pour repérer les étapes inefficaces et comprendre où le temps des ressources est consacré. Où trouver ces données Cette valeur peut être déduite. L’heure de fin d’une activité correspond souvent à l’heure de début de l’activité suivante pour le même cas. Pour la dernière activité, elle correspond à l’horodatage de résolution ou de clôture. Exemples 2023-10-26T10:05:15Z2023-10-26T11:45:10Z2023-10-28T09:00:00Z
	Priorité Priority	Niveau de priorité attribué à la demande de service, qui indique son incidence sur l’activité et son degré d’urgence.
Description La priorité détermine l’ordre de traitement des demandes et la rapidité avec laquelle elles doivent être prises en charge. Les valeurs courantes sont « Critique », « Élevée », « Moyenne » et « Faible ». La priorité est souvent définie en fonction de l’incidence de la demande sur l’activité et de son urgence. L’analyse par priorité permet de vérifier si les demandes prioritaires sont traitées plus rapidement que les demandes moins prioritaires. Il s’agit d’une dimension essentielle des Dashboards sur les délais de résolution et le respect des SLA, qui aide à vérifier que les ressources sont affectées aux besoins les plus importants de l’organisation. Pourquoi est-ce important ? Cet attribut permet de vérifier si le processus établit correctement les priorités et respecte les niveaux de service attendus pour les demandes ayant des incidences différentes sur l’activité. Où trouver ces données Il s’agit du champ « Priority » du formulaire « SRM:Request ». Exemples CritiqueÉlevéeMoyenneFaible
	Statut de la demande RequestStatus	Statut de la demande de service au moment de l’événement, par exemple « In Progress », « Pending » ou « Closed ».
Description Cet attribut indique l’état de la demande de service à différents moments de son cycle de traitement. Le statut apporte du contexte à chaque activité et sert souvent de source pour déterminer l’attribut « Activité » lui-même. L’analyse par statut permet de comprendre combien de temps les demandes restent dans certains états, comme « Pending Customer » ou « Waiting for Approval ». Elle est essentielle pour repérer les goulots d’étranglement et les retards dus à des dépendances externes ou à des files d’attente internes. Elle alimente directement le Dashboard d’identification des goulots d’étranglement. Pourquoi est-ce important ? Cet attribut donne un aperçu de l’état de la demande. Il permet de comparer le temps passé en attente au temps passé en traitement actif, ce qui est essentiel pour repérer les goulots d’étranglement. Où trouver ces données Il s’agit du champ « Status » du formulaire « SRM:Request ». Les valeurs historiques sont disponibles dans le journal d’audit. Exemples PlanificationEn coursEn attenteRésolueClôturée
	Type de service ServiceType	Catégorie ou type de service demandé par l’utilisateur.
Description Le type de service classe la nature de la demande, par exemple « Demande de nouveau logiciel », « Réinitialisation du mot de passe » ou « Intégration d’un nouvel employé ». Il s’agit d’une dimension essentielle pour filtrer et segmenter les données du processus. Lors de l’analyse du processus, cet attribut sert à comparer les performances des différents types de demandes. Il aide à répondre à des questions telles que « Quels types de service prennent le plus de temps à résoudre ? » ou « Quels types de service donnent lieu au plus grand nombre de reprises ? ». Il est essentiel aux Dashboards sur les délais de résolution et le respect des SLA. Pourquoi est-ce important ? Cet attribut permet de segmenter les demandes de service afin de comparer les déroulements des processus, de repérer les problèmes propres à chaque type de demande et de cibler les efforts d’optimisation. Où trouver ces données Ces données figurent souvent dans le champ « Title » ou dans un champ de catégorisation du formulaire « SRM:Request ». Elles sont dérivées du service sélectionné dans le catalogue. Exemples Demande de nouveau matérielDemande d’accès à un logicielConfiguration d’un accès VPN
	Canal de soumission SubmissionChannel	Le moyen ou le canal utilisé pour soumettre la demande de service.
Description Cet attribut indique comment la demande de service a été soumise : par exemple, via un portail en libre-service, par e-mail, par téléphone au centre de services ou à la suite d’une alerte automatique du système. Selon le canal, les variantes du processus et les délais de résolution peuvent différer. L’analyse du processus par canal de soumission peut révéler des inefficacités ou des pratiques efficaces propres à certaines méthodes de réception. Les demandes soumises via le portail en libre-service peuvent, par exemple, être résolues plus rapidement grâce à des données initiales de meilleure qualité, tandis que celles reçues par e-mail peuvent nécessiter un triage manuel plus important. Pourquoi est-ce important ? Cet attribut aide à comprendre l’incidence du mode de réception sur l’efficacité du processus, la qualité des données et le temps de cycle global. Vous pouvez ainsi cibler les améliorations sur certains canaux. Où trouver ces données Cette information peut souvent être déduite de champs tels que « Client Type » ou « Reported Source » du formulaire « SRM:Request », ou des tickets de traitement associés. Exemples Portail en libre-serviceE-mailTéléphoneGénéré par le système
	Catégorie de résolution ResolutionCategory	La classification de la solution apportée pour résoudre la demande.
Description Cet attribut classe de manière structurée le mode de résolution d’une demande, par exemple « Correction logicielle », « Formation de l’utilisateur » ou « Correction des données ». Il précise la nature de la résolution, au-delà du simple code de clôture. Il est essentiel au Dashboard « Exactitude de la catégorie de résolution », qui permet de comparer la catégorie à celle du service initial et d’en vérifier la cohérence. L’analyse des catégories de résolution met en évidence les tendances liées aux problèmes et éclaire la gestion proactive des problèmes. Elle peut, par exemple, révéler que de nombreuses demandes sont résolues grâce à une formation des utilisateurs. Pourquoi est-ce important ? Cet attribut renseigne sur la nature des solutions et aide à repérer les tendances liées aux problèmes récurrents, ainsi que les possibilités de gestion proactive des problèmes ou de formation des utilisateurs. Où trouver ces données Cette information figure parmi les champs de catégorisation opérationnelle et produit du ticket de traitement, souvent sous le nom « Resolution Category ». Exemples Administration des comptesPanne matérielleMise à niveau logicielleInformations fournies
	Code de clôture CloseCode	Code indiquant le résultat final ou le motif de clôture de la demande de service.
Description Le code de clôture permet de classer de manière normalisée la résolution d’une demande de service. Il peut s’agir, par exemple, de « Résolue par le centre de services », « Annulée par l’utilisateur » ou « Demande en double ». L’analyse des codes de clôture aide à comprendre les résultats les plus fréquents des demandes. Elle peut mettre en évidence, par exemple, un nombre élevé d’annulations par les utilisateurs, signe possible d’un processus trop long, ou de nombreux doublons, qui peuvent révéler un problème de système ou de communication. Cet attribut contribue au Dashboard « Exactitude de la catégorie de résolution ». Pourquoi est-ce important ? Il fournit des données structurées sur les résultats des demandes et permet d’analyser l’efficacité des résolutions ainsi que les motifs d’inachèvement ou d’annulation. Où trouver ces données Cette information figure généralement dans le champ « Resolution » ou « Closure Code » du ticket de traitement associé à la demande de service. Exemples RéussieAnnulée par l’utilisateurN’est plus nécessaireRésolution automatisée
	Comporte des reprises IsRework	Indicateur booléen précisant si une demande de service a fait l’objet de reprises, par exemple si elle est revenue à une étape précédente.
Description Cet indicateur repère les demandes de service qui ont connu une boucle ou des reprises dans leur parcours. Par exemple, une demande qui passe de « Traitement en cours » à « Demande en cours d’examen » est considérée comme ayant fait l’objet de reprises. La définition exacte dépend de la logique du processus métier. Cet attribut contribue directement au Dashboard « Analyse des reprises et réaffectations des demandes » et à l’indicateur de taux de reprises des demandes. Il permet de mesurer la fréquence des reprises et d’en analyser les causes courantes, comme une évaluation initiale incorrecte ou des informations incomplètes, qui peuvent rendre le processus moins efficace. Pourquoi est-ce important ? Il mesure les inefficacités du processus en signalant les cas qui s’écartent du « parcours nominal », afin d’aider à repérer les causes profondes des boucles et des tâches répétées. Où trouver ces données Cet attribut calculé est dérivé de la séquence des activités dans le journal d’événements. Une logique spécifique est nécessaire pour détecter les retours en arrière dans le flux du processus. Exemples truefalse
	Date limite du SLA SlaTargetDate	La date et l’heure auxquelles la demande de service doit être résolue, conformément à son accord de niveau de service (SLA).
Description La date limite du SLA est un horodatage calculé qui correspond à l’échéance de traitement de la demande de service. Elle est déterminée par les règles de l’accord de service, qui tiennent souvent compte de facteurs tels que la priorité et le type de demande. Cet attribut est fondamental pour le Dashboard « Vue d’ensemble de la conformité aux SLA ». Il sert de référence pour mesurer le délai réel de résolution. En comparant l’« EventEndTime » de la dernière activité de résolution à cette date limite, vous pouvez déterminer si l’engagement de service a été respecté. Pourquoi est-ce important ? Il s’agit de la principale référence pour mesurer la performance du service au regard des engagements pris. Cet attribut est donc essentiel au suivi et au reporting de la conformité aux SLA. Où trouver ces données Cette date est calculée et enregistrée par le module Service Level Management (SLM). Vous la trouverez dans les formulaires SLM associés à la demande de service. Exemples 2023-10-28T17:00:00Z2023-11-01T09:00:00Z2023-10-27T12:00:00Z
	Dépasse le SLA IsSlaBreached	Indicateur booléen précisant si la demande de service a été résolue après la date limite de son SLA.
Description Cet indicateur calculé prend la valeur true si l’horodatage de résolution finale de la demande de service est postérieur à sa « date limite du SLA ». Il fournit un résultat binaire simple sur la performance du SLA pour chaque demande. Cet attribut est essentiel au Dashboard « Vue d’ensemble de la conformité aux SLA » et à l’indicateur de respect des SLA. Il permet de calculer facilement les taux de conformité globaux et de filtrer les demandes ayant dépassé le délai pour comparer leurs caractéristiques à celles des demandes conformes. Vous pouvez ainsi rechercher les causes profondes des dépassements. Pourquoi est-ce important ? Il simplifie l’analyse de la performance des SLA en transformant la comparaison de deux horodatages en un indicateur booléen facile à mesurer et à représenter, pour suivre les taux de conformité. Où trouver ces données Il s’agit d’un champ calculé. La logique est la suivante : IF 'Resolution Timestamp' > 'SlaTargetDate' THEN true ELSE false. Exemples truefalse
	Est escaladée IsEscalated	Indicateur booléen précisant si la demande de service a fait l’objet d’une escalade.
Description Cet indicateur prend la valeur true lorsqu’une demande de service a fait l’objet d’une escalade fonctionnelle ou hiérarchique. Une escalade intervient généralement lorsqu’une demande n’avance pas comme prévu, risque de dépasser le délai du SLA ou nécessite l’approbation ou l’intervention d’une autorité supérieure. Cet attribut est essentiel au Dashboard « Analyse de l’efficacité des escalades de demandes ». Il permet de filtrer et d’analyser les parcours des demandes escaladées afin de comprendre ce qui déclenche l’escalade, le temps nécessaire à la résolution après celle-ci et l’efficacité du processus d’escalade. Pourquoi est-ce important ? Il permet d’isoler et d’analyser les demandes qui ont nécessité une escalade, afin de repérer les faiblesses du processus standard ou les facteurs à l’origine des problèmes complexes. Où trouver ces données Il ne s’agit généralement pas d’un champ unique. Cet indicateur est calculé à partir des activités liées aux escalades dans le journal d’audit, ou des changements de priorité ou d’affectation effectués selon un protocole d’escalade. Exemples truefalse
	Nombre de transferts HandoffCount	Nombre total de réaffectations d’une demande de service entre différents agents ou équipes.
Description Cette métrique calculée compte le nombre de changements d’« AssignedAgent » ou d’« AssignedTeam » pour une même demande de service. Un nombre élevé de transferts peut indiquer une fragmentation du processus, une résolution insuffisante dès le premier contact ou un acheminement inefficace. Cet attribut sert de base à l’indicateur du nombre moyen de transferts entre agents par demande et est utilisé dans le Dashboard « Reprises et réaffectations des demandes ». L’analyse des cas comportant de nombreux transferts peut révéler des possibilités d’améliorer le triage, de mieux former les équipes ou de simplifier le processus de résolution, afin de réduire les délais et d’améliorer la satisfaction des clients. Pourquoi est-ce important ? Il mesure la fragmentation du processus et le temps consacré à la communication. Un nombre élevé de transferts est souvent associé à des délais de résolution plus longs et à une moindre efficacité du processus. Où trouver ces données Cette métrique calculée est obtenue en comptant le nombre de valeurs distinctes de l’attribut « AssignedAgent » ou « AssignedTeam » pour chaque identifiant unique de demande de service. Exemples 0135
	Service du demandeur RequestorDepartment	Le service ou l’unité opérationnelle de l’utilisateur qui a soumis la demande.
Description Cet attribut désigne le service de la personne qui demande le service, par exemple « Finance », « Ressources humaines » ou « Informatique ». Cette information provient généralement du profil de l’utilisateur dans le système. La segmentation de l’analyse du processus par service permet de repérer les besoins propres à chaque service, les tendances dans les demandes et les possibilités de formation ciblée ou d’amélioration du service. Elle peut notamment aider à répondre à des questions comme : « Le service financier doit-il attendre plus longtemps pour obtenir le traitement de ses demandes ? » Pourquoi est-ce important ? Cet attribut permet d’analyser la consommation des services et la performance des processus par unité opérationnelle, afin de mettre en évidence les problèmes ou les tendances propres à certains services. Où trouver ces données Cette information est généralement récupérée dans le profil de l’utilisateur associé au champ « Requested For » du formulaire « SRM:Request ». Exemples FinanceVentesRessources humainesInformatique

Obligatoire Recommandé Facultatif

Activités de gestion des demandes de service

Pour découvrir et représenter fidèlement le processus, consignez dans votre journal d’événements les principales étapes et les jalons suivants.

6 Recommandé 8 Facultatif

	Activité	Description
	Demande attribuée	La demande de service a été attribuée à un agent ou à une équipe chargé de la traiter. Cette étape marque la fin du tri.
Pourquoi est-ce important ? Cette étape permet de mesurer la durée du tri et d’analyser la charge de travail des agents. Des réaffectations fréquentes peuvent révéler des problèmes d’acheminement ou un manque de compétences adaptées. Où trouver ces données Cet événement peut être extrait explicitement du journal d’audit des champs « Assigned Group » ou « Assignee » du formulaire SRM:Request ou des formulaires des applications de traitement associées, par exemple WOI:WorkOrder. Données à recueillir Horodatage du journal d’audit indiquant la première attribution d’une valeur non nulle au champ « Assignee ». Type d’événement explicit
	Demande de service annulée	Le demandeur ou le centre de services a retiré la demande de service avant la fin de son traitement. Il s’agit d’un état final pour cette demande.
Pourquoi est-ce important ? Le suivi des annulations permet de repérer certaines tendances, par exemple les demandes incorrectes ou les services qui ne sont plus nécessaires. Ces informations peuvent guider l’amélioration du catalogue de services. Où trouver ces données Cette activité est déduite d’un changement de statut dans le formulaire SRM:Request vers « Canceled ». Données à recueillir Horodatage de l’événement de mise à jour au cours duquel le champ « Status » de SRM:Request prend la valeur « Canceled ». Type d’événement inferred
	Demande de service clôturée	La demande de service est officiellement clôturée et passe en lecture seule, dans un état archivé. Cela se produit après sa résolution et à l’issue de toute période de confirmation.
Pourquoi est-ce important ? Cette activité marque la fin définitive du processus. Le délai entre « Resolved » et « Closed » peut révéler des inefficacités dans la procédure de clôture. Où trouver ces données Cette activité est déduite du changement de statut final dans le formulaire SRM:Request vers « Closed ». Données à recueillir Horodatage de l’événement de mise à jour au cours duquel le champ « Status » de SRM:Request prend la valeur « Closed ». Type d’événement inferred
	Demande de service résolue	Le traitement de la demande de service est terminé et la résolution a été communiquée au demandeur. La demande attend sa confirmation finale ou sera clôturée automatiquement après un délai défini.
Pourquoi est-ce important ? Cette étape marque la fin du cycle de prestation de service. Elle constitue le principal point de référence pour mesurer le délai de résolution et le respect des SLA. Où trouver ces données Cette activité est déduite d’un changement de statut dans le formulaire SRM:Request vers « Resolved » ou « Completed ». Données à recueillir Horodatage de l’événement de mise à jour au cours duquel le champ « Status » de SRM:Request prend la valeur « Resolved » ou « Completed ». Type d’événement inferred
	Demande de service soumise	Cette activité correspond à la création et à l’envoi d’une nouvelle demande de service par un utilisateur. Elle est enregistrée lorsqu’une nouvelle entrée, dont le statut initial est généralement « Submitted », est créée dans le formulaire SRM:Request.
Pourquoi est-ce important ? Il s’agit du point de départ de chaque cas de demande de service. Cette étape est indispensable pour mesurer la durée totale du cycle et analyser le volume de demandes reçues. Où trouver ces données Cet événement est déduit de l’horodatage de création et du statut initial, par exemple « Submitted », d’un enregistrement dans le formulaire SRM:Request. Données à recueillir Repérez l’horodatage de création d’un nouvel identifiant de demande de service dans le formulaire SRM:Request lorsque le statut est « Submitted ». Type d’événement inferred
	Traitement en cours	L’agent ou l’équipe à qui la demande a été attribuée a commencé à la traiter. La demande est ainsi passée de la file d’attente à un état de traitement actif.
Pourquoi est-ce important ? Cette étape marque le début du travail de traitement qui apporte de la valeur. L’analyse du temps passé à cette étape aide à comprendre la productivité des ressources et la complexité du traitement. Où trouver ces données Cette activité est déduite d’un changement de statut dans le formulaire SRM:Request vers « In Progress ». Données à recueillir Horodatage de l’événement de mise à jour au cours duquel le champ « Status » de SRM:Request prend la valeur « In Progress ». Type d’événement inferred
	Demande approuvée	La demande de service a été officiellement approuvée par la personne ou l’instance requise. Son traitement peut donc se poursuivre. Cet événement suit généralement le statut « Waiting for Approval ».
Pourquoi est-ce important ? Cet événement marque la fin du sous-processus d’approbation. Il permet de suivre la durée des approbations et leur effet sur le délai global de résolution. Où trouver ces données Cette activité est déduite d’un changement de statut dans le formulaire SRM:Request, de « Waiting Approval » à un statut ultérieur comme « Planning » ou « In Progress ». La décision d’approbation elle-même est consignée dans les formulaires d’approbation associés. Données à recueillir Horodatage du changement de statut après « Waiting Approval », à la suite d’une décision d’approbation favorable. Type d’événement inferred
	Demande en attente d’approbation	La demande de service a été transmise à un approbateur désigné ou à un groupe d’approbation. Elle attend une décision avant que son traitement puisse commencer. Cette étape est fréquente pour les demandes liées aux coûts ou aux droits d’accès.
Pourquoi est-ce important ? Cette activité permet d’isoler les retards liés aux approbations, de mesurer les délais d’approbation et de repérer les goulots d’étranglement dans le circuit d’approbation. Où trouver ces données Cette activité est déduite d’un changement de statut dans le formulaire SRM:Request, par exemple vers « Waiting Approval ». Données à recueillir Horodatage de l’événement de mise à jour au cours duquel le champ « Status » de SRM:Request prend la valeur « Waiting Approval ». Type d’événement inferred
	Demande en cours d’examen	Le centre de services procède à l’examen initial et au tri de la demande afin d’en déterminer la nature et la priorité, puis de choisir l’équipe chargée de la traiter. Cette étape se traduit généralement par un changement de statut dans l’enregistrement de la demande.
Pourquoi est-ce important ? Le suivi de cette activité permet de mesurer l’efficacité du tri et de repérer les retards entre l’envoi de la demande et son attribution. Il est essentiel au calcul de l’indicateur « Durée moyenne du tri ». Où trouver ces données Cette activité est déduite d’un changement de statut dans le formulaire SRM:Request, par exemple vers « In Review » ou « Planning ». Données à recueillir Horodatage de l’événement de mise à jour au cours duquel le champ « Status » de SRM:Request prend la valeur « In Review ». Type d’événement inferred
	Demande rejetée	La demande de service a été refusée lors de la phase d’approbation. Cet état final interrompt le processus avant le début du traitement.
Pourquoi est-ce important ? L’analyse des demandes rejetées peut révéler des problèmes liés aux justifications fournies, aux critères d’admissibilité ou aux règles d’approbation. Où trouver ces données Cette activité est déduite d’un changement de statut dans le formulaire SRM:Request vers « Rejected ». Données à recueillir Horodatage de l’événement de mise à jour au cours duquel le champ « Status » de SRM:Request prend la valeur « Rejected ». Type d’événement inferred
	Demande reprise	La demande de service n’est plus en attente, généralement parce que l’utilisateur a fourni les informations requises. L’agent reprend son traitement.
Pourquoi est-ce important ? Cet événement marque la fin d’une période d’attente. Il permet de mesurer précisément les délais d’attente liés à des facteurs externes et leur effet sur le respect des SLA. Où trouver ces données Cette activité est déduite du changement de statut de SRM:Request, de « Pending » à « In Progress ». Données à recueillir Horodatage de l’événement de mise à jour au cours duquel le champ « Status » de SRM:Request passe de « Pending » à « In Progress ». Type d’événement inferred
	Informations demandées à l’utilisateur	L’agent chargé du traitement a besoin d’informations complémentaires de la part du demandeur pour poursuivre. La demande passe généralement à l’état « Pending ».
Pourquoi est-ce important ? Cette activité est essentielle au calcul du « temps d’attente des informations externes » et permet de déterminer à quelle fréquence les demandes sont bloquées faute d’informations complètes. Où trouver ces données Cette activité est déduite d’un changement de statut dans le formulaire SRM:Request vers « Pending », avec un motif tel que « Customer Hold » ou « Awaiting Information ». Données à recueillir Horodatage du changement de statut vers « Pending », associé à un motif de statut précis. Type d’événement inferred
	Résolution confirmée par l’utilisateur	Le demandeur a confirmé que le service a été fourni de manière satisfaisante et que la demande est résolue. Cette confirmation déclenche souvent la clôture définitive de la demande.
Pourquoi est-ce important ? Cet événement indique clairement la satisfaction du client et met officiellement fin à l’échange lié au service. Il distingue la résolution du processus de l’acceptation par le client. Où trouver ces données Cet événement peut être consigné dans les journaux de travail ou les notes d’activité de SRM:Request lorsque l’utilisateur confirme la résolution par le portail ou par e-mail. Il ne correspond pas toujours à un statut distinct. Données à recueillir Recherchez dans les journaux de travail (SRM:WorkInfo) les entrées indiquant une confirmation de l’utilisateur ou la réalisation d’une enquête. Type d’événement explicit
	Solution mise en œuvre	L’agent a terminé le travail technique nécessaire au traitement de la demande de service. La solution peut maintenant être confirmée par l’utilisateur avant la résolution officielle de la demande.
Pourquoi est-ce important ? Cette activité distingue la fin du travail technique de la résolution officielle. Elle permet de repérer les retards entre la fin du travail et la confirmation de l’utilisateur. Où trouver ces données Cette activité peut être déduite d’un changement de statut d’un ticket de traitement en arrière-plan, par exemple le passage du statut d’un ordre de travail à « Completed », avant que la demande SRM:Request parente soit marquée « Resolved ». Données à recueillir Horodatage auquel un ticket de traitement en arrière-plan, comme un ordre de travail ou un incident, lié à SRM:Request est marqué comme terminé. Type d’événement inferred

Recommandé Facultatif

Guides d’extraction

Comment extraire vos données de BMC Helix ITSM

Étapes

Accéder à Smart Reporting : Connectez-vous à votre environnement BMC Helix ITSM. Accédez à la section des rapports et lancez Smart Reporting. Selon votre version, cette fonctionnalité peut s’appeler « Rapports » ou « Smart Reporting ».
Créer un rapport : Dans Smart Reporting, choisissez l’option permettant de créer un rapport, puis sélectionnez « Rapport » comme type.
Sélectionner la source de données et la vue : Vous serez invité à sélectionner une source de données. Choisissez votre source de données AR System principale. Pour la vue, recherchez et sélectionnez la vue des demandes de service, généralement basée sur le formulaire SRM:Request.
Ajouter des formulaires (jointures) : Pour couvrir l’ensemble du cycle de vie, vous devez joindre le formulaire principal SRM:Request aux formulaires associés. Dans l’onglet « Données », ajoutez les jointures suivantes :
- SRM:WorkInfo (sur SR ID+ = Request Number) pour obtenir les détails des activités de traitement et des journaux de travail.
- AP:Signature (sur Request = SRInstanceID) pour récupérer les événements liés aux approbations, notamment les approbations et les refus. Une jointure personnalisée peut être nécessaire.
Définir les colonnes du rapport : Faites glisser les champs requis depuis les formulaires joints vers la zone « Colonnes ». Ajoutez notamment les champs Request Number, Submit Date, Status, Description, Priority, Assigned To et Assigned Group de SRM:Request, ainsi que les champs associés des formulaires joints.
Créer des champs calculés pour les activités : Cette méthode repose sur la création de plusieurs champs calculés représentant l’horodatage de chaque activité. Dans l’onglet « Données », créez un champ calculé pour chaque activité. Par exemple :
- Horodatage de soumission : utilisez directement le champ Submit Date.
- Horodatage de l’approbation : utilisez le champ Signature Date du formulaire AP:Signature.
- Horodatage du début du traitement : utilisez MIN(Submit Date) dans SRM:WorkInfo, avec un regroupement par numéro de demande.
Préparer le rapport pour l’union des données : Smart Reporting ne propose pas de bouton « UNION ALL » comme SQL. Pour obtenir ce résultat, créez un rapport unique et utilisez des fonctions avancées ou des sous-requêtes pour pivoter les données. Une méthode courante consiste à créer plusieurs colonnes calculées, une pour l’horodatage de chaque activité. Vous devrez ensuite mettre en forme l’export final afin de convertir ces colonnes en lignes distinctes pour chaque activité.
Appliquer des filtres : Pour limiter le périmètre des données et améliorer les performances, ajoutez des filtres au rapport. Au minimum, filtrez le champ Submit Date du formulaire SRM:Request afin de sélectionner une période donnée. Si votre environnement est multi-tenant, ajoutez également un filtre sur « Company ».
Exécuter le rapport et vérifier les données : Lancez le rapport pour vous assurer que les données sont correctement extraites. Vérifiez les jointures, le contenu des colonnes et les horodatages renvoyés par les champs calculés.
Exporter le rapport : Une fois le rapport validé, exportez les données au format CSV ou Microsoft Excel, deux formats faciles à préparer pour l’importation dans des outils de Process Mining.
Transformer les données : Après l’export, convertissez les données d’un format large (une ligne par demande de service, avec plusieurs colonnes d’horodatage) en format long (une ligne par activité). Utilisez un script, par exemple en Python ou PowerShell, ou un outil comme Power Query dans Excel pour dépivoter les colonnes d’horodatage et obtenir deux colonnes : ActivityName et EventStartTime. Cette étape est indispensable pour créer la structure requise du journal d’événements.

Configuration

Prérequis : Vous devez disposer d’un compte utilisateur doté de droits de création et d’exécution de rapports dans Smart Reporting de BMC Helix ITSM. Vous devez également pouvoir lire les données des formulaires SRM:Request, SRM:WorkInfo et AP:Signature.
Formulaires principaux : Le rapport est constitué en joignant les formulaires suivants :
- SRM:Request : formulaire principal contenant les détails de la demande de service.
- SRM:WorkInfo : formulaire contenant les entrées du journal de travail, utilisées pour déduire les activités de traitement.
- AP:Signature : formulaire contenant les enregistrements d’approbation, nécessaires au suivi des activités associées.
Filtrage par période : Appliquez toujours un filtre de période au champ SRM:Request.Submit Date. Une période de 3 à 6 mois est recommandée pour obtenir un échantillon représentatif sans ralentir le rapport.
Filtres importants : En plus de la période, filtrez le champ « Company » pour isoler les données d’une entité donnée. Vous pouvez aussi exclure certains types de demandes ou certains états, comme « Brouillon », s’ils ne sont pas pertinents pour l’analyse du processus.
Performances : Les rapports qui joignent plusieurs formulaires sur une longue période peuvent être lents à générer. Pour les volumes importants, il est vivement conseillé de programmer leur exécution en dehors des heures de pointe. Si des délais d’expiration surviennent, répartissez l’extraction en périodes mensuelles plus courtes.

Exemple de requête sql

/*
This is a conceptual SQL query representing the logic you would build in the BMC Helix ITSM Smart Reporting UI.
Smart Reporting uses a graphical interface, so you will create this structure by joining forms and creating calculated fields that correspond to each SELECT block below.
The final step of unpivoting data from columns to rows must be done after exporting the report.
*/

-- 1. Service Request Submitted
SELECT
  'Service Request Submitted' AS "ActivityName",
  req."Request Number" AS "ServiceRequestId",
  req."Submit Date" AS "EventStartTime",
  NULL AS "EventEndTime",
  req."Status" AS "RequestStatus",
  req."Title" AS "ServiceType", -- Or another field representing the service
  req."Priority" AS "Priority",
  req."ASG_Assignee" AS "AssignedAgent",
  req."Assigned Group" AS "AssignedTeam",
  'BMC Helix ITSM' AS "SourceSystem",
  GETDATE() AS "LastDataUpdate"
FROM "SRM:Request" AS req
WHERE req."Submit Date" BETWEEN '[START_DATE]' AND '[END_DATE]'

UNION ALL

-- 2, 3, 4, 14: Approval Steps (Waiting, Approved, Rejected)
SELECT
  CASE sig."Outcome" WHEN 'Approved' THEN 'Request Approved' WHEN 'Rejected' THEN 'Request Rejected' ELSE 'Request Waiting for Approval' END AS "ActivityName",
  req."Request Number" AS "ServiceRequestId",
  sig."Signature Date" AS "EventStartTime",
  NULL AS "EventEndTime",
  req."Status" AS "RequestStatus",
  req."Title" AS "ServiceType",
  req."Priority" AS "Priority",
  req."ASG_Assignee" AS "AssignedAgent",
  req."Assigned Group" AS "AssignedTeam",
  'BMC Helix ITSM' AS "SourceSystem",
  GETDATE() AS "LastDataUpdate"
FROM "SRM:Request" AS req
JOIN "AP:Signature" AS sig ON req."InstanceId" = sig."Request"
WHERE req."Submit Date" BETWEEN '[START_DATE]' AND '[END_DATE]'

UNION ALL

-- 5. Request Assigned (based on first Work Info entry)
SELECT
  'Request Assigned' AS "ActivityName",
  wi."Request Number" AS "ServiceRequestId",
  MIN(wi."Submit Date") AS "EventStartTime",
  NULL AS "EventEndTime",
  req."Status" AS "RequestStatus",
  req."Title" AS "ServiceType",
  req."Priority" AS "Priority",
  req."ASG_Assignee" AS "AssignedAgent",
  req."Assigned Group" AS "AssignedTeam",
  'BMC Helix ITSM' AS "SourceSystem",
  GETDATE() AS "LastDataUpdate"
FROM "SRM:WorkInfo" AS wi
JOIN "SRM:Request" AS req ON wi."Request Number" = req."Request Number"
WHERE req."Submit Date" BETWEEN '[START_DATE]' AND '[END_DATE]'
GROUP BY wi."Request Number", req."Status", req."Title", req."Priority", req."ASG_Assignee", req."Assigned Group"

UNION ALL

-- 6, 7, 8, 9: Fulfillment Steps from Work Logs
SELECT
  CASE 
    WHEN wi."Work Log Type" = 'General Information' AND wi.Description LIKE '%Fulfillment In Progress%' THEN 'Fulfillment In Progress'
    WHEN wi."Work Log Type" = 'Customer Communication' AND wi.Description LIKE '%Information Requested%' THEN 'Information Requested from User'
    WHEN wi."Work Log Type" = 'General Information' AND wi.Description LIKE '%Request Resumed%' THEN 'Request Resumed'
    WHEN wi."Work Log Type" = 'Resolution Communications' THEN 'Solution Implemented'
    ELSE NULL 
  END AS "ActivityName",
  wi."Request Number" AS "ServiceRequestId",
  wi."Submit Date" AS "EventStartTime",
  NULL AS "EventEndTime",
  req."Status" AS "RequestStatus",
  req."Title" AS "ServiceType",
  req."Priority" AS "Priority",
  req."ASG_Assignee" AS "AssignedAgent",
  req."Assigned Group" AS "AssignedTeam",
  'BMC Helix ITSM' AS "SourceSystem",
  GETDATE() AS "LastDataUpdate"
FROM "SRM:WorkInfo" AS wi
JOIN "SRM:Request" AS req ON wi."Request Number" = req."Request Number"
WHERE req."Submit Date" BETWEEN '[START_DATE]' AND '[END_DATE]'
  AND wi."Work Log Type" IN ('General Information', 'Customer Communication', 'Resolution Communications')

UNION ALL

-- 10, 11, 12, 13: Terminal Statuses (Resolved, Confirmed, Closed, Canceled)
SELECT
  CASE req."Status"
    WHEN 'Resolved' THEN 'Service Request Resolved'
    WHEN 'Closed' AND req."Status_Reason" = 'Confirmed' THEN 'Resolution Confirmed by User'
    WHEN 'Closed' THEN 'Service Request Closed'
    WHEN 'Cancelled' THEN 'Service Request Canceled'
    ELSE NULL
  END AS "ActivityName",
  req."Request Number" AS "ServiceRequestId",
  req."Last Modified Date" AS "EventStartTime", -- This is an approximation of when the status change occurred
  NULL AS "EventEndTime",
  req."Status" AS "RequestStatus",
  req."Title" AS "ServiceType",
  req."Priority" AS "Priority",
  req."ASG_Assignee" AS "AssignedAgent",
  req."Assigned Group" AS "AssignedTeam",
  'BMC Helix ITSM' AS "SourceSystem",
  GETDATE() AS "LastDataUpdate"
FROM "SRM:Request" AS req
WHERE req."Submit Date" BETWEEN '[START_DATE]' AND '[END_DATE]'
  AND req."Status" IN ('Resolved', 'Closed', 'Cancelled')

Étapes

Prérequis : Munissez-vous d’un client de base de données, tel que DBeaver, SQL Server Management Studio ou Oracle SQL Developer, ainsi que d’identifiants en lecture seule pour la base de données BMC Helix AR System.
Se connecter à la base de données : Utilisez votre client de base de données pour établir une connexion au serveur AR System.
Préparer la requête : Copiez la requête SQL complète fournie dans la section « Requête » de ce document et collez-la dans l’éditeur de requêtes de votre client.
Définir les paramètres : Repérez les valeurs de remplacement dans la requête. Remplacez :start_date et :end_date par la période souhaitée, par exemple « 2023-01-01 » et « 2023-12-31 ». Le cas échéant, remplacez :company_name par le nom de l’entreprise à utiliser comme filtre.
Exécuter la requête : Lancez la requête SQL modifiée. Selon la période et la taille du système, l’opération peut prendre plusieurs minutes.
Vérifier les résultats : Une fois la requête terminée, le jeu de résultats contenant le journal d’événements s’affiche. Vérifiez rapidement que les données ont été correctement récupérées et que les colonnes et activités attendues sont présentes.
Vérifier les horodatages : Assurez-vous que les colonnes d’horodatage, notamment EventStartTime, EventEndTime et LastDataUpdate, utilisent un format cohérent, par exemple « YYYY-MM-DD HH:MI:SS ». Si votre base de données renvoie un autre format, adaptez les fonctions TO_CHAR ou CONVERT de la requête.
Exporter les données : Utilisez la fonction d’export de votre client de base de données pour enregistrer l’ensemble des résultats dans un fichier CSV. Choisissez l’encodage UTF-8 pour garantir la compatibilité.
Préparer l’importation : Donnez au fichier un nom explicite, par exemple servicerequest_eventlog.csv. Il est alors prêt à être importé dans ProcessMind.

Configuration

Identifiants de base de données : Un compte utilisateur en lecture seule pour la base de données AR System est nécessaire. Il évite toute modification accidentelle des données et respecte les bonnes pratiques de sécurité.
Filtrage par période : La requête contient les paramètres :start_date et :end_date. Définissez une période précise et adaptée, généralement de 3 à 12 mois, afin de maîtriser les performances de la requête et le volume de données. Le filtre s’applique au champ Submit_Date de la demande de service.
Filtre sur l’entreprise : Le paramètre :company_name permet de filtrer les demandes d’une entreprise donnée. Pour extraire les données de toutes les entreprises, vous pouvez supprimer la ligne AND req.Company = :company_name ou utiliser un caractère générique si cette option est prise en charge.
Valeurs d’état : La requête utilise les valeurs entières standard des états de BMC Helix ITSM (par exemple, Submitted = 0, In Review = 1, etc.). Votre système peut comporter des états personnalisés ou utiliser une autre correspondance avec les valeurs entières. Vérifiez ces valeurs dans le formulaire SYS:Status ou dans Developer Studio, puis adaptez les clauses WHERE de la requête si nécessaire.
Performances : Les requêtes directes sur de grandes tables comme SRM_Request et leurs journaux d’audit peuvent mobiliser beaucoup de ressources. Planifiez l’extraction en dehors des heures de pointe afin de limiter son impact sur les performances du système.

Exemple de requête sql

WITH ServiceRequests AS (
  SELECT
    req.Request_Number AS ServiceRequestId,
    req.Submit_Date AS SubmitDate,
    req.Status AS CurrentStatus,
    req.Description AS ServiceType,
    req.Priority AS Priority,
    req.Assignee AS AssignedAgent,
    req.Assigned_Group AS AssignedTeam,
    req.Company,
    req.InstanceId
  FROM
    SRM_Request req
  WHERE
    req.Submit_Date BETWEEN TO_TIMESTAMP(:start_date, 'YYYY-MM-DD') AND TO_TIMESTAMP(:end_date, 'YYYY-MM-DD')
    AND req.Company = :company_name
)
-- 1. Service Request Submitted
SELECT
  sr.ServiceRequestId AS "ServiceRequestId",
  'Service Request Submitted' AS "ActivityName",
  sr.SubmitDate AS "EventStartTime",
  sr.SubmitDate AS "EventEndTime",
  'Submitted' AS "RequestStatus",
  sr.ServiceType AS "ServiceType",
  sr.Priority AS "Priority",
  sr.AssignedAgent AS "AssignedAgent",
  sr.AssignedTeam AS "AssignedTeam",
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
UNION ALL
-- 2. Request In Review
SELECT
  sr.ServiceRequestId,
  'Request In Review' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'In Review' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%In Review%'
UNION ALL
-- 3. Request Waiting for Approval
SELECT
  sr.ServiceRequestId,
  'Request Waiting for Approval' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Waiting Approval' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Waiting Approval%'
UNION ALL
-- 4. Request Approved
SELECT
  sr.ServiceRequestId,
  'Request Approved' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Approved' AS "RequestStatus", -- This status might vary, often transitions to Planning or Assigned
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Planning%' AND audit.Old_Values LIKE '%Waiting Approval%'
UNION ALL
-- 5. Request Assigned
SELECT
  sr.ServiceRequestId,
  'Request Assigned' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Assigned' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Assigned_Group%' AND audit.New_Values IS NOT NULL
UNION ALL
-- 6. Fulfillment In Progress
SELECT
  sr.ServiceRequestId,
  'Fulfillment In Progress' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'In Progress' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%In Progress%'
UNION ALL
-- 7. Information Requested from User
SELECT
  sr.ServiceRequestId,
  'Information Requested from User' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Pending' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Pending%'
UNION ALL
-- 8. Request Resumed
SELECT
  sr.ServiceRequestId,
  'Request Resumed' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'In Progress' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%In Progress%' AND audit.Old_Values LIKE '%Pending%'
UNION ALL
-- 9. Solution Implemented
SELECT
  sr.ServiceRequestId,
  'Solution Implemented' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Completed' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Completed%'
UNION ALL
-- 10. Service Request Resolved
SELECT
  sr.ServiceRequestId,
  'Service Request Resolved' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Resolved' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Resolved%'
UNION ALL
-- 11. Resolution Confirmed by User
SELECT
  sr.ServiceRequestId,
  'Resolution Confirmed by User' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Closed' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Closed%' AND audit.Old_Values LIKE '%Resolved%'
UNION ALL
-- 12. Service Request Closed
SELECT
  sr.ServiceRequestId,
  'Service Request Closed' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Closed' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Closed%'
UNION ALL
-- 13. Service Request Canceled
SELECT
  sr.ServiceRequestId,
  'Service Request Canceled' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Cancelled' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Cancelled%'
UNION ALL
-- 14. Request Rejected
SELECT
  sr.ServiceRequestId,
  'Request Rejected' AS "ActivityName",
  audit.Audit_Date AS "EventStartTime",
  audit.Audit_Date AS "EventEndTime",
  'Rejected' AS "RequestStatus",
  sr.ServiceType,
  sr.Priority,
  sr.AssignedAgent,
  sr.AssignedTeam,
  'BMC Helix ITSM' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate"
FROM
  ServiceRequests sr
  JOIN SRM_Request_AuditLog audit ON sr.InstanceId = audit.Original_Request_ID
WHERE
  audit.Fields_Changed LIKE '%Status%' AND audit.New_Values LIKE '%Rejected%';

Étapes

Prérequis : Vérifiez que Python 3.6 ou une version ultérieure est installé sur votre système. Installez la bibliothèque requests, nécessaire aux appels d’API HTTP, en exécutant pip install requests dans votre terminal ou invite de commandes.
Obtenir les identifiants de l’API : Créez ou obtenez les identifiants d’un compte de service dédié dans BMC Helix ITSM. Ce compte doit disposer au minimum d’un accès en lecture au formulaire SRM:Request et au formulaire de journal d’audit correspondant, souvent nommé SRM:Request_AuditLog ou de façon similaire. Notez le nom d’utilisateur, le mot de passe et l’URL de base de votre instance BMC Helix, par exemple https://[your-company].bmc.com.
Configurer le script Python : Copiez le script Python fourni dans un fichier, par exemple extract_servicerequests.py. Modifiez le script et renseignez les variables de remplacement en haut du fichier : BASE_URL, USERNAME, PASSWORD et AUDIT_FORM_NAME. Adaptez le dictionnaire STATUS_ACTIVITY_MAP aux valeurs d’état utilisées dans le flux de travail de gestion des demandes de service de votre organisation.
Définir la période d’extraction : Modifiez les variables START_DATE et END_DATE du script. Elles définissent la période d’extraction à partir de la date de soumission des demandes de service. Pour un premier test, choisissez une période courte, par exemple une seule journée.
Exécuter le script : Lancez le script depuis votre terminal avec la commande python extract_servicerequests.py. Le script commence par s’authentifier auprès de l’API afin d’obtenir un jeton.
Récupérer les données initiales : Le script interroge le formulaire SRM:Request pour obtenir la liste des demandes de service créées pendant la période définie. Cette étape récupère l’identifiant du cas et les attributs statiques associés, comme la priorité et le type de service.
Récupérer l’historique des événements : Le script parcourt les identifiants de demande de service obtenus à l’étape précédente. Pour chaque identifiant, il effectue un second appel à l’API sur le formulaire de journal d’audit configuré afin de récupérer l’historique détaillé des changements d’état de la demande.
Transformer les données en journal d’événements : Pour chaque enregistrement du journal d’audit, le script associe le changement d’état à un nom d’activité standard à l’aide de STATUS_ACTIVITY_MAP. Il crée une ligne pour chaque activité associée, avec l’identifiant de la demande de service, le nom de l’activité et l’horodatage du changement.
Créer l’événement de soumission : Le script crée également l’activité initiale « Demande de service soumise » pour chaque demande, à partir du champ Submit Date du formulaire principal SRM:Request.
Exporter au format CSV : Après avoir traité toutes les demandes de service et leur historique, le script rassemble les lignes générées dans une liste unique et les enregistre dans un fichier CSV nommé servicerequest_event_log.csv. Ce fichier est mis en forme et prêt à être importé dans un outil de Process Mining.

Configuration

Points de terminaison de l’API : Le script utilise principalement deux points de terminaison. L’authentification passe par api/jwt/login. Les données sont interrogées à partir de arsys/v1/entry/SRM:Request pour obtenir la liste des cas et de arsys/v1/entry/[AUDIT_FORM_NAME] pour récupérer l’historique des événements.
Droits du compte de service : Un compte de service dédié, doté d’un accès en lecture au formulaire SRM:Request et au formulaire de journal d’audit du système, est nécessaire. Son utilisation est importante pour la sécurité et la traçabilité.
Filtrage par période : Le script filtre les demandes de service selon leur champ Submit Date. Pour garantir des performances fiables, il est recommandé d’extraire les données par lots de taille raisonnable, par exemple sur des périodes de 3 à 6 mois.
Association des états aux activités : Le dictionnaire STATUS_ACTIVITY_MAP du script constitue le cœur de la logique de transformation. Configurez-le avec soin pour tenir compte des états personnalisés de votre organisation et les associer aux noms d’activité souhaités. Tout état du flux de travail qui ne figure pas dans le dictionnaire sera ignoré.
Formulaire de journal d’audit : La capacité du script à récupérer les activités détaillées dépend entièrement de la disponibilité d’un journal d’audit interrogeable. Identifiez le nom du formulaire qui contient l’historique des changements d’état des demandes de service dans votre environnement, puis renseignez la variable AUDIT_FORM_NAME en conséquence.
Pagination : Le script gère automatiquement la pagination de l’API pour récupérer tous les enregistrements. Le paramètre limit est défini sur 1 000 enregistrements par requête afin d’équilibrer les performances et l’utilisation de la mémoire.

Exemple de requête python

import requests
import json
import csv
import datetime

class=class="hl-string">"hl-comment"># --- Configuration Settings --- #
class=class="hl-string">"hl-comment"># Replace with your BMC Helix environment details
BASE_URL = class="hl-string">"https://[your-company].bmc.com"
USERNAME = class="hl-string">"[your-service-account-username]"
PASSWORD = class="hl-string">"[your-service-account-password]"
class=class="hl-string">"hl-comment"># This is a placeholder; you must identify the correct audit form for SRM:Request in your system
AUDIT_FORM_NAME = class="hl-string">"SRM:Request_AuditLog"

class=class="hl-string">"hl-comment"># Date range for the extraction (YYYY-MM-DD format)
START_DATE = class="hl-string">"2023-01-01"
END_DATE = class="hl-string">"2023-03-31"

class=class="hl-string">"hl-comment"># --- Status to Activity Mapping --- #
class=class="hl-string">"hl-comment"># CRITICAL: Customize this map to match your system's status values
STATUS_ACTIVITY_MAP = {
    class="hl-string">"In Review": class="hl-string">"Request In Review",
    class="hl-string">"Waiting for Approval": class="hl-string">"Request Waiting for Approval",
    class="hl-string">"Approved": class="hl-string">"Request Approved",
    class="hl-string">"Assigned": class="hl-string">"Request Assigned",
    class="hl-string">"In Progress": class="hl-string">"Fulfillment In Progress",
    class="hl-string">"Pending": class="hl-string">"Information Requested from User", class=class="hl-string">"hl-comment"># This is a simplification; may need refinement
    class="hl-string">"Completed": class="hl-string">"Service Request Resolved",
    class="hl-string">"Closed": class="hl-string">"Service Request Closed",
    class="hl-string">"Cancelled": class="hl-string">"Service Request Canceled",
    class="hl-string">"Rejected": class="hl-string">"Request Rejected"
    class=class="hl-string">"hl-comment"># Add other custom statuses as needed
}

class=class="hl-string">"hl-comment"># Map specific status transitions for more granular activities
TRANSITION_ACTIVITY_MAP = {
    (class="hl-string">'Pending', class="hl-string">'In Progress'): class="hl-string">'Request Resumed'
    class=class="hl-string">"hl-comment"># You can add other specific transitions here
}

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

def get_paginated_results(base_url, token, form_name, query, fields):
    class="hl-string">"""Retrieves all entries from a form, handling pagination."""
    all_entries = []
    url = fclass="hl-string">"{base_url}/api/arsys/v1/entry/{form_name}"
    headers = {
        class="hl-string">'Authorization': fclass="hl-string">'AR-JWT {token}',
        class="hl-string">'Content-Type': class="hl-string">'application/json'
    }
    params = {
        class="hl-string">'q': query,
        class="hl-string">'fields': fclass="hl-string">'values({fields})',
        class="hl-string">'limit': 1000
    }
    while True:
        try:
            response = requests.get(url, headers=headers, params=params)
            response.raise_for_status()
            data = response.json()
            all_entries.extend(data[class="hl-string">'entries'])
            class=class="hl-string">"hl-comment"># Check for next page link
            if class="hl-string">'next' in data[class="hl-string">'_links']:
                url = data[class="hl-string">'_links'][class="hl-string">'next'][class="hl-string">'href']
                params = {}
            else:
                break
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching data from {form_name}: {e}")
            break
    return all_entries

def main():
    class="hl-string">"""Main function to orchestrate the data extraction."""
    print(class="hl-string">"Starting extraction...")
    token = get_jwt_token(BASE_URL, USERNAME, PASSWORD)
    if not token:
        return

    class=class="hl-string">"hl-comment"># 1. Get all Service Requests within the date range
    print(fclass="hl-string">"Fetching service requests from {START_DATE} to {END_DATE}...")
    srm_query = fclass="hl-string">"'Submit Date' >= \"{START_DATE}T00:00:00Z\class="hl-string">" AND 'Submit Date' <= \"{END_DATE}T23:59:59Z\class="hl-string">""
    srm_fields = class="hl-string">"Request Number,Submit Date,Priority,Assignee,Assigned Group,Title"
    srm_requests = get_paginated_results(BASE_URL, token, class="hl-string">"SRM:Request", srm_query, srm_fields)
    print(fclass="hl-string">"Found {len(srm_requests)} service requests.")

    event_log = []
    current_time = datetime.datetime.utcnow().isoformat() + class="hl-string">"Z"

    class=class="hl-string">"hl-comment"># 2. For each request, get its audit history
    for i, req in enumerate(srm_requests):
        req_values = req[class="hl-string">'values']
        request_id = req_values.get(class="hl-string">'Request Number')
        if not request_id:
            continue

        print(fclass="hl-string">"Processing request {i+1}/{len(srm_requests)}: {request_id}")

        class=class="hl-string">"hl-comment"># Add class="hl-string">'Service Request Submitted' event
        event_log.append({
            class="hl-string">'ServiceRequestId': request_id,
            class="hl-string">'ActivityName': class="hl-string">'Service Request Submitted',
            class="hl-string">'EventStartTime': req_values.get(class="hl-string">'Submit Date'),
            class="hl-string">'EventEndTime': req_values.get(class="hl-string">'Submit Date'),
            class="hl-string">'RequestStatus': class="hl-string">'Submitted',
            class="hl-string">'ServiceType': req_values.get(class="hl-string">'Title'),
            class="hl-string">'Priority': req_values.get(class="hl-string">'Priority'),
            class="hl-string">'AssignedAgent': req_values.get(class="hl-string">'Assignee'),
            class="hl-string">'AssignedTeam': req_values.get(class="hl-string">'Assigned Group'),
            class="hl-string">'SourceSystem': class="hl-string">'BMC Helix ITSM',
            class="hl-string">'LastDataUpdate': current_time
        })

        class=class="hl-string">"hl-comment"># 3. Fetch audit log for status changes
        audit_query = fclass="hl-string">"'Original Request ID' = \"{request_id}\class="hl-string">" AND 'Fields Changed' LIKE \"%Status%\class="hl-string">""
        audit_fields = class="hl-string">"New Value,Old Value,Log Key 1,Create Date"
        audit_entries = get_paginated_results(BASE_URL, token, AUDIT_FORM_NAME, audit_query, audit_fields)
        
        class=class="hl-string">"hl-comment"># Sort audit entries by date to ensure correct order
        audit_entries.sort(key=lambda x: x[class="hl-string">'values'][class="hl-string">'Create Date'])

        for audit_entry in audit_entries:
            audit_values = audit_entry[class="hl-string">'values']
            class=class="hl-string">"hl-comment"># Ensure we are only processing status changes
            if class="hl-string">'Status' not in audit_values.get(class="hl-string">'Log Key 1', class="hl-string">''):
                continue

            new_status = audit_values.get(class="hl-string">'New Value')
            old_status = audit_values.get(class="hl-string">'Old Value')
            timestamp = audit_values.get(class="hl-string">'Create Date')
            activity_name = None

            class=class="hl-string">"hl-comment"># Check for specific transitions first
            if (old_status, new_status) in TRANSITION_ACTIVITY_MAP:
                activity_name = TRANSITION_ACTIVITY_MAP.get((old_status, new_status))
            class=class="hl-string">"hl-comment"># Then check for general status mappings
            elif new_status in STATUS_ACTIVITY_MAP:
                activity_name = STATUS_ACTIVITY_MAP.get(new_status)

            if activity_name:
                event_log.append({
                    class="hl-string">'ServiceRequestId': request_id,
                    class="hl-string">'ActivityName': activity_name,
                    class="hl-string">'EventStartTime': timestamp,
                    class="hl-string">'EventEndTime': timestamp,
                    class="hl-string">'RequestStatus': new_status,
                    class="hl-string">'ServiceType': req_values.get(class="hl-string">'Title'),
                    class="hl-string">'Priority': req_values.get(class="hl-string">'Priority'),
                    class="hl-string">'AssignedAgent': req_values.get(class="hl-string">'Assignee'), class=class="hl-string">"hl-comment"># Note: Assignee is static from the main request
                    class="hl-string">'AssignedTeam': req_values.get(class="hl-string">'Assigned Group'), class=class="hl-string">"hl-comment"># Note: Team is static from the main request
                    class="hl-string">'SourceSystem': class="hl-string">'BMC Helix ITSM',
                    class="hl-string">'LastDataUpdate': current_time
                })
    
    class=class="hl-string">"hl-comment"># 4. Write to CSV
    output_file = class="hl-string">'servicerequest_event_log.csv'
    print(fclass="hl-string">"Writing event log to {output_file}...")
    if event_log:
        with open(output_file, class="hl-string">'w', newline=class="hl-string">'', encoding=class="hl-string">'utf-8') as f:
            writer = csv.DictWriter(f, fieldnames=event_log[0].keys())
            writer.writeheader()
            writer.writerows(event_log)
        print(class="hl-string">"Extraction complete.")
    else:
        print(class="hl-string">"No events to write.")

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

Prêt à commencer ?

Utilisez ce modèle pour simplifier la collecte de données et lancer votre démarche de Process Mining en toute confiance. Commencez dès aujourd’hui à optimiser la gestion de vos demandes de service !

Retour au guide d’amélioration

Télécharger le modèle

Gagnez en efficacité : optimisez dès aujourd’hui la gestion des demandes de service

Atteignez 70 % d’automatisation, réduisez les délais de traitement et améliorez l’expérience des utilisateurs.

Démarrez votre essai gratuit

Aucune carte bancaire requise. Commencez en quelques minutes.

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

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

Attributs de gestion des demandes de service

Activités de gestion des demandes de service

Guides d’extraction

Smart Reporting de BMC Helix ITSM pour les demandes de service

Étapes

Configuration

Exemple de requête sql

Requête SQL directe sur les tables de la base de données AR System

Étapes

Configuration

Exemple de requête sql

Extraction avec un script Python via l’API REST de BMC Helix

Étapes

Configuration

Exemple de requête python

Prêt à commencer ?

Gagnez en efficacité : optimisez dès aujourd’hui la gestion des demandes de service

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

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

Attributs de gestion des demandes de service

Activités de gestion des demandes de service

Guides d’extraction

Smart Reporting de BMC Helix ITSM pour les demandes de service

Étapes

Configuration

Exemple de requête sql

Requête SQL directe sur les tables de la base de données AR System

Étapes

Configuration

Exemple de requête sql

Extraction avec un script Python via l’API REST de BMC Helix

Étapes

Configuration

Exemple de requête python

Prêt à commencer ?

Gagnez en efficacité : optimisez dès aujourd’hui la gestion des demandes de service

Prêt à commencer ?

Gagnez en efficacité : optimisez dès aujourd’hui la gestion des demandes de service