Nie zaczynałem od aplikacji. Zacząłem od pytania, czego nie można przeoczyć w transporcie.

Transport to znacznie więcej niż samochód, kierowca i adres dostawy.

Kiedy patrzy się na pojedyncze zlecenie z boku, wszystko może wydawać się proste: odebrać towar i dostarczyć go w określone miejsce. W praktyce za każdym takim zadaniem stoją zapytanie, kalkulacja, negocjacje, dokumenty, czas kierowcy, dobór właściwego pojazdu, kontrola techniczna, monitoring, rozliczenie oraz odpowiedzialność za ewentualne odstępstwa.

Wiedziałem, że sama lista tych czynności nie wystarczy. Chciałem pokazać ich zależności. Jeżeli zmienia się godzina załadunku, może zmienić się legalny plan pracy kierowcy. Jeżeli zmienia się rodzaj ładunku, może być potrzebna inna naczepa, dokumentacja i procedura bezpieczeństwa.

Pierwszym krokiem było rozpisanie procesu od A do Z.

Zacząłem od zapytania ofertowego. Jakie informacje naprawdę trzeba zebrać? Trasa, masa, typ ładunku, okna czasowe, temperatura, wymagania specjalne, waluta i termin płatności. Dopiero potem można uczciwie ocenić wykonalność i policzyć cenę.

Proces rozwinął się do 25 etapów. Każdy otrzymał właściciela, wymagane dane, warunek przejścia i dowód wykonania. Dzięki temu status nie jest tylko kolorową etykietą. Oznacza, że określone czynności zostały rzeczywiście wykonane.

Najważniejsza zasada projektu brzmi: jeśli czynność ma znaczenie dla bezpieczeństwa, zgodności albo rozliczenia, musi pozostawić sprawdzalny ślad.

Czas pracy kierowcy nie mógł być dodatkiem dopisanym na końcu.

Planowanie trasy bez uwzględnienia jazdy, innej pracy, przerw i odpoczynku jest tylko planowaniem życzeniowym. Dlatego kontrola czasu kierowcy stała się jedną z głównych bramek procesu. System ma odpowiedzieć nie tylko, czy kierowca jest dostępny, ale czy może legalnie i bezpiecznie wykonać dane zlecenie.

Uwzględniłem też procedurę pobierania danych: maksymalnie co 28 dni z karty kierowcy i co 90 dni z jednostki pojazdowej. Sam odczyt to dopiero początek. Dane trzeba sprawdzić, przeanalizować, wyjaśnić naruszenia, zabezpieczyć i przypisać do osoby, która wykonała kontrolę.

Flota została podzielona według rzeczywistego sposobu pracy.

Model transportu ciężkiego obejmuje 20 zestawów: 12 chłodni, 4 cysterny oraz 4 plandeki. Każdy typ ma wspólne podstawy, serwis, ubezpieczenie, leasing, tachograf i dokumenty, ale również własne ryzyka. Chłodnia wymaga kontroli temperatury i ATP. Cysterna wymaga historii ładunków, mycia i w odpowiednich przypadkach ADR oraz TDT. Plandeka wymaga szczególnej kontroli masy i zabezpieczenia towaru.

Osobno zachowałem wcześniejszy moduł 18 pojazdów: samochody osobowe wynajmowane pod taxi, samochód właściciela oraz trzy kontenery z windami. Nie chciałem mieszać dwóch różnych modeli biznesowych, ale zależało mi na wspólnym podejściu do kosztów, terminów, szkód i cyklu życia pojazdu.

Stawka za kilometr powinna wyjaśniać cenę, a nie ją zgadywać.

W kalkulatorze rozdzieliłem kilometry płatne od wszystkich kilometrów rzeczywiście przejechanych. Paliwo, myto, praca kierowcy, leasing, serwis, puste przejazdy, baza operacyjna i ryzyko wpływają na koszt zlecenia niezależnie od tego, czy klient płaci za cały dystans.

Model pokazuje koszt na kilometr całkowity oraz minimalną stawkę sprzedaży na kilometr płatny. Dzięki temu widać, co dzieje się z marżą, gdy rośnie udział pustego przebiegu albo zmienia się paliwo, myto czy kurs EUR.

Dokumenty zostały potraktowane jak część procesu, a nie archiwum po fakcie.

CKZ, zezwolenie, licencja wspólnotowa, wypisy, prawo jazdy, kod 95, karta kierowcy, tachograf, CMR, ATP, ADR, SENT, UDT i TDT mają różne znaczenie, ale wspólną cechę: ich brak może uniemożliwić wykonanie pracy.

Dlatego dokument ma w modelu właściciela, termin, alert i listę procesów, które blokuje. W ten sposób rejestr staje się aktywnym narzędziem zarządzania zgodnością.

Arkusz, strona i aplikacja pokazują trzy różne poziomy tego samego modelu.

Excel służy do prześledzenia danych, formuł, leasingów, kosztów i KPI. Publiczna strona wyjaśnia proces osobie, która widzi projekt po raz pierwszy. Portal PWA pokazuje dziewięć perspektyw: klienta, handlu, dyspozycji, kierowcy, floty i serwisu, kadr i zgodności, finansów, najmu taxi i kontenerów oraz właściciela/administratora.

Klient widzi tylko własne zlecenie: etap procesu, ETA, ostatnią lokalizację pojazdu realizującego przewóz oraz dokument dostawy. Nie śledzi prywatnej lokalizacji kierowcy. Lokalna warstwa Python i SQLite dodaje relacje, walidacje, historię statusów oraz API. Nie udaję jednak, że statyczne portfolio jest produkcyjnym TMS-em, rzeczywiste wdrożenie wymaga logowania, serwerowych uprawnień RBAC, audytu i integracji z telematyką.

QA było częścią projektu od początku.

Sprawdziłem scenariusze, w których coś powinno zostać zatrzymane: brak czasu kierowcy, wygasły dokument, brak CMR/POD, zbyt niska marża, odchylenie temperatury albo nieważne badanie pojazdu. To właśnie takie przypadki pokazują, czy proces jest logiczny.

Powstała macierz łącząca wymaganie, pole danych, regułę i test. Dzięki temu każdą ważną deklarację można odnieść do konkretnego elementu projektu.

Co ten projekt mówi o moim sposobie pracy?

Najważniejszym rezultatem nie jest liczba wykorzystanych technologii. Jest nim umiejętność połączenia doświadczenia operacyjnego, dokumentów, kosztów, odpowiedzialności i komunikacji w jeden zrozumiały model.

TransportFlow 360 pokazuje, że potrafię rozłożyć złożony proces na części, zauważyć zależności, zbudować narzędzie i następnie sprawdzić je z perspektywy użytkownika oraz jakości.