TMS, WMS of ERP: welk systeem heeft je logistieke bedrijf nodig?.

Wat doen TMS, WMS en ERP precies?

Bijna elk logistiek bedrijf dat ik spreek, heeft dezelfde vraag anders geformuleerd: "we zijn de planning kwijt in Excel, welk pakket moeten we hebben?" Het antwoord begint niet bij pakketten maar bij een scherpere vraag: wat is bij jou het proces dat geld verdient of geld kost? Bij de één is dat het plannen van ritten, bij de ander het picken van orders, bij de derde het doorbelasten van uren en kilometers. Die drie vragen leiden naar drie verschillende systemen — en de fout die het vaakst wordt gemaakt, is er één kiezen dat het allemaal zou moeten doen.

TMS — het systeem dat beweging bestuurt

Een Transport Management System gaat over alles wat rijdt, vaart of vliegt. Transportorders aannemen, ritten samenstellen, voertuigen en chauffeurs toewijzen, statussen terugkoppelen aan de opdrachtgever, vrachtbrieven produceren en aan het eind van de rit de basis voor de factuur opleveren. Een TMS denkt in ritten, stops, tijdvensters en beladingsgraad.

WMS — het systeem dat voorraad bestuurt

Een Warehouse Management System gaat over alles wat stilstaat en verplaatst wordt binnen vier muren. Inslag, locatiebeheer, batch- en THT-registratie, orderpicken (per order, per batch of per zone), controle en verzendgereedheid. Een WMS denkt in locaties, aantallen en scanmomenten — en is daarmee sterk afhankelijk van scan- en registratieapplicaties op de vloer.

ERP — het systeem dat de administratie bestuurt

Een ERP is de administratieve ruggengraat: debiteuren en crediteuren, inkoop, verkoop, kostprijzen, projecten en boekhouding. De meeste ERP-pakketten hebben ook logistieke modules, en die zijn precies zo diep als een generiek pakket kan zijn: breed inzetbaar, zelden scherp op jouw proces. Wat een ERP wel en niet is, staat uitgebreider in deze uitleg over ERP-systemen.

Wanneer heb je welk systeem nodig?

Zet de drie naast elkaar en de keuze wordt zakelijker dan de demo's van leveranciers suggereren.

Praktisch komt het meestal op drie situaties neer:

• Je vervoert, maar slaat niet op: een TMS is je primaire systeem, gekoppeld aan je boekhouding. Een WMS voegt niets toe.
• Je slaat op en verzendt via vervoerders: een WMS is je primaire systeem, gekoppeld aan verzendsoftware zoals Sendcloud en je webshop of B2B-portaal.
• Je doet beide (warehousing én eigen wagenpark): je hebt twee systemen én een expliciet ontwerp voor het overdrachtsmoment — het punt waarop een order "verzendgereed" wordt en een rit wordt.

De vraag is nooit welk pakket het meeste kan, maar welk proces bij jou het duurst is als het misloopt.

De koppelingen zijn het echte werk

In vrijwel elk logistiek project dat ik heb gezien, zat het risico niet in het systeem maar in de naden ertussen. Een TMS, een WMS, een boekhoudpakket, een verzendplatform, telematica in de trucks, een klantportaal en straks een eFTI-platform: dat zijn zes tot acht partijen die dezelfde zending anders benoemen. Wat je daar minimaal vastlegt:

• Één leidend zendingsnummer: elk systeem mag zijn eigen ID hebben, maar er is er één die de waarheid bepaalt en die in elke koppeling meereist.
• Statussen als afspraak, niet als tekst: "onderweg", "afgeleverd", "geweigerd" en "deelgelost" moeten in alle systemen dezelfde betekenis en dezelfde tijdstempel hebben. Vrije tekstvelden zijn de bron van de meeste discussies met opdrachtgevers.
• Idempotente verwerking: mobiele netwerken vallen weg, apps versturen dubbel. Een tweede keer dezelfde statusmelding mag geen tweede rit, tweede factuurregel of tweede voorraadmutatie opleveren. Hoe je dat afdwingt, staat in idempotentie bij API-koppelingen.
• Één richting per gegeven: bepaal per veld welk systeem eigenaar is. Voorraadaantallen uit het WMS, tarieven uit het ERP, ritstatus uit het TMS. Twee eigenaren van hetzelfde veld betekent structureel handmatig corrigeren.
• Zichtbare fouten: een koppeling die stil faalt, kost je dagen later een factuurdiscussie. Bouw een plek waar mislukte berichten met reden en herhaalknop zichtbaar zijn.

Wie nog moet bepalen hoe zo'n koppeling technisch werkt — API, webhook of bestandsuitwisseling — vindt de basis in wat is een API-koppeling. In logistiek kom je daarnaast nog vaak EDI-berichten tegen bij grotere verladers; behandel die als een extra kanaal op hetzelfde model, niet als een tweede administratie.

eFTI en de e-CMR: digitalisering wordt de norm

Er is een wettelijke beweging die de komende jaren invloed heeft op je systeemkeuze. De Europese eFTI-verordening (EU) 2020/1056 regelt de elektronische uitwisseling van wettelijk verplichte vrachtinformatie. Vanaf 9 juli 2027 zijn bevoegde overheden verplicht om die gegevens elektronisch te accepteren via gecertificeerde eFTI-platforms, aldus TLN.

