Core
De commerce-stack uitgelegd: ERP, PIM, OMS, WMS en wie wat beheert
Stephan Spijkers · 2026-10-18 · 15 min leestijd
Een webshop, een app, een B2B-portaal, een listing op een marktplaats en de kassa in een winkel moeten allemaal hetzelfde product, dezelfde prijs en dezelfde voorraad tonen. Daarachter zit een set systemen die elk een deel van het werk doen: een ERP voor de boeken, een PIM voor de productcontent, een OMS voor de orders, en nog een paar meer. Deze gids brengt die commerce-stack in kaart. Hij laat zien welk systeem eigenaar is van welke data, hoe de data tussen de systemen beweegt en waar de grenzen tussen de systemen horen te liggen. Begin met de interactieve kaart en lees daarna verder voor de details.
De commerce-stack op één kaart
Interactieve kaart
Verken de commerce-stack
Kies een systeem en zie waar het eigenaar van is, wat het ontvangt en verstuurt, en wat niet zijn taak is.
Productcontent
Verkopen
Leveren
Fundament
Product information management
PIM
Maakt van een artikelnummer een product dat verkoopt: beschrijvingen, specificaties, taxonomie, vertalingen, relaties zoals varianten en accessoires, en een volledigheidscheck voordat iets live gaat.
Systeem van registratie voor
- Marketingteksten en specificaties
- Categorieën en zoekattributen
- Vertalingen en kanaalversies
- Productrelaties en volledigheid
Ontvangt
- Artikelidentiteit uit het ERP of de MDM
- Assetlinks uit de DAM
- Productdata van leveranciers
Verstuurt
- Gepubliceerde productcontent naar de storefront, marktplaatsen, print en AI-kanalen
Niet zijn taak: Voorraad, prijzen en orders. Een PIM kan ze tonen, maar is er niet de eigenaar van.
Lees de gids over PIMDe kaart toont acht systemen in vier gekleurde groepen rond één integratielaag: productcontent, verkopen, leveren en het fundament eronder. Lijnen die door het midden lopen, zijn asynchroon: events, iPaaS-flows en batches gaan allemaal door de integratielaag. Lijnen die in een boog rechtstreeks van het ene systeem naar het andere lopen, zijn directe API-aanroepen. Die gebruik je als een koper op het antwoord wacht. Verderop komt dezelfde kaart terug, een keer om te laten zien wie eigenaar is van elk gegeven en een keer om de routes door de stack af te spelen.
Systemen van registratie en systemen van interactie
Twee soorten systemen delen de stack. Een systeem van registratie (system of record) is de autoriteit voor een gegeven: de enige plek waar het mag worden aangemaakt of gewijzigd. Een systeem van interactie (system of engagement) is waar klanten en medewerkers werken: de storefront, de app, het B2B-portaal, het kassasysteem. Systemen van interactie lezen voorbereide data uit de systemen van registratie en sturen terug wat de koper deed.
De regel die een stack gezond houdt, is kort: één eigenaar voor elk gegeven. Kan hetzelfde veld in twee systemen worden bewerkt, dan lopen de twee kopieën uit elkaar. Een beschrijving die in de webshop is verbeterd, wordt bij de volgende import overschreven. Een contractprijs verschilt tussen het portaal en de factuur. Voorraad die als beschikbaar wordt getoond, is een uur geleden in een winkel verkocht. Elk van deze gevallen is een probleem van data-eigenaarschap voordat het een softwareprobleem is.
De acht systemen en waar elk eigenaar van is
ERP: het financiële en operationele record
Het ERP (enterprise resource planning) is de juridische en financiële ruggengraat. Het maakt het artikelnummer aan, koppelt de stuklijst, bewaart standaardkostprijzen en lijstprijzen, regelt de inkoop en boekt elke verkoop in het grootboek. Het bepaalt of een artikel actief is, kan worden ingekocht en kan worden verkocht. Waar het niet voor is gebouwd, is content voor de klant: de database is ontworpen voor boekhoudkundige nauwkeurigheid, niet voor rijke attributen, overerving en vertalingen. Waar ERP stopt, begint PIM behandelt die grens uitgebreid.
MDM: één identiteit voor elke klant, leverancier en elk product
MDM (master data management) houdt één betrouwbaar record bij, het golden record, voor de entiteiten die het hele bedrijf deelt: klanten, leveranciers, locaties, accounthiërarchieën en productidentiteit. Het matcht dubbele records uit inkoopsystemen, regionale databases en feeds van partners en voegt ze samen. Het telt het meest in bedrijven met meerdere ERP's, vaak na een fusie, waar dezelfde leverancier of hetzelfde product onder verschillende codes bestaat. Lees de basisprincipes van master data management voor hoe een MDM-programma begint.
PIM: productcontent die verkoopt
De PIM (product information management) neemt het artikelnummer en de basiseenheden over uit het ERP of de MDM en maakt er een product van dat verkoopt: beschrijvingen, specificaties, categorieën, zoekattributen, vertalingen, compliancedocumenten en relaties zoals varianten, accessoires, reserveonderdelen en sets. Volledigheidsregels en reviewworkflows houden een product tegen tot het klaar is voor elk kanaal. Dan publiceert de PIM het. Wat is PIM legt uit hoe een PIM werkt.
DAM: de bestanden en het recht om ze te gebruiken
De DAM (digital asset management) is de bibliotheek voor foto's, video, 3D-modellen, technische tekeningen en handleidingen. Hij leest de metadata van elk bestand, bewaakt gebruiksrechten en vervaldatums, en maakt het juiste formaat en bestandstype voor elk scherm, geleverd via een content delivery network. De PIM bewaart de link, de DAM bewaart het bestand. DAM en PIM legt uit hoe de twee koppelen.
Het commerceplatform: waar de koper handelt
Het commerceplatform, vaak headless met een eigen front-end, is het belangrijkste systeem van interactie. Het draait sessies, accounts, zoeken en navigatie, de winkelwagen, offerteaanvragen en de checkout. Het leest productcontent uit de PIM en de DAM, vraagt de prijsengine om prijzen en het OMS om voorraad, en geeft elke afgeronde order door aan het OMS. Headless en composable commerce legt uit hoe front-end en back-end uit elkaar gaan.
De prijs- en promotie-engine: de prijs op dit moment
Een aparte prijsengine haalt de prijslogica uit het ERP en de storefront. Hij berekent staffels, prijszones, contractprijzen per klant, bundels zoals koop X en krijg Y, en margeregels die voorkomen dat een korting te ver gaat. Hij houdt zijn regels in het geheugen, zodat hij de prijs van een winkelwagen kan berekenen terwijl de koper wacht, en hij geeft het web, de app, het portaal en de winkels hetzelfde antwoord.
OMS: de belofte en de route
Het OMS (ordermanagementsysteem) zit tussen de storefront en de magazijnen. Het telt de voorraad in distributiecentra, winkels, bij 3PL's en bij dropshipleveranciers op tot één cijfer voor available to promise. Voor elke order bepaalt het de beste plek om vanaf te verzenden, en weegt het afstand, voorraad, de kosten van een deellevering en capaciteit af. Het regelt ook wat er na de order gebeurt: backorders, deelleveringen en retouren.
WMS: binnen de vier muren
Het WMS (warehousemanagementsysteem) draait één locatie. Het regelt ontvangst en wegzetten, opslaglocaties, pickrondes, inpakken, scanners en geautomatiseerde apparatuur, en het verzendmanifest voor de vervoerder aan de laadkade. Het OMS bepaalt welk magazijn een order verzendt. Het WMS bepaalt hoe dat magazijn het doet.
Wie eigenaar is van welke data
De tabel is de korte versie van de kaart: één eigenaar per gegeven, waar het vandaan komt, wie het leest en hoe het beweegt.
| Data | Eigenaar | Gevoed door | Gebruikt door | Hoe het beweegt |
|---|---|---|---|---|
| Leveranciers en rechtspersonen | MDM | Leveranciersonboarding en inkoop | ERP, PIM, WMS | iPaaS-flow |
| Artikelnummer en maateenheden | ERP | MDM, PLM | PIM, OMS, WMS, Commerce | Event |
| Producttekst en taxonomie | PIM | ERP | Commerce, marktplaatsen en print | Event |
| Beelden, video en formaten | DAM | Studio's en bureaus | PIM, Commerce, marketingautomatisering | API-aanroep |
| Lijstprijzen en standaardkostprijzen | ERP | Financiële planning en inkoop | Pricing, OMS, het grootboek | Batch |
| Kortingsregels en klantprijzen | Pricing | ERP, commerciële strategie | Commerce, offertetools | API-aanroep |
| Voorraad per opslaglocatie | WMS | Scans bij ontvangst en picken | OMS, ERP | Event |
| Available to promise (ATP) | OMS | WMS, ERP | Commerce, klantenservice en het B2B-portaal | Event |
| Winkelwagens en orders in de checkout | Commerce | De koper | OMS, fraudecheck en betaalgateway | API-aanroep |
| Orderroutering en leverstatus | OMS | Commerce | WMS, ERP, 3PL's en klantberichten | iPaaS-flow |
| Grootboek en btw | ERP | OMS | Business intelligence en btw-aangifte | Event |
Bekijk de tabel als geheel en er tekent zich een patroon af. Elke rij heeft precies één eigenaar, terwijl er veel systemen kunnen zijn die de data aanleveren of lezen. Het ERP is eigenaar van de meeste rijen, omdat het het financiële record is, en de systemen aan de kant van de koper zijn van weinig eigenaar en lezen veel. Kies hieronder een rij in de kaart om die te zien als data die door de stack beweegt. De eigenaar kleurt donker, de systemen die de data aanleveren krijgen een gestreepte rand en de systemen die haar lezen worden gevuld in de kleur van hun groep.
Interactieve kaart
Wie is eigenaar van deze data?
Kies een rij uit de tabel. De eigenaar kleurt donker, en je ziet elk systeem dat de data aanlevert en elk systeem dat haar leest.
Productcontent
Verkopen
Leveren
Fundament
Leveranciers en rechtspersonen
- Eigenaar
- MDMMaster data management
- Levert data
- Leveranciersonboarding en inkoop
- Gebruikt data
- ERP, PIM, WMS
- Hoe het beweegt
- iPaaS-flowBijna realtime, via een API of de iPaaS.
Hoe data beweegt: vier integratiepatronen
Elk systeem rechtstreeks met elk ander systeem koppelen werkt met drie systemen en loopt vast met acht. Elke koppeling brengt een eigen mapping, een eigen foutafhandeling en eigen blinde vlekken mee, en als er één verandert, weet niemand wat er verder breekt. Een beheerde integratielaag geeft één plek voor connectors, datamappings, routering, monitoring en herhaalpogingen. Enterprise-iPaaS-platforms zoals Alumio, MuleSoft, Boomi en SAP Integration Suite doen dat werk, naast message brokers voor events.
Directe API-aanroep
Gebruik het alsHet antwoord is nu nodig en kan niet uit een cache komen.
VoorbeeldenKaartbetalingen, adrescontroles, voorraad reserveren bij de checkout, de prijs van de winkelwagen berekenen.
Events
Gebruik het alsMeerdere systemen moeten weten dat er iets is veranderd.
VoorbeeldenProduct gepubliceerd, voorraad onder een drempel, order vastgelegd. Message brokers zoals Apache Kafka, RabbitMQ of AWS SQS vervoeren ze.
iPaaS-orkestratie
Gebruik het alsData moet tussen systemen en formaten worden gemapt of vertaald.
VoorbeeldenJSON omzetten in EDI-verzendberichten voor een 3PL, ERP-velden mappen naar de PIM, met herhaalpogingen en monitoring op één plek. Alumio, MuleSoft, Boomi en SAP Integration Suite zijn voorbeelden.
Geplande batch
Gebruik het alsHet volume is groot en de data kan wachten.
VoorbeeldenImports van leverancierscatalogi, orderdata voor het datawarehouse, financiële afstemming aan het eind van de dag.
De keuze volgt uit twee vragen: hoe snel moet de data aankomen, en hoeveel is het? Een koper die bij de checkout wacht, heeft een directe aanroep nodig. Een wijziging waar meerdere systemen van moeten horen, is een event. Een formaat dat de ene kant niet kan lezen, vraagt om een iPaaS-mapping. Een leverancierscatalogus met duizenden artikelen die tot vannacht kan wachten, is een batch.
Drie routes door de stack
Dezelfde systemen doen mee aan heel verschillende routes. Lees de drie hieronder en volg ze daarna op de kaart.
Van nieuw artikel tot live productpagina
Het ERP maakt het artikel en de basiseenheid aan. In grotere bedrijven schoont MDM de identiteit op en verwijdert dubbele records. Het schone artikel komt als event in de PIM terecht, waar product- en marketingteams categorieën, vertalingen, specificaties en relaties toevoegen, terwijl de DAM de media toevoegt. Doorstaat het record de volledigheidscheck en is het goedgekeurd, dan publiceert de PIM het, en de integratielaag zet het om voor de zoekindex, de storefront en de marktplaatsen.
Van winkelwagen tot factuur
Bij de checkout vraagt de storefront de prijsengine om het totaal van de winkelwagen en het OMS om wat het kan toezeggen. Na de betaling wordt de order vastgelegd en doorgegeven aan het OMS, dat de beste locatie kiest. Het WMS pickt, pakt in en verzendt, en bevestigt daarna de zending met track & trace. Het OMS zet de order op afgehandeld en geeft hem door aan het ERP, dat de omzet en de kostprijs van de verkochte goederen boekt en de factuur verstuurt.
Een prijs in de winkelwagen
Volgens een vast schema stuurt het ERP lijstprijzen, kostprijzen en contractvoorwaarden naar de prijsengine. Commerciële teams stellen acties en staffels in de engine in. Elke wijziging in de winkelwagen stuurt de volledige context mee, van het account van de koper tot de coupons, en de engine geeft meteen de nieuwe totalen terug, zonder het ERP aan te roepen.
De drie routes op de kaart
Hier zijn dezelfde drie routes, stap voor stap. Let op waar elke route begint: productdata begint in het fundament en gaat via productcontent omhoog naar de storefront, terwijl een order bij de storefront begint en via leveren terug omlaag loopt naar het ERP. Een vierde route laat zien wat er gebeurt als een betaling halverwege een order mislukt, een geval dat het deel voor architecten hieronder uitlegt.
Volg de data
Vier routes door de stack
Druk op afspelen om een route te volgen, of loop er in je eigen tempo stap voor stap doorheen.
Hoe één nieuw artikel een productpagina wordt.
Productcontent
Verkopen
Leveren
Fundament
Het ERP maakt het artikel aan
Gaat een product van ontwerp naar productie, dan geeft het ERP het een artikelnummer, koppelt het de stuklijst en legt het een standaardkostprijs en een basiseenheid vast, zoals stuk, doos of pallet.
Available to promise: wat het OMS kan verkopen
Voorraad op de plank is nog geen voorraad die je kunt verkopen. Een deel is al gereserveerd voor orders die nog niet zijn verzonden, en een deel wordt achtergehouden als buffer voor telfouten. Available to promise (ATP) is wat overblijft voor een nieuwe klant. Het OMS berekent het op een van twee manieren. Voor orders die nu worden verzonden, telt het alleen de voorraad die er ligt. Voor orders met een leverdatum in de toekomst telt het ook de inkooporders en productie mee die vóór die datum binnenkomen, min de vraag die voor dezelfde periode al is toegezegd.
Probeer het zelf
Kunnen we het toezeggen?
Verschuif de schuifregelaars en zie hoe het OMS bepaalt wat het kan toezeggen. Leveren uit voorraad telt alleen wat op de plank ligt. Toezeggen op datum telt ook mee wat vóór de leverdatum binnenkomt.
Leveren uit voorraad
Voor orders die nu worden verzonden.
75 stuks
Beschikbaar om toe te zeggen
Op voorraad − toegewezen − veiligheidsvoorraad120 − 35 − 10 = 75
Je kunt 75 van de 90 toezeggen. 15 tekort.
Toezeggen op datum
Voor orders met een leverdatum in de toekomst.
130 stuks
Beschikbaar om toe te zeggen
(Op voorraad + binnenkomend) − (toegezegd + veiligheidsvoorraad)(120 + 60) − (40 + 10) = 130
Je kunt alle 90 toezeggen.
Toont de storefront de voorraad die er ligt in plaats van ATP, dan wordt er meer verkocht dan er is: twee kopers krijgen het laatste exemplaar, en een van hen krijgt een excuus. Daarom vraagt de storefront het aan het OMS, niet aan het WMS en niet aan het ERP.
Waar de grenzen liggen
De meeste architectuurproblemen komen voort uit overlap. Elk van deze paren deelt een stuk terrein, en elk paar werkt als één regel bepaalt wie waar eigenaar van is.
MDM
Eén identiteit voor klanten, leveranciers, locaties en producten in het hele bedrijf.
PIM
De commerciële content van het product en de levering ervan aan elk kanaal.
MDM legt vast wat iets is. De PIM bepaalt hoe het wordt verkocht.
- Gedeeld terrein
- Attributen, validatieregels, governance-workflows.
- Als één systeem allebei doet
- Merchandisingwerk loopt vast in governance-workflows, of een PIM moet juridische en leveranciershiërarchieën bevatten waarvoor hij niet is gebouwd.
ERP
Boekhouding, kostprijs van de verkochte goederen, voorraadwaarde, inkoop en het grootboek.
OMS
Live leverbelofte (ATP) over alle locaties, orderroutering, deelleveringen en retouren.
Het ERP beheert de boeken. Het OMS beheert de leverbelofte en de route.
- Gedeeld terrein
- Verkooporders, klantdata, voorraadtellingen.
- Als één systeem allebei doet
- Databaselocks bij verkeerspieken, oververkoop en dure deelleveringen.
OMS
Welke locatie elke orderregel verzendt, over het hele netwerk.
WMS
Hoe één locatie pickt, inpakt en verzendt: opslaglocaties, pickrondes, scanners, manifesten.
Het OMS bepaalt waar. Het WMS bepaalt hoe.
- Gedeeld terrein
- Voorraad, orderstatus, verzendbevestiging.
- Als één systeem allebei doet
- Geen eenduidig zicht op voorraad, routeringslogica die twee keer is gebouwd, orders die naar de verkeerde plek gaan.
Commerce
De winkelwagen, de checkout en de sessie van de koper.
Prijsengine
Contractprijzen, staffels, bundels en margeregels, gelijk in elk kanaal.
De storefront legt vast wat de koper wil. De engine bepaalt wat het kost.
- Gedeeld terrein
- Winkelwagentotalen, kortingscodes, actieprijzen.
- Als één systeem allebei doet
- Trage checkouts, en verschillende prijzen op het web, in de app en aan de kassa.
Het patroon herhaalt zich: het systeem met het overzicht over het hele bedrijf stelt de regels, en het specialistische systeem voert uit. MDM bewaakt de identiteit en de PIM verkoopt. Het OMS routeert over het hele netwerk en het WMS werkt binnen één gebouw. Het ERP houdt de boeken bij en het OMS bewaakt de leverbelofte.
Voor architecten: een opgesplitste stack consistent houden
Een stack opsplitsen in specialistische systemen haalt de knelpunten van één grote suite weg, maar je levert de zekerheid van één database in. Deze patronen brengen die zekerheid terug.
Opslaan en publiceren in één keer: het outbox-patroon
Een systeem moet vaak een wijziging opslaan en andere systemen erover informeren. Lukt het opslaan en mislukt het bericht, dan horen de andere systemen er nooit van. Gaat het bericht de deur uit en wordt het opslaan teruggedraaid, dan handelen ze op iets wat nooit is gebeurd. Met de transactional outbox schrijft het systeem de wijziging en het uitgaande bericht in één transactie naar de eigen database. Een aparte lezer, vaak change data capture zoals Debezium die het databaselog leest, publiceert het bericht daarna naar de broker. Ontvangers houden bij welke berichten ze al hebben verwerkt, zodat een bericht dat twee keer binnenkomt maar één keer wordt verwerkt.
Saga's in plaats van één grote transactie
Een checkout raakt het OMS, de betaalprovider en het WMS. Alle drie vastzetten in één gedistribueerde transactie is traag en kwetsbaar in de cloud. Een saga splitst het werk op in lokale stappen, elk met een eigen herstelstap. Een coördinator, zoals het OMS of een workflowservice, voert de stappen op volgorde uit. Mislukt er één, dan voert hij de herstelstappen in omgekeerde volgorde uit: de voorraad vrijgeven, de betaalautorisatie intrekken, de klant informeren.
Eén verzoek voor de productpagina
Een productpagina heeft de beschrijving uit de PIM nodig, beelden uit de DAM, de prijs van de klant uit de prijsengine en de beschikbaarheid uit het OMS. Elk systeem apart vanuit de browser bevragen is traag en legt de binnenkant van de stack bloot. Een API-gateway regelt aan de rand de beveiliging, rate limits en tokencontroles, en daarachter beantwoordt een laag met GraphQL federation één query door de systemen parallel te bevragen en één antwoord terug te geven.
Houd lezen en schrijven gescheiden
Shoppers browsen veel vaker dan ze kopen. Komt elke zoekopdracht en elke paginaweergave bij dezelfde database uit die de orders verwerkt, dan vertragen pieken alles. Met CQRS (command query responsibility segregation) verwerken de systemen van registratie de wijzigingen, en kopieert een eventstream de resultaten naar zoekmachines, caches en voor lezen geoptimaliseerde opslag die de storefront bedient.
Veilig falen
Een circuit breaker stopt met het aanroepen van een trage of falende service, zoals een externe btw- of adrescontrole, en levert een terugvaloptie tot de service herstelt. Asynchrone checkout bevestigt de order aan de koper zodra de betaling is geautoriseerd en de order veilig is opgeslagen, en laat fraudecontroles, toewijzing en boekingen in het grootboek over aan wachtrijen op de achtergrond. En omdat message brokers minstens één keer afleveren, moet elk ontvangend systeem idempotent zijn: hetzelfde bericht twee keer verwerken mag niet leiden tot twee keer afschrijven, twee keer verzenden of voorraad twee keer tellen.
Suite, microservices of packaged business capabilities
Jarenlang draaide commerce op suites die catalogus, prijzen, klanten, winkelwagens en orders in één codebase en één database hielden. Dat maakte consistentie makkelijk en verandering traag: een druk onderdeel betekende de hele applicatie opschalen, en elke release betekende alles testen. Microservices en de MACH-principes splitsten de stack op in kleine services achter API's. Die schalen en worden los van elkaar uitgerold, maar hebben soms veel netwerkaanroepen nodig om één pagina op te bouwen.
Veel teams komen nu ergens tussenin uit, met packaged business capabilities, de term van Gartner voor componenten die elk één complete bedrijfsfunctie leveren, zoals catalogusbeheer of orderroutering, via hun eigen API's en events. De keerzijde is het integratiewerk ertussen, ook wel de integration tax genoemd: koppelingen, mappings en monitoring die iemand moet bouwen, draaien en betalen. Duidelijk eigenaarschap en een beheerde integratielaag houden die kosten in de hand. Headless, composable en MACH behandelt de keuze tussen deze opzetten.
Wat dit betekent als je een PIM kiest
Een PIM werkt nooit alleen. Breng in kaart waar hij in je stack komt te staan voordat je leveranciers vergelijkt.
Zet je huidige en geplande systemen op een rij
Noem je ERP, een eventuele MDM, de DAM, het commerceplatform, het OMS en WMS, de prijstools en elk kanaal. Noteer welke systemen in de komende twee jaar veranderen.
Geef elk gegeven één eigenaar
Loop de attributen door en bepaal welk systeem elk attribuut aanmaakt en wijzigt. De eigenaarstabel hierboven is een goed startpunt.
Teken de stromen en kies een patroon
Bepaal per stroom de richting, hoe snel de data moet aankomen en hoeveel data er beweegt. Dan weet je of het een API-aanroep, een event, een iPaaS-flow of een batch wordt.
Test de koppelingen van de PIM
Vraag naar API's, events of webhooks bij publicatie, bulkimport en -export, een DAM-connector en kant-en-klare connectors voor je iPaaS. Test ze in de demo met je eigen data, niet met de voorbeeldcatalogus van de leverancier.
Neem de integratielaag op in het budget
Connectors, mappings, monitoring en de mensen die ze beheren horen vanaf het begin in de business case, niet in een wijzigingsverzoek na de go-live.
Waar dit naartoe gaat: agents als kopers
Een stack met duidelijke eigenaren en snelle, gestructureerde API's is ook wat AI-shoppingagents nodig hebben. Als een agent producten vergelijkt, een prijs controleert en voor een klant een order plaatst, leest hij dezelfde productdata, prijzen en ATP-cijfers als je storefront, alleen kijkt er dan niemand mee op het scherm. Duidelijk eigenaarschap houdt die antwoorden juist. AI-klare productdata beschrijft wat je als eerste oplost.
Hoe je verder gaat
Frequently asked questions
Wat is een systeem van registratie (system of record)?
Het systeem van registratie is het ene systeem dat eigenaar is van een gegeven en het mag wijzigen. Elk ander systeem dat de data nodig heeft, leest er een kopie van. Artikelnummers en kostprijzen staan meestal in het ERP, productcontent in de PIM, beschikbare voorraad in het OMS en voorraad per opslaglocatie in het WMS.
Wat is het verschil tussen een OMS en een WMS?
Het OMS bepaalt waar een order wordt uitgeleverd: welk magazijn, welke winkel of welke 3PL elke orderregel verzendt, op basis van voorraad, afstand en kosten in het hele netwerk. Het WMS bepaalt hoe dat binnen één magazijn gebeurt: opslaglocaties, pickrondes, inpakken en verzendmanifesten voor de vervoerder.
Wat is het verschil tussen een ERP en een OMS?
Het ERP houdt het financiële record bij: kostprijzen, voorraadwaarde, inkoop, het grootboek en facturen. Het OMS regelt de live orderafhandeling: available to promise over alle locaties, orderroutering, deelleveringen en retouren. Het OMS stuurt de afgeronde order naar het ERP voor de boeken.
Hoort productdata in het ERP, de MDM of de PIM?
Elk systeem is eigenaar van een ander deel. Het ERP maakt het artikelnummer, de eenheden, de kostprijzen en de lijstprijzen aan. Is er een MDM, dan houdt die één schone identiteit van het product bij voor het hele bedrijf. De PIM is eigenaar van alles wat het product laat verkopen: beschrijvingen, specificaties, categorieën, vertalingen, relaties en kanaalversies.
Heb ik een aparte prijsengine nodig?
Niet altijd. De kortingstools in een commerceplatform volstaan voor eenvoudige acties en coupons. Een aparte engine loont bij B2B-contractprijzen, staffels, complexe bundels, margeregels, of meerdere kanalen zoals web, app, portaal en winkels die dezelfde prijs moeten tonen.
Wat is available to promise (ATP)?
Available to promise is de voorraad die je nog aan een nieuwe klant kunt verkopen. ATP voor levering uit voorraad is de voorraad die er ligt, min wat is toegewezen aan open orders en min de veiligheidsvoorraad. ATP op datum telt daar ook de aanvoer bij op die vóór de leverdatum binnenkomt, en trekt de vraag af die voor die periode al is toegezegd.
Wat doet een iPaaS in een commerce-stack?
Een iPaaS (integration platform as a service) is de middenlaag die de systemen verbindt. Het biedt kant-en-klare connectors, mapt en transformeert data tussen formaten, routeert berichten, probeert mislukte leveringen opnieuw en laat zien waar een flow brak, zodat niet elk systeem een eigen koppeling met elk ander systeem nodig heeft.
Wat is een packaged business capability (PBC)?
Een packaged business capability is de term van Gartner voor een softwarecomponent die één complete bedrijfsfunctie levert, zoals catalogusbeheer of orderroutering, via eigen API's en events. Het is groter dan een microservice en kleiner dan een volledige suite, en je kunt het los vervangen.
Diagnose
Heb je eigenlijk wel een PIM nodig?
Draai eerst de complexiteitsindex voordat je software budgetteert of een systeemintegrator inhuurt.
Budget
Maak een eerste TCO-berekening
Zet de vorm van je catalogus in minder dan tien minuten om in een kostenrange voor drie jaar.