Votre modèle de données Purchase to Pay - Requisition
Votre modèle de données Purchase to Pay - Requisition
- Attributs recommandés à collecter
- Activités clés à suivre pour la découverte du processus
- Conseils pour l’extraction des données
Purchase to Pay - Requisition : attributs
| Nom | Description | ||
|---|---|---|---|
|
Heure de l’événement
EventTime
|
La date et l’heure précises auxquelles l’activité a eu lieu. | ||
|
Description
L’heure de l’événement, ou horodatage, enregistre le moment exact où une activité a eu lieu. Ces données temporelles sont essentielles pour comprendre la dynamique du processus de demande d’achat, notamment sa durée, l’enchaînement des événements et leur calendrier. Dans l’analyse des processus, les horodatages servent à calculer les temps de cycle, les temps d’attente entre les activités et le respect des accords de niveau de service. Ils constituent le fondement de toutes les analyses temporelles et permettent de créer des Dashboards tels que « Temps de cycle d’approbation des demandes d’achat » ainsi que des KPI comme « Temps de cycle moyen des demandes d’achat ». Des horodatages précis sont indispensables à un modèle de processus fiable.
Pourquoi c’est important
Cet horodatage constitue le fondement de toutes les analyses liées à la performance, notamment le calcul des temps de cycle, l’identification des retards et la mesure de l’efficacité du processus.
Où les obtenir
Ces informations sont capturées dans des champs générés par le système, tels que « Date Created », ou dans les horodatages disponibles dans les System Notes ou les journaux d’exécution du flux de travail de chaque transaction.
Exemples
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z
|
|||
|
Identifiant de la demande d’achat
PurchaseRequisitionId
|
Identifiant unique de chaque demande d’achat, utilisé comme Case ID principal pour l’analyse du processus. | ||
|
Description
Le Purchase Requisition ID est l’identifiant central qui relie toutes les activités et tous les événements associés à une demande précise de biens ou de services. Chaque demande reçoit un identifiant unique lors de sa création dans NetSuite, qui reste inchangé pendant tout son cycle de vie. Dans le process mining, cet attribut est fondamental pour corréler les cas. Il permet de reconstituer le parcours de bout en bout de chaque demande, depuis sa création initiale jusqu’à toutes les étapes d’approbation, modifications et issues finales, comme l’approbation, le rejet ou la conversion en bon de commande. L’analyse des processus à partir de cet identifiant est essentielle pour calculer les durées du cycle de vie, suivre les changements de statut et repérer les variations des parcours.
Pourquoi c’est important
Il s’agit de la clé essentielle pour suivre le cycle de vie complet d’une demande d’achat, analyser les parcours et calculer les indicateurs au niveau du cas.
Où les obtenir
Il s’agit de l’identifiant interne ou du numéro de transaction de l’enregistrement Purchase Requisition dans NetSuite. Il se trouve généralement dans le champ « tranid » de la transaction.
Exemples
PR-001254PR-001255PR-001256
|
|||
|
Nom de l’activité
ActivityName
|
Nom d’un événement métier ou d’une tâche précise survenu dans le cycle de vie de la demande d’achat. | ||
|
Description
L’Activity Name décrit une étape distincte du processus de demande, comme « Requisition Created », « Approval Step Approved » ou « Purchase Order Created ». Ces activités constituent les éléments de base de la cartographie du processus et représentent le travail effectué. L’analyse de ces activités permet de visualiser le parcours, d’identifier les goulots d’étranglement et de mesurer le temps passé aux différentes étapes. La séquence des activités associées à un Purchase Requisition ID donné définit son parcours, qui peut ensuite être comparé aux procédures standard afin de repérer les écarts ou les inefficacités.
Pourquoi c’est important
Il définit les étapes du processus et permet de visualiser les cartographies, d’analyser les variantes de parcours et d’identifier les goulots d’étranglement.
Où les obtenir
Cette étape est généralement déduite d’une combinaison du statut de la transaction, des entrées du journal système, de l’historique du flux de travail ou d’un suivi d’événements personnalisé dans NetSuite.
Exemples
Demande crééeÉtape d’approbation approuvéeDemande modifiéeBon de commande créé
|
|||
|
Demandeur
Requester
|
Le collaborateur qui a créé et soumis la demande d’achat. | ||
|
Description
Le demandeur est la personne qui lance le processus d’approvisionnement en créant la demande d’achat. Il s’agit généralement d’un collaborateur ayant besoin de biens ou de services spécifiques pour exercer ses fonctions. L’analyse des données par demandeur est essentielle pour identifier les comportements récurrents des utilisateurs. Elle permet de créer des Dashboards tels que « Performance des demandeurs et besoins de formation », en mettant en évidence les personnes présentant un taux élevé de rejets ou effectuant fréquemment des modifications. Ces analyses peuvent révéler les domaines dans lesquels une formation complémentaire ou des consignes plus claires amélioreraient la qualité des soumissions dès la première tentative et l’efficacité globale du processus.
Pourquoi c’est important
Identifie l’initiateur du processus, ce qui est essentiel pour analyser le comportement des utilisateurs, les taux de rejet par demandeur et les besoins de formation.
Où les obtenir
Il s’agit généralement du champ « Employee » ou « Created By » de l’enregistrement de transaction Purchase Requisition.
Exemples
John SmithJane DoePeter Jones
|
|||
|
Département
Department
|
Le département de l’entreprise auquel la demande d’achat ou le demandeur est rattaché. | ||
|
Description
L’attribut Department représente l’unité organisationnelle associée à la demande d’achat, généralement le service du demandeur. Il permet de segmenter et d’analyser le processus selon une perspective organisationnelle. Il constitue une dimension essentielle pour de nombreuses analyses, notamment la comparaison des temps de cycle d’approbation entre les services, la compréhension des habitudes de dépense ou l’identification des services affichant les taux de rejet les plus élevés. Cette segmentation aide la direction à affecter les ressources, à adapter la formation et à simplifier les flux de travail pour chaque unité opérationnelle.
Pourquoi c’est important
Permet de segmenter finement les données du processus afin de comparer la performance, les coûts et la conformité entre différentes unités opérationnelles.
Où les obtenir
Ces informations sont souvent associées à l’enregistrement du collaborateur demandeur ou peuvent être définies directement dans l’en-tête de transaction de la Purchase Requisition.
Exemples
MarketingInformatiqueFinanceOpérations
|
|||
|
Montant total
TotalAmount
|
La valeur monétaire totale de la demande d’achat. | ||
|
Description
Cet attribut indique le coût total de tous les articles figurant sur la demande d’achat. Il s’agit d’une donnée financière importante qui influence souvent le processus, par exemple en déclenchant différents flux de travail d’approbation selon des seuils de montant. L’analyse du montant total aide à comprendre les habitudes de dépense et l’impact financier. Elle permet de filtrer les demandes par valeur, de mettre en relation les écarts de processus avec les demandes de montant élevé et de prioriser l’analyse des cas ayant une incidence financière importante. Il s’agit d’un attribut fondamental pour toute analyse de processus liée aux finances ou à la conformité.
Pourquoi c’est important
Fournit un contexte financier et permet d’analyser les demandes selon leur valeur, laquelle détermine souvent le circuit d’approbation et la priorité métier.
Où les obtenir
Il s’agit d’un champ standard de l’enregistrement Purchase Requisition, souvent nommé « Total » ou selon une variante similaire.
Exemples
500.001250.7525000.00
|
|||
|
Statut de la demande d’achat
RequisitionStatus
|
Indique l’état actuel de la demande d’achat dans son cycle de vie. | ||
|
Description
Le statut de la demande d’achat fournit un aperçu de la position de la demande dans le processus à un moment donné. Les statuts courants comprennent « Pending Approval », « Fully Approved », « Rejected » et « Closed ». Cet attribut est essentiel à la création de Dashboards tels que « Statut et ancienneté des demandes d’achat », qui suivent les demandes actives et la durée passée dans leur état actuel. L’analyse des transitions de statut constitue un élément clé de la découverte des processus. Elle permet de comprendre les parcours conformes comme les exceptions. Elle sert également à déterminer l’issue finale d’un dossier.
Pourquoi c’est important
Fournit un aperçu de l’avancement d’un dossier, permettant d’analyser l’ancienneté des demandes et d’identifier les étapes auxquelles elles restent bloquées.
Où les obtenir
Il s’agit du champ « Status » ou « Approval Status » de l’en-tête de transaction Purchase Requisition.
Exemples
En attente d’approbationEntièrement approuvéeRejetéeClôturée
|
|||
|
Approbateur
Approver
|
Le collaborateur ou l’utilisateur chargé d’approuver ou de rejeter une étape d’approbation. | ||
|
Description
L’approbateur est la personne chargée d’examiner une demande d’achat et d’agir à une étape précise du flux de travail d’approbation. Une même demande peut avoir plusieurs approbateurs, chacun étant associé à une activité d’approbation différente. Cet attribut est essentiel pour analyser les performances du processus d’approbation lui-même. Il permet de créer des Dashboards tels que « Approval Step Cycle Time Distribution », capables de repérer les goulots d’étranglement individuels ou collectifs. En suivant les personnes qui effectuent les approbations, les organisations peuvent clarifier la répartition des responsabilités, équilibrer les charges et identifier les retards imputables à certains approbateurs.
Pourquoi c’est important
Identifie l’utilisateur qui effectue les tâches d’approbation, ce qui est essentiel pour analyser la performance et la charge de travail des approbateurs et repérer les goulots d’étranglement.
Où les obtenir
Ces informations figurent souvent dans le journal d’exécution du flux de travail ou dans les notes système associées aux changements de statut d’approbation. Elles peuvent également être stockées dans des champs personnalisés des enregistrements liés au flux de travail d’approbation.
Exemples
Sarah JenkinsDavid ChenGroupe d’approbation financière
|
|||
|
Catégorie d’article
ItemCategory
|
La catégorie des biens ou services demandés dans la demande d’achat. | ||
|
Description
La catégorie d’article classe les articles d’une demande d’achat en groupes logiques tels que « Matériel informatique », « Fournitures de bureau » ou « Services professionnels ». Elle peut être déduite des enregistrements d’articles associés aux lignes de la demande. Cet attribut permet une analyse plus détaillée et plus précise du processus de demande d’achat. Il aide à répondre à des questions telles que : « Les demandes de matériel informatique prennent-elles plus de temps à approuver que celles de fournitures de bureau ? » En segmentant le processus par catégorie d’article, les entreprises peuvent repérer les goulots d’étranglement propres à certains domaines, analyser les dépenses par catégorie et adapter leurs stratégies d’approvisionnement.
Pourquoi c’est important
Permet d’analyser le processus selon la nature des achats et d’identifier les goulots d’étranglement ou les problèmes de conformité propres à certaines catégories.
Où les obtenir
Ces informations sont déduites des enregistrements « Item » associés au niveau des lignes de la Purchase Requisition. La catégorie elle-même peut être un champ standard ou personnalisé de l’enregistrement Item.
Exemples
Matériel informatiqueLicences logiciellesFournitures de bureauServices marketing
|
|||
|
Chemin du flux de travail d’approbation
ApprovalWorkflowPath
|
Une représentation de la séquence des étapes d’approbation suivies par une demande d’achat. | ||
|
Description
Le parcours du Workflow d’approbation est un attribut dérivé qui concatène la séquence des activités ou des statuts d’approbation d’une demande d’achat donnée, par exemple « Submitted -> Manager Approval -> Finance Approval ». Il crée une signature unique du parcours suivi par chaque dossier. Cet attribut constitue le fondement du contrôle de conformité et de l’analyse des variantes. Il alimente directement les Dashboards « Parcours non conformes des demandes d’achat » et « Conformité du parcours du Workflow d’approbation », en facilitant le filtrage et le regroupement des dossiers selon leur flux de processus exact. En comparant les parcours réels aux parcours standard prédéfinis, les organisations peuvent mesurer la conformité et analyser les causes profondes des écarts.
Pourquoi c’est important
Permet une analyse détaillée des variantes et un contrôle de conformité en résumant la séquence exacte des étapes d’approbation pour chaque dossier.
Où les obtenir
Il s’agit d’un attribut dérivé, calculé en concaténant les valeurs « ActivityName » dans l’ordre chronologique pour chaque « PurchaseRequisitionId ».
Exemples
Créée > Soumise > ApprouvéeCréée > Soumise > Rejetée > Modifiée > Soumise > ApprouvéeCréée > Soumise > Approuvée > Retirée
|
|||
|
Dernière mise à jour des données
LastDataUpdate
|
L’horodatage indiquant la date de la dernière extraction ou actualisation des données depuis le système source. | ||
|
Description
Cet attribut enregistre la date et l’heure de la dernière extraction des données depuis NetSuite. Il s’agit d’un élément essentiel des métadonnées de tout Dashboard ou de toute analyse de Process Mining. Cet horodatage indique le degré d’actualité des données et permet de déterminer si les utilisateurs consultent des informations en temps réel ou un instantané correspondant à un moment précis. Il est indispensable à la validation des données et à la communication, auprès des parties prenantes, de l’actualité des analyses produites par l’analyse des processus.
Pourquoi c’est important
Informe les utilisateurs de l’actualité des données et leur permet de comprendre dans quelle mesure les analyses du processus sont à jour.
Où les obtenir
Cet horodatage est généré et ajouté lors du processus d’extraction, de transformation et de chargement des données (ETL).
Exemples
2024-05-21T08:00:00Z2024-05-20T08:00:00Z
|
|||
|
Devise
Currency
|
Le code devise correspondant au montant total de la demande d’achat. | ||
|
Description
L’attribut Devise indique la devise dans laquelle sont exprimées les valeurs financières de la demande d’achat, par exemple USD, EUR ou GBP. Il est particulièrement important pour les organisations internationales qui utilisent plusieurs devises. Ce champ garantit une interprétation correcte des données financières. Dans le Process Mining, il permet d’agréger et de comparer correctement les montants, soit en convertissant toutes les valeurs dans une devise de référence, soit en segmentant l’analyse par devise. Il évite les erreurs de reporting financier et garantit une lecture claire des opérations internationales.
Pourquoi c’est important
Essentiel à la précision des analyses financières dans les organisations internationales, il garantit une interprétation et une agrégation correctes des valeurs monétaires.
Où les obtenir
Il s’agit d’un champ standard « Currency » de l’enregistrement de transaction Purchase Requisition, notamment dans les instances NetSuite multidevises.
Exemples
USDEURGBP
|
|||
|
ID du bon de commande
PurchaseOrderId
|
L’identifiant du bon de commande créé à partir de la demande d’achat approuvée. | ||
|
Description
L’ID du bon de commande est l’identifiant unique du bon de commande généré à la suite de l’approbation d’une demande d’achat. Cet attribut établit le lien entre le processus de demande d’achat et les activités d’approvisionnement qui suivent. Dans l’analyse des processus, ce lien est essentiel à l’analyse P2P de bout en bout. Il permet de calculer le KPI « Délai de création du bon de commande » en mesurant le temps écoulé entre l’approbation de la demande et la création du bon de commande. Il permet également de calculer le « Taux de conversion des demandes d’achat en bons de commande » et d’évaluer l’efficacité avec laquelle les demandes sont transformées en commandes.
Pourquoi c’est important
Relie la demande d’achat au bon de commande correspondant et permet de mesurer le délai de création du bon de commande ainsi que le processus de bout en bout.
Où les obtenir
Cette information figure dans l’enregistrement Purchase Requisition, souvent dans un sous-onglet consacré aux enregistrements associés, ou dans un lien « Created From » du bon de commande lui-même.
Exemples
PO-005432PO-005433PO-005434
|
|||
|
Indicateur de reprise
IsRework
|
Un indicateur booléen précisant si la demande d’achat a fait l’objet d’un rejet suivi d’une nouvelle soumission. | ||
|
Description
L’indicateur de reprise est un attribut booléen dérivé, défini sur true lorsqu’une demande d’achat a été rejetée à un moment donné, puis modifiée ou soumise à nouveau pour approbation. Il identifie les dossiers ayant nécessité un traitement supplémentaire par rapport au parcours standard. Cet attribut simplifie l’analyse des inefficacités du processus. Il sert à calculer le KPI « Nombre de cycles de rejet lors de l’approbation » et à mesurer l’impact des rejets sur le processus global. En filtrant les dossiers pour lesquels l’indicateur de reprise est true, les analystes peuvent isoler les variantes problématiques et rechercher les causes profondes des rejets initiaux, telles qu’une mauvaise qualité des données ou une mauvaise compréhension des règles.
Pourquoi c’est important
Aide à mesurer la fréquence et l’impact des boucles de reprise, qui constituent une source importante d’inefficacité et de retard dans les processus.
Où les obtenir
Il s’agit d’un attribut calculé. La logique vérifie si une activité « Requisition Submitted for Approval » survient après une activité « Approval Step Rejected » pour le même dossier.
Exemples
truefalse
|
|||
|
Motif du rejet
RejectionReason
|
L’explication fournie par un approbateur lorsqu’une demande d’achat est rejetée. | ||
|
Description
Le motif du rejet est un attribut textuel dans lequel l’approbateur peut expliquer pourquoi une demande d’achat ne répondait pas aux exigences d’approbation. Il fournit un contexte qualitatif à l’activité « Approval Step Rejected ». Ces informations sont particulièrement utiles à l’analyse des causes profondes. Elles alimentent des Dashboards tels que « Analyse du taux de rejet des demandes d’achat », qui indiquent non seulement ce qui a été rejeté, mais aussi pourquoi. Les motifs courants peuvent être « Compte GL incorrect », « Budget dépassé » ou « Informations insuffisantes ». L’analyse de ces motifs permet d’identifier les problèmes systémiques, d’améliorer la formation des utilisateurs et de préciser les consignes de soumission afin de réduire les reprises et les taux de rejet.
Pourquoi c’est important
Fournit le contexte nécessaire pour comprendre les rejets et permet d’analyser leurs causes profondes afin de réduire les futurs rejets et d’améliorer la qualité dès la première soumission.
Où les obtenir
Ces informations sont souvent saisies dans un champ « Memo » lors du rejet ou dans un champ personnalisé ajouté au flux de travail d’approbation. Elles peuvent également figurer dans les notes système.
Exemples
Budget dépasséFournisseur incorrect sélectionnéDétails des articles manquantsDemande en double
|
|||
|
Niveau d’urgence
UrgencyLevel
|
Une classification de la priorité de la demande d’achat, par exemple Standard ou Urgent. | ||
|
Description
Le niveau d’urgence est un attribut catégoriel qui indique la priorité métier d’une demande d’achat. Il permet aux collaborateurs de signaler les demandes nécessitant un traitement accéléré en raison de besoins opérationnels importants. Cet attribut est spécialement conçu pour alimenter le Dashboard « Performance du traitement des demandes urgentes » et le KPI « Temps de traitement des demandes d’achat urgentes ». En filtrant les données du processus selon cet attribut, les analystes peuvent comparer les temps de cycle et les parcours des demandes urgentes à ceux des demandes standard afin de déterminer si le traitement prioritaire est efficace ou si des goulots d’étranglement continuent de provoquer des retards.
Pourquoi c’est important
Permet de comparer la performance du processus pour les demandes prioritaires et les demandes standard, afin de répondre efficacement aux besoins importants.
Où les obtenir
Il s’agit généralement d’un champ personnalisé du corps de transaction sur le formulaire Purchase Requisition.
Exemples
ÉlevéMoyenFaible
|
|||
|
Nom du fournisseur
VendorName
|
Le nom du fournisseur suggéré ou privilégié pour la demande d’achat. | ||
|
Description
L’attribut Nom du fournisseur identifie le fournisseur auprès duquel les biens ou services doivent être achetés. Même si une demande d’achat est un document interne, un fournisseur privilégié y est souvent indiqué. L’analyse de cet attribut peut révéler des tendances liées à la gestion des fournisseurs. Elle permet de suivre les fournisseurs les plus fréquemment demandés, de vérifier si les demandes concernant certains fournisseurs prennent plus de temps à approuver et de contrôler le respect des accords conclus avec les fournisseurs privilégiés. Ces informations peuvent contribuer à la sélection stratégique des fournisseurs et à la gestion des relations fournisseurs.
Pourquoi c’est important
Aide à analyser les habitudes d’approvisionnement par fournisseur, à garantir le respect des listes de fournisseurs privilégiés et à identifier les variations de processus propres à certains fournisseurs.
Où les obtenir
Il peut s’agir d’un champ « Vendor » au niveau de l’en-tête ou d’une information indiquée sur les lignes de l’enregistrement Purchase Requisition.
Exemples
Dell Inc.StaplesMcKinsey & Company
|
|||
|
Système source
SourceSystem
|
Identifie le système source à partir duquel les données ont été extraites. | ||
|
Description
Cet attribut indique le système d’origine des données du processus, qui est ici NetSuite. Il est particulièrement utile lorsque les données provenant de plusieurs systèmes sont regroupées afin d’obtenir une vue globale du processus. Même s’il peut sembler statique dans le cadre d’une analyse portant sur un seul système, il fournit un contexte essentiel et constitue une bonne pratique en matière de gouvernance et de traçabilité des données. Il permet de confirmer l’origine des données et de s’assurer que toute logique ou transformation propre au système est correctement comprise pendant l’analyse.
Pourquoi c’est important
Fournit un contexte essentiel sur l’origine des données, en garantissant leur bonne compréhension et une gouvernance appropriée, notamment dans les environnements multisystèmes.
Où les obtenir
Il s’agit d’une valeur statique, « NetSuite », qui doit être ajoutée lors de l’extraction et de la transformation des données.
Exemples
NetSuiteNetSuite SuitePeopleNetSuite ERP
|
|||
|
Temps de cycle
CycleTime
|
Le temps total écoulé entre la création et la résolution finale d’une demande d’achat. | ||
|
Description
Le temps de cycle est une mesure calculée qui évalue la durée totale du processus de demande d’achat pour un dossier donné. Il est généralement calculé comme la différence entre la première activité, par exemple « Requisition Created », et la dernière activité terminale, par exemple « Requisition Fully Approved » ou « Requisition Finally Rejected ». Il s’agit d’un indicateur clé de la performance globale du processus. Il sert à calculer le KPI « Temps de cycle moyen des demandes d’achat » et aide à repérer les tendances, les valeurs atypiques et l’impact des initiatives d’amélioration. L’analyse de la répartition des temps de cycle peut révéler les demandes dont la durée exceptionnellement longue dégrade fortement la performance moyenne.
Pourquoi c’est important
Mesure directement l’efficacité du processus de bout en bout. Il s’agit d’un indicateur central pour identifier les retards et évaluer la performance globale.
Où les obtenir
Il s’agit d’un attribut calculé, obtenu en soustrayant l’horodatage du premier événement de celui du dernier événement pour chaque « PurchaseRequisitionId ».
Exemples
25920060480086400
|
|||
Purchase to Pay - Requisition : activités
| Activité | Description | ||
|---|---|---|---|
|
Bon de commande créé
|
Un bon de commande (PO) est généré à partir de la demande approuvée, ce qui engage officiellement des fonds auprès d’un fournisseur. Il s’agit d’un événement explicite, marqué par la création d’une nouvelle transaction PO liée à la demande d’origine. | ||
|
Pourquoi c’est important
Il s’agit du principal résultat d’une demande aboutie et d’un transfert important dans le processus Purchase to Pay. Le délai entre l’approbation et la création du PO constitue un KPI essentiel de l’efficacité des achats.
Où les obtenir
Cet événement est identifié en recherchant un enregistrement Purchase Order dont le champ « Created From », ou un champ de liaison similaire, fait référence au Purchase Requisition ID. La date de création de ce PO constitue l’horodatage de l’activité.
Collecte
Trouvez le PO dont le champ « Created From » correspond au Requisition ID et utilisez le champ « Date Created » du PO.
Type d’événement
explicit
|
|||
|
Demande clôturée
|
La demande est officiellement clôturée, ce qui indique qu’aucune action supplémentaire n’est attendue. Cette clôture intervient souvent automatiquement après la commande de toutes les quantités de la demande au moyen de bons de commande associés. | ||
|
Pourquoi c’est important
Cette activité marque la fin définitive du cycle de vie de la demande. Elle confirme que le besoin de l’entreprise a été traité et que l’enregistrement est finalisé.
Où les obtenir
Cette étape est déduite du sous-onglet System Notes, en identifiant l’horodatage auquel le champ « Status », au niveau de la ligne ou de l’en-tête, est mis à jour avec la valeur « Closed ».
Collecte
Horodatage du changement du champ « Status » à « Closed ».
Type d’événement
inferred
|
|||
|
Demande créée
|
Un utilisateur lance le processus d’approvisionnement en créant et en enregistrant une nouvelle demande d’achat. Il s’agit du premier événement du cycle de vie de la demande, enregistré lors de la première sauvegarde de la transaction dans NetSuite. | ||
|
Pourquoi c’est important
Cette activité marque le début officiel du processus d’approvisionnement pour un besoin donné. L’analyse du délai entre la création et la soumission peut révéler des retards de saisie ou de formulation initiale de la demande.
Où les obtenir
Cet événement est enregistré à partir de l’horodatage de création de la transaction Purchase Requisition. Il figure généralement dans l’en-tête principal de l’enregistrement ou dans le sous-onglet System Notes, qui consigne l’action « Create ».
Collecte
Utilisez le champ « Date Created » de l’enregistrement Purchase Requisition.
Type d’événement
explicit
|
|||
|
Demande définitivement rejetée
|
La demande d’achat est définitivement rejetée et ne sera pas traitée davantage. Cet événement est déduit lorsque le champ « Approval Status » final de la demande est mis à jour avec la valeur « Rejected ». | ||
|
Pourquoi c’est important
Cette activité constitue le point final d’une demande non aboutie. Comprendre pourquoi et quand les demandes sont définitivement rejetées fournit des indications sur la conformité aux politiques et les problèmes budgétaires.
Où les obtenir
Cette étape est déduite du sous-onglet System Notes, en identifiant l’horodatage auquel le champ « Approval Status » prend sa valeur finale « Rejected ».
Collecte
Horodatage du changement de « Approval Status » à « Rejected ».
Type d’événement
inferred
|
|||
|
Demande entièrement approuvée
|
La demande d’achat termine avec succès toutes les étapes requises du flux de travail d’approbation. Cette étape est déduite lorsque l’« Approval Status » final de l’enregistrement passe à « Approved ». | ||
|
Pourquoi c’est important
Il s’agit d’une étape majeure, qui indique que la demande peut être convertie en bon de commande. Elle marque la fin du cycle d’approbation et le début de la phase d’exécution de l’approvisionnement.
Où les obtenir
Cette étape est déduite du sous-onglet System Notes, en identifiant l’horodatage auquel le champ « Approval Status » prend sa valeur finale « Approved ».
Collecte
Horodatage du changement de « Approval Status » à « Approved ».
Type d’événement
inferred
|
|||
|
Demande modifiée
|
Un utilisateur modifie un champ de la demande d’achat après sa création initiale, souvent à la suite d’un rejet ou d’une évolution des besoins. Cet événement est enregistré directement dans la piste d’audit de NetSuite. | ||
|
Pourquoi c’est important
Le suivi des modifications est essentiel pour identifier les boucles de reprise et les problèmes de qualité des données. Une fréquence élevée de modifications peut signaler des exigences initiales peu claires ou un besoin de formation des demandeurs.
Où les obtenir
Cet événement est enregistré dans le sous-onglet System Notes de l’enregistrement Purchase Requisition. Chaque entrée dont le champ « Type » indique « Change » ou « Edit » sur un champ pertinent représente une modification.
Collecte
Enregistrez un événement pour chaque entrée de type « Change » dans le journal System Notes.
Type d’événement
explicit
|
|||
|
Demande retirée
|
Le demandeur initial ou un administrateur annule la demande avant son approbation complète ou sa conversion en bon de commande. Cette étape est généralement déduite d’un changement de statut vers « Cancelled » ou « Withdrawn ». | ||
|
Pourquoi c’est important
Cette activité représente une exception ou l’arrêt du processus à l’initiative du demandeur. L’analyse des retraits peut mettre en évidence une évolution des besoins de l’entreprise ou des demandes qui ne sont plus valides.
Où les obtenir
Cette étape est déduite du sous-onglet System Notes, en suivant l’horodatage auquel le champ « Approval Status » est mis à jour avec une valeur telle que « Cancelled » ou un statut personnalisé de retrait.
Collecte
Horodatage du changement de « Approval Status » à « Cancelled » ou « Withdrawn ».
Type d’événement
inferred
|
|||
|
Demande soumise pour approbation
|
Le demandeur soumet officiellement la demande d’achat complétée dans le flux de travail d’approbation désigné. Cette étape est souvent déduite d’un changement de statut de l’enregistrement de la demande, par exemple de « Draft » ou « Pending Submission » à « Pending Approval ». | ||
|
Pourquoi c’est important
Cette activité déclenche le cycle d’approbation et constitue le point de départ pour mesurer les délais d’approbation. Elle permet de déterminer combien de temps les demandes attendent avant le début officiel du processus d’approbation.
Où les obtenir
Cette étape est déduite du sous-onglet System Notes, en identifiant l’horodatage auquel le champ « Approval Status » prend pour la première fois une valeur telle que « Pending Approval ».
Collecte
Identifiez le premier horodatage auquel le champ « Approval Status » prend la valeur « Pending Approval ».
Type d’événement
inferred
|
|||
|
Étape d’approbation approuvée
|
Un utilisateur autorisé approuve l’étape qui lui est affectée dans le flux de travail, rapprochant ainsi la demande de l’approbation finale. La plateforme SuiteApprovals de NetSuite enregistre explicitement cette action avec les informations relatives à l’utilisateur et à l’horodatage. | ||
|
Pourquoi c’est important
Cette activité représente une progression positive dans la chaîne d’approbation. L’analyse du délai entre les étapes d’approbation aide à comprendre l’efficacité du flux de travail et de chaque approbateur.
Où les obtenir
Cet événement est enregistré dans le journal SuiteApprovals ou dans le sous-onglet System Notes, qui consigne l’action d’approbation, l’approbateur et l’horodatage exact.
Collecte
Identifiez les actions d’approbation dans le journal SuiteApprovals ou dans System Notes.
Type d’événement
explicit
|
|||
|
Étape d’approbation démarrée
|
La demande d’achat entre dans une étape précise du flux de travail d’approbation et attend l’intervention d’un approbateur ou d’un groupe désigné. Cette étape est généralement déduite lorsque le flux de travail affecte la demande à l’approbateur suivant de la séquence. | ||
|
Pourquoi c’est important
Cette activité marque le début du temps d’attente de chaque étape d’approbation. Elle est essentielle pour localiser les goulots d’étranglement dans la hiérarchie d’approbation et identifier les approbateurs les plus lents.
Où les obtenir
Cette étape est déduite des journaux d’exécution du flux de travail ou des changements apportés à un champ « Current Approver » ou à un champ d’état du flux de travail. La plateforme SuiteApprovals suit l’étape d’approbation active.
Collecte
Déduisez cette étape des journaux du flux de travail ou lorsque l’enregistrement est affecté à un nouvel approbateur.
Type d’événement
inferred
|
|||
|
Étape d’approbation rejetée
|
Un approbateur rejette l’étape qui lui est affectée, ce qui renvoie généralement la demande au demandeur pour correction. Cette action est enregistrée explicitement par le moteur de flux de travail SuiteApprovals. | ||
|
Pourquoi c’est important
Cet événement est un indicateur important de reprise et d’inefficacité du processus. L’analyse des points de rejet permet d’identifier les causes fréquentes d’échec, comme le non-respect des politiques ou des données incorrectes.
Où les obtenir
Cet événement est enregistré dans le journal SuiteApprovals ou dans le sous-onglet System Notes, qui consigne l’action de rejet, l’utilisateur l’ayant effectuée et l’horodatage.
Collecte
Identifiez les actions de rejet dans le journal SuiteApprovals ou dans System Notes.
Type d’événement
explicit
|
|||
Guides d’extraction
Prêt à commencer ?
Utilisez ce modèle pour commencer votre démarche de Process Mining et obtenir des analyses utiles sur votre processus Purchase to Pay, Requisition dans NetSuite. Commencez dès aujourd’hui à optimiser son efficacité et à accélérer les approbations.
Optimisez votre Purchase to Pay - Requisition dès aujourd’hui !
Obtenez des approbations de demandes 30 % plus rapides et éliminez les goulots d’étranglement.
Aucune carte bancaire requise. Commencez à optimiser vos processus dès aujourd’hui.