SAP Ariba mit S/4HANA oder ECC integrieren: Die wichtigsten Architekturen, Managed-Gateway-Szenarien und Integrationsoptionen im Überblick.

SAP Ariba mit SAP S/4HANA und ECC integrieren: Architektur, Szenarien und Managed Gateway

Eine SAP-Ariba-Integration klingt zunächst nach einer Schnittstellenfrage. In der Praxis entscheidet sie jedoch über deutlich mehr: Wo entstehen Bestellungen? Welches System führt Lieferanten- und Materialdaten? Wie gelangen Sourcing-Ergebnisse zurück ins ERP? Und was passiert mit der gesamten Architektur, wenn SAP ECC später durch SAP S/4HANA ersetzt wird?

Gerade in gewachsenen SAP-Landschaften reicht deshalb die Frage „Wie verbinden wir Ariba mit unserem ERP?“ nicht aus.

Unternehmen müssen entscheiden, welche Prozesse in SAP Ariba laufen, welche in SAP S/4HANA oder ECC verbleiben, welches System für welche Daten führend ist und welche Integrationskomponenten langfristig zur SAP-Roadmap passen.

Eine zentrale Rolle spielt dabei SAP Integration Suite, Managed Gateway for Spend Management and SAP Business Network – vielen SAP-Teams noch unter dem früheren Namen SAP Ariba Cloud Integration Gateway (CIG) bekannt. SAP unterstützt damit sowohl SAP ERP als auch SAP S/4HANA und bietet je nach Backend und Szenario unterschiedliche Integrationswege.

Dieser Leitfaden zeigt, wie die Architektur funktioniert, wann Managed Gateway, APIs oder zusätzliche Integration-Suite-Komponenten sinnvoll sind und welche Integrationsszenarien SAP 2026 für Ariba und S/4HANA vorsieht.

SAP Ariba mit S/4HANA oder ECC integrieren: Die Kurzantwort

SAP Ariba kann sowohl mit SAP S/4HANA als auch mit SAP ERP beziehungsweise ECC integriert werden.

Für beide Welten unterstützt SAP eine add-on-basierte Integration über den Managed Gateway. Dafür stehen separate Add-ons für SAP ERP und SAP S/4HANA zur Verfügung. Für SAP S/4HANA gibt es zusätzlich API-basierte Integrationsmöglichkeiten; SAP beschreibt auch hybride Modelle, in denen Add-on und S/4HANA-APIs parallel eingesetzt werden.

Vereinfacht sieht das klassische Modell so aus:

SAP Ariba / SAP Business Network

↓

SAP Integration Suite, Managed Gateway for Spend Management and SAP Business Network

↓

SAP Cloud Connector / Integrationsschicht

↓

SAP S/4HANA oder SAP ECC

Der Managed Gateway übernimmt dabei unter anderem Mapping und Transformation und stellt Funktionen für die Überwachung von Transaktionen zwischen dem ERP und SAP-Ariba- beziehungsweise Business-Network-Lösungen bereit.

Für SAP S/4HANA kommen je nach Prozess standardisierte Integrationsszenarien hinzu, etwa:

• 2NV für Guided Buying,
• 4BL für SAP Ariba Sourcing,
• 4AZ für SAP Ariba Contracts,
• 4QN für Central Procurement mit SAP Ariba Sourcing,
• 3EN für Guided Buying mit Central Procurement.

Kurz erklärt: Managed Gateway ist die standardisierte SAP-Integrationsschicht zwischen SAP Ariba beziehungsweise SAP Business Network und SAP ERP/S/4HANA. Für S/4HANA können zusätzlich API-basierte Integrationsmuster relevant sein. Die richtige Architektur hängt jedoch nicht nur vom Backend, sondern vor allem vom jeweiligen Procurement-Prozess ab.

Wie sieht eine typische SAP-Ariba-Integrationsarchitektur aus?

Eine gute Integrationsarchitektur beginnt nicht mit Middleware. Sie beginnt mit der Trennung von fachlichen Verantwortlichkeiten.

Ein typisches Zielbild kann so aussehen:

Bedarfsträger, Einkauf und Lieferanten

↓

SAP Ariba
Guided Buying · Sourcing · Contracts · Supplier Management

↕

SAP Integration Suite, Managed Gateway for Spend Management and SAP Business Network

↕

SAP S/4HANA / SAP ECC
Materialwirtschaft · Bestellungen · Bestand · Logistik · Finance

↕

SAP Business Network
Lieferanten · Bestellkommunikation · Kollaboration · Rechnungsprozesse

Diese Darstellung ist bewusst vereinfacht. In realen Landschaften können zusätzliche Komponenten hinzukommen:

• SAP Integration Suite,
• SAP Cloud Connector,
• bestehende Middleware,
• SAP Master Data Governance,
• Central Procurement,
• weitere SAP- oder Non-SAP-ERP-Systeme,
• kundenspezifische Anwendungen und APIs.

Entscheidend ist, welche Komponente welche Aufgabe übernimmt.

SAP Ariba: Procurement- und Supplier-Layer

SAP Ariba übernimmt je nach eingesetzten Lösungen beispielsweise:

