Wie lange dauert eine SAP-Ariba-Implementierung wirklich – und was treibt die Kosten? Der Leitfaden zeigt Ablauf, Aufwand, Risiken und Erfolgsfaktoren für eine erfolgreiche Einführung.

SAP Ariba Implementierung: Ablauf, Dauer, Kosten und Erfolgsfaktoren

„Wie lange dauert eine SAP-Ariba-Implementierung?“ klingt nach einer einfachen Projektfrage. In der Praxis ist sie ohne eine zweite Frage kaum zu beantworten:

Was genau soll implementiert werden?

Ein einzelnes SAP-Ariba-Sourcing-Modul, eine neue Buying Experience für mehrere tausend Mitarbeiter und eine globale Source-to-Pay-Transformation mit SAP S/4HANA, Lieferanten-Onboarding und mehreren Ländern sind drei völlig unterschiedliche Projekte.

Entsprechend unterschiedlich fallen Dauer, Kosten, Projektteam und Risiken aus.

SAP nutzt für Ariba-Deployments die SAP-Activate-Methodik. Der Lebenszyklus umfasst Discover, Prepare, Explore, Realize, Deploy und Run. Dahinter steckt jedoch mehr als eine technische Cloud-Konfiguration: Prozesse müssen neu gestaltet, Daten bereinigt, Integrationen aufgebaut, Lieferanten aktiviert und Nutzer tatsächlich in den neuen Einkaufsprozess gebracht werden.

Dieser Leitfaden zeigt, wie eine SAP-Ariba-Einführung typischerweise abläuft, welche Zeitplanung realistisch ist, welche Faktoren die Kosten treiben – und warum erfolgreiche Projekte nicht beim Go-live enden.

SAP Ariba implementieren: Die wichtigsten Antworten vorab

Wie lange dauert eine SAP-Ariba-Implementierung?

Für klar abgegrenzte, standardisierte Deployments können einzelne Ariba-Lösungen innerhalb weniger Monate produktiv gehen.

SAP nennt in einer aktuellen Beschreibung seiner standardisierten Deployment Services beispielsweise einen Go-live innerhalb von 12 Wochen für SAP Ariba Sourcing sowie 14 Wochen für SAP Ariba Contracts und SAP Ariba Supplier Lifecycle and Performance. Diese Zeitangaben gelten allerdings für definierte Standard-Scopes: unter anderem ein Produktiv- und ein Testsystem, einen Go-live und ohne externe Systemintegration im enthaltenen Standardumfang. Zusätzliche Integrationen, Regionen oder Rollout-Wellen können zusätzlichen Aufwand verursachen.

Für ein umfassendes Enterprise-Programm ist „12 Wochen“ deshalb kein sinnvoller Universalbenchmark.

Ein einzelnes standardnahes Modul kann in wenigen Monaten live gehen. Eine globale Source-to-Pay-Transformation ist dagegen ein mehrstufiges Transformationsprogramm.

Was kostet SAP Ariba?

Auch dafür gibt es keine seriöse Universalzahl.

Schon die Softwarekosten hängen vom eingesetzten Produkt und dessen Lizenzmetrik ab. SAP Ariba Sourcing wird beispielsweise pro Nutzer und Jahr lizenziert; den konkreten Preis veröffentlicht SAP nicht, sondern stellt ihn auf Anfrage bereit.

Die Gesamtkosten einer Einführung bestehen zudem nicht nur aus der Subscription:

SAP-Ariba-Gesamtkosten = Software + Implementierung + Integration + Daten + Supplier Enablement + Change Management + Rollout + Betrieb

Deshalb kann eine Kostenschätzung erst belastbar werden, wenn Scope und Zielarchitektur feststehen.

Was entscheidet über den Projekterfolg?

Vor allem sechs Dinge:

• klarer Scope,
• standardnahe Prozesse,
• saubere Daten,
• passende Integrationsarchitektur,
• frühzeitige Lieferanten- und Nutzeraktivierung,
• klare Governance.

Die Software selbst ist nur ein Teil des Projekts.

Was wird bei einer SAP-Ariba-Implementierung eigentlich implementiert?

„Wir führen SAP Ariba ein“ sagt über den tatsächlichen Projektumfang erstaunlich wenig aus.

SAP Ariba umfasst mehrere Procurement- und Spend-Management-Lösungen, die einzeln oder kombiniert eingeführt werden können.

SAP Ariba Sourcing

SAP Ariba Sourcing unterstützt strategische Beschaffungsprozesse wie:

• RFIs und RFPs,
• Ausschreibungen,
• Lieferantenangebote,
• Auktionen,
• Angebotsbewertung,
• Verhandlungen,
• Zuschlagsentscheidungen.

Ein Sourcing-Projekt kann relativ fokussiert bleiben, wenn es zunächst unabhängig von komplexen Buying-, Invoice- oder Supplier-Lifecycle-Prozessen eingeführt wird.

SAP Ariba Contracts

Hier liegt der Schwerpunkt auf strategischem Vertragsmanagement:

• Contract Workspaces,
• Vertragsdokumente,
• Freigabeprozesse,
• Vorlagen,
• Vertragsbedingungen,
• Lifecycle und Governance.

Sobald operative Einkaufskontrakte oder Preisinformationen mit SAP S/4HANA beziehungsweise ECC verbunden werden sollen, kommt zusätzlich Integrationsaufwand hinzu.

SAP Ariba Supplier Lifecycle and Performance

Diese Einführung betrifft vor allem:

• Lieferantenregistrierung,
• Onboarding,
• Qualifizierung,
• Preferred-Supplier-Prozesse,
• Fragebögen,
• Performance Management,
• Lifecycle Governance.

Damit wird aus einem Procurement-Projekt schnell auch ein Daten- und Governance-Projekt.

