Integracja platformy B2B z ERP i marketplace - jak zaplanować wymianę danych?

Integracja łączy procesy, a nie tylko systemy

Firma może korzystać jednocześnie z ERP, platformy B2B, PIM, WMS, CRM, systemu finansowo-księgowego, aplikacji przewoźników oraz kilku platform marketplace. Każde z tych rozwiązań obsługuje inny fragment procesu i przechowuje część potrzebnych danych.

Samo techniczne połączenie aplikacji nie zapewnia jednak spójnego przepływu informacji.

Przed rozpoczęciem integracji trzeba ustalić:

• który system jest głównym źródłem poszczególnych danych,
• w jakim kierunku informacje mają być przekazywane,
• jak często powinny być aktualizowane,
• jak rozpoznawane są produkty, klienci i dokumenty,
• co dzieje się w przypadku błędu,
• kto odpowiada za poprawę odrzuconego rekordu,
• jak sprawdzić, czy dane dotarły do systemu docelowego,
• kto będzie utrzymywał integrację po jej uruchomieniu.

Bez tych ustaleń firma może jedynie przyspieszyć nieuporządkowany proces. Dane będą przesyłane szybciej, ale nadal mogą być niepełne, sprzeczne lub przypisane do niewłaściwych rekordów.

Integracja czy wymiana obecnego systemu?

Brak potrzebnej funkcji nie zawsze oznacza konieczność wymiany całego ERP.

Jeżeli obecny system prawidłowo obsługuje podstawowe procesy firmy, można rozważyć rozszerzenie go o wyspecjalizowane rozwiązanie, na przykład:

• platformę sprzedażową B2B,
• system PIM,
• mobilną obsługę magazynu,
• system TMS,
• elektroniczny obieg dokumentów,
• aplikację dla handlowców,
• dodatkowy kanał marketplace.

Warunkiem jest możliwość kontrolowanej wymiany danych między nowym rozwiązaniem a systemami używanymi przez firmę.

Integracja może być właściwym kierunkiem, gdy:

• główny ERP nadal odpowiada procesom organizacji,
• brak dotyczy konkretnego obszaru,
• system umożliwia wymianę danych przez API lub pliki,
• dane źródłowe są wystarczająco uporządkowane,
• można jednoznacznie określić odpowiedzialność systemów,
• pełna migracja byłaby nieproporcjonalna do rozwiązywanego problemu.

Wymianę systemu warto natomiast rozważyć, gdy jego struktura blokuje rozwój, wymiana danych jest niewiarygodna albo większość procesów i tak odbywa się poza nim za pomocą arkuszy oraz ręcznych obejść.

O decyzji nie powinien przesądzać sam wiek oprogramowania. Znaczenie mają jego możliwości, jakość danych, dostępność interfejsów i koszt dalszego utrzymania całego środowiska.

Zacznij od mapy systemów i procesu

Pierwszym etapem powinno być opisanie obecnej architektury.

Warto wskazać:

• wszystkie aplikacje uczestniczące w sprzedaży i realizacji zamówień,
• dane przechowywane w każdym systemie,
• istniejące integracje,
• ręczne importy i eksporty,
• arkusze wykorzystywane poza głównymi aplikacjami,
• miejsca, w których dane są ponownie przepisywane,
• osoby odpowiedzialne za poszczególne informacje,
• procesy zależne od wiedzy pojedynczych pracowników.

Szczególną uwagę należy zwrócić na nieformalne elementy procesu.

Jeżeli cennik jest oficjalnie przechowywany w ERP, ale handlowcy regularnie korygują ceny w prywatnych arkuszach, samo połączenie platformy z ERP nie odtworzy rzeczywistych warunków sprzedaży. Najpierw trzeba ustalić, gdzie powinna znajdować się obowiązująca informacja.

Podobny problem może dotyczyć stanów magazynowych, opisów produktów, adresów klientów, kodów towarów i statusów zamówień.

Określ cel integracji

Projekt nie powinien zaczynać się od pytania:

Jakie dane możemy przesłać przez API?

Najpierw trzeba określić, jaki problem biznesowy ma zostać rozwiązany.

Celem może być na przykład:

• przekazywanie zamówień z platformy B2B do ERP bez ręcznego przepisywania,
• publikowanie aktualnych cen i stanów w kanałach sprzedaży,
• ograniczenie ręcznego tworzenia ofert na platformach marketplace,
• pobieranie zamówień z kilku kanałów do jednego procesu,
• synchronizacja opisów i parametrów z PIM,
• przekazywanie klientom informacji o wysyłce,
• udostępnienie partnerom handlowym danych przez API,
• wyeliminowanie ręcznego importowania dokumentów.

