Jedes Entwicklungsunternehmen hat diesen einen Kollegen. Er weiß, warum die Platine 2011 umkonstruiert wurde, welcher Lieferant damals das Problem verursachte und warum man Variante B nie wieder anfassen sollte. Er beantwortet Fragen in dreißig Sekunden, für die das Ticketsystem dreißig Suchanfragen bräuchte. Und er geht in vier Jahren in Rente.
Die Demografie ist im Engineering keine abstrakte Statistik. Die Jahrgänge, die in den nächsten zehn Jahren ausscheiden, tragen in vielen Häusern das Produkt- und Prozesswissen mehrerer Jahrzehnte — und Nachfolger, die es aufnehmen könnten, sind auf dem Arbeitsmarkt kaum zu bekommen. Was mit dem Kollegen die Firma verlässt, steht in keiner Bilanz, aber es fehlt in jedem künftigen Projekt.
Warum die klassische Antwort scheitert
Die übliche Reaktion heißt: „Dann muss er halt alles dokumentieren, bevor er geht.” Jeder, der das einmal versucht hat, kennt das Ergebnis. Dokumentation, die auf Vorrat geschrieben wird, scheitert dreifach:
Niemand hat Zeit, sie zu schreiben. Der erfahrene Kollege ist bis zum letzten Arbeitstag der gefragteste Mensch der Abteilung — gerade weil er so viel weiß. Die Wochen für die große Wissensniederschrift gibt der Kalender nie her.
Niemand weiß, was aufgeschrieben gehört. Der Wert seines Wissens zeigt sich in der Situation, nicht im Voraus. Die entscheidende Randnotiz — „bei Temperaturen unter minus zwanzig schwingt das Gehäuse” — steht in keinem Inhaltsverzeichnis, das man vorab plant.
Niemand findet sie wieder. Selbst gute Dokumentation stirbt im Ablagesystem. Ein Wiki mit zehntausend Seiten, von denen die Hälfte veraltet ist, beantwortet keine Fragen — es versteckt Antworten.
Was eine KI-Wissensbasis anders macht
Der entscheidende Perspektivwechsel: Das meiste Wissen ist längst aufgeschrieben — nur nicht dort, wo man sucht. Es liegt verstreut in zwanzig Jahren Confluence-Seiten, Ticket-Verläufen, Review-Kommentaren, Änderungsanträgen, Prüfberichten und Projektordnern. Kein Mensch kann diese Masse lesen. Eine KI kann es.
Eine KI-gestützte Wissensbasis — technisch: ein Retrieval-System, das Antworten aus Ihren eigenen Dokumenten belegt — macht aus diesem Bestand ein abfragbares Gedächtnis:
- Fragen in natürlicher Sprache. „Warum haben wir beim Vorgängerprojekt den Stecker gewechselt?” statt fünf Suchbegriffe in drei Systemen.
- Antworten mit Quellenangabe. Jede Antwort verweist auf die Fundstellen — das Änderungsticket von 2014, das Protokoll der Design-Review. Prüfbar statt plausibel; keine freie Erfindung des Modells.
- Im eigenen Haus. Konstruktionswissen ist das wertvollste Geschäftsgeheimnis eines Entwicklungsunternehmens. Eine Wissensbasis dieser Art gehört self-hosted auf Ihre Infrastruktur — nicht in einen fremden Cloud-Index.
Der ausscheidende Kollege wird dadurch nicht kopiert. Aber der Teil seines Wertes, der „Ich weiß, wo es steht und was damals war” heißt, bleibt der Firma erhalten — und steht plötzlich jedem im Team zur Verfügung, nicht nur denen, die sich trauen zu fragen.
Der Aufbau: vier Schritte, kein Gewaltakt
In der Praxis bauen wir Wissensbasen entlang unseres Stufenprinzips auf — planbar und einzeln messbar statt als Großprojekt:
1. Quellen-Inventur. Welche Bestände enthalten Wissen: Wiki, ALM-System, Tickets, Laufwerke, Prüfberichte? Was davon ist rechtlich und organisatorisch nutzbar? Hier zeigt sich fast immer: Es ist mehr da, als alle dachten.
2. Datenreife herstellen. Der unbequeme, entscheidende Schritt — KI ist nur so gut wie die Daten darunter. Zugriffsrechte klären, Dubletten und veraltete Stände markieren, Formate erschließbar machen. Wer diesen Schritt überspringt, baut eine Maschine, die selbstbewusst aus veralteten Ständen zitiert.
3. Wissensbasis aufbauen und mit einer Pilotgruppe scharf schalten. Ein Team, ein abgegrenzter Wissensbereich, echte Alltagsfragen. Die Trefferqualität wird gemessen, nicht behauptet — und das System an den Fragen nachgeschärft, die danebengehen.
4. Kopfwissen gezielt nacherfassen. Erst jetzt lohnt das Gespräch mit dem Kollegen, der geht: Die Wissensbasis zeigt, wo die Lücken sind. Statt „schreib alles auf” heißt es dann „erzähl uns die Geschichte hinter diesen zwölf Entscheidungen” — strukturierte Interviews, die direkt in den Bestand einfließen. Das respektiert seine Zeit und trifft das Wissen, das wirklich fehlt.
Die Grenzen — ehrlich benannt
Damit kein falscher Eindruck entsteht: Eine Wissensbasis ersetzt keine Erfahrung. Das Urteil, welche der drei dokumentierten Lösungen zur neuen Situation passt, bleibt Ingenieursarbeit. Drei Grenzen gehören zu jeder ehrlichen Beratung dazu:
- Die Qualität hängt an den Quellen. Was nie dokumentiert wurde, kann kein System hervorholen. Die Wissensbasis macht Vorhandenes auffindbar — Schritt 4 schließt gezielt die wichtigsten echten Lücken.
- Ohne Pflegeprozess veraltet sie. Neue Projekte, neue Erkenntnisse müssen einfließen. Das ist ein definierter Prozess in der laufenden Betreuung, kein Selbstläufer.
- Governance ist Pflicht. Wer darf was abfragen? Gehaltslisten und Konstruktionsdaten gehören nicht in denselben Index. Zugriffskonzept und Freigaberegeln entstehen vor dem ersten Import — nicht nach dem ersten Vorfall.
Aus eigener Praxis
Wir empfehlen nichts, was wir nicht selbst betreiben: In unserer eigenen Organisation beantwortet eine self-hosted Wissensbasis täglich Kunden- und interne Anfragen — mit Quellenbeleg, unter menschlicher Aufsicht an den kritischen Punkten. Denselben Aufbau bringen wir in Entwicklungsabteilungen, bevor das Wissen dort in Rente geht.
Die unbequeme Wahrheit zum Schluss: Der beste Zeitpunkt für dieses Projekt war vor fünf Jahren — der zweitbeste ist, solange der Kollege noch da ist. Danach wird aus Wissenssicherung Archäologie.