Fallstudie: Word-Ausgabe nach Firmenvorgaben bei einem Konsumgüterhersteller

Manche Probleme sind interessant, weil sie schwierig sind. Und manche sind interessant, weil sie einfach sind – und trotzdem drei Wochen gekostet haben. Dieser Fall gehört in die zweite Kategorie, und genau deshalb lohnt es sich, ihn zu erzählen: Er zeigt weniger über RoboHelp als über die Art, wie man Fehler sucht.

Die Ausgangslage: Ein Konsumgüterhersteller aus Ostdeutschland, mittelständisch, mit einer umfangreichen Online-Hilfe in RoboHelp. Aus derselben Quelle sollte zusätzlich ein Handbuch als Word-Dokument entstehen – im Corporate Design des Hauses, mit der offiziellen Dokumentvorlage, wie sie auch für Angebote und Berichte verwendet wird. Eine Anforderung, die alltäglich klingt und es auch ist.

Was daraus wurde, waren drei Wochen Fehlersuche mit wechselnden Hypothesen, mehreren Sackgassen und wachsender Frustration – und am Ende eine Korrektur, die fünf Minuten dauerte. Dieser Beitrag erzählt den Verlauf, benennt die Sackgassen und zieht sechs Lehren daraus. Wer die technische Anleitung sucht, wie man die Word-Ausgabe aus RoboHelp einrichtet, findet sie im eigenen Beitrag dazu – hier geht es um die Geschichte und das, was man daraus lernen kann.

★ Fakten kompakt Die Word-Ausgabe aus RoboHelp läuft über eine Zuordnung von Quellstilen zu Word-Formatvorlagen Fehlt eine Zuordnung, greift eine Ersatzregel – ohne Fehlermeldung, ohne Warnung Der Fehler ist im Ergebnis sichtbar, aber die Ursache liegt in einer Tabelle, die man öffnen muss Diagnose-Regel: Im erzeugten Word-Dokument nachsehen, welche Formatvorlage tatsächlich zugewiesen ist Am Projekt-Stylesheet zu drehen, um die Word-Ausgabe zu reparieren, verschlechtert die Online-Hilfe Nachbearbeitung per Makro löst das Problem nicht, sondern verschiebt es in die Wartung

 

Ein Wort zur Abgrenzung, weil dieser Beitrag bewusst eine Geschichte erzählt und keine Anleitung ist: Wie man die Word-Ausgabe technisch einrichtet — welche Einstellungen es gibt, wie die Zuordnung angelegt wird, worauf bei der Dokumentvorlage zu achten ist —, steht im eigenen Beitrag dazu. Hier geht es um den Verlauf und darum, was man aus einer misslungenen Fehlersuche mitnehmen kann. Beides zusammen ergibt das vollständige Bild: die Anleitung für den Aufbau, die Fallstudie für den Ernstfall.

Woche 0: die Anforderung

Der Auslöser war banal. Das Produkt bekam eine größere Version, und mit ihr sollte erstmals ein gedrucktes Handbuch für Schulungen erscheinen – zusätzlich zur Online-Hilfe, die es seit Jahren gab. Die Vorgabe kam aus dem Marketing: Das Dokument müsse dem Corporate Design entsprechen, also die Dokumentvorlage des Hauses verwenden, mit den dort definierten Schriften, Farben, Abständen und Kopfzeilen.

In der Redaktion war das kein Grund zur Sorge. RoboHelp bringt eine Word-Ausgabe mit, die Firmenvorlage lag vor, die Inhalte waren ohnehin da. Die Aufgabe wurde großzügig mit einem halben Tag veranschlagt – Vorlage hinterlegen, Ausgabe erzeugen, fertig. Genau so ging es auch los: Die Ausgabe wurde eingerichtet, die Dokumentvorlage zugewiesen, der Erzeugungslauf gestartet.

