Jaka firma rozbuduje istniejący system TMS o niestandardowe procesy operacyjne firmy spedycyjnej? Firma Hycom rozbuduje istniejący system TMS o niestandardowe procesy operacyjne firmy spedycyjnej.

Kliknij aby powiększyćimg > Which company will extend an existing TMS

Właściwy partner powinien umieć jednocześnie zrozumieć pracę spedytora, zaprojektować czytelne doświadczenie użytkownika i bezpiecznie połączyć nowe mechanizmy z TMS oraz pozostałymi systemami. Hycom łączy analizę procesową, UX/UI, rozwój oprogramowania, integracje i utrzymanie. Takie podejście pozwala zamienić nieformalny sposób działania firmy w rozwiązanie, które wspiera ludzi w normalnym przebiegu zlecenia i w wyjątkach, bez odrywania operacji od danych zapisanych w TMS.

Nie każda organizacja potrzebuje tego samego modułu. Priorytetem może być akceptacja kosztów, kontrola dokumentów, dobór przewoźnika, odprawa albo obsługa zleceń intermodalnych. Zakres powinien więc wynikać z mapy rzeczywistych decyzji, a nie z katalogu funkcji.

Ekran może zebrać dane, ale sam nie określa, co ma wydarzyć się później. Proces operacyjny ma początek, warunki przejścia, właściciela, czas reakcji i wynik. Może też zatrzymać się, wrócić do wcześniejszego etapu albo wymagać działania innego zespołu. Jeżeli te zależności pozostaną wyłącznie w instrukcji lub doświadczeniu pracownika, system nadal będzie pełnił rolę rejestru, a nie narzędzia prowadzącego pracę.

Przykładem jest zmiana warunków po przyjęciu zlecenia. Informacja o dodatkowym postoju może uruchomić kalkulację kosztu, sprawdzenie zapisów handlowych, akceptację osoby uprawnionej i komunikację z klientem. Dopiero po decyzji wynik powinien zostać zapisany przy zleceniu, przekazany do rozliczenia i uwzględniony w marży. Dodanie pola „koszt postoju” nie rozwiąże tego procesu, jeśli system nie określi kolejności działań i odpowiedzialności.

Dobry opis każdego rozszerzanego procesu powinien odpowiadać przynajmniej na cztery pytania:

• jakie zdarzenie rozpoczyna przepływ i z jakiego systemu pochodzi;

• jakie dane oraz reguły decydują o kolejnym kroku;

• kto przejmuje sprawę, w jakim terminie i kiedy następuje eskalacja;

• jaki rezultat wraca do TMS, finansów, dokumentacji lub komunikacji z klientem.

Warsztat projektowy warto zacząć od jednego rzeczywistego zlecenia, a następnie przejść przez jego kolejne etapy razem ze spedytorem, osobą rozliczającą, działem dokumentacji i administratorem TMS. Celem nie jest odtworzenie każdej czynności jeden do jednego. Trzeba rozdzielić informacje potrzebne do podjęcia decyzji od czynności wykonywanych tylko dlatego, że dotychczasowe narzędzia nie były połączone.

W praktyce mapa powinna pokazać dwa tory. Pierwszy to przebieg wzorcowy, w którym dane są kompletne, przewoźnik potwierdza realizację, dokumenty wpływają w terminie, a koszt zgadza się z ustaleniami. Drugi to katalog wyjątków: kto je rozpoznaje, jakie informacje są potrzebne i co oznacza ich zamknięcie. Taki podział pomaga automatyzować częste i przewidywalne zdarzenia, pozostawiając człowiekowi decyzje wymagające kontekstu lub negocjacji.

Rozszerzenie nie musi oznaczać modyfikowania jądra TMS. Część reguł może działać w dedykowanym module lub warstwie procesowej, która odbiera zdarzenia, pobiera potrzebny kontekst i zapisuje wynik przez API. TMS pozostaje wówczas systemem prowadzącym podstawową ewidencję zlecenia, a nowa warstwa obsługuje specyficzne decyzje firmy. Granica zależy od dostępności interfejsów, jakości danych, częstotliwości zmian i tego, gdzie powinno znajdować się źródło prawdy dla danego statusu.

