ERP-/PIM-Integration · herstellerneutraler Leitfaden

Produktkonfigurator mit ERP und PIM verbinden Datenflüsse prüfbar planen.

Eine Produktkonfigurator-Schnittstelle ist nicht nur der Transport eines JSON-Dokuments. Produktstamm, Merkmale, Regeln, Medien, Preise, Kundenkontext und das angenommene Ergebnis können aus verschiedenen Systemen kommen und zu unterschiedlichen Zeitpunkten verbindlich werden. Dieser Leitfaden ordnet die fachlichen Verträge zwischen PIM, Konfigurator, CPQ, CRM, Shop und ERP, bevor eine konkrete API oder Plattform gewählt wird.

SuchauftragERP-/PIM-Datenvertrag

MethodeHoheit · Revision · Abnahme

Stand29. August 2026

Direktantwort

ERP, PIM und Konfigurator brauchen mehrere Verträge – nicht nur eine Schnittstelle.

Um einen Produktkonfigurator belastbar mit ERP und PIM zu verbinden, wird zuerst für jedes Datenobjekt ein führendes System festgelegt. Danach werden stabile IDs, Richtung, Takt, Version, Transformation und fachliche Abnahme dokumentiert. Produkt- und Mediendaten können beispielsweise periodisch aus dem PIM kommen, während Preise zur Laufzeit aus ERP oder CPQ geprüft werden. Das freigegebene Konfigurationsergebnis benötigt eine unveränderliche ID und Revision, bevor daraus ein Angebot oder Auftrag entsteht. Wiederholung, Timeout, Duplikat, veraltete Varianten und abweichende Preise gehören als erwartete Betriebsfälle in Vertrag, Monitoring und Reconciliation – nicht erst in die Fehlersuche nach dem Go-live.
Herstellerneutrale Planungsgrundlage. Keine Machbarkeits-, Kosten-, Termin-, Rechts- oder Produktempfehlung für ein ungeprüftes Vorhaben.

Ungegatete Arbeitsvorlagen

Integration Boundary Kit ohne Upload und E-Mail-Gate

Die CSV-Vorlage macht Systemhoheit, Quell- und Ziel-ID, Änderungsrichtung, Aktualität, Transformation, Deaktivierung und Abnahmeregel je Feld sichtbar. Die Abnahmematrix ergänzt zehn konkrete Prüfungen vom gültigen Ergebnis bis zum mehrdeutigen ERP-Timeout. Sämtliche Beispielnamen, IDs, Produkte, Preise und Systemzustände sind fiktiv und müssen durch den eigenen Projektkontext ersetzt werden.

Die Dateien werden direkt heruntergeladen. Es werden dafür keine Produkt-, Kunden- oder Zugangsdaten an Midnight Motion übertragen.

CSV · SystemhoheitSystemhoheit-FeldmappingObjekt, Quelle, ID, Richtung, Version, Deaktivierung und Abnahme dokumentieren.CSV herunterladen → Markdown · TestmatrixKonfiguration-zu-Auftrag-AbnahmeRevisionen, Wiederholung, Timeout, Preisabweichung und Reconciliation prüfen.Markdown herunterladen →

System Boundary Ledger

PIM, Konfigurator, CPQ, CRM, Shop und ERP besitzen unterschiedliche Mandate.

Die folgende Rollenverteilung ist ein Prüfrahmen, keine universelle Zielarchitektur. Ein Unternehmen kann Produktregeln vollständig im ERP, in einer CPQ-Plattform oder in einem spezialisierten Konfigurator führen. Entscheidend ist nicht der Systemname, sondern wer ein Objekt fachlich freigibt, wer es ändern darf und welches System bei einem Widerspruch gewinnt.

S-01

PIM oder Produktdatenquelle

Pflegt häufig Produktfamilien, Attribute, lokalisierte Texte, Medien, Dokumente und kanalbezogene Ausleitungen. Ein PIM kann Variantenachsen und Beziehungen beschreiben, muss aber nicht die vollständige technische Gültigkeitslogik eines konfigurierbaren Produkts enthalten.

Empfängt: Je nach Organisation kommen Artikelreferenzen, technische Grunddaten oder Freigabestatus aus ERP, PLM oder Produktmanagement hinein.
Sendet: Veröffentlichte Produktinformationen, Assets, Merkmalsdefinitionen und stabile Referenzen gehen an Konfigurator, Shop oder weitere Kanäle.
Hoheitsentscheidung: Je Attributgruppe festlegen, ob PIM, ERP, PLM oder Konfigurator fachlich führt; nicht pauschal das gesamte Produkt einem System zuweisen.

Warnung

Ein übersetzter Marketingtext und eine produktionsrelevante Materialeigenschaft haben unterschiedliche Freigaben und dürfen nicht still gleich behandelt werden.

S-02

Produktkonfigurator

Führt Nutzer durch Merkmale, prüft Regeln und erzeugt ein nachvollziehbares Konfigurationsergebnis. Er sollte die verwendete Produkt- und Regelversion festhalten, damit ein späterer Auftrag nicht nur den aktuellen, inzwischen veränderten Katalog kennt.

Empfängt: Merkmale, Inhalte, Preise oder Preisparameter, Kundenkontext und gegebenenfalls Verfügbarkeit aus den jeweils führenden Quellen.
Sendet: Konfigurations-ID, Revision, ausgewählte Optionen, berechnete technische Werte, Dokumentreferenzen und den vorgesehenen nächsten Geschäftsstatus.
Hoheitsentscheidung: Klären, ob Regeln ausschließlich hier gepflegt werden oder aus ERP beziehungsweise PLM repliziert und nur für die Nutzerführung interpretiert werden.

Warnung

Ein im Browser sichtbarer Zustand ist noch kein dauerhaftes Geschäftsdokument; erst ein serverseitig gespeichertes und versioniertes Ergebnis kann zuverlässig weitergegeben werden.

S-03

CPQ oder Angebotslogik

Steuert je nach Lösung kundenspezifische Preise, Rabatte, Margengrenzen, Freigaben, Angebotsversionen und Dokumente. Ein Konfigurator kann Bestandteil dieses Prozesses sein, ohne dass beide Systeme dieselbe Regelengine besitzen.

Empfängt: Gültiges Konfigurationsergebnis, Account- und Opportunity-Kontext sowie Preis- oder Konditionsgrundlagen.
Sendet: Freigegebene Quote-Revision, Konditionen, Gültigkeit, Angebotspositionen und nach Annahme den Auftragshandoff.
Hoheitsentscheidung: Festlegen, an welchem Schritt ein angezeigter Preis verbindlich wird und ob spätere ERP-Neuberechnung erlaubt, blockierend oder freigabepflichtig ist.

Warnung

Eine einfache Optionssumme macht den Konfigurator noch nicht zum führenden System für kundenspezifische Konditionen und Angebotsfreigaben.

S-04

CRM

Führt häufig Account, Kontakt, Opportunity, Vertriebsphase und Verantwortlichkeit. Es kann die Konfigurations- oder Angebotsreferenz speichern, ohne technische Produktdaten zu duplizieren.

