Intranet-Projekt-Checkliste: vom Business Case bis zum Launch

Beim Start eines Intranets gibt es vieles im Blick zu behalten: Wer kümmert sich um die Richtlinienbibliothek, wie funktioniert der Zugang für Mitarbeitende, und wer leistet Support, sobald alle das System nutzen? Diese Intranet-Projekt-Checkliste hilft Ihrem Team, diese Fragen zu klären, bevor sie zu Überraschungen in letzter Minute werden.

Nutzen Sie sie, um eine Open-Intranet-Einführung zu planen, zu prüfen, wie das Produkt die Bedürfnisse der Mitarbeitenden erfüllt, und zu sehen, was bereit ist und was noch Aufmerksamkeit braucht. Beginnen Sie mit vorhandenen Funktionen und Konfiguration. Ergänzen Sie Integrationen oder Erweiterungen nur dort, wo eine vereinbarte Anforderung offen bleibt.

In diesem Artikel:

So nutzen Sie diese Checkliste
1. Geschäftsproblem und Projektauftrag bestätigen
2. Mitarbeitende und ihre Zugangsbedürfnisse verstehen
3. Verantwortlichkeiten und Entscheidungswege festlegen
4. Budget und Lieferumfang genehmigen
5. Open Intranet anhand der Anforderungen validieren
6. Hosting, Verträge und Betriebskontrolle bestätigen
7. Anforderungen an Identität, Zugriff und Datenschutz definieren
8. Inhalte prüfen und Publishing-Governance festlegen
9. Navigation, Suche und zentrale Nutzerpfade validieren
10. Funktionen für das erste Release konfigurieren
11. Erforderliche Systeme anbinden und testen
12. Umgebungen und Wiederherstellungsverfahren vorbereiten
13. Launch-Inhalte migrieren und freigeben
14. Abnahmetests und Mitarbeiter-Pilot abschließen
15. Mitarbeitende vorbereiten und Launch freigeben
16. Betreiben, verbessern und das alte Intranet abschalten
Die Checkliste in einen Umsetzungsplan verwandeln

So nutzen Sie diese Intranet-Projekt-Checkliste

Übertragen Sie die Prüfpunkte in Ihr Projekt-Tracking-Tool oder eine gemeinsame Tabelle. Jede der 16 Phasen enthält sechs Prüfpunkte, insgesamt also 96 Prüfpunkte.

Diese Spalten sind ein guter Ausgangspunkt:

Prüfpunkt	Verantwortlich	Fälligkeitsdatum	Status	Nachweisdokument oder Entscheidung
Zu erledigende Aufgabe	Verantwortliche Person	Vereinbartes Datum	Aktueller Status	Freigabe, Testergebnis oder Dokument

Verwenden Sie fünf Statuswerte: nicht begonnen, in Arbeit, blockiert, erledigt oder nicht zutreffend.

Bevor Sie einen Prüfpunkt als erledigt abhaken, stellen Sie sicher, dass die verantwortliche Person auf das vereinbarte Ergebnis verweisen kann. Wenn etwas nicht zutrifft, notieren Sie warum und wer das entschieden hat. Optionale Funktionen bleiben optional: Entscheiden Sie, welche Sie brauchen, und konfigurieren und testen Sie dann nur die ausgewählten.

Sie müssen nicht jede Phase abschließen, bevor Sie die nächste beginnen. Inhaltsprüfung, Hosting-Bewertung und Produktevaluation können parallel laufen, soweit ihre Abhängigkeiten das zulassen. Jede Phase endet mit einem kurzen Hinweis darauf, was bereitliegen sollte.

Lassen Sie Raum für eine finale Launch-Entscheidung. Selbst wenn die Planung im Zeitplan liegt, muss Ihr Team noch Blocker prüfen, vereinbaren, welche Risiken es akzeptieren kann, und festlegen, wer einen Rollback autorisieren darf.

1. Geschäftsproblem und Projektauftrag bestätigen

Einigen Sie sich zunächst darauf, was das Intranet verbessern soll, bevor Sie in Konfiguration, Migration oder Entwicklung einsteigen.

Dokumentieren Sie die Probleme der Mitarbeitenden, die das Intranet lösen muss, mit Beispielen aus der Organisation.
Vereinbaren Sie, welche Probleme ins Intranet gehören und welche bei bestehenden Fachsystemen bleiben.
Benennen Sie einen Executive Sponsor mit der Befugnis, Mittel freizugeben und teamübergreifende Konflikte zu lösen.
Bestimmen Sie eine verantwortliche Intranet-Ownerin oder einen Owner und klären Sie, wie viel Zeit diese Person vor und nach dem Launch einbringen kann.
Definieren Sie messbare Ergebnisse, Ausgangswerte und eine verantwortliche Person für jede Messung.
Genehmigen Sie ein Projekt-Briefing mit Umfang, Rahmenbedingungen, erwarteten Ergebnissen und der Begründung für den angestrebten Launch-Termin.

