Lessons-Learned-Auswertung

Das echte Ausmaß des Problems

Lessons-Learned-Sitzungen finden in der Beratungsbranche meistens statt. Das ist die gute Nachricht. Die schlechte: Die Ergebnisse ändern selten etwas am nächsten Projekt.

Eine Studie von Ernst & Young gemeinsam mit dem Project Management Institute (PMI, 2007) nennt als größtes Hindernis bei der Durchführung strukturierter Lessons-Learned-Sitzungen: „zu wenig Zeit” — nicht fehlende Methodik, nicht mangelnde Einsicht, sondern schlichtes Zeitbudget. Was erfasst wird, landet in einer Präsentation oder einer Datenbank, die zum Projektstart des nächsten Projekts kein Mensch öffnet. Laut PMI-Bibliothek ist der entscheidende Punkt nicht das Erfassen, sondern das Aktivieren: „Die meisten Organisationen haben den Prozess der Identifikation und Dokumentation institutionalisiert — aber selbst korrekt dokumentierte Erkenntnisse gehen verloren.”

Dass das kein Randproblem ist, belegt eine empirische Studie von Volker Nissen (TU Ilmenau, ResearchGate), die 92 deutschsprachige Beratungsunternehmen befragte: Wissensmanagement hat in Unternehmensberatungen zwar hohe strategische Relevanz — aber die Umsetzung bleibt weit hinter dem Anspruch zurück. Besonders in der Strategieberatung dominiert das Personalisierungsmodell: Wissen steckt in den Köpfen der Senior-Partner, wird mündlich weitergegeben und stirbt mit dem Wechsel von Mitarbeitenden.

Das führt zu einem konkreten Muster, das jede Beratung kennt:

• Risikoklassen werden neu erfunden. Jedes Projektteam erarbeitet von Grund auf eine Risikoeinschätzung für Themen, die bereits drei Mal in der Unternehmensgeschichte aufgetaucht sind.
• Junior-Berater lernen nur das, was ihr nächster Senior-Partner zufällig mitgibt. Wer im falschen Projekt startet oder dessen Partner wenig Zeit hat, lernt das institutionelle Wissen erst nach Jahren.
• Fluktuation löscht Erfahrung. Wenn der Partner, der den Change-Freeze erlebt hat, das Unternehmen verlässt, ist das Wissen weg — unabhängig davon, wie viele Dokumente er hinterlassen hat.

Ein Retrieval-Augmented Generation (RAG)-System kann an genau dieser Stelle eingreifen — aber nur unter bestimmten Voraussetzungen, die in der Praxis seltener erfüllt sind, als die Tool-Anbieter es versprechen.

Mit vs. ohne KI — ein ehrlicher Vergleich

¹ Schätzwert auf Basis strukturierter Interviews; keine repräsentative Studie.
² Optimistische Annahme bei vollständig befüllter, strukturierter Wissensbasis — in der Praxis oft 50–60 % erreichbar.

Das Wissen lässt sich tatsächlich aktivieren. Was nicht messbar ist: ob die abgerufene Lektion im nächsten Projekt auch angewendet wird — und ob das die Projektergebnisse messbar verbessert. Dieser Kausalzusammenhang bleibt schwer zu isolieren, was direkte Auswirkungen auf die ROI-Sicherheit hat.

Einschätzung auf einen Blick

Zeitersparnis — niedrig (2/5)
Bei Projektkickoffs und Risikoanalysen spart ein gut befülltes Lessons-Learned-System 30–60 Minuten Recherchezeit. Das ist real, aber verglichen mit anderen Beratungs-Anwendungsfällen — zum Beispiel Projektdokumentation automatisieren oder dem automatischen Projektabschlussbericht — ist der Hebel klein. Der Effekt materialisiert sich nur, wenn Berater aktiv nachfragen und das System tatsächlich in den Kick-off-Prozess eingebettet ist. Wenn es als optionales Nachschlagewerk positioniert wird, nutzt es niemand regelmäßig.

