So wählen Sie eine selbst gehostete Projektmanagement-Anwendung aus: ein praxisnaher Bewertungsrahmen

Wählen Sie ein Arbeitsmodell, bevor Sie Produktfunktionslisten vergleichen

Um eine selbst gehostete Projektmanagement-Anwendung gut auszuwählen, beginnen Sie mit dem Betriebsmodell, das Ihr Team unterstützen muss. Eine lange Funktionscheckliste kann die zentrale Frage verdecken: Wie soll Arbeit vom Eingang einer Anfrage bis zum Abschluss dargestellt, gesteuert und überprüft werden?

Ein Team, das einen kontinuierlichen Strom kleiner Aufgaben koordiniert, kann beispielsweise ein klares Board, wiederverwendbare Ausgangsstrukturen und eine unkomplizierte Beteiligung priorisieren. Ein Produktteam benötigt möglicherweise eine Arbeitsbereichsstruktur rund um Projekte, Arbeitselemente, Zyklen und Module. Ein Team für gesteuerte Leistungserbringung benötigt möglicherweise stärkere Konfiguration auf Projektebene, rollenbasierte Abgrenzung und strukturierte Datensätze. Dies sind wesentlich unterschiedliche Anforderungen, selbst wenn jedes Team das Wort „Projekt“ verwendet.

