Digitaler Produktpass aus SAP-Daten: Add-on-Projekt oder API-Connector?

Liegen Ihre Produktdaten in SAP, führen zwei realistische Wege zum Digitalen Produktpass: ein SAP-natives Add-on-Projekt oder ein leichtgewichtiger Connector, der Ihre bestehenden Stammdaten über die API liest und Pässe außerhalb des ERP erzeugt. Der erste Weg ist ein IT-Projekt von zwölf Monaten aufwärts. Der zweite dauert Wochen. Dieser Artikel zeigt, wo DPP-relevante Daten in einer typischen SAP-Landschaft liegen, wie beide Wege funktionieren und wie Sie sich entscheiden.

Die gute Nachricht: Die Daten sind schon in SAP

Die ESPR (Verordnung (EU) 2024/1781) verpflichtet Hersteller, definierte Produktdaten öffentlich bereitzustellen, Kategorie für Kategorie, sobald die delegierten Rechtsakte kommen. Legen Sie die Anforderungen eines Passes neben ein gewachsenes SAP-System:

DPP-DatenblockWo er in SAP üblicherweise liegt
Produktidentifikation, GTINMaterialstamm (MARA), EAN/UPC-Felder
MaterialzusammensetzungKlassifizierung, Stücklisten, EHS-Stoffdaten
Abmessungen, GewichtMaterialstamm-Grunddaten
Zertifikate, ErklärungenDokumentenverwaltung (DMS)
Lieferanten- und HerkunftsdatenEinkaufsinfosätze, Lieferantenstamm
Pflege-, Nutzungs-, ReparaturdokumentationDMS oder angebundenes PIM/Commerce-System

Die Daten existieren. Die Frage ist nur, wie daraus ein öffentlicher, standardkonformer, im Register gemeldeter Pass wird. Das zentrale DPP-Register der EU ist seit dem 19. Juli 2026 live, das „Wie" hat also eine konkrete technische Bedeutung.

Weg 1: die SAP-native Route

SAPs Nachhaltigkeits-Portfolio wächst, und Systemintegratoren bieten DPP-Add-ons innerhalb des SAP-Stacks an. Der Vorteil ist architektonische Reinheit: Alles bleibt in der Welt eines Anbieters. Die Nachteile sind die klassischen. Das sind IT-Projekte mit Scoping, Lizenzierung, Customizing und Release-Abhängigkeiten. Budgets beginnen sechsstellig, Zeitpläne bei etwa einem Jahr, und jeder delegierte Rechtsakt, der Datenanforderungen ändert, wird zum Change Request.

Für einen Konzern mit großem SAP Center of Excellence und DPP-Volumen in Millionenhöhe kann dieser Weg richtig sein. Für einen Mittelständler mit Compliance-Deadline und ohne freie IT-Kapazität ist er es selten.

Weg 2: die Connector-Route

Die Alternative behandelt SAP als das, was es ist, das führende System, und lässt es unangetastet. Ein Connector liest Produktdaten über SAP-Standardschnittstellen (OData-Services bei S/4HANA, BAPIs oder IDocs bei älteren ECC-Systemen), überträgt sie ins DPP-Schema, validiert sie und erzeugt QR-codierte Pässe auf einer Plattform, die genau dafür gebaut ist. Das Muster ist dasselbe wie bei PIM-Systemen, beschrieben in DPP erstellen aus PIM-Daten:

  1. Sync: Materialstamm-Änderungen fließen per OData-Abfrage oder ereignisbasiert zum Connector
  2. Mapping: Eine Konfiguration ordnet SAP-Felder und Klassifizierungsmerkmale den DPP-Feldern zu
  3. Validierung: Produkte mit fehlenden Pflichtfeldern landen auf einer Arbeitsliste, die Ihr Team abarbeitet
  4. QR und Rückschreiben: Die Pass-URL kann in ein Materialstamm-Feld zurückgeschrieben oder an Ihr Etiketten-Management übergeben werden

Kein SAP-Customizing, keine Transportaufträge, keine Release-Abhängigkeit. Ihr SAP-Team stellt API-Zugänge bereit und sitzt in einem Mapping-Workshop, das war seine Beteiligung.

Der ehrliche Vergleich

SAP-natives Add-onAPI-Connector (dpp.cloud)
Zeitplan12+ Monate3 bis 5 Wochen
KostenstrukturLizenz + Integrationsprojekt, typischerweise sechsstellig10.500 bis 17.500 Euro pro Jahr, fest
Beteiligung des SAP-TeamsLaufendAPI-Zugang + ein Workshop
Regulatorische UpdatesChange RequestsEnthalten, Mapping ist Konfiguration
Pässe auf Einzelstück-EbeneJe nach Add-onEingebaut, jede Einheit kann eine eigene Identität tragen
Service-Layer auf dem PassUnüblichChat, Ticketing, Ersatzteile, Anleitungen enthalten

Eine Nuance der Fairness halber: SAP-Landschaften streuen stärker als PIM-Systeme. Ein sauberes S/4HANA mit disziplinierter Klassifizierung ist in Tagen gemappt. Ein zwanzig Jahre altes ECC mit kundeneigenen Z-Feldern braucht erst eine Discovery-Phase. Deshalb rechnen wir bei SAP-Projekten mit drei bis fünf Wochen statt der zwei bis drei bei Akeneo. Den Vergleich über alle Plattformtypen, inklusive Beratungsroute, finden Sie im DPP-Software-Kaufratgeber.

Wie Sie sich entscheiden

Stellen Sie zwei Fragen. Erstens: Lässt Ihre Kategorie-Timeline Raum für ein Jahresprojekt? Prüfen Sie die DPP-Timeline, und denken Sie daran, dass Datenbereinigung den Puffer schneller frisst als geplant. Zweitens: Soll der Pass mehr können als Compliance? Wenn QR-Codes Anleitungen, Serviceanfragen oder Ersatzteilbestellungen tragen sollen, wollen Sie eine Plattform, auf der diese Schicht existiert, statt eines Compliance-Add-ons, in dem sie erst gebaut werden müsste.

Der nächste Schritt

Buchen Sie eine 30-minütige Strategy Session und bringen Sie jemanden mit, der Ihre SAP-Landschaft kennt. Wir sagen Ihnen noch im Call, ob Ihr Setup ein Drei-Wochen-Fall ist oder eine Discovery-Phase braucht, und was beides kostet.

Strategy Session buchen

FAQ

Wo liegen DPP-relevante Daten in SAP?

Braucht der Connector SAP-Customizing?

Wie lange dauert eine SAP-DPP-Integration?

Was kostet die SAP-native Add-on-Route?

Können Pässe pro Einheit statt pro Material erzeugt werden?

Related Posts