Integration von Logistik-Carriern

Problem

Ein Logistikbetreiber arbeitete mit 12 Carrier-Partnern. Jeder hatte eine andere API oder ein anderes EDI-Format für Buchungen, Statusupdates und Zustellnachweise. Das interne Team pflegte für jeden Carrier eine eigene Integration, und diese Integrationen brachen, sobald ein Carrier ein Update ausspielte. Niemand überwachte proaktiv - Betriebsmitarbeiter entdeckten Ausfälle, nicht das Tooling. Einen neuen Carrier anzubinden dauerte Wochen.

Was wir gebaut haben

Eine normalisierte Carrier-Schicht zwischen dem internen TMS und allen 12 Carriern. Das Format jedes Carriers wird in beide Richtungen übersetzt (Buchung, Status, Zustellnachweis) - hinter einer einzigen konsistenten API. Die Schicht überwacht die API-Gesundheit und Antwortzeiten der Carrier und liefert einen einheitlichen Sendungsstatus über alle Carrier hinweg in Echtzeit.

flowchart LR
C1[Carrier 1<br>REST] --> NORM[Normalisierte<br>Carrier-Schicht]
C2[Carrier 2<br>EDI] --> NORM
C3[Carrier 3-11<br>gemischt] --> NORM
C4[Carrier 12<br>SOAP] --> NORM
NORM --> TMS[Internes TMS]

Was wir verantworten

Alle 12 Integrationen, dauerhaft. Wenn ein Carrier seine API ändert, sein EDI-Schema aktualisiert oder einen Endpunkt abkündigt, erkennen und beheben wir es, bevor der Betrieb betroffen ist. Die Anbindung neuer Carrier folgt einem standardisierten Adapter-Muster: Das interne Team fordert einen Carrier an, wir liefern die Integration innerhalb des vereinbarten SLA.

Geschäftsergebnis

Das interne Team stellte die Carrier-Integrationswartung vollständig ein. Keine Notfall-Fixes mehr zu ungünstigen Zeiten, wenn ein Carrier ein Update ausspielt. Die Anbindung eines neuen Carriers ging von Wochen auf Tage zurück. Ein vermiedener Ausfall, der Same-Day-Delivery-SLAs getroffen hätte, finanzierte sechs Monate des Vertrags.