Integraties tussen applicaties: systemen laten samenwerken zonder nieuwe problemen te bouwen

Een koppeling bouwen is een middag werk. Een koppeling bouwen die over drie jaar nog steeds klopt is iets anders. Daar gaat deze pagina over.

applicatie integratie
integraties tussen applicaties

Het probleem is zelden dat systemen niet kunnen praten

Vrijwel elk modern pakket heeft tegenwoordig een API. De vraag of twee systemen technisch met elkaar kunnen communiceren is dus bijna nooit het probleem. Toch zitten organisaties massaal met dezelfde klachten: gegevens die op twee plekken anders staan, orders die iemand overtypt, een maandelijkse export die niet klopt, en een klantnaam die in drie systemen drie keer anders is gespeld.

De oorzaak zit niet in de techniek maar in de afspraken eromheen. Welk systeem is leidend voor welk gegeven? Wat gebeurt er als een bericht niet aankomt? Wie merkt dat? En wie past de koppeling aan als een van beide kanten verandert?

Vier manieren om te koppelen

Er is geen beste methode. Er is een beste methode voor jouw situatie, en die hangt af van wat je koppelt, hoe vaak, en hoe erg het is als er iets misgaat.

Methode Wanneer je die kiest Let op
Standaardconnector Veelgebruikte combinatie, standaardvelden, geen bijzondere logica Je zit vast aan wat de connector ondersteunt; maatwerkvelden vallen er vaak buiten
Integratieplatform (iPaaS) Meerdere systemen, hogere volumes, behoefte aan logging en herstel Abonnementskosten; vraagt iemand die het beheert
Maatwerk API-koppeling Specifieke logica, afwijkende velden, geen bruikbare standaardoplossing Meeste controle, meeste onderhoud; documentatie is cruciaal
RPA Het systeem heeft geen bruikbare API of importroute Werkt op schermniveau en breekt bij interface-wijzigingen

In de praktijk combineer je ze. Een standaardconnector voor de hoofdstroom, maatwerk voor de twee velden die er niet in zitten, en een RPA-bot voor dat ene oude portaal waar geen API achter zit.

De zes vragen die je beantwoordt vóórdat je bouwt

Dit is het deel dat bij de meeste koppelprojecten wordt overgeslagen, en het verklaart waarom ze later alsnog problemen geven.

  • Wie is eigenaar van welk gegeven?

    Per veld, niet per systeem. Een klantnaam kan in je CRM thuishoren terwijl het btw-nummer uit je boekhouding komt en de leveringsvoorkeur uit je WMS. Leg dat vast in een eigenaarschapsmatrix. Zonder die afspraak gaan twee systemen elkaar om beurten overschrijven, en dat is een probleem dat pas na maanden opvalt.

  • Welke kant op, en hoe vaak?

    Eenrichtings- of tweerichtingsverkeer, realtime of periodiek. Realtime klinkt altijd beter maar is duurder en kwetsbaarder. Voor voorraad bij snellopende artikelen is het noodzaak; voor een adreswijziging is één keer per uur ruim voldoende.

  • Hoe herken je of twee records dezelfde zijn?

    De matchingsleutel. E-mailadres, KvK-nummer, klantnummer, artikelnummer? Dit is de meest onderschatte vraag en de meest voorkomende oorzaak van dubbele records. Als beide systemen hun eigen nummering hebben, moet je een koppeltabel bijhouden.

  • Wat gebeurt er als het misgaat?

    Een API die er even uit ligt, een veld dat te lang is, een verplicht veld dat leeg is. Krijgt iemand een melding, wordt het bericht opnieuw aangeboden, of verdwijnt het stilletjes? Bij duizend orders per dag ontdek je een stille fout pas bij de klacht.

  • Wat is het volume, nu en over twee jaar?

    Een koppeling die honderd records per dag verwerkt is iets anders dan een die er vijftigduizend doet. Dat bepaalt je architectuur, en achteraf opschalen is bijna altijd opnieuw bouwen.

  • Wie beheert hem?

    Een koppeling is geen project maar een voorziening. Beide kanten brengen updates uit, velden veranderen, en iemand moet dat opmerken voordat je klant dat doet.

Integraties die wij veel bouwen: rond Zoho

