Ist das nicht primär ein HR-Thema?

Nein. HR kann den Abgang von Mitarbeitern managen, Nachfolgeplanung betreiben, Einarbeitungsprozesse strukturieren. Was HR nicht kann: das operative Wissen, das mit einem Mitarbeiter geht, identifizieren, extrahieren und in nutzbare Form bringen. Das ist eine Schnittstellenaufgabe zwischen Operations, IT und einer strukturierten Methodik. Wer es als reines HR-Thema behandelt, löst das Symptom, nicht das Problem.

Wir haben bereits ein Dokumentenmanagementsystem. Reicht das nicht?

Ein DMS erfasst, was Menschen bereit und in der Lage sind einzugeben. Es löst nicht das grundlegende Problem: dass das wertvollste operative Wissen nicht in Dokumenten steckt, sondern in Köpfen, und dass die meisten Systeme keine Hilfestellung bieten, dieses Wissen zu extrahieren und zu strukturieren. Ein DMS ist notwendig, aber nicht das Instrument, das implizites Wissen sichtbar macht.

Wie lange dauert es, bis wir Ergebnisse sehen?

Das hängt vom Ausgangszustand ab. Die erste Phase, Bestandsaufnahme und Priorisierung, ist in vier bis sechs Wochen abgeschlossen und liefert bereits ein konkretes Bild des Risikoprofils. Erste strukturierte Wissensextraktion für kritische Rollen kann innerhalb von drei Monaten beginnen. Ein vollständig funktionsfähiges Retrieval-System auf Basis des erfassten Wissens ist ein Projekt mit einer Dauer von sechs bis zwölf Monaten, je nach Umfang und vorhandener Infrastruktur.

Müssen wir auf Cloud-Infrastruktur setzen?

Nicht zwingend. Für Unternehmen mit strikten Datenschutzanforderungen oder Sicherheitsauflagen gibt es On-Premises-Architekturen, die dieselbe Funktionalität liefern. Die Modelle, die für strukturierte Wissensextraktion und Retrieval benötigt werden, sind nicht notwendigerweise die großen, ressourcenintensiven Modelle der Hyperscaler. Die Architekturentscheidung sollte aus den Anforderungen folgen, nicht aus der Verfügbarkeit von Cloud-Angeboten.

Was, wenn unsere Datenqualität schlecht ist?

Das ist die häufigste Ausgangssituation. Servicereports sind unvollständig, Fehlerprotokolle inkonsistent, Wartungsaufzeichnungen lückenhaft. Das ist kein Ausschlusskriterium, beeinflusst aber den Ansatz. Ein realistischer erster Schritt ist oft, die Datenerfassung für kritische Anlagen und Prozesse zu verbessern, parallel zur Wissensextraktion aus bestehenden Quellen. Wer mit der Infrastruktur wartet, bis die Daten perfekt sind, wartet zu lange.

Der stille Wertverlust: Knowledge Drain in der Produktion

Es gibt ein Risiko in produzierenden Unternehmen, das weder in einem Risikoregister steht noch in einer Investitionsplanung auftaucht und von keinem Auditor bemängelt wird. Es ist in der GuV nicht erfasst. Es löst keine Alarme aus. Und doch untergräbt es die operative Leistungsfähigkeit von Unternehmen leiser und dauerhafter als die meisten Faktoren, über die in Führungsrunden gesprochen wird.

Knowledge Drain. Der schleichende Abfluss operativer Expertise aus Organisationen.

Nicht durch Datenlecks. Nicht durch Cyberangriffe. Sondern durch das Normalste der Welt: Menschen gehen in Rente, wechseln den Arbeitgeber, werden krank. Und sie nehmen mit, was nirgendwo aufgeschrieben steht.

Was Knowledge Drain wirklich bedeutet

Die meisten Gespräche über Knowledge Drain bleiben an der Oberfläche. Es geht um Dokumentation, Übergaben, Wissensmanagement-Systeme. Das sind Symptombehandlungen.

Das eigentliche Problem ist tiefer: In produzierenden Unternehmen steckt ein erheblicher Teil des operativen Wissens nicht in ERP-Systemen, in Wartungshandbüchern oder in Prozessdokumentation. Es steckt in Menschen.

Konkret: Der Instandhaltungsleiter, der nach zwanzig Jahren Betriebszugehörigkeit weiß, dass Anlage 7 bei einer Luftfeuchte von über 70 Prozent anders reagiert. Der Produktionstechniker, der durch Gehör erkennt, wann eine Maschine aus dem Toleranzbereich läuft. Der Schichtführer, der intuitiv weiß, welche Parameterkombinationen zu Ausschuss führen, weil er es hundert Mal erlebt hat.

Dieses Wissen ist nicht dokumentiert, weil es schwer zu dokumentieren ist. Es ist kontextuell, situativ, sensorisch. Es entsteht durch jahrelange Erfahrung mit einem spezifischen System in einer bestimmten Umgebung. Und es ist betriebskritisch.

