Wenn die Anbindung eines Versanddienstleisters an SAP zum Thema wird, steht am Anfang fast immer dieselbe Grundsatzfrage: Baut man die Schnittstelle mit dem eigenen SAP-Team selbst – oder kauft man eine fertige Integrationslösung ein? Die Antwort fällt oft vorschnell zugunsten der Eigenentwicklung aus, weil die eigentlichen Folgekosten des „Build"-Wegs erst über die Zeit sichtbar werden.
Einleitung
Die Build-vs-Buy-Entscheidung wirkt auf den ersten Blick wie eine reine Kostenfrage: Entwicklungsaufwand im eigenen Haus gegen Lizenzkosten einer externen Lösung. Diese Rechnung greift jedoch zu kurz. Eine Carrier-Anbindung ist kein einmaliges Projekt mit definiertem Ende, sondern eine dauerhafte Verbindung zu einem externen System, das sich unabhängig vom eigenen Release-Zyklus verändert. Wer die Entscheidung nur an den Erstentwicklungskosten festmacht, vergleicht den falschen Zeitraum.
Dieser Beitrag zeigt, was „Build" tatsächlich umfasst, wo die versteckten Folgekosten der Eigenentwicklung liegen, in welchen Fällen der Eigenbau trotzdem die richtige Wahl ist – und wie man die Entscheidung sauber strukturiert, statt sie aus dem Bauch heraus zu treffen.
Was Build tatsächlich bedeutet
Die Anbindung eines Carriers wird gedanklich oft auf die Erzeugung eines Versandlabels reduziert. Tatsächlich umfasst eine Integration deutlich mehr: die Übergabe und Validierung der Sendungsdaten, die Übersetzung in das carrier-spezifische API-Format, die Erzeugung von Versand- und Retourenlabels im jeweils geforderten Format, den Rückfluss der Tracking-Informationen ins SAP-System, die Behandlung von Fehlern und Teilausfällen sowie die Abbildung von Sonderfällen wie Gefahrgut, Nachnahme oder internationalen Zolldaten.
Jeder dieser Punkte ist für sich beherrschbar. In Summe entsteht jedoch ein System, das nicht nur einmal gebaut, sondern dauerhaft betrieben und gepflegt werden muss – und das für jeden weiteren Carrier erneut. Genau hier beginnt die Diskrepanz zwischen der ersten Aufwandsschätzung und den tatsächlichen Gesamtkosten.
Die versteckten Kosten der Eigenentwicklung
Die Erstentwicklung ist in der Regel der kleinere und am besten planbare Teil. Der eigentliche Aufwand entsteht danach.
Der größte Posten ist die laufende Wartung. Carrier ändern ihre Schnittstellen, Label-Anforderungen und Datenformate regelmäßig und ohne Rücksicht auf den eigenen Release-Kalender. Jede dieser Änderungen erfordert eine Anpassung der selbst gebauten Schnittstelle, inklusive Test und Transport durch die SAP-Systemlandschaft. Bei mehreren Carriern summiert sich das zu einem kontinuierlichen Wartungsaufwand, der in der ursprünglichen Wirtschaftlichkeitsrechnung selten auftaucht.
Der zweite Posten ist die Abhängigkeit vom Know-how einzelner Personen. Eine selbst entwickelte Carrier-Integration lebt vom Wissen derjenigen, die sie gebaut haben. Verlässt diese Person das Unternehmen oder wechselt in ein anderes Projekt, wird aus einer funktionierenden Schnittstelle schnell eine Blackbox, die niemand mehr sicher anfassen möchte. Dieses Klumpenrisiko lässt sich schwer beziffern, wird aber im Störfall unmittelbar teuer.
Der dritte Posten ist die Kopplung an den SAP-Core. Wird die Carrier-Logik direkt im SAP-System entwickelt, wandert carrier-spezifisches Verhalten in den Core. Jede Carrier-Änderung wird damit zu einer Änderung am SAP-System selbst – mit entsprechendem Test- und Freigabeaufwand und einem wachsenden Bestand an schwer wartbarem Code, der die Systemlandschaft über die Jahre belastet.
Der vierte Posten ist die Skalierung. Eine Schnittstelle, die für einen Carrier und ein moderates Volumen entworfen wurde, trägt nicht automatisch drei Carrier und ein Vielfaches an Sendungen. Wächst das Geschäft, steht häufig ein Re-Engineering an – also ein zweites Projekt für dieselbe Aufgabe.
Wann Build trotzdem die richtige Wahl ist
Eigenentwicklung ist nicht grundsätzlich der falsche Weg. Sie ist dann sinnvoll, wenn die Carrier-Anbindung ein echtes Kerndifferenzierungsmerkmal des eigenen Geschäftsmodells ist – etwa bei einem Logistikdienstleister, dessen Produkt genau in dieser Integration besteht. Ebenso kann Build die richtige Entscheidung sein, wenn nur ein einziger, stabiler Carrier mit geringem Änderungstakt angebunden wird, ausreichend internes Entwicklungs-Know-how dauerhaft verfügbar ist und die Bereitschaft besteht, die Lösung über ihren gesamten Lebenszyklus aktiv zu pflegen.
Der ehrliche Prüfstein lautet: Ist die Carrier-Anbindung ein Wettbewerbsvorteil, den man selbst kontrollieren möchte – oder eine notwendige Infrastruktur, die einfach zuverlässig funktionieren soll? Nur im ersten Fall rechtfertigt der strategische Wert die dauerhaften Betriebskosten der Eigenentwicklung.
Was Buy abnimmt
Der Kern des „Buy"-Ansatzes ist nicht die eingesparte Erstentwicklung, sondern die verlagerte Verantwortung für den laufenden Betrieb. Genau diese Aufgabe übernimmt eine zentrale Integrationsschicht wie CEP One: Sie pflegt die Carrier-Anbindungen zentral, statt jeden Dienstleister einzeln an das SAP-System zu binden. Ändert ein Dienstleister seine API, wird das innerhalb von CEP One nachgezogen, ohne dass am SAP-System etwas angepasst werden muss. Das SAP-Backend sendet unabhängig vom Carrier stets dieselbe standardisierte Datenstruktur, und die carrier-spezifische Übersetzung liegt außerhalb des SAP-Core.
Damit verschieben sich genau die vier versteckten Kostenposten der Eigenentwicklung: Die Wartung der Carrier-Schnittstellen liegt bei CEP One, das Know-how ist nicht an einzelne interne Personen gebunden, der SAP-Core bleibt frei von carrier-spezifischem Code, und die Skalierung mit wachsendem Versandvolumen ist Teil der Integrationsschicht statt eines eigenen Projekts. Man kauft weniger eine Software als die dauerhafte Freistellung von einer Betriebsaufgabe.
Die Entscheidung strukturieren
Statt Build und Buy anhand der Erstkosten zu vergleichen, lohnt sich der Blick auf drei Dimensionen über einen realistischen Zeitraum von mehreren Jahren.
Erstens die Gesamtkosten über den Lebenszyklus: nicht nur die Entwicklung, sondern Wartung, Weiterentwicklung, Test, Betrieb und das absehbare Re-Engineering bei Wachstum. Zweitens das Änderungsprofil: Wie viele Carrier, in welchem Änderungstakt, mit welcher Volatilität der Schnittstellen? Je mehr Dienstleister und je häufiger deren Änderungen, desto stärker fällt die Wartungslast ins Gewicht. Drittens die strategische Einordnung: Ist die Carrier-Anbindung Kern des eigenen Angebots oder unterstützende Infrastruktur? Fällt die Antwort auf „Infrastruktur", überwiegen in den meisten Fällen die Argumente für Buy.
Fazit
Die Build-vs-Buy-Entscheidung bei der Carrier-Anbindung ist keine Frage der Erstentwicklungskosten, sondern der Gesamtkosten über den Lebenszyklus. Eigenentwicklung lohnt sich, wenn die Integration ein echter Wettbewerbsvorteil ist und dauerhaft internes Know-how zur Pflege bereitsteht. In allen anderen Fällen – mehrere Carrier, volatile Schnittstellen, begrenzte Entwicklungskapazität, der Wunsch nach einem sauberen SAP-Core – überwiegen die versteckten Betriebskosten der Eigenentwicklung, und eine eingekaufte Integrationslösung nimmt genau die Aufgaben ab, die den Eigenbau über die Jahre teuer machen.
Wie eine solche eingekaufte Integrationsschicht als Middleware zwischen SAP-System und Paketdienstleistern funktioniert und den SAP-Core vom Carrier-Netzwerk entkoppelt, beschreibt der Beitrag Glossar: Was ist die zentrale Integrationsschicht von CEP One?. Wie sich mehrere Dienstleister auf dieser Basis regelbasiert und ohne Wartungsfalle betreiben lassen, zeigt der Artikel Multi-Carrier-Strategie: Wann sie sich lohnt und wie man sie sauber aufsetzt. Und warum sich weitere Carrier in diesem Modell in Tagen statt Monaten anbinden lassen, erläutert der Beitrag Carrier-Portfolio flexibel erweitern: Neue Versanddienstleister in Tagen statt Monaten.