Szablon danych dotyczących zarządzania magazynem
Szablon danych dotyczących zarządzania magazynem
- Zalecane atrybuty do zebrania na potrzeby szczegółowej analizy
- Najważniejsze działania do śledzenia w przepływie materiałów
- Praktyczne wskazówki dotyczące pobierania danych z Blue Yonder WMS
Atrybuty zarządzania magazynem
| Nazwa | Opis | ||
|---|---|---|---|
| Czas rozpoczęcia zdarzenia EventStartTime | Znacznik czasu wskazujący, kiedy rozpoczęła się konkretna aktywność lub zdarzenie magazynowe. | ||
| Opis Ten atrybut zapisuje datę i godzinę rozpoczęcia zadania lub zdarzenia magazynowego. Określa kolejność wszystkich aktywności w ramach sprawy. Ten znacznik czasu jest niezbędny w analizach process mining opartych na czasie. Służy do porządkowania zdarzeń, obliczania czasu cyklu między aktywnościami i czasu trwania całego procesu, a także do wykrywania oczekiwania i opóźnień. Stanowi podstawę analizy wyników i jest potrzebny do animowania mapy procesu. Dlaczego to ważne Znacznik czasu rozpoczęcia jest niezbędny do chronologicznego uporządkowania zdarzeń i obliczenia wszystkich miar wyników, takich jak czas cyklu i czas oczekiwania. Skąd pobrać Znajduje się w dzienniku zdarzeń lub tabelach zadań. Odpowiada czasowi utworzenia lub rozpoczęcia zarejestrowanej czynności. Przykłady 2023-10-26T08:30:00Z2023-10-26T09:15:10Z2023-10-26T11:05:45Z | |||
| Nazwa aktywności ActivityName | Nazwa konkretnego zadania lub zdarzenia magazynowego, na przykład „Pobranie towarów” lub „Nadanie przesyłki”. | ||
| Opis Ten atrybut opisuje konkretny etap lub zadanie wykonane w ramach procesu zarządzania magazynem. Każde zdarzenie w dzienniku procesu ma przypisaną nazwę aktywności, która wraz z innymi zdarzeniami tworzy sekwencję kroków procesu. Podczas analizy nazwa aktywności jest podstawą do odkrywania mapy procesu, badania przejść między krokami oraz wykrywania wąskich gardeł i odstępstw od standardowego przebiegu. Jest wykorzystywana w niemal każdej analizie process mining, od weryfikacji zgodności po monitorowanie wyników. Dlaczego to ważne Ten atrybut jest niezbędny do zbudowania mapy procesu. Określa poszczególne kroki i pozwala przedstawić oraz analizować przebieg procesu. Skąd pobrać Informacje te zwykle znajdują się w tabelach zadań magazynowych lub dziennika zdarzeń. Często pochodzą z typu zadania lub kodu statusu. Przykłady Utworzenie zadania kompletacjiPobranie towaru z lokalizacji magazynowejWysyłka nadana | |||
| Zlecenie magazynowe WarehouseOrder | Unikalny identyfikator zlecenia magazynowego, który służy jako główna sprawa do śledzenia wszystkich powiązanych czynności logistycznych od utworzenia do zakończenia. | ||
| Opis Zlecenie magazynowe to główny identyfikator grupujący wszystkie zdarzenia i zadania związane z konkretną potrzebą logistyczną, taką jak przyjęcie dostawy lub wysyłka. Oznacza kompletną jednostkę pracy w magazynie. W process mining atrybut ten służy do zdefiniowania sprawy, co umożliwia analizę całego cyklu życia zlecenia. Śledząc wszystkie aktywności powiązane z jednym zleceniem magazynowym, analitycy mogą mierzyć łączny czas realizacji, wykrywać typowe różnice w przebiegu procesu i odtworzyć pełną drogę zlecenia przez magazyn. Dlaczego to ważne To podstawowy identyfikator sprawy, który łączy wszystkie powiązane czynności magazynowe i umożliwia pełną analizę procesu realizacji zlecenia lub przyjęcia towarów. Skąd pobrać Zwykle jest to klucz główny w tabeli nagłówków zleceń magazynowych. Informacji o tabelach związanych z zarządzaniem zleceniami należy szukać w dokumentacji Blue Yonder WMS. Przykłady WO-0012845WO-0012991WO-0013057 | |||
| Ostatnia aktualizacja danych LastDataUpdate | Znacznik czasu wskazujący, kiedy dane tego rekordu zostały ostatnio odświeżone z systemu źródłowego. | ||
| Opis Ten atrybut zapisuje datę i godzinę ostatniego wyodrębnienia lub zaktualizowania zbioru danych z Blue Yonder WMS. Zawiera metadane o aktualności analizowanych danych. Ten znacznik czasu jest ważny z punktu widzenia zarządzania danymi i pozwala użytkownikom ocenić, jak aktualna jest analiza. Dzięki niemu interesariusze wiedzą, z jakiego okresu pochodzą dane, i mogą mieć pewność, że analizują aktualny obraz procesu. Dlaczego to ważne Ten znacznik czasu informuje o aktualności danych i pozwala ustalić, jaki okres obejmuje analiza. Skąd pobrać To pole metadanych, które zwykle jest generowane i dodawane podczas procesu wyodrębniania danych (ETL). Przykłady 2024-01-15T04:00:00Z2024-01-16T04:00:00Z | |||
| System źródłowy SourceSystem | System, z którego wyodrębniono dane, w tym przypadku Blue Yonder WMS. | ||
| Opis Ten atrybut wskazuje system źródłowy danych o zdarzeniach. W nowoczesnym środowisku IT dane dotyczące jednego procesu od początku do końca mogą pochodzić z kilku systemów, takich jak ERP, WMS i TMS. Wskazanie systemu źródłowego jest ważne z punktu widzenia zarządzania danymi, rozwiązywania problemów i zrozumienia kontekstu danych. Pomaga ustalić źródło problemów z jakością danych i jest niezbędne przy łączeniu danych z wielu systemów w celu uzyskania spójnego obrazu procesu. Dlaczego to ważne Zapewnia informacje o pochodzeniu danych, co pomaga prześledzić je do źródła w celu weryfikacji oraz w sytuacji łączenia danych z wielu systemów. Skąd pobrać Zwykle jest to stała wartość dodawana podczas wyodrębniania danych w celu oznaczenia źródła zbioru danych. Przykłady BlueYonderWMS_USBlueYonderWMS_EU | |||
| Czas zakończenia zdarzenia EventEndTime | Znacznik czasu wskazujący, kiedy zakończyła się konkretna aktywność lub zdarzenie magazynowe. | ||
| Opis Ten atrybut zapisuje datę i godzinę zakończenia zadania lub zdarzenia magazynowego. Jeśli jest dostępny, pozwala dokładnie zmierzyć czas realizacji każdej aktywności. Dostępność czasu rozpoczęcia i zakończenia umożliwia dokładniejszą analizę wyników. Pozwala oddzielić czas oczekiwania, czyli przerwy między aktywnościami, od czasu realizacji, czyli czasu trwania samej aktywności. Dzięki temu można ustalić, czy opóźnienia wynikają z przestojów, czy ze zbyt długiego wykonywania zadań. Dlaczego to ważne Pozwala dokładnie obliczyć czas realizacji aktywności i odróżnić go od czasu oczekiwania, co ułatwia ukierunkowane usprawnianie wyników. Skąd pobrać Znajduje się w dzienniku zdarzeń lub tabelach zadań. Odpowiada czasowi zakończenia lub zamknięcia zarejestrowanej czynności. Przykłady 2023-10-26T08:35:12Z2023-10-26T09:20:05Z2023-10-26T11:06:00Z | |||
| Identyfikator użytkownika/operatora UserOperatorId | Identyfikator pracownika magazynu lub operatora, który wykonał daną aktywność. | ||
| Opis Ten atrybut zawiera unikalny identyfikator osoby odpowiedzialnej za wykonanie danego zadania magazynowego, takiego jak kompletacja, pakowanie lub odłożenie. Łączy aktywności w procesie z zasobami ludzkimi. Analiza aktywności według identyfikatora użytkownika/operatora pomaga zrozumieć wykorzystanie zasobów, rozkład obciążenia pracą i wyniki poszczególnych osób. Pozwala ustalić, którzy operatorzy pracują najwydajniej, kto może potrzebować dodatkowego szkolenia i jak rozdzielane są zadania w zespole. To jeden z głównych wymiarów dashboardu wykorzystania zasobów magazynowych. Dlaczego to ważne Ten atrybut łączy etapy procesu z osobami, które je wykonały, umożliwiając analizę wyników pracy, obciążenia i potrzeb szkoleniowych. Skąd pobrać Zwykle znajduje się w tabelach zadań lub transakcji i jest powiązany z użytkownikiem zalogowanym do systemu lub urządzenia przenośnego podczas wykonywania operacji. Przykłady JSMITHBWILLISAMILLER | |||
| Lokalizacja magazynowa StorageLocation | Konkretne miejsce w magazynie, na przykład lokalizacja składowania lub alejka, w którym towary są przechowywane albo z którego są pobierane. | ||
| Opis Ten atrybut wskazuje fizyczną lokalizację w magazynie powiązaną z zadaniem. W przypadku odłożenia jest to lokalizacja docelowa, a w przypadku kompletacji lokalizacja źródłowa. Może być zapisana jako kod złożony z oznaczeń alejki, regału, półki i miejsca składowania. Analiza danych według lokalizacji magazynowej pomaga ocenić układ magazynu, strategie rozmieszczania towarów i przemieszczanie zasobów. Ułatwia wykrywanie miejsc o dużym natężeniu ruchu, niewykorzystanych stref i potencjalnych wąskich gardeł w przepływie materiałów. Ten atrybut jest podstawą dashboardu trendów wykorzystania lokalizacji magazynowych. Dlaczego to ważne Dostarcza kontekstu potrzebnego do analizy układu magazynu i skuteczności strategii rozmieszczania towarów oraz do wykrywania wąskich gardeł w ich przemieszczaniu. Skąd pobrać Dostępny w tabelach dotyczących zapasów, zadań magazynowych, takich jak kompletacja i odłożenie, oraz danych podstawowych lokalizacji. Przykłady A1-R03-S02-B01B5-R10-S04-B05C2-R01-S01-B02 | |||
| Planowana ilość PlannedQuantity | Oczekiwana liczba produktów dla danego zadania, na przykład liczba produktów do pobrania lub przyjęcia. | ||
| Opis Planowana ilość to docelowa liczba jednostek określona w zleceniu magazynowym dla danego zadania. W przypadku dostawy przychodzącej jest to ilość oczekiwana od dostawcy. W przypadku zadania kompletacji jest to ilość zamówiona przez klienta. Ten atrybut jest niezbędny do analizy dokładności. Porównanie planowanej ilości z ilością rzeczywistą pozwala wykryć rozbieżności podczas przyjęcia, kompletacji lub liczenia zapasów. Wspiera wskaźniki KPI, takie jak odsetek rozbieżności w ilości skompletowanych produktów, i jest potrzebny do dashboardu kontroli dokładności ilości. Dlaczego to ważne Stanowi punkt odniesienia przy pomiarze dokładności i pozwala wykrywać rozbieżności ilościowe podczas przyjęcia i kompletacji. Skąd pobrać Znajduje się w tabelach szczegółów lub pozycji zleceń magazynowych albo konkretnych zadań. Przykłady 1005024 | |||
| Poziom priorytetu PriorityLevel | Priorytet zlecenia magazynowego, na przykład „Wysoki”, „Standardowy” lub „Niski”. | ||
| Opis Poziom priorytetu określa pilność zlecenia magazynowego. Zlecenia o wysokim priorytecie, takie jak przesyłki ekspresowe, powinny być realizowane szybciej niż standardowe. WMS wykorzystuje ten atrybut do ustalania kolejności zadań i przydzielania zasobów. W process mining atrybut ten służy do sprawdzania skuteczności zasad ustalania priorytetów. Dashboard realizacji zleceń o wysokim priorytecie wykorzystuje to pole do filtrowania pilnych zleceń i porównywania ich czasu cyklu ze zleceniami standardowymi. Pozwala sprawdzić, czy zlecenia o wysokim priorytecie rzeczywiście przechodzą przez proces szybciej, czy też zatrzymują się w tych samych wąskich gardłach. Dlaczego to ważne Pozwala sprawdzić, czy zlecenia o wysokim priorytecie są realizowane szybciej niż standardowe, i ocenić skuteczność zasad ustalania priorytetów. Skąd pobrać Informacje te są zwykle zapisane w tabeli nagłówków zleceń magazynowych. Przykłady WysokiStandardowyNiski | |||
| Rzeczywista ilość ActualQuantity | Rzeczywista liczba produktów obsłużonych w ramach zadania, na przykład fizycznie policzonych lub pobranych. | ||
| Opis Rzeczywista ilość to liczba jednostek fizycznie obsłużonych przez operatora magazynu podczas zadania. Może to być liczba produktów przyjętych od dostawcy, pobranych z lokalizacji magazynowej lub spakowanych do pojemnika transportowego. Porównanie z planowaną ilością pozwala wykryć wyjątki i błędy w procesie. Rzeczywista ilość jest podstawową miarą przy obliczaniu odsetka rozbieżności, który wskazuje jakość operacji. Dane te pomagają wykrywać problemy z dostawami od dostawców, błędy kompletacji i niezgodności w zapasach. Dlaczego to ważne Porównanie z planowaną ilością jest niezbędne do wykrywania błędów procesu i obliczania wskaźników KPI jakości, takich jak odsetek rozbieżności. Skąd pobrać Znajduje się w tabelach potwierdzeń zadań lub dzienników transakcji, w których operatorzy zapisują wykonaną ilość. Przykłady 1004924 | |||
| Wymagana data zakończenia RequestedCompletionDate | Data i godzina, do której zlecenie magazynowe ma zostać zrealizowane i wysłane. | ||
| Opis Wymagana data zakończenia określa poziom usług (SLA) lub termin realizacji wychodzącego zlecenia magazynowego. Do tego czasu towary powinny zostać skompletowane, spakowane i przygotowane do wysyłki. Ta data stanowi punkt odniesienia przy ocenie rzeczywistych wyników. Służy do obliczania wskaźnika KPI terminowości wysyłek przez porównanie z rzeczywistym czasem nadania. Analiza zleceń według tego atrybutu pomaga wykryć te, którym grozi opóźnienie, i ustalić przyczyny niedotrzymania SLA. Dlaczego to ważne Ten atrybut stanowi punkt odniesienia przy pomiarze terminowości i jest niezbędny do obliczenia wskaźnika KPI terminowości wysyłek. Skąd pobrać Zwykle jest zapisany w tabeli nagłówków zleceń magazynowych i często pochodzi ze źródłowego zlecenia sprzedaży lub żądania dostawy. Przykłady 2023-10-27T17:00:00Z2023-10-28T12:00:00Z2023-11-01T17:00:00Z | |||
| Identyfikator magazynu WarehouseId | Identyfikator konkretnego magazynu lub centrum dystrybucji, w którym odbyła się dana aktywność. | ||
| Opis Identyfikator magazynu jednoznacznie wskazuje obiekt, w którym przebiega proces. Jest niezbędny w organizacjach prowadzących kilka centrów dystrybucji. Ten atrybut umożliwia porównywanie wyników i analizę porównawczą różnych lokalizacji. Filtrowanie lub podział danych według identyfikatora magazynu pozwala porównywać wyniki, wykrywać dobre praktyki w najlepiej działających obiektach i ustalać, dlaczego inne osiągają słabsze wyniki. Umożliwia analizę operacji w wielu lokalizacjach. Dlaczego to ważne W organizacjach działających w wielu lokalizacjach ten atrybut jest niezbędny do porównywania wyników i procesów między obiektami. Skąd pobrać Często jest to pole organizacyjne najwyższego poziomu, dostępne w niemal wszystkich tabelach transakcji. Można je też wywnioskować na podstawie instancji systemu. Przykłady WHC-01DC-EAST-03FAC-WEST | |||
| Identyfikator sprzętu EquipmentId | Identyfikator użytego sprzętu do transportu materiałów, na przykład konkretnego wózka widłowego lub przenośnika taśmowego. | ||
| Opis Identyfikator sprzętu wskazuje maszynę lub urządzenie użyte do wykonania zadania magazynowego. Może to być wózek widłowy, wózek paletowy, autonomiczny pojazd transportowy (AGV) lub konkretne stanowisko pakowania. Ten atrybut pozwala analizować wykorzystanie i wydajność sprzętu oraz potrzeby konserwacyjne. Śledzenie aktywności dla poszczególnych urządzeń pomaga kierownikom wykrywać sprzęt przeciążony lub niewykorzystany, porównywać wydajność różnych typów maszyn i planować konserwację. To jeden z głównych wymiarów dashboardu wykorzystania zasobów magazynowych. Dlaczego to ważne Pozwala analizować wykorzystanie i wydajność sprzętu, co pomaga lepiej przydzielać zasoby i planować konserwację. Skąd pobrać Może być zapisany w dziennikach realizacji zadań, zwłaszcza w miejscach, w których operatorzy logują się na używanym sprzęcie. Przykłady FORKLIFT-07AGV-03PACKSTATION-12 | |||
| Identyfikator wysyłki ShipmentId | Unikalny identyfikator wysyłki wychodzącej, do której należy zlecenie magazynowe. | ||
| Opis Identyfikator wysyłki to identyfikator wyższego poziomu, który może grupować kilka zleceń magazynowych wysyłanych tą samą ciężarówką lub w tym samym pojemniku. W przypadku pojedynczego zlecenia może być taki sam jak numer zlecenia magazynowego lub dostawy. Analiza według identyfikatora wysyłki pozwala przyjrzeć się procesowi nadania. Pomaga zrozumieć, jak łączone są zlecenia, zmierzyć czas od odłożenia do nadania całego ładunku oraz ocenić wydajność działu wysyłek. Łączy czynności magazynowe z końcowym etapem transportu w łańcuchu dostaw. Dlaczego to ważne Grupuje zlecenia magazynowe wysyłane razem, umożliwiając analizę łączenia przesyłek i procesu nadania. Skąd pobrać Znajduje się w tabelach dotyczących wysyłek lub transportu i jest powiązany ze zleceniami magazynowymi. Przykłady SHP-45000123SHP-45000124SHP-45000125 | |||
| Niezgodność ilości IsQuantityMismatch | Wartość logiczna wskazująca, czy rzeczywista ilość obsłużonych produktów różni się od ilości planowanej dla danego zadania. | ||
| Opis Ten obliczany atrybut wskazuje, czy w danym zadaniu, na przykład kompletacji lub przyjęciu, wystąpiła rozbieżność ilościowa. Przyjmuje wartość prawda, gdy „Rzeczywista ilość” nie jest równa „Planowanej ilości”. Wskaźnik ten ułatwia wykrywanie i zliczanie błędów w procesie. Upraszcza obliczanie wskaźników KPI, takich jak odsetek rozbieżności ilościowych w kompletacji i przyjęciach. Ułatwia też analizę przyczyn źródłowych, ponieważ analitycy mogą filtrować zdarzenia z niezgodną ilością i szukać prawidłowości związanych z produktami, operatorami lub lokalizacjami. Dlaczego to ważne Oznacza zdarzenia z błędami ilościowymi, ułatwia obliczanie odsetka rozbieżności i pozwala skupić analizę na zadaniach wykonanych nieprawidłowo. Skąd pobrać Obliczany przez porównanie pól PlannedQuantity i ActualQuantity dla każdej odpowiedniej aktywności. Przykłady falsetruefalse | |||
| SKU produktu ProductSku | Jednostka magazynowa (SKU) lub numer materiału obsługiwanego produktu. | ||
| Opis Ten atrybut wskazuje konkretny produkt związany z zadaniem magazynowym. Zawiera szczegółowe informacje o materiałach, które są przemieszczane, składowane, kompletowane i pakowane. Analiza procesu według SKU produktu może ujawnić prawidłowości dotyczące konkretnych artykułów. Niektóre produkty mogą na przykład częściej powodować błędy kompletacji, wymagać dłuższego czasu odłożenia ze względu na specjalne warunki obsługi lub być składowane w nieefektywnych lokalizacjach. Pozwala to usprawniać procesy dla poszczególnych produktów i poprawiać strategie rozmieszczania towarów. Dlaczego to ważne Umożliwia analizę na poziomie produktu i pomaga wykrywać artykuły powodujące opóźnienia lub błędy w procesie albo wymagające specjalnej obsługi. Skąd pobrać Informacje te znajdują się na poziomie pozycji w tabelach zleceń magazynowych lub zadań. Przykłady PN-A5540-BSKU-300-RED-LGHW-88201 | |||
| Status zadania TaskStatus | Końcowy status danego zadania, na przykład „Zakończone”, „Anulowane” lub „Niepowodzenie”. | ||
| Opis Ten atrybut opisuje wynik konkretnego zadania magazynowego. Większość zadań kończy się powodzeniem, ale niektóre mogą zostać anulowane przez przełożonego lub zakończyć się niepowodzeniem z przyczyn systemowych albo operacyjnych. Dzięki temu atrybutowi dostępne są informacje wykraczające poza samą nazwę aktywności. Analiza według statusu zadania pomaga zrozumieć wyjątki i problemy w procesie. Duży odsetek anulowanych zadań lub zadań zakończonych niepowodzeniem może wskazywać na problemy z dokładnością zapasów, konfiguracją systemu lub przeszkoleniem operatorów. Pozwala wykryć aktywności podatne na błędy, które wymagają dalszego zbadania. Dlaczego to ważne Informuje o wyniku aktywności i umożliwia analizę wyjątków, takich jak anulowane zadania lub zadania zakończone niepowodzeniem, które mogą wskazywać na głębsze problemy operacyjne. Skąd pobrać Zwykle znajduje się w tabeli zadań i wskazuje końcowy stan rekordu zadania. Przykłady ZakończoneAnulowaneWstrzymane | |||
| Typ zlecenia magazynowego WarehouseOrderType | Określa kategorię zlecenia magazynowego, na przykład przyjęcie dostawy, wysyłkę lub przesunięcie wewnętrzne. | ||
| Opis Ten atrybut określa ogólny cel zlecenia magazynowego. Typowe kategorie to dostawy przychodzące od dostawców, wysyłki do klientów, obsługa zwrotów i wewnętrzne przesunięcia zapasów między lokalizacjami magazynowymi. Podział procesu według typu zlecenia magazynowego to podstawowy pierwszy krok analizy. Procesy przychodzące i wychodzące często znacznie się różnią pod względem etapów, zasobów i celów. Ten atrybut pozwala filtrować dane i analizować osobno wybrany proces, na przykład przyjęcie towarów lub realizację zlecenia. Dlaczego to ważne Pozwala rozdzielić i porównać różne procesy, na przykład przychodzące i wychodzące, które mają odmienny przebieg i cele. Skąd pobrać Znajduje się w tabeli nagłówków zleceń magazynowych, zwykle w polu typu dokumentu lub kategorii zlecenia. Przykłady Dostawa przychodzącaWysyłka wychodzącaPrzesunięcie wewnętrzne | |||
| Wysyłka terminowa IsOnTimeShipment | Wartość logiczna ustawiona na prawdę, jeśli wysyłka została nadana w wymaganym terminie lub wcześniej. | ||
| Opis Ten obliczany atrybut wskazuje, czy zlecenie spełniło warunki SLA dotyczące wysyłki. Jego wartość wynika z porównania znacznika czasu aktywności „Wysyłka nadana” z wymaganą datą zakończenia zlecenia. Ten wskaźnik ułatwia analizę i prezentację terminowości. Pozwala łatwo filtrować i agregować dane, aby obliczyć wskaźnik KPI terminowości wysyłek i zasilać odpowiedni dashboard. Umożliwia też analizę przyczyn źródłowych, która pomaga wykryć typowe cechy opóźnionych wysyłek. Dlaczego to ważne Ta wartość logiczna ułatwia obliczenie wskaźnika KPI terminowości wysyłek i filtrowanie danych w celu analizy cech opóźnionych zleceń. Skąd pobrać Obliczany przez porównanie EventStartTime aktywności „Wysyłka nadana” z atrybutem RequestedCompletionDate. Przykłady truefalsetrue | |||
Działania w procesie zarządzania magazynem
| Działanie | Opis | ||
|---|---|---|---|
| Odłożenie towaru do lokalizacji magazynowej | To zdarzenie potwierdza, że towary zostały przeniesione do wyznaczonego miejsca składowania i zeskanowane. Jest rejestrowane, gdy operator potwierdza wykonanie zadania, zwykle za pomocą ręcznego urządzenia RF. | ||
| Dlaczego to ważne To koniec procesu przyjęcia, po którym zapasy są dostępne do realizacji zamówień. Analiza czasu od przyjęcia do tego etapu jest niezbędna dla dashboardu „Goods Receipt to Putaway Cycle Time”. Skąd pobrać Rejestrowane jako transakcja ze znacznikiem czasu, gdy status zadania składowania zmienia się na „Completed” lub „Confirmed”. Dane znajdują się w tabelach zadań magazynowych lub zleceń przesunięcia. Rejestrowanie Znacznik czasu potwierdzenia zadania składowania. Typ zdarzenia explicit | |||
| Przyjęcie i przeliczenie towaru | To zdarzenie oznacza, że towary zostały rozładowane i zeskanowane, a ich ilość sprawdzono z dokumentami dostawy. Zwykle jest rejestrowane, gdy pracownik przyjęć potwierdza w systemie ilość przyjętego towaru dla każdej pozycji zamówienia. | ||
| Dlaczego to ważne To ważny etap, w którym zapasy stają się oficjalnie dostępne w systemie, choć nie są jeszcze gotowe do realizacji zamówień. Czas trwania i dokładność tego etapu bezpośrednio wpływają na widoczność zapasów i rozpoczęcie składowania. Skąd pobrać To jawna transakcja zapisywana w dziennikach zapasów lub przyjęć. Warto szukać transakcji księgowania przyjęcia towaru lub zmian statusu pozycji dostawy przychodzącej na „Received”. Rejestrowanie Znacznik czasu transakcji potwierdzającej przyjęcie towaru. Typ zdarzenia explicit | |||
| Utworzenie Warehouse Order | To zdarzenie oznacza utworzenie zamówienia magazynowego, czyli głównego dokumentu służącego do zarządzania zadaniami przyjęcia, wydania lub operacjami wewnątrz magazynu. Zwykle jest rejestrowane jako jawna transakcja w chwili wprowadzenia nowego zamówienia do Blue Yonder WMS, ręcznie lub przez integrację. | ||
| Dlaczego to ważne To jednoznaczny początek procesu. Analiza czasu od tego zdarzenia do zakończenia pozwala określić całkowity czas realizacji zamówienia, niezbędny do pomiaru ogólnej efektywności i dotrzymywania uzgodnionych poziomów obsługi. Skąd pobrać To zdarzenie prawdopodobnie jest rejestrowane w tabeli nagłówków zamówień na podstawie znacznika czasu utworzenia rekordu zamówienia magazynowego. Warto sprawdzić tabele takie jak Rejestrowanie Znacznik czasu utworzenia rekordu zamówienia magazynowego. Typ zdarzenia explicit | |||
| Utworzenie zadania kompletacji | To zdarzenie oznacza utworzenie zadania dla operatora, który ma pobrać towar z lokalizacji magazynowej w celu realizacji zamówienia wychodzącego. Jest generowane przez WMS w chwili zwolnienia zamówienia do kompletacji. | ||
| Dlaczego to ważne To początek fizycznego procesu wydania towaru. Analiza czasu od utworzenia zamówienia do utworzenia zadania kompletacji ujawnia opóźnienia w obsłudze i przydzielaniu zamówień. Skąd pobrać Rejestrowane w tabelach zarządzania zadaniami lub kontroli magazynu. Odpowiada znacznikowi czasu utworzenia zadań kompletacji powiązanych z zamówieniem magazynowym. Rejestrowanie Znacznik czasu utworzenia zadania kompletacji wygenerowanego przez system. Typ zdarzenia explicit | |||
| Wysyłka nadana | To zdarzenie oznacza, że spakowane towary załadowano na samochód przewoźnika, który opuścił magazyn. Zwykle jest rejestrowane po zaksięgowaniu w systemie rozchodu towarów, co finalizuje wysyłkę. | ||
| Dlaczego to ważne To ważny etap, który oznacza koniec odpowiedzialności magazynu za zlecenie. Jest to końcowy punkt danych służący do pomiaru terminowości wysyłek i całkowitego czasu realizacji zlecenia. Skąd pobrać To ważna transakcja finansowa i logistyczna, często nazywana „zaksięgowaniem rozchodu towarów” (PGI). Jej znacznik czasu wyznacza moment nadania przesyłki i zwykle jest zapisany w tabelach dokumentów dostawy wychodzącej lub wysyłki. Rejestrowanie Znacznik czasu transakcji zaksięgowania rozchodu towarów (PGI). Typ zdarzenia explicit | |||
| Zlecenie magazynowe zakończone | To końcowy status zlecenia magazynowego. Oznacza, że zakończono wszystkie powiązane czynności, w tym wysyłkę, i zamknięto zlecenie. Jest rejestrowany po zmianie statusu cyklu życia zlecenia na „Zakończone” lub „Zamknięte”. | ||
| Dlaczego to ważne Ta aktywność oznacza definitywny koniec sprawy w procesie. Dzięki niej analiza obejmuje pełny cykl życia każdego zlecenia, od początku do końca. Skąd pobrać Zdarzenie można wywnioskować na podstawie zmiany statusu w tabeli nagłówków zleceń magazynowych. Należy szukać statusu końcowego, takiego jak „Zakończone”, „Zamknięte” lub „Zafakturowane”, oraz znacznika czasu jego zmiany. Rejestrowanie Można je wywnioskować ze znacznika czasu ostatniej zmiany statusu w nagłówku zlecenia. Typ zdarzenia inferred | |||
| Pobranie towaru z lokalizacji magazynowej | Oznacza zakończenie zadania kompletacji: operator pobrał produkty i potwierdził tę czynność w systemie. Zdarzenie jest rejestrowane, gdy operator skanuje produkty i potwierdza pobranie na urządzeniu. | ||
| Dlaczego to ważne Ten etap kończy kompletację. Dokładność i czas trwania czynności mają zasadnicze znaczenie dla sprawnej realizacji zamówień i stanowią podstawę analizy „Picking Accuracy”. Skąd pobrać Dane pochodzą ze znacznika czasu potwierdzenia, gdy status zadania kompletacji zmienia się na „Completed”. Znajdują się w tabelach zadań magazynowych, często wraz z informacjami o operatorze i sprzęcie. Rejestrowanie Znacznik czasu potwierdzenia zadania kompletacji. Typ zdarzenia explicit | |||
| Powiadomienie o dostawie przychodzącej | Oznacza otrzymanie od dostawcy awiza wysyłki (ASN), które informuje, że towary są w drodze do magazynu. Zdarzenie jest rejestrowane w chwili otrzymania i przetworzenia ASN przez system, często za pośrednictwem EDI lub portalu. | ||
| Dlaczego to ważne To zdarzenie rozpoczyna planowanie przyjęcia i przydział zasobów. Czas od powiadomienia do fizycznego przyjęcia towaru jest ważnym KPI, który pozwala mierzyć terminowość dostawcy i widoczność dostaw w drodze. Skąd pobrać Dane pochodzą z dzienników odbioru ASN lub znacznika czasu utworzenia dokumentu dostawy przychodzącej w Blue Yonder WMS. Warto sprawdzić tabele dotyczące ASN lub powiadomień o dostawach przychodzących. Rejestrowanie Znacznik czasu z ASN lub dokumentu dostawy przychodzącej. Typ zdarzenia explicit | |||
| Przeprowadzenie kontroli jakości | Oznacza kontrolę jakości przyjętych towarów. Może być standardowym etapem dla określonych materiałów lub zdarzeniem wywołanym przez wyjątek. Jest rejestrowana, gdy kontroler jakości zapisuje wyniki w systemie. | ||
| Dlaczego to ważne Kontrole jakości mogą znacznie opóźniać proces przyjęcia. Analiza ich częstotliwości i czasu trwania pomaga wykryć problemy z jakością dostawców oraz wąskie gardła w workflow kontroli. Skąd pobrać Rejestrowane w modułach zarządzania jakością (QM) lub dziennikach powiązanych z dostawą przychodzącą. Warto szukać kodów transakcji dotyczących wyników kontroli jakości lub zmian statusu zapasów na „Quality Hold”. Rejestrowanie Znacznik czasu zakończenia kontroli jakości lub aktualizacji statusu. Typ zdarzenia explicit | |||
| Przygotowanie do wysyłki | Oznacza przemieszczenie spakowanych pojemników ze strefy pakowania do wyznaczonego pasa odkładczego, gdzie czekają na odbiór przez przewoźnika. Zdarzenie jest rejestrowane, gdy operator potwierdza przemieszczenie jednostki ładunkowej do strefy odkładczej. | ||
| Dlaczego to ważne Ta aktywność pozwala analizować czas oczekiwania, czyli okres, w którym spakowane zlecenia czekają na załadunek. Długi czas w strefie odkładczej może wskazywać na słabą koordynację z przewoźnikami lub nieefektywne wykorzystanie tej przestrzeni. Skąd pobrać Zdarzenie można wywnioskować na podstawie zmiany lokalizacji jednostki ładunkowej lub pojemnika transportowego na lokalizację w strefie odkładczej. Może też być rejestrowane jako jawne potwierdzenie zadania „Przenieś do strefy odkładczej”. Rejestrowanie Można je wywnioskować z dzienników ruchów zapasów, które wskazują przeniesienie do lokalizacji odkładczej. Typ zdarzenia inferred | |||
| Przyjazd towaru do doku | To zdarzenie oznacza fizyczny przyjazd ciężarówki lub przewoźnika do doku przyjęć, przed rozpoczęciem rozładunku. Często jest rejestrowane w module zarządzania placem lub podczas odprawy dostawy przez pracownika ochrony. | ||
| Dlaczego to ważne Rejestrowanie czasu przyjazdu pozwala mierzyć terminowość przewoźników i wykrywać opóźnienia między przyjazdem a rozpoczęciem przyjęcia. Ujawnia potencjalne wąskie gardła w zarządzaniu placem lub przy dokach przyjęć. Skąd pobrać Zwykle rejestrowane w module zarządzania placem lub kontroli wjazdu w Blue Yonder WMS. Pracownik przyjęć może też ręcznie wprowadzić znacznik czasu przyjazdu ciężarówki. Rejestrowanie Znacznik czasu transakcji odprawy przewoźnika. Typ zdarzenia explicit | |||
| Rozpoczęcie pakowania | To zdarzenie oznacza rozpoczęcie pakowania na stanowisku pakowania. Zwykle jest rejestrowane, gdy operator skanuje pobrane produkty lub pojemnik z zamówieniem, aby rozpocząć przygotowanie wysyłki. | ||
| Dlaczego to ważne To zdarzenie oznacza przekazanie zamówienia z kompletacji do pakowania. Pozwala wyodrębnić etap pakowania i wykryć wąskie gardła w tym obszarze. Skąd pobrać Może to być jawny zapis transakcji z interfejsu stanowiska pakowania. Można też wywnioskować to zdarzenie na podstawie pierwszej aktywności z oznaczeniem czasu, powiązanej z centrum roboczym pakowania dla danego zlecenia. Rejestrowanie Znacznik czasu transakcji „Rozpocznij pakowanie” na stanowisku pakowania. Typ zdarzenia explicit | |||
| Towary spakowane | To zdarzenie potwierdza, że wszystkie pozycje z wysyłki zostały spakowane do opakowań transportowych i wygenerowano etykiety. Jest rejestrowane, gdy osoba pakująca potwierdza w systemie zakończenie pakowania zlecenia. | ||
| Dlaczego to ważne Oznacza zakończenie czynności zwiększających wartość, wykonywanych na terenie magazynu. Czas od tego momentu do wysłania przesyłki obejmuje oczekiwanie w strefie wysyłkowej i załadunek. Na tym etapie mogą występować opóźnienia. Skąd pobrać To jawnie rejestrowana transakcja, która oznacza zakończenie pakowania. Należy szukać zmiany statusu dostawy wychodzącej na „Spakowana” albo znacznika czasu zakończenia transakcji na stanowisku pakowania. Rejestrowanie Znacznik czasu transakcji „Potwierdź pakowanie” lub „Zamknij pojemnik”. Typ zdarzenia explicit | |||
| Utworzenie zadania składowania | To zdarzenie oznacza utworzenie przez system zadania przeniesienia przyjętych towarów z doku przyjęć do docelowej lokalizacji magazynowej. Jest to jawne zdarzenie systemowe generowane przez logikę WMS w celu przydzielenia zadania operatorowi magazynu. | ||
| Dlaczego to ważne To początek procesu składowania. Opóźnienie między przyjęciem towaru a utworzeniem zadania może wskazywać na problemy z konfiguracją lub wydajnością systemu, przez które towary pozostają w strefie przyjęć. Skąd pobrać Zadanie jest generowane i rejestrowane w tabelach zarządzania zadaniami lub kontroli magazynu. Warto sprawdzić znacznik czasu utworzenia zadań składowania lub zleceń przesunięcia powiązanych z dostawą przychodzącą. Rejestrowanie Znacznik czasu utworzenia zadania składowania wygenerowanego przez system. Typ zdarzenia explicit | |||
| Zlecenie magazynowe anulowane | Oznacza anulowanie zlecenia magazynowego przed jego pełną realizacją lub wysyłką. Zdarzenie jest rejestrowane, gdy użytkownik wykonuje transakcję anulowania, zmieniając status zlecenia na „Anulowane”. | ||
| Dlaczego to ważne Analiza anulowań pomaga ustalić przyczyny problemów w procesie, takie jak brak zapasów lub zmiany po stronie klienta. To ważne zdarzenie kończące, które pozwala zrozumieć odstępstwa od procesu i ich skutki. Skąd pobrać Zdarzenie to zwykle wywnioskowuje się na podstawie końcowego statusu zlecenia magazynowego. Wykorzystuje się znacznik czasu zmiany statusu na „Anulowane” lub „Usunięte”. Rejestrowanie Można je wywnioskować ze znacznika czasu zmiany statusu na „Anulowane”. Typ zdarzenia inferred | |||
Instrukcje pobierania danych
Kroki
- Wymagania wstępne i dostęp: Należy mieć konto użytkownika Blue Yonder WMS z uprawnieniami do wykonywania poleceń MOCA i dostępu do wymaganych tabel, takich jak ord_hdr, pckwrk_dtl i invmov. Potrzebny będzie klient MOCA, na przykład MOCA Console lub interfejs wiersza poleceń.
- Sprawdzenie i dostosowanie skryptu MOCA: Skopiuj dostarczony skrypt MOCA. Sprawdź nazwy tabel i kolumn, aby upewnić się, że odpowiadają konkretnej implementacji Blue Yonder WMS. Zwróć szczególną uwagę na symbole zastępcze, takie jak
@[where_clause_dates]i@[where_clause_warehouse], które trzeba zastąpić rzeczywistymi wartościami. - Ustawienie parametrów pobierania: Zastąp zmienne zastępcze w skrypcie. Dla
@[where_clause_dates]określ zakres dat, na przykładwhere adddte between 'YYYY-MM-DD' and 'YYYY-MM-DD'. Dla@[where_clause_warehouse]podaj identyfikatory magazynów, z których mają zostać pobrane dane, na przykładwhere wh_id = '[Your Warehouse ID]'. - Połączenie z serwerem MOCA: Uruchom klienta MOCA, na przykład MOCA Console, i połącz się z właściwym środowiskiem Blue Yonder WMS.
- Uruchomienie skryptu MOCA: Wklej dostosowany skrypt do MOCA Console i wykonaj polecenie. Skrypt uruchomi się na serwerze i zbierze dane dotyczące wszystkich wskazanych działań.
- Monitorowanie wykonania: Przy dużych zbiorach danych zapytanie może działać długo. Obserwuj komunikaty o błędach i ostrzeżenia dotyczące wydajności w konsoli. Jeśli zapytanie przekroczy limit czasu, podziel pobieranie na krótsze zakresy dat.
- Eksport wyników do pliku: Po pomyślnym wykonaniu skryptu wyniki pojawią się w konsoli. Użyj funkcji eksportu klienta, aby zapisać je jako plik CSV. Z wiersza poleceń można przekierować wynik bezpośrednio do pliku, na przykład:
mocarun -S "[Your MOCA Script]" > event_log.csv. - Przygotowanie pliku CSV do ProcessMind: Otwórz wyeksportowany plik CSV. Sprawdź, czy nagłówki kolumn odpowiadają atrybutom wskazanym w zapytaniu (
WarehouseOrder,ActivityName,EventStartTimeitd.). Zapisz plik w kodowaniu UTF-8, aby uniknąć problemów z wyświetlaniem znaków podczas przesyłania. - Weryfikacja i przesłanie: Sprawdź zawartość pliku pod kątem oczywistych błędów i niespójności. Następnie prześlij plik CSV do ProcessMind, aby rozpocząć analizę.
Konfiguracja
- Zakres dat: Zaleca się pobranie danych z okresu od 3 do 6 miesięcy, aby uwzględnić reprezentatywny zakres wariantów procesu. Symbol zastępczy filtra dat
@[where_clause_dates]należy zastosować do głównej kolumny znacznika czasu w każdej instrukcji SELECT, na przykładadddtelubmoddte. - Filtry magazynu i klienta: Zawsze ograniczaj zakres pobieranych danych za pomocą filtrów. Symbol
@[where_clause_warehouse]powinien służyć do filtrowania według konkretnych identyfikatorów magazynów (wh_id) oraz, jeśli dotyczy, identyfikatorów klientów (client_id). Ma to istotne znaczenie dla wydajności i przydatności danych. - Filtry typu zamówienia: Aby zawęzić analizę, warto filtrować według określonych typów zamówień magazynowych (
ordtyp). Można na przykład analizować wyłącznie zamówienia klientów do wysyłki lub przychodzące zamówienia zakupu. Odpowiedni warunek można dodać do klauzuli WHERE w wybranych częściach skryptu. - Wydajność: Skrypt łączy i scala wiele dużych tabel. Aby nie obciążać systemu, należy zaplanować pobieranie poza godzinami szczytu. W bardzo dużych środowiskach bezpieczniej jest pobierać dane w mniejszych partiach, na przykład po jednym miesiącu.
- Wymagania wstępne: Użytkownik uruchamiający skrypt musi mieć uprawnienia do odczytu wszystkich tabel użytych w zapytaniu, w tym
ord_hdr,ord_dtl,invmov,pckwrk_dtl,asnhdritrn_log. Musi też mieć uprawnienia do wykonywania poleceń MOCA.
Przykładowe zapytanie 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]'
] Kroki
- Nawiązanie połączenia z bazą danych: Uzyskaj dane dostępowe tylko do odczytu oraz informacje o połączeniu z bazą Blue Yonder WMS, takie jak adres serwera, nazwa bazy i port. Zwykle jest to baza Oracle lub SQL Server. Połącz się z nią za pomocą standardowego klienta SQL, na przykład DBeaver, Oracle SQL Developer lub SQL Server Management Studio.
- Identyfikacja podstawowych tabel WMS: Dostarczone zapytanie korzysta ze standardowych tabel Blue Yonder WMS, takich jak
ord(zamówienia),pckwrk(prace kompletacyjne),wrkque(kolejka prac),invmov(przesunięcia zapasów) ilodhdr(nagłówek ładunku). Sprawdź nazwy tabel i strukturę kolumn w słowniku danych systemu, ponieważ mogły zostać wprowadzone modyfikacje. - Sprawdzenie i parametryzacja zapytania SQL: Skopiuj dostarczony skrypt SQL do klienta SQL. Znajdź zmienne zastępcze w wyrażeniu tabelarycznym
BaseOrdersna początku skryptu. - Ustawienie zakresu dat: Zmień warunki
adddte >= 'YYYY-MM-DD'iadddte < 'YYYY-MM-DD', aby określić okres pobierania danych. Do wstępnej analizy zaleca się zakres od 3 do 6 miesięcy. - Zastosowanie filtrów właściwych dla systemu: Zmień filtr
wh_id = '[Your_Warehouse_ID]', aby ograniczyć pobieranie do konkretnego magazynu. W razie potrzeby dodaj lub zmień inne filtry, na przykładclient_idw środowiskach obsługujących wielu klientów. - Uruchomienie skryptu pobierającego dane: Wykonaj cały skrypt SQL. Zapytanie łączy zdarzenia z wielu tabel w jeden dziennik zdarzeń. Czas wykonania zależy od zakresu dat i ilości danych.
- Weryfikacja wstępnych wyników: Po zakończeniu zapytania sprawdź wyniki. Upewnij się, że kolumny
WarehouseOrder,ActivityNameiEventStartTimezawierają oczekiwane dane. Wierszy powinno być znacznie więcej niż unikalnych zamówień magazynowych. - Eksport dziennika zdarzeń: Wyeksportuj wyniki zapytania do pliku CSV. Ustaw kodowanie UTF-8, aby uniknąć problemów z kodowaniem znaków podczas przesyłania.
- Przygotowanie pliku do przesłania: Sprawdź, czy nagłówki kolumn w wyeksportowanym pliku CSV odpowiadają wymaganym atrybutom, na przykład
WarehouseOrder,ActivityNameiEventStartTime. Plik jest gotowy do przesłania do oprogramowania process mining.
Konfiguracja
- Wymagania wstępne: Potrzebny jest dostęp SQL tylko do odczytu do bazy Blue Yonder WMS. Przydatna będzie znajomość konfiguracji WMS i modelu danych używanych w organizacji.
- Połączenie z bazą danych: Ta metoda wymaga bezpośredniego połączenia z bazą. Przed rozpoczęciem należy skonfigurować wymagane reguły zapory sieciowej i uprawnienia dostępu do sieci.
- Filtrowanie według zakresu dat: W klauzuli
WHEREzapytania należy określić zakres dat, aby kontrolować ilość pobieranych danych. Zwykle okres od 3 do 6 miesięcy wystarcza do przeprowadzenia miarodajnej analizy i nie powoduje nadmiernego obciążenia bazy. - Filtrowanie według magazynu i klienta: W środowiskach z wieloma magazynami lub klientami należy zawsze filtrować dane według konkretnego
wh_id(identyfikatora magazynu) iclient_id(identyfikatora klienta). Dzięki temu analiza będzie odpowiednio zawężona, a zbiór danych łatwiejszy do obsłużenia. - Wydajność: Uruchomienie zapytania w produkcyjnej bazie danych może wpłynąć na wydajność systemu. Zaleca się wykonywanie go poza godzinami szczytu, a najlepiej w dedykowanej bazie raportowej lub jej replice, jeśli jest dostępna.
- Modyfikacje systemu: Zapytanie korzysta ze standardowych nazw tabel i kolumn. W zależności od modyfikacji lub wersji używanej instancji Blue Yonder WMS może być konieczna ich zmiana. W razie wątpliwości warto skonsultować się z administratorem WMS lub sprawdzić słownik danych.
Przykładowe zapytanie 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 Gotowi do rozpoczęcia?
Wykorzystaj ten szablon, aby rozpocząć analizę process mining i znaleźć sposoby na usprawnienie pracy magazynu. Już dziś zacznij optymalizować przepływ materiałów.
Zwiększ efektywność Blue Yonder WMS już dziś
Wskaż wąskie gardła, ogranicz błędy kompletacji i osiągnij 99,5% dokładności stanów magazynowych.
Bez podawania danych karty płatniczej. 14-dniowy okres próbny.