Aplikacja mobilna dla kierowcy i spedytora jako jedno narzędzie

Aplikacja mobilna dla kierowcy i spedytora obsługuje dwie grupy o odmiennych warunkach pracy. Kierowca korzysta z ekranu przez kilkadziesiąt sekund i robi to w kabinie, często w rękawicy. Spedytor siedzi przy dużym monitorze i porównuje kilkanaście kursów jednocześnie. Rozwiązanie działa, jeśli obie grupy pracują na tym samym rekordzie zlecenia, ale widzą go inaczej.

Ten podział jest decyzją projektową, a nie ozdobą interfejsu. Dane zlecenia istnieją raz, w bazie systemu TMS, a każda perspektywa jest ich projekcją dopasowaną do zadania. Zmiana wprowadzona po jednej stronie pojawia się po drugiej bez ręcznego potwierdzania przez telefon.

ObszarKierowca w kabinieSpedytor w biurze
Zlecenieotrzymuje je z systemu TMS na telefontworzy je i zmienia w systemie TMS
Statuszaznacza etap, na przykład załadunek lub rozładunekwidzi status na liście i reaguje na wyjątki
Dokumentfotografuje CMR albo list przewozowyotrzymuje plik przy zleceniu i rozlicza kurs
Lokalizacjanie musi jej zgłaszać, bo robi to telefonwidzi pozycję pojazdu na mapie
Kontaktpisze lub dzwoni do dyspozytora z poziomu zleceniaodpowiada w kontekście tego samego zlecenia

Wspólny rekord i dwa widoki w bazie

Rozdzielenie perspektyw najprościej odzwierciedla warstwa danych. Poniższy przykład w T-SQL pokazuje dwa widoki nad jedną tabelą: wąski dla aplikacji kierowcy i szerszy dla dyspozytorni. Nazwy obiektów są umowne i nie oznaczają schematu konkretnego produktu.

CREATE VIEW dbo.vw_ZlecenieKierowcy AS
SELECT  ZlecenieId, NumerZlecenia, AdresZaladunku, AdresRozladunku, OknoRozladunkuOd, OknoRozladunkuDo
FROM    dbo.Zlecenie
WHERE   StatusZlecenia IN ('PRZYDZIELONE', 'W_TRASIE');
GO
CREATE VIEW dbo.vw_ZlecenieSpedytora AS
SELECT  z.*, p.Nazwa AS Przewoznik, k.Nazwisko AS Kierowca
FROM    dbo.Zlecenie AS z
JOIN    dbo.Przewoznik AS p ON p.PrzewoznikId = z.PrzewoznikId
LEFT JOIN dbo.Kierowca AS k ON k.KierowcaId = z.KierowcaId;

Widok kierowcy ogranicza zakres pól, więc telefon nie dostaje stawek ani danych rozliczeniowych, których do pracy nie potrzebuje. Dokumentację składni tego mechanizmu opisuje strona Microsoft o instrukcji CREATE VIEW.

Perspektywa kierowcy - mała liczba kroków

Linkway.TRACKER jest opisywany jako aplikacja mobilna dla kierowców transportu krajowego i międzynarodowego, dostępna na Androida i iOS. Według opisu na stronie producenta zlecenia trafiają do niej z Linkway.TMS, a kierowca potwierdza kolejne etapy i przesyła dokumenty. Szczegóły funkcji zebrano też w artykule o aplikacji linkway.TRACKER.

Zakres ekranu kierowcy warto ograniczyć do czterech czynności. Każda dodatkowa funkcja wydłuża czas obsługi i zwiększa liczbę błędnych dotknięć.

  • Odbiór zlecenia - kierowca widzi adresy oraz okna czasowe, a do tego uwagi do zlecenia, bez przełączania się między aplikacjami.
  • Potwierdzenie etapów - załadunek i rozładunek zaznaczane jednym dotknięciem, z czasem zapisanym na urządzeniu.
  • Zdjęcia dokumentów - CMR lub list przewozowy fotografowany od razu po rozładunku.
  • Kontakt z dyspozytorem - wiadomość związana ze zleceniem, a nie osobny komunikator.

Reguła: ekran kierowcy projektuje się pod jedną rękę i krótką uwagę, a wszystko, co wymaga dłuższego wpisywania, przenosi się do biura.

