Wissensmanagement ist das Organisationsgedächtnis mit CLI-Seele

Wissensmanagement ist das Organisationsgedächtnis mit CLI-Seele

Die meisten Wissensmanagementsysteme sind Archive: ein Ordner, der sammelt, und eine Suchmaske, die vergisst. Das bessere Modell behandelt Wissen als Infrastruktur — jedes Dokument, jede Entscheidung, jede Änderung wird indexiert, verknüpft und in natürlicher Sprache abfragbar. Doch um das zu bauen, hilft es zu verstehen, was hier eigentlich verwaltet wird — und warum die meisten Versuche, „Wissen zu managen“, schon scheiterten, bevor der moderne Stack überhaupt existierte.

Was „Wissensmanagement“ lösen sollte

Das Fachgebiet ist nicht neu. Als akademische und beratende Disziplin formte sich Wissensmanagement in den 1990er-Jahren, und sein prägender Frühtext war Working Knowledge: How Organizations Manage What They Know von Thomas H. Davenport und Laurence Prusak, erschienen 1998 bei Harvard Business School Press.[5] Davenport, ein Wirtschaftsprofessor mit Schwerpunkt auf Analytics, Prozessinnovation und Wissensmanagement, gab der Disziplin im Wesentlichen ihren Namen und ihr Forschungsprogramm.[5]

Die Kernidee war, dass Organisationen jedes Mal Wert verlieren, wenn eine mühsam erworbene Erkenntnis im Kopf einer einzelnen Person bleibt. Wissensmanagement zielte darauf ab, das kollektive Wissen einer Organisation zu erfassen, zu teilen und wiederzuverwenden — nicht nur Dokumente zu speichern, sondern zu verhindern, dass die Organisation dieselben Dinge neu lernt oder sie vergisst, wenn die Wissensträger:in geht.

Der alte Stack konnte Wissen nicht von Information trennen

Das klassische Modell ist die DIKW-Hierarchie: Daten → Information → Wissen → Weisheit. Ihre genaue Herkunft ist unklar, aber das Modell wurde in den 1980er-Jahren durch die Arbeiten von Milan Zeleny, Russell Ackoff und Robert W. Lucky populär.[1]

Der entscheidende Unterschied liegt hier zwischen Information und Wissen. Information ist die Tatsache; Wissen ist der Rahmen, um darauf zu handeln. Zeleny argumentierte, dass Wissen, sobald es in symbolischer Form erfasst wird, tatsächlich zu Information wird — woraus er schloss: „All knowledge is tacit.“[1] Genau diese Behauptung ist der Grund, warum Archive scheitern: Wenn Wissen nicht niedergeschrieben werden kann, ohne den „Wissens“-Anteil zu verlieren, dann ist ein Ordner voller Dokumente immer nur ein Archiv von Informationen, nicht von Wissen. Davenports viel zitierte Definition bringt das auf den Punkt: Wissen sei „eine fließende Mischung aus gerahmter Erfahrung, Werten, kontextueller Information und Expertenwissen“, die „in den Köpfen der Wissenden“ lebt und oft nur teilweise in Dokumente und Routinen einfließt.[1]

Implizites vs. explizites Wissen: Polanyi

Der tiefere Grund, warum Archive vergessen, ist, dass ein großer Teil des Wissens nie niedergeschrieben wurde — und nicht niedergeschrieben werden kann.[2] Der Philosoph und Chemiker Michael Polanyi prägte den Begriff des tacit knowledge in Personal Knowledge (1958) und schärfte ihn in The Tacit Dimension (1966) mit der These „we can know more than we can tell“.[2] Für Polanyi ist tacit knowing nicht einfach Wissen, das schwer zu artikulieren ist — alles Wissen wurzelt in tacit knowledge, und das meiste davon ist selbst erfahrenen Praktiker:innen nicht „explizit“ bewusst.[2]

Sie wissen, wie man Fahrrad fährt, eine Schweißnaht beurteilt oder eine Stimmung im Raum liest — aber Sie können diese Fähigkeit nicht vollständig in einem Dokument kodieren. Genau diese Lücke ist der Grund, warum „Schreib es auf“ notwendig, aber nie ausreichend ist.

Das SECI-Modell — Nonaka und Takeuchi

Wie wird tacit knowledge überhaupt zu organisationalem Wissen? Diese Frage beantworteten Ikujiro Nonaka und Hirotaka Takeuchi mit dem SECI-Modell der Wissensdimensionen (SECI = Sozialisierung, Externalisierung, Kombination, Internalisierung), das Nonaka ursprünglich 1990 entwickelte und später mit Takeuchi verfeinerte.[3] Es erklärt, wie tacit und explicit knowledge in organisationales Wissen umgewandelt werden — und vor allem zielt es darauf ab, explicit knowledge zurück in das tacit knowledge der Mitarbeiter:innen zu überführen, damit das Wissen tatsächlich in der Organisation bleibt.[3]