SAP Ariba Supplier Risk

Supplier Risk ergänzt Lieferantenprozesse um Risikoinformationen und entsprechende Bewertungs- und Monitoring-Prozesse.

Der Aufwand hängt stark davon ab, wie Risikoinformationen in bestehende Sourcing-, Onboarding- und Entscheidungsprozesse eingebunden werden sollen.

SAP Ariba Buying und Guided Buying

Bei Buying-Projekten verschiebt sich der Fokus.

Hier muss nicht nur Procurement funktionieren. Der neue Prozess muss auch für Mitarbeiter verständlich sein, die vielleicht nur zwei- oder dreimal im Jahr etwas bestellen.

Typische Themen sind:

• Kataloge,
• Guided Buying,
• Freitextanforderungen,
• Genehmigungen,
• Procurement Policies,
• Kontierungen,
• bevorzugte Lieferanten,
• User Experience.

SAP Ariba Buying and Invoicing

Wenn zusätzlich Rechnungsprozesse Bestandteil des Scopes sind, steigen Prozess- und Integrationsanforderungen deutlich.

Dann müssen unter anderem ERP-, Finance-, PO-, Receipt- und Invoice-Prozesse gemeinsam betrachtet werden.

SAP Business Network

Supplier Collaboration bringt eine weitere Dimension hinzu:

Die Gegenpartei muss mitmachen.

Bestellungen, Bestätigungen, Rechnungen und andere Geschäftsdokumente können digital mit Lieferanten ausgetauscht werden – aber nur, wenn Supplier Enablement, Testing und Support ebenfalls Teil des Projekts sind.

Damit wird deutlich:

„SAP Ariba implementieren“ kann ein einzelnes Modul bedeuten – oder die Transformation eines kompletten Source-to-Pay-Modells.

Und genau deshalb sollten Dauer und Kosten nie vor dem Scope diskutiert werden.

SAP-Ariba-Implementierung nach SAP Activate: Der typische Ablauf

SAP empfiehlt für SAP-Ariba-Deployments die SAP-Activate-Methodik. Der vollständige Lifecycle umfasst Discover, Prepare, Explore, Realize, Deploy und Run. Für den eigentlichen Deployment-Prozess konzentriert sich SAP insbesondere auf Prepare, Explore, Realize und Deploy.

Für ein Projektteam sind die Phasennamen weniger wichtig als die Entscheidungen, die darin getroffen werden.

1. Discover: Warum führen wir SAP Ariba überhaupt ein?

Vor dem Projektplan sollte der Business Case stehen.

Das klingt selbstverständlich, wird aber häufig zu früh von Feature-Diskussionen verdrängt.

Die erste Frage lautet nicht:

Welche Funktionen wollen wir konfigurieren?

Sondern:

Welches Procurement-Problem wollen wir lösen?

Mögliche Ziele sind beispielsweise:

• Maverick Buying reduzieren,
• Sourcing-Prozesse standardisieren,
• Lieferanten-Onboarding zentralisieren,
• Spend Transparency erhöhen,
• Source-to-Pay-Prozesse harmonisieren,
• Supplier Risk besser berücksichtigen,
• Mitarbeiter aus E-Mail- und Excel-basierten Einkaufsprozessen holen,
• eine S/4HANA-Transformation mit einer Procurement-Transformation verbinden.

Anschließend muss der Scope konkret werden:

• Welche Ariba-Lösungen?
• Welche Länder?
• Welche Gesellschaften?
• Welche Warengruppen?
• Welche Nutzergruppen?
• Welche Lieferanten?
• Welche ERP-Systeme?
• Welche Integrationen?
• Welche Prozesse gehören ausdrücklich nicht in Wave 1?

Der letzte Punkt ist oft besonders wichtig.

Ein guter Scope definiert nicht nur, was das Projekt macht. Er definiert auch, was es bewusst später macht.

2. Prepare: Projekt, Team und Governance aufsetzen

SAP ordnet der Prepare-Phase unter anderem Projektplanung und Onboarding, Solution Provisioning und den Projekt-Kick-off zu.

In dieser Phase sollte aus einer Procurement-Idee ein steuerbares Transformationsprojekt werden.

Dazu gehören:

• Projektcharter,
• Projektplan,
• Governance,
• Rollen,
• Entscheidungswege,
• Eskalationsmodell,
• Arbeitsstreams,
• Systemzugänge,
• Test- und Produktivumgebungen,
• Meeting-Rhythmus,
• initiale Daten- und Integrationsplanung.

Eine wichtige Entscheidung lautet:

Wer darf Prozessentscheidungen treffen?

Wenn jede lokale Organisation, jeder Category Manager und jedes IT-Team ein faktisches Vetorecht hat, werden selbst kleine Prozessfragen zu mehrwöchigen Diskussionen.

Deshalb sollte früh feststehen:

• Was wird global standardisiert?
• Was darf lokal abweichen?
• Wer genehmigt Ausnahmen?
• Wer besitzt das globale Procurement Template?

3. Explore: Fit-to-Standard statt Digitalisierung jeder Sonderregel

Hier entscheidet sich häufig, ob das Projekt später schlank bleibt oder ausufert.

SAP ordnet der Explore-Phase Requirements Gathering, Process Design, Datenanforderungen, Design Specifications und die Change-Management-Strategie zu.

Der gefährlichste Satz in einem solchen Workshop lautet:

„Das machen wir heute aber anders.“

Das kann ein valider Hinweis sein.

Es kann aber genauso gut bedeuten, dass ein vor zwölf Jahren eingeführter Sonderprozess heute ungeprüft in eine neue Cloud-Plattform übertragen werden soll.

Eine bessere Frage lautet:

Warum machen wir es heute anders – und brauchen wir diese Abweichung zukünftig noch?

