PIM dla e-commerce

Problem zwykle nie zaczyna się od tego, że firma „potrzebuje Pimcore".

Zaczyna się wtedy, gdy dane produktowe są rozproszone między ERP, Magento, arkuszami i innymi systemami, a coraz trudniej odpowiedzieć na proste pytanie: która wersja informacji jest właściwa i kto za nią odpowiada?

Projektujemy architekturę danych produktowych i wdrażamy rozwiązania PIM. Najpierw ustalamy źródła danych, przypisujemy właściciela danych i docelowy model informacji. Dopiero później wybieramy technologię.

Jeżeli PIM nie jest potrzebny albo prostsze rozwiązanie będzie wystarczające, powiemy Wam o tym.

Bezpłatna rozmowa, 30-60 minut. Poznamy źródła danych produktowych, obecne procesy i kanały publikacji. Wstępnie ocenimy, czy PIM rozwiąże kluczowe problemy i które obszary wymagają analizy.

Wyzwanie

Kiedy problemem przestaje być sam katalog

Na początku sposób zarządzania produktami często jest prosty.

ERP dostarcza podstawowe informacje. Marketing uzupełnia opisy w Magento. Zdjęcia znajdują się w osobnym katalogu. Tłumaczenia powstają w arkuszach.

Przy jednym rynku i niewielkim katalogu taki model może działać przez lata.

Problem pojawia się, gdy dochodzą kolejne języki, rynki, warianty, atrybuty i kanały publikacji. Ta sama informacja zaczyna występować w kilku miejscach, a zmiana produktu wymaga pracy kilku osób w różnych narzędziach.

Wtedy problemem nie jest już brak kolejnego pola w Magento.

Problemem jest brak spójnego modelu zarządzania informacją produktową.

Odpowiedzialność

PIM zaczyna się od odpowiedzialności za dane

Wdrożenie kolejnego systemu nie rozwiąże problemu, jeśli ta sama informacja nadal może być niezależnie zmieniana w kilku miejscach.

Dlatego jednym z pierwszych pytań jest: który system odpowiada za konkretną informację?

Przykładowo ERP może być źródłem SKU, cen, stanów i informacji handlowych, PIM - opisów, atrybutów, relacji, tłumaczeń i treści marketingowych, DAM - zdjęć i dokumentów, a Magento odpowiadać za prezentację produktu i proces sprzedaży.

To tylko przykład. W konkretnym projekcie granice mogą przebiegać inaczej, często nie na poziomie całych systemów, lecz pojedynczych pól.

Sprawdzian jest prosty. Jeżeli po wdrożeniu opis produktu nadal da się poprawić w trzech miejscach, a nikt nie potrafi wskazać, które z nich jest właściwe, PIM nie zmienił sposobu pracy. Został tylko dołożony do istniejącego układu.

Model informacji

Model danych przed wyborem technologii

PIM nie powinien być miejscem, do którego przenosi się istniejącą strukturę tylko dlatego, że już kiedyś powstała.

Przy dużych i złożonych katalogach analizujemy produkty i warianty, atrybuty, relacje pomiędzy produktami, klasyfikacje, wersje językowe, różnice między rynkami oraz sposób publikacji do poszczególnych kanałów.

Jeżeli dotychczasowy model przez lata obrósł duplikatami i wyjątkami, wdrożenie PIM jest dobrym momentem, żeby go uprościć.

Przeniesienie bałaganu z Excela lub Magento do nowej platformy tylko utrwali problem w droższym narzędziu.

Wiele rynków

Wiele rynków to coś więcej niż tłumaczenia

Ten sam produkt może mieć inną nazwę, opis, zestaw dokumentów czy wymagane informacje w zależności od rynku.

Do tego dochodzą marketplace'y, feedy, katalogi B2B, aplikacje i inne kanały.

PIM pozwala oddzielić dane wspólne dla produktu od informacji specyficznych dla rynku i treści przygotowanych dla konkretnego kanału.

Dzięki temu nowy rynek nie musi oznaczać tworzenia kolejnej niezależnej wersji katalogu.

Proces produktu

