Co zrobić, gdy ERP, PIM i Magento mają różne wartości tego samego parametru?

ERP mówi: kolor = grafit. PIM mówi: kolor = antracyt. W Magento ten sam produkt również ma przypisaną wartość koloru. Co powinien zobaczyć klient?

Problem nie polega na tym, że trzy systemy przechowują dane o tym samym produkcie. W rozbudowanym e-commerce to normalna sytuacja. Problem zaczyna się wtedy, gdy nie wiadomo, który system odpowiada za konkretną informację i co ma się wydarzyć, kiedy dwa źródła podają różne wartości.

Dlatego przy projektowaniu integracji ERP, PIM i Magento warto określić nie tylko ogólnego mastera danych produktowych, ale również odpowiedzialność za poszczególne pola i kierunki ich synchronizacji.

Dlaczego ERP, PIM i Magento mogą mieć różne dane o tym samym produkcie?

Ten sam produkt funkcjonuje jednocześnie w kilku procesach firmy.

ERP może potrzebować informacji do obsługi zakupów, produkcji, magazynu, logistyki czy sprzedaży. PIM może służyć do centralnego zarządzania i wzbogacania informacji produktowej oraz przygotowywania jej dla różnych kanałów. Magento przechowuje dane potrzebne do działania katalogu i sprzedaży w konkretnym kanale e-commerce.

Granice pomiędzy tymi systemami nie zawsze są jednak oczywiste.

Nazwa produktu może znajdować się zarówno w ERP, PIM, jak i Magento. To samo może dotyczyć wagi, ceny, statusu produktu, kategorii czy koloru.

Samo powielenie danych nie musi być błędem. System sprzedażowy potrzebuje przecież lokalnej kopii wielu informacji, żeby móc z nich korzystać.

Problem pojawia się wtedy, gdy nie wiadomo:

• gdzie dana informacja powstaje,
• gdzie można ją edytować,
• który system jest jej źródłem,
• które systemy tylko ją konsumują,
• co zrobić, jeśli pojawią się różne wartości.

Bez tych zasad integracja sama zaczyna rozstrzygać, która wartość jest „prawidłowa”.

ERP mówi „grafit”, PIM mówi „antracyt”. Czy naprawdę mamy konflikt?

Niekoniecznie.

Zanim zdecydujemy, która wartość powinna wygrać, trzeba sprawdzić, czy oba systemy rzeczywiście opisują tę samą informację.

Wyobraźmy sobie producenta mebli.

W ERP kolor wariantu może być zapisany jako:

GRF

To wewnętrzny kod wykorzystywany w procesach firmy.

W PIM ten sam kolor może mieć nazwę:

Antracyt

To nazwa przeznaczona dla klienta.

W niemieckiej wersji językowej może natomiast występować jako:

Anthrazit

Magento może otrzymać kod pozwalający jednoznacznie zidentyfikować wariant oraz odpowiednią etykietę przeznaczoną dla konkretnego sklepu lub wersji językowej.

W takim przypadku nie mamy trzech konkurujących ze sobą wartości.

Mamy kilka reprezentacji tej samej cechy używanych w różnych kontekstach.

Dlatego pytanie:

„ERP ma grafit, a PIM antracyt – która wartość powinna wygrać?”

może być postawione zbyt wcześnie.

Najpierw trzeba ustalić:

co dokładnie oznacza każde z tych pól?

Kod wartości i etykieta dla klienta to nie zawsze ta sama informacja

To szczególnie ważne przy atrybutach takich jak kolor, materiał, kolekcja czy rozmiar.

W modelu danych można rozdzielić:

kod: ANT_01

etykieta PL: Antracyt

etykieta EN: Anthracite

etykieta DE: Anthrazit

Kod może być stabilnym identyfikatorem wykorzystywanym przez integracje. Etykiety mogą natomiast zmieniać się zależnie od języka, rynku albo sposobu prezentacji produktu.

To znacznie bezpieczniejsze niż próba identyfikowania wartości wyłącznie po tekście widocznym dla użytkownika.

Zmiana nazwy „grafit” na „antracyt” nie musi wtedy oznaczać zmiany samego wariantu produktu.

Zmienia się sposób jego prezentacji.

Kiedy rzeczywiście dochodzi do konfliktu danych?

