Správa SKU pro více-dodavatelské trhy: Praktická příručka

Kdokoliv, kdo pracoval v e-commerce více než pár měsíců, se setkal s problémem SKU. Dva produkty se stejným kódem. Kód, který po šesti měsících nic neznamená. Podpora, která trvá dvacet minut na vyřešení, protože nikdo nemůže říct, který SKU byl skutečně odeslán.

Na obchodě s jednou značkou je to otravné. Na trhu s více prodejci, kde desítky nebo stovky prodejců vytvářejí svá vlastní produktová data, je to strukturální riziko, které se zvyšuje s každým novým prodejcem, který se připojí.

SKU vs. UPC: zmatení, které způsobuje skutečné problémy

Tyto dva pojmy se používají zaměnitelně, a to je skutečná chyba, nejen technická záležitost.

SKU, sklady udržovací jednotka, je interní kód, který vaše firma vytváří pro sledování konkrétní varianty produktu, je to vlastní systém, který má smysl pro vás a vaše dodavatele, nikoli pro někoho mimo váš trh. UPC, univerzální produktový kód, je externí, standardizovaný čárový kód přiřazený produktu, aby mohl být rozpoznán v jakémkoli maloobchodě nebo systému, který jej skenuje.

Praktický rozdíl je zde konkrétně důležitý: tržiště může a mělo by plně řídit svou vlastní strukturu SKU, protože je interní. UPC není něco, co si vymyslíte, je vydáno a musí zůstat v souladu s tím, co je vytištěno na skutečném produktu. Zacházení s těmito dvěma jako se stejnou věcí přímo vede k duplicitním seznamům, narušené synchronizaci zásob a vrácením, která nelze zpětně přiřadit k původní objednávce.

Proč je správa SKU na tržišti jiný problém

Obchod s jednou značkou musí dodržovat pouze jeden systém SKU, svůj vlastní. Všichni, kteří zadávají údaje o produktech, pracují pro stejný podnik, pod stejnými pravidly, ať už jsou tato pravidla sepsaná, nebo ne.

Trh to převrací. Každý prodejce přichází se svými vlastními zvyky, svými vlastními tabulkami, někdy se svým vlastním stávajícím systémem SKU z obchodu, který již jinde provozuje. Bez sdílené struktury zavedené při onboardingu skončíte s tolika různými logikami SKU, kolik máte prodejců, a bez spolehlivého způsobu, jak je prohledávat, reportovat nebo sloučit.

To je přesně důvod, proč správa SKU zasluhuje svůj vlastní promyšlený plán na tržišti, místo aby byla ponechána jako předpokládaný detail, který si dodavatelé prostě vyřeší.

Jak vypadá dobrá struktura SKU?

Konzistentní namingová konvence, aplikovaná na každého dodavatele.

Funkční struktura obvykle kóduje dodavatele, kategorii a variantu přímo do samotného kódu, něco jakoVEND-CAT-COLOR-VELIKOST. Přesný formát je méně důležitý než to, že každý dodavatel dodržuje stejný.

Jedinečnost je zajištěna na úrovni platformy, nikoli ponechána na důvěře.

Tržiště by mělo samo odmítnout SKU, která již jsou používána, namísto spoléhání se na dodavatele, aby si před zařazením produktu zkontrolovali možné konflikty.

Prostor pro růst bez nutnosti začínat znovu.

Pojmenovací konvence vytvořená pro 10 dodavatelů a 200 produktů by měla stále dávat smysl při 100 dodavatelích a 20 000 produktech, aniž by bylo potřeba uprostřed projektu provádět celkové přejmenování.

Jasné oddělení mezi SKU a jakýmkoli externím kódem.

UPC, čárové kódy a čísla dílů výrobců mohou být uloženy vedle SKU, ale neměly by být použity jako samotné SKU, protože nejsou vždy k dispozici, nejsou vždy jedinečné v různých kontextech a nejsou pod kontrolou tržiště.

Jak skutečně opravit a udržovat toto: krok za krokem

1. Definujte svůj formát SKU před zapojením svého prvního dodavatele.

• Rozhodněte, co se zakóduje do SKU: identifikátor dodavatele, kategorie a varianta jsou nejběžnější.
• Napište formát jako krátké, jednoduché pravidlo, které mohou dodavatelé dodržovat bez hádání.
• Považujte to za politiku platnou napříč platformou, nikoli za doporučení, které může každý dodavatel interpretovat po svém.

