SAP Business Technology Platform

Was ist SAP BTP?

SAP Business Technology Platform (SAP BTP) ist die Cloud-Plattform von SAP für Integration, Erweiterungen, Prozessautomatisierung, Daten und KI: die Schicht, die SAP- und Nicht-SAP-Systeme verbindet und die Logik trägt, die nicht in eine Standardanwendung gehört. Spadoom ist ein Schweizer SAP Gold Partner, der SAP BTP einführt, um SAP S/4HANA Public Cloud mit Sales Cloud V2, Service Cloud V2 und dem übrigen CX-Stack zu verbinden, und der die Schnittstellen und Erweiterungen betreibt, die er baut. Seit September 2026 ist Spadoom zudem SAP PartnerEdge Build Partner: Unsere eigenen BTP-Lösungen durchlaufen die Prüfung durch SAP und werden im SAP Store angeboten.

In der Praxis trägt BTP drei Arten von Arbeit: die Schnittstelle zwischen ERP und CX-Anwendungen, den Freigabeschritt, den Ihr Prozess braucht und den der Standard nicht hat, und das Ereignis, das drei Systeme in der richtigen Reihenfolge erreichen muss. Die Plattformdokumentation von SAP ist die verbindliche technische Referenz, die Produktseite von SAP BTP zeigt die Dienstfamilien, SAP Integration Suite ist der Dienst, mit dem die meisten unserer Projekte beginnen, und das SAP Discovery Center ist der SAP-Katalog für Dienste, Pläne und Referenzmissionen, samt dem Kostenschätzer, den wir in der Umfangsklärung verwenden.

Die Regel, an die wir uns halten: BTP ist nicht die erste Antwort. Wir prüfen Standardfunktionen, dann unterstützte In-App-Erweiterungen und erst danach eine Side-by-Side-Erweiterung auf BTP. Eine Erweiterung, die Sie nicht gebraucht hätten, ist ein System, das Sie nun betreiben, patchen und übergeben müssen. Wenn Sie zuerst die allgemeine Einführung lesen möchten, erklärt unser Blog, was SAP BTP ist und wann Sie es brauchen. Diese Seite handelt von der Umsetzung: was wir auf BTP bauen, wie es lizenziert wird und wer es danach betreibt.

Spadoom baut auf BTP als Teil der Umsetzung von Cloud ERP und Customer Experience in der Schweiz, in Deutschland, Österreich und Italien, mit einem Team für die ERP-Seite und die CX-Seite jeder Schnittstelle.

Fallstudie: über eine Million Nachrichten pro Monat bei Meier Tobler

Meier Tobler liefert Heizungs-, Lüftungs- und Sanitärtechnik in der ganzen Schweiz. Die in die Jahre gekommene SAP-PI/PO-Plattform lieferte keine verlässlichen Echtzeitdaten zwischen Onlineshop und SAP S/4HANA, Preise und Bestände im Shop waren deshalb oft nicht aktuell. Wir haben zuerst beim Kauf und bei der Dimensionierung der SAP-Integration-Suite-Lizenzen für das Nachrichtenvolumen beraten, danach SAP Integration Suite als zentrale Integrationsplattform eingeführt und die Schnittstellen zwischen Shop und ERP gebaut.

Heute laufen mehr als eine Million Nachrichten pro Monat über eine überwachte Plattform, Preise und Bestände im Shop werden in Echtzeit synchronisiert, und Aufträge fliessen ohne manuelle Eingriffe zurück ins ERP. Die neue Architektur bereitet zudem die schrittweise Ablösung der alten PI/PO-Systeme vor. Lesen Sie die ganze Geschichte von Meier Tobler.

Bei intelligentfood war die BTP-Arbeit anderer Art: mobile Anwendungen für ein Vertriebsteam, das unterwegs arbeitet, dazu Sales Cloud V2 und die Cloud-ERP-Integration.

Integration Suite, Build oder KI: welcher BTP-Dienst was leistet

«Wir brauchen BTP» ist noch kein Umfang. BTP ist ein Katalog von Diensten, die einzeln lizenziert und betrieben werden, und die meisten Projekte brauchen zwei oder drei davon, nicht alle. So erklären wir die wichtigsten, bevor etwas bestellt wird.

Die Reihenfolge zählt. Integration Suite kommt meist zuerst, weil ERP und CX-Anwendungen sich über die Daten einig sein müssen, bevor darauf etwas automatisiert wird. Build folgt, wenn ein Prozessschritt fehlt. KI kommt zuletzt, wenn die Daten stimmen, auf die sie sich stützt, und jemand für den Prüfschritt verantwortlich ist.

