Definitie
POC staat voor Proof of Concept: een kleine, afgebakende uitvoering waarmee wordt aangetoond dat een idee of techniek in de praktijk werkt. Een POC heeft een duidelijke vraag (werkt deze koppeling, is dit algoritme snel genoeg, accepteert de klant deze interface) en levert een ja-of-nee-antwoord, geen eindproduct.
Het verschil met een MVP: een MVP is een echte eerste versie waarmee gebruikers werken. Een POC is een experiment voor intern gebruik, vaak weggegooid na afloop. Het doel is leren, niet leveren.
Waarom het ertoe doet voor MKB
Voor MKB-bedrijven die een grotere software-investering overwegen, voorkomt een POC dat tienduizenden euro’s worden uitgegeven aan iets dat achteraf niet blijkt te werken. In plaats van een groot project starten op basis van een leveranciers-demo, levert een POC binnen enkele weken hard bewijs dat het in de eigen situatie doet wat beloofd is.
De terugverdientijd zit niet in het bouwen van de POC zelf, maar in het vermijden van een mislukte hoofdinvestering. Een POC van €8.000 die voorkomt dat een ERP-traject van €120.000 in de tweede helft alsnog wordt afgeblazen, is in feite een verzekering.
Concreet voorbeeld
Een familiebedrijf in metaalbewerking overwoog een AI-oplossing voor automatische kwaliteitscontrole van geproduceerde onderdelen. De leverancier claimde 95% detectie van fouten. Volledige uitrol zou €180.000 kosten over twee productielijnen.
In plaats daarvan werd eerst een POC opgezet: vier weken doorlooptijd, €11.000 budget, op een enkele productielijn met camera en geleverd algoritme. Resultaat: detectie kwam op 78% in plaats van 95%, omdat het materiaal in de eigen fabriek meer variatie had dan in de demodataset. Op basis daarvan is een aangepast contract onderhandeld met een resultaatsverplichting, en is de uitrol uiteindelijk met een ander algoritme gerealiseerd dat wel boven de 90% kwam. De POC heeft naar schatting €60.000 aan teleurstelling en herwerk bespaard.
Misverstanden en valkuilen
- “Een POC kost weinig dus altijd doen.” Een POC zonder duidelijke onderzoeksvraag is verspilde tijd. Wat moet bewezen worden, en wat is het ja-en-nee-criterium, hoort vooraf vastgelegd te zijn.
- “Een geslaagde POC betekent direct uitrollen.” Een POC test een idee in een gecontroleerde omgeving. Productieklaar maken (beveiliging, schaal, integratie, support) vraagt vaak vijf tot tien keer zoveel tijd als de POC zelf.
- “De POC mag rommelig zijn, het wordt toch weggegooid.” Een POC moet wel representatief zijn voor de eigen situatie. Met perfecte testdata aantonen dat iets werkt, levert geen geldig bewijs voor de eigen praktijk.
- “De leverancier doet de POC en wij wachten af.” Een POC waarbij de eigen organisatie niet betrokken is, levert weinig leerwaarde op. Juist de eigen werknemers moeten ermee aan de slag om de echte vraag (past dit bij ons) te beantwoorden.
Wanneer moet je hiervan wakker liggen, wanneer niet
Wakker liggen: als jouw bedrijf op het punt staat een grote software-investering te doen op basis van een leveranciers-demo of een algemene business case. Demos worden altijd in optimale omstandigheden gehouden, je eigen situatie is dat zelden. Een POC vooraf is dan goedkoop verzekeringsgeld, zeker bij investeringen boven de €50.000.
Niet wakker liggen: als de oplossing een bewezen standaardpakket is dat bij vele vergelijkbare bedrijven al draait. Een POC voor een SaaS-boekhoudsysteem heeft weinig zin, daarvoor zijn referenties en proefperiodes het juiste instrument. POC’s horen bij nieuwe technologie of bij maatwerk, niet bij commodity-software.
Gerelateerde termen
- MVP: de logische vervolgstap na een geslaagde POC.
- Build vs buy: een POC helpt bij de afweging tussen zelf bouwen en kopen.
- Maatwerk software: bij maatwerktrajecten is een POC vaak verstandig voorwerk.
- Agile: POC’s passen binnen een iteratieve werkwijze.
- Sprint: een POC wordt vaak in een of twee sprints opgeleverd.
- TCO: een POC geeft betere input voor een realistische TCO-berekening.