Erhalte unsere neuesten Artikel und Updates bequem per E-Mail
In vielen mittelständischen Logistik- und Speditionsunternehmen laufen TMS, ERP und Excel-Listen nebeneinander her statt miteinander. Disponenten pflegen Sendungsdaten doppelt, Buchhaltung und Lager arbeiten mit veralteten Ständen, und jede Änderung im Transportauftrag muss manuell in drei Systeme übertragen werden. Dieser Artikel zeigt, wie sich TMS, ERP und Excel über definierte Schnittstellen sauber verbinden lassen, welche Integrationsmuster sich in der Praxis bewährt haben, wo die typischen Stolperfallen liegen und mit welcher Vorgehensweise Geschäftsführer das Projekt realistisch planen können – inklusive einer durchgerechneten Beispielrechnung zu den Kosten manueller Doppelerfassung.
In vielen mittelständischen Speditionen und Industrieunternehmen ist die Systemlandschaft historisch gewachsen. Das ERP wurde vor Jahren für Finanzbuchhaltung und Materialwirtschaft eingeführt, das TMS kam später für die Transportdisposition hinzu, und Excel füllt bis heute die Lücken, die keines der beiden Systeme abdeckt – etwa Sonderauswertungen für einzelne Kunden, individuelle Frachtkostenkalkulationen oder die tägliche Tourenübersicht für die Disposition. Das Ergebnis ist eine Systemlandschaft mit drei parallelen Wahrheiten: die Auftragsdaten im ERP, die Transportstatus im TMS und die operative Feinsteuerung in einer oder mehreren Excel-Dateien, die per E-Mail zwischen Abteilungen zirkulieren.
Dieses Nebeneinander ist selten das Ergebnis einer bewussten Entscheidung, sondern eher die Summe vieler kleiner Workarounds. Ein Disponent, der schnell eine Sonderauswertung braucht, exportiert Daten aus dem TMS nach Excel. Die Buchhaltung, die Frachtkosten mit Eingangsrechnungen abgleichen muss, pflegt eine eigene Referenztabelle, weil das ERP die TMS-Referenznummern nicht kennt. Der Vertrieb kalkuliert Angebote in einer weiteren Excel-Vorlage, weil die ERP-Preisfindung zu unflexibel für individuelle Kundenkonditionen ist. Jede dieser Lösungen war für sich genommen pragmatisch – in Summe entsteht daraus aber ein fragiles Geflecht aus manuellen Übertragungen, das bei jeder Systemumstellung, jedem Mitarbeiterwechsel und jeder Volumensteigerung an seine Grenzen stößt.
Statistisch lässt sich dieser Rückstand beim Mittelstand recht klar belegen: Größere Unternehmen setzen bei der Systemintegration deutlich häufiger auf automatisierten Datenaustausch zwischen Geschäftsanwendungen als kleinere Betriebe, wie aktuelle Erhebungen zur E-Business-Integration zeigen [1][2]. Das bedeutet im Umkehrschluss nicht, dass kleinere Speditionen keine Schnittstellen brauchen – im Gegenteil, gerade bei begrenzter Personaldecke wiegt jede Stunde manueller Datenpflege besonders schwer, weil es keine zusätzliche Verwaltungsebene gibt, die den Mehraufwand abfedert.
In der Disposition zeigt sich häufig: Die Verbindung von TMS und ERP scheitert oft nicht an der Technik, sondern an uneinheitlichen Referenznummern. Wenn ein Transportauftrag im TMS eine andere ID trägt als der zugehörige Auftrag im ERP und diese Zuordnung nur in einer Excel-Tabelle dokumentiert ist, wird jede Automatisierung zur Fehlerquelle – die Systeme sprechen technisch, aber nicht semantisch dieselbe Sprache.
Für die Verbindung von TMS, ERP und Excel haben sich in der Praxis grundsätzlich drei Ansätze etabliert, die sich auch kombinieren lassen. Der erste Ansatz ist die direkte API-Integration zwischen TMS und ERP, bei der Sendungsdaten, Statusmeldungen und Frachtkosten automatisiert und in Echtzeit oder nahezu Echtzeit ausgetauscht werden. Dieser Weg ist technisch am saubersten, setzt aber voraus, dass beide Systeme über dokumentierte Schnittstellen verfügen und die Stammdaten – Kunden, Referenznummern, Kostenstellen – konsistent gepflegt sind.
Der zweite Ansatz ist der Einsatz einer Middleware oder eines Integrationslayers, der zwischen den Systemen vermittelt. Diese Zwischenschicht übernimmt die Zuordnung unterschiedlicher Datenformate, puffert Nachrichten bei Systemausfällen und ermöglicht es, weitere Systeme wie ein Lagerverwaltungssystem oder ein CRM später anzubinden, ohne die bestehenden Punkt-zu-Punkt-Verbindungen neu aufzubauen. Für Unternehmen mit mehreren Standorten oder heterogener Systemlandschaft ist dieser Weg oft der wartungsärmere, weil Änderungen an einem System nicht zwangsläufig Anpassungen an allen anderen erfordern.
Der dritte Ansatz – und in der Praxis nach wie vor der verbreitetste im Mittelstand – ist der dateibasierte Austausch über strukturierte Excel- oder CSV-Exporte, die automatisiert generiert, geprüft und importiert werden. Das ist kein Rückschritt, sondern häufig ein sinnvoller Zwischenschritt: Statt Daten manuell zwischen drei Oberflächen hin- und herzutippen, wird der Excel-Export zur definierten Schnittstelle mit festem Format, automatisierter Validierung und geplantem Import-Turnus. Excel verschwindet in diesem Modell nicht, sondern wird vom Ort der manuellen Dateneingabe zum kontrollierten Übergabepunkt zwischen Systemen.
Fraunhofer IML beschreibt in seiner Analyse zur Systemintegration in der Logistik, dass die Wahl der Architektur wesentlich von der Komplexität der Prozesslandschaft und der Zahl der beteiligten Systeme abhängt [4]. Für ein mittelständisches Unternehmen mit einem TMS, einem ERP und punktuellen Excel-Auswertungen ist häufig keine vollständige Enterprise-Service-Bus-Architektur nötig – oft reicht eine schlanke, klar abgegrenzte Integration der wichtigsten Datenflüsse: Auftragsübergabe vom ERP ins TMS, Statusrückmeldung vom TMS ins ERP, und ein automatisierter Reporting-Export für die Fälle, die weiterhin in Excel ausgewertet werden sollen.
Bei der Reihenfolge zeigt sich in der Regel: Wer zuerst versucht, alle Datenfelder zwischen TMS und ERP zu synchronisieren, statt mit den geschäftskritischen Feldern zu beginnen, verliert sich häufig in Sonderfällen. Bewährt hat sich, zunächst nur Auftragsnummer, Status, Termin und Frachtkosten zu verbinden – und Zusatzfelder wie interne Kommentare oder Sonderkonditionen bewusst später oder gar nicht zu automatisieren, wenn sie ohnehin nur für wenige Ausnahmefälle relevant sind.
Die Kosten unverbundener Systeme zeigen sich selten auf einer einzelnen Rechnung, sondern verteilen sich über viele kleine Zeitblöcke im Tagesgeschäft: die zusätzlichen Minuten für den Abgleich zwischen TMS-Status und ERP-Auftrag, die Nacharbeit, wenn eine Excel-Tabelle nicht aktuell war, die Rückfragen zwischen Disposition und Buchhaltung, weil Frachtkosten nicht automatisch zugeordnet wurden. In Summe ergibt das einen erheblichen, aber oft unsichtbaren Aufwand, der im laufenden Betrieb nicht als Projektkosten verbucht wird, sondern als ganz normale Arbeitszeit erscheint.
Um diesen Effekt greifbar zu machen, lohnt sich eine Modellrechnung mit angenommenen Werten für ein mittelständisches Speditionsunternehmen mit rund 40 Transportaufträgen pro Tag, bei dem TMS und ERP nicht direkt verbunden sind und Statusabgleiche über eine manuell gepflegte Excel-Liste erfolgen.
| Position | Wert |
|---|---|
| Transportaufträge pro Tag | 40 |
| Manuelle Übertragungszeit pro Auftrag (TMS → ERP/Excel) | 4 Minuten |
| Zeitaufwand pro Tag | ca. 2,7 Stunden |
| Arbeitstage pro Monat | 21 |
| Zeitaufwand pro Monat | ca. 56 Stunden |
| Angenommener Stundensatz Disposition/Sachbearbeitung | 32 € |
| Monatliche Kosten reine Übertragungszeit | ca. 1.790 € |
| Zusätzliche Korrekturzeit bei Übertragungsfehlern (angenommen 8 % der Fälle, 12 Minuten Nacharbeit) | ca. 13,4 Stunden/Monat |
| Kosten Fehlerkorrektur | ca. 430 €/Monat |
| Angenommene Gesamtkosten manueller Doppelerfassung pro Monat | ca. 2.220 € |
Diese Modellrechnung mit angenommenen Werten bildet nur die reine Erfassungs- und Korrekturzeit ab – nicht eingerechnet sind Folgekosten wie verspätete Rechnungsstellung durch fehlende Statusdaten, Rückfragen von Kunden zu Sendungsstatus oder die Zeit, die Führungskräfte für die Klärung von Dateninkonsistenzen aufwenden. Je nach Auftragsvolumen und Komplexität der Tarifstruktur kann der reale Aufwand also deutlich höher liegen als in diesem vereinfachten Beispiel.
Interessant ist dabei die strukturelle Dimension: Laut Eurostat setzen größere Unternehmen deutlich häufiger auf automatisierte Systemintegration als kleinere [1][2], was nahelegt, dass gerade Mittelständler mit begrenzten IT-Ressourcen überproportional von manuellen Prozessen betroffen sind – nicht weil die Notwendigkeit geringer wäre, sondern weil die Investition in Schnittstellenprojekte bislang seltener priorisiert wurde.
Bei den Fehlerquellen zeigt sich in der Regel: Besonders anfällig sind Prozesse, bei denen Statusänderungen im TMS nicht automatisch, sondern nur auf Zuruf in die Excel-Liste für die Buchhaltung übertragen werden. Wird eine Sendung im TMS als "zugestellt" markiert, aber die Information erreicht die Buchhaltung erst Tage später über eine aktualisierte Tabelle, verzögert sich die Rechnungsstellung – ein Effekt, der sich bei wachsendem Sendungsvolumen überproportional verstärkt, weil die Wahrscheinlichkeit vergessener Übertragungen mit der Zahl der Vorgänge steigt.
Ein Schnittstellenprojekt zwischen TMS, ERP und Excel sollte nicht als einmaliges Großprojekt angegangen werden, sondern als stufenweiser Prozess mit klar abgegrenzten Etappen. Der erste Schritt ist immer eine Bestandsaufnahme der tatsächlichen Datenflüsse: Welche Felder werden wirklich zwischen den Systemen benötigt, wo entstehen aktuell Excel-Zwischenschritte, und welche davon sind reine Gewohnheit statt fachlicher Notwendigkeit? Diese Analysephase wird häufig unterschätzt, dabei entscheidet sie maßgeblich über den späteren Projekterfolg – wer die Datenflüsse nicht genau kennt, baut Schnittstellen für Prozesse, die in Wirklichkeit längst anders laufen.
Im zweiten Schritt empfiehlt sich die Festlegung eines Pilotprozesses mit überschaubarem Risiko. Ein bewährtes Vorgehen ist, zunächst nur die Statusrückmeldung vom TMS an das ERP zu automatisieren – also den Vorgang, bei dem ein Transportstatus (disponiert, unterwegs, zugestellt) automatisch im ERP hinterlegt wird, ohne dass zunächst auch Stammdaten, Preise oder Sonderfelder synchronisiert werden. Dieser eng abgegrenzte erste Schritt lässt sich in der Regel schneller umsetzen, liefert schnell sichtbaren Nutzen für Disposition und Buchhaltung, und reduziert das Risiko, dass ein zu komplexes Projekt an unerwarteten Datenkonflikten scheitert.
Bei der technischen Umsetzung ist die Datenqualität der limitierende Faktor, nicht die gewählte Integrationstechnologie. Cloud-basierte Anbindungen erleichtern zwar grundsätzlich den Datenaustausch zwischen TMS und ERP, wie Erhebungen zur Cloud-Nutzung in Unternehmen zeigen [3], doch selbst die modernste API-Verbindung liefert keine verlässlichen Ergebnisse, wenn Kundennummern in beiden Systemen unterschiedlich gepflegt werden oder Referenzfelder nicht eindeutig zugeordnet sind. Vor jeder technischen Integration lohnt sich daher ein Abgleich der Stammdaten – Kunden, Lieferanten, Frachtführer, Kostenstellen –, um Dubletten und Inkonsistenzen zu bereinigen, bevor sie automatisiert repliziert werden.
Fraunhofer beschreibt in seiner Übersicht zu Logistiksoftware-Systemen die funktionalen Schnittstellen zwischen ERP, WMS, TMS und SCM als zentrale Herausforderung integrierter Logistik-IT [5]. Für mittelständische Unternehmen bedeutet das praktisch: Eine Schnittstelle zwischen TMS und ERP sollte nicht isoliert betrachtet werden, sondern im Kontext der gesamten Systemlandschaft – inklusive Lagerverwaltung, sofern vorhanden. Wer beispielsweise die Lagerverwaltung bereits automatisiert hat, sollte die TMS-ERP-Schnittstelle so gestalten, dass sie an bestehende Datenstrukturen anschließt statt eine weitere isolierte Insellösung zu schaffen.
Bei der Testphase zeigt sich häufig ein typischer Fehler: die neue Schnittstelle erst im Echtbetrieb mit vollem Auftragsvolumen zu testen. Bewährt hat sich stattdessen ein Parallelbetrieb über zwei bis vier Wochen, in dem die automatisierte Übertragung neben dem bisherigen manuellen Prozess läuft und beide Ergebnisse verglichen werden. So lassen sich Abweichungen identifizieren, bevor sich Disponenten vollständig auf die neue Datenquelle verlassen – und bevor fehlerhafte automatisierte Daten in die Rechnungsstellung oder das Reporting einfließen.
Eine verbreitete Fehlannahme bei Schnittstellenprojekten ist, dass das Ziel die vollständige Abschaffung von Excel sein müsse. In der Praxis zeigt sich jedoch, dass Excel auch nach einer gelungenen TMS-ERP-Integration eine sinnvolle Rolle behält – allerdings eine andere als zuvor. Statt als Ort der manuellen Ersterfassung dient Excel dann als Auswertungs- und Analysewerkzeug für Fragestellungen, die weder TMS noch ERP standardmäßig abdecken: individuelle Kundenreports, Ad-hoc-Kalkulationen, Abweichungsanalysen oder Planungsszenarien für den Vertrieb.
Der entscheidende Unterschied liegt darin, woher die Daten in Excel stammen. Vor der Integration wurden sie manuell eingetippt oder mühsam zusammenkopiert; nach der Integration werden sie automatisiert aus TMS und ERP exportiert oder über eine Verbindung direkt in Excel eingespeist. Damit bleibt Excel als flexibles Werkzeug erhalten, ohne dass es weiterhin als fehleranfällige Zwischenstation im operativen Datenfluss fungiert. Diese Unterscheidung – Excel als Analysewerkzeug versus Excel als manuelle Datendrehscheibe – ist für viele Geschäftsführer der entscheidende Perspektivwechsel im Projekt.
Besonders in der Disposition und im Vertrieb bleibt der Bedarf an flexiblen Auswertungen hoch. Ein TMS bildet den standardisierten Transportprozess gut ab, ist aber selten so flexibel, dass es jede kundenspezifische Auswertung ohne Zusatzaufwand liefert. Hier kann eine automatisierte Excel-Anbindung – etwa über einen geplanten Export, der täglich aktuelle Sendungsdaten in eine vordefinierte Vorlage schreibt – den Aufwand erheblich reduzieren, ohne dass eine vollständige Individualentwicklung im TMS notwendig wird.
Gleichzeitig zeigt die Praxis, dass Unternehmen, die ihre TMS-ERP-Schnittstelle sauber aufsetzen, häufig weitere Anschlussprozesse identifizieren, die von einer ähnlichen Logik profitieren. Wer beispielsweise Transportaufträge bislang manuell aus E-Mails erfasst, sieht nach einer gelungenen Systemintegration oft, dass sich auch dieser vorgelagerte Prozess automatisieren lässt, sodass Aufträge nicht erst manuell ins TMS übertragen werden müssen, bevor die Schnittstelle zum ERP überhaupt greift. Ähnlich verhält es sich mit nachgelagerten Prozessen: Wenn Statusdaten zuverlässig zwischen TMS und ERP fließen, wird auch die automatisierte Avisierung von Sendungsstatus an Kunden technisch einfacher, weil die zugrunde liegenden Daten bereits konsistent vorliegen.
Auf konsistenten Auftrags- und Sendungsdaten aufbauend lässt sich auch die Tourenplanung und Disposition automatisieren, statt Routen weiterhin manuell zusammenzustellen.
Beim Rollout zeigt sich häufig: Mitarbeitende, die jahrelang mit ihrer eigenen Excel-Logik gearbeitet haben, akzeptieren eine neue automatisierte Datenquelle in der Regel schneller, wenn ihre bestehenden Auswertungsvorlagen weiterverwendet werden können und lediglich die Datenquelle wechselt – statt ihnen ein komplett neues Reporting-Format vorzuschreiben. Diese Kontinuität in der Oberfläche, bei gleichzeitigem Wechsel der Datenherkunft, senkt den Widerstand gegen die Umstellung spürbar.
Eine Schnittstelle zwischen TMS, ERP und Excel ist selten ein einmaliges Projekt, sondern eine Infrastrukturentscheidung, die über Jahre Bestand haben sollte. Deshalb lohnt sich vor der technischen Umsetzung ein Blick auf die absehbare Entwicklung: Wächst das Sendungsvolumen, werden neue Standorte oder Kunden mit eigenen Anforderungen hinzukommen, oder ist ein Wechsel des TMS oder ERP in den kommenden Jahren wahrscheinlich? Diese Fragen beeinflussen, ob eine schlanke Punkt-zu-Punkt-Verbindung ausreicht oder ob eine Middleware-Architektur sinnvoller ist, die spätere Systemwechsel ohne kompletten Neubau der Schnittstellen ermöglicht.
Der BVL-Studienbericht zu Trends und Strategien in Logistik und Supply Chain Management betont, dass Systemintegration und Datenverfügbarkeit zu den zentralen Handlungsfeldern für die kommenden Jahre zählen [6]. Für mittelständische Speditionen und Logistikdienstleister bedeutet das, dass die Investition in saubere Schnittstellen nicht als IT-Kostenstelle, sondern als Voraussetzung für die weitere Skalierung des Geschäfts zu betrachten ist. Ein Unternehmen, das bei steigendem Auftragsvolumen weiterhin auf manuelle Excel-Übertragung setzt, stößt nicht nur an Kapazitätsgrenzen in der Disposition, sondern riskiert auch eine steigende Fehlerquote, die sich direkt auf Kundenbeziehungen auswirkt – etwa durch falsche Statusmeldungen oder verzögerte Rechnungsstellung.
Bei der Priorisierung hilft ein einfacher Grundsatz: Zuerst die Prozesse verbinden, die das höchste Volumen und die höchste Fehleranfälligkeit gleichzeitig aufweisen. Das ist in den meisten Speditionen die Kombination aus Statusrückmeldung und Frachtkostenabgleich, seltener die Stammdatensynchronisation, die zwar wichtig, aber meist weniger fehleranfällig im Tagesgeschäft ist. Wer diese Priorisierung sauber vornimmt, erzielt mit begrenztem Aufwand den größten Effekt auf die tägliche Arbeitsbelastung der Disposition und Buchhaltung.
Bei der Governance zeigt sich häufig: In Unternehmen, die ihre Schnittstellen langfristig stabil betreiben, gibt es fast immer eine benannte Verantwortlichkeit für die Datenqualität – eine Person oder ein kleines Team, das Stammdatenänderungen prüft, bevor sie produktiv werden, und das bei Auffälligkeiten in den automatisierten Datenflüssen als erste Anlaufstelle dient. Fehlt diese Verantwortlichkeit, verwildern Stammdaten über die Zeit erneut, und die Schnittstelle liefert zunehmend fehlerhafte Ergebnisse, obwohl die Technik selbst unverändert funktioniert. Die Investition in eine funktionierende Schnittstellenarchitektur ist damit nicht nur ein technisches, sondern auch ein organisatorisches Vorhaben, das über die reine Implementierung hinaus kontinuierliche Pflege erfordert.
Für die konkrete Umsetzung gilt: Die Kosten eines solchen Projekts hängen wesentlich vom Umfang der zu verbindenden Prozesse, der vorhandenen Systemlandschaft, der Datenqualität und dem gewünschten Individualisierungsgrad ab. Eine belastbare Einschätzung lässt sich erst nach einer Analyse der konkreten Ausgangslage und einem Erstgespräch treffen, in dem die vorhandenen Systeme, Datenflüsse und Prioritäten gemeinsam durchgegangen werden.
Nein, Excel behält in der Regel eine sinnvolle Rolle als Auswertungswerkzeug. Der Unterschied liegt darin, dass Excel nach einer gelungenen Integration Daten automatisiert aus TMS und ERP bezieht, statt als Ort der manuellen Ersterfassung zu dienen – die fehleranfällige Doppelpflege entfällt, die Flexibilität für individuelle Auswertungen bleibt erhalten.
Das hängt stark von der Komplexität der Datenflüsse und der Zahl der beteiligten Systeme ab. Ein eng abgegrenzter Pilotprozess, etwa nur die Statusrückmeldung vom TMS ans ERP, lässt sich üblicherweise deutlich schneller umsetzen als eine vollständige Synchronisation aller Datenfelder; eine belastbare Zeiteinschätzung ergibt sich erst nach Analyse der konkreten Systemlandschaft.
Priorität haben die Datenfelder mit dem höchsten Volumen und der höchsten Fehleranfälligkeit im Tagesgeschäft – typischerweise Auftragsstatus, Termine und Frachtkosten. Stammdaten wie Kunden- oder Frachtführerinformationen sind zwar wichtig, verursachen im laufenden Betrieb aber meist seltener konkrete Fehler als fehlende oder verspätete Statusübertragungen.
Ja, ein strukturierter, automatisierter Excel- oder CSV-Austausch kann ein sinnvoller und oft ausreichender Zwischenschritt sein, solange Format, Validierung und Import-Turnus klar definiert sind. Wichtig ist, dass der Export nicht mehr manuell zusammengestellt wird, sondern als feste, automatisierte Schnittstelle zwischen den Systemen fungiert.
Schnittstellen zwischen TMS, ERP und Excel analysieren lassen
Abdullah hat Wirtschaftsinformatik (B.Sc.) studiert und verantwortet bei Socialeap den Bereich Prozessautomatisierung. Jede Lösung wird zu 100 % auf den jeweiligen Kunden zugeschnitten – kein Standardpaket, sondern Systeme, die exakt auf die bestehenden Abläufe im Unternehmen passen. Kunden sparen dadurch im Durchschnitt 10 Stunden pro Woche. Abdullah ist bei jedem Automatisierungsprojekt persönlich am Aufbau beteiligt. Auf diesem Blog schreibt er über Automatisierung, Prozessoptimierung und die Frage, wo Zeit im Tagesgeschäft tatsächlich verloren geht.
