Meet- en weegsysteem koppelen aan ERP of WMS: hoe verwerk je de artikeldata?

Een meet- en weegsysteem kan lengte, breedte, hoogte en gewicht automatisch vastleggen, maar daarmee staan die gegevens nog niet automatisch in je ERP of WMS. Na de meting moeten ze ook bij het juiste artikel in het juiste systeem terechtkomen. Als dat proces niet goed is ingericht, moeten medewerkers meetgegevens handmatig overnemen, ontstaat er extra werk en neemt de kans toe dat verkeerde gegevens bij een artikel worden vastgelegd.

Daarvoor zijn in de praktijk drie manieren: via een CSV-bestand, via een QR-code waarmee je de velden in je eigen software invult of via een API die de gegevens direct overdraagt.

Welke route het beste past, hangt niet alleen af van de techniek. Het gaat vooral om hoeveel handmatig werk en controle je in het proces wilt houden. Misschien wil je de metingen eerst controleren voordat je ze uploadt. Misschien wil je medewerkers in hun vertrouwde ERP-omgeving laten werken zonder lengte, breedte, hoogte en gewicht handmatig over te typen. Of misschien wil je juist dat de gegevens na één druk op de knop direct bij het juiste artikel worden verwerkt.

In dit artikel lees je:

• Welke drie manieren er zijn om meet- en weeggegevens te verwerken;
• Hoe CSV, QR-code en API in de praktijk van elkaar verschillen;
• Hoe je zorgt dat een meting bij het juiste artikel terechtkomt;
• Waarom je vooraf bepaalt welk systeem leidend is voor je artikeldata;
• Wanneer controle vóór verwerking juist gewenst is;
• Wanneer een API meer mogelijkheden biedt dan alleen automatisch doorsturen;
• Welke rol operations en IT spelen bij de inrichting.

Meetgegevens verwerken in ERP of WMS: CSV, QR-code of API?

Bij iedere meting legt het meet- en weegsysteem gegevens vast. Bij de ZippCube kan een meting onder andere bestaan uit de barcode, het verpakkingstype, lengte, breedte, hoogte, gewicht en datum en tijdstip. Daarnaast kan er een foto van het gemeten artikel als JPEG worden opgeslagen. Vervolgens moet worden bepaald wat er met die gegevens gebeurt.

Robbert onderscheidt daarvoor in de praktijk drie routes:

1. CSV: Iedere meting wordt als regel opgeslagen in een CSV-bestand. Dat bestand kun je controleren en later uploaden in bijvoorbeeld je ERP.
2. QR-code: Na de meting verschijnt een QR-code met de meetwaarden. Je opent zelf het juiste artikel in je ERP of andere applicatie en scant de QR-code, waarna de waarden in de betreffende velden worden ingevuld.
3. API: Het meetsysteem en het ontvangende systeem wisselen rechtstreeks gegevens uit. Na de meting kunnen de waarden direct worden verwerkt en kan het ontvangende systeem ook informatie teruggeven.

Niet iedere route is dus even automatisch. Bij CSV zit er bewust nog een controlemoment tussen. Bij de QR-code blijft de medewerker in het eigen systeem werken en voert hij één scan uit in plaats van vier waarden over te typen. Met een API kan de gegevensoverdracht verder worden geautomatiseerd.

Welke route past, hangt daarom vooral af van je gewenste proces. Wil je eerst controleren, wil je eenvoudig starten zonder uitgebreide integratie of wil je gegevens direct tussen systemen uitwisselen?

1. Meetgegevens via CSV naar je ERP of WMS: hoe werkt het?

Bij verwerking via CSV wordt iedere meting als een aparte regel opgeslagen. Zo’n regel kan bijvoorbeeld de barcode, het verpakkingstype, lengte, breedte, hoogte, gewicht en het moment van meten bevatten. Daarna bepaalt je organisatie zelf wanneer het bestand wordt verwerkt.

Dat kan interessant zijn wanneer je de gegevens niet direct in je ERP of WMS wilt schrijven. Robbert ziet bijvoorbeeld dat iemand die verantwoordelijk is voor de artikeldata eerst door het bestand gaat, opvallende metingen controleert en het bestand daarna uploadt.

“Sommigen hebben de voorkeur voor CSV omdat ze er nog even overheen willen kijken.”

Die extra stap is niet automatisch een nadeel. Juist wanneer je een grote hoeveelheid bestaande masterdata opschoont, kan het prettig zijn om afwijkingen eerst te beoordelen voordat nieuwe waarden in je systemen terechtkomen. Je bepaalt bovendien zelf of je dagelijks, wekelijks of op een ander moment importeert.

