Online nog op voorraad, in de winkel gisteren uitverkocht: waarom je voorraad tussen systemen nooit klopt

De website toont nog drie stuks. In de winkel ging gistermiddag het laatste exemplaar over de toonbank. De magazijnexport van vanochtend zegt twee. De financiële afdeling kijkt in de boekhouding naar een vierde getal, en niemand aan tafel kan zeggen welk getal klopt. De meeste teams zien dit als een invoerprobleem en nemen iemand extra aan om de cijfers bij te houden. Maar voorraad die tussen systemen niet synchroon loopt, is zelden een invoerprobleem. Het gebeurt omdat elk systeem zijn eigen kopie van de telling bijhoudt en geen van die systemen ooit is aangewezen als het systeem dat beslist. Sneller synchroniseren verandert hoe snel de kopieën uit elkaar lopen. Het verandert niets aan het feit dát ze uit elkaar lopen.

Om dat onderscheid draait dit hele artikel. Zie je voorraad eenmaal als een getal dat meerdere systemen elk op hun eigen manier berekenen, dan lijkt het dagelijkse verschil niet langer op slordigheid. Dan zie je dat de architectuur precies oplevert waarvoor ze gebouwd is. Hieronder lopen we het mechanisme van begin tot eind door, ook op de plekken waar de gebruikelijke oplossingen ongemerkt ophouden te werken. Zo kun je inschatten welke oplossing in jouw situatie standhoudt en welke alleen de klok terugzet tot je opnieuw iets verkoopt wat je niet hebt.

Wat “niet synchroon” eigenlijk betekent

Voorraad die tussen systemen niet synchroon loopt, betekent dat twee of meer platforms op hetzelfde moment een ander aantal voor hetzelfde product tonen. Elk platform houdt een eigen administratie bij en werkt die bij op zijn eigen moment. Het verschil is geen storing in één tool. Het is het voorspelbare gevolg van meerdere tools die elk hun eigen kopie van het getal als juist beschouwen, zonder één administratie waar ze allemaal naar luisteren.

Het woord “beschikbaar” verbergt het grootste deel van het probleem. In de praktijk is een verkoopbaar aantal bijna nooit een kale fysieke telling. In Shopify is de aanwezige voorraad bijvoorbeeld het fysieke totaal, en beschikbaar is wat overblijft nadat toegezegde en niet-beschikbare eenheden zijn afgetrokken. Beschikbaar is een berekend getal, geen feit dat je van een schap afleest. Zet nu vier systemen naast elkaar. Elk berekent zijn eigen versie van “beschikbaar”, vanuit zijn eigen beeld van wat toegezegd, gereserveerd, beschadigd of onderweg is. Ze konden nooit op hetzelfde getal uitkomen, want ze meten niet hetzelfde. Elk systeem rekent met een net iets andere formule op net iets andere invoer.

Een single source of truth, of leidend systeem, is het ene systeem dat voor een bepaald gegeven de doorslaggevende waarde bewaart. Alle andere systemen lezen daaruit en houden geen eigen, concurrerende kopie bij. Als mensen zeggen dat een bedrijf “geen leidend systeem voor voorraad” heeft, bedoelen ze precies dit: meerdere systemen geloven elk hun eigen getal, en het bedrijf heeft nooit besloten welk getal wint. Onthoud die definitie. Elke oorzaak hieronder komt erop terug.

Oorzaak één: elk systeem houdt zijn eigen telling bij

Begin bij de plek waar de getallen echt staan. Een groeiend merk draait meestal een webshop, een kassasysteem, een magazijn- of 3PL-systeem en een boekhoud- of ERP-pakket. Elk van die systemen registreert voorraad, omdat elk systeem voorraad nodig heeft voor zijn eigen werk. De webshop moet weten wat hij kan verkopen. Het magazijn moet kunnen picken en inpakken. De financiële afdeling moet de voorraad kunnen waarderen. Geen van die systemen is gebouwd om eerst een ander systeem om toestemming te vragen.

Eén verkoop raakt dus meerdere administraties die los van elkaar worden bijgewerkt. Een klant koopt online. De webshop zet die eenheid van beschikbaar naar toegezegd en verlaagt het verkoopbare aantal. Het magazijnsysteem weet dat pas als een synchronisatie of een scan het doorgeeft. De boekhouding weet het pas als er een orderexport draait, vaak 's nachts. Minuten of zelfs uren lang hebben drie systemen drie verdedigbare getallen, en binnen hun eigen systeem kloppen ze alle drie. Het verschil is geen fout. Het is vertraging tussen administraties die bewust los van elkaar zijn opgezet.

