Votre modèle de données pour la gestion d’entrepôt
Votre modèle de données pour la gestion d’entrepôt
- Attributs recommandés pour une analyse complète
- Activités clés à suivre dans vos flux de marchandises
- Conseils pratiques pour extraire les données de Blue Yonder WMS
Attributs de gestion d’entrepôt
| Nom | Description | ||
|---|---|---|---|
| Commande d’entrepôt WarehouseOrder | Identifiant unique d’une commande d’entrepôt. Il sert de cas principal pour suivre toutes les activités logistiques associées, de la création à la clôture. | ||
| Description La commande d’entrepôt est l’identifiant central qui regroupe tous les événements et toutes les tâches liés à une demande logistique précise, comme une réception entrante ou une expédition sortante. Elle représente une unité de travail complète au sein de l’entrepôt. En Process Mining, cet attribut sert à définir le cas et à analyser le cycle de vie complet de la commande, de bout en bout. En retraçant toutes les activités associées à une même commande d’entrepôt, les analystes peuvent mesurer le délai total de traitement, repérer les variations récurrentes du processus et comprendre le parcours complet de la commande dans l’entrepôt. Pourquoi est-ce important ? Cet identifiant de cas essentiel relie toutes les activités associées à une commande d’entrepôt et permet d’analyser de bout en bout le traitement des commandes ou le processus de réception des marchandises. Où trouver ces données Il s’agit généralement de la clé primaire de la table d’en-tête des commandes d’entrepôt. Consultez la documentation de Blue Yonder WMS pour connaître les tables liées à la gestion des commandes. Exemples WO-0012845WO-0012991WO-0013057 | |||
| Heure de début de l’événement EventStartTime | Horodatage indiquant le début d’une activité ou d’un événement précis dans l’entrepôt. | ||
| Description Cet attribut enregistre la date et l’heure de lancement d’une tâche ou d’un événement dans l’entrepôt. Il situe chronologiquement toutes les activités d’un cas. Cet horodatage est indispensable aux analyses de Process Mining fondées sur le temps. Il sert à ordonner les événements, à calculer les temps de cycle entre les activités, à mesurer la durée totale du processus et à repérer les temps d’attente ou les retards. Il constitue la base de l’analyse des performances et est nécessaire pour animer la cartographie du processus. Pourquoi est-ce important ? L’horodatage de début est indispensable pour ordonner les événements chronologiquement et calculer les indicateurs de performance, notamment les temps de cycle et les temps d’attente. Où trouver ces données Présent dans les tables des journaux d’événements ou des tâches, il correspond à l’heure de création ou de début d’une action enregistrée. Exemples 2023-10-26T08:30:00Z2023-10-26T09:15:10Z2023-10-26T11:05:45Z | |||
| Nom de l’activité ActivityName | Nom de la tâche ou de l’événement précis survenu dans l’entrepôt, par exemple « Marchandises prélevées » ou « Expédition partie ». | ||
| Description Cet attribut décrit l’étape ou la tâche effectuée dans le processus de gestion de l’entrepôt. Chaque événement du journal de processus est associé à un nom d’activité, qui contribue à définir la séquence des étapes du processus. Dans l’analyse, le nom de l’activité est indispensable pour découvrir la cartographie du processus, étudier les transitions entre les étapes et repérer les goulots d’étranglement ou les écarts par rapport à la procédure standard. Il intervient dans presque toutes les analyses de Process Mining, du contrôle de conformité au suivi des performances. Pourquoi est-ce important ? Cet attribut est essentiel à la création de la cartographie du processus : il définit chaque étape et permet de visualiser et d’analyser le flux du processus. Où trouver ces données Cette information figure généralement dans les tables des tâches ou des journaux d’événements. Elle est souvent dérivée d’un type de tâche ou d’un code de statut. Exemples Tâche de préparation crééeMarchandises prélevées dans le stockExpédition partie | |||
| Dernière mise à jour des données LastDataUpdate | Horodatage indiquant la dernière actualisation des données de cet enregistrement depuis le système source. | ||
| Description Cet attribut enregistre la date et l’heure de la dernière extraction ou mise à jour du jeu de données depuis Blue Yonder WMS. Il fournit des métadonnées sur l’actualité des données analysées. Cet horodatage est important pour la gouvernance des données et permet aux utilisateurs de connaître la date de leur analyse. Les parties prenantes savent ainsi de quelle période datent les données et peuvent vérifier qu’elles consultent un état récent et pertinent du processus. Pourquoi est-ce important ? Cet horodatage renseigne les utilisateurs sur l’actualité des données et leur permet de connaître la période couverte par l’analyse. Où trouver ces données Il s’agit d’un champ de métadonnées généralement généré et ajouté lors du processus d’extraction, de transformation et de chargement (ETL) des données. Exemples 2024-01-15T04:00:00Z2024-01-16T04:00:00Z | |||
| Système source SourceSystem | Système d’où proviennent les données extraites, ici Blue Yonder WMS. | ||
| Description Cet attribut identifie le système d’origine des données d’événement. Dans un environnement informatique moderne, les données d’un même processus de bout en bout peuvent provenir de plusieurs systèmes, comme un ERP, un WMS et un TMS. La précision du système source est essentielle à la gouvernance des données, au dépannage et à la compréhension de leur contexte. Elle permet de remonter à l’origine des problèmes de qualité des données et est indispensable pour fusionner des données de plusieurs sources afin d’obtenir une vue unifiée du processus. Pourquoi est-ce important ? Il fournit des informations essentielles sur la provenance des données, ce qui permet de remonter à leur origine pour les valider et de suivre leur parcours lorsqu’elles sont fusionnées depuis plusieurs systèmes. Où trouver ces données Il s’agit généralement d’une valeur fixe ajoutée lors de l’extraction des données pour indiquer l’origine du jeu de données. Exemples BlueYonderWMS_USBlueYonderWMS_EU | |||
| Date d’achèvement demandée RequestedCompletionDate | Date et heure auxquelles la commande d’entrepôt doit être terminée et expédiée, selon le calendrier ou la demande. | ||
| Description La date d’achèvement demandée correspond à l’accord de niveau de service (SLA) ou à l’objectif de traitement d’une commande d’entrepôt sortante. Elle fixe l’échéance à laquelle les marchandises doivent être prélevées, emballées et prêtes à être expédiées. Cette date sert de référence pour mesurer les performances réelles. Elle permet de calculer le taux d’expédition dans les délais en la comparant à l’horodatage réel du départ de l’expédition. L’analyse des commandes selon cet attribut aide à repérer celles qui risquent d’être en retard et à en déterminer les causes profondes des manquements au SLA. Pourquoi est-ce important ? Cet attribut sert de référence pour mesurer le respect des délais et est essentiel au calcul du taux d’expédition dans les délais. Où trouver ces données Généralement stockée dans la table d’en-tête des commandes d’entrepôt, cette date est souvent reprise de la commande client ou de la demande de livraison source. Exemples 2023-10-27T17:00:00Z2023-10-28T12:00:00Z2023-11-01T17:00:00Z | |||
| Emplacement de stockage StorageLocation | Emplacement précis dans l’entrepôt, comme une case ou une allée, où les marchandises sont stockées ou prélevées. | ||
| Description Cet attribut indique l’emplacement physique de l’entrepôt associé à une tâche. Pour une activité de rangement, il s’agit de l’emplacement de destination. Pour une activité de prélèvement, c’est l’emplacement source. Il peut être représenté par un code composé de l’allée, du rayonnage, de l’étagère et du numéro d’emplacement. L’analyse des données par emplacement de stockage permet d’évaluer l’efficacité de l’agencement de l’entrepôt, les stratégies d’affectation des emplacements et les déplacements des ressources. Elle sert à repérer les zones très fréquentées, les espaces sous-utilisés et les goulots d’étranglement potentiels dans la circulation des marchandises. Cet attribut est essentiel au Dashboard des tendances d’utilisation des emplacements de stockage. Pourquoi est-ce important ? Il fournit le contexte nécessaire pour analyser l’agencement de l’entrepôt et l’efficacité des stratégies d’affectation des emplacements, ainsi que pour repérer les goulots d’étranglement liés aux déplacements. Où trouver ces données Disponible dans les tables liées aux stocks, aux tâches d’entrepôt (prélèvement, rangement) et aux données de référence des emplacements. Exemples A1-R03-S02-B01B5-R10-S04-B05C2-R01-S01-B02 | |||
| Heure de fin de l’événement EventEndTime | Horodatage indiquant la fin d’une activité ou d’un événement précis dans l’entrepôt. | ||
| Description Cet attribut enregistre la date et l’heure de fin d’une tâche ou d’un événement dans l’entrepôt. Lorsqu’il est disponible, il permet de mesurer précisément la durée de traitement de chaque activité. La présence des heures de début et de fin permet une analyse plus détaillée des performances. Elle permet de distinguer le temps d’attente, c’est-à-dire le temps entre les activités, de la durée de traitement, qui correspond à la durée de l’activité elle-même. Cette distinction aide à déterminer si les retards sont dus à des périodes d’inactivité ou à des tâches trop longues. Pourquoi est-ce important ? Cet attribut permet de calculer précisément la durée de traitement d’une activité et de la distinguer du temps d’attente, une étape essentielle pour améliorer les performances de façon ciblée. Où trouver ces données Présent dans les tables des journaux d’événements ou des tâches, il correspond à l’heure de fin ou de clôture d’une action enregistrée. Exemples 2023-10-26T08:35:12Z2023-10-26T09:20:05Z2023-10-26T11:06:00Z | |||
| ID de l’utilisateur ou de l’opérateur UserOperatorId | Identifiant de l’employé ou de l’opérateur de l’entrepôt qui a effectué l’activité. | ||
| Description Cet attribut enregistre l’identifiant unique de la personne chargée d’effectuer une tâche dans l’entrepôt, comme le prélèvement, l’emballage ou le rangement. Il relie les activités du processus aux ressources humaines. L’analyse des activités par ID d’utilisateur ou d’opérateur permet de comprendre l’utilisation des ressources, la répartition de la charge de travail et les performances individuelles. Elle aide à déterminer quels opérateurs sont les plus efficaces, qui pourrait avoir besoin d’une formation complémentaire et comment les tâches sont réparties au sein d’une équipe. C’est une dimension essentielle du Dashboard sur l’utilisation des ressources de l’entrepôt. Pourquoi est-ce important ? Cet attribut relie les étapes du processus aux personnes qui les ont effectuées et permet d’analyser les performances des ressources, la charge de travail et les besoins en formation. Où trouver ces données On le trouve généralement dans les tables des tâches ou des transactions. Il est associé à l’utilisateur connecté au système ou à l’appareil portable pendant l’opération. Exemples JSMITHBWILLISAMILLER | |||
| Niveau de priorité PriorityLevel | Priorité de la commande d’entrepôt, par exemple « Élevée », « Standard » ou « Faible ». | ||
| Description Le niveau de priorité indique le degré d’urgence d’une commande d’entrepôt. Les commandes prioritaires, comme les expéditions accélérées, sont censées être traitées plus rapidement que les commandes standard. Le WMS utilise cet attribut pour ordonner les tâches et affecter les ressources. En Process Mining, cet attribut permet d’évaluer l’efficacité des stratégies de priorisation. Le Dashboard de traitement des commandes prioritaires s’appuie sur ce champ pour filtrer les commandes urgentes et comparer leurs temps de cycle à ceux des commandes standard. Il permet de vérifier si les commandes prioritaires avancent réellement plus vite ou si elles se heurtent aux mêmes goulots d’étranglement. Pourquoi est-ce important ? Cet attribut permet de vérifier si les commandes prioritaires sont traitées plus rapidement que les commandes standard et d’évaluer l’efficacité des règles de priorisation. Où trouver ces données Cette information est généralement stockée dans la table d’en-tête des commandes d’entrepôt. Exemples ÉlevéeStandardFaible | |||
| Quantité prévue PlannedQuantity | Quantité d’articles prévue pour une tâche donnée, par exemple la quantité à prélever ou à réceptionner. | ||
| Description La quantité prévue correspond au nombre d’unités défini par la commande d’entrepôt pour une tâche donnée. Pour une livraison entrante, il s’agit de la quantité attendue du fournisseur. Pour une tâche de prélèvement, c’est la quantité demandée dans la commande du client. Cet attribut est essentiel à l’analyse de la précision. La comparaison entre la quantité prévue et la quantité réelle permet de repérer les écarts lors de la réception, du prélèvement ou du comptage des stocks. Il contribue directement à des indicateurs clés de performance comme le taux d’écart de quantité au prélèvement et est indispensable au Dashboard d’audit de la précision des quantités. Pourquoi est-ce important ? Elle sert de référence pour mesurer la précision et repérer les écarts de quantité lors des activités de réception et de prélèvement. Où trouver ces données Présente dans les tables de détail ou de lignes associées aux commandes d’entrepôt ou à des tâches précises. Exemples 1005024 | |||
| Quantité réelle ActualQuantity | Quantité d’articles effectivement traitée pendant une tâche, par exemple la quantité comptée physiquement ou prélevée. | ||
| Description La quantité réelle correspond au nombre d’unités effectivement traitées par un opérateur de l’entrepôt pendant une tâche. Il peut s’agir du nombre d’articles reçus d’un fournisseur, d’unités prélevées dans un emplacement de stockage ou d’articles emballés dans un conteneur d’expédition. Comparé à la quantité prévue, cet attribut révèle les exceptions et les erreurs du processus. C’est la métrique de référence pour calculer les taux d’écart, qui sont des indicateurs clés de la qualité opérationnelle. Ces données sont essentielles pour repérer les problèmes liés aux expéditions des fournisseurs, aux erreurs de prélèvement ou à l’inexactitude des stocks. Pourquoi est-ce important ? La comparaison avec la quantité prévue est essentielle pour repérer les erreurs de processus et calculer des indicateurs clés de qualité, comme les taux d’écart. Où trouver ces données Présente dans les tables de confirmation des tâches ou les journaux de transactions, où les opérateurs enregistrent la quantité traitée. Exemples 1004924 | |||
| Écart de quantité IsQuantityMismatch | Indicateur booléen signalant si la quantité réellement traitée diffère de la quantité prévue pour une tâche. | ||
| Description Cet attribut calculé indique simplement un écart de quantité pour une tâche donnée, comme un prélèvement ou une réception. Il prend la valeur vrai lorsque la quantité réelle ne correspond pas à la quantité prévue. Cet indicateur facilite le repérage et le décompte des erreurs dans le processus. Il simplifie le calcul d’indicateurs clés de performance comme le taux d’écart de quantité au prélèvement et le taux d’écart de quantité à la réception. Il facilite aussi l’analyse des causes profondes : les analystes peuvent filtrer tous les événements présentant un écart et rechercher des tendances liées aux produits, aux opérateurs ou aux emplacements. Pourquoi est-ce important ? Il signale les événements présentant des erreurs de quantité, simplifie le calcul des taux d’écart et permet d’analyser de façon ciblée les tâches comportant des inexactitudes. Où trouver ces données Calculé en comparant les champs PlannedQuantity et ActualQuantity pour chaque activité concernée. Exemples falsetruefalse | |||
| Expédition dans les délais IsOnTimeShipment | Indicateur booléen vrai si l’expédition est partie à la date d’achèvement demandée ou avant. | ||
| Description Cet attribut calculé indique simplement si une commande a respecté son SLA d’expédition. Il est obtenu en comparant l’horodatage de l’activité « Expédition partie » à la date d’achèvement demandée pour la commande. Cet indicateur facilite l’analyse et la visualisation du respect des délais. Il permet de filtrer et d’agréger facilement les données pour calculer le taux d’expédition dans les délais et alimenter le Dashboard correspondant. Il permet également d’analyser les causes profondes et de repérer les caractéristiques communes aux expéditions en retard. Pourquoi est-ce important ? Cet indicateur booléen simplifie le calcul du taux d’expédition dans les délais et facilite le filtrage des commandes en retard pour en analyser les caractéristiques. Où trouver ces données Calculé en comparant l’EventStartTime de l’activité « Expédition partie » à l’attribut RequestedCompletionDate. Exemples truefalsetrue | |||
| ID de l’entrepôt WarehouseId | Identifiant de l’entrepôt ou du centre de distribution où l’activité a eu lieu. | ||
| Description L’ID de l’entrepôt identifie de manière unique le site où se déroule le processus. Cet attribut est essentiel aux organisations qui exploitent plusieurs centres de distribution. Il permet de comparer les performances entre différents sites et de les évaluer par rapport à des références. En filtrant ou en segmentant les données par ID d’entrepôt, les entreprises peuvent comparer les performances, repérer les bonnes pratiques des sites les plus performants et comprendre les difficultés des autres. Il apporte une dimension essentielle à l’analyse des opérations sur plusieurs sites. Pourquoi est-ce important ? Pour les organisations présentes sur plusieurs sites, cet attribut est essentiel pour comparer les performances et les processus d’un emplacement à l’autre. Où trouver ces données Il s’agit souvent d’un champ organisationnel de premier niveau, disponible dans presque toutes les tables de transactions, ou qui peut être déduit de l’instance du système. Exemples WHC-01DC-EAST-03FAC-WEST | |||
| ID de l’équipement EquipmentId | Identifiant de l’équipement de manutention utilisé, par exemple un chariot élévateur ou un convoyeur précis. | ||
| Description L’ID de l’équipement indique quelle machine ou quel équipement a servi à effectuer une tâche dans l’entrepôt. Il peut s’agir de chariots élévateurs, de transpalettes, de véhicules à guidage automatique (AGV) ou de postes d’emballage précis. Cet attribut permet d’analyser l’utilisation et les performances des équipements, ainsi que leurs besoins de maintenance. En suivant les activités par équipement, les responsables peuvent repérer les actifs surutilisés ou sous-utilisés, comparer l’efficacité de différents types de machines et recueillir des données pour planifier la maintenance. C’est une dimension essentielle du Dashboard sur l’utilisation des ressources de l’entrepôt. Pourquoi est-ce important ? Il permet d’analyser l’utilisation et les performances des équipements afin d’optimiser l’affectation des actifs et la planification de leur maintenance. Où trouver ces données Peut être enregistré dans les journaux d’exécution des tâches, notamment lorsque les opérateurs se connectent aux équipements. Exemples FORKLIFT-07AGV-03PACKSTATION-12 | |||
| ID de l’expédition ShipmentId | Identifiant unique de l’expédition sortante à laquelle appartient une commande d’entrepôt. | ||
| Description L’ID de l’expédition est un identifiant de niveau supérieur qui peut regrouper plusieurs commandes d’entrepôt expédiées dans le même camion ou conteneur. Pour une commande unique, il peut être identique au numéro de commande d’entrepôt ou de livraison. L’analyse par ID d’expédition donne une vue du processus d’expédition. Elle permet de comprendre comment les commandes sont regroupées, de mesurer le temps entre la mise en zone d’expédition et le départ final d’un camion complet, et d’analyser l’efficacité du service d’expédition. Elle relie les activités de l’entrepôt à la dernière étape de transport de la chaîne logistique. Pourquoi est-ce important ? Il regroupe les commandes d’entrepôt expédiées ensemble et permet d’analyser les processus de regroupement et de départ des expéditions. Où trouver ces données Présent dans les tables liées aux expéditions ou au transport, auxquelles les commandes d’entrepôt sont associées. Exemples SHP-45000123SHP-45000124SHP-45000125 | |||
| Référence produit (SKU) ProductSku | Unité de gestion des stocks (SKU) ou numéro de référence de l’article traité. | ||
| Description Cet attribut identifie le produit précis concerné par une tâche dans l’entrepôt. Il fournit des informations détaillées sur les marchandises déplacées, stockées, prélevées et emballées. L’analyse du processus par référence produit (SKU) peut révéler des tendances propres à certains articles. Par exemple, certains produits peuvent être plus souvent concernés par des erreurs de prélèvement, nécessiter un rangement plus long en raison de contraintes de manutention particulières ou être stockés à des emplacements peu efficaces. Ces informations permettent d’optimiser le processus pour chaque produit et d’améliorer les stratégies d’affectation des emplacements. Pourquoi est-ce important ? Il permet d’analyser le processus à l’échelle des produits et de repérer les articles qui entraînent des retards ou des erreurs, ou qui nécessitent une manutention particulière. Où trouver ces données Cette information figure au niveau des lignes d’article dans les tables des commandes d’entrepôt ou des tâches. Exemples PN-A5540-BSKU-300-RED-LGHW-88201 | |||
| Statut de la tâche TaskStatus | Statut final d’une tâche donnée, par exemple « Terminée », « Annulée » ou « Échouée ». | ||
| Description Cet attribut décrit le résultat d’une tâche précise dans l’entrepôt. Si de nombreuses tâches se terminent correctement, certaines peuvent être annulées par un responsable ou échouer en raison d’un problème système ou opérationnel. Il apporte plus de contexte que le seul nom de l’activité. L’analyse par statut de la tâche permet de comprendre les exceptions et les échecs du processus. Un taux élevé de tâches annulées ou échouées peut révéler des problèmes sous-jacents liés à la précision des stocks, à la configuration du système ou à la formation des opérateurs. Elle aide à repérer les activités sujettes aux échecs qui nécessitent un examen plus approfondi. Pourquoi est-ce important ? Il indique le résultat d’une activité et permet d’analyser les exceptions, comme les tâches annulées ou échouées, qui peuvent révéler des problèmes opérationnels plus profonds. Où trouver ces données Généralement présent dans la table des tâches, il indique l’état final de l’enregistrement de la tâche. Exemples TerminéeAnnuléeEn attente | |||
| Type de commande d’entrepôt WarehouseOrderType | Catégorise la commande d’entrepôt, par exemple en réception entrante, expédition sortante ou transfert interne. | ||
| Description Cet attribut classe la finalité générale de la commande d’entrepôt. Les types courants comprennent les livraisons entrantes des fournisseurs, les expéditions sortantes aux clients, le traitement des retours et les mouvements de stock internes entre différents emplacements de l’entrepôt. La segmentation du processus par type de commande d’entrepôt est une première étape fondamentale de toute analyse. Les processus entrants et sortants diffèrent souvent sensiblement par leurs étapes, leurs ressources et leurs objectifs de performance. Cet attribut permet de filtrer les données pour analyser séparément un processus précis, comme la réception des marchandises ou le traitement des commandes. Pourquoi est-ce important ? Il permet de distinguer et de comparer différents processus, comme les flux entrants et sortants, qui suivent des parcours et répondent à des objectifs distincts. Où trouver ces données Présent dans la table d’en-tête des commandes d’entrepôt, généralement dans un champ de type de document ou de catégorie de commande. Exemples Livraison entranteExpédition sortanteTransfert interne | |||
Activités de gestion d’entrepôt
| Activité | Description | ||
|---|---|---|---|
| Commande d’entrepôt créée | Cet événement marque la création d’une commande d’entrepôt, document central pour gérer les tâches entrantes, sortantes ou internes. Il est généralement enregistré comme une transaction explicite lors de la saisie d’une nouvelle commande dans Blue Yonder WMS, manuellement ou par intégration. | ||
| Pourquoi est-ce important ? Cet événement marque le début du processus. Le temps écoulé entre sa survenue et l’achèvement de la commande correspond au délai total de traitement, essentiel pour mesurer l’efficacité globale et le respect des niveaux de service convenus. Où trouver ces données Cet événement est probablement enregistré dans une table d’en-tête de commande, à partir de l’horodatage de création de la commande d’entrepôt. Recherchez les tables liées à Données à recueillir À partir de l’horodatage de création de la commande d’entrepôt. Type d’événement explicit | |||
| Commande d’entrepôt terminée | Il s’agit du statut final de la commande d’entrepôt. Il indique que toutes les activités associées, y compris l’expédition, sont terminées et que la commande est clôturée. Ce statut est enregistré lorsque le cycle de vie de la commande passe à « Terminée » ou « Clôturée ». | ||
| Pourquoi est-ce important ? Cette activité marque la fin définitive du cas de processus. Elle permet à l’analyse de couvrir le cycle de vie complet de chaque commande, du début à la fin. Où trouver ces données Cet événement peut être déduit d’un changement de statut dans la table d’en-tête des commandes d’entrepôt. Recherchez un statut final tel que « Terminée », « Clôturée » ou « Facturée », ainsi que l’horodatage du changement. Données à recueillir Déduit de l’horodatage du changement de statut final dans l’en-tête de la commande. Type d’événement inferred | |||
| Expédition partie | Cet événement indique que les marchandises emballées ont été chargées dans le camion du transporteur et que celui-ci a quitté l’entrepôt. Il est généralement enregistré lors de la validation de la sortie de marchandises dans le système, qui finalise l’expédition. | ||
| Pourquoi est-ce important ? Cette étape importante marque la fin de la responsabilité de l’entrepôt pour la commande. C’est le dernier point de mesure du respect des délais d’expédition et du délai total de traitement de la commande. Où trouver ces données Il s’agit d’une transaction financière et logistique majeure, souvent appelée « validation de la sortie de marchandises » (PGI). Son horodatage correspond à l’heure de départ de l’expédition et figure généralement dans les tables des livraisons sortantes ou des documents d’expédition. Données à recueillir Horodatage de la transaction de validation de la sortie de marchandises (PGI). Type d’événement explicit | |||
| Marchandises rangées en stock | Cet événement confirme que les marchandises ont été déplacées et scannées à leur emplacement de stockage prévu. Il est enregistré lorsqu’un opérateur confirme l’achèvement de la tâche de rangement, généralement à l’aide d’un terminal RF portable. | ||
| Pourquoi est-ce important ? Cette étape marque la fin du processus de livraison entrante et rend les stocks disponibles pour le traitement des commandes. L’analyse du temps écoulé entre la réception et cette étape est essentielle au Dashboard « Goods Receipt to Putaway Cycle Time ». Où trouver ces données Enregistré sous forme de transaction horodatée lorsque le statut de la tâche de rangement passe à « Completed » ou « Confirmed ». Ces données se trouvent dans les tables des tâches d’entrepôt ou des ordres de transfert. Données à recueillir Horodatage de confirmation de la tâche de rangement en entrepôt. Type d’événement explicit | |||
| Marchandises reçues et comptées | Cet événement indique que les marchandises ont été déchargées et scannées, et que leurs quantités ont été vérifiées par rapport aux documents de livraison. Il est généralement enregistré lorsqu’un employé de la réception confirme dans le système les quantités reçues pour chaque article de la commande entrante. | ||
| Pourquoi est-ce important ? Cette étape importante rend officiellement les stocks disponibles dans le système, sans pour autant les rendre prêts à être expédiés. Sa durée et sa précision ont une incidence directe sur la visibilité des stocks et sur le début du rangement. Où trouver ces données Il s’agit d’une transaction explicite enregistrée dans les journaux de stock ou de réception. Recherchez les transactions liées à la validation de la réception des marchandises ou les changements de statut des lignes de livraison entrante indiquant « Received ». Données à recueillir Horodatage de la transaction confirmant la réception des marchandises. Type d’événement explicit | |||
| Tâche de préparation créée | Cet événement marque la création d’une tâche demandant à un opérateur de prélever des marchandises dans un emplacement de stockage pour traiter une commande sortante. Il s’agit d’un événement explicite généré par le WMS lorsqu’une commande sortante est lancée pour préparation. | ||
| Pourquoi est-ce important ? C’est le début du processus physique de sortie des marchandises. L’analyse du temps écoulé entre la création de la commande et celle de la tâche de préparation révèle les retards de traitement et d’affectation. Où trouver ces données Enregistré dans les tables de gestion des tâches ou de contrôle de l’entrepôt. Il correspond à l’horodatage de création des tâches de préparation associées à la commande d’entrepôt. Données à recueillir Horodatage de création de la tâche de préparation générée par le système. Type d’événement explicit | |||
| Commande d’entrepôt annulée | Cet événement correspond à l’annulation d’une commande d’entrepôt avant son traitement complet ou son expédition. Il est enregistré lorsqu’un utilisateur exécute une transaction d’annulation qui fait passer le statut de la commande à « Annulée ». | ||
| Pourquoi est-ce important ? L’analyse des annulations permet de repérer les causes d’échec du processus, comme une rupture de stock ou un changement de la part du client. Cet événement terminal est essentiel pour comprendre les écarts du processus et les commandes abandonnées. Où trouver ces données Cet événement est généralement déduit du statut final de la commande d’entrepôt. L’horodatage utilisé est celui du changement de statut à « Annulée » ou « Supprimée ». Données à recueillir Déduit de l’horodatage du changement de statut à « Annulée ». Type d’événement inferred | |||
| Contrôle qualité effectué | Cet événement correspond à un contrôle qualité des marchandises reçues. Il peut s’agir d’une étape standard pour certains matériaux ou d’un contrôle déclenché par une exception. Il est enregistré lorsque l’inspecteur qualité saisit ses observations dans le système. | ||
| Pourquoi est-ce important ? Les contrôles qualité peuvent retarder considérablement le processus de livraison entrante. L’analyse de leur fréquence et de leur durée aide à repérer les problèmes de qualité chez les fournisseurs et les goulots d’étranglement dans le flux de travail d’inspection. Où trouver ces données Enregistré dans les modules de gestion de la qualité (QM) ou dans les journaux associés à la livraison entrante. Recherchez les codes de transaction correspondant aux résultats des contrôles qualité ou les changements de statut des stocks indiquant « Quality Hold ». Données à recueillir Horodatage de la fin du contrôle qualité ou de la mise à jour du statut. Type d’événement explicit | |||
| Emballage commencé | Cette activité marque le début de l’emballage à un poste dédié. Elle est généralement enregistrée lorsqu’un opérateur scanne les articles prélevés ou le bac de la commande au poste d’emballage pour préparer l’expédition. | ||
| Pourquoi est-ce important ? Cet événement marque le passage de la préparation à l’emballage. Il permet d’isoler cette étape du traitement des commandes afin de repérer les goulots d’étranglement propres à la zone d’emballage. Où trouver ces données Il peut s’agir d’un journal de transactions explicite provenant de l’interface d’un poste d’emballage. Il peut aussi être déduit de la première activité horodatée associée à un poste d’emballage pour cette commande. Données à recueillir Horodatage de la transaction « Démarrer l’emballage » sur un poste d’emballage. Type d’événement explicit | |||
| Livraison entrante signalée | Cet événement correspond à la réception d’un avis d’expédition préalable (ASN) envoyé par un fournisseur pour signaler que les marchandises sont en route vers l’entrepôt. Il est enregistré explicitement lorsque le système reçoit et traite l’ASN, souvent par EDI ou via un portail. | ||
| Pourquoi est-ce important ? Cette activité déclenche la planification des livraisons entrantes et l’affectation des ressources. Le temps écoulé entre cette notification et la réception physique des marchandises est un KPI important pour mesurer la performance des fournisseurs et la visibilité sur les livraisons en cours. Où trouver ces données Données issues des journaux de réception des ASN ou de l’horodatage de création du document de livraison entrante dans Blue Yonder WMS. Consultez les tables liées aux ASN ou aux notifications d’expédition entrante. Données à recueillir Horodatage de réception d’un ASN ou de création d’un document de livraison entrante. Type d’événement explicit | |||
| Marchandises arrivées au quai | Cette activité marque l’arrivée physique d’un camion ou d’un transporteur au quai de réception de l’entrepôt, avant le début du déchargement. Elle est souvent enregistrée explicitement par un module de gestion de cour ou lors de l’enregistrement de la livraison par un agent à l’entrée. | ||
| Pourquoi est-ce important ? Le suivi de l’heure d’arrivée permet de mesurer la ponctualité des transporteurs et de repérer les retards entre leur arrivée et le début de la réception. Il met en évidence les goulots d’étranglement possibles dans la gestion de cour ou au niveau des quais de réception. Où trouver ces données Généralement enregistrée dans un module de gestion de cour ou de contrôle des accès de Blue Yonder WMS. Un employé de la réception peut aussi saisir manuellement l’heure d’arrivée du camion. Données à recueillir Horodatage de l’enregistrement du transporteur à son arrivée. Type d’événement explicit | |||
| Marchandises emballées | Cet événement confirme que tous les articles d’une expédition ont été emballés dans des conteneurs d’expédition et que les étiquettes ont été générées. Il est enregistré lorsque l’opérateur confirme dans le système que l’emballage de la commande est terminé. | ||
| Pourquoi est-ce important ? Cet événement marque la fin des activités à valeur ajoutée dans l’entrepôt. Le temps écoulé entre ce moment et le départ de l’expédition correspond au temps de mise en zone d’expédition et de chargement, une étape où des retards peuvent survenir. Où trouver ces données Il s’agit d’une transaction explicite enregistrée à la fin de l’emballage. Recherchez un changement de statut de la livraison sortante à « Emballée » ou l’horodatage de fin de la transaction au poste d’emballage. Données à recueillir Horodatage de la transaction « Confirmer l’emballage » ou « Fermer le conteneur ». Type d’événement explicit | |||
| Marchandises prélevées dans le stock | Cet événement marque l’achèvement de la tâche de préparation : l’opérateur a prélevé les articles et confirmé l’opération dans le système. Il est enregistré lorsque l’opérateur scanne les articles et confirme le prélèvement sur son appareil. | ||
| Pourquoi est-ce important ? Cette étape marque la fin de la préparation. Sa précision et sa durée sont essentielles à l’efficacité globale du traitement des commandes et servent de base à l’analyse « Picking Accuracy ». Où trouver ces données Donnée issue de l’horodatage de confirmation, lorsque le statut de la tâche de préparation passe à « Completed ». Elle se trouve dans les tables des tâches d’entrepôt, souvent associée à l’opérateur et à l’équipement concernés. Données à recueillir Horodatage de confirmation de la tâche de préparation en entrepôt. Type d’événement explicit | |||
| Mise en zone d’expédition | Cet événement correspond au déplacement des conteneurs emballés de la zone d’emballage vers une voie d’attente désignée, où ils attendent la prise en charge par le transporteur. Il est enregistré lorsqu’un opérateur confirme le déplacement de l’unité de manutention vers cette zone. | ||
| Pourquoi est-ce important ? Cette activité permet d’analyser le temps d’attente des commandes emballées avant leur chargement. Une attente prolongée peut révéler une mauvaise coordination avec les transporteurs ou une utilisation inefficace de l’espace de mise en zone d’expédition. Où trouver ces données Cet événement peut être déduit d’un changement d’emplacement de l’unité de manutention ou du conteneur d’expédition vers une zone d’attente. Il peut aussi correspondre à la confirmation explicite de la tâche « Déplacer vers la zone d’attente ». Données à recueillir Déduit des journaux de mouvements de stock indiquant un transfert vers un emplacement de mise en zone d’expédition. Type d’événement inferred | |||
| Tâche de rangement créée | Cette activité marque la création, par le système, d’une tâche visant à déplacer les marchandises reçues du quai de réception vers leur emplacement de stockage définitif. Il s’agit d’un événement explicite généré par la logique du WMS pour guider un opérateur d’entrepôt. | ||
| Pourquoi est-ce important ? C’est le début du processus de rangement. Un délai entre la réception des marchandises et la création de la tâche peut révéler un problème de configuration ou de performance du système, et laisser les marchandises dans la zone de réception. Où trouver ces données Générée et enregistrée dans les tables de gestion des tâches ou de contrôle de l’entrepôt. Recherchez l’horodatage de création des tâches de rangement ou des ordres de transfert liés à la livraison entrante. Données à recueillir Horodatage de création de la tâche de rangement générée par le système. Type d’événement explicit | |||
Guides d’extraction
Étapes
- Prérequis et accès : Vérifiez que vous disposez d’un compte utilisateur Blue Yonder WMS avec les autorisations nécessaires pour exécuter des commandes MOCA et accéder aux tables requises, telles que ord_hdr, pckwrk_dtl et invmov. Vous devez également avoir accès à un client MOCA, comme MOCA Console ou une interface en ligne de commande.
- Vérifiez et personnalisez le script MOCA : Copiez le script MOCA fourni. Vérifiez attentivement les noms des tables et des colonnes pour vous assurer qu’ils correspondent à votre implémentation de Blue Yonder WMS. Portez une attention particulière aux espaces réservés tels que
@[where_clause_dates]et@[where_clause_warehouse], qui doivent être remplacés par des valeurs réelles. - Définissez les paramètres d’extraction : Remplacez les variables de substitution dans le script. Pour
@[where_clause_dates], définissez une période précise, par exemplewhere adddte between 'YYYY-MM-DD' and 'YYYY-MM-DD'. Pour@[where_clause_warehouse], indiquez les identifiants des entrepôts à extraire, par exemplewhere wh_id = '[Your Warehouse ID]'. - Connectez-vous au serveur MOCA : Lancez votre client MOCA, par exemple MOCA Console, puis connectez-vous au bon environnement Blue Yonder WMS.
- Exécutez le script MOCA : Collez le script personnalisé dans MOCA Console, puis exécutez la commande. Le script s’exécutera sur le serveur et recueillera les données de toutes les activités spécifiées.
- Surveillez l’exécution : Pour les grands volumes de données, la requête peut prendre beaucoup de temps. Surveillez la console afin de repérer les messages d’erreur ou les avertissements de performance. Si la requête expire, envisagez de réduire la période d’extraction.
- Exportez les résultats dans un fichier : Une fois le script exécuté, les résultats s’affichent dans la console. Utilisez la fonction d’exportation du client pour enregistrer les résultats dans un fichier CSV. En ligne de commande, vous pouvez rediriger directement la sortie vers un fichier, par exemple :
mocarun -S "[Your MOCA Script]" > event_log.csv. - Formatez le fichier CSV pour ProcessMind : Ouvrez le fichier CSV exporté. Vérifiez que les en-têtes de colonnes correspondent aux attributs indiqués dans la requête (
WarehouseOrder,ActivityName,EventStartTime, etc.). Enregistrez le fichier en UTF-8 pour éviter les problèmes d’encodage lors de l’importation. - Vérifiez le fichier et importez-le : Contrôlez une dernière fois le contenu du fichier pour repérer d’éventuelles erreurs ou incohérences. Une fois cette vérification terminée, importez le fichier CSV dans ProcessMind pour l’analyser.
Configuration
- Période : Il est recommandé d’extraire les données sur une période de 3 à 6 mois afin d’obtenir un échantillon représentatif des variations du processus. Le filtre de dates
@[where_clause_dates]doit s’appliquer à la colonne d’horodatage principale de chaque instruction SELECT, par exempleadddteoumoddte. - Filtres sur l’entrepôt et le client : Limitez toujours le périmètre de l’extraction à l’aide de filtres. Utilisez l’espace réservé
@[where_clause_warehouse]pour filtrer par identifiants d’entrepôt (wh_id) et, le cas échéant, par identifiants client (client_id). Ces filtres sont importants pour les performances et la pertinence des données. - Filtres sur le type de commande : Pour cibler l’analyse, envisagez de filtrer certains types de commandes d’entrepôt (
ordtyp). Vous pouvez, par exemple, analyser uniquement les commandes clients sortantes ou les commandes d’achat entrantes. Ajoutez ce filtre à la clause WHERE des sections concernées du script. - Performances : Le script d’extraction joint et combine plusieurs tables volumineuses. Pour éviter de nuire aux performances du système, planifiez l’extraction en dehors des heures de pointe. Dans les environnements très volumineux, une extraction par lots incrémentiels plus petits, par exemple un mois à la fois, est une approche prudente.
- Prérequis : L’utilisateur qui exécute le script doit disposer d’un accès en lecture à toutes les tables référencées dans la requête, notamment
ord_hdr,ord_dtl,invmov,pckwrk_dtl,asnhdrettrn_log. Il doit également être autorisé à exécuter des commandes MOCA.
Exemple de requête sql
publish data
where wh_id = '[Your Warehouse ID]'
and event_time between to_date(@start_date, 'YYYY-MM-DD') and to_date(@end_date, 'YYYY-MM-DD')
|
[
/* 1. Warehouse Order Created */
select
ordnum as WarehouseOrder,
'Warehouse Order Created' as ActivityName,
adddte as EventStartTime,
moddte as EventEndTime,
add_usr_id as UserOperatorId,
ordqty as PlannedQuantity,
null as ActualQuantity,
null as StorageLocation,
req_ship_dte as RequestedCompletionDate,
prifld as PriorityLevel,
'Blue Yonder WMS' as SourceSystem,
sysdate as LastDataUpdate
from ord_hdr
where ordtyp in ('ORD', 'INB')
and adddte between to_date(@start_date, 'YYYY-MM-DD') and to_date(@end_date, 'YYYY-MM-DD')
and wh_id = '[Your Warehouse ID]'
union all
/* 2. Inbound Delivery Notified */
select
supnum as WarehouseOrder, /* ASN number often used as the order key for inbound */
'Inbound Delivery Notified' as ActivityName,
adddte as EventStartTime,
moddte as EventEndTime,
add_usr_id as UserOperatorId,
null as PlannedQuantity,
null as ActualQuantity,
null as StorageLocation,
expdte as RequestedCompletionDate,
null as PriorityLevel,
'Blue Yonder WMS' as SourceSystem,
sysdate as LastDataUpdate
from asnhdr
where adddte between to_date(@start_date, 'YYYY-MM-DD') and to_date(@end_date, 'YYYY-MM-DD')
and wh_id = '[Your Warehouse ID]'
union all
/* 3. Goods Arrived at Dock */
select
refnum as WarehouseOrder,
'Goods Arrived at Dock' as ActivityName,
cmpl_dte as EventStartTime,
cmpl_dte as EventEndTime,
mod_usr_id as UserOperatorId,
null as PlannedQuantity,
null as ActualQuantity,
dstloc as StorageLocation, /* Typically a receiving dock location */
null as RequestedCompletionDate,
null as PriorityLevel,
'Blue Yonder WMS' as SourceSystem,
sysdate as LastDataUpdate
from trn_log
where trncod = 'RCV_ARVL'
and cmpl_dte between to_date(@start_date, 'YYYY-MM-DD') and to_date(@end_date, 'YYYY-MM-DD')
and wh_id = '[Your Warehouse ID]'
union all
/* 4. Goods Received and Counted */
select
ordnum as WarehouseOrder,
'Goods Received and Counted' as ActivityName,
cmpl_dte as EventStartTime,
cmpl_dte as EventEndTime,
mod_usr_id as UserOperatorId,
untqty as PlannedQuantity,
actqty as ActualQuantity,
srcloc as StorageLocation,
null as RequestedCompletionDate,
null as PriorityLevel,
'Blue Yonder WMS' as SourceSystem,
sysdate as LastDataUpdate
from invmov
where trntyp = 'R' /* Standard receipt transaction type */
and cmpl_dte between to_date(@start_date, 'YYYY-MM-DD') and to_date(@end_date, 'YYYY-MM-DD')
and wh_id = '[Your Warehouse ID]'
union all
/* 5. Quality Inspection Performed */
select
ordnum as WarehouseOrder,
'Quality Inspection Performed' as ActivityName,
cmpl_dte as EventStartTime,
cmpl_dte as EventEndTime,
mod_usr_id as UserOperatorId,
untqty as PlannedQuantity,
actqty as ActualQuantity,
srcloc as StorageLocation,
null as RequestedCompletionDate,
null as PriorityLevel,
'Blue Yonder WMS' as SourceSystem,
sysdate as LastDataUpdate
from invmov
where trntyp = 'H' and trncod = 'QA_CMP' /* Example transaction for QA Hold Release/Complete */
and cmpl_dte between to_date(@start_date, 'YYYY-MM-DD') and to_date(@end_date, 'YYYY-MM-DD')
and wh_id = '[Your Warehouse ID]'
union all
/* 6. Putaway Task Created */
select
ordnum as WarehouseOrder,
'Putaway Task Created' as ActivityName,
adddte as EventStartTime,
moddte as EventEndTime,
add_usr_id as UserOperatorId,
pckqty as PlannedQuantity,
null as ActualQuantity,
srcloc as StorageLocation,
null as RequestedCompletionDate,
prifld as PriorityLevel,
'Blue Yonder WMS' as SourceSystem,
sysdate as LastDataUpdate
from pckwrk_dtl
where wrktyp = 'P' /* Putaway work type */
and adddte between to_date(@start_date, 'YYYY-MM-DD') and to_date(@end_date, 'YYYY-MM-DD')
and wh_id = '[Your Warehouse ID]'
union all
/* 7. Goods Put Away in Storage */
select
ordnum as WarehouseOrder,
'Goods Put Away in Storage' as ActivityName,
cmpl_dte as EventStartTime,
cmpl_dte as EventEndTime,
mod_usr_id as UserOperatorId,
untqty as PlannedQuantity,
actqty as ActualQuantity,
dstloc as StorageLocation,
null as RequestedCompletionDate,
null as PriorityLevel,
'Blue Yonder WMS' as SourceSystem,
sysdate as LastDataUpdate
from invmov
where trntyp = 'M' and trncod = 'PUTAWAY' /* Move transaction for putaway */
and cmpl_dte between to_date(@start_date, 'YYYY-MM-DD') and to_date(@end_date, 'YYYY-MM-DD')
and wh_id = '[Your Warehouse ID]'
union all
/* 8. Picking Task Created */
select
ordnum as WarehouseOrder,
'Picking Task Created' as ActivityName,
adddte as EventStartTime,
moddte as EventEndTime,
add_usr_id as UserOperatorId,
pckqty as PlannedQuantity,
null as ActualQuantity,
srcloc as StorageLocation,
null as RequestedCompletionDate,
prifld as PriorityLevel,
'Blue Yonder WMS' as SourceSystem,
sysdate as LastDataUpdate
from pckwrk_dtl
where wrktyp = 'O' /* Outbound Picking work type */
and adddte between to_date(@start_date, 'YYYY-MM-DD') and to_date(@end_date, 'YYYY-MM-DD')
and wh_id = '[Your Warehouse ID]'
union all
/* 9. Goods Picked from Storage */
select
ordnum as WarehouseOrder,
'Goods Picked from Storage' as ActivityName,
pk_end_dte as EventStartTime,
pk_end_dte as EventEndTime,
pckr_id as UserOperatorId,
pckqty as PlannedQuantity,
actqty as ActualQuantity,
srcloc as StorageLocation,
null as RequestedCompletionDate,
prifld as PriorityLevel,
'Blue Yonder WMS' as SourceSystem,
sysdate as LastDataUpdate
from pckwrk_dtl
where wrktyp = 'O'
and statcod = 'P' /* Status 'Picked' */
and pk_end_dte between to_date(@start_date, 'YYYY-MM-DD') and to_date(@end_date, 'YYYY-MM-DD')
and wh_id = '[Your Warehouse ID]'
union all
/* 10. Packing Initiated */
select
ordnum as WarehouseOrder,
'Packing Initiated' as ActivityName,
cmpl_dte as EventStartTime,
cmpl_dte as EventEndTime,
mod_usr_id as UserOperatorId,
null as PlannedQuantity,
null as ActualQuantity,
dstloc as StorageLocation, /* Packing station */
null as RequestedCompletionDate,
null as PriorityLevel,
'Blue Yonder WMS' as SourceSystem,
sysdate as LastDataUpdate
from trn_log
where trncod = 'PACK_INIT'
and cmpl_dte between to_date(@start_date, 'YYYY-MM-DD') and to_date(@end_date, 'YYYY-MM-DD')
and wh_id = '[Your Warehouse ID]'
union all
/* 11. Goods Packed */
select
ordnum as WarehouseOrder,
'Goods Packed' as ActivityName,
moddte as EventStartTime,
moddte as EventEndTime,
mod_usr_id as UserOperatorId,
null as PlannedQuantity,
null as ActualQuantity,
null as StorageLocation,
req_ship_dte as RequestedCompletionDate,
prifld as PriorityLevel,
'Blue Yonder WMS' as SourceSystem,
sysdate as LastDataUpdate
from ord_hdr
where statcod >= 80 and statcod < 90 /* Example status range for Packed */
and moddte between to_date(@start_date, 'YYYY-MM-DD') and to_date(@end_date, 'YYYY-MM-DD')
and wh_id = '[Your Warehouse ID]'
union all
/* 12. Staging for Shipment */
select
ordnum as WarehouseOrder,
'Staging for Shipment' as ActivityName,
cmpl_dte as EventStartTime,
cmpl_dte as EventEndTime,
mod_usr_id as UserOperatorId,
untqty as PlannedQuantity,
actqty as ActualQuantity,
dstloc as StorageLocation, /* Staging lane */
null as RequestedCompletionDate,
null as PriorityLevel,
'Blue Yonder WMS' as SourceSystem,
sysdate as LastDataUpdate
from invmov
where trncod = 'STG_MOVE' /* Move to staging transaction */
and cmpl_dte between to_date(@start_date, 'YYYY-MM-DD') and to_date(@end_date, 'YYYY-MM-DD')
and wh_id = '[Your Warehouse ID]'
union all
/* 13. Shipment Dispatched */
select
ordnum as WarehouseOrder,
'Shipment Dispatched' as ActivityName,
act_ship_dte as EventStartTime,
act_ship_dte as EventEndTime,
mod_usr_id as UserOperatorId,
ordqty as PlannedQuantity,
shpqty as ActualQuantity,
null as StorageLocation,
req_ship_dte as RequestedCompletionDate,
prifld as PriorityLevel,
'Blue Yonder WMS' as SourceSystem,
sysdate as LastDataUpdate
from ord_hdr
where statcod = 90 /* Status Shipped */
and act_ship_dte between to_date(@start_date, 'YYYY-MM-DD') and to_date(@end_date, 'YYYY-MM-DD')
and wh_id = '[Your Warehouse ID]'
union all
/* 14. Warehouse Order Completed */
select
ordnum as WarehouseOrder,
'Warehouse Order Completed' as ActivityName,
moddte as EventStartTime,
moddte as EventEndTime,
mod_usr_id as UserOperatorId,
ordqty as PlannedQuantity,
shpqty as ActualQuantity,
null as StorageLocation,
req_ship_dte as RequestedCompletionDate,
prifld as PriorityLevel,
'Blue Yonder WMS' as SourceSystem,
sysdate as LastDataUpdate
from ord_hdr
where statcod = 99 /* Status Completed/Closed */
and moddte between to_date(@start_date, 'YYYY-MM-DD') and to_date(@end_date, 'YYYY-MM-DD')
and wh_id = '[Your Warehouse ID]'
union all
/* 15. Warehouse Order Canceled */
select
ordnum as WarehouseOrder,
'Warehouse Order Canceled' as ActivityName,
moddte as EventStartTime,
moddte as EventEndTime,
mod_usr_id as UserOperatorId,
ordqty as PlannedQuantity,
null as ActualQuantity,
null as StorageLocation,
req_ship_dte as RequestedCompletionDate,
prifld as PriorityLevel,
'Blue Yonder WMS' as SourceSystem,
sysdate as LastDataUpdate
from ord_hdr
where statcod = 91 /* Example Canceled status */
and moddte between to_date(@start_date, 'YYYY-MM-DD') and to_date(@end_date, 'YYYY-MM-DD')
and wh_id = '[Your Warehouse ID]'
]Étapes
- Établissez une connexion à la base de données : Obtenez des identifiants en lecture seule et les paramètres de connexion (adresse du serveur, nom de la base de données, port) à la base sous-jacente de Blue Yonder WMS, généralement Oracle ou SQL Server. Connectez-vous à l’aide d’un client SQL standard, comme DBeaver, Oracle SQL Developer ou SQL Server Management Studio.
- Repérez les principales tables WMS : La requête fournie utilise des tables standard de Blue Yonder WMS, telles que
ord(commandes),pckwrk(travaux de préparation),wrkque(file d’attente des travaux),invmov(mouvements de stock) etlodhdr(en-tête de chargement). Vérifiez les noms des tables et la structure des colonnes dans le dictionnaire de données de votre système, car des personnalisations peuvent avoir été apportées. - Vérifiez et paramétrez la requête SQL : Copiez le script SQL fourni dans votre client SQL. Repérez les variables de substitution dans l’expression de table commune (CTE)
BaseOrders, au début du script. - Définissez la période : Modifiez les clauses
adddte >= 'YYYY-MM-DD'etadddte < 'YYYY-MM-DD'pour définir la période d’extraction. Pour une première analyse, une période de 3 à 6 mois est recommandée. - Appliquez les filtres propres à votre système : Modifiez le filtre
wh_id = '[Your_Warehouse_ID]'pour limiter l’extraction à un entrepôt donné. Au besoin, ajoutez ou modifiez d’autres filtres, commeclient_iddans les environnements multi-clients. - Exécutez le script d’extraction : Exécutez l’ensemble du script SQL. La requête rassemble les événements de plusieurs tables dans un journal d’événements unifié. La durée d’exécution dépend de la période sélectionnée et du volume de données.
- Vérifiez les premiers résultats : Une fois la requête terminée, examinez rapidement les résultats. Vérifiez que les colonnes
WarehouseOrder,ActivityNameetEventStartTimesont renseignées comme prévu. Le nombre de lignes doit être nettement supérieur au nombre de commandes d’entrepôt distinctes. - Exportez le journal d’événements : Exportez les résultats de la requête dans un fichier CSV. Vérifiez que l’encodage du fichier est UTF-8 afin d’éviter les problèmes d’encodage lors de l’importation.
- Préparez l’importation : Vérifiez que les en-têtes de colonnes du fichier CSV exporté correspondent aux attributs requis, par exemple
WarehouseOrder,ActivityNameetEventStartTime. Le fichier est prêt à être importé dans le logiciel de Process Mining.
Configuration
- Prérequis : Vous devez disposer d’un accès SQL en lecture seule à la base de données Blue Yonder WMS. Une bonne connaissance de la configuration WMS et du modèle de données propres à votre organisation est également très utile.
- Connexion à la base de données : Cette méthode nécessite une connexion directe à la base de données. Avant de commencer, vérifiez que les règles de pare-feu et les autorisations d’accès au réseau nécessaires sont en place.
- Filtrage par période : Il est essentiel de définir une période précise dans la clause
WHEREde la requête afin de maîtriser le volume de données. Une période de 3 à 6 mois suffit généralement pour obtenir une analyse pertinente sans solliciter excessivement la base de données. - Filtres sur l’entrepôt et le client : Dans les environnements comportant plusieurs entrepôts ou clients, filtrez toujours par
wh_id(identifiant de l’entrepôt) etclient_id(identifiant du client) afin de cibler l’analyse et de maîtriser le volume de données. - Performances : L’exécution de cette requête sur une base de données de production en service peut affecter les performances du système. Il est fortement recommandé de la lancer en dehors des heures de pointe ou, de préférence, sur une base de reporting dédiée ou répliquée, si elle est disponible.
- Personnalisations du système : La requête fournie utilise des noms de tables et de colonnes standard. Vous devrez peut-être les adapter aux personnalisations ou aux différences de version de votre instance Blue Yonder WMS. Pour obtenir de l’aide, consultez l’administrateur WMS de votre organisation ou le dictionnaire de données.
Exemple de requête sql
WITH BaseOrders AS (
SELECT
ordnum AS WarehouseOrder
FROM
ord
WHERE
adddte >= '2023-01-01' -- Placeholder: Set your start date
AND adddte < '2023-07-01' -- Placeholder: Set your end date
AND wh_id = '[Your_Warehouse_ID]' -- Placeholder: Set your warehouse ID
)
-- 1. Warehouse Order Created
SELECT
o.ordnum AS WarehouseOrder,
'Warehouse Order Created' AS ActivityName,
o.adddte AS EventStartTime,
o.adddte AS EventEndTime,
o.add_usr_id AS UserOperatorId,
o.req_shp_dte AS RequestedCompletionDate,
o.prirty AS PriorityLevel,
CAST(o.ordqty AS DECIMAL(18, 4)) AS PlannedQuantity,
NULL AS ActualQuantity,
NULL AS StorageLocation,
'Blue Yonder WMS' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM ord o
WHERE o.ordnum IN (SELECT WarehouseOrder FROM BaseOrders)
UNION ALL
-- 2. Inbound Delivery Notified (ASN Received)
SELECT
a.ordnum AS WarehouseOrder,
'Inbound Delivery Notified' AS ActivityName,
a.adddte AS EventStartTime,
a.adddte AS EventEndTime,
a.add_usr_id AS UserOperatorId,
a.exp_arv_dte AS RequestedCompletionDate,
NULL AS PriorityLevel,
CAST(ad.qtyord AS DECIMAL(18, 4)) AS PlannedQuantity,
NULL AS ActualQuantity,
NULL AS StorageLocation,
'Blue Yonder WMS' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM asnhdr a
JOIN asndtl ad ON a.asnhdr_id = ad.asnhdr_id
WHERE a.ordnum IN (SELECT WarehouseOrder FROM BaseOrders)
UNION ALL
-- 3. Goods Arrived at Dock
SELECT
t.ordnum AS WarehouseOrder,
'Goods Arrived at Dock' AS ActivityName,
t.checkin_dte AS EventStartTime,
t.checkin_dte AS EventEndTime,
t.usr_id AS UserOperatorId,
NULL AS RequestedCompletionDate,
NULL AS PriorityLevel,
NULL AS PlannedQuantity,
NULL AS ActualQuantity,
t.dock_loc AS StorageLocation,
'Blue Yonder WMS' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM trk_log t -- Note: Yard management table may vary
WHERE t.ordnum IN (SELECT WarehouseOrder FROM BaseOrders) AND t.checkin_dte IS NOT NULL
UNION ALL
-- 4. Goods Received and Counted
SELECT
i.ordnum AS WarehouseOrder,
'Goods Received and Counted' AS ActivityName,
i.moddte AS EventStartTime,
i.moddte AS EventEndTime,
i.mod_usr_id AS UserOperatorId,
NULL AS RequestedCompletionDate,
NULL AS PriorityLevel,
CAST(i.qtyexp AS DECIMAL(18, 4)) AS PlannedQuantity,
CAST(i.qtyrcv AS DECIMAL(18, 4)) AS ActualQuantity,
i.inv_loc AS StorageLocation,
'Blue Yonder WMS' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM rcvlin i -- Receiving Line table
WHERE i.ordnum IN (SELECT WarehouseOrder FROM BaseOrders) AND i.qtyrcv > 0
UNION ALL
-- 5. Quality Inspection Performed
SELECT
q.ordnum AS WarehouseOrder,
'Quality Inspection Performed' AS ActivityName,
q.insp_dte AS EventStartTime,
q.insp_dte AS EventEndTime,
q.usr_id AS UserOperatorId,
NULL AS RequestedCompletionDate,
NULL AS PriorityLevel,
CAST(q.insp_qty AS DECIMAL(18, 4)) AS PlannedQuantity,
CAST(q.act_qty AS DECIMAL(18, 4)) AS ActualQuantity,
q.stoloc AS StorageLocation,
'Blue Yonder WMS' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM qc_log q -- Quality Control log table may vary
WHERE q.ordnum IN (SELECT WarehouseOrder FROM BaseOrders) AND q.status = 'COMPLETED'
UNION ALL
-- 6. Putaway Task Created
SELECT
w.ordnum AS WarehouseOrder,
'Putaway Task Created' AS ActivityName,
w.adddte AS EventStartTime,
NULL AS EventEndTime,
w.add_usr_id AS UserOperatorId,
NULL AS RequestedCompletionDate,
w.wrkprt AS PriorityLevel,
CAST(w.untqty AS DECIMAL(18, 4)) AS PlannedQuantity,
NULL AS ActualQuantity,
w.frmloc AS StorageLocation, -- From receiving dock
'Blue Yonder WMS' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM wrkque w
WHERE w.ordnum IN (SELECT WarehouseOrder FROM BaseOrders) AND w.wrktyp = 'PUTAWAY'
UNION ALL
-- 7. Goods Put Away in Storage
SELECT
m.ordnum AS WarehouseOrder,
'Goods Put Away in Storage' AS ActivityName,
m.adddte AS EventStartTime,
m.adddte AS EventEndTime,
m.usr_id AS UserOperatorId,
NULL AS RequestedCompletionDate,
NULL AS PriorityLevel,
NULL AS PlannedQuantity,
CAST(m.movqty AS DECIMAL(18, 4)) AS ActualQuantity,
m.toloc AS StorageLocation, -- Destination storage location
'Blue Yonder WMS' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM invmov m -- Inventory Movement table
WHERE m.ordnum IN (SELECT WarehouseOrder FROM BaseOrders) AND m.trntyp = 'PUTFIN' -- Putaway Finish transaction type
UNION ALL
-- 8. Picking Task Created
SELECT
w.ordnum AS WarehouseOrder,
'Picking Task Created' AS ActivityName,
w.adddte AS EventStartTime,
NULL AS EventEndTime,
w.add_usr_id AS UserOperatorId,
o.req_shp_dte AS RequestedCompletionDate,
w.wrkprt AS PriorityLevel,
CAST(w.untqty AS DECIMAL(18, 4)) AS PlannedQuantity,
NULL AS ActualQuantity,
w.frmloc AS StorageLocation,
'Blue Yonder WMS' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM wrkque w
JOIN ord o ON w.ordnum = o.ordnum
WHERE w.ordnum IN (SELECT WarehouseOrder FROM BaseOrders) AND w.wrktyp = 'PICK'
UNION ALL
-- 9. Goods Picked from Storage
SELECT
p.ordnum AS WarehouseOrder,
'Goods Picked from Storage' AS ActivityName,
p.moddte AS EventStartTime,
p.moddte AS EventEndTime,
p.mod_usr_id AS UserOperatorId,
NULL AS RequestedCompletionDate,
NULL AS PriorityLevel,
CAST(p.pckqty AS DECIMAL(18, 4)) AS PlannedQuantity, -- Often planned and actual are the same here
CAST(p.pckqty AS DECIMAL(18, 4)) AS ActualQuantity,
p.pckloc AS StorageLocation,
'Blue Yonder WMS' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM pckwrk p
WHERE p.ordnum IN (SELECT WarehouseOrder FROM BaseOrders) AND p.wrksts = 'C' -- Status for Completed Pick
UNION ALL
-- 10. Packing Initiated
SELECT
s.ordnum AS WarehouseOrder,
'Packing Initiated' AS ActivityName,
s.moddte AS EventStartTime,
NULL AS EventEndTime,
s.mod_usr_id AS UserOperatorId,
NULL AS RequestedCompletionDate,
NULL AS PriorityLevel,
NULL AS PlannedQuantity,
NULL AS ActualQuantity,
s.pckstn AS StorageLocation, -- Packing Station
'Blue Yonder WMS' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM ord_status_log s -- Status log table may vary
WHERE s.ordnum IN (SELECT WarehouseOrder FROM BaseOrders) AND s.ordsta = 'PCK_START'
UNION ALL
-- 11. Goods Packed
SELECT
c.ordnum AS WarehouseOrder,
'Goods Packed' AS ActivityName,
c.moddte AS EventStartTime,
c.moddte AS EventEndTime,
c.mod_usr_id AS UserOperatorId,
NULL AS RequestedCompletionDate,
NULL AS PriorityLevel,
NULL AS PlannedQuantity,
CAST(c.actqty AS DECIMAL(18, 4)) AS ActualQuantity,
c.pckstn AS StorageLocation, -- Packing Station
'Blue Yonder WMS' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM ship_cntr c -- Shipping Container table
WHERE c.ordnum IN (SELECT WarehouseOrder FROM BaseOrders) AND c.cntr_sts = 'PACKED'
UNION ALL
-- 12. Staging for Shipment
SELECT
m.ordnum AS WarehouseOrder,
'Staging for Shipment' AS ActivityName,
m.adddte AS EventStartTime,
m.adddte AS EventEndTime,
m.usr_id AS UserOperatorId,
NULL AS RequestedCompletionDate,
NULL AS PriorityLevel,
NULL AS PlannedQuantity,
CAST(m.movqty AS DECIMAL(18, 4)) AS ActualQuantity,
m.toloc AS StorageLocation, -- Staging location
'Blue Yonder WMS' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM invmov m
WHERE m.ordnum IN (SELECT WarehouseOrder FROM BaseOrders) AND m.trntyp = 'STAGEMOV' -- Staging Movement transaction type
UNION ALL
-- 13. Shipment Dispatched
SELECT
l.ordnum AS WarehouseOrder,
'Shipment Dispatched' AS ActivityName,
l.shp_dte AS EventStartTime,
l.shp_dte AS EventEndTime,
l.mod_usr_id AS UserOperatorId,
NULL AS RequestedCompletionDate,
NULL AS PriorityLevel,
NULL AS PlannedQuantity,
CAST(sl.shpqty AS DECIMAL(18, 4)) AS ActualQuantity,
l.wh_id AS StorageLocation,
'Blue Yonder WMS' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM lodhdr l
JOIN ship_line sl ON l.lodnum = sl.lodnum
WHERE l.ordnum IN (SELECT WarehouseOrder FROM BaseOrders) AND l.lodsts = 'S' -- Shipped status
UNION ALL
-- 14. Warehouse Order Completed
SELECT
o.ordnum AS WarehouseOrder,
'Warehouse Order Completed' AS ActivityName,
o.moddte AS EventStartTime,
o.moddte AS EventEndTime,
o.mod_usr_id AS UserOperatorId,
o.req_shp_dte AS RequestedCompletionDate,
o.prirty AS PriorityLevel,
CAST(o.ordqty AS DECIMAL(18, 4)) AS PlannedQuantity,
CAST(o.shpqty AS DECIMAL(18, 4)) AS ActualQuantity,
NULL AS StorageLocation,
'Blue Yonder WMS' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM ord o
WHERE o.ordnum IN (SELECT WarehouseOrder FROM BaseOrders) AND o.ordsta = 'C' -- Status for Completed
UNION ALL
-- 15. Warehouse Order Canceled
SELECT
o.ordnum AS WarehouseOrder,
'Warehouse Order Canceled' AS ActivityName,
o.moddte AS EventStartTime,
o.moddte AS EventEndTime,
o.mod_usr_id AS UserOperatorId,
o.req_shp_dte AS RequestedCompletionDate,
o.prirty AS PriorityLevel,
CAST(o.ordqty AS DECIMAL(18, 4)) AS PlannedQuantity,
NULL AS ActualQuantity,
NULL AS StorageLocation,
'Blue Yonder WMS' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM ord o
WHERE o.ordnum IN (SELECT WarehouseOrder FROM BaseOrders) AND o.ordsta = 'X'; -- Status for CanceledPrêt à commencer ?
Appuyez-vous sur ce modèle pour lancer votre démarche de Process Mining et améliorer l’efficacité de vos opérations d’entrepôt. Commencez dès aujourd’hui à optimiser vos flux de marchandises !
Optimisez dès aujourd’hui l’efficacité de Blue Yonder WMS
Repérez les goulots d’étranglement, réduisez les erreurs de préparation et atteignez une précision de 99,5 % dans la gestion des stocks.
Aucune carte bancaire requise. Essai gratuit de 14 jours.