Hoe bewijs je een vaardigheid? Een model met 6 niveaus van bewijs

Een Skills First-benadering verschuift de aandacht van formele labels naar competenties die iemand daadwerkelijk kan aantonen. Daarmee is het probleem van beoordeling echter niet automatisch opgelost.

De OECD beschrijft skills-first als een aanpak waarbij werving en talentmanagement zo worden ingericht dat mensen worden beoordeeld op aangetoonde vaardigheden. Het rapport wijst ook op de noodzaak van geschikte beoordelingsinstrumenten en competentiekaders. [1]

Een langere "Skills"-sectie in plaats van "Education" is dus niet genoeg. We hebben ook een betere manier nodig om uit te leggen waarom een competentieclaim geloofwaardig is.

Twee mensen kunnen precies dezelfde competentie vermelden en toch totaal verschillende praktijkervaring hebben.

Stel je twee specialisten voor die allebei aangeven:

Angular - gevorderd

De eerste heeft een cursus afgerond, enkele eigen projecten gebouwd en kent de basis van het framework.

De tweede werkt al drie jaar aan een productieapplicatie, is verantwoordelijk geweest voor de architectuur van een deel van het systeem, heeft migraties tussen Angular-versies uitgevoerd en kan concrete resultaten van dat werk aanwijzen.

Op een traditionele skillslijst kunnen ze erg op elkaar lijken.

Pas bewijs in context maakt het echte verschil zichtbaar.

Het model is niet bedoeld om mensen één universele score te geven. Verschillende beroepen leveren verschillende soorten bewijs op en niet elk project kan openbaar worden getoond.

Het model beantwoordt een eenvoudigere vraag:

hoe sterk is het materiaal waarop we baseren dat een bepaalde competentie geloofwaardig is weergegeven?

Het eenvoudigste niveau is de eigen verklaring van de gebruiker.

Voorbeelden:

• Angular
• Figma
• SEO
• teamleiding
• B2B-onderhandeling

Deze informatie is nuttig voor zoeken en ontdekken, maar de bewijskracht is beperkt.

We weten nog niet:

• waar de competentie is gebruikt,
• hoe lang,
• op welke schaal,
• met welke verantwoordelijkheid,
• met welk resultaat.

Een verklaring is het beginpunt, niet het einde van de beoordeling.

Bewijs wordt sterker wanneer we weten waar en in welke context de vaardigheid is gebruikt.

In plaats van:

Angular

krijgen we:

Angular gedurende 2 jaar gebruikt bij de ontwikkeling van een SaaS-applicatie voor de logistieke sector.

Dit bewijst nog niet de kwaliteit van het werk, maar geeft wel belangrijke context:

• een echt project,
• duur van het gebruik,
• toepassingsgebied,
• aard van de omgeving.

Op dit niveau is de vaardigheid niet langer alleen een label.

Het volgende niveau ontstaat wanneer verklaring en ervaring kunnen worden gekoppeld aan een echt werkproduct.

Afhankelijk van het beroep kan dat zijn:

• een werkende applicatie,
• een codevoorbeeld,
• een repository,
• een interfaceontwerp,
• een prototype,
• een rapport,
• een analyse,
• een campagne,
• een artikel,
• documentatie,
• een financieel model,
• een foto,
• een technisch ontwerp,
• een opname van uitgevoerd werk.

Het werkproduct beantwoordt een belangrijke vraag:

kunnen we iets zien dat daadwerkelijk met deze vaardigheid is gemaakt?

Dat betekent niet dat een portfolio een formele competentietest is. Onderzoek naar personeelsselectie laat wel zien dat methoden die dicht bij echte werkzaamheden staan, zoals work samples en beroepskennistests, nuttige voorspellers van werkprestaties kunnen zijn. De auteurs benadrukken ook dat resultaten moeten worden geïnterpreteerd met oog voor context, kosten en beperkingen van de methode. [2]

Ook een werkproduct kan een moeilijke vraag onbeantwoord laten:

wat heeft deze persoon precies gedaan?

Dat is vooral belangrijk bij teamprojecten.

Een applicatie kan door 20 mensen zijn gebouwd. Een campagne kan door een team van 8 mensen zijn uitgevoerd. Een rebranding kan een bureau, intern marketingteam en externe consultants hebben omvat.

