SAP-Integrationsplattformen: Tools, Lizenzen, Szenarien

SAP-Integrationsplattformen: Tools, Lizenzierung und Praxisszenarien

SAP in eine größere Systemlandschaft zu integrieren, kann sich anfühlen wie ein Puzzle, bei dem einige Teile einfach nicht passen wollen. Verschiedene Tools, Plattformen und Datenformate konkurrieren um Aufmerksamkeit. Das kann überwältigend sein, vor allem bei so vielen Integrationsoptionen, darunter die SAP Integration Suite, die alle für sich beanspruchen, die beste Lösung zu sein. Ich habe erlebt, wie Teams wochenlang Plattformen verglichen und am Ende merkten, dass sie etwas Grundlegendes übersehen hatten, etwa die Folgen für die Lizenzierung oder die Systemlatenz unter Last.

Diese Seite versucht deshalb, Klarheit zu schaffen. Vielleicht nicht perfekte Klarheit, aber genug, um sichere Entscheidungen zu treffen. Ich betrachte SAP-Integrationsplattformen ganz praktisch:

Welche Tools tatsächlich gut zusammenarbeiten
Wo Sie bei der indirekten Lizenzierung stolpern können
Wie sich SAP Integration Suite, CPI, PI und BTP wirklich vergleichen
Wann Tools von Drittanbietern sinnvoller sind als die von SAP

Eine einzige Antwort für jedes Projekt gibt es nicht. Aber sobald der Anwendungsfall feststeht, wird der richtige Integrationsweg meist offensichtlich. Das ist zumindest die Hoffnung.

1. Einführung in die SAP Integration Suite

Bei einer SAP-Implementierung geht es selten nur darum, SAP einzurichten. Öfter geht es darum, SAP mit allem anderen zum Laufen zu bringen: mit den Altsystemen, Cloud-Anwendungen, Datenbanken und allen individuellen Tools, auf die sich das Unternehmen seit Jahren verlässt.

Genau hier wird die Integration kritisch. Sie kann die gesamte Landschaft zusammenhalten oder leise Reibung erzeugen, die niemand bemerkt, bis etwas bricht.

In der Praxis wird die Integration tendenziell unterschätzt. Teams konzentrieren sich auf Funktionalität, Prozessdesign und Tests. Spät im Projekt merkt jemand:

Wichtige Daten werden nicht in Echtzeit synchronisiert
API-Limits wurden schon vor Wochen erreicht
Die Lizenzkosten haben sich durch indirekte Nutzung gerade verdoppelt
Die gewählte Middleware schafft das Volumen unter Last nicht

Das ist am Anfang nicht immer offensichtlich. Am Ende wirkt es sich aber auf Zeitpläne, Budgets und sogar auf die Compliance aus.

Diese Seite betrachtet die SAP Integration Suite aus diesem Blickwinkel: wie die Tools in Projekten wirklich funktionieren, welche Probleme sie lösen und wo sich die Risiken gern verstecken.

Starten Sie Ihre Implementierungsbewertung SAP-Integration

2. Gängige Integrationsszenarien in SAP-Projekten

SAP-Projekte beginnen in der Regel nicht bei null. Sie beginnen mit einem Mix aus bestehenden Systemen: manche gut dokumentiert, andere kaum verstanden. Die Integration muss all das in Einklang bringen, oft ohne viel Spielraum für Verzögerungen.

Ein paar Muster tauchen in den meisten Landschaften auf:

Verbindungen von SAP zu Nicht-SAP-Systemen. Alt-ERPs, CRMs oder selbst entwickelte Anwendungen, die noch im Einsatz sind.
Hybride Setups. Ein Mix aus Cloud-Diensten und On-Premise-Systemen, die versuchen, synchron zu bleiben.
Echtzeit- und Batch-Flüsse. Schnell ist gut, aber verlässlich gewinnt oft.
API-getrieben oder Middleware-basiert. Manchmal beides, je nach Situation.

Tools wie die SAP Integration Suite sind darauf ausgelegt, viele dieser Muster abzudecken, besonders in hybriden oder stark cloudgeprägten Umgebungen. Aber das Tool selbst ist nur ein Teil der Lösung.

SAP mit externen Plattformen zu verbinden klingt oft einfach, bis Formate, Sicherheit oder Timing dazwischenkommen. Ich habe Teams tagelang an kleinen Abweichungen hängen sehen. Die eine Seite spricht REST, die andere besteht auf Flat Files.

Hybride Setups wirken zunächst flexibel. In der Praxis beruhen sie meist auf einem Flickenteppich aus Ausnahmen. Ein Dienst schiebt Daten sofort weiter. Ein anderer verlässt sich noch auf nächtliche Jobs.

Echtzeitintegration gefällt in der Planungsphase allen. Sie funktioniert aber nur, wenn beide Systeme damit umgehen können. Das ist nicht immer der Fall.

Middleware bietet Struktur, APIs bieten Geschwindigkeit. Die Wahl hängt weniger von Vorlieben ab als davon, was bereits vorhanden ist und was das Team realistischerweise betreiben kann.

Anwendungsübergreifende Integrationsszenarien, die Sie bedenken sollten

1. Integration von SAP mit Nicht-SAP-Systemen

SAP muss sich oft mit Plattformen wie Salesforce, Oracle oder branchenspezifischen Tools verbinden. Diese Integrationen sichern die Kontinuität über kritische Geschäftssysteme und -prozesse hinweg.

Ermöglicht strukturierten Datenaustausch zwischen SAP und Drittplattformen
Umfasst Authentifizierung, Feld-Mapping und Transformationsschichten
Hilft, bestehende Geschäftsabläufe zu erhalten, während SAP ausgerollt wird

2. Hybride Landschaften (On-Premise / Cloud)

Die meisten SAP-Kunden betreiben hybride Umgebungen. On-Premise-Systeme von SAP koexistieren mit Cloud-Plattformen, sodass Integration für Datenkonsistenz und geschäftliche Flexibilität unverzichtbar ist.

