SharePoint-Hub-Sites – Architektur, Governance, Betrieb und Praxis

1. Management Summary

Die SharePoint-Hub-Site (kurz: Hub) ist ein zentrales Element in Microsoft 365, um zusammengehörige Sites thematisch, funktional oder organisatorisch zu bündeln. Durch die Hub-Funktionalität erhalten alle zugeordneten Team- und Kommunikationssites beispielsweise eine einheitliche Hauptnavigation und ein konsistentes Design; zudem können News und andere Inhalte bereichsübergreifend aggregiert dargestellt werden. Dies erleichtert den Mitarbeitern das Auffinden von Informationen und schafft ein konsistentes Benutzererlebnis über Abteilungs- und Standortgrenzen hinweg. Gleichzeitig bringt die Einführung von Hubs besondere Anforderungen an die Architekturplanung und Governance mit sich. Ohne klare Struktur und definierte Zuständigkeiten können Hub-Strukturen unübersichtlich werden oder Sicherheitsrisiken bergen. Dieser Leitfaden zeigt praxisnah, wie SharePoint-Hubs effektiv geplant, betrieben und kontinuierlich verbessert werden können. Zu den Erfolgsfaktoren zählen eine wohlüberlegte Hub-Architektur (z.B. nach Themen oder Regionen), eine konsistente Navigations- und Suchstrategie sowie eindeutig definierte Rollen für Eigentümer, Redaktion, IT-Betrieb und Compliance. Typische Stolperfallen – etwa die Annahme, dass Hubs Berechtigungen automatisch vereinheitlichen, oder eine unkontrollierte Flut an Inhalten ohne regelmäßige Überprüfung – lassen sich durch klare Governance-Regeln und Schulungen vermeiden. Als erste Schritte haben sich Pilotprojekte bewährt. In einem begrenzten Bereich (z.B. einer Abteilung) wird ein Hub mit wenigen ausgewählten Sites aufgebaut, um Erfahrungen zu sammeln und Feinheiten der Hub-Nutzung zu erproben. Dabei sollte frühzeitig die IT- und Compliance-Abteilung eingebunden werden, um Richtlinien (etwa für Berechtigungen, Sensitivity Labels (Empfindlichkeitsbezeichnungen) und Aufbewahrungsfristen) festzulegen. Auf Basis dieser Pilot-Erkenntnisse kann die Hub-Landschaft schrittweise und kontrolliert ausgebaut werden – mit dem Ziel, ein flexibles und dennoch regelkonformes Intranet-Ökosystem zu schaffen.

2. Grundlagen & Begriffe

Eine SharePoint-Hub-Site (kurz Hub) ist eine moderne SharePoint-Website, die vom Administrator als zentraler Hub registriert wird, um mehrere eigenständige Websites logisch zu verbinden. Im Gegensatz zu einer einzelnen Team-Site oder Kommunikationssite steht bei einer Hub-Site weniger der Inhalt selbst im Vordergrund, sondern die verbindende Struktur: Sie fungiert als Dreh- und Angelpunkt für Navigation, Suche, News und Design für alle ihr zugeordneten Sites. Wichtig zu unterscheiden sind dabei die Basistypen von Sites: Eine Team-Site ist in der Regel für die teaminterne Zusammenarbeit konzipiert (oft mit Microsoft 365-Gruppe und eingeschränktem Teilnehmerkreis), während eine Kommunikationssite primär der bereichsweiten Information und Veröffentlichung von Inhalten dient (meist für ein größeres Publikum mit Lesezugriff). Eine Hub-Site kann theoretisch beide Arten aufnehmen – häufig werden jedoch Kommunikationssites als Hubs verwendet, da sie sich gut als zentrale Einstiegsseiten eignen.

Alle Websites, die einem Hub zugeordnet sind, bilden zusammen eine Hub-Familie. Die Hub-Site selbst ist dabei der „Knotenpunkt“ dieser Familie. Sobald eine Site einem Hub beitritt (durch Zuordnung via Hubsite association), erhält sie automatisch das Design (Farbschema, Theme) und die Hauptnavigation des Hubs. Inhalte wie News oder Aktualisierungen aus den zugeordneten Sites können auf der Hub-Startseite gesammelt angezeigt werden (z.B. mittels News-Webparts). Außerdem erstreckt sich der Standard-Suchumfang auf den gesamten Hub-Bereich: Sucht ein Benutzer innerhalb einer Hub-Site, erhält er Ergebnisse aus allen zugehörigen Sites (sofern er dort entsprechende Zugriffsrechte besitzt). Benutzer können die Suche bei Bedarf immer noch auf „Gesamte Organisation“ erweitern, aber der Hub bietet eine fokussierte Suche im Kontext des Themas oder Bereichs.

Der Begriff Parent-Hub bezeichnet eine Hierarchieerweiterung: Microsoft 365 ermöglicht es, einen Hub mit einem anderen Hub zu verknüpfen. Dabei wird ein Hub als übergeordneter Parent eines oder mehrerer anderer Hubs festgelegt, um ein Netzwerk von Hubs zu schaffen. Das Hauptziel dieser Parent-Child-Verknüpfung ist es, Suchergebnisse über mehrere Hubs hinweg zu verbinden und eine erweiterte Inhaltsfindung zu ermöglichen. Praktisch bedeutet dies, dass Inhalte eines Hub-Verbunds (bis zu drei Ebenen tief) gegenseitig auffindbar sind, wenn ein Benutzer in einem der verbundenen Hubs eine Suche ausführt. Wichtig: Diese Verknüpfung ändert nichts an der visuellen Darstellung oder Navigation, außer dass optional manuell Querverweise zwischen den Hubs in der Navigation eingefügt werden können. Es gibt auch keine automatische Vererbung von Designs oder Logos über mehrere Hub-Ebenen hinweg – jeder Hub behält sein eigenes Erscheinungsbild. Die Hub-Familien bleiben in der Benutzeroberfläche separat, sind aber im Hintergrund suchtechnisch verknüpft. Grenzen dieser Hierarchie: Ein Hub kann maximal eine Ebene über sich (einen Parent) und mehrere darunter (Children) haben, wobei die Suchverknüpfung bis zur dritten Ebene funktioniert. Jede einzelne Site kann stets nur Mitglied eines Hubs sein; Mehrfachzuordnungen sind nicht möglich.

Zur Abrundung der Grundlagen hier ein kurzer Überblick über die zentralen Eigenschaften von Hubs in SharePoint Online:
– Navigation: Der Hub stellt eine übergeordnete Navigationsleiste bereit, die auf jeder zugeordneten Site oben angezeigt wird. Diese Hub-Navigation kann bis zu drei Ebenen tief verschachtelt werden und wird vom Hub-Eigentümer gepflegt. Dadurch entsteht ein konsistentes Navigationsgerüst über alle verbundenen Sites hinweg.
– Suche: Der integrierte Suchbereich einer Hub-Site umfasst standardmäßig alle Sites der Hub-Familie. Benutzer können innerhalb dieses Bereichs gezielt suchen, was besonders bei thematisch abgegrenzten Hubs (z.B. „HR-Hub“ für alle Personalthemen) die Auffindbarkeit steigert. Es besteht weiterhin die Möglichkeit, die Suche auf die gesamte Organisation auszuweiten, aber der Hub-Kontext liefert relevantere Ergebnisse im thematischen Umfeld.
– News-Rollup: Hub-Sites ermöglichen ein zentrales News-Handling. Nachrichten, die auf einer der verbundenen Sites erstellt werden, können automatisch auf der Hub-Seite angezeigt werden (z.B. in einem „News aus diesem Hub“-Webpart). Dadurch werden wichtige Mitteilungen bereichsübergreifend verteilt, ohne dass Inhalte doppelt erstellt werden müssen. Der Hub fungiert als Aggregator für Neuigkeiten und Ankündigungen.
– Branding: Um ein einheitliches Look-and-Feel sicherzustellen, erbt jede zugeordnete Site das Design des Hubs. Dazu zählen das Farbthema, Schriften und ggf. das Hub-Logo in der Navigationsleiste. So erkennen Benutzer sofort die Zusammengehörigkeit der Sites zum Hub. (Hinweis: Das Logosymbol der einzelnen Site kann weiterhin individuell sein, aber das Hub-Logo erscheint in der Leiste.)
– Berechtigungen: Eine Hub-Site ändert nicht automatisch die Berechtigungsstruktur ihrer zugeordneten Sites. Jede Site behält grundsätzlich ihre individuellen SharePoint-Berechtigungen. Inhalte, die ein Nutzer mangels Rechte nicht sehen darf, bleiben auch im Hub-Kontext verborgen (Security Trimming greift für Navigation, News und Suche). Allerdings gibt es die Möglichkeit einer Hub-Berechtigungssynchronisation für Besucher: Der Hub-Eigentümer kann eine oder mehrere Gruppen (bis zu 10 Einträge) als Besucher des Hubs definieren und diese Einstellung mit allen zugehörigen Sites synchronisieren. So lässt sich z.B. eine unternehmensweite Leseberechtigung für sämtliche Sites eines Hubs realisieren. Diese Synchronisation erfolgt aber nur auf explizite Aktion hin und betrifft standardmäßig nur das Besucherniveau (Lesezugriff). Darüber hinausgehende Berechtigungen (Mitglieder, Eigentümer) werden nicht über den Hub verteilt. Entsprechend bleibt die sorgfältige Pflege der Berechtigungen auf Site-Ebene weiterhin essenziell.

In Summe bildet ein Hub also einen losen Verbund von Sites, der durch gemeinsame Navigation, Suche, Neuigkeiten und Gestaltung verbunden ist, ohne die Autonomie der Einzelsites (z.B. in Bezug auf Inhalte und Zugriffsrechte) völlig aufzuheben. Diese Grundlagen bilden das Fundament, auf dem die weitere Planung der Hub-Architektur, Governance-Regeln und Betriebsprozesse aufsetzen.

3. Architektur & Topologie

Bei der Planung der Hub-Architektur stellt sich zunächst die Frage, nach welchen Kriterien Hubs gebildet werden sollen. Bewährt haben sich hierbei mehrere Ansätze:
– Thematische Hubs: Hier werden Hub-Sites nach unternehmensweiten Themen oder Prozessen ausgerichtet. Beispielsweise könnte es einen Hub für Qualitätsmanagement, einen für IT & Digitalisierung und einen für Arbeitssicherheit geben. Alle Inhalte und Sites, die zu einem Thema gehören – auch wenn sie verschiedenen Abteilungen angehören – werden unter dem entsprechenden Themen-Hub gesammelt.
– Funktionale/Abteilungs-Hubs: In diesem Modell bildet jede Hauptfunktion oder Abteilung des Unternehmens einen Hub. So könnte es Hubs für HR (Personal), Finanzen, Vertrieb, Produktion etc. geben. Innerhalb des HR-Hubs wären dann z.B. Sites für Personalentwicklung, Recruiting, Benefits usw. zugeordnet. Dieses Modell spiegelt direkt die Organisationsstruktur wider.
– Regionale Hubs: Bei international oder geografisch verteilten Unternehmen kann es sinnvoll sein, Hubs nach Regionen oder Ländern aufzusetzen. So könnte ein Europa-Hub, ein Nordamerika-Hub und ein Asien-Pazifik-Hub existieren, die jeweils die lokal relevanten Sites und Inhalte bündeln. Dieser Ansatz berücksichtigt unterschiedliche Sprachen, Zeitzonen oder lokale Compliance-Anforderungen.
– Hybride Ansätze: In der Praxis werden oft mehrere Kriterien kombiniert. Beispielsweise könnte ein Unternehmen funktionale Hubs haben (z.B. globale Hubs für HR, IT, Vertrieb) und darunter regionale Unter-Hubs für die länderspezifischen Inhalte in jeder Funktion. Wichtig ist, eine klare Linie zu definieren und diese konsistent umzusetzen, damit Nutzer die Hub-Struktur intuitiv nachvollziehen können.

Die Parent-Hub-Beziehungen kommen ins Spiel, wenn mehrere Hubs logisch zusammengehören und ein übergreifendes Dach benötigen. Ein Parent-Hub kann dann als obere Ebene dienen, unter der verwandte Hubs als „Kinder“ angesiedelt werden. Ein praktisches Beispiel: Ein Unternehmen hat getrennte Hubs für Vertrieb Europa und Vertrieb Nordamerika, da diese Regionen eigenständig operieren (z.B. mit eigenen Teams und unterschiedlichen Zeitzonen). Um dennoch einen konzernweiten Austausch im Vertrieb zu ermöglichen, könnte ein globaler Vertrieb-Parent-Hub eingerichtet werden, der die regionalen Vertriebshubs verbindet. Die Entscheidung für Parent-Hubs sollte jedoch gezielt getroffen werden: Sie sind dann sinnvoll, wenn Benutzer regelmäßig in mehreren Hubs nach Inhalten suchen müssen oder wenn eine thematische Klammer über separaten Hubs benötigt wird. Nicht sinnvoll wären Parent-Hubs, wenn die Hubs inhaltlich kaum Überschneidungen haben oder wenn die globale Navigation (z.B. über die SharePoint-App-Bar) bereits alle wichtigen Verbindungen liefert. Zu beachten ist auch, dass Parent-Child-Hub-Verknüpfungen die Navigation nicht automatisch verschmelzen – sie wirken vor allem im Hintergrund für die Suche. Der Pflegeaufwand steigt mit jeder zusätzlichen Hierarchieebene, da Änderungen an der Struktur manuell in die Navigation übernommen werden müssen.

Multi-Geo-Aspekte: In einem Multi-Geo-Tenant werden Daten in unterschiedlichen geographischen Regionen gespeichert (etwa um lokale Datenschutzvorgaben einzuhalten und die Latenz für Nutzer vor Ort zu reduzieren). Bei der Hub-Planung in einem Multi-Geo-Umfeld ist zu berücksichtigen, dass Sites idealerweise dem Hub in der jeweils gleichen Geo zugeordnet werden, um Performance und Datenresidenz zu optimieren. Beispielsweise könnte ein weltweit agierendes Unternehmen einen EMEA-Hub im europäischen Rechenzentrum haben, einen Americas-Hub in Nordamerika und einen APAC-Hub in Asien. Jeder Hub würde die Sites seiner Region enthalten, sodass Nutzer in Europa primär den EMEA-Hub nutzen, wo alle relevanten Inhalte in EU-Rechenzentren liegen. Wenn über Geo-Grenzen hinweg Inhalte gefunden werden sollen, lässt sich entweder die organisationsweite Suche verwenden oder – falls verfügbar – Parent-Hubs zur Verknüpfung einsetzen. Allerdings ist zu beachten, dass die SharePoint-Suche standardmäßig innerhalb der eigenen Geo priorisiert. News-Flows (der Austausch von Nachrichten) bleiben in der Regel regional begrenzt, es sei denn, man plant bewusst eine mehrsprachige, globale News-Übersicht (z.B. indem die zentralen Nachrichten des Headquarters in allen Hubs gespiegelt oder verlinkt werden). In Multi-Geo-Szenarien müssen ferner Compliance-Anforderungen pro Region (z.B. europäische DSGVO, US-amerikanische Archivierungsvorschriften) pro Hub berücksichtigt werden – hierzu mehr im Abschnitt Compliance.

Skalierung und technische Limits: Microsoft 365 erlaubt derzeit bis zu 2.000 Hubs pro Tenant. Praktisch nutzen selbst große Unternehmen meist eine deutlich geringere Zahl, da zu viele Hubs die Übersichtlichkeit für Anwender mindern würden. Auch die Anzahl der Sites, die einem Hub zugeordnet werden können, ist technisch nicht limitiert (abgesehen von der allgemeinen SharePoint Site-Obergrenze im Tenant, die in zehntausenden liegt). Allerdings sollte ein Hub thematisch fokussiert bleiben; Hunderte von wild zusammengewürfelten Sites in einem Hub würden die Vorteile (klare Navigation, überschaubarer Suchraum) konterkarieren. Pro Hub-Navigation sind drei Ebenen an Menüpunkten möglich – mehr Tiefe sollte auch aus Usability-Gründen vermieden werden. Die Tiefe von Hub-Verknüpfungen (Parent-Child) ist wie erwähnt auf 3 Ebenen beschränkt; Content jenseits der dritten Ebene wird in der Hub-übergreifenden Suche nicht mehr erfasst.

Flexibilität bietet die Hub-Architektur dadurch, dass Sites relativ leicht von einem Hub in einen anderen verschoben werden können (durch Ändern der Zuordnung im SharePoint Admin Center) – etwa bei Umorganisationen. Dies sollte jedoch sparsam genutzt werden, da jeder Wechsel Auswirkungen auf Navigation und Nutzergewohnheiten hat. Es empfiehlt sich, die Hub-Topologie zu dokumentieren und bei Änderungen sowohl administrativ als auch kommunikativ kontrolliert vorzugehen.

Nachfolgend ein vereinfachtes Musterdiagramm einer Hub-Landschaft, das eine Kombination aus einem übergeordneten Unternehmens-Hub und mehreren darunter organisierten Hubs zeigt:

Unternehmens-Hub (Level 1, Parent)
├── Finanzen-Hub (Level 2)
│   └── Finanz-Team-Site A
├── IT-Hub (Level 2)
│   ├── IT-Projekt-Site Alpha
│   └── IT-Projekt-Site Beta
└── Vertrieb-Hub (Level 2)
    ├── Vertrieb Europa-Hub (Level 3)
    │   ├── Sales-Team-Site DE
    │   └── Sales-Team-Site FR
    └── Vertrieb USA-Hub (Level 3)
        ├── Sales-Team-Site East
        └── Sales-Team-Site West

(Legende: Hubs sind in der Darstellung mit „-Hub“ benannt. Level 1 ist ein Parent-Hub ganz oben, Level 2 sind Hubs, die dem Parent untergeordnet sind, Level 3 sind weitere Hubs unterhalb eines Level-2-Hubs. Darunter sind beispielhaft zugeordnete Team-Sites aufgeführt.)

In diesem Beispiel dienen der Unternehmens-Hub als zentraler Einstiegspunkt und „Dach“ für alle Bereiche. Unterhalb sind funktionale Hubs wie Finanzen und IT angeordnet. Der Bereich Vertrieb ist weiter untergliedert in regionale Hubs für Europa und USA. Eine solche Struktur ermöglicht es, dass ein Mitarbeiter, der im Unternehmens-Hub sucht, Inhalte aus allen verbundenen Vertriebshubs findet, während jemand, der im Hub „Vertrieb Europa“ sucht, primär die europäischen Vertriebsinhalte durchsucht. Das Diagramm verdeutlicht, wie hierarchische Hubs eingesetzt werden können – in der Praxis muss jede Organisation die für sie passende Topologie finden, die sowohl einfach navigierbar als auch skalierbar für zukünftige Erweiterungen ist.

4. Informationsarchitektur & Navigation

Eine klar strukturierte Navigation ist entscheidend dafür, dass Nutzer sich im Hub zurechtfinden. Während die Hub-Topologie festlegt, welche Sites zusammengehören, definiert die Navigation den „roten Faden“ durch diese Inhalte. Folgende Grundsätze helfen beim Aufbau einer verständlichen Hub-Navigation:
– Maximale Tiefe begrenzen: Wie bereits erwähnt, unterstützt die Hub-Navigation bis zu drei Ebenen von Menüpunkten. In der Praxis sollten Menüs aber so flach wie möglich gehalten werden – ideal sind 1 bis 2 Navigationsebenen. Zu viele verschachtelte Unterpunkte überfordern Nutzer und werden auf kleineren Bildschirmen unübersichtlich.
– Klare, konsistente Bezeichnungen: Jeder Navigationspunkt sollte eindeutig und für die Zielgruppe verständlich benannt sein. Abkürzungen oder interne Begrifflichkeiten gilt es sparsam zu verwenden (oder bei erster Verwendung zu erläutern). Wenn mehrere Hubs im Unternehmen vorhanden sind, ist es sinnvoll, eine einheitliche Benennungslogik zu verfolgen – etwa dass Links zu Abteilungen immer im Singular stehen (z.B. „Personal“ statt „Personalabteilung“) oder Funktionsseiten einheitlich benannt sind.
– Konsistente Struktur über Hubs hinweg: Nutzer profitieren davon, wenn ähnliche Strukturen gleichartig navigierbar sind. Beispiel: Wenn sowohl der HR-Hub als auch der IT-Hub jeweils Unterbereiche für „Richtlinien“, „Projekte“ und „Teams“ haben, sollten diese Navigationspunkte ähnlich aufgebaut und platziert sein. Eine konsistente Informationsarchitektur erleichtert den Wechsel zwischen Hubs.
– Wichtige Inhalte zuerst: Platzieren Sie die wichtigsten oder meistgenutzten Links weit oben bzw. vorne in der Navigation. Seltener genutzte Seiten können weiter unten oder in Untermenüs erscheinen. Die Hub-Startseite selbst sollte in der Navigation klar hervorgehoben sein (in der Regel ist der Hub-Name bereits ein Link zur Startseite).
– Vermeidung von Redundanz: Jeder Navigationspunkt sollte eine eindeutige Funktion haben. Vermeiden Sie Dopplungen (z.B. zwei verschiedene Pfade, die zur gleichen Seite führen) – dies kann die Nutzer verwirren. Falls es inhaltliche Überschneidungen gibt, ist ggf. ein zentraler Seite besser, auf die von mehreren Stellen verlinkt wird.

Ein mächtiges Werkzeug zur Optimierung der Navigation ist das Audience Targeting (Zielgruppensteuerung) für Menüpunkte. Damit können bestimmte Navigationslinks nur für definierte Personenkreise sichtbar gemacht werden. In einem Hub kann dies z.B. eingesetzt werden, um interne Links zu sensiblen Projektsites vor externen Partnern zu verbergen, oder um jedem Mitarbeiter nur die für ihn relevanten Regionen anzuzeigen. Die Funktionsweise: Im Hub kann der Administrator die Zielgruppenansprache für die Navigation aktivieren und jedem Menüpunkt eine oder mehrere Microsoft Entra ID-Gruppen (früher Azure Active Directory, Azure AD) zuordnen. Nur Mitglieder dieser Gruppen sehen den entsprechenden Link. Bei Einsatz von Audience Targeting ist eine sorgfältige Pflege und regelmäßige Überprüfung nötig: Die hinterlegten Gruppenmitgliedschaften müssen aktuell gehalten werden, damit keine berechtigten Benutzer ausgeschlossen oder Unberechtigte eingeschlossen sind. Zudem sollte die Navigation aus Sicht verschiedener Zielgruppen getestet werden – idealerweise durch Testkonten oder Rückmeldungen von Endanwendern – um sicherzustellen, dass jeder die für ihn gedachte Navigation vorfindet.

