Informationen intelligent bereitstellen

Text: Martin Ley

Anhand einer Fabriksimulation erforscht die Hochschule München den praxisnahen Einsatz von Systemen für Content Management und Content Delivery. Wie lauten die ersten Ergebnisse und was lässt sich für die Technische Kommunikation ableiten?

Inhaltsübersicht

Lesedauer: 15:01 Minuten

Information medienneutral und systemherstellerunabhängig erfassen und verwalten, anschließend flexibel und intelligent über ein Portal den Benutzerinnen und Benutzern für Szenarien wie Bedienung oder Wartung bereitstellen – dieses (Wunsch-)Bild soll durch ein Component-Content-Management-System (CCMS) und ein Content-Delivery-Portal (CDP) Wirklichkeit werden. In einem Projekt des Studiengangs Technische Redaktion und Kommunikation an der Hochschule München mit dem Projektpartner Pantopix GmbH & Co. KG haben wir dieses Szenario einer Prüfung unterzogen. Dabei haben wir neben konzeptionellen und systemtechnischen Aspekten auch die Frage behandelt, was es bedeutet, Information intelligent bereitzustellen.

Der Auslöser für das Projekt

Wer kennt dieses Szenario nicht? Eine komplexe Maschine besteht aus mehreren Komponenten. Sie werden zum Teil von unterschiedlichen Lieferanten bereitgestellt. Oder: In eine komplexe Industrieanlage sind mehrere Maschinen integriert, die ihrerseits von verschiedenen Herstellern produziert und geliefert werden. Das Ziel eines Maschinenherstellers oder Anlagenbetreibers wiederum ist es, alle notwendigen Informationen zur Maschine bzw. Anlage zentral bereitzustellen. Letztlich muss das Produkt ordnungsgemäß genutzt und gewartet werden können – über eine zusammenhängende Dokumentation (Print oder PDF) oder über ein anderes digitales Informationsprodukt wie zum Beispiel ein zentrales Serviceportal. Daraus entstehen große Herausforderungen etwa durch die unterschiedlichen Formate und Strukturen, in denen die Informationen von den jeweiligen Herstellern bereitgestellt werden, wie in Microsoft Word oder Adobe FrameMaker oder als XML und PDF.

Im Studiengang Technische Redaktion und Kommunikation beschäftigen wir uns mit den Best Practices des Informationsmanagements sowie zukünftigen Lösungsansätzen. Allerdings ist es nicht leicht, geeignete Produkte als Demonstrations- oder auch Versuchsobjekte an die Hochschule zu bekommen. Das ist besonders dann der Fall, wenn wir von komplexen Maschinen oder Anlagen sprechen. Um die verschiedenen Aspekte des Informationsmanagements an einem relativ einfachen, dennoch aber mit der „realen Welt“ durchaus vergleichbaren Produkt simulieren zu können, haben wir die Fabriksimulation von fischertechnik angeschafft (Abb. 01). Dieses Modell besteht aus mehreren Einzelmodellen. Sein ursprünglicher Zweck ist, Ansätze von Industrie 4.0 zu trainieren, genauer gesagt die Verkettung der Stationen in einer Bearbeitungslinie.

Das Modell kann Anwendungsszenarien simulieren.

Abb. 01 Die Fabriksimulation kann auch dabei helfen, Szenarien eines modernen Informationsmanagements durchzuspielen. Foto fischer

Unser Projekt soll herausfinden, wie Informationen in einem CCMS erfasst und verwaltet werden (müssen), um sie anschließend über ein CDP (intelligent?) bereitstellen zu können. Konkreter gingen wir zunächst der Frage nach, was dies bedeutet, wenn die Informationen aus unterschiedlichen CCMS stammen. Die Fabriksimulation diente uns in diesem Fall nicht der Simulation von Logistik- oder Fertigungsprozessen, sondern der Simulation von Informationserstellungs- und nutzungsprozessen. Einzelne Stationen der Simulation wie das Hochregallager, die Bearbeitungsstation mit Brennofen oder die Sortierstrecke wurden jeweils von einem studentischen Projektteam autark und ohne Abgleich mit den anderen Projektteams in drei unterschiedlichen CCMS dokumentiert. Um es einfach zu machen, nennen wir die Systeme CCMS Rot, CCMS Blau und CCMS Grün. Anschließend sollten die Informationen auf verschiedenen Wegen bereitgestellt werden (Abb. 02):

  • CCMS und CDP stammen aus demselben Haus.
  • CCMS und CDP sind von unterschiedlichen Herstellern.
  • Aus den drei unterschiedlichen CCMS wird in die Wissensplattform eines vierten Herstellers publiziert.

