SharePoint Best Practices: Struktur, Berechtigungen & Governance

Die meisten SharePoint-Probleme sind keine technischen Probleme. Die Plattform funktioniert – die Art, wie sie eingerichtet wurde, nicht. Jemand hat den alten Dateiserver als fünfstufigen Subsite-Baum nachgebaut, einem Dutzend Personen Full Control gegeben, um eine Deadline zu überbrücken, und nie aufgeschrieben, wie eine Site heißen oder wann ihr Inhalt ablaufen soll. Zwei Jahre später findet niemand mehr etwas, und die Suche bekommt die Schuld.

Dieser Guide fasst die SharePoint Best Practices zusammen, die genau das verhindern – in der Reihenfolge, in der sie relevant sind. Er behandelt Struktur, Dokumentenbibliotheken und Metadaten, Dokumentenmanagement, Berechtigungen und externes Teilen, Governance sowie Adoption. Jeder Abschnitt ist eine kompakte Übersicht mit den Entscheidungen, die tatsächlich getroffen werden müssen – wo vertiefende Informationen benötigt werden, verweisen Links auf dedizierte Guides. Wer noch prüft, ob SharePoint überhaupt die richtige Plattform ist, startet am besten mit Was ist SharePoint und wofür wird es verwendet.

Vorab noch eine wichtige Anmerkung: Viele SharePoint-Empfehlungen, die nach wie vor kursieren, wurden für die Classic-Oberfläche geschrieben – vor Hub Sites, vor Microsoft 365-Gruppen und bevor Teams hinter jedem Kanal eine SharePoint-Site angelegt hat. Einige davon sind inzwischen schlicht falsch – das deutlichste Beispiel ist die verschachtelte Subsite-Hierarchie. Wo dieser Guide von älteren Quellen abweicht, hat das in der Regel diesen Grund.

Kurzüberblick: Die wichtigsten SharePoint Best Practices

Wenn nur sechs Dinge verbessert werden, sollten es diese sein:

• Flache Struktur beibehalten. Separate Sites erstellen und über eine Hub Site verbinden, anstatt Subsites in eine Root-Site-Collection zu verschachteln.
• Metadaten statt tiefer Ordnerstrukturen. Spalten und Ansichten ermöglichen es, eine Datei auf sechs verschiedene Arten zu finden; ein Ordnerpfad erlaubt genau eine.
• Least-Privilege-Prinzip anwenden. Berechtigungen an Gruppen vergeben, auf der breitesten sinnvollen Ebene, und eindeutige Berechtigungen auf Elementebene als dokumentierte Ausnahme behandeln.
• Externes Teilen gezielt steuern. Die Mandantenstandard-Einstellung auf die restriktivste Option setzen, die noch funktionales Arbeiten erlaubt – und site-weise lockern.
• Governance schriftlich festhalten. Benennungsstandards, Versionierungseinstellungen, Site-Anfrageprozess, Aufbewahrungsfristen und Überprüfungsdaten – eine Seite, die niemand geschrieben hat, hält sich auch niemand.
• Adoption planen. Mit einem Team pilotieren, Champions schulen, Inhalte migrieren, bevor der Wechsel erwartet wird, und das alte Laufwerk zu einem festen Datum abschalten.

Die Reihenfolge ist entscheidend. Berechtigungen lassen sich einfacher auf einer flachen Struktur planen. Governance ist leichter durchzusetzen, wenn Metadaten bereits vorhanden sind. Adoption gelingt einfacher, wenn die ersten drei Punkte umgesetzt sind – weil die Umgebung dann navigierbar ist.

Diese Praktiken gelten gleichermaßen beim Aufbau eines neuen Mandanten, beim Bereinigen eines organisch gewachsenen Umfelds und bei der Migration von einem Dateiserver. Wer eine bestehende Umgebung übernimmt, sollte dem Impuls widerstehen, alles auf einmal neu zu gestalten. Die Struktur für neue Inhalte korrigieren, alte Inhalte mit einer klaren Kennzeichnung an Ort und Stelle lassen und sie in Batches migrieren, während Teams sie wieder aufgreifen. Eine perfekte Architektur, in die niemand umgezogen ist, ist keine Verbesserung.

Abb. 1. Die fünf Säulen der SharePoint Best Practices und die Reihenfolge, in der sie angegangen werden sollten.

Struktur und Architektur: Flach bleiben, mit Hub Sites verbinden

Die folgenreichste Entscheidung in einer SharePoint-Umgebung ist die Informationsarchitektur – wie viele Sites es gibt, wofür jede einzelne steht und wie sie zusammenhängen. Wird sie falsch getroffen, lassen sich alle späteren Probleme (Berechtigungschaos, defekte Links, unzuverlässige Suche) darauf zurückführen.

Warum die Subsite-Hierarchie keine Best Practice mehr ist

Klassisches SharePoint favorisierte eine Baumstruktur: eine Root-Site-Collection, Abteilungen als Subsites, Teams als Subsites davon, Projekte eine Ebene tiefer. Das spiegelte das Organigramm wider, wirkte intuitiv – und verursachte vier vorhersehbare Probleme.