2. Vytvořte kontroly jedinečnosti v procesu onboardingu a při vytváření seznamu.

• Konfigurace produktu Shipturtlepodporuje strukturovaná pole a validaci potřebnou k zajištění zachycení duplicitního SKU před tím, než je nabídka zveřejněna
• Zamítněte SKU, která již existuje jinde na platformě, místo toho, abyste ji pouze označili.
• Udělej to automatické, nikoli jako ruční krok kontroly, na který si někdo musí pamatovat, aby ho spustil.

3. Úmyslně migrujte stávající dodavatele do nové struktury.

• Dodavatelé, kteří již mají svůj vlastní systém SKU, nebudou přecházet dobrovolně bez jasného důvodu a jednoduché cesty, jak to udělat.
• Nabídněte nástroj pro hromadné přepracování nebo krátké okno pro migraci, místo abyste očekávali ruční opětovné zadávání produktů jeden po druhém.
• Informujte o změně před jejím provedením, nikoli poté, co dodavatelé zjistí, že jejich staré SKU již nefungují.

4. Výslovně oddělte pole SKU od polí UPC a čárových kódů.

• Dejte dodavatelům samostatné pole pro UPC nebo kód výrobce, oddělené od pole SKU samotného.
• Použijte UPC pro skenování čárových kódů a rozpoznávání produktů, a SKU pro interní sledování a reportování.
• Vyhněte se jakémukoli výčtu, který tyto dvě oblasti považuje za zaměnitelné, protože právě tam začíná zmatení.

5. Provádějte audit duplicit a nesrovnalostí na pravidelném rozvrhu

• Jednorázové čištění nezůstává čisté, protože se neustále přidávají noví dodavatelé a nové produkty.
• Nastavte opakovanou kontrolu, měsíční je rozumné pro většinu tržišť, abyste zachytili odchylky, než se stanou skutečnou zátěží pro podporu.
• Považujte rostoucí počet podpůrných tiketů souvisejících s SKU jako raný signál, že je nutné přehodnotit současnou strukturu, a ne jen jednotlivé tikety k uzavření.

6. Spojte kvalitu SKU s tréninkem pro onboarding dodavatelů

• Noví dodavatelé by měli vidět požadavek na formát SKU během onboardingového procesu, nikoli ho zjistit až poté, co bude jejich první nabídka zamítnuta.
• Krátký, konkrétní příklad je účinnější než pouze písemná politika.
• Prodejci, kteří chápou důvody, rychlejší vyhledávání, méně sporů, čistší reporting, mají tendenci dodržovat pravidla ochotněji než ti, kteří jsou pouze instruováni, aby dodržovali pravidlo.

Co ovlivňuje náklady na chybný krok?

Úklid chaosu SKU po skutečnosti stojí mnohem více než jeho prevence. Marketplace s tisíci nekonzistentními, duplicitními nebo bezvýznamnými SKU čelí skutečnému projektu migrace dat, aby to zpětně opravila, přemapovala produkty, aktualizovala historické objednávky a znovu proškolila dodavatele, kteří si již vytvořili návyky kolem rozbitého systému.

Aplikace tržiště bez kódu zásadně mění výchozí bod, protože strukturovaná pole SKU a validace jedinečnosti již existují jako vestavěné funkce, spíše než něco, co se musí vytvářet od nuly poté, co se problém již projeví.Podívejte se, co je zahrnuto v sadě funkcí Shipturtle.a azkontrolujte aktuální cenypro přesná čísla.

Opravit to, než se to stane migračním projektem.

Čistá struktura SKU se mnohem lépe prosazuje od prvního dne než ji dodatečně přizpůsobovat poté, co se stovky dodavatelů už vytvořily vlastní návyky. Náklady na to, abychom to správně nastavili v začátku, jsou politickým rozhodnutím. Náklady na to, abychom to opravili později, jsou datovým projektem.

Rezervujte si ukázku.vidět, jak Shipturtle vynucuje strukturu SKU a zabraňuje duplikaci v okamžiku zveřejnění. Neboprozkoumejte kompletní sadu funkcíabyste viděli, co je předem připraveno, než začnete.