> 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 (21) 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 offre une vue d'ensemble claire des attributs de données essentiels à collecter et des activités clés à suivre pour votre processus de gestion des demandes de service. Il comprend également des conseils pratiques sur la manière d'extraire ces données efficacement de BMC Helix ITSM. Utilisez cette ressource pour rationaliser votre préparation de données et démarrer vos initiatives de Process Mining en toute confiance.

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

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

Télécharger le modèle

Attributs de gestion des demandes de service

Ces champs de données sont essentiels pour créer un journal d'événements (event log) complet, permettant une analyse approfondie de votre processus de gestion des demandes de service.

5 Obligatoire 6 Recommandé 10 Facultatif

	Nom	Description
	Activité ActivityName	Le nom de l'`event` ou de la tâche spécifique qui s'est produit(e) à un moment donné du cycle de vie de la demande de service.
Description Cet attribut décrit une étape spécifique ou un changement de statut dans le processus de demande de service, tel que '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 est le cœur du Process Mining. Elle permet la découverte de cartes de processus, l'identification des goulots d'étranglement et l'analyse des variantes de processus. Comprendre quelles activités se produisent, dans quel ordre et à quelle fréquence est crucial pour l'optimisation des processus. Pourquoi c'est important Les activités constituent les éléments fondamentaux de la carte des processus. Leur suivi permet la visualisation et l'analyse du flux de processus, révélant comment le travail est réellement effectué. Où obtenir Ceci est généralement dérivé des changements dans les champs 'Statut' (Status) et 'Raison du statut' (Status Reason) du formulaire 'SRM:Request' ou des journaux d'application d'exécution connexes (par exemple, Incident, Ordre de travail). Exemples Demande en attente d'approbationExécution en coursDemande de service résolueDemande de service fermée
	Heure de début EventStartTime	L'horodatage indiquant le début d'une activité ou d'un événement spécifique.
Description Cet attribut enregistre la date et l'heure précises du début d'une activité. Chaque événement dans le journal (event log), de la soumission initiale à la clôture finale, doit avoir une heure de début pour établir la séquence chronologique du processus. Cet horodatage (timestamp) est critique pour toutes les analyses de Process Mining basées sur le temps. Il est utilisé pour calculer les temps de cycle, les durées d'activités, les temps d'attente entre les étapes et pour vérifier la conformité aux SLA. Il permet la découverte des goulots d'étranglement et l'analyse de la performance du processus au fil du temps. Pourquoi c'est important L'heure de début fournit l'ordre chronologique des événements, ce qui est essentiel pour calculer les durées de processus, identifier les retards et comprendre la chronologie du processus. Où obtenir Cela correspond aux champs d'horodatage (timestamp) dans les journaux d'audit ou les tables d'historique de statut associés au formulaire 'SRM:Request', tels que 'Date de soumission' (Submit Date) pour l'événement initial. Exemples 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:00Z
	ID de demande de service ServiceRequestId	L'identifiant unique de chaque demande de service, servant de clé primaire pour suivre l'ensemble de son cycle de vie.
Description L'ID de la demande de service identifie de manière unique chaque demande de service soumise par un utilisateur ou un système. Il sert de fil conducteur central reliant tous les événements ultérieurs, de l'enregistrement initial à la clôture finale, permettant une analyse complète et de bout en bout du parcours de chaque demande de service. En Process Mining, cet ID est essentiel pour reconstituer la séquence des activités de chaque cas. Il permet à l'outil de regrouper tous les événements liés, tels que 'Demande soumise', 'Demande assignée' et 'Demande de service clôturée', en une seule instance de processus, formant la base de toute l'analyse de processus. Pourquoi c'est important C'est l'identifiant de cas fondamental. Sans lui, il est impossible de tracer le parcours de bout en bout d'une demande de service, rendant impossible la découverte et l'analyse des processus. Où obtenir Il s'agit généralement du champ 'InstanceId' ou 'Numéro de demande' (Request Number) du formulaire 'SRM:Request' dans BMC Helix ITSM. Exemples SR000010572931SR000010572932SR000010572933
	Dernière mise à jour des données LastDataUpdate	L'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 la dernière extraction de données de BMC Helix ITSM. Il fournit aux utilisateurs un contexte sur la fraîcheur des données qu'ils analysent, s'assurant qu'ils sont conscients de la période couverte par l'analyse. C'est un attribut de métadonnée critique pour tout dashboard ou analyse de Process Mining. Il permet aux utilisateurs de comprendre si les insights sont basés sur des données quasi en temps réel ou sur un instantané historique, ce qui affecte la validité et la pertinence des conclusions tirées. Pourquoi c'est important Il informe les utilisateurs sur l'actualité des données, ce qui est essentiel pour prendre des décisions basées sur les informations de performance de processus les plus récentes disponibles. Où obtenir Cet horodatage (timestamp) est généré et ajouté pendant le processus d'extraction et de chargement des données. Exemples 2024-05-21T08:00:00Z
	Système source SourceSystem	Identifie le `système` à partir duquel les `données` ont été extraites.
Description Cet attribut spécifie l'origine des données de processus. Pour cette vue, il serait défini statiquement comme 'BMC Helix ITSM' pour indiquer que tous les événements liés aux demandes de service proviennent de ce système. Dans les environnements avec plusieurs systèmes intégrés, ce champ est crucial pour comprendre la lignée des données et partitionner les données en fonction de leur source. Il assure clarté et traçabilité, en particulier lors de la fusion de données provenant de différentes plateformes. Pourquoi c'est important Il fournit un contexte sur 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 multi-systèmes. Où obtenir Il s'agit d'une valeur statique ajoutée pendant le processus d'extraction et de transformation des données, et non d'un champ au sein de BMC Helix ITSM lui-même. Exemples BMC Helix ITSM
	Agent assigné AssignedAgent	L'utilisateur individuel actuellement affecté au traitement de la demande de service.
