DD# 017 Digitaler Produktpass – Technische Redaktion im Focus

Stellen Sie sich vor, Sie öffnen Ihr Redaktionssystem – und statt eines neuen Kapitels oder das Einbinden eines Bildes haben Sie heute diese neue Aufgabe: „Erstellen Sie den Datenexport für den digitalen Produktpass.“

Was auf den ersten Blick nach einem zusätzlichen Arbeitsschritt aussieht, ist in Wahrheit der Beginn einer grundlegenden Veränderung in der Technischen Redaktion. Denn der digitale Produktpass ist nicht nur eine neue EU-Anforderung – er verändert die Art und Weise, wie wir Informationen erfassen, strukturieren und weitergeben.
Und: Er macht die Technische Redaktion zu einem zentralen Akteur in der digitalen Produktkommunikation.

In unserer vorherigen Folge haben wir erklärt, was der digitale Produktpass ist, warum er kommt und welche Daten er enthalten muss.

Heute gehen wir einen Schritt weiter. Es geht nicht mehr um das Was, sondern um das Wie.
Wie kann eine Technische Redaktion diese Anforderungen praktisch umsetzen?
Wie lässt sich das eigene Informationsmanagement fit machen für 2027?
Und welche neuen Aufgaben und Chancen entstehen dadurch?

Wenn es darum geht den Digitalen Produktpass in der Technischen Redaktion praktisch umzusetzen, sind die eisten Redaktionen noch am Anfang. Die Produktinformationen liegen verteilt in PDFs, Datenblättern oder Word-Dateien. Es gibt kaum Metadaten, keine automatisierten Schnittstellen, und wenn ein Update kommt, wird es manuell eingepflegt.

Einige sind schon einen Schritt weiter. Sie arbeiten mit modularen Inhalten, vielleicht sogar in XML-Strukturen, und nutzen ein CCMS (Component Content Management System) mit Metadaten.

Doch die finale Stufe, die mit dem digitalen Produktpass erreicht werden soll, sind automatisierte, maschinenlesbare Datenflüsse.

Inhalte, die sich aus Redaktionssystem, PLM und ERP-Systemen automatisch zusammenfügen, mit eindeutigen IDs versehen sind und als Datensatz in den Produktpass einfließen können.

Das klingt nach Zukunftsmusik – ist aber der Schritt, den Maschinenbauer bis 2027 realistisch schaffen können.

Ein großer Teil der Informationen, die in den digitalen Produktpass einfließen, stammt direkt aus der Technischen Dokumentation.

Dazu gehören:

• Betriebs- und Wartungsinformationen – also Anleitungen, Sicherheitshinweise, Schmierpläne und Intervalle.
• Konformitätsdaten – CE-Erklärungen, Risikobeurteilungen, Prüfberichte.
• Ersatzteildaten – Stücklisten, Lebensdauer der Teile, Austauschteile.
• Material- und Umweltinformationen – Angaben zu verwendeten Stoffen, Recyclingfähigkeit oder Energieverbrauch.

Diese Inhalte müssen nicht nur vorhanden, sondern auch strukturiert und maschinenlesbar sein.
Das heißt: Texte werden mit Metadaten versehen, Ersatzteile mit eindeutigen IDs verknüpft, Sicherheitsinformationen in standardisierten Formaten bereitgestellt.

Ein praktisches Beispiel hierzu:

Ein mittelständischer Maschinenbauer hat begonnen, seine Wartungsanleitungen schrittweise in XML zu überführen.
Jeder Arbeitsschritt erhält ein Tagging – Bauteil, Werkzeug, Sicherheitskennzeichen, Zeitbedarf.

Diese Informationen werden automatisch an das PLM-System übergeben und dort mit den zugehörigen Komponenten verknüpft.

Wenn der digitale Produktpass erstellt wird, zieht sich das System genau diese Daten heraus – vollständig, konsistent, nachvollziehbar.
Das Handbuch dient damit nicht mehr nur als Nachschlagewerk für den Menschen, sondern als Datenquelle für den Produktlebenszyklus.

