Eén source of truth voor je voorraad: wat een unified-commerce-architectuur echt vraagt

Zoek op deze term en bijna elk resultaat geeft je hetzelfde: een checklist met onderdelen en een platform om te kopen. Centrale data, één klantprofiel, realtime voorraad, kant-en-klare integraties, teken hier. Die checklist klopt wel, maar hij slaat het deel over dat bepaalt of je voorraadtelling te vertrouwen is. Een unified-commerce-architectuur is minder een product dat je koopt dan een besluit over welk systeem ernaast mag zitten. De echte eis is een volgorde. Wijs voor elk soort data één eigenaar aan, leg vast hoe het getal van die eigenaar bij alle andere systemen komt, en houd dat eigenaarschap overeind terwijl je stack groeit. Dit artikel loopt die volgorde door, met de twee plekken waar de meeste projecten vastlopen.

Een checklist is niet genoeg, omdat een lijst met onderdelen je vertelt wat je moet samenstellen, niet hoe je die onderdelen het met elkaar eens laat worden. Vier systemen kunnen elk de beste in hun soort zijn en het toch oneens zijn over hoeveel stuks er op de plank liggen. Geen enkele onderdelenlijst bepaalt namelijk wie er wint als twee systemen een ander getal hebben. Dat besluit is de architectuur. Hieronder staat de bouwvolgorde die op elk kanaal één betrouwbare voorraadtelling oplevert. Hij is geschreven voor het team dat al besloten heeft om te bouwen en wil weten wat daarvoor nodig is.

Begin hier: bepaal welk systeem ernaast mag zitten

Nog vóór de eerste connector komt het besluit waar alles op rust: welk systeem heeft voor elk soort data het leidende getal? Alle andere systemen volgen dat getal, in plaats van hun eigen getal door te drukken. Dat is wat “single source of truth” in de praktijk betekent. Geen product, maar een uitspraak: als twee systemen het oneens zijn, wint dit systeem en geeft dat andere toe. Alles wat daarna komt, is het mechaniek om die uitspraak af te dwingen.

De vraag welk systeem “ernaast mag zitten” is de handigste manier om ernaar te kijken. In elke echte stack hebben systemen even verschillende getallen. De architectuur hoeft dat niet onmogelijk te maken, dat lukt ook niet. Ze moet vooraf bepalen wiens getal telt als het gebeurt. Ernaast zitten mag elk systeem behalve de eigenaar. Een systeem dat geen eigenaar is en een verouderd getal heeft, herstelt zich bij de volgende gebeurtenis vanzelf. Zit de eigenaar ernaast, dan is dat de enige fout die bij een klant een belofte oplevert die je niet kunt waarmaken. Wijs je de eigenaar aan, dan heb je het ene getal aangewezen dat altijd moet kloppen.

Neem dit besluit per datadomein, niet één keer voor de hele stack. Voorraad, bestellingen, klanten en prijzen hebben elk een eigenaar nodig, en dat zijn vaak verschillende systemen. Beslis je het in één keer voor alles (“het ERP is overal leidend”), dan krijg je voor sommige domeinen een eigenaar die daar nooit voor gemaakt was.

Stap één: breng de domeinen in kaart en geef elk een eigenaar

De eerste bouwstap: zet je datadomeinen op een rij en wijs aan elk precies één leidend systeem toe. Schrijf erbij wat de andere systemen met die data mogen doen. Voorraad, bestellingen, klantgegevens, prijzen, productcatalogus. Per domein schrijft één systeem de waarheid weg en lezen de andere mee.

De vraag welk systeem eigenaar wordt van de voorraad weegt hier het zwaarst, en daar zijn drie gangbare antwoorden op. Ligt je fysieke telling in het ERP of het warehousesysteem het dichtst bij de werkelijkheid, dan is dat systeem eigenaar van de fysieke voorraad. Het eCommerce-platform leest daar een afgeleid verkoopbaar getal uit. Is je allocatie- en kanaallogica het verst uitgewerkt in een order management system, dan is het OMS eigenaar van de beschikbaarheid en lezen winkel en webshop allebei daaruit. Ben je een retailer die om Shopify heen is gebouwd, en staat en beweegt je voorraad vooral binnen Shopify, dan kan het platform zelf eigenaar zijn en stemt het ERP daarop af. Twijfel je, kies dan de veilige standaard: het systeem waar voorraad fysiek van hand wisselt, is eigenaar van de fysieke voorraad. De verkoopbare beschikbaarheid reken je één laag hoger uit.

