> 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 la 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 clairement les attributs de données essentiels à collecter et les activités clés à suivre pour votre processus de gestion des demandes de service. Il fournit également des conseils pratiques pour extraire efficacement ces données de BMC Helix ITSM. Utilisez cette ressource pour préparer vos données plus simplement et lancer vos initiatives de Process Mining dans de bonnes conditions.

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

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 demandes de service

Ces champs de données sont essentiels pour créer un journal d’événements complet et analyser en profondeur 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 précise survenu à un moment donné du cycle de vie de la demande de service.
Description Cet attribut décrit une étape précise ou un changement d’état dans le processus de demande de service, par exemple « Demande en cours d’examen », « Exécution en cours » ou « Demande de service résolue ». Chaque activité représente un événement unique dans le parcours de bout en bout d’une demande de service. L’analyse de la séquence et de la fréquence des activités constitue le cœur du Process Mining. Elle permet de découvrir les cartes de processus, d’identifier les goulots d’étranglement et d’analyser les variantes du processus. Comprendre quelles activités se produisent, dans quel ordre et à quelle fréquence est essentiel pour optimiser le processus. Pourquoi c’est important Les activités constituent les éléments de base de la carte de processus. Leur suivi permet de visualiser et d’analyser le déroulement du processus, et de comprendre comment le travail est réellement effectué. Où les obtenir Cet attribut est généralement dérivé des modifications apportées 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 précises auxquelles une activité a commencé. Chaque événement du journal, de la soumission initiale à la clôture finale, doit comporter une heure de début afin d’établir l’ordre chronologique du processus. Cet horodatage est essentiel pour toutes les analyses de Process Mining fondées sur le temps. Il sert à calculer les temps de cycle, la durée des activités, les temps d’attente entre les étapes et le respect des SLA. Il permet de découvrir les goulots d’étranglement et d’analyser la performance du processus au fil du temps. Pourquoi c’est important L’heure de début établit l’ordre chronologique des événements. Elle est essentielle pour calculer la durée des processus, identifier les délais et comprendre la chronologie du processus. Où les obtenir Cet attribut correspond aux champs d’horodatage des journaux d’audit ou des tables d’historique des statuts associés au formulaire « SRM:Request », comme « Submit Date » pour l’événement initial. Exemples 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:00Z
	Identifiant de demande de service ServiceRequestId	Identifiant unique de chaque demande de service, utilisé comme clé primaire pour suivre l’ensemble de son cycle de vie.
Description L’identifiant de demande de service identifie de manière unique chaque demande soumise par un utilisateur ou un système. Il constitue le fil conducteur reliant tous les événements ultérieurs, de l’enregistrement initial à la clôture finale, et permet une analyse complète du parcours de chaque demande de service. Dans le Process Mining, cet identifiant est essentiel pour reconstituer la séquence des activités de chaque cas. Il permet à l’outil de regrouper tous les événements associés, tels que « Request Submitted », « Request Assigned » et « Service Request Closed », au sein d’une même instance de processus, qui sert de base à toutes les analyses de processus. Pourquoi c’est important Il s’agit de l’identifiant fondamental du cas. Sans lui, il est impossible de suivre le parcours de bout en bout d’une demande de service, ce qui rend la découverte et l’analyse des processus impossibles. Où les obtenir 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 de ce processus depuis le système source.
Description Cet attribut indique la date et l’heure de l’extraction de données la plus récente depuis BMC Helix ITSM. Il donne aux utilisateurs des informations sur l’actualité des données analysées et leur permet de connaître la période couverte par l’analyse. Il s’agit d’un attribut de métadonnées essentiel pour tout Dashboard ou toute analyse de Process Mining. Il permet de déterminer si les analyses reposent sur des données quasi en temps réel ou sur un instantané historique, ce qui influe sur la validité et la pertinence des conclusions. Pourquoi c’est important Il informe les utilisateurs de l’actualité des données, un élément essentiel pour prendre des décisions fondées sur les informations les plus récentes disponibles concernant la performance du processus. Où les obtenir 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	Identifie le système depuis lequel les données ont été extraites.
Description Cet attribut précise l’origine des données du processus. Dans cette vue, sa valeur serait définie statiquement sur « BMC Helix ITSM » afin d’indiquer que tous les événements liés aux demandes de service proviennent de ce système. Dans les environnements intégrant plusieurs systèmes, ce champ est essentiel pour comprendre la traçabilité des données et les partitionner selon leur source. Il garantit la clarté et la traçabilité, notamment lors de la fusion de données provenant de différentes plateformes. Pourquoi c’est important Il fournit le contexte relatif à l’origine des données, ce qui est important pour la gouvernance des données, la traçabilité et le dépannage dans les environnements multisystèmes. Où les obtenir 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 présent dans BMC Helix ITSM. Exemples BMC Helix ITSM
	Agent affecté AssignedAgent	Utilisateur actuellement chargé de traiter la demande de service.
