Votre modèle de données pour le traitement des retours et des remboursements

L’heure de l’événement, ou son horodatage, indique la date et l’heure exactes auxquelles une activité a eu lieu. Chaque activité du journal d’événements est associée à un horodatage, qui établit l’ordre chronologique des événements.

Cet attribut est indispensable à toute analyse du processus fondée sur le temps. Il sert à calculer les temps de cycle entre les activités, à repérer les temps d’attente et les goulots d’étranglement, à mesurer la durée totale des dossiers et à vérifier le respect des accords de niveau de service (SLA). La fiabilité de toute analyse des performances dépend directement de la précision des horodatages.

Cet horodatage est indispensable au calcul des indicateurs de durée, comme les temps de cycle et les temps d’attente, qui sont essentiels à l’analyse des performances.

Correspond aux champs de date de création ou de modification de différentes tables, par exemple « SalesTable.createdDateTime » pour la création d’une commande ou « WMSJournalTrans.createdDateTime » pour les journaux d’entrepôt.

L’identifiant du dossier de retour est l’identifiant principal de chaque instance de processus de retour. Il relie toutes les activités associées à un retour ou à une demande de remboursement spécifique, depuis la création initiale de la commande de retour jusqu’à sa clôture.

Dans l’analyse des processus, cet identifiant est indispensable pour reconstituer le parcours complet de chaque retour. Il permet de suivre tout le cycle de vie, de mesurer les temps de cycle totaux et d’analyser les différences entre les dossiers. Tous les événements, les données et les indicateurs sont regroupés et mis en relation à l’aide de cet identifiant.

Cet identifiant de dossier essentiel relie toutes les étapes du processus et permet de suivre et d’analyser chaque retour du début à la fin.

Il s’agit généralement du numéro d’autorisation de retour de marchandise (RMA) ou du numéro de commande client de type « Returned Order » dans le module « Sales and marketing ». Il se trouve dans des tables comme « SalesTable », où « SalesType » correspond à « Returned Order ».

Cet attribut décrit une étape ou un événement précis du cycle de vie d’un retour et d’un remboursement, par exemple « Commande de retour créée », « Article reçu » ou « Note de crédit validée ». Chaque activité correspond à une étape distincte du processus, enregistrée dans le système.

L’analyse de l’ordre et de la fréquence de ces activités est au cœur du Process Mining. Elle permet de représenter les processus, de repérer les goulots d’étranglement entre les étapes et de découvrir les variantes courantes ou inhabituelles. L’ensemble des activités délimite le périmètre du processus analysé.

Il définit les étapes du processus et permet d’en représenter le déroulement, ainsi que de repérer les goulots d’étranglement, les reprises et les écarts.

Il s’agit d’un attribut conceptuel déduit des événements du système. Il peut être généré en associant les changements de statut dans des tables comme « SalesTable » et « WMSJournalTable », ou des journaux d’événements spécifiques, à des noms faciles à comprendre.

Cet attribut indique le canal utilisé par le client pour lancer le processus de retour, par exemple « Portail en ligne », « En magasin », « Appel au service client » ou « Courrier postal ».

L’analyse du processus par canal de retour permet d’évaluer les performances et l’efficacité de chacun. Une entreprise peut comparer les temps de cycle, les coûts et la satisfaction client entre les différents canaux afin de repérer les bonnes pratiques et les domaines où investir ou apporter des améliorations. Cet attribut est essentiel au Dashboard « Performance d’utilisation des canaux de retour ».

Permet de comparer les performances des différents canaux de retour et de repérer ceux qui sont les plus efficaces et les plus économiques.

Cette information peut être enregistrée dans l’en-tête de la commande de retour (« SalesTable ») ou déduite de l’utilisateur qui a créé la commande. Une logique personnalisée ou un champ dédié peut être nécessaire.

Le code de décision est attribué lors du contrôle qualité d’un article retourné. Il détermine l’étape suivante du processus, par exemple « Credit », « Replace », « Scrap » ou « Return to Customer ».

Cet attribut correspond à un point de décision important dans le processus de retour. L’analyse par code de décision permet aux entreprises de comprendre l’issue des retours, de suivre les conséquences financières de la mise au rebut des articles et d’évaluer l’efficacité des différentes options de résolution, comme le remplacement ou le remboursement.

Ce code détermine le parcours suivi par un dossier de retour après inspection. Il est donc essentiel pour analyser les variantes du processus et leurs conséquences pour l’entreprise.