Verbindet SAP ECC oder S/4HANA mit Cloud-Produkten wie SuccessFactors oder Ariba
Überbrückt unterschiedliche Protokolle und Sicherheitsmodelle
Erfordert starke Governance, um Latenz und Synchronisationsprobleme zu vermeiden

3. Echtzeit- und Batch-Integration

Die Wahl zwischen Echtzeit- und Batch-Integration hängt von den Fähigkeiten der Systeme, dem Datenvolumen und dem Geschäftsbedarf ab. Nicht alle Prozesse profitieren gleichermaßen von sofortiger Datensynchronisation.

Echtzeit eignet sich gut für Transaktionen wie Auftragsanlage oder Bestandsaktualisierungen
Batch ist besser für große Datenmengen wie Preise, Stammdaten oder historische Datenladungen
Die meisten Landschaften nutzen beides, je nach Kritikalität des Prozesses

4. API-basierte Integration

API-basierte Integrationen erlauben es Anwendungen, über schlanke Protokolle direkt miteinander zu kommunizieren. Sie eignen sich gut für Cloud-native Dienste und moderne Entwicklungsumgebungen.

Ideal, um SAP mit mobilen Apps, Portalen oder Microservices zu verbinden
Schneller bereitzustellen, braucht aber strikte Versionierung und Sicherheitsmaßnahmen
Häufig im Einsatz mit SAP API Management und OData-Services

5. Middleware-basierte Integration

Middleware schafft einen zentralen Kontrollpunkt, um SAP mit mehreren Systemen zu integrieren. Sie hilft, Komplexität durch Orchestrierung, Nachrichtenwarteschlangen und Datentransformation zu beherrschen.

Im Einsatz in Landschaften, in denen mehrere Systeme mit SAP interagieren
Bietet zentrales Monitoring und zentrale Fehlerbehandlung
Beispiele: SAP PI/PO, SAP Integration Suite, MuleSoft, Dell Boomi

6. Gemischte Integrationsansätze

Die meisten Unternehmen nutzen eine Kombination aus API- und Middleware-Strategien. Dieses hybride Modell passt sich an Systemgrenzen, Fähigkeiten des Teams und langfristigen Supportbedarf an.

Kombiniert direkte und verwaltete Integrationsmethoden
Schafft Flexibilität für künftige Erweiterungen oder Tool-Wechsel
Hilft, die Integration an technischen und fachlichen Prioritäten auszurichten

3. Überblick über die SAP Integration Suite

Wenn es um SAP-Integration geht, ist die Wahl der richtigen SAP-Integrationsplattform wichtiger, als die meisten Teams erwarten. Die Entscheidung geht über Funktionen und Geschwindigkeit hinaus. Sie kann Zeitpläne, Supportmodelle und sogar die Lizenzierung beeinflussen. Ich habe erlebt, wie Projekte ins Stocken gerieten, nicht weil die Integration scheiterte, sondern weil die Plattform nicht zur Arbeitsweise des Unternehmens passte.

SAP bietet mehrere Integrationsoptionen: manche älter, manche neuer und manche, die sich stärker überschneiden, als man denkt. Es gibt oft Streit darüber, welches Tool man nehmen soll. Es kommt natürlich darauf an. Darauf, was Sie verbinden. Darauf, wie Daten fließen müssen. Darauf, was das Team kann.

Kein Tool deckt alles ab. Jedes bringt Kompromisse mit sich. Wenn Sie aber verstehen, wo jedes am besten passt, ergibt das Gesamtbild mehr Sinn.

Hier ein kurzer Überblick über die am weitesten verbreiteten SAP-Integrationsplattformen, so, wie sie in realen Projekten tatsächlich eingesetzt werden, und nicht nur so, wie SAP sie vermarktet.

SAP-Integrationsplattformen

1. SAP PI / PO (Process Integration / Orchestration)

PI/PO ist seit Jahren der Standard für die On-Premise-Integration von SAP. Es übernimmt Nachrichtentransformationen, Workflows und verschiedene Protokollkonvertierungen. Es ist zuverlässig, wirkt in dynamischeren Umgebungen aber etwas schwerfällig. Trotzdem erledigt es die Aufgabe, wenn komplexe Backend-Logik im Spiel ist.

Gut geeignet für SAP-zu-SAP- und Altsystem-Integrationen
Unterstützt IDoc, BAPI, RFC, SOAP und mehr
Häufig in ECC-basierten oder hybriden Setups im Einsatz

2. SAP CPI / Integration Suite

SAP CPI ist anpassungsfähiger und für Cloud-First- und hybride Landschaften ausgelegt. Der Einstieg fällt leichter, besonders für Teams, die neu bei SAP sind. Die vorgefertigten iFlows helfen, aber echte Anpassung braucht trotzdem Zeit. Für die meisten neuen S/4HANA-Projekte ist das in der Regel die Standardwahl.

Unterstützt Cloud- und Hybrid-Integrationen
Enthält wiederverwendbare Content-Pakete und Adapter
Teil des Lizenzmodells der SAP Integration Suite

3. SAP API Management

Stärker auf Governance ausgerichtet als auf die eigentliche Bewegung von Daten. API Management hilft Ihnen zu steuern, wer unter welchen Bedingungen auf was zugreift. Denken Sie eher an ein Eingangstor als an ein Lieferfahrzeug. Nützlich ist es, wenn APIs für Partner oder interne Konsumenten bereitgestellt werden.

Dient der Verkehrssteuerung, Drosselung (Throttling) und Authentifizierung
Nützlich, wenn SAP-APIs für externe Anwendungen bereitgestellt werden
Ergänzt häufig CPI oder andere Backend-Tools

4. SAP BTP Integration Services

Das ist ein breiterer Rahmen, der CPI, API Management, Ereignisverarbeitung und mehr umfasst. Er gibt Ihnen einen zentralen Ort, um Tools zu verwalten, doch die Tools selbst verhalten sich weiterhin ziemlich eigenständig. Der Wert liegt darin, sie gebündelt und lose vereinheitlicht zu haben.