Description Cet attribut identifie l’agent informatique ou le membre de l’équipe de support responsable de la demande à un moment donné. Les modifications de ce champ au cours du cycle de vie d’une même demande indiquent un transfert ou une réaffectation. Cet attribut est essentiel pour analyser la performance et la charge de travail des agents. Il permet de suivre le nombre de demandes traitées par chaque agent, leur délai 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 c’est important Le suivi de l’agent affecté est essentiel pour analyser les transferts, mesurer la performance individuelle et comprendre la répartition de la charge de travail au sein de l’équipe de support. Où les obtenir Cet attribut 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	Groupe ou équipe de support actuellement chargé de la demande de service.
Description Cet attribut identifie le groupe fonctionnel chargé de traiter la demande, par exemple « Centre d’assistance », « Équipe réseau » ou « Administration des bases de données ». Une modification de ce champ indique un transfert de responsabilité entre équipes. L’analyse fondée sur l’équipe attribuée permet d’identifier les goulots d’étranglement au niveau des équipes, d’analyser les transferts entre équipes et d’évaluer l’efficacité des différents groupes d’assistance. Elle est essentielle pour les Dashboards Reprises et réattributions des demandes et Efficacité du triage, qui révèlent comment le travail est orienté au sein de l’organisation. Pourquoi c’est important Il permet d’analyser le déroulement du processus entre différents groupes fonctionnels, d’identifier les inefficacités de routage et de mesurer la performance au niveau des équipes. Où les obtenir Cet attribut correspond au champ « Assigned Group » de l’enregistrement de traitement, par exemple Work Order ou Incident, associé à la demande de service. Exemples Centre de servicesSupport de l'infrastructureSupport applicatif, 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é. Si de nombreuses activités des systèmes ITSM correspondent à des modifications instantanées de statut, certaines ont une durée mesurable. L’heure de fin permet de calculer précisément la durée de ces activités. Dans l’analyse, l’heure de fin est utilisée avec l’heure de début pour calculer le temps de traitement des activités individuelles. Elle permet d’identifier les tâches précises, et pas seulement les temps d’attente entre elles, qui consomment le plus de temps dans le processus. Pourquoi c’est important Elle permet de calculer les temps de traitement des activités, ce qui est essentiel pour identifier les étapes inefficaces et comprendre où les Ressources consacrent leur temps. Où les obtenir Cette valeur peut être dérivée. L’heure de fin d’une activité correspond souvent à l’heure de début de l’activité séquentielle suivante pour le même cas. Pour l’activité finale, 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, indiquant son impact sur l’activité et son degré d’urgence.
Description La priorité détermine l’ordre et la rapidité de traitement des demandes. Les valeurs courantes sont « Critical », « High », « Medium » et « Low ». Cette attribution repose souvent sur une combinaison de l’impact de la demande sur l’activité et de son urgence. L’analyse par priorité est essentielle pour vérifier que les demandes hautement prioritaires sont traitées plus rapidement que les demandes faiblement prioritaires. Il s’agit d’une dimension clé des Dashboards consacrés au délai de résolution et à la conformité aux SLA, car elle contribue à garantir une allocation appropriée des Ressources aux besoins les plus importants de l’organisation. Pourquoi c’est important Il permet d’évaluer si le processus hiérarchise correctement le travail et respecte les niveaux de service attendus pour les demandes présentant différents niveaux d’impact sur l’activité. Où les obtenir 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 vie. L’état fournit le contexte de chaque activité et constitue souvent la source à partir de laquelle l’attribut « Activité » lui-même est dérivé. L’analyse par état permet de comprendre combien de temps les demandes restent dans certains états, comme « En attente du client » ou « En attente d’approbation ». Elle est essentielle pour identifier 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 c’est important Il fournit un instantané de l’état de la demande et permet d’analyser le temps passé dans les états d’attente par rapport aux états actifs, ce qui est essentiel pour identifier les goulots d’étranglement. Où les obtenir Il s’agit du champ « Status » du formulaire « SRM:Request ». Les valeurs historiques peuvent être consultées dans le journal d’audit. Exemples PlanificationEn coursEn attenteRésoluClôturé
	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 « Request New Software », « Password Reset » ou « Onboard New Employee ». Il constitue une dimension fondamentale pour filtrer et segmenter les données du processus. Dans l’analyse des processus, cet attribut sert à comparer la performance de différents types de demandes. Il permet de répondre à des questions telles que « Quels types de services prennent le plus de temps à résoudre ? » ou « Quels types de services nécessitent le plus de reprises ? ». Il est essentiel pour les Dashboards de délai de résolution et de conformité aux SLA. Pourquoi c’est important Il permet de segmenter les demandes de service afin de comparer les déroulements des processus, d’identifier les problèmes propres à chaque type et d’adapter efficacement les efforts d’optimisation. Où les obtenir Ces données se trouvent souvent dans le champ « Title » ou dans un champ de catégorisation du formulaire « SRM:Request », dérivé du service sélectionné dans le catalogue. Exemples Demande de nouveau matérielDemande d'accès à un logicielConfiguration de l'accès VPN
	Canal de soumission SubmissionChannel	Méthode ou canal par lequel la demande de service a été soumise.