Cel powinien być możliwy do sprawdzenia po wdrożeniu.

Zamiast ogólnego założenia „automatyzujemy sprzedaż” lepiej przyjąć konkretny rezultat:

Zamówienie złożone na platformie ma zostać zapisane w ERP bez ponownego przepisywania, a ewentualny błąd przekazania powinien być widoczny dla wskazanego pracownika.

Ustal główne źródło danych

Ten sam produkt może występować równocześnie w ERP, PIM, platformie B2B i kilku kanałach marketplace. Nie oznacza to, że we wszystkich miejscach powinien być niezależnie edytowany.

Dla każdego obszaru trzeba wskazać system główny.

Produkty i ich identyfikatory

Podstawowe kartoteki mogą być prowadzone w ERP. System ten może odpowiadać za kod produktu, jednostkę sprzedaży, stawkę podatkową i status handlowy.

Platforma B2B oraz kanały marketplace wykorzystują te dane podczas publikacji oferty i rejestracji zamówienia.

Opisy, zdjęcia i parametry

W firmach z rozbudowanym katalogiem źródłem informacji marketingowej i technicznej może być PIM.

To w nim mogą być zarządzane:

• opisy,
• zdjęcia,
• dokumenty,
• parametry,
• klasyfikacje,
• wersje językowe,
• powiązania między produktami,
• informacje wymagane przez poszczególne kanały.

Ceny, rabaty i warunki handlowe

Najczęściej odpowiada za nie ERP lub inny system prowadzący politykę handlową.

Platforma B2B może prezentować klientowi indywidualne warunki, natomiast kanał marketplace może otrzymywać osobne ceny przeznaczone dla danego sposobu sprzedaży.

Stany i dostępność

Źródłem może być ERP albo WMS.

Trzeba jednak odróżnić fizyczny stan magazynowy od ilości dostępnej do sprzedaży. Firma może uwzględniać rezerwacje, zamówienia oczekujące, bufory bezpieczeństwa lub towary przeznaczone dla innych kanałów.

Klienci i kontrahenci

Głównym źródłem może być ERP lub CRM.

Należy ustalić, gdzie tworzy się klienta, kto aktualizuje jego dane oraz w jaki sposób konta użytkowników platformy są łączone z właściwym kontrahentem.

Zamówienia

Zamówienie może powstać na platformie B2B, w kanale marketplace, aplikacji mobilnej lub systemie partnera.

Systemem odpowiedzialnym za dalszą realizację jest zazwyczaj ERP. Integracja powinna przekazać do niego komplet informacji potrzebnych do sprzedaży, magazynu, płatności i dostawy.

Dokumenty i statusy

Faktury i rozrachunki mogą pochodzić z ERP lub systemu finansowego, status kompletacji z WMS, a informacja o dostawie z TMS albo systemu przewoźnika.

Platforma B2B i kanały marketplace prezentują klientowi wybrane informacje, ale nie muszą być ich głównym źródłem.

Wybierz kierunek wymiany danych

Integracja może być jednokierunkowa albo dwukierunkowa.

Wymiana jednokierunkowa

Dane są przekazywane z jednego systemu do drugiego.

Przykłady:

• ceny z ERP do platformy B2B,
• opisy z PIM do kanału marketplace,
• zamówienia z marketplace do ERP,
• status dostawy z TMS do platformy.

To prostszy model, ponieważ tylko jedno rozwiązanie ma prawo zmieniać daną informację.

Wymiana dwukierunkowa

Dane mogą być tworzone lub aktualizowane w obu systemach.

Może to dotyczyć niektórych danych klientów, statusów lub dokumentów wymienianych z partnerem.

Taki model wymaga wcześniejszego ustalenia:

• które pola można zmieniać w każdym systemie,
• która zmiana ma pierwszeństwo,
• jak wykrywane są konflikty,
• czy każda aktualizacja jest przesyłana z powrotem,
• jak zapobiegać wielokrotnemu powtarzaniu tej samej zmiany.

Integracja dwukierunkowa nie jest automatycznie lepsza. Jest bardziej złożona i może zwiększać ryzyko niespójności.

Jak często synchronizować dane?

