Das Headless Intranet
Irgendwann kommt in jeder Firma der Punkt, an dem jemand sagt: “Wir brauchen ein neues Intranet.”
Meistens nutzt es niemand. Das System lahmt, der Suchindex ist unbrauchbar, Inhalte stammen aus 2019, und die Oberfläche sieht aus wie 2014. Also wird ein Projekt aufgesetzt. Budget wird freigegeben. Ein neues Portal wird evaluiert, ausgewählt, implementiert. Sechs bis zwölf Monate später ist es live.
Und dann passiert das Gleiche nochmal. Nach ein paar Monaten nutzt es wieder niemand.
Das Problem ist ein anderes: Du packst ein neues Portal auf alte Probleme und hoffst, das hilft.
Warum Portale scheitern
Die meisten Teams arbeiten heute in mehreren SaaS-Tools: Notion für Dokumentation, Jira oder Linear für Projektmanagement, Figma für Design, Google Drive oder SharePoint für Dateien und Slack oder Teams für Kommunikation. Dazu kommen spezialisierte Tools wie CRM, Analytics-Dashboard, HR-System oder Wiki.
Jedes dieser Tools hat seine eigene Oberfläche, seine eigene Suchfunktion, seine eigene Logik. Die Inhalte leben verteilt über diese Tools. Das ist auch richtig so — du willst deine Designs in Figma bearbeiten, nicht in einem Intranet-Portal.
Ein klassisches Intranet versucht, all diese Inhalte an einem zentralen Ort zusammenzuführen. Entweder durch Kopieren (dann sind die Inhalte sofort veraltet) oder durch Einbettungen und iFrames (dann ist die Nutzererfahrung schlecht). In beiden Fällen entsteht ein zusätzliches Tool, das gepflegt werden muss. Und Pflege ist genau das, woran Intranets sterben.
Keiner will noch ein Portal öffnen. Mitarbeiter wollen wissen, wo was ist. Das ist alles.
Was “Headless” in diesem Kontext bedeutet
In der Softwareentwicklung meint “headless”, dass man den Inhalt von der Darstellung trennt. Ein Headless CMS speichert Inhalte, zeigt sie aber nicht selbst an — das übernehmen andere Systeme.
Übertragen auf ein Intranet heißt das: Du brauchst kein Portal, das Inhalte anzeigt. Du brauchst ein System, das weiß, wo Inhalte leben, und die Leute dorthin bringt.
Keine weitere Oberfläche, kein zusätzliches Portal. Ein Verzeichnis, das die Leute zu ihren bestehenden Tools führt.
Statt: Mitarbeiter öffnet Intranet-Portal, sucht nach “Urlaubsantrag”, findet (vielleicht) einen Link zum HR-Tool.
Eher so: Ein Mitarbeiter tippt short, drückt die Leertaste, gibt urlaub ein und landet direkt im HR-Tool.
Wie das in der Praxis aussieht
Das Team erstellt Shortcuts für die wichtigsten Ressourcen. /roadmap führt zur Notion-Seite mit der Produkt-Roadmap, /hr zum HR-Tool, /brand zum Google-Drive-Ordner mit den Brand Guidelines und /pitch-deck zur aktuellen Präsentation.
Die Shortcuts sind für alle im Team sichtbar und funktionieren im Browser. Wenn sich die URL hinter einem Shortcut ändert (weil jemand eine Notion-Seite verschoben hat oder das Analytics-Tool gewechselt wurde), wird der Shortcut einmal aktualisiert. Alle anderen merken davon nichts.
Das ist kein Intranet im klassischen Sinn. Es gibt keine Startseite, keine News-Beiträge, keine Kommentarfunktion. Es ist eher ein Inhaltsverzeichnis. Aber Inhaltsverzeichnisse sind nützlicher als die meisten Leute denken, weil sie das eine Problem lösen, das tatsächlich jeden Tag auftritt: “Wo finde ich X?”
Für wen das funktioniert (und für wen nicht)
Dieser Ansatz kann gut zu kleinen und mittleren Teams passen, die mehrere SaaS-Tools nutzen und noch kein Intranet haben oder mit dessen Nutzung unzufrieden sind.
Er funktioniert weniger gut für Unternehmen, die ein Intranet als Kommunikationskanal brauchen — für News, Ankündigungen, CEO-Updates. Dafür brauchst du tatsächlich eine Oberfläche mit Feed und Kommentaren. Aber selbst in diesem Fall löst ein Portal nicht das Navigationsproblem. Du brauchst beides: einen Ort für Kommunikation und einen Ort, der dir sagt, wo Dinge liegen.
Was das für die IT bedeutet
Klassische Intranet-Projekte können Monate dauern und eigene Administration erfordern. Auch ein leistungsfähiges Portal hat ein Akzeptanzproblem, wenn die Leute weiterhin in Slack fragen, wo der Urlaubsantrag ist.
Ein Navigations-Layer kann mit wenigen häufig genutzten Links beginnen und mit der Zeit wachsen. Die Pflege lässt sich im Team verteilen, und die Browser-Erweiterung bietet einen direkten Ablauf über die Adresszeile.
Größere Unternehmen mit Compliance-Anforderungen brauchen wahrscheinlich echte Intranets. Aber für ein 20-Personen-Startup, das gerade überlegt, ob es Confluence oder eine Notion-Seite als “Intranet” nutzen soll? Da ist ein leichtgewichtiges Navigations-System die bessere Antwort.
Das nächste Mal, wenn jemand in deinem Team sagt “Wir brauchen ein Intranet”, frag zurück: “Was genau soll es lösen?” Wenn die Antwort “Die Leute finden nichts” ist, brauchst du kein Portal. Du brauchst ein Inhaltsverzeichnis.