SharePoint in der Praxis: verstehen, strukturieren, wirklich nutzen

SharePoint ist überall. In fast jedem Microsoft-365-Tenant, unter jedem Teams-Team, hinter jedem OneDrive. Und trotzdem gibt es kaum ein Produkt, das so konsequent unter Wert betrieben wird: als bessere Netzwerkfreigabe, als Ordnerfriedhof mit Weboberfläche, als der Ort, an dem Dokumente hingehen, um nie wieder gefunden zu werden. Dabei kann SharePoint so viel mehr — wenn man es richtig versteht. Genau darum geht es hier: Was SharePoint wirklich ist, warum Inhaltstypen, Taxonomie und Suche über Erfolg oder Frust entscheiden, und wie du aus der Plattform ein Dokumentenmanagement-, Wissensmanagement- und Publishing-System machst, das den Namen verdient.

Was SharePoint eigentlich ist (und was nicht)

Die ehrliche Kurzfassung: SharePoint ist eine Plattform für strukturierte Zusammenarbeit mit Inhalten. Websites, Dokumentbibliotheken, Listen, Seiten, Berechtigungen, Versionierung, Workflows, Suche — alles in einem System, tief verzahnt mit dem Rest von Microsoft 365. Das klingt unspektakulär, ist aber der Punkt: SharePoint ist keine App für einen Zweck, sondern der Unterbau für viele.

Was SharePoint dagegen nicht ist: ein Fileserver mit Browserzugang. Wer SharePoint so behandelt, bekommt auch genau das — nur langsamer, mit URL-Längenproblemen und dem zusätzlichen Bonus, dass sich hinterher alle beschweren. Der Unterschied zwischen einem Fileserver und SharePoint liegt nicht im Speichern. Er liegt im Beschreiben, Finden, Steuern und Wiederverwenden von Inhalten. Wer nur speichert, hat den teuersten Fileserver seiner Firmengeschichte gekauft.

Warum SharePoint 2026 wichtiger ist denn je

Man könnte meinen, SharePoint sei ein Thema von gestern — schließlich reden alle nur noch über Teams und Copilot. Die Pointe: Beide stehen auf SharePoint. Jedes Teams-Team speichert seine Dateien in einer SharePoint-Website. Jede Kanal-Registerkarte „Dateien“ ist eine Dokumentbibliothek. OneDrive? Technisch eine persönliche SharePoint-Websitesammlung. Viva und das moderne Intranet? SharePoint-Seiten. Und Microsoft 365 Copilot beantwortet Fragen auf Basis der Inhalte, die — Überraschung — größtenteils in SharePoint liegen.

Das heißt im Klartext: Die Qualität deiner SharePoint-Struktur bestimmt die Qualität von so ziemlich allem, was darauf aufsetzt. Ein chaotischer SharePoint macht Teams chaotisch, die Suche nutzlos und Copilot zu einem sehr eloquenten Erzähler von Halbwahrheiten aus Dateileichen von 2017. Ein gut strukturierter SharePoint dagegen macht aus denselben Werkzeugen ein Produktivitätssystem.

Abb.: SharePoint als Fundament des Microsoft-365-Kosmos. Teams, OneDrive, Intranet und Copilot stehen auf SharePoint — und SharePoint steht auf Inhaltstypen, Taxonomie und Suche.

Und noch etwas hat sich geändert: Die Investition in Struktur zahlt sich heute schneller aus als je zuvor. Früher war eine saubere Informationsarchitektur ein Komfortthema — schön für die, die suchen. Heute ist sie die Voraussetzung dafür, dass KI-Werkzeuge überhaupt brauchbare Ergebnisse liefern. Wer seine Inhalte 15 Jahre lang verwildern ließ, bekommt jetzt die Rechnung präsentiert. Mit Zinsen.

Die Informationsarchitektur: SharePoint richtig aufsetzen

