Was PIM-Anwender über den Digital Product Pass (DPP) wissen müssen

11.02.2025 | Thomas Kern 

Digital Product Pass (DPP)  – was zunächst wie eine weitere bürokratische Herausforderung von der EU erscheinen mag, birgt auch Chancen. Denn Transparenz stärkt das Vertrauen der Verbraucher und sorgt für nachhaltige Kundenbeziehungen. Doch was genau verlangen die Regularien, und wie können Unternehmen diese Anforderungen effizient umsetzen?

Es gibt ja bereits eine Fülle von Informationen von Dienstleistern, Verbänden, Behörden und Hochschulen zu diesem Thema. Ich möchte die Informationen in den PIM-Kontext einordnen.

Was ist der Hintergrund?

Der Digital Product Pass (DPP) ist als eine Maßnahme in den Green Deal bzw. Sustainable Products Regulation (ESPR) einzuordnen. Das Ziel ist es, kurz gesagt, einen nachhaltigen Produktlebenszyklus zu schaffen („Circular Economy“, „Kreislaufwirtschaft“). Um dieses Ziel zu erreichen, soll der Käufer über das Produkt vollumfassend informiert werden („Kaufentscheidung) und ebenso die Behörden („Einhaltung von Gesetzen“). Behörden benötigen natürlich andere Produktinformationen als der Käufer.

Was ist das Vorhaben und der Zeitplan?

Ab 2026 bis 2030 sollen schrittweise alle relevanten Produktgruppen einen DPP erhalten (ausgenommen sind Lebens- und Futtermittel sowie Arzneimittel). Das bedeutet, dass jedes Produkt identifiziert (QR-Code, Chip) und über die Id die Informationen eingesehen werden können. Im Prinzip betrifft dies alle industriellen Hersteller und Händler.

Der DPP ist im Prinzip ein Datensatz. Ich vergleiche das gerne mit Datensätzen in BMEcat oder ähnlichen Formaten. Der Datensatz muss Käufern und Behörden auf Knopfdruck zur Verfügung stehen. Dafür sind direkte Zugriffe auf Datenbanksysteme notwendig. Die Visualisierung für Käufer kann bspw. auf Weboberflächen oder Apps erfolgen. Für Behörden oder B2B-Kunden kann der Datensatz über sogenannte API-Schnittstellen bereitgestellt werden.

Welche Produktinformationen sind in dem DPP-Datensatz enthalten?

Das wird eine ganze Menge an Inhalten sein und sich laufend erweitern; ich sage mal, der Phantasie sind hier keine Grenzen gesetzt:

• Produktidentifizierungen (Artikelnummer, EAN, Bezeichnung usw.)
• Produktbeschreibungen
• Technische Produktdaten (Abmessungen, Material/Oberfläche, elektrische und mechanische Eigenschaften usw.)
• Logistische Daten (Verpackung, Gewicht, Zolltarifnummer usw.)
• Produktbilder (Fotos, Zeichnungen)
• Zulassungen, Zertifikate
• Produktbeziehungen (Ersatzteile, Zubehör, Lieferumfang)
• Bedien- und Montageinformationen
• Reparaturhinweise
• Sicherheitshinweise
• Bestandteile des Produkts (bspw. relevant für Entsorgung)
• Daten zur Ermittlung von CO2-Fußabdruck und H2O-Fußabdruck

Abbildung der Produktinformationen im DPP-Datensatz

Jetzt kann man sich bildlich vorstellen was dies an riesigen Datenmengen verursacht. Es gibt ja eine Vielzahl von völlig unterschiedlichen Produkten mit unterschiedlichen Beschreibungen. Anderseits werden auch die unterschiedlichsten Begriffe für Eigenschaften verwendet. Manche sprechen beispielsweise bei einem Kunststoffrohr vom Durchmesser, andere vom Innendurchmesser oder Rohrdurchmesser.
Das heißt die Beschreibung und die Sprache sollten produktgruppenspezifisch genormt bzw. klassifiziert werden. Da gibt es glücklicherweise seit Jahrzehnten schon gebräuchliche Klassifizierungssysteme wie ECLASS oder ETIM, die man hierfür einsetzen kann.

Technische Umsetzung von DPP

„Just another tool“. Die technische Umsetzung erfordert folgende Komponenten:

• Ein Datenbanksystem, genauer gesagt ein Product Information System (PIM). Die Daten müssen validiert vorliegen
• Integrierte Standardklassifikationen (ECLASS, ETIM), wie oben erwähnt
• Channel Output Management zur Ausgabesteuerung der DPP-relevanten Artikel (mindestens die Artikel, die ab 2026 verkauft wurden bzw. werden) und der erforderlichen Inhalte und Sprachen
• REST-API („Json“) zur Datenbereitstellung in einem Format X für den direkten und sicheren Datenzugriff, wie oben erwähnt

Das Format X ist noch nicht bekannt. Verschiedene Player, ich sage mal so „bringen sich hier ein“. Ich nehme an, dass sich das Asset Administration Shell (AAS)-Format durchsetzen wird, siehe https://industrialdigitaltwin.org.

Aus meiner Sicht hat dieses Modell unter anderem folgende Vorteile:

• Die Beschreibung anhand von Submodellen ist fortgeschritten, u. a. Nameplate (Produktidentifizierung), Reliability (Elektrokomponenten), Technical Data, Contact Informations (Kontaktdaten). Siehe: https://industrialdigitaltwin.org/content-hub/teilmodelle
• Standardklassifikation ECLASS ist im „Submodel Technical Data“ eingebunden

Fazit

Ohne PIM kein DPP. Haben Sie bereits ein PIM mit ECLASS, REST-API und Ausgabesteuerung dann können Sie sich recht entspannt zurücklehnen – zumindest was den technischen Part betrifft. REST-API und Ausgabesteuerung sind typischerweise beim PIM-System standardmäßig enthalten. Sollten Sie noch kein ECLASS haben, dann empfehle ich den Einsatz, optimalerweise integriert im PIM, zu prüfen.

Inhaltlich ist es sicher notwendig Informationen zu ergänzen. Dazu sind die inhaltlichen Anforderungen an DPP-Daten zu listen, mit den bestehenden Daten im PIM abzugleichen und das Delta zu prüfen, sprich wo die fehlenden Daten zu pflegen sind (bspw. im ERP oder im PIM). Diesen Prozess kann man nicht früh genug beginnen, weil er erfahrungsgemäß am aufwändigsten ist.