de kennisbank

Ik schreef een tijdje terug op LinkedIn dat mijn Teams-folder eigenlijk gewoon een GitHub-repository is. En daar kwam elke keer diezelfde vraag op terug. Klinkt mooi, maar hoe zet ik zoiets nou zelf op? Nou. Minder spannend dan je zou denken, hoor. Een map met markdown-bestanden, één instructiebestand ernaast, en een AI die bij die map kan. Meer is het eigenlijk niet. Ik zit er zelf elke dag in, met Claude Cowork.

Het begon trouwens al in mijn dagen als consultant. Dit is een game changer geweest. Kijk naar een project bij een grote corporate organisatie: implementatie van Sales en Service Cloud, SAP, samen met S/4HANA als ERP-systeem, waar ik 30 Solution Design-gesprekken heb uitgevoerd. Daar hebben we allemaal transcripten van gemaakt, opnames, speech-to-text, en dat vervolgens geüpload in een kennisdatabank. Dat was mijn eigen kennisbank, een levende kennisbank. Ik kon daar samen met mijn partner live in werken. We hebben dat toen in Teams opgezet, met de Teams Read&Write-tools, dus dat was met een MCP-server. En wij konden daar live in werken: als hij erin had gewerkt, nieuwe transcripten had verwerkt, het solution design had aangepast, dan kwam dat daar weer in terecht. Uiteindelijk hebben we een solution design van 150 pagina’s opgezet met twee consultants, in echt een beperkt aantal tijd, wat nooit had gekund zonder die kennisbank. En er zijn nog zoveel meer manieren om zo’n kennisbank goed te gebruiken. Dat is enorm waardevol, ook in kleinere bedrijven: als je gewoon je kennis en je processen centraal ergens wil hebben staan. Het concept van een LLM-wiki gebruik ik vaak het liefst, omdat dat concept eigenlijk op alles toe te passen is. Het maakt kennis zonder moeite centraal beheerbaar.

Maar het gaat me hier niet om die tool, hoor. Hoe zo’n wiki technisch in elkaar zit, en waarom documentatie voor een machine meer oplevert dan een betere prompt, dat heb ik al eens uitgeschreven in context verslaat de prompt. Dat ging over de persoonlijke kant. Eén werkplek, één gebruiker. Ik wil hier de laag daarboven pakken. Want wie onderhoudt zo’n kennisbank nou eigenlijk? Wie mag erin schrijven? En wie bepaalt wat waar is als twee pagina’s elkaar tegenspreken? Kijk, en precies daarop liep elke eerdere generatie kennissystemen vast.

het archief dat niemand leest

Bijna elke organisatie sleept zo’n kennisgraveyard mee. Een gedeelde schijf die niemand meer openmaakt. Een intranet. Een wiki die ooit vol goede moed is opgetuigd en na drie maanden stilviel. En de doodsoorzaak is bijna nooit de software, hoor. Het is het onderhoud. De last groeit harder dan wat het oplevert, en op een gegeven moment haken mensen gewoon af.

En dan zakt het alleen maar verder weg. Het archief veroudert, dus niemand vertrouwt het nog. Zoek je iets op, dan check je het antwoord tóch nog even bij een collega. En weet je zelf iets? Dan schrijf je het niet meer op, want ja, het wordt toch niet gelezen. Zo’n kennisbank zonder onderhoud is niet zomaar onvolledig. Het is een stapel verlopen claims die eruitziet als documentatie. En dat is erger dan niks.

Want wat ik heel vaak zie bij organisaties, is dat kennis gewoon enorm bij personen ligt. Bedrijven hebben heel vaak last van kennis die uit de organisatie lekt omdat iemand weggaat. En dat komt gewoon omdat mensen vaak druk zijn met hun eigen proces. Ik reflecteer naar mezelf: ik ben in die tijd heel druk geweest met projectwerk, soms zit je op drie projecten, en dan heb je geen zin en geen puf, maar ook geen tijd om daarnaast ook nog eens alles wat je leert en wat je doet te documenteren. En met een levende kennisbank gaat dat automatisch.

