Supply Chain Optimization Software, Februar 2025

Von Léon Levinas-Ménard

Zuletzt geändert am: 2. Februar 2025

Anbieter-Ranking & Zusammenfassung (Basierend auf technischer Strenge)

Lokad - Top Technische Glaubwürdigkeit. Lokad sticht durch seine Transparenz und technische Tiefe hervor. Es hat die probabilistische Prognose vorangetrieben und seine Methoden in offenen Wettbewerben bewiesen (Platz #1 auf der SKU-Ebene und insgesamt Platz #6 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, automatisierung in der Cloud) und betont finanziell optimierte Entscheidungen über simplistische Metriken. Der Fokus auf strenge Mathematik (Quantilprognosen, stochastische Optimierung) und vollständig skriptbare, automatisierte Workflows (über APIs und Codierung) zeigt ein Design, das auf Ingenieurwesen basiert. Es werden keine großen KI/ML-Behauptungen ohne Unterstützung gemacht - stattdessen bietet Lokad technische Whitepapers und sogar Open-Source-Tools zur Skalierung von Daten über RAM-Grenzen hinaus ² ³. Dieses Maß an Offenheit und nachgewiesener Leistung setzt Lokad an die Spitze.
Anaplan - “Excel 2.0” Plattform. Anaplan ist im Wesentlichen die Unternehmens-SaaS-Version einer Tabellenkalkulation, die von seinem proprietären Hyperblock-In-Memory-Motor angetrieben wird ⁴. Technisch gesehen ist Hyperblock ein robuster multidimensionaler Berechnungsmotor, der es Tausenden von Benutzern ermöglicht, in Echtzeit an Planungsmodellen zusammenzuarbeiten - ähnlich wie ein aufgeladener, cloudbasierter Excel. Obwohl Anaplan an sich kein spezialisierter Supply-Chain-Optimizer ist (Prognosen und algorithmische Optimierung sind auf dieser Plattform “Bürger zweiter Klasse” ⁵), liegt seine Stärke in seiner soliden Architektur für Modellierung und Szenarioplanung. Es verkauft keine mystische KI; stattdessen bietet es eine zuverlässige, leistungsstarke Sandbox zum Aufbau benutzerdefinierter Planungslogik. Kurz gesagt, es ist ein leistungsstarkes allgemeines Planungstool mit einem ehrlichen Ansatz - keine übertriebenen Behauptungen über prognostische Magie, sondern ein gut konstruiertes, skalierbares System ähnlich einer Tabellenkalkulation. Dieses klare technische Angebot bringt Anaplan einen hohen Rang in Glaubwürdigkeit ein.
Kinaxis (RapidResponse) - In-Memory-Simulation Engine. Kinaxis ist bekannt für seinen einzigartigen Parallelitätsmotor, der es ermöglicht, Versorgungspläne in Echtzeit in einem Unternehmen neu zu berechnen. Technisch gesehen hat Kinaxis seinen eigenen Datenbankmotor von Grund auf aufgebaut, 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 sofortiges Feedback über die Auswirkungen von Änderungen erhalten ⁸. Das System behält alle Supply-Chain-Daten im Speicher für Geschwindigkeit, wobei Algorithmen direkten Speicherzugriff auf Daten für maximale Durchsatzrate haben ⁹. Dieses Design ermöglicht echte parallele Planung (z.B. Vertrieb, Produktion und Lagerpläne werden gemeinsam in Echtzeit aktualisiert). Aus ingenieurtechnischer Sicht ist der Aufbau eines benutzerdefinierten In-Memory-, versionskontrollierten Datenspeichers eine beeindruckende Leistung, die Agilität bietet. Der Kompromiss besteht jedoch in der hohen Hardwareanforderung - ein vollständiger In-Memory-Ansatz bedeutet, dass das Skalieren auf massive Datenmengen teuer sein kann (da die RAM-Anforderungen wachsen) ¹⁰. Insgesamt zeigt Kinaxis eine starke technische Strenge in Architektur und Leistung, ohne sich auf trendy KI-Behauptungen einzulassen. Es glänzt in der Supply-Chain-Planung und S&OP-Simulationen, bietet jedoch weniger Out-of-the-Box-ML-Prognosefunktionen im Vergleich zu einigen Mitbewerbern.
SAS - Statistisches Schwergewicht. SAS ist ein etabliertes Analyse-Softwareunternehmen (gegründet 1976) und bringt einen beeindruckenden statistischen Modellierungsansatz für Probleme in der Supply Chain mit. Zu den Flaggschiffprodukten gehört eine domänenspezifische Sprache für Statistiken (die SAS-Sprache), die bis in die 1970er Jahre zurückreicht ¹¹ - möglicherweise die ursprüngliche Plattform für Datenwissenschaft. Die Stärke von SAS liegt in der Tiefe seiner Algorithmen: eine umfangreiche Bibliothek von Zeitreihenprognosemodellen, Optimierungsroutinen und maschinelles Lernen, die über Jahrzehnte aufgebaut wurden. Es beschäftigt einige der talentiertesten Ingenieure und Statistiker der Branche ¹¹ und hat fortschrittliche Prognosen lange vor dem Aufkommen von “KI” vorangetrieben. 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 umfangreich. Die Werkzeuge können veraltet wirken (die Welt ist größtenteils zu Open-Source-Sprachen wie Python/R gewechselt, und tatsächlich sind Jupyter-Notebooks jetzt eine überlegene offene Alternative ¹²). SAS beansprucht nicht lautstark magische KI; es verlässt sich auf seinen Ruf und solide Technologie. Für Organisationen mit der Expertise, sie zu nutzen, bietet SAS ernsthafte analytische Schlagkraft, die auf echten Algorithmen (ARIMA, ETS usw.) statt Hype basiert. Der Hauptnachteil ist, dass es sich um eine allgemeine Analyseplattform handelt - extrem leistungsstark unter der Haube, aber erfahrene Benutzer benötigt, um sie auf die Supply Chain anzuwenden, und sie wurde in jüngsten Prognosewettbewerben nicht speziell benchmarkt (Open-Source-Tools konkurrieren oft mit ihr ¹³).
Dassault Systèmes (Quintiq) - Optimierungsspezialist. Quintiq (2014 von Dassault Systèmes übernommen) ist eine Plattform, die sich auf komplexe Supply-Chain-Optimierung und Terminplanung konzentriert. Es verfügt über eine eigene domänenspezifische Sprache namens Quill zur Modellierung von Geschäftsbeschränkungen ¹⁴. Diese DSL ermöglicht es Ingenieuren, maßgeschneiderte Lösungen zu codieren (zum Beispiel benutzerdefinierte Produktionspläne oder Routenpläne) und mathematische Solver zu nutzen. Die Existenz einer DSL im Produkt ist ein Beweis für ernsthafte technische Kompetenz - die Entwicklung einer Programmiersprache für Planungsprobleme ist keine Kleinigkeit ¹⁵. Quintiq glänzt in Szenarien wie der Fabrikplanung, der Optimierung von Logistiknetzwerken und anderen NP-schweren Problemen, bei denen ein benutzerdefiniertes Optimierungsmodell erforderlich ist. Technisch gesehen ist es einer der flexibelsten und leistungsstärksten Optimierungsmotoren, die in der Supply-Chain-Software verfügbar sind. Allerdings geht der Fokus von Quintiq auf Optimierung auf Kosten 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 möglicherweise veraltet ist oder zumindest nicht schnell genug weiterentwickelt wird ¹⁷. Benutzer verlassen sich oft auf die Berater von Dassault, um Lösungen zu konfigurieren, und ohne klare öffentliche Dokumentation ist es schwer, die jüngsten Innovationen einzuschätzen. Zusammenfassend ist Quintiq eine erstklassige Wahl für komplexe Optimierungsanforderungen und zeigt starke Ingenieursleistungen durch seine DSL - aber es ist nicht so transparent oder aktuell in Bereichen wie KI/Prognosen, und seine Stärken liegen darin, was die Implementierer damit aufbauen, anstatt in Out-of-the-Box-“Intelligenz”.
ToolsGroup (SO99+) - Probabilistischer Vorreiter mit Einschränkungen. Die Software von ToolsGroup (SO99+) hat sich lange auf Nachfrageprognosen und Bestandsoptimierung spezialisiert, mit einem Schwerpunkt auf probabilistischen Modellen. Es bietet umfangreiche Supply-Chain-Funktionalitäten (Nachfrageplanung, Wiederbeschaffung, Multi-Echelon-Bestandsoptimierung) und war einer der ersten Anbieter, die “Powerfully Simple” probabilistische Prognosen beworben haben. Auf dem Papier klingt das fortgeschritten - ToolsGroup sagt, dass es die Unsicherheit der Nachfrage modelliert und “selbstabstimmende” Prognosen erstellt, was genauere Bestandsziele ermöglichen sollte. Ein genauer technischer Blick wirft jedoch Bedenken auf. ToolsGroups öffentliche Materialien deuten immer noch darauf hin, dass sie Vorhersagemodelle aus der Zeit vor 2000 verwenden ¹⁸ - sie haben in der Vermarktung einen “KI”-Glanz hinzugefügt, jedoch ohne konkrete Angaben. Bezeichnenderweise werben sie seit 2018 mit probabilistischen Prognosen, während sie gleichzeitig mit MAPE-Verbesserungen prahlen ¹⁹. Dies ist ein offensichtlicher Widerspruch: Wenn Prognosen wirklich probabilistische Verteilungen sind, sind Metriken wie MAPE (die die Genauigkeit von Einzelwerten misst) nicht mehr direkt anwendbar ¹⁹. Solche Inkonsistenzen legen nahe, dass der “probabilistische” Teil oberflächlich sein könnte oder dass sie sich trotz neuer Methoden an alten Metriken orientieren. Darüber hinaus hat ToolsGroup Schlagwörter wie “KI für die Nachfrageerfassung” verwendet, aber diese Behauptungen sind nicht durch wissenschaftliche Literatur oder bekannte Benchmarks unterstützt ²⁰. In der Praxis funktionieren viele ToolsGroup-Implementierungen immer noch als automatisierte regelbasierte Systeme mit Ausnahmemeldungen. Fazit: ToolsGroup verfügt über eine breite Funktionalität und war führend bei der Befürwortung der Modellierung von Unsicherheit, aber die mangelnde Transparenz hinsichtlich der Algorithmen und die Diskrepanz zwischen Marketing und Realität in Bezug auf KI/ML machen seine technische Glaubwürdigkeit nur moderat. Es handelt sich um ein solides, auf das Fachgebiet ausgerichtetes Toolset, das jedoch nach heutigen Maßstäben nicht eindeutig auf dem neuesten Stand der Technik ist.
Slimstock (Slim4) - Einfach und Solide. Slimstock ist eine erfrischende Ausnahme, die keinen Trends hinterherjagt. Die Software Slim4 konzentriert sich auf mainstream Supply-Chain-Techniken - Dinge wie klassische Sicherheitsbestandsberechnungen, Nachbestellpunkte, wirtschaftliche Bestellmenge (EOQ) usw. ²¹. Mit anderen Worten, Slimstock hält sich an etablierte, erprobte Methoden, die in Lehrbüchern gelehrt werden. Auch wenn dies bedeutet, dass es keine ausgefallene KI/ML oder hochmoderne Algorithmen gibt, bedeutet dies auch, dass Slim4 zuverlässig und einfach zu verstehen ist. Der Anbieter vermeidet explizit vage KI-Behauptungen und betont stattdessen praktische Funktionen, die den täglichen Bedürfnissen der Supply Chain entsprechen ²². Diese Ehrlichkeit ist ein technischer Vorteil: Benutzer wissen genau, was sie bekommen, und das Verhalten des Systems ist vorhersehbar. Natürlich kann Einfachheit auch eine Einschränkung sein - Sie erhalten keine probabilistischen Nachfrageprognosen oder fortschrittliche 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 gilt: Einfacher ist besser, wenn das bedeutet, dass das Tool konsistent funktioniert. Slimstock erhält Glaubwürdigkeitspunkte für das Vermeiden von Buzzword-Bingo; sein “auf-den-Punkt” Ansatz wird von Kollegen als Kontrast zu anderen KI-Posen gelobt ²³. Zusammenfassend: Slim4 treibt die technologische Entwicklung nicht 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 Machine. o9 präsentiert sich als “Digital Brain” für die unternehmensweite Supply Chain, indem es die Nachfrageprognose, die Lieferplanung, S&OP und sogar das Umsatzmanagement auf einer Plattform kombiniert. 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 reine “Technikmasse” von o9 ist außerordentlich hoch ²⁴ - nach Unternehmenssoftwarestandards handelt es sich um eine sehr ambitionierte Architektur, die versucht, alle Daten- und Planungsanalytik zu vereinen. Bei genauerer Betrachtung scheint jedoch vieles davon Technologie um der Technologie willen zu sein, ohne klaren Nutzen. Das In-Memory-Design von o9 garantiert extrem hohe Hardwarekosten im großen Maßstab ²⁵, ähnlich dem kontinuierlichen Betrieb eines riesigen BI-Würfels. o9 preist seinen EKG (Wissensgraph) als ermöglicher überlegene Prognosen und KI-gesteuerte Erkenntnisse an, aber keine wissenschaftlichen Beweise oder glaubwürdigen Benchmarks werden bereitgestellt ²⁵. Tatsächlich zerfallen viele der auffälligen Behauptungen von o9 unter genauerer Prüfung: Das Unternehmen spricht über KI überall, aber Fragmente ihres öffentlich sichtbaren Codes auf GitHub zeigen eher gewöhnliche Techniken ²⁶. Zum Beispiel hat o9 Funktionen wie maschinelles Lernen für die Nachfrageprognose und “digitale Zwilling” -Simulationen beworben, aber sie haben diese in keinem öffentlichen Wettbewerb oder peer-reviewed Fallstudie demonstriert. Ohne Beweise müssen wir ihre KI-Behauptungen als Marketing-Hype behandeln. Dennoch hat o9 Stärken - es ist eine einheitliche Plattform (intern entwickelt, nicht eine Ansammlung von Übernahmen) und kann eine Datenintegration im großen Maßstab bewältigen. Für ein Unternehmen, das in Hardware investieren und sich mit einer steilen Lernkurve auseinandersetzen möchte, bietet o9 die Flexibilität, komplexe Planungsmodelle zu erstellen. Aber aus ingenieurtechnischer Sicht ist es eine überkonstruierte Lösung: viel Komplexität, unklare ROI auf der ausgefallenen Technologie und potenzielle Leistungsprobleme, wenn die Daten über das hinauswachsen, was der Speicher fassen kann. Bis o9 harte Beweise liefert (z. B. Algorithmusdokumentation oder Benchmark-Ergebnisse), bleibt seine Glaubwürdigkeit fragwürdig.
SAP IBP (Integrated Business Planning) - Umfassend, aber komplex. SAPs IBP-Suite ist die Weiterentwicklung des SAP-Legacy APO, die jetzt als Cloud-Lösung auf der SAP HANA In-Memory-Datenbank angeboten wird. SAP IBP zielt darauf ab, das gesamte Spektrum abzudecken: Nachfrageprognose, Bestandsoptimierung, Lieferplanung, Vertriebs- und Betriebsplanung und mehr - alles eng integriert mit dem SAP-ERP. Die Stärke von SAP IBP liegt in der Breite: Es gibt ein Modul für nahezu jeden Planungsaspekt, oft mit sehr umfangreichen Funktionen, die aus jahrzehntelanger SAP-Erfahrung stammen. Allerdings kam die Breite durch Übernahmen und Legacy-Systeme zustande. SAP hat Spezialisten wie SAF (Nachfrageprognose), SmartOps (Bestandsoptimierung) und andere ²⁷ übernommen und diese auf seine hauseigenen Tools (wie APO und HANA) aufgesetzt. Das Ergebnis unter der Haube ist ein Flickenteppich aus verschiedenen Engines und Ansätzen ²⁷. Als Konsequenz ist die technische Architektur von IBP nicht elegant - es handelt sich um eine Sammlung von Komponenten, die nicht natürlicherweise “zusammenpassen” und einen hohen Integrationsaufwand erfordern. Selbst die Dokumentation von SAP räumt die hohe Komplexität und die Notwendigkeit von erstklassigen Systemintegratoren (und erheblicher Zeit) ein, um alles reibungslos zum Laufen zu bringen ²⁸. Technologisch setzt IBP stark auf SAP HANA, eine In-Memory-Spalten-Datenbank, um Echtzeitleistung zu erreichen. HANA ist tatsächlich schnell, aber auch teuer - die Speicherung großer Planungsdaten ausschließlich im RAM ist inherently costly (RAM ist etwa 100-mal teurer pro TB als Festplattenspeicher) ¹⁰. Das bedeutet, dass das Skalieren von IBP auf sehr große Supply-Chain-Datensätze erhebliche Infrastrukturkosten verursacht, und wenn die Daten den Speicher übersteigen, kann die Leistung drastisch sinken. SAP hat begonnen, einige Funktionen des maschinellen Lernens hinzuzufügen (z. B. “Demand Driven MRP” und IBP for Demand hat einige ML-Prognoseoptionen), aber diese sind größtenteils optionale Add-Ons mit begrenzter Transparenz. Es gibt keine Beweise dafür, dass das ML von SAP anderen überlegen ist; tatsächlich hat kein SAP-Algorithmus in unabhängigen Prognosewettbewerben eine gute Figur gemacht. Zusammenfassend ist SAP IBP funktionsreich und unternehmenserprobt - es wird alle Funktionen abhaken - aber aus rein technischer Sicht ist es eine Mischung: In-Memory-Geschwindigkeit verheiratet mit Legacy-Logik, viel Komplexität aus fusionierten Produkten und keine klare technische Innovation bei der Prognose oder Optimierung über das hinaus, was die übernommenen Teile bereits geleistet haben. Unternehmen wählen es oft für die Integration mit SAP ERP, nicht unbedingt für die Optimierungsexzellenz an sich.
Blue Yonder - Ehemaliger Branchenführer wird zum Flickenteppich. Blue Yonder (ehemals JDA Software) bietet eine umfassende Suite, die Prognosen, Supply Planning, Merchandising und Ausführung umfasst. Es ist das Ergebnis vieler Jahre von Fusionen und Übernahmen, darunter JDA’s Übernahme von i2 Technologies (Supply Chain Planning), Manugistics und dem KI-Startup Blue Yonder (dessen Namen es übernommen hat) unter anderem ²⁹. Leider ist Unternehmenssoftware keine einfache Summe der Teile: Unter der vereinheitlichten Marke Blue Yonder verbirgt sich eine Zusammenstellung von Produkten (viele davon ziemlich veraltet), die locker miteinander verbunden sind ²⁹. Aus technischer Sicht reichen Blue Yonders Lösungen von altmodischen deterministischen Prognose-Engines bis hin zu Bestandsoptimierungsmodulen, die sich in über 15 Jahren nicht grundlegend verändert haben. Das Unternehmen bewirbt stark “KI” und “ML” Fähigkeiten in seiner Luminate-Plattform, aber Details sind knapp. 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 zugeschrieben 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 heute oft von neueren Methoden übertroffen werden. Es scheint, dass Blue Yonders viel gepriesene KI möglicherweise einfach neu verpackte Regressionen und Heuristiken sind. Ohne transparente Fallstudien oder technische Papiere muss man davon ausgehen, dass Blue Yonders Behauptungen über “revolutionäre KI-Prognosen” reine Marketingfloskeln sind. Darüber hinaus ist die Integration aller erworbenen Komponenten eine fortwährende Herausforderung - viele Kunden bemerken Schwierigkeiten bei der Umsetzung des “end-to-end”-Versprechens, da die Module (Nachfrage, Angebot, Erfüllung usw.) nicht ohne erhebliche Anpassungen nativ zusammenpassen. In-Memory vs. On-Disk? Blue Yonder wirbt nicht mit einer vollständigen In-Memory-Architektur wie einige andere; Teile des Systems laufen wahrscheinlich auf herkömmlichen relationalen Datenbanken. Dies könnte tatsächlich ein Segen in Bezug auf die Kosten sein, bedeutet aber auch, dass die Leistung nachlassen kann, es sei denn, die Daten werden aggregiert (z.B. ihre älteren Systeme verwendeten oft Batch-Planungsläufe). Zusammenfassend ist Blue Yonder eine Warnung: 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 Technologie unter einem neuen Anstrich und ein Mangel an glaubwürdigen Beweisen für seine neuen “KI”-Fähigkeiten.

(Anmerkung: Andere Anbieter wie Infor (mit den Legacy-Komponenten GT Nexus und Mercia), GAINS Systems (ein weiterer Spezialist für Bestandsoptimierung), John Galt Solutions (Nachfrageplanung im mittleren Marktsegment), Relex Solutions (Einzelhandelsprognosen 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 auch für diejenigen, die nicht einzeln eingestuft sind: zum Beispiel verwendet Relex ein In-Memory, OLAP-Würfel-Design - großartig für 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 Grundfunktionalitäten, aber es gibt wenig öffentlich dokumentiertes zu neuartigen Techniken. Jeder Anbieter, der keine technischen Details oder Nachweise offen teilt, würde in jedem Fall niedrig in der Methodik dieser Studie eingestuft.)*

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: Prognosen & KI, Automatisierungsfähigkeiten, Systemarchitektur und Integration von Modulen. Alle Analysen basieren auf veröffentlichten technischen Informationen oder konkreten Beweisen und vermeiden explizit jegliche Marketing-Sprache.

Prognose- & KI-Fähigkeiten

Moderne Supply-Chain-Planung hängt 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 die Standard-Statistikmethoden nicht wesentlich übertreffen - trotz Schlagwörtern wie “KI” oder “Maschinelles Lernen” in ihrer Vermarktung.

Nachgewiesene Leistung vs. Hype: Unter allen Anbietern ist Lokad der einzige mit einer überprüfbaren Weltklasse-Prognosebilanz, dank des offenen M5-Wettbewerbs. Lokad hat seine probabilistische Prognosefähigkeit unter Beweis gestellt, indem es bei der SKU-genauen Genauigkeit an der Spitze rangierte ¹. Dies verleiht Lokads Behauptungen über eine bessere Prognosegenauigkeit Glaubwürdigkeit. Im krassen Gegensatz dazu hat kein anderer Anbieter vergleichbare Ergebnisse auf einem unabhängigen Benchmark veröffentlicht. Einige Anbieter werben beispielsweise mit proprietären Algorithmen (einer nennt seine Methode “Procast”), die eine überlegene Genauigkeit versprechen, aber diese Methoden waren nicht unter den Top-Rängen des M5-Wettbewerbs ³². In der Praxis sind akademische Open-Source-Ansätze (wie die R-Prognosepakete von Prof. Rob Hyndman) wahrscheinlich genauso gut oder besser als die meisten geschlossenen proprietären Engines ¹³. Daher sollte jede Anbieterbehauptung über “branchenbeste Prognosegenauigkeit” ohne öffentlichen Beweis als nicht unterstützt betrachtet werden.
KI- und maschinelles Lernen-Behauptungen: Wir betrachteten KI/ML-Buzz mit äußerstem Skeptizismus. Anbieter wie o9 Solutions und Blue Yonder verwenden in ihren Broschüren häufig Begriffe wie “KI-/ML-gesteuerte Prognosen”. Wenn es jedoch um Substanz geht, fanden wir wenig. Im Fall von o9 sind ihre Behauptungen, dass der graphenbasierte “Enterprise Knowledge Graph” bessere Prognosen liefert, zweifelhaft und ohne wissenschaftliche Untermauerung ²⁵. Blue Yonder preist ebenfalls KI an, liefert jedoch keine Details - der einzige Einblick in ihre Technologie stammt aus einigen Open-Source-Repositories, die die Verwendung recht gewöhnlicher Zeitreihentechniken (ARMA, lineare Regression, Merkmalsentwicklung) zeigen ³⁰. Es gibt keine Hinweise auf Deep Learning, fortgeschrittene probabilistische Methoden oder andere moderne KI, die ihre Vermarktung rechtfertigen würden. ToolsGroup hat Konzepte des maschinellen Lernens integriert (sie sprechen von “Nachfragesensorik” unter Verwendung von maschinellem Lernen), aber auch hier keine peer-reviewed Studien oder Wettbewerbsgewinne, um es zu validieren ²⁰. Tatsächlich legt die Verknüpfung von “probabilistischer Prognose” durch ToolsGroup mit alten Metriken wie MAPE nahe, dass ihre KI eher ein Buzz als ein Durchbruch ist ¹⁹. Fazit: Abgesehen von Lokad (und in gewissem Maße SAS, das bewährte statistische Modelle verwendet), basiert die Prognose in den meisten Supply-Chain-Softwarelösungen auf bekannten Methoden (exponentielle Glättung, Regression, vielleicht einige baumbasierte ML) und nicht auf einem proprietären genialen KI-System. Anbieter, die wirklich neuartige Algorithmen haben, würden sie öffentlich demonstrieren. Das Fehlen unabhängiger Validierung spricht Bände.
Probabilistische vs. deterministische Ansätze: Ein bemerkenswerter technischer Unterschied besteht darin, ob ein Anbieter probabilistische Prognosen (die Vorhersage einer vollständigen Verteilung der Nachfrageergebnisse) unterstützt oder sich auf Ein-Punkt-Prognosen beschränkt. Lokad ist seit 2012 ein vehementer Verfechter vollständiger Wahrscheinlichkeitsverteilungen und optimiert tatsächlich Entscheidungen (wie Lagerbestände) direkt auf Basis der probabilistischen Prognosen. ToolsGroup behauptet ebenfalls, probabilistische Prognosen zu erstellen (wahrscheinlich über Monte-Carlo-Simulationen der Nachfrage). Wir haben jedoch festgestellt, dass viele, die sich als “probabilistisch” bezeichnen, intern dennoch zu deterministischen Metriken und Prozessen zurückkehren. Beispielsweise ist die Marketingaussage von ToolsGroup über die Reduzierung des MAPE durch die Verwendung probabilistischer Modelle inkohärent, da MAPE nicht einmal auf einer probabilistischen Prognoseausgabe berechnet werden kann ¹⁹. Dies legt nahe, dass ihr Prozess letztendlich auf eine Punktprognose (Mittelwert oder Median) zur Bewertung zurückfällt und 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 gehen ihre Benutzeroberflächen und Berichte oft auf Einzelzahlprognosen mit traditionellen Fehlermetriken zurück. Die echte probabilistische Prognose erfordert ein Umdenken bei den KPIs (Verwendung von Pinball-Verlust, CRPS oder Service-Level-Erreichung anstelle von MAPE). Wir haben keine Hinweise darauf gefunden, 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 für die meisten Anbieter der Realität voraus ist - sie können zwar einige Verteilungen im Hintergrund generieren, aber Planer betrachten immer noch Punktprognosezahlen und klassische KPIs, was auf eine begrenzte Übernahme des Paradigmas hinweist.
Prognosemetriken und Bewertung: Ein wichtiger Aspekt der technischen Strenge ist, wie ein Anbieter die Qualität der Prognosen bewertet. Ein Warnsignal ist die fortgesetzte Abhängigkeit von Metriken wie MAPE, WAPE oder Bias als alleinige Erfolgsmessung, insbesondere wenn der Anbieter angibt, KI- oder probabilistische Methoden zu verwenden. Dies liegt daran, dass diese Metriken konservative, mittelmäßige Prognosen fördern und manipuliert werden können (zum Beispiel durch Abschneiden von Höchst- und Tiefstständen). Wir haben beobachtet, dass Anbieter mit wirklich fortschrittlichen Prognosen tendenziell über Service-Level oder Geschäftsergebnisse sprechen (z. B. Wahrscheinlichkeit von Lagerausfällen, Kostenwirkung) anstelle von nur MAPE. Lokad betont beispielsweise die Reduzierung des “Fehlerbetrags” und die Ausrichtung der Prognosen auf die Entscheidungsoptimierung ³³. Im Gegensatz dazu heben ToolsGroup, Blue Yonder und viele andere immer noch prozentuale Fehler in ihren Fallstudien hervor und zeigen ein veraltetes Denken. Wenn die Dokumentation oder Demo eines Anbieters stark auf MAPE/WAPE-Dashboards ausgerichtet ist, ist dies ein Zeichen dafür, dass ihre Prognose wahrscheinlich traditionell ist. Tatsächlich wurde bereits die Inkonsistenz von ToolsGroup bezüglich MAPE festgestellt ¹⁹. Kurz gesagt: wirklich hochmoderne Prognosen in der Lieferkette würden sich durch probabilistische Metriken und Realitätsvalidierung auszeichnen - Eigenschaften, die außerhalb von ein oder zwei Anbietern größtenteils fehlen.

Automatisierung & Workflow-Fähigkeiten

Die Optimierung der Lieferkette geht nicht nur um Algorithmen, sondern auch darum, wie automatisiert und “hands-free” die Software den Planungsprozess ausführen kann. Wir haben die Ansprüche und Dokumentation jedes Anbieters auf Hinweise auf Automatisierung, API-Integration und Unterstützung bei autonomen Entscheidungen untersucht.

Lokad: Automatisierung ist eines der Markenzeichen von Lokad. Die gesamte Lösung basiert auf einer domänenspezifischen Sprache (Envision), die es Lieferkettenplanern ermöglicht, ihre Logik und Entscheidungen in Skripten zu codieren, die dann automatisch nach Zeitplan ausgeführt werden. Lokad dokumentiert klar seine Datenpipelines und Workflow-Manager, die Daten aktualisieren und Entscheidungen (Prognosen, Nachbestellungen usw.) ohne manuelle Eingriffe neu berechnen ³⁴ ³⁵. Sie diskutieren sogar über “hochgradig automatisierte Setups” für ~100 Lieferketten in der Produktion ³⁵, was bedeutet, dass die Software Daten abruft, Prognosen erstellt und Entscheidungen ausgibt (wie Vorschläge für Bestellmengen) auf automatische Weise. Darüber hinaus bietet Lokad APIs für den Datenupload und den Ergebnisdownload und hat ein Konzept des “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/Parameter zu überwachen und zu verfeinern, nicht manuell für jeden Plan Knöpfe zu drücken. Lokads Ansatz zur Automatisierung ist glaubwürdig und technisch detailliert (sie haben sogar Vorlesungen darüber gehalten, wie man von manuellen zu automatisierten Entscheidungen übergeht ³⁷ ³⁸).
Kinaxis: Kinaxis RapidResponse ist für schnelle Szenarioanalysen und Zusammenarbeit konzipiert und nicht für vollautomatische Planung. Das Konzept des “gleichzeitigen Planens” bedeutet, dass alle mit denselben Daten in Echtzeit arbeiten, aber in der Regel immer noch menschliche Planer involviert sind, um Szenarien zu bewerten und Entscheidungen zu treffen. Dennoch unterstützt Kinaxis Automatisierung auf bestimmte Weise: Es kann Daten aus ERP-Systemen nahezu in Echtzeit aufnehmen, seine Angebots-/Nachfrage-Abgleichsalgorithmen kontinuierlich ausführen und Benutzer benachrichtigen oder Ausnahmemeldungen auslösen, wenn etwas außerhalb der Grenzen liegt. Es stellt Funktionalitäten über APIs zur Verfügung und verfügt über Skripting (in Form von konfigurierbaren Algorithmen und Makros in seiner Umgebung) für Power-User. Kinaxis positioniert sich jedoch im Allgemeinen als Entscheidungsunterstützung und nicht als Blackbox, die automatisch Aufträge freigibt. Der Anbieter beansprucht nicht lautstark eine “autonome Lieferkette”; stattdessen konzentriert er sich darauf, Planer effizienter zu machen. Dies ist eine ehrliche Haltung. Das bedeutet, dass RapidResponse von Haus aus immer noch menschliche Beteiligung erwartet - was eine Einschränkung darstellen kann, wenn man ein “selbstfahrendes” Lieferketten-System sucht. Technisch gesehen kann Kinaxis tief integriert werden (zum Beispiel integriert es sich oft mit SAP ERP, um genehmigte Pläne auszuführen), aber ein unbeaufsichtigter End-to-End-Betrieb würde eine Menge individueller Konfiguration erfordern. Wir haben keine Hinweise darauf gefunden, dass Kinaxis KI-gestützte Entscheidungsempfehlungen bietet (ihre Stärke liegt eher in der schnellen Berechnung von Szenarien, die von Benutzern definiert sind).
o9 Solutions: o9 vermarktet stark Konzepte wie einen “digitalen Zwilling” der Organisation und KI, die Empfehlungen geben kann. Sie sprechen über “Automatisierung” im Zusammenhang mit ihren digitalen Assistenten - vermutlich Bots, die Erkenntnisse liefern oder einige Aufgaben erledigen können. Allerdings ist es aufgrund des Fehlens konkreter technischer Dokumentation schwer zu sagen, wie viel davon real ist. Wir konnten keine Details wie „o9 kann basierend auf seinen Plänen automatisch Auffüllungsaufträge über API freigeben“ oder „o9 verwendet Verstärkendes Lernen, um Parameter eigenständig anzupassen“ finden. Die Unbestimmtheit von o9s Automatisierungsgeschichte ist besorgniserregend: viel hochrangiges Gerede, wenig Detail. Angesichts seines In-Memory-EKG-Fundaments vermuten wir, dass o9 in der Lage ist, Echtzeitdatenaktualisierungen und Neuberechnungen durchzuführen, aber wahrscheinlich immer noch darauf angewiesen ist, dass Benutzer konfigurieren, was mit diesen Informationen zu tun ist. Ohne glaubwürdige Referenzen behandeln wir o9s “Autonomie”-Behauptungen als nicht überprüft. Es ist möglich, o9 über APIs in Ausführungssysteme zu integrieren (es handelt sich um eine moderne Software, daher sollte eine API-Integration vorhanden sein), aber wie viel Entscheidungsfindung tatsächlich von KI in o9 automatisiert wird, ist unklar. Die Beweise legen nahe, dass o9s aktuelle Automatisierung eher darauf abzielt, die Analytik zu beschleunigen (z. B. sofortige Was-wäre-wenn-Szenarien) als die Automatisierung von Entscheidungsergebnissen.
Blue Yonder: In den letzten Jahren hat Blue Yonder (insbesondere seit der Übernahme durch Panasonic) den Begriff “autonome Lieferkette” vorangetrieben, was auf ein System hindeutet, das mit minimalem menschlichem Eingriff betrieben werden kann. Sie haben einige Komponenten wie Luminate Control Tower, die KI zur Erkennung von Störungen verwenden und möglicherweise Reaktionen auslösen können. Angesichts des Legacy-Kerns von Blue Yonder ist es jedoch wahrscheinlich, dass jede Autonomie durch das Hinzufügen 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 sie automatisch anhand von Echtzeitverkäufen anpassen (Bedarfserfassung) oder eine Warnung senden, wenn sie abweicht. Aber vollautomatische Planung (wie automatische Auftragserteilung, automatische Anpassung von Lagerpolitiken) ist wahrscheinlich selten bei BY-Lösungen - Kunden haben in der Regel immer noch Planer, die Aktionen überprüfen und genehmigen. Das Fehlen detaillierter technischer Literatur darüber, wie Blue Yonder Entscheidungen automatisiert, ist aussagekräftig. Wenn sie wirklich einen 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 daraus, dass Blue Yonder eine gewisse Automatisierung ermöglicht (wie Stapelverarbeitung, Aktualisierungen von Plänen, möglicherweise geschlossene Integration in Ausführungssysteme), aber in diesem Bereich nicht nachweislich führend ist. Wahrscheinlich verwendet es ähnliche Ausnahme-basierte Planung wie ältere Systeme (nur mit einer neuen KI-Oberfläche im Warnsystem).
ToolsGroup: ToolsGroup hat sich historisch auf “Leistungsstarke einfache Automatisierung” spezialisiert. Sie behaupteten, dass ihr System über einen längeren Zeitraum im Lights-Out-Modus laufen könne und Planer nur bei Ausnahmen eingreifen müssten. Tatsächlich war die Philosophie von ToolsGroup, dass das System täglich automatisch neu prognostiziert und replant, sich an neue Daten anpasst. Zu ihrem Vorteil haben viele ToolsGroup-Kunden eine reduzierte Arbeitsbelastung der Planer gemeldet, da die Software automatisch Inventarziele anpasst und Bestellungen automatisch empfiehlt. ToolsGroup verfügt auch über ein Integrations-Toolkit, um genehmigte Bestellungen an ERP-Systeme zu übermitteln. Aufgrund der zuvor erwähnten Widersprüche haben wir jedoch Zweifel an der Intelligenz dieser Automatisierung. Es könnte einfach jeden Tag dieselbe Formel anwenden und nur dann Alarm schlagen, wenn etwas nicht stimmt (Ausnahmemanagement). ToolsGroup bietet eine API und unterstützt geplante Läufe, sodass 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 stimmt, ist das eine nützliche Automatisierung (die den Bedarf an ständiger menschlicher Neukonfiguration beseitigt). Ohne unabhängige Bewertung sagen wir vorsichtig, dass ToolsGroup eine hohe Automatisierung bei routinemäßigen Planungsaufgaben bietet, aber aufgrund des Mangels an Transparenz ist es schwer zu beurteilen, wie “intelligent” diese Automatisierung ist (z. B. lernt und verbessert sie sich tatsächlich oder folgt sie nur voreingestellten Regeln?).
Andere Anbieter: Die meisten anderen Anbieter unterstützen Standard-Automatisierungsfunktionen: Datenintegration über APIs oder Datei-Chargen, geplante Planungsläufe und einige workflows basierend auf Ausnahmen. Zum Beispiel kann SAP IBP so eingestellt werden, dass es jeden Monat automatisch einen Prognoseauftrag ausführt und Planungsergebnisse generiert, aber in der Regel überprüft ein Planer die Ausgabe. Anaplan konzentriert sich weniger auf Automatisierung - es handelt sich eher um eine manuelle Modellierungsplattform, obwohl Sie seine API verwenden können, um Daten zu übertragen und bestimmte Berechnungen möglicherweise zu automatisieren. Dassault/Quintiq kann so skriptiert werden, dass Optimierungsroutinen nach einem Zeitplan ausgeführt werden (und Quintiqs DSL bedeutet, dass Sie benutzerdefinierte automatische Verhaltensweisen programmieren können), aber auch hier ist es so autonom, wie es der Implementierer programmiert. GAINS, Relex, Netstock und andere Nischenanbieter werben alle mit “End-to-End-Automatisierung” in der Wiederbeschaffung - was in der Regel bedeutet, dass sie automatisch Bestellungen generieren oder Lagertransferempfehlungen abgeben können. Der entscheidende Unterschied liegt darin, wie viel Überwachung erforderlich ist: Ein wirklich autonomes Planungssystem würde nur in ungewöhnlichen Situationen Menschen anrufen und seine Entscheidungen mit Begründung dokumentieren. Wir haben keinen Anbieter gefunden, der dieses Ideal vollständig erreicht. Sie erfordern entweder, dass Menschen Anpassungen vornehmen und genehmigen (meistens) oder automatisieren nur die einfachsten Entscheidungen und überlassen den Rest den Menschen.

Zusammenfassung zur Automatisierung: Nur wenige Anbieter (insbesondere Lokad) geben öffentlich Einzelheiten zu einem Automatisierungsrahmen bekannt, der unbeaufsichtigte, API-gesteuerte Planungszyklen ermöglicht. Andere verfügen zwar über die technischen Mittel zur Automatisierung, verlassen sich jedoch immer noch auf Menschen, um den Kreis zu schließen. Wir stellen auch fest, dass einige Anbieter ihren Fokus in den letzten Jahrzehnten von vollständiger Automatisierung auf “Ausnahmemanagement” verlagert haben - was im Wesentlichen einen halbautomatisierten Ansatz darstellt, bei dem die Software das tut, was sie kann, und den Rest für Menschen markiert ³⁸. Dieser Ansatz kann zwar praktisch sein, kann aber eine Stütze für Software sein, der nicht robust genug ist, um vollständig vertraut zu werden. Unsere skeptische Meinung 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 vs. On-Disk und allgemeine Designentscheidungen - hat enorme Auswirkungen auf die Skalierbarkeit, Kosten und Leistungsfähigkeit einer Supply-Chain-Software. Wir haben den Kern-Technologie-Stack jedes Anbieters mit einem Fokus darauf untersucht, wie sie mit großen Datenmengen und komplexen Berechnungen umgehen.

In-Memory-Computing – Vor- und Nachteile: Mehrere der führenden Anbieter verlassen sich 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 schnell darauf zugreifen zu können. Dazu gehören Kinaxis, Anaplan, o9, SAP HANA (IBP), Relex und möglicherweise Quintiq (für die Lösung von Szenarien). Der Vorteil liegt in der Geschwindigkeit: Der Zugriff auf den RAM ist um Größenordnungen schneller als auf die Festplatte. Zum Beispiel platziert der Motor von Kinaxis alle Daten im Speicher, um eine sofortige Neuberechnung von Szenarien und direkte algorithmische Operationen auf dem Datensatz zu ermöglichen ⁹. SAPs HANA wurde mit der Prämisse entwickelt, dass die Analyse von Live-Daten in Echtzeit im Speicher erfolgen sollte, um sofortige Ergebnisse zu erzielen ⁴⁰ ⁴¹. Es gibt jedoch ein grundlegendes Problem bei einem reinen In-Memory-Design: Kosten und Skalierbarkeit. Der Speicher (RAM) ist im Vergleich zur Speicherung extrem teuer. 1 TB RAM kann 100-mal 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 mehrere Terabyte oder Petabyte große Datensätze in großen Lieferketten üblich sind). In den letzten Jahren sind die erwarteten drastischen Preisrückgänge bei RAM nicht eingetreten - RAM-Preise und Kapazitäten sind ziemlich stagniert ⁴². Das bedeutet, dass jedes System, das alle Daten im Speicher erfordert, enorme Infrastrukturkosten hat, wenn die Datenmenge wächst, oder an eine harte Grenze stößt, an der die Daten einfach nicht mehr hineinpassen. Wir bezeichnen eine starke Abhängigkeit von einem In-Memory-Design als einen architektonischen Fehler für große Lieferketten, es sei denn, er wird gemildert.
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 usw. ⁴³ ⁴⁴. Einige Supply-Chain-Software hat 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 plus schnellem NVMe-SSD für Überlauf verarbeiten ⁴⁵ ³. Sie erreichen eine nahezu RAM-Performance durch das Speichern von Dateien im Speicher und das Beibehalten der heißesten Daten im RAM, wobei die Software intelligent bei Bedarf tauscht ⁴⁶ ⁴⁷. Dieser Ansatz führt zu enormen Kosteneinsparungen - z.B. für den Preis von 18 GB hochwertigem RAM kann man 1 TB NVMe-SSD kaufen ³, also ist es pro Byte 50-mal billiger, während es nur ~6-mal langsamer im direkten Zugriff ist, ein Kompromiss, der oft lohnenswert ist. Keiner der auf In-Memory zentrierten Anbieter (Kinaxis, SAP, o9 usw.) hat eine solche adaptive Speicherverwaltung öffentlich beschrieben, was darauf hindeutet, dass ihre Lösungen möglicherweise einfach viel RAM erfordern oder eine Datenaggregation erfordern, um zu passen. Anaplan hat Probleme mit Modellgrößenbeschränkungen - einige Kunden stoßen an die Speichergrenzen seines Hyperblocks und müssen Modelle aufteilen. Kinaxis benötigt wahrscheinlich auch mehrere miteinander vernetzte Server für sehr große Daten (sie haben ein Konzept der Datenverteilung, aber innerhalb jedes Knotens ist es im Speicher). 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 brillant für kleine bis mittlere Daten funktionieren, aber wenn die Lieferkette wächst (denken Sie an eine detaillierte SKU-Store-Day-Level-Planung für einen globalen Einzelhändler), steigen die Kosten und Leistungsrisiken enorm. Moderne Technik bevorzugt eine Mischung aus Speicher- und Festplattennutzung, um Geschwindigkeit und Kosten auszugleichen, und Anbieter, die das nicht tun, hinken hinterher.
Technologie-Stack und Komplexität: Über den Speicher hinaus ist ein weiteres architektonisches Element der Gesamttechnologie-Stack - monolithisch vs. Microservices, Verwendung moderner Programmiersprachen usw. Ohne zu tief einzugehen, haben wir beobachtet, dass ältere Anbieter (SAP APO/IBP, Blue Yonder) auf monolithischeren, veralteten Stacks laufen, während neuere (o9, Anaplan) ihr eigenes Ding von Grund auf mit neuerer Technologie aufgebaut haben. Zum Beispiel beinhaltet der Kern von SAP IBP immer noch Engines aus den 2000er Jahren (wie den Optimierer von APO), die jetzt in einer HANA/Cloud-Schicht eingewickelt sind. Das führt zu Komplexität und potenzieller Ineffizienz (mehrere Abstraktionsebenen). Blue Yonder hat ähnlich viel Legacy-Code aus den i2- und JDA-Tagen. Kinaxis ist etwas einzigartig - es ist alt (begann in den 90er Jahren), aber sie haben kontinuierlich in ihren eigenen Datenbank-Kernel refaktoriert; dennoch ist es ein proprietärer Stack, den nur sie verwenden. Anaplan hat einen sehr effizienten Berechnungsmotor (in Java) für seinen spezifischen Anwendungsfall (Hyperblock) entwickelt, der für diesen Zweck optimiert ist - aber er ist nicht offen und man muss mit seinen Einschränkungen leben (z.B. keine SQL-Abfragen, begrenzte algorithmische Komplexität, da es sich um mehr zellbasierte Berechnungen handelt). o9’s Plattform umfasst eine Mischung aus Technologien (wahrscheinlich eine NoSQL/Graphdatenbank, vielleicht Spark oder ähnliches für ML usw.), was sie theoretisch flexibel, aber komplex macht.
Hardware und Cloud: Ein bemerkenswerter Trend ist das Cloud-native Design. Viele Anbieter bieten ihre Software jetzt als SaaS an 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 allokiert Ressourcen dynamisch). SAP IBP ist cloud-gehostet, aber im Grunde genommen ist jeder Kunde eine isolierte Instanz auf HANA (nicht Multi-Tenant im gleichen Sinne). ToolsGroup, Blue Yonder bieten SaaS-Lösungen an, aber oft handelt es sich dabei nur um ihre On-Prem-Software, die von ihnen in der Cloud verwaltet wird. Warum ist das technisch wichtig? Cloud-native Architekturen sind typischerweise elastischer - sie können die Rechenleistung bei Bedarf erhöhen (für einen großen Planungslauf) und danach reduzieren, um möglicherweise die Kosten zu kontrollieren. Nicht-Cloud-Systeme erfordern oft den Kauf von Spitzenkapazitäten, auch wenn sie nur gelegentlich genutzt werden. Außerdem können Cloud-native Systeme möglicherweise besser mit anderen Cloud-Services integrieren (zum Beispiel Anbindung an einen Cloud-ML-Service oder Data Lake). Nach unseren Erkenntnissen scheinen die cloud-nativsten, von Grund auf skalierbaren Lösungen Lokad und o9 (und vielleicht Anaplan) zu sein, während andere aufholen. Allerdings bedeutet allein Cloud-Native nicht automatisch eine gute Architektur - o9 ist cloud-nativ, aber wir haben seinen in-memory schweren Ansatz in Frage gestellt; SAP IBP ist zwar in der Cloud, aber das beseitigt nicht seine Komplexitätsprobleme.
Parallelität und Echtzeit-Anforderungen: Eine architektonische Überlegung ist, wie das System mit gleichzeitigen Benutzern und Echtzeit-Updates umgeht. 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 Datenversionsverwaltung und Sperrlogik - was Kinaxis über ihren Branching-Mechanismus erreicht hat ⁸. Die meisten anderen Tools folgten traditionell einem Batch-Paradigma (Planung, Veröffentlichung, dann separate Zusammenarbeit). Jetzt fügen viele gleichzeitige Planungsfunktionen hinzu. Anaplan ermöglicht es mehreren Personen, gleichzeitig in verschiedenen Teilen des Modells zu arbeiten (da es im Wesentlichen zellbasiert ist wie Google Sheets). SAP IBP hat eine “Microsoft Excel-ähnliche” Benutzeroberfläche eingeführt, die Daten auf Abruf vom Server aktualisieren kann, aber echte Parallelität (mehrere Benutzer, die gleichzeitig den gleichen Plan bearbeiten) ist begrenzt. o9 unterstützt wahrscheinlich eine gewisse Parallelität aufgrund seines Wissensgraphen (mehrere Benutzer können verschiedene Knoten anpassen). Bei der Bewertung des technischen Werts zeigt ein System, das wirklich in Echtzeit mit vielen Benutzern arbeiten kann, eine robuste Architektur an. Kinaxis und Anaplan punkten hier. Es ist nicht so, dass andere es nicht können, aber oft machen es ihre älteren Architekturen schwierig - was entweder zu langsamer Leistung oder zur Erzwingung sequenzieller Prozesse führt.

