SKU-hallinta monikauppapaikoille: käytännön opas

Kukaan, joka on työskennellyt verkkokaupassa enemmän kuin muutaman kuukauden, on törmännyt SKU-ongelmaan. Kaksi tuotetta, joilla on sama koodi. Koodi, joka ei merkitse mitään kuuden kuukauden kuluttua. Tuki-pyyntö, jonka ratkaisemiseen menee kaksikymmentä minuuttia, koska kukaan ei voi kertoa, mikä SKU on oikeasti lähetetty.

Yhden brändin myymälässä tämä on hermoja raastavaa. Monen myyjän markkinapaikassa, jossa kymmenet tai sadat myyjät luovat omia tuotedatojaan, se on rakenteellinen riski, joka kasvaa joka kerta, kun uusi myyjä liittyy mukaan.

SKU vs. UPC: hämmennys, joka aiheuttaa todellisia ongelmia

Näitä kahta termiä käytetään vaihtelevasti, ja se on todellinen virhe, ei vain tekninen yksityiskohta.

SKU, varastonhallintakoodi, on sisäinen koodi, jonka liiketoimintasi luo seurataksesi tiettyä tuotevarianttia, oma järjestelmä, joka on merkityksellinen sinulle ja myyjillesi, mutta ei kenellekään muulle markkinapaikallasi. UPC, yleinen tuotetunnus, on ulkoinen, standardoitu viivakoodi, joka on annettu tuotteelle, jotta se voidaan tunnistaa missä tahansa vähittäiskaupassa tai järjestelmässä, joka skannaa sen.

Käytännöllinen ero on tässä erityisen tärkeä: markkinapaikan täytyy pystyä ja sen tulee kontrolloida omaa SKU-rakennettaan täysin, koska se on sisäinen. UPC ei ole jotain, jonka keksit itse, se myönnetään ja sen on pysyttävä yhdenmukaisena sen kanssa, mitä on painettu itse tuotteeseen. Näiden käsitteleminen samanlaisina asioina johtaa suoraan päällekkäisiin luetteloihin, rikkoutuneeseen varaston synkronointiin ja palautuksiin, joita ei voida yhdistää alkuperäiseen tilaukseen.

Miksi SKU-hallinta on eri ongelma markkinapaikalla?

Yhden brändin myymälä tarvitsee vain valvoa yhtä SKU-järjestelmää, omaansa. Kaikki tuotteita syöttävät työntekijät työskentelevät samalle liiketoiminnalle, samoilla säännöillä, olivatpa säännöt kirjattuina tai eivät.

Markkinapaikka kääntää tämän ympäri. Jokainen myyjä saapuu omien tapojensa, omien taulukkolaskentataulujensa kanssa, joskus myös oman olemassa olevan SKU-järjestelmänsä kanssa, joka on peräisin kaupasta, jota he jo ylläpitävät muualla. Ilman yhteistä rakennetta, joka pakotetaan perehdytyksessä, päädytään niin moneen eri SKU-logiikkaan kuin on myyjiä, eikä luotettavaa tapaa etsiä, raportoida tai sovittaa näitä yhteen.

Juuri siksi SKU-hallinnan ansaitsee oman harkitun suunnitelmansa markkinapaikalla sen sijaan, että se jätettäisiin olettamukseksi, jonka myyjät vain selvittävät.

Miltä hyvä SKU-rakenne todellisuudessa näyttää?

Johdonmukainen nimeämiskäytäntö, joka on sovellettu jokaiseen toimittajaan.

Toimiva rakenne koodaa tyypillisesti myyjän, kategorian ja variantin itse koodiin, jotain kutenVEND-CAT-VÄRI-KOOSTUMUSTarkka muoto on vähemmän tärkeä kuin se, että jokainen myyjä noudattaa samaa.

Yksilöllisyys varmistettu alustan tasolla, ei jätetty luotettavaksi.

Markkinapaikan tulisi itse hylätä SKU, joka on jo käytössä, sen sijaan että luottaisi myyjiin tarkistamaan ristiriitoja itse ennen tuotteen listaamista.

Tilaa laajentaa ilman, että aloitat alusta.

Nimien käyttöönottokäytäntö, joka on rakennettu 10 toimittajalle ja 200 tuotteelle, tulisi silti olla järkevä 100 toimittajalle ja 20 000 tuotteelle ilman, että tarvitaan täydellistä uudelleennimeämisprojektia kesken matkan.

Selkeä erottelu SKU:n ja minkä tahansa ulkoisen koodin välillä.

UPC:t, viivakoodit ja valmistajan osanumeroita voidaan tallentaa SKU:n rinnalle, mutta niitä ei tulisi käyttää SKU:na itsessään, koska ne eivät aina ole saatavilla, eivätkä ne ole aina ainutlaatuisia eri konteksteissa, eikä niitä hallitse markkinapaikka.

Kuinka korjata ja ylläpitää tätä: askel askeleelta

1. Määritä SKU-muotosi ennen ensimmäisen myyjäsi liittymistä.

