Votre Modèle de Données de Demandes d'Achat – Du Bon de Commande au Paiement

Event Time est l'horodatage qui enregistre le moment où une activité a eu lieu. Ces données sont essentielles pour l'ordonnancement chronologique des événements au sein d'un cas et constituent la base de tous les calculs de durée et de performance en process mining. Par exemple, la différence de temps entre les événements 'Demande soumise' et 'Demande approuvée' détermine le temps de cycle d'approbation.

Des horodatages précis sont essentiels pour analyser les performances des processus, identifier les retards et surveiller le respect des accords de niveau de service. Cet attribut permet des dashboards qui visualisent les temps de cycle, suivent les demandes bloquées et comparent les performances sur différentes périodes.

Cet horodatage est essentiel pour ordonner les événements, calculer les temps de cycle et analyser la performance des processus ainsi que les goulots d'étranglement.

Les timestamps proviennent généralement des en-têtes de documents de modification (CDHDR-UDATE, CDHDR-UTIME) ou des journaux d'événements de workflow.

L'ID de la Demande d'Achat est la clé primaire qui identifie de manière unique chaque demande de biens ou services au sein de SAP S/4HANA. Il sert d'identifiant central de cas, reliant toutes les activités et modifications liées à une demande spécifique, de sa création à son état final, comme l'approbation, le rejet ou la conversion en commande d'achat.

En process mining, cet attribut est fondamental pour reconstituer le cycle de vie de bout en bout de chaque demande. En regroupant tous les événements associés sous un seul ID de Demande d'Achat, les analystes peuvent mesurer avec précision les temps de cycle, suivre les changements de statut et analyser les différents chemins qu'une demande peut emprunter à travers le processus d'approbation.

C'est l'identifiant de cas essentiel qui relie toutes les étapes de processus connexes, permettant une vue complète et cohérente du cycle de vie de la demande.

Cet attribut est le Numéro de Demande d'Achat, trouvé dans la table EBAN, champ BANFN.

Le nom de l'activité décrit un événement ou une tâche spécifique qui a eu lieu 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 de workflow, et représentent des étapes clés du processus comme « Demande créée », « Étape d'approbation démarrée » ou « Commande d'achat créée ».

L'analyse de ces activités permet la visualisation du flux de processus, l'identification des goulots d'étranglement et la mesure du temps passé dans différentes étapes. Comprendre la séquence et la fréquence d'activités comme « Demande modifiée » ou « Demande rejetée » est crucial pour identifier les inefficacités du processus et les pistes d'amélioration.

Il définit les étapes du processus, formant l'épine dorsale de la carte de processus et permettant l'analyse du flux de processus, des variations et des goulots d'étranglement.

C'est un attribut dérivé, généralement construit en interprétant les données des tables de documents de modification (CDHDR, CDPOS) et des journaux de workflow (par exemple, SWWLOGHIST).

L'attribut Département, souvent représenté par le Centre de Coût dans SAP, identifie l'unité commerciale responsable de l'achat demandé. C'est une information financière et organisationnelle critique, attribuée au niveau de la ligne de la demande.

En process mining, cet attribut est essentiel pour l'analyse de la performance départementale. Il alimente les tableaux de bord qui comparent des métriques clés comme le temps de cycle, les taux de modification et les taux de rejet entre différents départements. Cela aide à identifier les départements très performants dont les pratiques pourraient être adoptées ailleurs, ainsi que ceux qui pourraient nécessiter une formation ou un soutien processuel supplémentaire.

Permet la comparaison des performances entre les unités commerciales, mettant en évidence les variations des temps de cycle ou des taux de rejet afin d'identifier les meilleures pratiques et les domaines d'amélioration.

C'est le Centre de Coût, généralement trouvé dans la table d'imputation EBKN, champ KOSTL.

L'ID de l'approbateur identifie spécifiquement l'utilisateur qui a complété une activité d'approbation ou de rejet. Il se distingue de l'ID utilisateur général car il se concentre uniquement sur les décideurs au sein du workflow d'approbation. La capture de cette information est vitale pour analyser en détail le processus d'approbation.

