Waarom je systemen niet met elkaar praten (en wat dat kost)

Er komt een bestelling binnen in de webshop. Iemand pakt die over en typt hem in het boekhoudpakket. Daarna nog een keer in het voorraadsysteem, want anders klopt de telling niet. Dezelfde gegevens, drie keer ingetikt, door een mens dat zich ook nog eens kan vertypen. Komt dit je bekend voor?

Dit is precies het moment waarop het zin heeft om je systemen te koppelen: je laat twee programma's rechtstreeks met elkaar praten, zodat informatie maar één keer ergens ingevoerd hoeft te worden. Klinkt logisch. Toch werken heel veel bedrijven nog jaren door met overtypen, omdat een koppeling vaag en duur klinkt. Dat valt mee, maar er zitten ook haken en ogen aan. Die wil ik eerlijk met je doornemen.

Wat een koppeling eigenlijk is

Een koppeling loopt bijna altijd via een API. Dat is niets anders dan een afgesproken manier waarop twee systemen berichtjes aan elkaar doorgeven, een soort stekkerdoos waar andere software op kan inprikken. Jouw webshop zegt tegen je boekhouding: er is een nieuwe order, hier zijn de gegevens. De boekhouding zegt terug: ontvangen, ik heb er een conceptfactuur van gemaakt.

Het mooie is dat dat in een fractie van een seconde gebeurt, zonder dat iemand iets hoeft te doen. Geen overtypen. Geen vergeten order. En geen ruzie meer over de vraag welk systeem nu het juiste getal heeft, want er is nog maar één plek waar de gegevens vandaan komen. Dat laatste punt onderschatten mensen vaak. Versnipperde data over losse systemen is een sluipend probleem dat pas opvalt als iemand een simpele vraag stelt en niemand het antwoord met zekerheid kan geven.

Een voorbeeld uit de praktijk

Een tijdje terug bouwde ik voor de Kelderspecialist in Gorredijk een offerteaanvraag op hun website. Vroeger kwam zo'n aanvraag binnen als mailtje, en dan zette iemand de gegevens met de hand in het boekhoudpakket om er een offerte van te maken. Werkbaar, maar elke keer een paar minuten priegelen en af en toe een tikfout.

Nu zet de aanvraag zichzelf meteen als conceptofferte in hun boekhoudpakket Rompslomp. De klant vult het formulier in, en aan de andere kant staat het er al klaar. Iemand controleert het, past eventueel iets aan en verstuurt. Het werk dat overblijft is het werk dat er echt toe doet. De rest deed het systeem. Wil je zien hoe dat eruitziet, lees dan de case over de offertekoppeling met Rompslomp.

Wat dit voorbeeld goed laat zien: een koppeling hoeft niet groot of ingewikkeld te zijn om veel op te leveren. Het ging hier om één duidelijke handeling die elke werkdag terugkwam.

Wanneer het loont en wanneer niet

Een koppeling is geen doel op zich. Het kost geld om te bouwen en het kost daarna geld om te onderhouden, want systemen veranderen en dan moet de koppeling mee. Dat moet je eerlijk afwegen tegen wat het oplevert.

De rekensom is meestal simpel. Hoe vaak gebeurt de handeling, en hoeveel tijd kost hij nu? Iets wat een paar keer per dag voorbijkomt en telkens vijf tot tien minuten kost, telt op tot uren per week. Daar verdien je een koppeling snel mee terug. Maar een handeling die je twee keer per jaar doet? Laat die gewoon met de hand. Een koppeling bouwen voor iets wat zelden gebeurt, is geld weggooien.

Er is nog een reden die los staat van tijd: fouten. Bij overtypen sluipt er vroeg of laat een verkeerd bedrag of een verkeerde voorraadstand in. Soms merk je dat pas weken later, als het al doorwerkt in je cijfers. Een koppeling maakt die fout onmogelijk, en dat is in sommige bedrijven het echte argument, niet de tijdwinst.

Waar het misgaat

Nu het eerlijke deel. Een koppeling is niet iets wat je één keer bouwt en daarna vergeet. De andere kant is software van iemand anders, en die kan veranderen zonder dat ze het jou vragen. Een leverancier brengt een nieuwe versie uit, een veld krijgt een andere naam, en ineens komt er niets meer door. Dan moet er iemand zijn die dat snel oppakt.

Daar gaat het in de praktijk het vaakst mis. De koppeling werkt prima, iedereen is tevreden, en de bouwer is allang weer weg. Een halfjaar later hapert er iets en weet niemand meer waar te beginnen. Daarom hoort onderhoud er gewoon bij. Wij regelen dat via onderhoud en doorontwikkeling, zodat er altijd iemand is die de koppeling kent als er iets verandert.

Let ook op wat er gebeurt als de andere kant er even uit ligt. Servers gaan een keer plat. Een goede koppeling vangt dat op: hij probeert het later nog eens en gooit niet zomaar gegevens weg. Vraag daar expliciet naar als je iemand een koppeling laat bouwen, want het is precies het soort detail dat in een snelle offerte wordt overgeslagen.

Een korte checklist voordat je begint

• Hoe vaak komt de handeling voor en hoeveel tijd kost hij nu? Reken het echt uit.
• Welke twee systemen moeten praten, en hebben ze allebei een API?
• Wat gebeurt er als de koppeling een keer uitvalt? Mag er dan niets verloren gaan?
• Wie houdt de koppeling werkend als een van de systemen verandert?
• Begin klein. Eén handeling die elke dag terugkomt, levert vaak meer op dan een groot plan dat nooit afkomt.

Wat ik je zou adviseren

Kijk eerst eens een week mee met je eigen mensen. Welke gegevens tikken ze ergens over die al in een ander systeem staan? Dat is je lijstje. Pak daar de handeling uit die het vaakst voorkomt en begin daar. Niet alles tegelijk.

Soms kan een koppeling met standaardsoftware en een kant-en-klare integratie. Soms past geen enkel pakket op jouw situatie en is maatwerk software de logische keuze. Dat hangt af van hoe bijzonder jouw proces is. Twijfel je waar jouw geval onder valt, leg het me dan gewoon voor. Vaak is in een halfuur al duidelijk of een koppeling de moeite waard is, en zo niet, dan zeg ik dat ook.