Jeśli TMS sprawnie obsługuje zlecenia, statusy i rozliczenia, słaby moduł planowania tras nie przesądza o konieczności wymiany całego systemu. Można połączyć go z zewnętrznym silnikiem optymalizacji, który przydzieli zlecenia do pojazdów, ustali kolejność punktów i wyznaczy planowane czasy. Firma ogranicza wówczas zakres modernizacji oraz pracę związaną z migracją danych i przebudową pozostałych integracji.
Warunki integracji z obecnym TMS-em
Warunkiem jest stabilność obecnego TMS-u, zapewnione wsparcie oraz możliwość pobierania zleceń i zapisywania planu. Po stronie starszego systemu może służyć do tego API albo wspierany import i eksport plików. Trzeba również sprawdzić, czy planista będzie mógł obejrzeć, poprawić i zatwierdzić trasy otrzymane z nowego silnika.
Połączenie zwykle wymaga adaptera, czyli warstwy oprogramowania tłumaczącej dane między systemami. TMS przechowuje zlecenia i statusy wykonania, a silnik oblicza propozycję planu. Oddzielenie ich modeli danych odpowiada zasadzie opisanej przez Microsoft we wzorcu anti-corruption layer. Adapter również wymaga utrzymania, monitorowania i aktualizacji.
Wynik optymalizacji powinien zawierać przydział pojazdów, kolejność punktów, planowane czasy oraz informacje o zleceniach bez przydziału. Przed zapisaniem tras trzeba sprawdzić kompletność wyniku i zgodność z ograniczeniami. Jeśli w trakcie obliczeń zmieniło się zlecenie lub dostępność pojazdu, stary wynik nie może nadpisać nowszych ustaleń. Na wypadek awarii potrzebny jest uzgodniony sposób planowania zastępczego.
Dane i koszty decydują o wyniku
Najwięcej pracy może wymagać przygotowanie danych. Do planowania potrzebne są współrzędne, okna czasowe, czasy obsługi, wielkość ładunków, pojemność pojazdów oraz dostępność i wymagane kwalifikacje kierowców. Reguły znane wyłącznie planistom trzeba zapisać i wskazać osobę odpowiedzialną za ich aktualizację.
Podobnie jest z kosztami. Jeśli firma uwzględni wyłącznie kilometry, algorytm może wybrać krótszą trasę z długimi postojami. Model powinien odzwierciedlać także koszt czasu, użycia pojazdu i transportu zewnętrznego. Trzeba przy tym rozdzielić ograniczenia obowiązkowe od preferencji. Godzina zamknięcia magazynu może być nieprzekraczalna, podczas gdy preferowana pora dostawy dopuszcza odstępstwo.
API czy pełna platforma?
Przykładem takiej usługi jest Route Optimization OptiFlow API firmy PTV. Aplikacja przekazuje dane do obliczeń, sprawdza postęp zadania i pobiera wynik. PTV oferuje również pełną platformę OptiFlow z interfejsem dla planisty oraz integracją z innymi systemami. Wariant API pozwala osadzić obliczenia w dotychczasowym środowisku pracy, o ile TMS potrafi obsłużyć otrzymany plan. Pełna platforma oznacza szerszą zmianę sposobu planowania.
Od porównania planów do pilotażu
Test rozpocząłbym od reprezentatywnej próbki zleceń obejmującej dni typowe, szczyt wolumenowy i powtarzające się wyjątki. Najpierw silnik powinien działać równolegle na kopii danych, bez wysyłania nowych tras kierowcom. Oba plany należy ocenić według tych samych stawek, ograniczeń i założeń dotyczących przejazdów. Takie porównanie pokazuje potencjał oszczędności.
Dopiero ograniczone uruchomienie, na przykład w jednym oddziale, pozwala sprawdzić wykonanie. Wtedy mierzymy rzeczywiste kilometry, godziny pracy, terminowość, liczbę niezaplanowanych zleceń, ręczne poprawki i czas pracy planistów. Wyniki trzeba odnosić do porównywalnego wolumenu transportu. Ręczne przebudowy tras mogą zniwelować oszczędność wyliczoną przez silnik.
Podobny przebieg pilotażu opisuje PTV w materiale o Distrilog. Firma przez około sześć tygodni prowadziła stare i nowe planowanie równolegle w oddziale Olen, korygując parametry na podstawie uwag pracowników. To opis pilotażu pełnej platformy, opublikowany przez dostawcę. Czas i opłacalność dołączenia samego API trzeba ustalić osobno.
Rachunek opłacalności
Opłacalność trzeba policzyć po uwzględnieniu kosztu usługi, wdrożenia i utrzymania. Poniższe kwoty są wyłącznie założeniami przykładu:
| Pozycja | Kwota |
|---|---|
| Roczny koszt transportu objętego optymalizacją (bez kosztu pracy planistów) | 10 mln zł |
| Integracja, przygotowanie danych i testy, jednorazowo | 200 tys. zł |
| Silnik i wsparcie, rocznie | 200 tys. zł |
| Utrzymanie adaptera, rocznie | 80 tys. zł |
| Uniknięte wydatki na pracę planistów, rocznie | 40 tys. zł |
Przy pełnym roku działania redukcja kosztu transportu o 5% daje 500 tys. zł oszczędności. Po dodaniu 40 tys. zł korzyści z planowania oraz odjęciu 200 tys. zł na wdrożenie i 280 tys. zł kosztów rocznych pozostaje 60 tys. zł w pierwszym roku. W kolejnych latach byłoby to 260 tys. zł rocznie, przy niezmienionych założeniach.
Aby pokryć wszystkie wymienione wydatki w pierwszym roku, koszt transportu musiałby spaść o 4,4%. Później wystarczyłoby 2,4%. To uproszczony bilans korzyści i wydatków przed podatkiem oraz kosztami finansowania. Cały koszt wdrożenia obciąża pierwszy rok; nie odejmujemy dodatkowo amortyzacji.
Odzyskany czas planistów ma wartość pieniężną wtedy, gdy pozwala ograniczyć nadgodziny lub uniknąć dodatkowego zatrudnienia. Sama mniejsza liczba godzin spędzonych przy planie nie oznacza spadku wydatków.
Kiedy jednak wymienić TMS?
Pełna wymiana TMS-u będzie rozsądniejsza, jeśli kilka podstawowych modułów wymaga przebudowy, producent zakończył wsparcie lub bezpieczna wymiana danych okazuje się zbyt kosztowna. Sygnałem ostrzegawczym jest też adapter, który zaczyna przechowywać własne kartoteki, obsługiwać zlecenia i prowadzić rozliczenia. Wtedy trzeba porównać koszt utrzymania całego zestawu z kosztem nowej platformy.
Przed rozpoczęciem pilotażu ustal minimalną oszczędność, dopuszczalną liczbę ręcznych poprawek i wymagany poziom terminowości. Zatwierdzenie wdrożenia uzależnij od wyników osiągniętych przy rzeczywistej realizacji tras.