Niet elk overtypwerk verdient een koppeling

De meeste stukken over koppelingen gaan over hoe je het doet. Dit gaat over of je het moet doen. Ik heb vaker gezegd dat iemand er niet aan moest beginnen dan dat ik er een bouwde, en dat scheelde die bedrijven meer geld dan de koppeling ooit had opgeleverd.

Wanneer loont het om twee systemen te koppelen?

Een koppeling loont zodra dezelfde gegevens vaker dan eens per week met de hand van het ene systeem naar het andere gaan, en er iets misgaat als iemand zich vergist. Gebeurt het een keer per kwartaal, dan is een export genoeg. En knoop je drie pakketten aan elkaar die alle drie half passen, dan los je niets op.

De echte maat is niet de tijd die het overtypen kost. Dat is de som die iedereen maakt en hij valt altijd te laag uit. De maat is wat er misgaat: een verkeerd overgenomen bedrag dat pas bij de jaarrekening opvalt, een order die blijft liggen omdat niemand hem heeft doorgezet, dezelfde klant twee keer in het bestand met twee verschillende telefoonnummers. Dat soort fouten verdwijnt niet doordat mensen beter hun best doen. Ze verdwijnen door de mens uit de herhaling te halen.

Andersom geldt het net zo hard. Biedt je pakket al een standaardkoppeling die doet wat je wilt, gebruik die dan. Maatwerk is pas zinvol als de standaard aantoonbaar tekortschiet, en dat moet je kunnen aanwijzen, niet vermoeden.

Wanneer plak je met een koppeling juist een probleem dicht?

Als je eigenlijk drie pakketten hebt die alle drie half doen wat je wilt. Dan koop je met een koppeling rust die niet klopt: het overtypen is weg, maar de scheefheid zit er nog en groeit mee. Twee jaar later heb je vier koppelingen, geen overzicht, en niemand die nog iets durft te veranderen.

Dit is het moment waarop ik meestal afhaak als bouwer. Niet omdat het technisch niet kan, want dat kan bijna altijd, maar omdat je dan software gaat betalen om een keuze te ontlopen. De vraag is dan niet welke koppeling je nodig hebt, maar welk pakket eruit moet. Dat gesprek is korter en het antwoord is goedkoper.

Er is een simpele toets. Kun je in één zin uitleggen welk systeem de baas is over je klantgegevens? Zo niet, dan is koppelen te vroeg. Eerst die vraag beantwoorden, dan pas bouwen, anders bouw je de onduidelijkheid mee in. En dan zit hij er voorgoed in.

Waarom merk je pas weken later dat een koppeling eruit ligt?

Omdat koppelingen niet stukgaan met een knal. Ze vallen stil. Er komt geen foutmelding op iemands scherm, want er kijkt niemand naar dat scherm. Het valt op als er facturen ontbreken, en dan ben je een maand verder en moet je uitzoeken wat er in die maand niet is doorgekomen.

Een koppeling moet zich daarom zelf melden als hij hapert. Dat klinkt vanzelfsprekend en het is het zeldzaamste onderdeel van elke bestaande koppeling die ik tegenkom. Niet stilvallen is belangrijker dan nooit haperen, want dat laatste bestaat niet: leveranciers wijzigen hun loket, servers liggen er even uit, iemand draait een sleutel om.

Wat mij betreft is dat de meetlat. Een koppeling zonder eigen alarm is geen af product. Je hebt dan geen automatisering maar een stille aanname.

Wanneer is een webhook beter dan een koppeling die elk kwartier kijkt?

Zodra iemand op je zit te wachten. Een webhook is een systeem dat zelf van zich laat horen op het moment dat er iets gebeurt: er komt een aanvraag binnen en jouw software weet het binnen seconden. Een gewone koppeling vraagt periodiek of er nog iets is, en loopt dus per definitie achter.

