Medienneutrale Datenhaltung — und warum sie über Ihr Dokumentationsprojekt entscheidet

Medienneutrale Datenhaltung und eines validen Datenmodells ist ein Thema, das in vielen Technischen Redaktionen aktuell ist. Worauf in der Praxis wirklich ankommt, jenseits von Marketing und Tool-Versprechen.

Medienneutrale Datenhaltung klingt nach einem technischen Detail. Nach etwas, das man der IT überlässt. Nach einer dieser Fragen, die man irgendwann klärt, wenn das dringendere Thema abgearbeitet ist.

Das ist ein Irrtum, der später teuer wird.

Ich habe in den vergangenen Jahren ausreichend Technische Redaktionen und Dokumentationsbereiche von innen gesehen, um eine These zu formulieren, die ich hier ungern verwässere: Die Entscheidung darüber, wie Sie Inhalte halten, ist die Entscheidung darüber, ob Ihr Dokumentationsprojekt in fünf Jahren skaliert oder in sich zusammenfällt. Alles andere — Tool-Auswahl, Publikationswege, Übersetzungsbudget, folgt dieser einen Entscheidung.

Das Muster, das mir regelmäßig begegnet

Ein mittelständischer Maschinenbauer produziert zwanzig Produktvarianten. Für jede Variante gibt es eine Bedienungsanleitung. Die Bedienungsanleitung existiert in PDF, in Word, zunehmend auch in HTML für die Web-Dokumentation. Mancher Kunde verlangt zusätzlich ein XML-Paket nach iiRDS.

Jede Variante wird separat gepflegt. In Word. Mit Copy-Paste aus dem Master-Dokument. Jede Produktänderung löst zwanzig redaktionelle Prozesse aus. Die Redaktion läuft dem Produkt permanent hinterher.

Das Unternehmen glaubt, es habe ein Redaktionsproblem. Und sucht nach mehr Personal, schnelleren Redakteuren, besseren Word-Vorlagen.

Das Problem liegt in der Datenhaltung, nicht in der Redaktion.

Ich habe in einer solchen Situation einmal nachgezählt: Von den acht Stunden, die eine Redakteurin täglich arbeitete, verbrachte sie knapp vier Stunden damit, identische oder nahezu identische Inhalte in verschiedenen Dokumenten zu pflegen. Nicht weil sie ineffizient war. Stattdessen weil die Struktur es ihr nicht anders erlaubte. Das ist der Normalzustand in Unternehmen, die ihre Datenhaltung nie grundlegend hinterfragt haben.

Was medienneutrale Datenhaltung tatsächlich bedeutet

Medienneutrale Datenhaltung heißt: Ein Inhalt wird genau einmal erfasst, strukturiert abgelegt und von dort aus automatisiert in jedes benötigte Zielmedium überführt. PDF, HTML, Mobile, Print, XML, Chatbot-Input, was auch immer morgen dazukommt.

Der Inhalt kennt sein Ausgabeformat nicht. Er kennt seine Bedeutung.

Das hat zwei unmittelbare Folgen.

Erstens: Eine Produktänderung führt zu genau einer redaktionellen Änderung. Nicht zu zwanzig. Die Publikation in alle Kanäle übernimmt das System.

Zweitens: Neue Kanäle kosten keine Neuproduktion. Wenn ein Kunde morgen iiRDS-konforme Daten fordert oder eine App ein mobiles Ausgabeformat braucht, ergänzen Sie einen Output-Weg, nicht zwanzig Anleitungen.

Klingt nach einer Selbstverständlichkeit. Ist in der Praxis die Ausnahme.

Warum ist das so? Nun, weil medienneutrale Datenhaltung unbequem startet. Sie verlangt am Anfang eine Entscheidung, bevor irgendein Tool im Spiel ist: Wie beschreibe ich meine Inhalte? Was ist das Einheitlichste, was alle meine Dokumente teilen? Das ist unbequemer als ein System einzukaufen, in das man bestehende Word-Dokumente hochlädt und hofft, dass es schon irgendwie funktioniert. Tut es nicht.

Warum „medienneutral“ ohne valides Datenmodell nicht trägt

Es reicht nicht, Inhalte in ein CCMS zu kippen und sich auf der Schulter zu klopfen. Wer Inhalte medienneutral halten will, braucht ein Datenmodell, das die Inhalte beschreibt. Und zwar präzise genug, damit ein System weiß, was es mit welchem Inhaltsbaustein tun darf.

Drei Ebenen müssen dafür modelliert sein.

Funktionale Metadaten. Was ist das für ein Inhalt? Eine Warnung? Ein Handlungsschritt? Eine Spezifikation? Ein Ersatzteilverweis? Ohne diese Unterscheidung kann das System keinen sinnvollen Satz über Ausgabeformate treffen. Eine Sicherheitswarnung muss anders behandelt werden als ein Werbetext, rechtlich und typografisch. Wer das nicht im Modell verankert, baut auf Sand.