Clean Core: wann eine Erweiterung auf BTP gehört

Clean Core heisst, das ERP nahe am Standard zu halten, damit sich die SAP-Releases ohne Nacharbeit einspielen lassen. In SAP S/4HANA Cloud gibt es drei Orte, an denen eine Anforderung gelöst werden kann, und wir prüfen sie in dieser Reihenfolge.

1. Key-User-Erweiterungen im System. Eigene Felder, eigene Logik in freigegebenen Erweiterungspunkten, angepasste Formulare und Masken. Keine eigene Plattform, kein zusätzlicher Betrieb.
2. Entwicklererweiterungen im System. ABAP-Cloud-Entwicklung auf freigegebenen APIs, nahe an den Daten, für Logik, die innerhalb der ERP-Transaktion laufen muss.
3. Side-by-Side auf SAP BTP. Eine eigene Anwendung oder ein eigener Workflow, der mit dem ERP nur über freigegebene APIs und Ereignisse spricht. Das ist der richtige Ort, wenn die Logik mehreren Systemen dient (ERP und CX zugleich), eigene Benutzer ausserhalb des ERP hat oder in einem anderen Rhythmus skalieren oder sich ändern muss als der Kern.

Eine Side-by-Side-Erweiterung kostet im Betrieb mehr als eine In-App-Erweiterung: eigenes Deployment, eigene Berechtigungen, eigenes Monitoring. Wir empfehlen sie, wenn einer der genannten Gründe zutrifft, und halten diesen Grund im Architekturentscheid fest, damit das nächste Team ihn nachvollziehen kann.

Verbinden. Erweitern. Automatisieren.

SAP BTP ist die Basis unserer Erweiterungen. Wir verbinden SAP S/4HANA Public Cloud mit Sales Cloud, Service Cloud, Commerce, CPQ und FSM. Wir beginnen beim Geschäftsprozess, klären, welches System für welchen Datensatz führend ist, und bauen darauf Schnittstellen, Anwendungen und Überwachung auf.

Drei Fragen entscheiden die meisten Schnittstellenentwürfe, bevor eine Zeile Code geschrieben ist:

• Wem gehört der Datensatz? Ein Preis lebt im ERP, eine Opportunity in Sales Cloud, ein Serviceauftrag in FSM. Jede Schnittstelle kopiert vom führenden System, nie in beide Richtungen ohne Regel für Konflikte.
• Synchron oder Ereignis? Eine Preisprüfung während der Angebotserstellung braucht sofort eine Antwort. Ein Lieferstatus darf als Ereignis ein paar Sekunden später ankommen. Die Wahl verändert Fehlerbehandlung, Volumen und Kosten.
• Was passiert, wenn das Zielsystem ausfällt? Wiederholungen, eine Dead-Letter-Queue und eine Meldung an eine benannte Person, vereinbart vor dem Go-live.

Auf SAP BTP entwickeln wir auch eigene Produkte, darunter die Engage-Erweiterungen für Sales und Service Cloud V2: siehe Built by Spadoom.

Vom Angebot zum Einsatz vor Ort

Der Vertrieb erstellt ein Angebot in Sales Cloud und CPQ. Der angenommene Auftrag gelangt ins Cloud ERP, das Bonität, Preise und Verfügbarkeit prüft. Ein Servicebedarf erzeugt einen Einsatz für das Team im Feld in FSM, und die bestätigten Stunden und das Material fliessen zur Fakturierung zurück ins ERP. BTP verbindet die Übergaben und trägt die Erweiterungen, die der Prozess braucht, etwa eine Freigabe für einen Rabatt über einer Schwelle. Das ist eine Beispielarchitektur: die genauen Schnittstellen, der Produktumfang und die Lizenzen werden im Assessment geprüft. Unsere Transformationsübersicht zeigt, wie ERP- und CX-Bausteine durchgängig zusammenpassen.

Wie SAP BTP lizenziert wird

SAP verkauft BTP in zwei kommerziellen Modellen, verbrauchsbasiert und als Abonnement, und viele Kunden nutzen beide gleichzeitig. Das ist eine Orientierung, kein Angebot: Ihre tatsächlichen Berechtigungen hängen von Ihrem Vertrag ab. Das SAP-Schulungsmaterial zu den kommerziellen Modellen von SAP BTP beschreibt sie im Detail.