Diese Situation treffen wir in der realen Welt häufig an. Die CCMS stehen dabei stellvertretend für verschiedene Informationsquellen, die nicht ausschließlich für Technische Dokumentation genutzt werden müssen. Denkbar wäre auch, andere Informationsquellen zum Beispiel für Ersatzteile oder Werkzeuge anzubinden. Wichtig ist an dieser Stelle, dass wir die drei CCMS als Standardinstallation nutzen – sozusagen „out of the box“. Eine spezielle Anpassung („Customization“) fand nicht statt.

Wege der Informationserfassung und Informationsbeschreibung

Abb. 02 Verschiedene Wege der Informationserfassung und Informationsbereitstellung. Quelle Martin Ley

Wie sind wir vorgegangen? Wie in einem richtigen Projekt wurde das Vorgehen in Arbeitspakete unterteilt:

  • Anforderungsdefinition
  • Informationsarchitektur
  • Systemarchitektur
  • Informationserfassung
  • Konfiguration
  • Publikation
  • Evaluation

Abbildung 02 zeigt schematisch die Systemarchitektur. Auf einige besonders wichtige Aspekte des Projekts soll in diesem Beitrag genauer eingegangen werden: die Anforderungsdefinition, die Informationsarchitektur und die Informationsbereitstellung. Eine kritische, evaluierende Betrachtung fließt in die jeweiligen Abschnitte ebenfalls ein.

Anforderungen genau festlegen

Grundlage eines jeden Entwicklungsprojekts ist die Anforderungsdefinition. Aus der IT stammen verschiedene Methoden/Ansätze wie Lastenhefte oder Anwendungsszenarien – neudeutsch Use Cases. Wir haben uns, wie dies in Softwareprojekten häufig der Fall ist, für „User Stories“ entschieden. Im Gegensatz zu einem detailliert ausbuchstabierten Lastenheft beschreibt eine User Story in Alltagssprache ein bestimmtes Bedürfnis von Benutzerinnen und Benutzern. Die Beschreibung ist dabei bewusst kurz gehalten und folgt dem Formulierungsmuster: „Als [Rolle] möchte ich [Funktion], um [Zweck]“ [1]. Darüber hinaus kann die Beschreibung weitere Elemente enthalten wie zum Beispiel Akzeptanzkriterien (für eine spätere Verifikation), eine Klassifikation zum Beispiel nach Zielgruppe oder eine Priorisierung. Tabelle 01 zeigt einen Auszug aus unseren User Stories.

Übersicht über User Stories

Tab. 01 Quelle Martin Ley

Dieses Vorgehen hat sich als recht sinnvoll und praktikabel herausgestellt. Die Formulierung aus Sicht einer bestimmten Rolle (zum Beispiel Wartungsplaner) stellt sicher, bei der Entwicklung der Anwendung stets die Zielgruppe im Blick zu haben. Außerdem verzichtet die Formulierung auf technische Details, so dass die Anforderung ohne Bezug zum jeweiligen Softwareprodukt und zur konkret implementierten bzw. zu implementierenden Funktion vorgegeben wird. Am Ende dieses Arbeitspakets stand eine lange Liste mit mehreren Dutzend User Stories. Nicht alle konnten in der ersten Projektphase umgesetzt werden und sind in das Backlog gewandert.

Eine Architektur entwickeln

Als Dreh- und Angelpunkt sollte sich das Arbeitspaket Informationsarchitektur erweisen. Zwei unterschiedliche Dinge sind darunter zu verstehen: Erstens spricht man von einem so genannten Informationsmodell zur Erfassung der eigentlichen Inhalte. Es wird typischerweise von einer XML-DTD oder einem XML-Schema repräsentiert. Zweitens gibt es ein Metadatenkonzept, das

  • (a) grundsätzlich für die Verwaltung und Steuerung der Information im CCMS unabkömmlich ist,
  • (b) unabhängig von der hier verfolgten Fragestellung auch für die Filterung von Information für die Publikation im CCMS genutzt werden kann und
  • (c) speziell im Kontext von Content Delivery für die Filterung der Informationen im CDP über so genannte Facetten relevant ist.