Prawdziwy problem pojawia się wtedy, gdy dwa systemy mogą niezależnie zmieniać tę samą informację biznesową.

Załóżmy, że nazwa marketingowa koloru jest zarządzana w PIM.

Pracownik zmienia:

Grafit → Antracyt

PIM wysyła zmianę do Magento.

Kilka minut później uruchamia się integracja ERP → Magento, a ERP nadal posiada wartość „Grafit”.

Jeżeli obie integracje mają prawo nadpisywać to samo pole, Magento ponownie zapisuje „Grafit”.

Użytkownik PIM zrobił wszystko prawidłowo, synchronizacja również technicznie wykonała swoje zadanie, a mimo to w sklepie pojawiła się niewłaściwa z punktu widzenia przyjętego procesu wartość.

Problem leży w architekturze odpowiedzialności za dane.

Dlaczego „ostatnia aktualizacja wygrywa” nie powinna zastępować reguł biznesowych?

Jednym ze sposobów automatycznego rozwiązywania konfliktów jest podejście Last Write Wins: wygrywa wartość uznana za najnowszą.

Taka strategia rzeczywiście istnieje w systemach informatycznych i w określonych zastosowaniach jest świadomie wykorzystywana. Nie powinna jednak automatycznie zastępować reguł biznesowych dotyczących danych produktowych.

Jeżeli PIM odpowiada za nazwę marketingową produktu, fakt, że ERP przesłał swoją wartość trzy minuty później, nie powinien sam w sobie dawać ERP pierwszeństwa.

Czas aktualizacji odpowiada na pytanie:

która zmiana nastąpiła później?

Nie odpowiada natomiast na pytanie:

który system ma prawo decydować o tej informacji?

W przypadku danych produktowych te dwie rzeczy nie muszą być tym samym.

Zamiast jednego mastera dla produktu ustal odpowiedzialność za konkretne dane

W osobnym artykule wyjaśnialiśmy już, gdzie powinien znajdować się master danych produktowych: w ERP, PIM czy Magento.

Przy projektowaniu konkretnej integracji trzeba jednak zejść poziom niżej.

Często mówi się, że ERP, PIM albo Magento jest „masterem produktu”. To przydatny skrót, ale produkt składa się z wielu informacji, a odpowiedzialność za nie może być rozłożona pomiędzy kilka systemów.

Przykładowo:

Dane	Potencjalne źródło	Przykładowe zastosowanie
SKU / kod produktu	ERP	identyfikacja produktu w procesach firmy
Stan magazynowy	ERP / WMS	dostępność wynikająca z gospodarki magazynowej
Dane logistyczne	ERP / WMS	realizacja procesów magazynowych i dostaw
Opis marketingowy	PIM	prezentacja produktu w kanałach sprzedaży
Tłumaczenia	PIM	obsługa wielu języków i rynków
Parametry produktowe	PIM lub inne źródło domenowe	wzbogacanie i dystrybucja danych produktowych
Materiały produktowe	PIM / DAM	zdjęcia, dokumenty i inne materiały
Wybrane dane merchandisingowe	Magento	sposób prezentacji i sprzedaży w konkretnym kanale
Dane specyficzne dla sklepu	Magento	ustawienia obowiązujące tylko w danym kanale

To nie jest gotowa architektura, którą można zastosować w każdej firmie.

W jednym przedsiębiorstwie cena może pochodzić z ERP. W innym może istnieć osobny system pricingowy. Jeszcze gdzie indziej PIM będzie przechowywał część danych, które w innej organizacji pozostają w ERP.

Znaczenie ma zasada:

dla danych współdzielonych pomiędzy systemami trzeba świadomie określić źródło oraz zasady ich modyfikacji i dystrybucji.

Master, miejsce edycji i konsument danych to trzy różne rzeczy

Warto rozdzielić jeszcze trzy pojęcia.

Pierwsze to źródło prawdy dla danego pola – system, którego wartość jest traktowana jako obowiązująca w określonym procesie.

Drugie to miejsce edycji – system, w którym użytkownik faktycznie powinien tę informację zmieniać.

Trzecie to konsument danych – system, który potrzebuje tej informacji do własnego działania.

Magento może więc posiadać opis produktu, wyświetlać go klientowi i przechowywać go w swoim katalogu, ale w konkretnej architekturze źródłem tego opisu może pozostawać PIM.

