Waarom een puur technische partij je vaak de verkeerde oplossing verkoopt

Door Clen Mourik

Een kwart van alle ICT-projecten mislukt volledig. Niet door slechte techniek, maar door verkeerde aannames. Technische partijen bouwen wat je vraagt — niet wat je bedrijf nodig heeft. Het verschil zit in proceskennis.

Hoeveel tijd ben je deze maand kwijt geweest aan het rechttrekken van fouten in je administratie? Facturen die niet kloppen. Orders die verkeerd zijn doorgezet. Voorraadstanden die nergens op slaan.

Je had een systeemkoppeling laten bouwen. Technisch werkt het. De API's praten met elkaar. De data stroomt. Maar het eindresultaat? Meer chaos dan vóór de integratie.

Het probleem is niet de technologie. Het probleem is dat je een technische oplossing hebt gekocht voor een procesprobleem.

Inhoudsopgave

• Belangrijkste punten
• Het verschil tussen techniek en proces
• Waarom integraties mislukken
• Echte voorbeelden uit de praktijk
• Wat proceskennis je oplevert
• Hoe herken je een goede integratiePartner
• De kosten van fout integreren
• Stappenplan: kies de juiste aanpak
• Veelgestelde vragen

Belangrijkste punten

Het verschil tussen techniek en proces

Een technische systeemintegrator kan een perfecte koppeling bouwen tussen AFAS en Exact Online. De data stroomt feilloos van het ene systeem naar het andere. Maar als niemand heeft uitgezocht welke data waar naartoe moet, wat de bron van waarheid is, en hoe jullie bedrijf eigenlijk werkt — dan heb je een technisch perfect systeem dat zakelijk nutteloos is.

Laat ik concreet zijn. Een groothandel met 30 medewerkers laat een koppeling bouwen tussen hun WooCommerce-webshop en Exact Online. De technische partij vraagt: "Welke API-endpoints hebben jullie nodig?" Ze bouwen de koppeling. Orders stromen door. Technisch werkt het.

Maar wat ze niet hebben gevraagd: hoe gaan jullie om met nabestellingen? Met deelleveringen? Met backorders? Wanneer maak je een factuur aan — bij bestelling of bij verzending? Hoe werkt de BTW-verlegging voor B2B-klanten? Wat is de bron van waarheid voor voorraadstanden?

De technologie werkt technisch vrijwel altijd. Het probleem zit in de aannames, de processen en het gedrag eromheen.

Het gevolg: facturen worden te vroeg aangemaakt, de BTW klopt niet voor zakelijke klanten, de voorraad raakt uit sync met de werkelijkheid in het magazijn. De medewerkers moeten alles handmatig corrigeren. Netto meer werk dan vóór de integratie.

Wat een procesgeoriënteerde aanpak wel doet

Een procesgeoriënteerde integratiePartner begint niet met "welke systemen", maar met "hoe werkt je bedrijf". Ze stellen vragen die technisch irrelevant lijken maar zakelijk cruciaal zijn:

• Wat gebeurt er als een klant een dag later belt om de bestelling aan te passen?
• Hoe weet de magazijnmedewerker of iets voorrang heeft?
• Wanneer gaat een order van "besteld" naar "geleverd" in jullie proces?
• Wie is verantwoordelijk als de data niet klopt?
• Wat zijn de uitzonderingen op de regel?

Die vragen leiden tot een specificatie die technische én zakelijke logica bevat. Business rules. Beslisbomen. Foutafhandeling. Validaties. Dat is wat een integratie bruikbaar maakt.

Waarom integraties mislukken

Een kwart van alle ICT-projecten loopt uit op een totale mislukking, waarbij het nieuwe systeem nooit in gebruik wordt genomen. Bij grote projecten ligt dat percentage nog hoger: 36% mislukt dusdanig dat het systeem niet gebruikt wordt, en 57% verloopt niet volgens plan (Dutch IT Channel).

Dat zijn geen kleine projecten bij incompetente partijen. Dit zijn professioneel gebouwde systemen door technisch capabele mensen. Waarom gaat het dan mis?

Fout 1: Tool-first denken

De meeste gesprekken met technische partijen beginnen met: "Welke systemen wil je koppelen?" Niet: "Waar loop je tegenaan?" of "Wat kost je handmatige werk het meest?"

Het gevolg is dat je een oplossing koopt voor een probleem dat je niet hebt omschreven. Een aannemer belt over een koppeling tussen urenregistratie en AFAS. De technische partij bouwt de koppeling. Maar niemand heeft gevraagd: hoe registreren jullie uren nu? Per project? Per kostensoort? Per fase? Hoe werken zzp'ers? Wat is verrekenbaar meerwerk?

Zonder die context krijg je een koppeling die uren doorstuurt, maar niet bruikbaar is voor projectanalyse of facturatie.

