Dieser Beitrag ist ein Abstract des gleichnamigen Vortrags des TANNER-Mitarbeiters Jürgen Schnurr, der zu diesem Thema auf der tekom-Jahrestagung 2014 referiert. Hören Sie den kompletten Vortrag: Dienstag, 11. November 2014, von 13:45 – 14:30 Uhr auf der tekom in Raum C6.2 im OG
Zwei Definitionen:
Ist Modularisieren eine Innovation?
Modularisieren wird oft als der Königsweg zu guter und bezahlbarer Technischer Dokumentation gepriesen. Das Argument ist, dass durch Wiederverwenden von bereits erstellten Modulen die Menge an zu schreibendem und zu übersetzendem Text kleiner wird und somit die Aufwände beim Erstellen und Übersetzen sinken. Bei großen Dokumentationsprojekten können mehrere Redakteure einfacher zusammenarbeiten, weil sie jeweils nur ein kleines Dokumentationsfragment statt des ganzen Dokuments bearbeiten.
Aber dies ist nichts Neues. FrameMaker- oder Interleaf-Anwender kennen solch modulare Dokumente seit Jahrzehnten. Natürlich hat man die Dokumente für neue Produkte nicht immer von Grund auf neu geschrieben, sondern hat Varianten-Management eingesetzt oder ein neues Dokument von einem bestehenden Dokument abgeleitet. Das heißt, das Modularisieren von Dokumenten ist keine Neuheit und kann somit keine Wunder bewirken. Mit dem Umstieg auf DITA und/oder der Einführung eines Redaktionssystems kann man effizienter mit kleineren Modulen arbeiten. Ein Redaktionssystem ermöglicht einer organisierten Redaktion, mehr Module im Griff zu haben.
Warum reden alle vom “alten Hut” Modularisieren?
Bei der Softwareerstellung, in der Produktion und auf dem Bau werden schon seit langer Zeit Produkte modular erstellt. Aber dort ist das Arbeiten mit Modulen ein übliches Verfahren, über das kaum noch grundsätzlich diskutiert wird. Wenn in der Technischen Dokumentation seit langem modularisiert wird und trotzdem immer noch darüber diskutiert wird, müssen grundsätzliche Probleme existieren.
Wieso funktioniert das Modularisieren von Dokumenten häufig nicht?
Modularisieren von Dokumenten bedeutet, dass man nach wie vor das Dokument in den Mittelpunkt stellt. Zu oft werden die Module nicht als eigenständige Objekte verstanden, sondern als Teile eines Ganzen behandelt. Wenn man diese dokumentbezogene Sichtweise auch bei komplexen Produkten bzw. Produktreihen beibehält, schieben sich die Nachteile der Modularisierung immer stärker in den Vordergrund: Man denkt weiterhin dokumentzentriert, aber dokumentbezogene Arbeitstechniken wie “Suchen” oder “Suchen & Ersetzen” über das Dokument funktionieren nicht. Je feiner man modularisiert, desto mehr Module müssen verwaltet werden. Je mehr Module existieren, desto größer ist die Gefahr, dass Dubletten angelegt werden. Da die Module zu stark im Kontext der Dokumente stehen, ergibt sich folgendes Spannungsfeld: Wenn man konkret auf das Produkt eingeht, sind die Module nicht mehr wiederverwendbar. Wenn man starken Fokus auf die Wiederverwendbarkeit legt, besteht die Gefahr, dass nichtssagende, abstrakte Module entstehen. Die Metadaten der Bausteine sind eine Herausforderung: Wenn zu wenige Metadatenfelder vorliegen, kann man die Bausteine nicht finden. Wenn zu viele vorliegen, steigt der Verwaltungsaufwand. Damit steigt auch das Risiko von unvollständig oder falsch befüllten Metadatenfeldern. Sehr häufig schleicht sich bei den Redakteuren das Gefühl ein, dass sie das Dokument nur zerlegen, um es dann wieder zusammenzubauen.
Die Idee, Dokumente zu modularisieren, ist der falsche Weg
Erfolgreiche Software- und Produktionsprozesse modularisieren keine Programme bzw. Produkte, sondern setzen Endprodukte aus Modulen zusammen. Die Module selbst sind eigenständig. Die Idee, Dokumente zu modularisieren, bedeutet im Idealfall: Man zerlegt das Dokument in Module und verwendet diese Module in anderen Dokumenten wieder. Dieser auf den ersten Blick logische und eingängige Weg führt bei der konkreten Umsetzung zu Problemen. Denn die Module werden nach wie vor aus Dokumentensicht geschrieben. Es ist illusorisch zu erwarten, dass beim Zerlegen von Dokumenten Standardbausteine entstehen. Vor allem, wenn man beachtet, dass die meisten Dokumente durch Ableiten aus anderen Dokumenten entstehen. Beim Ableiten entstehen Änderungen im Dokument nicht nur wegen anderer Sachverhalte in den jeweiligen Produkten, sondern auch, weil subjektive Ansichten der beteiligten Ingenieure und Redakteure einfließen. Die Unterschiede durch subjektive Änderungen beschränken sich nicht auf Formulierungsmuster. Sie können auch das Erwähnen oder Weglassen von Details sein. Die eine Person hält sie für wichtig, die andere nicht. Nur durch Vergleichen der Dokumente kann man diese subjektiven Änderungen nicht erkennen, dies erfordert zusätzlich fundierte Produktkenntnisse.
Technische Dokumentation kann man nicht vom Produkt lösen
Die Gliederung des Dokuments ist eine Struktur, die es den Anwendern leicht macht, die notwendigen Informationen zu finden. Die Module müssen im Dokument in dieser Struktur angeordnet werden. Es stellen sich jedoch folgende Fragen:
Technische Dokumentation ist Produktinformation. Man kann sie nicht beliebig organisieren. Um eine gute Technische Dokumentation zu erstellen, müssen die Redakteure die Struktur des Produktes kennen und verstehen, wie Funktionen des Produktes von den Produktdetails abhängen.
Nur dann sind sie in der Lage zu verstehen, auf welche Stellen im Dokument sich Änderungen von Produktdetails auswirken. Leider ist dieses Wissen zu häufig nicht explizit im Dokument hinterlegt, sondern befindet sich ausschließlich in den Köpfen der Redakteure. Deshalb ist es so schwierig, Dokumente zu bearbeiten, die von anderen Personen erstellt wurden.
Wie kann man effektiv modularisieren?
Man organisiert die Module entsprechend der Produktstruktur. Jedes Datenmodul wird einem Produktdetail zugeordnet. Umgekehrt betrachtet hat jedes Produktdetail die Datenmodule zugeordnet, die von ihm beeinflusst werden. Das Verknüpfen der Module mit den zugehörigen Produktdetails hat folgende Vorteile: Die Zuordnung zwischen Produktinformation und Produktdetail wird explizit. Wie wiederverwendet wird, entscheiden die Produkte. Wenn ein neues Produkt ein Produktdetail wiederverwendet, verwendet das neue Dokument die Module des Produktdetails. Da man weiß, welche Varianten zu einem Produktdetail tatsächlich vorliegen, kann man eine gute Entscheidung zur Detailtiefe und den erforderlichen Modul-Varianten treffen. Wenn sich zwei Produktdetails nur in Sachverhalten unterscheiden, die für die Technische Dokumentation nicht relevant sind, kann man ihnen dieselben Module zuordnen. Die Position des Produktdetails in der Produktstruktur gibt vor, welche Informationen ein Modul enthalten darf, ohne seine Wiederverwendbarkeit einzuschränken.
Regeln zur Erhaltung der Wiederverwendbarkeit von Modulen
