Dr. Walter Fischer, Geschäftsführer Fischer Computertechnik
Nur wer mit der richtigen Technik arbeitet, behält die Übersicht.
Worauf Sie beim Kauf eines Systems zur Technikdokumentation achten sollten, haben wir mit Dr. Walter Fischer, Geschäftsführer Fischer Computertechnik, diskutiert.
Unter dem großen Sammelbegriff Content-Management-Systeme (CMS) finden sich Web-Content-Management-Systeme (Web-CMS) genauso wie Redaktionssysteme, die speziell auf die Belange technischer Redakteure ausgerichtet sind. Während Web-CMS unternehmensübergreifende News, Online-Informationen unternehmensintern und auch extern in einem Portal, Intranet oder Extranet bereitstellen, geht es bei der Technikdokumentation darum, eine Maschine oder eine Software bis ins letzte Detail zu dokumentieren. Was zeichnet nun ein Redaktionssystem, also ein System für die Technikdokumentation aus?
Fischer: Produktorientierte Fragen stehen im Vordergrund. Eine Maschine gibt es immer in verschiedenen Ausführungen, in verschiedenen Varianten. Nehmen wir das Beispiel Auto: Da gibt es ein Grundmodel. Dann gibt es die Ausführung mit Schiebedach, mit oder ohne Navigationsgerät, mit oder ohne Klima-Anlage. Der Kunde sollte nun eine Dokumentation erhalten, die exakt dem gekauften Autotyp entspricht. Hat er also ein Auto ohne Schiebedach gekauft, soll dieses in seiner Anleitung auch nicht in epischer Breite erklärt werden. Aber auch die Wartungsanleitungen für die Werkstätten müssen auf die jeweilige Variante zugeschnitten sein.
Und wie rückt ein Redaktionssystem diesem Variantenreichtum zu Leibe?
Fischer: Technische Dokumente sind in Module zu zerlegen, und zwar so, dass die einzelnen Informationseinheiten logisch schlüssig und zugleich möglichst oft wieder verwendbar sind. Ein Informationsmodul kann eine Graphik, eine Seite oder ein ganzes Kapitel über mehrere Seiten sein. In einem Masterdokument sind dann alle Varianten einer Maschine, in unserem Beispiel eines Autos, in Modulen beschrieben. Beim Kauf konfiguriert der Händler das individuelle Auto für seinen Kunden: PS-Stärke, Schiebedach und so weiter. Gleichzeitig werden aus dem Masterdokument die betreffenden Module herausgefiltert. Eine Liste zeigt auf, was gebraucht wird, und das System erzeugt automatisch das Dokument für den Kunden
Wie ist das möglich?
Fischer: Durch eine Verbindung der Stücklisten, die die einzelnen Bauteile aufzählen, mit den Textbausteinen.
Werden die Stücklisten nicht in den Enterprise-Ressource-Planing-Systemen (ERP) erzeugt?
Fischer: Natürlich: das ERP-System kennt die Stücklisten. Es weiß, was bestellt wurde. Hier ist eine Integration von ERP- und CMS-System gefragt. Im Vordergrund steht der Prozess, der festlegt, zu welcher Baugruppe welche Dokumente gehören.
Ist das Zukunftsmusik oder Realität?
Fischer: Noch gibt es kein ERP-System mit integriertem XML-Redaktionssystem. Es gibt Ansätze die Produktmerkmale, welche in einem Katalog benötigt werden, in einem ERP-System abzulegen, um damit aus dem ERP-System Produktkataloge oder auch Ersatzteilkataloge automatisiert zu erstellen. Für die Technische Dokumentation benötigt man aber eine Zuordnung zwischen den Baugruppen (funktional- und aufbauorientiert) und den zugehörigen Informationseinheiten (Texte, Grafiken etc.) der Technischen Dokumentation. Daran scheitern die meisten ERP-Systeme, weil sie diese Beziehung nicht berücksichtigen. Darüber hinaus braucht man Tools, um diese Informationseinheiten strukturiert zu bearbeiten und den Publikationsprozess zu unterstützen.
Maschinen werden kontinuierlich weiterentwickelt. Bauteile ändern sich. Wie kann der Redakteur auf Änderungen reagieren, wie kann er sie in den Text einpflegen ohne die Konsistenz, die Schlüssigkeit des Textes, zu gefährden?
Fischer: Redaktionssysteme verfügen über ein Änderungsmanagement. Bauteile werden häufig geändert. Textmodule sind zu ändern, anzupassen. Zu klären ist, in welchen Varianten der geänderte Baustein verwendet wird. Welche Textmodule sind zu überarbeiten? Wo bestehen Bezüge, Querverweise zu anderen Textstellen? Und was muss neu übersetzt werden? Damit der Redakteur die betreffende Stelle nur einmal ändern muss, hilft Single-Source-Publishing: ein und dasselbe Modul kann zeitgleich in mehreren Dokumenten, Dokumententypen oder sogar in ganz verschiedenen Medien verwendet werden, ohne wirklich mehrfach und in unterschiedlicher Form vorhanden zu sein. Der Vorteil: Der Redakteur kann mehrere Dokumente zeitgleich ändern, indem er lediglich das entsprechende Informationsmodul verändert – ein wichtiger Schritt, um Inkonsistenzen zu vermeiden. Natürlich muss der Redakteur die richtigen Bausteine finden. Wer hier nicht lange suchen muss, spart viel Geld. Deshalb ist es wichtig, dass ein Redaktionssystem den Bezug von Content und Produkt herstellen kann. Im Idealfall kann ein Redaktionssystem dem Redakteur die betreffenden Textstellen automatisch suchen.
Deutschland ist Exportweltmeister. Das heißt, dass die Dokumentationen meist auch noch in 20 bis 30 Sprachen vorliegen müssen. Für einen Webauftritt reichen meist Englisch, Französisch und Deutsch.
Fischer: Auf Produktseite ist aus Haftungsgründen die Dokumentation in der Sprache des Kunden zu verfassen. Der Normalfall ist also: Wir haben eine Maschine von der es 50 Varianten gibt, und für jede diese Varianten müssen Produktdokumentationen in 20 Sprachen vorgehalten werden. Knackpunkt ist auch hier die Modularisierung. Bei Änderungen oder Varianten muss der Übersetzer nur noch die nicht übersetzten Textstellen in eine andere Sprache übertragen.
Systeme machen sich für den Anwender vor allem dann bezahlt, wenn sie auf Standards basieren und damit mit anderen Systemen problemlos kommunizieren können. Auf welche Standards sollten die Anwender beim Kauf eines Redaktionssystems achten?
Fischer: Natürlich XML (extensible markup language)!
Aber XML ist nicht gleich XML?
Fischer: Ja in XML lassen sich beliebig viele Strukturen festlegen. Deshalb gibt es DITA (Darwin Information Typing Architecture). IBM hat DITA kreiert, um die eigene Software besser zu entwickeln. Bei DITA geht es darum, auch die Strukturen innerhalb von XML zu standardisieren. Ein wichtiger Schritt, der die Modularisierung von Softwaredokumentationen weiter vorantreibt. Allerdings ist DITA wenig geeignet für den Maschinenbau. DITA behandelt vor allem die Funktionen eines Systems, nicht die Aufbaustruktur. Für Software ist das kein Problem: Sie besteht vor allem aus Funktionen, die zu unterscheiden und zu dokumentieren sind. Gerade hierfür ist DITA entwickelt worden. Eine Maschine oder Anlage ist aber aufbau- (Produktstruktur) und funktionsorientiert. Das heißt eine Bedienungsanleitung für eine Maschine muss alle Strukturen, nämlich Aufbau-, Funktions- und Dokumentenstruktur berücksichtigen.
Und woran sollten sich dann die Maschinenbau orientieren?
Fischer: An mumasy (Multimediales Maschineninformationssystem). Der VDMA (Verband des deutschen Maschinen- und Anlagenbaus) hofiert diesen Standard. Noch wird fleißig daran gearbeitet, die Strukturen zu definieren.
Mit welchem Ziel wurde mumasy ins Leben gerufen?
Fischer: Ziel des Projektes war es, ein herstellerunabhängiges Informationsmodell für den Maschinenbau zu schaffen, das den Datenaustausch zwischen Zulieferern, Hersteller und Kunden erleichtert. Dann können auch die Dokumentationen der Zulieferer in die eigene Dokumentation integriert werden. Der Zulieferer schickt ein Komplettdokument. Der Automobilhersteller braucht aber nur Teile davon für seine eigene Dokumentation. Mit einem standardisierten XML-Dokument kein Problem. Herstellerübergreifend können dann Dokumente zusammengestellt werden.
Wir haben ja bereits die enge Verzahnung von Redaktionssystemen und ERP-Systemen angesprochen, wo sehen sie die Berührungspunkte zu Enterprise-Content-Management- Systemen (ECM)?
Fischer: Natürlich gibt es hier auch Berührungen: Die Produktkataloge verbinden zumindest die Redaktionssysteme mit den WEB-CMS. Viele Maschinenbauer packen die Daten aus der Technikdokumentation, also die Gewindelängen, Hublängen und Leistungsdaten, in einen Produktkatalog und der wird dann gedruckt oder einfach ins Internet gestellt. Ansonsten ist zu sagen: Die Redaktionssysteme beschäftigen sich vor allem mit der Dokumentenerstellung, die ECM-Systeme mit der Dokumentenverwaltung. Die Modularisierung könnte man noch weiter vorantreiben. Bisher hatten wir die Module für die Technikdokumentation gebraucht. Man könnte aber noch einen Schritt weiter gehen, und die Module aus der Technikdokumentation so aufbereiten, dass sie sich auch für kommerzielle Dokumente wie zum Beispiel Angebote eignen.
Kommen die ECM-Hersteller damit nicht den Product-Lifecycle-Management- Produkten (PLM) in die Quere?
Fischer: Dokumentenmanagement respektive ECM impliziert, dass der gesamte Content eines Unternehmens, also alle kommerziellen Dokumente, alle technischen Dokumente und alle Konstruktionszeichnungen, unternehmensweit verwaltet werden. PLM umfasst – wie der Name schon sagt – den Lifecycle der Produktdaten inklusive der Logistik. Bekannt ist beispielsweise das PLM von SAP. Hier sind alle Konstruktionszeichnungen, technischen Daten, 3-D-Animationen und so weiter verwaltet. Im Gegensatz hierzu kümmert sich das ECM vor allem um die kommerziellen Dokumente also um Lieferscheine, Angebote, die ganze Verkaufsabwicklung. Aber die Integration schreitet voran. Die Grenzen zwischen PLM und ECM werden immer fließender. SAP macht’s vor. Allerdings tummeln sich auf dem ECM- Markt noch sehr viele proprietäre Lösungen, die diese Hürden so nicht nehmen.
Wohin wird sich der Markt für Technische Redaktionssysteme entwickeln?
Fischer: Sicher ist, dass die Redaktionssysteme immer mehr Bestandteil von PLM-Produkten werden.