| Aktuelle Artikel und Nachrichten rund um die technische Dokumentation finden Sie im Nachfolgemagazin der doculine news, den transline tecNews
Single Source Publishing aus Anwendersicht:
Der Redakteur als Informationsmanager
Artikel erschienen in
Ausgabe Juli/August 2002
Von Armin
Hoffmann
Inhaltsübersicht:
Technische Redakteure sehen sich nicht
erst seit heute mit den Forderungen nach immer effizienterer Dokumentenerstellung
und Publikation in verschiedene Zielmedien – Druck, Web,
CD-ROM und Online-Hilfe – konfrontiert. Mit den Stichworten
XML und Single Source Publishing (SSP) wird oft die einfache Lösung
für diese Problemstellung in Aussicht gestellt. Doch nur
unter den richtigen Voraussetzungen verspricht die Einführung
einer SSP-Lösung Erfolg.
Damit erhält allerdings der Redakteur
neue Möglichkeiten: Er kann sich am Aufbau eines Informationsmanagement-Systems
beteiligen, das über die reine Erstellung von Dokumentation
hinausgeht und über den gesamten Produktlebenszyklus hinweg
Informationen für andere Bereiche wie Entwicklung, Vertrieb
oder Schulung zur Verfügung stellen kann. Dies soll im Folgenden
am Beispiel eines Dokumentationsprojekts erläutert werden,
das mit dem Redaktionssystem SchemaText realisiert wurde.
Allgemeine Projektanforderungen
Ein Redaktionssystem für Single Source Publishing einzuführen,
ist insbesondere dann sinnvoll, wenn mehrere der folgenden Anforderungen
bestehen:
- Kurz- oder mittelfristig sollen mehrere Zielmedien bedient
werden.
Trotz aller zusätzlich geforderten oder gewünschten
Ausgabeformate steht die Produktion von gedruckte Dokumenten
nach wie vor im Vordergrund – einerseits weil Kunden die
Übergabe einer Druckfassung als selbstverständlich
voraussetzen, andererseits als Referenz in Streitfällen.
Das System muss also einfach hochwertige Dokumentation erzeugen
können. Nach Möglichkeit sollte keine dauerhafte Festlegung
auf ein einziges Druckformat nötig sein, sondern der Datenbestand
soll ohne Konvertierung oder Anpassung auch für die Ausgabe
zusätzlicher Print-Formate nutzbar sein.
Die Generierung von HTML für Internet, Intranet, Extranet
und CD-ROM sollte eine Selbstverständlichkeit sein. HTML-Produkte
sind sofort für die hausinterne Information nutzbar und
können sehr schnell für Marketing- und Vertriebszwecke
eingesetzt werden.
Oft besteht auch die Anforderung, Online-Hilfe sofort oder in
absehbarer Zeit nutzen zu können. Auch diese muss natürlich
ohne großen Zusatzaufwand aus dem gleichen Datenbestand
erzeugt werden können.
- Wiederverwendung statt doppelter Datenhaltung
Allgemein verwendbare Standard-Informationsbausteine und individuell
für einzelne Produkte erstellte Bausteine (Varianten) sollen
für verschiedene Dokumentationsprodukte verwendet und an
einer Stelle zentral verwaltet und bearbeitet werden, um doppelte
Datenhaltung bzw. aufwendigen Abgleich zwischen voneinander
abgeleiteten Dokumenten zu vermeiden. Durch die Verknüpfung
produktspezifischer Strukturen mit den Inhalten eines Content
Repository soll ein hoher Wiederverwendungsgrad bei maximaler
Flexibilität der Projektdokumentation erreicht werden.
- Es müssen Varianten und/oder Versionen verwaltet
werden.
Sämtliche Varianten und Optionen für ein neues Projekt
sollen auf Anhieb zur Verfügung stehen, ohne sie erst aus
verschiedenen Datenbeständen zusammenstellen zu müssen.
Dabei kann nicht nur auf die aktuelle Version, sondern auch
auf beliebige vorherige Stände zurückgegriffen werden.
- Die Informationen liegen in mehreren Sprachen vor.
Mehrsprachigkeit erfordert von einem Redaktionssystem einerseits
komfortablen Zugang zu den Inhalten in den verschiedenen Fremdsprachen
unter Wahrung des Zusammenhangs mit den Ausgangssprachen und
andererseits Funktionen für das Übersetzungsmanagement
(Vermeidung von mehrfachen Übersetzungen, Auftragsmanagement,
Anbindung an Translation-Memory-Systeme).
- Schnittstellen zur Datenübernahme
Teilekataloge, ERP-Systeme wie SAP R/3 oder andere Datenquellen
sollen angebunden werden.
- Hohe Änderungsdynamik
Änderungen sollen für Standardbausteine zentral an
einer Stelle für alle betroffenen Dokumente durchgeführt
und nach Bedarf publiziert werden. Dabei muss das System die
Einhaltung von Workflows für Erstellung, Review und Freigabe
unterstützen und gewährleisten.
Vorgehen bei der Umsetzung
Sind die Anforderungen an das Redaktionssystem erst einmal definiert,
erfolgt die Einführung in vier Phasen. In allen Projektphasen
kommt der Redaktion als Know-how-Träger und Ideenlieferant
entscheidende Bedeutung zu. Für den Projekterfolg ist entscheidend,
ob die Redaktion ihr eigenes Wissen über Stand und Weiterentwicklungsmöglichkeiten
des Informationsmanagements aktiv einbringt und das Management
ihren Bewertungen und Vorschlägen den nötigen Raum gewährt.
Erste Phase: Analysephase
- Analyse der internen Ist-Situation:
In welcher Form liegt der Datenbestand vor? Wie gut ist der
Datenbestand inhaltlich bereits strukturiert? Welche Tools werden
für Erstellung, Übersetzung und Ausgabe verwendet?
Welche Schnittstellen zu anderen Systemen werden genutzt? Welche
Erstellungsprozesse existieren zur Zeit? Welche Rollen sind
an den Prozessen beteiligt?
- Ermittlung oder Präzisierung der Kundensicht/Kundenwünsche:
Welche Struktur des Informationsbestands ist angestrebt? Welche
Medien sollen erzeugt werden? Welche Werkzeuge sollen weiterhin
verwendet werden, welche entfallen? Wie können bestehende
Prozesse optimiert werden?
- Einbeziehung erkennbarer Trends:
Welche Technologien müssen von vornherein eingeplant werden?
Zweite Phase: Entwicklung eines Dokumentationskonzeptes
- Erstellung einer für die gesamte Organisation einheitlichen
Sicht auf die Produkte in Form einer hierarchischen Baumstruktur
der Komponenten:
Unterschiedliche Sichtweisen auf Produktmodule und -komponenten
(z.B. können die Sichtweisen von Entwicklung, Vertrieb
und Marketing erheblich auseinanderklaffen) werden im Konsens
auf eine unternehmensweit einheitliche Sicht von Hierarchie,
Varianten und Optionen zusammengeführt.
- Definition von Zielgruppen für die verschiedenen Informationen:
Oft existieren entweder heterogene oder unscharfe Vorstellungen
über die Personenkreise, für die Dokumentation erstellt
wird; nur die genaue Kenntnis des Adressatenkreises erlaubt
aber zielgruppengerechte Zusammenstellung und Aufbereitung der
Inhalte.
- Definition von Informationsarten:
In der Regel ergibt sich bereits aus der vorhandenen Dokumentation
eine Unterteilung in verschiedene Arten von Informationen. Auf
dieser Basis werden notwendige Änderungen oder Ergänzungen
ermittelt. Dadurch entsteht eine Liste aller im System zu erfassenden
Informationsarten: technische Beschreibung, Bedienungsanweisungen,
Wartungsarbeiten, Ersatzteile, OEM-Dokumente, Schulung usw.
Dritte Phase: Strukturierung des Informationsbestands
In einer Makrostruktur wird das Beziehungsgeflecht der einzelnen
Informationsbausteine und deren Umfang festgelegt (Modularisierung).
Dem technischen Aufbruch der Produkte werden die vorhandenen Informationsarten
zugeordnet. Die daraus resultierende Inhaltsstruktur, die definierten
Informationsarten und die Verknüpfungen zwischen Anlagenhierarchie
und Informationsarten werden im Redaktionssystem abgebildet.
Für die verschiedenen Informationsarten legt eine Mikrostruktur
den Aufbau der einzelnen Informationsbausteine fest. Hier wird
beliebig kleinteilig je nach Projektanforderung definiert, welche
Informationen ein Beschreibungs-Baustein enthalten muss (Aufbau,
Funktion, Wirkungsweise etc.) und welche Struktur für einen
Bedienungs-Baustein vorgegeben wird. Einzelne Bausteine sollten
immer so groß sein, dass sie komplette Sinneinheiten bilden,
die auch in anderen Zusammenstellungen verwendet werden können.
 |