En de conclusie is dan niet dat organisaties zich voortaan beter moeten gedragen. Kijk naar de geschiedenis van de bedrijfswiki: dat gebeurt niet, hoe vaak je het ook afspreekt. Dus dat onderhoud moet ergens anders komen te liggen. Weg bij de mens.

twee lezers, één bron

Wat deze kennisbank anders maakt dan al zijn voorgangers, zit ‘m in één ding. Er zijn nu twee soorten lezers. En ze lezen hetzelfde bestand.

De AI gebruikt de wiki als werkgeheugen, en houdt ‘m bij terwijl het werk vordert. De mens leest diezelfde map als naslag. Wil je het wat overzichtelijker? Dan wijs je Obsidian naar de wiki-map. Gratis programma, dat je die markdown-mappen laat zien als een doorklikbare kennisbank. Met zo’n grafiekweergave erbij, een plaatje dat je in één oogopslag laat zien wat met wat verbonden is, en welke pagina’s er een beetje los bij bungelen. De AI zit te schrijven op basis van het gesprek, en jij bladert er ondertussen live doorheen.

En dat is het hele punt. Geen aparte documentatie voor de mensen en een los brokje context ernaast voor de machines. Eén bron van waarheid. In het enige formaat dat allebei die lezers moeiteloos aankunnen, en dat is gewoon platte tekst in mappen. Geen vendor ertussen. Geen abonnement dat maar door blijft lopen. En heet de tool van volgend jaar anders? Dan valt er niks te migreren. Maar het mooiste zit ‘m eigenlijk in wat je hiermee juist voorkomt. Namelijk twee versies van de werkelijkheid die stilletjes uit elkaar groeien.

wie onderhoudt wat

De rolverdeling, dát is de kern van de methode. En die is streng, hoor.

Jij bent de redacteur. Jij draagt de bronnen aan, jij geeft richting, en jij hakt de knoop door zodra twee pagina’s elkaar tegenspreken. De ruwe bronnen, die blijven heilig. Daar leest de AI wel uit. Aankomen doet-ie er nooit.

En de AI, dat is de schrijver. De kruisverwijzingen, de samenvattingen, de indexregels, de logboekvermeldingen. Dat is allemaal zijn werk. Precies dat soort saaie klusjes waar elke menselijke wiki-beheerder vroeg of laat op afknapt.

De kennisdatabank is gemaakt door een LLM, en met de LLM-wiki is het ook zo gemaakt dat een LLM-model er heel efficient in kan werken. Je hebt een centraal introductiebestand, de CLAUDE.md, met instructies en gouden regels die het model altijd leest. Als organisatie kun je vanuit een top-down principe zorgen, vanuit die instructiefolder die niemand kan aanpassen, dat iedereen altijd met het LLM werkt onder dezelfde regels. Dat is al enorm krachtig.

Rot en wildgroei, dat houd je niet tegen met goede voornemens. Daar heb je een vast regime voor nodig. En dat regime kent drie operaties. Ingest, om te beginnen: komt er een nieuwe bron binnen, dan wordt die verwerkt in de pagina’s die er al staan. En spreekt-ie iets tegen wat er al staat? Dan wordt dat netjes gemarkeerd, in plaats van dat er stilletjes overheen geschreven wordt. Dan Query: een antwoord dat echt wat waard is, dat schrijf je terug als nieuwe pagina. Zo bouwen vragen zelf ook kennis op. En Lint, tot slot: een periodieke gezondheidscheck. Op tegenstellingen, op verouderde claims, op pagina’s waar geen enkele link naartoe wijst, en op begrippen die nog geen eigen pagina hebben. Die laatste operatie, díe scheidt een kennisbank van een losse stapel notities. Want zo komt rot aan het licht, nog voordat iemand erop verder bouwt.

En dat onderhoud heeft een vaste plek in de werkdag. Elke sessie eindigt met diezelfde opdracht: werk de wiki bij met wat we deze sessie geleerd hebben. Geen documentatiesprint. Geen kwartaalopschoning. Nee, gewoon de laatste handeling van elk werkblok. En juist daardoor loopt het vanzelf gelijk met het werk mee.