Kombiniert mehrere SAP-Integrationskomponenten
Zentraler Zugriff über das SAP BTP Cockpit
Nützlich für Integrationslandschaften mit mehreren Tools

5. SAP Data Intelligence

Data Intelligence ist für den Fall gedacht, dass Daten in einer strukturierten Pipeline über Plattformen hinweg fließen müssen. Denken Sie eher an Analytik als an Transaktionen. Es verbindet SAP mit Data Lakes, ML-Tools oder anderen externen Quellen, die nicht Teil der täglichen Prozessabläufe sind.

Konzentriert sich auf Datenorchestrierung über Plattformen hinweg
Integriert sich in Analytics- und Machine-Learning-Stacks
Am besten für Datenpipelines, nicht für hochfrequente Transaktionen

6. Das richtige Tool auswählen

Die eine „beste“ Plattform gibt es nicht. Das richtige Tool hängt davon ab, was integriert wird, wie groß die Integration ist und wie viel Flexibilität gebraucht wird. Manchmal kommt es darauf an, womit Ihr Team bereits vertraut ist. Auch das zählt.

Beginnen Sie mit dem Anwendungsfall, nicht mit dem Tool
Bewerten Sie Lizenzierung, Verfügbarkeit von Fachkräften und Supportmodell
Oft werden mehrere Tools parallel eingesetzt

Integrationsplattformen von Drittanbietern, die mit SAP funktionieren

1. Dell Boomi

Dell Boomi bietet eine cloudbasierte Low-Code-Plattform, die sich gut für Organisationen eignet, die eine schnelle Bereitstellung und wiederverwendbare Integrationen brauchen. Sie verbindet sich über vorgefertigte Konnektoren mit SAP und bewältigt Echtzeit- wie Batch-Abläufe effektiv.

Low-Code-Oberfläche für eine schnellere Umsetzung
Verbindet SAP mit Cloud-Anwendungen, CRMs und Altsystemen
Gute Wahl für mittelgroße Unternehmen mit hybridem Bedarf

2. MuleSoft

MuleSoft wird oft in Unternehmen mit umfangreichem Integrationsbedarf über SAP hinaus eingesetzt. Es bietet API-led Connectivity und eine reichhaltige Entwicklererfahrung. Die SAP-Konnektoren sind stark, doch die gute Konfiguration kann anfangs mehr Aufwand erfordern.

API-first-Modell für flexibles Service-Design
Wird eingesetzt, wenn SAP in eine breitere Unternehmensarchitektur integriert wird
Besser geeignet für komplexe oder verteilte Systeme

3. Informatica

Informatica glänzt in datenintensiven Umgebungen. Es wird häufig für Integrationen gewählt, bei denen ETL, Stammdatenmanagement oder Analytik im Mittelpunkt stehen. Die direkte SAP-Integration wird unterstützt, ist aber meist weniger auf Echtzeit ausgerichtet als bei anderen Plattformen.

Ideal für Datenbewegung und -bereinigung in großen Mengen
Wird oft mit SAP für Reporting- oder MDM-Anwendungsfälle kombiniert
Passend für Organisationen mit ausgereiften BI-Umgebungen

4. Wann Plattformen von Drittanbietern sinnvoll sind

Manchmal passen die nativen Tools von SAP nicht, besonders in gemischten Systemlandschaften. Ein Tool eines Drittanbieters bietet vielleicht bessere Konnektoren, einfachere Oberflächen oder passt schlicht zu den bestehenden internen Gepflogenheiten.

Wenn Teams bereits auf externen Plattformen geschult sind
Wenn SAP nur ein Teil einer viel größeren Architektur ist
Wenn Echtzeit, Low-Code oder fortgeschrittene Datenintegration gefragt sind

5. Lizenzierung und Kostenfaktoren

Die Lizenzierung kann sich je nach Plattform stark unterscheiden. SAP-Tools bündeln die Integration oft in bestehende Subskriptionen. Tools von Drittanbietern bieten vielleicht Flexibilität, doch die Preismodelle können je nach Volumen oder Nutzerzahl schnell wachsen.

Bewerten Sie die Kosten anhand von Transaktionsvolumen und Konnektoren
Achten Sie auf Überschneidungen mit bereits lizenzierten SAP-Funktionen
Betrachten Sie die Gesamtbetriebskosten (TCO), nicht nur die Lizenzgebühren

6. Wartung und Support der Integration

Plattformen von Drittanbietern erfordern möglicherweise andere Supportmodelle. Manche bieten starken Herstellerrückhalt, andere hängen stark von internem Know-how ab. Die langfristige Wartung sollte Teil der Entscheidung sein, nicht nur die Geschwindigkeit der Ersteinrichtung.

Prüfen Sie SLAs und Update-Zyklen der Anbieter
Berücksichtigen Sie internes Wissen oder den Bedarf an externen Beratern
Planen Sie Governance, Versionierung und Sicherheitsupdates ein

4. Die richtigen Komponenten der SAP Integration Suite auswählen

Das perfekte Integrationstool gibt es nicht. Was in einem SAP-Projekt funktioniert, erzeugt in einem anderen unnötigen Mehraufwand. Die Auswahl der richtigen Komponenten der SAP Integration Suite hängt von der Landschaft ab, mit der Sie arbeiten, und von der Art des Drucks, unter dem Ihre Integrationen stehen werden: technisch, betrieblich und manchmal sogar politisch.

Grenzen Sie das Feld zunächst anhand einiger Kriterien ein:

Systemlandschaft: Wie viele Systeme sind beteiligt? Sind es alles SAP-Systeme oder ein Mix aus Cloud- und Nicht-SAP-Tools?
Latenzanforderungen: Müssen Daten sofort fließen, oder ist eine Verzögerung akzeptabel?
Erweiterbarkeit: Kommen häufig neue Systeme hinzu? Ist Flexibilität wichtiger als Standardisierung?
Volumen: Bewegen Sie ein paar Datensätze pro Stunde oder Zehntausende pro Minute?