Neben der primären Hub-Navigation (oben unter dem Suite-Bar) spielen auch andere Navigationselemente eine Rolle:
– Globale Navigation/App Bar: Seit der Einführung der SharePoint-App-Leiste (links als ausklappbares Menü) gibt es eine unternehmensweite globale Navigation, die typischerweise vom Intranet-Startpunkt (Home Site) gesteuert wird. Diese globale Navigation sollte mit den Hub-Strukturen abgestimmt sein. Beispielsweise kann die oberste Ebene der globalen Navigation die Haupt-Hubs des Unternehmens auflisten. So finden Nutzer schnell zum richtigen Hub. Die Hub-Navigation wiederum kümmert sich dann um die tieferen Ebenen innerhalb des Themenbereichs.
– Footernavigation: SharePoint-Seiten bieten optional eine Fußzeile, in der z.B. Impressum, Datenschutz oder weiterführende Links untergebracht werden können. Es ist empfehlenswert, für alle Sites eines Hubs eine einheitliche Fußzeilen-Gestaltung zu nutzen (z.B. mittels eines einheitlichen Site-Designs oder manuellen Abgleichs), damit auch am Seitenende eine konsistente Erfahrung entsteht. Unternehmensweite Links (Kontakt IT-Support, Rechtliche Hinweise etc.) sollten idealerweise in jedem Hub verfügbar sein – sei es in der globalen Navigation oder in der Fußzeile.
– Header und Branding: Das Layout des Seiten-Headers (Standard- vs. erweitert mit Hintergrundbild) sollte pro Hub abgestimmt sein. Viele Unternehmen bevorzugen ein reduziertes Header-Design, damit die Hub-Navigation prominent bleibt. Farben und Logos sind durch das Hub-Branding ohnehin vereinheitlicht; hier sollte darauf geachtet werden, dass keine Site aus der Reihe tanzt (außer es ist bewusst z.B. für Extranet-Bereiche anders gestaltet). Ein gemeinsames Logo oder Erkennungszeichen pro Hub (z.B. ein Icon im Nav-Menü) hilft Nutzern ebenfalls bei der Orientierung.

Um die Navigation zu gestalten und freizugeben, empfiehlt es sich, systematisch vorzugehen. Eine Checkliste für die Navigation kann folgende Punkte umfassen (Beispiele):
1. Konzeptphase: Alle erforderlichen Haupt- und Unterpunkte identifiziert? Struktur logisch gruppiert? (Review mit Stakeholdern)
2. Benennung: Alle Navigationslabels eindeutig, konsistent und Duden-konform? Keine verbotenen Abkürzungen oder jargonlastigen Begriffe?
3. Technische Umsetzung: Navigation im Hub angelegt und ggf. Audience Targeting pro Link korrekt konfiguriert? (inkl. Test der Sichtbarkeit mit verschiedenen User-Rollen)
4. Verlinkung: Stimmen alle Linkziele (korrekte URLs, keine toten Links)? Externe Links oder Links zu anderen Hubs entsprechend gekennzeichnet?
5. Abnahme: Navigation mit Fachbereichsverantwortlichen abgestimmt und durch die Intranet-/UX-Verantwortlichen freigegeben?
6. Dokumentation: Navigationsstruktur dokumentiert (z.B. als Sitemap-Grafik oder Tabelle) und Versionsstand festgehalten, um Änderungen nachverfolgen zu können.

Diese Schritte sichern, dass die Hub-Navigation nicht nur bei Launch korrekt und durchdacht ist, sondern auch im laufenden Betrieb gepflegt und weiterentwickelt werden kann. Insbesondere die Dokumentation und das Änderungslog der Navigation sind wichtig, um bei personellen Veränderungen oder späteren Anpassungen die Historie nachvollziehen zu können. Letztlich sollte die Navigation regelmäßig (z.B. jährlich) einem Review unterzogen werden, um sie an veränderte Inhalte oder Nutzerbedürfnisse anzupassen. Die detaillierte Checkliste dazu findet sich im Abschnitt Checklisten dieses Leitfadens.

5. Suche & Auffindbarkeit

Die Suchfunktion in SharePoint ist ein zentrales Werkzeug, um Inhalte schnell zu finden – gerade in einer Hub-Struktur. Nutzer haben hierbei verschiedene Suchbereiche zur Verfügung:
– Website-spezifische Suche: Befindet man sich auf einer einzelnen Site (z.B. einer Team-Site), werden bei einer Suche zunächst nur Treffer aus dieser Site angezeigt.
– Hub-weite Suche: Sucht man innerhalb einer Hub-Site, umfasst der Suchindex standardmäßig alle dem Hub zugeordneten Sites. Oft wird dies dem Nutzer durch einen Hinweis „Suche in \<Hub-Name>“ deutlich gemacht. Dieser Hub-Kontext filtert also die Ergebnisse auf den Themen- oder Funktionsbereich des Hubs.
– Organisationsweite Suche: Über die globale Suchseite (z.B. von der SharePoint Startseite oder via Office.com) oder durch manuelles Umschalten können Benutzer auch über alle Inhalte der Organisation suchen. Dies ist nützlich für querliegende Suchen, aber die Ergebnismenge kann sehr groß sein.

Für Hub-Verantwortliche stellt sich die Aufgabe, den Suchbereich zielgerichtet zu setzen und zu konfigurieren. In den meisten Fällen ist es sinnvoll, dass die Nutzer zunächst im Hub-Kontext suchen (um nur relevante, thematisch passende Ergebnisse zu erhalten) und nur bei Bedarf auf die gesamte Organisation ausweiten. Die Standardeinstellungen von SharePoint unterstützen dies bereits. Es kann dennoch hilfreich sein, in Schulungen oder Hilfetexten darauf hinzuweisen, wie man zwischen Hub- und Organisationssuche wechselt – gerade für weniger geübte Anwender.

Ergebnisquellen und Vertikalen: In der modernen Microsoft Search gibt es vordefinierte Vertikalen (Register) wie „Alle“, „Dateien“, „Websites“, „Personen“, „Nachrichten“ usw., die es Nutzern erleichtern, Ergebnisse zu filtern. Als Hub-Administrator kann man im Microsoft 365 Search & Intelligence Admin Center auch benutzerdefinierte Vertikalen oder Ergebnisquellen definieren, um die Suche noch zielgerichteter zu machen. Beispielsweise könnte man einen eigenen Such-Tab für „Verfahrensanweisungen“ einrichten, der nur Ergebnisse aus dem QM-Hub anzeigt. Solche Anpassungen erfordern jedoch einiges an Konzeption und sollten nur vorgenommen werden, wenn ein klarer Mehrwert besteht. Wichtig ist vor allem, dass die Standard-Suchergebnisse möglichst relevant sind: Die meisten Nutzer schauen nur die ersten Treffer an (die „erste Ergebnisseite“ – auch wenn in Microsoft Search via Endlos-Scroll dargestellt – ist entscheidend). Daher lohnt es sich, in die Optimierung der Suchergebnisse zu investieren.

Ein Aspekt der Optimierung ist die Nulltreffer-Analyse: Hub-Verantwortliche sollten regelmäßig prüfen, welche Suchanfragen keine Treffer liefern. Diese Informationen stellt Microsoft 365 im Suchbericht zur Verfügung. Typische Nulltreffer könnten z.B. auf fehlende Inhalte oder ungebräuchliche Begrifflichkeiten hindeuten. Maßnahmen daraus können sein, die betreffenden Inhalte bereitzustellen (wenn relevante Fragen häufiger gestellt werden, aber Inhalte fehlen) oder Synonyme/Abkürzungen zu hinterlegen. Microsoft Search erlaubt das Hinterlegen von Synonymen für Fachbegriffe, sodass Benutzer auch mit anderen Begriffen zum Ziel kommen. Ebenso können Bookmarks (Lesezeichen) definiert werden – das sind von Administratoren kuratierte Treffer, die bei bestimmten Schlüsselwörtern ganz oben angezeigt werden, beispielsweise ein Link zum „HR-Portal“, wenn jemand „Urlaub beantragen“ sucht.

Bei der kuratierten Suche ist jedoch Vorsicht geboten im Hub-Kontext. Ein bekanntes Fallbeispiel: Ein Unternehmen richtet ein Lesezeichen für „Reisekostenrichtlinie“ ein, das auf die entsprechende Seite im Finance-Hub zeigt. Sucht ein Nutzer nun auf der globalen Suche danach, erscheint das Bookmark prominent. Sucht er jedoch innerhalb eines anderen Hubs (oder im Finance-Hub selbst mit auf Hub begrenzter Suche), kann es sein, dass das Bookmark nicht angezeigt wird, da Microsoft Search Bookmarks primär auf die globale Ebene wirken. Dies ist ein Fallstrick: Nutzer könnten annehmen, die Richtlinie existiere nicht, wenn sie im falschen Kontext suchen. Die Lösung ist, wichtige unternehmensweite Inhalte entweder über die Organisationssuche zu kommunizieren oder sicherzustellen, dass sie in allen relevanten Hubs gefunden werden (z.B. durch Querverlinkungen oder indem man Benutzer auf die globale Suche leitet). Kurz gesagt: Hub-scoped Search liefert nur Ergebnisse aus dem Hub – global konfigurierte Hilfsmittel wie Bookmarks und Q&As wirken nur, wenn der Suchkontext die gesamte Organisation umfasst.

Eine besondere Rolle spielt Restricted SharePoint Search (RSS), eine Einstellung, mit der die Organisation den durchsuchbaren Inhaltsumfang gezielt einschränken kann. Ist diese Option aktiviert, wird die organisationsweite Suche (und damit auch die Datenbasis für Tools wie Microsoft 365 Copilot) auf einen kuratierten Satz von SharePoint-Seiten begrenzt – bis zu 100 ausgewählte Sites können auf eine Allow-Liste gesetzt werden. Der Zweck ist es, die Ausgabe von KI und Suche auf verlässliche, geprüfte Inhalte zu beschränken und sensible Informationen aus dem Index herauszuhalten. In der Praxis würde man z.B. die wichtigsten Hub-Sites (Intranet-Startseite, Policy-Hub, Qualitätsmanagement-Hub etc.) auf die Liste setzen. Alle nicht gelisteten Sites würden bei aktivierter Restricted Search weder in der globalen Suche noch für Copilot berücksichtigt. Für Hub-Architekten bedeutet dies: Wenn Ihr Unternehmen RSS einsetzt, müssen die Hubs, die als „zugelassene“ Inhaltsquellen dienen sollen, besonders sorgfältig kuratiert werden (inhaltlich aktuell, vollständig und für alle zugänglich). Gleichzeitig muss den Nutzern kommuniziert werden, dass die globale Suche nicht mehr alles findet, sondern nur einen Ausschnitt – was die Bedeutung der Hub-internen Suche erhöhen kann. Es ist eine strategische Entscheidung, RSS zu nutzen: Sie verbessert die Qualität der Suchtreffer und die Datensicherheit, kann aber die Auffindbarkeit von randständigen oder neuen Inhalten erschweren.

Taktiken für kuratierte Inhalte: Um die Auffindbarkeit im Hub zu erhöhen, sollten wichtige Informationen gezielt aufbereitet werden. Dazu gehört etwa, innerhalb eines Hubs zentrale FAQs, Richtliniensammlungen oder Glossare anzulegen, damit häufige Fragen sofort beantwortet werden. Solche Seiten können prominent im Hub verlinkt sein und tauchen bei passenden Suchanfragen im Hub entsprechend weit oben auf. Ebenso kann man in News-Beiträgen oder Seiten Schlagworte verwenden, von denen man weiß, dass Nutzer danach suchen (z.B. in einer Personal-FAQ das Wort „Urlaub“ und „Ferien“ aufnehmen, wenn beide Begriffe genutzt werden). In Microsoft Search gibt es die Möglichkeit, Q&A-Einträge zu erstellen – diese funktionieren ähnlich wie Lesezeichen, geben aber Frage-Antwort-Paare aus. Für einen Hub könnte man z.B. typische Fragen als Q&A hinterlegen („Wie beantrage ich Home Office?“ – Antwort mit Link zur Anleitung im Hub). Aber erneut gilt: Diese Q&As greifen nur, wenn die Suche nicht hart auf den Hub eingeschränkt ist. Daher sollte man immer prüfen, wie die Nutzer tatsächlich suchen.

Zusammengefasst ist das A und O für Auffindbarkeit im Hub eine Kombination aus: technisch richtig eingestellter Suchreichweite (Hub vs. global), inhaltlicher Kuratierung wichtiger Stichworte und einer regelmäßigen Analyse des Suchverhaltens. Es empfiehlt sich, KPIs für die Suche zu definieren (siehe Abschnitt Monitoring & KPIs) – etwa die Quote erfolgreicher Suchen oder die Top-10-Suchanfragen pro Hub – und anhand dieser Kennzahlen die Informationsarchitektur kontinuierlich zu verbessern.

6. News, Rollups & Kommunikation

News-Beiträge sind ein zentrales Element der Hub-Kommunikation. Über die News-Funktion können aktuelle Meldungen, Ankündigungen oder Erfolgsgeschichten leicht erstellt und über Hubs hinweg verteilt werden. Es empfiehlt sich, einen klar definierten News-Lebenszyklus festzulegen:
– Quellen: Legen Sie fest, welche Sites innerhalb des Hubs Nachrichten publizieren dürfen. In manchen Organisationen erfolgen alle wichtigen Ankündigungen zentral über die Hub-Site selbst (z.B. durch die interne Kommunikationsabteilung). In anderen Fällen dürfen auch Unterseiten (Team-Sites) News posten, etwa Projektberichte oder bereichsspezifische Updates. Es kann sinnvoll sein, bestimmte Seiten als offizielle „News-Quellen“ zu deklarieren (SharePoint bietet die Möglichkeit, Sites als organisationweite Newsquelle zu markieren, damit deren Meldungen gesondert hervorgehoben werden).
– Erstellung und Freigabe: Definieren Sie, ob News vor Veröffentlichung einen Freigabeprozess durchlaufen sollen. Beispielsweise könnten alle News auf dem Qualitätsmanagement-Hub zuerst von einem QM-Verantwortlichen geprüft werden (mittels Seitenüberprüfung oder Power Automate-Flow zur Genehmigung). Für weniger kritische Bereiche reicht evtl. das Vier-Augen-Prinzip im Redaktionsteam. Wichtig ist, dass die Autoren wissen, was von ihnen erwartet wird (z.B. wer für die finale Freigabe zuständig ist und welche Richtlinien für Inhalte gelten, wie Sprachstil, Verwendung von Bildern, etc.).
– Publikation und Ablauf: Überlegen Sie, wie lange News sichtbar sein sollen. Alte News können mit der Zeit an Relevanz verlieren; manche Organisationen entfernen sie nach X Tagen von der Startseite oder verschieben sie ins News-Archiv (z.B. eine separate Seite mit älteren Meldungen). SharePoint bietet keine automatische Ablaufsteuerung für News, aber man kann manuell z.B. am Monatsende veraltete Beiträge ausblenden oder mittels Filter (z.B. „zeige nur News der letzten 60 Tage“) arbeiten.
– Governance: Benennen Sie einen Verantwortlichen für die News-Sektion des Hubs. Diese Person bzw. Gruppe sollte ein Auge darauf haben, dass regelmäßig neue Inhalte erscheinen, die Qualität stimmt und keine wichtigen Updates untergehen. Zudem sollte es Richtlinien geben (vielleicht in Form eines Redaktionsleitfadens), was als News geeignet ist und wie die Kommunikation tonlich und visuell gestaltet sein soll.

Für die Anzeige von Nachrichten auf der Hub-Startseite nutzt man typischerweise Rollup-Webparts wie das News-Webpart oder das Highlighted Content (Inhalt hervorheben)-Webpart. Diese lassen sich so konfigurieren, dass sie Inhalte aus dem gesamten Hub anzeigen:
– Im News-Webpart kann als Quelle „Alle Websites in der Hubsite“ gewählt werden. Dann werden automatisch alle News-Seiten aus allen zugeordneten Sites zeitlich sortiert angezeigt. Alternativ kann man eine manuelle Auswahl von bestimmten Quellsites treffen, falls nur ein Teil der Sites News beitragen soll.
– Filter und Sortierung: Beide genannten Webparts erlauben Filter (z.B. nur News mit bestimmter Eigenschaft oder Schlagwort) und Sortieroptionen (nach Datum, manuelle Sortierung, nach Beliebtheit etc.). In der Praxis bewährt es sich, News chronologisch oder nach Wichtigkeit (manuell priorisiert) zu sortieren. Eine manuelle Sortierung erfordert jedoch ständige Pflege. Ein guter Kompromiss ist, wichtige Meldungen via „organisatorische Newsquelle“ oder durch festgelegte Highlight-Slots anzuzeigen und den Rest chronologisch.
– Dubletten vermeiden: Wenn mehrere Webparts oder Übersichtsseiten eingesetzt werden, ist darauf zu achten, dass identische Inhalte nicht parallel angezeigt werden. Beispielsweise sollte ein News-Beitrag, der schon im zentralen News-Webpart erscheint, nicht noch einmal in einem anderen Abschnitt derselben Seite redundant auftauchen. Auch beim Einsatz von Highlighted Content-Webparts (die z.B. Dokumente oder Seiten anzeigen) sollte man filtern, dass keine News-Seiten doppelt gelistet werden, wenn parallel das News-Webpart verwendet wird.

Die Mehrsprachigkeit von News ist eine Herausforderung für multinationale Unternehmen. SharePoint bietet die Möglichkeit, mehrsprachige Seiten zu erstellen: Eine News-Seite kann also Übersetzungen in verschiedenen Sprachen haben, die je nach Spracheinstellung des Benutzers angezeigt werden. Alternativ kann man getrennte News-Sites pro Sprache anlegen (z.B. eine deutsche und eine englische Newsseite) und jeweils nur die entsprechenden Beiträge veröffentlichen. Beide Ansätze erfordern klare Prozesse: Bei Übersetzungen muss z.B. definiert werden, wer eine News in die Zweitsprache überträgt und wie zeitnah dies geschieht. Oftmals werden wichtige globale News in Englisch publiziert und lokal in wichtigen Hubs zusammengefasst oder kommentiert. Wichtig ist, den Nutzern die Möglichkeit zu geben, die für sie relevanten sprachlichen Inhalte zu sehen – entweder automatisch durch Spracheinstellungen oder durch Auswahlmöglichkeiten (manche Intranets bieten z.B. Schalter „Switch to English“ an News-Seiten).

Bilder und Medien: News sind in der Regel ansprechender mit Bildern oder Grafiken. Es sollte einheitlich geregelt sein, welche Bildformate und -größen verwendet werden (SharePoint skaliert Thumbnails meist auf Querformat 16:9 – idealerweise liefern die Redakteure also Bilder in diesem Format, um unpassende Ausschnitte zu vermeiden). Auch die Verwendung von Titelbildern, Autorenangaben und Datum sollte im Hub möglichst konsistent gehandhabt werden, damit die News-Liste ein aufgeräumtes Erscheinungsbild hat. Ein zentrales Bildarchiv oder die Nutzung von Stock-Bildquellen kann hilfreich sein, um qualitativ hochwertige und passende Bilder bereitzustellen. Beachten Sie zudem Barrierefreiheit: Alternativtexte für Bilder in News sollten von den Autoren gepflegt werden.

Layout-Standards: Jeder Hub sollte definieren, wie eine News-Seite aufgebaut ist. Beispielsweise kann man Templates oder Vorlagen nutzen: Überschrift immer nach dem Muster „[Thema]: Kurzer Titel“, Einleitungstext fett, Haupttext in Abschnitten, am Ende ggf. ein Call-To-Action oder weiterführende Links. Solche Standards sorgen dafür, dass unabhängig vom Autor die Beiträge professionell wirken. Außerdem erleichtert es dem Leser die Orientierung, wenn z.B. immer an ähnlicher Stelle eine Zusammenfassung steht oder zusätzlicher Kontext gegeben wird.

Zusammenfassend erhöhen regelmäßige, gut aufbereitete News die Lebendigkeit eines Hubs und fördern die bereichsübergreifende Kommunikation. Sie erfordern aber auch Disziplin und Betreuung – veraltete oder schlecht gemachte News können das Nutzervertrauen senken. Ein fester Rhythmus (z.B. wöchentlicher News-Check-in), klare Verantwortlichkeiten und definierte Qualitätskriterien helfen, die Hub-News als zuverlässige Informationsquelle zu etablieren. Governance-seitig sollte dokumentiert sein, wer News erstellen darf, wer freigibt und wie Korrekturen oder Rückfragen gehandhabt werden. So wird die News-Kommunikation im Hub zum effektiven Bindeglied in der Informationsarchitektur.

7. Berechtigungen & Sicherheit

In puncto Berechtigungen gilt bei Hubs der wichtige Grundsatz: Ein Hub ändert nichts an den Berechtigungen seiner Sites, es sei denn, man handelt bewusst. Das heißt, auch wenn mehrere Sites unter einem Hub verbunden sind, bleibt die Zugriffssteuerung jeder einzelnen Site separat. Benutzer sehen über Hub-Navigation, News-Rollups oder Suche nur das, wofür sie auf den Quellsites Berechtigungen haben (Security Trimming greift überall). Dieses Prinzip schützt Inhalte vor unbefugtem Zugriff, erfordert aber, dass Administratoren und Site-Eigentümer weiterhin sorgfältig mit Berechtigungen umgehen.

Hub-Berechtigungssynchronisation (Besucher): Um dennoch in bestimmten Szenarien einen einheitlichen Leserkreis herzustellen, bietet Microsoft 365 die Option, eine Hub-weite Besuchergruppe zu synchronisieren. Ist diese Funktion im Hub aktiviert, können bis zu 10 Einträge (Personen oder – besser – Sicherheitsgruppen bzw. Microsoft 365-Gruppen) als Hub-Besucher festgelegt werden. Alle Sites, die dem Hub neu beitreten, übernehmen dann automatisch diese Besucher als Leser (Besucher-Rechte) auf Site-Ebene. Bestehende zugeordnete Sites können ebenfalls synchronisiert werden, sodass beispielsweise die Gruppe „Alle Mitarbeitende“ auf jeder Hub-Site Leserechte erhält. Die Einsatzmöglichkeiten: Vor allem Intranet-Hubs, die als organisationsweite Informationsdrehscheibe dienen, profitieren davon – man stellt sicher, dass wirklich jeder Mitarbeiter Zugriff auf alle Inhalte hat, ohne jede Site einzeln freizuschalten. Grenzen und Tücken: Die Synchronisation umfasst nur das Besucherniveau. Mitglieder- oder Eigentümerrechte werden nicht verteilt. Außerdem sind Site-Owner nicht gezwungen, die Hub-Besucher zu übernehmen – sensible Sites können also vom Hub getrennt bleiben oder die Synchronisation ignorieren. In der Praxis sollte man diese Funktion gezielt einsetzen und die Konsequenzen bedenken: Wenn ein Nutzer aus der Hub-Besuchergruppe entfernt wird, verliert er damit auch auf allen zugehörigen Sites die Leserechte. Entsprechend muss ein Änderungsprozess (z.B. bei Austritt eines Mitarbeiters oder Rollenwechsel) dafür sorgen, dass die Berechtigungen aktuell bleiben. Ein Audit der Hub-Berechtigungssynchronisation empfiehlt sich in regelmäßigen Abständen: Prüfen, welche Sites synchronisiert sind, ob alle gewünschten Personen in der Hub-Besuchergruppe sind und ob keine veralteten Gruppen verwendet werden. Im Security-&-Compliance-Center lassen sich entsprechende Aktivitäten (wie das automatische Hinzufügen von Usern zu Site-Berechtigungsgruppen) nachvollziehen, was bei Bedarf für Revisionen dokumentiert werden kann.