Nie wszystkie informacje muszą być przekazywane w tym samym momencie.

Wymiana po wystąpieniu zdarzenia

Sprawdza się tam, gdzie opóźnienie wpływa na realizację procesu.

Może dotyczyć:

• nowych zamówień,
• anulowania zamówienia,
• krytycznej zmiany statusu,
• potwierdzenia płatności,
• informacji o wysyłce.

Synchronizacja cykliczna

Może być wystarczająca dla danych, które nie zmieniają się często albo nie wymagają natychmiastowego odświeżenia.

Przykłady:

• opisy produktów,
• zdjęcia,
• część parametrów,
• słowniki,
• wybrane dane historyczne.

Model mieszany

W jednym projekcie można stosować kilka częstotliwości.

Zamówienia mogą być przekazywane bezpośrednio po ich złożeniu, stany aktualizowane co kilka minut, a kompletne dane produktowe publikowane według ustalonego harmonogramu.

Częstotliwość powinna wynikać z procesu biznesowego, a nie wyłącznie z technicznych możliwości interfejsu.

API, zdarzenia czy pliki?

Nie każda integracja musi działać w ten sam sposób.

API

API umożliwia aplikacjom bezpośrednią wymianę danych według określonych reguł.

Może służyć do:

• pobierania produktów i cen,
• sprawdzania dostępności,
• składania zamówień,
• pobierania dokumentów,
• przekazywania statusów,
• komunikacji z systemami partnerów.

Przed wykorzystaniem API trzeba sprawdzić:

• dostępne operacje,
• sposób uwierzytelniania,
• ograniczenia liczby zapytań,
• wersjonowanie,
• komunikaty błędów,
• zasady wycofywania starszych wersji.

Powiadomienia o zdarzeniach

System może informować drugą aplikację, że wystąpiło określone zdarzenie, na przykład złożono nowe zamówienie albo zmienił się jego status.

Pozwala to ograniczyć ciągłe sprawdzanie, czy pojawiły się nowe dane.

Wymiana plików

Pliki CSV, XML lub inne uzgodnione formaty mogą być właściwym rozwiązaniem, szczególnie gdy jeden z systemów nie posiada odpowiedniego API.

Trzeba jednak ustalić:

• format i kodowanie,
• nazewnictwo plików,
• miejsce przekazywania,
• częstotliwość,
• sposób potwierdzania odbioru,
• obsługę błędnych wierszy,
• ochronę przed ponownym importem tego samego pliku.

Technologia powinna zostać dobrana do możliwości połączonych systemów oraz znaczenia procesu.

Mapowanie danych

Dwa systemy mogą przechowywać tę samą informację w inny sposób.

Przykładowo:

• produkt może mieć różne kody w ERP i marketplace,
• jednostka „opakowanie” może oznaczać inną liczbę sztuk,
• magazyny mogą posiadać odmienne identyfikatory,
• status „wysłane” może być inaczej rozumiany przez ERP i przewoźnika,
• klient może występować pod różnymi numerami,
• platforma marketplace może wymagać parametrów, których nie ma w ERP.

Przed uruchomieniem trzeba przygotować mapowanie obejmujące między innymi:

• kody produktów,
• numery EAN i inne identyfikatory,
• jednostki miary,
• warianty,
• magazyny,
• klientów i adresy,
• statusy zamówień,
• formy płatności,
• metody dostawy,
• waluty,
• stawki podatkowe,
• kategorie i atrybuty marketplace.

Brak mapowania nie zawsze powoduje zatrzymanie całej integracji. Może prowadzić do trudniejszych do wykrycia problemów, takich jak błędna jednostka, niewłaściwy magazyn albo niepełna oferta.

Integracja platformy B2B z ERP

W sprzedaży B2B platforma zwykle wykorzystuje dane pochodzące z ERP i przekazuje do niego zamówienia klientów.

Zakres wymiany może obejmować:

• kontrahentów i użytkowników,
• adresy dostawy,
• produkty,
• ceny i rabaty,
• limity kredytowe,
• stany i dostępność,
• zamówienia,
• faktury,
• rozrachunki,
• statusy realizacji.

Ważne jest sprawdzenie całego przepływu: od danych źródłowych, przez prezentację na platformie, do zapisania zamówienia i jego dalszej realizacji w ERP.

Szerzej proces przygotowania samej platformy opisujemy w poradniku Wdrożenie platformy B2B - funkcje, etapy i integracje.

