Warum Wissensmanagement in Beratungen scheitert – und was ein Wissensgraph anders macht

In Beratungen ist Wissen das eigentliche Produkt, und trotzdem baut ein Team oft eine Methodik-Folie neu, die es irgendwo schon gibt. Wikis und Lessons-Learned-Datenbanken lösen das selten, weil sie nur eine von zwei Arten von Wissen bedienen und weil kaum jemand sie nutzt. Ein Wissensgraph setzt an beiden Stellen an, ersetzt aber weder das Gespräch mit Kollegen noch eine Kultur, in der Projekte überhaupt dokumentiert werden.

„Das hatten wir doch schon einmal“

Ein Angebot soll bis Donnerstag raus. Die Partnerin fragt im Team-Kanal: „Hatten wir nicht 2024 eine Kostensenkung bei einem Versorger? Wer war da dabei, und gibt es noch das Vorgehensmodell?“ Dann beginnt die Suche. Jemand durchsucht SharePoint nach „Stadtwerk“, findet drei Ordner mit Projektkürzeln, die niemand mehr zuordnen kann, und eine Abschlusspräsentation in der siebten Fassung. Ein Kollege erinnert sich an den Projektleiter, der aber inzwischen die Firma gewechselt hat. Am Ende baut das Team die Methodik-Folie neu, obwohl sie irgendwo existiert.

Das ist kein Ordnungsproblem einzelner Mitarbeitender. In Beratungen ist Wissen das eigentliche Produkt, und es entsteht verteilt: in Angeboten, Workshop-Protokollen, Excel-Modellen, Mails an den Mandanten und vor allem in den Köpfen derer, die das Projekt gemacht haben.

Warum Wikis und Ordnerstrukturen in Beratungen selten tragen

Beratungen haben zwei Arten von Wissen, und Ablagen bedienen nur eine. Hansen, Nohria und Tierney haben 1999 untersucht, wie Beratungsfirmen Wissen managen ^[1]. Sie unterscheiden zwei Strategien: Bei der Kodifizierung wird Wissen in Dokumente gegossen und in Datenbanken abgelegt, damit andere es ohne Rücksprache wiederverwenden können. Als Beispiele nennen sie Andersen Consulting und Ernst & Young. Bei der Personalisierung bleibt das Wissen an die Person gebunden, die es erarbeitet hat, und wird im direkten Gespräch weitergegeben; Computer dienen dort vor allem dazu, Wissen zu kommunizieren, nicht es zu speichern – bei Bain etwa über eine „People Finder“-Datenbank, mit der Berater passende Kollegen suchen. Als Beispiele nennen sie Bain, die Boston Consulting Group und McKinsey. Ihre Empfehlung: eine Strategie zu etwa 80 Prozent verfolgen, die andere zu 20 Prozent. Für Strategieberatungen halten sie fest, dass alle untersuchten Firmen mit dokumentgetriebenen Systemen Probleme bekamen, weil Berater versucht waren, Standardlösungen zu liefern, wo der Mandant für Maßarbeit bezahlte.

Ein Wiki oder ein Ordnerbaum beantwortet nur die Kodifizierungsfrage („Wo ist das Dokument?“). Die Frage, die in Beratungen oft wichtiger ist – „Wer hat das schon einmal gemacht, und wen frage ich?“ –, bleibt offen.

Vieles wird nie aufgeschrieben. Nonaka beschreibt organisationales Wissen als fortlaufenden Dialog zwischen implizitem und explizitem Wissen ^[2]. Warum ein Vorgehen bei einem bestimmten Mandanten funktioniert hat, welcher Ansprechpartner wirklich entscheidet, welche Annahme im Modell wackelig war: Das steht selten in der Abschlusspräsentation. Ein Wiki hält nur, was jemand ausdrücklich hineinschreibt.

Lessons-Learned-Datenbanken werden befüllt, aber kaum genutzt. Newell und Kollegen haben 13 Projekte in sechs Organisationen untersucht ^[3]. Ihr Befund: Teams halten „Lessons Learned“ fest und legen sie in Datenbanken ab, eine verbreitete Praxis, doch diese Datenbanken werden kaum genutzt. Die Gründe: Das Festgehaltene gilt als nicht nützlich, oder die Teams wissen gar nicht, dass es dort etwas Nützliches gäbe. Beides trifft Beratungen besonders. Am Projektende ist das Team schon im nächsten Mandat, und das Lessons-Learned-Dokument entsteht unter Zeitdruck.

Ordner sortieren nach einer Achse, Fragen kommen quer. Ein Ordnerbaum ist nach Kunde, Jahr oder Geschäftsbereich gegliedert. Die Fragen im Angebotsalltag kreuzen diese Achsen: „Welche Projekte zur Netzentgelt-Regulierung hatten wir, egal bei welchem Kunden, und wer hat die Methodik dafür entwickelt?“ Keine Ordnerstruktur kann alle Kombinationen gleichzeitig abbilden.

Was ein Wissensgraph anders macht