Damit verändert sich in der Zukunft auch die Rolle der Technischen Redaktion. Die Redakteur:innen stellen sicher, dass Informationen korrekt, vollständig und maschinenlesbar sind.
Sie übersetzen nicht nur Technik in Sprache – sondern Sprache in Daten.

Das erfordert neue Kompetenzen:

• Verständnis für Datenmodelle und Schnittstellen,
• Wissen über Standards wie iiRDS oder AAS,
• und das Arbeiten in cross-funktionalen Teams mit Entwicklung, IT und Qualitätsmanagement.

Viele Redaktionen beginnen bereits, Rollenprofile zu erweitern – etwa um einen „Informationsarchitekten“ oder „Metadatenbeauftragten“.
Das klingt nach Bürokratie, ist aber in Wahrheit die Voraussetzung dafür, dass der Produktpass später funktioniert.

Der Digitaler Produktpass stellt die Technische Redaktion vor neue Herausforderungen. Beispielsweise wird ein Redaktionssystem bzw. ein CCMS künftig nicht mehr ausreichen, wenn es keine offenen Schnittstellen bietet. Die Systeme müssen in der Lage sein, Daten automatisch zu exportieren – idealerweise in standardisierten Formaten wie iiRDS, JSON oder XML.

Auch der Datenaustausch mit PLM, ERP und PIM wird entscheidend.

Nur so kann der digitale Produktpass am Ende aus allen Quellen zusammengeführt werden: Technische Daten aus der Entwicklung, Materialdaten aus dem Einkauf und Dokumentationsdaten aus der Technischen Redaktion.

Einige Hersteller von Redaktionssystemen bieten bereits erste iiRDS-Schnittstellen oder AAS-Mapping-Funktionen an.

Eine weitere Herausforderung ist die Qualität der Daten. Was früher ein unbemerkt veralteter Satz im PDF war, kann künftig zum Compliance-Problem werden.
Denn sobald Daten aus der Redaktion automatisiert in den Produktpass fließen, sind sie Teil einer behördlich prüfbaren Dokumentation.

Das bedeutet:

• Jede Information braucht eine Quelle, eine Prüfroutine und eine Freigabe.
• Änderungen müssen nachvollziehbar dokumentiert werden.
• Verantwortlichkeiten müssen klar zugewiesen sein.

Viele Unternehmen beginnen daher, Audit-Trails in ihre Redaktions-Workflows zu integrieren.
So lässt sich jederzeit belegen, wer welche Information wann geändert oder freigegeben hat.

Nicht jede Information darf automatisch veröffentlicht werden.
Gerade im Maschinenbau gibt es sensible Daten – etwa zur Lieferkette, zu verbauten Komponenten oder zu verwendeten Materialien.

Hier gilt es, den richtigen Balancepunkt zu finden:
Der digitale Produktpass verlangt Transparenz, aber er darf keine Betriebsgeheimnisse offenlegen.

Das bedeutet für Redaktionen:

• Sensible Daten müssen markiert und gegebenenfalls anonymisiert werden.
• Klare Zugriffskonzepte sind notwendig.
• Und auch die DSGVO spielt mit – denn personenbezogene Daten, etwa in Prüfdokumentationen, dürfen nicht ungefiltert übernommen werden.

Der digitale Produktpass wird kommen – und er wird die Arbeit in der Technischen Redaktion verändern. Dies passiert nicht blitzartig, kein Unternehmen muss den digitalen Produktpass auf einen Schlag einführen.
Sinnvoll ist ein schrittweises Vorgehen, am besten mit einem Pilotprojekt.

Das könnte so aussehen:

1. Vorbereitung: Wer übernimmt welche Rolle? Welche redaktionellen Daten liegen bereits strukturiert vor?
2. Pilotinhalte: Für die gewählte Maschine die Dokumentation auf Kompatibilität zum digitalen Produktpass prüfen und Inhalte identifizieren, die für den Testexport genutzt werden sollen.
3. Metadatenschema: Festlegung des minimalen Sets an Metadaten sowie die Schnittstellen zwischen CCMS, PLM und digitalen Produktpass definieren.
4. Testlauf: Aufbau eines exemplarischen Workflows
5. Validierung: Prüfen, ob alle Informationen vollständig und richtig abgebildet sind. Ergebnisse bewerten und Prozesse dokumentieren.

