サプライチェーン計画および予測ソフトウェア、2025年2月

By Léon Levinas-Ménard

最終更新日：2025年2月2日

サプライチェーン計画ソフトウェアは、不確実性の中での意思決定の最適化（何を生産するか、在庫をどうするか、いつ移動するか）を意味します - ただし、取引を記録するだけではありません。ある定義では、サプライチェーンは*「変動と制約に直面したときの選択肢の量的でありながら実践的なマスタリー… 根底のオペレーションの直接的な管理ではなく、選択育成と選択育成に焦点を当てる」*とあります¹。言い換えれば、最高の計画ツールは最適化（たとえば、最適な在庫や生産レベルを決定すること）に焦点を当てており、単なる取引管理（注文と在庫の追跡）ではありません。この研究は、世界中の主要なサプライチェーン計画および予測ソフトウェアベンダーを比較し、具体的な技術的証拠を重視しています。各ベンダーを主要な基準で評価します：

確率的予測 - ポイント予測を超えて、完全な分布や高度なモデルを提供していますか？「AI/ML」予測が主張されている場合、M5などのグローバル予測コンペティションでの優れたパフォーマンスなどの証拠はありますか？
自動化の程度 - システムは、定期的な人間のいじりなしに予測と計画を実行できますか（完全にロボット化）？意思決定能力はどれだけ自律していますか？
拡張性とパフォーマンス - テクノロジーは大規模なデータを効率的に処理できますか？（データが増えるにつれてスケールしないメモリアーキテクチャに注意してください。メモリコストが停滞します。）
テクノロジーの統合と買収 - 解決策は、一貫したテックスタックまたは取得されたモジュールのパッチワークに基づいて構築されていますか？長いM&Aの歴史は、断片化された一貫性のないテクノロジーにつながる可能性があります。
技術的信頼性 - ベンダーの技術的主張は科学的原理またはエンジニアリングの証拠で裏付けられていますか？我々は具体的な説明や同僚の検証のためにバズワード（「AI/ML」、「需要感知」）を超えて見ます。
一貫性と矛盾 - ベンダーのメッセージは一致していますか？（たとえば、確率的予測を主張しながらMAPEなどの確定的精度メトリクスを宣伝することは警告信号となります。）
時代遅れの慣行 - 現代の確率的最適化と矛盾する古い方法（単純な安全在庫の式など）を指摘します。
意思決定指向の出力 - ソフトウェアは単に予測を生成するだけなのか、それらの予測に基づいて最適化された意思決定（注文計画、在庫ターゲット）を提供していますか？真の目標は、数字だけでなく、意思決定を促進することです。

アプローチ： 各ベンダーについて、公開された技術文書、信頼できる分析、および（利用可能な場合は）オープンなベンチマークや競技会を評価するために頼ります。ベンダーの煽り、有料アナリストレポート、光沢のある事例研究は、ハードエビデンスで検証されていない限り無視されます。トーンは故意に懐疑的です - 主張はデータやエンジニアリングの実質で獲得しなければなりません。一貫性や透明性の欠如は、重大な弱点と見なされます。

以下では、まず、技術的リーダーシップによってトップのサプライチェーン計画ソフトウェアベンダーをランク付けし、それぞれについて簡単な理由を示します。ランキングの要約の後に、上記の技術基準に従って詳細な比較が続きます。すべての声明は信頼できるソースへの引用（形式【ソース†行】）で裏付けられています。

技術的卓越性によるトップベンダーのランキング

Lokad – 最先端の確率的最適化
Lokadは技術革新のリーダーであり、確率的予測と真に意思決定中心の計画を先駆けています。2012年には、Lokadは確率的予測を推進し（他のほとんどの企業よりもほぼ10年も前に）、その全ソリューションをそれに基づいて構築しました²。予測と計画を別々のステップとして扱うベンダーとは異なり、Lokadのシステム（Envisionと呼ばれるドメイン固有言語に基づく）は確率モデルから最適化された意思決定（注文、在庫レベル）を直接生成します。Lokadの技術的信頼性は卓越しており、その手法を公開文書化しており、チームは権威あるM5予測競技会でSKUレベルで第1位の精度を達成しました（909チーム中）³。この粒度の細かい予測での実績は、Lokadの最先端の予測能力を裏付けています。このプラットフォームはクラウドネイティブであり、完全に自動化されています（予測と最適化はスケジュールに従って監視なしで実行されます）、そしてスケーラブルなクラウドコンピューティングを活用することでインメモリ設計の制約を回避しています。要するに、Lokadはサプライチェーン最適化において確率論、自動化優先、エビデンスに基づいたアプローチで基準を設定しています。
Kinaxis – 高速、インメモリ計画と新興AI
Kinaxisは、その瞬時の「同時計画」エンジンで知られる確立されたリーダーです。そのRapidResponseプラットフォームは、サプライ、需要、在庫全体にわたるリアルタイムシナリオシミュレーションを可能にするインメモリアーキテクチャを使用しています。この設計により、プランナーは瞬時のwhat-if分析能力を持ち、迅速な対応力を発揮できます。ただし、インメモリ計算への重大な依存は、データが増えるにつれて高いハードウェアコストとスケーラビリティの制限を意味する場合があります（大規模な展開には膨大なRAMが必要です）⁴。従来、Kinaxisは確定的計画に焦点を当てていました（ユーザー定義のルールと手動調整を活用）。業界の変化に気づいたKinaxisは、最近、買収/提携を通じて確率的手法を取り入れています。例えば、パートナーのWahupaから確率的多段階在庫最適化（MEIO）エンジンを追加し、需要予測のためのAI企業（Rubikloud）を買収しました。これらの追加機能により、Kinaxisには高度な予測と不確実性モデリングがもたらされますが、それらはボルトオンとして、テックスタックの整合性について疑問を投げかけます。Kinaxisの「AI」と機械学習に関するメッセージは、競合他社と比較して慎重です – 人間と機械の知能を組み合わせることを強調しています。実際には、Kinaxisは計画の再計算の自動化に優れており（データが変更されるたびに、システムは自律的に供給需要計画を再バランスできます）、しかし、これまではプランナーがパラメータを設定し、最終的な意思決定を完全に自動化していませんでした。新しい確率モジュールを備えたKinaxisは、より不確実性の下での意思決定の自動化に向けて進んでいますが、確定論的な遺産からの移行です。要するに、Kinaxisは強力なリアルタイム計画プラットフォームを提供し、AI駆動の予測に追いついていますが、新しい確率的機能が表面的でなく、深く統合されていることを証明する必要があります。
o9 Solutions – 大きな野望とビッグデータ
o9 Solutionsは比較的新しい参入企業（2009年設立）であり、サプライチェーンの「デジタルブレイン」としてしばしば言及されています。技術的には、o9は非常に野心的であり、グラフベースのデータモデル（Enterprise Knowledge Graph、EKG）を備えた広範なプラットフォームを構築し、巨大で複雑なデータセットに対応しています（これにより、エンドツーエンドの計画ツールを求める大企業に人気があります）。ただし、o9のアプローチにはトレードオフが伴います。システムはインメモリ設計を使用しており、高速な分析を可能にする一方で、大規模な使用には「高いハードウェアコストを保証」すると報告されています⁴。これにより、問題にさらに多くのRAMを投入するとコストがかかり、最終的には限界に達します（特にメモリ価格が急速に下落しなくなったため）。o9はAI/MLを中心に積極的にマーケティングしていますが、その主張の多く（たとえば、その知識グラフが予測を独自に改善するという主張など）は、科学的根拠がないと疑わしいです⁵。実際、GitHubで公開されているo9の技術要素の分析では、o9は主に標準的な技術を使用していると示唆されています（大々的な「AI」ブランディングを正当化するだけの根本的に新しいものはありません）⁶。o9はある程度確率的シナリオ計画をサポートしています - 複数の需要シナリオをモデル化し、シミュレーションを実行できますが、本当の確率的予測分布を提供しているのか、単なるシナリオ分析を行っているのかは不明です。プラットフォームは特定の計画タスクを自動化できますが、o9はしばしば自らを意思決定支援と位置付けており、最終的には人間が「デジタルブレイン」を導いています。全体として、o9は幅広い機能を備えた技術重視のプラットフォームですが、インメモリコンピューティングへの依存とAIの主張に対する曖昧さが、その技術的リーダーシップを抑制しています。o9は、統合ビジョンとビッグデータの取り扱いにおいて、独自の予測精度よりもリーダーです。
Relex Solutions – 小売業に焦点を当てた自動化（限界あり）
Relex Solutions（2005年設立）は、小売業の需要予測、補充、スペースプランニングに特化しています。いくつかの大手食料品店は、Relexを使用して店レベルの需要を自動的に予測し、人間の介入を最小限に抑えて注文を生成しています。この小売環境でのエンドツーエンドの自動化は注目すべき強みです。Relexはまた、小売業向けに調整された現代の機械学習予測技術を売りにしています（プロモーション、地域イベントなどを考慮しています）。ただし、その裏側を見ると、いくつかのアーキテクチャ上の制約や方法論上の制限が明らかになります。Relexのシステムは、非常に高速な分析とレポートを提供するためにインメモリ、OLAPスタイルのデータキューブ設計を使用しています⁷。これにより、素早いダッシュボードが提供されますが、これはハードウェアコストを増加させ、複雑な最適化問題を本質的に解決しません。実際、Relexのリアルタイムで詳細なアプローチは、ネットワーク全体の最適化と相反することがあります - 製品のカニバリゼーションや代替品などの現象に直面した際に、大規模な供給ネットワーク全体での意思決定を最適化するのに苦労する可能性があります⁸。また、Relexの予測モデルがマーケティングされているほど「次世代」ではないことを示す兆候があります - 証拠によると、彼らのアプローチの多くは2000年以前の手法（例：回帰、時系列平滑化）に依存しているとされています⁹、大規模に適用されていますが。小売業者の99％以上の在庫可用性を自慢することがよくありますが、業界調査（例：ECR協会によるもの）では、典型的な店頭在庫の可用性は低いことが示されており、このような一般的な主張に疑問が呈されています¹⁰。Relexは主に小売業向けに社内で構築されたほぼ一貫したテックスタックを持ち、大規模な買収を通じて成長していないため、一貫性があります。要約すると、Relexは小売業の自動化のリーダーであり、印象的なハンズオフ運用を実現できますが、予測科学の技術的深さは議論の余地があり、インメモリアーキテクチャは他の課題と同様のスケーラビリティの懸念を抱えています。
ToolsGroup – 初期のイノベーターが今「AI」を謳っている
ToolsGroup（1993年創立）は、SO99+ソフトウェアを提供しており、サービスレベル志向の予測と在庫最適化で歴史的に知られています。 “AI"が流行語になる何年も前、ToolsGroupはサプライチェーンで確率的概念を普及させるのに役立ちました。たとえば、需要の変動をモデリングして、所望のサービスレベルを達成するために必要な安全在庫を決定することなどです。実際には、彼らのツールは需要の確率分布を生成し（特に動きの遅いアイテムに対して）、目標のフィル率を達成するための在庫ターゲットを計算できます。しかし、最近、ToolsGroupのメッセージはAI/MLのハイプに参加するように変わり、ここで信頼性の欠点が現れます。彼らは「AIパワード」の計画を大々的に宣伝していますが、公開された手がかりは、彼らのコアアルゴリズムが基本的にはレガシー（2000年以前）の統計モデルであることを示しています ¹¹。特筆すべきは、2018年頃から、彼らは出力を「確率的予測」としてブランド化し始め、同時にMAPEの改善を自慢しています ¹² – これは明白な矛盾です。なぜなら、MAPE（確定的な予測誤差メトリック）は*「確率的予測には適用されない」*からです ¹³。これは、誤解かマーケティングの手品（たとえば、彼らが確率的予測を生成しているが、それらを中央値と実際の値とMAPEで比較して評価している可能性があるため、確率的手法のポイントを見逃している）を示唆しています。ToolsGroupはまた、短期予測の調整のための「需要センシング」を強調していますが、そのような主張は科学的文献に支持されておらず ¹³、しばしば再パッケージ化された移動平均に過ぎません。良い面では、ToolsGroupのソリューションはサプライチェーンプランニングのためにかなり機能が揃っており（需要予測、在庫最適化、S&OPなどをカバー）、ライトアウトモード（毎晩自動的に補充提案を生成する）で実行できます。その最適化の焦点（最小限の在庫でサービスターゲットを満たす）は、意思決定志向の予測と一致しています。しかし、最近のAIのポストリングと明確な技術的証拠の欠如、および現代的なクラウドネイティブではない可能性のあるアーキテクチャ（おそらくより単一サーバー志向）により、技術リーダーシップで少し後退しています。要するに、ToolsGroupは確率的在庫モデリングの実績のあるプレーヤーですが、新しいAIの主張を裏付け、その手法が停滞していないことを保証するためには、より多くの透明性が必要です。
Blue Yonder – パワフルなレガシー、パッチワーク技術
Blue Yonder（1985年にJDAソフトウェアとして設立され、後にBlue Yonderという名前の小さなAI企業を買収した後にブランド名を変更）は、サプライチェーンプランニングの巨人です。需要計画、供給計画、小売など、さまざまなソリューションを提供しています。数十年にわたり、Blue Yonder（BY）は多くの買収を通じて大規模なポートフォリオを蓄積してきました - 供給チェーン最適化のManugisticsからi2 Technologiesの要素、そして最近ではBlue Yonder AIスタートアップまで。その結果、「無秩序な製品のコレクション、ほとんどが時代遅れ」となっています ¹⁴。技術的には、Blue Yonderのレガシーモジュール（需要予測やフルフィルメントなど）は、古い手法（ヒューリスティック予測、安全在庫を用いたルールベースの計画など）をよく使用しています。同社は現在マーケティングで「AI/ML」を誇示していますが、その主張は曖昧で内容が乏しい傾向があります ¹⁵。明らかな手がかりとして、Blue YonderはGitHub上でわずか数のオープンソースプロジェクトを持っています（たとえばtsfresh、PyDSE、Vikosなど）、これらは主に特徴抽出+ARIMA/線形回帰モデルなどの伝統的な手法であることを示唆しています ¹⁶。最新のディープラーニングや確率モデルではなく、BYの「AI」はおそらくブレイクスルーというよりもブザーである可能性があります。プラットフォームの結束は懸念事項です - プランニング、補充、在庫最適化は、シームレスに機能しない別々のエンジンとして存在する可能性があります（統合は大規模な実装作業に依存しています）。Blue Yonderには、特定の分野で非常に強力な最適化機能がいくつかあります（たとえば、サプライチェーンネットワーク最適化のためのレガシーi2アルゴリズムが近代化されれば、強力になるかもしれません）。そして多くの大企業がBlue Yonderを実行して計画タスクを自動化しています（たとえば、MRPプロセスを駆動する予測を生成したり、安全在庫レベルを設定したりするなど、プランナーが例外を調整する）。しかし、新しいテクノロジーリーダーと比較すると、Blue Yonderは技術的に停滞しているように見えます：決定論的予測にほぼ固執しており（MAPEやバイアスなどの古いメトリクスでよく測定されています）、中央計画要素として安全在庫の式などの時代遅れの手法を使用し、AI用語をほんのりと重ねています。リソースを考えると、Blue Yonderは進化する可能性がありますが、現時点では大手ベンダーのトレードオフを示しています：幅広い機能性がある一方で、断片化し、経年劣化した技術スタック ¹⁴。技術的な観点から見ると、より前向きな競合他社よりもランクが下がっています。

