Om tot een keuze te komen van een softwarepakket voeren klanten vaak één of meerdere proeftuinen (pilots) uit. Deze kom je in het projectplan dan tegen als 'PoC' (Proof of Concept). Leveranciers beloven in de aanloop naar de afname van hun product meer dan ze later kunnen waarmaken. Ik geloof in een andere manier van het inrichten van een proeftuin en dat is het laten uitvoeren van een Proof of Product (PoP) in plaats van de gebruikelijke PoC.
Wikipedia geeft als definitie van Proof of Concept het volgende: 'A proof of concept or (POC) or a proof of principle is a realization of a certain method or idea(s) to demonstrate its feasibility, or a demonstration in principle, whose purpose is to verify that some concept or theory has the potential of being used. A proof-of-concept is usually small and may or may not be complete.'
Iedereen die over het begrip PoC heeft nagedacht in relatie tot de manier waarop wij het gebruiken binnen de ict zal het met me eens zijn dat deze definitie achterhaald is. Het gaat helemaal niet meer om het aantonen van de haalbaarheid van een methode of idee. Nu we steeds meer te maken hebben met volwassen producten is al vele malen en gedurende vele jaren aangetoond dat het product werkt. Het gaat om de haalbaarheid bij de klant, in zijn situatie, binnen zijn randvoorwaarden (geld, architectuur, gebruikers et cetera).
Om die reden spreek ik liever over een Proof of Product. Het uitgangspunt is dat de applicatie werkt (uiteraard bij standaard producten) en dat de organisatie weet wat ze wil. Eén van de belangrijke redenen voor het houden van een PoP is: het kunnen achterhalen van de benodigde (soms verborgen) functionaliteiten die voor jouw organisatie van belang zijn. Veel doorontwikkelde producten zoals enterprise search engine software of document management systemen bestaan tegenwoordig uit 1001 functionaliteiten.
Bij een PoP kies je uit de functionaliteiten van de applicatie, de voor jouw organisatie belangrijkste onderdelen (knockout criteria en bijzondere features) en zegt tegen de leverancier wat je wilt zien, op welke manier en binnen welke tijd. Liefst doe je dat tegen een aantal leveranciers tegelijkertijd zodat je heel precies kunt zien en meten wat de leveranciers kunnen en doen. Meestal doorkruist dat het 'normale' patroon van de leverancier en komt het voor hen aan op snel creatief kunnen schakelen, je maakt er een soort competitie van tussen de leveranciers.
Waarom is dat nodig? Een pakketselectie van een standaard product is voor de gemiddelde afnemer een ware jungle waarin je eenvoudig door de bomen het bos niet meer ziet. Bij een PoC zal de leverancier alleen dat laten zien dat eenvoudig en snel te realiseren is binnen zijn applicatie. Sterker nog, in veel gevallen ligt de PoC van een vorige klant nog op de plank en wordt deze zo doorgeschoven. Veel meer dan constateren dat de applicatie werkt mag je niet verwachten.
Een software leverancier zal proberen in eerste instantie een uitgekleed pakket te verkopen. Daarmee blijft de prijs relatief laag, hoge kortingen worden weggegeven aan het einde van het kwartaal, de klant kan starten en de concurrentie heeft het nakijken. Als de klant het pakket heeft gekocht en wil uitbreiden gaat de geldstroom pas echt op gang komen. Dan worden immers de extra functionaliteiten aangeschaft en dan is de korting over.
Bij een PoP zal de leverancier extra werk moeten verrichten om aan jouw specifieke vereisten te voldoen. Daar hangt dan vaak een prijskaartje aan van enkele duizenden euro’s, maar dat blijkt in nagenoeg alle gevallen meer dan verwachte opbrengsten te genereren. Leveranciers vallen vaak tijdens de PoP door de mand omdat ze toch niet de juiste mensen en attitude hebben om de wedstrijd aan te gaan. De standaard functionaliteit blijkt vaak toch nét niet helemaal standaard (ook als je de omstandigheden vooraf heel nauwkeurig hebt gedefinieerd), wat kan leiden tot problemen (niet tijdig kunnen leveren, niet alles kunnen leveren e.d.).
Daarin schuilt dan ook de kracht van een PoP, je komt heel snel te weten welke leverancier je in de toekomst wel en niet zal kunnen helpen bij je probleem, wie heeft het product goed onder de knie, wie is creatief. Allemaal zaken die je liever weet voordat je een handtekening hebt gezet onder een contract zodat je achteraf niet met een minder geslaagde aankoop of zelfs miskoop zit.
Uiteraard vraagt dit van jou als opdrachtgever ook een en ander, jij moet immers de lead nemen. Wat moet je doen:
1) doe een grondige requirements analyse (Je moet goed weten wat de organisatie wil);
2) de technische en organisatorische randvoorwaarden in kaart brengen (op welk platform en wie kan in het project meedraaien);
3) definieer vooraf goed wat je belangrijk vindt om te zien, meestal de knockout criteria en een paar special features (niet standaard functionaliteit);
4) bepaal hoe je de prestaties van de leveranciers gaat meten (beschrijf de criteria);
5) nodig leverancier(s) uit , leg uit wat je wilt, binnen welk tijdsbestek en op welke criteria afgerekend wordt;
6) meet de resultaten en analyseer deze met alle betrokkenen;
7) maak de keuze voor leverancier en product.
Kortom, projectleiders en opdrachtgevers, stap af van de traditionele Proof of Concept en neem de proef op de som door zelf een Proof of Product in het stappenplan op te nemen. Kijk hoe de leveranciers reageren, het geeft je een goede indicatie van de verwachtingen die je mag hebben over het toekomstige product en de relatie. Als leverancier en afnemer hier samen doorheen komen is een gezonde basis gelegd voor een succesvolle samenwerking.
Beste Anja,
Ik kan het verschil tussen jouw voorstel, PoP en PoC niet snel vinden! Ik lees dat je bij een PoC de leverancier en zijn product als de leider van het proces positioneert(klant kijkt toe) en bij PoP de klant! Met andere woorden het verschil zit in de aanpak en uitvoering.
Maar wie zegt dat bij een PoC de leverancier de leider van het proces is? Als je als klant een PoC, professioneel aanpakt dan zie je geen verschil tussen jouw voorstel, PoP en PoC!
De door jou benoemde (7) stappen zijn terecht en ook al bekend bij een professionele organisatie (of projectleider). Ik heb een opmerking over stap 6!
Stap 6: ik vind deze stap niet reëel! Een software gedrag zich in een test omgeving anders dan in de productie. Wanneer de software opgenomen is in het applicatielandschap (met de benodigde koppelingen van/naar software), wanneer de software compleet in de productie netwerk, hardware, gebruikers opgenomen is en door verschillende pakketten en meer gebruikers benaderd wordt dan kun je pas de prestatie van het pakket zien en meten. Daarom denk ik dat je in test fase geen waarde aan deze meting kan hechten.
Ik mis verder een belangrijke stap in je aanpak!
Stap 8: Een bezoek brengen aan een referentie wanneer je van long list naar short list gaat!
Door een bezoek brengen aan een referentie kun je zien hoe het pakket nu functioneert, hoe het met de support, klantvriendelijkheid en kennis van leverancier gaat, hoe de implementatie verlopen is (welke problemen zich voorgedaan hebben, hoe ze opgelost zijn en hoe de leverancier met dit soort onverwachte gebeurtenissen omging) en bij afsluiting van je bezoek, stel de vraag aan de betreffende referentie: “ met de kennis van nu, had je toen ook voor deze leverancier en pakket gekozen?”
Ik denk dat je nu als klant makkelijker verder een keuze kan maken uit de leveranciers van je PoC`s.
Goedemiddag Anja,
Heb met interesse je artikel gelezen en zie daarin een aantal dingen niet terug. Het verschil tussen het aantonen van functionaliteit en capaciteit van standaard pakketten versus ontwikkelplatformen. In die laatste situatie kun je moeilijk zaken van de plank trekken en zal het echt aankomen op het bewijzen van de capaciteiten van het ontwikkelplatform, iedere situatie en vereisten zijn immers nieuw.
Daarnaast ben ik het volledig oneens dat de meeste pakketten dermate volwassen zijn dat ze wel kunnen leveren wat ze vooraf beloven. Wat doen die geweldig negatieve statistieken dan ieder jaar in de media? Juist de volwassenheid ontbreekt in het product of de manier waarop de finesses moeten worden aangebracht. Daarin is volgens mij nog ontzettend veel te winnen!
Een mening delen we zeker! Het feit dat pakketten 1001 functies leveren en je soms af moet vragen of een pakket wel het juiste uitgangspunt is, of dat maatwerk een veel slimmere optie is in aanschaf en beheer.
De holle frase ‘buy over build’ gaat de laatste jaren steeds minder op als het gaat over product acceptatie en total cost of ownership.
Als je ‘kijken naar het complete plaatje’ bedoelt met PoP, ga ik geheel met je mee.
Vriendelijke groet,
Mark
Volgens mij sluit een POC een POP niet uit.
Met een POC laten leveranciers zien dat hun pakket zou moeten kunnen wat jij denkt nodig te hebben.
Op basis van de diverse POC-demo’s van de leverancier ga je vervolgens met één of meerdere leveranciers een pilot project uitvoeren in een (Semi-) real life omgeving, dat wat jij de POP noemt.
Vergelijk het met productontwikkeling: je zet eerst een concept neer om te laten zien wat je wil/kunt maken. Is de klant hiermee tevreden, dan ga je het concept verder uitwerken tot een product.
@PaVaKe,
Ergens heb je gelijk in! Afhankelijk van het product of dat een standaard product is of een maatwerk dan zou je de door jou benoemde fases kunnen doorlopen. In dit artikel wordt soms naar standaard product verwezen terwijl sommige zaken verderop meer bij het selectren van een maatwerk behoren!(zo lees ik het)
Zoals je weet bij een standaard product heb je geen tot weinig ruimte om het pakket aan de verschillende eisen van de klant aan te passen. Hierdoor vervalt een deel of totale uitwerking van het concept tot eindproduct.
Het ontwikkelen van een concept tot een eindproduct zie ik ook als een integrale fase binnen je PoC-aanpak.
@Reza:
Je stelt:
“Zoals je weet bij een standaard product heb je geen tot weinig ruimte om het pakket aan de verschillende eisen van de klant aan te passen. Hierdoor vervalt een deel of totale uitwerking van het concept tot eindproduct.
Het ontwikkelen van een concept tot een eindproduct zie ik ook als een integrale fase binnen je PoC-aanpak.”
Dit is denk ik heel erg product specifiek, waardoor dit eigenlijk geen “eerlijke” discussie is.
Pak een product als sharepoint. Op zich een standaard product, waarbinnen je heel veel kunt configureren.
Op papier (het POC) lijkt het product te kunnen wat ik er mee wil, de demo’s zien er goed uit.
Ga ik in detail een pilot doen (POP) dan blijkt dat die ene manier van werken die wij gebruiken niet kan, of dat de koppeling met ons systeem Y niet mogelijk is omdat ….
Het product pas ik niet aan, maar ook de diverse configureerbare mogelijkheden van een product kun je benaderen via de POC/POP methodiek.
Beste Anja, onder enigzins andere namen zijn jouw PoC en PoP door grote organisaties toegepast. Dit is uitgebreid beschreven in mijn “Whitepaper: Design Contest Tender – A Guide for Innovative Procurement”. Misschien goed om dit eens in Computable op te nemen…
POC/POP/PILOT, de gemeenschappelijke deler is de P en daar houd het mee op.
Ik zou zeggen terug naar de tekentafel en eerst bepalen waar je mee bezig bent. Is dit een new buy, straight rebuy of modified rebuy proces? Dus koop je functionaliteit voor de eerste keer of is het een vervangingstraject?
Een POC komt meestal voor in een new buy proces, dus de organisatie gaat voor de eerste keer functionaliteit inkopen conform het concept van de aanbieder. Een POC dient er dan voor om aan te tonen dat het concept werkt in de omgeving van de klant. Vaak neemt een leverancier het initiatief voor een POC omdat er een bepaalde mate van zekerheid moet worden verkregen voor het eindresultaat. Denk bijvoorbeeld aan het automatische scannen en betalen van boodschappen zonder te betalen. In de fabriek werkt het, maar ook in de supermarkt?
Een POP zie je vaak terug in vervangingsprojecten, dan is men al bekend met de functionaliteit en weet men wat men wil. Ook hier kan de leverancier een grote rol spelen en zelfs afspraken maken tegen aanvaardbaar lage kosten.
Pilots zijn POC of POP in productieomgevingen met een beperkte gebruikersgroep. Dit is vaak een taak voor de organisatie.
Dus: doe een POC bij new buy trajecten en een POP bij vervangingstrajecten en haal ze vooral niet door elkaar.
Beste allemaal,
Dank voor jullie reacties op mijn blog. In de meeste opmerkingen kan ik mij prima vinden. Het verschil in benadering is voornamelijk gelegen in de technische versus de meer klantgeoriëteerde invalshoek. Ik tracht mijn blogs zo te schrijven dat ze voor een relatieve leek in een organisatie zonder IT-kennis houvast geven en informatie geeft waarmee zij in gesprek kunnen gaan met IT-ers.
In de praktijk kom ik bij de voortrajecten voor standaardpakketten alle aspecten tegen. Wij maken wel degelijk de resultaten van de PoP meetbaar omdat de omstandigheden waaronder de leveranciers hun product moeten bewijzen gelijk zijn en ze dus allemaal hetzelfde “nadeel” hebben; dat calculeer je dus in of maak je inzichtelijk.
Referentiebezoeken maken geen onderdeel uit van het proces om te komen van de shortlist naar de keuze van het pakket, dan ben je al te laat mijns inziens. Als je een bezoek wilt afleggen kan dat in de fase van longlist naar shortlist (kan onderdeel zijn van stap 4).
Terecht wordt in een aantal reacties gewezen op het onderscheid van standaardpakketten versus ontwikkelplatformen. Nadrukkelijk heb ik het in mijn blog over geschiktheid van een PoP voor standaardpakketten. Tevens wordt gewezen op PoC-demo’s die gedurende de trajecten vaak langskomen om een beeld te krijgen of de mogelijkheid om zowel een PoC als een PoP te doen. Mijn ervaring met demo’s is dat deze vaak niet veel afwijken van hetgeen de leverancier in een PoC neerzet, precies om die reden kies ik er niet voor dit in het projectplan op te nemen.
Fijn dat de geinteresseerden ook nog een aantal tips en leesvoer meekrijgen van jullie.
Tot de volgende keer.