Integracja awizacji z ERP, WMS i TMS

Co płynie i w którą stronę

Z ERP do awizacji idą numer zamówienia i dane kontrahenta. Dzięki nim zgłoszenie przewoźnika wiąże się z konkretną dostawą, a magazyn zna cel przyjazdu, nie samą jego godzinę. W formularzu awizacji jest osobne pole na numer zamówienia SAP - widać je na zrzucie w galerii.

Z awizacji do WMS idzie zapowiedź przyjęcia: kiedy, na którą rampę i z jakim ładunkiem. Ten kierunek zamienia kalendarz w narzędzie planowania pracy - bez niego magazyn dowiaduje się o dostawie w chwili, gdy pojazd stoi pod bramą.

Z WMS z powrotem wracają potwierdzenie przyjęcia i rozbieżności ilościowe. System awizacji sam ich nie zna, a bez nich nie da się policzyć pełnego OTIF - awizacja mierzy terminowość, WMS kompletność. Zob. wskaźniki terminowości.

Do systemów przewoźnika idą status dostawy i przypisane okno czasowe, żeby dyspozytor po drugiej stronie widział to samo co magazyn. Różnice między klasami systemów opisuje system zarządzania transportem.

Trzy sposoby połączenia

W praktyce wdrożenia mieszają te metody: zamówienia przychodzą plikiem raz na godzinę, a statusy wracają od razu. To rozsądne, dopóki ktoś pilnuje, żeby oba kanały używały tego samego identyfikatora dostawy. Na wybór wpływa też miejsce instalacji - zob. chmura czy własny serwer.

Identyfikator, po którym łączą się rekordy

Cała integracja stoi na jednym polu: wartości, która opisuje ten sam obiekt po obu stronach i się nie zmienia. Bez niej dopasowanie sprowadza się do porównywania nazw i dat, a to działa do pierwszego kontrahenta zapisanego raz jako spółka z ograniczoną odpowiedzialnością, a raz jako sp. z o.o.

Kartoteka kontrahentów pokazuje to wprost: obok nazwy własnej stoi numer z systemu nadrzędnego. Nazwa służy człowiekowi, numer - integracji. Ta sama zasada dotyczy dostaw, gdzie rolę klucza pełni numer zamówienia, i przewoźników, gdzie bywa nim numer identyfikacji podatkowej.

Reguła projektowa. Klucz dopasowania ma być niezmienny przez całe życie rekordu. Numer, który dział zakupów poprawia po korekcie zamówienia, przestaje być kluczem i staje się kolejnym polem opisowym - a dostawy powiązane starą wartością zostają w systemie bez powiązania.

Częstotliwość, ponowienia i duplikaty

Druga rzecz, która decyduje o jakości integracji, to zachowanie przy błędzie. Połączenie sieciowe zerwie się prędzej czy później, a plik przyjdzie dwa razy - pytanie brzmi, co system wtedy robi. Odpowiedź daje operacja idempotentna: powtórzone przetworzenie tego samego rekordu ma dać ten sam wynik, a nie drugie zgłoszenie na tę samą dostawę. W bazie realizuje to instrukcja MERGE albo zapis warunkowy oparty o klucz naturalny, nigdy samo wstawianie wiersza.

• Okno przetwarzania - pora, w której wymiana nie koliduje ze szczytem na bramie; import kilkudziesięciu tysięcy wierszy o ósmej rano potrafi spowolnić obsługę wjazdów.
• Liczba ponowień - ile razy system próbuje ponownie, zanim uzna operację za nieudaną i zgłosi ją człowiekowi zamiast ponawiać w nieskończoność.
• Rejestr wymiany - zapis każdej paczki z czasem, liczbą rekordów i wynikiem; bez niego pytanie „czy zamówienie doszło” kończy się przeszukiwaniem dwóch systemów ręcznie.
• Reakcja na dane niepoprawne - odrzucenie pojedynczego rekordu z opisem przyczyny, a nie całej paczki, bo jeden błędny wiersz nie powinien zatrzymać dostaw na cały dzień.

Co przygotować przed rozmową techniczną

Cztery rzeczy skracają ustalenia z tygodni do dni:

• Lista systemów z wersjami wraz z informacją, który stoi w sieci lokalnej, a który w chmurze; od tego zależy, czy w ogóle da się zestawić połączenie.
• Właściciel każdego systemu po stronie klienta - integracja rozbija się częściej o brak decydenta niż o protokół.
• Środowisko testowe albo zgoda na pracę na kopii danych; testowanie na produkcji kończy się zwykle zgłoszeniami widmo w kalendarzu.
• Przykładowe dane - kilkanaście realnych rekordów mówi o formacie więcej niż specyfikacja pól, zwłaszcza o tym, co siedzi w polach opisowych.

Czego integracja nie załatwi

