Information 4.0: Wie HOMAG Informationen aus der Dokumentation zur Anlagensteuerung nutzt

Das Bild zeigt eine Person in einer Holzfabrik, die ein Tablet hält, auf dem Lösungen für Wartungsaufgaben angezeigt werden.

Kürzlich haben wir berichtet, wie wir für den Maschinenbauer HOMAG eine neue Publikationsumgebung mit FrameMaker, iiRDS und SAP aufgebaut haben. Heute erzählen wir Ihnen, wie wir für HOMAG Maschinenereignisse zur Fehlersuche oder zur Priorisierung der Wartung mit der Technischen Dokumentation verknüpft haben. Die MaschinenbedienerMaschinenbedienerinnenMaschinenbediener und MaschinenbedienerinnenMaschinenbediener:innen müssen nicht umständlich nach richtigen Informationen suchen, sondern erhalten diese passend zum Maschinenzustand auf einem Tablet oder Smartphone angezeigt. Hier schon mal vorweg: Die Lösung heißt iiRDS und lässt sich vielleicht auch auf Ihre Systemumgebung übertragen. Und das Ergebnis können Sie sich im HOMAG-Youtube-Kanal ansehen.

Neue Anforderungen aus der Entwicklungsabteilung: Doku-Datenpakete für die HOMAG-Service-Cloud

Nachdem wir die DITA-basierte Publikationslösung mit SAP-Integration umgesetzt hatten, kam HOMAG mit einer neuen Anforderung auf uns zu. Die Entwicklungsabteilung von HOMAG hatte sich an das Team der Technischen Dokumentation gewandt und gefragt, wie man dem SAP-Dokumentenmanagementsystem Informationen für Fehlerbeschreibungen und entsprechende Lösungen zu Problemen entnehmen könne. Ziel war, Datenpakete mit passenden Informationen in die HOMAG-Cloud zu laden und mit den Maschinen zu verknüpfen. Die MaschinenbedienerMaschinenbedienerinnenMaschinenbediener und MaschinenbedienerinnenMaschinenbediener:innen und ServicetechnikerServicetechnikerinnenServicetechniker und ServicetechnikerinnenServicetechniker:innen sollten dann über die App HOMAG ServiceAssist oder den HOMAG ServiceRemote über Probleme an einer Maschine informiert werden und gleich die passenden Dokumente mit Lösungsvorschlägen angeboten bekommen.

Dazu haben die HOMAG-EntwicklerEntwicklerinnenEntwickler und EntwicklerinnenEntwickler:innen in einer Schnittstellendefinition festgelegt, welche Informationen aus der Technischen Dokumentation geliefert werden sollten, um die Verknüpfung von Maschine und Dokumentation herzustellen.

Da waren wir von c-rex.net als langjähriger Systemintegrator von HOMAG gefragt und setzten eine Lösung um, die nach einem unseren Grundprinzipien entwickelt wurde, das da lautet: „Verwende einen Standard, wenn es ihn gibt und passe ihn bei Bedarf an Deine Bedürfnisse an!“.

Standards, Standards, Standards! XML, iiRDS, DITA

Da wir in der bisherigen Lösung für die Erstellung und automatischen Publikation von Technischer Dokumentation auf Standards gesetzt haben, nämlich auf iiRDS, wollten wir das auch bei der Entwicklung der neuen Anforderung tun. Deshalb haben wir die Liste der geforderten Metadaten gegen den intelligent information Request and Delivery Standard (iiRDS) gemappt. Schließlich ging es bei der Anfrage der Entwicklungsabteilung um den Austausch von Informationen zwischen zwei verschiedenen Systemen. Und siehe da! Es gab fast einen 1:1 Match.

Es stellte sich also heraus, dass die Bündelung der von der Entwicklungsabteilung geforderten Informationen und Dokumente in einem iiRDS-Paket der geeignete Weg war. Es mussten nur einige Anpassungen in iiRDS und in den bereits bei HOMAG etablierten iiRDS-Strukturen gemacht werden.

Was wird durch iiRDS abgedeckt? Welche Erweiterungen waren notwendig?

Bildliche Darstellung des Metadaten-Mapping zwischen iiRDS und iiRDS — Metadaten-Mapping DITA – iiRDS

Es gab viele Anforderungen für die HOMAG-Cloud, die sich durch iiRDS ohne Anpassungen abdecken ließen. Einige wenige Anforderungen machten es notwendig, den iiRDS-Standard zu erweitern.