Empfängt: Status, Referenz und zusammengefasste Werte, die Vertrieb und Service im Kundenkontext benötigen.
Sendet: Kunden-ID, Kundengruppe, Opportunity-ID, Vertriebsrolle oder freigegebene Übergabe an CPQ und Konfigurator.
Hoheitsentscheidung: Bestimmen, welche Kundenkennung über alle Systeme stabil ist und welche personenbezogenen Daten für Konfiguration oder Auftrag tatsächlich erforderlich sind.

Warnung

Kontaktdaten aus dem CRM ersetzen weder ERP-Geschäftspartnerfunktionen noch eine fachlich freigegebene Liefer- oder Rechnungskonstellation.

S-05

Shop oder Kundenportal

Stellt den Self-Service-Kanal, Warenkorb, Login oder Dokumentzugriff bereit. Der Kanal kann eine Konfiguration starten und fortsetzen, sollte aber fachliche Regeln und sensible Preise nicht unkontrolliert duplizieren.

Empfängt: Darstellbare Produktdaten, Konfigurationszustand, erlaubte Aktionen, Preisansicht und Ergebnisreferenz.
Sendet: Kanal-, Session- und Kundenkontext, Warenkorb- oder Anfrageaktion sowie die gewählte Konfigurationsrevision.
Hoheitsentscheidung: Klären, ob der Warenkorb nur eine Referenz übernimmt oder alle Optionen materialisiert und wie Änderungen nach dem Hinzufügen behandelt werden.

Warnung

Eine alte Browser-Session darf nicht unbemerkt mit neuen Regeln oder Preisen zu einem scheinbar identischen Ergebnis fortgesetzt werden.

S-06

ERP

Führt abhängig von der Landschaft Materialien, Einheiten, Geschäftspartner, Preise, Bestände, Lieferfähigkeit, Stücklisten, Aufträge, Fertigung und Abrechnung. Nicht jedes ERP stellt alle diese Objekte über dieselbe Schnittstelle oder in derselben Aktualität bereit.

Empfängt: Freigegebene Angebots- oder Auftragspositionen, stabile Produkt- und Kundenreferenzen, Konfigurationsrevision sowie gegebenenfalls technische Ausprägung oder Stücklistenparameter.
Sendet: Stammdaten, Preis- und Verfügbarkeitsantworten, Auftragsnummer, Annahme oder fachliche Ablehnung und nachgelagerte Status.
Hoheitsentscheidung: Je Objekt festlegen, ob ERP die Quelle, ein Prüfer oder nur das operative Ziel ist. Ein pauschales ‘ERP führt alles’ verdeckt sonst widersprüchliche Verantwortlichkeiten.

Warnung

Ein HTTP-Erfolg belegt nicht automatisch, dass Auftrag, Positionen und Konfigurationsreferenz fachlich vollständig angelegt wurden.

Authority Rules

Systemhoheit objektweise statt per Systemlogo klären

Systemhoheit bedeutet, dass für einen definierten fachlichen Wert genau feststeht, wo er freigegeben wird und wie andere Systeme Änderungen erhalten. Eine bidirektionale Vollsynchronisation ist selten ein sinnvoller Standard. Meist sind bewusst gerichtete Datenflüsse mit expliziten Rückmeldungen leichter zu verstehen, zu testen und zu betreiben.

Rule 01

Ein Eigentümer je kritischem Wert

Artikelnummer, Regel, Listenpreis, Kundenkondition und Auftragsstatus können unterschiedlichen Eigentümern gehören. Für jeden kritischen Wert wird ein System benannt, das Änderungen freigibt; andere Systeme halten Referenzen, Projektionen oder zeitlich begrenzte Kopien.

Wenn zwei Systeme denselben Wert ändern dürfen, muss vor der Umsetzung eine fachliche Konfliktregel existieren. ‘Der neueste Zeitstempel gewinnt’ ist für Preise, Regeln oder Auftragsstatus meist keine ausreichende Entscheidung.

Rule 02

Stabile Identität vor Feldmapping

Gleich benannte Produkte oder Optionswerte sind keine sichere Zuordnung. Fachliche IDs, externe IDs und Zielschlüssel werden dokumentiert, bevor Texte und Felder gemappt werden. Umbenennung darf eine bestehende Referenz nicht brechen.

Eine Zuordnung gilt erst als belastbar, wenn sie auch nach Umbenennung, Deaktivierung und erneutem Import eindeutig bleibt und ein Fachverantwortlicher die Bedeutung bestätigen kann.

Rule 03

Version und Zeitpunkt gehören zum Ergebnis

Ein Konfigurationsergebnis hängt von Produktstand, Regelversion, Preiszeitpunkt, Währung und gegebenenfalls Kundenkontext ab. Ohne diese Angaben lässt sich später nicht erklären, warum dieselbe Auswahl ein anderes technisches oder kaufmännisches Ergebnis erzeugt.

Das übergebene Ergebnis trägt die Revisionen, die für Reproduktion und fachliche Prüfung benötigt werden. Welche Änderungen eine erneute Validierung auslösen, wird ausdrücklich festgelegt.

Rule 04

Deaktivierung ist ein Geschäftsereignis

Gelöschte Optionen, geänderte Einheiten und zurückgezogene Produktstände betreffen gespeicherte Entwürfe, offene Angebote und Wiederbestellungen unterschiedlich. Eine technische Löschung ohne Übergangsregel kann historische Belege oder laufende Vorgänge unverständlich machen.

Für jedes relevante Objekt wird zwischen nicht mehr neu auswählbar, nur für Bestand sichtbar, ersetzbar und vollständig ungültig unterschieden. Historische Referenzen bleiben nachvollziehbar.

Data Contracts

Die wichtigsten Datenobjekt-Verträge

Ein Datenvertrag beschreibt mehr als Feldname und Datentyp. Er verbindet fachliche Bedeutung, Eigentümer, Identität, Version, zulässige Werte, Aktualität und die Reaktion auf Ablehnung. Die folgenden Objekte bilden einen neutralen Startpunkt und müssen am realen Produkt- und Auftragsprozess geprüft werden.