Die vier Umwandlungen sind: tacit zu tacit (Sozialisierung, Weitergabe durch Praxis), tacit zu explicit (Externalisierung, das Artikulieren von Wissen), explizit zu explizit (Kombination, die Synthese von Dokumenten), und explizit zurück zu implizit (Internalisierung, das Verinnerlichen der Dokumente in die eigene Arbeitsweise).[3] Der entscheidende Punkt für alle, die ein Wissenssystem aufbauen: Ein statisches Archiv leistet nur „Kombination“. Es erfasst keine Sozialisierung, Externalisierung oder Internalisierung — genau dort entsteht jedoch der horizontale, dokumentübergreifende Mehrwert.

Communities of Practice – Wenger

Bevor Wissen zu einem Dokument wird, lebt es in einer Gruppe. Das Konzept der Community of Practice , das Jean Lave und Etienne Wenger in Situated Learning (1991) vorstellten und Wenger in Communities of Practice (1998) weiterentwickelte, beschreibt eine Gruppe von Menschen mit gemeinsamen Interessen, die durch regelmäßigen Austausch voneinander lernen.[4] Wenger unterteilte die Struktur in drei Teile: ein Wissensgebiet , das eine gemeinsame Grundlage schafft, eine Community , die Identität und Zugehörigkeit stiftet, und eine Praxis , in der sich die tatsächlichen Arbeitsweisen ansammeln.[4]

Das ist der eigentliche Ursprung des meisten Organisationswissens: Es entsteht in Communities (Teams, Gilden, Praktikergruppen) durch legitime periphere Partizipation — Neue lernen durch Mitmachen von erfahrenen Mitgliedern.[4] Ein Retrieval-System ersetzt das nicht. Es ermöglicht lediglich, die Artefakte, die die Community produziert — Diffs, Entscheidungen, Postmortems –, für die nächste Community nutzbar zu machen.

Was ein Archiv trotzdem falsch macht

Ordner und Suchfelder scheitern an allen drei Theorien zugleich. Sie behandeln Wissen als Information (DIKW), gehen davon aus, dass implizites Wissen explizit gemacht wurde (Polanyi), und überspringen den Umwandlungszyklus (SECI). Zudem präsentieren sie Wissen ausschließlich in vertikaler Struktur.

Dokumente sind eine vertikale Struktur — ein Thema, von oben nach unten. Entity-Extraktion und Clustering erfassen die horizontale Wiederkehr von Themen über viele Dokumente hinweg. Diese dokumentübergreifende Sicht macht aus einem Stapel Dateien ein Organisationsgedächtnis. Eine Wissensbasis, die nicht beantworten kann „Welche drei Teams haben diesen Service angefasst, und warum ist er instabil?“, bleibt ein Archiv.

Ein moderner Retrieval-Stack

Der moderne Stack verwandelt eine Frage in eine fundierte Antwort, indem er sie durch Chunking, Embeddings und Retrieval leitet, bevor die Generierung erfolgt. Retrieval-augmented generation (RAG) — der Begriff wurde 2020 in einem Paper von Lewis et al. eingeführt — verankert LLM-Ausgaben in externen, häufig aktualisierten Quellen, gibt die Quellen in den Antworten mit an, sodass Nutzer:innen sie überprüfen können, und reduziert den Bedarf, das Modell mit neuen Daten nachzutrainieren.[8] Das ist der „CLI-Soul“-Teil: Statt einen Ordnerbaum zu durchsuchen, stellt man eine Frage in natürlicher Sprache, und die Antwort kommt mit den Dokumenten zurück, aus denen sie generiert wurde.

Doch RAG hat einen bekannten blinden Fleck. Das GraphRAG-Paper von Microsoft (arXiv:2404.16130) zeigt, dass herkömmliches Retrieval Schwierigkeiten hat, „die Punkte zu verbinden“, wenn eine Antwort das Kombinieren disparater Informationen aus einem Korpus erfordert, und bei ganzheitlichen Sinnfragen schlecht abschneidet.[9] Ihre Lösung: Aus den Quelldokumenten wird ein Entity-Wissensgraph abgeleitet und vorab Community-Zusammenfassungen für Gruppen verwandter Entitäten, sodass globale Fragen eine Synthese statt eines Stapels passender Chunks erhalten.[9]

Warum der Graph hilft

Ein Wissensgraph ist eine Wissensbasis, die ein graphenstrukturiertes Modell nutzt, um Daten abzubilden und zu verarbeiten — verknüpfte Beschreibungen von Entitäten (Objekte, Ereignisse, Konzepte) sowie die semantischen Beziehungen zwischen ihnen.[7] Graphdatenbanken speichern Verbindungen als erstklassige Bürger: Daten als Knoten und Kanten, wobei Beziehungen direkt vorgehalten werden, sodass sie in einem einzigen Schritt traversiert werden können.[14] Das Abfragen von Beziehungen ist schnell, weil sie permanent gespeichert sind — eine Eigenschaft namens indexfreie Adjazenz —, weshalb sich Graphdatenbanken für stark vernetzte Daten eignen.[14]