Fout 2: Oude processen digitaliseren

50 tot 75% van de projecten waarbij oude processen in nieuwe software ingebouwd worden, mislukt (Logic4).

Waarom? Omdat de huidige processen trucjes zijn om om de beperkingen van de huidige software heen te werken. Een medewerker typt bijvoorbeeld eerst alles in Excel, omdat het boekhoudpakket geen bulk-import kan. Of er worden notities in het "memo"-veld gezet omdat er geen veld is voor leveringsinstructies.

Als je die trucjes automatiseert, bouw je de workarounds in beton. Beter: de processen opnieuw bekijken en ze ontwerpen voor de nieuwe situatie.

Fout 3: Geen eigenaarschap na oplevering

Een technische partij bouwt, levert op, factureert en verdwijnt. Drie maanden later verandert er iets in jullie proces. Of de leverancier van je boekhoudpakket update de API. Of een nieuwe medewerker begrijpt niet waarom het systeem zich zo gedraagt.

Zonder iemand intern die begrijpt wat de koppeling doet en waarom, ben je volledig afhankelijk van de externe partij voor elke aanpassing. Dat wordt duur en traag.

Fout 4: Te groot, te snel, te ambitieus

Een bedrijf wil tien processen tegelijk automatiseren. Volledig geïntegreerd. Real-time. Met dashboards. En AI natuurlijk. Het projectteam is groot, de tijdlijn is lang, het budget is fors.

Zes maanden later is er nog niets live. Het budget is op. De interesse is verslapt. Het project wordt stil afgeblazen.

Grote projecten falen vaker dan kleine — niet omdat de ambities te hoog zijn, maar omdat de complexiteit te groot wordt om te managen. Elke extra integratie voegt risico toe.

Echte voorbeelden uit de praktijk

Laat me je drie voorbeelden geven die ik regelmatig tegenkom. Geen verzonnen verhalen, maar herkenbare situaties uit het Nederlandse MKB.

Voorbeeld 1: Bouwbedrijf met urenregistratie

Een regionaal bouwbedrijf met 18 medewerkers werkt met branchespecifieke software voor projectadministratie en wil dit koppelen aan AFAS voor salarisverwerking. De technische partij koppelt de systemen op basis van medewerker-ID en aantal uren.

Wat ze over het hoofd zien: het bouwbedrijf werkt met projectgebonden uurcodes (projectnummer, kostensoort, fase). Er zijn verrekenbare meerwerk-regels. En zzp-inleners worden anders gefactureerd dan eigen personeel.

De koppeling dumpt alle uren als "gewerkte uren" in AFAS, zonder projecttoewijzing. Gevolg: de verlies-en-winstanalyse per project is onbruikbaar. De controller moet dagelijks handmatig de data reconciliëren. Drie maanden later wordt de koppeling stilgelegd.

Voorbeeld 2: Zorginstelling met declaraties

Een thuiszorgorganisatie met 60 medewerkers koppelt hun zorgplanningspakket aan het declaratiesysteem. De technische partij bouwt een koppeling die zorgminuten doorstuurt.

Maar in de zorg gelden specifieke declaratieregels per zorgprestatiecode (WLZ, WMO, Jeugdwet). Een minuut "persoonlijke verzorging" bij een WLZ-klant mag niet worden samengevoegd met een minuut bij een WMO-klant. Er zijn maximale tijdvensters per declaratieregel. Indicatiedatums moeten worden gecontroleerd vóór verzending.

De koppeling stuurt ruwe minuten door zonder validatie. Gevolg: massale afwijzingen bij het zorgkantoor, terugvorderingen, én een boete wegens onjuiste declaraties.

In gereguleerde sectoren als de zorg is domeinkennis minstens zo belangrijk als technische kennis. Een puur technische partij zonder zorgkennis is hier actief schadelijk.

Voorbeeld 3: Webshop met prioriteitslevering

Een webshop met 300 orders per dag koppelt Shopify aan het WMS van hun fulfilmentpartner. De API werkt. Orders stromen door.

Maar de webshop heeft een loyaltyprogramma met prioriteitslevering voor vaste klanten. Bepaalde producten mogen niet samen worden verzonden (gevaarlijke stoffen). En retouren moeten automatisch creditnota's aanmaken in Exact Online.

Geen van deze business rules is meegenomen. Het WMS behandelt alle orders gelijk. Gevaarlijke combinaties worden wél samen verzonden. Retouren stranden in een handmatig proces. Na drie maanden draait de eigenaar zelf dagelijks een Excel-overzicht om de gaten te dichten.

Wat proceskennis je oplevert

Meer dan 80% van MKB-ondernemers geeft aan dat zij of hun medewerkers onvoldoende kennis hebben om effectief te investeren in nieuwe technologieën (Vodafone Business). Dat is niet gek — je bent ondernemer, geen IT-specialist.