Hier ein grober Überblick, wie Plattformen zu verschiedenen Anforderungen passen:

SAP-zu-SAP - PI/PO oder CPI
Cloud-zu-Cloud - CPI, MuleSoft, Boomi
API-Management - SAP API Management, MuleSoft
ETL mit hohem Volumen - Informatica, SAP Data Intelligence
Komplexe Orchestrierung - PI/PO, MuleSoft, BTP Integration Services

5. SAP Integration Suite mit Oracle, Microsoft und Salesforce

In realen SAP-Landschaften arbeitet SAP selten isoliert. Viele Umgebungen enthalten große, geschäftskritische Plattformen wie Oracle, Microsoft oder Salesforce. Jede bringt eigene Integrationsherausforderungen mit: manche technisch, manche strukturell und manche, die in lizenzrechtliche Grauzonen fallen.

1. SAP ↔ Oracle (ERP, HR, SCM)

SAP und Oracle existieren in größeren Unternehmen oft nebeneinander. Das eine System kümmert sich um Finanzen, das andere um Lieferkette oder Personal. Die beiden zu einem verlässlichen Datenaustausch zu bringen, kann sich anfangs zäh anfühlen, besonders wenn sich die Modelle stärker unterscheiden als erwartet.

Oracle-Tabellen müssen oft über APIs oder Staging-Schichten bereitgestellt werden
SAP sendet meist IDocs oder nutzt BAPIs, die übersetzt werden müssen
Das Timing ist entscheidend: Batch-Fenster können Synchronisationsverzögerungen verursachen
Risiken durch indirekten Zugriff sind häufig, wenn Oracle-Anwendungen SAP-Prozesse automatisch auslösen

2. SAP ↔ Microsoft (Azure, Power Platform, M365)

Microsoft und SAP berühren sich an mehr Stellen, als die meisten erwarten. Ob Power BI Daten aus SAP zieht oder Teams Live-KPIs anzeigt: Die Verbindungen nehmen zu. Die Integration erfordert aber eine sorgfältige Einrichtung. Manches läuft reibungslos. Anderes weniger.

Azure Logic Apps können SAP-APIs aufrufen, aber Zugangsdaten müssen sorgfältig verwaltet werden
Die Power Platform bietet Konnektoren, braucht für komplexe Abläufe aber eventuell eigene Funktionen
Microsoft 365 (etwa Excel) wird oft genutzt, um SAP-Daten offline zu bearbeiten und dann zurück zu synchronisieren. Dieses Setup kann unbemerkt Lizenzprobleme verursachen, wenn es nicht nachverfolgt wird

Die Konnektivität zwischen SAP und Azure verbessert sich, doch hybride Modelle brauchen weiterhin eine starke Authentifizierung, besonders wenn On-Premise-Systeme beteiligt sind.

3. SAP ↔ Salesforce (Kundendaten, Aufträge, Support)

Salesforce ist fast immer kundennah. SAP übernimmt das Backend. Beide zu verbinden bedeutet meist, Kundenstammsätze, Auftragsstatus und Servicehistorie zu synchronisieren.

Für diese Abläufe sind SAP CPI oder MuleSoft üblich
Die Objektmodelle unterscheiden sich: Salesforce ist flexibler, SAP starrer
API-Ratenlimits in Salesforce können Synchronisationen mit hohem Volumen ausbremsen
Risiko indirekter Lizenzierung, wenn Salesforce SAP-Transaktionen ohne lizenzierten Nutzer auslöst

Manchmal wirken diese Verbindungen einfach. Sobald aber das Volumen steigt oder sich der Prozess mitten im Projekt ändert, zeigt sich die Komplexität. Diese Ausnahmen früh einzuplanen, ist selten vergebliche Mühe.

CPI-Integration

6. Was ist indirekte Lizenzierung?

Indirekte Lizenzierung entsteht, wenn Systeme außerhalb von SAP im Hintergrund mit SAP interagieren. Niemand meldet sich direkt in SAP an, und trotzdem hängen Geschäftsprozesse davon ab. Ein typisches Beispiel: Salesforce legt automatisch Kundenaufträge in SAP an, ohne dass ein SAP-Nutzer den Bildschirm berührt. Das zählt.

SAP nennt das „indirekten Zugriff“. Und das ist wichtig, denn es gilt weiterhin als lizenzpflichtiges Ereignis, selbst wenn der Nutzer SAP nie zu Gesicht bekommt.

Um damit umzugehen, hat SAP das Digital-Access-Modell eingeführt, das den Schwerpunkt von Nutzern auf Belege verlagert.

Typische Auslöser sind unter anderem:

Ein Portal eines Drittanbieters, das Aufträge in SAP schreibt
Eine mobile App, die Lagerbestände über eine API abfragt
Ein Bot, der Kundendaten aktualisiert, ohne sich anzumelden
Ein CRM, das Preise in Echtzeit aus SAP abruft

Wo die Grenze verläuft, ist nicht immer klar. Wenn SAP aber etwas im Auftrag eines anderen Systems verarbeitet, lohnt sich eine Prüfung.

7. Überlegungen zu Lizenzierung und Compliance (direkt + indirekt)

Die Lizenzierung in SAP-Projekten kommt tendenziell spät aufs Tapet, manchmal erst, nachdem Integrationsentscheidungen bereits getroffen wurden. Aber sie zählt. Mehr, als die meisten erwarten. Besonders dann, wenn Drittsysteme ohne Named User aus SAP lesen oder in SAP schreiben.

Im Kern geht es oft um direkten und indirekten Zugriff. Direkter Zugriff ist unkompliziert. Ein Named User von SAP meldet sich an, löst einen Prozess aus, und diese Handlung ist lizenziert. Indirekter Zugriff liegt vor, wenn ein externes System (Salesforce, ein individuelles Portal, vielleicht sogar ein Bot) im Hintergrund mit SAP interagiert. Auch das kann nach den Bedingungen von SAP als Nutzung zählen.