Bevor wir über Funktionen reden, reden wir über Struktur — denn hier werden die meisten Fehler gemacht, und zwar am Anfang, wo sie noch niemandem wehtun. Die moderne SharePoint-Welt ist flach: viele einzelne Websites, jede mit klarem Zweck und eigenem Berechtigungskreis, verbunden über Hub Sites. Die tiefen Websitesammlungs-Bäume der Server-Ära mit Untersites in fünfter Ebene sind Geschichte — und das ist gut so, denn diese Bäume waren in der Praxis vor allem eines: Berechtigungs-Albträume mit Navigationsproblemen.

Abb.: Moderne Informationsarchitektur — flache Websites, verbunden über eine Hub Site. Innerhalb jeder Website: Bibliotheken, Listen und Seiten mit klar getrennten Aufgaben.

Websites, Bibliotheken, Listen, Seiten

Die vier Grundbausteine, einmal sauber sortiert: Eine Website ist der Container mit eigenem Berechtigungskreis — pro Thema, Team oder Zweck eine. Dokumentbibliotheken speichern Dateien samt Metadaten, Versionen und Regeln. Listen speichern strukturierte Daten ohne Datei — Maßnahmen, Anfragen, Geräte, was auch immer — und sind der natürliche Andockpunkt für Power Apps und Power Automate. Seiten schließlich sind das Gesicht: moderne, responsive Pages für News, Wissensartikel und Handbücher.

Hub statt Hierarchie

Hub Sites verbinden Websites logisch, ohne sie technisch zu verschachteln: gemeinsame Navigation, gemeinsames Erscheinungsbild, übergreifende Suche und News-Rollup. Der entscheidende Vorteil: Die Zuordnung zu einem Hub ist eine Einstellung, keine Ehe. Reorganisation im Unternehmen? Website vom einen Hub lösen, an den anderen hängen, fertig. Wer das mit klassischen Untersites erlebt hat, weiß, dass „Umziehen“ dort eher „Migrationsprojekt“ hieß.

Inhaltstypen: das unterschätzte Fundament

Jetzt wird es interessant — und zwar genau an der Stelle, die in neun von zehn SharePoint-Einführungen übersprungen wird. Ein Inhaltstyp beantwortet die Frage, die ein Fileserver nie stellen würde: Was ist dieses Dokument eigentlich? Ein Vertrag ist etwas anderes als ein Protokoll, ein Angebot etwas anderes als eine Arbeitsanweisung. Und weil sie etwas anderes sind, brauchen sie andere Metadaten, andere Vorlagen, andere Genehmigungswege und andere Aufbewahrungsfristen.

Ein Inhaltstyp bündelt genau das: die Spalten (Metadaten), die Dokumentvorlage, die Richtlinien und die Prozesse für eine Dokumentart — zentral definiert, überall verfügbar. Dazu kommt Vererbung: Aus dem Basistyp „Dokument“ wird „Vertrag“, daraus „Rahmenvertrag“ und „NDA“. Eine neue Pflichtspalte für alle Verträge? Eine Änderung am Elterntyp, und die Kinder ziehen mit.

Abb.: Anatomie eines Inhaltstyps (links) und Vererbung vom Allgemeinen zum Speziellen (rechts). Zentral definieren, überall nutzen — das ist der Unterschied zwischen Bibliotheks-Bastelei und System.

Warum das so wichtig ist: Ohne Inhaltstypen ist jede Bibliothek ein Unikat mit selbstgestrickten Spalten. „Vertrag“ heißt in Bibliothek A „Vertragsart“, in B „Dokumenttyp“ und in C gar nichts. Die Suche kann darauf nicht filtern, Automatisierung nicht andocken, und Auswertungen über Bibliotheksgrenzen hinweg kannst du vergessen. Mit Inhaltstypen wird aus vierzehn Bastellösungen ein System — und aus SharePoint eine Plattform.

Taxonomie: ein Vokabular für alle

Metadaten sind nur so gut wie ihre Werte. Und hier lauert der Klassiker: die Freitextspalte. Drei Monate nach Einführung stehen in der Spalte „Standort“ die Werte „Düsseldorf“, „Ddorf“, „Duesseldorf“, „NL West“ und einmal, aus Gründen, „siehe Dateiname“. Herzlichen Glückwunsch — die Spalte ist jetzt Deko.