Daarom is het cruciaal dat je partner wél die proceskennis heeft. Niet alleen technisch, maar met een blik van ondernemer, productowner én developer. Wat levert dat op?

1. Minder handmatig werk

Een medewerker die dagelijks 50 orders handmatig overneemt van een webshop naar een boekhoudpakket, besteedt bij gemiddeld 5 minuten per order ruim 4 uur per dag aan louter datatransfer. Op jaarbasis is dat meer dan 1.000 uur verloren arbeidstijd — bij een uurtarief van €35 goed voor circa €31.000 aan verspilde loonkosten per jaar.

Een goede koppeling neemt dat volledig weg. Maar alleen als de business rules kloppen: wanneer wordt een order een factuur? Hoe gaan jullie om met creditnota's? Wat gebeurt er bij een retour?

2. Minder fouten

Handmatig werk betekent fouten. Orders die verkeerd worden overgenomen. Voorraadstanden die niet kloppen. Facturen met de verkeerde BTW. Bij een klant zagen we de orderfoutenratio zakken van 8% naar minder dan 1% na een goed gebouwde koppeling tussen Shopify en Picqer.

Maar dat werkt alleen als de validaties goed zitten. Als de koppeling wél data doorstuurt, maar niet controleert of het klopt, heb je straks geautomatiseerde fouten — die zijn nog erger.

3. Grip op je bedrijf

Als je data verspreid zit over drie systemen die niet met elkaar praten, heb je geen enkel overzicht. Hoeveel voorraad heb je? Welke projecten zijn winstgevend? Welke klanten betalen te laat?

Goede integraties zorgen dat je één bron van waarheid hebt. Eén plek waar de data klopt. Dat geeft rust en grip.

Hoe herken je een goede integratiePartner

Niet elke partij die zegt "wij bouwen koppelingen" is geschikt voor jouw bedrijf. Hier zijn concrete signalen waar je op kunt letten:

Vragen die je moet stellen

• Hebben jullie ervaring in mijn branche? (niet alleen technisch, maar inhoudelijk)
• Hoe gaan jullie te werk bij het in kaart brengen van processen?
• Wat gebeurt er als mijn proces over een half jaar verandert?
• Wie is eigenaar van de koppeling na oplevering?
• Kunnen jullie uitleggen wat er misgaat als de koppeling faalt?

Een goede partner kan niet alleen technisch bouwen, maar ook uitleggen waarom bepaalde keuzes zakelijk slim of dom zijn. Ze denken mee vanuit de driehoek: ondernemer, productowner, developer. Dat is precies de aanpak die wij hanteren bij SyncIT.

De kosten van fout integreren

Een mislukte integratie kost je meer dan alleen het geld dat je aan de technische partij betaalt. Laat me de echte kosten even uitsplitsen.

Directe kosten

• Betaalde uren voor de koppeling: gemiddeld €5.000 tot €25.000 voor een middelgrote integratie
• Verloren tijd van je team: meetings, testen, data aanleveren — minimaal 40 uur intern
• Correctiewerk na oplevering: handmatig data rechttrekken, fouten herstellen

Indirecte kosten (vaak veel hoger)

• Klantontevredenheid: verkeerde leveringen, foute facturen, trage afhandeling
• Gemiste kansen: terwijl je bezig bent met repareren had je kunnen groeien
• Medewerkersfrustratie: "we hebben dit laten bouwen en nu is het nóg erger"
• Reputatieschade bij leveranciers: verkeerde bestellingen, te late betalingen

Naar schatting kost een mislukt ICT-project Nederland jaarlijks vier tot vijf miljard euro (Boom Management). Dat zijn niet alleen grote overheidssystemen — ook MKB-bedrijven betalen de prijs.

Stappenplan: kies de juiste aanpak

Hoe pak je het dan wél goed aan? Hier is een stappenplan dat werkt, gebaseerd op tientallen projecten die we hebben gedaan.

Stap 1: Begin met het probleem, niet de oplossing

Beschrijf het probleem zo concreet mogelijk. Niet "we willen een koppeling tussen systeem A en B", maar "onze medewerkers besteden dagelijks 3 uur aan handmatig orders overtypen, en daarbij gaan 5% van de orders fout".

Stap 2: Breng je huidige proces in kaart

Ga letterlijk bij je mensen zitten en kijk hoe ze werken. Waar zitten de handmatige stappen? Welke trucjes gebruiken ze? Wat zijn de uitzonderingen op de regel? Schrijf het op. Simpele opsommingen zijn genoeg.

Stap 3: Bepaal de gewenste situatie

Hoe zou het ideaal werken? Niet technisch, maar zakelijk. "Een order komt binnen, het systeem controleert de voorraad, stuurt automatisch een picklijst naar het magazijn, en maakt een factuur aan bij verzending." Dat is een procesbeschrijving.