Verkoop je via meerdere kanalen, dan wordt het nog duidelijker. Verkoop je tegelijk via je webshop en een marketplace, dan putten beide uit dezelfde fysieke voorraad terwijl elk kanaal zijn eigen telling bijhoudt. Bij normaal verkeer is het gat zo klein dat je het kunt negeren. Tijdens een actie of een lancering komen orders sneller binnen dan welk synchronisatie-interval ook, en blijven beide kanalen verkopen op een getal dat al op is. Dat is klassieke overselling, en het loont om de oorzaak precies te benoemen. De kanalen hadden wel degelijk contact met elkaar. Ze spraken alleen met vertraging, en de vraag was sneller dan die vertraging.

Het aangrijpingspunt is hier niet “vaker synchroniseren”. Het is bepalen welk systeem het echte getal mag bewaren, zodat de andere systemen ophouden hun eigen getal door te drukken. Daar komen we op terug. Eerst moeten er nog twee oorzaken op tafel, want wie alleen deze oplost, blijft kwetsbaar.

Oorzaak twee: “synchroon” betekent alleen “gelijk bij de laatste sync”

De meeste koppelingen zetten voorraad volgens een vast schema over. Elk kwartier, elk uur of elke nacht draait een job die de laatste aantallen tussen systemen kopieert. Tussen twee runs zijn de systemen niet synchroon. Ze houden vast wat ze bij de vorige run hebben afgesproken, terwijl de werkelijkheid al verder is. “Synchroon” is een momentopname, geen live toestand. Zo lang als het gat duurt, zo lang loop je risico.

Het gebruikelijke antwoord is het interval verkorten of overstappen op event-driven updates, waarbij een wijziging in het ene systeem direct een bericht naar de andere stuurt. Shopify ondersteunt dat met webhooks die een update versturen zodra de voorraad of een order verandert. Dat is echt beter dan op een timer blijven pollen. De stap van batch naar event-driven verkleint het venster waarin systemen het oneens zijn, en voor veel merken verdwijnt daarmee de alledaagse versie van het probleem. Het is de goede richting.

Het is ook het punt waar de oplossing ongemerkt ophoudt volledig te zijn, en precies dit deel slaan kortere handleidingen over. Ook event-driven sync heeft een venster, alleen een klein. Een bericht kan vertraging oplopen door een API-rate limit, wegvallen door een time-out of vastzitten in een retry-wachtrij, juist tijdens de piek waarin een kloppend getal het meest telt. Twee systemen kunnen dezelfde eenheid afboeken in de paar seconden voordat het bericht aankomt. Ook de manier waarop het misgaat, verandert. Bij batch-sync verwacht je vertraging en plan je daaromheen. Bij event-driven sync ga je ervan uit dat alles live klopt, en word je overvallen als een bericht stilletjes wegvalt en één kanaal voorraad blijft verkopen die al weg is. Sneller is beter. Maar sneller is niet hetzelfde als leidend. Een snellere kopie blijft een kopie, en twee kopieën kunnen allebei ja zeggen.

Oorzaak drie: de voorraad verandert op plekken waar de sync nooit kijkt

Zelfs een snelle, betrouwbare koppeling synchroniseert alleen de events waar hij naar kijkt. Voorraad verandert ook op manieren die buiten het nette pad van “één verkocht, één eraf” vallen. Elk daarvan opent een gat dat geen interval dichtkrijgt, omdat niemand de sync ooit heeft verteld daar te kijken.

Retouren zijn het duidelijkste voorbeeld. Een klant stuurt een artikel terug. Fysiek is het er weer, maar verkoopbaar wordt het pas als iemand het controleert, besluit dat het opnieuw verkocht kan worden en het in het juiste systeem de juiste status geeft. Tot die tijd telt het ene systeem het als aanwezig, terwijl een ander het nog als weg beschouwt. Het artikel bestaat echt. De systemen zijn het oneens over de vraag of het verkocht kan worden, en allebei hebben ze er iets voor te zeggen.

Reserveringen en conceptorders veroorzaken dezelfde splitsing, alleen vanaf de andere kant. Legt een medewerker voorraad apart voor een klant, zet een pre-order-app eenheden opzij of wordt er een conceptorder aangemaakt, dan is die voorraad vergeven zonder dat hij verkocht is. In Shopify krijgen deze eenheden de status toegezegd of niet beschikbaar. Het verkoopbare aantal daalt dus, terwijl er niets is verzonden. Een systeem dat alleen naar afgeronde orders kijkt, ziet die reservering nooit en blijft voorraad aanbieden die al beloofd is.