Workflow: produkt ma proces, nie tylko zestaw pól

W większej organizacji dane produktowe rzadko przygotowuje jedna osoba.

Dział produktowy dostarcza dane techniczne. Marketing tworzy opisy. Ktoś przygotowuje tłumaczenia. Inna osoba odpowiada za zdjęcia i dokumenty. Produkt przed publikacją może wymagać zatwierdzenia.

PIM może obsługiwać ten proces jako workflow.

Możemy zaprojektować:

  • role i etapy przygotowania produktu,
  • pola wymagane na poszczególnych etapach,
  • akceptacje i status gotowości danych,
  • reguły publikacji do kanałów.

Dzięki temu organizacja nie musi polegać na pamięci osób pracujących przy katalogu i dodatkowych arkuszach kontrolnych.

Zasoby cyfrowe

DAM i media

W wielu projektach problem z danymi produktowymi nie kończy się na tekstach i atrybutach. Trzeba również zarządzać zdjęciami, instrukcjami, certyfikatami, dokumentacją techniczną i materiałami marketingowymi.

Pimcore może łączyć funkcje PIM i DAM, dzięki czemu assety są powiązane z produktami, wersjami językowymi i rynkami.

Nie każdy projekt tego potrzebuje. DAM jest elementem architektury wtedy, gdy rzeczywiście rozwiązuje problem organizacji materiałów.

Wybór rozwiązania

Pimcore czy inne rozwiązanie?

Nie zaczynamy projektu od decyzji: „wdrażamy Pimcore".

Najpierw sprawdzamy strukturę danych, liczbę rynków i kanałów, sposób pracy zespołu, potrzeby workflow, wymagania dotyczące DAM oraz integracje z ERP i e-commerce.

Pimcore dobrze sprawdza się w projektach wymagających elastycznego modelu danych, relacji pomiędzy obiektami i rozbudowanej warstwy DAM.

Jeżeli wymagania są prostsze albo lepiej pasują do bardziej wyspecjalizowanego PIM, powiemy o tym - również wtedy, gdy oznacza to mniejszy zakres projektu po naszej stronie.

Technologia ma wynikać z procesu i modelu informacji, nie odwrotnie.

Integracje

PIM musi współpracować z ERP i Magento

PIM nie powinien stać się kolejną niezależną wyspą.

Typowy przepływ może wyglądać tak:

ERP → dane podstawowe → PIM → wzbogacenie i uporządkowanie → Magento i inne kanały

Ale równie dobrze część informacji może powstawać bezpośrednio w PIM, a ERP otrzymywać tylko wybrane dane.

Na etapie discovery definiujemy źródła informacji, kierunki przepływu, odpowiedzialność systemów, częstotliwość synchronizacji i mapowanie danych. Dopiero wtedy budujemy integrację.

Praktyka projektowa

Doświadczenie ze złożonymi danymi

W jednym z dużych projektów migracyjnych pracowaliśmy z bazą obejmującą setki tysięcy produktów i wieloletnie dane legacy.

Istotną częścią pracy było nie samo przeniesienie rekordów, lecz ich uporządkowanie: usunięcie nieaktywnych pozycji, normalizacja niespójności, mapowanie do nowego modelu oraz pogodzenie wymagań nowej platformy z istniejącym ERP i strukturą SEO.

Nie był to projekt PIM.

Pokazuje jednak klasę problemu, z którą PIM często ma sobie później poradzić: przy dużej skali ręczne poprawianie danych przestaje być procesem, na którym można oprzeć rozwój e-commerce.

Jak pracujemy

Jak prowadzimy projekt PIM

  1. 01

    Analiza stanu danych

    Ustalamy, gdzie dane znajdują się dziś, kto je tworzy i które systemy ich potrzebują.

  2. 02

    Właściciele danych

    Definiujemy źródło prawdy dla poszczególnych typów danych.

  3. 03

    Model danych

    Projektujemy produkty, atrybuty, relacje, wersje językowe, rynki i zasady publikacji.

  4. 04

    Wybór platformy

    Dopiero na tym etapie rekomendujemy Pimcore albo inne rozwiązanie PIM.

  5. 05

    Architektura integracji

    Projektujemy wymianę danych z ERP, Magento, DAM i pozostałymi kanałami.

  6. 06

    Wdrożenie

    Budujemy model danych, workflow, role i potrzebne rozszerzenia.

  7. 07

    Migracja danych

    Mapujemy, czyścimy i przenosimy dane do nowej struktury.

  8. 08

    Testy end-to-end

    Sprawdzamy cały przepływ - od systemu źródłowego po finalny kanał publikacji.

