Zarządzanie SKU dla wielowariantowych rynków: Praktyczny przewodnik

Każdy, kto pracował w e-commerce przez więcej niż kilka miesięcy, napotkał problem SKU. Dwa produkty z tym samym kodem. Kod, który nic nie znaczy sześć miesięcy później. Zgłoszenie pomocy technicznej, które zajmuje dwadzieścia minut do rozwiązania, ponieważ nikt nie potrafi powiedzieć, który SKU faktycznie został wysłany.

W sklepie jednobrandowym jest to irytujące. W wielowalutowym markecie, gdzie dziesiątki lub setki dostawców tworzy własne dane o produktach, stanowi to ryzyko strukturalne, które kumuluje się z każdym nowym dostawcą, który dołącza.

SKU a UPC: zamieszanie, które powoduje prawdziwe problemy

Te dwa terminy są używane zamiennie, co jest rzeczywistym błędem, a nie tylko kwestią techniczną.

SKU, czyli jednostka magazynowa, to wewnętrzny kod, który Twoja firma tworzy w celu śledzenia konkretnej warianty produktu, systemu własnego, znaczącego dla Ciebie i Twoich dostawców, ale nie dla nikogo spoza Twojego rynku. UPC, czyli uniwersalny kod produktu, to zewnętrzny, standardowy kod kreskowy przypisany do produktu, aby mógł być rozpoznawany przez każdego detalistę lub system, który go skanuje.

Praktyczna różnica ma tu szczególne znaczenie: marketplace może i powinien całkowicie kontrolować swoją własną strukturę SKU, ponieważ jest to wewnętrzne. UPC nie jest czymś, co wymyślasz, jest nadawany i musi być spójny z tym, co jest wydrukowane na rzeczywistym produkcie. Traktowanie tych dwóch rzeczy jako jednych i tych samych prowadzi bezpośrednio do duplikatów ofert, problemów z synchronizacją zapasów oraz zwrotów, które nie mogą być przypisane z powrotem do pierwotnego zamówienia.

Dlaczego zarządzanie SKU to inny problem na rynku?

Sklep jednoorganizacyjny musi egzekwować tylko jeden system SKU, swój własny. Wszyscy wprowadzający dane produktowe pracują dla tej samej firmy, zgodnie z tymi samymi zasadami, niezależnie od tego, czy te zasady są zapisane, czy nie.

Rynek to odwraca. Każdy sprzedawca przyjeżdża z własnymi przyzwyczajeniami, własnymi arkuszami kalkulacyjnymi, a czasami z własnym istniejącym systemem SKU z sklepu, który już prowadzi gdzie indziej. Bez wspólnej struktury narzuconej podczas procesu onboardingu, kończysz z taką samą liczbą różnych logik SKU, jak masz sprzedawców, i bez niezawodnego sposobu na przeszukiwanie, raportowanie czy uzgadnianie między nimi.

Dokładnie dlatego zarządzanie SKU zasługuje na własny, przemyślany plan na rynku, zamiast być traktowane jako oczywisty szczegół, który sprzedawcy po prostu rozwiążą.

Czym tak naprawdę jest dobra struktura SKU?

Spójna konwencja nazewnictwa, stosowana do każdego dostawcy.

Struktura, która działa, zazwyczaj koduje dostawcę, kategorię i wariant bezpośrednio w kodzie, coś takiego jakWYSK-CAT-KOLOR-ROZMIARDokładny format ma mniejsze znaczenie niż fakt, że każdy dostawca stosuje się do tego samego.

Unikalność wymuszana na poziomie platformy, a nie pozostawiana do zaufania.

Rynek powinien odrzucić SKU, który jest już w użyciu, zamiast polegać na dostawcach, aby sami sprawdzali konflikty przed wystawieniem produktu.

Miejsce na rozwój bez rozpoczynania od nowa.

Konwencja nazewnictwa stworzona dla 10 dostawców i 200 produktów powinna nadal mieć sens przy 100 dostawcach i 20 000 produktach, bez potrzeby przeprowadzania pełnego projektu zmiany nazw w połowie drogi.

Wyraźne rozdzielenie między SKU a wszelkimi zewnętrznymi kodami.

Numery UPC, kody kreskowe oraz numery części producenta mogą być przechowywane obok SKU, ale nie powinny być używane jako same SKU, ponieważ nie zawsze są dostępne, nie zawsze są unikalne w różnych kontekstach i nie są pod kontrolą rynku.

Jak rzeczywiście naprawić i utrzymać to: krok po kroku

1. Zdefiniuj format SKU przed rozpoczęciem współpracy z pierwszym dostawcą.

