Wat een koppeling tussen systemen echt inhoudt

Nederlandse bedrijven zoeken relatief vaak naar “systemen koppelen” of “API integratie kosten” — logisch, want weinig markten hebben zo’n sterke cultuur van systemen die met elkaar moeten praten: een webshop die moet synchroniseren met een boekhoudpakket, een CRM dat orders moet zien zodra ze binnenkomen, een planningstool die voorraad moet lezen uit een ERP. De vraag “wat kost een koppeling” heeft alleen zelden een vast antwoord, om een reden die weinig aanbieders hardop zeggen: de moeilijkheid zit bijna nooit in de koppeling zelf.

De koppeling is het makkelijke deel

De meeste moderne systemen — een webshop, een boekhoudpakket, een CRM — hebben tegenwoordig een redelijk gedocumenteerde API of ondersteunen webhooks. Dat is een solide basis, en het betekent dat we zelden vastlopen op dat deel van een integratie. Waar we wél op vastlopen, en waar het echte werk zit, is het systeem aan de andere kant: een ouder pakket zonder onderhouden API, een intern systeem dat nooit is gebouwd om iets anders te laten meelezen, of twee systemen die hetzelfde begrip — een klant, een order, een voorraadregel — allebei net anders modelleren.

Wat de prijs echt bepaalt

Of het andere systeem een bruikbare API heeft. Dit is de grootste variabele. Een gedocumenteerde, actief onderhouden API met testomgeving maakt een koppeling relatief voorspelbaar. Een API die technisch bestaat maar nauwelijks gedocumenteerd is, of waarvoor je eerst een supportticket moet indienen om toegang te krijgen, kost tijd voordat er ook maar één regel integratiecode geschreven is.

Wat er gebeurt zonder API. Sommige systemen — vooral oudere ERP’s — hebben simpelweg niets bruikbaars. Dan is een geplande bestandsuitwisseling het eerlijke alternatief, of als laatste redmiddel gedocumenteerde automatisering tegen een systeem dat daar nooit voor gebouwd is. Beide werken. Geen van beide is direct klaar, en beide hebben monitoring nodig — een stille storing in een nachtelijke synchronisatie is erger dan geen synchronisatie.

De richting van de synchronisatie. Orders uit een webshop uitlezen naar een ander systeem is eenvoudiger dan voorraad, prijzen en status in twee richtingen synchroon houden. Tweerichtingsverkeer betekent kiezen welk systeem wint als beide kanten hetzelfde record hebben aangepast — een echte ontwerpkeuze, geen vinkje.

Volume en foutafhandeling. Een webshop met een handvol orders per dag kan met een eenvoudige synchronisatietaak toe. Een met duizenden orders heeft retries, wachtrijen en idempotentie nodig, zodat een webhook die twee keer afgaat geen dubbele order creëert.

Situatie	Wat het vraagt
Modern systeem met gedocumenteerde API	Standaard koppeling, gemiddelde inspanning
Verouderd systeem met gedeeltelijke API	Maatwerk tussenlaag, meer foutafhandeling
Systeem zonder bruikbare API	Geplande bestandsuitwisseling of automatisering
Eenrichtingssynchronisatie	Eenvoudigere conflictlogica
Tweerichtingssynchronisatie	Expliciete regels over welke kant wint

Waar het werk echt zit

Een handige manier om ernaar te kijken: de API vertelt je wat er is veranderd, webhooks vertellen je wanneer, en alles daartussenin — een veld uit het ene systeem mappen naar het veld dat het andere systeem verwacht, bepalen wat als duplicaat telt, een product afhandelen dat in het ene systeem al bestaat en in het andere nog niet — is waar de daadwerkelijke ontwikkeltijd naartoe gaat. Dat staat in geen enkele API-documentatie, want het is specifiek voor de twee systemen die gekoppeld worden, niet voor een van beide op zich.

Dit is ook waar de meeste offertes de plank misslaan. Een voorstel dat “API-koppeling” als één regel opvoert, behandelt het goed gedocumenteerde deel van het probleem alsof het het hele probleem is. De mapping en foutafhandeling aan de andere kant is meestal het grootste deel van het echte werk.

Monitoring is geen extraatje

Een koppeling die stilletjes stopt met werken is erger dan een die nooit heeft bestaan, want iedereen blijft vertrouwen op cijfers die niet meer bijwerken. Orders synchroniseren niet meer, en niemand merkt het tot een klant belt over een zending die nooit is aangemaakt. Wij bouwen dit vanaf het begin in: als de laatste succesvolle synchronisatie langer geleden is dan verwacht, wordt iemand gewaarschuwd voordat de klant dat doet.

Dat is precies het soort werk dat bij onze integraties-praktijk hoort: systemen aan elkaar koppelen die daar nooit voor gebouwd zijn, met de foutafhandeling en monitoring die daadwerkelijk nodig zijn — niet alleen de eerste koppeling die werkt op de dag van de demo.

Wat we als eerste vragen

Voordat we iets offreren, vragen we wat het andere systeem is, of het gedocumenteerde API-toegang heeft, hoeveel transacties per dag het betreft, en of de bedrijfslogica een- of tweerichtingsverkeer vraagt. Die vier antwoorden bepalen de vorm van het project meer dan wat dan ook aan de kant van het systeem waar je vandaan koppelt. Voorbeelden van dit soort werk staan op de pagina werk, of lees meer over onze integraties-aanpak.

De koppeling zelf was nooit het risico. Het systeem aan de andere kant is dat wel.

Als de vraag eerder gaat over een CRM dan over een koppeling, leest u CRM kopen of laten bouwen verder. Voor de rest is een kort contact-gesprek over wat er aan de andere kant staat sneller dan verder zoeken naar een vaste prijs.