Jedno źródło prawdy o produkcie. Dlaczego w naszym sklepie niczego nie poprawiamy ręcznie

Pod koniec września puściłem prosty raport po naszej bazie produktów: porównaj kartotekę produktu z jego wariantami i pokaż, gdzie coś się nie zgadza. Spodziewałem się kilkunastu pozycji. Wyszło 168 kartotek na 240. W 58 opis był wpisany tylko w wariancie, a w produkcie głównym pustka. W 58 tytuł SEO różnił się między rodzicem a dzieckiem. Dwanaście nie miało żadnego zdjęcia. A na deser formularz „Dodaj produkt” zapisywał opis do pola, którego sklep w ogóle nie czytał - więc ktoś starannie pisał opisy, które nigdy nie trafiały do klienta.

Nikt w tym zespole nie zrobił niczego głupiego. Każdy poprawiał to, co miał przed oczami, tam, gdzie akurat pracował. I właśnie dlatego to się rozjechało. Prowadzę agencję AI i automatyzacji dla MŚP, a razem ze wspólnikiem prowadzę też mały sklep ze sprzętem do hokeja na trawie - i wszystko, co radzę klientom w handlu, najpierw sprawdzam na tym sklepie. Opowiem, dlaczego u nas obowiązuje zasada, że w sklepie niczego się nie poprawia, jak wyglądały porządki 26 września i co poszło nie tak po drodze.

Spis treści

• Skąd w małym sklepie bierze się bałagan w danych?
• Co to znaczy, że panel jest jedynym źródłem prawdy?
• Dlaczego reguły trzymamy w bazie, a nie w głowie?
• Jak wyglądały porządki 26 września?
• Gdzie pracowała AI, a gdzie jej nie wpuściłem?
• Na czym sami się potknęliśmy?
• Czy twoja firma potrzebuje takiego panelu?
• Od czego zacząć u siebie?
• Słownik pojęć

Skąd w małym sklepie bierze się bałagan w danych?

Weź jeden kij hokejowy. Ma nazwę od producenta, kod EAN z etykiety, długość, wygięcie, skład (ile węgla, ile włókna szklanego), cenę, zdjęcia, opis po polsku i po angielsku, kategorię i markę. Teraz pomnóż to przez rozmiary i kolory. Mamy kilkaset wariantów od kilku zagranicznych marek, a każda marka przysyła dane w innym formacie: jedna arkusz eksportu ze swojego sklepu, druga PDF z cennikiem, trzecia zdjęcie etykiety w mailu.

Te same dane muszą potem pojawić się w kilku miejscach naraz. W sklepie internetowym. Na kasie na stoisku, kiedy sprzedajemy na turnieju. Na marketplace, który właśnie podłączamy. Na fakturze. W raporcie, który pokazuje, ile zarobiliśmy na danym modelu.

I tu zaczyna się problem, który zna każdy, kto prowadzi sprzedaż w więcej niż jednym kanale. Jeśli każde z tych miejsc ma własną kopię danych, każda kopia zaczyna żyć własnym życiem. Ktoś zauważy literówkę w sklepie, to poprawi w sklepie. Kasa wymaga krótszej nazwy, to ktoś skróci na kasie. Na marketplace trzeba dopisać kolor po angielsku, bo inaczej nie przejdzie. Po trzech miesiącach masz cztery wersje tego samego kija i nikt nie wie, która jest prawdziwa.

Najlepiej tłumaczy to analogia z zegarkami. Jeśli w domu masz zegar w kuchni, na piekarniku, w telefonie i na ścianie w salonie, i każdy przestawiasz ręcznie, to po miesiącu każdy pokazuje trochę inną godzinę. Nie dlatego, że któryś jest zepsuty. Dlatego, że każdy poprawiasz osobno. Telefon ma dokładną godzinę, bo bierze ją z jednego źródła i nikt jej nie dotyka. Z danymi produktu jest dokładnie tak samo.

Najgorsze jest to, że ten bałagan nie boli od razu. Boli przy inwentaryzacji, kiedy stan w sklepie nie zgadza się ze stanem na półce. Boli, kiedy klient kupuje kij w rozmiarze, którego nie ma, bo sklep pokazywał stary stan. Boli przy rozliczeniu dostawy, kiedy nie da się przypisać kosztu zakupu do produktu, bo w fakturze jest jedna nazwa, w sklepie druga, a na kasie trzecia.

