Wat is een RFP en waarom schrijft u er een?

Een Request for Proposal (RFP) is het formele document waarmee u PIM-leveranciers uitnodigt om een voorstel in te dienen. Het vertaalt uw interne eisenpakket naar een extern gericht document dat leveranciers voldoende context geeft om een concreet, vergelijkbaar en realistisch voorstel op te stellen.

Het alternatief — leveranciers informeel benaderen en vragen wat ze te bieden hebben — leidt tot onvergelijkbare voorstellen. Elke leverancier benadrukt dan zijn sterkste punten en omzeilt de zwaktes. Een goed RFP dwingt alle leveranciers om dezelfde vragen te beantwoorden, in dezelfde structuur, waardoor u eerlijk kunt vergelijken.

De structuur van een PIM RFP

Een effectief PIM RFP bevat de volgende secties, in deze volgorde.

1. Introductie en context

Begin met een beknopte beschrijving van uw organisatie: de branche, de omvang, het aantal producten, de huidige verkoopkanalen en de belangrijkste marktgebieden. Geef vervolgens de aanleiding voor het PIM-project: waarom zoekt u een PIM-systeem, welke pijnpunten wilt u oplossen en wat zijn de strategische doelen?

Deze context is essentieel. Zonder deze informatie kan de leverancier geen relevant voorstel schrijven. Wees open maar niet vertrouwelijk — deel voldoende om de situatie te begrijpen, maar bescherm bedrijfsgevoelige details.

2. Huidige situatie

Beschrijf uw huidige IT-landschap en productdataproces. Welke systemen gebruikt u nu (ERP, webshop, marktplaatsen, Excel)? Hoe stroomt productdata door uw organisatie? Welke teams zijn betrokken? Wat zijn de belangrijkste knelpunten?

Noem ook de volumes: het aantal actieve producten, het aantal attributen, het aantal talen, het aantal kanalen en het verwachte groeipad voor de komende drie tot vijf jaar.

3. Scope en doelstellingen

Definieer de scope van het PIM-project: wat valt wel en niet binnen het project? Is het doel een volledige vervanging van het huidige proces of een gefaseerde aanpak? Welke integraties zijn in scope voor de eerste fase?

Formuleer de doelstellingen SMART: specifiek, meetbaar, acceptabel, realistisch en tijdgebonden. Bijvoorbeeld: "Binnen zes maanden na go-live worden alle productdata centraal beheerd in het PIM en automatisch gepubliceerd naar onze webshop en drie marktplaatsen."

4. Functionele eisen

Neem de functionele eisen uit uw programma van eisen op, geprioriteerd volgens de MoSCoW-methode. Structureer deze per domein: datamodellering, workflows, import/export, publicatie, datakwaliteit, mediabeheer en meertaligheid.

Maak de eisen concreet en toetsbaar. In plaats van "Het systeem moet gebruiksvriendelijk zijn" schrijft u: "Een nieuwe gebruiker moet binnen vier uur training zelfstandig producten kunnen aanmaken, verrijken en publiceren."

5. Technische eisen

Beschrijf uw technische randvoorwaarden: het gewenste deployment-model (SaaS, on-premise, hybrid), de API-vereisten (REST, GraphQL), de integratie-eisen met specifieke systemen (noem de systemen en versies), en de eisen aan performance, beveiliging en beschikbaarheid.

Wees specifiek over uw technische landschap: welk ERP-systeem gebruikt u (versie, modules), welk e-commerceplatform, welke marktplaatsen, welk DAM-systeem? Hoe specifieker u bent, hoe realistischer de leverancier kan inschatten wat de integratie kost.

6. Gewenste aanpak en planning

Geef aan wat uw gewenste go-live-datum is en hoe u het project wilt faseren. Welke deliverables verwacht u per fase? Wilt u een big-bang-implementatie of een gefaseerde uitrol?

