Systemen die niet met elkaar praten: zo koppelt u ze en wat het oplevert
Twee systemen die niet met elkaar praten koppelt u op drie manieren: via hun API als die er is, via bestandsuitwisseling als die er niet is, of via een tussenlaag die tussen beide vertaalt. Wat mogelijk is bepaalt de keuze, niet de voorkeur. Constant is het resultaat: het overtikken stopt, en daarmee de meeste datafouten.
Het signaal dat u een koppeling nodig hebt
Het is bijna altijd hetzelfde tafereel: iemand op de administratie is meerdere uren per week bezig gegevens van het ene naar het andere systeem te zetten. Dat is geen probleem van die persoon maar van het ontwerp, en het is op te lossen.
- Webshoporders worden handmatig in het bedrijfssysteem gezet
- Dezelfde klant staat in drie systemen onder drie verschillende namen
- Iemand exporteert maandelijks naar een spreadsheet om twee systemen te laten kloppen
- Magazijn en website zeggen iets anders over hetzelfde product
- Geklokte uren worden opnieuw ingetypt voor de salarisverwerking
- Rapportages duren dagen omdat gegevens uit meerdere systemen moeten komen
De drie manieren om twee systemen te koppelen
De nette route is de API: het systeem biedt een gedocumenteerde deur waardoor gegevens in realtime in- en uitgaan. Die gebruiken we altijd als hij bestaat, want hij is stabiel en hangt niet af van iemand die een bestand op de juiste plek zet.
Is er geen API — gebruikelijk bij oudere bedrijfssystemen — dan werkt u met bestandsuitwisseling: de één zet een bestand in een map of op een server, de ander haalt het op en verwerkt het. Minder elegant, maar betrouwbaar als u goed afvangt wat er gebeurt als een bestand fout of helemaal niet aankomt.
Zijn er meerdere systemen bij betrokken, dan loont een tussenlaag die van alle kanten ontvangt, formaten vertaalt en verdeelt. Dat kost vooraf meer, maar voorkomt zes gekruiste koppelingen die breken zodra iemand iets bijwerkt.
Wat u beslist voordat er code komt
Koppelingen lopen bijna altijd stuk op dezelfde slecht beantwoorde vragen. Wie heeft gelijk: als een klant in twee systemen met andere gegevens staat, welke is leidend. Hoe vaak: realtime, elk uur of eenmaal per dag, want elke variant kost iets anders. En wat gebeurt er bij een fout: als het andere systeem plat ligt, opnieuw proberen, in de wachtrij zetten, of iemand waarschuwen?
Die derde vraag scheidt een koppeling die jaren meegaat van een koppeling die dagelijks bewaakt moet worden.
Wat het oplevert, los van bespaarde uren
De tijdwinst valt als eerste op, maar is niet het waardevolst. Wat echt verandert is dat de gegevens elkaar niet meer tegenspreken: één voorraadstand, één klantgegeven, één rapportage waar iedereen uit leest. Vanaf dat moment kunt u op cijfers besluiten in plaats van te discussiëren uit welk systeem ze komen.
Ook de foutmarge verandert: een gegeven dat niet twee keer wordt ingetypt kan niet twee keer verkeerd worden ingetypt.
Hoe wij dat bij iDeo Networks aanpakken
Wij bouwen maatwerkkoppelingen tussen bedrijfssystemen, webshops, eigen applicaties en clouddiensten. We beginnen altijd met vaststellen wat elk systeem werkelijk toelaat, want daar komt de echte omvang vandaan en niet uit de brochure.
We werken in heel Spanje, inclusief de Canarische Eilanden, de Balearen, Ceuta en Melilla, en ook voor Spaanse vestigingen van internationale groepen die hun lokale systeem op het concernsysteem moeten laten aansluiten.
Gerelateerde diensten
Hebt u systemen die niet met elkaar praten?
Wij bekijken wat elk systeem toelaat en vertellen hoe u ze koppelt en welk handwerk verdwijnt.
Vertel ons uw situatie