Point-to-point-koppelingen of unified commerce: welk systeem heeft het laatste woord over je voorraad?

Je hebt twee systemen die het oneens zijn over je voorraad. Een koppeling ertussen kost een paar duizend euro en twee weken werk. Die lost het probleem op, dus je koopt hem. Bij twee systemen is dat de juiste keuze. Alleen is die koppeling niet de laatste, en de offerte waar het echt om gaat, ligt nog niet op tafel. Die komt bij systeem vier, als een nieuwe tool met drie andere moet praten en het aantal koppelingen sneller groeit dan het aantal systemen. Point-to-point of unified commerce is dus geen vraag met één juist antwoord uit het boekje. Het is een vraag over de kostencurve. Welke curve goedkoper uitvalt, hangt af van hoeveel systemen je over drie jaar draait, niet van hoeveel er vandaag pijn doen.

Wat in Google bovenaan staat over deze vergelijking, komt meestal van partijen die een van de twee antwoorden verkopen. Een eerlijk verhaal is daardoor lastig te vinden. Dit artikel probeert dat verhaal te zijn: wat elke aanpak kost naarmate je groeit, waar je source of truth (het systeem dat leidend is) in beide gevallen terechtkomt, een nuchtere vergelijking van beide kanten, en een keuzeregel die er niet van uitgaat dat je de dure optie moet kopen. Flatline bouwt zowel point-to-point-koppelingen als unified stacks. Dit advies is dus geen verkooppraatje. Het beschrijft de afweging zoals die in echte stacks uitpakt.

Twee aanpakken, en waar de source of truth zit

Een point-to-point-koppeling verbindt twee systemen rechtstreeks, zodat het ene systeem het andere kan uitlezen of bijwerken, waarbij je elk paar voor één specifiek doel aan elkaar knoopt. Unified commerce is een architectuur waarin al je systemen één gedeelde datalaag gebruiken. Elk kanaal leest en schrijft dan in hetzelfde record, in plaats van een eigen versie bij te houden. Het eerste is een verzameling losse draden tussen systemen. Het tweede is een gedeeld centrum waar alle systemen op aansluiten.

Wat de pagina’s van leveranciers overslaan: beide aanpakken kunnen één source of truth hebben. Een source of truth is een afspraak over welk systeem het leidende getal bevat. Die afspraak maak je in een point-to-point-opzet net zo goed als in een unified opzet. In een point-to-point-stack kun je bijvoorbeeld het ERP aanwijzen als leidend voor voorraad, en elke rechtstreekse koppeling laten uitgaan van wat daar staat. Het echte verschil tussen de twee zit dus niet in de vraag óf er een source of truth is. Het zit in hoeveel koppelingen je moet bouwen en onderhouden om die bron betrouwbaar te houden, en hoe snel dat aantal groeit als er systemen bijkomen.

Daar komt de hele beslissing op neer. De vraag is niet “verbonden of versnipperd”. De vraag is “hoeveel koppelingen heb je over drie jaar in beheer, en welk systeem is leidend”. Zo gesteld is het geen geloofskwestie meer, maar rekenwerk.

De criteria die echt de doorslag geven

Vijf criteria bepalen de keuze, en één ervan draait het antwoord om: wat het kost als je groeit. De vijf zijn de kosten vooraf, de kosten per systeem dat erbij komt, waar de source of truth ligt, onderhoud en hoe ver een storing doorwerkt, en de tijd tot de eerste werkende oplossing. De meeste vergelijkingen kijken alleen naar het eerste en het laatste criterium. Daardoor lijkt point-to-point steeds de voor de hand liggende goedkope optie. Dat is het ook, tot het tweede criterium alle andere overvleugelt.