• Verbrauchsbasiert mit vorausbezahlten Cloud Credits. Im SAP BTP Enterprise Agreement (BTPEA) verpflichten Sie sich für die Vertragslaufzeit zu einem vorausbezahlten Volumen an Cloud Credits, und die tatsächliche Nutzung berechtigter Dienste wird monatlich davon abgezogen. BTPEA ist das Modell für neue Verträge; das ältere Cloud Platform Enterprise Agreement (CPEA) funktioniert gleich und läuft für bestehende CPEA-Konten weiter. Die beiden Dienstlisten sind nicht identisch.
• Pay-As-You-Go. Keine Vorabverpflichtung; Sie erhalten monatlich im Nachhinein eine Rechnung für das, was Sie nutzen. SAP positioniert das Modell für kleine Anwendungen, Proofs of Concept und Pilotprojekte.
• Subskription. Ein Fixpreis für einen bestimmten Dienst und Plan über eine feste Laufzeit, unabhängig vom Verbrauch. Geeignet für Dienste mit planbarer Nutzung.
• Free Tier. Viele Dienste bieten kostenlose Pläne mit Nutzungsgrenzen, die genügen, um einen Ablauf zu prototypisieren, bevor etwas bestellt wird.

Auch RISE with SAP und GROW with SAP enthalten BTP: SAP führt BTP Cloud Credits als Bestandteil von RISE auf, und beide GROW-Editionen enthalten Credits aus dem BTP Enterprise Agreement sowie Berechtigungen für SAP-Build-Funktionen. Ob diese Credits Ihre geplanten Integrationen abdecken, hängt vom Volumen und von den genutzten Diensten ab.

Was wir vor der Umfangsklärung prüfen, damit Sie die Lizenzierung nach dem Go-live nicht überrascht:

• Bestehende Berechtigungen. Welche BTP-Dienste, Pläne und Credits Ihr aktueller Vertrag (auch RISE oder GROW) bereits enthält.
• Dienste und Pläne, die der Ablauf braucht. Integration Suite, ein Build-Dienst, ein KI-Dienst oder keiner davon, und in welchem Plan.
• Eine Verbrauchsschätzung. Erwartetes Nachrichtenvolumen und Verbindungen, berechnet mit dem Schätzer im SAP Discovery Center und mit den Annahmen dokumentiert. Bei Meier Tobler war diese Dimensionierung das erste Ergebnis, bevor eine einzige Schnittstelle gebaut wurde.
• Wer den Verbrauch beobachtet. Credits werden monatlich verbraucht; jemand auf Ihrer oder unserer Seite prüft die Nutzung im BTP Cockpit und erhält eine Warnung, bevor das Budget aufgebraucht ist.

Was der Betrieb kostet, nach dem Aufbau

Über einen BTP-Business-Case entscheidet selten der Aufbau. Entscheidend ist, wer die Schnittstellen zum Monatsende beobachtet, was die Service-Berechtigungen in Ihrem Vertrag tatsächlich abdecken und was passiert, wenn ein Zielsystem um zwei Uhr nachts nicht erreichbar ist. Berechtigungen, Protokollierung, Deployment und Alarmierung gehören bei uns von Anfang an zum Umfang, und wir vereinbaren die Abnahmetests vor der Umsetzung statt danach.

Nach dem Go-live gibt es zwei Möglichkeiten, und wir vereinbaren vor Baubeginn, welche gilt. Entweder übernimmt Ihre IT mit Dokumentation, Runbooks und der Übergabe jeder Alarmierung, oder Spadoom betreibt die Schnittstellen und Erweiterungen im Rahmen eines Supportvertrags: Wir überwachen die Nachrichtenverarbeitung, analysieren fehlerhafte Nachrichten, testen die vierteljährlichen SAP-Releases gegen die Schnittstellen und berichten über den Verbrauch. In beiden Fällen hat jede Schnittstelle eine benannte verantwortliche Person und einen dokumentierten Wiederherstellungsweg.

Mit einem Ablauf anfangen. Sauber bauen.

Bringen Sie einen Ablauf mit, bei dem heute noch Daten kopiert oder E-Mails nachgefasst werden. Im Fixpreis-Assessment erfassen wir Systeme, Datenverantwortliche und Ausnahmen, prüfen Ihre bestehenden BTP-Berechtigungen und schätzen den Verbrauch. Sie erhalten einen Architekturvorschlag, den Lieferumfang und eine Kostenbasis. Monitoring und Übergabe gehören zum Umfang, nicht in einen späteren Änderungsantrag.

Wenn Sie noch SAP PI/PO betreiben, kann dasselbe Assessment bei Ihrem Schnittstelleninventar beginnen: welche Abläufe unverändert in die Integration Suite wechseln, welche neu gestaltet werden und welche wegfallen können.

Ihre Integration besprechen oder lesen, wie ERP- und CX-Seite zusammenpassen.