自動車アフターマーケット最適化ソフトウェア、2025年2月

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

はじめに

自動車アフターマーケットは、孤立した在庫や価格設定ツール以上のものを求めています。需要がまばらで、部品が交換可能で、複雑さが増している中で、本当に在庫、価格、アソートメントを一緒に最適化できるベンダーはほんの数社です。この調査は、技術的根拠に基づいて競合他社をランク付けし、不確実性の中での共同最適化の約束を果たしている企業と、まだレガシー思考に固執している企業を明らかにします。

ベンダーランキング（共同在庫-価格-アソートメント最適化）

1. Lokad – 確率モデリングと経済最適化のために一から構築された最も一貫性のある共同最適化アプローチを提供。部品-車両の互換性データをネイティブで処理し、厳密な財務論拠に基づいて価格設定を在庫決定に統合 ^{1 2}。
2. Syncron – アフターマーケットのサービス部品向けに特別に設計された在庫と価格モジュールを統合。断続的需要のための強力な確率予測と競合他社価格の処理が堅固だが、一部の最適化はユーザー定義の戦略に依存している ^{3 4}。
3. PTC Servigistics – 在庫と価格をカバーする成熟したサービス部品最適化スイート。証明された多階層アルゴリズムとMLの強化 ^{5 6}があるが、レガシーの複雑さやモジュールの統合は、エンドツーエンドのAIを謳っているにもかかわらず、課題を引き起こす可能性がある。
4. ToolsGroup（Evoを搭載） – 新たに取得した価格AI（Evo）によって強化された高度な在庫最適化（SO99+）。確率需要モデリングと多階層在庫に優れているが、最近の買収（例：Evo、JustEnough）によって統合に関する疑問が生じている ^{7 8}。
5. o9 Solutions – 需要、供給、価格を一つの環境でモデル化する現代的な統合計画プラットフォーム（“Digital Brain”）。価格弾力性モデリングとシナリオ計画を提供している ⁹が、部品の互換性などの特定のドメイン能力はカスタム構成を必要とするかもしれない。
6. Blue Yonder – 強力な在庫最適化と小売価格設定モジュール（Revionics）を備えた広範なサプライチェーンスイート（レガシーJDA/i2）。ただし、共同最適化は固有のものではなく、買収後も価格設定と在庫は分離された技術のままである ¹⁰。レガシーi2テクノロジーと「自律サプライチェーン」という言葉に依存することで、統合の隙間が露呈している。

(SAP、Oracle、Kinaxisなどの他のベンダーは、アフターマーケットの文脈での共同在庫-価格最適化の実証が不足しているため、ここでは省略されています。通常、価格設定と在庫を別々に扱います。)

概要 – 共同最適化の重要性

自動車アフターマーケットにおいて、在庫最適化は価格設定から意味を持つことができません。 この市場の複雑さ - 数十万もの動きの遅いSKU、非常に断続的な需要、多くの交換可能な部品 - は、在庫の決定と価格戦略が一緒に決定される必要があることを要求しています。この業界では、在庫レベルを単独で最適化する従来のツール（例：補充率やサービスレベルを通じて）は「的外れ」です ¹¹。価格は需要と収益性に直接影響を与えるため、在庫、価格、アソートメントは一体として最適化されなければなりません。この分野のベンダーは、これらの課題に取り組むためにAI/MLを使用していると主張していますが、本物の能力とマーケティングの誇張を区別するためには懐疑的な目が必要です。

以下では、各主要ベンダーの技術を主要要件に対して批判的に評価します：断続的需要のための確率的予測、部品-車両互換性マトリックスの取り扱い、意思決定の真の経済最適化、アーキテクチャのスケーラビリティ/コスト効率、競合情報の統合、マルチチャネル販売データのサポート、および自動化の度合いとユーザー調整への依存度。曖昧な主張や遺産の問題を指摘し、ベンダーが過剰な約束をしている可能性（例：文脈のない大胆なパーセンテージの改善）や、買収されたコンポーネントを組み合わせている可能性を指摘します。各ベンダーの分析は、彼らの強みから始まり、制限事項と赤旗を続けます。

¹² フィルタからブレーキディスクまで、さまざまな予備部品が自動車アフターマーケットを特徴づけています。解決策は、これら数百万のアイテムの希薄な需要パターンを解読し、在庫と価格を単独で最適化するのではなく、共同で最適化する必要があります。

1. Lokad – 確率的、経済主導の最適化

Lokadは、自動車アフターマーケットなどの複雑なサプライチェーン向けに特に設計された確率的予測の基盤とエンドツーエンドの**“予測最適化”**によって区別されています。 Lokadは、単一点需要を予測するのではなく、需要の完全な確率分布をリードタイムにわたって生成し、不確実性を認識します。彼らの技術文書によると：“在庫最適化に関わる際には、確率的需要予測が必須です。” ¹³ これは予備部品にとって重要であり、需要が希薄でゼロインフレーションがある場合、従来の平均予測や周期モデルは在庫切れのリスクを誤って判断します。 Lokadのエンジンは断続的な需要パターンや確率的リードタイムさえもハンドリングし、これらを最適化の決定に供給します。

一流の部品互換性の取り扱い。 Lokadは、部品-車両互換性マトリックスのモデリングに多額の投資を行い、そのアルゴリズムでこれを“第一級市民”として扱っています ^{14 1}。この互換性データ（通常は約100万の部品を約100kの車両モデルにリンクする1億以上の関係 ¹⁵）は、真の需要を推測するために不可欠です。 Lokadのグラフベースのモデルは、単純に各部品番号を予測するのではなく、基礎となる*“必要単位”*、つまり車両の要件を特定します ¹。これは、複数の部品番号が同じニーズを満たす場合（OEM部品対アフターマーケットの同等品、後継品など）、Lokadの予測と推奨がその相互運用性を反映しています。したがって、需要信号は正しく解釈されます：たとえば、販売実績がゼロの部品でも、互換性のある代替品が販売されている場合は、在庫が必要となる可能性があります - これは古典的な時系列手法が見逃すものです ¹⁶。

真の経済最適化。 Lokadの哲学は、任意のサービスターゲットではなく経済ドライバーに焦点を当てています。その最適化プログラムは、収益性と稼働時間を最大化するために、すべての関連するコスト、価格、制約を考慮しています。このソリューションは、在庫コスト、サービスレベル、価格の間のトレードオフ、つまり資本、価格、サービスの“三つ巴”を明示的にモデル化しています ¹⁷。たとえば、在庫を増やすとサービスが向上しますが、資本を拘束し、陳腐化のリスクが高まります。価格を上げるとマージンが向上しますが、ボリュームが抑制されます ¹⁸。 Lokadは、保持コストからサービスの質の低下による顧客喪失のリスクまで、“すべての関連する経済的要因を考慮に入れて”最適化しています ²。単なる補充率を達成しようとする多くのツールとは異なり、Lokadは、たとえば、Envisionスクリプト言語でカスタム“在庫報酬”または経済的目的関数を使用して、サービス制約の下で期待利益を最大化したり、総コストを最小化したりするように構成できます。目標に関する固定された仮定が付属していないため、ユーザーは望むようにサービスとコストと市場シェアの重み付けを行うことができます ²。

この経済的焦点は価格最適化にも及びます。Lokadのプラットフォームは在庫レベルや需要弾力性を考慮した価格推奨を生成できます。実際、Mister Auto（オンライン部品販売業者）のような顧客は、20カ国で数千の部品の価格を動的に設定するためにLokadを使用し、「ビッグデータに基づくアルゴリズムモデル」を引用して価格効果を高めました ¹⁹。 LokadのCEOはインタビューで、アフターマーケットにおける価格設定の重要性と同様の部品の競合他社の価格を分析することを強調しています ²⁰。実際、システムは競合他社の価格ポイントや販売データを取り込んで価格弾力性を学習できます ²¹。 仮説検証シミュレーション（たとえば、ツール内でのA/Bテスト ²²）を実行することで、Lokadはユーザーに小さな価格変更が需要をどのように変化させるかを見ることができます ²¹。 これらすべての要素は最終的に在庫の決定にフィードバックされます。たとえば、動かない部品の価格を上げても需要があまり変わらない場合、システムは在庫レベルを下げることを受け入れるかもしれません（逆も然り）。これは共同最適化の実践です - 価格設定と在庫計画の間に人工的な壁はありません。

拡張性とアーキテクチャ。 Lokadはクラウドベースのソリューションとして提供されており（Azureでホストされています）、特筆すべき点はコード駆動です（ユーザーはデータ変換や最適化ロジックをカスタマイズするために専用のEnvisionという言語でスクリプトを書きます）。 これにはある程度の専門知識が必要ですが、高度な自動化とカスタマイズが可能になります。拡張性の観点から、Lokadのアーキテクチャは、クラウドリソースを使用して大規模で疎なデータセットを効率的に処理するように構築されており、すべてのデータを高価なRAMやデータウェアハウスに強制することなく処理できます。 たとえば、互換性グラフアルゴリズムは、ブルートフォースの行列展開に頼らずに約100Mの関係ラインを処理できます ¹⁵。 彼らは列指向のストレージとストリーミング計算を活用しており（彼らのエンジニアリングコミュニケーションによると）、クライアントが日常業務にSnowflakeのような別個のデータキューブのライセンスを取得する必要がないようにしています。 これはおそらく、これらのグラフモデルが、そのような膨大で詳細なデータに苦労する古典的な時系列手法を上回ることを意味します ¹⁶。 Lokadのクラウド最適化に焦点を当てることで、ほとんどの重い作業はサーバーサイドで行われ、クライアントはオンプレミスのHPCハードウェアを維持する必要はありません。 SKU数が増えるとコストが膨れ上がる単一のインメモリモデルに依存する証拠はありません。代わりに、ターゲット指向のビッグデータアルゴリズム（たとえば、カスタム組み合わせソルバーやモンテカルロシミュレーション）を適用して、商品クラウドインスタンスで実行できます。

競合情報とマルチチャネルサポート。 Lokadは設計上、競合他社の価格、Web価格スクレイプ、車両台数データ、eコマースと実店舗の販売など、あらゆる補助データを取り込むことができます。スクリプトアプローチの柔軟性により、ユーザーは異なるデータソースを統合し、Lokadのエンジンはそのパターンを学習したり、適切な決定を行ったりします。 たとえば、競合他社が特定の部品の在庫切れの場合、Lokadは利益を最大化するために価格（および/または在庫）を増やすことを提案できます。これはSyncronも強調している戦略です ²³。 Lokadがそのようなロジックを組み込む能力は、彼ら自身のコンテンツによって裏付けられています：競合他社の価格を比較し、アフターマーケットにおいて小さな価格変更が需要にどのように影響するかを理解することについて議論しています ²⁴。 マルチチャネル需要は、チャネル全体での統合された予測を通じて処理されます - 個別の販売データストリーム（B2Bワークショップ販売、B2Cオンライン注文など）をフィードでき、Lokadの確率モデルは各チャネルの特性を捉えます。 Lokad TVのエピソードでは、Vermorelがeコマースの台頭と、アフターマーケットでのオンラインとオフラインのチャネルが融合する様子について言及し、予測アプローチがこれに適応する必要があると述べています ²⁵。 モデルの粒度（一般的には「特定のチャネルと個々の注文ライン」レベルのデータ ²⁶）により、Lokadは、例えば、オンラインのフラッシュセールと安定したワークショップ需要を区別し、信号の明瞭さを向上させることができます。

自動化 vs. チューニング可能なパラメータ。 Lokadのソリューションは、意思決定において高度に自動化されています。設定されたEnvisionスクリプトは、手動介入なしで毎晩再注文の決定、価格の更新、アソートメントの推奨を出力します。手動の予測オーバーライドや各サイクルごとに調整する数十の計画パラメータはありません - これは従来のツールとは大きく異なります。Lokadは、ABC分類やユーザーが選択した安全在庫レベルなどの概念を「時代遅れ」として批判することがよくあります¹¹。代わりに、プラットフォームは数量モデルに基づいて自動的に決定を行い、ユーザーは制約や目標（予算制限、希望の利益率など）の定義に焦点を当てます。このロボット化されたアプローチは、人間の偏見や労働量を減らすという意味では良いですが、システムへの信頼と正しいモデルの設定には初期の努力が必要です。Lokadは比較的新しいアプローチを取る小規模なベンダーであることに留意する価値があります。将来の顧客は、モデリングの柔軟性が終わりのないコーディングプロジェクトにならないように検証すべきです。ただし、ケーススタディからの証拠（例：Lokadを介したブリヂストンの多段階最適化²⁷、ミスターオートの価格設定の成功¹⁹）は、アプローチがうまく実行された場合には大きな利益が得られることを示しています。