Objektbezogene Verträge für Produktkonfigurator-Integrationen
Objekt / Frage	Quelle und Payload	Identität / Version	Abnahme / Risiko
Produktfamilie und verkaufbares ProduktWelche Einheit kann ausgewählt, angeboten oder bestellt werden, und wie unterscheidet sie sich von Produktfamilie, Modell, Material und Verkaufsartikel?	PIM, ERP oder PLM können je nach Organisation unterschiedliche Teile der Definition führen. Stabile Produkt-ID, Bezeichnung, Status, Kategorie, Einheit, Gültigkeitszeitraum, Kanal und Referenzen auf Varianten- oder Regelmodell.	Interne Datenbank-ID und fachliche Artikelnummer getrennt behandeln; externe IDs je Zielsystem dokumentieren. Struktur- oder Freigabeänderungen erhalten einen nachvollziehbaren Stand. Reine Textkorrekturen können anders behandelt werden als technische Änderungen.	Ein freigegebenes Referenzprodukt ist in allen vorgesehenen Kanälen genau einmal zugeordnet und besitzt dieselbe fachliche Bedeutung. Doppelte Artikel, wiederverwendete Nummern oder unterschiedliche Einheiten erzeugen scheinbar erfolgreiche, aber fachlich falsche Übergaben.
Merkmal, Option und VariantenachseWelche Eingaben darf ein Nutzer sehen, welche Werte sind technisch zulässig und welche Attribute dienen nur Beschreibung oder Filterung?	PIM kann Merkmale und Variantenachsen liefern; technische Regeln können im Konfigurator, ERP oder PLM liegen. Merkmals-ID, Wert-ID, Datentyp, Einheit, Wertebereich, Übersetzung, Reihenfolge, Status und gegebenenfalls Abhängigkeit zur Produktfamilie.	Anzeigenamen sind nicht stabil. Auswahl und Ergebnis verwenden unveränderliche Codes oder IDs mit getrennten lokalisierten Labels. Wertebereich, Einheit oder Bedeutung ändern den Vertrag und erfordern eine Prüfung gespeicherter Konfigurationen.	Gültige und bewusst ungültige Kombinationen werden gegen dieselben Merkmals- und Wertreferenzen getestet. Ein PIM-Variantenmodell wird ungeprüft als vollständige Regelengine interpretiert oder eine übersetzte Bezeichnung als technische ID verwendet.
Regelwerk und RegelversionWelches System entscheidet über Ausschluss, Pflichtwert, Berechnung und technische Gültigkeit einer Kombination?	Konfigurator, CPQ, ERP-Variantenkonfiguration oder PLM – abhängig von Produkt und vorhandener Governance. Regelreferenz, Version, Freigabestatus, Gültigkeitsbeginn, relevante Eingaben, Ergebnis und verständliche Ablehnungsgründe.	Regel-ID und veröffentlichte Regelversion werden getrennt gespeichert; ein Entwurf darf keine produktive Revision überschreiben. Neue Regeln gelten nur für definierte Vorgänge oder lösen eine kontrollierte Revalidierung offener Konfigurationen aus.	Goldene gültige Fälle und bewusst ungültige Gegenbeispiele liefern unter der dokumentierten Version reproduzierbare Ergebnisse. PIM, Frontend und ERP prüfen unterschiedliche Stände und erklären dieselbe Kombination widersprüchlich für gültig oder ungültig.
Texte, Medien und DokumenteWelche Inhalte erklären die Auswahl, welche sind vertrags- oder produktionsrelevant und wann gelten sie als veröffentlicht?	PIM oder DAM führen häufig lokalisierte Inhalte und Assets; freigegebene technische Dokumente können aus PLM oder DMS kommen. Inhalts-ID, Sprache, Kanal, Freigabestatus, Asset-URL oder Dokumentreferenz, Prüfsumme und Alternativtext.	Asset-Referenzen bleiben stabil, auch wenn eine Datei ersetzt wird; Version oder Prüfsumme macht die verwendete Ausgabe nachvollziehbar. Marketinginhalt kann unabhängig aktualisiert werden, während ein Angebots- oder Prüf-Dokument an der Quote-Revision eingefroren wird.	Fehlende Übersetzung, gesperrtes Asset und ersetzte Datei besitzen einen definierten Fallback und werden im vorgesehenen Kanal geprüft. Der Konfigurator speichert ablaufende URLs oder zeigt eine aktuelle Zeichnung zu einer historischen Konfigurationsrevision.
Preis und KundenkontextWelcher Preis wird nur angezeigt, welcher wird angeboten und welcher wird beim Auftrag verbindlich geprüft?	ERP oder CPQ führen häufig Preislisten und Konditionen; einfache Optionszuschläge können im Konfigurator liegen. Währung, Netto-/Bruttokontext, Preisbestandteile, Kundengruppe, Sales Area, Gültigkeit, Steuerhinweis und Berechnungszeitpunkt.	Preisantwort referenziert Produkt, Konfigurationsrevision, Kunde oder Kundengruppe und Preisregelstand. Festlegen, ob ein gespeicherter Preis bis zu einem Zeitpunkt gilt oder bei Quote beziehungsweise Auftrag neu berechnet werden muss.	Mindestens Standardkunde, kundenspezifische Kondition, Währungswechsel und abgelaufene Preisgültigkeit werden fachlich abgeglichen. Frontend, CPQ und ERP zeigen unterschiedliche Werte, ohne dass die Abweichung blockiert oder einer Freigabe zugeführt wird.
Verfügbarkeit und LieferaussageBenötigt der Nutzer eine Momentaufnahme, eine belastbare Zusage oder nur einen unverbindlichen Hinweis auf Beschaffbarkeit?	ERP, Warenwirtschaft oder Produktionsplanung; ein PIM ist dafür typischerweise nur eine Darstellungsschicht. Material- oder Produktreferenz, Standort, Menge, Zeitpunkt, Status, erwartetes Datum und Aussagequalität.	Antworten werden auf Produkt, relevante Optionen, Werk beziehungsweise Lager und Abfragezeitpunkt bezogen. Kurzlebige Verfügbarkeit wird nicht wie ein dauerhafter Stammdatensatz behandelt und vor verbindlicher Bestellung erneut geprüft.	Nicht verfügbar, unbekannt, verspätet und Zielsystem nicht erreichbar sind getrennte, verständliche Zustände. Ein Cache oder Timeout wird fälschlich als Bestand null interpretiert oder eine alte Momentaufnahme als Lieferzusage angezeigt.
KonfigurationsergebnisWelche Auswahl und Berechnung muss später exakt wiedergefunden, geprüft und in ein Angebot oder einen Auftrag übernommen werden?	Der serverseitige Konfigurationsdienst oder die Plattform, die Gültigkeit und Revision garantiert. Konfigurations-ID, Revision, Produkt- und Regelversion, ausgewählte Werte, berechnete Ausgaben, Status, Erstellungszeit und Akteur- oder Kanalreferenz.	Eine stabile ID bezeichnet den Vorgang; jede fachliche Änderung erzeugt eine neue Revision statt stiller Überschreibung. Angebot und Auftrag referenzieren genau die freigegebene Revision. Ein späterer Entwurf verändert diese Referenz nicht rückwirkend.	Das Ergebnis ist nach Reload und über den vorgesehenen Folgeschritt reproduzierbar; geänderte Regeln werden sichtbar behandelt. Nur ein Frontendzustand oder Freitext wird übertragen, sodass ERP und Support die ursprüngliche Auswahl nicht zuverlässig rekonstruieren können.
Quote oder AngebotsrevisionWelche Konfiguration, Preise, Konditionen und Dokumente wurden tatsächlich freigegeben und dem Kunden angeboten?	CPQ, CRM-Angebotsmodul oder ERP – abhängig vom verbindlichen Angebotsprozess. Quote-ID, Revision, Konfigurationsreferenz, Positionen, Preisstand, Gültigkeit, Freigaben, Dokumente und Annahmestatus.	Quote und Konfiguration besitzen getrennte IDs und Revisionen; mehrere Angebote können auf demselben Konfigurationsstand aufbauen. Änderungen an Preis, Position oder Kondition erzeugen eine neue Quote-Revision und können erneute Freigaben erfordern.	Freigegebene Dokumente, angezeigte Summe und strukturierte Positionen stimmen unter derselben Revision überein. Ein aktualisiertes PDF und ein alter strukturierter Datensatz werden gemeinsam an ERP oder Kunde weitergegeben.
Auftrag, Position und StücklistenbezugWas muss das ERP nach Annahme erzeugen, und welche technische Ausprägung wird für Auftragsabwicklung oder Fertigung benötigt?	Das ERP nimmt den Auftrag an; Stücklisten oder Arbeitspläne können aus ERP-Variantenlogik, Konfigurator oder PLM abgeleitet werden. Externe Übergabe-ID, Quote- und Konfigurationsrevision, Kunde, Positionen, Mengen, Einheiten, Preisreferenz, technische Parameter und gewünschter Folgeprozess.	Die externe Übergabe-ID wird im ERP eindeutig gespeichert und mit ERP-Auftragsnummer sowie Positionen zurückgemeldet. Nach Annahme wird nicht dieselbe Revision überschrieben. Änderung und Storno folgen dem dafür definierten ERP-Prozess.	Erfolg bedeutet einen fachlich angenommenen Auftrag mit korrekten Positionen und Referenzen, nicht nur eine erfolgreiche Transportantwort. Ein Retry erzeugt einen Doppelauftrag oder technische Optionen werden ohne eindeutige Material-, Parameter- oder Stücklistenzuordnung übernommen.

