Viele Integrationsprojekte werden als Connector-Aufgabe geplant: System A spricht mit System B. Aus Management-Sicht ist die bessere Frage: Welche Umsatz- und Serviceversprechen hängen an dieser Verbindung?

Die teuersten Integrationsfehler sind fast nie Entwicklerstunden, sondern Effekte wie:

• falsche Verfügbarkeiten → falsche Lieferzeiten → Checkout-Abbrüche
• fehlende Order-Updates → Support-Kontakte → höhere Kosten pro Bestellung
• inkonsistente Preise/Promos → Stornos, Kulanz, negative Bewertungen

Wenn Sie Integration als Umsatzhebel betrachten, ändern sich automatisch Prioritäten: Datenqualität, Prozesssicherheit und Monitoring werden „Revenue Protection“, nicht „nice to have“.

1) Integration als IT-Projekt statt als Umsatzhebel
Fehlerbild: Erfolg wird an „Go-live“ gemessen, nicht an Conversion, Retourenquote, Service-Level oder Durchlaufzeiten.
Verhindern: Definieren Sie 3–5 Business-KPIs pro Integration (z. B. „% Orders mit korrekter ETA“, „Refund-Durchlaufzeit“, „Support-Tickets pro 1.000 Orders“) und führen Sie diese als Abnahmekriterium.

2) „Shop → ERP“ denken statt Order Lifecycle Architecture
Fehlerbild: Der Order-Flow wird als einzelne Übergabe modelliert, nicht als Lebenslinie: Created → Paid → Picked → Shipped → Returned → Refunded.
Verhindern: Modellieren Sie den Order-Prozess als Zustandsmaschine. Legen Sie pro State fest, welches System autoritativ ist, welche Events „genau einmal“ wirken müssen und welche re-playbar sind.

3) Keine klare Regel für Exactly-once vs. At-least-once
Fehlerbild: Retry-Mechanismen erzeugen Doppelbuchungen (Payments, Refunds) oder doppelte Fulfillment-Aufträge.
Verhindern: „Exactly-once“ ist selten technisch garantiert, aber operativ erreichbar: Idempotency-Keys, dedizierte Business-Keys, eindeutige Event-IDs, und pro kritischer Aktion ein „write once“-Ledger (z. B. Payment/Refund Journal).

4) Idempotenz wird „vergessen“ (bis es teuer wird)
Fehlerbild: Duplikate werden als Randfall behandelt, sind aber in realen Netzen normal (Timeouts, Retries, Replays).
Verhindern: Erzwingen Sie Idempotenz in jeder mutierenden Schnittstelle (Create Order, Capture, Refund, Fulfillment Create). Testen Sie Duplikate bewusst: „Sende denselben Request 10ד. Erwartung: 1 Wirkung, 9 No-ops.

5) Fehlende Reconciliation-Loops (Abgleich statt Hoffnung)
Fehlerbild: Wenn etwas schiefgeht, gibt es keinen systematischen Abgleich. Man sucht manuell in Logs, bis Kunden eskalieren.
Verhindern: Bauen Sie einen regelmäßigen Abgleich: „Was sollte im Zielsystem existieren?“ vs. „Was ist dort?“ inkl. Auto-Repair oder Ticketing. Ein sauberer Reconciliation-Loop spart häufig mehr als „20% schnellere APIs“.

6) Delta-Logik naiv: „updated_at“ als Integrationsstrategie
Fehlerbild: Deletes, Korrekturen, verspätete Updates (Late Arrivals) und Backfills werden nicht sauber verarbeitet. Ergebnis: schleichende Inkonsistenzen.
Verhindern: Definieren Sie Delta-Regeln pro Datenklasse: Create/Update/Delete, Korrekturflüsse, Backfill-Prozess. Legen Sie fest, welches System Source of Truth ist (Orders ≠ Product ≠ Customer).

