Wie viel kostet die Migration von Daten und Dokumenten?

Die Überführung von Print-orientierten Dokumenten in ein Content-Management-System haben wir im letzten Blogbeitrag beleuchtet. Dabei war auch die Sprache davon, wie intensiv und fordernd diese Migration sein kann – wir nannten den Artikel darum auch „Feindliche Übernahme“. So verschieden das Ausgangsmaterial ist und so verschieden die Anforderungen an Zielformat und Zielqualität sind, so unterschiedlich ist auch der Weg, der bei einer Content-Migration eingeschlagen werden kann. Ganz praktisch stellen sich aber viele Unternehmen die Frage: Wie plane und kalkuliere ich denn so ein Migrationsprojekt? Weiterlesen

Feindliche Übernahme: Print-orientierte Dokumente ins medienneutrale CMS migrieren

Von Print zu Digital: Eine sorgfältige Planung erleichtert die Migration von technischen Dokumenten

Viele Unternehmen nutzen den Schwung der aktuellen Digitalisierungsbestrebungen, um auch ihre technische Kommunikation, also Datenblätter, Handbücher usw. elektronisch verwertbar zu machen. Wo vormals Papier und PDF als Maßstab dienten, soll Information nun auch online, mobil und interaktiv bereitgestellt werden.

Die Idee hinter „Information 4.0“ ist, die richtige Information zur richtigen Zeit an die richtige Person auszuliefern. Um das zu bewerkstelligen, muss im Vorfeld aber festgelegt werden, was jeweils hinter dem Begriff „richtig“ zu verstehen ist. Das bedeutet, dass Informationen systematisiert und in mundgerechte Bausteine (diese Metapher klingt nur für Leute abwegig, die keine Kinder haben) zerlegt und aufbereitet werden. Schnell fallen Begriffe wie Metadaten, Modularisierung, Taxonomien, HTML 5 oder Content Delivery. An diesem Punkt kommt man nur noch mit Mühe, wenn überhaupt, ohne ein Content-Management-System weiter. So führen derzeit recht viele Unternehmen, deren Technische Redaktion bisher vorwiegend Dokumente mit DTP-Werkzeugen (Desktop Publishing) wie InDesign erstellt hat, ein Baustein-orientiertes CMS (auch „Component-CMS“ oder „CCMS“) als Publikationslösung ein.

Ist die Systementscheidung getroffen (als Goldpartner von SCHEMA empfehlen wir meistens deren ST4, aber das tut hier nichts zur Sache), das System installiert und die Mitarbeiter geschult, steht die Übernahme der bestehenden Dokumente ins neue System an. Und diese Migration bestehender Dokumente gestaltet sich möglicherweise wesentlich aufwändiger als gedacht. Warum das so ist, möchte ich in diesem Beitrag erläutern. Vergleichen wir dazu das Ausgangsmaterial mit dem Zielsystem.

Das Ausgangsmaterial

Verbreitete Werkzeuge, mit denen Dokument-orientierte Technische Redaktionen arbeiten, sind InDesign, Word oder FrameMaker. Unabhängig vom eigentlichen Tool finden sich eine Reihe von ähnlichen Merkmalen in der Redaktionsarbeit, die in unsere Betrachtung hineinspielen:

  • Dokument-Dateien als Arbeits-Einheit
    Die Datei ist die führende Informationseinheit im Prozess, auch wenn sich z. B. mit Buchfunktion oder Variablen im gewissen Umfang über- und untergeordnete Informations-Strukturen definieren lassen. Vom Inhalt her gedacht, agieren wir mit ganzen Dokumenten, bestenfalls in Kapiteln. Auf diesem Korn werden auch Varianten gebildet: Übersetzungen, Gerätevarianten, Dokumenttypen sind jeweils eigene Dateien. Bedingte Texte und Variablen leisten hier zwar je nach Werkzeug ihren Beitrag, das Ausmultiplizieren der Optionen im Griff zu behalten, ändern aber nicht das Grundprinzip.
  • Informationen sind linear strukturiert
    Im Wesentlichen ordnen sich Absätze und Tabellen brav hintereinander von der Titelseite bis zum Anhang. Alternativ dazu verteilen sich Text- und Bildrahmen auf einzelne Seiten. Besonders bei eher werblich genutzten Informationen wie Datenblättern kann man von einem hohen Maß an individuellen Layout-Entscheidungen ausgehen. Beliebt ist es, komplexe Tabellen zu gestalten, die bis hinunter zur einzelnen Zelle mit unterschiedlichen Schriftarten, Rahmen und Hintergründen versehen sind.
  • Dokumente und Arbeitsprozesse hängen vom Werkzeug ab
    Viele Porzesse sind auf das verwendete Werkzeug zugeschnitten und damit proprietär. In Word kann man Zeichnungen erstellen, in InDesign lassen sich Illustrator-Grafiken einbetten. Felder und Textmarken, Layout-Automatismen wie Silbentrennung, Seitenumbruch mit Schusterjungen-Regeln oder generierte Verzeichnisse sind praktische Hilfsmittel, die die Tools bereitstellen, die aber nur dort funktionieren.