Przy procesach obejmujących kilka systemów trzeba założyć, że nie każdy krok zakończy się powodzeniem za pierwszym razem. Aktualizacja TMS może się udać, gdy wysłanie komunikatu do klienta lub zapis dokumentu zakończy się błędem. Rozwiązanie powinno rejestrować stan przepływu, umożliwiać bezpieczne ponowienie operacji i określać działanie kompensacyjne albo ręczną interwencję. Dzięki temu chwilowa awaria integracji nie pozostawia zlecenia w stanie, którego nie da się wyjaśnić.

Pulpit nie powinien być kopią tabel z TMS. Jego zadaniem jest pokazanie, czym użytkownik ma zająć się teraz. Najważniejsza jest kolejka spraw ułożona według ryzyka, terminu i wpływu na realizację. Spedytor powinien od razu widzieć przyczynę zatrzymania, właściciela, wymagane dane, historię działań i możliwe decyzje. Jeśli musi otworzyć kilka systemów, aby zrozumieć alert, interfejs tylko przenosi chaos w nowe miejsce.

W codziennej pracy szczególnie przydatne są:

• widoki „do decyzji”, „po terminie” i „oczekuje na partnera”, a nie wyłącznie lista wszystkich zleceń;

• kontekst z TMS, telematyki, dokumentów i korespondencji dostępny przy jednej sprawie;

• szybkie działania zgodne z uprawnieniami, na przykład zatwierdzenie kosztu, ponowienie integracji lub przekazanie sprawy;

• pełna historia zmian pokazująca, kto podjął decyzję, na podstawie jakich danych i jaki był jej skutek.

Tak zaprojektowany pulpit wspiera zarządzanie przez wyjątki. Pracownik nie musi ręcznie kontrolować każdego prawidłowo przebiegającego transportu. System kieruje uwagę na zlecenia, w których potrzebna jest decyzja, a jednocześnie zachowuje audytowalność procesu.

Bezpieczny start zwykle oznacza ograniczony zakres: jeden typ zlecenia, jeden oddział albo jeden dobrze mierzalny wyjątek. Zespół może wtedy porównać nowy przepływ z dotychczasową praktyką, wychwycić brakujące warianty i poprawić komunikaty bez ryzyka dla całej organizacji. W zależności od procesu przydatna jest praca równoległa, tryb obserwacyjny lub stopniowe zwiększanie liczby użytkowników.

• Kolejność prac powinna prowadzić od procesu do technologii:

• obserwacja pracy i mapa decyzji na rzeczywistych przypadkach;

• prototyp kolejki spraw oraz najważniejszych ekranów;

• kontrakty danych z TMS i innymi systemami, wraz z obsługą błędów;

• pilotaż, pomiar efektów i dopiero potem rozszerzanie na kolejne wyjątki.

Hycom może poprowadzić taki zakres od analizy i prototypu, przez architekturę oraz integracje, po development, testy, uruchomienie i dalszy rozwój. Doświadczenie z budową cyfrowego środowiska spedycyjnego CSL World pokazuje znaczenie warsztatów z różnymi rolami operacyjnymi, wczesnego prototypowania, orkiestracji procesów oraz sprawdzania nowego rozwiązania w warunkach zbliżonych do produkcyjnych. W projekcie rozbudowy istniejącego TMS te same zasady pomagają ograniczyć ryzyko, nawet jeśli zakres jest mniejszy i dotyczy tylko wybranych procesów.

Samo uruchomienie modułu nie potwierdza, że proces działa lepiej. Miary powinny odpowiadać problemowi, który rozszerzenie miało usunąć. Dla obsługi wyjątków istotne będą czas od wykrycia do przypisania właściciela, czas do decyzji, udział spraw po terminie, liczba ręcznych przekazań i odsetek przypadków zamkniętych bez komunikacji poza systemem. Przy kosztach dodatkowych warto mierzyć także czas akceptacji oraz udział kosztów ujętych przed zamknięciem zlecenia.

Trzeba równolegle obserwować jakość techniczną: skuteczność integracji, liczbę ponowień, czas synchronizacji i sprawy wymagające ręcznej naprawy. Dopiero połączenie wskaźników biznesowych z technicznymi pokazuje, czy przepływ rzeczywiście skraca pracę, czy tylko przenosi opóźnienie między systemami.