Unterschiedliche Informationsmodelle

Sehen wir uns die Informationsmodelle der eingesetzten CCMS genauer an. Vorab kann festgehalten werden, dass die Informationsmodelle recht unterschiedlichen Charakter haben. Während die Informationsmodelle von CCMS Grün und CCMS Blau einen eher generischen Ansatz verfolgen, ist das Informationsmodell von CCMS Rot semantisch stark ausgeprägt (zur Unterscheidung von semantisch vs. generischem Ansatz vgl. [2]).

Abbildung 03 illustriert diesen Gedanken: In CCMS Grün existiert als Grundeinstellung zunächst ein einziger Topic-Typ. Er hat eine allgemeingültige, zugleich semantisch recht heterogene innere Struktur. So gibt es zum Beispiel spezifische Elemente für technische Daten, Wartungstabellen oder Prozeduren, aber auch generische Elemente für Paragrafen, Listen und Tabellen. CCMS Blau hingegen bietet verschiedene Topic-Typen. Dazu zählen Installation, Bedienung oder Wartung. Deren Unterstrukturen wiederum sind stets identisch. Über so genannte Fragmente ist es möglich, kleinere Informationseinheiten zu definieren. Das entspricht sicherlich der gängigen Praxis und schafft so ein größeres Wiederwendungspotenzial. Das Informationsmodell von CCMS Rot schließlich ist ein so genanntes semantisches Informationsmodell. Es enthält auf der einen Seite verschiedene Topic-Typen, zum Beispiel für Wartungstätigkeiten, Diagnose oder verschiedene Prozeduren wie Einbau, Ausbau oder Prüfung. Deren Unterstrukturen wiederum sind abhängig vom Topic-Typ. Zum Beispiel gibt es eigenständige Elemente für Symptome, Intervalle, Materialien oder Personal. Selbstverständlich können in allen drei CCMS auf der Metaebene die Topics über Kapitel bzw. kapitelähnliche Konstrukte zu größeren Informationsgebilden bis einschließlich kompletten Informationsprodukten zusammengefasst werden.

System Rot, Grün und Blau im Vergleich

Abb. 03 Informationsmodelle verschiedener CCMS im Vergleich. Quelle Martin Ley

Während das Informationsmodell in CCMS Rot vorgegeben ist und den Technischen Redakteurinnen und Redakteuren eine zwar komplexe, dafür aber eindeutige Schablone bietet, sind die Informationsmodelle in CCMS Blau und CCMS Grün relativ frei. Hier sind redaktionelle Festlegungen nötig (und/oder entsprechende Erfassungstemplates), welche Elemente in welchem Kontext für welche Zwecke tatsächlich verwendet werden dürfen. Denn es gilt stets zu beachten: Am Ende entscheidet die Informationsqualität darüber, ob die bereitgestellten Informationen tatsächlich brauchbar sind oder nicht – und das ist zunächst keine Frage des Systems. Auf redaktionelle Grundlagenarbeit kann also unter keinen Umständen verzichtet werden.

An dieser Stelle sei angemerkt, dass der Begriff der Topic-Orientierung offenbar noch immer Fragen aufwirft und von den CCMS-Herstellern unterschiedlich ausgelegt wird (s. aber [5]). So wird in CCMS Grün das Topic strukturell mit einem Kapitel gleichgesetzt, nur dann lässt es sich in dem dazugehörigen CDP auch als Topic navigieren und anzeigen. Berücksichtigt man, dass ein Kapitel eine umfangreiche Unterstruktur aufweisen kann, ist dies sicherlich ein unkonventioneller Ansatz. Er zeigt, dass hier Wissen über das Zusammenwirken von CCMS und CDP essenziell ist und redaktionelle Standards unabdingbar sind. Ebenso interessant ist die Beobachtung, dass nach wie vor der Schritt von der Dokumentenzentrierung hin zur Topic-Orientierung nicht konsequent gegangen wird. So sind viele CCMS für die Arbeit und Bereitstellung der Informationen in Dokumenten ausgelegt. Aber auch in einigen CDP sind in der Voreinstellung Inhaltsverzeichnisse für Dokumente als Navigationselemente implementiert.