Machen Sie „einfacheren Zugang zu Richtlinien“ gemeinsam überprüfbar. Bitten Sie zum Beispiel Mitarbeitende aus verschiedenen Teams, die aktuelle Reiserichtlinie zu finden und festzustellen, wer sie freigegeben hat. Notieren Sie, wie lange es dauert, wo sie hängen bleiben und ob sie die richtige Version finden. Wiederholen Sie denselben Test nach dem Launch. Seitenaufrufe allein sagen Ihnen nicht, ob die Aufgabe leichter geworden ist.

Es hilft auch, das Finden von Informationen vom Abschluss einer Transaktion zu trennen. Das Intranet kann einen Spesenprozess erklären und auf das Finanzsystem verlinken, ohne dieses System zu ersetzen.

Nutzen Sie den Leitfaden zum Intranet-Business-Case, um Mitarbeiterprobleme mit Finanzierungsentscheidungen zu verbinden.

Was bereitliegen sollte: Ein genehmigtes Projekt-Briefing und ein Plan zur Messung Ihres Ausgangspunkts.

2. Mitarbeitende und ihre Zugangsbedürfnisse verstehen

Stellen Sie sicher, dass das erste Release für die Menschen funktioniert, die es nutzen sollen, nicht nur für das Projektteam.

Identifizieren Sie Mitarbeitergruppen nach Rolle, Standort, Sprache, Arbeitsmodell und Zugang zu einem Firmengerät.
Sprechen Sie mit Mitarbeitenden aus Büro, Homeoffice, Frontline und anderen relevanten Gruppen oder beobachten Sie sie bei der Arbeit.
Priorisieren Sie die Aufgaben, die Mitarbeitende erledigen müssen, etwa eine Richtlinie finden, eine Kollegin ausfindig machen oder einen Antrag einreichen.
Halten Sie Hürden fest, die mit gemeinsam genutzten Geräten, privaten Smartphones, instabilen Verbindungen oder fehlender Firmen-E-Mail zusammenhängen.
Dokumentieren Sie Sprach- und Barrierefreiheitsanforderungen und beziehen Sie betroffene Mitarbeitende in die geplanten Tests ein.
Prüfen Sie die vorgeschlagenen Aufgaben des ersten Releases mit Personen aus den Gruppen, die sie nutzen sollen.

Denken Sie daran, dass nicht alle einen Laptop, ein Firmenpostfach oder dieselben Arbeitszeiten haben. Eine Frontline-Mitarbeiterin an einem gemeinsam genutzten Terminal hat andere Anforderungen an Login, Datenschutz und Support als jemand mit Firmenlaptop im Homeoffice.

Notieren Sie für jede wichtige Aufgabe, wer sie erledigen muss, wie diese Person das Intranet erreicht, wie ein gutes Ergebnis aussieht und was ihr im Weg stehen könnte. Das gibt Ihrem Team einen praktischen Ausgangspunkt, um Zugänge einzurichten, die Nutzung zu testen und das neue Intranet den Mitarbeitenden zu erklären.

Was bereitliegen sollte: Ein Bild Ihrer Mitarbeitergruppen und eine priorisierte Liste der Aufgaben, die für sie am wichtigsten sind.

3. Verantwortlichkeiten und Entscheidungswege festlegen

Geben Sie allen eine klare Ansprechperson und vereinbaren Sie, wer welche Entscheidungen trifft, damit die Arbeit im Fluss bleibt.

Benennen Sie Vertreterinnen und Vertreter aus IT, interner Kommunikation, HR und den vom Rollout betroffenen Fachbereichen.
Klären Sie, wann Sicherheit, Datenschutz, Einkauf, Rechtsabteilung und Mitarbeitervertretung einbezogen werden müssen.
Weisen Sie die Verantwortung für Produktentscheidungen, Umsetzung, Inhalte, Integrationen, Tests und laufenden Support zu.
Vereinbaren Sie, wer Anforderungen, Budgetänderungen, Launch-Reife und Ausnahmen genehmigt.
Legen Sie fest, wie oft Sie sich treffen, wo Entscheidungen und Risiken dokumentiert werden und an wen man sich wendet, wenn die Arbeit stockt.
Reservieren Sie Zeit für Content-Verantwortliche, Testpersonen aus der Belegschaft, Administratoren und andere interne Mitwirkende.

Gehen Sie einen Schritt weiter, als nur eine Abteilung zu nennen: Wählen Sie für jeden Arbeitsstrang eine Person, die Entscheidungen treffen oder die richtige Freigabe einholen kann.

Halten Sie Entscheidungsnotizen kurz, aber nützlich: Fragestellung, geprüfte Optionen, Entscheidung, Genehmigende, Datum und betroffene Anforderungen. Vereinbaren Sie, wer bei einer blockierten Entscheidung helfen kann, damit das Team nicht ständig informell nachhaken muss.

Was bereitliegen sollte: Eine klare Liste von Verantwortlichkeiten, Entscheidungsträgern und der Zeit, die jede beteiligte Person einbringen kann.