Stap 4: Start klein

Kies één proces. Eén koppeling. Eén duidelijk gedefinieerd probleem. Maak dat perfect. Daarna kun je uitbreiden. Een werkende koppeling die 80% van het handmatige werk wegneemt is beter dan een halve koppeling die tien processen zou moeten automatiseren.

Stap 5: Zorg voor intern eigenaarschap

Wijs iemand aan die verantwoordelijk is voor de koppeling. Niet technisch bouwen, maar begrijpen wat het doet, waarom het zo werkt, en wanneer het aangepast moet worden. Die persoon is de brug tussen jullie bedrijf en de technische partij.

Wil je weten welke integratiecombinaties het populairst zijn in jouw branche? Bekijk ons overzicht van meer dan 3300 veelgebruikte koppelingen.

Veelgestelde vragen

Wat is het verschil tussen een technische systeemintegrator en een procesgeoriënteerde partner?

Een technische systeemintegrator bouwt de datastroom tussen twee systemen op basis van jouw specificatie. Een procesgeoriënteerde partner helpt je eerst de specificatie te maken door je bedrijfsprocessen te begrijpen, zodat de koppeling zakelijk nuttig is en niet alleen technisch correct.

Waarom mislukken zoveel integratieprojecten in het MKB?

De meeste integratieprojecten mislukken niet door slechte techniek, maar door verkeerde aannames. Het voortraject wordt overgeslagen: niemand toetst of de aannames kloppen, het team wordt niet betrokken, en de processen zijn niet helder. Het gevolg is een technisch werkende koppeling die het verkeerde probleem oplost.

Hoe kies je de juiste integratiePartner voor je MKB-bedrijf?

Let op deze signalen: vraagt de partner naar je problemen of alleen naar je systemen? Leveren ze een procesbeschrijving of alleen een technische spec? Hebben ze ervaring in jouw branche? Blijven ze betrokken na oplevering? Een goede partner denkt mee vanuit ondernemer, productowner én developer.

Wat zijn de echte kosten van een mislukte systeemintegratie?

Naast de betaalde uren (€5.000 tot €25.000) zijn er indirecte kosten: verloren tijd van je team, correctiewerk achteraf, klantontevredenheid door fouten, gemiste groeikansen, en medewerkersfrustratie. Die indirecte kosten zijn vaak veel hoger dan de directe investering.

Kun je oude processen automatiseren zonder aanpassingen?

Dat kan technisch, maar het is zelden slim. Huidige processen zijn vaak trucjes om om de beperkingen van oude software heen te werken. Als je die automatiseert, bouw je de workarounds in beton. Beter: processen opnieuw bekijken en ontwerpen voor de nieuwe situatie. 50-75% van de projecten die oude processen kritiekloos digitaliseren, mislukt.

Hoe begin je met systeemintegratie als je weinig technische kennis hebt?

Begin met het probleem, niet de techniek. Beschrijf concreet waar je tegenaan loopt: hoeveel tijd kost het handmatige werk, hoeveel fouten maken jullie, waar zit de frustratie? Een goede partner vertaalt dat naar een technische oplossing. Je hoeft zelf geen technische kennis te hebben — je moet wel precies weten hoe je bedrijf werkt.

Tot slot: techniek is niet het probleem

Laten we eerlijk zijn: de technologie werkt. API's zijn volwassen. Systemen kunnen met elkaar praten. De tools zijn er.

Waar het misgaat is in de vertaalslag van "hoe werkt ons bedrijf" naar "wat moet de koppeling doen". Die vertaalslag vraagt meer dan technische kennis. Het vraagt begrip van bedrijfsprocessen, branchekennis, en het vermogen om de juiste vragen te stellen.

Als je een puur technische partij inhuurt, krijg je een technische oplossing. Technisch correct, maar zakelijk waardeloos als de aannames niet kloppen. Het is niet hun schuld — ze bouwen wat je vraagt, niet wat je bedrijf nodig heeft.

Bij SyncIT kijken we altijd met de driehoek: de blik van een ondernemer (waar loop je tegenaan?), een productowner (hoe moet het werken?) én een developer (hoe bouwen we dat?). Pas als die drie kloppen, bouwen we. Dat voortraject kost tijd, maar bespaart maanden aan correctiewerk achteraf.

Loop je vast in handmatig werk, systemen die niet met elkaar praten, of een eerdere integratie die niet doet wat je had verwacht? Plan een vrijblijvend gesprek. We helpen je de juiste vragen te stellen voordat we ook maar één regel code schrijven. Geen verkooppraatje, gewoon uitzoeken of en hoe we je kunnen helpen.

Want uiteindelijk gaat het niet om techniek. Het gaat om rust, grip en ritme in je bedrijf. En dat krijg je niet door sneller data te verplaatsen — dat krijg je door slimmer te werken.