Ein Wissensgraph speichert nicht nur Dokumente, sondern die Dinge, um die es darin geht, und ihre Beziehungen: Kunde, Projekt, Angebot, Methode, Person, Behörde. Aus „Das Angebot 2024-017 ging an Kunde A, nutzte die Methode Marktscreening, Projektleitung hatte Frau K.“ werden Knoten und Verbindungen, die man in jede Richtung abfragen kann. Hogan und Kollegen geben einen Überblick über Datenmodelle, Abfragesprachen und darüber, wie solches Wissen aus Daten gewonnen wird ^[4].

Der Unterschied zur Volltextsuche oder zu einer reinen Wissensdatenbank mit Ähnlichkeitssuche liegt in der Art der Frage. Eine Suche findet Textstellen, die der Frage ähneln. Für Fragen über einen ganzen Bestand („Welche Methoden haben wir in Versorger-Projekten eingesetzt?“) reicht das oft nicht. Forscher von Microsoft beschreiben genau diese Schwäche: Retrieval-Verfahren scheitern an globalen Fragen, die sich an einen ganzen Textkorpus richten ^[5]. Ihr Ansatz baut mit einem Sprachmodell zuerst einen Graphen aus Entitäten und fasst eng verbundene Gruppen zusammen. In ihren Tests auf Datensätzen von rund einer Million Tokens lieferte das deutlich umfassendere und vielfältigere Antworten als ein herkömmliches Retrieval-Verfahren.

Für Beratungen ist ein zweiter Punkt wichtiger: Ein Graph kennt auch Personen und Teams. Er unterstützt damit beide Strategien aus ^[1] – er findet das Dokument und nennt die Menschen, die man dazu fragen sollte.

Was ein Wissensgraph nicht leistet: Er macht implizites Wissen nicht explizit. Er zeigt, wer beteiligt war, aber nicht, was diese Person im Kopf hat. Und er ist nur so gut wie die automatische Zuordnung. Dazu mehr im nächsten Abschnitt.

Das Thema ist in Unternehmen angekommen: Laut Bitkom setzen 22 Prozent der befragten Unternehmen KI im internen Wissensmanagement ein, nach 11 Prozent im Vorjahr ^[6].

Was ein Wissensgraph nicht kann

• Implizites Wissen bleibt implizit. Ein Graph findet, was in Dokumenten, Mails und Folien steht. Was nur im Kopf eines Kollegen ist, findet er nicht. Er zeigt aber, wer beteiligt war, und damit, wen Sie fragen sollten.
• Zuordnungen sind maschinell und können falsch sein. Zwei Projekte mit ähnlichem Kürzel, zwei Personen mit gleichem Namen oder ein Kunde, der umfirmiert hat: Hier kann die automatische Verknüpfung danebenliegen.
• Rechte werden übernommen, wie sie gepflegt sind. Ist ein SharePoint-Ordner zu weit freigegeben, gilt das auch für jedes System, das diese Rechte übernimmt.
• Ob Wissen aus Mandat A in Mandat B verwendet werden darf, entscheidet nicht die Software. Vertraulichkeitsvereinbarungen, Clean-Team-Regeln oder Wettbewerbskonflikte muss ein Mensch beurteilen.
• Viele Fassungen, unklare Gültigkeit. Liegen zehn Versionen derselben Präsentation in der Ablage, kann eine Antwort auf eine ältere Fassung verweisen.
• Keine Wissenskultur auf Knopfdruck. Wenn Projekte nie dokumentiert werden, gibt es auch nichts zu finden.

Was das für die Praxis heißt

• Beide Fragen bedienen. Ein System für Beratungen sollte nicht nur „Wo ist das Dokument?“ beantworten, sondern auch „Wer hat das gemacht?“. Hansen, Nohria und Tierney nennen Bain, BCG und McKinsey als Beispiele für Personalisierung; Strategieberatungen mit dokumentgetriebenen Systemen bekamen Probleme ^[1].
• Nicht auf ein separates Wiki bauen. Was zusätzlich abgetippt werden muss, entsteht am Projektende unter Zeitdruck und wird dann kaum gelesen ^[3]. Besser ist ein System, das die vorhandenen Ablagen liest, wie sie sind.
• Einen kurzen Projektabschluss beibehalten. Ergebnis und Methodik in wenigen Sätzen festzuhalten bleibt sinnvoll; das Dokument muss nur dort liegen, wo ohnehin gearbeitet wird.
• Fundstellen prüfen, bevor eine Referenz nach außen geht. Datum und Ablageort zeigen, ob eine Fassung noch gilt.
• Vertraulichkeit vorher klären. Bestände, die nie ins gemeinsame Wissen gehören, gehören gar nicht erst angebunden. Bei Postfächern lohnt es sich, Datenschutzbeauftragte und Betriebsrat früh einzubeziehen.

Wie enter ai das umsetzt

enter ai liest Dokumente, Mails, Tabellen, Folien und Diagramme aus den Systemen, die Sie verbinden, und ordnet sie zu einem Company Brain: Kunden, Projekte, Angebote, Methoden und die beteiligten Personen. Es gelten die Zugriffsrechte der Quellsysteme. Fragen beantwortet es mit Fundstelle; digitale Kollegen stellen daraus Referenzlisten oder Methodik-Abschnitte zur Freigabe zusammen. Wie das konkret abläuft, zeigt der Anwendungsfall Wissensmanagement mit einem Company Brain.