PPWR als Softwareprojekt

Warum die EU-Verpackungsverordnung vor allem eine Frage des Datenmodells ist — und PDF, Oberfläche und API nur das sind, was am Ende dabei herauskommt.

Ein Thema wie die EU-Verpackungsverordnung (PPWR) ließe sich bei der Oberfläche beginnen: ein Formular, ein Export, ein Knopf, der ein PDF erzeugt. Dieser Ansatz greift zu kurz, denn das Eigentliche liegt darunter. Eine Verpackung ist nicht ein Produktname plus ein Dokument, sondern besteht aus Komponenten, Materialien mit Anteilen, Gewichten, Rezyklat und oft mehrschichtigen Verbundaufbauten — dazu Dokumente in verschiedenen Versions- und Freigabeständen.

Bildet man diese Wirklichkeit einmal sauber ab, ordnet sich der Rest fast von selbst. Das Datenmodell ist das Fundament; Oberfläche, PDF und Schnittstellen sind nur unterschiedliche Sichten darauf. Die eigentliche Arbeit steckt darin, dass die einfache Verpackung einfach bleibt und der komplizierte Verbund trotzdem vollständig abgedeckt ist — ohne dass die Bedienung darunter leidet.

Das PDF ist nur eine Ausgabe

Eine Konformitätserklärung als PDF zu erzeugen, ist der einfache Teil. Die spannende Frage liegt dahinter: Welche Daten haben zu genau dieser Version geführt — und lässt sich das noch beantworten, wenn längst eine Komponente ausgetauscht wurde? Ein PDF aus einem überschriebenen Datensatz kann darauf keine ehrliche Antwort geben.

Am Anfang steht deshalb nicht die Dokumentvorlage, sondern das Modell: Produkt und Verpackung, ihre Komponenten, deren Materialien und Anteile, dazu Zustände und die Zuordnung, welches Dokument aus welchem Datenstand entstanden ist. Steht das, wird das PDF zur Ableitung statt zur Fehlerquelle. Wie sich das für PPWR ausbuchstabiert, zeigen die Seiten zur Konformitätserklärung und zur technischen Dokumentation.

Eine Verpackung ist mehr als eine Zeile

In PakPruvo ist eine Verpackung deshalb kein einzelner Eintrag, sondern eine Struktur aus Bestandteilen. Jeder Bestandteil trägt seine eigenen Eigenschaften — Gewicht, eine Materialzusammensetzung aus mehreren Anteilen, Rezyklat, mehrschichtige Verbunde. Das ist keine Kosmetik, sondern die eigentliche Fachlichkeit: Genau diese Zusammenhänge muss man später auswerten, prüfen und belegen können.

Der Anspruch dabei ist, beide Enden gleichzeitig zu bedienen. Die simple Einweg-Verpackung soll sich in wenigen Feldern erfassen lassen, der mehrschichtige Verbund mit vielen Komponenten aber genauso sauber im selben Modell Platz finden. Aus einer scheinbar einfachen Produktinformation wird so ein zusammenhängendes Modell, das die reale Verpackung abbildet, statt sie in Freitextfeldern zu verstecken. Wie diese Daten erfasst und strukturiert werden, steht unter PPWR-Verpackungsdaten.

Ändern heißt nicht überschreiben

Ein reines „Datensatz speichern“ verliert Geschichte, und bei Nachweisen ist das ein echtes Problem: Ändern sich Material, Gewicht oder eine ganze Komponente, muss der frühere Stand rekonstruierbar bleiben, denn eine bereits ausgegebene Erklärung bezieht sich auf die Daten von damals, nicht auf die von heute.

Das Modell muss Änderungen deshalb als neue Stände führen statt als Überschreiben. In PakPruvo hängen Verpackungsdaten und Dokumente an einer gemeinsamen Historie — nachvollziehbar von der technischen Dokumentation bis zur ausgegebenen Konformitätserklärung. Nach außen bleibt es dabei bewusst schlicht: Wer heute etwas ändert, arbeitet einfach weiter; die Nachvollziehbarkeit entsteht darunter, ohne dass man sie im Alltag verwalten muss.

Die API gehört zum Modell, nicht obendrauf

Produkt- und Verpackungsdaten liegen meist längst irgendwo — im ERP, im PIM, in gewachsenen Fachsystemen. Eine Anwendung, die dieselben Stammdaten ein zweites Mal pflegen lässt, schafft nur ein weiteres Silo und die nächste Quelle für Widersprüche.

Ist das Datenmodell sauber definiert, ist eine Schnittstelle keine nachträgliche Zusatzfunktion, sondern fällt fast von selbst an — sie legt dieselbe Struktur nur maschinell offen. PakPruvo stellt dafür eine REST-API bereit, über die die Anwendung Teil einer bestehenden Systemlandschaft wird, statt neben ihr zu stehen.

Für Menschen lesbar, für Maschinen eindeutig

Dieselben Daten müssen zwei Publika bedienen: Menschen wollen eine verständliche Oberfläche, Maschinen — Suchsysteme, andere Systeme und zunehmend KI-Agenten — brauchen klar strukturierte, eindeutig benannte Daten. Beides speist sich aus demselben Modell, wenn dieses von Anfang an ordentlich ist; die eine Anforderung muss nicht auf Kosten der anderen gehen.

Ein sauberes Datenmodell trägt so weiter als die aktuelle Ansicht. Aus denselben Stammdaten entsteht sowohl eine QR-Produktseite für Menschen als auch eine maschinenlesbare Schnittstelle — ohne die Daten doppelt zu denken.

Fazit

Kurzfristig lässt sich die PPWR mit Tabellen und Dokumentvorlagen erschlagen. Sobald Daten aber zusammenhängen, sich ändern und nachvollziehbar bleiben müssen, ist es keine Formularaufgabe mehr, sondern eine Frage der Modellierung. PakPruvo ist entlang dieser Idee gebaut: erst das Modell für Verpackungsdaten, Versionen und Dokumente, das den einfachen wie den komplizierten Fall trägt — Oberfläche, PDF und API ergeben sich daraus.