• Päätä, mitä koodataan SKU:hun: myyjän tunniste, kategoria ja variantti ovat yleisimmät.
• Kirjoita muoto selkeänä, yksinkertaisena sääntönä, jota myyjät voivat seurata ilman arvailuja.
• Kohdista tämä koko alustan laajuiseksi määräykseksi, ei ehdotukseksi, jota jokainen myyjä voi tulkita omalla tavallaan.

2. Rakenna ainutlaatuisuus tarkistuksia rekrytointi- ja listausprosessiin.

• Shipturtlen tuotekonfiguraatiotukee strukturoidut kentät ja validoinnin, joka tarvitaan tupla SKU:n havaitsemiseksi ennen kuin lista julkaistaan.
• Hylkää, sen sijaan että vain liputtaisit, SKU, joka jo exists elsewhere on the platform.
• Tee tästä automaattinen, ei manuaalinen tarkistusaskel, jonka joku joutuu muistamaan suorittaa.

3. Siirrä olemassa olevat toimittajat uuteen rakenteeseen harkitusti

• Myyjät, joilla on jo oma SKU-järjestelmä, eivät vaihda vapaaehtoisesti ilman selkeää syytä ja yksinkertaista tapaa tehdä se.
• Tarjoa suurten uudelleensuunnittelujen työkalu tai lyhyt siirtymäikkuna sen sijaan, että odotat manuaalista uudelleenkirjoitusta tuote kerrallaan.
• Viestitän muutoksesta ennen sen voimaanastumista, ei vasta sen jälkeen kun myyjät huomaavat, että heidän vanhat SKU:t eivät enää toimi.

4. Erottele SKU-kentät UPC- ja viivakoodikentistä selkeästi.

• Anna myyjille erillinen kenttä UPC- tai valmistuskoodia varten, erillään itse SKU-kentästä.
• Käytä UPC:tä viivakoodin skannaamiseen ja tuotteen tunnistamiseen, ja SKU:ta sisäiseen seurantaan ja raportointiin.
• Vältä kaikkia luetteloita, jotka käsittelevät näitä kahta kenttää vaihdettavina, sillä juuri siitä epäselvyys alkaa.

5. Tarkista päällekkäisyydet ja epäjohdonmukaisuudet säännöllisellä aikataululla.

• Kertaluonteinen puhdistus ei pysy puhtaana, kun uusia toimittajia ja uusia tuotteita lisätään jatkuvasti.
• Aseta toistuva tarkistus, kuukausittain on kohtuullista useimmille markkinapaikoille, jotta päästään kiinni mahdollisiin muutoksiin ennen kuin ne muuttuvat todelliseksi tukitaakaksi.
• Kohdista nouseva määrä SKU:ihin liittyviä tukilippuja varhaisena signaalina siitä, että nykyistä rakennetta on tarpeen tarkastella uudelleen, eikä vain yksittäisten lippujen sulkemiseen.

6. Liitä SKU-laatu toimittajan perehdyttämiskoulutukseen

• Uusien toimittajien tulisi nähdä SKU-muoto vaatimukset koulutusvaiheessa, ei huomata niitä vasta sen jälkeen, kun heidän ensimmäinen ilmoituksensa hylätään.
• Lyhyt, konkreettinen esimerkki on tehokkaampi kuin pelkkä kirjallinen käytäntö.
• Myyntiedustajat, jotka ymmärtävät syyt, nopeammat haut, vähemmän riitoja, selkeämpi raportointi, noudattavat yleensä sääntöjä halukkaammin kuin ne, joita vain käsketään noudattamaan sääntöä.

Mikä ohjaa tätä väärin tekemisen kustannusta?

SKU-kaoksen siivoaminen jälkikäteen maksaa paljon enemmän kuin sen estäminen etukäteen. Markkinapaikka, jolla on tuhansia epäjohdonmukaisia, duplicoituja tai merkityksettömiä SKUja, kohtaa todellisen tietojen siirtoprojektin korjatakseen asiat jälkikäteen, tuottaen tuotteet uudelleen, päivittäen historiallisia tilauksia ja kouluttaen toimittajia, jotka ovat jo muodostaneet tapoja rikkoutuneen järjestelmän ympärille.

Ilman koodia toimiva markkinapaikka-sovellus muuttaa lähtökohtaa merkittävästi, koska rakenteelliset SKU-kentät ja yksilöllisyyden vahvistaminen ovat jo olemassa olevia ominaisuuksia sen sijaan, että ne rakennettaisiin alusta alkaen ongelman näkyessä.Katso, mitä Shipturtlen ominaisuuksiin kuuluu.jatarkista nykyinen hinnoittelutarkkojen lukujen osalta.

Korjaa tämä ennen kuin siitä tulee siirtoprojekti.

Puhdas SKU-rakenne on paljon helpompi toteuttaa alusta alkaen kuin muokata sitä, kun satoja toimittajia ovat jo luoneet omat tapansa. Tämän hankkiminen oikein varhaisessa vaiheessa on poliittinen päätös. Oikeaksi saaminen myöhässä on tietoprojekti.

Varaa esittelynähdä, miten Shipturtle valvoo SKU-rakennetta ja estää kaksoiskappaleet kohteen listauksessa. Taitutustu koko ominaisuusjoukkoonnähdäksesi mitä on rakennettu ennen kuin aloitat.