Description Cet attribut enregistre la manière dont la demande de service a été initiée, par exemple via un portail en libre-service, un e-mail, un appel téléphonique au service desk ou une alerte système automatisée. Les différents canaux peuvent entraîner des variantes de processus et des délais de résolution différents. L’analyse du processus par canal de soumission peut révéler les inefficacités ou les bonnes pratiques associées à certaines méthodes de réception. Par exemple, les demandes soumises via le portail en libre-service peuvent être résolues plus rapidement grâce à une meilleure qualité des informations initiales, tandis que les demandes reçues par e-mail peuvent nécessiter un triage plus manuel. Pourquoi c’est important Il permet de comprendre l’influence de la méthode de réception sur l’efficacité du processus, la qualité des données et la durée globale du cycle, afin de cibler les améliorations sur certains canaux. Où les obtenir Cet attribut peut souvent être déduit de champs tels que « Client Type » ou « Reported Source » du formulaire « SRM:Request » ou des tickets de traitement associés. Exemples Portail libre-serviceE-mailTéléphoneGénéré par le système
	Catégorie de résolution ResolutionCategory	Classification de la solution fournie pour résoudre la demande.
Description Cet attribut fournit une catégorisation structurée de la manière dont une demande a été résolue, par exemple « Software Fix », « User Training » ou « Data Correction ». Il va au-delà d’un simple code de clôture en décrivant la nature de la résolution. Il est essentiel pour le Dashboard de précision des catégories de résolution, où il peut être comparé au type de service initial afin d’en vérifier la cohérence. L’analyse des catégories de résolution permet d’identifier les tendances liées aux problèmes et d’éclairer la Gestion proactive des problèmes, par exemple lorsque de nombreuses demandes sont résolues par une formation des utilisateurs. Pourquoi c’est important Cette information permet de mieux comprendre la nature des solutions apportées, d’identifier les tendances liées aux problèmes récurrents et de repérer les possibilités d’amélioration proactive de la Gestion des problèmes ou de formation des utilisateurs. Où les obtenir Cette information figure dans les champs de catégorisation opérationnelle et produit du ticket de traitement, souvent intitulés « Resolution Category ». Exemples Administration des comptesDéfaillance 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 fournit une méthode standardisée pour classer la résolution d’une demande de service. Les valeurs possibles incluent « Resolved by Service Desk », « Canceled by User » ou « Duplicate Request ». L’analyse des codes de clôture permet de comprendre les résultats courants des demandes. Elle peut mettre en évidence un nombre élevé de demandes annulées par les utilisateurs, ce qui peut indiquer un processus trop long, ou de nombreuses demandes en double, ce qui peut révéler un problème système ou de communication. Cet attribut alimente le Dashboard de précision des catégories de résolution. Pourquoi c’est 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 de non-achèvement ou d’annulation. Où les obtenir Ces informations se trouvent généralement dans un champ « Resolution » ou « Closure Code » du ticket de traitement associé à la demande de service. Exemples RéussiAnnulé par l'utilisateurN'est plus nécessaireRésolution automatisée
	Date cible du SLA SlaTargetDate	Date et heure auxquelles la demande de service doit être résolue conformément à son accord de niveau de service (SLA).
Description La date cible du SLA est un horodatage calculé qui représente 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 prennent souvent en compte des facteurs tels que la priorité et le type de demande. Cet attribut est fondamental pour le Dashboard de suivi 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 l’activité finale de résolution à cette date cible, il est possible de déterminer si l’engagement de service a été respecté. Pourquoi c’est important Il constitue la référence principale pour mesurer la performance du service par rapport aux engagements. Il est donc essentiel au suivi et au reporting de la conformité aux SLA. Où les obtenir Cette date est calculée et enregistrée par le module Service Level Management (SLM). Elle peut être consultée dans les formulaires SLM associés à la demande de service. Exemples 2023-10-28T17:00:00Z2023-11-01T09:00:00Z2023-10-27T12:00:00Z
	Est escaladé 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 un SLA ou nécessite l’intervention d’une autorité supérieure pour être approuvée ou traitée. Cet attribut est essentiel au Dashboard Request Escalation Efficiency Analysis. 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 à leur résolution après celle-ci et l’efficacité du processus d’escalade. Pourquoi c’est important Il permet d’isoler et d’analyser les demandes ayant nécessité une escalade, afin d’identifier les faiblesses du processus standard ou les facteurs déclencheurs des problèmes complexes. Où les obtenir Il ne s’agit généralement pas d’un champ unique. Cet indicateur est calculé à partir de la présence d’activités spécifiques liées à l’escalade dans le journal d’audit, ou de changements de priorité ou d’affectation intervenus conformément à un protocole d’escalade. Exemples truefalse
	Est une reprise IsRework	Indicateur booléen précisant si une demande de service a fait l’objet d’une reprise, par exemple lorsqu’elle revient à une étape précédente.
