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.
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.
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?
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.
Dit is het deel dat bij de meeste koppelprojecten wordt overgeslagen, en het verklaart waarom ze later alsnog problemen geven.
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.
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.
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.
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.
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.
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.
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.
Klantinformatie, verkoopgegevens en facturen tussen je financiële systeem en je BPM-platform, zodat je procesvoering en je administratie dezelfde werkelijkheid zien.
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.
Dezelfde logistieke stroomlijning als bij Zoho, maar dan met Creatio als orkestratielaag: orders snel verwerkt, transparante communicatie en een voorraad die klopt.
Financiële administratie en procesplatform in één omgeving, zodat klant-, verkoop- en financiële gegevens bij elkaar komen.
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.
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.
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.
Veel koppelingen loggen keurig, maar niemand kijkt erin. Een foutmelding die nergens terechtkomt, bestaat in de praktijk niet.
De persoon die hem heeft gebouwd is weg, en er ligt niets. Dan wordt elke wijziging een onderzoek.
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.
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.
Wat moet er gebeuren, voor wie, en hoe vaak? Soms blijkt dat de helft van de gewenste synchronisatie helemaal niet nodig is.
In een matrix die beide kanten begrijpen.
Connector, platform, maatwerk of RPA, op basis van volume, complexiteit en beheerlast.
Niet als nabrander.
Inclusief de rare gevallen die altijd blijken te bestaan.
En spreken het beheer af.
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.
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.
Leg hem aan ons voor.