Der Projektkonfigurator im Einsatz bei SKOV: Von Michelangelos David zum 3D-Drucker

Der klassische Weg zur Projektvariante

Ganz generell: In ST4 enthalten Projekte die Publikationsstrukturen für die Zieldokumente. Ein Projekt wird dafür manuell angelegt und anschließend ordnet ein Redakteur Content-Knoten aus dem Informationspool diesem Projekt zu. Hier gibt es 3 mögliche Wege, Projektvarianten zu erzeugen:

1. Ein Projekt enthält nur die Content-Knoten, die für ein Bedienungshandbuch relevant sind.
2. Man arbeitet mit einer Maximalstruktur; das heißt in einem Projekt sind sämtliche Content-Knoten referenziert. Per Variantenfilter werden anschließend die entfernt, die für eine Variante nicht relevant sind.
3. Man erstellt die Varianten bereits an den Content-Knoten und lässt diese im Projekt wieder filtern.

Der Redakteur muss aber bei all diesen Möglichkeiten gewissenhaft die richtigen Knoten im Projekt referenzieren und das manuell. Das ist ein bisschen wie Michelangelos David: Es wird all das entfernt, was nicht dazu gehört. Und das ist der Standard-Weg, der generell sehr gut funktioniert. Aber: Kommen immer mehr Varianten für Produkte und auch Dokumente hinzu, ist das manuelle Konfigurieren der Projekte schlichtweg zu langsam.

Was tun bei sehr vielen Varianten?

Bevor SKOV 2017 ST4 einführte, wurden die Dokumentvarianten noch mit Word erstellt. Vor allem bei sich wiederholenden Aufgaben, wie das Aktualisieren der Dokumentation parallel zum Entwicklungsprozess, hat sich die Effizienz gesteigert. Die Einführung von ST4 hat in der Technischen Dokumentation von SKOV damit zu radikalen positiven Veränderungen geführt, die sowohl die Standards der Dokumente als auch die internen Prozesse optimiert haben.

Eine große Rolle spielt dabei der Projektkonfigurator. Die Redakteure bei SKOV konfigurieren die Projekte für die verschiedenen Varianten nicht selbst, sondern lassen das den Projektkonfigurator erledigen. Der Projektkonfigurator zieht quasi wie ein Magnet die für das Projekt relevanten Knoten an - ersetzt also den manuellen Schritt des Referenzierens der Knoten. Und er übernimmt nicht nur das Referenzieren, sondern auch das Anlegen eines Projekts.

Schon von Beginn an haben wir den SKOV-Redakteuren geraten, den Projektkonfigurator zu nutzen. Denn die Dokumente- und Projektlandschaft bei SKOV sieht so aus:

Wiederverwendete Knoten werden farblich hervorgehoben.

Der Großteil der Informationsknoten wird in ganz verschiedenen Dokumenten wiederverwendet. Ein Knoten mit dem Content „Produktbeschreibung“ findet sich so in mindestens 5 verschiedenen Dokumenten wieder. Die Dokumente selbst haben eine sehr unterschiedliche Struktur. Damit steht man bei einem manuellen Anlegen eines Projekts vor der Herausforderung, die richtigen Knoten in die richtigen Projekte zu ziehen und keine relevanten Knoten zu übersehen.

Was muss nun aber vorhanden sein, damit SKOV effektiv mit dem Projektkonfigurator arbeiten kann? Welche Voraussetzungen müssen erfüllt sein?

Der Weg zum automatisch erstellten Projekt

Wenn man vom Ende herdenkt, also vom fertigen Projekt mit gegebenenfalls zugeordneten Filtern, wird klar: Wenn man das Projekt nicht manuell erstellt, muss direkt am Informationsknoten nachvollziehbar sein, warum er zu diesem Projekt gehört und nicht zu einem anderen. Das kann die Dokumentart sein (z. B. umfangreiche Betriebsanleitung vs. Wartungsunterlagen), aber auch das Produkt (Bauteile vs. Baugruppe vs. Maschine; Leistungsbeschreibung einer Software vs. Fensterhilfe). Der Projektkonfigurator braucht also Erkennungsmerkmale, die ihm zeigen, dass dieser eine Knoten sowohl in der Betriebsanleitung als auch im Service-Handbuch verwendet werden soll und für die gesamte Maschine gilt.

Damit ergeben sich diese 3 Voraussetzungen, um den Projektkonfigurator einzusetzen:

• Eindeutig verwendete Knotenklassen
• Ein klares und eindeutiges Metadaten-Konzept
• Vorlagen für die Dokumentstrukturen

Eindeutige Knotenklassen

Die Knotenklassen können z. B. nach dem SCHEMA Konzept verwendet werden (Anleitung, Wartung, Bedienung etc.). SKOV verwendet für die oberste Ebene lediglich universelle Textknoten.

„Everything starts with the taxonomies“

Um den Projektkonfigurator effektiv einzusetzen, haben die Redakteure bei SKOV ein Konzept für ihre Taxonomien erstellt und sich für 3 getrennte Taxonomien entschieden: Produkt, Information und Dokumenttyp.