Hieronder een greep uit koppelingen die we regelmatig realiseren. Staat jouw combinatie er niet bij, dan is dat zelden een belemmering: met maatwerk API-koppelingen verbinden we vrijwel elk systeem, inclusief eigen ontwikkelde platformen.

  • Exact Online en Zoho CRM

    De meest gevraagde combinatie. Klantgegevens, facturen en betalingen stromen tussen je financiële administratie en je CRM, zodat je verkoper openstaande posten ziet zonder in te loggen bij finance, en je boekhouding geen klantgegevens hoeft over te tikken. Hier speelt de eigenaarschapsvraag sterk: adresgegevens horen meestal in CRM, fiscale gegevens in Exact.

  • WooCommerce en Zoho CRM

    Je WordPress-webshop als verkoopkanaal, met orders, klantgegevens en interacties die automatisch in je CRM landen. Daarmee wordt een webshopklant een herkenbaar profiel in plaats van een rij in een orderoverzicht: de basis voor gerichte marketing en opvolging.

  • Lightspeed en Zoho CRM

    Via een maatwerk API-koppeling gaan klant- en orderdata rechtstreeks naar je CRM. Vooral waardevol voor organisaties die naast hun webshop ook actief accountbeheer doen en het hele klantbeeld op één plek willen.

  • Zoho CRM en Picqer

    De logistieke kant. Door je CRM te koppelen aan Picqer stroomlijn je het orderproces van bestelling tot verzending: orders worden sneller verwerkt, de klantcommunicatie is transparanter en voorraadstanden blijven actueel. Let hier op de synchronisatiefrequentie van voorraad: nachtelijke updates leiden bij snellopende artikelen gegarandeerd tot verkopen die je niet kunt leveren.

  • Clickker en Zoho CRM

    Je financiële administratie en je klantsysteem in één samenhangend geheel, zodat je besluitvorming op complete informatie rust in plaats van op twee halve beelden.

  • UBO-identificatie in Zoho CRM

    Een eigen door ons ontwikkelde applicatie waarmee je rechtstreeks vanuit Zoho CRM de uiteindelijk belanghebbende van een klant identificeert, zoals de Wwft vereist. Dit is een voorbeeld van een integratie die verder gaat dan data verplaatsen: een compliance-proces dat in je bestaande werkomgeving plaatsvindt in plaats van in een los systeem met een eigen inlog.

Integraties rond Creatio

  • Exact Globe en Creatio

    Klantinformatie, verkoopgegevens en facturen tussen je financiële systeem en je BPM-platform, zodat je procesvoering en je administratie dezelfde werkelijkheid zien.

  • WordPress en Creatio

    Een maatwerk API-koppeling tussen je website of webshop en Creatio, waarbij de online klantervaring aan de voorkant staat en alle data aan de achterkant automatisch in je procesplatform landt.

  • Creatio en Picqer

    Dezelfde logistieke stroomlijning als bij Zoho, maar dan met Creatio als orkestratielaag: orders snel verwerkt, transparante communicatie en een voorraad die klopt.

  • Clickker en Creatio

    Financiële administratie en procesplatform in één omgeving, zodat klant-, verkoop- en financiële gegevens bij elkaar komen.

building API

En als jouw combinatie er niet bij staat

Dan bouwen we hem. Dat is geen marketingzin maar het normale werk: de meeste koppelingen die wij maken bestaan nog niet als standaardproduct. Branchepakketten, overheidsportalen, leveranciersomgevingen, machines en zelfontwikkelde systemen vallen vrijwel altijd in die categorie.

Onze systemen praten nu met elkaar. Het dubbele invoerwerk is verdwenen, en de fouten die daarbij hoorden ook.

Voorbeeldquote Echte klantquote volgt

Waar koppelingen in de praktijk stukgaan

Een update aan één kant. Een van beide leveranciers brengt een nieuwe versie uit, een veld verandert van naam of een API-versie loopt af. Zonder monitoring merk je dat pas als de telefoon gaat.

De koppeling doet te veel. Als er bedrijfslogica in je koppeling zit (kortingsregels, goedkeuringen, berekeningen) zit die op de verkeerde plek. Die hoort in een van beide systemen of in een procesplatform. Een koppeling hoort te vertalen en te vervoeren, niet te beslissen.

Datakwaliteit aan de bron

Dubbele klanten, artikelnummers die niet overeenkomen, adressen zonder huisnummer. Een koppeling vermenigvuldigt die problemen in plaats van ze op te lossen. Opschonen gaat altijd vooraf aan koppelen.

Niemand kijkt naar de logging

Veel koppelingen loggen keurig, maar niemand kijkt erin. Een foutmelding die nergens terechtkomt, bestaat in de praktijk niet.

Er is geen documentatie

De persoon die hem heeft gebouwd is weg, en er ligt niets. Dan wordt elke wijziging een onderzoek.

business proces automation

Beheer: het deel dat niemand verkoopt

Een koppeling bouwen is het makkelijke deel. Hem vijf jaar laten draaien is het werk. Dat betekent concreet: monitoring die meldt wanneer er iets niet doorkomt, een logboek dat iemand daadwerkelijk bekijkt, een afspraak over wie er kijkt als er iets stukgaat, en documentatie waarmee ook een ander team verder kan.

Wij leveren koppelingen op die overdraagbaar zijn. Je moet van ons af kunnen: een integratie die alleen wij begrijpen is geen oplossing maar een afhankelijkheid.

Hoe wij een koppeltraject aanpakken