Description Cet attribut identifie l'agent IT ou le membre du personnel de support spécifique responsable de la demande à un moment donné. Les changements dans ce champ au cours du cycle de vie d'une seule demande indiquent un transfert ou une réaffectation. Cet attribut est crucial pour l'analyse de la performance des agents et de la charge de travail. Il permet de suivre le nombre de demandes traitées par chaque agent, leur temps de résolution moyen et la fréquence des réaffectations. Ces données soutiennent la gestion des ressources et l'identification des opportunités de formation. Pourquoi c'est important Le suivi de l'agent assigné 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ù obtenir Cela correspond au champ 'Assigné à' (Assignee ou Assigned To) du dossier d'exécution (par exemple, Ordre de travail, Incident) associé à la demande de service. Exemples Bob SmithAlice JohnsonCharlie Brown
	Équipe assignée AssignedTeam	Le groupe ou l'équipe de support actuellement affecté(e) à la demande de service.
Description Cet attribut identifie le groupe fonctionnel responsable du traitement de la demande, tel que le 'Service d'assistance', l''Équipe réseau' ou l''Administration de bases de données'. Un changement dans ce champ signifie un transfert de responsabilité entre équipes. L'analyse basée sur l'équipe assignée aide à identifier les goulots d'étranglement au niveau de l'équipe, à analyser les transferts inter-équipes et à évaluer l'efficacité des différents groupes de support. C'est essentiel pour les dashboards de retravail et de réaffectation des demandes, ainsi que d'efficacité du triage, révélant les schémas de routage du travail au sein de l'organisation. Pourquoi c'est important Il permet l'analyse du flux de processus entre différents groupes fonctionnels, aidant à identifier les inefficacités de routage et à mesurer la performance au niveau de l'équipe. Où obtenir Cela correspond au champ 'Groupe assigné' (Assigned Group) du dossier d'exécution (par exemple, Ordre de travail, Incident) associé à la demande de service. Exemples Service DeskSupport InfrastructureSupport Applicatif Niveau 2
	Heure de fin EventEndTime	L'horodatage indiquant quand une activité ou un événement spécifique a été achevé.
Description L'heure de fin marque la conclusion d'une activité. Si de nombreuses activités dans les systèmes ITSM sont des changements de statut instantanés, certaines ont une durée mesurable. Disposer d'une heure de fin permet un calcul précis de la durée de ces activités. En analyse, l'heure de fin est utilisée conjointement avec l'heure de début pour calculer le temps de traitement des activités individuelles. Cela aide à identifier quelles tâches spécifiques, et pas seulement le temps d'attente entre elles, consomment le plus de temps dans le processus. Pourquoi c'est important Il permet le calcul des temps de traitement des activités, ce qui est crucial pour identifier les étapes inefficaces et comprendre où les ressources passent leur temps. Où obtenir Cela peut être dérivé. L'heure de fin d'une activité est souvent l'heure de début de l'activité séquentielle suivante pour le même cas. Pour l'activité finale, il s'agirait de 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	Le niveau de priorité attribué à la demande de service, indiquant son impact commercial et son urgence.
Description La priorité détermine l'ordre et la rapidité avec lesquels les demandes doivent être traitées. Les valeurs courantes incluent 'Critique', 'Élevée', 'Moyenne' et 'Faible'. Cette affectation est souvent basée sur une combinaison de l'impact de la demande sur l'entreprise et de son urgence. L'analyse par priorité est essentielle pour évaluer si les demandes de haute priorité sont traitées plus rapidement que celles de faible priorité. C'est une dimension clé dans les tableaux de bord pour le temps de résolution et la conformité aux SLA, aidant à garantir que les ressources sont allouées de manière appropriée aux besoins commerciaux les plus critiques. Pourquoi c'est important Il aide à évaluer si le processus priorise correctement le travail et respecte les niveaux de service attendus pour les demandes ayant différents niveaux d'impact commercial. Où obtenir Il s'agit du champ 'Priorité' (Priority) du formulaire 'SRM:Request'. Exemples CritiqueÉlevéMoyenFaible
	Statut de la demande RequestStatus	Le statut de la demande de service au moment de l'événement, tel que 'En cours', 'En attente' ou 'Clôturé'.