Dan is er nog de locatie. Zodra je voorraad op meer dan één plek ligt, wordt de vraag “hoeveel hebben we” de vraag “hoeveel, en waar”. Een order wordt toegezegd aan een specifieke fulfilmentlocatie, niet aan de totale voorraad van het bedrijf. Een eenheid kan dus fysiek in het pand liggen en toch niet verkoopbaar zijn voor een bepaald kanaal, omdat hij aan een andere locatie is toegewezen. Tel daar deelleveringen, transfers die onderweg zijn en voorraad die door schade of kwaliteitscontrole op niet beschikbaar staat bij op. Dan heb je een reeks volkomen legitieme bewegingen die een simpele sync platslaat tot één getal dat hij onmogelijk eerlijk kan houden. Op deze laag stapelen voorraadverschillen tussen kanalen zich ongemerkt op, en daarom lost een hertelling het vandaag op en morgen niet meer.

Het echte knelpunt: geen enkel systeem is ooit leidend gemaakt

Leg de drie oorzaken naast elkaar en het echte knelpunt wordt zichtbaar. Het is niet de snelheid van de sync. Het is dat meerdere systemen elk een getal bewaren dat als doorslaggevend geldt, en geen van hen boven de andere staat. Er is geen leidend systeem. Als twee administraties het oneens zijn, beslist niets in de architectuur wie gelijk heeft. Dus beslist het bedrijf, met de hand, keer op keer, meestal nadat een klant het gat al heeft gevonden.

Daarom voelt voorraad hertellen productief, terwijl het niets verandert. Na een hertelling zijn alle systemen het even eens. Dan trekken de volgende retour, de volgende reservering en de volgende order die tijdens een sync-vertraging binnenkomt ze weer uit elkaar, omdat de oorzaak van dat uit elkaar lopen er nog steeds is. Je hebt het symptoom verholpen en de oorzaak laten staan. De klok begint opnieuw. Het probleem was nooit dat de getallen fout waren. Het probleem was dat het bedrijf geen regel had voor welk getal wint, dus bleven ze allemaal meedoen.

Een leidend systeem aanwijzen is een beslissing over architectuur, geen aankoop van software. En het is een beslissing die de meeste stacks nooit echt hebben genomen. Koop je een sync-app zonder die beslissing, dan los je het conflict niet op. Je automatiseert het. Je hebt dan een sneller mechanisme om het getal te verspreiden dat toevallig als laatste is bijgewerkt, en dat is iets anders dan het getal dat klopt.

Waar ingrijpen echt verschil maakt

De stap met de meeste impact is precies de stap die de hertelling en de snellere sync allebei overslaan: bepaal welk systeem eigenaar is van het doorslaggevende voorraadgetal, en laat elk ander systeem daaruit lezen in plaats van een concurrerende kopie bij te houden. Dat is wat “single source of truth” in de praktijk betekent. Het is eerst een afspraak over eigenaarschap en pas daarna een technische kwestie.

Een paar principes zorgen dat het in de dagelijkse praktijk standhoudt. Wijs eigenaarschap per datadomein toe, niet één keer voor alles. Het ene systeem is eigenaar van de fysiek aanwezige voorraad, een ander van wat per kanaal verkoopbaar is, en de grens daartussen is uitgesproken in plaats van aangenomen. Laat alleen de eigenaar van een getal dat getal wijzigen, en laat de rest zich erop abonneren. Werk bij op basis van events in plaats van een timer, zodat de alleen-lezen-kopieën dicht bij de werkelijkheid blijven. En accepteer dat een afstemmingsproces bij het ontwerp hoort en geen teken is dat het mislukt is. Een geplande controle die systemen vergelijkt, afwijkingen markeert en ze zichtbaar maakt voordat een klant ze vindt: zo blijft een goed ingerichte stack eerlijk tussen de events door.

Dit is het werk achter de term “unified commerce”, en het loont om dat concreet te zien in plaats van als slogan. Toen Flatline bij North Actionsports het losse PIM, het ERP en meerdere webshops koppelde tot één samenhangende flow, zat de winst niet in data die sneller tussen de systemen bewoog. De winst was dat de systemen ophielden elk een eigen versie van de waarheid te bewaren en zich gingen voegen naar een vastgelegde rangorde. Dat maakt een eind aan het dagelijkse verschil: niet sneller kopiëren, maar besluiten welk getal telt.