• Bedarfserfassung und Guided Buying,
• strategisches Sourcing,
• Lieferanten-Onboarding,
• Supplier Lifecycle Management,
• Supplier Risk,
• Vertragsprozesse,
• weitere Source-to-Pay-Funktionen.

SAP S/4HANA oder ECC: ERP- und Transaction Layer

Im ERP liegen typischerweise Prozesse und Daten, die unmittelbar mit:

• Materialwirtschaft,
• Bestandsführung,
• Werken,
• Kontierung,
• Wareneingang,
• Logistik,
• Rechnungsprüfung,
• Finance

verbunden sind.

Managed Gateway: standardisierte Integrationsschicht

Der Managed Gateway verbindet diese Welten und unterstützt SAP bei standardisierten Datenflüssen, Transformation, Mapping und Monitoring. SAP dokumentiert dafür Integrationen mit SAP ERP und S/4HANA sowie SAP Ariba und SAP Business Network.

Damit entsteht bereits ein wichtiges Architekturprinzip:

SAP Ariba und SAP S/4HANA sollten nicht dadurch integriert werden, dass möglichst viele Daten zwischen beiden Systemen repliziert werden. Integriert werden sollte nur, was ein definierter End-to-End-Prozess tatsächlich benötigt.

Was ist SAP Integration Suite, Managed Gateway for Spend Management and SAP Business Network?

Der Name ist lang. Die Aufgabe dahinter ist deutlich einfacher zu erklären.

SAP Integration Suite, Managed Gateway for Spend Management and SAP Business Network ist eine von SAP bereitgestellte Integrationslösung für die Verbindung von SAP-Ariba- und SAP-Business-Network-Szenarien mit Backend-Systemen wie SAP ERP und SAP S/4HANA.

SAP beschreibt die Lösung als SAP-managed Integration-as-a-Service und ordnet sie der Integration-Suite-Welt zu.

Was wurde aus SAP Ariba CIG?

Viele Unternehmen und SAP-Teams verwenden weiterhin den Begriff:

SAP Ariba Cloud Integration Gateway oder kurz CIG.

Das ist nicht überraschend, denn CIG war jahrelang die etablierte Produktbezeichnung.

SAP hat SAP Ariba Cloud Integration Gateway mit dem SAP-Ariba-Release 2302 in SAP Integration Suite, Managed Gateway for Spend Management and SAP Business Network umbenannt. Laut SAP änderte die Umbenennung selbst nichts an der Funktionalität.

Deshalb beziehen sich Begriffe wie:

• SAP Ariba CIG,
• Ariba Cloud Integration Gateway,
• CIG Integration,
• Managed Gateway,
• Managed Gateway for Spend & Network

in vielen Projekten auf dieselbe Produktentwicklung beziehungsweise deren aktuelle Bezeichnung.

Für neue Dokumentationen und Architekturentscheidungen sollte jedoch die aktuelle SAP-Terminologie verwendet werden.

Was übernimmt der Managed Gateway?

Zu den zentralen Aufgaben gehören unter anderem:

Mapping und Transformation

Datenstrukturen aus ERP und Ariba stimmen nicht immer unmittelbar überein. Der Gateway unterstützt die Transformation zwischen den jeweiligen Formaten.

Standardisierte Integrationsinhalte

Für unterstützte SAP-Szenarien stehen vordefinierte Integrationsinhalte und Prozesse zur Verfügung.

Custom Mapping

Wenn kundenspezifische Felder oder Werte berücksichtigt werden müssen, können zusätzliche Zuordnungen erforderlich sein. SAP sieht dafür Mapping-Funktionen innerhalb des Gateway-Modells vor.

Monitoring

Transaktionen zwischen SAP ERP/S/4HANA und Ariba beziehungsweise SAP Business Network können überwacht werden.

Connection Setup

Backend-Systeme, Verbindungen, Zertifikate und weitere technische Parameter werden im Integrationssetup konfiguriert.

Managed Gateway ist nicht dasselbe wie „normale Middleware“

Das ist für Architekturentscheidungen wichtig.

Der Managed Gateway ist speziell auf die Integration der SAP-Spend-Management- und Business-Network-Welt ausgerichtet.

Eine allgemeine SAP Integration Suite kann dagegen zusätzliche Aufgaben übernehmen, beispielsweise wenn:

• Non-SAP-Systeme eingebunden werden,
• zusätzliche Routinglogik notwendig ist,
• mehrere Integrationsdomänen orchestriert werden,
• kundenspezifische Transformationen außerhalb des Standardflusses gebraucht werden.

Beides kann deshalb in derselben Landschaft vorkommen.

SAP Ariba mit SAP S/4HANA integrieren

Bei SAP S/4HANA stehen heute mehr Integrationsoptionen zur Verfügung als bei klassischen ECC-Landschaften.

SAP unterscheidet grundsätzlich zwischen add-on-basierter und API-basierter Integration. Für S/4HANA kann zudem ein hybrides Modell eingesetzt werden, in dem APIs und Add-on-basierte Integration koexistieren.

Add-on-basierte Integration

Bei diesem Modell wird das entsprechende Managed-Gateway-Add-on im SAP-S/4HANA-System installiert.

Das Add-on stellt die Verbindung zu den von Managed Gateway unterstützten Ariba- und Business-Network-Prozessen her.

