Verlage verlieren selten am Mangel an Themenideen. Sie verlieren an Tempo und Wiederholbarkeit der Produktion: Ein Beitrag wartet auf die Freigabe, eine Grafikerin sucht die richtige Version eines Fotos, und ein Video muss für drei Plattformen von Hand neu kodiert werden. Sobald sich diese Reibungen häufen, reicht ein weiteres CMS-Plugin nicht mehr. Nötig ist ein Content-Produktionssystem, in dem Redaktions-CMS, Asset-Bibliothek (DAM) und Medienverarbeitung als eine Maschine laufen.
Aus unserer Erfahrung liegt das Schwierige nicht in der Werkzeugwahl, sondern darin, Redaktion, Assets und Medien zu einem vorhersehbaren Ablauf zu verbinden, der ein wachsendes Volumen aufnimmt, ohne für jeden Kanal Personal zu brauchen. Wir haben Anwendungen für die Medienbranche gebaut, kennen also die Besonderheiten von Inhalten, Metadaten und vielen Ausgabeformaten, und stellen das Team genau auf diese Arbeit zu.
Warum braucht die Medien-Content-Produktion heute ein eigenes System?
Der Grund ist banal: Umfang und Zahl der Kanäle sind den Prozessen entwachsen. Ein Beitrag endet selten als einzelner Artikel; er fächert sich auf Website, Newsletter, App, Social Media und Syndikationspartner auf, jeweils mit anderen Anforderungen an Format und Metadaten. Ohne System ruht all das auf Menschen und ihrem Gedächtnis: „finale” Versionen vermehren sich, Assets liegen doppelt auf verschiedenen Laufwerken, und die Kosten jeder Veröffentlichung steigen.
Ein Content-Produktionssystem macht aus dieser Arbeit einen wiederholbaren Prozess: eine einzige Quelle der Wahrheit, klare Arbeitszustände und automatische Varianten je Kanal. Hier geht es längst nicht mehr um den Komfort der Redaktion, sondern um die Stückkosten von Inhalten.
Was ist ein Redaktions-CMS, und wie gestalten Sie seinen Workflow?
Ein Redaktions-CMS ist mehr als ein Editor und eine Liste von Beiträgen. Es ist ein Werkzeug für Zusammenarbeit, in dem Inhalte definierte Rollen und Zustände durchlaufen, bevor sie das Publikum erreichen. Wir gestalten es entlang des realen Ablaufs der jeweiligen Redaktion, nicht entlang der Voreinstellungen der Engine.
In der Praxis modellieren wir mehrere Dinge gleichzeitig:
- Rollen und Berechtigungen (Autorin, Ressortleitung, Schlussredaktion, Publisher, Administration), damit jede Person genau das sieht, was sie sehen soll,
- Zustände und Übergänge (Entwurf, in Bearbeitung, zur Freigabe, geplant, veröffentlicht, zurückgezogen) mit den Bedingungen für den nächsten Schritt,
- Versionierung und Änderungshistorie, also die Möglichkeit zu vergleichen, wer was geändert hat, und zurückzurollen,
- Planung und Veröffentlichung, inklusive Sperrfristen, terminierter Beiträge und gleichzeitiger Publikation über mehrere Kanäle.
Ein guter Workflow verkürzt den Weg von der Idee zur Veröffentlichung und schützt dabei weiterhin die Qualität.
Wie bringt Digital Asset Management (DAM) Ordnung in die Assets einer Redaktion?
Text ist nur ein Teil des Inhalts. Fotos, Grafiken, Video, Podcasts und Quelldateien brauchen ihre eigene Ordnung, und genau die liefert Digital Asset Management (DAM). Eine zentrale Asset-Bibliothek erspart der Redaktion die Jagd nach Dateien über Laufwerke und Postfächer und gibt jedem Asset einen Ort, eine Historie und klare Nutzungsregeln.
Beim Bau der DAM-Schicht achten wir auf:
- eine Quelle der Wahrheit für Originale, aus denen wir Varianten erzeugen, statt Kopien zu vervielfachen,
- Suche über Metadaten und Inhalt (Urheber, Datum, Rechte, Tags, bei Bildern auch erkannte Objekte),
- Beziehungen zwischen Assets und Veröffentlichungen, also das Wissen, wo ein Element bereits verwendet wurde,
- Versions- und Statuskontrolle für Assets (in Arbeit, freigegeben, zurückgezogen), stimmig zum redaktionellen Ablauf.
DAM zahlt sich dort am stärksten aus, wo das Archiv groß und aktiv ist: Es macht aus einem Kostenblock ein Gut, das sich wirklich wiederverwenden lässt.
Wie bauen Sie eine Pipeline für Medien-Transcoding?
Video und Audio erreichen das Publikum nicht in dem Format, in dem sie entstanden sind. Sie müssen neu kodiert, normalisiert und für bestimmte Kanäle aufbereitet werden, und bei echtem Volumen geht das nicht von Hand. Deshalb richten wir eine automatische Transcoding-Pipeline ein, die startet, sobald eine neue Datei ins System kommt.
Die Pipeline nimmt das Ausgangsmaterial, kodiert es in mehrere Profile (verschiedene Auflösungen und Bitraten für Web, App und Social), erzeugt Untertitel und Vorschaubilder und legt die fertigen Varianten mit Metadaten im DAM ab. Wir legen sie so aus, dass sie mit der Last skaliert, nicht mit der Zahl der Bedienenden: mehr Dateien heißt mehr parallele Jobs, nicht mehr Überstunden.
Welche Metadaten und welche Taxonomie halten dieses System unter Kontrolle?
Metadaten sind das Nervensystem des ganzen Aufbaus. Ohne sie werden selbst das beste CMS und DAM zur gut aussehenden Rumpelkammer, deshalb entwerfen wir die Taxonomie vorab und nicht im Nachhinein.
Wir stimmen ein gemeinsames Metadatenmodell für Inhalte und Assets ab (Thema, Kategorie, Tags, Sprache, Rechte, Beziehungen), halten konsistente Vokabulare, damit „Sport” und „sport” nicht zwei Kategorien sind, und bereiten die Struktur für Suche und Empfehlungen vor. Wo es sinnvoll ist, unterstützen wir das Tagging halbautomatisch, schlagen Kategorien vor und erkennen Objekte auf Fotos, überlassen die Entscheidung aber der Redaktion. Die Taxonomie entscheidet darüber, ob das Archiv durchsuchbar bleibt und Inhalte sinnvoll verknüpft werden können.
Wie behalten Sie Rechte und Lizenzen an Inhalten im Griff?
In den Medien können die Rechte an einem Material mehr kosten als seine Produktion, und ein Fehler kostet echtes Geld und Reputation. Deshalb behandeln wir Rechte und Lizenzen als vollwertige Daten, verdrahtet in die Metadaten des Assets, statt sie in einer Tabelle daneben zu parken.
Das System erfasst, woher ein Asset stammt, zu welchen Bedingungen und wie lange es genutzt werden darf und in welchen Kanälen und Gebieten, und es meldet eine auslaufende Lizenz oder eine Nutzung außerhalb des erlaubten Rahmens. Diese Kontrolle bremst die Redaktion nicht, sie nimmt Risiko heraus, denn die Entscheidung „erlaubt oder nicht” ist in dem Moment sichtbar, in dem jemand ein Foto auswählt.
Headless oder Monolith: wie wählen Sie die CMS-Architektur?
Das ist eine der ersten Architekturfragen, und es gibt keine einzig richtige Antwort. Ein monolithisches CMS hält Inhalt und Darstellung zusammen, startet also schneller und ist für einen Hauptkanal leichter zu führen. Ein Headless-CMS trennt den Inhalt von der Präsentationsschicht und stellt ihn über eine API bereit, was sich auszahlt, wenn dasselbe Material viele Frontends speist: Website, App, TV, Sprachassistent, Partner.
Wir beraten bei der Wahl anhand der Zahl der Kanäle, des Änderungstempos und der Frage, wie unabhängig die Produktteams von der Redaktion sein sollen. Oft bauen wir Hybride: ein Headless-Kern liefert Inhalte über eine API, darüber liegt ein bequemes Redaktionswerkzeug. Entscheidend ist, dass die Architektur der Art folgt, wie Inhalte verteilt werden.
Welche Kompetenzen stellen wir für ein Content-Produktionsprojekt bereit?
Auch wenn wir genau diese CMS-Einführung für einen bestimmten Verlag nicht geliefert haben, stellen wir die Menschen, die solche Systeme bauen. Wir stellen das Team passend zum konkreten Umfang zusammen, nicht „auf Vorrat”, und besetzen meist:
- einen Solution Architect, der das Modell wählt (Headless oder Monolith) und Content-Fluss und Integrationen entwirft,
- Backend-Entwickler, die Content-API, Workflow, Metadatenverarbeitung und Berechtigungen bauen,
- Medien- und DevOps-Spezialisten, die Transcoding-Pipeline und Infrastruktur für Skalierung aufsetzen,
- Frontend-Engineers und Integratoren, die das CMS mit den Ausgabekanälen und den bestehenden Systemen des Verlags verbinden.
Ein solches Team fügt sich in das bestehende Ökosystem ein, statt einen Umbau rund um ein neues Werkzeug zu verlangen.
Wie machen wir das bei RITS?
Wir machen das als Nearshore-Partner aus Polen, der Kompetenzen genau dort ergänzt, wo sie Verlagen fehlen:
- wir stellen ein Team passend zum Umfang des Projekts zusammen (CMS, DAM, Transcoding) und prüfen die Kompetenzen vor dem Start,
- wir verbinden Redaktions-, Asset- und Medienschicht zu einem wartbaren Ganzen, statt lose Werkzeuge aneinanderzuheften,
- wir arbeiten in einer nahen Zeitzone, sodass unsere Engineers ohne lange Anlaufzeit an Code-Reviews und Terminen teilnehmen,
- wo es sinnvoll ist, ergänzen wir eine AI- und Datenschicht (Tagging, Suche, Empfehlungen), die die Redaktion unterstützt und nicht ersetzt.
Meist liefern wir das als Individualsoftware, gebaut von unserem Team, und dort, wo Kompetenzen schnell aufgestockt werden müssen, als Team-Verstärkung.
Womit fangen Sie beim Aufbau eines Content-Produktionssystems an?
Beginnen Sie beim schmerzhaftesten Engpass: Bleiben Beiträge in der Freigabe hängen, starten Sie mit dem CMS-Workflow; gehen Assets verloren, starten Sie mit dem DAM; blockiert Video die Veröffentlichung, starten Sie mit der Transcoding-Pipeline. Treffen Sie dazu eine Entscheidung zu Taxonomie und Rechten, denn sie bestimmen die Qualität des Ganzen, und bauen Sie den Rest in Etappen. Die Unterschiede zwischen den Kooperationsmodellen haben wir in unserem Artikel zu IT-Kooperationsmodellen beschrieben.
Sie bauen oder erneuern ein Content-Produktionssystem (CMS, DAM)? Sprechen wir darüber - wir stellen Team und Architektur passend zu Ihrer Redaktion zusammen.