Cet attribut permet l'analyse du comportement d'approbation, comme l'identification des managers avec des délais d'approbation longs ou ceux qui rejettent fréquemment des demandes d'achat. Il est fondamental pour les tableaux de bord axés sur les temps de cycle des étapes d'approbation et l'analyse des goulots d'étranglement du workflow, aidant à localiser les individus ou rôles spécifiques qui pourraient causer des retards.

Désigne le décideur spécifique d'une étape d'approbation, permettant une analyse détaillée des temps de cycle d'approbation et des goulots d'étranglement par individu ou par rôle.

Cette information est généralement extraite des tables SAP Business Workflow comme SWW_WI2OBJ et SWWLOGHIST, qui lient les éléments de travail à l'utilisateur qui les a complétés.

L'ID Utilisateur identifie l'employé ou l'utilisateur système responsable d'un événement particulier dans le cycle de vie de la demande d'achat. Il peut s'agir de la personne qui a créé la demande, du manager qui l'a approuvée ou de l'agent qui l'a modifiée. Dans les cas d'étapes automatisées, il peut s'agir d'un ID d'utilisateur système ou batch.

L'analyse par ID Utilisateur aide à comprendre le comportement spécifique des utilisateurs, la distribution de la charge de travail et la performance. Elle est essentielle pour identifier les besoins en formation, reconnaître les individus performants et assurer la responsabilisation au sein du processus. Elle soutient également l'analyse de la performance départementale lorsqu'elle est combinée avec les données de base des utilisateurs.

Permet l'analyse des performances des utilisateurs, de la répartition de la charge de travail et de la conformité des processus. Il est crucial pour identifier les opportunités de formation et les goulots d'étranglement en matière de ressources.

Trouvé dans EBAN-ERNAM pour le créateur. Pour les modifications ultérieures, c'est dans CDHDR-USERNAME. Pour les approbations, c'est dans les journaux de workflow.

Le Montant de la Demande d'Achat représente le coût total estimé des biens ou services demandés. Cette valeur est souvent un facteur clé pour déterminer la complexité et la durée du workflow d'approbation, les demandes de valeur plus élevée nécessitant généralement plus de niveaux d'approbation.

L'analyse de cet attribut permet une segmentation du processus basée sur la valeur. Elle peut aider à répondre à des questions telles que : « Les demandes de grande valeur prennent-elles plus de temps à approuver ? » ou « Quelle est la valeur des demandes qui sont fréquemment rejetées ? ». C'est une dimension critique pour comprendre l'impact financier des inefficacités du processus.

Aide à segmenter le processus par impact financier, souvent en corrélation avec la complexité d'approbation et le temps de cycle. C'est vital pour l'analyse de processus basée sur la valeur.

La valeur totale se trouve dans la table EBAN, champ GFWERT. La valeur au niveau de l'article est dans EBAN-PREIS.

Le Statut de la Demande d'Achat indique l'état actuel de la demande au sein de son cycle de vie. Dans SAP, il est souvent représenté par l'Indicateur de déblocage, qui montre si une demande est bloquée, en cours d'approbation, partiellement approuvée ou entièrement approuvée. Ce statut change à mesure que la demande progresse dans le workflow.

Le suivi du statut au fil du temps est fondamental pour comprendre le flux de processus. Il aide à identifier où les demandes se bloquent et pendant combien de temps. L'analyse des transitions entre les statuts permet une vue détaillée du processus d'approbation et de ses variantes.

Indique l'état actuel d'une demande d'achat, ce qui est essentiel pour suivre les progrès, identifier les goulots d'étranglement et analyser le flux de processus.

Le statut de déblocage est souvent déterminé par l'Indicateur de déblocage, trouvé dans la table EBAN, champ FRGZU.

Le Type de Demande d'Achat, également connu sous le nom de Type de Document dans SAP, est un champ de configuration clé qui catégorise les demandes d'achat. Différents types peuvent déclencher des workflows d'approbation différents, avoir des paramètres de champ différents et être utilisés à des fins commerciales distinctes, telles que les articles en stock standard, les services externes ou les achats d'actifs.

