Integracja systemu transportowego z pozostałymi systemami firmy: po co, jakimi kanałami i co się psuje bez niej

Transport przestaje być osobną wyspą dopiero wtedy, gdy zlecenie, dostawa, ważenie i faktura opisują to samo zdarzenie tymi samymi danymi. Integracja systemu transportowego z pozostałymi systemami firmy nie jest zadaniem kosmetycznym: decyduje o tym, czy dane z trasy trafiają do rozliczeń bez przepisywania ręcznego i bez różnic w raportach.

Po co jest integracja systemu transportowego z pozostałymi systemami firmy

Integracja systemu transportowego z pozostałymi systemami firmy ma jeden nadrzędny cel: jedno zdarzenie w świecie fizycznym ma zostawić jeden ślad w danych. Kierowca potwierdza dostawę raz, a potwierdzenie samo zasila magazyn, rozliczenie kierowcy i fakturę dla klienta. Bez tego to samo zdarzenie jest wprowadzane trzy razy, przez trzy osoby, z trzema możliwościami pomyłki.

W firmie produkcyjnej z własnym transportem granica między systemami biegnie zazwyczaj tam, gdzie kończy się rampa. ERP wie, co zostało sprzedane i zafakturowane. System magazynowy wie, co i skąd zostało wydane. System transportowy wie, kto to wiózł, o której dojechał, ile przejechał kilometrów i ile zatankował. Dopóki te trzy obrazy nie są ze sobą powiązane, nikt w firmie nie zna rzeczywistego kosztu obsługi pojedynczego klienta.

Druga przesłanka jest czasowa. ERP pracuje w rytmie dnia i miesiąca księgowego, transport pracuje w rytmie godziny. Jeśli informacja o opóźnieniu dociera do biura obsługi klienta dopiero z poranną paczką danych, to dział handlowy dowiaduje się o problemie po kliencie. Integracja nie przyspiesza ciężarówki, ale przyspiesza decyzję o tym, komu i kiedy zadzwonić.

Jakie dane przepływają w integracji systemu transportowego z ERP, magazynem i księgowością

Integracja systemu transportowego z ERP, magazynem i księgowością sprowadza się do kilkunastu obiektów danych, nie do setek. Warto je spisać przed wyborem technologii, bo zakres wymiany, nie protokół, określa trudność projektu. Zwykle są to: kontrahenci i adresy, zlecenia, pozycje towarowe, potwierdzenia wykonania, pomiary oraz dokumenty rozliczeniowe.

Zakres integracji zależy też od tego, jak szeroki jest sam system transportowy: im więcej procesów obsługuje on sam, tym mniej interfejsów trzeba budować na zewnątrz. W SOTiPM producent wymienia obok planowania przewozów także obsługę pracowników mobilnych, flotę, place manewrowe, obieg dokumentów i fakturowanie. Strona integracyjna tego dostawcy porządkuje punkty styku w ośmiu kategoriach, a każda z nich odpowiada innemu typowi źródła danych:

• systemy ERP (wskazane są m.in. SAP i Sage),

• BDO,

• systemy GPS do lokalizacji pojazdów,

• terminale wagowe,

• karty paliwowe,

• kontrola tankowania w pojazdach,

• dostawcy map i optymalizacji,

• bramki powiadomień SMS.

Kanały integracji systemu transportowego z innymi aplikacjami: EDI, API i wymiana plikowa

Integracja systemu transportowego z innymi aplikacjami odbywa się dziś trzema kanałami, które różnią się nie jakością, lecz zastosowaniem. Wymiana plikowa obsługuje duże porcje danych raz na dobę. EDI obsługuje ustandaryzowane dokumenty handlowe między firmami. Interfejsy programistyczne obsługują zdarzenia, które muszą dotrzeć natychmiast.

EDI to elektroniczna wymiana dokumentów handlowych w uzgodnionym formacie, bez udziału człowieka po obu stronach. W Europie najbardziej rozpowszechnionym zestawem komunikatów jest UN/EDIFACT, w którym awizo dostawy ma postać komunikatu DESADV, a faktura komunikatu INVOIC. Dla firmy dostarczającej do dużych sieci handlowych EDI nie jest wyborem technologicznym, ale warunkiem współpracy narzuconym przez odbiorcę.