7) Schema Drift: Integration scheitert nicht am Start, sondern am Betrieb
Fehlerbild: Neue Felder, andere Datentypen, neue Kategorien oder Enum-Werte „brechen“ Downstream, ohne dass es auffällt.
Verhindern: Arbeiten Sie mit Data Contracts (Versionierung, erlaubte Felder, Validierungen) und automatisierten Contract-Tests. Behandeln Sie Datenvertrags-Tests so ernst wie Checkout-Tests.

8) Keine klare Datenkanonisierung (PIM/MDM als Luftfilter fehlt)
Fehlerbild: Produktdaten sind inkonsistent; jedes Zielsystem bekommt „eine andere Wahrheit“. Marktplätze, Ads, CRM und Support explodieren operativ.
Verhindern: Nutzen Sie PIM/MDM nicht nur für Content, sondern als Kanonisierungs- und Normalisierungsschicht: eindeutige Attribute, saubere Variantenlogik, stabile IDs, Übersetzungs- und Kategorie-Regeln. Ziel: weniger Sonderfälle in Integrationen.

9) Marketplace-Integration wird unterschätzt (Case-Management statt Feed)
Fehlerbild: Man plant „Produkte hoch, Orders runter“. In der Realität kommen SLA-Compliance, Claims, Returns, Preisregeln, Promos und Dispute-Handling dazu.
Verhindern: Modellieren Sie Marktplätze als operatives Regelwerk-Ökosystem. Definieren Sie Prozesse für Exceptions (Claims, Cancel-Requests, Late Shipment) inklusive Ownership und Eskalation. Technisch: Event-Trails und fallbezogene Historie pro Order/Listing.

10) Payment & Fraud ohne zustandsbehaftete Logik
Fehlerbild: Payment wird als Abfolge von API Calls implementiert; Retries ohne Idempotency-Key erzeugen echte finanzielle Schäden. Fraud-Signale werden zu spät oder gar nicht zurückgespielt.
Verhindern: Nutzen Sie eine Payment-State-Machine (Authorized/Captured/Void/Refunded/Chargeback) und klare Regeln, welche Aktion wann erlaubt ist. Fraud/PSP-Events müssen im Order Lifecycle „scharf“ verdrahtet sein, nicht als nachträgliches Logging.

11) Keine Observability: „Warum steckt der Auftrag?“ bleibt unbeantwortet
Fehlerbild: Es gibt Logs, aber keine Management-Antworten. Orders bleiben hängen, bis Kunden nachfragen.
Verhindern: Bauen Sie ein Revenue-Protection-Dashboard für Integrationen:

• Wie viele Orders stecken?
• Wo (System/Step) und seit wann?
• Welche Fehlercodes/Gründe dominieren?
• Wie hoch ist der betroffene Umsatz?

Ergänzen Sie Alerts nach Business-Impact (z. B. „>50 Orders im Status Paid-not-Fulfilled > 30 min“).

12) iPaaS vs. Custom als falsche Grundsatzfrage
Fehlerbild: Diskussion dreht sich um Tooling statt um Differenzierung und Änderungsfrequenz. Ergebnis: Commodity wird teuer gebaut oder Wettbewerbsvorteil wird in ein starres Tool gezwängt.
Verhindern: Nutzen Sie ein 2×2: Business-Differenzierung (niedrig/hoch) × Änderungsfrequenz (niedrig/hoch). Commodity + niedrig: iPaaS/Connector. Hoch differenzierend oder hoch volatil: eigene Domänenlogik/Events, bewusst getestet und beobachtbar.

• Wo zählt „genau einmal“? (Payment, Refund, Fulfillment-Create) Und ist Idempotenz dort technisch und operativ abgesichert?
• Wie finden wir Inkonsistenzen? Gibt es einen Reconciliation-Loop oder verlassen wir uns auf Support-Tickets?
• Wie messen wir Integration? Haben wir ein Dashboard, das Impact in Orders/Umsatz zeigt statt nur technische Metriken?

Wenn Sie diese drei Punkte sauber beantworten, sind viele Integrationsprobleme keine Überraschung mehr, sondern steuerbar.