Zusammenfassung zur Architektur: Wir haben ein Muster identifiziert: In-Memory-zentrierte Designs (Kinaxis, Anaplan, o9, Relex, SAP HANA) bieten Geschwindigkeit, aber auf Kosten der Skalierbarkeit und Kosten, während hybride Designs (Lokads spill-to-disk, möglicherweise Tools, die moderne Datenbanken verwenden) skalierbarer und kosteneffizienter sind. Ein klares Warnsignal ist ein Anbieter, der darauf besteht, dass alles im RAM sein muss, um zu funktionieren - dieser Ansatz gilt heute als veraltet, angesichts der Fortschritte bei SSD-Geschwindigkeit und verteiltem Computing ⁴³ ⁴⁴. Wir möchten auch darauf hinweisen, dass Anbieterarchitekturen, die aus mehreren Übernahmen stammen (wie SAP, Blue Yonder), tendenziell übermäßig komplex sind und viel Feinabstimmung erfordern. Einfachere, selbst entwickelte Architekturen (Kinaxis’ Single-Codebasis, Anaplans Single-Engine, Lokads Single-Engine) neigen dazu, technisch kohärenter zu sein und damit 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 aufgebaut ist (Microservices? Benutzerdefinierte DB? Verwendung von ML-Bibliotheken usw.). Ein Mangel an technischer Diskussion könnte bedeuten, dass die Architektur nur eine Blackbox ist - was oft auf entweder veraltete Technologie oder mangelndes Vertrauen in ihre Einzigartigkeit hinweist.

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