Daar staat tegenover dat CSV geen volledig automatische gegevensstroom oplevert. Iemand moet het bestand uiteindelijk verwerken. Wil je dat de meetgegevens direct na de meting beschikbaar zijn, dan ligt een andere route meer voor de hand.

2. Meetgegevens via QR-code in je ERP of WMS invoeren: hoe werkt het?

Een tweede mogelijkheid is werken met de QR-code die na een meting op het scherm van de ZippCube verschijnt. In die code zitten de gemeten lengte, breedte, hoogte en het gewicht verwerkt. De medewerker opent het artikel in het eigen systeem, gaat naar het eerste relevante veld en scant vervolgens de QR-code.

De QR-code werkt daarbij als het ware als een toetsenbord. De software kan zo worden ingesteld dat na een waarde bijvoorbeeld een tab of enter wordt meegestuurd, zodat achtereenvolgens de juiste velden worden gevuld.

Deze werkwijze heeft een praktisch voordeel: je hoeft geen uitgebreide systeemkoppeling te bouwen om het overtypen van vier afzonderlijke waarden te voorkomen. Volgens Robbert kan de meetoplossing in dat geval bovendien stand-alone worden gebruikt, waardoor minder betrokkenheid van IT nodig kan zijn. Dat kan vooral praktisch zijn wanneer de IT-afdeling weinig capaciteit heeft en daardoor niet direct tijd kan vrijmaken voor de inrichting van een koppeling.

Er blijft wel een belangrijke handmatige stap bestaan. De medewerker moet vóór het scannen het juiste artikel en het juiste invoerveld geopend hebben. Daardoor blijft deze werkwijze afhankelijk van de juiste handelingen van de medewerker.

“De ene zegt: ideaal. En de ander zegt: ik vind het gevaarlijk, want medewerkers moeten dan wel op het juiste vakje klikken.”

Sommige organisaties vangen dat risico op met een eigen, afgebakende applicatie waarin de medewerker nauwelijks verkeerde keuzes kan maken. Of dat nodig is, hangt af van je bestaande software en werkwijze.

3. Meet- en weegsysteem via API koppelen aan ERP of WMS: hoe werkt het?

Met een API kan het meet- en weegsysteem rechtstreeks gegevens uitwisselen met het systeem van de klant. Voor de magazijnmedewerker verandert het meetproces daardoor nauwelijks: hij identificeert het artikel, meet en weegt het en kiest voor export. Het verschil zit vooral in wat daarna gebeurt.

Robbert legt dat als volgt uit:

“Het enige verschil wat na druk op export gebeurt, is dat het direct via de API in het systeem komt.”

Een API kan bovendien meer doen dan alleen vier meetwaarden versturen. Het ontvangende systeem kan bijvoorbeeld op basis van een gescande barcode controleren of het artikel bekend is. Is de barcode onbekend, dan kan dat worden teruggegeven en kun je voorkomen dat meetgegevens aan een niet-bestaand artikel worden gekoppeld.

Dat betekent ook dat artikelidentificatie bij deze route een belangrijke voorwaarde is. Een artikel moet in het ontvangende systeem herkenbaar zijn voordat de meetgegevens betrouwbaar aan het juiste record kunnen worden toegevoegd.

Een API past daardoor vooral bij een proces waarin je meetgegevens direct wilt verwerken en systemen tijdens het proces informatie met elkaar moeten uitwisselen. Daar staat tegenover dat deze route meer technische afstemming vraagt dan bijvoorbeeld werken met een QR-code.

CSV, QR-code of API: welke koppeling met je ERP of WMS past bij jouw proces?

De drie routes lossen hetzelfde basisprobleem op, maar leggen het controlemoment op een andere plek. Bij CSV controleer je de gegevens voordat je ze importeert. Bij QR-code blijft de medewerker zelf betrokken bij het selecteren van het artikel. Bij een API kun je een groter deel van de verwerking en controle tussen systemen laten plaatsvinden.

Er bestaat geen route die voor ieder magazijn automatisch de beste is. Robbert ziet juist dat organisaties andere voorkeuren hebben: de één wil bewust eerst controleren, terwijl de ander de gegevens zo snel mogelijk direct wil verwerken.

Hoe koppel je meetgegevens aan het juiste artikel in je ERP of WMS?

Welke van de drie routes je ook kiest, de meetgegevens moeten altijd ergens aan gekoppeld worden. Meestal gebeurt dat via een barcode. Het meet- en weegsysteem legt de barcode vast samen met de gemeten gegevens, zodat duidelijk is bij welk artikel de waarden horen.