Die Lösung heißt Taxonomie: der Term Store, ein zentrales, mandantenweites Vokabular. Termgruppen enthalten Termsets (Standorte, Produktlinien, Dokumentarten …), Termsets enthalten Terme — hierarchisch, mehrsprachig, mit Synonymen. Eine verwaltete Metadatenspalte bietet dann Auswahl statt Freitext: Tippfehler haben Hausverbot, und wenn die Niederlassung umbenannt wird, änderst du den Term an einer Stelle — alle Dokumente ziehen mit.

Abb.: Der Term Store als zentrales Vokabular — Gruppen, Termsets, Terme mit Synonymen. Verwaltete Spalten und Suche greifen auf dasselbe Vokabular zu.

Ordner vs. Metadaten: der ewige Glaubenskrieg

Kaum eine Diskussion wird in SharePoint-Projekten so leidenschaftlich geführt wie diese — meist von Leuten, die seit 25 Jahren Ordner anlegen und das auch die nächsten 25 Jahre vorhaben. Deshalb einmal nüchtern: Ein Ordnerbaum kodiert genau eine Sichtweise auf die Dokumente. Kunde → Jahr → Thema. Wer die Frage anders stellt — „alle Verträge, die dieses Jahr auslaufen“ — steht im falschen Ast und fängt an zu klicken. Oder schlimmer: legt eine Kopie im anderen Ast an.

Abb.: Dasselbe Dokument in zwei Welten. Links der Ordnerpfad mit genau einem Weg (inklusive des unvermeidlichen Ordners „wirklich_final“), rechts ein Dokument mit Metadaten und beliebig vielen Ansichten.

Metadaten drehen das Prinzip um: Ein Dokument, viele Sichten. Dieselbe Bibliothek zeigt sich gruppiert nach Kunde, gefiltert nach Jahr oder sortiert nach Status — je nachdem, wer gerade was braucht. Kein Original wird kopiert, keine Parallelwelt entsteht, und die Suche kann über Eigenschaften filtern statt über Dateinamen-Archäologie.

Heißt das, Ordner sind verboten? Nein. Ordner haben legitime Einsatzzwecke: als Berechtigungsgrenze innerhalb einer Bibliothek, als grobe Erstsortierung bei Massenablage, als Zugeständnis an synchronisierte Arbeitsweisen mit dem Explorer. Aber sie sind ein Werkzeug für Sonderfälle — nicht das Ordnungsprinzip. Wer eine Bibliothek plant, plant zuerst Inhaltstypen und Spalten, dann Ansichten, und erst ganz am Ende, widerwillig, vielleicht einen Ordner.

Die Suche: der heimliche Star

Und jetzt der Teil, in dem sich alle Vorarbeit auszahlt. Die SharePoint- beziehungsweise Microsoft-Suche indiziert nicht nur Volltext, sondern auch Metadaten: Aus gecrawlten Eigenschaften werden verwaltete Eigenschaften (Managed Properties), und die kannst du in Abfragen, Filtern und Verfeinerungen nutzen. Eine Suche nach „Vertrag Meier 2026“ ist nett. Eine Suche, die per Klick auf Dokumentart, Kunde und Status einschränkt, ist ein Arbeitsinstrument.

Abb.: Die Such-Pipeline von Inhalten über Crawl und Index bis zur Abfrage — und ihre Konsumenten: Suchseiten, Rollup-Webparts und Microsoft 365 Copilot, der über denselben Index arbeitet.

Der unterschätzte Teil: Die Suche ist nicht nur das Suchfeld oben rechts. Sie ist auch der Motor hinter dynamischen Inhalten — Webparts wie „Hervorgehobene Inhalte“ oder die PnP-Modern-Search-Webparts bauen aus Suchabfragen lebende Übersichten: alle gültigen Arbeitsanweisungen eines Bereichs, alle Wissensartikel zu einem Produkt, alle Verträge mit Ablaufdatum im nächsten Quartal. Solche Rollups sind der Kern jedes ernsthaften Wissensportals — und sie funktionieren exakt so gut, wie die Metadaten gepflegt sind.