• Berechtigungen vererben sich nach unten; eine Änderung nahe der Spitze wirkt sich still und leise mehrere Ebenen weiter unten aus.
• URLs werden lang und fragil. Das Verschieben eines Astes zerstört jeden Link, jedes Lesezeichen und jeden Dokumentverweis darin.
• Umstrukturierungen sind aufwändig. Wenn Marketing und Kommunikation zusammengelegt werden, muss die Struktur neu aufgebaut statt einfach umgeleitet werden.
• Speicher-, Such- und Lebenszykluseinstellungen gelten für die gesamte Collection statt für das Team, dem der Inhalt gehört.

Subsites existieren weiterhin und es gibt schmale Anwendungsfälle dafür – sie sind jedoch nicht mehr die Standardantwort. Microsofts eigene Anleitung zur modernen Informationsarchitektur empfiehlt eine flache Struktur, ebenso alle, die schon einmal einen Baum entwirren mussten.

Das flache Modell: eine Site pro Aufgabenbereich, Hub Sites für die Verbindungen

Im modernen SharePoint erhält jedes Team, Projekt oder jede Abteilung seine eigene Site auf oberster Ebene. Eine Hub Site verbindet diese Sites anschließend, sodass sie Navigation, Branding, Suchbereich und News teilen. Die Beziehung ist eine Eigenschaft, kein Standort – eine Site kann in wenigen Klicks einer anderen Hub Site zugeordnet werden, ohne dass sich eine URL ändert.

Abb. 2. Dieselbe Organisation als verschachtelter Subsite-Baum und als flache Sites, die über eine Hub Site verbunden sind.

Best Practices für die Informationsarchitektur

• Eine Site pro Aufgabenbereich, nicht pro Teammitglied oder pro Jahr. Wenn ein Projekt endet, wird die Site archiviert – keine Subsite für die Folgeversion erstellen.
• Den Site-Typ bewusst wählen. Team Sites für kollaboratives Arbeiten mit einer Microsoft 365-Gruppe im Hintergrund; Communication Sites für die Einweg-Kommunikation wie Richtlinien, News und eine Intranet-Startseite.
• Hub Sites planen, bevor sie erstellt werden. Ein Mandant hat eine begrenzte Anzahl an Hub Sites, und eine Hub Site mit vierzig zugehörigen Sites hat dasselbe Navigationsproblem wie ein Ordner mit vierzig Unterordnern. Microsofts Leitfaden zur Hub-Site-Planung lohnt sich vor der ersten Erstellung.
• Navigation nach der Suchweise der Nutzer gestalten, nicht nach der Unternehmensstruktur. Hub-Navigation, Site-Navigation und das Mega-Menü bedienen jeweils unterschiedliche Zielgruppen – siehe Planung der Site-Navigation.
• Die Anzahl der Top-Level-Einstiegspunkte klein halten. Die meisten Nutzer sollten alles, was sie brauchen, in drei Klicks von der Intranet-Startseite aus erreichen.
• Sites so benennen, dass sie auch Außenstehende verstehen. „HR-Richtlinien" ist besser als „Team Site 4" – und deutlich besser als „Sharons Site".
• Site-Vorlagen verwenden, um neue Sites konsistent zu halten. Site Scripts und Site Designs richten Bibliotheken, Spalten, Ansichten und Einstellungen automatisch ein, sodass Best Practices die Standardlösung sind und nicht erst erklärt werden müssen.

Team Site oder Communication Site?

Diese Wahl wird einmal pro Site getroffen und lässt sich nur umständlich rückgängig machen – es lohnt sich also, dreißig Sekunden darüber nachzudenken. Eine Team Site ist für eine Gruppe von Menschen gedacht, die gemeinsam arbeiten: Sie kommt mit einer Microsoft 365-Gruppe, einem gemeinsamen Postfach und – wenn aus Teams heraus erstellt – einem Teams-Kanal. Mitgliedschaft und Berechtigungen werden über diese Gruppe verwaltet, und standardmäßig können alle Mitglieder Inhalte beisteuern.

Eine Communication Site dient der Veröffentlichung für eine Zielgruppe, die hauptsächlich liest: Richtlinien, News, ein HR-Portal, eine Produkt-Wissensdatenbank. Eine kleine Redaktionsgruppe bearbeitet Inhalte; alle anderen haben Lesezugriff. Sie hat keine Microsoft 365-Gruppe im Hintergrund, was die Berechtigungsverwaltung vereinfacht und ihren Lebenszyklus von einem bestimmten Team unabhängig macht.

Der typische Fehler ist, eine Team Site als Intranet zu verwenden. Alle Mitglieder erhalten Bearbeitungsrechte auf das Unternehmenshandbuch – weil das nun mal der Standard bei Team-Site-Mitgliedschaft ist – und die Zielgruppe fragt sich, warum auf der Newsseite ein Reiter „Dateien" erscheint. Wenn das primäre Verb „lesen" ist, sollte eine Communication Site verwendet werden.

Hinweis zu Sites, die durch Microsoft Teams erstellt werden