In Explore werden typischerweise:

• Ist-Prozesse analysiert,
• Zielprozesse definiert,
• SAP-Standardfunktionen bewertet,
• Gaps dokumentiert,
• Anforderungen priorisiert,
• Rollen und Genehmigungen gestaltet,
• Integrationspunkte identifiziert,
• Datenanforderungen definiert,
• Reporting- und Compliance-Anforderungen abgestimmt.

Das Ziel sollte keine möglichst perfekte Kopie der alten Welt sein.

Das Ziel ist ein besserer zukünftiger Procurement-Prozess.

4. Realize: Konfiguration, Integration, Daten und Tests

In Realize wird aus dem Prozessdesign ein funktionierendes System.

SAP nennt für diese Phase unter anderem Solution Configuration, Projekt-Templates, Datenbereitstellung und Change-Management-Inhalte.

Typische Aktivitäten sind:

• Ariba-Konfiguration,
• Formulare,
• Workflows,
• Templates,
• Rollen und Berechtigungen,
• Kataloge,
• Datenmigration,
• SAP-S/4HANA- oder ECC-Integration,
• Managed-Gateway- beziehungsweise API-Konfiguration,
• Custom Mappings,
• Reports,
• Testvorbereitung,
• Unit Tests,
• Integration Tests,
• User Acceptance Tests.

Hier zeigt sich häufig erstmals, ob Entscheidungen aus Explore wirklich belastbar waren.

Ein Prozess kann auf einer Workshop-Folie sehr einfach aussehen.

Sobald echte:

• Lieferanten,
• Materialien,
• Kontierungen,
• Genehmigungshierarchien,
• Vertragsdaten,
• Länder,
• steuerliche Anforderungen

in das System kommen, entstehen die tatsächlichen Ausnahmefälle.

Deshalb sollte Testing nicht nur den Happy Path bestätigen.

Getestet werden müssen auch:

• fehlende Daten,
• falsche Kontierungen,
• abgelehnte Genehmigungen,
• Lieferantenfehler,
• Änderungen,
• Stornos,
• Datenkonflikte,
• Integrationsfehler.

5. Deploy: Cutover, Training und Go-live

SAP ordnet Deploy unter anderem Production Migration, Change-Management-Aktivitäten, Go-live und Post-Go-live-Support zu.

Technisch bedeutet Deploy:

• finale Konfiguration,
• finale Datenmigration,
• Benutzerbereitstellung,
• Cutover,
• Produktivsetzung,
• Hypercare.

Geschäftlich bedeutet die Phase etwas anderes:

Der neue Prozess muss tatsächlich benutzt werden.

Dazu müssen Nutzer wissen:

• wo sie einkaufen,
• wie sie einen Bedarf anlegen,
• wie Genehmigungen funktionieren,
• welche Lieferanten bevorzugt sind,
• was sich gegenüber dem alten Prozess ändert,
• wo sie Hilfe bekommen.

Lieferanten müssen möglicherweise ebenfalls:

• registriert,
• verbunden,
• getestet,
• geschult

werden.

Deshalb ist ein technischer Go-live nur ein Teil des Deployments.

6. Run: Der Business Case beginnt erst nach dem Go-live

Der vielleicht größte Fehler in Procurement-Transformationen ist, Go-live mit Erfolg gleichzusetzen.

Ein System kann technisch stabil laufen und trotzdem seinen Business Case verfehlen.

Nach dem Go-live sollte deshalb nicht nur Systemverfügbarkeit gemessen werden.

Interessanter sind beispielsweise:

• Anteil der Nutzer, die den neuen Prozess verwenden,
• Katalognutzung,
• Guided-Buying-Adoption,
• Anteil compliant spend,
• Maverick Spend,
• Sourcing Cycle Time,
• Supplier Adoption,
• Transaktionsfehler,
• Durchlaufzeiten für Genehmigungen,
• Anteil digitaler Bestell- und Rechnungsprozesse.

Run ist damit nicht nur Support.

Es ist die Phase, in der das Unternehmen überprüft, ob das neue Procurement-Modell tatsächlich funktioniert.

Wie lange dauert eine SAP-Ariba-Implementierung?

Die richtige Antwort lautet:

Es hängt vom Scope ab – aber nicht völlig beliebig.

Für bestimmte standardisierte Deployment Services veröffentlicht SAP konkrete Zeitrahmen.

SAP sieht beispielsweise für ein standardisiertes SAP-Ariba-Sourcing-Deployment einen Go-live innerhalb von 12 Wochen nach Projekt-Kick-off vor. Für SAP Ariba Contracts und Supplier Lifecycle and Performance nennt SAP jeweils 14 Wochen.

Diese Zahlen brauchen jedoch Kontext.

Das zugrunde liegende Deployment-Modell geht unter anderem von:

• einem Produktivsystem,
• einem Testsystem,
• einem definierten Scope,
• einem Go-live

aus. Externe Systemintegration ist in diesem Standard-Deployment nicht enthalten; weitere Regionen, Divisionen oder Go-lives können zusätzlichen Aufwand bedeuten.

Deshalb ist folgende Planung sinnvoller:

Warum Projekte länger dauern

Nicht unbedingt wegen der SAP-Konfiguration.

Typische Zeitfresser sind:

• ausstehende Prozessentscheidungen,
• Datenbereinigung,
• Integration,
• Testdaten,
• Custom Requirements,
• Lieferanten-Onboarding,
• interne Freigaben,
• Länderunterschiede,
• fehlende Ressourcen auf Kundenseite.

Ein Projektplan sollte deshalb nicht nur technische Tasks enthalten.

Er sollte auch Decision Lead Time berücksichtigen.