API REST działa inaczej: zamiast paczki dokumentów przesyła pojedyncze wywołania na żądanie, więc nadaje się do rzeczy, które dzieją się w ciągu minut. Status zlecenia, pozycja pojazdu, potwierdzenie rozładunku, zapytanie o dostępność okna czasowego. W praktyce w jednej firmie współistnieją wszystkie trzy kanały i to jest stan normalny, a nie oznaka bałaganu. Błędem jest natomiast używanie kanału wsadowego do danych operacyjnych: paczka plików wysyłana o 23:00 nigdy nie obsłuży awizacji na następny poranek.

Dane podstawowe jako warunek wstępny integracji systemu transportowego z resztą architektury IT

Integracja systemu transportowego z resztą architektury IT rozbija się najczęściej nie o protokół, lecz o dane podstawowe, określane też jako master data. Jeśli ten sam odbiorca istnieje w ERP pod jednym indeksem, a w systemie transportowym pod innym, to żaden interfejs tego nie naprawi. Przepisze tylko niezgodność szybciej i w większej skali.

Typowy objaw tego problemu jest prozaiczny: dwie kartoteki kontrahentów prowadzone niezależnie przez dwa działy. Handel dopisuje klientów w ERP, dyspozytornia dopisuje punkty dostaw u siebie, bo tam są potrzebne godziny przyjęć i ograniczenia tonażowe. Po dwóch latach różnica sięga kilkuset rekordów i nikt nie wie, która wersja jest prawdziwa. Dlatego pierwszym rozstrzygnięciem w projekcie integracyjnym jest wskazanie systemu właściciela dla każdej kategorii danych oraz zgoda, że pozostałe systemy tę daną tylko odczytują.

Osobnym warunkiem jest wspólny język opisu przewożonego towaru. Standardy GS1 dostarczają go w postaci etykiety logistycznej, której kluczowym elementem jest kod SSCC, osiemnastocyfrowy identyfikator jednostki logistycznej. Jeden skan takiej etykiety pozwala magazynowi, przewoźnikowi i odbiorcy mówić o tej samej palecie, zamiast o numerze wewnętrznym zrozumiałym tylko w jednym zakładzie.

Punkt-punkt czy szyna danych: architektura integracji systemu transportowego z systemami firmy

Architektura integracji systemu transportowego z systemami firmy ma dwa warianty i wybór między nimi zależy od liczby systemów, nie od ambicji działu IT. Integracja punkt-punkt łączy dwie aplikacje bezpośrednio. Szyna danych wprowadza warstwę pośrednią, do której każdy system podłącza się raz.

Arytmetyka jest tu nieubłagana. Przy pięciu systemach łączonych bezpośrednio każdy z każdym daje dziesięć interfejsów do utrzymania, przy ośmiu już dwadzieścia osiem. Każdy z nich ma własny format, własny harmonogram i własnego autora, który zwykle zmienił pracodawcę. Szyna danych ma wyższy koszt wejścia i wymaga kompetencji, których średnia firma produkcyjna często nie ma na pokładzie, ale przy rozbudowanym krajobrazie aplikacji zwraca się na utrzymaniu.

Dla większości firm z własnym transportem rozsądny jest wariant mieszany: bezpośrednie połączenie z ERP, bo to jedna relacja o dużym natężeniu, oraz warstwa pośrednia dla urządzeń i usług zewnętrznych, których jest wiele i które się zmieniają. Dobrze zaprojektowana integracja systemu transportowego z ERP i WMS zaczyna się od decyzji o tym podziale, a nie od wyboru narzędzia. Osobno należy zaplanować obsługę błędów: co się dzieje z komunikatem, który nie przeszedł walidacji, kto to widzi i w jakim czasie.

Dokumenty i urządzenia mobilne w integracji systemu transportowego z zapleczem biurowym

