Waarom de verwarring ontstaat
Je ERP kent je artikelen al. Er staat een nummer, een inkoopprijs, een voorraad en een leverancier. Het lijkt dus logisch om de omschrijving en de foto er ook maar bij te zetten.
Dat werkt totdat je meer wilt dan één regel tekst. Een ERP is gebouwd om transacties vast te leggen, niet om een product te presenteren. Zodra je per taal een andere tekst wilt, tien afbeeldingen per artikel, of vijftien filterbare eigenschappen, zit je tegen de grenzen aan.
De grens in één regel
Een ERP gaat over geld en logistiek: wat kost het, hoeveel hebben we, wie levert het, wat is er verkocht. Een PIM gaat over betekenis en presentatie: wat is het, waarvoor gebruik je het, hoe ziet het eruit, hoe leg je het uit in vier talen.
Hou die scheiding aan en bijna elke vraag lost zich op. Twijfel je over een veld, vraag je af of een boekhouder of een koper het nodig heeft.
Wat er misgaat als je alles in het ERP zet
Drie dingen, in deze volgorde. Eerst gaan je teksten lijden, omdat het veld te kort is of geen opmaak toestaat. Dan gaan je filters lijden, omdat eigenschappen als vrije tekst zijn ingevoerd en dus niet betrouwbaar te filteren zijn.
En uiteindelijk gaat je proces lijden: iemand van de administratie moet marketingteksten bijwerken in een systeem waar hij niet in thuis is, dus het gebeurt niet meer. Dat laatste is de echte schade.
Wat er misgaat als je alles in de webshop zet
Dan heb je één kanaal dat klopt en de rest niet. Zodra je gaat verkopen via een marktplaats, een vergelijker of een dealerportaal, moet je alles opnieuw invoeren of exporteren met de hand.
Ook bij een replatforming voelt dit meteen. Zit je productinformatie in je webshopplatform, dan is een verhuizing naar een ander platform een datamigratie in plaats van een technische omzetting. Zie productdata migreren.
Beslistabel per soort gegeven
In het ERP: artikelnummer, inkoop- en verkoopprijs, staffels en klantcondities, voorraad per locatie, leverancier, levertijd, btw-code, gewicht voor de verzendkosten.
In het PIM of de productlaag: naam, korte en lange omschrijving per taal, alle filterbare eigenschappen, afbeeldingen en video, handleidingen en certificaten, categorieën, accessoires en alternatieven, en de SEO-velden.
De praktijk in het MKB
De meeste bedrijven die wij zien beginnen in het ERP en lopen vast op precies twee punten: beeldmateriaal en meertaligheid. Dat zijn de momenten om de scheiding aan te brengen.
Dat hoeft niet meteen een apart pakket te zijn. Vaak is de eerste stap dat de webshop de productlaag wordt en het ERP alleen nog prijzen en voorraad levert. Dat is een koppeling van beperkte omvang met veel effect.
Het migratiepad
Kies eerst welk systeem eigenaar is van welk veld en schrijf dat op. Zonder dat document wordt elke koppeling een discussie.
Zet daarna de stroom één kant op: het ERP overschrijft nooit een tekst, de productlaag overschrijft nooit een prijs. Conflicten die anders maandelijks terugkomen, verdwijnen dan in één keer.
Veelgestelde vragen
Kan ik voorlopig alles in mijn ERP houden?
Bij één kanaal, één taal en een beperkte catalogus kan dat prima. Ga je meer kanalen of talen bedienen, dan verdient een aparte productlaag zich vrij snel terug, vooral in de tijd die je niet meer aan dubbel invoeren kwijt bent.
Welk systeem is dan de bron van waarheid?
Per veld een ander, en dat is geen probleem zolang je het vastlegt. Prijs en voorraad uit het ERP, tekst en beeld uit de productlaag. Twee bronnen voor hetzelfde veld is wat je moet vermijden.
Wat als mijn ERP geen koppeling heeft?
Vrijwel elk pakket biedt een API of een export. Ontbreekt dat, dan werken we met een tussenlaag die periodiek bestanden verwerkt. Minder elegant, wel werkbaar.
Hebben jullie hier ervaring mee?
Ja, dit is onze niche. We koppelen webshops aan onder meer Business Central, Exact Online en AFAS, en hebben zowel de logistieke als de productkant gebouwd. De eerste analyse en de offerte zijn gratis.