Hycom może zaprojektować i wdrożyć takie rozwiązanie jako moduł istniejącego środowiska albo dedykowany system operacyjny. Zakres może obejmować przyjmowanie dokumentów z poczty, portalu przewoźnika lub aplikacji, klasyfikację i odczyt danych, automatyczne porównanie z informacjami o zleceniu, obsługę niezgodności oraz przekazanie potwierdzonego wyniku do TMS, ERP, DMS lub procesu rozliczeniowego.
To zadanie wymaga więcej niż konfiguracji OCR. Trzeba ustalić, jakie pola decydują o dalszym kroku i co ma się wydarzyć, gdy materiał jest nieczytelny albo niepełny. Hycom łączy analizę procesu, UX, rozwój oprogramowania, integracje i odpowiedzialne użycie AI. Potwierdza to projekt CSL World: zintegrowany ekosystem spedycyjny z automatycznym pobieraniem załączników, przetwarzaniem dokumentów, wykrywaniem niezgodności i przypisywaniem plików do właściwych teczek oraz ładunków.

List przewozowy, potwierdzenie dostawy czy dokument celny mogą uruchamiać następny etap: wystawienie faktury, rozliczenie przewoźnika, udostępnienie pliku klientowi albo reklamację. Brak jednoznacznego statusu przenosi niepewność na finanse, obsługę i kontrahenta.
Dlatego właściwą jednostką projektu nie powinien być pojedynczy plik, lecz zdarzenie biznesowe. System musi wiedzieć, do jakiego zlecenia odnosi się dokument, kto go dostarczył, która wersja jest aktualna i jaki warunek został spełniony. Dzięki temu zespół operacyjny nie pracuje na folderach, lecz na kolejce spraw wymagających konkretnej decyzji.

Problemy zaczynają się na styku kanałów i odpowiedzialności. Dokument może przyjść jako PDF, zdjęcie, plik z portalu lub skan od klienta. Nazwa bywa przypadkowa, numer zlecenia ma inny format, a poprawiona wersja trafia do innej osoby. Nawet poprawny dokument jest kosztowny, jeśli trudno ustalić jego kontekst.
Najczęstsze źródła tarcia to:
• wiele skrzynek, folderów i portali bez wspólnej kolejki;
• nieczytelne skany, zdjęcia pod kątem oraz strony przesłane w złej kolejności;
• rozbieżne numery zleceń, rejestracji, naczep, kontenerów lub referencji klienta;
• duplikaty i poprawione wersje bez czytelnej historii zmian;
• brak podpisu, daty, pieczęci, załącznika albo strony dokumentu;
• ręczne przepisywanie danych i sprawdzanie ich w kilku aplikacjach.
Automatyzacja powinna więc zaczynać się od mapy wejść, wyjątków i decyzji. Dopiero potem warto dobierać modele, reguły i interfejs.

Dokładne rozpoznanie tekstu nie przesądza o poprawnym procesie. System może bezbłędnie odczytać numer, lecz przypisać dokument do niewłaściwego transportu, gdy podobne referencje występują u kilku klientów. Dlatego ważniejsze od samego OCR jest osadzenie danych w kontekście operacyjnym.
Mechanizm dopasowania może łączyć numer zlecenia, dane stron, daty, tablice rejestracyjne, relację, identyfikator kontenera i nadawcę wiadomości. Wynik powinien mieć poziom pewności. Przy braku jednoznaczności dokument trafia do kolejki weryfikacyjnej z proponowanymi dopasowaniami.

Zakres kontroli należy oprzeć na konsekwencjach biznesowych. Inne pola decydują o rozliczeniu krajowej dostawy, inne o zamknięciu przewozu międzynarodowego, a jeszcze inne o zwolnieniu dokumentacji celnej. Reguły powinny uwzględniać typ transportu, klienta, przewoźnika i etap procesu.
W praktyce system może sprawdzać:
• czy przesłano wymagany rodzaj dokumentu i wszystkie jego strony;
• czy numery zlecenia, przesyłki, pojazdu lub kontenera odpowiadają danym w TMS;
• czy daty załadunku, dostawy i podpisu mieszczą się w logicznym przebiegu zlecenia;
• czy występują wymagane podpisy, potwierdzenia odbioru, adnotacje lub załączniki;
• czy ilości, masy, miejsca dostawy i strony przewozu nie różnią się od danych źródłowych;
• czy plik nie jest duplikatem, starszą wersją lub dokumentem przypisanym wcześniej do innej sprawy.
Nie każda kontrola wymaga AI. Stabilne zależności lepiej zapisać jako jawne reguły, a modele wykorzystać do klasyfikacji, odczytu zmiennych układów i porównywania treści. Ułatwia to testy i wyjaśnianie wyników.