(その他の注目すべきベンダー：SAP IBPおよびOracle SCM Cloudもサプライチェーンプランニングスイートを提供していますが、これらは主にトランザクショナルERPシステムの拡張機能です。これらは、レガシーシステムと買収から複雑な技術的負債を引き継いでいます。たとえば、SAPのプランニング提供は、SAP APO、SAP HANA、予測のためのSAF、在庫のためのSmartOpsなどのコンポーネントの組み合わせであり、基本的には「製品のコレクション」であり、多くの統合作業が必要です ¹⁷。これらのERPに結びついたソリューションは、ある面では強力ですが、一般的には予測科学や自動化のリーダーではないため、上位ランクから除外されています。)

トップベンダーを紹介した後、確率的予測、自動化、スケーラビリティなど、各ベンダーがどのようにして確率的予測、自動化、スケーラビリティなどの観点でどのように積み重ねているかを基準ごとの分析に掘り下げ、証拠と例に重点を置いてハイライトします。この比較的な視点は、各ソリューションの強みと弱みを詳細に明らかにします。

確率的予測：決定論的モデルを超えて

現代のサプライチェーン最適化は、確率的予測から莫大な利益を得ています - 単一の「最も可能性の高い」数値ではなく、可能な結果の範囲や分布（確率付き）を推定することです。確率的予測は需要の変動性をよりよく捉え、より堅牢な意思決定を可能にします（たとえば、X単位の在庫をストックした場合の欠品の確率を知ること）。私たちは、どのベンダーが真に確率的手法を採用しているか、決定論的予測に固執しているかを調査しました。主な調査結果：

Lokadは確率的予測を深く組み込んでいることで際立っています。確率モデルの普及を早くから推進してきました（2012年以降）² そしてその能力を継続的に向上させてきました。 Lokadのアプローチは、確率的需要分布をすべての最適化の基盤として使用しています - たとえば、需要分布を通じてさまざまな在庫数量の期待利益を計算することなどです。 Lokadの予測技術の信頼性は、グローバルな競技会によって確認されています：Lokadチームは、M5予測コンペティションでSKUレベルで最高の精度を達成しました³、これは高い評価を受けるベンチマークチャレンジです。重要なのは、M5はすべて確率的予測に関するものであり（ランキングは重み付けされた分布誤差メトリクスに基づいていました）、Lokadのパフォーマンスは、精度の高い確率分布を細かいレベルで生成する方法が本当に最先端であることを示しています。実際には、Lokadは単なる数値ではなく、各アイテムの需要に対する完全な確率分布（またはシナリオ）を生成し、これが直接意思決定の最適化スクリプトにフィードされます。
ToolsGroupは、サービスレベルの最適化の文脈で数年にわたって確率的機能を提供してきました。彼らのソフトウェアは、明示的な需要分布を作成できます（しばしば断続的な需要モデルや他の統計的適合を介して）その後、所望のサービス確率を満たすための在庫目標を計算します。ただし、モデルの下に確率的モデルを持っていることと、それを精神的に完全に受け入れることとの違いがあります。 ToolsGroupの2018年以降のマーケティングは、確率的予測のリーダーとしての再ブランド化を試みていることを示唆していますが、同時に確率的予測と並行してMAPEの改善についても話しています¹³。これは矛盾しています - もし本当に分布を予測しているなら、成功を主にMAPEで測定するべきではありません（これは単一の「正しい」数値を想定しています）。確率的メトリクスにまだ依存しているという事実は、彼らがまだ点予測を生成し、その後在庫要件をシミュレートするためだけに分布を使用している可能性があることを示しています。したがって、ToolsGroupは確率的機能を持っていますが、その方法の洗練度は最先端ではないかもしれず、確率的にすべてを行っているか、単なるアドオンとして使用しているかは不明です。
Kinaxisは、*コアオファリングで確率的予測を提供していませんでした（ユーザーによるポイント予測または単純な統計によって生成された予測に依存していました）。このギャップに気づいたKinaxisは、**確率的MEIO（Multi-Echelon Inventory Optimization）**エンジンを組み込むためにWahupaと提携しました¹⁸。さらに、Kinaxisは機械学習需要予測に特化したAI企業（Rubikloud）を買収しました（おそらく確率的な性質であり、予測区間を生成するなど）。2023年時点で、Kinaxisは「Planning.AI」などの機能をマーケティングし始め、意思決定に確率科学を使用し、「不確実性を受け入れる」必要性を明示的に認識しています¹⁹。これは前向きな展開ですが、比較的新しいため、Kinaxisの確率的予測の成熟度はまだ進化中です。Kinaxisまたはその関連企業が公開予測コンペティションに登場したり、詳細な方法論を公開したりするのを見たことがないため、彼らの確率的能力の技術的証拠は、彼らが主張する範囲に限られています。
o9 Solutionsも概念的に不確実性モデリングを強調しています - 彼らのナレッジグラフには多くの因果要因を保存でき、データをリンクさせることでより良い予測を生成できると主張しています。しかし、o9が実践で確率的予測を提供しているという公的な証拠は見当たりません（公開された精度ベンチマークやオープンアルゴリズムはありません）。彼らの資料におけるベイジアンネットワークやモンテカルロの言及はわずかです。o9のコードリポジトリで発見された要素は、新しい確率的アルゴリズムではなく、典型的な予測技術に焦点を当てているようです⁶。o9が逆を証明するまで、o9が主に向上した決定論的予測を提供していると仮定しなければなりません（シナリオ分析を行うかもしれません）、そして「確率的」のラベリングは主にマーケティングである可能性があります。
Relex Solutionsは、変動性（特にプロモーションや新鮮な商品の場合）が高い小売業に取り組んでいます。彼らはおそらく内部でいくつかの確率的アプローチを使用しています（たとえば、プロモーション商品の需要分布を推定したり、サービスレベルを目標として店舗ごとの安全在庫ニーズを計算したりするために）。しかし、Relexの公開資料では「確率的予測」を明示的に宣伝していません。彼らは通常、機械学習による予測精度の向上について話しています（通常はより良いポイント予測を意味します）。Relexのピアレビューによると、彼らの予測技術は2000年以前のものであることが示唆されており⁹、これはおそらく指数平滑化などの主に決定論的な手法、おそらく季節性やトレンドを伴う手法を意味します - ポイント予測を生成し、おそらく安全在庫の標準偏差を生成する手法。したがって、Relexはユーザーに完全な確率曲線を提供するのではなく、予測してからバッファを追加するという古いパラダイムに依存している可能性があります。
Blue Yonderは、従来の需要計画ではさまざまな統計モデル（ARIMA、指数平滑化、因果要因のいくつかの機械学習など）を使用して予測を行い、通常は集約され、コンセンサスプロセスで行われます - 基本的には決定論的です。 Blue Yonderは一部の文脈で確率的用語を言及し始めました（誰もがそうしているため）、しかし、彼らのオープンソースの貢献はARIMAと回帰に依存していることから¹⁶、確率的予測は強みではないと言えます。彼らはまた、MAPE、バイアスなどの決定論的なメトリクスを引き続き推奨しています。また、Blue Yonderが既知の予測ベンチマークに参加しているのを見たことはありません。
その他のベンダー：John Galt Solutionsは、優れた精度を謳う「Procast」アルゴリズムをマーケティングしていますが、レビューによると、この主張は疑わしいとされています。なぜなら、ProcastはM5などの大規模な予測コンペティションの上位ランクには登場していなかったからです²⁰。実際、利用可能なオープンソースの予測ツール（たとえば、ProphetやHyndmanのRパッケージ）はおそらく同等以上の性能を発揮するでしょう²¹。これは一般的なテーマを示しており、本当の革新は公開評価が行われる場所で現れるということを強調しています。ロカドを除くほとんどのベンダーが公開コンペティションに参加していないことは、多くのベンダーが予測において学術界やオープンソースの先を行っていないことを示唆しています - もしそうであれば、それをそのフォーラムで証明するでしょう。