Wtedy typowy przepływ wygląda tak:

PIM → Magento

Magento potrzebuje danych, ale nie musi być miejscem, w którym powstają.

Ta różnica ma duże znaczenie przy projektowaniu paneli administracyjnych i integracji.

Jeżeli pole ma być zarządzane wyłącznie w PIM, trzeba również zdecydować, co zrobić z możliwością jego ręcznej edycji w Magento. Sama obecność pola w panelu administracyjnym nie powinna automatycznie oznaczać, że jest ono równorzędnym źródłem danych.

Jeżeli w architekturze PIM pełni centralną rolę w zarządzaniu informacją produktową, trzeba również określić, jak Pimcore wymienia dane z ERP, Magento i innymi systemami e-commerce.

Kierunek synchronizacji jest równie ważny jak źródło danych

Załóżmy, że opis marketingowy powstaje w PIM.

Najprostszy model wygląda wtedy następująco:

PIM → Magento

PIM publikuje zmianę, a Magento ją konsumuje.

Nie oznacza to automatycznie, że potrzebujemy również:

Magento → PIM

Dwukierunkowa synchronizacja powinna wynikać z konkretnej potrzeby biznesowej.

Jeżeli dwa systemy mogą modyfikować tę samą informację, trzeba dodatkowo określić zasady rozwiązywania konfliktów. Im więcej równorzędnych miejsc zapisu, tym więcej scenariuszy trzeba obsłużyć.

Dlatego przy projektowaniu integracji warto osobno określić:

kto zapisuje, kto publikuje, kto konsumuje i kto może nadpisywać daną wartość.

Ma to szczególne znaczenie przy projektowaniu Magento 2 połączonego z ERP, PIM, WMS i innymi systemami. Samo połączenie API nie rozwiązuje problemu odpowiedzialności za dane.

Jak przygotować field ownership matrix przed integracją?

Do uporządkowania odpowiedzialności wystarczy na początku prosta tabela.

Może wyglądać tak:

Pole	Źródło	Miejsce edycji	Odbiorca	Kierunek	Edycja w Magento
SKU	ERP	ERP	PIM, Magento	ERP → PIM/Magento	Nie
Stan magazynowy	ERP/WMS	ERP/WMS	Magento	ERP/WMS → Magento	Nie
Opis PL	PIM	PIM	Magento	PIM → Magento	Nie
Opis DE	PIM	PIM	Magento DE	PIM → Magento	Nie
Etykieta koloru	PIM	PIM	Magento	PIM → Magento	Nie
Ustawienie merchandisingowe	Magento	Magento	Magento	lokalnie	Tak

To dopiero początek.

W większej integracji warto określić również:

• identyfikator pola po obu stronach integracji,
• typ danych i dozwolone wartości,
• mapowanie wartości pomiędzy systemami,
• zakres danych, np. język, sklep lub rynek,
• sposób obsługi wartości pustej,
• sposób obsługi usunięcia wartości,
• regułę konfliktu,
• częstotliwość lub sposób wyzwalania synchronizacji,
• zachowanie podczas błędu,
• odpowiedzialność biznesową za dane.

Dzięki temu programista nie musi sam decydować, co oznacza brak wartości albo który system powinien wygrać.

Uważaj na wartości puste

Konflikt nie zawsze wygląda tak:

ERP: grafit

PIM: antracyt

Czasami wygląda tak:

ERP: grafit

PIM: brak wartości

I tutaj pojawia się ważne pytanie:

co oznacza brak wartości?

Może oznaczać:

• usuń dotychczasową wartość,
• informacja nie została jeszcze uzupełniona,
• tego pola nie dotyczy dany produkt,
• źródło nie przesłało tego pola w danej aktualizacji.

To są różne sytuacje.

Integracja nie powinna samodzielnie zakładać, że brak pola, null, pusty tekst i pole świadomie wyczyszczone oznaczają dokładnie to samo.

Reguły powinny wynikać z kontraktu integracyjnego i modelu danych.

Nie zapominaj o języku, rynku i kanale

Jest jeszcze jeden przypadek, który łatwo przeoczyć.

Dwie różne wartości nie muszą oznaczać konfliktu, jeżeli obowiązują w innym zakresie.

Przykładowo produkt może mieć:

PL: Antracyt

DE: Anthrazit

Podobnie różne informacje mogą obowiązywać dla różnych sklepów, rynków lub kanałów sprzedaży.

Dlatego w field ownership matrix samo pole „nazwa produktu” może być niewystarczające.

Trzeba czasami określić:

nazwa produktu + język + rynek + kanał

Dopiero wtedy wiadomo, czy dwie wartości rzeczywiście są ze sobą sprzeczne.

Ma to szczególne znaczenie w architekturze Magento Multistore wykorzystywanej do sprzedaży na wielu rynkach, gdzie część danych może być wspólna, a część zależeć od konkretnej wersji sklepu.

Co zrobić, gdy ERP, PIM i Magento już nadpisują sobie dane?

W istniejącym e-commerce rzadko zaczynamy od pustej kartki.

Integracje już działają, część danych jest edytowana ręcznie, istnieją importy, zadania cykliczne, API i procesy, o których wie tylko część zespołu.

Wtedy warto zacząć od inwentaryzacji przepływów.

1. Znajdź dane występujące w kilku systemach

Najpierw trzeba zidentyfikować pola, które są przechowywane lub synchronizowane w więcej niż jednym miejscu.

Szczególnej uwagi wymagają te, które mogą być edytowane w kilku systemach.

2. Sprawdź rzeczywiste miejsca edycji

Dokumentacja może wskazywać, że opis jest zarządzany w PIM.

Jeżeli jednak e-commerce managerowie regularnie poprawiają go bezpośrednio w Magento, rzeczywisty proces wygląda inaczej.

Trzeba zdecydować, czy zachowujemy taki model, czy eliminujemy jedno z miejsc edycji.

3. Rozdziel pola, które tylko wyglądają na identyczne

„Kolor” w ERP i „kolor” w sklepie mogą mieć inne znaczenie.

Zamiast ustalać, który z nich wygrywa, czasami trzeba poprawić model danych i mapowanie.

4. Wyznacz źródło i odpowiedzialność

Dla każdego współdzielonego pola trzeba określić, który system posiada wartość obowiązującą w danym kontekście i gdzie użytkownik powinien ją zmieniać.

5. Ustal kierunki synchronizacji

Nie każda informacja musi wracać do systemu, z którego nie pochodzi.

Jeżeli Magento konsumuje opis z PIM, nie oznacza to automatycznie potrzeby wysyłania opisu z Magento z powrotem do PIM.

6. Zdefiniuj obsługę wyjątków

Co dzieje się, gdy system źródłowy jest niedostępny?

Co oznacza pusta wartość?

Co robimy z wartością, której nie można zmapować?

Czy błąd zatrzymuje cały import, czy tylko jeden produkt?

Czy poprzednia poprawna wartość pozostaje w Magento?

Czy ktoś zostanie poinformowany o błędzie?

To również jest część projektu integracji.

7. Zapewnij możliwość sprawdzenia, skąd wzięła się wartość

Gdy pojawia się problem, zespół powinien móc ustalić, skąd pochodziła zmiana i kiedy została przetworzona.

Logowanie zmian, identyfikatory komunikatów, monitoring integracji i historia synchronizacji potrafią znacząco skrócić analizę problemu.

Sama zasada ownership zapobiega wielu konfliktom. Obserwowalność pozwala natomiast znaleźć przyczynę, gdy konflikt mimo wszystko się pojawi.

Dlaczego warto zrobić to przed rozpoczęciem developmentu?

Field ownership matrix może być zwykłą tabelą.

Ale odpowiada na pytania, które podczas implementacji i tak będzie musiał ktoś rozstrzygnąć:

Skąd pobieramy wartość?

Gdzie użytkownik może ją zmienić?

Czy pusta wartość usuwa poprzednią?

Czy Magento może nadpisać dane?

Czy wartość jest globalna, czy zależy od rynku?

Co zrobić, gdy przyjdą dwie różne wartości?

Jeżeli nie odpowie na nie biznes i architektura rozwiązania, odpowiedzi zaczną powstawać podczas developmentu.

A wtedy decyzja biznesowa może przypadkiem stać się fragmentem kodu, o którego istnieniu po kilku miesiącach nikt już nie pamięta.

Ustal odpowiedzialność za dane, zanim połączysz systemy