Wenn ein globaler Freigabeprozess vier Wochen Diskussion benötigt, kann ein Implementierungspartner ihn nicht durch schnelleres Customizing kompensieren.

Was kostet eine SAP-Ariba-Implementierung?

Auch hier ist eine einzelne Zahl wenig hilfreich.

SAP veröffentlicht für verschiedene Ariba-Lösungen nicht zwingend einen öffentlichen Listenpreis. SAP Ariba Sourcing wird beispielsweise pro Nutzer und Jahr lizenziert, der konkrete Preis wird auf Anfrage bereitgestellt.

Für Buying and Invoicing weist SAP ebenfalls darauf hin, dass Pricing-Details auf Anfrage verfügbar sind.

Die Projektkosten bestehen jedoch aus deutlich mehr als der Software.

1. Software und Subscription

Abhängig von:

• Ariba-Lösung,
• Edition,
• Nutzungsmetrik,
• Nutzerzahl,
• Vertragslaufzeit,
• Zusatzkomponenten.

Deshalb sollten Software- und Implementierungskosten getrennt betrachtet werden.

2. Implementierungsleistungen

Hierzu gehören typischerweise:

• Projektmanagement,
• Prozessworkshops,
• Solution Design,
• Konfiguration,
• Workflow-Design,
• Templates,
• Testing,
• Dokumentation,
• Go-live-Unterstützung.

Je standardnäher der Scope, desto besser lässt sich dieser Aufwand kontrollieren.

3. Integration

Eine der häufigsten unterschätzten Kostenpositionen.

Relevant sind beispielsweise:

• SAP S/4HANA oder ECC,
• Managed Gateway,
• APIs,
• SAP Integration Suite,
• Non-SAP-Systeme,
• kundenspezifische Mappings,
• Master-Data-Flows,
• Transaktionsdaten,
• Monitoring.

Die Integrationskosten hängen deshalb nicht allein davon ab, ob Ariba integriert wird, sondern wie viele Prozesse und Systeme beteiligt sind.

4. Datenmigration und Datenbereinigung

Ein Unternehmen mit:

• 700 aktiven Lieferanten,
• sauberer Kategorisierung,
• konsistenten Stammdaten

hat einen anderen Aufwand als ein Konzern mit:

• 80.000 Lieferantensätzen,
• Dubletten,
• mehreren ERP-Instanzen,
• lokalen Kategorien,
• historisch gewachsenen Vertragsdaten.

Die Software kennt diesen Unterschied nicht.

Das Projektbudget schon.

5. Supplier Enablement

Je nach Scope müssen Lieferanten:

• segmentiert,
• kontaktiert,
• registriert,
• verbunden,
• getestet,
• unterstützt

werden.

Gerade bei SAP Business Network oder umfassender transaktionaler Integration kann Supplier Enablement zu einem eigenen Workstream werden.

6. Change Management und Training

Die Kosten entstehen nicht nur durch Trainingsmaterial.

Change umfasst:

• Stakeholder Management,
• Kommunikation,
• Key-User-Netzwerke,
• Rollenänderungen,
• Trainings,
• Supportmodelle,
• Adoption Monitoring.

7. Rollout

Jede zusätzliche Region kann neue Anforderungen mitbringen:

• Gesellschaften,
• Prozesse,
• Steuern,
• Rechnungsanforderungen,
• Sprache,
• Lieferanten,
• lokale Governance,
• Integrationen.

Eine einmal entwickelte globale Vorlage reduziert Aufwand, eliminiert ihn aber nicht.

Eine seriöse SAP-Ariba-Kostenschätzung beginnt deshalb nicht mit der Nutzerzahl. Sie beginnt mit Scope, Prozesskomplexität, ERP-Landschaft, Datenqualität, Lieferantenbasis und Rollout-Modell.

Welche Faktoren treiben die Kosten besonders stark?

Nicht alle Projektparameter wirken gleich stark auf das Budget.

Ein wichtiger Zusammenhang wird dabei oft übersehen:

Komplexität multipliziert sich.

Fünf Länder plus drei ERP-Systeme plus vier Ariba-Lösungen sind nicht einfach zwölf einzelne Aufgaben.

Sie erzeugen Abhängigkeiten zwischen:

• Prozessen,
• Daten,
• Integrationen,
• Rollen,
• Tests,
• Rollouts.

Deshalb ist Scope Management gleichzeitig Kostenmanagement.

Welche Rollen braucht ein SAP-Ariba-Projekt?

Eine SAP-Ariba-Einführung sollte weder ein reines IT-Projekt noch ein reines Procurement-Projekt sein.

Beide Seiten werden gebraucht.

Executive Sponsor

Schafft Priorität, löst Eskalationen und sorgt dafür, dass globale Entscheidungen nicht an lokalen Interessenkonflikten hängen bleiben.

Procurement Process Owner / CPO-Organisation

Verantwortet fachliche Zielprozesse:

• Sourcing,
• Buying,
• Supplier Management,
• Contracts,
• Governance.

Ariba Product Owner

Besitzt die Produktperspektive und priorisiert Anforderungen, Backlog und Weiterentwicklung.

IT / Enterprise Architecture

Verantwortet:

• Systemlandschaft,
• Sicherheitsmodell,
• Integrationen,
• ERP-Abhängigkeiten,
• Architekturprinzipien.

Integration Lead

Koordiniert:

• SAP S/4HANA,
• ECC,
• Managed Gateway,
• APIs,
• Middleware,
• End-to-End-Flows.

Data Lead

Definiert:

• Datenquellen,
• Datenverantwortung,
• Cleansing,
• Migration,
• Validierung.

Change Lead

Plant Adoption, Kommunikation und Training.

Key User

Sind entscheidend, um sicherzustellen, dass ein „standardisierter Prozess“ auch im realen Einkauf funktioniert.

