So bauen Sie ein SharePoint-Intranet auf — das wirklich funktioniert

Ein strategischer Leitfaden für CIOs, IT-Leiter, HR und Internal Comms zum Aufbau eines verwalteten, KI-tauglichen Intranets auf Microsoft 365

SharePoint Intranet aufbauen

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

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.

→ Wenn Sie sich hier wiederfinden: springen Sie zum Abschnitt Der Lebenszyklus von Tools weiter unten in diesem Artikel. Wir haben dort einen schrittweisen Prozess aufgezeigt, wie Sie einen Content-Lebenszyklus einrichten, der genau das verhindert — oder Ihnen hilft, sich davon zu erholen, wenn es bereits passiert ist.

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.

→ Wenn Sie sich hier wiederfinden: Schritt 1 des Governance-Abschnitts weiter unten beschreibt genau, wie wir die Definition von Verantwortlichkeiten angehen. Es ist das Erste, was wir tun, bevor eine einzige Site erstellt wird.

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.

→ Wenn Sie sich hier wiederfinden: der Abschnitt zur Benutzerfreundlichkeit beschreibt, wie wir Navigationsdesign und Adoption angehen. Kurz gesagt: Testen Sie Ihre Navigation mit Mitarbeitenden, bevor Sie bauen — nicht danach.

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

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

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.

Für IT-Administratoren: Auditieren Sie Ihre Teams-Umgebung auf verwaiste Teams — Teams, deren ursprüngliche Eigentümer das Unternehmen verlassen haben oder bei denen keine Aktivität mehr stattfindet. Jedes dieser Teams hat eine SharePoint-Site dahinter. Diese Sites sind Teil Ihres Governance-Perimeters, unabhängig davon, ob sie in Ihrer Intranet-Navigation erscheinen. Der SharePoint Admin Agent kann diese automatisch identifizieren, wenn Sie eine Copilot-Lizenz haben.

Governance zuerst: Das strategische Konzept vor dem Aufbau

Governance First

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.

1
Verantwortlichkeiten definieren — wer das Intranet als Ganzes besitzt und wer jeden Bereich

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.

Wie wir es gemacht haben: Ein Fertigungsunternehmen mit 3.000 Mitarbeitenden bat uns, ein Intranet zu sanieren, bei dem die Inhaltsverantwortlichkeit vollständig zusammengebrochen war. Bevor wir eine einzige Seite anfassten, führten wir die Verantwortlichkeits-Mapping-Session durch. Die Leiterin der Unternehmenskommunikation wurde zur gesamten Intranet-Eigentümerin. HR übernahm den Hub „People & Culture“. IT übernahm den Hub „Technology & Tools“. Finance übernahm den Hub „Finance & Compliance“.Jeder Hub-Eigentümer erhielt einen einseitigen Brief, der seine Überprüfungsverantwortlichkeiten definierte. Als das sanierte Intranet sechs Wochen später startete, hatte jeder Bereich einen verantwortlichen Menschen dahinter. Das Intranet hat seitdem kein Sanierungsprojekt mehr benötigt.
2
Die Content-Richtlinie definieren — was ins Intranet gehört, was nach Teams und was in Dokumentenbibliotheken

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.

Wie wir es gemacht haben: Ein Finanzdienstleistungsunternehmen wandte sich an uns, nachdem seine Intranet-Suche immer wieder Duplikate zurückgab — dieselbe Richtlinie an drei verschiedenen Orten, keiner davon klar als maßgebliche Version gekennzeichnet. Wir führten den Content-Richtlinien-Workshop durch und erstellten eine einseitige Matrix.Richtliniendokumente kamen als Seiten ins Intranet, mit einer PDF-Kopie in der Compliance-Dokumentenbibliothek. Arbeitsentwürfe gingen nach Teams. Abgeschlossene Kundendokumente kamen in eine verwaltete Bibliothek mit angewendeten Aufbewahrungsbezeichnungen. Innerhalb eines Monats gingen Duplikate um 70% zurück, und Mitarbeitende fragten nicht mehr, welche Version aktuell ist.
3
Namenskonventionen und Site-Struktur festlegen, bevor die erste Site erstellt wird

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.