Das Ergebnis sah zu neunzig Prozent richtig aus. Überschriften saßen, Fließtext stimmte, Kopf- und Fußzeilen kamen aus der Firmenvorlage. Falsch waren einige Absatzarten: Hinweise und Handlungsschritte erschienen in einer Formatierung, die mit der Firmenvorlage nichts zu tun hatte – falsche Schrift, falsche Einrückung, kein Abstand. Ein Fehlerbild, das nach einer Kleinigkeit aussah — nach etwas, das in zehn Minuten behoben wäre. Und genau das war der Anfang des Problems.

Vorab eine Einordnung zur Ausgangslage, weil sie erklärt, warum niemand misstrauisch wurde: Die Online-Hilfe aus demselben Projekt sah seit Jahren einwandfrei aus. Dieselben Inhalte, dieselben Stile, dasselbe Projekt — nur eben ein anderer Ausgabeweg. Wenn eine Ausgabe funktioniert und die andere nicht, liegt der Gedanke nahe, dass es an der zweiten Ausgabe liegen muss. Das stimmte sogar; nur suchte man den Fehler dann in der Ausgabekonfiguration statt in der Zuordnung, die zu ihr gehört.

Woche 1 bis 3: die Sackgassen

Die erste Hypothese lag nahe: Wenn die Formatierung nicht der Firmenvorlage entspricht, stimmt womöglich etwas mit der Firmenvorlage nicht. Also wurde sie geprüft, dann eine ältere Fassung getestet, dann eine bereinigte Kopie. Drei Varianten, drei Erzeugungsläufe, dasselbe Ergebnis. Der Befund hätte stutzig machen können – wenn die Vorlage nie einen Unterschied macht, liegt es vermutlich nicht an ihr. Stattdessen führte er zur nächsten Hypothese.

Die zweite: Vielleicht liegt es an der Formatierung im Projekt selbst. Also wurde am Stylesheet gedreht – die betreffenden Stile bekamen andere Eigenschaften, in der Hoffnung, dass sich das auf die Word-Ausgabe durchschlägt. Das tat es nicht in der gewünschten Weise, dafür verschlechterte es die Online-Hilfe, die bis dahin einwandfrei aussah. Nach zwei Tagen wurden die Änderungen zurückgenommen – ein Verlust ohne Erkenntnisgewinn, abgesehen von der wichtigen Einsicht, dass beide Ausgaben nicht dieselben Stellschrauben teilen.

Die dritte Hypothese lautete: Die Ausgabekonfiguration ist beschädigt. Also wurde sie gelöscht und neu angelegt, sorgfältig, mit allen Einstellungen von Hand. Das Ergebnis war identisch – was ebenfalls ein sehr aussagekräftiger Befund gewesen wäre, wenn ihn jemand als solchen gelesen hätte. Denn wenn eine frisch angelegte Konfiguration denselben Fehler produziert, liegt der Fehler nicht in der Konfiguration, sondern in etwas, das mit ihr zusammen entsteht.

Abb.: Der Verlauf über vier Wochen – der eigentliche Aufwand lag im Suchen, nicht im Beheben.

Die vierte Sackgasse: hinterher reparieren

Nach zweieinhalb Wochen kam der Punkt, an dem der Pragmatismus siegte: Wenn das Werkzeug es nicht richtig macht, machen wir es eben hinterher. Es entstand ein Word-Makro, das nach dem Erzeugen die betroffenen Absätze suchte und ihnen die richtige Formatvorlage zuwies. Das funktionierte – und war für einen Moment eine Erleichterung, weil endlich ein brauchbares Dokument vorlag.

Die Erleichterung hielt bis zur nächsten Fassung. Beim zweiten Durchlauf tauchte ein Absatztyp auf, den das Makro nicht kannte, weil er beim ersten Mal nicht vorkam. Also wurde das Makro erweitert. Beim dritten Durchlauf machte es eine Kollegin, die das Makro nicht kannte, und lieferte ein Dokument aus, das die Nachbearbeitung nie gesehen hatte. Spätestens hier war klar, was dieser Ansatz war: keine Lösung, sondern eine dauerhafte Wartungsaufgabe, die an einer einzelnen Person hängt.

