Pexon Consulting | 9 Min. Lesezeit | 16.07.2026
TL;DR
SAP Bestandsoptimierung mit ML-Bedarfsprognose hebt totes Kapital aus dem Lager, ohne die Lieferfähigkeit zu senken. Pexon (Data und KI) analysiert echte SAP-Verbrauchsdaten, Partner WIAG pflegt die Dispo-Parameter im SAP. In einem 6-Wochen-Check zum Festpreis setzen Mittelständler typisch 10 bis 30 Prozent Überbestand frei, bei 30 Mio EUR Bestand sind das 3 bis 9 Mio EUR Cash.
Warum in Ihrem SAP-Lager totes Kapital liegt
Bei 200 Mio EUR Umsatz stecken im Mittelstand typisch 25 bis 50 Mio EUR im Bestand, und 10 bis 30 Prozent davon lassen sich meist ohne jedes Lieferrisiko freisetzen. Der Grund ist selten operativ, sondern liegt in den Stammdaten: Dispo-Parameter, die über Jahre nie nachgepflegt wurden.
Nach den Lieferkettenkrisen 2021 und 2022 haben fast alle Disponenten die Sicherheitsbestände hochgedreht. Verständlich, damals war Lieferfähigkeit alles. Nur: zurückgenommen hat die Werte danach kaum jemand. Sie stehen bis heute im Materialstamm und binden Cash. Gleichzeitig ist jeder Euro Überbestand teurer geworden. Das EZB-Zinsniveau der Jahre 2024 bis 2026 macht Lagerfinanzierung zu einer echten GuV-Position, nicht mehr zu einer Fußnote.
Dazu kommt der Klassiker: Reichweitenlisten. Viele Häuser steuern ihren Bestand über statische Reichweiten, etwa „sechs Wochen für alles in dieser Warengruppe“. Das ist der teuerste Kompromiss, den man treffen kann. Eine Schraube mit stabilem Wochenbedarf braucht keine sechs Wochen Puffer, ein sporadisch abgerufenes Ersatzteil mit 14 Wochen Wiederbeschaffungszeit ist damit chronisch unterversorgt. Die pauschale Regel produziert an beiden Enden Schaden: totes Kapital bei den Schnelldrehern, Fehlteile bei den Langsamdrehern.
So funktioniert SAP Bestandsoptimierung mit ML-Bedarfsprognose
Wir lesen die echten Verbrauchsdaten read-only aus Ihrem SAP, prognostizieren je Material den Bedarf mit klassischem Machine Learning und simulieren daraus optimale Dispo-Parameter. Erst danach schreibt jemand etwas ins SAP zurück, kontrolliert und in Wellen. Keine neue Software, kein Parallelsystem.
Der Extraktionsweg ist read-only über ODP und CDS-Views. Wir ziehen die Materialbewegungen (Tabelle MSEG/MKPF beziehungsweise die entsprechenden CDS-Views), die Dispo-Stammdaten aus MARC und die Materialstämme. Ein schlanker CDS-View als Extraktionsbasis sieht so aus:
@AbapCatalog.sqlViewName: 'ZBESTVERBR'
@EndUserText.label: 'Verbrauch je Material und Monat für die Prognose'
@Analytics.dataCategory: #FACT
define view Z_Bestand_Verbrauch as
select from matdoc as bewegung
association [1] to marc as _disp
on bewegung.matnr = _disp.matnr
and bewegung.werks = _disp.werks
{
key bewegung.matnr as Material,
key bewegung.werks as Werk,
// Buchungsmonat als Aggregationsebene für den Forecast
key concat(substring(bewegung.budat, 1, 4),
substring(bewegung.budat, 5, 2)) as Periode,
// nur echte Warenausgänge (Bewegungsart 261/601) zählen als Verbrauch
@Semantics.quantity.unitOfMeasure: 'Basiseinheit'
sum(bewegung.menge) as Verbrauchsmenge,
_disp.eisbe as Sicherheitsbestand, // heutiger Wert, unser Referenzpunkt
_disp.plifz as Wiederbeschaffungszeit,
_disp.dismm as Dispomerkmal
}
where bewegung.bwart = '261' or bewegung.bwart = '601'
group by bewegung.matnr, bewegung.werks,
bewegung.budat, _disp.eisbe, _disp.plifz, _disp.dismmEin technischer Punkt, der 2026 akut ist: Wer ODP nutzt, muss den Extraktionsweg prüfen. Seit Juni 2026 kontrolliert SAP im ODP-Framework den Subscriber-Type und blockt Nicht-SAP-Consumer, die klassisch über RFC ziehen. Der saubere Weg ist ODP-OData. Wir setzen das direkt so auf, damit die Extraktion auch nach dem Patch stabil läuft. Die Rohdaten landen auf einer Databricks- beziehungsweise EU-Cloud-Datenplattform, nicht in einem SAP-Modul. Diese Trennung ist bewusst: Der Forecast rechnet auf einer offenen AI-ready Data Platform, das SAP bleibt das führende System für die Umsetzung.
Der Forecast selbst ist bewusst kein LLM. Wir rechnen Bedarfsprognosen mit Gradient Boosting und statsmodels, weil das reproduzierbar, erklärbar und je Material auditierbar ist. Ein Sprachmodell nutzen wir nur an einer Stelle: für die natürlichsprachliche Erklärung der Ergebnisse, damit Ihr Disponent liest, warum ein Sicherheitsbestand fallen darf. Dafür läuft claude-sonnet-5 über die aggregierten Zahlen, nie über das Roh-Material.
Dispo-Parameter differenzieren statt Sicherheitsbestand pauschal senken
Sicherheitsbestand pauschal um 20 Prozent zu senken ist gefährlich und der schnellste Weg zu Fehlteilen. Der einzige seriöse Weg ist, jeden Parameter je Material aus der Prognose abzuleiten: Sicherheitsbestand, Losgröße, Dispomerkmal und Wiederbeschaffungszeit differenziert, nicht per Rasenmäher.
Konkret läuft je Material eine Prognose mit Prognosefehler, und der Sicherheitsbestand ergibt sich aus dem gewünschten Servicegrad und genau diesem Fehler, nicht aus einer Wochenregel. So sieht der Kern der Simulation aus:
import numpy as np
from sklearn.ensemble import HistGradientBoostingRegressor
from scipy.stats import norm
# X = Kalender-/Saison-Features je Periode, y = tatsächlicher Verbrauch
modell = HistGradientBoostingRegressor(max_iter=300, learning_rate=0.05)
modell.fit(X_train, y_train)
prognose = modell.predict(X_test)
prognose_fehler = np.std(y_test - prognose) # Streuung des Prognosefehlers
# Sicherheitsbestand aus Servicegrad ableiten, nicht pauschal setzen
servicegrad = 0.97
z = norm.ppf(servicegrad) # Sicherheitsfaktor für 97 Prozent
wiederbeschaffung_wochen = 8
neuer_sicherheitsbestand = z * prognose_fehler * np.sqrt(wiederbeschaffung_wochen)
# Nur senken, wenn der neue Wert die Lieferfähigkeit hält
if neuer_sicherheitsbestand < aktueller_eisbe:
print(f"Freisetzbar: {aktueller_eisbe - neuer_sicherheitsbestand:.0f} Stück")Genau hier liegt der Unterschied zur Reichweitenliste: Ein Schnelldreher mit kleinem Prognosefehler bekommt einen niedrigen Sicherheitsbestand, ein Langsamdreher mit hoher Streuung und langer Wiederbeschaffungszeit bekommt mehr Puffer, nicht weniger. Das Ergebnis ist meistens beides gleichzeitig: weniger gebundenes Kapital gesamt und weniger Fehlteile bei den kritischen Materialien. Wer nur die Summe senken will, verschlechtert die Lieferfähigkeit. Wer differenziert, verbessert sie oft sogar.
Zurückgeschrieben wird dann kontrolliert in Wellen. WIAG pflegt die neuen Parameter per Massenpflege im SAP, Welle für Welle, mit Monitoring der Fehlteil- und Bestandsentwicklung nach jeder Welle. Dreht ein Wert in die falsche Richtung, wird er zurückgenommen, bevor die nächste Welle läuft.
IBP-Vollprojekt oder erst die Parameter aufräumen?
Die kurze Antwort: erst aufräumen. SAP hat mit Integrated Business Planning (IBP) ein eigenes, starkes Werkzeug, inklusive der KI-Analyse „Joule“ in den Releases 2025 und 2026. Für den gehobenen Mittelstand lohnt ein IBP-Vollprojekt aber selten, bevor die Dispo-Stammdaten überhaupt bereinigt sind.
Der Grund ist simpel: IBP ist ein eigenes Lizenz- und Einführungsprojekt, oft sechs- bis siebenstellig und über Monate. Wenn Sie verschmutzte Sicherheitsbestände und nie geprüfte Dispomerkmale in ein IBP übernehmen, planen Sie den Müll nur schneller. Unser Weg braucht kein IBP: Er läuft auf einer offenen Datenplattform auf den Roh-Verbrauchsdaten und schreibt das Ergebnis in Ihr bestehendes ECC oder S/4HANA zurück.
Das Timing ist 2026 besonders günstig, und zwar aus einem harten Grund: Die Mainstream-Wartung für SAP ECC endet am 31.12.2027. Viele Mittelständler migrieren 2026 und 2027 auf S/4HANA. Genau das ist der Moment, die Dispo-Stammdaten zu bereinigen, statt die alten Fehler mitzunehmen. Wer den Bestands-Check vor die Migration zieht, wandert mit sauberen Parametern und weniger gebundenem Kapital ins neue System. Wer ihn danach macht, hat den Müll erst teuer mitmigriert. Dieselbe Logik gilt für die KI in der Wertschöpfungskette: Datenqualität an der Quelle entscheidet über jeden späteren KI-Use-Case.
Was der 6-Wochen-Check kostet und liefert
Der Bestands-Check läuft als 6-Wochen-Projekt zum Festpreis, nicht auf Tagessatz-Basis. Das ist 2026 relevant, denn die SAP-Tagessätze steigen laut Branchenerhebungen für 2026 und 2027 um bis zu 50 Prozent gegenüber 2024, getrieben vom Fachkräftemangel. Ein Festpreis-Scope schützt Sie vor genau dieser Kostendynamik.
Woche 1 und 2: read-only-Extraktion aus ECC oder S/4HANA und Datenaufbau. Woche 3 und 4: ML-Bedarfsprognose je Material und Simulation der Dispo-Parameter, inklusive der freisetzbaren Kapitalsumme je Warengruppe. Woche 5 und 6: erste kontrollierte Massenpflege-Welle im SAP durch WIAG plus Monitoring-Setup für die Folgewellen. Am Ende steht eine belastbare Zahl, wie viel Cash konkret in Ihrem Lager gebunden ist und was ohne Lieferrisiko heraushebbar ist.
Rechnen Sie das gegen: Bei 30 Mio EUR Bestand und 15 Prozent freisetzbarem Anteil sind das 4,5 Mio EUR einmalig freigesetztes Working Capital, plus die laufend gesparten Lagerkosten. Gegen einen Festpreis im niedrigen fünfstelligen bis mittleren fünfstelligen Bereich ist der Business Case in fast jedem Fall in den ersten Wochen positiv. Das ist der Grund, warum wir den Check als Einstieg in ein größeres Datenplattform-Projekt anbieten: Er zahlt sich selbst zurück, bevor die Plattform steht.
Häufig gestellte Fragen
Was kostet eine SAP Bestandsoptimierung mit ML-Bedarfsprognose?
Der 6-Wochen-Check läuft zum Festpreis, meist im niedrigen bis mittleren fünfstelligen Bereich, nicht auf Tagessatz. Bei 30 Mio EUR Bestand und 10 bis 30 Prozent freisetzbarem Überbestand steht dem ein einmaliger Cash-Effekt von 3 bis 9 Mio EUR gegenüber. Der Business Case ist damit meist in den ersten Wochen positiv.
Was ist der Unterschied zu SAP IBP mit Joule?
IBP ist ein eigenes Lizenz- und Einführungsprojekt für integrierte Planung, die KI „Joule“ kam in den Releases 2025 und 2026 dazu. Unser Weg braucht kein IBP: Er rechnet auf einer offenen Datenplattform auf den Roh-Verbrauchsdaten und schreibt das Ergebnis in Ihr bestehendes SAP zurück. Für den Mittelstand ist das der schnellere und günstigere Einstieg, gerade vor einer S/4HANA-Migration.
Riskiere ich mit gesenkten Sicherheitsbeständen Fehlteile?
Nein, wenn differenziert vorgegangen wird. Wir senken nichts pauschal, sondern leiten den Sicherheitsbestand je Material aus Prognosefehler, Servicegrad und Wiederbeschaffungszeit ab. Kritische Langsamdreher bekommen oft mehr Puffer, nicht weniger. Zurückgeschrieben wird in Wellen mit Monitoring, sodass jeder Wert vor der nächsten Welle korrigierbar ist.
Brauche ich dafür neue Software oder ein Parallelsystem?
Nein. Die Extraktion ist read-only über ODP und CDS-Views, die Analyse läuft auf einer Datenplattform, und das Ergebnis, die optimierten Dispo-Parameter, wird per Massenpflege ins bestehende SAP zurückgeschrieben. Es entsteht keine neue Lizenz und kein System, das Sie danach betreiben müssen. Das Ergebnis lebt im SAP.
Funktioniert das auch auf SAP ECC oder nur auf S/4HANA?
Beides. Wir extrahieren aus ECC und aus S/4HANA. Weil die ECC-Mainstream-Wartung am 31.12.2027 endet, ist der Check gerade vor einer geplanten Migration besonders sinnvoll: Sie bereinigen die Dispo-Stammdaten, bevor Sie sie ins neue System übernehmen, statt den Datenmüll teuer mitzumigrieren.
Nächster Schritt
Der ehrlichste erste Schritt ist ein kurzer Blick auf Ihre Dispo-Stammdaten, bevor irgendjemand ein Angebot schreibt.
Verwandte Themen
Externe Referenz zum Forecast-Verfahren: scikit-learn HistGradientBoostingRegressor.