Ce champ joue un rôle clé dans le module de gestion de la qualité. Il est associé au traitement des ordres de qualité ou d’inspection.

Le code du motif de retour enregistre la raison invoquée par le client, par exemple « Article défectueux », « Taille incorrecte », « Non conforme à la description » ou « N’est plus nécessaire ». Cette information est généralement recueillie au moment où le retour est demandé.

L’analyse des motifs de retour est essentielle pour en déterminer les causes profondes. Elle aide les entreprises à repérer les problèmes de qualité des produits, les descriptions inexactes ou les erreurs logistiques. Ces données peuvent orienter les améliorations de la conception des produits, du marketing et de la chaîne d’approvisionnement afin de réduire les retours à l’avenir.

Permet de comprendre les raisons des retours et d’en rechercher les causes profondes afin de réduire leur fréquence et d’améliorer la satisfaction client.

Cette information est généralement enregistrée au niveau de la ligne de commande de retour. Recherchez les champs de code de motif dans la table « SalesLine » des commandes de retour.

L’ID du produit, souvent appelé unité de gestion des stocks (SKU), identifie précisément l’article retourné par le client. Chaque ligne de commande de retour est associée à un ID de produit.

L’analyse des retours par produit est essentielle pour repérer les articles dont le taux de retour est élevé. Cela peut révéler des problèmes de contrôle qualité, des descriptions inexactes ou des défauts de fabrication. Cette analyse aide à prioriser les enquêtes et les améliorations liées aux produits.

Permet d’analyser les retours par produit et de repérer les articles présentant des problèmes de qualité ou un volume élevé de retours.

Correspond au champ « ItemId » de la table « SalesLine » pour la commande de retour.

Cet attribut identifie la personne responsable de l’exécution d’une étape du processus. Il peut s’agir de l’employé de l’entrepôt qui a réceptionné l’article, de l’inspecteur qualité ou du comptable qui a validé la note de crédit.

L’analyse du processus par utilisateur permet de comprendre la répartition de la charge de travail, de repérer les personnes les plus performantes et de détecter les besoins de formation. Elle peut également servir à examiner les dossiers traités par certaines personnes ou équipes et à vérifier la séparation des tâches.

Il permet d’analyser la répartition de la charge de travail et les performances par personne ou par équipe, ainsi que de repérer les besoins de formation et les possibilités de réaffectation des ressources.

Ces informations figurent dans les champs « created by » ou « modified by » des enregistrements de transaction, par exemple « SalesTable.createdBy » ou les identifiants utilisateur associés dans les tables de journaux.

Cet attribut booléen calculé indique si un retour respecte tous les critères définis dans la politique de retour de l’entreprise. Il peut tenir compte de facteurs tels que le délai de retour, l’état de l’article ou le motif du retour.

Cet attribut alimente directement le Dashboard « Vue d’ensemble de la conformité des approbations de retour » et l’indicateur de performance clé « Taux d’approbation des retours conformes ». Il permet à l’entreprise de mesurer le respect des règles, de repérer les dossiers approuvés à titre exceptionnel et d’analyser les motifs et la fréquence de ces exceptions. Il est essentiel à la gouvernance et à la maîtrise des coûts.

Mesure directement le respect des règles de l’entreprise et aide à repérer et à réduire les approbations de retour non conformes, susceptibles d’entraîner une perte de revenus.

Il s’agit d’un attribut dérivé. Sa logique doit comparer les attributs du retour, par exemple la date de retour par rapport à la date d’achat ou le motif du retour, aux règles métier prédéfinies.

Cet attribut définit l’échéance de l’accord de niveau de service (SLA) pour la résolution d’un dossier de retour. À cette date, le client doit avoir obtenu une réponse définitive, par exemple un remboursement validé ou l’expédition d’un article de remplacement.

Cette date cible est essentielle au suivi des engagements de service. Elle sert à calculer l’indicateur de performance clé « Taux de respect du SLA de résolution » et alimente le Dashboard « Performance du SLA de résolution des remboursements ». En comparant cette date à la date réelle de fin du processus, l’entreprise peut repérer les dépassements de SLA et prendre en charge de manière proactive les dossiers en attente depuis longtemps.

Sert de référence pour mesurer les performances du processus, suivre le respect du SLA et repérer les dossiers en retard.