Was alle vier Sackgassen eint, ist bemerkenswert: Sie setzen dort an, wo das Problem sichtbar ist – im erzeugten Dokument, in der Vorlage, in der Ausgabekonfiguration. Keine von ihnen fragte danach, wo das Problem entstanden ist. Und je mehr Zeit investiert war, desto plausibler wirkte jede weitere Variante desselben Vorgehens: Man hatte schließlich schon so viel probiert, da musste die Lösung doch in derselben Richtung liegen.

Abb.: Vier Ansätze, ein gemeinsamer Denkfehler – alle setzen am Symptom an.

Zwischendurch wurde auch der Hersteller-Support kontaktiert — was naheliegend war und wenig brachte, allerdings nicht aus Unwilligkeit. Die Rückfrage lautete sinngemäß, ob die Stilzuordnung vollständig gepflegt sei; die Antwort aus der Redaktion war ein überzeugtes Ja, weil man die Ausgabe ja mehrfach neu angelegt hatte. Damit war die entscheidende Spur nach zwei Sätzen wieder verlassen. Rückblickend ist das der lehrreichste Moment des ganzen Vorgangs: Die richtige Frage war gestellt worden — und wurde falsch beantwortet, weil niemand nachgesehen hatte.

Woche 4: der Wendepunkt

Der Durchbruch kam durch eine andere Frage. Statt zu fragen „Warum sieht dieser Absatz falsch aus?“, wurde gefragt: „Welche Formatvorlage trägt dieser Absatz eigentlich im erzeugten Dokument?“ Das ist keine Zauberei – man setzt in Word den Cursor in den betreffenden Absatz und liest ab, welche Formatvorlage zugewiesen ist. Zwei Klicks, jederzeit möglich, und in drei Wochen intensiver Fehlersuche hatte es niemand getan.

Die Antwort war aufschlussreich: Die betroffenen Absätze trugen nicht etwa eine falsch definierte Firmenvorlage, sondern eine Formatvorlage mit einem Namen, der in der Firmenvorlage gar nicht vorkam. Das änderte die ganze Fragestellung. Es ging nicht darum, warum eine Formatvorlage falsch aussah – es ging darum, warum überhaupt diese Formatvorlage verwendet wurde und nicht die vorgesehene.

Damit war die Suche plötzlich zielgerichtet. Zwischen dem Stil im Topic und der Formatvorlage im Word-Dokument liegt eine Zuordnung: eine Tabelle, die festlegt, welcher Quellstil zu welcher Word-Formatvorlage wird. In dieser Tabelle fehlten Einträge für genau die Stile, die falsch dargestellt wurden. Und wo ein Eintrag fehlt, greift eine Ersatzregel – der Absatz landet in einer Standardvorlage. Ohne Fehlermeldung, ohne Warnung, ohne Hinweis darauf, dass hier etwas nicht zugeordnet ist.

Abb.: Vier Stationen – drei davon sichtbar, und die vierte war es, die den Fehler enthielt.

Hypothese	Was geprüft wurde	Was der Befund bedeutet hätte
Firmenvorlage defekt	Drei Vorlagenvarianten getestet	Kein Unterschied heißt: nicht die Ursache
Stylesheet falsch	Projektstile geändert	Wirkt auf die Online-Hilfe, nicht auf Word
Konfiguration beschädigt	Ausgabe neu angelegt	Gleicher Fehler heißt: liegt woanders
Word macht es falsch	Makro zur Nachbearbeitung	Funktioniert, aber löst nichts
Zuordnung unvollständig	Abbildungstabelle geöffnet	Treffer – fehlende Einträge
Alle Hypothesen	Vom Ergebnis rückwärts geprüft	Hätte in zwei Stunden zum Ziel geführt

 

Die Lösung