Technische Metadaten. Wer hat den Baustein erstellt, wann, in welcher Version, mit welcher Freigabe? Wo liegt er? Wer darf ihn ändern? Ohne diese Spur haben Sie keine Revisionssicherheit. Und ohne Revisionssicherheit keine belastbare Technische Dokumentation im Sinne der einschlägigen Richtlinien. Kommen wir zu dem unangenehmen Teil: Bei einem Zwischenfall, der vor Gericht landet, wird gefragt, welche Version der Sicherheitshinweis zum Zeitpunkt der Auslieferung hatte. Wenn Sie das nicht lückenlos nachweisen können, haben Sie ein Problem, das weit über den Dokumentationsbereich hinausgeht.

Redaktionelle Metadaten. Welchem Produkt gehört der Baustein an? In welcher Sprache liegt er vor? Zu welchem Kapitel, welchem Modul, welcher Zielgruppe? Ohne diese Information ist „wiederverwendbar“ eine Behauptung, die in keinem Publikationslauf einlöst. Wiederverwendung funktioniert nur, wenn das System weiß, was es wohin spielen soll. Sonst haben Sie eine gut gemeinte Datenbank, aus der trotzdem manuell zusammengekopiert wird.

Wer eine dieser drei Ebenen weglässt, hat kein valides Modell. Eine Datei-Ablage mit Schlagworten ist etwas anderes als ein Datenmodell.

Der häufigste Einwand — und warum er nicht zieht

„Das ist zu viel Aufwand. Wir sind doch nur ein mittelständisches Unternehmen.“

Der Einwand ist nachvollziehbar und fast immer falsch. Der Aufwand liegt nicht im Aufbau des Modells. Er liegt in der Nicht-Entscheidung. Wer fünf Jahre lang zwanzig Bedienungsanleitungen parallel pflegt, hat das Datenmodell bereits bezahlt, nur dass er dafür nichts bekommt außer Pflege.

Der ehrliche Vergleich heißt: einmaliger Modell-Aufbau gegen fortlaufende manuelle Pflege in Redundanz. Der Vergleich fällt eindeutig aus, aber nur, wenn man ihn ehrlich rechnet.

Es gibt einen zweiten Einwand, den ich regelmäßig höre: „Wir haben das immer so gemacht, und es hat funktioniert.“ Das stimmt. Es hat funktioniert, solange die Produktpalette überschaubar war, die Übersetzungsanforderungen begrenzt blieben und kein Kunde iiRDS-Pakete verlangte. Sobald sich eine dieser drei Variablen ändert, und das tun sie in wachsenden Unternehmen immer — funktioniert es nicht mehr. Dann steht man vor einem Berg an Altdokumenten, dessen Migration Monate kostet, während das Produktgeschäft nicht wartet.

Die Frage, die am Anfang stehen muss

Wer ein Dokumentationsprojekt startet oder ein bestehendes System ablöst, sollte an den Anfang keine Tool-Frage stellen. Die Tool-Frage ist die falsche Frage, und sie ist zu früh.

Die erste Frage lautet: Wie sieht unser Datenmodell aus? Welche Inhaltstypen haben wir? Welche Metadaten brauchen wir, damit das Modell trägt, heute und in fünf Jahren?

Erst wenn diese Antwort steht, ist die Tool-Auswahl eine technische Übung. Vorher ist sie eine teure Wette.

Ich sage das ungern so zugespitzt, aber die meisten gescheiterten CCMS-Einführungen, die ich aus der Nähe gesehen habe, sind an genau dieser Reihenfolge gescheitert. Das Tool wurde entschieden, bevor das Modell stand. Danach wurde versucht, das Modell an das Tool anzupassen. Das Ergebnis ist vorhersehbar: Das System bildet die alten Prozesse digital ab, ohne sie zu verbessern. Man hat eine neue Oberfläche für das alte Problem.

Was das in der Praxis bedeutet

Ein valides Datenmodell aufzubauen muss keine monatelange Grundsatzarbeit sein. Ich empfehle einen pragmatischen Einstieg: Nehmen Sie fünf Ihrer häufigsten Dokumenttypen und listen Sie auf, welche Inhaltsbausteine darin regelmäßig identisch oder sehr ähnlich sind. Das sind Ihre Kandidaten für Wiederverwendung. Listen Sie dann auf, welche Attribute Sie brauchen, um diesen Baustein eindeutig zu identifizieren. Produktzugehörigkeit, Sprachversion, Freigabestatus, Gültigkeitsbereich. Das ist Ihr erstes Datenmodell.