Dieser Weg ist praxisnah und realistisch – vor allem für mittelständische Unternehmen, die schrittweise wachsen wollen. Wie können diese einzelnen Schritte im Detail aussehen?

In der Phase der Vorbereitung werden alle relevanten Personen und ihre Rolle benannt, welche redaktionellen Daten vorliegen und ein grober Zeitplan für das Pilotprojekt ausgearbeitet.

Folgende Rollen sollten vergeben werden:

• Die Projektleitung (PM)
• Der leitende Redakteur im Team
• Ein Verantwortlicher in der IT-Abteilung
• Zuständige Person für das PLM-System
• Zuständige Person für QM und/oder CE
• Zuständige Person im Einkauf (für Materialdaten)
• eine Person im Bereich Datenschutz / Legal Aspects

In einem Kickoff mit allen Beteiligten wird dann festgelegt, welche Maschine bzw. Produkt für das Pilotprojekt in Frage kommt. Ziel des Kickoffs ist es dann einen Überblick zu bekommen, welche Daten existieren, wie sie strukturiert sind und wo Lücken sind.

Zeitliche Dauer für diese Phase: Etwa 3-4 Wochen

Nach dem Kickoff geht es darum einen Überblick über existierende Daten aufzustellen.

Die Aufgaben der Redaktion umfassen hierbei:

• Inventur vorhandener Inhalte: Welche Teile der Dokumentation (z. B. Wartung, Betrieb, Sicherheit) sind relevant für den Pilot?
• Strukturvorschlag machen: Wie lassen sich bestehende Module logisch auf Produktdaten abbilden?
• Qualität bewerten: Welche Texte sind normkonform, welche müssen überarbeitet werden?

• Abstimmung: Mit PLM und IT das Metadatenschema abstimmen – welche Felder kommen aus der Redaktion in den digitalen Produktpass
• Redaktionsleitfaden erweitern: Wie werden Metadaten gepflegt? Welche Felder sind Pflicht?
• Normabgleich durchführen: Welche Normen und Formate sind relevant (z. B. iiRDS, IEC/IEEE 82079, VDI 2770)?
• Pilotinhalte markieren: Inhalte identifizieren, die für Testexporte genutzt werden.

Zeitliche Dauer für diese Phase: Etwa 1-2 Wochen

Als nächstes Ziel sollte ein klar definiertes, praxistaugliches Datenschema erstellt werden, das direkt in der Redaktion gepflegt werden kann.

Die Aufgaben der Redaktion umfassen hierbei:

• Ein erstes Excel- oder XML-Template entwerfen, das Autoren später verwenden können.

• Minimalset an Datenfelder definieren – Exemplarischer Auszug:
  – produktID
  – produktName
  – hersteller
  – versionsnummer
  – sprache
  – kapitel
  – abschnitt (Sicherheit, Betrieb, Wartung)
  – zutreffendeTeile
  – quelle (Pfad / URL)

Zeitliche Dauer für diese Phase: Etwa 1-2 Wochen

Als nächstes testet Die Redaktion, wie Inhalte mit Metadaten versehen und automatisiert ausgegeben werden. Ziel dieses Testlaufes ist es einen ersten durchlaufbaren Workflow zu erproben, von der redaktionellen Erstellung bis zum Export.

Die Aufgaben der Redaktion umfassen hierbei:

• Autorenbriefing: Redakteur:innen bekommen das Metadaten-Template und eine Schulung zur Metadatenpflege im Redaktionssystem — wie taggen, welche Felder verpflichtend sind.
• Pilotkapitel auswählen: z. B. eine Wartungsanleitung oder ein Sicherheitsabschnitt.
• Tagging durchführen: Inhalte mit Produkt-, Sicherheits- und Strukturmetadaten versehen.
• Mapping abstimmen: Redakteure verknüpfen Teile aus PLM mit Textreferenzen (gemeinsam mit PLM)
• Export begleiten: Testexport als iiRDS/JSON erzeugen, Format prüfen, Rückmeldung geben
• Dokumentieren: Welche Felder fehlen? Welche Strukturen müssen nachgebessert werden?