Description Cet attribut capture l'état de la demande de service à différents moments de son cycle de vie. Le statut fournit un contexte pour chaque activité et est souvent la source d'où l'attribut 'Activité' lui-même est dérivé. L'analyse par statut aide à comprendre combien de temps les demandes passent dans certains états, tels que 'En attente du client' ou 'En attente d'approbation'. C'est essentiel pour identifier les goulots d'étranglement et les retards causés par des dépendances externes ou des files d'attente internes. Il soutient directement le dashboard d'Identification des goulots d'étranglement. Pourquoi c'est important Il fournit un aperçu de l'état de la demande, permettant l'analyse du temps passé en attente par rapport au temps passé en activité, ce qui est essentiel pour identifier les goulots d'étranglement. Où obtenir Il s'agit du champ 'Statut' (Status) du formulaire 'SRM:Request'. Les valeurs historiques peuvent être trouvées dans le journal d'audit (audit log). Exemples PlanificationEn coursEn attenteRésoluClôturé
	Type de service ServiceType	La catégorie ou le 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 de mot de passe' ou 'Intégration d'un nouvel employé'. C'est une dimension fondamentale pour filtrer et segmenter les données de processus. En analyse de processus, cet attribut est utilisé pour comparer les performances de différents types de demandes. Il aide à répondre à des questions telles que : 'Quels types de services prennent le plus de temps à résoudre ?' ou 'Quels types de services génèrent le plus de retravail ?'. C'est crucial pour les dashboards de Temps de Résolution et de Conformité SLA. Pourquoi c'est important Il permet la segmentation des demandes de service pour comparer les flux de processus, identifier les problèmes spécifiques à chaque type et adapter efficacement les efforts d'optimisation. Où obtenir Ces données se trouvent souvent dans le champ 'Titre' ou un champ de catégorisation sur le formulaire 'SRM:Request', dérivées du service sélectionné dans le catalogue. Exemples Nouvelle demande de matérielDemande d'accès logicielConfiguration de l'accès VPN
	Canal de soumission SubmissionChannel	La méthode ou le 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 self-service, un e-mail, un appel téléphonique au service desk ou une alerte système automatisée. Différents canaux peuvent entraîner différentes variantes de processus et temps de résolution. L'analyse du processus par canal de soumission peut révéler des inefficacités ou des meilleures pratiques associées à des méthodes d'accueil spécifiques. Par exemple, les demandes soumises via le portail self-service peuvent être résolues plus rapidement grâce à une meilleure qualité des données initiales, tandis que celles provenant d'e-mails peuvent nécessiter un triage manuel plus important. Pourquoi c'est important Il aide à comprendre comment la méthode de réception des demandes affecte l'efficacité du processus, la qualité des données et le temps de cycle global, permettant des améliorations ciblées sur des canaux spécifiques. Où obtenir Cela peut souvent être déduit de champs comme 'Type de client' ou 'Source rapportée' sur le formulaire 'SRM:Request' ou les tickets d'exécution associés. Exemples Portail `Self-Service`E-mailTéléphoneGénéré par le système
	Catégorie de résolution ResolutionCategory	La 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 'Correction logicielle', 'Formation utilisateur' ou 'Correction de données'. Il va au-delà d'un simple code de clôture pour décrire la nature de la résolution. C'est essentiel pour le dashboard de précision de la Catégorie de Résolution, où il peut être comparé au type de service initial pour vérifier la cohérence. L'analyse des catégories de résolution aide à identifier les tendances des problèmes et informe la gestion proactive des problèmes, par exemple, si de nombreuses demandes sont résolues par une formation utilisateur. Pourquoi c'est important Il offre des informations sur la nature des solutions, aidant à identifier les tendances des problèmes récurrents et les opportunités de gestion proactive des problèmes ou de formation des utilisateurs. Où obtenir Cette information fait partie des champs de catégorisation opérationnelle et produit sur le ticket d'exécution, souvent étiqueté 'Catégorie de résolution'. Exemples Administration de comptePanne MatérielleMise à niveau logicielleInformations fournies
	Code de fermeture CloseCode	Un code indiquant le résultat final ou la raison de la clôture de la demande de service.
Description Le Code de Clôture fournit un moyen standardisé de classer la résolution d'une demande de service. Les exemples incluent 'Résolu par le Service Desk', 'Annulé par l'utilisateur' ou 'Demande en double'. L'analyse des codes de clôture aide à comprendre les issues courantes des demandes. Elle peut mettre en évidence des problèmes tels qu'un nombre élevé de demandes annulées par les utilisateurs, ce qui pourrait indiquer un processus long, ou de nombreux doublons, ce qui pourrait signaler un problème de système ou de communication. Cet attribut soutient le dashboard de précision de la Catégorie de Résolution. Pourquoi c'est important Il fournit des données structurées sur les résultats des demandes, permettant l'analyse de l'efficacité de la résolution et des raisons de non-achèvement ou d'annulation. Où obtenir Cette information se trouve généralement dans un champ 'Résolution' ou 'Code de clôture' sur le ticket d'exécution associé à la demande de service. Exemples RéussiAnnulé par l'utilisateurN'est plus requisRésolution automatisée
	Date cible 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 cible SLA (Service Level Agreement) est un horodatage calculé qui représente la date limite pour l'achèvement 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 la demande. Cet attribut est fondamental pour le dashboard Vue d'ensemble de la Conformité SLA. Il sert de référence pour mesurer le temps de résolution réel. En comparant l''EventEndTime' de l'activité de résolution finale avec cette date cible, nous pouvons déterminer si l'engagement de service a été respecté. Pourquoi c'est important C'est la référence principale pour mesurer la performance du service par rapport aux engagements, ce qui le rend essentiel pour le suivi et le reporting de la conformité aux SLA. Où obtenir Cette date est calculée et stockée par le module de Gestion des Niveaux de Service (SLM) et peut être trouvée sur les formulaires SLM liés à la demande de service. Exemples 2023-10-28T17:00:00Z2023-11-01T09:00:00Z2023-10-27T12:00:00Z
	Est escaladé IsEscalated	Un indicateur booléen qui indique si la demande de service a été escaladée.
Description Cet indicateur est défini sur 'vrai' si une demande de service a fait l'objet d'une escalade fonctionnelle ou hiérarchique. Une escalade se produit généralement lorsqu'une demande ne progresse pas comme prévu, est sur le point de violer un SLA, ou nécessite une autorité supérieure pour approbation ou action. Cet attribut est essentiel pour le dashboard d'analyse de l'efficacité des escalades de demandes. Il permet de filtrer et d'analyser les parcours de processus des demandes escaladées pour comprendre ce qui les déclenche, combien de temps elles prennent à résoudre après l'escalade, et quelle est l'efficacité du processus d'escalade. Pourquoi c'est important Il permet d'isoler et d'analyser le sous-ensemble de demandes qui ont nécessité une escalade, aidant à identifier les faiblesses du processus standard ou les déclencheurs de problèmes complexes. Où obtenir Il ne s'agit généralement pas d'un champ unique. Il est dérivé en vérifiant les activités spécifiques liées à l'escalade dans le journal d'audit (audit log) ou les changements de priorité ou d'affectation qui suivent un protocole d'escalade. Exemples truefaux
	Est un retravail IsRework	Un indicateur booléen signalant si une demande de service a fait l'objet d'un remaniement, comme un retour à une étape précédente.