Typisches Modell:

SAP Ariba

↓

Managed Gateway

↓

SAP Cloud Connector

↓

Managed-Gateway-Add-on

↓

SAP S/4HANA

Der SAP Cloud Connector kann dabei eine sichere Verbindung zwischen Cloud und Backend bereitstellen. SAP nennt ihn ausdrücklich als eine der Komponenten beziehungsweise Möglichkeiten zur sicheren Datenübertragung.

API-basierte Integration

Für SAP S/4HANA unterstützt SAP zusätzlich API-basierte Integrationsmuster.

Hierbei kommuniziert die Integration über unterstützte S/4HANA-APIs statt ausschließlich über ein klassisches Backend-Add-on.

Das bedeutet allerdings nicht:

„APIs sind neuer, also sollten wir grundsätzlich alle Add-ons ersetzen.“

Die richtige Entscheidung hängt vom unterstützten Geschäftsszenario ab.

SAP beschreibt ausdrücklich auch Coexistence beziehungsweise Hybrid Integration, bei der S/4HANA-APIs und das Add-on parallel genutzt werden können.

Welche Variante ist besser?

Für einen SAP Architect ist die sinnvollere Frage:

Welche Integrationsmethode unterstützt den Prozess möglichst standardnah und mit möglichst wenig kundenspezifischer Logik?

Wenn SAP einen etablierten Standardprozess bereitstellt, sollte dieser in der Regel zuerst bewertet werden.

APIs gewinnen an Bedeutung, wenn:

• der konkrete Prozess API-basiert unterstützt wird,
• stärker entkoppelte Architekturen benötigt werden,
• zusätzliche Anwendungen eingebunden werden,
• Echtzeit- oder serviceorientierte Integrationsmuster relevant sind.

Eine kundenspezifische Integration sollte dagegen nicht allein deshalb gebaut werden, weil sie technisch möglich ist.

SAP Ariba mit SAP ECC integrieren: Was ist 2026 noch sinnvoll?

SAP ECC verschwindet nicht aus einer Integrationslandschaft, nur weil ein S/4HANA-Programm gestartet wurde.

In vielen Unternehmen müssen Ariba und ECC noch für eine Übergangsphase gemeinsam funktionieren.

Und technisch ist das weiterhin vorgesehen: Die aktuelle SAP-Dokumentation für Managed Gateway umfasst ausdrücklich SAP ERP neben SAP S/4HANA und beschreibt ein dediziertes Add-on für die ERP-basierte Integration.

Typische ECC-Architektur

SAP Ariba / SAP Business Network

↓

Managed Gateway

↓

SAP Cloud Connector / Middleware

↓

Managed-Gateway-Add-on für SAP ERP

↓

SAP ECC / SAP MM / FI

Der Unterschied zu S/4HANA liegt vor allem darin, dass die moderne API-basierte S/4HANA-Option für ECC nicht in gleicher Form zur Verfügung steht. SAP beschreibt die API-basierte Variante ausdrücklich für SAP S/4HANA.

Wann lohnt sich eine neue Ariba-ECC-Integration noch?

Beispielsweise dann, wenn:

• das Ariba-Programm deutlich vor der S/4HANA-Transformation live gehen soll,
• ECC noch mehrere Jahre Teil der operativen Landschaft bleibt,
• der Procurement Business Case nicht auf die komplette ERP-Migration warten kann,
• mehrere Gesellschaften unterschiedliche ERP-Migrationszeitpunkte haben.

Die entscheidende Frage lautet dann allerdings nicht:

„Können wir Ariba noch mit ECC verbinden?“

Die Antwort darauf ist grundsätzlich ja.

Die wichtigere Frage lautet:

Wie gestalten wir die heutige ECC-Integration so, dass sie die spätere S/4HANA-Zielarchitektur nicht unnötig verteuert?

Genau hier werden Integrationsprojekte zu Architekturprojekten.

Mappings, Stammdatenverantwortung, Prozessgrenzen und Custom Extensions sollten bereits mit Blick auf das zukünftige S/4HANA-Modell entworfen werden.

Managed Gateway, SAP Integration Suite oder APIs: Was braucht man wirklich?

Diese Begriffe werden häufig gegeneinander gestellt, obwohl sie unterschiedliche Ebenen adressieren.

SAP nennt neben Cloud Connector auch bestehende Middleware-Optionen für die sichere Übertragung zwischen Managed Gateway und ERP/S/4HANA.

Für neue Architekturen würde ich deshalb mit einem einfachen Prinzip arbeiten:

Standardisieren, wo SAP Standard liefert. Orchestrieren, wo die Landschaft es verlangt. Individualisieren nur dort, wo ein echter Business Case besteht.

Denn jede zusätzliche individuelle Mapping- oder Middleware-Schicht muss später:

• getestet,
• überwacht,
• dokumentiert,
• aktualisiert,
• bei Releases überprüft,
• bei einer S/4HANA-Migration möglicherweise erneut angepasst

werden.

Welche SAP-Ariba-Integrationsszenarien gibt es?

Die wichtigste Verbesserung gegenüber einer generischen „Ariba-S/4HANA-Schnittstelle“ besteht darin, die Integration pro Business Process zu betrachten.

