SAP Ariba Erfahrungen: Wenn integrierte Sourcing-Prozesse zu Kostenfaktoren werden

S/4HANA ist da – und jetzt? Einkaufsleiter, die den nächsten Schritt in Richtung digitales Sourcing gehen wollen, brauchen eine Lösung, mit der sich Sourcing-Prozesse strukturiert, transparent und möglichst SAP-integriert abwickeln lassen. Der Einkauf mit SAP Ariba Sourcing, dem Cloud-Modul für Ausschreibungen, Angebotsvergleiche und Vergaben, scheint auf den ersten Blick die naheliegende Wahl.

SAP Ariba Sourcing ist keine Erweiterung von S/4HANA — es ist eine eigenständige Cloud-Plattform mit eigenem Datenmodell. Das erzeugt in S/4HANA-Umgebungen drei strukturelle Kostentreiber: laufende Integrationsaufwände zwischen zwei Datenmodellen, doppelten Lizenz- und Betriebsaufwand, und Prozessbrüche im Einkaufsalltag. Für mittelständische SAP-Umgebungen überwiegt dieser Aufwand häufig den Funktionsgewinn. Dieser Artikel beleuchtet, warum das so ist — und vor welchen Entscheidungen Einkaufsorganisationen heute stehen.

SAP Ariba Sourcing – separate Plattform statt ERP-Erweiterung

SAP Ariba Sourcing wird als zentrale Komponente für strategisches Beschaffungsmanagement positioniert. Jedoch ist Ariba Sourcing keine Erweiterung von S/4HANA, sondern eine eigenständige Cloud-Plattform.

Das bedeutet für den SAP-Einkauf:

• Separate Middleware- und Schnittstellenprojekte zur Anbindung an S/4HANA

• Replikation und Synchronisation von Angebots-, Lieferanten- und Vergabedaten.

• Eigenständiges Datenmodell und separate Business-Logik außerhalb des SAP-Belegflusses.

Ariba Sourcing bringt neue Funktionen ins Spiel – aber auf einer separaten Plattform, die strategisches Sourcing vom ERP-System entkoppelt. Clean Core, die Grundlage für eine One-Plattform Strategie der SAP, wird so nicht umsetzbar. Und genau an dieser Stelle beginnen in vielen Unternehmen die strukturellen Probleme.

SAP Ariba in S/4HANA: strukturelle Folgen

Kombination aus zwei Systemwelten – SAP Ariba Sourcing und S/4HANA – erzeugt fünf strukturelle Folgeprobleme:

Integrationsaufwand & Betrieb – die unterschätzte Kostenstelle

Die Kopplung zwischen Ariba Sourcing und S/4HANA ist kein „Standard-Connector“, den man einmal einrichtet und danach nie wieder anfasst. Die Integration ist ein eigener Architekturstrang – und in vielen Projekten die größte Quelle für Aufwand, Fehler und versteckte Kosten. Angebote, Vergaben, Lieferantenupdates oder BANF-Daten liegen nicht im selben Datenmodell vor. Alles muss übertragen, gemappt oder repliziert werden. An dieser Stelle darf nicht der Unterschied SAP-integriert vs. SAP-nativ nicht unterschätzt werden.

Ein mittelständisches Unternehmen aus dem Energiesektor berichtete uns von der Erfahrung, dass das Projektteam über ein Jahr versuchte, die Integration zum Laufen zu bringen — zwei Monate vor dem geplanten Livegang wurde entschieden, das Projekt zu verschieben. Kein Einzelfall: Aus zwei vergleichbaren Ariba-Projekten kennen wir dasselbe Muster. Die notwendige, fortlaufende Entwicklung und Pflege von Schnittstellen zu S/4HANA bremst Unternehmen in ihrer digitalen Transformation, statt sie zu unterstützen.

 
Das sind die typischen Kostentreiber in einem SAP Ariba Projekt:

⚠️ Einrichtung und Pflege von Integrationsschnittstellen (Mapping, Monitoring, Fehlerhandling, Release-Anpassungen)

⚠️ Separate Lizenzen für Ariba Sourcing und Onboarding-Kosten für das Business Network, über das die Lieferanten eingebunden sind

⚠️ Doppelter Support- und Schulungsaufwand für zwei Systemumgebungen

⚠️ Dauerhafter Pflegeaufwand und permanentes Nachjustieren bindet internes und externes Personal

Gerade mittelständische Unternehmen berichten, dass die erwarteten Einsparungen der Cloud-Standardisierung durch den hohen Integrationsaufwand weitgehend verpuffen. Die Nutzerakzeptanz bleibt häufig unter 30 Prozent und viele Einkaufsteams greifen weiterhin auf ihre etablierten Workarounds zurück. Entsprechend rücken die ursprünglich definierten ROI-Ziele in weite Ferne. SAP-native Lösungen vermeiden diesen Integrationsaufwand. Grund genug, sich mit möglichen Ariba-Alternativen zu beschäftigen.

Nutzererfahrung & Prozessbrüche – zwei Welten im Einkauf

Aus Anwendersicht zeigt sich die Trennung zwischen Ariba und S/4HANA besonders deutlich. Beide Systeme folgen einer eigenen Businesslogik – Oberfläche, Navigation, Prozessführung, Datenstrukturen.

