SharePoint ist kein Wissensmanagement. Es ist die Bühne.

Wir haben alles dokumentiert. Wir finden es nur nicht.

Dieser Satz fiel bei einem Kundenbesuch. Der IT-Leiter suchte ein Prozessdokument, das er selbst erstellt hatte – irgendwann vor rund anderthalb Jahren. Drei Treffer in SharePoint. Zwei veraltet, eines ohne Versionsnummer. Er zuckte mit den Schultern.

Dieses Schulterzucken kenne ich. Ich sehe es in fast jedem zweiten Projekt. Und jedes Mal ist die Ursache dieselbe: Das Problem ist nicht SharePoint. Das Problem ist, dass niemand definiert hat, was mit Wissen passiert, nachdem es abgelegt wurde.

SharePoint wurde eingeführt, weil der Fileserver voll war. Oder weil M365 eh in der Lizenz enthalten war. Oder weil „wir endlich einen zentralen Ort für alles brauchen”. Und dann? Der Betrieb lief weiter. SharePoint wuchs weiter. Zwei Jahre später fragte niemand, ob das, was drinsteht, noch trägt.

Dieser Beitrag ist keine SharePoint-Abrechnung. SharePoint kann wirklich exzellent sein – aber nur, wenn du verstehst, was es ist und was es strukturell nie sein wird.

Worüber reden wir eigentlich – und welche Werkzeuge sind beteiligt?

Es gibt drei Ebenen, die in der Praxis selten sauber getrennt werden:

• SharePoint: der strukturierte Wissensspeicher. Dokumente, Richtlinien, Vorlagen, Handbücher. Explizites Wissen mit klarer Zugriffssteuerung.
• Microsoft Teams: wo die eigentliche Arbeit passiert. Entscheidungen fallen im Chat. Kontextwissen entsteht in Kanälen. Und bleibt dort.
• Microsoft Foundry / Copilot Studio: die KI-Schicht, die Wissen aus verteilten Quellen bündeln und kontextbezogen zugänglich machen kann – wenn richtig konfiguriert.

Das Dreieck klingt einfach. In der Praxis werden alle drei Ebenen vermischt, verwechselt oder schlicht ignoriert. Das Ergebnis: Informationen leben überall. Wissen lebt nirgends.

Was SharePoint wirklich gut kann – und was nicht

Die Stärken: wo SharePoint liefert. SharePoint ist ein exzellentes Dokumentenmanagement-System. Punkt. Es kann:

• Dokumente versionieren und mit Metadaten anreichern
• Zugriffsrechte granular steuern (Gruppe, Site, Ordner, Datei)
• über Microsoft Search im gesamten M365-Ökosystem durchsuchbar gemacht werden
• als Single Source of Truth für explizites, strukturiertes Wissen dienen – Prozesse, Richtlinien, Vorlagen, Projektabschlüsse

Die Voraussetzung: eine saubere Informationsarchitektur. Wer darf was ablegen? Welche Namenskonvention gilt? Wem gehört der Inhalt? Ohne diese drei Fragen vor dem ersten Ordner gibt es Chaos in Zeitlupe.

Darauf achten …

• Eine klare Site-Struktur vom ersten Tag an (3 gut strukturierte Sites schlagen 15 unklare)
• Namenskonventionen aufgeschrieben und in den Onboarding-Unterlagen enthalten
• Benannte Content Owner pro Site oder Dokumentbereich – sonst pflegt niemand etwas
• Suchoptimierung: Metadaten und Managed Properties früh konfigurieren, nicht nachträglich

Die strukturelle Lücke: was SharePoint nicht sieht. SharePoint sieht nur, was jemand aktiv ablegt. Klingt trivial. Ist es nicht.