Der Rest war unspektakulär. Die fehlenden Zuordnungen wurden ergänzt – jeder Quellstil bekam eine Word-Formatvorlage aus der Firmenvorlage zugewiesen. Dann wurde die Ausgabe erneut erzeugt, und das Dokument sah aus, wie es aussehen sollte: Hinweise als Hinweise, Handlungsschritte als Handlungsschritte, alles im Corporate Design. Der Aufwand für die eigentliche Korrektur lag bei wenigen Minuten — nach drei Wochen Suche.

Anschließend wurde noch eine Vollständigkeitsprüfung gemacht, und die förderte weitere Lücken zutage: Stile, die im Projekt existierten, aber im aktuellen Handbuch nicht vorkamen und deshalb nicht aufgefallen waren. Sie wurden gleich mit zugeordnet – eine Vorsorge, die sich beim nächsten Handbuch auszahlte, als ein bislang ungenutzter Stil zum ersten Mal verwendet wurde und einfach richtig erschien.

Und die Zuordnungstabelle bekam einen Platz in der Projektdokumentation. Nicht als Bildschirmfoto, sondern als Liste: Quellstil, Zielvorlage, Bemerkung. Diese Liste ist seitdem Bestandteil der Übergabe an neue Kollegen – und sie ist der Ort, an dem beim Anlegen eines neuen Stils der zugehörige Eintrag ergänzt wird, bevor jemand die Ausgabe erzeugt und sich über das Ergebnis wundert.

Bemerkenswert ist auch, was der Fall nicht war: kein Werkzeugfehler, kein Versionsproblem, keine kaputte Installation. Alle Beteiligten hatten sauber gearbeitet — das Projekt war gepflegt, die Firmenvorlage in Ordnung, die Ausgabe korrekt eingerichtet. Was fehlte, waren einzelne Zeilen in einer Tabelle, die beim Anlegen neuer Stile über die Jahre schlicht nicht mitgepflegt worden war. Genau deshalb taugt der Fall als Lehrstück: Er entstand nicht durch Nachlässigkeit, sondern durch eine Lücke im Prozess, die niemandem auffiel, solange die Word-Ausgabe nicht gebraucht wurde.

Wie kam es überhaupt zu der Lücke? Diese Frage wurde im Nachgang gestellt, und die Antwort ist unspektakulär: Die Zuordnung war beim ersten Aufsetzen des Projekts vollständig — für die damals vorhandenen Stile. In den Jahren danach kamen Stile hinzu, weil neue Inhaltsarten gebraucht wurden: ein Hinweiskasten, ein Handlungsschritt mit Nummerierung, später ein Codeblock. Jeder dieser Stile wurde im Projekt angelegt und in der Online-Hilfe formatiert. Die Zuordnung für die Word-Ausgabe pflegte niemand mit, weil diese Ausgabe jahrelang nicht verwendet wurde.

Damit ist der Fall im Kern ein Prozessproblem und kein technisches: Ein Artefakt, das nur bei einem selten genutzten Ausgabeweg gebraucht wird, veraltet unbemerkt. Dasselbe Muster kennt man von Sicherungskonzepten, die nie geprüft werden, und von Notfallplänen, die niemand liest. Die Gegenmaßnahme ist in allen Fällen dieselbe: eine regelmäßige Probe. Wer die Word-Ausgabe einmal im Quartal über das Musterdokument laufen lässt, findet die Lücke in dem Moment, in dem sie entsteht — und nicht drei Jahre später unter Termindruck.

Warum es so lange dauerte

Die interessantere Frage ist nicht, wie der Fehler behoben wurde, sondern warum er drei Wochen brauchte. Drei Faktoren spielten zusammen. Der erste ist die Sichtbarkeit: Von den vier Stationen der Kette sind drei sichtbar – der Stil im Topic, die Firmenvorlage, das Ergebnis. Die Zuordnung dazwischen sieht man nur, wenn man sie ausdrücklich öffnet. Sie war nicht versteckt; sie war nur nicht im Blickfeld.

