Ich habe noch kein CCMS-Migrationsprojekt gesehen, das im ursprünglichen Zeitplan geblieben ist. Das sage ich nicht, um die Vorhaben kleinzureden. Eine CCMS-Migration ist eine der sinnvollsten Investitionen, die eine Technische Redaktion tätigen kann. Aber die Diskrepanz zwischen geplantem und tatsächlichem Aufwand ist in diesem Bereich auffällig groß.
Es gibt Gründe dafür. Die meisten sind bekannt. Trotzdem werden sie beim nächsten Projekt wieder unterschätzt. Deshalb schreibe ich sie hier auf.
Warum CCMS-Migration-Zeitpläne regelmäßig nicht halten
Der erste Grund ist strukturell: Eine CCMS-Migration ist ein Prozessumbau, keine Software-Einführung. Der Prozessumbau der die Art verändert, wie Informationen erstellt, strukturiert, verwaltet und ausgespielt werden. Wer das als IT-Projekt plant, unterschätzt den menschlichen und organisatorischen Anteil der Arbeit von Beginn an.
Der zweite Grund ist die Datenbasis. Die meisten Unternehmen unterschätzen den Zustand ihrer bestehenden Dokumentation vor einer CCMS-Migration. Wenn Sie 500 Word-Dokumente haben, ist die relevante Frage nicht: Wie lange dauert die Migration? Die relevante Frage ist: Wie viele dieser 500 Dokumente sind aktuell, vollständig und korrekt? In meiner Erfahrung ist die Antwort auf diese Frage selten komfortabel.
Das Datenmüll-Problem vor der Systemeinführung
Wenn Sie Inhalte in ein neues System übernehmen, die falsch oder minderwertig sind, füllen Sie ein neues System mit altem Problem. Shit in, shit out, das gilt für jede Systemeinführung, nicht nur für diese.
Die erste Entscheidung sollte daher sein: Was migrieren wir, und was nicht? Abgekündigte Produkte, veraltete Funktionen, Inhalte, die niemand mehr verifizieren kann, all das gehört nicht ins neue System. Es kostet Aufwand, erzeugt Ballast und macht die Strukturierungsarbeit schwerer.
Mein Vorschlag: Beginnen Sie mit dem aktuellen, validierten Produktportfolio. Das gibt eine klare Basis, von der aus Sie planen können. Alles andere ist eine Entscheidung, die Sie treffen können. Aber nicht sofort treffen müssen.
Eine Situation, die ich kenne: Eine Information muss minimal überarbeitet werden. Die Überarbeitung dauert drei Minuten. Die Aufnahme in das neue System würde zwei Tage dauern. Hier gibt es keine pauschale Antwort. Es kommt darauf an, wie zeitkritisch das Projekt ist und ob Übersetzungen im Spiel sind. Wenn ja, ist die Übernahme fast immer der richtige Weg — weil Sie dann bestehende Übersetzungen wiederverwenden können, sobald der Ausgangstext unverändert bleibt.
In der Praxis, wurden rund 40 % der vorhandenen Dokumente aus dem Migrationsscope herausgenommen — abgekündigte Produkte, doppelte Versionen, Inhalte ohne verifizierten Gültigkeitsstatus. Das hat den Migrationsaufwand erheblich reduziert und gleichzeitig die Qualität des Datenbestands im neuen System deutlich verbessert. Das ist kein Nebeneffekt, das ist das Ziel.
Der unterschätzte Prozessumbau bei der CCMS-Migration
Die Arbeit in einem CCMS unterscheidet sich fundamental von der Arbeit in Word-Dokumenten. Sie arbeiten plötzlich in einer Datenbank, müssen Metadaten entwickeln, sich mit XML oder Markdown beschäftigen, Strukturierungsregeln einhalten. Themen wie DITA, iiRDS oder ETIM sind für viele Teams neu.
Das bedeutet konkret: Schulung, Einarbeitung, Fehler, Korrekturen. Der produktive Betrieb beginnt nicht am Tag der Systemübergabe. Er beginnt nach einer Lernphase, deren Länge vom Ausgangszustand des Teams abhängt. Wer diesen Anlauf nicht im Projektplan berücksichtigt, hat einen unrealistischen Projektplan.
Die iiRDS-Spezifikation gibt dabei eine gute Orientierung, wohin der Weg bei der Informationsauslieferung führen kann. iiRDS-Spezifikation, tekom Wer das früh versteht, trifft bessere Architekturentscheidungen.
Ein weiterer Aspekt, der regelmäßig unterschätzt wird: die Schnittstellenarbeit. Ein CCMS ist kein isoliertes System. Es muss Daten aus CAD-Systemen, ERP-Systemen, Übersetzungswerkzeugen empfangen und in verschiedene Ausgabeformate exportieren. Jede dieser Schnittstellen ist ein Projekt im Projekt. Ich empfehle, in der Systemkonzeption explizit zu klären, welche Schnittstellen im ersten Schritt abgebildet werden müssen und welche in einer zweiten Phase nachgezogen werden können. Alles auf einmal ist selten der richtige Ansatz, und fast immer ein Grund für Verzögerungen.
Change Management — Führungsarbeit, kein Workshop
Das dritte unterschätzte Element bei jeder CCMS-Migration: der menschliche Widerstand gegen Veränderung. Das ist kein Vorwurf gegen Mitarbeitende, es ist eine beobachtbare Gesetzmäßigkeit. Menschen sind Energiesparer. Der gewohnte Weg ist weniger anstrengend als der neue.
Wenn ich von Veränderungsmanagement schreibe, meine ich keine Guru-Workshops mit „Du kannst alles schaffen“-Botschaften. Das halte ich für wenig zielführend. Was ich darunter verstehe: transparent vermittelen, was sich ändert und warum, Mitarbeitenden Entwicklungsperspektiven zeigen, die mit dem neuen System einhergehen, eine klare Linie ziehen, ab wann die alte Arbeitsweise nicht mehr erlaubt ist. Und diese Linie durchhalten.
Sie werden Beschwerden bekommen. Das ist normal. Ihre Aufgabe ist es nicht, beliebt zu sein, sondern die Abteilung zukunftsfähig aufzustellen. Beides gleichzeitig gelingt selten vollständig.
Konkret empfehle ich: Legen Sie für jedes Teammitglied frühzeitig fest, welche Rolle es in der neuen Welt übernehmen wird. Wer eignet sich für die Strukturierung und Pflege des Metadatenmodells? Wer für die Terminologiearbeit? Wer für die Qualitätssicherung der importierten Inhalte? Menschen, die eine konkrete neue Aufgabe sehen, unterstützen Veränderungen erheblich besser als Menschen, die nur das Ende der alten Aufgabe sehen. Analysieren Sie die Stärken Ihres Teams und planen Sie die Entwicklung frühzeitig. Das kostet Zeit am Anfang, und spart Widerstand über den gesamten Projektverlauf.
Verbindung zur EU-Maschinenverordnung 2023/1230
Eine CCMS-Migration bietet auch eine gute Gelegenheit, regulatorische Anforderungen strukturell zu verankern. Die EU-Maschinenverordnung 2023/1230 stellt konkrete Anforderungen an Benutzerinformationen, von der Vollständigkeit der Risikoabdeckung bis zur Übersetzungsqualität. Ein CCMS, dessen Metadatenstruktur diese Anforderungen von Beginn an abbildet, macht Konformitätsprüfungen erheblich einfacher.
Wer bei der CCMS-Migration wartet, bis das System läuft, und dann die Konformitätsstruktur nachbaut, hat unnötigen Mehraufwand. Besser: die Anforderungen der EU-Maschinenverordnung 2023/1230 bereits in der Systemkonzeption berücksichtigen. Dann schlägt man zwei Fliegen mit einer Klappe.
Die tekom-Publikationen zur strukturierten Technischen Dokumentation bieten eine gute konzeptionelle Grundlage dafür. tekom, Strukturierte Technische Dokumentation Ergänzend empfehle ich die iiRDS-Spezifikation als Referenz für zukunftsfähige Metadatenmodelle. iiRDS-Spezifikation, tekom
Konkret bedeutet das: Prüfen Sie bei der Metadatenmodellierung, ob Sie Felder für Dokumenttyp, Produktzugehörigkeit, Revisionsstatus und Sprachversion von Anfang an einplanen. Das sind genau die Informationen, die Sie für eine Konformitätsprüfung brauchen. Sie investieren damit besonders bei der Konzeption, und ersparen sich später aufwändige Nachbesserungen im laufenden Betrieb.
KI und Systemeinführung: Reihenfolge beachten
Ich werde häufig gefragt, ob man KI-Tools direkt bei einer Systemeinführung einsetzen kann. Die Antwort ist: ja, aber mit der richtigen Reihenfolge. KI kann bei der Strukturierung von Ausgangsmaterial helfen, bei der Konsistenzprüfung, bei der Erstellung von Metadatenvorschlägen. Aber nur dann, wenn die Datenbasis dafür bereit ist.
Konkret empfehle ich: Grundstruktur und Terminologiearbeit zuerst, dann schrittweise KI-Unterstützung integrieren. Was das in der Praxis bedeutet, habe ich im Artikel zu KI in der Technischen Redaktion beschrieben.
Eines noch zum Thema Zeitplan: Planen Sie eine Pufferphase von mindestens zwei bis drei Monaten nach der offiziellen Systemübergabe ein. In dieser Phase läuft das Team produktiv, macht Fehler, fragt nach und stellt Anforderungen, die vorher nicht bekannt waren. Das ist kein Projektversagen, das ist der normale Lernprozess. Wer diesen Puffer nicht einplant, steht unter Druck und trifft dann schlechte Entscheidungen: Abkürzungen bei der Einarbeitung, Migration von Inhalten, die besser überarbeitet worden wären, oder der Rückfall in alte Arbeitsweisen.
Fazit: Was Sie vor der CCMS-Migration ändern sollten
Aus meiner Erfahrung zahlen sich drei Maßnahmen vor dem Projektbeginn am stärksten aus.
Erstens: Datenbasis bereinigen, bevor die CCMS-Migration beginnt. Veraltete Inhalte identifizieren und aus dem Migrationscope herausnehmen. Das spart mehr Zeit, als man vorher annimmt.
Zweitens: Terminologiearbeit starten. Wer ohne gepflegte Terminologie in ein CCMS migriert, baut diese Arbeit im laufenden Betrieb nach, unter deutlich ungünstigeren Bedingungen.
Drittens: Prozesse beschreiben, bevor das Tool eingeführt wird. Wer erst nach dem Systemkauf fragt, wie der neue Erstellungsprozess aussehen soll, hat die Reihenfolge umgekehrt.
Die drei genannten Maßnahmen lassen sich in der Regel in zwei bis vier Wochen abschließen. Sie kosten Zeit. Aber deutlich weniger Zeit als die Probleme, die entstehen, wenn sie übersprungen werden.
Wenn Sie eine CCMS-Migration planen oder vorbereiten und wissen wollen, wo die typischen Fallstricke liegen, bin ich für ein Gespräch erreichbar.
Bevor das nächste Tool gekauft wird — sprechen wir vorher
In Technischen Redaktionen entscheidet selten das Werkzeug, sondern die Datenbasis und die Prozessreife. Schübeler Consulting prüft Ihre konkrete Situation: Modularitätsgrad, Terminologie, Schnittstellen, Personal-Setup. Daraus kommt eine Empfehlung, mit der Sie Ihre nächste Investition belastbar begründen können.
Erstgespräch direkt online buchen →
Lieber schreiben? info@schuebeler-consulting.de
— Johann Jörgen Schübeler, Schübeler Consulting
