Waarom een Proof-of-Concept?
Een PoC test of een specifiek platform de specifieke problemen van jouw organisatie daadwerkelijk oplost, met jouw eigen data en jouw eigen use cases — vóórdat je een langdurig contract aangaat of maanden aan implementatie investeert. Het doel is niet om het platform volledig te implementeren, maar om snel, goedkoop en met beperkt risico een onderbouwd go/no-go-besluit te kunnen nemen.
Het belangrijkste principe
Een PoC die te breed wordt opgezet, verliest zijn doel: in plaats van snel een besluit te onderbouwen, groeit hij ongemerkt uit tot een half afgemaakt productieproject, zonder de governance en architectuur die een echte implementatie wél zou krijgen.
De Vier Fasen van een PoC
1. Scope en Use Case Selectie (Week 1)
Kies 2-3 use cases die directe bedrijfswaarde aantonen, meetbare resultaten opleveren, en technisch haalbaar zijn binnen de PoC-periode. Meer use cases verdunnen de aandacht zonder het besluit te versterken.
2. Technische Opzet (Week 1-2)
Verbind het platform met een representatieve subset van échte data — niet schone voorbeelddata, die precies de datakwaliteitsproblemen verbergt die een PoC moet blootleggen.
3. Bouw en Test (Week 2-5)
Bouw de gekozen use cases daadwerkelijk uit, inclusief randgevallen (ontbrekende data, schema-afwijkingen, piekbelasting) — een PoC die alleen de happy path test, geeft een vertekend positief beeld.
4. Evaluatie en Besluit (Week 6)
Beoordeel tegen vooraf vastgestelde criteria (zie hieronder), niet achteraf verzonnen argumenten die toevallig bij de voorkeurskeuze passen.
Evaluatiecriteria: Stel Ze Vóóraf Vast
De meest voorkomende fout bij een PoC is pas achteraf bepalen waarop je beoordeelt. Stel in plaats daarvan vooraf criteria vast, bijvoorbeeld:
- Functioneel: lost het platform de gekozen use cases daadwerkelijk op, inclusief de geteste randgevallen?
- Performance: zijn queries/rapportages snel genoeg voor de daadwerkelijke datavolumes, niet alleen een kleine testset?
- Integratie: sluit het platform aan op bestaande databronnen en tools zonder bovenmatige custom-koppelingen?
- Beheerslast: hoeveel specialistische kennis is nodig om het platform te onderhouden na livegang?
- Kosten op schaal: wat kost het platform niet in de PoC, maar bij het volledige, verwachte gebruiksvolume?
- Gebruikersacceptatie: kunnen de daadwerkelijke eindgebruikers ermee werken, niet alleen het technische team?
Platformspecifieke Aandachtspunten
| Platform | Waar een PoC extra op moet letten |
|---|---|
| Power BI | Licentiemodel (Pro vs Premium) bij het verwachte aantal gebruikers; DAX-complexiteit bij geavanceerde berekeningen. |
| Tableau | Servergebruik en beheerslast bij zelf-hosten versus Tableau Cloud; licentiekosten per gebruiker op schaal. |
| Qlik Sense | Het associatieve datamodel (anders dan de meeste concurrenten) vraagt een eigen leercurve — test dit expliciet met eigen data-analisten. |
| Looker | LookML (de modelleertaal) vereist meer initiële technische investering dan drag-and-drop-tools — weeg dit mee in de PoC-tijdlijn. |
| Databricks | Clusterconfiguratie en -kosten testen onder realistische workload, niet alleen een klein interactief cluster. |
| Snowflake | Warehouse-sizing en auto-suspend-instellingen direct meenemen in de kostenevaluatie — een verkeerd ingestelde warehouse vertekent de PoC-kosten. |
| Microsoft Fabric | Capaciteitseenheden (CU's) zijn gedeeld over alle workloads — test met een realistische mix van gelijktijdige belasting, niet één werklast geïsoleerd. |
Veelgemaakte Fouten
- Te veel use cases tegelijk testen, waardoor geen enkele use case grondig genoeg wordt getest om een besluit op te baseren.
- Alleen schone, opgeschoonde testdata gebruiken, waardoor datakwaliteitsproblemen die in productie wél optreden onopgemerkt blijven.
- Evaluatiecriteria pas achteraf vaststellen, wat de deur openzet voor bevestigingsbias richting de reeds gewenste uitkomst.
- Kosten alleen op PoC-schaal beoordelen, zonder te extrapoleren naar het daadwerkelijke productievolume.
- Eindgebruikers pas na de PoC betrekken, terwijl hun acceptatie een van de belangrijkste succesfactoren is voor de uiteindelijke implementatie.
Conclusie
Een goed opgezette PoC is scherp begrensd: twee tot drie representatieve use cases, echte (of realistisch gesynthetiseerde) data, vooraf vastgestelde evaluatiecriteria, en een harde tijdlijn van 4-8 weken. De platformspecifieke aandachtspunten hierboven bepalen waar je binnen die structuur extra scherp op moet letten, maar de onderliggende methodiek — scope, fasering, criteria, evaluatie — is voor elk platform hetzelfde.
Overweeg je een proof-of-concept voor een nieuw dataplatform, en wil je hulp bij de opzet of uitvoering? Neem contact op — ik denk graag mee over scope en evaluatiecriteria die passen bij jouw organisatie.
Veelgestelde vragen
Hoe lang moet een dataplatform-PoC duren?
Typisch 4 tot 8 weken. Korter is vaak te weinig tijd voor echte productiedata en randgevallen; langer laat een PoC ongemerkt uitgroeien tot een productieproject zonder bijbehorende governance.
Hoeveel use cases moet je testen?
Twee tot drie, niet meer — elke extra use case verdunt de aandacht en vertraagt het go/no-go-besluit.
Moet een PoC met echte productiedata werken?
Bij voorkeur met een representatieve subset van echte of realistisch gesynthetiseerde data — schone voorbeelddata verbergt precies de problemen die een PoC moet blootleggen.