FrameMaker strukturiert: Der Weg Richtung DITA ohne Big Bang

Im Beitrag zum Duell FrameMaker gegen Word gab es einen dritten Ausgang im Entscheidungsbaum, der dort bewusst nur angerissen wurde: Wenn Varianten, Wiederverwendung, Sprachen und Kanäle der eigentliche Schmerz sind, ist die Werkzeugfrage die falsche Frage – dann geht es um Struktur. Für viele FrameMaker-Häuser klingt das nach einem gewaltigen Sprung: neues Paradigma, neues System, am Ende noch ein CCMS-Projekt mit sechsstelligem Budget. Und weil der Sprung so groß wirkt, wird er verschoben – Jahr für Jahr, während die Varianten-Kopien sich vermehren.

Die gute Nachricht dieses Artikels: Der Sprung ist gar keiner. FrameMaker trägt beide Welten in sich – das unstrukturierte Arbeiten mit Formaten, das du kennst, und das strukturierte Arbeiten mit Elementen, das der Weg Richtung DITA ist. Der Wechsel zwischen beiden ist kein Systemwechsel, sondern ein Stufenweg im vertrauten Werkzeug: Man kann strukturiert denken lernen, ohne eine Zeile zu migrieren, strukturiert schreiben, ohne den Bestand anzufassen, und den Bestand überführen, ohne den Betrieb zu unterbrechen. Big Bang ist keine Notwendigkeit – er ist ein Planungsfehler.

Dieser Artikel erklärt, was „strukturiert" wirklich bedeutet, bringt die berüchtigte EDD auf ein verständliches Maß – und liefert den Stufenplan, mit dem der Weg in Etappen gelingt, jede mit eigenem Nutzen.

Was „strukturiert" wirklich heißt

Der Begriff klingt nach Ordnung, und Ordnung hat man ja schon – schließlich gibt es Vorlagen, einen Styleguide und Disziplin. Aber strukturiertes Arbeiten ist etwas kategorial anderes als disziplinierte Formatierung, und der Unterschied lässt sich an einer Frage festmachen: Woher weiß das Dokument, was ein Absatz ist? Im unstrukturierten Dokument weiß es das nicht – es weiß nur, wie der Absatz aussieht. Dass der fett gerahmte Kasten eine Warnung ist, steht im Kopf des Autors und im Styleguide; das Dokument selbst kennt nur ein Absatzformat namens „Warnung", und nichts hindert jemanden, es für eine Randbemerkung zu missbrauchen oder die Warnung im Format „Hinweis" zu setzen.

Im strukturierten Dokument ist es umgekehrt: Der Inhalt lebt als Elementbaum, und jedes Element sagt explizit, was es ist – eine Warnung ist ein Warnungs-Element, ein Handlungsschritt ein Schritt-Element, verschachtelt nach Regeln, die ein Modell definiert. Das Aussehen ist eine Folge daraus, keine Eigenschaft des Textes. Für den Autor äußert sich das als geführtes Schreiben: An jeder Position im Baum bietet der Editor nur die Elemente an, die dort gültig sind – nach dem Titel die erlaubten Inhalte, im Handlungsschritt keinen zweiten Titel, in der Warnung das, was in Warnungen gehört. Man kann das Modell nicht aus Versehen verletzen; das Dokument ist jederzeit maschinell prüfbar gültig.

Daraus folgen die drei strategischen Gewinne. Erstens erzwungene Konsistenz: Der Aufbau stimmt nicht, weil alle diszipliniert waren, sondern weil das Modell nichts anderes zulässt – unabhängig von Tagesform, Zeitdruck und Personalwechsel. Zweitens Maschinenlesbarkeit: Der Elementbaum ist XML, also austauschbar, transformierbar, auswertbar – die Eintrittskarte für automatisierte Ausgaben, Systemwechsel ohne Neuerfassung und übrigens auch für alles, was KI-Werkzeuge mit sauber ausgezeichneten Inhalten anfangen können. Und drittens der Anschluss an die Topic-Welt: Strukturierte Inhalte lassen sich in Bausteine schneiden und mehrfach nutzen – das Grundprinzip, das der Beitrag zum topic-basierten Schreiben ausführlich erklärt, findet hier sein technisches Fundament.

