Gdzie powinien być master danych produktowych ERP, PIM czy Magento

Gdzie powinien być master danych produktowych: ERP, PIM czy Magento?

E-commerce

Jak podzielić odpowiedzialność za dane w e-commerce?

ERP przechowuje produkt. PIM przechowuje produkt. Magento również przechowuje produkt. Problem zaczyna się wtedy, gdy każdy z tych systemów może zmienić tę samą informację, a integracje przesyłają dane w kilku kierunkach.

Dlatego zamiast wybierać jeden system jako master całego produktu, warto ustalić źródło prawdy osobno dla poszczególnych grup danych. SKU może pochodzić z ERP, opis z PIM, a ustawienia sprzedaży internetowej z Magento.

Co właściwie oznacza „master danych produktowych”?

Master to system, w którym znajduje się obowiązująca wersja konkretnej informacji.

Jeżeli masterem nazwy produktu jest PIM, nazwa może być przesłana do Magento, marketplace’u czy katalogu produktowego, ale nie powinna być później niezależnie poprawiana w każdym z tych miejsc.

Jeżeli ktoś zmieni ją bezpośrednio w Magento, przy kolejnej synchronizacji PIM może ponownie przesłać swoją wersję. Efekt jest dobrze znany zespołom pracującym z rozbudowanymi integracjami: ktoś poprawia dane, po kilku godzinach zmiana znika i zaczyna się szukanie błędu w sklepie.

Tymczasem technicznie wszystko może działać poprawnie. Problem znajduje się w architekturze danych.

Dla każdego istotnego pola trzeba ustalić:

  • gdzie dana powstaje,
  • gdzie może być edytowana,
  • który system posiada wersję obowiązującą,
  • które systemy są jej odbiorcami,
  • w jakim kierunku odbywa się synchronizacja,
  • co powinno się wydarzyć w przypadku błędu lub konfliktu danych.

Dopiero taki podział pozwala sensownie projektować integracje.

Czy cały produkt powinien mieć jeden system master

Czy cały produkt powinien mieć jeden system master?

Niekoniecznie.

Produkt widoczny w sklepie internetowym składa się z wielu rodzajów informacji, które są wykorzystywane przez różne działy firmy.

Dla działu operacyjnego ważne będą indeks, jednostka miary czy status produktu w ERP.

Marketing potrzebuje nazw handlowych, zdjęć, opisów, parametrów, instrukcji oraz tłumaczeń.

Zespół e-commerce zarządza tym, jak produkt jest sprzedawany i prezentowany w konkretnym kanale.

Próba umieszczenia całej odpowiedzialności w jednym systemie często prowadzi do sytuacji, w której narzędzie zaczyna obsługiwać procesy, do których nie zostało stworzone.

Znacznie praktyczniejszy jest master przypisany do konkretnego typu danych.

ERP jako master danych produktowych

ERP jest zwykle najbliżej operacyjnej części przedsiębiorstwa. Produkt często pojawia się w nim wcześniej niż w sklepie internetowym, ponieważ musi istnieć jako indeks używany przy produkcji, zakupach, magazynowaniu, fakturowaniu czy księgowości.

Dlatego ERP dobrze sprawdza się jako źródło podstawowych danych identyfikujących produkt.

Najczęściej są to:

  • SKU lub inny indeks produktu,
  • jednostka miary,
  • stawka VAT lub informacje podatkowe,
  • status operacyjny produktu,
  • podstawowe dane logistyczne,
  • wybrane dane handlowe,
  • ceny bazowe lub cenniki, jeśli to ERP odpowiada za politykę cenową.

W firmach produkcyjnych właśnie ERP bardzo często powinien inicjować utworzenie produktu.

Jeżeli powstaje nowe SKU, informacja może następnie trafić do PIM, gdzie produkt jest wzbogacany o dane potrzebne w sprzedaży.

Czego lepiej nie prowadzić w ERP?

Sam fakt, że ERP posiada pole „opis produktu”, nie oznacza jeszcze, że powinien zostać masterem opisów wykorzystywanych przez e-commerce.

Problem pojawia się szczególnie przy:

  • wielu wersjach językowych,
  • dużej liczbie parametrów,
  • rozbudowanych opisach marketingowych,
  • zdjęciach i filmach,
  • instrukcjach i certyfikatach,
  • różnych zestawach informacji dla różnych kanałów,
  • relacjach między produktami.