Gastzugriff und Extranet im Hub-Kontext: Viele Unternehmen öffnen bestimmte SharePoint-Sites für externe Partner oder Gäste. Wenn solche Sites Teil eines Hubs sind, stellt sich die Frage, wie man die Navigation und Inhalte gestaltet, damit Externe nur sehen, was sie dürfen. Wichtig: Ein Gastbenutzer, der auf eine Hub-Site zugreift, sieht prinzipiell die gleiche Hub-Navigation – inkl. Links, die ggf. auf interne Sites zeigen, zu denen er keinen Zutritt hat. Klickt er einen solchen Link, erhält er eine Zugriffsverweigerung. Um diese irritierende Erfahrung zu vermeiden, gibt es zwei Ansätze:
1. Audience Targeting für Navigation nutzen: Wie in Abschnitt 4 beschrieben, kann man die Navigation so einstellen, dass externe Benutzer (die meist in bestimmten Gäste-Gruppen oder via Domänenkennung identifizierbar sind) bestimmte Links gar nicht sehen. So könnte man z.B. alle internen Bereichs-Links im Hub nur für Mitarbeiter sichtbar schalten und für Gäste ausblenden. Dies setzt eine saubere Trennung der Benutzergruppen voraus.
2. Separate Hubs oder Bereiche für Externe: In vielen Fällen ist es die bessere Lösung, externe Partner auf dedizierte Extranet-Hubs oder -Sites zu führen, statt sie auf dem normalen Mitarbeiter-Hub „mitzunehmen“. Zum Beispiel könnte ein Partnerportal als eigener Hub eingerichtet sein, wo nur ausgewählte interne Informationen bereitgestellt werden, die für Partner relevant sind. Vom internen Hub aus kann man einen Link dorthin anbieten (der für externe wiederum nicht sichtbar ist). Damit bleibt die interne Hub-Navigation „sauber“ und Externe bewegen sich in einer für sie gestalteten Umgebung.

Zusätzlich sollten Conditional Access-Richtlinien in Betracht gezogen werden. Diese ermöglichen es, Zugriffe auf SharePoint (und damit Hubs) nach Gerätetyp, Standort oder Benutzerkategorie zu steuern. Beispielsweise kann man vorgeben, dass externe Gäste nur mit MFA (Multi-Faktor-Authentifizierung) und über einen Webbrowser zugreifen dürfen, oder dass interne Nutzer außerhalb des Firmennetzes keine Downloads von bestimmten Hub-Sites machen können. Solche Richtlinien werden nicht auf Hubs direkt konfiguriert, sondern über Azure AD/Entra ID, wirken sich aber auf die Nutzung der Hub-Inhalte aus und sollten in der Sicherheitsbetrachtung eines Hub-Konzepts mit einbezogen werden. Ein typisches Beispiel: Ein Qualitätsmanagement-Hub mit vertraulichen Dokumenten könnte durch Conditional Access so geschützt sein, dass der Zugriff nur mit Managed Devices möglich ist. Die Hub-Site selbst lädt zwar für jedermann, aber Inhalte werden ggf. blockiert, wenn die Bedingung nicht erfüllt ist.

Sensitivity Labels (Empfindlichkeitsbezeichnungen) auf Sites-Ebene sind ein weiteres Werkzeug: SharePoint Online ermöglicht es, ganze Sites mit einem Label zu versehen (z.B. „Vertraulich“ oder „Extern frei“). Diese Labels steuern u.a. die Möglichkeiten zum externen Teilen, zur Gerätezugriffsbeschränkung und zur Verschlüsselung von heruntergeladenen Dateien. In einem Hub sollte man konsistente Labeling-Strategien verfolgen, damit nicht extrem unterschiedliche Sicherheitsniveaus wild gemischt werden. Beispielsweise könnte man festlegen, dass alle Sites im Mitarbeiter-Intranet-Hub maximal „Intern“ sein dürfen und keine hochgeheimen Inhalte dort liegen (diese kämen dann in einen separaten, streng vertraulichen Hub). Umgekehrt kann man Extranet-Hubs generell mit „Extern zugänglich“ labeln, um sicherzustellen, dass dort keine Daten abgelegt werden, die nicht geteilt werden dürfen. Die Integration von Sensitivity Labels in die Hub-Governance bedeutet auch: Bei der Aufnahme einer neuen Site in den Hub sollte geprüft werden, welches Label sie hat und ob es zu den restlichen passt.

Trotz aller technischen Maßnahmen bleibt ein Punkt essenziell: Trennung sensibler Bereiche trotz gemeinsamer Navigation. Wenn sensible Sites bewusst in einen Hub aufgenommen werden (etwa ein internes HR-Teamprojekt im öffentlichen HR-Hub), sollte man zumindest dafür sorgen, dass die Existenz dieser Site nicht unnötig prominent für alle auftaucht. Wie im Microsoft-Beispiel empfohlen, kann man solche Links entweder gezielt verstecken (Audience Targeting nur für das HR-Team) oder klar kennzeichnen – z.B. „HR-Team (privat)“ in der Navigation – damit normale Nutzer direkt wissen, dass sie dort keinen Zugriff haben. So reduziert man Frust und vermeidet ständige Zugriffsanfragen. Alternativ könnte man auch überlegen, wirklich hochsensible Bereiche gar nicht erst an den Hub anzuschließen, sondern separat zu belassen, wenn deren Mehrwert im Hub gering ist.

Überwachung und Rezertifizierung: Im Kontext Berechtigungen ist es ratsam, regelmäßige Überprüfungen durchzuführen. Wer hat Zugang zu den Hub-Sites (insbesondere bei Hubs mit vertraulichen Infos)? Sind alle Gastnutzer noch aktuell oder können alte Zugänge entfernt werden? Hier bietet sich ein Rezertifizierungsprozess an, bei dem z.B. alle 6 oder 12 Monate die Site Owners die Berechtigungen ihrer Sites durchgehen und bestätigen müssen, dass noch alles korrekt ist. Auch die Hub-Besuchergruppe (falls genutzt) sollte periodisch geprüft werden. Diese Überprüfungen lassen sich organisatorisch (via E-Mail-Reminder und manuelle Checklisten) oder technisch (via Access Reviews in Entra ID für Gruppen) umsetzen. Wichtig ist, dass im Governance-Konzept des Hubs solche Maßnahmen verankert sind, um über die Zeit die Sicherheit aufrecht zu erhalten.

Zusammengefasst bietet ein Hub zwar die Möglichkeit, Informationen breiter bereitzustellen, aber er verlangt auch eine sorgfältige Abstimmung der Sicherheitsmaßnahmen. Eine klare Richtlinie, welche Inhalte in welchem Hub-Level gehören, welche extern geteilt werden dürfen und wie Berechtigungen verwaltet werden, ist unabdingbar. Indem man die technischen Features (Audience Targeting, Sensitivity Labels, Berechtigungssync, Conditional Access) kombiniert und mit prozessualen Kontrollen (Rezertifizierungen, Audits) ergänzt, lässt sich ein Hub schaffen, der sowohl offen und nutzerfreundlich als auch sicher und compliant ist.

8. Compliance, Governance & Lebenszyklus

SharePoint-Hubs berühren auch den Bereich Compliance und erfordern eine gute Governance, um langfristig erfolgreich zu sein.

Aufbewahrungsrichtlinien (Retention) und DLP: Je nach Art der Inhalte in den Hub-Sites müssen Retention-Policies (Aufbewahrungs- und Löschrichtlinien) definiert werden. Beispielsweise könnte im Qualitätsmanagement-Hub gelten, dass bestimmte Dokumentbibliotheken einer 10-jährigen Aufbewahrungspflicht unterliegen (etwa nach ISO-Zertifizierungsvorgaben). Solche Richtlinien können zentral im Purview Compliance Center erstellt und den Sites oder sogar einzelnen Dokumentenbibliotheken zugewiesen werden. Hub-Sites an sich vererben keine Retention automatisch an ihre Sites, aber man kann alle Sites eines Hubs in eine bestimmte Compliance-Kategorie einordnen und darüber steuern. Data Loss Prevention (DLP)-Regeln wiederum können eingerichtet werden, um zu verhindern, dass vertrauliche Informationen unkontrolliert aus dem Hub gelangen – z.B. eine Regel, die verhindert, dass in einem Personal-Hub Dateien mit Personaldaten extern geteilt oder per E-Mail versandt werden. Solche DLP-Policies prüfen Inhalte auf definierte Muster (wie Kreditkartennummern, personenbezogene Daten etc.) und können Aktionen blockieren oder protokollieren. Im Hub-Kontext sollte man identifizieren, welche Art von sensiblen Daten in welchem Hub vorkommt und entsprechende Schutzmaßnahmen aktivieren.

Sensitivity Labels wurden bereits angesprochen: Auf Hubs angewandt, dienen sie vor allem der Klassifizierung von Sites und der Kontrolle von Freigabeeinstellungen. Hier sollte die Governance definieren, welche Labels in welchen Hubs zulässig oder vorgesehen sind. Beispiel: Ein öffentlicher Intranet-Hub darf nur Sites mit dem Label „Intern – frei teilbar“ enthalten, wohingegen ein Forschung-&-Entwicklung-Hub vielleicht „Vertraulich“ oder höher erfordert. Wichtig ist, dass diese Regeln dokumentiert sind und den Site-Verantwortlichen bekannt gemacht werden.

Audit und Überwachung: Für alle Hub-relevanten Aktivitäten (Seitenaufrufe, Änderungen an Seiten, Berechtigungsänderungen etc.) stehen Audit-Logs zur Verfügung. Die IT oder Compliance-Abteilung sollte festlegen, welche Audit-Daten regelmäßig überprüft werden. Beispielsweise könnte man ein monatliches Audit-Report erstellen, der alle Site-Zuordnungen zum Hub (neu hinzugefügte oder entfernte Sites) zeigt, alle externen Freigaben von Dateien in Hub-Sites, oder auch verdächtige Zugriffsmuster. Diese Reports helfen, Probleme frühzeitig zu erkennen – etwa wenn plötzlich sehr viele externe Gäste auf einen Hub eingeladen wurden oder massenhaft Dateien heruntergeladen werden.

Eine klare Rollenverteilung ist ein Kernstück der Governance. Typische Rollen in Zusammenhang mit einem Hub:
– Hub-Eigentümer (Owner): Verantwortlich für die Gesamtfunktion des Hubs, typischerweise jemand aus dem Fachbereich oder der Intranet-Verantwortung. Er entscheidet über die inhaltliche Ausrichtung, genehmigt neue Site-Aufnahmen in den Hub und ist erster Ansprechpartner bei Fragen.
– Hub-Administrator (Technisch): Meist aus der IT, zuständig für die technischen Einstellungen des Hubs (z.B. Registrierung als Hub, Konfiguration der Berechtigungssynchronisation, Einrichtung von Approval-Flows für Site-Beitritte). Dieser stellt auch sicher, dass Einstellungen wie Theme, Navigation und Audience Targeting korrekt umgesetzt sind.
– Site-Eigentümer (der zugeordneten Sites): Diese behalten Verantwortung für ihre jeweilige Site (Inhalte, Berechtigungen innerhalb der Site, etc.), arbeiten aber im Hub-Kontext mit dem Hub-Eigentümer zusammen. Sie müssen z.B. Hub-Regeln beachten (etwa in puncto Branding oder Navigation keine eigenen abweichenden Designs einführen, News-Regeln einhalten).
– Redaktion/Content-Verantwortliche: Personen, die Inhalte im Hub pflegen – z.B. News-Redakteure, Seiteneditoren für zentrale Inhalte, ggf. Übersetzer für mehrsprachige Inhalte. Sie sind für Aktualität und Qualität der Inhalte zuständig und folgen den Redaktionsrichtlinien.
– Compliance-Beauftragter: Diese Rolle überwacht, ob im Hub alle Compliance-Vorgaben eingehalten werden (Datenschutz, Aufbewahrung, Klassifizierung). Sie wird oft von jemandem in IT-Compliance oder Datenschutz wahrgenommen, der regelmäßig die Audit-Logs checkt und sicherstellt, dass z.B. keine sensiblen Daten falsch behandelt werden.
– Support/Betrieb: In manchen Fällen gibt es noch eine operative Rolle, die für den laufenden Betrieb sorgt – z.B. Site Collections Administrator oder Support-Mitarbeiter, die bei Nutzerfragen oder Problemen mit Berechtigungen, Suche etc. helfen.

Um Missverständnisse zu vermeiden, wird häufig eine RACI-Matrix erstellt, die genau festhält, wer für welche Aufgaben Responsible (durchführend), Accountable (letztverantwortlich), Consulted (konsultiert) oder Informed (zu informieren) ist. Ein Ausschnitt einer solchen Matrix könnte z.B. zeigen, dass für „Änderung der Hub-Navigation“ der Hub-Owner verantwortlich (R) ist, der IT-Admin konsultiert wird (C) und alle Site-Owner informiert werden (I), während die endgültige Freigabe durch den Intranet-Leiter erfolgt (A). Eine vollständige RACI-Matrix für Hub-Betrieb und Governance ist in der Tabellen-Sammlung dieses Dokuments enthalten.

Änderungsprozesse: Ein Hub ist kein statisches Konstrukt – mit der Zeit werden Anpassungen nötig. Daher sollten klare Prozesse definiert sein für Änderungen in folgenden Bereichen:
– Design/Layout: Wenn z.B. die Startseite des Hubs ein Redesign bekommen soll oder neue Webparts hinzugefügt werden, wer initiiert und wer genehmigt das? (Z.B. Vorschlag durch Hub-Owner, Abstimmung mit Kommunikationsteam, Umsetzung durch IT oder einen Power-User, Freigabe durch einen Lenkungsausschuss)
– Navigation/Struktur: Änderungen an der Hub-Navigation (neue Menüpunkte, Umbenennungen, Umlagerungen) sollten kontrolliert erfolgen. Oftmals ist es sinnvoll, solche Änderungen in einem Staging-Bereich zu testen und mit Schlüsselanwendern abzustimmen, bevor sie live gehen. Auch sollte dokumentiert werden, wann welche Änderung durchgeführt wurde (Änderungslog der Navigation).
– Berechtigungen: Das Aktivieren/Deaktivieren der Hub-Berechtigungssynchronisation, das Hinzufügen neuer Besuchergruppen oder das Ändern von Zugriffsrechten auf sensiblen Sites im Hub sollte einen definierten Prozess durchlaufen. Beispielsweise könnte festgelegt sein, dass jede Anpassung der Berechtigungssync von der IT-Security abgesegnet werden muss.
– Suchkonfiguration: Falls entschieden wird, die Suche anzupassen (etwa durch Einführung von Restricted Search oder neuen Such-Vertikalen), sollte ein Konzept erarbeitet und mit den Stakeholdern (inkl. Compliance, wenn es um Datenzugriff geht) abgestimmt werden. Änderungen an der Suche haben einen großen Einfluss auf die Nutzererfahrung und müssen gut kommuniziert werden.

All diese Prozesse sollten idealerweise in einer Hub-Governance-Dokumentation festgehalten sein. Dazu gehört auch ein Risikoregister: Eine Liste möglicher Risiken bei Betrieb des Hubs, bewertet nach Eintrittswahrscheinlichkeit und Auswirkungsgrad, samt Gegenmaßnahmen. Beispiele für Risiken:
– Risiko: Nutzer finden Inhalte nicht und greifen auf veraltete Quellen zurück (Eintritt: mittel, Auswirkung: hoch). Maßnahme: Regelmäßige Suchanalyse und Verbesserung der Inhalte/Struktur; Trainings für Nutzer.
– Risiko: Unautorisierte Site wird dem Hub hinzugefügt und teilt falsche oder unsichere Inhalte (Eintritt: gering, Auswirkung: mittel). Maßnahme: Hub-Zuordnungen nur via Approval-Flow zulassen; regelmäßige Überprüfung der Hub-Mitglieder.
– Risiko: Verstoß gegen Datenschutz durch unsachgemäße Ablage personenbezogener Daten im falschen Hub (Eintritt: mittel, Auswirkung: hoch). Maßnahme: Sensibilisierung der Site-Owner, automatische DLP-Prüfung aller Uploads auf solchen Sites, regelmäßiges Audit durch Datenschutzbeauftragten.
– Risiko: Performance-Probleme, wenn die Hub-Seite zu viele dynamische Inhalte lädt (Eintritt: mittel, Auswirkung: mittel). Maßnahme: Performance-Monitoring einführen, schwere Webparts (z.B. große Listen anzeigen) reduzieren, CDN nutzen.

Diese und weitere Risiken sollten identifiziert und mit Verantwortlichkeiten für Gegenmaßnahmen versehen werden. Im Anhang findet sich eine Beispiel-Risiko-Matrix mit Bewertungs- und Maßnahmenplan (siehe Tabellen-Sammlung).

Zusammengefasst stellt die Governance sicher, dass der Hub nicht nur initial gut aufgesetzt ist, sondern über seinen gesamten Lebenszyklus hinweg den Anforderungen entspricht. Das beinhaltet regelmäßige Reviews (z.B. jährliche Hub-Überprüfung auf Relevanz der Navigation, Inhalt, Zugriffe), einen Änderungsmanagement-Prozess für Weiterentwicklungen und klare Compliance-Kontrollen. Mit einem solchen Fundament kann der Hub auch auf lange Sicht flexibel bleiben, ohne Wildwuchs oder Regelverstöße zu riskieren.

9. Betrieb, Monitoring & KPIs

Der langfristige Betrieb eines Hubs erfordert kontinuierliche Aufmerksamkeit. Während die vorigen Abschnitte Planung und Aufbau behandeln, geht es nun darum, wie der Hub im Alltag gemanagt und optimiert wird.

Verantwortlichkeiten im Betrieb: Bereits in der Governance wurden Rollen definiert – im operativen Alltag ist insbesondere der Hub-Owner (inhaltlich) und der Hub-Administrator (technisch) gefragt. Diese sollten in regelmäßigen Abständen zusammenkommen (z.B. monatliches Hub-Team-Meeting), um anstehende Änderungen oder Beobachtungen zu besprechen. Auch Site-Owner der wichtigsten zugeordneten Sites können in diese Runde einbezogen werden, um einen breiten Blick zu gewährleisten. Ein Betriebshandbuch für den Hub kann helfen: Darin steht, wer im Fehlerfall zu kontaktieren ist, wie Backup/Restore (sofern relevant bei gelöschten Inhalten) gehandhabt wird, und wie mit Updates von Microsoft (neue Features, Änderungen) umzugehen ist. Da Microsoft 365 kontinuierlich aktualisiert wird, sollte jemand die Roadmap und Änderungsbenachrichtigungen im Blick haben – z.B. wenn ein neues Hub-Feature ausgerollt wird, muss entschieden werden, ob/wie man es nutzt.

Pflegezyklen: Es ist ratsam, feste Intervalle für Wartung und Inhaltspflege zu definieren. Beispiele:
– Wöchentliche Aufgaben: Prüfung, ob neue News anstehen; Beantwortung von Nutzerfeedback (viele Intranets haben Feedback-Funktionen oder E-Mail für Verbesserungsvorschläge).
– Monatliche Aufgaben: Überprüfen der Hub-Navigation auf Aktualität (müssen Links angepasst werden, sind neue Sites hinzugekommen, die verlinkt werden sollen?); Auswertung der KPIs (s.u.); kleine Stichproben-Audits (funktionieren alle Zugriffe, ist die Seite performant?).
– Quartalsweise Aufgaben: Größerer Review der Inhalte – welche Seiten sind veraltet, welche News können ins Archiv; Überprüfung der Berechtigungen und Mitglieder (insbes. externe Gäste); ggf. Meeting mit Stakeholdern, um neue Anforderungen aufzunehmen.
– Jährliche Überprüfung: Strategischer Check, ob der Hub noch den ursprünglichen Zielen entspricht, ob die Informationsarchitektur angepasst werden muss (z.B. neue Abteilungen hinzugekommen?), ob Schulungen für Redakteure notwendig sind und ob die definierten KPIs erfüllt werden. Hier kann auch eine Nutzerumfrage sinnvoll sein: Wie zufrieden sind die Mitarbeiter mit Navigation, Inhalten, Ladegeschwindigkeit etc.?

Änderungslog: Jede bedeutende Änderung am Hub sollte protokolliert werden. Ob man dafür ein einfaches Word-/Excel-Dokument nutzt oder ein spezielles Änderungsprotokoll – wichtig ist, dass nachvollziehbar bleibt, wann was geändert wurde und warum. Beispielsweise: „01.09.2025 – Navigation: Bereich XY hinzugefügt, auf Wunsch der Abteilung Z, genehmigt von [Name].“ Oder „15.10.2025 – Hub-Theme aktualisiert auf neues Corporate Design, durchgeführt von IT“. Dieses Änderungslog hilft bei der Einarbeitung neuer Verantwortlicher und im Fehlerfall (z.B. wenn plötzlich KPIs abfallen, kann man schauen, ob kurz zuvor eine relevante Änderung stattfand).