ERP, PIM i Magento mogą przechowywać informacje dotyczące tego samego produktu. Nie oznacza to jednak, że każdy z tych systemów powinien mieć takie samo prawo do ich zmiany.

Przed wdrożeniem integracji warto ustalić dla współdzielonych danych:

• co dokładnie oznacza dane pole,
• jaki ma identyfikator,
• który system jest jego źródłem,
• gdzie można je edytować,
• które systemy je konsumują,
• w jakim kierunku przepływa,
• czy zależy od języka, rynku lub kanału,
• co oznacza brak wartości,
• jak obsłużyć konflikt i błąd synchronizacji.

Dopiero wtedy warto przenieść te zasady do integracji.

Jeżeli ERP mówi „grafit”, PIM „antracyt”, a Magento raz pokazuje jedno, raz drugie, problem prawdopodobnie nie zaczyna się w Magento. Najpierw trzeba sprawdzić model danych, ownership oraz kierunki przepływu informacji pomiędzy systemami.

Jeżeli w Twoim e-commerce ERP, PIM, Magento lub inne systemy zaczynają nadpisywać sobie dane, skontaktuj się z Aurora Creation. Możemy przeanalizować przepływy danych i zaprojektować zasady integracji tak, aby było wiadomo, skąd pochodzi każda kluczowa informacja i który system może ją zmienić.

FAQ: synchronizacja danych między ERP, PIM i Magento

Co zrobić, gdy ERP i PIM mają różne wartości tego samego parametru?

Najpierw trzeba sprawdzić, czy oba systemy rzeczywiście opisują tę samą informację. Jeżeli tak, należy ustalić źródło prawdy i regułę synchronizacji dla tego pola. Jeżeli wartości pełnią różne funkcje, np. kod operacyjny i nazwa marketingowa, lepszym rozwiązaniem może być rozdzielenie ich w modelu danych.

Który system powinien być masterem danych produktowych?

Nie ma jednego podziału właściwego dla każdej architektury. ERP, PIM, Magento i inne systemy mogą odpowiadać za różne grupy danych, dlatego przy projektowaniu integracji warto określić odpowiedzialność również na poziomie konkretnych pól. Więcej na ten temat opisaliśmy w artykule „Gdzie powinien być master danych produktowych: ERP, PIM czy Magento?”.

Czy Magento może być źródłem danych produktowych?

Tak. Magento może być źródłem wybranych danych zarządzanych specyficznie dla kanału e-commerce, jeżeli tak została zaprojektowana architektura. Jednocześnie może przechowywać kopie danych, których źródłem jest ERP, PIM lub inny system.

Czy PIM powinien być masterem wszystkich parametrów produktu?

Nie musi. PIM jest przeznaczony do zarządzania i wzbogacania informacji produktowej, ale konkretne źródła danych zależą od architektury firmy. Część parametrów może pochodzić z ERP, systemu produkcyjnego, PLM lub innego źródła i dopiero trafiać do PIM.

Czy dane między ERP, PIM i Magento powinny być synchronizowane w obie strony?

Tylko wtedy, gdy istnieje konkretna potrzeba biznesowa i zdefiniowane zasady zapisu oraz konfliktów. Jeżeli jeden system jest źródłem pola, pozostałe często mogą jedynie konsumować jego wartość.

Czym jest field ownership matrix?

Field ownership matrix to tabela opisująca odpowiedzialność za poszczególne dane pomiędzy systemami. Może określać źródło wartości, miejsce edycji, odbiorców, kierunek synchronizacji, zakres danych oraz sposób obsługi konfliktów i pustych wartości.

Czy „ostatnia aktualizacja wygrywa” jest błędną metodą synchronizacji?

Nie jest błędna sama w sobie. Last Write Wins jest stosowaną strategią rozwiązywania konfliktów. Problem pojawia się wtedy, gdy czas aktualizacji zastępuje regułę biznesową, mimo że jeden z systemów powinien być nadrzędnym źródłem konkretnej informacji.

Co powinna zrobić integracja, gdy PIM zwróci pustą wartość?

Powinno to wynikać z wcześniej ustalonych zasad integracji. Brak pola, wartość null, pusty tekst oraz świadome usunięcie wartości mogą oznaczać różne operacje i nie powinny być automatycznie traktowane tak samo.