ERP może przechowywać część tych danych, ale zarządzanie nimi zaczyna się komplikować wraz ze wzrostem katalogu i liczby kanałów sprzedaży.

PIM jako master informacji produktowej

System PIM znajduje się pomiędzy systemami operacyjnymi a kanałami sprzedaży.

Jego zadaniem jest zebranie informacji o produkcie, uporządkowanie ich, wzbogacenie i przygotowanie do publikacji.

W typowej architekturze PIM może odpowiadać za:

  • nazwę handlową produktu,
  • krótki i długi opis,
  • parametry techniczne,
  • cechy wykorzystywane przez filtry,
  • tłumaczenia,
  • zdjęcia i inne multimedia,
  • dokumenty produktowe,
  • relacje między produktami,
  • dane charakterystyczne dla konkretnych rynków,
  • kompletność informacji przed publikacją.

Dzięki temu marketing, e-commerce i inne osoby pracujące nad ofertą nie muszą edytować produktu osobno w Magento, na marketplace i w kolejnych plikach eksportowych.

Zmiana powstaje w jednym miejscu, a następnie trafia do odpowiednich kanałów.

Taką rolę może pełnić między innymi Pimcore, który może łączyć zarządzanie informacjami produktowymi z zasobami cyfrowymi i dystrybucją danych do kolejnych systemów.

PIM nie powinien automatycznie przejmować wszystkiego

Wdrożenie PIM nie oznacza, że każda informacja dotycząca produktu musi od tej chwili pochodzić właśnie z niego.

Jeżeli ceny są obliczane w ERP, nie ma powodu ręcznie przepisywać ich do PIM.

Jeżeli aktualny stan magazynowy pochodzi z WMS, może trafić bezpośrednio do platformy e-commerce.

PIM powinien mieć jasno określoną odpowiedzialność tak samo jak każdy pozostały element architektury.

Magento jako master danych związanych ze sprzedażą online

Magento potrafi przechowywać bardzo dużo informacji produktowych. Można w nim tworzyć atrybuty, opisy, warianty, kategorie, ceny czy relacje między produktami.

Techniczna możliwość przechowywania danych nie oznacza jednak, że Magento powinno być ich źródłem.

Jeżeli sklep jest jednym z kilku kanałów, przechowywanie głównej wersji opisu wyłącznie w Magento szybko powoduje problem. Marketplace, aplikacja, katalog produktowy czy kolejny sklep nie mają wtedy wspólnego źródła informacji.

Magento dobrze sprawdza się natomiast jako master danych, które istnieją wyłącznie ze względu na konkretny kanał sprzedaży.

W zależności od architektury mogą to być:

  • widoczność produktu w konkretnym sklepie,
  • przypisanie do wybranych website’ów i store view,
  • wybrane ustawienia merchandisingowe,
  • reguły promocyjne,
  • ustawienia wyszukiwania,
  • wybrane relacje upsell i cross-sell,
  • konfiguracja sprzedaży charakterystyczna wyłącznie dla danego storefrontu.

Nie wszystkie firmy powinny stosować dokładnie taki podział. Jeżeli na przykład relacje produktowe są wykorzystywane jednocześnie przez sklep, marketplace i katalog, znacznie lepszym masterem może być PIM.

Decyzję trzeba więc podejmować na poziomie konkretnego pola.

Jak może wyglądać podział mastera między ERP, PIM i Magento?

Przykładowa architektura dla producenta sprzedającego online może wyglądać następująco:

DANEMASTERODBIORCYKIERUNEK PRZEPŁYWU
SKU / indeks produktuERPPIM, Magento, WMS, marketplaceERP → pozostałe systemy
jednostka miaryERPPIM, MagentoERP → PIM / Magento
status operacyjny produktuERPPIM, MagentoERP → PIM → Magento
stawka VATERPMagentoERP → Magento
nazwa handlowaPIMMagento, marketplace, katalogPIM → kanały
opis produktuPIMMagento, marketplace, katalogPIM → kanały
parametry technicznePIMMagento, marketplace, katalogPIM → kanały
tłumaczeniaPIMsklepy na poszczególnych rynkachPIM → kanały
zdjęcia i dokumentyPIM / DAMMagento, marketplace, katalogPIM → kanały
ceny bazowe i cennikiERP / system cenowyMagento, B2Bźródło ceny → kanały
stan magazynowyWMS / ERPMagento, marketplaceWMS / ERP → kanały
promocje e-commerceMagento lub system promocjisklepsystem sprzedażowy → storefront
ustawienia specyficzne dla sklepuMagentostorefrontMagento → frontend