Die Planung der Lieferkette umfasst typischerweise mehrere Bereiche (Nachfrageprognose, Bestandsoptimierung, Produktionsplanung usw.). Einige Anbieter bieten eine integrierte Suite, die organisch aufgebaut wurde, während andere durch Übernahmen gewachsen sind und neue Module hinzugefügt haben. Wir haben uns angesehen, wie das Lösungsangebot jedes Anbieters integriert ist und welche Warnsignale sich aus ihrer Wachstumsstrategie ergeben.

Blue Yonder (JDA) ist das Paradebeispiel für Wachstum durch Übernahmen. 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), zuvor Manugistics übernommen, dann RedPrairie (für das Lagermanagement) und schließlich das Startup Blue Yonder für KI. Jedes Stück hatte sein eigenes Datenbankschema, seine eigene Logik. Das Ergebnis: selbst heute teilen Blue Yonders Bedarfsplanung, Versorgungsplanung und Bestandsoptimierung möglicherweise kein einheitliches Datenmodell - die Integration basiert auf Schnittstellen. Dies ist ein Warnsignal, denn es bedeutet, dass die Implementierung der gesamten Suite im Wesentlichen die Integration mehrerer unterschiedlicher Softwarepakete bedeutet. Wenn die Produkte eines Anbieters nicht wirklich vereint sind, stehen Kunden vor Problemen wie Daten-Synchronisierungsverzö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 zur Bestandsplanung - eine von der alten Manugistics und eine von i2). Das Unternehmen hat sich bemüht, dies zu rationalisieren, aber es ist noch nicht vollständig gelöst. In technischen Begriffen mischen sich Unternehmenssoftware nicht magisch wie Flüssigkeiten, wenn Unternehmen fusionieren ²⁹ - es bedarf jahrelanger Neugestaltung. Wir haben keine Hinweise darauf gesehen, dass Blue Yonder diese Neugestaltung abgeschlossen hat. Daher ist der Mangel an Kohärenz eine wesentliche technische Schwäche.
SAP IBP kombinierte ebenfalls erworbene Komponenten: SAPs Kauf von SAF, SmartOps und anderen brachte separate Tools ein, die SAP dann in den IBP-Dachverband integrierte ²⁷. Benutzer haben festgestellt, dass IBP verschiedene Module hat, die sich wie separate Apps anfühlen (zum Beispiel IBP für Bedarf gegen IBP für Bestand). Die Sicherheitsbestandsoptimierungslogik in IBP stammt wahrscheinlich aus der SmartOps-Übernahme, während das Nachfragesensing von SAF oder internen Entwicklungen stammen könnte. Die Integration ist besser als bei Blue Yonder (SAP hat zumindest die Benutzeroberfläche neu geschrieben und alles auf die HANA-Datenbank gesetzt), aber dennoch ist IBP unter der Haube keine Single-Codebasis. SAP warnt ausdrücklich davor, 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 ein Warnsignal - sie deutet auf mögliche Inkonsistenzen und Komplexität hin.
Infor (obwohl nicht unter den Top 10 oben genannt) hat ebenfalls verschiedene Planungssysteme fusioniert (sie hatten Mercias Supply-Chain-Planung und GT Nexus usw. übernommen). Das Ergebnis war nie eine wirklich vereinigte Planungsplattform; Infor neigt dazu, sich auf Ausführungssysteme zu konzentrieren. Es ist also ein weiteres Beispiel, bei dem Übernahmen kein großartiges integriertes Planungsprodukt hervorgebracht haben.
Dassault (Quintiq): In diesem Fall hat die Übernahme (durch Dassault) nicht die Fusion von Quintiq mit einem anderen Planungstool beinhaltet - Dassault ließ Quintiq mehr oder weniger als eigenständiges Angebot weiterlaufen, das sich auf die Optimierung von Produktion/Planung konzentriert. Daher ist die interne Kohärenz von Quintiq in Ordnung (sie wurde intern entwickelt und bleibt so), aber der Nachteil ist, dass es nicht alle Bereiche abdeckt (z. B. keine native Nachfrageprognose, wie bereits erwähnt ¹⁶). Das Portfolio von Dassault umfasst andere Produkte (wie Apriso für MES usw.), aber sie sind nicht tiefgreifend mit Quintiq integriert. In Bezug auf Integration ist Quintiq also selbstkonsistent, aber funktional eng. Aus der Sicht eines Benutzers müssten Sie es möglicherweise mit einem anderen Prognosetool integrieren, was zusätzliche Arbeit auf der Client-Seite bedeutet.
Kinaxis ist größtenteils organisch gewachsen - es hat 2020 ein kleines KI-Unternehmen Rubikloud (für KI im Einzelhandel) und ein Supply-Chain-Design-Tool (Castle Logistics) erworben, aber diese sind relativ neu 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 (Bedarf, Angebot, Bestand) teilen eine Datenbank und Benutzeroberfläche in Kinaxis. Ebenso hat Anaplan verschiedene Planungs-“Apps” auf einer Plattform entwickelt - Verkaufs-, Finanz- und Supply-Chain-Pläne befinden sich alle in der gleichen Hyperblock-Umgebung, die technisch sehr kohärent ist (nur unterschiedliche Modellvorlagen). o9 Solutions ist ebenfalls eine organisch entwickelte Einzelplattform, die viele Bereiche abdeckt (sie ist nicht gewachsen, indem sie andere Planungsanbieter übernommen hat, zumindest keine großen). Diese drei - Kinaxis, Anaplan, o9 - haben einen architektonischen Vorteil der Einheit. Die Vorsicht bei ihnen betrifft nicht die Integration unterschiedlicher Module, sondern ob ihre eine Plattform wirklich die Tiefe in jedem Bereich bewältigen kann.
ToolsGroup & Slimstock: Diese Anbieter haben sich auf ihre Nische (Bedarfs- und Bestandsplanung) konzentriert. Sie haben keine anderen Unternehmen übernommen; stattdessen arbeiten sie bei Bedarf mit Ausführungssystemen zusammen oder integrieren sie. Das bedeutet, dass ihre Software intern konsistent ist (eine Codebasis), was gut ist, aber wenn ein Kunde umfassendere Funktionen benötigt (wie Produktionsplanung), müssen sie ein anderes Produkt verwenden und 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 erworben, aber auch diese wurden in das Kernprodukt integriert, anstatt separat verkauft zu werden. Die Integration ist also kein großes Problem für ToolsGroup oder Slimstock - der Kompromiss besteht darin, ob ihr Design mit Einzelfokus genügend Umfang für die Bedürfnisse des Benutzers abdeckt.

