Digital Product Passport & Supply-Chain-Integration

Der Digital Product Passport ist nur so zuverlässig wie die Daten, auf denen er basiert. Für Hersteller, die mit den sich weiterentwickelnden EU-Regulierungsanforderungen umgehen müssen, liegt die eigentliche Herausforderung selten im konzeptionellen Bereich: Die meisten Unternehmen verstehen bereits, dass ein DPP Lebenszyklus-, Material- und Compliance-Daten enthalten muss. Die eigentliche Schwierigkeit besteht darin, diese Daten aus isolierten Unternehmenssystemen zu extrahieren, sie zu konsolidieren und in einem strukturierten, revisionssicheren Format bereitzustellen.

Dieser Artikel konzentriert sich auf die Integrationsebene: welche Daten in einen DPP einfliessen müssen, welche Quellsysteme beteiligt sind, welche Architekturmuster am besten geeignet sind und wo die meisten Unternehmen auf Probleme stossen.

Die Datenintegrations-Herausforderung beim DPP

Der EU Digital Product Passport, der im Rahmen der Ökodesign-Verordnung für nachhaltige Produkte (ESPR) definiert ist, verpflichtet Hersteller dazu, produktbezogene Daten entlang der gesamten Wertschöpfungskette zugänglich zu machen: für Regulierungsbehörden, supply chain Partner, Recyclingunternehmen und Endverbraucher. Diese Daten umfassen unter anderem Produktzusammensetzung, CO2-Fussabdruck, Reparierbarkeit und Informationen zur Entsorgung.

Der Grossteil dieser Daten ist bereits im Unternehmen vorhanden. Das Problem ist, dass sie über mehrere Systeme verteilt sind, von verschiedenen Teams gepflegt werden, in unterschiedlichen Formaten vorliegen und unterschiedlichen Aktualisierungszyklen folgen. Ein ERP-System enthält Chargen- und Produktionsdaten. Ein PLM-System enthält die massgebliche Stückliste und Materialkomplianz-Nachweise. Lieferantenerklärungen gelangen über Beschaffungsportale oder als E-Mail-Anhänge ins Unternehmen. Logistikdaten liegen in WMS- und TMS-Plattformen. Diese Systeme zuverlässig und kontrolliert miteinander zu verbinden, ist die zentrale Integrationsherausforderung — und eine, die frühzeitig im Programm architektonische Entscheidungen erfordert, nicht als nachträgliche Überlegung.

Welche Daten müssen für den DPP integriert werden?

Ein vollständiger DPP aggregiert Daten aus mehreren Bereichen. Die wichtigsten Kategorien sind:

• Materialzusammensetzung: Stücklistendaten, Erklärungen zu gefährlichen Stoffen, REACH-Compliance-Nachweise
• Produktionsdaten: Produktionsstandort, Chargenidentifikation, Qualitätszertifikate
• CO2- und Umweltdaten: Produkt-CO2-Fussabdruck (PCF), Energieverbrauch je Lebenszyklusphase
• Lieferantenerklärungen: Konfliktmineralien, Zertifikate zum Recyclinganteil, Nachhaltigkeitsbestätigungen der Lieferanten
• Logistik und Vertrieb: Rückverfolgbarkeitsdaten, Versandnachweise, Zolldokumentation
• Informationen zur Entsorgung: Demontageanleitungen, Recyclingbewertungen, Informationen zu Pfand- oder Rücknahmesystemen

Jede Kategorie ist einem oder mehreren Quellsystemen im Unternehmen oder in der supply chain zugeordnet. Die Integrationsherausforderung besteht nicht nur darin, diese Daten einmalig zu extrahieren, sondern sie als lebendigen Datensatz zu pflegen, der sich aktualisiert, wenn sich Quelldaten ändern: wenn eine neue Produktionscharge angelegt wird, wenn ein Lieferant eine Erklärung erneuert oder wenn ein Produkt in einen neuen Absatzmarkt geliefert wird.

Integrationsarchitektur für Digital Product Passports

Eine DPP-Plattform ist keine eigenständige Anwendung. Sie fungiert als Datenintegrations-Hub, der Produktdaten aggregiert, normalisiert und in dem Format bereitstellt, das die jeweilige Regulierung oder der Industriestandard vorschreibt — sei es ESPR, IEC 62474 oder eines der sektorspezifischen Schemata, die von Normierungsgremien wie GS1 entwickelt werden.

