Build vs. Buy vs. Open Source: die richtige Intranet-Plattform wählen

Das richtige Intranet kann die Zeit für die Suche nach Richtlinien verkürzen, Mitarbeitende mit Services verbinden und interne Kommunikation leichter umsetzbar machen. Die Wahl der Intranet-Plattform bestimmt aber auch, welche Kosten, Einschränkungen und Wartungsverantwortlichkeiten Ihr Unternehmen über Jahre tragen wird.

Eigenentwicklung, kommerzielle Produkte und Open-Source-Plattformen verteilen diese Verantwortlichkeiten jeweils unterschiedlich. Die Entscheidung lautet nicht einfach, ob Sie für Software oder für Entwickler bezahlen. Es geht darum, ob die Plattform zu Ihren wesentlichen Arbeitsabläufen passt, sich mit Ihren Systemen verbindet und im Betrieb sowie bei Änderungen bezahlbar bleibt.

Nutzen Sie dieses Raster, um Fünfjahreskosten, Integrationsfähigkeit, Kontrolle und Ausstiegsoptionen zu vergleichen, bevor Funktionslisten die Diskussion bestimmen.

In diesem Artikel:

Was wählen Sie tatsächlich, wenn Sie entwickeln, kaufen oder Open Source einsetzen?
Welche Rahmenbedingungen schließen eine Plattform ein oder aus?
Wann ist welcher Ansatz wirtschaftlich sinnvoll?
Wie viel Kontrolle erfordern Integrationen und Sicherheitsanforderungen?
Was kostet das Intranet über fünf Jahre?
Wo kann Lock-in entstehen, und wie testen Sie Ihre Ausstiegsoptionen?
Wo passen Drupal und Open Intranet hinein?
Wie machen Sie aus den Abwägungen eine belastbare Entscheidung?

Was wählen Sie tatsächlich, wenn Sie entwickeln, kaufen oder Open Source einsetzen?

Die hilfreichste Unterscheidung ist, wie viel vorhandene Funktionalität Sie übernehmen können und wie viel technische Verantwortung bei Ihnen verbleibt.

Eigenentwicklung bedeutet, ein Intranet rund um unternehmensspezifische Anforderungen zu entwickeln. Sie kontrollieren sein Verhalten, müssen aber laufende Entwicklung, Tests, Sicherheitsupdates und Dokumentation finanzieren. Eigenentwicklung heißt nicht, jede Komponente von Grund auf neu zu schreiben.

Kaufen bedeutet, ein bestehendes kommerzielles Intranet-Produkt innerhalb seiner unterstützten Konfigurations- und Erweiterungsgrenzen einzusetzen. Der Anbieter pflegt das Produkt, während Ihr Team weiterhin Aufgaben wie Content-Governance, Zugriffsentscheidungen, Konfiguration und Akzeptanzförderung verantwortet.

Open Source einsetzen bedeutet, eine bestehende Codebasis zu nutzen, die Sie gemäß ihrer Lizenz einsehen und anpassen können. Ihr Unternehmen kann sie intern pflegen, einen Dienstleister beauftragen oder beide Ansätze kombinieren.

Diese Kategorien überschneiden sich. Ein individuell entwickeltes Intranet kann auf Drupal basieren, und ein Open-Source-Intranet kann mit kostenpflichtiger Implementierung, Hosting und Support angeboten werden. Auch ein kommerzielles Produkt kann erheblichen Integrationsaufwand erfordern.

Trennen Sie drei Entscheidungen:

Die Ausgangsplattform: ein bestehendes Intranet-Produkt, eine Content-Plattform oder eine individuelle Anwendung.
Das Liefer- und Wartungsmodell: internes Personal, ein externer Dienstleister oder geteilte Verantwortung.
Das Hosting-Modell: vom Anbieter gehostete Software, Managed Hosting oder Infrastruktur, die Ihr Unternehmen selbst kontrolliert.

Wenn Sie diese Punkte getrennt bewerten, vermeiden Sie Annahmen wie „Open Source bedeutet Selbsthosting“ oder „Kaufen bedeutet keinen internen Aufwand“.

Welche Rahmenbedingungen schließen eine Plattform ein oder aus?

Beginnen Sie mit Geschäftszielen statt mit einem Funktionskatalog. Eine kurze Liste könnte so aussehen:

Mitarbeitende finden die aktuelle Richtlinie, ohne bei HR nachfragen zu müssen.
Es gibt einen zentralen Einstiegspunkt für häufig genutzte Mitarbeiterservices.
Auch Mitarbeitende ohne Schreibtischarbeitsplatz werden erreicht.
Das Veröffentlichen in Fachbereichen erfolgt nachvollziehbar und einheitlich.

Legen Sie fest, wie Sie diese Ziele messen. Die Auffindbarkeit von Richtlinien lässt sich über erfolgreich erledigte Aufgaben und die Suchdauer testen. Der Zugang zu Mitarbeiterservices lässt sich eher an erfolgreich abgeschlossenen Aufgaben als an Seitenaufrufen bewerten.

Identifizieren Sie anschließend die Rahmenbedingungen, die einen Kandidaten ausschließen können:

Rahmenbedingung	Vor der Shortlist zu klärende Frage
Starttermin	Können die wesentlichen Arbeitsabläufe in der verfügbaren Zeit live gehen?
Budget	Können Sie Implementierung und laufenden Betrieb finanzieren?
Betriebskapazität	Wer pflegt Integrationen, Zugriffsregeln und Software?
Identität und Zugriff	Erfüllt die Plattform die Anforderungen an Anmeldung, Provisionierung und Entzug von Zugriffen?
Datenresidenz	Können erforderliche Daten, Backups und Logs an genehmigten Standorten verbleiben?
Barrierefreiheit	Erfüllt die konfigurierte Mitarbeiter-Experience Ihren geforderten Standard?
Unternehmenssysteme	Können wesentliche Systeme die benötigten Daten zuverlässig austauschen?

Behandeln Sie Pflichtanforderungen als Ausschlusskriterien. Eine Plattform, die eine rechtliche oder sicherheitsrelevante Anforderung nicht erfüllt, sollte nicht gewinnen, nur weil sie beim visuellen Design gut abschneidet.

Unterscheiden Sie außerdem Standardbedarf von spezifischem Verhalten. News zu veröffentlichen ist üblich. Mitarbeiteranfragen über mehrere Altsysteme mit unterschiedlichen Berechtigungsregeln zu leiten, kann dagegen tiefergehende Entwicklung erfordern.

Lassen Sie diese Kriterien von IT, HR, interner Kommunikation, Informationssicherheit oder Rechtsabteilung sowie von Vertretern der Belegschaft prüfen. So wird verhindert, dass die Vorlieben einer Abteilung zur unternehmensweiten Vorgabe werden.

Wann ist welcher Ansatz wirtschaftlich sinnvoll?

Setzen Sie auf Eigenentwicklung, wenn spezifische Arbeitsabläufe die Entwicklungskosten rechtfertigen. Am stärksten ist dieses Argument, wenn das Standardverhalten eines Produkts teure Workarounds erzwingen würde und Ihr Unternehmen einen Product Owner, Entwicklungskapazität und laufende Wartung dauerhaft sicherstellen kann.

Setzen Sie auf ein kommerzielles Produkt, wenn dessen vorhandene Funktionalität den Bedürfnissen der Mitarbeitenden weitgehend entspricht. Das kann den anfänglichen Umsetzungsaufwand senken, insbesondere wenn unterstützte Konnektoren die wesentlichen Integrationen abdecken. Der Preis dafür ist, die Grenzen des Produkts und die Roadmap des Anbieters zu akzeptieren.

Setzen Sie auf Open Source, wenn Code-Zugriff, freie Hosting-Wahl und Erweiterungsfreiheit einen klaren geschäftlichen Nutzen haben. Open Source bietet eine anpassungsfähige Grundlage, doch diese Freiheit braucht einen ausdrücklichen Wartungsplan.