Kosteneinsparung — mittel (3/5)
Der theoretische Hebel ist groß: Ein vermiedener Fehler in einem Beratungsprojekt kann schnell 20.000–80.000 Euro in Nacharbeit, Verzögerung und Vertrauensverlust kosten. In der Praxis lässt sich aber kaum belegen, dass genau dieses System diesen Fehler verhindert hat. Die Kosteneinsparung ist real, aber indirekt und schwer zu isolieren — vergleichbar mit der Einsparung durch gutes Onboarding, die ebenfalls nie exakt beziffert wird.

Schnelle Umsetzung — niedrig (2/5)
Eines der langsamsten Projekte in dieser Kategorie. Die Dokumenten-Aufbereitung allein — Altdokumente sichten, anonymisieren, strukturieren, indexieren — frisst 30–40 % des Budgets (Erfahrungswert aus RAG-Projekten). Bis ein System produktiv ist, vergehen realistisch 12–18 Wochen. Wer noch keine strukturierte Projektdokumentation hat, braucht noch länger.

ROI-Sicherheit — niedrig (2/5)
Das ist der ehrlichste Score in dieser Übersicht. Der Kausalzusammenhang „System lieferte Lektion → Berater las sie → Fehler wurde vermieden → Projekt lief besser → ROI” ist an so vielen Stellen unterbrochen, dass er sich für Budgetentscheidungen kaum formalisieren lässt. Die Nutzungsrate des Systems ist messbar — aber ob Nutzung Ergebnisse verbessert, bleibt eine organisationale Überzeugungsfrage, keine Buchungsfrage.

Skalierbarkeit — mittel (3/5)
Ein RAG-System skaliert technisch gut — mehr Projekte, mehr Dokumente, mehr Anfragen ohne proportional wachsende Kosten. Das Problem ist die Datenpflege: Wenn jedes neue Projekt strukturiert dokumentiert und indexiert werden muss, entsteht ein Verwaltungsaufwand, der mit der Projektzahl wächst. Wer keine klare Governance hat — wer indexiert was, in welchem Format, mit welchen Metadaten — hat nach zwei Jahren eine Datenbank, die ebenso unübersichtlich ist wie das Laufwerk vorher. Skalierbarkeit ist hier keine technische, sondern eine organisationale Frage.

Richtwerte — stark abhängig von Dokumentationsreifegrad und verfügbarer Projekthistorie.

Was das System konkret macht

Technisch ist das Konzept dasselbe wie bei einer internen Wissensdatenbank: Das System indexiert alle verfügbaren Projektdokumentationen in einer semantisch durchsuchbaren Form. Wenn ein Berater eine Frage stellt — „Was lief bei SAP-Migrationsprojekten in der Lebensmittelbranche immer wieder schief?” — sucht das System nicht nach dem Wortlaut, sondern nach dem Bedeutungsgehalt. Es findet relevante Textpassagen aus Abschlussberichten, Retrospektiv-Protokollen und Risikodokumenten, reicht sie an ein LLM weiter und liefert eine direkte Antwort mit Quellenangabe.

Was diesen Use Case von einer allgemeinen Wissensdatenbank unterscheidet, sind vier spezifische Anforderungen:

Projektstruktur als Metadaten. Ein gutes Lessons-Learned-System weiß nicht nur was in einem Dokument steht, sondern welchem Projekttyp, welcher Branche, welchem Jahr und welcher Projektphase es entstammt. Ohne Metadaten sind alle Projektdokumentationen ein unstrukturierter Haufen — und Fragen wie „Was lief bei IT-Infrastrukturprojekten 2022–2024 besonders häufig schief?” können nicht sinnvoll beantwortet werden.

Anonymisierungsschicht. Projektdokumentationen enthalten Kundennamen, Ansprechpartner, Vertragsdetails und manchmal sensitive strategische Informationen. Bevor sie indexiert werden können, braucht es eine explizite Anonymisierungsstrategie — mehr dazu im Abschnitt zum NDA-Dilemma.