Diese strukturelle Ehrlichkeit ist genau das, was organisatorisches Gedächtnis braucht:

• Verbindungen werden direkt gespeichert, nicht mit Fremdschlüsseln angehängt.
• Pfade sind nachvollziehbar — Sie können die exakte Kette von Dokumenten und Entscheidungen hinter einer Antwort aufzeigen.
• Stabile, stark vernetzte Daten belohnen die Struktur; volatile, unverbundene Einmaldaten nicht.

Neo4j ist das Flaggschiff der kommerziellen ACID-Graphdatenbank-Bewegung, die dies ab Mitte der 2000er-Jahre praxistauglich machte.[14][15] Und das Anbieter-Ökosystem hat seine eigene Produktlinie seitdem auf „Wissensebene + GraphRAG“ als explizite Produktkategorie ausgerichtet.[15]

Die Werkzeuge — ehrlich positioniert

Jedes ernstzunehmende Werkzeug behauptet heute den Graph- plus Retrieval-Pivot, doch sie besetzen unterschiedliche Positionen im Spektrum:

• Notion — „der KI-Arbeitsbereich“, der eine Enterprise Search und eine Wissensbasis explizit bewirbt: „Zentralisieren Sie Ihr Wissen.“ Es handelt sich um ein Wiki-großes Archiv mit aufgesetzter KI-Retrieval.[10]
• Obsidian — local-first, Plain-Text-Markdown-Notizen, eine graph view, Backlinks und die Aussage, man könne „sein eigenes persönliches Wiki aufbauen“ und „seine Daten langfristig besitzen“. Am nächsten am Graph-first-Ideal für ein persönliches oder kleines Team-Vault.[11]
• Confluence (Atlassian) — „der eine Ort für alle Ihre Ideen, Dokumente, Wissen und menschlichen+KI-Teammitglieder“, jetzt mit Team-Workspaces und KI-Suche.[12] Team-Wiki + KI obendrauf.
• Microsoft Loop — ein kollaborativer Online-Arbeitsbereich aus teilbaren, Echtzeit-„Blöcken“, die zwischen Teams, Outlook, Word und Whiteboard kopiert und eingefügt werden können.[13] Wissen als komponierbare Bausteine statt als Ordner.
• Wissensgraph-Anbieter (Neo4j u. a.) — die Infrastruktur, die das Organisationsgedächtnis-Modell real macht: vernetzte Daten speichern, GraphRAG ausführen und Agenten antreiben.[15]

Die ehrliche Lesart: Fast alle verkaufen eine Suchmaske. Die Organisationen, die tatsächlich ein Organisationsgedächtnis aufbauen, sind jene, die Wissen nicht mehr als Dokumentenarchiv behandeln, sondern als vernetzte, abfragbare Infrastrukturebene — die „CLI-Seele“ unter dem Wiki.

Das Fazit

Wissen ist kein Ordner. Polanyi wusste, dass es sich nicht vollständig niederschreiben lässt; Nonaka zeigte, dass es durch Menschen zirkulieren muss; Wenger bewies, dass es in der Praxis entsteht; DIKW macht deutlich, dass das Niederschreiben eigentlich eine Kodierung in Information ist. Der moderne Stack — Embeddings, Retrieval und ein Graph — ist der erste ehrliche Versuch, dieses organisationale Wissen überhaupt abfragbar zu machen, ohne vorzugeben, ein Dokumenten-Dump sei Wissen. Behandeln Sie Wissen als Infrastruktur, nicht als Archiv. Das ist das Organisationsgedächtnis mit CLI-Seele.

Quellen

[1] https://en.wikipedia.org/wiki/DIKW_pyramid — DIKW pyramid [2] https://en.wikipedia.org/wiki/Tacit_knowledge — Tacit knowledge [3] https://en.wikipedia.org/wiki/SECI_model_of_knowledge_dimensions — SECI model [4] https://en.wikipedia.org/wiki/Community_of_practice — Community of practice [5] https://en.wikipedia.org/wiki/Thomas_H._Davenport — Thomas Davenport [7] https://en.wikipedia.org/wiki/Knowledge_graph — Knowledge graph [8] https://en.wikipedia.org/wiki/Retrieval-augmented_generation — Retrieval-augmented generation [9] https://arxiv.org/abs/2404.16130 — GraphRAG paper [10] https://www.notion.com/product — Notion product [11] https://obsidian.md — Obsidian [12] https://www.atlassian.com/software/confluence — Atlassian Confluence [13] https://en.wikipedia.org/wiki/Microsoft_Loop — Microsoft Loop [14] https://en.wikipedia.org/wiki/Graph_database — Graph database [15] https://neo4j.com/product — Neo4j product