In der Logistik arbeitet kein System für sich. Eine einzelne Sendung durchläuft das ERP, in dem der Auftrag entsteht, das TMS, das den Transport plant, das WMS, das das Lager führt, das Portal des Frachtführers und den Scanner in der Hand der Mitarbeitenden. Sprechen diese Systeme nicht automatisch miteinander, tippt jemand Daten von Hand ab, und jede dieser Berührungen ist Verzögerung, Fehler und Kosten. Für die IT-Leitung ist Integration kein Nebenprojekt mehr, sondern das Fundament des Betriebs.
Aus unserer Erfahrung liegt das Schwierige nicht darin, zwei Systeme für eine Demo zu verbinden, sondern Dutzende solcher Verbindungen unter Last, Ausfällen und einem ständig wechselnden Kreis von Partnern am Leben zu halten. Wir haben hier keine Logistikreferenz zum Vorzeigen, aber wir haben Engineers, die seit Jahren Systemintegrationen bauen - in Industrie- und Embedded-Projekten und dort, wo wir Systeme der Enterprise-Klasse an externe Anbieter angebunden haben. Diese Kompetenz bringen wir in die Logistik ein.
Warum ist Logistik ein Geflecht von Integrationen und kein einzelnes System?
Weil der Wert in der Logistik an den Nahtstellen entsteht. Ware bewegt sich zwischen Versender, Frachtführer, Lager und Empfänger, und parallel muss sich auch ihre digitale Spur bewegen: Status, Dokumente, Position, Liefernachweis - und jeder Beteiligte betreibt sein eigenes System, Datenformat und Arbeitstempo.
Ein einziges Riesensystem löst das nicht. Stattdessen baut man eine Integrationsschicht, die Nachrichten zwischen Welten übersetzt, Ereignisse in Ordnung hält und dafür sorgt, dass ein Status aus dem Portal des Frachtführers das TMS erreicht und von dort das ERP und die Kundin. Sie entscheidet darüber, ob ein Unternehmen seinen Betrieb in Echtzeit sieht oder von Problemen zu spät erfährt.
Was ist EDI, und wie organisieren Sie Integrationen mit Partnern?
EDI ist nach wie vor die verbreitetste Art, wie Logistikpartner strukturierte Dokumente austauschen: Aufträge, Lieferavis, Lieferbestätigungen, Rechnungen. Der Haken ist, dass „EDI” kein einzelner Standard ist, sondern eine Familie von Standards und Varianten, die man in Einklang bringen muss.
In der Praxis läuft EDI-Integration für uns auf eine Handvoll wiederkehrender Aufgaben hinaus:
- Formatmapping - EDIFACT, ANSI X12 oder branchenspezifische Dateien in das Datenmodell des Kunden übersetzen und zurück,
- Nachrichtentransport - die Kanäle AS2, SFTP oder VAN bedienen, über die Partner Dateien tatsächlich senden,
- Validierung und Fehlerbehandlung - unvollständige oder nicht konforme Nachrichten abfangen, bevor sie tief ins System gelangen,
- Onboarding neuer Partner - einen weiteren Geschäftspartner schnell ergänzen, ohne die gesamte Logik neu zu schreiben.
Die Mappings müssen leicht wartbar bleiben, denn die Zahl der Partner wächst, und ihre Formate unterscheiden sich in kleinen, aber schmerzhaften Details.
Wie verbinden Sie ERP und TMS, damit Planung und Abrechnung zusammenpassen?
ERP und TMS sind die beiden Herzen eines Logistikunternehmens. Aufträge, Geschäftspartner und Abrechnungen leben im ERP, während das TMS Routen plant, Frachtführer zuordnet und die Ausführung verfolgt. Sind die beiden nicht synchron, arbeitet die Planung auf anderen Daten als die Buchhaltung, und die Kundin bekommt eine Rechnung, die nicht zur Lieferung passt.
Für uns heißt Integration von TMS und ERP, einen stimmigen Ereignisfluss zu entwerfen: Ein Auftrag aus dem ERP speist die Planung im TMS, und der erledigte Auftrag mit Kosten und Bestätigungen kehrt zur Abrechnung ins ERP zurück. Wir halten für jedes Objekt eine einzige Quelle der Wahrheit - damit eine Adresse, ein Gewicht oder eine Auftragsnummer nicht an drei Stellen ein Eigenleben führt. Meist bedeutet das eine dünne Zwischenschicht statt einer starren Punkt-zu-Punkt-Verbindung, denn dann stürzt beim Austausch eines Systems nicht die gesamte Integration ein.
Wie nutzen Sie Carrier-APIs und Logistik-Marktplätze?
Heute stellen die meisten Frachtführer und Plattformen moderne Carrier-APIs bereit und nicht nur EDI. Das eröffnet Möglichkeiten, vervielfacht aber die Zahl der zu pflegenden Verbindungen. Über diese Schnittstellen verdrahten wir meist:
- Tarifierung und Buchung von Transport in Echtzeit über mehrere Frachtführer gleichzeitig,
- Erzeugen von Etiketten und Versanddokumenten ohne manuelle Anmeldung in Portalen,
- Sendungsverfolgung über Webhooks und Statusabfragen,
- Marktplätze und Frachtbörsen, auf denen Angebot und Nachfrage nach Fracht dynamisch zusammenfinden.
Die Schwierigkeit liegt hier nicht in einer einzelnen API, sondern in ihrer Vielfalt - unterschiedliche Ratenbegrenzungen, unterschiedliche Authentifizierung, derselbe Status mit unterschiedlicher Bedeutung. Deshalb entwerfen wir ein gemeinsames Frachtführermodell und hängen neue Integrationen daran, statt jede von Grund auf zu schreiben.
Wie binden Sie Geräte, Scanner und Sensoren an die Systeme an?
Integration endet nicht bei IT-Systemen, denn Logistik geschieht in der physischen Welt. Barcodescanner, mobile Terminals, Etikettendrucker, Waagen, RFID-Tore und Sensoren im Fahrzeug erzeugen einen Ereignisstrom, der im richtigen Moment das WMS und das TMS erreichen muss.
Hier zahlt sich unsere Erfahrung aus Embedded und Industrie aus, denn Geräteintegration spielt nach anderen Regeln als Anwendungsintegration: brüchige Netze auf der Lagerfläche, hardwarespezifische Protokolle und die Tatsache, dass ein Gerät nicht auf den Server wartet. Wir bauen eine Schicht, die diese Ereignisse lokal sammelt, bei Verbindungsabbruch puffert und an die zentralen Systeme weitergibt, sobald die Verbindung zurückkehrt.
Wie machen Sie Integrationen verlässlich: Idempotenz, Wiederholungen, Queues?
Das ist der Unterschied zwischen einer Integration, die in einer Demo funktioniert, und einer, der man in der Produktion vertrauen kann. In der Logistik gehen Nachrichten verloren, Netze brechen ab, und derselbe Status kann zweimal ankommen - eine unvorbereitete Integration zeigt dann doppelte Sendungen oder verliert Liefernachweise. Deshalb legen wir sie entlang einiger Prinzipien der Belastbarkeit aus:
- Idempotenz - dieselbe Nachricht zweimal empfangen erzeugt eine Wirkung, nicht zwei,
- Queues und Broker - Ereignisse laufen über eine Queue, die den Verkehr glättet und bei einer Lastspitze keine Nachrichten verliert,
- Wiederholungen mit Backoff - ein fehlgeschlagener Aufruf wird in wachsenden Abständen wiederholt und nicht einmal pro Sekunde abgefeuert,
- eine Dead-Letter-Queue - was sich nicht verarbeiten lässt, landet zur Analyse an einem eigenen Ort, statt zu verschwinden,
- Monitoring und Alarme - das Team sieht, dass etwas hängt, bevor die Kundin anruft.
Welche Kompetenzen stellen wir für Logistikintegrationen bereit?
Für Integrationen stellen wir das Team passend zur konkreten Architektur zusammen, nicht „auf Vorrat”. In solchen Projekten besetzen wir typischerweise:
- einen Integrationsarchitekten, der Flüsse, Datenmodell und Zwischenschicht entwirft,
- Backend-Entwickler, die die Verbindungen, APIs und Mapping-Logik bauen,
- EDI-Spezialisten, die die Realität von EDIFACT, X12 und Dateitransport kennen,
- DevOps-Engineers, die Queues, Monitoring und Deployments aufsetzen.
So lernen wir Integration nicht auf Kosten des Kunden - wir kommen mit Menschen, die Systeme der Enterprise-Klasse bereits an externe Anbieter angebunden haben.
Wie machen wir das bei RITS?
Wir machen das als Nearshore-Partner aus Polen, der Kompetenz genau dort ergänzt, wo sie fehlt. Wir geben nicht vor, eine fertige Logistikumsetzung im Regal zu haben - stattdessen stellen wir Engineers mit echter Erfahrung in Systemintegrationen und Industrieprojekten, Menschen, die EDI, Carrier-APIs und Geräte in einem Projekt übernehmen können.
Meist arbeiten wir entweder als Individualsoftware, wenn die Integrationsschicht von Grund auf gebaut werden muss, oder als Team-Verstärkung, wenn der Kunde ein eigenes Team hat und eine fehlende Kompetenz schnell aufstocken will. Die Unterschiede zwischen diesen Modellen haben wir in unserem Artikel zu IT-Kooperationsmodellen dargelegt.
Womit fangen Sie bei der Integration von Logistiksystemen an?
Starten Sie damit, einen einzigen, wichtigsten Fluss zu kartieren - zum Beispiel vom Auftrag im ERP über die Planung im TMS bis zum Status vom Frachtführer und der Bestätigung für die Kundin. Dieser eine Fluss zeigt, welche Systeme sich verbinden müssen, welche Formate im Spiel sind und wo heute Daten von Hand abgetippt werden - und er bestimmt den Umfang der ersten Etappe, die Architektur der Integrationsschicht und die Rollen, die Sie brauchen. Weitere Partner und Frachtführer kommen später dazu, auf einem Fundament, das bereits funktioniert.
Sie verbinden Logistiksysteme - EDI, TMS, ERP und Carrier-APIs? Sprechen wir darüber; wir stellen Team und Integrationsarchitektur passend zu Ihrem Betrieb zusammen.