Vraag de leverancier om een projectplan op te stellen met een tijdlijn, een teamsamenstelling, een risico-analyse en de verwachte betrokkenheid van uw eigen team.

7. Commercieel

Vraag de leverancier om een transparante prijsopgave die alle kosten omvat: licentiekosten (per maand en per jaar), implementatiekosten (gespecificeerd per fase of werkstroom), trainingskosten, eventuele kosten voor extra gebruikers, producten of kanalen, en de jaarlijkse kosten na go-live (licentie, support, onderhoud).

Vraag ook naar de contractvoorwaarden: de minimale contractduur, de opzegmogelijkheden, de eigendomsverhouding van data bij beëindiging en de SLA's.

8. Referenties en use cases

Vraag de leverancier om minimaal twee referenties van klanten in een vergelijkbare branche of met een vergelijkbare scope. Vraag daarnaast om een beschrijving van een vergelijkbaar implementatieproject: de scope, de doorlooptijd, de uitdagingen en het resultaat.

9. Scoringsmodel

Sluit het RFP af met een beschrijving van het scoringsmodel dat u zult gebruiken om de voorstellen te evalueren. Dit geeft de leverancier inzicht in uw prioriteiten en helpt hem om het voorstel daarop af te stemmen.

Een gangbaar scoringsmodel kent gewichten toe aan functionele fit (30%), technische fit (20%), prijs (20%), leveranciersprofiel (15%) en implementatieaanpak (15%). Pas de gewichten aan op uw eigen prioriteiten.

Tips voor een effectief RFP

Stel een duidelijke deadline. Geef leveranciers drie tot vier weken om te reageren. Korter leidt tot haastwerk; langer verliest het project momentum. Zorg dat leveranciers beschikbaar zijn door uw RFP naar bestaande kandidaten te sturen, bijvoorbeeld via PIM Vendors.

Bied een vragenronde aan. Plan een moment waarop leveranciers vragen kunnen stellen over het RFP. Publiceer de vragen en antwoorden (geanonimiseerd) naar alle deelnemende leveranciers, zodat iedereen dezelfde informatie heeft.

Wees eerlijk over uw budget. Als u een budgetbandbreedte kunt delen, helpt dit de leverancier om een realistisch voorstel te schrijven. Zonder budgetindicatie loopt u het risico op voorstellen die ver boven of onder uw verwachting liggen.

Vermijd merknamen in eisen. Schrijf "Het systeem moet integreren met een leading enterprise-ERP" in plaats van "Het systeem moet integreren met SAP S/4HANA." Dit voorkomt dat u leveranciers uitsluit die een andere terminologie gebruiken maar dezelfde functionaliteit bieden.

Laat ruimte voor de leverancier. Een RFP dat elke functie tot in detail voorschrijft, beperkt de ruimte voor innovatieve oplossingen. Beschrijf het gewenste resultaat en laat de leverancier voorstellen hoe dat te bereiken.

Na het RFP: het evaluatieproces

Na ontvangst van de voorstellen scoort u elke leverancier op de criteria uit uw scoringsmodel. Plan vervolgens demo's met de twee tot drie hoogst scorende leveranciers, op basis van uw eigen use cases. Het RFP-voorstel geeft u een papieren beeld; de demo geeft u een werkelijk beeld.

Controleer referenties voordat u een definitieve keuze maakt. Vraag referentieklanten naar de implementatie-ervaring, de kwaliteit van de support, de betrouwbaarheid van het platform en eventuele verrassingen die zij tegenkwamen.

Samenvatting

Een goed PIM RFP is een gestructureerd document dat leveranciers voldoende context geeft voor een concreet en vergelijkbaar voorstel. De structuur omvat introductie, huidige situatie, scope, functionele en technische eisen, gewenste aanpak, commerciële vragen, referenties en scoringsmodel. Een helder RFP bespaart u weken aan onvergelijkbare voorstellen en leidt tot een eerlijker selectieproces.