懐疑的な検証: Lokadの主張は、主にエンジニアリングの論理に基づいており、一掃的なマーケティング統計ではないが、計測された結果を求めるべきです。たとえば、Lokadは最適化された意思決定によって「1ドルあたりの故障時間を劇的に削減できる」と暗示しています²⁸。直感的ではありますが、その改善をベースラインと比較することは注意深い分析が必要です。良いニュースは、Lokadが意味のないAIの言葉を大々的に使っていないことです。説明なしに「リアルタイムの認知需要センシング」と謳うことはありません。むしろ、彼らの弱点は、プラットフォームを十分に活用するために熟練したユーザーが必要とされることかもしれません - これは実質的に実装の一部を顧客側に移すことを意味します（Lokadのサポートを受けながら）。それでも、共同在庫価格アソートメント最適化の観点から、Lokadは確率論的で、互換性を考慮した、経済的に合理的なシステムで高い基準を設定しています。最近10年間に構築された遺産のない（過去10年間に構築された）システムと意思決定の最適化に特化した単一の焦点は、データサイエンスに基づくアプローチを扱える企業にとって最高の競争相手となります。

2. Syncron – 専用のアフターマーケットプラットフォーム（在庫 + 価格）

Syncronは、アフターマーケットサービス部品に特化した統合クラウドプラットフォームを提供しており、Syncron Inventory（部品計画）とSyncron Priceの2つの主力モジュールを備えています。多くの競合他社とは異なり、Syncronは同じドメイン向けに両機能を社内で開発し、部品の製造業者や流通業者に焦点を当てたより緊密な統合を実現しています。この焦点は、ディーラーネットワーク、後継チェーンの処理、部品向けの適合した価格戦略などの機能に表れています。Syncronは、在庫管理と価格設定を組み合わせることでシナジーを生み出すことを強調しており、彼ら自身の出版物の1つが指摘するように、「真の最適化をアフターセールスサービス組織全体にもたらすのは、両戦略の組み合わせです。」⁴以下では、Syncronがどのように主要な基準に対処しているかを調査します：

確率的予測＆断続的需要 - Syncronの在庫計画は、サービス部品の需要の断続性に取り組むためにAI/ML予測手法を使用しています。詳細なアルゴリズムはプロプライエタリですが、SyncronはCroston法およびその派生物を実装しており、パターン検出のために機械学習を組み合わせています。彼らのマーケティングは明示的に*「AIパワードサービス部品計画」*を言及し、クライアントに対して部品の可用性が20%向上し、在庫が30%削減されたという結果を謳っています^{29 30}。これらの改善は、従来の再注文システムよりも優れた予測精度と最適化を示唆しています。正確な割合には懐疑的であるべきです（ベースラインやサンプルサイズが示されていない）、しかし独立した参照（例：IDC MarketScapeがSyncronをリーダーとして名指し³¹）は、業界でSyncronの予測が高く評価されていることを示しています。彼らは多段階計画をサポートしており、予測が中央倉庫、地域デポ、ディーラーまでの在庫を割り当てる最適化に供給され、各レベルでの変動性を考慮しています。この多段階アプローチは、自動車業界において重要であり、OEMは世界中で部品を在庫しています。Syncronのシステムは、各階層で需要をシミュレートし、最適な在庫目標を伝播させることができます。それぞれの場所を孤立して扱うのではなく。

部品-車両の互換性と需要シグナル – Syncronの強みは主に部品計画の側にあります（これにはスーパーセッションやグルーピングが含まれます）が、予測において車両台数データを明示的に使用することは少ないです。とは言っても、Syncronは部品スーパーセッションチェーン（部品番号が別の部品番号に置き換えられる場合）を完全に処理します。実際、自動車業界ではOEMが時々*「競合他社を遠ざけるために技術的な理由なしに新しいスーパーセッションアイテム番号を生成することがある」*と述べています。Syncronのソフトウェアはこのようなスーパーセッションアイテムをリンクし、需要履歴を統合し、将来の予測が断片化されないようにします – これは彼らが提供する基本的な必要性です。異なるブランドやソース間の**互換性（交換可能性）*に関して、Syncronは機能的に等価な部品の「PICS/VAUマトリックス」または相互参照を定義することを許可します。彼らの共同最適化ブログでは、挙げられた利点の1つは次のとおりです:「競合他社が在庫を保持しないアイテムの価格を上げるためにPICS/VAUマトリックスやサービスレベルから情報を使用する」*というものです。これは、Syncronの価格設定モジュールが在庫の可用性と互換性を認識していることを意味します。他で見つけるのが難しい部品の場合、システムはより高い価格を提案します。これは真の互換性の推論の代理となります – 部品の需要を予測する代わりに（Lokadのアプローチ）、Syncronは同等の部品を認識して戦略を調整できるようにします（特に価格設定）。

Syncronのソリューションはネイティブで「車両」レベルで予測を作成するかもしれませんが、詳細な過去の需要を取り込み、外部ドライバーを組み込むことができます。彼らの文書には*「何百万ものデータポイント」*が言及されており、ディーラー在庫管理のためにIoT/テレマティクスデータ（例：GPS、使用パターン）さえ使用しています。これは、提供された車両の使用状況や台数データがあれば、Syncronがそれを予測に反映させることができる可能性があることを示唆しています。実際には、ほとんどのSyncronユーザーは、需要履歴（出荷、ディーラー注文）を主要なシグナルとして依存しており、これはある程度互換性を反映しています（各需要トランザクションはおそらくすでに適合する部品のために発生しているため）。Syncronが輝いているのは、部品が変更されたり代替品がある場合に需要が失われないようにすることです：彼らの統合プラットフォームは、計画において交換可能な部品を別々に扱う古典的なエラーを防ぎます。

経済最適化と価格統合 – Syncronは在庫と価格を一緒に最適化することが有益であると明確な立場を取っています。彼らは部品の可用性に基づく価格設定や在庫ライフサイクル段階による価格設定などのシナリオを強調しています。具体的には、例えば、Syncron Priceは市場で希少な部品（競合在庫が少ない）や故意に在庫を少なく保持している部品の価格を引き上げることを推奨できます。供給と需要をバランスさせるために。逆に、在庫が過剰または陳腐化している場合、Syncronは価格の引き下げをトリガーしてクリアすることができます。これは経済的意思決定の一形態です：価格設定を在庫コスト削減のレバーとして使用し、在庫状況を利益のための価格設定に通知することです。彼らはまたサービスレベルに結びついたチャネル固有の価格設定を言及しています – たとえば、高い利益率のチャネルの部品にはプレミアム価格を請求し（より高いサービスレベルに投資する）、競合が少ないキャプティブ部品には低いサービス（在庫切れリスク）を受け入れるかもしれませんが、顧客には選択肢がないため、キャプティブ性による価格の維持も行うかもしれません。これら微妙な戦略は、Syncronの最適化が純粋なコスト最小化やサービス最大化ではないことを示しています；それは収益と利益を最大化し、サービス目標を達成しようとします。実際、彼らのメッセージ「無駄を出さずに利益を上げる」は示唆的です。

Within Syncron Inventory, users typically set target service levels or fill rates for various categories of parts, and the software optimizes stock levels to hit those at minimum cost. However, thanks to integration with Syncron Price, those targets can be informed by price sensitivity. Syncron Price itself uses advanced analytics to optimize price points: it moves clients beyond simplistic cost-plus pricing to value-based and competitive pricing. A Syncron consultant noted the importance of defining “the local competitor set…and qualifying competitor item cross-references in terms of functional fit, quality and brand value to find the correct competitive price positioning.” ³² This shows Syncron’s pricing tool can store and analyze competitor prices for equivalent parts (with the user qualifying which competing products truly match). Strategies like automated price leadership/followership (e.g. always 5% above a competitor or 5% below) can be configured ³³, and the system will execute those rules on large catalogs. More sophisticated is their price elasticity analysis: Syncron Price can measure how demand volume changes with price for sensitive parts ³⁴, giving a “scientific view of volume impact” that helps set an optimal price.

All these pricing capabilities loop back to inventory optimization by influencing what demand will be (and how profitable). While it’s not fully unified in one single algorithm (inventory and price are still separate modules exchanging data), Syncron has effectively pre-integrated the data and workflows. The result is a form of prescriptive analytics: e.g. if a part’s optimal price goes up, Syncron Inventory will see slightly lower forecasted demand and won’t overstock it; if a big promotion or price cut is planned, the forecast can be adjusted upward and inventory positioned accordingly ^{35 36}. They explicitly mention ensuring inventory support during price promotions so you can tell if a sales spike was genuine new demand or just timing shift ³⁶.

Scalability & cost efficiency. Syncron’s solutions are SaaS, hosting data and computations on the cloud (likely Azure). They claim 20k+ instances deployed across 100+ countries ³⁷, implying a robust multi-tenant cloud. In terms of data scale, many Syncron customers are major OEMs (e.g. Volvo, JCB, Hitachi). The software handles tens of millions of part-location combinations and large transactional histories. There haven’t been public red flags about scaling limits; Syncron’s original on-premise versions (from a decade ago) have been modernized to a cloud-native stack in recent years. One area to watch is cost: Syncron does not rely on something like Snowflake for analytics as far as known, but being a specialized provider, its subscription costs can be high (reflected in one source noting Syncron’s cost as “much lower than average” in one rating, possibly due to pricing not being user-based but value-based ³⁸). The benefit is that you’re not paying separately for a data warehouse – Syncron brings its own optimized data management for parts. They also provide a supplier portal and virtual warehouse features ^{39 40} (for collaboration and pooling stock), adding value beyond core calculations. From a technology standpoint, Syncron doesn’t push extremely trendy terms; “AI-powered” is used, but behind it are known methods tailored to spare parts domain (e.g. probabilistic forecast, optimization solvers). This suggests their R&D is focused, not generic AI hype. We should, however, scrutinize the impressive performance claims on their site (40% cost reduction, etc. ²⁹) – these likely represent cherry-picked successful projects. For instance, “30% inventory reduction” ³⁰ might have come from an OEM that previously had no optimization at all. It’s not guaranteed for a company already using some planning tool.

競合情報の統合。 Syncronは、競合他社の価格や市場データを価格推奨に組み込むことを明確にサポートしています。彼らがユーザーに競合他社のセットを定義し、クロスリファレンスを行うようアドバイスするのを見ました ³²。これは、たとえばOEMが予備部品を販売している場合、アフターマーケットのサプライヤーの部品番号と価格をSyncron Priceにロードし、自社の部品にマッピングすることができるということです。ソフトウェアは、競合他社に対して望ましいマージン内で価格を自動的に維持することができます。また、地理的な違いも考慮されており、地域によって現地の競争が異なることがあります ⁴¹。この機能はアフターマーケットにおいて重要であり、第三者サプライヤーがしばしばOEMを割り込む場合、Syncronは体系的な対応方法を提供します。競合他社の部品に関する互換性行列の取り扱いに関しては、ユーザーはクロスリファレンスを維持する必要があります（たとえば、競合他社Xの部品1234が私の部品ABCと同等であることなど）。システムはこれを魔法のように知っているわけではありませんが、設定されると、そのマッピングを使用して価格を調整し、競争がない部品を示すことさえできます（価格を安全に引き上げることができる部品）。Syncron Inventoryは競合他社のデータを直接使用しません（ほとんどの企業は在庫レベルを共有しません）、しかし、自社の在庫を最適化することで、価格競争力を知ることにより、間接的に計画を立てることができます。たとえば、独自の価値部品に対して高い価格を設定し、商品化された部品に対しては低い価格を設定する価値ベースの価格戦略を選択した場合、Syncronの統合アプローチにより、在庫投資がそれに続くことが保証されます - 高利益率で高勝率の部品にはより多くの在庫があり、価格で損をする部品を過剰在庫にしないようにします ⁴²。