To przykład, nie uniwersalny schemat do skopiowania.

W jednej firmie kategorie będą zarządzane w PIM, ponieważ ta sama klasyfikacja zasila kilka kanałów. W innej struktura kategorii Magento będzie tworzona specjalnie pod zachowania klientów w konkretnym sklepie.

Podobnie może wyglądać sytuacja z SEO, relacjami produktowymi czy statusem publikacji.

Właśnie dlatego tabela powinna powstać dla konkretnej organizacji.

Najpierw tabela DANE → MASTER → ODBIORCY → KIERUNKI PRZEPŁYWU, później API

Przy projektowaniu integracji łatwo zacząć od technologii.

Jakie endpointy przygotować? REST czy GraphQL? Jak często uruchamiać synchronizację? Czy przesyłać cały produkt, czy wyłącznie zmienione pola?

To są ważne pytania, ale pojawiają się za wcześnie, jeżeli nie wiadomo jeszcze, kto jest właścicielem danych.

Najpierw warto przygotować mapę odpowiedzialności.

1. Spisz dane uczestniczące w integracji

Nie wystarczy pozycja „produkt”.

Trzeba zejść niżej:

  • SKU,
  • nazwa,
  • opis,
  • EAN,
  • stawka VAT,
  • cena,
  • stan,
  • parametry,
  • zdjęcia,
  • kategorie,
  • tłumaczenia,
  • status sprzedaży,
  • widoczność,
  • dokumentacja.

Im dokładniejsza lista, tym mniej niejasności pojawi się później.

2. Wskaż master dla każdej informacji

Każde pole powinno mieć jedno źródło obowiązującej wartości.

Jeżeli nazwą produktu zarządza PIM, ERP i Magento nie powinny samodzielnie zmieniać jej bez ustalonego procesu.

3. Określ odbiorców

Nazwa może trafiać do Magento, marketplace’u i katalogu PDF.

Cena może być potrzebna Magento i platformie B2B.

Stan magazynowy może zasilać sklep, marketplace oraz portal handlowca.

Lista odbiorców pokazuje, gdzie rzeczywiście potrzebna jest synchronizacja.

4. Ustal kierunek przepływu

Szczególnie ostrożnie trzeba podchodzić do synchronizacji dwukierunkowych.

Jeżeli Magento pobiera opis z PIM, a następnie PIM pobiera opis z Magento, pojawia się pytanie: która zmiana jest ważniejsza?

Bez jednoznacznej odpowiedzi łatwo zbudować mechanizm, w którym systemy nadpisują się nawzajem.

5. Ustal, co dzieje się w przypadku błędu

Co ma zrobić Magento, jeżeli PIM nie posiada wymaganej wartości?

Czy produkt powinien zostać opublikowany?

Czy pozostaje niewidoczny?

Czy ktoś otrzymuje informację o braku danych?

Architektura danych powinna opisywać również takie przypadki.

Dopiero wtedy można sensownie projektować integrację Pimcore z ERP i e-commerce, API, kolejki, harmonogramy synchronizacji i obsługę błędów.

Co się dzieje, gdy master danych nie jest ustalony?

Pierwsze problemy często wyglądają niegroźnie.

Marketing poprawia nazwę produktu w Magento. W nocy działa import z ERP i przywraca wcześniejszą wersję.

Ktoś zmienia parametr w PIM, ale integracja pobiera tę samą wartość z ERP godzinę później.

Administrator sklepu wyłącza produkt, lecz kolejny import ponownie go aktywuje.

Każdy zespół wykonuje swoją pracę prawidłowo. System również robi dokładnie to, do czego został zaprogramowany. Brakuje jedynie decyzji, która informacja jest nadrzędna.