Kosten vooraf zijn wat je betaalt om de eerste koppeling werkend te krijgen. Kosten bij groei zijn wat je betaalt voor elk extra systeem dat je aansluit. Daar lopen de twee aanpakken sterk uiteen. De plek van de source of truth gaat over welk systeem het leidende record heeft, en hoe rechtstreeks alle andere systemen daarbij kunnen. Bij onderhoud en storingen gaat het om wat er gebeurt als één koppeling breekt: valt er één verbinding uit, of trekt het door de hele stack? De tijd tot de eerste oplossing is hoe snel je die ene koppeling fixt die nu pijn doet. Onthoud deze vijf. Een eerlijke vergelijking is niets meer dan deze criteria toepassen, zonder de weegschaal een duwtje te geven.

Point-to-point of unified commerce, per criterium

Op de kosten vooraf wint point-to-point. Op de kosten bij groei wint unified commerce. Om het punt waar die twee elkaar kruisen, draait de hele beslissing. Eén point-to-point-koppeling is goedkoop en snel gebouwd. Een unified platform of een centrale integratielaag is een grote vaste investering, die je doet voordat je er iets van terugziet. Stopte de vergelijking op dag één, dan won point-to-point altijd. Maar ze stopt niet op dag één.

Waarom de kosten bij groei het antwoord omdraaien, kun je zelf narekenen. Moet elk systeem rechtstreeks met elk ander systeem praten, dan heeft een volledig gekoppelde stack n keer (n min 1), gedeeld door twee, verbindingen nodig. Twee systemen hebben één koppeling nodig. Drie hebben er drie nodig. Vier hebben er zes nodig. Vijf tien. Zes vijftien. Het aantal systemen groeit in een rechte lijn, het aantal koppelingen in een curve. En elke koppeling is maatwerk dat los gebouwd, getest en onderhouden moet worden. De meeste stacks zijn in de praktijk niet volledig gekoppeld, dus het echte aantal ligt onder dat plafond. Maar de vorm blijft: koppelingen groeien sneller dan systemen. Elke koppeling die erbij komt, kan op zichzelf stukgaan en is een extra regel op de onderhoudsfactuur. Dat is de prijs van “systeem vier” uit de inleiding. Het vierde systeem is niet bijzonder. Het is alleen het punt waar de curve de rechte lijn voorbij begint te lopen.

Unified commerce draait die vorm om. Elk systeem sluit één keer aan op de gedeelde laag, dus het aantal koppelingen groeit ongeveer gelijk op met het aantal systemen, niet sneller. Voor die laag betaal je vooraf flink. In ruil daarvoor blijven de kosten per nieuw systeem daarna vlak. Dan de source of truth: point-to-point kan er één hebben, maar moet die afdwingen via veel losse verbindingen. Daardoor raakt hij makkelijker uit de pas naarmate de stack groeit. Een unified laag houdt hem centraal vast, daar is hij voor ontworpen. Dat is waarom een unified opzet het record consistent houdt, ook als er steeds meer systemen bijkomen. Bij storingen werkt de afweging andersom. Een kapotte point-to-point-koppeling legt meestal één verbinding plat. Een probleem in de centrale laag raakt alles wat daaruit leest. Dat risico neem je voor lief, in ruil voor de vlakkere kostencurve.

Wanneer point-to-point, wanneer unified commerce

Kies point-to-point als je stack klein en stabiel is: twee of drie kernsystemen waar je niet steeds iets aan wilt toevoegen, één koppeling die het probleem oplost, en geen roadmap waarin de komende jaren steeds meer integraties staan. Dan is die koppeling geen compromis. Ze heeft precies het juiste formaat. Een unified platform kopen zou betekenen dat je een grote vaste prijs betaalt voor een probleem dat je niet hebt. Platformbudget uitgeven aan een stack van drie systemen is ook een verkeerde keuze, en dat lees je nergens op de pagina’s van leveranciers.

