Dobrze wyznaczona trasa może okazać się niewykonalna, jeśli w planie przewidziano zbyt mało czasu na wniesienie i montaż. Kolejne dostawy się opóźniają, dyspozytor zmienia ustalenia z klientami, a część zleceń może wymagać ponownego wyjazdu.
W takiej sytuacji sprawdziłbym, czy AI pomoże trafniej przewidywać czas obsługi. Test ma ograniczyć opóźnienia wynikające z błędnych założeń planu. Trzeba przy tym porównać model z prostszym rozwiązaniem i policzyć, czy dodatkowa poprawa pokryje koszt wdrożenia.
Trafniejsze planowanie czasu i obciążenia
Przy dostawach do domu klienta sam czas przejazdu opisuje tylko część pracy załogi. Dochodzi znalezienie miejsca do zatrzymania, dojście do budynku, wniesienie towaru, montaż czy odbiór zużytego urządzenia.
Jeżeli firma przeznacza na różne zlecenia jednakowy czas, część tras będzie przeciążona już w momencie zatwierdzenia. Model uczący się na historii dostaw może pomóc oszacować czas zlecenia na podstawie jego cech. Potrzebuje jednak danych, które pozwalają odróżnić zwykłe przekazanie paczki od dostawy dużego sprzętu z dodatkowymi usługami.
Trafniejsza prognoza daje podstawę do rozsądniejszego obciążenia załóg i wyznaczania godzin dostaw. Jej wartość trzeba jednak sprawdzić na gotowym planie. Mniejszy błąd przewidywania czasu nie przesądza jeszcze o spadku kosztów ani poprawie terminowości.
Punktem odniesienia powinien być plan z osobnymi czasami obsługi dla poszczególnych rodzajów usług. Dopiero przewaga nad takim wariantem uzasadnia rozważenie bardziej złożonego rozwiązania.
Szybsza reakcja na opóźnienia
Po wyjeździe samochodów swoboda planowania jest ograniczona. Towar znajduje się w konkretnych pojazdach, klienci mają przekazane godziny, a część załóg rozpoczęła już obsługę.
Przy opóźnieniu przydatne byłoby wskazanie, które kolejne dostawy są zagrożone i jakie zmiany można jeszcze wykonać. Dyspozytor mógłby wtedy ocenić propozycję korekty zamiast samodzielnie sprawdzać wiele wariantów.
Do ponownego planowania może wystarczyć klasyczny algorytm optymalizacji. AI bywa badana jako sposób wyboru fragmentów planu, którymi ten algorytm ma się zająć. W pracy „Learning to Delegate for Large-scale Vehicle Routing” takie połączenie przyspieszało obliczenia przy konkurencyjnej jakości rozwiązań. Były to testy obliczeniowe, a nie badanie reakcji na opóźnienia w jeżdżącej flocie.
W firmie sprawdziłbym czas przygotowania korekty oraz koszt jej wykonania: kontakt z klientami, zmianę instrukcji dla kierowców i ryzyko pomyłek. Zespół musi zdążyć zastosować wynik. Przed testem trzeba więc ustalić limit czasu na obliczenia i warunki pozostawienia dotychczasowego planu.
Dane muszą wyjaśniać przebieg dostawy
Status „doręczono” z godziną zamknięcia zadania nie wystarczy do oceny czasu obsługi. Potrzebne jest rozróżnienie przejazdu, oczekiwania i pracy u klienta. Opóźnione uzupełnianie statusów w aplikacji może dodatkowo zniekształcić wynik.
Warto też zapisywać przyczyny ręcznych korekt planu. Dyspozytor mógł przełożyć dostawę po rozmowie z klientem albo uwzględnić utrudnienie, którego nie odnotowano w systemie. Bez tego kontekstu trudno ocenić, czy jego decyzja była uzasadniona.
Model należy uczyć na wcześniejszych dostawach i oceniać na późniejszych, których nie użyto do jego przygotowania. W każdym porównaniu wolno wykorzystać wyłącznie informacje dostępne w chwili podejmowania decyzji. Dane poznane dopiero po zakończeniu trasy mogą zawyżyć wynik testu.
Oszczędność trzeba sprawdzić w rozliczeniu operacji
Krótsza trasa nie zawsze oznacza niższą fakturę. Jeśli firma płaci przewoźnikowi stałą stawkę za dzień pracy pojazdu, oszczędność kilku kilometrów może nie zmienić kosztu usługi. Korzyść może pojawić się dopiero wtedy, gdy uda się obsłużyć więcej zleceń tą samą flotą albo ograniczyć liczbę potrzebnych pojazdów.
Dlatego przed pilotażem trzeba określić, jak poprawa planowania ma przełożyć się na wynik firmy. Przy ocenie proponuję uwzględnić:
- koszt skutecznego doręczenia razem z kosztami ponownych prób;
- terminowość w uzgodnionych oknach dostaw;
- liczbę zleceń obsłużonych przez dostępną flotę;
- czas pracy dyspozytorów poświęcony na korekty i wyjaśnienia.
Do rachunku należy dodać koszt oprogramowania, integracji, przygotowania danych i późniejszego utrzymania rozwiązania. Uwolniony czas pracowników warto wykazać osobno od faktycznego zmniejszenia wydatków.
Porównanie musi obejmować podobny wolumen, rodzaje usług i obciążenie floty, w tym dni szczytowe. Mniej zleceń lub łatwiejsze trasy mogą poprawić wynik niezależnie od zastosowanej technologii.
Na początku system może przygotowywać propozycje w tle bez wysyłania ich kierowcom. Pozwoli to sprawdzić wykonalność rekomendacji i powody ich odrzucania przez dyspozytorów. Rzeczywisty wpływ na koszty i obsługę można ocenić dopiero w ograniczonym pilotażu po zastosowaniu zmian.
Na pierwszą próbę wybrałbym jeden powtarzalny problem, na przykład niedoszacowanie czasu dostaw z wniesieniem. Przed startem uzgodniłbym z dostawcą wynik uzasadniający dalsze wdrożenie, pełny koszt rozwiązania oraz warunki przerwania testu.