PIM, WMS i logistyka

Platforma sprzedażowa nie musi pobierać wszystkich informacji bezpośrednio z ERP.

PIM

PIM może przekazywać do kanałów sprzedaży opisy, zdjęcia, parametry, dokumenty, klasyfikacje i wersje językowe.

Pozwala oddzielić dane handlowe oraz magazynowe od rozbudowanej informacji produktowej.

Poznaj system PIM Certusoft

WMS

WMS może dostarczać informacje związane z dostępnością, rezerwacją, kompletacją i przygotowaniem towaru.

Zakres zależy od tego, które procesy prowadzone są w ERP, a które w systemie magazynowym.

TMS i przewoźnicy

System transportowy albo aplikacja przewoźnika może przekazywać numer przesyłki, status dostawy i inne informacje udostępniane później klientowi.

Każde dodatkowe połączenie zwiększa możliwości procesu, ale także liczbę zależności wymagających monitorowania.

Integracja z marketplace

Platforma marketplace nie jest jedynie kolejnym miejscem publikacji tego samego katalogu.

Każdy kanał może posiadać własne:

• kategorie,
• obowiązkowe parametry,
• zasady tworzenia wariantów,
• formaty opisów,
• wymagania dotyczące zdjęć,
• modele cenowe,
• sposoby obsługi dostawy,
• statusy zamówień,
• reguły anulowania i zwrotów,
• ograniczenia techniczne.

Integracja powinna obejmować cały cykl sprzedaży, a nie tylko wystawienie oferty.

Publikacja ofert

Trzeba ustalić, które produkty są przeznaczone do danego kanału i jakie informacje są wymagane do ich opublikowania.

Nie każdy produkt z ERP musi automatycznie trafić do kanału marketplace.

Ceny i stany

Firma powinna określić, czy kanał korzysta z ceny bazowej, osobnego cennika, narzutu albo innej reguły.

W przypadku stanów trzeba uwzględnić rezerwacje, inne kanały sprzedaży i ewentualny bufor chroniący przed sprzedażą niedostępnego towaru.

Zamówienia

Zamówienie powinno trafić do systemu odpowiedzialnego za jego dalszą realizację wraz z informacją o:

• kanale,
• produktach i ilościach,
• cenie,
• kosztach dostawy,
• sposobie płatności,
• danych odbiorcy,
• adresie,
• identyfikatorach wymaganych przez marketplace.

Należy też ustalić, jak obsłużyć zamówienie, którego produktu nie udało się rozpoznać.

Statusy i wysyłka

Po przygotowaniu towaru informacja o realizacji może wracać do kanału marketplace.

Trzeba określić, który system jest źródłem statusu i kiedy przesyłkę można uznać za faktycznie nadaną.

Anulowania, zwroty i korekty

Proces nie kończy się po przekazaniu zamówienia.

Projekt powinien uwzględniać również anulowanie, częściową realizację, zwrot, korektę danych i dokumenty powstające po sprzedaży - w zakresie obsługiwanym przez dany kanał oraz integrację.

Bezpośrednie połączenia czy warstwa pośrednia?

Firma korzystająca z kilku kanałów może tworzyć osobne połączenie każdego systemu z ERP albo zastosować warstwę pośrednią.

Bezpośrednia integracja może być wystarczająca, gdy:

• liczba kanałów jest niewielka,
• procesy są proste,
• zakres wymiany pozostaje stabilny,
• systemy mają dobrze dopasowane interfejsy.

Warstwa pośrednia może być przydatna, gdy:

• firma korzysta z wielu platform marketplace,
• potrzebne jest wspólne mapowanie danych,
• zamówienia mają trafiać do jednego procesu,
• należy przekształcać dane między różnymi formatami,
• ważne jest centralne monitorowanie wymiany,
• system główny nie powinien być bezpośrednio połączony z każdym kanałem.

Nie istnieje jeden model właściwy dla wszystkich firm. Architektura powinna uwzględniać liczbę systemów, skalę sprzedaży, częstotliwość zmian i możliwości zespołu odpowiedzialnego za utrzymanie.

Obsługa błędów jest częścią procesu

W każdym projekcie integracyjnym trzeba założyć możliwość wystąpienia błędów - zarówno po stronie danych, jak i komunikacji między systemami.

Przyczyną może być:

• brak obowiązkowego pola,
• nieznany kod produktu,
• nieprawidłowa jednostka,
• niedostępność systemu zewnętrznego,
• zmiana struktury danych,
• duplikat dokumentu,
• brak uprawnień,
• niezgodność statusów,
• czasowy problem z połączeniem.

Dlatego trzeba zaplanować:

• rejestrowanie wykonanych operacji,
• status każdego rekordu,
• informację o przyczynie odrzucenia,
• możliwość ponowienia transmisji,
• ochronę przed utworzeniem duplikatu,
• wskazanie odpowiedzialnej osoby,
• historię prób przekazania danych.

Szczególnie istotne są błędy częściowe. Część produktów może zostać zaktualizowana prawidłowo, a pozostałe rekordy odrzucone.

Proces nie powinien przedstawiać całej operacji jako zakończonej bez informacji o takich wyjątkach.

Monitorowanie po uruchomieniu

Integracja działająca prawidłowo w dniu odbioru może przestać działać po zmianie jednego z połączonych systemów.

Należy monitorować między innymi:

• liczbę przekazanych i odrzuconych rekordów,
• czas przetwarzania,
• opóźnienia synchronizacji,
• zamówienia, które nie dotarły do ERP,
• produkty nieopublikowane w kanałach,
• rozbieżności cen i stanów,
• błędy uwierzytelniania,
• zmiany wersji interfejsów.

Trzeba również określić, kto reaguje na problem i kto kontaktuje się z dostawcą systemu zewnętrznego.

Samo zapisanie błędu w technicznym logu nie wystarcza, jeżeli osoba odpowiedzialna za sprzedaż nie wie, że zamówienie nie jest realizowane.

Testy i kryteria odbioru

Testy powinny obejmować nie tylko poprawny rekord, ale również sytuacje występujące w rzeczywistym procesie.

Warto sprawdzić:

• nowy i istniejący produkt,
• zmianę ceny,
• brak wymaganej ceny,
• kilka jednostek sprzedaży,
• stan zerowy,
• nowego klienta,
• zmianę adresu,
• zamówienie wielopozycyjne,
• częściową realizację,
• anulowanie,
• ponowienie tej samej transmisji,
• niedostępność jednego z systemów,
• nieznany identyfikator,
• błędną wartość pola,
• wznowienie procesu po usunięciu błędu,
• większą liczbę danych przesyłanych jednocześnie.

Przed rozpoczęciem testów trzeba też określić warunki uznania integracji za gotową.

Przykładowe kryteria:

• produkt jest jednoznacznie identyfikowany,
• cena w kanale odpowiada właściwemu źródłu,
• stan jest aktualizowany zgodnie z harmonogramem,
• zamówienie trafia do odpowiedniego kontrahenta i magazynu,
• ponowienie transmisji nie tworzy duplikatu,
• odrzucony rekord jest widoczny wraz z przyczyną,
• status realizacji wraca do właściwego kanału,
• historia wymiany pozwala odtworzyć przebieg operacji.

Samo stwierdzenie, że API odpowiada poprawnie, nie potwierdza jeszcze działania całego procesu biznesowego.

Pilotaż i uruchomienie

Przy większym zakresie warto rozpocząć od ograniczonego pilotażu.

Może on obejmować:

• jednego partnera,
• wybraną grupę produktów,
• jeden magazyn,
• jeden kanał marketplace,
• ograniczoną liczbę zamówień,
• wybrany rodzaj dokumentu.

Pozwala to sprawdzić mapowanie, obsługę błędów i odpowiedzialność zespołów bez jednoczesnego uruchamiania wszystkich kanałów.

Przed startem produkcyjnym trzeba ustalić:

• moment ostatniej synchronizacji początkowej,
• sposób włączenia automatycznej wymiany,
• procedurę reakcji na problem krytyczny,
• możliwość czasowego powrotu do wcześniejszego procesu,
• osoby dostępne w pierwszych dniach działania,
• sposób weryfikacji kompletności danych po uruchomieniu.

Utrzymanie integracji

Integracja jest elementem infrastruktury operacyjnej firmy, a nie jednorazowym importem danych.

Po uruchomieniu trzeba ustalić odpowiedzialność za:

• monitorowanie działania,
• aktualizację danych dostępowych,
• reagowanie na zmiany interfejsów,
• rozwój mapowania,
• dodawanie nowych produktów i kanałów,
• analizę błędów,
• testy po aktualizacji systemów,
• dokumentację techniczną i procesową.