En van elke sessie wordt een log gemaakt van iedereen die erin werkt. Stel, ik ben aan het werken en laat dat in mijn sessie weten, dan wordt daar automatisch een samenvatting van gemaakt: wat er is gedaan, wat ik heb gedaan, waar het is geschreven. En dat gaat live. Als Jantje tegelijk met mij aan iets werkt, dan weten we dat direct van elkaar doordat onze LLM-modellen dat zien. Dat heeft heel veel toegevoegde waarde voor projecten met meerdere mensen, en zonder aparte software. Natuurlijk heb je Slack en andere programma’s die daarvoor bedoeld zijn, maar hier heb je gewoon je eigen; het kan lokaal leven.

van map naar fundament

Beginnen kan gewoon lokaal, in een mapje op je eigen machine. Dat is vooral fijn voor projecten waar ik in mijn eentje op werk. Je kan het ook in de cloud hebben, met Microsoft Teams bijvoorbeeld, een voor de hand liggende keuze voor enterprise. Maar OneDrive of Google Drive kan ook. En daar zit dan geen dure subscriptie met chatfunctie aan vast.

En je kan zo’n kennisdatabank splitsen in verschillende projecten. Je kan er een hele grote van maken, organisatiebreed, en daaronder alle projecten of afdelingsbreed. Maar je kan het ook per project schalen. En het leuke is: de AI gaat verbanden zien die jij nooit had gevonden. Je kan prompten met enorme context bij elke prompt.

Wat er echt een organisatiefundament van maakt, is de stap naar een repository. Zet die map op GitHub, en je hebt in één klap versiegeschiedenis, een back-up, én de mogelijkheid om er met een heel team in te werken. En dat is niet zomaar gemak, hoor. Dat is governance. Elke wijziging van de AI is een zichtbare wijziging in je versiebeheer. Te reviewen, terug te draaien, net zoals je dat met code doet. Kijk, een schrijver die nooit moe wordt, die heeft een redactie nodig die kan zien wat-ie heeft gedaan.

Vandaar dus die uitspraak over die Teams-folder. Een repo, dat is niet hip bedoeld. Het is domweg de enige gedeelde opslag waar zo’n AI-agent echt volwaardig in kan werken, én waar elke wijziging tegelijk traceerbaar blijft.

De écht open vraag zit trouwens een verdieping hoger. Met een heel team tegelijk in diezelfde wiki schrijven, zonder dat het botst? Dat heb ik nog niet opgelost. De technische botsingen, die vangt versiebeheer prima op. De redactievraag blijft staan: wie bepaalt er bij een tegenstelling welke pagina wint? Voor mij in m’n eentje werkt het vandaag al. En voor een klein team met één duidelijke redacteur ook. Maar de governance voor tien schrijvers die allemaal tegelijk aan de gang zijn? Ja, dat is nog werk in uitvoering.

Hoeveel dat regime nou echt waard is, dat merkte ik eigenlijk pas laat. Ik kwam na een CRM-traject bij de ene klant net zo’n soort proces tegen bij een tweede. En die wiki was op dat moment gewoon actueel. Om de simpele reden dat het bijwerken nooit had stilgelegen. Ik hoefde dus niet eerst te gaan zitten twijfelen of ik ‘m nog wel kon vertrouwen. De AI legde dat vastgelegde patroon naast de nieuwe situatie, en wees me zo op verschillen die ik zelf allang weer vergeten was.

En dat is uiteindelijk het punt waarop een gedeelde kennisbank echt een fundament wordt. Kijk, elke eerdere generatie kennissystemen was een plek waar het werk naartoe moest. Ná het echte werk. Bijgehouden door mensen die eigenlijk wel wat beters te doen hadden. Dit is de eerste generatie waarin de kennisbank zelf meewerkt. Hij leest mee, hij schrijft bij, en hij wordt beter van elke sessie. Zo’n fundament dat terugduwt, dat is geen archief meer. Dat is gewoon een collega die nooit van project wisselt.