KPIs (Key Performance Indicators): Um den Erfolg und die Nutzung des Hubs messbar zu machen, sollten konkrete Kennzahlen definiert werden. Diese KPIs sollten sowohl die Nutzungsintensität als auch die Qualitätsaspekte abbilden. Typische KPIs für einen SharePoint-Hub:
– Nutzung/Traffic: Anzahl eindeutiger Benutzer pro Woche/Monat auf dem Hub; durchschnittliche Verweildauer auf der Hub-Startseite; Gesamtseitenaufrufe im Hub.
– Suche: Anzahl Suchanfragen im Hub pro Zeitraum; Anteil der Suchanfragen ohne Ergebnis (Nulltrefferquote); Top 5 Suchbegriffe und deren Abdeckung (wurden Ergebnisse geklickt?).
– News-Reichweite: Durchschnittliche Views pro News-Beitrag; Anzahl Interaktionen (Gefällt mir, Kommentare falls aktiviert) pro News; Anteil der Mitarbeiter, die wichtige Ankündigungen gesehen haben (ggf. messbar über View-Zahlen vs. Benutzerzahl).
– Zugriff/Adoption: Anzahl neuer Lesezeichen (Favoriten), die Nutzer den Hub-Seiten geben (sofern gemessen); Anzahl Abonnements, falls Nutzer Hub-News via E-Mail abonnieren (bei SharePoint möglich, „Benachrichtigungen“).
– Performance: Durchschnittliche Ladezeit der Hub-Startseite (z.B. gemessen mit Browser DevTools für verschiedene Netzwerke oder via Monitoring-Tool); Anzahl Performance-Vorfälle (Seite sehr langsam oder nicht geladen).
– Qualität: z.B. Ergebnisse einer Nutzerumfrage (Zufriedenheitswert auf einer Skala); man kann KPI auch qualitativ erfassen wie „Hub erfüllt Benutzerbedürfnisse“ an X% Zustimmung in Befragung.

Natürlich sollten zu diesen KPIs Zielwerte definiert werden, um eine Einordnung zu ermöglichen (z.B. „Mindestens 80% der Mitarbeiter nutzen den Hub monatlich“, „Nulltrefferquote unter 5%“, „Durchschnittliche Ladezeit < 3 Sekunden“). In der Tabellen-Sammlung weiter unten ist ein beispielhaftes KPI-Set mit Zielwerten aufgeführt.

Telemetrie-Quellen: Wo kommen die Daten für diese KPIs her? SharePoint bietet out-of-the-box einige Statistiken über die Site Usage Page (Nutzerzahlen, populäre Inhalte). Für detailliertere Auswertungen kann man auf das Microsoft 365 Admin Center (Berichte für SharePoint-Aktivitäten) oder das Search & Intelligence Dashboard zurückgreifen. Auch PowerShell/Graph-API-Auswertungen sind möglich, um z.B. benutzerdefinierte Reports zu erstellen. Einige Unternehmen integrieren SharePoint-Daten in ein BI-Tool (z.B. Power BI) für ein komfortables Dashboard. Wichtig ist, dass bereits zu Beginn überlegt wird, welche Daten verfügbar sind und wie man sie sammelt (Konten für Zugriff auf die Reports, Aufbewahrung der Logs etc.). Nicht zu vergessen: Qualitatives Feedback der Nutzer kann über regelmäßige Umfragen oder Feedback-Buttons auf der Seite erhoben und in die Bewertung einbezogen werden.

Performance-Optimierung: Ein oft unterschätzter Aspekt ist die technische Performance des Hubs – niemand wartet gern lange, bis sich die Intranet-Startseite aufbaut. Einige Tipps, um die Ladezeiten im Griff zu halten:
– Webparts optimieren: Verwenden Sie nur die nötigen Webparts auf der Startseite. Insbesondere Webparts, die große Datenmengen laden (etwa ein Highlighted Content Webpart, das ungefiltert hunderte Elemente scannt), können die Ladezeit erhöhen. Beschränken Sie die Anzahl angezeigter Elemente und nutzen Sie Filter. Webparts, die nicht im sichtbaren Bereich starten (unten auf der Seite), laden asynchron – überlegen Sie, unwichtige Inhalte nach unten zu setzen.
– Bilder & Medien: Komprimieren Sie Bilder für das Web. Eine Startseite sollte keine unkomprimierten 5 MB großen Bilder laden. Nutzen Sie idealerweise JPEG/PNG in vernünftiger Auflösung oder moderne Formate wie WebP. Wenn möglich, aktivieren Sie ein CDN (Content Delivery Network) für SharePoint (Microsoft bietet Public CDN für veröffentlichte Assets), sodass Bilder und Skripte von geografisch nahegelegenen Servern kommen.
– Customizations: Sollte der Hub Anpassungen enthalten (z.B. custom SPFx Webparts oder eigene Skripte), stellen Sie sicher, dass diese performant sind und nicht unnötig viele API-Calls absetzen. Testen Sie die Seite mit Tools wie dem SharePoint Page Diagnostics Tool oder Browser-DevTools (Ladezeit, Anzahl Anfragen, Größe).
– Caching nutzen: SharePoint cached viele Inhalte serverseitig und im Browser. Ein Hub-User, der die Seite regelmäßig besucht, profitiert davon. Vermeiden Sie jedoch, ständig Änderungen am Layout vorzunehmen, die Caches entwerten könnten. Für häufig genutzte Dateien (Logos, CSS) sorgt das CDN/Browsercache automatisch für Wiederverwendung.

Ein Mindest-Dashboard für den Hub-Betrieb könnte z.B. folgende Kennzahlen auf einem Blick zeigen: Aktive Nutzer diese Woche, Seitenaufrufe, durchschnittliche Suchanfragen pro Nutzer, Top 3 geklickte News, aktuelle Ladezeit der Startseite. Dieses Dashboard kann monatlich dem Hub-Verantwortlichen Team präsentiert werden, um gemeinsam Entscheidungen abzuleiten (z.B. „Wir sehen weniger Suchen – eventuell finden Nutzer Inhalte direkt, oder die Suche wird gemieden? Müssen wir hier nachsteuern?“).

Letztlich ist der Betrieb eines Hubs ein fortlaufender Verbesserungsprozess. Durch Monitoring erkennt man Trends (steigende Nutzung = positiv, oder z.B. abnehmende News-Leserschaft = Handlungsbedarf) und durch definierte KPIs behält man das Ziel im Auge, den Hub für die Benutzer effektiv und effizient zu gestalten. Eine lernende Betriebsorganisation – die auf Basis der Daten und Feedbacks Anpassungen vornimmt – wird den Hub kontinuierlich optimieren.

10. Einführung & Migration

Die Einführung eines neuen Hub-Konzepts sollte gut geplant und schrittweise erfolgen – ein „Big Bang“ für das gesamte Intranet birgt Risiken. Daher empfiehlt sich ein Pilotvorgehen:
– Pilot-Hub definieren: Wählen Sie einen Bereich aus, der repräsentativ genug ist, aber überschaubar, um das Hub-Konzept zu erproben. Das könnte z.B. eine Abteilung wie „Marketing“ sein oder ein funktionsübergreifendes Thema wie „Projektmanagement-Office“. Wichtig: Die Pilotgruppe sollte motiviert sein und Unterstützung für das neue Konzept zeigen, damit das Feedback konstruktiv ausfällt.
– Pilot-Hub umsetzen: Bauen Sie für diese Gruppe einen Hub nach den erarbeiteten Prinzipien (Navigation, Berechtigungen, Inhalte). Migrieren oder erstellen Sie die wichtigsten Inhalte und Sites, damit ein realistisches Bild entsteht. Führen Sie die beteiligten Nutzer in das neue System ein (siehe Kommunikation & Schulung unten).
– Abnahme-Kriterien und Erfolgsmessung: Legen Sie von Anfang an fest, wann der Pilot als erfolgreich gilt. Quantitative Kriterien könnten sein: „Mindestens 80% der Marketing-Mitarbeiter nutzen den Hub nach 2 Monaten regelmäßig (>= 1x/Woche)“ oder „Die Zufriedenheit der Pilotnutzer mit der Informationsauffindbarkeit steigt von Durchschnittsnote 3 auf 2 bei der Umfrage“. Qualitative Kriterien: Feedback der Nutzer ist überwiegend positiv; identifizierte Probleme konnten behoben werden; das Management steht hinter der Lösung.
– Iterationen: Nutzen Sie die Pilotphase, um Learnings abzuleiten. Vielleicht stellt sich heraus, dass die Navigation noch nicht intuitiv genug war, oder dass die Berechtigungsprozesse angepasst werden müssen. Planen Sie mindestens einen Verbesserungszyklus ein, bevor die breite Ausrollung erfolgt.

Kommunikation und Schulung: Die Einführung eines Hubs ist auch ein Change für die Nutzer. Deshalb sollte parallel zur technischen Umsetzung ein Kommunikationsplan stehen:
– Kündigen Sie den neuen Hub frühzeitig an, idealerweise mit dem Warum (z.B. „Wir verbessern unser Intranet, damit Sie Informationen leichter finden – das neue Marketing-Portal kommt bald…“).
– Erstellen Sie Kurzleitfäden oder FAQs für Endnutzer: z.B. „So navigieren Sie im neuen Marketing-Hub“, „So funktioniert die Suche in unserem Hub“. Diese sollten in klarer Sprache und mit Bildschirmfotos die wichtigsten Bedienungsaspekte erklären.
– Bieten Sie Schulungen oder Sprechstunden an, vor allem für Redakteure und Site-Owner. Diese müssen wissen, wie sie z.B. News erstellen, Seiten bearbeiten, Audience Targeting nutzen oder auf Feedback reagieren. Ein kurzer virtueller Trainingsworkshop kann hier Wunder wirken.
– „So funktioniert dieser Hub“-Seite: Legen Sie im Hub selbst eine Seite an, die den Zweck und Aufbau des Hubs erläutert. Darin kann stehen, welche Inhalte wo zu finden sind, wer die Ansprechpartner sind (Hub Owner, Redakteure) und wie man z.B. vorgeht, wenn man eine neue Unterseite braucht oder Feedback hat. Diese Seite dient neuen Mitarbeitern als Orientierung und kann häufige Fragen direkt klären.

Vom Pilot zum Standard: Nach erfolgreichem Pilot ist die Skalierung der nächste Schritt. Hierbei sollten die Lessons Learned einfließen. Möglicherweise erstellt man jetzt eine Hub-Template oder Checklisten, damit bei jedem neuen Hub nichts vergessen wird (ähnlich wie eine „Hub-Einführungs-Checkliste“ mit allen Aufgaben von Navigation bis Schulung). Die Ausrollung könnte stufenweise nach Abteilungen oder Regionen erfolgen. Wichtig ist, den gleichen Qualitätsmaßstab überall anzulegen, damit nicht ein Bereich ein Top-Hub bekommt und anderswo ein lieblos eingerichteter entsteht. Es kann hilfreich sein, ein zentrales Hub-Governance-Team zu etablieren, das die Einführung in den einzelnen Bereichen koordiniert und beratend zur Seite steht.

Migration bestehender Sites: In vielen Fällen existieren vor der Einführung von Hubs schon zahlreiche SharePoint-Sites (oder sogar noch klassische SharePoint-Seiten, ggf. On-Premises). Diese gilt es sinnvoll in die neue Hub-Struktur zu überführen:
– Bestandsaufnahme: Listen Sie alle vorhandenen Sites und Inhalte auf, die ins neue Konzept übergehen sollen. Gruppieren Sie sie nach inhaltlicher Zugehörigkeit. Dies bildet die Grundlage für das Mapping zu Hubs.
– Mapping auf Hubs: Entscheiden Sie, welche bestehende Site in welchen Hub eingegliedert wird. Dabei können Sie sich an der neuen Informationsarchitektur orientieren. Beispiel: Eine bestehende Teamseite „Vertrieb DE“ wird künftig Teil des „Vertrieb Europa-Hub“. Falls es Inhalte gibt, die keinem der definierten Hubs eindeutig zuordenbar sind, ist zu entscheiden, ob man dafür einen neuen Hub schafft, sie einem verwandten Hub zuordnet oder sie als eigenständige Site belässt. Letzteres sollte die Ausnahme sein, da das Ziel ja eine konsolidierte Navigation ist – aber es gibt Fälle, wo eine sehr isolierte Site (z.B. Vorstand intern) bewusst nicht in einen allgemeinen Hub aufgenommen wird.
– Migration der Inhalte: Hier kommen die klassischen Migrationsmethoden ins Spiel. Möglich sind z.B. ein Kopieren/Neuanlegen von Inhalten (wenn man gleichzeitig von klassischen zu modernen Seiten wechselt, ist oft Neuerstellung mit Copy-Paste sinnvoll), der Einsatz von Migrationstools (Microsoft SharePoint Migration Tool, Drittanbieter-Tools), oder Skripte mit PnP PowerShell für Massenmigration. Jede Option hat Vor- und Nachteile hinsichtlich Aufwand, Meta-Daten-Erhalt etc. In einem Hub-Kontext ist wichtig, die URL-Struktur zu beachten: Wenn z.B. eine alte Subsite „/dept/marketing“ zu einer eigenen Sitecollection wird, ändert sich der Pfad. Planen Sie Redirects ein, damit Benutzerfavoriten nicht ins Leere laufen. SharePoint bietet für Verschiebungen innerhalb der Cloud teils automatische Umleitungen, aber man sollte das verifizieren und ggf. über Custom Redirects (z.B. via Azure AD Proxy oder ähnlichem) nachhelfen.
– Umgang mit Ausnahmen: Falls bestimmte Inhalte nicht migriert werden (z.B. weil sie obsolet sind oder aus Compliance-Gründen nicht in die Cloud dürfen), dokumentieren Sie diese Entscheidung. Kommunizieren Sie gegenüber den Nutzern, wo diese Inhalte künftig zu finden sind oder ob sie archiviert wurden. Jede Lücke in der neuen Struktur kann sonst Unsicherheit erzeugen („Wo ist denn jetzt die Seite XY geblieben?“). Im Idealfall gibt es keine ungeklärten Fälle – ansonsten sollte ein Übersichtsseite „Weitere Inhalte“ im Intranet vorgehalten werden, wo z.B. auf Archivsysteme oder Nicht-M365-Plattformen verlinkt wird.

Die Einführungsphase sollte eng begleitet werden von Change Management: Holen Sie Feedback der ersten Nutzer ein, passen Sie schnell an, was unklar ist, und feiern Sie auch Erfolge („Heute hat sich bereits 1000. Mitarbeiter im neuen Intranet angemeldet.“). Mit transparentem Fortschritts-Tracking (z.B. „Wir sind jetzt bei Rollout 3 von 5 – Asien ist als nächstes dran“) halten Sie alle Beteiligten informiert und vermeiden Verunsicherung.

Abschließend gilt: Nach der Migration ist vor der Optimierung. Planen Sie nach dem Go-Live nochmals eine Phase ein, in der Sie intensives Monitoring betreiben (siehe KPIs) und die Struktur feinjustieren. Oft zeigen sich erst im Echtbetrieb manche Optimierungspotenziale. Durch die iterative Einführung und Migration in Tranchen stellen Sie sicher, dass am Ende ein durchdachtes, erprobtes Hub-System für das gesamte Unternehmen steht.

11. Tabellen-Sammlung

a) Funktionen & Grenzen von Hubs
Diese Tabelle zeigt die zentralen Hub-Funktionen und was dabei beachtet werden muss (Grenzen oder besondere Hinweise):

b) Vergleich: Hub vs. alternatives Intranet-Muster
Verglichen wird die Nutzung eines Hub-Konzepts mit einer klassischen Alternative (eine einzelne zentrale Kommunikationssite mit Unterseiten oder separate Sites ohne Hub-Verknüpfung):

c) RACI-Matrix für Hub-Betrieb und -Governance
Die folgende Tabelle zeigt ausgewählte Aufgaben im Hub-Management und welche Rolle dafür Responsible (R), Accountable (A), Consulted (C) oder Informed (I) ist:

(Hinweis: R = Responsible (Durchführungsverantwortlich), A = Accountable (Endverantwortlich), C = Consulted (konsultiert), I = Informed (zu informieren). In jeder Zeile sollte mindestens ein A und ein R vorhanden sein.)

d) KPI-Set für Hub-Betrieb (mit Zielwerten)
Beispielhafte Kennzahlen zur Erfolgsmessung eines Hubs und angestrebte Ziele:

(Tatsächliche Zielwerte sollten an die Unternehmensgröße und den Hub-Zweck angepasst werden. Wichtig ist, Trends zu beobachten.)

e) Risiko-Matrix und Maßnahmenplan
Typische Risiken bei Planung und Betrieb eines Hubs, mit Bewertung der Eintrittswahrscheinlichkeit, Auswirkungsstärke und vorgesehenen Gegenmaßnahmen:

f) Checkliste „Hub Go-Live“ (Bereitschafts- & Abnahmekriterien)
Vor dem Livegang eines neuen Hubs sollte sichergestellt sein, dass alle wichtigen Punkte erledigt sind:

(Diese Checkliste kann erweitert werden. Sie dient dazu, ein gemeinsames Verständnis zu haben, wann ein Hub „fertig“ für den Start ist – analog einer Definition of Done.)

12. Fünf ausführliche Anwendungsbeispiele

Beispiel 1: Konzern-Intranet mit funktionalen Hubs und zentralem Corporate-Hub

Ausgangslage: Die ACME AG (fiktives Unternehmen) mit ~5.000 Mitarbeitern an global verteilten Standorten hatte ein klassisches Intranet, das aus einer zentralen Startseite und vielen einzelnen Bereichsseiten bestand. Jede Abteilung pflegte ihre Inhalte mehr oder weniger eigenständig, die Navigation war uneinheitlich und Nutzer beschwerten sich über mangelnde Auffindbarkeit. Insbesondere wünschte man sich einerseits eine zentrale Anlaufstelle für Unternehmensnachrichten und wichtige Ankündigungen (Corporate News), andererseits bereichsspezifische Portale für Abteilungen wie IT, Finanzen, Vertrieb etc. ACME entschied sich für einen Neuaufbau des Intranets mit SharePoint Online und dem Hub-Site-Konzept.

Zielbild: Das Ziel war ein zweistufiges Intranet: Ein Corporate-Hub als oberster Einstieg mit allgemeinen Inhalten (Unternehmensstrategie, CEO-Blog, zentrale News) und darunter mehrere funktionale Hubs für die Hauptbereiche (z.B. einen HR-Hub, einen IT-Hub, einen Vertriebs-Hub, usw.). Jeder Mitarbeiter sollte über den Corporate-Hub Zugang zu allen wichtigen Themen finden, gleichzeitig aber in seinem Fachbereich einen dedizierten Raum mit vertiefenden Infos vorfinden. Die Navigation und das Design sollten konsistent sein, sodass man sofort merkt, dass alle Bereiche Teil des gleichen Intranets sind. Die Auffindbarkeit von Informationen – egal ob über Navigation oder Suche – sollte deutlich verbessert werden. Außerdem galt es, die redaktionelle Verantwortung klar zu verteilen: Die Unternehmenskommunikation steuert den Corporate-Hub, während die Fachabteilungen ihre Hubs eigenverantwortlich pflegen.

Architektur/Topologie: ACME hat den Corporate-Hub als Parent-Hub definiert, und alle funktionalen Hubs (IT, HR, Finanzen, Vertrieb, F&E usw.) als Child-Hubs damit verknüpft. Technisch gesehen wurde jeweils eine moderne Kommunikationssite pro Hub angelegt und vom IT-Admin mittels SharePoint Admin Center zum Hub deklariert. Der Corporate-Hub lag z.B. unter der URL intranet.acme.com, die funktionalen Hubs entsprechend unter intranet.acme.com/hr, …/it etc. Durch die Parent-Child-Verknüpfung konnte ACME sicherstellen, dass die Suche vom Corporate-Hub aus alle Inhalte der untergeordneten Hubs umfasst. Umgekehrt konnten Nutzer, die sich z.B. im HR-Hub befinden, zunächst nur innerhalb HR suchen (was dort standardmäßig so eingestellt ist), hatten aber die Möglichkeit, die Suche auf das ganze Intranet (alle Hubs) auszuweiten, ohne die Seite wechseln zu müssen. Die Hub-Architektur blieb bewusst zweistufig; man verzichtete darauf, weitere Unter-Hubs einzuführen, um die Struktur flach und verständlich zu halten.

Navigation: Die Gestaltung der Navigation erfolgte nach dem Prinzip „global einheitlich, lokal spezialisiert“. Das heißt, es wurde eine globale Navigationsleiste (über die SharePoint-App-Bar) eingerichtet, in der alle Hubs des Intranets aufgeführt sind: Startseite, HR, IT, Finanzen, Vertrieb, usw., sowie einige globale Links (Helpdesk, Telefonbuch). Diese globale Navigation ist überall sichtbar und bietet die erste Orientierung. Innerhalb jedes Hubs gibt es dann die Hub-Navigation, die spezifisch für den Bereich ist. Beispielsweise hat der HR-Hub Menüpunkte wie „Benefits“, „Karriereentwicklung“, „Weiterbildung“, während der IT-Hub Punkte wie „IT-Services“, „Projekte“, „Anwendungen A-Z“ hat. ACME achtete darauf, dass gewisse Parallelen in der Struktur bestehen – etwa hat jeder Hub einen Menüpunkt „News“ und „Teams“, damit die Nutzer in jedem Bereich ähnliche Anlaufstellen haben. Die Navigationspunkte wurden in enger Absprache mit den Fachabteilungen festgelegt und vor Go-Live mit einer Testgruppe von Mitarbeitern erprobt (Card-Sorting-Übung, Test der Verständlichkeit). Audience Targeting wurde in geringem Maße eingesetzt: Zum Beispiel existiert im HR-Hub ein interner Link „HR-Team Intern“, der nur für HR-Mitarbeiter sichtbar ist (damit nicht alle anderen ins Leere laufen). Die Freigabe der Navigation erfolgte durch ein Gremium aus Vertretern aller Hubs, um sicherzustellen, dass kein Widerspruch oder redundante Begriffe zwischen den Bereichen entstehen.

Suchkonzept: Durch die Parent-Hub-Struktur ist die Suche auf Corporate-Ebene in der Lage, alle Inhalte aller Hubs zu durchsuchen. ACME hat zudem im Microsoft Search Admin Center sogenannte Bookmarks eingerichtet: Gibt ein Nutzer im Suchfeld z.B. „Urlaub“ ein, erscheint als erstes Ergebnis ein Link zur Urlaubbeantragung im HR-Hub (unabhängig davon, in welchem Hub gesucht wurde, da dies als org-weites Lesezeichen konfiguriert ist). Auch häufige Fragen wie „Reisekosten“ oder „Spesenformular“ wurden mit Q&A-Einträgen versehen, die auf die entsprechenden Hub-Seiten verweisen. Allerdings stellte ACME fest, dass viele Nutzer zunächst gar nicht die Suchfunktion nutzten, sondern über die Navigation gingen. Deshalb wurden an kritischen Stellen Querverweise geschaffen: Auf der Corporate-Startseite befindet sich ein prominentes Suchfeld mit dem Hinweis „Durchsuchen Sie das gesamte Intranet“, um die globale Suche zu fördern, während auf den Fach-Hub-Startseiten jeweils ein kurzer Abschnitt „Häufig gesuchte Themen“ mit Links zu populären Inhalten anderer Hubs steht (eine Art manuelle Quick-Links-Sektion). Restricted Search setzte ACME nicht ein, da das Intranet bewusst offen sein sollte und keine hochsensiblen Daten enthielt, die man vor der Suche ausschließen müsste – stattdessen wurden sensible Inhalte schlicht nicht in diese Hubs integriert.