Modelle für die Metadaten

Wie wir gesehen haben, sind die Informationsmodelle der drei CCMS recht unterschiedlich und zum Teil recht frei interpretierbar. Das trifft insbesondere auf CCMS Grün und CCMS Blau zu. Diese Systeme wiederum bieten nun mehrere Möglichkeiten, die Informationsmodelle mit zusätzlichen Daten anzureichern, womit wir bei den Metadaten angekommen wären.

Metadaten werden für viele unterschiedliche Aufgaben im Content Management benötigt. Zu nennen wären beispielsweise Metadaten zur systemseitigen Verwaltung, zur Suche oder zur Abbildung von Workflows. Aber auch für die nähere Beschreibung der Topics, sozusagen zur semantischen Anreicherung der Topics, können Metadaten eingesetzt werden. Der Klassifikation (und späteren Modellierung) der Metadaten kommt somit eine zentrale Rolle zu. Hierfür hat sich der Ansatz PI-Class als brauchbar erwiesen [3]. Demzufolge lassen sich Metadaten etwa in produktbezogene und informationsbezogene Metadaten unterteilen. Zu ersteren gehört typischerweise der Produktaufbau nach Maschine, Komponenten und Teilen; Beispiele für letztere können sein: Sprache, Topic-Typ oder Zielgruppe. Je nach Klassen und dazugehörigen Merkmalen ergibt sich letztlich eine multiple Metadatentaxonomie, genauer gesagt ein hierarchisches Metadatenmodell. Es dient dazu, ein Topic in einem mehrdimensionalen Informationsraum zu verorten (Abb. 04).

Position eines Topics

Abb. 04 Vorortung eines Topics im mehrdimensionalen Informationsraum. Quelle Martin Ley

Interessante Ergebnisse entstehen, wenn eine Projektgruppe, ausgestattet mit identischem Auftrag und nahezu identischem theoretischen Hintergrundwissen, ein Metadatenmodell für ein Produkt/eine Maschine und somit stellvertretend für ein Unternehmen entwickelt (Abb. 05).

Auszug Gruppe 1 und 2

Abb. 05 Auszug Metadatentaxonomie Gruppe 1 (Brennofen) und Gruppe 2 (Hochregallager). Quelle Martin Ley

Die Ergebnisse können nämlich mehr oder weniger gravierend voneinander abweichen. Und ähnlich unterschiedlich dürfte es auch in der Realität aussehen. In jedem Unternehmen existiert eine Vielzahl an Metadaten, mit denen Informationen klassifiziert werden: Manchmal ähneln sich die Metadatenmodelle sehr und sind lediglich in ihren Benennungen unterschiedlich, manchmal handelt es sich um komplett andere (Teil-)Taxonomien. Hinzu kommt, dass unterschiedliche CCMS notwendige Metadaten auch unterschiedlich umsetzen bzw. in dem Informationsmodell des einen CCMS bereits die Information vorhanden ist, die in einem zweiten CCMS erst über Metadaten einem Topic – gewissermaßen von außen – hinzugefügt wird. So mussten für unsere Zwecke beispielsweise in CCMS Rot (mit Ausnahme der Produktstruktur) keine weiteren Metadaten definiert werden. Aufgrund seines semantisch ausgeprägten Charakters enthält das Informationsmodell bereits alle erforderlichen Merkmale.

Die erforderlichen Metadatenmodelle sind in den meisten CCMS im Auslieferungszustand nicht enthalten. Abhängig von der gewünschten Funktionalität, müssen sie erst erarbeitet werden. Vorlagen und Standards gibt es hierfür nicht. Auch Ansätze wie PI-Class sind noch kein Garant für ein einheitliches Metadatenkonzept. Sie bieten lediglich eine erste Orientierung. Im Detail bleibt sehr viel Spielraum für Interpretation.