マルチチャネルと自動化。 Syncronは主にB2Bチャネル（OEMからディーラー、OEMから独立ネットワークへ）とマルチエシュロンマルチチャネルシナリオをサポートしています。メーカーはSyncronを使用して中央在庫と数十のディーラーの在庫を管理することができます（彼らのディーラー在庫管理ソリューションは、各ディーラーの地域需要と中央データに基づいて現地在庫レベルと再注文ポイントを設定するのを支援する拡張機能です ⁴³）。販売チャネルに関して、Syncronの需要予測は地域や顧客の種類によってセグメント化することができます。アフターマーケットでは、チャネルが小売店とeコマースのようにはないため、「オムニチャネル」とは明示的に呼ばれないかもしれませんが、アイデアは似ています - すべての流通ノードで需要の統一されたビューを得ることができます。

自動化に関して、Syncronのソリューションは、高度なハンズオフ運用を目指していますが、戦略に対するユーザーの制御も可能です。Syncron Inventoryを使用するプランナーは、再補充を大部分自動化することができます（システムは注文/提案を継続的に生成します）。彼らのビュレットポイントの1つは「再補充計画の自動化」です ⁴⁰。価格モジュールも同様に、ルールと最適化に従って新しい価格リストを自動生成することができます。ただし、Syncronはユーザーの入力を完全に排除しません：ユーザーはセグメンテーションを定義し、初期ルールを設定し、価格提案をオーバーライドまたは承認することができます。システムは、「もしも」シナリオをシミュレートするための豊富なUIを提供し（たとえば、価格変更がボリュームに与える影響を見る）、承認前に推奨事項を確認することができます。これは、Lokadのコード中心の自動化と比較して、より伝統的な意思決定支援アプローチです。ガバナンスと専門家の監督を望む組織にとって有益です（たとえば、価格マネージャーが戦略を微調整し、システムに再計算させることができます）。ただし、ユーザーが過度に干渉したり、多くのパラメーターが公開されたりすると、これは弱点になる可能性があります。Syncronのブログは、価格設定と在庫のペアリングによって複雑さと重複した作業が削減されることを警告しています ⁴⁴ - つまり、統合されたプラットフォームでは、2つの別々のデータ統合や調整プロセスを維持する必要がないということです。実際、彼らは、1つのシステムで両方を持つことにより、TCOが削減され、アップグレードが容易になると述べています ⁴⁴。

懐疑的な視点: Syncronは、具体的なエンジニアリングの考慮事項（たとえば、価格設定と在庫統合が予測需要を価格シミュレーションに使用する方法や、プロモーションが実際に需要を生み出したかどうかを評価する方法など）を裏付けてアプローチを支持しています。これは信頼性を与えます。未だにサポートされていないハイプには疑問を持つべきです。たとえば、「AI駆動」という用語が使用されていますが、AIの詳細は通常、「大規模データ上の機械学習」という表現を超えて説明されていません。Syncronに具体的な情報を求めることは賢明です（予測にニューラルネットワークを使用していますか？勾配ブースティングを使用していますか？ゼロ需要期間を数学的にどのように処理していますか？）。また、Syncronはリーダーであり多くの大規模なクライアントを持っていると主張していますが、一部のプロジェクトでは長期間の実装が報告されています - 複雑なERPシステムとの統合、数十年にわたる部品データのクリーニングなどは簡単ではありません。ベンダーが迅速なROIを約束する場合、参照先を要求するべきです：それらの「50以上のエンタープライズクライアント」⁴⁵は全員20％の可用性向上を達成しましたか？おそらく均一ではないでしょう。懐疑的な視点のもう一つのポイント：ユーザー調整対自動化。 Syncronは多くの構成可能性を提供しています（サービスクラス、価格セグメントなど）、これは両刃の剣となり得ます。技能の低いチームは高度な機能を十分に活用できず、最適でない結果につながる可能性があります（その後、彼らはツールを責めるかもしれません）。

全体的に、Syncronはアフターマーケット向けに価格設定と在庫を意図的に結びつけるための共同最適化能力で非常に高いスコアを獲得しています。それは断続的需要と部品の置換の核心的な課題を扱います。Lokadほど斬新なアプローチではないかもしれませんが、信頼性のある実績のある技術を用いています。その主な利点はアフターマーケット向けに構築されていることであり、カスタマイズの必要性を減らしています。懐疑論は、大胆な主張が自分の状況に当てはまることを確認し、統合が広告通りに機能することを確認することにほとんど集中しています。Syncronのコンテンツは多くの信頼性チェックをパスしています（具体的な例、あまりにも多くの専門用語の不在など）、そのため、在庫と価格の最適化が本当に協力するトップソリューションの1つであるという評価は変わりません。

3. PTC Servigistics – エンタープライズグレードのサービス部品最適化（在庫と価格）

Servigisticsは、PTCが所有する最も古く、最も広く展開されているサービス部品管理（SPM）システムの1つです。これは、航空宇宙・防衛、自動車OEM、ハイテク、産業企業がアフターセールスサプライチェーンに使用するエンタープライズグレードのソリューションです。Servigisticsは実際には、サービス部品管理（予測と在庫最適化）とサービス部品価格設定を含むスイートです。PTCは公式のニュースブリーフで、「PTCのServigisticsサービス部品管理およびサービス部品価格設定ソフトウェア」がAIと最適化アルゴリズムを活用して統合的に提供されていることを強調しています⁵。数十年にわたり、Servigistics（および吸収された前身）は、多階層在庫最適化の豊富な機能を開発してきました。最近では、機械学習とIoTに基づく予測の改善を追加しています⁶。

断続的需要予測とAI。 Servigisticsは、まれな部品需要に適したアルゴリズムの長い歴史を持っています。おそらく、Croston法、ブートストラップ、高度な時系列手法を使用して予測しています。2020年、PTCは、「機械学習と高度な最適化エンジンを活用して予測精度を向上させ、在庫の最大活用を図っている」と発表しました⁶。PTCはさらに、サービスサプライチェーンの最適化のためのアルゴリズムと数学の開発に10億ドル以上を投資したと主張しています⁴⁶ - これは検証が難しい数字ですが、数十年にわたる研究開発（以前の企業の作業も含む、たとえばServigisticsはXelusなどの元競合他社の一部を買収しています）を裏付けています。実際には、Servigisticsは需要を「需要ストリーム」に分割して別々に分析することを可能にします⁴⁷ - たとえば、1つのストリームは定期メンテナンス需要、別のストリームはリコールやキャンペーンのためのものです。これにより、原因別に断続的な需要をモデル化し、安定性を高めることができます。Servigisticsはまた、IoTデータを使用した因果関係予測をサポートしています：アドオンを使用して、PTCのThingWorxプラットフォームを活用して接続された機械データ（たとえば、部品の故障を予測するセンサー）を収集して予測を調整します^{48 49}。これは、IoTに焦点を当てたPTCに固有の高度な機能です。

マルチエシュロン最適化は、中核的な強みです。このツールは、複雑なネットワーク（中央倉庫、地域倉庫、現場ロケーション、バンなど）全体で在庫を最適化し、各所で目標サービスレベルを最小のコストで満たすための最適な在庫レベルを推奨することができます。ある事例では、Pratt & WhitneyがServigisticsに切り替え、合併後に統合計画を行った結果、在庫を10%削減し、フィル率を10%向上させたことが記録されています⁵⁰。このような改善は、より良いマルチエシュロンアルゴリズムを示唆しています（おそらく、シロ化された計画ではなく、より包括的でネットワーク全体を対象とした最適化）。Lokadが「SKUごとのローカルサービスレベルに焦点を当てた古典的なツール」に対する批判⁵¹は、おそらく古い手法を指しています。Servigisticsは、ネットワーク効果（たとえば、上流でより多くの在庫を保持することで、より少ない総在庫で複数の地域をカバーできる）を考慮することで、それを回避しようとしています。PTCはこれをマーケティングで強調しています：「適切な部品を適切な場所に適切な時に適切なコストで」⁵²という信条を確保すること。

部品の互換性とデータの複雑さ。 Servigisticsは、サービス部品に焦点を当てているため、スーパーセッション（ある部品が別の部品に置き換わること）をシームレスに処理します。これにより、Part AがPart Bを置き換えるときに、Aの将来の需要にはBの過去の需要が含まれるように自動的に予測をリンクさせます。また、廃止された部品の最終購入数量を提案したり、新しい部品の在庫を増やす際にもサポートします。ただし、ServigisticsはLokadのようなグラフベースの互換性ロジックを明示的に宣伝していません。それは、正確な部品マスターデータと計画階層（たとえば、「機能グループ」や機器タイプで部品をグループ化する）に依存しています。あるPTCコミュニティの投稿では、彼らの製品管理にはVendavoの価格設定プラクティスとMCA Solutionsからの人々が関与していることが示唆されており、内部で価格設定と在庫の専門知識が融合していることを示しています。この相互交流は、価格設定と需要の相互作用を考慮した可能性があるが、歴史的にServigistics Pricingは別々のモジュールであり、異なるコードベースから派生した可能性がある（おそらく、2010年頃にPTCが行ったSPM競合他社の買収による価格設定ツール）。

サービス部品価格モジュール。 PTCのServigistics Pricingは、スペアパーツの価値ベースの価格設定に向けられています。通常、部品をセグメント化（競争レベル、独占部品対非独占部品、顧客への価値などによって）し、利益を最大化する価格を設定するのに役立ちます。たとえば、OEMは、顧客が便利さを重視することを知っている場合、低コストのファスナーに大幅な値上げを行うかもしれませんが、高コストのエンジン部品には控えめな値上げを行い、OEM部品の使用を奨励するかもしれません。価格設定モジュールは市場価格を追跡することもできますが、競合他社の価格統合に関する詳細はPTCからはあまり公開されていません。PTCは製造業者に焦点を当てているため、彼らの価格最適化はしばしばサービス契約や全体的なサービスライフサイクル価値に結びついています（保証やサービス契約のためのモジュールも持っています）。そのため、PTCは価格設定にやや異なる視点でアプローチする可能性があります：個々の部品のマージンだけでなく、ライフサイクルの収益性を確保すること。これは、PTCが「サービスライフサイクル管理（SLM）」を強調していることからも明らかです。実際、PTCはしばしば、価格設定、在庫、フィールドサービスなどがすべてデータを共有するSLMスイートを販売しています。

PTCからの注目すべき引用は、「厳格な評価を通じて… [さまざまなクライアント] が、Servigisticsを市場で唯一の価値を最大化し、コストを最小限に抑えることができるソリューションとして検証している」⁵³と主張しています。この大胆な発言（おそらくスポンサーされたアナリストやユーザーグループからのもの）は、彼らが他の人よりもサービスとコストのベストスポットを見つける最適化を実現していると信じていることを示唆しています。このような表明は慎重に扱う必要がありますが、どのツールも文字通りに「唯一の」ものではないということを示しています。しかし、これは、PTCがServigisticsを最適な最適化ツールとして位置付けていることを示しています。

共同最適化の現実。 Servigisticsは本当に価格設定と在庫最適化を統合していますか？ソフトウェアでは、2つのモジュールがいくつかの統合を持っています（部品データベースを共有し、価格の推奨事項は在庫パラメータによっていくらか情報提供されることがあります）。しかし、歴史的には異なるため、統合はSyncronのように緊密ではないかもしれません。PTCが2020年にAIの改善とともにそれらをまとめて発表したこと⁵は、それらが協調して機能するようにする取り組みを示しています。たとえば、価格設定モジュールに在庫モジュールが見る需要弾力性を提供したり、その逆を行ったりする可能性があります。たとえば、価格の変更がフィル率や在庫決定にどのように影響するかをシミュレートすることが可能であるかもしれませんが、これが一つのシームレスなユーザーエクスペリエンスになっているかどうかは不明です。PTCの顧客（通常、どちらかを使用することが多い）を考えると、完全な共同展開はまれかもしれません。しかし、別々でも、それぞれのモジュールは強力です。