De eerste praktische stap kost niets en maakt veel duidelijk. Breng je huidige stack in kaart en schrijf per systeem op welk voorraadgetal het bewaart en waar dat getal vandaan komt. De meeste teams ontdekken binnen een uur dat drie of vier systemen allemaal denken dat zij eigenaar zijn van “beschikbaar”, en dat geen van die systemen ooit is gezegd zich naar een ander te voegen. Dat overzicht is de echte diagnose. Zie je eenmaal welke systemen gezag claimen dat ze nooit hebben gekregen, dan is de keuze welk systeem leidend wordt niet langer abstract. Dan ligt ze voor de hand.

Veelgestelde vragen

Waarom staat mijn voorraad online op beschikbaar terwijl het product in de winkel uitverkocht is?

De webshop en het kassasysteem houden elk een eigen telling bij en werken die met vertraging bij. Wordt er in de winkel een stuk verkocht, dan weet de webshop dat pas als er een sync draait of een scan het doorgeeft. In dat gat toont de website een getal dat klopte bij de laatste sync en inmiddels verouderd is. De oorzaak: beide systemen houden hun eigen telling bij, zonder gedeelde administratie waar ze allebei naar luisteren.

Voorkomt realtime synchronisatie overselling helemaal?

Het vermindert overselling flink, maar haalt het niet weg. Event-driven sync verkleint het venster waarin systemen het oneens zijn tot seconden. Toch kan een bericht nog steeds vertraging oplopen door een rate limit, wegvallen door een time-out of blijven hangen in een retry-wachtrij tijdens een piek in het verkeer. Binnen dat venster kunnen twee systemen dezelfde eenheid afboeken. Realtime is een snellere kopie, geen leidende administratie.

Wat is een single source of truth voor voorraad?

Het is het ene systeem dat is aangewezen om het doorslaggevende voorraadgetal te bewaren, zodat elk ander systeem daaruit leest in plaats van een eigen versie bij te houden. Het is een afspraak over welke administratie wint als twee het oneens zijn, geen specifiek product. Zonder die afspraak beschouwen meerdere systemen elk hun eigen telling als juist, en lost het bedrijf het conflict met de hand op.

Lost een ERP voorraadverschillen vanzelf op?

Een ERP kan het leidende systeem zijn, omdat het gebouwd is om operationele data centraal te beheren. Maar het lost verschillen alleen op als je het inricht als het systeem waar de andere zich naar voegen. Zet je een ERP zonder die beslissing in je stack, dan wordt het gewoon nog een systeem met een eigen getal. De oplossing zit in de keuze voor eigenaarschap, en het ERP is één plek waar die keuze kan landen.

Waarom zorgen retouren steeds voor voorraadverschillen?

Een geretourneerd artikel bestaat fysiek weer, maar is pas verkoopbaar als het gecontroleerd is en in het juiste systeem de juiste status heeft gekregen. Tot dat moment telt het ene systeem het wel en het andere niet, en allebei zijn ze te verdedigen. Retouren veranderen de voorraad buiten het gewone pad van één verkocht, één eraf. Een sync die alleen naar afgeronde orders kijkt, ziet die wijziging dus nooit.

De kern op een rij

• Voorraad die tussen systemen niet synchroon loopt, is een kwestie van gezag, niet van snelheid. Meerdere systemen houden elk hun eigen telling bij, en geen daarvan is aangewezen als het systeem dat beslist.

• “Beschikbaar” is een berekend getal, geen fysiek feit. Elk systeem berekent het vanuit zijn eigen beeld van toegezegde, gereserveerde en niet-beschikbare voorraad. Uit zichzelf gingen ze dus nooit overeenkomen.

• Snellere en event-driven sync verkleinen het gat, maar dichten het nooit. Een snellere kopie blijft een kopie, en twee kopieën kunnen nog steeds allebei dezelfde eenheid verkopen.

• Retouren, reserveringen, voorraad op meerdere locaties en voorraad onderweg veranderen de telling op manieren die een simpele sync nooit ziet. Daarom lost een hertelling het vandaag op en morgen niet meer.

• Het verschil maak je door per datadomein één leidend systeem aan te wijzen en elk ander systeem daaruit te laten lezen. Breng eerst in kaart welk systeem nu eigenaar is van welk getal. Zodra je het opschrijft, zijn de conflicten meestal meteen zichtbaar.

Zo bekeken is het verschil op je scherm geen teken dat iemand slordig telt. Het is een teken dat de architectuur nooit heeft besloten wiens telling je gelooft. Dat probleem is op te lossen. Het begint niet met een nieuwe tool, maar met een beslissing waarop je systemen al die tijd hebben gewacht.