SAP stellt dafür definierte Scope Items und Integrationsszenarien bereit.

Guided Buying mit SAP S/4HANA: 2NV

Guided Buying Capability with SAP Ariba Buying (2NV) verbindet die geführte Einkaufserfahrung aus SAP Ariba Buying mit Procurement-Prozessen in SAP S/4HANA.

Im von SAP dokumentierten Szenario erstellt der Anwender seine Anforderung über Guided Buying. Die entsprechende Purchase Requisition wird anschließend in SAP S/4HANA angelegt und dort in die operativen Folgeprozesse eingebunden. Status- und Prozessinformationen werden zwischen den Systemen ausgetauscht.

Vereinfacht:

SAP Ariba Guided Buying
Bedarf · Katalog · User Experience · Policies

↓

Managed Gateway

↓

SAP S/4HANA
Purchase Requisition · Purchase Order · ERP-Prozess

Typischer Einsatz: Viele gelegentliche Einkäufer benötigen eine einfachere Buying Experience, während S/4HANA der operative Procurement-Core bleiben soll.

SAP Ariba Sourcing mit SAP S/4HANA: 4BL

Sourcing with SAP Ariba Sourcing (4BL) ermöglicht es, Beschaffungsbedarfe aus SAP S/4HANA für den Sourcing-Prozess in SAP Ariba zu verwenden.

SAP beschreibt 4BL als Szenario zur Identifikation von Bezugsquellen für Bestellanforderungen aus SAP S/4HANA unter Nutzung von SAP Ariba Sourcing.

Typischer Ablauf:

SAP S/4HANA
Purchase Requisition / Bedarf

↓

SAP Ariba Sourcing
Sourcing Request → Event → Lieferanten → Angebote → Award

↓

SAP S/4HANA
Folgeprozess / Bestellung

Damit bleibt der Bedarf ERP-nah, während die eigentliche Ausschreibung in einem spezialisierten Sourcing-System stattfindet.

Wichtig: 4BL statt älterem 1A0 für neue Implementierungen

SAP weist beim älteren Szenario Integration with SAP Ariba Sourcing (1A0) ausdrücklich auf den Nachfolger 4BL hin und empfiehlt, 1A0 nicht neu zu implementieren.

Das ist insbesondere für ältere Ariba-Landschaften relevant: Ein bestehendes Integrationsmuster sollte bei einem neuen S/4HANA-Projekt nicht automatisch übernommen werden.

SAP Ariba Contracts mit SAP S/4HANA: 4AZ

Mit Contract Management with SAP Ariba Contracts (4AZ) können strategische Vertragsprozesse aus SAP Ariba mit dem S/4HANA-Core verbunden werden.

SAP beschreibt dabei unter anderem die Übertragung relevanter Vertragsinformationen beziehungsweise Purchase Contracts in die S/4HANA-Welt.

Das ermöglicht eine klare Prozessaufteilung:

SAP Ariba Contracts
Verhandlung · Contract Workspace · Governance

↓

Integration

↓

SAP S/4HANA
operativer Einkaufskontrakt · Bestellung · Procurement-Ausführung

Central Procurement mit SAP Ariba Sourcing: 4QN

Für Multi-ERP- und Central-Procurement-Szenarien unterstützt SAP Central Procurement with SAP Ariba Sourcing (4QN).

Dabei können Bedarfe zentral orchestriert und an SAP Ariba Sourcing übergeben werden.

Typisches Zielbild:

Mehrere ERP-Backends

↓

Central Procurement

↓

SAP Ariba Sourcing

↓

Central Procurement / ERP

Das ist besonders relevant, wenn ein Konzern nicht nur Ariba mit einem ERP integrieren möchte, sondern Procurement über mehrere Backend-Systeme hinweg zentralisieren muss.

Guided Buying mit Central Procurement: 3EN

Mit Guided Buying for Central Procurement with SAP Ariba Buying (3EN) kann Ariba die nutzerorientierte Bedarfserfassung übernehmen, während Central Procurement die weitere Orchestrierung Richtung Backend steuert.

Ein typischer Flow:

Guided Buying

↓

Central Procurement

↓

zuständiges ERP-Backend

Damit lassen sich User Experience, zentrale Procurement-Steuerung und operative ERP-Verarbeitung voneinander trennen.

Achtung bei älteren Procure-to-Pay-Integrationen

Gerade bestehende Ariba-Landschaften verdienen einen Architektur-Check.

SAP kennzeichnet beispielsweise das frühere Szenario Procure-to-Pay with SAP Ariba Buying and Invoicing inzwischen als veraltet. In der aktuellen S/4HANA-Dokumentation wird der entsprechende Hinweis direkt im Integrationsbereich angezeigt.

Das bedeutet nicht, dass jede bestehende Implementierung sofort technisch abgelöst werden muss.

Es bedeutet aber:

Eine neue S/4HANA-Transformation sollte nicht automatisch mit den Integrationsentscheidungen eines zehn Jahre alten Ariba-Projekts starten.

Welche Daten werden zwischen SAP Ariba und SAP S/4HANA oder ECC ausgetauscht?

Eine gute Integration beginnt mit einer überraschend einfachen Frage:

Welche Daten müssen überhaupt das System wechseln?

Je nach Ariba-Lösung und Geschäftsprozess können unterschiedliche Objekte betroffen sein.

Stammdaten

Typische Master-Data-Kategorien sind beispielsweise:

• Lieferanten und Business Partner,
• Materialien,
• Services,
• Warengruppen,
• Einkaufsorganisationen,
• Buchungskreise,
• Werke,
• Kostenstellen,
• Kontierungsinformationen,
• Zahlungsbedingungen,
• weitere organisations- oder procurementrelevante Referenzdaten.

Nicht jedes Objekt muss dabei bidirektional synchronisiert werden.

Transaktionsdaten

Abhängig vom Szenario können unter anderem ausgetauscht werden:

• Bestellanforderungen,
• Sourcing Requests,
• RFQs,
• Supplier Quotations,
• Vertragsinformationen,
• Bestellungen,
• Empfangs- oder Statusinformationen,
• Rechnungsinformationen,
• weitere Procurement-Dokumente.

Der konkrete Umfang ist vom implementierten SAP-Szenario abhängig.

System of Record zuerst definieren

Der häufigste Architekturfehler besteht darin, Synchronisierung mit Governance zu verwechseln.

Nur weil zwei Systeme dieselben Lieferantendaten speichern können, sollten sie nicht beide gleichberechtigt führend sein.

Für jedes wichtige Datenobjekt sollte deshalb feststehen:

Eine gute Ariba-Integration repliziert nicht möglichst viele Daten. Sie schafft klare Datenverantwortung und überträgt nur, was der Prozess benötigt.

Multi-ERP: Wenn SAP Ariba mit ECC und S/4HANA gleichzeitig verbunden werden muss

Ein einzelnes ERP ist der einfache Fall.

Ein internationaler Konzern kann dagegen gleichzeitig betreiben:

• SAP ECC in mehreren Ländern,
• bereits migrierte SAP-S/4HANA-Systeme,
• SAP S/4HANA Cloud,
• weitere Nicht-SAP-ERPs,
• eine zentrale Ariba-Landschaft.

Dann reicht ein simples Diagramm mit:

Ariba ↔ ERP

nicht mehr aus.

Die Architektur muss zusätzlich beantworten:

• Wie wird ein Dokument dem richtigen Backend zugeordnet?
• Sind System-IDs eindeutig?
• Wo liegen zentrale und lokale Stammdaten?
• Kann ein globaler Lieferant in mehreren Backends unterschiedlich repräsentiert sein?
• Wo entsteht eine Bestellanforderung?
• Wie wird während einer Migration von ECC nach S/4HANA geroutet?

SAP dokumentiert für Managed Gateway unter anderem System-ID- und Routing-Aspekte; bei mehreren Backends können zusätzliche Mapping- und Routingentscheidungen notwendig werden.

Wichtig ist allerdings, Multi-ERP nicht pauschal als simples Standard-Mapping zu behandeln. Für bestimmte S/4HANA-Managed-Gateway-Integrationen weist SAP ausdrücklich auf Einschränkungen rund um Multi-ERP und SystemID hin.

Deshalb sollte bei komplexen Landschaften zusätzlich geprüft werden:

• Ist Central Procurement sinnvoll?
• Wird eine zusätzliche Orchestrierungsebene benötigt?
• Welche Prozesse können während der ERP-Transformation zentralisiert werden?
• Welche Integrationen sind nur Übergangslösung?

SAP-Ariba-Integration implementieren: Sechs Phasen, die wichtiger sind als die Schnittstelle

Eine technische Verbindung lässt sich herstellen.

Eine stabile End-to-End-Integration erfordert mehr.

1. Prozessgrenzen definieren

Zuerst muss für jeden relevanten Prozess feststehen:

Was passiert in Ariba und was im ERP?

Beispielsweise:

Guided Buying: Ariba
Purchase Requisition: S/4HANA
Sourcing: Ariba
Purchase Order: S/4HANA
Supplier Qualification: Ariba
Business Partner: S/4HANA

Solange diese Grenzen nicht feststehen, ist jede technische Schnittstellendiskussion verfrüht.

2. System of Record definieren

Anschließend wird pro Datenobjekt entschieden, welches System führend ist.

Besonders wichtig sind:

• Lieferanten,
• Materialien,
• Kategorien,
• Verträge,
• Preise,
• Organisationseinheiten.

3. SAP-Standardszenario auswählen

Erst jetzt sollte geprüft werden:

• Gibt es ein aktuelles SAP Scope Item?
• Unterstützt Managed Gateway den Prozess?
• Ist Add-on- oder API-basierte Integration vorgesehen?
• Wird eine zusätzliche Middleware benötigt?

Damit verhindert man, einen Standardprozess unnötig individuell zu bauen.

4. Mapping und Extensions definieren

Die nächste Frage lautet:

Wo weicht der reale Unternehmensprozess vom SAP-Standard ab?

Typische Ursachen sind:

• Custom Fields,
• eigene Lieferantenklassifikationen,
• spezielle Kontierungslogik,
• zusätzliche Organisationsebenen,
• kundenspezifische Dokumenttypen.

Jede Abweichung sollte hinterfragt werden.

Nicht:

„Wie mappen wir dieses Custom Field?“

Sondern zuerst:

„Brauchen wir dieses Custom Field im zukünftigen Prozess überhaupt noch?“

5. End-to-End testen

Ein positiver API- oder Verbindungstest ist noch kein erfolgreicher Procurement-Prozess.

Getestet werden müssen reale Abläufe:

Bedarf → Approval → ERP → Bestellung → Lieferant → Status → Folgebeleg

Ebenso wichtig sind Negativfälle:

• fehlende Stammdaten,
• ungültige Kontierung,
• Lieferant nicht synchronisiert,
• Mappingfehler,
• Timeout,
• doppelte Nachricht,
• Reprocessing.

6. Monitoring und Betrieb organisieren

Wer sieht morgens, dass 300 Bestellungen nicht übertragen wurden?

Das ist keine rhetorische Frage.

Vor Go-live müssen Verantwortlichkeiten feststehen für:

• Monitoring,
• Fehleranalyse,
• Reprocessing,
• Zertifikate,
• Release Changes,
• Mapping-Änderungen,
• Backend-Probleme,
• Ariba-Probleme.

SAP unterstützt Monitoring für Transaktionen im Managed Gateway und bietet auch Anbindungsmöglichkeiten an SAP Cloud ALM.

Wo SAP-Ariba-Integrationen in der Praxis scheitern

Die meisten Probleme entstehen nicht dort, wo im Architekturdiagramm ein Pfeil fehlt.

Sie entstehen an den Übergängen.

Inkonsistente Lieferantenstammdaten

Ein Supplier besitzt in Ariba eine Identität, im ERP mehrere Vendor IDs und nach der S/4HANA-Migration vielleicht zusätzlich ein neues Business-Partner-Modell.

Ohne definierte Matching- und Governance-Regeln entstehen Dubletten und falsche Zuordnungen.

Custom Fields werden ungeprüft übernommen

Über Jahre gewachsene ECC-Systeme enthalten häufig kundenspezifische Felder und Logiken.

Wer versucht, jedes Legacy-Feld unverändert nach Ariba beziehungsweise später S/4HANA zu spiegeln, überträgt technische Altlasten in die neue Architektur.

Der Happy Path funktioniert – Ausnahmen nicht

Purchase Order erfolgreich übertragen?

Gut.

Was passiert aber bei:

• Storno,
• Änderungsbestellung,
• abgelehntem Approval,
• gelöschter Position,
• ungültiger Lieferantenreferenz,
• Teilwareneingang,
• erneut gesendeter Nachricht?

Enterprise-Integration wird in den Ausnahmefällen entschieden.

Dokumentvolumen wird unterschätzt

Ein Test mit zehn Transaktionen sagt wenig darüber aus, wie sich eine Integration im Monatsabschluss oder bei großen Batch-Läufen verhält.

Volumen- und Performance-Tests gehören deshalb zum Integrationsdesign.

Niemand besitzt den End-to-End-Prozess

Ariba-Team:

„Die Nachricht wurde verschickt.“

Integration-Team:

„Middleware ist grün.“

ERP-Team:

„Bei uns ist nichts angekommen.“

Dieser Klassiker ist weniger ein technisches als ein organisatorisches Problem.

Für geschäftskritische Procurement-Flows braucht es End-to-End-Ownership.

Die Integration wird vor der Zielarchitektur entworfen

Das ist der teuerste Fehler.

Wenn heute eine komplexe ECC-Ariba-Schnittstelle gebaut wird, obwohl ECC in absehbarer Zeit durch S/4HANA ersetzt werden soll, kann derselbe Prozess zweimal implementiert werden.

Deshalb sollte die Integration immer gegen die zukünftige ERP- und Procurement-Roadmap geprüft werden.

Was ändert sich 2026 beim Managed Gateway?

2026 ist für bestehende Managed-Gateway-Kunden technisch besonders relevant.

Migration von SAP BTP Neo zu Cloud Foundry

SAP hat angekündigt, ab Q1 2026 Managed-Gateway-Instanzen schrittweise von der SAP-BTP-Neo-Umgebung in die SAP-BTP-Cloud-Foundry-Umgebung zu migrieren. Die Migration erfolgt abhängig vom jeweiligen Data Center in Phasen.

Für betroffene Kunden können deshalb unter anderem Themen relevant werden wie:

• Cloud-Connector-Konfiguration,
• neue Cloud-Foundry-Subaccounts,
• Connectivity,
• Identity-Konfiguration,
• Tests nach der Migration.

SAP stellt hierfür spezifische Migrations- und Supportinformationen bereit.

Wer 2026 ein bestehendes CIG-/Managed-Gateway-Setup betreibt, sollte deshalb nicht nur funktionale Integrationsprojekte betrachten, sondern ebenfalls prüfen, ob und wann die eigene Instanz von der Infrastrukturmigration betroffen ist.

Alte und neue Begriffe sauber auseinanderhalten

Auch 2026 werden in Projekten weiterhin nebeneinander verwendet:

• CIG,
• Cloud Integration Gateway,
• Managed Gateway,
• Managed Gateway for Spend & Network.

Für Architektur- und Projektdokumentationen empfiehlt sich eine klare Konvention:

SAP Integration Suite, Managed Gateway for Spend Management and SAP Business Network (im Folgenden: Managed Gateway).

Dadurch werden Missverständnisse mit der allgemeinen SAP Integration Suite vermieden.

Welche Integrationsarchitektur passt zu welcher SAP-Landschaft?

Nicht jede Organisation benötigt denselben Stack.

Die sieben Architekturfragen vor jedem Ariba-Integrationsprojekt

Bevor ein Team Add-ons installiert oder APIs konfiguriert, sollten sieben Fragen beantwortet werden.

1. Welches System führt den Prozess?

Ariba, S/4HANA, ECC oder Central Procurement?

2. Welches System besitzt die Daten?

Wo entstehen Lieferant, Material, Vertrag, Preis und Bestellung?

3. Welcher SAP-Standardprozess existiert?

2NV? 4BL? 4AZ? 4QN? 3EN?

4. Welche Integrationsmethode unterstützt diesen Prozess?

Add-on, API, Hybrid oder zusätzliche Middleware?

5. Welche Customizations sind wirklich notwendig?

Nicht jede Legacy-Anforderung sollte in die neue Architektur übernommen werden.

6. Wie sieht die ERP-Landschaft in drei Jahren aus?

Eine ECC-Integration für eine Übergangslandschaft sollte anders gebaut werden als eine langfristige S/4HANA-Architektur.

7. Wer besitzt Monitoring und Fehlerbehandlung?

Eine Schnittstelle ohne klaren Betriebsprozess ist kein produktionsreifes Integrationsmodell.

Häufige Fragen zur SAP-Ariba-Integration

Wie wird SAP Ariba mit SAP S/4HANA integriert?

SAP unterstützt mehrere Integrationsmodelle. Über SAP Integration Suite, Managed Gateway for Spend Management and SAP Business Network kann S/4HANA add-on-basiert integriert werden. Für SAP S/4HANA stehen außerdem API-basierte und hybride Integrationsmöglichkeiten zur Verfügung. Das konkrete Modell hängt vom Ariba-Produkt und Business Process ab.

Kann SAP Ariba mit SAP ECC integriert werden?

Ja. SAP unterstützt SAP ERP beziehungsweise ECC weiterhin über Managed Gateway und das entsprechende SAP-ERP-Add-on. Das Add-on ermöglicht die Kommunikation zwischen dem ERP und SAP-Ariba- beziehungsweise SAP-Business-Network-Lösungen über den Managed Gateway.

Was ist SAP Ariba CIG?

SAP Ariba Cloud Integration Gateway, kurz CIG, war der frühere Name der heutigen Lösung SAP Integration Suite, Managed Gateway for Spend Management and SAP Business Network. Die Umbenennung erfolgte mit dem Ariba-Release 2302 und änderte laut SAP nicht die zugrunde liegende Funktionalität.

Ist CIG dasselbe wie Managed Gateway?

Im heutigen SAP-Sprachgebrauch ja: Managed Gateway ist die Nachfolgebezeichnung von SAP Ariba Cloud Integration Gateway. In älteren Dokumentationen und Projektunterlagen ist der Begriff CIG deshalb weiterhin sehr häufig zu finden.

Braucht man SAP Integration Suite zusätzlich zum Managed Gateway?

Nicht zwangsläufig. Für unterstützte Standard-Ariba-ERP-Szenarien kann Managed Gateway die benötigte Integrationsfunktion bereitstellen. Eine zusätzliche Integration-Suite-Schicht kann sinnvoll werden, wenn weitere Orchestrierung, Routing, Non-SAP-Systeme oder kundenspezifische Integrationsanforderungen hinzukommen.

Was ist der Unterschied zwischen Managed Gateway und SAP Integration Suite?

Managed Gateway ist speziell auf Integrationen rund um SAP Ariba, SAP Business Network und relevante Backend-Systeme ausgerichtet. SAP Integration Suite ist dagegen eine breitere Integrationsplattform für Application-, API-, Event- und B2B-Integrationsszenarien. Managed Gateway selbst wird von SAP im Integration-Suite-Kontext positioniert.

Welche Daten werden zwischen SAP Ariba und SAP S/4HANA ausgetauscht?

Das hängt vom Szenario ab. Typische Daten umfassen Supplier- und Organisationsinformationen, Materialien, Kategorien, Bestellanforderungen, Sourcing-Dokumente, Vertragsinformationen, Bestellungen und Statusdaten. Welche Objekte tatsächlich integriert werden, sollte pro Business Process und System-of-Record-Modell definiert werden.

Benötigt Managed Gateway ein Add-on in SAP S/4HANA?

Bei der add-on-basierten Integration ja. SAP stellt ein spezifisches Managed-Gateway-Add-on für SAP S/4HANA bereit. Daneben unterstützt SAP bei S/4HANA auch API-basierte Integrationsmöglichkeiten, sodass das konkrete Setup vom Szenario abhängt.

Benötigt Managed Gateway ein Add-on in SAP ECC?

Für die klassische add-on-basierte SAP-ERP-Integration stellt SAP ein entsprechendes Add-on für SAP ERP bereit. Welche Softwarekomponente und Support-Package-Version benötigt wird, sollte gegen die aktuelle SAP Product Availability Matrix und Dokumentation geprüft werden.

