Stamdata: waarom het ERP zo goed is als de artikelkaart

Stamdata zijn de vaste gegevens waar elke order naar verwijst: artikelen, klanten, leveranciers, prijzen en locaties. Een ERP rekent alleen zo goed als die gegevens kloppen. Bij een meubelproducent stond 27,9% van de orderregelprijzen in geen enkele prijslijst. Geen pakket repareert dat. Het neemt de fout gewoon over.

Wat is het verschil tussen stamdata en transactiedata?

Een order, een ontvangst en een factuur zijn transacties. Ze gebeuren één keer. Het artikel op die order, de klant en de prijs zijn stamdata. Die worden steeds opnieuw gebruikt.

Dat verschil bepaalt de schade. Een tikfout in een order raakt één order. Een verkeerd gewicht op een artikelkaart raakt elke vrachtbrief met dat artikel, maandenlang, zonder dat iemand het ziet.

Wat is master data management?

Het beheer van die stamdata. Drie vragen vormen de kern:

1. Wie mag een artikel, klant of prijs aanmaken en wijzigen?
2. Welke velden zijn verplicht voordat iets gebruikt mag worden?
3. Welk systeem is leidend als dezelfde gegevens op twee plekken staan?

Bij grote concerns is dat een eigen pakket met een eigen afdeling. Bij een bedrijf van 10-250 medewerkers is het meestal een set afspraken plus controles in het ERP. Dat is genoeg, mits het systeem die afspraken afdwingt en ze niet alleen in een handboek staan.

Waarom bepaalt de artikelkaart wat het ERP kan?

Omdat elke automatische stap op de artikelkaart leunt. Een ordermail wordt pas een conceptorder als het artikel uit de mail in de artikelkaart te vinden is. Bij een B2B-producent komen zo 2 van de 3 van 5.017 gemeten ordermails als conceptorder binnen, zie orderverwerking automatiseren. Een vrachtbrief klopt pas als het gewicht en de verpakking kloppen. Een EDI-bericht naar een grote afnemer wordt geweigerd zonder goederencode per regel.

Bij de meubelproducent rekenden we uit hoeveel orderregels automatisch door konden. Zolang poot en binnenwerk vaak onbepaald bleven, was dat 19,2%. Met die twee keuzes vastgelegd liep het berekende plafond op naar 41,6%. Ruim een verdubbeling, en dat verschil zit volledig in twee velden van de stamdata.

Ook de opbouw van de artikelkaart telt. Het oude systeem kende 12.785 unieke configuraties op 98.655 orderregels. Van die regels droeg 85,8% een keuze voor stof, poot en binnenwerk. Elke configuratie een eigen artikelnummer geven, maakt er tienduizenden artikelen van. Die keuzes horen daarom op de orderregel. Het artikel blijft het model.

Hoe wordt de kwaliteit van stamdata gemeten?

Niet door ernaar te kijken, maar door ze door te rekenen. Vijf controles die op elke artikel- en prijstabel draaien:

• Leeg: verplichte velden zonder waarde, zoals gewicht, eenheid of goederencode.
• Dubbel: hetzelfde artikel onder twee nummers, dezelfde klant onder twee codes.
• Overlap: twee geldige prijzen voor hetzelfde artikel op dezelfde dag.
• Buiten de lijst: prijzen op orders die in geen prijslijst voorkomen.
• Ongebruikt: artikelen die in jaren niet zijn verkocht of ingekocht.

Twee voorbeelden van wat dat oplevert. Bij de meubelproducent vonden we naast de 27,9% prijzen buiten elke lijst ook 188 prijsafspraken met overlappende geldigheid. Bij een importeur van meubels bleven van de 10.127 artikelen in Exact er 6.267 over die er voor inkoop toe deden. De rest was dienstartikel, geen voorraadartikel of nooit verkocht.

Wat zo'n percentage betekent, laat een som zien. Stel dat 27,9% gelijk blijft over een jaar met circa 30.000 orderregels. Dan gaat het om 30.000 x 0,279 = 8.370 regels met een prijs die nergens vastligt. Elk van die regels is een vraag voor iemand van verkoop: was dit een bewuste afspraak, of een uitzondering die nooit terug had moeten komen?

