Überprüfung von SAP, Supply Chain Planung Softwareanbieter

Von Léon Levinas-Ménard

Zuletzt aktualisiert: Dezember, 2025

SAP SE ist ein börsennotierter Anbieter von Unternehmenssoftware, dessen supply chain Angebot am besten als Portfolio verstanden werden kann: ein transaktioneller „digitaler Kern“ (SAP S/4HANA), umgeben von spezialisierten Anwendungen für die Planung (SAP Integrated Business Planning, „IBP“), Ausführung (z. B. Extended Warehouse Management und Transportation Management) und netzwerkübergreifende Sichtbarkeit (z. B. Supply Chain Control Tower). In supply chain Begriffen liefern SAPs Produkte typischerweise (i) prozessintegrierte Planung und Ausführung, verankert in ERP-Stamm-/Transaktionsdaten, (ii) Szenarioplanung und Optimierungsfunktionen, eingebettet in spezifische Module (insbesondere IBP), und (iii) eine Integrationsplattform-Schicht (SAP Business Technology Platform, „BTP“) sowie ein großes Partner-Ökosystem für Implementierung, Anpassung und Betrieb.

SAP Überblick

Die supply chain-spezifischste Planungsproduktfamilie von SAP ist SAP Integrated Business Planning (IBP), das als Suite vermarktet wird, die S&OP/S&OE, Bedarfs-, Versorgungs-, Bestandsplanung und Überwachung abdeckt.¹² In der Ausführung positioniert SAP Extended Warehouse Management (EWM) für Lagerprozesse und Transportation Management (TM) für Transportplanung und -überwachung (einschließlich restriktionsbewusster Planung, wie in der Hilfedokumentation beschrieben).³²⁴ Die Fertigungsplanung wird üblicherweise über das in S/4HANA eingebettete Production Planning and Detailed Scheduling (PP/DS) abgewickelt, wobei SAP-Schulungsmaterial finite Planungs- und Detaillierungsziele sowie entsprechende Werkzeuge beschreibt.⁵²

Technisch ist SAPs Planungs- und Analytikstrategie eng geknüpft an seine Datenbank- und Plattformstrategie: SAP HANA (ein In-Memory-DBMS, das sich auf Column-Store konzentriert) wird mit Mechanismen wie Column-Store Main-/Delta-Speicherung und „Delta Merge“ dokumentiert, die zentral für seine Leistungsmerkmale sind.⁶⁷⁸ Für Erweiterbarkeit und Integrationen setzt SAP BTP-Komponenten wie den Kyma Runtime (Kubernetes-basiert) und das Cloud Application Programming Model (CAP) ein, um Dienste im SAP-Cloud-Ökosystem zu erstellen.⁹¹⁰

Kommerziell ist SAP ein etablierter Anbieter mit den Offenlegungspflichten und dem operativen Umfang eines großen börsennotierten Unternehmens, was sich in seinen Jahresberichten und Investorenmaterialien widerspiegelt.¹¹

SAP vs Lokad

SAP und Lokad unterscheiden sich zunächst in der Produktstruktur: SAP ist eine umfangreiche Unternehmenssuite, die durch ERP-Transaktionen (S/4HANA) verankert und von spezialisierten Modulen (IBP, EWM, TM, Control Tower) umgeben ist, während Lokad eine einzelne Cloud-Plattform für „die Quantitative Supply Chain“-Apps positioniert, die als Code programmiert und iterativ weiterentwickelt werden (anstatt hauptsächlich durch Modulkonfiguration zusammengesetzt zu werden).¹²¹³

Zudem unterscheiden sie sich in der Planungsphilosophie und den Ergebnissen. SAP IBP stellt die Planung als eine Reihe integrierter Prozesse dar (Bedarf, Versorgung, Bestand, S&OP/S&OE) mit eingebetteten Optimierungsfunktionen und Workflows.¹² Lokad betrachtet das Ergebnis als eine entscheidungsorientierte Optimierungspipeline: probabilistische Prognosen und finanziell priorisierte Entscheidungen, mit expliziter Modellierung wirtschaftlicher Abwägungen als erstklassige Eingaben.¹³¹⁴¹⁵

