SharePoint vs. Drupal für Ihr Intranet: ein ehrlicher Vergleich

Die Entscheidung SharePoint vs. Drupal fürs Intranet sollte bei den Aufgaben der Mitarbeitenden beginnen, nicht bei einer Funktionscheckliste. Finden die Beschäftigten die richtige Richtlinie, können sie gemeinsam an Dokumenten arbeiten und interne Services erreichen, ohne zwischen unverbundenen Tools zu wechseln? Was kostet es, diese Aufgaben möglich zu machen, und wer hält das Intranet langfristig am Laufen?

Die Nutzung von Microsoft 365 ist Teil dieser Diskussion, aber noch keine Entscheidung über das Intranet selbst. Vergleichen Sie, wie jede vorgeschlagene Umsetzung mit Ihren Inhalten, Mitarbeiter-Journeys, Integrationen und künftigen Änderungen umgeht. Weder vorhandene Lizenzen noch Gestaltungsfreiheit allein sollten die Frage entscheiden.

Dieser Vergleich betrachtet beide Wege, einschließlich Drupal-basierter Ausgangspunkte wie Open Intranet.

In diesem Artikel:

SharePoint vs. Drupal fürs Intranet: Was vergleichen Sie eigentlich?
Welche Plattform passt zu Ihrem Microsoft-365-Ökosystem?
Wie viel Freiheit brauchen Sie bei Design und Workflows?
Was kostet jedes Intranet über die Lizenzen hinaus?
Wer steuert Zugriff, Governance und Hosting?
Was sollten Sie in unterschiedlichen Arbeitsszenarien prüfen?
Wie lässt sich die Wahl vor einer Festlegung validieren?

SharePoint vs. Drupal fürs Intranet: Was vergleichen Sie eigentlich?

Verglichen wird hier SharePoint Online innerhalb von Microsoft 365 mit einem Drupal-basierten Intranet, einschließlich Open Intranet. SharePoint Server ist nicht Gegenstand des Vergleichs, da es ein anderes Bereitstellungs- und Betriebsmodell hat.

SharePoint Online ist ein von Microsoft verwalteter Dienst. Microsoft betreibt die zugrunde liegende Plattform, während Ihre Organisation Websites, Inhalte, Zugriffe und das Erlebnis der Mitarbeitenden konfiguriert.

Drupal ist ein Open-Source-Framework für Content-Management. Es gibt Ihrer Organisation die Kontrolle über Anwendung und Bereitstellung, doch jemand muss Hosting, Konfiguration, Updates und laufenden Support übernehmen.

Ein Drupal-basiertes Produkt kann den Ausgangspunkt verändern. Open Intranet, entwickelt von Droptica, bietet eine Grundlage für ein Intranetprojekt, statt dass jedes Element von Grund auf zusammengesetzt werden muss. Seine aktuellen Funktionen müssen dennoch mit Ihren Anforderungen abgeglichen werden.

Unsere Perspektive ist transparent: Droptica entwickelt Open Intranet auf Drupal. Der folgende Vergleich konzentriert sich auf Funktionen, Einschränkungen und Verantwortlichkeiten bei der Umsetzung und bewertet beide Ansätze anhand derselben Aufgaben der Mitarbeitenden.

Entscheidungsbereich	SharePoint Online	Drupal-basiertes Intranet
Passung zu Microsoft 365	Microsoft-Identität, Zusammenarbeit an Dokumenten und Integrationen mit verbundenen Diensten, abhängig von Konfiguration und Plänen	Anbindungen über Module, APIs und Umsetzungsaufwand
Erlebnis der Mitarbeitenden	Moderne Seiten, Navigation, Designs und Webparts innerhalb der Microsoft-Plattform	Kontrolle über Inhaltsmodelle, Seitenlayouts und Interaktionsdesign
Lizenzierung	Zugang über berechtigte Microsoft-365- oder SharePoint-Pläne; zusätzliche Funktionen können extra kosten	Keine Softwarelizenzgebühr für Drupal Core; Umsetzung und Betrieb müssen finanziert werden
Berechtigungen	Websites, Gruppen, Vererbung und Freigabesteuerung	Rollen und Berechtigungen, mit zusätzlicher Konfiguration oder Erweiterungen für granularen Inhaltszugriff
Hosting	Von Microsoft betriebene Infrastruktur im Rahmen der verfügbaren Serviceoptionen	Infrastruktur, die von der Organisation oder ihrem Dienstleister gewählt wird
Wartung	Microsoft wartet den Dienst; Kunden pflegen Konfiguration und Erweiterungen	Die Organisation oder der Dienstleister wartet Anwendung, Abhängigkeiten und Hosting
Ausgangspunkt	Für das Intranet konfigurierte Komponenten für Zusammenarbeit und Veröffentlichung	Drupal-Framework oder ein fertiger Ausgangspunkt wie Open Intranet

