Component-Content-Management-System oder Redaktionssystem auswählen. So gehen Sie vor

Ein Content-Component-Management-System (CCMS) oder Redaktionssystem verwaltet die modularen Inhalte der Technischen Dokumentation in einer Datenbank. Für die Inhalte wird in der Regel das XML-Format verwendet.

Das CCMS oder Redaktionssystem verwaltet Inhalte, Layout und Metadaten getrennt. Dadurch ist es möglich, Inhalte für verschiedene Publikationen wiederzuverwenden sowie verschiedene Dokumentationsvarianten aus derselben Quelle zu erzeugen.

Ein CCMS bietet unter anderem Funktionen für Workflows, inklusive Rollen- und Rechteverwaltung, Sprachen- und Übersetzungsmanagement, Terminologiekontrolle, Variantenmanagement sowie Versionierung.

In diesem Artikel diskutieren wir, wann und warum Sie ein CCMS benötigen, was Sie bei der Auswahl eines CCMS beachten sollten und mit welchen CCMS/Redaktionssystemen wir bereits gearbeitet haben.

Inhaltsverzeichnis

• Wann lohnt sich ein CCMS/Redaktionssystem?
• Ansätze für die Auswahl eines CCMS/Redaktionssystems
• Anforderungen an ein CCMS/Redaktionssystem
  
  - User Stories in Funktionsbereichen
  - INVEST-Kriterien für User Stories
  - User Stories priorisieren
• Passende Redaktionssysteme auswählen
  
  - Von der Longlist zur Shortlist: CCMS-Anforderungskatalog
  - Spannungsfeld Zeit, Budget und Funktionsumfang
• Die Wichtigkeit von Sandboxes, PoCs und Content-Prototypen
• Einführung des Produktivsystems
• Marktübersicht: Welche CCMS/Redaktionssysteme gibt es?
• Wir unterstützen Sie bei der Einführung eines CCMS oder Redaktionssystems

Wann lohnt sich ein CCMS/Redaktionssystem?

Ob ein CCMS bzw. Redaktionssystem benötigt wird, hängt ab von der Größe und Komplexität der Technischen Dokumentation, der Größe und Zusammensetzung der Redaktionsabteilung, den Anforderungen an die Übersetzung und den Arbeitsprozessen im Unternehmen.

Folgende Faktoren sprechen für den Einsatz eines Redaktionssystems:

• Ihre Technische Dokumentation wird in mehreren Versionen und Varianten ausgeliefert, für die Inhalte wiederverwendet werden sollen.
• Ihr Unternehmen liefert Produkte und die dazugehörige Dokumentation in mehreren Sprachen aus. Die Übersetzungsprozesse müssen strukturiert gesteuert werden.
• Sie verwenden viele Abbildungen in jeweils mehreren Varianten und Ausgabeformaten, die medienspezifisch ausgespielt werden sollen.
• Sie liefern Informationsprodukte in unterschiedlichen Formaten aus und möchten die Publikation automatisieren.
• Sie wollen Daten aus externen Systemen in die Technische Dokumentation integrieren, z.B. Produktdaten aus einem Product Information Management System (PIM).
• Ihre Autor:innen und Reviewer arbeiten in verschiedenen Regionen und Zeitzonen und arbeiten kollaborativ an der Dokumentation. Sie möchten die Arbeitsprozesse wie z.B. fachliche Prüfung und Freigabe genau steuern und dokumentieren.

Erfahren Sie mehr: Redaktionssysteme und CCMS für die Technische Dokumentation

Ansätze für die Auswahl eines CCMS/Redaktionssystems

Für die Auswahl eines Redaktionssystems gibt es verschiedene Ansätze. Beispielsweise führen die Anbieter in einer Funktionsübersicht alle besonderen Merkmale ihres Redaktionssystems auf. So können Sie sich informieren, welches Redaktionssystem welche Alleinstellungsmerkmale hat.