Niet ieder artikel heeft echter een barcode. In dat geval kan bijvoorbeeld een artikelnummer handmatig worden ingevoerd. Het principe blijft hetzelfde: er is altijd een herkenbare identificatie nodig waaraan de meetgegevens kunnen worden gekoppeld.

Bij een API kan nog een extra controle plaatsvinden. Het ontvangende systeem kan teruggeven of de gescande barcode daadwerkelijk bekend is. Is dat niet het geval, dan moet het artikel bijvoorbeeld eerst in het ERP worden aangemaakt voordat de meting verder kan worden verwerkt.

Dat is een belangrijk verschil met alleen gegevens versturen. Je wilt namelijk niet alleen weten dat lengte, breedte, hoogte en gewicht zijn aangekomen, maar vooral dat ze aan het juiste artikel zijn toegevoegd.

ERP, WMS of PIM: welk systeem moet leidend zijn voor je artikeldata?

Voordat je een technische route kiest, moet duidelijk zijn waar lengte, breedte, hoogte en gewicht officieel worden beheerd. Dat kan je ERP zijn, maar ook een Product Information Management-systeem (PIM) of in sommige situaties rechtstreeks een WMS.

Robbert ziet dat het ERP vaak leidend is. De meetgegevens worden daar vastgelegd en vervolgens vanuit het ERP met bijvoorbeeld het WMS gedeeld. Sommige organisaties gebruiken juist een PIM waarin alle productinformatie centraal staat. Rechtstreeks vastleggen in een WMS komt ook voor.

“Het is eigenlijk een organisatorisch vraagstuk voor die klant: welk systeem is leidend voor mijn data?”

Die keuze maak je vóórdat je beslist waar het meet- en weegsysteem zijn gegevens naartoe stuurt. Als je ERP al de centrale bron voor artikeldata is, ligt het bijvoorbeeld voor de hand om eerst te onderzoeken of de meetgegevens daar moeten worden vastgelegd en vervolgens via de bestaande gegevensstroom naar het WMS gaan.

Daarmee voorkom je ook dat meerdere systemen dezelfde artikelgegevens onafhankelijk van elkaar gaan beheren. Het meet- en weegsysteem hoeft niet ieder systeem afzonderlijk van nieuwe waarden te voorzien wanneer er binnen je organisatie al één centrale bron voor die gegevens bestaat.

Wat gebeurt er met bestaande afmetingen en gewichten in je ERP of WMS?

Het komt regelmatig voor dat een artikel al lengte, breedte, hoogte en gewicht in het ERP, WMS of een ander systeem heeft staan. Een nieuwe meting hoeft dan niet automatisch te betekenen dat de bestaande gegevens verkeerd zijn of direct moeten worden overschreven.

In het interview geeft Robbert aan dat dit afhangt van de werkwijze van de klant. Sommige organisaties willen artikelen bijvoorbeeld periodiek opnieuw meten omdat verpakkingen kunnen veranderen. In zo’n proces kan worden afgesproken dat de laatste meting leidend is.

Daarom moet je vóór de inrichting bepalen wat een nieuwe meting betekent. Wil je bestaande waarden vervangen? Wil je eerst controleren? En hoe vaak wil je artikelen opnieuw meten?

Bij CSV heb je van nature een controlemoment voordat je importeert. Bij een API kan de verwerking verder worden geautomatiseerd, maar moet juist vooraf duidelijk zijn welke regels het ontvangende systeem moet volgen.

Welke meetgegevens moet je vastleggen in je ERP of WMS?

Wanneer een artikel toch op het meetstation ligt, ontstaat al snel de neiging om het proces uit te breiden met allerlei extra velden. Volgens Robbert is het verstandig om daar kritisch naar te kijken.

“Alles wat je nu vraagt, dat zit al in je ERP. Weet goed wat je toevoegt.”

Zijn advies is om vooral gegevens vast te leggen die je op dat moment nog niet weet en die voor je proces relevant zijn. Als productinformatie al betrouwbaar in je ERP staat, hoeft die niet nogmaals in de software rondom het meetproces te worden ingevoerd.

Extra velden kunnen wel zinvol zijn wanneer informatie pas bij goederenontvangst zichtbaar wordt of wanneer je een specifieke meetflow wilt afdwingen. In het interview noemt Robbert bijvoorbeeld een klant waarbij meerdere verpakkingsniveaus achter elkaar moesten worden vastgelegd en medewerkers het proces pas konden afronden nadat de benodigde stappen waren doorlopen.

