Een proof of concept voor PIM uitvoeren met de top 2 leveranciers

Wanneer heeft een PIM-selectie een proof of concept nodig?

Een PIM-selectie heeft een proof of concept nodig als een risicovolle eis na de scenariodemo's onbewezen blijft, of als de top 2 leveranciers te dicht bij elkaar scoren om te kiezen. In alle andere gevallen volstaan referentiechecks en het bewijs uit de demo's.

De proof of concept valt in week 10 van het PIM-selectieproces van 12 weken, naast de referentiechecks. Op dat moment hebben de scenariodemo's een shortlist van 3 tot 5 leveranciers teruggebracht tot twee. De proof of concept toetst wat een demo van een halve dag niet kan laten zien.

Gangbare aanleidingen in selecties van PIMvendors:

• Een complex variantmodel met drie of meer assen en diepe overerving.
• Een integratiepatroon met het ERP waarbij het bronsysteem per attribuut verschilt.
• Performance op volledige catalogusomvang, zoals bulkbewerkingen op honderdduizenden producten.
• Een datamodel voor compliance dat de demo maar deels liet zien, zoals verpakkingscomponenten.
• Een AI-use case die op je eigen data veelbelovend oogde maar niet is gemeten.

Speelt geen van deze punten, sla de proof of concept dan over en besteed week 10 aan grondigere referentiechecks. Een proof of concept zonder heldere vraag kost tijd en geeft de leverancier reden om te denken dat hij al gewonnen heeft.

Wat toets je in een proof of concept voor PIM?

Een proof of concept toetst één of twee eisen, gekozen op risico en zakelijk gewicht, met meetbare slaagcriteria. De breedte is al gedekt door de RFP en de demo's. De proof of concept gaat de diepte in op het punt dat het project kan laten ontsporen.

Leg de scope vast in een korte briefing:

De criteria hierboven zijn een illustratief voorbeeld, denk aan een machinebouwer in Brabant met een groot onderdelenassortiment. Leid je eigen criteria af uit je eisprioriteiten en volumes.

Beide finalisten krijgen dezelfde briefing, dezelfde data en dezelfde deadline. Met verschillende scopes zijn de resultaten niet te vergelijken.

Een proof of concept voor PIM in één week uitvoeren

Voer de proof of concept uit als sprint van één week, met een kick-off, dagelijkse check-ins en een afsluitende review tegen de criteria. Eén week actief werk volstaat als de scope uit één of twee eisen bestaat (schatting PIMvendors).

Wijs per proof of concept één teamlid van de koper aan als waarnemer. De waarnemer ziet hoeveel configuratie de oplossing vroeg, wie het deed en hoe lang het duurde. Die inspanning zegt meer over de beheerkosten dan het eindresultaat.

Houd de proof of concept gescheiden van elk demosysteem van sales. Vraag de leverancier elke configuratiestap te documenteren, zodat je de inspanning achteraf kunt beoordelen.

Wie betaalt een proof of concept voor PIM?

Betalen voor een proof of concept is redelijk als er echt configuratie- of integratiewerk nodig is, en de fee hoort te worden verrekend als je voor die leverancier kiest. Met een betaalde proof of concept houdt de koper de regie over de scope.

Gratis proofs of concept komen veel voor, maar ze sturen gedrag. De leverancier bepaalt hoeveel inspanning hij levert en richt zich vaak op wat goed oogt. Een bescheiden fee maakt de scope een verplichting aan beide kanten.

Leg drie afspraken schriftelijk vast:

1. De fee, of een bevestiging dat het werk gratis is.
2. Verrekening van de fee met de licentie of implementatie in het eerste jaar als je voor die leverancier kiest.
3. Eigendom van de configuratie en documentatie, zodat het werk de implementatie kan voeden.

Voert een implementatiepartner de proof of concept uit, dan wordt het team van die partner onderdeel van de beoordeling. Vraag om de mensen die jouw project zouden doen, en controleer of de partner hen in het voorstel bij naam noemt. Het register met rode vlaggen noemt waarschuwingssignalen bij partners, zoals een leveringsteam zonder namen.

Hoe beoordeel je de uitkomst van de proof of concept?

Beoordeel de uitkomst tegen de slaagcriteria die vóór de start zijn vastgelegd, en leg per criterium het bewijs vast. Criteria verschuiven nadat het resultaat bekend is, is de meest voorkomende manier waarop een proof of concept zijn waarde verliest.

Gebruik per criterium een eenvoudige uitkomst: geslaagd, geslaagd onder voorwaarden of gezakt. Een voorwaarde kan een extra module zijn, een partnerextensie of configuratie die technische kennis vraagt. Noteer de kosten en inspanning van elke voorwaarde.

Combineer de uitkomst met de scenarioscores en de bevindingen uit de referenties. Een proof of concept haalt een duidelijke voorsprong uit de demo's zelden in zijn eentje onderuit. Hij bevestigt of wegt de resterende twijfel over de koploper weg, en geeft de directie bewijs voor het meest risicovolle deel van het plan.

Deel de uitkomst met beide leveranciers. De leverancier die slaagde, weet dat de volgende stap commercieel is. De leverancier die zakte, krijgt een eerlijke kans op toelichting en blijft betrokken als terugvaloptie terwijl jij de onderhandeling ingaat.

Wat is het verschil tussen een proof of concept en een pilot?

Een proof of concept onderbouwt het besluit vóór het contract; een pilot ondersteunt de adoptie erna. Wie de twee verwart, krijgt proofs of concept die maanden duren en pilots die starten zonder besluit.

Een leverancier die een lange pilot voorstelt in plaats van een proof of concept, vraagt om een verplichting voordat de commerciële voorwaarden rond zijn. Houd de proof of concept kort en vergelijkbaar, en plan de pilot binnen de implementatie. De pijler implementatie behandelt de pilot en de eerste 90 dagen.