Zusammenfassung zur Integration: Aus skeptischer Sicht sind mehrere große Übernahmen in der Geschichte eines Anbieters ein Warnzeichen. Oft führt dies zu einem Produkt, das in allem gut ist, aber in nichts Meister, mit versteckter Komplexität. Blue Yonder und SAP sind Beispiele dafür - ihre technische Komplexität stammt teilweise daher, dass sie versuchen, viele geerbte Teile zusammenzufügen. Im Gegensatz dazu vermeiden Anbieter mit einer einzigen vereinheitlichten 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 Bedarfsplanungsmodul und das Angebotplanungsmodul von verschiedenen ursprünglichen Unternehmen stammen, untersuchen Sie, wie sie Daten teilen und ob die Integration nahtlos oder über Schnittstellen erfolgt. Die Geschichte hat gezeigt, dass, es sei denn, die übernommene Technologie von Grund auf in eine vereinheitlichte Architektur umgeschrieben wurde (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 entwickelt, während diejenigen mit den niedrigsten Bewertungen (Blue Yonder, Infor) unterschiedliche Technologien angesammelt haben, ohne sie vollständig zu vereinheitlichen.

Kritische Schwächen & Warnzeichen

In unserem rigorosen Review haben wir mehrere wiederkehrende Schwächen und Warnzeichen identifiziert, auf die potenzielle Benutzer achten sollten. Im Folgenden finden Sie eine Zusammenfassung der wichtigsten Probleme, mit Beispielen von spezifischen 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 proklamiert, ohne harte technische Beweise vorzulegen. Zum Beispiel bewirbt Blue Yonder stark KI, liefert jedoch nur vage Behauptungen ohne Substanz ³⁰ - das Wenige, was wir von ihren Methoden sehen können, deutet darauf hin, dass sie auf ältere Techniken und nicht auf modernste KI setzen. Ebenso preist o9 Solutions seine KI und graphenbasierte Intelligenz an, doch die Analyse ihres öffentlichen Codes und Materials zeigt “eine Menge KI-Hype” mit nur durchschnittlicher Analytik in der Realität ²⁶. Wenn ein Anbieter nicht auf peer-reviewed Studien, Patente, Wettbewerbe oder detaillierte technische Papiere verweisen kann, um ihre KI-Behauptungen zu untermauern, gehen Sie davon aus, dass es sich um Marketing-Geschwätz handelt. Wirklich fortschrittliche Anbieter werden stolz darauf sein, ihre Algorithmen im Detail zu erläutern.
Kein Wettbewerbsbenchmarking (Behauptungen zur Überlegenheit der Prognosen): Viele Anbieter behaupten “beste Prognosegenauigkeit in ihrer Klasse”, aber keiner außer Lokad hat es in offenen Wettbewerben oder Publikationen bewiesen. Wir betrachten jede solche Behauptung als unbegründet, es sei denn, sie ist validiert. Zum Beispiel wurde der proprietäre Algorithmus eines Anbieters, der damit prahlte, “genauer als andere” zu sein, nicht unter den Top-Rängen des M5-Wettbewerbs ³² gefunden, was stark darauf hindeutet, dass ihre Behauptung unbegründet ist. Tatsächlich erschien kein einziger traditioneller Anbieter von Supply-Chain-Software (außer Lokad) unter den Top 100 dieses globalen Prognosewettbewerbs. Dies ist ein großes Warnzeichen: Es deutet darauf hin, dass diese Anbieter entweder nicht teilgenommen haben (vielleicht um öffentliche Peinlichkeiten zu vermeiden) oder teilgenommen haben und schlecht abgeschnitten haben. Handlungsempfehlung: Fordern Sie objektive Genauigkeitsergebnisse ein (zum Beispiel, wie hat sich ihr Tool auf einem Standardbenchmark wie dem M5- oder M4-Datensatz geschlagen) - wenn sie keine liefern können, kaufen Sie nicht das Marketing-Geschwätz.
Übermäßige In-Memory-Architektur: Anbieter, die auf ein ausschließlich in-memory Design setzen, sollten hinsichtlich Skalierbarkeit und Kosten hinterfragt werden. In-Memory-Computing bietet Geschwindigkeit, aber RAM ist ~100x teurer pro GB als Festplatte ¹⁰ 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 teuer. 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-)Kosten garantiert ²⁴ ³¹. Es ist bezeichnend, dass moderne Systemdesigns sich von diesem Ansatz entfernen - wie ein Experte bemerkt, ist der anfängliche Hype, alles in RAM zu packen, an praktische Grenzen gestoßen, und Datenbanken “finden ihre Liebe zur Festplatte wieder”, um kalte Daten effizient zu verarbeiten ⁴³ ⁴⁴. Wenn ein Anbieter immer noch in einem reinen In-Memory-Denken feststeckt, betrachten Sie es als architektonisches Warnzeichen. Skalierbarere Anbieter werden über gestaffelten Speicher, Cloud-Elastizität oder ähnliche Strategien sprechen, um große Datenmengen zu verarbeiten, ohne unendlich viel RAM zu benötigen.
Black-Box aus M&A (Integrationsdysfunktion): Wenn das Produktportfolio eines Anbieters das Ergebnis von vielen Übernahmen ist, seien Sie vorsichtig hinsichtlich Integrationslücken und sich überschneidender Funktionalität. Wie wir gesehen haben, ist das Portfolio von Blue Yonder eine willkürliche Mischung veralteter Produkte aufgrund einer langen Reihe von Fusionen ²⁹, und die Module von SAP IBP stammen von verschiedenen übernommenen Unternehmen ²⁷, was zu Komplexität und einer “Sammlung” von Tools anstelle eines nahtlosen Ganzen führt. Unternehmenssoftware ist nicht einfach durch M&A “mischbar” ²⁹ - es sei denn, der Anbieter hat eine vollständige Neugestaltung 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. Warnzeichen-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 selbst von SAP anerkannt ²⁸. Bevorzugen Sie Anbieter mit einer einheitlichen Plattform oder minimaler Überschneidung bei übernommenen Komponenten.
Widersprüchliche Metriken und Schlagwörter: Ein subtiler, aber aussagekräftiger Warnhinweis ist, wenn die technische Geschichte eines Anbieters interne Widersprüche oder veraltete Praktiken enthält, die mit neuen Begriffen kaschiert sind. Ein offensichtliches Beispiel war ToolsGroup, die probabilistische Prognosen bewerben, während sie gleichzeitig auf MAPE-Verbesserungen verweisen ¹⁹ - ein Zeichen dafür, dass sie nur neue Begriffe auf alte Praktiken auftragen (da die Verwendung von MAPE zur Beurteilung probabilistischer Prognosen konzeptionell falsch ist). Ein weiteres Beispiel sind Anbieter, die behaupten, “fortschrittliche KI” zu verwenden, aber dann den Erfolg mit alten Metriken wie MAPE oder traditionellen Service-Levels messen - es deutet darauf hin, 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 genauer hinschauen 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), dann handelt es sich um einen Widerspruch. Wir haben tatsächlich Fälle gefunden, in denen Anbieter über “probabilistische” oder “optimale” Bestände sprechen, aber ihre Dokumentation Standard-Sicherheitsbestandsberechnungen und die Verwendung veralteter Metriken wie Füllrate offenbart. Fazit: Inkonsistenzen zwischen dem, was sie vermarkten, und dem, was sie messen/liefert, sind ein Warnsignal. Wenn ein Anbieter sich als modern und KI-getrieben präsentiert, aber 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 der Ein-Echelon- zur Mehr-Echelon-Optimierung), aber einige Software haben nicht Schritt gehalten. Die Abhängigkeit von jahrzehntealten Praktiken ist ein Schwachpunkt, insbesondere wenn Anbieter vorgeben, anders zu sein. Zum Beispiel ist ein Tool, das hauptsächlich noch Sicherheitsbestand + Wiederbeschaffungspunktlogik mit festen Vorlaufzeiten für den Bestand verwendet, nicht auf der Höhe der Zeit, wenn es die Nachfragevariabilität nicht dynamisch berücksichtigt. Wir haben festgestellt, dass Slimstock sich explizit auf traditionelle Formeln (Sicherheitsbestand, EOQ) konzentriert ²¹ - sie sind transparent, was für eine grundlegende Lösung in Ordnung ist, aber es ist offensichtlich nicht auf dem neuesten Stand. Wenn ein angeblich fortschrittlicher Anbieter nicht transparent ist, könnten sie dasselbe tun, es aber nicht zugeben. Ein weiteres Beispiel: Die Open-Source-Schnipsel von Blue Yonder wiesen auf ARMA-Modelle hin ⁴⁸, die Techniken zur Prognose aus den 1970er Jahren sind, auch wenn ihr Verkaufsdeck von KI spricht. Infor, Oracle, John Galt und andere in der unteren Ebene verlassen sich ebenfalls oft auf Zeitreihenmethoden und Heuristiken, die schon immer existieren (wie Winters exponentielle Glättung, einfache Optimierungslöser) - sie funktionieren, aber daran ist nichts Modernes. Der Warnhinweis besteht nicht darin, alte Methoden an sich zu verwenden (alte Methoden können in einigen Fällen immer noch die besten sein), sondern darin, sie zu verwenden, während man behauptet, innovativ zu sein, oder sie ausschließlich zu verwenden, wenn bessere Methoden für das Problem existieren. Erkundigen Sie sich immer, welche Algorithmen tatsächlich verwendet werden (z.B. “Berücksichtigt Ihre Bestandsoptimierung die gesamte Verteilung der Nachfrage oder nur einen einzelnen Servicefaktor? Verwenden Sie eine Mehr-Echelon-Optimierung oder nur Berechnungen für einzelne Knoten?”). Ausweichende oder vage Antworten deuten darauf hin, dass die Methodik veraltet sein könnte.
Fehlende technische Transparenz: Schließlich ein meta Warnhinweis: Wenn ein Anbieter keine technische Dokumentation bereitstellt - keine Whitepaper, keine Referenzarchitektur, keine Erklärung der Algorithmen - ist dies selbst ein Warnzeichen. In unserer Forschung haben Anbieter, die technisch gut abschnitten (Lokad, Kinaxis, SAS usw.), zumindest etwas technischen Inhalt verfügbar (sei es Blogs, wissenschaftliche Arbeiten oder technische Notizen). Anbieter, die schlecht abschnitten, 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 erhalten hauptsächlich glänzende Broschüren. Lokad hat dagegen eine 18-seitige detaillierte Marktstudie veröffentlicht (die wir reichlich zitiert haben), die die Ansätze der Anbieter vergleicht ⁴⁹ ²⁹ ²⁵, sowie Videos darüber, wie ihre Algorithmen funktionieren. Wenn ein Anbieter verschwiegen ist, wie seine Lösung funktioniert, muss man sich fragen, ob es daran liegt, dass sie tatsächlich nichts Besonderes ist. Transparenz korreliert mit Glaubwürdigkeit. Ein Anbieter, der sich hinter Schlagwörtern versteckt und seine Methoden nicht offenlegt, hat wahrscheinlich “gewöhnliche Technologie mit zusätzlichem Lippenstift”.