Heb je nog geen helder beeld van je processen? Dan is een losse procesmapping-workshop vaak een goed startpunt, zonder verplichting om daarna iets te bouwen.

  1. We beginnen bij het proces, niet bij de systemen

    Wat moet er gebeuren, voor wie, en hoe vaak? Soms blijkt dat de helft van de gewenste synchronisatie helemaal niet nodig is.

  2. We leggen eigenaarschap per gegeven vast

    In een matrix die beide kanten begrijpen.

  3. We bepalen de methode

    Connector, platform, maatwerk of RPA, op basis van volume, complexiteit en beheerlast.

  4. We bouwen inclusief foutafhandeling, logging en herhaalpogingen

    Niet als nabrander.

  5. We testen met echte data

    Inclusief de rare gevallen die altijd blijken te bestaan.

  6. We leveren op met documentatie en monitoring

    En spreken het beheer af.

Een koppeling is geen doel, maar een afspraak die uitgevoerd wordt

Systemen verbinden gaat niet over techniek. Het gaat over het vastleggen van wie waarover gaat, en dat vervolgens laten uitvoeren door software in plaats van door mensen die het hopelijk onthouden.

Dat is waarom wij altijd beginnen bij de vraag welk systeem leidend is voor welk gegeven, en waarom we een koppeling pas opleveren als duidelijk is wie hem beheert. Zoho, Creatio, je boekhouding, je webshop en je magazijnsysteem kunnen prima samenwerken, mits iemand de afspraken heeft gemaakt.

functioneringsgesprek

Veelgestelde vragen over integraties tussen applicaties

  • Dat loopt sterk uiteen. Een standaardconnector tussen twee gangbare pakketten is vooral een kwestie van configureren en kost dagen. Een maatwerk API-koppeling met afwijkende velden, bedrijfsregels en hoge volumes kost weken. De grootste kostenbepaler is zelden de techniek maar de complexiteit van de afspraken: hoeveel velden, hoeveel richtingen, hoeveel uitzonderingen. Vraag altijd ook naar de beheerkosten, want die lopen door.

  • Een eenvoudige, eenzijdige koppeling met een beperkt aantal velden staat doorgaans binnen enkele weken, inclusief testen. Complexere trajecten met meerdere systemen, tweerichtingsverkeer en datamigratie lopen op naar enkele maanden. De analyse en het opschonen van data kosten in de praktijk meer tijd dan het bouwen.

  • Dan zijn er nog drie routes. Veel pakketten bieden een import- of exportroute via bestanden, wat minder elegant maar robuust is. Sommige leveranciers bieden databasetoegang. En als geen van beide bestaat, kan een RPA-bot de handelingen uitvoeren zoals een medewerker dat zou doen. Dat laatste is kwetsbaarder voor interface-wijzigingen, maar het werkt, en het is bij oudere branchepakketten en leveranciersportalen vaak de enige optie.

  • Niet één systeem voor alles, maar per gegeven. Klantnaam en contactgegevens horen meestal in je CRM, fiscale gegevens en facturen in je boekhouding, voorraad en artikelgegevens in je ERP of WMS. Leg dat vast per veld voordat je bouwt. Dit is de belangrijkste beslissing in het hele traject en tegelijk de vaakst overgeslagen.

  • Dat hangt volledig af van hoe hij is gebouwd. Een goede koppeling detecteert fouten, probeert het opnieuw bij tijdelijke storingen, logt alles en stuurt een melding naar een aangewezen persoon. Een slechte koppeling laat berichten stilletjes verdwijnen. Vraag bij elke offerte expliciet hoe foutafhandeling en monitoring geregeld zijn: dat is het verschil tussen een koppeling die je vertrouwt en een die je regelmatig moet controleren.

  • Ja. In de praktijk komen we regelmatig koppelingen tegen die ooit zijn gebouwd door iemand die er niet meer is, zonder documentatie en zonder monitoring. We brengen dan eerst in kaart wat er feitelijk gebeurt, repareren of herbouwen waar nodig, en zorgen dat het daarna overdraagbaar is.

  • Bij twee systemen en een overzichtelijke stroom kan een directe koppeling prima. Zodra je meer dan drie systemen verbindt, of wanneer volumes oplopen en je fouten wilt kunnen herstellen, wordt een integratieplatform meestal de verstandigere keuze. Je krijgt dan logging, bufferen en opnieuw aanbieden standaard in plaats van dat je het per koppeling bouwt. Daar staan abonnementskosten tegenover en iemand die het beheert.

  • Een koppeling vervoert en vertaalt gegevens tussen systemen. Procesautomatisering bepaalt wat er met die gegevens moet gebeuren: welke stappen, welke goedkeuringen, welke uitzonderingen. Die twee moeten gescheiden blijven. Zodra er bedrijfslogica in je koppeling kruipt, wordt hij onbeheersbaar: leg die logica in een van beide systemen of in een procesplatform.

Loopt er bij jou nog ergens een Excel tussen twee systemen?

Leg hem aan ons voor.