Der Moment, in dem es die Organisation verlässt, ist selten dramatisch. Es gibt keinen Systemausfall. Keine Fehlermeldung. Erst Wochen oder Monate später, wenn eine Anlage häufiger ungeplante Stillstände hat, wenn die Ausschussquote langsam steigt, wenn die Einarbeitungszeit für neue Mitarbeiter immer länger wird, dann wird das Fehlen spürbar.

Dann ist es zu spät, um es zurückzuholen.

Warum das Problem jetzt eskaliert

Knowledge Drain ist kein neues Phänomen. Aber es hat einen strukturellen Charakter angenommen, der in den nächsten Jahren für viele Unternehmen zur ernsthaften Belastung wird.

Der Grund ist demografisch bedingt und wurde jahrelang verdrängt: Die Generation, die in den 1980er- und 1990er-Jahren in den produzierenden Sektor eingetreten ist, verlässt ihn jetzt. Gleichzeitig. In der Breite.

Das ist keine Prognose. Es ist eine laufende Bewegung.

Hinzu kommt ein Effizienzdruck der letzten zwei Jahrzehnte, der in vielen Unternehmen dazu geführt hat, Wissensüberlappung als Redundanz zu behandeln. Wo früher zwei erfahrene Mitarbeiter parallel an einem System arbeiteten und Wissen organisch weitergegeben wurde, arbeitet heute oft einer. Wenn dieser geht, gibt es niemanden, der das informelle Wissen bereits erworben hat.

Und schließlich: Die Komplexität der Systeme ist gestiegen. Moderne Produktionsanlagen sind vernetzt, softwaregesteuert, mit Sensorik durchzogen. Das Wissen, das es braucht, um sie verlässlich zu betreiben, ist nicht mehr in einem Handbuch fassbar.

Warum bisherige Ansätze nicht reichen

Die übliche Reaktion auf Knowledge Drain ist Dokumentation. Prozesshandbücher, Betriebsanweisungen, Übergabeprotokolle. Das ist notwendig. Aber es ist nicht hinreichend.

Dokumentation erfasst explizites Wissen: Was zu tun ist, wenn Zustand X eintritt. Was in bestimmten Situationen vorgeschrieben ist.

Was sie nicht erfasst, ist das implizite Wissen: Warum eine erfahrene Person Situation X von Situation Y unterscheidet, obwohl die Messwerte ähnlich aussehen. Wie man zwischen einem Muster, das sich noch im Toleranzbereich bewegt, und einem, das kurz vor dem Ausreißen ist, unterscheidet. Welche Kombination aus Erfahrungswerten, Kontextinformationen und schwer beschreibbaren Indikatoren zu einer Entscheidung führt.

Wissensmanagement-Systeme haben dasselbe Problem, nur in digitaler Form: Sie erfassen, was Menschen eingeben. Sie erfassen nicht, was Menschen wissen, aber nie artikuliert haben, weil es bisher nicht nötig war.

Das Ergebnis: Unternehmen investieren in Dokumentationssysteme und stellen fest, dass sie nach dem Abgang des erfahrenen Mitarbeiters dennoch vor denselben Fragen stehen.

Wo KI tatsächlich hilft, und wo nicht

Hier beginnt die nüchterne Einschätzung.

KI wird in der Diskussion um den Knowledge Drain inzwischen als Universallösung gehandelt. Das ist die falsche Erwartungshaltung. Aber es gibt einen spezifischen, gut definierten Bereich, in dem KI – insbesondere große Sprachmodelle – echten Wert liefert.

Zunächst das klare Nein: LLMs gehören nicht in Echtzeit-Steuerungssysteme. Sie sind zu langsam (200 bis 500 Millisekunden Latenz sind in einem Regelkreis inakzeptabel), zu probabilistisch (Produktionssysteme brauchen deterministische Entscheidungen, keine wahrscheinlichen Antworten) und zu kontextabhängig in ihren Ausgaben. Wer LLMs für Echtzeit-Maschinensteuerung evaluiert, hat das Architekturprinzip missverstanden.

Das Ja ist präziser und substanzieller:

Wissensextraktion aus unstrukturierten Quellen. Servicereports, Fehlerprotokolle, Wartungsaufzeichnungen, interne E-Mails: Diese Datenquellen gibt es in praktisch jedem Produktionsbetrieb. Sie sind selten systematisch ausgewertet, weil der Aufwand für manuelle Analyse zu hoch ist. LLMs können Muster erkennen, Zusammenhänge herstellen, Anomalien kennzeichnen, und zwar nicht in Echtzeit, sondern in analytischen Prozessen, die täglich oder wöchentlich laufen.

