Votre template de données pour la gestion d’entrepôt
Votre template de données pour la gestion d’entrepôt
- Attributs recommandés pour une analyse complète
- Activités clés à suivre dans l’ensemble de votre flux de matières
- Recommandations pratiques pour extraire les données de Blue Yonder WMS
Attributs de la gestion d’entrepôt
| Nom | Description | ||
|---|---|---|---|
| Commande d'entrepôt WarehouseOrder | Identifiant unique d'une commande d'entrepôt, qui sert de cas principal pour suivre toutes les activités logistiques associées, de la création à la finalisation. | ||
| 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 donnée, 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. Dans le Process Mining, cet attribut sert à définir le cas et permet d'analyser de bout en bout l'ensemble du cycle de vie de la commande. En retraçant toutes les activités associées à une même commande d'entrepôt, les analystes peuvent mesurer les délais d'exécution totaux, identifier les variations courantes du processus et comprendre le parcours complet d'une commande dans l'installation. Pourquoi c’est important Il s'agit de l'identifiant de cas essentiel qui relie toutes les activités d'entrepôt associées et permet une analyse complète, de bout en bout, du processus d'exécution des commandes ou de réception des marchandises. Où les obtenir 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 auxquelles une tâche ou un événement d'entrepôt a été lancé. Il fournit le contexte chronologique de toutes les activités d'un cas. Cet horodatage est essentiel pour toutes les 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 à identifier les temps d'attente ou les retards. Il constitue la base de l'analyse de la performance et est nécessaire pour animer la carte du processus. Pourquoi c’est important L'horodatage de début est obligatoire pour ordonner les événements chronologiquement et calculer toutes les mesures de performance, telles que les temps de cycle et les temps d'attente. Où les obtenir Situé dans les tables des journaux d'événements ou des tâches, il correspond à la date de création ou à l'heure 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 d'entrepôt précis qui s'est produit, par exemple « Goods Picked » ou « Shipment Dispatched ». | ||
| Description Cet attribut décrit l’étape ou la tâche précise exécutée dans le processus de gestion d’entrepôt. Chaque événement du journal de processus est associé à un nom d’activité, qui forme la séquence des étapes composant le flux du processus. Dans l’analyse, le nom de l’activité est fondamental pour découvrir la carte des processus, analyser les transitions entre les étapes et identifier les goulots d’étranglement ou les écarts par rapport à la procédure standard. Il est utilisé dans presque toutes les analyses de Process Mining, de la vérification de la conformité au suivi des performances. Pourquoi c’est important Cet attribut est essentiel pour construire la carte du processus, car il définit les différentes étapes et permet de visualiser et d'analyser le flux du processus. Où les obtenir Cette information se trouve généralement dans les tables des tâches d'entrepôt ou des journaux d'événements, souvent dérivée d'un type de tâche ou d'un code de statut. Exemples Tâche de prélèvement crééeMarchandises prélevées du stockExpédition envoyée | |||
| Dernière mise à jour des données LastDataUpdate | Horodatage indiquant la dernière actualisation des données de cet enregistrement à partir du système source. | ||
| Description Cet attribut enregistre la date et l'heure auxquelles le jeu de données a été extrait ou mis à jour pour la dernière fois 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 comprendre l'actualité de leur analyse. Il garantit que les parties prenantes connaissent la période couverte par les données et peuvent se fier à un instantané récent et pertinent du processus. Pourquoi c’est important Cet horodatage informe les utilisateurs de l'actualité des données et leur permet de comprendre la période couverte par l'analyse. Où les obtenir Il s'agit d'un champ de métadonnées généralement généré et ajouté lors du processus d'extraction des données (ETL). Exemples 2024-01-15T04:00:00Z2024-01-16T04:00:00Z | |||
| Système source SourceSystem | Système à partir duquel les données ont été extraites, en l'occurrence Blue Yonder WMS. | ||
| Description Cet attribut identifie le système d'origine des données d'événements. Dans un environnement informatique moderne, les données d'un même processus de bout en bout peuvent provenir de plusieurs systèmes, tels qu'un ERP, un WMS et un TMS. La spécification du système source est essentielle à la gouvernance des données, au dépannage et à la compréhension de leur contexte. Elle aide à retracer les problèmes de qualité des données jusqu'à leur origine et est indispensable lors de la fusion de données provenant de plusieurs sources afin de créer une vue unifiée du processus. Pourquoi c’est important Il fournit la traçabilité essentielle des données et aide à les relier à leur origine pour les valider, notamment lorsque des données provenant de plusieurs systèmes sont fusionnées. Où les obtenir Il s'agit généralement d'une valeur statique 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, ou est censée, être terminée et expédiée. | ||
| Description La date d'achèvement demandée représente l'accord de niveau de service (SLA) ou l'objectif associé à l'exécution d'une commande d'entrepôt sortante. Il s'agit de la date limite à 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 la performance réelle. Elle est utilisée pour calculer le KPI du taux d'expédition dans les délais, en la comparant à l'horodatage réel de l'expédition. L'analyse des commandes selon cet attribut aide à identifier celles qui risquent d'être en retard et à déterminer les causes profondes des dépassements de SLA. Pourquoi c’est important Cet attribut sert de référence pour mesurer la performance dans les délais et est essentiel au calcul du KPI du taux d'expédition dans les délais. Où les obtenir Généralement stockée dans la table d'en-tête des commandes d'entrepôt, souvent héritée 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, tel qu'un emplacement ou une allée, où les marchandises sont stockées ou prélevées. | ||
| Description Cet attribut identifie l’emplacement physique de l’entrepôt associé à une tâche. Pour une activité de mise en stock, il s’agit du bac de destination. Pour une activité de prélèvement, il s’agit du bac source. Il peut être représenté par un code composé de l’allée, du rayonnage, de l’étagère et du numéro de bac. L’analyse des données par emplacement de stockage aide à comprendre l’efficacité de l’agencement de l’entrepôt, l’efficacité des stratégies d’affectation des emplacements et les déplacements des ressources. Elle sert à identifier les zones très fréquentées, les zones sous-utilisées et les goulots d’étranglement potentiels du flux de matières. Cet attribut est essentiel au Dashboard Storage Location Utilization Trends. Pourquoi c’est important Il fournit le contexte nécessaire pour analyser l’agencement de l’entrepôt, l’efficacité de la stratégie d’affectation des emplacements et l’identification des goulots d’étranglement liés aux déplacements. Où les obtenir Disponible dans les tables liées aux stocks, aux tâches d'entrepôt, notamment le prélèvement et la mise en stock, ainsi qu'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 auxquelles une tâche ou un événement d'entrepôt a été terminé. Lorsqu'il est disponible, il fournit une mesure précise du temps de traitement de chaque activité. La présence des heures de début et de fin permet une analyse plus détaillée de la performance. Elle permet de distinguer le temps d'attente, c'est-à-dire le temps entre les activités, du temps de traitement, qui correspond à la durée de l'activité elle-même. Cette distinction est essentielle pour déterminer si les retards sont dus à des périodes d'inactivité ou à des tâches trop longues à réaliser. Pourquoi c’est important Il permet de calculer précisément le temps de traitement d'une activité et de le distinguer du temps d'attente, ce qui est essentiel pour améliorer la performance de manière ciblée. Où les obtenir Situé dans les tables des journaux d'événements ou des tâches, il correspond à l'heure d'achèvement 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 exécuté l'activité. | ||
| Description Cet attribut enregistre l'identifiant unique de la personne responsable de l'exécution d'une tâche d'entrepôt donnée, comme le prélèvement, l'emballage ou la mise en stock. Il relie les activités du processus aux ressources humaines. L'analyse des activités par ID de l'utilisateur ou de l'opérateur est essentielle pour comprendre l'utilisation des ressources, la répartition de la charge de travail et la performance individuelle. Elle permet de répondre à des questions telles que : quels opérateurs sont les plus efficaces, lesquels pourraient avoir besoin d'une formation complémentaire, ou comment les tâches sont réparties au sein d'une équipe. Il s'agit d'une dimension principale du Dashboard d'utilisation des ressources de l'entrepôt. Pourquoi c’est important Cet attribut relie les étapes du processus aux personnes qui les ont exécutées et permet ainsi d'analyser la performance des ressources, la charge de travail et les besoins de formation. Où les obtenir On le trouve généralement dans les tables des tâches ou des transactions, associé à l'utilisateur connecté au système ou au terminal mobile pendant l'opération. Exemples JSMITHBWILLISAMILLER | |||
| Niveau de priorité PriorityLevel | Priorité de la commande d'entrepôt, par exemple « High », « Standard » ou « Low ». | ||
| Description Le niveau de priorité indique le degré d’urgence d’une commande d’entrepôt. Les commandes hautement prioritaires, comme les expéditions urgentes, sont censées être traitées plus rapidement que les commandes standard. Le WMS utilise cet attribut pour séquencer les tâches et affecter les ressources. Dans le Process Mining, cet attribut est essentiel pour analyser l’efficacité des stratégies de priorisation. Le Dashboard High Priority Order Fulfillment 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 hautement prioritaires avancent réellement plus vite dans le processus ou si elles restent bloquées dans les mêmes goulots d’étranglement. Pourquoi c’est important Il permet de déterminer si les commandes hautement prioritaires sont traitées plus rapidement que les commandes standard et de vérifier ainsi l'efficacité des règles de priorisation. Où les obtenir Cette information est généralement stockée dans la table d'en-tête des commandes d'entrepôt. Exemples ÉlevéeStandardFaible | |||
| Quantité planifiée PlannedQuantity | Quantité attendue d'articles pour une tâche donnée, par exemple la quantité à prélever ou à réceptionner. | ||
| Description La quantité planifiée représente le nombre cible d'unités indiqué 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, il s'agit de la quantité demandée par la commande client. Cet attribut est essentiel pour analyser la précision. En comparant la quantité planifiée à la quantité réelle, il devient possible d'identifier les écarts lors de la réception, du prélèvement ou du comptage des stocks. Il contribue directement à des KPI tels que 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 c’est important Elle sert de référence pour mesurer la précision et détecter les écarts de quantité lors des activités de réception et de prélèvement. Où les obtenir 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é réelle d'articles traités pendant une tâche, par exemple la quantité comptée ou prélevée physiquement. | ||
| 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, du nombre d'unités prélevées dans un emplacement de stockage ou de la quantité emballée dans un conteneur d'expédition. Comparé à la quantité planifiée, cet attribut révèle les exceptions et les erreurs du processus. Il constitue la mesure de référence pour calculer les taux d'écart, qui sont des indicateurs essentiels de la qualité opérationnelle. Ces données sont indispensables pour identifier les problèmes liés aux expéditions des fournisseurs, les erreurs de prélèvement ou les inexactitudes des stocks. Pourquoi c’est important La comparaison avec la quantité planifiée est essentielle pour identifier les erreurs du processus et calculer des KPI de qualité importants, tels que les taux d'écart. Où les obtenir Présente dans les tables de confirmation des tâches ou des journaux de transactions, où les opérateurs enregistrent la quantité exécutée. Exemples 1004924 | |||
| Écart de quantité IsQuantityMismatch | Indicateur booléen signalant si la quantité réelle traitée diffère de la quantité planifiée pour une tâche. | ||
| Description Cet attribut calculé est un indicateur simple qui signale un écart de quantité pour une tâche donnée, telle qu'un prélèvement ou une réception. Il prend la valeur vrai lorsque la « quantité réelle » est différente de la « quantité planifiée ». Cet indicateur sert à identifier et à comptabiliser facilement les erreurs du processus. Il simplifie le calcul de KPI tels que le taux d'écart de quantité au prélèvement et le taux d'écart de quantité à la réception. Il facilite également l'analyse des causes profondes en permettant aux analystes de filtrer tous les événements présentant un écart et de rechercher des tendances liées aux produits, aux opérateurs ou aux emplacements. Pourquoi c’est important Il signale les événements présentant des erreurs de quantité, simplifie le calcul des taux d'écart et permet une analyse ciblée des tâches imprécises. Où les obtenir 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 lorsque l'expédition a été effectuée à la date d'achèvement demandée ou avant celle-ci. | ||
| Description Cet attribut calculé fournit un indicateur simple, vrai ou faux, permettant de déterminer si une commande a respecté son SLA d'expédition. Il est obtenu en comparant l'horodatage de l'activité « Shipment Dispatched » à la date d'achèvement demandée de la commande. Cet indicateur simplifie l'analyse et la visualisation de la performance dans les délais. Il permet de filtrer et d'agréger facilement les données pour calculer le KPI du taux d'expédition dans les délais et alimenter le Dashboard correspondant. Il permet également d'analyser les causes profondes afin d'identifier les caractéristiques communes des expéditions en retard. Pourquoi c’est important Cet indicateur booléen simplifie le calcul du KPI du taux d'expédition dans les délais et permet de filtrer facilement les données pour analyser les caractéristiques des commandes en retard. Où les obtenir Calculé en comparant l'EventStartTime de l'activité « Shipment Dispatched » à l'attribut RequestedCompletionDate. Exemples truefalsetrue | |||
| ID de l'entrepôt WarehouseId | Identifiant de l'entrepôt ou du centre de distribution précis où l'activité a eu lieu. | ||
| Description L'ID de l'entrepôt identifie de manière unique l'installation dans laquelle le processus se déroule. Il est essentiel pour les organisations qui exploitent plusieurs centres de distribution. Cet attribut permet d'établir des comparaisons et des références de performance entre différents sites. En filtrant ou en répartissant les données par ID d'entrepôt, les entreprises peuvent comparer les performances, identifier les meilleures pratiques des sites les plus performants et comprendre pourquoi certaines installations accusent un retard. Il fournit une dimension essentielle à l'analyse opérationnelle multisite. Pourquoi c’est important Pour les organisations multisites, cet attribut est essentiel pour comparer les performances et les processus entre différents emplacements. Où les obtenir Il s'agit souvent d'un champ organisationnel de niveau supérieur 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é, tel qu'un chariot élévateur ou un convoyeur précis. | ||
| Description L'ID de l'équipement précise quelle machine ou quel équipement a été utilisé pour exécuter une tâche d'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 la performance des équipements ainsi que les besoins de maintenance. En suivant les activités par équipement, les responsables peuvent identifier 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. Il s'agit d'une dimension essentielle du Dashboard d'utilisation des ressources de l'entrepôt. Pourquoi c’est important Il permet d'analyser l'utilisation et la performance des équipements afin d'optimiser l'affectation des actifs et les calendriers de maintenance. Où les obtenir Peut être enregistré dans les journaux d'exécution des tâches, notamment dans les environnements où 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 lorsqu'elles sont expédiées dans le même camion ou conteneur. Pour une commande unique, il peut être identique au numéro de la commande d'entrepôt ou de la livraison. L'analyse par ID d'expédition fournit une vue du processus d'expédition. Elle peut aider à comprendre comment les commandes sont regroupées, à mesurer le temps écoulé entre la mise en préparation et l'expédition finale d'un chargement complet et à 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 c’est important Il regroupe les commandes d'entrepôt expédiées ensemble et permet d'analyser les processus de consolidation et d'expédition. Où les obtenir Présent dans les tables liées aux expéditions ou au transport, avec un lien vers les commandes d'entrepôt. Exemples SHP-45000123SHP-45000124SHP-45000125 | |||
| SKU du produit 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 d'entrepôt. Il fournit un niveau de détail précis sur les articles déplacés, stockés, prélevés et emballés. L'analyse du processus par SKU de produit peut révéler des tendances propres à certains articles. Par exemple, certains produits peuvent être plus sujets aux erreurs de prélèvement, nécessiter davantage de temps pour la mise en stock en raison de contraintes particulières de manutention ou être stockés dans des emplacements peu efficaces. Cette analyse permet d'optimiser les processus propres aux produits et d'améliorer les stratégies d'affectation des emplacements. Pourquoi c’est important Il permet une analyse au niveau du produit et aide à identifier les articles à l'origine de retards ou d'erreurs, ou qui nécessitent une manutention particulière. Où les obtenir Cette information se trouve au niveau de la ligne d'article dans les tables des commandes ou des tâches d'entrepôt. Exemples PN-A5540-BSKU-300-RED-LGHW-88201 | |||
| Statut de la tâche TaskStatus | Statut final d'une tâche donnée, par exemple « Completed », « Canceled » ou « Failed ». | ||
| Description Cet attribut décrit le résultat d'une tâche d'entrepôt précise. Si de nombreuses tâches se terminent correctement, certaines peuvent être annulées par un superviseur ou échouer en raison de problèmes système ou opérationnels. Il fournit davantage de contexte que le seul nom de l'activité. L'analyse par statut de tâche est utile pour 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 et nécessitant un examen approfondi. Pourquoi c’est important Il fournit le résultat d'une activité et permet d'analyser les exceptions, telles que les tâches annulées ou échouées, qui peuvent révéler des problèmes opérationnels plus profonds. Où les obtenir 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éAnnuléEn attente | |||
| Type de commande d'entrepôt WarehouseOrderType | Catégorise la commande d'entrepôt, par exemple comme une réception entrante, une expédition sortante ou un transfert interne. | ||
| Description Cet attribut classe la finalité globale de la commande d'entrepôt. Les types courants comprennent les livraisons entrantes des fournisseurs, les expéditions sortantes vers les clients, le traitement des retours ou les mouvements internes de stocks entre différents emplacements de l'entrepôt. La segmentation du processus par type de commande d'entrepôt constitue une première étape fondamentale de toute analyse. Les processus entrants et sortants sont souvent très différents, avec des étapes, des ressources et des objectifs de performance distincts. Cet attribut permet de filtrer les données afin d'analyser séparément un processus précis, tel que la réception des marchandises ou l'exécution des commandes. Pourquoi c’est important Il permet de séparer et de comparer différents processus, tels que les flux entrants et sortants, qui présentent des parcours et des objectifs distincts. Où les obtenir Présent dans la table d'en-tête des commandes d'entrepôt, généralement sous la forme d'un type de document ou d'une 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 de l’entrepôt. Il est généralement enregistré comme une transaction explicite lorsqu’une nouvelle commande est saisie dans Blue Yonder WMS, manuellement ou par l’intermédiaire d’une intégration. | ||
| Pourquoi c’est important Il s’agit du début officiel du processus. L’analyse du délai entre cet événement et l’achèvement de la commande fournit le délai total de préparation, essentiel pour mesurer l’efficacité globale et le respect des accords de niveau de service. Où les obtenir Cet événement est probablement enregistré dans une table d’en-tête de commande, au moyen de l’horodatage de création de l’enregistrement de la commande d’entrepôt. Recherchez les tables liées à Collecte À partir de l’horodatage de création de l’enregistrement 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. Il est enregistré lorsque le statut du cycle de vie de la commande est mis à jour sur « Completed » ou « Closed ». | ||
| Pourquoi c’est important Cette activité marque la fin définitive du cas de processus. Elle garantit que l'analyse du processus couvre le cycle de vie complet de chaque commande, du début à la fin. Où les obtenir 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 « Completed », « Closed » ou « Invoiced », ainsi que l'horodatage de ce changement de statut. Collecte Déduit de l'horodatage du dernier changement de statut dans l'en-tête de la commande. Type d’événement inferred | |||
| Expédition envoyée | Cet événement indique que les marchandises emballées ont été chargées sur le camion du transporteur et que celui-ci a quitté l'entrepôt. Il est généralement enregistré lorsqu'une « sortie de marchandises » est comptabilisée dans le système, ce qui finalise l'expédition. | ||
| Pourquoi c’est important Il s'agit d'une étape essentielle qui marque la fin de la responsabilité de l'entrepôt pour la commande. C'est le dernier point de données utilisé pour mesurer la performance des expéditions dans les délais et le délai d'exécution de bout en bout. Où les obtenir Il s'agit d'une transaction financière et logistique majeure, souvent appelée « Post Goods Issue » (PGI). L'horodatage de cette transaction correspond à l'heure d'expédition et est généralement enregistré dans les tables des livraisons sortantes ou des documents d'expédition. Collecte Horodatage de la transaction Post Goods Issue (PGI). Type d’événement explicit | |||
| Marchandises mises en stock | Cet événement confirme que les marchandises ont été déplacées et scannées avec succès dans leur emplacement de stockage désigné. 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 c’est important Il marque la fin du processus entrant et rend les stocks disponibles pour la préparation des commandes. L’analyse du délai entre la réception et cette étape est essentielle pour le Dashboard « Goods Receipt to Putaway Cycle Time ». Où les obtenir Enregistré sous la forme d’une transaction horodatée lorsque le statut de la tâche de rangement est mis à jour vers « Completed » ou « Confirmed ». Ces données se trouvent dans les tables des tâches d’entrepôt ou des ordres de transfert. Collecte Horodatage de confirmation de la tâche de rangement de l’entrepôt. Type d’événement explicit | |||
| Marchandises réceptionnées et comptées | Cet événement indique que les marchandises ont été déchargées, 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 agent de réception confirme dans le système les quantités reçues pour chaque article de la commande entrante. | ||
| Pourquoi c’est important Il s’agit d’une étape importante qui rend officiellement les stocks disponibles dans le système, même s’ils ne sont pas encore prêts pour la préparation des commandes. La durée et la précision de cette étape ont une incidence directe sur la visibilité des stocks et sur le début du rangement. Où les obtenir 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 aux changements de statut des lignes de livraison entrante vers « Received ». Collecte Horodatage de la transaction confirmant la réception des marchandises. Type d’événement explicit | |||
| Tâche de prélèvement créée | Cet événement indique la création d’une tâche destinée à un opérateur chargé de récupérer des marchandises dans un emplacement de stockage pour préparer une commande sortante. Il s’agit d’un événement explicite généré par le WMS lorsqu’une commande sortante est libérée pour le picking. | ||
| Pourquoi c’est important Il s’agit du début du processus sortant physique. L’analyse du délai entre la création de la commande et celle de la tâche de picking révèle les retards liés au traitement et à l’affectation des commandes. Où les obtenir 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 picking associées à la commande d’entrepôt. Collecte Horodatage de création de la tâche de picking générée par le système. Type d’événement explicit | |||
| Commande d'entrepôt annulée | Représente l'annulation d'une commande d'entrepôt avant son traitement ou son expédition complète. Cet événement est enregistré lorsqu'un utilisateur exécute une transaction d'annulation, ce qui met à jour le statut de la commande sur « Canceled ». | ||
| Pourquoi c’est important L'analyse des annulations aide à identifier les causes des échecs du processus, telles que l'indisponibilité des stocks ou les changements demandés par les clients. Il s'agit d'un événement terminal essentiel pour comprendre les écarts par rapport au processus et les abandons. Où les obtenir Il s'agit généralement d'un événement déduit du statut final de la commande d'entrepôt. L'horodatage du changement de statut sur « Canceled » ou « Deleted » serait utilisé. Collecte Déduit de l'horodatage d'un changement de statut sur « Canceled ». Type d’événement inferred | |||
| Emballage lancé | Cette activité marque le début du conditionnement à un poste d’emballage. Elle est généralement enregistrée lorsqu’un opérateur scanne les articles prélevés ou le contenant de la commande au poste de conditionnement pour commencer à préparer l’expédition. | ||
| Pourquoi c’est important Cet événement signale le transfert du picking vers le conditionnement. Il permet d’isoler cette étape du processus de préparation des commandes afin d’identifier les goulots d’étranglement propres à la zone de conditionnement. Où les obtenir Il peut s’agir d’un journal de transaction explicite provenant de l’interface utilisateur d’un poste de conditionnement. Il peut également être déduit de la première activité horodatée associée à un centre de travail de conditionnement pour la commande concernée. Collecte Horodatage de la transaction « Start Packing » à un poste de conditionnement. Type d’événement explicit | |||
| Inspection qualité effectuée | Représente un contrôle qualité effectué sur les marchandises reçues. Il peut s’agir d’une étape standard pour certains matériaux ou d’un événement déclenché par une exception. L’événement est enregistré lorsque l’inspecteur qualité saisit ses conclusions dans le système. | ||
| Pourquoi c’est important Les contrôles qualité peuvent constituer une source importante de retards dans le processus entrant. L’analyse de leur fréquence et de leur durée aide à identifier les problèmes de qualité chez les fournisseurs et les goulots d’étranglement du flux de travail d’inspection. Où les obtenir Enregistré dans les modules de Quality Management (QM) ou dans les journaux associés à la livraison entrante. Recherchez les codes de transaction correspondant aux résultats d’inspection qualité ou les changements de statut des stocks vers « Quality Hold ». Collecte Horodatage de la fin de l’inspection qualité ou de la mise à jour du statut. Type d’événement explicit | |||
| Livraison entrante annoncée | Représente la réception d’une Advanced Shipping Notification (ASN) envoyée par un fournisseur, indiquant que les marchandises sont en route vers l’entrepôt. Il s’agit d’un événement explicite enregistré lorsque l’ASN est reçue et traitée par le système, souvent via EDI ou un portail. | ||
| Pourquoi c’est important Cette activité déclenche la planification des opérations entrantes et l’affectation des ressources. Le délai entre cette notification et la réception physique des marchandises constitue un KPI important pour mesurer la performance des fournisseurs et la visibilité sur le flux entrant. Où les obtenir Enregistré dans les journaux de réception des ASN ou à partir 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. Collecte Horodatage de création d’une ASN ou 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. Cet événement est souvent enregistré explicitement par un module de gestion de cour ou lorsque l’agent de contrôle enregistre l’arrivée de la livraison. | ||
| Pourquoi c’est important Le suivi de l’heure d’arrivée permet de mesurer la ponctualité du transporteur et d’identifier les retards entre son arrivée et le début de la réception. Il met en évidence les éventuels goulots d’étranglement dans la gestion de cour ou au niveau des portes de réception. Où les obtenir Généralement enregistré dans un module de gestion de cour ou de contrôle des accès de Blue Yonder WMS. Il peut également s’agir d’un horodatage saisi manuellement par un agent de réception à l’arrivée du camion. Collecte Horodatage de la transaction d’enregistrement du transporteur. Type d’événement explicit | |||
| Marchandises emballées | Cet événement confirme que tous les articles d’une expédition ont été conditionnés dans des contenants 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 la fin du conditionnement de la commande. | ||
| Pourquoi c’est important Il marque la fin des activités créatrices de valeur dans l’entrepôt. Le délai entre cette étape et l’expédition correspond au temps de mise en attente et de chargement, une source potentielle importante de retards. Où les obtenir Il s’agit d’une transaction explicite enregistrée lorsque le conditionnement est finalisé. Recherchez un changement de statut de la livraison sortante vers « Packed » ou un horodatage de fin provenant de la transaction du poste de conditionnement. Collecte Horodatage de la transaction « Confirm Packing » ou « Close Container ». Type d’événement explicit | |||
| Marchandises prélevées du stock | Représente l’achèvement de la tâche de picking, lorsqu’un opérateur a récupéré les articles et confirmé l’opération dans le système. L’événement est enregistré lorsque l’opérateur scanne les articles et confirme le picking sur son terminal. | ||
| Pourquoi c’est important Cette étape clôt la phase de picking. La précision et la durée de cette activité sont essentielles à l’efficacité globale de la préparation des commandes et servent de base à l’analyse « Picking Accuracy ». Où les obtenir Capturé à partir de l’horodatage de confirmation lorsque le statut de la tâche de picking passe à « Completed ». Ces informations se trouvent dans les tables des tâches d’entrepôt, souvent associées à l’opérateur et à l’équipement concernés. Collecte Horodatage de confirmation de la tâche de picking de l’entrepôt. Type d’événement explicit | |||
| Mise en attente pour expédition | Représente le déplacement des contenants conditionnés de la zone de conditionnement vers une voie de mise en attente désignée pour l’expédition, dans l’attente de leur enlèvement par le transporteur. L’événement est enregistré lorsqu’un opérateur confirme le déplacement de l’unité de manutention vers la zone de mise en attente. | ||
| Pourquoi c’est important Cette activité permet d’analyser le temps d’attente, c’est-à-dire la durée pendant laquelle les commandes conditionnées attendent avant d’être chargées. Des temps d’attente élevés peuvent révéler une mauvaise coordination avec les transporteurs ou une utilisation inefficace de l’espace de mise en attente. Où les obtenir Cet événement peut être déduit d’un changement d’emplacement de l’unité de manutention ou du contenant d’expédition vers un emplacement de mise en attente. Il peut également correspondre à la confirmation explicite d’une tâche « Move to Stage ». Collecte Déduit des journaux de mouvements de stock indiquant un transfert vers un emplacement de mise en attente. Type d’événement inferred | |||
| Tâche de mise en stock 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 un emplacement de stockage final. Il s’agit d’un événement système explicite généré par la logique du WMS pour guider un opérateur d’entrepôt. | ||
| Pourquoi c’est important Il s’agit du début du processus de rangement. Les retards entre la réception des marchandises et la création de la tâche de rangement peuvent révéler des problèmes de configuration ou de performance du système, laissant les marchandises dans la zone de réception. Où les obtenir Généré et enregistré 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 associés à la livraison entrante. Collecte 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 la MOCA Console ou une interface en ligne de commande.
- Vérifier et personnaliser le script MOCA : Copiez le script MOCA fourni. Vérifiez attentivement les noms des tables et des colonnes afin de confirmer leur correspondance avec 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éfinir les paramètres d’extraction : Remplacez les variables d’espace réservé 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]'. - Se connecter au serveur MOCA : Lancez votre client MOCA, par exemple MOCA Console, puis établissez une connexion avec l’environnement Blue Yonder WMS approprié.
- Exécuter le script MOCA : Collez le script personnalisé dans MOCA Console. Exécutez la commande. Le script s’exécutera sur le serveur et recueillera les données correspondant à toutes les activités indiquées.
- Surveiller l’exécution : Pour les volumes importants, la requête peut nécessiter un temps d’exécution conséquent. Surveillez la console afin de détecter les messages d’erreur ou les avertissements de performance. Si la requête expire, envisagez de l’exécuter sur des périodes plus courtes.
- Exporter les résultats dans un fichier : Une fois le script exécuté avec succès, les résultats s’affichent dans la console. Utilisez la fonction d’export du client pour enregistrer la sortie au format CSV. En ligne de commande, vous pouvez notamment rediriger directement la sortie vers un fichier, par exemple :
mocarun -S "[Your MOCA Script]" > event_log.csv. - Formater 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 avec un encodage UTF-8 afin d’éviter les problèmes de caractères lors du chargement. - Vérifier et charger le fichier : Effectuez une dernière vérification du contenu du fichier afin de repérer d’éventuelles erreurs ou incohérences manifestes. Une fois cette vérification terminée, chargez 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. L’espace réservé au filtre de dates
@[where_clause_dates]doit être appliqué à la colonne d’horodatage principale de chaque instruction SELECT, commeadddteoumoddte. - Filtres sur l’entrepôt et le client : Utilisez toujours des filtres pour limiter le périmètre de l’extraction. L’espace réservé
@[where_clause_warehouse]doit servir à filtrer les identifiants d’entrepôt (wh_id) et, le cas échéant, les identifiants client (client_id). Cette étape est essentielle 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 dans les sections concernées du script. - Considérations de performance : Le script d’extraction joint et regroupe plusieurs tables volumineuses. Pour éviter d’affecter les performances du système, planifiez son exécution 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, constitue 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.
a 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
- Établir la connexion à la base de données : Obtenez des identifiants en lecture seule et les informations de connexion, notamment l’adresse du serveur, le nom de la base et le port, pour la base de données sous-jacente de Blue Yonder WMS, généralement Oracle ou SQL Server. Utilisez un client SQL standard tel que DBeaver, Oracle SQL Developer ou SQL Server Management Studio pour vous connecter.
- Identifier les tables WMS principales : La requête fournie s’appuie sur des tables Blue Yonder WMS standard telles que
ord(commandes),pckwrk(travaux de picking),wrkque(file de travaux),invmov(mouvements de stock) etlodhdr(en-tête de chargement). Vérifiez les noms de ces tables et la structure de leurs colonnes dans le dictionnaire de données de votre système, car des personnalisations peuvent exister. - Vérifier et paramétrer la requête SQL : Copiez le script SQL fourni dans votre client SQL. Repérez les variables d’espace réservé dans l’expression de table commune (CTE)
BaseOrders, au début du script. - Définir la période : Modifiez les clauses
adddte >= 'YYYY-MM-DD'etadddte < 'YYYY-MM-DD'afin de définir la période d’extraction. Pour une première analyse, une période de 3 à 6 mois est recommandée. - Appliquer les filtres propres au système : Modifiez le filtre
wh_id = '[Your_Warehouse_ID]'afin de limiter l’extraction à un entrepôt donné. Ajoutez ou modifiez d’autres filtres, commeclient_iddans les environnements multi-clients, selon vos besoins. - Exécuter le script d’extraction : Exécutez l’intégralité du script SQL. La requête consolide les événements issus de plusieurs tables dans un journal d’événements unifié. La durée d’exécution varie selon la période et le volume de données.
- Valider les premiers résultats : Une fois la requête terminée, examinez rapidement la sortie. 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. - Exporter 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 de caractères lors du chargement.
- Préparer le chargement : Confirmez que les en-têtes de colonnes du fichier CSV exporté correspondent aux attributs requis, par exemple
WarehouseOrder,ActivityNameetEventStartTime. Le fichier peut alors être chargé 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 vivement recommandée.
- 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 réseau nécessaires sont en place.
- Filtrage de la 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 imposer une charge excessive à la base de données. - Filtrage de l’entrepôt et du client : Dans les environnements comportant plusieurs entrepôts ou clients, filtrez toujours l’identifiant d’entrepôt (
wh_id) et l’identifiant client (client_id) concernés afin de cibler l’analyse et de conserver un volume de données maîtrisable. - Considérations de performance : L’exécution de cette requête sur une base de production active peut affecter les performances du système. Il est fortement recommandé de l’exécuter 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 en fonction des personnalisations ou des différences de version de votre instance Blue Yonder WMS. Consultez votre administrateur WMS interne ou votre dictionnaire de données.
a 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 ?
Utilisez ce template 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 votre flux de matières !
Atteignez dès aujourd’hui une efficacité maximale avec Blue Yonder WMS
Localisez les goulots d’étranglement, éliminez les erreurs de prélèvement et atteignez une précision des stocks de 99,5 %.
Aucune carte bancaire requise, essai gratuit de 14 jours.