Docs

Verificatie

Heeft het buiten het lab gewerkt?

Een technologie slaagt voor haar pilot. De resultaten zijn goed, het rapport is positief, de certificering is in orde. Ze wordt ingekocht en gedeployd.

Dan komt ze omstandigheden tegen die niemand heeft getest. Operators onder tijdsdruk in plaats van een betrokken projectteam. Integratie met systemen die nooit deel van de pilot waren. Gedegradeerde stroom, slechte connectiviteit, interferentie, kou, stof, belasting. Een tegenstander die zich anders gedraagt dan in het testscenario. Binnen enkele maanden wordt om de capaciteit heen gewerkt die in de pilot wel functioneerde.

De meeste betrokkenen hebben hun werk correct gedaan. De pilot liet zien wat hij ontworpen was om te laten zien. Het probleem is dat men hem iets anders liet bewijzen: dat de capaciteit werkt waar ze nodig is.

Dat is het probleem dat we met verificatie bedoelen. Capaciteiten worden routinematig gedeployd op basis van bewijs dat elders, onder andere omstandigheden en vaak door iemand met belang bij het resultaat is verzameld. Totdat een capaciteit heeft laten zien dat ze werkt waar ze nodig is, rust de deployment op een aanname.

Onze positie is eenvoudig te formuleren. Gevalideerd is niet gedeployd. Bewijs is een eigenschap van een capaciteit onder benoemde omstandigheden, en het is slechts zo sterk als de omstandigheden waarin het is verzameld.

Een geslaagde pilot bewijst de pilot

Pilots zijn ontworpen om te slagen. Dat is geen cynisme; zo worden ze opgezet. De scope is beperkt, het team is gemotiveerd, de leverancier is nauw betrokken, de omgeving is voorbereid en problemen worden opgelost wanneer ze opduiken.

Dat maakt een pilot een goede test van de vraag of iets kan werken. Het maakt hem een slechte test van de vraag of het zal werken wanneer de leverancier afstand neemt, het oorspronkelijke team verdergaat en de capaciteit binnen gewone operations moet draaien.

De kloof tussen beide is bekend. In innovatiebeleid wordt ze vaak de “valley of death” genoemd: het traject tussen een veelbelovend resultaat en een gedeployde capaciteit, waar veel initiatieven stoppen. De gebruikelijke reactie is meer financiering voor meer pilots. Dat levert meer veelbelovende resultaten op, en dezelfde vallei.

Wat ontbreekt is zelden nog een pilot. Het is een manier om bewijs te verzamelen onder de omstandigheden waarmee de capaciteit werkelijk te maken krijgt.

Verificatie en validatie zijn verschillende vragen

Systems engineering maakt al lang onderscheid tussen twee vragen die gemakkelijk door elkaar lopen.

Verificatie vraagt of het systeem juist is gebouwd: doet het wat de specificatie zegt? Validatie vraagt of het juiste systeem is gebouwd: doet het wat gebruikers werkelijk nodig hebben, in de omgeving waar ze het nodig hebben? Standaarden zoals IEEE 1012 behandelen beide terecht als verschillende activiteiten.

Een capaciteit kan voor verificatie slagen en voor validatie falen. Ze voldoet op papier aan elke eis en werkt toch niet voor de mensen en omstandigheden waarvoor ze is aangeschaft, omdat de eisen zelf voor een schonere wereld zijn geschreven.

Wij gebruiken “verificatie” in de brede betekenis waarin mensen buiten engineering het woord gebruiken: met bewijs vaststellen dat een capaciteit werkt waar ze bedoeld is te werken. Dat omvat beide vragen. Alleen de eerste beantwoorden is hoe systemen gecertificeerd en ongebruikt eindigen.

Readiness levels meten volwassenheid, niet geschiktheid

Technology Readiness Levels zijn een nuttige gemeenschappelijke taal. Ze beschrijven hoe ver een technologie is gekomen, van basisprincipes tot een systeem dat in zijn operationele omgeving is bewezen. Europese onderzoeksprogramma’s gebruiken ze om te beschrijven waar een project begint en waar het moet eindigen.