Anhand von Funktionalitäten oder kurzen Produktdemonstrationen können Sie aber nicht unbedingt beurteilen, wie gut das System zu Ihren Bedürfnissen und Anforderungen passt. Auch die Handhabung des Systems und die Usability lassen sich nur bedingt über Listen erfassen. Deshalb arbeitet parson mit einer detaillierten Anforderungsliste, die Anforderungen aus verschiedenen Bereichen enthält. Darüber hinaus empfehlen wir, vor der Einführung eines neuen Systems mit Testsystemen der Hersteller zu arbeiten, Beispielinhalte zu testen oder einen kompletten Proof-of-Concept durchzuführen.

Anforderungen an ein CCMS/Redaktionssystem

Um die Anforderungen an das Redaktionssystem gemeinsam mit unserer Kundschaft zu klären, verwendet parson eine Anforderungsliste in Form von User Stories. In diesen User Stories sammeln wir die Anforderungen der Nutzer:innen und beantworten kurz und knapp die wichtigsten Fragen: Wer braucht warum welche Funktion?

Eine User Story hat folgendes Format:

Als <Persona/Rolle> benötige ich, <eine Funktion>, damit/weil <Motivation>.

User Stories in Funktionsbereichen

Die Anforderungen werden in Funktionsbereichen (so genannten Epics) gruppiert. Typische Funktionsbereiche sind:

• Content-Erstellung: In diesen Bereich gehören Anforderungen an das Autorenwerkzeug, das Content-Format, das Variantenmanagement und die Wiederverwendung von Inhalten.

• Workflows: Hier werden Anforderungen für die Steuerung von Arbeitsprozessen wie Prüfung, Freigabe, Veröffentlichung und Übersetzungsmanagement gelistet.

• Linguistische und terminologische Prüfung von Inhalten: Diese User Stories sammeln Anforderungen an die Prüfung und Sicherstellung der sprachlichen Qualität von Dokumentationsinhalten und Autorenunterstützung.
• Lokalisierung: Hierzu gehören Anforderungen an das Übersetzungsmanagement und das Zusammenspiel mit einem Translation-Management- System (TMS).
• Publikation und Content-Delivery: Hierzu gehören Anforderungen an die Erzeugung von Informationsprodukten und die dynamische Auslieferung von Dokumentationsinhalten, z.B. in ein Content-Delivery-Portal.

• Schnittstellen zu anderen Systemen

Neben den funktionalen Anforderungen sind auch nicht-funktionale Anforderungen wichtig. Dazu gehören z.B. das Lizenzmodell, IT-Anforderungen wie Cloud-Betrieb oder Verfügbarkeit sowie organisatorische Anforderungen wie Service-Level-Agreements für den Support.

INVEST-Kriterien für User Stories

Das Format der User Stories ist simpel; aber die Kunst ist auch nicht das Format, sondern die User Stories richtig zu schreiben, sodass sie den sogenannten INVEST-Kriterien entsprechen:

I – Independent: Ist es eine in sich geschlossene und von anderen Anforderungen unabhängige Anforderung?

N – Negotiable: Weiß ich als Entwickler:in, was der/die Anwender:in braucht, und kann ich somit verschiedene Lösungen für die technische Umsetzung verhandeln?

V – Valuable: Ist diese Funktion wirklich wichtig? Hat sie einen Geschäftswert?

E – Estimatable: Kann ich für diese Anforderung abschätzen, wie lange ich brauche? Liegt die Zeitschätzung unter zwei Tagen?

S – Small: Ist es wirklich das kleinstmögliche Inkrement oder kann ich die Anforderung in mehrere Inkremente aufbrechen?

T – Testable: Kann ich die Umsetzung der Anforderung testen? Welche Angaben fehlen mir, damit ich weiß, was ich testen muss?

User Stories, die die INVEST-Kriterien erfüllen, enthalten konkrete, spezifische Anforderungen. So können die Anforderungen an ein CCMS herauskristallisiert werden. Im nächsten Schritt wird evaluiert, welche Anbieter welche Kriterien bzw. User Stories erfüllen können.

