SKU's

Wat is een goed systeem voor het coderen van SKU's? Ik ben blij dat je het vraagt!

Principes

Houd het kort - Hoge informatiedichtheid

Lange SKU's zijn heel onhandig. Zie casus met EAN-nummers als SKU verderop
Hiermee samenhangend: Verhoog de informatiedichtheid
Voorbeeld van een codering met een hoge informatiedichtheid, zijn Amazon's ASINs.

Duidelijk dat het een SKU is

Handig als je in één keer ziet dat het een SKU is. Daarom zijn alleen maar cijfers wat onhandig. Amazon's ASIN's scoren redelijk

Incorporeer producteigenschappen?

Wel of niet producteigenschappen incorporeren in SKU's?

Ik denk dat het handig kan zijn ivm. handling: Medewerkers kunnen gemakkelijker herkennen om welk product het gaat. Da's handig voor foutdetectie.

Het heeft ook nadelen:

Informatiedichtheid van codes neemt af → Je hebt langere codes nodig
Als producteigenschappen veranderen, kloppen de codes niet meer. Daarom handig om alleen intrinsieke producteigenschappen te incorporeren. In nov. 2019 hoorde ik het voorbeeld van een bedrijf dat de opslaglocatie incorporeerde in SKU's. Da's onhandig, als producten ooit op een nieuwe locatie worden opgeslagen
Het kan ingewikkeld zijn om codes te ontcijferen. Als dat noodzakelijk is tijdens handling, is dat onhandig (voorbeeld: Kleurcoderingen van weerstanden: Ik heb vrijwel altijd een tabel nodig).

Klare taal ipv. codering

Als je producteigenschappen incorporeert in een SKU, kan het handig zijn om dat niet gecodeerd te doen, maar meer in klare taal: Het kan verdraaid lastig zijn om gecodeerde informatie te interpreteren.

Voorbeeld niet-gecodeerde informatie: Gebruik de eerste twee letters van een kleur, ipv. een code.

Niet alleen cijfers

Het is onhandig als een SKU alleen uit cijfers bestaat, want dat kan allerlei fouten geven bij verwerken van data
Het maakt de SKU ook niet herkenbaar als SKU.

Geen cijfers beginnend met een 0

Zie afbeelding hiernaast.

Het klinkt raar (of misschien niet), maar Bol.com kan niet overweg met SKU's die uit cijfers bestaan en die met een '0' beginnen. Hier is bv. de voorloopnul bij '815' weggevallen

Vaste lengte?

Het kan handig zijn als SKU's een vaste lengte hebben ivm. foutdetectie. Voorbeelden:

Amazon's ASIN
EAN-nummer

Systemen met coderingen met een vaste lengte, hebben echter flinke nadelen:

Flexibiliteit: Verlies aan flexibiliteit: Voor Amazon heb je aparte SKU's nodig voor de FBA- en FBM-varianten van een product. Dat los ik nu (lente 2020) op, door achter een SKU een postfix toe te voegen, bv. -02. Dat kan niet binnen coderingssystemen met vaste lengte
Incorporaar productgegevens: Het wordt moeilijker om productgegevens te incorporeren, want ook in de toekomst moet het systeem dezelfde aantal posities gebruiken. Dit kun je goed zien bij EAN-nummers: Ik geloof dat de eerste posities iets zeggen over het land, maar daarna houdt het op. Ik heb de indruk dat ASIN's zelfs helemaal geen producteigenschappen incorporeren in ASIN's. Het zijn vermoedelijk puur nominale codes.

Streepjes of andere leesbaarheidstekens?

Enerzijds maken streepjes (of andere tekens) de code langer. Anderzijds worden ze wel een stuk leesbaarder. Dat beperkt fouten.

Voorbeeld: Wat is gemakkelijker te lezen?

+31650243451

of

+31-6-50.243.451

Altijd inclusief volgnummers

Als je een beetje creatief bezig bent als handelaar, komt er onvermijdelijk een moment, dat producten meerdere SKU's zullen krijgen (héél verwarrend, maar het is niet anders). Voeg daarom altijd een ordinaal getal toe, bv. als suffix
Met een ordinaal getal wordt een volgnummer bedoeld. Als je die op een handige manier toevoegt (bv. productgroep voor productgroep), kun je verbazend veel informatie uit zo'n getal halen.