Ein vierter Gewinn wird gern übersehen, weil er unscheinbar daherkommt: die Attribute. Elemente können Zusatzinformationen tragen – für welche Produktvariante ein Abschnitt gilt, für welche Zielgruppe, ab welchem Softwarestand. Damit wandern Metadaten dorthin, wo sie hingehören: an den Inhalt selbst statt in Dateinamen, Ordnerkonventionen oder das Gedächtnis der Kollegen. Variantensteuerung, gezielte Ausgaben und später auch jede systemische Auswertung setzen genau hier an – und auch dieser Hebel existiert im unstrukturierten Arbeiten schlicht nicht.

Und weil „maschinell prüfbar" abstrakt klingt, ein konkretes Bild: Im unstrukturierten Bestand prüft ein Mensch mit Checkliste, ob jede Handlungsanleitung eine Voraussetzung, nummerierte Schritte und ein Ergebnis hat – stichprobenweise, so weit die Zeit reicht. Im strukturierten Bestand prüft das die Validierung: flächendeckend, in Sekunden, bei jedem Speichern. Qualitätssicherung wandert damit von der Heldentat einzelner Sorgfältiger in den Maschinenraum – und die menschliche Prüfzeit gehört wieder dem Inhalt statt dem Aufbau.

Abb.: Vom Formatieren zum Auszeichnen – der Unterschied liegt nicht im Aussehen, sondern darin, wer die Regeln kennt: der Kopf oder das Modell.

Noch ein Wort zur Abgrenzung, weil die Begriffe im Alltag durcheinandergehen: Strukturiertes FrameMaker ist nicht dasselbe wie DITA, und beides ist nicht dasselbe wie ein CCMS. Strukturiert ist die Arbeitsweise – Elemente statt Formate. DITA ist ein konkretes, standardisiertes Strukturmodell, das FrameMaker fertig mitbringt. Und ein CCMS ist eine Verwaltungsschicht darüber, die man haben kann, aber lange nicht braucht. Wer die drei Begriffe sauber trennt, entdramatisiert die Entscheidung erheblich: Es geht zunächst nur um die Arbeitsweise – alles Weitere sind spätere, getrennte Fragen.

Die EDD-Grundidee – knapp und ohne Ehrfurcht

Wer sich strukturiertem FrameMaker nähert, stößt schnell auf drei Buchstaben, die in Foren mit einer Mischung aus Respekt und Schrecken behandelt werden: die EDD, das Element Definition Document. Die Grundidee ist deutlich unspektakulärer als ihr Ruf – die EDD ist Bauplan und Stilbuch in einem Dokument. Als Bauplan definiert sie die Strukturregeln: welche Elemente es gibt, was worin stecken darf, was Pflicht und was optional ist, in welcher Reihenfolge. Als Stilbuch definiert sie die Formatregeln: wie jedes Element aussieht – und zwar kontextabhängig, was der eigentliche Aha-Moment ist. Dieselbe Liste kann im Fließtext anders formatiert sein als innerhalb eines Warnhinweises, derselbe Titel auf Kapitelebene anders als auf Abschnittsebene – ohne dass der Autor auch nur einen Gedanken daran verschwendet. Er zeichnet aus, die EDD formatiert.

Damit ist auch klar, warum die EDD das Herzstück jeder Strukturanwendung ist: Sie ist die Stelle, an der Informationsmodell und Erscheinungsbild zusammengeführt werden – gewissermaßen das, was im unstrukturierten Arbeiten auf Styleguide, Vorlagensatz und Kopfwissen verteilt war, nur eben ausführbar. Und damit ist ebenso klar, warum man sie mit Respekt, aber ohne Ehrfurcht behandeln sollte: EDD-Entwicklung ist eine Expertendisziplin – wer ein eigenes Strukturmodell samt EDD von Grund auf baut, betreibt Informationsarchitektur und Regelwerks-Engineering zugleich, und das ist selten der richtige erste Schritt.