En analysant le processus basé sur le Type de Demande d'Achat, les organisations peuvent comprendre comment les différents types de requêtes sont gérés. Cela permet de comparer les performances, les temps de cycle et les chemins d'approbation entre les catégories, ce qui peut révéler si certains types de demandes sont plus ou moins efficaces et aider à adapter les améliorations de processus.

Catégorise les demandes d'achat pour permettre une analyse comparative, aidant à comprendre si différents types de demandes ont des flux de processus, des goulots d'étranglement ou des temps de cycle différents.

C'est le champ Type de Document, trouvé dans la table EBAN, champ BSART.

La Date Requise, ou Date de Livraison dans SAP, spécifie quand les biens ou services de la ligne de la demande d'achat sont nécessaires. Cette date est définie par le demandeur et sert d'objectif pour l'ensemble du processus d'approvisionnement.

Cet attribut est essentiel pour calculer le KPI « Taux de conformité des demandes d'achat livrées à temps ». En comparant la Date Requise avec la date d'approbation finale ou de création de la commande d'achat, l'organisation peut mesurer sa capacité à respecter les niveaux de service internes et les besoins commerciaux. L'analyse des demandes qui ne respectent pas cette date peut mettre en évidence des retards systémiques dans le processus d'approvisionnement.

Définit la date de fin cible pour une demande, permettant de mesurer la livraison à temps et le respect des niveaux de service internes.

C'est la Date de Livraison, trouvée au niveau de l'article dans la table EBAN, champ LFDAT.

Cet attribut enregistre la date et l'heure de la plus récente extraction ou mise à jour des données du système source. C'est une pièce critique de métadonnées pour comprendre la fraîcheur des données analysées. Les analystes et les utilisateurs métier se fient à ce timestamp pour savoir si les données du processus reflètent l'état le plus actuel des opérations.

Dans toute analyse de processus, connaître l'actualité des données est fondamental pour prendre des décisions éclairées. Cet attribut aide à gérer les attentes des utilisateurs et garantit que les conclusions sont tirées de données aussi à jour que nécessaire pour l'analyse spécifique.

Indique la fraîcheur des données, ce qui est crucial pour faire confiance à l'analyse et prendre des décisions commerciales opportunes.

Ce timestamp est généré et ajouté pendant le processus d'extraction, de transformation et de chargement des données (ETL).

Cet attribut spécifie la devise dans laquelle le montant de la demande d'achat est libellé, par exemple, USD, EUR ou JPY. Il fournit le contexte nécessaire à l'attribut Montant de la Demande d'Achat, particulièrement dans les organisations multinationales qui opèrent avec plusieurs devises.

Pour une analyse financière et un reporting précis, il est essentiel de prendre en compte la devise. Lors de l'agrégation ou de la comparaison des valeurs de demande, tous les montants doivent être convertis en une devise commune pour garantir des résultats significatifs. Cet attribut est un prérequis pour de telles conversions.

Fournit un contexte essentiel pour le montant de la demande d'achat, permettant une analyse financière précise et des comparaisons dans des environnements multi-devises.

Ceci se trouve dans la table EBAN, champ WAERS.

L'attribut Est Automatisé est un indicateur booléen qui est vrai si une activité a été exécutée par un système ou un utilisateur batch, tel que « WF-BATCH » pour les actions de workflow. Cela permet de distinguer les étapes manuelles des étapes automatisées dans le processus.

Cet attribut est essentiel pour mesurer le niveau d'automatisation dans le processus de demande d'achat et pour calculer le KPI « Taux d'approbation automatisée ». En filtrant les étapes automatisées ou manuelles, les analystes peuvent comparer leur efficacité et identifier les opportunités d'automatisation supplémentaire pour réduire les temps de traitement et l'effort manuel.

Distingue les activités humaines des activités système, ce qui est essentiel pour mesurer les taux d'automatisation et identifier les opportunités d'automatisation des tâches manuelles.