4. Budget und Lieferumfang genehmigen

Planen Sie sowohl die Inbetriebnahme des Intranets als auch dessen Betreuung, sobald Mitarbeitende es nutzen.

Schätzen Sie die Anfangskosten für Einrichtung, Konfiguration, Integrationen, Migration, Schulung und vereinbarte Erweiterungen.
Schätzen Sie die laufenden Kosten für Hosting, Support, Updates, Content-Betrieb und Drittanbieterdienste.
Berücksichtigen Sie interne Personalzeit und eine Reserve mit einem vereinbarten Freigabeprozess für deren Nutzung.
Definieren Sie, was im ersten Release enthalten ist, was verschoben wird und was ausdrücklich ausgeschlossen ist.
Vereinbaren Sie Meilensteine mit Abhängigkeiten, Verantwortlichen und Abnahmekriterien statt reiner Termine.
Genehmigen Sie sowohl das Implementierungsbudget als auch ein Betriebsbudget mit namentlich benannten Budgetverantwortlichen.

Open Intranet ist ein Open-Source-System auf Basis von Drupal. Es gibt keine Lizenzgebühren pro Nutzer, aber die Betriebskosten brauchen trotzdem einen Platz im Budget. Kalkulieren Sie Hosting, Wartung, redaktionelle Arbeit, Support und kostenpflichtige externe Dienste ein. Prüfen Sie die Preisinformationen zu Open Intranet zusammen mit Ihren internen Personalschätzungen.

Geben Sie jedem Meilenstein eine klare Bedeutung. „Pilotbereit“ sollte heißen, dass vereinbarte Inhalte, Mitarbeiterzugänge und Testszenarien bereitstehen, nicht einfach, dass die geplante Woche erreicht ist.

Was bereitliegen sollte: Ein finanzierter Umsetzungsplan und ein Mehrjahresbudget mit dokumentierten Annahmen und Budgetverantwortlichen.

5. Open Intranet anhand der Anforderungen validieren

Bevor Sie neue Entwicklung planen, prüfen Sie, was das Produkt bereits für Ihr Team leisten kann.

Wandeln Sie jede Muss-Anforderung in ein Szenario um, das sich vorführen und testen lässt.
Prüfen Sie diese Szenarien in einer Open-Intranet-Demo oder Evaluierungsinstallation mit repräsentativen Inhalten.
Klassifizieren Sie jede Anforderung als verfügbar, konfigurierbar, abhängig von einem zusätzlichen Modul oder einer Integration oder als erweiterungsbedürftig.
Prüfen Sie Verfügbarkeit und Release-Status der vorgesehenen Funktionen, statt experimentelle oder Vorabversionen als launchreif zu behandeln.
Entscheiden Sie für jede verbleibende Lücke, ob Sie den Prozess ändern, eine vorhandene Funktion konfigurieren, eine unterstützte Komponente ergänzen, erweitern oder verschieben.
Genehmigen Sie die Übersicht dessen, was passt und was fehlt, zusammen mit Kosten, Wartungsverantwortung und Abnahmekriterien für jede vorgeschlagene Erweiterung.

Beginnen Sie mit der Produktdokumentation von Open Intranet und probieren Sie Ihre wichtigsten Aufgaben in der Version aus, die Sie einsetzen wollen. Ziel ist, ein konfiguriertes Produkt gegen Ihre Bedürfnisse zu prüfen, nicht jede Funktion von Grund auf neu zu beauftragen.

Ersetzen Sie zum Beispiel „unterstützt zugriffsbeschränkte Dokumente“ durch ein Szenario: Eine berechtigte Mitarbeiterin kann ein Dokument finden und öffnen, während ein nicht berechtigtes Konto weder über die Suche noch über einen direkten Link darauf zugreifen kann.

Nutzen Sie die Ressource zu Intranet-Anforderungen, um den Vergleich zu strukturieren. Notieren Sie die getestete Version, Annahmen zur Einrichtung, Ergebnisse und noch offene Entscheidungen.

Planen Sie Zeit ein, um Identitätsintegrationen in Ihrer eigenen Umgebung zu konfigurieren und zu testen. Ebenso muss Self-Hosting weiterhin gegen Ihre Sicherheits- und regulatorischen Pflichten geprüft werden.

Was bereitliegen sollte: Ein genehmigter Vergleich Ihrer Anforderungen mit den Produktfunktionen, mit einer Entscheidung für jede verbleibende Lücke.

6. Hosting, Verträge und Betriebskontrolle bestätigen

Stellen Sie sicher, dass Ihr Team weiß, wie das Intranet betrieben wird, was enthalten ist und an wen es sich bei Problemen wenden kann.