Thematische Verschlagwortung. Wer fragt: „Hatten wir schon Projekte mit aggressiven SLA-Vereinbarungen?” braucht eine Wissensbasis, in der SLA-Probleme auch als solche getaggt sind — nicht nur in dem Abschnitt, in dem irgendwo in einem Statusbericht der Begriff „Service Level” auftaucht.

Zeitliche Priorisierung. Erkenntnisse aus einer SAP-Einführung von 2019 sind weniger relevant als solche von 2024. Das System sollte neuere Quellen bevorzugen und alte Dokumente als solche kennzeichnen.

Das NDA-Dilemma: Was darf in die Wissensdatenbank?

Das ist die Frage, die am häufigsten unterschätzt wird — und die über Erfolg oder Scheitern des ganzen Projekts entscheidet.

Consulting-Verträge enthalten fast immer eine Vertraulichkeitsklausel, die es verbietet, mandantenspezifische Informationen an Dritte weiterzugeben oder für andere Projekte zu nutzen. Das klingt klar, wird aber in der Praxis selten konsequent auf interne Wissensdatenbanken angewendet — bis ein Mandant fragt, ob seine Projektdaten intern weiterverwendet werden.

Was darf rein:

• Strukturelle Erkenntnisse: „SAP-Migrationen in Unternehmen mit <500 Mitarbeitenden scheitern häufig an fehlenden internen Key Usern” — ohne Mandantennennung
• Methodische Learnings: „Risikoworkshops vor Abschluss des Lastenhefts sind weniger effektiv als nach dem ersten Prototyp”
• Zeitplan-Erkenntnisse: „Dezember-Change-Freeze in produzierendem Gewerbe führt zu 3–6 Wochen Projektverzögerung — gilt für ca. 70 % der Industriekunden”

Was nicht rein darf (ohne explizite Genehmigung):

• Mandantenspezifische Zahlen, Namen oder strategische Entscheidungen
• Interne Prozessdetails des Mandanten, die im Projekt bekannt wurden
• Vertragskonditionen, Verhandlungsverläufe, Preismodelle

Praktische Lösung: Viele Beratungen bauen eine zweistufige Wissensbasis. Stufe 1 enthält de-identifizierte, methodische Erkenntnisse — alles, was als allgemeines Projektwissen gilt. Stufe 2 enthält vollständige Projektdokumentationen, die ausschließlich internen Senior-Mitarbeitenden zugänglich sind, die ohnehin für den jeweiligen Mandanten tätig waren oder sind.

Die Grenze zwischen beiden Stufen muss vor Projektstart rechtlich geklärt sein — idealerweise mit einem standardisierten Anonymisierungs-Workflow als Teil des Projektabschlussprozesses. Ein System ohne diese Governance schafft keine Wissensdatenbank, sondern ein Compliance-Risiko.

Wer fragt eigentlich? — PMO vs. Projektteam

Das ist eine Frage, die den Unterschied zwischen einem gut genutzten und einem verwaisten System macht.

Der PMO-Ansatz: Das Project Management Office oder die Beratungsleitung pflegt die Datenbank aktiv und bindet sie strukturell in den Kick-off-Prozess ein. Jede neue Projektbeschreibung wird automatisch gegen die Wissensbasis geprüft: „Gibt es vergleichbare Projekte? Was waren die kritischen Risiken?” Das Ergebnis wird Teil der Standard-Kick-off-Dokumentation. Dieses Modell funktioniert — weil es nicht von individueller Initiative abhängt.

Das Problem: In der Realität haben die wenigsten mittelgroßen Beratungen einen aktiven PMO. Die Verantwortung für Wissensdatenbanken liegt beim Management — das dafür keine Zeit hat — oder beim Einzelnen — der sie kaum nutzt.

