Waarom een MVP een goed begin is

De technologische revolutie heeft weinig vat gekregen op het inkoopproces van de meeste bedrijven. In de jaren ’70 deed je je Request for Information op de post. Later 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. Dat kan anders.

Begrijpelijk is dit wel. Organisaties worden geacht niet zomaar hun geld uitgeven. 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 vendors niet ondervragen over functionalities die je in de praktijk niet nodig hebt, of vereisten die juist onmisbaar zijn over het hoofd zien.

En dan? 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.

Maar het kan veel sneller

Hoe nuttig is zo’n RfP in e-commerce? De meeste B2B- of B2C-organisaties stellen unieke eisen aan hun platforms; one-size-fits-all kom je weinig tegen in e-commerce. Met andere woorden, de voorstellen waar je in een RfP om vraagt moeten in hoofdzaak antwoord geven op de vraag of de vendor genoeg in huis heeft om zijn solution aan te passen aan jouw behoeften. Daarna zul je vrijwel zeker een Proof of Concept nodig hebben om te peilen of de leverancier daadwerkelijk kan leveren wat hij heeft beloofd. En zelfs dan is het nog een sprong in het donker.

Een e-commerceplatform of re-platformproject is altijd eigenlijk een developmentproject, 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 testpoging 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-commerceplatform.

De voordelen van MVP voor een commerceproject

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-commerceplatform 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 hervertellen. 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-commercebedrijven is een MVP veel effectiever, en meer agile.

En wie houdt er niet van een cupcake?