👉 Zwei Systeme statt eines Prozesses
Einkäufer erfassen Bedarfe, Bestellungen und Wareneingänge in S/4HANA – und wechseln für Ausschreibungen, Angebotsvergleiche und Vergaben in Ariba Sourcing. Diese Systemwechsel sind nicht nur lästig, sondern brechen den Prozessfluss.

👉 Angebots- und Vergabedaten fehlen im ERP-Kontext
Vergabedokumentation, Angebotsdetails oder Rückfragen laufen in Ariba Sourcing – und werden nur teilweise oder gar nicht nach S/4HANA zurückgeschrieben. Die Trennung zwischen Ariba Sourcing (Angebote, Vergaben) und S/4HANA (Bestellungen, Wareneingänge) macht Reporting, Nachvollziehbarkeit und Revision unnötig kompliziert: Vollständige Belegketten existieren nicht.

👉 Schattenprozesse bleiben bestehen
Wenn die Businesslogik von Ariba Sourcing und der Bedarf im ERP nicht zusammenpassen, rutschen Einkäufer wieder in Excel-Listen, E-Mail-Abstimmungen oder lokale Bewertungsmatrizen. Genau die Schritte, die eigentlich digitalisiert werden sollten, landen erneut in manuellen Workarounds. Es entsteht kein durchgängiger SAP Einkaufsprozess und eben keine „One-Plattform“, sondern ein fragmentierter Ablauf über zwei Systemlandschaften.

Wo SAP Ariba Sourcing an funktionale Grenzen stößt

Ariba Sourcing deckt klassische Anfrage- und Ausschreibungsszenarien ab, auch wenn die Usability an mehreren Stellen Optimierungspotenzial bietet. Sobald die Anforderungen jedoch komplexer werden – etwa bei technischen Anlagen, Dienstleistungen, projektbezogenen Ausschreibungen, Bauvorhaben oder mehrstufigen Strukturen –, stößt das System schnell an funktionale Grenzen.

Der größte Bruch zwischen Erwartung und Realität tritt bei komplexen RFX-Szenarien auf: Lean Services in S/4HANA werden von SAP Ariba nicht unterstützt, GAEB-Leistungsverzeichnisse lassen sich nicht abbilden, und Angebotsdokumente von Lieferanten können nicht nach S/4HANA übertragen werden.

Typische Limitierungen von SAP Ariba Sourcing sind:

❌ Lean Services und Item Hierarchies: nicht unterstützt

❌ GAEB-Leistungsverzeichnisse: nicht abbildbar

⚠️ Individuelle Bewertungslogiken: nur über aufwendiges Customizing möglich

⚠️ Projektbezogene Vergaben und Freigaben: erfordern Zusatzmodule oder externe Tools

Viele Einkaufsbereiche nutzen Ariba Sourcing zwar für einfache Standard-RFQs – kehren bei komplexen oder projektbezogenen Ausschreibungen aber wieder zu manuellen Prozessen zurück. Genau die Bereiche, die strategisch wichtig wären, bleiben damit weiterhin analog oder teilstrukturiert.

Fazit – Drei Entscheidungen und eine Empfehlung

SAP Ariba Sourcing ist ein etabliertes System – insbesondere für global agierende Unternehmen mit großer Lieferantenbasis. Seine Stärken zeigt Ariba vor allem dann, wenn es im Zusammenspiel mit weiteren Ariba-Modulen genutzt wird – etwa Supplier Lifecycle, Contracts oder Buying. In dieser Kombination entsteht ein geschlossenes Prozessbild innerhalb des SAP Business Network, das für international aufgestellte Organisationen gut funktioniert.

In S/4HANA-basierten Organisationen muss Ariba Sourcing allerdings hinsichtlich Integrationsaufwand, Systemkomplexität und laufenden Betrieb bewertet werden – besonders, wenn ein schlanker, SAP-naher Architekturansatz im Fokus steht.

Genau deshalb stehen Einkaufsorganisationen heute vor drei grundlegenden Entscheidungen:

1️⃣ Wo soll Sourcing künftig verortet sein?
Im ERP, in einer separaten Cloud oder als Mischarchitektur?

2️⃣ Wie viel Integrationsaufwand ist akzeptabel?
Einmalig, dauerhaft oder möglichst gar nicht?

3️⃣ Welche RFX-Komplexität muss abgedeckt werden?
Einfache Standardanfragen oder projektorientierte, technische Ausschreibungen?

Die Entscheidung für oder gegen eine bestimmte Sourcing-Architektur ist dabei selten eine isolierte Systemfrage. Warum sie 2026 zur zentralen Weichenstellung im Einkauf werden – und weshalb es dabei um Handlungsfähigkeit statt Systemlogik geht –, haben wir hier eingeordnet.

Es lohnt sich, die Alternative einer SAP-nativen Integration zu prüfen. Lösungen wie FUTURA Smart setzen genau hier an: RFX-Prozesse laufen vollständig im SAP-Kern und folgen konsequent der „One-Plattform-Strategie“ von SAP. Die Belegkette bleibt geschlossen und die Lösung wächst nahtlos mit dem S/4HANA-System. Für Einkaufsorganisationen, die eine schlanke, revisionssichere und vollständig integrierte Sourcing-Architektur anstreben – insbesondere im mittelständischen und großen SAP-Umfeld – ist dies ein idealer Ansatz.