Description Cet indicateur identifie les demandes de service qui ont connu une boucle ou un retravail dans leur flux de processus. Par exemple, une demande passant de 'Exécution en cours' à 'Demande en cours d'examen' serait considérée comme un retravail. La définition exacte dépend de la logique du processus métier. Cet attribut soutient directement le dashboard d'analyse du retravail et de la réaffectation des demandes et le KPI Taux de retravail des demandes. Il permet de quantifier la fréquence du retravail et d'analyser les causes courantes, telles qu'une évaluation initiale incorrecte ou des informations incomplètes, menant à des inefficacités de processus. Pourquoi c'est important Il quantifie l'inefficacité des processus en signalant les cas qui s'écartent du « chemin idéal », aidant à identifier les causes profondes des boucles et du travail répété. Où obtenir Ceci est un attribut calculé dérivé de la séquence d'activités dans le journal d'événements (event log). Une logique est nécessaire pour détecter les mouvements rétrogrades dans le flux de processus. Exemples truefaux
	Nombre de transferts HandoffCount	Le 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 fois où l''Agent Assigné' ou l''Équipe Assignée' change pour une seule demande de service. Un nombre élevé de transferts peut indiquer une fragmentation du processus, un manque de résolution au premier contact ou un routage inefficace. Cet attribut est la base du KPI Transferts d'Agents Moyens par Demande et est utilisé dans le dashboard de retravail et réaffectation des demandes. L'analyse des cas avec un nombre élevé de transferts peut révéler des opportunités d'améliorer le triage, de fournir une meilleure formation ou de rationaliser le processus de résolution pour réduire les délais et améliorer la satisfaction client. Pourquoi c'est important Il mesure la fragmentation des processus et les frais généraux de communication. Un nombre élevé de transferts est souvent corrélé à des temps de résolution plus longs et à une efficacité de processus moindre. Où obtenir Ceci est une métrique calculée obtenue en comptant le nombre de valeurs distinctes dans l'attribut 'Agent Assigné' ou 'Équipe Assignée' pour chaque ID de demande de service unique. Exemples 0135
	Service du demandeur RequestorDepartment	Le service ou l'unité commerciale de l'utilisateur qui a soumis la demande.
Description Cet attribut identifie le service organisationnel de la personne demandant le service, tel que 'Finance', 'Ressources Humaines' ou 'IT'. Cette information est généralement tirée du profil de l'utilisateur dans le système. La segmentation de l'analyse de processus par service permet d'identifier les besoins spécifiques à chaque service, les modèles de demandes et les domaines potentiels d'amélioration de la formation ou des services. Cela peut aider à répondre à des questions telles que : 'Le service financier subit-il des temps d'attente plus longs pour ses demandes ?'. Pourquoi c'est important Il permet l'analyse de la consommation de services et de la performance des processus par unité commerciale, ce qui peut mettre en évidence des problèmes ou des tendances spécifiques à un département. Où obtenir Ces informations sont généralement récupérées du profil de l'utilisateur associé à l'utilisateur 'Demandé pour' (Requested For) sur le formulaire 'SRM:Request'. Exemples FinanceVentesRessources HumainesTechnologies de l'Information
	SLA est enfreint IsSlaBreached	Un indicateur booléen signalant si la demande de service a été résolue après sa date cible de SLA.
Description Cet indicateur calculé est défini sur 'vrai' si l'horodatage de résolution finale de la demande de service est postérieur à sa 'Date Cible SLA'. Il fournit un résultat simple et binaire pour la performance SLA par demande. Cet attribut est essentiel pour le dashboard Vue d'ensemble de la Conformité SLA et le KPI Taux de Respect des SLA. Il permet une agrégation facile pour calculer les taux de conformité globaux et permet le filtrage pour analyser les caractéristiques de processus des demandes non conformes par rapport aux demandes conformes, aidant à identifier les causes profondes des échecs de SLA. Pourquoi c'est important Il simplifie l'analyse de la performance des SLA en convertissant une comparaison d'horodatage en un simple indicateur booléen, facilitant ainsi la mesure et la visualisation des taux de conformité. Où obtenir Ceci est un champ calculé. La logique est : SI 'Horodatage de résolution' > 'SlaTargetDate' ALORS vrai SINON faux. Exemples truefaux
	Temps de cycle CycleTime	Le temps total écoulé entre la création de la demande de service et sa résolution finale.
Description Le temps de cycle, également appelé durée de bout en bout, mesure la durée de vie totale d'une demande de service. Il est calculé comme la différence entre l'horodatage du premier événement (par exemple, 'Demande de service soumise') et le dernier événement de résolution (par exemple, 'Demande de service résolue'). C'est l'un des KPI les plus fondamentaux du process mining, qui soutient directement le tableau de bord du temps de résolution des demandes de service. L'analyse du temps de cycle moyen, et sa segmentation par dimensions comme le type de service ou la priorité, révèle l'efficacité globale du processus et met en évidence les domaines qui prennent trop de temps. Pourquoi c'est important C'est une mesure primaire de l'efficacité des processus. Comprendre et réduire le temps de cycle est souvent un objectif clé des initiatives d'amélioration des processus. Où obtenir Ceci est une métrique calculée. Elle est dérivée en soustrayant la 'Date de soumission' de la 'Date de clôture' ou 'Date de résolution' pour chaque ID de demande de service unique. Exemples 2 jours 4 heures8 heures 30 minutes15 jours

Obligatoire Recommandé Facultatif

Activités de gestion des demandes de service

Ces étapes clés du processus et ces jalons doivent être capturés dans votre journal d'événements (event log) pour une découverte et une visualisation précises du processus.

