Ihr Daten-Template für die Lagerverwaltung
Ihr Daten-Template für die Lagerverwaltung
- Empfohlene Attribute für eine umfassende Analyse
- Wichtige Aktivitäten entlang Ihres Materialflusses
- Praktische Hinweise zur Datenextraktion aus Blue Yonder WMS
Attribute der Lagerverwaltung
| Name | Beschreibung | ||
|---|---|---|---|
| Aktivitätsname ActivityName | Der Name der konkreten Lageraufgabe oder des Ereignisses, zum Beispiel „Goods Picked“ oder „Shipment Dispatched“. | ||
| Beschreibung Dieses Attribut bezeichnet den konkreten Arbeitsschritt oder die Aufgabe im Lagerverwaltungsprozess. Jedem Ereignis im Prozessprotokoll ist ein Aktivitätsname zugeordnet. Zusammen bilden die Aktivitäten die Abfolge der Prozessschritte. Für die Analyse ist der Aktivitätsname grundlegend: Er dient dazu, die Prozesslandkarte zu ermitteln, Übergänge zwischen Schritten zu analysieren und Engpässe oder Abweichungen von der Standardvorgehensweise zu erkennen. Er kommt in nahezu allen Process-Mining-Analysen zum Einsatz, von der Konformitätsprüfung bis zur Leistungsüberwachung. Warum das wichtig ist Dieses Attribut ist für die Erstellung der Prozesslandkarte entscheidend. Es definiert die einzelnen Schritte und ermöglicht, den Prozessablauf darzustellen und zu analysieren. Woher beziehen Diese Information findet sich üblicherweise in Tabellen zu Lageraufgaben oder Ereignisprotokollen. Häufig wird sie aus einem Aufgabentyp oder Statuscode abgeleitet. Beispiele Picking Task CreatedGoods Picked from StorageSendung versandt | |||
| Lagerauftrag WarehouseOrder | Die eindeutige Kennung eines Lagerauftrags. Sie dient als zentraler Prozessfall, um alle zugehörigen logistischen Aktivitäten von der Erstellung bis zum Abschluss nachzuverfolgen. | ||
| Beschreibung Der Lagerauftrag ist die zentrale Kennung, unter der alle Ereignisse und Aufgaben zu einem bestimmten logistischen Auftrag zusammengefasst werden, etwa zu einem Wareneingang oder einem ausgehenden Versand. Er bildet eine vollständige Arbeitseinheit im Lager ab. Im Process Mining dient dieses Attribut zur Definition des Prozessfalls und ermöglicht die durchgängige Analyse des gesamten Auftragslebenszyklus. Wenn Analysten alle Aktivitäten eines Lagerauftrags nachverfolgen, können sie die gesamte Auftragsabwicklungszeit messen, häufige Prozessvarianten erkennen und den vollständigen Weg eines Auftrags durch das Lager nachvollziehen. Warum das wichtig ist Diese zentrale Kennung verknüpft alle zugehörigen Lageraktivitäten und ermöglicht eine vollständige, durchgängige Analyse der Auftragsabwicklung oder des Wareneingangs. Woher beziehen Dies ist üblicherweise der Primärschlüssel in der Kopftabelle des Lagerauftrags. Informationen zu den Tabellen für die Auftragsverwaltung finden Sie in der Dokumentation zu Blue Yonder WMS. Beispiele WO-0012845WO-0012991WO-0013057 | |||
| Startzeit des Ereignisses EventStartTime | Der Timestamp, der angibt, wann eine bestimmte Lageraktivität oder ein Ereignis begonnen hat. | ||
| Beschreibung Dieses Attribut erfasst Datum und Uhrzeit, zu denen eine Lageraufgabe oder ein Ereignis begonnen hat. Es liefert den zeitlichen Kontext für alle Aktivitäten eines Prozessfalls. Dieser Timestamp ist für alle zeitbasierten Process-Mining-Analysen unverzichtbar. Er dient dazu, Ereignisse zu ordnen, Zykluszeiten zwischen Aktivitäten und die Dauer des gesamten Prozesses zu berechnen sowie Wartezeiten und Verzögerungen zu erkennen. Er bildet die Grundlage der Leistungsanalyse und wird benötigt, um die Prozesslandkarte zu animieren. Warum das wichtig ist Der Start-Timestamp ist erforderlich, um Ereignisse chronologisch zu ordnen und alle Leistungskennzahlen wie Zyklus- und Wartezeiten zu berechnen. Woher beziehen Zu finden in Ereignisprotokollen oder Aufgabentabellen. Das Feld entspricht dem Erstellungs- oder Startzeitpunkt einer erfassten Aktion. Beispiele 2023-10-26T08:30:00Z2023-10-26T09:15:10Z2023-10-26T11:05:45Z | |||
| Letzte Datenaktualisierung LastDataUpdate | Timestamp der letzten Aktualisierung dieses Datensatzes aus dem Quellsystem. | ||
| Beschreibung Dieses Attribut erfasst Datum und Uhrzeit, zu denen der Datensatz zuletzt aus Blue Yonder WMS extrahiert oder aktualisiert wurde. Es gibt Auskunft darüber, wie aktuell die analysierten Daten sind. Dieser Timestamp ist für die Data Governance wichtig und hilft Benutzern, die Aktualität ihrer Analyse einzuschätzen. So wissen alle Beteiligten, auf welchem Datenstand die Analyse beruht, und können beurteilen, ob der betrachtete Prozessstand aktuell und relevant ist. Warum das wichtig ist Dieser Timestamp informiert Benutzer über die Aktualität der Daten und zeigt, welchen Zeitraum die Analyse abdeckt. Woher beziehen Dieses Metadatenfeld wird üblicherweise während der Datenextraktion (ETL) erzeugt und hinzugefügt. Beispiele 2024-01-15T04:00:00Z2024-01-16T04:00:00Z | |||
| Quellsystem SourceSystem | Das System, aus dem die Daten extrahiert wurden, in diesem Fall Blue Yonder WMS. | ||
| Beschreibung Dieses Attribut identifiziert das Ursprungssystem der Ereignisdaten. In einer modernen IT-Landschaft können die Daten für einen durchgängigen Prozess aus mehreren Systemen stammen, etwa aus einem ERP-, WMS- und TMS-System. Die Angabe des Quellsystems ist wichtig für die Data Governance, die Fehlerbehebung und das Verständnis des Datenkontexts. Sie hilft, Probleme mit der Datenqualität bis zu ihrem Ursprung zurückzuverfolgen. Außerdem ist sie unverzichtbar, wenn Daten aus mehreren Quellen zu einer einheitlichen Prozessansicht zusammengeführt werden. Warum das wichtig ist Das Attribut liefert wichtige Informationen zur Datenherkunft. So lassen sich Daten zur Validierung bis zu ihrem Ursprung zurückverfolgen und Szenarien mit Daten aus mehreren Systemen nachvollziehen. Woher beziehen Üblicherweise handelt es sich um einen statischen Wert, der bei der Datenextraktion ergänzt wird, um die Herkunft des Datensatzes zu kennzeichnen. Beispiele BlueYonderWMS_USBlueYonderWMS_EU | |||
| Angeforderter Abschlusstermin RequestedCompletionDate | Datum und Uhrzeit, zu denen der Lagerauftrag planmäßig oder auf Anfrage abgeschlossen und versandt werden soll. | ||
| Beschreibung Der angeforderte Abschlusstermin bezeichnet die Service-Level-Vereinbarung (SLA) oder den Zieltermin für die Abwicklung eines ausgehenden Lagerauftrags. Bis zu diesem Termin sollten die Waren kommissioniert und verpackt sowie versandbereit sein. Dieser Termin dient als Vergleichswert für die tatsächliche Leistung. Durch den Vergleich mit dem tatsächlichen Versand-Timestamp lässt sich die Kennzahl zur termingerechten Versandquote berechnen. Eine Analyse nach diesem Attribut zeigt, bei welchen Aufträgen eine Verspätung droht und welche Ursachen zu SLA-Verstößen führen. Warum das wichtig ist Dieses Attribut ist der Vergleichswert für die Messung der Termintreue und entscheidend für die Berechnung der Kennzahl zur termingerechten Versandquote. Woher beziehen Üblicherweise in der Kopftabelle des Lagerauftrags gespeichert, oft übernommen aus dem ursprünglichen Kundenauftrag oder der Lieferanforderung. Beispiele 2023-10-27T17:00:00Z2023-10-28T12:00:00Z2023-11-01T17:00:00Z | |||
| Benutzer-/Mitarbeiter-ID UserOperatorId | Die Kennung des Lagermitarbeiters oder Bedieners, der die Aktivität ausgeführt hat. | ||
| Beschreibung Dieses Attribut erfasst die eindeutige ID der Person, die eine Lageraufgabe wie Kommissionieren, Verpacken oder Einlagern ausgeführt hat. Es verknüpft Prozessaktivitäten mit den Mitarbeitenden. Die Analyse nach Benutzer-/Mitarbeiter-ID ist wichtig, um Ressourcenauslastung, Arbeitsverteilung und individuelle Leistung zu verstehen. Sie hilft bei Fragen wie: Welche Mitarbeitenden arbeiten besonders effizient? Wer benötigt möglicherweise zusätzliche Schulungen? Wie sind die Aufgaben im Team verteilt? Diese Dimension ist zentral für das Dashboard zur Ressourcenauslastung im Lager. Warum das wichtig ist Dieses Attribut verknüpft Prozessschritte mit den Personen, die sie ausgeführt haben. So lassen sich Ressourcenleistung, Arbeitsauslastung und Schulungsbedarf analysieren. Woher beziehen Häufig in Aufgaben- oder Transaktionstabellen zu finden. Die Verknüpfung erfolgt mit dem Benutzer, der während des Vorgangs am System oder am Handheld-Gerät angemeldet war. Beispiele JSMITHBWILLISAMILLER | |||
| Endzeit des Ereignisses EventEndTime | Der Timestamp, der angibt, wann eine bestimmte Lageraktivität oder ein Ereignis abgeschlossen wurde. | ||
| Beschreibung Dieses Attribut erfasst Datum und Uhrzeit, zu denen eine Lageraufgabe oder ein Ereignis beendet wurde. Wenn verfügbar, lässt sich damit die Verarbeitungszeit jeder Aktivität genau messen. Mit Start- und Endzeit ist eine detailliertere Leistungsanalyse möglich. So lassen sich Wartezeiten zwischen Aktivitäten von der Verarbeitungszeit der jeweiligen Aktivität unterscheiden. Das ist entscheidend, um festzustellen, ob Verzögerungen durch Leerlauf oder durch zu lange Bearbeitungszeiten entstehen. Warum das wichtig ist Damit lässt sich die Verarbeitungszeit einer Aktivität genau berechnen und von der Wartezeit unterscheiden. Das ist wichtig, um gezielte Verbesserungen umzusetzen. Woher beziehen Zu finden in Ereignisprotokollen oder Aufgabentabellen. Das Feld entspricht dem Abschluss- oder Schließzeitpunkt einer erfassten Aktion. Beispiele 2023-10-26T08:35:12Z2023-10-26T09:20:05Z2023-10-26T11:06:00Z | |||
| Geplante Menge PlannedQuantity | Die erwartete Artikelmenge für eine Aufgabe, zum Beispiel die zu kommissionierende oder zu empfangende Menge. | ||
| Beschreibung Die geplante Menge bezeichnet die Anzahl der Einheiten, die der Lagerauftrag für eine bestimmte Aufgabe vorgibt. Bei einer Anlieferung entspricht sie der vom Lieferanten erwarteten Menge. Bei einer Kommissionieraufgabe ist es die im Kundenauftrag angeforderte Menge. Dieses Attribut ist für die Genauigkeitsanalyse entscheidend. Durch den Vergleich der geplanten mit der tatsächlichen Menge lassen sich Abweichungen beim Wareneingang, bei der Kommissionierung oder bei der Bestandszählung erkennen. Es unterstützt direkt Kennzahlen wie die Abweichungsquote bei der Kommissioniermenge und ist für das Dashboard zur Prüfung der Mengengenauigkeit unverzichtbar. Warum das wichtig ist Sie dient als Vergleichsbasis für die Genauigkeitsmessung und hilft, Mengenabweichungen beim Wareneingang und bei der Kommissionierung zu erkennen. Woher beziehen Zu finden in Detail- oder Positionstabellen zu Lageraufträgen oder bestimmten Aufgaben. Beispiele 1005024 | |||
| Lagerort StorageLocation | Der konkrete Ort im Lager, etwa ein Lagerplatz oder Gang, an dem Waren gelagert oder entnommen werden. | ||
| Beschreibung Dieses Attribut bezeichnet den physischen Lagerort, der einer Aufgabe zugeordnet ist. Bei einer Einlagerung ist es der Ziellagerplatz, bei einer Kommissionierung der Quelllagerplatz. Der Ort kann durch einen zusammengesetzten Code aus Gang, Regal, Fach und Lagerplatz dargestellt werden. Die Analyse nach Lagerort hilft, die Effizienz des Lagerlayouts, die Lagerplatzstrategien und die Bewegungen von Ressourcen zu verstehen. Sie zeigt stark frequentierte Bereiche, wenig genutzte Zonen und mögliche Engpässe im Materialfluss. Dieses Attribut ist eine zentrale Dimension des Dashboards zu Trends bei der Lagerortauslastung. Warum das wichtig ist Das Attribut liefert wichtigen Kontext für die Analyse des Lagerlayouts und der Wirksamkeit von Lagerplatzstrategien sowie für die Erkennung von Bewegungsengpässen. Woher beziehen Verfügbar in Tabellen zu Beständen, Lageraufgaben wie Kommissionierung und Einlagerung sowie Lagerplatzstammdaten. Beispiele A1-R03-S02-B01B5-R10-S04-B05C2-R01-S01-B02 | |||
| Prioritätsstufe PriorityLevel | Die Priorität des Lagerauftrags, zum Beispiel „Hoch“, „Standard“ oder „Niedrig“. | ||
| Beschreibung Die Prioritätsstufe gibt an, wie dringend ein Lagerauftrag ist. Aufträge mit hoher Priorität, etwa Expresssendungen, sollen schneller bearbeitet werden als Standardaufträge. Das WMS verwendet dieses Attribut, um Aufgaben zu sortieren und Ressourcen zuzuweisen. Im Process Mining ist dieses Attribut entscheidend, um die Wirksamkeit von Priorisierungsstrategien zu analysieren. Das Dashboard zur Auftragsabwicklung mit hoher Priorität verwendet dieses Feld, um dringende Aufträge herauszufiltern und ihre Zykluszeiten mit denen von Standardaufträgen zu vergleichen. So lässt sich prüfen, ob Aufträge mit hoher Priorität den Prozess tatsächlich schneller durchlaufen oder an denselben Engpässen hängen bleiben. Warum das wichtig ist Damit lässt sich prüfen, ob Aufträge mit hoher Priorität schneller bearbeitet werden als Standardaufträge und ob die Priorisierungsregeln wirksam sind. Woher beziehen Diese Information ist üblicherweise in der Kopftabelle des Lagerauftrags gespeichert. Beispiele HochStandardNiedrig | |||
| Tatsächliche Menge ActualQuantity | Die tatsächlich bei einer Aufgabe bearbeitete Artikelmenge, zum Beispiel die physisch gezählte oder kommissionierte Menge. | ||
| Beschreibung Die tatsächliche Menge gibt an, wie viele Einheiten ein Lagermitarbeiter bei einer Aufgabe physisch bearbeitet hat. Das kann die Anzahl der vom Lieferanten empfangenen Artikel, der aus einem Lagerplatz entnommenen Einheiten oder der in einen Versandbehälter verpackten Artikel sein. Im Vergleich mit der geplanten Menge macht dieses Attribut Prozessausnahmen und Fehler sichtbar. Es ist die zentrale Kennzahl zur Berechnung von Abweichungsquoten, die wichtige Indikatoren für die operative Qualität sind. Diese Daten helfen, Probleme bei Lieferungen, Kommissionierfehler oder ungenaue Bestände zu erkennen. Warum das wichtig ist Der Vergleich mit der geplanten Menge ist wichtig, um Prozessfehler zu erkennen und zentrale Qualitätskennzahlen wie Abweichungsquoten zu berechnen. Woher beziehen Zu finden in Tabellen zu Aufgabenbestätigungen oder Transaktionsprotokollen, in denen Mitarbeitende die ausgeführte Menge erfassen. Beispiele 1004924 | |||
| Aufgabenstatus TaskStatus | Der Endstatus einer Aufgabe, zum Beispiel „Completed“, „Canceled“ oder „Failed“. | ||
| Beschreibung Dieses Attribut beschreibt das Ergebnis einer bestimmten Lageraufgabe. Viele Aufgaben werden erfolgreich abgeschlossen, andere werden möglicherweise von einer Führungskraft storniert oder scheitern aufgrund technischer oder betrieblicher Probleme. Der Aufgabenstatus liefert damit mehr Kontext als der Aktivitätsname allein. Die Analyse nach Aufgabenstatus hilft, Ausnahmen und Prozessfehler zu verstehen. Ein hoher Anteil stornierter oder fehlgeschlagener Aufgaben kann auf grundlegende Probleme mit der Bestandsgenauigkeit, der Systemkonfiguration oder der Schulung von Mitarbeitenden hindeuten. So lassen sich fehleranfällige Aktivitäten erkennen, die genauer untersucht werden sollten. Warum das wichtig ist Das Attribut zeigt das Ergebnis einer Aktivität. So lassen sich Ausnahmen wie stornierte oder fehlgeschlagene Aufgaben analysieren, die auf tiefer liegende betriebliche Probleme hindeuten können. Woher beziehen Üblicherweise in der Aufgabentabelle zu finden. Das Feld gibt den Endstatus des Aufgabensatzes an. Beispiele AbgeschlossenStorniertZurückgestellt | |||
| Geräte-ID EquipmentId | Kennung des verwendeten Flurförderzeugs oder Fördermittels, zum Beispiel eines bestimmten Gabelstaplers oder Förderbands. | ||
| Beschreibung Die Geräte-ID gibt an, welche Maschine oder welches Gerät für eine Lageraufgabe verwendet wurde. Dazu zählen beispielsweise Gabelstapler, Hubwagen, fahrerlose Transportfahrzeuge (AGVs) oder bestimmte Packstationen. Mit diesem Attribut lassen sich Gerätenutzung, Leistung und Wartungsbedarf analysieren. Wenn Aktivitäten nach Gerät erfasst werden, können Verantwortliche über- oder unterausgelastete Betriebsmittel erkennen, die Effizienz verschiedener Maschinentypen vergleichen und Wartungspläne datenbasiert erstellen. Es ist eine zentrale Dimension des Dashboards zur Ressourcenauslastung im Lager. Warum das wichtig ist Damit lassen sich Gerätenutzung und Leistung analysieren, um den Einsatz von Betriebsmitteln und Wartungspläne zu optimieren. Woher beziehen Kann in Protokollen zur Aufgabenausführung erfasst sein, insbesondere wenn sich Mitarbeitende am Gerät anmelden. Beispiele FORKLIFT-07AGV-03PACKSTATION-12 | |||
| Lager-ID WarehouseId | Kennung des Lagers oder Distributionszentrums, in dem die Aktivität stattgefunden hat. | ||
| Beschreibung Die Lager-ID identifiziert eindeutig den Standort, an dem der Prozess stattfindet. Sie ist für Unternehmen mit mehreren Distributionszentren unverzichtbar. Dieses Attribut ermöglicht Benchmarking und Vergleiche zwischen verschiedenen Standorten. Wenn Unternehmen die Daten nach Lager-ID filtern oder aufteilen, können sie die Leistung vergleichen, bewährte Vorgehensweisen an besonders leistungsstarken Standorten erkennen und nachvollziehen, warum bestimmte Standorte zurückliegen. Damit steht eine wichtige Dimension für die standortübergreifende Betriebsanalyse zur Verfügung. Warum das wichtig ist Für Unternehmen mit mehreren Standorten ist dieses Attribut unverzichtbar, um die Leistung zu vergleichen und Prozesse an verschiedenen Standorten gegenüberzustellen. Woher beziehen Häufig handelt es sich um ein übergeordnetes Organisationsfeld, das in fast allen Transaktionstabellen verfügbar ist. Alternativ lässt es sich aus der Systeminstanz ableiten. Beispiele WHC-01DC-EAST-03FAC-WEST | |||
| Lagerauftragstyp WarehouseOrderType | Kategorisiert den Lagerauftrag, zum Beispiel als Wareneingang, ausgehende Sendung oder interne Umlagerung. | ||
| Beschreibung Dieses Attribut klassifiziert den Zweck des Lagerauftrags. Zu den gängigen Typen zählen Anlieferungen von Lieferanten, ausgehende Sendungen an Kunden, Retouren oder interne Bestandsbewegungen zwischen Lagerorten. Die Segmentierung nach Lagerauftragstyp ist ein grundlegender erster Schritt jeder Analyse. Wareneingangs- und Versandprozesse unterscheiden sich oft deutlich, etwa bei den Arbeitsschritten, Ressourcen und Leistungszielen. Mit diesem Attribut können Sie die Daten filtern und einen bestimmten Prozess, beispielsweise den Wareneingang oder die Auftragsabwicklung, separat analysieren. Warum das wichtig ist Damit lassen sich unterschiedliche Prozesse wie Wareneingang und Versand getrennt betrachten und vergleichen, da sie jeweils eigene Abläufe und Ziele haben. Woher beziehen Zu finden in der Kopftabelle des Lagerauftrags, üblicherweise in einem Feld für Dokumenttyp oder Auftragskategorie. Beispiele AnlieferungAusgehende SendungInterne Umlagerung | |||
| Mengenabweichung vorhanden IsQuantityMismatch | Ein boolesches Kennzeichen, das angibt, ob die tatsächlich bearbeitete Menge von der geplanten Menge einer Aufgabe abweicht. | ||
| Beschreibung Dieses berechnete Attribut kennzeichnet eine Mengenabweichung bei einer Aufgabe, etwa beim Kommissionieren oder beim Wareneingang. Es wird auf „true“ gesetzt, wenn die tatsächliche Menge nicht der geplanten Menge entspricht. Mit diesem Kennzeichen lassen sich Fehler im Prozess einfach erkennen und zählen. Es vereinfacht die Berechnung von Kennzahlen wie der Abweichungsquote bei der Kommissioniermenge und der Abweichungsquote bei der Wareneingangsmenge. Außerdem unterstützt es die Ursachenanalyse: Analysten können alle Ereignisse mit Mengenabweichungen herausfiltern und nach Mustern bei Produkten, Mitarbeitenden oder Lagerorten suchen. Warum das wichtig ist Das Kennzeichen markiert Ereignisse mit Mengenfehlern. So lassen sich Abweichungsquoten einfacher berechnen und Aufgaben mit ungenauen Mengen gezielt analysieren. Woher beziehen Berechnet durch den Vergleich der Felder PlannedQuantity und ActualQuantity für jede relevante Aktivität. Beispiele falsetruefalse | |||
| Produkt-SKU ProductSku | Die Artikelnummer (Stock Keeping Unit, SKU) oder Materialnummer des bearbeiteten Artikels. | ||
| Beschreibung Dieses Attribut identifiziert das konkrete Produkt, das bei einer Lageraufgabe bearbeitet wird. Es liefert detaillierte Informationen zu den Materialien, die bewegt, gelagert, kommissioniert und verpackt werden. Die Analyse nach Produkt-SKU kann Muster bei bestimmten Artikeln aufdecken. Bei manchen Produkten treten beispielsweise häufiger Kommissionierfehler auf, die Einlagerung dauert wegen besonderer Handhabung länger oder sie werden an ungünstigen Orten gelagert. So lassen sich Prozesse gezielt für einzelne Produkte verbessern und Lagerplatzstrategien optimieren. Warum das wichtig ist Damit lassen sich Prozesse auf Produktebene analysieren und Artikel erkennen, die Verzögerungen oder Fehler verursachen oder eine besondere Handhabung erfordern. Woher beziehen Diese Information ist auf Positionsebene in den Tabellen zu Lageraufträgen oder Aufgaben zu finden. Beispiele PN-A5540-BSKU-300-RED-LGHW-88201 | |||
| Sendung termingerecht versandt IsOnTimeShipment | Ein boolesches Kennzeichen, das den Wert „true“ hat, wenn die Sendung am angeforderten Abschlusstermin oder früher versandt wurde. | ||
| Beschreibung Dieses berechnete Attribut gibt mit einem einfachen Wahr-oder-falsch-Wert an, ob ein Auftrag die Versand-SLA eingehalten hat. Der Wert ergibt sich aus dem Vergleich des Timestamps der Aktivität „Shipment Dispatched“ mit dem angeforderten Abschlusstermin des Auftrags. Das Kennzeichen vereinfacht die Analyse und Darstellung der Termintreue. Es ermöglicht eine einfache Filterung und Aggregation zur Berechnung der Kennzahl zur termingerechten Versandquote und speist das zugehörige Dashboard. Außerdem unterstützt es die Ursachenanalyse, indem sich gemeinsame Merkmale verspäteter Sendungen erkennen lassen. Warum das wichtig ist Dieses boolesche Kennzeichen vereinfacht die Berechnung der Kennzahl zur termingerechten Versandquote und ermöglicht eine gezielte Filterung, um Merkmale verspäteter Aufträge zu analysieren. Woher beziehen Berechnet durch den Vergleich von EventStartTime der Aktivität „Shipment Dispatched“ mit dem Attribut RequestedCompletionDate. Beispiele truefalsetrue | |||
| Sendungs-ID ShipmentId | Die eindeutige Kennung der ausgehenden Sendung, zu der ein Lagerauftrag gehört. | ||
| Beschreibung Die Sendungs-ID ist eine übergeordnete Kennung, unter der mehrere Lageraufträge zusammengefasst werden können, wenn sie mit demselben Lkw oder Container versandt werden. Bei einem einzelnen Auftrag kann sie mit der Lagerauftrags- oder Auslieferungsnummer übereinstimmen. Die Analyse nach Sendungs-ID gibt Einblick in den Versandprozess. Sie zeigt, wie Aufträge zusammengefasst werden, ermöglicht die Messung der Zeit von der Bereitstellung bis zum endgültigen Versand einer Komplettladung und hilft, die Effizienz der Versandabteilung zu analysieren. Außerdem verknüpft sie die Lageraktivitäten mit dem letzten Transportabschnitt der Lieferkette. Warum das wichtig ist Damit werden gemeinsam versandte Lageraufträge gruppiert. So lassen sich die Zusammenstellung und der Versand von Sendungen analysieren. Woher beziehen Zu finden in Tabellen zu Sendungen oder Transporten, mit einer Verknüpfung zu den Lageraufträgen. Beispiele SHP-45000123SHP-45000124SHP-45000125 | |||
Aktivitäten in der Lagerverwaltung
| Aktivität | Beschreibung | ||
|---|---|---|---|
| Goods Put Away in Storage | Dieses Ereignis bestätigt, dass die Waren erfolgreich bewegt und am vorgesehenen Lagerplatz eingescannt wurden. Es wird erfasst, wenn ein Mitarbeitender den Abschluss der Einlagerungsaufgabe bestätigt, in der Regel über ein mobiles RF-Gerät. | ||
| Warum das wichtig ist Damit endet der Wareneingangsprozess und der Bestand steht für die Auftragsabwicklung zur Verfügung. Die Zeit vom Wareneingang bis zu diesem Punkt ist eine wichtige Kennzahl im Dashboard „Goods Receipt to Putaway Cycle Time“. Woher beziehen Wird als Transaktion mit Timestamp erfasst, wenn der Status der Einlagerungsaufgabe auf „Completed“ oder „Confirmed“ gesetzt wird. Diese Daten finden Sie in den Tabellen zu Lageraufgaben oder Umlagerungsaufträgen. Erfassung Bestätigungs-Timestamp der Einlagerungsaufgabe. Ereignistyp explicit | |||
| Goods Received and Counted | Dieses Ereignis zeigt an, dass die Waren entladen und gescannt wurden und ihre Mengen mit den Lieferdokumenten abgeglichen sind. Es wird in der Regel erfasst, wenn ein Mitarbeitender im Wareneingang die erhaltenen Mengen für jeden Artikel des eingehenden Auftrags im System bestätigt. | ||
| Warum das wichtig ist Dies ist ein wichtiger Meilenstein: Der Bestand ist nun offiziell im System verfügbar, aber noch nicht für die Auftragsabwicklung bereit. Dauer und Genauigkeit dieses Schritts wirken sich unmittelbar auf die Bestandstransparenz und den Beginn der Einlagerung aus. Woher beziehen Dieses Ereignis wird als explizite Transaktion in Bestands- oder Wareneingangsprotokollen erfasst. Suchen Sie nach Buchungen des Wareneingangs oder nach Statusänderungen der Positionen einer eingehenden Lieferung auf „Received“. Erfassung Timestamp der Transaktion, die den Wareneingang bestätigt. Ereignistyp explicit | |||
| Lagerauftrag abgeschlossen | Dies ist der Endstatus des Lagerauftrags. Er zeigt an, dass alle zugehörigen Aktivitäten einschließlich des Versands abgeschlossen und der Auftrag geschlossen sind. Er wird erfasst, wenn der Lebenszyklusstatus des Auftrags auf „Completed“ oder „Closed“ gesetzt wird. | ||
| Warum das wichtig ist Diese Aktivität markiert das endgültige Ende des Prozessfalls. So umfasst die Prozessanalyse den vollständigen Lebenszyklus jedes Auftrags vom Anfang bis zum Abschluss. Woher beziehen Dieses Ereignis lässt sich aus einer Statusänderung in der Kopftabelle des Lagerauftrags ableiten. Suchen Sie nach einem Endstatus wie „Completed“, „Closed“ oder „Invoiced“ sowie dem Timestamp der Statusänderung. Erfassung Abgeleitet aus dem Timestamp der letzten Statusänderung im Auftragskopf. Ereignistyp inferred | |||
| Picking Task Created | Dieses Ereignis kennzeichnet die Erstellung einer Aufgabe für einen Mitarbeitenden, der Waren für einen ausgehenden Auftrag vom Lagerplatz entnehmen soll. Das WMS erzeugt dieses explizite Ereignis, wenn ein ausgehender Auftrag zur Kommissionierung freigegeben wird. | ||
| Warum das wichtig ist Damit beginnt der physische Warenausgang. Die Zeit von der Auftragserstellung bis zur Erstellung der Kommissionieraufgabe zeigt Verzögerungen bei der Auftragsbearbeitung und Zuweisung auf. Woher beziehen Wird in den Tabellen zur Aufgabenverwaltung oder Lagersteuerung protokolliert. Das Ereignis entspricht dem Erstellungs-Timestamp der Kommissionieraufgaben, die dem Lagerauftrag zugeordnet sind. Erfassung Erstellungs-Timestamp der vom System erzeugten Kommissionieraufgabe. Ereignistyp explicit | |||
| Sendung versandt | Dieses Ereignis zeigt an, dass die verpackte Ware auf den Lkw des Frachtführers geladen wurde und dieser das Lager verlassen hat. Üblicherweise wird es erfasst, wenn im System ein Warenausgang gebucht und damit die Sendung abgeschlossen wird. | ||
| Warum das wichtig ist Dieser wichtige Meilenstein markiert das Ende der Verantwortung des Lagers für den Auftrag. Er ist der letzte Datenpunkt zur Messung der termingerechten Versandquote und der gesamten Durchlaufzeit der Auftragsabwicklung. Woher beziehen Dabei handelt es sich um eine wichtige finanzielle und logistische Transaktion, die häufig „Post Goods Issue“ (PGI) genannt wird. Ihr Timestamp gilt als Versandzeitpunkt und ist üblicherweise in den Tabellen zur Auslieferung oder zum Versanddokument gespeichert. Erfassung Timestamp der Transaktion Post Goods Issue (PGI). Ereignistyp explicit | |||
| Warehouse Order Created | Dieses Ereignis kennzeichnet die Erstellung eines Lagerauftrags. Er ist das zentrale Dokument zur Verwaltung eingehender, ausgehender oder interner Lageraufgaben. Das Ereignis wird in der Regel als explizite Transaktion erfasst, wenn ein neuer Auftrag manuell oder über eine Integration in Blue Yonder WMS angelegt wird. | ||
| Warum das wichtig ist Dies ist der eindeutige Prozessbeginn. Die Zeit von diesem Ereignis bis zum Abschluss entspricht der gesamten Durchlaufzeit der Auftragsabwicklung. Sie ist entscheidend, um die Gesamteffizienz und die Einhaltung von Service-Level-Vereinbarungen zu messen. Woher beziehen Dieses Ereignis wird wahrscheinlich in einer Auftragstabelle erfasst, und zwar über den Erstellungs-Timestamp des Lagerauftragsdatensatzes. Suchen Sie nach Tabellen wie Erfassung Aus dem Erstellungs-Timestamp des Lagerauftragsdatensatzes. Ereignistyp explicit | |||
| Für den Versand bereitstellen | Dieses Ereignis bezeichnet den Transport verpackter Behälter vom Packbereich zu einer festgelegten Bereitstellspur, wo sie auf die Abholung durch den Frachtführer warten. Es wird protokolliert, wenn ein Mitarbeiter den Transport der Ladeeinheit zum Bereitstellbereich bestätigt. | ||
| Warum das wichtig ist Mit dieser Aktivität lässt sich die Liegezeit analysieren, also die Zeit, in der verpackte Aufträge vor der Verladung warten. Lange Bereitstellzeiten können auf eine schlechte Abstimmung mit den Frachtführern oder eine ineffiziente Nutzung der Bereitstellfläche hindeuten. Woher beziehen Dieses Ereignis lässt sich aus einer Änderung des Lagerorts der Ladeeinheit oder des Versandbehälters auf einen Bereitstellort ableiten. Es kann auch durch eine explizite Bestätigung der Aufgabe „Move to Stage“ erfasst werden. Erfassung Abgeleitet aus Bestandsbewegungsprotokollen, die den Transport zu einem Bereitstelllagerplatz zeigen. Ereignistyp inferred | |||
| Goods Arrived at Dock | Diese Aktivität kennzeichnet die physische Ankunft eines Lkw oder Frachtführers an der Warenannahme des Lagers, bevor das Entladen beginnt. Das Ereignis wird häufig explizit in einem Yard-Management-Modul protokolliert oder erfasst, wenn ein Mitarbeitender am Tor die Lieferung anmeldet. | ||
| Warum das wichtig ist Die Erfassung der Ankunftszeit hilft, die Pünktlichkeit des Frachtführers zu messen und Verzögerungen zwischen dessen Ankunft und dem Beginn des Wareneingangs zu erkennen. So werden mögliche Engpässe im Yard-Management oder an den Wareneingangstoren sichtbar. Woher beziehen Wird üblicherweise in einem Yard-Management- oder Torsteuerungsmodul von Blue Yonder WMS erfasst. Alternativ kann ein Mitarbeitender im Wareneingang den Timestamp bei Ankunft des Lkw manuell eingeben. Erfassung Timestamp der Anmeldebuchung des Frachtführers. Ereignistyp explicit | |||
| Goods Picked from Storage | Dieses Ereignis steht für den Abschluss der Kommissionieraufgabe: Ein Mitarbeitender hat die Artikel entnommen und den Vorgang im System bestätigt. Erfasst wird es, wenn die Artikel gescannt und die Entnahme auf dem Gerät bestätigt werden. | ||
| Warum das wichtig ist Dieser Meilenstein schließt die Kommissionierung ab. Genauigkeit und Dauer dieser Aktivität sind entscheidend für die Effizienz der gesamten Auftragsabwicklung und bilden die Grundlage für die Analyse „Picking Accuracy“. Woher beziehen Erfasst anhand des Bestätigungs-Timestamps, wenn der Status der Kommissionieraufgabe auf „Completed“ gesetzt wird. Diese Daten finden Sie in den Tabellen zu Lageraufgaben, häufig mit Verknüpfungen zum jeweiligen Mitarbeitenden und Gerät. Erfassung Bestätigungs-Timestamp der Kommissionieraufgabe. Ereignistyp explicit | |||
| Inbound Delivery Notified | Dieses Ereignis steht für den Eingang einer Advanced Shipping Notification (ASN) von einem Lieferanten. Sie kündigt an, dass Waren auf dem Weg zum Lager sind. Das Ereignis wird explizit erfasst, wenn eine ASN eingeht und vom System verarbeitet wird, häufig über EDI oder ein Portal. | ||
| Warum das wichtig ist Diese Aktivität löst die Planung des Wareneingangs und die Zuweisung von Ressourcen aus. Die Zeit zwischen der Benachrichtigung und dem physischen Wareneingang ist eine wichtige KPI zur Messung der Lieferantenleistung und der Transparenz über eingehende Lieferungen. Woher beziehen Erfasst aus den ASN-Eingangsprotokollen oder anhand des Erstellungs-Timestamps des Wareneingangsbelegs in Blue Yonder WMS. Prüfen Sie Tabellen zu ASNs oder Benachrichtigungen über eingehende Lieferungen. Erfassung Timestamp aus einer ASN oder der Erstellung eines Wareneingangsbelegs. Ereignistyp explicit | |||
| Lagerauftrag storniert | Dieses Ereignis bezeichnet die Stornierung eines Lagerauftrags, bevor er vollständig bearbeitet oder versandt wurde. Es wird erfasst, wenn ein Benutzer eine Stornierungstransaktion ausführt und dadurch den Auftragsstatus auf „Canceled“ setzt. | ||
| Warum das wichtig ist Die Analyse von Stornierungen hilft, Ursachen für Prozessfehler zu erkennen, etwa fehlende Bestände oder Änderungen seitens des Kunden. Als abschließendes Ereignis ist sie wichtig, um Prozessabweichungen und abgebrochene Vorgänge zu verstehen. Woher beziehen Dieses Ereignis wird üblicherweise aus dem Endstatus des Lagerauftrags abgeleitet. Verwendet wird der Timestamp der Statusänderung auf „Canceled“ oder „Deleted“. Erfassung Abgeleitet aus dem Timestamp einer Statusänderung auf „Canceled“. Ereignistyp inferred | |||
| Packing Initiated | Diese Aktivität kennzeichnet den Beginn des Verpackens an einer Packstation. Sie wird üblicherweise protokolliert, wenn ein Mitarbeitender die kommissionierten Artikel oder den Auftragsbehälter an der Packstation scannt, um die Sendung vorzubereiten. | ||
| Warum das wichtig ist Dieses Ereignis markiert die Übergabe von der Kommissionierung an das Verpacken. Es grenzt die Verpackungsphase der Auftragsabwicklung ab und hilft, Engpässe im Verpackungsbereich zu erkennen. Woher beziehen Dabei kann es sich um ein explizites Transaktionsprotokoll aus der Benutzeroberfläche einer Packstation handeln. Alternativ lässt sich der Vorgang aus der ersten mit einem Timestamp versehenen Aktivität ableiten, die für diesen Auftrag einem Packarbeitsplatz zugeordnet ist. Erfassung Timestamp der Transaktion „Start Packing“ an einer Packstation. Ereignistyp explicit | |||
| Putaway Task Created | Diese Aktivität kennzeichnet die Erstellung einer Systemaufgabe, mit der eingegangene Waren von der Warenannahme an ihren endgültigen Lagerplatz bewegt werden. Das WMS erzeugt dieses explizite Systemereignis, um einen Lagerbediener anzuweisen. | ||
| Warum das wichtig ist Damit beginnt die Einlagerung. Verzögerungen zwischen dem Wareneingang und der Erstellung der Einlagerungsaufgabe können auf Probleme bei der Systemkonfiguration oder -leistung hindeuten. Die Waren bleiben dann im Wareneingangsbereich stehen. Woher beziehen Wird in den Tabellen zur Aufgabenverwaltung oder Lagersteuerung erzeugt und protokolliert. Suchen Sie nach dem Erstellungs-Timestamp von Einlagerungsaufgaben oder Umlagerungsaufträgen, die mit der eingehenden Lieferung verknüpft sind. Erfassung Erstellungs-Timestamp der vom System erzeugten Einlagerungsaufgabe. Ereignistyp explicit | |||
| Quality Inspection Performed | Dieses Ereignis steht für eine Qualitätsprüfung der eingegangenen Waren. Sie kann für bestimmte Materialien ein Standardschritt sein oder durch eine Ausnahme ausgelöst werden. Erfasst wird sie, wenn ein Qualitätsprüfer seine Ergebnisse im System dokumentiert. | ||
| Warum das wichtig ist Qualitätsprüfungen können den Wareneingang erheblich verzögern. Die Analyse ihrer Häufigkeit und Dauer hilft, Qualitätsprobleme bei Lieferanten und Engpässe im Prüfablauf zu erkennen. Woher beziehen Erfasst in Modulen des Qualitätsmanagements (QM) oder in Protokollen zur eingehenden Lieferung. Suchen Sie nach bestimmten Transaktionscodes für Prüfergebnisse oder nach Statusänderungen des Bestands auf „Quality Hold“. Erfassung Timestamp des Abschlusses der Qualitätsprüfung oder der Statusaktualisierung. Ereignistyp explicit | |||
| Waren verpackt | Dieses Ereignis bestätigt, dass alle Artikel einer Sendung in Versandbehälter verpackt und die Etiketten erstellt wurden. Es wird erfasst, wenn der Verpacker den Abschluss des Verpackungsvorgangs für den Auftrag im System bestätigt. | ||
| Warum das wichtig ist Damit sind die wertschöpfenden Tätigkeiten innerhalb des Lagers abgeschlossen. Die Zeit bis zur Abfahrt der Sendung umfasst die Bereitstellung und Verladung. In diesem Abschnitt können Verzögerungen entstehen. Woher beziehen Dieses Ereignis wird explizit protokolliert, wenn der Verpackungsvorgang abgeschlossen ist. Achten Sie auf eine Statusänderung der Auslieferung auf „Packed“ oder auf einen Abschluss-Timestamp der Packstationstransaktion. Erfassung Timestamp der Transaktion „Confirm Packing“ oder „Close Container“. Ereignistyp explicit | |||
Anleitungen zur Datenextraktion
Schritte
- Voraussetzungen und Zugriff: Stellen Sie sicher, dass Sie über ein Benutzerkonto für Blue Yonder WMS mit den erforderlichen Berechtigungen zum Ausführen von MOCA-Befehlen und zum Zugriff auf die benötigten Tabellen verfügen, etwa ord_hdr, pckwrk_dtl und invmov. Sie benötigen außerdem Zugriff auf einen MOCA-Client, zum Beispiel die MOCA Console oder eine Befehlszeilenschnittstelle.
- MOCA-Skript prüfen und anpassen: Kopieren Sie das bereitgestellte MOCA-Skript. Prüfen Sie die Tabellen- und Spaltennamen sorgfältig und gleichen Sie sie mit Ihrer Blue Yonder WMS-Implementierung ab. Achten Sie besonders auf Platzhalter wie
@[where_clause_dates]und@[where_clause_warehouse], die Sie durch konkrete Werte ersetzen müssen. - Extraktionsparameter festlegen: Ersetzen Sie die Platzhaltervariablen im Skript. Legen Sie für
@[where_clause_dates]einen konkreten Zeitraum fest, zum Beispielwhere adddte between 'YYYY-MM-DD' and 'YYYY-MM-DD'. Geben Sie für@[where_clause_warehouse]die Lager-IDs an, deren Daten Sie extrahieren möchten, zum Beispielwhere wh_id = '[Your Warehouse ID]'. - Mit dem MOCA-Server verbinden: Starten Sie Ihren MOCA-Client, zum Beispiel die MOCA Console, und stellen Sie eine Verbindung zur richtigen Blue Yonder WMS-Umgebung her.
- MOCA-Skript ausführen: Fügen Sie das angepasste Skript in die MOCA Console ein und führen Sie den Befehl aus. Das Skript wird auf dem Server ausgeführt und erfasst Daten für alle angegebenen Aktivitäten.
- Ausführung überwachen: Bei großen Datenmengen kann die Abfrage längere Zeit in Anspruch nehmen. Achten Sie in der Konsole auf Fehlermeldungen und Leistungshinweise. Läuft die Abfrage in einen Timeout, führen Sie sie für kleinere Zeiträume aus.
- Ergebnisse in eine Datei exportieren: Nach erfolgreicher Ausführung werden die Ergebnisse in der Konsole angezeigt. Verwenden Sie die Exportfunktion des Clients, um die Ausgabe als CSV-Datei zu speichern. Über die Befehlszeile können Sie die Ausgabe beispielsweise direkt in eine Datei umleiten:
mocarun -S "[Your MOCA Script]" > event_log.csv. - CSV-Datei für ProcessMind formatieren: Öffnen Sie die exportierte CSV-Datei. Prüfen Sie, ob die Spaltenüberschriften den in der Abfrage angegebenen Attributen entsprechen, zum Beispiel
WarehouseOrder,ActivityNameundEventStartTime. Speichern Sie die Datei mit UTF-8-Kodierung, damit beim Upload keine Zeichenfehler auftreten. - Prüfen und hochladen: Kontrollieren Sie die Datei abschließend auf offensichtliche Fehler und Unstimmigkeiten. Laden Sie die CSV-Datei anschließend zur Analyse in ProcessMind hoch.
Konfiguration
- Zeitraum: Für eine repräsentative Auswahl verschiedener Prozessabläufe empfiehlt sich eine Datenextraktion über einen Zeitraum von 3 bis 6 Monaten. Wenden Sie den Platzhalter für den Datumsfilter
@[where_clause_dates]in jeder SELECT-Anweisung auf die primäre Timestamp-Spalte an, zum Beispieladddteodermoddte. - Filter für Lager und Kunden: Begrenzen Sie den Umfang der Extraktion immer durch Filter. Verwenden Sie den Platzhalter
@[where_clause_warehouse], um nach bestimmten Lager-IDs (wh_id) und, falls zutreffend, Kunden-IDs (client_id) zu filtern. Das ist wichtig für die Leistung und die Relevanz der Daten. - Filter für Auftragsarten: Sie können die Analyse auf bestimmte Lagerauftragsarten (
ordtyp) beschränken. Analysieren Sie beispielsweise nur ausgehende Kundenaufträge oder eingehende Bestellungen. Ergänzen Sie den Filter im WHERE-Abschnitt des entsprechenden Skriptteils. - Leistung berücksichtigen: Das Extraktionsskript verknüpft mehrere große Tabellen und führt sie zusammen. Planen Sie die Extraktion außerhalb der Spitzenzeiten, um die Systemleistung nicht zu beeinträchtigen. Bei sehr großen Umgebungen empfiehlt sich eine Extraktion in kleineren, aufeinanderfolgenden Abschnitten, zum Beispiel jeweils für einen Monat.
- Voraussetzungen: Der Benutzer, der das Skript ausführt, benötigt Leseberechtigungen für alle in der Abfrage referenzierten Tabellen, darunter
ord_hdr,ord_dtl,invmov,pckwrk_dtl,asnhdrundtrn_log. Außerdem muss der Benutzer zum Ausführen von MOCA-Befehlen berechtigt sein.
a Beispielabfrage 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]'
]Schritte
- Datenbankverbindung herstellen: Besorgen Sie sich schreibgeschützte Zugangsdaten und die Verbindungsinformationen für die zugrunde liegende Blue Yonder WMS-Datenbank, in der Regel Oracle oder SQL Server. Stellen Sie die Verbindung mit einem gängigen SQL-Client wie DBeaver, Oracle SQL Developer oder SQL Server Management Studio her.
- Zentrale WMS-Tabellen ermitteln: Die bereitgestellte Abfrage greift auf gängige Blue Yonder WMS-Tabellen wie
ord(Aufträge),pckwrk(Kommissionieraufträge),wrkque(Arbeitswarteschlange),invmov(Bestandsbewegungen) undlodhdr(Ladungskopf) zu. Prüfen Sie die Tabellennamen und Spaltenstrukturen anhand des Datenwörterbuchs Ihres Systems, da Anpassungen möglich sind. - SQL-Abfrage prüfen und parametrisieren: Kopieren Sie das bereitgestellte SQL-Skript in Ihren SQL-Client. Suchen Sie die Platzhaltervariablen in der Common Table Expression (CTE)
BaseOrdersam Anfang des Skripts. - Zeitraum festlegen: Passen Sie die Klauseln
adddte >= 'YYYY-MM-DD'undadddte < 'YYYY-MM-DD'an den gewünschten Extraktionszeitraum an. Für die erste Analyse empfiehlt sich ein Zeitraum von 3 bis 6 Monaten. - Systemspezifische Filter anwenden: Passen Sie den Filter
wh_id = '[Your_Warehouse_ID]'an, um die Extraktion auf ein bestimmtes Lager zu begrenzen. Ergänzen oder ändern Sie bei Bedarf weitere Filter, etwaclient_idin Umgebungen mit mehreren Kunden. - Extraktionsskript ausführen: Führen Sie das vollständige SQL-Skript aus. Die Abfrage führt Ereignisse aus mehreren Tabellen in einem einheitlichen Event-Log-Format zusammen. Die Ausführungsdauer hängt vom Zeitraum und Datenvolumen ab.
- Ergebnisse stichprobenartig prüfen: Prüfen Sie die Ausgabe nach Abschluss der Abfrage kurz. Kontrollieren Sie, ob die Spalten
WarehouseOrder,ActivityNameundEventStartTimewie erwartet gefüllt sind. Die Zeilenzahl sollte deutlich über der Anzahl eindeutiger Lageraufträge liegen. - Event Log exportieren: Exportieren Sie die Abfrageergebnisse als CSV-Datei. Stellen Sie UTF-8 als Dateikodierung ein, um Zeichenfehler beim Upload zu vermeiden.
- Upload vorbereiten: Prüfen Sie, ob die Spaltenüberschriften in der exportierten CSV-Datei den erforderlichen Attributen entsprechen, zum Beispiel
WarehouseOrder,ActivityNameundEventStartTime. Anschließend können Sie die Datei in die Process-Mining-Software hochladen.
Konfiguration
- Voraussetzungen: Sie benötigen schreibgeschützten SQL-Zugriff auf die Blue Yonder WMS-Datenbank. Kenntnisse der spezifischen WMS-Konfiguration und des Datenmodells Ihrer Organisation sind von Vorteil.
- Datenbankverbindung: Für diese Methode ist eine direkte Verbindung zur Datenbank erforderlich. Stellen Sie vor Beginn sicher, dass die erforderlichen Firewall-Regeln und Netzwerkberechtigungen eingerichtet sind.
- Filter für den Zeitraum: Legen Sie in der WHERE-Klausel der Abfrage unbedingt einen konkreten Zeitraum fest, um das Datenvolumen zu begrenzen. Für aussagekräftige Analysen reichen in der Regel 3 bis 6 Monate aus, ohne die Datenbank übermäßig zu belasten.
- Filter für Lager und Kunden: Filtern Sie in Umgebungen mit mehreren Lagern oder Kunden immer nach der jeweiligen
wh_id(Lager-ID) undclient_id(Kunden-ID). So bleibt die Analyse fokussiert und der Datensatz handhabbar. - Leistung berücksichtigen: Die Ausführung dieser Abfrage auf einer produktiven Datenbank kann die Systemleistung beeinträchtigen. Führen Sie sie möglichst außerhalb der Spitzenzeiten oder, falls verfügbar, auf einer dedizierten Reporting-Datenbank oder einer replizierten Datenbank aus.
- Systemanpassungen: Die bereitgestellte Abfrage verwendet standardisierte Tabellen- und Spaltennamen. Passen Sie diese gegebenenfalls an individuelle Erweiterungen oder Versionsunterschiede Ihrer Blue Yonder WMS-Instanz an. Wenden Sie sich bei Fragen an die interne WMS-Administration oder prüfen Sie das Datenwörterbuch.
a Beispielabfrage 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 CanceledMöchten Sie loslegen?
Verwenden Sie dieses Template als Grundlage für Ihr Process Mining und erschließen Sie neue Effizienzpotenziale im Lagerbetrieb. Beginnen Sie noch heute damit, Ihren Materialfluss zu optimieren.
Holen Sie heute das Maximum aus Blue Yonder WMS heraus
Ermitteln Sie Engpässe, vermeiden Sie Kommissionierfehler und erreichen Sie eine Bestandsgenauigkeit von 99,5 %.
Keine Kreditkarte erforderlich. 14 Tage kostenlos testen.