Opzetten van een artikelbestand

Het opzetten van een artikelbestand is belangrijker dan je wellicht in eerste instantie zou denken, het is als een pijler onder een brug. De pijler in de grond krijgen als de brug er nog niet staat is relatief eenvoudig, alleen als de brug er eenmaal staat is het verplaatsen of aanpassen van die pijler bijna onmogelijk geworden. Daarom moet je voordat je aan het inrichten van een ERP begint goed nadenken over hoe ga ik om met het artikelbestand en daarbinnen met artikelcode. Niet heel erg ingewikkeld en het is uiteindelijk maar een keuze. Maar eenmaal een keuze gemaakt is het veranderen daarvan niet zo eenvoudig meer.

Vorige week keek ik naar een mooie applicatie waarmee je op eenvoudige wijze de data die in een ERP-systeem opgeslagen zijn, kan ontsluiten. Simpele zaken zoals productbenaming, e-mailadressen bleken fout, onvolledig of ontbraken. Vandaag de dag met die mooie overkoepelende systemen kan dat niet meer. Klanten verwachten van je dat je dit soort overzichten snel en gemakkelijk kan maken, anders ben je verloren. Artikelbestand is daarin dus belangrijk en de artikelcodering is de sleutel tot het  artikelbestand. Verder zijn er allerlei groeperingen en classificaties die je op orde moet hebben om goede overzichten en dwarsdoorsnedes te kunnen maken. Maar zoals gezegd begint alles met het artikelbestand en de artikelcodering. Voordat we dieper inzoomen op de artikelcodering, eerst een en ander over de opzet van een artikelbestand.

Artikelcode, Globaal bestand dan wel lokaal

Zo’n 10 jaar geleden was ik eens bij een project betrokken waarbij een ‘globaal’ opererend bedrijf met een aantal vestigingen een ERP-implementatie locatie voor locatie had gedaan. Gevolg was dat iedere vestiging zijn eigen artikelnummers en stuklijsten had ook voor de producten die eigenlijk hetzelfde waren. Je zit dan meteen in de problematiek want wanneer is een artikel precies gelijk? Misschien op het eerste gezicht een rare vraag maar ook al zijn de ingrediënten gelijk, het zou kunnen dat de dosering gedurende het productieproces toch net iets anders is omdat de installatie per locatie niet precies gelijk is. Is dan het product gelijk? Niet 100 procent natuurlijk maar naar extern toe wel? Maakt het verschil voor de klant?

De uitdaging

De uitdaging waarvoor ik gesteld werd was dat men aan globale planning en forecast wilde doen over de locaties heen, waarbij je dus de afweging moet maken vanaf welke locatie het product het beste aan de klantlocatie kon worden geleverd. Logistieke afwegingen maar ook capacitaire afwegingen spelen daarbij een rol. Dit is eigenlijk alleen maar zinvol als je hetzelfde product ook op meerdere locaties kunt maken. Maar ook al zijn de artikelbestanden qua opzet vergelijkbaar en de producten uitwisselbaar maar de codes zijn niet gelijk hoe organiseer je dat dan? Gekozen is destijds voor parallelle trajecten. Terwijl we de software in gereedheid brachten moesten anderen werken aan een globaal artikelbestand met gelijke artikelnummers voor dezelfde producten. Het moest mogelijk zijn om decentrale afwijkingen aan te geven. Een geweldige tijdrovende klus die maanden kostten.

Daarom is het denk ik bij implementaties altijd beter om meteen vanaf het begin heel bewust een globaal dan wel lokaal een artikelbestand op te zetten. Ondernemingen groeien, fuseren en dan zie je toch vaak in de loop der tijd de behoefte om producten op meerdere plekken te kunnen maken. De keuze voor een lokaal dan wel globale database is  dan ook een strategische keuze mijns inziens.

De meeste ERP-pakketten kennen een hiërarchie: globaal, facility, warehouse. Een artikel en stuklijst wordt dan in eerste instantie globaal aangelegd en kan dan gekopieerd worden naar de verschillende facilities waar je dan de verbijzonderingen zoals bijvoorbeeld een andere stuklijst of prijs en dergelijke kan aangeven. In die hiërarchie werk je dus altijd top down en op die manier kan je toch lokale verschillen gemakkelijk aanbrengen terwijl het eindartikel gelijk blijft.

Samengevat: de belangrijkste pro’s en con’s met betrekking tot een globaal danwel een locaal artikelbestand.