拡張性とアーキテクチャ。 Servigisticsは巨大なスケールでの実績があります - Boeing、Deere、Caterpillar（過去に）が使用しており、それぞれ数百万の部品と世界規模の運用を扱っています⁵⁴。PTCは現在、PTC Cloud上でSaaSとして提供していますが、多くの大規模ユーザーは引き続きオンプレミスまたはプライベートクラウドインスタンスを使用しています。これは重いアプリケーションスタックです（おそらくJavaベースで、リレーショナルデータベースを使用しています）。デフォルトでは外部のクラウドデータウェアハウスに依存していません。PTCは独自のデータスキーマと計算エンジンを持っており、多くのものが大規模な線形プログラムやヒューリスティクスをインメモリで実行しています。過去には、メモリと計算時間の制約が大規模プロジェクトに課題をもたらしました（例：数千万の部品-場所の組み合わせの最適な購入を計算することはNP困難である可能性があります）。PTCは時間とともにパフォーマンスを向上させてきました - 例えば、*「パフォーマンスアナリティクスとインテリジェンスモジュール」の改善やAIを使用した原因分析⁶。おそらく、より多くのクラウド弾力性も活用しているでしょう（重いシナリオに対してより多くの計算ノードを立ち上げる）。彼らがSnowflakeのようなものを使用しているという公開情報はありません。おそらく、PTCは分析をアプリ内に組み込む傾向があるため、そうではないでしょう。コスト面では、PTC Servigisticsはプレミアムソリューションです（ライセンスと実装にはしばしば数百万ドルかかります）。価値（現場での在庫切れの削減、サービス収益の向上）が高ければ、そのコストは価値があるかもしれませんが、小規模なディストリビューターにとってはコストがかかりすぎるかもしれません。また、それがモノリシックなエンタープライズソフトウェアであるため、実装コストとリスクは無視できないものです - これはしばしばPTCの競合他社によって悪用されます。実際、GartnerのJDAがi2を買収した際のコメント（当時Servigisticsの競合他社であった）では、i2が「管理が難しい…[製品が増殖している]」*と指摘されています¹⁰。Servigistics自体も複数の買収を経験してきました（PTCが2012年にServigisticsを買収し、それ以前にServigisticsはClick Commerceの部品ソフトウェアを買収していましたなど）、そのため、レガシーレイヤーがあります。PTCは数年間にわたり統合と再ブランディングに取り組んできましたが、いくつかの基盤となるコンポーネントは完全に統一されていないかもしれません。

競合データとインテリジェンス。 伝統的に、Servigistics Pricingでは競合価格情報の入力を許可していましたが、新しいクラウドツールほど動的ではないかもしれません。PTCのVPがVendavo/Deloitteの価格設定プラクティスのバックグラウンドを持っているという言及⁵⁵は、B2B価格設定をよく知っていることを示唆しています（Vendavoは製造業向けの価格設定ソフトウェアです）。したがって、Servigistics Pricingには、セグメントに基づいた価格ガイダンス、マージンのウォーターフォール分析などの機能が含まれている可能性があります。競合他社の価格を自動的にスクレイプしたり更新したりすることはないかもしれません - ユーザーは定期的に市場価格情報をインポートする必要があります。また、多くのPTCの顧客がOEM部品がアフターマーケットやグレーマーケットと競合するセクターにいるため、高い競争がある部品と唯一の供給元である部品を特定する機能を持っている可能性が高いです。PTCのドキュメントは頻繁に顧客価値と稼働時間の最大化をほのめかしています。TrustRadiusのレビューには、*「適切な部品を…適切な価格で持っていることを確認する」*というトップ機能があるとさえさり気なく述べられています⁵⁶。これは、価格最適化が少なくとも一部のユーザーによって実際に使用されていることを示唆しています。

マルチチャネルとマルチ目的。 Servigisticsはアフターセールスチャネル（サービス部品）に焦点を当てています。それ自体は、消費者への部品のマルチチャネル小売販売用に設計されているわけではありません（PTCはこれをAutoZoneやAmazonをターゲットにしていませんが、OEMおよびディーラーネットワークを対象としています）。ただし、そのコンテキスト内では、複数のチャネルをカバーしています：OEMは独自のサービスセンター、独立ディストリビューター、直接販売のための部品を計画することができ、各チャネルの需要を考慮しています。また、フィールドサービスシステム（ServiceMaxなど）と統合しており、サービスの実行を部品計画とつなげています。この種の統合により、フィールド技術者が部品を使用するとすぐに、Servigisticsは在庫を調整し、機械が問題を報告した場合には使用量が増加することさえ予測できます。これは自動化につながります - 需要信号を自動的に感知して応答します。

自動化とユーザー調整。 Servigisticsは多くの意思決定を自動化できます（配送オーダー、発注提案、在庫の再調整）。しかし、通常、大規模な組織ではプランナーが出力を確認します。ソフトウェア自体はルールに従って動作します：ユーザーはポリシーを設定します（例：部品分類ごとのサービスレベル目標、最小/最大レベルなど）、システムは提案を計算します。プランナーが予測を分析し、在庫の健康状態を確認し、パラメータを微調整するための非常に包括的なユーザーインターフェースを持っています。PTCはUXを改善するために取り組んできました（彼らは「デザイン思考を活用してユーザーエクスペリエンスを変革する」と述べています⁴⁶）。それでも、Servigisticsは多くのツマミを公開していると批判されるかもしれません - 柔軟性と呼ぶ人もいれば、複雑性と呼ぶ人もいます。たとえば、適切に構成されていない場合、より最適な結果を生み出さない可能性があり、コンサルタントが設定を調整するためにやって来るかもしれません。PTCは包括的なドキュメントを提供し、顧客アドバイザリーグループを設立してベストプラクティスを共有しています⁵⁷、したがって彼らはユーザーの知識が重要であることを認識しています。自律モードは実際にはServigisticsの売りではありません。むしろ、人間のプランナーを補完するものです（新しい競合他社であるEvoが「マネージャーがより良い意思決定を行うのを支援するAI」と表現した方法⁵⁸は、皮肉にもServigisticsの理念と一致しています）。

批判的な視点： Servigisticsは長寿命で幅広い機能を持っていますが、それには過去の遺産が付いてきます。過去に特に多くのユーザーが失敗したり停滞した実装を経験しています。たとえば、米空軍の採用はデータの問題やプロジェクトの範囲のために結果を出すのに数年かかりました（最新バージョンを使用して成功例として引用されていますが⁵⁴）。業界でよく引用される歴史的な逸話の1つ：CaterpillarはServigisticsを使用していましたが、最終的にSyncronに切り替えました - この移行は、Servigisticsがその場合に期待されたように機能していなかった可能性を示唆しています（詳細は内部事情ですが、新しい競合他社が既存の企業に挑戦した方法を反映しています）。PTCは、IoTデータ（ThingWorx）の統合、AI分析の追加など、このような結果を防ぐために革新しようとしてきました。しかし、これらの新しい要素が古いコアにどのようにシームレスに適合するか疑問に思う必要があります。たとえば、彼らの機械学習予測が実際の展開で本当に古い統計モデルを上回るのでしょうか？それとも、ほとんどの顧客が完全に活用していないセリングポイントなのでしょうか？PTCの「無類の深さ」という主張は、大規模なインストールベースと機能チェックリストによって部分的に裏付けられていますが、より小規模な競合他社は特定の分野でより機敏かもしれません（互換性モデリングではLokad、クラウド展開の容易さではSyncronなど）。また、Servigisticsの価格最適化機能はあまり宣伝されておらず、専門の価格設定ベンダーと比較して可能性が低いかもしれません。ルールベースの価格設定や単純な弾力性を行うかもしれませんが、電子商取引業者が必要とするリアルタイムの競争価格設定ではないかもしれません。

要するに、PTC Servigisticsは在庫最適化の強力な支援力を持ち、価格最適化のための堅実でやや伝統的なソリューションです。それは非常に大規模な運用で信頼されています（これはそのスケーラビリティを証明しています）。共同最適化は概念的に存在しています - PTCはサービス部品のライフサイクル全体を財務的および運用的にカバーできます - ただし、実装中に価格モジュールと在庫モジュールが本当に適切なデータと前提条件で互いに通信することを確認する必要があります。うまく実装されれば、Servigisticsのユーザーは、サービスレベルを維持しながら、部品セグメントごとの利益を最大化する価格で、グローバルに最適化された在庫を実現できます。注意すべきは、複雑さに迷い込まないことです（熟練したリソース、注意深いデータメンテナンス、および可能性のある重要な統合作業が必要とされるため、完全な価値を実現するために）。

4. ToolsGroup（Service Optimizer 99+およびEvo）- 在庫最適化と価格のための指示型AIを結びつける

ToolsGroupは、サプライチェーンプランニングのベテランであり、需要予測と在庫最適化に特化した**Service Optimizer 99+ (SO99+)**ソフトウェアで知られています。特に長尾と断続的な需要に対応しています。多くの流通業者や製造業者（自動車および産業を含む）が、在庫計画のためにToolsGroupを利用しています。最近まで、ToolsGroupはネイティブの価格最適化を提供していませんでした-在庫/サービスレベルに焦点を当てていました。しかし、2023年末に、ToolsGroupは価格とプロモーションの最適化に特化したAI企業であるEvoを買収しました⁷。この買収（および以前に小売計画ツールJustEnoughを買収したこと）は、価格と在庫の意思決定が一致する「共同、意思決定中心の計画」を提供するToolsGroupの戦略を示しています⁸。統合された提供は、「ダイナミックプランニング」と「.io」製品スイート（例：Inventory.io、Price.io、Markdown.io）の周りにブランド化されています^{59 60}。ここでは、ToolsGroupのアフターマーケット最適化の文脈での能力を評価し、その価格最適化部分が非常に新しいことを認識しています（したがって、機会と懐疑点の両方です）。

確率的予測と断続的需要の習得。 ToolsGroupは長い間、「断続的需要を予測する卓越した能力」を宣伝してきました⁶¹。彼らのSO99+システムは、在庫計画のために単一の予測ではなく確率分布を使用する先駆者の1つでした。彼らは内部および外部の要因を組み込み、自動的に「新製品の導入、代替品、廃止」などの処理を行います²⁶ - 部品が頻繁に取り替えられたり段階的に導入/廃止されるサービス部品にとって重要です。 ToolsGroupの需要モデリングは、最も細かい粒度（注文行）で分析し、部品の使用の断続的な性質を捉えます²⁶。アフターマーケットでは、例えば、特定の部品が年に数ユニットしか売れないことを検出し、ポアソン分布などのキャリブレーションされた分布を使用して適切に計画できます。これにより、在庫切れの恐れによる在庫過剰を回避できます-彼らの顧客が在庫を大幅に削減しながらサービスを維持または向上させるというセリングポイントです。実際、ToolsGroupは、クライアントが達成した在庫削減30-40％および96％以上の製品可用性などのメトリクスを頻繁に引用しています⁶²。これらの数字の一般性を疑問視すべきですが（おそらく最良のケース）、独立したアナリストはToolsGroupのサービスレベル最適化の強みを指摘しています-最小限のコストで目標の充足確率を満たすための在庫のバランスを取ることです。

マルチエシュロンと長尾の焦点。 ToolsGroupは、SyncronやPTCのように、マルチエシュロン配布をネイティブで処理します。たとえば、中央倉庫と地域倉庫でどれだけの部品を保持するかを最適化して、バックオーダーや緊急出荷を最小限に抑えることができます^{63 64}。製造に関するToolsGroupのブログでは、「公平な割り当てロジックを含む補充計画プロセス全体をカバーしている」と述べており、戦術的計画を実行に結びつけています⁶⁵。自動的に代替品を処理することを明示しています²⁶ - つまり、部品Aが部品Bに代替できる場合、その需要分析に考慮されます。これは互換性の処理に似ていますが、おそらく一対一の代替（新しい後継部品など）についてのものであり、広範な交換可能性セットについてではないと考えられます。