Hinsichtlich technischer Transparenz veröffentlicht SAP funktionale Dokumentationen und einige algorithmische Hinweise (z. B. verweist Demand Sensing auf Gradient Boosting; „Supply Optimizer“-Inhalte und Beispiele verweisen auf gemischt-ganzzahlige Programmierung), aber der „vollständige Stack“ aus Modelltraining, Solver-Auswahl und End-to-End-Reproduzierbarkeit wird typischerweise nicht als ein einzeln prüfbares Artefakt an Kunden geliefert.¹⁶¹⁷¹⁸ Lokad macht designbedingt die kundenspezifische Logik in einer domänenspezifischen Sprache (Envision) explizit und präsentiert seine Architektur als eine programmierbare Ausführungsumgebung.¹³¹⁴

Schließlich weicht der Deployment-Stil ab: SAP-Implementierungen stützen sich häufig auf die SAP Activate-Methodik und große Systemintegrationsprogramme, die sich über mehrere Module und Datendomänen erstrecken.¹⁹ Die dokumentierte Vorgehensweise von Lokad liegt näher an einer iterativen Build-Run-Schleife mit einem engeren Optimierungsumfang, bei der die „Anwendung“ der sich entwickelnde Optimierungscode und dessen automatisierte Ausführungen ist.¹³¹⁴

Unternehmensidentität, Geschichte und Akquisitionen

SAP wurde 1972 gegründet und stellt eine eigene Chronik der Unternehmensgeschichte als primäre Referenz für wesentliche Meilensteine bereit.²⁰ Als börsennotiertes Unternehmen sind SAPs Jahresberichte und Form 20-F-Einreichungen die maßgeblichsten Quellen für Governance, Risikoberichte, Geschäftsstruktur und Segmentberichterstattung.¹¹

SAP hat eine lange Akquisitionshistorie; mehrere Transaktionen haben seine Daten-/Analytik- und Supply Chain Planung-Fähigkeiten wesentlich geprägt. Beispiele:

Sybase (2010 angekündigt/abgeschlossen), oft als strategischer Schritt in SAPs Datenbank- und Mobilitätsambitionen genannt.²¹
SmartOps (2013 angekündigt), von SAP explizit als Optimierung von Beständen und Servicelevels für die supply chain positioniert.²²
LeanIX (Fertigstellungsankündigung in 2023), ausgerichtet auf Enterprise Architecture Management (relevant für groß angelegte Transformationsprogramme, anstatt direkt auf supply chain Algorithmen).²³
WalkMe (Fertigstellungsankündigung in 2024), ausgerichtet auf digitale Akzeptanz (wiederum transformationsbedingt anstatt einer Planungs-Engine).²⁴

Unabhängige Berichterstattungen über diese Akquisitionen gibt es, aber das „Warum“ und die beabsichtigte Produktintegration werden am verlässlichsten in SAPs eigenen Einreichungen und Transaktionsankündigungen festgehalten, wobei Berichte Dritter am besten als kontextuell und nicht als abschließend zu betrachten sind.¹¹²²

Supply chain Produktumfang und was SAP liefert

SAPs supply chain Umfang ist breit; die praktischen Ergebnisse hängen davon ab, welche Komponenten eingesetzt werden:

Kernausführungsrückgrat (ERP): SAP S/4HANA als transaktionelles System zur Erfassung von Bestellungen, Lagerbuchungen, Beschaffung, Produktionsausführungsbuchungen und finanzgesteuerter Abstimmung.¹¹
Planung (IBP): IBP wird als integrierte Planungssuite positioniert, die den Ausgleich von Nachfrage und Angebot, Bestandsplanung und Überwachung abdeckt, wobei Produktseiten und Hilfeseiten den Funktionsumfang beschreiben.¹²
Lagerausführung (EWM): EWM wird als Lagerverwaltungssystem positioniert, das Prozessunterstützung und Automatisierungsoptionen bietet.³
Transportplanung/-ausführung (TM): Die TM-Dokumentation beschreibt die Transportplanung unter Einschränkungen wie Servicelevel, Kosten und Ressourcenverfügbarkeit.⁴
Sichtbarkeit und Orchestrierung (Control Tower): Der Supply Chain Control Tower wird um End-to-End-Sichtbarkeit und ereignisgesteuerte Überwachung positioniert und oft als „Kontrollschicht“ über mehrere Ausführungs- und Planungssysteme eingesetzt.²⁵

Eine kritische Beobachtung für technische Käufer: Die supply chain „Lösung“ von SAP ist selten ein einzeln einsetzbares Artefakt. Es handelt sich um eine Konfiguration mehrerer Produkte, von denen jedes eigene Erwartungen an das Datenmodell, Integrationspfade und Betriebsverfahren hat – in der Regel geliefert durch eine Methodik und ein Partner-Ökosystem statt als schlüsselfertiges Paket.¹⁹¹¹

Mechanismen, Architekturen und Belege für KI/Optimierungsansprüche

Planung und Optimierung in SAP IBP

SAPs expliziteste Optimierungsansprüche in der supply chain Planung konzentrieren sich auf IBP. Öffentliche Materialien bieten teilweise Einblick in die zugrunde liegenden Mechanismen:

Demand Sensing / kurzfristige Formgebung: Die SAP-Dokumentation verweist auf Machine-Learning-Ansätze im Demand Sensing, einschließlich Beschreibungen, die Gradient Boosting erwähnen.¹⁶
Supply Optimization: SAP-Materialien und -Beispiele diskutieren „Supply Optimizer“-Ansätze, die auf gemischt-ganzzahlige Formulierungen und Optimierungs-Benchmarking verweisen, was mit einer MILP-Style-Planungsoptimierung übereinstimmt – öffentliche Quellen geben jedoch typischerweise nicht die vollständige Solver-Auswahl, Dekompositionsstrategie oder Garantien (Optimierungsgrenzen, Konvergenzkriterien) preis, die eine unabhängige End-to-End-Reproduktion ermöglichen würden.¹⁷¹⁸

Kurz gesagt, es gibt Hinweise darauf, dass IBP echte Optimierungskomponenten enthält (und nicht nur CRUD-Workflows), aber das öffentlich verfügbare Material ist in der Regel nicht ausreichend, um „State-of-the-Art“-Ansprüche über das „Verwenden von gängigen OR/ML-Techniken in einem kommerziellen Produkt“ hinaus zu validieren.

Plattform-Grundlagen: SAP HANA und BTP

Die Architektur von SAP HANA wird in SAPs eigenen Hilfematerialien dokumentiert (z. B. Column Store, Main-/Delta-Speicherung, Delta Merge), was die Behauptung stützt, dass SAPs Leistungsstrategie auf In-Memory- und spaltenbasierten Datenstrukturen basiert.⁶⁷⁸ Für Erweiterbarkeit und cloud-native Bereitstellungen positioniert SAP BTP-Komponenten wie den Kyma Runtime und CAP; diese sind in SAPs eigener Entwicklerdokumentation und auf Plattformseiten dokumentiert.⁹¹⁰

Diese Komponenten sind von Bedeutung, da SAP-Implementierungen häufig auf: (i) Replikation/Virtualisierung von ERP-Daten in Analyse- bzw. Planungskontexte, (ii) kundenspezifische Services und Integrationen sowie (iii) Erweiterungs-Apps für Planungs-Workflows angewiesen sind – häufig implementiert auf BTP statt innerhalb des ERP-Kerns.¹¹⁹

Bereitstellungs- und Rollout-Methodik