Die nützliche Frage lautet nicht: „Welche Plattform hat mehr Funktionen?“ Sondern: „Was braucht es, um unsere wichtigsten Aufgaben der Mitarbeitenden umzusetzen, und wofür sind wir danach verantwortlich?“

Welche Plattform passt zu Ihrem Microsoft-365-Ökosystem?

Wenn Ihre Mitarbeitenden Teams, Outlook und Office-Anwendungen nutzen, legen Sie fest, welche dieser Tätigkeiten das Intranet unterstützen muss. Ein gemeinsamer Herstellername beschreibt weder die vollständige Mitarbeiter-Journey noch den Aufwand, sie umzusetzen.

Betrachten Sie drei alltägliche Tätigkeiten:

Eine Richtlinie finden: SharePoint kann Richtlinien als Seiten veröffentlichen oder in Dokumentbibliotheken ablegen. Die Auffindbarkeit hängt dennoch von Metadaten, Navigation, Berechtigungen und der Suchkonfiguration ab.
Ein freigegebenes Dokument öffnen: SharePoint-Bibliotheken unterstützen die Zusammenarbeit an Office-Dokumenten, sofern die entsprechenden Anwendungszugänge und Lizenzen vorhanden sind.
Zwischen Intranet und Teams wechseln: SharePoint-Seiten und -Bibliotheken lassen sich über unterstützte Teams-Integrationen einbinden. Dadurch ist aber nicht automatisch jede Intranet-Aufgabe in Teams verfügbar.

Diese Funktionen gehören nicht alle zu SharePoint selbst. Teams liefert Oberflächen für die Zusammenarbeit, Microsoft Entra ID stellt Identitätsdienste bereit, und andere Microsoft-365-Dienste können Automatisierung, Analysen oder Compliance-Funktionen bieten. Die Verfügbarkeit hängt von Ihren Plänen und Ihrer Konfiguration ab.

Auch Drupal kann Microsoft Entra ID für die Anmeldung nutzen und sich mit Microsoft Graph, HR-Systemen, Ticketing-Tools und anderen Anwendungen verbinden. Diese Anbindungen müssen ausgewählt, konfiguriert und getestet werden. Manche erfordern individuelle Entwicklung.

Legen Sie fest, was „Integration“ bedeutet

Hinter einer Integrationsanforderung kann sich sehr unterschiedlicher Aufwand verbergen:

Integrationstiefe	Beispiel	Wichtigster Aspekt
Link	Eine Verknüpfung auf der Startseite öffnet das HR-System	Mitarbeitende verlassen das Intranet; das Anmeldeverhalten hängt vom Ziel ab
Einbettung	Eine Anwendungsansicht erscheint innerhalb einer Intranetseite	Die Quellanwendung muss Einbettung, Authentifizierung und Browser-Einschränkungen unterstützen
Lesen über eine API	Eine Seite zeigt freigegebene Informationen aus einem anderen System	API-Berechtigungen, Verfügbarkeit, Caching und Lizenzierung müssen geprüft werden
Daten synchronisieren	Mitarbeiterdatensätze werden in ein Intranet-Verzeichnis kopiert	Aktualisierungen, Löschungen, Datenschutz und widersprüchliche Datensätze brauchen klare Regeln

Single Sign-on gewährt nicht automatisch Zugriff auf verbundene Inhalte. Angemeldete Mitarbeitende sollten weiterhin nur die Datensätze und Dokumente sehen, für die sie berechtigt sind.