Das Zielsystem

Baustein-orientierte Content-Management-Systeme sind deswegen ein hervorragende Basis für die Digitalisierung der Technischen Kommunikation, weil sie genau die Mechanismen mitbringen, um Informationen für die Digitalisierung zu systematisieren. Für unsere Betrachtung relevant sind u.a. diese Aspekte:

  • Medienneutrales Arbeiten mit CCMS
    CCMS sind auf die Ausgabe in diversen Zielmedien spezialisiert. Inhalte werden also nicht direkt gelayoutet, sondern als klassifizierte Elemente typisiert, z. B. als Überschrift, Auflistung oder Grafik mit Bildunterschrift. Wie diese Elemente im Ausgabemedium dargestellt werden, wird frühestens beim Erzeugen einer Publikation generisch anhand der Klassifizierung festgelegt. In digitalen Publikationen, z. B. im iiRDS-Format, kann das Layout auch vollständig dem anzeigenden System überlassen werden. Damit die Generik effektiv funktioniert, muss der Content im CCMS konsequent strukturell und semantisch aufbereitet sein. Das bedeutet auch, dass punktuelle, individuelle Anpassungen in der Darstellung nur sehr aufwändig zu realisieren sind und tunlichst vermieden werden sollten.
  • Textbausteine als Arbeits-Einheiten
    Die Arbeit im CCMS dreht sich um Textbausteine, die vor einer Publikation zusammengestellt werden. Diese Bausteine können Hierarchien bilden (z. B. Kapitel und Unterkapitel), lassen sich mehrfach wiederverwenden (typisch z. B. für Sicherheitshinweise) und v. a. lassen sie sich mit Eigenschaften bzw. Metadaten versehen, die sie beschreiben (z. B. Titel oder Schlagwörter) oder nach unterschiedlichen Kriterien klassifizieren (z. B. als Sicherheitshinweis, als einem Produkt X zugehörig oder als nur relevant für Wartungstechniker). Auf Basis der Textbausteine erfolgt im CCMS die Ausbildung von Varianten und Versionen, und auch Übersetzung und Mehrsprachigkeit wird normalerweise auf diesem Korn verwaltet.

Womit Sie also rechnen sollten

Wir haben also als Ausgangsmaterial linear strukturierte, möglicherweise individuell gelayoutete Dokumente in proprietären Formaten. Diese sollen in ein System übernommen werden, in dem klassifizierte Textbausteine mit medienneutralen Inhalten zu Hierarchien und Publikationen zusammengestellt werden. Sie müssen also damit rechnen, dass eine Reihe von Änderungen und Ergänzungen bei der Migration notwendig sein werden.