| Makro- und Mikrostrukturierung
des Informationsbestandes |
Vierte Phase: Pilotbetrieb
Anhand eines geeigneten Pilotprojekts werden die vereinbarten
Prozesse getestet und der für den Produktivbetrieb notwendige
Feinschliff vorgenommen.
Abläufe im redaktionellen Alltag
Die Erstellung, Bearbeitung und Verwaltung von Inhalten unterliegt
idealerweise einem Rollenspiel mit klar abgegrenzten Verantwortlichkeiten
zwiwschen Content Provider, technischem Redakteur und Publisher.
Der Content Provider verfügt über Fachwissen, das er
mittels Standard-Editoren erfasst (z.B. Microsoft Word) und dem
Redakteur zur Verfügung stellt. Hier soll nach Möglichkeit
an bestehenden Werkzeugen festgehalten werden, soweit dies sinnvoll
ist. Da es sich bei den Content Providern in der Regel um die
größte am Dokumentationsprozess beteiligte Gruppe handelt,
wirkt sich anfallender Schulungsaufwand besonders kostenintensiv
aus und sollte nach Möglichkeit auf ein Mindestmaß
beschränkt werden. Außerdem sollte der Ingenieur oder
Techniker nicht über Gebühr durch Dokumentationsaufgaben
belastet werden. Nicht zuletzt steigt die Bereitschaft zur Kooperation
mit dem technischen Redakteur erfahrungsgemäß mit der
Einfachheit der durchzuführenden Handlungsschritte.
Der technische Redakteur ist für Recherche, Überarbeitung
und Verwaltung der Inhalte zuständig. Hinzu treten hier in
stärkerem Maße die Pflege der Dokumentstrukturen und
die Definition der zu erzeugenden Medienprodukte. Ferner sind
Redakteure gefragt, um zusätzliche Informationsarten im Sinne
eines Informationsmanagement-Systems in den Kontext des Redaktionssystems
einzuführen. Der Redakteur hat den nötigen Einblick,
wie Rationalisierungspotenziale durch die Nutzung bereits im System
befindlicher Daten in Kombination mit anderen, bisher außerhalb
gelagerten Daten realisiert werden können.
Der Publisher – nicht selten identisch mit dem Redakteur
– produziert für jede Zielgruppe die benötigten
Informationen im geeigneten Medium. In diesen Bereich fallen das
Generieren der Zieldaten, das Nachbearbeiten im Print-Bereich
(Endlayout, Umwandlung in PDF), Verfügbarmachung und Konfektionierung.
 |