6 Recommandé 8 Facultatif

	Activité	Description
	Demande assignée	La demande de service a été attribuée à un agent d'exécution ou à une équipe spécifique chargée de réaliser le travail. Cela 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 indiquer des problèmes de routage ou des lacunes en compétences. Où obtenir Cet événement peut être capturé explicitement à partir du journal d'audit des champs 'Groupe assigné' (Assigned Group) ou 'Assigné à' (Assignee) sur le formulaire SRM:Request ou les formulaires d'application d'exécution connexes (par exemple, WOI:WorkOrder). Capture Horodatage (timestamp) du journal d'audit (audit log) montrant qu'une valeur non nulle est définie pour la première fois dans le champ 'Assigné à' (Assignee). Type d'événement explicit
	Demande de service annulée	La demande de service a été retirée soit par le demandeur, soit par le service desk avant que l'exécution ne soit achevée. C'est un état terminal pour la demande.
Pourquoi c'est important Le suivi des annulations aide à identifier des modèles, tels que des utilisateurs soumettant des demandes incorrectes ou des services n'étant plus nécessaires, ce qui peut éclairer les améliorations du catalogue de services. Où obtenir Déduit d'un changement de statut du formulaire SRM:Request à 'Annulé'. Capture Horodatage (timestamp) de l'événement de mise à jour où le champ 'Statut' (Status) de SRM:Request passe à 'Annulée'. Type d'événement inferred
	Demande de service fermée	La demande de service est formellement clôturée et déplacée vers un état archivé, en lecture seule. Cela se produit après la résolution et l'expiration de toute période de confirmation.
Pourquoi c'est important Cette activité représente la fin définitive du processus. Le temps entre 'Résolu' et 'Clôturé' peut mettre en évidence des inefficacités dans la procédure de clôture. Où obtenir Déduit du changement de statut final du formulaire SRM:Request à 'Clôturé'. Capture Horodatage (timestamp) de l'événement de mise à jour où le champ 'Statut' (Status) de SRM:Request passe à 'Clôturée'. Type d'événement inferred
	Demande de service résolue	L'exécution de la demande de service est terminée et la résolution a été communiquée au demandeur. La demande est en attente de confirmation finale ou se clôturera automatiquement après une période définie.
Pourquoi c'est important Une étape cruciale marquant la fin du cycle de prestation de service. C'est le point final principal pour mesurer le temps de résolution et le respect des SLA. Où obtenir Déduit d'un changement de statut du formulaire SRM:Request à 'Résolu' ou 'Terminé'. Capture Horodatage (timestamp) de l'événement de mise à jour où le champ 'Statut' (Status) de SRM:Request passe à 'Résolue' ou 'Complétée'. Type d'événement inferred
	Demande de service soumise	Cette activité marque 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, typiquement 'Soumise'.
Pourquoi c'est important C'est le point de départ de chaque cas de demande de service, essentiel pour mesurer la durée totale du cycle de vie et analyser les volumes de demandes entrantes. Où obtenir Cet événement est déduit de l'horodatage (timestamp) de création et du statut initial (par exemple, 'Soumise') d'un enregistrement dans le formulaire SRM:Request. Capture Identifier l'horodatage de création d'un nouvel ID de demande de service dans le formulaire SRM:Request lorsque le statut est 'Soumis'. Type d'événement inferred
	Exécution en cours	L'agent ou l'équipe désignée a commencé à travailler activement à la réalisation de la demande de service. Cela indique que la demande est passée d'une file d'attente à un état de travail actif.
Pourquoi c'est important Marque le début du travail d'exécution à valeur ajoutée. L'analyse du temps passé dans cette phase permet de comprendre la productivité des ressources et la complexité de l'exécution. Où obtenir Déduit d'un changement de statut du formulaire SRM:Request à 'En cours'. Capture Horodatage (timestamp) de l'événement de mise à jour où le champ 'Statut' (Status) de SRM:Request passe à 'En cours'. Type d'événement inferred
	Demande approuvée	La demande de service a été formellement approuvée par la partie requise, permettant au processus d'exécution de se poursuivre. Cet événement fait généralement suite à un statut 'En attente d'approbation'.
Pourquoi c'est important Marque la fin du sous-processus d'approbation et constitue une étape clé pour suivre la durée des approbations et leur impact sur le temps de résolution global. Où obtenir Déduit d'un changement de statut dans le formulaire SRM:Request de 'En attente d'approbation' à un statut ultérieur tel que 'Planification' ou 'En cours'. La décision d'approbation elle-même est enregistrée dans les formulaires d'approbation liés. Capture Horodatage (timestamp) du changement de statut hors de 'En attente d'approbation' après une décision d'approbation positive. Type d'événement inferred
	Demande en attente d'approbation	La demande de service a été soumise à un approbateur désigné ou à un groupe d'approbation et est en attente d'une décision avant que l'exécution puisse commencer. Il s'agit d'une étape courante pour les demandes impliquant des coûts ou des droits d'accès.
Pourquoi c'est important Cette activité isole les retards liés à l'approbation, permettant l'analyse des temps de cycle d'approbation et l'identification des goulots d'étranglement dans la chaîne d'approbation. Où obtenir Déduit d'un changement de statut du formulaire SRM:Request à une valeur comme 'En attente d'approbation'. Capture Horodatage (timestamp) de l'événement de mise à jour où le champ 'Statut' (Status) de SRM:Request passe à 'En attente d'approbation'. Type d'événement inferred
	Demande en cours d'examen	La demande de service fait l'objet d'un examen initial et d'un triage par le service desk afin de déterminer sa nature, sa priorité et l'équipe d'exécution appropriée. Cela est généralement représenté par un changement de statut dans l'enregistrement de la demande.
