Migracja PIM: jak przenieść dane produktowe do nowego systemu

Wdrożenie PIM jest opisane w kilkuset artykułach. Migracja z jednego systemu PIM do drugiego prawie w żadnym, a to ona jest dzisiaj częstszym projektem: firma, która ma PIM od pięciu lat, nie pyta „czy warto”, tylko „co się przeniesie, czego nie przeniosę i ile to potrwa”.

W Macopedia wdrażamy trzy systemy PIM: Akeneo, Ergonode i Pimcore, i mamy za sobą ponad 30 projektów PIM. Migracje robimy w obie strony, więc ten tekst nie jest argumentem za żadnym z tych systemów. Jest opisem tego, co dzieje się z danymi, kiedy zmienia się narzędzie.

Kiedy migracja PIM ma sens, a kiedy wystarczy porządek w danych

Zacznijmy od pytania, które oszczędza najwięcej pieniędzy: czy problem jest w systemie, czy w modelu danych, który w nim siedzi.

Trzy najczęstsze skargi na PIM nie są skargami na PIM:

„Nikt nie wie, gdzie jest aktualny opis”. To brak zdefiniowanego źródła prawdy i procesu, a nie brak funkcji. Po migracji ten sam problem pojawi się w nowym systemie, tylko z nowym interfejsem.
„Mamy 900 atrybutów i nikt ich nie rozumie”. To dług w modelu danych. Można go spłacić w obecnym systemie, zwykle taniej niż w trakcie migracji.
„Eksport do sklepu ciągle się wysypuje”. To najczęściej integracja albo jakość danych, nie PIM.

Migracja ma sens, gdy powód jest po stronie samego narzędzia. Realne powody, które widzimy w projektach: koszt licencji przestał się spinać z wielkością katalogu, brakuje funkcji, której nie da się dobudować, system nie ma ścieżki aktualizacji, albo zespół nie jest w stanie w nim pracować bez pośrednika technicznego.

Co przenosi się między systemami PIM

Migracja PIM to nie jeden transfer, a trzy różne prace o różnym koszcie.

Struktura, którą trzeba odtworzyć, a nie skopiować

Atrybuty, ich typy, grupy atrybutów, rodziny produktów, warianty i modele produktowe, drzewa kategorii, kanały sprzedaży, języki i lokalizacje, typy asocjacji, jednostki miary. To definicja katalogu, nie jego treść, i każdy system zapisuje ją inaczej. Nie ma tu eksportu, który wystarczy zaimportować: strukturę projektuje się w systemie docelowym, mając starą jako punkt wyjścia.

To zarazem jedyny moment w życiu katalogu, kiedy uporządkowanie modelu jest tanie. Jeśli 300 z 900 atrybutów nie jest używane przez żaden kanał, migracja jest okazją, żeby ich nie odtwarzać.

Dane produktowe

Wartości atrybutów, produkty, modele produktowe i warianty, przypisania do kategorii i kanałów, asocjacje. To część, która przenosi się najlepiej, bo jest tabelaryczna: eksport przez API albo do plików, mapowanie kolumn, import.

Jeden szczegół decyduje o tym, czy ta część jest łatwa: identyfikator. SKU albo kod produktu przenosi się bez problemu, ale wewnętrzne identyfikatory systemu nie. Każda integracja, która trzyma się wewnętrznego id zamiast SKU, jest do przepisania.

Media i tłumaczenia

Pliki przenoszą się razem z metadanymi i to zwykle działa. Trudniejsza jest struktura wokół nich: atrybuty aktywów, warianty i transformacje, powiązania z produktami.

Tłumaczenia są największym cichym mnożnikiem w całym projekcie. Katalog w jednym języku i w jednym kanale to jedna tabela. Ten sam katalog w sześciu językach i czterech kanałach to dwadzieścia cztery zestawy wartości, które trzeba przenieść, sprawdzić i wystawić. Liczba języków razy liczba kanałów mówi o pracochłonności migracji więcej niż liczba produktów.

Czego nie da się przenieść

Ta lista jest krótka i to ona zaskakuje zespoły w połowie projektu:

Historia zmian i audyt. Kto zmienił opis w marcu 2023 i na co, zostaje w starym systemie. Jeśli historia jest potrzebna do celów regulacyjnych, stary system zostaje włączony w trybie tylko do odczytu albo eksportujesz audyt do archiwum poza PIM.
Reguły i automatyzacje. Każdy silnik reguł ma własną składnię. Reguły przepisuje się, nie migruje, i to dobra okazja, żeby sprawdzić, które z nich ktoś jeszcze rozumie.
Uprawnienia na poziomie atrybutu, kanału i języka. Odwzorowanie jeden do jednego prawie nigdy nie jest możliwe. Zwykle projektuje się model uprawnień od nowa, prościej niż był.
Przepływy akceptacji i publikacji. Workflow to najbardziej specyficzna dla systemu część PIM, a jednocześnie ta, do której zespół jest najbardziej przywiązany.
Integracje. Nie migrują się w żadnym stopniu. Każde połączenie z ERP, e-commerce, DAM czy paszportem produktu trzeba przepisać na API systemu docelowego. To najczęściej największa pozycja w budżecie migracji i najłatwiejsza do przeoczenia w wycenie, bo nie widać jej w PIM.