Um das zu regeln, hat SAP das Digital-Access-Modell eingeführt. Statt nach Nutzern abzurechnen, zählt es die Anzahl bestimmter Belegarten, die über indirekten Zugriff entstehen. Dazu gehören etwa Kundenaufträge, Rechnungen oder Materialbewegungen. Auf dem Papier ist das klarer. In der Praxis gibt es weiterhin Grauzonen.

Compliance-Risiken entstehen oft durch gut gemeinte Automatisierungen. Zum Beispiel:

Eine mobile App, die Preise ohne Nutzeranmeldung aus SAP abruft
Ein CRM, das automatisch Kundenstammsätze in SAP anlegt
Ein Planungstool, das stündlich Lagerbestände prüft

Das alles ist nützlich. Es kann aber ein Lizenzrisiko auslösen, wenn es nicht ordentlich nachverfolgt und gemeldet wird.

Es gibt Wege, die Kosten zu steuern. SAP bietet mit dem Digital Access Adoption Program (DAAP) Anreize für den Wechsel zur belegbasierten Lizenzierung. Manche Unternehmen setzen außerdem Tools zur Nutzungsüberwachung ein (SAP Passport oder externe Logging-Tools), um zu verfolgen, wo das Risiko liegt.

Audits sind ein eigenes Kapitel. Sie können technisch, kommerziell oder beides sein. Manche Audits sind vorhersehbar. Andere weniger. So oder so ist Proaktivität meist günstiger, als überrascht zu werden.

1. Salesforce legt Kundenaufträge in SAP an

Vertriebsmitarbeiter erfassen Abschlüsse in Salesforce, das die Auftragsdaten dann automatisch an SAP sendet. Kein SAP-Nutzer meldet sich an, aber im Backend entstehen Belege.

Das Problem: Kundenaufträge entstehen über indirekten Zugriff, der unter die digitale Lizenzierung von SAP fällt.
Gegenmaßnahme: Nutzen Sie das Digital-Access-Modell von SAP und zählen Sie diese als Belege, oder gestalten Sie den Ablauf so um, dass er über Workflows von Named Usern in SAP ausgelöst wird.

2. Individuelles Portal liest Preise aus SAP

Ein öffentliches oder partnerseitiges Webportal zeigt Echtzeitpreise an, die per API aus SAP abgerufen werden. Es wird keine SAP-Authentifizierung verwendet.

Das Problem: Der Zugriff auf Preisdaten umgeht Named User und legt das SAP-Backend ohne Nachvollziehbarkeit offen.
Gegenmaßnahme: Leiten Sie den Zugriff über SAP API Management und setzen Sie eine saubere Nutzerauthentifizierung oder Quotenkontrollen ein.

3. Mobile App prüft die Bestandsverfügbarkeit

Lagerteams nutzen eine mobile App, die den aktuellen SAP-Bestand abfragt, ohne sich direkt in SAP anzumelden.

Das Problem: Auf die Daten wird indirekt zugegriffen, und je nach Volumen oder Häufigkeit kann das eine Lizenzhaftung auslösen.
Gegenmaßnahme: Lizenzieren Sie die mobilen Nutzer oder stellen Sie sicher, dass der Zugriff die Schwellenwerte der belegbasierten Lizenzierung einhält.

4. E-Commerce-Plattform erstellt Rechnungen

Online-Käufe führen zu automatisierten Rechnungsbuchungen in SAP. Der Prozess läuft vollständig von System zu System, ohne dass ein SAP-Nutzer beteiligt ist.

Das Problem: Die Rechnungserstellung ist nach dem Digital-Access-Modell von SAP ein lizenzpflichtiges Ereignis, wenn sie indirekt erfolgt.
Gegenmaßnahme: Beziehen Sie Rechnungsbelege in Ihre Zählung der Digital-Access-Lizenzen ein und beobachten Sie die Volumentrends.

5. HR-System schreibt Mitarbeiterdaten nach SAP

Eine HR-Software eines Drittanbieters verwaltet die Mitarbeiterstammdaten und aktualisiert SAP HCM über Batch-Jobs.

Das Problem: Die Anlage von Stammdaten ohne lizenzierten SAP-Nutzer kann je nach Verarbeitung der Daten nicht konform sein.
Gegenmaßnahme: Klären Sie mit SAP, ob diese als lizenzpflichtige Belege gelten, und führen Sie eine Nutzungsverfolgung ein oder leiten Sie die Vorgänge über Named User.

6. BI-Tool zieht regelmäßig Berichte aus SAP

Reporting-Plattformen wie Power BI oder Tableau verbinden sich zeitgesteuert über OData oder JDBC mit SAP-Tabellen und ziehen still Daten.

Das Problem: Häufige Datenextraktion kann gegen Zugriffsrichtlinien verstoßen, wenn sie nicht authentifiziert ist oder die Nutzer nicht lizenziert sind.
Gegenmaßnahme: Leiten Sie den Zugriff über autorisierte Reporting-Nutzer oder nutzen Sie SAP-zertifizierte Analytics-Konnektoren, die die Lizenzierung korrekt nachverfolgen.

8. Wie kann ich Ihnen helfen?

Nach 25 Jahren in SAP und digitaler Transformation habe ich Projekte vom Kickoff bis zum Go-live gesehen, und auch die chaotische Mitte, über die niemand spricht. Manchmal führe ich von Anfang an. Ein andermal werde ich geholt, um das Schiff zu stabilisieren, wenn etwas schiefläuft.

So oder so ist meine Rolle dieselbe: zusammenzubringen, was das Unternehmen wirklich braucht und was das System tatsächlich liefern kann. Kein Fachjargon. Kein Füllmaterial. Was Sie hier finden, ist keine Theorie. Es ist geprägt von Jahren im Feld, in denen ich echte Probleme unter echtem Druck gelöst habe.

Anforderungen aufnehmen

9. Best Practices für die Integration

Früh im Projekt heißt Integration meist, dass etwas funktionieren muss. Daten von einem System ins andere bewegen, ein paar Haken setzen und weitermachen. Die eigentliche Herausforderung zeigt sich später, wenn etwas leise kaputtgeht oder sich niemand mehr erinnert, wie die Schnittstelle überhaupt eingerichtet wurde.

