Migration – eine neue Heimat für den Content

Edgar Hellfritsch

Edgar Hellfritsch

Daten und Content: Ein Schatz, den wir im Lauf der Jahre mühsam aufgebaut haben. Und der zum Problem wird, wenn wir uns zum Beispiel entscheiden von der altgedienten Textverarbeitung (z. B. Word oder FrameMaker) auf ein Content-Management-System umzusteigen. Seltene Aufgabe, die aber doch immer wieder zu erledigen ist, wenn ein Systemumstieg ansteht. Wir haben mit Edgar Hellfritsch geredet. Er beschäftigt sich seit über zwanzig Jahren mit der Frage, wie man Daten und Content am besten migriert und hat über hundert Migrationsprojekte geleitet. In diesem Interview schildert er uns seine Erfahrungen.

doctima: Edgar, wie sieht denn das typische Migrationsprojekt aus?

Jedes Projekt ist irgendwie natürlich wieder anders. Aber grundsätzlich kann man sagen: Ein typisches Migrationsprojekt hat etwa 10.000 Seiten DIN A4, die in etwa 30 Sprachen vorliegen. Migriert wird meistens von einem layout-orientierten Textverarbeitungssystem in ein strukturiertes Format, also ein CMS oder xml-basierte Standards wie DITA. Letzten Endes kommt aber alles vor. Wir hatten auch schon Fälle wo wir DITA nach DITA migriert haben, weil zwei Unternehmensteile sich für einen gemeinsamen Standard entschieden haben.

doctima: Und wie geht man dabei vor?

Grundsätzlich muss man sich entscheiden, ob der Content schrittweise nach und nach migriert werden soll oder zu einem Stichtag in einer großen Hauruck-Aktion. Welches Vorgehen da sinnvoll ist, lässt sich nicht pauschal sagen. Das hängt von der Gesamtdatenmenge, vom Vernetzungsgrad des Contents, von den Redaktions- und Freigabeprozessen und natürlich von der Terminplanung für den Produktionsstart im neuen System ab.

Nach und nach zu migrieren erscheint auf den ersten Blick oft erst einmal wünschenswerter. Altdaten können fallweise auch einmal unmigriert bleiben, der Aufwand ist überschaubarer und die ersten Erfolgserlebnisse sind schnell vorhanden. Aber: Nach und nach zu migrieren bedeutet einen deutlichen Mehraufwand, denn beide Systeme müssen über einen längeren Zeitraum weiterbetreut werden. Und wenn die Redaktion diesen Mehraufwand personell nicht leisten kann, kommt es im schlimmsten Fall dazu, dass die (produktive) Systemeinführung sich so lange verzögert, bis sie komplett scheitert.

Und dann gibt es noch eine Fülle weitere Entscheidungen: intern oder extern, automatisiert oder manuell und, und, und. Jede dieser Entscheidungen hat ihr eigenes Für und Wider. Aber ich glaube das würde jetzt zu weit führen, wenn ich da im Detail darauf eingehe.

doctima: Übernimmt so eine Migration der Systemhersteller?

In den seltensten Fällen. Denn Migration bedeutet eine ganz eigene Art von Expertise, bei der man Ausgangsformat und Endformat genau im Blick haben muss. Auf dem Weg gibt es dabei einige Tücken, die für Systemhersteller schwer zu kalkulieren sind. Im Normalfall ist es hier besser, sich einen Dienstleister ins Boot zu holen, der auf Migrationsprojekte spezialisiert ist.

doctima: Welche Formate sind denn besonders schwer zu migrieren?

Wahrscheinlich erwarten jetzt viele als Antwort: Word! Das ist aber gar nicht so. Denn das Problem liegt nicht so sehr im Format selbst, sondern eher darin, wie strukturiert die Redakteure gearbeitet haben und wie konsequent sie ihre Standards eingehalten haben. Da sind mir Word-Dokumente, bei denen sauber mit Formatvorlagen gearbeitet wurde, tausendmal lieber als Dokumente, bei denen die Redakteure versucht haben, mit XML zu layouten.

