← Alle Fallstudien

Fallstudie · ERP-Integration · E-Commerce

Produktdaten in 45 Minuten verarbeiten – mit einer schrittweise optimierten ERP-Integration.

Ein SAP-System liefert XML-Dateien per SFTP, ein Magento-Shop benötigt aktuelle Produkte, Bilder und PDFs. Eine neue Integrationsschicht mit Azure Functions ersetzt den störanfälligen Windows-Service.

6–8 Std → 45 Min
Import von 50.000 Produkten
23 % → 0,03 %
fehlerhafte Importläufe
23.280 € → 4.800 €
Kosten pro Jahr im Modell

Anonymisierter Bericht aus der Integrationspraxis. Ergebnisse beziehen sich auf das beschriebene System und 14 dokumentierte Betriebsmonate.

01 · Ausgangslage und Rolle

Ausgangslage und Rolle

Die vorhandene Verarbeitung lief auf einer dedizierten Windows-VM. Ein Import brauchte sechs bis acht Stunden, Fehler erforderten häufig manuelle Eingriffe. Ein einzelner langsamer oder fehlgeschlagener API-Aufruf konnte den gesamten Lauf beeinträchtigen.

Meine Arbeit in diesem Projekt umfasste Architektur und technische Umsetzung der Integrationslösung. Die Verbesserung entstand aus mehreren Optimierungsschritten im Betrieb; die Kennzahlen beschreiben das Gesamtsystem und keinen isolierten Beratereffekt.

02 · Entscheidungen

Die wesentlichen Entscheidungen

  • Verarbeitungsschritte über Queues entkoppeln, damit Fehler nicht jeden weiteren Schritt blockieren.
  • Große XML-Dateien streamen und API-Aufrufe unter Beachtung der Zielsystem-Limits parallelisieren.
  • Wiederholungen, Fehlerablage und Monitoring als Bestandteil der Lösung behandeln.
  • Verarbeitungszustände für Nachvollziehbarkeit und Reporting in SQL speichern.
03 · Ergebnisse

Ergebnisse im Projektbericht

Tabelle 1 — Technische Ergebnisse
MessgrößeAusgangslageErgebnisVeränderung
Import von 50.000 Produkten6–8 Stunden45 Minuten≈ −90 %
Fehlerhafte Importläufe23 %0,03 %−22,97 Pp.
Tägliches Volumenbegrenzt durch feste VM-Kapazität50.000–200.000 Produktupdatesskalierbar

Ein erfolgreicher Importlauf und die Erreichbarkeit einer Anwendung sind unterschiedliche Messgrößen. Die Erfolgsrate ist daher keine Uptime-Angabe.

Wirtschaftlichkeit: ein Kostenmodell mit offengelegten Annahmen

Der Projektbericht vergleicht jährliche Infrastruktur- und Betriebsaufwände. Interne Betriebs- und Incident-Zeit wird mit 100 € pro Stunde bewertet. Das ist ein Rechenansatz für gebundene Kapazität und nicht automatisch eine Auszahlungseinsparung.

Tabelle 2 — Jährliche Kosten im Modell
BestandteilAlte LösungNeue Lösung
Infrastruktur und Plattformdienste2.880 €3.600 €
Angesetzte Betriebs- und Incident-Zeit20.400 €1.200 €
Summe23.280 €4.800 €
Rechnerische Differenz
18.480 € pro Jahr (rund 79 %)
Angesetzter Entwicklungsaufwand
60.000 €
Einfache Amortisation
rund 3,3 Jahre ab voller Wirksamkeit
Nicht berücksichtigt
Finanzierungskosten, zusätzliche Umsätze

Hochrechnung, kein innerhalb der 14 Betriebsmonate bereits realisierter Gesamtertrag.

04 · Grenzen

Grenzen und Abwägungen

Serverless bringt Cold Starts, Ausführungsgrenzen und verteilte Fehlersuche mit sich. Warme Instanzen verbessern das Antwortverhalten, erhöhen aber die Infrastrukturkosten. Im Kostenmodell kommt der wirtschaftliche Nutzen vor allem aus weniger Betriebsarbeit und Fehlerbehandlung.

05 · Übertragbarkeit

Übertragbarkeit auf Ihr Vorhaben

Der Ansatz passt zu entkoppelbaren Integrationsschritten mit wiederholbarer Verarbeitung. Ob er für Ihre Datenmengen und Zielsysteme sinnvoll ist, hängt von API-Limits, Wiederholbarkeit der Verarbeitung und Betriebsanforderungen ab. Er trägt nicht, wenn Verarbeitungsschritte streng sequenziell und transaktional verkettet sind.

Vollständiger Projektbericht – Architektur und Kostenansätze →

Nächster Schritt

Eigene Integrationsarchitektur bewerten lassen.

Im Architektur-Review prüfen wir Entkopplung, Fehlerbehandlung und Betriebskosten Ihrer Integrationen – mit Ausgangswerten, nicht mit Annahmen.