Bei Best Practices geht es nicht darum, einem starren Standard zu folgen. Es geht darum, vermeidbare Risiken zu verringern. Das kann bedeuten, eine stärkere Authentifizierung zu nutzen oder das Monitoring einzurichten, bevor die Last wächst. Manchmal heißt es einfach, mehr zu dokumentieren, als es zum jeweiligen Zeitpunkt nötig erscheint.

Einige Dinge halten Integrationen langfristig gesund:

Nutzen Sie sichere Protokolle wie OAuth2, SAML oder X.509
Richten Sie Monitoring ein, auch wenn der Ablauf einfach wirkt
Bauen Sie iFlows oder APIs, die sich wiederverwenden oder erweitern lassen
Dokumentieren Sie, wie es funktioniert und was bei einem Ausfall zu tun ist

Diese Schritte sind selten dringend. Später sparen sie aber Stunden. Manchmal Tage.

1. Jeden Integrationspunkt absichern

Sicherheit wird tendenziell spät angegangen, meist kurz vor dem Go-live. Dann ist sie aber am schwersten nachzubessern. Nutzen Sie je nach Szenario OAuth2, SAML oder Zertifikate. Und wenn statische Zugangsdaten verwendet werden, protokollieren und rotieren Sie sie ordentlich. Lassen Sie sie nicht einfach in einer Konfigurationsdatei liegen und hoffen, dass es niemand vergisst.

Nutzen Sie Verschlüsselung durchgängig, nicht nur nach außen
Wählen Sie Authentifizierungsprotokolle nach dem Datenrisiko
Testen Sie Ablauf und Erneuerung von Tokens frühzeitig

2. Von Anfang an überwachen

Monitoring wird oft nach einem Vorfall ergänzt. Es wirkt aber am besten, wenn es da ist, bevor etwas kaputtgeht. Schon minimales Logging hilft. Es geht nicht um aufwendige Dashboards. Es geht darum zu wissen, was ausgefallen ist, wann und warum. Ohne das kann selbst ein kleines Problem Stunden der Ursachensuche kosten.

Richten Sie Alarme für Fehler und Timeouts ein
Protokollieren Sie Antwortzeiten und Wiederholungsversuche
Nutzen Sie vorhandenes SAP-Monitoring, falls verfügbar

3. Für Wiederverwendung entwerfen, nicht für den Moment

Es ist verlockend, das akute Problem mit einer schnellen, fest verdrahteten Lösung zu beheben. Aber jede Einzellösung erzeugt später Reibung. Wiederverwendbare iFlows, gemeinsame Transformationslogik und parametrisierte Eingaben sparen Zeit, wenn sich Prozesse weiterentwickeln, was fast immer der Fall ist.

Nutzen Sie Vorlagen, wo immer möglich
Vermeiden Sie Geschäftsregeln in Mapping-Schritten
Trennen Sie Logik von Transportschichten

4. Mit Blick auf den Betrieb dokumentieren

Die Dokumentation endet tendenziell mit der Designphase. Support-Teams brauchen aber mehr als Diagramme. Sie müssen wissen, was passiert, wenn der Endpunkt ausfällt oder ein Feld fehlt. Gute Dokumentation beantwortet diese Fragen, bevor Tickets entstehen.

Nehmen Sie Wiederholungslogik, Fehlerbehandlung und Versionsangaben auf
Beschreiben Sie Annahmen über vor- und nachgelagerte Systeme
Halten Sie die Dokumente aktuell, wenn sich Abläufe ändern

5. Klare Verantwortung zuweisen

Manche Integrationen laufen monatelang, bevor jemand merkt, dass sie niemandem gehören. Fällt eine aus, nimmt jeder an, dass jemand anderes sie im Blick hat. Vermeiden Sie das. Weisen Sie Verantwortung zu. Auch informell. Dieser eine Schritt reduziert Ausfallzeiten stärker als die meisten technischen Korrekturen.

Legen Sie die Verantwortung für jeden Ablauf oder jede Schnittstelle fest
Stellen Sie sicher, dass der Verantwortliche Zugriff auf Logs und Tools hat
Nehmen Sie die Verantwortung in Onboarding- und Übergabedokumente auf

6. Für Veränderung bauen, nicht nur für den Start

Schnittstellen sind nicht statisch. Felder ändern sich. APIs werden versioniert. Volumen wachsen. Ist der Ablauf zu starr, bricht er schon bei kleinen Änderungen. Planen Sie Anpassungen von Anfang an ein, auch wenn die Anforderungen jetzt stabil wirken.

Nutzen Sie Versionskontrolle für Mappings und Konfigurationen
Dokumentieren Sie bekannte Grenzen und Einschränkungen klar
Überprüfen Sie Integrationsabläufe in den Release-Zyklen

10. Gesamtkosten und ROI

Integrationsprojekte beginnen oft mit technischen Zielen: Systeme verbinden, Daten synchronisieren, alles zum Laufen bringen. Darunter spielen die Kosten aber eine größere Rolle, als die meisten bemerken. Nicht nur die Lizenzen am Anfang, sondern die Kosten, die später auftauchen: wenn Lasten skalieren, Anforderungen sich verschieben oder ein Provisorium zum Dauerzustand wird.

Cloud-Tools wie SAP CPI wirken anfangs vielleicht kostengünstiger. Keine Hardware, schnellere Einrichtung. Bei nutzungsbasierter Preisgestaltung können die Kosten aber mit dem Volumen steigen. On-Premise-Optionen wie PI/PO sind preislich stabiler, bringen aber Infrastrukturaufwand mit.

Dann gibt es die Plattformen von Drittanbietern. Jede mit eigenem Lizenzmodell: manche rechnen nach Nutzern ab, andere nach Transaktionen oder Konnektoren. Das summiert sich.