Die pragmatische Botschaft für den Einstieg lautet deshalb: Du musst keine EDD schreiben, um strukturiert zu arbeiten. FrameMaker bringt die DITA-Unterstützung als fertige Strukturanwendung mit – Modell, Regeln und Formatierung inklusive. Der Standard deckt die typischen Bedürfnisse Technischer Dokumentation ab und hat den unschätzbaren Vorteil, ein Standard zu sein: austauschbar, dokumentiert, mit Ökosystem. Ein eigenes Modell lohnt dort, wo Branchenstandards oder sehr spezielle Strukturen es verlangen – aber das ist die Ausnahme für später, nicht die Hürde am Anfang. Wer die Ehrfurcht vor der EDD als Einstiegsbarriere empfindet, darf sie getrost ablegen: Der Einstieg führt am Eigenbau vorbei. Das gilt übrigens auch für Anpassungswünsche an den Standard selbst: Erst sammeln, dann bewerten, dann – vielleicht – ändern. Die meisten Wünsche der ersten Monate erledigen sich, sobald das Team den Standard wirklich kennt.

Woher kommt eine EDD in der Praxis? In der DITA-Anwendung liegt sie fertig bei – das ist der Normalfall des Einstiegs. Darüber hinaus lassen sich Strukturmodelle aus vorhandenen Grammatiken ableiten, etwa wenn ein Haus- oder Branchenstandard als DTD oder Schema existiert; die EDD ist dann die FrameMaker-Ausprägung dieses Modells samt Formatierung. Wichtig für den Betrieb: Wo auch immer sie herkommt – die EDD ist ein gepflegtes Betriebsmittel mit Version und Verantwortlichem, kein Einmalartefakt. Änderungen am Modell sind Änderungen am Fundament und laufen entsprechend geordnet.

Abb.: Die EDD in einem Bild – Strukturregeln plus kontextabhängige Formatregeln ergeben das geführte Autorenerlebnis.

Warum überhaupt – und wann ehrlicherweise nicht

Bevor der Stufenplan kommt, die Nutzenfrage in aller Nüchternheit. Strukturiert lohnt sich, wenn mindestens einer dieser Hebel für dich zählt: Varianten und Wiederverwendung (Bausteine statt Kopien – jede Korrektur einmal statt siebenmal), Mehrsprachigkeit (konsistente, modulare Quellen senken Übersetzungskosten spürbar), Mehrkanal-Ausgabe (dieselbe Quelle für PDF, Online und was noch kommt), Verbindlichkeit (der Aufbau sicherheitsrelevanter Inhalte ist erzwungen statt erhofft) – und Zukunftsfähigkeit, denn XML-Quellen überleben Werkzeugmoden und füttern kommende Systeme, vom CCMS bis zum KI-Assistenten. Auffällig dabei: Keiner dieser Hebel belohnt Struktur um ihrer selbst willen – jeder übersetzt sich in gesparte Stunden oder vermiedene Fehler, und genau so gehört die Entscheidung auch gerechnet.

Der Übersetzungshebel verdient dabei eine eigene Zeile in der Rechnung, weil er sich am schnellsten in Geld übersetzt: Modulare, strukturell erzwungen konsistente Quellen liefern dem Translation Memory saubere, wiedererkennbare Segmente – und ein Baustein, der in vier Varianten wiederverwendet wird, wird eben nur einmal übersetzt statt viermal. Wer heute je Sprachfassung ganze Buchkopien durch die Übersetzung schickt, findet in dieser einen Zahl oft schon die halbe Begründung für den ganzen Weg.

