Ein selbst gehostetes CMS für ein Redaktionsteam auswählen: den Redaktionsablauf testen
Vergleichen Sie selbst gehostete CMS-Optionen, indem Sie Ihren tatsächlichen Veröffentlichungsprozess mit ihnen durchspielen – vom ersten Entwurf und der Freigabe bis hin zu Korrekturen, Export und laufender Wartung.
Warum die Eignung für den Arbeitsablauf wichtiger ist als eine Funktionsliste
Ein CMS kann Funktionen auflisten, die passend klingen, und die tägliche Veröffentlichung trotzdem umständlich machen. Entscheidend ist nicht einfach, ob eine Plattform Entwürfe, Rollen oder Terminplanung bietet. Entscheidend ist, ob Ihr Team seine tatsächliche Arbeit klar erledigen kann, die richtigen Personen einbezogen werden und vermeidbare Umwege ausbleiben.
Behandeln Sie WordPress, Drupal, Ghost oder jeden anderen Kandidaten als etwas, das getestet werden muss – nicht als Ergebnis, das sich aus dem Namen oder der Funktionsliste ableiten lässt. Die vorliegenden Informationen belegen weder, welche Plattform sich am besten für ein Redaktionsteam eignet, noch welche Funktionen eine bestimmte aktuelle Version unterstützt. Prüfen Sie die Funktionen in der Version und Konfiguration, die Sie tatsächlich einsetzen würden.
- Bewerten Sie eine vollständige Aufgabe statt einer einzelnen Funktion.
- Verwenden Sie für jeden Kandidaten dieselben Testinhalte, Personen und Abnahmekriterien.
- Halten Sie neben erfolgreichen Ergebnissen auch Umwege, unklare Übergaben und erforderliche Konfigurationen fest.
Den Veröffentlichungsablauf einschließlich Ausnahmen abbilden
Bevor Sie eine Demo öffnen, halten Sie fest, wie ein typischer Beitrag Ihr Team durchläuft. Berücksichtigen Sie den normalen Ablauf und Situationen, die ihn unterbrechen. Eine einfache Übersicht kann mit einem Auftrag oder einer Idee beginnen, über Entwurf und Prüfung führen und anschließend Freigabe, Veröffentlichung und spätere Pflege abdecken. Passen Sie die Schritte an Ihren Prozess an, statt davon auszugehen, dass jedes Team dieselbe Reihenfolge einhält.
Bitten Sie jede Rolle zu beschreiben, was sie erhält, was sie ändert, worüber sie entscheidet und woran sie erkennt, dass die nächste Person tätig werden kann. Berücksichtigen Sie Ausnahmen, etwa wenn eine prüfende Person nicht verfügbar ist, nach der Veröffentlichung eine Korrektur eingeht, ein Beitrag auf einen späteren Termin verschoben werden muss oder ein Entwurf pausiert wird. Gerade solche Fälle eignen sich als Tests, weil eine reibungslose Demo sie möglicherweise nicht zeigt.
- Benennen Sie jede Phase, die zuständige Rolle, die Übergabe und das erwartete Ergebnis.
- Kennzeichnen Sie, welche Schritte verpflichtend sind und welche von Inhaltstyp oder Risiko abhängen.
- Listen Sie häufige Ausnahmen auf, darunter abgelehnte Entwürfe, dringende Korrekturen und geänderte Veröffentlichungstermine.
- Legen Sie vor dem Systemvergleich fest, woran eine erfolgreiche Übergabe zu erkennen ist.
Eine repräsentative Testauswahl zusammenstellen
Wählen Sie Testmaterial, das die Arbeit widerspiegelt, die Ihr CMS unterstützen muss. Ein einzelner kurzer Artikel reicht selten aus, um zu zeigen, wie das System mit unterschiedlichen Strukturen, Mitwirkenden oder Prüfanforderungen umgeht. Verwenden Sie Beispielinhalte statt sensibler Live-Inhalte, es sei denn, Ihre Organisation hat die Testumgebung dafür freigegeben.
Halten Sie die Testauswahl überschaubar, aber abwechslungsreich. Berücksichtigen Sie die Inhaltstypen, die Ihr Team veröffentlicht, die verwendeten Arten von Medien und Links sowie wiederkehrende Inhalte, die an mehreren Stellen erscheinen müssen. Richten Sie Testkonten ein, die tatsächlichen Zuständigkeiten entsprechen, etwa für Autorinnen und Autoren, Redaktion, Freigabe und Administration. Gehen Sie nicht davon aus, dass eine Rollenbezeichnung bedeutet, dass die Person nur die von Ihnen vorgesehenen Aktionen ausführen kann – prüfen Sie die Zugriffsrechte direkt.
- Wählen Sie einen Routinebeitrag, einen komplexen Beitrag und einen Beitrag, der korrigiert werden muss.
- Beziehen Sie Mitwirkende und Prüfende ein, die Ihre tatsächlichen Übergaben abbilden.
- Verwenden Sie, sofern relevant, Beispiele mit unterschiedlichen Prüfabläufen oder Veröffentlichungsterminen.
- Notieren Sie die erwarteten Ergebnisse vor dem Test, damit das Team die Kandidaten einheitlich vergleichen kann.
Entwurf, Prüfung, Freigabe und Vorschau testen
Führen Sie eine vollständige Übung vom Entwurf bis zur Entscheidung durch. Eine Person erstellt oder bearbeitet den Testbeitrag, eine andere prüft ihn und die zuständige Person entscheidet über die Veröffentlichung. Beobachten Sie, ob alle Beteiligten erkennen können, was als Nächstes erwartet wird und ob das Team in seinem tatsächlichen Arbeitsablauf zwischen einem Entwurf, einem zur Prüfung anstehenden Beitrag und einem freigegebenen Beitrag unterscheiden kann.
Testen Sie die Vorschau mit den Personen, die darauf angewiesen sind. Prüfen Sie, ob die Prüfenden den Inhalt in einer Darstellung beurteilen können, die für ihre Entscheidungen hilfreich ist, und ob das Team Änderungen nach der Prüfung leicht erkennen kann. Verifizieren Sie das Verhalten anhand der aktuellen Version und Konfiguration des jeweiligen Kandidaten. Leiten Sie Vorschau- oder Freigabefunktionen nicht allein aus einer Produktbeschreibung ab.
- Kann die schreibende Person erkennen, wer den Beitrag prüfen soll und was noch aussteht?
- Kann eine prüfende Person wie erwartet eine Entscheidung oder Rückmeldung abgeben?
- Kann das Team feststellen, ob die angeforderten Änderungen vorgenommen wurden?
- Unterstützt die Vorschau die Prüfaufgabe, einschließlich relevantem Layout und verknüpften Inhalten?
- Können Sie erklären, was geschieht, wenn eine prüfende Person einen Entwurf ablehnt, pausiert oder zurückgibt?
Überarbeitungen, Terminplanung, Korrekturen und Wiederverwendung testen
Der Veröffentlichungsablauf endet nicht mit der Freigabe. Testen Sie, wie das Team mit Änderungen im Laufe der Zeit umgeht: Überarbeiten Sie einen Beitrag, vergleichen Sie die geänderte Version mit der früheren und stellen Sie fest, welche Informationen dem Team helfen, die Änderungen nachzuvollziehen. Prüfen Sie die verfügbaren Funktionen direkt, statt anzunehmen, dass Versionsverlauf oder Vergleich auf eine bestimmte Weise funktionieren.
Wenn Ihr Team Veröffentlichungen terminiert, testen Sie das Festlegen, Ändern und Stornieren eines geplanten Veröffentlichungstermins. Prüfen Sie, wie die zuständigen Personen den vorgesehenen Zeitpunkt bestätigen können und was sie bei einer Terminänderung tun. Testen Sie bei Korrekturen den vollständigen Ablauf – vom Erkennen eines Problems bis zur Freigabe und Veröffentlichung der Korrektur. Ermitteln Sie bei wiederverwendeten Inhalten, wo die maßgebliche Quelle liegt, und prüfen Sie, wie Aktualisierungen an allen Stellen gehandhabt werden, an denen der Inhalt erscheint.
- Kann das Team frühere Änderungen so prüfen, dass der Korrekturprozess unterstützt wird?
- Kann die zuständige Person die geplante Veröffentlichung bei Bedarf überprüfen, ändern oder stornieren?
- Sind Korrekturen nach der Veröffentlichung klar zugewiesen, geprüft und bestätigt?
- Können Mitarbeitende bei wiederverwendeten Inhalten feststellen, wo diese erscheinen und wie Aktualisierungen verwaltet werden?
- Halten Sie manuelle Schritte, doppelt gepflegte Inhalte und unklare Zuständigkeiten fest.
Rollen und Übergaben mit den tatsächlichen Zuständigkeiten abgleichen
Gehen Sie von Zuständigkeiten aus, nicht von den Rollenbezeichnungen im CMS. Erstellen Sie eine kurze Zugriffsmatrix, aus der hervorgeht, wer Inhalte erstellen, bearbeiten, prüfen, freigeben, veröffentlichen und Einstellungen verwalten darf. Testen Sie anschließend jedes repräsentative Konto anhand dieser Matrix. Vergewissern Sie sich sowohl, dass alle ihre Arbeit erledigen können, als auch, dass niemand Aktionen ausführen kann, die laut Richtlinie einer anderen Person vorbehalten sind.
Berücksichtigen Sie vorübergehende und seltenere Situationen, etwa wenn ein Mitwirkender das Team verlässt, eine prüfende Person eine Kollegin oder einen Kollegen vertritt oder eine Administratorin oder ein Administrator bei einem blockierten Beitrag hilft. Legen Sie fest, wer Zugriffsrechte beantragt, genehmigt und entzieht. Ein Ablauf, der vom Konto oder informellen Wissen einer einzelnen Person abhängt, kann schwer aufrechtzuerhalten sein – selbst wenn der normale Weg funktioniert.
- Listen Sie zunächst die beruflichen Zuständigkeiten und erforderlichen Aktionen auf und ordnen Sie ihnen erst dann Systemrollen zu.
- Prüfen Sie Zugriffsrechte mit separaten Konten, statt sich auf die Administratoransicht zu verlassen.
- Prüfen Sie, ob Übergaben verständlich bleiben, wenn eine beteiligte Person nicht verfügbar ist.
- Dokumentieren Sie, wer Änderungen an Konten und Entscheidungen zum Arbeitsablauf verantwortet.
Migration, Export und langfristige Verfügungsgewalt über Inhalte beurteilen
Die Wahl eines CMS betrifft mehr als die erste Veröffentlichung. Klären Sie vor einer Entscheidung, was Ihr Team möglicherweise verschieben oder aufbewahren muss: Inhalte, Medien, Links, Strukturen, Metadaten und Aufzeichnungen redaktioneller Entscheidungen. Erkundigen Sie sich beim Anbieter oder in der Projektdokumentation nach den Exportmöglichkeiten und führen Sie anschließend einen kleinen Praxistest mit repräsentativem Material durch. Betrachten Sie weder eine Export-Schaltfläche noch eine allgemeine Aussage zur Portabilität als Beleg dafür, dass das Ergebnis Ihren Anforderungen entspricht.
Legen Sie fest, was ein erfolgreicher Ausstieg für Ihre Organisation bedeutet. Kann das Team die exportierten Daten prüfen? Bleiben die benötigten Informationen erhalten? Was würde manuelle Arbeit oder einen separaten Prozess erfordern? Die Antworten hängen von Ihren Inhalten und Aufbewahrungsanforderungen ab. Machen Sie diese deshalb ausdrücklich deutlich, statt anzunehmen, dass jedes CMS Migration auf dieselbe Weise handhabt.
- Listen Sie die Inhalte und zugehörigen Informationen auf, die aufbewahrt oder übertragen werden müssen.
- Testen Sie den Export mit mehreren Inhaltstypen und beziehen Sie, sofern relevant, zugehörige Medien ein.
- Lassen Sie das Ergebnis von den Personen prüfen, die für eine künftige Migration oder die Aufzeichnungen zuständig sind.
- Dokumentieren Sie, was nicht enthalten ist, was umgewandelt werden muss und wer diese Arbeit verantwortet.
Hosting und Wartung in die Entscheidung einbeziehen
Bei einem selbst gehosteten CMS muss die Organisation festlegen, wer für den begleitenden Dienst und nicht nur für die redaktionelle Nutzung verantwortlich ist. Klären Sie, wer Server und Anwendung verwaltet, wer Backups und Wiederherstellungsverfahren überprüft, wer den Zugriff kontrolliert und wer über die Wartung entscheidet. Eine Plattform, die der Redaktion zusagt, kann trotzdem ungeeignet sein, wenn die erforderliche betriebliche Verantwortung nicht übernommen werden kann.
Ein verwalteter Betrieb kann beeinflussen, wer Teile der Infrastruktur betreut. Die Verantwortung der Kundinnen und Kunden für Inhalte, Zugriffsentscheidungen, Governance und das Verständnis des Wiederherstellungsbedarfs entfällt dadurch jedoch nicht. Airbip bietet beispielsweise den verwalteten Betrieb von Kataloganwendungen als Docker-Workloads auf Airbip-Cloud-Servern an. Routing und TLS-Zertifikate werden dabei über Traefik und Let’s Encrypt automatisiert. Außerdem stellt Airbip DNS-Prüfungen, Verwaltung des Dienstlebenszyklus sowie konfigurierbare tägliche, wöchentliche und monatliche Backups bereit. Prüfen Sie die aktuelle Website von Airbip auf geltende Tarife und kommerzielle Bedingungen und klären Sie, wie Ihre eigenen Anforderungen an Daten, Zugriffsrechte und Wiederherstellung erfüllt werden.
- Weisen Sie den Aufgaben für Anwendung und Infrastruktur vor dem Start Verantwortliche zu.
- Erkundigen Sie sich nach der Konfiguration von Backups und wie Ihr Team eine Wiederherstellung überprüfen könnte.
- Legen Sie fest, wer Zugriffsrechte, Domains, die Inhaltsverwaltung und Entscheidungen im Störungsfall verantwortet.
- Wählen Sie ein Betriebsmodell, das zur betrieblichen Kapazität und zu den Kontrollanforderungen Ihres Teams passt.
Häufige Fragen
Wie sollte ein Redaktionsteam selbst gehostete CMS-Optionen vergleichen?
Bilden Sie den tatsächlichen Arbeitsablauf des Teams ab und führen Sie anschließend in jedem Kandidaten dieselben repräsentativen Aufgaben durch. Berücksichtigen Sie routinemäßige Veröffentlichungen und Ausnahmen wie zurückgegebene Entwürfe, geänderte Termine und Korrekturen nach der Veröffentlichung. Dokumentieren Sie Ergebnisse, Umwege, Konfigurationsbedarf und offene Fragen.
Sollte ein Team WordPress, Drupal oder Ghost für redaktionelle Abläufe wählen?
Die vorliegenden Informationen stützen weder eine Rangfolge der Plattformen noch die Behauptung, eine davon sei für ein bestimmtes Team am besten. Testen Sie jeden Kandidaten in der Version und Konfiguration, die Sie einsetzen würden, anhand Ihrer Inhaltstypen, Rollen, Prüfprozesse und betrieblichen Anforderungen.
Was sollten wir bei der Vorschau in einem CMS testen?
Prüfen Sie, ob die für die Kontrolle zuständigen Personen den Inhalt in einer hilfreichen Darstellung beurteilen können, einschließlich relevantem Layout und verknüpftem Material. Testen Sie Änderungen nach der Prüfung und vergewissern Sie sich, wie das Team erkennen kann, was zur Freigabe bereit ist.
Wie können wir den Inhaltsexport beurteilen, bevor wir uns für ein CMS entscheiden?
Listen Sie die Inhalte und zugehörigen Informationen auf, die Sie aufbewahren müssen, und führen Sie anschließend mit repräsentativem Material einen kleinen Export durch. Lassen Sie das Ergebnis von den für Migration oder Aufzeichnungen zuständigen Personen prüfen und dokumentieren Sie fehlende Angaben, erforderliche Umwandlungen und manuelle Arbeit.
Entbindet verwaltetes Hosting das Team von seiner Verantwortung für ein selbst gehostetes CMS?
Nein. Ein verwalteter Betrieb kann Teile der Infrastruktur abdecken, doch die Organisation muss weiterhin Entscheidungen über ihre Daten, Zugriffsrechte, Governance und Wiederherstellungsanforderungen treffen. Klären Sie die Zuständigkeiten, bevor Sie ein Betriebsmodell auswählen.
Quellen und weiterführende Literatur
- Docker documentation — Docker
- Traefik documentation — Traefik Labs
- Let’s Encrypt documentation — Internet Security Research Group