WMS, TMS en ERP koppelen: één laag voor EDI, API, bestanden en mail

WMS, TMS en ERP koppelen betekent dat orders en vrachtopdrachten vanzelf tussen die systemen overgaan, zonder dat iemand ze overtypt, ook als elke partij in de supply chain zijn eigen formaat gebruikt. Bij een 3PL is een WMS-koppeling zelden één koppeling. De ene opdrachtgever stuurt orders via EDI, de tweede via een API vanuit zijn webshop, de derde mailt elke ochtend een Excel. Koppelen betekent dan dat al die stromen op dezelfde plek landen, in dezelfde vorm, zonder dat de volgende opdrachtgever weer een nieuw project wordt.

Wat is een WMS-koppeling bij een 3PL?

Een koppeling is een afspraak tussen twee systemen: welke velden er overgaan, in welk formaat en hoe vaak, en wat er gebeurt als iets niet klopt. Een magazijn dat voor één bedrijf werkt, heeft er een handvol. Bij een 3PL komt er met elke opdrachtgever een bij, en met elke vervoerder ook.

Daar gaat het meestal mis. Elke nieuwe klant wordt een los stuk werk: iemand schrijft een vertaling van het bestand van die klant naar het WMS en zet die na een paar proeforders aan. Na een paar jaar draaien er zo veel van die vertalingen naast elkaar, elk net anders gebouwd. Vaak weet één persoon hoe ze werken. Valt er een om terwijl die persoon op vakantie is, dan blijven de orders van die opdrachtgever liggen.

Wat is het verschil tussen EDI, API, bestanden en mail?

Alle vier brengen ze dezelfde order of vrachtopdracht binnen. Ze verschillen in hoe strak het formaat vastligt en in wie het initiatief neemt.

EDI

EDI werkt met vaste berichten in een afgesproken standaard. De bekendste is EDIFACT, ontwikkeld voor de Verenigde Naties. In retail en logistiek wordt vaak de EANCOM-variant gebruikt, voor orders, pakbonnen en facturen. Omdat het formaat vastligt, is EDI betrouwbaar. Toch vult elke partner de standaard net iets anders in, dus ook bij EDI heeft elke opdrachtgever zijn eigen afwijkingen.

API

Een API is een ingang in een systeem waar een ander systeem gegevens kan ophalen of neerzetten, op het moment dat het nodig is. Webshops en verzendsoftware zoals Shopify, WooCommerce, Picqer en Sendcloud hebben er een. De gegevens zijn actueel. Je bent wel afhankelijk van wat de leverancier openstelt, en van de toegang die je opdrachtgever je geeft.

Bestanden

Een CSV of Excel die op een vaste plek wordt neergezet, vaak op een SFTP-server, eens per uur of eens per nacht. Simpel en nog altijd heel gewoon. Alleen bewaakt niemand het formaat. Schuift er een kolom op omdat iemand bij de opdrachtgever er een heeft toegevoegd, dan gaat de import mis zonder dat iemand het merkt.

Mail

Een order als tekst in de mail, of als PDF of Excel in de bijlage. Voor een systeem is dit het lastigst, want er is geen formaat, dus typt iemand op kantoor het over. Dit is de stroom waar AI het meeste werk doet. Hoe het lezen van zo’n mail gaat, staat in orders uit mail in je WMS.

Hoe zorgt één laag ervoor dat een nieuwe klant geen bouwklus meer is?

Door alles eerst naar één eigen formaat te vertalen en pas daarna naar het WMS, TMS of ERP te sturen. De laag ertussen kent per bron een vertaling. Deze opdrachtgever stuurt EDI met deze afwijkingen, die zet elke nacht een CSV met deze kolommen klaar. Wat eruit komt, is altijd dezelfde order met dezelfde velden.

Komt er een klant bij, dan bestaat de koppeling naar het WMS al. Je voegt aan de voorkant een vertaling toe en de rest van de keten blijft zoals hij is. Gaat er iets mis met die ene bron, dan raakt dat de andere opdrachtgevers niet.

De controles zitten dan ook op één plek. Een order met een onbekend artikelnummer, een afleveradres zonder postcode of een aantal dat ver buiten het gewone ligt, gaat niet stil het WMS in. Hij komt in een wachtrij, en iemand van je team kijkt ernaar.

Wat doet AI in een WMS-koppeling, en wat niet?