Und wann nicht? Auch das gehört auf den Tisch, und zwar ohne Bedauern: Wer eine überschaubare Doku ohne nennenswerte Varianten in ein, zwei Sprachen pflegt und mit dem klassischen FrameMaker glücklich ist, gewinnt durch Struktur wenig und bezahlt trotzdem den Denkwechsel. Die Faustregel aus dem DITA-Beitrag – interessant wird strukturiertes Arbeiten ab etwa 300 Seiten, drei Varianten, zwei Sprachen – gilt sinngemäß auch hier; die ausführliche Lohnt-sich-Rechnung samt ehrlichem Nein-Szenario steht im Beitrag zur DITA-Frage für Mittelständler. Der Stufenweg hat allerdings einen Charme, den die Alles-oder-nichts-Betrachtung übersieht: Seine frühen Stufen lohnen sich fast immer – Strukturdenken und ein sauberes Informationsmodell verbessern jede Doku, auch die, die nie migriert wird.

Der Stufenplan: fünf Etappen, jede mit eigenem Nutzen

Damit zum Kern des Artikels. Der Stufenplan ist so gebaut, dass er drei Eigenschaften garantiert: Jede Stufe ist einzeln abschließbar – man kann nach jeder pausieren, ohne einen halbfertigen Zustand zu hinterlassen. Jede Stufe liefert eigenen Nutzen – selbst wer nach Stufe eins aufhört, hat eine bessere Doku als vorher. Und keine Stufe unterbricht den Betrieb – die Handbücher werden durchgehend ausgeliefert, Übersetzungen laufen weiter, niemand wartet auf ein Projektende.

Stufe null ist unglamourös und unverzichtbar: das saubere Fundament im Bestand. Konsistente Absatz- und Zeichenformate, aufgeräumte Vorlagen, keine wilden Sonderformate – das ist ohnehin gute Praxis, aber hier wird es zur Investition, denn die spätere Konvertierung wird exakt so gut, wie die Formatkonsistenz es erlaubt. Wer diese Stufe überspringt, bezahlt sie bei der Migration doppelt zurück. Praktischer Nebeneffekt: Diese Aufräumarbeit lohnt sich selbst dann vollständig, wenn der Weg später doch woanders hinführt.

Stufe eins ist der Denkwechsel – und er findet komplett ohne Werkzeug statt: das Informationsmodell auf Papier. Welche Informationsbausteine hat deine Doku wirklich – Handlungsanleitungen, Beschreibungen, Referenzen, Warnungen? Wie granular sollen sie sein, wie heißen sie, was gehört in welchen Baustein? Das ist Informationsarchitektur im Kleinen, gespeist aus der Topic-Denkweise, und sie ist die eigentliche Umstellung: Wer sein Modell kennt, für den ist die spätere Strukturanwendung nur noch die technische Ausprägung. Wer es nicht kennt, für den ist jedes Werkzeug ein Rätsel. Stufe zwei macht die Sache dann konkret: ein strukturierter Pilot – ein kleines, echtes Dokument, neu aufgesetzt in der mitgelieferten DITA-Anwendung. Hier erlebt das Team geführtes Schreiben, hier werden Ausgaben getestet, hier zeigt sich, wo das Papiermodell und der Standard sich reiben. Der Pilot ist bewusst neu geschrieben statt migriert – erst das Arbeiten lernen, dann das Umziehen.

Stufe drei ist die Migration nach Priorität – dazu gleich ein eigenes Kapitel zur Mechanik. Entscheidend ist hier das Prinzip: Es wandert, was die Reise verdient – Dokumente mit hoher Änderungs- und Übersetzungsfrequenz zuerst, ruhender Bestand bleibt unstrukturiert liegen und wird bei Bedarf aus dem Archiv bedient. Die Koexistenz beider Welten im selben Werkzeug ist dabei kein Provisorium, sondern der Normalzustand des Übergangs – mit einer klaren Landkarte, welches Werk wo lebt. Und Stufe vier ist der Betrieb mit Ausbau: Wiederverwendung systematisch nutzen, Varianten über Bausteine statt Kopien steuern, Ausgaben automatisieren. Erst auf dieser Stufe stellt sich sinnvollerweise die CCMS-Frage – wenn Topic-Mengen, Verweise und Team-Zugriffe die Dateiverwaltung sprengen. Sie stellt sich wohlgemerkt vielleicht: Viele Redaktionen arbeiten dauerhaft gut strukturiert ohne CCMS.