Description Cet indicateur identifie les demandes de service ayant suivi une boucle ou fait l’objet d’une reprise dans leur parcours. Par exemple, une demande passant de « Fulfillment in Progress » à « Request in Review » est considérée comme une reprise. La définition exacte dépend de la logique du processus métier. Cet attribut contribue directement au Dashboard Request Rework and Reassignment Analysis et au KPI Request Rework Rate. Il permet de quantifier la fréquence des reprises et d’analyser leurs causes courantes, comme une évaluation initiale incorrecte ou des informations incomplètes, qui entraînent une perte d’efficacité du processus. Pourquoi c’est important Il mesure l’inefficacité du processus en signalant les cas qui s’écartent du « happy path », afin d’identifier les causes profondes des boucles et du travail répété. Où les obtenir Il s’agit d’un attribut calculé à partir de la séquence des activités du journal d’événements. Une logique spécifique est nécessaire pour détecter les retours en arrière dans le parcours du processus. Exemples truefalse
	Nombre de transferts HandoffCount	Nombre total de fois où une demande de service a été réaffectée entre différents agents ou équipes.
Description Cette métrique calculée compte le nombre de changements de « AssignedAgent » ou de « AssignedTeam » pour une même demande de service. Un nombre élevé de transferts peut révéler une fragmentation du processus, un faible taux de résolution au premier contact ou un routage inefficace. Cet attribut sert de base au KPI Average Agent Handoffs per Request et est utilisé dans le Dashboard Request Rework and Reassignment. L’analyse des cas présentant un nombre élevé de transferts peut faire ressortir des possibilités d’amélioration du triage, de renforcement de la formation ou d’optimisation du processus de résolution, afin de réduire les délais et d’améliorer la satisfaction client. Pourquoi c’est important Il mesure la fragmentation du processus et le temps consacré aux échanges. Un nombre élevé de transferts est souvent associé à des délais de résolution plus longs et à une moindre efficacité du processus. Où les obtenir Il s’agit d’une métrique calculée en comptant, pour chaque identifiant unique de demande de service, le nombre de valeurs distinctes de l’attribut « AssignedAgent » ou « AssignedTeam ». Exemples 0135
	Service du demandeur RequestorDepartment	Service ou unité opérationnelle de l’utilisateur ayant soumis la demande.
Description Cet attribut identifie le service organisationnel de la personne qui demande le service, comme « Finance », « Human Resources » ou « IT ». Ces informations proviennent généralement du profil de l’utilisateur dans le système. La segmentation de l’analyse des processus par service permet d’identifier les besoins propres à chaque service, les tendances de demande et les éventuels besoins de formation ou d’amélioration ciblés. Elle peut aider à répondre à des questions telles que « Le service Finance connaît-il des temps d’attente plus longs pour ses demandes ? » Pourquoi c’est important Il permet d’analyser la consommation de services et la performance des processus par unité opérationnelle, ce qui peut mettre en évidence des problèmes ou des tendances propres à certains services. Où les obtenir Ces informations sont généralement récupérées dans le profil de l’utilisateur associé à l’utilisateur « Requested For » du formulaire « SRM:Request ». Exemples FinanceVentesRessources humainesTechnologies de l'information
	SLA non respecté IsSlaBreached	Indicateur booléen précisant si la demande de service a été résolue après la date cible de son SLA.
Description Cet indicateur calculé prend la valeur true lorsque l’horodatage de résolution finale de la demande de service est postérieur à sa « SLA Target Date ». Il fournit un résultat binaire simple pour évaluer la performance du SLA de chaque demande. Cet attribut est essentiel au Dashboard SLA Compliance Overview et au KPI SLA Adherence Rate. Il permet d’agréger facilement les résultats pour calculer le taux global de conformité, puis de filtrer les demandes afin de comparer les caractéristiques des processus ayant dépassé le SLA à celles des demandes conformes et d’identifier les causes profondes des écarts. Pourquoi c’est important Il simplifie l’analyse de la performance des SLA en convertissant la comparaison de deux horodatages en un indicateur booléen facile à mesurer et à visualiser. Où les obtenir Il s’agit d’un champ calculé. La logique est la suivante : IF 'Resolution Timestamp' > 'SlaTargetDate' THEN true ELSE false. Exemples truefalse

