Dwa zlecenia jadą jednym samochodem, a trzecie zostało podzielone między dwa przewozy. Jeśli system traktuje każde zlecenie jak jeden niezmienny transport, trudno przypisać postój, dokument i wynik. TMS musi obsłużyć zależności, które faktycznie występują w działalności firmy.
Warto więc przyjrzeć się modelowi danych. Sposób powiązania zamówienia, planu i wykonania jest często ważniejszy niż kolejny wykres na pulpicie.
Zlecenie klienta i przewóz nie zawsze są tym samym rekordem
Zlecenie opisuje potrzebę klienta: ładunek, miejsca, terminy i uzgodnione warunki. Plan transportu określa, jak tę potrzebę zrealizować. Możliwe są konsolidacja kilku zleceń, podział jednego ładunku albo przewóz z przeładunkiem.
System powinien zachować relację między tymi obiektami. Po otwarciu zlecenia użytkownik musi widzieć jego przewozy, a z poziomu przewozu — obsługiwane zlecenia. Nazwy ekranów mogą być różne; istotne jest, czy powiązanie pozostaje czytelne także po zmianie planu.
Dokumentacja Oracle dotycząca wymagań transportowych pokazuje jeden z modeli przejścia od zamówienia do planowanych przewozów. Nie każdy TMS ma jednak jednakowy sposób odwzorowania tych relacji.
Plan musi uwzględniać ograniczenia, nie tylko trasę
Adres i kolejność punktów to początek. Dochodzą okna czasowe, czas obsługi, rodzaj pojazdu, wymiary i masa ładunku oraz możliwości załadunku. Dobra propozycja na mapie może być niewykonalna, jeśli wybrany samochód nie podjedzie pod rampę.
Ustal, skąd system pobiera każde ograniczenie oraz kto może je zmienić. Jeżeli parametr jest nieznany, oprogramowanie powinno pokazać założenie, zamiast ukrywać je pod wynikiem optymalizacji. Sposób konfiguracji i dostępne reguły należy sprawdzić w konkretnym produkcie.
Jedna zmiana może wpłynąć na kilku klientów
Opóźnienie na pierwszym rozładunku może przesunąć następne punkty. W przewozie skonsolidowanym dotyczy to kilku zleceń. TMS powinien umożliwić ustalenie, które terminy i powiadomienia wymagają aktualizacji.
Oddziel dane planowane od rzeczywistych. Nadpisanie planowanej godziny czasem przyjazdu usuwa informację potrzebną do oceny punktualności. Zachowanie obu wartości pozwala później sprawdzić, czy opóźnienie wynikało z planu, czy z przebiegu realizacji.
Wykonanie może być zasilane telematyką, potwierdzeniem kierowcy albo ręcznym wpisem. Źródło i czas aktualizacji powinny pozostać widoczne. Szczegóły opisuje artykuł o integracji telematyki z TMS.
Podział wspólnego kosztu
Przyjmijmy umowny koszt przewozu 1800 zł i dwa zlecenia o masach 2 oraz 4 t. Proporcjonalny podział według masy da odpowiednio 600 i 1200 zł. To jedna metoda, nie automatycznie najwłaściwsza. Ładunki mogą zajmować inną powierzchnię, jechać różne odległości albo wymagać osobnego postoju.
Zasada alokacji powinna odpowiadać celowi raportu. W przykładzie Oracle koszt można dzielić według atrybutów takich jak masa, objętość czy odległość. Ustal także sposób rozliczenia kosztu przypisanego wyłącznie do jednego zlecenia.
Każdy wspólny koszt powinien zostać policzony raz i rozdzielony bez zgubienia sumy. Przy porównaniu raportu sprawdź, czy wartości na zleceniach dają łącznie koszt przewozu oraz jak system pokazuje korekty.
Próba, która sprawdza cały model
Przygotuj trzy przypadki: pojedynczy przewóz, konsolidację oraz podział zlecenia. Dla każdego wprowadź zmianę terminu, dokument i dopłatę. Następnie odtwórz historię oraz porównaj wyniki na poziomie klienta i transportu.
To ujawnia różnicę między zbiorem osobnych modułów a powiązanym systemem. Jeśli koszt widać tylko na jednej liście, dokument trafia do niewłaściwego etapu lub raport powiela przychód, najpierw wyjaśnij reguły danych. Dopiero później oceniaj wygląd zestawienia. Kontrolę rozliczenia rozwija poradnik koszty i wynik zlecenia w TMS.