Warstwa integracyjna jest jedynym miejscem, gdzie da się ten koszt obciąć strukturalnie: jeśli systemy łączy middleware, a nie zestaw połączeń każdy z każdym, wymiana PIM dotyka jednego końca, nie wszystkich.

Wyjście z Akeneo Enterprise: kiedy licencja przestaje się spinać

To dziś najczęstszy powód migracji PIM, jaki widzimy, i nie jest nim niezadowolenie z systemu. Jest nim rachunek: licencja Enterprise rośnie z katalogiem i z liczbą użytkowników, a nie z korzyścią, którą firma z niej ma. Katalog urósł trzy razy, funkcji używanych jest tyle samo, a odnowienie kosztuje wielokrotnie więcej niż pierwsze.

Dwa kierunki wyjścia, które w praktyce wybierają firmy, to Ergonode i Pimcore.

Co tracisz, schodząc z Enterprise

Uczciwa lista, bo to ona rozstrzyga, czy oszczędność jest prawdziwa. Poza samym narzędziem tracisz przede wszystkim rzeczy, które w Enterprise są gotowe:

rozbudowany workflow z akceptacjami i osobnym stanem opublikowanym,
silnik reguł wypełniających i wyliczających atrybuty,
wskaźniki jakości i kompletności danych, które podpowiadają redakcji, co uzupełnić,
drobnoziarniste uprawnienia dla zespołów, per atrybut i per język,
zarządzanie aktywami jako osobny, ustrukturyzowany moduł,
wsparcie producenta z umową i czasem reakcji.

Każdą z tych rzeczy da się mieć po migracji, ale w innej walucie: jako pracę wdrożeniową i utrzymanie, a nie jako pozycję w licencji. Migracja z Enterprise to zamiana kosztu stałego na koszt jednorazowy plus własne utrzymanie. Jeśli w rachunku nie ma pozycji na odtworzenie workflow, reguł i uprawnień, ten rachunek jest nieprawdziwy i wróci po pół roku.

Wsparcie jest osobną pozycją i najczęściej pomijaną. Odchodząc od producenta, przejmujesz odpowiedzialność za aktualizacje i za to, że katalog działa w piątek wieczorem. To rola dla partnera wdrożeniowego albo dla własnego zespołu, ale nie dla nikogo.

Ergonode czy Pimcore

Skrótowo, bo pełne porównanie trzech systemów mamy osobno: porównanie systemów PIM i artykuł Ergonode PIM: co to jest, cennik, funkcje i porównanie z Akeneo.

Ergonode jest bliżej sytuacji, w której zespół redakcyjny ma pracować od pierwszego dnia bez pośrednika: gotowe widoki katalogu, szablony karty produktowej, wbudowana automatyzacja i tłumaczenia. Wybierają go firmy, którym Enterprise dawał więcej, niż potrzebowały, i które chcą to samo tempo pracy taniej.

Pimcore jest odpowiedzią, gdy PIM nie jest jedynym problemem: katalog, aktywa i treść mają być w jednym systemie, model danych jest nietypowy, albo trzeba go dowolnie rozszerzać. Za tę swobodę płaci się pracą deweloperską, i to jest realny warunek wejścia, nie przypis.

Kryterium jest jedno i nie jest techniczne: kto będzie utrzymywał to, co dziś utrzymuje producent. Jeśli odpowiedź to „zespół redakcyjny”, kierunkiem jest Ergonode. Jeśli „zespół deweloperski albo partner”, w grze jest Pimcore.

Migracja z Pimcore do Akeneo: gdzie rozjeżdżają się modele danych

Kierunek odwrotny też się zdarza i wygląda inaczej, bo różnica nie dotyczy funkcji, a filozofii modelu.

Pimcore nie narzuca modelu: klasy obiektów definiuje się dowolnie i katalog może być praktycznie każdą strukturą. Akeneo narzuca swój: atrybut, rodzina, model produktowy, wariant. Migracja w tę stronę jest więc przede wszystkim sprowadzeniem swobodnego modelu do modelu zdefiniowanego, i tam leży cała praca.

Typowe punkty tarcia:

obiekty Pimcore, które nie są produktem ani wariantem, a czymś pomiędzy (zestawy, konfiguracje, pozycje techniczne),
relacje między obiektami, które w Akeneo muszą stać się asocjacjami albo atrybutami referencyjnymi,
treść i strony, które w Pimcore mieszkały obok katalogu, a w Akeneo nie mają gdzie mieszkać i wracają do CMS,
aktywa: wbudowany DAM Pimcore trzeba zmapować na sposób, w jaki aktywa trzyma Akeneo.

Zysk jest po stronie zespołu, nie technologii: model, który jest zdefiniowany, jest też zrozumiały dla nowej osoby po tygodniu, a nie po kwartale.

Ile to trwa i co decyduje o terminie

Migracja katalogu to zwykle projekt na kilka tygodni do kilku miesięcy, a rozrzut nie wynika z liczby produktów. Decydują w kolejności:

Liczba języków razy liczba kanałów. Największy mnożnik, o którym mówiliśmy wyżej.
Liczba integracji do przepisania. Każda to osobna praca z osobnymi testami.
Ile z Enterprise trzeba odtworzyć. Workflow, reguły i uprawnienia to trzy osobne projekty w projekcie.
Jakość danych źródłowych. Migracja niekompletnych danych jest droższa, bo każdy błąd trzeba rozstrzygnąć ręcznie.
Czy jest okno zamrożenia katalogu. Migracja bez zamrożenia oznacza dwa systemy pracujące równolegle i mechanizm dosyłania różnic, co jest osobną funkcjonalnością do zbudowania.

Liczba produktów jest na tej liście dopiero po nich. Katalog 200 tysięcy pozycji w jednym języku i jednym kanale migruje się szybciej niż 5 tysięcy w sześciu językach z akceptacjami.

Pięć rzeczy, które psują migrację PIM

Przeniesienie bałaganu. Migracja modelu jeden do jednego jest najszybsza w realizacji i najdroższa w skutkach: płacisz za projekt i zostajesz z tym samym problemem.
Brak decyzji o źródle prawdy na czas przejścia. Dwa systemy zapisujące ten sam atrybut przez trzy tygodnie to rozjazd danych, którego potem nikt nie rozplącze. Jeden system pisze, drugi czyta, od pierwszego dnia.
Integracje mapujące po wewnętrznym id. Wychodzi w dniu przełączenia, kiedy jest najdrożej. Mapowanie po SKU sprawdza się przed migracją, nie po.
Niedoszacowane tłumaczenia i kanały. Zespół liczy produkty, a pracochłonność robią języki.
Brak testu na pełnym wolumenie i brak planu wycofania. Import 500 produktów zawsze działa. Problemy pojawiają się przy pełnym katalogu, i wtedy trzeba wiedzieć, jak wrócić.

Najczęstsze pytania

Czy da się przenieść historię zmian z poprzedniego PIM?

Nie w sposób, który zachowa ją jako historię edytowalnego rekordu. Praktyczne rozwiązania to eksport audytu do archiwum albo utrzymanie starego systemu w trybie tylko do odczytu na czas wymagany przez firmę.

Czy migrację można zrobić etapami?

Tak, i najczęściej tak się ją robi: najpierw jedna rodzina produktów albo jeden kanał, potem reszta. Warunek jest jeden i jest twardy: na każdym etapie musi być jasne, który system jest źródłem prawdy dla danego zakresu danych.

Co z integracjami z ERP i sklepem?

Trzeba je przepisać, bo API systemu docelowego jest inne. To zwykle największa pozycja migracji. Jeśli integracje idą przez warstwę pośrednią, wymiana PIM dotyka tylko jej jednego końca.

Czy zamiast migracji można zostać na Akeneo Community?

Można i czasem to najtańsza droga, ale to nie jest „ten sam system taniej”. Tracisz dokładnie te funkcje, które są w Enterprise, więc rachunek jest ten sam co przy migracji: co trzeba odtworzyć i kto to utrzyma. Różnica jest tylko taka, że model danych zostaje bez zmian, a to oszczędza najbardziej pracochłonną część projektu.

Ile kosztuje migracja PIM?

Zależy od pięciu czynników z sekcji o terminach, a nie od liczby produktów. Strukturę kosztu wdrożenia rozkładamy w artykule co wpływa na koszt wdrożenia PIM Akeneo; w migracji dochodzą do tego integracje i odtworzenie tego, co dawała licencja.

Jeśli zastanawiasz się nad zmianą systemu PIM, najtańsza pierwsza godzina to przejrzenie modelu danych i listy integracji, a nie wybór narzędzia. Zobacz, jak podchodzimy do wdrożeń PIM, albo od razu do PIM Starter, jeśli katalog ma trafić do nowego systemu w ustalonym zakresie i terminie.