Co to znaczy, że panel jest jedynym źródłem prawdy?

U nas wszystkie dane o produkcie żyją w jednym miejscu: w panelu, który zbudowaliśmy na własne potrzeby. Nazwy, kody, ceny, opisy, zdjęcia, stany magazynowe, koszty zakupu i sprzedaż. Sklep, kasa i marketplace nie są miejscami, gdzie dane się tworzy. Są miejscami, do których dane się wysyła.

Kierunek jest jeden i nie ma od niego wyjątków. Panel mówi sklepowi, jak nazywa się produkt, ile kosztuje i ile go mamy. Sklep nigdy nie mówi panelowi, jak ma się nazywać produkt. W drugą stronę płyną tylko zdarzenia: ktoś złożył zamówienie, ktoś zapłacił, paczka została doręczona. Fakty o sprzedaży, nie fakty o produkcie.

Brzmi jak biurokracja, ale w praktyce jest odwrotnie. Wysyłka zmian do sklepu chodzi automatycznie co minutę. Poprawiasz cenę w panelu, za chwilę jest w sklepie. Nie musisz pamiętać, że trzeba jeszcze zmienić na kasie i w arkuszu dla księgowej.

A co, jeśli ktoś zobaczy literówkę w sklepie?

Zgłasza ją i poprawia w panelu. Nie w sklepie. To jest jedyna zasada, którą trzeba wbić wszystkim do głowy, i jedyna, której łamanie od razu się mści. Poprawka zrobiona bezpośrednio w sklepie zostanie nadpisana przy najbliższej synchronizacji, bo panel wyśle swoją wersję. Albo, co gorsze, przetrwa w sklepie, a w panelu zostanie stara wersja i wtedy masz dwa zegarki pokazujące różne godziny.

Dlatego u nas „nie poprawiamy w sklepie” nie jest prośbą, tylko opisem tego, jak działa system. Nawet gdybyś chciał, poprawka w sklepie nie przeżyje.

Kasa i marketplace dostają to samo

W połowie września przeładowaliśmy bazę towarów na kasie fiskalnej, której używamy na turniejach. Zanim cokolwiek skasowaliśmy, odczytaliśmy z kasy dotychczasową bazę i zapisaliśmy ją do pliku: 146 towarów. Potem wygenerowaliśmy nową bazę prosto z panelu, przejrzałem listę i dopiero wtedy poszło 468 wariantów, zero błędów. Kasa wymaga unikalnych nazw, więc tam, gdzie dwa warianty nazywały się tak samo, automat sam dopisał rozróżnienie. Ręcznie nikt niczego na kasie nie wpisywał.

Z marketplace jesteśmy na etapie zakładania kont i dostępu do API. Ale zasada obowiązuje od pierwszego dnia: oferty powstaną z panelu, a dopasowanie do katalogu marketplace pójdzie po kodzie EAN, nie po nazwie. Jeśli raz pozwolisz, żeby marketplace miał „swoją” wersję produktu, za pół roku będziesz ją utrzymywał ręcznie.

Jeśli brzmi to dla ciebie abstrakcyjnie, to jak systemy w ogóle wymieniają się danymi, opisałem bez żargonu w tekście o tym, co naprawdę znaczy, że systemy „gadają”.

Dlaczego reguły trzymamy w bazie, a nie w głowie?

W większości firm reguły danych istnieją w formie wiedzy plemiennej. „Pamiętaj, żeby zawsze wpisać EAN.” „Nie usuwaj produktu, który już się sprzedawał.” „Kolor piszemy po polsku.” Ktoś to wie, ktoś to przekazał nowej osobie, ktoś zapomniał. Czasem jest nawet dokument w Wordzie z zasadami, którego nikt nie otwierał od roku.

U nas najważniejsze reguły siedzą w samej bazie danych jako twarde blokady. Baza po prostu nie przyjmie zapisu, który je łamie:

• wariant musi mieć kod EAN, cenę większą od zera i przypisany produkt główny
• zatwierdzonego produktu nie da się usunąć
• nie mogą istnieć dwa produkty główne o tej samej nazwie ani dwa warianty z tym samym EAN-em

To jest różnica między tabliczką „prosimy nie wjeżdżać” a szlabanem. Tabliczka działa, dopóki wszyscy są uważni. Szlaban działa także w piątek o osiemnastej, kiedy ktoś się spieszy. Przy danych, które idą do klienta, wolę szlaban.

Co z produktami bez kodu kreskowego?

Część towaru przychodzi bez EAN-u. Zamiast robić wyjątek w regule, każdy wariant dostał nasz własny kod (z prefiksem 2, który jest zarezerwowany do użytku wewnętrznego), a do tego ma SKU. Skaner szuka kaskadą: najpierw kod producenta, potem nasz, potem SKU. Reguła została twarda, a towar bez etykiety producenta i tak da się sprzedać i przyjąć na magazyn.

Co baza robi, kiedy ktoś się pomyli?

Odrzuca zapis i mówi dlaczego. Człowiek poprawia i zapisuje jeszcze raz. To irytuje dokładnie przez pierwszy tydzień. Potem wszyscy przyzwyczajają się, że panel nie przepuści produktu bez ceny, i przestają o tym myśleć. A ja przestaję się bać, że jutro rano w sklepie będzie kij za zero złotych.

Jest w tym też dobra lekcja dla pracy z AI. Model językowy, któremu każesz „pamiętaj, żeby zawsze wpisać EAN”, zachowuje się jak bardzo pracowity stażysta - zwykle pamięta, czasem nie. Baza z blokadą nie ma gorszych dni. Dlatego wszędzie, gdzie się da, zamieniam reguły zapisane w notatkach na reguły zapisane w kodzie.

Jak wyglądały porządki 26 września?

Sam system z blokadami nie naprawia przeszłości. Dane, które weszły do bazy wcześniej, w czasie gorączkowego zatowarowania przed sezonem, miały wszystkie grzechy, o których pisałem na początku. 26 września zrobiliśmy jeden duży przegląd. Trzy liczby z tego dnia mówią najwięcej.

879 pustych pól uzupełnionych

Każdy produkt u nas to rodzic (produkt główny, np. konkretny model kija) i co najmniej jeden wariant (np. długość 36,5 cala). Część informacji jest wspólna dla wszystkich wariantów: dostawca, kraj pochodzenia, przeznaczenie na halę albo na trawę, poziom zaawansowania, skład, wygięcie, opis. Te pola powinny żyć w rodzicu. W praktyce często wpisywano je w wariancie, a rodzic zostawał pusty.

Skrypt przeszedł po wszystkich kartotekach i tam, gdzie rodzic miał puste pole, a warianty miały zgodną wartość, przeniósł ją wyżej. Wyszło 879 pól w 155 kartotekach: dostawca w 119, kraj w 117, hala lub trawa w 115, poziom w 79, skład w 78, wygięcie w 72, opisy po polsku w 58 i po angielsku w 57. Przed zapisem kopia bazy, po zapisie kontrola, że ładunek, który pójdzie do sklepu, nie zmienił się ani o jedno pole. Zmienił się tylko porządek wewnątrz.

Przy okazji naprawiłem formularz „Dodaj produkt”, który zapisywał opisy w złym miejscu. Pewnie to była najcenniejsza poprawka tego dnia, bo zamykała źródło bałaganu, a nie sprzątała jego skutki.

165 nazw ujednoliconych

Nazwy produktów głównych były mieszanką wszystkiego. Wielkie litery skopiowane z faktury dostawcy. Kolor i rozmiar w nazwie, choć to są cechy wariantu. Polskie słowa doklejone do angielskiej nazwy modelu. Ta sama marka raz pisana z wielkiej, raz małymi.

Ustaliliśmy jedną zasadę: nazwa produktu to marka plus nazwa handlowa producenta, w jego zapisie. Bez koloru, bez rozmiaru, bez polskich dopisków. Polski typ produktu („kij do hokeja halowego”, „rękawica na halę i trawę”) idzie do tytułu SEO, czyli tam, gdzie pracuje na wyszukiwarkę, a nie zaśmieca nazwę. Kolory wariantów po polsku, małymi literami, kombinacje przez ukośnik. Rozmiary jednym zapisem: XS, S, M, L, XL.