Kies unified commerce als je veel systemen gaat draaien, of als je plan voor de komende drie jaar er steeds meer toevoegt: nieuwe verkoopkanalen, meer vestigingen, een aparte B2B-tak, marketplaces, een abonnementsmodel. Stijgt het aantal systemen, dan kosten al die koppelingen samen meer dan het platform. Op dat moment is het de vlakke curve per systeem die je redt. Waar je op beslist, is het aantal systemen dat je over drie jaar verwacht te draaien. Niet het aantal dat dit kwartaal pijn doet. Heb je vandaag vier systemen en in 2028 negen, plan dan rond die negen. Wie op basis van die vier beslist, bouwt anderhalf jaar na het betalen van de koppelingen de hele integratielaag opnieuw.

Eerlijk gezegd kiezen de meeste merken niet verkeerd, maar op het verkeerde moment. Ze kiezen terecht voor point-to-point in de fase waarin ze zitten, en blijven dat doen als de curves elkaar allang gekruist hebben. Elke losse koppeling lijkt op zichzelf namelijk nog steeds goedkoop. De kosten dienen zich nooit aan in één factuur. Ze stapelen zich op over een stuk of twaalf.

Randgevallen: hybride opzetten en de middenweg

Voor groeiende middelgrote merken is de middenweg meestal het juiste antwoord: een centrale integratielaag. Die geeft je de vlakke kostencurve van unified commerce, zonder dat je naar één native systeem hoeft te replatformen. In plaats van elk systeem aan elk ander te knopen, laat je ze allemaal via één event-driven hub of integratielaag lopen. Die laag bewaakt de source of truth en stuurt wijzigingen door naar de rest. Je houdt je best-of-breed-systemen en krijgt toch één centrum, waardoor het aantal koppelingen niet uit de hand loopt.

Zo ziet een unified build er in de praktijk meestal uit. Toen Flatline de Shopify Plus-omgeving, POS, ERP en WMS van OGÉR samenbracht in één samenhangende structuur, was het doel niet om alles in één product te proppen. Het doel was de systemen één vast centrum te geven, zodat online en offline uit hetzelfde record lezen. Een hybride opzet werkt ook als het grootste deel van je stack stabiel is, maar één hoek vaak verandert. Houd de stabiele systemen dan op directe koppelingen en laat dat beweeglijke deel via een laag lopen. De strategische argumenten voor unified commerce kloppen, zodra je schaal het rechtvaardigt. Maar de meeste middelgrote merken beginnen beter met die laag dan met een volledig nieuw native platform.

Wanneer je de keuze opnieuw bekijkt

Bekijk de keuze opnieuw zodra je aantal systemen over de grens gaat die je zelf hebt gesteld, niet op een vast moment in het jaar. Welke kant je ook kiest, de keuze klopt alleen binnen een bepaalde omvang van je stack. En in welke omvang je zit, verandert als het bedrijf groeit. Schrijf op bij welk aantal systemen je zou overstappen. Ga je daaroverheen, dan is dat het signaal om opnieuw te kijken. Zo pak je elke beslissing aan waarvan het goede antwoord afhangt van een getal dat blijft bewegen.

De signalen dat je die grens voorbij bent, zijn steeds dezelfde: je bouwt elk kwartaal een nieuwe koppeling, één wijziging in een systeem vraagt aanpassingen op meerdere plekken, of je bent meer tijd kwijt aan het in de lucht houden van koppelingen dan aan het gebruiken van de data die ze verplaatsen. Zie je dat gebeuren, dan is de point-to-point-stack die bij vier systemen klopte ongemerkt de dure optie geworden. De laag die je eerder oversloeg, is nu de goedkopere. Die omslag vroeg zien is meer waard dan de eerste keuze perfect maken. Die eerste keuze was toch al tijdelijk.

Zet je de opties voor je source of truth op een rij? Neem deze beslissing dan voordat je koppelingen koopt. Flatline is Shopify Platinum Partner en bouwt zowel point-to-point-koppelingen als unified stacks. We kunnen dus naar het aantal systemen kijken dat je over drie jaar draait, en je vertellen op welke curve je werkelijk zit. Neem contact op, dan lopen we het samen met je door.