Es ist nicht perfekt. Es wird sich weiterentwickeln. Aber es ist ein Fundament, auf dem man aufbauen kann. Und es zeigt Ihnen, welche Tool-Anforderungen Sie tatsächlich haben, bevor Sie in einer Anbieter-Demo nicken und einen Vertrag unterschreiben.

Groß planen, klein starten. Das gilt nirgendwo mehr als hier.

Medienneutralität und Übersetzungen

Ein Aspekt, der in dieser Diskussion zu selten vorkommt: der Hebel bei der Übersetzung. Sofern Ihre Dokumentation in mehrere Sprachen übertragen werden muss — und das ist im Maschinenbau, in der Medizintechnik und in der Elektrotechnik fast immer der Fall, vervielfacht sich der Schaden einer redundanten Datenhaltung sofort.

Zwanzig Varianten bedeuten bei drei Zielsprachen sechzig Übersetzungsprojekte. Wenn sich ein Sicherheitshinweis ändert, zahlen Sie die Übersetzung dieses Hinweises bis zu sechzigmal. Mit medienneutraler Datenhaltung und einem funktionierenden Translation-Memory-System zahlen Sie sie einmal — und das System erkennt beim nächsten Durchlauf, dass sich der Ausgangstext nicht verändert hat, und liefert die vorhandene Übersetzung.

Das ist unmittelbar messbares Einsparpotenzial. Und es ist ein Argument, das auch die Geschäftsleitung versteht.

Was eine Migration bedeutet — und wann sie sich lohnt

Irgendwann kommt die Frage: Was machen wir mit den bestehenden Dokumenten? Sie haben vielleicht hundert, vielleicht fünfhundert Anleitungen im alten Format. Vollständige Migration klingt nach einem klar definierten Projekt. In der Praxis ist es eine der schwierigsten Entscheidungen im gesamten Digitalisierungsvorhaben.

Meine Empfehlung: Migrieren Sie nicht um der Migration willen. Stellen Sie sich für jeden Bestand die Frage: Ist dieser Inhalt aktuell, validiert und wird er noch aktiv genutzt? Wenn ja, lohnt sich die Migration. Wenn nicht, lassen Sie ihn zunächst außen vor. Eine abgekündigte Produktlinie braucht keine migrierten Dokumente.

Wo Übersetzungen im Spiel sind, ist die Migrationsentscheidung meist eindeutig: Der Aufwand der Neuübersetzung, der entsteht, wenn Sie Inhalte neu erfassen statt migrieren erfassen, ist größer als der Migrationsaufwand, sofern die Ausgangstexte stabil sind. Nutzen Sie vorhandene Übersetzungen. Die Translation-Memory-Bestände, die in Ihrem Übersetzungsbüro oder in Ihrem TMS liegen, sind Kapital. Wer das wegwirft und von vorne anfängt, zahlt zweimal.

Und wenn Sie migrieren: Seien Sie ehrlich. Wenn eine Information auch in Word schon falsch war, ist sie im CCMS nicht richtiger. Nehmen Sie sich die Zeit, Inhalte bei der Migration zu prüfen und zu bereinigen. Das klingt nach Mehraufwand. Es ist weniger Aufwand als die Alternative — nämlich schlechte Inhalte in einem System zu pflegen, das eigentlich für Qualität gemacht wurde.

Was Sie von hier aus tun können

Wenn Sie diesen Artikel bis hier gelesen haben, sind Sie vermutlich in einer Situation, in der entweder ein Digitalisierungsprojekt ansteht oder Sie erkennen, dass die bisherige Datenhaltung an ihre Grenzen stößt.

Der konkrete erste Schritt ist nicht, einen CCMS-Anbieter anzurufen. Er ist, Ihre eigene Dokumentationslandschaft zu beschreiben: Wie viele Dokumenttypen haben Sie? Welche Inhalte tauchen regelmäßig in mehreren Dokumenten auf? Welche Ausgabeformate werden heute gefordert, und welche könnten in drei Jahren dazukommen?

Diese Beschreibung ist die Grundlage für jedes valide Datenmodell. Sie können sie intern erarbeiten, ohne externes Know-how. Und sie ist das Erste, was jeder ernsthafte Berater oder Anbieter von Ihnen verlangen wird, oder verlangen sollte. Wer sofort mit einer Tool-Demo beginnt, ohne diese Fragen gestellt zu haben, hat andere Interessen als Ihre.

---

Dieser Beitrag ist Teil einer Reihe zur Datenmodellierung in der Technischen Kommunikation. Folgeteile beschreiben Modellierungsentscheidungen im Detail, Migrationsmuster aus Word- und FrameMaker-Beständen und die Rolle von Standards wie DITA und iiRDS.

Weiterführende Standards und Branchen-Information bei der tekom — Gesellschaft für Technische Kommunikation.

Mehr zu konkreten Praxisfällen finden Sie in unserer Beitragsreihe zu Künstlicher Intelligenz und Technischer Dokumentation.