Zo ziet een voorraadsynchronisatieproject er in de praktijk uit

De meeste voorraadprojecten beginnen niet bij techniek. Ze beginnen bij een mailtje van de klantenservice: artikel verkocht, magazijn heeft niets meer liggen. Of bij een verkoper die voor de derde keer die week een voorraadaantal handmatig corrigeert omdat het ERP achterloopt. Dat kost tijd, het levert vervelende gesprekken op met klanten en het maakt groeien riskanter dan nodig is.

Voorraadsynchronisatie is dan ook geen koppeling die u een keer installeert en daarna vergeet. Het is een afspraak tussen systemen: webshop, ERP, WMS, kassa, marketplaces en leveranciersfeeds moeten het eens zijn over wat er nog verkocht kan worden. Het lastige zit zelden in het uitwisselen van getallen. Het zit in de vraag welk systeem gelijk heeft, wanneer een mutatie meetelt en wat er gebeurt als een van de partijen even niet reageert.

Het uitgangspunt van dit project

Neem een groothandel met zo'n 8.000 artikelen, die verkoopt via een B2B-webshop, een binnendienst met telefonische orders en twee marketplaces. De administratieve voorraad staat in het ERP. Het magazijn draait op een WMS met scanners. De webshop heeft een eigen catalogus met een eigen voorraadveld. Tot nu toe werd dat veld ieder uur bijgewerkt met een exportbestand uit het ERP.

Een uur klinkt kort genoeg, tot de ordervolumes stijgen. Een klant koopt om 10:05 het laatste exemplaar in de webshop, terwijl de marketplace tot 11:00 nog vijf stuks blijft tonen. Een verkoper legt telefonisch drie stuks vast, maar die reservering zit pas in de volgende export. Het resultaat is bekend: overselling, creditnota's, nabellen en correcties die niemand had ingepland.

Het doel van zo'n project is niet dat elk systeem precies dezelfde getallen bijhoudt. Het ERP telt nu eenmaal anders dan het WMS, en dat mag ook. Het doel is dat ieder verkoopkanaal op het moment van verkopen dezelfde verkoopbare voorraad hanteert. Fysieke voorraad, gereserveerde voorraad, afgekeurde voorraad en verwachte inkomende voorraad zijn verschillende getallen met een verschillende functie. Alleen dat onderscheid scherp krijgen scheelt al de helft van de discussies.

Eerst bepalen wie gelijk heeft

In dit voorbeeld is het ERP eigenaar van de artikelgegevens en van de verkoopbare voorraad die naar buiten gaat. Het WMS is leidend voor alles wat fysiek in het magazijn gebeurt: inslag, pickbevestigingen, tellingen en correcties. Die mutaties stromen naar het ERP, dat ze verwerkt en er de verkoopbare voorraad uit berekent. Webshop en marketplaces zijn puur ontvanger van dat cijfer. Orders lopen de andere kant op, van kanaal naar ERP, zodat een reservering direct effect heeft.

Zonder die verdeling krijgt u systemen die elkaar de hele dag overschrijven. Een webshop die na een mislukte betaling zelf de voorraad terugzet, stuurt een getal terug dat het ERP niet kent, waarna de volgende synchronisatie het weer omdraait. Een koppeling moet dus niet alleen weten welke gegevens hij mag lezen, maar vooral welke hij mag wijzigen.

In de praktijk leggen we minimaal dit vast:

Het ERP beheert artikelen, locaties, administratieve voorraad en de berekening van de verkoopbare voorraad.
Het WMS meldt fysieke bewegingen en pickstatussen, en is daarin leidend.
De webshop toont de ontvangen verkoopbare voorraad en meldt orders direct terug.
Marketplaces ontvangen alleen de voorraad die daar verkocht mag worden.
De integratielaag verzorgt vertaling, controles, wachtrijen en foutafhandeling.

Die integratielaag is geen extra schakel voor de vorm. Hij voorkomt dat elk platform rechtstreeks met elk ander platform praat. Met vijf systemen zijn dat al tien mogelijke verbindingen, en bij een storing mag u raden welke het was. Via een centrale laag is een wijziging overzichtelijk en een fout snel te herleiden.

Van mutatie naar zichtbare voorraad

Synchroniseren werkt het beste op gebeurtenissen in plaats van op de klok. Is een order betaald of bevestigd, dan zakt de verkoopbare voorraad. Heeft het magazijn een retour goedgekeurd, dan komt het artikel weer beschikbaar. Wachten op de volgende geplande export is voor organisaties met meerdere verkoopkanalen niet meer houdbaar.

Een webshoporder loopt in dit voorbeeld zo. De klant rekent af en de webshop stuurt de order meteen naar de integratielaag. Die controleert artikelnummer, locatie, orderstatus en beschikbare voorraad. Klopt alles, dan gaat er een reservering het ERP in. Het ERP herberekent de verkoopbare voorraad en dat nieuwe getal gaat terug naar de webshop en naar de marketplaces waar het artikel staat. Bij het picken bevestigt het WMS de fysieke afname, waarna de reservering vervalt.