Het grootste deel van een koppeling is gewone code: een EDI-bericht omzetten, een API aanroepen, een bestand inlezen. Dat moet elke keer precies hetzelfde gaan. Daar heb je geen taalmodel voor nodig, en je wilt er ook geen, want een model geeft niet elke keer hetzelfde antwoord.

Een model komt pas in beeld waar geen vast formaat is: bij de mail met een order in de tekst, bij de PDF die elke opdrachtgever anders opmaakt of bij de Excel waar een klant zelf iets aan heeft veranderd. Het model leest dat, haalt de orderregels eruit en geeft per veld aan hoe zeker het is. Wat onder de drempel valt, gaat naar een mens. Bij het aansluiten van een nieuwe bron kan een model voorstellen hoe de kolommen van een onbekend bestand op je eigen formaat passen. Iemand keurt dat voorstel goed voordat het draait.

Het systeem past nooit zelf een order aan en werkt geen afwijking weg zonder dat iemand het ziet. Bij elke wijziging staat waar hij vandaan komt.

Waarom bouw je in de naad en vervang je het WMS niet?

Meestal is het WMS het probleem niet. Het handwerk zit tussen het WMS en de losse opdrachtgever: overtypen, bestanden omzetten, nabellen over een order die niet aankwam. Een nieuw WMS verandert daar niets aan. De opdrachtgevers sturen daarna nog steeds hun eigen bestanden, op hun eigen manier.

Een WMS vervangen betekent een migratie, andere processen op de vloer en een team dat opnieuw moet leren werken. Wij bouwen in het WMS en de administratie die er al staan. Je mensen werken in hetzelfde scherm als gisteren, alleen staan de orders er nu al in.

Wanneer een pakket wel de betere keuze is, staat in maatwerk of standaardsoftware.

Welke toegang heeft een bouwer nodig?

Zo weinig mogelijk, en eerst alleen lezen. Voor de eerste stap is een account met leesrechten op het WMS vaak genoeg, of een export. Daarmee zien we hoe je orders en artikelen eruitzien, zonder dat we iets kunnen veranderen.

Schrijfrechten komen later, en alleen voor wat het systeem moet doen. Zet het orders klaar in het WMS, dan mag het orders aanmaken en verder niets. Per bron is er nog toegang nodig: de map of de dienst waar de EDI-berichten binnenkomen, een API-sleutel per platform en een mailbox waar de ordermails heen gaan. Die toegang geef je zelf, en je kunt hem ook zelf weer intrekken.

Wat is een leeslaag over een oud systeem?

Sommige magazijnen draaien op een systeem zonder API, of op een versie die niemand meer durft aan te raken. Dan bouwen we een leeslaag. Op vaste momenten halen we een kopie van de gegevens op, uit de database of uit een export. Er wordt alleen uit gelezen, nooit in geschreven, dus het oude systeem blijft precies zoals het is.

Op die kopie kun je zonder risico controleren en vergelijken, bijvoorbeeld welk werk wel is uitgevoerd maar nooit gefactureerd. Hoe die controle werkt, staat in werk dat nooit op een factuur kwam.

Welke aanpak past bij welke bron?

Leg je opdrachtgevers en vervoerders een voor een langs deze toets. Stuurt een bron EDI, dan bouw je een vaste vertaling met zijn eigen afwijkingen erin, zonder taalmodel. Heeft hij een API, dan haal je de gegevens op met de toegang die je opdrachtgever je geeft. Zet hij een bestand klaar, dan controleer je bij elke levering ook de vorm, zodat een verschoven kolom opvalt. Mailt hij tekst of een PDF, dan leest een model de order en gaat alles onder de drempel naar een mens.

Begin bij de stroom die nu het meeste handwerk kost. Vaak zijn dat de orders die per mail of als PDF binnenkomen, omdat die met de hand worden overgetypt. Die ene stroom bouwen we eerst. Vooraf leggen we vast wat hij moet doen en meten we hoe het nu gaat. Pas als hij werkt, komt de volgende bron erbij.

Zo groeit de laag mee met je opdrachtgevers en hoeft niet alles vooraf ontworpen te zijn. De stappen staan in onze werkwijze. Waar AI verder in een magazijn past, lees je in AI in het magazijn.

Zet je eigen bronnen zo op een rij, dan kijken we er in een kennismaking samen naar.