Według tej zasady zmieniliśmy 165 nazw. Kilkadziesiąt kolejnych świadomie wstrzymaliśmy, bo wymagały decyzji, której nie dało się podjąć zza biurka - brak katalogu producenta, niejasne, czy to wersja dla juniora, produkty marki własnej, o których decyduje wspólnik.

11 grup duplikatów scalonych

Najbardziej podstępny problem: ten sam produkt istniał w bazie dwa albo trzy razy. Zwykle dlatego, że kolejna dostawa przyszła z trochę inaczej zapisaną nazwą i system uznał ją za nowy produkt. W sklepie wyglądało to tak, że klient widział dwa takie same ochraniacze, jeden w kolorze białym, drugi w granatowym, zamiast jednego produktu z wyborem koloru.

Scaliliśmy 11 takich grup. Ważne, jak: nie przez kasowanie i zakładanie od nowa, tylko przez przepięcie wariantów do jednego rodzica. Wariant ze swoim EAN-em, stanem i historią sprzedaży zostaje ten sam, zmienia mu się tylko „rodzic”. Przed zmianą sprawdziliśmy, czy nie powstaną dwa warianty z tym samym rozmiarem i kolorem pod jednym produktem. Po zmianie policzyliśmy stan magazynu: 2 621 sztuk przed, 2 621 po.

Po scaleniu zostało 12 pustych produktów głównych, bez żadnego wariantu. Usunięcie to operacja nieodwracalna, więc poszła dopiero po trzech krokach: kopia bazy, lista dwunastu numerów do przejrzenia, wyraźne „rób” dopiero po niej. Do tego mapa starych adresów w sklepie na nowe, żeby ktoś, kto zapisał stary link, nie trafił na pustą stronę.

Do sklepu zmienione nazwy nie poszły od razu. Najpierw zapytaliśmy programistę sklepu, czy zmiana nazwy nie zmieni adresu strony produktu. Gdyby zmieniała, stracilibyśmy pozycje w Google na kilka tygodni. Nie zmienia. Kilka dni później pełna synchronizacja przeszła przez 218 kartotek bez jednego błędu.

Gdzie pracowała AI, a gdzie jej nie wpuściłem?

Przy 240 kartotekach ręczne przejrzenie każdej nazwy to dzień pracy kogoś, kto zna asortyment. Tu AI rzeczywiście się przydała, ale w ściśle określonej roli.

Jeden agent dostał zasadę nazewnictwa i listę wszystkich nazw, i zaproponował nowe. Drugi agent dostał te same zasady i propozycje pierwszego, z zadaniem: znajdź błędy. Recenzja dała 154 propozycje do przyjęcia, 11 do poprawy i 32 do wstrzymania. Taki układ, w którym jeden model pisze, a drugi sprawdza, opisałem dokładniej przy okazji testu, czy można ufać sędziemu AI. Tu zadziałał dobrze, bo zadanie było wąskie, a kryteria jasne.

Natomiast AI nie zapisywała niczego do bazy. Zmiany wprowadzał zwykły skrypt z dwoma bezpiecznikami. Zmieniał tylko produkty główne, nigdy warianty. I zmieniał nazwę tylko wtedy, gdy nazwa w bazie była dokładnie taka sama jak ta, od której zaczynała się propozycja. Jeśli ktoś w międzyczasie poprawił coś ręcznie, skrypt to pomijał zamiast nadpisywać.

To jest podział, którego trzymam się przy każdym wdrożeniu: model językowy proponuje, człowiek decyduje, a zapisuje deterministyczny kod z blokadami. AI jest świetna w czytaniu bałaganu i rozpoznawaniu, że „GRYPHON CLASSIC SHINGUARDS WHITE L” i „Gryphon Classic Shinguards” to ten sam produkt. Gorzej z konsekwencją przy pięćsetnym rekordzie. Jeśli masz w bazie kilka wersji tej samej informacji, AI wybierze którąś z nich i nie zawsze tę, której się spodziewasz - pisałem o tym w tekście o czterech cennikach w jednej bazie. Jedno źródło prawdy to nie tylko porządek dla ludzi. To warunek, żeby AI w ogóle mogła na tych danych pracować.