Z czasem pojawiają się kolejne symptomy:

  • te same dane są poprawiane w kilku systemach,
  • pracownicy nie wiedzą, gdzie należy wykonać zmianę,
  • po synchronizacji wracają stare wartości,
  • część integracji działa w obie strony bez wyraźnego powodu,
  • pojawiają się kolejne wyjątki w kodzie,
  • dane w sklepie różnią się od danych na marketplace,
  • nowe produkty wymagają ręcznego sprawdzania kilku systemów,
  • każda większa zmiana katalogu wymaga udziału programisty.

To zwykle nie jest pojedynczy błąd integracji. To sygnał, że trzeba uporządkować odpowiedzialność za dane.

Czy Magento może być głównym masterem produktu?

Może.

Przy prostym e-commerce taki model bywa całkowicie wystarczający.

Jeżeli firma posiada jeden sklep, jeden rynek, stosunkowo niewielki katalog i nie dystrybuuje danych produktowych do wielu kanałów, dodawanie kolejnego systemu nie musi przynieść korzyści.

Magento może wtedy przechowywać większość informacji potrzebnych do sprzedaży.

Sytuacja zmienia się wraz ze wzrostem skali.

Jeżeli dochodzą:

  • kolejne wersje językowe,
  • marketplace’y,
  • osobny B2B i B2C,
  • kilka marek,
  • tysiące produktów i wariantów,
  • rozbudowana dokumentacja techniczna,
  • wielu użytkowników pracujących nad katalogiem,

platforma sprzedażowa zaczyna pełnić jednocześnie rolę sklepu, PIM-u, repozytorium materiałów i narzędzia workflow.

Wtedy warto rozważyć oddzielenie zarządzania informacją produktową od samej sprzedaży.

Kiedy producent powinien rozważyć PIM?

Sam fakt posiadania ERP i Magento nie oznacza jeszcze, że firma potrzebuje PIM.

Sygnałem jest raczej sposób pracy z danymi.

PIM zaczyna mieć uzasadnienie, gdy ten sam produkt trzeba przygotowywać dla wielu odbiorców, a zarządzanie informacją wymaga coraz większej liczby ręcznych operacji.

Typowe sytuacje to:

  • produkt występuje w wielu wersjach językowych,
  • firma sprzedaje na kilku rynkach,
  • oprócz sklepu obsługuje marketplace’y, katalogi lub portale partnerskie,
  • jeden produkt posiada dziesiątki parametrów,
  • marketing pracuje na zdjęciach, filmach, instrukcjach i certyfikatach,
  • dane pochodzą z kilku działów firmy,
  • trudno sprawdzić, czy produkt jest kompletny przed publikacją,
  • zmiana informacji wymaga edycji kilku systemów.

W takim układzie Pimcore dla e-commerce może pełnić centralną warstwę odpowiedzialną za informację produktową, podczas gdy ERP nadal zarządza danymi operacyjnymi, a Magento procesem sprzedaży.

Dobry master danych skraca pracę przy każdym kolejnym kanale

Porządek w danych może długo pozostawać niewidoczny dla klienta końcowego. Jego znaczenie widać dopiero wtedy, gdy firma chce zrobić coś szybciej.

Uruchomić nową wersję językową.

Wejść na marketplace.

Zmienić jednocześnie parametry kilku tysięcy produktów.

Przygotować nową markę.

Uruchomić dodatkowy sklep B2B.

Jeżeli każde pole ma określone źródło, nowy kanał przede wszystkim odbiera przygotowany zestaw danych.

Jeżeli master nie jest określony, przy każdym kolejnym kanale trzeba ponownie ustalać, skąd pobrać nazwę, skąd opis, która cena jest właściwa i gdzie znajduje się aktualne zdjęcie.

Różnica zaczyna być widoczna również na stronie sklepu. Spójne dane oznaczają mniej błędnych parametrów, brakujących zdjęć, starych opisów czy rozbieżności pomiędzy wersjami językowymi. Dla klienta są to drobne elementy, ale właśnie na ich podstawie ocenia wiarygodność oferty.

Jak ustalić master danych przed kolejnym wdrożeniem lub integracją?

Najlepiej nie zaczynać od pytania „czy masterem ma być ERP, PIM czy Magento?”.

