Logistik-IT-Entscheider und IT-Architekten, die eine Einführung von CEP One prüfen, stellen sich häufig ähnliche strategische Fragen zu Wachstum, Abhängigkeit und den beiden verfügbaren Lösungspaketen.
Einleitung
Wer den Einsatz von CEP One evaluiert, stellt sich neben technischen Detailfragen oft grundsätzlichere Fragen: Trägt die Architektur auch bei steigendem Versandvolumen? Wie stark bindet man sich an einzelne Versanddienstleister? Und unterscheiden sich die beiden Lösungspakete überhaupt in Abrechnung und Verfügbarkeit? Dieser Beitrag beantwortet vier häufige Fragen von Logistik-IT-Entscheidern und IT-Architekten.
Wächst CEP One mit steigendem Versandvolumen mit, ohne dass SAP umgebaut werden muss?
Ja. CEP One wächst mit dem Versandvolumen, ohne dass bei steigendem Durchsatz ein Re-Engineering nötig ist. Das gilt unabhängig davon, welches der beiden Lösungspakete im Einsatz ist: Die Integrationsschicht bleibt in ihrer Architektur davon unberührt, ob sie ein kleines oder ein stark wachsendes Versandvolumen verarbeitet. Für Logistik-IT-Entscheider bedeutet das, dass eine einmal getroffene Entscheidung für CEP One nicht laufend neu bewertet werden muss, sobald das Versandvolumen zunimmt.
Wie abhängig bin ich nach der Einführung von CEP One noch von einzelnen Versanddienstleistern?
Weniger als bei einer Anbindung, die einzelne Versanddienstleister direkt und individuell an SAP koppelt. Da Carrier zentral über CEP One angebunden sind, sinkt die Abhängigkeit von einzelnen Versanddienstleistern – Carrier lassen sich wechseln oder ergänzen, ohne das SAP-System umzubauen. Möglich wird das durch die architektonische Entkopplung von SAP und den angebundenen Carriern: Das carrier-spezifische Mapping liegt vollständig in CEP One, nicht in SAP. Für IT-Architekten heißt das konkret: Ein Carrier-Wechsel wirkt sich auf CEP One aus, nicht auf das SAP-System.
Unterscheiden sich Abrechnungsmodell und Verfügbarkeit zwischen den beiden Lösungspaketen?
Nein. Es gibt zwei Lösungspakete – die API Solution für den flexiblen Einstieg und die SAP Full Solution mit vollständiger SAP-Integration über das CEP Add-on –, doch beide arbeiten nach demselben Abrechnungsmodell Pay per Message / CEP, und für beide wird dieselbe Verfügbarkeit von 99,95 % zugesichert. Die konkreten Konditionen werden individuell auf das jeweilige Versandvolumen und die genutzten Carrier-Anbindungen abgestimmt, unabhängig vom gewählten Paket. Für Logistik-IT-Entscheider bedeutet das: Die Wahl zwischen den beiden Paketen lässt sich am benötigten Integrationsumfang ausrichten, nicht an unterschiedlichen Abrechnungs- oder Verfügbarkeitsmodellen.
Muss das SAP-System für unterschiedliche Carrier-Formate jeweils angepasst werden?
Nein. Aus dem SAP-Backend wird unabhängig vom jeweiligen Carrier immer dieselbe standardisierte Datenstruktur an CEP One gesendet – ein Datenmodell, ein Request-Format, ein einheitlicher Prozess. Die Übersetzung in das jeweilige carrier-spezifische Format übernimmt CEP One zentral, nicht das SAP-System. Für IT-Architekten entfällt damit die Notwendigkeit, für jeden neuen oder geänderten Carrier eine eigene Schnittstellenlogik im SAP-System zu pflegen.
Fazit
Für Logistik-IT-Entscheider und IT-Architekten lassen sich diese vier strategischen Fragen zu CEP One auf ein gemeinsames Architekturprinzip zurückführen: eine zentrale, vom SAP-System entkoppelte Integrationsschicht, die mit dem Versandvolumen mitwächst, die Abhängigkeit von einzelnen Versanddienstleistern reduziert und für beide Lösungspakete dieselben Konditionen bei Abrechnung und Verfügbarkeit bietet. Wie sich die beiden Lösungspakete im Detail unterscheiden, beschreibt der Artikel CEP One Lösungspakete: API Solution vs. SAP Full Solution; die grundsätzliche Architektur der Integrationsschicht vertieft Glossar: Was ist die zentrale Integrationsschicht von CEP One?.