Na czym sami się potknęliśmy?

Gdybym napisał, że od początku wszystko szło gładko, nie byłbym uczciwy. Trzy potknięcia, wszystkie pouczające.

Pod koniec sierpnia testowałem pierwszy import produktów z panelu do sklepu. Test robiłem na żywym sklepie, a import rozpoznawał „ten sam produkt” po nazwie. Trafił na produkty, które programista sklepu założył wcześniej ręcznie, uznał je za swoje i przestawił na szkice. Na produkcji. Przywróciłem je z kopii, ale lekcja została: test na żywej bazie musi być odizolowany, a produkty rozpoznaje się po kodzie, nigdy po nazwie. Od tamtej pory kluczem jest EAN i nic innego.

Drugie potknięcie było jeszcze bardziej wstydliwe, bo dotyczyło dokładnie tego, o czym jest ten tekst. Panel sam zakłada w sklepie marki i kategorie. Nasz kod porównywał marki tylko po skrócie w adresie. Jedna marka występowała u nas pod pełną nazwą, a w sklepie pod skrótem, więc kod uznał, że jej nie ma, i założył drugą. Ta sama marka, dwie strony w sklepie, jedna z zerem produktów. Poprawka była prosta (porównanie po skrócie i po nazwach w obu językach), ale wpadka była nasza, nie sklepu.

Trzecie wyszło przy ujednolicaniu kolorów. Panel wysłał poprawiony słownik, a sklep zamiast zastąpić stare wartości, dopisał nowe obok starych. W 107 produktach pojawiło się łącznie 209 nadmiarowych wartości: ten sam ochraniacz miał kolor „czarny” i „Black” jednocześnie. Szczerze? Miałem ochotę wejść do panelu sklepu i wyklikać to ręcznie. Byłoby szybciej o jakieś pół dnia. Nie zrobiłem tego, bo naprawiłbym objaw, a przy następnej wysyłce problem wróciłby w tym samym miejscu. Programista sklepu poprawił odbiornik tak, żeby lista wartości była zastępowana, a nie uzupełniana, i po dwóch pełnych synchronizacjach w sklepie nie było ani jednej starej wartości.

Wspólny mianownik: każdy z tych błędów powstał na styku dwóch systemów, a nie w żadnym z nich osobno. I każdy dało się naprawić raz, w jednym miejscu, właśnie dlatego, że kierunek przepływu danych był jasny.

Czy twoja firma potrzebuje takiego panelu?

Nie zawsze. I mówię to jako ktoś, kto taki panel zbudował.

Jeśli sprzedajesz trzydzieści produktów w jednym sklepie internetowym, bez wariantów, bez kasy i bez marketplace, nie potrzebujesz osobnego systemu. Sklep jest wtedy twoim źródłem prawdy i wystarczy go pilnować. Zbudowanie panelu i synchronizacji kosztowałoby więcej niż wszystkie twoje literówki przez najbliższe pięć lat.

Zasada jednego źródła obowiązuje jednak każdego. Nawet przy małej skali ustal, gdzie jest wersja prawdziwa: może to być sklep, może arkusz, może program magazynowy. I trzymaj się tego, że poprawki robi się tylko tam. To nic nie kosztuje, a oszczędza dokładnie tego bałaganu, który opisałem na początku.

Osobny panel zaczyna mieć sens, kiedy spotkają się trzy rzeczy:

• więcej niż jeden kanał sprzedaży - sklep plus kasa, sklep plus marketplace, dwa sklepy w różnych językach
• warianty - rozmiary, kolory, długości, czyli dziesiątki rekordów zależnych od jednego produktu
• koszt błędu wyższy niż koszt pilnowania - sprzedaż towaru, którego nie ma, zwroty, zła cena na kasie, nierozliczone koszty dostawy

U nas wszystkie trzy były od pierwszego miesiąca. Kilkaset wariantów, sklep, kasa na turniejach, marketplace w drodze, towar z importu z cłem i transportem, który trzeba rozłożyć na konkretne sztuki, żeby wiedzieć, ile zarabiamy na danym modelu. Przy takim układzie pytanie nie brzmiało „czy”, tylko „jak szybko”.

