Votre modèle de données Purchase to Pay, phase de demande d’achat
Votre modèle de données Purchase to Pay, phase de demande d’achat
- Attributs recommandés pour une analyse détaillée
- Activités clés à suivre pour découvrir le processus
- Recommandations pour extraire les données de SAP S/4HANA
Purchase to Pay - Attributs des demandes d’achat
| Nom | Description | ||
|---|---|---|---|
| Heure de l’événement EventTime | Date et heure précises auxquelles une activité donnée s’est produite. | ||
| Description L’heure de l’événement est l’horodatage qui indique à quel moment une activité s’est produite. Ces données sont essentielles pour classer chronologiquement les événements d’un cas et constituent la base de tous les calculs de durée et de performance dans le Process Mining. Par exemple, la différence entre les événements « Requisition Submitted » et « Requisition Approved » détermine le temps de cycle d’approbation. Des horodatages précis sont indispensables pour analyser la performance du processus, identifier les retards et contrôler le respect des accords de niveau de service. Cet attribut permet de créer des Dashboards qui visualisent les temps de cycle, suivent les demandes d’achat bloquées et comparent les performances sur différentes périodes. Pourquoi c’est important Cet horodatage est essentiel pour classer les événements, calculer les temps de cycle et analyser la performance du processus ainsi que ses goulots d’étranglement. Où les obtenir Les horodatages proviennent généralement des en-têtes des documents de modification (CDHDR-UDATE, CDHDR-UTIME) ou des journaux d’événements du flux de travail. Exemples 2023-04-15T10:05:30Z2023-04-15T14:22:01Z2023-04-16T09:00:15Z | |||
| Identifiant de la demande d’achat PurchaseRequisitionId | Identifiant unique d’un document de demande d’achat. | ||
| Description L’identifiant de la demande d’achat est la clé primaire qui identifie de manière unique chaque demande de biens ou de services dans SAP S/4HANA. Il sert d’identifiant central du cas et relie toutes les activités et modifications associées à une demande donnée, de sa création à son état final, par exemple son approbation, son rejet ou sa conversion en commande d’achat. Dans le Process Mining, cet attribut est fondamental pour reconstituer le cycle de vie complet de chaque demande d’achat. En regroupant tous les événements associés sous un même identifiant de demande d’achat, les analystes peuvent mesurer précisément les temps de cycle, suivre les changements de statut et analyser les différents parcours possibles dans le processus d’approbation. Pourquoi c’est important Il s’agit de l’identifiant de cas essentiel qui relie toutes les étapes associées du processus et permet d’obtenir une vue complète et cohérente du cycle de vie de la demande d’achat. Où les obtenir Cet attribut correspond au numéro de demande d’achat, présent dans la table EBAN, champ BANFN. Exemples 100178901001789110017892 | |||
| Nom de l’activité ActivityName | Nom de l’activité métier survenue à un moment précis du processus de demande d’achat. | ||
| Description Le nom de l’activité décrit un événement ou une tâche précise survenu au cours du cycle de vie d’une demande d’achat. Ces activités sont dérivées des journaux système, tels que les documents de modification et les historiques des flux de travail, et représentent des jalons importants du processus, comme « Requisition Created », « Approval Step Started » ou « Purchase Order Created ». L’analyse de ces activités permet de visualiser le flux du processus, d’identifier les goulots d’étranglement et de mesurer le temps passé à chaque étape. Comprendre la séquence et la fréquence d’activités telles que « Requisition Amended » ou « Requisition Rejected » est essentiel pour repérer les inefficacités et les possibilités d’amélioration. Pourquoi c’est important Il définit les étapes du processus, constitue l’ossature de la cartographie du processus et permet d’analyser le flux, les variantes et les goulots d’étranglement. Où les obtenir Il s’agit d’un attribut dérivé, généralement construit à partir de l’interprétation des données des tables de documents de modification (CDHDR, CDPOS) et des journaux de flux de travail, par exemple SWWLOGHIST. Exemples Demande d’achat crééeÉtape d’approbation terminéeDemande d’achat approuvéeCommande d’achat créée | |||
| Identifiant de l’approbateur ApproverId | Identifiant de l’utilisateur qui a effectué une étape d’approbation ou de rejet. | ||
| Description L’identifiant de l’approbateur identifie précisément l’utilisateur qui a effectué une activité d’approbation ou de rejet. Il se distingue de l’identifiant utilisateur général, car il concerne uniquement les personnes qui prennent les décisions dans le flux de travail d’approbation. La collecte de cette information est essentielle pour analyser en détail le processus d’approbation. Cet attribut permet d’analyser les comportements d’approbation, par exemple en identifiant les responsables dont les délais d’approbation sont longs ou qui rejettent fréquemment des demandes. Il est fondamental pour les Dashboards consacrés aux temps de cycle des étapes d’approbation et à l’analyse des goulots d’étranglement des flux de travail, car il aide à repérer les personnes ou les rôles qui peuvent provoquer des retards. Pourquoi c’est important Identifie précisément le décideur d’une étape d’approbation et permet d’analyser en détail les temps de cycle et les goulots d’étranglement par personne ou par rôle. Où les obtenir Cette information est généralement extraite de tables SAP dédiées aux flux de travail, telles que SWW_WI2OBJ et SWWLOGHIST, qui associent les éléments de travail à l’utilisateur ayant terminé la tâche. Exemples MJOHNSONCWILLIAMSLBLACK | |||
| Identifiant utilisateur UserId | Identifiant de l’utilisateur qui a créé la demande d’achat ou effectué une activité donnée. | ||
| Description L’identifiant utilisateur désigne l’employé ou l’utilisateur système responsable d’un événement donné du cycle de vie de la demande d’achat. Il peut s’agir de la personne qui a créé la demande, du responsable qui l’a approuvée ou de l’agent qui l’a modifiée. Pour les étapes automatisées, il peut correspondre à l’identifiant d’un utilisateur système ou d’un utilisateur de traitement par lots. L’analyse par identifiant utilisateur aide à comprendre les comportements individuels, la répartition de la charge de travail et la performance. Elle est utile pour repérer les besoins de formation, identifier les collaborateurs les plus performants et garantir la responsabilité au sein du processus. Associée aux données de référence des utilisateurs, elle permet également d’analyser la performance des services. Pourquoi c’est important Permet d’analyser la performance des utilisateurs, la répartition de la charge de travail et la conformité du processus. Il est essentiel pour identifier les besoins de formation et les goulots d’étranglement liés aux ressources. Où les obtenir Pour le créateur, cette information se trouve dans EBAN-ERNAM. Pour les modifications ultérieures, elle se trouve dans CDHDR-USERNAME. Pour les approbations, elle figure dans les journaux du flux de travail. Exemples JSMITHRROEWF-BATCH | |||
| Montant de la demande d’achat RequisitionAmount | Valeur monétaire totale de la demande d’achat. | ||
| Description Le montant de la demande d’achat représente le coût total estimé des biens ou services demandés. Cette valeur joue souvent un rôle déterminant dans la complexité et la durée du flux de travail d’approbation, les demandes d’un montant élevé nécessitant généralement davantage de niveaux d’approbation. L’analyse de cet attribut permet de segmenter le processus selon la valeur. Elle peut aider à répondre à des questions telles que « Les demandes d’un montant élevé prennent-elles plus de temps à être approuvées ? » ou « Quel est le montant des demandes fréquemment rejetées ? ». Il s’agit d’une dimension essentielle pour comprendre l’impact financier des inefficacités du processus. Pourquoi c’est important Aide à segmenter le processus selon son impact financier, souvent corrélé à la complexité de l’approbation et au temps de cycle. Il est essentiel à l’analyse des processus par valeur. Où les obtenir La valeur totale se trouve dans la table EBAN, champ GFWERT. La valeur au niveau du poste se trouve dans EBAN-PREIS. Exemples 1500.0075000.50250.75 | |||
| Service Department | Service ou centre de coûts auquel les coûts de la demande d’achat sont imputés. | ||
| Description L’attribut Service, souvent représenté par le centre de coûts dans SAP, identifie l’unité métier responsable de l’achat demandé. Il s’agit d’une information financière et organisationnelle essentielle, affectée au niveau du poste de la demande d’achat. Dans le Process Mining, cet attribut est indispensable à l’analyse de la performance des services. Il permet de créer des Dashboards comparant des indicateurs clés tels que le temps de cycle, le taux de modification et le taux de rejet entre différents services. Cette analyse aide à repérer les services les plus performants, dont les pratiques pourraient être reprises ailleurs, ainsi que ceux qui nécessitent une formation ou un accompagnement supplémentaire. Pourquoi c’est important Permet de comparer la performance des unités métier, de mettre en évidence les écarts de temps de cycle ou de taux de rejet et d’identifier les bonnes pratiques ainsi que les possibilités d’amélioration. Où les obtenir Il s’agit du centre de coûts, généralement présent dans la table d’imputation comptable EBKN, champ KOSTL. Exemples FIN-1001IT-2005MKT-3010 | |||
| Statut de la demande d’achat RequisitionStatus | Statut actuel de traitement ou d’approbation de la demande d’achat. | ||
| Description Le statut de la demande d’achat indique son état actuel dans son cycle de vie. Dans SAP, cet état est souvent représenté par l’indicateur de libération, qui précise si la demande est bloquée, en cours d’approbation, partiellement approuvée ou entièrement approuvée. Le statut évolue au fur et à mesure que la demande progresse dans le flux de travail. Le suivi du statut dans le temps est fondamental pour comprendre le flux du processus. Il aide à identifier les points où les demandes restent bloquées et la durée de ces blocages. L’analyse des transitions entre les statuts offre une vision détaillée du processus d’approbation et de ses variantes. Pourquoi c’est important Indique l’état actuel d’une demande d’achat, ce qui est essentiel pour suivre sa progression, identifier les goulots d’étranglement et analyser le flux du processus. Où les obtenir Le statut de lancement est souvent déterminé par l’indicateur de lancement, présent dans la table EBAN, champ FRGZU. Exemples B1S | |||
| Type de demande d’achat RequisitionType | Code qui classe la demande d’achat, par exemple pour des articles standard, des services ou des dépenses d’investissement. | ||
| Description Le type de demande d’achat, également appelé type de document dans SAP, est un champ de configuration essentiel qui catégorise les demandes d’achat. Les différents types peuvent déclencher des flux de travail d’approbation différents, appliquer des paramètres de champs distincts et répondre à des besoins métier variés, comme les articles de stock standard, les services externes ou les achats d’immobilisations. L’analyse du processus par type de demande permet aux organisations de comprendre le traitement des différentes catégories de demandes. Elle permet de comparer la performance, les temps de cycle et les parcours d’approbation, afin de déterminer si certains types de demandes sont plus ou moins efficaces et d’adapter les améliorations du processus. Pourquoi c’est important Catégorise les demandes d’achat pour permettre une analyse comparative et déterminer si les différents types de demandes présentent des flux, des goulots d’étranglement ou des temps de cycle distincts. Où les obtenir Il s’agit du champ Type de document, présent dans la table EBAN, champ BSART. Exemples NBFORV | |||
| Date requise RequiredByDate | Date à laquelle le demandeur doit disposer des biens ou services demandés. | ||
| Description La date requise, ou date de livraison dans SAP, précise à quel moment les biens ou services du poste de demande d’achat sont nécessaires. Cette date est définie par le demandeur et sert de référence pour l’ensemble du processus d’approvisionnement. Cet attribut est essentiel pour calculer le KPI « Taux d’achèvement des demandes d’achat dans les délais ». En comparant la date requise à la date d’approbation finale ou de création de la commande d’achat, l’organisation peut mesurer sa capacité à respecter ses niveaux de service internes et ses besoins métier. L’analyse des demandes qui dépassent cette date peut mettre en évidence des retards systémiques dans le processus d’approvisionnement. Pourquoi c’est important Définit la date cible d’achèvement d’une demande et permet de mesurer le respect des délais de livraison ainsi que des niveaux de service internes. Où les obtenir Il s’agit de la date de livraison, présente au niveau du poste dans la table EBAN, champ LFDAT. Exemples 2023-11-152023-12-012024-01-20 | |||
| Dernière mise à jour des données LastDataUpdate | Horodatage indiquant à quel moment les données de cet enregistrement ont été actualisées pour la dernière fois depuis le système source. | ||
| Description Cet attribut enregistre la date et l’heure de l’extraction ou de la mise à jour la plus récente des données depuis le système source. Il s’agit d’une métadonnée essentielle pour évaluer la fraîcheur des données analysées. Les analystes et les utilisateurs métier s’appuient sur cet horodatage pour vérifier si les données du processus reflètent l’état opérationnel le plus récent. Dans toute analyse de processus, connaître l’actualité des données est indispensable pour prendre des décisions éclairées. Cet attribut aide à gérer les attentes des utilisateurs et garantit que les conclusions reposent sur des données suffisamment à jour pour l’analyse concernée. Pourquoi c’est important Indique la fraîcheur des données, essentielle pour accorder sa confiance à l’analyse et prendre des décisions métier au bon moment. Où les obtenir Cet horodatage est généré et ajouté pendant le processus d’extraction, de transformation et de chargement (ETL) des données. Exemples 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| Devise Currency | Code devise du montant de la demande d’achat. | ||
| Description Cet attribut précise la devise dans laquelle le montant de la demande d’achat est exprimé, par exemple USD, EUR ou JPY. Il fournit le contexte nécessaire à l’attribut Montant de la demande d’achat, notamment dans les organisations internationales qui utilisent plusieurs devises. Pour garantir l’exactitude des analyses et des rapports financiers, il est essentiel de tenir compte de la devise. Lors de l’agrégation ou de la comparaison des montants des demandes d’achat, toutes les valeurs doivent être converties dans une devise commune afin d’obtenir des résultats pertinents. Cet attribut est indispensable à ces conversions. Pourquoi c’est important Fournit le contexte nécessaire au montant de la demande d’achat et permet des analyses et comparaisons financières fiables dans les environnements multidevises. Où les obtenir Ce champ se trouve dans la table EBAN, champ WAERS. Exemples USDEURGBP | |||
| Est automatisée IsAutomated | Indicateur précisant si une activité a été effectuée par un utilisateur système plutôt que par une personne. | ||
| Description L’attribut « Is Automated » est un indicateur booléen qui prend la valeur true lorsqu’une activité est exécutée par un système ou un utilisateur de traitement par lots, par exemple « WF-BATCH » pour les actions du flux de travail. Il permet de distinguer les étapes manuelles des étapes automatisées du processus. Cet attribut est essentiel pour mesurer le niveau d’automatisation du processus de demande d’achat et calculer l’indicateur « Automated Approval Rate ». En filtrant les étapes automatisées ou manuelles, les analystes peuvent comparer leur efficacité et repérer de nouvelles possibilités d’automatisation afin de réduire les délais de traitement et les efforts manuels. Pourquoi c’est important Distingue les activités exécutées par des personnes de celles pilotées par le système. Cette distinction est essentielle pour mesurer le taux d’automatisation et repérer les tâches manuelles susceptibles d’être automatisées. Où les obtenir Il s’agit d’un attribut dérivé, généralement fondé sur une règle qui vérifie si le User ID associé à un événement appartient à une liste d’utilisateurs système ou batch connus. Exemples truefalse | |||
| Est une reprise IsRework | Indicateur précisant si une activité constitue une reprise, par exemple une modification effectuée après la soumission. | ||
| Description Is Rework est un indicateur booléen calculé qui identifie les activités correspondant à un travail répétitif ou sans valeur ajoutée. Dans ce processus, l’activité « Requisition Amended » qui intervient après la soumission de la demande pour approbation en est un exemple courant, car elle oblige à relancer le processus d’approbation. Cet attribut est essentiel pour quantifier les reprises dans le processus et mesurer leur impact sur les délais de cycle globaux. Le Dashboard Requisition Amendment and Rework Rate s’appuie sur cet indicateur pour mettre en évidence les inefficacités du processus. La réduction des reprises constitue souvent un objectif prioritaire des initiatives d’amélioration des processus, car elle se traduit directement par un gain de temps et d’effort. Pourquoi c’est important Signale les activités qui représentent un effort inutile ou répétitif, permettant de mesurer directement les reprises et leur impact sur l’efficacité du processus. Où les obtenir Il s’agit d’un attribut calculé. La logique signale généralement comme reprises les activités « Requisition Amended » qui surviennent après la première activité « Requisition Submitted For Approval ». Exemples truefalse | |||
| Heure de fin EndTime | Date et heure précises auxquelles une activité donnée a été terminée. | ||
| Description EndTime est l’horodatage qui indique la fin d’une activité. De nombreux événements générés par le système sont instantanés, ce qui signifie que StartTime est égal à EndTime. En revanche, les tâches humaines, comme les approbations, peuvent avoir une heure de début et une heure de fin distinctes. Cet horodatage marque l’achèvement du travail. La présence d’un EndTime distinct permet de mesurer plus précisément le temps de traitement actif par rapport au temps d’attente. Utilisé avec StartTime, il permet de calculer la métrique ProcessingTime. Ce niveau de détail améliore l’analyse de l’utilisation des ressources et de l’efficacité des tâches manuelles. Pourquoi c’est important Indique qu’une activité est terminée, ce qui permet de calculer le temps de traitement actif et d’obtenir une vision plus précise de la durée des tâches. Où les obtenir Cette information est dérivée des journaux du flux de travail, qui peuvent enregistrer à la fois la création d’un élément de travail (StartTime) et sa finalisation (EndTime). Exemples 2023-04-15T10:20:30Z2023-04-15T14:25:01Z2023-04-16T11:00:45Z | |||
| Motif du rejet RejectionReason | Motif fourni lorsqu’une demande d’achat est rejetée. | ||
| Description Le motif du rejet explique pourquoi un approbateur a décidé de rejeter une demande d’achat. Les motifs peuvent inclure un dépassement de budget, des informations incorrectes, le non-respect d’une politique ou le doublon d’une autre demande. Ces informations fournissent un contexte essentiel pour comprendre les échecs du processus. L’analyse des motifs de rejet aide à identifier les causes profondes des inefficacités et des reprises. Par exemple, si « Centre de coûts incorrect » revient fréquemment, cela peut indiquer un besoin de formation renforcée des utilisateurs ou de contrôles de validation dans le système. Cet attribut est au cœur du Dashboard d’analyse des rejets de demandes d’achat et joue un rôle essentiel dans l’amélioration ciblée du processus. Pourquoi c’est important Fournit la cause profonde des échecs du processus et permet de mettre en place des améliorations ciblées afin de réduire les reprises et d’augmenter le taux de traitement correct dès la première fois des demandes d’achat. Où les obtenir Il ne s’agit souvent pas d’un champ standard. Cette information peut être enregistrée dans les éléments du conteneur du flux de travail, dans le texte long associé à la demande ou dans des champs personnalisés. Exemples Budget dépasséFournisseur incorrectDemande en double | |||
| Niveau d’urgence UrgencyLevel | Classification du niveau d’urgence de la demande d’achat, susceptible d’influencer sa priorité de traitement. | ||
| Description Le niveau d’urgence indique la priorité de la demande d’achat. Bien qu’il n’existe pas toujours de champ standard dédié, certaines organisations utilisent des champs tels que le numéro de suivi de la demande pour enregistrer cette information. Les demandeurs peuvent ainsi signaler les besoins critiques nécessitant un traitement accéléré. L’analyse de l’impact de l’urgence est importante pour évaluer la capacité du processus à traiter en priorité les demandes critiques. Le Dashboard Urgency Level Impact Analysis utilise cet attribut pour comparer les délais de cycle et les taux d’approbation des demandes urgentes et standard, afin de déterminer si le traitement prioritaire fonctionne comme prévu. Pourquoi c’est important Permet d’analyser les écarts de performance du processus pour les demandes prioritaires et de vérifier que les éléments urgents sont effectivement traités plus rapidement. Où les obtenir Il n’existe pas de champ d’urgence standard. Certaines entreprises utilisent le numéro de suivi de la demande (EBAN-BEDAR) à cette fin. Il peut également s’agir d’un champ personnalisé. Exemples ÉlevéMoyenFaible | |||
| Nom de l’étape d’approbation ApprovalStepName | Le nom ou la description précise d’une étape d’approbation dans le flux de travail. | ||
| Description Le nom de l’étape d’approbation fournit une description lisible par l’utilisateur d’une étape précise du flux de travail d’approbation, comme « Manager Approval » ou « VP Finance Approval ». Il est plus descriptif qu’une activité générique telle que « Approval Step Completed ». Cet attribut est essentiel pour les Dashboards Temps de cycle des étapes d’approbation et Analyse des goulots d’étranglement. Il offre une vision détaillée du processus d’approbation et permet de repérer précisément les étapes qui provoquent les retards les plus importants et les points où le travail s’accumule. Ce niveau de détail est nécessaire pour mettre en place des mesures ciblées et simplifier la chaîne d’approbation. Pourquoi c’est important Fournit un niveau de détail précis sur les étapes d’approbation et permet d’identifier exactement les goulots d’étranglement du flux de travail d’approbation à plusieurs niveaux. Où les obtenir Cette information est dérivée de la description de la tâche du flux de travail, qui peut être obtenue en reliant le journal du flux de travail aux tables de définition des tâches, telles que T528T. Exemples Approbation du responsableApprobation du directeurApprobation du vice-président Finance | |||
| Numéro de commande d’achat PurchaseOrderNumber | Numéro de la commande d’achat créée à partir de la demande d’achat. | ||
| Description Le numéro de commande d’achat est l’identifiant du document d’achat officiel créé à partir d’une demande approuvée. La création d’une commande d’achat constitue souvent le résultat final et positif d’une demande d’achat : la demande est convertie en commande officielle auprès d’un fournisseur. Cet attribut est essentiel pour mesurer le KPI de délai entre la demande d’achat et la commande d’achat, ainsi que le taux global de conversion. Il relie le processus de demande d’achat au processus d’approvisionnement en aval et permet d’obtenir une vue de bout en bout du cycle Purchase-to-Pay. Pourquoi c’est important Relie la demande d’achat au document d’approvisionnement suivant et permet de mesurer le taux et le délai de conversion de la demande d’achat en commande d’achat. Où les obtenir Présent dans la table EBAN, champ EBELN, lorsqu’une commande d’achat a été créée à partir du poste de demande d’achat. Exemples 450001789045000178914500017892 | |||
| Système source SourceSystem | Identifie l’instance SAP S/4HANA précise à partir de laquelle les données ont été extraites. | ||
| Description L’attribut Système source indique le système d’origine dans lequel les données du processus ont été générées. Dans les organisations qui utilisent plusieurs instances SAP, par exemple des systèmes distincts pour le développement, l’assurance qualité et la production, ou des systèmes différents selon les régions, ce champ est essentiel à la gouvernance et à la contextualisation des données. Il garantit que les données provenant de sources différentes peuvent être distinguées, évite les agrégations incorrectes et permet une analyse propre à chaque système. Il s’agit d’un attribut obligatoire pour préserver la traçabilité des données et assurer le suivi de leur origine. Pourquoi c’est important Fournit le contexte essentiel sur l’origine et la gouvernance des données, notamment dans les environnements comportant plusieurs systèmes, et garantit leur traçabilité. Où les obtenir Il s’agit généralement de l’identifiant du système SAP (SID), qui peut être récupéré à partir des variables système ou des tables de configuration. Exemples S4PECCS4H_PROD_01 | |||
Purchase to Pay - Activités liées aux demandes d’achat
| Activité | Description | ||
|---|---|---|---|
| Commande d’achat créée | Indique qu’une commande d’achat a été générée à partir du poste de demande d’achat. Il s’agit d’un événement système explicite qui relie la demande d’achat au document d’approvisionnement créé ensuite. | ||
| Pourquoi c’est important Il s’agit d’une étape majeure et d’un résultat positif du processus de demande d’achat. Le délai entre l’approbation de la demande et la création de la commande d’achat constitue un KPI essentiel pour mesurer l’efficacité des achats. Où les obtenir Enregistré explicitement lors de la création d’un poste de commande d’achat. Le lien est stocké dans la table EKPO (poste de commande d’achat), qui contient le numéro de demande d’achat source (BANFN) et le numéro de poste (BNFPO). Collecte Reliez la table EKPO à la table EBAN à partir du numéro et du poste de la demande d’achat. La date de création du poste de commande marque l’événement. Type d’événement explicit | |||
| Demande d’achat approuvée | Marque l’approbation finale et complète de la demande d’achat, qui peut alors être convertie en commande d’achat. Cette étape est déduite lorsque le statut global de lancement atteint son état final approuvé. | ||
| Pourquoi c’est important Il s’agit d’une étape de réussite essentielle et d’un point de terminaison courant pour l’analyse du temps de cycle. Elle indique que la demande d’achat a passé tous les contrôles et que le service achats peut la traiter. Où les obtenir Déduit d’une modification du statut dans la table EBAN, notamment lorsque l’indicateur global de lancement (FRGZU) ou le statut de traitement (PROCSTAT) prend une valeur finale « Approved ». Collecte Identifiez l’horodatage auquel le dernier code de lancement est appliqué ou auquel le statut global de la demande d’achat passe à « Approved ». Type d’événement inferred | |||
| Demande d’achat clôturée | Indique que le poste de demande d’achat est considéré comme entièrement traité et qu’aucune autre commande d’achat ne peut être créée à partir de celui-ci. Ce statut est généralement défini automatiquement lorsque la totalité de la quantité a été commandée. | ||
| Pourquoi c’est important Cette activité représente l’achèvement final et réussi du cycle de vie du poste de demande d’achat. Elle confirme que le besoin métier a été entièrement traduit en commande d’approvisionnement. Où les obtenir Déduit de la table EBAN. Cet événement se produit lorsque l’indicateur « Closed » (EBAKZ) est renseigné, généralement lorsque la quantité commandée dans les commandes d’achat est égale à la quantité demandée. Collecte Identifiez, au moyen des documents de modification, l’événement au cours duquel l’indicateur « Closed » (EBAKZ) est renseigné dans la table EBAN. Type d’événement inferred | |||
| Demande d’achat créée | Indique la création initiale du document de demande d’achat dans le système. Cet événement est enregistré explicitement lorsqu’un utilisateur sauvegarde une nouvelle demande pour la première fois, avec son horodatage de création. | ||
| Pourquoi c’est important Cette activité constitue le point de départ principal de l’analyse du cycle de vie de la demande d’achat. Elle est indispensable pour mesurer le temps de cycle de bout en bout, depuis l’identification du besoin jusqu’à l’approbation finale ou la conversion en commande d’achat. Où les obtenir Il s’agit d’un événement explicite extrait de la table EBAN, à partir des champs de date de création (ERDAT) et d’heure de création (ERZEIT) associés au numéro de demande d’achat concerné (BANFN). Collecte Utilisez les champs d’horodatage de création (ERDAT, ERZEIT) de la table EBAN pour chaque demande d’achat (BANFN). Type d’événement explicit | |||
| Demande d’achat rejetée | Représente le rejet définitif de la demande d’achat par un approbateur, ce qui interrompt le processus. Cet événement est enregistré par une mise à jour de statut indiquant le rejet. | ||
| Pourquoi c’est important Cette activité constitue un point de terminaison critique en cas d’échec. L’analyse de la fréquence et des motifs de rejet, ainsi que des étapes concernées, aide à identifier les problèmes liés au respect des politiques, au budget ou à la qualité des demandes. Où les obtenir Déduit d’une modification du statut dans la table EBAN. Le statut de traitement (PROCSTAT) ou un indicateur de lancement prend une valeur indiquant explicitement « Rejected ». Collecte Identifiez, à partir des documents de modification, l’horodatage auquel le statut global dans EBAN passe à l’état « Rejected ». Type d’événement inferred | |||
| Étape d’approbation terminée | Se produit lorsqu’un approbateur effectue une action positive sur une demande d’achat et termine ainsi une étape du flux de travail d’approbation à plusieurs niveaux. Cet événement est déduit d’une modification du statut de libération de la demande. | ||
| Pourquoi c’est important Cette activité permet d’analyser en détail le flux de travail d’approbation et de mesurer le temps consacré à chaque étape. Elle aide à distinguer les approbateurs efficaces des goulots d’étranglement du processus. Où les obtenir Déduit des documents de modification (CDHDR/CDPOS) de la table EBAN. La modification du statut du code de lancement, par exemple dans le champ FRGZU, d’un état non lancé à un état lancé pour un code donné signale cet événement. Collecte Suivez les modifications des champs de statut de lancement dans EBAN pour chaque code de lancement défini dans la stratégie. Type d’événement inferred | |||
| Demande d’achat modifiée | Se produit lorsqu’un utilisateur modifie un champ important de la demande d’achat après sa création initiale, par exemple la quantité, le prix ou le matériel. Cette action est enregistrée explicitement dans le système de documents de modification de SAP. | ||
| Pourquoi c’est important Le suivi des modifications est essentiel pour identifier les boucles de reprise et leur impact sur les temps de cycle. Une fréquence élevée de modifications peut révéler des problèmes de qualité des données ou l’évolution des besoins, deux domaines importants pour améliorer le processus. Où les obtenir Enregistré explicitement dans les tables de documents de modification SAP (CDHDR et CDPOS) pour les changements apportés à la table EBAN. Chaque modification d’un champ suivi génère une entrée. Collecte Extrayez les événements de modification de CDHDR/CDPOS lorsque la classe d’objet est BANF pour les demandes d’achat. Type d’événement explicit | |||
| Demande d’achat retirée | Se produit lorsque le demandeur initial annule ou supprime la demande d’achat avant son traitement complet. Il s’agit généralement d’une action explicite qui active un indicateur de suppression sur le poste de la demande. | ||
| Pourquoi c’est important Le suivi des retraits aide à comprendre la volatilité de la demande et les raisons des annulations. Il s’agit d’un état terminal pour la demande d’achat, qui empêche tout traitement ultérieur. Où les obtenir Enregistré explicitement lorsque le champ d’indicateur de suppression (LOEKZ) de la table EBAN est renseigné pour un poste de demande d’achat. La modification est consignée dans CDHDR/CDPOS. Collecte Identifiez l’événement au cours duquel l’indicateur de suppression (LOEKZ) de la table EBAN prend la valeur « L ». Type d’événement explicit | |||
| Demande d’achat soumise pour approbation | Représente le moment où le demandeur soumet officiellement la demande d’achat, ce qui déclenche le flux de travail d’approbation. Ce moment est généralement déduit lorsque la stratégie de libération de la demande est déterminée et que son statut passe à « In Approval ». | ||
| Pourquoi c’est important Il s’agit d’une étape essentielle pour démarrer le calcul des KPI de temps de cycle d’approbation. L’analyse du délai entre la création et la soumission peut révéler des retards lors de la préparation de la demande d’achat. Où les obtenir Déduit des documents de modification (CDHDR/CDPOS) de la table EBAN, notamment lorsque les champs de stratégie de lancement, par exemple FRGST, sont renseignés ou lorsque le statut global (PROCSTAT) passe à un état indiquant une approbation en cours. Collecte Identifiez la première entrée du document de modification qui indique le début du flux de travail d’approbation ou le passage du statut à « In Approval ». Type d’événement inferred | |||
| Étape d’approbation démarrée | Indique qu’une demande d’achat attend l’intervention d’un approbateur ou d’un groupe d’approbation donné. Cet événement est déduit lorsque le statut de la demande indique qu’un code de lancement précis est en attente. | ||
| Pourquoi c’est important Cette activité est essentielle pour localiser les goulots d’étranglement dans la chaîne d’approbation. L’analyse de la durée de cet état permet d’identifier les demandes bloquées et les approbateurs surchargés. Où les obtenir Déduit des champs de statut de lancement de la table EBAN, par exemple FRGZU, et de la configuration sous-jacente de la stratégie de lancement. L’événement commence lorsqu’un code de lancement donné devient le prochain code à traiter. Collecte Déterminez à quel moment une demande d’achat entre dans un état où un code de libération précis est en attente d’approbation, à partir des journaux du flux de travail ou des champs de statut. Type d’événement inferred | |||
| Réinitialisation de l’approbation | Représente un événement au cours duquel l’ensemble du flux de travail d’approbation est réinitialisé, souvent à la suite d’une modification importante de la demande d’achat. Le processus d’approbation doit alors recommencer au premier niveau. | ||
| Pourquoi c’est important Cette activité met en évidence une reprise importante qui allonge fortement le temps de cycle. L’identification des causes des réinitialisations d’approbation est essentielle pour optimiser le processus et réduire les retards. Où les obtenir Déduit des documents de modification (CDHDR/CDPOS) de la table EBAN. Cet événement est détecté lorsque les champs de statut de lancement, tels que FRGKZ ou FRGZU, sont effacés après avoir été partiellement ou entièrement renseignés. Collecte Recherchez dans les journaux de modification un passage du statut de lancement d’un état lancé à un état non lancé. Type d’événement inferred | |||
| Source d’approvisionnement affectée | Représente l’action par laquelle un acheteur affecte un fournisseur, un contrat ou une fiche info précis à un poste de demande d’achat approuvé. Il s’agit d’une étape importante pour préparer la création de la commande d’achat. | ||
| Pourquoi c’est important Cette activité fait le lien entre l’approbation et la commande. La mesure du délai d’affectation d’une source permet d’identifier les retards liés à la charge de travail de l’acheteur et à l’efficacité du sourcing. Où les obtenir Déduit de la saisie d’une valeur dans les champs liés à la source d’approvisionnement de la table EBAN, tels que le fournisseur fixe (LIFNR), la fiche info (INFNR) ou le contrat (KONNR). Collecte Suivez, au moyen des documents de modification, le renseignement de champs tels que LIFNR, INFNR ou KONNR dans la table EBAN. Type d’événement inferred | |||
Guides d’extraction
Étapes
- Prérequis : vérifiez que vous disposez, dans SAP S/4HANA, d’un utilisateur possédant les autorisations nécessaires pour accéder aux vues CDS requises. Cela implique généralement des droits sur des objets tels que S_TABU_NAM et l’accès aux outils d’affichage des données.
- Identifiez la méthode d’accès au système : déterminez comment vous vous connecterez à la base de données SAP S/4HANA pour exécuter les requêtes SQL. Les outils courants sont SAP HANA Studio, l’IDE Eclipse avec ADT (ABAP Development Tools) ou des clients SQL tiers comme DBeaver, capables de se connecter via le client de base de données SAP HANA.
- Examinez la requête SQL : familiarisez-vous avec le script SQL fourni. Il utilise des Common Table Expressions (CTE) pour réunir les données de différentes activités, puis les regroupe afin de créer un Event Log unifié.
- Personnalisez les espaces réservés : repérez et remplacez les espaces réservés dans la requête. Vous devez définir la période d’extraction au format
[YYYY-MM-DD]et indiquer les codes société concernés ([Your Company Code]). - Exécutez la requête : lancez la requête SQL complète et personnalisée sur la base de données SAP S/4HANA. Selon le volume de données et la période sélectionnée, son exécution peut prendre un certain temps.
- Effectuez une première vérification des données : une fois la requête terminée, examinez les premières lignes du résultat. Vérifiez que toutes les colonnes, notamment PurchaseRequisitionId, ActivityName et EventTime, sont renseignées comme prévu et que les formats sont corrects.
- Vérifiez la transformation des données : la requête fournie génère des données dans un format prêt pour le Process Mining. Les fonctions
CASTetCONCATgarantissent la cohérence des types de données. Aucune transformation importante après l’exécution ne devrait être nécessaire. - Exportez l’Event Log : exportez l’ensemble du résultat depuis votre client SQL vers un fichier CSV. Vérifiez que l’encodage UTF-8 est sélectionné afin d’éviter les problèmes de caractères.
- Préparez le chargement : avant d’importer le fichier dans un outil de Process Mining, vérifiez que le fichier CSV contient les en-têtes corrects (
PurchaseRequisitionId,ActivityName,EventTime, etc.) et que le format de date et d’heure deEventTimeest cohérent et pris en charge par la plateforme cible. - Importez les données dans ProcessMind : chargez le fichier CSV final dans votre projet ProcessMind. Configurez le projet en associant
PurchaseRequisitionIdà Case ID,ActivityNameà Activity etEventTimeà Timestamp.
Configuration
- Vues CDS principales : l’extraction utilise principalement
I_PurchaseRequisitionAPI01pour les données de base des demandes,I_ChangeDocumentetI_ChangeDocumentItempour suivre les modifications et les mises à jour de statut, ainsi queI_PurchaseOrderItemAPI01pour établir le lien avec les commandes d’achat. - Autorisations : l’utilisateur qui exécute la requête doit disposer d’un accès en lecture aux vues CDS mentionnées ci-dessus. Consultez votre équipe de sécurité SAP pour connaître les rôles et autorisations nécessaires.
- Filtrage par période : il est essentiel d’appliquer un filtre sur la date de création de la demande (
CreationDate) afin de limiter le volume de données. Pour une première analyse, une période de 3 à 6 mois est recommandée. - Filtrage organisationnel : filtrez les données selon
CompanyCodeafin d’analyser la bonne entité. Vous pouvez également filtrer selonPurchaseRequisitionTypepour vous concentrer sur certains processus d’achat, par exemple les biens standard ou les services. - Configuration des documents de modification : l’enregistrement d’activités telles que « Requisition Amended » et des différentes étapes d’approbation dépend de l’activation de la journalisation des modifications pour les champs concernés dans votre système SAP. Si ces événements sont absents, vérifiez la configuration du système pour la table EBAN.
- Performance : dans les systèmes très volumineux comptant des millions de demandes, l’exécution de cette requête sur une longue période peut affecter les performances. Envisagez de l’exécuter en dehors des heures de pointe ou dans un environnement hors production contenant des données récemment actualisées.
a Exemple de requête sql
WITH REQUISITIONS AS (
SELECT
PurchaseRequisition,
PurchaseRequisitionType,
PurReqnDescription,
CreatedByUser,
CreationDate,
CAST(CONCAT(CreationDate, 'T', LPAD(CreationTime, 6, '0')) AS TIMESTAMP) AS CreationTimestamp,
SourceOfSupplyIsAssigned
FROM I_PurchaseRequisitionAPI01
WHERE CreationDate BETWEEN '[YYYY-MM-DD]' AND '[YYYY-MM-DD]'
AND CompanyCode IN ('[Your Company Code]')
),
CHANGE_DOCS AS (
SELECT
ObjectValue AS PurchaseRequisition,
UserName,
CAST(CONCAT(CreationDate, 'T', LPAD(CreationTime, 6, '0')) AS TIMESTAMP) AS ChangeTimestamp,
FieldName,
ValueNew,
ValueOld
FROM I_ChangeDocument AS H
JOIN I_ChangeDocumentItem AS I
ON H.ChangeDocument = I.ChangeDocument
WHERE H.Objectclass = 'EINKBELEG'
AND H.CreationDate BETWEEN '[YYYY-MM-DD]' AND '[YYYY-MM-DD]'
)
-- 1. Requisition Created
SELECT
R.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Created' AS "ActivityName",
R.CreationTimestamp AS "EventTime",
R.CreatedByUser AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM REQUISITIONS AS R
JOIN I_PurchaseRequisitionItemAPI01 AS I
ON R.PurchaseRequisition = I.PurchaseRequisition
UNION ALL
-- 2. Requisition Submitted For Approval & 5. Approval Step Started
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
CASE
WHEN C.ValueOld = ''
THEN 'Requisition Submitted For Approval'
ELSE 'Approval Step Started'
END AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
R.CreatedByUser AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R
ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I
ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueNew != ''
UNION ALL
-- 3. Requisition Amended
SELECT DISTINCT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Amended' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName IN ('MENGE', 'PREIS', 'MATNR', 'LIFNR', 'INFNR')
AND C.ChangeTimestamp > R.CreationTimestamp
UNION ALL
-- 4. Approval Reset
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Approval Reset' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueOld != '' AND C.ValueNew = ''
UNION ALL
-- 6. Approval Step Completed
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Approval Step Completed' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
NULL AS "UserId",
C.UserName AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueNew IN ('1', '2', '3', '4', '5', '6', '7') -- Adjust release codes as per your config
UNION ALL
-- 7. Requisition Approved
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Approved' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
NULL AS "UserId",
C.UserName AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGKE' AND C.ValueNew = '2' -- Final release indicator '2' is common for approved
UNION ALL
-- 8. Requisition Rejected
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Rejected' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
NULL AS "UserId",
C.UserName AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueNew = 'B' -- 'B' for Blocked/Rejected is a common setting
UNION ALL
-- 9. Requisition Withdrawn
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Withdrawn' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'LOEKZ' AND C.ValueNew = 'X'
UNION ALL
-- 10. Source of Supply Assigned
SELECT DISTINCT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Source of Supply Assigned' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName IN ('LIFNR', 'INFNR') AND C.ValueNew != ''
AND C.ChangeTimestamp > R.CreationTimestamp
UNION ALL
-- 11. Purchase Order Created
SELECT DISTINCT
I.PurchaseRequisition AS "PurchaseRequisitionId",
'Purchase Order Created' AS "ActivityName",
CAST(CONCAT(H.PurchaseOrderDate, 'T', LPAD(H.CreationTime, 6, '0')) AS TIMESTAMP) AS "EventTime",
H.CreatedByUser AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.OrderPriceUnit * I.OrderQuantity AS "RequisitionAmount",
'PO Created' AS "RequisitionStatus"
FROM I_PurchaseOrderItemAPI01 AS I
JOIN I_PurchaseOrderAPI01 AS H
ON I.PurchaseOrder = H.PurchaseOrder
JOIN REQUISITIONS AS R
ON I.PurchaseRequisition = R.PurchaseRequisition
WHERE I.PurchaseRequisition IS NOT NULL AND I.PurchaseRequisition != ''
UNION ALL
-- 12. Requisition Closed
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Closed' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'EBAKZ' AND C.ValueNew = 'X' Étapes
- Vérifiez que l’accès direct en lecture au schéma SAP HANA contenant EBAN et EBKN est disponible, puis identifiez les objets de documents de modification et de documents d’achat utilisés dans votre système pour les modifications des demandes, le traitement des libérations, l’affectation des sources, les références aux commandes d’achat et la clôture. Comme ces objets et ces champs peuvent varier selon la version et la configuration, remplacez chaque espace réservé entre crochets dans la requête par l’objet ou le champ correspondant de votre système.
- Dans SAP GUI, utilisez la transaction SE16H ou un outil d’administration de base de données approuvé pour examiner EBAN et EBKN, vérifier les champs clés des demandes et confirmer la disponibilité des champs de date, d’heure, d’utilisateur, de statut, de suppression, de libération, d’imputation et de référence aux documents d’achat. Utilisez SE11 ou le dictionnaire de données SAP pour vérifier les définitions des champs. N’exposez pas de données de production pendant les tests.
- Identifiez la source configurée des documents de modification pour les amendements des demandes et les changements d’approbation. La requête attend une source de modification normalisée nommée [Your requisition change document source], avec des champs pour le numéro de demande, le numéro de poste, le champ modifié, l’ancienne valeur, la nouvelle valeur, la date de modification, l’heure de modification et l’utilisateur. Associez cette source aux tables de documents de modification SAP ou à la vue CDS pertinente de votre système avant l’exécution.
- Identifiez la source configurée du flux de travail ou des libérations pour la soumission, la réinitialisation de l’approbation, le début de l’étape d’approbation, la fin de l’étape d’approbation, l’approbation finale et le rejet. La requête attend [Your requisition approval event source], avec une ligne par transition de statut ou de libération et des champs pour le numéro de demande, le numéro de poste, le type d’événement, le code de libération ou le groupe d’approbation, l’approbateur, la date de l’événement, l’heure de l’événement et le statut. Associez cette source aux données persistantes des libérations ou du flux de travail utilisées par votre configuration S/4HANA.
- Identifiez les sources de l’affectation des sources, de la référence aux commandes d’achat et de la clôture. La requête attend [Your requisition source assignment source], [Your requisition purchase order reference source] et [Your requisition closure source]. Associez ces espaces réservés aux tables ou vues approuvées de votre système. La création d’une commande d’achat doit être représentée par une référence explicite entre le poste de commande et le poste de demande d’achat, et non déduite d’une activité d’achat sans lien.
- Définissez la fenêtre d’extraction à l’aide de [Start date] et [End date]. Une période de trois à six mois est recommandée pour la première exécution. N’utilisez une période plus large qu’après avoir validé les performances de la base de données et le volume d’événements. La requête filtre les dates de création et d’événement, tout en conservant l’identifiant de la demande comme identifiant du cas.
- Exécutez la requête dans un client SQL approuvé connecté à SAP HANA. Remplacez uniquement les informations de connexion situées en dehors de la requête, les paramètres de date, les filtres propres à l’entreprise et les espaces réservés de sources et de champs explicitement documentés. Conservez exactement les noms de colonnes de sortie suivants : PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount et RequisitionStatus.
- Examinez les événements en double, la précision des horodatages, la gestion des fuseaux horaires et la granularité au niveau du poste ou du document. La requête produit des identifiants de cas au niveau du document et inclut le contexte du poste en interne. Si plusieurs postes produisent la même activité au même horodatage, conservez des lignes distinctes, sauf si votre conception ProcessMind exige explicitement une déduplication.
- Vérifiez que chaque activité requise apparaît comme valeur de ActivityName, que EventTime est renseigné et chronologiquement plausible et que l’identifiant de cas requis n’est pas nul. Rapprochez les volumes avec les rapports SAP ou les extractions opérationnelles approuvées pour la même période.
- Exportez le résultat au format CSV UTF-8 ou dans un autre format tabulaire pris en charge par ProcessMind. Incluez une ligne d’en-tête, conservez des horodatages compatibles ISO, représentez les valeurs nulles par des cellules vides et importez le fichier en utilisant PurchaseRequisitionId comme identifiant du cas, ActivityName comme colonne d’activité et EventTime comme colonne d’horodatage.
Configuration
- Identifiant du cas : utilisez le numéro de document de la demande d’achat provenant d’EBAN, représenté par PurchaseRequisitionId. Si le processus est configuré au niveau du poste, utilisez plutôt une clé composite documentée, telle que le numéro de demande et le numéro de poste, puis appliquez cette même clé à chaque événement.
- Source principale : EBAN est utilisée pour les données des postes de demande d’achat. EBKN est utilisée pour l’imputation et l’enrichissement avec le service ou le centre de coûts. Vérifiez les noms et les types de données exacts des champs dans le dictionnaire de données SAP avant l’exécution.
- Sources des événements : la requête utilise volontairement des espaces réservés précis pour les sources de modification, d’approbation, d’affectation des sources, de référence aux commandes d’achat et de clôture, car ces sources dépendent de la version de S/4HANA, de la conception du flux de travail, de la procédure de libération, des fonctions métier activées et des extensions propres au client.
- Période : commencez par trois à six mois. Utilisez, lorsque cela est possible, une période bornée sur des champs de date indexés ou permettant l’élagage des partitions. Pour les chargements incrémentiels, faites suffisamment chevaucher les fenêtres d’extraction afin de capturer les modifications reçues tardivement, puis dédupliquez à l’aide du cas, de l’activité, de l’horodatage, du poste et de la clé de l’événement source.
- Filtres métier : configurez [Company code filter], [Document type filter], [Purchasing group filter] et [Plant filter] uniquement lorsque ces champs sont disponibles et que leur signification métier est confirmée. Évitez de filtrer sur le statut lorsque l’objectif est de capturer l’intégralité du cycle de vie.
- Association des statuts : configurez les valeurs correspondant à In Approval, final approved, rejected, reset, pending release code et closed selon la stratégie de libération ou la configuration du flux de travail du système cible. Ne partez pas du principe qu’un même code de statut est universel dans tous les clients SAP.
- Association des amendements : incluez les modifications de quantité, de prix, de matériel, de date de livraison, d’imputation et des autres champs que votre processus définit comme essentiels. La requête contient des prédicats explicites pour les champs clés indiqués et exige que la source expose le nom du champ modifié.
- Gestion des horodatages : combinez la date et l’heure de l’événement dans le fuseau horaire de la base de données, puis documentez toute conversion en UTC. Si une source ne stocke qu’une date, utilisez minuit uniquement lorsqu’aucun horodatage plus précis n’existe et consignez cette limite.
- Performances : limitez l’extraction initiale par date et par périmètre métier, sélectionnez uniquement les colonnes nécessaires, évitez les jointures sans restriction avec de volumineux historiques de modifications ou de flux de travail et examinez le plan d’exécution HANA. Matérialisez ou préparez les sources d’événements normalisées si des extractions répétées sont nécessaires.
- Autorisations et prérequis : obtenez les autorisations de lecture pour EBAN, EBKN, les sources configurées de modification et de flux de travail, les données d’affectation des sources, les données de référence des commandes d’achat et les données de clôture. Vérifiez que l’accès direct à la base de données est approuvé, que les fonctionnalités d’achat et de flux de travail concernées sont actives et que toute licence de base de données SAP HANA ou tout outil d’administration nécessaire est disponible.
- Sécurité : appliquez le principe du moindre privilège, protégez les identifiants des utilisateurs et des approbateurs et respectez les règles de votre organisation concernant l’extraction des informations d’achat et des données financières.
a Exemple de requête sql
WITH
base_items AS (
SELECT
eban.[Purchase requisition number field] AS PurchaseRequisitionId,
eban.[Purchase requisition item field] AS RequisitionItem,
eban.[Creation date field] AS CreationDate,
eban.[Creation time field] AS CreationTime,
eban.[Created by field] AS CreatedBy,
eban.[Requisition type field] AS RequisitionType,
eban.[Company code field] AS CompanyCode,
eban.[Plant field] AS Plant,
eban.[Purchasing group field] AS PurchasingGroup,
eban.[Quantity field] AS Quantity,
eban.[Net price field] AS NetPrice,
eban.[Currency field] AS Currency,
eban.[Material field] AS Material,
eban.[Deletion indicator field] AS DeletionIndicator,
eban.[Overall release status field] AS OverallReleaseStatus,
eban.[Item processing status field] AS ItemProcessingStatus,
ebkn.[Cost center field] AS CostCenter,
ebkn.[Department field] AS Department,
CAST(eban.[Quantity field] * eban.[Net price field] AS DECIMAL(19,4)) AS RequisitionAmount
FROM [Your SAP schema].EBAN eban
LEFT JOIN [Your SAP schema].EBKN ebkn
ON ebkn.[Purchase requisition number field] = eban.[Purchase requisition number field]
AND ebkn.[Purchase requisition item field] = eban.[Purchase requisition item field]
WHERE eban.[Creation date field] BETWEEN '[Start date]' AND '[End date]'
AND ('[Company code filter]' = '' OR eban.[Company code field] = '[Company code filter]')
AND ('[Document type filter]' = '' OR eban.[Requisition type field] = '[Document type filter]')
AND ('[Purchasing group filter]' = '' OR eban.[Purchasing group field] = '[Purchasing group filter]')
AND ('[Plant filter]' = '' OR eban.[Plant field] = '[Plant filter]')
),
created_events AS (
SELECT
PurchaseRequisitionId,
'Requisition Created' AS ActivityName,
TO_TIMESTAMP(CAST(CreationDate AS NVARCHAR(8)) || LPAD(COALESCE(CAST(CreationTime AS NVARCHAR(6)), '000000'), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CreatedBy AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
RequisitionType,
Department,
RequisitionAmount,
'Created' AS RequisitionStatus
FROM base_items
),
submitted_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Submitted For Approval' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
a.[Requester or submitter field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'SUBMITTED'
OR a.[Status field] = 'In Approval'
),
amended_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Amended' AS ActivityName,
TO_TIMESTAMP(CAST(c.[Change date field] AS NVARCHAR(8)) || LPAD(CAST(c.[Change time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
c.[Change user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
'Amended' AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition change document source] c
ON c.[Purchase requisition number field] = b.PurchaseRequisitionId
AND c.[Purchase requisition item field] = b.RequisitionItem
WHERE c.[Changed field field] IN ('QUANTITY', 'PRICE', 'MATERIAL', 'DELIVERY_DATE', 'ACCOUNT_ASSIGNMENT')
),
reset_events AS (
SELECT
b.PurchaseRequisitionId,
'Approval Reset' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
a.[Event user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'RESET'
OR a.[Status field] = 'Approval Reset'
),
step_started_events AS (
SELECT
b.PurchaseRequisitionId,
'Approval Step Started' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserId,
a.[Approver or approval group field] AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'STEP_STARTED'
OR a.[Status field] = 'Pending Release'
),
step_completed_events AS (
SELECT
b.PurchaseRequisitionId,
'Approval Step Completed' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserId,
a.[Approver or approval group field] AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'STEP_COMPLETED'
OR a.[Status field] = 'Step Approved'
),
approved_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Approved' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserId,
a.[Approver or approval group field] AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'FINAL_APPROVED'
OR a.[Status field] = 'Approved'
),
rejected_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Rejected' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserId,
a.[Approver or approval group field] AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'REJECTED'
OR a.[Status field] = 'Rejected'
),
withdrawn_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Withdrawn' AS ActivityName,
TO_TIMESTAMP(CAST(c.[Change date field] AS NVARCHAR(8)) || LPAD(CAST(c.[Change time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
c.[Change user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
'Withdrawn' AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition change document source] c
ON c.[Purchase requisition number field] = b.PurchaseRequisitionId
AND c.[Purchase requisition item field] = b.RequisitionItem
WHERE c.[Changed field field] = 'DELETION_INDICATOR'
AND c.[New value field] IS NOT NULL
AND c.[New value field] <> ''
),
source_assigned_events AS (
SELECT
b.PurchaseRequisitionId,
'Source of Supply Assigned' AS ActivityName,
TO_TIMESTAMP(CAST(s.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(s.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
s.[Event user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
'Source Assigned' AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition source assignment source] s
ON s.[Purchase requisition number field] = b.PurchaseRequisitionId
AND s.[Purchase requisition item field] = b.RequisitionItem
WHERE s.[Source identifier field] IS NOT NULL
AND s.[Source identifier field] <> ''
),
purchase_order_events AS (
SELECT
b.PurchaseRequisitionId,
'Purchase Order Created' AS ActivityName,
TO_TIMESTAMP(CAST(p.[Purchase order creation date field] AS NVARCHAR(8)) || LPAD(CAST(p.[Purchase order creation time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
p.[Purchase order creator field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
'Purchase Order Created' AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition purchase order reference source] p
ON p.[Purchase requisition number field] = b.PurchaseRequisitionId
AND p.[Purchase requisition item field] = b.RequisitionItem
WHERE p.[Purchase order number field] IS NOT NULL
AND p.[Purchase order number field] <> ''
),
closed_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Closed' AS ActivityName,
TO_TIMESTAMP(CAST(cl.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(cl.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
cl.[Event user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
cl.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition closure source] cl
ON cl.[Purchase requisition number field] = b.PurchaseRequisitionId
AND cl.[Purchase requisition item field] = b.RequisitionItem
WHERE cl.[Event type field] = 'CLOSED'
OR cl.[Status field] = 'Closed'
)
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM created_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM submitted_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM amended_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM reset_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM step_started_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM step_completed_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM approved_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM rejected_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM withdrawn_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM source_assigned_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM purchase_order_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM closed_events
ORDER BY PurchaseRequisitionId, EventTime, ActivityName; Prêt à commencer ?
Utilisez ce modèle pour préparer vos données en toute confiance et tirer le meilleur parti du Process Mining dans votre processus Purchase to Pay, phase de demande d’achat. Commencez dès aujourd’hui à optimiser votre efficacité !
Finissez-en avec les retards des demandes d’achat P2P : optimisez votre flux de travail dès maintenant !
Optimisez vos processus, réduisez les délais et diminuez le temps de cycle de 30 %.
Aucune carte bancaire requise, configuration en 5 minutes.