Wytyczne dostępności Androida zalecają, aby elementy dotykowe miały co najmniej 48 dp, co opisuje dokumentacja dostępności na developer.android.com. W kabinie, przy drganiach, ta wartość ma praktyczne znaczenie: przycisk mniejszy od kciuka w rękawicy generuje błędne statusy.

Kobieta w kurtce odblaskowej z tabletem stoi przed otwartą naczepą wypełnioną kartonami wieczorem
Urządzenie mobilne przy pojeździe - ekran używany krótko i w ruchu, dlatego liczba kroków na ekranie kierowcy ma znaczenie

Nawigacja z gabarytami pojazdu

Producent opisuje w aplikacji wbudowaną nawigację, która uwzględnia gabaryty pojazdu. Ma to znaczenie przy zestawach ciężarowych, dla których zwykła nawigacja samochodowa proponuje drogi z ograniczeniem wysokości lub nacisku na oś. Trasa wyliczona bez tych parametrów jest wprawdzie krótsza, ale kończy się objazdem albo mandatem.

Dane pojazdu, które nawigacja wykorzystuje, muszą pochodzić z jednego miejsca. Jeżeli wysokość zestawu jest wpisana w systemie TMS, a kierowca dodatkowo ustawia ją ręcznie w nawigacji, pierwsza pomyłka wystarczy, by rzeczywista trasa różniła się od planu. Aplikacja powiązana ze zleceniem ogranicza to ryzyko, bo pojazd jest przypisany do kursu po stronie biura.

Dokumenty fotografowane w kabinie

Kierowca może zrobić zdjęcie dokumentu CMR albo listu przewozowego i wysłać je do biura zaraz po rozładunku. Po stronie spedytora plik jest widoczny przy zleceniu, więc rozliczenie kursu nie czeka na dostarczenie papieru po powrocie pojazdu do bazy. Zdjęcie powinno obejmować cały dokument z podpisem i pieczęcią odbiorcy, bo zbyt ciasny kadr utrudnia późniejsze wyjaśnianie sporów.

Perspektywa spedytora - widok floty i wyjątki

Po stronie biura liczy się szerokość widoku. Spedytor potrzebuje zestawienia całej floty, a nie pojedynczego zlecenia, i wybiera z niego kursy wymagające reakcji. Pozycja pojazdu na mapie pozwala ocenić, czy kierowca zdąży do okna rozładunku, a powiadomienie o zejściu z wirtualnego korytarza trasy sygnalizuje sytuację, której plan nie przewidział.

Praca według wyjątków ogranicza liczbę kursów, które trzeba oglądać. Kurs zgodny z planem nie wymaga uwagi, dopóki jego status nie zmieni się na opóźniony. Aplikacja kierowcy dostarcza dane, a widok spedytora decyduje, które z nich wyciągnąć na wierzch. Codzienną pracę przy takim widoku opisują teksty o programie do zarządzania transportem w pracy spedytora oraz o programie TMS w codziennej pracy spedytora.

Jak spedytor korzysta ze statusów kierowcy

Status rozładunku zamyka kurs i pozwala zaplanować kolejny bez telefonu do kierowcy. Status opóźnienia uruchamia sprawdzenie okna u odbiorcy i decyzję, czy przesunąć następny załadunek. Brak statusu w spodziewanym czasie jest sygnałem samym w sobie, choć wymaga rozróżnienia, czy kierowca zapomniał go zaznaczyć, czy naprawdę jeszcze nie dojechał.

Planowanie kolejnych kursów opiera się na tych danych w module opisanym w tekście o planowaniu transportu. Im bliżej rzeczywistości są statusy, tym mniej korekt wymaga plan dnia.

Komunikacja między biurem a kierowcą

Aplikacja porządkuje komunikację przez to, że wiadomość jest przypisana do zlecenia. Historia rozmów pozostaje w jednym miejscu, więc dyspozytor przejmujący kurs po zmianie dyżuru widzi wcześniejsze ustalenia. Nie musi przeglądać skrzynki mailowej ani pytać poprzednika, co obiecano kierowcy.

Warto przy tym z góry ustalić, jakie zdarzenia wymagają reakcji i w jakim czasie. Bez takiej umowy aplikacja tylko przenosi chaos z telefonu na ekran: wiadomości przychodzą, ale nikt nie wie, kto ma na nie odpowiedzieć.