Wählen Sie einen Hosting-Ansatz auf Basis der organisatorischen Anforderungen und weisen Sie die Verantwortung für den Betrieb zu.
Dokumentieren Sie die geplanten Speicherorte von Anwendungsdaten, Backups, Logs und relevanter externer Verarbeitung.
Prüfen Sie Implementierungsleistungen, Ausschlüsse, Abnahmebedingungen, Support-Umfang und laufende Gebühren.
Bestätigen Sie den Zugriff der Organisation auf Code-Repositories, Konfiguration, Datenexporte, Hosting-Konten und Administrator-Zugangsdaten.
Dokumentieren Sie kostenpflichtige Drittanbieter-Abhängigkeiten, nutzungsabhängige Gebühren, Verlängerungsbedingungen und Leistungsgrenzen.
Vereinbaren Sie einen Übergabe- und Anbieterwechselprozess, einschließlich Exporten, Dokumentation, Zugangsdaten und Unterstützung beim Übergang.

Wählen Sie das Hosting nach Ihrem tatsächlichen Bedarf: Datenstandorte, verfügbares Betriebspersonal, Wiederherstellungsziele, Zugriffskontrollen und Support-Umfang. Berücksichtigen Sie auch die ausgewählte externe Verarbeitung für E-Mail, Analytics oder Suche, nicht nur den eigentlichen Anwendungsserver.

Eine Unterscheidung sollte klar bleiben: Nutzungsrechte an Software und Urheberrecht sind zwei verschiedene Dinge. Open-Source-Lizenzen gewähren Rechte nach ihren Bedingungen; sie übertragen kein exklusives Eigentum an sämtlichem Code aus der Community. Verträge sollten die Rechte und Übergaberegelungen für projektspezifische Arbeiten festhalten.

Was bereitliegen sollte: Eine genehmigte Hosting-Entscheidung und schriftliche Vereinbarungen zu Verantwortlichkeiten und Leistungen.

7. Anforderungen an Identität, Zugriff und Datenschutz definieren

Stellen Sie sicher, dass Mitarbeitende die Informationen erreichen, die sie brauchen, während sensible Informationen bei den richtigen Personen bleiben.

Genehmigen Sie eine Zugriffsmatrix für Mitarbeitende, Redakteure, Administratoren, externe Mitarbeitende und sensible Inhaltsbereiche.
Wählen Sie den Identity Provider und das Login-Verfahren und dokumentieren Sie den erforderlichen Konfigurations- oder Integrationsaufwand.
Definieren Sie Kontoerstellung, Rollenwechsel, Kontolöschung und den Umgang mit bestehenden Sitzungen, wenn der Zugriff entzogen wird.
Vereinbaren Sie mit der Sicherheitsverantwortlichen oder dem Sicherheitsverantwortlichen Anforderungen an Authentifizierung, Sitzungen, gemeinsam genutzte Geräte und Notfall-Administratorzugang.
Identifizieren Sie personenbezogene und sensible Daten und holen Sie die Entscheidungen der zuständigen Verantwortlichen zu Erhebung, Sichtbarkeit, Aufbewahrung und Löschung ein.
Vereinbaren Sie Anforderungen an Sicherheitsprotokollierung, Zugriffsüberprüfungen, Incident Response und die Bearbeitung von Datenauskunftsanfragen von Mitarbeitenden.

Sehen Sie sich die Dokumentation zur Benutzerverwaltung in Open Intranet an, wenn Sie Rollen und Identitätsoptionen zuordnen. Prüfen Sie den gewählten Ansatz gegen Ihren Identity Provider, Ihre Deployment-Variante und Ihre Mitarbeitergruppen.

Nehmen Sie die Kontolöschung in Ihre Tests auf. Prüfen Sie nach dem Deaktivieren eines Kontos im angebundenen Identitätssystem, was mit einer Mitarbeiterin passiert, die bereits im Intranet angemeldet ist. Vereinbaren Sie, wie schnell dieser Zugriff enden soll, und testen Sie es dann.

Nutzen Sie diese Prüfpunkte, um das Gespräch mit Ihren Kolleginnen und Kollegen aus Sicherheit, Datenschutz und Recht zu strukturieren. Sie müssen die Anforderungen für Ihr Deployment weiterhin freigeben; die Checkliste ist keine Rechtsberatung und keine Garantie für Compliance.

Was bereitliegen sollte: Ein genehmigter Plan, wer auf was zugreifen darf, zusammen mit den vereinbarten Sicherheits- und Datenschutzanforderungen.

8. Inhalte prüfen und Publishing-Governance festlegen

Geben Sie dem neuen Intranet einen nützlichen, gut strukturierten Ausgangspunkt, bei dem sich jemand um jeden Inhaltsbereich kümmert.

Inventarisieren Sie bestehende Seiten, Dateien, Wissensquellen und Ablagen, einschließlich ihrer Verantwortlichen und Zielgruppen.
Klassifizieren Sie jeden Inhaltsbestand als migrieren, neu schreiben, archivieren, löschen nach Freigabe gemäß Aufbewahrungsregeln oder im bestehenden System belassen.
Weisen Sie jedem Inhaltsbereich, der zum Launch enthalten ist, eine verantwortliche Person und ein nächstes Überprüfungsdatum zu.
Vereinbaren Sie Inhaltstypen, erforderliche Metadaten, Namenskonventionen und Regeln für Dokumentversionen.
Dokumentieren Sie den Prozess für Entwurf, Prüfung, Freigabe, Veröffentlichung, Korrektur und Ausmusterung.
Genehmigen Sie redaktionelle Leitlinien und barrierefreie Vorlagen für die im ersten Release benötigten Inhaltstypen.