Ocena potrzeby

Kiedy PIM może być niepotrzebny

PIM nie jest obowiązkowym elementem dojrzałego e-commerce.

Jeżeli katalog jest prosty, firma działa na jednym rynku, dane są spójne, a ERP i Magento mają jasno określone role, dokładanie kolejnej platformy może jedynie zwiększyć koszt utrzymania.

W takim przypadku lepiej uporządkować istniejącą architekturę niż uzasadniać wdrożenie dodatkowego systemu.

Doświadczenie

Dlaczego Velocity

Patrzymy na PIM jako część całej architektury e-commerce.

Pracujemy z Magento, dużymi katalogami, integracjami ERP, wyszukiwarką i migracjami danych. Dzięki temu projekt PIM nie kończy się dla nas na konfiguracji panelu.

Interesuje nas cały przepływ:

ERP → PIM → Magento → wyszukiwanie → pozostałe kanały.

Jeżeli problem da się rozwiązać bez PIM, nie będziemy budować argumentacji za kolejną platformą.

Dopasowanie

Kiedy problem leży gdzie indziej

Integracje ERP

Jeżeli największym problemem są ceny, stany, zamówienia i komunikacja Magento z systemem operacyjnym, właściwym punktem wyjścia będą integracje ERP.

Integracje ERP →

Duże katalogi w Magento

Jeżeli dane są poprawnie uporządkowane, ale skala katalogu zaczyna wpływać na wydajność Magento, duże katalogi wymagają dedykowanego podejścia.

Duże katalogi w Magento →

Audyt wydajności i bezpieczeństwa

Jeżeli nie masz pewności, gdzie leży wąskie gardło, punktem wyjścia może być bezpłatny audyt wydajności i bezpieczeństwa.

Migracja i replatforming

Jeżeli wyzwaniem jest przeniesienie całej obecnej platformy i danych do Magento, właściwym kierunkiem będzie migracja i replatforming.

Migracja i replatforming →

Pytania

FAQ

VLCT

PIM to system służący do zarządzania informacją produktową: atrybutami, opisami, relacjami, tłumaczeniami i wersjami danych przeznaczonymi do różnych kanałów.

VLCT

Zwykle nie. ERP może nadal odpowiadać za ceny, stany i informacje handlowe, a PIM za dane opisowe i produktowe.

VLCT

Nie. Magento odpowiada za commerce i proces sprzedaży. PIM przygotowuje i dystrybuuje dane wykorzystywane przez Magento.

VLCT

Pimcore jest szczególnie interesujący przy złożonym modelu danych, wielu relacjach, wymaganiach DAM i potrzebie elastycznego budowania procesów.

VLCT

Pimcore jest rozwiązaniem, które znamy najlepiej. Jeżeli z discovery wyniknie, że lepiej dopasowane będzie narzędzie skoncentrowane wyłącznie na zarządzaniu i wzbogacaniu danych produktowych, na przykład Akeneo, powiemy o tym i wesprzemy w jego wdrożeniu.

VLCT

Nie zawsze, ale wiele języków i rynków znacząco zwiększa wartość centralnego zarządzania informacją produktową.

VLCT

Tak. W przypadku Pimcore zarządzanie assetami może być częścią tego samego rozwiązania.

VLCT

Taką potrzebę oceniamy podczas discovery. W praktyce wdrożenie PIM często jest dobrym momentem na uporządkowanie modelu i historycznych niespójności.

VLCT

Tak. Jeżeli problem można rozwiązać prostszą zmianą modelu danych lub integracji, będzie to lepsza rekomendacja niż wdrażanie kolejnego systemu.