Obligatoire Recommandé Facultatif

Activités de gestion des demandes de service

Ces principales étapes et ces jalons du processus doivent être enregistrés dans votre journal d’événements pour une découverte et une visualisation précises du processus.

6 Recommandé 8 Facultatif

	Activité	Description
	Demande affectée	La demande de service a été affectée à un agent ou à une équipe chargé de réaliser le travail. Cette étape marque la fin de la phase de triage.
Pourquoi c’est important Ce jalon est essentiel pour mesurer le temps de triage et analyser la charge de travail des agents. Des réaffectations fréquentes peuvent révéler des problèmes de routage ou des lacunes en matière de compétences. Où les obtenir Cet événement peut être capturé explicitement dans le journal d’audit des champs « Assigned Group » ou « Assignee » du formulaire SRM:Request ou des formulaires associés de traitement, par exemple WOI:WorkOrder. Collecte Horodatage du journal d’audit indiquant qu’une valeur non nulle a été définie pour la première fois dans le champ « Assignee ». Type d’événement explicit
	Demande de service annulée	La demande de service a été retirée par le demandeur ou le service desk avant la fin de son traitement. Il s’agit d’un état terminal de la demande.
Pourquoi c’est important Le suivi des annulations permet d’identifier des tendances, par exemple les demandes incorrectes ou les services qui ne sont plus nécessaires, afin d’améliorer le catalogue de services. Où les obtenir Déduit d’une modification du statut du formulaire SRM:Request vers « Canceled ». Collecte 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 dans un état archivé en lecture seule. Cette étape intervient après la résolution et l’expiration éventuelle de la période de confirmation.
Pourquoi c’est important Cette activité représente la fin définitive du processus. Le délai entre « Resolved » et « Closed » peut mettre en évidence des inefficacités dans la procédure de clôture. Où les obtenir Déduit de la modification finale du statut du formulaire SRM:Request vers « Closed ». Collecte 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 une confirmation finale ou sera automatiquement clôturée après une période définie.
Pourquoi c’est important Ce jalon important marque la fin du cycle de prestation de service. Il constitue le point de terminaison principal pour mesurer le délai de résolution et le respect des SLA. Où les obtenir Déduit d’une modification du statut du formulaire SRM:Request vers « Resolved » ou « Completed ». Collecte 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 à la soumission d’une nouvelle demande de service par un utilisateur. Elle est enregistrée lorsqu’une nouvelle entrée est créée dans le formulaire SRM:Request avec un statut initial, généralement « Submitted ».
Pourquoi c’est important Il s’agit du point de départ de chaque demande de service. Cette activité est essentielle pour mesurer la durée totale du cycle de vie et analyser le volume des demandes reçues. Où les obtenir Cet événement est déduit de l’horodatage de création et du statut initial, par exemple « Submitted », d’un enregistrement du formulaire SRM:Request. Collecte Identifiez 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 affecté a commencé à traiter activement la demande de service. La demande est ainsi passée de la file d’attente à un état de travail actif.
Pourquoi c’est important Cette étape marque le début du travail de traitement créateur de valeur. L’analyse du temps consacré à cette phase permet de mieux comprendre la productivité des Ressources et la complexité du traitement. Où les obtenir Déduit d’une modification du statut du formulaire SRM:Request vers « In Progress ». Collecte 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 partie compétente, ce qui permet au processus de traitement de se poursuivre. Cet événement intervient généralement après le statut « Waiting for Approval ».
Pourquoi c’est important Cette étape marque la fin du sous-processus d’approbation. Elle constitue un jalon important pour suivre la durée des approbations et leur impact sur le délai global de résolution. Où les obtenir Déduit d’une modification du statut du formulaire SRM:Request, qui passe de « Waiting Approval » à un statut ultérieur tel que « Planning » ou « In Progress ». La décision d’approbation elle-même est enregistrée dans les formulaires d’approbation associés. Collecte Horodatage de la modification du statut quittant « Waiting Approval » après 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 et attend une décision avant le début de son traitement. Cette étape est fréquente pour les demandes impliquant des coûts ou des droits d’accès.
Pourquoi c’est important Cette activité isole les retards liés aux approbations, afin d’analyser les temps de cycle des approbations et d’identifier les goulots d’étranglement dans la chaîne d’approbation. Où les obtenir Déduit d’une modification du statut du formulaire SRM:Request vers une valeur telle que « Waiting Approval ». Collecte 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	La demande de service fait l’objet d’un premier examen et d’un triage par le service desk afin d’en déterminer la nature, la priorité et l’équipe chargée de son traitement. Cette étape est généralement représentée par une modification du statut de l’enregistrement de la demande.
Pourquoi c’est important Le suivi de cette activité permet de mesurer l’efficacité du triage et d’identifier les délais entre la soumission et l’affectation. Il s’agit d’un élément essentiel du KPI « Average Triage Time ». Où les obtenir Déduit d’une modification du statut du formulaire SRM:Request vers une valeur telle que « In Review » ou « Planning ». Collecte 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 au cours d’une phase d’approbation. Il s’agit d’un état terminal qui interrompt le processus avant le début du traitement.
Pourquoi c’est important L’analyse des demandes rejetées peut mettre en évidence des problèmes liés à la justification des demandes, aux critères d’éligibilité ou aux politiques d’approbation. Où les obtenir Déduit d’une modification du statut du formulaire SRM:Request vers « Rejected ». Collecte 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 a quitté un état d’attente, généralement après que l’utilisateur a fourni les informations requises. L’agent chargé du traitement reprend alors le travail sur la demande.
Pourquoi c’est important Cette étape marque la fin d’une période d’attente et permet de mesurer précisément les temps d’attente externes ainsi que leur impact sur la conformité aux SLA. Où les obtenir Déduit lorsque le statut de SRM:Request passe de « Pending » à « In Progress ». Collecte 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 supplémentaires de la part du demandeur pour poursuivre son travail. La demande est généralement placée dans l’état « Pending ».
Pourquoi c’est important Cette activité est essentielle pour calculer le « External Information Wait Time » et identifier la fréquence à laquelle les demandes sont bloquées en raison d’informations incomplètes. Où les obtenir Déduit d’une modification du statut du formulaire SRM:Request vers « Pending », accompagnée d’un motif tel que « Customer Hold » ou « Awaiting Information ». Collecte Horodatage de la modification du 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 finale de la demande.
Pourquoi c’est important Cette étape fournit un indicateur clair de la satisfaction du client et conclut officiellement l’interaction de service. Elle distingue la résolution du processus de l’acceptation par le client. Où les obtenir Cet événement peut être capturé dans les journaux de travail ou les notes d’activité de SRM:Request lorsqu’un utilisateur confirme la résolution via le portail ou par e-mail. Il ne correspond pas toujours à un statut distinct. Collecte Examinez les journaux de travail SRM:WorkInfo à la recherche d’entrées indiquant une confirmation de l’utilisateur ou l’achèvement d’une enquête. Type d’événement explicit
	Solution mise en œuvre	Le travail technique nécessaire au traitement de la demande de service a été réalisé par l’agent. La demande est désormais prête à être confirmée avec l’utilisateur avant sa résolution officielle.