Strukturierter Wissenstransfer. Wenn ein erfahrener Mitarbeiter interviewt wird, entstehen unstrukturierte Aussagen: “Ich würde in dieser Situation auf X achten, weil Y normalerweise bedeutet, dass Z kommt.” Ein LLM kann dabei helfen, diese Aussagen in strukturierte Wissensrepräsentationen zu überführen: Wenn-dann-Logiken, Entscheidungsbäume, annotierte Fehlerklassifikationen. Nicht als Ersatz für das menschliche Gespräch, sondern als strukturierendes Werkzeug danach.

Durchsuchbare Wissensbasen aus bestehenden Dokumenten. Handbücher, Zeichnungen, Spezifikationen, Prüfprotokolle. Der Großteil dieses Materials ist vorhanden, aber nicht zugänglich, weil die Suche darin zu aufwendig ist. Ein gut konfiguriertes Retrieval-System auf Basis von LLMs macht dieses Wissen operativ nutzbar, ohne es neu zu erzeugen.

Diagnoseunterstützung mit menschlichem Review. Nicht: Die KI entscheidet. Sondern: Die KI analysiert Fehlermuster aus historischen Daten, schlägt wahrscheinliche Ursachen vor, und ein Mensch bewertet und entscheidet. Das ist die richtige Rollenverteilung. Sie reduziert den kognitiven Aufwand für den Techniker und erhöht gleichzeitig die Konsistenz der Diagnose.

Der gemeinsame Nenner dieser Anwendungen: Sie respektieren die Grenze zwischen dem, was ein Sprachmodell strukturell kann (Muster in Sprache und Text erkennen, strukturieren, zusammenführen), und dem, was ein industrielles System braucht (Verlässlichkeit, Determinismus, Latenz). Planung statt Steuerung. Entscheidungsvorbereitung statt Entscheidungsausführung.

Was eine ernsthafte Herangehensweise erfordert

Den Knowledge Drain als technisches Problem zu behandeln, das sich mit dem richtigen Tool lösen lässt, ist der häufigste Fehler. Es handelt sich um ein organisatorisches Problem mit technischer Komponente.

Was das konkret bedeutet:

Der erste Schritt ist eine ehrliche Bestandsaufnahme. Welches Wissen existiert in der Organisation ausschließlich in Köpfen? Welche Rollen und Personen tragen dieses Wissen? Welcher zeitliche Horizont besteht, bevor dieses Wissen die Organisation verlässt?

Diese Analyse wird in den meisten Unternehmen nicht systematisch durchgeführt. Das Ergebnis ist, dass Handlungsbedarf erst sichtbar wird, nachdem der Abgang bereits erfolgt ist.

Der zweite Schritt ist die Priorisierung nach der Kritikalität. Nicht alles implizite Wissen ist gleich wichtig. Was betrifft Anlagen mit hoher Ausfallkritikalität? Was betrifft Prozesse, bei denen Fehler direkte Qualitäts- oder Sicherheitsfolgen haben? Was betrifft Systeme, für die externe Kompetenz schwer oder teuer zu beschaffen ist? Diese Priorisierung bestimmt, wo der Sicherungsaufwand gerechtfertigt ist.

Der dritte Schritt ist die Wahl der passenden Methoden für den jeweiligen Wissenstyp. Explizites Wissen: Dokumentation, Prozesshandbücher, strukturierte Übergaben. Implizites Wissen: geführte Interviews mit strukturierender KI-Unterstützung, Tandem-Phasen mit gezielter Dokumentation, annotierte Fallbeispiele aus realen Situationen.

Der vierte Schritt ist die technische Infrastruktur. Kein Tool rettet eine Wissensmanagement-Initiative, die organisatorisch nicht getragen wird. Aber das beste organisatorische Commitment scheitert an einer Infrastruktur, die zwar Wissen erfasst, es aber nicht zugänglich macht. Retrieval, Suchbarkeit, Integration in bestehende Systeme: Diese Anforderungen müssen von Anfang an mitgedacht werden.

Was ich dazu beobachten

Ich arbeite mit Unternehmen, die dieses Problem in unterschiedlichen Reifegraden angehen. Die häufigste Ausgangssituation: Das Problem ist bekannt, die Dringlichkeit ist gespürt, aber es fehlt ein strukturierter Ansatz, der über “wir müssen mehr dokumentieren” hinausgeht.

Was in der Praxis funktioniert, ist kein großes Transformationsprojekt. Es ist ein schrittweiser Ansatz: Mit den kritischsten Wissensträgern beginnen, einen strukturierten Extraktionsprozess entwickeln, der für die jeweilige Organisation handhabbar ist, und eine Infrastruktur aufbauen, die das erfasste Wissen operativ nutzbar macht.

Der Unterschied zwischen Projekten, die halten, und solchen, die versanden: Die erfolgreichen behandeln Wissensmanagement nicht als Einmalprojekt, sondern als fortlaufenden Prozess. Wissen entsteht kontinuierlich. Die Sicherung muss es auch.