Zwei Betriebsregeln machen Stufe drei berechenbar. Erstens die Abnahme: Jedes migrierte Werk wird gegen seine bisherige Ausgabe abgenommen – Ausgabe aus der neuen Strukturwelt neben die letzte unstrukturierte Fassung, Stichprobenplan quer durchs Werk, dokumentiertes Ergebnis. Erst dann wird die alte Quelle eingefroren; ab diesem Moment gibt es je Werk genau eine Wahrheit. Zweitens ehrliche Zeit-Hausnummern: Der Modell-Workshop ist ein Nachmittag, der Pilot eine Sache von Wochen, die Migration eines gepflegten Werks je nach Umfang Tage bis wenige Wochen – und ein Gesamtvorhaben mittlerer Größe spielt sich eher in Monaten ab als in Wochen. Wer das in den Redaktionskalender einträgt, nimmt dem Weg den Druck, aus dem Big-Bang-Fehler entstehen.

Abb.: Fünf Stufen statt eines Sprungs – und die CCMS-Frage steht ganz am Ende, nicht am Anfang.

Die Migration im Maschinenraum: Konvertierungstabellen

Für die Überführung des Bestands bringt FrameMaker ein bewährtes Instrument mit: die Konvertierungstabelle. Ihr Prinzip ist herrlich unmagisch – sie ist eine Zuordnungsliste: Welches Absatz- und Zeichenformat des unstrukturierten Dokuments wird zu welchem Element des Strukturmodells? Der Titel-Absatz wird zum Titel-Element, das Handlungsschritt-Format zum Schritt-Element, das Warnungs-Format zum Warnungs-Element samt Umgebung. Auf dieser Grundlage baut das Werkzeug aus dem formatierten Text den Elementbaum. Damit ist auch sonnenklar, warum Stufe null so betont wurde: Die Zuordnung kann nur so eindeutig sein wie die Formatlandschaft. Ein Dokument, in dem „Warnung", „WarnungAlt" und händisch gefetteter Fließtext dieselbe Rolle spielen, liefert der Tabelle Rätsel statt Regeln – und produziert Nacharbeit statt Struktur.

Der bewährte Arbeitsmodus ist iterativ und beginnt klein: ein repräsentatives Kapitel, erste Fassung der Tabelle, konvertieren, Ergebnis gegen das Modell validieren, Befunde in die Tabelle zurückspielen – und wieder von vorn, bis das Kapitel sauber durchläuft. Erst dann kommt das ganze Werk an die Reihe, und erst nach dessen Abnahme das nächste. Ehrlichkeit gehört dazu: Eine Restnacharbeit bleibt praktisch immer – Stellen, an denen die Quelle mehrdeutig war, Strukturen, die das Format nicht hergab, Grenzfälle des Modells. Diese Nacharbeit ist kein Scheitern der Methode, sondern ihr letzter Schritt; wer sie einplant, erlebt sie als Fleißarbeit, wer sie verdrängt, als Krise. Und ein Trost aus der Praxis: Die zweite Konvertierung ist immer drastisch schneller als die erste, weil Tabelle und Erfahrungswissen mitwachsen.

Zur Auswahl dessen, was überhaupt konvertiert wird, lohnt ein kühler Blick: Nicht jedes Dokument verdient die Reise. Die Priorität folgt der Änderungs- und Übersetzungsfrequenz – was lebt, zieht um; was ruht, bleibt als eingefrorener Bestand in der alten Welt und wird bei Bedarf von dort ausgeliefert. Auch innerhalb der Werke darf entrümpelt werden: Die Migration ist wie jede Migration eine Aufräumgelegenheit, und tote Kapitel konvertiert man am schnellsten, indem man sie vorher streicht. Aus demselben Grund gehört vor die Konvertierung eine kurze Inventur: Was wird wirklich noch gebraucht, was ist Erblast mit Formaten von 2009?