Sie müssen nicht jede alte Datei mitnehmen. Beginnen Sie mit dem Material, das Mitarbeitende für die Aufgaben des ersten Releases brauchen. Bitten Sie Content-Verantwortliche, widersprüchliche Richtlinien und doppelte Dokumente vor dem Import zu bereinigen.

Nutzen Sie die Dokumentation zur Dokumentenverwaltung, um Ihre Veröffentlichungsregeln mit den verfügbaren Konfigurationsmöglichkeiten abzugleichen. Wo Informationen in einem anderen System bleiben, machen Sie deutlich, wie Mitarbeitende die aktuelle, freigegebene Version finden.

Was bereitliegen sollte: Eine Liste der zu migrierenden Inhalte, benannte Verantwortliche und vereinbarte Veröffentlichungsregeln.

Helfen Sie Mitarbeitenden, nützliche Informationen zu finden, ohne das Organigramm auswendig kennen zu müssen.

Strukturieren Sie die vorgeschlagene Navigation nach Aufgaben der Mitarbeitenden und validieren Sie die Bezeichnungen mit den vorgesehenen Nutzern.
Vereinbaren Sie die Prioritäten der Startseite und die Inhalte, die verschiedene Zielgruppen zuerst sehen müssen.
Definieren Sie Taxonomie, Metadaten, Filter und die Inhaltsquellen, die die Suche einbeziehen oder ausschließen soll.
Bereiten Sie repräsentative Suchanfragen mit erwarteten nützlichen Ergebnissen sowie Beispiele für zugriffsbeschränkte Ergebnisse vor, die verborgen bleiben müssen.
Testen Sie zentrale Nutzerpfade in einer konfigurierten Evaluierungsumgebung, bevor Sie unnötige Änderungen an der Oberfläche beauftragen.
Halten Sie Abnahmekriterien für Mobilgeräte und Barrierefreiheit fest und lösen Sie Navigationsprobleme, die in frühen Tests auffallen.

Beginnen Sie mit der bestehenden Oberfläche und der Navigationskonfiguration von Open Intranet. Probieren Sie diese Optionen zuerst mit Mitarbeitenden aus und prototypisieren Sie zusätzliches Verhalten erst dort, wo ein ungelöster Bedarf es rechtfertigt.

Verwenden Sie die Wörter, die Mitarbeitende tatsächlich eintippen würden, nicht nur exakte Dokumenttitel. Prüfen Sie zum Beispiel, ob „frei nehmen“ zur passenden Urlaubsregelung führt. Prüfen Sie außerdem, dass zugriffsbeschränkte Informationen für nicht berechtigte Konten aus Ergebnistiteln, Textausschnitten und anderen Vorschauen herausbleiben.

Was bereitliegen sollte: Eine getestete Navigation und ein Satz von Mitarbeiteraufgaben und Suchanfragen mit klar erwarteten Ergebnissen.

10. Funktionen für das erste Release konfigurieren

Konzentrieren Sie das erste Release auf das, was Mitarbeitende am dringendsten brauchen. Weitere nützliche Funktionen können später folgen.

Konfigurieren Sie Branding, Startseiten-Layouts, Navigation und wiederverwendbare Seitenvorlagen für die vereinbarten Zielgruppen.
Konfigurieren Sie die ausgewählten Funktionen für News, Wissen, Dokumente und Mitarbeiterverzeichnis sowie deren Content-Verantwortliche.
Entscheiden Sie, ob Veranstaltungen, Formulare, soziale Interaktionen, Lesebestätigungen und andere optionale Funktionen ins erste Release gehören.
Konfigurieren Sie ausgewählte Workflows, Benachrichtigungen, Zielgruppensteuerung und Moderationsregeln und testen Sie deren Empfänger.
Konfigurieren Sie ausgewählte Sprachen, Profilfelder und Sichtbarkeitseinstellungen mit repräsentativen Mitarbeiterkonten.
Prüfen Sie jede vorgeschlagene Codeänderung gegen die verfügbaren Konfigurationsoptionen und dokumentieren Sie genehmigte Ausnahmen.

Wenden Sie diese Prüfpunkte auf die Funktionen an, die Sie für Ihr geplantes Release ausgewählt und verifiziert haben. Manche Optionen benötigen möglicherweise zusätzliche Komponenten oder Aufwand.

Halten Sie fest, welche optionalen Funktionen Sie aufnehmen und welche Sie für später zurückstellen. Eine Funktion, die Sie bewusst nicht nutzen, müssen Sie weder konfigurieren noch testen. Für die aufgenommenen Funktionen klären Sie zuerst Verfügbarkeit, Abhängigkeiten, Berechtigungen und Abnahmekriterien.

