Aplikacja dla spedycji: jak przekazać przewoźnikowi zmianę okna załadunku

Nowa godzina to początek uzgodnienia

Magazyn przesuwa załadunek z rana na popołudnie. Spedytor wpisuje nową godzinę w systemie, ale przewoźnik widzi jeszcze poprzednie zlecenie. Kierowca planuje przyjazd według wiadomości otrzymanej dzień wcześniej. Kiedy zmiana dotrze do wszystkich, może okazać się, że nowy termin nie pasuje do dalszej trasy.

Aplikacja dla spedycji powinna pomóc przekazać propozycję zmiany i ustalić, czy została ona przyjęta. Potrzebny jest też plan postępowania, gdy przewoźnik nie odpowie albo zaproponuje inną godzinę. Samo zapisanie terminu nie jest jeszcze potwierdzeniem dostępności pojazdu, magazynu i osób odpowiedzialnych za załadunek.

Przykład w tym artykule jest hipotetyczny. Warunki konkretnego przewozu zależą od umów, dostępności miejsca oraz obowiązujących zasad pracy. Nie podajemy uniwersalnych okresów pracy kierowcy ani nie zakładamy, że każdą zmianę można zatwierdzić automatycznie.

Co naprawdę oznacza okno załadunku

Zacznijcie od ustalenia, co strony rozumieją przez podany przedział. Może on oznaczać czas, w którym pojazd powinien przyjechać do obiektu, okres rozpoczęcia załadunku albo zaplanowaną dostępność stanowiska. Jeśli każda osoba używa tych samych godzin w innym znaczeniu, kalendarz będzie wyglądał poprawnie, a proces nadal będzie się rozchodził.

Przy zleceniu zapiszcie miejsce, identyfikator przewozu, uzgodniony przedział oraz osobę kontaktową. Warto uwzględnić również przewidywany czas czynności, jeśli jest potrzebny do planowania stanowiska. Nie trzeba jednak udawać dokładności: szacunek powinien być rozpoznawalny jako szacunek, a zmiana warunków musi mieć właściciela.

Osobno ustalcie, czy godziny są pokazywane według strefy miejsca załadunku, czy ustawienia odbiorcy. Przy przewozach między krajami termin bez wskazania strefy może zostać odczytany inaczej przez każdą stronę. Dotyczy to również zmiany czasu. System powinien przechować jednoznaczny moment oraz pokazać użytkownikowi kontekst potrzebny do jego interpretacji.

Dokumenty przewozowe i uzgodnienie godziny są powiązane, ale odpowiadają na inne pytania. W artykule o dokumentach w aplikacji logistycznej opisujemy drogę informacji związanych z przewozem. Tutaj skupiamy się na decyzji o terminie i potwierdzeniu jego zmiany.

Przy terminie warto zapisać również miejsce, do którego należy zgłosić przyjazd, jeśli różni się ono od adresu samego obiektu. Brama, punkt obsługi i stanowisko mogą być różnymi miejscami. Gdy organizacja zmieni sposób wjazdu, osoba prowadząca zlecenie powinna wiedzieć, kto potwierdził aktualną instrukcję. Dzięki temu nowa godzina nie trafi do przewoźnika bez informacji potrzebnej do jej wykorzystania.

Kto może zaproponować zmianę

Magazyn może zgłosić niedostępność stanowiska, przewoźnik opóźnienie pojazdu, a spedytor potrzebę zmiany planu. Ustalcie, kto ma prawo wprowadzić propozycję i kto podejmuje decyzję w imieniu każdej strony. Osoba widząca zlecenie nie zawsze jest uprawniona do zmiany ustaleń.

Propozycja powinna wskazywać wcześniejszy termin, nowy przedział, przyczynę w zakresie potrzebnym do pracy oraz moment, do którego oczekiwana jest odpowiedź. Nie każda przyczyna musi trafiać do wszystkich uczestników. Magazyn może potrzebować wiedzieć, że pojazd nie przyjedzie o pierwotnej porze, bez wglądu w prywatne dane kierowcy.

Przy każdej zmianie pokażcie, czy jest robocza, wysłana do uzgodnienia, przyjęta czy odrzucona. Jeśli przewoźnik widzi jedynie nową godzinę bez stanu decyzji, może założyć, że termin został narzucony albo już zaakceptowany przez magazyn. Nazwy statusów powinny odpowiadać rzeczywistemu procesowi, a nie tylko kolejnym przyciskom w interfejsie.

Zastępstwo jest równie ważne jak główna osoba kontaktowa. Gdy dyspozytor kończy zmianę, otwarte propozycje nie powinny znikać z listy. Ustalcie, kto przejmuje sprawę, jakie informacje otrzymuje i gdzie zapisuje odpowiedź. Podobne pytania o przekazywanie pracy opisujemy w artykule o obsłudze zleceń w firmie usługowej. Szczegółowe pytania o przyjęcie odpowiedzialności i kontekst poprzedniej decyzji omawiamy w artykule o przekazaniu zadania w aplikacji.