Dimension	Eigenentwicklung	Kommerzielles Intranet-Produkt	Open-Source-Plattform
Aufwand bis zum Start	Mehr Funktionalität muss konzipiert und getestet werden	Geringer, wenn Konfiguration und unterstützte Konnektoren ausreichen	Abhängig vom Ausgangspunkt und den benötigten Erweiterungen
Grenzen der Anpassung	Weit, begrenzt durch Entwicklungskapazität	Festgelegt durch Produkteinstellungen und Erweiterungsschnittstellen	Weit, innerhalb der Plattformarchitektur und der Lizenz
Integrationsmöglichkeiten	Umsetzbar, soweit Schnittstellen und Zugriffe es erlauben	Unterstützte Konnektoren und APIs, teils je nach Tarif eingeschränkt	Vorhandene Module und APIs plus individuelle Entwicklung
Betriebsverantwortung	Vor allem Ihr Unternehmen und seine Dienstleister	Anbieter verantwortet die Produktwartung; Kunde behält Konfiguration und Governance	Ihr Unternehmen und beauftragte Dienstleister teilen sich die Verantwortung
Wichtigste Kostentreiber	Entwicklung, Personal, Tests und laufende Änderungen	Abonnements, Implementierung, Konnektoren und Service-Level	Implementierung, Hosting, Support, Integrationen und Upgrades
Flexibilität beim Ausstieg	Abhängig von Eigentumsrechten, Dokumentation und Architektur	Abhängig von Exportmöglichkeiten und Vertragsbedingungen	Code-Zugriff hilft, aber Datenportabilität und Übergabe müssen trotzdem getestet werden

Nehmen Sie ein Unternehmen, das vor allem News, Richtlinien, ein Mitarbeiterverzeichnis und Links zu Mitarbeiterservices braucht. Wenn ein kommerzielles Produkt dessen Anforderungen an Identität und Barrierefreiheit mit wenig Anpassung erfüllt, kann der Kauf unnötige Entwicklung vermeiden.

Betrachten Sie nun ein Unternehmen, das mehrere Altsysteme über unternehmensspezifische Zugriffsregeln verbindet. Eine Drupal-basierte Implementierung oder ein anderer individueller Ansatz kann hier mehr Kontrolle über diese Interaktionen bieten.

Keines der beiden Szenarien macht eine Kategorie grundsätzlich günstiger. Der Kostenvorteil hängt davon ab, wie genau der Ausgangspunkt zu der Arbeit passt, die Mitarbeitende erledigen müssen.

Wie viel Kontrolle erfordern Integrationen und Sicherheitsanforderungen?

Kontrolle ist dort am wichtigsten, wo Einschränkungen der Plattform wiederkehrenden Aufwand, Risiken oder Abhängigkeiten erzeugen.

Unterscheiden Sie drei Ebenen von Änderungen:

Konfiguration: unterstützte Einstellungen, Inhaltsstrukturen, Berechtigungen und Layouts. In der Regel die am einfachsten zu pflegenden Änderungen.
Unterstützte Erweiterungen: Module, Plugins, APIs oder dokumentierte Erweiterungspunkte. Sie erfordern Kompatibilitätstests und klare Zuständigkeiten.
Änderungen am Kernverhalten: Anpassungen außerhalb der unterstützten Erweiterungsgrenzen. Sie können Upgrades erschweren und die Abhängigkeit von den ursprünglichen Entwicklern erhöhen.

Bevorzugen Sie bei Drupal Konfiguration und unterstützte Erweiterungsmechanismen gegenüber Änderungen am Core-Code. Code-Zugriff macht Anpassungen möglich; er macht nicht jede Anpassung wirtschaftlich.

Testen Sie Identität über die erfolgreiche Anmeldung hinaus. SSO allein beweist nicht, dass der gesamte Mitarbeiter-Lebenszyklus abgedeckt ist. Prüfen Sie Provisionierung, Gruppenänderungen, Zugriffe für externe Mitarbeitende und was passiert, wenn jemand das Unternehmen verlässt. Klären Sie, wie schnell Zugriffe enden müssen und wie aktive Sitzungen behandelt werden.

Fragen Sie bei HRIS, Microsoft 365, Google Workspace, Ticketing- und Dokumentensystemen:

Welche Datensätze und Aktionen müssen zwischen den Systemen übertragen werden?
Ist die Verbindung einseitig oder bidirektional?
Sind Konnektoren und API-Zugriff im angebotenen Tarif enthalten?
Welche Rate Limits, Synchronisationsverzögerungen oder Speichergrenzen gelten?
Wie werden Berechtigungen zwischen den Systemen abgebildet?
Wer repariert die Integration, wenn sich eine vorgelagerte API ändert?

Die Suche verdient besondere Aufmerksamkeit. Eine systemübergreifende Suche darf eingeschränkte Inhalte weder über Titel noch über Textauszüge oder zwischengespeicherte Ergebnisse preisgeben.