News/Rollup: Für die Unternehmenskommunikation war es essenziell, dass wichtige Neuigkeiten vom Corporate-Hub aus „heruntergebrochen“ und zugleich von unten nach oben „hochgerollt“ werden können. Um dies zu erreichen, wurde ein dualer Ansatz gewählt:
– Auf der Corporate-Startseite gibt es einen zentralen News-Bereich „Aus den Bereichen“, der mit dem News-Webpart realisiert wurde. Hier wählte man als Quellen gezielt die News-Seiten der Fach-Hubs aus (HR, IT, etc.). Wenn also der HR-Hub eine News „Neuer Head of HR stellt sich vor“ veröffentlicht, taucht diese automatisch auch auf der Corporate-Seite in „Aus den Bereichen“ auf. Die Corporate-Kommunikation behält redaktionell die Kontrolle, indem sie bestimmen kann, welche Hubs angezeigt werden und notfalls Beiträge ausblenden kann (Webpart-Filter nach Schlagwort „TopNews“ beispielsweise).
– Umgekehrt gibt es Themen, die von oben nach unten verteilt werden: Corporate-News (z.B. Quartalszahlen, wichtige Ankündigungen vom Vorstand) sollen auch in den Bereichs-Hubs sichtbar sein, damit Mitarbeiter, die primär ihren Fach-Hub besuchen, nichts verpassen. Dazu hat man einen „Corporate News“-Webpart auf jeder Hub-Startseite eingebunden, der News von der Corporate-Site anzeigt. Technisch wurde dies durch ein zentrales Label gelöst: alle Corporate-News sind mit der Kategorie „Unternehmensnews“ versehen, und die Bereichsseiten blenden genau diese per Highlighted Content Webpart ein.
– Dadurch entstand ein vernetzter News-Lebenszyklus: Bereichsnews erscheinen oben, und Top-News von oben erreichen unten alle Mitarbeiter. Eine Dublettenproblematik trat nicht auf, weil klar getrennt ist, welche Webparts welche Quellen bedienen.

Berechtigungen: ACME verfolgte die Philosophie „so offen wie möglich, so geschlossen wie nötig“. Das bedeutet, dass alle inhaltlichen Hubs grundsätzlich für alle Mitarbeiter lesbar sind. Realisiert wurde das, indem in jeder Hub-Site die Gruppe „Alle Benutzer (außer Externe)“ als Besucher mit Leserechten eingetragen wurde. Die IT hat hierfür via Skript die Hub-Berechtigungssynchronisation verwendet: Im Corporate-Hub wurde die globale „Alle Mitarbeiter“-Gruppe als Hub-Visitor definiert und auf alle zugehörigen Sites synchronisiert. Für die Child-Hubs (IT, HR etc.) hat man sich teils dagegen entschieden, die Synchronisation zu aktivieren – denn in einigen Hubs gab es auch vertrauliche Teilbereiche. Stattdessen wurden diese Hubs offen gelassen, aber die vertraulichen Seiten innerhalb eines Hubs mit eigenen Berechtigungen versehen oder gar nicht im Hub verlinkt. Zum Beispiel existierte im IT-Hub ein Projektraum für ein geheimes Projekt, der nicht in der Hub-Navigation auftauchte und nur für das Projektteam freigegeben war. Security Trimming sorgte dafür, dass Inhalte daraus auch nicht in der Hub-Suche anderer auftauchten. Externe Zugriffe waren im normalen Intranet nicht vorgesehen – dafür hat ACME separate Extranet-Sites, die nicht Teil dieser Hubs sind.

Governance/Compliance: ACME etablierte ein Intranet-Steuerungsteam, das aus dem Corporate-Intranet-Manager (Leiter Unternehmenskommunikation), den jeweiligen Hub-Ownern der Fachbereiche (meist jemand aus dem Bereich, z.B. HR-Manager für HR-Hub) und einem IT-Ansprechpartner bestand. Dieses Team traf sich quartalsweise, um die Hub-Performance durchzugehen (Nutzungszahlen, Feedback) und gemeinsame Standards zu überprüfen. Es wurden beispielsweise KPI-Berichte angeschaut, die zeigten, welcher Hub wie stark frequentiert wurde und wo evtl. die Suche oft versagte. Compliance-seitig waren die Inhalte eher unkritisch (öffentlichkeitsfähige Inhalte oder interne Informationen ohne strenge Reglementierung). Nichtsdestotrotz achtete man auf Aufbewahrungspflichten: Die Rechtsabteilung verlangte, dass alle veröffentlichten News für 5 Jahre abrufbar bleiben (Nachweis der Mitarbeiterinformation). Daher wurde ein News-Archiv eingerichtet, wo ältere News-Seiten automatisiert via Flow mit einem „Archiv“ Label versehen und gelagert wurden, anstatt sie zu löschen. Sensitivity Labels waren nicht im Einsatz auf diesen Hubs, weil alles als „Intern allgemein“ klassifiziert war.

Betrieb/KPIs: Nach Launch des neuen Hub-Intranets überwachte ACME einige Schlüssel-KPIs: So stieg die Nutzerreichweite rapide an – binnen des ersten Monats loggten sich 90% der Mitarbeiter mindestens einmal ein, was deutlich über dem alten Intranet lag. Besonders erfreulich: Die durchschnittliche Verweildauer auf dem HR-Hub stieg um 50%, was ACME als Indikator wertete, dass Inhalte gefunden und gelesen wurden (z.B. neue HR-Richtlinien). Die Suchanfragen nahmen ebenfalls zu; anfangs gab es noch ca. 15% Suchen ohne Treffer, doch durch Ergänzen von Synonymen (z.B. Suche nach „Urlaub“ liefert jetzt auch Treffer zur „Abwesenheitsverwaltung“) sank dies auf unter 5%. ACME definierte als Erfolg, dass die Zufriedenheit der Mitarbeiter mit dem Intranet (gemessen durch eine Umfrage nach 6 Monaten) auf Note 2,0 oder besser liegen sollte – tatsächlich wurde mit 1,8 dieses Ziel übertroffen. Im Betrieb zeigte sich, dass regelmäßige Abstimmungen zwischen den Hub-Redaktionen sinnvoll waren: z.B. tauschten sich die HR- und IT-Redakteure monatlich aus, ob es bereichsübergreifende News gibt, die man gemeinsam gestalten sollte (etwa eine News zur neuen HR-Software brachten HR und IT abgestimmt heraus). Risiken & Lessons Learned: Ein Risiko war zu Beginn die Komplexität für die Redakteure – es gab Klagen, warum man eine News zweimal anlegen müsse (oben und unten). Man reagierte, indem man Schulungen zur Handhabung der News-Webparts anbot und klar kommunizierte, wann man eine Corporate-News versus eine Bereichsnews nutzt. ACME lernte, dass zentraler Content (wie Unternehmensleitlinien) am besten auf dem Corporate-Hub belassen und von dort referenziert wird, statt Kopien in jedem Fach-Hub vorzuhalten – das hatte man anfangs versucht (jede Abteilung kopierte Teile des Mitarbeiterhandbuchs in ihren Hub), was aber schnell zu Inkonsistenzen führte. Dieses Beispiel zeigt, dass ein funktionales Hub-Modell mit zentralem Dach sehr gut funktionieren kann, wenn Navigation und Suche richtig umgesetzt sind und die beteiligten Rollen koordiniert zusammenarbeiten.

Beispiel 2: Projekt- und Portfolio-Hub für Projekte mit Vorlagen und Übergabe

Ausgangslage: Die Contoso GmbH (fiktiv) hat dutzende laufende Projekte gleichzeitig – von kleinen Verbesserungsinitiativen bis zu großen Kundenprojekten. Bisher wurden Projektinformationen dezentral verwaltet: Manche Teams nutzten eigene Team-Sites, andere speicherten alles in Teams oder sogar File Shares. Das Management hatte kaum Überblick über alle Projekte, und nach Projektende gingen wertvolle Dokumentationen oft verloren oder waren schwer auffindbar. Es gab den Wunsch nach einer einheitlichen Projekt- und Portfolio-Plattform, wo alle Projekte nach standardisiertem Muster abgebildet sind, und am Ende die Ergebnisse an die Linienorganisation übergeben werden können.

Zielbild: Contoso entschied sich für einen Projekt-Portfolio-Hub als zentrale Anlaufstelle für alle Projekte. Dieser Hub sollte:
– Vorlagen und Standards für neue Projekt-Sites bereitstellen (damit jedes Projekt z.B. eine Risks-Liste, ein Dokumentenablagestruktur, etc. hat).
– Einen Überblick über alle laufenden Projekte bieten (Portfolio-Dashboard).
– Nach Projektabschluss eine strukturierte Übergabe an die Fachbereiche ermöglichen (Knowledge Transfer).
– Breite Sichtbarkeit sicherstellen: Mitarbeiter aus dem ganzen Unternehmen sollten zumindest lesen können, was in Projekten passiert (sofern nicht vertraulich), um aus Erfahrungen zu lernen und Doppelarbeit zu vermeiden.

Architektur/Topologie: Implementiert wurde ein einziger Hub namens „Project Portfolio“, unter dem alle Projekt-Sites angesiedelt werden. Jeder Projektleiter, der ein neues Projekt startet, kann über ein automatisiertes Verfahren (mittels Power Automate und einem Site Design) eine neue Team-Site erstellen lassen, die automatisch dem Project-Portfolio-Hub zugeordnet wird. Diese Site erhält vordefinierte Listen (Tasks, Risiken, Entscheidungen) und Bibliotheken (Projektdokumente, Berichte, Lessons Learned) basierend auf einer Vorlage. Der Hub selbst ist als Kommunikationssite angelegt, die Meta-Informationen zum gesamten Portfolio enthält, wie z.B. ein Projektkatalog und Gesamtstatusberichte. Es gibt keine Parent-Child-Relation zu anderen Hubs, da dieser Hub für sich steht (rein projektfokussiert). Die Zahl der Projekte (Sites) unter dem Hub kann dynamisch wachsen – Contoso rechnete mit ca. 100 Projektsites gleichzeitig.

Navigation: Die Hub-Navigation des Project-Portfolio-Hubs wurde in zwei Bereiche aufgeteilt: Zum einen Portfolio-Übersicht (Seiten wie „Alle Projekte“, „Projektpipeline“, „Ressourcen & Templates“, „Best Practices“), zum anderen Projektspezifische Navigation. Da es unpraktisch wäre, jeden einzelnen Projekt-Namen im Menü zu führen (bei 100+ Projekten), entschied man sich für eine andere Lösung: In der Hub-Navigation gibt es einen Menüpunkt „Projekte A-Z“, der auf eine Seite führt, wo alle Projekte als Liste aufgeführt und verlinkt sind. Zusätzlich wurden Filter (nach Abteilung, Status, Jahr) angeboten, damit Nutzer schnell ein Projekt finden können. Einzelne besonders wichtige Projekte (Top 5 strategische) bekamen jedoch Direktlinks in der Navigation unter „Top-Projekte“. Das Menü „Ressourcen & Templates“ enthielt Unterpunkte wie „Projektvorlage herunterladen“, „PMO-Richtlinien“, „Tools & Formulare“. So fanden Projektleiter an zentraler Stelle alles, was sie für die Abwicklung brauchten. Audience Targeting wurde hier kaum benötigt, da die Inhalte grundsätzlich allen intern zugänglich sein sollten. Nur im Abschnitt „Best Practices“ gab es einen Bereich „Interne Lessons Learned“ mit sensiblen Analysen, der nur für Mitarbeiter mit PMO-Rolle sichtbar war.

Suchkonzept: Die Suche im Project-Portfolio-Hub wurde darauf optimiert, dass Nutzer sowohl nach Projektnamen als auch nach Projektdokumenten suchen können. Durch die Hub-zugehörigkeit aller Projektsites reicht eine Suche im Hub-Kontext aus, um alle Projektseiten und -dokumente zu durchsuchen. Contoso ergänzte die Microsoft Search mit Synonymen: z.B. „PRJ123“ sollte auch Treffer für „Projekt Phoenix (PRJ123)“ liefern, obwohl der Spitzname und der formale Code unterschiedlich sind. Auch Abkürzungen wie „BRD“ (für Business Requirements Document) wurden hinterlegt, damit die entsprechenden Dokumente gefunden werden. Ein besonderes Feature war die Nutzung von Ergebnis-Vertikalen: Contoso erstellte eine benutzerdefinierte Vertikale „Projektdokumente“, die ausschließlich Dokumente aus den Projektbibliotheken filtert, und eine Vertikale „Projektsites“, die nur die Projekt-Homepage jeder Site anzeigt. So konnten Nutzer z.B. schnell alle Projekt-Kickoff-Präsentationen finden, indem sie in „Projektdokumente“ nach „Kickoff“ suchten. Restricted Search kam nicht zum Einsatz, weil Transparenz gewünscht war – außer für ein paar vertrauliche Projekte. Diese Projekte wurden allerdings gar nicht erst dem Hub hinzugefügt (z.B. ein M&A-Projekt blieb separat mit eigenem privaten Site, um keine Spuren im allgemein zugänglichen Hub zu hinterlassen).

News/Rollup: Der Project-Portfolio-Hub setzte News in Form eines „Project Spotlight“ ein. Jeden Monat wurde ein bestimmtes Projekt auf der Hub-Startseite vorgestellt (z.B. „Projekt des Monats: Modernisierung ERP“). Diese News-Beiträge wurden vom PMO-Team verfasst und erschienen hubweit. Darüber hinaus hatten Projekte die Freiheit, auf ihrer eigenen Projekt-Site News zu posten (etwa „Go-Live Phase 1 erreicht“). Um diese dezentralen News sichtbar zu machen, wurde auf der Hub-Seite ein News-Webpart mit Quelle „Alle Sites in diesem Hub“ konfiguriert. So erschienen neue Projekt-News automatisch auf der Portfolio-Startseite in einer Übersicht „Aktuelles aus den Projekten“. Dabei musste Contoso beachten, dass nicht zu viele Meldungen auf einmal kamen – das PMO richtete Regeln ein, dass jedes Projekt maximal 2 News pro Monat veröffentlichen sollte, und moderierte die News-Übersicht (notfalls via Filter Webpart gezielt steuern). Dubletten waren hier kein Problem, eher die Flut begrenzen: Wenn 50 Projekte gleichzeitig berichten, würde niemand mehr durchblicken. Daher entwickelte Contoso ein Tagging-System: Projekte markierten ihre News mit Kategorien (z.B. „Meilenstein erreicht“, „Problem/Risiko“, „Erfolgsgeschichte“), und die Hub-News-Übersicht filterte standardmäßig nur auf „Erfolgsgeschichte“ und „Meilenstein“. So erschienen primär positive, wichtige Meldungen. Wer tiefer einsteigen wollte, konnte die Filter manuell lösen und alle News sehen.

Berechtigungen: Eines der Ziele war es, möglichst breite Leserechte zu haben, damit jeder im Unternehmen aus anderen Projekten lernen kann. Deshalb wurden alle Projektsites so angelegt, dass alle internen Mitarbeiter Leserzugriff haben. Technisch wurde dies über die Hub-Berechtigungssynchronisation erreicht: Im Project-Portfolio-Hub ist die Gruppe „Contoso Belegschaft“ als Besucher eingetragen und auf alle Projekt-Sites propagiert. Somit konnten theoretisch alle Mitarbeiter jede Projektsite aufrufen und die Inhalte lesen. Schreibrechte hatten natürlich nur die jeweiligen Projektteams (über eine Microsoft 365-Gruppe pro Site oder dedizierte Berechtigungsgruppen). Es gab wenige Ausnahmen: Falls ein Projekt vertraulich war (z.B. Personalabbau-Planung), wurde es nicht dem Hub zugeordnet. Ein solches Projekt lief dann „unter dem Radar“. Contoso entschied bewusst, solche Ausnahmen minimal zu halten, um die Transparenzkultur zu fördern. Für externe Partner gab es die Möglichkeit, gezielt auf einzelne Projektsites eingeladen zu werden (z.B. ein Berater mit Zugriff auf eine Projektsite); diese Sites behielten aber den Hub-Zusammenhang. Die Navigation blendete diesen Partnern die Hub-Leiste nicht aus (ging technisch nicht anders), aber über Audience Targeting wurde zumindest der Link „Alle Projekte“ verborgen, sodass Externe nicht die Gesamtübersicht hatten.

Governance/Compliance: Der Project-Portfolio-Hub wurde vom PMO (Project Management Office) betreut. Das PMO-Team stellte sicher, dass alle neuen Projekte richtig angelegt wurden (sie prüften z.B. die Nutzung der Vorlage und halfen bei Bedarf nach). Sie etablierten ein Site Lifecycle: Projekt-Sites wurden bei Abschluss archiviert (schreibgeschützt und mit einem Tag „Abgeschlossen“ versehen, blieben aber lesbar im Archiv-Bereich des Hubs). Nach 2 Jahren wurden archivierte Sites komplett entfernt/exportiert, gemäß der Projektarchivierungsrichtlinie. Dies alles war im Governance-Dokument festgehalten. Aufbewahrungstechnisch galt: Projektdokumente, die relevant für das Unternehmenswissen sind, sollten in ein zentrales Wissensarchiv überführt werden. In der Praxis bedeutete dies, dass am Projektende die Lessons Learned Dokumentation und ggf. wichtige Deliverables in eine separate Knowledge Base (im Intranet-Hub des jeweiligen Fachbereichs) kopiert wurden. Der Hub unterstützte diesen Prozess durch Checklisten und Automatisierung (eine Flow-Schaltfläche „Projekt abschließen“ schickte eine Aufgabe an das PMO, all das zu tun). Compliance-seitig gab es bei Projekten vor allem das Risiko, dass vertrauliche Daten (z.B. Kundenlisten) versehentlich für alle intern sichtbar waren. Hier vertraute man auf die Sensibilisierung der Projektleiter – in Schulungen wurde klar gemacht, dass wer z.B. Personalakten in ein Projektraum hochlädt, eventuell vielen Lesern Zugriff gewährt. Zusätzlich richtete Contoso eine DLP-Regel ein, die in Projektsites Kreditkartennummern und Gesundheitsdaten detektiert und blockiert (um zumindest offensichtlich heikle Daten abzufangen).

Betrieb/KPIs: Das PMO verfolgte als Haupt-KPI die Projektdisziplin: z.B. wie viele Projekte nutzen die Standardvorlagen (Ziel 100%), wie viele Projekte liefern am Ende einen Lessons Learned Bericht ab (Ziel >90%). Außerdem wurde geschaut, ob die Nutzerzahlen steigen – Contoso wollte, dass nicht nur Projektmitglieder, sondern auch andere Mitarbeiter regelmäßig im Hub stöbern. Tatsächlich zeigten die Zahlen nach 6 Monaten, dass durchschnittlich 1.000 Mitarbeiter pro Monat den Project-Portfolio-Hub besuchten, obwohl nur 300 in Projektteams aktiv waren. Das wertete man als Erfolg, da Wissen aus Projekten offensichtlich abgerufen wurde. Die Suchstatistik zeigte, dass häufig nach Projektkürzeln und nach Dokumenttypen gesucht wurde („Projektplan“, „Budget Excel“). Das PMO nutzte diese Daten, um die Vorlage weiter zu verbessern (man stellte z.B. ein Standard-Budget-Excel bereit, nachdem klar war, dass das ein häufiges Suchobjekt war). Risiken & Lessons Learned: Ein Risiko war die anfängliche Zurückhaltung mancher Projektleiter, alles offen zu legen. Einige hatten Bedenken, dass z.B. negative Projektnachrichten öffentlich werden. Das Management begegnete dem mit einer offenen Kultur: Man ermunterte dazu, auch Probleme zu teilen, damit andere daraus lernen können, und stellte klar, dass keine „Schuldzuweisungen“ erfolgen. Ein anderes Problem war die Überinformation: Manche Mitarbeiter fühlten sich von der Fülle an Projektmeldungen erschlagen. Hier justierte Contoso nach, indem es opt-out Mechanismen anbot (z.B. Newsletter-Abos nur für bestimmte Projektkategorien) und die Hub-Startseite auf wirklich wesentliche Infos beschränkte. Insgesamt hat dieses Beispiel gezeigt, dass ein Hub als Projektportfolio wunderbar funktioniert, wenn klare Prozesse für Start und Ende von Sites da sind und eine zentrale Stelle (PMO) die Zügel in der Hand hält. Besonders die Übergabe der Projektergebnisse an die Linie wurde mit dem Hub deutlich verbessert, weil die Fachbereiche nun eine definierte Anlaufstelle haben, um auf Projektdokumentation zuzugreifen.

Beispiel 3: Regionales Multi-Geo-Hub-Netz (Europa, Nordamerika, APAC) mit Parent-Hub

Ausgangslage: GlobalCorp (fiktives Unternehmen) operiert weltweit und unterliegt verschiedenen lokalen Anforderungen. Das Unternehmen hat Standorte in Europa, Nordamerika und Asien-Pazifik (APAC). Bisher gab es ein zentrales Intranet in den USA gehostet, worauf aber z.B. die europäischen Mitarbeiter aufgrund Latenz und teilweise Sprachausgaben in Englisch nur begrenzt zugriffen. Zudem mussten bestimmte Inhalte aus Datenschutzgründen in der EU gespeichert werden (Stichwort DSGVO). GlobalCorp entschloss sich, auf Microsoft 365 Multi-Geo zu migrieren und ein regionales Hub-Konzept einzuführen, das sowohl globale Kommunikation ermöglicht als auch regionale Autonomie gibt.

Zielbild: Das Ziel war ein mehrstufiges Hub-Netz:
– Globaler Corporate-Hub: Eine zentrale Seite (Home) mit unternehmensweiten News, Strategie, Führungskommunikation – primär in Englisch.
– Regionale Hubs: Je ein Hub für EMEA (Europa/Mittlerer Osten/Afrika), Americas (Nord- und Südamerika) und APAC (Asien/Pazifik). Diese sollen lokale News, lokale HR-Infos, Standortseiten und regionale Kollaborationsthemen abdecken und idealerweise in Landessprachen oder regionstypischer Geschäftssprache gepflegt sein.
– Jeder Region-Hub wiederum kann lokale Sites (z.B. Länderseiten oder Standortseiten) beinhalten.
– Parent-Child-Verknüpfung: Der Global-Hub sollte als Parent fungieren, damit Suchanfragen über alle Regionen hinweg möglich sind und eine gewisse Verbindung existiert. Gleichzeitig sollte die Navigation nicht automatisch alles vermischen – d.h. Nutzer in Europa sehen primär ihren EU-Inhalt, haben aber Zugriff auf globales bei Bedarf.

