Der wichtigste Satz vorweg: Linchpin ist keine geschlossene Intranet-Anwendung, sondern eine Veredelung von Confluence. Diese Konstruktion erklärt fast alle Stärken und alle Grenzen des Produkts. Stärke, weil Sie ein ausgereiftes Wiki mit Versionierung, Rechtekonzept, Kommentaren, Vorlagen und einem großen Erweiterungsmarkt gratis mitbekommen – Wissensmanagement und Intranet fallen zusammen, statt zwei getrennte Systeme zu sein. Grenze, weil Sie Confluence auch dann pflegen, lizenzieren und aktualisieren müssen, wenn Sie es eigentlich nur als Unterbau brauchen, und weil Sie in der Produktstrategie eines zweiten Herstellers stehen.
Drei Eigenschaften beschreiben Linchpin treffender als jede Funktionsliste:
//SEIBERT/MEDIA ist seit vielen Jahren als Atlassian-Partner im deutschsprachigen Raum aktiv und hat sich vom Dienstleister zum Produkthersteller entwickelt. Das Unternehmen entwickelt eine Reihe von Erweiterungen für Confluence und Jira, betreibt Beratung und Umsetzung und ist in der deutschen Atlassian-Community stark sichtbar. Linchpin ist das Produkt, mit dem der Anbieter über die Grenzen dieser Community hinaus bekannt wurde.
Diese Herkunft prägt das Produkt in zwei Richtungen. Positiv: Linchpin ist von Menschen gebaut, die Confluence in der Praxis großer Installationen kennen. Die Erweiterungen greifen nicht nur oberflächlich in die Oberfläche ein, sondern nutzen die Plattformmechanismen – Berechtigungen, Bereichsstrukturen, Makros, Vorlagen – so, wie sie gedacht sind. Für die Wartbarkeit ist das entscheidend. Kritisch: Der Anbieter ist ein mittelständisches Unternehmen und kein Konzern. Das bedeutet kurze Wege, direkten Kontakt und deutschsprachigen Support – aber auch, dass Sie sich mit der Frage der Anbieterstabilität und der Produktabhängigkeit auseinandersetzen sollten, so wie bei jedem spezialisierten Hersteller.
Wichtig für die Einordnung: Der Name Linchpin begegnet Ihnen in mehreren Zusammenhängen – als vollständige Suite, als einzelne Erweiterungen aus dieser Suite und als Cloud-Variante mit eigenem Zuschnitt. Prüfen Sie deshalb bei jeder Aussage über Linchpin, auf welche Ausbaustufe und auf welche Atlassian-Plattform sie sich bezieht. Die Unterschiede sind erheblich und die häufigste Ursache für Missverständnisse in Auswahlprojekten.
Ein Intranet auf Confluence zu bauen, ist eine bewusste Architekturentscheidung mit Folgen weit über das Portal hinaus. Sie erwerben und betreiben zwei Produkte von zwei Herstellern, die in einer Abhängigkeitskette stehen: Atlassian liefert die Plattform, //SEIBERT/MEDIA die Intranet-Schicht darauf. Wenn Atlassian seine Produktstrategie ändert, betrifft das Ihr Intranet – nicht theoretisch, sondern unmittelbar.
Genau das ist in den vergangenen Jahren geschehen: Atlassian hat die klassische Server-Variante aus dem Angebot genommen und Kunden auf Data Center oder in die Cloud gelenkt. Wer sein Intranet auf Confluence betreibt, musste diesen Weg mitgehen. Das ist kein Argument gegen Linchpin, aber ein Argument dafür, die Plattformfrage vor der Produktfrage zu klären. Fragen Sie sich zuerst: „Wollen wir Confluence als strategische Plattform?“ Erst danach: „Ist Linchpin die richtige Intranet-Schicht darauf?“
Umgekehrt gilt: Wenn Confluence bei Ihnen ohnehin läuft – etwa weil die Entwicklung mit Jira arbeitet, weil das Qualitätsmanagement dort dokumentiert oder weil das Wissensmanagement bereits darauf aufgebaut ist –, dann ist Linchpin einer der naheliegendsten Wege zu einem Intranet. Sie nutzen vorhandene Lizenzen, vorhandenes Betriebswissen, vorhandene Berechtigungsstrukturen und ein Werkzeug, das Ihre Beschäftigten schon kennen. In dieser Konstellation ist das Kosten-Nutzen-Verhältnis kaum zu schlagen.
Aus unserer Beratungspraxis passt Linchpin besonders gut zu vier Profilen. Erstens zu Organisationen mit vorhandener Atlassian-Landschaft, die ihr Intranet nicht als weiteres Silo aufbauen wollen. Zweitens zu Unternehmen mit mehreren Standorten, Sprachen oder Gesellschaften, bei denen zielgruppengenaue Kommunikation nicht Komfort, sondern Voraussetzung ist. Drittens zu Organisationen mit klarer Anforderung an Datenhoheit und deutschsprachige Vertragsbeziehungen – etwa im öffentlichen Umfeld, in regulierten Branchen oder in Unternehmen mit strengen Konzernvorgaben. Viertens zu Betrieben, bei denen Intranet und Wissensmanagement dieselbe Aufgabe sind: Arbeitsanweisungen, Handbücher, Prozessbeschreibungen und Nachrichten sollen an einem Ort liegen.
Weniger gut passt Linchpin, wenn Sie ein reines Kommunikationsinstrument für eine überwiegend gewerbliche Belegschaft suchen, bei dem die App im Zentrum steht und Wissensmanagement keine Rolle spielt. In diesem Szenario sind auf Mitarbeiter-Apps zugeschnittene Produkte oft der direktere Weg. Ebenso zurückhaltend wären wir, wenn in Ihrer Organisation weder Confluence-Erfahrung vorhanden ist noch die Bereitschaft besteht, sie aufzubauen – dann kaufen Sie mit dem Intranet eine zweite Lernkurve ein.
Die Grundlogik folgt dem Atlassian-Marktplatzmodell: Abgerechnet wird typischerweise nach der Zahl der Nutzenden Ihrer Confluence-Instanz, gestaffelt nach Größenklassen, und zwar zusätzlich zur Confluence-Lizenz selbst. Wer die Suite als Bündel lizenziert, zahlt für ein Paket aus mehreren Erweiterungen; wer nur einzelne Bausteine braucht, kann diese getrennt beziehen. Zwischen den Wegen unterscheiden sich vor allem der Funktionsumfang der Personalisierung, die redaktionellen Werkzeuge, die Mehrsprachigkeit, die Verfügbarkeit der App sowie Umfang und Reaktionszeiten des Supports. Die konkrete Zusammensetzung sollten Sie sich für Ihr Angebot schriftlich bestätigen lassen.
Dies ist der wichtigste Abschnitt dieses Kapitels, und er wird in Auswahlprojekten am häufigsten übersehen. Confluence existiert in zwei technisch getrennten Ausprägungen: Data Center für den Betrieb in eigener oder beauftragter Infrastruktur und Cloud als betreuter Dienst des Plattformanbieters. Erweiterungen müssen für beide Welten getrennt entwickelt werden, weil die Erweiterungsschnittstellen unterschiedlich sind. Für Sie bedeutet das: Der Funktionsumfang einer Intranet-Suite kann sich zwischen Data Center und Cloud unterscheiden – bei Linchpin genauso wie bei anderen Marktplatzprodukten.
Historisch ist der Data-Center-Weg der ältere und funktional weiter ausgebaute. Die Cloud-Variante ist neuer, wird kontinuierlich erweitert und bringt Vorteile mit, die der Eigenbetrieb nicht hat: keine Aktualisierungsplanung, keine Infrastrukturverantwortung, laufende Verbesserungen ohne Projektaufwand. Umgekehrt sind Eingriffe in Oberfläche, Navigation und Erscheinungsbild in der Cloud typischerweise stärker begrenzt, weil der Plattformanbieter definiert, was Erweiterungen dürfen.
Die praktische Konsequenz ist einfach und wirksam: Erstellen Sie vor der Beschaffung eine Liste Ihrer unverzichtbaren Funktionen – etwa Zielgruppensteuerung nach bestimmten Profilmerkmalen, mehrsprachige Nachrichten mit Übersetzungsworkflow, eine App für Beschäftigte ohne Firmenkonto, bestimmte Anpassungen am Erscheinungsbild – und lassen Sie deren Verfügbarkeit für Ihre gewählte Plattform schriftlich bestätigen. Allgemeine Produktübersichten reichen dafür nicht.
Linchpin positioniert sich nicht als Konkurrent zu vollständigen Kommunikationsplattformen mit App-Schwerpunkt, sondern als Intranet-Schicht für Organisationen, die Atlassian als Plattform nutzen oder nutzen wollen. Die Argumentation ruht auf vier Säulen: Personalisierung über Nutzerprofile, die Verbindung von Intranet und Wissensmanagement in einem System, ein deutscher Anbieter mit deutschsprachigem Support und Vertragsverhältnis sowie die Möglichkeit des Betriebs in eigener Infrastruktur.
In Ausschreibungen konkurriert Linchpin deshalb selten über den reinen Funktionsumfang, sondern über eine Vorfrage: Soll das Intranet ein eigenständiges Kommunikationsprodukt sein oder eine Erweiterung der bestehenden Kollaborationsplattform? Wo die Antwort auf ein eigenständiges Produkt hinausläuft, treten Anbieter wie Staffbase oder Haiilo an. Wo die Plattformerweiterung gewünscht ist, konkurriert Linchpin mit SharePoint samt Microsoft-Viva-Bausteinen – und mit der Möglichkeit, bei Confluence pur zu bleiben und die Intranet-Anforderungen abzuspecken.
Ein wichtiger Hinweis zur Erwartungshaltung: Linchpin ist kein Werkzeug für Marketingkommunikation mit aufwendigen Kampagnenlayouts, kein Redaktionssystem für eine öffentliche Website und keine Plattform für hochfrequente Kurznachrichten im Stil moderner Chat-Werkzeuge. Es ist ein Mitarbeiterportal, das Information auffindbar, zielgruppengerecht und dauerhaft nutzbar macht. Wer das erwartet, wird zufrieden sein. Wer eine Social-Media-Erfahrung im Unternehmen erwartet, wird enttäuscht – und zwar unabhängig von der Produktqualität.
Lassen Sie Linchpin nicht in einem generischen Kriterienkatalog gegen App-zentrierte Kommunikationsplattformen antreten. Ein solcher Vergleich fällt zwangsläufig verzerrt aus, weil er entweder Kriterien enthält, die auf Kampagnensteuerung und Push-Kommunikation zielen, oder Kriterien, die auf Dokumentation und Versionierung zielen – je nachdem, wer den Katalog geschrieben hat. Beide Produktkategorien lösen unterschiedliche Aufgaben.
Sinnvoller ist ein Vergleich entlang der Fälle, die Ihre Intranet-Anforderung tatsächlich begründen: die standortspezifische Kantinenmeldung, die verbindliche Arbeitsanweisung mit Lesebestätigung, das Auffinden der zuständigen Person in einem anderen Werk, die Onboarding-Strecke für neue Beschäftigte, die mehrsprachige Nachricht der Geschäftsführung an alle Gesellschaften. Wer so vergleicht, erhält ein realistisches Bild – und eine Entscheidung, die auch zwei Jahre später nachvollziehbar bleibt.
Die folgenden Bausteine machen den praktischen Alltag aus. Welche davon in Ihrer Plattform und Ausbaustufe verfügbar sind und in welcher Ausprägung, sollten Sie vor der Beschaffung abgleichen – der Funktionsumfang von Marktplatzprodukten verändert sich laufend.
Wenn Sie nur eine Funktion aus diesem Kapitel behalten, sollte es diese sein. In einem gewöhnlichen Wiki sehen alle dasselbe – wer Zugriff hat, sieht den Inhalt, wer keinen hat, sieht ihn nicht. Für Dokumentation ist das richtig. Für ein Intranet ist es die Wurzel des größten Problems: Alle bekommen alles, niemand liest mehr etwas, und die Kommunikationsabteilung wundert sich über Reichweiten, die sich nicht bewegen.
Linchpin löst das über Profilmerkmale. Jede Person trägt Eigenschaften – Standort, Gesellschaft, Abteilung, Rolle, Sprache, Schichtmodell, was auch immer Sie definieren –, die entweder aus dem Verzeichnisdienst oder aus dem Personalsystem stammen oder selbst gepflegt werden. Auf diese Merkmale lassen sich Inhalte ausrichten: Nachrichten, Bausteine der Startseite, Navigationseinträge, Verlinkungen zu Fachanwendungen. Aus einem Portal werden viele Sichten – ohne dass Sie viele Portale pflegen.
Der Nutzen ist in Projekten deutlich messbar, allerdings nicht in Klickzahlen, sondern in Entlastung. Die Werksleitung in Standort B muss die Kantinenmeldung von Standort A nicht mehr überlesen. Die Vertriebsmitarbeiterin sieht die Preisliste, nicht die Wartungsplanung. Die Geschäftsführung kann eine Mitteilung an alle senden, ohne dass jede Bereichsmeldung denselben Weg nimmt. Diese Trennschärfe ist die Voraussetzung dafür, dass wichtige Nachrichten überhaupt noch wahrgenommen werden.
Die Kehrseite ist ebenso ehrlich zu benennen: Personalisierung setzt gepflegte Profildaten voraus. Wenn Standort und Abteilung nicht verlässlich hinterlegt sind, funktioniert die Zielgruppensteuerung nicht – und ein Intranet, das Inhalte falsch ausspielt, verliert Vertrauen schneller als eines, das zu viel zeigt. Die Datenquelle für Profilmerkmale ist deshalb kein Nebenthema, sondern ein eigener Arbeitsschritt in der Einführung. Klären Sie früh, ob Verzeichnisdienst oder Personalsystem die führende Quelle ist und wie Änderungen dorthin gelangen.
Der zweite Funktionsblock adressiert die Menschen, die das Intranet betreiben. Nachrichten entstehen nicht mehr als Wiki-Seite, sondern als redaktioneller Beitrag mit definiertem Lebenszyklus: erstellen, freigeben, terminieren, Zielgruppe zuweisen, veröffentlichen, archivieren. Das klingt bürokratisch und ist in der Praxis eine Erleichterung, weil es die Frage beantwortet, wer eine Meldung an alle senden darf – eine Frage, die in offenen Wikis regelmäßig zu Konflikten führt.
Dazu kommen Möglichkeiten, wichtige Meldungen hervorzuheben, sie zeitlich zu befristen und ihre Wahrnehmung nachzuvollziehen. Gerade der letzte Punkt verdient Aufmerksamkeit: Funktionen, die sichtbar machen, wer eine Nachricht gelesen hat, sind fachlich wertvoll – etwa bei sicherheitsrelevanten Anweisungen – und arbeitsrechtlich sensibel, weil sie Verhaltens- und Leistungskontrolle ermöglichen können. Diese Funktionen gehören auf die Agenda der Mitbestimmung, bevor sie aktiviert werden, nicht danach.
Erscheinungsbild und Navigation sind der dritte Teil dieses Blocks. Linchpin erlaubt es, Confluence deutlich stärker an die eigene Marke anzupassen als im Standard: eigene Kopfzeile, eigene Navigationsstruktur, Einstiegspunkte zu Fachanwendungen, ein Erscheinungsbild, das nicht nach Wiki aussieht. Für die Akzeptanz ist dieser Punkt wichtiger, als Technikverantwortliche vermuten. Ein Portal, das aussieht wie das eigene Unternehmen, wird als eigenes Werkzeug angenommen; eines, das aussieht wie ein Entwicklerwerkzeug, wird als solches behandelt. Wie weit diese Anpassungen reichen, unterscheidet sich zwischen Data Center und Cloud – prüfen Sie das für Ihre Plattform.
Der dritte Block ist derjenige, für den Linchpin nichts tun muss, weil Confluence ihn mitbringt – und der in Auswahlprojekten am meisten unterschätzt wird. Sie erhalten ein vollwertiges Wiki: Bereiche mit eigenem Rechtekonzept, Seitenbäume, Versionierung mit Vergleichsfunktion, Kommentare an konkreten Textstellen, Vorlagen, Aufgaben, Verlinkung untereinander, Volltextsuche und einen großen Markt an Erweiterungen für Diagramme, Tabellen, Genehmigungen oder Formulare.
Für viele Organisationen ist genau das der ausschlaggebende Vorteil. Ein Intranet ohne Wissensmanagement führt dazu, dass Arbeitsanweisungen, Handbücher und Prozessbeschreibungen weiterhin in Dateiablagen oder Dokumentenmanagementsystemen liegen – und dass Beschäftigte zwischen Systemen wechseln müssen. Wenn Nachricht und Anweisung in derselben Plattform liegen, entfällt dieser Bruch. Die Meldung über eine geänderte Prüfvorschrift verlinkt direkt auf die aktuelle Version der Vorschrift, und diese Version ist nachweisbar aktuell.
Gleichzeitig ist die Confluence-Basis der Ort, an dem Intranet-Projekte scheitern können. Ein Wiki, in dem jede Person alles anlegen darf, wächst unkontrolliert; nach zwei Jahren existieren vier Versionen desselben Handbuchs, und die Suche liefert die falsche. Das ist kein Linchpin-Problem, sondern ein Governance-Problem – aber es tritt mit Linchpin auf, weil Sie mit dem Intranet ein Wiki einführen. Legen Sie deshalb von Anfang an fest, wer Bereiche anlegt, wer für Inhalte verantwortlich ist, in welchem Rhythmus Inhalte überprüft werden und was mit veralteten Seiten geschieht.
Vorab eine notwendige Einordnung: Der Nutzen von KI in einem Intranet liegt selten dort, wo Produktdemonstrationen ihn zeigen. Beeindruckend wirken Textgenerierung und Bildvorschläge; wirtschaftlich relevant sind Auffindbarkeit, Übersetzung und Zusammenfassung langer Dokumente. Prüfen Sie Angebote deshalb nicht danach, ob KI enthalten ist, sondern danach, welches konkrete Alltagsproblem damit kleiner wird.
Aus unseren Projekten sind vier Anwendungsfälle belastbar. Erstens die Suche: Ein Intranet mit einigen tausend Seiten wird ohne gute Suche zum Archiv. Verfahren, die Fragen in natürlicher Sprache beantworten und die Antwort mit Quellenangabe belegen, verändern die Nutzung spürbar – vorausgesetzt, sie greifen nur auf Inhalte zu, für die die fragende Person berechtigt ist. Zweitens Zusammenfassungen: Wer eine dreißigseitige Arbeitsanweisung in fünf Sätzen erfassen kann, liest sie überhaupt. Drittens Übersetzung: In mehrsprachigen Unternehmen ist maschinelle Übersetzung der Unterschied zwischen einer erreichten und einer nicht erreichten Belegschaft. Viertens Redaktionsunterstützung: Entwürfe, Überschriftenvorschläge, Kürzungen und Stilanpassungen sparen der Kommunikationsabteilung real Zeit.
Deutlich weniger überzeugend sind KI-Funktionen, die Inhalte selbstständig erzeugen und veröffentlichen. In einem Intranet ist Verbindlichkeit ein Kernwert: Was dort steht, gilt. Ein automatisch erzeugter Text, den niemand geprüft hat, untergräbt diesen Wert – und in Bereichen wie Arbeitssicherheit, Qualitätsmanagement oder Personalthemen ist das nicht nur unangenehm, sondern riskant. Halten Sie deshalb an einem einfachen Prinzip fest: „KI darf vorschlagen, Menschen veröffentlichen.“
Hier liegt der wichtigste Prüfpunkt dieses Kapitels. Die KI-Fähigkeiten der Atlassian-Plattform – Assistenzfunktionen in Confluence, unternehmensweite Suche über verbundene Systeme, Zusammenfassungen, Textwerkzeuge – wurden vom Plattformanbieter in erster Linie für die Cloud-Welt entwickelt. Für Data-Center-Installationen ist die Verfügbarkeit solcher Funktionen erfahrungsgemäß eingeschränkter, teilweise anders gelöst oder von zusätzlichen Voraussetzungen abhängig.
Damit entsteht eine Abwägung, die viele Organisationen unangenehm ehrlich finden, aber sauber treffen sollten: Der Data-Center-Weg bringt Datenhoheit, Standortkontrolle und Anpassbarkeit – und liegt bei plattformseitigen KI-Funktionen tendenziell hinten. Der Cloud-Weg bringt laufende KI-Weiterentwicklung – und verlagert Verarbeitung in eine Infrastruktur, die Sie nicht selbst betreiben. Beides ist vertretbar. Nicht vertretbar ist, beides gleichzeitig zu erwarten.
Für Ihre Beschaffung heißt das konkret: Fragen Sie getrennt nach den KI-Funktionen des Intranet-Herstellers und nach denen der Plattform. Lassen Sie sich für Ihre gewählte Plattform und Ausbaustufe bestätigen, welche Funktionen heute verfügbar sind, welche angekündigt sind und was zusätzlich lizenziert werden muss. Behandeln Sie Ankündigungen als Ankündigungen: Sie sind eine Perspektive, aber keine Grundlage für eine Anforderung, die Sie ab Tag eins brauchen.
Der größere und unspektakulärere Hebel liegt in klassischer Automatisierung, und hier profitiert Linchpin erheblich von der Plattform. Confluence bringt Regelwerke mit, die auf Ereignisse reagieren können – eine Seite wird erstellt, ein Feld geändert, ein Datum erreicht –, und über Schnittstellen lassen sich Fachsysteme anbinden. Daraus entstehen Abläufe, die im Intranet-Alltag spürbar Arbeit sparen.
Diese Automatisierungen sind unscheinbar und deshalb häufig nicht Teil der Auswahlentscheidung. In der Nutzungsbilanz nach einem Jahr sind sie oft der Grund, warum ein Intranet lebt oder eingeschlafen ist. Wir empfehlen, mindestens die Inhaltsüberprüfung und die Profildatenpflege von Anfang an zu automatisieren – alles andere kann nachwachsen.
Sobald KI-Funktionen Intranet-Inhalte verarbeiten, entsteht eine datenschutzrechtliche Frage, die vor der Aktivierung geklärt werden muss. Intranet-Inhalte enthalten regelmäßig personenbezogene Daten: Namen in Meldungen, Profildaten, Kommentare, Abwesenheiten, teilweise auch Angaben aus dem Personalbereich. Wenn diese Inhalte an einen KI-Dienst übergeben werden, ist zu klären, wer verarbeitet, wo verarbeitet wird, wie lange Daten vorgehalten werden und ob sie zum Training verwendet werden.
Vier Punkte gehören dazu in jedes Gespräch mit dem Anbieter. Erstens der Verarbeitungsort und die Frage nach Unterauftragsverarbeitern. Zweitens eine ausdrückliche Zusage, dass Ihre Inhalte nicht zum Training allgemeiner Modelle verwendet werden. Übernehmen Sie diese Aussage nicht aus einer Marketingseite, sondern lassen Sie sie in die Vertragsunterlagen aufnehmen. Drittens die Berechtigungslogik: Eine KI-Suche darf nur Inhalte einbeziehen, für die die fragende Person berechtigt ist – andernfalls entsteht über die Antwortfunktion ein Weg an der Rechtestruktur vorbei. Viertens die Abschaltbarkeit: Können Sie einzelne KI-Funktionen deaktivieren oder auf bestimmte Bereiche begrenzen, wenn Datenschutz oder Mitbestimmung das verlangen?
Die relevanten Anknüpfungspunkte gliedern sich in vier Gruppen: das Atlassian-Ökosystem, die Büro- und Kommunikationswelt von Microsoft und Google, Identitäts- und Verzeichnisdienste sowie Fachsysteme aus Personal, Instandhaltung, Warenwirtschaft und Reporting. Die konkrete Verfügbarkeit einzelner Anbindungen sollten Sie für Ihre Ausbaustufe, Ihre Version und Ihre Atlassian-Plattform beim Anbieter verifizieren.
Der naheliegendste und stärkste Integrationspunkt liegt im eigenen Haus. Wenn Ihre Entwicklung, Ihr Projektmanagement oder Ihr Servicedesk mit Jira arbeitet, lassen sich Vorgänge, Kennzahlen und Übersichten unmittelbar in Intranet-Seiten einbinden – ohne Zusatzprodukt, weil die Verbindung zwischen den Atlassian-Anwendungen zum Standardumfang gehört. Ein Bereich für die Instandhaltung kann offene Wartungsaufträge zeigen, ein Bereich für die IT den aktuellen Störungsstand, ein Bereich für Projekte den Fortschritt.
Ebenso wertvoll ist der Erweiterungsmarkt. Für Diagramme, strukturierte Tabellen, Genehmigungsläufe, Formulare, Umfragen, Organigramme oder Vorlagenverwaltung existieren etablierte Erweiterungen, von denen viele auch von deutschsprachigen Anbietern kommen. Sie kaufen mit Linchpin also nicht nur ein Intranet, sondern Zugang zu einem Ökosystem, in dem eine typische Zusatzanforderung meist bereits gelöst ist.
Diese Stärke hat eine Rückseite, die Sie einplanen sollten. Jede zusätzliche Erweiterung ist ein weiteres Produkt mit eigenem Lizenzvertrag, eigenem Aktualisierungsrhythmus und eigener Kompatibilitätsfrage bei Plattform-Upgrades. In gewachsenen Installationen sammeln sich über Jahre Erweiterungen an, und irgendwann blockiert eine davon ein notwendiges Upgrade. Führen Sie deshalb von Anfang an eine kurze Liste Ihrer Erweiterungen mit Zweck, Verantwortlichem und Notwendigkeit – und prüfen Sie diese Liste bei jedem Upgrade.
Die häufigste Frage in Projekten lautet: Wie verträgt sich ein Confluence-Intranet mit Microsoft 365, wenn Teams, Outlook und SharePoint ohnehin genutzt werden? Die ehrliche Antwort ist zweiteilig. Technisch gibt es brauchbare Verbindungen: Confluence-Inhalte lassen sich in Teams einbinden, Dokumente aus der Microsoft-Welt in Intranet-Seiten verlinken oder einbetten, Benachrichtigungen in Kanäle spielen und Kalenderdaten anzeigen. Für die Anmeldung sorgt in der Regel derselbe Identitätsdienst, sodass Beschäftigte keine zweiten Zugangsdaten benötigen.
Organisatorisch bleibt jedoch eine Abgrenzungsaufgabe, die kein Produkt für Sie löst. Wenn Dokumente in der Microsoft-Welt liegen und Wissen im Intranet, muss klar sein, was wohin gehört. Unsere Empfehlung aus vielen Projekten: Dateien mit Bearbeitungscharakter – Tabellen, Präsentationen, Entwürfe – bleiben in der Office-Ablage. Verbindliches, dauerhaft gültiges Wissen – Arbeitsanweisungen, Prozessbeschreibungen, Handbücher, Nachrichten – lebt im Intranet und verlinkt auf die Dateien. Wer diese Regel in zwei Sätzen aufschreibt und kommuniziert, verhindert die häufigste Ursache doppelter Ablagen.
Für Google Workspace gilt dasselbe Prinzip mit anderen Namen: Anmeldung über den Identitätsdienst, Einbettung von Dokumenten und Tabellen, Kalender- und Verzeichnisanbindung. Der Umfang der jeweiligen Verbindungen unterscheidet sich zwischen Atlassian-Plattformen und ist von Erweiterungen abhängig – prüfen Sie deshalb genau die Anbindungen, die Sie tatsächlich brauchen, statt sich auf allgemeine Kompatibilitätsaussagen zu verlassen.
Dies ist der Integrationspunkt, der am stärksten über den Erfolg der Personalisierung entscheidet – und der am häufigsten zu spät bearbeitet wird. Confluence lässt sich an gängige Verzeichnisdienste und Anmeldeverfahren anbinden, sodass Anmeldung, Gruppenzugehörigkeiten und Rechte aus einer zentralen Quelle kommen. Für die Zielgruppensteuerung ist entscheidend, dass nicht nur die Anmeldung, sondern auch die Profilmerkmale aus dieser Quelle stammen.
Klären Sie deshalb in der Einführung vier Fragen. Welches System ist die führende Quelle für Standort, Abteilung und Rolle – der Verzeichnisdienst oder das Personalsystem? Wie gelangen Änderungen dorthin und in welchem Rhythmus werden sie übertragen? Welche Merkmale pflegen Beschäftigte selbst, und welche dürfen sie ausdrücklich nicht ändern? Und wie werden Konten beim Austritt deaktiviert, damit keine verwaisten Zugänge zurückbleiben? Diese vier Antworten sind die Grundlage dafür, dass Personalisierung dauerhaft funktioniert statt nur am Eröffnungstag.
Über Schnittstellen lassen sich Inhalte aus Fachsystemen im Intranet darstellen: Kennzahlen aus dem Reporting, Abwesenheiten aus der Zeitwirtschaft, Speiseplan aus der Kantinenverwaltung, Störungsstände aus der Instandhaltung, Belegungspläne aus der Raumverwaltung. Technisch sind solche Anbindungen in der Regel über die Programmierschnittstelle, über Erweiterungen oder über eine Automatisierungsplattform lösbar.
Die Grenze liegt selten in der Technik, sondern in Aufwand und Pflege. Jede individuelle Anbindung ist ein kleines Softwareprojekt mit Lebenszyklus: Sie muss bei Änderungen im Quellsystem angepasst und bei Plattform-Upgrades geprüft werden. Wir empfehlen deshalb, mit maximal zwei Anbindungen zu starten – idealerweise mit denen, die den größten sichtbaren Nutzen für die Belegschaft haben – und weitere erst zu ergänzen, wenn das Intranet angenommen ist. Eine ungenutzte Kennzahlenanzeige ist teurer Ballast, ein funktionierender Speiseplan überraschend wirksam für die tägliche Nutzung.
Für die mobile Nutzung gilt eine eigene Prüffrage: Welche dieser Integrationen funktionieren auch in der App? Beschäftigte ohne Bürorechner sind häufig genau diejenigen, für die Schichtplan, Speiseplan oder Sicherheitsmeldung besonders relevant sind. Wenn die App diese Inhalte nicht darstellt, verpufft ein wesentlicher Teil des Nutzens. Lassen Sie sich das für Ihre Ausbaustufe konkret zeigen, statt es aus der Produktbeschreibung zu schließen.
Diese beiden Anbieter sind die naheliegendsten Vergleichspunkte im DACH-Raum, weil sie ebenfalls aus Deutschland kommen und dieselbe Motivation bedienen: interne Kommunikation, die alle erreicht. Ihr Ausgangspunkt ist allerdings ein anderer. Staffbase und Haiilo denken zuerst in Kommunikation und in Reichweite: Kampagnen, App-Erlebnis, Push-Nachrichten, Kanäle, Auswertung von Wahrnehmung. Sie sind gebaut für Organisationen mit großem gewerblichen Anteil, in denen die Belegschaft primär über das eigene Telefon erreicht wird – und sie sind in diesem Feld ausgereifter als eine Wiki-Erweiterung.
Linchpin denkt zuerst in Information und in Struktur: Wo steht das Wissen, wer ist zuständig, welche Version gilt, wie finde ich das wieder. Der Vorteil liegt dort, wo Kommunikation und Dokumentation dieselbe Aufgabe sind – etwa wenn eine Sicherheitsmeldung auf eine verbindliche Arbeitsanweisung verweisen soll, die versioniert und nachweisbar aktuell ist. Der Nachteil liegt in der Reichweitensteuerung: Wer aufwendige Kampagnen, ausgefeilte Wahrnehmungsauswertung und ein App-Erlebnis auf dem Niveau von Verbraucheranwendungen erwartet, ist bei den spezialisierten Kommunikationsplattformen besser aufgestellt.
Ein zweiter Unterschied betrifft das Betriebsmodell. Staffbase und Haiilo werden typischerweise als betreuter Dienst genutzt; ein Betrieb im eigenen Rechenzentrum ist in der Regel nicht vorgesehen. Wer Datenhoheit im engen Sinne braucht – eigene Infrastruktur, eigene Kontrolle über Standort und Zugriff –, findet diese Option bei Linchpin über Data Center. Staffbase und Haiilo ordnen wir in eigenen Artikeln ausführlich ein.
Dies ist der Vergleich, der in der Praxis am häufigsten entscheidet, weil Microsoft 365 in vielen mittelständischen Unternehmen ohnehin lizenziert ist. Das Argument liegt auf der Hand: Warum ein zusätzliches Produkt bezahlen, wenn SharePoint bereits im Paket ist? Es ist ein gutes Argument und verdient eine ehrliche Antwort.
SharePoint ist als Intranet-Grundlage leistungsfähig, tief in die Office-Welt integriert und für Beschäftigte in der Anmeldung unsichtbar, weil sie ohnehin angemeldet sind. Die Bausteine für Nachrichten, Seiten und Zielgruppen existieren, und mit Microsoft Viva kommen Funktionen für Wissen, Lernen und Kommunikation hinzu. Der Aufwand liegt jedoch nicht in der Lizenz, sondern in der Umsetzung: Ein gutes SharePoint-Intranet ist ein Projekt mit Konzeption, Informationsarchitektur, Gestaltung und Umsetzung – die Bausteine sind vorhanden, das Portal ist es nicht. Wer nur die Lizenz vergleicht und den Umsetzungsaufwand weglässt, vergleicht falsch.
Wo Linchpin sich unterscheidet: Personalisierung über Profilmerkmale ist Kernfunktion statt Konfigurationsaufgabe, Mehrsprachigkeit ist deutlich einfacher zu führen, das integrierte Wissensmanagement mit Versionierung und Seitenstruktur ist ausgeprägter als in einer dateizentrierten Ablage, und der Anbieter sitzt im deutschsprachigen Raum mit entsprechendem Vertrags- und Supportverhältnis. Wo SharePoint gewinnt: Integrationstiefe in die Office-Welt, keine zusätzliche Plattform, kein zusätzlicher Hersteller in der Abhängigkeitskette und in der Regel geringerer Betriebsaufwand. Diese Abwägung sollten Sie dokumentieren – sie ist die häufigste Frage der Geschäftsführung.
Der interessanteste Vergleich ist der unauffälligste: Brauchen Sie Linchpin überhaupt, wenn Sie Confluence haben? In manchen Organisationen lautet die Antwort Nein. Wenn Sie im Kern ein Wissensmanagement brauchen, wenn Ihre Belegschaft überwiegend am Rechner arbeitet, wenn Sie eine Sprache sprechen und wenn Nachrichten selten und ohne Zielgruppensteuerung erscheinen, dann reicht Confluence mit einer sorgfältig gebauten Startseite und ein paar kostengünstigen Erweiterungen.
Linchpin lohnt sich, wenn mindestens zwei der folgenden Punkte zutreffen: Sie haben mehrere Standorte, Gesellschaften oder Sprachen. Sie müssen Beschäftigte ohne Bürorechner erreichen. Sie haben eine Kommunikationsabteilung, die redaktionelle Prozesse mit Freigabe und Terminierung braucht. Sie wollen ein Portal, das nach Ihrem Unternehmen aussieht und nicht nach einem Wiki. Und Sie brauchen ein belastbares Personenverzeichnis, weil Ihre Organisation groß genug ist, dass Zuständigkeiten nicht mehr allen bekannt sind.
Gegen Linchpin spricht, wenn Sie Confluence nicht als strategische Plattform wollen, wenn Ihre Anforderung im Kern App-zentrierte Kampagnenkommunikation ist, wenn Sie keine zweite Herstellerabhängigkeit eingehen möchten oder wenn Ihre IT den Data-Center-Betrieb nicht dauerhaft leisten kann und die Cloud-Variante Ihre unverzichtbaren Funktionen nicht abdeckt. Auch diese Abwägung gehört dokumentiert – sie ist die beste Grundlage, die Entscheidung später gegenüber Geschäftsführung und Belegschaft zu erklären.
Das folgende Vorgehen hat sich in Mittelstandsprojekten bewährt. Es beginnt bewusst nicht mit der Technik, sondern mit der Frage, welche Aufgabe das Intranet lösen soll – denn ein Portal ohne klaren Auftrag ist nach sechs Monaten eine Nachrichtenseite, die niemand liest.
Die Wahl der Atlassian-Plattform ist die folgenreichste Einzelentscheidung des Projekts, und sie ist nachträglich nur mit erheblichem Aufwand zu korrigieren. Der Data-Center-Weg bringt Kontrolle über Standort, Datenzugriff, Anpassungen und Aktualisierungszeitpunkte. Er ist die richtige Wahl, wenn regulatorische Vorgaben oder Konzernvorgaben ihn erzwingen, wenn Sie ohnehin eigene Rechenzentren betreiben oder wenn Ihre Anforderungen an Erscheinungsbild und Anpassbarkeit über das hinausgehen, was die Cloud-Welt zulässt.
Der Preis dieses Weges ist Betriebsverantwortung, und zwar dauerhaft. Sie betreiben eine Java-Anwendung mit Datenbank, Suchindex und mehreren Erweiterungen, Sie planen Aktualisierungen, Sie prüfen die Kompatibilität aller Erweiterungen vor jedem Upgrade, und Sie halten Sicherheitsaktualisierungen zeitnah nach. Das ist eine anteilige Personalstelle, keine Nebentätigkeit – und ein Intranet, dessen Upgrade zwei Jahre liegen bleibt, wird zum Sicherheits- und Kompatibilitätsproblem. Wer diese Kapazität nicht sicherstellen kann, sollte den Betrieb an einen Dienstleister übergeben oder den Cloud-Weg wählen.
Der Cloud-Weg entlastet die IT genau um diese Aufgaben: keine Serverbeschaffung, keine Aktualisierungsplanung, keine Kompatibilitätsprüfung, definierte Verfügbarkeit. Er verlagert die Verarbeitung jedoch in eine Infrastruktur, die Sie nicht kontrollieren, und begrenzt Anpassungen stärker. Vergleichen Sie deshalb nicht Lizenzkosten mit Serverkosten, sondern die Gesamtaufwände einschließlich Personal, Bereitschaft, Aktualisierungsdisziplin und Ausfallrisiko – und lassen Sie sich für beide Wege bestätigen, welche Ihrer unverzichtbaren Funktionen verfügbar sind.
Im laufenden Betrieb entsteht eine Aufgabe, die es bei einer einzelnen Intranet-Plattform nicht gibt: die Abstimmung zweier Produktlebenszyklen. Atlassian veröffentlicht Confluence-Versionen, //SEIBERT/MEDIA veröffentlicht Linchpin-Versionen, und weitere Erweiterungen haben eigene Rhythmen. Ein Upgrade der Plattform setzt voraus, dass alle Erweiterungen die neue Version unterstützen – andernfalls warten Sie, oder Sie verzichten auf eine Erweiterung.
In der Praxis ist das beherrschbar, wenn Sie drei Regeln befolgen. Erstens: Führen Sie eine Liste aller Erweiterungen mit Zweck, Verantwortlichem und Notwendigkeit, und streichen Sie regelmäßig, was niemand mehr braucht. Zweitens: Betreiben Sie eine Testumgebung und spielen Sie Upgrades zuerst dort ein – bei einem Intranet, das die ganze Belegschaft nutzt, ist ein fehlgeschlagenes Upgrade unmittelbar sichtbar. Drittens: Planen Sie Upgrades als Termin, nicht als Gelegenheit. Ein festes Fenster pro Halbjahr ist wirksamer als der Vorsatz, bei Bedarf zu aktualisieren.
Zur Herstellerabhängigkeit gehört auch eine Frage, die selten gestellt wird und deshalb umso wichtiger ist: Was passiert mit Ihren Inhalten, wenn Sie Linchpin einmal ablösen? Weil Inhalte in Confluence liegen und nicht in einer geschlossenen Intranet-Datenbank, bleibt die Substanz erhalten – Seiten, Bereiche, Versionen. Verloren gehen Personalisierung, Erscheinungsbild, Navigationsstruktur und redaktionelle Metadaten. Das ist eine deutlich bessere Ausgangslage als bei vielen geschlossenen Plattformen und ein sachliches Argument für die Wiki-Basis. Lassen Sie sich dennoch bestätigen, in welcher Form Inhalte und Profildaten exportierbar sind.
Der technische Betrieb ist der einfachere Teil. Der schwierigere ist die Frage, wer das Intranet inhaltlich führt. Ein Portal ohne benannte Redaktion füllt sich in den ersten Wochen und schläft dann ein – das ist das häufigste Scheitern, das wir sehen, und es hat nichts mit dem Produkt zu tun.
Bewährt hat sich ein zweistufiges Modell. Eine kleine zentrale Redaktion – häufig in der Unternehmenskommunikation angesiedelt – verantwortet Nachrichten an alle, das Erscheinungsbild, die Navigation und die Qualitätsregeln. Dezentrale Verantwortliche in Bereichen und Standorten pflegen ihre Inhalte selbst und dürfen an ihre Zielgruppen kommunizieren. Diese zweite Gruppe ist entscheidend: Ein Intranet, das nur von der Kommunikationsabteilung gefüllt wird, bleibt eine Unternehmenszeitung.
Dazu gehören drei wiederkehrende Aufgaben, die einer benannten Rolle zugeordnet und in einen festen Rhythmus gebracht werden sollten. Erstens die Inhaltsüberprüfung: Welche Seiten sind veraltet, welche Verantwortlichkeit ist unklar geworden, welche Bereiche können archiviert werden? Zweitens die Profildatenprüfung: Sind Standort, Abteilung und Sprache noch verlässlich, funktioniert die Zielgruppensteuerung? Drittens die Nutzungsbeobachtung: Welche Inhalte werden gesucht und nicht gefunden, welche Bereiche werden nicht genutzt? Eine halbjährliche Prüfung mit dokumentiertem Ergebnis kostet wenige Stunden und ist gleichzeitig ein guter Nachweis, dass das Intranet nicht nur eingeführt, sondern geführt wird.
Dies ist das Szenario mit dem größten sichtbaren Nutzen und gleichzeitig dem größten Vorbereitungsaufwand. In einem typischen mittelständischen Produktionsbetrieb arbeitet nur ein Teil der Belegschaft am Rechner. Der Rest erfährt Unternehmensnachrichten über Aushänge im Pausenraum, über Vorgesetzte oder gar nicht. Sicherheitsrelevante Anweisungen werden unterschrieben und im Ordner abgelegt, aber niemand weiß, wie viele Menschen sie tatsächlich gelesen haben.
Ein Intranet mit App verändert diese Situation, allerdings nur, wenn drei Voraussetzungen geklärt sind. Erstens die Frage der Geräte: Nutzen Beschäftigte ihre privaten Telefone, und wenn ja, auf welcher Grundlage? Das ist keine technische, sondern eine arbeitsrechtliche und mitbestimmungsrelevante Frage, und sie gehört vor den Rollout. Zweitens die Frage der Konten: Beschäftigte ohne Firmenrechner haben häufig keine geschäftliche E-Mail-Adresse – klären Sie, wie Anmeldung und Kontoanlage für diese Gruppe funktionieren und was das lizenzseitig bedeutet. Drittens die Frage der Inhalte: Eine App, die nur Unternehmensnachrichten enthält, wird nach zwei Wochen nicht mehr geöffnet. Was diese Gruppe wirklich interessiert, ist der Schichtplan, die Urlaubsübersicht, der Speiseplan, die Ansprechperson in der Personalabteilung.
Unsere Empfehlung: Beginnen Sie nicht mit Kommunikation, sondern mit Nutzwert. Wenn die App den Speiseplan und die Kontaktdaten der Personalabteilung zeigt, wird sie geöffnet – und dann erreicht auch die Sicherheitsmeldung ihre Leserschaft. Diese Reihenfolge ist der Unterschied zwischen einem angenommenen und einem ignorierten Portal.
Das wirtschaftlich attraktivste Szenario betrifft Unternehmen, in denen Confluence schon läuft – häufig als Wiki der Entwicklung, der IT oder des Qualitätsmanagements, meist ohne Intranet-Anspruch. In dieser Konstellation ist die Ausgangslage außergewöhnlich gut: Lizenzen sind vorhanden, Betriebswissen existiert, Berechtigungsstrukturen sind eingerichtet, und ein Teil der Belegschaft arbeitet bereits mit dem Werkzeug.
Typischerweise entwickelt sich das Vorhaben aus einem konkreten Bedarf. Das Qualitätsmanagement möchte Arbeitsanweisungen versioniert ablegen und dabei nachweisen können, welche Version gilt. Die Personalabteilung sucht einen Ort für Formulare und Onboarding. Die Geschäftsführung will Nachrichten nicht mehr per Sammelmail versenden. Jede dieser Anforderungen könnte für sich ein eigenes Produkt bekommen – oder alle drei landen auf einer Plattform, die schon da ist.
Ein Hinweis aus der Praxis: Achten Sie in dieser Konstellation besonders auf die Bereichsstruktur und die Rechte. Ein Wiki, das als Entwicklerwerkzeug gewachsen ist, hat oft eine Struktur, die für ein unternehmensweites Intranet nicht taugt – offene Bereiche mit technischen Namen, historische Inhalte ohne Verantwortliche, uneinheitliche Berechtigungen. Bevor Sie das Intranet darüberlegen, lohnt eine Aufräumphase. Sie ist unbeliebt und zahlt sich unmittelbar aus, weil die Suchqualität davon abhängt.
Für Unternehmensgruppen mit Werken oder Vertriebsgesellschaften im Ausland ist Mehrsprachigkeit häufig das ausschlaggebende Merkmal. Die Alternative lautet in der Praxis meist: Kommunikation auf Englisch, die ein erheblicher Teil der gewerblichen Belegschaft nicht versteht, oder mehrere getrennte Portale, die niemand pflegen kann.
Ein personalisiertes Intranet löst das anders. Oberfläche und Navigation erscheinen in der Sprache der jeweiligen Person, Nachrichten können in mehreren Sprachfassungen geführt werden, und die Zielgruppensteuerung sorgt dafür, dass eine Meldung des Werks in Polen nicht in Deutschland erscheint und umgekehrt. Gleichzeitig bleibt eine gemeinsame Ebene für Nachrichten der Gruppenleitung, die alle erreichen sollen.
Zwei praktische Hinweise dazu. Erstens: Klären Sie früh, wer Übersetzungen verantwortet. Ein Übersetzungsworkflow im Produkt ersetzt keine Zuständigkeit – wenn niemand benannt ist, erscheinen Nachrichten nur in der Konzernsprache, und die Personalisierung läuft leer. Maschinelle Übersetzung kann hier viel leisten, sollte aber bei verbindlichen Inhalten wie Sicherheitsanweisungen geprüft werden. Zweitens: Achten Sie auf die rechtliche Struktur. Bei mehreren Gesellschaften sind Verantwortlichkeiten im Datenschutz sowie Mitbestimmungsgremien pro Gesellschaft zu berücksichtigen – ein gruppenweites Portal mit einheitlichen Profildaten braucht dafür eine saubere Grundlage.
Das vierte Szenario wird selten als Intranet-Anforderung formuliert und ist wirtschaftlich oft das gewichtigste. In vielen mittelständischen Betrieben liegt entscheidendes Wissen bei einzelnen langjährigen Beschäftigten: Wer die Anlage kennt, wer die Besonderheiten eines Kunden im Kopf hat, wer weiß, warum eine Konstruktion vor fünfzehn Jahren so und nicht anders gelöst wurde. Wenn diese Menschen in den Ruhestand gehen, geht das Wissen mit ihnen – und der Nachfolger lernt es neu, teuer und langsam.
Hier spielt die Confluence-Basis ihre eigentliche Stärke aus. Ein Intranet, das gleichzeitig ein Wiki ist, macht Wissenssicherung zu einer Nebentätigkeit statt zu einem Projekt: Der Instandhalter dokumentiert einen Fehlerfall dort, wo er ohnehin nachschaut, mit Bildern, Kommentaren und Verlinkung auf die Anlagendokumentation. Die Vertriebsmitarbeiterin hinterlegt Kundenbesonderheiten auf einer Seite, die ihr Nachfolger findet. Versionierung sorgt dafür, dass nachvollziehbar bleibt, wer was wann geändert hat.
Damit das funktioniert, braucht es allerdings zwei Dinge, die kein Produkt liefert: eine Kultur, in der Dokumentieren als Teil der Arbeit gilt und nicht als Zusatzaufgabe, und eine Führung, die das ernst nimmt. Wir empfehlen, Wissenssicherung explizit als Ziel der Intranet-Einführung zu benennen und mit wenigen, konkreten Bereichen zu beginnen – zum Beispiel dem Fehlerkatalog einer Anlage. Ein sichtbarer Erfolg an einer Stelle überzeugt mehr als jede Schulung zum Thema Wissensmanagement.
Zunächst zu den Kosten. Die Gesamtkosten setzen sich aus fünf Blöcken zusammen, von denen nur die ersten zwei auf einem Angebot stehen – und der teuerste Block steht dort nie.
Diesen Kosten steht ein Nutzen gegenüber, der sich benennen lässt: deutlich weniger Sammelmails und damit weniger Suchzeit, erreichbare Beschäftigte auch ohne Bürorechner, schnelleres Onboarding, nachweisbar aktuelle Arbeitsanweisungen, gesichertes Erfahrungswissen und ein Ort, an dem Zuständigkeiten auffindbar sind. Wir empfehlen, diese Nutzenerwartung vor der Einführung schriftlich zu fixieren – mit zwei oder drei einfachen Messpunkten –, damit nach zwölf Monaten überprüfbar ist, ob sie eingetreten ist.
Der Data-Center-Betrieb ist das stärkste Argument für Datenhoheit, das ein Intranet-Produkt bieten kann: Inhalte, Profildaten und Nutzungsdaten liegen in einer Infrastruktur, die Sie kontrollieren, an einem Standort, den Sie bestimmen. Für Organisationen mit strengen Vorgaben – im öffentlichen Umfeld, in regulierten Branchen, in Konzernstrukturen mit klaren Standortauflagen – ist das häufig der ausschlaggebende Punkt.
Gleichzeitig sollten Sie zwei Einschränkungen kennen. Erstens: Auch beim Eigenbetrieb bleibt der Plattformhersteller Ihr Lizenzgeber mit eigenen Bedingungen, und für Support- oder Diagnosefälle können Daten übermittelt werden – klären Sie, welche und unter welchen Voraussetzungen. Zweitens: Sobald Sie plattformseitige KI-Funktionen oder cloudbasierte Zusatzdienste nutzen, verlassen Daten Ihre Umgebung möglicherweise doch. Datenhoheit ist deshalb keine Eigenschaft, die Sie mit der Betriebsentscheidung ein für alle Mal erwerben, sondern eine Eigenschaft, die Sie bei jeder Funktionsaktivierung erneut prüfen.
Für die Cloud-Variante gilt die umgekehrte Logik. Sie gewinnen Entlastung und laufende Weiterentwicklung, und die Argumentation ist mit europäischer Datenregion und ordentlichen Vertragsunterlagen in der Regel führbar. Sie verlieren die unmittelbare Kontrolle über Standort und Zugriffswege und sollten sich mit Fragen zum Drittlandtransfer, zu Unterauftragsverarbeitern und zu behördlichen Zugriffsmöglichkeiten sorgfältig auseinandersetzen. Beide Wege sind vertretbar – dokumentieren Sie, welchen Sie gewählt haben und warum.
Bei einem personalisierten Intranet liegt die datenschutzrechtliche Hauptfrage nicht im Betriebsmodell, sondern in den Profildaten. Personalisierung funktioniert nur mit Merkmalen über Personen – und je feiner diese Merkmale sind, desto wirksamer die Zielgruppensteuerung und desto sensibler die Verarbeitung. Standort und Abteilung sind unkritisch, Rollen und Sprachen meist ebenso. Merkmale wie Schichtmodell, Qualifikationen, Fotos, private Interessen oder Angaben zur Erreichbarkeit verdienen eine bewusste Entscheidung.
Wir empfehlen eine einfache Systematik. Trennen Sie Merkmale in drei Klassen: solche, die aus dem Personalsystem stammen und für die Steuerung zwingend erforderlich sind; solche, die Beschäftigte freiwillig pflegen können; und solche, die Sie bewusst nicht erheben. Legen Sie für jede Klasse fest, wer sie sieht – nur Vorgesetzte, alle Beschäftigten, oder eine definierte Gruppe. Halten Sie das in einem kurzen Konzept fest und kommunizieren Sie es. Ein Intranet, in dem Beschäftigte nicht wissen, wer welche ihrer Daten sieht, wird nicht mit Profilen gepflegt – und ohne gepflegte Profile funktioniert die Personalisierung nicht.
Der zweite sensible Bereich sind Nutzungsdaten. Funktionen, die Aufrufe zählen, Lesebestätigungen erfassen oder Reaktionen auswerten, sind fachlich wertvoll und arbeitsrechtlich heikel, weil sie eine Verhaltens- und Leistungskontrolle ermöglichen können. Diese Funktionen gehören ausdrücklich auf die Agenda der Mitbestimmung, und zwar bevor sie aktiviert werden. Praktikabel ist meist eine Vereinbarung, die Auswertungen auf aggregierter Ebene erlaubt und personenbezogene Auswertungen ausschließt – mit Ausnahmen für klar begründete Fälle wie den Nachweis sicherheitsrelevanter Unterweisungen.
Fünf Punkte gehören in jede Einführung. Erstens die Auftragsverarbeitungsverträge für beide Hersteller und alle relevanten Erweiterungen, abgeschlossen und im Verarbeitungsverzeichnis dokumentiert – beim Data-Center-Betrieb entsprechend die eigene Verantwortlichkeit sauber beschrieben. Zweitens ein Berechtigungs- und Rollenkonzept: Wer legt Bereiche an, wer darf Nachrichten an alle senden, wer sieht welche Profildaten, wer verwaltet Konten? Drittens ein Profildatenkonzept mit Zweck, Pflichtfeldern, Freiwilligkeit und Sichtbarkeit je Merkmal. Viertens die Einbindung der Mitbestimmung: Personalisierung, Lesebestätigungen und Nutzungsauswertung berühren regelmäßig mitbestimmungspflichtige Tatbestände; eine frühzeitige Betriebsvereinbarung ist einfacher als eine nachträgliche Auseinandersetzung. Fünftens Regeln zu Aufbewahrung, Archivierung und Löschung, einschließlich der Frage, was mit Beiträgen und Profilen beim Ausscheiden einer Person geschieht.
Ein besonderer Blick gilt der Frage, welche Inhalte überhaupt ins Intranet gehören. Personalakten, Krankmeldungen, Leistungsbeurteilungen und vergleichbare Unterlagen gehören in die dafür vorgesehenen Systeme, nicht in ein Wiki mit breiten Leserechten. Weil die Confluence-Basis das Anlegen von Seiten so einfach macht, entsteht dieses Risiko in der Praxis regelmäßig – nicht durch böse Absicht, sondern durch Bequemlichkeit. Eine kurze, klare Aussage in der Nutzungsrichtlinie, welche Datenkategorien ausdrücklich nicht im Intranet abgelegt werden dürfen, ist eine der wirksamsten Maßnahmen überhaupt.