Abb.: Die fünf Schritte der Bestandsmigration – der unscheinbare zweite entscheidet über die Qualität des vierten.

Der Denkwechsel im Team – und die Koexistenz im Betrieb

Die größte Umstellung des ganzen Wegs ist keine technische: Es ist der Rollenwechsel des Autors vom Gestalter zum Auszeichner. Jahrelang bestand ein Teil des Handwerks darin, Dinge gut aussehen zu lassen – jetzt übernimmt das die Strukturanwendung, und der Autor konzentriert sich darauf, Inhalte richtig zu benennen und aufzubauen. Für manche ist das eine Befreiung, für andere fühlt es sich zunächst wie Entmachtung an: „Ich kann mein Layout nicht mehr anfassen" ist der meistgehörte Einwand – und die ehrliche Antwort lautet: genau, das ist der Punkt. Konsistenz entsteht, weil niemand mehr lokal am Aussehen dreht. Wer diesen Einwand ernst nimmt, ihn offen bespricht und im Pilot erlebbar macht, was man dafür bekommt, hat den Denkwechsel halb gewonnen; wer ihn übergeht, bekommt stille Verweigerung. Erfahrungsgemäß kippt die Stimmung im Pilot – spätestens, wenn der erste Kollege merkt, dass er einen Warnhinweis nicht mehr falsch bauen kann und das Ergebnis trotzdem besser aussieht als früher.

Praktisch heißt das: Schulung als fester Bestandteil des Stufenplans – nicht als Werkzeugkunde, sondern als Modellkunde: Was ist ein Handlungsschritt, was eine Beschreibung, wo verläuft die Grenze? Dazu eine benannte Verantwortung für das Modell und die Strukturanwendung – eine Person, bei der Modellfragen, Erweiterungswünsche und die Pflege der Konvertierungstabellen zusammenlaufen, damit das Regelwerk nicht per Flurfunk erodiert. Beides ist kein Großprojekt: ein Schulungstag, eine Rollenbeschreibung – aber ohne beides bleibt die Struktur ein Projekt der zwei Kollegen, die sie eingeführt haben.

Und schließlich die Koexistenz, denn sie ist jahrelang Realität: strukturierte und unstrukturierte Werke leben nebeneinander im selben Werkzeug. Das funktioniert reibungslos mit einer dokumentierten Landkarte – welches Werk lebt in welcher Welt, was ist eingefroren, was wandert als Nächstes – und mit unveränderten Außenprozessen: Reviews laufen weiterhin über ausgeleitete PDFs mit Kommentaren, die Fachabteilung merkt vom Strukturwechsel im Idealfall gar nichts außer der gestiegenen Konsistenz. Die Landkarte gehört einmal im Jahr auf den Prüfstand, zusammen mit der Frage, ob die nächste Migrationswelle ansteht – so bleibt der Stufenweg ein gesteuerter Prozess statt einer ewigen Baustelle. Und falls irgendwann doch ein CCMS oder ein anderes System ansteht: Die strukturierte XML-Quelle ist dann die beste Mitgift, die eine Redaktion mitbringen kann – nichts migriert leichter als das, was schon ein Modell hat.

Fazit

Der Weg von unstrukturiertem FrameMaker Richtung DITA ist kein Sprung über eine Schlucht, sondern eine Treppe im eigenen Haus: Formatfundament, Strukturdenken, Pilot, priorisierte Migration, Betrieb – jede Stufe abschließbar, jede mit eigenem Ertrag. Die EDD verliert dabei ihren Schrecken, sobald man sie als das nimmt, was sie ist – Bauplan und Stilbuch in einem, für den Einstieg fertig mitgeliefert im DITA-Standard. Und die Konvertierungstabelle macht aus der Bestandsmigration ein iteratives Handwerk statt eines Abenteuers, dessen Qualität du selbst in der Hand hast: Sie heißt Formatkonsistenz. Und der vielleicht wichtigste Befund des ganzen Wegs ist ein psychologischer: Die frühen Stufen kosten fast nichts und nützen fast immer – wer mit dem Textmarker-Nachmittag beginnt, hat noch nichts riskiert und schon gewonnen.