Fragen Sie bei jeder Anbindung, was das Angebot enthält und was noch konfiguriert oder entwickelt werden muss. Stellen Sie diese Frage für beide Plattformen, unabhängig davon, ob die Quelle Microsoft 365 oder ein anderes Geschäftssystem ist. Vorhandene Microsoft-Anwendungen können Teil des Arbeitsplatzes bleiben, ohne automatisch die Intranetplattform für die Mitarbeitenden festzulegen.

Wie viel Freiheit brauchen Sie bei Design und Workflows?

Gestaltungsfreiheit ist wichtig, wenn sie Aufgaben der Mitarbeitenden erleichtert. Weniger wichtig ist sie, wenn eine individuelle Oberfläche Kosten verursacht, ohne die Arbeitsweise zu verändern.

Moderne SharePoint-Seiten, Designs und Webparts sind die Bausteine, aus denen sich das Veröffentlichungserlebnis zusammensetzt. Erweiterungen über das SharePoint Framework können individuelles Verhalten ergänzen, bewegen sich aber innerhalb der Grenzen der Microsoft-Plattform.

Drupal bietet Kontrolle über Inhaltstypen, Beziehungen, Templates und das Verhalten der Anwendung. Bewerten Sie diese Kontrolle anhand der Anforderungen, die Sie unterstützen müssen, und des damit verbundenen Umsetzungs- und Wartungsaufwands.

Testen Sie konkrete Anforderungen statt visueller Vorlieben

Nehmen Sie drei typische Beispiele:

Eine rollenbasierte Startseite für Mitarbeitende: SharePoint bietet Zielgruppenadressierung für unterstützte Inhalte und Navigation. Drupal kann rollen- oder profilbasierte Erlebnisse über Konfiguration, Module oder eigenen Code bereitstellen. In beiden Fällen sind verlässliche Mitarbeiterattribute eine Voraussetzung.
Eine standortspezifische Richtlinienbibliothek: SharePoint kann Bibliotheken, Metadaten, Ansichten und die Suche nutzen. Drupal kann Richtlinien mit Standort, verantwortlicher Person, Gültigkeitsdatum und zugehörigen Services modellieren. Testen Sie, was passiert, wenn eine Richtlinie für mehrere Standorte gilt.
Ein gebrandetes Verzeichnis interner Services: Prüfen Sie, ob die Listen, Seiten und Webparts von SharePoint das geforderte Verhalten des Verzeichnisses abbilden. Prüfen Sie bei Drupal strukturierte Service-Datensätze, Beziehungen und Navigation. Ermitteln Sie in beiden Angeboten den Aufwand für Filterung und Anfragebearbeitung.

Klären Sie, welche vorhandenen Komponenten die Anforderung erfüllen und welche Interaktionen, Beziehungen oder Freigaberegeln zusätzlichen Aufwand erfordern. Beziehen Sie fertige Drupal-Produkte in diese Bewertung ein, statt anzunehmen, dass Drupal immer einen Start mit einem leeren Framework bedeutet.

Vergleichen Sie auch die Redaktionserfahrung

Bitten Sie Mitarbeitende aus interner Kommunikation und HR, in jeder vorgeschlagenen Umsetzung dieselben Aufgaben zu erledigen:

Eine News mit Bild und Veröffentlichungsdatum erstellen.
Eine Richtlinie aktualisieren, ohne versehentlich ihr Layout zu verändern.
Die Änderung zur Freigabe einreichen.
Die verantwortliche Person und das nächste Überprüfungsdatum ermitteln.
Veraltete Inhalte archivieren, ohne wichtige Links zu beschädigen.

SharePoint bietet Veröffentlichungssteuerung für Seiten und Bibliotheken; aufwendigere Freigabeprozesse können Power Automate oder andere Dienste einbeziehen. Drupal unterstützt strukturierte Inhalte und konfigurierbare Moderations-Workflows; das Team muss die gewünschte Redaktionserfahrung dennoch konfigurieren und testen.