Potwierdzenie jest osobnym zdarzeniem

Wysłanie wiadomości do przewoźnika oznacza próbę przekazania propozycji. Odczyt nie musi oznaczać, że pojazd może przyjechać o nowej porze. Uzgodnijcie, kto i w jaki sposób potwierdza termin oraz jak system zapisuje wersję propozycji, której dotyczy odpowiedź. Zgoda na poprzednią godzinę nie powinna automatycznie zatwierdzać kolejnej zmiany.

Jeśli przewoźnik proponuje inny przedział, potrzebna jest decyzja osoby, która może sprawdzić dostępność magazynu. System może przekazać propozycję dalej, ale nie powinien sam przedstawiać jej jako uzgodnionej. Każdy uczestnik powinien móc odróżnić ostatni potwierdzony termin od aktualnie negocjowanego.

W sytuacji bez odpowiedzi ustalcie moment przypomnienia i kanał zastępczy. Jeżeli sprawa wymaga telefonu, wynik rozmowy powinien trafić do tej samej historii co wcześniejsze wiadomości. W przeciwnym razie system może nadal pokazywać oczekiwanie, choć strony podjęły decyzję poza nim. O przypisaniu odpowiedzialności za brak odpowiedzi piszemy przy monitorowaniu automatyzacji.

Potwierdzenie powinno mieć znaczenie zrozumiałe dla użytkownika. Czy oznacza akceptację terminu przez przewoźnika, czy również potwierdzenie stanowiska przez magazyn? Jeżeli potrzebne są obie decyzje, pokażcie je osobno. Jedna zielona etykieta nie powinna ukrywać tego, która ze stron nadal musi odpowiedzieć.

Uzgodnijcie również sposób wycofania propozycji, która nie jest już aktualna. Jeśli magazyn zaproponuje kolejny przedział przed odpowiedzią przewoźnika, wcześniejsza wiadomość nie powinna pozostać aktywną prośbą o decyzję. Odbiorca potrzebuje zobaczyć aktualną wersję, a osoba prowadząca historię prób. Potwierdzenie musi odnosić się do konkretnej propozycji, którą strony rzeczywiście uzgodniły.

Kiedy zmienia się plan magazynu

Zmiana okna może wpłynąć na inne pojazdy i dostępność załogi. Przed przekazaniem propozycji sprawdźcie, czy stanowisko rzeczywiście można przydzielić w nowym czasie. Ustalcie także, co dzieje się z poprzednim terminem w trakcie uzgadniania. Jego zbyt wczesne zwolnienie może pozbawić przewoźnika obu możliwości, a pozostawienie blokady bez ograniczenia utrudni planowanie innych zleceń.

Dokumentacja SAP opisuje przykład integracji planowania transportu z systemem magazynowym, w której wniosek o termin i potwierdzenie stanowiska są osobnymi etapami. To funkcja konkretnego rozwiązania i konfiguracji, a nie dowód, że każde TMS oraz każdy magazyn udostępniają te same mechanizmy. Przed projektem trzeba sprawdzić dostęp oraz zakres danych dla używanych systemów.

Jeśli magazyn proponuje inny termin, zapiszcie jego stan oraz odpowiedzialność za przekazanie tej informacji przewoźnikowi. Gdy odpowiedź nie dotrze do systemu transportowego, osoba planująca powinna widzieć problem zamiast polegać na nieaktualnym widoku. O wyborze obowiązującego źródła informacji piszemy w tekście o integracji systemów.

Przy kilku stanowiskach uwzględnijcie ograniczenia konkretnego miejsca, jeśli mają znaczenie dla zlecenia. Dwa wolne pola w kalendarzu nie muszą oznaczać dwóch zamiennych stanowisk. Osoba odpowiedzialna powinna móc sprawdzić, czy dany pojazd i rodzaj ładunku pasują do uzgodnionego sposobu obsługi. Szczegóły należy ustalić z operatorem obiektu.

Przy planowaniu sprawdźcie, czy magazyn i przewoźnik używają tych samych identyfikatorów zlecenia. Numer stanowiska, numer przewozu oraz numer zamówienia mogą oznaczać różne rzeczy. Powiązanie powinno pozwolić uczestnikom rozpoznać właściwą sprawę bez kopiowania pełnych dokumentów do każdego powiadomienia. W razie braku jednoznacznego dopasowania potrzebny jest właściciel wyjaśnienia.

Zmiana po drodze i brak łączności