Een eerste belangrijke keuze die we dus moeten maken is: ‘hanteer je een globaal artikelbestand of een lokaal’. Met lokaal wordt bedoeld dat iedere vestiging zijn eigen artikelbestand heeft, in principe onafhankelijk van elkaar. Natuurlijk kan de opzet dezelfde zijn maar de inhoud van de ene vestiging is onafhankelijk van de inhoud van de andere. Een globaal bestand is een bestand waarbij het artikelbestand ‘centraal’ is, iedereen moet daaruit putten. De voordelen van lokaal bestand is dat iedereen dat voor zichzelf organiseert, er is weinig overleg en afstemming nodig. Het voordeel van een globaal bestand is dat iedereen voor een groot deel de gegevens uit een ruif haalt. Maar in dat geval is behoefte aan overleg en afstemming groter.

Betekenisloze artikelcodering

Als je zoals ik veel in logistieke omgevingen werkt kom je vaak in culturen terecht waar het kennen van de coderingen de mores is. Gesprekken zijn van de aard: ‘ bedoel je nou de 16alpkl?’,  ‘Nee ik heb het over de 16alpgv, want die gv staat voor grootverpakking’. We noemen dat ook wel een betekenisvolle codering. In de codering zijn kenmerken gestopt waaraan men kan zien om welk product het hier gaat. De code is dus eigenlijk genoeg, verdere informatie is eigenlijk niet nodig.

Betekenisvolle coderingen komen vermoed ik uit lang vervlogen tijden dat de computer nog zijn intrede moest doen. Toen zal dat ook zeker wel handig zijn geweest. Ook in de beginjaren van de automatisering waren systemen verre van flexibel en was programmatuur vaak gecodeerd dwz van de aard: ‘ als de tweede positie een a is dan …, maar als de tweede positie een b is dan…..’. En dat liep natuurlijk uit de hand: ‘ als de op de tweede positie een a staat en op de negende een 1 dan ….’ Natuurlijk was niet iedereen op de hoogte van de programmatuur en bedacht dan toch een verkeerde code en dan was het eind helemaal zoek natuurlijk. Maar ook al is de technische oorzaak weggenomen, nog steeds wordt in veel organisatie een betekenisvolle codering gehanteerd. Waarom is dat toch?

Ik denk toch dat dit gebeurt uit een soort gemak en onzekerheid, waarom zou je het niet doen? Het verhoogt toch de leesbaarheid voor de medewerkers? Je kunt toch het een doen en hoeft het ander niet te laten?

Artikelcodering: niet langer dan nodig

Voor de leesbaarheid moet je de omschrijving gebruiken. De codering is de sleutel voor het artikelbestand maar ook niet meer dan dat. Maak het niet langer dan nodig is, want als medewerker  moet je zulke nummers dagelijks meerdere keren invullen. Voor kenmerken, groeperingen en classificaties moet je desbetreffende velden gebruiken die aan de artikelcodering zijn verbonden. Aan die velden zit namelijk programmatuur die het dan weer vergemakkelijkt om dergelijke informatie gemakkelijk te ontsluiten. Ook zijn deze velden gemakkelijk in een database te laden waardoor je allerlei overzichten gemakkelijk naar je hand kan zetten.

Naast dat betekenisvolle coderingen toch beperkt lijken te zijn qua lengte, posities etcetera is de belangrijkste overweging om niet voor betekenisvolle codering te gaan dat de programmatuur niet standaard aanwezig is. Je moet dus maatwerk maken om de informatie te ontsluiten. Dat is in deze tijd gewoon jammer en onnodig. Zoals aangegeven als je de informatie in de velden opslaat die daarvoor zijn bedoeld kan je wel die informatie met standaardprogammatuur ontsluiten.

Het gaan voor een betekenisvolle codering en het voorlopig niet loslaten van een betekenisvolle codering acht ik zeer risicovol en af te raden. Het is onduidelijk, mag ik nu wel of niet een waarde hechten aan een in principe betekenisloze codering.

Het is dus beter in deze tijd voor een relatief korte en betekenisloze codering te kiezen en de betekenissen in aparte velden onder te brengen. Achter elkaar geschakeld is dat natuurlijk ook een bepaalde vorm van een betekenisvolle codering. Het voordeel is echter dat validatie en dergelijke gemakkelijker te regelen is en dat aan de verschillende velden standaardprogrammatuur hangt.

Wijzigingsnummer

Een mooie oplossing heb ik ooit eens gezien bij een bedrijf die een 5-cijferige code had met daaraan een 6 getal voor de wijzigingen. Het 6 cijferige nummer was intern en 5 cijferige extern. Het 5 cijferige nummer was een random getal, dat precies past binnen de EAN-conventie. Dat zal ik straks nog even toelichten, maar nu eerst over dat wijzigingsnummer. De zesde positie werd gebruikt voor wijzigingen die men extern niet wilde doorgeven. In een bedrijf gebeurt het regelmatig dat het product wijzigingen ondergaat die men niet altijd naar de markt wil communiceren. Daarvoor werd dus die zesde positie gebruikt. Het artikelbestand begon dus altijd met een zescijferige code waarvan de eerste vijf posities random waren en de zesde een volgnummer.