Zeitliche Dauer für diese Phase: Etwa 2-3 Wochen

In der letzten Phase überprüft die Redaktion, ob die erzeugten Daten korrekt, konsistent und fachlich stimmig sind.

Die Aufgaben der Redaktion umfassen hierbei:

• Inhaltliche Prüfung: Stimmen die Anweisungen mit der realen Maschine überein?
• Metadatenkontrolle: Sind Pflichtfelder ausgefüllt? Wurden alle IDs korrekt zugeordnet? Update des Metadatenschemas (falls notwendig)
• Konsistenzcheck: Wurden sicherheitsrelevante Abschnitte richtig gekennzeichnet und versioniert?
• Abgleich mit PLM: Stimmen PartIDs zwischen Text und Datenbank?
• Validierungsbericht erstellen: Alle Auffälligkeiten dokumentieren, Korrekturvorschläge machen. Was lief gut? Wo waren Datenlücken? Welche Ressourcen wurden benötigt?

• Freigabeprozess begleiten: Roadmap für Rollout erstellen, Priorisierung weiterer Maschinen

Zeitliche Dauer für diese Phase: Etwa 2-3 Wochen

Wenn wir die Zeit über die 5 Phasen unseres Beispiels zusammenrechnen kommen wir auf eine gesamte zeitliche Dauer von 9 – 12 Wochen für dieses Pilotprojekt.

Im Laufe des Pilotprojektes sind auch einige Personen im Prozess mit eingebunden:

Projektleiter, Redakteure, PLM, IT, QM, CE, Einkauf / Lieferantenmanagement, Datenschutz.

Nach dem Pilotprojekt zieht die Redaktion Bilanz. Sie bewertet, wie sich Aufwand, Nutzen und Datenqualität entwickelt haben, und erstellt Handlungsempfehlungen für den Rollout.

Auch hier können Aufgaben für die Redaktion definiert werden:

• Feedback einholen: von Autoren, PLM, IT und CE-Verantwortlichen.
• Redaktionsrichtlinien anpassen: Was hat sich bewährt, was muss geändert werden?
• Checklisten und Templates verbessern
• Trainingsunterlagen erstellen: Für weitere Teams oder Produktlinien.
• Kennzahlen erheben: Zeitaufwand, Fehlerquote, Metadatenvollständigkeit.
• Vorschläge für Automatisierung erarbeiten: z. B. automatische ID-Zuweisung oder Tagging-Regeln.

Der digitale Produktpass ist keine zusätzliche Bürde für die Technische Redaktion – er ist eine Chance, die eigene Arbeit sichtbarer, wertvoller und zukunftssicher zu machen. Denn mit dem Produktpass rückt die Redaktion aus der Ecke der „Pflichterfüller“ in die Rolle der Datenarchitekten. Sie gestaltet aktiv mit, wie Wissen über Maschinen künftig erfasst, strukturiert und genutzt wird.

Wo früher Dokumente abgelegt wurden, entstehen nun vernetzte Informationssysteme, die Wartung, Service und Recycling unterstützen. Jede sauber gepflegte Information, jedes Metadatenfeld, jede eindeutige Zuordnung trägt dazu bei, dass eine Maschine im gesamten Lebenszyklus transparent bleibt. Das eröffnet neue Möglichkeiten – etwa, Inhalte automatisiert in Serviceportale zu spielen, Warnhinweise kontextbezogen anzuzeigen oder Nachhaltigkeitsdaten direkt aus der Dokumentation zu gewinnen.

Kurz gesagt: Der digitale Produktpass macht die Technische Dokumentation zu einem zentralen Bestandteil des digitalen Zwillings. Und das verändert alles – von der Wahrnehmung der Redaktion im Unternehmen bis hin zu ihrer strategischen Bedeutung. Wer jetzt beginnt, redaktionelle Daten systematisch aufzubauen, schafft nicht nur Konformität, sondern legt den Grundstein für eine neue, vernetzte Informationskultur.