SAP bewirbt SAP Activate als seine Implementierungsmethodik, die typischerweise in Phasen (discover/prepare/explore/realize/deploy/run) beschrieben wird und bei S/4HANA sowie verwandten Produkteinführungen eingesetzt wird.¹⁹ In der Praxis stimmt dies mit dem beobachteten Marktverhalten überein: SAP supply chain Programme sind häufig Transformationen mit mehreren Arbeitsströmen (Daten, Prozesse, Integration, Change Management), mit erheblicher Einbeziehung von Systemintegration und langanhaltender operativer Governance.¹¹¹⁹

Kundengeschichten und Partnerfallstudien können Ergebnisse veranschaulichen, sollten aber als hinweisende Belege behandelt werden: Sie lassen häufig Kosten, Zeitpläne, Fehlerquoten und das Ausmaß, in dem Ergebnisse auf Softwarefähigkeiten gegenüber Prozessneugestaltung und Datenbereinigung zurückzuführen sind, außer Acht.²⁶²⁷

Öffentlich benannte Kunden und Referenzbelege

SAP stellt öffentlich Kundenstories und Referenzen in seinem Portfolio vor, einschließlich im Kontext der supply chain Planung.¹ Unabhängige Bestätigungen variieren je nach Kunde und Initiative; die verlässlichsten Referenzen sind diejenigen, bei denen der Kunde (oder ein großer SI-Partner) eine namentlich genannte Fallstudie mit konkret definiertem Umfang und eingesetzten Modulen veröffentlicht, anstatt anonymisierte „global manufacturer“-Erzählungen.²⁶²⁷

Wenn SAP-Materialien nur Logowände oder allgemeine Behauptungen ohne Umfang, Zeitpläne und Modulbenennung liefern, sollten diese Referenzen als schwache Belege für spezifische technische Fähigkeiten betrachtet werden.

Bewertung der technischen Reife und des „State-of-the-Art“-Niveaus

Kommerzielle Reife: SAP ist ein etablierter Anbieter mit umfangreicher Installationsbasis und geregelten Offenlegungen; es ist in Marktpräsenz und operativem Footprint nicht sinnvoll mit einem Startup vergleichbar.¹¹
Technische Reife: SAPs Stack spiegelt Jahrzehnte an Unternehmens-Engineering wider: ERP-Transaktionsmodelle, ein modernes In-Memory-DBMS mit dokumentierten Interna und eine Cloud-Plattform-Strategie mit Kubernetes-nativen Komponenten.⁶⁹
State-of-the-art (enger technischer Sinn): Die öffentlich sichtbaren Planungsalgorithmen von SAP (z. B. Verweise auf Gradient Boosting; Verweise auf gemischt-ganzzahlige Optimierung) entsprechen der gängigen ML/OR-Praxis, anstatt eindeutig neuartige Forschungsbeiträge zu sein. Der stärkste Beleg ist „Industrialisierung und Integration im großen Maßstab“, nicht einzigartig fortgeschrittene Algorithmen, die aus öffentlichen Artefakten unabhängig reproduziert werden können.¹⁶¹⁸

Fazit

Die supply chain Software von SAP lässt sich am besten als modulare Unternehmenssuite charakterisieren: Planung (IBP), Ausführung (EWM/TM/ERP) und Sichtbarkeitsschichten (Control Tower), integriert durch eine Plattformstrategie (HANA + BTP). Öffentliche Dokumentationen belegen, dass SAP in der Planung echte Optimierungs- und ML-Funktionen liefert (und nicht nur Workflow-Software), aber die Belege sind in der Regel eher übergeordnet: Kunden können die Leistungsfähigkeit durch Pilotprojekte und detaillierte Produktdokumentationen validieren, dennoch ist eine unabhängige, reproduzierbare technische Überprüfung der „State-of-the-Art AI“-Ansprüche allgemein durch die inhärente Intransparenz kommerzieller Unternehmenssuites eingeschränkt. Kommerziell und operativ ist SAP ein äußerst reifer Anbieter; technisch liegt seine Differenzierung mehr in der Breite, Integration und Industrialisierung als in einzigartig transparenter oder forschungsführender Optimierung.