Pourquoi c’est important Cette activité distingue l’achèvement technique de la résolution officielle et permet d’identifier les éventuels délais entre la fin du travail et la confirmation de l’utilisateur. Où les obtenir Cette étape peut être déduite d’une modification du statut d’un ticket de traitement backend, par exemple lorsque le statut d’un Work Order passe à « Completed », avant que la demande SRM:Request parente soit marquée comme « Resolved ». Collecte Horodatage auquel un ticket backend, tel qu’un Work Order ou un Incident, associé à SRM:Request est marqué comme terminé. Type d’événement inferred

Recommandé Facultatif

Guides d’extraction

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

Étapes

Accédez à Smart Reporting : Connectez-vous à votre environnement BMC Helix ITSM. Accédez à la section des rapports, puis lancez Smart Reporting. Selon votre version, cette fonctionnalité peut être appelée « Reports » ou « Smart Reporting ».
Créez un rapport : Dans l’interface Smart Reporting, sélectionnez l’option permettant de créer un rapport. Choisissez « Report » comme type de rapport.
Sélectionnez 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 Service Request, généralement basée sur le formulaire SRM:Request.
Ajoutez des formulaires supplémentaires (jointures) : Pour couvrir l’ensemble du cycle de vie, vous devez joindre le formulaire principal SRM:Request aux formulaires associés. Utilisez l’onglet « Données » et 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 obtenir les événements liés aux approbations, comme les approbations et les rejets. Une jointure personnalisée peut être nécessaire.
Définissez les colonnes du rapport : Faites glisser les champs requis des formulaires joints vers la zone « Columns ». Il s’agit notamment de Request Number, Submit Date, État, Description, Priority, Assigned To et Assigned Group du formulaire SRM:Request, ainsi que des champs associés provenant des formulaires joints.
Créez des champs calculés pour les activités : Cette méthode repose sur la création d’une série de champs calculés représentant l’horodatage de chaque activité. Accédez à l’onglet « Données » et créez un champ calculé pour chaque activité. Par exemple :
- Horodatage de soumission : Utilisez directement le champ Submit Date.
- Horodatage de l’approbation : Utilisez Signature Date du formulaire AP:Signature.
- Horodatage du traitement en cours : Utilisez MIN(Submit Date) de SRM:WorkInfo, regroupé par Request Number.
Structurez le rapport pour l’union : Smart Reporting ne propose pas de bouton « UNION ALL » simple comme SQL. Pour obtenir ce résultat, créez un rapport unique et utilisez des fonctions avancées ou des sous-requêtes afin de faire 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 formater l’export final afin de transformer ces colonnes en lignes distinctes pour chaque activité.
Appliquez des filtres : Pour limiter le périmètre des données et améliorer les performances, ajoutez des filtres à votre rapport. Au minimum, filtrez le champ Submit Date du formulaire SRM:Request afin de sélectionner une période donnée. Ajoutez également un filtre « Company » si vous travaillez dans un environnement multi-tenant.
Exécutez le rapport et prévisualisez les données : Exécutez le rapport pour vérifier que les données sont correctement récupérées. Contrôlez les jointures, le remplissage des colonnes et le retour des horodatages attendus par vos champs calculés.
Exportez le rapport : Une fois le rapport validé, exportez les données. Choisissez CSV ou Microsoft Excel comme format d’export, car ces formats sont faciles à traiter pour une importation dans des outils de Process Mining.
Transformez les données finales : Après l’export, transformez les données d’un format large, avec une ligne par demande de service et de nombreuses colonnes d’horodatage, en format long, avec une ligne par activité. Utilisez un script, par exemple en Python ou PowerShell, ou un outil tel qu’Excel Power Query pour transformer les colonnes d’horodatage en 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é des autorisations de reporting dans BMC Helix ITSM, notamment des droits nécessaires pour créer et exécuter des rapports dans Smart Reporting. Vous devez également être autorisé à lire les données des formulaires SRM:Request, SRM:WorkInfo et AP:Signature.
Formulaires clés : Le rapport est construit en joignant les formulaires principaux suivants :
- SRM:Request : formulaire principal contenant les informations essentielles de la demande de service.
- SRM:WorkInfo : contient les entrées du journal de travail utilisées pour déduire les activités de traitement.
- AP:Signature : contient les enregistrements d’approbation essentiels au suivi des activités liées aux approbations.
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 afin de trouver un équilibre entre représentativité de l’échantillon et performances du rapport.
Filtres importants : En plus de la période, filtrez le champ « Company » pour isoler les données d’une entité métier précise. Vous pouvez également exclure certains types de demandes ou statuts, comme « Draft », qui ne sont pas pertinents pour l’analyse du processus.
Considérations relatives aux performances : Les rapports qui joignent plusieurs formulaires sur une longue période peuvent être longs à générer. Pour les volumes importants, il est vivement recommandé de planifier leur exécution en dehors des heures de pointe. Si des délais d’expiration surviennent, envisagez de diviser l’extraction en lots mensuels plus petits.