De regel die je opschrijft, is net zo belangrijk als de keuze zelf. “Het ERP is eigenaar van de fysieke voorraad; Shopify beheert niets van de voorraad behalve het verkoopbare getal dat het binnenkrijgt” is een regel die een developer kan bouwen en een team kan verdedigen. “Het ERP en Shopify houden de voorraad allebei synchroon” is geen regel. Het is het ontbreken ervan, en daar beginnen de getallen uit elkaar te lopen.

Stap twee: leg vast wat “beschikbaar” betekent en wie het uitrekent

De architectuur moet het verkoopbare getal vastleggen als formule en één systeem aanwijzen dat het uitrekent. “Beschikbaar” is namelijk geen ruwe telling. In de meeste commercesystemen is beschikbare voorraad de fysieke voorraad min wat toegezegd en niet beschikbaar is. Voert elk systeem die aftreksom uit met zijn eigen beeld van wat er toegezegd is, dan komen er van dezelfde plank verschillende verkoopbare getallen. Eén systeem moet de berekening in handen hebben.

De eis is dus helder. Kies het systeem dat de verkoopbare beschikbaarheid uitrekent. Leg precies vast wat het ervan aftrekt (openstaande bestellingen, reserveringen, beschadigde voorraad, veiligheidsbuffers). En laat elk kanaal dat uitgerekende getal tonen, in plaats van zelf een getal af te leiden. In deze stap wordt “één eigenaar” van een principe een getal waar een klant op kan vertrouwen. De eigenaar houdt niet alleen de fysieke voorraad bij. Hij publiceert het ene verkoopbare getal waar de hele stack op verkoopt.

Dit gaat vaak ongemerkt mis, omdat het getal van elk systeem op zichzelf correct lijkt. De voorraadlaag tussen ERP en Shopify is precies waar een heldere definitie voorkomt dat de telling uiteenvalt. Leg de formule één keer vast, op één plek, en de rest van de architectuur heeft iets stevigs om door te geven.

Stap drie: kies hoe het leidende getal bij alle andere systemen komt

Staan eigenaar en formule vast, dan heb je een manier nodig om het getal te verspreiden. Hoe komt het leidende getal bij elk systeem dat alleen leest, en hoe vaak controleer je of het is aangekomen? Je kiest tussen event-driven en gepland. Voor een telling die je wilt kunnen vertrouwen, is dat eigenlijk geen keuze.

Bij event-driven verspreiding stuurt elke wijziging in het leidende systeem direct een update naar buiten. De lezende systemen blijven dan vrijwel live, en dat is de juiste standaard. Bij geplande batches kopieert een job de getallen op vaste tijden. Tussen twee runs werkt elk systeem dan met verouderde data, dus bewaar dat voor data die echt niet snel verandert. Maar event-driven alleen is niet genoeg, en dat onderschatten de meeste projecten. Een bericht kan vertraging oplopen, verloren gaan of worden afgeknepen. De architectuur heeft dus ook een geplande reconciliatie nodig: een periodieke controle die het getal van de eigenaar naast dat van elke lezer legt en elke afwijking markeert. Events houden de stack actueel. Reconciliatie houdt hem eerlijk. Je hebt ze allebei nodig, en vastleggen hoe vaak je reconcilieert is een bouweis, geen extraatje.

De eerste plek waar het vastloopt: voorraadbewegingen die de sync nooit ziet

Het eerste struikelpunt komt zodra het ideale scenario botst op retouren, reserveringen en meerdere locaties. Een opzet die alleen afgeronde verkopen synchroniseert, negeert stilletjes elke andere manier waarop voorraad beweegt. Hier begint een architectuur die af leek te lekken, en dat is voorspelbaar genoeg om er vanaf het begin op te ontwerpen.