Każda większa zmiana w ERP, platformie, PIM lub marketplace powinna uwzględniać wpływ na działającą wymianę danych.

Czego integracja nie rozwiąże samodzielnie?

Integracja nie zastąpi:

• uporządkowanych kartotek produktów,
• jednoznacznych kodów i jednostek,
• aktualnych danych klientów,
• spójnej polityki cenowej,
• właściwej konfiguracji magazynów,
• zdefiniowanego procesu zwrotów,
• odpowiedzialności za błędy,
• kontroli jakości danych,
• decyzji o systemach źródłowych.

Jeżeli w ERP występują duplikaty, błędne jednostki lub nieaktualne ceny, automatyczna synchronizacja może rozpowszechnić te problemy we wszystkich kanałach.

Najpierw trzeba uporządkować dane i reguły, a następnie je automatyzować.

Certusoft Connector i integracje z systemami zewnętrznymi

Certusoft realizuje integracje pomiędzy ERP, systemami magazynowymi, platformami e-commerce, platformami marketplace, aplikacjami mobilnymi oraz innymi rozwiązaniami wykorzystywanymi przez firmy.

W zależności od procesu wymiana może obejmować między innymi:

• dane sprzedażowe,
• informacje finansowe,
• dane magazynowe,
• produkty i opisy,
• oferty publikowane w kanałach marketplace,
• zamówienia,
• dokumenty,
• komunikację z urządzeniami i systemami zewnętrznymi.

Integracja może działać jednokierunkowo lub dwukierunkowo. Zakres, częstotliwość i sposób komunikacji są ustalane na podstawie możliwości połączonych systemów oraz rzeczywistego procesu klienta.

Connector lub dedykowane API mogą pozwolić rozbudować istniejące środowisko bez konieczności wymiany całego ERP. Wymaga to jednak wcześniejszej analizy interfejsów, danych i odpowiedzialności poszczególnych aplikacji.

Poznaj możliwości integracji systemów Certusoft

Poznaj platformę e-commerce B2B i B2C Certusoft

Najczęściej zadawane pytania

Jakie systemy można integrować z platformą B2B?

Najczęściej są to ERP, PIM, CRM, WMS, systemy finansowe, TMS, aplikacje przewoźników, platformy marketplace oraz systemy partnerów. Możliwość integracji zależy od dostępnych interfejsów i zakresu danych.

Czy każda integracja musi wykorzystywać API?

Nie. W zależności od możliwości systemów można stosować API, powiadomienia o zdarzeniach, wymianę plików albo inne uzgodnione mechanizmy.

Czy synchronizacja powinna działać w czasie rzeczywistym?

Nie dla każdego rodzaju danych. Zamówienia i krytyczne statusy mogą wymagać szybkiej wymiany, natomiast zdjęcia, opisy i słowniki mogą być aktualizowane okresowo.

Czy dane powinny być synchronizowane w obu kierunkach?

Tylko wtedy, gdy wynika to z procesu. Dwukierunkowa wymiana zwiększa ryzyko konfliktów i wymaga określenia, który system ma pierwszeństwo.

Czy integracja pozwala uniknąć wymiany obecnego ERP?

Czasami tak. Jeżeli obecny ERP prawidłowo obsługuje podstawowe procesy i umożliwia wymianę danych, można rozbudować środowisko o dodatkowe rozwiązania. Decyzja wymaga jednak analizy technicznej i biznesowej.

Jak sprawdzić, czy integracja działa prawidłowo?

Należy monitorować kompletność danych, błędy, opóźnienia i rozbieżności oraz testować cały proces - od źródła informacji do jej wykorzystania w systemie docelowym.

Dobra integracja zaczyna się od uporządkowania danych

Wartość integracji nie wynika z samego faktu przesłania informacji pomiędzy aplikacjami.

Znaczenie ma to, czy właściwe dane trafiają do odpowiedniego miejsca, w wymaganym czasie i w formie, którą system docelowy potrafi prawidłowo wykorzystać.

Dlatego projekt powinien rozpocząć się od procesów, odpowiedzialności i źródeł danych. Dopiero później należy wybrać techniczny sposób komunikacji.

Dobrze zaplanowana integracja może połączyć platformę B2B, ERP, PIM, magazyn, logistykę i kanały marketplace w jeden kontrolowany proces. Nie usuwa jednak potrzeby dbania o dane, reguły biznesowe i utrzymanie całego środowiska.

Porozmawiaj z nami o integracji systemów w Twojej firmie