Ze zijn ook gemakkelijk te ruim te lezen. Een readiness level zegt hoe volwassen een technologie langs een algemeen pad is. Het zegt niet of ze past bij de omstandigheden, systemen en mensen van een specifieke instelling. Een systeem dat in “an operational environment” is gedemonstreerd, is in één operationele omgeving gedemonstreerd, niet noodzakelijk in de uwe.

Daarom behandelen we een readiness level als het begin van een gesprek over bewijs, niet als het einde. De volgende vraag is altijd dezelfde: waar gedemonstreerd, onder welke omstandigheden, en hoe dicht liggen die bij de onze?

De omgeving is onderdeel van de test

Waar een capaciteit wordt getest bepaalt wat de test kan aantonen. Een laboratorium kan prestaties onder gecontroleerde omstandigheden vaststellen. Het kan niet vaststellen hoe de capaciteit zich gedraagt onder de omstandigheden die echte operations moeilijk maken.

Verschillende omgevingen leggen verschillende soorten falen bloot. Een geïsoleerde of geharde omgeving test wat gebeurt wanneer support, connectiviteit en supply wegvallen. Een live maritieme omgeving test blootstelling aan weer, corrosie, afstand en de moeilijkheid van fysieke toegang. Een omgeving die een bestuurlijke of nationale grens kruist test of bevoegdheid, procedures en overdrachten werken wanneer dat nodig is. Een gewoon kantoor of een cloudtestomgeving test geen van deze dingen.

Daarom behandelen we de testomgeving als een instrument op zichzelf. De keuze ervan is een ontwerpbeslissing: zij bepaalt welke faalcondities kunnen worden geoefend en dus welke claims het resultaat kan ondersteunen.

Elk resultaat heeft voorwaarden

Een testresultaat dat zijn voorwaarden niet vermeldt nodigt uit om verder te worden gegeneraliseerd dan gerechtvaardigd is.

Voor elk verificatieresultaat willen we ten minste weten: wat is getest, in welke configuratie, in welke omgeving, door wie, onder welke omstandigheden, hoe lang, wat is gemeten, wat gebeurde en wat bewust niet is meegenomen. Het laatste item ontbreekt het vaakst en is het belangrijkst voor de volgende koper.

Een smal resultaat dat zijn grenzen vermeldt is bruikbaar. Men kan erop vertrouwen, het vergelijken en erop voortbouwen. Een brede claim zonder voorwaarden kan alleen worden geloofd of niet.

Dit is dezelfde discipline die voor resilienceclaims geldt. Een resultaat binnen één envelope bewijst niets daarbuiten. Zie Veerkracht.

Negatieve resultaten zijn bewijs

Tests die falen vertellen ons minstens zoveel als tests die slagen. Ze laten zien waar de grenzen van een capaciteit werkelijk liggen, met welke omstandigheden ze niet kan omgaan en welke aannames in het ontwerp niet standhielden.

Het zijn ook de resultaten die het waarschijnlijkst verdwijnen. Leveranciers hebben weinig reden ze te publiceren. Kopers willen misschien niet toegeven dat een aanbesteding mislukte. Programma’s worden beoordeeld op succesverhalen.

Wij behandelen gedocumenteerd falen als onderdeel van de evidence base. Een verificatiedossier met alleen geslaagde tests beschrijft óf een capaciteit die nooit tot haar grenzen is geduwd, óf laat iets weg.

De koper moet kunnen oordelen

Het meeste verificatiebewijs bereikt een instelling via iemand met belang bij de uitkomst: een testrapport van de leverancier, een certificering die door de vendor is verkregen, een referentie van een andere klant. Geen daarvan is waardeloos. Geen daarvan is onafhankelijk.

Een instelling die zulk bewijs niet kritisch kan lezen heeft geen manier om een sterke claim van een goed gepresenteerde te onderscheiden. Zij kan niet vragen welke omstandigheden zijn getest, of die overeenkomen met de eigen omstandigheden, of wat buiten beschouwing bleef. Ze koopt het label.

