De mail komt op een dinsdag: je meest ervaren engineer heeft een nieuwe baan. Iedereen gunt het hem, en tegelijk voelt de afdeling de grond even bewegen. Twaalf jaar aan projecten, klantwensen en ontwerpkeuzes staat op het punt de deur uit te lopen, en het grootste deel daarvan staat nergens op papier.
De reflex is een dik overdrachtsdocument in de laatste week. Dat document wordt geschreven, opgeslagen en nooit meer geopend. Kennisborging bij het vertrek van een engineer werkt anders: je kiest scherp wat het borgen waard is, legt het vast op de plek waar de opvolger het vanzelf tegenkomt, in de modellen, mappen en templates zelf, en draagt lopende projecten warm over. Daar heb je geen apart systeem voor nodig, al helpt gereedschap als Thundercad om metadata die rol te laten spelen.
Hieronder staat een draaiboek voor de opzegtermijn, week voor week. Het is geschreven met een vertrekkende senior bij een machinebouwer in gedachten, maar werkt net zo goed bij een plaatwerkbedrijf of speciaalbouwer.
Het archief dat nergens staat
Wat vertrekt er eigenlijk? Niet de modellen en tekeningen; die blijven netjes op de server staan. Wat vertrekt is de laag eromheen: waarom het frame gelast is en niet geschroefd, waarom die ene klant elke revisie dubbel gecontroleerd wil zien, welke leverancier maatwerk kan leveren als het echt moet, en welke samenstelling je nooit zomaar moet bijwerken omdat er dan elders iets omvalt.
Die laag valt uiteen in drie soorten kennis, en die volgorde is meteen de prioriteit bij het borgen:
- Waarschuwingskennis: waar liggen de lijken? Modellen die stukgaan bij hergebruik, constructies die op het randje zijn gedimensioneerd, afspraken die nergens formeel zijn vastgelegd.
- Klantkennis: voorkeuren, gevoeligheden en stilzwijgende afspraken per klant. Vaak belangrijker voor de relatie dan de techniek zelf.
- Waaromkennis: de redenen achter ontwerpkeuzes. Zonder die redenen "verbetert" een opvolger iets terug naar een oplossing die jaren geleden al is afgevallen.
Prioriteren: tien werkdagen, dus kies
Een opzegtermijn van een maand of twee klinkt ruim, maar er lopen ook nog projecten die af moeten. Reken realistisch op hooguit tien werkdagen echte borgingstijd, vaak minder. Alles vastleggen is dus geen optie; het gaat om de kennis die duur is om opnieuw uit te vinden én die waarschijnlijk snel nodig is.
Stel de prioriteitenlijst niet op met de vraag "wat weet je allemaal", want daar komt een encyclopedie uit. Stel gesloten, concrete vragen:
- Welke drie projecten zou je opvolger nooit zonder hulp moeten reviseren, en waarom niet?
- Welke klanten bellen altijd over hetzelfde, en wat is dan het goede antwoord?
- Welke modellen of samenstellingen zou je zelf nooit als startpunt hergebruiken?
- Wat doe jij anders dan de rest van het team, en is dat erg?
Vastleggen in de systemen, niet in een document
Het overdrachtsdocument heeft een fundamenteel probleem: het staat los van het werk. De opvolger die over vier maanden een machine reviseert, denkt er niet aan om eerst een document uit een map te vissen. Kennis moet opduiken op het moment dat je ze nodig hebt, en dat gebeurt alleen als ze in de systemen zelf zit:
- In de metadata van modellen en tekeningen. Een opmerkingen- of notitieveld op het bestand is de beste plek voor waarschuwingen: wie het model opent, ziet de datakaart en dus de waarschuwing. Met het iProperty Panel van Thundercad richt je per documenttype zo'n datakaart in, zodat het veld er altijd staat en niet per bestand hoeft te worden uitgevonden.
- In templates. Klantspecifieke eisen aan titelblokken, projectie of aanlevering horen in een template per klant, niet in het geheugen van één persoon.
- In de projectstructuur. Markeer per klant of productfamilie één referentieproject als startpunt, en zet dat er expliciet bij in de omschrijving. Dat voorkomt dat de opvolger het verkeerde project kopieert.
- In de klantgegevens. Voorkeuren en gevoeligheden per klant horen in het systeem waar klantinformatie leeft, kort en feitelijk, geen roman.
Het grote voordeel van kennis in metadata: ze is doorzoekbaar. Wie zoekt op eigenschappen in plaats van op mapkennis, vindt ook de waarschuwing die een vertrokken collega ooit achterliet. Hoe je die omslag maakt, beschreven we in Terugvinden op eigenschappen in plaats van mapkennis.
Eén categorie verdient een eigen inventarisatie: zelfgeschreven automatisering. Elke iLogic-regel of macro waarvan de vertrekker de enige auteur is, hoort minstens op een lijst met wat hij doet en waar hij draait. Waarom zulke zelfbouw kwetsbaar is en wanneer een kant-en-klare toolbox de betere keuze is, behandelden we in iLogic of een kant-en-klare toolbox? Wanneer kies je wat; hier volstaat: zet het op de inventarislijst en wijs een nieuwe beheerder aan.
Kennis die in metadata en templates zit, blijft gewoon staan als de engineer vertrekt. Met een vaste datakaart per documenttype leg je ze vast op het moment dat ze ontstaat, niet pas in de laatste week.
Probeer 30 dagen gratisLopende projecten warm overdragen
Voor lopende projecten schiet elk document tekort; daar is de overdracht pas geslaagd als de overnemer het werk echt heeft gedaan terwijl de vertrekker er nog naast zat. Draai de rollen dus bewust om: de overnemer voert uit, de vertrekker kijkt mee en vult aan. Andersom, meekijken over de schouder van de vertrekker, voelt productief maar beklijft niet.
- Wijs per lopend project één overnemer aan. "Het team neemt het over" betekent dat niemand het overneemt.
- Laat de overnemer de eerstvolgende wijziging of revisie zelf uitvoeren, van model tot vrijgave, met de vertrekker als vraagbaak.
- Loop per project één uur samen door de hoofdsamenstelling: browserstructuur, kritieke maten, de plekken waar je niet aan moet komen. In het model zelf, niet in een presentatie.
- Doe het eerstvolgende klantoverleg samen en kondig daar de overdracht aan. Een warm doorgegeven contact scheelt de opvolger maanden aftasten.
Laat na elke sessie de overnemer zelf de drie belangrijkste inzichten in de projectmetadata of het projectdossier zetten. Wat je zelf formuleert, onthoud je; wat je alleen aanhoort, vervliegt.
Het draaiboek per week
Samengevat ziet de opzegtermijn er zo uit, uitgaande van zes weken. Is de termijn korter, schaal dan naar rato en schrap eerst in het vastleggen, nooit in het warm overdragen.
| Periode | Zwaartepunt | Concreet resultaat |
|---|---|---|
| Week 1 | Inventariseren en prioriteren | Toptienlijst, inventaris van scripts en sjablonen, overnemers aangewezen |
| Week 2 en 3 | Vastleggen in de systemen | Waarschuwingen in metadata, templates bijgewerkt, referentieprojecten gemarkeerd |
| Week 4 en 5 | Warm overdragen | Overnemers hebben zelf een wijziging uitgevoerd, klantcontacten samen gedaan |
| Laatste week | Alleen nog vragen | Geen nieuwe taken meer naar de vertrekker; restpunten en toegang afgerond |
De laatste week bewust leeg houden is het minst intuïtieve en tegelijk het belangrijkste onderdeel. Wie tot de laatste dag productiewerk bij de vertrekker legt, koopt één week extra capaciteit en betaalt met maanden zoekwerk daarna.
Veelgestelde vragen
Wat als de opzegtermijn maar een paar weken is?
Prioriteer dan meedogenloos: alleen waarschuwingskennis en het warm overdragen van het grootste lopende project. Een middag samen door de kritieke samenstellingen lopen en de waarschuwingen direct in de metadata zetten levert meer op dan elke poging om alles te documenteren.
Is een exitgesprek niet genoeg?
Een exitgesprek gaat over de organisatie en belandt in een verslag dat engineering nooit ziet. Kennisborging hoort in de werkomgeving zelf: in modellen, templates en projectdossiers, vastgelegd door de mensen die ermee verder moeten. Het gesprek is een prima afsluiting, geen borging.
Hoe voorkom ik dat dit bij een volgend vertrek weer een crisis is?
Door vastleggen onderdeel van het gewone werk te maken: een opmerkingenveld op de datakaart, referentieprojecten die actueel worden gehouden, en afspraken direct in de klantgegevens in plaats van in hoofden. Wil je zien hoe zo'n vaste datakaart per documenttype werkt, probeer Thundercad dan 30 dagen gratis.