Fordern Sie für Sicherheit und Betrieb Nachweise zu folgenden Punkten an:

Hosting-Standorte und Umgang mit Backups und Logs.
Audit-Ereignisse, Aufbewahrungsoptionen und Zugriffskontrollen für Administratoren.
Verantwortung für das Patchen jeder Softwareschicht.
Incident Response, Wiederherstellung aus Backups und Recovery-Verfahren.
Performance bei erwarteter Nutzung, einschließlich Lastspitzen durch Mitarbeitende.

Bewerten Sie die tatsächliche Bereitstellung und den Vertrag, nicht nur die beworbenen Fähigkeiten der Plattform. Eine Sicherheitsfunktion hilft nur, wenn sie konfiguriert, überwacht und einer verantwortlichen Person zugeordnet ist.

Was kostet das Intranet über fünf Jahre?

Eine Fünfjahresbetrachtung macht wiederkehrende Verpflichtungen und wahrscheinliche Änderungskosten sichtbar.

Verwenden Sie ein gemeinsames Modell:

Gesamtbetriebskosten über fünf Jahre = Anfangskosten + laufende Kosten für die Jahre eins bis fünf + erwartete Änderungskosten + erwartete Ausstiegskosten.

Erstellen Sie jede Schätzung auf Basis desselben Umfangs und derselben Serviceerwartungen.

Kostenkategorie	Was dazugehört
Anfangskosten	Gegebenenfalls Erstlizenzen, Implementierung, Design, Integrationen, Migration, Sicherheitsprüfung und Unterstützung beim Start
Laufende Kosten	Abonnements, Hosting, Support, internes Personal, Wartung, Tests, Monitoring und reguläre Upgrades
Erwartete Änderungen	Wachstum der Belegschaft, neue Integrationen, zusätzliche Arbeitsabläufe, steigender Speicherbedarf und größere Upgrade-Arbeiten
Ausstiegskosten	Datenextraktion, Übergabe von Code und Infrastruktur, Migrationsunterstützung, Personal für die Übergangsphase und gegebenenfalls Kosten der Vertragskündigung

Die Unterscheidung zwischen regulärer Wartung und größeren Änderungen ist wichtig. Wenn reguläre Updates im Support enthalten sind, rechnen Sie sie nicht noch einmal als separate Entwicklung. Wenn ein Major-Upgrade gesondert finanziert werden muss, weisen Sie das ausdrücklich aus.

Ebenso kann ein Abonnement Hosting und Produktupdates umfassen, aber den Support für Konnektoren oder Konfigurationsänderungen ausschließen. Schlüsseln Sie das Angebot auf, bevor Sie es mit einem gemanagten Open-Source-Service vergleichen.

Interne Zeit gehört in jede Schätzung. Der Kauf von Software macht einen Product Owner, Content-Verantwortliche, Zugriffsverwaltung und die Steuerung von Integrationen nicht überflüssig. Auch Eigenentwicklung und Open Source können dauerhaft vorgehaltene Entwicklungskapazität erfordern.

Erstellen Sie auf Basis von Anbieterangeboten und internen Schätzungen zwei Szenarien:

Basisszenario: erwartete Mitarbeiterzahl, vereinbarter Startumfang, geplante Integrationen und normales Inhaltswachstum.
Szenario mit höheren Kosten: schnelleres Wachstum, zusätzliche Anbindungen, größerer Speicherbedarf, höhere Serviceanforderungen oder umfangreiche Upgrade-Arbeiten.

Dokumentieren Sie Annahmen zu Verlängerungspreisen, Währung, Vertragsbedingungen und Personalverfügbarkeit. Planen Sie einen Puffer ein, der an identifizierte Unsicherheiten gekoppelt ist, statt einen unbegründeten Pauschalbetrag.

Halten Sie den Nutzen neben den Kosten sichtbar. Vergleichen Sie zum Beispiel, ob jeder Kandidat die Schritte bis zum Auffinden einer freigegebenen Richtlinie reduzieren kann. Der niedrigste Fünfjahrespreis ist keine Einsparung, wenn Mitarbeitende weiterhin einen manuellen Umweg brauchen.

Wo kann Lock-in entstehen, und wie testen Sie Ihre Ausstiegsoptionen?