Integracja systemu transportowego z zapleczem biurowym domyka się na dokumencie przewozowym i na urządzeniu w ręku kierowcy. Dopóki potwierdzenie dostawy wraca do biura na papierze, cykl rozliczeniowy jest zakładnikiem obiegu teczek, a nie wydajności systemów. Ostatni odcinek drogi danych decyduje więc o tym, kiedy można wystawić fakturę.

W transporcie międzynarodowym odpowiedzią na ten problem jest e-CMR, elektroniczna postać listu przewozowego CMR, oparta na protokole dodatkowym do konwencji CMR. Jej wartość polega nie na braku papieru, lecz na tym, że dane z listu stają się rekordem, który można przekazać interfejsem do systemu rozliczeniowego od razu po rozładunku. W przewozach krajowych podobną rolę odgrywają potwierdzenia zbierane w aplikacji mobilnej razem z podpisem i zdjęciem.

Po stronie urządzeń rolę kanału pełni identyfikacja automatyczna. Znacznik RFID albo kod kreskowy, jednowymiarowy lub dwuwymiarowy, przypisany do nośnika, partii produkcyjnej albo lokalizacji w hali, zamienia czynność fizyczną w rekord bez udziału klawiatury. Ten kanał jest jednak tak sprawny, jak warstwa radiowa pod nim. Zasięg sieci w hali zależy od tego, z czego zbudowane są ściany, jak wysokie i jak gęste są regały oraz ile towaru akurat stoi na półkach. Przy pełnym magazynie skanowanie potrafi działać wyłącznie w głównej alei, a wtedy integracja jest sprawna tylko na papierze.

Integracja systemu transportowego z systemami firmy: pytania przed uruchomieniem projektu

Od czego zależy czas uruchomienia pierwszego interfejsu? Przede wszystkim od stanu danych podstawowych i od tego, czy ERP ma udokumentowany interfejs. Projekt, w którym najpierw trzeba uporządkować kartotekę kontrahentów, trwa dłużej niż ten, w którym wystarczy ją zmapować. Harmonogram warto liczyć od momentu, w którym dostępna jest dokumentacja obu stron.

Jakie role trzeba obsadzić w organizacji, żeby projekt nie stanął? Trzy. Właściciel procesu transportowego, osoba faktycznie znająca konfigurację ERP i rozjemca sporów o dane, umocowany na tyle wysoko, żeby jego decyzja była ostateczna. Pominięcie trzeciej roli zatrzymuje projekt najczęściej, bo żaden dział nie oddaje swojej kartoteki dobrowolnie.

Co zrobić z istniejącymi arkuszami i własnymi narzędziami? Nie usuwać ich w dniu startu. Arkusz, w którym dyspozytornia pracuje od lat, zawiera wiedzę o wyjątkach, której nie ma w żadnej dokumentacji. Rozsądne jest utrzymanie go w trybie równoległym do pierwszego pełnego okresu rozliczeniowego i dopiero potem wygaszenie.

Jakie są główne ryzyka takiego wdrożenia? Trzy: niezgodne dane podstawowe, brak właściciela błędów integracyjnych oraz założenie, że interfejs zastąpi uzgodnienie procesu. Interfejs przenosi dane, ale nie rozstrzyga, czy godzina dostawy liczy się od wjazdu na plac czy od podstawienia pod rampę. To trzeba ustalić wcześniej.

Co zmienia się, gdy zakładów jest kilka i są rozproszone? Każda lokalizacja wnosi własne urządzenia, własne godziny pracy i często własne lokalne przyzwyczajenia w nazewnictwie. Zaleca się uruchomienie integracji najpierw w jednej lokalizacji, potraktowanie jej jako wzorca i rozliczenie rozbieżności przed rozszerzeniem na pozostałe zakłady.

Czy integracja z urządzeniami wymaga wymiany sprzętu? Nie zawsze. Wiele terminali wagowych i systemów kontroli tankowania udostępnia dane w ustalonym formacie i wymaga tylko po stronie systemu transportowego odpowiedniego sterownika lub konwertera. Zakres do sprawdzenia to wersja oprogramowania urządzenia oraz to, czy producent nadal je wspiera.

Artykuł sponsorowany