Wie gut sich die Übernahme automatisieren lässt, hängt dabei zum großen Teil davon ab, wie heterogen und individuell gestaltet das Ausgangsmaterial ist. Hier die wichtigsten Überlegungen:

  • Der Aufwand steigt mit der Heterogenität
    Je heterogener die Ausgangsdokumente, aber auch je höher die gesteckten Ziele, was Wiederverwendung, Vereinheitlichung und Klassifikation von Bausteinen angeht, desto mehr Aufwand bedeutet das für die Content-Übernahme. Ein umfassender Migrationsplan, der sowohl technische Details der Abbildung von alt nach neu als auch eine Timeline der Übernahme-Aktivitäten beinhaltet, sollte auf jeden Fall erstellt werden. Positiver Nebeneffekt: Die dazu notwendige Analyse der Bestandsdaten lädt dazu ein, alte Ausnahmen und Sonderfälle auszumerzen.
  • Nicht alles muss mit
    Nicht alle vorhandenen Dokumente müssen ins neue System übernommen werden. Je länger ein Dokument nicht mehr angefasst wurde, desto geringer die Wahrscheinlichkeit, dass es noch einmal überarbeitet wird. Hier lässt sich einiges an Aufwand einsparen. Denn sei es, weil Redaktionsteams sich nach und nach besser organisieren, oder weil die ganze Tech-Dok-Branche sich insgesamt weiterentwickelt, oder weil die Werkzeuge früher nicht so gut waren: ältere Dokumente verursachen erfahrungsgemäß mehr Aufwand als neuere.
  • Semantik fällt nicht vom Himmel
    Aus der linearen Abfolge von Absätzen, Überschriften, Auflistungen, Grafiken  und Tabellen der Ausgangsdokumente lassen sich zwar einige Strukturen und Attribute für das Zielsystem ermitteln. Aus einer Überschrift und dem nachfolgenden Text bis zur nächsten Überschrift lässt sich noch relativ leicht ein Textbaustein erzeugen. Aus einer zweispaltigen, einzeiligen Tabelle mit Warnsymbol-Grafik lässt sich vielleicht ein Warnhinweis ermitteln. Aber spätestens wenn es darum geht, eine Folge von Listenpunkten als Handlungsanweisung mit Arbeitsschritten und Zwischenergebnissen zu erkennen, wird eine automatische Konvertierung schwierig. Auch das Klassifizieren der Bausteine, meinetwegen als Sicherheits- oder Wartungsinformation, oder als nur für den amerikanischen Markt relevant, lässt sich oft nur manuell nachträglich zuordnen.
  • Vorsicht bei Übersetzungen
    Dass Ausgangsdokumente heterogen sein können, wirkt sich an einer Stelle besonders aus: Beim Übernehmen von Übersetzungen. Auch die Übersetzung basiert im CCMS auf dem Textbaustein als Einheit. Sind nicht alle übersetzten Dokumente exakt so strukturiert wie das Ausgangsdokument, weil beispielsweise ein Überschrift versehentlich zum Standard-Absatz wurde, kann die Zusammenführung schnell chaotisch werden. Wenn deshalb die vorliegenden Übersetzungen bereits mithilfe eines Translation-Memory-Systems (TMS) entstanden sind, empfiehlt es sich, nur die Ausgangssprache zu migrieren und die Übersetzung der Bausteine über die TMS-Anbindung abzuwickeln, die alle gängigen CCMS besitzen, um mit den zu erwartenden Hundertprozent-Matches günstig einen sauberen Übersetzungsstand zu erhalten.
  • Achten Sie auf Grafiken
    Proprietäre Mechanismen und Formate lassen sich nicht immer übernehmen. Als Beispiel möchte ich hier auf Grafiken etwas näher eingehen. CCMS arbeiten i.d.R. mit dem medienneutralen XML-Format, um Inhalte zu strukturieren. Grafiken in gängigen Austauschformaten von PNG und JPG über TIFF und EPS lassen sich dort verwalten, anzeigen und einbinden. In den Ausgangsdokumenten finden sich aber nicht nur hauseigene Dateiformate wie Illustrator (AI) oder Photoshop (PSD) in InDesign oder in WMF-Container verpacktes EPS  in MS-Word. Grafiken können auch direkt im Werkzeug gezeichnet sein und sind dann als Gruppe frei schwebender Objekt auf der Seite positioniert. Oder sie sind mithilfe der Grafikeinstellungen individuell beschnitten, skaliert und mit Effekten versehen. In all diesen Fällen ist eine Konvertierung in ein medienneutral verwertbares Format nötig.
  • Schützen Sie sich vor Doppelungen
    Dass man Textbausteinen  ggf. vielfach wiederverwenden kann, ist einer der großen Vorzüge von CCMS. Nach der Übernahme von Dokumenten, wo die Mehrfachverwendung eine eher untergeordnete Rolle spielt, bleibt hier ein großer Spielraum für Nacharbeiten. Es hat sich bewährt, bei der Migration dafür zu sorgen, dass zumindest Sicherheitshinweise, die ja gerne an vielen Stellen des gesamten Dokumentbestands in identischer Form wiederkehren, als eigene, wiederverwendbare Bausteine zu extrahieren und an zentraler Ablage-Stelle einzusammeln. Ähnlich lässt sich ggf. mit Konformitätserklärungen, einleitenden Bemerkungen u. ä. verfahren. Damit hat man einen guten Ausgangspunkt, um den Informationsbestand nach und nach von Doppelerfassungen zu bereinigen.

Schlussbemerkungen

Die Migration von DTP-orientierten Dokumenten in ein Baustein-orientiertes CCMS kann im einfachsten Fall (nicht zu viele homogene, strukturiert erfasste Dokumente, einfache Projektziele) sehr schnell und mit Bordmitteln (CCMS besitzen in der Regel eine Dokument-Import-Schnittstelle) von Statten gehen. Der Regelfall ist das unserer Erfahrung nach leider nicht.