UTF8 & ASCII

Gebruik bij voorkeur UTF8-tekens. Nog beter: Gebruik alleen ASCII-tekens.

Max. 50 tekens

Ik weet niet meer waar ik dat tegenkwam, maar het is heel redelijk. Al is het maar, omdat titels van producten op webwinkels anders te lang worden.

Geen spaties

Gebruik geen spaties: Da's vragen om verwarring, omdat daardoor de SKU niet een geheel vormt (bv. bij regelafbreking). Daarnaast kan Google Shopping/Google Merchant Center daar niet mee overweg [2]

Geen symbolen

Wees terughoudend met gebruik van symbolen. Underscores zijn altijd goed. Gewone streepjes zijn iets minder goed (omdat tekstverwerkers daar mogelijk n- of m-streepjes van maken). +-tekens zijn waarschijnlijk ook nog ok. Daarna gaat het snel bergafwaarts

Geen onderscheid hoofd- en kleine letters

Maak geen verschil tussen SKU's met of zonder hoofdletters. Maw., MijnSKU en mijnSKU moeten als identiek worden beschouwd.

Voorbereid op postfixes

Amazon vereist verschillende SKU's voor FBA en FBM. Handig om daar rekening mee te houden. Ik doe dat door een postfix toe te voegen. Bv. -02.

Best practices (2020)

De duplicaatcode op nummerplaten, is een voorbeeld van een postfix. De oorspronkelijke nummerplaat heeft duplicaatcode 00. Het eerste duplicaat heeft code 1 (zonder voorloopnul) [1]

Dit is wat ik gebruik:

<prefix>-<stam>-<suffix>-<postfix>

Prefix: Twee- of drieletterige code die fabrikant en productgroep aan geeft
Stam: Producteigenschappen, in bij voorkeur 2 tot 5 tekens
Suffix: Nominaal nummer binnen deze prefix-stam-combinatie. Liefst ook ordinaal: Bv. alfabetisch. Liever niet op omzet, want dat is geen intrinsieke eigenschap
Postfix: Bv. -02 of -03, indien nodig voor bv. Amazon FBA/FBM.

Achtergrond: Nominale, ordinale & kardinale getallen

Hier enige achtergrondinformatie. De boodschap van dit hoofdstuk: Als je met volgnummers gaat werken, laat 't dan ordinale getallen zijn, die zoveel mogelijk informatie bevatten.

Nominale getallen

Nominale getallen zijn getallen die alleen dienen ter identificatie. Net als een naam of een label. Verhoudingen of volgordes zeggen niets.

Voorbeelden:

GUID's - ID's die als toevalsgetallen zijn gegenereerd
Bankrekeningnummers?
Abonneenummers vaste telefoon? Die lijken me volledig willekeurig
SKU's van de Spaanse fabrikant A? Die nummers lijken volstrekt willekeurig.

Ordinale getallen

Ordinale getallen geven rang of volgorde aan. In bredere zin: De getallen zeggen meer dan allleen een unieke identifier. In dit artikel beschouw ik ze als een superset van nominale getallen.

Voorbeelden:

SoFi-nummers: Ik neem aan, dat een jonger iemand een 'hoger' SoFi-nummer heeft dan een ouder iemand?
Nummerborden van auto's: Nummerborden hebben oplopende 'waardes' in de tijd
Type-aanduidingen van auto's: Deze zijn soms ordinaal, bv. als hogere getallen duurdere modellen aangeven (bv. BMW 3-serie vs. 7-serie).
Telefoon-abonneenummers: De eerste cijfers van een abonneenummer, geven de provider aan. Hier zit een nominaal aspect aan: Een nieuwe provider heeft vermoedelijk een hoger cijfer dan een al langer bestaande provider
Postcodes: Ze geven de geografische volgorde aan, waarin de codes in Nederland zijn toegewezen
EAN-codes zijn in beperkte mate ordinaal: Het eerste cijfer zegt iets over het land. Daarnaast worden EAN-nummers in blokken vrijgegeven met min-of-meer samenhangende getallen (maar niet achtereenvolgende oplopende getallen, in mijn ervaring)