要約すると、確率的予測は差別化要因です：ロカドは明確に実証された能力と完全に統合された確率的意思決定をリードしています。ToolsGroupとKinaxisはその重要性を認識していますが、最近取り入れたばかりであり（それについてのメトリクスやプロセスを説得力を持たせる必要があります）、他の多くは主に決定論的な世界に留まっており、パンフレットに「確率的」という用語を散りばめていても同じです。この違いは重要です。なぜなら、真の確率的予測がない場合、計画システムは粗い安全在庫に頼ることになり、リスクとコストを最適にバランスさせることができません。

自動化の程度：ハンズオフプランニング対ヒューマンインザループ

予測と計画の自動化は、システムが手動介入なしでデータ取り込み、予測生成、計画最適化、さらには意思決定の実行までを実行できる能力を指します - 監視と時折のパラメータ調整を除いて。高度な自動化は大規模な運用にとって重要です（何千もの予測を手動で調整することは不可能です）し、変更に迅速に対応するためにも重要です（ロボットは人間よりも速く反応します）。各ソリューションがどれだけ自動化されているか、そしてそれが**「無人」の計画**実行をサポートしているか（クライアントが実際にその方法で使用しているか）を評価しました。観察結果は次のとおりです：

Lokadは自動化を考慮して設計されています。そのEnvisionスクリプト環境を使用すると、予測と補充ロジック全体をコーディングしてスケジュールすることができます。多くのLokad展開は完全にロボット化された基盤で実行されており、システムが毎日または毎週新しいデータを自動的に取り込み、予測を再計算し、意思決定を最適化（たとえば、発注数量や割り当て計画を生成）し、それらをERPや実行システムに出力します - すべて人間の手を加えることなく。その哲学は、モデルが正しく設定されていれば、手動でのオーバーライドは最小限に抑えられ、プランナーは例外やモデルの改善に焦点を当てることができます。ルーチンの調整ではなく。Lokadの成功事例は、この自動化によるプランナーの作業量の劇的な削減をしばしば強調しています。基本的に、Lokadはプランナーをデータサイエンティストやプロセスの監督者のように扱い、毎日計画のつまみを手動で動かす人々としてではありません。
Relex Solutionsも、特に補充において高度な自動化を可能にしています。たとえば、食料品小売業者向けに、Relexは予測、在庫状況、リードタイムを考慮して毎日店舗の発注を自動的に生成できます。Relexを使用している一部の小売業者は、ほとんどの発注が自動的に出荷されると報告しており、プランナーは異常な提案のみを確認しています。Relexのシステムは例外のワークフローをサポートしています（たとえば、予測が通常と大きく異なる場合にフラグを立て、その後人間が確認します）、それ以外は需要計画と発注を自動実行するように構築されています。これは、手動計画が不可能なほど規模が大きい小売業界での重要なセールスポイントです（SKU-店舗の組み合わせが何百万もあるため）。ただし、この自動化を達成するには、安定した成熟したモデルと狭い焦点（たとえば、食料品の主要品目）が必要です。より複雑な多段階製造計画では、Relexはあまり存在しません。それでも、Relexはそのドメインにおいて、無人の予測と補充が実現可能であることを証明していますが、その範囲はインメモリアーキテクチャの制約内にあります。
Kinaxisは再計算の自動化を提供しています - その同時性により、データが変更されるたびに、サプライチェーンモデル（部品表、在庫、容量）を介して変更を伝播させ、すべての依存する計画を自動的に更新できます。これは一種の自動化です（各レベルごとに個別の計画サイクルを手動で再実行する必要がなくなります）。ただし、Kinaxisは従来、プランナーがある程度関与することを期待しています：シナリオを設定し、結果をレビューし、コミットするシナリオを決定します。Kinaxisはアラートシステムを介してルーチンの意思決定を自動化できます（たとえば、在庫がしきい値を超えている場合に計画を自動承認する）、しかし一般的には意思決定支援ツールとして使用されることが多いです。 “暗い"オートパイロットではなく。それにもかかわらず、AIの統合とより高度な予測を取り入れることで、Kinaxisはより多くの自動化された意思決定に向けて進んでいます。たとえば、新しいMEIOは、各計画実行ごとに階層間で在庫バッファを自動的に再バランスすることができ、ユーザーは何かがおかしければ受け入れるかもしれません。同社はまた、「自己修復型サプライチェーン」と呼ばれるものに投資しており、より大きな自律性を示唆しています。ただし、クライアントベース（しばしば航空宇宙、自動車など、プランナーが慎重な業界）を考慮すると、Kinaxisの展開では完全にハンズオフの計画が一般的ではありません。
o9 Solutions は通常、ユーザー（プランナーや需要マネージャーなど）が積極的に関わる プランニングプラットフォーム として展開されます – 予測の調整、S&OP計画の共同作業、シナリオの実行など。 o9は計算を自動化する技術能力を持っています（たとえば、定期的な予測の更新を設定できます）、しかしo9の哲学はAIの洞察力を持つ人間のプランナーを補完する方向に傾いています。マーケティング用語の「組織のデジタルツイン」は、ソフトウェアで供給チェーンを反映することを示唆していますが、鏡は通常、あなたが行うことを反映するだけであり、独立して決定することはありません。私たちは、o9を完全に自律的な方法で使用している企業の証拠を見つけることはできませんでした。むしろ、これはクロスファンクショナルな計画を容易にするための単一のデータモデルと分析を提供するツールです。自動化は統合に焦点を当てています（モジュール間のデータフローを自動化すること）。
ToolsGroup は伝統的に「低タッチの計画」アプローチを提案してきました。彼らのSO99+ツールは、各SKUに対して統計的な予測を自動的に生成し、在庫ターゲットを計算し、補充注文さえ提案するように設定できます。多くの中小企業は、実際にはこれを使用して発注書や生産提案を自動生成しており、プランナーは例外（たとえば、システムが異常な状況によって不確かである場合）を確認するだけです。達成される自動化のレベルは、システムの推奨事項への信頼に依存します。ToolsGroupは、確率的アプローチがより信頼性の高い在庫推奨をもたらし、それによって企業が注文をより多く自動化することに快適になるとしばしば強調します。ただし、ToolsGroupのモデルが適切に調整されていない場合、ユーザーは多くを上書きするかもしれません。技術的な能力に関しては、ToolsGroupは確かに予測と初期計画のバッチ未対応モードで実行できます。しかし、Kinaxisのようなものほど即座の再計画を処理できないかもしれません（よりバッチ指向の夜間計画です）。
Blue Yonder (JDA) には、ESP（Enterprise Supply Planning） や Fulfillment などのコンポーネントがあり、予測と在庫ポリシーに基づいて供給注文や在庫転送の推奨を自動的にリリースできます。 Blue Yonderの多くのユーザーは、自動生成された出力に依存しています：たとえば、システムが地域倉庫の在庫レベルを目標に補充するための配送注文を自動的に作成するかもしれません。 Blue Yonderの Demand モジュールは、毎週または毎月基本的な予測を自動的に生成できます。ただし、歴史的にJDA/Blue Yonderの実装には多くの人間のワークフローが関与しています：需要プランナーが予測を調整し、供給プランナーがシステムからの推奨注文を確認するなど。ソフトウェアは自動化をサポートしていますが、必ずしも「手を離す」考え方を奨励するわけではありません – それはむしろ プランナーの作業台 です。さらに、BYのスイートのパッチワーク的な性質から、エンドツーエンドの自動化を達成するには、かなりの統合作業が必要になるかもしれません（需要計画が供給計画モジュールに流れ、手動介入なしで実行に移ることを確認することは難しいかもしれません）。したがって、技術的には可能ですが、実際にはBlue Yonderのサイトでは計画に対して多くの人間の監視が行われることがよくあります。

