Das Gewicht eines Produkts steht in der Materialwirtschaft. Der Rezyklatanteil steht im Rezeptursystem. Das Zertifikat des Zulieferers liegt als PDF auf einem Netzlaufwerk. Der Produktpass braucht alle drei Angaben in einem einzigen Datensatz, und genau darin steckt das Integrationsprojekt, nicht in der Verbindung zweier Systeme.
«Nahtlose ERP-Integration» ist ein Standard-Versprechen, nach dem in der Praxis ein Drei-Monats-Projekt folgt. Wir veröffentlichen unseren Leitfaden, damit Ihre IT vor Vertragsunterzeichnung prüfen kann, was tatsächlich abgefragt wird. Dieser Artikel zeigt, welche Daten der Pass aus Ihren Systemen braucht, auf welchen drei Wegen sie zu uns kommen und warum das in zwei Wochen geht.
Was Ihr ERP eigentlich liefern muss
Damit ein DPP entsteht, brauchen wir pro Produkt:
- Stammdaten - Artikelnummer, Bezeichnung, Varianten, Gewichte, Masse, Bilder
- Stücklistendaten - Komponenten mit Mengen und Rezyklatanteilen
- Herkunftsdaten - Produktionsort, Chargennummer, Produktionsdatum
- Umweltdaten - CO2eq pro Einheit, Wasserverbrauch, Energieverbrauch
- Lieferantendaten - Wer liefert welche Komponente (für die Sorgfaltspflichten)
In Ihrem ERP sind diese Daten theoretisch alle vorhanden. Praktisch sind sie in 4 bis 7 Modulen verteilt: Materialwirtschaft, Produktion, Qualität, Lieferantenstamm, manchmal ein separates Modul für Umweltdaten, manchmal ein eigenes System für Rezepturen und Stücklisten.
Die Integrationsfrage ist nicht: «Liefert Ihr ERP Daten an einen DPP?» Sie ist: «Wie bringen Sie die Daten aus 5 Subsystemen zu einem zusammenhängenden Datensatz?»
Drei bewährte Wege
Weg 1: Die Daten aus dem ERP abholen
Funktioniert gut mit modernen ERPs (SAP S/4HANA Cloud, Dynamics 365, Odoo). Der DPP-Anbieter holt die Daten über die Schnittstelle des ERP ab (technisch OData oder REST). Nur die Änderungen, nach Zeitplan oder ausgelöst durch ein Ereignis.
Vorteile: wenig Entwicklung Ihrerseits, Sie stellen einen Lesezugang, der Anbieter baut die Umwandlung.
Nachteile: funktioniert nicht mit älteren SAP-ECC-Installationen ohne zusätzliche Schnittstellenschicht. Sie brauchen klare Regeln, wer welche Daten lesen darf.
Weg 2: Änderungen weiterleiten
Ihr ERP meldet jede Änderung als Ereignis (über SAP Event Mesh, Apache Kafka oder RabbitMQ), der DPP-Anbieter nimmt sie entgegen.
Vorteile: nahezu in Echtzeit, wächst mit, die Systeme hängen nicht voneinander ab.
Nachteile: Die Einrichtung ist anspruchsvoll und braucht Infrastruktur, die nicht jede IT-Abteilung hat. Für kleinere Firmen meist übertrieben.
Weg 3: Die vorhandene Integrationsschicht nutzen
Sie haben bereits eine Integrationsschicht (Mulesoft, Boomi, Informatica, Azure Data Factory) zwischen ERP und externen Systemen. Diese Schicht ist der Vertrag: Der DPP-Anbieter spricht mit ihr, nie direkt mit dem ERP.
Vorteile: bestehende Investitionen sind nutzbar, die Regeln bleiben stabil, kein direkter ERP-Zugriff für Dritte.
Nachteile: Ihre Kosten für die Integrationsschicht wachsen mit.
Was wir in konkreten Projekten anders machen
Viele Anbieter wollen sich direkt mit Ihrem ERP verbinden. Wir bauen grundsätzlich einen Zwischenschritt ein: Unsere Schnittstelle nimmt ein neutrales Datenformat (ein JSON-Schema) entgegen, das Sie mit einem Werkzeug Ihrer Wahl befüllen. Das heisst:
- Sie können die Daten-Aufbereitung selbst machen, mit den Werkzeugen, die Ihr Team kennt
- Sie können uns austauschen - das neutrale Format ist portabel
- Sie holen Ihren gesamten Bestand jederzeit wieder heraus - als CSV, XLSX, JSON-LD und SQL sowie über die REST-API
- Wir liefern einen Import-Validator, der Ihre Daten vor dem Upload prüft
Das vollständige Format und alle Abfragen sind unter /apidocs öffentlich dokumentiert, als Schnittstellenbeschreibung nach OpenAPI. Ihre IT kann die Schnittstelle prüfen, bevor ein Vertrag unterschrieben wird - inklusive Beispiel-Anfragen, Fehlerantworten und Authentifizierungsdetails.
Zeitrahmen mit diesem Ansatz in der Praxis:
- Tag 1 bis 2: Mapping-Workshop. Welches ERP-Feld wird welches DPP-Feld?
- Tag 3 bis 5: Erste JSON-Exports aus dem ERP, durch unseren Validator.
- Tag 6 bis 8: Fehlerbehebung (fehlende Felder, inkonsistente Codierungen).
- Tag 9 bis 10: Erste DPPs sind live.
Zwei Wochen, keine drei Monate. Der Knackpunkt ist der Mapping-Workshop - dort wird über Datenqualität entschieden.
Was schiefgeht: die häufigsten Fallen
Produktstammdaten in mehreren Systemen: SAP hat die Artikelnummer, PIM hat die Bilder und Marketingtexte, PLM hat die Stückliste. Niemand hat ein konsistentes Bild. Lösung: definieren Sie vor dem Projekt, welches System für welches Feld das führende ist.
Zertifikate als PDF: Zulieferer liefern GOTS-, OEKO-TEX- oder REACH-Zertifikate als PDF-Scan. Das ist keine strukturierte Datenquelle. Lösung: Zertifizierungsbetreiber bieten zunehmend eine Abfrage per Schnittstelle an (OEKO-TEX ist vorn, GOTS hinkt nach). Oder: manuell erfassen, aber mit Gültigkeitsdatum, damit keine abgelaufenen Zertifikate im DPP auftauchen.
Rezeptur-Geheimhaltung: besonders in Kosmetik, Lebensmitteln und Pharma: die vollständige Rezeptur ist Betriebsgeheimnis. Der DPP soll sie öffentlich machen? Lösung: Das Drei-Ebenen-Modell der ESPR. Öffentlich steht die Produktkategorie, Behörden sehen die vollständige Rezeptur. Fast nie ein Blocker, aber muss früh geklärt werden.
CO2-Daten auf Zulieferer-Basis: Ihr Zulieferer gibt einen Durchschnittswert für sein gesamtes Portfolio, nicht pro Charge. Lösung: zeitweise akzeptieren, langfristig Lieferantenverträge anpassen. Die ESPR fordert produktspezifische Werte ab einem Stichtag, aber die aktuelle Praxis ist ein Kompromiss.
Lokale Sprachversionen: Ihr ERP enthält nur die Produktbezeichnung in Deutsch und Englisch. Für 27 EU-Länder brauchen Sie mehr. Lösung: Maschinenübersetzung mit Terminologie-Datenbank, wir haben dazu einen separaten Artikel.
Die Fragen, die Sie vor dem Projekt stellen sollten
Bevor Sie ein RFP an drei Anbieter schicken, beantworten Sie intern:
- Wie viele Produkte/Artikelnummern sollen DPPs haben? (10, 10 000, 1 Million?)
- Welche Systeme halten heute DPP-relevante Daten?
- Welche Abteilung verwaltet jedes der Systeme?
- Haben Sie eine Integrationsschicht, die genutzt werden sollte?
- Gibt es eine bereits funktionierende Schnittstelle über Ihrem ERP?
Die Antworten bestimmen, welcher der drei Wege für Sie passt. Und sie legen fest, ob ein Projekt zwei Wochen oder sechs Monate dauert.
Fragen zu diesem Beitrag
Reicht die REST-Schnittstelle, oder brauchen wir eine Middleware?
Die Schnittstelle reicht. Die drei Muster unterscheiden sich darin, wo die Transformation stattfindet, nicht darin, was wir entgegennehmen - unsere Schnittstelle nimmt ein neutrales JSON-Schema an, gleich womit Sie es erzeugt haben. Ein Pull aus einem modernen ERP, ein Ereignisstrom und eine bestehende Integrationsschicht enden alle am selben Endpunkt. Eine Middleware lohnt sich, wenn Sie ohnehin eine betreiben und sie der Vertrag gegenüber Dritten bleiben soll. Existiert heute keine, kaufen Sie für den Produktpass keine.
Was wird im Mapping-Workshop entschieden?
Welches ERP-Feld welches Passfeld wird - und welches System die führende Quelle ist, wenn mehrere denselben Wert halten. Der Workshop liegt auf Tag 1 und 2 und ist der Knackpunkt des ganzen Projekts, weil dort über Datenqualität entschieden wird und nicht später im Code. Bringen Sie die Personen mit, die die Systeme pflegen, nicht nur die, die das Projekt verantworten - Stammdaten, Produktion, Qualität und Einkauf sitzen selten in einer Abteilung. Alles danach, also Exporte, Validierung und Fehlerbehebung, ist Handwerk.
Unsere Zertifikate liegen nur als PDF-Scan vor. Was machen wir damit?
Ein Scan ist keine strukturierte Datenquelle und für den Pass damit unbrauchbar. Zwei Wege funktionieren - Zertifizierungsbetreiber bieten zunehmend API-Abfragen an, und wo es keine gibt, erfassen Sie die Werte von Hand, aber immer mit Gültigkeitsdatum, damit kein abgelaufenes Zertifikat in einem veröffentlichten Pass stehen bleibt. Planen Sie den manuellen Weg als wiederkehrende Arbeit ein, nicht als einmalige Aufgabe.
Kann unsere IT die Schnittstelle prüfen, bevor wir etwas unterschreiben?
Ja. Das vollständige Schema und alle Endpunkte stehen als OpenAPI-Spezifikation unter /apidocs, mit Beispiel-Anfragen, Fehlerantworten und Authentifizierungsdetails. Nichts davon liegt hinter einem Vertriebsgespräch, Ihr Integrationsteam kann den Aufwand also abschätzen, bevor ein Vertrag existiert. Zeigt ein Anbieter seine Schnittstelle in dieser Phase nicht, ist auch das eine Antwort.
Was passiert mit unseren Daten, wenn wir den Anbieter wechseln?
Sie gehen mit. Die Schnittstelle nimmt ein neutrales JSON-Schema entgegen statt eines proprietären Formats, und Ihr gesamter Bestand kommt als CSV, XLSX, JSON-LD und SQL oder über die REST-API wieder heraus. Das ist Absicht - das Format, das Sie befüllen, ist portabel, ein Wechsel kostet also einen Export und keinen Neubau. Stellen Sie jedem Anbieter dieselbe Frage vor dem Mapping-Workshop, denn danach stehen Ihre Feldnamen in seinem Modell.
Wie lange dauert eine Anbindung wirklich?
In den Projekten, die wir begleiten, zwei Wochen - zwei Tage Mapping, drei Tage bis zu den ersten Exporten durch unseren Validator, drei Tage Fehlerbehebung, zwei Tage bis zu den ersten veröffentlichten Pässen. Der lange Weg ist nie der Code, sondern das, was der Validator findet - fehlende Felder, uneinheitliche Codierungen, Werte, für die sich niemand zuständig fühlt. Planen Sie diese Tage ein, statt sie zu kürzen. Ein Projekt, das sie überspringt, veröffentlicht die Lücken mit.
Müssen wir alle Produkte auf einmal anbinden?
Nein. Beginnen Sie mit den Produkten, die zuerst einen Pass brauchen, und mit einem Quellsystem - das neutrale Schema nimmt einen Teilkatalog genauso an wie einen vollständigen, und Importe sind wiederholbar, spätere Läufe aktualisieren den Bestand also. Das hält auch den Mapping-Workshop klein genug, um ihn in zwei Tagen zu schaffen. Die Ausweitung danach ist eine Mapping-Aufgabe, kein neues Projekt.