Das empfohlene Architekturmuster ist ein Hub-and-Spoke-Modell mit event-driven Datenflüssen. Eine zentrale DPP-Datenplattform fungiert als System of Record für Produktpass-Daten, während Quellsysteme Daten über definierte APIs oder Message Buses übermitteln oder bereitstellen. Dadurch wird die DPP-Plattform von einzelnen Quellsystemen entkoppelt, sodass Änderungen an einer einzelnen Integration vorgenommen werden können, ohne dass koordinierte Releases über das gesamte Unternehmen erforderlich sind.

Die Integrationsplattform besteht aus vier zentralen Komponenten. Die erste ist eine Integrationsschicht — eine Middleware oder ein Event Broker —, die Daten von Quellsystemen empfängt und weiterleitet. Die zweite ist ein DPP-Datenspeicher, der strukturierte, versionierte Produktdatensätze persistiert. Die dritte ist eine Normalisierungs- und Validierungsschicht, die Quellsystemformate auf das DPP-Datenmodell abbildet. Die vierte ist eine Bereitstellungsschicht — entweder ein REST API oder ein QR-Code-verknüpfter Endpunkt —, die den DPP in dem von der Regulierung geforderten Format an autorisierte Empfänger ausliefert.

Für Unternehmen, die bereits Confluent Platform oder Apache Kafka betreiben, ist event-driven Integration mit themenbasierten Message Flows eine architektonisch gut geeignete Lösung. Jedes Quellsystem veröffentlicht Datenänderungen in einem dedizierten Topic, und die DPP-Plattform verarbeitet diese Events nahezu in Echtzeit. So wird ein aktueller Produktdatensatz gepflegt, ohne auf Polling oder Batch-Synchronisierungsfenster angewiesen zu sein.

Integrationsmuster nach Quellsystem

Das geeignete Integrationsmuster hängt vom Quellsystem, dem Datenvolumen und der Häufigkeit der Datenänderungen ab. Die nachfolgende Tabelle fasst die wesentlichen Aspekte der wichtigsten DPP-Datenquellen zusammen.

ERP

ERP-Systeme — darunter SAP S/4HANA und Oracle ERP Cloud — sind die primäre Quelle für Produktstammdaten, Chargenrückverfolgung und Produktionsstandortinformationen. SAP bietet IDocs und BAPIs für Legacy-Integrationen sowie OData APIs über die SAP Business Technology Platform für moderne Implementierungen. Bei hohem Datenvolumen ist Change Data Capture (CDC) über Datenbankverbindungen eine zuverlässige Alternative, die den ERP-Anwendungsserver entlastet und eine nahezu echtzeitfähige Synchronisierung mit der DPP-Plattform ermöglicht.

PLM

Product Lifecycle Management Systeme sind die massgebliche Quelle für Stücklistendaten und Materialkomplianz-Informationen. Die PLM-to-DPP-Integration umfasst typischerweise die Extraktion von BoM-Snapshots zu definierten Engineering-Release-Meilensteinen — keine kontinuierlichen Event-Flows, da sich PLM-Daten im Rhythmus der Produktentwicklung ändern, nicht im Takt operativer Transaktionen. REST API- oder dateibasierter Export, gefolgt von Transformation und Ingestion in die DPP-Plattform, ist der Standardansatz. Die Integrationslogik muss unvollständige oder im Entwurfsstatus befindliche Stücklisten erkennen und zurückweisen.

Lieferantendaten

Lieferantendaten sind der komplexeste Integrationsvektor. Nachhaltigkeitserklärungen, Konfliktmineraliendeklarationen und Recyclinganteilszertifikate gehen häufig als PDFs, Tabellenanhänge oder Portaleinreichungen ein — nicht als strukturierte API-Aufrufe. Ein Lieferanten-Onboarding-Portal mit einem strukturierten Datenmodell für eingehende Erklärungen reduziert manuelle Verarbeitungsschritte und schafft einen revisionssicheren Nachweis, der bis zur Einreichung durch den Lieferanten zurückverfolgt werden kann. Wer diese Realität von Anfang an einplant, statt API-basiertem Austausch vorauszusetzen, vermeidet erheblichen Nachbesserungsaufwand.

