Integracja awizacji z ERP, WMS i TMS
„Integracja z ERP” to za ogólne sformułowanie, żeby cokolwiek na jego podstawie zaplanować. Poniżej konkret: które dane płyną w którą stronę, jakimi sposobami da się je przenieść i co trzeba mieć przygotowane, zanim zacznie się rozmowa techniczna.
Integracja systemu awizacji polega na wymianie trzech grup danych: zamówień i kontrahentów z ERP, zapowiedzi przyjęć do WMS oraz statusów i okien czasowych do systemów przewoźnika. Techniczne sposoby połączenia są trzy — wymiana plikowa, API i dostęp do bazy — a wybór między nimi zależy od tego, jak świeże muszą być dane i co dopuszcza polityka bezpieczeństwa.
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 wie nie tylko, kto przyjedzie, ale i po co. 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
| Metoda | Świeżość danych | Kiedy się sprawdza |
|---|---|---|
| Wymiana plikowa (CSV, XML) przez katalog lub SFTP | Cykliczna — co kilka minut do kilku godzin | Gdy ERP nie ma API, a dane zmieniają się rzadko; najprostsza do uruchomienia i do zdiagnozowania |
| API po stronie jednego z systemów | Natychmiastowa | Gdy status ma być widoczny od razu po obu stronach; wymaga kanału sieciowego i obsługi błędów |
| Widok lub tabela pośrednia w bazie | Natychmiastowa w odczycie | Gdy oba systemy stoją w tej samej sieci; najmniej narzutu, ale wiąże systemy najmocniej |
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.
Co przygotować przed rozmową techniczną
Pięć rzeczy skraca ustalenia z tygodni do dni. Lista systemów z wersjami i informacja, który stoi w sieci lokalnej, a który w chmurze. Nazwisko właściciela każdego z nich po stronie klienta — integracja rozbija się częściej o brak decydenta niż o protokół. Środowisko testowe albo zgoda na pracę na kopii danych. Wspólny identyfikator dostawy: numer zamówienia, numer dokumentu, cokolwiek, co istnieje po obu stronach i się nie zmienia. Przykładowe dane — kilkanaście realnych rekordów mówi więcej niż specyfikacja pól.
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.