ERP koppelen aan maatwerksoftware: Robaws, Odoo, Exact en meer

Zowat elk ERP met een API kan gekoppeld worden aan software die op de werf wél werkt: Robaws, Odoo, Exact Online, Teamleader, SAP, en daarnaast je boekhouding, je planningstool en je loonsecretariaat. De vraag is niet óf het kan, maar hoe: rechtstreeks via de API, via middleware, met een add-on van je ERP-leverancier, of met een maatwerklaag ernaast. Hieronder de aanpak, wat we bij bouwbedrijven al koppelden, en waar het technisch misgaat.

In het kort

• Rechtstreekse API-koppeling: één datastroom tussen twee systemen. Snel en goedkoop, zolang het bij één blijft.
• Middleware: meerdere systemen via één tussenlaag, met centrale foutafhandeling. Extra abonnement en beheer.
• ERP-add-on: snel als je proces in de module past. De code blijft van de leverancier.
• Maatwerklaag: gebouwd rond jouw werfplanning, werkbonnen en goedkeuringen, met het ERP als bron voor klanten, projecten en facturen.

Waarom wil een bouwbedrijf zijn ERP koppelen?

Omdat het ERP de administratie doet en de werf niet. Robaws, Odoo, Exact Online of Teamleader beheren klanten, projecten en facturen prima. Maar planners verdelen ploegen nog in Excel, ploegbazen sturen werkbonnen en uren via WhatsApp of papier, en de administratie typt alles opnieuw in. Elke overdracht is een kans op een ontbrekend uur, een fout projectnummer of een factuur die blijft liggen.

Een ERP-koppeling laat werfsoftware en ERP samenwerken. De planner haalt het project uit Robaws, de ploeg registreert uren en werkbonnen in een scherm dat op de werf werkt, en goedgekeurde uren gaan terug naar het ERP of rechtstreeks naar Yuki of Billit voor facturatie. Iedereen legt iets één keer vast. Het ERP blijft de bron.

Met welke systemen koppelen we?

Met alles wat een API of een exportformaat heeft. Bij bouw-, transport- en maritieme bedrijven komen dezelfde namen terug:

• ERP en projectbeheer: Robaws, Odoo, Exact Online, Teamleader, SAP, Oracle.
• Boekhouding en facturatie: Yuki, Billit, Octopus, Exact Online, Codabox, Isabel, en e-facturatie via Peppol.
• Loon en personeel: SD Worx, Acerta, Geodynamics voor tijdsregistratie.
• Planning en transport: Dashdoc, Qargo, Timocom, Navitrans, Transics.
• Wat er bij iedereen openstaat: Outlook, Gmail, Google Calendar, WhatsApp en Excel.

Staat jouw pakket er niet bij, dan is de eerste vraag of het een API heeft en hoe die gedocumenteerd is. Dat bepaalt meer dan de naam van het pakket.

Hoe koppel je een ERP aan maatwerksoftware?

Op vier manieren, en het verschil zit in hoeveel systemen moeten meepraten en hoe hard je werfproces afwijkt van wat het ERP verwacht.

Rechtstreekse API-koppeling

De maatwerksoftware leest en schrijft rechtstreeks in het ERP via zijn API. Dit past bij één afgebakende datastroom. Voor Goeyvaerts-R bouwden we in twee weken een certificatentool die rechtstreeks aan Odoo hangt: honderden VCA- en heftruckattesten worden automatisch opgevolgd, zonder aparte integratielaag. Bij één databron, weinig velden en een stabiele API is dit de snelste en goedkoopste optie. Let op API-limieten bij grote volumes, en spreek af wie de koppeling test na een ERP-update.

Middleware of integratieplatform

Een centrale laag waarmee elk systeem praat in plaats van met elkaar. Planning, werkbonnen, uren en boekhouding hangen er alle vier aan. Het grote voordeel is foutafhandeling: mislukte transacties worden bewaard, opnieuw geprobeerd en gemeld, zodat een ERP-storing niet eindigt in ontbrekende uren of dubbele factuurregels. Het nadeel is een extra abonnement, technisch beheer en afhankelijkheid van het platform. Voor één datastroom is dit overkill; bij drie of meer systemen wordt het logisch.

ERP-add-on

Een module van je ERP-leverancier die uren omzet in factuurregels of werkbonnen aan projecten hangt. Als je proces past in wat de module verwacht, start je snel. Bouwspecifieke uitzonderingen leggen de grens snel bloot: onderaannemers, materieel, foto's en handtekeningen op de werkbon, meerwerk. Dan pas jij je werkwijze aan, of je voegt handwerk toe. En de code is van de leverancier. Jij krijgt een gebruiksrecht, geen aanpasbaarheid.

Maatwerklaag naast het ERP

Software gebouwd rond jouw werfproces, die via de API van het ERP gegevens uitwisselt. Dit is wat we het vaakst bouwen voor bouw- en maritieme bedrijven:

• Bij ZET Wonen hangt de nacalculatietool rechtstreeks aan Robaws. Projecten, uren en werkbonnen komen daaruit, de tool schrijft er ook naar terug, en de planning per ploeg en camionette zit in hetzelfde scherm.
• Bij K&C Marine Contractors vullen duikers hun inspectierapport in een app in; de koppeling met Robaws synchroniseert projecten en klanten, zodat er geen dubbele administratie ontstaat.
• Bij Antwerp Underwater Solutions checkt de ploeg materiaal in en uit met één scan, en de koppeling met Yuki zorgt voor automatische herbestellingen.

Een scherm of goedkeuringsstap aanpassen kan zonder de boekhouding te raken. De koppeling zelf vraagt onderhoud bij elke API-wijziging van het ERP, en dat hoort in het contract te staan. Meer over wat we rond Robaws bouwden, inclusief een AI-koppeling waarmee je Robaws in gewone taal bevraagt, lees je in Robaws x Build More.

Welke vorm past bij jouw situatie?

De kwaliteit van de ERP-API weegt uiteindelijk zwaarder dan de gekozen vorm. Robaws en Odoo hebben een goed gedocumenteerde API; bij oudere pakketten is dat vaak de eerste vraag die je stelt.

Waar gaat een ERP-koppeling technisch mis?

Op vijf plekken, en ze zijn allemaal te voorkomen als je ze vooraf benoemt.

• Geen afgesproken hoofdbron. Twee systemen passen hetzelfde record aan en overschrijven elkaar. Leg per gegeven vast wie de bron is: het ERP voor klanten en facturen, het maatwerk voor werkbonnen en planning.
• Veldmapping die niet klopt. Een projectnummer in Robaws moet op het juiste werfdossier landen, en een status als "uitgevoerd" kan in het ERP iets anders betekenen.
• Dubbele records. Een aanvraag slaagt, de bevestiging komt door een time-out niet aan, en de koppeling probeert opnieuw. Een uniek extern ID per record voorkomt dat één werkbon twee factuurregels oplevert.
• Te ruime toegang. Een urenapp leest en schrijft uren en projectcodes, maar hoort geen leveranciers of betaalgegevens te raken. API-sleutels in een kluis, nooit in code of een spreadsheet.
• Stille fouten. Een storing die dagen onzichtbaar blijft. Ongeldige gegevens in een aparte foutenlijst, en een verantwoordelijke die een melding krijgt zodra een drempel overschreden wordt.

En als geen enkel ERP past?

Dan bouw je het centrale proces zelf. Bij De Greef Spoorkranen bekeken we Robaws en Timeking, en niets paste op hoe spoorkranen, laadbakken, machinisten en transporteurs per werf gepland worden. We bouwden een ERP op maat: één platform voor alle resources, nul papieren werkbonnen, en facturatie die rechtstreeks naar Billit gaat. Dat is de uitzondering, niet de regel. Wanneer een pakket wél volstaat, lees je in software op maat voor bouwbedrijven in Antwerpen.

Hoe verloopt zo'n traject, en wat bepaalt de prijs?

Vier fasen. Discovery: hoe lopen planning, werkbonnen, uren en facturatie vandaag, en wie is de hoofdbron per gegeven. Een klikbaar prototype, zodat planners en ploegbazen de schermen zien voor er code geschreven is. Bouw in wekelijkse releases, elk met een werkend stuk koppeling dat je test met echte werven. Acceptatie in een testomgeving, inclusief testmigratie en een gesimuleerde ERP-uitval. Een eerste werkende versie staat doorgaans in een achttal weken; bij Goeyvaerts-R waren het twee, bij De Greef zestien.

De prijs hangt af van vier dingen: het aantal verbindingen en de kwaliteit van de API's, de hoeveelheid bouwspecifieke logica, het datavolume en de synchronisatiefrequentie, en het onderhoud dat je afspreekt. Een vaste prijs zonder afgebakende scope bestaat niet. Wij geven na een eerste gesprek binnen 24 uur een scope en prijsindicatie, met bouw en beheer apart.

Wat check je vóór je een offerte aanvraagt?

• Vraag de API-documentatie van je ERP op, en controleer of je abonnement die API-toegang bevat.
• Inventariseer elke databron en wijs per gegeven één hoofdbron aan.
• Beschrijf de velden die uitgewisseld worden, met een ingevuld voorbeeld voor klant, project, uren en werkbon.
• Leg vast hoe vaak er gesynchroniseerd wordt en wie voorrang krijgt bij een conflict.
• Definieer vijf praktijkscenario's voor de acceptatietest, waaronder een gecorrigeerde werkbon en een dubbele urenregistratie.
• Vraag wie eigenaar wordt van code en documentatie, en laat onderhoud en ondersteuning bij ERP-updates in de offerte zetten.

Twijfel je tussen een add-on van je ERP-leverancier en een maatwerklaag? Neem contact op, dan bekijken we je Robaws-, Odoo- of Exact-omgeving samen. Soms is de conclusie dat de add-on volstaat. Dat hoor je dan ook van ons.