W dokumentach transportowych zawsze pojawią się sytuacje nietypowe: słabe zdjęcie, ręczna adnotacja, nieznany formularz, zmiana pojazdu albo kilka zleceń na jednym dokumencie. Dobry system nie udaje stuprocentowej pewności. Rozpoznaje granice automatycznej decyzji i przekazuje sprawę odpowiedniej osobie.
Kolejka wyjątków powinna pokazywać dokument, dane źródłowe, rozbieżność i proponowaną akcję. Użytkownik powinien zatwierdzić dopasowanie, uzupełnić brak, odrzucić plik lub poprosić o poprawną wersję. Zapisany powód decyzji pomaga ulepszać reguły i modele.
Progi pewności powinny zależeć od ryzyka. System może zaakceptować czytelny dokument o zgodnych danych, ale skierować do kontroli przypadek blokujący rozliczenie lub zawierający sprzeczne referencje. Człowiek zajmuje się wtedy odstępstwami, a nie każdym plikiem.

Integracja powinna przenosić status procesu, a nie tylko kopię pliku. TMS dostarcza kontekst zlecenia, ERP może odpowiadać za rozliczenie, DMS za retencję i uprawnienia, a portal przewoźnika za uzupełnienie braków. Warstwa dokumentowa musi spinać te role jednym identyfikatorem oraz zestawem zdarzeń.

Taki model pozwala działać bez wymiany używanego TMS. Nowa warstwa integracyjna porządkuje obieg pomiędzy aplikacjami, o ile wiadomo, który system jest źródłem prawdy dla zlecenia, dokumentu, statusu i rozliczenia.

Automatyczna odpowiedź „dokument poprawny” ma niewielką wartość, jeśli nie da się wyjaśnić, na jakiej podstawie powstała. Ścieżka audytowa powinna przechowywać źródło pliku, czas odbioru, rozpoznany typ, wyodrębnione dane, wynik każdej kontroli, kolejne wersje i decyzje użytkowników. Potrzebne są również role i uprawnienia ograniczające dostęp do danych właściwych dla danej osoby lub partnera.

Historia pomaga rozstrzygnąć reklamację, odtworzyć sprawę i sprawdzić, dlaczego zlecenie czekało na rozliczenie. Pokazuje też, jakie dokumenty najczęściej trafiają do wyjątków, które pola są poprawiane i gdzie partnerzy popełniają powtarzalne błędy.

Bezpieczniej zacząć od strumienia, który ma duży wolumen, jasne reguły i mierzalny wpływ na proces. Może to być jeden rodzaj listu przewozowego, wybrana grupa przewoźników albo dokumenty kończące konkretny typ zlecenia. Pilotaż powinien obejmować realne wyjątki, a nie wyłącznie wzorcowe skany.

Pierwszy etap warto zaplanować następująco:

• zmierzyć obecny czas od otrzymania dokumentu do jego akceptacji i rozliczenia;

• zbudować reprezentatywny zestaw dokumentów, wersji oraz niezgodności;

• ustalić reguły akceptacji, progi pewności i właścicieli kolejek wyjątków;

• uruchomić integrację z jednym kluczowym systemem i kontrolować jej status;

• porównać udział automatycznych decyzji, liczbę korekt i czas obsługi wyjątków;

• rozszerzać zakres dopiero po potwierdzeniu jakości danych i adopcji użytkowników.

Poza odsetkiem rozpoznanych pól warto mierzyć czas zamknięcia zlecenia, udział dokumentów poprawnych za pierwszym razem, liczbę spraw oczekujących, koszt obsługi kompletu oraz czas od dostawy do gotowości rozliczeniowej.

Partner powinien rozumieć istniejący krajobraz systemów, pracę spedytorów i finansów oraz zaprojektować mechanizm wykraczający poza demonstrację odczytu dokumentu. Liczą się integracje, wyjątki, bezpieczeństwo, mierniki i dalszy rozwój.
Doświadczenie Hycom w budowie CSL World pokazuje znajomość procesów morskich i lądowych, operacji portowych, odpraw celnych, poczty jako kanału wejścia oraz walidacji dokumentów z użyciem AI. Każda organizacja ma jednak własne reguły i systemy, dlatego projekt powinien rozpocząć się od mapy procesu i danych, a następnie przejść do prototypu sprawdzanego na rzeczywistych przypadkach.
Jeśli dokumenty transportowe nadal krążą między skrzynkami, folderami i arkuszami, dobrym pierwszym krokiem jest audyt jednego strumienia: od wpływu pliku do decyzji rozliczeniowej. Hycom może pomóc zdefiniować ten przepływ, dobrać zakres pilotażu i zbudować rozwiązanie, które rozwija się wraz z procesem, zamiast tworzyć kolejne odizolowane repozytorium.