W tym artykule znajdziesz odpowiedź na to, z czego naprawdę składa się model danych w PIM (producenci, kategorie, atrybuty i relacje między nimi), dlaczego kategorie trzeba budować po stabilnym numerze, a nie po nazwie, czym model danych w B2B różni się od modelu w B2C (cenniki, rabaty, kredyt kupiecki zależne od typu klienta), oraz jak w praktyce wygląda budowanie i utrzymanie takiego modelu po starcie systemu.
Czym jest model danych w PIM?
Wiele firm, które zaczynają wdrożenie PIM, myśli o modelu danych jako o liczbie pól opisujących produkt: nazwa, cena, kolor, wymiary. W praktyce model danych to układ czterech elementów, które muszą się ze sobą zgadzać: producenci, kategorie, atrybuty podzielone na grupy oraz relacje łączące to wszystko z konkretnym produktem. Dopiero to razem daje strukturę, na której da się filtrować, porównywać i importować produkty bez ręcznej poprawki każdego rekordu. Zobaczmy, dlaczego pominięcie jednego z tych elementów potrafi zablokować cały import, zanim ktokolwiek zdąży zauważyć błąd.
Z czego naprawdę składa się model danych?
Podczas jednego z wdrożeń dla klienta z branży oświetleniowej cały model danych sprowadzał się do pięciu plików: lista producentów, lista kategorii, lista atrybutów, lista grup atrybutów i lista wartości tych atrybutów. Każdy produkt w systemie musi mieć przypisanego producenta, przypisaną kategorię, wybrane atrybuty z odpowiednich grup i wybrane wartości tych atrybutów. To jest rdzeń, od którego zależą kolejne kroki: mapowanie plików od dostawców, wzbogacanie opisów, eksport do systemu sprzedażowego. Jeżeli ten rdzeń jest niekompletny, każdy kolejny krok trzeba wykonywać ręcznie, bo system nie ma się o co oprzeć przy dopasowywaniu nowych danych. Więcej o tym, jak wygląda to w naszych wdrożeniach opartych na Akeneo, w przeglądzie modułów PIM Akeneo.
Dlaczego kategorie trzeba budować po numerze, a nie po nazwie?
Podczas migracji danych produktowych u jednego z klientów wyszedł na jaw prosty, ale kosztowny błąd: dopasowanie kategorii w eksporcie opierało się na nazwie, a nie na numerze identyfikującym kategorię w systemie. Polskie znaki w nazwach powodowały, że to samo dopasowanie rozjeżdżało się między plikami, mimo że dla człowieka obie nazwy wyglądały identycznie. Poprawka wymagała przebudowy: każda kategoria musi mieć swój stabilny numer, a hierarchia, czyli informacja, która kategoria jest nadrzędna względem której, powinna być budowana na numerach kategorii nadrzędnej, nie na tekście. Ten sam numer pozwala też przypisać jednemu produktowi więcej niż jedną kategorię, co w B2B zdarza się częściej, niż zakładają domyślne szablony PIM.
Co w tym modelu jest inne w B2B niż w B2C?
W sklepie konsumenckim model danych kończy się zwykle na atrybutach i kategoriach. W B2B do tego samego rdzenia trzeba dopisać warstwę, która reaguje na to, kto kupuje. Podczas wdrożenia platformy dla klienta z branży budowlanej okazało się, że jeden produkt może mieć różną cenę w zależności od trzech powiązanych ustaleń: cennika przypisanego do konkretnego kontrahenta, rabatu wynegocjowanego dla tego kontrahenta i tego, czy kupujący jest zweryfikowanym klientem biznesowym czy zwykłym gościem korzystającym ze standardowego dostępu. Do tego dochodzi limit kredytu kupieckiego, czyli suma, do której dany kontrahent może kupować bez płacenia z góry. Model danych bez miejsca na te elementy zadziała poprawnie na demo i przestanie działać w chwili, gdy pierwszy handlowiec zapyta, dlaczego klient X widzi inną cenę niż klient Y.
Jak w praktyce wygląda budowanie i utrzymanie tego modelu?
Zbudowanie modelu danych to jednorazowa praca, ale jego utrzymanie już nie. W jednym z wdrożeń każda zmiana atrybutu w systemie klienta, czyli nowa wartość, nowa kategoria albo nowy producent, wymagała wyeksportowania pięciu plików ze źródłowego systemu i ponownego wgrania ich do narzędzia importującego, żeby model przebudował się na nowo. Zespół prowadzący ten proces wprowadził walidację kolumn na wejściu, żeby błąd w pliku został wychwycony przed importem, a nie po nim, kiedy trzeba by już czyścić bazę aktywnych produktów. To jest różnica między modelem danych, który działa raz, na potrzeby prezentacji, a modelem, który wytrzymuje setki zmian w katalogu bez powrotu do punktu wyjścia. Ten etap opisujemy szerzej w roadmapie wdrożenia PIM dla producentów i dystrybutorów.
Czego ten artykuł nie rozstrzyga
Nie ma jednego uniwersalnego schematu modelu danych, który pasuje do każdej branży. Liczba grup atrybutów i sposób ich łączenia z kategoriami zależą od tego, jak zróżnicowany jest katalog konkretnego klienta — firma z jednym typem produktu potrzebuje prostszej struktury niż firma sprzedająca kilkadziesiąt technicznie odmiennych kategorii towarów.
Co zapamiętać o budowie modelu danych w PIM
Model danych w PIM nie kończy się na liście atrybutów. To układ producentów, kategorii i atrybutów oparty na stabilnych identyfikatorach, do którego w B2B dochodzi dodatkowa warstwa: ceny i dostępność zależne od tego, kto kupuje. Firmy, które budują ten model z myślą o pierwszej prezentacji, a nie o setkach zmian w katalogu, prędzej czy później wracają do punktu wyjścia.
Zanim zaczniecie budować model danych, sprawdźcie:
- Czy kategorie i producenci mają w systemie źródłowym stabilny numer identyfikacyjny, a nie tylko nazwę?
- Czy wiadomo, kto po stronie klienta odpowiada za uzupełnianie i porządkowanie atrybutów po wdrożeniu?
- Czy model uwzględnia to, że ten sam produkt może mieć inną cenę i inną dostępność zależnie od typu klienta?
- Czy istnieje sposób walidacji danych przed importem, a nie tylko poprawianie błędów po nim?\
Jeśli ten sam chaos widzicie dziś na poziomie samych wartości atrybutów, a nie całego modelu, zobaczcie też nasz artykuł o tym, dlaczego atrybuty blokują wdrożenia PIM, albo napiszcie do nas — sprawdzimy, jak zaprojektować model danych pod wasz katalog.
