W życiu każdej firmy przychodzi moment, w którym stare rozwiązania już nie wystarczają i trzeba wdrożyć nowe, odpowiadające obecnym potrzebom i wyzwaniom. W Militaria.pl ten moment przyszedł w 2019 r., kiedy w związku z dynamicznym rozwojem podjęto decyzję o rezygnacji z dalszej rozbudowy ówczesnej platformy e-commerce i wdrożeniu zupełnie nowej. Oprócz tego postawiono na zmianę architektury systemu i odejście od monolitu na rzecz odrębnych aplikacji. W tym artykule skupię się na wdrożeniu PIM (product information management).
Militaria.pl to jeden z najstarszych brandów e-commerce w Polsce. W ofercie sklepu znajduje się szeroki wybór produktów z obszarów strzelectwa, samoobrony i outdooru. Obecnie jest to ponad 60 tys. aktywnych indeksów. Celem wdrożenia aplikacji PIM była optymalizacja zarządzania informacją produktową i jej dystrybucją w wielu kanałach.
Aktualnie na rynku są dwa bardzo popularne systemy PIM oraz kilka mniejszych. W ogromnym uproszczeniu można powiedzieć, że jedni liderzy charakteryzują się łatwością wdrożenia i obsługi (gotowe rozwiązania) a drudzy – szerokimi możliwościami konfiguracji. Zdecydowaliśmy się na drugą opcję, tzn. postawiliśmy na Pimcore 6 (który został już zaktualizowany do wersji X).
Czym jest PIM
PIM to aplikacja do zarządzania informacjami o produktach będących w ofercie firmy. Moja ulubiona definicja, często stosowana na etapie ewangelizacji w firmie, brzmi: „Główne źródło prawdy o produkcie, które konsoliduje dane produktowe z różnych źródeł, porządkuje je, wzbogaca, a następnie dostarcza do kolejnych aplikacji”.
W praktyce oznacza to, że PIM okaże się szczególnie użyteczny tam, gdzie informacje produktowe będą wykorzystywane w wielu kanałach. Co warte podkreślenia – nie zawsze cyfrowych.
Zapamiętaj
Dane można ustrukturyzować i wyeksportować do działów zajmujących się przygotowaniem katalogów (papierowych), plików PDF z kartą produktów lub informacjami technicznymi, jak również materiałów do sklepów stacjonarnych. Niemniej najczęściej takie dane zasilają strony internetowe, sklepy online, a także mogą zostać udostępnione klientom biznesowym.
Dzięki natywnym mechanizmom ułatwiającym zarządzanie tłumaczeniami PIM stanowi również dobre rozwiązanie dla firm oferujących swoje produkty na wielu rynkach.
Czym PIM nie jest
Dosyć powszechne jest przekonanie, że każdą aplikację można przebudowywać w nieskończoność i dodawać do niej coraz to nowsze funkcje. Często zapomina się, że customizacja wpływa na czas i koszt aktualizacji systemu przez producenta oprogramowania (a czasami wiąże się z brakiem takiej możliwości, przez co z rozwiązania ustandaryzowanego robi się aplikacja dedykowana).
Wskazówka
PIM to przede wszystkim baza informacji o produkcie – wspólnych we wszystkich kanałach i dla wszystkich klientów. Łatwiej i efektywniej (w mojej ocenie) przenieść odrębne procesy do innych aplikacji, a PIM używać do tego, do czego został stworzony.
Zatem z pewnością PIM nie jest aplikacją, która przetwarza informacje o produkcie na docelowy format. Najlepiej, aby dostarczała „suche” dane, wykorzystywane przez mechanizmy innych aplikacji. Te same dane przechowywane w PIM mogą mieć różny wygląd (ale także zakres, można je „personalizować” osobno dla każdego kanału).
Przebieg wdrożenia
1. Prace analityczne i przedwdrożeniowe
Działania analityczne i przedwdrożeniowe rozpoczęliśmy od określenia modelu danych, które w mojej ocenie jest kluczowe. Zdefiniowaliśmy:
- jakie informacje będą przechowywane w PIM,
- w jaki sposób będą uporządkowane,
- jakie relacje będą zachodziły między różnymi typami danych – powiązania między produktami (tzw. produkty podobne), relacje produktu do producenta (który zbiera informacje o nim) i do kategorii.
Należy pamiętać, że model powinien zostać zweryfikowany w kontekście źródła danych, tzn.:
- skąd i w jaki sposób zostaną zaimportowane dane,
- czy dane w źródle są kompletne,
- czy ich obecna struktura jest taka jak docelowa,
- czy potrzebne jest dodatkowe mapowanie lub przetwarzanie.
Zapamiętaj
Oszczędności dokonane na etapie analizy odbiją się na etapie wdrożenia, dlatego nie można poprzestać na utworzeniu samego modelu. Konieczna jest analiza danych wsadowych przeprowadzona na dużej, zróżnicowanej próbce, a wszystko to w kontekście ustalonej metody migracji.
Model powinien zawierać strukturę zawartych w nim danych.
2. Konfiguracja aplikacji, aby odwzorować zaprojektowany model
Podstawowym obiektem w systemie Pimcore jest klasa, dlatego na początku:
1. Stworzyliśmy klasę (w zależności od potrzeb: produkt, producent, metoda dostawy, kategoria).
2. W ramach klasy zdefiniowaliśmy atrybuty (identyfikatory, jakich używamy, nazwa, multimedia, pola opisowe).
Jeśli nie jest to określone w firmie, należy ustalić, który z identyfikatorów będzie nadrzędny i za pomocą którego różne aplikacje będą się komunikować – idealnie, jeśli będzie on taki sam we wszystkich aplikacjach (np. SKU generowane w ERP).
3. Utworzyliśmy relacje między obiektami. Relacje mogą być symetryczne (np. gdy po utworzeniu relacji wiatrówki do śrutu tworzy się na karcie produktowej śrutu relacja do wiatrówki) lub nie.
3. Zasilenie modelu danymi
Z perspektywy czasu mogę powiedzieć, że to najtrudniejszy krok migracji danych produktowych – nie tylko ze względu na konieczność utworzenia mechanizmów pobierających dane ze starej bazy do nowej, ale głównie z powodu różnic w modelu wynikających z licznych zmian w strukturze danych bazy źródłowej, mającej za sobą ponad 15 lat rozbudowy i zmian.
W Militaria.pl zdecydowaliśmy się na iteracyjne (przyrostowe) importy danych. Dzięki temu udało nam się na dosyć wczesnym etapie zlokalizować niezgodności, braki, a także błędy w założeniach modelu danych (np. oddzieleniu zarządzania grupami parametrów technicznych od drzewa kategorii publikacji).
Dzieliliśmy zakres importu danych i kolejna iteracja przebiegała już z poszerzonym zakresem: od atrybutów prostych (nazwa, opis), przez dane techniczne i multimedia, po relacje (jest to o tyle istotne, że nie można utworzyć relacji do obiektu, którego w bazie jeszcze nie ma, stąd konieczność wcześniejszego importu kompletnej oferty).
Wskazówka
Istotne w migracji danych produktowych jest ustalenie kolejności importowanych obiektów – np. aby utworzyć relację produktu do producenta, trzeba mieć zaimportowanych producentów. Niby truizm, ale na etapie planowania prac warto mieć to z tyłu głowy, aby nie tworzyć opóźnień. Pewne prace można realizować równolegle, aby maksymalnie skrócić ścieżkę krytyczną projektu, jednak w pewnym momencie brak jednego z elementów może zablokować inne zadania lub nawet całe przedsięwzięcie.
W tym miejscu warto wspomnieć o funkcji Pimcore’a, jaką jest dziedziczenie danych (czyli ustalanie, które dane z obiektów nadrzędnych są przekazywane do wszystkich obiektów podrzędnych). Dzięki takiemu podziałowi można automatyzować wypełnianie niektórych atrybutów przez przypisanie obiektu do wybranego rodzica (obiektu nadrzędnego), dzięki czemu potomek (obiekt podrzędny) otrzyma tą samą wartość w momencie przypisania.
Trudność w tym obszarze polegała na tym, że takiego mechanizmu we wcześniejszym systemie, na którym bazowały Militaria.pl, nie było, co powodowało konieczność definiowania dodatkowych warunków oraz zmian przy imporcie i mapowaniu.
4. Integracja z platformą e-commerce i ERP
To moment prawdy, w którym wychodzą na jaw wcześniejsze błędy w założeniach. Poprawna integracja z platformą e-commerce jest kluczowa dla celu biznesowego. Jeśli coś pójdzie niezgodnie z planem, produkty mogą się nie wyświetlać na froncie sklepu lub ich opisy mogą zawierać nieaktualne dane.
Integracja z ERP jest pośrednio związana z importem inicjalnym. Tworzy się niektóre atrybuty produktu i zarządza się nimi właśnie w ERP (chodzi szczególnie o status aktywności czy aktualizację EAN). Ustanowienie komunikacji, integracja inicjalna, a następnie ciągła aktualizacja danych z ERP to elementy niezbędne do utrzymania aktualności oferty.
Wskazówka
Należy pamiętać, że aplikacje biznesowe mają różne wymagania i elastyczność wobec tych samych danych. W przypadku Pimcore’a wysoki poziom elastyczności w konfiguracji należało skonfrontować z wymaganiami wobec danych produktowych z platformy e-commerce.
Już po pierwszych próbach integracji zauważyliśmy braki i błędy w modelu, które przekładały się na pomyłki w komunikacji.
Przykład
PIM ignorował wartość atrybutu „<pusty>” (w modelu określonym jako „niewymagany”). Natomiast platforma e-commerce w swoich procesach tej informacji wymagała, co skutkowało koniecznością nie tylko poprawy w modelu, lecz także uzupełnienia brakujących danych.
Komunikacja na linii PIM – ERP – platforma e-commerce jest i powinna być trójstronna. Dane przekazywane z ERP do PIM i dalej do platformy dotyczą tylko informacji produktowych (np. EAN). Bezpośrednio z ERP do platformy trafiają dane tylko w zakresie, który w PIM nie jest istotny (np. cena, dostępność). Decyduje tu czas przekazania informacji, bez dodatkowych opóźnień w aplikacji pośredniczącej.
Gdy mieliśmy zrealizowane zadania związane z modelem danych, importem inicjalnym i integracją, mogliśmy rozpocząć prace nad workflow, blokadami dotyczącymi miejsc potencjalnie narażonych na pomyłki użytkowników oraz zmianami w GUI (poprawkami UX-owymi zgłaszanymi przez użytkowników). Dodatkowo w trakcie prac z użytkownikami zauważyliśmy, że proces tworzenia indeksów w naszych systemach IT ma spory potencjał optymalizacji.
Największe wyzwania i jak udało się im sprostać
Największym wyzwaniem okazała się desynchronizacja w zakresie posiadanych informacji. W wyniku testów natrafialiśmy na krytyczne braki w danych, zmuszające nas do ponawiania importu inicjalnego. Skutkowało to koniecznością powtórzenia procesów związanych m.in. z wyrównaniem poziomu aktualności. Warto pamiętać, że w e-commerce importujemy z „żywego organizmu”, więc kolejne importy różnią się zakresem oferty i informacjami. Każdy z nich był długotrwały (szczególnie dotyczący zdjęć), co bezpośrednio wynikało z bardzo dużej liczby indeksów. W konsekwencji przywrócenie pewnej synchronizacji zajmowało nam dosyć dużo czasu. Rozwiązaniem okazało się przesunięcie zasobów do testów, dzięki czemu szybciej identyfikowaliśmy błędy.
Kolejne wyzwanie stanowiła równoległa aktualizacja informacji produktowych w dwóch systemach. Tu rozwiązaniem stało się utworzenie kilku dodatkowych importerów wybranych atrybutów (w wersji X Pimcore udostępnił nowe narzędzie, które bardzo usprawniło proces masowej aktualizacji danych). W tym wypadku była to dla nas także dodatkowa korzyść. Wspomniane importery są bardzo doceniane przez użytkowników w zakresie szybkich zmian masowych w produktach, np. dodawania kategorii lub relacji do innego produktu.
Podsumowanie
Czy było warto? Zdecydowanie. W efekcie tego projektu znacznie usprawniono zarządzanie informacją produktową w wielu kanałach oraz procesy związane z aktualizacją produktów. Dzięki wdrożeniu PIM zyskaliśmy nowe narzędzia do zarządzania tłumaczeniami oraz drzewami kategorii publikacji.
5 wskazówek, jeśli decydujesz się na wdrożenie PIM (lub innej aplikacji) w e-sklepie
- Po analizie możliwie szybko przejdź do testów i zweryfikuj swoje założenia na prawdziwych danych.
- Wdrożenie prowadź iteracyjnie, aby jak najczęściej testować, czy na danym etapie wszystko przebiega poprawnie, znajdować błędy i je eliminować.
- Lepsze jest wrogiem dobrego – proste rozwiązania często są wystarczające. Zanim się zdecydujesz na zmianę, przeanalizuj konsekwencje i korzyści, jakie zamierzasz odnieść.
- Unikaj niekontrolowanej customizacji. Prowadzi ona do tworzenia unikatowego systemu, dopasowanego tylko do Twojej firmy, co z czasem może utrudnić Ci życie (brak aktualizacji przez producenta, konieczność utrzymywania zespołu programistów i trudności z ich zatrudnieniem w przypadku mało popularnych technologii).
- Usprawnienia i zmiany natywnych funkcji odłóż na koniec. Najlepiej wprowadzaj je na podstawie doświadczeń użytkowników, a nie założeń z etapu planowania projektu.