**部品-車両互換性マトリックスの取り扱い。歴史的に、ToolsGroupはLokadのように互換性マトリックスの概念に関する独自の機能を公開していませんでした。彼らは、クライアントが定義した需要履歴と製品階層に依存しています。クライアントが構造化された互換性または交換ファイルを提供する場合、ToolsGroupのモデルは部品グループを関連付けることができます（たとえば、「返品と代替品」モデリングを通じて）⁶⁶。それは、各車両のニーズをモデリングするほど細かくないかもしれません。ただし、ToolsGroupには自動車関連のクライアントがおり、おそらくACES/PIESデータ（北米の業界標準のアフターマーケットデータ）を、同等部品の需要を集計することで取り扱っています。明示的な言及がない場合、ToolsGroupは代替部品のリストで作業し、グループ全体の需要を効果的に予測し、それを市場シェアやその他の要因に基づいて各アイテムに割り当てることができると仮定します。それは、生の車両データからそれを計算することができないかもしれません。つまり、ToolsGroupにモデルを構築せずに、生の車両データを部品の予測に直接変換することはできません。これは、ToolsGroupが新しい「データハブ/デジタルサプライチェーンツイン」**コンセプト⁶⁰に依存して、さらに多様なデータソースを組み込むことができる領域です。おそらく、車両のテレメトリや登録など、さらに多様なデータソースを組み込むことができる領域ですが、これにはカスタム構成が必要です。

**経済的意思決定と新しい価格最適化（Evo）。*ToolsGroupのコア在庫最適化は、従来、サービスレベルとコストのトレードオフに基づいて機能していました。ユーザーはサービスレベルの目標を設定します（またはシステムが在庫切れコストと保有コストのバランスを取ることで最適なサービスレベルを見つけます、これは経済的アプローチです）。その結果、在庫の推奨事項が得られ、最小の在庫投資で一定の充足率を達成します- 間接的には経済的結果（在庫の最大ROI）。ただし、価格がないと、利益最大化を直接計算することはできませんでした。Evoの取得により、真の経済最適化機能が導入されました：Evoの技術は、価格などに対する「非線形最適化、量子学習、高度な予測分析」*を提供しています⁸。量子学習はバズワードのように聞こえますが、おそらくEvoが開発したいくつかの新しいAIアルゴリズムを指しています（Evoは学術研究との関係があり、ハーバードのケーススタディさえあります）⁶⁷。重要なのは、Evoのソリューションが価格やプロモーションさえも最適化してビジネス目標を達成することです。たとえば、Evoは、各部品の最適な価格を決定して、需要の変化を考慮しながら総利益を最大化することができます。これをToolsGroupの在庫エンジンと統合することで、組み合わせたシステムは、理論的には、両者を調整することができます：Evoが特定の部品の価格を下げて市場シェアを獲得することを提案した場合、ToolsGroupの在庫計画は、需要が高まることによる在庫切れを避けるために、それらの部品の在庫を増やすことができます。逆に、在庫が非常に制約されている場合、システムは価格を上げる（または割引を避ける）ことで需要をバランスさせるかもしれません。

ToolsGroupはすでにこのシナジーをマーケティングし始めています。彼らのプレスリリースによると、統合は*「最も効率的でリアルタイムのサプライチェーンと価格最適化ソリューションを提供する」と述べています⁶⁸。彼らはまた、在庫と価格に関する決定がAIによって最小限の人間の入力で行われる*「自律サプライチェーン」についても話しています⁶⁹。要するに、ToolsGroup + Evoは、在庫と価格（さらにはプロモーションや顧客のセグメンテーションなどの他のレバー）の共同最適化を目指しています。ToolsGroupのCEOは、Evoの機能が意思決定中心の計画**を可能にすると強調しました- つまり、システムが単なる洞察ではなく、直接的な意思決定を出力するということです⁸。

具体的には、ToolsGroupには現在、Price.io（Evoから）というモジュールがあります^{59 60}。Evoの方法論は、すべての関連データ（売上、コスト、競合他社、天候など）をマッピングして、最適な価格を推奨することを含んでおり、市場状況に適応するための「テストアンドラーン」反復的アプローチを使用して予測を洗練させます⁷⁰。1つのスニペットには次のように記載されています：「Evoは、売上、コスト、顧客、天候、競合他社などの既存データのマップを構築し、最適な価格設定を提案し…予測の精度を向上させ、市場状況に迅速に適応して、組織が顧客を満足させながら在庫効率と収益性を向上させることができるようにします」⁷⁰。これは、価格行動を在庫効率に結びつける強力な主張です- たとえば、価格の引き下げが需要を増やしている場合、EvoのAIが気づき、ToolsGroupが在庫が予期せずに不足するのを防ぎます。

アフターマーケットでこの共同ソリューションの事例を見るのはまだ早いですが、ToolsGroupは在庫管理のために自動車アフターマーケットの顧客を持っていました（たとえば、2024年のブログではアフターマーケットメーカーがEV関連部品の需要変化をナビゲートするのを支援することが記載されています^{71 72}）。価格設定により、たとえば、部品ディストリビューターがチャネル全体で価格を動的に調整し、在庫の深さを最適化するのに役立つかもしれません。ToolsGroupはまた、廃止予定の部品のための**Markdown最適化（Markdown.io）やプロモーション（Promo.io）**を提供しており、これは時代遅れの在庫を整理したり、売れ行きの悪い商品をバンドルしたりするのに関連するかもしれません - これは直接アソートメントの最適化の決定に関連しています。

拡張性とアーキテクチャの考慮事項。 ToolsGroupの在庫エンジンは中規模から大規模な問題（数十万のSKUロケーション）で実証されています。非常に大規模な展開（数百万のSKU）では注意深い調整が必要かもしれませんが、クラウドサービス（Inventory.io）への移行は、簡素化とスケーリングを目指していることを示唆しています。新しい“.io”製品は、よりクラウドネイティブなアプローチを示しており、おそらくマイクロサービスを使用し、現代的なデータバックエンドを使用している可能性があります。たとえば、Inventory.ioは2024年1月に発売され、リアルタイムの需要信号と在庫の総利益回転率（GMROI）を最適化する「AIパワード在庫最適化」を約束しています^{73 74} - 在庫を利益に直接リンクさせることにより、在庫を利益に直接リンクさせることは新しいことであり、おそらくEvoの影響のおかげです。 “Evo showed us that responsive inventory…”（おそらく市場の変化に応じて在庫戦略を動的に調整することを意味する）というヒントがあります⁷⁴。これは、ToolsGroupがSO99+の一部を再設計してEvoのロジックを統合する可能性があることを示唆しています、おそらく共通のデータプラットフォームを使用して。

一つの懸念は規模におけるコスト効率です。ToolsGroupの新しいソリューションが、たとえば、すべてのデータをSnowflakeデータウェアハウスにフィードするか、メモリを多く消費するシステムに大きく依存している場合、コストが上がる可能性があります。ToolsGroupは明示的にSnowflakeに言及していませんが、競合他社の中にはそうしたり、クライアントがそれを使用するかもしれません。“.io”の命名規則と“デジタルサプライチェーンツイン”についての話は、すべてのサプライチェーンデータをミラーリングするクラウドデータベースを示唆しています⁶⁰。ToolsGroupのアプローチが効率的であるか、大きなクラウド請求につながるかどうかを監視する必要があります。ToolsGroupの中堅市場に焦点を当てると、彼らはおそらくコスト効率を保つよう努めているでしょう（彼らは自動化が緊急発送コストなどを削減し、ソフトウェアコストを相殺すると主張してきました）。

競合情報とマルチチャネル。 Evoの組み込みにより、競合他社の価格が明確になりました：Evoエンジンは明示的に競合他社の価格を価格決定のための入力として使用します⁷⁰。したがって、ToolsGroupのクライアントは、たとえば、オンラインマーケットプレイスからスクレイピングした競合他社の部品価格を計画に取り入れることができます。これは、ToolsGroupだけでは以前扱っていなかったことです。組み合わせると、彼らはSyncronの価格モジュールと同様に競合価格の位置づけを行うことができます。ToolsGroupの強みは既にマルチチャネルの需要処理でした - 彼らの需要予測は異なるチャネルや地域からデータを取り込み、それらを個別にモデル化できます²⁶。たとえば、ToolsGroupは、需要分析が特定のチャネルの動向を処理し、短期的な調整のために需要センシングを可能にし、最近の売上の急増に反応する需要センシング製品を持っています⁵⁹。マルチチャネル販売（オンライン直販、卸売業者、小売店）は別々のストリームとして入力され、ToolsGroupはすべてを考慮した単一の最適化された計画を作成できます。今ではEvoとともに、おそらくマルチチャネル価格設定もサポートされているでしょう - たとえば、eコマースと卸売B2Bチャネル用に異なる価格を推奨することができ、マージン戦略に合わせることができます。

自動化 vs ユーザー入力。 ToolsGroup はこれまでに多くの自動化を提供してきました：自動予測、自動在庫推奨。ユーザーはいくつかのパラメータを設定しました（グループごとのサービスターゲットなど）、しかし構成されると注文提案が出力されました。Evo 統合により、ビジョンは**「自律的な計画に近づくこと」です。ToolsGroup は、*「将来の自律的なサプライチェーンを提供する」と発表し、Evo の創設者はクライアントが目標を設定し「アプリがそれらを達成するための最適な在庫レベル、価格、オファーを表示する」*と述べました。これは、より成果主導型、ロボット化された意思決定者**への移行を示しています - ユーザーが目標を設定し（例：利益を最大化する、98% の充足条件を優先するなど）、システムの最適化モデルが残りを行い、計画を提示します。これはかなり高度であり、実践ではまだ一般的ではありません。これは志向的ですが、Evo の経験（彼らは歴史的にクライアントに 3 億ドル以上の利益をもたらしたと主張しています）を考えると、より狭い範囲ではありえるでしょう。現実的な近期の使用例は、例えば次のようなものです：ToolsGroup が補充計画を作成し、Evo が価格を提案し、プランナーが統一された UI を介して両方を監視し、変更を承認し、KPI を監視します。つまり、まだ人間がループ内にいますが、手動で操作するつまみが少なくなっています。

懐疑的な視点： ToolsGroup には注意すべき点がいくつかあります。まず、買収統合リスクです。質問が指摘したように、買収されたソフトウェアはしばしば本当に統合されるのに苦労します。ToolsGroup は現在、Evo のプラットフォーム（おそらく独自のデータモデルと UI を持っていたと思われる）を SO99+ とおそらく JustEnough の機能と統合する必要があります。これは挑戦的な課題となる可能性があります。暫定的には、解決策は少しパッチワークになるかもしれません（データがモジュール間を移動する代わりに統一されたアルゴリズムが使用される）。プレスリリースでは即時の利点が主張されていますが、現実的には完全な技術統合には時間がかかります。過去の例を思い出す必要があります：JDA が i2 を買収した際、合理化に数年かかり、成功はまちまちでした。ToolsGroup は規模が小さいですが、専門技術の買収は最初は不連続なユーザーエクスペリエンスや壊れやすいデータフローという同じリスクを伴います。彼らはこれを素早く再ブランド化し、おそらくシステム間の API 接続を使用して全てを書き換える代わりにします。それでも、ToolsGroup の新しい価格最適化の早期採用者は、共同システムを較正するためにいくつかのつまずきを予想するか、追加のコンサルティング支援が必要になるかもしれません。

二番目に、**「量子学習」のような言葉を使うことは疑問を呼び起こします - これは機械学習の標準用語ではありません。これは「非常に高速な学習アルゴリズム」と言うためのマーケティング手法であるか、量子コンピューティングを参照しているかもしれません（ただし、Evo は既知の範囲では文字通り量子コンピュータを使用していないかもしれません。比喩的かもしれません）。この専門用語は、ToolsGroup/Evo に具体的な説明を求める根拠があります。「量子」**をそのまま受け入れないでください - おそらくそれは彼らの AI エンジンのためのブランディングに過ぎません。良い面では、ToolsGroup は資料で具体的な例を提供しました：例えば、Evo の顧客（Event Network の CEO）からの引用（Evo の価格最適化が持続可能な革新とタイムリーな洞察を提供すると賞賛されています）。彼らはまた、Evo に関する実績やハーバードのケーススタディを引用しており、Evo のアプローチに第三者の信頼性を与えています。