• Zdecyduj, co ma być zakodowane w SKU: identyfikator dostawcy, kategoria i wariant to najczęstsze elementy.
• Napisz format jako krótką, prostą zasadę, którą sprzedawcy mogą stosować bez zgadywania.
• Traktuj to jako politykę obowiązującą na całej platformie, a nie jako sugestię, którą każdy dostawca może interpretować na swój sposób.

2. Wprowadź kontrole unikalności w procesie onboardingu i dodawania ogłoszeń.

• Konfiguracja produktu Shipturtleobsługuje strukturalne pola i walidację, które są potrzebne do wychwycenia duplikującego się SKU zanim ogłoszenie stanie się aktywne
• Odrzuć, zamiast tylko zgłaszać, SKU, który już istnieje w innym miejscu na platformie.
• Zautomatyzuj to, aby nie było potrzeby ręcznego przeglądu, o którym ktoś musi pamiętać, aby go uruchomić.

3. Świadomie przenieś istniejących dostawców do nowej struktury.

• Dostawcy, którzy już mają własny system SKU, nie będą się dobrowolnie zmieniać bez wyraźnego powodu i prostego sposobu na to.
• Oferuj narzędzie do masowej zmiany mapowania lub krótki okres migracji, zamiast oczekiwać ręcznego wprowadzania produktów jeden po drugim.
• Poinformuj o zmianie przed jej wdrożeniem, a nie po tym, jak dostawcy odkryją, że ich stare SKU już nie działają.

4. Wyraźnie oddziel pola SKU od pól UPC i kodów kreskowych.

• Daj dostawcom wyraźne pole na kod UPC lub kod producenta, oddzielone od samego pola SKU.
• Użyj UPC do skanowania kodów kreskowych i rozpoznawania produktów, a SKU do śledzenia wewnętrznego i raportowania.
• Unikaj wszelkich schematów, które traktują te dwa pola jako wymienne, ponieważ to właśnie tam zaczyna się zamieszanie.

5. Audyt w poszukiwaniu duplikatów i niespójności w regularnym harmonogramie.

• Jednorazowe sprzątanie nie pozostaje czyste, ponieważ ciągle dodawani są nowi dostawcy i nowe produkty.
• Ustaw cykliczny przegląd, co miesiąc jest rozsądne dla większości rynków, aby wykryć odchylenia, zanim staną się prawdziwym obciążeniem dla wsparcia.
• Traktuj rosnącą liczbę zgłoszeń związanych z SKU jako wczesny sygnał, że obecna struktura wymaga przeanalizowania, a nie tylko zamykania pojedynczych zgłoszeń.

6. Połącz jakość SKU z treningiem onboardingu dostawców

• Nowi dostawcy powinni zobaczyć wymagania dotyczące formatu SKU podczas wprowadzania, a nie odkrywać je po odrzuceniu ich pierwszej oferty.
• Krótkie, konkretne przykłady są bardziej efektywne niż sama polityka pisemna.
• Dostawcy, którzy rozumieją powody, szybsze wyszukiwanie, mniej sporów, czystsze raportowanie, zazwyczaj chętniej przestrzegają zasad niż ci, którzy są po prostu informowani o przestrzeganiu reguły.

Co sprawia, że koszt błędnego wykonania tego jest tak wysoki?

Zarządzanie chaosem SKU po fakcie kosztuje znacznie więcej niż zapobieganie mu. Rynek z tysiącami niespójnych, zduplikowanych lub bezsensownych SKU staje w obliczu rzeczywistego projektu migracji danych, aby naprawić to retrospektywnie, przemapowując produkty, aktualizując historyczne zamówienia i ponownie szkoląc dostawców, którzy już wyrobili sobie nawyki związane z uszkodzonym systemem.

Aplikacja marketplace bez kodu znacznie zmienia punkt wyjścia, ponieważ strukturalne pola SKU i walidacja unikalności są już wbudowanymi funkcjami, a nie czymś, co należy stworzyć od podstaw, gdy problem jest już widoczny.Zobacz, co zawiera zestaw funkcji Shipturtle.isprawdź aktualne cenydla dokładnych liczb.

Napraw to, zanim stanie się projektem migracyjnym.

Czysta struktura SKU jest znacznie łatwiejsza do wdrożenia od pierwszego dnia niż do naprawienia, gdy setki dostawców już przyzwyczaiły się do niej. Koszt poprawnego wdrożenia na początku to decyzja polityczna. Koszt naprawy później to projekt związany z danymi.

Zarezerwuj demonstracjęaby zobaczyć, jak Shipturtle egzekwuje strukturę SKU i zapobiega duplikacji w punkcie wystawienia. Lubprzeglądaj pełny zestaw funkcjiaby zobaczyć, co jest wbudowane, zanim zaczniesz.