Daarom is een sterker bewijs een case study die de individuele bijdrage duidelijk beschrijft.

Een goede case study scheidt minimaal:

• probleem of doel,
• totale projectomvang,
• persoonlijke verantwoordelijkheid van de specialist,
• werkelijk uitgevoerde acties,
• gebruikte competenties,
• samenwerking met anderen,
• resultaat.

In plaats van:

Ik bouwde een e-commerceplatform.

is beter:

Ik was verantwoordelijk voor de frontendarchitectuur, de checkoutimplementatie en de integratie van de betaalflow. Het project werd uitgevoerd door een team van vijf personen.

De tweede beschrijving is nuttiger omdat het werk van het hele team niet aan één persoon wordt toegeschreven.

Bewijs wordt nog sterker wanneer het werk tot een concreet resultaat leidt dat zonder vaagheden kan worden beschreven.

Voorbeelden:

Frontend
Laadtijd van de hoofdweergave teruggebracht van 4,2 s naar 1,8 s.

UX
Minder uitval in het registratieformulier na herontwerp van de flow.

Marketing
Kosten per lead verlaagd met behoud van vergelijkbare verkeerskwaliteit.

Sales
Een nieuw klantsegment geopend en een bepaald aantal contracten gesloten.

Operations
Een proces teruggebracht van meerdere dagen naar enkele uren.

Niet elk beroep kan of moet resultaat in percentages of geld uitdrukken. Metrics moeten niet worden verzonnen alleen om een profiel indrukwekkender te maken.

De nuttige vraag is:

wat veranderde er door dit werk?

Het sterkste niveau ontstaat wanneer ten minste een deel van de informatie onafhankelijk van de eigen verklaring van de profieleigenaar kan worden geverifieerd.

Dat kan bijvoorbeeld zijn:

• een openbaar project,
• een repository met bijdragehistorie,
• een openbare publicatie,
• bevestigde deelname aan een project,
• een klant- of collegareferentie die rechtmatig mag worden gepubliceerd,
• een onafhankelijk bevestigbaar resultaat,
• een officiële kwalificatie wanneer die echt relevant is,
• een andere bron die concreet werk bevestigt.

Dit betekent niet dat elk project openbaar moet zijn.

Veel waardevolle projecten vallen onder NDA, bedrijfsgeheimen of andere geheimhoudingsplichten.

Gebrek aan openbaar bewijs betekent daarom niet gebrek aan competentie.

Het betekent alleen dat de onafhankelijke verifieerbaarheid lager is.

Niveau 1 - verklaring
Angular.

Niveau 2 - context
Angular gedurende 3 jaar gebruikt in SaaS-applicaties.

Niveau 3 - werkproduct
Een openbare applicatie, repository of ander werkvoorbeeld dat getoond mag worden.

Niveau 4 - individuele bijdrage
Verantwoordelijk voor de architectuur van geselecteerde modules, gedeelde componenten en migratie van de applicatie.

Niveau 5 - resultaat
Een optimalisatie verkortte de opstarttijd van de hoofdmodule van 4,2 s naar 1,8 s. De cijfers zijn illustratief.

Niveau 6 - verificatie
Resultaat en bijdrage kunnen aanvullend worden bevestigd via een openbaar project, wijzigingshistorie, referentie of andere onafhankelijke bron.

Twee bewijsstukken op hetzelfde niveau kunnen sterk verschillen in waarde. Vijf extra dimensies helpen bij de interpretatie.

1. Relevantie - heeft het bewijs echt betrekking op de competentie die wordt beoordeeld?

2. Actualiteit - wanneer is de competentie gebruikt en hoe belangrijk is recente ervaring in dit vakgebied?

3. Auteurschap en verantwoordelijkheid - weten we wat de persoon daadwerkelijk heeft gedaan?

4. Context - wat waren schaal, complexiteit, verantwoordelijkheid, middelen en werkomstandigheden?

5. Verifieerbaarheid - is er een onafhankelijke manier om ten minste een deel van de informatie te bevestigen?

Relevantie

Een project waarin een technologie slechts zijdelings werd gebruikt is zwakker bewijs dan een project waarin die competentie centraal stond.

Actualiteit

Het belang van recente ervaring verschilt per vakgebied. In sommige domeinen kan ervaring van tien jaar geleden nog steeds zeer waardevol zijn. In andere veranderen tools en werkwijzen zo snel dat recent gebruik veel belangrijker is.

