Dokument, którego nikt nie potrafi znaleźć, nie chroni firmy.

Zaczyna się niewinnie: wiadomość, telefon i plik w załączniku.

Klient pyta o transport. Handlowiec zbiera podstawowe dane. Pojawia się kalkulacja, później poprawiona oferta, potwierdzenie warunków i zlecenie. W kolejnych godzinach dochodzą dane kierowcy, pojazdu, dokumenty ładunku, CMR, potwierdzenie dostawy i faktura. Każdy element może być poprawny, a mimo to cały proces może być trudny do kontrolowania.

Wystarczy, że część ustaleń zostanie w poczcie, część w komunikatorze, a termin dokumentu w prywatnym arkuszu jednej osoby. Firma ma wtedy dane, ale nie ma wspólnego obrazu sytuacji.

Dobry obieg dokumentów nie zaczyna się od folderów. Zaczyna się od decyzji: kto, co, kiedy i na jakiej podstawie może zrobić dalej.

Dlatego projektuję obieg od procesu, nie od programu.

Najpierw rozpisuję rzeczywisty przebieg pracy: od zapytania ofertowego, przez kalkulację i akceptację, po wykonanie, dostawę oraz rozliczenie. Przy każdym etapie zadaję te same pytania: jakie dane są wymagane, kto jest właścicielem, co należy zweryfikować, jaki dokument stanowi dowód i co ma zablokować dalszą pracę.

Dopiero później dobieram narzędzie. Czasem wystarczy dobrze zaprojektowany Excel lub Google Sheets. W bardziej rozbudowanym procesie potrzebne są formularze, baza danych, role dostępu, alerty i historia zmian. Technologia ma wspierać logikę firmy, nie zmuszać firmy do obchodzenia technologii.

Status powinien coś znaczyć.

„W realizacji” brzmi dobrze, ale nie mówi, czy zaakceptowano cenę, sprawdzono dokumenty, przydzielono zasoby albo potwierdzono termin. W TransportFlow 360 rozbiłem proces na kontrolowane etapy. Każdy status ma warunek wejścia i wyjścia.

Przykład: zlecenie nie powinno trafić do planowania, jeżeli nie ma kompletu warunków handlowych. Wyjazd nie powinien zostać zatwierdzony, jeżeli kierowca nie ma dostępnego czasu albo dokument krytyczny jest nieważny. Faktura nie powinna powstać bez zweryfikowanego potwierdzenia dostawy. Dzięki temu status staje się informacją zarządczą, a nie tylko etykietą.

Każda rola widzi tyle, ile potrzebuje, i ani trochę więcej.

Klient potrzebuje własnego numeru zlecenia, aktualnego etapu, przewidywanego terminu i dokumentu dostawy. Dyspozytor pracuje na trasie, pojeździe i dostępności kierowcy. Flota pilnuje serwisu oraz dokumentów. Finanse kontrolują koszt, marżę, fakturę i płatność. Właściciel widzi całość i miejsca, w których proces się zatrzymuje.

W publicznym demo przełącznik ról pokazuje tę logikę bez prawdziwego logowania. W systemie firmowym wymagałoby to uwierzytelniania, uprawnień po stronie serwera i rejestru operacji. To ważne rozróżnienie: makieta może pokazać sposób myślenia, ale nie może udawać zabezpieczeń produkcyjnych.

Jakich narzędzi użyłem, żeby zbudować ten prosty system?

Warstwę analityczną przygotowałem w Excelu: tabele, formuły kosztowe, kalkulację stawki za kilometr, leasingi, terminy, walidację danych, KPI i dashboard. Python wykorzystałem do modelowania logiki zaplecza i automatycznej kontroli danych, SQLite do relacyjnego prototypu bazy, a JSON do uporządkowanej wymiany przykładowych rekordów oraz odpowiedzi API.

Publiczny interfejs powstał w HTML, CSS i JavaScript. Dodałem responsywny układ, przełączanie dziewięciu perspektyw użytkownika, lokalną historię demonstracyjnych statusów oraz funkcje PWA, dzięki którym portal można zainstalować na telefonie. Kod wersjonuję w Git, udostępniam przez GitHub, a statyczną prezentację publikuję na GitHub Pages.

Osobną warstwą jest QA: scenariusze testowe, walidacja reguł, przypadki negatywne, kontrola linków i spójności danych. Korzystałem również z narzędzi AI do przyspieszania analizy i pracy nad kodem, ale każdą istotną regułę, treść oraz wynik sprawdzałem względem założeń procesu. To połączenie wiedzy operacyjnej, narzędzi cyfrowych i kontroli jakości jest właściwym przedmiotem tego projektu.

Terminy dokumentów trzeba zamienić w działanie.

Sam zapis daty ważności nie rozwiązuje problemu. Potrzebny jest właściciel, odpowiednio wczesny alert, potwierdzenie odnowienia i jasna konsekwencja braku dokumentu. Jeżeli pozycja jest krytyczna dla przewozu, system powinien zatrzymać przydział albo wyjazd.

Ta sama zasada działa poza transportem: przy umowach, szkoleniach, uprawnieniach, polisach, odbiorach jakościowych i dokumentach pracowniczych. Rejestr staje się użyteczny dopiero wtedy, gdy prowadzi do zadania, decyzji i sprawdzalnego zamknięcia.

Co mogę wnieść do firmy, która chce uporządkować taki obieg?

Mogę pomóc przełożyć codzienną pracę na czytelną mapę procesu: wskazać właścicieli etapów, wymagane dane, dokumenty, punkty kontroli, wyjątki i raporty. Potrafię przygotować prototyp arkusza lub panelu, opisać role i stworzyć scenariusze testowe, które sprawdzą, czy proces działa również wtedy, gdy czegoś brakuje.

Nie chodzi o obietnicę „systemu na wszystko”. Chodzi o metodyczne uporządkowanie informacji, ograniczenie ręcznego szukania i zbudowanie jednego, zrozumiałego źródła statusu. Tak właśnie powstał TransportFlow 360, z doświadczenia operacyjnego, pytań kontrolnych, danych syntetycznych i kolejnych testów spójności.

Najlepszy obieg dokumentów jest prawie niewidoczny.

Użytkownik nie powinien zastanawiać się, gdzie zapisać plik ani komu przypomnieć o terminie. Powinien wiedzieć, co jest teraz do zrobienia, dlaczego i co będzie kolejnym krokiem. Kierownik powinien widzieć wyjątki, a nie przekopywać się przez wszystkie poprawne sprawy.

To jest dla mnie miara dobrze zaprojektowanego procesu: mniej domysłów, mniej podwójnego wpisywania, czytelna odpowiedzialność i ślad, do którego można wrócić.