Der beste erste Schritt kostet einen Nachmittag: drei Dokumente, Textmarker, das Modell auf einer Seite – und danach die ehrliche Lohnt-sich-Rechnung entlang deiner Varianten, Sprachen und Änderungsfrequenzen. Wenn du dabei Unterstützung willst – vom Modell-Workshop über den Pilot bis zur Konvertierung des Bestands: Genau dabei unterstütze ich dich gern; die Details findest du auf der Beratungsseite zur Technischen Dokumentation.

Häufige Fragen zum strukturierten FrameMaker

Was unterscheidet strukturiertes Arbeiten von disziplinierten Vorlagen?

Die Verbindlichkeit und die Bedeutung. Vorlagen beschreiben, wie Inhalte aussehen sollen – ob sie richtig eingesetzt werden, hängt an der Disziplin der Autoren. Im strukturierten Dokument tragen Elemente die Bedeutung explizit, und das Modell erzwingt den gültigen Aufbau: An jeder Position sind nur die dort erlaubten Elemente wählbar, das Ergebnis ist maschinell prüfbar und als XML austauschbar. Kurz: Vorlagen empfehlen, Strukturen garantieren.

Was ist eine EDD – in einem Absatz?

Das Element Definition Document ist das Regelwerk einer FrameMaker-Strukturanwendung und vereint zwei Rollen: Als Bauplan definiert es, welche Elemente es gibt und wie sie sich verschachteln dürfen; als Stilbuch legt es fest, wie jedes Element formatiert wird – auch kontextabhängig, sodass dieselbe Liste im Warnhinweis anders aussieht als im Fließtext. Für den Einstieg musst du keine EDD schreiben: Die mitgelieferte DITA-Anwendung bringt Modell und Formatierung fertig mit.

Müssen wir gleich „richtiges" DITA machen?

Strukturiert und DITA sind nicht dasselbe – FrameMaker kann auch eigene Strukturmodelle. Praktisch ist die mitgelieferte DITA-Anwendung aber der empfehlenswerte Einstieg: Sie ist fertig, deckt die typischen Doku-Bedürfnisse ab und ist als Standard austauschbar und zukunftssicher. Ein eigenes Modell lohnt nur bei speziellen Anforderungen – und sinnvoll entscheiden lässt sich das erst, nachdem das Team Erfahrung mit dem Standard gesammelt hat.

Wie kommen unsere Bestandsdokumente in die Struktur?

Über Konvertierungstabellen: Sie ordnen die Absatz- und Zeichenformate des unstrukturierten Dokuments den Elementen des Strukturmodells zu, und FrameMaker baut daraus den Elementbaum. Der bewährte Weg ist iterativ – repräsentatives Kapitel, Tabelle verfeinern, validieren, dann das ganze Werk – und beginnt mit Formatbereinigung, denn die Konvertierung wird nur so gut wie die Konsistenz der Quelle. Eine planbare Restnacharbeit bleibt und gehört zum Verfahren.

Brauchen wir dafür ein CCMS?

Nicht für den Einstieg – der ganze Stufenweg bis einschließlich Migration und Betrieb funktioniert dateibasiert im vertrauten Werkzeug. Die CCMS-Frage stellt sich erst auf der letzten Stufe, wenn Topic-Mengen, Verweisnetze und paralleler Team-Zugriff die Dateiverwaltung sprengen – und auch dann ist die Antwort nicht automatisch ja. Viele mittelständische Redaktionen arbeiten dauerhaft gut strukturiert ohne CCMS; entscheidend sind Bestandsgröße, Teamgröße und Prozessreife.