Jeśli masz w firmie arkusz, który trzy osoby edytują na zmianę, i do tego sklep, w którym ktoś „na szybko” poprawia ceny, to jesteś dokładnie w tym miejscu, w którym my byliśmy w sierpniu. Nie potrzebujesz od razu własnego systemu. Potrzebujesz decyzji, która kopia jest prawdziwa.

Od czego zacząć u siebie?

Gdybym miał to zrobić jeszcze raz w innej firmie, kolejność byłaby taka:

1. Wybierz jedno źródło i ogłoś to zespołowi. Jedno zdanie: „dane produktu poprawiamy tylko w X”. Bez tej decyzji żadna technologia nie pomoże. 2. Wybierz klucz, po którym rozpoznajesz produkt. Kod EAN, SKU, własny numer. Nigdy nazwa, bo nazwy się zmieniają, a klucz musi zostać na zawsze. Jeśli towar nie ma EAN-u, nadaj mu własny kod. 3. Ustal kierunek przepływu. Dane o produkcie płyną ze źródła do kanałów. Z kanałów wracają tylko zdarzenia: zamówienie, płatność, zwrot. 4. Zamień trzy najważniejsze zasady w blokady. Nie dokument z zasadami, tylko pole, którego nie da się zostawić pustym, cena, której nie da się wpisać jako zero, produkt, którego nie da się usunąć po pierwszej sprzedaży. 5. Zrób jeden porządny przegląd i policz rozbieżności. Najpierw raport, potem decyzje, potem zmiany. Każda zmiana z kopią bazy przed i kontrolą po. 6. Najpierw zamknij źródło bałaganu, potem sprzątaj. Formularz, który zapisuje w złym miejscu, napraw przed porządkami, inaczej będziesz sprzątał w nieskończoność. 7. Usuwaj na końcu i ostrożnie. Scalanie przez przepięcie wariantów, kasowanie tylko pustych rekordów, po zgodzie i z mapą starych adresów.

Nie musisz mieć do tego zespołu programistów. Pierwsze trzy kroki to decyzje, nie kod. Kod jest potrzebny dopiero wtedy, gdy kanałów jest tyle, że ręczne przenoszenie zmian zaczyna zjadać godziny.

Słownik pojęć

• Jedno źródło prawdy - jedno miejsce, w którym dane uznaje się za prawdziwe i tylko tam się je zmienia. Wszystkie inne systemy dostają z niego kopię i niczego w niej nie poprawiają.
• Produkt główny i wariant - produkt główny (rodzic) to model, np. konkretny kij. Wariant to jego wersja, którą fizycznie sprzedajesz, np. ten kij w długości 36,5 cala. Stan magazynowy i kod EAN ma wariant.
• EAN - numer pod kodem kreskowym na produkcie, nadawany przez producenta. Najlepszy klucz do rozpoznawania produktu między systemami, bo się nie zmienia.
• SKU - wewnętrzny kod produktu w sklepie lub magazynie. Pomaga, gdy EAN-u brakuje.
• Synchronizacja - automatyczne przesyłanie zmian z jednego systemu do drugiego, np. z panelu do sklepu co minutę.
• Blokada w bazie danych - reguła wpisana w samą bazę, która odrzuca błędny zapis, np. wariant bez ceny. Działa niezależnie od tego, kto i jakim programem próbuje coś zapisać.
• Tytuł SEO - tytuł strony produktu widoczny w wynikach Google. Może zawierać polskie określenie produktu, choć sama nazwa produktu pozostaje oryginalna.

Ile wersji jednego produktu masz dziś w firmie?

Zrób prosty test: weź swój najlepiej sprzedający się produkt i porównaj jego nazwę, cenę i opis w sklepie, w programie magazynowym, na kasie i w arkuszu, który trzyma ktoś z zespołu. Jeśli wszędzie jest to samo, masz porządek, którego wiele firm może ci pozazdrościć. Jeśli nie, napisz do mnie na [email protected]. Zwykle wystarczy jedna rozmowa, żeby ustalić, gdzie powinna być wersja prawdziwa i co da się zrobić bez budowania czegokolwiek od zera.