Das Wissens-Paradoxon: Senior-Partner, die am meisten von einer solchen Datenbank profitieren könnten (weil sie komplexe Entscheidungen treffen), wissen die Erkenntnisse oft schon aus eigener Erfahrung. Junior-Berater, die am meisten davon profitieren würden, wissen nicht, welche Fragen sie stellen sollen — sie kennen die Risikokategorien nicht, bevor sie sie erlebt haben.

Diese Dynamik hat einen Namen in der Lernpsychologie: der „Curse of Knowledge” — erfahrene Berater wissen bereits, was relevant ist, und vergessen, dass Junior-Berater es nicht wissen. Eine Wissensdatenbank löst das Problem nur teilweise: Sie gibt Junior-Beratern Zugang zu historischen Dokumenten, aber nicht zur impliziten Urteilsfähigkeit, welche Erkenntnisse auf das aktuelle Projekt wirklich zutreffen.

Die Konsequenz für die Systemgestaltung: Guided Search ist wichtiger als Free Search. Statt „frag einfach mal” braucht es strukturierte Einstiegspunkte: „Projekttyp wählen” → „Branche wählen” → „Welche Phasen sind geplant?” → „Hier sind die Top-5-Risiken aus vergleichbaren Projekten”. Das ist weniger flexibel, aber deutlich nützlicher für Junior-Berater, die noch nicht wissen, wonach sie suchen sollten.

Konkrete Werkzeuge — was wann passt

Das richtige Tool hängt davon ab, wie viel Eigenentwicklung du bereit bist zu investieren und wo eure Projektdokumentationen heute liegen.

Confluence mit Atlassian Intelligence (Premium) — Wenn deine Beratung bereits Confluence für Projektdokumentation nutzt, ist der Einstieg hier am einfachsten. Die integrierte KI durchsucht bestehende Confluence-Spaces und beantwortet Fragen direkt. Einschränkung: Die Qualität hängt stark davon ab, wie strukturiert die Projektseiten gepflegt sind. In Beratungen, wo Confluence ein „wir laden Dokumente hoch”-System ist statt ein strukturiertes Wiki, bleibt die KI-Qualität begrenzt. Kosten: ab ca. 12,30 USD pro Nutzer und Monat für den Premium-Plan (Stand Mai 2026).

Notion AI (Business) — Für Beratungen, die ihre Projektdokumentation in Notion führen. Der Notion Agent durchsucht den Workspace und beantwortet Fragen mit Seitenverweisen. Vorteil: Notion eignet sich gut für strukturierte Projektseiten mit Metadaten-Feldern (Branche, Projekttyp, Jahr). Nachteil: US-Datenhosting außerhalb des Enterprise-Plans. Kosten: 19,50 Euro pro Person und Monat.

Guru — Wenn Governance wichtiger ist als Suchtiefe: Jede Wissenskarte bekommt einen Verantwortlichen und ein Überprüfungsdatum. Besonders geeignet für methodische Erkenntnisse (Stufe 1 der Wissensbasis), die explizit de-identifiziert und freigegeben sind. Nachteil: US-Hosting, kein öffentliches Pricing, für datenschutzsensible Beratungen problematisch.

Custom RAG mit Azure OpenAI Service — Für Beratungen, die maximale Kontrolle und DSGVO-konforme EU-Datenhaltung brauchen. Der Aufwand ist höher: Dokumente müssen aufbereitet, indexiert und eine Abfrageoberfläche gebaut werden. Aber das Ergebnis ist ein System, das exakt auf eure Metadatenstruktur zugeschnitten ist, EU-seitig gehostet wird und keine Mandantendaten an US-Anbieter überträgt. Realistischer Projektumfang: 8.000–25.000 Euro für einen Proof of Concept, 25.000–80.000 Euro für eine produktive Lösung (laut dataconsultingfirms.com, 2026). Laufende Infrastrukturkosten: 300–800 Euro monatlich.

