Kort samengevat
- Dubbel invoeren kost tijd en is een bron van fouten, ook al ziet niemand het.
- Begin niet bij de techniek. Bepaal eerst per gegeven waar het voor het eerst wordt vastgelegd: de bron van waarheid.
- Er zijn vier soorten koppelingen: export en import, API, webhook en koppelplatform.
- Koppelingen gaan stuk bij updates en verschillen in betekenis. Iemand moet ze bewaken.
In dit artikel
Het overtikken dat niemand ziet
Een dienst wordt gepland in het rooster. Daarna zet iemand de gewerkte uren in het urensysteem. Dan gaan ze nog eens naar de salarisadministratie. En aan het eind van de maand naar de facturatie.
Vier keer hetzelfde gegeven. Drie keer overtikken. In veel organisaties is dat gewoon zo gegroeid.
Dat werk ziet niemand, tot er een fout in sluipt. Een verkeerd getal in het salaris. Een dienst die niet wordt gefactureerd. Of een klant die belt omdat de gegevens niet kloppen.
Figuur
Overtikken tussen systemen, of één bron die doorgeeft
Zonder koppeling
Met één bron
Begin bij de bron van waarheid
De verleiding is om meteen naar de techniek te kijken. Welk pakket heeft een API? Welk koppelplatform is het handigst? Begin liever een stap eerder.
Bepaal per gegeven waar het voor het eerst wordt vastgelegd. Dat is de bron van waarheid. Alle andere systemen lezen het daar uit, en passen het daar niet aan.
Een paar voorbeelden:
- Wie wanneer werkt: de bron is het rooster.
- Wie er in dienst is: de bron is het HR-systeem.
- Wat een klant heeft besteld: de bron is de bestelling of de offerte.
- Wat er is gefactureerd: de bron is de boekhouding.
Klinkt logisch. Maar in de praktijk blijken er vaak twee bronnen te zijn. Het rooster zegt iets anders dan de urenlijst. Dan moet je eerst kiezen welke leidend is. Anders koppel je de verwarring alleen maar door.
Vier soorten koppelingen
Als de bron duidelijk is, kies je hoe de gegevens doorgaan. Er zijn grofweg vier manieren.
| Soort | Hoe het werkt | Goed voor | Let op |
|---|---|---|---|
| Export en import | Een bestand uit het ene systeem halen en in het andere inlezen | Af en toe, kleine aantallen | Blijft handwerk, en versies lopen uit elkaar |
| API-koppeling | Systemen wisselen direct gegevens uit via een afgesproken taal | Dagelijks gebruik, actuele gegevens | Hangt af van wat de leverancier openstelt |
| Webhook | Het ene systeem seint het andere zodra er iets verandert | Direct reageren op een gebeurtenis | Vang op wat er gebeurt als de ontvanger even niet bereikbaar is |
| Koppelplatform | Een tussenlaag die meerdere systemen verbindt | Veel systemen tegelijk | Een extra abonnement en een extra plek waar iets mis kan gaan |
Waar koppelingen stukgaan
Een koppeling bouwen is één ding. Hem werkend houden is een ander. Dit zijn de vier plekken waar het in onze ervaring misgaat.
Een leverancier verandert iets. Een update van het pakket, een nieuw veld, een andere naam. De koppeling werkt niet meer, en niemand merkt het meteen.
Woorden betekenen net iets anders. In het rooster is een "dienst" acht uur. In het urensysteem telt de pauze niet mee. Dan kloppen de getallen niet, terwijl de koppeling technisch prima werkt.
Niemand houdt het in de gaten. Een koppeling die stil faalt, is gevaarlijker dan geen koppeling. Je denkt dat alles doorgaat, maar dat is niet zo.
Te veel tegelijk. Alles in één keer koppelen klinkt efficiënt. Maar als er iets misgaat, weet je niet waar.
Zo pakken wij het aan
We beginnen vaak met een koppeling die alleen leest. Het nieuwe systeem haalt gegevens op, maar verandert niets in het bronsysteem. Zo kan er niets kapot, en zie je eerst of de gegevens kloppen.
Een paar voorbeelden uit ons werk:
- StarShift, de roosterapplicatie voor een zorgorganisatie, is gekoppeld aan HR en uren. Wat gepland en gewerkt is, gaat door zonder overtikken.
- De kandidaatmatching voor een technisch recruitmentbureau haalt kandidaten uit OTYS en HelloFlex. Het bureau werkt gewoon door in zijn eigen pakketten.
- Het kliksysteem voor kwaliteitsregistratie is gekoppeld aan het rooster, zodat medewerkers niets dubbel invullen.
In alle drie de gevallen blijven wij de koppeling beheren. Verandert een leverancier iets, dan passen wij het aan.
- 1
Maak een lijst van alles wat je overtikt
Van welk systeem naar welk systeem, hoe vaak en door wie?
- 2
Kies per gegeven de bron van waarheid
Waar wordt het voor het eerst vastgelegd?
- 3
Vraag wat elk pakket openstelt
Is er een API, een webhook of alleen een export?
- 4
Begin met één koppeling die alleen leest
Controleer een paar weken of de gegevens kloppen.
- 5
Regel het beheer
Wie merkt het als het misgaat, en wie lost het op?
Gaat het overtikken vooral om een groot Excel-bestand? Lees dan vijf signalen dat Excel op is. En twijfel je of een koppeling genoeg is of dat er meer nodig is, kijk dan bij maatwerksoftware of standaardpakket. Wat we voor de industrie doen, staat op technisch mkb en industrie.
Veelgestelde vragen
Wat is een API-koppeling?
Een API is een afgesproken manier waarop een systeem gegevens deelt met andere systemen. Bij een API-koppeling vraagt het ene systeem gegevens op bij het andere, of stuurt ze door. Zonder dat iemand iets overtikt.
Wat is het verschil tussen een API en een webhook?
Bij een API vraagt jouw systeem zelf om gegevens, bijvoorbeeld elk uur. Bij een webhook seint het andere systeem jou zodra er iets verandert. Een webhook is dus sneller, maar je moet goed opvangen wat er gebeurt als jouw kant even niet bereikbaar is.
Kan elk systeem gekoppeld worden?
Niet altijd. Het hangt af van wat de leverancier openstelt. Sommige pakketten hebben een goede API, andere alleen een export. Vraag dat na voordat je een pakket kiest.
Wie beheert een koppeling?
Spreek dat vooraf af. Een koppeling kan stukgaan als een leverancier iets verandert. Iemand moet merken dat het misgaat en het oplossen, bij voorkeur voordat een collega het merkt.
Bronnen
- McKinsey Global Institute, The social economy: Unlocking value and productivity through social technologies, juli 2012.
- Voorbeelden StarShift, kandidaatmatching en kliksysteem: BesluitPartners, 2026.
Melih Durmaz
Oprichter van BesluitPartners
Melih werkte als procesoperator in de petrochemie en in operations in de energiesector. Nu bouwt en beheert hij software die past bij hoe het werk echt loopt, voor organisaties van 5 tot 500 mensen.
Meer over Melih en BesluitPartners