Il ne s’agit pas nécessairement d’un champ standard. Cette date est souvent calculée en ajoutant une période de SLA prédéfinie à la date de création du retour, par exemple 14 jours. Elle peut être enregistrée dans un champ personnalisé.

Cet attribut indique la date et l’heure de la dernière extraction des données du système source et de leur mise à jour dans l’outil de Process Mining. Il permet de savoir à quel moment les données analysées étaient à jour.

Connaître la date de la dernière mise à jour aide à évaluer l’actualité de l’analyse. Les utilisateurs peuvent ainsi interpréter correctement les Dashboards et les KPI, en sachant s’ils consultent des données en temps réel ou un instantané datant d’un moment précis. C’est essentiel au suivi opérationnel.

Indique si les données sont à jour et permet aux analystes de savoir à quel point leurs analyses du processus sont récentes.

Il s’agit d’un attribut de métadonnées généré et stocké pendant le processus d’intégration des données. Il correspond généralement à l’horodatage de fin du traitement ETL.

L’heure de fin correspond à l’horodatage d’achèvement d’une activité. Alors que StartTime indique le début, EndTime marque la fin et permet de calculer la durée de traitement de la tâche concernée.

Cet attribut est essentiel à l’analyse détaillée des performances, en particulier pour les tâches dont la durée peut être mesurée, comme « Inspection de l’article ». En comparant StartTime et EndTime, les analystes peuvent mesurer précisément le temps de traitement actif des tâches et le distinguer du temps d’attente entre les tâches. Ils peuvent ainsi repérer les inefficacités au sein d’activités précises, et pas seulement entre elles.

Il permet de calculer le temps de traitement actif de chaque activité et de distinguer le temps d’attente du temps de travail effectif.

Cette valeur doit souvent être déduite. Il peut s’agir, par exemple, du champ « modifiedDateTime » correspondant au changement de statut qui clôt une activité, ou de StartTime pour l’activité suivante.

Lorsqu’un remboursement est traité, un document financier appelé avoir est généré. Cet attribut enregistre l’identifiant unique de ce document.

Cet identifiant relie directement le processus opérationnel de retour aux écritures financières du système comptable. Il est utile pour les audits et l’examen détaillé des écarts financiers : l’analyste peut suivre un dossier de retour jusqu’à la transaction financière précise qui l’a réglé.

Relie le processus opérationnel de retour à la transaction financière correspondante, ce qui est essentiel pour les audits et le rapprochement financier.

Le numéro de l’avoir figure généralement dans le champ « InvoiceId » de la table « CustInvoiceJour », lorsque le type de transaction est « Credit note ». Il peut être relié à la commande de retour.

Cet attribut identifie l’entrepôt physique ou le centre de retour qui traite l’article retourné. Les processus, les ressources et les niveaux de performance peuvent varier d’un site à l’autre.

L’analyse du processus par entrepôt permet de comparer les performances des différents sites. Elle peut aider à repérer les installations qui traitent les retours le plus efficacement, à mettre en évidence les goulots d’étranglement régionaux et à orienter les décisions concernant la répartition des ressources et la standardisation des processus dans le réseau logistique.

Permet de comparer les performances des entrepôts et des centres de retour, et de repérer les goulots d’étranglement régionaux ou les bonnes pratiques.

Cette information est enregistrée dans le champ « InventLocationId » des transactions liées aux stocks, par exemple dans le journal de réception (« WMSJournalTable ») ou dans « SalesLine ».

L’ID du client est l’identifiant unique du compte client associé au retour. Il relie la transaction de retour à un client précis dans le CRM ou la base de données clients.

L’analyse des retours par client permet de repérer ceux qui retournent des articles à une fréquence inhabituelle, ce qui peut signaler un comportement frauduleux ou une insatisfaction récurrente. Elle peut également servir à segmenter la clientèle, par exemple pour proposer des services de retour premium aux clients à forte valeur.

Relie le processus de retour à un client précis, ce qui permet d’analyser les retours par client et de repérer des tendances ou une fraude potentielle.

Il s’agit du champ « CustAccount » de la table « SalesTable » pour la commande de retour.

Cet attribut correspond au montant initial du remboursement demandé ou prévu au début du processus de retour. Il est généralement calculé à partir du prix d’achat initial des articles retournés.

Cette valeur sert de référence pour l’analyse des écarts de remboursement. En la comparant au montant effectivement remboursé, l’entreprise peut repérer les écarts dus aux frais de remise en stock, aux remboursements partiels d’articles endommagés ou à d’autres ajustements. Cela permet de suivre l’exactitude financière et le respect des règles.

