System dostaw NutriBota obsługuje firmy cateringowe, które realizują od 30 do 2500 dostaw dziennie, flotą od kilku do kilkudziesięciu aut. Korzystają z niego firmy z Nowej Zelandii, Hongkongu, Zjednoczonych Emiratów Arabskich, Europy i Stanów Zjednoczonych, z własną dostawą, z firmą zewnętrzną albo w modelu mieszanym. Jestem współzałożycielem NutriBota. Kierowałem w nim sprzedażą oraz obsługą klienta, a mój dziewięcioosobowy zespół odpowiadał za zbieranie potrzeb od klientów, sprzedaż i wdrożenia modułu dostaw. Brałem też udział w projektowaniu i testach systemu, a część ekranów zaprojektowałem sam.
Catering dietetyczny nie jest transportem drogowym. Mechanika dostawy pozostaje jednak ta sama: dyspozytor rozdziela ładunek na auta, kierowca jedzie z listą adresów i oknami czasowymi, a firma potrzebuje dowodu, że dostawa dotarła. Ten tekst opisuje, jak taki system dostaw, czyli w praktyce TMS dla dostaw ostatniej mili, rósł etapami, co nie zadziałało przy pierwszych wdrożeniach i co z tego wynika dla firmy transportowej z flotą od 20 do 200 aut.
Punkt wyjścia: kartki, arkusz i import pliku
Zanim moduł powstał, klienci NutriBota planowali dostawy na trzy sposoby. Część pracowała na kartkach, część w Excelu, a część w zewnętrznych aplikacjach dla kurierów, do których przed każdym dniem dostaw trzeba było wgrać plik z listą adresów.
Wspólna słabość tych trzech sposobów ujawniała się po powrocie kierowcy. Efektów dostaw nie było widać ani w systemie produkcji, ani w sklepie internetowym, czyli tam, gdzie powstawało zamówienie. Informacja o tym, która dostawa dotarła, a która nie, pozostawała w drugim programie albo w telefonie dyspozytora.
Jeżeli w Twojej firmie zlecenia są w jednym programie, faktury w drugim, a pomiędzy nimi krąży arkusz uzupełniany ręcznie, mechanizm jest ten sam. Sposoby wyjścia z takiego układu opisaliśmy we wpisie Excel w zarządzaniu flotą: jak z niego wyjść.
Najpierw lista, potem dowód doręczenia
Pierwsza wersja modułu była prostą aplikacją z listą dostaw dla kierowcy. W kolejnej doszły statusy i zdjęcia. Kolejne funkcje dochodziły od najprostszych do bardziej złożonych, w tempie, w jakim klienci zaczynali z nich korzystać.
Kierowca po zalogowaniu widzi listę paczek przypisanych do siebie na dany dzień i może przełączyć ją na mapę, na której każdy adres ma pinezkę. Przy adresie widzi dystans, a jednym dotknięciem uruchamia zewnętrzną aplikację nawigacyjną. Szczegóły dostawy obejmują to, czego kierowca szuka pod budynkiem: klatkę, piętro, kod domofonu i kod bramy, godziny i miejsce dostawy, notatkę od klienta, telefon z wybieraniem jednym dotknięciem oraz kwotę do pobrania, jeżeli klient płaci gotówką.
Po dostawie kierowca zmienia status i robi zdjęcie torby pod drzwiami. Aplikacja zapisuje w systemie czas oraz lokalizację GPS, a klient dostaje powiadomienie, że zamówienie czeka pod drzwiami. Dyspozytor widzi na mapie, gdzie są kierowcy i które dostawy są zakończone. Przy reklamacji ma zdjęcie, godzinę i miejsce doręczenia.
Dostawa zaczyna się wcześniej niż trasa. Gotowe posiłki trafiają do toreb według raportu kompletacji, na etykiecie torby jest kod zamiast pełnych nazw dań, a spakowanie potwierdza się skanem kodu QR. Dzięki temu system wie, które torby są już spakowane.
Przy tej części najszybciej okazało się, czego oczekują kierowcy. Chcieli możliwie najprostszej aplikacji i nie używali funkcji zaawansowanych. W praktyce kompletność danych z trasy zależy od tego, czy kierowca korzysta z aplikacji przy każdej dostawie.
Planowanie tras: algorytm kupiony, nie pisany
Trzecim etapem było planowanie tras. Na nagraniu z kwietnia 2024 roku pokazywałem je jako nową funkcję.
Pierwsza decyzja dotyczyła tego, do czego przypisać parametry trasy. W NutriBocie obiektem w systemie jest auto, a pojazdy noszą nazwy modeli, na przykład Fiat Doblo albo Citroen Berlingo. Powód jest praktyczny: firma ma na przykład pięć aut, natomiast kierowcy zmieniają się często, ponieważ to stanowisko o dużej rotacji. Przypisanie parametrów do auta sprawia, że zmiana kierowcy nie wymaga zmian w konfiguracji.
Każdy pojazd ma w systemie koszt przejechania kilometra, koszt godziny pracy, maksymalny czas trasy, maksymalną ładowność, średni czas obsługi jednego adresu, strefę oraz punkt startu i końca trasy. Punktem startu może być baza floty, kuchnia albo inne miejsce, na przykład dom kierowcy.
Kolejność adresów dyspozytor może ułożyć ręcznie, klikając pinezki na mapie, a system policzy kilometry, czas i koszt trasy. Druga droga to automatyczne planowanie: lista adresów trafia do algorytmu Google, który zwraca gotową trasę dla każdego auta. Algorytm uwzględnia jednocześnie maksymalny czas pracy kierowcy, koszt godziny pracy i koszt kilometra ustawione osobno dla każdego auta, godziny wyjazdu i powrotu, adresy oraz strefy. Według mojego doświadczenia radzi sobie z trasami liczącymi nawet 100 punktów.
Koszt wywołań API jest spory. Zespół zdecydował się na niego, ponieważ algorytm Google dobrze rozwiązuje trasy z wieloma ograniczeniami naraz.
Po wyliczeniu trasy dyspozytor wprowadza zwykle drobne korekty. Przydział paczek do aut może poprawić na liście, przeciągając adres do kolumny innego auta, albo na mapie, gdzie paczki bez przydziału są szare, a każde auto ma swój kolor.
Wczorajsza trasa jako szablon
Catering dietetyczny sprzedaje się w abonamencie, dlatego lista adresów zmienia się z dnia na dzień w niewielkim stopniu. Nowy dzień nie wymaga więc planowania od zera. Dyspozytor zakłada trasę na podstawie poprzedniej, a kilka nowych adresów dopisuje ręcznie do istniejących tras.
Taka zmiana nie wymaga wywołania API, więc nie generuje kosztu algorytmu. Szablon trasy oszczędza zarówno czas dyspozytora, jak i koszt usługi Google. Jeżeli Twoja flota obsługuje stałe trasy dystrybucyjne, ten sam mechanizm ma zastosowanie w transporcie.
Co nie zadziałało: lokalne szczegóły
Przy pierwszych wdrożeniach na nowych rynkach problemem okazywały się szczegóły, których zabrakło na starcie. Każdy rynek miał własne:
| Rynek | Czego zabrakło na starcie |
|---|---|
| Polska | stref dostaw według kodów pocztowych |
| Katar | obsługi adresów, w których nie ma miasta |
| Kuwejt | kwot z trzema miejscami po przecinku |
| Zjednoczone Emiraty Arabskie | dostaw co drugi dzień oraz obsługi toreb chłodniczych i wkładów z lodem |
| Stany Zjednoczone | subskrypcji i nietypowych przesunięć dostaw |
Torby chłodnicze pokazują, jak jedna luka prowadzi do następnej. Najpierw zabrakło możliwości pobrania kaucji za torbę i wkłady z lodem. Po jej dodaniu okazało się, że brakuje zarządzania obiegiem toreb i wkładów, czyli informacji, ile z nich jest u klientów, a ile wróciło do firmy.
Odpowiedzią były kolejne warstwy systemu: przeładunek paczek z jednego pojazdu na inny, strefy kierowców i dostaw rysowane na mapie, później strefy według kodów pocztowych oraz obsługa formatów adresów z różnych części świata.
Czego w module brakowało
Gdy odpowiadałem za sprzedaż i wdrożenia, w module brakowało kilku funkcji: szczegółowych raportów kaucji oraz obiegu toreb i wkładów chłodniczych, czatu kierowcy z klientem oraz podglądu na żywo, gdzie jest kierowca, gdy zbliża się do klienta, w sposób znany z aplikacji Uber.
Ten system powstał do dostaw do drzwi klienta i nie obsługuje dokumentów przewozowych ani czasu pracy kierowcy według przepisów transportowych. Firma transportowa potrzebuje obu tych obszarów, dlatego wnioski z tego tekstu dotyczą mechaniki dostawy, a nie całego systemu TMS.
Co z tego wynika dla firmy z flotą 20–200 aut
Poniższe zestawienie jest moją interpretacją: przekładam mechanizmy z cateringu na transport. Prawa kolumna zawiera pytania, które możesz zadać każdemu dostawcy systemu, także nam.
| W NutriBocie | Odpowiednik w transporcie | Pytanie przed wyborem systemu |
|---|---|---|
| Obiektem w systemie jest auto | stała flota przy rotacji kierowców | Czy koszty i ograniczenia przypisuje się do pojazdu, czy do osoby? |
| Strefy rysowane na mapie i według kodów pocztowych | rejony obsługi i podział zleceń | Czy podział na strefy zmienisz sam, bez udziału dostawcy? |
| Adresy i kwoty w formatach różnych krajów | transport międzynarodowy | Czy system przyjmie adres i kwotę w formacie kraju, do którego jeździsz? |
| Kaucja i obieg toreb chłodniczych | obieg palet i opakowań zwrotnych | Czy system wie, ile palet jest u którego klienta? |
| Zdjęcie, czas i GPS przy dostawie | potwierdzenie dostawy | Czy potwierdzenie zapisuje się samo, czy ktoś przepisuje je z telefonu? |
| Wczorajsza trasa jako szablon | stałe trasy dystrybucyjne | Czy powtarzalną trasę trzeba codziennie planować od zera? |
| Najprostsza aplikacja kierowcy | kierowcy niechętni kolejnej aplikacji | Ile ekranów musi przejść kierowca, aby zamknąć dostawę? |
Gdybym budował taki system dziś, zachowałbym tę samą kolejność: od najprostszych funkcji do bardziej złożonych, w tempie, w jakim zespół zaczyna z systemu korzystać. Automatyczne planowanie tras dodałbym prawdopodobnie wcześniej. Dziś doszłyby do tego AI oraz optymalizacja tras pod kątem spalania i emisji CO2.
Jeżeli rozważasz, czy taki system kupić gotowy, czy zbudować pod własne procesy, porównanie dróg znajdziesz we wpisie Software House, SaaS czy dedykowany system dla firmy TSL. Aplikację kierowcy jako wycinek panelu dyspozytora zbudowaliśmy już w RapidLogic dla platformy Tidly: zobacz realizację.
Materiały źródłowe
Opis funkcji w tym tekście pochodzi z publicznych materiałów NutriBota, a historia rozwoju modułu z mojej pracy przy jego sprzedaży i wdrożeniach. Materiały są w języku angielskim.
- Panel dostaw NutriBot
- Aplikacja kierowcy NutriBot
- Nagranie: planowanie tras w NutriBot, kwiecień 2024
- Nagranie: logistyka i dostawy w NutriBot, styczeń 2025
- Mój wpis o planowaniu tras na blogu NutriBota
Sprawdź, od czego zacząć system dostaw w Twojej firmie
Bezpłatny audyt cyfrowy pokazuje, które kroki dostawy obsługują dziś kartki, arkusz i telefon dyspozytora, oraz od którego z nich zacząć budowę systemu.
Umów bezpłatny audyt →