Veelgestelde vragen

Wat is het verschil tussen een point-to-point-koppeling en unified commerce?

Een point-to-point-koppeling verbindt twee systemen rechtstreeks, met een eigen verbinding voor één specifiek doel. Unified commerce sluit alle systemen aan op één gedeelde datalaag, waarin ze allemaal lezen en schrijven. Het praktische verschil zit in hoe het aantal verbindingen groeit: point-to-point voegt voor elk paar systemen een nieuwe koppeling toe, unified commerce één verbinding per systeem met een centraal record.

Is point-to-point goedkoper dan unified commerce?

Vooraf en bij een kleine, stabiele stack wel. Naarmate je systemen toevoegt, wordt het duurder. Eén koppeling kost weinig en werkt snel. Maar point-to-point-koppelingen groeien sneller dan het aantal systemen, en elke koppeling onderhoud je apart. Boven een bepaald aantal systemen zijn de opgetelde kosten daardoor hoger dan de grotere vaste prijs van een unified platform.

Heb je met point-to-point één source of truth?

Dat kan. Een single source of truth is een keuze over welk systeem het leidende record heeft. Dat dwing je in een point-to-point-opzet af door één systeem als master aan te wijzen. Het verschil is dat point-to-point dit via veel losse verbindingen moet doen. Daardoor raakt het makkelijker uit de pas als de stack groeit, terwijl een unified laag het centraal vasthoudt.

Wanneer stap je over van point-to-point naar unified commerce?

Stap over als het aantal systemen over drie jaar hoog is of blijft stijgen, niet omdat je huidige stack pijn doet. De signalen zijn praktisch: elk kwartaal een nieuwe koppeling bouwen, één systeemwijziging die aanpassingen op meerdere plekken vraagt, of meer tijd kwijt zijn aan het onderhoud van koppelingen dan aan het gebruik ervan. Zie je die signalen, dan kosten al je koppelingen samen al meer dan een centrale laag.

Is unified commerce altijd beter?

Nee. Bij een kleine, stabiele stack van twee of drie systemen die je niet wilt uitbreiden, is unified commerce overkill. Je betaalt een grote vaste prijs voor een probleem dat point-to-point al goedkoop oplost. Unified commerce wint als het aantal systemen hoog is of groeit. Daaronder passen directe koppelingen beter.

De belangrijkste punten

• Point-to-point of unified commerce kies je op basis van de kostencurve, niet op basis van best practices. Het juiste antwoord hangt af van hoeveel systemen je over drie jaar draait.

• Beide aanpakken kunnen één source of truth hebben. Het echte verschil is hoeveel koppelingen je moet onderhouden om die betrouwbaar te houden, en hoe snel dat aantal groeit.

• Point-to-point wint op kosten vooraf en op de snelheid van de eerste oplossing. Unified commerce wint op kosten bij groei, omdat het aantal koppelingen gelijk oploopt met het aantal systemen in plaats van sneller.

• Point-to-point-koppelingen groeien sneller dan de systemen die ze verbinden. Die curve, niet één losse factuur, is de prijs van het moment “systeem vier”.

• De gebruikelijke fout is het verkeerde moment, niet de verkeerde keuze: terecht voor point-to-point kiezen en eraan vasthouden als de curves elkaar al gekruist hebben. Schrijf op bij welk aantal systemen je zou overstappen, en kijk opnieuw als je daaroverheen gaat.

De voorraadverschillen die je wilt oplossen, komen voort uit deze keuze. Daarom loont het om haar bewust te maken, en niet koppeling voor koppeling. Neem de beslissing over je source of truth zorgvuldig, stem haar af op de stack die je straks hebt in plaats van de stack van nu, en je integratiekosten zijn geen reeks verrassingen meer. Ze volgen een curve die je zelf hebt gekozen.