Kort antwoord
Een programma van eisen voor PIM beschrijft in toetsbare zinnen wat het systeem moet kunnen, verdeeld over zes categorieën: datamodel, verrijking en workflow, import en onboarding, publicatie, integratie en techniek, en leverancier en contract. U prioriteert met MoSCoW, houdt must-haves beperkt en koppelt elke eis aan een use case, zodat leveranciers vergelijkbaar antwoorden en u objectief kunt scoren.
Een programma van eisen (PvE) voor PIM legt in toetsbare zinnen vast wat het systeem moet kunnen, hoe belangrijk elke eis is en hoe u beoordeelt of een leverancier eraan voldoet. Met een goed PvE vergelijkt u leveranciers op uw criteria. Zonder PvE vergelijkt u ze op de onderdelen die zij zelf in een demo laten zien.
Het PvE is de ruggengraat van de hele selectie. Uit dezelfde eisen bouwt u de RFP, de demoscenario's en later de acceptatietests van de implementatie.
Waarom begint een PvE bij use cases?
Een eis zonder context levert een standaardantwoord op: "ja, dat kan". Begin daarom bij vijf tot acht use cases die uw werkelijke werk beschrijven, en leid de eisen daaruit af.
Voorbeeld van een use case: "Een merkleverancier levert maandelijks een Excel-bestand met 1.500 artikelen aan. Productdata moet dit binnen vijf werkdagen controleren, aanvullen met ETIM-kenmerken en Nederlandse en Franse teksten, en publiceren naar de webshop en bol." Uit deze ene zin volgen eisen over import met mapping, validatieregels, classificatie volgens ETIM, vertaalworkflow en kanaalexport.
Leg per use case vast wie de eigenaar is. Die persoon beoordeelt straks in de demo of de eis gehaald wordt.
Welke eisencategorieën horen in een PIM-PvE?
Gebruik zes categorieën die elkaar niet overlappen en samen het hele systeem dekken.
| Categorie | Onderwerpen | Typische eigenaar |
|---|---|---|
| 1. Datamodel | Productfamilies, attributen, varianten, relaties, classificaties, meertaligheid, eenheden | Productdatamanager |
| 2. Verrijking en workflow | Rollen en rechten, taken, review, completeness, validatieregels, AI-ondersteuning, versiebeheer | Data steward, marketing |
| 3. Import en onboarding | Bestandsimport, mapping, leveranciersportaal, ontdubbeling, foutafhandeling | Inkoop, productdata |
| 4. Publicatie en syndicatie | Kanaalspecifieke content, exportformaten, feeds, marktplaatsen, printcatalogus | E-commerce |
| 5. Integratie en techniek | API, ERP- en DAM-koppeling, hosting, prestaties, beveiliging, beschikbaarheid, back-up | IT-architect |
| 6. Leverancier en contract | Support, SLA, roadmap, partners, licentiemetriek, exit en dataexport, AVG | Inkoop, juridisch |
Voor de niet-functionele eisen in categorie 5 kunt u de kwaliteitskenmerken van ISO/IEC 25010 als controlelijst gebruiken, zoals prestatie-efficiëntie, compatibiliteit en interactievermogen. Zo dekt u alle kwaliteitsaspecten met een erkende indeling. Voor de inhoud van categorie 1 sluit dit artikel aan op een productdatamodel opzetten.
Hoe prioriteert u PIM-eisen met MoSCoW?
MoSCoW komt uit de DSDM-methode van het Agile Business Consortium. De vier klassen:
- Must have: de minimale set waarzonder de oplossing onbruikbaar is. Een leverancier die een must-have mist, valt af.
- Should have: belangrijk, maar met een tijdelijke workaround te overbruggen.
- Could have: wenselijk, met beperkte impact als het ontbreekt.
- Won't have this time: bewust buiten scope voor deze fase. Benoem deze klasse expliciet om scope-uitbreiding tijdens de selectie te voorkomen.
DSDM adviseert in een project typisch niet meer dan 60 procent van de inspanning aan must-haves te besteden en rond 20 procent aan could-haves als buffer. Dat advies gaat over projectinspanning. Voor een selectie-PvE werkt een strengere regel beter: houd must-haves indicatief op 20 tot 30 procent van het aantal eisen. Elke must-have is een knock-out, en te veel knock-outs sluit goede leveranciers uit op details.
Koppel de klassen aan een score. Must-haves zijn ja of nee. Should- en could-haves scoort u op een schaal van 0 tot 3 of 1 tot 5, met een hogere weging voor should-haves.
Hoe formuleert u een toetsbare eis?
Een goede eis beschrijft een uitkomst, is meetbaar en is in een demo of test te controleren. Vergelijk:
| Zwak | Toetsbaar |
|---|---|
| Het systeem moet gebruiksvriendelijk zijn | Een key user wijzigt na één uur training één attribuut voor 500 producten in maximaal vijf handelingen |
| Het systeem moet snel zijn | Een export van 50.000 producten met 120 attributen naar CSV is binnen 15 minuten klaar |
| Goede koppeling met ERP | Nieuwe artikelen uit het ERP-systeem verschijnen binnen 15 minuten in het PIM, met artikelnummer, GTIN, prijs en status |
| Moet AI hebben | Het systeem genereert een conceptbeschrijving per product uit attributen, met verplichte review door een redacteur vóór publicatie |
De getallen in deze tabel zijn voorbeelden. Vervang ze door uw eigen volumes en doelen.
Voorbeeldtabel met PIM-eisen
| ID | Categorie | Eis | MoSCoW | Toetsing |
|---|---|---|---|---|
| DM-01 | Datamodel | Producten met varianten op minimaal twee assen (kleur, maat) en overerving van attributen van model naar variant | Must | Demo |
| DM-02 | Datamodel | Attributen per taal en per kanaal, met minimaal Nederlands, Frans, Duits en Engels | Must | Demo |
| DM-03 | Datamodel | Classificatie volgens ETIM met import van een nieuwe ETIM-release | Should | Demo en referentie |
| WF-01 | Workflow | Completeness-score per kanaal en per taal, zichtbaar per product en per categorie | Must | Demo |
| WF-02 | Workflow | Configureerbare reviewstap vóór publicatie met rollen per productgroep | Should | Demo |
| WF-03 | Workflow | Volledige audit trail per attribuutwijziging met gebruiker en tijdstip | Should | Demo |
| IM-01 | Import | Import van Excel en CSV met opgeslagen mapping per leverancier en foutrapport per regel | Must | PoC |
| IM-02 | Import | Leveranciersportaal waarin externe partijen zelf data aanleveren | Could | Demo |
| PB-01 | Publicatie | Export naar bol en Amazon met kanaalspecifieke attributen | Should | Referentie |
| PB-02 | Publicatie | Geplande en event-gestuurde export naar de webshop via API of webhook | Must | PoC |
| IT-01 | Integratie | Gedocumenteerde REST- of GraphQL-API voor lezen en schrijven van alle objecten | Must | Documentatie |
| IT-02 | Techniek | Hosting in de EU en SSO via uw identiteitsprovider | Must | RFP-antwoord |
| LC-01 | Contract | Volledige dataexport in een open formaat zonder extra kosten bij beëindiging | Must | Contract |
| LC-02 | Contract | Verwerkersovereenkomst conform artikel 28 AVG | Must | Contract |
De toetsingskolom bepaalt waar u het bewijs zoekt. Laat leveranciers per eis antwoorden met "standaard", "configuratie", "maatwerk" of "niet beschikbaar", plus een toelichting. Dat onderscheid voorkomt dat maatwerk als standaardfunctionaliteit wordt verkocht en legt de basis voor uw kostenvergelijking.
Welke fouten maken organisaties in een PvE?
- Oplossingen voorschrijven. "Het PIM moet een Excel-plug-in hebben" sluit betere oplossingen uit. Beschrijf de uitkomst.
- Alleen management interviewen. De mensen die dagelijks attributen invullen, kennen de knelpunten het best.
- Integraties vaag laten. Noem elk systeem met naam, versie, richting van de datastroom en frequentie. De plek van PIM tussen de andere systemen staat uitgewerkt in PIM in het IT-landschap.
- Groei negeren. Neem de verwachte aantallen SKU's, talen en kanalen over drie tot vijf jaar op.
- Geen exit-eisen. Eisen over dataexport en beëindiging voorkomen vendor lock-in en zijn later niet meer te onderhandelen.
Het afgeronde PvE gaat als bijlage mee in de PIM RFP-template.
Belangrijkste punten
- Leid eisen af uit vijf tot acht use cases en geef elke eis een eigenaar.
- Werk met zes categorieën: datamodel, workflow, import, publicatie, integratie en techniek, leverancier en contract.
- Houd must-haves beperkt (indicatief 20 tot 30 procent) en behandel ze als knock-out.
- Formuleer elke eis meetbaar en noteer of u hem toetst in demo, PoC, referentie of contract.
- Laat leveranciers per eis aangeven of het standaard, configuratie of maatwerk is.
Veelgestelde vragen
Hoeveel eisen bevat een programma van eisen voor een PIM-systeem?
Indicatief 60 tot 120 eisen voor een middelgrote organisatie. Onder de 40 blijven belangrijke onderwerpen zoals varianten, rechten of exportformaten vaak onbenoemd. Boven de 150 kost het leveranciers en uw beoordelaars veel tijd, terwijl de extra eisen zelden het verschil maken. Het aantal must-haves is belangrijker dan het totaal: houd die lijst kort.
Wat is MoSCoW bij het opstellen van PIM-eisen?
MoSCoW is een prioriteringsmethode uit DSDM met vier klassen: Must have (zonder deze eis is de oplossing onbruikbaar), Should have (belangrijk, met een tijdelijke workaround te overbruggen), Could have (wenselijk) en Won't have this time (bewust buiten scope). Een must-have die een leverancier mist, betekent uitsluiting. Overige eisen tellen mee in de score.
Wie schrijft het programma van eisen voor een PIM?
De projectleider of selectieadviseur schrijft en bewaakt het document. De inhoud komt uit interviews en workshops met de eigenaar van de productdata, e-commerce, marketing, IT, inkoop en twee of drie key users. Laat elke eis eindigen bij een eigenaar die later in de demo beoordeelt of eraan is voldaan.
Mag u merknamen noemen in een programma van eisen?
Noem bestaande systemen waarmee het PIM moet koppelen, zoals uw ERP-systeem, webshopplatform of DAM, met versie. Vermijd merknamen als eis voor het PIM zelf. Publieke organisaties zijn hier extra voorzichtig: eisen moeten objectief en proportioneel zijn en mogen leveranciers niet onnodig uitsluiten.