Jedes Teams-Team erstellt eine SharePoint-Site, und jeder Kanal erstellt einen Ordner in der Dokumentenbibliothek dieser Site. Das ist praktisch – und gleichzeitig die häufigste Quelle für ungeplantes Wachstum, denn wer ein Team erstellen kann, erstellt auch eine Site. Zwei Maßnahmen halten das handhabbar: Eine Benennungsrichtlinie und eine Ablaufrichtlinie für Microsoft 365-Gruppen einrichten, damit inaktive Teams sich nicht anhäufen – und bewusst entscheiden, welche Inhalte in eine Teams-gestützte Site gehören und welche in eine eigenständige SharePoint-Site. Arbeitsdateien und Kanalunterhaltungen gehören in Teams; Referenzinhalte für die gesamte Organisation nicht.

Dokumentenbibliotheken und Metadaten: Aufhören, Ordnerbäume zu bauen

Eine Dokumentenbibliothek ist kein Netzlaufwerkordner mit einer Webseite davor. Sie ist eine Liste mit Spalten – und die Spalten machen sie nützlich. Teams, die Bibliotheken wie Dateifreigaben behandeln, erhalten Dateifreigabe-Ergebnisse.

Warum Metadaten besser sind als Ordner

Ein Ordner legt eine Datei an genau einem Ort ab. Alle, die diese Datei suchen, müssen denselben Pfad erraten, in derselben Reihenfolge, mit demselben Vokabular. Metadaten platzieren dieselbe Datei an so vielen Stellen, wie es nützliche Fragen gibt: Wem gehört sie, welchen Typ hat sie, welcher Kunde, welche Phase, wann läuft sie ab?

Abb. 3. Derselbe Vertrag – abgelegt in einem Ordnerpfad und beschrieben mit Metadatenspalten.

Hinter dem Rat stehen auch technische Grenzen. Tiefe Ordnerpfade erzeugen lange URLs, und Ansichten, die mehr als 5.000 Elemente auf einmal anzeigen sollen, stoßen an die Listenansichtsschwelle. Gut gestaltete Metadaten mit Ansichten umgehen beides – Microsofts Leitfaden zu großen Listen und Bibliotheken erklärt, wie gefilterte, indizierte Ansichten große Bibliotheken schnell halten.

Best Practices für Dokumentenbibliotheken

• Zunächst flach halten. Maximal eine oder zwei Ordnerebenen – und nur dort, wo sie etwas wirklich Strukturelles abbilden, etwa eine Sicherheitsgrenze.
• Spalten hinzufügen, die echte Fragen beantworten. Dokumenttyp, Verantwortlicher, Status, Kunde oder Projekt, Überprüfungsdatum. Fünf gut gewählte Spalten sind besser als zwanzig aspirationale.
• Verwaltete Metadaten für alles mit kontrolliertem Vokabular verwenden. Ein Begriffssatz für Abteilungen oder Dokumenttypen sorgt dafür, dass alle dieselben Begriffe eingeben – siehe Einführung in verwaltete Metadaten.
• Wichtige Spalten als Pflichtfelder definieren. Optionale Felder sind innerhalb eines Monats bei der Hälfte der Bibliothek leer.
• Ansichten statt Ordner erstellen. „Meine Dokumente", „Warten auf Genehmigung", „Läuft dieses Quartal ab" – jede Ansicht ist eine Ordnerstruktur, die keinerlei Pflege erfordert.
• Standardspaltenwerte pro Bibliothek festlegen, damit Metadaten beim Upload vergeben werden und nicht in einem späteren Bereinigungsprojekt.
• Nach Zweck trennen, nicht nach Größe. Separate Bibliotheken für Richtlinien, Verträge und Arbeitsdokumente lassen sich leichter sichern und aufbewahren als eine Bibliothek mit allem.
• Dateien einheitlich benennen. Auch mit guten Metadaten machen konsistente Namen Suchergebnisse übersichtlicher und Exporte lesbar.
• Vierteljährlich überprüfen. Ungenutzte Ansichten löschen, Spalten, die niemand ausfüllt, entfernen und prüfen, ob die Bibliothek noch zur Arbeitsweise des Teams passt. Microsofts Übersicht zum Organisieren von Dokumenten und Sites ist eine nützliche Checkliste dafür.

Abb. 4. Screenshot: Hinzufügen einer verwalteten Metadatenspalte.

Inhaltstypen: sinnvoll, aber nicht überall

Ein Inhaltstyp bündelt eine Vorlage, einen Spaltensatz, eine Aufbewahrungsrichtlinie und einen Workflow zu einer wiederverwendbaren Definition – „Rechnung", „Leistungsverzeichnis", „Richtliniendokument". Aus dem Inhaltstypkatalog veröffentlicht, überträgt er dieselbe Struktur auf jede Bibliothek, die ihn verwendet – genau das, was man für Inhalte mit einer formalen Form und einem Compliance-Verantwortlichen braucht.

Das ist auch mehr Aufwand, als die meisten Bibliotheken benötigen. Eine teamspezifische Ablage für laufende Arbeitsdokumente profitiert nicht von einem Inhaltstyp; eine Vertragsbibliothek mit Aufbewahrungspflicht absolut schon. Die praktische Regel: Inhaltstypen einführen, wenn derselbe Dokumenttyp in mehr als einer Bibliothek auftaucht und Regeln daran hängen. Bis dahin erfüllen Site-Spalten und Bibliotheksstandards den Zweck mit deutlich weniger Aufwand.

Suche und Auffindbarkeit