De vraag is dus niet hoeveel informatie je tijdens het meten kúnt registreren, maar welke informatie op dat moment werkelijk ontbreekt en nodig is.

Welke rol heeft IT bij het koppelen van een meet- en weegsysteem aan ERP of WMS?

Hoeveel IT erbij nodig is, verschilt per verwerkingsmethode. Bij een API is technische afstemming nodig tussen de systemen. Bij CSV moet bijvoorbeeld worden bepaald waar bestanden worden opgeslagen en verwerkt. Volgens Robbert wordt het meetstation bij dergelijke toepassingen meestal ook opgenomen in de IT-omgeving van de klant.

Werken met een QR-code kan eenvoudiger zijn. De meetoplossing kan daarbij stand-alone blijven en de gegevens worden vanaf het scherm in de bestaande applicatie ingevoerd. Dat kan interessant zijn wanneer je IT-afdeling weinig capaciteit heeft of wanneer je niet direct een koppeling met de bedrijfsomgeving wilt realiseren.

Bij de voorbereiding zijn daarom meestal meerdere rollen relevant:

• Operations bepaalt hoe het meetproces op de werkvloer moet verlopen;
• De verantwoordelijke voor artikeldata bepaalt waar de gegevens worden beheerd;
• IT of applicatiebeheer beoordeelt wat technisch nodig is;
• De ERP-, WMS- of andere softwareleverancier kan nodig zijn wanneer aan de ontvangende kant iets moet worden ingericht;
• Logitrade stemt af hoe de meetgegevens vanuit de gekozen meetoplossing beschikbaar moeten worden gemaakt.

Zo voorkom je dat je eerst een technische oplossing kiest en daarna ontdekt dat die niet past bij de manier waarop je artikeldata intern wordt beheerd.

Wanneer heb je geen API-koppeling met je ERP of WMS nodig?

Niet iedere organisatie heeft een API-koppeling nodig. Wil je bijvoorbeeld eenmalig je bestaande assortiment meten en daarna de artikeldata weer handmatig beheren, dan kan een CSV-bestand juist praktisch zijn. Je kunt de gegevens verzamelen, controleren en op een gekozen moment verwerken.

Ook een QR-code kan voldoende zijn wanneer je wel van het overtypen af wilt, maar geen uitgebreide koppeling wilt realiseren. De medewerker blijft dan in de bekende software werken en gebruikt de meetoplossing vooral om de waarden snel in te vullen.

Een API wordt interessanter wanneer meten en wegen een structureel onderdeel van je proces is en je de gegevens direct wilt verwerken of automatisch wilt laten controleren tegen informatie uit je eigen systeem. Het volume alleen bepaalt die keuze niet.

Robbert ziet dat verschil ook:

“De een wil gewoon betrouwbare data. Dan maakt het niet uit of de aantallen niet zo hoog zijn. En de ander zegt: de aantallen zijn zo hoog, we kunnen het niet netjes bijhouden.”

Kijk daarom niet alleen naar hoeveel artikelen je meet. Kijk vooral naar hoeveel handmatige verwerking je wilt houden, hoeveel controle je nodig hebt en welke rol de meetgegevens daarna in je processen spelen.

Meet- en weegsysteem koppelen aan ERP of WMS: welke oplossing kies je?

Een meet- en weegsysteem koppelen aan je ERP of WMS kan op drie manieren: via een CSV-bestand, via een QR-code of via een API. Het verschil zit vooral in wat er na de meting gebeurt. Bij CSV verwerk je de gegevens later, bij QR-code vult de medewerker zijn bestaande systeem sneller en via een API kunnen systemen de meetgegevens rechtstreeks uitwisselen.

Welke oplossing past, hangt vervolgens af van een paar fundamentele keuzes. Je moet weten hoe je het artikel identificeert, waar de artikeldata officieel wordt beheerd, of je metingen eerst wilt controleren en wat er met bestaande waarden moet gebeuren. Pas daarna kun je bepalen hoeveel automatisering je nodig hebt.

Een logische volgende stap is daarom om operations, de verantwoordelijke voor artikeldata en IT samen het gewenste proces te laten uitschrijven. Begin bijvoorbeeld bij het scannen van het artikel en eindig bij het systeem waarin lengte, breedte, hoogte en gewicht uiteindelijk moeten staan. Daarmee kun je veel gerichter beoordelen of CSV, QR-code of een API bij jouw situatie past.

Logitrade kijkt bij zo’n vraagstuk daarom niet alleen naar het meet- en weegsysteem zelf. Ook de manier waarop medewerkers ermee werken en de route die de gegevens daarna moeten afleggen, bepalen welke oplossing logisch is.