NotebookLM (kostenlos) — Für einen schnellen Proof of Concept: 5–10 Abschlussberichte hochladen und befragen. Kein Setup, keine Kosten, in 15 Minuten nutzbar. Zeigt, ob das Konzept für eure Dokumentenqualität funktioniert — bevor du Geld in eine Implementierung investierst. Wichtig: NotebookLM ist kein Produktivsystem — es läuft auf US-Servern und ist auf 50 Quellen je Notizbuch begrenzt.

Zusammenfassung: Wann welcher Ansatz

• Alles in Confluence, Atlassian-Ökosystem → Confluence Atlassian Intelligence (Premium)
• Alles in Notion, US-Hosting akzeptabel → Notion AI Business
• Governance und de-identifizierte Methodik im Vordergrund → Guru
• Maximale Kontrolle, EU-Hosting, benutzerdefinierte Metadaten → Custom RAG mit Azure OpenAI Service
• Schneller Proof of Concept ohne Budget → NotebookLM

Datenschutz und Datenhaltung

Consulting-Wissensbasen sind datenschutzrechtlich komplex — nicht wegen des Systems selbst, sondern wegen der Inhalte.

Das Grundproblem: Projektdokumentationen enthalten fast immer personenbezogene Daten (Ansprechpartner des Mandanten, interne Kontaktpersonen, manchmal auch HR- oder Finanzdaten). Sobald ein KI-System diese Dokumente verarbeitet, gilt die DSGVO — mit AVV-Pflicht gegenüber jedem Cloud-Anbieter.

US-Anbieter (Guru, Notion AI außerhalb Enterprise, NotebookLM): AVV ist erhältlich, Daten werden aber auf US-Servern verarbeitet. Für Beratungen, die mit Mandantendaten aus regulierten Branchen (Finanzen, Gesundheit, öffentlicher Sektor) arbeiten, ist das eine ernste Einschränkung.

Confluence (Atlassian): Data Residency für EU muss aktiv konfiguriert werden — nicht automatisch aktiv. DPA verfügbar. Für DSGVO-saubere Nutzung: Data Residency EU konfigurieren und DPA abschließen, bevor Projektdaten indexiert werden.

Azure OpenAI Service (EU-Region): Daten verbleiben vertraglich in der gewählten EU-Region (z.B. West Europe/Amsterdam oder Germany West Central). Keine Weitergabe für Trainingszwecke. Für Beratungen mit hohen Compliance-Anforderungen die sauberste technische Lösung.

Wichtige Grundregel: Vor dem Start muss klar sein, welche Dokumente welcher Klassifikation in die Wissensbasis eingehen. Ein Anonymisierungsworkflow — idealerweise Teil des regulären Kick-off-Meeting-Dokumentation-Prozesses — verhindert, dass aus einem Wissensmanagement-System ein Compliance-Risiko wird.

Was es kostet — realistisch gerechnet

Option 1: Plattformbasiert (Confluence Premium oder Notion AI Business)

• Einmalige Einrichtung: 1–3 Tage intern + ggf. externe Begleitung (1.000–4.000 Euro)
• Laufend: 10–20 Euro pro Person und Monat (im bestehenden Plan oft enthalten)
• Dokumenten-Aufbereitung: 40–80 Stunden interner Aufwand für erste 50–100 Projektdokumentationen

Option 2: Custom RAG (Azure OpenAI Service + Azure AI Search)

• Proof of Concept (8–14 Wochen): 8.000–25.000 Euro
• Produktive Lösung: 25.000–80.000 Euro, je nach Dokumentvolumen und Integrationstiefe
• Laufende Infrastruktur: 300–800 Euro monatlich
• Versteckte Kosten: Datenvorbereitung frisst 30–40 % des Budgets — ein häufig unterschätzter Posten

Was du dagegenrechnen kannst — konservativ: Eine mittelgroße IT-Beratung mit 30 Beratern startet monatlich 5–8 neue Projekte. Jeder Kick-off braucht im Schnitt 2 Stunden Risikorecherche, die das System auf 30–40 Minuten reduziert. Bei einem Beraterstundensatz von internen 60–90 Euro (Vollkostenrechnung) spart das 700–1.200 Euro monatlich — allein für die Kick-off-Vorbereitung. Ein einzelner vermiedener Projektfehler, der sonst 15.000–30.000 Euro Nacharbeit gekostet hätte, amortisiert die gesamte Einrichtung.