Integration unter dem Gesichtspunkt des ROI zu betrachten heißt, mehr zu fragen als „Was kostet es jetzt?“. Es heißt, nach vorn zu schauen. Wie skaliert das? Und wer zahlt, wenn es sich ändern muss?

1. Kosten von Cloud und On-Premise

Cloud-Plattformen wie SAP CPI bieten eine schnellere Einrichtung und geringere Infrastrukturkosten, doch die Preise skalieren oft mit der Nutzung. On-Premise-Tools wie PI/PO erfordern mehr Anfangsinvestition, können aber über die Zeit Kostenstabilität bieten, besonders wenn die Hardware bereits vorhanden ist.

Cloud: abonnementbasiert, oft pro Nachricht oder Verbindung
On-Premise: CAPEX-lastig, mit niedrigeren laufenden Lizenzkosten
Die Preise hängen vom Systemvolumen und vom IT-Fußabdruck ab

2. Auswirkungen der SAP-CPI-Lizenzierung

SAP CPI nutzt ein gestaffeltes, nutzungsbasiertes Modell. Abgerechnet wird nach Nachrichtenvolumen und Durchsatz. In Szenarien mit niedriger bis mittlerer Last ist es planbar, doch starker Datenverkehr oder nicht optimierte Abläufe können zu deutlichen Kostensteigerungen führen.

Einstiegsstufen beginnen typischerweise bei etwa 1.000 bis 2.000 €/Monat
Zusatzkosten für Nachrichten mit hohem Volumen oder nicht standardmäßige Adapter
Verfolgen Sie die Nutzung monatlich, um Kosten proaktiv zu steuern

3. Preise für Middleware von Drittanbietern

MuleSoft, Dell Boomi und Informatica folgen unterschiedlichen Preismodellen: pro Konnektor, pro Nutzer oder pro Transaktion. Der Grundpreis wirkt vielleicht erschwinglich, doch beim Skalieren stößt man oft auf Grenzen, die neue Gebühren auslösen.

MuleSoft: Lizenz + API-Volumen + Core-Packs (ca. 18.000 $ und mehr pro Jahr)
Boomi: pro Integrationsprozess, Konnektor oder Nutzerstufe
Informatica: Kosten abhängig von ETL-Volumen und Plattformdiensten

4. Änderungskosten im Zeitverlauf

Die Kosten der Ersteinrichtung sind nur ein Teil der Geschichte. Änderungen (neue Endpunkte, angepasste Mappings oder verschobene Geschäftsregeln) können zusätzliche Lizenz- oder Entwicklungskosten verursachen, besonders in starren Umgebungen.

Rechnen Sie in komplexen Landschaften mit 15 bis 30 % jährlichen Änderungskosten
Modularere Plattformen verringern tendenziell die Reibung bei Änderungen
Anpassungen können Lizenzerweiterungen oder Beratung erfordern

5. Support- und Wartungskosten

Support wird bei Kostenprognosen oft übersehen. SAP CPI enthält grundlegende Supportstufen, doch Reaktionszeiten und SLAs variieren. Tools von Drittanbietern bieten möglicherweise schnelleren Support, aber zu einem Preis, oder verlangen zusätzliche Serviceverträge.

SAP-Support ist an bestehende Unternehmensvereinbarungen gebunden
Tools von Drittanbietern können für den Support jährlich 15 bis 20 % der Lizenz berechnen
Der interne Supportbedarf kann mit der Systemkomplexität steigen

6. ROI über die Einrichtung hinaus bewerten

Der wahre ROI umfasst die Betriebskosten über die Zeit, nicht nur die Implementierung. Einer günstigeren Plattform fehlt vielleicht Flexibilität, während ein teureres Tool später Ausfallzeiten oder Änderungsaufwand senken kann. Bewerten Sie über den Lebenszyklus, nicht nur über den Start.

Berücksichtigen Sie die Summe aus Lizenz, Wartung, Support und Änderungskosten
Schätzen Sie den ROI über einen Horizont von 2 bis 3 Jahren, nicht nur über die Projektphase
Beziehen Sie die Kosten gescheiterter oder verzögerter Integrationen als mögliches Risiko ein

Häufig gestellte Fragen

Viele Kunden kreisen um dieselben Fragen, wenn sie zum ersten Mal über eine SAP-Implementierung nachdenken.

Vielleicht hatten Sie selbst einige davon: wie lange es wirklich dauert, was es kosten könnte oder welche Art von Support nach dem Go-live nötig ist. Berechtigte Fragen.

Statt Sie im Ungewissen zu lassen, habe ich klare, ehrliche Antworten zusammengestellt, damit Sie besser einschätzen können, was Sie erwartet und wo die heiklen Stellen meist auftauchen.

Nehmen wir Kontakt auf!

1. Was ist SAP CPI?

SAP CPI, kurz für Cloud Platform Integration, ist Teil der SAP Integration Suite. Es hilft, SAP und Nicht-SAP-Systeme zu verbinden, vor allem in Cloud- oder Hybridumgebungen. Stellen Sie es sich als Middleware vor, aber gebaut für verteilte Landschaften.

Es enthält:

Vorgefertigte Integrationsabläufe (iFlows genannt)
Unterstützung für Protokolle wie HTTPS, SFTP und OData
Optionen für individuelles Mapping, Scripting und Routing

CPI ist besonders nützlich beim Wechsel von On-Premise in die Cloud oder wenn Anwendungen von Drittanbietern sicher mit SAP kommunizieren müssen.

2. Wie integriert sich SAP mit Salesforce?

SAP und Salesforce tauschen Daten typischerweise über APIs oder Middleware wie SAP CPI, MuleSoft oder Dell Boomi aus.

Typische Anwendungsfälle sind:

Synchronisierung der Kundenstammdaten
Übertragung von Auftrags- und Rechnungsdetails
Austausch von Support-Fallhistorien oder Preisinformationen

Herausforderungen entstehen oft durch Unterschiede der Datenmodelle und API-Limits auf Salesforce-Seite. Sorgfältiges Mapping und Throttling sind entscheidend.

