Waarom 90% van alle integraties mislukken (en hoe die van jou kan slagen)

“We hebben een leverancier die blijft zeuren over ons changeproces. Elk project is er wel weer een nieuwe database of API die ze nodig hebben… en dan moeten wij weer door de hele changeprocedure heen.” – r/sysadmin
Als je ook maar vijf minuten in de integratiewereld hebt rondgelopen, heb je zo’n klaagzang al gehoord — en waarschijnlijk ook meegemaakt. Integraties mislukken zelden omdat de technologie tekortschiet. Ze mislukken omdat de mensen dat doen.
Wanneer Sales niet weet dat het nieuwe CRM live is. Wanneer Operations vasthoudt aan hun “schaduw-Excel” omdat “de ERP nog niet klaar is.” Wanneer IT nog steeds brandjes blust van de vorige integratie… dan is het project al dood voordat de API’s elkaar überhaupt begroeten.
En toch blijven we doen alsof het een technisch probleem is.
De echte reden: integraties sterven in de gaten ertussen
Integraties falen in de leegtes — tussen teams, tussen verwachtingen, tussen hoe mensen denken dat ze werken en hoe ze het werkelijk doen.
Het eerste projectoverleg begint altijd hoopvol. Iedereen knikt enthousiast terwijl de flowcharts op het scherm verschijnen. Blokjes en pijlen stromen keurig van links naar rechts. Iemand zegt: “Ziet er vrij simpel uit,” en iedereen besluit om dat even te geloven.
Twee weken later ontdekt Finance dat het dataformaat niet overeenkomt met hun rapportagetool. Marketing blijkt geen toegang te hebben tot de testomgeving. Het magazijn komt erachter dat “realtime updates” eigenlijk betekenen “wanneer de nachtelijke batch klaar is.”
Het is geen sabotage — het is entropie. In grote organisaties is iedereen zo druk met zijn eigen stukje optimaliseren dat niemand de opstopping opmerkt die ondertussen ontstaat.
De sleutel: het gaat niet om code, maar om coördinatie
De bedrijven die de integratiekerkhof overleven — waaronder meerdere leden van Kaunas High Tech Cluster — zien integratie niet als een technisch probleem, maar als een coördinatieprobleem.
Ze bouwen niet alleen API’s; ze bouwen begrip.
Voordat er ook maar één regel code wordt geschreven, organiseren ze “war rooms”. Niet voor de show, maar voor afstemming. Ze zetten Sales, Operations, IT, Finance en zelfs de stagiair die de dashboards bijwerkt in één kamer en stellen één simpele vraag:
“Wat verandert er voor jou?”
Ze voeren pilots uit per afdeling. Ze schrijven “human release notes” — korte, begrijpelijke updates die in gewone taal uitleggen wat er verandert.
(“Je hoeft tabblad 3 van Excel niet meer te gebruiken. Het nieuwe veld ‘Product_ID’ vervangt ‘SKU’ in rapporten. En nee, je hoeft historische data niet aan te passen — dat is geregeld.”)
Het is niet sexy. Het is geen AI. Maar het werkt. En het redt projecten die anders zouden sterven aan miscommunicatie.
Een praktijkvoorbeeld
Een van onze clusterleden werkte met een middelgrote productieklant aan de integratie van ERP-, logistieke en CRM-systemen — de heilige drie-eenheid van enterprise-chaos.
Voordat ze begonnen met bouwen, eisten ze dat iedereen die geraakt werd een sessie van één uur zou volgen waarin werd uitgelegd wat er zou veranderen en waarom. De klant zuchtte. De projectstart liep twee weken vertraging op.
Maar toen het systeem live ging, gebeurde er iets ongewoons: niets ging kapot.
Sales hield op met elke tien minuten IT te bellen. Het magazijn raakte niet in paniek. Iedereen wist precies wat er zou gebeuren.
Die twee weken vertraging bespaarden drie maanden nablussen.
Zo zorg je dat jouw integratie wél slaagt
Begin niet met bouwen voordat iedereen die geraakt wordt de “na”-situatie kan beschrijven.
Als de eindgebruikers niet kunnen uitleggen wat succes betekent, maakt perfecte code geen verschil.
Breng afhankelijkheden in kaart vóór je gaat coderen.
En ga er gerust van uit dat je er een paar vergeet — want dat doe je. Er zijn altijd verborgen koppelingen of verouderde scripts die niemand kende.
Wijs één integratieverantwoordelijke aan die géén ontwikkelaar is.
Kies iemand die processen begrijpt, niet alleen code. Die ziet de menselijke valkuilen voordat ze productie halen.
Communiceer in mensentaal.
Een Slack-thread van 200 berichten is geen documentatie. Mensen moeten begrijpen en voelen wat er voor hen verandert.
Integraties mislukken zelden in de cloud. Ze mislukken in de vergaderkamer.
De volgende keer dat iemand de API de schuld geeft, kijk dan eens rond in de ruimte. De echte bug zit waarschijnlijk op een bureaustoel, niet op een server.
Laat de “plug-and-play”-illusie los. Vertrouw niet op de gelikte PowerPoint die “naadloze integratie” belooft.
Stop met vertrouwen op grote namen. Begin met het oplossen van echte problemen.