Das zentrale EU-DPP-Register läuft seit dem 19. Juli 2026. Hersteller in regulierten Kategorien mappen gerade ihre Produktdaten auf ESPR-Felder, wählen eine Plattform und bereiten sich auf die Batteriepass-Pflicht ab Februar 2027 vor. Diese Arbeit ist notwendig. Der eigentliche Punkt ist sie trotzdem nicht.

Ein neuer Report von Forrester, "The Digital Product Passport Is A Bridge To Your Customer" von Analyst Paul Miller, bringt einen Gedanken auf den Tisch, den Sie sich vor dem finalen DPP-Setup anschauen sollten: Ein Produktpass kann ESPR-konform sein und trotzdem an genau der Sache scheitern, wegen der es sich lohnt, ihn überhaupt zu bauen.

Was der Report wirklich sagt

Miller nennt fünf Anwendungsfälle für einen digitalen Produktpass, die über Nachhaltigkeits-Compliance hinausgehen: Lieferkettendaten wiederverwenden statt doppelt erfassen, eine verlässliche Quelle für Produktinformationen schaffen, Rückverfolgbarkeit entlang der Wertschöpfungskette verbessern, Kaufentscheidungen erleichtern und regionale Kreislaufwirtschafts-Ziele unterstützen.

Er beschreibt außerdem, was ein Produktpass technisch braucht: eine eindeutige Kennung auf Artikel- oder Chargenebene, einen maschinenlesbaren Zugangspunkt (in der Praxis fast immer ein QR-Code), ein verlässliches Register, klar definierte Pflicht- und optionale Datenfelder, und eine Governance, die die Daten dauerhaft korrekt hält. Dann folgt eine Anforderung, die die meisten Teams überspringen: Zugang und Darstellung müssen sich danach richten, wer gerade scannt.

Als Beispiel nennt er Volvos EX90, dessen Batteriepass bereits seit 2024 live läuft, deutlich vor der regulatorischen Frist.

Woran die meisten DPP-Projekte scheitern

Millers Kernkritik ist unverblümt: Die meisten DPP-Demos scheitern nicht an fehlenden Daten, sondern daran, dass sie jedes verfügbare Feld aus jedem angebundenen System ziehen, anstatt zu fragen, was die scannende Person tatsächlich braucht.

Schauen Sie sich an, wer einen ESPR-Produktpass in der Praxis scannt. Ein Auditor prüft Konformität und braucht Zertifikate und Prüfberichte. Eine Kundin im Laden will wissen, woraus das Produkt besteht und wie sie es pflegt, kein Datenschema. Ein Recycler braucht Demontage-Informationen und Materialanteile. Und wenn Ihr Produkt Service oder Reparatur beinhaltet, braucht der Techniker Ersatzteile und Service-Historie, keinen Nachhaltigkeitswert.

Zeigen Sie all das allen, und der Pass ist technisch konform und praktisch nutzlos. Niemand scannt einen QR-Code, bekommt eine Wand aus Feldern, die er nicht braucht, und kommt für einen zweiten Blick zurück.

Warum das unter ESPR noch mehr zählt, nicht weniger

Man könnte das als nettes Extra oben auf die Compliance lesen. Ist es nicht. ESPR selbst geht schon von unterschiedlichen Datenebenen aus: Die Verordnung trennt Pflicht- von optionalen Feldern und verlangt Governance für die Datenqualität, genau die Punkte, die Miller als Anforderungen an einen Produktpass nennt. Allein für Textilien umfasst die aktuelle Spezifikation 49 Datenpunkte über vier Kategorien, und nicht jeder davon gehört auf denselben Bildschirm.

Ein Produktpass, der als eine lange Datentabelle gebaut ist, erfüllt den Buchstaben der Verordnung und verfehlt genau das, wofür das EU-Register live gegangen ist: eine echte Verbindung zwischen Ihren Produkten, den Menschen, die im Laufe ihres Lebenszyklus damit zu tun haben, und den Compliance-Daten dahinter.

Den wirtschaftlichen Fall, das richtig zu machen, haben wir an anderer Stelle bereits ausführlich behandelt: wie ein DPP vom Compliance-Projekt zum Wettbewerbsvorteil wird, und wie Hersteller QR-Scans schon heute in Umsatz verwandeln. Forrester liefert dazu eine unabhängige Bestätigung: Das zugrunde liegende Design-Prinzip, Darstellung nach Rolle statt nach verfügbarem Datenfeld, ist keine Meinung von dpp.cloud. Es ist da, wo auch die Analystenwelt gerade ankommt.

Gebaut für die, die tatsächlich scannen

Genau deshalb baut dpp.cloud Produktpässe auf einer Identität pro Gerät auf, nicht nur auf einem Datensatz pro Produkt. Ein Pass auf Produktebene kann sagen, woraus ein Material besteht. Er kann einem Techniker nicht sagen, welches konkrete Gerät er gerade in der Hand hält, was daran schon ausgetauscht wurde, oder wie seine individuelle Service-Historie aussieht. Rollenbasierte Darstellung braucht diese Granularität als Fundament, sonst gibt es nichts, das man unterschiedlich zeigen könnte.

Diese Architektur ist für uns nicht neu. Es ist dieselbe Grundlage, die sqanit, das Unternehmen hinter dpp.cloud, bereits in regulierten MedTech-Deployments betreibt, wo ein einzelnes gescanntes Gerät einem Servicetechniker etwas anderes zeigen muss als der Person, die es benutzt. Überträgt man das auf ESPR-getriebene Hersteller in Textilien und Elektronik, heißt das: Ihre Compliance-Daten und Ihre kundenseitigen Daten leben auf demselben Pass, ohne sich um denselben Bildschirm zu streiten.

Für einen Hersteller in Textilien oder Elektronik könnte das konkret so aussehen: ein einziger QR-Code öffnet eine Compliance-Ansicht für den Auditor, eine Material- und Pflegeansicht für die Käuferin, und eine Demontage-Ansicht für den Recycler, alles aus einem Produktdatensatz, einmal aus dem bestehenden PIM gemappt.

Was Sie vor dem Go-live klären sollten

Bevor Sie Ihre Feld-Mappings final machen und Ihren ESPR-Pass als fertig abhaken, beantworten Sie eine Frage: Wer scannt das, und was braucht jede dieser Personen wirklich zu sehen? Wenn die ehrliche Antwort "alle sehen alles" lautet, haben Sie ein Compliance-Dokument gebaut, nicht die Brücke zum Kunden, die Forrester beschreibt.

Wenn Sie einen zweiten Blick auf Ihr konkretes Setup wollen, ist eine 30-minütige Strategy Session der schnellste Weg dahin. Wir schauen uns Ihre Produktdaten, Ihre regulierten Kategorien und die tatsächlich scannenden Rollen an und sagen Ihnen, wie ein rollenbasierter Rollout für Ihren Katalog aussieht.

Strategy Session buchen