Was du nicht rechnen solltest: ROI über vermiedene Fehler ist plausibel, aber nicht buchhalterisch greifbar. Wer dem Vorstand eine Zahl präsentieren muss, zählt Nutzungsrate und Kick-off-Zeitersparnis — nicht hypothetische Fehlerkosten.

Drei typische Einstiegsfehler

1. Mit der vollständigen Projekthistorie beginnen wollen. Der Reflex: Alles rein, dann ist das System so vollständig wie möglich. In der Praxis führt das zu sechs Monaten Datenpflege bevor das erste produktive Ergebnis kommt — und zu Burnout im Team. Lösung: mit den 20 ähnlichsten Projekten aus den letzten drei Jahren starten. Dieser Kern liefert 80 % des Wertes. Alles andere kommt schrittweise.

2. Mandantendaten ohne Anonymisierungsprozess indexieren. Unter Zeitdruck landen Abschlussberichte ungeprüft in der Datenbank — inklusive Mandantennamen, Kontaktpersonen, Vertragsdetails. Das läuft monatelang problemlos, bis ein Mandant fragt, ob seine Daten für andere Projekte verwendet werden. Oder bis eine Person aus dem Projekt das Unternehmen verlässt und mitnimmt, was in der Datenbank steht. Lösung: standardisierten Anonymisierungsschritt als Pflichtbestandteil des Projektabschlussprozesses festlegen, bevor das System live geht.

3. Das System wird eingeführt, aber nicht in den Kick-off-Prozess integriert. Das ist der gefährlichste Fehler — weil er leise passiert. Das System existiert, die Dokumentation ist da, aber kein Berater öffnet es beim nächsten Projekt. Nicht aus Faulheit, sondern weil es kein Reminder gibt, kein Pflichtfeld im Kick-off-Template, keine Norm. Ein RAG-System ist kein Selbstläufer — es muss in einen bestehenden Prozessschritt eingebettet sein. Wer ein „freiwilliges Nachschlagewerk” baut, baut ein Archiv. Wer eine „Pflicht-Risikoreferenz im Kick-off-Template” baut, schafft tatsächlich Nutzung.

4. Den Pflegeaufwand nach der Einführung unterschätzen. Jede Erkenntnis veraltet. SAP-Erkenntnisse aus 2019 gelten heute nur noch bedingt. Wenn neue Projekte nicht regelmäßig indexiert werden — und alte Dokumentationen nicht als veraltet markiert — liefert das System irgendwann selbstbewusst falsche Empfehlungen. Wer dieses Problem ignoriert, hat nach 18 Monaten eine Datenbank, die auf die meisten Fragen mit veralteten Antworten reagiert, was das Vertrauen im Team dauerhaft zerstört.

Was mit der Einführung wirklich passiert — und was nicht

Was passiert: Die ersten vier Wochen laufen gut. Das System beantwortet Testfragen überzeugend, die Partner sind beeindruckt, die ersten Kick-offs profitieren spürbar von der beschleunigten Risikorecherche. Die Nutzungsrate liegt bei 60–80 % der Projektteams.

Was danach passiert: Nach drei bis sechs Monaten sinkt die Nutzungsrate auf 20–40 % — wenn das System nicht aktiv in den Prozess eingebettet ist. Der typische Verlauf: Anfangs nutzen es alle neugierig. Dann kommen zwei schlechte Antworten (weil ein Dokument schlecht aufbereitet war). Die Skeptiker ziehen sich zurück. Das System wird als „optional” wahrgenommen.

Widerstandsmuster, die du kennen solltest:

Wissenshüter. Senior-Partner, die das Unternehmen als wandelnde Wissensdatenbanken kennen, sehen das System manchmal als Angriff auf ihre Rolle. Konkret hilft: Sie als Redakteure einsetzen, nicht als Nutzer. Wer entscheidet, welche Erkenntnisse als „kanonisch” gelten und in die Datenbank kommen, hat Einfluss auf das System — und wird zum Fürsprecher statt zum Kritiker.

Qualitätsskeptiker. Wer das System einmal mit einer falschen Antwort erwischt, traut ihm dauerhaft nicht mehr. Das ist nicht irrational — es ist die richtige Reaktion auf ein schlecht befülltes System. Lösung: vor der Freigabe einen internen Testdurchlauf mit 20–30 realen Fragen machen und alle „schlechten Antworten” auswerten, bevor das System für alle freigegeben wird.

Zeitdruckflüchtige. „Ich hätte das mal nachschauen sollen, aber das Deck musste raus.” Dieser Moment ist der häufigste Nutzungsabbruch. Abhilfe: das System direkt in die Kick-off-Vorlage integrieren — als Link, als automatischer Trigger oder als Pflichtfeld. Was zwei Klicks vom Workflow entfernt ist, wird genutzt. Was einen App-Wechsel erfordert, oft nicht.

Realistischer Zeitplan mit Risikohinweisen

Der typische Aufwand bis zu einem funktionsfähigen Pilotsystem liegt bei 12–18 Wochen — mit einem gut strukturierten Dokumentenbestand. Wer erst aufräumen muss, braucht 4–8 Wochen mehr.

Häufige Einwände — und was dahintersteckt

„Wir haben das alles schon in Confluence / SharePoint — das reicht.”
Klassisches Suchsystem vs. semantische Suche: Wer in Confluence „SAP Dezember Risiko” eingibt, findet Dokumente, die diese Wörter enthalten — nicht Dokumente, die das Konzept beschreiben, ohne den Begriff zu nennen. Ein Berater, der nach „Change-Freeze-Risiken in Produktionsbetrieben” fragt, findet über Keyword-Suche kaum etwas. Ein RAG-System versteht die Bedeutung — das ist der Unterschied.

„Unsere Senior-Partner haben dieses Wissen im Kopf — wozu ein System?”
Richtig für heute. Falsch für die nächsten drei Jahre. Consulting-Branche hat hohe Fluktuation, besonders im mittleren Karrierelevel. Jeder Senior-Consultant, der das Unternehmen verlässt, nimmt drei bis fünf Jahre implizites Projektwissen mit. Das System macht unabhängig von Personen — das ist sein eigentlicher Wert.

„Unsere Kunden haben uns das Wissen in Vertrauen gegeben — das darf nicht in eine Datenbank.”
Das ist der richtigste Einwand in dieser Liste — und er löst sich auf, wenn ihr eine klare Anonymisierungsstrategie habt. Methodische Erkenntnisse ohne Mandantenbezug sind in keinem NDA verboten. Was verboten ist: Mandantendaten ohne Genehmigung zu verarbeiten. Die Lösung ist ein zweistufiges System, keine Absage an das Konzept.

Woran du merkst, dass das zu dir passt

Du bist in der richtigen Position für eine Lessons-Learned-KI, wenn:

• Deine Beratung schließt mindestens 10–15 vergleichbare Projekte pro Jahr ab — genug Material, um Muster zu erkennen
• Du hast eine strukturierte Projektdokumentation — Abschlussberichte, Retrospektiv-Protokolle, Risikoregister als Standard-Deliverable, nicht als Sonderwunsch
• Junior-Berater wiederholen regelmäßig Fehler, die in der Unternehmensgeschichte schon einmal aufgetreten sind — das ist das verlässlichste Signal
• Du hast eine Person, die die Wissensbasis dauerhaft pflegt — kein Vollzeit-Job, aber 2–4 Stunden pro Woche, konsequent
• Das Management unterstützt die Integration in Pflichtprozesse — ein freiwilliges System wird nicht genutzt

