Viele Fragen …

Wenn Sie sich gerade mit der Vorstellung beschäftigen, Ihre technische Dokumentation auf XML umzustellen, stellen sich Ihnen viele Fragen. Sollen wir auf ein branchenübliches XML-Datenmodell wie etwa S100D, DITA oder DocBook oder gar XHTML setzen? Oder soll eine davon abgeleitete, „verschlankte“ Variante entwickelt werden, die z.B. überflüssige, gar nicht benötigte Strukturen weglässt oder das gewünschte Modell um eigene Elemente ergänzt? Oder soll doch lieber gleich ein ganz eigenenes Datenmodell zum Einsatz kommen, das die individuellen Anforderungen besser abdeckt, als ein Standardmodell? Und mit welchen Tools soll gearbeitet werden? Müssen die Autoren künftig in Quelltext-Editoren zwischen Tag-Wüsten ihren Text tippen und wie in den Anfangstagen des Computersatzes Formatierungsanweisungen händisch eintippen? Oder gibt es auch professionelle Textverarbeitungs-Tools, mit denen man komfortabel und visuell ansprechend XML-basierte, strukturierte Texte erfassen kann? Ggf. gar auch gleich mit einem Authoring Assistant? Und wie entsteht aus der XML-Quellcodewüste hinterher (möglichst einfach und komfortabel) ein ansehnliches PDF – und zwar bitte mit „klickbaren“ Querverweisen, IVZ, Index und Lesezeichen? Muss man wirklich erst für (zehn)tausende Euros einen XSLT-FO Prozessor kaufen und die nötigen Prozesse entwickeln lassen? Und funktioniert das Ganze dann auch noch in den ganzen benötigten Zielsprachen? Ist der Übersetzungsprozess überhaupt mitabgedeckt? Muss es bei XML immer auch gleich ein Content Management System (CMS) sein? Und wer sind überhaupt geeignete Partner für die Realisierung eines solchen Vorhabens? Entscheidungen für oder gegen ein bestimmtes Werkzeug bzw. einen Prozess ziehen immer auch finanzielle Konsequenzen nach sich, die gewichtet und berücksichtigt werden wollen. Nichts ist ärgerlicher, als wenn die Einführung hinterher erheblich mehr kostet, als über die reinen Produktkosten im Vorfeld absehbar war. Oder wenn die Einführung sich über Monate oder gar Jahre hinzieht und massiv Kosten und Arbeitszeit bindet, ständig nachgebessert werden muss und die Automatisierungs-Hochglanzversprechen sich als Fass ohne Boden entpuppen. Und wenn die erhofften „großen Einsparungen“ dann doch nicht so üppig ausfallen, wie vom Softwarehersteller suggeriert wurde oder gar durch andere, neue, Kosten vollständig aufgefressen werden.

FrameMaker ROI Calculator

Irgenndwann – hoffentlich möglichst früh – stellt sich auch die nicht ganz unwichtige Frage nach dem Budget. Hier können frühe Planungsfehler schnell in finanziellen Katastrophen enden. Adobe bietet zur ersten Orientierung einen, wenn auch recht groben und bei weitem nicht alles abdeckenden, „FrameMaker ROI Calculator“ an.

Passt man die vorgegebenen Standardwerte sinnvoll an, entsteht eine Annäherung, mit welchen Kosten bei der Einführung eines XML basierten Redaktionsprozesses zu rechnen ist. Da dieser ROI-Kalkulator weder eine Umstellung der Bestandsdokumentation berücksichtigt, noch eine Anpassung der Übersetzungsprozesse, oder gar die Einführung eines Content Management Systems kann dieser ROI-Calcultor natürlich nur als Einstieg dienen und sollte keinesfalls eine detaillierte Planung ersetzen. Es ist aber interessant zu sehen, welch erhebliche Kostenunterschiede entstehen, je nachdem welche Strategie schon ganz im Grundsatz gewählt wird. Selbst bei auf kleine Verhältnisse heruntergebrochenen Werten ist es kaum möglich, vierstellig zu werden. Berücksichtigt man dabei, dass dieser ROI-Rechner nur einen Bruchteil des Gesamtprozesses berücksichtigt, sollten diesen Kosten unbedingt auch die tatsächlich zu erzielenden Einsparungen gegenübergestellt werden. Erst das ermöglicht dann eine sinnvolle Beurteilung des Kosten-/Nutzen-Effektes. Je nach Ausgangsituation können dann auch durchaus andere Wege interessant sein. So bringt z.B. ein Wechsel von Dokumentationen, die mit Microsoft Publisher, Word oder gar CorelDRAW mühselig „gebastelt“ werden, in eine saubere, „klassische“ FrameMaker-Umgebung bereits ein sehr deutliches Plus an Komfort, Prozessstabilität und Kosteneinsparungen – bei deutlich geringerem finanziellen Einsatz und verringerten Kosten bei einem späteren Umstieg auf XML.

Was für Sie der richtige Weg ist, hängt also von vielen Faktoren ab. Gerne klären unsere Consultants Ihre individuellen Fragen zu diesem umfangreichen Thema mit ihnen. Sprechen Sie uns an.