要約すると、自動化能力 はすべての主要ツールにさまざまな程度で存在しますが、哲学と実際の使用方法 は異なります。LokadとRelexは、それぞれのニッチで本当に自律的な計画を推進することで注目されています（Lokadはさまざまな産業向けに 完全にスクリプト化された「サプライチェーンオートパイロット」 を可能にし、Relexは小売業でそれを行っています）。伝統的な大手ベンダーは、自動化についてより慎重に取り組んでおり、しばしばプランナーに最終決定を任せています。これは、信頼の問題によることがあります – システムの予測があまり信頼性がない場合、ユーザーはそれを自動運転させません。これは、自動化はそれを支える知識によってのみ有効である ということを強調しています：確率的で意思決定志向のツールが必要な理由の1つは、自動化を実現するためには（システム自体が良い決定をしなければならない）ということです。ベンダーを評価する際には、企業は次のように尋ねる必要があります：このシステムは1か月間自己運用でき、パフォーマンスを維持または向上させることができますか？ 最高のテクノロジーは、その質問に対して「はい」と近づいていますが、他のものは根本的に手動での監視が必要です。

スケーラビリティ＆パフォーマンス：アーキテクチャの重要性

サプライチェーンプランニングはしばしばビッグデータ（多数のSKU、店舗、注文、IoT信号など）や複雑な計算（多くの変数を最適化する）を扱う必要があります。各ソリューションの基盤アーキテクチャ – インメモリまたは分散型であるか、増加するデータ量をどのように処理するか – は、そのスケーラビリティとパフォーマンスに直接影響します。悪いアーキテクチャの選択は、ビジネスが成長するにつれて、遅いパフォーマンスまたは過大なハードウェアコスト（またはその両方）につながる可能性があります。ベンダーのスケーラビリティに関する主要なポイント：

インメモリ vs. 分散型：主要なテーマの1つは、ほとんどのデータをRAMに読み込んで高速な計算を行うソリューションと、より分散型でオンデマンドな計算を行うソリューション（クラウドスタイル）の違いです。Kinaxis、o9、Relex、およびSAP IBPはすべて強力なインメモリコンポーネントを持っています。Kinaxisのエンジンは、すべての関連する計画データがメモリに存在し、瞬時の再計算が可能であるという考え方に基づいて構築されました – これはある程度まではうまく機能しますが、メモリ内の数テラバイトを超えるスケーリングは非常に高価で技術的に難しいことがあります。O9とRelexもインメモリ設計による高いハードウェアコストを保証しています⁴ ⁷ – 実質的に、ユーザーは非常に大きなサーバーまたは大規模なRAMを持つクラスターのために支払うことになります。このアプローチは、10〜20年前にはメモリが安価でデータサイズが控えめだったときにメリットがありましたが、メモリ価格は横ばいになり、データの複雑さが増しており、これは将来に向けた戦略としては少し未来に対応していません。対照的に、Lokadは完全にクラウドベースであり、すべてのデータをRAMに保持する必要はありません。必要に応じてコンピューティングを活用します（たとえば、必要に応じて多くのマシンで並列に数値を処理し、その後解放します）。これにより、単一のマシンのRAM天井に達する代わりに、計算ノードを追加することで非常に大規模な問題にスケーリングできます。Lokadのクラウドネイティブ設計は、適切な場合にはディスクとネットワークを大量に使用し、現代のビッグデータのトレンド（分散ストレージとコンピューティング、マップリデュースパラダイムのようなスケールを処理する方法）と一致しています。
大規模なスケールでのパフォーマンス：Blue Yonderの古いモジュール（SAPのAPOやJDA自身のレガシーなど）は、大規模な問題インスタンスに苦労することがあり、データの集計やセグメンテーションが必要になることがあります。新しいクラウドバージョン（BY Luminate）は、おそらくメモリ管理が向上し、おそらく弾力的なスケーリングが行われているかもしれませんが、証拠は乏しいです。SAP IBPはHANA（インメモリカラムDB）を使用しており、大規模なデータを処理できますが、非常に高いインフラコストがかかり、計画実行がタイムリーに終了するためにはしばしばデータを特定のレベルまで集計する必要があります。Oracleの計画はリレーショナルDBバックエンドを使用しており、一部をディスクにオフロードすることができますが、計算ごとに遅くなる可能性があります（ただし、Oracleはデータベースのチューニングを活用しています）。ToolsGroupは通常、中規模のデータセット（数千から数万のSKU）を単一のサーバーで処理していました。非常に大きなSKU数になるとパフォーマンスが低下する可能性がありますが、計算が慎重に制限されていない限り（たとえば、興味のあるアイテムに焦点を当てるなど）、最近はクラウド提供に移行しており、おそらくスケーリングアウトできるようになっていますが、コアアルゴリズムが分散コンピューティング用にリファクタリングされたか、単に大規模なVM上でホストされたかは不明です。
誤ったアプローチ：「インメモリ設計の欠陥」は強調すべき価値があります。いくつかのベンダーは、供給チェーン全体を1つの巨大なメモリ内モデルでモデリングするアプローチを取りました（OLAPキューブや巨大なスプレッドシートのようなもの）。これは小規模から中規模のケースでは非常に高速ですが、線形的にスケーリングされません – 簡単に分散することはできず、さらにデータを追加するとメモリの必要量が爆発的に増加します。Lokadベンダースタディは、o9とRelexについてこれを明示的に指摘しています：彼らの設計は「印象的なリアルタイムレポートを提供します」が、本質的にハードウェアコストを高め、グローバル最適化問題とはうまくマッチしません⁷。同様に、Kinaxis自体の文献は間接的に制限を認めています：たとえば、古いKinaxisの文書では、32ビットシステムで約4GBのRAMが昔の制限要因であったと述べられており、64ビットになった今でも、それが無限ではないとしています²²。根本的な問題は、データがRAM容量よりも速く成長していることです。小売業者が2,000店舗と50,000SKUの店舗-SKU-日レベルで計画を立てたい場合、これは1億の時系列データになります – そのサイズのインメモリキューブ（過去と将来の期間を含む）は数十億のセルを押し込むことになり、これは実用的ではありません。店舗ごとに処理するか、賢明にパーティションを分ける分散型アプローチの方がスケーラブルです。
同時性 vs バッチ: Kinaxisのセリングポイントは同時性です（すべての計算が一度にメモリ内で再計算されます）。これはインタラクティブな使用には最適ですが、フルモデルをメモリに準備する必要があります。夜間のLokadランやToolsGroupのアプローチのようなバッチ指向のシステムは、タスクを分割することでスケーリングできます（たとえば、各SKUを個別に予測することなど、恥ずかしげもなく並列に実行できます）。たとえば、LokadのEnvisionは、クラウド上で並列に実行されるサブ問題に問題を分割できます。リアルタイムのインタラクティビティをスケーラビリティと生のパワーに交換します。ビジネスのニーズに応じて、どちらかが好ましいです。しかし、最良の計画を立てることが目標である場合、一晩中膨大なシナリオ空間を処理するバッチプロセスが簡略化されたリアルタイム計算を上回る可能性があります。

要点: Lokadのクラウドプラットフォームなどのソリューションは、水平方向にスケーリングし、データの複雑さが増すにつれてスケーラビリティのボトルネックやコストが増大するリスクを冒します。これらを評価する企業は、自社のサプライチェーンデータの規模と成長の軌跡を慎重に考慮すべきです。いくつかの新しい「AI」プランニングスタートアップが、意図的にインメモリモノリスを避け、代わりにマイクロサービスやビッグデータフレームワークを使用していることは興味深いことです。また、注意点として、パフォーマンスチューニングはしばしば実装チームに委ねられます。ベンダーがデータを集約したり削除したりしてモデルをメモリに収めることを要求する場合、それはスケーラビリティの警告信号です。真にスケーラブルなテクノロジーは、データを単純化せずに細かく処理できます。

テクノロジー統合と買収: 統合プラットフォーム vs フランケンスイート

ベンダーの歴史 - 彼らがソリューションを有機的に構築したか、買収によって拡大したか - は、テクノロジーの一貫性と統合に大きな影響を与えます。計画スイートが多くの買収された部分で構成されている場合、異なるモジュールが異なるデータベース、ユーザーインターフェース、さらにはプログラミング言語を使用することが多く、全体的な製品が一貫性を欠いてしまいます。私たちは各ベンダーのバックグラウンドを調査しました:

Blue Yonder (JDA)は買収を通じて成長した最も明確な例の1つです。JDAはこれまでに、Manugistics（サプライチェーンプランニングアルゴリズム）、i2（2008年にその取引が失敗した）、Intactix（小売スペースプランニング）、RedPrairie（倉庫管理）などを買収し、スタートアップのBlue Yonder（AI/ML予測）などを買収しました。これは、現在のBlue Yonderのソリューションスイートがパッチワークであることを意味します: たとえば、需要計画は古いManugisticsエンジンかもしれませんし、フルフィルメントは別のものかもしれませんし、価格最適化は別の買収から来ているかもしれません。Lokadの調査によると、「エンタープライズソフトウェアはM&Aを通じて混合できない… BYのバナーの下には無秩序な製品のコレクションがある」と述べています。彼らは、これらをAzureの共通のUIおよびおそらく共通のデータレイヤーの下で「Luminate」プラットフォームの下に統一しようとしていますが、根本的にはこれらを1つのスムーズなシステムに組み合わせることは難しいです。クライアントはしばしば一部の部分のみを実装し、それらを連携させるにはカスタム統合が必要になることがあります。一貫性の欠如は避けられません（たとえば、1つのモジュールが確率論的ロジックをサポートしている一方、別のモジュールはサポートしていないかもしれません。最適化ソルバーを1つ使用しているものと、別のものを使用しているものがあります）。断片化されたテックスタックは、矛盾する慣行が同じスイート内で共存することを意味します（たとえば、BYの一部が20年前の安全在庫の計算式を使用している一方、別の部分が先進的なMLを誇っているかもしれません）。
SAPも同様にいくつかを構築し、いくつかを買収しました。特に、SAPは2009年にSAF（予測ベンダー）を、2013年にSmartOps（在庫最適化ベンダー）を買収しました¹⁷、そして以前にAPOを社内で開発していました。これらはすべてSAPの統合ビジネスプランニング（IBP）クラウドオファリングに組み込まれました。その結果、SAP IBPには異なるモジュール（予測、在庫、供給）がありますが、1つの傘の下にありながら、時々別々の製品のように感じることがあります。予測はSAFのアルゴリズムを使用し、在庫最適化はSmartOpsのロジックを使用します。ピアレビューはSAPのスイートを「製品のコレクション」と呼び、複雑さが高いと警告し、「最高の統合者と数年」が成功を収めるのに必要とされることが多い」と述べています。言い換えれば、統合は実装チームに任され、すべての部分がシームレスに連携するまでには長い道のりが必要です。
Kinaxis は、最近まで主に内部開発でした - 彼らの主力製品であるRapidResponseは数十年にわたって内部で開発されました。これにより、非常に統一感がありました（1つのデータモデル、1つのユーザーインターフェース）。しかし、過去3〜4年間で、Kinaxisはいくつかの戦略的な買収/提携を行い、ギャップを埋めるためにいくつかの企業と提携しました。例えば、確率的在庫最適化のためにWahupaと提携 ¹⁸、AI予測のためにRubikloudを買収し、2021年にはサプライチェーン分析プロバイダーであるPranaを買収しました。Kinaxisは、これらを拡張可能なプラットフォームを介して統合しています（新しい機能に対するユーザーインターフェースを介した「ノーコード」統合を謳っています）、しかし、現実的にはこれらは別々のエンジンが接続されています。例えば、WahupaのMEIOは、RapidResponseにアタッチされたサービスとして実行されるかもしれませんが、ネイティブコードとして内部に組み込まれているわけではありません。将来的には、Kinaxisはこれらをより緊密に統合する可能性がありますが、常に緩やかに連結されたアドオンになるリスクがあります（例えば、予測の変動データをWahupaのエンジンに送り、安全在庫レベルを取得するなど）。数十の買収を行ったベンダーと比較して、Kinaxisはまだ比較的結束していますが、franken-suiteの道をたどらないように注意する価値があります。
o9 Solutions は、その創業者たち（元i2社員）によって主に社内で構築されました。それは同じ基盤上に開発されたモジュールを持つ単一のプラットフォームです。o9はほとんど買収を行っていません（1つの小規模な買収はサプライチェーンネットワーキング企業であり、最近のものはAI/MLスタートアップであるProcessiumですが、計画アルゴリズムに関しては大きなものは知られていません）。したがって、o9のテックスタックは、古い競合他社よりもより統一しています - すべてがo9エンタープライズナレッジグラフに配置され、同じUIフレームワークを使用しています。これは一貫性の点でプラスです（データベーススキーマの重複などがありません）。欠点は、彼らのテックの一部が弱い場合、買収を通じて簡単に修正できないことです - 彼らはそれを開発しなければなりません。これまでに、内部開発で対処してきましたが、私たちが議論した制限（たとえば、ユーザーインターフェースの下におそらく平凡な予測技術など）があるかもしれません。
ToolsGroup は、主にSO99+製品を中心に有機的に成長しました。他の計画ベンダーを大規模に買収していないようです。したがって、需要予測、在庫最適化、補充モジュールは一緒に設計されました。これにより、一貫性のある、しかし多少モノリシックなアプリケーションが生まれました。ToolsGroupの課題は、近年のアーキテクチャとUIが時代遅れであったことでしたが、それ以降、クラウドへの移行やインターフェースの更新に努めてきました。それでも、結束していることはToolsGroupが比較的簡単である理由の1つです：他のツールを接続する必要がなく、エンドツーエンドで1つのこと（サービスレベルの最適化）を行います。
Relex Solutions も、小売業向けに特別にゼロからプラットフォームを構築しました。最近、隣接する領域のいくつかの企業を買収しました（最近は労働力管理ソリューションと店舗スペース計画ソリューションを買収しましたが、彼らのコアな予測と補充エンジンは自社開発です）。そのコアは統一されています（すべてのデータが同じインメモリDBにあるため、リアルタイムでユーザーに任意のメトリクスを表示できる理由です）。新しい領域での買収はいくつかの統合の継ぎ目を導入するかもしれませんが、Relexはまだ古いベンダーの買収ラッシュからは遠いです。

断片化されたスイートの主要な問題は、技術的なオーバーヘッドだけでなく、機能的な不一致もあります：1つのモジュールが1つのアプローチ（たとえば、安全在庫を持つ確定的な計画）のために設計され、別のモジュールが確率的な入力を前提としている場合、それらは衝突する可能性があります。例えば、1つの買収からの在庫最適化モジュールが、別の買収からの需要計画モジュールがUIで処理方法を知らない安全在庫を計算するかもしれず、混乱や重複したデータエントリを引き起こす可能性があります。実際、ベンダーがマーケティングで確率的な予測を推進しているにもかかわらず、彼らの販売＆運用計画モジュールはMAPEを追跡し、単一の数値のコンセンサス予測を使用しているケースを見ました - 異なる製品系統から来る内部の矛盾からおそらく派生しています。

対照的に、一貫したプラットフォームを持つベンダーは、全体的に変更（確率的手法への移行など）をより簡単に実装できます。完全に統一されているLokadは、内部の矛盾がないように確率的最適化に明確に焦点を当てることができます（彼らはすべてをEnvision言語とクラウドバックエンドの周りに構築しました）。同様に、一般的な計画プラットフォームであるAnaplanも技術的に非常に統一されています（1つのHyperblockエンジン）、しかし、専門的なサプライチェーンアルゴリズムが欠けています；Anaplanの一貫性は素晴らしいですが、その専門性は限られています ²³。

したがって、技術的な観点からは、多くの合併から生まれたスイートには注意が必要です - 予測部分と計画部分が本当に同じエンジンやデータモデルを共有しているかどうかを尋ねてください。そうでない場合、統合の苦痛や矛盾する出力の可能性があります。

技術的信頼性：AI/MLのハイプを切り抜ける

「AI駆動のサプライチェーン」と「機械学習予測」という言葉をすべてのベンダーが主張する時代には、これらの主張をどのように裏付けるかを検証することが重要です。私たちは、先進的な技術手法の具体的な技術的証拠を探します - ピアレビューされた研究、文書化された独自のアルゴリズム、オープンソースへの貢献、または中立的なベンチマークでのパフォーマンスなど。また、バズワードの誤用をチェックします - たとえば、単なるif-elseルールであるものをAIと呼ぶことなど。ベンダーの評価は次のとおりです：

Lokadは高い技術的信頼性を示しています。AIを主張するだけでなく、アルゴリズムを説明するコンテンツを公開しています（たとえば、彼らのM5-winning予測モデルがどのように機能したかを詳しく説明した講義など ²⁴）。同社のCEOやチームは、なぜ特定のアプローチ（たとえば、分位数予測のアンサンブルやトレーニングにピンボール損失を使用することなど）が選択されたかについて、技術的な議論（ブログ、講義を通じて）に参加しています。また、Lokadの中核的なイノベーションであるEnvisionプログラミング言語は、供給チェーン最適化のために作成された一般的なMLではなく、ドメイン固有の言語であるユニークな技術的アーティファクトです ²⁵。これは、外部の人々が評価できる具体的な技術的な要素です（一部は公に文書化されています）。Lokadは有料アナリストの引用に頼ることはありません。代わりに、自身の方法のピアレビューを招待しています。このオープンさとスローガンよりも科学に焦点を当てた姿勢は、信頼性のためのゴールドスタンダードを設定しています。
一方、Blue Yonderは、AIに関して曖昧な言語を使う傾向があります。「LuminateプラットフォームにAI/MLを組み込む」といった具体的な技術やモデルについて詳細を示さずにいます。Lokadのベンダースタディは、Blue YonderのAI主張に「ほとんど実質がない」と指摘し、ごく少数の利用可能なアーティファクトは**古典的な予測手法（ARMA、回帰）**に依存していることを示唆しています ¹⁵。たとえば、BYは「需要の変化を感知するためにAIを使用しています」と言うかもしれませんが、実際には最近の販売に対する線形回帰を使用している場合（数十年前の手法）、それはAIという用語を広げています。時系列特徴抽出のオープンソースプロジェクトであるtsfreshが存在することは、透明性の点でBYにとってプラスの要素ですが、これらのプロジェクト自体は広く知られた一般的なツールであり、独自のブレークスルーではありません。BYのデータサイエンスチームからの公開された結果や競技がないことは、彼らの主張がよりマーケティング主導であることを示唆しています。要するに、Blue Yonderは、重いAIブランディングを裏付ける説得力のある技術的証拠を提供していません - 信頼性のための警告信号です。
o9 Solutions は同様に懐疑的な目を向けられています。彼らはEnterprise Knowledge Graph (EKG)の概念を差別化要因としてマーケティングしており、これはデータ内の関係性を捉えるAIの一形態であると示唆しています。グラフデータベースは有用ですが、データをグラフとして保存すること自体には本質的に「予測の天才」的な要素はありません - 重要なのはその上にあるアルゴリズムです。Lokadの調査では、o9のグラフに関する予測主張は科学的文献によって支持されていないと指摘されています ²⁶。さらに、o9のGitHubを調べても、革命的なアルゴリズムは見つからず、彼らのAIに関する話はしばしば一般的な能力（「高度な分析」や「ML予測」など）に帰着します。彼らは「デジタルブレイン」、「AI/ML」、「ナレッジグラフ」といった騒々しい用語を使用していますが、外部の検証がない状態です。o9が、たとえば、自社のMLモデルが他を凌駕する方法についてのホワイトペーパーを公開するか、あるいは厳密なデータで文書化されたクライアントケースがあるまで、o9のAIは主にハイプであると仮定するのが最も安全です - おそらく標準的なMLモデル（ニューラルネット、勾配ブースティングなど）がうまくマーケティングされているだけです。また、サプライチェーンコミュニティでは、本当に画期的なAIコンセプト（サプライ最適化のための深層強化学習や新しい確率モデルなど）は通常、学術的またはオープンなフォーラムで議論されます - それらにo9が参加していないことから、独自の技術の欠如が示唆されます。
Kinaxis はマーケティングにおいて比較的慎重であり、「AI」をあらゆる文に過度に使用していないことは、ある意味では良いことです（過度な主張が少ない）。ただし、AIパートナーを統合するにつれて、それを強調し始めています。良い兆候の1つ：WahupaのCEOと共同執筆したブログ投稿 ²⁷ ²⁸ が、確率論と統計的手法について議論していることは、Kinaxisが科学に踏み込もうとしていることを示しています（確率論、不確実性下での意思決定などを言及）。これは、彼らが自社の提供を堅実な方法論に基づかせようとしていることを示しています。しかし、Kinaxisはそれらの手法の結果を証明する必要があります。たとえば、「新しいML予測が従来のアプローチよりもX％精度が向上した」と詳細に公表していないのは、まだ統合中であるためでしょう。したがって、Kinaxisの信頼性は移行中です：歴史的には予測技術のリーダーであるとは主張していませんでした（したがって誤った表現をしていなかった）、そして今では高度な分析を主張しているため、証拠を待たなければなりません。Wahupaとのパートナーシップは、少なくとも外部の専門知識が必要であることを認識していることを示しています - これは信頼性があります（確率論をマスターしたとは主張しておらず、専門家を招いています）。
ToolsGroup は、バックアップなしにAIの流行語に乗っかることで信頼性を損なってしまいました。調査によると、彼らのAIの主張は**「疑わしい」とされ、公開資料には依然として2000年以前のモデル**を示唆するものがあるとのことです ¹¹。これは、ToolsGroupが既存の機能を単に「AI」として再ブランド化している可能性があることを示唆しています。たとえば、ToolsGroupが「需要感知のためのAI」と広告しているかもしれませんが、調査の結果、それは単に最近の販売により重みを置くルールである可能性があります（これはAIではなく、単なるアルゴリズムの微調整です）。公開された詳細がないと、疑念を持つのは難しいです。彼らの信頼性は、初期の2000年代に確率的在庫モデルで本当に先を行っていたときに強かったのですが、今では可能性の停滞から苦しんでいます。
SAS（私たちがトップにランク付けしていないが、ミックスに含まれている）は、一般的に技術的な信頼性が高いケースです（SASは統計学の長い歴史を持っています）、しかし、裏を返せば彼らのコア技術は古いということです。SASの予測手法はよく文書化されています（彼らは多くの統計手法の教科書を実際に書いています）、しかし、それはまた、カスタムワークでSASを使用しない限り、最新の機械学習技術を取り入れない可能性があります。Lokadの調査は、SASを先駆者として認めていますが、今ではPythonノートブックなどのオープンソースツールによって超越されています ²⁹。SASは通常、過度に売り込むことはありません - 彼らは自分たちの評判に頼っています - しかし、サプライチェーンソリューションとしては、オフシェルフであまり使用されていません（より一般的には、企業はカスタムソリューションを構築するためにSASを使用します）。
一般的な観察: ベンダーの技術的な誠実さをテストする迅速な方法は、彼らが時々自分たちのテクノロジーの制限や 適切な使用例 を認めるかどうかを見ることです。マーケティングモードに陥っているベンダーは、彼らのAIがすべての問題を解決すると主張します。本物のテクノロジーを持つベンダーは、「これができること、そしてここではうまくいかない可能性がある」と言います。たとえば、Lokadは、特定のモデルが特定の需要タイプに適していない理由（なぜ一部のアプローチが断続的な需要に対して失敗するのかなど）について頻繁に議論し、知的な誠実さを示しています ³⁰ ³¹。私たちは、Lokad以外に、その微妙な公開会話をすることを望むベンダーはほとんどいないことがわかりました。ほとんどの他のベンダーは、慎重な顧客に警戒心を抱かせるべき楽観的な一般論にとどまっています。