Retouren zijn het duidelijkste voorbeeld. Een geretourneerd product is er fysiek weer, maar is pas verkoopbaar als het is gekeurd en in het leidende systeem terug is gezet naar een verkoopbare status. De architectuur moet die route dus vastleggen, in plaats van aan te nemen dat een retour de voorraad vanzelf herstelt. Reserveringen en conceptbestellingen zijn het spiegelbeeld: voorraad die voor een klant is vastgehouden, is vergeven zonder verkocht te zijn. Het leidende systeem moet die als toegezegd behandelen, zodat het verkoopbare getal daalt. Meerdere locaties maken van “hoeveel” de vraag “hoeveel, en waar”. Een bestelling wordt namelijk toegezegd op een specifieke locatie, niet op één pot voor het hele bedrijf, en de architectuur moet bepalen welke locaties meetellen voor de online beschikbaarheid. Een opzet die de nette verkoop afhandelt en deze drie overslaat, heeft straks geen voorraadprobleem. Hij heeft nu een onaf ontwerp. De retourroute, de reserveringsstatussen en de locatieregels uitwerken: dat is het verschil tussen een demo en een systeem.

De tweede plek waar het vastloopt: governance en afwijkingen opsporen

Het tweede struikelpunt is governance: bepalen wie het leidende getal mag wijzigen en hoe je afwijkingen opvangt. Zonder die afspraken brokkelt je source of truth af, handmatige aanpassing na handmatige aanpassing. Een opzet kan correct live gaan en in de maanden daarna toch achteruitgaan. Medewerkers doen met de beste bedoelingen directe correcties in systemen die alleen hadden mogen lezen, en elke correctie opent opnieuw het gat dat de architectuur had gedicht.

Twee eisen houden dit overeind. Ten eerste mag alleen het leidende systeem het leidende getal wijzigen, via de routes die daarvoor zijn vastgelegd. Zo kan een lezer niet ongemerkt een tweede schrijver worden. Ten tweede is de reconciliatie uit stap drie zo ingericht dat ze een mens waarschuwt zodra ze een afwijking vindt. Dan ziet iemand het verschil op een dashboard, in plaats van dat een klant iets koopt wat er niet meer is. Governance is de eis die je het makkelijkst overslaat, omdat er niets kapotgaat op de dag dat je hem overslaat. Het gaat langzaam kapot, en dat is erger: tegen de tijd dat de telling weer onbetrouwbaar is, weet niemand meer met welke aanpassing het begon. Een architectuur zonder governance is geen lichtere versie van een unified architectuur. Het is een unified architectuur met een houdbaarheidsdatum.

Ontwerp ook voor wat later misgaat

Naast de twee struikelpunten houdt een opzet die lang meegaat rekening met de manieren waarop hij later breekt. Een sync-token verloopt en bestellingen komen niet meer door. Er crasht niets zichtbaar, alleen het gat in je data groeit. De architectuur heeft dus meldingen nodig op authenticatie en op de gezondheid van de sync, niet alleen op de data zelf. Een actie op één kanaal laat de voorraadallocatie bewust afwijken, dus de regels moeten een bedoeld verschil kunnen onderscheiden van een onbedoelde afwijking. En in jaar twee komt er een nieuw systeem bij. Dat is eenvoudig als het aansluit op de eigenaar en het gepubliceerde getal leest, en duur als het point-to-point wordt gekoppeld aan alles wat al draait.

Dat laatste is waarom het eigenaarsmodel verder reikt dan kloppende voorraad. Een goed opgezette unified architectuur maakt de volgende integratie goedkoop, omdat er een vast middelpunt is om op aan te sluiten. Flatline heeft precies zo’n middelpunt gebouwd in projecten als het samenbrengen van Shopify Plus, POS, ERP en WMS bij OGÉR, en de middleware die de webshops van North Actionsports verbindt met ERP en fulfilment. De waarde zat daar minder in een losse connector dan in de gezamenlijke structuur waar de systemen zich naar richten.

Check: ben je klaar om dit te bouwen?

Je bent klaar om te bouwen als je vier vragen kunt beantwoorden. Welk systeem is eigenaar van de voorraad? Met welke formule bereken je de verkoopbare beschikbaarheid? Hoe verspreidt het getal zich, en hoe vaak reconcilieer je het? En wie mag het wijzigen? Hebben die vier een helder antwoord, dan is de bouw vooral uitvoering. Luidt een van de antwoorden nog “beide systemen houden het synchroon”, dan is dat het gat dat je dicht voordat er ook maar één connector wordt begroot. Elk later probleem is terug te voeren op dat gat.

De meeste teams kunnen een of twee van de vier vragen met zekerheid beantwoorden en worden stil bij de rest. Dat is een normaal vertrekpunt, geen tekortkoming. De vier vragen zijn de eigenlijke specificatie van een unified-commerce-architectuur, meer dan welke onderdelenlijst ook, omdat ze vastleggen welk gedrag de onderdelen moeten opleveren.