Jede Organisation hat eine zweite Wissensebene: Entscheidungen, die in einem Teams-Chat fallen. Lösungen, die per Mail kommuniziert werden. Lessons Learned aus einem Projekt, die nur im Kopf der Projektleitung existieren – und nie aufgeschrieben wurden. Dieses Wissen ist real. Es ist betrieblich relevant. Und es existiert schlicht nicht in SharePoint.

Das ist keine Kritik an SharePoint. Es ist ein strukturelles Merkmal. SharePoint ist passiv. Es wartet, dass jemand etwas ablegt. Es erkennt nicht, dass wichtige Entscheidungen im Chat getroffen werden. Es meldet nicht, dass eine Richtlinie seit 14 Monaten niemand angefasst hat. Es schlägt nicht Alarm, wenn jemand das Unternehmen verlässt und sein Wissen mitnimmt.

Typische Wissenslücken – kommt dir das bekannt vor?

• Der Teams-Chat aus Projekt X ist die eigentliche Projektdokumentation
• Die SharePoint-Richtlinie stammt von 2022 – die Organisation hat sich seither dreimal verändert
• Ist Kollegin A im Urlaub, weiß niemand, wie Prozess Y funktioniert
• Neue finden Dokumente, aber nicht den Kontext dahinter
• Niemand weiß sicher, welche Dokumente noch aktuell sind und welche nicht

Der Wissenskreislauf: das, was fast alle übersehen

Hier die unbequeme Wahrheit: Die meisten Organisationen haben einen Wissensspeicher, aber keinen Wissenskreislauf. Dieser Unterschied ist alles.

Ein Wissenslebenszyklus beschreibt, was mit Wissen von der Entstehung bis zur Archivierung oder Löschung passiert. Ohne diesen Kreislauf veraltet SharePoint leise. Niemand bemerkt es. Bis jemand eine Richtlinie sucht und die falsche findet.

Der Lebenszyklus in fünf Phasen – konkret

• Entstehung: Wo entsteht Wissen? Nicht nur in Dokumenten – auch in Projekten, Meetings, Kundengesprächen und Chats. Wer ist dafür verantwortlich, dieses Wissen zu erkennen und zu entscheiden, ob es dokumentiert werden muss?
• Dokumentation: Wer schreibt es auf? In welchem Format? Wo? Mit welchen Metadaten? Klare Verantwortung und eine definierte Vorlage sind der Unterschied zwischen „irgendwo abgelegt” und „auffindbar”.
• Nutzung und Verteilung: Wie erreicht Wissen die Leute, die es brauchen? Wer wird benachrichtigt, wenn ein relevantes Dokument aktualisiert wird? Microsoft Search, Viva Topics (sofern lizenziert) oder ein KI-Agent können hier aktiv unterstützen.
• Aktualisierung und Pflege: Wer prüft welche Dokumente in welchem Abstand? Zweimal im Jahr für operative Prozesse, jährlich für strategische Dokumente – das muss vorab definiert und eingeplant werden. Nicht als Absicht. Als Kalendertermin mit Verantwortlichem.
• Archivierung oder Löschung: Was passiert mit Wissen, das nicht mehr aktuell ist? Klar definierte Aufbewahrungslabels in SharePoint helfen – aber nur, wenn jemand sie pflegt und die Regeln konsequent angewendet werden.

Lebenszyklus-Schnellstart: beantworte zuerst diese 4 Fragen

1. Wer ist Content Owner für welche Bereiche in SharePoint?
2. Wie oft werden Dokumente auf Aktualität geprüft?
3. Was passiert mit Wissen aus Teams und Outlook – wird es je übertragen?
4. Wer entscheidet, wann ein Dokument archiviert oder gelöscht wird?

KI-Agenten: funktioniert – wenn du es richtig machst

Nichts vormachen: KI-Agenten auf Basis von Microsoft Foundry oder Copilot Studio sind technisch beeindruckend. Aber ich nenne auch die Grenzen.