Belangrijk detail: die plicht ligt bij de overheid, niet bij de vervoerder. Je mág papier blijven gebruiken. Kies je voor digitaal, dan moet je systeem wél voldoen aan de eFTI-eisen of aansluiten op een gecertificeerd platform. Daarnaast loopt in de Benelux al sinds 1 december 2017 een pilot voor de elektronische vrachtbrief (e-CMR), die inmiddels is verlengd tot en met 8 juli 2027.

Voor je systeemkeuze betekent dat twee dingen. Ten eerste: vraag je leverancier niet of het pakket "eFTI-ready" is, maar hoe de vrachtdocumentgegevens eruit komen — welk formaat, via welke interface, en of jij zelf bij die data kunt. Ten tweede: zorg dat de gegevens die straks een digitaal document vullen (partijen, lading, gewichten, tijdstippen, ondertekening) nu al gestructureerd worden vastgelegd in plaats van in opmerkingenvelden. Dat is het werk dat de overstap later goedkoop maakt.

Standaardpakket, maatwerk of een combinatie?

De discussie wordt vaak als alles-of-niets gevoerd, terwijl het in de praktijk bijna altijd een gelaagde keuze is. Mijn vuistregel: koop wat overal hetzelfde is, bouw wat bij jou anders is.

1. Kopen: boekhouding, salarisadministratie, verzendlabels en carrier-integraties, tachograaf- en telematicadata. Dit is wetgeving en commodity — daar valt niets te onderscheiden.
2. Kopen of bouwen, afhankelijk van je proces: TMS en WMS. Een standaard TMS is uitstekend als je werk lijkt op dat van je concurrenten. Wijkt je lading, je planning of je klantafspraak structureel af, dan ga je in een pakket eindeloos velden misbruiken voor iets waar ze niet voor bedoeld zijn.
3. Bouwen: het klantportaal, de chauffeurs- of buitendienstapp en de planningslogica die jouw voorsprong is. Dit zijn de schermen waar je klant en je medewerker je bedrijf beoordelen.

Voor de bredere afweging — en de kostenkant ervan op langere termijn — is build vs buy de plek om verder te lezen. Loop je nog aan de voorkant van een selectietraject, dan helpt de checklist voor softwareselectie om leveranciers vergelijkbaar te maken.

Valkuilen die ik in logistieke projecten zie

• Het pakket kiezen op de demo: elke demo toont de gelukkige route. Vraag om het scenario dat bij jou wekelijks misgaat: een deellevering, een geweigerde pallet, een spoedrit die tussendoor komt.
• De planner overslaan: planners hebben jaren kennis in hun hoofd die nergens is opgeschreven. Als het systeem hen niet sneller maakt, gaat de planning stilletjes terug naar Excel — en heb je twee waarheden.
• De chauffeursapp als bijzaak behandelen: als de app onbetrouwbaar is bij slecht bereik, komt de data 's avonds handmatig binnen en klopt de facturatie niet.
• Koppelingen achteraan plannen: ze staan bijna altijd op het kritieke pad. Ontwerp ze in week één, niet in de laatste sprint.
• Data uit het oude systeem onderschatten: tarieven, adressen, laad- en losvoorwaarden en klantspecifieke afspraken zijn vaak vervuild. Dat opschonen is projectwerk, geen bijkomstigheid — en uitstellen levert alleen technische schuld op.

Mijn kijk op logistieke software

Wat mij in deze sector opvalt: de operatie is bijna altijd verder dan de software. Planners hebben werkbare workarounds, chauffeurs appen foto's, de administratie heeft een eigen Excel met de echte tarieven. Dat is geen slordigheid, dat is aanpassingsvermogen — maar het betekent ook dat een nieuw systeem niet wordt afgerekend op functionaliteit, maar op de vraag of het net zo snel is als de workaround die het vervangt.

Daarom begin ik in logistieke trajecten liever met één keten helemaal af dan met alle modules half. Neem één type opdracht, van aanname tot factuur, inclusief de chauffeursapp en de boekhoudkoppeling, en laat die volledig werken. Je ontdekt in die eerste keten alle statusdiscussies, alle uitzonderingen en alle datavervuiling — en je hebt iets waar de operatie meteen op kan draaien. Alles daarna is herhaling van een patroon dat al bewezen is.

En wees eerlijk over waar je bijzonder bent. De meeste transport- en logistiekbedrijven zijn dat op één of twee punten: een bepaald type lading, een servicebelofte, een klantrelatie met eigen afspraken. Die punten verdienen maatwerk. Voor de rest is een goed pakket met een schone koppeling sneller en verstandiger dan opnieuw beginnen.

— Jasper

Zo helpt Coding Agency hierbij

Wij bouwen de logistieke laag die tussen jouw pakketten hangt: planning die past bij jouw type werk, een chauffeurs- of warehouse-app die ook offline doorwerkt, een klantportaal met actuele status, en koppelingen naar je boekhouding en verzendpartijen die retry-safe zijn opgezet. Vaak begint dat met één keten volledig werkend maken in plaats van een big bang — zo blijft de operatie draaien terwijl je moderniseert.

Twijfel je of je een TMS moet aanschaffen, je huidige pakket beter moet koppelen of een deel op maat moet laten bouwen? Neem contact op voor een vrijblijvend gesprek — we kijken eerst naar je proces, dan naar software.

Bronnen: EUR-Lex (Verordening (EU) 2020/1056), TLN (eFTI-verordening) en NIWO (e-CMR).