Hoe nuttig is zo’n RFP in e-commerce? En waarom niet beginnen met een MVP? Er is veel verwarring over de term Request for Proposal. Je hebt ook RF Information and RF Quotation. De RFP is dus je waslijstje met functionaliteiten die je graag wilt. Maar je moet in de praktijk nog maar zien of dat echt past bij jouw cultuur, manier van werken en zaken doen. Overweeg daarom een MVP! Je kan meteen aan de slag. Al doende leert men. Welke customizations echt nodig zijn blijkt snel.
Eigenlijk heeft de technologische revolutie weinig vat gekregen op het inkoopproces van de meeste bedrijven. In het verre verleden - en ik bedoel de jaren 70 - deed je je Request for Information op de post. In de jaren 90 kon je prachtig faxen. En vandaag gaat die RfI met de snelheid van het licht naar een longlist van leveranciers. Is dat nu vooruitgang? Je hebt je postzegels weggegooid, maar de procedure is nog net zo omslachtig.
Begrijpelijk is dit wel. Organisaties worden geacht niet zomaar hun geld uit te geven. Een formeel inkoopproces is nooit gemakkelijk, maar brengt wel het een en ander aan het licht: je neemt die eventuele suppliers onder de loep en wordt gedwongen razend goed na te denken over wat je nodig hebt. Makkelijk is dat niet. Je wilt leveranciers niet ondervragen over functionaliteiten die je in de praktijk niet nodig hebt, of vereisten die juist onmisbaar zijn over het hoofd zien.
En dan wat? De shortlist! Je nodigt een aantal leveranciers uit om een concreet en min of meer bindend voorstel te doen, de beruchte Request for Proposal. Zo’n RfP is in feite een blueprint voor het project zelf (en eindigt bovendien met een offerte), dus is het zaak zo gedetailleerd en specifiek mogelijk te zijn. Dat is een hele klus.
Je kunt er niet omheen: een e-commerce platform of re-platform project is altijd eigenlijk een development project dus loont het wellicht de moeite een kijkje te nemen bij de software industrie.
App-ontwikkelaars maken regelmatig gebruik van een zogenaamd Minimal Viable Product (MVP). “Viable” betekent “haalbaar” of “levensvatbaar” en dat klopt, want een MVP is een volwaardig product, geen test poging van een nog te schrijven app. De analogie die je vaak tegenkomt is die van een cupcake: een kant en klaar product waar je van smult en dus helemaal geen beta versie van een bruidstaart. Die kun je bij de bakker bestellen als de cupcake je beviel, en dan met alle versieringen waar je zin in hebt.
Zo gebruiken developers MVP's: wat zijn de mogelijkheden de webshop, wat vinden mijn klanten gebruiksvriendelijk of juist niet, hoe breiden wij de de webshop uit enzovoort? En dat is nu juist wat je wilde weten over je (nieuwe) e-commerce platform.
Je kan alle screenshots en technische details hebben die je wilt, niets evenaart de ervaring van het omgaan met de applicatie zelf. Een MVP versie van een e-commerce platform geeft je de kernfuncties, maar dit is een voordeel omdat je toch een eigen maatoplossing wilt. Al doende leert men, en een MVP stelt je in staat vlijmscherp te focussen op de add-ons die je werkelijk nodig hebt. Vaak blijken deze af te wijken van de eisen die je in je RfI had gesteld. Een RfP is nooit zo verhelderend, omdat de antwoorden die uit de bus komen alleen maar je eigen verhaal terugvertellen. Maar met een MVP kom je veel eerder in contact met de realiteit - echte klanten, echte feedback, en inzichten waar je wat aan hebt.
Dit verkort de doorlooptijd en versnelt de implementatie van je nieuwe platform. De roll-out zelf zal minder problemen geven, al is het alleen maar omdat je al een relatie opgebouwd hebt met je klanten en de developers van je toekomstige platform.
We zijn allemaal heel erg gewend aan RfP's; overheidsinstanties en zeer grote bedrijven zullen het moeilijk vinden om zich ervan los te maken. Maar vooral voor e-commerce bedrijven is een MVP veel effectiever, en meer agile.
En wie houdt er niet van een cupcake?
Meer informatie
Heb je een MVP opgesteld en wil je deze vertaald zien worden naar een (nieuwe) webshop? Neem dan contact met ons op om de mogelijkheden te bespreken.
NL
English 