結論として、競争ランキング、詳細な技術ブログ、またはユーザーコミュニティの議論など、技術的な強さの具体的な証拠 は、多くの有名なベンダーにとって乏しいです。Lokadは証拠を提供することでリードしています（M5の勝利、オープンな説明）。Blue Yonderやo9などの他のベンダーは、時代遅れのテクノロジーを匂わせるハイプ を提供しており、これは彼らの主張する「AI革命」を疑問視します ¹⁶。見込み客は、ベンダーに要求すべきです。アルゴリズムがどのように機能し、なぜそれがより優れているのかを 具体的な言葉で 説明し、回答が単なる専門用語の羅列である場合は警戒すべきです。サプライチェーンにおける真のAI/MLの価値は実証可能であるべきです（たとえば、「私たちは勾配ブースティング木を使用して、天候などの非線形需要要因を捉え、1000のSKU全体でベースラインに対して5%の改善を実証しました」という声明は、「私たちのAIはデータの中の隠れたパターンを見つけ出します」というよりも説得力があります）。

ベンダーアプローチの一貫性と矛盾

ベンダーのメッセージングや方法論に内部の矛盾が含まれているというのは、表面的な革新の兆候です。私たちはそのような矛盾を探しました - たとえば、不確実性について説く一方で成功を決定論的なメトリクスで測定する、または古い慣行を廃止すると主張しながら、それらを裏で使用している場合。いくつかの注目すべき発見:

確率的対決定論的メトリクス: 先に述べたように、ToolsGroup はこれに罪があります - 確率的な予測能力を宣伝しているにもかかわらず、結果をMAPE（平均絶対パーセント誤差）の削減として示しています ¹³。MAPEは点予測誤差メトリクスです。本当に確率的な予測を行っているのであれば、キャリブレーション、確率的対数尤度、ピンボール損失（分位数用）、または少なくとも達成されたサービスレベルについて話すはずです。MAPEに固執することで、ToolsGroupは基本的に確率的なストーリーと矛盾しています。この矛盾は、彼らの「確率的」な出力が単なる変換された決定論的な予測であるか、それともそれが彼らの研究開発によって深く受け入れられていないマーケティングオーバーレイであることを示唆しています。
需要センシングのハイプ: 多くのベンダーが「需要センシング」という用語を使用して、最新のトレンドを捉える特別な短期予測を持っていると暗示しています（非常に最近の販売や外部信号を使用するなど）。ToolsGroup、SAP、およびGAINSystems はすべてこの用語を使用しています。この研究は、これらの「需要センシング」の主張が文献に支持されていない 「空気製品」 であることを指摘しています ³²。ベンダーが「私たちのAIは3か月先の需要変化を感知します」と主張しても、それがどのように機能するかを説明できない場合（そして同様のことが信頼できる方法で可能であることを裏付ける同僚のレビューされた研究がない場合）、それは警告のサインです。同じベンダーが基本的な時系列モデルを引き続き使用している場合、矛盾が生じます。基本的に、彼らは標準の指数平滑化予測を行い、最終週の調整を追加して「センシング」と呼んでいます。その矛盾: 小さな調整を画期的なものとして描写することです。
決定論的KPIの使用: ベンダーの ケーススタディやインターフェース が、MAPE、バイアス、またはトラッキングシグナルなどの決定論的KPIを中心にしている場合、それらがAI/ML全体に関するものであると主張していても、それは矛盾しています。たとえば、ベンダーが機械学習を誇示しているが、デモではプランナーが予測MAPEを改善しようとしたり、ABCセグメンテーションを使用して安全在庫を設定している場合、それは一貫していません。真のML駆動の確率的計画は、期待されるコスト、在庫切れの確率、または他の確率的なメトリクスに焦点を移すべきです - 予測可能で静的な需要の分類を前提とする従来のMAPEやABC分類ではなく（これは、予測可能で静的な需要の分類を前提とする）、私たちはいくつかの大手ベンダーのユーザーマニュアルでこのような二面性を観察しました: 1つの章では新しいAIモジュールについて語っていますが、別の章ではユーザーにARIMAパラメータや安全在庫ルールを調整するよう指示しています。
安全在庫の哲学: 重要な哲学的な矛盾は、「不確実性管理について話すベンダーでも、プロセスを「安全在庫」に重点を置いている」という点です。安全在庫の概念は、確定的な予測+バッファに根ざしています。完全に確率的なフレームワークでは、需要分布とサービス目標から直接最適な在庫レベルを計算するべきです（これにより、「基本」と「安全」が1つの決定に統合されます）。ベンダーが「AIで在庫を最適化している」と言った場合、ユーザーに「希望のサービスレベル」を入力して正規分布の仮定を使用して安全在庫を計算するよう求めるかどうか尋ねてみてください。もし求めるなら、彼らは本当に進歩していないことになります - 彼らは古い安全在庫計算を新しい言葉で飾っているだけです。例えば、Blue Yonderの在庫最適化（歴史的には）は、分散とサービス目標に基づいて安全在庫を計算します - これは基本的に確率的最適化ではありません。それは公式の適用です。Lokadのようなベンダーは、「安全在庫」という用語を時代遅れとして明確に拒否しています。真の確率的最適化では、すべての在庫が需要の確率分布に従っていると見なされます。「次世代の計画」をマーケティングしているベンダーが、彼らのソリューションガイドで安全在庫設定を維持するよう指示している場合、それは一貫性の問題です。
AIの魔法 vs. ユーザーのコントロール: 一部のベンダーは同時に「当社のAIが供給チェーンを自律的に推進する」と主張し、「ユーザーに計画プロセスへの完全な制御と可視性を提供する」とも主張しています。バランスを取る必要がありますが、広範な主張は矛盾する可能性があります。AIが本当に自律的であれば、ユーザーは常に監視する必要はありません。ユーザーが常に微調整する必要がある場合、それは本当に自律的ではありません。マーケティングはしばしば両方を約束したがります（「オートパイロットと手動オーバーライド！」）が、実際にはソリューションはどちらかに傾きがちです。ここでは特定のベンダーを指摘していませんが、我々は完全な自動化を約束する一方で、ユーザーが設定しなければならない数十の計画パラメータのスクリーンショットが添付された一般的な約束を見つけました。

当社の調査では、矛盾を解消する明確な例として、Lokadがどのように自らを位置付けているかが挙げられます。Lokadは、MAPEのような指標や安全在庫のような概念を教育コンテンツで明確に批判し、その方法論をそれに合わせて調整しています（確率的指標を使用し、直接的に意思決定を行います）¹³ ³¹。一方、GAINSystemsのようなベンダーは最適化志向を主張していますが、依然として過去の時代からの需要感知やマッチングアルゴリズムなどを強調しています³² - 事実上、2つの馬に乗っている状態です。John Galt Solutionsは、独自の予測アルゴリズムが他を凌駕すると主張していますが、それは独立したランキングには登場せず、ピアレビューによるとオープンソースよりも優れていない可能性があります²⁰。これは主張と証拠の間の矛盾です。

要するに、ベンダーを評価する際には、内部の一貫性を確認することが重要です。彼らが言うことを実践しているかどうか？ベンダーが不確実性と最適化について大それたことを言っている場合、彼らの資料は同時に確定的な指標や単純化された方法を賞賛すべきではありません。矛盾はしばしば「新しい考え方」が表面的なものに過ぎないことを示しています。