Integration Patterns

Fünf Integrationsmuster – passend zur fachlichen Aktualität

REST, Datei, Event und Middleware sind keine Qualitätsstufen. Ein täglich freigegebener Katalog kann per Batch verlässlicher sein als eine unnötige Live-Kopplung. Ein angenommener Auftrag benötigt dagegen meist eine unmittelbare, nachweisbare Bestätigung. Häufig kombiniert eine Architektur mehrere Muster.

batch

Geplanter Batch oder versionierter Import

Ein freigegebener Produktstand wird zu einem definierten Zeitpunkt exportiert, validiert und als vollständige oder inkrementelle Version in den Konfigurator übernommen.

Passt, wenn

Produkttexte, Medien, Merkmale oder Katalogstände nicht sekundengenau sein müssen und ein fachlicher Veröffentlichungszeitpunkt wichtiger ist als permanente Kopplung.

Passt nicht, wenn

Kundenpreis, verbindliche Verfügbarkeit oder unmittelbare Auftragsbestätigung vom aktuellen Zielsystemzustand abhängen.

Import-ID, Quellversion und Zeitfenster protokollieren
Schema und fachliche Pflichtwerte vor Aktivierung validieren
fehlerhaften Stand nicht teilweise veröffentlichen
vorherige freigegebene Version als kontrollierten Rückfall behalten

event

Ereignisgesteuerte Synchronisation mit Queue

Das führende System meldet eine Änderung. Ein Integrationsdienst liest den aktuellen Datensatz, transformiert ihn und verarbeitet ihn entkoppelt im Ziel.

Passt, wenn

Änderungen zeitnah verteilt werden sollen, das Ziel kurze Verzögerung akzeptiert und Lastspitzen oder temporäre Ausfälle gepuffert werden müssen.

Passt nicht, wenn

Ereignisse keine stabile Objekt-ID oder Version tragen und das Ziel bei falscher Reihenfolge keinen aktuellen Stand erkennen kann.

Ereignis-ID und Objektversion gegen Duplikate verwenden
Reihenfolge beziehungsweise Last-Write-Regel fachlich definieren
Dead-Letter- und Wiederanlaufweg sichtbar betreiben
regelmäßigen Soll-Ist-Abgleich trotz Events vorsehen

runtime-lookup

Laufzeitabfrage mit begrenztem Cache

Der Konfigurator fragt Preis, Verfügbarkeit oder einen anderen flüchtigen Wert während eines konkreten Schritts aus dem führenden Dienst ab.

Passt, wenn

Die Aussage aktuell sein muss, nur für einen begrenzten Kontext gilt und das Quellsystem eine dafür geeignete, belastbare Schnittstelle bereitstellt.

Passt nicht, wenn

Jeder UI-Schritt vom ERP abhängt, keine klare Timeout-Anzeige existiert oder eine alte Antwort still als aktueller Wert weitergenutzt wird.

Timeout, Cache-Dauer und Fallback fachlich sichtbar machen
Antwort mit Kunde, Produkt, Kontext, Währung und Zeitpunkt binden
Rate Limits und Lastverhalten mit realistischen Tests prüfen
verbindlichen Wert vor Quote oder Auftrag erneut validieren

command-handoff

Expliziter Command mit fachlicher Bestätigung

Eine freigegebene Konfigurations- oder Quote-Revision wird mit eindeutiger Übergabe-ID an das ERP gesendet. Das Ziel bestätigt Auftrag und Positionen oder lehnt fachlich begründet ab.

Passt, wenn

Ein Geschäftsvorgang genau einmal wirksam werden und seine Annahme für Nutzer, Support und Folgeprozesse nachweisbar sein muss.

Passt nicht, wenn

Der Absender bei Timeout nicht prüfen kann, ob das Ziel bereits verarbeitet hat, oder dieselbe Aktion bei Wiederholung Doppelaufträge erzeugt.

eindeutige externe Übergabe-ID und Revisionsbezug senden
Annahme, Ablehnung und unbekannten Ausgang getrennt modellieren
Retry nur mit idempotentem fachlichem Vertrag ausführen
ERP-Referenz und Positionsabgleich als Erfolgsbeleg speichern

orchestration

Middleware oder Prozess-Orchestrierung

Ein eigener Integrationsdienst koordiniert mehrere Schritte, etwa Kunde prüfen, Preis validieren, Auftrag anlegen, Dokument referenzieren und Status zurückmelden.

Passt, wenn

Mehrere Systeme, Transformationen und Rückmeldungen zusammengehören, ohne dass die gesamte Prozesslogik in Frontend oder ERP-Anpassung verteilt werden soll.

Passt nicht, wenn

Die Zwischenschicht nur Nachrichten weiterleitet, aber niemand Datenverträge, Betrieb, Monitoring und fachliche Fehlerentscheidung verantwortet.

Prozesszustand und Korrelation über alle Systeme speichern
Schritte einzeln wiederholbar oder kompensierbar planen
technische und fachliche Fehler getrennt eskalieren
Schnittstellenänderungen versionieren und Ende-zu-Ende testen

Configuration → Order

Von der Konfiguration zum bestätigten Auftrag

Eine robuste Übergabe macht Zwischenzustände explizit. Dadurch sieht der Vertrieb den Unterschied zwischen gespeichert, gültig, preislich geprüft, angenommen, an ERP gesendet und im ERP fachlich bestätigt. Das verhindert, dass ein Timeout vorschnell als Fehlschlag oder ein Transporterfolg als fertiger Auftrag behandelt wird.