Trzeba rozłożyć produkt na dane, które rzeczywiście przepływają między systemami.

Dla każdego z nich ustalić:

DANE → MASTER → ODBIORCY → KIERUNKI PRZEPŁYWU

Dopiero później warto projektować API i logikę synchronizacji.

ERP może odpowiadać za indeks i dane operacyjne. PIM za informację produktową. Magento za elementy związane wyłącznie ze sprzedażą internetową. WMS za stan magazynowy. Osobny system może obliczać ceny.

Taki podział jest znacznie bezpieczniejszy niż próba znalezienia jednego systemu, który będzie „rządził całym produktem”.

Podsumowanie: ERP, PIM czy Magento?

Nie ma jednej poprawnej odpowiedzi dla całego produktu.

W dobrze zaprojektowanej architekturze każdy rodzaj danych ma konkretnego właściciela.

ERP najczęściej prowadzi dane operacyjne. PIM zarządza informacją produktową i przygotowuje ją do kolejnych kanałów. Magento odpowiada za sprzedaż i dane charakterystyczne dla konkretnego sklepu.

Najważniejsze, aby ta odpowiedzialność była ustalona przed stworzeniem integracji.

Jeżeli obecnie dane produktowe są rozproszone między ERP, PIM, Magento, arkuszami i innymi systemami, możemy pomóc uporządkować źródła danych, kierunki przepływu i sposób ich synchronizacji.

FAQ:

Co to jest master danych produktowych?

Master danych produktowych to system będący głównym źródłem konkretnej informacji o produkcie. Jeżeli PIM jest masterem opisu produktu, to właśnie znajdująca się w nim wersja powinna być traktowana jako obowiązująca i przesyłana do pozostałych systemów.

Czy ERP powinien być masterem danych produktowych?

ERP najczęściej powinien być źródłem danych operacyjnych, takich jak SKU, jednostka miary, VAT, status produktu czy wybrane dane logistyczne. Nie musi jednak odpowiadać za opisy, zdjęcia, tłumaczenia czy inne informacje wykorzystywane przede wszystkim w sprzedaży i marketingu.

Kiedy PIM powinien być masterem danych produktowych?

PIM sprawdza się jako master nazw handlowych, opisów, parametrów, zdjęć, dokumentów i tłumaczeń. Jego znaczenie rośnie szczególnie wtedy, gdy producent posiada dużą ofertę, kilka kanałów sprzedaży, wiele wersji językowych lub sprzedaje produkty na kilku rynkach.

Czy Magento może być masterem danych produktowych?

Tak. Przy prostym modelu sprzedaży Magento może być głównym miejscem zarządzania dużą częścią katalogu. Przy bardziej rozbudowanej architekturze lepiej pozostawić w Magento przede wszystkim dane charakterystyczne dla konkretnego kanału sprzedaży, a informacje produktowe prowadzić w PIM lub innych systemach źródłowych.

Czy jeden produkt może mieć kilka systemów master?

Tak, ponieważ master powinien być określany dla konkretnego rodzaju danych, a nie dla produktu jako całości. SKU może pochodzić z ERP, opis z PIM, stan magazynowy z WMS, a ustawienia widoczności produktu z Magento.

Gdzie powinny być przechowywane ceny produktów?

Zależy to od sposobu zarządzania cenami w firmie. Masterem może być ERP, osobny system cenowy lub Magento. Najważniejsze jest jednoznaczne ustalenie, który system odpowiada za obliczenie obowiązującej ceny, a które systemy jedynie ją odbierają.

Gdzie powinien być master stanów magazynowych?

Najczęściej źródłem stanów magazynowych jest ERP lub WMS, ponieważ to te systemy obsługują fizyczny przepływ towaru. Magento powinno wtedy otrzymywać informację o dostępności, a nie samodzielnie tworzyć nadrzędny stan magazynowy.

Jak ustalić master danych przed integracją ERP, PIM i Magento?

Najpierw należy spisać wszystkie dane przesyłane pomiędzy systemami, a następnie dla każdego pola określić master, odbiorców i kierunek przepływu. Dobrą podstawą jest tabela: DANE → MASTER → ODBIORCY → KIERUNKI PRZEPŁYWU. Dopiero po jej przygotowaniu warto projektować API i mechanizmy synchronizacji.