Hoe zorg je dat kennis niet verloren gaat als een systems engineering plan alleen in hoofden zit?

Systems engineering kennis gaat verloren wanneer het alleen in de hoofden van mensen zit en niet structureel is vastgelegd in een systeem dat meegaat met het project. De oplossing is kennisborging: het actief vastleggen van eisen, besluiten, verificaties en onderlinge relaties in een centrale, doorzoekbare omgeving, zodat kennis overdraagbaar blijft, ongeacht wie er op het project zit. In dit artikel beantwoorden we de meest gestelde vragen over hoe je dat in de praktijk aanpakt.

Waarom gaat systems engineering kennis zo makkelijk verloren?

Systems engineering kennis verdwijnt omdat het doorgaans verspreid is over losse bestanden, persoonlijke notities en de ervaring van individuele engineers. Zodra iemand het project verlaat, van rol wisselt of simpelweg vergeet iets bij te houden, is die kennis weg. De kern van het probleem is dat de meeste teams documenteren in plaats van borgen: ze maken bestanden aan, maar die bestanden leven niet mee met het project.

Er zijn een paar structurele oorzaken die dit patroon in stand houden:

Versnippering van informatie: Eisen staan in Word, verificaties in Excel, besluiten in e-mails. Niemand heeft het totaalplaatje.
Geen traceability: De relatie tussen een eis, het ontwerp en het bewijs van verificatie is niet zichtbaar gemaakt. Als er iets wijzigt, weet niemand wat de impact is.
Kennis zit in mensen, niet in systemen: Ervaren engineers dragen cruciale context in hun hoofd. Bij een projectwissel begint het volgende team vanaf nul.
Tooling sluit niet aan: Zware MBSE-tools zijn te complex of te duur, waardoor teams terugvallen op wat ze kennen: spreadsheets en tekstdocumenten.

Het gevolg is dat audits stressvol zijn, overdrachten tijdrovend en fouten moeilijk te herleiden. Niet omdat engineers slordig zijn, maar omdat de infrastructuur voor kennisborging simpelweg ontbreekt.

Wat is het verschil tussen kennisborging en documentatie?

Documentatie is het vastleggen van informatie op een bepaald moment. Kennisborging is het structureel inrichten van een omgeving waarin informatie levend, doorzoekbaar en traceerbaar blijft gedurende de hele projectlevenscyclus. Het verschil zit niet in wat je vastlegt, maar in hoe en waar je dat doet.

Een systems engineering plan dat alleen als PDF bestaat, is documentatie. Zodra de eisen daarin wijzigen, is het document verouderd en weet niemand meer welke versie geldig is. Kennisborging betekent dat diezelfde eisen leven in een systeem dat relaties bijhoudt: welke eis hoort bij welk deelsysteem, welke verificatiemethode is gekoppeld, en wat is het bewijs dat de eis is aangetoond?

Concreet onderscheidt kennisborging zich op drie punten:

Dynamisch versus statisch: Geborgde kennis past mee als het project evolueert. Documentatie is een momentopname.
Relationeel versus lineair: Kennisborging legt verbanden vast tussen objecten, eisen en verificaties. Documentatie beschrijft ze los van elkaar.
Overdraagbaar versus persoonsgebonden: Geborgde kennis kan door iedereen worden opgepakt. Gedocumenteerde kennis vereist vaak uitleg van degene die het schreef.

Hoe zorg je voor traceability zonder dat het een dagtaak wordt?

Traceability wordt alleen haalbaar als het ingebakken zit in de manier waarop je werkt, niet als een aparte taak die je er achteraf bij doet. De sleutel is een omgeving waarin je eisen, verificaties en besluiten direct aan elkaar koppelt op het moment dat je ze vastlegt, zodat de traceabilitymatrix zichzelf opbouwt.

In de praktijk betekent dit dat je afstapt van het bijhouden van losse matrices in Excel. Een verificatiematrix die handmatig wordt samengesteld, is altijd verouderd en foutgevoelig. Zodra een eis wijzigt, moet de matrix opnieuw worden doorgelopen. Dat is de reden waarom traceability in veel projecten als een dagtaak voelt: het is reactief in plaats van proactief ingericht.

Effectieve traceability vraagt om drie dingen:

Een centrale plek voor eisen: Niet verspreid over documenten, maar beheerd in één systeem waar wijzigingen direct zichtbaar zijn.
Expliciete relaties: Elke eis is gekoppeld aan het systeem of deelsysteem waarop het betrekking heeft, en aan de verificatiemethode die aantoont dat eraan voldaan wordt.
Automatische rapportage: De verificatiematrix en traceabilityrapportages worden gegenereerd vanuit het systeem, niet handmatig samengesteld.