Betrachten Sie Produkte wie Kan, OpenProject und Plane als Kandidaten, die Sie an Ihrem Modell testen, und nicht als austauschbare Namen auf einer Auswahlliste. Plane dokumentiert Arbeitsbereiche mit Projekten, Arbeitselementen, Zyklen, Modulen und Seiten. [OpenProject dokumentiert](https://www.openproject.org/docs/api/endpoints/projects/) Projekte als Container für Informationen, einschließlich Arbeitspaketen und Wikis; Rollen in Projektmitgliedschaften dienen dazu, Berechtigungen einzuschränken. Prüfen Sie bei einem boardorientierten Kandidaten wie Kan während des Piloten die von Ihrem Team benötigte Board-Struktur, Sichtbarkeitskontrollen, Aktivitätshistorie und wiederverwendbare Ausgangsstrukturen.

• Schreiben Sie eine Ein-Satz-Beschreibung des Arbeitssystems, das Sie auswählen: zum Beispiel „Kundenprojekte mit getrennten vertraulichen Projekten verwalten“ oder „Produktarbeit in Zyklen koordinieren“.
• Listen Sie die Objekte auf, die im System eigenständige Elemente sein müssen, statt in Tabellenkalkulationen oder informellen Konventionen gepflegt zu werden.
• Ermitteln Sie die nicht verhandelbaren Entscheidungen, die die Anwendung unterstützen muss: Priorisierung, Freigabe, Zuweisung, Statusberichterstattung, Kundenzugang oder Audit-Prüfung.
• Verwerfen Sie Anforderungen, die lediglich eine vertraute Oberfläche nachbilden, sofern sie nicht zu einem tatsächlichen betrieblichen Bedarf beitragen.

Definieren Sie die Arbeit, die Sie tatsächlich verwalten

Ein Auswahlprozess wird verlässlicher, wenn er die Art der Arbeit von der Abteilung trennt, die sie ausführt. Marketing-, Engineering- und Operations-Teams können jeweils wiederkehrende Arbeit, Kundenprojekte, Produktentwicklung oder formelle Initiativen verwalten. Die Anwendung muss das vorherrschende Muster einfach machen, ohne wichtige Ausnahmen unmöglich zu machen.

Beginnen Sie mit einer Schätzung der Verteilung. Sind die meisten Elemente wiederholbare operative Aufgaben? Handelt es sich um Kundenprojekte mit einem eigenen Projektbereich? Sind es Produktarbeitselemente, die sich durch Zyklen bewegen? Benötigen Sie eine Portfolioansicht über Initiativen hinweg? Oder sind Projekte gesteuerte Datensätze mit Kategorien, benutzerdefinierten Feldern und kontrollierter Beteiligung?

Ermitteln Sie anschließend die kostspieligen Fehler. Das Verpassen einer kundenbezogenen Frist, das Offenlegen eines vertraulichen Arbeitsbereichs, der Verlust von Anhängen oder die Unfähigkeit, ein historisches Projekt wiederherzustellen, kann weitaus wichtiger sein als die Frage, ob ein Board ein bevorzugtes visuelles Layout hat.

• Wiederkehrende Aufgaben: Testen Sie wiederholbare Ausgangsstrukturen, Wechsel der Verantwortlichkeit und die einfache Prüfung überfälliger Arbeit.
• Produktentwicklung: Testen Sie, ob Zyklen, Module, Arbeitselemente und Projektkontext zum Planungsvokabular des Teams passen.
• Kundenarbeit: Testen Sie Projekttrennung, kundensicheren Zugang und einen Übergabeprozess für abgeschlossene Arbeit.
• Portfolios: Testen Sie, wie Führungskräfte Statusinformationen bündeln, ohne dass Mitwirkende doppelte Berichtsdaten pflegen müssen.
• Gesteuerte Projekte: Testen Sie projektspezifische Typen, Kategorien, Felder, Rollen und die aufbewahrte Historie.

Ordnen Sie jeder Person, die Zugang benötigt, die passenden Rechte zu

Berechtigungen sind kein administratives Detail, das bis zum Rollout warten kann. Sie entscheiden darüber, ob die Anwendung die Menschen, die sie benötigen, sicher unterstützen kann. Erstellen Sie eine Zugriffsübersicht, bevor Sie Rollenbezeichnungen wie Admin, Mitglied, Gast oder Betrachter vergleichen; identische Bezeichnungen können sehr unterschiedliche effektive Zugriffe verbergen.

Beziehen Sie interne Mitwirkende, Projektmanager, Führungskräfte, Auftragnehmer, Kunden sowie Plattformadministratoren ein. Legen Sie für jede Gruppe fest, was sie sehen, erstellen, bearbeiten, exportieren und administrieren darf. Definieren Sie außerdem, wer Personen einladen, Rollen ändern, Projekte erstellen und Arbeitsbereiche oder Projekte löschen kann.

[OpenProject dokumentiert](https://www.openproject.org/docs/system-admin-guide/users-permissions/roles-permissions/) Berechtigungen, die über Rollen auf Anwendungs-, globaler und Projektebene zugewiesen werden. Die Projektrollen sind auf einzelne Projekte beschränkt, und eine Person kann in verschiedenen Projekten unterschiedliche Rollen haben. Dieses Modell ist prüfenswert, wenn dasselbe interne Team in verschiedenen Aufträgen unterschiedliche Zugriffsrechte benötigt.

[Plane dokumentiert](https://docs.plane.so/roles-and-permissions/overview) Bereiche auf Arbeitsbereichs-, Projekt- und Teamspace-Ebene. Laut Dokumentation wird der Zugriff vom spezifischsten Bereich aufwärts ausgewertet und standardmäßig verweigert, wenn keine passende Berechtigung vorliegt. Außerdem wird dokumentiert, dass Eigentümer und Administratoren des Arbeitsbereichs ohne explizite Mitgliedschaft auf alle Projekte und Projektinhalte zugreifen können. Dies ist im Hinblick auf Richtlinien für vertrauliche Projekte wichtig zu testen: Administrative Bequemlichkeit und strikte Trennung sind unterschiedliche Anforderungen.

• Erstellen Sie eine Zugriffsmatrix mit Personen oder Gruppen auf einer Achse und Aktionen auf der anderen.
• Nehmen Sie ein Szenario für ein vertrauliches Projekt mit einer internen Führungskraft, einem externen Auftragnehmer und einem Arbeitsbereichsadministrator auf.
• Testen Sie, ob sich der Zugriff einer Person korrekt ändert, wenn sie ein Projekt verlässt, aber in der Organisation bleibt.
• Entscheiden Sie, ob Plattformadministratoren alle Projektinhalte lesen dürfen sollen, und dokumentieren Sie diese Entscheidung als Governance-Richtlinie.
• Prüfen Sie Exportberechtigungen getrennt von Anzeigeberechtigungen, wenn der Export sensibler Datensätze ein Thema ist.

Bewerten Sie das Informationsmodell, nicht nur die Aufgabenansicht

Das Informationsmodell bestimmt, was im Zeitverlauf berichtet, integriert und aufbewahrt werden kann. Erstellen Sie während der Bewertung ein kurzes Datenlexikon: Projekt, Aufgabe oder Arbeitselement, Vorgang, Status, Verantwortliche, Termine, Abhängigkeiten, Dokumente, Zeitdatensätze, Kategorien, benutzerdefinierte Felder und Kennungen. Kennzeichnen Sie jedes Element als erforderlich, nützlich oder unnötig.

Ein System lässt sich leichter steuern, wenn wichtige Unterschiede konsistent dargestellt werden, statt in Titeln, Labels oder Kommentaren verborgen zu sein. Wenn jedes Team eine andere Lieferklassifizierung benötigt, ermitteln Sie, ob die Anwendung sie auf der passenden Ebene modellieren kann. Wenn ein Attribut in Berichten oder Exporten erscheinen muss, testen Sie es als gespeichertes Datum, statt anzunehmen, dass eine manuelle Konvention ausreicht.

[OpenProject dokumentiert](https://www.openproject.org/docs/user-guide/projects/project-settings/work-packages/) die projektbezogene Konfiguration von Arbeitspakettypen, Kategorien und benutzerdefinierten Feldern. Die Dokumentation behandelt benutzerdefinierte Felder über Arbeitspakete hinaus, einschließlich aufgewendeter Zeit, Projekten, Versionen, Benutzern, Gruppen, Zeiterfassungsaktivitäten und Arbeitspaketprioritäten. Diese Breite kann relevant sein, wenn die Organisation strukturierte Projektdatensätze benötigt; sie sollte jedoch mit den Feldern und Berichtsfragen getestet werden, die Ihr Team tatsächlich hat.

[Plane dokumentiert](https://docs.plane.so/core-concepts/workspaces/overview) einen Arbeitsbereich als obersten Bereich, der Projekte, Arbeitselemente, Zyklen, Module und Seiten enthält. Teams, deren Betriebssprache sich bereits um diese Objekte dreht, sollten testen, ob diese Struktur Umgehungslösungen reduziert. Testen Sie Kan dort, wo ein boardorientierter Ansatz zur verwalteten Arbeit passt, und verwenden Sie realistische Daten und Berichtsfragen statt nur eines Oberflächenvergleichs.

• Erstellen Sie fünf realistische Elemente mit den Feldern, Beschreibungen, Beziehungen und Anhängen, die Ihr Team heute nutzt.
• Versuchen Sie, eine monatliche Statusfrage ausschließlich mit den gespeicherten Daten der Kandidatenanwendung zu beantworten.
• Testen Sie ein Projekt, das eine Ausnahme von der Standardstruktur benötigt.
• Prüfen Sie, ob eine Kennung eindeutig bleibt, wenn Arbeit in E-Mails, Besprechungen und verknüpften Dokumenten besprochen wird.
• Übernehmen Sie keine Felder allein deshalb, weil eine Anwendung sie anbietet; unnötige Struktur senkt die Datenqualität.

Testen Sie die Workflow-Eignung mit realistischen Ausnahmen

Ein Workflow ist mehr als eine Reihe von Spalten. Er umfasst, wie Arbeit begonnen, klassifiziert, vorangebracht, überprüft, eskaliert, abgeschlossen und kommuniziert wird. Bewerten Sie, ob Teams konsistent arbeiten können, ohne gewöhnliche Arbeit in Verwaltung zu verwandeln.

Verwenden Sie ein praxisnahes Szenario statt einer allgemeinen Demonstration. Erstellen Sie zum Beispiel ein Projekt aus einer Vorlage oder wiederverwendbaren Ausgangsstruktur, nehmen Sie eine Änderungsanfrage entgegen, weisen Sie Arbeit einem internen Mitwirkenden und einem Auftragnehmer zu, führen Sie ein Element durch die Prüfung, benachrichtigen Sie den verantwortlichen Manager und bereiten Sie ein Statusupdate vor. Führen Sie dann eine Ausnahme ein: eine blockierte Abhängigkeit, ein wiedereröffnetes Element oder eine nicht rechtzeitig erteilte Freigabe.

Testen Sie bei einem boardorientierten Kandidaten, ob wiederverwendbare Ausgangsstrukturen und Aktivitätshistorie – falls erforderlich – ausreichend Konsistenz für die Arbeit schaffen, ohne einen Prozess aufzuerlegen, den das Team umgehen wird. Die entscheidende Frage ist nicht, ob ein Konzept in einer Funktionsliste erscheint, sondern ob es die Arbeit in den Händen der Personen, die es nutzen werden, zuverlässig unterstützt.

Definieren Sie Berichtsanforderungen frühzeitig. Ein Führungsdashboard, ein Kundenupdate und ein operatives Stand-up können unterschiedliche Ansichten derselben Daten erfordern. Fordern Sie von jedem Finalisten die Berichte oder Exportdaten, auf die Ihre Organisation tatsächlich angewiesen sein wird.

• Testen Sie Statuswerte anhand der tatsächlichen Entscheidungspunkte des Teams, nicht anhand einer allgemeinen Abfolge aus Zu erledigen, In Bearbeitung und Erledigt.
• Prüfen Sie, was geschieht, wenn Arbeit neu zugewiesen, blockiert, wiedereröffnet oder abgebrochen wird.
• Bestätigen Sie, wie Vorlagen, Benachrichtigungen und Freigaben projektübergreifend gesteuert würden.
• Lassen Sie Projektmanager während des Piloten eine wöchentliche Prüfung und Führungskräfte eine Statusprüfung durchführen.
• Dokumentieren Sie jede während des Tests erstellte Tabellenkalkulation oder jeden manuellen Bericht; dies kann auf ein fehlendes Informationsmodell oder eine fehlende Integration hindeuten.

Prüfen Sie Integrationen und Datengrenzen

Self-Hosting verändert, wo eine Anwendung läuft; es beseitigt nicht die Notwendigkeit, zu gestalten, wie Informationen in die Anwendung gelangen, sie verlassen und mit ihr verbunden sind. Erfassen Sie Identität, Kalender, E-Mail, Automatisierung, Dokumentverknüpfungen, Reporting und alle führenden Systeme, bevor Sie sich für eine Bereitstellung entscheiden.

Ermitteln Sie für jede Verbindung die übertragenen Daten, die Übertragungsrichtung, die verwendete Identität, das Verhalten bei Fehlern und den verantwortlichen Eigentümer. Das schützt vor einem häufigen Implementierungsproblem: Eine Anwendung wird wegen der Kontrolle ausgewählt, aber Routineintegrationen erzeugen an anderer Stelle unkontrollierte Kopien derselben Daten.

E-Mail verdient besondere Aufmerksamkeit, da sie sicherheitssensible und operative Nachrichten enthalten kann. Die [Self-Hosting-Dokumentation von Plane](https://developers.plane.so/self-hosting/overview) enthält eine SMTP-Konfiguration. Testen Sie im Rahmen des Piloten die Versanddomain, die vorgesehenen Empfänger und die Kontrollen für exportierte Informationen.

Wenn API-basierte Integration erforderlich ist, validieren Sie die unterstützte Authentifizierung und die für Ihren Anwendungsfall benötigten Endpunkte genau. [OpenProject dokumentiert](https://www.openproject.org/docs/api/introduction/) API v3 als OpenAPI-3.1-Spezifikation und führt Sitzungsauthentifizierung, API-Token und OAuth 2.0 auf. Dies ermöglicht eine konkretere Bewertung, als einfach anzunehmen, dass eine API jeden gewünschten Workflow abdeckt.

• Listen Sie jede erforderliche Systemverbindung auf und kennzeichnen Sie sie als zwingend, wünschenswert oder zukünftige Überlegung.
• Legen Sie für jede Integration das führende System fest und ob Daten kopiert oder nur verknüpft werden.
• Testen Sie Identitäts- und Offboarding-Abläufe mit einem Nicht-Produktivkonto.
• Überprüfen Sie den E-Mail-Versand, Benachrichtigungsempfänger und Zustellwege für Exporte.
• Prüfen Sie die API-Dokumentation auf die genauen Datenobjekte und den erforderlichen Authentifizierungsansatz, bevor Sie eine Automatisierung zusagen.

Überprüfen Sie die Portabilität vor der Einführung

Portabilität ist nicht einfach das Vorhandensein einer Exportschaltfläche. Ein nutzbarer Ausstiegs- oder Wiederherstellungsweg sollte strukturierte Datensätze, Anhänge, stabile Kennungen, Beziehungen, Konfigurationswissen und einen dokumentierten Prozess enthalten, um die Daten an anderer Stelle wiederherzustellen. Bewerten Sie dies, bevor Benutzer im Laufe der Jahre umfangreiche Arbeitshistorien ansammeln.

Exportieren Sie ein reales Pilotprojekt und prüfen Sie es außerhalb der Anwendung. Kontrollieren Sie Überschriften, Termine, Verantwortliche, Statuswerte, Beschreibungen, Beziehungen, benutzerdefinierte Felder, Anhänge und Kennungen. Stellen Sie fest, ob die exportierte Form den Kontext bewahrt, der für rechtliche, kundenbezogene oder operative Abrufe erforderlich ist.

[OpenProject dokumentiert](https://www.openproject.org/docs/user-guide/work-packages/exporting/) PDF-, XLS- und CSV-Exporte mehrerer Arbeitspakete sowie PDF- und Atom-Exporte einzelner Arbeitspakete. Die [XLS-Exportdokumentation](https://www.openproject.org/docs/user-guide/work-packages/exporting/xls-excel/) besagt, dass der Export ausgewählte Spalten, Beschreibungen und Beziehungen enthalten kann. Sie weist jedoch auch darauf hin, dass XLS-Ausgaben immer flach sind und die angezeigte Arbeitspakethierarchie nicht bewahren. Das ist nicht zwingend ein Grund für eine Ablehnung, aber genau die Art von Einschränkung, die entdeckt werden sollte, bevor ein Archivierungs- oder Migrationsplan von einer Hierarchie abhängt.

Die [Arbeitsbereichsdokumentation von Plane](https://docs.plane.so/core-concepts/workspaces/overview) warnt, dass das Löschen eines Arbeitsbereichs dessen Projekte, Arbeitselemente, Zyklen, Module und Seiten dauerhaft entfernt, und rät zum Export wichtiger Daten, da Plane keine automatischen Backups bereitstellt. Behandeln Sie Exporte und Backups als getrennte Kontrollen: Ein Export kann für Prüfung oder Migration nützlich sein, während Backup und Wiederherstellung die operative Wiederherstellung schützen.

• Exportieren Sie ein Pilotprojekt mit Hierarchie, Beziehungen, Anhängen und benutzerdefinierten Feldern.
• Bestätigen Sie, ob exportierte Kennungen mit Links, Dokumenten und externen Systemen abgeglichen werden können.
• Dokumentieren Sie, wer Exporte ausführen darf und wo exportierte Dateien gespeichert werden dürfen.
• Führen Sie eine Migrationsdokumentation mit Feldzuordnungen, Statuswerten, Benutzern, Anhängen und historischen Beziehungen.
• Führen Sie eine Wiederherstellungsübung getrennt von der Überprüfung eines Exports durch.

Ermitteln Sie Hosting- und Betriebsabhängigkeiten

Eine selbst gehostete Anwendung ist eine Betriebsverantwortung, auch wenn ein Anbieter Infrastrukturaufgaben übernimmt. Weisen Sie klare Verantwortlichkeiten für Domains, E-Mail, Zugriffsverwaltung, Datenaufbewahrung, Backup-Prüfung, Update-Entscheidungen, Incident Response und Offboarding zu. Die Frage ist nicht, ob Ihr Team die Anwendung einmal installieren kann, sondern ob diese Aufgaben nach dem Start konsequent erfüllt werden.

Die [Self-Hosting-Dokumentation von Plane](https://developers.plane.so/self-hosting/overview) behandelt Bereitstellungsansätze mit Docker und Kubernetes sowie Authentifizierung, SMTP, benutzerdefinierte Domains, SSL, externe Reverse-Proxys, Backup und Wiederherstellung, Protokolle und Zustandsprüfungen. Diese Bereiche bieten unabhängig vom Kandidatenprodukt eine nützliche Betriebscheckliste für jede Self-Hosting-Bewertung.

Der Umfang des Backups muss zur Datenarchitektur der Anwendung passen. Die [Backup- und Wiederherstellungsdokumentation von Plane](https://developers.plane.so/self-hosting/manage/backup-restore) fordert die Sicherung der PostgreSQL-Datenbank, des Objektspeichers mit Anhängen und hochgeladenen Dateien sowie der Umgebungskonfiguration, etwa Verbindungszeichenfolgen und Speicherzugangsdaten. Außerdem wird empfohlen, Backups getrennt von der Installation aufzubewahren, idealerweise extern oder in einer anderen Cloud-Region.

Dokumentieren Sie bei jeder Docker-basierten Bereitstellung die Speicherorte persistenter Daten, die Befehle, die Administratoren verwenden dürfen, sowie das Wiederherstellungsverfahren. Testen Sie den dokumentierten Backup- und Wiederherstellungsprozess der ausgewählten Anwendung in einer Nicht-Produktivumgebung, bevor Sie sich darauf verlassen. Schriftliche Betriebsverfahren sollten destruktive Aktionen und den erwarteten Wiederherstellungsweg ausdrücklich benennen.

Airbip kann die Infrastruktur rund um unterstützte selbst gehostete Anwendungen praktikabler machen: Anwendungsinstanzen laufen als Docker-Workloads auf Airbip-Cloud-Servern, wobei Routing und TLS-Zertifikate über Traefik und Let’s Encrypt automatisiert werden. Airbip bietet außerdem DNS-Prüfungen, Verwaltung des Service-Lebenszyklus und konfigurierbare tägliche, wöchentliche und monatliche Backups. Kunden können eine Airbip-Subdomain oder eine kompatible benutzerdefinierte Domain nutzen. Diese Funktionen können den Infrastrukturaufwand reduzieren, doch der Kunde muss weiterhin Zugriffsentscheidungen, Data Governance, Anwendungskonfiguration und die für sein Team geltenden Betriebsrichtlinien verantworten.

• Benennen Sie vor dem Start einen Anwendungsverantwortlichen, einen technischen Verantwortlichen und einen fachlichen Verantwortlichen.
• Dokumentieren Sie den Eigentümer der Domain und DNS-Verwaltung, den Verantwortlichen für ausgehende E-Mails und den Eskalationsweg bei Zugriffsproblemen.
• Definieren Sie Backup-Umfang, Anforderungen an die Aufbewahrung, Speicherort und den Turnus für Wiederherstellungstests.
• Bewahren Sie Konfigurationsgeheimnisse und Wiederherstellungsanweisungen unter angemessener Zugriffskontrolle auf.
• Erstellen Sie einen Update-Prüfprozess, der eine für Ihre Umgebung angemessene Test- oder Rollback-Entscheidung umfasst.
• Lesen Sie die aktuellen Airbip-Pläne und kommerziellen Bedingungen direkt auf der Airbip-Website, wenn Sie eine verwaltete Bereitstellung in Betracht ziehen.