Responsives Verhalten und Barrierefreiheit gehören in die Abnahmekriterien, nicht in Annahmen. Testen Sie in beiden Umsetzungen Tastaturnavigation, Screenreader-Verhalten, mobile Layouts und eingebettete Anwendungen.

Fragen Sie schließlich, was nach dem Launch geschieht. Umfangreiche Anpassungen bedeuten mehr Regressionstests, mehr Upgrade-Aufwand und eine größere Abhängigkeit von Spezialwissen, unabhängig von der Plattform.

Was kostet jedes Intranet über die Lizenzen hinaus?

Der richtige Vergleich betrifft die Kosten für Launch, Betrieb und spätere Änderungen des Intranets, nicht nur den Posten für Softwarelizenzen.

Der Zugang zu SharePoint ist in bestimmten Microsoft-365-Plänen enthalten und auch über passende eigenständige Pläne erhältlich. Der Einkauf sollte aktuelle Bedingungen, die Abdeckung der Mitarbeitenden und die benötigten Funktionen prüfen. Gehen Sie nicht davon aus, dass alle Frontline-Mitarbeitenden, externen Dienstleister oder externen Nutzer den nötigen Zugang haben.

Halten Sie fest, was bestehende Abonnements abdecken und was zusätzliche Kosten verursacht. Informationsarchitektur, Migration, Konfiguration, Schulung und Governance müssen trotzdem budgetiert werden.

Für Drupal Core fällt keine Softwarelizenzgebühr an. Hosting, Entwicklung, Updates, Sicherheitsüberwachung und Support brauchen dennoch ein Budget. Kommerzielle Erweiterungen oder verbundene Dienste können wiederkehrende Kosten verursachen.

Nutzen Sie für beide Plattformen dasselbe Kostenraster

Kostenkategorie	Was einzubeziehen ist
Discovery und Design	Nutzerforschung, Content-Audit, Navigation, Taxonomie, Barrierefreiheit und Prototypen
Umsetzung	Konfiguration, Seitenvorlagen, Inhaltsmodelle, Workflows und individuelle Komponenten
Integrationen	Identität, HR-Daten, Dokumentsysteme, APIs und Zugriffstests
Migration	Bereinigung, Mapping, Übertragung, Weiterleitungen und Validierung der Inhalte
Suche	Suchkonfiguration, Indexierung, Konnektoren und gegebenenfalls zusätzliche Suchinfrastruktur
Lizenzen und Add-ons	Erforderliche Abonnements, kostenpflichtige Erweiterungen, Premium-Konnektoren und zusätzlicher Speicher, sofern zutreffend
Hosting und Betrieb	Drupal-Infrastruktur oder zusätzlicher Servicebedarf, Monitoring, Backups und Wiederherstellungsregelungen
Akzeptanz	Schulung der Redaktion, Anleitungen für Mitarbeitende, Launch-Kommunikation und Pilot-Support
Laufender Support	Administration, Patches sofern zutreffend, Wartung von Erweiterungen, Incident-Bearbeitung und Weiterentwicklungen
Ausstieg	Exporte, Ersatz-Workflows, Anpassungen von Integrationen und Migration auf eine andere Plattform

Erstellen Sie ein Mehrjahresmodell mit derselben Zahl an Mitarbeitenden, denselben Funktionen, Supportstunden und Annahmen zum internen Personaleinsatz. Trennen Sie einmalige Kosten von laufenden Ausgaben.

Unterscheiden Sie bei SharePoint zwischen den bestehenden Microsoft-365-Ausgaben der Organisation und den neuen Kosten, die dem Intranet zuzurechnen sind. Klären Sie bei Drupal, ob Hosting und Support separat berechnet werden oder Teil eines Servicevertrags sind.

Kalkulieren Sie auch die wahrscheinlichen Änderungswünsche: ein weiteres Land, ein neues HR-System, eine zusätzliche Sprache oder eine Umstrukturierung von Abteilungen. Sie zeigen oft Kostenunterschiede, die eine reine Launch-Schätzung übersieht.