Lock-in bezeichnet die Kosten und die Schwierigkeit eines Richtungswechsels. Er kann bei jedem Ansatz auftreten.

Produkt-Lock-in: proprietäre Inhaltsstrukturen, eingeschränkte Exporte, begrenzte APIs oder produktspezifische Arbeitsabläufe.
Abhängigkeit vom Dienstleister: Nur der Implementierungspartner versteht die Anpassungen oder kann Änderungen ausrollen.
Abhängigkeit von der Infrastruktur: Hosting-spezifische Dienste oder fest codierte Annahmen erschweren einen Umzug.
Abhängigkeit von internen Spezialisten: Kritisches Wissen liegt bei einer einzelnen Person und ist nicht dokumentiert.

Open Source beseitigt einige Einschränkungen beim Code-Zugriff, aber nicht diese betrieblichen Abhängigkeiten.

Testen Sie die Portabilität vor der Vertragsunterzeichnung. Fordern Sie einen repräsentativen Export mit Inhalten, Dateien, Metadaten, Beziehungen und Berechtigungen an. Prüfen Sie, ob sich auch die Konfiguration exportieren oder so ausreichend dokumentieren lässt, dass sie rekonstruiert werden kann.

Prüfen Sie anschließend die Verwendbarkeit. Ein Export kann jede Seite enthalten und dennoch die Taxonomie, Verlinkungen oder Zugriffsregeln verlieren, die nötig sind, damit diese Seiten anderswo nützlich sind.

Sichern Sie sich bei individuellem Code vertragliche Rechte und Zugriff auf:

Quellcode-Repositories und relevante Lizenzinformationen.
Deployment-Anleitungen und Infrastrukturkonfiguration.
Technische Dokumentation und Integrationsspezifikationen.
Testressourcen und Betriebshandbücher.
Vom Kunden kontrollierte Konten, die für den Betrieb des Dienstes erforderlich sind.

Stellen Sie eine praktische Frage: Könnte ein anderes kompetentes Team dieses System betreiben und weiterentwickeln, ohne es neu aufzubauen?

Eine glaubwürdige Antwort sollte den voraussichtlichen Übergabeaufwand, bekannte Abhängigkeiten und alle Komponenten umfassen, die ersetzt werden müssten. „Ihre Daten gehören Ihnen“ reicht nicht aus.

Wo passen Drupal und Open Intranet hinein?

Drupal ist eine Open-Source-Grundlage für inhaltsgetriebene Anwendungen. Seine Content-Modellierung, Berechtigungen, Publishing-Workflows und Erweiterungsmechanismen können ein Intranet tragen, aber Drupal allein ist noch kein fertiges Mitarbeiterportal.

Eine Implementierung braucht weiterhin intranetspezifische Konfiguration, UX-Design, Integrationen, Content-Aufbereitung, Tests und Wartung. Der Aufwand hängt von der gewünschten Mitarbeiter-Experience ab.

Open Intranet ist ein Drupal-basiertes Intranet-System, entwickelt von Droptica. Es bietet einen vorhandenen Ausgangspunkt, statt dass ein Team mit Drupal allein beginnen muss.

Innerhalb des Open-Source-Wegs lautet die Entscheidung dann:

Mit einem bestehenden Intranet-System starten, wenn dessen vorhandene Funktionalität zu Ihren Anforderungen passt.
Eine stärker unternehmensspezifische Drupal-Implementierung aufbauen, wenn besondere Anforderungen zusätzliches Design und zusätzliche Entwicklung rechtfertigen.

Ein vorhandener Ausgangspunkt kann dort Aufwand sparen, wo er bereits zu Ihrem Bedarf passt. Prüfen Sie diese Passung, statt anzunehmen, dass jeder benötigte Arbeitsablauf und jeder Konnektor enthalten ist.

Bewerten Sie Open Intranet anhand derselben Tests wie jeden anderen Kandidaten:

Unterstützt es Ihre wesentlichen Aufgaben für Mitarbeitende?
Welche Integrationen sind verfügbar, und welche erfordern Entwicklung?
Wer verantwortet Hosting, Patches, Zugriffskontrollen und Incident Response?
Was kosten Betrieb und Änderungen über fünf Jahre?
Kann ein anderer Dienstleister die Implementierung und ihre Daten übernehmen?