01
draft
Entwurf gespeichert
Eingaben besitzen eine Konfigurations-ID, sind aber noch änderbar und nicht als fachlich gültiges Ergebnis freigegeben.
Transition
Eine vollständige Eingabe wird gegen die vorgesehene Produkt- und Regelversion validiert.
Beleg
Gespeicherte ID, Revision, Erstellungszeit und verwendeter Produktkontext.
02
validated
Technisch validiert
Pflichtwerte und Regeln sind unter einer dokumentierten Version erfüllt. Das ist noch keine verbindliche Preis- oder Lieferzusage.
Transition
Preis- und gegebenenfalls Verfügbarkeitskontext werden aus den führenden Quellen bestimmt.
Beleg
Validierungszeit, Regelversion, Ergebniswerte und verständliche Prüfantwort.
03
priced
Preislich geprüft
Ein Preis wurde für Kunde oder Kundengruppe, Währung, Kanal und Zeitpunkt ermittelt und seiner Gültigkeit zugeordnet.
Transition
Das Ergebnis wird als Quote oder andere freigabefähige Angebotsgrundlage materialisiert.
Beleg
Preisreferenz, Bestandteile, Kontext, Zeitpunkt und gegebenenfalls Freigabestatus.
04
quoted
Quote revisioniert
Positionen, Konditionen, Dokumente und Konfigurationsrevision bilden eine zusammengehörige Angebotsrevision.
Transition
Die nötigen fachlichen Freigaben werden abgeschlossen und die Annahme wird eindeutig erfasst.
Beleg
Quote-ID, Revision, freigegebene Dokumentversion und Genehmigungsprotokoll.
05
accepted
Annahme erfasst
Die maßgebliche Quote- und Konfigurationsrevision wurde angenommen. Nachträgliche Änderungen erzeugen einen neuen Vorgang oder eine geregelte Änderung.
Transition
Ein Order-Command mit eindeutiger externer Übergabe-ID wird erzeugt.
Beleg
Annahmezeit, Akteur, Quote-Revision und daraus gebildete Übergabe-ID.
06
order-requested
Auftrag angefordert
Der vollständige Handoff wurde an ERP oder Orchestrator gesendet. Solange keine eindeutige Antwort vorliegt, ist der Ausgang unbekannt und nicht automatisch fehlgeschlagen.
Transition
Das Ziel meldet fachliche Annahme, fachliche Ablehnung oder bleibt innerhalb der vereinbarten Frist ungeklärt.
Beleg
Korrelations-ID, Payload-Prüfsumme, Sendezeit, Versuch und technische Antwort.
07
order-acknowledged
Auftrag fachlich bestätigt
Das ERP hat einen Auftrag mit den erwarteten Positionen und Referenzen angelegt und seine eigenen IDs zurückgemeldet.
Transition
Nachgelagerte Status können separat synchronisiert werden; der ursprüngliche Handoff bleibt unverändert nachweisbar.
Beleg
ERP-Auftragsnummer, Positionszuordnung, bestätigte externe ID und fachliches Ergebnis.
08
rejected-or-reconciled
Abgelehnt oder abgeglichen
Eine fachliche Ablehnung besitzt einen bearbeitbaren Grund. Ein zunächst unbekannter Ausgang wurde gegen das Zielsystem geprüft und eindeutig auf bestätigt, abgelehnt oder manuell zu klären gesetzt.
Transition
Korrektur erzeugt eine neue Revision oder einen neuen kontrollierten Übergabeversuch; kein stilles Überschreiben des alten Nachweises.
Beleg
Ablehnungscode oder Reconciliation-Protokoll, Verantwortlichkeit und dokumentierte Folgeentscheidung.

Failure Ledger

Retry und Reconciliation für reale Fehlerwege

Technische Wiederholung ist nur sicher, wenn die fachliche Wirkung eindeutig bleibt. Besonders bei Auftragsanlage kann eine unterbrochene Antwort bedeuten, dass das ERP bereits verarbeitet hat. Reconciliation prüft deshalb anhand stabiler IDs den tatsächlichen Zielzustand, statt dieselbe Aktion blind erneut auszuführen.

Timeout mit unbekanntem Ausgang

Mehrdeutigkeit

Die Verbindung endet, nachdem das ERP die Anfrage möglicherweise angenommen hat. Der Absender kennt weder sicheren Erfolg noch sicheren Fehlschlag.

Retry

Nicht sofort mit neuer Übergabe-ID erneut senden. Zuerst mit derselben externen ID den Zielzustand abfragen oder einen idempotenten Wiederholungsvertrag verwenden.

Reconciliation

ERP nach externer ID durchsuchen und Auftrag, Positionen sowie Revision abgleichen. Erst bei bestätigtem Nichtvorhandensein erneut auslösen.

Nachweis

Korrelations-ID, Versuch, Zeit, Payload-Prüfsumme, technische Antwort und Ergebnis der Zielsuche.

Doppelte Zustellung

Mehrdeutigkeit

Queue, Nutzeraktion oder Wiederanlauf liefert denselben fachlichen Command mehrfach aus.

Retry

Das Ziel erkennt die externe Übergabe-ID und gibt dieselbe fachliche Referenz zurück, statt einen weiteren Auftrag zu erzeugen.

Reconciliation

Mehrere Zielobjekte mit derselben externen ID gelten als Abweichung und werden nicht automatisch zusammengeführt oder gelöscht.

Nachweis

Deduplizierungsentscheidung und eindeutige Zuordnung zwischen externer Übergabe-ID und ERP-Auftrag.

Veraltete Produkt- oder Regelversion

Mehrdeutigkeit

Eine gespeicherte Konfiguration referenziert Werte, die inzwischen deaktiviert oder fachlich verändert wurden.

Retry

Wiederholung ändert den alten Datensatz nicht. Der Prozess folgt der festgelegten Regel für Bestandsschutz, Revalidierung oder neue Revision.

Reconciliation

Produktmanagement entscheidet anhand Änderungsart und Vorgangsstatus, ob die historische Revision gültig bleibt oder neu bearbeitet werden muss.

Nachweis

Alte und aktuelle Version, Änderungsgrund, betroffene Vorgänge und Freigabeentscheidung.

Preisabweichung vor Auftrag

Mehrdeutigkeit

Der im Angebot dokumentierte Preis weicht von der aktuellen ERP-Berechnung ab. Technisch sind beide Antworten gültig, fachlich aber nicht austauschbar.

Retry

Keine automatische Überschreibung. Vertraglich festlegen, ob Angebotsgültigkeit gewinnt, eine Toleranz greift oder eine erneute Freigabe erforderlich ist.

Reconciliation

Preisbestandteile, Währung, Kunde, Zeitpunkt und Regelstände vergleichen und eine nachvollziehbare kaufmännische Entscheidung speichern.

Nachweis

Quote-Revision, ursprüngliche Preisantwort, ERP-Neuberechnung und Freigabe beziehungsweise Ablehnung.

Unbekannte ID, Einheit oder deaktivierte Option

Mehrdeutigkeit

Das Ziel kann einen fachlichen Wert nicht zuordnen, obwohl Schema und Transport formal korrekt sind.

Retry

Erst Mapping oder Stammdatenstand korrigieren; identischer unveränderter Payload wird nicht wiederholt.

Reconciliation