Architektur/Topologie: GlobalCorp setzte dieses Modell wie folgt um: Drei Geo-Standorte in Microsoft 365 (EU, US, Asia) wurden genutzt, um Datenresidenz sicherzustellen. In jeder Geo wurde eine Kommunikationssite als Regional-Hub erstellt: z.B. EMEA Hub in der EU-Geo, Americas Hub in der US-Geo, APAC Hub in der Asia-Geo. Zusätzlich wurde in der US-Geo (Haupt-Tenant) die zentrale Global Hub Site erstellt und mittels SharePoint Admin Center als Hub registriert. Dann wurden die drei Regional-Hubs als Child-Hubs dem Global-Hub zugeordnet (Parent-Child). Dadurch entstand eine Hierarchie: Global (Level 1) -> EMEA/Americas/APAC (Level 2). Die Regional-Hubs selbst enthielten wiederum lokale Sites, aber GlobalCorp entschied, keine weitere Hub-Ebene darunter mehr einzuführen (also z.B. Länder wurden nicht als eigene Hubs definiert, sondern als normale Sites unter dem Regions-Hub, um die Tiefe zu begrenzen). Datenresidenz: Inhalte, die Europa-bezogen sind, liegen physisch in der EU (im EMEA-Hub und dessen Sites), likewise für APAC in Asia – so erfüllte man die Auflagen, dass z.B. persönliche Mitarbeiterdaten der Europäer nicht in die USA übertragen werden müssen.

Navigation: Die Herausforderung war, globale und regionale Navigation zu kombinieren. GlobalCorp löste es so:
– Der Global-Hub hat eine Navigation mit übergeordneten Punkten, die eher funktional sind (ähnlich wie im Beispiel 1: z.B. „Über uns“, „News“, „Strategy“, „Produkte“ etc.). Ein Punkt darin heißt „Regionen“, unter dem die drei Region-Hubs verlinkt sind (Europa, Americas, APAC). Diese Links wurden mittels der Funktion „Associated hubs“ halbautomatisch ins Menü gebracht.
– Jeder Region-Hub hat seine eigene Navigation mit lokalen Menüpunkten. Beispielsweise der EMEA-Hub hat Menüs in Deutsch, Französisch etc. (GlobalCorp entschied, pro Region eine Hauptsprache zu nutzen plus ggf. zweisprachige Inhalte: EMEA in Englisch/Deutsch gemischt, APAC in Englisch/Chinesisch gemischt). Die Region-Hub-Navigation enthält lokale Themen: z.B. „Standorte“ (mit Unterpunkten Berlin, London, Dubai etc.), „Lokale HR-Infos“, „Regional News“. – Wichtig: In der Region-Navigation gibt es immer einen Link zurück zum Global-Hub („Global Home“) damit Benutzer leicht wieder zur globalen Ebene gelangen. Ebenso hat der Global-Hub in der Navigation, wie erwähnt, die Links zu allen Regionen.
– Audience Targeting kam hier vor allem für Sprachen zum Einsatz: Im EMEA-Hub hat man z.B. einige Links nur für die Gruppe „Mitarbeiter Deutschland“ sichtbar gemacht (wenn es um deutschsprachige Inhalte geht), während der Default in Englisch sichtbar war. – Zusätzlich verwendete man die Fußzeile global einheitlich (in allen Hubs die gleiche Footer-Navigation mit Impressum, Datenschutzerklärung auf Englisch und Verlinkung der lokalen Varianten).

Suchverhalten: Durch die Parent-Hub-Architektur ist die Suche global verknüpft: Ein Mitarbeiter, der im Global-Hub sucht, bekommt Ergebnisse aus allen Region-Hubs (Level 2) und auch aus deren zugehörigen Sites (Level 3) – das war einer der Hauptgründe für die Hub-zu-Hub-Association. Umgekehrt, ein Nutzer im EMEA-Hub sieht zunächst nur EMEA-Ergebnisse, kann aber via „Suche erweitern“ oder indem er zum Global-Hub wechselt, auch global suchen. GlobalCorp stellte fest, dass viele Nutzer doch lieber global suchen, weil das Intranet in der Regel auf Englisch funktionierte und sie meist auch bei deutschen Begriffen englische Inhalte in Kauf nahmen. Allerdings war es für die IT wichtig, dass Multi-Geo-Suche überhaupt klappt: Hier zeigte sich, dass Microsoft 365 tatsächlich die Indizes aus EU, US, Asia zusammenführen konnte, wenn die Hubs verbunden sind – allerdings gab es in der Anfangszeit leichte Verzögerungen (z.B. neu erstellter Inhalt im APAC-Hub tauchte erst mit etwas Verspätung in globalen Suchergebnissen auf). Daher kommunizierte GlobalCorp, dass für zeitkritische lokale Inhalte die regionale Suche zu nutzen sei. News-Flows in der Suche: Man integrierte auch Nachrichten in die Suchergebnisse (die vertikale „News“ zeigt länderübergreifend News, sofern Berechtigung).

News-Verteilung: Das Nachrichtenwesen war zweigeteilt: Der Global-Hub veröffentlichte globale News (in Englisch), die für alle relevant sind, wie Vorstandsmeldungen, Pressemitteilungen etc. Jede Region veröffentlichte regionale News (z.B. „Neues Logistikzentrum in Frankreich eröffnet“ in EMEA-Hub, möglicherweise auf Französisch oder in zwei Sprachen). Um die Verteilung zu steuern, machte GlobalCorp folgendes:
– Globale News wurden zusätzlich in die regionalen Hubs „gespiegelt“: Konkret hat das Comms-Team global entschieden, welche Meldungen für alle wichtig sind, und diese im jeweiligen Regional-Hub als übersetzte News neu veröffentlicht. Beispiel: Eine globale News „Q3 Ergebnisse“ wird vom EMEA-Kommunikationsteam aufgegriffen und mit regionalem Kontext/Kommentar auf dem EMEA-Hub auf Deutsch publiziert (ggf. mit Link zur globalen Quelle). So fühlte sich jede Region direkt angesprochen.
– Umgekehrt durften besonders wichtige regionale News auch im Global-Hub erscheinen, allerdings sparte man sich Doppelnennungen: Statt alle regionalen News global zu zeigen, wählte man ein „News from the Regions“-Spotlight auf der globalen Seite, das pro Woche 1 Meldung aus jeder Region hervorhob (per manuellem Auswahl-Webpart).
– Technisch nutzte man hier viel manuelle Kuratierung, da automatische Rollups über Hubs hinweg begrenzt sind. Kein Hub kann out-of-the-box die News seiner Child-Hubs anzeigen, deswegen waren die globalen Redakteure in den regionalen Sites als Mitglieder hinzugefügt, um dort Inhalte einzustellen. Ein anderes Werkzeug war die Nutzung von Yammer/Viva Engage für global-regionale Kommunikation, was aber in SharePoint dann nur verlinkt wurde.
– Mehrsprachigkeit war eine Daueraufgabe: GlobalCorp nutzte die SharePoint-Mehrsprachigkeitsfunktion auf dem Global-Hub (primär Englisch, einige Seiten auch auf Spanisch und Chinesisch übersetzt). In den Regional-Hubs machte man es pragmatischer: Inhalte erschienen meist in der Regionensprache, ein Teil auch auf Englisch, aber man verzichtete auf formale Übersetzungsseiten, da das zu viel Aufwand wurde. Stattdessen markierte man z.B. wichtige Seiten mit Flaggen („EN“ und „DE“ Buttons zum Umschalten, die zu jeweils anderssprachigen Seiten führten).

Berechtigungen & Zugang: Grundsätzlich waren alle Hubs und Sites für alle internen Mitarbeiter mit Leserechten zugänglich, egal aus welcher Region – GlobalCorp förderte Transparenz. Die Ausnahme war ein paar lokal gesetzlich eingeschränkte Inhalte: z.B. bestimmte Personalinformationen durften nur in EU von EU-Mitarbeitern gesehen werden. Hier kamen Sensitivity Labels ins Spiel: Einige Bibliotheken im EMEA-Hub waren mit „EU-Confidential“ gelabelt, was externes Teilen verbot und theoretisch den Zugriff beschränken könnte. In der Praxis wurden aber alle internen Mitarbeiter als „berechtigt“ angesehen. Wichtiger war der Conditional Access Aspekt: GlobalCorp richtete Richtlinien ein, dass z.B. APAC-Mitarbeiter, wenn sie auf EU-Daten zugreifen, bestimmte Bedingungen erfüllen müssen (MFA, etc.), um eventuellen Datenschutzauflagen Rechnung zu tragen. Dies war aber eher eine formale Sache. Externe Zugriffe wurden generell in den regionalen Hubs nicht erlaubt – dafür hätten separate Extranet-Sites gedient, was aber in diesem Szenario nicht relevant war.

Lokale Compliance/Aufbewahrung: Jede Region musste ihre eigenen Vorgaben umsetzen. Für EMEA bedeutete das z.B. DSGVO-Konformität – im Hub-Kontext achtete man darauf, dass keine persönlichen Daten ohne Rechtsgrundlage veröffentlicht wurden (z.B. keine Listen „Mitarbeitergeburtstage“ öffentlich). In APAC gab es Anforderungen an Aufbewahrung: Einige Länder verlangen, dass bestimmte HR-Dokumente X Jahre vorgehalten werden; das EMEA-Hub implementierte bspw. eine 10-Jahres-Aufbewahrung für Personalrichtlinien in der EU. Solche Policies wurden als Label oder Policy auf die entsprechenden Bibliotheken gelegt. Audit-Logs wurden regionenweise von den jeweiligen IT-Teams geprüft.

Governance & Betrieb: GlobalCorp bildete ein globales Intranet-Team, dem Vertreter jeder Region angehörten. Dieses Gremium sorgte für übergeordnete Richtlinien (z.B. was kommt global, was regional; Styleguide; technisches Setup). Gleichzeitig hatte jede Region ein kleines eigenes Redaktionsteam, das autonom über die regionalen Inhalte entschied. Man führte quartalsweise einen „Hub Health Check“ durch, bei dem aus jeder Region ein Bericht vorgestellt wurde: Nutzungsstatistiken, Erfolge, Probleme, geplante Änderungen. So lernte man voneinander – z.B. sah man, dass APAC eine sehr lebendige Community-Sektion im Hub hatte (mit Diskussionsboard), was den anderen Regionen als Best Practice diente. Risiken & Lessons Learned: Ein großes Risiko war die Inkonsistenz: Man fürchtete, dass die drei Regional-Hubs völlig unterschiedlich aussehen und sich Nutzer schwer tun, wenn sie zwischen ihnen wechseln. Anfangs war APAC-Hub z.B. viel bunter und verspielt gestaltet als der eher konservative EMEA-Hub. Das globale Team erarbeitete daraufhin einen Minimalstandard (Logo-Platzierung, gewisse Farbpalette, gemeinsame Schriftart), ließ aber bewusst Freiraum für kulturelle Unterschiede. Auch technisch gab es Hürden: Die Multi-Geo-Umgebung führte gelegentlich zu Suchproblemen, besonders wenn ein Nutzer aus USA im EU-Hub suchte – manchmal wurden Resultate wegen Index-Latenzen nicht gefunden. Hier lernte GlobalCorp, dass Geduld und Nutzeraufklärung wichtig ist („Suchen Sie notfalls auf Globalebene erneut“). Ein weiteres Learning: Zeitverschiebung im Betrieb – das globale Team musste Abstimmungen asynchron oder zu wechselnden Uhrzeiten machen, damit alle Regionen teilnehmen können. Fazit dieses Beispiels: Ein regionales Hub-Netz kann erfolgreich sein, wenn klare Verantwortlichkeiten pro Region bestehen und gleichzeitig eine Klammer (z.B. Parent-Hub für Suche und ein globales Steuerungsteam) alles zusammenhält. So profitieren die Regionen von Autonomie und lokalem Fokus, während das Unternehmen als Ganzes dennoch ein verbundenes Intranet behält.

Beispiel 4: Qualitätsmanagement-/Richtlinien-Hub mit strengem Veröffentlichungsprozess, Restricted Search und KPI-Reporting

Ausgangslage: Die PharmaCorp AG (fiktiv) ist ein pharmazeutisches Unternehmen, das strengen Regularien (GxP, FDA, EU-GMP etc.) unterliegt. Sie benötigt ein zentrales Qualitätsmanagement (QM)-Portal, in dem alle gültigen Richtlinien, Verfahrensanweisungen (SOPs) und Formulare bereitgestellt werden. Gleichzeitig müssen Änderungen an diesen Dokumenten kontrolliert genehmigt werden, und es ist kritisch, dass Mitarbeiter stets nur auf die aktuelle, freigegebene Version zugreifen. Früher nutzte PharmaCorp ein Intranet auf einem File-Share mit PDF-Dokumenten; es gab Probleme mit veralteten Dateien, schwer auffindbaren Infos und fehlender Nachvollziehbarkeit, wer wann was gelesen hat. Außerdem wünschte man sich, das System perspektivisch mit KI (z.B. einem Copilot) zu verknüpfen, ohne Risiko, dass halbfertige Entwürfe von Dokumenten ausgelesen werden.

Zielbild: Ein Qualitätsmanagement-Hub auf SharePoint Online, der als einzige „Quelle der Wahrheit“ für alle QM-Dokumente dient. Anforderungen waren:
– Strenger Veröffentlichungsprozess: Kein Dokument geht live, ohne von Qualitätsmanagern geprüft und freigegeben zu sein. Entwürfe müssen gekennzeichnet und vor allgemeinem Zugriff verborgen sein.
– Restricted Search: Die Suche (und KI-Tools) sollen nur freigegebene Inhalte berücksichtigen, nicht etwa Entwürfe oder veraltete Dokumente.
– Klare Eigentümerschaften: Jedes Dokument (Richtlinie) hat einen Owner, der regelmäßig Reviews macht; der Hub selbst hat definierte Owner/Editoren.
– KPI-Reporting: Es soll nachvollziehbar sein, wie oft welche Richtlinie gelesen wird, wer Schulungen absolviert hat etc., um Audits zu bestehen.
– Trennung intern/extern: Manche QM-Dokumente dürfen auch mit Partnern (Auftragsfertigern, Auditoren) geteilt werden, andere sind streng intern.

Architektur/Topologie: PharmaCorp entschied sich, einen dedizierten QM-Hub zu schaffen, losgelöst von anderen Hubs (also kein Parent/Child mit dem allgemeinen Intranet, um Verwechselungen zu vermeiden). Der Hub ist eine Kommunikationssite „Quality Portal“. Darunter wurden mehrere Team-Sites als Unterbau assoziiert:
– Eine Site für Dokumentenentwürfe (Zugriff nur QM-Abteilung), wo neue SOP-Entwürfe erarbeitet werden.
– Eine Site für Freigegebene QM-Dokumente (Leserechte für alle Mitarbeiter), die das eigentliche veröffentlichte Handbuch darstellt.
– Optionale Sites für externe Audits (wo bestimmte Dokumente für Externe bereitgestellt werden, z.B. ein Hub-Extranet-Bereich).

All diese Sites sind im selben Hub, damit die Navigation und Suche sie verbinden kann, aber mittels Berechtigungen separiert. Der Hub selbst dient als Einstiegsseite mit News und Übersichten.

Navigation: Die Hub-Navigation wurde so gestaltet, dass ein normaler Mitarbeiter im Grunde nur die freigegebenen Inhalte präsentiert bekommt:
– Hauptmenüpunkte: „Qualitätsrichtlinien“, „Arbeitsanweisungen (SOP)“, „Formulare“, „Schulungen“, „QM-News“.
– Diese Punkte verlinken auf Seiten in der freigegebenen QM-Site, welche Übersichten der entsprechenden Dokumente bieten (z.B. eine nach Kategorien filterbare Liste aller SOPs, mit Status „gültig ab [Datum]“).
– Ein interner Menüpunkt „Drafts (Entwürfe)“ ist nur für QM-Mitarbeiter sichtbar (Audience Targeting), der zur Entwurfs-Site führt. Normale Benutzer sehen diesen Menüpunkt nicht.
– Ebenso gibt es einen Menüpunkt „Externe Audits“, der nur für eine spezielle Benutzergruppe sichtbar ist, wo selektierte Dokumente für Partner eingesehen werden können (diese Site hat externe Freigaben erlaubt).
– Einheitliches Design und klare Kennzeichnung: z.B. alle Seiten in der Entwurfs-Site haben einen roten „Entwurf“ Hinweis im Header, um Verwechslung auszuschließen. Die Navigation spiegelt das nicht direkt wider, aber die Nutzer aus QM wissen, wann sie im Entwurfsbereich sind.

Suchkonzept: Dies war der kritischste Teil. PharmaCorp wollte sicherstellen, dass bei einer Suche nur freigegebene, gültige Inhalte gefunden werden, keinesfalls Entwürfe oder überholte Versionen. Daher entschieden sie sich, die Tenant-weite Option Restricted SharePoint Search (RSS) zu aktivieren und als erlaubte Sites nur die freigegebene QM-Site sowie wenige andere geprüfte Quellen (z.B. ein Glossar) einzutragen. Effekt: Egal wo ein Mitarbeiter sucht (global, über Copilot etc.), es erscheinen nur Ergebnisse aus dieser kuratierten Liste. Das garantiert, dass keine Work-in-Progress Dokumente auftauchen. Für den Hub selbst bedeutet es: die Suchleiste im QM-Hub ist ohnehin schon auf Hub-Kontext (d.h. freigegebene Site + evtl. Entwurfs-Site) eingestellt. Durch RSS und Berechtigungen erreicht man, dass ein normaler Mitarbeiter nur Treffer aus der freigegebenen Site sieht – Entwurfssite-Inhalte sind für ihn unzugänglich und zudem nicht im Index. Die QM-Mitarbeiter hingegen können gezielt auch in der Entwurfs-Site suchen (für sie zugänglich), aber sie tun das meist direkt dort. Für das QM-Team hat man RSS nicht zum Hindernis werden lassen – sie haben alternative Wege oder mussten in dem Fall auf SharePoint-eigene Suche innerhalb der Entwurfs-Site zurückgreifen, was okay ist. Zusätzlich setzte PharmaCorp stark auf metadatenbasierte Suche: Alle QM-Dokumente tragen eine eindeutige Nummer und Stichworte (Prozessname etc.). Man richtete konfigurierbare Filter in der Suche ein (Search Verticals mit Refinern), damit Mitarbeiter z.B. alle Dokumente zum Prozess „Herstellung“ oder alle Formulare filtern können. Auch Synonyme wurden gepflegt, etwa „SOP“ <-> „Arbeitsanweisung“.

Taktiken für kuratierte Inhalte: Neben den formalen Dokumenten wollte PharmaCorp, dass der Hub auch Wissen vermittelt. Darum erstellten sie FAQ-Seiten zu Qualitätsprozessen und ein Glossar der wichtigsten Begriffe. Diese Inhalte wurden ebenfalls auf der freigegebenen Site bereitgestellt und in die Suche einbezogen. Insbesondere richteten sie Q&A-Einträge in Microsoft Search ein: Fragt jemand „Wie melde ich einen Qualitätsvorfall?“, erscheint eine geführte Antwort mit Link auf die entsprechende SOP. Das QM-Team kuratierte diese Q&As auf Basis häufiger Fragen aus Audits oder Trainings. Wichtig war aber, dass diese Q&As stets auf offizielle Dokumente verwiesen (um Parallelinformationen zu vermeiden).

News & Kommunikation: Im QM-Hub gab es auch einen News-Bereich, aber streng moderiert. Nur QM-Leitung durfte News veröffentlichen (z.B. „Neues Dokumentenlenkungs-Prozess eingeführt“ oder „Audit erfolgreich bestanden“). Die News sind wichtig, um Änderungen bekannt zu machen. PharmaCorp richtete einen Newsletter ein: alle Mitarbeiter wurden via automatischer E-Mail benachrichtigt, wenn eine neue QM-News erschien (das SharePoint-News Digest-Feature, aber zentral vom Hub ausgelöst). Damit sollte sichergestellt sein, dass keine Änderung unbemerkt bleibt. Dubletten oder Flut waren hier kein Thema, da News selten (vielleicht 1-2 im Monat) und zentral gesteuert waren. Die News waren mehrsprachig: Offiziell in Englisch verfasst, mit Zusammenfassung in Deutsch und Französisch in der gleichen Seite (man nutzte die Mehrsprachigkeitsfunktion pro News-Seite, um übersetzte Varianten zu haben). So konnten alle Standorte informiert werden. Ein weiterer Kommunikationsaspekt: Manche QM-Seiten erforderten eine Bestätigung (z.B. Mitarbeiter müssen lesen und „verstanden“ klicken). Das implementierte man mit Power Automate – die Seite enthielt einen Button „Bestätigen“, der im Hintergrund ein Flow auslöste, der den Namen in einer Liste vermerkt. Solche Mechanismen gingen über Standard hinaus, waren aber für Compliance erforderlich.

Berechtigungen & Sicherheit: Wie bereits angedeutet, hat die Berechtigungsarchitektur drei Zonen:
– Öffentliche QM-Bibliothek: Leserechte für alle Mitarbeiter. Hier liegen nur final freigegebene PDFs der Dokumente. Schreibrechte nur für QM-Redakteure.
– Entwurfsbereich: Streng beschränkt auf QM-Team. Sensitivity Label „Strict Internal“ gesetzt, externes Teilen deaktiviert. Hier wird in Word/Excel gearbeitet, bevor PDF erstellt wird.
– Extranet-Bereich: Eine separate Site, ebenfalls Hub-zugeordnet, aber so eingerichtet, dass bestimmte externe Partner Zugriff haben. Hierhin kopiert man bei Bedarf einzelne freigegebene Dokumente, die etwa einem Auftragshersteller bereitgestellt werden müssen. Dieser Bereich hat seine eigene Navigation (im Menü des Hubs taucht er nur für Berechtigte auf). Zusätzlich markiert man Dokumente dort mit Wasserzeichen „Copy“ etc. (auch wenn das außerhalb SharePoint passiert).
– Hub-Berechtigungssync wurde hier nicht genutzt, da granularere Kontrolle nötig war. Stattdessen setzte man auf klassisches Berechtigungsmanagement mit Gruppen (z.B. „Alle Mitarbeiter“ auf der Freigegebenen Site als Leser, keine Besucher-Sync-Funktion im Hub aktiviert).
– Auditing: Jede Dokumentenansicht wird protokolliert (Audit Log). Das QM-Team generiert quartalsweise Reports: Wer hat welche kritische SOP gelesen? (Kombination aus SharePoint-Audit und manuellen Anwesenheitslisten der Schulungen).

