Software zur Optimierung der Supply Chain

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 hat die probabilistische Prognose eingeführt und seine Methoden in einem offenen Wettbewerb bewiesen (Platz #1 auf SKU-Ebene und #6 insgesamt von 909 Teams im M5-Prognosegenauigkeitswettbewerb ¹ – das einzige vom Anbieter geführte Team in den Top-Rängen). Lokad veröffentlicht detaillierte Einblicke in seine Architektur (z.B. eine domänenspezifische Sprache namens Envision, Cloud-basierte Automatisierung) und betont finanziell optimierte Entscheidungen über einfache Metriken. Sein Fokus auf rigorose Mathematik (Quantilprognosen, stochastische Optimierung) und vollständig skriptfähige, automatisierte Workflows (über APIs und Codierung) zeigt ein Engineering-first-Design. Es werden keine großen AI/ML-Behauptungen ohne Unterstützung aufgestellt – stattdessen bietet Lokad technische Whitepapers und sogar Open-Source-Tools für das Skalieren von Daten über RAM-Grenzen hinaus ² ³. Diese Offenheit und bewährte Leistung setzt Lokad an die Spitze.
Anaplan – “Excel 2.0” Plattform. Anaplan ist im Wesentlichen die Unternehmens-SaaS-Version einer Tabelle, angetrieben von seinem proprietären Hyperblock In-Memory-Engine ⁴. Technisch gesehen ist Hyperblock eine robuste mehrdimensionale Berechnungsengine, die es Tausenden von Benutzern ermöglicht, in Echtzeit an Planungsmodellen zusammenzuarbeiten – vergleichbar mit einem supergeladenen, Cloud-basierten Excel. Obwohl Anaplan nicht per se ein spezialisierter Optimierer der Supply Chain ist (Prognose und algorithmische Optimierung sind “zweitrangige Bürger” auf dieser Plattform ⁵), liegt seine Stärke in seiner soliden Architektur für Modellierung und Szenarioplanung. Es handelt nicht mit irgendeiner mystischen KI; stattdessen bietet es eine zuverlässige, leistungsstarke Sandbox zum Erstellen von benutzerdefinierter Planungslogik. Kurz gesagt, es ist ein leistungsstarkes allgemeines Planungswerkzeug mit einem ehrlichen Ansatz – keine übertriebenen Behauptungen über Prognosemagie, nur ein gut konstruiertes, skalierbares Tabellenkalkulationssystem. Dieser unkomplizierte technische Vorschlag verleiht Anaplan eine hohe Glaubwürdigkeit.
Kinaxis (RapidResponse) – In-Memory-Simulation-Engine. Kinaxis ist bekannt für seine einzigartige Gleichzeitigkeit-Engine, die es ermöglicht, Versorgungspläne in Echtzeit im gesamten Unternehmen neu zu berechnen. Technisch gesehen hat Kinaxis seine eigene Datenbank-Engine von Grund auf neu erstellt, um dies zu unterstützen ⁶ ⁷. Das Ergebnis ist eine Plattform, die für schnelle “Was-wäre-wenn”-Simulationen optimiert ist: Benutzer können Szenarien abzweigen (wie Git für Daten) und erhalten sofortiges Feedback über die Auswirkungen von Änderungen ⁸. Das System hält alle Supply-Chain-Daten im Speicher für Geschwindigkeit, wobei Algorithmen direkten Speicherzugriff auf Daten für maximale Durchsatzleistung haben ⁹. Dieses Design ermöglicht eine echte gleichzeitige Planung (z.B. Verkaufs-, Produktions- und Bestandspläne werden in Echtzeit zusammen aktualisiert). Aus technischer Sicht ist der Aufbau eines benutzerdefinierten In-Memory-, versionskontrollierten Datenspeichers eine beeindruckende Leistung, die Agilität bietet. Der Kompromiss besteht jedoch in hohen Hardwareanforderungen – ein vollständig im Speicher basierender Ansatz bedeutet, dass das Skalieren auf massive Datengrößen kostspielig sein kann (da die RAM-Anforderungen wachsen) ¹⁰. Insgesamt zeigt Kinaxis starke technische Strenge in Architektur und Leistung, während es modische KI-Behauptungen vermeidet. Es glänzt in der Versorgungsplanung und S&OP-Simulationen, obwohl es im Vergleich zu einigen Kollegen weniger ML-Prognosefunktionen aus der Box bietet.
SAS – Statistisches Kraftpaket. SAS ist ein erfahrener Analytics-Softwareanbieter (gegründet 1976) und bringt einen formidablen statistischen Modellierungsmotor für Supply-Chain-Probleme mit. Sein Flaggschiff beinhaltet eine domänenspezifische Sprache für Statistiken (die SAS-Sprache), die bis in die 1970er Jahre zurückreicht ¹¹ – wohl die ursprüngliche Data-Science-Plattform. Die Stärke von SAS liegt in der Tiefe seiner Algorithmen: eine riesige Bibliothek von Zeitreihen-Prognosemodellen, Optimierungsroutinen und maschinellen Lernverfahren, die über Jahrzehnte hinweg entwickelt wurden. Es beschäftigt einige der talentiertesten Ingenieure und Statistiker der Branche ¹¹, und es hat die fortschrittliche Prognose lange vor “AI” als Schlagwort eingeführt. In Supply-Chain-Kontexten wird SAS oft für die Nachfrageprognose und die Bestandsanalyse verwendet. Technisch gesehen ist es robust und bewährt – aber auch schwer. Die Werkzeuge können sich veraltet anfühlen (die Welt ist weitgehend auf Open-Source-Sprachen wie Python/R umgestiegen, und tatsächlich sind Jupyter-Notizbücher nun eine überlegene offene Alternative ¹²). SAS behauptet nicht lautstark magische AI; es verlässt sich auf seinen Ruf und solide Technik. Für Organisationen, die die Expertise haben, sie zu nutzen, bietet SAS ernsthafte analytische Feuerkraft, die auf realen Algorithmen (ARIMA, ETS, etc.) statt auf Hype basiert. Sein Hauptnachteil ist, dass es sich um eine allgemeine Analyseplattform handelt – extrem leistungsfähig unter der Haube, aber erfordert geschulte Benutzer, um sie auf die Supply Chain anzuwenden, und sie wurde nicht speziell in jüngsten Prognosewettbewerben benchmarked (Open-Source-Tools stehen ihr oft gegenüber ¹³).
Dassault Systèmes (Quintiq) – Optimierungsspezialist. Quintiq (2014 von Dassault Systèmes übernommen) ist eine Plattform, die sich auf komplexe Supply-Chain-Optimierung und Planung konzentriert. Sie verfügt über eine proprietäre domänenspezifische Sprache namens Quill zur Modellierung von Geschäftsbeschränkungen ¹⁴. Diese DSL ermöglicht es Ingenieuren, maßgeschneiderte Lösungen zu kodieren (zum Beispiel benutzerdefinierte Produktionspläne oder Routing-Pläne) und mathematische Solver zu nutzen. Die bloße Existenz einer DSL im Produkt ist ein Beweis für ernsthafte Deep-Tech-Kompetenz – die Gestaltung einer Programmiersprache für Planungsprobleme ist nicht trivial ¹⁵. Quintiq glänzt in Szenarien wie Fabrikplanung, Logistiknetzwerkoptimierung und anderen NP-schweren Problemen, bei denen ein benutzerdefiniertes Optimierungsmodell benötigt wird. Technisch gesehen ist es einer der flexibelsten und leistungsfähigsten Optimierungsmotoren, die in der Supply-Chain-Software verfügbar sind. Allerdings kommt Quintiqs Fokus auf Optimierung auf Kosten anderer Bereiche: zum Beispiel hat es relativ begrenzte native Prognosefähigkeiten ¹⁶. Eine weitere Sorge ist, dass öffentliche technische Updates zu Quill selten sind, was darauf hindeutet, dass die Technologie möglicherweise veraltet ist oder zumindest nicht schnell weiterentwickelt wird ¹⁷. Benutzer verlassen sich oft auf Dassaults Berater, um Lösungen zu konfigurieren, und ohne klare öffentliche Dokumentation ist es schwer, jüngste Innovationen zu beurteilen. Zusammenfassend ist Quintiq eine erstklassige Wahl für komplexe Optimierungsbedürfnisse und zeigt starke Ingenieurleistungen durch seine DSL – aber es ist nicht so transparent oder aktuell in Bereichen wie AI/Prognose, und seine Stärken liegen in dem, was die Implementierer damit bauen, anstatt in der Out-of-Box-“Intelligenz”.
ToolsGroup (SO99+) – Probabilistischer Pionier mit Vorbehalten. Die Software von ToolsGroup (SO99+) hat sich lange auf Nachfrageprognose und Bestandsoptimierung spezialisiert, mit einem Schwerpunkt auf probabilistischen Modellen. Es bietet umfangreiche Supply-Chain-Funktionalität (Nachfrageplanung, Nachschub, Multi-Echelon-Bestandsoptimierung) und war einer der frühen Anbieter, die “Powerfully Simple” probabilistische Prognosen propagierten. Auf dem Papier klingt das fortschrittlich – ToolsGroup sagt, es modelliert Nachfrageunsicherheit und “selbsttunende” Prognosen, was genauere Bestandsziele ermöglichen sollte. Allerdings wirft ein genauer technischer Blick Bedenken auf. Die öffentlichen Materialien von ToolsGroup deuten immer noch darauf hin, dass sie Prognosemodelle aus der Zeit vor 2000 unter der Haube verwenden ¹⁸ – sie haben ein “AI”-Glossar im Marketing hinzugefügt, aber ohne Spezifika. Bezeichnenderweise werben sie seit 2018 für probabilistische Prognosen und prahlen gleichzeitig mit Verbesserungen der MAPE ¹⁹. Das ist ein eklatanter Widerspruch: Wenn Prognosen wirklich probabilistische Verteilungen sind, gelten Metriken wie MAPE (die die Genauigkeit von Einzelwerten misst) nicht mehr direkt ¹⁹. Solche Inkonsistenzen legen nahe, dass der “probabilistische” Teil möglicherweise oberflächlich ist oder dass sie sich trotz neuer Methoden an alte Metriken halten. Außerdem hat ToolsGroup Schlagworte wie “Demand Sensing AI” verwendet, aber diese Behauptungen werden nicht durch wissenschaftliche Literatur oder irgendeinen bekannten Benchmark unterstützt ²⁰. In der Praxis funktionieren viele ToolsGroup-Implementierungen immer noch als automatisierte regelbasierte Systeme mit Ausnahmealarmen. Fazit: ToolsGroup hat eine breite Funktionalität und war Vorreiter bei der Modellierung von Unsicherheit, aber seine mangelnde Transparenz über Algorithmen und die Kluft zwischen Marketing und Realität bei AI/ML machen seine technische Glaubwürdigkeit nur mäßig. Es ist ein solides, domänenfokussiertes Werkzeugset, aber nicht klar nach heutigen Standards state-of-the-art.
Slimstock (Slim4) – Einfach und solide. Slimstock ist ein erfrischender Außenseiter, der keine Trends verfolgt. Seine Slim4-Software konzentriert sich auf mainstream Supply-Chain-Techniken – Dinge wie klassische Sicherheitsbestandsberechnungen, Nachbestellpunkte, wirtschaftliche Bestellmenge (EOQ), usw. ²¹. Mit anderen Worten, Slimstock hält sich an bewährte, in Lehrbüchern gelehrt Methoden. Das bedeutet zwar keine ausgefallene KI/ML oder hochmoderne Algorithmen, aber es bedeutet auch, dass Slim4 zuverlässig und leicht zu verstehen ist. Der Anbieter vermeidet ausdrücklich vage KI-Behauptungen und betont stattdessen praktische Funktionen, die mit den alltäglichen Bedürfnissen der Supply Chain übereinstimmen ²². Diese Ehrlichkeit ist ein technisches Verdienst: Die Benutzer wissen genau, was sie bekommen, und das Verhalten des Systems ist vorhersehbar. Natürlich kann auch Einfachheit eine Einschränkung sein – Sie erhalten keine probabilistischen Bedarfsprognosen oder fortgeschrittene Optimierer von Slim4. Es ist nicht für hochkomplexe Netzwerke oder massive Datenmengen konzipiert (und tatsächlich ist seine technische Architektur wahrscheinlich eine Standarddatenbank mit In-Memory-Caching, geeignet für mittelgroße Probleme). Aber für viele Unternehmen ist einfacher besser, wenn das bedeutet, dass das Tool konsequent funktioniert. Slimstock verdient Glaubwürdigkeitspunkte für das Vermeiden von Buzzword-Bingo; sein “punktgenauer” Ansatz wird von Kollegen als Kontrast zur KI-Postur anderer gelobt ²³. Zusammenfassend ist Slim4 technologisch nicht bahnbrechend, aber es ist 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 Unternehmens-Supply-Chain, das Nachfrageprognosen, Lieferplanung, S&OP und sogar Umsatzmanagement auf einer Plattform kombiniert. Technisch gesehen hat o9 viele moderne Tech-Konzepte in sein Produkt eingebaut: ein In-Memory-Datenmodell, eine Graphdatenbank namens “Enterprise Knowledge Graph (EKG)” und verschiedene KI/ML-Komponenten. Die reine “Tech-Masse” von o9 ist außerordentlich hoch ²⁴ – nach den Standards von Unternehmenssoftware handelt es sich um eine sehr ehrgeizige Architektur, die alle Daten und Planungsanalysen vereinheitlichen will. Allerdings, wenn man skeptisch ist: Vieles davon scheint Technologie um ihrer selbst willen zu sein, ohne klaren Nutzen. Das In-Memory-Design von o9 garantiert extrem hohe Hardwarekosten im großen Maßstab ²⁵, ähnlich wie das kontinuierliche Betreiben eines riesigen BI-Würfels. o9 preist seinen EKG (Knowledge Graph) als ermöglicht überlegene Prognosen und KI-getriebene Erkenntnisse an, aber es werden keine wissenschaftlichen Beweise oder glaubwürdige Benchmarks geliefert ²⁵. Tatsächlich zerfallen viele der auffälligen Behauptungen von o9 unter genauer Betrachtung: Das Unternehmen spricht überall von KI, doch Teile ihres öffentlich sichtbaren Codes auf GitHub offenbaren eher Fußgänger-Techniken ²⁶. Zum Beispiel hat o9 Funktionen wie maschinelles Lernen zur Nachfrageprognose und “digitale Zwillings”-Simulationen beworben, hat diese aber in keinem öffentlichen Wettbewerb oder peer-reviewed Fallstudie demonstriert. Ohne Beweise müssen wir seine KI-Behauptungen als Marketing-Hype behandeln. Das heißt aber nicht, dass o9 keine Stärken hat – es ist eine einheitliche Plattform (in-house entwickelt, nicht eine Ansammlung von Übernahmen) und kann große Datenintegrationen bewältigen. Für ein Unternehmen, das bereit ist, in Hardware zu investieren und eine steile Lernkurve in Kauf zu nehmen, bietet o9 die Flexibilität, komplexe Planungsmodelle zu erstellen. Aber aus technischer Sicht ist es eine überentwickelte Lösung: viel Komplexität, unklarer ROI auf die ausgefallene Technik und mögliche Leistungsprobleme, wenn die Daten über das hinauswachsen, was der Speicher fassen kann. Bis o9 harte Beweise liefert (z.B. Dokumentation von Algorithmen oder Benchmark-Ergebnisse), bleibt seine Glaubwürdigkeit fragwürdig.
SAP IBP (Integrated Business Planning) – Umfassend, aber komplex. Die IBP-Suite von SAP ist die Weiterentwicklung des älteren APO von SAP, jetzt als Cloud-Lösung auf der In-Memory-Datenbank SAP HANA angeboten. SAP IBP zielt darauf ab, das gesamte Spektrum abzudecken: Nachfrageprognose, Bestandsoptimierung, Lieferplanung, Vertriebs- und Betriebsplanung und mehr - alles eng integriert mit SAPs ERP. Die Stärke von SAP IBP liegt in der Breite: Es gibt ein Modul für fast jeden Planungsaspekt, oft mit sehr reicher Funktionalität, die aus jahrzehntelanger SAP-Erfahrung stammt. Allerdings kam die Breite durch Übernahmen und ältere Systeme. SAP hat Spezialisten wie SAF (Nachfrageprognose), SmartOps (Bestandsoptimierung) und andere ²⁷ erworben und diese auf seine hauseigenen Tools (wie APO und HANA) aufgesetzt. Das Ergebnis unter der Haube ist ein Flickenteppich aus verschiedenen Motoren und Ansätzen ²⁷. Infolgedessen ist die technische Architektur von IBP nicht elegant - es handelt sich um eine Sammlung von Komponenten, die sich nicht natürlich “mischen”, und die eine intensive Integrationsarbeit erfordern. Selbst die eigene Dokumentation von SAP räumt die hohe Komplexität und den Bedarf an erstklassigen Systemintegratoren (und erheblicher Zeit) ein, um alles reibungslos zum Laufen zu bringen ²⁸. Auf der Technologiefront setzt IBP stark auf SAP HANA, eine In-Memory-Spalten-Datenbank, um Echtzeitleistung zu erreichen. HANA ist zwar schnell, aber auch teuer - die Speicherung großer Planungsdaten ausschließlich im RAM ist inhärent kostspielig (RAM ist etwa 100x teurer pro TB als Festplattenspeicher) ¹⁰. Das bedeutet, dass die Skalierung von IBP auf sehr große Supply-Chain-Datensätze erhebliche Infrastrukturkosten verursacht, und wenn die Daten den Speicher übersteigen, kann die Leistung einbrechen. SAP hat begonnen, einige Machine-Learning-Funktionen hinzuzufügen (z.B. “Demand Driven MRP” und IBP for Demand hat einige ML-Prognoseoptionen), aber diese sind meist optionale Add-Ons mit begrenzter Transparenz. Es gibt keine Anzeichen dafür, dass SAPs ML den Alternativen überlegen ist; tatsächlich hat kein SAP-Algorithmus in unabhängigen Prognosewettbewerben eine Rolle gespielt. Zusammenfassend lässt sich sagen, dass SAP IBP funktionsreich und unternehmenserprobt ist - es wird alle Funktionen abdecken - aber aus technischer Sicht ist es ein gemischter Beutel: In-Memory-Geschwindigkeit gepaart mit älterer Logik, viel Komplexität aus fusionierten Produkten und keine klare technische Innovation in Prognose oder Optimierung über das hinaus, was die erworbenen Teile bereits getan haben. Unternehmen wählen es oft wegen der Integration mit SAP ERP und nicht wegen der Optimierungsexzellenz an sich.
Blue Yonder – Ehemaliger Marktführer wird zum Flickenteppich. Blue Yonder (ehemals JDA Software) bietet eine vollständige Suite, die Prognose, Lieferplanung, Merchandising und Ausführung umfasst. Es ist das Ergebnis von vielen Jahren M&A, einschließlich der Übernahme von i2 Technologies (Supply-Chain-Planung), Manugistics und des AI-Startups Blue Yonder (dessen Namen es übernommen hat) unter anderem ²⁹. Leider ist Unternehmenssoftware nicht einfach die Summe ihrer Teile: Unter der einheitlichen Marke Blue Yonder liegt ein Sammelsurium von Produkten (viele davon ziemlich veraltet), die locker zusammengefügt sind ²⁹. Aus technischer Sicht reichen die Lösungen von Blue Yonder von altmodischen deterministischen Prognosemotoren bis hin zu Bestandsoptimierungsmodulen, die sich in den letzten 15+ Jahren grundlegend nicht verändert haben. Das Unternehmen bewirbt stark die “AI” und “ML” Fähigkeiten seiner Luminate Plattform, aber Details sind spärlich. Tatsächlich deuten die wenigen öffentlichen Artefakte, die wir finden können - wie Open-Source-Projekte und Patente, die dem Data-Science-Team von Blue Yonder gutgeschrieben werden - darauf hin, dass sie ziemlich traditionelle Methoden verwenden (z.B. Zeitreihen-Feature-Extraktion, ARMA und lineare Regressionsmodelle) ³⁰. Diese Techniken sind in Ordnung, aber es handelt sich um jahrzehntealte Ansätze, die oft von neueren Methoden übertroffen werden. Es scheint, dass Blue Yonders viel gepriesene AI einfach neu verpackte Regression und Heuristiken sein könnte. Ohne transparente Fallstudien oder technische Arbeiten muss man davon ausgehen, dass Blue Yonders Behauptungen von “revolutionärer AI-Prognose” Marketing-Fluff sind. Darüber hinaus ist die Integration all seiner erworbenen Komponenten eine laufende Herausforderung - viele Kunden bemerken Schwierigkeiten bei der Umsetzung des “End-to-End”-Versprechens, weil die Module (Nachfrage, Lieferung, Erfüllung usw.) nicht ohne erhebliche Anpassungen natürlich ineinander greifen. In-Memory vs. auf Festplatte? Blue Yonder bewirbt keine vollständige In-Memory-Architektur wie einige andere; Teile des Systems laufen wahrscheinlich auf Standard-Relationaldatenbanken. Dies könnte tatsächlich eine Rettung in Bezug auf die Kosten sein, aber es bedeutet auch, dass die Leistung nachlassen kann, wenn die Daten aggregiert werden (z.B. haben ihre älteren Systeme oft Batch-Planungsläufe verwendet). Zusammenfassend ist Blue Yonder eine mahnende Geschichte: Einst ein Branchenführer, bietet es jetzt eine breite, aber technisch inkonsistente Suite. Seine Stärken liegen in der Branchenerfahrung und einem breiten Funktionsumfang, aber seine Schwächen sind veraltete Technik unter einem frischen Anstrich und ein Mangel an glaubwürdigen Beweisen für seine neuen “AI”-Fähigkeiten.

(Hinweis: Andere Anbieter wie Infor (mit den Legacy-Komponenten GT Nexus und Mercia), GAINS Systems (ein weiterer Spezialist für Bestandsoptimierung), John Galt Solutions (Mittelstandsplanung der Nachfrage), Relex Solutions (Einzelhandelsprognose mit einem In-Memory-Engine), usw., existieren ebenfalls. Im Interesse der Fokussierung haben wir die prominentesten oder lehrreichsten Beispiele oben eingestuft. Die gleichen skeptischen Kriterien gelten für diejenigen, die nicht einzeln eingestuft wurden: zum Beispiel verwendet Relex ein In-Memory-, OLAP-Würfel-Design - großartig für die Geschwindigkeit, aber garantiert 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 Grundfunktionen, aber wenig öffentlich dokumentiert über neuartige Techniken. Jeder Anbieter, der technische Details oder Beweispunkte nicht offen teilt, würde in jedem Fall in dieser Studienmethodik niedrig eingestuft werden.)*

Detaillierte technische Analyse

In diesem Abschnitt gehen wir tiefer auf spezifische technische Aspekte der Top Supply Chain Optimierungssoftware ein und konzentrieren uns auf vier Schlüsselbereiche: Prognose & KI, Automatisierungsfähigkeiten, Systemarchitektur und Integration von Modulen. Alle Analysen basieren auf veröffentlichten technischen Informationen oder konkreten Beweisen und vermeiden ausdrücklich jegliche Marketing-Sprache.

Prognose- & KI-Fähigkeiten

Moderne Supply-Chain-Planung hängt von der Genauigkeit der Nachfrageprognose ab, doch Behauptungen über Prognoseüberlegenheit sind weit verbreitet und oft unbegründet. Unsere Untersuchung ergab, dass die Prognosefähigkeiten der meisten Anbieter die standardisierten statistischen Methoden nicht signifikant übertreffen - trotz Schlagwörtern wie “KI” oder “maschinelles Lernen” in ihrem Marketing.

Nachgewiesene Leistung vs. Hype: Unter allen Anbietern ist Lokad der einzige mit einer nachweisbaren Weltklasse-Prognosebilanz, dank des offenen M5-Wettbewerbs. Lokad demonstrierte seine probabilistische Prognosefähigkeit, indem es bei der SKU-Level-Genauigkeit an der Spitze rangierte ¹. Dies verleiht Lokads Behauptungen einer besseren Prognosegenauigkeit Glaubwürdigkeit. Im krassen Gegensatz dazu hat kein anderer Anbieter vergleichbare Ergebnisse auf einem unabhängigen Benchmark veröffentlicht. Zum Beispiel werben einige Anbieter mit proprietären Algorithmen (einer nennt seine Methode “Procast”), die eine überlegene Genauigkeit behaupten, doch diese Methoden waren in den Top-Rängen des M5-Wettbewerbs abwesend ³². In der Praxis sind akademische Open-Source-Ansätze (wie Prof. Rob Hyndmans R-Prognosepakete) wahrscheinlich genauso gut oder besser als die meisten geschlossenen proprietären Engines ¹³. Daher sollte jede Behauptung eines Anbieters von “branchenbester Prognosegenauigkeit” ohne öffentlichen Nachweis als nicht unterstützt behandelt werden.
KI- und Maschinelles Lernen Behauptungen: Wir haben extreme Skepsis auf AI/ML-Buzz angewendet. Anbieter wie o9 Solutions und Blue Yonder verwenden in ihren Broschüren häufig Begriffe wie “AI/ML-getriebene Prognose”. Bei der Suche nach Substanz fanden wir jedoch wenig. Im Fall von o9 sind ihre Behauptungen, dass das graphenbasierte “Enterprise Knowledge Graph” bessere Prognosen liefert, zweifelhaft und ohne wissenschaftliche Unterstützung ²⁵. Blue Yonder preist ebenfalls KI an, liefert aber keine Details - der einzige Einblick in ihre Technik kommt von einigen Open-Source-Repositories, die die Verwendung von ziemlich gewöhnlichen Zeitreihentechniken (ARMA, lineare Regression, Feature-Engineering) zeigen ³⁰. Es gibt keine Beweise für Deep Learning, fortgeschrittene probabilistische Methoden oder andere moderne KI, die ihr Marketing rechtfertigen würden. ToolsGroup hat Maschinenlernkonzepte integriert (sie sprechen von “Nachfrageerfassung” mit maschinellem Lernen), aber wieder keine von Fachkollegen überprüften Studien oder Wettbewerbsgewinne, um es zu validieren ²⁰. Tatsächlich deutet die Paarung von ToolsGroup’s “probabilistischer Prognose” mit alten Metriken wie MAPE darauf hin, dass ihre KI mehr Buzz als Durchbruch ist ¹⁹. Fazit: Außerhalb von Lokad (und in gewissem Maße SAS, das zeitbewährte statistische Modelle verwendet), bleibt die Prognose in den meisten Supply-Chain-Softwareprodukten auf bekannten Methoden (exponentielles Glätten, Regression, vielleicht einige baumbasierte ML) und nicht auf irgendeinem proprietären genialen KI. Anbieter, die wirklich neuartige Algorithmen haben, würden diese öffentlich demonstrieren. Das Fehlen einer unabhängigen Validierung ist aufschlussreich.
Probabilistische vs. deterministische Ansätze: Ein bemerkenswerter technischer Unterschied besteht darin, ob ein Anbieter probabilistische Prognosen (Vorhersage einer vollständigen Verteilung von Nachfrageergebnissen) unterstützt oder sich auf Einzelpunktprognosen beschränkt. Lokad ist seit 2012 ein starker Befürworter vollständiger Wahrscheinlichkeitsverteilungen und optimiert Entscheidungen (wie Lagerbestände) direkt auf der Grundlage der probabilistischen Prognosen. ToolsGroup behauptet ebenfalls, probabilistische Prognosen zu erstellen (wahrscheinlich über Monte-Carlo-Simulationen der Nachfrage). Wir haben jedoch festgestellt, dass viele, die “probabilistisch” behaupten, intern immer noch auf deterministische Metriken und Prozesse zurückgreifen. So ist beispielsweise ToolsGroups Marketingaussage, dass die MAPE durch den Einsatz probabilistischer Modelle reduziert wird, inkohärent, da die MAPE nicht einmal auf einem probabilistischen Prognoseergebnis berechnet werden kann ¹⁹. Dies deutet darauf hin, dass ihr Prozess letztendlich wieder auf eine Punktprognose (Mittelwert oder Median) für die Bewertung zurückfällt, was den probabilistischen Nutzen untergräbt. Andere Anbieter wie SAP, Oracle, Blue Yonder haben begonnen, probabilistische Begriffe zu erwähnen (SAP IBP hat jetzt “statistische Ensembles” und Konfidenzintervalle), aber auch hier sind ihre Benutzeroberflächen und Berichte oft standardmäßig auf Einzelzahlprognosen mit traditionellen Fehlermetriken eingestellt. Die Umsetzung echter probabilistischer Prognosen erfordert ein Umdenken der KPIs (Verwendung von Pinball-Verlust, CRPS oder Service-Level-Erfüllung anstelle von MAPE). Wir haben keine Beweise dafür gefunden, dass irgendein 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 der Realität voraus ist - sie erzeugen möglicherweise einige Verteilungen hinter den Kulissen, aber die Planer betrachten immer noch Punktprognosezahlen und klassische KPIs, was auf eine begrenzte Übernahme des Paradigmas hindeutet.
Prognosemetriken und -bewertung: Ein wichtiger Aspekt der technischen Strenge ist, wie ein Anbieter die Prognosequalität bewertet. Ein Warnsignal ist die fortgesetzte Abhängigkeit von Metriken wie MAPE, WAPE oder Bias als einzige Erfolgsmaßstäbe, insbesondere wenn der Anbieter behauptet, KI- oder probabilistische Methoden zu verwenden. Denn diese Metriken fördern konservative, mittlere Prognosen und können manipuliert werden (zum Beispiel durch das Beschneiden von Höchst- und Tiefstwerten). Wir haben beobachtet, dass Anbieter mit wirklich fortschrittlicher Prognose eher über Servicelevels oder Geschäftsergebnisse (z.B. Ausfallwahrscheinlichkeit, Kostenauswirkungen) statt nur über MAPE sprechen. Lokad betont beispielsweise die Reduzierung von “Fehlern in Dollar” und die Abstimmung von Prognosen mit der Entscheidungsoptimierung ³³. Im Gegensatz dazu heben ToolsGroup, Blue Yonder und viele andere in ihren Fallstudien immer noch prozentuale Fehler hervor, was auf eine veraltete Denkweise hindeutet. Wenn eine Anbieterdokumentation oder Demo stark auf MAPE/WAPE-Dashboards setzt, ist dies ein Zeichen dafür, dass ihre Prognose wahrscheinlich traditionell ist. Tatsächlich wurde die Inkonsistenz von ToolsGroup in Bezug auf MAPE bereits bemerkt ¹⁹. Kurz gesagt: Wirklich hochmoderne Prognosen in der supply chain würden sich durch probabilistische Metriken und eine Validierung in der realen Welt auszeichnen - Eigenschaften, die bei den meisten Anbietern fehlen.

Automatisierung & Workflow-Fähigkeiten

Die Optimierung der supply chain geht nicht nur um Algorithmen; es geht auch darum, wie automatisiert und “hands-free” die Software den Planungsprozess steuern kann. Wir haben die Behauptungen und Dokumentationen jedes Anbieters auf Hinweise auf Automatisierung, API-Integration und Unterstützung für autonome Entscheidungsfindung untersucht.

Lokad: Automatisierung ist eines der Markenzeichen von Lokad. Die gesamte Lösung basiert auf einer domänenspezifischen Sprache (Envision), die es den supply chain-Planern ermöglicht, ihre Logik und Entscheidungen in Skripten zu kodieren, die dann automatisch nach Zeitplan ausgeführt werden. Lokad dokumentiert klar seine Datenpipelines und den Workflow-Manager, der Daten aktualisiert und Entscheidungen (Prognosen, Nachbestellungen usw.) ohne manuelle Eingriffe neu berechnet ³⁴ ³⁵. Sie sprechen sogar von “hochautomatisierten Setups” für ~100 supply chains in Produktion ³⁵, was bedeutet, dass die Software Daten zieht, Prognosen erstellt und Entscheidungen (wie Kaufauftragsvorschläge) in einem lichtlosen Modus ausgibt. Darüber hinaus bietet Lokad APIs für den Datenupload und den Ergebnisdownload an und hat ein Konzept für einen “AI Pilot” zur Automatisierung von Büroaufgaben ³⁶. All dies deutet auf ein sehr hohes Maß an echter Automatisierung hin - die Rolle des Benutzers besteht hauptsächlich darin, den Code/die Parameter zu überwachen und zu verfeinern, nicht darin, für jeden Plan manuell Tasten 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 eine schnelle Szenarioanalyse und Zusammenarbeit konzipiert und nicht für eine vollständig automatisierte Planung. Das Konzept der “gleichzeitigen Planung” geht davon aus, dass alle auf dem gleichen Datensatz mit Echtzeit-Updates arbeiten, aber es erfordert in der Regel immer noch menschliche Planer, um Szenarien zu bewerten und Entscheidungen zu treffen. Kinaxis unterstützt jedoch die Automatisierung in bestimmten Bereichen: Es kann Daten von ERP-Systemen in nahezu Echtzeit aufnehmen, seine Supply/Demand-Abgleichalgorithmen kontinuierlich ausführen und Benutzer mit Warnungen oder Ausnahmemeldungen alarmieren, wenn Dinge außer Kontrolle geraten. Es stellt Funktionalität über APIs bereit und hat Skripting (in Form von konfigurierbaren Algorithmen und Makros in seiner Umgebung) für Power-User. Allerdings positioniert sich Kinaxis im Allgemeinen als Entscheidungsunterstützung, nicht als eine Black-Box, die automatisch Aufträge freigibt. Der Anbieter behauptet nicht lautstark “autonome supply chain”; stattdessen konzentriert er sich darauf, Planer effizienter zu machen. Dies ist eine ehrliche Haltung. Es bedeutet, dass RapidResponse out-of-the-box immer noch Menschen in der Schleife erwartet - was eine Einschränkung sein kann, wenn man ein “selbstfahrendes” supply chain-System sucht. Technisch gesehen kann Kinaxis tief integriert werden (zum Beispiel integriert es oft mit SAP ERP, um genehmigte Pläne auszuführen), aber ein unbeaufsichtigter End-to-End-Betrieb würde eine Menge benutzerdefinierter Konfiguration erfordern. Wir haben keine Beweise dafür gefunden, dass Kinaxis AI-gesteuerte Entscheidungsempfehlungen anbietet (ihre Stärke liegt eher in der schnellen Berechnung von von Benutzern definierten Szenarien).
o9 Solutions: o9 vermarktet stark Konzepte wie einen “digitalen Zwilling” der Organisation und KI, die Empfehlungen geben kann. Sie sprechen von “Automatisierung” im Kontext ihrer digitalen Assistenten - vermutlich Bots, die Einblicke liefern oder einige Aufgaben erledigen können. In Ermangelung konkreter technischer Dokumentation ist es jedoch schwierig zu bestimmen, wie viel davon real ist. Wir konnten keine spezifischen Angaben finden wie “o9 kann Nachbestellungen automatisch über API auf Basis seiner Pläne freigeben” oder “o9 verwendet Verstärkungslernen, um Parameter selbstständig anzupassen.” Die Unklarheit der Automatisierungsgeschichte von o9 ist besorgniserregend: viel hochrangiges Gerede, wenig Detail. Angesichts seiner In-Memory-EKG-Grundlage vermuten wir, dass o9 in der Lage ist, Echtzeit-Datenupdates und Neuberechnungen durchzuführen, aber wahrscheinlich immer noch auf Benutzer angewiesen ist, um zu konfigurieren, was mit diesen Informationen zu tun ist. Ohne glaubwürdige Referenzen betrachten wir die “Autonomie”-Behauptungen von o9 als nicht verifiziert. Es ist möglich, o9 über APIs in Ausführungssysteme zu integrieren (es handelt sich um eine moderne Software, daher sollte eine API-Integration existieren), aber wie viel Entscheidungsfindung wirklich durch KI in o9 automatisiert wird, ist unklar. Die Beweise deuten darauf hin, dass die aktuelle Automatisierung von o9 mehr darauf abzielt, die Analytik zu beschleunigen (z.B. sofortige Was-wäre-wenn-Szenarien) als die Entscheidungsausgaben zu automatisieren.
Blue Yonder: In den letzten Jahren hat Blue Yonder (insbesondere seit der Übernahme durch Panasonic) den Begriff “autonome Supply Chain” vorangetrieben, was auf ein System hindeutet, das mit minimaler menschlicher Intervention betrieben werden kann. Sie haben einige Komponenten, wie den Luminate Control Tower, der KI verwendet, um Störungen zu erkennen und möglicherweise Reaktionen auszulösen. Angesichts des bestehenden Kerns von Blue Yonder ist es jedoch wahrscheinlich, dass jegliche Autonomie durch das Aufschichten von RPA (Robotic Process Automation) oder einfachen KI-Agenten auf bestehende Module erreicht wird. Zum Beispiel könnte die Bedarfsplanung von Blue Yonder eine Prognose erstellen, und eine “KI”-Schicht könnte diese automatisch auf der Grundlage von Echtzeitverkäufen (Demand Sensing) anpassen oder einen Alarm auslösen, wenn sie abweicht. Aber vollautomatische Planung (wie das automatische Ausstellen von Bestellungen, das automatische Anpassen von Lagerbestandspolitiken) ist wahrscheinlich selten bei BY-Lösungen - Kunden haben in der Regel immer noch Planer, die Aktionen prüfen und genehmigen. Der Mangel an detaillierter technischer Literatur darüber, wie Blue Yonder Entscheidungen automatisiert, ist aufschlussreich. Wenn sie einen wirklich autonomen Planer hätten, würden sie Erfolgsgeschichten oder technische Blogs darüber veröffentlichen. Stattdessen veröffentlichen sie hauptsächlich Marketing-Webinare. Daher schließen wir, dass Blue Yonder zwar einen gewissen Grad an Automatisierung ermöglicht (wie Batch-Jobs, Aktualisierungen von Plänen, vielleicht geschlossene Integration in Ausführungssysteme), aber in diesem Bereich nicht nachweislich führend ist. Es verwendet wahrscheinlich ähnliche ausnahmebasierte Planung wie ältere Systeme (nur mit einer neuen KI-Schicht auf dem Warnsystem).
ToolsGroup: ToolsGroup hat sich historisch gesehen auf “Powerfully Simple Automation” spezialisiert. Sie behaupteten, dass ihr System über längere Zeiträume im “lights-out”-Modus laufen könnte, wobei Planer nur bei Ausnahmen hinzugezogen werden. Tatsächlich war die Philosophie von ToolsGroup, das System täglich automatisch neu zu prognostizieren und neu zu planen, um sich an neue Daten anzupassen. Zu ihrem Verdienst haben viele ToolsGroup-Kunden von einer reduzierten Planerbelastung berichtet, da die Software die Lagerbestandsziele selbst anpasst und Bestellungen automatisch empfiehlt. ToolsGroup verfügt auch über ein Integrationstoolkit, um genehmigte Bestellungen an ERP-Systeme zu übermitteln. Aufgrund der zuvor genannten Widersprüche haben wir jedoch Zweifel an der Intelligenz dieser Automatisierung. Es könnte einfach jeden Tag die gleiche Formel anwenden und markieren, wenn etwas nicht stimmt (Ausnahmeverwaltung). ToolsGroup bietet zwar eine API und unterstützt geplante Läufe, so dass technisch gesehen die Infrastruktur für die Automatisierung vorhanden ist. Die Frage ist die Qualität der automatisierten Entscheidungen. Sie erwähnen oft “Selbstabstimmung” - was darauf hindeutet, dass die Software die Parameter des Prognosemodells automatisch anpasst, wenn neue Daten eintreffen ³⁹. Wenn das wahr ist, ist das eine nützliche Automatisierung (die Notwendigkeit einer ständigen menschlichen Neukonfiguration entfällt). Ohne unabhängige Bewertung sagen wir vorsichtig, dass ToolsGroup hohe Automatisierung bei routinemäßigen Planungsaufgaben bietet, aber der Mangel an Transparenz macht es schwer zu beurteilen, wie “intelligent” diese Automatisierung ist (z.B., lernt sie wirklich und verbessert sich, oder folgt sie nur voreingestellten Regeln?).
Andere Anbieter: Die meisten anderen Anbieter unterstützen Standardautomatisierungsfunktionen: Datenintegration über APIs oder Datei-Batch, geplante Planungsläufe und einige ausnahmebasierte Workflows. So kann beispielsweise SAP IBP so eingestellt werden, dass es jeden Monat automatisch eine Prognose erstellt und Planungsergebnisse bereitstellt, aber in der Regel überprüft ein Planer die Ausgabe. Anaplan konzentriert sich weniger auf Automatisierung - es ist eher eine manuelle Modellierungsplattform, obwohl Sie seine API verwenden können, um Daten zu pushen/ziehen und vielleicht bestimmte Berechnungen zu automatisieren. Dassault/Quintiq kann so programmiert werden, dass es Optimierungsroutinen nach einem Zeitplan ausführt (und Quintiqs DSL bedeutet, dass Sie benutzerdefinierte automatische Verhaltensweisen programmieren können), aber wiederum ist es so autonom, wie der Implementierer es programmiert. GAINS, Relex, Netstock und andere Nischenanbieter werben alle für “End-to-End-Automatisierung” bei der Nachfüllung - normalerweise bedeutet das, dass sie automatisch Bestellungen oder Empfehlungen für Filialübertragungen generieren können. Der entscheidende Unterschied liegt darin, wie viel Aufsicht benötigt wird: Ein wirklich autonomes Planungssystem würde Menschen nur für ungewöhnliche Situationen heranziehen und seine Entscheidungen mit Begründungen dokumentieren. Wir haben keinen Anbieter gefunden, der dieses Ideal bisher vollständig erreicht. Sie benötigen entweder Menschen, um zu justieren und zu genehmigen (in den meisten Fällen), oder sie automatisieren nur die einfachsten Entscheidungen und lassen den Rest.

Zusammenfassung für Automatisierung: Nur wenige Anbieter (insbesondere Lokad) legen öffentlich ein Automatisierungsframework dar, das unbeaufsichtigte, API-gesteuerte Planungszyklen ermöglicht. Andere haben die technischen Mittel zur Automatisierung, verlassen sich aber immer noch auf Menschen, um die Schleife zu schließen. Wir stellen auch fest, dass einige Anbieter in den letzten Jahrzehnten den Fokus von der vollständigen Automatisierung auf das “Ausnahmemanagement” verlagert haben - das ist im Grunde ein halbautomatisierter Ansatz, bei dem die Software tut, was sie kann, und den Rest für Menschen markiert ³⁸. Dieser Ansatz, obwohl praktisch, kann eine Krücke für Software sein, die nicht robust genug ist, um ihr vollständig zu vertrauen. Unsere skeptische Sichtweise ist: Wenn ein Anbieter nicht erklären kann, wie er Entscheidungen automatisiert (welche Algorithmen, welche Auslöser, welche API-Aufrufe), dann ist seine “Automatisierung” wahrscheinlich nur Marketing-Gerede.

Systemarchitektur & Skalierbarkeit

Die Architektur unter der Haube - insbesondere die Verwendung von In-Memory-Computing im Vergleich zu On-Disk und allgemeine Designentscheidungen - hat enorme Auswirkungen auf die Skalierbarkeit, Kosten und Leistung einer Supply-Chain-Software. Wir haben den Kerntechnologiestack jedes Anbieters mit einem Fokus darauf untersucht, wie sie große Datenmengen und komplexe Berechnungen handhaben.

In-Memory-Computing - Vor- und Nachteile: Mehrere der führenden Anbieter setzen auf eine In-Memory-Architektur, d.h. die Software lädt die meisten oder alle relevanten Daten in den RAM für einen schnellen Zugriff während der Berechnungen. Dazu gehören Kinaxis, Anaplan, o9, SAP HANA (IBP), Relex und möglicherweise Quintiq (für die Lösung von Szenarien). Der Vorteil ist die Geschwindigkeit: Der Zugriff auf den RAM ist um Größenordnungen schneller als auf die Festplatte. Zum Beispiel legt Kinaxis’s Engine alle Daten im Speicher ab, um sofortige Neuberechnungen von Szenarien und direkte algorithmische Operationen auf dem Datensatz zu ermöglichen ⁹. SAP’s HANA wurde mit der Prämisse entwickelt, dass Analysen auf Live-Daten im Speicher für Echtzeitergebnisse stattfinden sollten ⁴⁰ ⁴¹. Es gibt jedoch ein grundlegendes Problem mit einem reinen In-Memory-Design: Kosten und Skalierbarkeit. Speicher (RAM) ist extrem teuer im Vergleich zu Speicher. 1 TB RAM kann 100x mehr kosten als 1 TB Festplatte ¹⁰. Und die Speichergröße auf Servern ist physisch begrenzt (typische Systeme haben höchstens 0,5-2 TB RAM, während Multi-Terabyte- oder Petabyte-Datensätze in großen Lieferketten üblich sind). In den letzten Jahren haben die erwarteten drastischen Preisstürze für RAM nicht stattgefunden - die RAM-Preise und -Kapazitäten sind ziemlich stagniert ⁴². Das bedeutet, dass jedes System, das alle Daten im Speicher benötigt, mit explodierenden Infrastrukturkosten konfrontiert wird, wenn die Daten wachsen, oder auf eine harte Grenze stößt, wo es die Daten einfach nicht unterbringen kann. Wir bezeichnen eine starke Abhängigkeit vom In-Memory-Design als architektonischen Fehltritt für große Lieferketten, es sei denn, er wird abgemildert.
Speicher vs. Festplatte: Moderne Praktiken: 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 - halten Sie heiße Daten im Speicher und kalte Daten auf SSDs, etc. ⁴³ ⁴⁴. Einige Supply-Chain-Software haben damit begonnen, dies zu übernehmen. Zum Beispiel verwendet Lokad explizit “Spill to Disk”-Techniken in seiner Cloud-Infrastruktur. Ihr CTO beschrieb, wie sie einen 10-Milliarden-Zeilen-Einzelhandelsdatensatz mit etwa 37 GB RAM und schnellem NVMe SSD für den Überlauf handhaben ⁴⁵ ³. Sie erreichen nahezu RAM-Leistung, indem sie Dateien im Speicher abbilden und nur die heißesten Daten im RAM behalten, wobei die Software intelligent nach Bedarf wechselt ⁴⁶ ⁴⁷. Dieser Ansatz führt zu enormen Kosteneinsparungen - z.B. kann man für den Preis von 18 GB High-End-RAM 1 TB NVMe SSD kaufen ³, so ist es 50x billiger pro Byte und dabei nur ~6x langsamer im Rohzugriff, ein oft lohnender Kompromiss. Keiner der auf In-Memory zentrierten Anbieter (Kinaxis, SAP, o9, etc.) hat eine solche adaptive Speicherverwaltung öffentlich beschrieben, was darauf hindeutet, dass ihre Lösungen einfach viel RAM benötigen oder eine Datenaggregation zur Anpassung erfordern. Anaplan ist bekannt dafür, dass es mit Modellgrößenlimits zu kämpfen hat - einige Kunden stoßen an die Speichergrenzen seines Hyperblocks und müssen Modelle aufteilen. Kinaxis benötigt wahrscheinlich auch mehrere vernetzte Server für sehr große Daten (sie haben ein Konzept der Datenverteilung, aber innerhalb jedes Knotens ist es im Speicher vorhanden). SAP HANA kann auf die Festplatte auslagern (es hat Erweiterungsknoten), aber die Leistung leidet. Das Fazit: Ein starres In-Memory-Design ist ein Warnsignal für die Skalierbarkeit. Es kann hervorragend für kleine bis mittlere Daten funktionieren, aber wenn die Lieferkette wächst (denken Sie: detaillierte SKU-Store-Day-Level-Planung für einen globalen Einzelhändler), steigen die Kosten und die Leistungsrisiken. Moderne Technik bevorzugt eine Mischung aus Speicher- und Festplattenverwendung, um Geschwindigkeit und Kosten auszugleichen, und Anbieter, die das nicht tun, hinken hinterher.
Tech Stack und Komplexität: Jenseits des Speichers ist ein weiteres architektonisches Element der gesamte Tech Stack - monolithisch vs. Mikrodienste, Einsatz moderner Programmiersprachen usw. Ohne zu sehr ins Detail zu gehen, haben wir festgestellt, dass ältere Anbieter (SAP APO/IBP, Blue Yonder) auf eher monolithischen, veralteten Stacks laufen, während neuere (o9, Anaplan) ihr eigenes Ding von Grund auf mit neuerer Technologie gebaut haben. Zum Beispiel beinhaltet der Kern von SAP IBP immer noch Motoren aus den 2000er Jahren (wie den APO-Optimizer), die jetzt in einer HANA/Cloud-Schicht eingebettet sind. Das führt zu Komplexität und potenzieller Ineffizienz (mehrere Abstraktionsebenen). Blue Yonder hat ähnlicherweise viel Legacy-Code aus den i2- und JDA-Tagen. Kinaxis ist etwas einzigartig - es ist alt (gestartet in den 90ern), aber sie haben kontinuierlich in ihren eigenen Datenbank-Kernel refaktorisiert; dennoch ist es ein proprietärer Stack, den nur sie verwenden. Anaplan hat eine sehr effiziente Berechnungsengine (in Java) für seinen spezifischen Anwendungsfall (Hyperblock) gebaut, und sie ist ziemlich optimiert für diesen Zweck - aber sie ist nicht offen, und man muss mit ihren Einschränkungen leben (z.B. keine SQL-Abfragen, begrenzte algorithmische Komplexität, da es eher zellenbasierte Berechnungen sind). Die Plattform von o9 beinhaltet eine Mischung aus Technologien (wahrscheinlich eine NoSQL/Graph-Datenbank, vielleicht Spark oder ähnliches für einige ML usw.), was sie komplex, aber theoretisch flexibel macht.
Hardware und Cloud: Ein bemerkenswerter Trend ist das Cloud-native Design. Viele Anbieter bieten ihre Software jetzt als SaaS oder zumindest Cloud-gehostet an, aber nicht alle sind wirklich Cloud-native. Zum Beispiel sind Anaplan und o9 Multi-Tenant SaaS (von Grund auf für die Cloud entwickelt). Lokad ist nativ in der Cloud (es läuft auf Microsoft Azure und weist dynamisch Ressourcen zu). SAP IBP ist Cloud-gehostet, aber im Grunde ist jeder Kunde eine isolierte Instanz auf HANA (nicht Multi-Tenant im gleichen Sinne). ToolsGroup, Blue Yonder haben SaaS-Angebote, aber oft sind diese nur ihre On-Prem-Software, die von ihnen in der Cloud verwaltet wird. Warum ist das technisch wichtig? Cloud-native Architekturen sind in der Regel elastischer - sie können Rechenleistung hochfahren, wenn sie benötigt wird (für einen großen Planungslauf) und danach wieder herunterfahren, möglicherweise Kosten kontrollierend. Nicht-Cloud-Systeme erfordern oft den Kauf von Spitzenkapazitäten, auch wenn sie nur gelegentlich genutzt werden. Außerdem könnten Cloud-native Systeme besser mit anderen Cloud-Diensten integrieren (zum Beispiel, Anschluss an einen Cloud-ML-Dienst oder Data Lake). Nach unseren Erkenntnissen scheinen die am meisten Cloud-nativen, skalierbaren Lösungen Lokad und o9 (und vielleicht Anaplan) zu sein, während andere aufholen. Allerdings bedeutet Cloud-native allein nicht gute Architektur - o9 ist Cloud-native, aber wir haben seinen speicherintensiven Ansatz in Frage gestellt; SAP IBP auf der Cloud zu sein, beseitigt nicht seine Komplexitätsprobleme.
Gleichzeitigkeit und Echtzeit-Bedürfnisse: Eine architektonische Überlegung ist, wie das System gleichzeitige Benutzer und Echtzeit-Updates handhabt. Kinaxis glänzt hier: Es wurde entwickelt, um mehreren Planern zu ermöglichen, gleichzeitig Szenarioplanung auf demselben Datensatz durchzuführen. Das erfordert eine sorgfältige Datenversions- und Sperrlogik - die Kinaxis durch ihren Verzweigungsmechanismus ⁸ erreicht hat. Die meisten anderen Tools folgten traditionell einem Batch-Paradigma (planen, veröffentlichen, dann separat zusammenarbeiten). Jetzt fügen viele gleichzeitige Planungsfunktionen hinzu. Anaplan ermöglicht es mehreren Personen, gleichzeitig in verschiedenen Teilen des Modells zu arbeiten (da es im Grunde genommen zellenbasiert ist wie Google Sheets). SAP IBP hat eine “Microsoft Excel-ähnliche” Benutzeroberfläche eingeführt, die Daten vom Server bei Bedarf aktualisieren kann, aber echte Gleichzeitigkeit (mehrere Benutzer bearbeiten gleichzeitig den gleichen Plan) ist begrenzt. o9 unterstützt wahrscheinlich eine gewisse Stufe von Gleichzeitigkeit, da es einen Wissensgraphen hat (mehrere Benutzer können verschiedene Knoten anpassen). Bei der Bewertung der technischen Verdienste deutet ein System, das wirklich in Echtzeit mit vielen Benutzern arbeiten kann, auf eine robuste Architektur hin. Kinaxis und Anaplan punkten hier. Es ist nicht so, dass andere es nicht können, aber oft machen es ihre älteren Architekturen schwer - was entweder zu langsamer Leistung führt oder sequenzielle Prozesse erzwingt.

Zusammenfassung zur Architektur: Wir haben ein Muster identifiziert: speicherzentrierte Designs (Kinaxis, Anaplan, o9, Relex, SAP HANA) liefern Geschwindigkeit, aber auf Kosten von Skalierbarkeit und $$, während hybride Designs (Lokads Spill-to-Disk, vielleicht Tools, die moderne Datenbanken verwenden) skalierbarer und kosteneffizienter sind. Eine klare Warnung ist jeder Anbieter, der darauf besteht, dass alles im RAM sein muss, um zu funktionieren - dies gilt heute angesichts der Fortschritte in der SSD-Geschwindigkeit und des verteilten Rechnens als veralteter Ansatz ⁴³ ⁴⁴. Wir weisen auch darauf hin, dass die Architektur von Anbietern, die aus mehreren Übernahmen hervorgegangen sind (wie SAP, Blue Yonder), dazu neigt, übermäßig komplex zu sein und viel Abstimmung zu erfordern. Einfachere, hausgemachte Architekturen (Kinaxis’ einzelner Codebase, Anaplans einzelner Motor, Lokads einzelner Motor) neigen dazu, kohärenter zu sein und daher technisch einfacher zu warten. Bei der Bewertung einer Supply-Chain-Software sollte man sich fragen: Hat der Anbieter etwas darüber veröffentlicht, wie ihre Software gebaut ist (Mikrodienste? benutzerdefinierte DB? Verwendung von ML-Bibliotheken? usw.). Ein Mangel an jeglicher technischer Diskussion könnte bedeuten, dass die Architektur nur eine Blackbox ist - oft ein Hinweis auf ein Erbe oder mangelndes Vertrauen in ihre Einzigartigkeit.

Integration & Modulkohärenz (Auswirkungen von M&A)

Die Supply-Chain-Planung erstreckt sich typischerweise über mehrere Bereiche (Nachfrageprognose, Bestandsoptimierung, Produktionsplanung usw.). Einige Anbieter bieten eine integrierte Suite an, die organisch gewachsen ist, während andere durch Übernahmen gewachsen sind und neue Module hinzugefügt haben. Wir haben uns angesehen, wie jedes Anbieterlösungsset integriert ist und welche Warnsignale aus ihrer Wachstumsstrategie hervorgehen.

Blue Yonder (JDA) ist das Paradebeispiel für Wachstum durch Übernahme. Wie bereits erwähnt, handelt es sich um eine “willkürliche Sammlung” von Produkten aus verschiedenen Epochen ²⁹. JDA hat i2 übernommen (das selbst mehrere Module hatte), früher Manugistics übernommen, dann RedPrairie (für das Warenhausmanagement), dann das Start-up Blue Yonder für KI. Jedes Stück hatte sein eigenes Datenbankschema, seine eigene Logik. Das Ergebnis: Auch heute teilen sich die Nachfrageplanung, die Lieferplanung und die Bestandsoptimierung von Blue Yonder möglicherweise nicht ein einheitliches Datenmodell - die Integration basiert auf Schnittstellen. Dies ist eine rote Flagge, weil es bedeutet, dass die Implementierung der gesamten Suite im Grunde genommen die Integration mehrerer verschiedener Softwarepakete ist. Wenn die Produkte eines Anbieters nicht wirklich vereinheitlicht sind, stehen die Kunden vor Problemen wie Daten-Synchronisationsverzögerungen, inkonsistenten Benutzeroberflächen und doppelter Funktionalität. Im Fall von Blue Yonder: Einige seiner Module überschneiden sich ehrlich gesagt (nach Übernahmen haben Sie möglicherweise zwei Möglichkeiten, die Bestandsplanung durchzuführen - eine aus dem Manugistics-Erbe und eine aus i2). Das Unternehmen hat Anstrengungen unternommen, dies zu rationalisieren, aber es ist noch nicht vollständig gelöst. In technischer Hinsicht “mischen” sich Unternehmenssoftware nicht magisch wie Flüssigkeiten, wenn Unternehmen fusionieren ²⁹ - es dauert Jahre der Neuentwicklung. Wir haben keine Beweise dafür gesehen, dass Blue Yonder diese Neuentwicklung abgeschlossen hat. Daher ist der Mangel an Kohärenz eine große technische Schwäche.
SAP IBP hat ähnlich erworbene Komponenten kombiniert: Der Kauf von SAF, SmartOps und anderen durch SAP brachte separate Tools mit sich, die SAP dann in den IBP-Schirm integrierte ²⁷. Benutzer haben festgestellt, dass IBP verschiedene Module hat, die sich wie separate Apps anfühlen (zum Beispiel IBP für Nachfrage vs. IBP für Inventar). Die Sicherheitsbestandsoptimierungslogik in IBP stammt wahrscheinlich aus der Übernahme von SmartOps, während das Demand Sensing möglicherweise von SAF oder internen Entwicklungen stammt. Die Integration ist besser als bei Blue Yonder (SAP hat zumindest die Benutzeroberfläche neu geschrieben und alles auf die HANA-Datenbank gelegt), aber trotzdem ist IBP unter der Haube kein einziger Codebase. SAP warnt ausdrücklich, dass die Implementierung von IBP in der Regel mehrere Jahre und Expertenintegratoren erfordert, um alle Module optimal zusammenarbeiten zu lassen ²⁸. Diese Aussage ist an sich schon ein rotes Tuch - sie impliziert mögliche Unstimmigkeiten und Komplexität.
Infor (obwohl nicht in den Top 10 oben) hat auch verschiedene Planungssysteme zusammengeführt (sie hatten Mercias Supply-Chain-Planung und GT Nexus usw. erworben). Das Ergebnis war nie eine wirklich vereinheitlichte Planungsplattform; Infor konzentriert sich eher auf Ausführungssysteme. Es ist also ein weiteres Beispiel, bei dem eine Übernahme kein großartiges integriertes Planungsprodukt hervorgebracht hat.
Dassault (Quintiq): In diesem Fall hat die Übernahme (durch Dassault) nicht dazu geführt, dass Quintiq mit einem anderen Planungstool zusammengeführt wurde - Dassault hat Quintiq mehr oder weniger als eigenständiges Angebot weiterlaufen lassen, das sich auf die Optimierung der Produktion/Planung konzentriert. Daher ist die interne Kohärenz von Quintiq in Ordnung (es wurde intern entwickelt und bleibt so), aber der Nachteil ist, dass es nicht alle Bereiche abdeckt (z.B. keine native Nachfrageprognose, wie angemerkt ¹⁶). Dassaults Portfolio hat andere Produkte (wie Apriso für MES usw.), aber sie sind nicht in irgendeiner tiefgreifenden Weise mit Quintiq integriert. In Bezug auf die Integration ist Quintiq selbstkonsistent, aber funktionell eng. Aus der Sicht eines Benutzers müssen Sie es möglicherweise mit einem anderen Prognosetool integrieren, was zusätzliche Arbeit auf der Kundenseite bedeutet.
Kinaxis wuchs hauptsächlich organisch - es erwarb zwar 2020 ein kleines KI-Unternehmen Rubikloud (für Einzelhandels-KI) und 2022 ein Tool für die Gestaltung von Supply Chains (Castle Logistics), aber das sind relativ neue Entwicklungen und es bleibt abzuwarten, wie sie integriert werden. Historisch gesehen war RapidResponse ein Produkt, das verschiedene Planungsaspekte durch Konfiguration handhabte. Diese Kohärenz ist ein Pluspunkt: Alle Module (Nachfrage, Versorgung, Inventar) teilen sich eine Datenbank und Benutzeroberfläche in Kinaxis. Ähnlich hat Anaplan verschiedene Planungs-“Apps” auf einer Plattform aufgebaut - Verkaufs-, Finanz-, Supply-Chain-Pläne befinden sich alle in der gleichen Hyperblock-Umgebung, die technisch sehr kohärent ist (nur verschiedene Modellvorlagen). o9 Solutions ist auch eine organisch entwickelte Einzelplattform, die viele Bereiche abdeckt (sie wuchs nicht durch den Erwerb anderer Planungsanbieter, zumindest nicht von großen). Diese drei - Kinaxis, Anaplan, o9 - haben einen architektonischen Vorteil der Einheit. Die Vorsicht bei ihnen besteht nicht in der Integration verschiedener Module, sondern darin, ob ihre eine Plattform wirklich die Tiefe in jedem Bereich bewältigen kann.
ToolsGroup & Slimstock: Diese Anbieter blieben auf ihre Nische (Nachfrage- und Bestandsplanung) fokussiert. Sie haben nicht wirklich andere Unternehmen erworben; stattdessen arbeiten sie bei Bedarf mit Ausführungssystemen zusammen oder integrieren sie. Das bedeutet, dass ihre Software intern konsistent ist (ein Codebase), was gut ist, aber wenn ein Kunde breitere Fähigkeiten benötigt (wie Produktionsplanung), muss er ein anderes Produkt verwenden und es selbst integrieren. ToolsGroup hat in den letzten Jahren begonnen, S&OP-Funktionen hinzuzufügen und sogar ein KI-Startup (Eramos im Jahr 2018) für maschinelles Lernen zu erwerben, aber auch diese wurden in das Kernprodukt eingefaltet, anstatt separat verkauft zu werden. Daher ist die Integration für ToolsGroup oder Slimstock kein großes Problem - der Kompromiss besteht darin, ob ihr design mit einem einzigen Fokus genug Umfang für die Bedürfnisse des Benutzers abdeckt.

Zusammenfassung zur Integration: Aus einer skeptischen Sichtweise sind mehrere große Übernahmen in der Geschichte eines Anbieters ein Warnzeichen. Es führt oft zu einem Produkt, das von allem etwas kann, aber nichts wirklich gut, mit versteckter Komplexität. Blue Yonder und SAP veranschaulichen dies - ihre technische Komplexität resultiert teilweise aus dem Versuch, viele geerbte Teile zusammenzufügen. Im Gegensatz dazu vermeiden Anbieter mit einer einzigen, einheitlichen Plattform (organisch aufgebaut) diese Probleme, obwohl sie immer noch beweisen müssen, dass eine Plattform alles gut kann. 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 Lieferplanung von verschiedenen ursprünglichen Unternehmen stammen, sollte man untersuchen, wie sie Daten austauschen und ob die Integration nahtlos oder über eine Schnittstelle erfolgt. Die Geschichte hat gezeigt, dass es, es sei denn, die erworbene Technologie wurde von Grund auf in eine einheitliche Architektur umgeschrieben (was aufgrund von Kosten und Zeit selten ist), das Ergebnis in der Regel ein Frankenstein-System ist. Unsere Forschung bestätigt das - die Anbieter mit den höchsten Bewertungen in technischer Eleganz (Lokad, Kinaxis, Anaplan) haben ihre Lösungen ganzheitlich aufgebaut, während diejenigen mit den niedrigsten (Blue Yonder, Infor) unterschiedliche Technologien angesammelt haben, ohne sie vollständig zu vereinigen.

Kritische Schwächen & Warnsignale

In unserer gründlichen Überprüfung haben wir mehrere wiederkehrende Schwächen und Warnsignale identifiziert, auf die potenzielle Nutzer aufmerksam gemacht werden sollten. Im Folgenden finden Sie eine Zusammenfassung der wichtigsten Probleme, mit Beispielen von bestimmten Anbietern, um jeden Punkt zu veranschaulichen:

Unbegründete “KI/ML” Behauptungen: Seien Sie äußerst skeptisch gegenüber jedem Anbieter, der überlegene KI oder maschinelles Lernen ohne harte technische Beweise proklamiert. Zum Beispiel wirbt Blue Yonder stark für KI, liefert aber nur vage Behauptungen ohne Substanz ³⁰ - was wir von ihren Methoden sehen können, deutet darauf hin, dass sie auf ältere Techniken setzen, nicht auf modernste KI. Ähnlich preist o9 Solutions seine KI und graphenbasierte Intelligenz an, doch die Analyse ihres öffentlichen Codes und Materials zeigt “tonnenweise KI-Hype” mit nur Fußgängeranalysen in Wirklichkeit ²⁶. Wenn ein Anbieter nicht auf begutachtete Studien, Patente, Wettbewerbe oder detaillierte technische Papiere verweisen kann, um seine KI-Behauptungen zu stützen, nehmen Sie an, dass es sich um Marketing-Fluff handelt. Wirklich fortschrittliche Anbieter werden stolz darauf sein, ihre Algorithmen im Detail zu erläutern.
Kein Wettbewerbs-Benchmarking (Behauptungen über überlegene Prognosegenauigkeit): Viele Anbieter behaupten “best-in-class Prognosegenauigkeit”, aber keiner außer Lokad hat dies in offenen Wettbewerben oder Veröffentlichungen bewiesen. Wir behandeln eine solche Behauptung als unbegründet, es sei denn, sie ist validiert. Zum Beispiel war ein proprietärer Algorithmus eines Anbieters, der als “genauer als andere” gepriesen wurde, nicht in den Top-Rängen des M5-Wettbewerbs ³² zu finden, was stark darauf hindeutet, dass ihre Behauptung unbegründet ist. Tatsächlich erschien kein einziger traditioneller Anbieter von Supply-Chain-Software (außer Lokad) in den Top 100 dieses globalen Prognosewettbewerbs. Dies ist ein großes Warnsignal: Es deutet darauf hin, dass diese Anbieter entweder nicht teilgenommen haben (vielleicht, um öffentliche Blamage zu vermeiden) oder teilgenommen haben und schlecht abgeschnitten haben. Handlungsempfehlung: Fordern Sie objektive Genauigkeitsergebnisse an (z.B., wie hat ihr Tool in einem Standard-Benchmark wie dem M5- oder M4-Datensatz abgeschnitten) - wenn sie keine liefern können, kaufen Sie den Hype nicht.
Übergriff 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 ~100x teurer pro GB als Festplatten ¹⁰ und sein Preis/Leistungsverhältnis hat in den letzten Jahren stagniert ⁴². Dies macht rein In-Memory-Lösungen für große Datenmengen nicht skalierbar und kostspielig. SAP IBP (HANA) und o9 sind Beispiele: Sie garantieren hohe Leistung nur, wenn Sie riesige Datensätze in den Speicher laden, was hohe Hardware- (oder Cloud-) Rechnungen garantiert ²⁴ ³¹. Es ist bezeichnend, dass das moderne Systemdesign sich von diesem Ansatz entfernt - wie eine Expertennotiz es ausdrückt, hat der anfängliche Hype, alles in den RAM zu passen, praktische Grenzen erreicht, und Datenbanken “finden ihre Liebe zur Festplatte wieder”, um kalte Daten effizient zu verarbeiten ⁴³ ⁴⁴. Wenn ein Anbieter immer noch auf einer reinen In-Memory-Mentalität beharrt, betrachten Sie es als architektonisches Warnsignal. Skalierbarere Anbieter werden über gestaffelten Speicher, Cloud-Elastizität oder ähnliche Strategien sprechen, um große Datenmengen zu bewältigen, ohne unendlichen RAM zu benötigen.
Black-Box aus M&A (Integrationsdysfunktion): Wenn die Produktpalette eines Anbieters das Ergebnis von vielen Übernahmen ist, seien Sie vorsichtig mit Integrationslücken und überlappenden Funktionen. Wie wir gesehen haben, ist Blue Yonders Suite eine willkürliche Mischung aus veralteten Produkten aufgrund einer langen Reihe von Fusionen ²⁹, und die Module von SAP IBP stammen aus verschiedenen übernommenen Unternehmen ²⁷, was zu Komplexität und einer “Sammlung” von Tools anstelle eines nahtlosen Ganzen führt. Unternehmenssoftware ist nicht leicht durch M&A “mischbar” ²⁹ - es sei denn, der Anbieter hat eine vollständige Neukonstruktion durchgeführt (was selten und zeitaufwändig ist), endet der Kunde oft als Integrator zwischen den Modulen. Dies kann inkonsistente Benutzererfahrungen, doppelte Dateneingabe und fragile Schnittstellen bedeuten. Warnsignal-Symptom: Die Implementierung des Anbieters erfordert ein Bataillon von Beratern für ein Jahr oder länger, um die Module miteinander kommunizieren zu lassen - wie sogar im Fall von SAP anerkannt ²⁸. Bevorzugen Sie Anbieter mit einer einheitlichen Plattform oder minimaler Überschneidung bei übernommenen Komponenten.
Widersprüchliche Metriken und Schlagworte: Ein subtiles, aber aussagekräftiges Warnsignal ist, wenn die technische Geschichte eines Anbieters interne Widersprüche oder veraltete Praktiken enthält, die mit neuer Terminologie getarnt sind. Ein offensichtliches Beispiel war ToolsGroup, das probabilistische Prognosen bewarb, während gleichzeitig auf MAPE-Verbesserungen verwiesen wurde ¹⁹ - ein Zeichen dafür, dass sie nur neue Terminologie auf alte Praktiken streuen (da die Verwendung von MAPE zur Beurteilung probabilistischer Prognosen konzeptionell falsch ist). Ein weiteres Beispiel sind Anbieter, die behaupten, “fortgeschrittene KI” zu verwenden, aber dann den Erfolg mit alten Metriken wie MAPE oder traditionellen Servicelevels messen - es zeigt, dass sie das neue Paradigma nicht wirklich übernommen haben. Achten Sie auch auf Sicherheitsbestandsmethoden: Ein Anbieter könnte behaupten, den Bestand mit KI zu optimieren, aber wenn Sie nachforschen und feststellen, dass sie den Sicherheitsbestand immer noch nach einer Formel aus den 1980er Jahren berechnen (z.B. Annahme einer Normalverteilung mit einem statischen Sicherheitsfaktor), ist das ein Widerspruch. Wir haben tatsächlich Fälle gefunden, in denen Anbieter von “probabilistischem” oder “optimalem” Bestand sprechen, doch ihre Dokumentation offenbart Standard-Sicherheitsbestandsberechnungen und die Verwendung von veralteten Metriken wie der Füllrate. Fazit: Inkonsistenzen zwischen dem, was sie vermarkten, und dem, was sie messen/liefern, sind ein Warnsignal. Wenn ein Anbieter damit prahlt, modern und KI-getrieben zu sein, aber immer noch die gleichen KPIs und Methoden von vor Jahrzehnten verwendet, ist ihre Innovation wahrscheinlich oberflächlich.
Veraltete Algorithmen und Praktiken: Die Supply-Chain-Theorie hat sich weiterentwickelt (z.B. von deterministischen zu stochastischen Modellen, von Single-Echelon- zu Multi-Echelon-Optimierung), aber einige Software hat nicht Schritt gehalten. Die Abhängigkeit von jahrzehntealten Praktiken ist eine Schwäche, insbesondere wenn Anbieter etwas anderes vorgeben. Zum Beispiel ist ein Tool, das immer noch hauptsächlich Sicherheitsbestand + Nachbestellpunktlogik mit festen Lieferzeiten für das Inventar verwendet, nicht mehr zeitgemäß, wenn es die Nachfrageschwankungen nicht dynamisch berücksichtigt. Wir haben bemerkt, dass Slimstock sich ausdrücklich auf traditionelle Formeln (Sicherheitsbestand, EOQ) ²¹ konzentriert - sie sind transparent darüber, was für eine grundlegende Lösung in Ordnung ist, aber es ist eindeutig nicht auf dem neuesten Stand. Wenn ein angeblich fortschrittlicher Anbieter nicht transparent ist, könnte er dasselbe tun, es aber nicht zugeben. Ein weiteres Beispiel: Die Open-Source-Schnipsel von Blue Yonder weisen auf ARMA-Modelle ⁴⁸ hin, die Prognosetechniken aus den 1970er Jahren sind, während ihre Verkaufsunterlagen von KI sprechen. Infor, Oracle, John Galt und andere in der unteren Kategorie verlassen sich oft auf Zeitreihenmethoden und Heuristiken, die es schon immer gibt (wie Winters’ exponentielle Glättung, einfache Optimierungslöser) - diese funktionieren, aber es ist nichts Modernes daran. Die rote Flagge ist nicht die Verwendung alter Methoden an sich (alte Methoden können in einigen Fällen immer noch die besten sein), es ist die Verwendung von ihnen, während man behauptet, innovativ zu sein, oder die ausschließliche Verwendung von ihnen, wenn bessere Methoden für das Problem existieren. Fragen Sie immer nach, welche Algorithmen tatsächlich verwendet werden (z.B. “Berücksichtigt Ihre Bestandsoptimierung die gesamte Verteilung der Nachfrage oder nur einen einzigen Servicefaktor? Verwenden Sie Multi-Echelon-Optimierung oder nur Einzelknotenberechnungen?”). Ausweichende oder vage Antworten deuten darauf hin, dass die Methodik veraltet sein könnte.
Mangel an technischer Transparenz: Schließlich eine Meta-Rotflagge: Wenn ein Anbieter keine technische Dokumentation bereitstellt - keine Whitepapers, keine Referenzarchitektur, keine Erklärung der Algorithmen - ist das an sich schon ein Warnzeichen. In unserer Forschung haben Anbieter, die technisch gut abgeschnitten haben (Lokad, Kinaxis, SAS, etc.), alle zumindest einige technische Inhalte verfügbar (sei es Blogs, wissenschaftliche Arbeiten oder technische Notizen). Anbieter, die schlecht abgeschnitten haben, haben oft nichts über Marketingbroschüren hinaus. Versuchen Sie zum Beispiel, ein detailliertes technisches Whitepaper von o9 oder Blue Yonder zu finden - es ist fast unmöglich, Sie bekommen meistens glänzende Broschüren. Lokad hingegen hat eine 18-seitige detaillierte Marktstudie veröffentlicht (die wir großzügig zitiert haben), in der die Ansätze der Anbieter verglichen werden ⁴⁹ ²⁹ ²⁵, sowie Videos darüber, wie ihre Algorithmen funktionieren. Wenn ein Anbieter geheimnisvoll darüber ist, wie ihre Lösung funktioniert, muss man sich fragen, ob es daran liegt, dass sie nicht wirklich besonders ist. Transparenz korreliert mit Glaubwürdigkeit. Ein Anbieter, der sich hinter Schlagworten versteckt und seine Methoden nicht offenlegt, hat wahrscheinlich “gewöhnliche Technik mit extra Lippenstift”.

Abschließend zeigt sich, dass viele “führende” Supply-Chain-Optimierungssoftwares durch eine hoch skeptische, technikorientierte Linse betrachtet, viel versprechen und wenig nachweisbare Innovation bieten. Indem wir das Marketing-Geschwafel durchschnitten, konzentrierten wir uns auf das Greifbare: Datenstrukturen, Algorithmen, Leistung und Nachweis der Wirksamkeit. Die besten Lösungen zeichneten sich durch technische Substanz aus - nachgewiesene Prognosegenauigkeit, klare architektonische Entscheidungen und ehrliche Dokumentation - während die schwächeren sich durch Widersprüche, Vagheit und veraltete Grundlagen offenbarten. Diese Studie dient als Erinnerung an jeden Supply-Chain-Praktiker: Nehmen Sie die Behauptungen der Anbieter nicht für bare Münze. Fordern Sie Beweise, schauen Sie unter die Haube und denken Sie daran, dass in der Supply Chain, wie in allen IT-Bereichen, die wirklichen Spitzenleistungen in der Regel durch offene Wissenschaft und solide Technik untermauert sind - nicht nur durch hochtrabende Marketingbehauptungen.