a 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 : Vérifiez que vous disposez d’un client de base de données, comme 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 de base de données AR System.
Préparer la requête : Copiez la requête SQL complète fournie dans la section « Query » de ce document dans l’éditeur de requêtes de votre client de base de données.
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 pour l’extraction, par exemple « 2023-01-01 » et « 2023-12-31 ». Remplacez :company_name par le nom de l’entreprise à utiliser pour le filtrage, le cas échéant.
Exécuter la requête : Exécutez la requête SQL modifiée. Selon la période sélectionnée 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, un jeu de résultats contenant le journal d’événements s’affiche. Vérifiez rapidement que les données sont correctement renseignées et que les colonnes et activités attendues sont présentes.
Gérer les horodatages : Vérifiez que toutes les colonnes d’horodatage, notamment EventStartTime, EventEndTime et LastDataUpdate, utilisent un format cohérent, tel que « 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 le chargement : Donnez au fichier un nom approprié, par exemple servicerequest_eventlog.csv. Il est alors prêt à être chargé dans la plateforme ProcessMind.

Configuration

Identifiants de base de données : Un compte utilisateur en lecture seule pour la base de données AR System est requis. Cela é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. Il est essentiel de définir une période précise et raisonnable, généralement de 3 à 12 mois, afin de maîtriser les performances de la requête et le volume de données. Le filtrage s’applique au champ Submit_Date de la demande de service.
Filtre Company : Le paramètre :company_name permet de filtrer les demandes d’une entreprise opérationnelle précise. 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 votre système le permet.
Valeurs de statut : La requête utilise les valeurs entières standard des statuts de BMC Helix ITSM, par exemple Submitted = 0 et In Review = 1. Votre système peut utiliser des statuts personnalisés ou une autre correspondance entre statuts et valeurs entières. Vérifiez ces valeurs dans le formulaire SYS:Status ou dans Developer Studio, puis adaptez si nécessaire les clauses WHERE de la requête.
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.