Implementierungspartner

Bringt Produkt-, Prozess- und Integrationsexpertise zusammen und sollte nicht nur konfigurieren, sondern auch auf unnötige Komplexität hinweisen.

Ein funktionierendes Governance-Modell lässt sich einfach zusammenfassen:

Procurement entscheidet über den Prozess. IT entscheidet über Architekturstandards. Gemeinsam entscheiden beide über die Trade-offs.

Datenmigration: Ein neues System repariert keine schlechten Stammdaten

Datenmigration wird gerne als technischer Arbeitspunkt behandelt.

Tatsächlich ist sie häufig ein Procurement-Governance-Thema.

Typische Fragen sind:

• Welche Lieferanten sind noch aktiv?
• Welche Dubletten existieren?
• Welche Lieferanten sollen überhaupt migriert werden?
• Welche Warengruppen sind konsistent?
• Welche Kataloge sind aktuell?
• Welche Verträge sind noch relevant?
• Welche Benutzer- und Organisationsdaten werden benötigt?
• Welches System bleibt nach dem Go-live führend?

Ein neues Procurement-System macht schlechte Stammdaten nicht automatisch besser.

Es macht ihre Auswirkungen nur sichtbarer.

Ein nicht sauber gematchter Lieferant kann beispielsweise anschließend Probleme verursachen in:

• Onboarding,
• Sourcing,
• Buying,
• Bestellung,
• Integration,
• Reporting.

Datenbereinigung sollte deshalb nicht wenige Wochen vor dem Go-live beginnen.

Sie gehört bereits in die frühen Projektphasen.

SAP Ariba mit SAP S/4HANA oder ECC integrieren

Integration sollte in einem Implementierungsartikel nicht zum technischen Handbuch werden.

Für die Projektplanung muss jedoch früh klar sein, welche Systeme zusammenspielen.

Typische Fragen lauten:

• Bleibt SAP S/4HANA System of Record für Materialien?
• Wo wird der Business Partner geführt?
• Wo entsteht die Bestellung?
• Werden Sourcing-Ergebnisse zurück ins ERP übertragen?
• Wie werden Kontierungsdaten bereitgestellt?
• Welche Statusinformationen benötigt Ariba?
• Welche Daten müssen bidirektional fließen?

Für SAP Ariba, SAP Business Network und SAP ERP/S/4HANA stellt SAP unter anderem SAP Integration Suite, Managed Gateway for Spend Management and SAP Business Network als standardisierte Integrationskomponente bereit. Je nach S/4HANA-Szenario können auch API-basierte Integrationsmuster relevant sein.

Die Architektur sollte vor der Konfiguration feststehen.

Zuerst Prozessverantwortung definieren. Dann System of Record. Dann Integration.

Nicht umgekehrt.

Für die technische Vertiefung sollte dieser Artikel intern auf den separaten LeverX-Leitfaden zur SAP-Ariba-Integration mit SAP S/4HANA und ECC verlinken.

Supplier Enablement: Go-live ohne Lieferanten ist nur ein technischer Go-live

Bei internen Softwareprojekten können Unternehmen die meisten Beteiligten direkt steuern.

Bei Procurement-Projekten nicht.

Ein Teil des End-to-End-Prozesses liegt außerhalb des Unternehmens.

Deshalb sollte Supplier Enablement frühzeitig geplant werden.

Lieferanten segmentieren

Nicht jeder Supplier benötigt dasselbe Enablement-Modell.

Sinnvoll ist beispielsweise eine Segmentierung nach:

• Spend,
• Transaktionsvolumen,
• strategischer Bedeutung,
• Kategorie,
• technischer Reife,
• gewünschtem Dokumentenaustausch.

Lieferanten früh informieren

Ein Lieferant, der zwei Wochen vor Go-live erstmals von einem neuen Portal oder Business-Network-Prozess hört, wird selten für einen reibungslosen Start sorgen.

Kommunikation sollte erklären:

• Was ändert sich?
• Warum?
• Was muss der Lieferant tun?
• Welche Termine gelten?
• Wo gibt es Hilfe?

Reale Prozesse testen

Nicht nur Registrierung testen.

Sondern – je nach Scope – auch:

• Bestellung,
• Bestätigung,
• Katalog,
• Rechnungsprozess,
• Status,
• Fehlerfälle.

Technisch kann SAP Ariba live sein, während der Procurement-Prozess faktisch noch nicht live ist – wenn die relevanten Lieferanten nicht transaktionsfähig sind.

Change Management: Warum Adoption über den Business Case entscheidet

Eine neue Procurement-Plattform verändert nicht nur Technologie.

Sie verändert Verhalten.

Besonders bei Guided Buying oder Self-Service Procurement betrifft die Einführung oft Menschen, die sich selbst gar nicht als „SAP-Nutzer“ sehen.

Ein Manager möchte einen Laptop.

Eine Marketingabteilung braucht eine Agentur.

Ein Standort bestellt Verbrauchsmaterial.

Diese Nutzer interessieren sich wenig für die Architektur hinter dem Prozess.

Sie erwarten, dass Einkauf einfach funktioniert.

Darum sollten Change-Maßnahmen rollenbasiert aufgebaut werden.

Für Bedarfsträger

• Wo starte ich?
• Was darf ich kaufen?
• Welchen Lieferanten soll ich nutzen?
• Wer genehmigt?

Für professionelle Einkäufer

• Was ändert sich im Prozess?
• Welche Aktivitäten werden automatisiert?
• Welche Verantwortung bleibt manuell?

Für Genehmiger

• Was muss geprüft werden?
• Wie schnell muss entschieden werden?
• Welche Informationen sind verfügbar?

Für Lieferanten

• Wie interagiere ich zukünftig mit dem Kunden?