Auteurschap en verantwoordelijkheid

Hoe groter project en team, hoe belangrijker het is om het totale resultaat te scheiden van de individuele bijdrage van de specialist.

Context

Hetzelfde resultaat kan anders worden gewogen afhankelijk van projectschaal, tijdsdruk, middelen, verantwoordelijkheid en complexiteit.

Verifieerbaarheid

Onafhankelijke verificatie is niet altijd mogelijk en hoeft niet altijd verplicht te zijn. Wanneer een onafhankelijke bron resultaat of bijdrage bevestigt, versterkt dat wel de geloofwaardigheid.

Iemand kan zijn of haar deel van een project uitstekend uitvoeren terwijl het project commercieel toch mislukt.

Iemand kan ook aan een zeer succesvol project werken en maar weinig invloed hebben gehad op het uiteindelijke succes.

Daarom is het nuttig drie zaken te scheiden:

1. Competentie
Kan de persoon een bepaald soort werk uitvoeren?

2. Bijdrage
Voor welk deel was de persoon werkelijk verantwoordelijk?

3. Resultaat
Wat veranderde er als gevolg van het werk?

De combinatie van deze elementen geeft een completer beeld.

Een certificaat of andere formele kwalificatie kan nuttig bewijs zijn, maar de waarde hangt af van wat het werkelijk bevestigt en hoe het is verkregen.

Het kan bijvoorbeeld bevestigen:

• voltooiing van training,
• behalen van bepaalde leeruitkomsten,
• slagen voor een specifieke beoordeling,
• kennis van een standaard,
• voldoen aan formele eisen.

De Europese Commissie beschrijft microcredentials als vastgelegde leeruitkomsten die via een korte leerervaring zijn behaald. De Europese aanpak legt onder andere nadruk op transparantie en kwaliteit. [3]

Een certificaat moet niet automatisch worden gelijkgesteld aan bewijs dat iemand zelfstandig complex werk in een echte professionele omgeving kan uitvoeren.

Een kwalificatie is daarom één mogelijk onderdeel van bewijs, waarvan de betekenis van de context afhangt.

Een project niet openbaar kunnen tonen mag waardevolle ervaring niet uitwissen.

Tegelijk hebben NDA’s, geheimhoudingsplichten, bedrijfsgeheimen, auteursrecht en gegevensbescherming voorrang op de wens om portfolio-werk te tonen.

Een specialist moet een project alleen beschrijven voor zover contracten, toepasselijk recht en rechten van andere personen en organisaties dat toestaan. Alleen de klantnaam weglaten is niet altijd voldoende als andere details het project, de klant, technologie, resultaten of vertrouwelijke methoden nog herkenbaar maken.

Wanneer openbaarmaking is toegestaan, kan het mogelijk zijn om te beschrijven:

• de branche op voldoende algemeen niveau,
• de aard van het probleem zonder vertrouwelijke informatie,
• de eigen rol en verantwoordelijkheid,
• gebruikte competenties,
• de schaal alleen voor zover toegestaan,
• het type resultaat zonder beschermde gegevens te publiceren,
• de aanpak op voldoende algemeen niveau.

Bij twijfel over publicatie is de veiligste keuze om de informatie niet te delen totdat het contract is gecontroleerd of toestemming van de rechthebbende is verkregen.

Een systeem voor competentiebewijs moet niet worden ontworpen alsof elk beroep softwareontwikkeling is.

Een designer kan proces, ontwerpbeslissingen, prototype en resultaat tonen.

Een developer kan product, code, architectuur of technische verantwoordelijkheid tonen.

Een marketeer kan campagne, aanpak, verantwoordelijkheid en verandering in resultaten beschrijven.

Een salesprofessional kan marktsegment, verkoopproces, eigen rol en resultaat beschrijven zonder vertrouwelijke klantgegevens te delen.

Een Project Manager kan projectomvang, werkorganisatie, beperkingen en invloed op levering tonen.

Een fotograaf kan uitgevoerd werk tonen zonder kunstmatige KPI’s te verzinnen.

Het model kan gemeenschappelijk zijn op principeniveau en flexibel in het type bewijs.

1. Controleer waar de competentie daadwerkelijk is gebruikt.