Simpel op papier. De details bepalen of het ook op een drukke maandag klopt. Een klant die in twee tabbladen tegelijk bestelt. Een betaling die na tien minuten alsnog mislukt. Een deellevering. Een order die iemand handmatig aanpast in het ERP. Daarom krijgt elke mutatie een uniek ID mee. Komt hetzelfde bericht twee keer binnen, bijvoorbeeld na een time-out en een nieuwe poging, dan daalt de voorraad niet twee keer.

Ook de rekenregel moet vooraf vaststaan en op een plek thuishoren. Meestal is dat: fysieke voorraad min harde reserveringen min veiligheidsvoorraad. Voor sommige artikelen komt daar een kanaalallocatie bij. Verkoopt u schaars materiaal via drie kanalen, dan wilt u niet dat iedere marketplace de volledige voorraad claimt.

Niet elk artikel volgt dezelfde regel

Een standaardartikel op een vaste locatie is geen probleem. De uitzonderingen maken het werk. Bundels bestaan uit losse componenten. Varianten delen soms een basisvoorraad. Pre-orders mogen verkocht worden, maar niet als direct leverbaar in beeld komen. Dropship-artikelen leunen op een leveranciersfeed die minder vaak en minder betrouwbaar binnenkomt.

Neem een cadeaupakket met een fles, een glas en een verpakking. De webshop verkoopt een artikel, het magazijn kent er drie. De beschikbare pakketvoorraad is dan geen eigen teller, maar het minimum van de componenten. Die berekening moet ergens thuishoren: of het ERP levert hem, of de integratielaag maakt hem. Op twee plekken tegelijk is vragen om verschillen.

Er is hier geen standaardantwoord. Bij een klein assortiment en rustige volumes is een periodieke synchronisatie prima. Bij veel orders, meerdere kanalen of krappe voorraad wordt realtime of bijna realtime al snel de verstandigere keuze. Kijk vooral naar wat een fout kost. Een overselling die eindigt in een excuusmail is iets anders dan een zakelijke order waar een installatieafspraak of een productieslot aan hangt.

Fouten horen erbij, stil falen niet

Een API is soms even onbereikbaar. Een token verloopt op vrijdagmiddag. Een artikelnummer bestaat in de webshop maar niet in het ERP, omdat iemand het daar met een streepje heeft aangemaakt. Dat zijn geen rampen, dat is gewoon de operatie. De koppeling moet er alleen op voorbereid zijn.

Mislukte berichten gooien we daarom niet weg. Ze gaan in een wachtrij en worden opnieuw geprobeerd volgens vaste regels, met oplopende tussenpozen. Lukt het na een paar pogingen nog niet, dan krijgt een beheerder of een medewerker een melding met ordernummer, artikelnummer, de foutmelding en wat er moet gebeuren. "Foutcode 500" is geen melding waar de operatie iets mee kan.

Daarnaast draait er elke nacht een reconciliatie. Die legt de verkoopbare voorraad uit het ERP naast wat de webshop en de marketplaces tonen. Kleine afwijkingen worden automatisch rechtgezet. Grote of terugkerende verschillen gaan naar een mens, want die wijzen bijna altijd op iets structureels: een orderstatus die niet wordt teruggemeld, een verkeerde mapping, of een handmatige stap die buiten de koppeling om gaat.

Testen met de echte uitzonderingen

Een voorraadkoppeling test u niet door een artikel van tien naar negen te zetten. Test twee orders op hetzelfde laatste stuk, een annulering na verzending, een retour die deels wordt afgekeurd, een deelzending, een voorraadcorrectie tijdens het picken, een bundel en een systeem dat er tien minuten uit ligt. Zet daar mensen uit verkoop, magazijn en klantenservice bij. Zij noemen binnen een kwartier de gevallen die in geen enkel procesplaatje staan.

Ga daarna gefaseerd live. Begin met een productgroep of een kanaal, kijk een week naar de mutaties, meet de verwerkingstijd en lees vooral de foutmeldingen. Draait het stabiel, dan pas uitbreiden. Zo merkt u op tijd dat een technisch correcte koppeling toch botst met de manier waarop uw team in de praktijk werkt.

Voor het dagelijkse beheer helpt een compact dashboard: de laatste geslaagde synchronisatie per kanaal, de lengte van de wachtrij, openstaande fouten, geconstateerde voorraadverschillen en de status van de aangesloten systemen. U hoeft niet elk bericht te volgen. U wilt alleen weten wanneer een storing geld gaat kosten.

Wat het uiteindelijk oplevert

Als de voorraad klopt op het moment dat het uitmaakt, daalt het aantal oversellingen. Maar de winst zit niet alleen daar. De klantenservice lost minder uitzonderingen op, het magazijn krijgt opdrachten die kloppen en uw kanalen tonen informatie waar klanten op durven te vertrouwen. Handmatig corrigeren wordt weer de uitzondering in plaats van een vast onderdeel van de dag.

De techniek hoort zich daarbij te voegen naar uw processen, niet andersom. LJPc bouwt koppelingen en interne tools vanuit die praktijk: duidelijk eigenaarschap, korte lijnen en een oplossing die ook een half jaar na livegang nog te beheren is.

Begin dus niet bij de vraag welke API u wilt koppelen. Begin bij een order en volg die helemaal: wat gebeurt er met de voorraad vanaf het moment dat de klant op bestellen klikt tot het moment dat het magazijn levert, annuleert of terugneemt? Wie dat verhaal scherp heeft, houdt aan de techniek een stuk minder werk over.