Der zweite Faktor ist die fehlende Rückmeldung. Ein Erzeugungslauf, der bei einer fehlenden Zuordnung eine Warnung ausgibt – „Für Stil X ist keine Zielvorlage definiert, es wird die Standardvorlage verwendet“ –, hätte das Problem in Minuten gelöst. Stattdessen läuft der Vorgang durch und liefert ein Ergebnis, das falsch ist, aber nicht als fehlerhaft erkennbar. Das ist kein Vorwurf an ein bestimmtes Werkzeug: Stille Ersatzregeln sind in Publishing-Ketten weit verbreitet, und sie sind eine der häufigsten Ursachen für lange Fehlersuchen.

Der dritte Faktor ist psychologisch und der eigentlich lehrreiche: die Selbstverstärkung des eingeschlagenen Wegs. Nach der ersten Sackgasse war die zweite naheliegend, nach der zweiten die dritte – jede weitere Variante wirkte plausibler, weil bereits so viel investiert war. Der Gedanke „vielleicht suche ich an der völlig falschen Stelle“ kommt in dieser Phase am seltensten in den Sinn, obwohl er in diesem Moment mit Abstand am nützlichsten wäre.

⚠ Warnung: Die Zwei-Stunden-Regel Wenn eine Fehlersuche in einer Publishing-Kette länger als etwa zwei Stunden dauert, ohne dass sich das Bild ändert, ist die Wahrscheinlichkeit hoch, dass an der falschen Stelle gesucht wird. Weiterprobieren hilft dann nicht — es verstärkt nur die Bindung an die aktuelle Hypothese, weil man mit jedem Versuch mehr Zeit investiert hat. Die Gegenmaßnahme ist ein bewusster Wechsel des Vorgehens: nicht mehr Varianten testen, sondern die Kette von hinten aufrollen und an jeder Station fragen, was hier ankommt und was herausgeht. Diese Umstellung fühlt sich wie ein Rückschritt an — man gibt eine Hypothese auf, in die man Zeit gesteckt hat. Sie ist trotzdem in aller Regel der deutlich kürzere Weg zum Ziel.

 

Auch die Kosten lohnen eine Betrachtung, ohne Zahlen zu nennen. Drei Wochen Fehlersuche binden nicht drei Wochen Arbeitszeit — die Redaktion arbeitete parallel weiter —, aber sie binden Aufmerksamkeit, verzögern einen Termin und erzeugen Unruhe im Haus. Das Handbuch war für eine Schulungsreihe eingeplant; die Verschiebung musste erklärt werden. Und der eigentliche Schaden ist schwer zu beziffern: Nach einer solchen Erfahrung sinkt die Bereitschaft, weitere Ausgabewege einzurichten — obwohl das Werkzeug es könnte und das Problem nie im Werkzeug lag.

Genau dieser Nebeneffekt ist der teuerste. In mehreren Häusern lässt sich beobachten, dass eine einzelne schlechte Erfahrung mit einem Ausgabeweg jahrelang nachwirkt: Man bleibt beim Bekannten, verzichtet auf zusätzliche Formate und baut lieber von Hand nach, weil „das damals ja nicht funktioniert hat“. Eine sauber dokumentierte Ursache hätte diesen Effekt verhindert — sie hätte gezeigt, dass es an einer Lücke lag und nicht an der Technik.

Zur Übertragbarkeit noch eine Beobachtung aus anderen Häusern: Dasselbe Problem tritt regelmäßig auf, wenn ein Projekt den Besitzer wechselt. Wer eine gewachsene Werkzeugkette übernimmt, kennt die Zuordnungen nicht, die sein Vorgänger im Kopf hatte — und stellt beim ersten ungewohnten Ausgabeweg fest, dass Dokumentation über die Kette selbst fehlt. Deshalb gehört bei jeder Übergabe nicht nur das Projekt weitergereicht, sondern auch die Beschreibung dessen, was zwischen den Stationen passiert.

Praktisch heißt das: eine Seite je Ausgabeweg. Welche Stationen gibt es, welche Konfigurationsdateien gehören dazu, wo liegen sie, was ist beim Anlegen neuer Stile zu tun? Diese Seite entsteht in einer Stunde, wenn jemand die Kette gerade im Kopf hat — und sie ist unbezahlbar, wenn dieser Jemand das Haus verlassen hat. Im geschilderten Fall existierte sie nicht, und das war neben der fehlenden Pflege der zweite Grund, warum niemand wusste, wo zu suchen war.