Die Produkt-Taxonomie ist dabei die führende Taxonomie, von ihr hängen die anderen Taxonomien ab. Eine führende Taxonomie ist in jedem Fall nötig, um unterscheiden zu können, welches Metadatum über die nachfolgenden Metadaten bestimmt. Für den Projektkonfigurator verwendet SKOV außerdem die Taxonomie Information. Die dritte Taxonomie Dokumenttyp wird erst beim Erzeugen des Layouts verwendet.

Dokumente strukturieren mit Vorlagen und Platzhaltern

Anschließend baute SKOV die Vorlagen (Templates) auf, um die Struktur ihrer Dokumente abzubilden. Die Vorlagen bestehen aber nicht aus Informationsknoten mit Content, sondern aus Platzhalter-Knoten. Das sind „Such-Knoten“, die stellvertretend für alle Knoten stehen, die im Projekt an ihrer Stelle stehen sollen. Beim Anlegen eines Platzhalters legt man fest, nach welchen Kriterien die Knoten zusammengesucht werden - was wird also wie ein Magnet mithilfe des Platzhalters angezogen und ins Projekt integriert:

Bei SKOV sieht eine Vorlage für das Dokument „Technische Informationen“ für zwei Produkte so aus:

SKOV nutzt pro Dokument jeweils eine Vorlage. Da diese und die darin enthaltenen Platzhalter stetig angepasst werden können, lässt sich auch damit in der Zukunft flexibel umgehen.

Und jetzt kommt der spannende Teil: Der Projektkonfigurator im Einsatz.

Projekte konfigurieren und anlegen - per Knopfdruck

Mithilfe der Vorlagen und der darin enthaltenen Platzhalter mit Metadaten startet der Projektkonfigurator die Suche. Er liest die Platzhalter-Knoten aus und sucht die Content-Knoten zusammen, an denen die jeweiligen Eigenschaften hinterlegt sind. In der Übersicht sieht man, welche und wie viel Knoten pro hinterlegter Taxonomie und Informationsart gefunden werden. So kann man auch auf einen Blick sehen, ob Inhalte fehlen.

Man kann hier sogar direkt neue Knoten anlegen, die man anschließend mit Content füllt. Diese Knoten besitzen dann schon die richtigen Eigenschaften für das Projekt. Für die SKOV-Redakteure ist das ein wichtiges Feature, das einige Arbeitsschritte erspart und das Risiko minimiert, Taxonomien falsch zuzuordnen.

Mit einem Klick auf „Projekt anlegen“ erstellt der Projektkonfigurator das Projekt. Es bekommt den Titel der Vorlage und enthält bereits die verwendeten Variantenfilter. Ein Vergleich von Vorlage und dem daraus konfigurierten Projekt bei SKOV macht das deutlich. Die Platzhalter (Titel in Englisch) werden im Projekt mit den passenden Content-Knoten belegt. Der Platzhalter „Product description“ findet mit den hinterlegten Taxonomien für das Projekt den Knoten „Produktbeskrivelse [DOL 63X]“:

SKOV profitiert vom Projektkonfigurator am meisten bei den Produktübersichten: Für jedes Zubehörteil gibt es einen eigenen Knoten, der vom Projektkonfigurator dank Taxonomie zum jeweiligen Projekt hinzugefügt wird. Manuell wäre das ein großer Aufwand, da viele Produkte die gleichen Zubehörteile haben und der Redakteur jedes Zubehörteil individuell zu jeder Variante zuordnen müsste.

Dank Projektkonfigurator bereit für immer mehr Varianten - auch in der Cloud

Spätestens mit dem nächsten Software-Update werden sich die großen Vorteile des Projektkonfigurators bei SKOV zeigen: Dann können die Redakteure die Dokumentation für alle Software-Varianten und Sprachen in einem einzigen Workflow erstellen.

Der Projektkonfigurator ist ein interessantes Tool überall dort, wo mit sauber konzipierten Taxonomien und eindeutiger Verwendung von Informationsarten gearbeitet wird bzw. werden soll. Wie bei SKOV wird man eine ganz andere Ebene und Praxis beim Projekterstellen erreichen. Das manuelle Erstellen der Projekte wird besonders dann an seine Grenzen kommen, wenn Daten in einer Cloud liegen (Schlagwort iiRDS) und zentral zu Projekten zusammengestellt werden.

Kirsten Müller Nielsen

Master in Geschichte und Religion. Einschneidende Neuorientierung und Arbeit mit technischer Dokumentation seit 2002 - insbesondere Software-Übersetzung und -Dokumentation. Seit 2016 Dokumentationsmanagerin in der Forschungs- und Entwicklungsabteilung von SKOV A/S. Sie hat Freude an der Herausforderung, unser Team, unsere Arbeitsprozesse und unsere Kundenorientierung weiterzuentwickeln - und ST4 zu implementieren. Certified Scrum Master und Auditorin (ISO 9001).