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 'inherente' 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 is nog onhandiger als zo'n SKU met een nul begint
Is ook niet herkenbaar.

Vaste lengte?

Ik denk dat het handig is, als SKU's een vaste lengte hebben, ivm. foutdetectie.

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

Gebruik ordinale getallen

Als je getallen toevoegt die geen betrekking hebben op producteigenschappen, laat het dan ordinale getallen zijn, met zoveel mogelijk informatie (zie elders in dit artikel).

Casus: Code+deel EAN-code (2018)

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: EAN-nummer als SKU (2016)

Slecht idee om het EAN-nummer als SKU te gebruiken:

Onnodig lang
Moeilijk en foutgevoelig
Lelijk in titels.

Het lijkt één ogenschijnlijk voordeel te hebben: Je hoeft geen SKU meer te verzinnen, want je gebruikt 'gewoon' de EAN-code. Dat voordeel lijkt tegen te vallen, want je krijgt een kip-en-ei-probleem: Je moet tegelijkertijd de EAN-code en de SKU regelen.

Casus: Amazon: ASIN & ISBN

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

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.

Nominale, ordinale & kardinale getallen

Nu wordt 't leuk! 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 dit artikel beschouw ik ze als een uitbreiding op nominale getallen.