Analog verhält es sich mit der teilweise schwer zu vermittelnden Trennung zwischen intrinsisch und extrinsisch. Ob tatsächlich strikt nach Produkt und Information und eventuell weiteren Klassen wie funktionalen Metadaten unterschieden wird, ist am Ende irrelevant. Wichtig und ausschlaggebend über Erfolg oder Misserfolg ist eine Vorgehensweise, die Regeln für die Entwicklung des Metadatenmodells festlegt und nichts dem Zufall überlässt. Eine solche Regel könnte lauten, dass innerhalb einer Teiltaxonomie die Relationen zwischen Ober-/Unterknoten als eine „ist-ein-Relation“ modelliert wird.

Letztlich betrifft die Problematik rund um Metadaten nicht nur die Technische Redaktion. Es können sehr viele Abteilungen und Bereiche in einem Unternehmen damit zu tun haben. Viele für die Technische Redaktion notwendige Metadaten, speziell die über Produkte, stammen aus anderen Bereichen wie der Entwicklung und liegen in Systemen für Product Lifecycle Management (PLM) oder Warenwirtschaft vor. Informationstechnologisch kann hier über geeignete Schnittstellen nachgedacht werden. Organisatorisch interessant könnte sein, im Unternehmen die Position einer Taxonomistin oder eines Taxonomisten einzurichten. Dort laufen idealerweise alle Bemühungen rund um Metadatenmodelle zusammen (vgl. hierzu [4]).

Sofern erforderlich, wird das Metadatenmodell in das CCMS integriert. In unserem Fall war dies für CCMS Blau und CCMS Grün der Fall und erfolgte über einfache Konfiguration. CCMS Blau lässt sich relativ „geradlinig“ an einer zentralen Stelle über eine so genannte Taxonomie konfigurieren. In CCMS Grün werden Metadaten auf zwei unterschiedliche Weisen angelegt. Zum einen als so genannte Gültigkeiten. Sie werden in erster Linie für die Filterung der Inhalte vor der Publikation bzw. Bereitstellung genutzt. Zusätzlich können auch die „eigentlichen“ Metadaten angelegt werden. Wenn man weiß, an welchen Stellen in welchem CCMS die Metadaten wie angelegt werden, ist dies alles keine Zauberei. CCMS Rot hat sich für uns als relativ geschlossenes System dargestellt. Abgesehen von der Konfiguration der Produktstruktur konnten wir in das System nicht eingreifen und aufgrund der detailliert ausbuchstabierten Informationsarchitektur mussten wir es auch nicht.

Bereitstellen über herstellereigene CDP

Für die Bereitstellung der Inhalte über ein CDP haben wir verschiedene Wege vorgesehen. Der naheliegende Weg ist, die Inhalte aus dem CCMS eines Herstellers in das herstellereigene CDP zu publizieren (s. Abb. in [1]).

Ein Kerngedanke von CDP Grün und CDP Blau ist es, den Benutzerinnen und Benutzern Informationen nach verschiedenen Kriterien bereitzustellen. Dies ähnelt stark dem Ansatz von Verkaufsportalen wie Amazon oder Zalando. Allerdings geht es in unserem Fall um technische Inhalte, die über verschiedene Mechanismen gefiltert werden. Hierfür hat sich neben der Volltextsuche die facettierte Suche etabliert. Über die Auswahl verschiedener hierarchisch strukturierter Merkmale wird die Suche immer weiter verfeinert. Die „Intelligenz“ dieser beiden CDP ist dabei relativ überschaubar. Ihre Aufgabe besteht primär darin, Informationen über Facetten bereitzustellen. Anders verhält es sich bei CDP Rot. Über CDP Rot werden die technischen Inhalte für serviceunterstützende Tätigkeiten aufbereitet, so dass sich zum Beispiel Arbeitszeiten berechnen oder Wartungspläne mit entsprechenden Werkzeugen oder Ersatzteilen erzeugen lassen. Aufgrund des zugrunde liegenden semantischen Informationsmodells sind hier weitreichende Verknüpfungen und Auswertungen der erfassten Informationen möglich.