Fehler in eine fachliche Klärungsliste mit Quellwert, Zielkontext und Eigentümer überführen. Korrektur wird versioniert und erneut getestet.

Nachweis

Ablehnungscode, betroffene Feldreferenz, Mappingversion und fachlich bestätigte Korrektur.

Teilweise Anlage im Zielsystem

Mehrdeutigkeit

Auftragskopf existiert, aber Position, Stücklistenbezug oder Dokumentreferenz fehlt. Ein pauschaler Erfolgsstatus wäre irreführend.

Retry

Nur einen ausdrücklich wiederholbaren Teilschritt erneut ausführen. Andernfalls den Vorgang sperren und fachlich prüfen.

Reconciliation

Erwartete und tatsächliche Zielobjekte positionsweise vergleichen und entscheiden, ob ergänzt, storniert oder neu angelegt wird.

Nachweis

ERP-Objekt-IDs, Positionsvergleich, fehlende Referenzen und dokumentierte Korrekturentscheidung.

PIM-Ereignisse in falscher Reihenfolge

Mehrdeutigkeit

Eine ältere Änderung trifft nach einer neueren ein oder ein Lösch-/Deaktivierungsereignis wird vor dem zugehörigen Update verarbeitet.

Retry

Objektversion oder Quellzeitpunkt prüfen; ältere Zustände nicht ungeprüft über neuere schreiben.

Reconciliation

Den aktuellen Datensatz aus dem führenden System lesen und regelmäßig einen vollständigen Soll-Ist-Abgleich durchführen.

Nachweis

Ereignis-ID, Objektversion, Verarbeitungsreihenfolge und zuletzt bestätigter Quellstand.

Abnahmematrix

Zehn Abnahmeszenarien vor dem Pilot

Die Szenarien verwenden das ausdrücklich fiktive Beispielprodukt ‘Demo-Pumpenmodul PX’ und erfundene IDs. Im Projekt werden sie durch repräsentative Produkte, Kundenkontexte und Zielsysteme ersetzt. Abnahme erfolgt über fachliche Ergebnisse und Zielbelege, nicht nur über erfolgreiche HTTP-Antworten.

AT-01

Gültige Konfiguration wird genau einmal angenommen

Setup

Fiktive Revision CFG-DEMO-1042-R1 enthält ein gültiges Pumpenmodul, freigegebene Optionen, passende Einheit und eine dokumentierte Quote.

Erwartet

Das ERP erzeugt genau einen Auftrag, ordnet alle Positionen zu und bestätigt externe Übergabe-ID sowie Konfigurationsrevision.

Nachweis

Payload-Prüfsumme, ERP-Auftragsnummer, Positionsmapping und fachlicher Soll-Ist-Abgleich.

AT-02

Identische Wiederholung erzeugt keinen Doppelauftrag

Setup

Der vollständige Command aus AT-01 wird mit derselben externen Übergabe-ID erneut geliefert.

Erwartet

Das Ziel gibt den vorhandenen Auftrag oder einen eindeutigen Duplicate-Status zurück; die Zahl der Aufträge bleibt unverändert.

Nachweis

Deduplizierungsprotokoll und Suche im ERP nach der externen Übergabe-ID.

AT-03

Neue Revision bleibt vom angenommenen Stand getrennt

Setup

Nach Annahme von R1 wird im Konfigurator die fiktive Revision R2 mit einer anderen Option gespeichert.

Erwartet

R1 und der bestehende Auftrag werden nicht überschrieben. R2 benötigt den vorgesehenen Änderungs- oder neuen Angebotsprozess.

Nachweis

Revisionshistorie, unveränderte Auftragsreferenz und dokumentierter Folgestatus für R2.

AT-04

Deaktivierte Option wird kontrolliert behandelt

Setup

Die fiktive Option OPT-DEMO-BLAU wird nach Speicherung eines Entwurfs für neue Konfigurationen deaktiviert.

Erwartet

Neue Auswahl ist gesperrt; der alte Entwurf zeigt einen verständlichen Status und folgt der festgelegten Bestands- oder Revalidierungsregel.

Nachweis

PIM-/Regelversion, UI- und API-Ergebnis sowie fachliche Entscheidung zum Altvorgang.

AT-05

Preisänderung löst die richtige Entscheidung aus

Setup

Der fiktive ERP-Preis ändert sich zwischen Konfiguration und Auftragsanforderung, während die Quote noch oder nicht mehr gültig ist.

Erwartet

Je vereinbarter Regel wird der Quote-Preis akzeptiert, der Vorgang blockiert oder eine neue Freigabe verlangt; es gibt keine stille Überschreibung.

Nachweis

Beide Preisantworten, Gültigkeit, Regelentscheidung und gegebenenfalls neue Quote-Revision.

AT-06

ERP-Timeout bleibt als unbekannter Ausgang sichtbar

Setup

Die Verbindung wird nach Versand der fiktiven Übergabe ORD-DEMO-778 unterbrochen, bevor eine Antwort gelesen wird.

Erwartet

Der Status lautet nicht vorschnell fehlgeschlagen. Reconciliation sucht nach ORD-DEMO-778 und verhindert einen blinden neuen Command.

Nachweis

Timeout-Protokoll, Zielabfrage, gefundener oder sicher nicht vorhandener Auftrag und Folgeentscheidung.

AT-07

Unbekannte Einheit wird fachlich abgelehnt

Setup

Eine fiktive Option verwendet den Quellcode ‘SET’, während das Ziel nur den abgestimmten Code ‘ST’ akzeptiert.

Erwartet

Der Auftrag wird nicht teilweise als Erfolg gemeldet. Die Antwort benennt Feld und Wert; Mapping wird kontrolliert korrigiert.

Nachweis

Ablehnung, Mappingversion, fachliche Freigabe der Einheit und erfolgreicher neuer Testfall.

AT-08

Fehlender PIM-Inhalt hat einen definierten Fallback

Setup

Für das fiktive Produkt fehlt in einem Kanal eine Übersetzung oder ein Asset ist vorübergehend nicht erreichbar.

Erwartet

Der Kanal zeigt den vereinbarten Fallback oder blockiert die Veröffentlichung. Technische Gültigkeit und Angebotsdokument werden nicht unbemerkt verfälscht.

Nachweis

Kanalansicht, API-Antwort, Fallbackquelle und Veröffentlichungsergebnis.

AT-09

Teilweise ERP-Anlage wird erkannt

Setup

Das fiktive ERP legt den Auftragskopf an, lehnt jedoch eine Optionsposition wegen fehlender Materialzuordnung ab.

Erwartet

Der Gesamtstatus bleibt klärungsbedürftig. Kein automatischer Voll-Retry erzeugt einen zweiten Kopf; Soll und Ist werden positionsweise verglichen.

Nachweis

Auftragskopf, fehlende Position, Ablehnungsgrund, Sperrstatus und dokumentierte Korrekturentscheidung.

AT-10

Ereignisse außerhalb der Reihenfolge überschreiben nichts

Setup

Für ein fiktives PIM-Objekt wird zuerst Version 12 und danach verspätet Version 11 an die Verarbeitung geliefert.

