Intranet-Content-Governance: Ein Lebenszyklusmodell gegen veraltete Inhalte

Veraltete Intranet-Seiten kosten Mitarbeitende Zeit. Eine überholte Reisekostenrichtlinie schickt jemanden durch den falschen Genehmigungsprozess. Doppelte Onboarding-Anleitungen lassen neue Kolleginnen und Kollegen rätseln, welcher Version sie trauen sollen. Intranet-Content-Governance verhindert solche Probleme, indem Verantwortlichkeiten, Review-Fristen und Entscheidungen über das Außerbetriebnehmen von Inhalten fester Bestandteil des täglichen Publizierens werden.
Ziel ist nicht, dass jede Änderung auf ein zentrales Kommunikationsteam warten muss. Es geht darum, Fachbereichen klare Verantwortung zu geben, Routine-Erinnerungen zu automatisieren und dort einzugreifen, wo Inhalte ein Risiko darstellen.
Bauen Sie diese Kontrollen vor dem Start auf und nutzen Sie sie während des gesamten Lebens Ihres Intranets. Hier ist ein praxisnahes Modell, mit dem Seiten nützlich bleiben, ohne einen Engpass beim Publizieren zu erzeugen.
In diesem Artikel:
- Wer verantwortet nach dem Start die einzelnen Bereiche und ihre Inhalte?
- Welchen Lebenszyklus sollte jede Intranet-Seite durchlaufen?
- Wie oft sollten Inhalte geprüft werden, und was passiert, wenn sie ablaufen?
- Wann sollten Inhalte zusammengeführt, archiviert oder außer Betrieb genommen werden?
- Wie kann Drupal Warnungen zu veralteten Inhalten automatisieren?
- Wie setzen Sie Standards durch, ohne das Publizieren zu bremsen?
- Woran erkennen Sie, dass das Governance-Modell funktioniert?
Wer verantwortet nach dem Start die einzelnen Bereiche und ihre Inhalte?
Jeder Bereich braucht eine rechenschaftspflichtige Verantwortliche oder einen Verantwortlichen aus dem Fachbereich, und jede Seite braucht eine namentlich benannte verantwortliche Person samt Vertretung. Ein Abteilungspostfach kann Benachrichtigungen empfangen, ersetzt aber keine persönliche Verantwortung.
So könnte beispielsweise HR den Bereich Sozialleistungen verantworten, während eine namentlich benannte Fachkraft für Benefits dessen Seiten überprüft. Eine Redakteurin kann diese Seiten pflegen, ohne dafür verantwortlich zu sein, ob die Informationen zu den Leistungen inhaltlich korrekt sind.
Trennen Sie die Zuständigkeiten:
| Rolle | Zuständigkeit |
|---|---|
| Bereichsverantwortliche/r | Hält den Bereich nützlich, schließt Lücken bei Zuständigkeiten und plant Zeit für die Pflege ein |
| Seitenverantwortliche/r | Prüft Fakten und entscheidet, ob eine Seite beibehalten, überarbeitet, zusammengeführt, archiviert oder außer Betrieb genommen wird |
| Vertretung | Übernimmt Reviews, wenn die/der Seitenverantwortliche nicht verfügbar ist |
| Redakteur/in | Aktualisiert Texte, Links, Anhänge und Seitenstruktur |
| Fachliche Freigabe | Prüft wesentliche Änderungen an sensiblen Inhalten |
| Digital-Workplace-Manager/in | Überwacht überfällige Aufgaben, koordiniert Eskalationen und pflegt die Governance-Regeln |
In einer kleinen Organisation kann eine Person mehrere Rollen innehaben. Entscheidend ist die Unterscheidung zwischen dem Bearbeiten einer Seite und der Verantwortung für ihre Richtigkeit.
Legen Sie ein Verantwortlichkeitsregister an, das Bereich, Seite oder Inhaltsgruppe, namentlich benannte verantwortliche Person, Vertretung, gegebenenfalls Freigebende, Review-Intervall und Eskalationskontakt enthält. Verknüpfen Sie es nach Möglichkeit direkt mit den Inhalten, statt eine separate Tabelle zu führen, die schnell veraltet.
Machen Sie die Neuzuweisung zum Teil von Austritten und Rollenwechseln. Verlässt eine verantwortliche Person das Unternehmen, leiten Sie ihre Seiten zur Neuzuweisung an die Bereichsverantwortlichen weiter. Übertragen Sie nicht stillschweigend alles an eine ohnehin überlastete Redaktion.
Welchen Lebenszyklus sollte jede Intranet-Seite durchlaufen?
Ein gemeinsamer Lebenszyklus gibt Publizierenden einen wiederholbaren Prozess:
Entwurf → Review → veröffentlicht → geplantes Review → beibehalten, überarbeiten, zusammenführen, archivieren oder außer Betrieb nehmen.
Dies sind fachliche Phasen, nicht zwingend separate Veröffentlichungsstatus in der Plattform. Insbesondere sollte ein geplantes Review eine ansonsten gültige Seite nicht automatisch unzugänglich machen.
Definieren Sie Eingangs- und Ausgangskriterien für jede Phase:
| Phase | Eingangsbedingung | Ausgangsanforderung |
|---|---|---|
| Entwurf | Ein Bedarf der Mitarbeitenden und eine verantwortliche Person sind identifiziert | Erforderliche Metadaten und brauchbare Inhalte liegen vor |
| Review | Der Entwurf ist bereit für fachliche und redaktionelle Prüfung | Die verantwortliche Person bestätigt die Richtigkeit, erforderliche Freigaben liegen vor |
| Veröffentlicht | Eine berechtigte Person gibt die Veröffentlichung frei | Die Seite bleibt verfügbar, bis ein Review oder eine Änderung Handlungsbedarf auslöst |
| Geplantes Review | Ein Review-Datum ist erreicht oder ein geschäftliches Ereignis löst eine Prüfung aus | Die prüfende Person dokumentiert eine Entscheidung und den nächsten Schritt |
| Verfügung | Die prüfende Person entscheidet sich für Beibehalten, Überarbeiten, Konsolidieren, Archivieren oder Außerbetriebnahme | Die Maßnahme ist umgesetzt und dokumentiert |
Verlangen Sie für jede Seite:
- Verantwortliche Person und Vertretung.
- Bereich und Inhaltstyp.
- Risikostufe.
- Datum der letzten Verifizierung.
- Datum des nächsten Reviews.
- Ablaufdatum, sofern zutreffend.
- Einen Verifizierungsnachweis, der festhält, wer die Seite geprüft hat und worauf die Entscheidung beruht.
Als Nachweis kann ein aktuelles Richtliniendokument dienen, die Bestätigung einer Prozessverantwortlichen oder ein erfolgreich getestetes Verfahren. „Geprüft“ sollte mehr bedeuten, als die Seite zu öffnen und auf einen Button zu klicken.
Halten Sie den Review-Status getrennt vom Veröffentlichungsstatus. Eine Seite, die auf eine Routineprüfung wartet, kann veröffentlicht bleiben. Eine Seite, von der bekannt ist, dass sie falsche Sicherheitsanweisungen enthält, muss sofort korrigiert oder zurückgezogen werden, mit einem Verweis auf gültige Informationen.
Trennen Sie außerdem „zuletzt bearbeitet“ von „zuletzt verifiziert“. Die Korrektur eines Tippfehlers beweist nicht, dass die Anweisungen aktuell sind.
Wie oft sollten Inhalte geprüft werden, und was passiert, wenn sie ablaufen?
Legen Sie Review-Intervalle danach fest, welche Folgen ein Fehler hätte und wie oft sich das Thema ändert. Jede Seite monatlich zu prüfen, erzeugt unnötige Arbeit. Jede Seite nur jährlich zu prüfen, lässt Anweisungen, die sich schnell ändern, ungeschützt.
Nutzen Sie die folgenden Werte als beispielhafte Ausgangspunkte, vorbehaltlich geschäftlicher und rechtlicher Anforderungen:
| Inhaltstyp | Ausgangsrhythmus für Reviews | Zusätzlicher Auslöser |
|---|---|---|
| Häufig wechselnde Verfahren | Vierteljährlich | Prozess- oder Systemänderung |
| Sensible Richtlinieninhalte | Mit der verantwortlichen Funktion abgestimmtes Intervall | Richtlinien-, Rechts- oder regulatorische Änderung |
| Stabile Referenzseiten | Jährlich | Organisatorische Änderung |
| Kampagnen und befristete Hinweise | Enddatum bei Veröffentlichung festgelegt | Absage oder Verlängerung |
| Kontakte und Teaminformationen | Regelmäßige Prüfungen plus ereignisbezogene Aktualisierungen | Rollenwechsel oder Austritt |
Datumsbasierte Reviews sind nur ein Sicherheitsnetz. Systemablösungen, Umstrukturierungen, Richtlinienänderungen und Übergaben von Verantwortlichkeiten sollten Prüfungen vor der nächsten planmäßigen Frist auslösen. Ermitteln Sie betroffene Seiten über Bereichszuordnungen, Tags und Verweise auf Quelldokumente.
Eine Review-Aufgabe sollte die verantwortliche Person auffordern:
- Fakten anhand der aktuellen Quelle zu prüfen.
- Anweisungen und Links zu testen, wo relevant.
- Kontakte, Anhänge und Zielgruppenbeschränkungen zu kontrollieren.
- Nach Dubletten oder widersprüchlichen Informationen zu suchen.
- Entscheidung, Nachweis und nächstes Review-Datum zu dokumentieren.
Überfälliges Review und hartes Ablaufdatum unterscheiden
Ein versäumtes Review bedeutet, dass die Verifizierung überfällig ist. Es bedeutet nicht automatisch, dass die Seite falsch ist.
Ein Ablaufdatum bedeutet, dass ein festgelegter Nutzungszeitraum beendet ist. Ein Hinweis zu einer Anmeldung sollte aus den aktuellen Übersichten verschwinden, sobald die Anmeldung geschlossen ist, auch wenn die verantwortliche Person nicht reagiert hat.
Für ein Pilotprojekt könnten Sie 14 Tage vor dem Review eine Erinnerung senden, die verantwortliche Person am Fälligkeitstag benachrichtigen und nach sieben Tagen Verzug an Vertretung und Bereichsverantwortliche eskalieren. Verkürzen Sie diese Fristen für Inhalte mit hohem Risiko. Bekannt fehlerhafte Inhalte sollten sofortiges Handeln auslösen und nicht auf die Erinnerungskette warten.
Definieren Sie das Verhalten bei Ablauf je Inhaltstyp. Manche Einträge sollten aus aktuellen Übersichten verschwinden, andere sollten depubliziert oder archiviert werden. Wesentliche Informationen sollten nicht ohne gültige Ersatzanweisungen oder einen ausdrücklichen Hinweis auf die Zurückziehung verschwinden.
Wann sollten Inhalte zusammengeführt, archiviert oder außer Betrieb genommen werden?
Wer alles behält, überlässt es den Mitarbeitenden, aktuelle Informationen von historischem Material zu trennen. Nutzen Sie stattdessen einen einheitlichen Entscheidungsrahmen.
| Entscheidung | Wählen Sie sie, wenn | Erforderliche Maßnahme |
|---|---|---|
| Beibehalten | Der Inhalt ist weiterhin korrekt, nützlich und eindeutig | Verifizierung und nächstes Review-Datum dokumentieren |
| Überarbeiten | Der Bedarf der Mitarbeitenden besteht weiter, aber Details haben sich geändert | Seite korrigieren und erforderliche Freigabe einholen |
| Zusammenführen | Mehrere Seiten erfüllen denselben Bedarf | Eine maßgebliche Seite bestimmen und nützliche Inhalte konsolidieren |
| Archivieren | Der Inhalt ist nicht mehr aktuell, hat aber einen Referenz- oder Aufbewahrungszweck | Archivverhalten anwenden und Aufbewahrungsanforderungen dokumentieren |
| Außer Betrieb nehmen | Der Inhalt hat keinen Zweck mehr und kann entfernt werden | Abhängigkeiten und Pflichten vor dem Entfernen prüfen |
Archivieren muss verändern, wie Mitarbeitende auf den Inhalt stoßen. Nur ein Label „Archiviert“ hinzuzufügen, während die Seite in der Suche weiterhin prominent erscheint, reicht nicht aus.
Definieren Sie das Archivverhalten ausdrücklich:
- Entfernen Sie archivierte Seiten aus Übersichten mit aktuellen Inhalten.
- Schließen Sie sie, wo sinnvoll, aus den Standard-Suchergebnissen aus.
- Bieten Sie eine separate Archivsuche oder einen Filter an, falls Mitarbeitende auf historische Inhalte zugreifen müssen.
- Zeigen Sie einen sichtbaren Hinweis an, dass der Inhalt keine aktuelle Vorgabe ist.
- Verlinken Sie auf einen aktuellen Ersatz, sofern vorhanden.
- Beschränken Sie den Zugriff, wo Vertraulichkeits- oder Aufbewahrungsregeln dies erfordern.
Suchfilterung ist keine Zugriffskontrolle. Eingeschränkte Archive benötigen Berechtigungsprüfungen für Seiten und zugehörige Dateien.
Prüfen Sie vor der Außerbetriebnahme eingehende Links, Navigationseinträge, Anhänge, Ersatzseiten, Aufbewahrungspflichten und Legal Holds. Eine Seite aus der Veröffentlichung zu nehmen, ist etwas anderes, als ihre Aufzeichnungen zu löschen. Ein Legal Hold kann eine Löschung verhindern, selbst wenn Mitarbeitende das Material nicht mehr nutzen sollen.
Leiten Sie nur auf einen wirklich gleichwertigen Ersatz weiter. Andernfalls sollten Sie einen klaren Hinweis zur Außerbetriebnahme oder eine passende Antwort für nicht verfügbare Seiten bereitstellen. Wer jede alte URL auf die Startseite umleitet, lässt Mitarbeitende im Unklaren.
Wie kann Drupal Warnungen zu veralteten Inhalten automatisieren?
Automatisierung erspart den Verantwortlichen das manuelle Nachhalten von Fristen und verschafft der Digital-Workplace-Managerin oder dem Digital-Workplace-Manager einen sichtbaren Rückstau.
Für ein Drupal-basiertes Intranet wie Open Intranet ist dies als Implementierungsmuster zu verstehen, das konfiguriert und getestet werden muss, nicht als Versprechen, dass jede Funktion standardmäßig verfügbar ist.
Governance-Daten als strukturierte Felder speichern
Nutzen Sie Benutzerreferenzen für Verantwortliche und Vertretungen, Datumsfelder für Review- und Ablauffristen sowie kontrollierte Werte für Risiko und Bereich.
Speichern Sie Verifizierungsnachweise mit der Identität der prüfenden Person, Datum, Entscheidung und unterstützenden Notizen. So können Teams ein tatsächliches Review von einer davon unabhängigen Inhaltsänderung unterscheiden.
Redaktionelle Status und Übergänge konfigurieren
Die Drupal-Core-Module Workflows und Content Moderation können redaktionelle Status und Übergänge definieren, etwa Entwurf, Review erforderlich und veröffentlicht. Berechtigungen für Übergänge steuern, welche Rollen Inhalte durch diese Status bewegen dürfen.
Für sich genommen bilden sie jedoch nicht den gesamten datumsgesteuerten Erinnerungs- und Ablaufprozess ab. Geplante Benachrichtigungen, Eskalationslogik und Ablaufaktionen erfordern zusätzliche Konfiguration, geeignete Contributed-Module oder individuellen Code.
Prüfen Sie bei der Auswahl von Modulen die Kompatibilität mit der eingesetzten Drupal-Version, den Wartungsstatus und die Abdeckung durch das Security-Team.
Arbeitslisten und geplante Prüfungen aufbauen
Nutzen Sie auf Views basierende Listen, um Folgendes anzuzeigen:
- Reviews, deren Frist näher rückt.
- Überfällige Seiten, gruppiert nach Risiko und Bereich.
- Seiten ohne aktive verantwortliche Person.
- Abgelaufene Inhalte, die auf eine Maßnahme warten.
- Archivierte Inhalte, bei denen eine Aufbewahrungsentscheidung ansteht.
Ein geplanter Prozess kann fällige Einträge erkennen und Benachrichtigungen an Verantwortliche und Vertretungen in die Warteschlange stellen. Dokumentieren Sie, welche Benachrichtigungen bereits versendet wurden, damit wiederholte Durchläufe keine doppelten Erinnerungen erzeugen.
Machen Sie jede Warnung handlungsorientiert. Nennen Sie Seitentitel, Frist, Risikostufe, Review-Link und die erforderliche Entscheidung. Bündeln Sie Routine-Erinnerungen in einem Digest und leiten Sie dringende Fälle separat weiter.
Die Automatisierung selbst überwachen
Ein fehlgeschlagener geplanter Durchlauf darf das Dashboard nicht fälschlich gesund aussehen lassen.
Protokollieren Sie abgeschlossene Durchläufe, prüfen Sie Fehler bei der Zustellung von Benachrichtigungen und benennen Sie jemanden, der verpasste Durchläufe untersucht. Testen Sie Abwesenheiten von Verantwortlichen, deaktivierte Konten, wiederholte Ausführungen und Ablaufaktionen.
Überprüfen Sie auch das Suchverhalten. Änderungen an der Veröffentlichung können Index-Aktualisierungen erfordern, und Benachrichtigungen dürfen Details eingeschränkter Seiten nicht an unberechtigte Empfänger preisgeben.
Wie setzen Sie Standards durch, ohne das Publizieren zu bremsen?
Setzen Sie bei der Veröffentlichung auf wenige verbindliche Kontrollen und passen Sie die Freigabeanforderungen dann an das Risiko an.
Verlangen Sie Verantwortlichkeit, Risikoeinstufung und Review-Daten vor der Veröffentlichung. Standardwerte je Inhaltstyp können wiederholte Eingaben reduzieren. So kann ein befristeter Hinweis ein Enddatum erfordern, während eine Referenzseite ein vorgeschlagenes Review-Intervall erhält, das die verantwortliche Person bestätigt.
Standardwerte sollen Tipparbeit sparen, nicht Verantwortung ersetzen. Vermeiden Sie es, jede neue Seite dauerhaft derjenigen Person zuzuordnen, die sie erstellt hat.
Nutzen Sie zwei grundlegende Freigabewege:
- Routine-Aktualisierungen: Berechtigte Verantwortliche oder Redakteure können Links, Kontakte und Formulierungen im Rahmen ihrer Berechtigungen korrigieren.
- Wesentliche oder sensible Änderungen: Änderungen an Richtlinien, Sicherheitsanweisungen, Rechten der Mitarbeitenden oder regulierten Inhalten gehen an benannte Freigebende.
Definieren Sie Beispiele für jeden Weg, damit Publizierende keine vagen Regeln interpretieren müssen. Setzen Sie kritische Anforderungen über Berechtigungen und Validierung durch, nicht allein über Schulungen.
Geben Sie Publizierenden eine kurze Checkliste an die Hand:
- Ist die Information korrekt und durch eine aktuelle Quelle belegt?
- Sind verantwortliche Person und Vertretung korrekt?
- Ist das nächste Review-Datum angemessen?
- Dupliziert die Seite eine andere?
- Sind die erforderlichen Freigaben dokumentiert?
Schaffen Sie eine Ausnahme für dringende Veröffentlichungen in Situationen, in denen Warten Schaden verursachen oder wesentliche Arbeit blockieren würde. Verlangen Sie eine namentlich benannte autorisierende Person, eine dokumentierte Begründung und eine Frist für ein nachgelagertes Review. Bewahren Sie Versionshistorie und Freigabenachweise auf.
Eine Ausnahme sollte nachvollziehbar und befristet sein, kein informeller Weg am Prozess vorbei.
Woran erkennen Sie, dass das Governance-Modell funktioniert?
Messen Sie, ob die Governance-Arbeit tatsächlich stattfindet und ob Mitarbeitende auf weniger Probleme mit Inhalten stoßen. Seitenzahlen allein verraten Ihnen weder das eine noch das andere.
| Kennzahl | Definition |
|---|---|
| Abdeckung der Verantwortlichkeiten | Anteil der veröffentlichten Seiten im Geltungsbereich mit einer aktiven, namentlich benannten verantwortlichen Person und Vertretung |
| Quote fristgerechter Reviews | Bis zur Frist abgeschlossene Reviews, geteilt durch die im Berichtszeitraum fälligen Reviews |
| Überfälliger Rückstau nach Risiko | Veröffentlichte Seiten mit überschrittener Review-Frist, gruppiert nach Risiko und Dauer des Verzugs |
| Offene Ablaufaktionen | Abgelaufene Einträge, deren konfigurierte Entfernung, Depublikation oder Archivierung noch nicht abgeschlossen ist |
| Bestätigte Fehler | Gemeldete inhaltliche Fehler, die noch auf Korrektur warten, gruppiert nach Schweregrad und Alter |
Einigen Sie sich auf Geltungsbereich und Berichtszeitraum, bevor Sie Teams vergleichen. Bewahren Sie die ursprünglichen Review-Fristen auf, damit das Verschieben eines Datums nicht als fristgerechter Abschluss zählt.
Unterscheiden Sie zwischen nahenden Fristen, überfälliger Verifizierung und bestätigten Fehlern. Sie stehen für unterschiedliche Dringlichkeitsstufen. Weisen Sie dem Rückstau mit dem höchsten Risiko eine namentlich benannte Eskalationsverantwortliche oder einen Eskalationsverantwortlichen zu.
Führen Sie ein regelmäßiges operatives Review durch, um Maßnahmen zuzuweisen, überlastete Verantwortliche zu erkennen und den Zeitpunkt von Erinnerungen oder die Review-Intervalle anzupassen. Kombinieren Sie das Dashboard mit Feedback der Mitarbeitenden: Melden Mitarbeitende widersprüchliche Anweisungen? Verweisen Support-Teams immer wieder auf eine Seite, die die Suche nicht findet?
Verlängern Sie Review-Intervalle nicht nur, um den Rückstau zu verkleinern. Passen Sie sie an, wenn die Faktenlage eine geringere Prüfhäufigkeit rechtfertigt.
Bereitschaft vor dem Start prüfen
Bestätigen Sie vor der Veröffentlichung des neuen Intranets, dass:
- Das Verantwortlichkeitsregister vollständig ist, mit namentlich benannten Vertretungen und Eskalationskontakten.
- Lebenszyklusphasen, Freigabewege und Regeln zur Außerbetriebnahme abgestimmt sind.
- Review-Daten für migrierte und neu erstellte Inhalte gepflegt sind.
- Ablaufaktionen je Inhaltstyp definiert sind.
- Archivverhalten, Sichtbarkeit in der Suche und Zugriffsbeschränkungen getestet sind.
- Erinnerungen, Eskalationen und Warnungen bei fehlgeschlagenen Durchläufen die richtigen Personen erreichen.
- Verantwortliche wissen, wie sie ein Review dokumentieren und Verantwortung übertragen.
Ein Starttermin sollte keine Ausrede sein, um Seiten ohne verantwortliche Person zu migrieren. Klären Sie zuerst die Verantwortlichkeit oder halten Sie diese Inhalte zurück, bis jemand die Verantwortung übernimmt.
Bereit für den Start?
Beginnen Sie mit einem stark genutzten Bereich, etwa Onboarding oder IT-Support. Weisen Sie Verantwortliche und Vertretungen zu, stufen Sie das Risiko ein, pflegen Sie Review-Daten und testen Sie einen vollständigen Zyklus von der Erinnerung bis zur dokumentierten Entscheidung. Nutzen Sie die Erkenntnisse, bevor Sie das Modell auf das gesamte Intranet ausweiten.
Open Intranet ist ein Open-Source-Intranet auf Basis von Drupal, entwickelt von Droptica. Sprechen Sie mit dem Open Intranet Team darüber, wie Sie Ihr abgestimmtes Governance-Modell in Drupal-Felder, Workflows, Arbeitslisten und geplante Aktionen überführen, mit einer klaren Unterscheidung zwischen bereits vorhandenen Funktionen und der Konfiguration oder Entwicklung, die Ihr Prozess erfordert.