三番目に、ToolsGroup の**「リアルタイム」と「反応性のある AI」**に関する主張は検証が必要です。サプライチェーンにおけるリアルタイム最適化はしばしばハイプです。価格変更や在庫の再バランスなどの意思決定は、実際には毎秒ではなく、おそらく毎日または毎週行われます。ToolsGroup がリアルタイムをマーケティングしている場合、新しいデータが到着するとすぐに再計算されることを意味するのか尋ねてみてください（これは良いことですが、連続的な瞬時の調整とは異なります）。また、ToolsGroup は 2024 年に Inventory.io を発表し、「AI によって在庫切れと値引きを減らす」と述べています。おそらく、シーズン中に在庫目標をより頻繁に調整することで、これは定期的な再最適化であり、毎分のライブ再計画ではないと思われます - これは問題ありませんが、非現実的な期待を持たないように明確にする必要があります。

最後に、パフォーマンスの主張: ToolsGroupはしばしば集計された改善（在庫の30-40％減など）を公表しています⁶²。最近の1つの記事では、彼らのインシーズン最適化が、より良い定価販売を通じて最大5.5パーセントの利益率をもたらすと述べています⁷⁵。このような主張については、文脈を要求すべきです（5.5ポイントはどのベースラインと比較していますか？それを達成したクライアントは何人ですか？）。多くの場合、これらは制御されたパイロットや単一のクライアントから来ています。良いことは、ToolsGroupが完全に信じられない数字を出さないことです。それらは良い最適化ができることに合致しているので、誇張されているわけではなく、ただし保証されているわけでもありません。

要約すると、ToolsGroupはアフターマーケットでの在庫最適化の強力な競合他社であり、価格最適化で新たに獲得した優位性を持っています。Evo以前は、ToolsGroupは他社と同様に、需要に応じて在庫を最適化していましたが、価格を通じてその需要に影響を与えることはありませんでした。しかし、EvoのAIにより、需要と収益に影響を与えることができるようになり、ループを閉じることができます。統合をうまく実行すれば、これによりToolsGroupは単なる計画ツールからより自律的な利益最適化システムへと昇格する可能性があります。しかし、より多くの証拠を見るまで、少し慎重であるべきです。ToolsGroupのデモが価格と在庫の推奨事項の実際の調整を示していることを確認してください（単なる2つの別々の出力ではなく）。また、コストを評価してください。ToolsGroupの新機能（Price.ioなど）はサブスクリプションに追加されます。これをSyncronのような価格設定をバンドルした代替手段と比較したり、専用の価格設定ツールと在庫ツールを使用したりすることができます。ToolsGroupの利点は、すべてが今や一つ屋根の下にあることです。つまり、Zilliant（価格設定）とToolsGroup（在庫）の間に独自のインターフェースを構築する必要がないためです。ToolsGroupの堅実な系譜とこれらの強化機能を考慮すると、それは共同最適化のトップベンダーの中でその場を確保していると言えますが、それは「在庫優先」から「包括的最適化」への移行の途中であり、それは真剣な投資とAIによるサプライチェーンの将来に向けた展望を持って取り組んでいるように見えます⁶⁹。

5. o9 Solutions – The Digital Brain: Integrated Planning with Pricing Capabilities (Emerging in Aftermarket)

o9 Solutionsは新しい参入者です（2009年に設立されましたが、2010年代後半に脚光を浴びました）。AIを活用した統合ビジネスプランニングプラットフォームを提供しています。o9のプラットフォームは「デジタルブレイン」としてブランド化されており、需要予測、供給計画、収益管理などを統一モデルで結集させることを目指しています。o9はさまざまな産業（小売業、製造業、消費財業界）で注目を集めており、従来の計画スイートやERP計画モジュールと競合するとされることもあります。自動車アフターマーケットにおいて、o9は専門家というわけではありませんが、柔軟なプラットフォームをサービス部品の流通と価格設定に構成できます。特筆すべきは、o9が解決策の範囲として価格、収益、市場計画を含んでいることです。在庫と価格の最適化に対するその能力と関連性を検討してみましょう：

高度な分析を備えた統合計画。 o9の特徴は、需要、供給、財務データが共存する単一の統合データモデルです。たとえば、彼らのシステムは、需要の変化（おそらく価格変更やプロモーションによって引き起こされる可能性がある）が生産や在庫にどのように影響するか、さらに供給の中断が価格や割り当ての変更を必要とするかを同時にシミュレートできます。彼らは多階層在庫最適化をモジュールとしてサポートしており⁷⁶、したがって、階層間の安全在庫を最適化するような中核的な在庫計画の数学を行うことができます。同時に、o9には価格設定と収益管理モジュールがあり、マーケティング資料では価格設定のための弾力性モデリングやシナリオ計画を強調しています。o9の1ページには次のように記載されています:「o9の需要計画の統合、弾力性モデル、外部要因のヒューリスティックスコアカードは、価格変更の最適な時期とクラスターを特定するのに役立ちます。o9デジタルブレインは、価格が変更されたときに、ポートフォリオ全体と市場全体でのボリュームと収益の変化をダイナミックにモデル化し、価格変更に伴うホリスティックな…」⁹（このスニペットは切り捨てられていますが、価格変更のホリスティックな影響分析を明確に示しています）。これはまさに共同最適化に必要な能力です：価格を調整すると、即座に予測される在庫と収益の結果が表示されます。

需要予測と断続的需要 – o9は予測のために現代の機械学習を使用し、多くのシグナル（経済指標、プロモーションなど）を組み込むことができます。ただし、LokadやToolsGroupのように断続的なサービス部品の需要に特有のアプローチを明確に打ち出していません。自動車アフターマーケットの需要では、Croston法やスパースデータ用にトレーニングされたニューラルネットワークを使用する必要があるかもしれません – おそらくo9はそれに対応できるでしょうが、それが彼らのセリングポイントではありません。彼らは、データが豊富な消費財や自動車OEM生産の予測改善についてより頻繁に自慢しています。アフターマーケットのクライアントがo9を使用した場合、利用可能なデータの年数に関係なく、おそらくそのMLに依存し、関連するアイテムを接続するために知識グラフ機能を使用する可能性があります。実際、o9のプラットフォームは、製品、部品などの知識グラフを作成でき、部品の後継品や互換性をモデル化するために活用できるかもしれません（部品の互換性行列に類似した概念ですが、明示的にその目的のためにパッケージ化されていません）。

部品の互換性とデータ統合。 o9は汎用プラットフォームであるため、自動車部品の互換性データベースは付属していません。ユーザーは（部品と車両、代替部品の相互参照などの）データベースをロードできます。o9のデータモデルを使用すると、部品を属性（車両モデル適用性など）にリンクさせることができます。これにより、「運用中の車両ごとの需要」といったカスタム予測指標を構築することが可能になります。o9の機能に含まれていますが、実装者が行う必要があります – 一方、Lokadや他の企業は事前に用意されているかもしれません。ただし、o9は地域ごとのサービス中の車両数などの需要ドライバーデータを取り込むかもしれません。その後、そのドライバーと部品需要を相関させるためにMLを使用します。o9は外部要因の統合に焦点を当てているため、これは可能です。o9は互換性データを処理できると言えますが、設定されていない限り、自動車アフターマーケットの微妙なニュアンスを「理解する」ための特別なモジュールはありません。

価格設定と競合情報。 o9の収益管理モジュールは比較的強力です。o9がサプライチェーンだけでなく商業的な意思決定を最適化することを目指していたことは重要な差別化要因でした。B2B価格設定（これはアフターマーケットで重要です。ディストリビューターや大口顧客に販売する場合）、o9は取引計画のために*「詳細な顧客分析と完全なサプライチェーンデータ統合」*を提供します。これは、大口契約の交渉や割引設定時に、サプライチェーンコストなどを考慮して利益を示すことができることを意味します。これはより多くの営業運用の視点ですが、価格最適化にも関連しています。カタログを定期的に更新するような動的価格設定（例：価格弾力性に基づく最適化）に対して、o9はサポートしています。価格最適化を高めるために、*主要な顧客インサイト（購買履歴、価格弾力性、インセンティブの影響）*を組み込むことを言及しています。競合他社の価格統合はおそらく手動のデータ入力シナリオです：o9は競合他社の価格を取り込み、それらを外部要因（制約としての競合他社よりもX以上の価格設定など、または価格弾力性に影響を与える要因）として扱うことができます。彼らは確かに価格決定をガイドするために外部要因のスコアカード（競合他社の動き、市場指標などを含む可能性があります）を有効にしています。

o9のシナリオ計画の強みの1つは有望です。ユーザーはプラットフォームで「これらの部品の価格を5%引き上げた場合どうなるか？サプライヤーのリードタイムが倍になった場合どうなるか？」などのシナリオを作成し、システムが需要供給ネットワークを通じて影響をシミュレートします。Blue Yonderもシナリオ計画を行っていますが、o9のインターフェースは、シナリオの作成と比較がユーザーフレンドリーであり、財務的な成果が得られることで知られています。たとえば、企業は在庫を20%削減するシナリオをシミュレートし、サービスへの影響と収益損失を見て、その後需要を高めるために価格を下げるシナリオをシミュレートし、それが補償されるかどうかを見ることができます。このような統合されたシナリオは、o9が概念的に優れているところです。

拡張性とコスト。 o9はクラウドベースであり、大規模な企業データを処理するように設計されています。一部の報告によると、o9はリソースを多く必要とすることがあります - これはしばしばサプライチェーンの内部に「デジタルツイン」を作成し、大規模な計算を実行することを含みます。 o9の実装がデータが増えるとパフォーマンスの期待に応えるために最適化が必要となることがあるというエピソードもあります。しかし、o9はFortune 500企業（例：Lenovo、Estée Lauder）によって大規模な計画に使用されてきました。たとえば、自動車アフターマーケットが50万個の部品と複数階層の流通を持つ場合、o9はそれをモデル化できるはずですが、頑強なクラウドインフラが必要かもしれません。コストに関しては、o9は通常、ハイエンドのクライアントをターゲットにしているため、その価格は大手ベンダーと同等です。ビジネスにモデルを構成するためにかなりのサブスクリプション料金やサービス料金がかかるかもしれません。企業が複数のレガシーツール（需要計画、在庫、価格設定、S&OP）を廃止し、すべてをo9で置き換えることができれば、統合された価値が費用を正当化する可能性があります。ただし、o9の一部のみを使用する場合（在庫と価格のみ）、その全体的なIBP機能を使用しない場合、専門のツールの方がコスト効果が高いかもしれません。

自動化とユーザー調整。 o9は、すべてのAIの話にもかかわらず、通常はガイド付き計画システムです。ユーザー（プランナー、需要マネージャー、価格アナリスト）は定期的にシステムとやり取りし、デジタル脳が生成するダッシュボードやアラートを見ます。o9は特定の決定を自動化することができます - たとえば、購買注文の提案を自動的にリリースしたり、価格変更を提案したりすることができますが、一般的にはユーザーがレビューまたは承認することを期待しています。それはただ実行するブラックボックスではなく、より知的なアシスタントです。彼らはリアルタイムの可視性と例外管理を強調しています：システムはKPIを監視し、何かが予測を大幅に上回る場合（たとえば需要が大幅に上回る場合）、それをフラグし、適切な場合は行動を提案します（供給を迅速化したり、適切な場合は価格を引き上げたり）。これは半自動化のアプローチです。完全に手を離しての操作を防ぎ、人間の監視を確保します。一部は、このユーザー主導のシナリオと調整への依存は、伝統的な計画の継続（ただし、より優れたツールを使用）であり、革命的な自律システムではないと主張するかもしれません。o9の「AI」の多くが裏方で行われているという批判は妥当であり、フロントエンドには依然として熟練したプランナーが必要です。

懐疑的な分析: o9はしばしばバズワードを多用します - 彼らのマーケティングは「AIパワード」、「リアルタイム」、「デジタルツイン」、「スケールでの機械学習」などの用語が好きです。彼らは時々公に具体性を欠いていることがあり、おそらくその秘密のソースは柔軟なデータモデルの一部と、埋め込まれたアルゴリズムのいずれか（他のものと根本的に異なるわけではなく、単により統合されているかもしれません）です。バズワードに対する質問の慎重さは間違いなく適用されます：たとえば、o9の「需要センシング」や「リアルタイム最適化」へのアプローチは具体的には何か？明確な回答がない場合、確立された技術と輝かしいインターフェースの組み合わせと仮定してください。もう1つの注目すべき点はドメインの専門知識です - o9のプラットフォームは何にでも構成できますが、これは自動車アフターマーケットの場合、顧客やコンサルタントが知識を入力する必要があることを意味します（どの部品が交換可能か、どのようにスーパーセッションをモデル化するか、サービスレベルのポリシーは何であるかなど）。SyncronやPTCのようなベンダーは、ある程度はドメイン知識を組み込んでいます（テンプレート、事前に調整されたパラメータから）。o9では、白紙または一般的なテンプレートから始めることができます。これは、アフターマーケットの計画に経験がない場合、より長い実装期間やリスクにつながる可能性があります。基本的に、o9は強力ですが、事前に調整されていません。