Erwartet

Version 11 überschreibt nicht den bestätigten neueren Stand. Ein Soll-Ist-Abgleich bestätigt anschließend den aktuellen Quellzustand.

Nachweis

Ereignisreihenfolge, gespeicherte Objektversion, verworfene Änderung und Ergebnis des Quellabgleichs.

Aufwandstreiber

Was den Integrationsaufwand tatsächlich treibt

Ohne konkrete Systeme, Zugänge, Datenmodelle und Abnahmeszenarien ist ein pauschaler Preis- oder Terminrahmen nicht belastbar. Die folgenden Faktoren helfen, Angebote vergleichbar zu machen, ohne erfundene Marktpreise oder unbelegte Laufzeiten zu versprechen.

Unklare Systemhoheit und Datenqualität

Wenn Artikel, Preise oder Merkmale in mehreren Systemen widersprüchlich gepflegt werden, beginnt das Projekt mit fachlicher Klärung statt Implementierung.

Benötigter Beleg

Quelleninventar, verantwortliche Rollen, reale Beispieldatensätze und dokumentierte Konflikte.

Vereinfachung

Einen repräsentativen Produktbereich wählen und je kritischem Objekt genau eine Freigabequelle festlegen.

Abweichende Produkt- und Regelmodelle

PIM-Varianten, ERP-Materialien und Konfiguratorregeln besitzen häufig unterschiedliche Hierarchien, IDs und Bedeutungen.

Benötigter Beleg

Produktfamilie mit Merkmalen, gültigen und ungültigen Kombinationen, Stücklistenbezug und Regelverantwortung.

Vereinfachung

Zuerst ein durchgängiges Modell mit wenigen repräsentativen Varianten mappen und fachlich abnehmen.

Qualität und Umfang vorhandener Schnittstellen

Dokumentation, Authentifizierung, Limits, Filter, Änderungsinformationen und Testzugänge bestimmen, was kontrolliert automatisierbar ist.

Benötigter Beleg

Aktuelle Primärdokumentation, Lizenzumfang, Sandbox, Beispielantworten und benannte technische Ansprechpartner im eigenen Unternehmen oder beim Anbieter.

Vereinfachung

Vor einer Umsetzungszusage einen kleinen Read-/Write-Spike gegen die reale Testumgebung durchführen.

Aktualität, Volumen und Lastverhalten

Ein freigegebener Nachtimport, zeitnahe Events und eine synchrone Preisabfrage benötigen unterschiedliche Betriebs- und Fehlerkonzepte.

Benötigter Beleg

Objektzahlen, Änderungshäufigkeit, akzeptierte Verzögerung, Spitzenlast und Verhalten bei Quellausfall.

Vereinfachung

Nur Werte live abfragen, deren fachlicher Nutzen die zusätzliche Laufzeitkopplung rechtfertigt.

Preis-, Kunden- und Freigabekontext

Kundengruppen, Sales Areas, Währungen, Konditionen und Genehmigungen machen aus einer Optionssumme einen revisionsfähigen Vertriebsprozess.

Benötigter Beleg

Konkrete Preisfälle, Freigabegrenzen, Gültigkeitsregeln, Kundenrollen und erwartete Quote-Ausgabe.

Vereinfachung

Im ersten Scope Standardpreis und einen repräsentativen Sonderfall vollständig durchspielen, statt alle Ausnahmen gleichzeitig zu übernehmen.

Tiefe der ERP-Übergabe

Lead, Angebotsgrundlage, Auftrag, neue Materialvariante, Stückliste und Fertigungsauftrag sind fachlich verschiedene Zielobjekte.

Benötigter Beleg

Erwartetes ERP-Ergebnis, Pflichtfelder, Beispielauftrag, Positions- und Stücklistenlogik sowie Änderungsprozess nach Annahme.

Vereinfachung

Ein eindeutiges Zielobjekt für Version eins wählen und nachgelagerte Automatisierung als getrennten Ausbau planen.

Fehlerbetrieb, Monitoring und Reconciliation

Produktive Integration benötigt Verantwortlichkeit für unbekannte Ausgänge, fachliche Ablehnungen, wiederholte Events und schleichende Datenabweichung.

Benötigter Beleg

Fehlerklassen, Alarmweg, Wiederholungsregeln, Suchmöglichkeit im Zielsystem und fachliche Klärungsrolle.

Vereinfachung

Schon im Pilot eine kleine Betriebsansicht mit Korrelations-ID, Status, letztem Versuch und nächster Entscheidung bereitstellen.

Testumgebung, Sicherheit und Rollout

Fehlende Sandbox, unklare Berechtigungen oder unrealistische Testdaten verschieben Risiken in den produktiven Betrieb.

Benötigter Beleg

Zugangsmodell, Netzwerkweg, Testkonten, anonymisierte Referenzdaten, Abnahmeverantwortliche und Cutover-Regel.

Vereinfachung

Mit einer begrenzten Nutzer- und Produktgruppe pilotieren und Go-/No-Go anhand der Abnahmematrix entscheiden.

Dieser Leitfaden bewertet keine konkrete ERP-, PIM- oder CPQ-Plattform und behauptet keine Standardconnector-, Herstellerpartner- oder Zertifizierungskompetenz. Ob eine vorhandene Schnittstelle, ein natives Modul, Middleware oder individuelle Entwicklung passt, wird erst nach Prüfung von Lizenz, Dokumentation, Datenmodell, Testzugang und realem Zielprozess entschieden.

Quellen und Grenzen

Nachvollziehbare Methoden und Primärdokumentation.

Die Quellen stützen Methoden oder dokumentierte Produktfunktionen. Sie bestätigen weder Midnight Motion noch die Eignung einer konkreten Lösung für ein ungeprüftes Vorhaben.

Häufige Fragen

Konkrete Grenzen, klare Antworten.

Alle Antworten sind sichtbar und crawlbar. Sie werden nicht mit strukturiertem FAQ-Markup als Rich-Result-Versprechen ausgezeichnet.

Welche Aufgabe haben PIM und ERP beim Produktkonfigurator?

Ein PIM führt häufig Produktbeschreibungen, Medien, Übersetzungen, Attribute und kanalbezogene Ausleitungen. Ein ERP führt je nach Landschaft Materialien, Einheiten, Preise, Kunden, Verfügbarkeit, Auftrag und Fertigung. Diese Verteilung ist kein Naturgesetz: Für jedes Objekt wird konkret festgelegt, welches System freigibt, wer nur liest und wie Änderungen verteilt werden. Der Konfigurator führt Nutzer durch Regeln und speichert das konkrete Ergebnis mit einer nachvollziehbaren Revision.

Braucht ein Produktkonfigurator immer ein PIM?

Nein. Ein kleiner, stabiler Produktbereich kann seine Inhalte in einer vorhandenen Plattform oder einer kontrollierten Konfiguratorverwaltung pflegen. Ein PIM wird eher relevant, wenn viele Produktfamilien, Kanäle, Sprachen, Medien und getrennte Pflegeverantwortlichkeiten zusammenkommen. Vor einer Einführung sollte geprüft werden, ob das eigentliche Problem Produktdaten-Governance, technische Regeln oder beides ist.