Wie wir es gemacht haben: Ein globales Professional-Services-Unternehmen wandte sich an uns mit einer SharePoint-Umgebung, in der jedes Team sein eigenes Benennungsmuster erfunden hatte. Die Suche nach irgendetwas war unzuverlässig, weil dieselbe Art von Inhalten ein Dutzend verschiedene URL-Strukturen hatte.Wir verbrachten zwei Stunden vor dem Intranet-Aufbau damit, einen Namensstandard zu definieren: Alle Hub-Sites verwenden [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.
4
Die Hub-Architektur um Geschäftsdomänen herum gestalten, nicht um das Organigramm

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.

5
Definieren, was „fertig“ bedeutet — Startkriterien, nicht nur ein Go-live-Datum

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.

Wie wir es gemacht haben: Ein Technologieunternehmen, mit dem wir zusammenarbeiteten, definierte eine zwölfpunktige Startcheckliste, bevor der Aufbau begann. Punkt neun lautete: „Alle Seiten in der Top-Navigation wurden vom zuständigen Bereichseigentümer innerhalb der letzten dreißig Tage überprüft.“Dieses einzelne Kriterium verzögerte den Start um drei Wochen. Es verhinderte auch ein Intranet, bei dem die IT-Helpdesk-Seite auf ein Ticketsystem verlinkt, das im Quartal zuvor abgeschaltet worden war. Die dreiwöchige Verzögerung war unangenehm. Die Alternative wäre schlimmer gewesen.

Governance in Microsoft 365: So richten Sie es ein

Governance in Microsoft 365
Mit dem definierten strategischen Governance-Modell übersetzen diese sechs Schritte Ihre Entscheidungen in die tatsächliche Microsoft 365-Konfiguration. Das sind IT-Schritte — aber sie sollten auf Basis der oben getroffenen Entscheidungen ausgeführt werden, nicht davor.
1
Hub-Sites konfigurieren und Sites mit Hubs verknüpfen

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.

Wie wir es gemacht haben: Ein Logistikunternehmen, mit dem wir zusammenarbeiteten, erstellte fünf Hub-Sites: Company (Root), People, Operations, Finance und Technology. Die HR-Richtlinien-Site, die Benefits-Site und die Lern- und Entwicklungs-Site wurden alle mit dem People-Hub verknüpft.Vor dieser Struktur mussten Mitarbeitende wissen, welche Site die Elternzeitrichtlinie enthält. Danach lieferte eine Suche von einer beliebigen People-Hub-Site Ergebnisse aus allen drei — und die häufigsten HR-Anfragen verschwanden innerhalb eines Monats aus der IT-Helpdesk-Warteschlange.
2
Site-Erstellungsrichtlinien festlegen — wer Sites erstellen kann und unter welchen Bedingungen

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.

Wie wir es gemacht haben: Ein Professional-Services-Unternehmen, das wir auditiert haben, hatte 340 aktive Sites, von denen 180 seit zwölf Monaten keine Aktivität mehr verzeichnet hatten. Die offene Site-Erstellung war jahrelang aktiviert gewesen, und niemand hatte verfolgt, was erstellt wurde.Wir implementierten ein dreifeldiges Site-Erstellungs-Anfrageformular. Die Site-Erstellung sank im ersten Quartal um 60%. Jede neue Site hatte von Anfang an einen namentlich genannten Eigentümer. Zwölf Monate später war die Anzahl der aktiven Sites um 40% gesunken, und der Suchrelevanz-Score hatte sich messbar verbessert.
3
Vertraulichkeitsbezeichnungen und Standard-Freigabeeinstellungen konfigurieren

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.

Wie wir es gemacht haben: Eine Gesundheitsorganisation, mit der wir zusammenarbeiteten, hatte sensible HR-Executive-Inhalte auf einer Intranet-Site mit Standardberechtigungen — zugänglich für ein viel breiteres Publikum als beabsichtigt. Niemand hatte das absichtlich so eingerichtet; die Berechtigungen waren einfach nie bewusst eingeschränkt worden.Wir wendeten eine „Vertraulich — Intern“-Vertraulichkeitsbezeichnung auf ihren HR-Executive-Hub an. Wenn Inhalte in diesem Hub entsprechend bezeichnet werden, verhindert Purview automatisch externe Freigaben, wendet eine Aufbewahrungsrichtlinie an und protokolliert den Zugriff für Prüfzwecke — ohne manuelle Berechtigungsverwaltung auf einzelnen Seiten.
4
Site-Lebenszyklusrichtlinien aktivieren — Erkennung inaktiver Sites, Ablauf der Eigentümerschaft und Archivierung

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.

Wie wir es gemacht haben: Ein Technologieunternehmen implementierte im Rahmen einer Governance-Auffrischung, die wir mit ihnen durchführten, eine 90-Tage-Inaktivitätsrichtlinie für alle Intranet-Sites. Im ersten Quartal wurden 47 Sites als inaktiv markiert.31 wurden von ihren Eigentümern als redundant bestätigt und archiviert. Die verbleibenden 16 wurden aktualisiert und blieben aktiv. Die Suchrelevanz verbesserte sich innerhalb von zwei Monaten messbar. Das IT-Team beschrieb es als „das erste Mal, dass die Suche wirklich nützlich war.“
5
Den SharePoint Admin Agent für laufendes Governance-Monitoring einrichten

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.

Wie wir es gemacht haben: Ein Enterprise-Kunde, der den SharePoint Admin Agent nutzt, erhält monatlich einen Governance-Digest. Eines Monats meldete er, dass eine Finance-Hub-Site ihre Standard-Freigabeeinstellungen geändert hatte, um externen Zugriff zu erlauben — eine Änderung, die nicht Teil einer genehmigten Anfrage war.Die IT untersuchte den Fall, fand einen Einstellungsfehler, der während eines SharePoint-Updates gemacht worden war, und korrigierte ihn innerhalb von 24 Stunden. Ohne den Admin Agent wäre das nur bei einem jährlichen Audit aufgefallen — wenn überhaupt.
6
Purview für Compliance und Datenklassifizierung anbinden

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.

Wie wir es gemacht haben: Ein Rechtdienstleistungsunternehmen, mit dem wir zusammenarbeiten, konfigurierte automatische Aufbewahrungsbezeichnungen auf allen Seiten im Legal-Hub. Als ein Juniorberater versehentlich eine Richtlinienseite löschte, verhinderte der Aufbewahrungsschutz von Purview die permanente Löschung. Die IT stellte die Seite innerhalb von fünfzehn Minuten aus dem Compliance-Center wieder her.Ohne Purview wäre die Seite weg gewesen. Das Unternehmen schätzte, dass die manuelle Wiederherstellung zwei Tage gedauert und die Genehmigung von drei Partnern erfordert hätte.

Der Lebenszyklus von Tools: So verhindern Sie, dass Ihr Intranet zum Problem von morgen wird

Lebenszyklus von Tools

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.

1
Das Intranet-Lebenszyklusmodell übernehmen — Plan → Build → Launch → Govern → Evolve

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.

Wie wir es gemacht haben: Ein globaler Einzelhändler, mit dem wir zusammenarbeiten, budgetiert zwei Tage pro Quartal für eine Intranet-Governance-Überprüfung. Über achtzehn Monate identifizierten und lösten diese vierteljährlichen Überprüfungen 140 Content-Probleme, die sich sonst zu einem Legacy-Schulden-Problem angehäuft hätten, das einen vollständigen Wiederaufbau erfordert hätte.Die zweitägige Quartalsinvestition ersetzte das, was ein sechsmonatiges Wiederaufbauprojekt gewesen wäre.
2
Jedem Inhaltseigentümer und Überprüfungsrhythmus bei der Erstellung einer Seite zuweisen

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.

Wie wir es gemacht haben: Ein Versicherungsunternehmen, mit dem wir zusammenarbeiteten, implementierte obligatorische „Seiteneigentümer“- und „Überprüfung fällig“-Metadatenfelder auf allen Intranetseiten. Drei Monate nach dem Launch zeigte ein automatisierter Bericht 23 Seiten mit überfälligen Überprüfungen.Das Communications-Team kontaktierte jeden Eigentümer. Achtzehn Seiten wurden aktualisiert; fünf wurden abgeschaltet. Der Prozess dauerte zwei Stunden. Ohne die Metadatenfelder wären diese Seiten unbegrenzt live geblieben und als maßgebliche Antworten von Copilot angezeigt worden.
3
Einen Content-Audit-Kalender aufbauen — vierteljährlich für stark frequentierte Seiten, jährlich für den Rest

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.

Wie wir es gemacht haben: Ein Medienunternehmen, mit dem wir zusammenarbeiteten, identifizierte mithilfe von SharePoint-Analysen seine zwanzig meistbesuchten Seiten. Die IT-Helpdesk-Seite erhielt 4.200 Besuche pro Monat — die meisten aller Seiten im Intranet.Ein vierteljährlicher Audit ergab, dass sie seit elf Monaten nicht überprüft worden war und zwei defekte Links sowie einen veralteten Ticket-Einreichungsprozess enthielt. Die Korrektur dauerte 30 Minuten. Die Kosten der Nicht-Behebung — 4.200 frustrierte Mitarbeitende pro Monat — waren schwerer zu berechnen.
4
Den Deaktivierungspfad definieren — wann Seiten archiviert werden, wer genehmigt und was sie ersetzt

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.

Wie wir es gemacht haben: Ein Pharmaunternehmen, mit dem wir zusammenarbeiten, deaktivierte seinen „COVID-19-Reaktions“-Bereich zwei Jahre später. Der Deaktivierungsprozess umfasste die Archivierung aller Seiten auf einer eigenen Archiv-Site, die Aktualisierung von Navigationslinks und die Veröffentlichung einer kurzen „Dieser Inhalt wurde archiviert“-Seite unter der ursprünglichen URL mit einem Link zum Archiv.Drei Mitarbeitende kontaktierten die IT wegen der Änderung. Ohne einen Deaktivierungsprozess wäre dieser Bereich als Geisterbereich des Intranets aktiv geblieben — und hätte weiterhin in Copilot-Antworten als scheinbar aktueller Inhalt aufgetaucht.
5
Integrierte Tools auf demselben Lebenszyklus wie Inhalte überprüfen — keine Integration ohne Eigentümer

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.

Wie wir es gemacht haben: Eine Einzelhandelsorganisation hatte eine Power App für Schichtaustausch-Anfragen direkt in den HR-Bereich des Intranets eingebettet. Als HR zu einer neuen Personalmanagement-Plattform wechselte, wurde die Power App abgeschaltet — aber die Intranet-Integration wurde nicht aktualisiert.Drei Wochen lang klickten Mitarbeitende auf einen defekten Link auf der meistbesuchten HR-Seite. Niemand bemerkte es, bis ein Mitarbeitender es seinem Manager gemeldet hatte. Ein Integrations-Eigentümer-Register, das mit dem Tool-Lebenszyklusprozess verbunden ist, hätte das vor dem Go-live der neuen Plattform aufgedeckt.
6
Das Intranet als Produkt behandeln, nicht als Projekt

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.

Wie wir es gemacht haben: Ein Professional-Services-Unternehmen, mit dem wir zusammenarbeiteten, launchte sein Intranet mit einem dedizierten Projektteam und wechselte dann beim Go-live zu einer 0,3-FTE-Intranet-Manager-Rolle innerhalb von Communications.Zwei Jahre später war ein Konkurrenzunternehmen, das den „nur Projekt“-Ansatz verfolgt hatte, mitten in einem kostspieligen Wiederaufbau. Dieses Unternehmen hatte eine um 40% höhere Adoptionsrate und einen Content-Freshness-Score, den sein IT-Team der Führungsebene jeden Quartal berichtet.

Benutzerfreundlichkeit: Für Adoption bauen, nicht nur für Struktur

Benutzerfreundlichkeit

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 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

KI-Aspekt - SharePoint

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?

KOSTENLOSEN AUDIT ANFORDERN

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.

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

Leistungen

Wir sorgen dafür, das Microsoft 365 und SharePoint in Ihrem Unternehmen optimal läuft

Lösungen

Mit innovativen Lösungen zu mehr Produktivität. Unser Ziel sind effektive Lösungen, die einfach und schnell in Ihrem Unternehmen umzusetzen sind