Sert de référence pour évaluer l’exactitude financière en le comparant au montant effectivement remboursé.

Il s’agit généralement du montant de la ligne ou du montant total de la ligne de commande de vente d’origine correspondant à l’article retourné. Cette valeur figure dans « SalesLine.LineAmount ».

Cet attribut correspond au montant final confirmé et remboursé au client. Il est enregistré lors de la création et de la validation de l’avoir.

Cet attribut est essentiel à l’analyse financière. Il est utilisé directement dans le Dashboard « Analyse des écarts de remboursement » et dans l’indicateur de performance clé « Taux d’exactitude des remboursements ». Son analyse permet de comprendre l’incidence financière des retours et les ajustements effectués au cours du processus.

Représente l’incidence financière réelle du retour. Il est essentiel pour calculer l’exactitude des remboursements et comprendre les résultats financiers.

Cette valeur figure dans les détails de la transaction de l’avoir validé. Elle est liée aux tables « CustTrans » et « CustInvoiceJour » de l’avoir.

Cet attribut indique le statut actuel de l’en-tête de la commande de retour, par exemple « Ouverte », « Facturée » ou « Annulée ». Il donne une vue d’ensemble de l’étape à laquelle se trouve le dossier.

Les activités décrivent les étapes détaillées du processus, tandis que le statut général facilite le filtrage et la segmentation des dossiers. Un analyste peut, par exemple, se concentrer sur les dossiers « Ouverts » pour comprendre la charge de travail actuelle, ou étudier le parcours des dossiers finalement « Annulés ».

Donne une vue d’ensemble de l’état du dossier, utile pour filtrer les dossiers et comprendre les résultats, notamment les annulations.

Cette information se trouve dans le champ « SalesStatus » ou « DocumentStatus » de la table « SalesTable ».

Cet attribut calculé indique simplement si le SLA a été respecté, généralement par les valeurs « Dans les délais » ou « En retard ». Il est déterminé en comparant l’horodatage de la dernière activité, par exemple « Commande de retour clôturée », à l’attribut « RefundSlaTargetDate ».

Cet attribut simplifie le suivi des performances dans des Dashboards comme « Performance du SLA de résolution des remboursements ». Au lieu de devoir comparer les dates, les utilisateurs disposent d’un statut direct et facile à comprendre. Ils peuvent ainsi filtrer et regrouper rapidement les dossiers pour calculer le « Taux de respect du SLA de résolution » global.

Fournit une indication immédiate du respect du SLA, ce qui facilite le filtrage des dossiers en retard et l’analyse des causes profondes des délais.

Il s’agit d’un attribut dérivé, calculé en comparant l’horodatage de l’activité de résolution finale à l’attribut « RefundSlaTargetDate ».

Cet attribut identifie le système d’information source des données. Dans ce contexte, il s’agira principalement de « Microsoft Dynamics 365 ».

Dans les grandes organisations, un processus peut s’étendre sur plusieurs systèmes. Préciser le système source de chaque événement est essentiel à la gouvernance des données, au diagnostic des problèmes d’extraction et à la compréhension de l’environnement technologique du processus. Cela permet de confirmer l’origine des données analysées.

Il précise l’origine des données, un contexte essentiel à leur gouvernance et à leur validation, ainsi qu’à la compréhension des systèmes utilisés dans le processus.

Il s’agit généralement d’une valeur statique ajoutée lors du processus d’extraction, de transformation et de chargement des données (ETL) pour indiquer l’origine du jeu de données.

Cet attribut classe le dossier de retour selon le type de résolution demandé par le client ou proposé par l’entreprise. Les types courants comprennent le remboursement, l’échange contre un article de remplacement ou la réparation.

Cette classification permet d’analyser les différents parcours du processus. Le traitement d’un remboursement diffère sensiblement de l’expédition d’un article de remplacement. La segmentation par type de retour permet d’analyser plus précisément les temps de cycle et les goulots d’étranglement propres à chaque parcours de résolution.

Permet de segmenter l’analyse selon le résultat prévu, car les processus de remboursement et de remplacement comportent des étapes et des temps de cycle différents.

Il peut s’agir d’un champ personnalisé de l’en-tête de la commande de retour, ou d’une valeur déduite du code de disposition ou de transactions ultérieures, comme la création d’une commande de vente de remplacement.