Abschließend zeigt die Anwendung einer hochgradig skeptischen, ingenieurlastigen Perspektive, dass viele “führende” Softwarelösungen für die Optimierung der Supply Chain viele Versprechungen machen, aber wenig überprüfbare Innovation bieten. Indem wir uns durch den Marketing-Schwulst hindurchgearbeitet haben, haben wir uns auf das Konzentriert, was greifbar ist: 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, Unklarheiten und veraltete Grundlagen offenbarten. Diese Studie dient als Erinnerung an jeden Supply Chain-Praktiker: Nehmen Sie die Behauptungen der Anbieter nicht einfach so hin. Fordern Sie Beweise an, schauen Sie unter die Haube und denken Sie daran, dass in der Supply Chain, wie in der gesamten IT, die wirklich fortschrittlichen Entwicklungen in der Regel durch offene Wissenschaft und solide Ingenieurskunst gestützt werden - nicht nur durch hochtrabende Marketingaussagen.

Fußnoten

“Auf die Festplatte schreiben in .NET” ⁴⁵: Auf die Festplatte schreiben in .NET
“Marktstudie, Anbieter für Supply Chain-Optimierung” ⁴⁴: Marktstudie, Anbieter für Supply Chain-Optimierung
“Warum Datenbanken ihre alte Liebe zur Festplatte wiederentdeckt haben” ⁴⁴: Warum Datenbanken ihre alte Liebe zur Festplatte wiederentdeckt haben | TUMuchData
“Warum Datenbanken ihre alte Liebe zur Festplatte wiederentdeckt haben” ⁴⁴: Warum Datenbanken ihre alte Liebe zur Festplatte wiederentdeckt haben | TUMuchData