Und dann ist da noch der neue prominente Konsument: Copilot beantwortet Fragen auf Basis desselben Index und derselben Berechtigungen. Die Suche ist damit endgültig kein Komfortfeature mehr, sondern die Datenversorgung der KI. Wer der Suche Müll füttert, bekommt von Copilot denselben Müll zurück — nur selbstbewusster formuliert.

Dokumentenmanagement: mehr als Dateiablage

Dokumentenmanagement ist die Disziplin, in der SharePoint richtig stark ist — wenn man die Funktionen tatsächlich einschaltet, statt sie im Standardzustand vor sich hin dämmern zu lassen. Die Bausteine:

Versionierung und Check-out

Jede Änderung eine Version, jede Version wiederherstellbar — das ist die Basis. Interessant wird es mit Haupt- und Nebenversionen: Entwürfe laufen als 0.1, 0.2, 0.3, und erst die Freigabe erzeugt die Hauptversion 1.0. Kombiniert mit der Einstellung, dass Leser nur Hauptversionen sehen, hast du das Grundgerüst gelenkter Dokumente — Autoren arbeiten an 1.3, die Organisation sieht stabil 1.0. Check-out verhindert bei Bedarf konkurrierende Änderungen; in der modernen Co-Authoring-Welt braucht man es seltener, aber für formale Dokumente hat es weiter seinen Platz.

Genehmigungen

Inhaltsgenehmigung sorgt dafür, dass nichts ohne Vier-Augen-Prinzip sichtbar wird. Für einfache Fälle reicht die eingebaute Genehmigung, für echte Prozesse — mehrstufig, mit Vertretungsregeln, Eskalation und Protokoll — kommt Power Automate ins Spiel. Wichtig ist die Reihenfolge: erst den Prozess auf Papier klären, dann automatisieren. Ein chaotischer Prozess wird durch Automatisierung nicht besser, nur schneller chaotisch.

Aufbewahrung und Compliance

Aufbewahrungsrichtlinien und -etiketten (Retention Labels aus Microsoft Purview) regeln, wie lange Dokumente leben müssen und wann sie sterben dürfen — beides ist wichtig, denn Aufbewahrung ohne definierte Löschung ist nur organisiertes Horten. Für geschäftskritische Nachweise gibt es Records-Funktionen: Ein deklarierter Datensatz ist unveränderbar, und genau das will der Auditor sehen. Das Schöne: All das dockt an Inhaltstypen an. Der Inhaltstyp „Vertrag“ bringt seine Aufbewahrungsregel gleich mit — niemand muss daran denken.

Wissensmanagement: damit Wissen nicht in Ordnern stirbt

Wissensmanagement scheitert selten an der Technik und fast immer an zwei Dingen: Das Wissen wird nicht aufgeschrieben, oder es wird aufgeschrieben und nie wieder gefunden. Gegen das erste hilft Kultur, gegen das zweite hilft — richtig eingesetzt — SharePoint.

Das Muster, das sich in der Praxis bewährt: Wissensartikel als moderne Seiten statt als Word-Dateien in Ordnern. Seiten sind sofort lesbar, mobil brauchbar, intern verlinkbar, versionierbar und — entscheidend — erstklassig durchsuchbar. Dazu ein Inhaltstyp oder Seitenmetadaten (Themengebiet, Produkt, Gültigkeit, Verantwortlicher), Terme aus dem Term Store zur Verschlagwortung, und Rollup-Webparts, die daraus dynamische Themenportale bauen. Neuer Artikel mit dem Term „Serie A“? Erscheint automatisch im Serie-A-Portal, ohne dass jemand eine Linkliste pflegt.

Der oft übersehene Bonus: Ein Verantwortlicher plus ein Überprüfungsdatum pro Artikel, ausgewertet über eine simple Ansicht oder einen Flow — und schon hat dein Wissensbestand ein Verfallsdatum-Management. Nichts zerstört Vertrauen in eine Wissensbasis schneller als der Artikel, der seit vier Jahren eine Version empfiehlt, die längst abgekündigt ist. Eine Wissensbasis, der man nicht traut, wird nicht genutzt; eine, die nicht genutzt wird, wird nicht gepflegt — und die Spirale dreht sich abwärts. Pflege ist keine Kür, sie ist der Betrieb.