Die Suche in Microsoft 365 funktioniert gut, wenn sie etwas zum Arbeiten hat – ein weiteres Argument für Metadaten. Verwaltete Eigenschaften, die aus den eigenen Spalten abgeleitet werden, ermöglichen es, Ergebnisse nach Abteilung, Dokumenttyp oder Status zu filtern statt zu scrollen. Ein Begriffssatz gibt der Suche konsistentes Vokabular zum Abgleichen, und Pflichtfelder sorgen dafür, dass Filter tatsächlich befüllt sind.

Drei Maßnahmen bringen den größten Effekt. Die Spalten indizieren, nach denen am häufigsten gefiltert und sortiert wird – besonders in großen Bibliotheken. Aussagekräftige Dateinamen und Dokumenttitel verwenden, da beide in die Relevanzgewichtung einfließen. Und prüfen, was die häufigsten Suchanfragen tatsächlich liefern – wenn „Spesenrichtlinie" die Spesenrichtlinie nicht unter den ersten drei Ergebnissen anzeigt, liegt das Problem meist an einem fehlenden Titel, einem fehlenden Spaltenwert oder einer Seite, die hätte hervorgehoben werden sollen, und nicht an der Suchkonfiguration.

Dokumentenmanagement: Versionierung, Genehmigung und Lebenszyklus

Wenn Inhalte auffindbar sind, stellt sich die nächste Frage: Kann man ihnen vertrauen? Ist das die aktuelle Version, wer hat sie freigegeben, und wie lange muss sie aufbewahrt werden? Das ist Dokumentenmanagement – und SharePoint bietet die nötigen Funktionen. Sie müssen nur bewusst aktiviert werden.

Versionierung, die tatsächlich genutzt wird

Die Versionierung ist in modernen Bibliotheken standardmäßig aktiviert, aber die Standardeinstellungen sind für wichtige Bibliotheken selten die richtigen.

• Haupt- und Nebenversionen verwenden, wo Inhalte veröffentlicht werden. Nebenversionen (0.1, 0.2) bleiben für Redakteure sichtbar; Hauptversionen (1.0, 2.0) sehen die Leser.
• Die Versionsanzahl begrenzen. Unbegrenzte Versionen großer Dateien erzeugen Speicherkosten, die niemand eingeplant hat. Ein Limit von 100 Hauptversionen mit einigen wenigen Nebenentwürfen ist für die meisten Bibliotheken großzügig.
• Inhaltsgenehmigung aktivieren, wo die Veröffentlichung ein formaler Akt ist – Richtlinien, kundenseitige Dokumente, alles mit einem Compliance-Verantwortlichen.
• Check-out nur verwenden, wo es wirklich notwendig ist. Co-Authoring ist für die meisten Arbeitsdokumente besser; erzwungenes Check-out erzeugt das klassische Problem „gesperrt von jemandem im Urlaub".
• Pro Bibliothek konfigurieren, nicht mandantenweit – und die Entscheidung dokumentieren. Microsofts Anleitung zum Aktivieren und Konfigurieren der Versionierung erläutert die Einstellungen.

Jedem Dokument ein Enddatum geben

Der Grund, warum Bibliotheken unbrauchbar werden, ist nicht, dass Inhalte hinzugefügt werden. Es ist, dass niemand jemals etwas entfernt. Ein Lebenszyklus verwandelt das von einem gelegentlichen Bereinigungsprojekt in einen routinemäßigen Vorgang.

Abb. 5. Der Inhaltslebenszyklus, den jede Bibliothek braucht – von der Erstellung bis zur Entsorgung.

• Aufbewahrungsbezeichnungen anwenden, damit Dokumente für den vorgeschriebenen Zeitraum aufbewahrt und danach überprüft werden – Erstellen von Aufbewahrungsbezeichnungen führt durch die Einrichtung.
• Eine Spalte für das Überprüfungsdatum anlegen und eine Ansicht erstellen, die alles anzeigt, was überfällig ist. Ein namentlicher Verantwortlicher plus eine sichtbare Liste ist wirksamer als ein jährliches Audit.
• Abgeschlossene Projektsites archivieren, statt sie live zu lassen. Schreibgeschützter Inhalt, der durchsuchbar bleibt, ist besser als Inhalt, der still vor sich hin veraltet.
• Entscheiden, wer für die Entsorgung zuständig ist, bevor es so weit ist. „Legal wird es uns sagen" ist kein Prozess.

Abb. 6. Screenshot: Der Versionsverlauf-Bereich mit den Versionen eines Dokuments.

Berechtigungen und externes Teilen: Least Privilege als Standard

Berechtigungen sind der Ort, an dem gute Absichten scheitern. Jemand braucht dringend Zugang, die schnellste Lösung ist eine eindeutige Berechtigung auf eine einzelne Datei – und drei Jahre später kann niemand mehr erklären, wer was sehen kann. Die Best Practice ist nicht Strenge, sondern Konsistenz und Nachvollziehbarkeit.

Abb. 7. Die vier Berechtigungsebenen und wie weit der Zugriff auf jeder Ebene sein sollte.

Best Practices für Berechtigungen

