SKU's: verschil tussen versies

Uit De Vliegende Brigade
Ga naar: navigatie, zoeken
(Casus: Amazon: ASIN & ISBN)
(Casus: Amazon: ASIN & ISBN)
(17 tussenliggende versies door dezelfde gebruiker niet weergegeven)
Regel 1: Regel 1:
Wat is een goed systeem voor het coderen van SKU's? Een paar opmerkingen (rond 2018 ik hier een onderzoekje naar gedaan, maar ik kan dat niet meer terugvinden).
+
Wat is een goed systeem voor het coderen van SKU's? Ik ben blij dat je het vraagt!
  
 
== Principes ==
 
== Principes ==
  
=== Houd het kort ===
+
=== Houd het kort - Hoge informatiedichtheid ===
  
 
* Lange SKU's zijn heel onhandig. Zie casus met EAN-nummers als SKU verderop
 
* Lange SKU's zijn heel onhandig. Zie casus met EAN-nummers als SKU verderop
* Hiermee samenhangend: Verhoog de informatiedichtheid. Dat doet Amazon met ASIN: Zowel letters als cijfers.
+
* Hiermee samenhangend: Verhoog de informatiedichtheid
 +
* Voorbeeld van een codering met een hoge informatiedichtheid: Amazon's ASINs: Zowel letters als cijfers. Daar zit geen enkele redundantie in: Eén karakter verkeerd, en je hebt een ander product.
  
 
=== Duidelijk dat het een SKU is ===
 
=== 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. ASIN's scoren redelijk
+
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 omschrijvingen? ===
+
=== Incorporeer producteigenschappen? ===
  
[https://fitsmallbusiness.com/sku-numbers/] heeft een aardige suggestie qua format:
+
Wel of niet producteigenschappen incorporeren in SKU's?
  
# Begin met een top-level identifier
+
Ik denk dat het handig kan zijn ivm. ''handling'': Medewerkers kunnen gemakkelijker herkennen om welk product het gaat. Da's handig voor foutdetectie.
# 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.
+
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).
  
De voorbeelden die ze vervolgens geven op de site, vind ik minder handig: Alleen numeriek en beginnend met een 0.
+
=== Klare taal ipv. codering ===
  
=== Geen 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.
  
* Bit-gecodeerde eigenschappen, zijn moeilijk te ontcijferen. Ook als je bv. cijfers gebruikt voor kleuren of eigenschappen
+
Voorbeeld niet-gecodeerde informatie: Gebruik de eerste twee letters van een kleur, ipv. een code.
* Handiger om dat op een niet-gecodeerde manier te doen. Bv. als het om kleuren gaat, de eerste twee letters van de betreffende kleur te gebruiken.
 
  
 
=== Niet alleen cijfers ===
 
=== Niet alleen cijfers ===
Regel 36: Regel 40:
  
 
Ik denk dat het handig is, als SKU's een vaste lengte hebben, ivm. foutdetectie.
 
Ik denk dat het handig is, als SKU's een vaste lengte hebben, ivm. foutdetectie.
 +
 +
=== Streepjes of andere deeltekens? ===
 +
 +
Enerzijds maken streepjes (of andere tekens) de code langer. Anderzijds worden ze wel een stuk leesbaarder. Daarnaast helpen ze met foutdetectie.
 +
 +
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) ==
 
== Casus: Code+deel EAN-code (2018) ==
Regel 74: Regel 94:
  
 
* Voor boeken hanteert Amazon ISBN-codes. Blijkbaar is dat systeem robuust genoeg om te gebruiken
 
* Voor boeken hanteert Amazon ISBN-codes. Blijkbaar is dat systeem robuust genoeg om te gebruiken
* Amazon's ''Amazon Standard Identification Number'' is een code van 10 cijfers en letters (alleen hoofdletters). Deze wordt gebruikt voor alle overige producten.
+
* Amazon's ''Amazon Standard Identification Number'' is een code van 10 cijfers en letters (alleen hoofdletters). Deze wordt gebruikt voor alle overige producten
 +
* Het is een coderingssysteem met een hoge informatiedichtheid. Het wordt lastig om die dichtheid verder te vergroten: Kleine letters gebruiken? Speciale tekens gebruiken? Er zit geen enkele redundantie in hun codes. Vermoedelijk zijn het ''nominale codes''.
 +
 
 +
== Voorbeeld: Fit Small Business (nov. 2019) ==
 +
 
 +
[https://fitsmallbusiness.com/sku-numbers/ 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.
 +
 
 +
== Ordinale, nominale & 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.
 +
 
 +
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'' orinaal, 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
 +
 
 +
=== Kardinale getallen ===
 +
 
 +
''Kardinale getallen'' geven hoeveelheden aan. Dat speelt amper bij SKU's, maar een voorbeeld zou een SKU kunnen zijn, waarin het aantal individuele producten per verpakking, is opgenomen.
  
 
== Zie ook ==
 
== Zie ook ==

Versie van 1 dec 2019 om 08:28

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: Amazon's ASINs: Zowel letters als cijfers. Daar zit geen enkele redundantie in: Eén karakter verkeerd, en je hebt een ander product.

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 deeltekens?

Enerzijds maken streepjes (of andere tekens) de code langer. Anderzijds worden ze wel een stuk leesbaarder. Daarnaast helpen ze met foutdetectie.

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
  • Amazon's Amazon Standard Identification Number is een code van 10 cijfers en letters (alleen hoofdletters). Deze wordt gebruikt voor alle overige producten
  • Het is een coderingssysteem met een hoge informatiedichtheid. Het wordt lastig om die dichtheid verder te vergroten: Kleine letters gebruiken? Speciale tekens gebruiken? Er zit geen enkele redundantie in hun codes. Vermoedelijk zijn het nominale codes.

Voorbeeld: Fit Small Business (nov. 2019)

Fit Small Business heeft een aardige suggestie qua format:

  1. Begin met een top-level identifier
  2. Gebruik een aantal tekens die het product omschrijven
  3. 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.

Ordinale, nominale & 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.

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 orinaal, 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

Kardinale getallen

Kardinale getallen geven hoeveelheden aan. Dat speelt amper bij SKU's, maar een voorbeeld zou een SKU kunnen zijn, waarin het aantal individuele producten per verpakking, is opgenomen.

Zie ook

Bronnen