Publishing: QM-Handbücher und andere gelenkte Dokumente

Mein persönliches Lieblingsthema, weil hier alles zusammenkommt: Inhaltstypen, Versionierung, Genehmigung, Metadaten, Suche — und ein sehr konkreter, sehr messbarer Nutzen. Gelenkte Dokumente — QM-Handbücher, Arbeitsanweisungen, Prozessbeschreibungen, Formulare — haben harte Anforderungen: Es gilt immer genau eine freigegebene Fassung, Änderungen laufen über definierte Freigaben, alte Fassungen bleiben nachvollziehbar archiviert, und im Audit muss das alles belegbar sein.

Abb.: Der Lebenszyklus eines gelenkten Dokuments — Entwurf, Prüfung, Freigabe, Veröffentlichung, Archiv. Leser sehen ausschließlich freigegebene Hauptversionen; jede Station ist protokolliert.

Genau diesen Lebenszyklus bildet SharePoint mit Bordmitteln ab: Nebenversionen für Entwürfe, Genehmigungsfluss für die Prüfung, Hauptversionen für die Freigabe, Leseberechtigungen nur auf freigegebene Fassungen, Aufbewahrung fürs Archiv. Dazu die Publishing-Frage: Bleibt das Handbuch ein Dokument, oder wird es ein Seitensystem? Meine Erfahrung: Für die Nutzung im Alltag schlagen Seiten jedes PDF — verlinkbar, durchsuchbar, mobil, mit Rollups pro Bereich. Das formale Dokument kann es zusätzlich geben, generiert aus derselben Quelle statt parallel gepflegt.

SharePoint und Teams: Freund, nicht Feind

„Wir brauchen kein SharePoint, wir haben doch Teams“ — dieser Satz fällt in erstaunlich vielen Gesprächen, und er ist ungefähr so richtig wie „Wir brauchen keinen Motor, wir haben doch ein Auto“. Jedes Team speichert seine Dateien in einer SharePoint-Website, jeder Kanal ist ein Ordner in deren Bibliothek. Teams ist die Oberfläche für Kommunikation und schnelle Zusammenarbeit; SharePoint ist der strukturierte Unterbau darunter.

Die praktische Konsequenz: Alles, was du in diesem Text über Inhaltstypen, Metadaten und Ansichten gelesen hast, funktioniert auch für Teams-Dateien — weil es dieselben Bibliotheken sind. Die Kunst liegt in der Arbeitsteilung: lebendige Projektarbeit in den Kanalordnern, formale und dauerhafte Ablage in dafür gebauten Bibliotheken mit Struktur und Regeln. Und ein Karriereende für den Reflex, für jedes Thema ein neues Team zu gründen: Aus jedem Team wird eine Website mit einer Microsoft-365-Gruppe, und ohne Governance hast du in zwei Jahren 400 Teams, von denen 280 seit achtzehn Monaten niemand mehr betreten hat — jede einzelne mit vollem Datenbestand, den die Suche und Copilot brav weiter ausliefern.

SharePoint Server oder SharePoint Online?

Für die große Mehrheit ist die Frage entschieden: SharePoint Online in Microsoft 365 ist die Plattform, in die Microsoft investiert — moderne Oberflächen, Copilot-Integration, Purview-Compliance, keine eigenen Farmen, keine Patch-Wochenenden. Wer heute neu startet, startet online, und braucht für alles andere sehr gute Gründe.

Aber es gibt sie, die guten Gründe: Datenresidenz- und Compliance-Vorgaben, Netztrennung, Souveränitätsanforderungen, tief verwachsene Fachanwendungen. Für diese Fälle existiert SharePoint Server Subscription Edition — kein abgekündigtes Auslaufmodell, sondern ein gepflegtes Produkt im Abo-Modell mit regelmäßigen Feature-Updates. Nur muss man ehrlich rechnen: Eine Server-Farm bedeutet Infrastruktur, SQL Server, Patching, Sicherung, Know-how — die Gesamtkosten stehen in keinem charmanten Verhältnis zur Online-Welt. Wer on-premises bleibt, sollte es aus dokumentierten Gründen tun, nicht aus Gewohnheit. Und die hybride Koexistenz will geplant sein: eine Suche, klare Zuständigkeit pro Inhaltsart, definierte Migrationsperspektive — sonst betreibt man zwei halbe Plattformen statt einer ganzen.