Wann es sich (noch) nicht lohnt — drei harte Ausschlusskriterien:

1. Weniger als 8–10 vergleichbare abgeschlossene Projekte im Archiv. Unter dieser Schwelle gibt es zu wenig Material, um Muster zu erkennen — das System gibt Einzelfallschilderungen zurück, die oft nicht generalisierbar sind. Ersatz: manuelle Lessons-Learned-Sitzungen und strukturierte Rückfragen bei Seniors.

2. Keine strukturierte Projektdokumentation als Standard. Wenn Projektabschlüsse von Team zu Team unterschiedlich dokumentiert werden — einmal ein PowerPoint, einmal ein Word-Dokument, einmal nur Sprachnotizen — dann ist der erste Schritt kein KI-System, sondern ein Dokumentationsstandard. Ein System, das unstrukturiertes Chaos indexiert, liefert unstrukturiertes Chaos zurück.

3. Kein klares Governance-Konzept für Mandantendaten. Wer keine Antwort auf die Frage hat „Welche Dokumente dürfen indexiert werden und wie werden sie anonymisiert?”, hat das Datenschutzproblem noch nicht — aber es wächst still. Ohne diese Klärung vor dem Start entsteht ein Compliance-Risiko, das im schlimmsten Fall durch einen Mandantenbeschwerdefall sichtbar wird.

Das kannst du heute noch tun

Lade drei bis fünf Abschlussberichte vergangener Projekte in NotebookLM hoch — kostenlos, kein technisches Setup. Stelle dann die Frage, die du wirklich beim nächsten Kick-off stellen würdest: „Was waren die häufigsten Ursachen für Projektverzögerungen?” oder „Welche Risiken wurden in diesen Projekten unterschätzt?”

Was du in 15 Minuten lernst: ob eure Dokumente gut genug aufbereitet sind, um sinnvolle Antworten zu liefern. Das Ergebnis ist ehrlicher als jede Proof-of-Concept-Demo eines Tool-Anbieters.

Für den strukturierten Einsatz im Kick-off verwende diesen System-Prompt als Ausgangspunkt:

Quellen & Methodik

• PMI / Ernst & Young (2007): Project Management Institute Learning Library, „Applying lessons learned”, zitiert: Ernst & Young-Studie in Zusammenarbeit mit PMI — Haupthindernis bei Lessons-Learned-Sitzungen ist „zu wenig Zeit”. pmi.org/learning/library/applying-lessons-learned-implement-project-8344
• Volker Nissen, TU Ilmenau: „Wissensmanagement in der Unternehmensberatung — Ergebnisse eines empirischen Vergleiches zwischen Strategieberatung und IT-orientierter Beratung”, ResearchGate (92 befragte Beratungsunternehmen). researchgate.net/publication/259080847
• RAG-Implementierungskosten: dataconsultingfirms.com, „AI Consulting Pricing: What GenAI Projects Actually Cost in 2026” — Proof of Concept €8.000, Vollimplementierung €25.000–€80.000.
• Azure OpenAI Pricing: Offizielle Microsoft Azure-Preisliste (Stand Mai 2026): GPT-4o ab ca. 2,50 USD pro 1M Input-Token.
• Dokumenten-Aufbereitungskosten: OpenAI RAG Cost Breakdown (ITNEXT, Mark Tinderholt) — 30–40 % des RAG-Budgets entfallen auf Datenvorbereitung.
• Preisangaben Confluence, Notion AI, Guru: Veröffentlichte Tarife der jeweiligen Anbieter (Stand Mai 2026).
• Erfahrungswerte (Kick-off-Zeitersparnis, Trefferquote): Schätzwerte auf Basis von PMO-Praxisberichten — keine repräsentative Studie.

Du willst wissen, ob eure Projektdokumentation gut genug für eine KI-gestützte Wissensbasis ist — und was der sinnvolle erste Schritt wäre? Meld dich für ein kurzes Gespräch.