• Zugriff an Gruppen vergeben, nie an Einzelpersonen. Die Gruppen Eigentümer, Mitglieder und Besucher der Site verwenden, unterstützt durch Microsoft 365-Gruppen oder Sicherheitsgruppen, die von HR-Prozessen bereits gepflegt werden.
• Die Vererbung so weit wie möglich intakt lassen. Jede gebrochene Vererbung ist ein Punkt, der bei einer Zugriffsüberprüfung gesondert geprüft werden muss.
• Wenn die Vererbung gebrochen wird, den Grund dokumentieren und ein Überprüfungsdatum setzen. Eine undokumentierte Ausnahme wird dauerhaft.
• Full Control auf zwei oder drei namentliche Eigentümer pro Site begrenzen und sicherstellen, dass mindestens zwei Personen diese Berechtigung haben, damit die Site nie verwaist.
• Eindeutige Berechtigungen auf Elementebene niemals als Routinewerkzeug einsetzen. Wenn eine einzelne Datei in einer Bibliothek anderen Zugriff benötigt, gehört sie in der Regel in eine andere Bibliothek.
• Zugriff nach einem festen Zeitplan und nach jeder Umstrukturierung überprüfen. Zugriffsüberprüfungen decken Berechtigungen auf, die das Projekt überlebt haben.
• Verstehen, was die moderne Oberfläche tatsächlich gewährt. Freigabelinks, „Alle"-Links und direkter Zugriff verhalten sich unterschiedlich – Microsofts Übersicht zu Freigabe und Berechtigungen ist die Referenz dafür.

Berechtigungen sind eine Schicht in einem größeren Bild, das auch Verschlüsselung, bedingten Zugriff, Verhinderung von Datenverlust und Auditprotokollierung umfasst. Unser SharePoint-Sicherheitsleitfaden deckt den gesamten Stack ab, und der Microsoft 365 Community-Artikel zu SharePoint Online-Sicherheit als Teamaufgabe ist ein überzeugendes Argument dafür, warum das nicht die Aufgabe eines einzelnen Administrators sein kann.

Zwei spezifische Fehler sind so häufig, dass sie gesondert genannt werden sollten. Erstens: Personen zur Eigentümergruppe der Site hinzufügen, um ein Problem zu lösen, für das nur die Berechtigung „Bearbeiten" nötig gewesen wäre – Full Control erlaubt es, Berechtigungen zu ändern, die Site zu löschen und die Vererbung an beliebiger Stelle zu unterbrechen. Zweitens: Zugriff für „Alle außer externen Benutzern" als Abkürzung vergeben. Das funktioniert, ist in den meisten Überprüfungen unsichtbar – und bedeutet, dass der Inhalt für jeden Mitarbeitenden der Organisation verfügbar ist, was fast nie beabsichtigt war.

Best Practices für externes Teilen

Externes Teilen ist eine Geschäftsanforderung, kein zu eliminierendes Risiko. Das Ziel ist, den sicheren Weg zum einfachen Weg zu machen. Unser vollständiger Leitfaden zum externen Teilen in SharePoint behandelt die Einstellungen im Detail; die folgenden Praktiken sind die, die überall gelten sollten.

• Die Richtlinie auf Mandantenebene auf die restriktivste Option setzen, die noch funktionales Arbeiten erlaubt, und sie dann site-weise lockern. Eine Site-Einstellung kann nie freizügiger sein als die des Mandanten – siehe die Übersicht zum externen Teilen.
• „Bestimmte Personen"-Links gegenüber „Jeder mit dem Link" bevorzugen. Sie erfordern eine Anmeldung und sind einer Person zuordenbar.
• Standardmäßig Ablaufdaten für Gastlinks festlegen – kürzere für Sites mit sensiblen Inhalten.
• Eine Domänen-Positivliste für regulierte Arbeit verwenden, damit Dateien nur mit Partnern geteilt werden können, mit denen Vereinbarungen bestehen.
• Den Standard-Linktyp ändern. Wenn der Standard „Jeder" ist, ändern ihn die meisten Nutzer nie; wenn der Standard „Bestimmte Personen" ist, müssen die meisten ihn nie ändern.
• Inhalte mit Vertraulichkeitsbezeichnungen klassifizieren, damit der Schutz mit der Datei reist statt davon abzuhängen, wo sie gespeichert ist.
• Gastzugang vierteljährlich überprüfen und Gäste entfernen, deren Projekt abgeschlossen ist. Sonst tut es niemand.

Abb. 8. Screenshot: Einstellungen für externes Teilen im SharePoint Admin Center.

Governance, Benennung und Lebenszyklus: Regeln schriftlich festhalten

Governance klingt nach Bürokratie – bis zum ersten Mal jemand fragt, wer eine Site namens „Projekt Falcon (neu) FINAL" genehmigt hat. Ein Governance-Plan ist schlicht die Sammlung bereits getroffener Entscheidungen, an einem Ort, den Menschen finden können. Microsofts SharePoint-Governance-Übersicht beschreibt den vollen Umfang; in der Praxis brauchen die meisten Organisationen Antworten auf sechs Fragen.

Die sechs Fragen, die ein Governance-Plan beantwortet