Migration: erst denken, dann schieben

Ob von Fileservern, von einer alten SharePoint-Farm oder aus dem Fremdsystem: Eine Migration ist die einzige Gelegenheit, den angesammelten Datenmüll von 15 Jahren nicht mitzunehmen. Die meisten Projekte verschenken genau diese Gelegenheit — mit dem Argument „keine Zeit, wir räumen hinterher auf“. Spoiler: Hinterher hat noch nie jemand aufgeräumt. Hinterher ist der Müll nur in der Cloud.

Abb.: Migration in fünf Phasen — Inventur, Bereinigung, Pilot, Wellen, Nacharbeit. Das Anti-Pattern „Lift and Shift“ verlagert die Deponie nur; übersetzt wird trotzdem nicht.

Der Weg, der funktioniert: Erst Inventur — was liegt wo, was wird genutzt, was wurde seit 2014 nicht mehr angefasst, welche Customizings und Workflows existieren. Dann Bereinigung und Zielbild: Löschen, was tot ist; zusammenlegen, was doppelt ist; die Zielstruktur mit Inhaltstypen und Taxonomie definieren. Dann ein Pilot mit einem echten Fachbereich und echten Daten, um das Mapping zu testen — Metadaten, Versionen, Berechtigungen. Erst danach die Wellen, Fachbereich für Fachbereich, mit Kommunikation und Schulung. Und am Ende die Nacharbeit, inklusive des Moments, den viele vergessen: die Quelle schreibgeschützt stellen. Solange die alte Ablage beschreibbar ist, arbeiten die Kollegen dort munter weiter, und du migrierst denselben Bestand ein zweites Mal.

Governance: gegen den Wildwuchs

SharePoint-Governance hat einen schlechten Ruf, weil sie oft als 80-Seiten-Dokument daherkommt, das niemand liest. Dabei ist der Kern simpel: ein paar Entscheidungen, die getroffen, dokumentiert und technisch verankert werden. Wer darf Websites und Teams erstellen — jeder, oder läuft das über einen Antragsprozess mit Vorlagen? Welche Metadaten sind unternehmensweit Pflicht? Wie heißen Websites (Namenskonventionen sind unsexy und Gold wert)? Was passiert mit inaktiven Websites — Ablaufrichtlinien, Archivierung, Löschung? Und wer ist pro Website verantwortlich, mit Namen und Vertretung?

Die technische Seite liefert Microsoft 365 mit: Bereitstellung über definierte Vorlagen, Ablauf- und Inaktivitätsrichtlinien, Vertraulichkeitsbezeichnungen für Websites, Freigabe-Einstellungen pro Website statt Konzern-Gießkanne. Der Punkt ist nicht, alles zu verbieten — der Punkt ist, dass Struktur von selbst entsteht, wenn der bequemste Weg der richtige ist. Eine gute Website-Vorlage mit fertigen Inhaltstypen wird genutzt, weil sie Arbeit spart. Das ist Governance, die funktioniert: nicht als Polizei, sondern als gepflasterter Weg.

SharePoint und Copilot: die Stunde der Wahrheit

Microsoft 365 Copilot hat eine bemerkenswerte Nebenwirkung: Er macht die Qualität deiner Informationsarchitektur sichtbar — gnadenlos. Copilot beantwortet Fragen auf Basis dessen, was der fragende Nutzer sehen darf, gefunden über denselben Index wie die Suche. Drei Konsequenzen:

• Erstens, Berechtigungen: Jahrelang war „versehentlich zu breit geteilt“ ein theoretisches Problem, weil niemand danach suchte. Copilot sucht. Die Gehaltsliste, die 2021 mit „Jeder außer externen Benutzern“ freigegeben wurde, ist jetzt eine Chat-Antwort entfernt. Vor dem Copilot-Rollout gehört deshalb eine Oversharing-Analyse ins Programm — Freigabeberichte, Restricted Content Discovery für heikle Websites, Aufräumen der „Jeder“-Links.
• Zweitens, Datenqualität: Copilot unterscheidet nicht zwischen der gültigen Arbeitsanweisung und ihren fünf veralteten Vorgängern, wenn beide gleichberechtigt herumliegen. Versionslenkung, Archivierung und Aufräumen sind plötzlich KI-Themen.
• Drittens, Struktur: Saubere Metadaten, gepflegte Seiten und klare Benennung verbessern messbar, was Copilot findet und wie er es einordnet. Die unbequeme Wahrheit: Es gibt keinen KI-Zauberstab, der eine kaputte Ablage kompensiert. Die gute Nachricht: Alles, was Copilot besser macht, macht auch ohne Copilot den Arbeitsalltag besser. Die Investition zahlt doppelt.

Die Klassiker: was in der Praxis schiefgeht

Nach mehr als zwei Jahrzehnten SharePoint-Projekten wiederholen sich die Fehlerbilder mit beruhigender Zuverlässigkeit. Die Hitliste:

• Der Fileserver-Reflex: Ordnerbäume nachbauen, Metadaten ignorieren, sich über die Suche beschweren. Das Problem sitzt nicht im Produkt.
• Die Struktur-Orgie: Das Gegenteil — 60 Inhaltstypen, zwölf Pflichtfelder, dreistufige Genehmigung für Besprechungsnotizen. Nutzer weichen dann auf OneDrive, E-Mail-Anhänge oder, Gott bewahre, den Desktop aus. Struktur muss dienen, nicht herrschen.
• Berechtigungen im Blindflug: Einzelberechtigungen auf Dokumentebene, unterbrochene Vererbung überall, niemand weiß mehr, wer was sieht. Faustregel: Berechtigungen auf Website-Ebene über Gruppen, Ausnahmen dokumentiert und selten.
• Das Projekt ohne Betrieb: Einführung als Projekt, danach ist niemand zuständig. SharePoint ohne Ownership verwildert — nicht sofort, aber sicher. Jede Website braucht einen Verantwortlichen mit Namen, nicht mit Abteilungsbezeichnung.
• Adoption als Fußnote: Die beste Struktur nützt nichts, wenn niemand sie versteht. Kurze, rollenbezogene Schulungen und sichtbare Quick Wins schlagen jede Intranet-Ankündigung.

Fazit: SharePoint kann viel — wenn man es lässt

SharePoint ist nicht kompliziert, weil Microsoft das so wollte, sondern mächtig, weil die Aufgabe es ist: Inhalte in Organisationen zu strukturieren, ist nun mal keine Trivialität. Die gute Nachricht: Die Konzepte, die den Unterschied machen, sind überschaubar — Informationsarchitektur, Inhaltstypen, Taxonomie, Suche, Lebenszyklus. Wer diese fünf Dinge versteht und konsequent anwendet, bekommt eine Plattform für Dokumentenmanagement, Wissensmanagement und Publishing, die jeden Vergleich mit Speziallösungen aushält — und die nebenbei die Grundlage dafür legt, dass Teams produktiv bleibt und Copilot Sinnvolles antwortet.

Was du nicht tun solltest: SharePoint einfach laufen lassen und hoffen, dass Struktur von allein entsteht. Tut sie nicht. Entropie ist im Datenbestand genauso zuverlässig wie in der Physik — nur schneller.

FAQ: die häufigsten Fragen zu SharePoint

Ist SharePoint nicht veraltet?

Das Gegenteil ist der Fall. SharePoint ist der Speicher- und Struktur-Unterbau von Microsoft 365 — unter Teams, OneDrive, dem Intranet und Copilot. Veraltet sind höchstens bestimmte Nutzungsmuster: der Ordnerfriedhof, die Untersite-Kaskade, das Intranet von 2012. Die Plattform selbst wird laufend weiterentwickelt und ist relevanter denn je.

Können wir nicht einfach Teams statt SharePoint nutzen?