Voor een boekhoudsync maakt dat niets uit. Boekingen van vanmorgen mogen prima vanmiddag doorkomen. Voor een aanvraag van een klant maakt het alles uit, want wie het eerst reageert krijgt de klus. Een kwartier verschil is daar geen technisch detail maar het verschil tussen wel of geen opdracht.

In de praktijk gebruik je vaak allebei: een webhook voor wat haast heeft, en daarnaast een periodieke sync als vangnet voor wat gemist is. Want een webhook die één keer niet aankomt, komt niet vanzelf nog een keer.

Is een pakket zonder API een reden om het pakket te vervangen?

Vaak wel. De omwegen bestaan, en ze werken ook: bestanden automatisch inlezen, of een robot die het scherm bedient alsof hij een medewerker is. Maar ze zijn breekbaar. Eén gewijzigd scherm of bestandsformaat legt ze stil, en de leverancier vraagt jou niets voordat hij iets wijzigt.

Dat zeg ik ook als het betekent dat er voor mij minder te bouwen valt. Reken eerst uit wat de omweg over zijn hele levensduur kost, met onderhoud erbij. Die som valt geregeld uit in het voordeel van een ander pakket. En een pakket zonder loket loopt meestal op meer punten achter dan alleen dat ene.

Eén uitzondering. Draait het pakket op je eigen server, dan valt er soms rechtstreeks uit de database te lezen. Dat vraagt zorgvuldigheid, want je omzeilt de controles van het pakket zelf, maar het is stabieler dan een schermrobot.

Wat leg je vast voordat er één regel code wordt geschreven?

Drie dingen: welk systeem de baas is over welke gegevens, wat er gebeurt als een systeem er even uit ligt, en van wie de koppeling straks is. Dat laatste hoort geen vraag te zijn. De code, de documentatie en de toegangssleutels zijn van jou en draaien op jouw omgeving.

Vertrek ik morgen, dan moet een andere bouwer verder kunnen met wat er ligt. Een koppeling die alleen zijn maker begrijpt is geen bezit maar een gijzeling, en die bouw ik niet. Ik ben ze bij anderen tegengekomen: geen documentatie, de bouwer al jaren weg, en niemand die er nog aan durft te komen.

En leg vast wie er naar omkijkt. Loketten veranderen, pakketten krijgen updates, en een koppeling zonder onderhoud loopt op enig moment vast. Dat mag bij mij liggen of bij je eigen mensen, als het maar ergens belegd is. Onbeheerd is de enige verkeerde keuze.

Hoe ziet dat er in mijn eigen bedrijven uit?

Bij mij draaien de koppelingen die ik anderen aanraad eerst zelf. Aanvragen van meerdere eigen websites komen binnen in één klantkaart, met de herkomst erbij, zodat ik zie via welke site iemand binnenkwam. En de offertes uit ons eigen systeem gaan rechtstreeks de boekhouding in SnelStart in, zonder dat iemand ze overtikt.

Dat is geen etalage maar een filter. Wat bij mij breekt, repareer ik bij mij en niet bij jou. Het is ook de reden dat ik bij een deel van de aanvragen zeg dat er niets gebouwd hoeft te worden: ik ken de rekening van beide kanten. Meer over wie ik ben staat op de over-mij-pagina.

Koppelingen zijn de bodem onder al het andere. Een agent die je offertes opvolgt kan pas iets als hij bij je gegevens kan. Lees anders eerst wat een AI-agent is en wanneer hij werkt, of hoe je AI werkend krijgt in je bedrijf.

Zoek je niet de afweging maar de uitvoering, en wil je weten wat er per pakket bij komt kijken bij Exact Online, SnelStart of AFAS? Dat staat per pakket uitgewerkt bij Cloudzicht, het bedrijf waarmee we dit voor anderen doen.

Mail marc@herdes.nl of bel 036 52 98 447. Ik kijk eerst in de documentatie van beide pakketten, en pas daarna praten we over bouwen.