Dem Mittelstand in Deutschland haftet der Geruch an, bieder und kleinbürgerlich zu sein. Das gilt auch für den bei Bedarf immer gerne gelobten Maschinenbau. Dort werden auf der grünen Wiese aus – von außen betrachtet unerklärlichen Gründen – Produkte gefertigt, die höchsten internationalen Standards genügen. Einerseits. Anderseits gilt vor allem der Süden der Republik als Heimat der Bastler, Tüftler und der kleinen aber feinen Kleinunternehmen, wo sich selbst der Chef nicht zu schade ist, auch mal zum Schraubenschlüssel zu greifen. Interessanterweise gelten dieser hohen Ansprüche nicht immer für das gesamte Produkt. Vor allem die Dokumentation leidet manchmal darunter, dass eben wirklich nur gebastelt und getüftelt wird.
Die Dokumentation ist ein wesentlicher Bestandteil der Kommunikation, nicht nur des Produkts mit dem Kunden, sondern auch des Unternehmens mit seiner Umwelt. Erstaunlicherweise werden Anleitungen häufiger gelesen als beispielsweise die Bibel. Dokumentation bedeutet eben nicht nur das Zusammenstellen technischer Daten oder das ungeliebte aber notwendige Berücksichtigen geforderter Sicherheitsnormen und Produkthaftungsgesetze. Das muss sie natürlich auch, es ist aber nur ein Teil der Dokumentation. Mit der technischen Dokumentation beweist der Herausgeber (Hersteller oder „Inverkehrbringer“), ob er willens und in der Lage ist, den Umgang der Käufer seiner Produkte zu antizipieren und ob er gewillt ist, dass aus dem Produkt ein Nutzen für beide Seiten entsteht.
Umso schmerzhafter ist es daher für Technische Redakteure, auf das bloße Kopieren der Vorgaben aus der Konstruktion oder der Fertigung reduziert zu werden.
Anforderungen
Technische Redakteure sind gefordert, beide Seiten des Produkts, oder vielmehr des „Dreiecks“ aus Hersteller – Produkt – Nutzer zu betrachten und zu berücksichtigen. Mit dem Zusammenkopieren der Informationen des Herstellers werden sie dem jedoch nicht gerecht. Redakteure können nicht davon ausgehen, dass das, was Ihnen aus anderen Abteilungen des Unternehmens vorgelegt wird, auch 1:1 an den Produktnutzer weitergegeben werden kann, denn der Informationslieferant (SME, Subject Matter Expert) mag zwar über profunde Produktkenntnisse verfügen, von den Anforderungen an eine verständliche und klare Informationsbereitstellung weiß er meist weniger. Muss er ja auch nicht. Erst aus dem Zusammenspiel zwischen SME und Technischem Redakteur ergibt sich der gesamte Informationsinput, den der Redakteur zu verarbeiten hat. Er macht das vor dem Hintergrund eines virtuellen Produktnutzers, für den er wie durch einen Filter die Informationen zerpflückt, auf ihre Relevanz überprüft und gliedert: „Gehört das ins Datenblatt oder doch in die Funktionsbeschreibung? – Sollte man diesen Handlungsschritt mit einer bildlichen Darstellung ergänzen?“
Dazu kommt der zunehmende Druck auf die Hersteller, auf spezifische Kundenwünsche einzugehen. Es wird nichts „von der Stange“ geliefert, sondern meist direkt auf die Anforderungen des Kunden zugeschnitten. Das kann dazu führen, dass noch vor Ort und wenige Tage vor der Übergabe am Produkt eine Änderung durchgeführt wird, die sich auch in der Dokumentation wiederfinden soll. Ob eine geänderte Grafik oder neue Bedienschritte, der Redakteur muss in seiner Dokumentation immer häufiger noch kurz vor knapp nachsteuern. Das verkürzt die Durchlaufzeiten und erhöht die Belastung.
Das richtige Werkzeug für den Job
Das ist der Beruf des Technischen Redakteurs, darin ist er ausgebildet und dafür wird er bezahlt. Er ist nicht die Schreibkraft des Konstruktionsleiters oder der kreative Lehrling der Marketingabteilung. Dazu braucht er aber die richtigen Werkzeuge. Denn so wie ein Konstrukteur heutzutage auch im deutschen Mittelstand kein Produkt mehr auf einem Reißbrett entwirft und mit Lineal und Zirkel hantiert, steigt auch für den technischen Redakteur der Aufwand unverhältnismäßig, wenn er nicht die richtigen Werkzeuge zur Hand hat, mit denen sich Korrekturläufe und Änderungen, Sprachen und die Verwendung von standardisierten Informationsbausteinen kontrollieren lässt. Oder, um es an einem Beispiel zu zeigen: wenn es zehn unterschiedliche Dokumentationen gibt und nur in der siebten muss die Serviceadresse geändert und in die Zielsprache übersetzt werden, macht sich eine saubere Dateiverwaltung bezahlt. Vor allem, wenn noch eine weitere Änderung in der dritten Dokumentation hinzukommt.
Jetzt gibt es flinke Mitarbeiter, die solche Änderungen in der letzten Minute vornehmen, ohne mit der Wimper zu zucken, dabei auch die übrigen Dokumentationen auf Rechtschreibung kontrollieren und die Vollständigkeit sowie Aktualität der technischen Zeichnungen sicherstellen. Diese Mitarbeiter sind rar gesät, da sie aufgrund der hohen Belastung kaum mehr Recherche und zum Anfertigen der Dokumentation für neue Produkte kommen – fatal, wenn dabei ein Sicherheitshinweis „vom Tisch rutscht“ und der Anwender für acht Wochen wegen schwerer Verbrennungen im Krankenhaus verbringt.
Grenzen und Möglichkeiten
Nun mag das für den Redakteur bei kleinem Auftragsumfang noch zu bewältigen sein. Bei hoher Produktvarianz oder extrem kurzen Änderungszeiträumen, wie sie gerade im deutschen Mittelstand zunehmend üblich werden, wird es schon schwieriger, vor allem, wenn auch die Qualität der Dokumentation zumindest konstant gehalten werden soll. In diesem Kreislauf aus kürzeren Änderungszyklen, höheren Qualitätsanforderungen, komplexeren Produkten und spezielleren Ausprägungen stößt die Redaktion an ihre Grenzen. Diese lassen sich auch nur schlecht durch einen höheren Personaleinsatz abfangen, denn diese Entwicklung betrifft zahlreiche Hersteller und entsprechend dünn ist die Angebotsdecke.
Gibt es Möglichkeiten, aus dieser Spirale auszubrechen? Ja, es gibt sie, aber sie verlangen nach sorgfältiger Planung und einer gewissen Investitionsbereitschaft. Wenn das Kind jedoch schon in den Brunnen gefallen ist, ist da kaum noch etwas zu machen.
– Und wie lauten die Optionen?
- Brainware statt Hardware. Entscheidend für den Erfolg der Dokumentation und ihrer Qualität ist der Einsatz der Vernunft: Wie groß ist der Aufwand für eine Änderung im Vergleich zum Weiterarbeiten wie bisher? Bei zehn Änderungen der Serviceadresse (die ja nicht jede Woche geändert wird), ist es müßig, über Optionen nachzudenken, das lohnt einfach nicht. Bei 100 Änderungen pro Woche sinken die Chancen auf einen erfolgreichen Änderungszyklus dagegen erheblich. Da hilft auch nicht der Einsatz schneller Rechner oder mehrerer Bearbeiter: der Fehlerquotient steigt mit jedem Bearbeiter exponentiell. Und damit auch der Aufwand, hier durch klare Vorgaben und Nachkontrollen dem förmlich explodierenden Wildwuchs Einhalt zu gebieten.
- Planung statt Chaos. So wie die Dokumentation versucht, die Handlungen oder möglichen Verständnisprobleme des Produktnutzers zu antizipieren, muss sie selbst dieser Betrachtung unterzogen werden: Das beginnt mit der Gliederung der Inhalte, der Ablagesysteme und der Dateinamen. Und es geht weiter mit der Behandlung der übersetzen Dokumente und der Nachvollziehbarkeit der Arbeit und der Archivierung. In welchem Format und mit welchem Dateinamen werden die Dokumente abgelegt – und zwar so, dass sie auch von einem Benutzer gefunden werden können? Was passiert, wenn es zu Änderungen kommt? Wie heißen die Ordner? Woran erkennt man die aktuelle Version? Ist diese inhaltlich deckungsgleich mit der übersetzten Fassung oder fallen für jede geänderte Kommasetzung neue Kosten an?
Bis zu einem gewissen Grad lassen sich die Probleme mit einer vernünftigen Dateiablage innerhalb einer überschaubaren Produktpalette abfangen, beispielsweise indem mehrere Varianten eines Produkts in einer Dokumentation behandelt werden (die Optionen müssen dann natürlich als solche gekennzeichnet werden).
An dieser Stelle bewegt sich der klassische deutsche Maschinenbau in einem Grenzbereich: einerseits ist oft die Produktpalette nicht groß, andererseits aber zahlreiche Varianten möglich, die sich meist noch aufeinander beziehen (wenn dort Bauteil A eingebaut ist, muss dort statt Bauteil B das Teil C verbaut werden). Dies kann bereits vor der eigentlich Erstellung der Dokumentation durch angepasste Flussdiagramme veranschaulicht werden, die auch dem Redakteur helfen, die Abhängigkeiten der Produktkomponenten und damit der Dokumentationsbausteine zu erkennen.
Im Laufe der Zeit entsteht aber – sofern der Redakteur nicht über eine unmenschliche Selbstdisziplin und ausreichend Zeit verfügt – allmählich eine Vielzahl an Varianten, die teils veraltet sind, teils parallel eingesetzt werden können. Selbst die schönste Ordnung hat keinen Bestand, wenn sie nicht ständig auf ihre Berechtigung überprüft und entsprechend gepflegt wird. Dies verlangt vom Redakteur neben der Disziplin einen erheblichen Zeitaufwand, der umso größer wird, je „älter “ das System ist und je vielfältiger die Kombinationsmöglichkeiten werden. Diese Zeit aber gibt es nicht.
Der Redakteur als „Humankapital“ verschlingt dann soviel Zeit für Aufgaben, die nicht zu seinem unmittelbaren Tätigkeitsfeld gehören, dass er unwirtschaftlich wird: sein Wert für das Unternehmen sinkt. Ihn durch Outsourcing und ähnlich zu kurz gedachte Maßnahmen zu ersetzen löst das Problem nicht – im Gegenteil, es verschärft die Situation, denn damit wird zusätzlich auch noch Unternehmenswissen verschleudert.
Ab einem gewissen Zeitpunkt lohnt dann eine Überlegung, die von vielen Unternehmen angestellt, aber ob ihrer Komplexität immer wieder zurückgestellt wird: die Investition in ein Redaktionssystem.
Wie ein Redaktionssystem grundsätzlich funktioniert und welchen Nutzen es bringen kann, beleuchte ich anschließend.
Die größte Verführung an dem Begriff „System“ ist, dass häufig angenommen wird, man könne mit Technik mehr Probleme lösen als sie verursacht. Das stimmt zwar prinzipiell, allerdings ist die Einbettung in einen größeren Zusammenhang wichtig: Ohne Redaktionskonzept kein Redaktionssystem. Ein Redaktionssystem ist ja keine eierlegende Wollmilchsau: Wie jedes System kann es nur so gut sein wie der Input, die Daten, mit denen es gefüttert wird. Wo die Unterschiede zu der herkömmlichen Vorgehensweise liegen, soll im folgenden Artikel angerissen werden.
Das Konzept
Ein Redaktionssystem als eine Art „aufgebohrtes“ Dokumentenmanagement zu verstehen, ist hier gar nicht mal so verkehrt. Von Außenstehenden wird das auch gerne in einen Topf geworfen und macht es einfacher, auf die konzeptionellen Anforderungen einzugehen. In der Tat verwaltet auch ein Dokumentationssystem Informationen. Diese liegen als Dokumente vor (Bilder, PDF, Office-Dokumente) und werden als Versionen abgelegt, für bestimmte Benutzer zur Verfügung gestellt und vor allem verschlagwortet, damit man sie leichter findet. Ein Dokumentenmanagement funktioniert daher ähnlich wie ein großes Lager mit vielen Behältern, die nicht alle mit dem gleichen Schlüssel geöffnet werden können. Um zu wissen, welche Teile am häufigsten benötigt werden und von wem, führt das System ständig Inventur. Und muss grundsätzlich so angelegt sein, dass man nicht erst alle Behälter öffnen muss, wenn man den Inhalt von einem Behälter in den nächsten verlagert. Wer hineinlegen darf, wer herausnehmen darf, wer die Behälter verschließt und wer sie öffnet, wer die Behälter wegräumt und holt, wer sie abstellt und wohin – dies alles regelt die Software nach vorgegebenen Parametern.
Diese Parameter müssen daher zunächst einmal auf der Grundlage der vorhandenen Prozesse und Datenmenge definiert werden. Kurz: Alles, was einen guten Archivar ausmacht, übersetzt die Software in bits und bytes. Wer also seine Dokumentenablage und die damit verbundenen Zugriffsrechte bisher eher lax gehandhabt hatte, bekommt jetzt Probleme, denn in einem Dokumentenmanagement entfällt der „menschliche Faktor“: Mal eben Dokumente auf der eigenen Festplatte speichern und darin weiterarbeiten, sie dann dem Kollegen als aktuelle Fassung zur Verfügung zu stellen und per E-Mail zu verteilen? Damit sind sie aus dem Informationsfluss gefischt und werden einen kläglichen Tod auf irgendeiner Festplatte sterben, unerreichbar für alle anderen.
Schon für eine Dokumentenverwaltung muss also ein schlüssiges und ausnahmefreies Konzept her, das für den Benutzer zunächst stark einschränkend wirkt, denn er darf nicht mehr nach Gusto in den Laufwerken wühlen und sich die Daten dorthin legen, wo er im Augenblick Lust drauf hat. Das System verbietet das.
Noch einen Schritt weiter geht ein Redaktionssystem.
| Eine Gegenüberstellung der unterschiedlichen Systeme findet sich auch auf workflowblog.de in der Reihe von Georg Eck: „ECM [Enterprise Content Management] kontra Redaktionssystem„ |
Neben der Dokumentenverwaltung ist ein Redaktionssystem auch damit beschäftigt, dem Benutzer nicht nur vorzugeben, wo und wie er die Informationen ablegt und behandelt, sondern auch, wie er sie zu erstellen hat. Statt nur auf der Ebene der Dokumente zu verwalten, greift ein Redaktionssystem in die Dokumente selbst ein: an welcher Stelle sind welche Informationen in welcher Form im Dokument zulässig? In welcher Sprache und in welcher Version liegt beispielsweise eine Sicherheitshinweis vor? Dazu muss ein Redaktionssystem in den gesamten Dokumentationsprozess eingebettet sein und ihn quasi „abbilden“: Von der Recherche über die Erstellung bis hin zur Ausgabe und Übersetzung spiegelt ein Redaktionssystem genau die Anforderungen wieder, die in der täglichen Arbeit an den Redakteur gestellt werden. Und über diese muss daher erst Klarheit bestehen. Wer bisher gerne mit Kopieren & Einfügen gearbeitet hat, kann mit den Anforderungen des Redaktionssystems zunächst nichts anfangen. Wer bisher ad hoc entschieden hat, ob noch eine Grafik oder ein Bild eingefügt wird oder statt vier Schrauben nur noch drei angezogen werden, der bekommt Probleme, denn die Änderungen können sich nicht nur auf das aktuelle Dokument bzw. den aktuellen Dokumentbaustein auswirken, sondern zahlreiche andere Dokumente betreffen. Das liegt daran, dass im System Bausteine (Bilder, Texte, Variable) per Referenzierung mehrmals verwendet werden können – und aus Effizienzgründen auch sollten. Beliebtestes Beispiel ist ein Sicherheitshinweis, der sich in der Formulierung nicht unterscheiden sollte – unabhängig davon, ob er vor schwebenden Lasten bei der Montage oder bei der Instandsetzung warnt. Er darf nur einmal vorliegen und wird per Referenz eingebunden. Einmal geändert, wird diese Änderung automatisch für alle Dokumente gültig, in denen er vorkommt. Damit ist zwar seine Konsistenz gewährleistet (er muss auch nur einmal übersetzt werden), er kann jedoch nicht mehr ohne Weiteres angepasst werden, ohne alle Dokumente zu ändern. Ihn mehrfach anzulegen führt jedoch mitunter zu genau dem Wildwuchs, den zu vermeiden der eigentliche Auftrag an das System ist.
Ist ein Dokumenten-Managementsystem mehr wie ein Lager, so ist das Redaktionssystem wie ein Netz, in dem die Informationen miteinander verknüpft und mehrfach ineinander verwoben sind. Das bedeutet aber auch, dass das Redaktionssystem anhand definierter Vorgaben die „Informationsknoten“ nur so verknüpft, wie es sie verknüpfen darf. Mit anderen Worten: es geht nicht mehr nur um die Frage, wer wann wo etwas macht, sondern auch wie und warum, denn doppelt vorhandene Informationen verlangsamen zwar moderne System nicht mehr, sie multiplizieren aber die Fehlerquote. Das Ändern eines Satzes in einem Sicherheitshinweis kann dann unabsehbare Folgen haben …
Die Technik
Ganz elementar besteht ein Redaktionssystem aus einer oder mehreren Datenbanken, die über zahlreiche Programmierschnittstellen an einen oder mehrere so genannte Editoren angeschlossen sind, mit denen der Redakteur das System füttert (Texte, Bilder, … ). Editoren können einfache Textverarbeitungsprogramme sein oder auch komplexe Layoutsoftware.
Auf der anderen Seite verfügt das System über mehrere Ausgabekanäle, die per Konvertierung aus dem Inhalt der Datenbank eine Vielzahl von Medien bedienen können. Das kann direkt die klassische Druckausgabe auf Totholz sein, oder aber digitale Medien wie PDF und HTML. Teilweise kann sogar der selbe Editor für die Ausgabe verwendet werden, wie er auch beim Input zum Zuge kam. Die Textinhalte werden im XML-Format in der Datenbank gespeichert, die übrigen Medien als geschlossene Datenformate (PDF, TIFF, …), die nur nur rudimentär bearbeitet werden können.
Durch die Ablage in einer Datenbank und mit Hilfe eines plattformneutralen Datenformats (XML) ergeben sich damit zahlreiche Möglichkeiten für das Redaktionssystem, die Informationshappen zu manipulieren: Suchen, Verschieben, Verschlagworten, Versionieren, Archivieren, Kombinieren, Verschachteln, Umbenennen – eigentlich alles, was man so mit Datenbankinhalten anstellen kann – bis hin zum Anschluss an eine Übersetzungssoftware (TMS, Translation Memory System).
Dies hat natürlich seinen Preis, und der ist nicht gering.
Je nach erwarteter Größe – im Anlagenbau können schnell mehrere Milliarden (!) Datensätze zusammenkommen – wird eine entsprechende (Server-)Hardware erforderlich, die diese Datenbank (oder Datenbanken) auch beheimaten kann. Um schnell auf diese Daten zugreifen zu können, muss natürlich auch das Netzwerk auf die entsprechenden Zugriffe ausgelegt sein. Bis beispielsweise ein Abschnitt aus einem Montagekapitel mit Tabellen, Text, Grafiken, Listen, Überschriften, Querverweisen und wiederverwendeten Abschnitten der aktuellen Version in der angeforderten Sprache auf dem Bildschirm angezeigt werden kann, schaufelt das System nämlich schnell einige hundert Datensätze durch die Leitungen, die vorher aus der Datenbank gefiltert wurden.
Da diese Daten aber nicht direkt auf dem Server bearbeitet werden, greifen die Redakteure mit einem Client darauf zu, nachdem sie sich am System angemeldet haben. Dieser Zugriff erfolgt meist über ein internes Netzwerk innerhalb des Unternehmens. Meist. Bei internationalen Unternehmen muss unter Umständen der Redakteur in Fernost genauso an seine Informationen kommen wie der Bearbeiter direkt neben dem Server. Dies wird sogar immer häufiger gefordert und stellt netzwerktechnisch höhere Anforderungen an die IT und die Datensicherheit.
Import und Königskinder
| Das Redaktionssystem bedeutet zunächst keine qualitative Verbesserung der Dokumentation, sondern eine Verbesserung der Datenorganisation. Beides gleichzeitig angehen zu wollen, ist hoch riskant und führt in den meisten Fällen zum Scheitern des gesamten Projekts.Sehr gute Überlegungen dazu auch bei Scriptorium.com von Sarah O’Keefe. |
Damit haben Sie aber immer noch keinen Inhalt in der Datenbank. Der muss erst noch hinein – und auch das kann sehr aufwändig werden. Besonders der Import bestehender Inhalte stellt die Redaktion vor schier unüberwindliche Aufgaben: Sind die Dokumente, die seit Jahren auf dem Rechner liegen und immer wieder kopiert, geändert und angepasst wurden, überhaupt aktuell hinsichtlich ihrer Formatierung? Wieviel Aufwand kostet es, die Dokumente vor dem Import zu kontrollieren, Schwachstellen auszubügeln und sie für das System „verdaulich“ zu machen?
Zwar gibt es Filter, aber diese halten sich strikt an die Vorgabe: Überschrift 1 ist eine Überschrift erster Ordnung, eine „Überschrift 1 + 24pt Arial“ ist es nicht und wird ignoriert, selbst wenn sie gleich aussieht. Knallhart. Das kann bedeuten, dass unter Umständen vor dem Import viel Zeit und Aufwand für das „Glätten“ aufgewendet werden muss, bevor überhaupt Inhalte im System sind und von ihm sinnvoll verwaltet werden können. Da in der Zwischenzeit aber nicht der ganze Betrieb warten kann, sondern parallel auch weiterhin Dokumente ausgegeben werden müssen, verfallen zahlreiche Unternehmen zu Recht auf die Idee, zunächst nur einen Teil der Dokumentation in das System zu übernehmen. Das ist an sich richtig, darf aber nicht dazu führen, mitten in der Umsetzung eine Pause einzulegen, denn sonst existiert in der Redaktion eine Parallelwelt: der eine Teil produziert aus dem System, der andere Teil ist „Business as usual“. Und beide können zusammen nie finden.
Es muss also bereits vorher konsequent festgelegt werden, wann welche Dokumentationsteile importiert werden und wie lange die daraus resultierenden Verzögerungen sein können.
Nacharbeit und Ausgabe
Sind aber erst einmal die gesamten Inhalte im System, beginnt die eigentliche Arbeit, die sich über Jahre hinziehen kann – und darf. Aus dem Redaktionssystem heraus ohne Qualitätsverlust zu produzieren, bedeutet schon eine gewaltige Verbesserung, selbst wenn der eigentliche Inhalt der Dokumentation nicht geändert wurde: Jetzt können Querverweise angelegt und Bildverweise nachgezogen werden, denn ein Import gelingt trotz bester Vorarbeiten nie vollständig, zu unterschiedlich sind die Herangehensweisen besonders in diesen Punkten zwischen einer optisch orientierten Textverarbeitung und einem strukturell ausgerichteten Redaktionssystem.
Dem Irrtum, man könne alle Probleme, die sich im redaktionellen Alltag stellen, mit einer genügend teuren und komplexen Technik lösen und dann rechtzeitig Feierabend machen, diesem Irrtum verfallen nicht nur Systemadministratoren, sondern auch Redakteure. Ein Redaktionssystem ist kein Toaster, ein Redaktionssystem ist eine Informationsverarbeitungsmaschine, deren Inhalt immer gut gepflegt und sorgfältig gewartet werden will.
Dies ist vor allem zu Beginn wichtig, denn die Ausgangslage in der Redaktion ist meist sehr vielschichtig. Es ist eine Utopie, dass ein Unternehmen sich dazu entschließt, quasi „auf der grünen Wiese“ alle Dokumente und Inhalte mit einem solchen System zu erstellen und verwalten.
Da solche Systeme sehr teuer sind, wird zunächst die Dokumentation von aufopfernden Redakteuren „zu Fuß“ angefertigt und zusammengetragen. Bis es zu dem folgenschweren Entschluss kommt, in ein Redaktionssystem zu investieren, haben sich dann schon viele Seiten und Dokumente unterschiedlichster Provenienz angesammelt. Je nach Kenntnis der möglichen Werkzeuge reicht die Spannbreite von nachträglich zusammengehefteten Präsentationsfolien bis zu aufwändig gelayouteten und strukturierten Dokumenten. Während es dem Papier weitgehend gleich ist, mit was es bedruckt wird – und demzufolge sehr unterschiedliche Inhalte zwischen die Deckel des Ordners passen – ist es einem Redaktionssystem überhaupt nicht egal, in welchem Zustand die Informationen sind, mit denen es gefüttert wird. Das Zauberwort und eine der größten Hürden, die es zu nehmen gilt, hört auf den exotischen Namen „Migration“.
Datenmigration
Hinter dem Begriff der „Datenmigration“ verbergen sich wie auch im realen Leben zahlreiche Einzelschicksale. In diesem Fall jedoch glücklicherweise nur virtuelle, die aber dennoch in Tragödien enden können. Da Redaktionssysteme die Daten im ubiquitären Datenformat XML ablegen, das auf Formatierungsanweisungen keine Rücksicht nehmen kann, müssen die einzuspielenden Daten zuerst auf ihre innere Logik und Kongruenz geprüft und notfalls „geradegezogen“ werden: Ist die Überschrift auf der vierten Seite auch wirklich so ausgezeichnet – oder handelt es sich um ein schnell mal hineinkopiertes „Arial-14pkt-fett-Einrückung-2cm-links-mit-Rand-oben“-Format? Mit anderen Worten: sind alle Überschriften auch wirklich Überschriften? Alle Tabellen auch wirklich Tabellen oder nur per Leerschritt formatiert? Sind die Pfeile in der Grafik auch wirklich in der Grafik oder nachträgliche Wordart-Basteleien?
Alle Dokumente zu kontrollieren und eben auch die eigene jahrelange handwerkliche Arbeit zu hinterfragen, stellt den Redakteur vor große Herausforderungen. Außerdem: Wie soll man den enormen Zeitaufwand rechtfertigen?
Natürlich lässt er sich rechtfertigen. Denn man sollte dabei bedenken, dass jedes System später nur so gut ist wie die Qualität der Daten, mit denen es gefüttert wird – also auch der migrierten Daten. Denn diese stellen das Fundament dar, auf dem später im System weitere Informationseinheiten erstellt werden. Jede Kontrolle, die hier nicht gemacht wird, jede Auslassung und Einsparung an dieser Stelle kostet später wesentlich mehr und kann sogar dazu führen, dass das ganze Projekt „Redaktionssystem“ scheitert.
Die Struktur
| In diesem Artikel verwendete Marken- und Firmennamen erfolgen nur zur Demonstrationszwecken. Es bestehen keine wirtschaftlichen Verpflichtungen gegenüber den erwähnten Unternehmen. |
Ist die erste Hürde genommen und werden die Daten tatsächlich weitgehend problemlos ins Redaktionssystem gefüttert, werden sie dort automatisch anhand ihrer Überschriften in einzelne „Informationshäppchen“ zerlegt – weitgehend anhand der Prinzipien des „Information Mapping“ in „Informationsknoten“. In dem nachfolgend exemplarisch herangezogenen System „ST4“ der Firma Schema heißen diese dann auch „Knoten“. Diese Informationsknoten können aus Unterknoten (hier „Fragmenten“) bestehen, die verknüpft und mehrfach verwendet werden können. Jetzt hat der Redakteur keine Dokumentation mehr, sondern nur noch Bausteine, die einer festgelegten Struktur folgen müssen und beliebig kombinierbar sind.
Und genau diese Struktur stellt die zweite große Herausforderung dar: Da das Ziel die Informationseffizienz sein soll, also jede Information nur genau einmal vorliegen sollte, ist die Frage dann, welcher der zahlreichen Bausteine eigentlich die relevante Information enthält und was mit den Bausteinen geschehen soll, die nicht benötigt werden. Oder werden sie vielleicht in Ausnahmen doch erforderlich? Wo vor der Migration das Augenmerk auf der formattechnischen Angleichung lag, kommt jetzt die Frage nach der einzusetzenden Struktur auf: Wie gehe ich mit häufig einzusetzenden Informationen wie beispielsweise Sicherheitshinweisen um? Ist es wirklich notwendig, zwanzig fast gleich lautende Sicherheitshinweise zu heißen Oberflächen zu haben? Kann man das allgemeiner formulieren? Oder muss der Sicherheitshinweis vielleicht sogar in zwei Teile zerlegt werden, weil er neben den heißen Oberflächen auch vor heißen Flüssigkeiten warnt, die aber in den meisten Fällen gar nicht zum Einsatz kommen? An welchen Stellen unterscheiden sich gleich lautende Informationsknoten? Ist der Unterschied beabsichtigt oder „gewachsen“?
Da diese Systeme die Inhalte nicht so darstellen, wie sie später vielleicht veröffentlicht werden, liegt der Schwerpunkt die Arbeit auf der inhärenten Logik der einzelnen Knoten. Ein großer Aufwand, denn meist muss ja gleichzeitig auch noch produziert werden.
Vom Redakteur wird an dieser Stelle ein beträchtliches Abstraktionsvermögen verlangt.
Das Informationspuzzle
Jetzt spulen wir im Schnelldurchlauf ein halbes Personaljahr in die Zukunft (was eine sehr optimistische Schätzung ist) und gehen davon aus, dass alle Informationsknoten auch sauber und konsistent strukturiert vorliegen. Es sind aber immer noch nur einzelne Bausteine, Puzzleteile eines großen Dokumentationsplans, eines Produkts, das über seinen gesamten Lebenszyklus (als betriebsanleitung einschließlich der Herstellerdokumentationen) oder auch nur in Ausschnitten (z.B. Montageanleitung) dokumentiert werden muss.
Mit anderen Worten: Es stehen tausende von Informationshäppchen zur Verfügung, die zu einem großen kohärenten Ganzen zusammengefügt werden müssen. Wie in einem Strukturbaum (näherungsweise einer DITA-Map) werden die Häppchen zusammengefasst und klassischerweise thematisch geordnet: Montage, Bedienung, Instandsetzung etc. Oder aber nach Zielgruppe: Schulungsunterlagen, Werbeunterlagen, Konstruktionsunterlagen. Um daraus dann ein Dokument zusammensetzen zu können, bleiben die einzelnen Informationen jedoch an ihrem angestammten Platz im System und für die Ausgabe als Dokumentation werden nur Verweise darauf zusammengestellt. Das eigentliche Dokument wird erst bei der Ausgabe erzeugt. Alle Bilder und Verweise werden dabei angepasst und entsprechend in das Dokument referenziert.
Auch das ist für den Redakteur ungewohnt, kann er doch nicht optisch mitverfolgen, wie das Dokument entsteht. Er schubst „nur“ die Informationshäppchen über den Bildschirm und stellt wie in einem Dateisystem lediglich Knotentitel zu Listen zusammen. Das ist zwar sehr effizient, aber auch sehr abstrakt. Da es auch möglich ist, in einem Dokument die Referenz auf eine weitere Referenz anzulegen, die dann wiederum auf ein anderes Dokument verweist, wird es schnell sehr unübersichtlich, wenn der Redakteur keinen klaren Vorgaben und Vorstellungen hat, welche Informationen an welcher Stelle im Dokument später erscheinen sollen. Und vor allem: wenn er in einem Baustein die Reihenfolge der Unterknoten ändert – welche Auswirkungen hat das auf andere Dokumente? Glücklicherweise unterstützen ihn die aktuellen Redaktionssysteme mit Hilfe so genannter „Verwendungsinformationen“ darin zu erkennen, welche Bausteine betroffen sind. Die mentale Vorarbeit jedoch bleibt. Hier ohne klare Struktur zu arbeiten, führt ins Chaos.
Das fällt vor allem bei Querverweisen auf, die im System als Hyperlinks geführt werden: sie verweisen auf die Überschriften anderer Bausteine im System. Was aber, wenn diese in der aktuellen Dokumentation gar nicht berücksichtigt werden? Das System deaktiviert dann zwar den Link, der Text der Überschrift bleibt aber erhalten. („Siehe Schmierstoffübersicht“ steht dann noch da, aber eine solche ist im Dokument gar nicht enthalten.) Dies zu berücksichtigen, ist auch Aufgabe des Redakteurs.
Und alles nochmals von vorne?
Und dann der Ernstfall: eine neue Version des Produkts soll geliefert werden, natürlich mit aktualisierter Information. Welche Informationen sollen für die neue Version geändert werden? Und was machen wir mit den alten Informationen? Das System kann natürlich versionieren, also für einen Informationshappen mehrere Versionen vorhalten, es ist aber Aufgabe der Redakteurs zu entscheiden welche Version im Dokument A und welche im Dokument B veröffentlicht wird. Zur Pflege der Varianten – der horizontalen Datenorganisation – kommt noch die Pflege der Versionen – der vertikalen Datenorganisation hinzu.
Gewiss, ohne Redaktionssystem ist das alles gar nicht möglich, denn ein Redaktionssystem speichert bei jeder Änderung mit, welcher Benutzer die Änderung durchgeführt hat. Und der Redakteur kann diese Änderungen auch im jeweiligen Baustein dokumentieren. Dazu zieht jeder Baustein eine Vielzahl an zusätzlichen Meta-Informationen mit, die einzig der Dateiverwaltung dienen – aber bedient werden muss es trotzdem.
Dennoch: liegen die kleinen Häppchen erstmal appetitlich konzipiert, gefertigt und gepflegt vor, geht die Produktion auf Knopfdruck.
Lehnen wir uns einmal kurz zurück und betrachten den bisherigen Stand: Wir haben alle Daten in das System migriert, haben die Redundanz weitgehend beseitigt, indem die Informationshäppchen so angelegt sind, dass sie wirklich nur noch einmal vorkommen und dementsprechend auch nur einmal gepflegt werden müssen, wir haben Versionen angelegt und Querverweise, Bilder eingefügt und – falls vorhanden – sogar Variablentabellen zur Variantensteuerung angelegt. Nun brauchen wir eine Korrekturfassung, die dem SME/Korrekturleser vorgelegt werden soll. Ob digital oder als PDF spielt keine Rolle.
Mit anderen Worten: wir müssen die Informationen ausgeben, publizieren, zur Verfügung stellen. Ja, und jetzt?
XML
Jetzt rufen wir uns in Erinnerung, dass ein Redaktionssystem, das etwas auf sich hält, die Informationshäppchen mit Hilfe von XML und den dazugehörenden Entitäten verwaltet. Mit anderen Worten: wir haben eine große Menge ausgabeunabhängiger Informationen in der Datenbank untergebracht, die wir vorsortiert haben und jetzt eigentlich nur noch herausfiltern müssen. Statt nun einen Filter zu programmieren, werden die Informationsknoten (hier in Schema ST4) zu Projekten gebündelt, indem im System eine Art Querverweisliste angelegt wird, die sich die referenzierten Knoten aus der Datenbank holt und zusammenstellt. Es liegt also immer noch kein „Buch“ im bildlichen Sinn vor, sondern eine Sammlung von Informationsknoten in einer definierten Reihenfolge.
Dies hat jedoch ein paar entscheidende Vorteile:
- „Systemneutralität“: Die Informationen im System sind systemneutral, weil sie in einem neutralen Datenformat (XML) vorliegen, die an kein Betriebssystem gebunden sind. Falls ein Wechsel auf ein anderes Betriebssystem oder eine aktuelle Systemversion durchgeführt wird, sind die Daten davon nicht betroffen.
- „Programmneutralität“: Die gleiche Voraussetzung gilt auch für Programme. Auch hier können die Daten mit einer Vielzahl unterschiedlicher Programme in das System eingefügt und auch wieder ausgelesen werden.
- „Ausgabeneutralität“: Die Unabhängigkeit geht jedoch noch einen Schritt weiter, denn dem Redaktionssystem ist es sogar völlig egal, ob die Informationen später gedruckt werden, auf einer Internetseite stehen oder als PDF weitergeleitet werden.
Letzteres ist für den Anwender am relevantesten.
Ausgabe und Templates
Für den Benutzer sieht das so aus: sobald es ans Veröffentlichen geht – sei es für eine Korrekturfassung oder die endgültige Ausgabe – wählt er das gewünschte Zielformat. Um die Daten entsprechend aufzubereiten, verfügt das Redaktionssystem über mehrere Konvertierungsprogramme, die die neutralen XML-Informationen entsprechend des Ziel-Datenformats umrechnen. Das kann ein definiertes Programm sein, beispielsweise ein Layoutprogramm, mit dem die Daten dann weiterverarbeitet werden, es kann aber auch eine direkte Konvertierung in HTML oder PDF sein.
Wie die Daten dann bei der Ausgabe aussehen, ob also die Überschrift in dunkelblau und fett oder in gelborange mager erscheint, das hängt davon ab, ob und wie das so genannte „Template“, also die Vorlage, eingestellt wurde. Die Einstellung erfolgt für gewöhnlich nur einmal für alle Dokumente eines Typs oder eines Unternehmens, denn es soll ja eine möglichst hohe Konsistenz in der Ausgabe erzielt werden. Das Layout kann daher sehr stark von dem Aussehen im Editor während der Bearbeitung abweichen.
Auch für Redakteure ist dies oft schwer nachvollziehbar, vor allem, wenn sie es gewöhnt sind, layoutorientiert zu arbeiten. Wer Überschriften daran erkennt, das sie ein bestimmtes Aussehen haben (und nicht eine Ordnungs- und Gliederungsfunktion), der wird die Darstellung im Editor immer als unbefriedigend empfinden und als ein Verlust der Orientierung – bis er das Ergebnis nach der Layoutierung durch das Template sieht. Da vorher jedoch alle inhaltlichen Bearbeitungsschritte erfolgt sind, hat der Bearbeiter kein visuelles Feedback für seine Arbeit. Ein Redaktionssystem ist in diesem Punkt aber unerbittlich: Struktur, Inhalt und Aussehen sind unterschiedliche Aspekte, die erst in der Publikation in einem Zielmedium zusammengeführt werden.
Dies ist jedoch gleichzeitig die große Stärke des Systems: Da die Informationen so lange wie nur möglich ausgabeneutral vorgehalten werden, ermöglicht diese Trennung eine sonst unerreichbare Flexibilität: Es muss nichts von einem (meist proprietäres) Format in ein anderes konvertiert werden – mitsamt der häufig nötigen Nacharbeit, weil die Konvertierung nicht verlustfrei vonstatten geht. Es kann sogar ohne weitere Nacharbeit parallel publiziert werden. Ein Handbuch für eine neue Softwareversion wird mit zwei Klicks sowohl als PDF in einem Druckformat produziert als auch als Onlinehilfe. Abweichung: Null (falls so definiert).
Mehrsprachigkeit
Durch die europäische Gesetzgebung forciert ist seit wenigen Jahren ein weiteres Betätigungsfeld auf die Redakteure zugekommen, auf dem sie mit einem Redaktionssystem besonders glänzen können: die Übersetzung.
Nur noch Kleinstdokumentationen und Einzelfertigungen für den heimischen Markt kommen um das Problem der Übersetzung in die Landessprache herum, denn schon im benachbarten Ausland muss das dort vertriebene Produkt von einer Dokumentation in Landessprache begleitet werden. Das ist nicht nur richtig und sinnvoll, sondern Gesetz. Schließlich soll ja auch in Frankreich oder Polen niemand zu Schaden kommen, nur weil er die Warnhinweise nicht lesen und verstehen konnte.
| Translation Memory„Ein Übersetzungsspeicher (auch Übersetzungsarchiv; engl. translation memory, abgekürzt TM) ist eine Datenbank mit strukturierten Übersetzungen, die die Hauptkomponente von Anwendungen zur rechnerunterstützten Übersetzung (Computer-aided translation, abgekürzt CAT) darstellt.[…] Ein Übersetzungsspeicher erfordert eine aufwändige Vor- und Nachbereitung sowie Datenpflege und bietet daher nur dann eine Erleichterung und Effizienzsteigerung, wenn immer wieder längere und gleichlautende Gebrauchstexte übersetzt werden (zum Beispiel Verträge, Bedienungsanleitungen, Wetterberichte). Bei kurzen Gelegenheitsübersetzungen und wechselnden Formulierungen ist der Aufwand für Vor- und Nachbereitung zu hoch und die Ausbeute an verwertbaren Datenbankeintragungen zu gering. TM-Systeme, die Funktionen zum Projektmanagement enthalten, erlauben das gleichzeitige Übersetzen langer Texte durch verschiedene Übersetzer unter Wahrung der terminologischen und stilistischen Konsistenz (Einheitlichkeit).“ (wikipedia) |
Ein Redaktionssystem, das an ein „Translation Memory System“ (TMS, siehe rechts) angeschlossen ist, verwaltet dieses Problem gleich mit. Redaktionssysteme verfügen nämlich über die Möglichkeit, Sprachversionen zu verwalten. Wenn also ein Informationsknoten in Deutsch (als Quellsprache) verfasst wird, kann das System überprüfen und anzeigen, ob ein entsprechender Informationsknoten auch in anderen Sprachen vorliegt und auf welchem Stand er ist: Hat schon eine Übersetzung in die Zielsprache stattgefunden, ist sie veraltet oder ist sie aktuell? Oder wird sie vielleicht gerade übersetzt? (Im letzten Fall sollte man sich natürlich hüten, den Knoten nachträglich zu ändern, weil dann die aktuelle Übersetzung wieder veraltet ist.)
Auf diese Weise passt zwischen die aktuelle Fassung in der Quellsprache und die Ausgabe in der Zielsprache kein Blatt. Das System ist sogar in der Lage, nur die Informationsknoten zu erkennen, die geändert wurden und nur diese wieder in den Übersetzungslauf zu schicken, was langfristig zu enormen Einsparungen bei den Übersetzungskosten führt. Auch wenn dies aus betriebswirtschaftlicher Sicht vielleicht der entscheidende „Killerfaktor“ sein mag, so hat dies auch redaktionell viele Vorteile, vor allem den der kürzeren Laufzeiten zwischen Freigabe und Ausgabe.
Denn auch hier sind die Systeme eisenhart: was nicht übersetzungstechnisch als aktuell erkannt wird, wird einfach nicht publiziert. Ohne wenn und aber. Dass dies natürlich eine enge Anbindung an einen Übersetzungsdienstleister und einen hohen Abstimmungsgrad erfordert, ist ein anderes Thema.
Fazit – vorläufig
Hat man sich einmal daran gewöhnt, fällt es sehr schwer, ohne ein Redaktionssystem zu arbeiten, denn die zahlreichen Verwaltungsschritte, die ein sauber definiertes und konfiguriertes System dem Redakteur abnimmt, muss er dann wieder „zu Fuß“ erledigen, was einerseits die Fehlerquote und die Bearbeitungszeit erhöht, und andererseits auch die Datenhaltungs- und Ausgabe-Sicherheit nimmt, die das System bietet. Der Aufwand für komplexere Dokumentationen im Anlagen- und Sondermaschinenbau sind ohne ein Redaktionssystem eigentlich nicht mehr vernünftig zu bewältigen. In diesem Industriezweig (und streng genommen im ganzen Maschinenbau) ist die Schmerzgrenze der manuellen Erstellung umfangreicher Dokumentationen sehr schnell erreicht. Die manchmal anzutreffende Annahme, man könne dies durch ein paar zusätzliche Redakteure auch abfangen, geht an der Tatsache vorbei, dass Ausgabesicherheit und Termintreue entscheidende betriebswirtschaftlich Vorteile sind. Deutschland ist schließlich kein Niedriglohnland.