DPP-Software auswählen: Datenmodell, API und Betrieb

Eine DPP-Software muss weit mehr leisten als eine Produktseite mit QR-Code. Sie verbindet Datenquellen, Produktidentität, regulatorische Einordnung, Nachweise, Rollen und Veröffentlichung – die Bausteine, die der Beitrag Digitaler Produktpass: Definition, Anforderungen und Umsetzung im Detail beschreibt. Für die Auswahl ist deshalb nicht die längste Featureliste entscheidend, sondern ob die Plattform im realen Betrieb nachvollziehbar bleibt.

Welche Kostenblöcke dabei entstehen, ordnet der Beitrag Was kostet ein Digitaler Produktpass? ein. Die beste Prüfung ist ein Pilot mit eigenen Daten. Er zeigt, ob ein System nur gut präsentiert oder tatsächlich importiert, bewertet, freigibt, veröffentlicht und wieder exportiert.

Was eine DPP-Plattform grundsätzlich leisten sollte

Eine belastbare Plattform deckt den Weg vom Rohdatum zum veröffentlichten Produktpass ab. Sie übernimmt nicht die fachliche Verantwortung für den Inhalt, macht diese Verantwortung aber sichtbar und handhabbar.

Die Kernbereiche sind:

1. Produkt- und Variantenmodell
2. Datenimport und Schnittstellen
3. Regel- und Anforderungsmanagement
4. Nachweise und Datenherkunft
5. Rollen, Freigaben und Zugriffsebenen
6. QR-Code und öffentliche Passansicht
7. Betrieb, Monitoring, Export und Backup

Kriterium 1: Mehrere Produktwelten statt Batterie-Silo

Der Batteriepass ist wegen seines konkreten Stichtags ein sinnvoller Startpunkt. Eine Plattform sollte dennoch nicht so gebaut sein, dass Textilien, Elektronik, Chemikalien, Möbel oder Stahl später ein komplett neues System erfordern.

Prüfen Sie, ob Produktgruppen eigene Datenmodelle und Regelpakete erhalten können, während gemeinsame Fähigkeiten – Identität, Rollen, Quellen, Versionierung und Veröffentlichung – wiederverwendet werden.

Kriterium 2: Model, Batch und Item

Die richtige Granularität beeinflusst Datenmenge, Kennungen und Prozesse. Manche Informationen gelten für ein Modell, andere für eine Charge oder einen einzelnen Artikel. Eine DPP-Software sollte diese Ebenen nicht nur als Textfeld führen, sondern Beziehungen und Vererbung kontrollieren.

Frage an den Anbieter	Gute Antwort erkennt man daran
Wie werden gemeinsame Modelldaten genutzt?	Daten werden referenziert und versioniert statt unkontrolliert kopiert
Wie entstehen Einzelpässe?	Kennungen und Item-Daten werden reproduzierbar erzeugt oder importiert
Was passiert bei Änderungen?	Gültigkeit und veröffentlichte Versionen bleiben nachvollziehbar
Lassen sich Ebenen kombinieren?	Modell, Charge, Artikel und Lifecycle sind fachlich verbunden

Kriterium 3: Regelwerk mit Quellen und Versionen

Ein DPP-System sollte nicht einfach behaupten, ein Produkt sei „EU-konform“. Es muss zeigen, gegen welchen Stand und mit welchem Produktkontext bewertet wurde – wie das für den ESPR-Rahmen aussieht, zeigt die Seite zu Standards und Compliance.

Wichtige Fähigkeiten:

• Quellenverweis pro Anforderung oder Regelpaket
• Gültigkeitszeitraum und Versionshistorie
• Bedingungen für Kategorie, Zeitpunkt und Produktmerkmal
• Status wie erforderlich, bedingt, später relevant oder nicht anwendbar
• Erklärung, warum eine Anforderung ausgelöst wurde
• Verknüpfung zu Datenfeld und Nachweis

Kriterium 4: APIs, Import und Export

Produktdaten entstehen nicht in der DPP-Maske. Sie kommen aus ERP, PLM, PIM, BMS, Lieferantenportalen, Tabellen und Dokumenten. Deshalb sind dokumentierte Schnittstellen ein Auswahlkriterium, kein späteres Zusatzmodul.

Fragen Sie konkret:

• Gibt es eine dokumentierte REST API?
• Können Strukturen über OpenAPI nachvollzogen werden?
• Welche CSV- oder XLSX-Prozesse existieren für Pilot und Migration?
• Wie werden Webhooks und Statusänderungen übertragen?
• Lassen sich Daten und Nachweise vollständig exportieren?
• Bleiben Kennungen und Referenzen beim Export erhalten?

Kriterium 5: Rollen und Freigaben

Nicht jede Person darf jeden Wert ändern oder veröffentlichen. Gute Systeme trennen Datenerfassung, fachliche Prüfung, regulatorische Bewertung und Veröffentlichung. Der Audit-Trail sollte zeigen, wer wann welchen Stand freigegeben hat.

Für externe Lieferanten oder Dienstleister sind begrenzte Arbeitsbereiche sinnvoll. Sie liefern Daten, erhalten aber nicht automatisch Zugriff auf das gesamte Produktportfolio oder geschützte Informationen.

Kriterium 6: Öffentliche Passansicht

Die öffentliche Ansicht muss mobil, schnell und verständlich sein. Gleichzeitig dürfen Gestaltung und Marketing nicht die strukturierte Datenebene ersetzen. Prüfen Sie QR-Code, Ladezeit, Sprachwechsel, Barrierefreiheit und Fehlerverhalten.

Ein DPP ist außerdem kein einmaliges Publishing-Projekt. Die Plattform sollte Entwurf, Prüfung, Veröffentlichung, Aktualisierung und gegebenenfalls Rücknahme als klaren Statusprozess abbilden.

Kriterium 7: Hosting, Sicherheit und Backup

Fragen zum Betrieb gehören vor die Vertragsentscheidung:

• Wo werden produktive Daten und Backups verarbeitet?
• Welche Rollen- und Sicherheitsmaßnahmen sind dokumentiert?
• Wie werden Ausfälle erkannt und kommuniziert?
• Welche Wiederherstellungsziele gelten?
• Kann ein unabhängiges Backup außerhalb des primären DPP-Anbieters geführt werden?
• Was passiert mit QR-Code-Zielen und Domains bei Vertragsende?

Anbieterbindung lässt sich nicht nur durch einen Datenexport vermeiden. Auch Resolver, Kennungen, Anhänge und veröffentlichte Ansichten müssen migrierbar sein.

Pilot statt Folienvergleich

Ein sinnvoller Pilot verwendet eine begrenzte, aber reale Produktmenge. Er beginnt mit Quellsystemen und endet beim Scan eines veröffentlichten Passes. Dabei sollten bewusst Datenlücken, Rollenwechsel und Aktualisierungen vorkommen.

Bewerten Sie anschließend nicht nur „funktioniert“ oder „funktioniert nicht“, sondern:

• Zeit bis zum ersten belastbaren Pass
• manueller Aufwand je Produkt oder Variante
• Transparenz von Fehlern und Anforderungen
• Qualität der Schnittstellen
• Verständlichkeit für Fachanwender
• Exportierbarkeit und Betriebskonzept

Fazit

Die Auswahl einer DPP-Software ist eine Architekturentscheidung. Entscheidend sind flexible Produktmodelle, ein erklärbares Regelwerk, offene Schnittstellen und kontrollierter Betrieb. Wer den vollständigen Prozess mit eigenen Daten testet, erkennt schnell den Unterschied zwischen einer Demo-Oberfläche und einer produktionsfähigen Plattform.