Wij hebben dit principe verwerkt in ons platform: binnen Datastorms leg je eisen, relaties en verificaties vast in een semantische structuur, waarna verificatiematrices automatisch worden gegenereerd. Dat bespaart niet alleen tijd, het maakt traceability ook betrouwbaar.

Welke tools helpen bij het borgen van systems engineering kennis?

De juiste tool voor kennisborging in systems engineering hangt af van de schaal van je project, de complexiteit van je eisenstructuur en het budget van je organisatie. Er zijn grofweg drie categorieën tools, elk met een eigen profiel.

Zware MBSE-tools

Tools zoals Cameo Systems Modeler of IBM DOORS zijn krachtig en breed inzetbaar, maar vragen een aanzienlijke investering in licenties, implementatie en training. Ze zijn ontworpen voor grote organisaties met dedicated tooling-teams en passen zelden goed bij projectteams die snel willen starten zonder een steile leercurve.

Lichtgewicht en semantische platforms

Platforms zoals Datastorms richten zich specifiek op de praktijk van systems engineers in de infra-, water- en maakindustrie. Ze combineren de structuur van MBSE met de toegankelijkheid van low-code of no-code omgevingen. Je werkt vanuit een centrale bibliotheek van objecten, definities en templates, en integreert via een API met tools die al in gebruik zijn. Dit maakt kennisborging haalbaar voor teams die geen dedicated tooling-specialist hebben, maar wel grip willen op eisen, verificatie en traceability. Wil je zelf ervaren hoe dit werkt? Via een proeflicentie kun je het platform vrijblijvend uitproberen binnen jouw eigen projectcontext.

Generieke samenwerkingstools

Tools zoals Confluence, SharePoint of Notion worden vaak ingezet voor kennisdeling, maar missen de relationele structuur die traceability mogelijk maakt. Ze zijn geschikt als aanvulling, maar niet als primaire omgeving voor systems engineering kennisborging.

Wanneer is het juiste moment om kennisborging in te richten?

Het beste moment om kennisborging in te richten is aan het begin van een project, als onderdeel van het systems engineering plan. Op dat moment zijn de structuren nog flexibel, de eisen nog in ontwikkeling en de teamleden nog beschikbaar om afspraken te maken over hoe kennis wordt vastgelegd en beheerd.

In de praktijk gebeurt dit zelden. De meeste teams starten met wat ze kennen, en pas als een project complexer wordt of een overdracht nadert, wordt het gebrek aan kennisborging pijnlijk zichtbaar. Dat is niet ideaal, maar het betekent niet dat het dan te laat is.

Er zijn drie momenten waarop kennisborging altijd urgent is:

Bij de start van een project: Ideaal, omdat je de structuur kunt inrichten voordat de complexiteit toeneemt.
Bij een teamwissel of overdracht: Wanneer iemand het project verlaat, wordt zichtbaar hoeveel kennis persoonsgebonden is. Dit is het moment om te structureren wat er is.
Voor een audit of mijlpaal: De voorbereiding op een audit dwingt teams om traceability inzichtelijk te maken. Gebruik die druk als aanleiding om het structureel in te richten.

Hoe begin je met kennisborging in een lopend project?

In een lopend project begin je met kennisborging door eerst in kaart te brengen waar de kritieke kennis nu zit en wie die kennis draagt. Dat geeft je een startpunt om te prioriteren: welke informatie is het meest kwetsbaar en het meest urgent om te borgen?

Je hoeft niet alles tegelijk te doen. Een pragmatische aanpak werkt beter dan een grootschalige migratie die weken kost en nooit wordt afgerond. Begin klein, maar begin gestructureerd:

Breng de eisenstructuur in kaart: Welke eisen zijn er, op welk systeem of deelsysteem hebben ze betrekking, en wie is eigenaar? Dit is de basis van elk systems engineering plan.
Maak de relaties expliciet: Koppel eisen aan verificatiemethoden en aan de onderdelen van het systeem waarop ze van toepassing zijn. Zelfs een beperkte traceabilitystructuur is beter dan geen.
Kies een centrale plek: Zorg dat de informatie op één plek leeft, niet verspreid over persoonlijke mappen en e-mailthreads.
Betrek het team: Kennisborging werkt alleen als iedereen het systeem gebruikt. Maak het zo laagdrempelig mogelijk en leg uit waarom het bijdraagt aan minder stress bij audits en overdrachten.
Bouw het stap voor stap uit: Zodra de basis staat, kun je verificaties toevoegen, besluiten vastleggen en rapportages genereren.

