Votre template de données Purchase to Pay, commande d’achat
Votre template de données Purchase to Pay, commande d’achat
- Attributs de données recommandés
- Activités clés du processus
- Étapes d’extraction des données Coupa
Purchase to Pay - Attributs des commandes d’achat
| Nom | Description | ||
|---|---|---|---|
|
Activité
ActivityName
|
Nom de l’événement ou de la tâche précise survenue à un moment donné du cycle de vie du bon de commande. | ||
|
Description
Le nom de l’activité décrit une étape unique du processus purchase-to-pay, comme « Bon de commande approuvé » ou « Réception des marchandises enregistrée ». Cette séquence d’activités constitue le flux du processus pour chaque bon de commande. Cet attribut est fondamental pour le Process Mining, car il sert à construire la carte du processus, à découvrir les variantes du processus et à analyser la fréquence ainsi que l’ordre des événements. Il aide à identifier les goulots d’étranglement, les cycles de reprise et les écarts par rapport au flux standard. Par exemple, l’analyse de la séquence des activités « Bon de commande modifié » peut révéler des inefficacités dans l’exactitude des commandes.
Pourquoi c’est important
Il définit les étapes du processus, ce qui permet de visualiser le flux du processus et d’identifier les goulots d’étranglement, les reprises et les écarts.
Où les obtenir
Dérivé des journaux d’événements, des pistes d’audit ou des enregistrements de changement de statut associés aux objets Bon de commande dans Coupa.
Exemples
Demande d’achat approuvéeBon de commande soumisRéception des marchandises enregistréeFacture reçue pour le bon de commande
|
|||
|
Bon de commande
PurchaseOrderNumber
|
Identifiant unique d’un bon de commande, utilisé comme identifiant principal du dossier dans le processus. | ||
|
Description
Le numéro du bon de commande est l’identifiant central du dossier qui relie toutes les activités, depuis la demande initiale jusqu’à la confirmation finale de la réception des biens ou des services. Chaque numéro de bon de commande unique représente une instance du processus d’approvisionnement. Dans une analyse de Process Mining, cet attribut est essentiel pour suivre le parcours complet de chaque achat. Il permet aux analystes de visualiser les cartes de processus, d’identifier les variantes et de calculer des KPI au niveau du dossier, comme le temps de cycle total d’une commande. Tous les événements et les données associées sont regroupés sous cet identifiant afin de fournir une vision cohérente du processus.
Pourquoi c’est important
Il est indispensable pour suivre le cycle de vie complet de chaque achat et reconstituer les instances individuelles du processus à des fins d’analyse détaillée.
Où les obtenir
Il s’agit d’un champ de clé primaire standard de l’objet Bon de commande dans Coupa.
Exemples
PO-2023-00123PO-2023-00456PO-2023-00789
|
|||
|
Heure de début
EventTime
|
Horodatage exact indiquant le moment où une activité ou un événement s’est produit. | ||
|
Description
L’heure de l’événement enregistre la date et l’heure auxquelles une activité précise a été exécutée. Chaque activité du processus possède un horodatage correspondant qui marque sa survenue. Cet attribut est essentiel pour toutes les analyses temporelles du Process Mining. Il sert à calculer les temps de cycle entre les activités, à mesurer la durée du processus et à identifier les retards. Par exemple, la différence entre les horodatages « Purchase Order Drafted » et « Purchase Order Approved » permet de calculer le KPI de temps de cycle d’approbation du bon de commande.
Pourquoi c’est important
Il fournit le contexte temporel de chaque événement, indispensable pour calculer les temps de cycle, analyser les performances et détecter les goulots d’étranglement.
Où les obtenir
Situé dans les journaux d’événements ou les pistes d’audit de Coupa, généralement associé à chaque changement de statut ou à chaque action effectuée sur un bon de commande.
Exemples
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z
|
|||
|
Dernière mise à jour des données
LastDataUpdate
|
Horodatage indiquant la dernière actualisation des données relatives à ce processus. | ||
|
Description
Cet attribut indique la date de la dernière mise à jour du jeu de données à partir du système source. Il s’agit d’un champ de métadonnées qui s’applique à l’ensemble du jeu de données, et non à des événements individuels. Dans tout Dashboard analytique, cet horodatage est essentiel pour permettre aux utilisateurs de connaître l’actualité des données consultées. Il confirme que les analyses reposent sur des informations récentes et aide à gérer les attentes concernant leur mise à jour. Il est généralement affiché de manière visible dans les Dashboards.
Pourquoi c’est important
Il informe les utilisateurs de l’actualité des données et leur permet de comprendre dans quelle mesure l’analyse du processus et les KPI sont à jour.
Où les obtenir
Cet horodatage est généré et enregistré par le pipeline d’extraction et de chargement des données (ETL) lors de son exécution.
Exemples
2023-11-01T05:00:00Z
|
|||
|
Système source
SourceSystem
|
Système à partir duquel les données du processus ont été extraites. | ||
|
Description
Cet attribut identifie le système d’information d’origine dans lequel les données de l’événement ont été enregistrées. Pour ce processus, sa valeur serait systématiquement « Coupa ». Dans les environnements d’entreprise où les données peuvent provenir de plusieurs systèmes, par exemple Coupa pour les achats et un autre ERP pour la facturation, cet attribut permet de différencier les sources de données. Il garantit la traçabilité de la provenance des données et peut servir à filtrer l’analyse selon la vision du processus propre à un système donné.
Pourquoi c’est important
Il fournit un contexte essentiel sur l’origine des données, garantit leur traçabilité et permet une gouvernance appropriée, notamment dans les environnements composés de plusieurs systèmes.
Où les obtenir
Il s’agit d’une valeur statique généralement ajoutée lors de l’extraction et de la transformation des données afin d’identifier le jeu de données.
Exemples
Coupa
|
|||
|
Catégorie d'achat
PurchaseCategory
|
Classification des biens ou services achetés, par exemple le matériel informatique ou les services professionnels. | ||
|
Description
La catégorie d'achat, également appelée Commodity ou Material Group, est une classification utilisée pour regrouper des achats de nature similaire. Ces données structurées permettent d'analyser systématiquement les dépenses et les processus d'achat. Dans le Process Mining, cet attribut constitue une dimension particulièrement utile pour filtrer et segmenter les données. Le Dashboard « Spend Analysis by Purchase Category » s'appuie sur lui pour détailler les habitudes de dépenses. Il peut également révéler si certaines catégories, par exemple les services complexes, présentent des temps de cycle plus longs ou des taux de modification plus élevés que d'autres, comme les fournitures de bureau standard.
Pourquoi c’est important
Permet d'analyser les dépenses et les processus par catégorie, d'identifier les tendances d'achat, de négocier avec les fournisseurs et d'adapter les contrôles du processus.
Où les obtenir
Généralement présent au niveau de la ligne du Purchase Order dans Coupa, souvent associé à un code Commodity ou à un catalogue d'achat.
Exemples
Matériel informatiqueFournitures de bureauServices professionnelsSupports marketing
|
|||
|
Montant total de la commande
TotalOrderAmount
|
Valeur monétaire totale du Purchase Order. | ||
|
Description
Cet attribut représente le coût total de l'ensemble des biens et services indiqués dans le Purchase Order, exprimé dans une devise donnée. Il s'agit d'un attribut au niveau du dossier, qui s'applique à l'ensemble de la commande. Ces données financières sont essentielles à l'analyse des dépenses et à la priorisation des initiatives d'amélioration des processus. Les commandes de montant élevé peuvent nécessiter un contrôle renforcé ou des circuits d'approbation différents. Elles sont utilisées directement dans le Dashboard « Spend Analysis by Purchase Category » et entrent dans le calcul du KPI « Spend by Non-Preferred Vendor Ratio ».
Pourquoi c’est important
Fournit le contexte financier de chaque achat, permettant d'analyser les dépenses, de prioriser les commandes de montant élevé et d'évaluer l'impact financier.
Où les obtenir
Disponible dans l'en-tête du Purchase Order dans Coupa, généralement sous l'intitulé « Total » ou « Grand Total ».
Exemples
1500.00250.7512500.50
|
|||
|
Nom du fournisseur
VendorName
|
Nom du fournisseur auprès duquel les biens ou services sont achetés. | ||
|
Description
Le nom du fournisseur identifie la partie externe qui fournit les articles indiqués sur le Purchase Order. Ces informations sont fondamentales pour l'analyse des achats. L'analyse de la performance des processus par fournisseur est essentielle à la gestion de la relation fournisseurs. Elle permet d'évaluer la « Supplier Lead Time Performance », d'identifier les retards dans le « Goods Receipt Process Delays » et d'évaluer la qualité des fournisseurs au moyen du « Goods Return Rate ». Cet attribut est également essentiel au calcul du KPI « Spend by Non-Preferred Vendor Ratio ».
Pourquoi c’est important
Permet d'analyser la performance des fournisseurs, d'optimiser leur sélection, de négocier de meilleures conditions et d'identifier les fournisseurs les plus ou les moins performants.
Où les obtenir
Champ standard de l'en-tête du Purchase Order dans Coupa, associé aux données de référence des fournisseurs.
Exemples
Global Office SuppliesTech Solutions Inc.Advanced Industrial PartsCreative Marketing Agency
|
|||
|
Service
Department
|
Service métier ou centre de coûts auquel le bon de commande est imputé. | ||
|
Description
L’attribut Service précise l’unité organisationnelle qui a initié l’achat ou qui en supportera le coût. Il est souvent associé au demandeur ou aux informations du centre de coûts figurant sur les lignes du bon de commande. Cette dimension est essentielle pour segmenter l’analyse des processus et des KPI. Elle permet aux responsables de comparer l’efficacité, la conformité et les habitudes de dépenses entre les différentes composantes de l’organisation. Par exemple, le Dashboard « Spend Analysis by Purchase Category » utilise l’attribut Service pour montrer comment les différentes unités métier dépensent leur budget.
Pourquoi c’est important
Il permet de filtrer et de comparer l’analyse des processus et des dépenses entre différentes unités métier, afin de révéler les écarts d’efficacité et de conformité.
Où les obtenir
Disponible dans l'en-tête du Purchase Order ou sur les lignes, dans Coupa, souvent associé à un Cost Center ou à une unité organisationnelle.
Exemples
MarketingTechnologies de l'informationOpérationsFinance
|
|||
|
Utilisateur
User
|
Identifiant ou nom de l’utilisateur ayant effectué l’activité, par exemple un approbateur ou un demandeur. | ||
|
Description
Cet attribut identifie la personne responsable de l’exécution d’un événement donné dans le processus. Il peut s’agir de la personne qui a créé la commande, du responsable qui l’a approuvée ou de l’agent qui a enregistré la réception des marchandises. L’analyse des performances par utilisateur aide à identifier les besoins de formation, les personnes les plus performantes et la répartition de la charge de travail. Par exemple, le Dashboard « Performance du temps de cycle d’approbation des bons de commande » utilise cet attribut pour ventiler les délais d’approbation par approbateur et mettre en évidence les personnes susceptibles de constituer un goulot d’étranglement.
Pourquoi c’est important
Il permet d’analyser les performances du processus par personne ou par rôle, afin d’identifier les goulots d’étranglement, les besoins de formation et les problèmes d’affectation des ressources.
Où les obtenir
Associé à chaque événement de la piste d’audit ou des journaux d’historique du bon de commande dans Coupa. Des champs tels que « Created By », « Approved By » ou « Updated By » constituent des sources courantes.
Exemples
j.doea.smithm.jones
|
|||
|
Approbation dès la première soumission
IsFirstPassApproval
|
Indicateur calculé qui prend la valeur true si le PO a été approuvé sans modification après sa création. | ||
|
Description
Cet indicateur booléen prend la valeur true si le parcours d'un Purchase Order entre « Purchase Order Drafted » et « Purchase Order Approved » ne contient aucune activité « Purchase Order Changed » ni « Purchase Order Rejected » intermédiaire. Cet attribut mesure directement le KPI « First-Pass PO Approval Rate ». Un taux élevé indique un traitement initial efficace et précis. L'analyse des dossiers pour lesquels cet indicateur prend la valeur false peut révéler les causes des reprises et contribuer à améliorer la qualité des données saisies en amont dans les Purchase Orders.
Pourquoi c’est important
Mesure directement l'efficacité du processus initial de création et d'approbation, en mettant en évidence le volume de commandes traitées sans reprise.
Où les obtenir
Calculé lors de la transformation des données en analysant la séquence des événements pour chaque PurchaseOrderNumber.
Exemples
truefalse
|
|||
|
Date de livraison demandée
RequestedDeliveryDate
|
Date à laquelle le demandeur souhaite recevoir les biens ou services. | ||
|
Description
Cet attribut correspond à la date de livraison cible indiquée par l'utilisateur métier lors du processus de demande. Il représente la date à laquelle l'entreprise souhaite que la commande soit exécutée. Cette date constitue une référence essentielle pour mesurer la performance des fournisseurs et des équipes internes. Elle sert directement au calcul du KPI « Supplier Delivery Date Adherence », en la comparant à la date réelle « Goods Receipt Posted ». Le Dashboard « Delivery Date Variance and Returns » visualise les écarts entre la date demandée et la date de livraison réelle, afin de mieux gérer les attentes et d'améliorer les prévisions.
Pourquoi c’est important
Sert de référence de performance pour mesurer le respect des délais de livraison par les fournisseurs et l'efficacité du processus interne de réception.
Où les obtenir
Champ standard de la ligne du Purchase Order dans Coupa.
Exemples
2023-11-152023-12-012024-01-10
|
|||
|
Devise
Currency
|
Code de la devise utilisée pour les montants du Purchase Order. | ||
|
Description
Cet attribut indique la devise, par exemple USD, EUR ou GBP, dans laquelle le montant total de la commande est exprimé. Il est essentiel pour interpréter correctement les données financières dans une organisation internationale. Pour les entreprises multinationales, analyser les dépenses sans tenir compte de la devise peut conduire à des conclusions trompeuses. Cet attribut permet d'effectuer les conversions nécessaires et de garantir la cohérence des rapports financiers dans les Dashboards, afin de comparer les montants sur une base homogène.
Pourquoi c’est important
Garantit la précision des analyses et des rapports financiers dans un contexte multinational en fournissant les informations nécessaires à la conversion des devises.
Où les obtenir
Champ standard de l'en-tête du Purchase Order dans Coupa.
Exemples
USDEURGBPJPY
|
|||
|
Fournisseur privilégié
IsPreferredVendor
|
Indicateur booléen précisant si l'achat a été effectué auprès d'un fournisseur privilégié ou stratégique. | ||
|
Description
Cet indicateur précise si le fournisseur du Purchase Order figure sur une liste préapprouvée de fournisseurs stratégiques. Cette information est généralement déterminée en comparant le nom ou l'identifiant du fournisseur avec une liste de référence des fournisseurs privilégiés. Cet attribut est essentiel aux initiatives de sourcing stratégique et de gestion des dépenses. Il sert à calculer le KPI « Spend by Non-Preferred Vendor Ratio », qui aide les organisations à surveiller et à limiter les achats hors processus, ainsi qu'à concentrer les dépenses auprès de partenaires clés pour bénéficier de remises sur volume et de meilleures conditions.
Pourquoi c’est important
Aide à suivre la conformité aux politiques d'achat et les objectifs de sourcing stratégique en comparant les dépenses réalisées auprès de fournisseurs privilégiés et non privilégiés.
Où les obtenir
Il ne s'agit souvent pas d'un champ standard dans Coupa. Il est calculé en comparant l'identifiant du fournisseur du PO à une liste externe de fournisseurs privilégiés.
Exemples
truefalse
|
|||
|
Lieu de réception
ReceivingLocation
|
Lieu physique, tel qu'un entrepôt ou un bureau, où les biens doivent être livrés. | ||
|
Description
Le lieu de réception indique la destination des biens commandés dans le Purchase Order. Il peut s'agir d'un entrepôt, d'un site de production ou d'une adresse de bureau précise. Cet attribut sert à analyser la performance logistique et la performance de réception sur différents sites. Le Dashboard « Goods Receipt Process Delays » peut être filtré selon cet attribut afin de déterminer si certains sites traitent plus lentement les livraisons entrantes, ce qui aide à repérer les inefficacités opérationnelles ou les contraintes de ressources propres à certains sites.
Pourquoi c’est important
Permet d'analyser le processus de réception par lieu et de mettre en évidence les écarts de performance entre les entrepôts, les sites de production et les bureaux.
Où les obtenir
Ces informations figurent dans l'adresse « Ship-To » du Purchase Order dans Coupa.
Exemples
Entrepôt A - ChicagoBâtiment 5 - bureau de LondresUsine de Francfort
|
|||
|
Livraison dans les délais
IsDeliveryOnTime
|
Indicateur calculé précisant si les biens ont été reçus à la date de livraison demandée ou avant celle-ci. | ||
|
Description
Cet attribut booléen est calculé en comparant l'horodatage de l'événement « Goods Receipt Posted » avec « RequestedDeliveryDate ». Il prend la valeur true si la date de réception est antérieure ou égale à la date demandée. Cet indicateur contribue directement au KPI « Supplier Delivery Date Adherence » et au Dashboard « Delivery Date Variance and Returns ». Il fournit une mesure binaire claire de la performance en matière de respect des délais, facile à agréger et à visualiser, afin d'identifier rapidement les problèmes liés aux fournisseurs ou aux processus internes de réception.
Pourquoi c’est important
Fournit une mesure binaire claire de la performance des livraisons et simplifie le calcul des KPI de livraison dans les délais ainsi que l'analyse des tendances.
Où les obtenir
Calculé lors de la transformation des données en comparant « RequestedDeliveryDate » avec l'horodatage de l'activité « Goods Receipt Posted ».
Exemples
truefalse
|
|||
|
Motif de modification
ChangeReason
|
Motif indiqué pour une modification apportée à un Purchase Order après sa création initiale. | ||
|
Description
Cet attribut enregistre la justification d'une modification du Purchase Order, par exemple « Quantité mise à jour » ou « Correction du prix ». Ces informations sont souvent consignées dans la piste d'audit lorsqu'un utilisateur exécute l'activité « Purchase Order Changed ». Comprendre les raisons des modifications est essentiel au Dashboard « Purchase Order Change Analysis ». Cela permet de distinguer les modifications inévitables, comme les problèmes de stock du fournisseur, de celles qui auraient pu être évitées, comme une erreur de saisie initiale, afin d'améliorer la précision des commandes et de réduire le KPI « Purchase Order Change Rate ».
Pourquoi c’est important
Explique les causes profondes des modifications des PO et permet de cibler les mesures visant à améliorer la précision des commandes dès la première saisie et à réduire les reprises du processus.
Où les obtenir
Souvent présent dans les journaux d'audit ou les commentaires associés aux événements de modification d'un Purchase Order dans Coupa.
Exemples
Mise à jour du prix par le fournisseurDate de livraison ajustéeCode article corrigé
|
|||
|
Motif du rejet
RejectionReason
|
Motif indiqué lorsqu'une demande d'achat ou un Purchase Order est rejeté lors d'une étape d'approbation. | ||
|
Description
Lorsqu'un approbateur rejette un Purchase Order, il indique souvent le motif du rejet. Cet attribut enregistre cette explication textuelle, par exemple « Code budgétaire incorrect » ou « Dépassement de la limite de dépenses ». L'analyse des motifs de rejet fournit des informations directes sur les causes profondes des reprises et des défaillances du processus. Ces données qualitatives permettent d'identifier les erreurs fréquentes lors de la création des demandes, puis de mettre en place des formations ciblées ou des améliorations du système afin d'éviter de nouveaux rejets et d'augmenter le taux d'approbation dès la première soumission.
Pourquoi c’est important
Fournit des informations concrètes sur les raisons du rejet des Purchase Orders et aide à traiter les causes profondes des reprises et des retards du processus.
Où les obtenir
Cette information est généralement enregistrée dans le champ des commentaires ou des notes associé à l’activité « Bon de commande rejeté » ou « Demande d’achat rejetée » dans le flux de travail d’approbation de Coupa.
Exemples
Demande en doubleBudget non approuvéFournisseur incorrect sélectionné
|
|||
|
Nom du demandeur
RequesterName
|
Nom de la personne qui a demandé initialement les biens ou services. | ||
|
Description
Cet attribut identifie le collaborateur qui a créé la demande d'achat à l'origine du Purchase Order. Le demandeur est l'utilisateur métier à l'origine du besoin, qui peut être différent de l'acheteur ou de l'approbateur. L'analyse du comportement du processus par demandeur permet d'identifier les tendances propres à certains utilisateurs ou services. Le Dashboard « Purchase Order Change Analysis » l'utilise pour déterminer si certains demandeurs modifient plus souvent leurs commandes, ce qui peut révéler un besoin de formation accrue sur les exigences de spécification.
Pourquoi c’est important
Permet d'identifier l'origine métier d'un achat et d'analyser le comportement ainsi que la précision du processus d'achat au niveau du demandeur.
Où les obtenir
Ces informations sont généralement enregistrées dans la demande d'achat source, puis reprises dans le Purchase Order dans Coupa.
Exemples
Alice CooperBob DylanCharlie Parker
|
|||
|
Numéro de demande d'achat
PurchaseRequisitionNumber
|
Identifiant unique de la demande d'achat qui a précédé le Purchase Order. | ||
|
Description
Cet attribut relie un Purchase Order à la demande d'achat à l'origine de sa création. Une même demande peut donner lieu à un ou plusieurs Purchase Orders. Ce lien est essentiel pour analyser le temps de cycle complet « Requisition-to-Order ». En reliant l'événement de création de la demande aux événements de création et d'envoi du Purchase Order, les organisations peuvent mesurer l'efficacité de l'ensemble de leur processus d'initiation des achats, de la demande à l'exécution.
Pourquoi c’est important
Relie les phases de demande et de commande du processus, permettant d'analyser le temps de cycle et les taux de conversion entre la demande et la commande.
Où les obtenir
Il s'agit généralement d'un champ de référence présent sur les lignes du Purchase Order dans Coupa, qui renvoie à la demande d'achat source.
Exemples
PR-2023-00098PR-2023-00152PR-2023-00341
|
|||
|
Reprise
IsRework
|
Indicateur calculé qui précise si un Purchase Order a fait l'objet d'une activité de modification. | ||
|
Description
Cet indicateur booléen prend la valeur true pour tout Purchase Order comportant au moins un événement « Purchase Order Changed » dans son historique. Il s'agit d'un attribut au niveau du dossier, dérivé du journal d'événements. Cet attribut simplifie le calcul de KPI tels que « Purchase Order Change Rate ». Il permet de filtrer et de segmenter facilement les données afin de comparer les processus des commandes ayant fait l'objet d'une reprise avec ceux des commandes n'en ayant pas fait l'objet, et de mesurer l'impact des modifications sur le temps de cycle et les coûts. Il constitue un élément central du Dashboard « Purchase Order Change Analysis ».
Pourquoi c’est important
Simplifie l'analyse des reprises en permettant de filtrer et d'agréger facilement tous les Purchase Orders ayant été modifiés au moins une fois.
Où les obtenir
Calculé lors de la transformation des données en vérifiant l'existence d'une activité « Purchase Order Changed » pour chaque PurchaseOrderNumber.
Exemples
truefalse
|
|||
Purchase to Pay - Activités liées aux commandes d’achat
| Activité | Description | ||
|---|---|---|---|
|
Bon de commande annulé
|
Cette activité correspond à l’annulation d’un bon de commande avant son achèvement. Une annulation peut intervenir à différentes étapes, par exemple si la demande n’est plus valide ou si le bon de commande a été créé par erreur. | ||
|
Pourquoi c’est important
En tant qu’issue alternative du processus, le suivi des annulations est important pour comprendre les abandons et identifier les raisons des demandes d’achat non abouties.
Où les obtenir
Cet événement est déduit d’un changement de statut de l’objet Bon de commande vers « Canceled ». L’horodatage de ce changement de statut sert d’heure de l’événement.
Collecte
Dérivé de l’horodatage du changement de statut vers « Canceled ».
Type d’événement
inferred
|
|||
|
Bon de commande approuvé
|
Cette étape clé indique que le bon de commande a terminé son flux de travail d’approbation interne et qu’il est autorisé à être envoyé au fournisseur. Il s’agit généralement de l’étape d’approbation finale d’un processus en plusieurs étapes. | ||
|
Pourquoi c’est important
Il s’agit d’une étape clé pour calculer les temps de cycle d’approbation des bons de commande et identifier les goulots d’étranglement. Elle constitue également un point de contrôle important en matière de conformité.
Où les obtenir
Extrait du journal de l’historique des approbations du bon de commande dans Coupa. L’horodatage de l’action d’approbation finale fournit l’heure de l’événement.
Collecte
Enregistré dans l’historique des approbations lorsque le dernier approbateur termine sa tâche.
Type d’événement
explicit
|
|||
|
Bon de commande clôturé
|
Il s’agit de l’activité finale, qui indique que le bon de commande est terminé. Le bon de commande est considéré comme clôturé lorsque les marchandises ont été entièrement reçues et facturées, et qu’aucune autre transaction n’est attendue. | ||
|
Pourquoi c’est important
Cette activité met officiellement fin au cycle de vie du bon de commande. L’analyse du délai de clôture peut révéler des inefficacités lors du rapprochement final et de la tenue des registres.
Où les obtenir
Cet événement est déduit d’un changement de statut de l’objet Bon de commande vers « Closed ». Coupa définit souvent automatiquement ce statut selon des règles métier relatives aux tolérances de réception et de facturation.
Collecte
Dérivé de l’horodatage du changement de statut vers « Closed ».
Type d’événement
inferred
|
|||
|
Bon de commande envoyé au fournisseur
|
Cette activité marque le moment où le bon de commande approuvé est officiellement transmis au fournisseur, par exemple par e-mail ou via le Coupa Supplier Portal. Cet événement fait passer le bon de commande d’un document interne à un engagement externe. | ||
|
Pourquoi c’est important
Il s’agit d’une étape importante qui clôt le cycle interne de la demande à la commande et lance le délai fournisseur. Elle est indispensable pour mesurer à la fois l’efficacité interne et la performance des fournisseurs.
Où les obtenir
Cet événement est souvent déduit d’un changement de statut du bon de commande vers « Ordered » ou « Sent ». Coupa peut également proposer un champ d’horodatage spécifique tel que « last_exported_at » ou « sent_to_supplier_at » dans l’enregistrement du bon de commande.
Collecte
Dérivé de l’horodatage du changement de statut vers « Ordered » ou d’un champ d’horodatage spécifique à la transmission.
Type d’événement
inferred
|
|||
|
Demande d’achat créée
|
Cette activité marque la création d’une demande d’achat, c’est-à-dire la demande officielle de biens ou de services qui précède un bon de commande. Dans Coupa, il s’agit d’un événement explicite enregistré lorsqu’un utilisateur enregistre et soumet une nouvelle demande. | ||
|
Pourquoi c’est important
En tant que point de départ habituel du processus d’approvisionnement, cette activité est indispensable pour mesurer l’intégralité du cycle de la demande à la commande et comprendre l’efficacité des étapes en amont.
Où les obtenir
Cet événement correspond à l’enregistrement de la création dans l’objet ou la table des demandes d’achat de Coupa. L’horodatage se trouve dans le champ « created_at » ou dans un champ équivalent contenant la date de création générée par le système.
Collecte
Enregistré directement lors de la création d’une nouvelle demande.
Type d’événement
explicit
|
|||
|
Réception des marchandises enregistrée
|
Il s’agit de la confirmation officielle que les marchandises ont été reçues, inspectées et acceptées. Cet événement met à jour les enregistrements de stock et indique que le fournisseur a rempli son obligation pour cette livraison. | ||
|
Pourquoi c’est important
Cette étape importante marque la fin du délai fournisseur et sert à mesurer le respect de la date de livraison. Les retards d’enregistrement des réceptions peuvent masquer les niveaux de stock réels.
Où les obtenir
Il s’agit d’une transaction centrale dans Coupa, enregistrée sur l’objet Receipt. L’événement est extrait de l’horodatage auquel le statut de la réception devient « Posted » ou « Received ».
Collecte
Enregistré lorsque la transaction de réception des marchandises est finalisée dans le système.
Type d’événement
explicit
|
|||
|
Bon de commande modifié
|
Cet événement correspond à toute modification apportée au bon de commande après sa première rédaction. Dans Coupa, les modifications sont souvent suivies au moyen du versionnage du document de bon de commande. | ||
|
Pourquoi c’est important
Le suivi des modifications est essentiel pour des KPI tels que le taux de modification des bons de commande et le taux de bons de commande non conformes. Des modifications fréquentes peuvent indiquer une instabilité du processus ou l’inexactitude des demandes initiales.
Où les obtenir
Cet événement peut être déduit du suivi des différentes versions d’un bon de commande. Chaque numéro de version supérieur au premier indique une modification, la date de création de la nouvelle version servant d’horodatage de l’événement.
Collecte
Déduit de l’horodatage de création d’une nouvelle version du bon de commande.
Type d’événement
inferred
|
|||
|
Bon de commande rédigé
|
Cet événement correspond à la création initiale du document de bon de commande dans le système, souvent à partir d’une demande approuvée. À ce stade, le bon de commande est un brouillon interne qui n’a pas encore été soumis à approbation ni envoyé au fournisseur. | ||
|
Pourquoi c’est important
Cette activité lance le calcul du KPI de temps de cycle d’approbation du bon de commande. Il s’agit de la première étape officielle du cycle de vie du bon de commande.
Où les obtenir
Cet événement correspond à l’horodatage de création de l’enregistrement du bon de commande dans Coupa, généralement disponible dans un champ tel que « created_at ».
Collecte
Extrait de l’horodatage de création généré par le système pour l’enregistrement du bon de commande.
Type d’événement
explicit
|
|||
|
Bon de commande rejeté
|
Cette activité intervient lorsqu’un approbateur rejette le bon de commande pendant le flux de travail d’approbation. Le bon de commande est alors généralement renvoyé à son créateur pour révision ou annulation. | ||
|
Pourquoi c’est important
L’analyse des rejets permet de révéler les problèmes de qualité des données, les violations des politiques ou les lacunes en matière de formation. Elle met en évidence les boucles de reprise qui entraînent des retards importants dans le processus.
Où les obtenir
Il s’agit d’un événement explicite enregistré dans le journal de l’historique des approbations du bon de commande dans Coupa. Le journal affiche une action « Reject » accompagnée d’un horodatage.
Collecte
Enregistré dans l’historique des approbations avec le statut « Reject ».
Type d’événement
explicit
|
|||
|
Bon de commande soumis
|
Après la création d’un bon de commande, celui-ci est officiellement soumis au flux de travail d’approbation. Cette action utilisateur distincte fait passer le bon de commande de l’état de brouillon à l’état d’approbation en attente. | ||
|
Pourquoi c’est important
Cet événement distingue le temps consacré à la rédaction du moment où le bon de commande est effectivement en attente d’approbation. Il offre une vision plus précise du comportement des utilisateurs et des transferts entre intervenants.
Où les obtenir
Déduit d’un changement de statut sur l’objet Bon de commande, par exemple de « draft » à « pending approval ». L’horodatage de ce changement de statut précis est utilisé.
Collecte
Dérivé de l’horodatage du changement de statut vers « pending approval ».
Type d’événement
inferred
|
|||
|
Commande confirmée par le fournisseur
|
Cet événement indique que le fournisseur a reçu et confirmé le bon de commande. Cette confirmation est souvent enregistrée électroniquement via un portail fournisseur tel que le Coupa Supplier Portal (CSP). | ||
|
Pourquoi c’est important
La confirmation du fournisseur garantit que la commande est en cours de traitement, améliore la précision des prévisions de livraison et réduit l’incertitude dans la chaîne d’approvisionnement.
Où les obtenir
Ces informations sont généralement disponibles sur le bon de commande lorsque le fournisseur utilise le Coupa Supplier Portal pour effectuer une action « Acknowledge ». L’horodatage de cette action est utilisé.
Collecte
Enregistré lorsqu’un fournisseur effectue l’action « Acknowledge » dans le portail fournisseur.
Type d’événement
explicit
|
|||
|
Confirmation de service saisie
|
Pour les bons de commande portant sur des services, cette activité équivaut à une réception de marchandises. Elle confirme qu’un service a été fourni conformément aux conditions du bon de commande. | ||
|
Pourquoi c’est important
Le suivi des confirmations de service est essentiel pour gérer les dépenses de services et s’assurer que les paiements portent uniquement sur des prestations dont l’achèvement a été vérifié.
Où les obtenir
Cet événement est extrait de la création ou de l’approbation d’une réception de service ou d’une feuille de saisie de service associée au bon de commande dans Coupa.
Collecte
Enregistré lors de la création et de l’approbation d’une feuille de saisie de service.
Type d’événement
explicit
|
|||
|
Demande d’achat approuvée
|
Une demande d’achat suit un flux de travail d’approbation avant de pouvoir être convertie en bon de commande. Cet événement indique que la demande a reçu son approbation finale et peut être transformée en commande. | ||
|
Pourquoi c’est important
Le suivi des approbations des demandes d’achat aide à identifier les goulots d’étranglement lors de la phase précédant la commande. Les retards à ce stade ont une incidence directe sur la rapidité d’émission d’un bon de commande.
Où les obtenir
Cet événement est généralement extrait de l’historique des approbations de l’objet de demande dans Coupa. L’action d’approbation finale est associée à un horodatage et à un utilisateur.
Collecte
Enregistré dans l’historique des approbations lorsque le dernier approbateur intervient.
Type d’événement
explicit
|
|||
|
Facture reçue pour le bon de commande
|
Cet événement marque la réception et la saisie de la facture d’un fournisseur faisant référence au bon de commande. Il indique le début de la phase de traitement et de paiement de la facture dans le cycle P2P. | ||
|
Pourquoi c’est important
Bien qu’elle relève du processus de comptabilité fournisseurs, l’association de la réception de la facture au bon de commande offre une vision de bout en bout du cycle de vie de la transaction et permet d’analyser l’écart entre la livraison et la facturation.
Où les obtenir
Extrait de l’horodatage de création du document Invoice dans Coupa, lorsque la facture est rapprochée du numéro de bon de commande correspondant.
Collecte
Enregistré lors de la création d’un enregistrement de facture associé au bon de commande.
Type d’événement
explicit
|
|||
|
Inspection qualité effectuée
|
Cet événement indique qu’un article reçu a fait l’objet d’une inspection qualité concluante. Selon le processus de l’entreprise, cette étape peut intervenir séparément après l’enregistrement initial de la réception des marchandises. | ||
|
Pourquoi c’est important
Cette activité est essentielle pour mesurer l’efficacité du processus de contrôle qualité. Les retards à ce stade peuvent créer des goulots d’étranglement entre la réception et la mise à disposition des marchandises.
Où les obtenir
Cette information peut être enregistrée comme un changement de statut sur la ligne de réception ou dans un objet d’inspection distinct dans Coupa. Sa disponibilité dépend de l’utilisation du module qualité ou d’un flux de travail personnalisé.
Collecte
Déduit d’un changement de statut de la réception ou de l’horodatage d’un enregistrement d’inspection associé.
Type d’événement
inferred
|
|||
|
Marchandises retournées
|
Cette activité est enregistrée lorsque des marchandises précédemment reçues sont renvoyées au fournisseur. Cela se produit généralement en raison de problèmes de qualité, de dommages ou d’une livraison incorrecte. | ||
|
Pourquoi c’est important
Le suivi des retours est indispensable pour calculer le taux de retour des marchandises et identifier les problèmes liés à la qualité des fournisseurs ou à l’exactitude des commandes. Un taux de retour élevé indique souvent des défaillances coûteuses du processus.
Où les obtenir
Cet événement est extrait d’une transaction « Return to Supplier » ou d’une transaction de réception négative dans Coupa. L’horodatage de cette transaction sert d’heure de l’événement.
Collecte
Enregistré lors de la création d’une transaction de retour associée au bon de commande ou à la réception d’origine.
Type d’événement
explicit
|
|||
|
Réception des marchandises initiée
|
Cette activité représente le début du processus de réception, par exemple lorsqu’un document de réception est créé dans Coupa à l’arrivée physique des marchandises. Les marchandises n’ont pas encore été officiellement enregistrées en stock ni confirmées comme reçues. | ||
|
Pourquoi c’est important
Cet événement constitue le point de départ du calcul du KPI de temps de traitement de la réception des marchandises. Il permet de distinguer le temps d’attente des marchandises sur le quai du temps consacré au traitement dans le système.
Où les obtenir
Cet événement peut être déduit de l’horodatage de création d’un document de réception dont le statut est « Draft » ou « Pending ». Il précède l’enregistrement final de la réception.
Collecte
Dérivé de l’horodatage de création d’un enregistrement de réception dans un état non enregistré.
Type d’événement
inferred
|
|||
Guides d’extraction
Prêt à commencer ?
Utilisez ce template pour préparer vos données au Process Mining et obtenir des analyses concrètes. Commencez dès aujourd’hui à optimiser votre processus Purchase to Pay, commande d’achat.
Optimisez vos commandes d’achat P2P et améliorez votre efficacité dès aujourd’hui
Réduisez de 30 % la durée de votre cycle P2P et commencez rapidement à obtenir des résultats.
Aucune carte bancaire requise, configuration en quelques minutes.