Transport Management Systeme können heute in unterschiedlichen Betriebsmodellen bereitgestellt werden. Begriffe wie Cloud-TMS, Software as a Service und Hosted TMS werden dabei häufig gleichgesetzt, obwohl sich die Modelle in wichtigen Punkten unterscheiden. Architektur, Verantwortlichkeiten und Individualisierung können je nach Variante unterschiedlich ausfallen. Dieser Artikel erklärt, was hinter den Begriffen steckt, wie sich die Betriebsmodelle unterscheiden und welche Kriterien Unternehmen bei der Auswahl berücksichtigen sollten.
Was ist ein Cloud-TMS?
Ein Cloud-TMS ist ein Transport Management System (TMS), dessen Anwendung und Daten über eine Cloud-Infrastruktur bereitgestellt werden. Diese Infrastruktur kann vom Anbieter, einem Rechenzentrumsdienstleister oder vom Unternehmen selbst betrieben werden.
Der Begriff allein sagt jedoch noch nicht aus, wie die Software technisch betrieben wird, welche Infrastruktur genutzt wird oder wer welche Aufgaben übernimmt. Deshalb sollten Unternehmen genauer auf das konkrete Betriebsmodell schauen.
Für die Einordnung lassen sich insbesondere SaaS, Hosted TMS und On-Premises voneinander unterscheiden.
SaaS, Hosted TMS und On-Premises im Vergleich
Software as a Service (SaaS)
Bei einem typischen SaaS-Modell betreibt der Anbieter eine standardisierte Anwendung für viele Kunden. Häufig wird dafür eine mandantenfähige Architektur eingesetzt. Die Kunden nutzen dieselbe Plattform, während ihre Daten und Berechtigungen logisch voneinander getrennt bleiben.
Aktualisierungen erfolgen zentral und der Anbieter verantwortet große Teile des technischen Betriebs.
Hosted TMS
Bei einem Hosted TMS wird die TMS-Software auf der Infrastruktur eines Anbieters oder eines Rechenzentrums betrieben. Anders als bei einem typischen SaaS-Modell kann dafür eine dedizierte oder stärker kundenspezifische Umgebung bereitgestellt werden.
Ein Hosted TMS kann damit eine stärkere Trennung oder Individualisierung der technischen Umgebung ermöglichen. Es muss nicht als gemeinsam genutzte SaaS-Plattform aufgebaut sein.
On-Premises
Beim On-Premises-Modell liegen Infrastruktur und wesentliche Betriebsaufgaben üblicherweise beim Kunden. Das Unternehmen übernimmt damit mehr Verantwortung für den technischen Betrieb als bei den beiden anderen Modellen.
Die Betriebsmodelle auf einen Blick
| Merkmal | SaaS | Hosted TMS | On-Premises |
| Anwendung | Typischerweise standardisierte Anwendung für viele Kunden | Kann stärker kundenspezifisch sein | Betrieb der eingesetzten TMS-Anwendung beim Kunden |
| Infrastruktur | Durch den Anbieter betrieben | Beim Anbieter oder Rechenzentrum | Beim Kunden |
| Architektur | Häufig mandantenfähige Plattform | Kann dedizierte Umgebung sein | Kundeneigene Umgebung |
| Betriebsverantwortung | Große Teile beim Anbieter | Je nach vereinbartem Leistungsumfang | Wesentliche Aufgaben beim Kunden |
| Individualisierung | Abhängig von der SaaS-Lösung | Stärker kundenspezifische Umgebung möglich | Abhängig von Software und eigener Infrastruktur |
Wichtig: Die Bezeichnung „Cloud-TMS“ allein lässt noch keine eindeutigen Rückschlüsse auf Architektur und Verantwortlichkeiten zu. Unternehmen sollten deshalb prüfen, welches konkrete Betriebsmodell hinter einer Lösung steht.
Welche Kriterien sind bei der Wahl des Betriebsmodells wichtig?
Vor der Entscheidung für ein Betriebsmodell sollten Unternehmen die technischen und organisatorischen Rahmenbedingungen genau prüfen.
Besonders relevant sind:
- Datenstandort: Wo werden Unternehmens- und Transportdaten gespeichert und verarbeitet?
- Mandantentrennung: Wie werden Daten und Berechtigungen unterschiedlicher Kunden voneinander getrennt?
- Verfügbarkeit: Welche Verfügbarkeit wird für das TMS zugesichert?
- Datensicherung und Wiederherstellung: Wie werden Daten gesichert und wie schnell können sie nach einem Ausfall wiederhergestellt werden?
- Updateverfahren: Wer führt Aktualisierungen durch und wie werden diese geplant?
- Verantwortlichkeiten: Welche Aufgaben übernimmt der Anbieter und welche verbleiben beim Kunden?
Diese Aspekte spielen auch für die Cybersicherheit im TMS eine wichtige Rolle. Das gewählte Betriebsmodell sollte daher immer zusammen mit den jeweiligen Sicherheits- und Compliance-Anforderungen betrachtet werden.
Ein Cloud-Modell ist dabei nicht automatisch sicherer, günstiger oder flexibler als ein lokaler Betrieb. Entscheidend ist, wie gut die konkrete Architektur und der vereinbarte Serviceumfang zu den eigenen Prozessen, Kompetenzen und Compliance-Anforderungen passen.
Welche weiteren Punkte sollten Unternehmen vor Vertragsabschluss klären?
Neben dem eigentlichen Betrieb gibt es weitere Anforderungen, die langfristig relevant werden können. Dazu zählen insbesondere:
- benötigte Schnittstellen,
- individuelle Konfigurationen,
- verfügbare Leistungsreserven,
- Zugriff auf Betriebsdaten,
- Servicezeiten,
- Wartungsfenster,
- Ausstiegsregelungen,
- Rückgabe der eigenen Daten.
Gerade Schnittstellen können entscheidend sein, wenn das TMS mit Telematik, Finanzbuchhaltung, Kundenportalen oder anderen Anwendungen verbunden werden soll. Anforderungen an API & Systemintegration sollten deshalb bereits bei der Auswahl des Betriebsmodells berücksichtigt werden.
Auch ein Service Level Agreement (SLA) kann festlegen, welche Leistungen und Servicebedingungen zwischen Anbieter und Kunde vereinbart sind.
Was bedeutet die Wahl des Betriebsmodells für Entscheider?
Bei der Auswahl eines TMS sollten Entscheider nicht nur „Cloud oder On-Premises?“ fragen. Sinnvoller ist eine genauere Betrachtung der jeweiligen Architektur und Verantwortlichkeiten.
Dabei helfen insbesondere folgende Fragen:
- Wo liegen die Daten und wer betreibt die Infrastruktur?
- Wer ist für Updates, Datensicherung und Wiederherstellung verantwortlich?
- Ist die Umgebung gemeinsam genutzt oder dediziert?
- Welche individuellen Konfigurationen werden benötigt?
- Welche Verfügbarkeit und Servicezeiten sind erforderlich?
- Wie lassen sich Daten bei einem späteren Wechsel zurückgeben oder übertragen?
Erst anhand dieser Punkte lassen sich unterschiedliche Betriebsmodelle sinnvoll miteinander vergleichen.
Wie CarLo dabei unterstützt
CarLo Hosted verbindet die bewährte CarLo-Anwendung mit einem von Soloplan betriebenen Hostingservice auf dedizierter virtualisierter Infrastruktur.
Kunden können dadurch den eigenen Aufwand für den Betrieb der zugrunde liegenden Infrastruktur reduzieren. Gleichzeitig wechseln sie nicht auf eine gemeinsam genutzte mandantenfähige SaaS-Plattform.
Dabei bleiben drei Leistungsbestandteile klar voneinander abgrenzbar:
- Hosting
- Softwarelizenz
- Softwarewartung
So können Betriebsmodell und Leistungsumfang passend zum jeweiligen Einsatzszenario ausgewählt werden.
Fazit
Ob SaaS, Hosted TMS oder On-Premises die passende Lösung ist, hängt von den individuellen Anforderungen eines Unternehmens ab. Entscheidend ist, wie Verantwortlichkeiten, Datenhaltung, Updates, Sicherheit und Service im konkreten Betriebsmodell geregelt sind. Unternehmen sollten deshalb nicht allein auf die Bezeichnung „Cloud-TMS“ achten, sondern genau prüfen, welche Leistungen und Pflichten tatsächlich dahinterstehen.