Nach Go-live sollte Adoption messbar sein.

Mögliche KPIs:

• aktive Nutzer,
• Guided-Buying-Nutzung,
• Katalognutzung,
• compliant spend,
• Maverick Spend,
• Supplier Adoption,
• Durchlaufzeiten,
• Anzahl manueller Prozessschritte.

Change ist damit kein weicher Begleitworkstream.

Es ist ein Bestandteil des Business Case.

Big Bang oder schrittweise SAP-Ariba-Einführung?

Die Frage ist besonders relevant für große Organisationen.

Big Bang

Alle definierten Prozesse beziehungsweise Organisationseinheiten gehen weitgehend gleichzeitig live.

Vorteile:

• schneller einheitlicher Zielzustand,
• weniger langer Parallelbetrieb,
• klare Umstellung.

Risiken:

• größere Cutover-Komplexität,
• mehr Nutzer gleichzeitig,
• mehr Supplier Enablement,
• hohe Testabhängigkeiten,
• mehr organisatorisches Risiko.

Phased Rollout

Module, Länder oder Prozesse werden in Waves eingeführt.

Beispielsweise:

Wave 1: Supplier Management
Wave 2: Sourcing und Contracts
Wave 3: Buying
Wave 4: weitere Länder

SAP beschreibt für Ariba ausdrücklich verschiedene Deployment-Szenarien und unterstützt auch stufenweise Einführungsmodelle.

Vorteile:

• Risiken werden verteilt,
• Learnings aus früheren Waves können genutzt werden,
• Change ist besser steuerbar.

Nachteile:

• längeres Transformationsprogramm,
• Übergangsarchitekturen,
• mögliche Doppelprozesse.

Template + Pilot + Rollout Waves

Für internationale Unternehmen ist häufig ein drittes Modell interessant:

1. Globales Template definieren
2. In einer geeigneten Gesellschaft pilotieren
3. Erfahrungen einarbeiten
4. Template stabilisieren
5. Rollout in Länder-Waves

Wichtig ist allerdings:

Der Pilot darf nicht zum Sondermodell werden.

Sonst wird aus dem „globalen Template“ lediglich der Prozess eines einzelnen Landes.

Wo SAP-Ariba-Projekte in der Praxis scheitern

SAP Ariba scheitert selten daran, dass eine Schaltfläche fehlt.

Projekte geraten ins Rutschen, wenn Unternehmen gleichzeitig Prozesse, Daten, Lieferanten und Organisation verändern – ohne diese Abhängigkeiten früh genug zu planen.

1. Der Scope ist zu groß

Sourcing, Buying, Contracts, SLP, Supplier Risk, Business Network, mehrere ERP-Systeme und zwölf Länder gleichzeitig?

Technisch möglich.

Projektseitig riskant.

Der größte Scope ist nicht automatisch der beste Business Case.

2. Alte Prozesse werden 1:1 übertragen

„Wir machen es heute so“ ist kein Architekturprinzip.

Cloud-Transformation sollte Gelegenheit sein, Prozesskomplexität zu reduzieren.

3. Jede Ausnahme wird zum Requirement

Eine lokale Sonderregel wird zum Custom Field.

Das Custom Field benötigt Mapping.

Das Mapping benötigt Tests.

Das Mapping muss bei Releases berücksichtigt werden.

Eine kleine Ausnahme kann damit einen langen technischen Schatten werfen.

4. Daten kommen zu spät

Wenn Lieferanten- und Organisationsdaten erst kurz vor dem Integration Test verfügbar sind, werden Probleme entdeckt, wenn Zeit für strukturelle Änderungen kaum noch vorhanden ist.

5. Integration wird als später IT-Workstream behandelt

Procurement-Prozess und Integration sind voneinander abhängig.

Wenn erst nach dem Solution Design geklärt wird, welches System eine Bestellung oder einen Lieferanten führen soll, wurde die Architektur in falscher Reihenfolge entwickelt.

6. Supplier Enablement beginnt zu spät

Besonders kritisch bei Business-Network- und transaktionalen Szenarien.

7. Change beginnt erst vor Go-live

Eine E-Mail mit:

„Ab Montag nutzen wir SAP Ariba“

ist keine Change-Strategie.

8. Go-live gilt als Endpunkt

Nach dem Go-live beginnt erst die Frage, ob:

• Mitarbeiter das System nutzen,
• Lieferanten digital arbeiten,
• Spend compliant wird,
• Sourcing schneller wird,
• Prozesskosten sinken.

Der Projektplan braucht deshalb nicht nur eine Go-live-Milestone.

Er braucht Business-Outcome-Milestones nach dem Go-live.

SAP Ariba in Deutschland einführen: Was zusätzlich relevant ist

Eine deutsche Implementierung benötigt keine grundsätzlich andere SAP-Activate-Methodik.

Lokale Anforderungen können den Scope jedoch beeinflussen.

Ein wichtiges Beispiel ist die E-Rechnung.

Seit dem 1. Januar 2025 gelten in Deutschland neue Regeln für die E-Rechnung bei Umsätzen zwischen inländischen Unternehmen. Das Bundesfinanzministerium weist darauf hin, dass für nach dem 31. Dezember 2024 ausgeführte B2B-Umsätze grundsätzlich die neuen E-Rechnungsregeln gelten, wobei Übergangsregelungen bestehen. Seit 2025 gilt zudem nur noch ein strukturiertes elektronisches Format als E-Rechnung; ein einfaches PDF allein erfüllt diese Definition nicht.

Wenn SAP Ariba Buying and Invoicing oder SAP Business Network Teil des Projekts sind, sollte deshalb früh geprüft werden:

• welche Rechnungskanäle verwendet werden,
• welche Formate unterstützt werden müssen,
• wie ERP- und Finance-Prozesse angebunden sind,
• welche Archivierungs- und Compliance-Anforderungen relevant sind.