Auch Ausstiegskosten verdienen Aufmerksamkeit. Der Zugang zum Drupal-Quellcode kann die Portabilität unterstützen, doch eigene Module, Infrastrukturabhängigkeiten und undokumentierte Arbeiten können einen Wechsel dennoch teuer machen. SharePoint-Inhalte lassen sich möglicherweise exportieren, plattformspezifische Workflows und Erweiterungen müssen aber gegebenenfalls anderswo neu aufgebaut werden.

Wer steuert Zugriff, Governance und Hosting?

Eine Plattform ersetzt keine klaren Zuständigkeiten. Benennen Sie vor der Umsetzung einen Product Owner für das Intranet und Verantwortliche für Inhalte, und vereinbaren Sie, wer Zugriffsregeln, Änderungen an der Veröffentlichung und Aufbewahrungsentscheidungen freigibt.

IT, HR, interne Kommunikation, Rechtsabteilung und Vertreter der Fachbereiche sollten diese Entscheidungen gemeinsam treffen.

Trennen Sie Personalisierung von Schutz

Der Zugriff in SharePoint basiert üblicherweise auf Websites, Gruppen, Berechtigungsvererbung und Freigabesteuerung. Das Unterbrechen der Vererbung für einzelne Elemente ermöglicht Ausnahmen, doch zahlreiche Ausnahmen lassen sich nur schwer überprüfen.

Drupal bietet Rollen und Berechtigungen. Anforderungen wie abteilungsbeschränkte Inhalte, Zugriff auf Datensatzebene oder standortbezogene Einschränkungen können zusätzliche Module oder eigene Zugriffslogik erfordern.

Zielgruppenadressierung ist keine Zugriffskontrolle. Einen Link auszublenden oder eine Startseite zu personalisieren beweist nicht, dass die zugrunde liegende Seite oder Datei geschützt ist.

Testen Sie den Zugriff über direkte URLs, Suchergebnisse, APIs und Downloads, nicht nur über die Navigation. Beziehen Sie Nutzer ohne Zugriff, mit Teilzugriff und mit mehreren Rollen in der Organisation ein.

Definieren Sie den Lebenszyklus der Inhalte

Beide Wege brauchen klare Regeln dafür:

Wer für welchen Inhaltsbereich verantwortlich ist.
Welche Änderungen eine Freigabe erfordern.
Wann Inhalte überprüft werden müssen.
Was passiert, wenn eine verantwortliche Person das Unternehmen verlässt.
Wann Inhalte archiviert oder gelöscht werden.
Wie mit Datensätzen umgegangen wird, die Aufbewahrungspflichten unterliegen.

Manche Anforderungen lassen sich mit nativen Funktionen der Plattform abdecken. Andere erfordern Konfiguration, Automatisierung, Erweiterungen oder zusätzliche Dienste. Ein Feld für das Überprüfungsdatum schafft beispielsweise für sich genommen noch keinen Erinnerungs- und Eskalationsprozess.

Weisen Sie die operative Verantwortung zu

Bei SharePoint Online betreibt Microsoft den zugrunde liegenden Dienst. Ihre Organisation bleibt verantwortlich für Identitäten, Zugriffe, Freigabekonfiguration, Inhalte und selbst verwaltete Erweiterungen. Erwartungen an die Wiederherstellung und Aufbewahrungsregelungen müssen dennoch validiert werden.

Bei Drupal müssen die Organisation oder ihr Dienstleister Folgendes verantworten:

Hosting und Konfiguration der Umgebungen.
Updates von Drupal, Modulen und Abhängigkeiten.
Backups und getestete Wiederherstellung.
Monitoring und Reaktion auf Vorfälle.
Bewertung und Behebung von Schwachstellen.
Deployment und Regressionstests.

Halten Sie diese Verantwortlichkeiten im Vertrag oder in einer internen Betriebsvereinbarung fest. „Support inklusive“ reicht nicht ohne definierte Reaktionszeiten, Abdeckung und Eskalationswege.

Datenresidenz, Aufbewahrung, Audit-Trails und Compliance müssen anhand des tatsächlichen SharePoint-Serviceplans oder der Architektur des Drupal-Deployments bewertet werden. Beziehen Sie Backups, Logs, Analysen und verbundene Systeme in diese Prüfung ein.