| Im redaktionellen Alltag gibt
es klar abgegenzte Verantwortlichkeiten zwischen Content Provider,
technischem Redakteur und Publisher. |
Das Szenario zu Projektbeginn
Ein Anlagenbauer fertigt Dampfturbinen auf Basis verschiedener
Grundtypen individuell nach Kundenwunsch. Die Fachabteilungen
liefern Standarddokumentation, je nach realisiertem Turbinentyp.
Die Inhalte dieser Teildokumentationen werden mit den Auftragsunterlagen
im Einzelfall abgeglichen und textlich und grafisch nachbearbeitet.
Soweit die Unterlagen elektronisch erfasst sind, werden sie an
ein einheitliches Erscheinungsbild angepasst. Dokumentation wird
ausschließlich in Papierform ausgeliefert und archiviert.
Die Datenhaltung in elektronischer Form erfolgt in der Regel dezentral
in den Fachabteilungen. Sofern Texte bereits elektronisch erfasst
wurden, liegen sie hauptsächlich im unternehmensweit vorgeschriebenen
Word-Format vor. Die Dokumentation wird auf deutsch erstellt und
standardmäßig ins Englische übersetzt. Bestimmte
Teile wie das Bedienhandbuch werden in Landessprache ausgeliefert.
Durch die dezentrale Ablage der Originale und deren Versionsvielfalt
müssen viele Inhalte bei jedem Auftrag erneut übersetzt
werden.
Folgende Zielvorstellungen waren für die Entscheidung, den
Dokumentationsprozess mit Hilfe eines Single-Source-Publishing-Systems
neu zu strukturieren, maßgeblich:
- Durch eine klare Definition des Erstellungsprozesses wird
dieser für alle Beteiligten transparenter.
- Der Einsatz von Standardwerkzeugen wie SchemaText und MS
Word in Verbindung mit vorgegebenen Grafikformaten strafft die
Abläufe und verringert die Bearbeitungszeiten.
- Die gezielte Strukturierung und hierarchische Gliederung
der Gesamtanlage ermöglicht die gezielte Wiederverwendung
von Informationen.
- Die Zusammenfassung aller Inhaltsstrukturen und deren Verknüpfungen
sowie der Informationen in einem Redaktionssystem auf der Basis
einer zentralen Datenbank macht neben einer Wiederverwendung
der Dokumentationsbausteine eine gezielte Übersetzung nur
jener Inhalte möglich, die nicht bereits für einen
anderen Auftrag übersetzt wurden bzw. deren ausgangssprachliche
Inhalte verändert wurden. Über der Füllgrad der
Dokumentation in den verschiedenen Sprachen kann jederzeit eine
detaillierte Aussage gemacht werden.
- Kunden fordern immer stärker die Auslieferung der gesamten
Dokumentation nicht nur in einer gedruckten Fassung, sondern
auch in elektronischer Form als PDF-Dateien sowie als HTML-Format.
Insgesamt soll besser als bisher gewährleistet sein, dass
die Kundendokumentation
- in einheitlichem Erscheinungsbild
- qualitativ hochwertig
- unter Beachtung von Produkthaftungs- und Qualitätssicherungsvorschriften
- zeitnah nach Auftragserteilung
- in Papierform und elektronisch (PDF und HTML) und nicht zuletzt
- mit geringerem finanziellen Aufwand
ausgeliefert werden kann.
Dabei ist wichtig, dass sich das Redaktionssystem an die bestehenden
bzw. verbesserten Prozesse und Werkzeuge anpasst und somit unnötiger
Umstellungs- und Schulungsaufwand gar nicht erst entsteht.
SchemaText als Redakteursarbeitsplatz
Im Zentrum der Single-Source-Publishing-Lösung steht der
SchemaText-Client als Redakteursarbeitsplatz. Hier werden die
zentralen Funktionen bedient wie:
- Strukturierung des Gesamtinformationsbestands
- Ableiten der Strukturen für Produkt- und Projektdokumentationen
aus der Gesamtstruktur
- Definition der Zielprodukte
- Verwaltung aller Inhalte und zugehöriger Metadaten
Die Dateneingabe auf Seiten der Content Provider erfolgt in Microsoft
Word. Bei der korrekten Erfassung unterstützt eine vorgefertigte
Dokumentenvorlage den Bearbeiter, mit der nur zuvor festgelegte
Absatz- und Zeichenformate, Grafiktypen und Tabellen zugewiesen
werden können.
Bedingt durch die Ablage der Daten in medienneutralem XML handelt
es sich bei der Erfassung der Texte nicht mehr im gleichen Umfang
wie bisher um Eingabe und Layout, sondern um strukturierte Erfassung.
Den Textabschnitten und Zeichen wird über Absatz- und Zeichenformate
eine Strukturinformation zugewiesen. Erst beim Generieren der
Zielformate werden diese Strukturinformationen wieder um formatspezifische
Layoutinformationen ergänzt.
Dem Redakteur erspart dies ein aufwendiges Nachbearbeiten der
Formatierungen. Metadaten, die für die Bearbeitung durch
den Autor freigegeben sind, können für den aktuell bearbeiteten
Informationsbaustein direkt in Word gesetzt werden.
 |