Prüfen Sie bei Benachrichtigungen, wer die Nachricht erhält, welche Informationen sie preisgibt und wohin ihre Links führen. Melden Sie sich bei Profilen als gewöhnliche Mitarbeiterin oder gewöhnlicher Mitarbeiter an, um die Sichtbarkeit der Felder zu prüfen, statt sich auf die Administratoransicht zu verlassen.

Was bereitliegen sollte: Eine Dokumentation der Konfiguration und Testergebnisse für die Funktionen in Ihrem vereinbarten Umfang.

11. Erforderliche Systeme anbinden und testen

Prüfen Sie, dass Informationen zuverlässig zwischen Ihren Systemen fließen und dass jemand bereitsteht, wenn der Fluss stoppt.

Listen Sie jede launchkritische Integration mit Systemverantwortlichem, Zweck und genehmigtem Umsetzungsansatz auf.
Vereinbaren Sie für jeden Datenfluss die führende Datenquelle, Feldzuordnungen, Übertragungsrichtung und Aktualisierungsfrequenz.
Beschaffen Sie erforderliche Zugangsdaten und Berechtigungen und dokumentieren Sie, wie Secrets gespeichert und rotiert werden.
Testen Sie erfolgreiche Übertragungen und Fehlerfälle, einschließlich doppelter Datensätze, fehlender Felder, veralteter Daten und nicht erreichbarer Dienste.
Klären Sie, wer Fehlermeldungen erhält, wer Incidents löst und wie verpasste Aktualisierungen nachgeholt werden.
Dokumentieren Sie Monitoring, laufende Kosten und die Verantwortung für das Testen künftiger Änderungen an angebundenen Systemen.

Vereinbaren Sie, welchem System bei widersprüchlichen Werten zu vertrauen ist. Stammen Abteilungsdaten der Mitarbeitenden aus einem HR-System, entscheiden Sie, ob Änderungen im Intranet gesperrt, überschrieben oder über einen vereinbarten Ausnahmeprozess behandelt werden.

Verwenden Sie in Testumgebungen realistische Beispieldaten oder angemessen geschützte Daten. Halten Sie sensible Echtdaten aus einer Testinstallation heraus, sofern deren Nutzung nicht ordnungsgemäß geprüft und abgesichert wurde.

Wenn für den Launch keine Integrationen nötig sind, dokumentieren Sie einfach diese Entscheidung und ihre Freigabe. So ist klar, dass das Team die Frage geprüft und nicht übersehen hat.

Was bereitliegen sollte: Eine Liste der Integrationen und genehmigte Testergebnisse oder vereinbarte Gründe für deren Verzicht.

12. Umgebungen und Wiederherstellungsverfahren vorbereiten

Geben Sie Ihrem Team einen wiederholbaren Weg, Updates auszurollen, und einen getesteten Plan, um das Intranet zurückzuholen, wenn etwas schiefgeht.

Richten Sie getrennte Umgebungen für Konfiguration/Test und Produktion mit angemessenen Zugriffsbeschränkungen ein.
Dokumentieren und üben Sie den Prozess, mit dem freigegebene Konfiguration und Code in die Produktion gelangen.
Konfigurieren Sie Domain, verschlüsselte Verbindungen, ausgehende Nachrichten, geplante Jobs und die vom Deployment benötigte Suchinfrastruktur.
Richten Sie Monitoring für Verfügbarkeit, Fehler, Kapazität, Hintergrundjobs und kritische Integrationen mit benannten Alarmempfängern ein.
Vereinbaren Sie Wiederherstellungsziele und demonstrieren Sie eine Wiederherstellung aus dem Backup in einer kontrollierten Umgebung.
Dokumentieren Sie Update-Tests, Verantwortung für Sicherheitspatches, Incident-Eskalation und Verfahren für den Deployment-Rollback.

Vereinbaren Sie, wie viel Datenverlust und Ausfallzeit die Organisation akzeptieren kann. Leiten Sie aus diesen Zielen ab, wie oft gesichert wird, wie lange Backups aufbewahrt werden und wie sie wiederhergestellt werden.

Testen Sie die Wiederherstellung, nicht nur das Backup. Stellen Sie die benötigte Datenbank, Dateien und Konfiguration wieder her und prüfen Sie dann Zugriff und zentrale Mitarbeiteraufgaben. Notieren Sie, wie lange es dauert und welche Schritte manuell erledigt werden müssen.

Beschränken Sie ausgehende Nachrichten in Testumgebungen, damit Übungen nicht versehentlich Mitarbeitende benachrichtigen. Halten Sie die Anleitung zum Zurückrollen eines Deployments getrennt von der zur Wiederherstellung des gesamten Dienstes.

Was bereitliegen sollte: Ein praxistaugliches Betriebshandbuch, ein erfolgreicher Wiederherstellungstest und benannte Personen, die für den Betrieb verantwortlich sind.

13. Launch-Inhalte migrieren und freigeben