時代遅れの計画の赤信号

サプライチェーンの計画は進化しており、一部の標準的だった実践が、現代の能力を考えると時代遅れまたは最適でないと見なされるようになっています。ベンダーがそのような実践に依存しているかどうかを特定することは示唆に富むことがあります。以下は、いくつかの時代遅れ（または少なくとも「オールドスクール」）の実践と、ベンダーがどのように位置付けられているかです。

松明としての安全在庫: 安全在庫を予測に追加する別個のクッションとして扱うことは古いアプローチです。安全在庫が「悪い」というわけではありません - 常に変動のためのバッファが必要です - しかし、現代の方法では変動を直接取り込んでいます。ベンダーの中核的な方法が「スムージングを使用して予測し、次に安全在庫を計算する = zスコア * シグマ * リードタイムの平方根」というものであれば、それはまだ1960年代の理論が適用されている状態です。例えば、SlimstockのSlim4は、そのような主流の数式（安全在庫、EOQ）を誇りに思っており、率直にそれについて述べています³³。Slimstockは実際には正直さにクレジットを与えられます：それは「ありふれたが重要な実用的な問題」に焦点を当てており、AIを使用していると偽ることはありません³⁴。しかし、技術リーダーシップの観点からは、これらの実践は時代遅れです。LokadとWahupa（Kinaxisのパートナー）は、確率モデルから直接最適な再発注ポイント/数量を計算する方向にシフトすることを主張します。これにより、「サイクル在庫対安全在庫」という人工的な区別がなくなります。多くのレガシーツール（SAP、Oracle、古いJDA）は、どこでも安全在庫パラメータに依存しています。これは、その基本的な数学があまり変わっていないことを示す赤信号です。真に最適化されたシステムでは、在庫のコストと不足のコストを入力し、ポリシーを解決することができます - 「安全在庫」と呼ばれるものを明示的に呼ぶことなく、アイテムごとに最適な在庫レベルを出力します。
MAPEと確定的な指標: MAPE、バイアスなどを主要な成功指標として重点を置くことは時代遅れと見なされることがあります。なぜなら、これらの指標がビジネス成果と直接的に相関していないため（たとえば、MAPEが低くてもサービスレベルが低いことがあります）、不確実性を無視しているからです。新しいアプローチでは、予測のための**ピンボール損失（分位数損失）**や計画のための期待コスト指標などの指標が好まれます。ベンダーの事例研究での成功基準が「予測精度を70%から80%のMAPEに向上させました」という場合、彼らは過去に固執していると言えます。John Galtの予測精度主張は、このような傾向があり（そして同僚に疑問を投げかけられました）²⁰。現代的な考え方は、「在庫切れをX％削減したか、在庫をY％削減したか」というものです - それは結果に基づいており、単なるMAPEではありません。
ヒューリスティックセグメンテーション（ABC、XYZ）: 古い計画プロセスでは、アイテムをボリューム（ABC）または変動性（XYZ）でセグメント化し、それぞれのグループに異なる計画パラメータを適用することがよくありました。これは、限られた計算能力や単純化されたモデルに対処するためのヒューリスティックであり、Aアイテムを1つのアプローチで処理（おそらくより手動的な焦点を当てる）し、Cアイテムを別のアプローチで処理（おそらく最小最大規則）することがあります。セグメンテーションは依然として有用であることがありますが、各SKUを個別に最適化し続ける計算能力がある場合、やや時代遅れです。手動のABC分類を強く強調するシステムや需要を「塊状対滑らか」と分類する必要があるシステムは、異なる需要パターンを自動的に堅牢に処理するアルゴリズムを持っていないことの松明として使用されている可能性があります。多くのレガシーシステム（そして一部の新しいシステムさえも）は、これを行っています。理想的には、AI駆動のシステムは、SKUごとにパターンを自動的に学習し、人間がそれを分類する必要がないようにするでしょう。
ルーチンとしての手動予測オーバーライド: 伝統的な需要計画では、ユーザーが判断（マーケティング情報など）に基づいて定期的に統計予測を上書きすることが期待されています。人間の入力は貴重ですが、システムの精度が低すぎてプランナーが毎サイクル多くの予測を見直さなければならない場合、そのシステムは基本的には過去のアプローチです。現代のシステムは、より多くのデータを組み込むことでオーバーライドを最小限に抑えることを目指しています（たとえば、モデルがすでにマーケティングがプロモーションを行っていることを「知っている」）。ベンダーがユーザーが手動で予測を調整することが簡単であることを強調している場合、そのアルゴリズムがそのまま信頼できないことを示しているかもしれません。トレンドは、例外ベースのオーバーライドに向かっています。
スプレッドシートへの依存: ベンダーのソリューションがユーザーをしばしばデータを最終分析のためにExcelにエクスポートしたり、Excelをインターフェースとして使用したりすることが多い場合、それは未熟なソリューションの兆候です。主要なツールは、プラットフォーム内で必要なすべての分析と意思決定支援を提供します（Anaplanはここで興味深い：基本的にはクラウドスプレッドシートのステロイドであり、スプレッドシートのパラダイムを受け入れていますが、制御されたマルチユーザー環境であるため、それは現代的でありながら古典的でもあります）。

収集したデータから：Slimstockは意図的に古いが実証済みの方法（安全在庫、EOQ）³³を使用しています。これは賞賛されるべきですが、これらの方法は確率最適化に対して時代遅れであると言えます。GAINSystems（あまり知られていないが長年のベンダー）も、古典的な予測モデルに固執しており、彼らの謳うML機能（「マッチングとクラスタリング」など）さえも2000年以前の技術³²を使用しているようであり、それは実質的に新しいものはほとんどないことを示唆しています。GAINSystemsのLokadレビューは、これらをバーポーウェアと明確にラベル付けしており、これらの方法を時代遅れまたは実践上効果がないと見なしていることを示しています³²。

Blue YonderとSAPは多くの遺産を引き継いでいます。たとえば、SAPの多くの実装では、異なる安全在庫レベルを設定するためにABCを使用するか、低い値のために単純移動平均予測を使用することがまだデフォルトです。彼らの新しい「機械学習を用いたIBP」がこれらの基本を根本的に変えない場合、それは基本的に新しいボトルに詰められた過去のワインです。

矛盾するメトリクス（革新について話すがMAPEを使用するなど）の存在は、一貫性として取り上げましたが、古いメトリクスに固執している証拠でもあります。

結論として、企業が最も先進的なソリューションを探している場合、安全在庫パラメータ、ABCセグメントルール、予測精度％を主要なKPIとしているベンダーには注意すべきです。これらは、解決策が過去の世紀の慣行に根ざしていることを示す兆候です。代わりに、サービスレベル、コスト、確率を強調するベンダーを探してください - それが現代のサプライチェーン科学の言語です。

意思決定指向の予測：予測から行動へ

最後に、各ベンダーが単なる予測を作成するだけでなく、それらの予測に基づいて最適化された意思決定をユーザーが行うのを助けるかどうかを評価します。サプライチェーンにおける最終目標は美しい予測ではなく、サービスを最大化しコストを最小化するための正しい行動（発注、在庫管理、スケジューリング）を取ることです。予測と関連する制約/コストに基づいて最適化された注文数量、生産計画、在庫目標などの推奨事項を直接出力し、それらの出力が最適化されている場合、そのソリューションを「意思決定指向」と呼びます。以下は、ベンダーの比較です：

