Het is een geliefd onderwerp bij bedrijfsborrels en verjaardagfeestjes. De mislukte implementatie van een nieuwe tool. Of de veel te duur uitgevallen bouw van een nieuwe applicatie. “Wat heeft Inkoop een broddelwerk afgeleverd”. “Iedereen kon toch zien dat het veel duurder zou uitvallen?”. De beste stuurlui aan wal nemen er vast nog een biertje op.

Helaas hebben ze wel een punt. Het gaat te vaak niet goed. Te duur, te lang, niet af of anders dan gewenst of voorspeld. Hoe kan het dat een selectietraject voor een nieuw te bouwen applicatie of te implementeren tool zo vaak niet oplevert wat ervan werd verwacht? Of veel duurder uitvalt dan gedacht? En de belangrijkste vraag; kunnen we er wat aan doen?

RFP-trajecten

Laten we inzoomen op de vraag waarom RFP-trajecten zo vaak mislukken. Een eerste, heel eenvoudige verklaring: doordat leveranciers de werkelijkheid mooier presenteren dan het in werkelijkheid is. Kan dat zomaar, melden dat “onze tool aan alle requirements voldoet”? Ja! Er lijkt in de huidige markt onvoldoende mechanisme om dat te voorkomen. En wanneer de concurrenten roepen dat zij het wel kunnen, ga je dat vanzelf ook doen. Net als doping in de Tour de France. Wil je bij voorbaat niet kansloos zijn….

Daarnaast is de klant niet altijd in staat kritisch en met kennis van zaken haar rol in het RFP- proces goed te vervullen. Tijd ontbreekt en in expertise loopt men logischerwijs achter op de leverancier. Men kijkt vanuit inkoop met een financiële bril naar de situatie en niet op basis van gewenste functionaliteit. Inhoudelijke mensen hebben het druk; zien de demo wel maar blijven niet overeind. De demo creëert een sfeer dat iedereen het wil hebben. De vragenlijst is “ja” of “nee”, terwijl het besluitvormingsproces juist genuanceerd moet zijn.

Het is bijzonder dat deze situatie kan blijven bestaan. Regels houden het in stand en “op papier” is het makkelijk. In de ogen van betrokkenen is er geen alternatief. Maar dat klopt niet. Want dat is er wel degelijk!

Vergelijk het met het kopen van een auto; een grote uitgave. Bijna niemand koopt een auto op basis van de specificaties op papier. Je maakt een proefrit voordat wordt besloten welke auto het wordt. Want pas als je rijdt vallen bepaalde details op; zitten de stoelen goed; trekt ie lekker fel op, stuurt ie goed in de bochten? Kortom; je doet een eerste ervaring op voordat je tot aanschaf overgaat.

Bij een toolselectie gaat het om veel grotere bedragen, met veel meer impact op een organisatie dan de aanschaf van een auto. Toch zie je zelden dat er een “proefrit” wordt gemaakt. Dat vinden we lastig uit te leggen. Hoe kun je nu een product, dat mede de kwaliteit van jouw dienstverlening voor een aantal jaar gaat bepalen, zonder proefrit aanschaffen?

Proof of concept

De oplossing bevat een aantal aspecten. Op de eerste plaats: zorg ervoor dat geselecteerde partijen een Proof of concept kunnen uitvoeren. Laat hen gedurende een sprint van een week aan de slag gaan om vervolgens het resultaat te presenteren. Zo ontstaat een veel genuanceerder beeld van de mogelijkheden. In een aanbesteding wordt de vraag gesteld “Kan uw tool een koppeling maken met andere applicaties”. Gegarandeerd dat alle partijen daar “ja” op zeggen. Maar de ene tool dient daartoe 3 weken maatwerk te bouwen en kost €10.000,-, terwijl de andere tool een kant-en-klare API beschikbaar heeft en in 5 minuten klaar is.

Daarnaast: laat medewerkers al werken met de tool. Zorg dat de Servicedesk 3 dagen calls kan registeren met de nieuwe tool. Borg dat er ervaring wordt opgedaan voordat er een definitieve selectie wordt gemaakt.

Ten slotte; zorg dat een onafhankelijk partij de RFP begeleidt. Dat heeft diverse voordelen. Deze heeft kennis en tijd om de geselecteerde partijen technisch goed te beoordelen. Daarnaast laat een onafhankelijk partij zich niet door emotie meeslepen en kan nuchter en objectief vaststellen wat de beste keuze is.