Logistik und Vertrieb

Logistikdaten stammen in der Regel aus Lagerverwaltungssystemen, Transportmanagementsystemen oder Drittlogistikanbietern. Die für den DPP relevanten Daten umfassen chargenbezogene Versandnachweise, Ursprungslanddokumentation und Rückverfolgungsnachweise. Die Anforderungen an die Rückverfolgbarkeit variieren je nach Produktkategorie: Batterien, Textilien und Lebensmittel gehören zu den ersten Kategorien, bei denen logistische Rückverfolgbarkeit unter ESPR und verwandten Regulierungen zur Pflicht wird.

Data Governance für DPP

Data Governance darf keine nachträgliche Überlegung sein. Sie muss von Beginn an in die Integrationsarchitektur eingebaut werden — bevor der erste Konnektor entwickelt wird.

Dateneigentümerschaft ist die erste zu klärende Governance-Anforderung. Jedes Datenelement im DPP sollte ein einziges, klar definiertes System of Record haben. Wenn CO2-Fussabdruck-Daten sowohl vom PLM-System als auch durch manuelle Korrekturen in der DPP-Plattform aktualisiert werden können, entstehen Konflikte und Auditprotokolle werden unzuverlässig. Das Integrationsdesign muss festlegen, welche Quelle Vorrang hat und unter welchen Bedingungen eine manuelle Überschreibung zulässig ist.

Versionierung ist die zweite Anforderung. DPP-Regulierungen verlangen, dass historische Versionen des Passes aufbewahrt werden, damit Behörden den Zustand eines Produktdatensatzes zu jedem Zeitpunkt prüfen können. Die Integrationsplattform muss Zeitpunkt-Snapshots erfassen und speichern — nicht nur den aktuellen Zustand. Dies betrifft sowohl das Datenmodell als auch die Speicherarchitektur.

Anforderungen an Auditprotokolle ergeben sich unmittelbar aus dem regulatorischen Kontext. Jeder Schreibvorgang in den DPP-Datenspeicher sollte mit einem Zeitstempel, der Kennung des Quellsystems und — soweit zutreffend — einem Verweis auf die auslösende Lieferantenerklärung protokolliert werden. Dies ist erforderlich für Regulierungsprüfungen und für Produktrückrufe, bei denen die Rückverfolgbarkeit zu einer bestimmten Charge oder einem bestimmten Lieferanten entscheidend ist.

Datenqualitätssicherung ist die letzte Governance-Schicht. Eingehende Daten aus Quellsystemen sollten validiert werden, bevor sie in den DPP-Datensatz aufgenommen werden. Schema-Validierung, Plausibilitätsprüfungen und die Durchsetzung von Pflichtfeldern reduzieren Folgefehler und verhindern, dass Compliance-Lücken in den veröffentlichten Pass einfliessen.

Häufige Integrationsfehler und wie man sie vermeidet

DPP-Integrationsprojekte, die in Verzögerungen geraten, weisen typischerweise wiederkehrende Muster auf.

Den DPP als statischen Bericht zu modellieren ist eine der folgenreichsten frühen Fehlentscheidungen. Ein DPP ist ein lebendiger Datensatz: Er ändert sich, wenn Produktionschargen angelegt werden, wenn Lieferantenerklärungen erneuert werden und wenn das Produkt die Logistikkette durchläuft. Wer ihn als einmaligen Datenexport behandelt, schafft einen Pflegeaufwand, der mit jedem regulatorischen Update zunimmt.

Ein zweites häufiges Problem ist die Unterschätzung der Komplexität von Lieferantendaten. Strukturierter API-basierter Lieferantendatenaustausch ist der Zielzustand, doch die meisten Lieferanten-Ökosysteme sind noch nicht so weit — insbesondere mittelständische und kleinere Lieferanten. Ein realistischer Integrationsplan berücksichtigt eine Übergangsphase mit halb-strukturierten oder manuell erfassten Daten und definiert einen klaren Migrationspfad hin zum strukturierten Austausch, wenn die Fähigkeiten der Lieferanten reifen.

