Kiedy import produktów się sypie, pierwsze podejrzenie pada na narzędzie. Zły format pliku, kiepski importer, za wolne API. Wydaje się, że to problem techniczny — coś, co da się naprawić lepszym skryptem i jednym sprintem.
Prawie nigdy tak nie jest. W projektach, przy których pracujemy, wdrożenie zatrzymuje się nie na technologii, tylko na atrybutach produktowych. Na tym, że pole opisane jako „tekst” ma w praktyce słownik dwóch tysięcy wartości. Że „wysokość w centymetrach” ma dwadzieścia jeden wartości do wyboru, choć powinna być polem do wpisania. Że ta sama wielkość fizyczna zapisana jest raz ze spacją, raz bez — i system traktuje to jako dwie różne rzeczy.
To dług, który narastał latami i którego — to najciekawsza część — nikt wewnątrz firmy nie chce dotknąć.
Dlaczego nikt tego nie rusza od lat?
Tu jest sedno.
Organizacja atrybutów bardzo często nie należy do nikogo konkretnego – nie ma właściciela. Dział produktowy powie, że to temat IT – przecież to baza danych. IT powie, że to temat produktowy — bo to decyzje merytoryczne, czy „złoty szczotkowany” to osobny kolor. E-commerce powie, że to zaszłość, która była przed nimi. Każda z tych odpowiedzi jest po części prawdziwa, i dlatego temat leży.
Punktem wyjścia do rozwiązania tego problemu nie jest więc czyszczenie wartości ani wybór narzędzia, tylko rozdzielenie, kto w tym procesie za co odpowiada: kto decyduje, czy „złoty szczotkowany” to nowy kolor, czy wariant istniejącego, kto wprowadza tę decyzję do systemu, i kto pilnuje, żeby katalog nie rozjeżdżał się przy kolejnym imporcie. Dopóki te trzy role nie mają przypisanych osób, każda rozmowa o uporządkowaniu atrybutów kończy się tak samo: nikt nie zaczyna, bo nikt nie czuje się za to odpowiedzialny. W praktyce widzimy to za każdym razem, kiedy klient zaczyna porządkować dane produktowe, niezależnie od branży czy wielkości katalogu.
Do tego dochodzi asymetria kosztu i efektu. Posprzątanie dwóch tysięcy wartości to tygodnie żmudnej pracy, której efekt jest niewidoczny — po niej sklep wygląda tak samo. Dopóki nie ma projektu, który to wymusza, nie ma też powodu, żeby zacząć. A kiedy projekt się pojawia — wdrożenie PIM, migracja, automatyzacja importu — okazuje się, że to właśnie ten dług jest kamieniem, o który wszystko się rozbija. I nagle trzeba go spłacić w tydzień.
Uczciwie: my też tego nie posprzątamy za klienta. Decyzja, czy „złoty szczotkowany” mapuje się na „złoty”, czy zostaje osobną wartością, jest decyzją biznesową, nie techniczną. Wdrożeniowiec może ją przygotować, opisać konsekwencje i zautomatyzować wykonanie — ale nie może jej podjąć.
Jak sprawdzić w kwadrans, czy problem dotyczy was
Nie trzeba audytu, żeby to zdiagnozować. Wystarczy wyeksportować z systemu listę atrybutów wraz z liczbą wartości każdego z nich i spojrzeć na skrajne przypadki. Sama liczba wartości jest sygnałem — jeśli atrybut ma ich setki albo tysiące, to prawie zawsze znaczy jedno z trzech:
- Zły typ pola. Wielkość ciągła (wysokość, waga, moc) trzymana jako lista wyboru zamiast pola liczbowego. Każdy nowy produkt dokłada wartość do słownika.
- Brak normalizacji zapisu. Ta sama wartość ze spacją, bez spacji, z jednostką i bez. Dla systemu to osobne byty; dla klienta na froncie — trzy identyczne pozycje w filtrze.
- Brak reguły mapowania. Dane od różnych producentów wpadają w to samo pole bez tłumaczenia na wewnętrzny słownik.
Drugi krok, jeszcze prostszy: wejść w konkretny atrybut i policzyć, ile razy każda wartość faktycznie występuje. Wartości używane raz albo dwa razy to zwykle literówki i duplikaty. To jest lista do posprzątania — i zarazem dowód, którym da się w firmie ruszyć temat z miejsca, bo pokazuje skalę w liczbach, a nie w narzekaniu.
Porządkowanie nie musi być wielkim projektem
Najczęstszy błąd to potraktowanie tego jako jednorazowej akcji „czyścimy wszystko”. To się nie udaje, bo zakres jest zniechęcający, a efekt odroczony.
Co działa lepiej:
- Ustalić podział odpowiedzialności, zanim ktokolwiek zacznie czyścić dane. Kto decyduje, czy „złoty szczotkowany” to nowy kolor, czy wariant istniejącego (produkt), kto wprowadza tę decyzję do systemu (wdrożeniowiec albo dział IT) i kto pilnuje, żeby nowe dane od producentów nie psuły ustalonego porządku (e-commerce albo dział danych). To nie musi być jeden etat, ale musi być jasne, do kogo należy każda z tych trzech decyzji — bez tego każde sprzątanie rozjeżdża się przy najbliższym imporcie.
- Zacząć od atrybutów, które faktycznie są używane — w filtrach, w wyszukiwarce, w feedach. Reszta może poczekać.
- Zamiast czyścić — mapować. Ustalić raz regułę („każde wystąpienie »złoty szczotkowany« przekształcamy na »złoty«”) i zapisać ją w narzędziu, żeby działa przy każdym kolejnym imporcie. Większość firm takiego narzędzia jeszcze nie ma, a to jest właśnie ten element jest warty zbudowania, bo inaczej każda reguła zacznie się gubić przy kolejnych importach. Sprzątanie, które nie utrwala reguły, trzeba powtórzyć za kwartał.
- Uzbroić proces w walidację po stronie wejścia, żeby dane od producenta nie dokładały nowych wartości bez decyzji człowieka.
I rzecz, która brzmi banalnie, a zwykle przesądza: porządkowanie danych powinno zacząć się przed wdrożeniem, nie w jego trakcie. Wtedy jest pracą planową. W trakcie wdrożenia staje się kryzysem z terminem.
Co z tego wynika?
Jeśli planujecie wdrożenie PIM, migrację albo automatyzację importu, sprawdźcie trzy rzeczy, zanim wybierzecie narzędzie:
- Czy macie rozdzielone, kto decyduje o wartościach atrybutów, kto wprowadza te decyzje do systemu, a kto odpowiada za to, żeby nowe dane od producentów nie psuły ustalonego porządku.
- Ile wartości mają wasze najbardziej rozbudowane atrybuty — i czy ich typ odpowiada temu, co faktycznie opisują.
- Czy istnieje reguła mapowania danych od producentów na wasz słownik, czy każdy import to decyzje ad hoc.
Pierwsze pytanie jest najtrudniejsze i najważniejsze. Technologia poradzi sobie z bałaganem, którego skalę znacie. Nie poradzi sobie z tym, że nikt nie chce go ruszyć.