Drupal bietet Kontrolle über Quellcode und Hosting. Das kann helfen, bestimmte Anforderungen zu erfüllen, doch Open Source macht ein Deployment nicht automatisch sicher oder compliant.

Was sollten Sie in unterschiedlichen Arbeitsszenarien prüfen?

Nutzen Sie Arbeitsszenarien, um festzustellen, was demonstriert werden muss, und nicht, um vor dem Testen einen Plattformsieger zu küren. Dieselbe Organisation kann mehrere der folgenden Situationen vereinen.

Die Mitarbeitenden arbeiten bereits in Microsoft 365

Listen Sie die Dokument- und Kollaborationsaufgaben auf, die mit Teams und den Office-Anwendungen verbunden bleiben müssen. Demonstrieren Sie diese Abläufe in jedem vorgeschlagenen Intranet, einschließlich Anmeldung, Zugriff auf geschützte Dokumente und Rückkehr zum Ausgangspunkt der Mitarbeitenden.

Anzufordernde Nachweise: Was enthalten ist, was konfiguriert werden muss, welche Erweiterungen oder Dienste beteiligt sind und welche Lizenzen erforderlich sind.

Vorhandene Microsoft-Tools sind Teil des Kontexts. Sie belegen für sich genommen nicht, dass das Intranet für die Mitarbeitenden Ihren Anforderungen entspricht.

Inhalte und Mitarbeiter-Journeys brauchen spezifische Strukturen

Vielleicht gilt eine Richtlinie für mehrere Standorte, ein Serviceverzeichnis verknüpft Datensätze aus verschiedenen Systemen, oder Mitarbeitende brauchen unterschiedliche Wege durch dieselben Informationen.

Anzufordernde Nachweise: Ein Prototyp der schwierigsten Anforderung auf jedem vorgeschlagenen Ausgangspunkt, einschließlich dessen, was die Redaktion für die Pflege tun muss.

Vergleichen Sie die Grenzen der vorhandenen Komponenten, die nötigen Änderungen und wie diese getestet und gewartet werden. Unterscheiden Sie zwischen der Konfiguration eines fertigen Produkts und Neuentwicklung.

Anforderungen an Hosting und Datenstandort sind verbindlich

Halten Sie die tatsächlichen Vorgaben schriftlich fest, bevor Sie Bereitstellungsoptionen vergleichen. Beziehen Sie Backups, Integrationen, Logs und Supportzugriffe ein, statt nur die Hauptanwendung zu prüfen.

Anzufordernde Nachweise: Eine dokumentierte Bewertung des geprüften SharePoint-Online-Dienstes oder Drupal-Deployments gegenüber jeder Anforderung, mit benannten operativen Verantwortlichkeiten.

Eine nicht erfüllte Pflichtanforderung ist eine Lücke, die geschlossen werden muss, keine Präferenz, die sich in einer Bewertungsmatrix wegmitteln lässt.

Portal und Dokumentenablage bleiben getrennt

Eine zu prüfende Architektur ist ein Drupal-basiertes Mitarbeiterportal, bei dem SharePoint für Dokumentenablage und Zusammenarbeit erhalten bleibt.

Anzufordernde Nachweise: Funktionierende Identitätszuordnung, Dokumentzugriff, Suchverhalten und Zuständigkeitsregeln über beide Systeme hinweg.

Berücksichtigen Sie den Aufwand für eine berechtigungsbewusste Suche und die Synchronisierung von Zugriffsänderungen. Vermeiden Sie es, Dokumente in beide Systeme zu kopieren, sofern es keine klare Anforderung dafür gibt; Mitarbeitende sollten wissen, wo die aktuelle Version liegt.

Das Angebot basiert auf Open Intranet

Bewerten Sie Open Intranet als bestehendes Drupal-basiertes Produkt, statt es als leeres Framework zu behandeln oder anzunehmen, dass jede Anforderung bereits enthalten ist.

Anzufordernde Nachweise: Welche benötigten Funktionen vorhanden sind, welche konfiguriert werden müssen und welche Entwicklung oder einen anderen Dienst erfordern.