Compliance & Governance: Dieser Hub hatte die umfangreichsten Governance-Regeln. Für den Änderungsprozess wurde eine SOP „Dokumentenlenkung“ definiert, die genau vorschreibt, wie ein neues Dokument erstellt wird, wer es reviewt, wer freigibt (Vier-Augen-Prinzip oder mehr). SharePoint wurde mittels Power Automate so integriert, dass bei einem neuen Entwurf in der Entwurfsbibliothek automatisch ein Flow startet: „Review-Aufgabe an QM-Leiter“ und nach Korrektur „Genehmigung durch QA-Direktor“. Erst nach finaler Genehmigung wird das Dokument automatisch in die freigegebene Bibliothek veröffentlicht (Flow verschiebt/konvertiert es nach PDF und legt es ab). Diese Vorgänge sind alle im Audit-Trail festgehalten (Flow schreibt Logeinträge, wer wann genehmigt hat). Somit kann man externen Prüfern lückenlos zeigen, dass kein Dokument unkontrolliert online ging. Rollen: Der Hub hat klar definierte Owner (Qualitätsleiter als inhaltlich Verantwortlicher, IT-Compliance als technischer Owner). Das restliche Unternehmen ist eher Konsument. KPI-Reporting: Hier war speziell, dass man z.B. Prozent der Mitarbeiter, die eine neue SOP innerhalb 30 Tagen gelesen haben, als KPI definierte (Ziel 100% bei verpflichtenden SOPs). Über die Bestätigungs-Mechanik ließ sich das messen. Auch „Anzahl überfälliger Dokumentenreviews“ (jedes Dokument hat jährlich Revisionsfälligkeit – Flow erinnert Owner 30 Tage vorher; KPI ist, dass 0 Dokumente über das Datum kommen). Risiken & Lessons Learned: Ein Risiko war, dass Mitarbeiter Workarounds suchen, wenn sie mal einen Entwurf brauchen. Etwa könnte jemand im Entwurfsbereich nach Infos suchen, zu denen er keinen Zugang hat, und dann außerhalb des Hubs Infos austauschen. Um dem vorzubeugen, hat PharmaCorp stark kommuniziert: „Wenn etwas nicht im QM-Hub steht, ist es nicht offiziell und darf nicht verwendet werden.“ Man schulte die Leute, lieber beim QM-Team nachzufragen, falls etwas fehlt. Eine unbeabsichtigte Hürde war die Restricted Search: Einige Power-User vermissten die Möglichkeit, über die normale Suche auch Entwürfe zu finden (wenn sie z.B. QA-Mitarbeiter sind). Hier half man sich mit gezielten Lesezugriffen für den Personenkreis auf die Entwurfs-Site oder indem man sie lehrte, direkt dort zu suchen. Insgesamt war das System aber erfolgreich – bei Audits erhielt PharmaCorp Lob für das „Single Source of Truth“-Portal. Das Beispiel zeigt, wie ein Hub mit klarer Abgrenzung und strikter Governance als Qualitätsportal eingesetzt werden kann, inklusive Nutzung der Restricted Search Funktion, um die Datenbasis für Benutzer (und KI) gezielt einzuschränken.

Beispiel 5: Partner-/Extranet-nahes Informationshub für selektive externe Leser

Ausgangslage: Die TechSolutions GmbH (fiktiv) arbeitet eng mit zahlreichen externen Partnerfirmen zusammen – z.B. Zulieferer, Vertriebspartner und Dienstleister. Es besteht das Bedürfnis, bestimmten Partnern ausgewählte Informationen bereitzustellen (Produktdokumentationen, Vertriebsmaterial, Schulungsunterlagen), ohne ihnen Zugriff auf das interne Intranet zu geben. Bisher wurden solche Infos per E-Mail oder über OneDrive-Links geteilt, was ineffizient und unsicher war. Gesucht wurde eine Lösung in Form eines Partnerportals, wo externe Benutzer (mit Azure AD B2B Konten) kontrolliert Zugriff auf freigegebene Inhalte erhalten. Gleichzeitig sollte das interne Team sicherstellen, dass diese extern freigegebenen Inhalte aktuell sind und keine sensiblen internen Daten versehentlich mit rausgegeben werden.

Zielbild: Ein separater Partner-Hub, der vom internen Intranet getrennt ist, aber den internen Mitarbeitern genauso als Plattform dient, um Inhalte für Partner bereitzustellen. Anforderungen:
– Jeder Partner (Firma) sieht nur die für ihn bestimmten Inhalte (Mandantentrennung auf Site-Ebene, nicht dass zwei Wettbewerber gegenseitig Infos sehen).
– Navigation und Struktur sollen für interne und die jeweiligen externen Nutzer nachvollziehbar sein, aber internes Personal darf auch Quersichten haben.
– Restriktive Navigation: Externe sollen keine Links auf interne Sites sehen und sich nur innerhalb des für sie zugänglichen Bereichs bewegen können.
– Sensitivity Labels und Schutz: Alle Dokumente, die extern bereitgestellt werden, sollen gekennzeichnet und evtl. read-only gemacht werden (z.B. mit Information Rights Management), um Weiterverbreitung einzudämmen.
– Auditing & Rezertifizierung: Zugriff der externen Nutzer muss regelmäßig überprüft und befristet sein (z.B. jährliche Neufreigabe), um „Karteileichen“ zu vermeiden.

Architektur/Topologie: TechSolutions löste das mit einem eigenständigen Hub „Partner Portal“. Dieser Hub liegt technisch im selben Tenant, ist aber nicht mit dem Intranet-Hub verbunden (kein Parent/Child mit internen Hubs, um Isolierung zu gewährleisten). Unter dem Partner-Hub wurden mehrere Sites pro Partnerfirma angelegt, jeweils vom Template einer Team-Site:
– z.B. eine Site „Partner X Portal“, eine „Partner Y Portal“ etc. – jede enthält Dokumentbibliotheken und Seiten spezifisch für diesen Partner (z.B. Angebote, Projektpläne, Handbücher).
– Zusätzlich gibt es eine zentrale Partnersupport-Site (Kommunikationssite), die allgemeine Infos für alle Partner bereithält (z.B. öffentliches Produktwiki, FAQs, Kontaktinfos). Diese wurde ebenfalls dem Hub zugeordnet und dient als Hub-Startseite.
– Die Navigation des Hubs zeigt allgemeine Bereiche und – für interne Nutzer – auch Links zu allen Partner-Sites, aber Externe sollen nur ihre eigene sehen. Das realisierte man über Audience Targeting: Jeder Partner-Site-Link im Menü ist nur für die Gruppe dieses Partners + interne Mitarbeiter sichtbar. Alternativ hätte man die Navigation personalisiert generieren können, aber man entschied sich für manuelle Pflege mit Zielgruppensteuerung.

Navigation & Zugriffssteuerung: Die Hub-Navigation hat z.B. Punkte: „Home“ (allgemeine Partnerinfo-Seite), „Dokumentation“, „Schulungen“, und dann „Partnerbereiche“ mit Unterpunkten für Partner A, Partner B, etc. Durch Audience Targeting sieht Partner A nur „Partner A“ unter Partnerbereiche und nichts von B, C. Interne Mitarbeiter sehen alle aufgelistet (da sie in allen Zielgruppen drin sind oder man internen eine eigene Gruppe „Mitarbeiter“ gab, die bei allen Links berechtigt ist). Zusätzlich hat man in der Seitennavigation der einzelnen Partner-Sites natürlich auch Struktur (die Partner-Teams können dort Unterseiten haben), aber da bewegen sich Externe ja nur in ihrer Site.
Um Restriktion weiter zu verstärken, hat man eine Einstellung in Azure AD B2B genutzt: Die externen Partner dürfen nur auf explizit freigegebene Sites zugreifen (was per se so ist) und man schränkte auch die Einladung so ein, dass nur bestimmte Personen im Unternehmen neue Gäste einladen dürfen (die Partner-Manager). So wurde verhindert, dass versehentlich ein Externer auf eine interne Site gelotst wird.

Berechtigungen & Sensitivity: Jede Partner-Site hat eine eigene SharePoint-Gruppe für „<Partnername> Externe“, worin die jeweiligen Gastbenutzer sind, plus eine Gruppe für interne Betreuer (Key Account Manager z.B.). Keine Partner-Site enthält interne Only-Inhalte – sollte intern etwas notiert werden müssen, hat man entweder Bereiche mit getrennten Berechtigungen (Ordner „Intern-Only“ für Notizen, nur intern zugänglich) oder nutzt Microsoft Teams intern. Wichtig: Alle Dokumente, die in diesen Partner-Sites hochgeladen werden, erhalten automatisch ein Sensitivity Label „Extern – Partner“, das via Auto-Labeling konfiguriert wurde. Dieses Label setzt z.B. fest, dass Dateien read-only sind (nicht von Externen editierbar, ggf. als PDF bereitstellen) und versehen sind mit einem Visual Marking (Wasserzeichen „TechSolutions Confidential – For Partner X“). Außerdem blockiert es das Weiterschicken solcher Dokumente an andere Domains (wenn MIP sensitivity in Office/Outlook greift). Das bedeutet, selbst wenn ein Partner versucht, ein Word-Dokument aus dem Portal herunterzuladen und weiterzuleiten, ist es geschützt. Intern war es etwas Aufwand, diese Policies zu konfigurieren, aber es erfüllte den Zweck.
Auch in der Suche verhält es sich konsequent: Externe Partner können im Portal nur ihre Site durchsuchen; sie bekommen keine Treffer aus anderen Sites (weil kein Zugriff). Die globale Suche von Microsoft ist für Gäste ohnehin eingeschränkt auf was sie Zugriff haben. Das war somit kein Problem.

Restricted Navigation vs. Globale Nav: TechSolutions wollte nicht, dass Externe überhaupt das interne Globale Menü sehen (das via App-Bar ja in allen Sites erscheint). Glücklicherweise blendet Microsoft die App-Bar für Gäste standardmäßig aus (Stand heute), sodass externe Partner nur die Hub-Navigation sehen. Damit war gewährleistet, dass keine internen Navigationspunkte durchschimmern. Zudem brandete man den Partner-Hub deutlich anders als das interne Intranet (anderes Farbschema, eigenes Logo „PartnerPortal“), um Verwechslungen zu vermeiden.

Schulung & „So funktioniert es“: Für Partner wurde eine kurze Anleitung bereitgestellt („Welcome to Partner Portal“, in mehreren Sprachen), die erklärt, wie sie das Portal nutzen, wo sie was finden, und dass sie bei Problemen ihren TechSolutions-Ansprechpartner kontaktieren können. Intern wurden die Key Account Manager geschult, wie man Inhalte hochlädt, wie man Berechtigungen für neue Partnernutzer setzt (wobei die IT initial die Gäste einlädt und Gruppenzuweisung vornimmt, damit nichts falsch läuft).

Auditing und Rezertifizierung: TechSolutions implementierte einen jährlichen Review: Jede Partner-Site wird einmal pro Jahr durch den verantwortlichen internen Owner geprüft. Dieser schaut nach, welche externen Accounts noch Zugriff haben. Ein Monat vor Ablaufjahr generiert ein Script eine Liste aller Gäste pro Site und schickt es an den Owner mit Bitte um Bestätigung oder Entfernung. Gäste, die nicht bestätigt werden, werden automatisch deaktiviert (Azure AD Guest Expiration Policy half hier mit). Dieser Prozess stellt sicher, dass Ex-Mitarbeiter der Partnerfirmen oder nicht mehr relevante Personen den Zugang verlieren. Zudem wird dabei auch der Content durchgesehen: Ist noch alles aktuell, kann etwas archiviert werden? Im Audit-Log werden externe Zugriffe besonders überwacht: Es gibt Alarme, wenn ein externer User ungewöhnlich viele Dateien auf einmal herunterlädt oder auf Bereiche zugreifen will, die er nicht sollte (was dank Berechtigungen fast nie vorkam, aber falls z.B. Konfiguration falsch, wollte man es merken). Risiken & Lessons Learned: Ein initiales Risiko war, dass interne Mitarbeiter versehentlich vertrauliche Infos in den offenen Partner-Bereich laden. Trotz Policies kann es vorkommen, dass man im falschen Fenster eine interne Datei hochlädt. Hier sensibilisierte man die Kollegen stark, und zusätzlich hat die DLP-Engine Regeln, die z.B. personalbezogene Daten oder Finanzpläne erkennen würde, um Alarm zu schlagen. Ein weiteres Risiko: Partner vermischen Foren – TechSolutions stellte fest, einige Partner hatten Schwierigkeiten, zwischen dem Partnerportal und früheren Kommunikationswegen zu wechseln. Manche schickten doch wieder Emails statt ins Portal zu schauen. Hier hilft nur Change Management: Der Vertrieb musste aktiv die Nutzung einfordern („Bitte entnehmen Sie die Unterlagen aus unserem Portal.“). Mit der Zeit wurde es Routine. Positiv war die Trennung: Durch die separate Hub-Architektur konnte man das gesamte Partnerportal auch mal temporär offline nehmen (für Wartung), ohne das interne Intranet zu berühren. Man hat separate Zugriffsstatistiken und konnte das Partnerportal auch einem eingeschränkten Support-Team zuweisen, das sich nur um externe Belange kümmert. Insgesamt zeigte dieses Beispiel, dass ein SharePoint-Hub auch als Extranet-Lösung taugt, sofern man die Navigation streng nach Zielgruppen gestaltet und die Sicherheitseinstellungen (Labels, Gastrestriktionen, Audience Targeting) konsequent nutzt. So behält man die Kontrolle über geteilte Informationen und bietet den Partnern dennoch einen professionellen Zugang zu relevanten Materialien.

13. Checklisten

Checkliste: Hub-Architektur-Review
Überprüfungspunkte, ob die grundlegende Hub-Architektur den Anforderungen entspricht.

Checkliste: Navigations-Review (Hub-Menüs)
Regelmäßige Prüfung der Hub-Navigation auf Vollständigkeit, Verständlichkeit und Effektivität.

Checkliste: Such- und Inhalts-Review
Überprüfung der Suchfunktion und der Content-Auffindbarkeit im Hub (ggf. Nulltreffer-Analyse).

(Alle Checklisten sollten regelmäßig aktualisiert und bei Reviews gemeinsam durchgegangen werden. „Ist-Stand“ und „Maßnahmen“ werden im Laufe der Überprüfung ausgefüllt.)

14. FAQ – Häufige Fragen zu SharePoint-Hubs

1. Wozu dient eine Hub-Site, und wie unterscheidet sie sich von Team-/Kommunikationssites?
   Eine Hub-Site verbindet mehrere SharePoint-Sites (Team- oder Kommunikationssites) unter einem gemeinsamen Dach für Navigation, Suche und Gestaltung. Während eine Team-Site der Zusammenarbeit eines bestimmten Teams dient und eine Kommunikationssite Inhalte für ein breites Publikum bereitstellt, ist die Hub-Site kein eigener Inhaltstyp, sondern eine Meta-Ebene: Sie sorgt für einheitliche Navigation, konsistentes Look&Feel und aggregierte Inhalte (z.B. News) über alle zu ihr gehörenden Sites hinweg.
2. Was ist eine Hub-Familie, und was macht ein Parent-Hub?
   Eine Hub-Familie bezeichnet die Gruppe von Sites, die mit einer Hub-Site assoziiert sind – also die Hub-Site selbst und alle zugehörigen Sites. Ein Parent-Hub ist ein übergeordneter Hub, der mit einem oder mehreren anderen Hubs verknüpft wurde, um z.B. die Suche über diese Hubs hinweg zu ermöglichen. Der Parent-Hub stellt gewissermaßen eine höhere Ebene dar, unter der mehrere Hub-Familien zusammenhängen, ohne dass ihre Navigation automatisch verschmilzt.
3. Welche Grenzen gibt es bei Anzahl, Tiefe und Struktur von Hubs?
   Pro Microsoft 365-Tenant können derzeit bis zu 2.000 Hub-Sites definiert werden. Ein Site kann immer nur zu einem Hub gehören (keine Mehrfachzuordnung). Hub-Hierarchien (Parent-Child) funktionieren bis zu einer Tiefe von 3 Ebenen in Bezug auf die durchsuchte Inhaltsausweitung. In der Navigation sind maximal 3 Ebenen an Dropdown-Menüs möglich. Generell sollte die Hub-Struktur flach und überschaubar gehalten werden – zu viele Hubs oder verschachtelte Ebenen erschweren die Orientierung.
4. Wie wirkt Audience Targeting auf die Hub-Navigation?
   Mit Audience Targeting lässt sich einstellen, dass bestimmte Navigationslinks im Hub-Menü nur für definierte Personengruppen sichtbar sind. Das bedeutet, Nutzer sehen je nach ihrer Zielgruppe unterschiedliche Menüeinträge (z.B. ein Link zu einer internen Team-Seite nur für Teammitglieder). Wichtig: Audience Targeting ändert nicht die Berechtigungen an den Sites selbst – es blendet nur die Links aus, um die Nutzerführung zu verbessern und Verwirrung oder Zugriffsfehler zu vermeiden.
5. Wie setze ich den Suchbereich auf „Dieser Hub“, und wann „Organisation“?
   Im SharePoint modern UI ist der Suchbereich kontextabhängig: Befindet man sich auf einer Hub-Site, werden Eingaben standardmäßig im Hub-Kontext gesucht („Dieser Hub“). Als Nutzer kann man das auf der Suchergebnisseite erweitern („Suchbereich: Gesamte Organisation“ auswählen), um alles zu durchsuchen. Man setzt „Dieser Hub“ ein, wenn man themenspezifisch innerhalb der verbundenen Sites suchen möchte (höhere Relevanz, weniger Rauschen). „Organisation“ wählt man, wenn man bereichsübergreifend oder unternehmensweit etwas finden will, was im aktuellen Hub nicht vorhanden ist.
6. Was leistet Restricted SharePoint Search, und wie kuratiere ich den Index?
   Restricted SharePoint Search (RSS) begrenzt die unternehmensweite Suche und Microsoft 365 Copilot auf einen vordefinierten Satz von SharePoint-Sites. Damit kann man den Suchindex „säubern“ und nur geprüfte Inhalte einbeziehen. Um den Index zu kuratieren, erstellt man im Microsoft 365 Admin Center eine Allow-Liste von max. 100 Sites, die durchsucht werden dürfen. Alle anderen Inhalte werden aus der globalen Suche ausgeschlossen. Diese Liste sollte sorgfältig gepflegt werden – z.B. Hauptintranetseiten, offizielle Portale – und regelmäßig überprüft/aktualisiert, damit wichtige Inhalte nicht fehlen.
7. Wie funktionieren News-Rollups, und wie vermeide ich Dubletten?
   News-Rollups aggregieren Nachrichtenbeiträge aus mehreren Sites und zeigen sie gesammelt an, typischerweise auf der Hub-Startseite. In SharePoint erfolgt das über das News-Webpart (Quelle: „Alle Sites in Hub“) oder gezielt ausgewählte Sites. Dubletten vermeidet man, indem man nicht die gleichen News von zwei Quellen anzeigen lässt – zum Beispiel sollte man entscheiden, ob man News via „alle Sites“ automatisch holt oder manuell kuratiert, aber nicht beides zugleich. Falls doch mehrere Webparts genutzt werden, kann man Filter einsetzen (z.B. nach Kategorien), um Überschneidungen auszuschließen. In der Praxis hilft ein klarer Veröffentlichungsprozess: jede News wird nur an einem Ort erstellt und dann zentral oder dezentral angezeigt, aber nicht mehrfach kopiert.
8. Was kann die Hub-Berechtigungssynchronisation (Besucher), was nicht?
   Die Hub-Berechtigungssynchronisation erlaubt es, einer Hub-Site bis zu 10 Personen oder Gruppen als „Besucher“ zuzuweisen und diese automatisch auf alle zugehörigen Sites als Leser einzutragen. So erreicht man mit einem Schritt einen einheitlichen Lesebereich (z.B. alle Mitarbeiter bekommen Lesezugriff auf alle Hub-Inhalte). Was sie nicht kann: Sie synchronisiert keine Bearbeitungs- oder Admin-Rechte und gleicht nicht vorhandene individuelle Berechtigungsunterschiede aus. Außerdem müssen Sites dem Hub erst beitreten, damit es wirkt – bestehende Berechtigungen auf einzelnen Sites bleiben unverändert, es sei denn, die Synchronisationsgruppe wird hinzugefügt. Und: Sensible Sites können sich dem entziehen (Site-Owner könnten die Hub-Gruppe entfernen). Kurz gesagt, es ist eine bequeme Möglichkeit für Lesezugriff, ersetzt aber kein detailliertes Berechtigungsmanagement.
9. Wie gehe ich mit Gastzugriffen in einem Hub-Kontext um?
   Externe Gäste in einem Hub erfordern sorgfältige Steuerung: Standardmäßig sehen Gäste die Hub-Navigation und könnten Links zu Sites sehen, auf die sie keinen Zugriff haben. Daher sollte man entweder solche Links via Audience Targeting ausblenden oder Gäste in einem separaten Hub halten (z.B. Extranet-Hub getrennt vom internen). Wichtig ist, dass jede Site, die Gäste enthält, entsprechend markiert und abgesichert ist (z.B. Sensitivity Label „Extern“ setzen, externes Teilen eingeschränkt). Auch sollte regelmäßig überprüft werden, welche Gastnutzer noch Zugriff brauchen (Rezertifizierung). Im Hub-Kontext empfiehlt es sich oft, Externe nur sehr gezielt zu integrieren oder wie gesagt getrennte Strukturen (Hub oder eigene Sites) zu verwenden, um interne Informationen zu schützen.
10. Welche Design-/Branding-Optionen sind hubweit konsistent?
    Ein Hub sorgt dafür, dass das gewählte Design (Theme) – also Farben, Schriftarten und Hintergrund – auf alle zugeordneten Sites angewandt wird. Auch das Hub-Logo (Icon neben dem Hub-Namen) wird in der Leiste überall gezeigt. Dinge wie die Header-Layout-Option (Standard oder Erweitert) und die Footernavigation muss man allerdings pro Site einstellen, sie lassen sich aber manuell konsistent halten. Hubweite Consistency bedeutet auch: verwendete Webpart-Designs (z.B. News-Layout) und Seitentemplates können koordiniert werden, aber technisch erzwingt der Hub abgesehen vom Theme nur die Top-Navigation und das Theme. Corporate Branding Guidelines sollte man den Site-Ownern an die Hand geben, damit sie keine abweichenden Logos/Designs verwenden.