Bringen Sie die freigegebenen Inhalte in ihr neues Zuhause und prüfen Sie, dass Mitarbeitende die richtige Version finden.

Ordnen Sie Quellinhalte, Dateien, Metadaten, Verantwortlichkeiten und Berechtigungen ihren Zielstrukturen zu.
Führen Sie eine Testmigration mit repräsentativen Inhaltstypen, Dokumenten und Zugriffsbeschränkungen durch.
Prüfen Sie migrierte Inhalte auf fehlende Dateien, defekte Links, doppelte Datensätze, Formatierungsprobleme und falsche Berechtigungen.
Lassen Sie Content-Verantwortliche die neu geschriebenen und migrierten Launch-Inhalte freigeben, einschließlich zentraler Richtlinien und Hilfeseiten.
Vereinbaren Sie Content Freeze, Prozess für letzte Aktualisierungen, Verantwortlichkeiten für den Cutover und Rückfallplan.
Definieren Sie Weiterleitungen, Archivzugriff und den Abschaltplan für alte Veröffentlichungsorte, damit Mitarbeitende wissen, welche Version verbindlich ist.

Vergleichen Sie, was Sie migrieren wollten, mit dem, was tatsächlich angekommen ist. Notieren Sie, was übertragen wurde, was fehlgeschlagen ist, was bewusst ausgelassen wurde und was manuell korrigiert werden muss. Datensatzzahlen helfen, fehlendes Material zu erkennen, aber prüfen Sie auch Berechtigungen, Links und die Inhalte selbst.

Ihr Plan für den Launch-Übergang sollte erklären, wie Änderungen nach der Testmigration auf die Live-Site gelangen. Vereinbaren Sie, wer während des Content Freeze veröffentlichen darf und wie dringende Korrekturen behandelt werden.

Was bereitliegen sollte: Geprüfte Migrationsergebnisse, Freigabe durch die Content-Verantwortlichen und ein Plan für den finalen Umzug.

14. Abnahmetests und Mitarbeiter-Pilot abschließen

Laden Sie Mitarbeitende ein, das Intranet unter den Bedingungen auszuprobieren, unter denen sie es tatsächlich nutzen werden, und prüfen Sie die Ergebnisse gegen Ihre vereinbarten Anforderungen.

Weisen Sie nach, dass jede launchkritische Anforderung ihren vereinbarten Abnahmetest besteht.
Testen Sie Berechtigungen mit berechtigten und nicht berechtigten Konten, einschließlich direkter Dateilinks, Suchergebnisse und Benachrichtigungen.
Testen Sie Login, Kontolöschung, mobile Nutzung, unterstützte Browser, Tastaturnavigation und relevante assistive Technologien.
Testen Sie die Performance anhand vereinbarter Nutzungsszenarien und dokumentieren Sie die Ergebnisse gegen die akzeptierten Schwellenwerte.
Führen Sie einen Pilot mit repräsentativen Mitarbeitenden durch und dokumentieren Sie Aufgabenerledigung, Feedback und Support-Anfragen.
Beheben Sie launchblockierende Fehler und holen Sie schriftliche Entscheidungen, Verantwortliche und Fristen für akzeptierte offene Punkte ein.

Probieren Sie Aufgaben als gewöhnliche Mitarbeiterin oder gewöhnlicher Mitarbeiter aus, nicht nur als Administrator. Berücksichtigen Sie verschiedene Rollen und Zugriffsbedingungen, etwa eingeschränkte Konten und gemeinsam genutzte Geräte, wo relevant.

Vereinbaren Sie Performance-Szenarien vor den Tests: erwartete gleichzeitige Aktivität, häufige Seitenaufrufe, Suchanfragen und Dokumentzugriffe. Notieren Sie Umgebung und Datenbestand, damit das Team versteht, was die Ergebnisse abdecken.

Führen Sie Fehlerbehebungen und neue Ideen auf getrennten Listen. Eine nicht bestandene launchkritische Anforderung braucht eine Korrektur und einen weiteren Test; eine nützliche Verbesserung kann im späteren Backlog warten, ohne das erste Release stillschweigend zu erweitern.

Was bereitliegen sollte: Ein Abnahmebericht und eine Pilot-Entscheidung, einschließlich Freigaben für alle noch offenen Punkte.

15. Mitarbeitende vorbereiten und Launch freigeben

Helfen Sie Mitarbeitenden, sich auf die Veränderung vorbereitet zu fühlen, und bringen Sie das Team für eine klare Launch-Entscheidung zusammen.

