Systemen koppelen zonder alles opnieuw te bouwen

Je koppelt bestaande systemen door per pakket uit te zoeken wat de API toestaat, één richting te kiezen per gegeven, en een tussenlaag te bouwen die vertaalt tussen de twee. Je hoeft daarvoor niets te vervangen. In verreweg de meeste gevallen is een koppeling goedkoper, sneller en minder risicovol dan een migratie.

In het kort

• Koppelen is in de meeste gevallen goedkoper, sneller en minder risicovol dan een migratie.
• Zoek per pakket uit wat de API toestaat, hoe er wordt ingelogd en wat er gebeurt bij een update.
• Bouw een tussenlaag die vertaalt, buffert en vastlegt wat er is overgedragen.
• Vervangen is pas logisch als er geen koppelmogelijkheid is of als de leverancier ermee stopt.

De vraag komt bijna altijd op hetzelfde moment: er ligt een offerte voor een nieuw systeem dat alles zou moeten kunnen, en het gevoel bekruipt je dat je iets weggooit wat prima werkt. Dat gevoel klopt meestal.

Wanneer koppelen beter is dan vervangen

Drie situaties waarin ik altijd voor koppelen kies.

• Het bestaande pakket doet zijn werk goed. Je boekhoudpakket is geen probleem, je accountant kent het, de btw-aangifte loopt. Dat vervang je niet omdat er een ander proces knelt.

• De kennis zit in de gegevens. Jaren aan klanthistorie, projecten en facturen. Migreren betekent overzetten, controleren en accepteren dat er iets zoekraakt. Dat is duur en het levert niets op.

• Het knelpunt zit tussen systemen, niet erin. Als de klacht is dat iemand gegevens overtypt, is dat per definitie een koppelingsprobleem. Een nieuw systeem lost dat alleen op als het beide functies overneemt, en dan koop je veel meer dan je nodig hebt.

Wanneer vervangen wel logisch is

Eerlijk blijven: soms moet je wel.

Als het pakket geen enkele koppelmogelijkheid heeft en de leverancier er ook niet aan werkt, houdt het op. Dan bouw je een koppeling op exportbestanden, en dat is broos.

Als de leverancier gestopt is of het product uitfaseert, moet je toch bewegen. Dan kun je dat beter gepland doen dan onder druk.

En als je het pakket zo hebt opgerekt met vrije velden en notities dat niemand meer weet wat er waar staat, is opnieuw beginnen soms goedkoper dan repareren.

Wat je per pakket moet uitzoeken

Voordat je iets belooft, drie vragen per systeem.

• Is er een API en wat mag je ermee. De grote Nederlandse boekhoudpakketten hebben er allemaal een, maar wat je ermee mag verschilt sterk. Bij het ene kun je facturen aanmaken, klanten wijzigen en betalingen uitlezen. Bij het andere alleen lezen, of alleen aanmaken. Bij weer een ander zit er een limiet op het aantal aanroepen per uur waar je in de praktijk tegenaan loopt bij een maandelijkse batch.

• Hoe wordt er ingelogd. Een API-sleutel is simpel. OAuth is netter maar vraagt een eenmalige koppelactie en soms een periodieke vernieuwing. Weet vooraf wat er gebeurt als een token verloopt, want dat is de meest voorkomende reden dat koppelingen stilvallen.

• Wat gebeurt er bij een update. Sommige leveranciers versienummeren hun API netjes en houden oude versies jaren in de lucht. Andere doen dat niet. Dat is een reëel risico dat je moet meewegen, ook al kun je het niet beheersen.

De tussenlaag

Wat ik bijna altijd bouw is geen directe verbinding van A naar B, maar een klein tussenstuk dat weet hoe beide kanten praten.

Dat lijkt omslachtig maar het lost drie problemen op.

Je kunt vertalen. Het ene systeem noemt het een relatie, het andere een debiteur, het derde een klant. Ergens moet dat op elkaar worden gelegd, en dat wil je op één plek doen.

Je kunt bufferen. Als het andere systeem even niet bereikbaar is, blijft het bericht staan tot het weer kan in plaats van dat het verdwijnt.

Je kunt zien wat er gebeurd is. Elke overdracht wordt vastgelegd, dus je kunt terugkijken waarom een factuur niet is aangekomen. Zonder dat log ben je bij het eerste probleem aan het gissen.

Het eerlijke verhaal over exports

Als er echt geen API is, blijft er koppelen via bestanden over. Iemand exporteert een bestand, een script leest het in.

Dat werkt, en voor sommige situaties is het prima. Maar wees eerlijk over de nadelen. Het is handmatig, dus iemand moet eraan denken. Het formaat kan veranderen na een update zonder dat iemand het aankondigt. En je kunt niet reageren op gebeurtenissen, alleen periodiek verwerken.

Als een exportkoppeling de enige optie is, bouw hem dan zo dat hij hard klaagt als er iets niet klopt. Een stille mislukking is het gevaarlijkst.

Waar het in de praktijk misgaat

• Er is geen eigenaar. De koppeling werkt, iedereen is blij, en dan verandert er iets. Niemand voelt zich verantwoordelijk en het duurt drie weken voor het opvalt.

• De sleutels kloppen niet. Klant Jansen in het ene systeem en Jansen BV in het andere. Zonder een echte sleutel, zoals een klantnummer of een KvK-nummer, ga je matchen op naam en dat gaat een keer fout.

• Er wordt te veel gesynchroniseerd. De verleiding is groot om alles maar over te zetten. Beperk je tot de gegevens die aan de andere kant echt worden gebruikt. Elk extra veld is onderhoud.

• Twee kanten op. Zoals gezegd: kies één richting per gegeven, tenzij je heel goed weet wat je doet.

Hoe ik dit meestal doe

Eerst een kaart van wat er is en waar het knelt. Dan één stroom kiezen, meestal de vaakst uitgevoerde. Die bouwen inclusief foutafhandeling en een plek waar je ziet dat het goed gaat. Een maand meedraaien naast het handmatige proces, zodat je kunt vergelijken. Pas dan de handmatige stap uitzetten en aan de volgende stroom beginnen.

Dat klinkt behoudend en dat is het ook. De reden is dat een koppeling die stiekem fout gaat je maanden later inhaalt in je cijfers, en dat is het duurste soort fout dat er is.

Wil je weten of jouw pakketten te koppelen zijn? Plan gerust een vrijblijvend gesprek, dan zoek ik dat uit voordat we iets afspreken.