11. Wie plane ich Multi-Geo-Hubs ohne inkonsistente Suche?
    In einem Multi-Geo-Szenario legt man idealerweise pro Geo-Region eigene Hubs an (damit Daten lokal bleiben), und verbindet sie ggf. über Parent-Hub-Verknüpfung für die Suche. Planungsschritte: definieren, welche Inhalte pro Region bleiben müssen, pro Region einen Hub aufbauen, und den globalen Hub als Parent (oder alternativ die globale Suche über alle Geos nutzen via SharePoint Startseite). Wichtig ist zu verstehen, dass die Suche in Multi-Geo zuerst die lokale Region bedient; mit Parent-Hub-Einstellung kann man das auf weitere Regionen ausdehnen, allerdings kann es leichte Verzögerungen geben. Konsistenz erreicht man, indem man die gleichen Metadaten/Suchsynonyme in allen Geos pflegt und regelmäßig testet, ob Suchergebnisse vergleichbar ausfallen. Kurz: Pro Region Hubs planen, global verknüpfen, aber einzelne regionale Suchen monitoren.
12. Wie dokumentiere ich Navigation und Änderungen (Änderungslog)?
    Man sollte für jeden Hub eine Dokumentation führen, die die aktuelle Navigationsstruktur (Menüpunkte, Hierarchie) festhält – etwa in Form eines Strukturdiagramms oder einfach einer Liste. Zudem empfiehlt sich ein Änderungslog: darin notiert man jede wesentliche Änderung (z.B. „05.07.2025: Menü ‚Services‘ um Unterpunkt X erweitert“) mit Datum und Verantwortlichem. Das kann in einem Wiki, OneNote oder SharePoint-Liste gepflegt werden. So behalten das Hub-Team und Nachfolger den Überblick. Zusätzlich zur Navigation können auch andere Änderungen (Designwechsel, Berechtigungskonfigurationen) mitprotokolliert werden. Diese Doku ist Teil der Hub-Governance und erleichtert die Kommunikation von Änderungen an die Nutzer (z.B. in einem „Was ist neu?“-Bereich des Hubs).
13. Welche KPIs sind sinnvoll, und wie messe ich sie?
    Sinnvolle KPIs für Hubs sind z.B.: Nutzerreichweite (wie viele einzigartige Benutzer nutzen den Hub pro Woche/Monat – messbar über SharePoint Nutzungsdaten), Verweildauer/Seitenaufrufe (wie intensiv werden Inhalte konsumiert – ebenfalls in Nutzungsberichten), Suchanfragen und Erfolgsquote (Anzahl der Suchen, Anteil mit mindestens einem Klick oder ohne Ergebnis – aus dem Search-Insights Dashboard oder per KQL-Log), News-Engagement (Views pro News, Likes/Comments – in der Seitenstatistik je News und aggregierbar), Ladezeiten (technische Performance, evtl. gemessen mit externen Tools oder Browser DevTools). Messen kann man viel davon in den SharePoint-Usage Reports (im Admin Center oder via PowerShell/Graph API) und in Microsoft Search Intelligence. Oft erstellt man ein Power BI Dashboard, das diese Daten zusammenführt. Wichtig ist, sich auf wenige KPI zu einigen, Zielwerte festzulegen und die Entwicklung über die Zeit zu beobachten.
14. Wie optimiere ich Performance (Webparts, Bilder, Startseite)?
    Zur Performance-Optimierung sollte man die Startseite schlank halten: Nur nötige Webparts verwenden, umfangreiche Listen oder Bibliotheken nicht ungefiltert darstellen. Bilder sollte man vorab auf Web-Größe optimieren und idealerweise die Nutzung des Microsoft CDN für Assets prüfen, damit sie schneller geladen werden. Unnötige Skripte oder Third-Party-Webparts vermeiden – jeder zusätzliche Inhalt erhöht Ladezeit. Auch das Aktivieren von „Seiten zwischenspeichern“ (Page caching) in SharePoint Online ist automatisch gegeben, man sollte aber z.B. nicht ständig Design ändern, was Cache bustet. Messungen mit dem SharePoint Page Diagnostics Tool oder Browser-Werkzeugen zeigen Engpässe. Zusammengefasst: leichte Bilder, wenige Webparts, Datenquellen begrenzen, CDN nutzen – dann lädt der Hub zügig.
15. Wie baue ich ein Risikoregister für die Hub-Einführung auf?
    Ein Risikoregister ist eine Tabelle oder Liste, in der man mögliche Risiken notiert, bevor (und während) man den Hub einführt. Man erstellt Spalten für das Risiko (Beschreibung), Wahrscheinlichkeit des Eintretens, potenzielle Auswirkung, und Gegenmaßnahmen/Verantwortliche. Beispiele könnten sein: „Akzeptanzproblem bei Nutzern“ oder „Unklare Content-Verantwortung“. Für jedes Risiko schätzt man Low/Medium/High und legt fest, wie man vorbeugt oder reagiert. Dieses Register sollte mit dem Projektteam und Stakeholdern durchgesprochen und regelmäßig aktualisiert werden. So hat man einen Plan, falls etwas schiefgeht. Wichtig ist auch, nach Einführung zu prüfen, welche Risiken tatsächlich eingetreten sind, um fürs nächste Mal zu lernen.
16. Wie vermeide ich, dass Hubs als „Sammelstellen für alles“ verkommen?
    Durch klare Governance und regelmäßige Pflege. Konkret: Definieren Sie den Scope eines jeden Hubs (welche Themen gehören rein, was nicht) und schulen Sie Site-Owner, sich daran zu halten. Nutzen Sie Approval-Flows für neue Site-Zuordnungen – so verhindert man, dass plötzlich jeder beliebige Projektraum sich an einen unpassenden Hub hängt. Entfernen Sie veraltete oder inaktive Inhalte/Sites aus dem Hub (Archivierung). Kurz: kontinuierliches „Ausmisten“ und eine Kultur, wo Qualität über Quantität steht. Wenn jeder Bereich denkt, er könne alles in den Hub laden, sollte das Hub-Team eingreifen und moderieren. Lieber weitere Hubs gründen oder andere Lösungen (z.B. Teams) nutzen, als einen Hub mit völlig heterogenem Ballast zu überfrachten.
17. Welche Rollen brauche ich, und wie sieht eine RACI-Matrix aus?
    Typische Rollen sind: Hub-Eigentümer (verantwortlich für Inhalte und Erfolg des Hubs), Hub-Administrator (IT) für technische Verwaltung, Site-Owner der einzelnen zugeordneten Sites, Redakteure für Inhalte/News, und Compliance-Verantwortliche für die Einhaltung von Regeln. Eine RACI-Matrix legt für Aufgaben fest, wer diese Rollen R = Responsible (führt aus), A = Accountable (letztlich verantwortlich), C = Consulted (konsultiert) und I = Informed (zu informieren) ist. Beispiel: Aufgabe „Navigation aktualisieren“: Hub-Owner R (führt Änderung durch), evtl. IT Admin C (berät bei Umsetzung), Intranet Manager A (freigibt) und Site-Owner I (werden informiert über Änderung). Die genaue RACI-Matrix variiert je nach Organisationsstruktur, aber sie sollte alle wichtigen Aufgaben (Design, Berechtigungen, Inhalte, Wartung, Kommunikation etc.) und die genannten Rollen abdecken.
18. Wie integriere ich Sensitivity Labels und Aufbewahrungsrichtlinien?
    Sensitivity Labels können auf Site-Ebene zugewiesen werden, um einen Hub oder dessen Sites als z.B. „Vertraulich“ oder „Extern freigegeben“ zu klassifizieren. Bei Integration bedeutet das: Legen Sie fest, welche Hub-Inhalte welches Label tragen sollen (z.B. alle Seiten im HR-Hub = „Intern“, Extranet-Hub = „Extern erlaubt“). Diese Labels bewirken dann automatisch bestimmte Einstellungen (externe Freigabe aus, Watermarking an Dokumenten, etc.). Aufbewahrungsrichtlinien können Sie im Compliance Center erstellen und auf Sites oder Inhaltstypen anwenden – z.B. eine Policy „Lösche News nach 2 Jahren“ oder „Bewahre QM-Dokumente 10 Jahre auf“. In den Hub-Kontext integriert man das, indem man die Richtlinien entwirft und testet, bevor der Hub live geht, und dann überwacht, dass sie wirken (Audit-Logs, Compliance Berichte). Praktisch heißt das: Bevor Inhalte eingestellt werden, wissen die Owner schon, wie lange sie bleiben und wie sie klassifiziert sind.
19. Wie bereite ich die Migration bestehender Sites zu Hubs vor?
    Zuerst analysiert man den Ist-Zustand: Welche Sites (auch alte SharePoint-On-Prem oder File Shares) sollen ins neue Modell? Dann entwirft man das Ziel-Hub-Konzept (z.B. 5 Hubs: Intranet, Teamspaces, Projektportfolio, etc.). Für jede bestehende Site ordnet man zu, in welchen Hub sie migrieren soll – das Mapping. Bereiten heißt auch, die Inhalte zu modernisieren: Alte klassische Seiten vielleicht als moderne Seiten neu erstellen, Navigation an neue Strukturen anpassen. Außerdem sollten die Besitzer der alten Sites ins Boot geholt werden, um doppelte/überflüssige Inhalte vorher zu bereinigen (Migration als Chance zur Aufräumaktion). Technisch kann man Migrationstools (SPO Migration Tool, Third Party) einsetzen, aber oft ist es ein manueller Prozess, insbesondere bei Neustrukturierung. Wichtig: Nutzer rechtzeitig informieren, Redirects einrichten (damit alte URLs auf den neuen Hub zeigen) und nach der Migration prüfen, ob Berechtigungen und Webparts korrekt funktionieren. Eine Testmigration im kleinen Umfang (Pilot) hilft, die Methode festzulegen.
20. Welche Prüfungen sind vor dem Go-Live zwingend?
    Eine Art Abnahme-Check: Ist die Navigation vollständig und freigegeben? Sind Berechtigungen korrekt gesetzt und getestet (z.B. ein Testnutzer mit gewissen Rechten ausprobiert)? Wurden Inhalte Korrektur gelesen und haben sie den richtigen Status (Entwürfe verborgen, nur final veröffentlichtes online)? Funktioniert die Suche wie erwartet (wichtige Inhalte erscheinen)? Ist die Seite performant und mobil abrufbar (Test auf verschiedenen Geräten)? Sind alle Stakeholder einverstanden (Fachbereichsleiter, IT, Compliance)? Wurden Kommunikations- und Hilfsmaterialien vorbereitet? Kurz: Ein finaler Testdurchlauf mit Nutzerperspektive, plus Abstimmung „Go“ von allen Verantwortlichen, bevor die breite Masse draufgelassen wird.
21. Wie gehe ich mit Such-Nulltreffern und Fehlnavigationen um?
    Nulltreffer (Suchanfragen ohne Ergebnis) sollten regelmäßig analysiert werden. Für häufige Nulltreffer-Fragen: Entweder Inhalt erstellen, wenn etwas Relevantes wirklich fehlt, oder Synonyme/Keywords hinzufügen, wenn es den Inhalt gibt, aber anders benannt. Fehlnavigation (Nutzer klicken oft falsch oder finden etwas unter dem falschen Menüpunkt) erkennt man entweder durch Nutzerfeedback oder Analysen (z.B. häufige interne Suche nach Inhalten, die eigentlich im Menü sein sollten). Hier hilft es, die IA (Informationsarchitektur) nachzujustieren: ggf. Menüpunkte umbenennen, umplatzieren oder zusätzliche Links einfügen. Auch „Friendly 404 pages“ mit Hinweisen oder eine gute Hub-Sitemap können helfen, dass sich verlorene Nutzer fangen. Letztlich ist das ein fortlaufender Optimierungsprozess: beobachten, Feedback einholen, anpassen.
22. Wie gestalte ich ein mehrsprachiges Hub-Erlebnis?
    SharePoint bietet out-of-the-box die Mehrsprachigkeit für Seiten: Man kann eine Standardsprache definieren und Übersetzungen der Seiten in anderen Sprachen anbieten. Für ein Hub bedeutet das: den Hub als Ganzes auf mehrere Sprachen ausrichten. Praktisch richtet man am Hub (der Hub-Site) die „mehrsprachige Website“-Funktion ein und wählt die benötigten Sprachen. Dann kann man die Navigationspunkte in diese Sprachen übersetzen und Inhaltsseiten in Varianten erstellen. Wichtige Hub-Seiten (Start, News) sollten in den Hauptsprachen verfügbar sein. Alternativ, falls komplett unterschiedliche Inhalte pro Sprache gebraucht werden, könnte man separate Hubs pro Sprache haben – das ist aber meist übertrieben, besser in einem Hub mit Übersetzungen arbeiten. Wichtig: Ein Team muss die Übersetzungen pflegen, sonst driften Sprachen auseinander. Zudem ist die Suchfunktion sprachunabhängig – man sollte also Sprache als Eigenschaft (z.B. in der Seitenbibliothek) markieren, um in der Suche filtern zu können. Ein mehrsprachiges Hub-Erlebnis erfordert Planung, aber SharePoint unterstützt es technisch gut.
23. Welche Auswirkungen haben Berechtigungs-Breaks in Hub-Sites?
    Ein „Berechtigungs-Break“ liegt vor, wenn innerhalb einer Site z.B. eine Bibliothek oder Seite eigene Berechtigungen hat (losgelöst von der Site-Vererbung). Im Hub-Kontext sieht der Nutzer nur Inhalte, für die er Rechte hat – Security Trimming filtert streng. Das heißt, wenn innerhalb einer Hub-Site ein Bereich abgetrennt ist, taucht dessen Inhalt für Unbefugte nirgendwo auf (weder in News noch in Suche oder Highlighted Content). Die Hauptauswirkung ist also: Der Hub präsentiert eventuell ein unvollständiges Bild für manche Nutzer, was verwirrend sein kann. Z.B. Hub-Navigation zeigt Link „Vertrauliches Projekt“, der Nutzer klickt und bekommt „Zugriff verweigert“ – daher sollte man solche Links per Audience Targeting ausblenden oder kennzeichnen. Grundsätzlich funktionieren Berechtigungs-Breaks wie gewohnt, aber man muss in der Hub-Governance entscheiden, ob man so etwas zulässt (es erhöht Komplexität). Ideal ist, pro Site möglichst einheitliche Berechtigungen zu haben und stark abweichende Inhalte eher auf separate Sites zu legen.
24. Wie adressiere ich regulatorische Anforderungen (DSGVO, Archivierung) im Hub-Kontext?
    Regulatorische Anforderungen greifen auch im Hub: DSGVO verlangt z.B., dass personenbezogene Daten nur bestimmten Berechtigten zugänglich sind und bei Austritt gelöscht werden. In Hubs sollte man also sicherstellen, dass solche Daten nur in Hubs/Sites liegen, wo die Berechtigung passt (z.B. Personaldaten nur im HR-Hub mit eingeschränktem Zugriff). Archivierungspflichten (z.B. 10 Jahre Aufbewahrung) erreicht man, indem man Aufbewahrungsrichtlinien auf die entsprechenden Hub-Inhalte anwendet – etwa eine automatische Archivierung von Dokumenten nach X Jahren. SharePoint Compliance Center ermöglicht das über Labels/Policies. Wichtig ist auch die Auskunfts- und Löschfähigkeit: über eDiscovery kann man hub-übergreifend suchen, falls jemand nach DSGVO wissen will „welche Daten von mir liegen wo“. Daher ist eine klare Struktur (z.B. alle HR-Daten im HR-Hub) hilfreich. Genauso muss man bei einem Löschersuchen gezielt in den betreffenden Hub gehen können und dort Inhalte entfernen. Fazit: Man erfüllt regulatorische Anforderungen, indem man Hubs thematisch sauber abgrenzt, Compliance-Features (Labels, Policies, Audit) konsequent nutzt und die Prozesse (z.B. jährliche Datenüberprüfung, Löschroutinen) in die Hub-Governance einbaut.
25. Wie plane ich Rezertifizierungen von Zugang, Navigation und Inhalten?
    Rezertifizierung bedeutet regelmäßige erneute Prüfung/Bestätigung, dass etwas noch gültig ist. Im Hub-Kontext gibt es drei Ebenen: Zugang – z.B. alle 6 oder 12 Monate überprüfen, ob die eingestellten Berechtigungen (vor allem externe Nutzer oder breite Gruppen) noch passen. Das kann per Access Review (Azure AD) oder manuell per Checkliste geschehen, wo Site-Owner bestätigen müssen, dass alle aufgeführten Personen noch Zugriff haben sollen. Navigation – man könnte jährlich einen Navigations-Review machen (entspricht dem in Checkliste 13 genannten): Sind alle Menüpunkte noch relevant, stimmen Bezeichnungen, müssen neue Punkte rein? Inhalte – Rezertifizierung von Inhalten heißt z.B., Dokument-Eigentümer müssen einmal im Jahr prüfen, ob ihre Seite/Dokument noch aktuell ist (das kann SharePoint via Seite-Expiration-Flow unterstützen oder manuell via Erinnerungsmails). Diese Überprüfungen sollten im Hub-Governance-Plan verankert sein. Im Idealfall gibt es für jede dieser Rezertifizierungen ein kleines Workflow: z.B. IT sendet quartalsweise Bericht über Zugriffsgruppen an Hub-Owner zur Bestätigung, oder eine Power Automate Lösung markiert Seiten als „Review fällig“ nach X Monaten. So bleibt der Hub „frisch“ und sicher.

15. Fazit & Nächste Schritte

Die Einführung von SharePoint-Hubs bringt Struktur, aber erfordert auch Engagement und Pflege. Abschließend sind hier konkrete nächste Schritte aufgeführt, nach Priorität und Zeithorizont gegliedert:

0–30 Tage (sofort umsetzbar):
– Governance-Team aufsetzen: Benennen Sie die Hub-Verantwortlichen (Owner, Admin, Redaktion etc.) und stimmen Sie grundlegende Regeln ab.
– Pilotbereich auswählen: Definieren Sie einen Hub (oder Teil eines Hubs) als Pilot und planen Sie dessen Umsetzung im kleinen Umfang.
– Inhalts- und Site-Inventar anlegen: Verschaffen Sie sich einen Überblick über bestehende Inhalte/Sites und ordnen Sie diese vorläufig der neuen Hub-Struktur zu.
– Schnelle Gewinne realisieren: Führen Sie einfache Verbesserungen ein – z.B. einheitliches Branding mit dem Hub-Theme auf bestehenden Sites oder eine provisorische Hub-Navigation – um Nutzen schnell sichtbar zu machen.
– Kommunikation starten: Informieren Sie Stakeholder und Nutzer über die geplanten Änderungen (Intranet-News, E-Mail der IT) und stellen Sie die Vorteile in den Vordergrund.

30–90 Tage (mittelfristig):
– Pilot-Hub implementieren: Setzen Sie den Pilot-Hub technisch um, migrieren Sie exemplarische Inhalte und sammeln Sie Feedback der Pilotnutzer.
– Schulungen & Guidelines: Führen Sie Trainings für Redakteure und Site-Owner durch. Stellen Sie Leitfäden bereit (z.B. „Hub Navigation gestalten“, „News erstellen im Hub“).
– Feedback-Auswertung: Analysieren Sie Rückmeldungen aus dem Pilot und justieren Sie Navigation, Berechtigungen oder Prozesse entsprechend nach.
– KPI-Baseline erheben: Erfassen Sie erste Kennzahlen (Nutzerzahlen, Suchstatistiken) als Ausgangswerte. Etablieren Sie ein Dashboard, um Fortschritte messbar zu machen.
– Weitere Migration planen: Erstellen Sie einen detaillierten Migrationsplan für verbleibende Bereiche: Reihenfolge, Verantwortliche, Timing. Nutzen Sie die Lessons Learned aus dem Pilot, um Fallstricke zu vermeiden.

> 90 Tage (langfristig):
– Rollout auf Breite: Nach erfolgreichem Pilot sukzessive Ausweitung des Hub-Konzepts auf alle vorgesehenen Bereiche/Regionen. Dabei stets die Qualität sicherstellen (lieber schrittweise als alles auf einmal).
– Regelbetrieb etablieren: Integrieren Sie Hub-Management in die Routine – regelmäßige Governance-Meetings, vierteljährliche Reviews von Navigation/Suche, jährliche Berechtigungschecks, etc.
– Weiterentwicklung & Features: Behalten Sie neue SharePoint-Funktionen im Blick (z.B. Updates in der Suche, Viva Connections) und prüfen Sie, wie diese Ihre Hubs bereichern können. Planen Sie ggf. Upgrades oder Erweiterungen (z.B. Integration eines Bots, neuer Hub für neues Geschäftsfeld).
– Kontinuierliches Training: Aktualisieren Sie Schulungsmaterial und führen Sie Auffrischungs-Workshops durch, vor allem wenn personelle Wechsel stattfinden oder neue Redakteure hinzukommen.
– Kultur und Akzeptanz fördern: Feiern Sie Erfolge (z.B. Meilenstein „1000 News veröffentlicht“ oder positive Umfragewerte) öffentlich im Unternehmen, um die Akzeptanz hoch zu halten. Holen Sie regelmäßig Nutzerfeedback ein (durch Umfragen oder Dialogformate) und zeigen Sie, dass der Hub lebt und sich an Nutzerbedürfnisse anpasst.

Vom Pilot zum Standard: Sobald der Hub-Ansatz unternehmensweit ausgerollt ist, geht es darum, ihn zum festen Bestandteil der digitalen Arbeitsumgebung zu machen. Das bedeutet, neue Projekte oder Abteilungen bekommen automatisch einen Platz im richtigen Hub (statt eigenständig Wildwuchs zu erzeugen), neue Inhalte werden nach den definierten Prozessen erstellt, und die Mitarbeiter wissen, wohin sie sich wenden können (die Hub-Struktur als „Landkarte“ des Intranets). Es lohnt sich, die Erfahrungen aus der Einführungsphase in einem kurzen Leitfaden zu dokumentieren – quasi ein „Operating Model“ für Hubs. Dieser Leitfaden beschreibt knapp: 1) Governance-Struktur, 2) Do’s & Don’ts bei Navigation und Berechtigungen, 3) Vorgehen bei Änderungen, und 4) Supportwege. So wird aus dem einmaligen Projekt „Hub-Einführung“ ein nachhaltiger Standard im Unternehmen. Mit klaren Verantwortlichkeiten, regelmäßiger Pflege und einer lernenden Haltung (Feedback aufnehmen, iterativ verbessern) entwickeln sich die SharePoint-Hubs vom Pilot zum etablierten Informationsfundament – und bieten dauerhaft einen Mehrwert in Architektur, Governance, Betrieb und Praxis.

Weitere Beiträge zum Thema SharePoint und Teams