Ein anderer Weg kann besser geeignet sein, wenn ein kommerzielles Produkt Ihre wesentlichen Anforderungen bereits mit weniger Implementierungsaufwand erfüllt. Ebenso ist Open Source keine nachhaltige Wahl, wenn Ihr Unternehmen keine interne oder vertraglich gesicherte Wartungskapazität aufbauen kann.

Wie machen Sie aus den Abwägungen eine belastbare Entscheidung?

Eine belastbare Entscheidung verknüpft die Fähigkeiten der Plattform mit den Geschäftsprioritäten und macht Unsicherheit sichtbar.

Wenden Sie zuerst die Pflichtkriterien an. Streichen Sie Kandidaten, die wesentliche Anforderungen an Sicherheit, Datenresidenz, Identität, Barrierefreiheit oder Integration nicht erfüllen. Lassen Sie nicht zu, dass optionale Funktionen ein nicht bestandenes Ausschlusskriterium ausgleichen.

Gewichten Sie dann die verbleibenden Kriterien. Vergleichen Sie Fünfjahreskosten, Aufwand bis zum Start, Integrationsfähigkeit, Kontrolle, Wartbarkeit und Ausstiegsfähigkeit. Legen Sie die Gewichtung nach Ihren Prioritäten fest, nicht nach einer universellen Vorlage.

Ein dringender Starttermin kann vorhandener Funktionalität mehr Gewicht verleihen. Eine komplexe Anwendungslandschaft kann die Kontrolle über Integrationen wichtiger machen. Ein kleines Betriebsteam priorisiert möglicherweise eine klare Managed-Service-Vereinbarung.

Validieren Sie drittens unsichere Annahmen. Nutzen Sie einen fokussierten Eignungsnachweis:

Spielen Sie einen repräsentativen Arbeitsablauf von Mitarbeitenden durch, einschließlich Berechtigungsprüfungen.
Testen Sie eine kritische Integration, einschließlich der Fehlerbehandlung.
Exportieren Sie Beispielinhalte und prüfen Sie, was erhalten bleibt.
Dokumentieren Sie die Verantwortung für Patches, Backups, Upgrades und Support-Eskalation.

Verwenden Sie eine einheitliche Bewertungsskala und dokumentieren Sie die Belege hinter jeder Bewertung. Ein vorgeführter Arbeitsablauf verdient mehr Vertrauen als ein Roadmap-Versprechen. Halten Sie Bewertungen und Konfidenzniveaus getrennt, damit Unsicherheit nicht in einer Gesamtsumme verschwindet.

Verfassen Sie zuletzt ein kurzes Entscheidungsprotokoll. Halten Sie darin den bevorzugten Ansatz, die Gründe für die Ablehnung der Alternativen, bewusst akzeptierte Kompromisse, die Annahmen zu den Fünfjahreskosten, namentlich benannte Betriebsverantwortliche und die Bedingungen fest, die eine erneute Prüfung auslösen würden.

Ein kommerzielles Produkt bleibt beispielsweise möglicherweise nur so lange vorzuziehen, wie sein Abonnement einen erforderlichen Konnektor enthält. Eine Open-Source-Implementierung kann davon abhängen, dass ein Managed-Support-Vertrag bestehen bleibt. Dokumentieren Sie diese Abhängigkeiten vor der Freigabe.

Die Regel ist einfach: Kaufen Sie bei starker vorhandener Passung, entwickeln Sie selbst bei begründeten besonderen Anforderungen, und setzen Sie Open Source ein, wenn Sie eine anpassungsfähige Grundlage mit einem klaren Plan für die Verantwortlichkeiten wollen.

Bereit zu starten?

Wenn Open Source auf Ihrer Shortlist steht, prüfen Sie Open Intranet anhand Ihrer wesentlichen Arbeitsabläufe, Integrationsanforderungen und Annahmen zu den Fünfjahreskosten.

Bringen Sie Ihre Pflichtkriterien und einen repräsentativen Ablauf aus Sicht der Mitarbeitenden zu einem Gespräch über die Plattformeignung mit dem Open Intranet Team mit. Ziel ist es herauszufinden, was heute passt, was zusätzlichen Aufwand erfordert und ob dieser Ansatz für Ihr Unternehmen sinnvoll ist.