Ihr nutzt mit Teams bereits SharePoint — jede Dateiablage in Teams ist eine SharePoint-Bibliothek. Die Frage ist also nicht ob, sondern wie bewusst: Mit etwas Struktur in den dahinterliegenden Bibliotheken wird aus der Teams-Dateiablage ein Dokumentenmanagement; ohne bleibt es ein Ordnerchaos mit Chat-Anschluss.

Brauchen wir wirklich Metadaten? Unsere Leute wollen Ordner.

Die ehrliche Antwort: Ihr braucht beides in der richtigen Dosis. Metadaten dort, wo gefunden, gefiltert, automatisiert und ausgewertet wird; Ordner allenfalls als Berechtigungsgrenze oder Grobsortierung. Der Trick ist, den Einstieg leicht zu machen: wenige, sinnvolle Spalten mit Auswahlwerten statt zwölf Pflicht-Freitextfeldern. Und ein Vorzeigebeispiel, das den Nutzen zeigt, überzeugt mehr als jede Richtlinie.

Was sind Inhaltstypen, in einem Satz?

Ein Inhaltstyp definiert zentral, was eine Dokumentart ist und welche Regeln für sie gelten — Metadaten, Vorlage, Genehmigung, Aufbewahrung — damit „Vertrag“ überall im Unternehmen dasselbe bedeutet und dieselben Regeln mitbringt.

Eignet sich SharePoint für QM-Handbücher und gelenkte Dokumente?

Ja, und zwar mit Bordmitteln: Haupt- und Nebenversionen, Inhaltsgenehmigung, Leserechte nur auf freigegebene Fassungen, Aufbewahrungsetiketten fürs Archiv. Damit lassen sich die Anforderungen an gelenkte Dokumente — eine gültige Fassung, definierte Freigaben, nachvollziehbare Historie — sauber und auditfest abbilden.

Wie viele Websites sollten wir anlegen — eine große oder viele kleine?

Viele kleine, verbunden über Hub Sites. Eine Website pro Thema, Team oder Zweck, mit eigenem Berechtigungskreis. Das hält Berechtigungen einfach, macht Reorganisationen zum Mausklick statt zum Migrationsprojekt und skaliert besser als jeder Baum.

Migrieren wir unsere Fileserver einfach 1:1 nach SharePoint?

Bitte nicht. Eine 1:1-Kopie verlagert die Deponie nur in die Cloud — inklusive aller Duplikate, Leichen und „wirklich_final_v3“-Ordner. Der Wert einer Migration entsteht im Übersetzen: Inventur, Bereinigung, Ordnerpfade zu Metadaten, dann in Wellen umziehen und die Quelle schreibgeschützt stellen.

Was hat SharePoint mit Copilot zu tun?

Alles. Copilot beantwortet Fragen auf Basis der Inhalte, die überwiegend in SharePoint liegen — gefunden über denselben Index wie die Suche, begrenzt durch dieselben Berechtigungen. Datenqualität, Versionslenkung und saubere Berechtigungen sind damit direkt KI-relevante Themen. Wer Copilot einführt, ohne vorher Oversharing und Altbestände anzugehen, erlebt Überraschungen — selten angenehme.

SharePoint Online oder SharePoint Server?

Im Regelfall Online: Dort finden Innovation, Copilot-Integration und Compliance-Funktionen statt, ohne eigenen Farmbetrieb. SharePoint Server Subscription Edition bleibt die richtige Wahl, wenn harte Gründe wie Datenresidenz, Netztrennung oder verwachsene Fachanwendungen es erfordern — dann aber als bewusste, dokumentierte Entscheidung mit ehrlicher Kostenrechnung.

Wo fangen wir an, wenn unser SharePoint schon verwildert ist?

Mit einer ehrlichen Standortbestimmung: Was liegt wo, was wird genutzt, wo klemmt es wirklich? Danach ein überschaubarer, sichtbarer Erfolg — eine wichtige Bibliothek oder ein Fachbereich, richtig gebaut. Der große Wurf auf dem Papier scheitert regelmäßig; das funktionierende Beispiel überzeugt und wächst.