ZdarzenieKto je zgłaszaOczekiwana reakcja biura
Opóźnienie na trasiekierowca w aplikacji albo system po zejściu z trasysprawdzenie okna rozładunku i powiadomienie odbiorcy
Usterka pojazdukierowcadecyzja o pojeździe zastępczym lub przeładunku
Zmiana okna rozładunkuspedytorpotwierdzenie przez kierowcę, że zmianę widział
Brak dokumentu przy rozładunkukierowcakontakt z klientem i ustalenie sposobu potwierdzenia dostawy

Obie strony powinny znać czas, w jakim odpowiedź jest normalna. Dyspozytor odpowiadający po kilkunastu minutach na pytanie zadane podczas rozładunku uczy kierowców, że szybciej jest zadzwonić.

Wspólne dane i integracje z innymi systemami

Aplikacja mobilna nie działa samodzielnie. Linkway.TRACKER współpracuje z Linkway.TMS, a pozycje pojazdów z zewnętrznych systemów GPS zbiera platforma linkway.INTEGRATOR. Dla wymiany danych z systemami ERP i CRM producent opisuje narzędzie Linkway.BRIDGE, według którego transmisja jest szyfrowana i nie wymaga modyfikacji istniejących systemów. Więcej o tej warstwie zawiera tekst o Linkway.BRIDGE i integracji systemów w logistyce, a strona narzędzia podaje zakres opisany przez producenta.

Od strony technicznej status z telefonu jest małym komunikatem, który serwer przyjmuje, a następnie weryfikuje i zapisuje. Poniższy przykład pokazuje jego umowną postać w JSON. Najważniejszy jest osobny czas zdarzenia zapisany na urządzeniu, bo czas odebrania przez serwer zależy od zasięgu.

{
  "zlecenieId": 48211,
  "typStatusu": "ROZLADUNEK",
  "czasZdarzenia": "2026-09-30T14:32:10+02:00",
  "szerokosc": 52.4064,
  "dlugosc": 16.9252
}

Serwer nie powinien ufać samej treści komunikatu. Sprawdza, czy zlecenie należy do tego kierowcy i czy przejście statusu jest dozwolone, na przykład rozładunek nie może poprzedzać załadunku. Odrzucony status wraca do aplikacji z powodem, żeby kierowca nie zakładał, że zgłoszenie zostało przyjęte.

Uprawnienia i zakres danych na telefonie

Telefon kierowcy opuszcza firmę każdego dnia, więc dane na nim traktuje się jak dane w pojeździe bez ochrony. Zakres widoczny w aplikacji powinien wynikać z roli, a nie z wygody wdrożenia. Stawka za kurs oraz marża spedycyjna nie są potrzebne kierowcy do wykonania zlecenia.

  • Zakres zlecenia - tylko kursy przypisane do danego kierowcy i tylko pola potrzebne do jazdy oraz rozładunku.
  • Uwierzytelnianie - konto imienne, a nie wspólne, żeby historia statusów wskazywała konkretną osobę.
  • Utrata urządzenia - procedura blokady konta, którą biuro uruchamia bez czekania na powrót pojazdu.
  • Przechowywanie zdjęć - dokumenty po wysłaniu nie powinny zostawać w galerii telefonu.

Widoki z pierwszej sekcji są tylko jednym z elementów. Przy przypisaniu ról sprawdza się też, czy serwer weryfikuje uprawnienia przy każdym żądaniu, zamiast polegać na tym, że aplikacja nie pokaże niedozwolonych pól.

Wdrożenie w zespole kierowców

Narzędzie odrzucone przez kierowców pozostaje nieużywane, niezależnie od swoich możliwości. Kierowca ma zwykle inne priorytety niż biuro: liczy się dla niego czas postoju i brak dodatkowych obowiązków. Aplikacja, która dokłada mu pracę bez widocznej korzyści, zostaje zastąpiona telefonem do dyspozytora.

Wdrożenie planuje się więc etapami, z osobnym celem dla każdego z nich. Ogólną kolejność prac w systemie TMS opisuje tekst o wdrożeniu Linkway.TMS w czterech etapach, a poniższa tabela dotyczy wyłącznie strony kierowców.

