Warum der digitale Produktpass eine Frage der PLM-Architektur ist
Der digitale Produktpass ist von der politischen Debatte auf den Zeitplan für die Einhaltung gesetzlicher Vorgaben gerückt. Nach der EU-Batterieverordnung wird ein Batteriepass ab dem 18. Februar 2027 für Batterien in Elektrofahrzeugen, Industriebatterien (über 2 kWh) und Batterien für leichte Verkehrsmittel verpflichtend. Die Ökodesign-Verordnung für nachhaltige Produkte (ESPR), die seit Juli 2024 gilt, erweitert den Produktpass über eine Reihe delegierter Rechtsakte bis in die 2030er-Jahre auf Produktgruppen wie Stahl, Textilien, Aluminium, Möbel und Elektronik.
Unternehmen, die Siemens Teamcenter einsetzen, denken oft zuerst an den Kauf eines „DPP-Systems“. Das kehrt die Problemstellung um. Ein Großteil der für den Pass benötigten Daten, etwa Identität, Zusammensetzung, Stoffe, Herkunft, Konformitätsnachweise sowie Reparatur- und End-of-Life-Daten, ist bereits im PLM-System modelliert. Der Pass bündelt und veröffentlicht Daten, die das Unternehmen schon besitzt.
Die Vorbereitung des PLM auf den digitalen Produktpass ist daher zuerst eine Frage des Datenmodells und erst danach eine Entscheidung über Compliance-Software. Entscheidend ist, welche Teamcenter-Objekte die relevanten Daten enthalten und ob sie ausreichend strukturiert, gepflegt und zugänglich sind. Mit einem passenden Datenmodell kann eine Produktpass-Plattform darauf aufbauen; ohne dieses Fundament hilft auch die Plattform nicht. Sieben Objekte sind besonders wichtig.
Welche Daten der digitale Produktpass verlangt
Die Datenanforderungen an den digitalen Produktpass ähneln sich über ESPR-Produktgruppen und die Vorlage für den Batteriepass hinweg. Ein Pass muss Folgendes enthalten:
- Eine eindeutige Produktkennung (Modell-, Chargen- oder Seriennummer), die mit einem Datenträger wie QR-Code, GS1 Digital Link oder RFID verknüpft ist
- Material- und Stoffzusammensetzung einschließlich besorgniserregender Stoffe und bei Batterien kritischer Rohstoffe wie Kobalt und Lithium
- Herkunft und Rückverfolgbarkeit in der Lieferkette
- Umweltkennzahlen wie den CO₂-Fußabdruck
- Informationen zu Reparierbarkeit, Ersatzteilen und Demontage
- Daten zu Lebensende und Recycling
- Konformitätsnachweise wie die EU-Konformitätserklärung, Zertifikate, Prüfdaten und eine Zusammenfassung von Risikobewertungen
Zwei Eigenschaften prägen die Architektur. Die Daten betreffen den gesamten Lebenszyklus von der Konstruktion über die Fertigung bis zur Wartung; daher besitzt kein einzelnes System alle Informationen. Außerdem erfordern die Vorschriften eine Granularität auf Produkt- und häufig auf Einzelstückebene sowie eine prüfbare Historie statt eines statischen Datenblatts.
Warum Teamcenter eine geeignete Grundlage ist
Teamcenter ist das führende System für Konstruktionsdaten: Produktstruktur, Engineering-Stückliste, Materialspezifikationen, Änderungshistorie und Entwicklungsdokumentation. Ein Produktpass bündelt und veröffentlicht diese Daten, statt sie zu ersetzen.
Bei Bewertungen der DPP-Bereitschaft beobachtet CloudZen regelmäßig, dass Teams die Auswahl einer Produktpass-Plattform überschätzen und den Aufwand zur Vereinheitlichung technischer Daten in Teamcenter-Objekten unterschätzen. Die Plattformentscheidung dauert Wochen; die Arbeit am Datenmodell eher Quartale. Dort entscheidet sich, ob die Anforderungen erfüllt werden.
Die sieben entscheidenden Teamcenter-Objekte
1. Item und Item Revision – Produktidentität
Das Item (ein WorkspaceObject) und seine Item Revisions tragen die Produktidentität. Die eindeutige Kennung des Passes muss sich zuverlässig einer bestimmten Item Revision zuordnen lassen.
- Ordnet die Passkennung einer Modell-, Chargen- oder Seriennummer zu
- Gleicht interne Item-IDs mit externen Schlüsseln wie Herstellerteilenummer, GTIN und GS1 Digital Link ab
- Revisionsregeln und Effectivity bestimmen, welche Revision der Pass beschreibt
- Identität auf Modellebene gegenüber Einzelstückebene (Serialisierung – Objekt 7)
Typische Schwachstelle: Sprechende Teilenummern, die nie als externe Schlüssel gedacht waren, und eine übernommene statt bewusst definierte Kennungs-Governance.
2. BOM View Revision und Produktstruktur – Zusammensetzung
Die Zusammensetzung liegt in der Struktur. Die BOMViewRevision bildet die Baugruppenaufteilung ab; Occurrences enthalten Mengen und Konfigurationen. Daraus werden Stoffgehalte, Recyclinganteile und CO₂-Werte aggregiert.
- Liefert die Zusammensetzung und die Grundlage für alle Aggregationsberechnungen
- Variant Management und Effectivity erfordern die Auflösung einer konkret gültigen Struktur statt einer allgemeinen Stückliste
- Abgleich von EBOM, MBOM und As-Built-Struktur über Manufacturing Process Planner
Typische Schwachstelle: Eine nicht aufgelöste Occurrence oder Abweichungen zwischen EBOM und MBOM verfälschen Aggregationen unbemerkt, bis auf einem veröffentlichten Pass ein falscher Wert erscheint.
3. Classification (CLS) – maschinenlesbare Merkmale
Ein Produktpass ist maschinenlesbar. Freitext lässt sich dafür kaum zuverlässig nutzen. Classification mit den in BMIDE definierten CLS-Klassenhierarchien enthält strukturierte Merkmale, die sich über Zehntausende Teile hinweg einheitlich auslesen lassen.
- Standardisierte Material- und Teilemerkmale für die automatisierte Auswertung
- Zuordnung zu externen Taxonomien wie ECLASS und produktspezifischen Schemata
- Erfordert eine verantwortliche Person für das Datenwörterbuch und aktive Governance
Typische Schwachstelle: Nicht klassifizierte Teile oder Freitext sind ein häufiger Grund, warum die DPP-Datenextraktion stockt.
4. Material and Substance Compliance – Stoffe und kritische Rohstoffe
Das Teamcenter-Modell Material and Substance Compliance verwaltet Materialien und deklarierte Stoffe, berechnet Aggregationen nach RoHS und REACH/SVHC und übernimmt Lieferantenerklärungen aus IMDS (Automobilindustrie) und BOMcheck (Elektronik).
- Deklarierte Stoffe, besorgniserregende Stoffe und kritische Rohstoffe (Kobalt, Lithium, Nickel)
- SCIP-Meldungen für SVHC über 0,1 Masse-% als Vorläufer der Stofftransparenz im DPP
- Abdeckung durch Lieferantenerklärungen und geteilte Verantwortung von Entwicklung und Compliance
Typische Schwachstelle: Stoffdaten verbleiben in Lieferanten-PDFs und Tabellen statt in Bezug zur Stückliste modelliert zu werden. Hier geraten viele Programme ins Stocken.
5. Document Revision und Dataset – Konformitätsnachweise
Nachweise liegen als Datasets und verwaltete Document Revisions vor und sind mit genau der Item Revision verknüpft, für die sie gelten.
- EU-Konformitätserklärung, Prüfzertifikate, Sicherheitsdaten sowie Anleitungen zu Reparatur, Demontage und Recycling
- Versioniert und an die zertifizierte Revision gebunden
Typische Schwachstelle: Lose PDFs in Netzwerkordnern oder ein Zertifikat, das der falschen Revision zugeordnet ist – letzteres ist sogar problematischer als ein fehlendes Zertifikat.
6. Change Management – Herkunft und Audit-Trail
Änderungsobjekte (ECR/ECN), die über EPM Workflow gesteuert und nativ versioniert werden, belegen die Herkunft der Daten hinter jedem Passfeld.
- Erfasst, was wann und von wem geändert wurde
- Passrelevante Merkmale müssen über kontrollierte Änderungsprozesse statt durch direkte Bearbeitung geändert werden
Typische Schwachstelle: Merkmale werden in Active Workspace direkt überschrieben. Dadurch geht die von den Vorschriften geforderte Prüfbarkeit verloren.
7. Serialized und As-Built Physical Part – Pass auf Einzelstückebene
Batteriepässe werden für einzelne Einheiten ausgestellt. Physical Part und As-Built-Struktur verbinden ein gefertigtes Einzelstück mit seiner Konfiguration und über den Digital Thread mit Betriebs- und End-of-Life-Daten.
- Zusammensetzung und Konformität je Seriennummer statt nur je Modell
- Verknüpfung mit MES und ERP zur Erfassung des As-Built-Zustands sowie mit dem physischen Datenträger im Feld
Typische Schwachstelle: Eine nachträgliche Einführung der Serialisierung ist unter Termindruck teuer; für Produktgruppen mit Einzelstückanforderungen reichen Daten auf Modellebene nicht aus.
Governance- und Bereitstellungsschicht
Zwei Funktionen betreffen alle sieben Objekte. Der über EPM Workflow gesteuerte Release Status legt fest, welche Daten verbindlich sind: Ein Produktpass veröffentlicht freigegebene Daten, keine laufende Arbeit. In BMIDE modellierte Forms und erweiterte Attribute enthalten passspezifische Felder, ohne das Standarddatenmodell zu verändern.
Die Bereitstellung ist eine eigene Aufgabe. Für den Datenaustausch zwischen Lieferanten und Herstellern entwickelt sich ein Standard: die Asset Administration Shell (AAS), eine digitale Zwillingshülle, die Siemens in Teamcenter integriert. Ob die Übertragung über AAS, ein Produktpass-Register oder eigene SOA-/REST-Dienste erfolgt: Direkte Datenbankabfragen und Punkt-zu-Punkt-Schnittstellen über ITK eignen sich nicht für einen stets aktuellen Pass je Einzelstück. Hier werden eine API-First-Integrationsstrategie und eine sorgfältige ERP-Integration zu den Mechanismen, die den Produktpass ermöglichen.
Bewährte Vorgehensweisen
- DPP-Merkmale auf Standardobjekten mit Forms und BMIDE modellieren – keine parallele Produktpass-Datenbank aufbauen
- Classification vor der Datenextraktion befüllen und steuern
- Stoffdaten über IMDS, BOMcheck und SCIP in Substance Compliance mit Bezug zur Stückliste übernehmen
- Jede Document Revision mit genau der Item Revision verknüpfen, für die sie einen Nachweis liefert
- Änderungen an passrelevanten Merkmalen über Change Management (EPM Workflow) steuern
- Den Release Status definieren, der die Veröffentlichung eines Passes erlaubt
- Abgleich von EBOM und MBOM sowie Serialisierung für Produktgruppen mit Einzelstückanforderungen frühzeitig lösen
- Daten über gesteuerte APIs und AAS bereitstellen, nicht über direkte Datenbankabfragen oder ITK-Punkt-zu-Punkt-Verbindungen
- Interne Kennungen GTIN und GS1 Digital Link zuordnen
- Verantwortung für Daten zwischen Entwicklung, Produkt-Compliance und Lieferkette festlegen
Häufige Anti-Patterns
- Den DPP als neue Datenbank aufbauen, die PLM-Daten dupliziert und eine zweite Datenquelle schafft
- Stoff- und Konformitätsdaten in Tabellen statt mit Bezug zur Stückliste verwalten
- Nicht klassifizierte Teile oder Freitext, die eine manuelle Datenextraktion erfordern
- Nachweise in Netzwerkordnern ohne Verknüpfung zu den jeweiligen Item Revisions
- Auf Einzelstück-Batteriepässe nur mit Daten auf Modellebene reagieren
- Momentaufnahmen ohne Herkunftsnachweis extrahieren, die nach jeder Datenänderung veralten
Geschäftlicher Nutzen
- Schnellere Umsetzung der Anforderungen, wenn delegierte Rechtsakte für weitere Produktgruppen gelten
- Eine einzige verlässliche Datenquelle ohne parallele Produktpass-Datenbank
- Wiederverwendung vorhandener Teamcenter-Daten, Governance und des Digital Thread
- Auditfähige Herkunftsnachweise durch native Änderungs- und Revisionssteuerung
- Weniger manuelle Datenextraktion und Nachverfolgung bei Lieferanten
- Eine Grundlage für Batteriepässe auf Einzelstückebene und künftige Produktgruppen
- Interoperabilität über AAS und eine API-First-Bereitstellungsschicht
- Geringere langfristige Kosten für die Einhaltung von Vorgaben im gesamten Produktportfolio
Fazit
Hersteller, die Anforderungen schnell und kostengünstig erfüllen möchten, sollten den digitalen Produktpass als Datenarchitektur-Aufgabe und nicht als Beschaffungsvorhaben betrachten. In Teamcenter sind die nötigen Daten bereits auf sieben Objekte verteilt: Item und Item Revision, BOMViewRevision, Classification, Material and Substance Compliance, Document Revision, Change sowie das serialisierte Physical Part. Diese Daten müssen strukturiert, gesteuert und zugänglich sein, bevor der delegierte Rechtsakt für die jeweilige Produktgruppe gilt. Ein strukturiertes Teamcenter Health Check mit Blick auf die Datenbereitschaft für den digitalen Produktpass zeigt schnell, wo Sie stehen. Batterien im Februar 2027 sind dabei nur der erste verpflichtende Anwendungsfall.
Häufig gestellte Fragen
Was ist ein digitaler Produktpass mit Teamcenter?
Er ist kein Modul, das Sie kaufen. Ein digitaler Produktpass mit Teamcenter bündelt und veröffentlicht die erforderlichen Daten zu Identität, Zusammensetzung, Stoffen, Konformitätsnachweisen und Lebenszyklus, die bereits in Teamcenter-Objekten vorliegen. Die Daten werden einem Register und einem Datenträger bereitgestellt.
Welche Teamcenter-Objekte enthalten Daten für den digitalen Produktpass?
Vor allem sieben: Item und Item Revision, BOMViewRevision und Produktstruktur, Classification, Material and Substance Compliance, Document Revision und Dataset, Änderungsobjekte sowie das serialisierte As-Built Physical Part.
Müssen wir Teamcenter ersetzen, um die DPP-Anforderungen zu erfüllen?
Nein. Teamcenter bildet den Großteil der Passdaten bereits ab. Entscheidend sind Datenqualität bei Classification und Stoffdaten, Governance für Änderungen und Freigaben, Serialisierung für Produktgruppen mit Einzelstückanforderungen und eine API-basierte Bereitstellungsschicht – nicht der Austausch der Plattform.
Ab wann wird der digitale Produktpass verpflichtend?
Die erste feste Frist betrifft den Batteriepass: Er wird ab dem 18. Februar 2027 verpflichtend. Die ESPR führt weitere Produktgruppen anschließend schrittweise über delegierte Rechtsakte ein. Prüfen Sie den Zeitplan für Ihre konkrete Produktgruppe.
Woran scheitern Teamcenter-DPP-Programme am häufigsten?
An Daten zur Zusammensetzung und zu Stoffen: Materialinformationen liegen bei Lieferanten als Erklärungen und Tabellen vor, statt mit Bezug zur Stückliste modelliert zu sein. Lücken in Classification und fehlende Serialisierung sind weitere häufige Hindernisse.