Pourquoi c'est important Le suivi de cette activité aide à mesurer l'efficacité du triage et identifie les retards entre la soumission et l'affectation, ce qui est crucial pour le KPI 'Temps de triage moyen'. Où obtenir Déduit d'un changement de statut du formulaire SRM:Request à une valeur comme 'En revue' ou 'Planification'. Capture Horodatage (timestamp) de l'événement de mise à jour où le champ 'Statut' (Status) de SRM:Request passe à 'En examen'. Type d'événement inferred
	Demande rejetée	La demande de service a été refusée pendant une phase d'approbation. C'est un état terminal qui arrête le processus avant que l'exécution ne commence.
Pourquoi c'est important L'analyse des demandes rejetées peut mettre en évidence des problèmes liés aux justifications de demande, aux critères d'éligibilité ou aux politiques d'approbation. Où obtenir Déduit d'un changement de statut du formulaire SRM:Request à 'Rejeté'. Capture Horodatage (timestamp) de l'événement de mise à jour où le champ 'Statut' (Status) de SRM:Request passe à 'Rejetée'. Type d'événement inferred
	Demande reprise	La demande de service est sortie d'un état d'attente, généralement après que les informations requises aient été fournies par l'utilisateur. Le travail sur la demande est repris par l'agent d'exécution.
Pourquoi c'est important Marque la fin d'une période d'attente, permettant une mesure précise des temps d'attente externes et de leur impact sur le respect des SLA. Où obtenir Déduit lorsque le statut du SRM:Request passe de 'En attente' à 'En cours'. Capture Horodatage (timestamp) de l'événement de mise à jour où le champ 'Statut' (Status) de SRM:Request passe de 'En attente' à 'En cours'. Type d'événement inferred
	Informations demandées à l'utilisateur	L'agent d'exécution nécessite des informations supplémentaires du demandeur pour poursuivre le travail. La demande est généralement placée en état 'En attente'.
Pourquoi c'est important Cette activité est cruciale pour calculer le 'Temps d'attente d'informations externes', identifiant la fréquence à laquelle les demandes sont bloquées en raison d'informations incomplètes. Où obtenir Déduit d'un changement de statut du formulaire SRM:Request à 'En attente' avec une raison de statut comme 'Attente client' ou 'En attente d'informations'. Capture Horodatage (timestamp) du changement de statut vers 'En attente' combiné à une raison de statut spécifique. Type d'événement inferred
	Résolution confirmée par l'utilisateur	Le demandeur a activement confirmé que le service a été fourni de manière satisfaisante et que la demande est résolue. Cela déclenche souvent la clôture finale de la demande.
Pourquoi c'est important Fournit un indicateur clair de la satisfaction client et conclut formellement l'interaction de service. Cela distingue la résolution du processus de l'acceptation par le client. Où obtenir Cet événement pourrait être capturé dans les journaux de travail ou les notes d'activité de SRM:Request lorsqu'un utilisateur confirme via le portail ou par e-mail. Ce n'est pas toujours un statut discret. Capture Scannez les journaux de travail (SRM:WorkInfo) pour des entrées spécifiques indiquant la confirmation de l'utilisateur ou la complétion d'un sondage. Type d'événement explicit
	Solution implémentée	Le travail technique requis pour exécuter la demande de service a été accompli par l'agent. La demande est maintenant prête pour confirmation avec l'utilisateur avant d'être formellement résolue.
Pourquoi c'est important Cette activité sépare l'achèvement technique de la résolution formelle, aidant à identifier tout retard entre la fin du travail et la confirmation de l'utilisateur. Où obtenir Cela peut être déduit d'un changement de statut sur un ticket d'exécution backend (par exemple, statut de l'ordre de travail à 'Terminé') avant que le SRM:Request parent ne soit marqué comme 'Résolu'. Capture Horodatage (timestamp) lorsqu'un ticket backend (Ordre de travail, Incident, etc.) lié au SRM:Request est marqué comme terminé. Type d'événement inferred

Recommandé Facultatif

Guides d'extraction

Comment obtenir vos données de BMC Helix ITSM

Étapes