Kierowca może nie mieć możliwości odczytania nowej informacji w chwili jej wysłania. Uzgodnijcie, kto po stronie przewoźnika jest właściwym odbiorcą i w jaki sposób przekazuje zmianę dalej. Aplikacja nie powinna zakładać, że powiadomienie na telefon automatycznie dotarło do osoby prowadzącej pojazd ani że może ona bezpiecznie zareagować w dowolnym momencie.

Jeśli osoba planująca ma dostęp do położenia pojazdu, ustalcie źródło danych, cel ich użycia i zakres widoczności. Nie każdy użytkownik potrzebuje szczegółowej historii trasy, aby podjąć decyzję o terminie załadunku. Przed integracją sprawdźcie dostępne uprawnienia oraz aktualność informacji.

Przy przerwanej synchronizacji pokażcie ostatni potwierdzony stan i informację, że nowa propozycja czeka na przekazanie. Ponowna próba nie powinna tworzyć kilku niezależnych propozycji bez możliwości ich rozróżnienia. Problemy z potwierdzeniem oraz kolejne etapy wymiany omawiamy w artykule o API i webhookach.

Zadbajcie również o plan kontaktu poza aplikacją. Jeżeli internet lub system przewoźnika są chwilowo niedostępne, osoby odpowiedzialne powinny wiedzieć, jak uzgodnić termin oraz jak później zapisać rezultat. Alternatywny kanał ma sens tylko wtedy, gdy ktoś przejmuje odpowiedzialność za przywrócenie wspólnego stanu w systemie.

Od decyzji do dnia załadunku

Po uzgodnieniu terminu sprawdźcie, kto potrzebuje aktualizacji: magazyn, przewoźnik, osoba planująca trasę oraz zespół przygotowujący towar mogą mieć różne zadania. Każdy odbiorca powinien dostać informację potrzebną do swojej pracy. Nie ma powodu przesyłać wszystkim pełnej korespondencji, jeśli wystarczy potwierdzony termin, miejsce i kontakt do osoby prowadzącej sprawę.

Ustalcie, co dzieje się z zadaniami zależnymi od terminu. Jeśli przygotowanie dokumentów lub towaru jest powiązane z pierwotną godziną, przesunięcie może wymagać osobnej decyzji. System powinien wskazać powiązane zadania i ich właścicieli. Nie każda zmiana oznacza, że wszystkie działania można przesunąć o identyczny czas.

Historia zlecenia powinna pozwalać wyjaśnić, którą propozycję przyjęto i kiedy. Jeżeli po uzgodnieniu pojawia się nowa informacja, zachowajcie poprzednią decyzję wraz z powodem kolejnej zmiany. To pomaga przy przekazaniu sprawy między dyspozytorami i przy późniejszym wyjaśnieniu rozbieżności.

W raportach odróżniajcie liczbę wysłanych propozycji od liczby potwierdzonych terminów. Wskaźnik ma sens dopiero po uzgodnieniu znaczenia i źródła danych, co omawiamy w artykule o definicjach wskaźników dashboardu. Liczba wiadomości nie mówi jeszcze, czy przewóz został uzgodniony.

Próba z przewoźnikiem i magazynem

Przygotujcie fikcyjne zlecenie, termin i role po obu stronach. Prześledźcie propozycję zmiany, odmowę, alternatywny termin oraz potwierdzenie. Dodajcie brak odpowiedzi, nieobecność osoby prowadzącej sprawę i zmianę stanowiska po wysłaniu wiadomości. Przed każdą próbą zapiszcie oczekiwany stan i osobę, która go potwierdzi.

Sprawdźcie także, co zobaczy użytkownik po przerwaniu połączenia i ponownym otwarciu zlecenia. Jeżeli integracja z magazynem jest symulowana, wynik testu dotyczy przygotowanej symulacji. Rzeczywisty interfejs i uprawnienia trzeba sprawdzić osobno z operatorem używanego systemu.

Poproście przyszłych użytkowników o wykonanie zadania bez podpowiadania, gdzie znajduje się aktualny termin. Jeśli każda osoba wskazuje inną wersję, problem dotyczy procesu lub komunikatu, a nie pamięci uczestników. O przygotowaniu takiej próby przeczytacie w artykule o testowaniu prototypu z pracownikami.

Jeśli planujesz narzędzie dla spedycji, zobacz zakres integracji systemów i skontaktuj się z Archifutura. W briefie opisz uczestników przewozu, obecny sposób uzgadniania terminu oraz miejsce, w którym najczęściej brakuje potwierdzenia. Na początek wystarczy fikcyjny przykład zlecenia.

Po próbie zapiszcie także pytania, na które nie udało się jeszcze odpowiedzieć. Może to być zakres danych dostępnych od przewoźnika albo sposób potwierdzenia stanowiska przez operatora magazynu. Przypiszcie osobę odpowiedzialną za sprawdzenie i decyzję, od której zależy kolejny etap. Nie warto zamieniać nieznanej możliwości integracji w obietnicę gotową do wpisania do harmonogramu.