Nie naprawi danych, które są niespójne po jednej ze stron. Jeśli ten sam kontrahent występuje w ERP pod trzema nazwami, po integracji będzie występował pod trzema nazwami także w awizacji - tyle że szybciej. Nie zastąpi też wspólnego identyfikatora: bez pola, które istnieje po obu stronach, każde dopasowanie jest zgadywaniem po nazwie i dacie.

Najczęstszy błąd projektowy to integracja w jedną stronę. Dane wchodzą do awizacji, ale statusy nie wracają, więc magazyn i tak sprawdza wszystko ręcznie w dwóch systemach - i po kwartale wraca do Excela. Kierunek powrotny jest tym, co decyduje, czy wdrożenie się przyjmie. Zakres platformy opisuje katalog modułów, a dane, które przyspieszają wycenę integracji - strona kontaktu.

Nie zastąpi wreszcie ustalenia, który system jest źródłem prawdy dla danego pola. Jeśli adres dostawy da się zmienić i w ERP, i w awizacji, to po pierwszym rozjeździe nikt nie będzie wiedział, która wartość jest aktualna. Rozstrzygnięcie zapada przy projekcie, pole po polu, a nie przy pierwszej reklamacji. Co system awizacji potrafi zrobić z tymi danymi, pokazuje pomiar terminowości, a jak wygląda sam proces - system awizacji dostaw.

Najczęściej zadawane pytania

Czy integracja z ERP jest konieczna do uruchomienia awizacji

Nie. Rezerwacja okna opiera się na danych ze zgłoszenia przewoźnika, więc system działa samodzielnie od pierwszego dnia. Integracja dokłada powiązanie z zamówieniem i potwierdzenie przyjęcia, bez którego nie da się policzyć kompletności dostaw, ale nie jest warunkiem startu.

Jaki identyfikator wybrać do łączenia rekordów

Ten, który istnieje po obu stronach i nie zmienia się przez całe życie rekordu - najczęściej numer zamówienia dla dostaw i numer kontrahenta z systemu nadrzędnego dla firm. Dopasowanie po nazwie i dacie zawodzi przy pierwszej rozbieżności w zapisie nazwy spółki.

Co się stanie, gdy ten sam plik przyjdzie dwa razy

Przy poprawnie zbudowanej integracji nic - operacja jest idempotentna, więc powtórne przetworzenie aktualizuje istniejący rekord zamiast tworzyć drugi. Realizuje to zapis warunkowy oparty o klucz naturalny. Samo wstawianie wierszy bez takiej kontroli daje duplikaty zgłoszeń na tę samą dostawę.

Czy wymiana plikowa jest gorsza od API

Jest wolniejsza, nie gorsza. Plik wymieniany co godzinę wystarcza dla zamówień, które zmieniają się rzadko, i ma zaletę, której API nie ma: da się go obejrzeć i odtworzyć. API wygrywa tam, gdzie status musi być widoczny po obu stronach od razu, na przykład przy potwierdzeniu wjazdu.

Dlaczego integracja w jedną stronę bywa gorsza niż jej brak

Bo dane wchodzą do awizacji, ale statusy nie wracają, więc magazyn i tak sprawdza wszystko w dwóch systemach. Praca rośnie zamiast maleć i po kilku miesiącach zespół wraca do arkusza. Kierunek powrotny decyduje o tym, czy wdrożenie się przyjmie.

Kto rozstrzyga, który system jest źródłem prawdy dla danego pola

Zespół projektowy po stronie klienta, przy projektowaniu wymiany, pole po polu. Jeśli adres dostawy albo dane kontrahenta da się zmienić w obu systemach, po pierwszym rozjeździe żadna ze stron nie wie, która wartość jest aktualna, a integracja tylko rozprowadza błąd szybciej.

Słownik pojęć

Pozostałe pojęcia z obsługi transportu zbiera słownik YMS.

KKlucz naturalny

Pole albo zestaw pól o znaczeniu biznesowym, jednoznacznie identyfikujące rekord po obu stronach wymiany, na przykład numer zamówienia.

IIdempotentność

Własność operacji, przy której powtórzone wykonanie na tych samych danych daje ten sam wynik, bez tworzenia duplikatów.

ZZapowiedź przyjęcia

Komunikat wysyłany z awizacji do systemu magazynowego, informujący o planowanej dostawie, jej terminie i rampie.

RRejestr wymiany

Zapis każdej przetworzonej paczki danych z czasem, liczbą rekordów i wynikiem, służący do odtworzenia przebiegu integracji.

ŹŹródło prawdy

System uznany za nadrzędny dla konkretnego pola, w którym wartość jest edytowana i z którego rozchodzi się do pozostałych.

ŚŚrodowisko testowe

Odrębna instancja systemu z kopią danych, na której sprawdza się wymianę przed uruchomieniem jej na danych produkcyjnych.