Het systems engineering plan hoeft niet perfect te zijn om te beginnen. Wat telt is dat kennis stap voor stap uit hoofden en bestanden wordt gehaald en in een omgeving terechtkomt die meegaat met het project, ook als de teamsamenstelling verandert.

Veelgestelde vragen

Hoe overtuig ik mijn team of management om te investeren in kennisborging?

De sterkste argumenten zijn tijd en risico: bereken hoeveel uur er per jaar opgaat aan het zoeken naar informatie, het voorbereiden van audits en het inwerken van nieuwe teamleden. Maak daarnaast inzichtelijk welke projectrisico's ontstaan als een ervaren engineer vertrekt zonder dat zijn kennis is geborgd. Een concrete pilot op een afgebakend project of deelsysteem — waarbij je de tijdsbesparing meetbaar maakt — is vaak effectiever dan een theoretisch verhaal.

Wat zijn de meest gemaakte fouten bij het opzetten van kennisborging in systems engineering?

De grootste fout is beginnen met de toolkeuze in plaats van met de structuur: een nieuw platform lost niets op als er geen afspraken zijn over hoe eisen, relaties en verificaties worden vastgelegd. Een tweede veelgemaakte fout is het willen migreren van alles in één keer, wat leidt tot een overbelast team en een half afgerond systeem. Begin met de meest kritieke kennisgebieden, stel duidelijke eigenaarschappen in en bouw de structuur stap voor stap uit.

Hoe ga je om met kennisborging in projecten met meerdere disciplines of externe partijen?

Bij multidisciplinaire projecten of samenwerkingen met externe partijen is het essentieel om vroegtijdig afspraken te maken over welk systeem de centrale bron van waarheid is en wie verantwoordelijk is voor welke onderdelen van de eisenstructuur. Gebruik een platform dat toegankelijk is voor alle betrokkenen, zonder dat iedereen een dure licentie of uitgebreide training nodig heeft. Leg ook vast hoe wijzigingen worden gecommuniceerd en wie goedkeuring geeft, zodat de traceability over organisatiegrenzen heen intact blijft.

Hoe houd je de geborgde kennis actueel naarmate het project vordert en eisen wijzigen?

Actueel houden van kennis begint bij het inbouwen van een wijzigingsproces: elke eiswijziging gaat via het centrale systeem, niet via e-mail of een apart document. Koppel wijzigingen altijd aan een reden en een besluitnummer, zodat de context bewaard blijft. In een goed ingericht platform worden de gevolgen van een wijziging — welke verificaties moeten worden herzien, welke deelsystemen zijn geraakt — direct inzichtelijk, wat het bijhouden van actuele kennis een stuk minder arbeidsintensief maakt.

Is kennisborging ook zinvol voor kleinere projecten of kleine teams?

Ja, juist bij kleine teams is kennisborging waardevol omdat er minder redundantie is: als één persoon het project verlaat of ziek wordt, is de impact direct voelbaar. De aanpak hoeft niet zwaar te zijn — een eenvoudige structuur met centrale eisen, expliciete relaties en een heldere verificatiestatus is al een enorme verbetering ten opzichte van losse bestanden. Kies voor een lichtgewicht platform dat snel op te zetten is, zodat de investering in verhouding staat tot de projectomvang.

Hoe verhoudt kennisborging zich tot het systems engineering plan (SEP)?

Het systems engineering plan beschrijft hoe je systems engineering aanpakt binnen een project, en kennisborging is een integraal onderdeel daarvan: het SEP moet vastleggen welk systeem wordt gebruikt, wie eigenaar is van welke informatie en hoe wijzigingen worden beheerd. Zonder een concrete kennisborgingsstrategie in het SEP blijft het plan een intentiedocument dat niet wordt nageleefd. Behandel kennisborging dus niet als bijlage, maar als een kernproces dat je net zo zorgvuldig inricht als de verificatiestrategie zelf.

Kan kennisborging ook helpen bij de voorbereiding op certificering of compliance-trajecten?

Absoluut. Bij certificerings- of compliance-trajecten — denk aan NEN-normen, ISO-standaarden of projectspecifieke eisenpakketten van opdrachtgevers — is aantoonbare traceability vaak een harde eis. Met een goed ingericht kennisborgingssysteem kun je op elk moment laten zien welke eis door welke verificatie is aangetoond en welk bewijs daarvoor beschikbaar is. Dat maakt audits en reviews niet alleen minder stressvol, maar ook aanzienlijk sneller doordat je rapportages direct uit het systeem genereert in plaats van ze handmatig samen te stellen.