Punkt-zu-Punkt-Integrationen zwischen jedem Quellsystem und der DPP-Plattform erzeugen eine fragile Architektur. Wenn ein ERP-System aktualisiert wird oder ein PLM-Anbieter einen API-Vertrag ändert, ist jede Direktverbindung separat anzupassen. Eine zentrale Integrationsschicht oder ein Event Broker fungiert als stabiler Vermittler und isoliert die DPP-Plattform von Änderungen in einzelnen Quellsystemen.

Das Governance-Design auf die Zeit nach Abschluss der technischen Integration zu verschieben, führt zuverlässig zu Dateneigentumskonflikten und Audit-Problemen. Diese Entscheidungen müssen in der Architekturphase getroffen werden, wo sie in das Integrationsdesign einfliessen können — nicht erst während Compliance-Tests entdeckt werden.

Wie Mimacom helfen kann

Der Aufbau einer DPP-Integrationsplattform erfordert Expertise in den Bereichen Unternehmensintegration, Datenarchitektur und regulatorische Compliance. Mimacom entwirft und implementiert Integrationsarchitekturen für DPP und supply chain Compliance-Programme — für Unternehmen aus den Bereichen Fertigung, Automobil, Chemie und Konsumgüter.

Als zertifizierter Confluent-Partner verfügt Mimacom über umfangreiche Erfahrung mit event-driven Integration auf Basis von Apache Kafka und Confluent Platform — eine Lösung, die sich besonders gut für DPP-Szenarien eignet, die eine nahezu echtzeitfähige Datensynchronisierung über mehrere Quellsysteme hinweg erfordern. Unsere Berater decken den gesamten Integrations-Stack ab: ERP-Konnektoren, PLM-API-Integration, Lieferanten-Onboarding-Workflows und DPP-Datenplattform-Design. Ob Sie Ihre Architektur erst konzipieren oder ein bestehendes Programm beschleunigen möchten — wir helfen Ihnen, eine Plattform aufzubauen, die den Compliance-Anforderungen gerecht wird und Produktdaten über den gesamten Lebenszyklus hinweg pflegt.

FAQs

Kann unser bestehendes ERP-System als DPP-Datenspeicher dienen?

Ein ERP ist ein Quellsystem für DPP-Daten, keine DPP-Plattform. ERP-Systeme verwalten operative und finanzielle Daten, sind aber nicht darauf ausgelegt, Produktdaten in den von DPP-Regulierungen geforderten Formaten an externe Empfänger bereitzustellen. Eine dedizierte DPP-Datenplattform, die vom ERP und anderen Quellsystemen gespeist wird, ist die geeignete Architektur. Das ERP bleibt das System of Record für Produktions- und Chargendaten; die DPP-Plattform aggregiert und stellt diese im erforderlichen regulatorischen Format bereit.

Wie lange dauert ein DPP-Integrationsprojekt in der Regel?

Der Zeitrahmen hängt von der Anzahl der Quellsysteme, der Datenkomplexität sowie der Reife vorhandener APIs und der Integrationsinfrastruktur ab. Ein fokussiertes Projekt, das ERP, PLM und ein Lieferantenportal an eine DPP-Plattform anbindet, dauert typischerweise vier bis acht Monate — vom Architekturdesign bis zur Inbetriebnahme. Unternehmen mit fragmentierten Datenlandschaften, Legacy-Quellsystemen oder ohne bestehende Integrations-Middleware sollten einen längeren Zeitrahmen und einen iterativen Lieferansatz einplanen.

Was passiert, wenn ein Lieferant keine strukturierten Daten liefern kann?

Das ist häufig der Fall — insbesondere bei kleineren Lieferanten oder solchen ohne digitale Integrationsmöglichkeiten. Der pragmatische Ansatz besteht darin, ein Lieferantendatenportal zu entwickeln, das manuelle Einreichungen über ein strukturiertes Webformular akzeptiert, mit Validierungsregeln, die direkt bei der Erfassung greifen. Das Portal erzeugt einen strukturierten Datensatz, der in dieselbe Integrationspipeline wie API-basierte Einreichungen einfliesst — und so Konsistenz im DPP-Datenspeicher sicherstellt. Ziel ist es, den manuellen Aufwand zu reduzieren und gleichzeitig einen realistischen Einstieg für Lieferanten auf unterschiedlichen Stufen der digitalen Reife zu schaffen.