Votre template de données de gestion d'entrepôt
Votre template de données de gestion d'entrepôt
- Attributs recommandés à collecter pour une analyse complète
- Activités clés à suivre tout au long de votre flux de matériaux
- Guide pratique pour l'extraction de données de Blue Yonder WMS
Attributs de gestion d'entrepôt
| Nom | Description | ||
|---|---|---|---|
| Commande d'entrepôt WarehouseOrder | L'identifiant unique d'une commande d'entrepôt, qui sert de cas principal pour le suivi de toutes les activités logistiques connexes, de la création à l'achèvement. | ||
| Description La commande d'entrepôt est l'identifiant central qui regroupe tous les événements et tâches liés à une demande logistique spécifique, telle qu'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 est utilisé pour définir le cas, permettant l'analyse de bout en bout du cycle de vie complet de la commande. En traçant toutes les activités associées à une seule commande d'entrepôt, les analystes peuvent mesurer les temps de traitement totaux, identifier les variations de processus courantes et comprendre le parcours complet d'une commande à travers l'installation. Pourquoi c'est important C'est l'identifiant de cas essentiel qui relie toutes les activités d'entrepôt connexes, permettant une analyse complète et de bout en bout du processus d'exécution des commandes ou de réception des marchandises. Où obtenir Ceci est typiquement la clé primaire dans la table d'en-tête de commande d'entrepôt. Consultez la documentation Blue Yonder WMS pour les tables liées à la gestion des commandes. Exemples WO-0012845WO-0012991WO-0013057 | |||
| Heure de Début de l'Événement EventStartTime | L'horodatage indiquant quand une activité ou un événement spécifique de l'entrepôt a commencé. | ||
| Description Cet attribut enregistre la date et l'heure à laquelle une tâche ou un événement d'entrepôt a été initié. Il fournit le contexte chronologique pour toutes les activités au sein d'un cas. Cet horodatage est essentiel pour toutes les analyses de Process Mining basées sur le temps. Il est utilisé pour ordonner les événements, calculer les temps de cycle entre les activités, mesurer la durée de l'ensemble du processus et identifier les temps d'attente ou les retards. Il constitue l'épine dorsale de l'analyse des performances et est requis pour animer la carte des processus. Pourquoi c'est important L'horodatage de début est obligatoire pour ordonner les événements chronologiquement et calculer toutes les métriques de performance, telles que les temps de cycle et les temps d'attente. Où obtenir Situé dans les journaux d'événements ou les tables de tâches, correspondant à 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 | Le nom de la tâche ou de l'événement spécifique de l'entrepôt qui s'est produit, tels que 'Marchandises prélevées' ou 'Expédition envoyée'. | ||
| Description Cet attribut décrit l'étape ou la tâche spécifique effectuée dans le processus de gestion d'entrepôt. Chaque événement dans le journal de processus est associé à un nom d'activité, formant la séquence d'étapes qui composent le flux de processus. En 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 pratiquement toutes les analyses de Process Mining, de la vérification de conformité à la surveillance des performances. Pourquoi c'est important Cet attribut est essentiel pour construire la carte des processus, car il définit les étapes individuelles et permet la visualisation et l'analyse du flux de processus. Où obtenir Ces informations se trouvent généralement dans les tables de tâches d'entrepôt ou de journaux d'événements, souvent dérivées d'un type de tâche ou d'un code de statut. Exemples Tâche de prélèvement crééeMarchandises prélevées en stockExpédition expédiée | |||
| 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 la fraîcheur des données analysées. Cet horodatage est important pour la gouvernance des données et pour que les utilisateurs comprennent la pertinence de leur analyse. Il garantit que les parties prenantes sont conscientes de l'actualité des données et peuvent avoir confiance qu'elles consultent un aperçu récent et pertinent du processus. Pourquoi c'est important Cet horodatage informe les utilisateurs sur la fraîcheur des données, garantissant qu'ils comprennent la période couverte par l'analyse. Où obtenir Il s'agit d'un champ de métadonnées généralement généré et ajouté pendant le processus d'extraction de données (ETL). Exemples 2024-01-15T04:00:00Z2024-01-16T04:00:00Z | |||
| Système source SourceSystem | Le système d'où les données ont été extraites, dans ce cas, Blue Yonder WMS. | ||
| Description Cet attribut identifie le système d'origine des données d'événement. Dans un paysage informatique moderne, les données pour un processus de bout en bout unique peuvent provenir de plusieurs systèmes, tels qu'un ERP, un WMS et un TMS. Spécifier le système source est crucial pour la gouvernance des données, le dépannage et la compréhension du contexte des données. Il aide à retracer les problèmes de qualité des données jusqu'à leur origine et est essentiel lors de la fusion de données provenant de plusieurs sources pour créer une vue unifiée du processus. Pourquoi c'est important Il fournit une lignée de données essentielle, aidant à tracer les données jusqu'à leur origine pour la validation et dans les scénarios où les données sont fusionnées à partir de plusieurs systèmes. Où obtenir Il s'agit généralement d'une valeur statique ajoutée pendant le processus d'extraction des données pour étiqueter l'origine de l'ensemble de données. Exemples BlueYonderWMS_USBlueYonderWMS_EU | |||
| Date d'achèvement demandée RequestedCompletionDate | La date et l'heure auxquelles la commande d'entrepôt est prévue ou demandée pour être complété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 pour l'exécution d'une commande d'entrepôt sortante. C'est la date limite à laquelle les marchandises devraient être prélevées, emballées et prêtes pour l'expédition. Cette date est la référence par rapport à laquelle la performance réelle est mesurée. Elle est utilisée pour calculer l'indicateur clé de performance (KPI) du Taux d'expédition à temps en la comparant à l'horodatage d'expédition réel. L'analyse des commandes basée sur cet attribut aide à identifier quelles commandes risquent d'être en retard et à diagnostiquer les causes profondes des violations de SLA. Pourquoi c'est important Cet attribut est la référence pour mesurer la performance à temps et est essentiel pour calculer le KPI du taux d'expédition à temps. Où obtenir Généralement stocké dans la table d'en-tête de commande d'entrepôt, souvent hérité de la commande client source ou de la demande de livraison. Exemples 2023-10-27T17:00:00Z2023-10-28T12:00:00Z2023-11-01T17:00:00Z | |||
| Emplacement de stockage StorageLocation | L'emplacement spécifique dans l'entrepôt, comme un bac ou une allée, où les marchandises sont stockées ou prélevées. | ||
| Description Cet attribut identifie l'emplacement physique dans l'entrepôt associé à une tâche. Pour une activité de mise en stock, c'est l'emplacement de destination. Pour une activité de prélèvement, c'est l'emplacement source. Cela pourrait être représenté comme un code composite incluant l'allée, le rayonnage, l'étagère et le numéro de bac. L'analyse des données par emplacement de stockage aide à comprendre l'efficacité de l'agencement de l'entrepôt, les stratégies de slotting et le mouvement des ressources. Elle est utilisée pour identifier les zones à fort trafic, les zones sous-utilisées et les goulots d'étranglement potentiels dans le flux de matériaux. Cet attribut est fondamental pour le dashboard des tendances d'utilisation des emplacements de stockage. Pourquoi c'est important Il fournit un contexte crucial pour analyser la disposition de l'entrepôt, l'efficacité de la stratégie de slotting et identifier les goulots d'étranglement de mouvement. Où obtenir Disponible dans les tables liées à l'inventaire, aux tâches d'entrepôt (picking, rangement) et aux données de base des emplacements. Exemples A1-R03-S02-B01B5-R10-S04-B05C2-R01-S01-B02 | |||
| Heure de fin de l'événement EventEndTime | L'horodatage indiquant quand une activité ou un événement spécifique de l'entrepôt a été terminé. | ||
| Description Cet attribut enregistre la date et l'heure à laquelle 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 pour chaque activité. Disposer d'une heure de début et de fin permet une analyse de performance plus détaillée. Il permet de séparer le temps d'attente (temps entre les activités) du temps de traitement (durée de l'activité elle-même). C'est crucial pour déterminer si les retards sont causés par des périodes d'inactivité ou par des tâches prenant trop de temps à s'achever. Pourquoi c'est important Il permet le calcul précis du temps de traitement des activités, le distinguant du temps d'attente, ce qui est essentiel pour une amélioration ciblée des performances. Où obtenir Situé dans les journaux d'événements ou les tables de tâches, correspondant à 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 | |||
| Niveau de priorité PriorityLevel | La priorité de la commande d'entrepôt, telle que 'Élevée', 'Standard' ou 'Basse'. | ||
| Description Le niveau de priorité indique l'urgence d'une commande d'entrepôt. Les commandes à haute priorité, telles que les expéditions accélérées, sont censées être traitées plus rapidement que les commandes standard. Cet attribut est utilisé par le WMS pour séquencer les tâches et allouer les ressources. En Process Mining, cet attribut est crucial pour analyser si les stratégies de priorisation sont efficaces. Le dashboard d'exécution des commandes prioritaires s'appuie sur ce champ pour filtrer les commandes urgentes et comparer leurs temps de cycle avec ceux des commandes standard. Il aide à vérifier si les commandes à haute priorité progressent réellement plus rapidement dans le processus ou si elles sont bloquées par les mêmes goulots d'étranglement. Pourquoi c'est important Cela permet d'analyser si les commandes à haute priorité sont traitées plus rapidement que les commandes standard, validant l'efficacité des règles de priorisation. Où obtenir Ces informations sont généralement stockées dans la table d'en-tête de commande d'entrepôt. Exemples ÉlevéStandardFaible | |||
| Quantité Planifiée PlannedQuantity | La quantité prévue d'articles pour une tâche donnée, telle que la quantité à prélever ou à recevoir. | ||
| Description La Quantité Planifiée représente le nombre d'unités cibles spécifié par la commande d'entrepôt pour une tâche particulière. Pour une livraison entrante, c'est la quantité attendue du fournisseur. Pour une tâche de picking, c'est la quantité demandée par la commande client. Cet attribut est essentiel pour l'analyse de la précision. En comparant la Quantité Planifiée à la Quantité Réelle, il devient possible d'identifier les écarts dans les réceptions, le picking ou les comptages d'inventaire. Il soutient directement des KPI tels que le Taux d'écart de quantité de picking et est essentiel pour le tableau de bord d'audit de la précision des quantités. Pourquoi c'est important Il sert de base pour mesurer la précision, permettant la détection des écarts de quantité dans les activités de réception et de picking. Où obtenir Trouvé dans les tables de détails ou de lignes associées aux commandes d'entrepôt ou à des tâches spécifiques. Exemples 1005024 | |||
| Quantité réelle ActualQuantity | La quantité réelle d'articles traités pendant une tâche, telle que la quantité physiquement comptée ou prélevée. | ||
| Description La Quantité Réelle est le nombre d'unités physiquement traitées par un opérateur d'entrepôt au cours d'une tâche. Il peut s'agir du nombre d'articles reçus d'un fournisseur, du nombre d'unités prélevées d'un bac 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 de processus. C'est la métrique fondamentale pour calculer les taux d'anomalies, qui sont des indicateurs clés de la qualité opérationnelle. Ces données sont vitales pour identifier les problèmes liés aux expéditions des fournisseurs, aux erreurs de picking ou aux inexactitudes d'inventaire. Pourquoi c'est important La comparaison avec la quantité planifiée est essentielle pour identifier les erreurs de processus et calculer les KPI de qualité clés comme les taux d'anomalies. Où obtenir Trouvé dans les tables de confirmation de tâche ou de journal de transactions, où les opérateurs enregistrent la quantité exécutée. Exemples 1004924 | |||
| User/Operator ID UserOperatorId | L'identifiant de l'employé d'entrepôt ou de l'opérateur qui a effectué 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, telle que le prélèvement, l'emballage ou la mise en stock. Il relie les activités de processus aux ressources humaines. L'analyse des activités par ID utilisateur/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, qui pourrait nécessiter une formation supplémentaire, ou comment les tâches sont équilibrées au sein d'une équipe. C'est une dimension essentielle pour le 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, permettant l'analyse des performances des ressources, de la charge de travail et des besoins en formation. Où obtenir Généralement trouvé dans les tables de tâches ou de transactions, lié à l'utilisateur connecté au système ou à l'appareil portable pendant l'opération. Exemples JSMITHBWILLISAMILLER | |||
| Est un écart de quantité IsQuantityMismatch | Un drapeau booléen indiquant si la quantité réelle traitée diffère de la quantité planifiée pour une tâche. | ||
| Description Cet attribut calculé est un simple indicateur qui signale un écart de quantité pour une tâche donnée, telle que le prélèvement ou la réception. Il est défini sur vrai lorsque la 'Quantité Réelle' ne correspond pas à la 'Quantité Planifiée'. Cet indicateur est utilisé pour identifier et compter facilement les erreurs au sein du processus. Il simplifie le calcul des KPI tels que le Taux d'écart de quantité de prélèvement et le Taux d'écart de quantité d'entrée. Il facilite également l'analyse des causes profondes en permettant aux analystes de filtrer tous les événements de non-concordance et de rechercher des schémas liés aux produits, aux opérateurs ou aux emplacements. Pourquoi c'est important Il signale les événements avec des erreurs de quantité, simplifiant le calcul des taux d'anomalies et permettant une analyse ciblée des tâches imprécises. Où obtenir Calculé en comparant les champs PlannedQuantity et ActualQuantity pour chaque activité pertinente. Exemples fauxtruefaux | |||
| Est une expédition à temps IsOnTimeShipment | Un indicateur booléen qui est vrai si l'expédition a été effectuée à la date de fin demandée ou avant. | ||
| Description Cet attribut calculé fournit un simple indicateur vrai ou faux indiquant si une commande a respecté son SLA d'expédition. Il est dérivé en comparant l'horodatage de l'activité 'Expédition envoyée' avec la 'Date d'achèvement demandée' pour la commande. Cet indicateur simplifie l'analyse et la visualisation de la performance à temps. Il permet un filtrage et une agrégation faciles pour calculer le KPI du taux d'expédition à temps et alimenter le dashboard correspondant. Il permet également l'analyse des causes profondes pour 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 à temps et permet un filtrage facile pour analyser les caractéristiques des commandes en retard. Où obtenir Calculé en comparant l'EventStartTime de l'activité « Expédition effectuée » à l'attribut RequestedCompletionDate. Exemples truefauxtrue | |||
| ID d'Équipement EquipmentId | Identifiant de l'équipement de manutention utilisé, tel qu'un chariot élévateur ou un convoyeur spécifique. | ||
| Description L'ID d'équipement spécifie quelle machine ou quel équipement a été utilisé pour effectuer une tâche d'entrepôt. Cela peut inclure des chariots élévateurs, des transpalettes, des véhicules guidés automatisés (AGV) ou des stations d'emballage spécifiques. Cet attribut permet d'analyser l'utilisation de l'équipement, ses performances et ses besoins en 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 collecter des données pour éclairer les plannings de maintenance. C'est une dimension clé pour le dashboard d'utilisation des ressources de l'entrepôt. Pourquoi c'est important Il permet l'analyse de l'utilisation et de la performance des équipements, aidant à optimiser l'allocation des actifs et les plannings de maintenance. Où obtenir Peut être enregistré dans les journaux d'exécution des tâches, en particulier dans les environnements où les opérateurs se connectent à l'équipement. Exemples FORKLIFT-07AGV-03PACKSTATION-12 | |||
| ID d'expédition ShipmentId | L'identifiant unique de l'expédition sortante à laquelle une commande d'entrepôt appartient. | ||
| Description L'ID d'expédition est un identifiant de niveau supérieur qui peut regrouper plusieurs commandes d'entrepôt si elles sont expédiées dans le même camion ou conteneur. Pour une seule commande, il peut être identique au numéro de commande d'entrepôt ou de livraison. L'analyse par ID d'expédition offre une vue du processus d'expédition. Elle peut aider à comprendre comment les commandes sont consolidées, à mesurer le temps écoulé entre le regroupement et l'expédition finale pour 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 d'approvisionnement. Pourquoi c'est important Il regroupe les commandes d'entrepôt expédiées ensemble, permettant l'analyse des processus de consolidation et d'expédition. Où obtenir Trouvé dans les tables liées aux expéditions ou au transport, rattaché aux commandes d'entrepôt. Exemples SHP-45000123SHP-45000124SHP-45000125 | |||
| ID de l'entrepôt WarehouseId | Identifiant de l'entrepôt ou du centre de distribution spécifique où l'activité a eu lieu. | ||
| Description L'ID d'entrepôt identifie de manière unique l'installation dans laquelle le processus se déroule. C'est essentiel pour les organisations qui exploitent plusieurs centres de distribution. Cet attribut permet l'analyse comparative et l'analyse comparative entre différents sites. En filtrant ou en divisant les données par ID d'entrepôt, les entreprises peuvent comparer les performances, identifier les meilleures pratiques sur les sites les plus performants et comprendre pourquoi certaines installations sont à la traîne. Il fournit une dimension cruciale pour l'analyse opérationnelle multi-sites. Pourquoi c'est important Pour les organisations multisites, cet attribut est essentiel pour l'analyse comparative des performances et la comparaison des processus entre les différents sites. Où obtenir Ceci est souvent un champ organisationnel de haut niveau disponible dans presque toutes les tables de transactions, ou il peut être déduit de l'instance du système. Exemples WHC-01DC-EAST-03FAC-WEST | |||
| SKU du produit ProductSku | L'unité de gestion des stocks (SKU) ou le numéro de matériau de l'article en cours de traitement. | ||
| Description Cet attribut identifie le produit spécifique impliqué dans une tâche d'entrepôt. Il fournit des détails granulaires sur les matériaux déplacés, stockés, prélevés et emballés. L'analyse du processus par SKU de produit peut révéler des schémas liés à des articles spécifiques. Par exemple, certains produits peuvent être sujets à des erreurs de prélèvement, avoir des temps de mise en stock plus longs en raison d'exigences de manipulation spéciales, ou être stockés dans des emplacements inefficaces. Cela permet une optimisation des processus spécifiques aux produits et l'amélioration des stratégies de slotting. Pourquoi c'est important Il permet une analyse au niveau du produit, aidant à identifier les articles qui causent des retards de processus, des erreurs ou nécessitent une manutention spéciale. Où obtenir Cette information se trouve au niveau de la ligne d'article des tables de commande d'entrepôt ou de tâches. Exemples PN-A5540-BSKU-300-RED-LGHW-88201 | |||
| Statut de la tâche TaskStatus | Le statut final d'une tâche donnée, tel que 'Terminée', 'Annulée' ou 'Échouée'. | ||
| Description Cet attribut décrit le résultat d'une tâche d'entrepôt spécifique. Bien que de nombreuses tâches se terminent avec succès, certaines peuvent être annulées par un superviseur ou échouer en raison de problèmes système ou opérationnels. Cela fournit plus de contexte que le simple nom de l'activité. L'analyse par statut de tâche est utile pour comprendre les exceptions et les échecs de processus. Un taux élevé de tâches annulées ou échouées peut indiquer 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 à identifier les activités sujettes aux échecs et nécessitant une enquête approfondie. Pourquoi c'est important Il fournit le résultat d'une activité, permettant l'analyse des exceptions comme les tâches annulées ou échouées qui peuvent indiquer des problèmes opérationnels plus profonds. Où obtenir Généralement trouvé dans la table des tâches, indiquant l'état final de l'enregistrement de la tâche. Exemples TerminéAnnuléEn Attente | |||
| Temps de traitement de l'activité ActivityProcessingTime | La durée, en secondes ou en minutes, nécessaire pour accomplir une seule activité. | ||
| Description Ceci est une métrique calculée qui mesure le temps écoulé entre le début et la fin d'une activité. Elle représente le temps réel passé à travailler sur une tâche, par opposition au temps passé à attendre que la tâche commence. Cette métrique est fondamentale pour l'analyse des performances, aidant à identifier les activités spécifiques les plus chronophages. Elle permet aux analystes de distinguer les étapes de processus intrinsèquement lentes des retards qui surviennent entre les étapes, permettant des efforts d'amélioration plus ciblés. C'est une métrique clé pour les dashboards axés sur le débit et les goulots d'étranglement. Pourquoi c'est important Il isole le temps passé à travailler activement sur une tâche, aidant à identifier quelles activités spécifiques prennent le plus de temps à être complétées. Où obtenir Calculé en soustrayant EventStartTime de EventEndTime pour chaque enregistrement d'activité. Exemples 31229515 | |||
| 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 l'objectif global de la commande d'entrepôt. Les types courants incluent les livraisons entrantes des fournisseurs, les expéditions sortantes vers les clients, le traitement des retours ou les mouvements de stock internes entre les emplacements d'entrepôt. Segmenter le processus par type de commande d'entrepôt est une première étape fondamentale dans toute analyse. Les processus d'entrée et de sortie sont souvent significativement différents, avec des étapes, des ressources et des objectifs de performance distincts. Cet attribut permet de filtrer les données pour analyser un processus spécifique, tel que la réception de marchandises ou l'exécution de commandes, de manière isolée. Pourquoi c'est important Il permet la séparation et l'analyse comparative de différents processus, tels que les flux entrants et sortants, qui ont des flux et des objectifs distincts. Où obtenir Trouvé dans la table d'en-tête de commande d'entrepôt, généralement comme type de document ou champ 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, qui est le document central pour la gestion des tâches d'entrepôt entrantes, sortantes ou internes. Il est généralement enregistré comme une transaction explicite lorsqu'une nouvelle commande est saisie dans le Blue Yonder WMS, soit manuellement, soit via une intégration. | ||
| Pourquoi c'est important C'est le début définitif du processus. L'analyse du temps écoulé entre cet événement et l'achèvement fournit le délai total d'exécution des commandes, ce qui est essentiel pour mesurer l'efficacité globale et le respect des accords de niveau de service. Où obtenir Cet événement est probablement enregistré dans une table d'en-tête de commande, capturé par l'horodatage de création de l'enregistrement de la commande d'entrepôt. Recherchez les tables liées à Capture À 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 | Ceci est le statut final de la commande d'entrepôt, indiquant 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 à 'Terminée' ou 'Fermée'. | ||
| Pourquoi c'est important Cette activité marque la fin définitive du cas de processus. Elle garantit que l'analyse de processus capture le cycle de vie complet de chaque commande, du début à la fin. Où obtenir Cela peut être déduit d'un changement de statut dans la table d'en-tête de commande d'entrepôt. Recherchez un statut final comme 'Terminée', 'Fermée' ou 'Facturée', ainsi que l'horodatage de ce changement de statut. Capture Déduit de l'horodatage du dernier changement de statut sur l'en-tête de commande. Type d'événement inferred | |||
| Expédition expédiée | Cet événement signifie que les marchandises emballées ont été chargées sur le camion du transporteur et que le camion a quitté l'entrepôt. Cela est généralement enregistré lorsqu'une 'Sortie de marchandises' est postée dans le système, finalisant l'expédition. | ||
| Pourquoi c'est important C'est une étape critique qui marque la fin de la responsabilité de l'entrepôt pour la commande. C'est le dernier point de données pour mesurer la performance d'expédition à temps et le délai de traitement de bout en bout. Où obtenir Ceci est une transaction financière et logistique majeure, souvent appelée 'Sortie de Marchandises' (PGI). L'horodatage de cette transaction sert d'heure d'expédition et est généralement stocké dans les tables de documents de livraison sortante ou d'expédition. Capture Horodatage de la transaction de 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 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 mise en stock, généralement à l'aide d'un appareil RF portable. | ||
| Pourquoi c'est important Ceci marque la fin du processus d'entrée, rendant l'inventaire disponible pour l'exécution. L'analyse du temps écoulé entre la réception et ce point est cruciale pour le dashboard 'Temps de cycle réception de marchandises à mise en stock'. Où obtenir Enregistré comme une transaction horodatée lorsque le statut de la tâche de mise en stock est mis à jour à 'Terminée' ou 'Confirmée'. Ces données se trouvent dans les tables des tâches d'entrepôt ou des ordres de transfert. Capture Horodatage de confirmation de la tâche de rangement de l'entrepôt. Type d'événement explicit | |||
| Marchandises reçues et comptées | Cet événement signifie que les marchandises ont été déchargées, scannées et leurs quantités vérifiées par rapport aux documents de livraison. Il est généralement enregistré lorsqu'un commis à la réception confirme les quantités reçues dans le système pour chaque article de la commande entrante. | ||
| Pourquoi c'est important C'est une étape critique qui rend l'inventaire officiellement disponible dans le système, bien qu'il ne soit pas encore prêt pour l'exécution. La durée et la précision de cette étape impactent directement la visibilité des stocks et le début du processus de mise en stock. Où obtenir Ceci est une transaction explicite enregistrée dans les journaux d'inventaire ou de réception. Recherchez les transactions liées à l'enregistrement de la réception des marchandises ou aux changements de statut sur les articles de la livraison entrante à 'Reçue'. Capture 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 signifie la création d'une tâche pour un opérateur afin de prélever des marchandises d'un emplacement de stockage pour exécuter une commande sortante. C'est un événement explicite généré par le WMS lorsqu'une commande sortante est libérée pour le prélèvement. | ||
| Pourquoi c'est important C'est le début du processus physique de sortie. L'analyse du temps écoulé entre la création de la commande et la création de la tâche de prélèvement révèle les retards dans le traitement et l'allocation des commandes. Où obtenir Enregistré dans les tables de gestion des tâches ou de contrôle d'entrepôt. Il correspond à l'horodatage de création des tâches de picking associées à la commande d'entrepôt. Capture 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 qu'elle ne soit entièrement traitée ou expédiée. Cet événement est enregistré lorsqu'un utilisateur exécute une transaction d'annulation, mettant à jour le statut de la commande à 'Annulée'. | ||
| Pourquoi c'est important L'analyse des annulations aide à identifier les raisons des échecs de processus, tels que l'indisponibilité des stocks ou les changements de client. C'est un événement de terminaison critique pour comprendre les déviations de processus et leurs conséquences. Où obtenir Ceci est typiquement un événement déduit basé sur le statut final de la commande d'entrepôt. L'horodatage du changement de statut à 'Annulée' ou 'Supprimée' serait utilisé. Capture Déduit de l'horodatage d'un changement de statut à « Annulé ». Type d'événement inferred | |||
| Emballage initié | Cette activité marque le début du processus d'emballage à une station d'emballage. Elle est généralement enregistrée lorsqu'un opérateur scanne les articles prélevés ou le bac de commande à la station d'emballage pour commencer à préparer l'expédition. | ||
| Pourquoi c'est important Cet événement signale le passage du prélèvement à l'emballage. Il aide à isoler l'étape d'emballage du processus d'exécution pour identifier les goulots d'étranglement spécifiques au sein de la zone d'emballage. Où obtenir Ceci peut être un journal de transactions explicite provenant de l'interface utilisateur d'une station d'emballage. Alternativement, il pourrait être déduit de la première activité horodatée associée à un centre de travail d'emballage pour cette commande. Capture Horodatage de la transaction 'Démarrer l'emballage' à une station d'emballage. 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é en raison d'exceptions, et il est enregistré lorsqu'un inspecteur qualité consigne ses observations dans le système. | ||
| Pourquoi c'est important Les inspections qualité peuvent être une source de retard importante dans le processus d'entrée. L'analyse de leur fréquence et de leur durée aide à identifier les problèmes de qualité avec les fournisseurs et les goulots d'étranglement dans le workflow d'inspection. Où obtenir Enregistré dans les modules ou journaux de Gestion de la Qualité (QM) associés à la livraison entrante. Recherchez les codes de transaction spécifiques pour les résultats d'inspection qualité ou les changements de statut de l'inventaire à 'Maintien Qualité'. Capture Horodatage de l'achèvement de l'inspection qualité ou de la mise à jour du statut. Type d'événement explicit | |||
| Livraison entrante notifiée | Représente la réception d'un avis d'expédition anticipé (ASN) d'un fournisseur, indiquant que les marchandises sont en transit vers l'entrepôt. Il s'agit d'un événement explicite enregistré lorsqu'un ASN est reçu et traité par le système, souvent via EDI ou un portail. | ||
| Pourquoi c'est important Cette activité est le déclencheur de la planification des entrées et de l'allocation des ressources. Le délai entre cette notification et la réception physique des marchandises est un KPI clé pour mesurer la performance des fournisseurs et la visibilité du pipeline d'entrée. Où obtenir Capturé à partir des journaux de réception des ASN ou de l'horodatage de création du document de livraison entrante dans Blue Yonder WMS. Vérifiez les tables liées aux ASN ou aux notifications d'expédition entrantes. Capture Horodatage de la création d'un 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 lorsqu'un agent d'entrée enregistre la livraison. | ||
| Pourquoi c'est important Le suivi de l'heure d'arrivée aide à mesurer la performance à temps du transporteur et identifie les retards entre l'arrivée du transporteur et le début du processus de réception. Il met en évidence les goulots d'étranglement potentiels dans la gestion de la cour ou aux portes de réception. Où obtenir Généralement enregistré dans un module de gestion de cour ou de contrôle d'accès au sein de Blue Yonder WMS. Il pourrait également s'agir d'une saisie manuelle d'horodatage par un commis à la réception lors de l'arrivée du camion. Capture 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é emballés dans des conteneurs d'expédition et que les étiquettes ont été générées. Il est enregistré lorsque l'emballeur confirme l'achèvement du processus d'emballage pour la commande dans le système. | ||
| Pourquoi c'est important Ceci marque l'achèvement des activités à valeur ajoutée à l'intérieur de l'entrepôt. Le temps écoulé entre ce point et l'expédition représente le temps de regroupement et de chargement, une zone clé pour les retards potentiels. Où obtenir Ceci est une transaction explicite enregistrée lorsque le processus d'emballage est finalisé. Recherchez un changement de statut sur la livraison sortante à 'Emballée' ou un horodatage de fin de la transaction de la station d'emballage. Capture Horodatage de la transaction 'Confirmer l'emballage' ou 'Fermer le conteneur'. Type d'événement explicit | |||
| Marchandises prélevées en stock | Représente l'achèvement de la tâche de prélèvement, où un opérateur a récupéré les articles et confirmé l'action dans le système. L'événement est enregistré lorsque l'opérateur scanne les articles et confirme le prélèvement sur son appareil. | ||
| Pourquoi c'est important Cette étape conclut la phase de prélèvement. La précision et la durée de cette activité sont critiques pour l'efficacité globale de l'exécution des commandes et constituent la base de l'analyse de la 'Précision du prélèvement'. Où obtenir Capturé à partir de l'horodatage de confirmation lorsque le statut de la tâche de picking passe à « Terminé ». Ceci se trouve dans les tables des tâches d'entrepôt, souvent lié à l'opérateur et à l'équipement spécifiques. Capture Horodatage de confirmation de la tâche de picking de l'entrepôt. Type d'événement explicit | |||
| Regroupement pour expédition | Représente le déplacement de conteneurs emballés de la zone d'emballage vers une zone de regroupement d'expédition désignée pour attendre l'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 regroupement. | ||
| Pourquoi c'est important Cette activité aide à analyser le temps de latence, la période pendant laquelle les commandes emballées attendent avant d'être chargées. Des temps de regroupement longs peuvent indiquer une mauvaise coordination avec les transporteurs ou une utilisation inefficace de l'espace de regroupement. Où obtenir 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 de regroupement. Il peut aussi s'agir d'une confirmation de tâche explicite 'Déplacer vers la zone de regroupement'. Capture Déduit des journaux de mouvements d'inventaire montrant le transfert vers un emplacement de préparation. 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 pour déplacer les marchandises reçues du quai de réception vers un emplacement de stockage final. C'est un événement système explicite généré par la logique du WMS pour diriger un opérateur d'entrepôt. | ||
| Pourquoi c'est important C'est le début du processus de mise en stock. Les retards entre la réception des marchandises et la création de la tâche de mise en stock peuvent indiquer des problèmes de configuration système ou de performance, laissant les marchandises en attente dans la zone de réception. Où obtenir Généré et enregistré dans les tables de gestion des tâches ou de contrôle d'entrepôt. Recherchez l'horodatage de création des tâches de rangement ou des ordres de transfert liés à la livraison entrante. Capture 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: Assurez-vous de disposer d'un compte utilisateur Blue Yonder WMS avec les permissions nécessaires pour exécuter les commandes MOCA et accéder aux tables requises, telles que ord_hdr, pckwrk_dtl et invmov. Vous aurez besoin d'un client MOCA, comme la MOCA Console ou une interface de ligne de commande.
- Examiner et personnaliser le script MOCA: Copiez le script MOCA fourni. Examinez attentivement les noms de tables et de colonnes pour vous assurer qu'ils correspondent à votre implémentation spécifique de Blue Yonder WMS. Portez une attention particulière aux marqueurs comme
@[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 de remplacement dans le script. Pour
@[where_clause_dates], définissez une plage de dates spécifique, par exemple,where adddte between 'YYYY-MM-DD' and 'YYYY-MM-DD'. Pour@[where_clause_warehouse], spécifiez les ID d'entrepôt que vous souhaitez extraire, par exemple,where wh_id = '[Your Warehouse ID]'. - Connecter au serveur MOCA: Lancez votre client MOCA (par exemple, MOCA Console) et établissez une connexion à l'environnement Blue Yonder WMS approprié.
- Exécuter le script MOCA: Collez le script personnalisé dans la MOCA Console. Exécutez la commande. Le script s'exécutera sur le serveur et collectera les données pour toutes les activités spécifiées.
- Suivre l'exécution: Pour les grands ensembles de données, la requête peut prendre un temps considérable pour s'exécuter. Surveillez la console pour tout message d'erreur ou avertissement de performance. Si la requête expire, envisagez de l'exécuter sur des plages de dates plus courtes.
- Exporter les résultats vers un fichier: Une fois le script exécuté avec succès, les résultats seront affichés dans la console. Utilisez la fonctionnalité d'exportation du client pour sauvegarder la sortie en tant que fichier CSV. Une méthode courante depuis la ligne de commande consiste à rediriger la sortie directement vers un fichier, par exemple :
mocarun -S \"[Your MOCA Script]\" > event_log.csv. - Formater le CSV pour ProcessMind: Ouvrez le fichier CSV exporté. Vérifiez que les en-têtes de colonnes correspondent aux attributs spécifiés dans la requête (
WarehouseOrder,ActivityName,EventStartTime, etc.). Assurez-vous que le fichier est enregistré avec un encodage UTF-8 pour éviter les problèmes de caractères lors du téléchargement. - Examiner et télécharger: Effectuez une dernière vérification du contenu du fichier, à la recherche d'erreurs ou d'incohérences évidentes. Une fois satisfait, téléchargez le fichier CSV sur ProcessMind pour analyse.
Configuration
- Période de données: Il est recommandé d'extraire les données sur une période de 3 à 6 mois afin de garantir un échantillon représentatif des variations de processus. Le marqueur de filtre de date
@[where_clause_dates]doit être appliqué à la colonne d'horodatage primaire dans chaque instruction SELECT, telle queadddteoumoddte. - Filtres Entrepôt et Client: Utilisez toujours des filtres pour limiter la portée de l'extraction. Le marqueur
@[where_clause_warehouse]doit être utilisé pour filtrer par ID d'entrepôt (wh_id) spécifiques et, le cas échéant, par ID client (client_id). C'est crucial pour la performance et la pertinence des données. - Filtres de type de commande: Pour affiner l'analyse, envisagez de filtrer sur des types de commandes d'entrepôt (
ordtyp) spécifiques. Par exemple, vous pourriez vouloir analyser uniquement les commandes client sortantes ou les commandes d'achat entrantes. Cela peut être ajouté à la clause WHERE dans les sections pertinentes du script. - Considérations de performance: Le script d'extraction joint et unit plusieurs grandes tables. Pour éviter d'affecter les performances du système, planifiez l'exécution de l'extraction pendant les heures creuses. L'extraction de données par lots plus petits et incrémentaux (par exemple, un mois à la fois) est une stratégie sûre pour les très grands environnements.
- Prérequis: L'utilisateur exécutant le script doit disposer des autorisations d'accès en lecture pour toutes les tables référencées dans la requête, y compris
ord_hdr,ord_dtl,invmov,pckwrk_dtl,asnhdr, ettrn_log. L'utilisateur doit également être autorisé à exécuter les commandes MOCA.
a Exemple de requête config
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 les identifiants en lecture seule et les détails de connexion (adresse du serveur, nom de la base de données, port) pour la base de données sous-jacente de Blue Yonder WMS, qui est généralement Oracle ou SQL Server. Utilisez un client SQL standard comme 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 standards telles que
ord(commandes),pckwrk(travail de picking),wrkque(file d'attente de travail),invmov(mouvements d'inventaire) etlodhdr(en-tête de chargement). Vérifiez ces noms de tables et structures de colonnes par rapport au dictionnaire de données de votre système, car des personnalisations peuvent exister. - Examiner et paramétrer la requête SQL: Copiez le script SQL fourni dans votre client SQL. Localisez les variables de remplacement dans l'expression de table commune (CTE)
BaseOrdersen haut du script. - Définir la plage de dates: Modifiez les clauses
adddte >= 'YYYY-MM-DD'etadddte < 'YYYY-MM-DD'pour définir la fenêtre temporelle de l'extraction des données. Une période de 3 à 6 mois est recommandée pour une analyse initiale. - Appliquer les filtres spécifiques au système: Ajustez le filtre
wh_id = '[Your_Warehouse_ID]'pour limiter l'extraction à un entrepôt spécifique. Ajoutez ou modifiez d'autres filtres, tels queclient_idpour les environnements multi-clients, selon les besoins. - Exécuter le script d'extraction: Exécutez le script SQL complet. La requête est conçue pour consolider les événements de plusieurs tables dans un format de journal d'événements unique et unifié. Le temps d'exécution variera en fonction de la plage de dates et du volume de données.
- Valider les résultats initiaux: Une fois la requête terminée, effectuez un examen rapide de la sortie. Vérifiez que les colonnes
WarehouseOrder,ActivityNameetEventStartTimesont renseignées comme prévu. Le nombre de lignes doit être significativement plus élevé que le nombre de commandes d'entrepôt uniques. - Exporter le journal d'événements: Exportez les résultats de la requête vers un fichier CSV. Assurez-vous que l'encodage du fichier est défini sur UTF-8 pour éviter les problèmes d'encodage de caractères lors du téléchargement.
- Préparer le téléchargement: Confirmez que les en-têtes de colonnes du fichier CSV exporté correspondent aux attributs requis, par exemple,
WarehouseOrder,ActivityName,EventStartTime. Le fichier est maintenant prêt à être télé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 spécifiques à votre organisation est fortement recommandée.
- Connexion à la base de données: Cette méthode nécessite une connectivité directe à la base de données. Assurez-vous que toutes les règles de pare-feu ou autorisations d'accès réseau nécessaires sont en place avant de commencer.
- Filtrage par plage de dates: Il est essentiel de définir une plage de dates spécifique dans la clause
WHEREde la requête pour gérer le volume de données. Une plage de 3 à 6 mois est généralement suffisante pour une analyse pertinente sans surcharger excessivement la base de données. - Filtrage par entrepôt et client: Dans les environnements multi-entrepôts ou multi-clients, filtrez toujours par
wh_id(ID de l'entrepôt) etclient_id(ID du client) spécifiques pour que l'analyse soit ciblée et que l'ensemble de données soit gérable. - Considérations de performance: L'exécution de cette requête sur une base de données de production en direct peut impacter les performances du système. Il est fortement recommandé de l'exécuter pendant les heures creuses ou, de préférence, sur une base de données dédiée aux rapports ou une base de données répliquée si disponible.
- Personnalisations du système: La requête fournie utilise des noms de tables et de colonnes standards. Préparez-vous à ajuster ces noms en fonction des personnalisations ou des différences de version de votre instance Blue Yonder WMS. Consultez votre administrateur WMS interne ou le dictionnaire de données pour obtenir des conseils.
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 Canceled