Müssen Produktdaten und Preise in Echtzeit synchronisiert werden?

Nicht automatisch. Freigegebene Produkttexte oder Medien können oft als versionierter Batch verteilt werden. Ein kundenbezogener Preis oder eine verbindliche Lieferaussage kann eine Laufzeitabfrage benötigen. Echtzeit erhöht die Kopplung und braucht Timeout-, Cache- und Ausfallverhalten. Deshalb wird die notwendige Aktualität je Objekt festgelegt, statt die gesamte Integration pauschal als live zu planen.

Wann reicht ein nativer Connector und wann braucht es individuelle Integration?

Ein vorhandenes Modul kann passen, wenn es die benötigten Objekte, Richtungen, Versionen, Fehlerwege und Zielprozesse nachweislich unterstützt. Der Produktname allein genügt nicht. Individuelle Integration oder Middleware wird relevant, wenn Datenmodelle übersetzt, mehrere Systeme orchestriert, besondere Regeln berücksichtigt oder Lücken im Fehlerbetrieb geschlossen werden müssen. Diese Entscheidung setzt aktuelle Dokumentation, Lizenzprüfung, Testzugang und repräsentative Abnahmeszenarien voraus.

Wie wird eine Konfiguration als Stückliste an das ERP übergeben?

Zuerst wird festgelegt, ob der Konfigurator bereits eine fertige Stückliste erzeugt oder nur Parameter und Ausprägungen an eine ERP- oder PLM-Regelengine übergibt. Materialreferenzen, Mengen, Einheiten, Revisionen und Gültigkeit müssen eindeutig sein. Erfolg ist erst erreicht, wenn das ERP die erwarteten Positionen beziehungsweise technischen Parameter fachlich angenommen und mit dem ursprünglichen Konfigurationsergebnis verknüpft hat.

Wie testet man eine Produktkonfigurator-ERP-Schnittstelle?

Neben gültigen Referenzprodukten gehören ungültige Kombinationen, geänderte Regeln, deaktivierte Optionen, Preisabweichungen, unbekannte Einheiten, doppelte Zustellung, Timeout mit unbekanntem Ausgang, teilweise Zielanlage und Ereignisse außerhalb der Reihenfolge in die Abnahme. Jeder Fall braucht ein erwartetes fachliches Ergebnis und einen Zielbeleg. Die kostenlose Abnahmematrix dieses Leitfadens liefert dafür einen Startpunkt mit ausschließlich fiktiven Beispielen.

Kontextuell verknüpft

Passende nächste Arbeitswege.

Passender ArbeitswegKonfigurator-Anforderungen in 20 Punkten prüfenProduktfamilie, Regeln, Preislogik, UX, Systemquellen und Abnahme als übergabefähiges Briefing strukturieren.Passender ArbeitswegKonkrete API-Integration briefenQuell- und Zielsystem, Authentifizierung, Mapping, Takt, Fehlerwege und Betrieb für einen ausgewählten Datenfluss dokumentieren.Passender ArbeitswegCPQ und Produktkonfigurator abgrenzenPrüfen, ob gültige Auswahl genügt oder Preissteuerung, Freigaben, Angebotsrevisionen und Quote-to-Order hinzukommen.Passender ArbeitswegProduktkonfigurator-Vorhaben einordnenPlugin, bestehende Plattform, CPQ und individuelle Entwicklung am realen Produktmodell und Muss-Scope vergleichen.

Einen echten Datenfluss statt einer Systemliste prüfen

Welche Konfiguration soll in welchem Zielobjekt ankommen?

Nennen Sie vorhandenes ERP oder PIM, ein repräsentatives Produkt, die wichtigste Regel, das gewünschte Zielobjekt und verfügbare Schnittstellendokumentation. Wir ordnen unverbindlich ein, ob native Anbindung, Middleware, ein fokussierter Integrations-Workstream oder zunächst eine fachliche Datenklärung sinnvoll ist.

Konfigurator-Integration unverbindlich einordnen →

Direkter Ansprechpartner: Nicolas-Alexander Schelle · +49 176 43665669 · info@midnightmotion.studio

ERP, PIM und Konfigurator brauchen mehrere Verträge – nicht nur eine Schnittstelle.

Integration Boundary Kit ohne Upload und E-Mail-Gate

PIM, Konfigurator, CPQ, CRM, Shop und ERP besitzen unterschiedliche Mandate.

PIM oder Produktdatenquelle

Produktkonfigurator

CPQ oder Angebotslogik

CRM

Shop oder Kundenportal

ERP

Systemhoheit objektweise statt per Systemlogo klären

Ein Eigentümer je kritischem Wert

Stabile Identität vor Feldmapping

Version und Zeitpunkt gehören zum Ergebnis

Deaktivierung ist ein Geschäftsereignis

Die wichtigsten Datenobjekt-Verträge

Fünf Integrationsmuster – passend zur fachlichen Aktualität

Geplanter Batch oder versionierter Import

Ereignisgesteuerte Synchronisation mit Queue

Laufzeitabfrage mit begrenztem Cache

Expliziter Command mit fachlicher Bestätigung

Middleware oder Prozess-Orchestrierung

Von der Konfiguration zum bestätigten Auftrag

Entwurf gespeichert

Technisch validiert

Preislich geprüft

Quote revisioniert

Annahme erfasst

Auftrag angefordert

Auftrag fachlich bestätigt

Abgelehnt oder abgeglichen

Retry und Reconciliation für reale Fehlerwege

Timeout mit unbekanntem Ausgang

Doppelte Zustellung

Veraltete Produkt- oder Regelversion

Preisabweichung vor Auftrag

Unbekannte ID, Einheit oder deaktivierte Option

Teilweise Anlage im Zielsystem

PIM-Ereignisse in falscher Reihenfolge

Zehn Abnahmeszenarien vor dem Pilot

Gültige Konfiguration wird genau einmal angenommen

Identische Wiederholung erzeugt keinen Doppelauftrag

Neue Revision bleibt vom angenommenen Stand getrennt

Deaktivierte Option wird kontrolliert behandelt

Preisänderung löst die richtige Entscheidung aus

ERP-Timeout bleibt als unbekannter Ausgang sichtbar

Unbekannte Einheit wird fachlich abgelehnt

Fehlender PIM-Inhalt hat einen definierten Fallback

Teilweise ERP-Anlage wird erkannt

Ereignisse außerhalb der Reihenfolge überschreiben nichts

Was den Integrationsaufwand tatsächlich treibt

Unklare Systemhoheit und Datenqualität

Abweichende Produkt- und Regelmodelle

Qualität und Umfang vorhandener Schnittstellen

Aktualität, Volumen und Lastverhalten

Preis-, Kunden- und Freigabekontext

Tiefe der ERP-Übergabe

Fehlerbetrieb, Monitoring und Reconciliation

Testumgebung, Sicherheit und Rollout

Nachvollziehbare Methoden und Primärdokumentation.

Konkrete Grenzen, klare Antworten.

Passende nächste Arbeitswege.

Welche Konfiguration soll in welchem Zielobjekt ankommen?