Schulen Sie Redakteure, Administratoren und Support-Mitarbeitende und bestätigen Sie, dass sie ihre zugewiesenen Aufgaben ausführen können.
Bereiten Sie Hinweise für Mitarbeitende vor, die erklären, wo sie sich anmelden, was umgezogen ist, warum sie das Intranet nutzen sollten und wo sie Hilfe bekommen.
Planen Sie die Launch-Kommunikation für alle relevanten Gruppen, einschließlich Mitarbeitender ohne Zugang zur Firmen-E-Mail.
Weisen Sie die Betreuung am Launch-Tag und in der Anfangsphase, einen Feedback-Kanal und Kontakte für die Incident-Eskalation zu.
Bestätigen Sie, dass die Verantwortlichen für Inhalte, Zugriff, Wiederherstellung, Integrationen, Tests und Betrieb ihre Nachweise zur Bereitschaft geliefert haben.
Halten Sie ein dokumentiertes Go/No-Go-Review ab, das Blocker, akzeptierte Risiken, Cutover-Zeitpunkt, Rollback-Auslöser und die Person mit Rollback-Befugnis abdeckt.

Geben Sie den Menschen in der Schulung die Gelegenheit zu üben. Lassen Sie Redakteure Inhalte veröffentlichen und korrigieren, Administratoren zugewiesene Kontoaufgaben erledigen und Support-Mitarbeitende ein realistisches Zugriffsproblem durcharbeiten.

Wählen Sie Kommunikationskanäle, die Mitarbeitende tatsächlich erreichen. Je nach Organisation können das Briefings durch Vorgesetzte, Schichtübergaben, gedruckte Anmeldeanleitungen oder bestehende Kanäle am Arbeitsplatz sein.

Teilen Sie im Go/No-Go-Review die relevanten Testergebnisse und Freigaben, nicht nur Fertigstellungsgrade in Prozent. Dokumentieren Sie, wer die Entscheidung wann getroffen hat, welche Risiken akzeptiert wurden und was das Team veranlassen würde, den Launch zu stoppen oder zurückzunehmen.

Was bereitliegen sollte: Eine genehmigte Launch-Entscheidung und ein Übergangsplan mit zugewiesenen Personen. Lassen Sie die Bereitschaft, nicht nur den Kalender, die finale Entscheidung bestimmen.

16. Betreiben, verbessern und das alte Intranet abschalten

Hören Sie nach dem Launch weiter zu, kümmern Sie sich um den Dienst und schalten Sie die alten Werkzeuge ab, wenn Ihr Team bereit ist, sie sicher loszulassen.

Bestätigen Sie nach dem Cutover, dass Mitarbeiterzugang, zentrale Aufgaben, Integrationen, Benachrichtigungen und Monitoring in der Produktion funktionieren.
Werten Sie frühe Support-Anfragen und Mitarbeiter-Feedback aus und weisen Sie wiederkehrenden Problemen Verantwortliche zu.
Vergleichen Sie vereinbarte Erfolgskennzahlen mit ihren Ausgangswerten und planen Sie Folgeüberprüfungen ein.
Nehmen Sie Inhaltsprüfungen, Zugriffsüberprüfungen, Patching, Wiederherstellungstests und Kapazitätsprüfungen in den Betriebskalender auf.
Pflegen Sie ein priorisiertes Verbesserungs-Backlog und prüfen Sie Kosten und Support-Bedarf, bevor Sie neue Funktionen ergänzen.
Schalten Sie das alte Intranet und überflüssige Dienste erst ab, wenn die Verantwortlichen Aufbewahrung, Archivzugriff, Weiterleitungen und Vertragsbeendigung freigegeben haben.

Kehren Sie zu den Mitarbeiteraufgaben-Tests zurück, die Sie im Business Case aufgesetzt haben. Sind Richtlinien immer noch schwer zu finden, schauen Sie auf Suchbegriffe, doppelte Inhalte, Navigation und Berechtigungen, bevor Sie entscheiden, dass eine weitere Funktion die Lösung ist.

Nutzen Sie einen Intranet-Check, um spätere Gespräche darüber zu strukturieren, was funktioniert und wo Mitarbeitende noch Unterstützung brauchen. Priorisieren Sie Verbesserungen nach Geschäftsnutzen, Belegen, Kosten und laufendem Support-Bedarf.

Die Abschaltung der alten Plattform muss nicht überstürzt werden. Sie kann nach der Anfangsphase mit erweitertem Support erfolgen. Klären Sie Archivzugriff und Aufbewahrungsentscheidungen, bevor Sie Infrastruktur entfernen oder Verträge beenden.

Was bereitliegen sollte: Eine abgeschlossene Übergabe, eingeplante Überprüfungen und die Freigabe zur Abschaltung des alten Systems. Der Launch ist ein Meilenstein; die Betreuung des Intranets geht weiter.

Bereit, die Checkliste in einen Umsetzungsplan zu verwandeln?

Bringen Sie diese Checkliste, die für Ihr Team wichtigsten Mitarbeiteraufgaben und Ihre Integrationsanforderungen in eine Open-Intranet-Demo mit.

Gemeinsam können wir herausfinden, was sich konfigurieren lässt, was angebunden werden muss und welche verbleibenden Lücken tatsächlich Entwicklung erfordern. So haben Sie einen klareren Ausgangspunkt für Umfang, Kosten, Verantwortlichkeiten und Launch-Reife, bevor Sie sich auf einen Liefertermin oder ein Budget festlegen.