C'est un attribut dérivé, généralement basé sur une règle qui vérifie si l'ID utilisateur d'un événement appartient à une liste d'utilisateurs système ou batch connus.

Is Rework (Est une retouche) est un indicateur booléen calculé qui identifie les activités représentant un travail sans valeur ajoutée ou répétitif. Un exemple courant dans ce processus est l'activité "Demande modifiée" qui se produit après que la demande a déjà été soumise pour approbation, forçant le processus d'approbation à redémarrer.

Cet attribut est crucial pour quantifier le volume de retouches dans le processus et son impact sur les temps de cycle globaux. Le tableau de bord "Taux de modification et de retouche des demandes" s'appuie sur cet indicateur pour mettre en évidence les inefficacités du processus. La réduction des retouches est souvent un objectif principal des initiatives d'amélioration des processus, car elle se traduit directement par un gain de temps et d'efforts.

Signalise les activités qui représentent un effort inutile ou une répétition, permettant la mesure directe des retouches et de leur impact sur l'efficacité du processus.

C'est un attribut calculé. La logique signalerait généralement comme retravail toute activité « Demande modifiée » survenant après la première activité « Demande soumise à approbation ».

EndTime est l'horodatage qui enregistre la fin d'une activité. Alors que de nombreux événements générés par le système sont instantanés (ce qui signifie que StartTime est égal à EndTime), les tâches humaines comme les approbations peuvent avoir un début et une fin distincts. Cet horodatage marque l'achèvement de ce travail.

Avoir un EndTime séparé permet une mesure plus précise du temps de traitement actif par rapport au temps d'attente inactif. Il est utilisé conjointement avec StartTime pour calculer la métrique ProcessingTime. Ce niveau de détail améliore l'analyse de l'utilisation des ressources et de l'efficacité pour les tâches manuelles.

Marque l'achèvement d'une activité, permettant le calcul du temps de traitement actif et offrant une vue plus détaillée de la durée de la tâche.

Ceci est dérivé des journaux de workflow qui peuvent capturer à la fois la date et l'heure de création d'un élément de travail (StartTime) et sa date et heure d'achèvement (EndTime).

La Raison du Rejet explique pourquoi un approbateur a décidé de rejeter une demande d'achat. Les raisons peuvent inclure un dépassement de budget, des informations incorrectes, une non-conformité à la politique ou la duplication d'une autre demande. Cette information fournit un contexte crucial pour comprendre les échecs du processus.

L'analyse des raisons de rejet aide à identifier les causes profondes des inefficacités du processus et du retravail. Par exemple, si « Centre de Coût Incorrect » est une raison courante, cela indique un besoin d'amélioration de la formation des utilisateurs ou de la validation du système. Cet attribut est la clé du tableau de bord d'Analyse des Rejets de Demandes et est vital pour une amélioration ciblée des processus.

Fournit la cause première des échecs de processus, permettant des améliorations ciblées pour réduire les retouches et augmenter le taux de "juste du premier coup" des demandes.

Ce n'est souvent pas un champ standard. Il peut être capturé dans des éléments de conteneur de workflow, du texte long associé à la demande ou des champs personnalisés.

Le Niveau d'Urgence indique la priorité de la demande d'achat. Bien qu'il ne s'agisse pas d'un champ standard dédié, certaines organisations utilisent des champs comme le Numéro de Suivi des Besoins pour capturer cette information. Cela permet aux demandeurs de signaler les besoins critiques qui peuvent nécessiter un traitement accéléré.

L'analyse de l'impact de l'urgence est importante pour évaluer si le processus priorise efficacement les demandes critiques. Le tableau de bord d'Analyse d'Impact du Niveau d'Urgence utilise cet attribut pour comparer les temps de cycle et les taux d'approbation des demandes urgentes par rapport aux demandes standard, aidant ainsi à déterminer si la gestion des priorités fonctionne comme prévu.