o9の創業者や多くのチームメンバーは、古いサプライチェーン企業（特にi2 Technologies）出身であることに注意すべきです。彼らは何がうまくいかなかったかを見てきました - 例えば、i2の過度に複雑で分断されたソリューション - そしてより統一された、ユーザーフレンドリーなシステムを作ろうとしました。その意味では、o9はレガシー統合の問題のいくつかを避けることができたかもしれません。それは新しく構築されているので、古いコードの統合の悪夢はありません。ただし、すべてを行うことで海を沸かそうとしているとも言えます（サプライ、需要、財務など）。場合によっては、特定の分野に重点を置くことがより良い結果をもたらすことがあります（たとえば、Lokadが確率的需要やカスタム最適化に重点を置くことで、o9のより一般的なMLよりも遅い動きの予測精度が優れているかもしれません）。

競争力のある価格設定に関して、o9はおそらくSyncronの10年間の専門アルゴリズムの深さを持っていないが、多くの戦略を複製することができます。ユーザーにどのような戦略を伝えるか（たとえば、競合他社よりも5％高い目標など）により頼るかもしれませんが、SyncronやRevionicsは組み込みのルールや価格テストからの自動学習さえ持っています。

結論として、o9 Solutionsは統合された計画のための強力なプラットフォームであり、すべての関連要因を1つの場所に持っていることで共同最適化と概念的に一致しています。在庫、価格設定、およびアソートメントを一緒に最適化することが可能ですが、効果は特定のアフターマーケットビジネスに適切に構成されているかどうかに依存します。需要予測からエグゼクティブS&OPまでのすべてを1つのシステムで望む組織にとって、o9は魅力的な選択肢です。ただし、約束されたAIが実際により良い意思決定をもたらし、コスト/複雑さが膨らまないようにするためには注意が必要です。 o9を検討する場合、実際の断続的需要データや競合価格データを使用して調整された在庫と価格設定計画を作成し、その結果が別々の専門ツールが行うことを上回るかどうかを確認するパイロットを要求すべきです。また、ユーザーエクスペリエンスも考慮してください：あなたのプランナーは基本的にシナリオをプログラムし、o9のAIの推奨事項を信頼することに快適ですか？それとも、より決定論的な制御を好むのですか？

o9がこの特定のドメインで比較的新しいことを考慮すると、アフターマーケットの参照が少ないため、少しランクが下がるかもしれません。Gartner Peer Insightsや他の比較では、o9はサプライチェーンではToolsGroupやBlue Yonder、収益のための価格設定ツールと頻繁に競合しており、それは何でも屋ですが、それらの取引のマスターであることを確認する必要があります。

6. Blue Yonder – モジュラーソリューションを持つレガシーリーダー（在庫最適化+小売価格設定、ただし統合が限られている）

Blue Yonder（旧JDA Software）は、サプライチェーンと小売計画の長年の巨人です。需要予測、供給計画、在庫最適化、商品陳列、価格設定ソリューションをカバーするLuminateと呼ばれる幅広いスイートを提供しています。 Blue Yonderの自動車アフターマーケットへの関連性は、主にその在庫最適化の系譜（OEMが使用する強力なサービス部品計画ソリューションを持つi2 Technologiesの2009年の買収に由来）および価格最適化ソリューション（2020年にRevionicsから取得した、より小売に焦点を当てたもの）から来ています。 Blue Yonderは在庫と価格の両方のコンポーネントを持っていると言えるかもしれませんが、重要な問題はそれらが本当に共同最適化のために一緒に動作するかどうかです。 Blue Yonderは分断されたモジュールを持っている傾向があり、データを介して統合することができますが、元々1つとして設計されていませんでした。これに加えて、いくつかのレガシーテクノロジーの課題と過度に宣伝されたメッセージングが組み合わさり、Blue Yonderはこの特定の評価においてより焦点を当てたソリューションよりもやや後れていると見なされます。

在庫最適化機能。 Blue Yonder Luminate Planning には、かつてi2のサービスパーツ管理だったものが含まれています。これは、マルチエシュロンネットワーク、断続的需要予測、複雑な供給制約を処理できる成熟した、機能豊富なIO（在庫最適化）ツールです。たとえば、Mercedes-Benz USA は、Blue Yonderのツールを使用して、400のディーラー全体で10万以上のサービスパーツを管理し、業界をリードするサービスレベルを達成しながら収益性を維持しました ^{77 78}。これは、Blue Yonderが高いフィル率を達成し（MBUSAは1つの議論で98％のサービスを引用 ⁷⁹）、在庫投資をバランスよく行ったことを示しています。おそらく、Blue Yonderのソリューションは、各エシュロンで安全在庫を計算し、シナリオ計画を使用してネットワークをストレステストしていました。最近の自動車ロジスティクス会議では、Blue Yonderの自動車戦略家が、サービスパーツ供給チェーン向けの「5つの主要な促進要因」を概説し、エンドツーエンドの可視性、混乱のためのシナリオ計画、サービスレベルと収益性の調整などを強調しました ^{80 81}。引用の1つ：「レジリエンスは在庫をたくさん持つことだけではありません…それは同時にリーンで収益性が高く、レジリエントであることです。インフレ率が高い中、高いサービスレベルを望みますが、それを低い運転資本で実現できますか？」 ⁶⁴。これは、Blue Yonderの在庫アプローチを要約したものです：在庫とコストを削減しながらサービスを維持するために最適化を使用する - 基本的には、どの良いIOツールも行うことです。

Blue Yonderは、S&OP/IBP レイヤーも提供して、財務成果を評価します。彼らは、「財務および戦略的ガイドライン」を計画プロセスに組み込むことを言及しています ⁸²、これは、彼らの計画システムが、単なるフィル率ではなく、ビジネスメトリクスに最適化できることを示唆しています。実際、Blue Yonderのマルチエシュロン在庫最適化ツールは、特定のサービスレベルのために総コストを最小化するか、予算の範囲でサービスを最大化するように構成できます - 経済最適化の形態です。ただし、従来、JDA/i2の最適化プログラムには動的価格決定が含まれていませんでした。需要曲線が入力であると仮定され、意思決定変数ではありませんでした。

Blue Yonderの需要予測は、現在AIによって補完されています（ドイツのAI企業「Blue Yonder」を買収した後に会社名を変更したため）。彼らは機械学習を使用した Luminate Demand Edge を持っています。おそらく、時系列メソッドとMLの組み合わせを使用して断続的需要を処理しています。サービスパーツについて具体的な情報はありませんが、MBUSAチームによると、Blue Yonderを通じてより正確な予測精度を達成したということから、適切に機能しているようです ^{83 84}。MBUSAのケースでは、**何度も（週に数回）**変更をテストするために素早くシナリオを実行できる能力が称賛されました ^{81 85} - これは、過去のツールでは1か月かかることがあったものです。この機動性は、不安定な時期（COVIDの混乱など）に重要です。MBUSAは、Blue Yonderで迅速に再計画することで対処しました ⁸⁶。

価格最適化（Revionics）機能。 Revionics（現在は「Blue Yonder Pricing」）は、主要な小売価格最適化SaaSです。価格弾力性モデリング、プロモーション分析、競合価格への反応などに優れています - 主に短いライフサイクルの小売製品（食料品、一般商品）向けです。アフターマーケットの文脈では、Revionicsは小売チャネルの部品価格に適用できます（たとえば、企業が部品をオンラインで直接消費者に販売する場合、競合他社のオンライン価格、需要弾力性などを考慮して価格を最適化するために使用できます）。Revionicsは需要が価格とどのように変化するかをモデル化するためにAIを使用し、価格設定ルール（たとえば、.99で終わるなど）を適用できます。また、競合他社の価格をスクレイピングして取り込むこともできます - 比較ショッピングが簡単な自動車部品の電子商取引では必須です。

ただし、RevionicsはB2Bサービス部品価格向けに構築されていません。それは、主に高ボリュームの小売シナリオに適合しています。自動車アフターマーケットにはそのような側面があります（たとえば、オンライン部品販売業者は非常に小売シナリオです）、しかし、弾力性を測定するのが難しい低ボリューム部品の長尾もあります。Revionicsは通常、弾力性を測定するために合理的な販売量が必要です。非常に遅い部品の場合、ルールベースのアプローチに戻ることがあります。Blue Yonderは、Revionicsを特にサービス部品ドメインにまだ適応していないかもしれません（しかし、できるかもしれません）。

統合のギャップ。 問題の核心は、Blue Yonderの在庫計画とRevionicsの価格設定がLuminateプラットフォーム上の別々の製品であることです。現時点では、統合された最適化ループを共有しているようには見えません。ユーザーは、例えば、Revionicsを使用して価格を決定し、それらの価格計画をLuminate Planningの需要予測にフィードして在庫が新しい価格に対応するように計画することができます。しかし、これは手動または半手動の統合であり、自動化された共同最適化ではありません。 Blue Yonderのロードマップには、より密接な統合が含まれるかもしれません（彼らはエンドツーエンドの統一された商取引について話しています）、しかし懐疑的には、これにはかなりの努力が必要になるでしょう。我々は以前の買収がどのように進展したかを見てきました：JDAがi2を買収したとき、業界の専門家は*「i2は幅広い複雑なソリューションを持っており…ソフトウェア会社としてi2を管理するのが難しい」*と述べました¹⁰。 JDA/Blue Yonderは最終的にいくつかのi2アルゴリズムを統合しましたが、数年かかり、一部のi2モジュールは廃止されました。同様に、Revionicsは独自のクラウドサービスです。リアルタイムでその出力を計画に統合することは容易ではないかもしれません。

拡張性とアーキテクチャ。 Blue Yonderは、クラウド（主にAzure）で実行するためにスタックの多くを近代化しました。彼らはまた、いくつかのケースでデータと分析にSnowflakeを活用し始めました（Luminateデータ共有のためのパートナーシップを発表しました）。これは、クライアントがBlue Yonderを使用する場合、計画と実行システムからデータを統合するためにSnowflakeを使用するかもしれないことを意味します- これには追加コストがかかります。ただし、Blue Yonder自体のアプリケーションは、通常、Azure SQLまたは類似のものを裏で使用しており、必ずしもSnowflakeを使用しているわけではありません。コスト的には、Blue Yonderは通常、企業レベルの価格設定です。需要、供給、在庫、価格をすべて別々に必要とする場合、ユーザーごとまたはモジュールごとに料金を請求することもあります。

アーキテクチャ上の懸念：Blue Yonderの遺産ソリューション（i2サービスパーツなど）は、メモリと計算に重点を置いていました（大規模な最適化問題の解決）。最適化されていない場合、それらをクラウドホスティングすることはコストがかかる可能性があります。ただし、Blue YonderはおそらくAzureでこれらを最適化し、スケーリングしています。MBUSAの場合、Blue YonderのSaaSを使用することで、シナリオをより速く実行できると明言しています⁸¹、適切なクラウドパフォーマンスを意味しています。

競合情報とチャネルの取り扱い。 Revionicsは競合価格情報に非常に強く、競合他社の価格を取り込むように設計されていました（特にAmazonなどに直面するオンライン小売業者向け）。そのため、Blue Yonderは価格側では競合他社の価格データを確実に組み込むことができます。在庫側では、競合情報は直接的には考慮されません（他の企業と同様に- 競合他社がたくさん持っているからといって在庫を減らすことは通常ありません、奇妙な方法で調整していない限り）。しかし、価格に関しては、はい：Blue Yonderのツールは、設定されたガードレール内で競合他社の価格変更に自動的に対応することができます。これは信頼できるものです。Revionicsはその点で小売業界で多くの参照がありました。マルチチャネル：Blue Yonderの商取引スイートはすべてオムニチャネルに関するものです- どのチャネルからでも最適に注文を処理します。ただし、彼らの計画は通常、ビジネスユニットごとにセグメント化されています（OEMサービスと小売販売のために別々の予測を行うかもしれません）。必要に応じて、IBPでそれらを統合することができます。ソフトウェアは、ディーラーの需要とeコマースの需要の両方を取り込むことができますが、おそらく2つの需要ストリームとして処理されるでしょう。

