-

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?

Deel dit bericht

2 Reacties

Jan Jaap Nijemeisland

Beste Dennis,

Ik heb een beetje moeite met je arikel. Vooral qua heen en weer vliegen tussen onderwerpen en termen in verschillende settings. Ik voelde me even als het balletje in een pinball machine dat hard heen en weer geschoten wordt.

Het balletje is de RfP en de MVP en die vliegen beiden door verschillende werelden heen. Je begint met de RfP voor een totaaloplossing of misschien eerder een e-commerce suite als aanvraag en gaat met de MVP langs de app ontwikkelaar die heel anders omgaat met een MVP, via kernfuncties van een e-commerce product door naar een algemene basis.

Ga uit van je MVP en pas het toe op je markt en inderdaad zie hoe verstandig het is en hoe je een begin hebt vanuit waar je het best kunt starten of uitdenken van wat je wilt.

Maak een titel die duidt dat je de e-commerce markt benaderd, web- en appontwikkelbedrijven en andere software ontwikkelingsbureau’s hebben geen pakket kijk op MVP, dus die verwachten 1 en ander net anders.

En dus vooral: schoenmaker blijf bij je leest. Dan smaakt je basis cupcake lekkerder!

Dennis Zuurhout

Beste Jan Jaap,

De flipperkast is nog net niet op tilt geslagen als ik je goed begrijp.

Maar in de essentie blijft het gaan om de keuze die een organisatie moet gaan maken. En inderdaad, dit heeft direct raakvlakken met een e-commerce traject waarbij organisaties toch nog vaak kiezen voor een uitgebreide RfP’s i.p.v. na te denken over een MVP, wat de doorlooptijd verkort en implementatie versnelt.

Begin klein en betrek de belangrijkste stakeholders erbij, zodat je van een cupcake door kan groeien naar een wedding cake. Ook lekker toch!

Plaats een reactie

Uw e-mailadres wordt niet op de site getoond