Zet je de opties voor je source of truth op een rij? Neem dan eerst deze beslissing, voordat je connectors koopt. Flatline is Shopify Platinum Partner met een lange staat van dienst in integraties en middleware, van maatwerkconnectors en ERP-integraties tot complete unified-commerce-trajecten. Wil je iemand laten meekijken naar waar de source of truth van je voorraad hoort te liggen? We bespreken je architectuur graag vrijblijvend in een verkennend gesprek. Neem contact op, dan lopen we de vier vragen samen met je door.

Veelgestelde vragen

Wat is een unified-commerce-architectuur?

Een unified-commerce-architectuur is een systeemontwerp waarin voor elk type data één leidend record bestaat. Elk verkoopkanaal en elk backendsysteem leest daaruit en schrijft daarnaar, in plaats van een eigen kopie bij te houden. Het kenmerk is één source of truth per domein, zodat voorraad, bestellingen en klantgegevens online en in de winkel realtime overeenkomen.

Wat heb je nodig voor een unified-commerce-architectuur?

Vier dingen: één leidend systeem per datadomein, een vaste formule voor verkoopbare beschikbaarheid die op één plek wordt berekend, event-driven verspreiding gecombineerd met geplande reconciliatie, en governance die beperkt wie het leidende getal mag wijzigen. De tools zelf doen er minder toe dan deze beslissingen, omdat de beslissingen bepalen welk gedrag de tools moeten opleveren.

Heb je één platform nodig voor unified commerce, of kun je systemen koppelen?

Eén native platform is niet nodig. Unified commerce draait om één source of truth per domein. Dat bereik je op een native platform, maar ook door best-of-breed-systemen te koppelen rond een centraal leidend record of een integratielaag. De eis is dat elk systeem één leidend getal volgt, niet dat alles in één product zit.

Waar hoort de source of truth voor voorraad te liggen?

In het systeem dat het dichtst zit op de plek waar voorraad fysiek verandert, met de verkoopbare beschikbaarheid één laag hoger berekend. Zijn fysieke tellingen het nauwkeurigst in het ERP of het warehousesysteem, dan is dat systeem eigenaar van de fysieke voorraad en leest de webshop een afgeleid getal. Is de allocatielogica het verst uitgewerkt in een order management system, dan kan dat systeem de beschikbaarheid beheren. De regel weegt zwaarder dan het specifieke systeem.

Waar lopen de meeste unified-commerce-projecten vast?

Op twee punten. Eerst bij retouren, reserveringen en voorraad op meerdere locaties: die verplaatsen voorraad op manieren die een sync op alleen afgeronde verkopen nooit ziet. Daarna bij governance, als geen regel beperkt wie het leidende getal mag wijzigen en de source of truth langzaam afbrokkelt door goedbedoelde handmatige aanpassingen. Op allebei ontwerp je vooraf, in plaats van ze achteraf te ontdekken.

De belangrijkste punten

• Een unified-commerce-architectuur is een bouwvolgorde, geen checklist met producten. De kern is per datadomein bepalen welk systeem ernaast mag zitten.

• Wijs per domein één leidend systeem aan en schrijf de regel op. “Beide systemen houden het synchroon” is het ontbreken van een regel, en daar beginnen de afwijkingen.

• Verkoopbare beschikbaarheid is een formule, geen ruwe telling. Eén systeem rekent haar uit en publiceert het ene getal waar elk kanaal op verkoopt.

• Verspreiding heeft twee helften nodig: event-driven updates om actueel te blijven, en geplande reconciliatie om eerlijk te blijven.

• Projecten lopen op twee voorspelbare plekken vast: de voorraadbewegingen die een sync nooit ziet (retouren, reserveringen, locaties) en het ontbreken van governance over wie het leidende getal mag wijzigen. Ontwerp vanaf het begin voor allebei.

Een unified-commerce-architectuur verdient de term “één source of truth” pas als de hele stack afspreekt één getal te volgen dat iedereen kan lezen. Dat is eerst een besluit en dan pas een bouwproject, en dat besluit goed nemen maakt de bouw de investering waard. Kun je de vier vragen beantwoorden, dan ben je al een heel eind. Lukt dat nog niet, dan is dat precies het gesprek om te voeren voordat je de eerste connector koopt.