自動化とユーザー制御。 Blue Yonderは歴史的に多くの設定可能性を提供してきました。MBUSAの事例では、彼らは時折プランナーの「部族の知識」を使用していることが示されました（COVID時のオーバーライド）⁸⁷。Blue Yonderは「自律型プランニング」のビジョンを強調していますが、現時点では、計画が実行され、システムが定期的に再計画され、ユーザーが監視するクローズドループプロセスについてです。彼らは問題を自動的に検出し、アクションをトリガーできるコントロールタワー機能を持っていますが、完全にロボット化されたサプライチェーンは理想論です。Blue YonderのSalim Shaikhは、「入力があり、何かが起こったときに感知し、反応してフィードバックし…繰り返す」というクローズドループシステムを説明しました⁸⁸。基本的には、自動化へのアプローチです：継続的に再計画（おそらく週に複数回）して調整します。反復的な再計算で自動化されていますが、人間が初期パラメーターを設定し、微調整できます。

懐疑的な点： Blue Yonderは多くのバズワードを使用する傾向があります - *「自律型サプライチェーン、認知、リアルタイム、ML駆動」*など。これらの背後にはしばしば実質があります（彼らはMLを使用しています。自動化もあります）、しかし、マーケティングは実際の統合よりも先行していることがあります。たとえば、彼らのソリューションを「エンドツーエンド」と呼ぶこと - 実際には、エンドツーエンドとは、すべてのモジュールを持っているかもしれませんが、それらのモジュールが暗示されているほどシームレスに接続されていないかもしれません。i2買収の失敗は、JDAが2010年にi2で「最も包括的な統合サプライチェーンオファリング」を約束したことを思い出させます⁸⁹。しかし、何年もの間、顧客は古いi2に留まるか、新しいバージョンで苦労していました。その遺産の一部は、Luminateを依然としてi2のロジックを効果的に参照しているMBUSAがいるかもしれません。さらに、Blue Yonderのパフォーマンスの主張は検証される必要があります。彼らが「X％の在庫削減とY％のサービス向上」と言う場合、それが平均値なのか、チェリーピックされたケースなのか尋ねてください。彼らは印象的な事例研究を持っています（DHLのネットワーク設計での7％の輸送コスト削減、ルノーの中央集中計画など）、しかし、それらにはしばしば注意点があります。

レガシーテクノロジーの問題 - Blue Yonderの在庫最適化（i2から）は強力でしたが、微調整が必要であり、時々複雑であるという評判がありました。完全に書き直されていない場合、それは依然として専門家コンサルティングを必要とするブラックボックスである可能性があります。また、Revionicsが別々であることは、構成するために別々のスキルセットが必要になるかもしれません（在庫計画のための1つのチーム、価格設定のための別のチーム）。これは、会社が積極的にそれらを橋渡ししない限り、組織のシロを意味する可能性があります。

アソートメント最適化 - Blue Yonderは小売側からのカテゴリー管理ツールを持っており、アソートメント（どの商品をどの場所で販売するかを決定する）を処理できる可能性があります。アフターマーケットでは、アソートメント最適化は、在庫に保持する部品を決定することを意味するかもしれません（特にスロームーバーの場合）。Blue Yonderのツールは、需要パターンと収益性を分析することでそれを理論的に行うことができます。しかし、これも自動化されているとは限らないかもしれません - プランナーはおそらくしきい値を設定します（たとえば、部品が3年間需要がなく、車両の台数が少ない場合、廃止のためにマークします）。Syncronなどの競合ソリューションには同様のロジックがあります。Blue Yonderが他の企業が行う以上にアソートメントを最適化している証拠はありません（おそらく焦点が少ないため、通常、カタログが与えられ、必要に応じて在庫を補充しようとします）。

総括すると、Blue Yonderは多くの要素を持ち込んでいます：トップティアの在庫最適化、堅実な需要計画、そして先進的な価格設定ソリューションです。ただし、これらの要素は現在、単に組み合わされているように感じられ、統合されているわけではありません。企業は確かにBlue Yonderを使用して共同最適化を行うことができますが、それには2つのシステムを並行して実行し、洞察を統合する必要があります。ベンダーはまだ、アフターマーケット向けに「価格と在庫を一緒に最適化する」ための一括提供ソリューションを提供していません。過去にいくつかの顕著な失敗した実装があったことを考慮すると（2000年代に一部の顧客がi2またはJDAに失望してシステムを切り替えた）、注意が必要です。Blue Yonderは、特に既存のモジュールのいずれかをすでに使用しており、拡張したい場合には強力な選択肢ですが、曖昧な約束を慎重に検討する必要があります。たとえば、「AI駆動の需要センシング」といった用語は、具体的にどのように役立つのかについての説明が付いているべきです（特定の部品の急増を検出してアラートを出すのか？そしてその後はどうなるのか – 自動的に価格や注文を調整するのか？）。これらの質問が具体的に回答されれば、Blue Yonderは安全な選択肢となるかもしれませんが、重い選択肢となるかもしれません。そうでない場合は、この特定の共同最適化ニーズに対するより専門化されたまたは現代的なソリューションに傾くかもしれません。

---

結論

自動車アフターマーケットのような厳しい市場では、断続的な需要、膨大なSKU数、およびサービス、コスト、利益のバランスを取る必要があるため、在庫、価格、およびアソートメントの共同最適化を本当に提供できるベンダーを見極めることが重要です。

この分析から：

• Lokadは、アフターマーケットの複雑さ（互換性グラフ、すべての意思決定の完全数値最適化）に直接取り組む新しい確率論的および経済的アプローチを提供し、革新のリーダーとして浮かび上がります^{1 2}。ユーザーの推測に頼ることを最小限に抑え、自動化された、証拠に基づく意思決定に焦点を当てていますが、データに精通した関与が必要です。

• Syncronは、価格と在庫のドメイン固有の統合で際立っています。信頼性のある、実戦済みの機能を提供し、実質的には部品計画のすべての細部を処理する一括アフターマーケット最適化プラットフォームを提供しています。その主張は一般的に具体的な機能で裏付けられていますが、ユーザーは戦略の設定を適切に実行する必要があります。

• PTC Servigisticsは、類稀なる深さと長い実績を提供しています。在庫最適化において信頼性があり、価格設定においても能力を持っていますが、その幅広い活用は実装者にかかっています。それは重く複雑であり、熟練したジョッキーが必要な純血種です。多くのOEM企業にとって優れた結果を達成できますが（そして実際に達成してきました⁵⁴）、古い慣行やインターフェースの摩擦に注意する必要があります。

• ToolsGroupは、アフターマーケットの在庫最適化において歴史的には静かな働き者であり、現在はEvoとともに共同最適化空間に積極的に進出しています。これは注目すべき点です：彼らの実績のある在庫エンジンとEvoの価格AIの組み合わせは、非常に強力でスマートかつユーザーフレンドリーなソリューションを生み出す可能性があります（彼らの新しいUI中心の“.io”製品が示唆しているように）。ただし、現時点では統合リスクと規模での未検証の組み合わせ使用があります – マーケティングの約束に賭ける前に慎重で、パイロットプロジェクトが賢明です⁸。ただし、そのビジョンが具現化すれば、潜在的なメリットは大きいです。

• o9 Solutionsは、統合された哲学と現代的な技術を提供し、統一された計画環境を求める人々に魅力的です。理論上は必要なことを確実に行うことができますが、特定のアフターマーケットに焦点を当てておらず、構成に依存しているため、プロジェクトチームが実装する限りにおいてのみ有効です。強力な分析チームを持つ企業は、o9を活用してカスタマイズされたスーパーソリューションを作成するかもしれません。他の企業は、柔軟性と即戦力の間でトレードオフを行い、より事前に準備されたものを選択するかもしれません。

• Blue Yonderは、サプライチェーンと価格設定の個別のトッププロバイダーであり続けていますが、アフターマーケットでの共同最適化においては現在遅れています。要素は揃っていますが、統一性がありません。Blue Yonderだけで在庫をX％削減し、充填率をY％引き上げるかつ同時にマージンを向上させるという主張には慎重であるべきです - 彼らが在庫計画とRevionics価格設定が実際に協調している場合を示すまで。彼ら自身の顧客ストーリーは、サプライチェーンの改善⁸⁴または価格設定の改善に焦点を当てており、両方を一緒に扱っているものはありません。Blue Yonderが価格設定と在庫を1つのエンジン（または少なくともシームレスなプロセス）に緊密に組み込むまで（または少なくともシームレスなプロセス）に緊密に組み込むまで、ユーザーは統合の多くを自分で考えなければなりません。

全体的に、共同最適化はもはや理論的な理想ではなく実践的な必要性であるという明確なトレンドがあります。1つのドメイン（在庫だけまたは価格だけ）で成長したベンダーは、開発または買収を通じて隣接するドメインに拡張しています。この収束は、お互いの競争力を高めるために、すべての人にゲームを上げることができるので、顧客にとって素晴らしいことです。ただし、それはまた、各ベンダーが「エンドツーエンドのAI最適化」を行うと主張することが増えることを意味します。買い手には透明性を要求する責任があります：特定のアフターマーケットシナリオ（たとえば、12か月間売上のない部品 - 在庫を削減しますか、価格を引き上げますか、または削除のためにフラグを立てますか？どのようなロジックに基づいて？または競合他社が在庫切れになったために部品の需要が急増した場合 - システムは競合他社の売上の減少（データが利用可能な場合）を通じて気づくでしょうか？価格設定または在庫を調整しますか？）。

買収によるポートフォリオの維持、文脈のない奇跡的なKPIの主張、バズワードが多いプレゼンテーションに対する健全な懐疑心を保ち、証拠に基づく具体的な機能に焦点を当てることで、企業は本当に自分たちのニーズに合ったベンダーを選択することができます。

要約すると、最高のベンダー（ここで最も高く評価されているベンダーのような）は、信頼性のあるソースを使用して次のことを実証しました：確率的予測を使用して変動を抑制する¹³、部品の互換性知識を計画に組み込む¹、最適化に経済的根拠（利益とコストのトレードオフ）を適用する²、狂気じみたコストなしで大規模なデータにスケーリングする、競合他社や市場データをアルゴリズムに取り込む³²、すべての販売チャネルを一貫してカバーし、専門家によるオーバーライドのオプションを備えた高度な自動化を可能にします。これらのポイントで説得力を持たなかったベンダーは、ランクが下がりました。

最後に、技術以外にも、ベンダーのアフターマーケットでの実績を考慮してください。実装ノウハウ、特定のデータのクセを処理する能力（たとえば、乱雑な相互参照テーブル、疎なデータ）、システムの調整をサポートするポスト実装サポートは、アルゴリズム自体よりも成功を作り出すか壊すかの要因となります。派手な「AI駆動」のデモは、ベンダーが30年間のサービス部品履歴をクレンジングする過程を支援できない場合はあまり意味がありません。逆に、やや派手さに欠ける技術を持ちながらもアフターマーケットに深い専門知識を持つベンダーは、より迅速かつ信頼性の高い価値を提供するかもしれません。最適な選択肢は、組織のサイズ、複雑さ、変化への準備状況によって異なりますが、上記の重要な洞察を持っていれば、ノイズを切り抜いて、よく根拠のある決定を下すことができます。

**要点：**自動車アフターマーケットにおける在庫、価格、およびアソートメントの最適化は、多面的な問題です - マーケティングの外観だけでなく、エンジニアリングの厳密さですべての側面に対処するソリューションを要求してください。各ベンダーには強みがありますが、完璧なものはありません。各機能に対する証拠を要求することで、選択したソリューションがスライド上でKPIを最適化するだけでなく、実際の倉庫や財務諸表でKPIを最適化することを保証します。

脚注