Erfahren Sie in unserem Wissensartikel, wie man gute User Stories schreibt. 

User Stories priorisieren

Kein Anbieter eines Redaktionssystems wird alle Ihre Anforderungen erfüllen können. Daher ist es sinnvoll, die User Stories zu priorisieren. Manche Anforderungen müssen zwingend erfüllt werden, damit ein CCMS in Frage kommt. Für die Dokumentation vieler verschiedener Produktvarianten könnte ein solches K.O.-Kriterium etwa das Variantenmanagement sein. Andere Anforderungen wiederum sind zwar praktisch, aber nicht zwingend erforderlich, z.B. integrierte Übersetzungsworkflows. parson empfiehlt die MoSCoW-Priorisierung zur Einstufung der Wichtigkeit.

Passende Redaktionssysteme auswählen

Der nächste Schritt im Auswahlprozess ist die Identifikation passender Systeme für Ihre Anforderungen. Gute Informationsquellen für Redaktionssysteme sind die folgenden:

• Die Websites der Hersteller mit Datenblättern zur Funktionalität ihrer Systeme
• Messen, z.B. auf der tekom-Jahrestagung, mit der Möglichkeit zur Produktvorführung
• Webinare der Hersteller
• Beratungsdienstleister, die Erfahrung mit mehreren Systemen haben

Erstellen Sie auf der Grundlage der verfügbaren Informationsquellen eine Liste aller grundsätzlich in Frage kommenden Systeme, die sogenannte Longlist.

Von der Longlist zur Shortlist: CCMS-Anforderungskatalog

Da Sie nicht viele Systeme detailliert testen können, gilt es als nächstes, die besten Kandidaten auf der Longlist zu identifizieren und daraus eine Shortlist zu erstellen. Dafür gleichen Sie anhand der vorhandenen Informationen ab, welche der Systeme Ihre Kernanforderungen am wahrscheinlichsten erfüllen.

Anschließend können Sie die Systeme auf der Shortlist konkret und detailliert miteinander vergleichen und z.B. einen Ausschreibungsprozess starten: Sie senden die fertig ausformulierten und priorisierten User Stories an die Hersteller der Redaktionssysteme als Anforderungskatalog. Diese beantworten dann, welche dieser Anforderungen sie wie anbieten können. Häufig sind viele Anforderungen bereits durch die Standardfunktionalitäten abgedeckt.

Manche Anforderungen sind aber nicht out-of-the-box umsetzbar und müssen speziell implementiert werden. Das kostet entsprechend. Andere Features werden von den Herstellern bereits angestrebt, befinden sich aber noch in der Entwicklung und sind also mit entsprechender Wartezeit verbunden.

Spannungsfeld Zeit, Budget und Funktionsumfang

Bei der Auswahl eines CCMS kann man in ein Spannungsfeld zwischen Zeit, Budget und Funktionsumfang geraten: Muss das CCMS schnell eingeführt werden, können Sie z.B. Abstriche beim Funktionsumfang machen oder mehr für das CCMS bezahlen. Eine höhere individuelle Anpassung, die zu einer vollständigeren Erfüllung der Anforderungen führt, kostet häufig auch mehr Geld und/oder Zeit.

Definieren Sie also die Anforderungen im Vorfeld möglichst genau, um zu wissen, mit welchen Aufwänden und Kosten Sie rechnen müssen.

Die Wichtigkeit von Sandboxes, Proof-of-Concepts und Content-Prototypen

Ein Redaktionssystem begleitet Sie in der Regel viele Jahre. Bei der Einführung werden Prozesse neu definiert und umgesetzt. Häufig werden auch das Dokumentationsformat und die Dokumentstrukturen umgestellt. Die Entscheidung für ein bestimmtes System hat also gravierende Auswirkungen auf die Arbeitsweise der Technischen Redaktion. 

Um das Risiko einer gescheiterten Einführung eines neuen Produktivsystems zu vermeiden, können Sie folgende Mittel einsetzen:

• Sandbox: Viele Hersteller bieten Testzugänge zu ihren Systemen an. Dort können Sie mit einigen Beispielinhalten die Funktionen des Redaktionssystems ausprobieren und ein Gefühl für die Arbeit im System bekommen. Die Zugänge sind oft zeitlich begrenzt und teilweise kostenfrei.
• Proof-of-Concept: In einem Proof-of-Concept (PoC) testen Sie in einem speziell für Sie bereitgestelltem System mit Ihren Inhalten ausgewählte Anforderungen aus dem Anforderungskatalog (User Stories). Dazu werden für die einzelnen Stories Abnahmekriterien definiert und die Funktionen entsprechend getestet. Da PoCs mit Konfigurations- und Anpassungsarbeiten seitens der Hersteller verbunden sind, sind diese in der Regel kostenpflichtig.
• Content-Prototyp: Wenn Sie mit der Einführung des Redaktionssystems auch die Informationsarchitektur ändern, z.B. weil Sie von Dokumenten auf modulare, topic-basierte Dokumentation umsteigen, dann sollten Sie die geplante Architektur mit repräsentativen Inhalten im neuen System testweise umsetzen. Der Content-Prototyp kann auch im Rahmen des PoC umgesetzt werden.

Geld und Aufwand, die Sie in solche vorgelagerten Tests investieren, sind gut angelegt und helfen dabei, Fehlinvestitionen in ungeeignete Systeme zu vermeiden. Sie können Schwachstellen und auch Vorzüge eines Redaktionssystems gut vorab identifizieren und verhindern so ein böses Erwachen während der eigentlichen Einführung des Systems. Aufwände, die für den PoC entstehen, kommen zudem auch dem späteren Produktivsystem zugute, sodass diese nicht erneut entstehen.

Einführung des Produktivsystems

Bei der Einführung eines Redaktionssystems können Sie gut nach agilen Prinzipien vorgehen: Sie definieren zwei- bis vierwöchige Sprints, in denen jeweils eine bestimmte Menge der definierten User Stories umgesetzt und getestet werden. So können Sie die Funktionalitäten des Systems nach und nach in Betrieb nehmen. 

Parallel können Sie Inhalte in das neue System übertragen. Wieviel Sie übernehmen und welche Inhalte zuerst drankommen, ist in der Regel von mehreren Faktoren abhängig:

• Gibt es eine neue Informationsarchitektur, d.h. müssen die Inhalte grundlegend neu strukturiert werden? Dann muss ggf. ein Content-Engineering durchgeführt werden. 
• Wechseln Sie das Dokumentationsformat? Dann kann ggf. (semi-)automatisch migriert werden, z.B. von einem XML-Format in ein anderes.
• Steht ein neues Produkt oder ein neues Release an? Dann können Sie diese Inhalte zuerst im neuen System erstellen.
• Müssten Bestandsinhalte aus dem neuen System heraus publiziert werden? Sonst können Sie diese in den vorhandenen Formaten einfrieren und als Legacy-Dokumente zur Verfügung stellen. So sparen Sie ggf. hohe Kosten für eine Migration.

Marktübersicht: Welche CCMS/Redaktionssysteme gibt es?

Nachfolgend finden Sie Beispiele für CCMS und Redaktionssystemen, mit denen parson bereits gearbeitet hat (in alphabetischer Reihenfolge):

• Adobe Experience Manager
• COSIMA 
• Docuglobe und XR/Engineering 
• Empolis Content Lifecycle Manager
• IXIA CCMS
• Paligo
• Schema ST4
• Smart Media Creator
• Tridion Docs

Darüber hinaus gibt es viele weitere CCMS von verschiedenen Anbietern.

Wir unterstützen Sie bei der Einführung eines CCMS oder Redaktionssystems

parson berät Sie herstellerübergreifend- und unabhängig bei der Auswahl eines CCMS oder Redaktionssystems. Wir helfen bei der Ausarbeitung von User Stories, unterstützen auf Wunsch bei deren Priorisierung und werten die Antworten der Hersteller für Sie aus. So arbeiten wir