Was ein KI-Agent kann: Er analysiert Wissensquellen über Systeme hinweg – SharePoint, Teams-Chats, Outlook (mit der richtigen Konfiguration) – und macht verteiltes Wissen kontextbezogen zugänglich. Statt über fünf Kanäle zu suchen, fragst du den Agenten: „Wie haben wir das für Kunde X gelöst?” Du bekommst eine gebündelte Antwort mit Quellenangaben.

Was ein KI-Agent nicht macht: Er ersetzt nicht den Lebenszyklus. Er bringt Wissen an die Oberfläche, das irgendwo existiert. Wurde das Wissen nie dokumentiert, findet er es nicht. Sind Dokumente veraltet, liefert er veraltete Antworten. Garbage in, garbage out – das gilt auch für intelligente Systeme.

Funktioniert, WENN …

• … ein solides SharePoint-Fundament existiert (strukturiert und einigermaßen aktuell)
• … Indexierung und Zugriffsrechte korrekt konfiguriert sind (Stichwort: Semantic Index für Copilot)
• … der Agent klar definierte Quellen hat und nicht auf „alles” durchsuchen steht
• … Nutzer verstehen, was der Agent kann und was nicht (kein Orakel, sondern ein Assistent)
• … die Organisation bereit ist, Wissen aktiv zu pflegen – KI verstärkt nur, was schon da ist

KI-Suche: Die Frage ist nicht „Was weiß der Agent?” – sondern „Was darf er indexieren?”

Wenn ein Microsoft-Foundry-KI-Agent Wissensfragen beantworten soll, hängt alles an einer einzigen Frage: Was hat der Agent tatsächlich gesehen? Die Intelligenz des Modells ist das eine. Der Index – die Menge der wirklich erreichbaren Quellen – das andere. Und in der Praxis ist der Index das häufigere Problem.

Microsoft Foundry nutzt Azure AI Search als Indexierungsschicht. Das heißt: Bevor ein Agent überhaupt etwas beantworten kann, müssen Dokumente und Inhalte in einen durchsuchbaren Vektor-Index aufgenommen werden. Dieser Index bestimmt, was der Agent „weiß” – und was für ihn schlicht nicht existiert. SharePoint-Dokumente lassen sich direkt anbinden. Aber Organisationswissen endet selten an der SharePoint-Grenze.

Externe Quellen anbinden: hier kommen MCP-Server ins Spiel. Viele Mittelständler betreiben neben SharePoint externe Systeme: Confluence oder Notion als Wiki, Jira oder ServiceNow für Tickets und Prozesse. Dieses Wissen ist real, aktiv genutzt – und landet nie in SharePoint. Klassische Integrationen hießen: API-Verbindungen bauen, Daten synchronisieren, Zugriffsrechte abgleichen. Komplex und fehleranfällig.

Genau da setzen MCP-Server (Model Context Protocol) an. MCP ist ein offenes Protokoll, mit dem ein KI-Agent zur Laufzeit Kontext aus externen Quellen abruft – ohne dass Daten vorher migriert oder dauerhaft synchronisiert werden müssten. Der Agent fragt, der MCP-Server liefert den Kontext, die Antwort berücksichtigt ihn. Confluence-Seiten, Jira-Tickets, ServiceNow-Einträge – alles bleibt dort, wo es lebt. Der Agent sieht es trotzdem.

Das ist kein Marketingversprechen – aber auch kein Plug-and-play. MCP-Server müssen konfiguriert, Zugriffsrechte sauber abgebildet und die Quellqualität solide sein. Ein veraltetes Confluence-Wiki richtet denselben Schaden an wie ein veraltetes SharePoint. Der Index ist nur so gut wie das, was drinsteckt.

Welche Quellen in den Index gehören – und worauf zu achten ist