a 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

Vérifiez les prérequis : Assurez-vous que Python 3.6 ou une version ultérieure est installé sur votre système. Installez la bibliothèque requests, nécessaire aux appels API HTTP, en exécutant pip install requests dans votre terminal ou votre invite de commandes.
Obtenez les identifiants 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’autorisations en lecture seule sur le formulaire SRM:Request et sur le formulaire du journal d’audit correspondant, souvent nommé SRM:Request_AuditLog ou de manière similaire. Notez votre nom d’utilisateur, votre mot de passe et l’URL de base de votre instance BMC Helix, par exemple https://[your-company].bmc.com.
Configurez le script Python : Copiez le script Python fourni dans un fichier, par exemple extract_servicerequests.py. Modifiez le script et renseignez les variables d’espace réservé situées en haut : 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éfinissez la période d’extraction : Modifiez les variables START_DATE et END_DATE dans le script. Elles définissent la période d’extraction à partir de la date de soumission des demandes de service. Pour les premiers tests, utilisez une période courte, par exemple une seule journée.
Exécutez le script : Lancez le script depuis votre terminal à l’aide de la commande python extract_servicerequests.py. Le script commence par s’authentifier auprès de l’API afin d’obtenir un jeton.
Récupérez les données initiales : Le script interroge le formulaire SRM:Request afin de récupérer la liste de toutes les demandes de service créées pendant la période indiquée. Cette étape recueille l’identifiant du cas et les attributs statiques associés, comme la priorité et le type de service.
Récupérez l’historique des événements : Le script parcourt chaque identifiant de demande de service obtenu à l’étape précédente. Pour chaque identifiant, il effectue un deuxième appel API vers le formulaire du journal d’audit configuré afin de récupérer l’historique détaillé des changements d’état de la demande concernée.
Transformez 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.
Générez l’événement de soumission : Le script crée également l’activité initiale « Demande de service soumise » pour chaque demande, en utilisant le champ Submit Date du formulaire principal SRM:Request.
Exportez au format CSV : Après avoir traité toutes les demandes de service et leur historique, le script regroupe les lignes générées dans une seule liste et écrit les données 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 API : Le script utilise principalement deux points de terminaison API. L’authentification est gérée via api/jwt/login. Les données sont interrogées depuis arsys/v1/entry/SRM:Request pour obtenir la liste des cas et depuis arsys/v1/entry/[AUDIT_FORM_NAME] pour récupérer l’historique des événements.
Autorisations du compte de service : Un compte de service dédié disposant d’un accès en lecture au formulaire SRM:Request et au formulaire du journal d’audit du système est requis. L’utilisation d’un compte de service est essentielle pour la sécurité et la traçabilité.
Filtrage par période : Le script filtre les demandes de service selon leur champ Submit Date. Il est recommandé d’extraire les données par lots gérables, par exemple sur des périodes de 3 à 6 mois, afin de garantir des performances fiables.
Association des états aux activités : Le dictionnaire STATUS_ACTIVITY_MAP du script constitue le cœur de la logique de transformation. Il doit être configuré avec soin pour refléter les états personnalisés de votre organisation et les associer aux noms d’activités souhaités. Tout état de votre flux de travail qui ne figure pas dans le dictionnaire sera ignoré.
Formulaire du journal d’audit : La capacité du script à capturer les activités détaillées dépend entièrement de l’existence d’un journal d’audit interrogeable. Vous devez identifier dans votre environnement le nom exact du formulaire qui conserve l’historique des changements d’état des demandes de service, puis mettre à jour la variable AUDIT_FORM_NAME en conséquence.
Pagination : Le script gère automatiquement la pagination de l’API afin de récupérer tous les enregistrements. Le paramètre limit de l’appel API est défini sur 1 000 enregistrements par requête, afin de trouver un équilibre entre performances et utilisation de la mémoire.

a 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 vos données et commencer 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, éliminez les traitements trop lents et améliorez l’expérience des utilisateurs.

Démarrer l’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 la 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

a Exemple de requête sql

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

Étapes

Configuration

a Exemple de requête sql

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

Étapes

Configuration

a 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 la 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

a Exemple de requête sql

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

Étapes

Configuration

a Exemple de requête sql

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

Étapes

Configuration

a Exemple de requête python

Prêt à commencer ?

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

Nous attachons de l’importance à votre confidentialité