Sechs Lehren

Erstens: vom Ergebnis rückwärts suchen. Die erste Frage bei einem Formatierungsproblem lautet nicht „warum sieht das falsch aus“, sondern „was steht hier tatsächlich“. Welche Formatvorlage trägt der Absatz im erzeugten Dokument? Diese Frage kostet zwei Klicks und schneidet die halbe Hypothesenlandschaft ab. Zweitens: Die Zuordnung ist ein eigenes Artefakt. Sie ist nicht Teil der Vorlage und nicht Teil des Projekts, sondern eine eigenständige Übersetzungstabelle dazwischen – und sie will gepflegt, dokumentiert und bei Übergaben mitgeliefert werden.

Drittens: Vollständigkeit prüfen, nicht Aussehen. Es reicht nicht, dass das aktuelle Dokument gut aussieht – jeder im Projekt vorhandene Stil braucht eine Zielvorlage, auch der selten benutzte. Sonst kippt die Ausgabe irgendwann bei einem Dokument, das den betreffenden Stil erstmals verwendet, und die Fehlersuche beginnt von vorn. Viertens: ein Minimaldokument als Prüfstück. Ein einzelnes Topic, das alle vorkommenden Stile einmal enthält, lässt sich in Minuten erzeugen und prüfen – und ersetzt den kompletten Erzeugungslauf über dreihundert Seiten.

Fünftens: nicht am Stylesheet drehen, um die Word-Ausgabe zu reparieren. Die Formatierung im Projekt steuert die Online-Hilfe; Änderungen dort verschlechtern sie, ohne das Word-Problem zu lösen. Getrennte Ausgabewege brauchen getrennte Stellschrauben. Und sechstens: Nachbearbeitung ist keine Lösung. Ein Makro, das hinterher repariert, funktioniert – bis ein neuer Stil auftaucht oder jemand anders die Ausgabe erzeugt. Es verschiebt das Problem von der Konfiguration in die Wartung, wo es auf Dauer deutlich teurer wird.

Abb.: Sechs Lehren – drei zur Diagnose, drei zur Vermeidung.

✓ Praxis-Tipp: Das Stil-Musterdokument Lege im Projekt ein einzelnes Topic an, das jeden verwendeten Stil genau einmal enthält — Überschriften aller Ebenen, Fließtext, Hinweis, Warnung, Handlungsschritt, Aufzählung, Tabelle, Code, Bildunterschrift. Beschrifte jeden Absatz mit dem Namen seines Stils, damit man im Ergebnis sofort sieht, worum es sich handelt. Dieses Topic ist das Prüfstück für jede Änderung an Vorlage, Zuordnung oder Ausgabekonfiguration: erzeugen, ansehen, fertig — in Minuten statt in einem Durchlauf über das ganze Handbuch. Und es ist zugleich die Prüfliste für Vollständigkeit: Was im Musterdokument richtig erscheint, ist zugeordnet. Beim Anlegen eines neuen Stils wird das Topic ergänzt — dann fällt eine fehlende Zuordnung auf, bevor sie jemanden Zeit kostet.

 

ℹ Ein zweiter Fall mit demselben Muster Ein typischer Fall aus einer anderen Redaktion zeigt dieselbe Struktur: Nach der Übersetzung kamen einzelne Topics in der Zielsprache leer zurück — der Import lief durch, meldete Erfolg, und die Inhalte fehlten trotzdem. Auch hier begann die Suche im Ergebnis: Zielprojekt geprüft, Import wiederholt, Dateien einzeln kontrolliert, Reimport mit anderen Einstellungen. Die Ursache lag wieder in der Mitte der Kette: Das Übersetzungswerkzeug des Dienstleisters hatte beim Bearbeiten bestimmte interne Markierungen entfernt, und ohne sie ließ sich der Rückläufer nicht mehr zuordnen. Sichtbar war das Symptom im Zielprojekt, entstanden war es zwei Stationen früher. Die Lehre ist identisch — und die Gegenmaßnahme auch: ein kleiner Testrundlauf mit einer einzigen Datei, bevor vierzig Sprachpakete unterwegs sind.

 