Umgekehrt kann eine scheinbar einfache Anforderung, wie DITA nach DITA zu migrieren, sich im Projektverlauf als extrem heikel erweisen, wenn z. B. Metadaten zur Steuerung des Publikationsprozesses verwendet wurden oder eben semantische Strukturen missbraucht wurden, um ein bestimmtes Erscheinungsbild zu erzeugen. Da werden dann Informationssequenzen als Bildbeschriftung getaggt, weil man das Ganze gerne in einer Box darstellen will. Für die Migration ist so etwas ein Desaster.

doctima: Ein Erfolgserlebnis?

Für unsere Kunden ist der größte Erfolg wohl immer, wenn sie sehen, wie schnell ein Großteil des Contents migriert ist. Als derjenige, der sich um die Umsetzung kümmert, sind die ERfolge für mich aber oft eher die Kleinigkeiten am Rande. Vor einiger Zeit ist es mir z. B. in einem Projekt gelungen, komplexe Tabellen automatisiert von CALS nach HTML und wieder zurück umzuwandeln. Der Weg von CALS nach HTML ist mehr oder weniger trivial. Der Weg zurück ist aber ziemlich trickreich, weil das CALS-Tabellenmodell – na sagen wir mal – „originell“ ist. Da muss man sich letzten Endes jede Tabellenzelle einzeln angesehen haben, bevor man die Tabelle zusammenbauen kann. Für den Laien ist das dann nicht weiter spektakulär, wenn am Ende alles klappt. Aber als Spezialist ist man da schon ein wenig stolz.

doctima: Zum Abschluss: Was würdest du jemandem für die Migration raten,  bevor er einen Systemumstieg plant?

Sich neben dem Dokumentbestand auch den Redaktionsprozess vorher genau anzusehen und sich im Zweifelsfall Hilfe von außen zu suchen.  Ohne Bestandsanalyse kann man sonst manche böse Überraschung erleben, weil zum Beispiel im Publikationsprozess Makros nachträglich noch den Content verändern. Generell ist es sinnvoll sich anzusehen, welche Strukturen im Content vorhanden sind und welche davon erhalten bleiben müssen. Wir haben dazu automatisierte Verfahren mit denen wir Bestands-Content analysieren. Da stellt sich dann eigentlich meistens heraus, dass es eine ganze Reihe von Dokumentstrukturen gibt, die bei 10.000 Seiten vielleicht nur drei oder vier Mal vorkommen. Und da sollte man sich dann schon fragen, ob es sich lohnt, das auch im Zielsystem abzubilden.

doctima: Danke für das spannende Interview.

Gerne.

 

Standardsammlung ohne Standardkost

Fünf Standards, viel Wissen, kein Vergleich

Wer technischer Redakteur, Verantwortlicher für die Einführung eines CMS, Quereinsteiger oder überhaupt an standardisierter und strukturierter Information interessiert ist, der soll mit „Standardisierungsmethoden für die technische Dokumentation“ gut bedient werden. Das Werk ist eine Hilfestellung für alle, die auf der Suche nach einer Methode zur Standardisierung ihrer Dokumentation sind. Werk sage ich bewusst, denn es handelt sich nicht um ein Buch, sondern um eine Sammlung von Aufsätzen, die von Experten oder Entwicklern der jeweiligen Standards verfasst wurden.

Amüsanter Anfang und lockeres Lernen

Geschichte mal anders: Mitreißender Informationsstrom statt öder Textwüste

