Integracja e-commerce z ERP zwykle zaczyna się od pytania o API. Czy system ma odpowiednie endpointy, jakie dane można pobierać i jak często da się je synchronizować.
To ważne, ale nie tylko od tego powinien zaczynać się projekt.
Trzeba również ustalić, który system odpowiada za konkretną informację, w którą stronę mają płynąć dane i co ma się wydarzyć, kiedy jeden z systemów przestanie odpowiadać.
Projektujemy integracje Magento z ERP jako część architektury platformy - nie jako zestaw skryptów dopiętych pomiędzy systemami na końcu wdrożenia.
Bezpłatna rozmowa, 30-60 minut. Poznamy system ERP, przepływy danych i procesy, które ma obsługiwać integracja. Wstępnie określimy zakres, główne ryzyka i obszary wymagające dalszej analizy.
Odpowiedzialność
W złożonym e-commerce te same informacje często występują w kilku systemach.
ERP może przechowywać ceny, stany i warunki handlowe. PIM odpowiadać za opisy i atrybuty. Magento za prezentację produktów, koszyk i proces zakupowy.
Problem zaczyna się wtedy, gdy tę samą informację można niezależnie zmienić w kilku miejscach.
Jeżeli cenę można edytować zarówno w ERP, jak i Magento, prędzej czy później pojawią się dwie różne wersje tej samej wartości.
Dlatego przed developmentem ustalamy źródło prawdy dla każdego istotnego typu danych.
Typowy podział może wyglądać tak:
To punkt wyjścia, nie gotowy schemat dla każdej firmy.
Jeżeli po wdrożeniu tę samą informację nadal można niezależnie zmienić w kilku systemach, problem odpowiedzialności za dane nie został rozwiązany. Integracja tylko go ukryła.
Zakres integracji
Zakres zależy od modelu biznesowego. Najczęściej integracja obejmuje kilka krytycznych przepływów.
ERP może przekazywać SKU, podstawowe dane produktów, jednostki, statusy, informacje logistyczne oraz dane potrzebne do powiązania rekordów pomiędzy systemami.
Jeżeli firma korzysta z PIM, nie ma potrzeby przenoszenia całej informacji produktowej przez ERP. Dane handlowe mogą pochodzić z jednego systemu, a treści i rozbudowane atrybuty z drugiego.
W B2B cena często zależy od konkretnego klienta, cennika, umowy, ilości czy rynku.
Jeżeli logika cenowa działa w ERP, zwykle nie ma sensu budować jej ponownie w Magento. Trzeba natomiast zaprojektować sposób, w jaki właściwa cena trafia do właściwego klienta i pozostaje wystarczająco aktualna.
Przy jednym magazynie synchronizacja dostępności może być stosunkowo prosta.
Przy wielu magazynach dochodzą zasady rezerwacji, różne lokalizacje, częstotliwość aktualizacji i decyzja, co sklep ma zrobić, kiedy dane źródłowe są chwilowo niedostępne.
W projektach B2B integracja może obejmować dane firmowe, przypisanie do grup i handlowców, cenniki, limity kupieckie, warunki płatności i inne informacje potrzebne podczas zakupów.
Tu również musi być jasne, który system jest właścicielem konkretnej informacji.
To zazwyczaj najbardziej krytyczny przepływ.
Magento przyjmuje zamówienie, ale jego dalsza realizacja często odbywa się w ERP. Do systemu zaplecza muszą więc trafić dane klienta, pozycje, ceny, rabaty, dostawa, płatność i identyfikatory wymagane przez proces operacyjny.
Później informacje wracają do Magento: status realizacji, wysyłka, dokumenty czy inne dane potrzebne klientowi.
Samo wysłanie zamówienia nie wystarcza. Trzeba również wiedzieć, czy ERP rzeczywiście je przyjął.
Odporność
Największe problemy nie pojawiają się wtedy, gdy oba systemy działają poprawnie.
Magento może wysłać zamówienie, ERP je przyjąć, ale odpowiedź zaginie. Jeśli komunikacja zostanie bez kontroli powtórzona, po stronie ERP mogą pojawić się dwa dokumenty dotyczące tej samej transakcji.
Idempotencja brzmi jak techniczny detal. Do momentu, w którym ten sam dokument trafia do ERP dwa razy. Wtedy staje się problemem operacyjnym, logistycznym albo księgowym.
Dlatego przy krytycznych przepływach projektujemy między innymi:
Chwilowa niedostępność systemu zaplecza nie powinna automatycznie oznaczać utraty danych lub zatrzymania całej sprzedaży.
Synchronizacja
„Chcemy mieć wszystkie dane natychmiast" brzmi jak oczywiste wymaganie. W praktyce nie każdy przepływ tego potrzebuje.
Cena konkretnego klienta może wymagać bardzo świeżej informacji. Aktualizacja dużej liczby danych katalogowych może spokojnie odbywać się asynchronicznie.
Dla każdego procesu ustalamy, jak świeże muszą być dane, jaki jest ich wolumen i co się stanie, jeśli informacja dotrze z opóźnieniem. Sprawdzamy też, czy użytkownik czeka na odpowiedź, czy proces może zostać wykonany w tle.
Dzięki temu nie uzależniamy działania Magento od dostępności ERP tam, gdzie biznes tego nie wymaga.
Architektura
W jednym z dużych projektów e-commerce integrowaliśmy Magento z wieloletnim systemem ERP przez dedykowane API rozwijane po stronie klienta przez wiele lat.
Model danych po stronie systemu źródłowego był historyczny i nie odpowiadał bezpośrednio strukturze, którą chcieliśmy uzyskać w Magento.
Zamiast odwzorowywać wszystkie ograniczenia legacy w nowej platformie, przygotowaliśmy warstwę konwertującą. Jej zadaniem było mapowanie i normalizacja danych, dostosowanie ich do docelowego modelu Magento, obsługa różnic pomiędzy strukturami obu systemów oraz przygotowanie informacji pod nowe mechanizmy filtrowania i prezentacji katalogu.
W tym projekcie warstwa pośrednia pozwoliła oddzielić model legacy od docelowego modelu Magento i rozwijać obie strony bez bezpośredniego sprzęgania ich struktur.
To ważne szczególnie wtedy, gdy ERP jest systemem rozwijanym od wielu lat i nie może zostać przebudowany tylko dlatego, że firma uruchamia nową platformę e-commerce.
Doświadczenie
Sama nazwa ERP nie określa jednak architektury integracji.
Dwie organizacje korzystające z tego samego produktu mogą mieć zupełnie inne rozszerzenia, modele cenowe, procesy i interfejsy.
Doświadczenie z konkretnym systemem może przyspieszyć discovery i pomaga szybciej rozpoznać typowe problemy, ale go nie zastępuje.
Pracowaliśmy przy integracjach z SAP ECC i SAP S/4HANA, Asseco Softlab, systemami Comarch, Microsoft Dynamics oraz enova365.
Mamy również doświadczenie z rozwiązaniami dedykowanymi i wieloletnimi systemami legacy.
Jak pracujemy
Zaczynamy od tego, co rzeczywiście dzieje się w firmie: skąd biorą się produkty, ceny i stany, kiedy powstaje klient, co dzieje się z zamówieniem i które procesy są krytyczne.
Ustalamy, który system odpowiada za konkretną informację i gdzie można ją zmieniać.
Definiujemy kierunki komunikacji, mapowanie danych, wymagania dotyczące aktualności oraz model synchroniczny lub asynchroniczny dla poszczególnych procesów.
Projektujemy kolejki, retry, idempotencję, logowanie i monitoring tam, gdzie są potrzebne.
Budujemy integrację po stronie Magento oraz potrzebne adaptery lub warstwy pośrednie.
Nie testujemy wyłącznie scenariusza, w którym wszystko działa poprawnie.
Sprawdzamy również, co dzieje się, gdy:
Po go-live obserwujemy rzeczywisty przepływ danych i stabilizujemy procesy w warunkach produkcyjnych.
Integracja może później być rozwijana i utrzymywana razem z platformą Magento.
Utrzymanie
ERP będzie się zmieniać. Pojawią się nowe pola, magazyny, rynki i procesy.
Dlatego integracja powinna być możliwa do diagnozowania bez ponownego odkrywania po roku, jak właściwie działają poszczególne przepływy.
Przy krytycznych procesach ważne są logi pozwalające prześledzić konkretną operację, monitoring błędów i możliwość kontrolowanego ponowienia przetwarzania.
Im bardziej krytyczny proces, tym mniej powinien przypominać skrypt, który „co kilka minut coś synchronizuje".
Doświadczenie
Integracje są stałym elementem złożonych projektów Magento, które realizujemy.
Pracujemy nie tylko na poziomie API, ale również danych, baz, kolejek, wyszukiwarki i infrastruktury. Dzięki temu możemy analizować cały proces, a nie tylko fragment pomiędzy dwoma endpointami.
Mamy doświadczenie zarówno z nowoczesnymi ERP, jak i z rozwiązaniami legacy rozwijanymi przez wiele lat.
To szczególnie ważne wtedy, gdy prawdziwym problemem nie jest brak API, tylko różnica pomiędzy historycznym modelem danych a sposobem, w jaki firma chce działać po wdrożeniu nowego e-commerce.
Dopasowanie
Jeżeli głównym problemem są rozproszone opisy, atrybuty, tłumaczenia i inne dane produktowe, samo podłączenie ERP nie rozwiąże sytuacji. Wtedy warto zacząć od PIM i zarządzania danymi produktowymi.
PIM i zarządzanie danymi produktowymi →Jeżeli problem dotyczy klientów, pracy handlowców, pipeline i relacji sprzedażowej, właściwszym kierunkiem będą integracje CRM.
Integracje CRM →Jeżeli ERP jest tylko jednym z elementów budowy zupełnie nowej platformy, właściwym kierunkiem będzie wdrożenie Magento.
Wdrożenia Magento →Jeżeli obecny sklep sam w sobie nie nadaje się do dalszego rozwoju, dopinanie kolejnej integracji może tylko odsunąć właściwą decyzję. W takim przypadku najpierw warto ocenić stan platformy za pomocą bezpłatnego audytu wydajności i bezpieczeństwa.
Pytania
Od procesów i ustalenia właściciela danych. Najpierw trzeba ustalić, jakie informacje są potrzebne w Magento, gdzie powstają, który system za nie odpowiada oraz jak świeże muszą być.
Najczęściej są to produkty, ceny, stany, klienci, warunki handlowe, limity, zamówienia i statusy. Zakres zależy od modelu firmy.
Tak. Mamy doświadczenie z SAP ECC i S/4HANA. Konkretna architektura zależy od konfiguracji systemu i procesów danej organizacji.
Tak. Mamy doświadczenie z integracją Magento z Asseco Softlab, w tym w środowisku z dedykowanym API rozwijanym po stronie klienta i historycznym modelem danych wymagającym warstwy konwertującej.
Tak, mamy doświadczenie z systemami Comarch. Zakres prac zależy od wersji, rozszerzeń i sposobu wykorzystania systemu w konkretnej organizacji.
Tak. Podobnie jak przy innych ERP, architekturę ustalamy po rozpoznaniu procesów i dostępnych interfejsów.
Tak, mamy doświadczenie z integracjami obejmującymi Enova. Konkretne rozwiązanie zależy od zakresu danych i sposobu pracy firmy.
Nie. Dla każdego przepływu ustalamy wymaganą świeżość, wolumen i konsekwencje opóźnienia. Część danych wymaga szybkiej odpowiedzi, inne mogą być synchronizowane w tle.
Architekturę można zaprojektować tak, aby chwilowa niedostępność ERP nie powodowała utraty danych. W zależności od procesu wykorzystujemy kolejki, retry i mechanizmy kontrolujące stan przetwarzania.
Tak, o ile istnieje możliwość wymiany danych. Przy rozwiązaniach legacy często przydatna jest warstwa pośrednia, która mapuje i normalizuje dane zamiast dostosowywać całe Magento do historycznego modelu.
Nie zawsze. Gotowy konektor może pomóc przy standardowym procesie, ale customowe cenniki, wiele magazynów, własne statusy czy rozbudowany ERP często wymagają dodatkowej logiki.
Nie. ERP może odpowiadać np. za SKU, ceny i stany, a PIM za treści, atrybuty, tłumaczenia i media.
Zależy przede wszystkim od liczby przepływów, jakości danych, dostępnych interfejsów i stopnia customizacji systemu ERP. Zakres i harmonogram określamy po discovery.
Skąd pochodzą produkty, ceny i stany, gdzie trafiają zamówienia i które przepływy dziś powodują najwięcej problemów.
Odezwiemy się w ciągu 12 godzin od wysłania formularza.