Model, Batch und Item: Die richtige DPP-Granularität

Model, Batch und Item beschreiben unterschiedliche Ebenen, auf denen Produktdaten und Digitale Produktpässe organisiert werden können. Die Entscheidung wirkt sich direkt auf Kennungen, Datenvolumen, Aktualisierungen und den späteren QR-Code aus. Den übergeordneten Rahmen beschreibt der Beitrag Digitaler Produktpass: Definition, Anforderungen und Umsetzung.

Zu grob modelliert, fehlen individuelle Informationen. Zu fein modelliert, werden identische Stammdaten millionenfach kopiert und schwer wartbar. Eine gute DPP-Architektur verbindet deshalb gemeinsame und individuelle Daten, ohne ihre Gültigkeit zu verwischen.

Was bedeutet Granularität beim DPP?

Die ESPR sieht ausdrücklich vor, dass in produktgruppenspezifischen Anforderungen angegeben wird, ob ein DPP auf Modell-, Chargen- oder Artikelebene zu erstellen ist. Es handelt sich daher nicht nur um eine technische Präferenz.

Model: gemeinsame Eigenschaften

Die Modellebene beschreibt Eigenschaften, die für eine definierte Produktversion gemeinsam gelten. Dazu können Design, Materialzusammensetzung, technische Dokumentation oder allgemeine Reparaturinformationen gehören.

Vorteile der Modellebene:

• gemeinsame Daten werden nur einmal gepflegt,
• Nachweise können einer definierten Modellversion zugeordnet werden,
• Änderungen lassen sich kontrolliert auf betroffene Produkte beziehen,
• Datenvolumen und Pflegeaufwand bleiben beherrschbar.

Die Herausforderung: Nicht jede reale Einheit hat automatisch denselben Zustand oder dieselbe Produktionshistorie. Dafür braucht es feinere Ebenen.

Batch: Daten einer Charge

Eine Charge verbindet Produkte, die unter gemeinsamen Produktions- oder Materialbedingungen entstanden sind. Chargendaten können beispielsweise Lieferlose, Produktionszeitfenster, Prüfergebnisse oder materialbezogene Nachweise abbilden.

Die Batch-Ebene ist sinnvoll, wenn Informationen genauer als das Modell, aber nicht für jedes Einzelstück unterschiedlich sind. Sie darf jedoch nicht als Sammelbecken dienen, nur weil individuelle Identifikation organisatorisch aufwendiger ist.

Item: das einzelne Produkt

Die Item-Ebene identifiziert ein individuelles physisches Produkt. Sie ist erforderlich, wenn Informationen oder Ereignisse genau diesem Objekt zugeordnet werden müssen. Beim Batteriepass verbindet Artikel 77 Informationen zum Batteriemodell mit spezifischen Informationen zur einzelnen Batterie.

Individuelle Daten können umfassen:

• eindeutige Produkt- oder Serienkennung
• Produktions- oder Inverkehrbringungsbezug
• Zustands- und Nutzungsinformationen
• Reparatur, Austausch oder Eigentumsereignisse, soweit vorgesehen
• Statusänderungen oder aktualisierte Lifecycle-Informationen

Vergleich der Ebenen

Ebene	Typische Reichweite	Geeignete Daten	Zentrale Herausforderung
Model	Produktdesign oder Modellversion	gemeinsame Stammdaten und Dokumentation	Gültigkeit bei Modelländerungen
Batch	Produktions- oder Liefercharge	gemeinsame Herkunfts- und Prüfdaten	saubere Chargenabgrenzung
Item	einzelnes physisches Produkt	Identität, Zustand und individuelle Ereignisse	skalierbare Kennung und Datenmenge
Lifecycle	zeitbezogene Ergänzungen zum Item	Nutzung, Reparatur, Wiederverwendung	Quelle, Zeit und Berechtigung

Wie funktioniert Datenvererbung?

Ein Item kann auf eine Charge und ein Modell verweisen. Die veröffentlichte Ansicht führt die passenden Informationen zusammen. Intern sollte das System aber wissen, aus welcher Ebene jeder Wert stammt.

Beispiel:

1. Das Modell definiert Nennwerte und allgemeine Dokumentation.
2. Die Charge ergänzt Produktionszeitraum und chargenbezogene Nachweise.
3. Das Item trägt Serienkennung und individuellen Status.
4. Lifecycle-Ereignisse ergänzen spätere Änderungen.

Wird eine neue Modellversion veröffentlicht, darf sie historische Items nicht stillschweigend umdeuten. Deshalb braucht jede Beziehung Gültigkeit und Version.

Kennungen pro Ebene

Kennungen müssen zur Granularität passen. Eine Modellkennung darf nicht so verwendet werden, als identifiziere sie ein einzelnes Produkt. Ebenso sollte eine individuelle Kennung nicht bei mehreren Items wiederverwendet werden.

Ein gutes Identifikationskonzept dokumentiert:

• welche Ebene eine Kennung bezeichnet,
• wer sie vergibt und verwaltet,
• ob sie dauerhaft oder versioniert ist,
• wie sie über offene Kennungsstandards in Datenträger und URL aufgelöst wird,
• wie Dubletten und Fehler behandelt werden,
• was bei Ersatz, Rücknahme oder Zusammenführung passiert.

So wählen Sie die richtige DPP-Ebene

Die Entscheidung sollte gemeinsam von Compliance, Produktmanagement, IT und Produktion getroffen werden. Eine rein regulatorische Sicht kann operative Kennungsprobleme übersehen; eine rein technische Sicht kann den geforderten Produktkontext verfehlen.

Typische Fehler im Datenmodell

Eine Produktseite für alle Varianten

Wenn unterschiedliche Modellversionen, Materialien oder Produktionsstände auf eine gemeinsame Seite zeigen, ist unklar, welche Information für das gescannte Produkt gilt.

Vollständige Kopie je Einzelprodukt

Millionen identische Kopien erhöhen Speicherbedarf und Änderungsrisiko. Besser ist eine versionierte Referenz, ergänzt um individuelle Werte.

Keine historische Gültigkeit

Ein aktuelles Modelldokument ersetzt rückwirkend den Stand, der bei einer früheren Veröffentlichung galt. Damit geht Nachvollziehbarkeit verloren.

Kennung und technische URL werden verwechselt

Bei einem Plattformwechsel ändert sich die Route und damit vermeintlich die Produktidentität. Eine getrennte Resolver- und Kennungslogik verhindert das.

Fazit

Model, Batch und Item sind das Rückgrat eines skalierbaren DPP-Datenmodells. Die richtige Ebene folgt dem anwendbaren Produktkontext und den tatsächlichen Datenunterschieden. Versionierte Vererbung verbindet gemeinsame Informationen mit individuellen Ereignissen – ohne Millionen widersprüchlicher Kopien. Wie DPPdesk diese Ebenen abbildet, zeigt die Produktseite.