EtapKto uczestniczyCo sprawdzić
Przygotowanieadministrator systemu i dyspozytorczy zlecenia trafiają na telefon, a status wraca do właściwego kursu
Pilotażkilku kierowców na stałych trasachile statusów kierowcy zgłaszają w aplikacji zamiast telefonicznie
Rozszerzeniekolejne grupy kierowcówczy obsługa zgłoszeń wsparcia nie wydłuża się przy większej liczbie użytkowników
Stan ustalonywszyscy kierowcy i biuroczy telefony z pytaniem o status stały się wyjątkiem
Trzy osoby w strojach biznesowych i odblaskowej kamizelce rozmawiają, dwie z nich trzymają tablety, w tle magazyn
Zespół wdrożeniowy z użytkownikiem końcowym - na pilotażu obecny jest przedstawiciel biura i przedstawiciel kierowców

Szkolenie i wsparcie w pierwszych tygodniach

Instruktaż powinien być krótki i przeprowadzony na rzeczywistym zleceniu. Kierowca, który zobaczy swój kurs w aplikacji i sam zaznaczy status, zapamięta sekwencję lepiej niż po prezentacji. Krótki film pokazujący cały cykl kursu sprawdza się lepiej niż instrukcja tekstowa, do której kierowca nie sięgnie w trasie.

W pierwszych tygodniach potrzebna jest osoba, która rozwiąże problem od razu. Zgłoszenie obsłużone po dwóch dniach oznacza, że kierowca wrócił do poprzedniego sposobu pracy. Adopcję warto mierzyć liczbami, a nie odczuciami, na przykład udziałem statusów zgłoszonych z aplikacji.

-- przykładowe nazwy, udział statusów zgłoszonych z aplikacji w ostatnich 14 dniach
SELECT  k.Nazwisko,
        COUNT(*) AS Statusy,
        SUM(CASE WHEN s.Zrodlo = 'APLIKACJA' THEN 1 ELSE 0 END) AS ZAplikacji,
        CAST(100.0 * SUM(CASE WHEN s.Zrodlo = 'APLIKACJA' THEN 1 ELSE 0 END) / COUNT(*) AS DECIMAL(5,1)) AS UdzialProc
FROM    dbo.StatusZlecenia AS s
JOIN    dbo.Kierowca AS k ON k.KierowcaId = s.KierowcaId
WHERE   s.CzasZdarzenia >= DATEADD(DAY, -14, SYSDATETIME())
GROUP BY k.Nazwisko
ORDER BY UdzialProc;

Zestawienie sortowane rosnąco wskazuje kierowców, którzy nadal wracają do telefonu. Rozmowa z nimi zwykle ujawnia konkretną przeszkodę: brak zasięgu na stałej trasie, zbyt wolny telefon albo niejasny krok w procesie. Usunięcie przeszkody daje więcej niż przypomnienie o obowiązku.

Kto szkoli kierowców

Najlepiej sprawdza się dyspozytor lub starszy kierowca, który sam korzysta z aplikacji na co dzień. Kierowcy ufają koledze, który zna trasy i wie, gdzie zawodzi zasięg, bardziej niż prezentacji administratora systemu. Instruktor zbiera przy okazji pierwsze uwagi, na przykład o nieczytelnym ekranie w słońcu albo o kroku, który powtarza się przy każdym rozładunku.

Uwagi z pierwszych dni trafiają do osoby odpowiedzialnej za konfigurację. Poprawka wdrożona w ciągu tygodnia pokazuje kierowcom, że zgłoszenia mają skutek, i podnosi skłonność do korzystania z aplikacji bardziej niż każda kampania informacyjna.

Sprzęt kierowcy i jego utrzymanie

Terminal używany w kabinie jest narażony na zmiany temperatury oraz na drgania i zabrudzenie. Sprzęt konsumencki bywa tańszy w zakupie, ale droższy w eksploatacji przez częstsze awarie. Do tego dochodzi kwestia własności: telefon prywatny obniża koszt wdrożenia, lecz przenosi na firmę różnorodność modeli i wersji systemu.

Warto przewidzieć zapas urządzeń zastępczych. Kierowca bez sprawnego terminala wraca do meldowania się telefonicznie, a dane z jego kursu nie trafiają do systemu. Temat sprzętu w kontekście aplikacji dla kierowców omawia też tekst o aplikacji dla kierowcy na Androidzie, a koszt opóźnień w komunikacji opisuje osobny artykuł o aplikacji dla kierowcy i kosztach opóźnień.