Was ist der Unterschied zwischen add-on-basierter und API-basierter Ariba-Integration?

Bei der add-on-basierten Integration übernimmt ein im ERP beziehungsweise S/4HANA installiertes SAP-Add-on einen Teil der Backend-Integration. Die API-basierte Variante nutzt unterstützte SAP-S/4HANA-APIs. SAP bietet für S/4HANA außerdem hybride Szenarien, bei denen beide Modelle parallel eingesetzt werden können.

Welche Rolle spielt SAP Cloud Connector?

SAP Cloud Connector kann eine sichere Verbindung zwischen dem Managed Gateway in der Cloud und SAP ERP beziehungsweise SAP S/4HANA bereitstellen. SAP führt ihn als Bestandteil beziehungsweise mögliche Methode der Backend-Konnektivität in der Managed-Gateway-Dokumentation auf.

Kann SAP Ariba gleichzeitig mit mehreren ERP-Systemen verbunden werden?

Komplexe Multi-ERP-Landschaften sind möglich, benötigen aber eine bewusste Routing- und Orchestrierungsarchitektur. Je nach Integrationsmodell gelten Einschränkungen, und Central Procurement kann eine zusätzliche Option sein. SAP weist bei bestimmten S/4HANA-Managed-Gateway-Szenarien ausdrücklich auf Multi-ERP-Einschränkungen hin.

Was passiert mit der Ariba-Integration bei einer Migration von ECC auf S/4HANA?

Die bestehende Integration sollte neu bewertet werden. S/4HANA eröffnet zusätzliche API-basierte und aktuelle standardisierte Integrationsszenarien. Deshalb sollten alte ECC-Mappings und Ariba-Integrationen nicht automatisch unverändert übernommen werden. Prozessverantwortung, System of Record und aktuelle SAP Scope Items sollten Teil der S/4HANA-Zielarchitektur werden.

Was ist 2NV?

Guided Buying Capability with SAP Ariba Buying (2NV) verbindet Guided Buying mit Procurement-Prozessen in SAP S/4HANA. Anforderungen können in Guided Buying erzeugt und als Bestellanforderungen in S/4HANA weiterverarbeitet werden.

Was ist 4BL?

Sourcing with SAP Ariba Sourcing (4BL) integriert SAP S/4HANA mit SAP Ariba Sourcing. Beschaffungsbedarfe aus S/4HANA können für Sourcing Events in Ariba genutzt und die Ergebnisse anschließend in ERP-Folgeprozesse überführt werden.

Was ist 4AZ?

Contract Management with SAP Ariba Contracts (4AZ) verbindet strategisches Vertragsmanagement in SAP Ariba Contracts mit SAP S/4HANA und ermöglicht die Integration relevanter Contract-Daten in operative Procurement-Prozesse.

Was ist 4QN?

Central Procurement with SAP Ariba Sourcing (4QN) verbindet Central Procurement mit SAP Ariba Sourcing. Das Szenario ist besonders relevant, wenn zentral gebündelte Beschaffungsbedarfe strategisch über Ariba ausgeschrieben werden sollen.

Ist SAP PI/PO für eine neue Ariba-Integration erforderlich?

Nein. Managed Gateway benötigt nicht grundsätzlich SAP PI/PO. SAP nennt PI/PO zwar weiterhin als mögliche Middleware beziehungsweise Methode für bestimmte Datenübertragungen, daneben stehen unter anderem Cloud Connector und andere Integrationsmöglichkeiten zur Verfügung. Bei neuen Projekten sollte die Middleware-Entscheidung deshalb aus der zukünftigen Integrationsarchitektur abgeleitet werden.

Was müssen Managed-Gateway-Kunden 2026 beachten?

SAP migriert Managed-Gateway-Instanzen seit Q1 2026 schrittweise von SAP BTP Neo zu SAP BTP Cloud Foundry. Betroffene Kunden sollten den Migrationszeitpunkt ihrer Instanz sowie Connectivity-, Cloud-Connector- und Testanforderungen prüfen.

Fazit: Gute Ariba-Integration beginnt vor der Schnittstelle

Eine stabile SAP-Ariba-Integration beginnt nicht mit einem Add-on, einer API oder einer Middleware.

Sie beginnt mit drei Entscheidungen:

Welcher Prozess läuft in welchem System? Welches System ist für welche Daten führend? Und wie sieht die zukünftige ERP-Landschaft aus?

Managed Gateway bietet eine standardisierte Grundlage für die Integration von SAP Ariba und SAP Business Network mit SAP ERP und S/4HANA. S/4HANA erweitert die Optionen zusätzlich um API-basierte und hybride Modelle.

Der größte Architekturvorteil entsteht jedoch nicht durch möglichst viele Schnittstellen, sondern durch wenige, klar definierte Systemgrenzen und standardisierte End-to-End-Prozesse.

LeverX unterstützt Unternehmen bei der Analyse bestehender SAP-Ariba-Integrationen, der Definition der Zielarchitektur für ECC- und S/4HANA-Landschaften sowie bei Implementierung, Migration und Optimierung von Managed-Gateway-, API- und SAP-Integration-Suite-Szenarien.