W logistyce dane są wszędzie, tylko rzadko w jednym miejscu. System transportowy wie, kiedy wyjechała ciężarówka, magazyn zna stan kompletacji, telematyka rejestruje trasę i czas pracy kierowcy, a arkusze controllingu liczą koszty po swojemu. Dyrektor operacyjny dostaje z tego cztery różne prawdy i żadnej pewności. Problemem nie jest brak danych, tylko brak jednej warstwy, która zamienia je w porównywalne KPI i konkretne decyzje.
Z naszego doświadczenia najtrudniejsza jest nie sama wizualizacja, lecz uzgodnienie, co dokładnie mierzymy i skąd bierzemy liczbę. Dlatego zaczynamy od definicji metryk i źródeł, a dopiero potem od wykresów. Kompetencje w danych i BI czerpiemy z całej Grupy RITS, w tym z zespołów Big Data i AI/Data, a doświadczenie w transport i travel tech budowaliśmy w projektach Data and Analytics. Nawet jeśli nie realizowaliśmy Twojego dokładnego scenariusza, dostarczamy ludzi, którzy takie rozwiązania projektowali i utrzymywali.
Dlaczego dane logistyczne są tak rozproszone?
Rozproszenie nie bierze się ze złej woli, tylko z historii systemów. Każde narzędzie powstało, żeby rozwiązać inny problem operacyjny, i każde trzyma dane w swoim formacie, z własną definicją „dostawy”, „zlecenia” czy „statusu”. TMS myśli zleceniami transportowymi, WMS liniami kompletacji, a telematyka zdarzeniami GPS co kilka sekund.
Do tego dochodzą dane spoza organizacji: statusy od przewoźników, awizacje od klientów, pliki EDI w kilku wariantach. W efekcie ta sama przesyłka ma inny identyfikator w trzech miejscach, a jej czas dostawy zależy od tego, kogo zapytasz. Zanim policzymy jakikolwiek wskaźnik, musimy te światy ze sobą pożenić i ustalić wspólny słownik pojęć. To mało efektowna, ale kluczowa część pracy, bo na błędnie połączonych danych każdy KPI będzie zmyślony.
Jak zbudować dashboardy KPI operacyjnych w logistyce?
Dobry dashboard nie pokazuje wszystkiego, tylko to, na co odbiorca może zareagować. Projektujemy go pod rolę: inaczej wygląda ekran dyspozytora, inaczej kokpit dyrektora operacyjnego. Zestaw KPI transportu, który sprawdza się najczęściej, to:
- terminowość (OTD/OTIF) w rozbiciu na przewoźnika, region i typ klienta,
- koszt na przesyłkę i na kilometr z podziałem na trasy własne i podwykonawców,
- wykorzystanie floty i wypełnienie pojazdu (ładowność, przebieg pusty),
- czas cyklu zamówienia od przyjęcia do dostarczenia,
- jakość danych jako osobny wskaźnik, czyli ile zdarzeń dociera na czas i kompletnie.
Każdą liczbę spinamy z możliwością wejścia głębiej, od wartości zbiorczej po pojedynczą trasę, bo bez tego KPI jest ciekawostką, a nie narzędziem decyzyjnym.
Jak policzyć realny koszt na przesyłkę?
Koszt na przesyłkę brzmi prosto, dopóki nie zacznie się go liczyć. Problem w tym, że koszty siedzą w różnych systemach i w różnej granularności: faktury przewoźników przychodzą zbiorczo, paliwo rozlicza się na pojazd, a praca magazynu na zmianę, nie na paczkę. Żeby dojść do uczciwej liczby, rozkładamy koszt całkowity na nośniki i alokujemy go z powrotem na przesyłki według sensownych kluczy, na przykład wagi, objętości albo liczby linii.
Dzięki temu widać rzeczy, których zbiorcza faktura nie pokazuje: że jedna relacja dowozi się strukturalnie pod straty, że drobnica zjada marżę mimo poprawnej ceny, albo że koszt pustych przebiegów przekracza oszczędności z taniego przewoźnika. Wtedy koszt przestaje być pozycją w raporcie, a staje się argumentem w negocjacjach i podstawą do zmiany tras.
Jak raportować terminowość dostaw (OTD)?
Raportowanie terminowości wydaje się banalne, tylko wszystko zależy od definicji „na czas”. Liczymy od awizacji czy od potwierdzenia? Tolerancja to okno czasowe czy konkretna minuta? Czy dostawa częściowa liczy się jako dotrzymana? Ustalenie tych reguł jest ważniejsze niż sam wykres, bo to one decydują, czy OTD na poziomie 95% to sukces, czy zamiatanie problemu pod dywan.
Kiedy reguły są jasne, raport terminowości projektujemy tak, żeby pokazywał nie tylko wynik, ale i przyczynę:
- trend OTD w czasie z rozbiciem na przewoźnika i oddział,
- powody opóźnień kategoryzowane spójnie, nie opisowo,
- przesyłki zagrożone sygnalizowane, zanim termin minie, a nie po fakcie.
Ten ostatni element przesuwa raportowanie z trybu rozliczeniowego w operacyjny, bo pozwala zareagować, póki jeszcze można coś uratować.
Jak prognozować przepustowość i wykorzystanie floty?
Kiedy historyczne dane są już uporządkowane, naturalnym krokiem jest patrzenie w przód. Budujemy modele prognozujące wolumen przesyłek i obciążenie magazynu w ujęciu tygodniowym i sezonowym, żeby planować obsadę zmian i podstawienia pojazdów, zanim pojawi się wąskie gardło. Nie chodzi o wróżenie z fusów, tylko o oparcie decyzji o przepustowości na wzorcach, które i tak powtarzają się co roku.
Warstwę prognostyczną traktujemy jako rozszerzenie analityki, nie osobny świat. Dopiero gdy fundament z czystych danych i uzgodnionych metryk działa, dokładamy modele predykcyjne, a tam gdzie ma to sens, komponent AI. Tę kompetencję w Grupie RITS realnie mamy, więc uruchamiamy ją wtedy, gdy przynosi wartość, a nie dlatego, że dobrze brzmi.
Jak zaprojektować hurtownię danych i warstwę metryk?
Pod każdym dashboardem musi stać powtarzalny fundament, inaczej liczby rozjadą się przy pierwszej zmianie w źródle. Budujemy go jako hurtownię danych z jawną warstwą metryk, zasilaną pipeline’ami, które regularnie zaciągają dane z systemów operacyjnych:
- pipeline’y z TMS, WMS i telematyki, odporne na braki i duplikaty zdarzeń,
- warstwa modelowania, w której surowe tabele zamieniamy w spójne encje (przesyłka, trasa, zlecenie),
- centralna definicja metryk, żeby OTD czy koszt na przesyłkę liczyły się identycznie w każdym raporcie,
- kontrola jakości danych wbudowana w pipeline, z alertem, gdy źródło przestaje dowozić komplet.
Taka architektura sprawia, że nowy wskaźnik dokłada się w dni, a nie tygodnie, i że wszyscy w firmie patrzą na te same liczby.
Jakie kompetencje dostarczamy do analityki logistycznej?
Skład dobieramy pod konkretny etap i zakres pracy, nie „na zapas”. W projektach danych najczęściej obsadzamy role:
- inżynier danych budujący i utrzymujący pipeline’y oraz hurtownię,
- analityk BI / developer dashboardów przekładający metryki na czytelne ekrany,
- architekt danych odpowiadający za model i warstwę metryk,
- specjalista ML / data scientist tam, gdzie wchodzą prognozy i komponent AI.
Taki zespół może pracować jako wzmocnienie Twojego działu danych albo jako zespół dedykowany prowadzący temat end-to-end. Różnice między tymi modelami rozpisaliśmy w artykule o modelach współpracy IT.
Jak robimy to w RITS?
Pracujemy jako partner nearshore z Polski, który łączy kompetencje danych z doświadczeniem w projektach transportowych:
- kompetencje Data i BI czerpiemy z Grupy RITS, w tym z zespołów Big Data i AI/Data,
- w sektorze transport i travel tech realizowaliśmy prace z obszaru Data and Analytics,
- zaczynamy od definicji metryk i jakości danych, a nie od ładnego wykresu,
- kompetencje weryfikujemy przed startem, a skład skalujemy w miarę dojrzewania projektu.
Najczęściej robimy to jako dedykowane oprogramowanie analityczne budowane przez nasz zespół, a tam gdzie trzeba szybko uzupełnić braki, w modelu wzmocnienia zespołu.
Od czego zacząć budowę analityki logistycznej?
Zacznij od jednej decyzji, którą chcesz podejmować lepiej, na przykład którego przewoźnika ograniczyć albo którą relację zrenegocjować. Ta decyzja wyznacza potrzebne metryki, a metryki wyznaczają źródła i architekturę. To znacznie zdrowszy punkt startu niż próba zmierzenia wszystkiego naraz, bo daje wynik, który od razu widać w operacji.
Chcesz zamienić dane z TMS, WMS i telematyki w KPI i decyzje? Porozmawiajmy, dobierzemy zespół i architekturę pod Twoją logistykę.