Was der Fall über Fehlersuche sagt

Die Lehren oben sind werkzeugbezogen und nützlich. Die allgemeinere Erkenntnis liegt aber woanders: Zeitverlust in technischen Ketten entsteht selten durch schwierige Probleme. Er entsteht durch falsch adressierte Suche – und die entsteht wiederum dadurch, dass man am sichtbaren Ende ansetzt statt an der Stelle, an der das Problem entsteht. Ein falsch formatierter Absatz ist sichtbar; die fehlende Zeile in einer Zuordnungstabelle, die ihn verursacht hat, ist es nicht.

Dieses Muster wiederholt sich in jeder Publishing-Kette. Ein PDF hat falsche Umbrüche – gesucht wird im PDF, verursacht wurde es in der Vorlage. Eine Übersetzung kommt leer zurück – gesucht wird im Zielprojekt, verursacht wurde es im Austauschformat. Eine Suche findet ein Dokument nicht – gesucht wird in der Suchkonfiguration, verursacht wurde es dadurch, dass ein Feld nie zugeordnet wurde. Immer dasselbe Prinzip: Das Symptom zeigt sich am sichtbaren Ende der Kette, die Ursache sitzt irgendwo in der Mitte.

Daraus folgt eine Arbeitsweise, die sich in jeder Redaktion einführen lässt: Bei Problemen in einer Kette zuerst die Kette aufzeichnen – welche Stationen gibt es, was geht wo hinein und heraus? Dann von hinten prüfen. Diese Übung dauert zwanzig Minuten und ersetzt regelmäßig Tage des Probierens. Sie hat außerdem einen Nebeneffekt, der langfristig mehr wert ist als die gesparte Zeit: Man versteht die eigene Kette hinterher tatsächlich.

Ein letzter Punkt zur Nachbereitung, der über den technischen Teil hinausgeht: Der Fall wurde im Team besprochen — nicht als Schuldfrage, sondern als Lernfall. Was war die erste Hypothese, warum wurde sie nicht früher verworfen, an welcher Stelle hätte ein Blick genügt? Diese halbe Stunde ist die wertvollste des ganzen Vorgangs gewesen, weil sie aus einer verlorenen Zeit eine übertragbare Erfahrung machte. Ohne sie wäre die Erinnerung geblieben, dass „die Word-Ausgabe zickt“ — was falsch ist und beim nächsten Mal wieder Zeit gekostet hätte.

Solche Nachbesprechungen sind in Redaktionen unüblich, obwohl sie wenig kosten. Drei Fragen genügen: Was war das Symptom? Wo saß die Ursache? Was hätte uns früher hingeführt? Die Antworten gehören in eine schlichte Sammlung — eine Seite je Fall —, und diese Sammlung ist nach zwei Jahren mehr wert als jedes Handbuch, weil sie die Eigenheiten der eigenen Werkzeugkette beschreibt statt die allgemeinen.

Fazit

Drei Wochen Fehlersuche, fünf Minuten Korrektur – dieses Verhältnis ist unangenehm und nicht untypisch. Der Fehler saß nicht in der Firmenvorlage, nicht im Stylesheet und nicht in der Ausgabekonfiguration, sondern in der Zuordnungstabelle dazwischen: fehlende Einträge, für die eine stille Ersatzregel griff. Sichtbar war das Symptom, unsichtbar die Ursache – und genau diese Konstellation macht Fehlersuchen teuer.