Accéder à Smart Reporting : Connectez-vous à votre environnement BMC Helix ITSM. Naviguez vers la section de reporting et lancez Smart Reporting. Selon votre version, cela peut être étiqueté comme 'Rapports' ou 'Smart Reporting'.
Créer un Nouveau Rapport : Une fois dans l'interface Smart Reporting, sélectionnez l'option pour créer un nouveau rapport. Choisissez 'Rapport' comme type.
Sélectionner la Source de Données et la Vue : Il vous sera demandé de 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, qui est généralement basée sur le formulaire SRM:Request.
Ajouter des Formulaires Supplémentaires (Jointures) : Pour capturer le cycle de vie complet, vous devez joindre le formulaire principal SRM:Request avec les formulaires associés. Utilisez l'onglet 'Données' et joignez les éléments suivants :
- SRM:WorkInfo (sur SR ID+ = Request Number) pour obtenir des détails sur les activités de réalisation et les journaux de travail.
- AP:Signature (sur Request = SRInstanceID) pour obtenir les événements liés aux approbations comme les approbations et les rejets. Vous pourriez avoir besoin d'une jointure personnalisée pour cela.
Définir les Colonnes du Rapport : Glissez-déposez les champs requis des formulaires joints dans la zone 'Colonnes'. Cela inclura des champs comme Request Number, Submit Date, Status, Description, Priority, Assigned To et Assigned Group du formulaire SRM:Request, ainsi que les champs connexes des formulaires joints.
Créer des Champs Calculés pour les Activités : Le cœur de cette méthode est la création d'une série de champs calculés pour représenter l'horodatage de chaque activité. Allez dans l'onglet 'Données' et créez un nouveau champ calculé pour chaque activité. Par exemple :
- Horodatage de Soumission : Utilisez directement le champ Submit Date.
- Horodatage d'Approbation : Utilisez le Signature Date du formulaire AP:Signature.
- Horodatage de Travail en Cours : Utilisez le MIN(Submit Date) du formulaire SRM:WorkInfo groupé par numéro de requête.
Structurer le Rapport pour l'Union : Smart Reporting ne dispose pas d'un simple bouton 'UNION ALL' comme SQL. Pour y parvenir, vous créerez un seul rapport et utiliserez des fonctions avancées ou des sous-requêtes pour pivoter les données. Une technique courante consiste à créer plusieurs colonnes calculées, une pour l'horodatage de chaque activité. Vous devrez ensuite formater l'exportation finale pour transformer ces colonnes en lignes distinctes pour chaque activité.
Appliquer des Filtres : Pour limiter la portée des données et améliorer les performances, ajoutez des filtres à votre rapport. Au minimum, filtrez par Submit Date du formulaire SRM:Request pour sélectionner une plage de dates spécifique. Ajoutez également des filtres pour 'Company' si vous opérez dans un environnement multi-client.
Exécuter et Prévisualiser les Données : Exécutez le rapport pour vous assurer que les données sont extraites correctement. Vérifiez la justesse des jointures, des colonnes remplies et que vos champs calculés renvoient les horodatages attendus.
Exporter le Rapport : Une fois le rapport validé, exportez les données. Choisissez CSV ou Microsoft Excel comme format d'exportation, car ils sont facilement traitables pour l'importation dans les outils de process mining.
Transformation Finale des Données : Après l'exportation, vous devez transformer les données d'un format large (une ligne par demande de service avec de nombreuses colonnes d'horodatage) à un format long (une ligne par activité). Utilisez un script (par exemple, Python, PowerShell) ou un outil comme Excel Power Query pour "dépivoter" les colonnes d'horodatage en deux colonnes : ActivityName et EventStartTime. Cette étape est essentielle pour créer la structure de journal d'événements requise.

Configuration

Prérequis : Vous devez disposer d'un compte utilisateur avec des autorisations de reporting dans BMC Helix ITSM, spécifiquement l'accès pour créer et exécuter des rapports dans Smart Reporting. Vous avez également besoin d'autorisations pour lire les données des formulaires SRM:Request, SRM:WorkInfo et AP:Signature.
Formulaires Clés : Le rapport est construit en joignant ces formulaires principaux :
- SRM:Request : Le formulaire principal contenant les détails essentiels de la demande de service.
- SRM:WorkInfo : Contient les entrées de journal de travail, utilisées pour dériver les activités de réalisation.
- AP:Signature : Contient les enregistrements d'approbation, essentiels pour suivre les activités liées aux approbations.
Filtrage par Plage de Dates : Appliquez toujours un filtre de plage de dates sur le champ SRM:Request.Submit Date. Une plage de données de 3 à 6 mois est recommandée pour équilibrer l'obtention d'un échantillon représentatif et la performance du rapport.
Filtres Importants : En plus d'une plage de dates, filtrez par Company pour isoler les données d'une entité commerciale spécifique. Vous pouvez également vouloir exclure certains types de requêtes ou statuts, tels que 'Draft', qui ne sont pas pertinents pour l'analyse des processus.
Considérations de Performance : Les rapports qui joignent plusieurs formulaires sur une large plage de dates peuvent être lents à générer. Il est fortement recommandé de planifier l'exécution du rapport pendant les heures creuses pour les grands volumes de données. Envisagez de diviser l'extraction en plus petits segments mensuels si des délais d'attente se produisent.

a Exemple de requête config

/*
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 : Assurez-vous de disposer d'un client de base de données (comme DBeaver, SQL Server Management Studio ou Oracle SQL Developer) et d'identifiants en lecture seule pour la base de données BMC Helix AR System.
Connectez-vous à 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éparez la Requête : Copiez la requête SQL complète fournie dans la section 'Requête' de ce document dans l'éditeur de requêtes de votre client de base de données.
Définissez les Paramètres : Localisez les valeurs de substituts dans la requête. Remplacez :start_date et :end_date par la plage de dates souhaitée pour l'extraction, par exemple, '2023-01-01' et '2023-12-31'. Remplacez :company_name par le nom spécifique de la société sur laquelle vous souhaitez filtrer, si applicable.
Exécutez la Requête : Exécutez la requête SQL modifiée. Selon la plage de dates et la taille du système, cela peut prendre plusieurs minutes.
Examinez les Résultats : Une fois la requête terminée, un ensemble de résultats contenant le journal d'événements s'affichera. Examinez brièvement les données pour vous assurer qu'elles ont été correctement remplies et qu'elles contiennent les colonnes et activités attendues.
Gérez les Horodatages : Vérifiez que toutes les colonnes d'horodatage, spécifiquement EventStartTime, EventEndTime et LastDataUpdate, sont formatées de manière cohérente, telle que 'YYYY-MM-DD HH:MI:SS'. Si votre base de données les renvoie dans un format différent, ajustez les fonctions TO_CHAR ou CONVERT dans la requête en conséquence.
Exportez les Données : Utilisez la fonctionnalité d'exportation de votre client de base de données pour enregistrer l'ensemble complet des résultats sous forme de fichier CSV. Choisissez l'encodage UTF-8 pour garantir la compatibilité.
Préparez l'Upload : Nommez le fichier de manière appropriée, par exemple, servicerequest_eventlog.csv. Ce fichier est maintenant prêt à être téléversé sur 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 prévient la modification accidentelle des données et respecte les meilleures pratiques de sécurité.
Filtrage par Plage de Dates : La requête inclut les marqueurs de position :start_date et :end_date. Il est crucial de définir une plage de dates spécifique et raisonnable, généralement 3 à 12 mois de données, pour gérer la performance de la requête et le volume de données. Le filtrage est appliqué à la Submit_Date de la demande de service.
Filtre par Société : Un marqueur de position :company_name est inclus pour filtrer les requêtes pour une société d'exploitation spécifique. Si vous devez extraire des données pour toutes les sociétés, vous pouvez supprimer la ligne AND req.Company = :company_name ou la définir sur un caractère générique si pris en charge.
Valeurs de Statut : La requête utilise les valeurs entières de statut standard de BMC Helix ITSM (par exemple, Soumis = 0, En Révision = 1, etc.). Votre système peut avoir des statuts personnalisés ou des mappages d'entiers différents. Vérifiez ces valeurs par rapport au formulaire SYS:Status de votre système ou à l'environnement de développement et ajustez les clauses WHERE de la requête si nécessaire.
Performance : Les requêtes directes de base de données sur de grandes tables comme SRM_Request et ses journaux d'audit peuvent être gourmandes en ressources. Planifiez l'extraction pendant les heures creuses pour minimiser l'impact sur la performance 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

Prérequis : Assurez-vous d'avoir Python 3.6 ou une version plus récente installée sur votre système. Installez la bibliothèque requests, nécessaire pour les appels HTTP API, en exécutant pip install requests dans votre terminal ou invite de commande.
Obtenir les Identifiants API : Créez ou obtenez des identifiants pour un compte de service dédié dans BMC Helix ITSM. Ce compte nécessite au moins des autorisations en lecture seule pour le formulaire SRM:Request et le formulaire de journal d'audit correspondant, souvent nommé SRM:Request_AuditLog ou similaire. Notez votre nom d'utilisateur, mot de passe et l'URL de base de votre instance BMC Helix (par exemple, https://[votre-entreprise].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 substitution en haut : BASE_URL, USERNAME, PASSWORD et AUDIT_FORM_NAME. Ajustez le dictionnaire STATUS_ACTIVITY_MAP pour qu'il corresponde aux valeurs de statut spécifiques utilisées dans le workflow de demande de service de votre organisation.
Définir la Période d'Extraction : Modifiez les variables START_DATE et END_DATE dans le script. Cela définit la fenêtre temporelle pour l'extraction basée sur la date de soumission de la demande de service. Pour les tests initiaux, utilisez une petite plage de dates, comme une seule journée.
Exécuter le Script : Exécutez le script depuis votre terminal en utilisant la commande python extract_servicerequests.py. Le script s'authentifiera d'abord avec l'API pour obtenir un jeton.
Extraction Initiale des Données : Le script interroge le formulaire SRM:Request pour récupérer une liste de toutes les demandes de service créées dans la plage de dates spécifiée. Cette étape collecte l'ID 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 itère sur chaque ID de demande de service obtenu à l'étape précédente. Pour chaque ID, il effectue un deuxième appel API au formulaire de journal d'audit configuré pour extraire l'historique détaillé des changements de statut pour cette demande spécifique.
Transformer les Données en Journal d'Événements : Pour chaque enregistrement du journal d'audit, le script mappe le changement de statut à un nom d'activité standard en utilisant le STATUS_ACTIVITY_MAP. Il crée une ligne pour chaque activité mappée, incluant l'ID de la demande de service, le nom de l'activité et l'horodatage du changement.
Générer l'Événement Soumis : Le script crée également l'activité initiale « Demande de Service Soumise » pour chaque demande, en utilisant la Submit Date du formulaire principal SRM:Request.
Exporter en CSV : Après avoir traité toutes les demandes de service et leurs historiques, le script consolide les lignes générées dans une liste unique et écrit les données dans un fichier CSV nommé servicerequest_event_log.csv. Ce fichier est formaté et prêt à être téléversé dans un outil de process mining.

Configuration

Points d'accès API : Le script utilise principalement deux points d'accès API. L'authentification est gérée via api/jwt/login. Les données sont interrogées à partir de arsys/v1/entry/SRM:Request pour la liste des cas et arsys/v1/entry/[AUDIT_FORM_NAME] pour l'historique des événements.
Autorisations du Compte de Service : Un compte de service dédié avec 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 Plage de Dates : Le script est configuré pour filtrer les demandes de service en fonction de leur Submit Date. Il est recommandé d'extraire les données par lots gérables, par exemple 3 à 6 mois à la fois, pour garantir une performance fiable.
Mappage Statut-Activité : Le dictionnaire STATUS_ACTIVITY_MAP dans le script est le cœur de la logique de transformation. Il doit être soigneusement configuré pour refléter les statuts personnalisés de votre organisation et les mapper aux noms d'activités souhaités. Tout statut de votre workflow non présent dans le mappage sera ignoré.
Formulaire du Journal d'Audit : La capacité du script à capturer des activités détaillées dépend entièrement d'un journal d'audit interrogeable. Vous devez identifier le nom de formulaire correct dans votre environnement qui stocke l'historique des changements de statut pour les demandes de service et mettre à jour 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 dans l'appel API est défini pour récupérer 1000 enregistrements par requête afin d'équilibrer la performance et l'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()

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

BMC Helix ITSM Smart Reporting pour les demandes de service

Étapes

Configuration

a Exemple de requête config

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 BMC Helix

Étapes

Configuration

a Exemple de requête python

Prêt(e) à démarrer ?

Débloquez l'efficacité : Optimisez la gestion des demandes de service dès aujourd'hui

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

BMC Helix ITSM Smart Reporting pour les demandes de service

Étapes

Configuration

a Exemple de requête config

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 BMC Helix

Étapes

Configuration

a Exemple de requête python

Nous respectons votre vie privée

Prêt(e) à démarrer ?

Débloquez l'efficacité : Optimisez la gestion des demandes de service dès aujourd'hui