Historisch ist das Unternehmen in Ulm entstanden und hat seinen Ausgangspunkt in einem sehr konkreten Problem der Industrie: Wie vergibt man Transporte an die richtige Spedition, ohne sie einzeln anzurufen? Aus dieser Frage ist über Jahre ein Netzwerk gewachsen, in dem sehr viele Transportdienstleister bereits angebunden sind und mit gängigen Verladern zusammenarbeiten. Genau dieser Netzwerkeffekt ist der eigentliche Kern des Angebots – nicht eine einzelne Funktion, sondern die Tatsache, dass die Gegenseite schon da ist.
Seit einigen Jahren gehört das Unternehmen zur US-amerikanischen Trimble-Gruppe, einem Anbieter, der unter anderem in der Bau-, Landwirtschafts- und Transporttechnik aktiv ist. Für die fachliche Bewertung ändert das zunächst wenig: Die Prozesse, die Bedienlogik und die europäische Ausrichtung sind erkennbar erhalten geblieben. Für die datenschutzrechtliche Bewertung ändert es dagegen viel, weil eine Konzernmutter außerhalb der EU eine eigene Prüfung notwendig macht. Wir behandeln das ausführlich in Kapitel 09.
Ein klassisches Transportmanagementsystem läuft im eigenen Haus oder in einer eigenen Cloud-Instanz und dient dazu, die eigenen Transportprozesse zu planen und zu dokumentieren. Es kennt die eigenen Aufträge, die eigenen Stammdaten und die eigenen Kosten. Was außerhalb passiert, muss über Schnittstellen hineingeholt werden. Eine Plattform wie Transporeon dreht diese Perspektive: Sie ist ein gemeinsamer Raum, in dem mehrere Unternehmen an derselben Transaktion arbeiten. Der Spediteur sieht die Ausschreibung, ohne dass sie ihm per Mail zugestellt werden muss. Der Fahrer bucht ein Zeitfenster, ohne dass jemand im Werk einen Kalendereintrag pflegt.
Diese Unterscheidung ist keine Wortklauberei, sondern hat handfeste Folgen. Erstens: Der Nutzen hängt davon ab, ob die eigenen Dienstleister mitmachen. Zweitens: Prozesse werden über Unternehmensgrenzen hinweg standardisiert, was Disziplin verlangt und individuelle Sonderwege erschwert. Drittens: Daten entstehen nicht nur im eigenen Haus, sondern in einer Umgebung, die mehrere Parteien nutzen – mit allen Fragen zur Sichtbarkeit, Trennung und Weiterverwendung, die daraus folgen.
Die typische Anwenderseite sind produzierende Unternehmen, Handelsunternehmen mit eigenem Werk- oder Lagerverkehr und Logistikdienstleister mit eigenem Transportbedarf. Gemeinsam ist ihnen, dass sie Transporte einkaufen statt selbst zu fahren, mehrere Dienstleister parallel beauftragen und an ihren Standorten Rampen bewirtschaften müssen. Sobald ein Unternehmen mehr als eine Handvoll Speditionen einsetzt und mehr als eine Rampe betreibt, entsteht der Koordinationsaufwand, für den solche Plattformen gebaut sind.
Auf der Gegenseite stehen Transportdienstleister, die von Verladern eingeladen werden. Für sie ist die Plattform Pflicht und Chance zugleich: Pflicht, weil der Auftraggeber es verlangt, Chance, weil sie über einen Zugang mehrere Kunden bedienen können. Wer als Mittelständler eine Plattformentscheidung trifft, sollte diese Doppelrolle im Blick behalten – sie erklärt, warum Onboarding-Gespräche mit Speditionen ganz unterschiedlich verlaufen.
In vielen mittelständischen Unternehmen ist der Transporteinkauf ein Bereich mit erstaunlich wenig Systemunterstützung. Es gibt gewachsene Beziehungen, Preislisten in Tabellen, Absprachen am Telefon und eine Rechnungsprüfung, die im Zweifel nicht stattfindet, weil niemand die Zeit hat. Gleichzeitig ist Transport ein wesentlicher Kostenblock und ein Risikofaktor für Liefertermine. Eine Plattform bringt hier vor allem Struktur: nachvollziehbare Vergaben, dokumentierte Konditionen, verlässliche Zeitfenster und eine Datenbasis, die Diskussionen versachlicht.
Grob lassen sich vier Bereiche unterscheiden, die in der Praxis unterschiedlich stark genutzt werden. Der erste betrifft die Beschaffung von Transportleistung: Ausschreibungen über längere Zeiträume, Rahmenvergaben, Spotanfragen für einzelne Ladungen. Der zweite betrifft die Ausführung: Wer bekommt den konkreten Transport, welches Zeitfenster gilt an welcher Rampe, welche Dokumente werden benötigt. Der dritte betrifft die Sichtbarkeit: Wo befindet sich die Sendung, welche Ankunftszeit ist realistisch, wo droht eine Abweichung. Der vierte betrifft das Geld: Was war vereinbart, was wurde geleistet, was wird abgerechnet.
Bezeichnungen, Lizenzschnitte und Paketierungen ändern sich im Laufe der Zeit und unterscheiden sich je nach Vertrag. Welche Funktionen konkret in welchem Baustein enthalten sind, ist beim Anbieter zu prüfen – wir beschreiben hier die fachlichen Bereiche, nicht die aktuelle Produktbroschüre.
Wer eine solche Plattform bewertet, sollte den Funktionsvergleich nicht überschätzen. Zeitfenster buchen, Aufträge vergeben, Status anzeigen – das können viele Systeme. Der Unterschied liegt darin, wie viel Aufwand entsteht, bis die Gegenseite tatsächlich mitmacht. Ein etabliertes Netzwerk bedeutet, dass ein erheblicher Teil der eigenen Speditionen bereits einen Zugang hat, das System kennt und Prozesse dafür eingerichtet hat. Das verkürzt die Einführung erheblich und senkt den Widerstand.
Umgekehrt entsteht daraus eine Abhängigkeit, die man ehrlich benennen sollte. Prozesse, die über eine Plattform laufen, sind schwerer zu verlagern als Prozesse in einem eigenen System, weil ein Wechsel nicht nur die eigene IT betrifft, sondern alle angebundenen Partner. Diese Wechselkosten sind ein legitimer Teil des Geschäftsmodells, sollten aber bei der Vertragsgestaltung berücksichtigt werden – insbesondere bei Datenexport, Laufzeiten und Preisanpassungsklauseln.
Die Zugehörigkeit zu einem größeren Technologiekonzern hat zwei Seiten. Positiv ist die breitere Basis: Ein Konzern mit Aktivitäten in Telematik, Flottentechnik und Transportsoftware kann Bausteine zusammenführen, die vorher getrennt eingekauft werden mussten – etwa Fahrzeugdaten, Spediteursysteme und Verladerplattform. Für Verlader kann das bedeuten, dass Positionsdaten leichter verfügbar werden.
Kritisch zu betrachten ist die strategische Abhängigkeit von Konzernentscheidungen. Produktlinien werden zusammengelegt, Roadmaps priorisiert, Preismodelle harmonisiert. Für einen Mittelständler heißt das: Die Frage nach der langfristigen Perspektive eines Moduls gehört in das Anbietergespräch, ebenso wie die Frage, welche Teile des Portfolios als strategisch gelten. Belastbare Aussagen über Marktanteile oder Nutzerzahlen machen wir bewusst nicht – solche Zahlen sind unterschiedlich abgegrenzt und schnell veraltet.
Transportleistung wird auf unterschiedlichen Zeithorizonten eingekauft. Über längere Zeiträume laufen Ausschreibungen, in denen Relationen, Mengengerüste und Serviceanforderungen beschrieben und von mehreren Dienstleistern bepreist werden. Das Ergebnis sind Konditionen und eine Rangfolge, wer welche Relation zu welchem Preis bedient. Im Tagesgeschäft entstehen daraus automatisierte Vergaben: Der Transportbedarf wird dem erstplatzierten Dienstleister angeboten, der innerhalb einer definierten Frist annimmt oder ablehnt; bei Ablehnung rückt der nächste nach.
Dieses Verfahren ist der eigentliche Effizienzgewinn, weil es die Telefonkette ersetzt. Es setzt allerdings voraus, dass die Rangfolgen sauber gepflegt sind und dass Ablehnungen Konsequenzen haben. In Projekten sehen wir häufig, dass die Automatik technisch funktioniert, aber fachlich unterlaufen wird: Ein Disponent vergibt weiterhin telefonisch, weil er einen bestimmten Fahrer kennt. Damit fällt die Datenbasis zusammen, auf der die nächste Ausschreibung aufbauen soll.
Für kurzfristigen Bedarf, für Sonderfahrten und für Relationen ohne Rahmenvertrag existieren Spotverfahren: Eine Anfrage geht an mehrere Dienstleister, Angebote kommen strukturiert zurück, die Vergabe erfolgt nachvollziehbar. Wichtig ist hier die Disziplin bei der Beschreibung des Transports. Unpräzise Angaben zu Ladehilfsmitteln, Abmessungen, Temperaturanforderungen oder Ladestellenbedingungen führen zu Angeboten, die nicht vergleichbar sind, und später zu Nachforderungen.
Hinter der automatischen Vergabe steht ein Regelwerk, das im Projekt aufgebaut werden muss. Es beantwortet Fragen wie: Welcher Dienstleister ist für welche Relation, welches Ladungsprofil und welchen Zeitraum vorgesehen? Was passiert bei Ablehnung oder Fristablauf? Welche Kriterien außer dem Preis zählen – Termintreue, Kapazitätszusage, Ausrüstung, Nachhaltigkeitsanforderungen? Wie werden Mengenzusagen über das Jahr eingehalten, damit ein Dienstleister nicht rechnerisch benachteiligt wird?
Der Aufbau dieses Regelwerks ist Beratungs- und keine Konfigurationsaufgabe. Er zwingt ein Unternehmen, implizite Entscheidungen explizit zu machen. Genau das ist wertvoll und gleichzeitig der Punkt, an dem Projekte stocken, weil niemand entscheiden möchte. Aus unserer Erfahrung lohnt es sich, mit einem bewusst einfachen Regelwerk zu starten und es nach einigen Wochen anhand echter Ablehnungsquoten zu verfeinern.
Das Zeitfenstermanagement ist für viele Anwender der Baustein mit dem schnellsten sichtbaren Effekt. Statt dass Lkw unkoordiniert eintreffen und Wartezeiten sowie Standgelder entstehen, buchen Spediteure oder Fahrer definierte Slots an einer Rampe. Das Werk kann Kapazitäten je Rampe, Ladungsart und Tageszeit hinterlegen, Vorlaufzeiten definieren und Pufferzeiten einplanen. Ergänzend lassen sich Wartebereiche steuern und Fahrzeuge in einer Reihenfolge aufrufen.
Die Wirkung entsteht nicht durch die Buchungsfunktion, sondern durch die Bewirtschaftungslogik dahinter. Ein Slotplan, der die realen Handlingzeiten nicht abbildet, produziert entweder Leerlauf oder chronische Verspätung. Deshalb beginnt ein sinnvolles Projekt mit einer Messung: Wie lange dauert Entladung tatsächlich, je Ladungsart, je Rampe, je Tageszeit? Ohne diese Grundlage wird ein Zeitfenstersystem zur Quelle neuer Konflikte, weil Spediteure sich an Fenster halten, die im Werk nicht einzuhalten sind.
Ein zweiter Erfolgsfaktor ist die Behandlung von Abweichungen. Was passiert, wenn ein Fahrer zu früh oder zu spät kommt? Gibt es eine Kulanzzone, eine automatische Umbuchung, eine Priorisierung nach Ladungsart? Wer diese Regeln nicht vorab festlegt, überlässt sie dem Pförtner – und damit dem Zufall.
Sichtbarkeit entsteht aus mehreren Quellen: Telematiksystemen der Fuhrunternehmen, mobilen Anwendungen für Fahrer, Statusmeldungen aus Spediteurssystemen und Ereignissen aus dem Zeitfenstersystem selbst. Aus diesen Daten werden Positionen, Statuswechsel und Ankunftsprognosen abgeleitet. Der praktische Nutzen liegt weniger in der Landkarte als in der Ausnahmesteuerung: Das System soll melden, wenn eine Zusage nicht mehr zu halten ist, und zwar früh genug, um zu reagieren.
In der Umsetzung ist die Datenabdeckung die zentrale Hürde. Große Fuhrunternehmen mit moderner Telematik sind schnell angebunden; kleine Subunternehmer, wechselnde Fahrer und Fahrzeuge ohne geeignete Ausrüstung sind es nicht. Realistisch ist ein gemischtes Bild, in dem ein Teil der Transporte präzise sichtbar ist und ein anderer Teil über manuelle Meldungen läuft. Wer im Projekt eine flächendeckende Sichtbarkeit als Voraussetzung setzt, wird enttäuscht; wer sie als Ausbaupfad plant, kommt weiter.
Die Abrechnung ist der Baustein, der am unmittelbarsten auf das Ergebnis wirkt. Wenn Konditionen, tatsächlich erbrachte Leistung und Rechnungsposition im gleichen System liegen, lässt sich maschinell prüfen, ob eine Rechnung der Vereinbarung entspricht. Abweichungen bei Zuschlägen, Wartezeiten, Palettentausch oder Mautanteilen werden auffällig, ohne dass jemand Belege vergleichen muss. Optional lassen sich Selbstabrechnungsverfahren aufbauen, bei denen der Verlader die Gutschrift erzeugt.
Voraussetzung ist eine saubere Kondition. Freitextliche Preisabsprachen, Sonderregeln aus Telefonaten und historische Ausnahmen lassen sich nicht maschinell prüfen. Die Einführung dieses Bausteins wirkt deshalb wie eine Inventur des Transporteinkaufs – oft unangenehm, meist lohnend. Konkrete Einsparquoten nennen wir bewusst nicht, weil sie vollständig vom Ausgangszustand abhängen: Wer heute gar nicht prüft, findet mehr als jemand mit funktionierender Kontrolle.
Prognosen zur Entwicklung von Frachtraten sollen dem Einkauf helfen, den Zeitpunkt und die Struktur einer Ausschreibung besser zu wählen. Wenn zu erwarten ist, dass Kapazität knapper wird, ist ein längerer Rahmenvertrag attraktiver; wenn Entspannung erwartet wird, lohnt mehr Spotanteil. Die Aussagekraft solcher Prognosen hängt von der Datenbasis und der Ähnlichkeit der Relationen ab. Für stark frequentierte Standardrelationen sind sie in der Regel belastbarer als für Spezialverkehre.
Aus unserer Sicht ist der wichtigste Nutzen nicht die Punktprognose, sondern die Versachlichung. Ein Einkäufer, der mit einer marktbasierten Einordnung in ein Gespräch geht, argumentiert anders als einer, der nur die letzte Rechnung kennt. Zahlen zur Prognosegüte nennen wir nicht – sie sind methodisch schwer vergleichbar und beim Anbieter mit Bezug auf das eigene Relationenprofil zu erfragen.
Unter Begriffen wie „autonome Beschaffung“ wird zusammengefasst, dass Vergabeentscheidungen ohne manuellen Eingriff getroffen werden: Das System wählt anhand von Regeln, Konditionen, Kapazitätszusagen und Marktlage den Dienstleister und spielt bei Ablehnung die nächste Option an. Ergänzend können Spotanfragen automatisch ausgelöst werden, wenn kein Rahmenpartner zusagt, und Angebote automatisch bewertet werden.
Der Nutzen ist erheblich, sobald das Volumen stimmt: Die Bearbeitung wandert von der Einzelentscheidung zur Ausnahmebehandlung. Die Voraussetzungen sind aber streng. Man braucht saubere Konditionsdaten, klare Ablehnungsfolgen, verbindliche Fristen und eine Organisation, die Automatikentscheidungen akzeptiert. Ein Regelwerk mit vielen Ausnahmen ist keine „Automatisierung“, sondern eine verlagerte Handarbeit. Deshalb empfehlen wir, Automatisierungsgrade schrittweise zu erhöhen und den Anteil manueller Eingriffe als Kennzahl zu führen.
Ankunftsprognosen sind der bekannteste KI-Anwendungsfall in der Transportsichtbarkeit. Aus Position, Fahrtverlauf, Verkehrslage, Lenk- und Ruhezeiten sowie historischen Abwicklungszeiten an Ladestellen wird eine erwartete Ankunft berechnet. Der Wert steigt mit der Qualität der Eingangsdaten und mit der Berücksichtigung der Randbedingungen: Eine Prognose, die die Wartezeit an der Zielrampe ignoriert, ist für die Werkslogistik kaum brauchbar.
Anomalieerkennung geht einen Schritt weiter und meldet Muster, die von der Erwartung abweichen – ein Fahrzeug, das ungewöhnlich lange steht, eine Relation mit auffällig häufigen Ablehnungen, ein Dienstleister mit systematisch abweichenden Abrechnungspositionen. Fachlich ist das der interessanteste Bereich, weil hier Probleme sichtbar werden, nach denen niemand gesucht hat. Praktisch entscheidet die Alarmqualität über den Nutzen: Zu viele Meldungen führen dazu, dass alle ignoriert werden.
Kein Algorithmus ersetzt eine belastbare Kapazitätszusage. Wenn im Markt keine Fahrzeuge verfügbar sind, optimiert das System die Verteilung des Mangels, nicht seine Behebung. Ebenso ersetzt keine Prognose die Beziehungspflege zu Dienstleistern, von der im Engpass mehr abhängt als von jeder Rangfolge. Und keine Automatik korrigiert schlechte Stammdaten: Falsche Ladestellenzeiten, unklare Ladehilfsmittel oder veraltete Ansprechpartner erzeugen Fehler, die sich durch den gesamten Prozess ziehen.
In den meisten Fällen entsteht der Transportbedarf im Geschäftssystem: aus Lieferungen, Bestellungen, Umlagerungen oder Fertigungsaufträgen. Von dort müssen Transportanforderungen mit allen relevanten Attributen an die Plattform übergeben werden – Ladestelle, Entladestelle, Zeitfenster, Gewicht, Volumen, Ladehilfsmittel, Warenbeschreibung, Gefahrgutkennzeichen, Referenznummern. Zurück kommen Vergabeergebnis, Dienstleister, Kennzeichen, Statusereignisse und Abrechnungsdaten.
Für SAP-Umgebungen ist dieser Weg gut eingespielt und über Standardschnittstellen abbildbar; für andere ERP-Systeme im Mittelstand ist er meist über Datei-, EDI- oder API-Verfahren möglich. Der Aufwand liegt selten in der Technik, sondern in der Datenqualität. Wenn Adressen unvollständig, Ladestellen nicht eindeutig oder Gewichte geschätzt sind, wird die Plattform diese Schwächen sichtbar machen. Das ist eine Chance, aber sie kostet im Projekt Zeit, die eingeplant werden muss.
Eine zweite Grundsatzfrage betrifft die Führung. Welches System hält die Wahrheit über Transportstatus und Frachtkosten? Wir empfehlen eine klare Antwort vor dem ersten Mapping. Doppelte Führung erzeugt Abstimmungsprobleme, die später kaum zu bereinigen sind.
Viele Unternehmen haben bereits ein Transportmanagementsystem – aus einer ERP-Suite, von einem Logistikspezialisten oder als Speditionssoftware. Die Plattform ersetzt es nicht zwangsläufig, sondern ergänzt es an der Außenkante: Das TMS plant Touren, Sendungsbildung und Kapazitäten, die Plattform organisiert Vergabe, Zeitfenster, Statusrückfluss und Abrechnung mit den externen Partnern. Diese Arbeitsteilung funktioniert gut, wenn die Schnittstellenverantwortung klar ist.
Kritisch wird es bei Funktionsüberlappungen. Beide Systeme können Frachtkosten kalkulieren, beide können Status führen, beide können Dienstleister verwalten. Ohne bewusste Entscheidung entsteht eine Doppelpflege, die im Alltag scheitert. In unseren Projekten arbeiten wir mit einer einfachen Regel: Ein Datenobjekt hat genau ein führendes System, alle anderen sind Konsumenten. Abweichungen davon sind zu begründen und zu dokumentieren.
Auf der Dienstleisterseite gibt es mehrere Anbindungstiefen. Die einfachste ist der Browserzugang: Der Spediteur arbeitet direkt in der Plattform. Die nächste Stufe sind Schnittstellen zwischen Plattform und Speditionssoftware, sodass Aufträge automatisch im System des Dienstleisters landen und Status automatisch zurückfließen. Die dritte Ebene betrifft Fahrzeugdaten: Telematiksysteme liefern Positionen, mobile Anwendungen liefern Ereignisse und Belege.
Für die Anbindung sind sowohl klassische EDI-Verfahren als auch moderne Programmierschnittstellen üblich. Welche Formate und welche konkreten Telematikanbieter unterstützt werden, ist beim Anbieter zu prüfen und ändert sich über die Zeit. Wichtig ist die Frage nach dem Aufwand pro Partner: Eine Anbindung, die je Spediteur ein individuelles Projekt bedeutet, skaliert im Mittelstand nicht. Deshalb ist die Zahl der bereits vorhandenen Standardanbindungen ein legitimes Auswahlkriterium – ohne dass wir hier Zahlen nennen.
Drei Anschlüsse tauchen in Projektplänen selten auf und verursachen später Arbeit. Erstens die Buchhaltung: Wenn die Rechnungsprüfung in der Plattform stattfindet, muss das Ergebnis nachvollziehbar in die Finanzbuchhaltung fließen, inklusive Kontierung und Belegverweis. Zweitens die Zoll- und Außenhandelsabwicklung: Bei grenzüberschreitenden Transporten müssen Dokumente und Daten zusammenpassen, was eine Abstimmung mit der Zollsoftware bedeutet. Drittens die Lagerverwaltung: Zeitfenster ohne Kopplung an die Kommissionierfortschritte erzeugen Slots, die im Lager nicht bedient werden können.
Diese Anbieter sind vom Sichtbarkeitsproblem her gewachsen. Ihr Kern ist die Zusammenführung von Positions- und Statusdaten aus vielen Quellen über viele Verkehrsträger hinweg, häufig mit starkem Fokus auf internationale Ketten inklusive See- und Luftfracht. Wer vor allem wissen will, wo Ware auf einer globalen Lieferkette steckt, findet dort ausgeprägte Stärken.
Der Unterschied zur Transportplattform liegt in der Transaktion. Visibility-Anbieter beobachten primär, was ohnehin passiert; eine Vergabeplattform organisiert, dass es passiert. Zeitfenstermanagement, Ausschreibungslogik und Frachtkostenabrechnung sind bei den Visibility-Spezialisten je nach Anbieter unterschiedlich ausgebaut, teils über Zukäufe ergänzt. Für ein Unternehmen mit vielen Rampen und vielen Straßenverkehren im europäischen Raum ist eine transaktionsorientierte Plattform meist näher am Bedarf; für ein Unternehmen mit globalen Containerströmen kann die Gewichtung umgekehrt sein.
Eine ehrliche Einordnung schließt ein, dass sich die Kategorien annähern. Visibility-Anbieter erweitern in Richtung Beschaffung und Zeitfenster, Plattformanbieter erweitern in Richtung multimodaler Sichtbarkeit. Wer heute vergleicht, sollte deshalb nicht die Kategorie bewerten, sondern die konkrete Abdeckung der eigenen Verkehre und die Anbindungstiefe der eigenen Dienstleister prüfen.
Auf der anderen Seite stehen Transportmanagementsysteme, die aus der Planung kommen: Sendungsbildung, Tourenbildung, Kapazitätsplanung, Frachtkalkulation, Auftragsdokumentation. Diese Systeme sind stark, wenn im eigenen Haus geplant wird und wenn eigene Fahrzeuge oder eigene Verkehre zu disponieren sind. Ihre Schwäche liegt traditionell in der Außenkante: Die Zusammenarbeit mit vielen externen Dienstleistern muss über Schnittstellen und Portale hergestellt werden, die jeder Anwender selbst aufbauen muss.
Umgekehrt sind Plattformen schwächer, wo tiefe Planungslogik verlangt wird. Wer komplexe Tourenoptimierung mit Zeitfenstern, Kapazitätsrestriktionen und Mehrtagesplanung braucht, wird das eher in einem Planungssystem finden. In der Praxis führt das häufig zu einer Kombination beider Welten, was die Frage nach der Systemführung wieder in den Mittelpunkt rückt.
Eine dritte Gruppe sind offene Frachtbörsen und digitale Speditionen. Frachtbörsen dienen dem kurzfristigen Kapazitätsausgleich; ihr Modell ist der anonyme Markt, nicht der geordnete Rahmenvertrag. Digitale Speditionen treten selbst als Dienstleister auf und liefern Transparenz als Teil ihrer Leistung. Beide Modelle können sinnvolle Ergänzungen sein, ersetzen aber keine Prozessplattform, weil sie die eigene Vergabelogik und die eigenen Rampenprozesse nicht abbilden.
Für eine belastbare Auswahl empfehlen wir, nicht Funktionslisten zu vergleichen, sondern drei konkrete Szenarien aus dem eigenen Betrieb durchzuspielen: eine typische Rahmenvergabe, einen Tag im Wareneingang mit realer Slotbelastung und eine strittige Frachtrechnung. Diese drei Fälle trennen Anbieter zuverlässiger als jede Bewertungsmatrix.
Die Plattform wird als Dienst bereitgestellt; Anwender arbeiten über den Browser, Systeme über Schnittstellen. Eine eigene Serverlandschaft entfällt, ebenso das Einspielen von Aktualisierungen. Im Gegenzug gibt man Kontrolle über Änderungszeitpunkte ab: Neue Versionen kommen, wenn der Anbieter sie ausrollt. Für Unternehmen mit strengen Freigabeprozessen ist das ein Thema, das man früh mit der IT klären sollte, inklusive Testumgebungen und Ankündigungsfristen.
Technisch relevant sind auf Kundenseite vor allem drei Punkte: eine belastbare Schnittstellenanbindung an das führende System, ein Konzept für Benutzerverwaltung und Berechtigungen samt Anbindung an das eigene Identitätsmanagement, und eine Regelung für mobile Nutzung an Pforte, Rampe und Lager. Der dritte Punkt wird oft unterschätzt: Ein Zeitfenstersystem, das an der Pforte nur auf einem Bürorechner erreichbar ist, wird umgangen.
Der kritische Pfad verläuft über die Dienstleister. Jeder Spediteur braucht einen Zugang, geschulte Mitarbeiter, eine interne Zuständigkeit und im Idealfall eine Schnittstelle zu seiner eigenen Software. Große Dienstleister sind meist geübt, weil sie für andere Verlader schon auf der Plattform arbeiten. Kleine Fuhrunternehmen und Subunternehmer sind es nicht, und genau dort entstehen Reibungen: fehlende Ansprechpartner, keine IT-Ressourcen, Sorge vor zusätzlicher Bürokratie.
Bewährt hat sich ein gestaffeltes Vorgehen. Man beginnt mit den Dienstleistern, die den größten Anteil des Volumens abdecken und technisch am besten aufgestellt sind, sammelt dort Erfahrungen und nutzt die Ergebnisse als Argument für die nächste Gruppe. Dazu gehört klare Kommunikation: Was ändert sich, ab wann ist es verbindlich, welche Unterstützung gibt es, welchen Nutzen hat der Dienstleister selbst – etwa weniger Wartezeit an der Rampe und weniger Rückfragen zu Rechnungen.
Widerstand gegen eine Transportplattform kommt selten aus Technikangst. Er kommt daher, dass sichtbare Prozesse Verantwortung erzeugen. Ein Disponent, der bisher flexibel entscheiden konnte, arbeitet künftig nach Regeln, deren Ergebnis messbar ist. Ein Werkleiter, dessen Wartezeiten dokumentiert werden, muss sie erklären. Das ist unbequem und gleichzeitig der eigentliche Zweck.
Gute Projekte nehmen diesen Punkt vorweg. Sie erklären, wofür Kennzahlen verwendet werden und wofür nicht, sie geben der Disposition definierte Eingriffsmöglichkeiten für begründete Ausnahmen, und sie beziehen die Betroffenen in die Regelgestaltung ein. Wo Betriebsräte zuständig sind, gehört die Beteiligung früh in den Plan – insbesondere dort, wo Daten anfallen, die auf Personen zurückführbar sind. Dazu mehr in Kapitel 09.
Vier Merkmale sprechen für eine Plattformlösung, unabhängig von der Umsatzgröße. Erstens die Anzahl der Dienstleister: Wer regelmäßig mit mehreren Speditionen arbeitet und Transporte einzeln zuteilt, hat ein Koordinationsproblem. Zweitens die Rampensituation: Wer Wartezeiten, Standgelder oder chaotische Anlieferspitzen kennt, hat ein Slotproblem. Drittens die Rechnungslage: Wer Frachtrechnungen nicht systematisch prüft, hat ein Kontrollproblem. Viertens die Auskunftslast: Wer täglich Anrufe zum Verbleib von Sendungen bearbeitet, hat ein Sichtbarkeitsproblem.
Umgekehrt gibt es Konstellationen, in denen der Aufwand nicht lohnt. Ein Unternehmen mit einem einzigen Hausspediteur, festen Abholzeiten und wenigen Sendungen pro Tag löst seine Probleme günstiger über saubere Absprachen und ein besseres Vorsystem. Ebenso ist ein Betrieb mit eigenem Fuhrpark und ausschließlich eigenen Fahrzeugen näher an einer Tourenplanung als an einer Vergabeplattform.
Für den Mittelstand empfehlen wir fast immer einen Einstieg über genau einen Baustein mit klarem Schmerzpunkt. In den meisten Fällen ist das das Zeitfenstermanagement, weil es einen abgegrenzten Bereich betrifft, wenige Schnittstellen braucht und schnell messbare Effekte liefert. Der zweite Schritt ist üblicherweise die Vergabe, weil sie den Einkauf strukturiert und die Datenbasis für Verhandlungen schafft. Sichtbarkeit und Abrechnung folgen, weil sie mehr Partnerbeteiligung und mehr Datenqualität voraussetzen.
Wichtig ist bei diesem Vorgehen eine ehrliche Aufwandsbetrachtung auf der eigenen Seite. Auch ein einzelner Baustein braucht eine verantwortliche Person, die Stammdaten pflegt, Ausnahmen bearbeitet und mit Dienstleistern spricht. Wer diese Rolle nicht benennt, bekommt ein System, das nach einigen Monaten wieder umgangen wird. Bei kleineren Organisationen ist es sinnvoll, diese Rolle bewusst als Teilzeitaufgabe mit fester Stundenzahl zu definieren, statt sie unausgesprochen zu verteilen.
Bevor eine Plattformentscheidung fällt, lohnt der Blick auf drei günstigere Wege. Erstens: Bringt das vorhandene ERP- oder Warenwirtschaftssystem bereits ausreichende Transportfunktionen mit, die nur nicht genutzt werden? Zweitens: Lässt sich das Rampenproblem durch eine schlichtere Slotlösung oder durch veränderte Öffnungszeiten lösen? Drittens: Wäre die Bündelung von Verkehren bei einem Logistikdienstleister, der Transparenz als Leistung mitbringt, wirtschaftlich sinnvoller als eigene Systemarbeit? Diese Fragen ersetzen die Plattform nicht in jedem Fall, sie schärfen aber die Begründung – und die braucht man später gegenüber Geschäftsführung und Partnern.
Konkrete Preise, Lizenzgebühren oder Transaktionssätze nennen wir bewusst nicht. Sie sind individuell verhandelt, unterscheiden sich nach Modulen, Volumen und Vertragslaufzeit und ändern sich über die Zeit. Sie sind ausschließlich beim Anbieter zu erfragen. Was sich verallgemeinern lässt, ist die Mechanik der Kosten – und die sollte man verstehen, bevor man in eine Verhandlung geht.
Für eine belastbare Wirtschaftlichkeitsrechnung braucht man die Gegenseite: heutige Kosten für Wartezeiten und Standgelder, Aufwand für Vergabe und Nachfassen, Aufwand für Rechnungsprüfung und Klärung, Kosten von Sonderfahrten und Eskalationen. Diese Zahlen liegen in den meisten Unternehmen nicht vor. Sie über einige Wochen zu erheben, ist der wichtigste Vorbereitungsschritt – ohne ihn wird jede Nutzenbehauptung zur Glaubensfrage.
Die Konstellation ist typisch für den europäischen Softwaremarkt und verlangt eine differenzierte Betrachtung. Auf der einen Seite steht ein Anbieter mit deutschen Wurzeln, europäisch geprägter Entwicklung und einer Kundschaft, die überwiegend europäischen Anforderungen unterliegt. Auf der anderen Seite steht eine Muttergesellschaft in den USA. Diese Struktur schließt einen datenschutzkonformen Einsatz nicht aus, verlangt aber, dass drei Fragen ausdrücklich geklärt und schriftlich belegt werden.
Erstens der Verarbeitungsort: In welcher Region werden die Daten gespeichert und verarbeitet, gibt es eine zugesicherte EU-Region, und gilt sie für alle genutzten Module einschließlich Auswertung, Protokollierung und Support? Zweitens der Datentransfer: Welche Daten verlassen die EU, in welchem Umfang und zu welchem Zweck – etwa für Support, Fehleranalyse, Weiterentwicklung oder konzerninterne Dienste? Drittens der Konzernzugriff: Welche verbundenen Unternehmen können auf welche Daten zugreifen, unter welchen Bedingungen, und wie ist dieser Zugriff technisch und organisatorisch begrenzt?
Als Wege zu einer DSGVO-konformeren Gestaltung kommen mehrere Bausteine in Betracht: die vertragliche Zusicherung einer EU-Verarbeitungsregion, ein Auftragsverarbeitungsvertrag mit klarer Beschreibung von Unterauftragsverhältnissen einschließlich Konzerngesellschaften, Standardvertragsklauseln für unvermeidbare Drittlandübermittlungen samt dokumentierter Risikobetrachtung, ergänzende technische Maßnahmen wie Verschlüsselung und Zugriffsbeschränkung sowie ein Support-Modell mit europäischen Ansprechpartnern und protokolliertem Zugriff. Welche dieser Bausteine im konkreten Fall vorliegen, ist beim Anbieter zu prüfen und schriftlich zu bestätigen.
Der sensibelste Bereich sind Daten, die auf Personen zurückführbar sind. Positionsdaten eines Fahrzeugs sind in der Praxis Positionsdaten des Fahrers. Kommen Ankunftszeiten, Wartezeiten, Pausen und Ladevorgänge hinzu, entsteht ein Bild, das Leistungs- und Verhaltensaussagen zulässt. Dass die Fahrer meist bei einem Dienstleister und nicht beim Verlader angestellt sind, entlastet nicht vollständig: Der Verlader ist Empfänger dieser Daten und muss Zweck, Umfang und Speicherdauer begründen können.
Für die eigene Belegschaft – etwa Mitarbeitende an Pforte, Rampe und in der Disposition, deren Bearbeitungszeiten im System sichtbar werden – greifen zusätzlich die Beteiligungsrechte des Betriebsrats. Wo eine technische Einrichtung geeignet ist, Verhalten oder Leistung zu überwachen, ist eine Beteiligung erforderlich; in der Praxis mündet das häufig in eine Betriebsvereinbarung, die Auswertungszwecke, Aggregationsebenen und Ausschlüsse festlegt. Unsere Erfahrung: Wer diese Vereinbarung früh anstößt, verliert Wochen, wer sie spät anstößt, verliert Monate.
Sinnvoll ist zusätzlich eine bewusste Datenminimierung. Braucht die Auswertung Einzelfahrten oder reichen Aggregate je Dienstleister und Relation? Wird das Kennzeichen dauerhaft benötigt oder nur für die Slotabwicklung am jeweiligen Tag? Welche Felder werden aus Gewohnheit übertragen, ohne dass jemand sie nutzt? Diese Fragen senken das Risiko und vereinfachen gleichzeitig die Systemarbeit.