2. Zoek naar een werkproduct of een concreet uitvoeringsvoorbeeld.

3. Scheid de bijdrage van de specialist van het werk van het hele team.

4. Bekijk het resultaat wanneer dat zinvol kan worden beschreven.

5. Beoordeel actualiteit en hoe vergelijkbaar de eerdere ervaring is met het probleem dat je wilt oplossen.

6. Zoek onafhankelijke bevestiging wanneer dat mogelijk en passend is.

Zo verschuift de beoordeling van profielwoorden naar de echte match tussen aangetoonde competenties en een concrete behoefte.

Het model is bedoeld om informatie te structureren en menselijk oordeel te ondersteunen. Het moet niet worden behandeld als een automatisch oordeel over aannemen, afwijzen of het starten van een professionele samenwerking.

Niet elke competentie heeft bewijs op niveau 6 nodig.

Het is nuttiger om de belangrijkste skills door te nemen en te vragen:

• waar heb ik deze skill gebruikt?
• welk probleem loste ik op?
• wat heb ik precies gedaan?
• heb ik een werkproduct?
• wat was het resultaat?
• kan ik dit beschrijven zonder vertrouwelijkheid te schenden?
• kan iemand of een bron mijn bijdrage bevestigen?

Alleen al de stap van:

Figma - gevorderd

naar:

Ik ontwierp het onboardingproces van een B2B-applicatie en was verantwoordelijk voor research, prototyping, usabilitytests en het uiteindelijke designsysteem

verbetert de kwaliteit van de informatie voor de profielbezoeker duidelijk.

Een Skills First-benadering is alleen zinvol wanneer het woord "skill" meer betekent dan nog een tag.

Als competenties een belangrijke manier worden om specialisten te vinden en te vergelijken, moeten ze worden gekoppeld aan de best beschikbare context:

ervaring -> portfolio -> individuele bijdrage -> resultaat -> verifieerbaarheid.

Niet elke competentie zal het hoogste niveau bereiken, en dat hoeft ook niet.

Het doel is niet om verplichte bureaucratie rond elk profielonderdeel te creëren.

Het doel is specialisten te laten uitleggen waarom een competentieclaim geloofwaardig is en mensen die expertise zoeken beter geïnformeerde beslissingen te laten nemen.

1. Concreet in plaats van alleen verklaren - laat zien waar en hoe de competentie is gebruikt.

2. Individuele bijdrage in plaats van teamsucces - scheid je eigen werk van het resultaat van de hele organisatie.

3. Resultaat in plaats van takenlijst - laat waar mogelijk zien wat door het werk veranderde.

4. Context in plaats van alleen een getal - een metric zonder omstandigheden kan tot verkeerde conclusies leiden.

5. Verificatie waar mogelijk - onafhankelijke bevestiging verhoogt geloofwaardigheid, maar afwezigheid ervan maakt de competentie niet ongeldig.

Een professioneel profiel zou de lezer niet moeten laten raden wat er echt achter een lijst met vaardigheden zit.

Een verklaring maakt een competentie vindbaar. Bewijs maakt haar begrijpelijk.

De zes niveaus vormen een eenvoudige route:

1. Ik zeg dat ik het kan.
2. Ik laat zien waar ik het gebruikte.
3. Ik laat zien wat ik maakte.
4. Ik leg uit wat ik precies deed.
5. Ik toon het resultaat.
6. Ik maak onafhankelijke bevestiging mogelijk waar dat kan.

Hoe meer van deze vragen we kunnen beantwoorden, hoe minder we alleen op een verklaring hoeven te vertrouwen.

Dan wordt Skills First meer dan alleen een andere volgorde van informatie in een profiel.

[1] OECD - A Skills-First Labour Market: Promoting skills-first hiring and talent management, 2026
Bron openen

[2] Sackett, Zhang, Berry, Lievens - Revisiting the design of selection systems in light of new findings regarding the validity of widely used predictors, Cambridge University Press, 2023
Bron openen

[3] European Commission - A European approach to micro-credentials
Bron openen

Methodologische toelichting: bronnen [1]-[3] bieden bredere context over Skills First, competentiebeoordeling en kwalificaties. Het model met 6 niveaus van competentiebewijs zelf is een oorspronkelijk conceptueel model dat in dit materiaal wordt beschreven en wordt niet gepresenteerd als resultaat van deze publicaties.