Für internationale DACH-Programme kommen außerdem häufig unterschiedliche:

• Gesellschaftsstrukturen,
• Sprachen,
• Lieferantenpopulationen,
• lokale Einkaufsorganisationen

hinzu.

Lokale Anforderungen sollten berücksichtigt werden – aber nicht automatisch das globale Template dominieren.

Was bedeutet Next-gen SAP Ariba für neue Implementierungsprojekte?

2026 kommt eine zusätzliche strategische Frage hinzu.

SAP hat Next-gen SAP Ariba verfügbar gemacht und baut die neue Generation auf SAP Business Technology Platform auf. SAP beschreibt unter anderem eine stärker vereinheitlichte Datenbasis, offene APIs, engere Cloud-ERP-Integration und Joule-basierte intelligente Funktionen. Weitere Next-gen-Funktionen werden schrittweise über 2026 und 2027 bereitgestellt.

Für ein Unternehmen, das heute ein neues Ariba-Programm startet, bedeutet das nicht, dass bestehende beziehungsweise Current-gen-Lösungen pauschal vermieden werden sollten.

SAP ermöglicht bestehenden Kunden einen freiwilligen Übergang und einen Parallelbetrieb aktueller und Next-gen-Umgebungen während einer aktiven Transition.

Die Konsequenz für das Implementierungsdesign ist vielmehr:

Neue Projekte sollten nicht unnötig tief in Legacy-Customizations investieren, wenn SAP die zugrunde liegende Plattform gleichzeitig modernisiert.

Besonders relevant sind deshalb:

• standardnahe Prozesse,
• API-Strategie,
• Datenarchitektur,
• Clean Extensions,
• Integrationsroadmap,
• zukünftige Joule- und AI-Szenarien.

Eine Procurement-Roadmap sollte die heutige Geschäftsanforderung lösen – aber die Architektur von morgen nicht blockieren.

SAP-Ariba-Implementierung planen: Die Entscheidungsmatrix

Vor der Budget- oder Terminplanung sollten folgende Fragen beantwortet sein:

Daraus folgt ein einfaches Planungsprinzip:

Je mehr Module, Länder, Backend-Systeme, Lieferanten und Prozessabweichungen gleichzeitig verändert werden, desto stärker sollte die Einführung in klar definierte Waves zerlegt werden.

Zehn Fragen, die Sie einem SAP-Ariba-Implementierungspartner stellen sollten

Nicht jede Implementierungskompetenz zeigt sich in einer Produktdemo.

Vor einer Partnerentscheidung lohnt es sich, konkret zu fragen:

1. Welche Ariba-Module haben Sie tatsächlich implementiert?

Sourcing-Erfahrung ist nicht automatisch Buying-, SLP- oder Business-Network-Erfahrung.

2. Haben Sie SAP-Ariba- und S/4HANA-Kompetenz im selben Team?

Die interessantesten Probleme liegen häufig zwischen den Systemen.

3. Wie gehen Sie mit Fit-to-Standard um?

Ein guter Partner sollte nicht jedes Custom Requirement begeistert umsetzen.

4. Wer designt die Integrationsarchitektur?

Und wie werden Ariba, S/4HANA/ECC, Managed Gateway und weitere Middleware zusammengedacht?

5. Wie wird Data Cleansing organisiert?

Nicht nur Data Migration.

6. Wie sieht Supplier Enablement aus?

Besonders bei Buying und Business Network.

7. Welche Teststrategie verwenden Sie?

Unit Test allein reicht nicht.

8. Wie wird Change Management eingebunden?

Von Beginn an oder erst vor Go-live?

9. Wie sieht der Hypercare- und Support-Übergang aus?

Das Projektteam wird irgendwann gehen.

Der Procurement-Prozess bleibt.

10. Wie berücksichtigen Sie Next-gen SAP Ariba?

Die Antwort sollte konkreter sein als „Wir verfolgen die SAP-Roadmap“.

Häufige Fragen zur SAP-Ariba-Implementierung

Wie lange dauert eine SAP-Ariba-Implementierung?

Das hängt stark vom Scope ab. Für bestimmte standardisierte SAP Deployment Services nennt SAP beispielsweise 12 Wochen bis zum Go-live für SAP Ariba Sourcing sowie 14 Wochen für SAP Ariba Contracts und Supplier Lifecycle and Performance. Diese Zeiträume gelten jedoch für definierte Standard-Scopes und sind kein Benchmark für komplexe Multi-Modul-, Integrations- oder globale Rollout-Projekte.

Was kostet eine SAP-Ariba-Implementierung?

Es gibt keinen universellen Projektpreis. Die Gesamtkosten setzen sich aus Software beziehungsweise Subscription, Implementierung, Integration, Datenmigration, Supplier Enablement, Change Management, Rollout und Betrieb zusammen. SAP veröffentlicht beispielsweise den konkreten Preis für SAP Ariba Sourcing nicht öffentlich, sondern stellt Pricing-Details auf Anfrage bereit.

Welche Faktoren beeinflussen die SAP-Ariba-Kosten am stärksten?

Besonders relevant sind Anzahl der Module, Länder und Backend-Systeme, Custom Requirements, Datenqualität, Integrationsumfang, Lieferantenanzahl und Rollout-Modell. Je mehr dieser Faktoren gleichzeitig komplex sind, desto höher werden Design-, Test- und Projektmanagementaufwand.

Wie läuft eine SAP-Ariba-Einführung ab?

SAP empfiehlt die SAP-Activate-Methodik. Sie umfasst Discover, Prepare, Explore, Realize, Deploy und Run. Im eigentlichen Deployment stehen unter anderem Projektvorbereitung, Prozessdesign, Konfiguration, Daten, Testing, Go-live und Post-Go-live-Support im Mittelpunkt.