Was hilft, ist eine andere erste Frage: nicht „warum sieht das falsch aus“, sondern „was steht hier tatsächlich“. Dazu ein Musterdokument mit allen Stilen als Prüfstück, eine gepflegte und dokumentierte Zuordnung – und die Bereitschaft, nach zwei Stunden das Vorgehen zu wechseln statt die nächste Variante zu probieren. Wenn du bei einer hakenden Ausgabekette Unterstützung willst: Genau dabei unterstütze ich dich gern; die Details findest du auf der Beratungsseite zur Technischen Dokumentation.

Häufige Fragen zu diesem Fall

Warum gibt es keine Fehlermeldung bei fehlender Zuordnung?

Weil eine Ersatzregel greift: Fehlt für einen Quellstil eine Zielvorlage, wird eine Standardvorlage verwendet, und der Erzeugungslauf läuft durch. Aus Sicht des Werkzeugs ist das kein Fehler, sondern ein definiertes Verhalten – das Ergebnis entsteht ja. Für die Fehlersuche ist es allerdings die unangenehmste Variante, weil das Dokument sichtbar falsch aussieht, ohne dass irgendwo ein Hinweis auf die Ursache erscheint. Stille Ersatzregeln dieser Art sind in Publishing-Ketten weit verbreitet.

Wie finde ich heraus, welche Formatvorlage ein Absatz hat?

In Word den Cursor in den betreffenden Absatz setzen und in den Formatvorlagen nachsehen, welche als aktiv markiert ist – zwei Klicks. Genau dieser Schritt war im geschilderten Fall der Wendepunkt: Er zeigte, dass die Absätze eine Formatvorlage trugen, die in der Firmenvorlage gar nicht vorkam. Damit verschob sich die Frage von „warum sieht diese Vorlage falsch aus“ zu „warum wird überhaupt diese Vorlage verwendet“ – und aus dem Herumprobieren wurde eine zielgerichtete Suche.

Ist ein Makro zur Nachbearbeitung wirklich so schlecht?

Als Übergangslösung für einen konkreten Termin: vertretbar. Als Dauerlösung: nein. Ein Makro kennt nur die Fälle, für die es geschrieben wurde – taucht ein neuer Stil auf, greift es nicht. Und es hängt an der Person, die es kennt und ausführt: Wer die Ausgabe ohne Nachbearbeitung erzeugt, liefert ein falsches Dokument aus, ohne es zu merken. Damit verschiebt sich das Problem von der Konfiguration, wo es einmalig zu lösen wäre, in die Wartung, wo es dauerhaft Aufmerksamkeit kostet.

Wie verhindern wir, dass so etwas wieder passiert?

Mit drei Maßnahmen. Erstens ein Musterdokument im Projekt, das jeden verwendeten Stil einmal enthält – es ist in Minuten erzeugt und zeigt sofort, ob alles zugeordnet ist. Zweitens die Zuordnungstabelle als dokumentiertes Artefakt: Quellstil, Zielvorlage, Bemerkung – gepflegt und bei Übergaben mitgeliefert. Drittens eine Regel im Team: Wer einen neuen Stil anlegt, ergänzt den Eintrag in der Zuordnung und im Musterdokument, bevor die nächste Ausgabe läuft.

Gilt das nur für RoboHelp?

Nein – das Muster ist allgemein. Jede Publishing-Kette übersetzt Quellformate in Zielformate, und überall dort, wo diese Übersetzung über eine Zuordnung läuft, kann sie unvollständig sein. Dasselbe Bild findet sich bei anderen Redaktionswerkzeugen, bei Konvertierungen und bei automatisierten PDF-Ausgaben. Die Diagnose-Regel bleibt dieselbe: vom Ergebnis rückwärts prüfen und an jeder Station fragen, was hier ankommt und was herausgeht – statt am sichtbaren Ende zu probieren.

 

Interne Links: Pillar (/technische-dokumentation/) · RoboHelp-Word-Ausgabe nach Firmenvorgaben (/robohelp-word-ausgabe-firmenvorgaben/) · RoboHelp-Konvertierung (/robohelp-konvertierung/) · Word-Formatvorlagen (/word-technische-dokumentation-formatvorlagen/) · Beratung (/technische-dokumentation-beratung/)