• SharePoint: direkte Anbindung über den Azure-AI-Search-Connector – Voraussetzung: saubere Struktur und aktuelle Inhalte
• Confluence / Notion: per MCP-Server anbindbar – Daten bleiben im Quellsystem, keine Datenübertragung nötig
• Jira / ServiceNow: Ticket-Historie und Prozesswissen über MCP – besonders wertvoll für Support- und IT-Agenten
• Zugriffsrechte: Was ein Nutzer im Quellsystem nicht sehen darf, darf der Agent ihm auch nicht liefern – das muss in der Konfiguration sauber abgebildet werden
• Quellqualität: Ein Agent verstärkt, was im Index steht – veraltetes Wissen wird durch KI nicht aktuell

Realitätscheck: Woran merke ich, dass es funktioniert?

Zeichen, dass es läuft:

• Neue finden relevante Dokumente innerhalb von Minuten – ohne jemanden fragen zu müssen
• Verlässt jemand das Unternehmen, bleibt sein Wissen in SharePoint – nicht nur im Kopf
• Dokumente haben ein Aktualisierungsdatum, das nicht älter als ein Jahr ist – bei operativen Prozessen
• Eine SharePoint-Suche liefert das erste relevante Ergebnis auf Seite eins
• Teams-Chats werden aktiv und bewusst nach SharePoint übertragen, wenn sie langfristig relevantes Wissen enthalten

Wenn es nicht läuft, prüf zuerst diese 3 Dinge:

• Keine Content Owner: Ist niemand für einen Bereich verantwortlich, pflegt ihn niemand. Nicht, weil Leute schlecht arbeiten – sondern weil es keine Zuständigkeit gibt.
• Kein Pflegeplan definiert: „Wir aktualisieren bei Bedarf” ist kein Prozess. Es ist ein Wunsch. Vierteljährliche Reviews für kritische Dokumente gehören in den Kalender – als wiederkehrender Termin mit Verantwortlichem.
• SharePoint-Struktur ist gewachsen, nicht geplant: Hat sich die Site-Struktur über drei Jahre ohne Plan entwickelt, ist es Zeit für einen Informationsarchitektur-Workshop. Lieber einmal aufräumen als ewig suchen.

Fazit: SharePoint ist gut. Aber allein reicht es nicht.

SharePoint ist ein solides Fundament. Einer der besten Dokumentenspeicher, die M365 zu bieten hat – mit Struktur genutzt. Aber ein Wissensmanagement-System ist es nicht. Es ist ein Teil davon.

Der eigentliche Hebel ist der Lebenszyklus. Definiere, wer Wissen pflegt – und in welchem Rhythmus – und du hast die halbe Miete. Der Rest ist Technik. Und Technik ist lösbar.

KI-Agenten können ein echter Game-Changer sein. Aber sie verstärken nur, was schon da ist. Eine solide Wissensbasis in SharePoint, klare Content Owner und ein aktiver Lebenszyklus – das ist die Voraussetzung. Nicht das Ergebnis.

Mein ehrliches Learning aus mehreren Mittelstandsprojekten: Organisationen, die am Wissensmanagement scheitern, scheitern selten an der Technik. Sie scheitern, weil sie SharePoint eingeführt – und dann aufgehört haben, zu denken.

☕ Espresso-Moment: SharePoint ist die Bühne. Aber du schreibst das Drehbuch – oder niemand taucht auf. Ferdi Lethen-Oellers

Schnell-Checkliste zum Mitnehmen

• Content Owner pro SharePoint-Bereich benennen – schriftlich, nicht nur mündlich
• Pflegeintervalle definieren: alle 6 Monate (operativ) / jährlich (strategisch)
• Namenskonventionen dokumentieren und ins Onboarding einbetten
• Implizites Wissen aus Teams aktiv übertragen – oder per KI-Agent sichtbar machen
• Aufbewahrungslabels in SharePoint konfigurieren und Archivierungsregeln definieren
• KI-Agenten erst ausrollen, wenn das Fundament steht (Struktur + aktuelle Inhalte)
• Mindestens einmal im Jahr: eine Informationsarchitektur-Prüfung durchführen