Aansluiting met EAN

Een typische externe codering is de EAN code. EAN13 is de meest voorkomende. De logica achter deze codering is dat de eerst 2 getallen het land aangeven en de volgende 5 getallen de vestiging  (aansluitnummer), dan volgen volgen 5 zogenaamde vrije velden en 1 controlegetal. De 5 vrije velden zijn dan handig om als interne code te gebruiken. Immers de andere posities zijn hetzelfde.

Wat je vaak ziet is dat de voor de opbouw van de EAN-code een vrij veld wordt gedefinieerd, als artikelcode wordt dan de 5-cijferige code genomen. Aan de artikelcode zelf hangen allerlei programma’s, aan de EAN-codering an sich niet.

Ik hoor vaak discussies om mij heen dat de barcodering zijn langste tijd heeft gehad. Zou kunnen maar qua opbouw is de EAN niet verkeerd, internationaal goed te gebruiken en geaccepteerd. Wellicht dat de barcodering an sich verdwijnt en een andere techniek wordt maar dat doet niet af aan dat de opzet van de codering an sich prima is.

Omschrijving

De omschrijving wordt doorgaans met de code afgedrukt op de eindverpakking. Zeker als de code een random getal is, wordt de omschrijving des te belangrijker  voor wat betreft de herkenbaarheid. De omschrijving moet duidelijk en onderscheidend zijn. Twee producten die op elkaar lijken moeten in eerste instantie uit elkaar te halen zijn aan de hand van de beschrijving.

Het is belangrijk om met betrekking tot de omschrijving een duidelijke conventie af te spreken en er op toe te zien dat deze ook aangehouden wordt. Probeer afkortingen te vermijden, groepen vooraan te zetten en daarna steeds gedetailleerder te worden. Voorbeeld schroeven: schroeven beginnen altijd met de aanhef schroeven gevolgd door de diameter en de lengte ‘SCHROEF 3,0X30 (200)’.  De letters zijn altijd capitals, inderdaad eerst de diameter in mm  gevolgd door lengte in mm. Tussen haakjes wordt de verpakkingseenheid vermeld. Maar iets heel eenvoudigst om af te spreken is dat je dus ‘schroef’ schrijft en niet ‘schroeven’. Je kunt op die manier goed zoeken, ook de etiketten zien er uniform uit en vergissingen worden daardoor minder gauw gemaakt.

Aanpak voor omschrijving

De meeste systemen onderscheiden een verkorte code die je bijvoorbeeld op de verpakking kan drukken. Daarnaast zijn er langere codes beschikbaar en meestal in verschillende talen. Deze langere codes worden vaker toegepast als de verpakkingsgrootte dat ook toelaat. Probeer ook hier een structuur aan te houden en zo min mogelijk afkortingen te gebruiken. Aanpak voor de omschrijving zou mijns inziens zijn:

• Maak een duidelijke conventie met betrekking tot omschrijvingen. Zorg er goed voor dat deze conventie regelmatig geupdate wordt en actueel blijft
• Begin met de lange codering op te schrijven
• Werk in de omschrijving van grof naar fijn.
• Kijk vervolgens hoe je zo logisch mogelijk de korte code kan samenstellen en houd de conventie daarbij goed in de gaten`
• Maak daarna de vertalingen

Productgroepen

Om diverse redenen wil men kunnen clusteren en groeperen. Productgroepen zijn daarbij ondersteunend. Zoals aangegeven zijn productgroepen in standaardsoftware geen losstaande velden, het zit doorgaans verweven in de software met allerlei specifieke programmatuur. Maak daarom zoveel als mogelijk gebruik van deze Productgroepen.

Samenvatting

Om data te ontsluiten is het hebben van een goed georganiseerd artikelbestand daarbij erg belangrijk. Het begint bij het maken van een duidelijke keuze voor een lokale database, dan wel een globale database met lokale verschillen. De sleutel van het artikelbestand is de artikelcodering. De codering zelf kan het beste een kort en random nummer zijn. Probeer als het enigszins kan de codering op 5 positie te houden zodat je binnen de mogelijkheden van EAN13 blijft. Betekenissen, groeperingen etcetera moet je onderbrengen in aparte velden waar je op kan zoeken en selecteren. Heeft u uw artikelbestand op orde?