1. Wer darf eine Site erstellen, und wie? Entweder Self-Service mit einer Vorlage und einer Benennungsregel oder ein Antragsformular, das an ein kleines Team weitergeleitet wird. Unkontrollierte Erstellung ist der Weg zu einem Mandanten mit 900 Sites und 40 aktiven.
2. Wie heißt alles? Eine Benennungskonvention für Sites, Bibliotheken, Spalten und Dateien, die einheitlich angewendet wird.
3. Wer besitzt jede Site? Ein namentlich genannter Eigentümer und ein Stellvertreter, an einem Ort außerhalb der Site selbst gespeichert, mit einem Prozess für den Fall, dass sie das Unternehmen verlassen.
4. Was sind die Standardeinstellungen? Versionierung, Freigabe, Aufbewahrung und Berechtigungen für eine neue Site – idealerweise automatisch über eine Site-Vorlage angewendet.
5. Wie lange leben Inhalte? Aufbewahrungsfristen nach Inhaltstyp – und wer prüft sie.
6. Wann wird das hier überprüft? Ein Governance-Dokument ohne Überprüfungsdatum ist innerhalb von achtzehn Monaten ein historisches Artefakt.

Benennungskonventionen, die im Alltag funktionieren

Eine Benennungskonvention scheitert, wenn sie lang, mehrdeutig oder schwer zu merken ist. Die funktionierenden haben eine feste Reihenfolge, ein festes Trennzeichen und höchstens vier oder fünf Komponenten.

Abb. 9. Der Aufbau einer Benennungskonvention, der ohne Spickzettel funktioniert.

• Datum in ISO-Reihenfolge angeben (2026-03-14), damit Namen automatisch chronologisch sortieren.
• Leerzeichen und Sonderzeichen vermeiden – sie werden in URLs zu %20 und Schlimmerem.
• Versionsnummern aus Dateinamen streichen, sobald die Bibliotheksversionierung aktiv ist. „v2_final_FINAL2" ist ein Symptom, kein Standard.
• Site-Namen kurz halten. Sie landen in jeder URL, jedem Link und jedem Navigationsmenü.
• Die Konvention im Intranet veröffentlichen – mit drei konkreten Beispielen. Niemand liest eine Regel; alle kopieren ein Beispiel.

Governance-Rollen, die namentlich besetzt sein sollten

Governance scheitert am häufigsten daran, dass sie niemandem gehört. Drei Rollen decken das meiste ab. Ein Plattformverantwortlicher – meist in der IT – verantwortet Mandanteneinstellungen, den Site-Provisionierungsprozess und den Sicherheitsbaseline. Ein Site-Eigentümer verantwortet Inhalt, Berechtigungen und Lebenszyklus einer Site und ist in der Site selbst namentlich genannt, damit Nutzer wissen, wen sie fragen können. Ein Business-Sponsor verantwortet die nicht-technischen Entscheidungen: Was wird aufbewahrt, was wird extern geteilt, und was passiert, wenn zwei Abteilungen dasselbe unterschiedlich gebaut haben wollen?

In kleinen Organisationen kann eine Person alle drei Rollen übernehmen – solange die Aufteilung schriftlich festgehalten ist. Was nicht funktioniert: ein Governance-Dokument, das dem „SharePoint-Team" gehört, wenn das SharePoint-Team ein gemeinsames Postfach ist.

Häufige Governance-Fehler

• Eine vierzigseitige Richtlinie schreiben, die niemand liest. Eine zweiseitige Seite im Intranet mit konkreten Beispielen verändert mehr Verhalten.
• Site-Erstellung vollständig sperren. Wenn der offizielle Weg drei Wochen dauert, weichen die Leute auf Teams, OneDrive oder persönliche Tools aus – und die Sichtbarkeit geht verloren, statt Kontrolle zu gewinnen.
• Die Plattform regeln, aber nicht den Inhalt. Regeln zur Site-Provisionierung sind die einfache Hälfte; Aufbewahrung, Eigentümerschaft und Überprüfungsdaten sind die Hälfte, die die Umgebung nutzbar hält.
• Governance als Einführungsaktivität behandeln. Es ist eine Wartungsaktivität mit einer Einführungskomponente.

Adoption und Schulung: Die Praxis, die alles andere stabilisiert

Eine gut strukturierte SharePoint-Umgebung, die niemand nutzt, ist weniger wert als eine chaotische, die genutzt wird. Adoption ist keine Kommunikationsmaßnahme am Projektende – sie ist eine Designanforderung von Beginn an.

Abb. 10. Ein vierphasiger Rollout: Pilot, Champions, abteilungsweiser Rollout, dann Verstärkung.

Best Practices für die Adoption