| Datenerfassung mit Microsoft
Word |
Der SchemaText-Redakteursarbeitsplatz erlaubt die Strukturierung
des Informationsbestands, die Pflege der Inhalte und die Erzeugung
der gewünschten Medienprodukte. Darüber hinaus kann
auf den Metadaten ein Workflow- und Berichtsmanagement aufgesetzt
werden. So stehen Informationen zu Projektstatus, Fertigstellungsgrad
usw. ständig zur Verfügung. Ein Verwaltungs-Overhead
durch separat geführte Listen oder Statistiken entfällt.
Für den Redaktionsleiter oder Projektmanager kann darüber
hinaus ein Projektplan nach Microsoft Project exportiert werden.
Dort können dezentral Ressourcenzuteilung und Termine geändert
werden, die anschließend wieder ins Redaktionssystem zurückfließen.
Für die Anbindung der Übersetzer sorgt ein komfortabler
Exportmechanismus, der ganze Projekte, Auswahlbereiche oder über
Filterfunktionen die noch nicht übersetzten Inhaltsbausteine
in eine für Translation-Memory-Systeme wie z.B. Trados vorbereitete
XML-Datei schreibt. Die Rückübernahme der fertigen Übersetzungen
in die entsprechende Sprachperspektive erfolgt automatisch.
 |
| Grafische Darstellung der Informationsbausteine
und ihrer Verknüpfungen in SchemaText DocuManager |
Fazit
Schon in der Konzeptionsphase kann sich der technische Redakteur
aktiv in die Gestaltung der Publishing-Lösung einbringen.
Durch die Integration der Dokumentation und zusätzlicher
Inhalte in das Redaktionssystem wird die Stellung des Redakteurs
gestärkt, da er immer mehr Informationen für immer mehr
Personen im Unternehmen zur Verfügung stellen kann.
Durch Zeit- und Ressourceneinsparungen sinkt die Auslastung des
Redakteurs hinsichtlich der klassischen Tätigkeiten wie Inhaltspflege
und Layout. Zudem sinkt durch die Erzeugung mehrerer Ausgabeformate
aus dem gleichen Informationsbestand der Aufwand für die
Erstellung von Websites und Online-Hilfen.
Im Vergleich zu konventioneller Dokumentationserstellung werden
Betätigungsfeld und Einfluss des technischen Redakteurs mit
der Einführung eines Single-Source-Publishing-Systems deutlich
erweitert – der Redakteur wird zum Informationsmanager.
Leserbrief schreiben
|