Grundlage für die Bereitstellung der Informationen über alle drei CDP sind erneut Metadaten. Die CDP werden demzufolge so konfiguriert, dass einige der vorhandenen Metadaten (und/oder Gültigkeiten) auch für die Navigation bzw. Bereitstellung der Information im CDP genutzt werden. Dies geschieht recht problemlos. Sobald die CDP einmal konfiguriert sind, lassen sich die Inhalte mehr oder weniger „auf Knopfdruck“ aus dem CCMS in das dazugehörige CDP publizieren.

Für die Publikation werden die Informationen aus den CCMS in Austauschpakete transformiert – typischerweise mittels XSLT. Sie können vom entsprechenden CDP verarbeitet werden. Diese Austauschpakete folgen im Normalfall einem HTML-Standard und enthalten Metadaten, Angaben zu den festgelegten Facetten, außerdem die eigentlichen Inhalte und eventuell referenzierte Medienobjekte. Dazu gehören etwa Illustrationen. In einem Fall wurde vom Hersteller auch ein eigenes proprietäres Exportformat entwickelt.

Der Aspekt der Austauschformate hat sich als Casus Knacksus erwiesen. Während der Weg vom CCMS eines Herstellers in „sein“ eigenes CDP unproblematisch ist, stellen die herstellerspezifischen Austauschpakete für die Bereitstellung herstellerfremder Inhalte eine relativ hohe Hürde dar. Hier müssen individuelle und teilweise aufwendige Transformationen geschrieben werden. Sie ermöglichen, die Informationsarchitektur des einen Herstellers auf die eines anderen zu „mappen“.

Bereitstellen über ein zusätzliches CDP

Aufgrund des Aufwands sollte im Projekt ein vierter Weg beschritten werden – CDP Schwarz. Dieser geht zunächst davon aus, dass eine neutrale Wissensplattform auf Basis einer Ontologie aufgesetzt wird, also einer expliziten Repräsentation einer Wissensdomäne. Dieses Wissensnetz besteht aus Objekten und deren Relationen. Die eigentlichen Inhalte (die technischen Informationen) werden in dieses Wissensnetz instanziiert. Einen kleinen Einblick in das Wissensnetz gibt Abbildung 06.

Wissenplattform einer Anlage

Abb. 06 Wissensnetz einer Wissensplattform (Auszug). Quelle Martin Ley

Auf dieser Wissensplattform lässt sich dann ein CDP als weitere Anwendung aufsetzen. Es verwendet das Wissensnetz für die Bereitstellung und Navigation der nunmehr verknüpften Inhalte. Die Beschreitung dieses Weges hat sich jedoch, verglichen mit den drei anderen Wegen, als anspruchsvoll herausgestellt. Dies liegt am Aufbau des Wissensnetzes und der Konfiguration des CDP. Aber auch an der Frage, in welchem Format die Informationen in die Wissensplattform importiert werden können.

Aus den CCMS kann grundsätzlich XML exportiert werden. Für die Darstellung im Web Frontend des CDP würde dies aber bedeuten, dass entsprechende und eventuell unterschiedliche Stylesheets (abhängig vom jeweiligen XML) mitgeliefert oder neu bereitgestellt werden müssten. Als naheliegend scheint sich HMTL bzw. HTML5 anzubieten. Es hat sich jedoch gezeigt, dass ein HMTL-/HTML5-Export aus den CCMS trotz „Single Source und Multiple Media Versprechen“ nicht selbstverständlich ist. Zudem geht die Konvertierung nach HTML/HTML5 einher mit Informationsverlust von den im CCMS mit Metadaten angereicherten Inhalten. Einige semantisch sinnvolle und für einen automatischen Import in die Wissensplattform notwendige Metadaten haben den Weg in die HTML-Welt einfach nicht „überlebt“. Die entsprechenden Relationen mussten im Wissensnetz manuell nachgezogen werden.

Trotz dieser Schwierigkeiten bietet sich dieser Weg dennoch als interessante Alternative zu herstellerspezifischen CDP an. Dafür sprechen drei Gründe:

  1. Die Wissensbasis ist unabhängig von einem spezifischen CCMS und bietet die Möglichkeit, verschiedene Informationsarchitekturen in einem übergeordneten Metadatenmodell zu organisieren.
  2. Über das Wissensnetz lassen sich weitere Informationen aus anderen Informationsquellen relativ problemlos zusammenführen.
  3. Aufgrund der Relationen im Wissensnetz sollte es möglich sein, neue, bisher unbekannte Inhalte zu erschließen oder Abfragen auf dem Wissensnetz zu realisieren. Die Inhalte können so noch individueller auf den Kontext und die Situation, in der sie von den Benutzerinnen und Benutzern benötigt werden, gefiltert und bereitgestellt werden.

