Leistung
Wissensdatenbanken
Wenn die Antworten auf 'wie macht man das' in Köpfen, Slack-Threads, verstreuten Dateien und alten Confluence-Seiten leben, leidet jedes Onboarding, jeder Support-Fall, jede Übergabe. Strukturiertes Wissen ist kein Nice-to-have, es ist Versicherung gegen den Schlüsselpersonen-Bus-Faktor.
Das Problem
Typisches Bild: ein veraltetes Confluence mit 300 Artikeln, davon 60 wirklich relevant, niemand weiß welche. Daneben 20 SharePoint-Ordner mit Word-Dokumenten von 2018. Slack-Threads mit Erklärungen die nie in die Doku gewandert sind. Eine Person die alles weiß, die in der Elternzeit ist. Ein Onboarding, das offiziell 4 Wochen dauert und in Wirklichkeit 4 Monate Hands-on-Lernen heißt.
Das eigentliche Problem ist selten 'wir brauchen ein besseres Wiki'. Das Problem ist: niemand kümmert sich um die Wissens-Pflege als eigenes Arbeitsfeld. Die Tools sind verfügbar, die Verantwortung ist nicht definiert.
Was hilft: ein klar abgegrenzter Wissens-Bereich mit Owner, Review-Rhythmus, Versionierung, sinnvoller Suche. Bei größeren Beständen optional ein RAG-Layer mit lokalem LLM, der Antworten aus Ihren Dokumenten zitiert, statt Halluzinationen aus dem öffentlichen Web.
Die Lösung
Phase 1: Inventur der bestehenden Wissens-Bestände. Was ist aktuell, was veraltet, was doppelt, was fehlt komplett. Strukturierung in klare Kategorien mit Ownern und Review-Rhythmus.
Phase 2: Eine schlanke Wissens-Architektur, die das Team auch wirklich nutzt: einfache Schreib-Vorlagen, Suchpfade, Versionsindikatoren, Ablauf-Hinweise. Toolauswahl je nach Stack (Confluence, SharePoint, GitLab Wiki, Notion, optional eigene schlanke Wissens-App).
Phase 3 (optional): RAG-Layer mit lokalem LLM (Ollama oder vLLM), Vektordatenbank (Qdrant oder pgvector), Embedding-Pipeline für die wichtigsten Dokumente. Suchergebnisse sind zitierfähig (zeigt Quelle und Abschnitt), Halluzinationen werden durch Score-Schwellen abgefangen. DSGVO-konform on-prem, keine Cloud-Egress.
Typische Anwendungsfälle
- Support-Wissensbasis: FAQs, Troubleshooting-Bausteine, eskalationsfähige Workflow-Beschreibungen, mit Versionsstand und Owner
- Onboarding-Pfade: pro Rolle ein strukturierter Lernpfad mit Pflicht- und Optional-Modulen, Fortschritts-Tracking
- Prozess-Dokumentation: jede operative Strecke als Living-Document mit Verantwortlichen und Review-Datum
- Code- und Excel-Snippet-Bibliothek: wiederverwendbare Bausteine mit Beispielen und Test-Daten
- RAG mit lokalem LLM: Mitarbeiter stellen Fragen in natürlicher Sprache, bekommen Antworten aus internen Dokumenten mit Zitation
- Veraltete-Inhalte-Erkennung: automatische Meldung wenn Artikel länger als 12 Monate nicht reviewed wurden
Konkreter Nutzen
- Onboarding-Dauer halbiert oder mehr: konkrete Lernpfade statt 'frag deinen Kollegen'
- Wissensverlust bei Personalwechseln signifikant reduziert: das Wissen ist dokumentiert, nicht nur im Kopf
- Support-Antwortzeiten verkürzt: typische Fragen sind in Sekunden auffindbar statt Minuten zu suchen
- Audit-Fitness: Wirtschaftsprüfer und Revisoren sehen dokumentierte Prozesse mit Verantwortlichen
- Optional KI-fähig: das strukturierte Wissen ist Basis für RAG ohne Halluzinations-Risiko, falls relevant
So läuft die Zusammenarbeit
Wissens-Inventur (1-2 Tage)
Was ist heute wo dokumentiert? Was ist aktuell, was veraltet, was doppelt? Wer pflegt was? Output ist eine Bestandsaufnahme mit konkreten Findings.
Architektur und Minimal-Prozess
Kategorien, Owner-Modell, Review-Rhythmus, einfache Schreib-Vorlagen. Toolauswahl je nach bestehendem Stack. Keine Tool-Migration ohne klaren Grund.
Pilot mit einem Themenbereich
Statt 'alles neu' ein begrenzter Bereich (z. B. eine Abteilung, ein Produkt) als Pilot. Erfahrungen sammeln bevor breit ausgerollt wird.
Skalierung + optional RAG
Erweiterung auf weitere Bereiche. Bei Bedarf RAG-Layer mit lokalem LLM für intelligente Suche über strukturierte und unstrukturierte Inhalte.
Häufige Fragen
Ersetzt das unser ITSM-Wiki oder unser Confluence?
Selten. Meistens ergänzen wir oder strukturieren neu innerhalb des bestehenden Tools. Ein neues Tool nur, wenn das bestehende strukturell nicht trägt.
Dürfen wir ChatGPT auf unsere Doku loslassen?
Nicht ohne Vertrag und Datenschutz-Prüfung. Bei wirklich sensiblen Inhalten (Kunden-PII, HR-Daten, Steuerunterlagen, Verwaltungsakten) baue ich RAG mit lokalem LLM on-prem. Damit verlässt nichts das Haus, Antworten sind nachvollziehbar mit Zitaten.
Was kostet ein RAG-Setup für die interne Wissensbasis?
Pilot mit 100-500 Dokumenten: 5-12 Werktage. Größere Setups mit Inkrement-Updates, mehreren Quellen und Audit-Logging: 15-30 Tage. Hardware on-prem (1 GPU, 24-48 GB VRAM) je nach Modellgröße.
Was wenn das Team die Doku trotzdem nicht pflegt?
Dann ist das Tool nicht das Problem. Pflege-Pflicht muss als Arbeitszeit anerkannt sein, nicht 'wann immer du Zeit hast'. Im Review-Termin sehen wir, ob ein klar geregelter Pflege-Slot pro Woche realistisch ist.
Können Sie auch beim kulturellen Teil helfen, nicht nur beim technischen?
Bedingt. Ich bin Engineer, kein Change-Manager. Aber ich kann den Pflege-Prozess so klein und schlank halten, dass er nicht an menschlicher Disziplin scheitert. Bei tieferen Kultur-Themen verweise ich auf entsprechende Spezialisten in meinem Netzwerk.
Passende weitere Leistungen
Wissensbasis aufbauen oder modernisieren?
Beschreiben Sie kurz die aktuelle Lage: welche Tools, welcher Bestand, was schmerzt am meisten? Sie bekommen eine Einschätzung mit realistischem Vorgehen.