In der angestrebten Cloud-Lösung sollten Angaben darüber gemacht werden, zu wie viel Prozent eine in der Service-App vorgeschlagene Lösung andere AnwenderAnwenderinnenAnwender und AnwenderinnenAnwender:innen zum Erfolg geführt hat. Diese Information war bisher in der Dokumentation nicht enthalten und hatte auch keine passende Entsprechung in iiRDS. Deshalb haben wir dafür ein custom-property ergänzt und damit den iiRDS-Standard erweitert.

Das haben wir über die sogenannten "docking points" realisiert, die dazu dienen, Metadaten aus anderen Standards (z.B. ECLASS) oder eben auch custom-Strukturen für Produkte und Baugruppen zu hinterlegen. Und das passte für die HOMAG-Umgebung ja perfekt. Denn HOMAG erstellt schon seit Jahren baugruppenorientierte Dokumentation.

Wie sieht die Umsetzung in DITA aus?

Im nächsten Schritt haben wir geprüft, wie wir das in DITA umsetzen können. Werfen wir dazu einen Blick auf die iiRDS-Strukturen, die bei HOMAG bereits vorhanden waren.

Da gibt es zum einen bereits spezialisierte Topics:

HomagFCR (Fault Cause Remedy) leitet vom Standard-Topictyp "Troubleshooting" ab.
HomagTask leitet vom Standard-Topictyp "Task" ab.

Zudem gibt es einen MDETask speziell für Wartungsinformationen, mit der die Maschine einen direkten Connect zur Doku herstellt. Darüber berichteten wir bereits in unserem ersten Blogbeitrag zur HOMAG-Lösung.

Die beiden spezialisierten Topictypen, HomagFCR und HomagTask, haben wir so erweitert, dass die AutorenAutorinnenAutoren und AutorinnenAutor:innen von Fehlerbeschreibungen zum einen die benötigten Metadaten erfassen können und zum anderen Beziehungen über Links im „Remedy“ zu den Lösungen herstellen können.

Was bedeutet das konkret für die redaktionelle Arbeit?

Die AutorenAutorinnenAutoren und AutorinnenAutor:innen erstellen wie gewohnt ihre Inhalte und vergeben zusätzlich Metadaten im Prolog des DITA-Topics.
Die Remedy (Abhilfe) im FCR-Topic sind Handlungsschritte, die AutorenAutorinnenAutoren und AutorinnenAutor:innen nicht direkt im HomagFCR-Topic beschreiben, sondern als Querverweis einfügen. Dieser Querverweis stellt die Beziehung zu dem Task her, in dem die Lösung (Abhilfe) beschrieben ist.

Wie kommen die Daten in die HOMAG Service-Cloud?

Dazu haben wir den in FrameMaker integrierten Publikationsprozess erweitert, der bislang schon unterschiedliche Publikationskanäle bedient und dafür XLIFF, PDF, Control-files für die Maschine und Trainingsfolien zur Verfügung stellt. Er generiert jetzt für die Dokumentart „Fehlerbehebung“ ein iiRDS-Paket und legt es zusätzlich zu den anderen Informationen baugruppenbezogen in SAP ab.

Der HOMAG ServiceAssist holt sich die Informationen aus SAP, wo das iiRDS-Paket bei der jeweiligen Baugruppe abgelegt ist und importiert es in die Cloud-Anwendung, wo dann der entsprechende Zugriff und die Weitergabe an die App und das CRM-System geregelt wird.

Wie sieht das für AnwenderAnwenderinnenAnwender und AnwenderinnenAnwender:innen aus?

AnwenderAnwenderinnenAnwender und AnwenderinnenAnwender:innen erhalten auf dem Tablet oder Smartphone Lösungsvorschläge. Basis der angezeigten Informationen ist jeweils ein iiRDS-Paket, das PDF und HTML-Inhalte bereithält, die sich genau auf den Fehler an der Maschine beziehen und die dafür möglichen Lösungen zur Verfügung stellen.

Den Einsatz der HOMAG-App können Sie sich hier auf YouTube im HOMAG-Kanal ansehen. Oder Sie probieren selbst einmal ein wenig herum, indem Sie die App HOMAG serviceAssist aus dem AppStore herunterladen.

Und bei Ihnen?

Haben Sie schon eine Idee, wie sich in Ihrem Publikationsprozess von technischen Informationen Metadaten für iiRDS-Pakete erfassen lassen und mit halb- oder ganz automatisierten Lösungen der Maschine und damit für MaschinenbedienerMaschinenbedienerinnenMaschinenbediener und MaschinenbedienerinnenMaschinenbediener:innen situationsbezogen zur Verfügung gestellt werden können? Oder ist bei Ihnen bereits eine Lösung umgesetzt? Treten Sie dazu gern in Kontakt mit uns.