Welke fouten zien we het vaakst?

Prijslijsten als volledige kopie per klant. Elke klant een eigen lijst met alle artikelen, gekopieerd van een andere klant. Een verhoging van de basisprijs moet dan in tientallen lijsten tegelijk. Na een paar jaar weet niemand meer welke afwijking bewust was. Een basisprijs met afwijkingen per klant is beter te beheren.

Handprijzen die nergens bestaan. Een prijs die op de order met de hand is aangepast, staat in geen lijst. Bij een migratie verdwijnt die afspraak, of komt hij mee als ruis.

Twee systemen die allebei eigenaar zijn. Een klantadres dat zowel in het ERP als in de boekhouding gewijzigd mag worden. Na een half jaar zijn het twee adressen.

Alles meenemen. Bij een migratie hoeft niet elk artikel mee. Bij de meubelproducent is de grens: gebruikt in de laatste drie jaar. De rest blijft als historie op te zoeken.

Opschonen als eenmalig project. Een schone tabel zonder eigenaar is binnen een jaar weer vervuild. De regels moeten in het systeem zitten, niet in een opschoonactie.

Wie hoort eigenaar te zijn van de stamdata?

Per soort gegeven precies één eigenaar, en die staat op papier. Bij de meubelproducent is de afspraak scherp. Technische productdata komen uit de fabriek, en Nederland accepteert ze. Inkoopprijzen gaan andersom: Nederland maakt een concept, de fabriek keurt goed. Er is altijd één eigenaar.

Leg ook een tweede persoon vast die mag bevestigen. Anders stopt het aanmaken van artikelen zodra de eigenaar op vakantie is, en dan gaat iemand er toch omheen werken.

Hoe pakken wij stamdata aan?

We meten eerst, met de vijf controles hierboven op de echte tabellen. Elk restant wordt een werklijst met een eigenaar en een besluit per regel. De 188 overlappende prijzen gaan bijvoorbeeld naar een werklijstscherm waar verkoop per sleutel kiest.

Daarna laten we het systeem de regels afdwingen. In het nieuwe ERP van de meubelproducent is dat zo ontworpen: zonder prijslijst geen order, en de eerste order van een klant voor een artikel gaat langs de commercieel verantwoordelijke. Een artikel zonder goederencode is niet bestelbaar voor een EDI-afnemer.

Waar dit in een ERP-overstap past, staat in ERP-implementatie: stappenplan uit de praktijk. Hoe schone stamdata de basis worden voor rapportage, staat op datafundament.

Plan een Data Impact Scan en zie binnen een week hoeveel van de eigen artikel- en prijsdata de vijf controles doorstaat.

Veelgestelde vragen

Wat is stamdata?

Stamdata zijn de vaste gegevens waar elke transactie naar verwijst: artikelen, klanten, leveranciers, prijzen, locaties en stuklijsten. Ze veranderen weinig en worden steeds opnieuw gebruikt. Een order zonder kloppende artikelkaart of prijs gaat later in het proces mis.

Wat is het verschil tussen stamdata en transactiedata?

Transactiedata zijn de gebeurtenissen: een order, een ontvangst, een factuur. Stamdata zijn de gegevens waar die gebeurtenissen naar verwijzen. Een fout in een transactie raakt één order, een fout in de stamdata raakt elke order die dat artikel of die klant gebruikt.

Wat is master data management?

Master data management is het beheer van stamdata: wie mag een artikel aanmaken of wijzigen, welke velden zijn verplicht, en welk systeem is leidend als er meerdere zijn. Voor een bedrijf van 10-250 medewerkers is dat meestal geen apart pakket, maar een set afspraken en controles in het ERP.

Wie is eigenaar van de stamdata?

Per soort gegeven precies één persoon of afdeling. Technische productdata horen bij wie het product maakt, verkoopprijzen bij de commercie, inkoopprijzen bij inkoop of finance. Leg ook een vervanger vast, anders stopt het aanmaken van artikelen bij ziekte of vakantie.