• Mit einem Team und einem echten Workflow beginnen. Ein Pilot, der ein echtes Ärgernis löst, erzeugt Fürsprecher; eine Demo-Umgebung erzeugt Meinungen.
• Champions pro Abteilung gewinnen und zuerst schulen. Menschen fragen eher den Kollegen zwei Schreibtische weiter, als ein Ticket zu öffnen.
• Inhalte migrieren, bevor der Wechsel erwartet wird. Eine leere Site ist ein Grund, zum alten Laufwerk zurückzukehren.
• Nach Rolle schulen, nicht nach Funktion. „Wie das Vertriebsteam ein Angebot ablegt" funktioniert; „Einführung in Inhaltstypen" nicht.
• Einen Termin zum Abschalten des alten Systems setzen – und einhalten. Parallelbetrieb ist der zuverlässigste Weg, ein Adoptionsprogramm scheitern zu lassen.
• Nutzung messen, nicht Deployment. SharePoint und Microsoft 365-Nutzungsberichte zeigen, welche Sites tatsächlich genutzt werden – Microsofts Leitfaden zu Schulung und Change Management erklärt, wie das Programm darauf aufgebaut wird.
• Den Nutzenden etwas geben, was sie vorher nicht konnten. Ein Live-Projektmanagement-Dashboard, ein gemeinsamer Teamkalender, ein Formular, das einen E-Mail-Thread ersetzt – sichtbare Vorteile amortisieren viel Change-Fatigue.

Praktische Bausteine helfen dabei ebenfalls: SharePoint Web Parts für das Zusammenstellen von Seiten, SharePoint Forms zum Ersetzen E-Mail-basierter Datenerfassung und Gemeinsame Kalender für SharePoint Online für Planungsprobleme, die Tabellen schlecht lösen.

Es hilft auch, ehrlich zu sein, was sich für jeden einzelnen verändert. Die meisten Nutzer interessieren sich nicht für Informationsarchitektur; sie interessieren sich dafür, ob die Aufgabe, die sie fünfzehnmal täglich erledigen, schneller oder langsamer geworden ist. Wenn eine neue Struktur zwei zusätzliche Klicks für die häufigste Aufgabe erfordert, hilft keine Schulung – dann muss die Struktur geändert werden. Adoptionsprobleme sind häufig Designprobleme in anderem Gewand.

Häufige SharePoint-Fehler und wie man sie vermeidet

Die meisten Umgebungen, die saniert werden müssen, zeigen dieselbe Handvoll Muster. Wer mehrere davon erkennt, sollte die oben genannten Maßnahmen in der angegebenen Reihenfolge priorisieren.

• Das Laufwerk neu erstellen. Einen Ordnerbaum unverändert zu migrieren verlagert das Problem an einen teureren Ort. Migration ist der Moment, in dem Umstrukturierung günstig ist – ihn nutzen.
• Eine riesige Site für alles. Das konzentriert Berechtigungen, Speicher und Lebenszyklus-Entscheidungen in einem einzelnen Objekt, das niemand sicher ändern kann.
• In Eile vergebene und nie überprüfte Berechtigungen. Jede dringende Ausnahme sollte mit einem Überprüfungsdatum angelegt werden – sonst wird sie standardmäßig dauerhaft.
• Metadatenspalten, die niemand ausfüllt. Optionale Felder verfallen. Die wichtigen als Pflichtfelder setzen, Standardwerte festlegen und Spalten löschen, die sich als unnötig herausgestellt haben.
• Unbegrenzte Versionierung in großen Bibliotheken. Der Speicher wächst still – bis er es nicht mehr tut, und die Bereinigung ist weit aufwändiger als die ursprüngliche Einstellung.
• Keine Site-Eigentümer. Wenn die Person, die die Site aufgebaut hat, das Unternehmen verlässt, wird eine Site ohne Eigentümer zu Inhalt, den niemand anfasst und niemand löscht.
• Rollout an die gesamte Organisation auf einmal. Ohne Pilot erfährt man von den Designproblemen durch dreihundert Personen gleichzeitig.
• Nichts jemals außer Betrieb nehmen. Abgeschlossene Projektsites zu archivieren und tote Bibliotheken zu schließen ist das, was Suchergebnisse zwei Jahre später noch relevant hält.

Wie Virto SharePoint Best Practices unterstützt

Einige der oben genannten Praktiken sind leicht zu formulieren, aber mit reinen Out-of-the-Box-Funktionen mühsam umzusetzen – konsolidierte Planung, sichtbarer Arbeitsfortschritt, Benachrichtigungen nach eigenen Regeln statt Microsofts Standardeinstellungen und Massenoperationen auf Bibliotheken, die auf mehrere hundert Dateien angewachsen sind. Virto-Apps für SharePoint schließen diese Lücken ohne individuelle Entwicklung.

• Virto Calendar App überlagert SharePoint-Listen, Exchange- und Microsoft 365-Kalender in einer einzigen farbcodierten Ansicht, sodass Teams aufhören, eine parallele Planungstabelle zu pflegen.
• Virto Kanban Board App verwandelt eine SharePoint-Liste in ein Board mit Swimlanes, Filtern und Work-in-Progress-Limits – eine unkomplizierte Möglichkeit, aus einer Aufgabenliste etwas zu machen, das Menschen tatsächlich betrachten.
• Virto Alerts and Reminders App sendet bedingte, geplante Benachrichtigungen auf Basis von Listen- und Bibliotheksdaten – das ist es, was Überprüfungsdaten und Genehmigungsschritte in der Praxis funktionierend macht.
• Virto Form Designer erstellt strukturierte Formulare mit Validierung und bedingter Logik, sodass Metadaten korrekt am Erfassungspunkt eingegeben werden statt später bereinigt werden zu müssen.
• Virto Multiple File Operations ermöglicht Massen-Upload, Kopieren, Verschieben und Metadatenzuweisung über Bibliotheken hinweg – das Werkzeug, das man bei einer Migration oder einer Ordner-zu-Metadaten-Bereinigung braucht.
• Virto Workflow Automation erweitert die Automatisierung für lokale SharePoint-Umgebungen, in denen Power Automate nicht verfügbar ist.