Lokad は非常に意思決定指向です。実際、彼らはしばしば予測自体の重要性を軽視し、重要なのは意思決定であると主張しています（「予測が良い意思決定につながる場合にのみ良い」という暗黙の哲学）。 LokadのEnvisionを使用すると、需要を予測するだけで終わることはありません。典型的なLokadのワークフローは、確率的な予測の下で、さまざまな候補の意思決定（たとえば、100単位 vs 200単位の注文）に対する期待される利益またはペナルティを計算し、その後、期待される結果を最大化する意思決定を選択します。ユーザーへの出力は「需要は120になる」というものではなく、「130単位を注文する」というものです（例えば）、その理由（たとえば、この数量は在庫切れと在庫過剰のリスクを予測分布とコストパラメータに応じてバランスさせる）と共に。これは真の処方箋指向または意思決定中心の分析です。したがって、Lokadは予測を直接実行に結びつけることを確実にします。最適化にはMOQ（最小発注数量）、賞味期限、予算制限などの制約も考慮されています。したがって、Lokadは予測を行動に変える基準を満たしています。
ToolsGroup も意思決定指向を持っており、特に在庫と補充の意思決定に関してです。そのSO99+ツールは単なる予測だけでなく、サービスレベルの目標を達成する在庫レベルと再注文ポイントを推奨します。実際には、ToolsGroupの実装では、各SKUに対して次のように出力されます。「安全在庫をX単位保持し、在庫がYに減少したときに再注文し、これにより現在Z単位を注文する必要があります。」それは予測から導かれた意思決定（補充数量）です。したがって、ToolsGroupは常に処方箋の出力についてであり、単なる予測についてではありません。制約条件が供給計画に影響を与えることを予測しない場合、次の段階で最適ではない計画が得られる可能性があります。真に意思決定指向のアプローチは、予測時または統合された最適化時にこれらの制約を考慮するでしょう。Blue Yonderの新しいメッセージング「自律型サプライチェーン」は、予測から自動的に意思決定を行いたいという意味であり、技術の混合を考えると、それがどれだけシームレスかは不明です。
Blue Yonder および他のレガシースイートは、予測と計画モジュールを分離することがよくあります。たとえば、BY Demandは予測を提供し、その後、BY Supply（またはFulfillment）がその予測を受け取り、計画を立てます。統合された実装では、最終的な結果は意思決定の推奨事項（マスタープロダクションスケジュールや展開計画など）です。Blue Yonderは完全な計画最適化モジュールを提供しています。たとえば、彼らのFulfillmentモジュールは、中央倉庫からDCを補充する方法を推奨します（これは予測と在庫データを使用して計画された注文を作成するDRPエンジンです）。彼らのProduction planningモジュールは、最適化された生産シーケンスやスケジュールを作成できます。したがって、BYはスイート全体で意思決定をカバーしていますが、それらの意思決定がどれだけ最適または統合されているかは、すべての要素が実装および調整されているかどうかにかかっています。歴史的には、1つのモジュールの出力が次のモジュールにとって常に最適でないという批判がありました（たとえば、予測が供給計画に影響を与える制約を考慮していない場合、実行不可能な計画が得られます）。真に意思決定指向のアプローチは、予測時または統合された最適化時にこれらの制約を考慮するでしょう。Blue Yonderの新しいメッセージング「自律型サプライチェーン」は、予測から自動的に意思決定を行いたいという意味であり、技術の混合を考えると、それがどれだけシームレスかは不明です。
Kinaxis は、その主な目的が実行可能な計画（サプライ計画、在庫予測など）を迅速に生成するという意味で、非常に意思決定/出力志向です。ユーザーは一般的にそれらの計画と作業し、決定を確認または調整できます（注文の緊急処理や供給の再割り当てなど）。Kinaxisの新しいMEIO追加機能では、現在、在庫バッファー（つまり、Kinaxisは現在、現金とサービスをバランスさせて安全在庫レベルを推奨できます³⁵）。以前、Kinaxisは異なる安全在庫をシミュレートして結果を見ることができましたが、必ずしも最適なものを教えてくれるわけではありませんでした。確率的MEIOでは、数学的に最適なものを見つけようとします。生産および配布計画などの他の領域では、Kinaxisはヒューリスティクスまたは最適化を使用しています（スケジューリングおよび割り当てのための最適化ソルバーを持っています） - しかし、Kinaxisの多くの力は、ハードな最適化よりもシミュレーションにあります。つまり、ユーザーの決定の結果を非常に速くシミュレートできますが、どのシナリオを選択するかは人間に委ねられることが多いです。要するに、Kinaxisはリアルタイムに完全な一連の推奨アクション（計画注文、再スケジュールなど）を生成します - 明らかに意思決定支援ですが、人間の入力なしで常に「最適な」計画を自動的に選択するわけではなく、MEIOなどの特定の機能や計画が明らかな場合を除いて（例：需要を確実に供給要件に伝達します）。
o9 Solutions も、需要、供給、在庫などの計画（つまり、一連の決定）を生成するように設計されています。o9には、特定の問題に対する最適化エンジンがあります - たとえば、制約条件を考慮してコストを最小化したり利益を最大化したりするための線形プログラミングを使用した供給計画など。それは「デジタルブレイン」コンセプトの一部であり、リソースの最適な割り当てを見つけ出すでしょう。ただし、すべてのo9の顧客が最適化された方法で使用しているわけではありません。一部の顧客は、協力的な計画を行うためにそのプラットフォームを使用するかもしれません（基本的には手動の決定ですが、データの可視性が向上しています）。疑問点は、o9が確率的な意思決定最適化をネイティブでサポートしているかどうかですか？おそらく強くはありません。シナリオ分析を行うかもしれません（「10％余分に生産した場合、結果はどうなりますか？」）、しかし、シナリオ全体で期待値を計算するわけではありません。したがって、意思決定志向はあります（推奨されるサプライチェーン計画を提供します）、しかし、不確実性の下で最適ではないことが明確ではありません。
Relex Solutions は小売業に焦点を当てており、その主な出力は店舗またはDC注文および在庫ターゲットです。Relexは、それらの決定を直接生成することに非常に成功しています（予測とパラメータを考慮して、自動補充システムとして機能します）。また、棚のスペース割り当て対在庫などの最適化も行うことができます（新しい統合計画とスペース計画アプローチを使用して）。これは、小売業に固有の意思決定のトレードオフです（たとえば、スペースが限られている場合、在庫とアソートメントをどのようにバランスさせるか）。Relexの決定は、主にユーザーが設定したルール（サービスレベル目標やサプライ日数など）によって駆動されていますが、システムは、それらのルールを満たす実際の注文を生成するための数値計算を処理します。確かに意思決定志向です（「今週の予測は100ユニットです」とだけ言わないでください - 現在の在庫が50で予測が100でリードタイムがこれであるため、小売業者に今すぐ50ユニット追加注文するように伝えますなど）。Relexは、ある意味であまり戦術的すぎるかもしれません（きれいに再注文しますが、長期的なネットワークの影響を考慮しないかもしれません - 各ノードは、そのサービスに対してローカルに最適化されています）。

意思決定志向の予測は、単なる分析ツールと真のサプライチェーン最適化ソリューションを区別するものです。上位ランクのすべてのベンダーは少なくとも意思決定の出力を提供することを目指しています。これが、私たちがそれらを対象と考えた理由です（研究概要では、意思決定を最適化しない純粋なトランザクションまたは純粋な予測ツールは除外すると明記されています）。ただし、それらの意思決定における最適性の程度や不確実性の統合は、さまざまです：

LokadとToolsGroupは、コスト/サービス目標を使用して予測を意思決定に結び付けています（Lokadは期待コストを最適化するカスタムスクリプトを使用し、ToolsGroupは在庫決定を生むサービスレベル目標を介しています）。
Kinaxisとo9は包括的な計画を生成し、意思決定を探索することができます。Kinaxisは最近、より形式的な最適化を追加しました（在庫最適化など）。
Blue Yonderには、意思決定を生成できる別々の最適化モジュールがあります（完全に使用すれば、すべての計画が得られます - ただし、それらを整合させるのは作業が必要です）。
Relexは特定の意思決定（補充）を非常にうまく自動化していますが、他の意思決定（長期的な容量計画など）はそうではありません。

ソリューションを評価する際に企業が重視すべき点は次の通りです：「システムが予測した後、どのような意思決定を推奨し、それが最善の意思決定であることをどのように保証するのか？」 ベンダーが明確に答えられない場合、またはユーザーが予測を手動で解釈することになるようであれば、そのベンダーは真の最適化志向ではない可能性が高いです。この質問により、たとえば、洗練された機械学習予測が在庫削減につながるのか、単にグラフ上の素敵な数字になるだけなのかが明らかになります。

結論

この比較研究では、技術的視点を優先し、マーケティングの約束よりも実際の能力を重視して、主要なサプライチェーン計画と予測ソフトウェアベンダーをランク付けし、分析しました。評価は、この分野での技術的リーダーシップには、証拠に基づく高度な予測（できれば確率的）、スケーラブルでモダンなアーキテクチャ、高度な自動化、統一されたおよびよく設計されたテックスタック、そして何よりも、予測分析だけでなく、規定的意思決定に焦点を当てることが必要であることを強調しました。

Lokadは、確率的予測の先駆的な取り組みと意思決定最適化への徹底的な焦点により、トップリーダーとして浮上しました - 外部のベンチマーク（M5コンペティションの勝利など）や透明な技術コミュニケーションによって検証された属性 ³ ²。これは、メインストリームのアプローチに対する懐疑（たとえば、MAPEのようなメトリクスやセーフティストックのような概念の価値を疑問視すること）が、健全な経済学に合致したより堅牢なソリューションにつながることを示しています ¹³ ³¹。

Kinaxisやo9 Solutionsなどの他のベンダーは、AI/MLに大きく投資しており、印象的に幅広いプラットフォームを構築していますが、まだ市場にその「AI」が表面的でないことや、アーキテクチャが過大なコストなしでスケーリングすることを説得する必要があります ⁴。Blue Yonder（JDA）やSAPなどの長年のプレーヤーは、サプライチェーン領域の経験と機能に富んでいますが、多くの買収からの断片化されたシステムや時代遅れのアルゴリズムによるレガシーの荷物が浮かび上がり、矛盾や技術革新の進展の遅れにつながっています ¹⁴ ¹⁷。ToolsGroupやRelexなどのニッチな専門家は、それぞれの領域（在庫最適化と小売補充）で強力なソリューションを提供していますが、それぞれに制限があります - ToolsGroupはAIの主張をより新しいテクノロジーで裏付ける必要があります ¹¹、そしてRelexのインメモリアプローチは、その得意分野外ではうまくいかないかもしれません ⁷。

分析の明確なパターンは、技術的な詳細と結果を率直に提供するベンダーが、言葉巧みに頼るベンダーよりも信頼を醸成するということです。ハイプに満ちた空間で、意思決定者が確固たる証拠と一貫性を要求することは重要です。たとえば、ベンダーが機械学習を使用していると主張する場合、精度やコストへの影響を見るように求めてください。確率的予測が謳われている場合、それがどのように計測され、計画にどのように使用されているかの証拠を要求してください（そして、答えが確定的なメトリクスで混乱している場合は警戒してください）。

さらに、サプライチェーンの複雑さが増すにつれて、スケーラビリティと自動化は単なる望ましいものではなく、不可欠です。手動で、Excel時代の実践に固執しているソリューションや、ヒーロー的なハードウェアなしでは大規模なデータを処理できないソリューションは、長期的に企業に役立ちません。この研究がインメモリのワンサイズフィットオールアーキテクチャに対する懐疑心を持っていることは、データによって裏付けられています - より分散された、クラウドネイティブなアプローチが、コストと機能の両方で利点を示しています。

最後に、サプライチェーン最適化ソフトウェアの究極の基準は、それが提供する結果です：在庫コストの低減、サービスレベルの向上、迅速な対応能力、および効率的なプランナーワークフロー。これらを達成するには、賢い数学以上のものが必要です - それはビジネスの現実に合致した統合された、自動化された意思決定プロセスにその数学を統合することを必要とします。最高のベンダーは、透明で科学的に妥当な方法で予測 -> 最適化 -> 決定 -> 結果のループを閉じることができるものです。孤立した予測や不確実性から切り離された決定ルールに固執しているベンダーは取り残されています。

結論として、サプライチェーン計画ソリューションを評価する企業は、各競合他社を厳格に技術的に見るべきです。光沢のあるパンフレットを切り捨て、私たちが探求した厳しい質問をしてください：ベンダーは確率的な予測を提供していますか、それとも単一の数字だけですか？彼らのシステムは自律的に動作できるのか、そしてスケールで証明されていますか？その技術は統一されていますか、それとも古い部品の合成ですか？彼らは自分たちの「AI」を理解可能で事実に基づいた用語で説明していますか？この厳格さを要求することで、サプライチェーン最適化の真の技術リーダーを特定することができます - 優れた意思決定を提供できるだけでなく、見栄えの良いダッシュボードだけではありません。ここでのランキングと分析は、Lokad、Kinaxis、o9、Relex、ToolsGroup、Blue Yonder（その他）を主要プレーヤーとして特定し、それぞれに強みと欠点があります。ベンダーは自分たちの主張を裏付け、ユーザーはサプライチェーンを駆動する脳を選択する際に健全な懐疑心とエビデンスに基づいている必要があります。