Hier hangt verificatie af van oordeelsvermogen. De koper heeft mensen nodig die bewijs van anderen kunnen beoordelen en om het bewijs kunnen vragen dat de vraag werkelijk zou beslissen. Die capaciteit moet binnen de instelling bestaan, niet alleen bij haar adviseurs. Zie Capaciteitsoverdracht.

Van pilot naar infrastructuur

Het eindpunt van verificatie is geen rapport. Het is een capaciteit die de instelling zelf exploiteert, onder haar eigen omstandigheden, met bewijs dat ze daar werkt.

Veel initiatieven eindigen bij de pilot omdat de financiering eindigt. Het resultaat is een demonstratie die niemand uitvoert. Wij behandelen een pilot als één stap in een langere volgorde: test onder gecontroleerde omstandigheden, daarna onder de omstandigheden die ertoe doen, daarna in operatie door de mensen die ermee zullen werken, met het bewijs bij elke stap vastgelegd.

Dat is de Operations-discipline in De volgorde: geïmplementeerd, getest onder echte omstandigheden en omgezet in iets dat onafhankelijk en duurzaam functioneert nadat het initiatief dat het creëerde is afgelopen.

Hoe we er samen aan werken

Ons werk rond verificatie begint bij de omstandigheden waarmee de capaciteit te maken zal krijgen, niet bij de capaciteit zelf.

Benoem de operationele omstandigheden. Spreek af waar en hoe de capaciteit werkelijk zal worden gebruikt, inclusief de omstandigheden die niemand graag plant.

Lees het bestaande bewijs. Stel vast wat is aangetoond, waar, onder welke omstandigheden en wat buiten beschouwing bleef.

Ontwerp de test rond de kloof. Kies een omgeving en scenario’s die de omstandigheden oefenen die het bestaande bewijs niet dekt.

Leg het resultaat met zijn voorwaarden vast. Inclusief wat faalde en wat niet is getest.

Laat het vermogen om te oordelen achter. De instelling moet eindigen met mensen die de volgende leveranciersclaim, het volgende testrapport of de volgende certificering zelf kunnen beoordelen.

Wanneer we samen met een partner naar een capaciteit kijken, werken we doorgaans deze vragen door:

Vraag Wat ze zichtbaar maakt
Waar, en onder welke omstandigheden, wordt dit werkelijk gebruikt? Wat het bewijs moet dekken.
Wat is tot nu toe aangetoond, en waar? De werkelijke omvang van het bestaande bewijs.
Wie produceerde dat bewijs, en met welk belang? Hoeveel onafhankelijk gewicht het heeft.
Welke omstandigheden zijn nooit getest? De kloof die een nieuwe test moet sluiten.
Welke omgeving kan die omstandigheden oefenen? Of de test de claim kan ondersteunen.
Wat faalde, en wat bleef buiten beschouwing? De grenzen van het resultaat.
Wie zal het exploiteren, en hebben zij het zelf getest? Of de pilot infrastructuur kan worden.

Waar we voorzichtig zijn

We houden ons aan enkele toezeggingen over wat we claimen.

We generaliseren een resultaat niet verder dan de omstandigheden waarin het werd verkregen.

We behandelen een readiness level, certificering of leveranciersrapport niet als bewijs dat een capaciteit in een specifieke omgeving werkt.

We presenteren testomgevingen niet als resultaten. Een omgeving maakt sterker bewijs mogelijk; ze is op zichzelf geen bewijs.

We laten mislukkingen niet uit het dossier.

En we beschrijven een capaciteit niet als bewezen zonder te benoemen waar, onder welke omstandigheden en door wie.

Verder lezen

Gerelateerde thema’s: Veerkracht · Capaciteitsoverdracht · Vroege waarschuwing

Wijzigingen in deze positie

  • 24 september 2026 — Voor het eerst gepubliceerd.

Materiële wijzigingen worden hier met datum vermeld. Correcties van formulering of links worden niet opgenomen.