Weichenstellung in der Beschaffung: Übergang von SAP SRM zu integrierten Lösungen

Mit dem angekündigten Support-Ende von SAP SRM stehen viele Unternehmen vor einer doppelten Weichenstellung: Einerseits rückt der Umstieg auf SAP S/4HANA näher, andererseits müssen Beschaffungsprozesse neu gedacht und in moderne Architekturen überführt werden. Dabei zeigt sich: Der reine „Funktionsersatz“ greift zu kurz. Entscheidend ist, wie eng ERP und Beschaffungsoberfläche künftig zusammenspielen, wo Business-Logik verankert bleibt, und wie sich Cloud-Modelle sicher in bestehende ERP-Strukturen einfügen lassen. [...]

Ein System wie SAP SRM verschwindet nicht spur- und folgenlos. Zurück bleiben gewachsene Workflows, fest verankerte ERP-Regeln, Abkürzungen für Ausnahmen – und die Erwartung, dass Beschaffung schnell, konform und verlässlich bleibt. Mit dem Auslaufen von SAP SRM [1] stellt sich vielen Unternehmen deshalb weniger die Frage nach einem Funktionsklon als nach einer stimmigen Neuordnung: Wo verortet man künftig die fachliche Logik, wie greifen ERP und Beschaffungsoberfläche ineinander, welche Bereiche gehören bewusst in die Cloud – und was bleibt im Kernsystem?

Wer diese Fragen beherzigt, kann Komplexität senken, Parallelwelten verhindern und Spielraum für die nächsten Jahre schaffen. Die folgenden Punkte markieren den Weg dorthin und zeigen, worauf Unternehmen achten sollten:

• Ausgangslage ordnen – Möglichkeiten ohne Illusionen: Im Wesentlichen stehen zwei Wege im Raum. S/4 mit Freitext-/Katalogfunktionen oder eine Cloud-Lösung wie Ariba. Anwender des bewährten SAP SRM müssen sich daran gewöhnen, dass nicht alle auf dem Markt verfügbaren Alternativen dieselbe funktionale Tiefe und Flexibilität bieten. Entsprechend wichtig ist eine sorgfältige Bewertung des Integrationsaufwands.
• S/4-Transformation als Taktgeber nutzen: Viele Unternehmen stehen ohnehin vor der Migration auf S/4HANA. Das ist der natürliche Moment, Beschaffung architektonisch neu zu ordnen: Daten-, Rollen- und Integrationsmodelle werden dabei angepasst; Doppelarbeit und spätere Umbauten lassen sich vermeiden, wenn die SRM-Ablösung an diesen Takt gekoppelt wird.
• Integrationsprinzip festlegen – Echtzeit statt Datenkopien: SAP SRM war tief ins ERP verwoben. Ein tragfähiger Nachfolger nutzt ERP-Daten möglichst in Echtzeit und führt Ergebnisse sauber ins Kernsystem zurück – ohne redundante Datentöpfe. Je näher Beschaffung an den SAP-Strukturen der Materialwirtschaft (MM) und des Controllings (CO) bleibt, desto geringer fallen Integrations-, Betriebs- und Pflegeaufwände aus; Prozesse bleiben auditfest und änderbar. Replizierungsarme Anbindung ist kein Komfortmerkmal, sondern Grundlage für Stabilität und niedrige Gesamtbetriebskosten (Total Cost of Ownership, kurz: TCO).
• Ort der Business-Logik entscheiden – im Kernsystem verankern: Genehmigungen, Berechtigungen, Kontierungen, Datenableitungen: Wo diese Logik liegt, entscheidet über Nachvollziehbarkeit und Änderbarkeit. Bewährt hat sich, die fachliche Steuerung im SAP zu belassen und die Beschaffungsoberfläche konsequent darauf aufzusetzen. So bleiben Anpassungen transparent – und die IT handlungsfähig, ohne auf spezifisches Wissen von Spezialisten angewiesen zu sein.
• Funktionsdeckung sichern – Stärken mitnehmen, Lücken benennen: Gefordert sind eine leistungsfähige, katalogübergreifende Suche, automatisierte Produktvergleiche, konsistente Kanäle (Lieferanten- und interne Kataloge, Materialstamm, Verträge, Lager, Marktplätze), ein sauberer Freitext-Intake zur Erfassung nicht katalogisierter Bestellungen sowie Sourcing-Abläufe. Potenzielle Lücken sollten früh benannt und explizit geplant werden – etwa bei Mehrfach-Klassifikationen (E-Class parallel zu domänenspezifischen Bäumen) oder im Supplier-Lifecycle von Registrierung über Onboarding/Qualifizierung bis hin zur Performancebewertung. Wo Funktionen per Roadmap vorgesehen sind, gehören belastbare Meilensteine, Akzeptanzkriterien und ein Ausweichpfad in die Vereinbarungen.
• Cloud mit Maß – Datenhoheit wahren: Ein tragfähiges Muster trennt Verantwortlichkeiten: Konfiguration und Prozesslogik können in der Cloud liegen, operative Geschäftsdaten sollten jedoch im ERP verbleiben. So lassen sich Skalierung und Release-Tempo der Cloud nutzen, ohne Datensouveränität und Compliance zu gefährden. Entscheidungsreif wird der Ansatz erst mit klaren Aussagen zu Protokollen, Aufbewahrungsorten, Zugriffen und Prüfpfaden.
• Betriebsmodell realistisch denken – beherrschbar durch die eigene IT: Der Zielzustand darf nicht an wenigen Spezialprofilen hängen. Eine Lösung, die interne Teams verstehen, betreiben und erweitern können, reduziert die TCO und Reaktionszeiten. Geringe Replikation, klare Erweiterungspunkte und überschaubare Lernkurven sind die Stellhebel, die in der Praxis Kosten und Risiken spürbar senken.
• Nutzererlebnis als Hebel – Guided Buying und Freitext operationalisieren: Akzeptanz entsteht, wenn Anfordernde ohne Umwege richtig einkaufen können: ein Einstiegspunkt, kuratierte Kanäle, vorausgefüllte Attribute und plausible Vorschläge (Materialgruppe, Vertrag, Kostenstelle). Freitext wird beherrschbar, wenn die Erfassung strukturiert erfolgt und automatisch in das Regelwerk des ERP mündet – erst dann werden Automatisierung, Messbarkeit und hohe Dunkelverarbeitungsraten erreichbar.
• Migration entscheiden – entschlossen statt endlos interim: Mischarchitekturen aus SRM, Hub und Cloud-Suite neigen dazu, sich zu verstetigen. Erfolgreich ist die Umstellung vor allem dann, wenn sie konsequent geplant und umgesetzt wird – entweder als vollständiger Wechsel, bei dem die neue Plattform alle relevanten SRM-Prozesse auf einmal übernimmt (die sogenannte Big-Bang-Migration), oder als schrittweise Einführung mit klaren Terminen und einer eindeutigen Exit-Strategie für das Altsystem. Lange Zwischenwelten kosten hingegen Momentum, erzeugen doppelten Pflegeaufwand und zementieren Sonderwege, die sich später nur schwer wieder auflösen lassen.
• Marktbild richtig lesen – Architektur vor Feature-Listen: Neben SAP-eigenen Bausteinen existiert eine breite Anbieterlandschaft. Entscheidend ist weniger die Anzahl der Häkchen in Tabellen als die Architekturentscheidung: Wie eng dockt die Lösung ans ERP an? Wo liegt die Logik? Wer betreibt und erweitert sie im Alltag?

Beispiel: SAP-nah denken, ERP nicht duplizieren

Oft bewährt sich ein Ansatz, der vom ERP her gedacht ist: Replikation minimieren, bestehende SAP-Strukturen nutzen, fachliche Steuerung im Kernsystem belassen – und die Beschaffungsschicht darauf ausrichten. So entsteht ein beherrschbarer Betrieb durch die eigene IT bei niedrigem TCO. Der Anbieter BeNeering [2] folgt dieser Philosophie als SAP-nahes Beispiel und adressiert SRM-Domänen so weit wie möglich: cross-Katalog-Suche mit automatisierten Vergleichen, strukturierten Kanälen, Freitext-Formularen; Weiterentwicklungen erfolgen konsequent nutzwertgetrieben. Das erleichtert den Umstieg, ohne das ERP aus der Hand zu geben.

Fazit

Die Ablösung von SAP SRM ist kein Feature-Tausch, sondern eine Architektur- und Betriebsentscheidung. Wer Integrationsprinzip, Ort der Business-Logik, Funktionsdeckung (inkl. potenzieller Lücken), Datenhoheit, Nutzererlebnis und Migration früh verbindlich klärt – und die Wirkung statt nur Lizenzen bewertet –, reduziert Projektrisiken und gewinnt Geschwindigkeit. So entsteht ein Zielbild, das heute trägt und morgen erweitert werden kann.