Auch die Lizenzierung kann ein Thema sein. Wenn Salesforce Aktionen in SAP auslöst, kann indirekter Zugriff vorliegen.

3. Was ist indirekter Zugriff bei SAP?

Indirekter Zugriff liegt vor, wenn externe Systeme mit SAP interagieren, ohne dass sich ein Nutzer direkt anmeldet. Zum Beispiel legt ein Portal oder eine Drittanbieter-App über eine API einen Kundenauftrag in SAP an.

SAP betrachtet das nach seinem Modell Digital Access als lizenzpflichtig, bei dem die Nutzung nach Belegart erfasst wird (Aufträge, Rechnungen usw.).

Das kann Teams unvorbereitet treffen. Systeme laufen leise im Hintergrund, erzeugen aber Belege, die ein Lizenzrisiko auslösen.

So gehen Sie damit um:

Bewerten Sie, wie externe Systeme SAP nutzen
Überwachen Sie das Volumen der Belegerstellung
Berücksichtigen Sie die digitale, belegbasierte Lizenzstruktur von SAP

4. Welches SAP-Integrationstool ist das beste?

Das hängt davon ab, was Sie integrieren, wie oft es sich ändert und wer es pflegt.

Für Cloud-zu-Cloud oder Hybrid: SAP Integration Suite (CPI)
Für On-Premise-SAP-zu-SAP: SAP PI/PO
Für API-Governance: SAP API Management
Für Datenpipelines und Analytik: SAP Data Intelligence
Für breitere Unternehmensintegration: MuleSoft oder Dell Boomi

Die meisten Landschaften nutzen einen Mix. Was „am besten“ ist, hängt stärker von der Passung ab als von Funktionen.

5. Kann sich SAP mit Microsoft und Oracle integrieren?

Ja, und das passiert oft.

SAP ↔ Microsoft

Azure Logic Apps, Power Automate oder SAP-Konnektoren in Power BI
Typische Nutzung: SAP-Daten in Excel, Teams oder Dashboards holen

SAP ↔ Oracle

Meist ist Middleware beteiligt (CPI, PI oder von Drittanbietern)
Anwendungsfälle sind Finanzen, Beschaffung oder HR-Integration

Zu den Herausforderungen zählen unterschiedliche Authentifizierungsmodelle, Timing-Abweichungen und in manchen Fällen die Lizenzierung.

6. Was ist die SAP Integration Suite?

Die SAP Integration Suite ist die Cloud-native Plattform von SAP, um Systeme, Anwendungen und Daten zu verbinden. Sie umfasst CPI, API Management, Open Connectors und Event-Mesh-Funktionen.

Sie können sie sich als Werkzeugkasten vorstellen. Manche Teile sind vorgefertigt, andere konfigurierbar. Sie ist für Cloud-First- und Hybridumgebungen ausgelegt.

Wichtigste Vorteile:

Vorgefertigter Content für gängige Integrationen
Echtzeit- und Batch-Verarbeitung
Werkzeuge für Sicherheit, Monitoring und Governance

Sie ist als strategische Integrationsschicht von SAP für moderne Landschaften positioniert.

7. Löst SAP CPI PI/PO ab?

In stark cloudgeprägten oder hybriden Landschaften ja: SAP CPI ist die bevorzugte Richtung. PI/PO wird aber weiterhin unterstützt und breit genutzt, besonders in ECC-basierten Systemen oder On-Premise-Setups.

SAP empfiehlt, mit der Zeit auf die Integration Suite umzusteigen, einen erzwungenen Wechsel gibt es aber nicht. Es hängt von Projekttiming, Systemfahrplan und Kosten ab.

Manche Unternehmen nutzen beides und führen CPI schrittweise ein.

8. Wie geht SAP mit API-Sicherheit um?

SAP unterstützt gängige Sicherheitsprotokolle:

OAuth2 für tokenbasierte Authentifizierung
SAML für föderierte Identität
X.509-Zertifikate für das Vertrauen zwischen Systemen

Die Integration Suite bietet außerdem API-Throttling, Quotendurchsetzung und Policy-Management. Die meisten Teams kombinieren die Sicherheitswerkzeuge von SAP mit unternehmenseigenen Identity-Providern wie Azure AD oder Okta.

Die Sicherheitsanforderungen unterscheiden sich je nach Szenario, planen Sie das also früh ein.

9. Was treibt die Kosten der SAP-Integration?

Mehrere Faktoren beeinflussen die Kosten:

Art des Tools (Cloud oder On-Premise)
Volumen der Transaktionen oder Nachrichten
Anzahl der Schnittstellen und Systeme
Lizenzmodell (z. B. ist CPI nutzungsbasiert)

So kann die Lizenzierung von SAP CPI anfangs niedrig wirken, aber mit dem Volumen schnell wachsen. Middleware von Drittanbietern rechnet möglicherweise nach Konnektor oder Nutzer ab.

Beziehen Sie in Ihre Schätzungen immer Support- und Änderungskosten ein, nicht nur die Lizenzgebühren.

10. Wie überwache ich SAP-Integrationen?

Die SAP Integration Suite enthält integrierte Monitoring-Dashboards, Logs und Trace-Werkzeuge. Sie können:

Nachrichtenprotokolle und Fehler in Echtzeit einsehen
Performance und Latenz verfolgen
Alarme für fehlgeschlagene oder langsame Abläufe einrichten

Bei On-Premise-Systemen wie PI/PO erfolgt das Monitoring in der Integration Engine oder über den SAP Solution Manager.

Entscheidend ist, das Monitoring früh einzurichten. Zu warten, bis etwas ausfällt, kostet meist mehr, als vorauszuplanen.

Erzählen Sie mir, woran Sie arbeiten.

Ein 30-minütiges Gespräch. Sie schildern das Programm, die Entscheidung oder das Problem. Ich sage Ihnen, ob ich helfen kann, und wenn nicht, wer es könnte.

Projekt besprechen

SAP Integration Suite: Tools, Lizenzierung und Praxisszenarien

Erzählen Sie mir, woran Sie arbeiten.