Alle Virto-Apps laufen innerhalb des eigenen Microsoft 365-Mandanten und folgen dem Sicherheitsmodell von Microsoft – Details dazu im Virto Trust and Security Center. Jedes Produkt ist mit einer vollständig nutzbaren 30-tägigen kostenlosen Testversion verfügbar, ohne Kreditkarte. Die Apps sind auch gebündelt im Virto M365 Productivity Kit erhältlich. Die nutzerbezogenen Preise beginnen bei 2 $ pro Nutzer und Monat im Starter-Plan (bis zu 30 Nutzer) und 3 $ pro Nutzer und Monat im Pro-Plan (31–200 Nutzer), mit Enterprise-Preisen auf Anfrage; aktuelle Details sind auf der Preisseite zu finden. Den vollständigen Katalog gibt es unter Virto-Apps für Microsoft 365 und SharePoint Online.

Abb. 11. Screenshot: Virto Kanban Board App zeigt eine SharePoint-Aufgabenliste als Board.

Abb. 12. Screenshot: Virto Calendar App überlagert mehrere SharePoint- und Exchange-Kalender.

SharePoint Best Practices – FAQ

Was sind SharePoint Best Practices?

Eine flache Struktur mit Hub Sites aufrechterhalten, Metadaten statt tiefer Ordner verwenden, Least-Privilege-Berechtigungen anwenden, Governance- und Benennungsstandards festlegen und die Nutzer-Adoption planen.

Was ist die beste Strukturierungsweise für SharePoint?

Eine Site pro Team, Projekt oder Abteilung auf oberster Ebene erstellen und verwandte Sites über eine Hub Site verbinden, statt sie als Subsites zu verschachteln. Flache Strukturen lassen sich einfacher sichern, überstehen Umstrukturierungen ohne defekte URLs und ermöglichen es jeder Site, eigene Berechtigungen, Speicher und Lebenszyklus zu verwalten.

Ordner oder Metadaten in SharePoint?

Metadaten und Ansichten sind tiefen Ordnerbäumen vorzuziehen – sie skalieren besser und vermeiden das 5.000-Element-Problem sowie lange URLs. Eine flache Ordnerebene ist vertretbar, wenn sie eine echte Grenze abbildet, aber Fragen an ein Dokument (Typ, Eigentümer, Status, Kunde, Ablauf) gehören in Spalten, nicht in einen Pfad.

Wie viele SharePoint-Sites sollten wir haben?

So viele, wie es eigenständige Aufgabenbereiche mit eigenständigen Zielgruppen und Berechtigungen gibt – und nicht mehr. Eine Site pro aktivem Projekt oder Team ist normal; eine Site pro Person, pro Jahr oder pro Dokumenttyp ist es in der Regel nicht. Sites archivieren, wenn die Arbeit, die sie unterstützt haben, abgeschlossen ist.

Was sind Best Practices für SharePoint-Berechtigungen?

Berechtigungen an Gruppen statt an Einzelpersonen vergeben, die integrierten Gruppen Eigentümer, Mitglieder und Besucher verwenden, die Vererbung so weit wie möglich intakt lassen, Full Control auf zwei oder drei namentliche Eigentümer pro Site begrenzen und eindeutige Berechtigungen auf Elementebene als dokumentierte Ausnahme mit Überprüfungsdatum behandeln.

Wie oft sollte Governance überprüft werden?

Mindestens einmal jährlich sowie nach jeder wesentlichen Umstrukturierung, Migration oder Änderung der Microsoft 365-Lizenzierung. Zugriffsüberprüfungen sollten häufiger stattfinden – vierteljährlich für Sites mit sensiblen oder extern geteilten Inhalten.

Gelten diese Best Practices auch für SharePoint On-Premises?

Die meisten schon. Metadaten, Versionierung, Least Privilege, Benennung und Adoption gelten für jede Version. Hub Sites und Vertraulichkeitsbezeichnungen sind Microsoft 365-Funktionen; lokale Umgebungen bilden diese Beziehungen stattdessen über Navigation und Site-Collection-Design ab.

Wo anfangen

Es braucht kein großes Programm, um anzufangen. Die Bibliothek auswählen, die das Team am häufigsten nutzt, drei Metadatenspalten und zwei Ansichten hinzufügen – und beobachten, ob jemand zu den Ordnern zurückkehrt. Dann prüfen, wer auf dieser Site Full Control hat, und alle entfernen, die es nicht benötigen. Diese zwei Änderungen dauern einen Nachmittag und zeigen den Wert des Rests.

Wenn der Rollout ausgeweitet werden soll, die Säulen in der Reihenfolge abarbeiten – Struktur, dann Metadaten, dann Berechtigungen, dann Governance, dann Adoption – und die dedizierten Guides für die Bereiche nutzen, die vertiefende Informationen erfordern: SharePoint Hub Sites, Dokumentenbibliotheken, Dokumentenmanagement, externes Teilen und SharePoint-Sicherheit.