Verwenden Sie dieselben Aufgaben, Zugriffstests und Kostenannahmen wie bei der Bewertung von SharePoint. So bleibt die Diskussion bei dem, was tatsächlich geliefert würde.

Wie lässt sich die Wahl vor einer Festlegung validieren?

Eine aufgabenbasierte Bewertung deckt Lücken früher auf als getrennte Anbieterpräsentationen.

Teilen Sie die Anforderungen zunächst in Pflichtbedingungen und Präferenzen ein. Eine nicht erfüllte Pflichtanforderung bei Zugriff, Hosting oder Barrierefreiheit sollte die Auswahl blockieren und nicht in einem Durchschnittswert verschwinden.

Einigen Sie sich dann auf Gewichtungen, bevor Sie die Plattformen bewerten:

Kriterium	Anzufordernde Nachweise
Passung zu Microsoft 365	Demonstrierte Aufgaben zu Identität, Dokumenten und Teams
Erledigung von Aufgaben der Mitarbeitenden	Pilotnutzer, die Informationen finden und Services erreichen
Anpassbarkeit	Ein Prototyp der schwierigsten geforderten Inhaltsstruktur oder Oberfläche
Berechtigungen	Positive und negative Zugriffstests mit realistischen Rollen
Hosting und Compliance	Eine dokumentierte Bewertung des Dienstes oder Deployments
Mehrjährige Kosten	Vergleichbare Annahmen, Ausschlüsse, Personaleinsatz und laufende Kosten
Betreibbarkeit	Benannte Verantwortlichkeiten, Supportbedingungen und ein Wartungskonzept

Geben Sie beiden Umsetzungsteams dasselbe Demonstrationsskript:

Freigegebene News veröffentlichen. Eine Redakteurin reicht einen Entwurf ein, eine freigebende Person prüft ihn, und Mitarbeitende sehen das veröffentlichte Ergebnis.
Eine geschützte Richtlinie abrufen. Berechtigte Mitarbeitende öffnen sie, während nicht berechtigte Mitarbeitende weder über Navigation noch über Suche oder einen direkten Link darauf zugreifen können.
Ein Dokument über verbundene Systeme hinweg finden. Die Person findet die aktuelle Version und öffnet sie mit den richtigen Berechtigungen.

Verwenden Sie realistische Konten statt Administratorzugängen. Beziehen Sie eine Frontline-Mitarbeiterin, einen regionalen Redakteur und einen Nutzer mit eingeschränktem Zugriff ein.

Fordern Sie für jede Aufgabe eine Aufschlüsselung, was:

In der vorgeschlagenen Plattform oder im Produkt enthalten ist.
Während der Umsetzung konfiguriert wird.
Individuell entwickelt wird.
Von einem anderen Dienst bereitgestellt wird.
Von einer zusätzlichen Lizenz abhängt.

Verlangen Sie benannte Verantwortliche für Support und Wartung, und halten Sie Annahmen fest, die noch validiert werden müssen. Messen Sie während eines Piloten Aufgabenerledigung, Sucherfolg und redaktionellen Aufwand, statt sich nur auf Seitenaufrufe zu stützen.

Schließen Sie mit einer Dokumentation der demonstrierten Ergebnisse, verbleibenden Lücken, mehrjährigen Kosten und operativen Verantwortlichkeiten ab. Beschreiben Sie auch, wie jedes Angebot mit wahrscheinlichen künftigen Änderungen umgeht. Das ist eine solidere Entscheidungsgrundlage als die Annahme, ein bestehendes Abonnement kläre die Frage oder mehr Anpassung sei automatisch von Vorteil.

Bereit für den Start?

Wenn Drupal auf Ihrer Shortlist steht, bewerten Sie Open Intranet anhand derselben Aufgaben der Mitarbeitenden, Zugriffstests und Kostenannahmen, die Sie für SharePoint verwenden.

Fordern Sie eine Open-Intranet-Präsentation an, die sich auf Ihre Anforderungen konzentriert. Bringen Sie Ihre wichtigsten Aufgaben und schwierigsten Vorgaben mit, und bitten Sie das Team, vorhandene Funktionen klar von Konfiguration und Entwicklung zu unterscheiden, die noch abgeschätzt werden müssten.