Wie is de bron? Prijzen, orders en productdata tussen ERP, PIM en shop
Als een prijs in je ERP anders is dan in je shop, welke klopt dan? Bij elke koppeling begint het met één vraag: welk systeem is leidend voor welke data?
Een webshop staat zelden op zichzelf. Productinformatie komt uit een PIM, prijzen uit het ERP, voorraad uit het magazijn en orders gaan terug naar de boekhouding. Dat werkt goed, zolang voor elk stukje data duidelijk is waar het vandaan komt.
Gaat het mis, dan zie je het meteen. Een medewerker past een prijs aan in de shop, en de volgende nacht staat de oude prijs er weer. Een producttekst wordt op twee plekken bijgewerkt, en niemand weet meer welke versie de juiste is.
Voor elk stukje data is er één bron. De rest volgt.
Eén bron per soort data
Het principe is eenvoudig: voor elk soort data is precies één systeem leidend. Daar wordt het aangemaakt en gewijzigd. Andere systemen krijgen een kopie, en passen die niet zelf aan.
Een veelvoorkomende verdeling:
| Data | Leidend systeem | Gaat naar |
|---|---|---|
| Productinformatie en vertalingen | PIM | Shop, marktplaatsen |
| Prijzen en klantspecifieke prijzen | ERP | Shop |
| Voorraad | WMS of ERP | Shop |
| Orders | Shop, tot ze zijn doorgezet | ERP, WMS |
| Content en landingspagina’s | Shop |
Dit is geen vaste regel. Een kleinere shop zonder PIM beheert productdata gewoon in de shop. Waar het om gaat, is dat de keuze bewust is gemaakt en dat iedereen hem kent.
Waar het misgaat
Wijzigen op de verkeerde plek. Als een prijs in de shop is aan te passen terwijl het ERP leidend is, gebeurt dat ook. Tot de volgende synchronisatie het overschrijft. Maak velden die uit een ander systeem komen daarom alleen-lezen in de shop, of laat duidelijk zien waar ze vandaan komen.
Twee kanten op synchroniseren. Een koppeling die data heen en weer stuurt, lijkt handig. Maar als beide kanten mogen wijzigen, wint de laatste wijziging. En dat is niet altijd de juiste.
Uitzonderingen zonder eigenaar. Een actieprijs, een product dat alleen online wordt verkocht, een vertaling die nog ontbreekt. Spreek af waar die thuishoren, anders belanden ze in het systeem dat toevallig het makkelijkst is.
Een voorbeeld: Ambiente
Bij Ambiente legden we eerst vast welk systeem waarvoor de bron is, voordat we een regel code schreven. Akeneo beheert alle productinformatie in vier talen. Exact Globe is leidend voor prijzen, klantspecifieke prijzen en klantgroepen, en ontvangt alle orders uit de shop. De shop toont en verkoopt, maar is voor die data geen bron.
Daardoor weet het team altijd waar iets moet worden aangepast. En een nieuwe collectie hoeft maar op één plek te worden ingevoerd.
Wat je hieruit meeneemt
- Leg per soort data vast welk systeem leidend is, voordat je een koppeling bouwt.
- Laat data in één richting lopen, en voorkom dat het op andere plekken kan worden gewijzigd.
- Spreek ook af waar uitzonderingen thuishoren, zoals actieprijzen en ontbrekende vertalingen.