Schwachpunkt Datenaustausch

Das Projekt mit der Fabriksimulation hat viele Einblicke in die Möglichkeiten und Herausforderungen beim Bereitstellen von Informationen aus einem CCMS in ein oder mehrere CDP geliefert. Für alle hier verfolgten Ansätze gilt, dass das Erstellen und Bereitstellen von Informationen innerhalb der Systemlandschaft des gleichen Herstellers meist gut und reibungslos gelingt. Dennoch kommt man um konzeptionelle Grundlagenarbeit für Metadatenmodelle und redaktionelle Festlegungen nicht herum. Erst durch diese Arbeit wird die Basis für eine intelligente Bereitstellung der Information gelegt.

Diese Intelligenz scheint aber noch nicht in allen CDP angekommen zu sein. Einige sind so konzipiert, dass Informationen (im besten Fall als Topics) anhand verschiedener Facetten aus einem großen Informationsbestand herausgefiltert und angezeigt werden können. Wirklich intelligente Dinge kann man mit diesen CDP bislang nicht machen. Interessanter sind Ansätze, die auf tiefen semantischen Strukturen basieren und so die Weiterverarbeitung der Informationen im CDP wie zum Beispiel eine Auswertung von verschiedenen Materialien, die Zusammenfassung verschiedener Wartungstätigkeiten zu einer größeren Wartungsprozedur oder die situative Diagnose mit verschiedenen Entscheidungsparametern ermöglichen.

Die Komplexität des Content Delivery steigt zudem enorm, wenn Herstellergrenzen überwunden werden. Hierfür sind heute weitreichende Kompetenzen bei der Transformation nötig. Ein Weg aus dem Publikationsdilemma sollte iiRDS sein. Dieser Standard verspricht, die beschriebenen Probleme bei Austauschpaketen zu lösen. Der Blick in die Systemwelt ist allerdings eher ernüchternd. Keines der eingesetzten CCMS ist in der Lage, iiRDS-Pakete direkt auszuspielen – obwohl es natürlich Anwendungen gibt, die eigens entwickelte Transformationen für die Erzeugung dieser Pakete nutzen. Analog gilt, dass lediglich eines der vier CDP iiRDS-Pakete „aus dem Stand“ importieren kann. Es bleibt also abzuwarten, wie sich dieser Standard entwickelt und eventuell implementiert wird.

In den folgenden Semestern soll das Projekt Fabriksimulation erweitert werden, um einen vollständigen Showcase rund um die Technische Redaktion abzudecken. So sollen etwa weitere Inhalte erfasst werden. Denkbar wäre auch, die Fabriksimulation mit Sensoren auszustatten, um so situativ bestimmte Tätigkeiten auszulösen. Darüber hinaus könnte der Einsatz von Augmented Reality erprobt werden usw. Interessierte sind auf jeden Fall eingeladen, ihre Ideen und Anforderungen in das Projekt einfließen zu lassen.

Links und Literatur zum Beitrag

[1] Patton, Jeff; Economy, Peter (2014): User Story Mapping. Discover the Whole Story, Build the Right Product. O’Reilly Media.

[2] Ley, Martin (2018): Informationen erhalten Bedeutung. In: technische kommunikation H. 4, S. 50–55.

[3] Drewer, Petra; Ziegler, Wolfgang (2014): Technische Dokumentation: Übersetzungsgerechte Texterstellung und Content-Management. Vogel Communications Group GmbH & Co. KG.

[4] Hedden, Heather (2010): The Accidental Taxonomist. Information Today Inc.

[5] Closs, Sissi (2011): Single Source Publishing. Entwickler.Press.

[6] iiRDS Consortium (2018): tekom iiRDS Standard. Version 1.0 Release Date 18 April 2018. Verfügbar unter iirds.tekom.de.

Quelle CSH, 123rf