Kardinale getallen

Kardinale getallen geven hoeveelheden aan

Kardinale getallen spelen amper een rol bij SKU's
Een voorbeeld zou een SKU zijn, waarin het aantal producten per verpakking, is opgenomen in de SKU.

Casus: EAN-nummer als SKU (2016)

In 2016 ontwierp ik voor een klant een SKU-coderingssysteem, waarbij het EAN-nummer gewoon de SKU was. Dat bleek een slecht idee te zijn:

Lange codes
Moeilijk en foutgevoelig - Geen foutdetectie of -correctie
Lelijk in titels
Werkt alleen voor producten die een EAN-code hebben, en dat bleek lang niet altijd het geval te zijn
Technisch was dit onhandig te realiseren in het datawarehouse: SKU's en EAN-codes moeten tegelijkertijd gealloceerd worden, en dat gaf rare kip- en eiproblemen.

Dit systeem had desalniettemin één voordeel: Je hoefde SKU's niet apart te onthouden.

Casus: Code+deel EAN-code (2018)

In 2018 bedacht ik voor een klant een systeem waarbij de SKU voor een deel bestond uit de EAN-code van dat product. Dit gaf codes zoals ca-14-56347:

c: Productgroep 'c'
a: Leverancier 'a'
1: Product heeft eigenschap 'A'
4: Dit is een bitvector, waarmee drie eigenschappen ('D=4', 'C=2' en 'B=1') gecodeerd kunnen worden. Dit specifieke product heeft blijkbaar alleen eigenschap 'D'
56347: Laatste vijf cijfers EAN-code.

Voordelen

Door het typische format, herken je gelijk dat het een productcode is
Handig dat het begint met een letter: Dan worden SKU's altijd als strings behandeld (itt. codes die alleen uit cijfers bestaan. Nog onhandiger: Als ze ook nog beginnen met een 0)
Productkenmerken geïncorporeerd in de code - Dat kan practisch zijn. Bv. ivm. foutdetectie
Relatief kort.

Nadelen

Ingewikkeld om SKU's te alloceren, omdat tegelijkertijd een EAN-nummer gereserveerd moet worden
Er wordt altijd een EAN-code gealloceerd als er een SKU wordt aangemaakt, terwijl dat lang niet altijd nodig is
Eigenschappen worden gecodeerd opgeslagen. Da's niet optimaal qua begrijpelijkheid: Medewerkers zullen al snel een codetabel nodig hebben om te snappen wat er staat
Relatief lang, althans als het gaat om vermelding in de titel van een product in een webwinkel.

Casus: Amazon: ASIN & ISBN (2019)

Voor boeken hanteert Amazon ISBN-codes. Blijkbaar is dat systeem robuust genoeg om te gebruiken.

Voor producten anders dan boeken, gebruikt Amazon haar eigen Amazon Standard Identification Number-systeem (ASIN). Dit is een code van 10 cijfers en letters (alleen hoofdletters):

Het is een coderingssysteem met een hoge informatiedichtheid. Het is zelfs lastig om die dichtheid verder te vergroten: Kleine letters gebruiken? Speciale tekens gebruiken?
Er zit amper redunantie in. Als je 2 optelt bij een ASIN, krijg je al de volgende geldige ASIN. Bv.:
- https://www.amazon.de/dp/B0722LNW92
- https://www.amazon.de/dp/B0722LNW94
Het lijkt geen producteigenschappen te incorporeren - Puur nominale codes.

Voorbeeld: Fit Small Business (nov. 2019)

Fit Small Business heeft een aardige suggestie qua format:

Begin met een top-level identifier
Gebruik een aantal tekens die het product omschrijven
Eindig met een volgnummer. Dit volgnummer is een aanvulling op (1) en (2). Dat is lastig qua berekening, maar uiteraard wel efficiënt.

De voorbeelden die ze vervolgens geven, vind ik echter minder geslaagd: Alleen numeriek en beginnend met een 0.

Zie ook

ASIN (Amazon)