«Nahtlose ERP-Integration» ist ein Standard-Versprechen, nach dem in der Praxis ein Drei-Monats-Projekt folgt. Wir veröffentlichen unser API-Playbook, damit Ihre IT vor Vertragsunterzeichnung prüfen kann, was tatsächlich abgefragt wird. Hier ist, was Sie vor einem Integrationsprojekt wissen sollten.
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 Due Diligence)
In Ihrem ERP sind diese Daten theoretisch alle vorhanden. Praktisch sind sie in 4 bis 7 Modulen verteilt: Materialwirtschaft (MM), Produktion (PP), Qualität (QM), Lieferant (LFA1), manchmal ein separates EHS-Modul für Umweltdaten, manchmal ein PLM-System für Rezepturen.
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 Integrationsmuster
Muster 1: OData / REST-Pull
Funktioniert gut mit modernen ERPs (SAP S/4HANA Cloud, Dynamics 365, Odoo). Der DPP-Anbieter zieht Daten über OData oder REST ab. Inkrementell, geplant oder ereignisgesteuert.
Vorteile: wenig Entwicklung Ihrerseits, Sie stellen Read-Credentials, der Anbieter baut die Transformation.
Nachteile: funktioniert nicht mit älteren SAP-ECC-Installationen ohne zusätzliche API-Schicht. Sie brauchen Governance über Data Access Requests.
Muster 2: Event-basierte Integration
SAP Event Mesh, Apache Kafka, RabbitMQ. Ihr ERP publiziert Änderungsereignisse, der DPP-Anbieter konsumiert sie.
Vorteile: nahezu in Echtzeit, elegant skalierbar, entkoppelt.
Nachteile: Die Einrichtung ist anspruchsvoll und braucht Infrastruktur, die nicht jede IT-Abteilung hat. Für kleinere Firmen meist übertrieben.
Muster 3: Middleware / ETL
Sie haben eine Integrationsschicht (Mulesoft, Boomi, Informatica, Azure Data Factory) zwischen ERP und externen Systemen. Die Middleware ist der Vertrag - der DPP-Anbieter spricht mit der Middleware, nie direkt mit dem ERP.
Vorteile: bestehende Investitionen sind nutzbar, Governance stabil, kein direkter ERP-Zugriff für Dritte.
Nachteile: Ihre Middleware-Kosten skalieren 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 API akzeptiert ein neutrales JSON-Schema, das Sie mit einem Tool 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 Schema und alle Endpoints sind unter /apidocs als OpenAPI-Spezifikation öffentlich dokumentiert. 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 «Source of Truth» für welches Feld 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 API-Abfragen 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 Middleware-Investition, die genutzt werden sollte?
- Gibt es eine bereits funktionierende API-Schicht über Ihrem ERP?
Die Antworten bestimmen, welches der drei Muster für Sie passt. Und sie legen fest, ob ein Projekt zwei Wochen oder sechs Monate dauert.