Inhaltsverzeichnis
Ein strategischer Leitfaden für CIOs, IT-Leiter, HR und Internal Comms zum Aufbau eines verwalteten, KI-tauglichen Intranets auf Microsoft 365
Bevor wir anfangen — dieser Artikel zeigt Ihnen nicht, wie Sie ein Intranet technisch aufbauen. Microsoft stellt dafür hervorragende Ressourcen und Vorlagen bereit, und wir empfehlen Ihnen, mit dem SharePoint-Intranet-Planungsleitfaden auf Microsoft Learn zu starten.
Was wir hier tun möchten, ist etwas anderes. Wir möchten Ihnen zeigen, warum so viele Intranets zu einer Belastung statt zu einem Gewinn werden — und wie Sie Ihres so planen und aufbauen, dass Sie dieselben Fehler nicht wiederholen. Das basiert direkt auf unserer Erfahrung aus der Arbeit mit Organisationen verschiedenster Branchen: beim Audit bestehender Intranets und beim Aufbau neuer auf Microsoft 365.
Warum die meisten Intranets scheitern
Immer wenn wir ein bestehendes Intranet auditieren, stoßen wir auf dieselben drei Herausforderungen — unabhängig von Plattform, Organisationsgröße oder Branche. Wir möchten Ihnen helfen, diese zu verstehen, bevor Sie Technologie auswählen oder konfigurieren, denn das ist der wichtigste erste Schritt.
Herausforderung 1: Einmal gebaut, nie verwaltet
Das Intranet startet mit einer soliden Struktur, gut geschriebenen Inhalten und begeisterter Nutzung. Sechs Monate später tauchen die ersten veralteten Seiten auf. Ein Jahr später gibt es doppelte Richtlinienseiten, defekte Links und Bereiche, die seit dem Go-live niemand mehr angefasst hat. Die Plattform ist nicht das Problem — das Fehlen eines Content-Lebenszyklus-Prozesses ist es.
Wir sehen das in fast jeder Organisation, mit der wir arbeiten. Der Aufbau bekommt Investitionen und Aufmerksamkeit. Die Governance nicht.
Herausforderung 2: Kein Verantwortungsmodell
Jedes Intranet braucht jemanden, der Verantwortung trägt — nicht für die Plattform, sondern für jeden Inhaltsbereich. Wenn Verantwortlichkeiten unklar sind, wird der Inhalt zur Aufgabe aller und damit zur Aufgabe von niemandem. Die IT hält den Betrieb aufrecht. Communications veröffentlicht Ankündigungen. Aber niemand stellt die entscheidende Frage: Ist dieser Bereich noch aktuell, und gehört er überhaupt noch hierher?
Das Muster, das wir am häufigsten sehen: Die IT besitzt die Technologie, die Fachbereiche besitzen die Inhalte — und keine Seite hat ein klares Bild davon, wofür die andere verantwortlich ist. Das Ergebnis ist eine langsame Anhäufung von Inhalten, die niemand die Befugnis hat zu entfernen.
Herausforderung 3: Für die IT gebaut, nicht für die Mitarbeitenden
Die Navigation spiegelt wider, wie die IT Daten organisiert — nicht, wie Mitarbeitende über ihre Arbeit nachdenken. Bezeichnungen sind Abteilungsnamen statt aufgabenorientierter Labels. Die Suche liefert zu viele Ergebnisse mit zu wenig Kontext. Das Intranet wird zu einem Ort, den Menschen nur besuchen, wenn sie müssen — für das Spesenformular, den IT-Helpdesk-Link, die obligatorische Schulung.
Wir haben Intranets mit wunderschön gestalteten Homepages gesehen, die Mitarbeitende so beschreiben: „Schaut gut aus, aber ich finde nie etwas.“ Die Struktur ergab für das aufbauende Team Sinn. Für die Nutzenden nicht.
Sie befinden sich wahrscheinlich in einer dieser drei Situationen:
- Noch kein Intranet — Sie haben die Möglichkeit, es von Anfang an richtig aufzubauen, ohne Migrationslast oder eingefahrene Gewohnheiten
- Ein veraltetes oder Drittanbieter-Intranet — Ihre bestehende Plattform ist entweder am Ende ihres Lebenszyklus, zu wenig verwaltet oder vom Rest Ihrer Microsoft 365-Investition abgekoppelt
- SharePoint bereits im Einsatz, aber ohne Governance — Sie haben die Plattform und die Inhalte, aber das Governance-Modell wurde nie entworfen, und die angesammelte Last ist jetzt sichtbar
In allen drei Fällen ist der Weg nach vorne derselbe. Erst Governance, dann bauen.
Warum SharePoint die richtige Plattform ist
Das strategische Argument für SharePoint dreht sich nicht um Funktionen. Es geht um Integration, Gesamtbetriebskosten und KI-Bereitschaft. So vermitteln wir es, wenn wir mit Führungsteams arbeiten:
Es ist bereits in Ihrer Lizenz enthalten
Wenn Sie Microsoft 365 E3 oder höher nutzen, ist SharePoint inklusive. Sie zahlen nicht für eine zusätzliche Plattform. Jeder Euro oder Dollar, der für ein Drittanbieter-Intranet-Produkt ausgegeben wird, ist ein Aufwand, den SharePoint nicht verursacht — und ein separates Governance-Gespräch, das SharePoint nicht erfordert.
Es ist der tiefste Integrationspunkt in Microsoft 365
SharePoint ist keine eigenständige Intranet-Plattform. Es ist die Dokumentenspeicherschicht hinter Teams. Es ist die Inhaltsquelle, über die Copilot schlussfolgert. Es speist Viva Connections für die Employee-Experience-Schicht. Es integriert sich nativ mit Microsoft Search, Purview für Compliance, Entra für Identität und Berechtigungen sowie Places für die Koordination hybrider Arbeitsplätze. Keine Drittanbieter-Plattform kann dieses Integrationsniveau ohne benutzerdefinierte Connectors erreichen, die ihren eigenen Overhead und ihre eigene Governance-Komplexität mitbringen.
Drittanbieter-Intranet-Produkte lösen UX-Probleme, indem sie Governance-Probleme schaffen
Plattformen wie Powell Intranet oder Omnia bieten polierte Vorlagen und schnellere Ergebnisse. In bestimmten Situationen sind sie es wert, in Betracht gezogen zu werden. Sie fügen jedoch eine Lizenzierungsschicht hinzu (3–8 US-Dollar pro Nutzer und Monat), eine separate Anbieterbeziehung und ein Inhaltsmodell, das auf SharePoint aufsetzt statt Teil davon zu sein. Wenn diese Plattformen abgelöst werden — und das passiert früher oder später immer — kehrt die Governance-Frage zu SharePoint zurück. Wir helfen Ihnen lieber einmal dabei, dieses Governance-Modell auf der Plattform aufzubauen, die Sie bereits besitzen.
Es ist der Ort, an dem Ihr KI-Wert entsteht
Wir haben das ausführlich in unserem Artikel über SharePoint als KI-Kontrollebene beschrieben. Kurz gesagt: Microsoft 365 Copilot schlussfolgert über SharePoint-Inhalte. Intranetseiten, Dokumentenbibliotheken und Site-Daten sind allesamt Eingaben für das Wissensmodell von Copilot. Ein auf SharePoint aufgebautes und verwaltetes Intranet macht Copilot zuverlässiger. Eines, das auf einer Drittanbieter-Plattform aufgebaut wurde, trägt ohne zusätzliche Connector-Konfiguration nichts zu diesem Modell bei — und selbst dann hängt die Qualität des Beitrags vollständig davon ab, was Sie aufgebaut und wie Sie es verwaltet haben.
Die Beziehung zwischen Teams und SharePoint
Dies ist die am häufigsten missverstandene Beziehung in Microsoft 365. In fast jeder Organisation, mit der wir arbeiten, werden Teams und SharePoint als separate Produkte betrachtet. Das sind sie nicht. Sie sind zwei Oberflächen derselben zugrunde liegenden Plattform — und dieses Verständnis verändert, wie man über Governance nachdenkt.
Was unter der Haube tatsächlich passiert
Wenn ein Team in Microsoft Teams erstellt wird, wird dahinter automatisch eine SharePoint-Websitesammlung bereitgestellt. Die Registerkarte „Dateien“ in jedem Kanal ist eine SharePoint-Dokumentenbibliothek. Wenn Ihre Kolleginnen und Kollegen Dokumente in Teams teilen, leben diese Dokumente in SharePoint. Wenn Copilot die Dateien eines Teams durchsucht, durchsucht es SharePoint.
Das bedeutet: SharePoint-Governance ist Teams-Governance. Berechtigungen, die auf einer SharePoint-Site gesetzt werden, beeinflussen, worauf Personen über Teams zugreifen können. Metadaten, die in einer SharePoint-Bibliothek angewendet werden, beeinflussen, wie Dokumente in der Teams-Suche erscheinen. Informationsarchitektur-Entscheidungen, die in SharePoint getroffen werden, bestimmen, wie Inhalte beim Zugriff über Teams organisiert sind. Man kann das eine nicht verwalten, ohne das andere zu verwalten.
Wie wir Kunden dabei helfen, das zu verstehen
Anstatt zu fragen „Sollen wir Teams oder SharePoint verwenden?“, fragen wir: In welcher Oberfläche leben diese Inhalte, und über welche Oberfläche begegnen ihnen die Mitarbeitenden?
- SharePoint-Intranetseiten verwenden für Inhalte, die an ein breites Publikum ausgestrahlt werden — Unternehmensnachrichten, Richtlinien, Verfahren, HR-Informationen, organisationale Programme. Inhalte, die von vielen gefunden, von wenigen verfasst werden
- Teams verwenden für Inhalte, die kollaborativ innerhalb einer definierten Gruppe erstellt und bearbeitet werden — Projektdateien, Arbeitsentwürfe, teamspezifische Dokumente
- SharePoint-Intranetinhalte über Teams via Viva Connections zugänglich machen — damit Mitarbeitende auf Intranet-News und Richtlinieninhalte zugreifen können, ohne Teams jemals zu verlassen
Da Teams und SharePoint dieselbe Datenschicht teilen, deckt ein Governance-Modell, das das SharePoint-Intranet abdeckt, automatisch die Dokumentenbibliotheken hinter jedem Team ab. Das ist eines der überzeugendsten Argumente dafür, das SharePoint-Governance-Modell zu entwerfen, bevor Ihr Teams-Einsatz weiter skaliert.
Governance zuerst: Das strategische Konzept vor dem Aufbau
Der größte Fehler, den wir bei Organisationen beobachten, ist der Start mit der Plattform, bevor die Governance entworfen wurde. Sites werden erstellt, Inhalte werden veröffentlicht, Navigation wird konfiguriert — und sechs Monate später fragt jemand, wer den HR-Bereich besitzt, und niemand hat eine klare Antwort.
Nachträglich hinzugefügte Governance ist immer teurer und störender als Governance, die vor der Erstellung der ersten Site entworfen wurde. Die fünf Schritte unten repräsentieren das Fundament, das wir mit jedem Kunden legen, bevor technische Arbeiten beginnen. Keiner davon erfordert SharePoint-Konfiguration. Es sind Entscheidungen, die zuerst getroffen und dokumentiert werden müssen.
Ihr Intranet braucht zwei Ebenen der Verantwortlichkeit, und nach unserer Erfahrung denken die meisten Organisationen nur an eine davon.
Die erste ist ein Plattformverantwortlicher: die Person, die für das gesamte Intranet verantwortlich ist — seine Informationsarchitektur, Navigation, Qualitätsstandards und das Governance-Modell. Das liegt üblicherweise bei IT oder Digital Workplace, braucht aber eine namentlich genannte Einzelperson, kein Team. „Das IT-Team besitzt das Intranet“ ist keine Verantwortlichkeit. Es ist Verwässerung von Rechenschaftspflicht.
Die zweite ist Bereichsverantwortlichkeit: Jeder größere Inhaltsbereich braucht einen Fachverantwortlichen, der für die Genauigkeit, Relevanz und den Lebenszyklus der Inhalte in seinem Bereich verantwortlich ist. Dokumentieren Sie, was das in der Praxis bedeutet: Der Eigentümer überprüft Inhalte in einem definierten Rhythmus, genehmigt neue Seiten in seinem Bereich und ist die Eskalationsstelle, wenn Inhalte veraltet oder umstritten werden.
Wie wir das machen: Bevor Sites erstellt werden, führen wir eine einstündige Verantwortlichkeits-Mapping-Session mit IT und den relevanten Fachbereichsleitungen durch. Wir verlassen die Session mit einem namentlich genannten Eigentümer für jeden Intranet-Bereich und einem einseitigen Brief, der definiert, was Eigentümerschaft in der Praxis für jeden von ihnen bedeutet.
Ohne eine explizite Content-Richtlinie trifft jeder seine eigenen Entscheidungen — und diese Entscheidungen sind inkonsistent. Wir sehen das ständig. Ein Team veröffentlicht ein Projektupdate als Intranet-News. Ein anderes erstellt einen Teams-Kanal für dasselbe Projekt. Ein drittes schickt ein PDF per E-Mail an die Verteilerliste. Dieselbe Information landet an drei Orten, keiner davon maßgeblich.
Die Content-Richtlinie beantwortet drei Fragen: Welche Inhaltstypen gehören ins Intranet? Was gehört nach Teams? Was gehört in eine SharePoint-Dokumentenbibliothek? Sie muss nicht lang sein. Eine Seite reicht.
Wie wir das machen: Wir entwickeln gemeinsam mit dem Kunden eine einfache Content-Entscheidungsmatrix — üblicherweise in einem 90-minütigen Workshop mit IT, Communications und einem oder zwei Fachbereichsleitungen. Wenn ein Content-Ersteller unsicher ist, wohin etwas gehört, beantwortet die Matrix die Frage — ohne IT-Ticket.
Namenskonventionen und Site-URL-Strukturen lassen sich nach der Erstellung und Verlinkung von Sites kaum noch ändern. Eine Site, die als /sites/HR-Richtlinien-2023 erstellt wurde, trägt diese URL bis 2026 und darüber hinaus — auch wenn die Inhalte nichts mit 2023 zu tun haben. Informell getroffene Benennungsentscheidungen zu Beginn eines Aufbaus setzen einen Präzedenzfall, dem andere Site-Ersteller folgen — meist inkonsistent.
Wie wir das machen: Wir definieren Namenskonventionen für drei Ebenen, bevor der Aufbau beginnt. Sites verwenden ein Abteilung-Funktion-Muster (z.B. HR-Benefits, IT-ServiceDesk). Hub-Sites verwenden ein Geschäftsdomänen-Muster (z.B. HumanResources, InformationTechnology). Seiten verwenden beschreibende, suchoptimierte Titel — keine Daten, keine Initialen, keine Projektkennzeichen. Diese Konventionen werden als Teil des Site-Erstellungs-Genehmigungsprozesses durchgesetzt.
[Domäne]-Hub, alle Abteilungs-Sites verwenden [Abteilung]-[Funktion], keine Site-Namen enthalten Jahresangaben, Initialen oder Projektkennzeichen. Dieses Gespräch, das weniger als einen Vormittag dauerte, verhinderte jahrelange URL-Schulden und machte Suchergebnisse sofort vorhersehbarer.Geschäftsdomänen sind stabiler und konsistenter, während Organigramme sich ändern. Wenn Sie ein Intranet um das Organigramm herum aufbauen, erfordert es jedes Mal eine Neustrukturierung, wenn sich die Organisation reorganisiert. Wir haben das erlebt, und es ist teuer und demoralisierend für die beteiligten Teams.
Wir empfehlen den Aufbau um Geschäftsdomänen — Finance, HR, Legal, Operations, Technology, Communications — damit Sie während Reorganisationen keine Neustrukturierung vornehmen müssen. Die Domänen bleiben bestehen, auch wenn sich die Berichtslinien verschieben.
Wie wir das machen: Wir kartieren Ihre Hub-Struktur auf fünf bis acht Domänen, die widerspiegeln, wie Mitarbeitende nach Informationen suchen — nicht, wie die Führung organisiert ist. Wir testen das mit einer einfachen Frage an einen Querschnitt von Mitarbeitenden: Wenn Sie die Spesenrichtlinie finden möchten, an welche Domäne denken Sie zuerst? Wenn die Antwort nicht zur vorgeschlagenen Navigation passt, ändert sich die Navigation.
Wie wir es gemacht haben: Ein Einzelhandelsunternehmen mit 1.500 Mitarbeitenden hatte sein Intranet ursprünglich um seine vier Geschäftsbereiche herum aufgebaut. Nach einer Reorganisation achtzehn Monate später benötigte das Intranet eine erhebliche Neustrukturierung. Beim zweiten Versuch halfen wir ihnen, es um sechs funktionale Domänen neu zu gestalten:
- People
- Technology
- Finance
- Operations
- Customer
- Legal
Diese Struktur blieb durch zwei weitere Organisationsveränderungen stabil. Dieselben Mitarbeitenden, die sich beschwert hatten, das Intranet bei jeder Strukturveränderung neu erlernen zu müssen, stellten das Thema vollständig ein.
Die meisten Intranet-Projekte werden am Go-live-Datum gemessen. Das ist die falsche Metrik. Das nützlichere Maß ist die Startbereitschaft: Welche Bedingungen müssen erfüllt sein, bevor das Intranet an Mitarbeitende freigegeben wird?
Ohne explizite Startkriterien geht das Intranet live, wenn es „gut genug“ ist — was meist bedeutet, mit strukturellen Lücken, die sofort sichtbar sind und einen ersten Eindruck erzeugen, der sich nur schwer wieder korrigieren lässt. Mitarbeitende bilden sich bei den ersten Besuchen eine Meinung über das Intranet, und „beim Start kaputt“ bleibt haften.
Wie wir das machen: Wir definieren mit jedem Kunden eine Startcheckliste, bevor der Aufbau beginnt. Sie umfasst typischerweise: Jeder Bereich hat einen namentlich genannten Eigentümer, jeder Eigentümer wurde eingewiesen, die zwanzig am häufigsten abgefragten Inhalte sind veröffentlicht und geprüft, die Navigation wurde mit Mitarbeitenden aus mindestens drei verschiedenen Rollen getestet, und die Suche liefert relevante Ergebnisse für die zehn häufigsten Anfragen.
Governance in Microsoft 365: So richten Sie es ein
Hub-Sites sind das primäre strukturelle Element eines modernen SharePoint-Intranets. Anders als das alte Untersite-Modell — starr, hierarchisch, teuer zu ändern — modellieren Hub-Sites Beziehungen als Links. Eine Site kann mit einem Hub verknüpft werden, ohne ihm zu gehören, und diese Verknüpfung kann sich ändern, wenn sich die Organisation ändert.
Hub-Sites beschränken auch die Suche automatisch. Wenn jemand von einer beliebigen mit dem HR-Hub verknüpften Site sucht, erhält er Ergebnisse aus der gesamten HR-Hub-Familie, gefiltert nach seinen Berechtigungen. Erstellen Sie Hub-Sites für jede der im Governance-Abschnitt oben definierten Geschäftsdomänen. Bestimmen Sie einen Root-Intranet-Hub als Home-Site. Und vermeiden Sie es, für jedes Team oder jede Abteilung einen Hub zu erstellen — Hubs sollten große logische Gruppierungen repräsentieren, keine einzelnen Einheiten.
Im SharePoint Admin Center erlaubt die Standardeinstellung in vielen Mandanten jedem Nutzer, eine SharePoint-Site zu erstellen. Das ist der Haupttreiber von Site-Sprawl. Diese Einstellung auf IT-Genehmigung zu ändern — oder die Erstellung über einen verwalteten Anfrageprozess zu leiten — ist eine der wirkungsvollsten Governance-Maßnahmen, die zur Verfügung stehen. Sie ist kostenlos zu implementieren und dauert einen Nachmittag.
Wir implementieren ein leichtgewichtiges Anfrageformular mit Power Automate, das drei Dinge erfasst: den beabsichtigten Zweck der Site, den vorgeschlagenen Eigentümer und den Hub, mit dem sie verknüpft werden soll. Ein Genehmigungsprozess am selben Tag fügt kaum Reibung hinzu, gibt der IT aber die Sichtbarkeit, um zu verhindern, dass sich strukturelle Schulden ansammeln.
Die meisten Intranetseiten sollten für alle Mitarbeitenden lesbar sein — aber bestimmte Bereiche brauchen mehr kontrollierten Zugriff. Führungskommunikation, Inhalte vor Ankündigungen, eingeschränkte Richtlinienentwürfe: Diese sollten nicht für jeden zugänglich sein, und die seitenweise Verwaltung von Berechtigungen schafft einen Governance-Overhead, der nicht skaliert.
Wir konfigurieren Vertraulichkeitsbezeichnungen auf Site-Ebene in Microsoft Purview, was es der IT ermöglicht, Zugangsdifferenzierungen automatisch durchzusetzen. Auf Mandantenebene setzen wir die Standard-Freigabe für Intranet-Sites auf „Personen in Ihrer Organisation“, mit strengeren Einstellungen für sensible Hubs — Legal, Finance, HR Executive.
Microsoft 365 bietet im SharePoint Admin Center Site-Lifecycle-Management-Tools, die inaktive Sites automatisch erkennen, Eigentümer benachrichtigen und Archivierungs- oder Lösch-Workflows einleiten können. Konfigurieren Sie diese vor dem Start, nicht nachdem die Umgebung unkontrolliert gewachsen ist. Die Kosten der Konfiguration vor dem Start sind ein Nachmittag. Die Kosten der Nicht-Konfiguration sind ein Wiederaufbau drei Jahre später.
Wir setzen einen Inaktivitätsschwellenwert von 90 Tagen und konfigurieren automatische Benachrichtigungen an Eigentümer, wenn eine Site diesen Schwellenwert überschreitet. Wenn der Eigentümer nicht antwortet: eine zweite Benachrichtigung, dann IT-Überprüfung, dann Archivierung. Archivierte Sites bleiben für die IT zugänglich, werden aber aus Navigation und Suche entfernt, was Rauschen reduziert, ohne permanenten Datenverlust zu riskieren.
Der SharePoint Admin Agent — verfügbar im SharePoint Admin Center für Organisationen mit Microsoft 365 Copilot-Lizenzen — bietet KI-gestütztes Governance-Monitoring über den gesamten Mandanten. Er identifiziert inaktive Sites, erkennt Überteilungsmuster, markiert Berechtigungsanomalien und gibt Empfehlungen zur Verbesserung.
Wir weisen einen namentlich genannten IT-Administrator zu, der seine Erkenntnisse monatlich überprüft und handelt. Wir verbinden diese Erkenntnisse mit dem Site-Lebenszyklus-Prozess in Schritt 4 — Admin-Agent-Erkenntnisse lösen denselben Benachrichtigungs- und Überprüfungs-Workflow aus wie die automatische Inaktivitätserkennung. Governance als kontinuierlicher Prozess, nicht als jährliches Ereignis.
Microsoft Purview erweitert die Governance über die nativen SharePoint-Einstellungen hinaus auf das vollständige Compliance-Framework: Verhinderung von Datenverlust, Aufbewahrungsrichtlinien, eDiscovery und Audit-Protokollierung. Für Organisationen in regulierten Branchen — Finanzdienstleistungen, Gesundheitswesen, Recht, öffentlicher Sektor — ist das nicht optional. Für alle anderen ist es die Compliance-Infrastruktur, die unverzichtbar wird, wenn das Intranet skaliert.
Wir konfigurieren Aufbewahrungsbezeichnungen für Intranet-Inhaltskategorien: Richtlinien (sieben Jahre), organisationale Ankündigungen (zwei Jahre), Projektdokumentation (fünf Jahre nach Projektabschluss). Wir wenden diese automatisch basierend auf Inhaltstyp oder Speicherort mithilfe der Auto-Label-Funktionen von Purview an — damit Inhalts-Eigentümer nicht über Aufbewahrung nachdenken müssen. Es wird auf Richtlinienebene durchgesetzt.
Der Lebenszyklus von Tools: So verhindern Sie, dass Ihr Intranet zum Problem von morgen wird
Der häufigste Grund, warum ein gut gebautes Intranet zum Problem wird, ist, dass es als Projekt statt als Produkt behandelt wird. Projekte haben Enddaten. Produkte haben Lebenszyklen. Wir haben Organisationen erlebt, die erhebliche Budgets für einen Wiederaufbau aufgewendet haben, nur um drei Jahre später wieder in derselben Situation zu sein, weil sich nichts an der Art und Weise, wie sie das Intranet nach dem Launch verwalten, geändert hat.
Plan umfasst Governance-Design und Informationsarchitektur. Build umfasst Konfiguration, Content-Erstellung und Testing. Launch umfasst Go-live, Mitarbeiterkommunikation und Adoption. Govern umfasst laufende Eigentümerschaft, Überprüfung und Lifecycle-Management. Evolve umfasst regelmäßige Verbesserungen basierend auf Nutzungsdaten, Feedback und Organisationsveränderungen.
Govern und Evolve sind die Bereiche, in denen die meisten Organisationen zu wenig investieren. Wir budgetieren eine vierteljährliche Intranet-Überprüfung als Teil des laufenden Betriebsmodells für jeden Kunden, mit dem wir arbeiten. Nicht als Projekt, nicht als einmaligen Audit — als stehenden Prozess.
Keine Seite sollte ohne einen namentlich genannten Eigentümer und ein definiertes Überprüfungsdatum veröffentlicht werden. In SharePoint setzen wir das durch Seitenmetadaten durch — ein erforderliches „Seiteneigentümer“-Feld und ein „Nächstes Überprüfungsdatum“-Feld auf jeder Communication-Site-Seite. Diese Felder fließen in Governance-Berichte und Admin-Agent-Dashboards ein und geben IT und Communications einen laufenden Überblick über den Content-Zustand.
Wir kalibrieren den Überprüfungszyklus auf den Inhaltstyp: Richtlinieninhalte jährlich überprüft, Programm- und Prozessdokumentation alle sechs Monate, zeitkritische Inhalte mit einem natürlichen Ablaufdatum. Diese Standards werden auf Inhaltstypebene festgelegt, sodass Eigentümer automatisch aufgefordert werden.
Ein Content-Audit ist eine strukturierte Überprüfung anhand eines einfachen Qualitätskriteriums-Sets: Ist es aktuell? Hat es einen Eigentümer? Wird es noch gebraucht? Dupliziert es etwas anderes? Stark frequentierte Seiten sollten vierteljährlich überprüft werden. Eine veraltete Richtlinie auf einer Seite, die niemand besucht, ist ein Governance-Problem. Auf Ihrer meistbesuchten Seite ist es ein Employee-Experience- und Compliance-Problem.
Wir nutzen SharePoint-Analysen — nativ in jeder modernen SharePoint-Site verfügbar — um die am stärksten frequentierten Seiten zu identifizieren. Wir integrieren den Audit-Kalender in die vierteljährliche Governance-Überprüfung und weisen spezifischen Eigentümern spezifische Seiten zu, anstatt eine breite „Bitte überprüfen Sie Ihre Seiten“-Kampagne durchzuführen, die inkonsistente Antworten erzeugt.
Seiten, die nicht mehr benötigt werden, sollten einen definierten Ausstiegspfad haben, keine unbegrenzte Existenz im Intranet. Wir definieren Deaktivierungskriterien für jeden Kunden: Eine Seite ist ein Kandidat für die Deaktivierung, wenn sie seit 90 Tagen nicht aufgerufen wurde, wenn ihr Inhalt durch eine neuere Seite abgelöst wurde oder wenn ihr Eigentümer bestätigt, dass sie nicht mehr benötigt wird.
Wir definieren auch, was eine deaktivierte Seite ersetzt. Wenn Mitarbeitende zu einer Seite navigiert sind und sie ohne Erklärung verschwindet, werden sie die IT kontaktieren. Eine Weiterleitung oder eine Navigationsänderung sollte Teil jeder Deaktivierungsmaßnahme sein — kein Nachgedanke.
Jedes Tool oder System, das in das Intranet integriert ist — eine Power App, die in eine Seite eingebettet ist, ein Power Automate-Flow, der von einem Formular ausgelöst wird, ein externer Connector, der HR-Systemdaten surfaced — ist eine Abhängigkeit. Wenn sich dieses Tool ändert oder abgeschaltet wird, bricht die Intranetseite, die davon abhängt. Wir haben das wiederholt erlebt, und es liegt immer daran, dass die Integration keinen Eigentümer hatte.
Wir wenden dieselben Eigentümer- und Überprüfungsanforderungen auf Integrationen an wie auf Inhaltsseiten. Jede Integration bekommt einen namentlich genannten Eigentümer, einen Überprüfungszyklus und einen Deaktivierungspfad. Wenn ein Tool abgeschaltet wird, wird der Intranet-Integrations-Eigentümer mit einem definierten Zeitfenster zur Aktualisierung oder Entfernung der Integration benachrichtigt.
Das Intranet ist nie fertig. Es ist ein lebendes Produkt, das den Zustand der Organisation widerspiegelt. Wenn sich Ihre Organisation verändert — neue Führung, eine Umstrukturierung, eine neue strategische Initiative, eine Änderung in der Arbeitsweise — sollte sich das Intranet damit verändern. Das erfordert laufende Investitionen, nicht nur einen Launch.
Die minimale laufende Investition für ein gut gepflegtes Intranet in einer Organisation mit 500 bis 5.000 Mitarbeitenden beträgt rund 0,2 bis 0,5 FTE — eine Teilzeit-Intranet-Manager-Rolle, innerhalb von IT oder Communications, deren primäre Verantwortung die Gesundheit des Intranets als Produkt ist. Wir empfehlen das immer als Teil des Übergangsplans beim Launch.
Benutzerfreundlichkeit: Für Adoption bauen, nicht nur für Struktur
Struktur ist die Voraussetzung. Adoption ist das Ziel. Ein Intranet, das perfekt verwaltet, aber selten besucht wird, hat versagt. So gehen wir Adoption bei jedem Kunden an:
Navigation für Mitarbeitende gestalten, nicht für die IT
Navigation sollte widerspiegeln, wie Mitarbeitende über ihre Arbeit nachdenken — nicht, wie die IT Daten kategorisiert. Wir testen jede vorgeschlagene Navigationsstruktur mit Mitarbeitenden aus verschiedenen Rollen und Betriebszugehörigkeiten, bevor wir bauen. Wir fragen sie, wo sie die Spesenrichtlinie, den IT-Helpdesk und den Leitfaden für neue Mitarbeitende erwarten würden. Wenn ihre Antworten nicht zur Navigation passen, ändert sich die Navigation — nicht die Mitarbeitenden.
Das Intranet über Teams via Viva Connections zugänglich machen
Der wirkungsvollste Adoptions-Treiber, den wir gefunden haben, ist es, das Intranet ohne eine separate URL zugänglich zu machen. Viva Connections bettet ein anpassbares Intranet-Dashboard direkt in die Teams-Seitenleiste ein — und bringt News, Tools und Richtlinieninhalte in die Oberfläche, die Menschen täglich nutzen. Für Organisationen, in denen Teams die primäre Arbeitsoberfläche ist, ist Viva Connections der Unterschied zwischen einem Intranet, das Menschen besuchen, und einem, dem sie tatsächlich begegnen.
Es zur einzigen maßgeblichen Quelle für kritische Informationen machen
Adoption folgt der Autorität. Wenn die Spesenrichtlinie im Intranet, in einem per E-Mail angehängten PDF und in einer Teams-Kanalnachricht existiert, verwenden Mitarbeitende die Version, die sie zuerst finden — und diese Version könnte veraltet sein. Wir deaktivieren alle anderen Versionen als Teil des Launch-Prozesses. Wenn Mitarbeitende lernen, dass das Intranet der Ort ist, an dem korrekte Informationen zu finden sind, gehen sie dorthin.
Personalisierung nutzen, um Inhalte relevant zu machen
Das Audience-Targeting von SharePoint erlaubt es, Inhalte — News, Quick Links, Ankündigungen — basierend auf dem Microsoft 365-Profil an bestimmte Gruppen zu richten. Ein Mitarbeitender im Londoner Büro sollte nicht an Frankfurt-spezifischen Ankündigungen vorbeiscrollen müssen, um das zu finden, was für ihn relevant ist. Wir konfigurieren Audience-Targeting von Anfang an, basierend auf derselben Organisationsstruktur, die die Hub-Architektur informiert.
Der KI-Aspekt: Warum Intranet-Qualität Copilot-Qualität bedeutet
Wir haben das ausführlich in unserem Artikel über SharePoint als KI-Kontrollebene beschrieben. Aber es lohnt sich, es hier zu wiederholen, weil es im Intranet-Kontext direkt umsetzbar ist — und weil es verändert, wie Sie Governance-Arbeit priorisieren.
Microsoft 365 Copilot schlussfolgert über SharePoint-Intranetseiten. Wenn ein Mitarbeitender Copilot fragt „Was ist die Elternzeitrichtlinie?“, durchsucht Copilot das Intranet. Wenn ein neuer Mitarbeitender fragt „Wen soll ich wegen IT-Zugang kontaktieren?“, durchsucht Copilot das Intranet. Die Qualität dieser Antworten — ihre Genauigkeit, Relevanz und Vertrauenswürdigkeit — ist eine direkte Funktion der Qualität der Seiten, über die Copilot schlussfolgert.
Für Menschen lesbar ist nicht dasselbe wie KI-tauglich. Eine Seite, die für die visuelle Wahrnehmung geschrieben wurde, gibt Copilot nicht zwingend das strukturierte, eindeutige Signal, das es braucht. Eine KI-taugliche Intranetseite hat einen klaren beschreibenden Titel, explizite Abschnittsüberschriften und Inhalte, die Fakten direkt nennen statt sie durch Layout zu implizieren.
Doppelte und veraltete Seiten werden durch KI verstärkt. Wenn zwei nahezu identische Richtlinienseiten existieren, liefert Copilot eine davon als Antwort — ohne die Mehrdeutigkeit zu kennzeichnen. Eine einzige maßgebliche Seite pro Thema zu pflegen ist kein Content-Qualitätsproblem. Es ist ein KI-Zuverlässigkeitsproblem.
Die Governance-Investition aus den obigen Abschnitten ist nicht nur eine Intranet-Investition. Sie ist eine Copilot-Zuverlässigkeitsinvestition. Jede entfernte veraltete Seite, jede geschlossene Eigentümerlücke, jedes deaktivierte Duplikat macht Copilot-Antworten genauer für jeden Mitarbeitenden, der es nutzt.
Fragen, die Sie vor dem Aufbau stellen sollten
Bevor Sie einen Aufbau beauftragen, eine Plattform migrieren oder ein bestehendes Intranet umstrukturieren, sind das die Fragen, die wir mit jedem Kunden durchgehen:
Governance & Strategie
- Haben Sie einen namentlich genannten Intranet-Plattform-Eigentümer, bevor die erste Site erstellt wird?
- Haben Sie die Content-Richtlinie definiert — was ins Intranet gehört, was nach Teams und was in Dokumentenbibliotheken?
- Ist Ihre Hub-Architektur um Geschäftsdomänen herum aufgebaut oder um das aktuelle Organigramm?
- Haben Sie explizite Startkriterien oder nur ein Go-live-Datum?
Microsoft 365-Konfiguration
- Haben Sie die offene Site-Erstellung im SharePoint Admin Center eingeschränkt?
- Sind Vertraulichkeitsbezeichnungen und Standard-Freigabeeinstellungen konfiguriert, bevor Inhalte veröffentlicht werden?
- Ist eine Site-Lebenszyklusrichtlinie vorhanden — nicht für später geplant, sondern jetzt konfiguriert?
Lebenszyklus & Adoption
- Hat jede veröffentlichte Seite einen namentlich genannten Eigentümer und ein Überprüfungsdatum?
- Ist das Intranet als laufendes Produkt budgetiert oder als einmaliges Projekt?
- Können Mitarbeitende über Teams darauf zugreifen, ohne eine separate URL aufzurufen?
KI-Bereitschaft
- Haben die zehn am häufigsten abgefragten Intranet-Themen jeweils eine einzige, aktuelle, maßgebliche Seite?
- Sind Ihre Seiten für maschinelles Schlussfolgern strukturiert, nicht nur für die visuelle Wahrnehmung?
- Ist Ihre Intranet-Governance mit Ihrer Copilot-Bereitschaftsarbeit verbunden — oder läuft sie als separate Initiative?
Wenn die meisten dieser Fragen unbequem zu beantworten sind, ist das Intranet noch nicht bereit zum Aufbau — oder nicht bereit zu skalieren. Dieses Unbehagen ist nützlich. Es zeigt Ihnen genau, wo Sie anfangen müssen.
Ein verwaltetes Intranet ist ein strategisches Asset. Ein nicht verwaltetes ist eine Belastung.
SharePoint gibt Ihnen eine leistungsstarke, tief integrierte, KI-taugliche Intranet-Plattform ohne zusätzliche Lizenzkosten. Es verbindet sich mit jedem Tool, das Ihre Mitarbeitenden bereits nutzen. Es speist die KI-Funktionen, in die Ihre Organisation investiert. Es skaliert mit Ihnen, anstatt alle fünf Jahre einen Plattformwechsel zu erfordern.
Aber es löst dieses Versprechen nur dann ein, wenn das dahinterliegende Governance-Modell bewusst entworfen wurde. Ein nicht verwaltetes SharePoint-Intranet ist kein neutrales Ergebnis. Es ist eine aktiv anwachsende Belastung: veraltete Inhalte, die Mitarbeitende in die Irre führen, verwaiste Sites, die Ihren Governance-Perimeter aufblähen, und KI-Antworten, die nur so zuverlässig sind wie die Seiten, aus denen sie stammen.
Die Organisationen, die ihr Intranet richtig aufbauen — Governance zuerst, Struktur an der Denkweise der Mitarbeitenden ausgerichtet, Lebenszyklus-Disziplin von Tag eins eingebaut — stellen fest, dass das Intranet zu einem sich verstärkenden Asset wird. Es verbessert die Adoption jeder anderen Microsoft 365-Investition. Es reduziert die IT-Kosten für die Verwaltung von Informationsanfragen. Und es wird das Wissensfundament, das Copilot wirklich nützlich macht.
Unsicher, wo Sie anfangen sollen — oder ob Ihre bestehende SharePoint-Umgebung ein Fundament ist, auf dem es sich lohnt aufzubauen?
Unser Team arbeitet mit Organisationen in jeder Phase der Intranet-Reise zusammen — vom Aufbau auf der grünen Wiese bis hin zu ungepflegten SharePoint-Umgebungen, die eine Governance-Sanierung benötigen, bevor sie skalieren können. Wir bewerten Ihre aktuelle Umgebung, entwerfen das Governance-Modell, das zu Ihrer Organisation passt, und erstellen eine Roadmap, die SharePoint zu dem strategischen Asset macht, für das Sie bereits lizenziert sind.
blog
Neues von Impactory
Informieren Sie sich über das Neueste aus unserem Unternehmen und bleiben Sie auf dem neuesten Stand mit allem Wissenswerten über unsere intelligenten Lösungen und Dienstleistungen aus der vielfältigen Microsoft-Office-Welt.
IMPACTORY
Ihr zuverlässiger und performancestarker Partner
Bei uns erhalten Sie ein breites Service- und Beratungsangebot rund um Planung, Einführung und Umsetzung von SharePoint, Microsoft 365 oder Hybrid-Anwendungen. Profitieren Sie dabei von unserer langjährigen Branchenerfahrung













