SKU's: verschil tussen versies

Uit De Vliegende Brigade
Naar navigatie springen Naar zoeken springen
Regel 32: Regel 32:
  
 
=== Niet alleen cijfers ===
 
=== Niet alleen cijfers ===
 +
 +
[[file:20200330-1059.png|thumb|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]]
  
 
* Het is onhandig als een SKU alleen uit cijfers bestaat, want dat kan allerlei fouten geven bij verwerken van data
 
* Het is onhandig als een SKU alleen uit cijfers bestaat, want dat kan allerlei fouten geven bij verwerken van data

Versie van 30 mrt 2020 11:00

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 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
  • 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

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.

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):

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.

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 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 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
  • 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.

Zie ook

Bronnen