Was passiert in der Explore-Phase?

In Explore werden Anforderungen und Zielprozesse definiert. SAP ordnet dieser Phase unter anderem Requirements Gathering, Process Design, Datenanforderungen, Design Specifications sowie Change-Management-Strategie zu. Ziel sollte sein, Anforderungen gegen den Standard zu bewerten und unnötige Sonderlösungen zu vermeiden.

Kann SAP Ariba schrittweise eingeführt werden?

Ja. Besonders bei mehreren Modulen, Ländern oder ERP-Systemen kann ein phased rollout sinnvoll sein. Unternehmen können beispielsweise zunächst Supplier Management oder Sourcing einführen und weitere Procurement-Prozesse in späteren Waves ergänzen. SAP beschreibt für Ariba unterschiedliche Deployment-Szenarien.

Welches SAP-Ariba-Modul sollte zuerst eingeführt werden?

Darauf gibt es keine allgemeingültige Antwort. Ausgangspunkt sollte der Business Case sein. Wenn der größte Pain Point strategisches Sourcing ist, kann Sourcing die erste Wave sein. Liegt das Problem im Supplier Onboarding, kann Supplier Lifecycle and Performance sinnvoller sein. Bei hoher Maverick-Buying-Quote kann Buying beziehungsweise Guided Buying priorisiert werden.

Muss SAP Ariba mit SAP S/4HANA integriert werden?

Nein, nicht jedes Ariba-Szenario benötigt dieselbe Tiefe der ERP-Integration. In vielen Enterprise-Landschaften ist eine Integration jedoch sinnvoll oder notwendig, beispielsweise für Stammdaten, Bestellanforderungen, Bestellungen, Verträge oder Statusinformationen.

Kann SAP Ariba mit SAP ECC eingeführt werden?

Ja. SAP Ariba kann auch mit SAP ERP beziehungsweise ECC integriert werden. Wenn bereits eine S/4HANA-Transformation geplant ist, sollte die Integrationsarchitektur jedoch so entworfen werden, dass möglichst wenig später erneut gebaut werden muss.

Wie aufwendig ist die Datenmigration?

Das hängt weniger vom Datenvolumen als von der Datenqualität und Governance ab. Dubletten, unterschiedliche Supplier IDs, inkonsistente Kategorien und veraltete Vertrags- oder Katalogdaten können deutlich mehr Aufwand verursachen als eine größere, aber konsistente Datenbasis.

Wie werden Lieferanten in SAP Ariba onboarded?

Das hängt von der eingesetzten Ariba-Lösung und dem Supplier-Interaction-Modell ab. Typischerweise umfasst Supplier Enablement Segmentierung, Kommunikation, Registrierung, Verbindungsaufbau, Datenvalidierung, Tests und Support. Bei transaktionalen Business-Network-Szenarien sollte Supplier Enablement früh im Projekt starten.

Was sind die häufigsten Fehler bei einer SAP-Ariba-Implementierung?

Zu den häufigsten Projektproblemen gehören ein zu großer Initial-Scope, ungeprüfte Übernahme historischer Prozesse, zu viele Custom Requirements, verspätete Datenbereinigung, unterschätzte Integrationen, spätes Supplier Enablement und unzureichendes Change Management.

Welche internen Ressourcen braucht ein SAP-Ariba-Projekt?

Neben Projektmanagement werden typischerweise Procurement Process Owner, IT- und Integrationsexperten, Data Owner, Key User und Change-Verantwortliche benötigt. Bei größeren Programmen kommen lokale Rollout-Teams und Supplier-Enablement-Rollen hinzu.

Ist SAP Ariba nur ein IT-Projekt?

Nein. Die Technologie wird von IT und Implementierungspartnern umgesetzt, aber Procurement muss fachliche Entscheidungen zu Prozessen, Governance, Lieferanten und Einkaufsrichtlinien besitzen. Ohne starke Procurement Ownership entsteht häufig ein technisch funktionierendes System, das fachlich nicht ausreichend standardisiert ist.

Wie beeinflusst Next-gen SAP Ariba neue Implementierungen?

Next-gen SAP Ariba ist seit 2026 verfügbar und wird schrittweise erweitert. Die neue Generation basiert auf SAP BTP und bringt unter anderem offene APIs, eine stärker vereinheitlichte Datenbasis und eingebettete Joule-Funktionen. Neue Projekte sollten deshalb insbesondere bei Customizing, Integration und Datenarchitektur die zukünftige Ariba-Roadmap berücksichtigen.

Fazit: Die SAP-Ariba-Implementierung beginnt mit dem Scope, nicht mit der Konfiguration

Die Frage „Wie schnell können wir SAP Ariba implementieren?“ lässt sich erst sinnvoll beantworten, wenn klar ist, was tatsächlich verändert werden soll.

Ein einzelnes Sourcing-Modul, ein integriertes Buying-Szenario und eine globale Source-to-Pay-Transformation sind drei unterschiedliche Projekte.

Entscheidend sind deshalb nicht möglichst viele Funktionen in Wave 1, sondern:

ein klarer Business Case, ein kontrollierter Scope, standardnahe Prozesse, saubere Daten, belastbare Integrationen und eine Organisation, die den neuen Prozess tatsächlich übernimmt.

Dann wird der Go-live nicht zum Ziel des Projekts, sondern zum Startpunkt für messbare Procurement-Verbesserungen.

LeverX unterstützt Unternehmen bei der Planung und Implementierung von SAP Ariba – von Prozess- und Architekturdesign über SAP-S/4HANA- und ECC-Integration bis zu Datenmigration, Supplier Enablement, Rollout und kontinuierlicher Optimierung.