Supply Chain Optimierungssoftware, Februar 2025

Von Léon Levinas-Ménard

Zuletzt geändert: 2. Februar 2025

Anbieter-Ranking & Zusammenfassung (Basierend auf technischer Strenge)

Lokad – Top technische Glaubwürdigkeit. Lokad zeichnet sich durch seine Transparenz und technische Tiefe aus. Es war Pionier bei der probabilistischen Prognose und bewies seine Methoden im offenen Wettbewerb (auf SKU-Ebene auf #1 platziert und insgesamt auf Platz #6 von 909 Teams im M5-Prognosegenauigkeitswettbewerb ¹ – das einzige von Anbietern geführte Team unter den Top-Platzierungen). Lokad veröffentlicht detaillierte Einblicke in seine Architektur (z.B. eine domänenspezifische Sprache namens Envision, cloud-basierte Automatisierung) und legt mehr Wert auf finanziell optimierte Entscheidungen als auf vereinfachte Kennzahlen. Sein Fokus auf rigorose Mathematik (Quantilprognosen, stochastische Optimierung) und vollständig skriptbare, automatisierte Workflows (über APIs und Codierung) zeugt von einem ingenieurtechnischen Ansatz. Es werden keine großen AI/ML-Versprechen ohne Nachweise gemacht – stattdessen stellt Lokad technische Whitepapers und sogar Open-Source-Tools zur Verfügung, um Daten über die Grenzen des Arbeitsspeichers hinaus zu skalieren ² ³. Diese Offenheit und nachgewiesene Leistung katapultieren Lokad an die Spitze.
Anaplan – „Excel 2.0“ Plattform. Anaplan ist im Wesentlichen die unternehmensspezifische SaaS-Version einer Tabellenkalkulation, angetrieben von seiner proprietären Hyperblock In-Memory-Engine ⁴. Technisch gesehen ist Hyperblock eine robuste, multidimensionale Berechnungs-Engine, die es Tausenden von Anwendern ermöglicht, in Echtzeit an Planungsmodellen zusammenzuarbeiten – vergleichbar mit einer aufgeladenen, cloud-basierten Excel. Obwohl Anaplan per se kein spezialisierter Optimierer für supply chain ist (Prognosen und algorithmische Optimierung sind auf dieser Plattform „zweitrangige Bürger“ ⁵), liegt seine Stärke in seiner soliden Architektur für Modellierung und Szenarioplanung. Es wirbt nicht mit mystischer KI; stattdessen bietet es eine zuverlässige, leistungsstarke Testumgebung zur Erstellung maßgeschneiderter Planungslogik. Kurz gesagt, es ist ein leistungsstarkes, allgemeines Planungstool mit einem ehrlichen Ansatz – keine übertriebenen Behauptungen über prognostischen Zauber, sondern ein gut entwickeltes, skalierbares System im Stil einer Tabellenkalkulation. Dieses umfassende technische Angebot bringt Anaplan hohe Glaubwürdigkeitswerte ein.
Kinaxis (RapidResponse) – In-Memory Simulations-Engine. Kinaxis ist bekannt für seine einzigartige Concurrency-Engine, die es ermöglicht, Versorgungspläne unternehmensweit in Echtzeit neu zu berechnen. Technisch gesehen hat Kinaxis seine eigene Datenbank-Engine von Grund auf neu entwickelt, um dies zu unterstützen ⁶ ⁷. Das Ergebnis ist eine Plattform, die für schnelle „Was-wäre-wenn“-Simulationen optimiert ist: Anwender können Szenarien abzweigen (wie Git für Daten) und sofortiges Feedback zu den Auswirkungen von Änderungen erhalten ⁸. Das System hält alle supply chain Daten im Arbeitsspeicher für maximale Geschwindigkeit, wobei Algorithmen direkten Speicherzugriff auf die Daten haben, um den Durchsatz zu maximieren ⁹. Dieses Design ermöglicht echtes gleichzeitiges Planen (z.B. werden Vertriebs-, Produktions- und Bestandspläne in Echtzeit gemeinsam aktualisiert). Aus ingenieurtechnischer Sicht ist der Bau eines maßgeschneiderten, im Arbeitsspeicher operierenden, versionskontrollierten Datenspeichers eine beeindruckende Leistung, die Agilität bietet. Der Kompromiss dabei ist jedoch hoher Hardwarebedarf – ein vollständig im Arbeitsspeicher arbeitender Ansatz bedeutet, dass die Skalierung auf enorme Datenmengen kostspielig werden kann (da die RAM-Anforderungen steigen) ¹⁰. Insgesamt zeigt Kinaxis starke technische Strenge in Architektur und Leistung, während es modische KI-Versprechen vermeidet. Es glänzt in der Supply-Planung und S&OP-Simulationen, obwohl es im Vergleich zu einigen Mitbewerbern weniger vorgefertigte ML-Prognosefunktionen bietet.
SAS – Statistisches Kraftpaket. SAS ist ein erfahrener Anbieter von Analysesoftware (gegründet 1976) und bringt eine formidable statistische Modellierungs-Engine für supply chain Probleme mit. Sein Hauptprodukt umfasst eine domänenspezifische Sprache für Statistik (die SAS-Sprache) aus den 1970er Jahren ¹¹ – man könnte sagen, die ursprüngliche Data-Science-Plattform. Die Stärke von SAS liegt in der Tiefe seiner Algorithmen: eine umfangreiche Bibliothek von Zeitreihen-Prognosemodellen, Optimierungsroutinen und Machine-Learning-Techniken, die über Jahrzehnte hinweg entwickelt wurden. Es beschäftigt einige der talentiertesten Ingenieure und Statistiker der Branche ¹¹ und war lange vor dem Buzzword „KI“ ein Vorreiter in der fortgeschrittenen Prognose. Im Kontext der supply chain wird SAS häufig für Bedarfsprognosen und Bestandsanalysen eingesetzt. Technisch gesehen ist es robust und bewährt – aber auch schwergewichtig. Die Werkzeuge können archaisch wirken (die Welt ist weitgehend zu Open-Source-Sprachen wie Python/R übergegangen, und in der Tat sind Jupyter-Notebooks inzwischen eine überlegene offene Alternative ¹²). SAS behauptet nicht lautstark, über magische KI zu verfügen; es verlässt sich auf seinen Ruf und solide Technik. Für Organisationen, die über das Fachwissen zur Nutzung verfügen, bietet SAS ernsthafte analytische Schlagkraft, die auf echten Algorithmen (ARIMA, ETS, etc.) statt auf Hype basiert. Das Hauptproblem ist, dass es sich um eine allgemeine Analytik-Plattform handelt – im Inneren äußerst leistungsstark, aber es erfordert versierte Nutzer, um es auf supply chain anzuwenden, und es wurde in jüngsten Prognosewettbewerben nicht speziell bewertet (Open-Source-Tools treten oft in Konkurrenz ¹³).
Dassault Systèmes (Quintiq) – Optimierungsspezialist. Quintiq (2014 von Dassault Systèmes übernommen) ist eine Plattform, die sich gezielt auf die komplexe supply chain Optimierung und Terminplanung konzentriert. Es verfügt über eine proprietäre domänenspezifische Sprache namens Quill zur Modellierung von Geschäftsbedingungen ¹⁴. Diese DSL ermöglicht es Ingenieuren, maßgeschneiderte Lösungen zu programmieren (zum Beispiel individuelle Produktionspläne oder Routenpläne) und mathematische Solver zu nutzen. Die bloße Existenz einer DSL im Produkt ist ein Beweis für ernsthafte Deep-Tech-Expertise – die Entwicklung einer Programmiersprache für Planungsprobleme ist nicht trivial ¹⁵. Quintiq glänzt in Szenarien wie Fabrikplanung, Optimierung von Logistiknetzwerken und anderen NP-schweren Problemen, bei denen ein maßgeschneidertes Optimierungsmodell erforderlich ist. Technisch gesehen ist es eine der flexibelsten und leistungsstärksten Optimierungs-Engines in der supply chain Software. Allerdings geht Quintiqs Fokus auf Optimierung zulasten anderer Bereiche: Zum Beispiel verfügt es über relativ begrenzte native Prognosefähigkeiten ¹⁶. Ein weiteres Problem ist, dass öffentliche technische Updates zu Quill rar sind, was darauf hindeutet, dass die Technologie altert oder zumindest nicht schnell voranschreitet ¹⁷. Anwender verlassen sich oft auf die Berater von Dassault, um Lösungen zu konfigurieren, und ohne klare öffentliche Dokumentation ist es schwer, aktuelle Innovationen einzuschätzen. Zusammenfassend ist Quintiq eine erstklassige Wahl für komplexe Optimierungsbedürfnisse und demonstriert starke Ingenieurskunst durch seine DSL – jedoch ist es in Bereichen wie KI/Prognosen nicht so transparent oder auf dem neuesten Stand, und seine Stärken liegen in dem, was die Implementierenden damit entwickeln, anstatt in eingebauter „Intelligenz“.
ToolsGroup (SO99+) – Probabilistischer Pionier mit Vorbehalten. Die Software von ToolsGroup (SO99+) ist seit langem auf Nachfrageprognosen und Bestandsoptimierung spezialisiert, mit einem Schwerpunkt auf probabilistischen Modellen. Sie bietet umfangreiche supply chain Funktionalitäten (Nachfrageplanung, Auffüllung, mehrstufige Bestandsoptimierung) und war einer der ersten Anbieter, der „Powerfully Simple“ probabilistische Prognosen anpries. Auf dem Papier klingt das fortschrittlich – ToolsGroup behauptet, die Nachfrageschwankungen zu modellieren und Prognosen „selbst zu optimieren“, was genauere Bestandsziele ermöglichen sollte. Ein genauer technischer Blick wirft jedoch Bedenken auf. Die öffentlichen Materialien von ToolsGroup deuten immer noch darauf hin, dass Prognosemodelle aus der Zeit vor 2000 im Hintergrund verwendet werden ¹⁸ – sie haben im Marketing einen „KI“-Anstrich hinzugefügt, jedoch ohne konkrete Details. Bemerkenswerterweise werben sie seit 2018 mit probabilistischen Prognosen und rühmen gleichzeitig Verbesserungen beim MAPE ¹⁹. Dies ist ein offensichtlicher Widerspruch: Wenn Prognosen tatsächlich probabilistische Verteilungen sind, dann gelten Kennzahlen wie MAPE (die die Genauigkeit eines Einzelwertes messen) nicht mehr direkt ¹⁹. Solche Inkonsistenzen deuten darauf hin, dass der „probabilistische“ Teil oberflächlich sein könnte oder dass sie sich trotz neuer Methoden an alten Kennzahlen orientieren. Zudem hat ToolsGroup Schlagwörter wie „demand sensing AI“ verwendet, aber diese Behauptungen werden durch wissenschaftliche Literatur oder bekannte Benchmarks nicht gestützt ²⁰. In der Praxis funktionieren viele ToolsGroup-Einsätze immer noch als automatisierte, regelbasierte Systeme mit Ausnahmealarmen. Fazit: ToolsGroup bietet umfassende Funktionalität und war Vorreiter in der Förderung von Unsicherheitsmodellierung, aber die mangelnde Transparenz bezüglich der Algorithmen und die Kluft zwischen Marketing und Realität im Bereich KI/ML machen seine technische Glaubwürdigkeit nur mäßig. Es ist ein solides, bereichsorientiertes Werkzeugset, das jedoch nach heutiger Maßstäben nicht eindeutig auf dem neuesten Stand der Technik ist.
Slimstock (Slim4) – Geradlinig und solide. Slimstock ist ein erfrischender Außenseiter, der keinen Trends hinterherjagt. Die Slim4-Software konzentriert sich auf konventionelle supply chain Techniken – Dinge wie klassische Berechnungen von Sicherheitsbeständen, Bestellpunkten, wirtschaftliche Bestellmenge (EOQ) usw. ²¹. Mit anderen Worten, Slimstock hält sich an bewährte, in Lehrbüchern vermittelte Methoden. Obwohl dies bedeutet, dass es keine ausgefallene KI/ML oder bahnbrechende Algorithmen gibt, ist Slim4 zuverlässig und leicht verständlich. Der Anbieter vermeidet ausdrücklich vage KI-Behauptungen und betont stattdessen praktische Funktionen, die den alltäglichen Anforderungen der supply chain entsprechen ²². Diese Ehrlichkeit ist ein technischer Vorteil: Die Nutzer wissen genau, was sie bekommen, und das Verhalten des Systems ist vorhersehbar. Natürlich kann Einfachheit auch eine Einschränkung sein – von Slim4 erhält man keine probabilistischen Nachfrageprognosen oder fortgeschrittene Optimierer. Es ist nicht für hochkomplexe Netzwerke oder massive Datenmengen konzipiert (und tatsächlich basiert seine technische Architektur vermutlich auf einer Standard-Datenbank mit In-Memory-Caching, die für mittelgroße Probleme geeignet ist). Aber für viele Unternehmen gilt: Einfacher ist besser, wenn das Tool konsequent funktioniert. Slimstock sammelt Glaubwürdigkeitspunkte dafür, dass es das Buzzword-Bingo vermeidet; sein „prägnanter“ Ansatz wird von Fachkollegen als Gegensatz zu den KI-Posen anderer gelobt ²³. Zusammenfassend treibt Slim4 technologisch nicht die Grenzen voran, ist aber eine solide Wahl für grundlegende Prognosen und Bestandsmanagement mit minimalem Hype und einer klaren, risikoarmen Architektur.
o9 Solutions – High-Tech Hype-Maschine. o9 präsentiert sich als „Digital Brain“ für die enterprise supply chain, das Nachfrageprognosen, Supply Planning, S&OP und sogar Revenue Management auf einer Plattform vereint. Technisch gesehen hat o9 viele moderne Technologiekonzepte in sein Produkt integriert: ein In-Memory-Datenmodell, eine Graphdatenbank namens „Enterprise Knowledge Graph (EKG)“ und verschiedene KI/ML-Komponenten. Die bloße „Tech-Masse“ von o9 sprengt alle Grenzen ²⁴ – nach den Standards von Unternehmenssoftware ist es eine sehr ambitionierte Architektur, die versucht, alle Daten und Planungsanalysen zu vereinheitlichen. Wendet man jedoch Skepsis an: Ein Großteil davon scheint Technologie um der Technologie willen zu sein, ohne klaren Nutzen. Das In-Memory-Design von o9 garantiert extrem hohe Hardwarekosten im Großmaßstab ²⁵, vergleichbar mit dem kontinuierlichen Betrieb eines gigantischen BI-Cubes. o9 preist sein EKG (Knowledge Graph) als Mittel zur Ermöglichung überlegener Prognosen und KI-gesteuerter Einblicke an, aber es werden keine wissenschaftlichen Belege oder glaubwürdigen Benchmarks geliefert ²⁵. Tatsächlich zerfallen viele der auffälligen Behauptungen von o9 unter genauer Prüfung: Das Unternehmen redet überall von KI, doch Ausschnitte des öffentlich einsehbaren Codes auf GitHub offenbaren eher durchschnittliche Techniken ²⁶. Zum Beispiel hat o9 Funktionen wie maschinelles Lernen bei der Nachfrageprognose und „Digital Twin“-Simulationen beworben, aber keines dieser Merkmale in einem öffentlichen Wettbewerb oder in einer peer-reviewed Fallstudie demonstriert. Ohne Beweise müssen wir seine KI-Behauptungen als Marketing-Hype ansehen. Das heißt, o9 ist nicht ohne Stärken – es ist eine einheitliche Plattform (in-house entwickelt, nicht eine Aneinanderreihung von Akquisitionen) und kann große Datenintegrationen bewältigen. Für ein Unternehmen, das bereit ist, in Hardware zu investieren und sich mit einer steilen Lernkurve auseinanderzusetzen, bietet o9 die Flexibilität, komplexe Planungsmodelle zu erstellen. Aber aus ingenieurtechnischer Sicht ist es eine übermäßig konstruierte Lösung: viel Komplexität, unklarer ROI bei der ausgefallenen Technik und potenzielle Performance-Probleme, falls die Daten über das hinauswachsen, was der Speicher fasst. Solange o9 keine harten Beweise liefert (z.B. Algorithmus-Dokumentation oder Benchmark-Ergebnisse), bleibt seine Glaubwürdigkeit fraglich.
SAP IBP (Integrierte Geschäftsplanung) – Umfassend, aber komplex. SAPs IBP-Suite stellt die Weiterentwicklung von SAPs Altprodukt APO dar, nun als Cloud-Lösung auf der SAP HANA In-Memory-Datenbank angeboten. SAP IBP zielt darauf ab, das gesamte Spektrum abzudecken: Bedarfsprognose, Bestandsoptimierung, Versorgungsplanung, Verkaufs- und Betriebsplanung und mehr – alles eng integriert mit SAPs ERP. Die Stärke von SAP IBP liegt in seiner Vielfalt: Es gibt ein Modul für nahezu jeden Planungsaspekt, oft mit sehr reichhaltigen Funktionen, die aus jahrzehntelanger SAP-Erfahrung hervorgegangen sind. Allerdings entstand diese Vielfalt durch Akquisitionen und Altsysteme. SAP erwarb Spezialisten wie SAF (Bedarfsprognose), SmartOps (Bestandsoptimierung) und andere ²⁷ und schichtete diese auf seine internen Tools (wie APO und HANA). Das Ergebnis im Hintergrund ist ein Flickenteppich unterschiedlicher Engines und Ansätze ²⁷. Folglich ist die technische Architektur von IBP nicht elegant – es handelt sich um eine Sammlung von Komponenten, die nicht von Natur aus “zusammenpassen” und einen hohen Integrationsaufwand erfordern. Selbst SAPs eigene Dokumentation räumt die hohe Komplexität und den Bedarf an erstklassigen Systemintegratoren (und erheblicher Zeit), um alles reibungslos zum Laufen zu bringen ²⁸ ein. Technologisch stützt sich IBP stark auf SAP HANA, eine In-Memory-Spaltendatenbank, um Echtzeit-Performance zu erzielen. HANA ist in der Tat schnell, jedoch auch teuer – die Speicherung großer Planungsdaten rein im RAM ist grundsätzlich kostspielig (RAM ist pro TB etwa 100-mal teurer als Festplattenspeicher) ¹⁰. Das bedeutet, dass das Skalieren von IBP auf sehr große supply chain-Datensätze erhebliche Infrastrukturkosten verursacht, und falls die Daten den Arbeitsspeicher überschreiten, kann die Leistung drastisch einbrechen. SAP hat begonnen, einige Machine-Learning-Funktionen hinzuzufügen (z. B. „Demand Driven MRP“ und IBP for Demand bietet einige ML-Prognoseoptionen), aber diese sind größtenteils optionale Add-ons mit begrenzter Transparenz. Es gibt keinen Beleg dafür, dass SAPs ML den Alternativen überlegen ist; tatsächlich hat in unabhängigen Prognosewettbewerben kein SAP-Algorithmus überzeugend abgeschnitten. Zusammenfassend ist SAP IBP funktionsreich und unternehmensgetestet – es erfüllt alle funktionalen Anforderungen – doch aus technischer Reinheit betrachtet ist es ein Mischmasch: In-Memory-Geschwindigkeit gepaart mit Altsystemlogik, viel Komplexität durch zusammengeführte Produkte und keine klare technische Innovation in der Prognose oder Optimierung über das hinaus, was die akquirierten Komponenten bereits leisteten. Unternehmen entscheiden sich oft dafür wegen der Integration mit SAP ERP und nicht primär aufgrund herausragender Optimierungsfähigkeiten.
Blue Yonder – Vom Branchenführer zum Flickenteppich. Blue Yonder (ehemals JDA Software) bietet eine umfassende Suite, die Prognose, Versorgungsplanung, Merchandising und Ausführung umfasst. Es ist das Ergebnis von vielen Jahren M&A, einschließlich JDAs Übernahme von i2 Technologies (supply chain-Planung), Manugistics und dem KI-Startup Blue Yonder (dessen Namen es übernommen hat) unter anderem ²⁹. Leider ist Unternehmenssoftware nicht einfach die Summe ihrer Teile: Unter der einheitlichen Marke Blue Yonder verbirgt sich ein Durcheinander von Produkten (von denen viele recht veraltet sind), die lose zusammengefügt wurden ²⁹.

(Hinweis: Weitere Anbieter wie Infor (mit legacy GT Nexus- und Mercia-Komponenten), GAINS Systems (ein weiterer Spezialist in der Bestandsoptimierung), John Galt Solutions (Nachfrageplanung für den Mittelstand), Relex Solutions (Einzelhandelsprognosen mit einer In-Memory-Engine) etc. existieren ebenfalls. Zur besseren Fokussierung haben wir die prominentesten oder lehrreichsten Beispiele oben aufgeführt. Dieselben skeptischen Kriterien gelten auch für diejenigen, die nicht einzeln bewertet wurden: So verwendet beispielsweise Relex ein In-Memory-, OLAP-Würfel-Design – hervorragend in Bezug auf Geschwindigkeit, garantiert jedoch hohe Hardwarekosten für große Einzelhändler ³⁰; Infor ist durch Übernahmen gewachsen, was zu Integrationsproblemen ähnlich wie bei SAP/Blue Yonder führt; GAINS und John Galt bieten solide Basisfunktionen, jedoch wenig öffentlich dokumentierte Neuerungen. Jeder Anbieter, der technische Details oder Belege nicht offen teilt, würde in der Methodik dieser Studie ohnehin niedrig bewertet.)*

Detaillierte Technische Analyse

In diesem Abschnitt gehen wir detaillierter auf spezifische technische Aspekte der führenden supply chain-Optimierungssoftware ein, mit Fokus auf vier Schlüsselaspekte: Prognose & KI, Automatisierungsfähigkeiten, Systemarchitektur und Integration der Module. Alle Analysen beruhen auf veröffentlichter technischer Information oder konkreten Belegen und vermeiden ausdrücklich jegliche Marketing-Sprache.

Prognose- & KI-Fähigkeiten

Die moderne supply chain-Planung hängt entscheidend von der Genauigkeit der Nachfrageprognosen ab, doch Behauptungen über überlegene Prognosefähigkeiten sind weit verbreitet und oft unbegründet. Unsere Untersuchung ergab, dass die Prognosefähigkeiten der meisten Anbieter nicht signifikant über den Standardmethoden der Statistik liegen – trotz Schlagwörtern wie „KI“ oder „machine learning“ in ihrem Marketing.

Bewiesene Leistung vs. Hype: Unter allen Anbietern ist Lokad der einzige, der eine überprüfbare weltklasse Prognosebilanz vorweisen kann, dank des offenen M5-Wettbewerbs. Lokad demonstrierte seine Fähigkeit zur probabilistischen Prognose, indem es bei der SKU-basierten Genauigkeit an der Spitze rangierte ¹. Dies verleiht Lokads Behauptungen einer besseren Prognosegenauigkeit Glaubwürdigkeit. Im krassen Gegensatz dazu hat kein anderer Anbieter vergleichbare Ergebnisse in einem unabhängigen Benchmark veröffentlicht. Beispielsweise werben einige Anbieter mit proprietären Algorithmen (einer nennt seine Methode „Procast“) und behaupten überlegene Genauigkeit, doch diese Methoden waren nicht unter den Top-Platzierungen des M5-Wettbewerbs zu finden ³¹. In der Praxis sind akademische Open-Source-Ansätze (wie die R-Prognosepakete von Prof. Rob Hyndman) vermutlich ebenso gut oder besser als die meisten geschlossenen proprietären Engines ¹³. Daher sollte jede Anbieter-Aussage von „branchenbester Prognosegenauigkeit“ ohne öffentlichen Nachweis als unbelegt angesehen werden.
KI- und Machine Learning-Versprechen: Wir haben den KI/ML-Hype mit äußerster Skepsis betrachtet. Anbieter wie o9 Solutions und Blue Yonder verwenden in ihren Broschüren häufig Begriffe wie „KI/ML-gesteuerte Prognose“. Doch bei der Suche nach Substanz fanden wir wenig. Im Fall von o9 sind ihre Behauptungen, dass der graphbasierte „Enterprise Knowledge Graph“ zu besseren Prognosen führt, zweifelhaft und ohne wissenschaftliche Grundlage ²⁵. Blue Yonder rühmt sich ebenfalls mit KI, liefert jedoch keine Details – der einzige Einblick in ihre Technik stammt aus einigen Open-Source-Repositories, die den Einsatz recht gewöhnlicher Zeitreihen-Techniken (ARMA, lineare Regression, Feature Engineering) zeigen ³². Es gibt keinen Hinweis auf Deep Learning, fortschrittliche probabilistische Methoden oder andere moderne KI, die ihre Marketingaussagen rechtfertigen würden. ToolsGroup hat Machine-Learning-Konzepte integriert (sie sprechen von „demand sensing“ mithilfe von machine learning), jedoch gibt es auch hier keine peer-reviewed Studien oder Wettbewerbserfolge, die dies validieren ²⁰. Tatsächlich legt die Kombination von „probabilistischer Prognose“ mit alten Metriken wie MAPE nahe, dass ihre KI mehr Hype als Durchbruch ist ¹⁹. Fazit: Abgesehen von Lokad (und in gewissem Maße SAS, das bewährte statistische Modelle einsetzt) basiert die Prognose in den meisten supply chain-Softwarelösungen weiterhin auf bekannten Methoden (exponentielle Glättung, Regression, vielleicht etwas tree-basiertes ML) und nicht auf einem proprietären genialen KI-Ansatz. Anbieter, die wirklich neuartige Algorithmen besitzen, würden diese öffentlich demonstrieren. Das Fehlen unabhängiger Validierung spricht für sich.
Probabilistische vs. Deterministische Ansätze: Ein wesentlicher technischer Unterschied besteht darin, ob ein Anbieter probabilistische Prognosen (also die Vorhersage einer vollständigen Verteilung der Nachfrageergebnisse) unterstützt oder sich auf Einzelpunktprognosen beschränkt. Lokad ist seit 2012 ein lautstarker Befürworter vollständiger Wahrscheinlichkeitsverteilungen und optimiert tatsächlich Entscheidungen (wie Bestandsniveaus) direkt basierend auf den probabilistischen Prognosen. Auch ToolsGroup behauptet, probabilistische Prognosen zu erstellen (vermutlich mittels Monte-Carlo-Simulationen der Nachfrage). Allerdings stellten wir fest, dass viele, die „probabilistisch“ behaupten, intern dennoch auf deterministische Metriken und Prozesse zurückgreifen. So ist beispielsweise das Marketing von ToolsGroup, das eine Reduzierung des MAPE durch den Einsatz probabilistischer Modelle verspricht, inkohärent, da MAPE nicht einmal auf das Ergebnis einer probabilistischen Prognose angewandt werden kann ¹⁹. Dies legt nahe, dass ihr Prozess letztlich wieder zu einer Einzelpunktprognose (Mittelwert oder Median) für die Bewertung zusammenbricht, wodurch der probabilistische Vorteil untergraben wird. Andere Anbieter wie SAP, Oracle, Blue Yonder haben begonnen, probabilistische Begriffe zu erwähnen (SAP IBP verfügt nun über „statistische Ensembles“ und Konfidenzintervalle), doch auch hier zeigen die Benutzeroberflächen und Berichte oft standardmäßig Einzelpunktprognosen mit traditionellen Fehlerkennzahlen. Wahre probabilistische Prognosen zu nutzen, erfordert ein Umdenken der KPIs (etwa durch den Einsatz von Pinball Loss, CRPS oder Service-Level-Erreichung anstelle von MAPE). Wir fanden keine Hinweise darauf, dass ein großer Anbieter außer Lokad in der Praxis so weit gegangen ist. Zusammenfassend ist die probabilistische Prognose ein Bereich, in dem das Marketing bei den meisten Anbietern ihrer Realität voraus ist – sie generieren vielleicht einige Verteilungen hinter den Kulissen, aber Planer betrachten weiterhin Einzelpunktprognosen und klassische KPIs, was auf eine beschränkte Übernahme des Paradigmas hinweist.
Prognosemetriken und -bewertung: Ein wichtiger Aspekt technischer Strenge ist, wie ein Anbieter die Qualität von Prognosen bewertet. Ein Warnsignal ist die fortwährende Abhängigkeit von Metriken wie MAPE, WAPE oder Bias als alleinige Erfolgsmaße, besonders wenn der Anbieter behauptet, KI oder probabilistische Methoden einzusetzen. Dies liegt daran, dass diese Metriken zu konservativen, durchschnittlichen Prognosen verleiten und manipulierbar sind (zum Beispiel durch das Abschneiden von Ausreißern). Wir stellten fest, dass Anbieter mit wirklich fortschrittlichen Prognosefähigkeiten eher über Servicelevels oder Geschäftsergebnisse (z. B. Ausfallwahrscheinlichkeit, Kostenfolgen) sprechen statt nur über MAPE. Lokad etwa betont die Reduktion von „Dollar des Fehlers“ und die Abstimmung der Prognosen mit der Entscheidungsoptimierung ³³. Im Gegensatz dazu heben ToolsGroup, Blue Yonder und viele andere in ihren Fallstudien weiterhin prozentuale Fehler hervor, was auf ein veraltetes Denken hindeutet. Wenn in einer Anbieter-Dokumentation oder Demo stark auf MAPE/WAPE-Dashboards gesetzt wird, ist dies ein Hinweis darauf, dass deren Prognoseansatz vermutlich traditionell ist. Tatsächlich wurde die Inkonsistenz von ToolsGroup in Bezug auf den MAPE bereits bemängelt ¹⁹. Kurzum: Eine wirklich hochmoderne Prognose in der supply chain würde sich durch probabilistische Metriken und eine Validierung in der Praxis auszeichnen – Attribute, die außerhalb von ein oder zwei Anbietern meist fehlen.

Automatisierungs- & Workflow-Fähigkeiten

Die Erreichung von supply chain-Optimierung beruht nicht nur auf Algorithmen; es hängt auch davon ab, wie automatisiert und „hands-free“ die Software den Planungsprozess durchführen kann. Wir haben die Aussagen und Dokumentationen jedes Anbieters dahingehend untersucht, ob Belege für Automatisierung, API-Integration und autonome Entscheidungsfindung vorliegen.

Lokad: Automatisierung ist eines der Markenzeichen von Lokad. Die gesamte Lösung basiert auf einer domänenspezifischen Sprache (Envision), die es supply chain-Planern ermöglicht, ihre Logik und ihre Entscheidungen in Skripten zu kodieren, die dann automatisch nach Zeitplan ausgeführt werden. Lokad dokumentiert dabei klar seine Datenpipelines und seinen Workflow-Manager, der Daten aktualisiert und Entscheidungen (Prognosen, Nachschubaufträge usw.) ohne manuellen Eingriff neu berechnet ³⁴ ³⁵. Sie berichten sogar von „hochautomatisierten Setups“ für ca. 100 supply chain in der Produktion ³⁵, was bedeutet, dass die Software Daten zieht, Prognosen erstellt und Entscheidungen (wie Bestellvorschläge) automatisch umsetzt. Zusätzlich stellt Lokad APIs für den Datenupload und -download bereit und hat ein „AI Pilot“-Konzept zur Automatisierung administrativer Aufgaben ³⁶. All dies weist auf ein sehr hohes Maß an tatsächlicher Automatisierung hin – die Rolle des Nutzers besteht größtenteils darin, den Code bzw. die Parameter zu überwachen und zu verfeinern, statt für jeden Plan manuell Knöpfe zu drücken. Lokads Ansatz zur Automatisierung ist glaubwürdig und technisch detailliert (sie haben sogar Vorträge darüber gehalten, wie man von manuellen zu automatisierten Entscheidungen übergeht ³⁷ ³⁸).
Kinaxis: Kinaxis RapidResponse ist für schnelle Szenarioanalysen und Zusammenarbeit konzipiert, anstatt vollautomatisierte Planung bereitzustellen. Das Konzept des „gleichzeitigen Planens“ bedeutet, dass alle am selben Datensatz mit Echtzeit-Updates arbeiten – was jedoch typischerweise menschliche Planer einbezieht, um Szenarien zu bewerten und Entscheidungen zu treffen. Nichtsdestotrotz unterstützt Kinaxis Automatisierung in gewisser Weise: Es kann Daten aus ERP-Systemen nahezu in Echtzeit übernehmen, seine supply/demand-Abstimmungsalgorithmen kontinuierlich ausführen und Benachrichtigungen oder Ausnahme-Meldungen an Nutzer auslösen, wenn etwas aus dem Rahmen fällt. Es stellt Funktionalitäten über APIs bereit und bietet Scripting (in Form von konfigurierbaren Algorithmen und Makros in seiner Umgebung) für Power-User. Allerdings positioniert sich Kinaxis im Allgemeinen als Entscheidungshilfe und nicht als eine Black-Box, die automatisch Aufträge freigibt. Der Anbieter behauptet nicht lautstark „autonome supply chain“; stattdessen konzentriert er sich darauf, die Effizienz der Planer zu steigern. Dies ist eine ehrliche Haltung. Es bedeutet, dass RapidResponse standardmäßig immer noch menschliche Eingriffe erwartet – was eine Einschränkung darstellen kann, wenn man ein „selbstfahrendes“ supply chain System anstrebt. Technisch kann Kinaxis tief integriert werden (zum Beispiel wird es häufig mit SAP ERP verbunden, um genehmigte Pläne auszuführen), aber ein unbeaufsichtigter End-to-End-Betrieb würde viel kundenspezifische Konfiguration erfordern. Wir fanden keine Hinweise darauf, dass Kinaxis KI-gesteuerte Entscheidungsempfehlungen bietet (ihre Stärke liegt eher in der schnellen Berechnung benutzerdefinierter Szenarien).
o9 Solutions: o9 vermarktet stark Konzepte wie einen „digitalen Zwilling“ der Organisation und KI, die Empfehlungen aussprechen kann. Sie sprechen von „Automatisierung“ im Kontext ihrer digitalen Assistenten – vermutlich Bots, die Einblicke liefern oder einige Aufgaben übernehmen können. Allerdings ist es, mangels konkreter technischer Dokumentation, schwer nachzuvollziehen, wie viel davon tatsächlich real ist. Wir konnten keine Details finden, wie etwa „o9 kann automatisch Auffüllaufträge via API basierend auf seinen Plänen freigeben“ oder „o9 verwendet Reinforcement Learning, um Parameter eigenständig anzupassen.“ Die Unklarheit in o9s Automatisierungsgeschichte ist bedenklich: Viel hochtrabendes Gerede, aber wenig Detail. Angesichts seiner In-Memory EKG-Basis vermuten wir, dass o9 in der Lage ist, Daten in Echtzeit zu aktualisieren und Neuberechnungen durchzuführen, verlässt sich dabei aber vermutlich weiterhin auf Nutzer, um zu konfigurieren, was mit diesen Informationen geschehen soll. Ohne glaubwürdige Referenzen behandeln wir o9s „Autonomie“-Ansprüche als unbestätigt. Es ist möglich, o9 via API in Ausführungssysteme zu integrieren (es handelt sich um moderne Software, sodass API-Integration vorhanden sein sollte), aber inwieweit die Entscheidungsfindung tatsächlich von KI automatisiert wird, bleibt unklar. Die Belege deuten darauf hin, dass o9s aktuelle Automatisierung eher darauf abzielt, Analysen zu beschleunigen (z. B. sofortige Was-wäre-wenn-Szenarien) als Entscheidungsergebnisse zu automatisieren.
Blue Yonder: In den letzten Jahren hat Blue Yonder (insbesondere seit der Übernahme durch Panasonic) verstärkt den Begriff „autonome supply chain“ propagiert, was ein System impliziert, das mit minimalem menschlichen Eingriff arbeiten kann. Sie verfügen über einige Komponenten, wie beispielsweise Luminate Control Tower, die KI einsetzen, um Störungen zu erkennen und möglicherweise Reaktionen auszulösen. Angesichts des vererbten Kerns von Blue Yonder ist es jedoch wahrscheinlich, dass jede Autonomie durch das Überlagern von RPA (Robotic Process Automation) oder einfachen KI-Agenten auf bestehenden Modulen erreicht wird. Beispielsweise könnte Blue Yonders Bedarfsplanung eine Prognose erzeugen, die dann von einer „KI“-Schicht automatisch auf Basis von Echtzeit-Verkäufen (Demand Sensing) angepasst oder mit einer Warnung versehen wird, wenn sie abweicht. Aber vollautomatisierte Planung (wie das automatische Ausgeben von Aufträgen, das automatische Anpassen von Inventarrichtlinien) ist bei BY-Lösungen vermutlich selten – Kunden lassen in der Regel weiterhin Planer die Maßnahmen prüfen und genehmigen. Das Fehlen detaillierter technischer Unterlagen darüber, wie Blue Yonder Entscheidungen automatisiert, spricht Bände. Wäre ein wirklich autonomer Planer vorhanden, würden Erfolgsgeschichten oder technische Blogs darüber veröffentlicht. Stattdessen konzentrieren sie sich fast ausschließlich auf Marketing-Webinare. Daher folgern wir, dass Blue Yonder zwar ein gewisses Maß an Automatisierung (wie Batch-Jobs, Aktualisierungen von Plänen, vielleicht sogar eine geschlossene Integration in Ausführungssysteme) ermöglicht, aber in diesem Bereich nicht eindeutig führend ist. Es verwendet vermutlich eine ausnahmebasierte Planung, ähnlich wie ältere Systeme – nur mit einer neuen KI-Fassade im Warnsystem.
ToolsGroup: ToolsGroup war historisch stolz auf „Powerfully Simple Automation“. Man behauptete, dass ihr System über längere Zeiträume im Lights-out-Modus arbeiten könne und nur Planer bei Ausnahmen hinzugezogen würden. Tatsächlich bestand die Philosophie von ToolsGroup darin, dem System zu erlauben, täglich automatisch neu zu prognostizieren und neu zu planen, um sich an neue Daten anzupassen. Viele ToolsGroup-Kunden berichteten zu Recht von einer reduzierten Arbeitsbelastung der Planer, da die Software selbstständig Inventarzielsätze anpasst und automatisch Aufträge empfiehlt. ToolsGroup verfügt zudem über ein Integrationstoolkit, um genehmigte Aufträge an ERP-Systeme weiterzuleiten. Aufgrund der zuvor erwähnten Widersprüche hegen wir jedoch Zweifel an der Intelligenz dieser Automatisierung. Es könnte einfach sein, dass jeden Tag dieselbe Formel angewendet und lediglich Ausnahmen markiert werden (Ausnahmemanagement). ToolsGroup bietet eine API und unterstützt geplante Ausführungen, sodass technisch gesehen die Grundlage für Automatisierung vorhanden ist. Die Frage bleibt jedoch die Qualität der automatisierten Entscheidungen. Sie sprechen häufig von „self-tuning“ – was impliziert, dass die Software die Parameter des Prognosemodells eigenständig anpasst, sobald neue Daten eintreffen ³⁹. Falls dem so ist, handelt es sich um eine nützliche Automatisierung (da dadurch die Notwendigkeit ständiger menschlicher Neukonfiguration entfällt). Ohne unabhängige Bewertung sagen wir vorsichtig, dass ToolsGroup hohe Automatisierung bei routinemäßigen Planungsaufgaben bietet, auch wenn die mangelnde Transparenz es schwierig macht zu beurteilen, wie „intelligent“ diese Automatisierung tatsächlich ist (zum Beispiel, ob sie wirklich lernt und sich verbessert oder lediglich vordefinierte Regeln befolgt).
Other Vendors: Die meisten anderen Anbieter unterstützen standardmäßige Automatisierungsfunktionen: Datenintegration via APIs oder Batch-Dateien, geplante Planungsläufe und einige ausnahmebasierte Workflows. Beispielsweise kann SAP IBP so konfiguriert werden, dass es monatlich automatisch einen Prognoseauftrag durchführt und Planungsergebnisse generiert – wobei in der Regel ein Planer die Ergebnisse überprüft. Anaplan steht weniger im Zeichen der Automatisierung – es handelt sich mehr um eine Plattform für manuelles Modellieren, obwohl man seine API nutzen kann, um Daten zu pushen/pullen und eventuell bestimmte Berechnungen zu automatisieren. Dassault/Quintiq kann so skriptiert werden, dass es Optimierungsroutinen zu festgelegten Zeiten ausführt (und Quintiqs DSL erlaubt es, benutzerdefinierte automatische Abläufe zu programmieren), aber auch hier ist es nur so autonom, wie es der Implementierer programmiert. GAINS, Relex, Netstock und weitere Nischenanbieter werben alle mit „end to end automation“ in der Auffüllung – meist im Sinne, dass sie automatisch Einkaufsaufträge oder Lagertransferempfehlungen generieren können. Der wesentliche Unterschied liegt darin, wie viel Überwachung nötig ist: Ein wirklich autonomes Planungssystem würde Menschen nur bei ungewöhnlichen Situationen einbeziehen und seine Entscheidungen mit Begründungen dokumentieren. Wir fanden keinen Anbieter, der dieses Ideal vollständig erreicht. Entweder ist ein Eingreifen von Menschen zur Feinabstimmung und Genehmigung erforderlich (in den meisten Fällen) oder es werden nur die einfachsten Entscheidungen automatisiert, während der Rest manuell erfolgt.

Summary for Automation: Nur wenige Anbieter (insbesondere Lokad) erläutern öffentlich ein Automatisierungsframework, das unbeaufsichtigte, API-gesteuerte Planungsläufe ermöglicht. Andere verfügen zwar technisch über die Mittel zur Automatisierung, verlassen sich aber dennoch auf menschliche Eingriffe, um den Kreislauf zu schließen. Wir stellen zudem fest, dass einige Anbieter in vergangenen Jahrzehnten den Fokus von vollständiger Automatisierung auf „Ausnahmemanagement“ verlagert haben – was im Wesentlichen ein halbautomatischer Ansatz ist, bei dem die Software das tut, was sie kann, und den Rest für Menschen markiert ³⁸. Dieser Ansatz mag praktisch sein, kann jedoch auch als Stütze für Software dienen, der man nicht vollständig vertrauen kann. Unser skeptischer Standpunkt lautet: Wenn ein Anbieter nicht erklären kann, wie er Entscheidungen automatisiert (welche Algorithmen, welche Auslöser, welche API-Aufrufe), dann ist seine „Automatisierung“ höchstwahrscheinlich bloß Marketing-Hype.

System Architecture & Scalability

Die Architektur unter der Haube – insbesondere der Einsatz von In-Memory Computing versus On-Disk und die allgemeinen Designentscheidungen – hat enorme Auswirkungen auf die Skalierbarkeit, die Kosten und die Leistung einer supply chain Software. Wir haben den Kerntechnologie-Stack jedes Anbieters dahingehend untersucht, wie sie mit großen Datenmengen und komplexen Berechnungen umgehen.

In-Memory Computing – Pros and Cons: Mehrere der führenden Anbieter setzen auf eine in-memory Architektur, was bedeutet, dass die Software die meisten oder alle relevanten Daten in den RAM lädt, um während der Berechnungen einen schnellen Zugriff zu ermöglichen. Dazu zählen Kinaxis, Anaplan, o9, SAP HANA (IBP), Relex und möglicherweise Quintiq (zum Lösen von Szenarien). Der Vorteil liegt in der Geschwindigkeit: Der RAM-Zugriff ist um Größenordnungen schneller als der Zugriff auf Festplatten. Beispielsweise legt Kinaxis’ Engine alle Daten in den Speicher, um eine sofortige Neuberechnung von Szenarien und direkte algorithmische Operationen auf dem Datensatz zu ermöglichen ⁹. SAP HANA wurde mit der Prämisse entwickelt, dass Analysen an Live-Daten im Speicher erfolgen sollten, um Echtzeitergebnisse zu liefern ⁴⁰ ⁴¹. Allerdings gibt es ein grundlegendes Problem bei einem rein In-Memory-Ansatz: Kosten und Skalierbarkeit. Speicher (RAM) ist im Vergleich zu Festplatten extrem teuer. 1 TB RAM kann 100× so viel kosten wie 1 TB Festplattenspeicher ¹⁰. Zudem ist die Größe des Speichers in Servern physisch begrenzt (typischerweise verfügen Systeme über 0,5–2 TB RAM, während bei großen supply chain Multi-Terabyte- oder Petabyte-Datensätze üblich sind). In den letzten Jahren traten die erwarteten drastischen Preisrückgänge bei RAM nicht ein – die Preise und Kapazitäten von RAM waren ziemlich stagnierend ⁴². Das bedeutet, dass jedes System, das sämtliche Daten im Speicher halten muss, mit in die Höhe schießenden Infrastrukturkosten konfrontiert wird, sobald die Daten wachsen, oder an eine harte Grenze stößt, an der die Daten schlichtweg nicht mehr passen. Wir bezeichnen eine starke Abhängigkeit von einem In-Memory-Design als einen architektonischen Fehltritt für große supply chain, sofern dem nicht entgegengewirkt wird.
Memory vs. Disk: Modern Practices: Interessanterweise hat die breitere Tech-Welt erkannt, dass reine In-Memory-Lösungen nicht die Zukunft für Big Data sind. Neuere Architekturen verwenden einen gestuften Ansatz – heiße Daten werden im Speicher gehalten, während kalte Daten auf SSDs abgelegt werden, etc. ⁴³ ⁴⁴. Einige supply chain Softwarelösungen haben begonnen, diesen Ansatz zu übernehmen. Beispielsweise verwendet Lokad explizit „spill to disk“ Techniken in seiner Cloud-Infrastruktur. Ihr CTO beschrieb, wie sie einen Einzelhandelsdatensatz mit 10 Milliarden Zeilen mit etwa 37 GB RAM plus einer schnellen NVMe-SSD zur Überlaufbehandlung bewältigen ⁴⁵ ³. Sie erreichen nahezu RAM-Performance, indem sie Dateien abbilden und nur die heißesten Daten im Speicher behalten, während die Software intelligent bei Bedarf swapt ⁴⁶ ⁴⁷. Dieser Ansatz führt zu enormen Kosteneinsparungen – beispielsweise zum Preis von 18 GB High-End-RAM kann man 1 TB NVMe-SSD erwerben ³, was pro Byte 50× günstiger ist, während der rohe Zugriff nur etwa ~6× langsamer erfolgt – ein oft lohnenswerter Kompromiss. Keiner der in-Memory-zentrierten Anbieter (Kinaxis, SAP, o9, etc.) hat öffentlich solch ein adaptives Speichermanagement beschrieben, was vermuten lässt, dass ihre Lösungen möglicherweise schlichtweg einen hohen RAM-Bedarf haben oder Daten aggregieren müssen, um zu passen. Anaplan ist dafür bekannt, an Modelleinschränkungen zu stoßen – einige Kunden stoßen bei der Speichergrenze seines Hyperblock an und müssen Modelle aufteilen. Kinaxis benötigt vermutlich ebenfalls mehrere vernetzte Server für sehr große Datenmengen (sie haben ein Konzept der Datenverteilung, aber innerhalb jedes Knotens verbleiben die Daten im Speicher). SAP HANA kann auf Festplatten auslagern (mittels Erweiterungsknoten), allerdings leidet die Leistung darunter. Fazit: Ein starres In-Memory-Design ist ein Warnsignal für die Skalierbarkeit. Es mag für kleine bis mittelgroße Datenmengen hervorragend funktionieren, aber wenn die supply chain wächst (denken Sie an detaillierte SKU-Store-Tag-Planung für einen globalen Einzelhändler), nehmen Kosten und Leistungsrisiken stark zu. Moderne Technik bevorzugt eine Mischung aus Speicher- und Festplattenspeicherung, um Geschwindigkeit und Kosten in Einklang zu bringen – Anbieter, die dies nicht umsetzen, hinken hinterher.
Tech Stack and Complexity: Über den Speicher hinaus ist ein weiteres architektonisches Element der gesamte Tech-Stack – monolithisch versus Microservices, Einsatz moderner Programmiersprachen etc. Ohne zu sehr ins Detail zu gehen, haben wir festgestellt, dass ältere Anbieter (SAP APO/IBP, Blue Yonder) auf monolithischen, veralteten Stacks basieren, während neuere Anbieter (o9, Anaplan) ihr System von Grund auf mit moderner Technologie entwickelt haben. Beispielsweise umfasst der Kern von SAP IBP immer noch Engines aus den 2000er-Jahren (wie den Optimierer von APO), die nun in eine HANA/Cloud-Schicht eingebettet sind. Dies führt zu Komplexität und potenzieller Ineffizienz (mehrere Abstraktionsebenen). Blue Yonder weist ähnlich viel Legacy-Code aus den Zeiten von i2 und JDA auf. Kinaxis ist insofern einzigartig – es ist schon älter (Beginn in den 90er Jahren), wurde jedoch kontinuierlich in einen eigenen Datenbankkernel umgebaut; trotzdem handelt es sich um einen proprietären Stack, den nur sie einsetzen. Anaplan hat eine sehr effiziente Berechnungs-Engine (in Java) für seinen spezifischen Anwendungsfall (Hyperblock) entwickelt, die für diesen Zweck gut optimiert ist – allerdings ist sie nicht offen und man muss mit ihren Einschränkungen leben (z. B. keine SQL-Abfragen, begrenzte algorithmische Komplexität, da die Berechnungen eher zellenbasiert erfolgen). Die o9-Plattform umfasst eine Mischung aus Technologien (vermutlich eine NoSQL-/Graph-Datenbank, möglicherweise Spark oder Ähnliches für manche ML-Aufgaben etc.), was sie komplex, aber theoretisch flexibel macht.
Hardware and Cloud: Ein bemerkenswerter Trend ist das cloud-native Design. Viele Anbieter bieten ihre Software mittlerweile als SaaS oder zumindest cloudbasiert an, doch nicht alle sind wirklich cloud-native. Beispielsweise sind Anaplan und o9 Multi-Tenant-SaaS (von Grund auf für die Cloud entwickelt). Lokad ist nativ cloudbasiert (es läuft auf Microsoft Azure und weist Ressourcen dynamisch zu). SAP IBP ist cloudgehostet, jedoch entspricht jeder Kunde im Wesentlichen einer isolierten Instanz auf HANA (nicht im gleichen Multi-Tenant-Sinne). ToolsGroup, Blue Yonder haben zwar SaaS-Angebote, diese sind oftmals lediglich ihre On-Premise-Software, die in der Cloud verwaltet wird. Warum ist das technisch relevant? Cloud-native Architekturen sind in der Regel elastischer – sie können bei Bedarf Rechenkapazitäten hochfahren (zum Beispiel für einen großen Planungsdurchlauf) und danach wieder herunterfahren, was unter Umständen Kosten spart. Nicht-cloud-native Systeme erfordern oft den Erwerb von Spitzenkapazitäten, auch wenn diese nur gelegentlich genutzt werden. Zudem lassen sich cloud-native Systeme oftmals besser in andere Cloud-Dienste integrieren (beispielsweise den Anschluss an einen Cloud-ML-Dienst oder Data Lake). Nach unseren Erkenntnissen erscheinen die cloud-native und von Grund auf skalierbaren Lösungen von Lokad und o9 (und vielleicht auch Anaplan) als führend, während andere Anbieter aufholen. Allerdings – allein cloud-native zu sein, garantiert nicht automatisch eine gute Architektur; o9 ist cloud-native, jedoch hinterfragen wir seinen in-memory-lastigen Ansatz, und SAP IBP beseitigt trotz Cloud-Betrieb seine Komplexitätsprobleme.
Nebenläufigkeit und Echtzeit-Anforderungen: Eine architektonische Überlegung ist, wie das System gleichzeitige Benutzer und Echtzeit-Updates handhabt. Kinaxis sticht hier hervor: Es wurde so entwickelt, dass mehrere Planer gleichzeitig Szenarioplanungen mit demselben Datensatz durchführen können. Das erfordert eine sorgfältige Datenversionierung und Sperrlogik – was Kinaxis durch seinen Verzweigungsmechanismus ⁸ erreichte. Die meisten anderen Tools folgten traditionell einem Batch-Paradigma (planen, veröffentlichen und dann getrennt zusammenarbeiten). Heute fügen viele Funktionen für gleichzeitige Planung hinzu. Anaplan ermöglicht es mehreren Personen, gleichzeitig in verschiedenen Teilen des Modells zu arbeiten (da es im Wesentlichen zellenbasiert ist wie Google Sheets). SAP IBP führte eine „Microsoft Excel-ähnliche“ Benutzeroberfläche ein, die Daten auf Abruf vom Server aktualisieren kann, jedoch ist echte Nebenläufigkeit (gleichzeitiges Bearbeiten desselben Plans durch mehrere Benutzer) begrenzt. o9 unterstützt wahrscheinlich ein gewisses Maß an Nebenläufigkeit aufgrund seines Knowledge Graph, wodurch mehrere Benutzer verschiedene Knoten anpassen können. Bei der Bewertung des technischen Mehrwerts zeigt ein System, das wirklich in Echtzeit mit vielen Benutzern arbeiten kann, eine robuste Architektur. Kinaxis und Anaplan erhalten hier Pluspunkte. Es ist nicht so, dass andere es nicht können, aber oft erschweren ihre älteren Architekturen dies – was entweder zu langsamer Leistung oder zur Erzwungener Sequentialisierung führt.

Zusammenfassung der Architektur: Wir haben ein Muster identifiziert: In-Memory-zentrierte Designs (Kinaxis, Anaplan, o9, Relex, SAP HANA) liefern Geschwindigkeit, allerdings auf Kosten von Skalierbarkeit und Kosten, während hybride Designs (Lokads Spill-to-Disk, möglicherweise Tools, die moderne Datenbanken nutzen) skalierbarer und kosteneffizienter sind. Ein deutliches Warnsignal ist jeder Anbieter, der darauf besteht, dass alles im RAM liegen muss – dies gilt angesichts der Fortschritte bei SSD-Geschwindigkeiten und im verteilten Rechnen inzwischen als veralteter Ansatz ⁴³ ⁴⁴. Wir heben auch hervor, dass Anbieterarchitekturen, die aus mehreren Akquisitionen hervorgegangen sind (wie SAP, Blue Yonder), dazu neigen, übermäßig komplex zu sein und viel Feintuning zu benötigen. Einfachere, hausgemachte Architekturen (Kinaxis’ Single-Codebase, Anaplan’s Single Engine, Lokads Single Engine) sind tendenziell kohärenter und somit technisch leichter zu warten. Bei der Bewertung einer Supply-Chain-Software sollte man sich fragen: Hat der Anbieter irgendetwas darüber veröffentlicht, wie seine Software aufgebaut ist (Microservices? Custom DB? Einsatz von ML-Bibliotheken? etc.)? Ein Mangel an jeglicher technischer Diskussion könnte bedeuten, dass die Architektur einfach eine Black Box ist – was oft auf Altlasten oder mangelndes Vertrauen in die eigene Einzigartigkeit hinweist.

Integration & Modul-Kohärenz (Auswirkungen von M&A)

Die Supply-Chain-Planung umfasst typischerweise mehrere Bereiche (Nachfrageprognose, Bestandsoptimierung, Produktionsplanung etc.). Einige Anbieter bieten eine integrierte Suite an, die organisch entwickelt wurde, während andere durch Akquisitionen gewachsen sind und neue Module hinzugefügt haben. Wir haben untersucht, wie das Lösungsportfolio jedes Anbieters integriert ist und welche Warnsignale sich aus deren Wachstumsstrategie ergeben.

Blue Yonder (JDA) ist das Paradebeispiel für Wachstum durch Akquisition. Wie bereits erwähnt, handelt es sich um eine „wilde Sammlung“ von Produkten aus verschiedenen Epochen ²⁹. JDA erwarb i2 (das selbst mehrere Module hatte), übernahm früher Manugistics, akquirierte dann RedPrairie (für das Lagerhausmanagement) und schließlich das Startup Blue Yonder für KI. Jedes Teil hatte sein eigenes Datenbankschema und seine eigene Logik. Das Ergebnis: Selbst heute teilen Blue Yonder’s Nachfrageplanung, Angebotsplanung und Bestandsoptimierung möglicherweise nicht dasselbe einheitliche Datenmodell – die Integration basiert auf Schnittstellen. Dies ist ein Warnsignal, da die Implementierung der kompletten Suite im Wesentlichen die Integration mehrerer unterschiedlicher Softwarepakete bedeutet. Wenn die Produkte eines Anbieters nicht wirklich vereinheitlicht sind, haben Kunden mit Problemen wie Verzögerungen bei der Datensynchronisation, inkonsistenten Benutzeroberflächen und doppelter Funktionalität zu kämpfen. Im Fall von Blue Yonder überlappen einige seiner Module offen (nach Akquisitionen könnte es zwei Wege zur Bestandsplanung geben – einen aus dem Legacy-System von Manugistics und einen aus i2). Das Unternehmen hat Anstrengungen unternommen, dies zu rationalisieren, aber es ist nicht vollständig gelöst. Technisch betrachtet, „vermischen“ sich Unternehmenssoftwares nicht wie Flüssigkeiten, wenn Firmen fusionieren ²⁹ – es bedarf jahrelanger Umgestaltung. Wir haben keine Hinweise darauf gefunden, dass Blue Yonder diese Umgestaltung abgeschlossen hat. Daher ist der Mangel an Kohärenz eine wesentliche technische Schwäche.
SAP IBP kombinierte ähnlich erworbene Komponenten: Der Erwerb von SAF, SmartOps und weiteren Tools durch SAP brachte separate Anwendungen mit sich, die dann unter dem IBP-Dach zusammengeführt wurden ²⁷. Nutzer haben festgestellt, dass IBP verschiedene Module umfasst, die sich wie separate Apps anfühlen (zum Beispiel IBP for Demand versus IBP for Inventory). Die Optimierungslogik für Sicherheitsbestände in IBP stammt wahrscheinlich aus der SmartOps-Akquisition, während die Nachfrageerfassung möglicherweise von SAF oder internen Entwicklungen herrührt. Die Integration ist besser als bei Blue Yonder (SAP hat jedenfalls die Benutzeroberfläche neu geschrieben und alles auf die HANA-Datenbank gestellt), aber dennoch ist unter der Haube IBP keine Single-Codebase. SAP weist ausdrücklich darauf hin, dass die Implementierung von IBP in der Regel mehrere Jahre und Expertenintegratoren erfordert, um alle Module optimal zusammenzuführen ²⁸. Diese Aussage ist an sich ein Warnsignal – sie deutet auf mögliche Unstimmigkeiten und hohe Komplexität hin.
Infor (obwohl nicht in den oben aufgeführten Top 10) fusionierte ebenfalls verschiedene Planungssysteme (sie hatten beispielsweise Mercia’s Supply-Chain-Planung und GT Nexus akquiriert). Das Ergebnis war nie eine wirklich einheitliche Planungsplattform; Infor konzentriert sich tendenziell auf Ausführungssysteme. Es ist also ein weiteres Beispiel, bei dem Akquisitionen kein hervorragend integriertes Planungsprodukt hervorgebracht haben.
Dassault (Quintiq): In diesem Fall beinhaltete die Akquisition (durch Dassault) nicht die Verschmelzung von Quintiq mit einem anderen Planungstool – Dassault ließ Quintiq weitgehend als eigenständiges Angebot für Produktions- und Terminoptimierung bestehen. Somit ist die interne Kohärenz von Quintiq in Ordnung (es wurde hausintern entwickelt und bleibt dies auch), aber der Nachteil ist, dass es nicht alle Bereiche abdeckt (z. B. keine native Nachfrageprognose, wie bereits erwähnt ¹⁶). Dassaults Portfolio umfasst weitere Produkte (wie Apriso für MES etc.), die jedoch nicht tief in Quintiq integriert sind. In Bezug auf die Integration ist Quintiq also selbstkonsistent, aber funktional begrenzt. Aus der Perspektive des Nutzers könnte es notwendig sein, es mit einem anderen Prognosetool zu integrieren, was zusätzlichen Aufwand auf Kundenseite bedeutet.
Kinaxis ist überwiegend organisch gewachsen – es akquirierte 2020 ein kleines KI-Unternehmen namens Rubikloud (für Retail-KI) und 2022 ein Supply-Chain-Design-Tool (Castle Logistics), aber diese Übernahmen sind relativ neu und es bleibt abzuwarten, wie sie integriert werden. Historisch war RapidResponse ein einziges Produkt, das verschiedene Planungsaspekte über Konfiguration abwickelte. Diese Kohärenz ist ein Vorteil: alle Module (Nachfrage, Angebot, Bestand) teilen sich eine einzige Datenbank und Benutzeroberfläche in Kinaxis. Ebenso baute Anaplan verschiedene Planungs-“Apps” auf einer Plattform aus – Vertriebs-, Finanz- und Supply-Chain-Pläne befinden sich alle in derselben Hyperblock-Umgebung, was technisch sehr kohärent ist (nur mit unterschiedlichen Modellvorlagen). o9 Solutions ist ebenfalls eine organisch entwickelte Single-Plattform, die viele Bereiche abdeckt (es ist zumindest nicht hauptsächlich durch Akquisition anderer Planungslösungsanbieter gewachsen). Somit haben diese drei – Kinaxis, Anaplan, o9 – einen architektonischen Vorteil in ihrer Einheitlichkeit. Die Vorsicht bei ihnen besteht weniger in der Integration unterschiedlicher Module, sondern vielmehr darin, ob ihre einzelne Plattform die notwendige Tiefe in jedem Bereich wirklich bewältigen kann.
ToolsGroup & Slimstock: Diese Anbieter blieben in ihrer Nische (Nachfrage- und Bestandsplanung) fokussiert. Sie akquirierten nicht wirklich andere Unternehmen; stattdessen arbeiten sie mit Ausführungssystemen zusammen oder integrieren diese bei Bedarf. Das bedeutet, dass ihre Software intern konsistent ist (eine einzige Codebasis), was vorteilhaft ist, jedoch müssen Kunden, die erweiterte Funktionen benötigen (wie Produktionsplanung), ein anderes Produkt verwenden und dieses selbst integrieren. In den letzten Jahren begann ToolsGroup, S&OP-Funktionen hinzuzufügen, und erwarb sogar ein KI-Startup (Eramos im Jahr 2018) für maschinelles Lernen, allerdings wurden diese dann in das Kernprodukt integriert, anstatt separat verkauft zu werden. Somit stellt die Integration für ToolsGroup oder Slimstock kein großes Problem dar – der Kompromiss besteht darin, ob ihr fokussiertes Design den Umfang der Kundenanforderungen abdeckt.

Zusammenfassung der Integration: Aus einer skeptischen Perspektive sind mehrere größere Akquisitionen in der Geschichte eines Anbieters ein Warnsignal. Oft führt dies zu einem Alleskönner-Produkt, das in nichts wirklich hervorragend ist und versteckte Komplexität aufweist. Blue Yonder und SAP veranschaulichen dies – ihre technische Komplexität resultiert teilweise daraus, dass sie viele übernommene Komponenten zusammenzufügen versuchen. Umgekehrt vermeiden Anbieter mit einer einheitlichen Plattform (die organisch entstanden ist) diese Probleme, auch wenn sie dennoch beweisen müssen, dass eine einzige Plattform alles gut beherrscht. Bei der Bewertung von Software sollte man nach dem Ursprung jedes Moduls fragen: Wenn das Modul für die Nachfrageplanung und das Modul für die Angebotsplanung von unterschiedlichen ursprünglichen Unternehmen stammen, sollte man untersuchen, wie sie Daten austauschen und ob die Integration nahtlos oder über Schnittstellen erfolgt. Die Geschichte zeigt, dass, sofern die erworbene Technologie nicht von Grund auf in eine einheitliche Architektur umgeschrieben wurde (was aufgrund von Kosten und Zeit selten vorkommt), das Ergebnis üblicherweise ein Frankenstein-System ist. Unsere Forschung untermauert dies – die Anbieter mit den höchsten Bewertungen in technischer Eleganz (Lokad, Kinaxis, Anaplan) haben ihre Lösungen ganzheitlich entwickelt, während jene mit den niedrigsten Bewertungen (Blue Yonder, Infor) disparate Technologien anhäuften, ohne sie vollständig zu vereinheitlichen.

Kritische Schwachstellen & Warnsignale

In unserer gründlichen Überprüfung haben wir mehrere wiederkehrende Schwächen und Warnsignale identifiziert, derer potenzielle Nutzer sich bewusst sein sollten. Nachfolgend eine Zusammenfassung der wichtigsten Probleme, mit Beispielen von bestimmten Anbietern zur Veranschaulichung jedes Punktes:

Unbelegte “KI/ML”-Behauptungen: Seien Sie äußerst skeptisch gegenüber jedem Anbieter, der überlegene KI oder maschinelles Lernen ohne harte technische Beweise behauptet. Zum Beispiel bewirbt Blue Yonder seine KI stark, liefert aber nur vage Aussagen ohne Substanz ³² – das Wenige, was wir von ihren Methoden sehen können, deutet darauf hin, dass sie sich auf ältere Techniken verlassen und nicht auf modernste KI. Ebenso rühmt o9 Solutions seine KI und graph-basierte Intelligenz an, doch die Analyse ihres öffentlichen Codes und Materials zeigt „Massen an KI-Hype“ mit lediglich durchschnittlicher Analytik in der Realität ²⁶. Wenn ein Anbieter nicht auf peer-reviewte Studien, Patente, Wettbewerbe oder detaillierte technische Papiere verweisen kann, um seine KI-Behauptungen zu untermauern, gehen Sie davon aus, dass es sich um reinen Marketing-Hype handelt. Wirklich fortschrittliche Anbieter werden stolz darauf sein, ihre Algorithmen im Detail darzulegen.
Kein wettbewerbsfähiges Benchmarking (Behauptungen über überlegene Prognosegenauigkeit): Viele Anbieter behaupten „Klassenbeste Prognosegenauigkeit“, aber außer Lokad hat keiner dies in offenen Wettbewerben oder Publikationen bewiesen. Wir werten jede derartige Behauptung als unglaubwürdig, sofern sie nicht validiert ist. Zum Beispiel tauchte ein proprietärer Algorithmus eines Anbieters, der damit prahlte, „genauer als andere zu sein“, in den Top-Rängen des M5-Wettbewerbs ³¹ nicht auf, was stark darauf hindeutet, dass seine Behauptung unbegründet ist. Tatsächlich erschien kein einziger traditioneller Supply-Chain-Softwareanbieter (außer Lokad) in den Top 100 dieses globalen Prognosewettbewerbs. Dies ist ein großes Warnsignal: Es impliziert, dass diese Anbieter entweder nicht teilgenommen haben (vielleicht um öffentliche Blamage zu vermeiden) oder teilgenommen und schlecht abgeschnitten haben. Konkreter Ratschlag: Fordern Sie objektive Genauigkeitsergebnisse an (z. B. wie hat sich Ihr Tool bei einem Standard-Benchmark wie dem M5- oder M4-Datensatz geschlagen) – wenn sie nichts vorweisen können, kaufen Sie nicht den Hype.
Überbeanspruchung der In-Memory-Architektur: Anbieter, die ein reines In-Memory-Design propagieren, sollten hinsichtlich Skalierbarkeit und Kosten hinterfragt werden. In-Memory Computing bietet Geschwindigkeit, aber RAM ist etwa 100-mal teurer pro GB als Festplattenspeicher ¹⁰ und sein Preis-Leistungs-Verhältnis stagniert in den letzten Jahren ⁴². Dies macht rein In-Memory-Lösungen bei großen Datenvolumen unskalierbar und kostspielig. SAP IBP (HANA) und o9 sind Beispiele: Sie garantieren hohe Leistung nur, wenn riesige Datensätze in den Speicher geladen werden, was hohe Hardware- (oder Cloud-)Kosten garantiert ²⁴ ³⁰. Es ist bemerkenswert, dass moderne Systemdesigns sich von diesem Ansatz entfernen – wie ein Experte anmerkte, hat der anfängliche Trend, alles in den RAM zu packen, praktische Grenzen erreicht, und Datenbanken „entdecken ihre Liebe zur Festplatte wieder“, um kalte Daten effizient zu verwalten ⁴³ ⁴⁴. Wenn ein Anbieter immer noch an einem ausschließlich In-Memory-Ansatz festhält, sollte dies als architektonisches Warnsignal betrachtet werden. Skalierbarere Anbieter sprechen über gestaffelten Speicher, Cloud-Elastizität oder ähnliche Strategien, um große Datenmengen zu bewältigen, ohne unendlichen RAM zu benötigen.
Black-Box durch M&A (Integrationsstörung): Wenn die Produktpalette eines Anbieters das Ergebnis mehrerer Akquisitionen ist, sollte man vorsichtig sein mit Integrationslücken und überlappenden Funktionen. Wie wir gesehen haben, ist Blue Yonder’s Suite ein willkürliches Gemisch aus veralteten Produkten aufgrund einer langen Reihe von Fusionen ²⁹, und die Module von SAP IBP stammen aus verschiedenen akquirierten Unternehmen ²⁷, was zu einer Komplexität und einer „Sammlung“ von Tools anstelle eines nahtlosen Ganzen führt. Unternehmenssoftware lässt sich nicht einfach durch M&A „vermischen“ ²⁹ – sofern der Anbieter nicht eine vollständige Umgestaltung vorgenommen hat (was selten und sehr zeitaufwändig ist), endet der Kunde oft als Integrator zwischen den Modulen. Dies kann zu inkonsistenten Benutzererfahrungen, doppelter Dateneingabe und fragilen Schnittstellen führen. Warnsignal: Die Implementierung beim Anbieter erfordert ein Bataillon von Beratern für ein Jahr oder länger, um die Module miteinander kommunizieren zu lassen – wie selbst im Fall von SAP zugegeben ²⁸. Bevorzugen Sie Anbieter mit einer einheitlichen Plattform oder minimalen Überschneidungen bei akquirierten Komponenten.
Widersprüchliche Kennzahlen und Schlagwörter: Ein subtiler, aber aussagekräftiger Warnhinweis ist, wenn die technische Darstellung eines Anbieters interne Widersprüche oder veraltete Praktiken, die in neuer Terminologie getarnt sind, enthält. Ein auffälliges Beispiel war, dass ToolsGroup probabilistische Prognosen bewirbt, während gleichzeitig auf MAPE-Verbesserungen verwiesen wird ¹⁹ – ein Hinweis darauf, dass sie lediglich neue Terminologie auf alte Praktiken übertragen (da die Verwendung von MAPE zur Beurteilung probabilistischer Prognosen konzeptionell falsch ist). Ein weiteres Beispiel ist, wenn Anbieter behaupten, „fortschrittliche KI“ zu verwenden, aber dann den Erfolg mit alten Kennzahlen wie MAPE oder traditionellen Servicelevels messen – das zeigt, dass sie das neue Paradigma nicht wirklich übernommen haben. Ebenso sollte man auf Methoden zur Berechnung des Sicherheitsbestands achten: Ein Anbieter könnte behaupten, Inventar mit KI zu optimieren, aber wenn man genauer hinschaut und feststellt, dass er den Sicherheitsbestand noch immer mit einer Formel aus den 1980er Jahren berechnet (z. B. unter Annahme einer Normalverteilung mit einem statischen Sicherheitsfaktor), ist das ein Widerspruch. Wir haben tatsächlich Fälle gefunden, in denen Anbieter über „probabilistisches“ oder „optimales“ Inventar sprechen, deren Dokumentation jedoch Standard-Sicherheitsbestandsberechnungen und den Einsatz veralteter Kennzahlen wie Fill-Rate enthüllt. Fazit: Inkonsistenzen zwischen dem, was sie vermarkten, und dem, was sie messen/liefern, sind ein Warnsignal. Wenn ein Anbieter damit wirbt, modern und KI-getrieben zu sein, dabei aber dieselben KPIs und Methoden verwendet, die seit Jahrzehnten im Einsatz sind, ist seine Innovation wahrscheinlich oberflächlich.
Veraltete Algorithmen und Praktiken: Die Theorie der supply chain hat sich weiterentwickelt (z. B. von deterministischen zu stochastischen Modellen, von Ein-Ebenen- zu Mehr-Ebenen-Optimierung), aber einige Softwarelösungen haben nicht Schritt gehalten. Die Abhängigkeit von jahrzehntealten Praktiken ist eine Schwäche, besonders wenn Anbieter etwas anderes vortäuschen. Zum Beispiel ist ein Tool, das nach wie vor vorwiegend Sicherheitsbestand- und Nachbestellpunkt-Logik mit festen Lieferzeiten für das Inventar verwendet, veraltet, wenn es die Nachfragevariabilität nicht dynamisch berücksichtigt. Wir haben festgestellt, dass Slimstock explizit auf traditionelle Formeln (Sicherheitsbestand, EOQ) ²¹ setzt – sie sind offen darüber, was für eine Basissolution in Ordnung ist, aber eindeutig nicht auf dem neuesten Stand. Wenn ein angeblich fortschrittlicher Anbieter nicht transparent ist, könnte er dasselbe tun, ohne es zuzugeben. Ein weiteres Beispiel: Blue Yonder’s Open-Source-Snippets wiesen auf ARMA-Modelle ⁴⁸ hin, Prognosetechniken aus den 1970er Jahren, obwohl in ihrem Vertriebsmaterial von KI die Rede ist. Infor, Oracle, John Galt und andere Anbieter im unteren Segment verlassen sich ähnlich oft auf Zeitreihenmethoden und Heuristiken, die es schon ewig gibt (wie Winters’ exponentielle Glättung, einfache Optimierungslöser) – diese funktionieren, aber es gibt nichts Modernes an ihnen. Das Warnsignal liegt nicht im Einsatz alter Methoden an sich (alte Methoden können in manchen Fällen immer noch die besten sein), sondern darin, sie zu verwenden und gleichzeitig zu behaupten, innovativ zu sein, oder sie ausschließlich einzusetzen, wenn für das Problem bessere Methoden verfügbar sind. Hinterfragen Sie stets, welche Algorithmen tatsächlich verwendet werden (z. B.: „Berücksichtigt Ihre Inventaroptimierung die gesamte Nachfrageverteilung oder nur einen einzelnen Servicerisikofaktor? Verwenden Sie Mehr-Ebenen-Optimierung oder nur Einzelknoten-Berechnungen?“). Ausweichende oder vage Antworten deuten darauf hin, dass die Methodik veraltet sein könnte.
Mangel an technischer Transparenz: Abschließend ein übergeordnetes Warnsignal: Wenn ein Anbieter keine technische Dokumentation bereitstellt – weder Whitepapers, noch eine Referenzarchitektur, noch eine Erklärung der Algorithmen – ist das an sich ein Warnhinweis. In unserer Untersuchung verfügten Anbieter, die technisch gut abschnitten (Lokad, Kinaxis, SAS usw.), alle über zumindest etwas technischen Inhalt (sei es in Blogs, wissenschaftlichen Arbeiten oder technischen Notizen). Anbieter, die schlecht abschnitten, verfügen oft nur über Marketingbroschüren. Zum Beispiel: Versuchen Sie, ein detailliertes technisches Whitepaper von o9 oder Blue Yonder zu finden – das ist nahezu unmöglich, meist erhält man nur glänzende Broschüren. Lokad hingegen hat eine 18-seitige, detaillierte Marktstudie veröffentlicht (die wir umfangreich zitiert haben) ⁴⁹ ²⁹ ²⁵, sowie Videos darüber, wie ihre Algorithmen funktionieren. Wenn ein Anbieter geheimniskrämend darüber ist, wie seine Lösung funktioniert, muss man sich fragen, ob es daran liegt, dass sie eigentlich nicht besonders ist. Transparenz korreliert mit Glaubwürdigkeit. Ein Anbieter, der sich hinter Schlagwörtern versteckt und seine Methoden nicht offenlegt, bietet wahrscheinlich „gewöhnliche Technik mit extra Lippenstift“.

Abschließend zeigt ein hoch skeptischer, ingenieurzentrierter Blick, dass viele „führende“ supply chain Optimierungssoftwares reich an Versprechen, aber arm an überprüfbarer Innovation sind. Indem wir den Marketing-Blabla beiseite ließen, konzentrierten wir uns auf das Greifbare: Datenstrukturen, Algorithmen, Leistung und den Nachweis der Wirksamkeit. Die besten Lösungen fielen dadurch auf, dass sie technische Substanz boten – nachgewiesene Prognosegenauigkeit, klare architektonische Entscheidungen und offene Dokumentation – während die schwächeren sich durch Widersprüche, Unklarheiten und veraltete Grundlagen zeigten. Diese Studie dient als Erinnerung für jeden supply chain Praktiker: Nehmen Sie die Aussagen der Anbieter nicht einfach so hin. Fordern Sie Beweise, schauen Sie unter die Haube und denken Sie daran, dass in der supply chain, wie in der gesamten IT, die echten, neuesten Fortschritte in der Regel von offener Wissenschaft und solider Ingenieurskunst getragen werden – und nicht nur von hochtrabenden Marketingaussagen.