Die ersten Zeilen lassen mich allerdings schmunzeln. Statt des erwarteten ernsthaften Textes überrascht ein unterhaltsamer Einstieg von Jürgen Muthig zur Vorstellung von Firmenstandards als Eigenentwicklung. Er ist gespickt mit humorvoller und anschaulicher Bildsprache, ohne lächerlich zu wirken oder mich als Einsteiger in meiner Wahl zu beeinflussen. Manfred Krüger und Wolfgang Ziegler schaffen es, den unterhaltsamen Stil der ersten Seiten weiterzuführen. Statt trockener Textwüsten über die Geschichte der Standards folgt ein ansprechender und kurzweiliger Fluss von Informationen. Nebenbei erhalte ich so solides Hintergrundwissen, das mir bei der Einschätzung der danach folgenden Expertenaufsätze hilft. Durch die Ansprache mit „wir“ ist der Text kein endloser Monolog und ich kann der zeitlichen Entwicklung von SGML und CALS über HTML und DocBook zu S1000D, DITA und weiteren modernen Standards gut folgen. Der Geschichtsteil hat auch einige Überraschungen parat: Zum Beispiel plaudert Ziegler ganz nebenbei aus dem Nähkästchen über den von ihm entwickelten Firmenstandard DOCU für Liebherr.

Eine bunte Mischung aus Expertenwissen

Sammelband: Vom Lehrbuch bis zur Werbebroschüre alles vertreten

Sammelband: Vom Lehrbuch bis zur Werbebroschüre alles vertreten

An manchen Stellen stößt das Konzept eines Sammelbandes leider an seine Grenzen. Die Autoren (Muthig/Schäflein-Armbruster, Closs, Lehrndorfer/Reuter, Juhl, Böhler) kommen auf sehr unterschiedlichen Wegen zur technischen Redaktion und unterscheiden sich in ihrem Schreibstil. Das schlägt sich auch in der Sammlung nieder. Die einen schreiben pistolenartige Kurzsätze, die anderen stapeln Schachtelsätze. Manche Aufsätze lesen sich wie eine Werbebroschüre, andere dagegen wie ein Lehrbuch. Ein wirklich objektiver Vergleich kann konzeptbedingt nicht stattfinden – kein Experte wird den Standard schlechtreden, für den er sich entschieden hat, und kein Entwickler das verreißen, was er selbst mühsam aufgebaut und verbreitet hat. Vergleichen muss der Leser deshalb selbst.

Entscheiden muss ich selbst

Wegfindung: Viele Standards führen zum Ziel

Wegfindung: Viele Standards führen zum Ziel

Die Entscheidung, welcher Standard für mich geeignet ist, wird mir nicht abgenommen. Aber sie wird mir erleichtert: So unterschiedlich die Stile der Autoren auch sein mögen, so wenig auch verglichen wird – jeder Aufsatz erklärt genau, wie der vorgestellte Standard funktioniert, für welche Einsatzzwecke er geeignet ist und erklärt die Hintergründe und Anwendung des Standards. Jeder Experte, der zu Wort kommt, macht deutlich, dass er ein Experte ist und vermittelt das Wissenswerte zu „seinem“ Standard. Die meisten von ihnen liefern auch eine Zusammenfassung für Eilige mit. Erfreulich ist, dass der Sammelband trotz des mehrfachen Aufgreifens derselben Themen in der Einführung und im dazu passenden Aufsatz nicht repetitiv ist – oder es zumindest schafft, nicht so zu wirken. Wer mehr wissen möchte, der wird im Werk ebenfalls fündig: Literaturangaben zu den jeweiligen Aufsätzen bieten eine Anlaufstelle zum Weiterlesen und das Autorenverzeichnis erleichtert die Kontaktaufnahme.

Gescheiterte Standards gibt es nicht

Das Schlusswort des Intros beschreibt in etwa den Eindruck, den die Sammlung von Expertenschriften bei mir hinterlassen hat. Das größte Problem eines Standards ist die Marktdurchdringung. Alle Standards haben ihre Berechtigung, einen gescheiterten Standard gibt es nicht. Was zu meinen Anwendungszwecken passt, wird übernommen. Und was nicht ganz passt, wird passend gemacht oder nur teilweise übernommen (dafür haben Krüger und Ziegler das schöne Wort „Steinbruchnutzung“ gefunden).

