Waarom de demo het selectieproces maakt
Het RFP geeft u een papieren beeld van wat een PIM-systeem kan. De demo geeft u het werkelijke beeld. Hier ziet u hoe de interface eruitziet, hoe snel het systeem reageert, hoe intuïtief de processen verlopen en hoe de leverancier omgaat met uw specifieke scenario's. Een goede demo is het meest informatieve onderdeel van het selectieproces.
Maar een demo is pas waardevol als u de juiste vragen stelt en de juiste scenario's laat doorlopen. Zonder voorbereiding krijgt u een gepolijste verkooppresentatie die indruk maakt maar weinig zegt over de dagelijkse realiteit.
Voorbereiding: de sleutel
Voordat u demo's inplant, kunt u leveranciers vinden en screenen via PIM Vendors. Dit helpt u te bepalen welke leveranciers op uw shortlist thuishoren.
Definieer uw use cases
Stel drie tot vijf use cases op die uw dagelijkse werkelijkheid weerspiegelen. Dit zijn geen generieke scenario's, maar concrete processen uit uw organisatie.
Een voorbeeld: "Wij ontvangen wekelijks een Excel-bestand van leverancier X met 200 nieuwe artikelen. De data bevat artikelnummers, beschrijvingen in het Engels, technische specificaties en afbeelding-URL's. Onze data steward moet deze data importeren, de beschrijvingen vertalen naar Nederlands en Duits, ontbrekende attributen aanvullen, de datakwaliteit controleren, en de producten publiceren naar onze webshop en twee marktplaatsen."
Stuur de use cases minimaal twee weken vóór de demo naar de leverancier, samen met een representatieve dataset. Vraag de leverancier om de demo op basis van deze use cases en data te geven — niet op basis van zijn eigen voorbeelddata.
Stel een scoreformulier op
Maak voor elke demo een scoreformulier aan waarop elke stakeholder het systeem beoordeelt op vooraf bepaalde criteria. Gebruik een schaal van 1 tot 5 en laat elke stakeholder onafhankelijk scoren — dus niet in groep bespreken vóór de individuele scoring is afgerond.
Typische criteria zijn gebruiksvriendelijkheid van de interface, snelheid en responsiviteit, ondersteuning van de use cases, kwaliteit van de uitleg door de leverancier, en geschiktheid voor de dagelijkse gebruiker.
De vragen: per categorie
Dagelijks gebruik
Hoe ziet het dagelijkse werk van een data steward eruit in dit systeem? Vraag de leverancier om een volledige werkdag te simuleren: producten importeren, verrijken, controleren en publiceren.
Hoe zoekt een gebruiker producten in het systeem? Laat de leverancier zoeken op verschillende criteria: artikelnummer, beschrijving, categorie, attribuutwaarde, status. Test de snelheid bij het volume dat u verwacht.
Hoe werkt bulkbewerking? Laat de leverancier vijftig producten tegelijk bewerken — een attribuutwaarde wijzigen, een categorie toekennen, een publicatiestatus aanpassen. Dit is het dagelijkse werk van een data steward; het moet snel en intuïtief zijn.
Hoe werkt de workflow? Laat de leverancier een product doorlopen van aanmaak via verrijking naar goedkeuring en publicatie. Wie ontvangt notificaties? Hoe ziet de takenlijst van elke rol eruit?
Import en onboarding
Hoe importeert het systeem data uit Excel of CSV? Laat de leverancier uw eigen leveranciersbestand importeren. Let op het mappingproces: hoe worden kolommen gekoppeld aan attributen? Hoe worden fouten en ontbrekende waarden afgehandeld?
Hoe gaat het systeem om met leveranciersdata van wisselende kwaliteit? Wat gebeurt er met velden die niet passen in het datamodel? Met onvolledige records? Met duplicaten?
Hoe verloopt de initiële datamigratatie? Kan de leverancier een migratieplan laten zien voor uw huidige datavolume?
Datakwaliteit
Hoe meet het systeem datakwaliteit? Laat de leverancier de completeness score tonen voor een subset van uw data. Hoe worden validatieregels geconfigureerd? Wat ziet een gebruiker wanneer een product niet voldoet aan de kwaliteitseisen?
Hoe voorkomt het systeem dat onvolledige of foutieve data wordt gepubliceerd? Welke kwaliteitsgates zitten er in de workflow?
Publicatie
Hoe publiceert het systeem naar uw webshop? Laat de leverancier de koppeling met uw e-commerceplatform demonstreren. Is er een kant-en-klare connector of is maatwerk nodig?
Hoe genereert het systeem feeds voor marktplaatsen? Laat de leverancier een feed genereren voor een marktplaats die u gebruikt. Hoe worden kanaalspecifieke eisen (verplichte attributen, formaten, maxlengtes) afgehandeld?
Hoe gaat het systeem om met kanaalspecifieke content — andere beschrijvingen, andere afbeeldingen of andere prijzen per kanaal?
Technisch
Hoe ziet de API eruit? Vraag de leverancier om de API-documentatie te tonen en een live API-call te demonstreren. Beoordeel de volledigheid, de consistentie en de kwaliteit van de documentatie.
Hoe verloopt de integratie met uw ERP? Vraag specifiek naar het synchronisatiemechanisme, de frequentie en de foutafhandeling. Als er een kant-en-klare connector bestaat voor uw ERP, vraag dan om deze te demonstreren.
Hoe presteert het systeem bij uw verwachte volume? Vraag de leverancier om een performancetest te laten zien met een dataset die representatief is voor uw volume.
Leveranciersprofiel
Hoeveel klanten heeft de leverancier in uw branche? Vraag om specifieke referenties en de mogelijkheid om met deze klanten te spreken.
Hoe ziet de productroadmap eruit voor de komende twaalf tot achttien maanden? Investeert de leverancier in de richting die voor u relevant is (AI, composable commerce, sustainability-data)?
Hoe is de support georganiseerd? Wat zijn de responstijden? Is er Nederlandstalige support beschikbaar?
Welke implementatiepartners zijn gecertificeerd en beschikbaar in uw regio?
De valkuilen tijdens demo's
De standaarddemo accepteren is de meest gemaakte fout. Een leverancier die weigert om op basis van uw use cases en data te demo-en, verdient extra scepsis. Het kan betekenen dat het systeem moeite heeft met uw specifieke scenario's.
Alleen naar de mooie functies kijken is de tweede valkuil. Vraag ook naar de minder glamoureuze maar kritieke aspecten: foutafhandeling, logboeken, rechtenstructuur en performance onder belasting.
Te weinig tijd nemen leidt tot oppervlakkige indrukken. Plan minimaal twee uur per leverancier en beperk het aantal demo's tot maximaal twee per dag. Demovermoeidheid na drie achtereenvolgende sessies leidt tot vlakkere beoordelingen.
De eindgebruiker niet betrekken resulteert in een systeem dat het management overtuigt maar de dagelijkse gebruiker frustreert. De data steward die het systeem acht uur per dag gebruikt, ziet dingen die een manager of IT-architect niet opmerkt.
Na de demo: de evaluatie
Plan direct na elke demo een korte evaluatiesessie van dertig minuten met alle stakeholders. Verzamel de individuele scores, bespreek opvallende observaties en leg de belangrijkste bevindingen vast.
Vergelijk de leveranciers na alle demo's op basis van het scoreformulier. Zorg dat de vergelijking gebaseerd is op de demonstraties, niet op de verkooppresentatie. Een leverancier die minder indrukwekkend presenteert maar uw use cases beter ondersteunt, verdient de voorkeur boven een leverancier die uitblinkt in presentatie maar uw realiteit niet aankan.
Samenvatting
De PIM-demo is het meest informatieve onderdeel van het selectieproces, mits u zich goed voorbereidt. Definieer uw use cases vooraf, stuur ze tijdig naar de leverancier, stel een scoreformulier op, betrek alle stakeholders, en evalueer direct na de demo. De juiste vragen stellen is minstens zo belangrijk als de antwoorden die u krijgt.