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 8 bis 15 verschiedenen SaaS-Tools. Notion für Dokumentation, Jira oder Linear für Projektmanagement, Figma für Design, Google Drive oder SharePoint für Dateien, Slack oder Teams für Kommunikation. Dazu kommen spezialisierte Tools: ein CRM, ein Analytics-Dashboard, ein HR-System, ein 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: Mitarbeiter tippt short/urlaub in die Browser-Adresszeile und landet direkt im HR-Tool. Fertig.
Wie das in der Praxis aussieht
Das Team erstellt Shortcuts für die wichtigsten Ressourcen. short/roadmap führt zur Notion-Seite mit der Produkt-Roadmap. short/hr führt zu Personio. short/brand führt zum Google-Drive-Ordner mit den Brand Guidelines. short/pitch-deck führt 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 funktioniert am besten für Teams zwischen 5 und 100 Personen, die mehrere SaaS-Tools nutzen und noch kein etabliertes Intranet haben. Oder die ein Intranet haben, das niemand nutzt.
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 sind IT-Projekte. Sie dauern Monate, kosten sechsstellig, und brauchen dedizierte Admins für die Pflege. Die meisten scheitern nicht an der Technik, sondern an der Adoption. Das schönste Portal bringt nichts, wenn die Leute weiterhin in Slack fragen, wo der Urlaubsantrag ist.
Ein Navigations-Layer ist das Gegenteil davon. Setup dauert eine Stunde, nicht ein Quartal. Die Pflege verteilt sich auf das Team. Und die Adoption ist hoch, weil es kein neues Verhalten erfordert — du tippst einfach eine Adresse in den Browser statt eine URL zu suchen.
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.