Unerlässlich ist daher eine umfassende Analyse des Ausgangs-Materials und davon ausgehend ein ebenso umfassender Migrationsplan, der auch eine Zeit- und Ressourcenplanung beinhalten sollte. Da man die Fähigkeiten und Besonderheiten des neu beschafften CCMS vielleicht selbst noch nicht vollständig einschätzen kann, lohnt es sich fast in jedem Fall, sich dabei von einem erfahrenen Dienstleister beraten und auch begleiten zu lassen.

Ist Ihre Technische Dokumentation fit für die Digitalisierung? Planen Sie den Umstieg von DTP zu einem CCMS? Wir beraten Sie gerne zur Migration Ihrer Daten! Schicken Sie uns einfach eine Mail an: benjamin.rauschenberger@doctima.de.

Von A nach B – 6 Tipps zur Contentmigration

Pelikane im Flug

Nur selten ist Migration so einfach wie bei Zugvögeln…

Wenn es um die Bestandsdatenübernahme geht, kann man beim Wechsel des CMS einige böse Überraschungen erleben. Denn bei der Übernahme von Altdaten steckt der Teufel im Detail. Deshalb wollen wir heute einmal ein paar Tipps zu den Details geben, auf die Sie in Ihrem Contentmigrations-Projekt achten sollten.

Zeichenkodierung beachten

Welche Zeichenkodierung haben eigentlich die Ausgangsdaten: ISO-8859-1, Windows-1252, Unicode oder etwas noch Exotischeres? Und welche Zeichenkodierung erlaubt bzw. verlangt das Zielsystem. Gibt es im Ausgangstext ein durchgehendes Escaping (Kodierung von Sonderzeichen durch Zeichenfolgen, z. B. „äußerst“ wird zu „äußerst“) und wie lässt sich dieses in das Zielsystem transformieren? Wer hier die Daten vorab genau analysiert, kann eine Menge Probleme im Migrationsprozess vermeiden.

Inkompatible Layout- und Textkonstrukte

Sind die Textkonstrukte zwischen Ausgangs- und Zielsystem kompatibel zueinander.  Komplexe semantische Handlungsanweisungen, tief geschachtelte Listen oder Zeichenformatkombinationen sind typische Problemstellen. Manches System lässt schon die Kombination aus Fett- und Kursivmarkierung (<b><i>Si meliora…</i></b>) aus der Kurve fliegen.

Makros machen Ärger

Gelegentlich werden auch statische Dokumente teilweise dynamisch gestaltet (z. B. durch eingebundene Excel-Berechnungen) oder nachträglich verändert (z. B. durch Word-Makros). Im eigentlichen Bestandscontent sind solche Mechanismen oft nicht leicht zu erkennen und manchmal sind sie den Benutzern nicht einmal bewusst. Hier ist also Recherche angesagt und ein Vergleich zwischen dem Bestandscontent und den ausgelieferten Dokumenten. Hat man solche Mechanismen entdeckt, gilt es zu entscheiden, ob sich auf sie verzichten lässt, ob sie im Zielsystem nachimplementiert werden können oder ob sie durch geeignete Mechanismen des Zielsystems ersetzt werden müssen.

Grafikformate

Auch bei Grafiken gibt es Formatprobleme – und nicht nur wenn es um print oder online als Ausgabemedien geht. Immer wieder kommen bestimmte Zielsysteme nicht mit den Formaten des Ausgangssystems zurecht. Word kann zum Beispiel nicht mit SVG umgehen. Umgekehrt stellen Word-Zeichnungen für fast alle anderen Systeme ein Problem dar. Also: Auch hier genau prüfen, was möglich ist und im Problemfall zum Beispiel ein Kompromissformat finden, mit dem beide Systeme zurechtkommen.

Beschriftungen

Neben den eigentlichen Grafikformaten sollten Sie sich auch die Art der Beschriftung in den Grafiken ansehen. Hier sind ganz unterschiedliche Varianten üblich: fest im Bild integriert (eher selten), als gruppierte Objekte (häufig und schwierig zu migrieren), mit einer eigenständigen, unabhängigen Legende (aufpassen, damit die Zusammenhänge nicht verloren gehen) u. v. m. Bedenken Sie auch die Optionen, die das Zielsystem bietet. Vielleicht ist ja z. B. eine Clickmap die bessere Lösung für die Beschriftung. Denn wenn man schon den Aufwand für die Migration betreibt, dann sollte der Content im Zielsystem auch besser sein als zuvor.

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.