Permet d'analyser comment la performance du processus diffère pour les demandes de haute priorité, aidant à valider si les articles urgents sont réellement traités plus rapidement.

Il n'existe pas de champ d'urgence standard. Certaines entreprises utilisent le Numéro de Suivi des Besoins (EBAN-BEDAR) à cette fin. Il peut également s'agir d'un champ personnalisé.

Le nom de l'étape d'approbation offre une description lisible par l'homme d'une étape particulière du workflow d'approbation, telle que « Approbation du Responsable » ou « Approbation du VP Finance ». Ceci est plus descriptif qu'une activité générique telle que « Étape d'approbation terminée ».

Cet attribut est essentiel pour les tableaux de bord d'analyse du temps de cycle des étapes d'approbation et des goulots d'étranglement du workflow. Il permet une vue granulaire du processus d'approbation, rendant possible d'identifier précisément quelles étapes d'approbation sont à l'origine des délais les plus significatifs et où le travail s'accumule. Ce niveau de détail est nécessaire pour des interventions ciblées visant à rationaliser la chaîne d'approbation.

Fournit des détails granulaires sur les étapes d'approbation, permettant une identification précise des goulots d'étranglement au sein du workflow d'approbation multi-niveaux.

Cette information est dérivée de la description de la tâche de workflow, qui peut être trouvée en liant le journal de workflow aux tables de définition des tâches comme T528T.

Le Numéro de la Commande d'Achat est l'identifiant du document d'achat officiel créé à partir d'une demande d'achat approuvée. La création d'une commande d'achat est souvent l'aboutissement final et réussi d'une demande, signifiant que la requête a été convertie en une commande formelle auprès d'un fournisseur.

Cet attribut est crucial pour mesurer le KPI « Délai de la Demande à la Commande d'Achat » et le taux de conversion global. Il relie le processus de demande au processus d'approvisionnement en aval, permettant une vue plus large et de bout en bout de l'ensemble du cycle Purchase-to-Pay.

Lie la demande d'achat au document d'approvisionnement ultérieur, permettant la mesure du taux de conversion demande-commande d'achat et du délai.

Trouvé dans la table EBAN, champ EBELN, une fois qu'une commande d'achat (PO) a été créée à partir de l'article de demande d'achat.

L'attribut Système Source indique le système d'origine où les données de processus ont été générées. Dans les organisations avec plusieurs instances SAP, telles que des systèmes différents pour le développement, l'assurance qualité et la production, ou des systèmes distincts pour différentes régions, ce champ est crucial pour la gouvernance des données et le contexte.

Il garantit que les données provenant de différentes sources peuvent être distinguées, évitant ainsi une agrégation incorrecte et permettant une analyse spécifique au système. C'est un attribut obligatoire pour maintenir la lignée des données et assurer la traçabilité des données de processus.

Fournit un contexte essentiel pour l'origine et la gouvernance des données, en particulier dans les environnements multi-systèmes, assurant la traçabilité des données.

Ceci est typiquement l'ID Système SAP (SID), qui peut être récupéré à partir des variables système ou des tables de configuration.

Le Processing Time (Temps de traitement) mesure le temps qu'il a fallu pour accomplir une seule activité. Il est calculé comme la différence entre l'heure de fin et l'heure de début d'un événement. Pour de nombreux événements dans SAP, les heures de début et de fin sont les mêmes, ce qui donne un temps de traitement nul. Cependant, pour les étapes d'approbation, il peut représenter le temps qu'un approbateur a passé à travailler sur la tâche.

Cette métrique calculée est utile pour comprendre l'effort impliqué dans les différentes étapes du processus. Elle peut aider à distinguer le temps d'attente d'un cas (wait time) du temps où il est activement traité (processing time), offrant une vue plus nuancée de la performance du processus.

Mesure le temps de travail actif pour une activité, aidant à distinguer le temps passé à travailler du temps passé à attendre, ce qui est essentiel pour l'analyse des ressources.

C'est un attribut calculé, généralement dérivé en soustrayant StartTime de EndTime pour chaque événement dans le journal d'événements.