Sinn und Zweck der Aufsatzsammlung ist es, einen Überblick über einige der etablierten Standards in der Technischen Dokumentation zu bekommen. Ein Vergleich findet nicht statt. Das hat den Vorteil, dass ich unvoreingenommen an meine Auswahl gehen kann. Das hat aber gleichzeitig auch den Nachteil, dass mir etwaige Schwierigkeiten erst nach meiner Entscheidung auffallen können. Denn die Experten erwähnen Probleme oder Schwächen bei der Einbindung „ihrer“ Standards in Technische Dokumentation nicht. Dazu sollte man andere Werke zu Rate ziehen, die auch explizit die Schwächen mit in den Vergleich einbeziehen. Trotzdem servieren die Autoren eine Menge mundgerecht aufbereitetes Wissen, das bei der Beurteilung hilfreich ist. Nebenbei erfährt man – gerade als Einsteiger wie ich – bei der Lektüre Dinge, die einen vorher vielleicht interessiert haben, für einen technischen Redakteur aber nicht unwichtig sind. Zum Beispiel hat OpenOffice bereits vor Word eines der heute meistgenutzten Datenaustauschformate genutzt: XML. Das war für mich neu. Für Sie auch?

Literatur: Jürgen Muthig (Hrsg.): Standardisierungsmethoden für die Technische Dokumentation (2008). Verlag Schmidt-Römhildt, Lübeck, 167 Seiten. ISBN 978-3-7950-7066-3

Hinweis: Das hier besprochene Buch wurde uns vom Verlag kostenfrei als elektronisches Rezensionsexemplar zur Verfügung gestellt. Der Verlag hat keinerlei Einfluss auf den Inhalt dieser Besprechung genommen.

DITA und Deutschland – eine Antwort an die Redakteuse

Warum weht in Deutschland bei DITA ein anderer Wind? (c) lichtkunst.73 / pixelio.de

Warum weht in Deutschland bei DITA ein anderer Wind?
(c) lichtkunst.73 / pixelio.de

Im Nachgang zur #tekom15 hat Marijana Prusina hier die Diskussion auf der Tagung und ihre Gedanken zu DITA zusammengefasst. Unser Kommentar dazu.

Deutschland zu zögerlich? Ich denke eher nicht. Ich sehe den wichtigen Punkt eben doch darin, dass in Deutschland schon lange sehr leistungsfähige CCMS auf dem Markt sind.

Denn das heißt zunächst einmal: Alle early adopter haben sich frühzeitig damit beholfen.

Zweite Konsequenz: Die Unternehmen, die bisher bei unstrukturierten Workflows geblieben sind und bei denen DITA eine Lösung wäre, treffen auf einen Markt, auf denen DITA eine Lösung unter mehreren mächtigen Standards ist. Denn nur weil DITA eine Lösung wäre, heißt das ja nicht, dass ein CMS keine sein kann.

Drittens: Es gibt außerdem auch etliche Fälle, bei denen Unternehmen von DITA wegmigrieren. Auch das hält den Markt für DITA in Deutschland schlanker.

Und Viertens: Vielen Redakteure in Deutschland mit denen ich gesprochen habe, geht DITA schlicht und einfach auf die Nerven. In jedem zweiten internationalen Vortrag zu DITA wird zumindest angedeutet, dass die Redakteure in Deutschland sagen wir mal zu dumm sind zu verstehen, was DITA leistet. Zunächst ist das ja ohnehin schon keine besonders clevere Verkaufsstrategie. Und wenn ich die Argumente pro DITA dann schon in identischer Form seit mehreren Jahren von den CMS-Herstellern kenne, dann wirkt der DITA-Promoter auf mich nicht sonderlich kompetent.

DITA ist (genau wie CMS) immer nur so gut, wie die Leute damit arbeiten. Wir bei doctima haben in unseren Migrationsprojekten aus DITA schon die erstaunlichsten Fälle von Missbrauch erlebt. Leider versäumen viele Kunden von DITA (ebenso wie von CMS) ihre Redakteure auch redaktionell für strukturierte Schreibprozesse zu qualifizieren. Und dann hilft das beste System nichts…