Wie profiteert van een kennissysteem, en waarom dat antwoord verandert
Jair Emanuels
CCO & Co-founder bij Nodient
De helft van alle kennismanagement-initiatieven haalt de doelstelling niet. Dat cijfer komt uit een synthese van de KM-literatuur sinds eind jaren negentig (Frost, 2014). Het is geen meta-analyse en de auteur merkt zelf op dat het percentage hoger uitvalt zodra je ook projecten meetelt die technisch draaien maar niet worden gebruikt. Onder de zeven faalfactoren die hij onderscheidt staan er twee die hier ter zake doen: gebrek aan brede bijdrage, en gebrek aan relevantie, kwaliteit en bruikbaarheid.
Wat kost kennis die niemand terugvindt?
De kosten van niet-vindbare kennis zijn wel gemeten. APQC ondervroeg 982 fulltime kenniswerkers en vond dat zij gemiddeld 8,2 uur per week besteden aan het zoeken, opvragen en opnieuw maken van informatie die al bestaat, waarvan 2,0 uur aan puur herhaald werk (APQC, 2021). Je zou ervan uit kunnen gaan dat 2 uur eerder een onder- dan een overschatting is, omdat je alleen kunt rapporteren dat je dubbel werk hebt uitgevoerd als je achteraf ontdekt dat het al bestond. De gevallen waarin niemand daar ooit achter komt, zitten niet in het cijfer.
Interessanter dan de vraag of het loont, is de vraag voor wie. En sinds kort is het antwoord op die vraag in tweeën gesplitst.
Wat bepaalt of een systeem bruikbaar is?
Ferreira et al. (2025) onderzochten kenniswerkers in de industrie die zelf een persoonlijk kennissysteem in Obsidian hadden opgebouwd. Hun bevinding was dat de structuur van zo'n systeem volgt uit de verwachte terugvindstrategie. Wie zoekt via zoekopdrachten legt notities anders aan dan wie navigeert via interne links of tags. De auteurs adviseren daarom een minimale beginstructuur die meegroeit, plus een expliciete verwerkingsroutine zodat nieuwe input niet ongesorteerd blijft liggen.
Dat is het omgekeerde van hoe kennisbanken doorgaans worden ingericht, waar de indeling vaak vooraf wordt ontworpen door iemand die er zelf nooit mee aan de slag gaat. Frost noemt gebrek aan bruikbaarheid als faalfactor en Ferreira laat zien dat bruikbaarheid ontstaat uit zoekgedrag in plaats van uit vooraf ontworpen indelingen.
Een semi-systematische review van 149 peer-reviewed artikelen uit 1993 tot 2025 maakt daarnaast onderscheid tussen werk overnemen en werk ondersteunen, ofwel augmentatie (Litvinenko, 2026). Automatisering van expliciete kennis, zoals transcriptie en indexering, verhoogt efficiëntie en schaalbaarheid, met bias, ondoorzichtigheid en deskilling als gedocumenteerde risico's bij overmatig gebruik. Augmentatie, waarbij het systeem verbanden voorstelt en de mens beslist, ondersteunt adaptief leren maar is afhankelijk van datakwaliteit en training. Dit is tegelijk de sterkste en de vaagste bron in dit rijtje. Een review levert een denkkader op en geen cijfers waar je een business case mee bouwt.
Wat levert het op voor mensen?
Die cijfers zijn er wel voor het ondersteunende geval. Brynjolfsson, Li en Raymond (2025) volgden 5.172 klantenservicemedewerkers bij de gestaffelde invoering van een AI-assistent, aangevuld met een gerandomiseerde pilot. De assistent was getraind op de gesprekken van de best presterende collega's, dus in feite was kennis die tot dan toe in een kleine groep hoofden zat, beschikbaar gemaakt voor de rest. Het resultaat was gemiddeld 15 procent meer opgeloste zaken per uur bij gelijkblijvende klanttevredenheid.
De verdeling van dat effect zegt meer dan het gemiddelde. De winst zat vrijwel volledig bij de minst ervaren medewerkers, ruim 30 procent voor de onderste groep. De meest ervaren medewerkers wonnen nauwelijks tijd en leverden licht in op kwaliteit.
Bij softwareontwikkelaars gebeurt hetzelfde. Cui et al. (2026) deden gerandomiseerde experimenten bij Microsoft, Accenture en een Fortune 100-bedrijf en kwamen over 4.867 ontwikkelaars uit op 26 procent meer afgeronde taken. Ook daar zat de winst bij de minder ervaren groep, die het hulpmiddel bovendien sneller ging gebruiken.
De tegenhanger is minstens zo leerzaam. Becker et al. (2025) lieten zestien ervaren open source-ontwikkelaars 246 taken uitvoeren in hun eigen, volwassen codebases, waarbij per taak werd geloot of AI-hulp was toegestaan. Vooraf verwachtten zij 24 procent tijdwinst. Achteraf schatten zij dat ze 20 procent sneller waren geweest. Gemeten waren ze 19 procent langzamer. Opvallend is dat de zelfrapportage in geen van beide richtingen klopte, wat betekent dat vragen of mensen sneller werken geen bruikbare meting is.
Bij elkaar wijst dit één kant op. Waar iemand het domein nog niet kent, levert toegang tot andermans kennis winst op. Waar iemand het domein al in zijn hoofd heeft zitten, kost het raadplegen van een systeem meer dan het oplevert. Een kennissysteem maakt je beste mensen dus niet beter. Het zorgt ervoor dat de rest niet elke keer opnieuw hoeft uit te vinden wat zij al weten.
Dat is een reëel maar begrensd rendement. Het schaalt met instroom, verloop en inwerktijd, en niet met de omvang van je organisatie. Dit is precies de reden waarom veel bedrijven na een jaar concluderen dat het de moeite niet waard was.
Wat levert het op voor AI?
Die conclusie is sinds kort niet meer compleet, want er is een tweede lezer bijgekomen.
Bij alle studies hierboven gaat het om mensen die iets opzoeken. Bij AI-ondersteund werk verschuift die vraag, want dan is het model de partij die iets moet opzoeken, en dat model is volledig afhankelijk van wat je het aanreikt.
Dat effect is gemeten. In EDIT-Bench, een evaluatie van modellen op echte codebewerkingen, verschilt het slagingspercentage tot 11 procentpunt op basis van niets anders dan de hoeveelheid en het soort context die het model krijgt (Chi et al., 2025). Dezelfde taak en hetzelfde model zorgden voor een andere uitkomst. Onderzoek naar codewijzigingen op repositoryniveau wijst het terugvinden van de juiste context aan als een van de belangrijkste knelpunten, en laat zien dat simpelweg méér context aanbieden niet helpt zodra het model de relevante stukken er niet uit weet te halen.
Dat verandert wat een kennissysteem moet zijn. Bij het schrijven van een handleiding of ander document gaan we ervan uit dat een collega al kennis heeft. Denk aan wat het bedrijf doet, wie de CEO is en welke problemen het bedrijf heeft. Een AI-model werkt niet hetzelfde. Beslissingen die nergens staan, afspraken die alleen in iemands hoofd zitten en de reden waarom een werkwijze is zoals hij is, bestaan voor het model simpelweg niet.
Het patroon uit het vorige deel was dat de winst zit bij wie het domein nog niet kent. Een model kent je organisatie per definitie niet en zal haar ook nooit leren kennen. Het is elke sessie opnieuw de nieuwe medewerker op dag één.
De bevinding van Becker et al. krijgt hierdoor een andere betekenis. Ervaren ontwikkelaars werden langzamer in hun eigen, volwassen codebase, waar zij de context al in hun hoofd hadden en het model niet. Het verschil zit in wat er is vastgelegd, niet in de hulp zelf.
Waar gaan de meeste implementaties mis?
De besproken literatuur pleit niet tegen het opzetten van een kennissysteem, maar identificeert wel waar de meeste implementaties tekortschieten. De indeling wordt vooraf vastgesteld in plaats van afgeleid uit het feitelijke zoekgedrag van gebruikers. Daarnaast neemt het systeem taken over op punten waar ondersteuning van het menselijk oordeel meer had opgeleverd. Het betreft in beide gevallen ontwerpbeslissingen die voorafgaand aan de implementatie te maken zijn.
Wat de afweging structureel verandert, is dat een kennissysteem inmiddels twee categorieën gebruikers bedient met uiteenlopende eisen. De menselijke gebruiker is gebaat bij een lichte structuur en een hoge vindbaarheid, en vult ontbrekende context aan op basis van ervaring. Het taalmodel beschikt niet over die ervaring en is aangewezen op wat expliciet is vastgelegd. Een systeem dat uitsluitend op de eerste categorie is toegesneden, resulteert in documentatie die machinaal niet bruikbaar is. Een systeem dat alleen de tweede bedient, resulteert in een gegevensverzameling zonder eigenaar.
Het startpunt van een implementatie ligt niet bij de mappenstructuur of de tooling, maar bij twee vragen aan degenen die het werk uitvoeren. Op welke wijze wordt deze informatie teruggezocht wanneer zij over drie maanden opnieuw nodig is? En welke context zou een gebruiker nodig hebben die geen enkele voorkennis van de organisatie bezit en die ook niet zal verwerven? De antwoorden op beide vragen bepalen in belangrijke mate of de investering rendeert.
Veelgestelde vragen
Voor wie loont een kennissysteem het meest?
Voor wie het domein nog niet kent: nieuwe en minder ervaren medewerkers. In de onderzochte studies zat vrijwel alle winst bij die groep, tot ruim 30 procent. Ervaren mensen wonnen nauwelijks tijd. Het rendement schaalt dus met instroom, verloop en inwerktijd.
Waarom heeft een AI-model andere documentatie nodig dan een collega?
Een collega vult ontbrekende context aan uit ervaring. Een model heeft die ervaring niet en is elke sessie opnieuw de nieuwe medewerker op dag één. Beslissingen, afspraken en de reden achter een werkwijze moeten expliciet zijn vastgelegd, anders bestaan ze voor het model niet.
Waar moet je beginnen bij het opzetten van een kennissysteem?
Niet bij de mappenstructuur of de tooling, maar bij twee vragen aan de mensen die het werk doen: hoe zoeken zij deze informatie over drie maanden terug, en welke context heeft iemand nodig die de organisatie helemaal niet kent? Begin daarna met een minimale structuur die meegroeit.
Kun je meten of een kennissysteem werkt door het te vragen?
Nee. In het onderzoek van Becker et al. schatten ervaren ontwikkelaars dat ze 20 procent sneller waren, terwijl ze gemeten 19 procent langzamer waren. Zelfrapportage klopte in geen van beide richtingen. Meet dus op uitkomsten, niet op ervaring.
Bronnen
- APQC. (2021, 9 november). APQC survey finds one quarter of knowledge workers' time is lost due to productivity drains. https://www.apqc.org/about-apqc/news-press-release/apqc-survey-finds-one-quarter-knowledge-workers-time-lost-due
- Becker, J., Rush, N., Barnes, E., & Rein, D. (2025). Measuring the impact of early-2025 AI on experienced open-source developer productivity (arXiv:2507.09089). arXiv. https://doi.org/10.48550/arXiv.2507.09089
- Brynjolfsson, E., Li, D., & Raymond, L. (2025). Generative AI at work. The Quarterly Journal of Economics, 140(2), 889-942. https://doi.org/10.1093/qje/qjae044
- Chi, W., Chen, V., Shar, R., Mittal, A., Liang, J., Chiang, W.-L., Angelopoulos, A. N., Stoica, I., Neubig, G., Talwalkar, A., & Donahue, C. (2025). EDIT-Bench: Evaluating LLM abilities to perform real-world instructed code edits (arXiv:2511.04486). arXiv. https://doi.org/10.48550/arXiv.2511.04486
- Cui, K. Z., Demirer, M., Jaffe, S., Musolff, L., Peng, S., & Salz, T. (2026). The effects of generative AI on high-skilled work: Evidence from three field experiments with software developers. Management Science. Advance online publication. https://doi.org/10.1287/mnsc.2025.00535
- Ferreira, J. J., Segura, V., Souza, J. G., & Brasil, J. H. G. (2025). How people manage knowledge in their "second brains": A case study with industry researchers using Obsidian. In Lecture Notes in Computer Science. Springer. https://doi.org/10.1007/978-3-032-05008-3_15
- Frost, A. (2014). A synthesis of knowledge management failure factors. https://www.knowledge-management-tools.net/failure.html
- Litvinenko, A. (2026). The knowledge collaboration framework: A review of artificial intelligence in organisational learning and knowledge management. Journal of Decision Systems, 35(1), 2616703. https://doi.org/10.1080/12460125.2026.2616703
