スペアパーツ最適化ソフトウェア、2025年2月

Last modified: February 2nd, 2025

ベンダーランキング＆サマリー

1. Lokad – 技術的に大胆で確率論に基づき、経済に基づく： Lokadは、需要とリードタイムの真に 確率論的な 予測と、経済最適化に焦点を当てたユニークなアプローチで際立っています。そのクラウドプラットフォームは、単一点の予測ではなく完全な需要分布をネイティブでモデル化し、在庫の財務的リターンを最大化することを重視しています ¹。Lokadのソリューションは高度に自動化されており、大規模なロングテールパーツカタログを最小限の手動調整で処理できるように構築されています。その深い技術的アプローチ（カスタムドメイン固有の言語、高度な確率モデリング）は、革新のリーダーでありながら、コード駆動型の方法論を受け入れる意欲が必要です。静的な安全在庫や単純化された「ABC」サービスクラスなどのレガシーの松葉杖を避け、代わりにエンドツーエンドの確率モデルとコストベースの最適化を使用しています。

2. ToolsGroup（Service Optimizer 99+） – マルチエシュロン強度を持つ実証済みの確率エンジン： ToolsGroupは、スペアパーツ計画における長い実績を持ち、確率論的予測 の基盤として認識されています ²。システムは需要の不確実性を自動的にモデル化し（スロームービングパーツにとって重要 ³）、モンテカルロスタイルのシミュレーションとAI/MLを使用して在庫レベルを最適化します。数万、数十万のSKUを動的にバランスさせ、可能な限り最低の在庫投資でサービスターゲットを達成 します ⁴。ToolsGroupは堅牢なマルチエシュロン最適化を提供し、技術を新鮮な状態に保ちながら（新しいAIエンジンの統合など）、統一されたプラットフォームを維持しています。自動化を重視しており、プランナーは例外を管理し、ソフトウェアが残りを最適化します。経済最適化： ToolsGroupは通常、ユーザーにサービスレベルを目標にすることを許可しますが、在庫とサービスの曲線を使用して、コスト効率の良い方法で行います。最近のIDCによるスペアパーツ/MRO計画の第1位のランキング ⁵ は、その強力な現在の能力を裏付けています。注意：ToolsGroupのマーケティングは今や「量子学習AI」などの流行語を掲げていますので、本物の改善点と再ブランディングを区別するためには懐疑的な目が必要です。全体として、基本的な数学（変動の確率モデルと最適な安全在庫）は確かであり、実戦を経ています ⁴。

3. PTC Servigistics – 包括的で洗練された（複雑な）リーダー: Servigistics（現在はPTCの傘下）は、サービス部品管理向けに特別に設計された重量級の製品です。この領域で最も幅広く、最も深い機能を誇っています ⁶。Servigisticsは、XelusやMCA Solutionsの高度なアルゴリズムを統合した数十年にわたる知的財産を内部に統合しています ⁷。その結果、非常に洗練された最適化エンジンが構築されており、低ボリュームの断続的需要予測や多階層在庫最適化（MEO）を含んでいます ⁸。Servigisticsは確率モデル（例：航空宇宙/防衛分野で一般的なポアソン分布に基づく需要分布）を活用し、PTCのThingWorxを介してIoT駆動の予測入力を組み込むことができ、部品の予測を装置のテレメトリと整合させることができます ⁹。Servigisticsは、プランナーが最高の可用性を最低の総コストで最適化することができる粒状の経済的トレードオフを可能にします。単なる一律の補充率を達成するだけでなく、最適化が可能です ⁸。このソリューションは、Boeing、Deere、米空軍などの200以上の顧客を含む大規模なスケールで実証されており、非常に大規模なカタログや複雑な多階層ネットワークを処理しています。機能が豊富であるにもかかわらず、自動化と例外管理に焦点を当てています。 注意点: 成熟した製品であるため、実装が複雑であり、その多くの機能を十分に活用するには専門知識が必要です。PTCは、取得した技術が成功裏に統合されたと主張しています ¹⁰が、システムの年齢と複雑さから、すべてのモジュールが実際にシームレスに動作することを確認するためには、デューデリジェンスが必要です。それでも、純粋な技術的メリットに基づいて、Servigisticsは、複雑さを乗り越えれば、高度なサービス部品最適化のためのトップティアの選択肢として残ります。

4. GAINSystems（GAINS） – コストに焦点を当てたエンドツーエンドのスコープを持つ最適化プログラム: GAINSは、サプライチェーンの継続的なコストと利益の最適化を強調する長年のプロバイダーです ¹¹。そのプラットフォームは、需要予測、在庫最適化、修理/ロータブル計画、さらには予防保守の整合性までカバーしており、グローバルなサービス部品業務に適しています ¹²。技術的には、GAINSは、需要とリードタイムの「変動を受け入れる」ために洗練された分析と確率モデリングを使用しています ¹³。それは、サービス目標を達成するか、コストを最小限に抑えるために在庫ポリシーを最適化することができます。GAINSは明示的にAI/ML駆動の自動化をマーケティングし、規模での意思決定の自動化を目指し、状況が変化するにつれて在庫を継続的に再バランスさせることができます ^{14 15}。それは多階層ネットワークをサポートし、多くの一般的なツールが無視する*修理可能部品（ロータブル）*計画を処理することで知られています ¹⁶。実際には、GAINSは、クライアントが最適な経済的バランスを見つけるのを支援し（例：ダウンタイムコストと保持コストを数量化することにより）、在庫を適切に調整します。競合他社ほど「確率的予測」を大声で叫ばないかもしれませんが、その結果志向のアプローチは、裏では高度な確率的最適化を取り入れていることを示しています。 懐疑的な見方: GAINSの「AI駆動の継続的最適化」という主張は、実際の証拠を検証する必要があります - おそらく、確立されたアルゴリズムといくつかの機械学習を微調整するために依存しているでしょう。それでも、業界の評価では、GAINSはROIと自動化に焦点を当てているため、スペアパーツ計画のリーダーの一人として位置付けられています。

5. バクスタープランニング – TCOに焦点を当てたサービス中心で、堅実ながらも伝統的なモデリング: バクスタープランニング（最近はその製品「Prophet by Baxter」を中心に再ブランド化）は、総所有コスト（TCO）アプローチを使用してアフターセールス部品計画に特化しています。このアプローチは、サービス志向のビジネスに共鳴するものであり、予測エンジンは断続的需要に適したさまざまな統計手法をサポートしています – Crostonベースの手法からブートストラップまで – そして設置基盤の故障率を取り入れて需要を予測することさえできます。これは、サービス部品にとって貴重な機能であり、バクスターの最適化は、最小限のコストでサービスレベル契約を遵守することに焦点を当てており、しばしばアップタイムが重要な前方在庫地（フィールドデポ）で在庫を最適化しています。顧客は、バクスターのアプローチが在庫の決定をビジネスの成果（SLAの遵守やコスト目標など）と調整していることを評価しています。[19]。システムは大規模なグローバルオペレーションを処理できます（ほとんどのバクスターの顧客は10億ドル以上の企業です[23]）、しかし多くは比較的「浅い」供給ネットワークを持っており、多段階最適化は必要ない限りバクスターの重点ではありません[24]。バクスターはまた、サービスとしての計画オプションを提供しており、多くの自動化が可能であることを示しています（バクスターのチームは、彼らのプラットフォームで計画を実行できます）。テクノロジーの深さ: バクスターのテクノロジーは堅牢ですが、やや伝統的です – 通常は在庫のための古典的な予測モデルやヒューリスティックに依存しているかもしれません。ただし、能力を強化してきました（例：2021年にEntercomsからAIビジネスユニットを取得して予測分析を強化）。懐疑的には、バクスターの「予測的」主張が標準的な予測を超えてどこまで行くかを検証する必要があります。それでも、コスト最適化と実世界のサービスメトリクスに重点を置いていることから、バクスターは関連性のある信頼できるベンダーの中にしっかりと位置しています。

6. シンクロン – 幅広いスイートを持つサービス部品の専門家ですが、最適化においては少し革新的ではありません: シンクロンは、製造業者向けのアフターマーケット（サービス）部品に特化したよく知られたプロバイダーです。そのクラウドプラットフォームには、在庫最適化（Syncron Inventory™）、価格最適化、ディーラー在庫管理、さらにはIoTに基づいた予測メンテナンス（Syncron Uptime™）のモジュールが含まれています。予測: シンクロンは、数百万の部品-場所の組み合わせ全体で需要を予測するために*「確率的AIモデル」を使用していると主張しています。実際には、アイテムを（需要パターン、価値などによって）セグメント化し、適切な断続的需要モデルや機械学習を各セグメントに適用する可能性が高いです。ただし、シンクロンは歴史的に価格とアップタイムのソリューションに重点を置いてきたため、予測科学の最先端を追求するよりも価格とアップタイムのソリューションに重点を置いてきた可能性があります。独立した分析では、シンクロンの戦略が価格最適化を先導し、予測/在庫管理が時には二次的な優先事項であることが指摘されています – これは、在庫アルゴリズムが競合他社よりも先端技術でない可能性があることを示唆しています。シンクロンの最適化アプローチは、予算や在庫の制約を考慮して高いサービスレベル（フィル率）を達成することを中心に回っています。それは確かに大規模なデータスケールと多段階ネットワークを処理できます（多くの自動車および産業用OEMが世界的に使用しています）。自動化は主要なセリングポイントです – シンクロンは、プランナーが例外管理に導かれ、ルーチンの意思決定を自動化することで手作業の努力を最小限に抑えることを宣伝しています。買収統合: シンクロンは、保証/フィールドサービス企業（Mize）を買収し、IoTの稼働時間製品を提供していますが、価格と在庫モジュールは依然として別々のデータベースで実行されていると報告されており、いくつかの統合のギャップを示唆しています。警告信号: シンクロンのマーケティングは「AI搭載」と「OEM向けに特別に設計された」といったキャッチフレーズを自由に使用しているため、購入者はその内容を検証する必要があります。それは本当に*確率的な予測を行っているのか、それとも統計的に駆動された安全在庫レベルを単に使用しているのか？経済的成果を最適化しているのか、単にルールベースのサービスレベルクラス（例：重要部品対非重要部品）を使用しているのか？これらは、シンクロンの評価で調査すべき領域です。要約すると、シンクロンは、現代のクラウドスイートを持つ強力な業界専門家ですが、厳密に技術的な視点から見ると、確率的最適化においてトップランクのベンダーほど先駆的ではないかもしれません。

7. Blue Yonder (JDA) – 適切な予備部品機能を備えた幅広いサプライチェーンスイート: Blue Yonderの計画プラットフォーム（旧JDA）は、サービス部品に適用できるエンドツーエンドのサプライチェーンソリューションですが、それだけに特化したものではありません¹⁷。需要予測（Luminateプラットフォーム内のMLベースのアルゴリズムを含む）および多階層在庫最適化をサポートしています。 Blue Yonderは、確率的リードタイム需要や小売り/製造計画に由来する多階層シミュレーターを使用して、例えば動きの遅いアイテムをモデル化できます。ただし、専門の予備部品ツールと比較すると、Blue Yonderは非常にまれな需要やアセットの故障率の統合などの処理にはより多くの構成が必要かもしれません。通常、サービスレベルと在庫回転を目標とし、他のツールのようにニュアンスのあるサービス部品機能（例：組み込みのロータブルトラッキングやIoT統合）を提供しないかもしれません。それでも、既にサプライチェーン計画のためにBlue Yonderに投資している大企業は、別のシステムを追加することを避けるために予備部品にも考慮するかもしれません。重要なのは、Blue Yonderの最近のAI/MLの強化（「Luminate」モジュール）が断続的な需要予測を具体的に改善するか、単に分析のレイヤーを追加するだけかを確認することです。要するに、Blue Yonderは、技術的に堅実でスケーラブルであり、現在はAIによって強化されていますが、上記の専門ベンダーほどサービス部品計画の特異性に焦点を当てていない能力があるが、専門化されていない予備部品最適化オプションです。

8. SAP & Oracle（ERPベースのソリューション） – 予備部品には不十分だった統合巨大企業: SAPとOracleの両社は、サービス部品計画向けの提供をしています（SAPのSPPモジュール、およびOracleのサプライチェーンスイートの一部であるSpares Management¹⁸）。理論的には、これらは大手ERPのデータを活用し、高度な機能を提供しています。しかし、実際には、多くの課題に直面しています。SAP: SAPサービス部品計画（SPP）は、APO/SCMスイートの一部であり、Servigisticsのロジックに類似した確率的多階層最適化を試みました。しかし、複数の有名な実装（例：Caterpillar、米海軍）が苦戦したり失敗したりしました - SAP SPPは非常に複雑であり、重いカスタマイズやサードパーティのアドオンなしでは稼働できないことがよくありました^{19 20}。実際、フォードのような企業は、「ほとんど価値がない」と考え、数年の努力の後にSPPを放棄することを検討しました²¹。主な批判点は、SAPのアプローチがまだ硬直した構造に依存しており、専門ツールによる補完なしには予備部品の現実をうまく処理していないことでした²²。Oracle: Oracleのサービス部品計画も、OracleのERPのアドオンです。サービス部品向けの基本的な予測、返品管理、在庫補充を提供しています²³。Oracleのソリューションは、主により単純なサービスサプライチェーンを持つ企業や複雑な航空宇宙/防衛シナリオではなく、アフターマーケットの小売部品販売に従事している企業によって使用されています²⁴。SAPもOracleも真の確率的予測で知られていません。通常、伝統的な時系列メソッド（例：正規分布またはポアソンの仮定に基づく単一点予測とセーフティストックの式）を使用しています。また、彼らはしばしばクラシックな最小/最大計画を通じてサービスレベル（フィルレートの目標）の達成を強調しています。判決: グローバルな予備部品の最適化に真剣に取り組む中～大規模企業にとって、ERPソリューションは*「何でも屋、何もの達人」*と証明されています。既存のスタックと統合できますが、その技術的な深さは遅れています。多くの企業は実際にSAP/Oracleの上にベストオブブリードツールを重ねて必要な最適化を行っています²⁵。したがって、SAPとOracleは市場での存在感によって「関連性がある」が、予備部品の最適化のための最先端で真実に基づいた結果を提供することで最も低い評価を受けています。

*(**Smart Software（SmartForecasts/IP&O）やInfor（EAM/Service Management）*などの他のニッチプレーヤーも存在しますが、より狭いセグメントに対応したり、より限られた革新を提供したりしています。彼らは既知の統計的手法（Croston法、ブートストラップ）に依存することが多く、グローバル企業にとっては目立たないため、このトップリストから省かれています。)

各ベンダーの深い技術的評価

このセクションでは、各ベンダーのソリューションを批判的な視点で掘り下げ、予備部品最適化の核心技術的課題にどのように対処しているかを検討します：

• 確率的予測（需要とリードタイムの不確実性）
• 在庫最適化アプローチ（経済対サービスレベル、シングル対マルチエシュロン）
• 自動化＆スケーラビリティ（ロングテール管理、例外処理、必要な人間の入力）
• 技術的深さ（本物のAI/ML技術、アルゴリズム、エンジニアリング）
• スパース/不規則な需要の取り扱い（断続性に対する特別な方法対古いヒューリスティック）
• 統合＆アーキテクチャ（複数の技術が取得された場合、ソリューションがどれだけ統一されているか）
• 警告信号（流行語や時代遅れの慣行の兆候）。

Lokad

• 確率的予測: Lokadは予備部品に対して本物の確率的予測を提供する数少ないベンダーの1つです。Lokadのシステムは、1つの需要推定値を生成するのではなく、「すべての可能な未来とそれぞれの確率」を考慮します。需要、リードタイム、返品などの不確実性を組み合わせて、需要の完全な確率分布を構築します^{26 27}。例えば、需要とリードタイムの分布を畳み込んで確率的リード需要（補充リードタイム中の需要）を計算します²⁶。これは、単純な平均値+安全在庫よりも、断続的需要に対してはるかに堅牢です。重要なのは、Lokadの予測が、ゼロ需要とスパイクのリスクをネイティブで数量化し、最適化がそれらの確率を明示的に考慮できるようにすることです。

• 在庫最適化アプローチ: Lokadは純粋な経済最適化の立場を取っています。サービスレベルを尋ねるのではなく、「各ユニットの在庫を保有するコストと利益のバランスは何か」と尋ねます。そのフレームワークは、在庫に費やされた1ドルあたりのリターンを最適化します¹。実際には、ユーザーが経済的ドライバーを定義し、例えば部品あたりの保有コスト、在庫切れペナルティまたはダウンタイムコスト、発注コストなどを定義し、Lokadのアルゴリズムが期待利益を最大化する在庫ポリシーを見つけます。この確率的最適化は、確率的予測を直接入力として使用します。特筆すべきは、Lokadが従来のサービスレベル目標を避け、それらを時代遅れと考えていることです²⁸。その理由は、サービスレベルの割合が、どのアイテムが本当に重要であり、それらを達成するコストを区別しないことです。代わりに、Lokadは、在庫投資に対して提供される総合的なサービス価値を最大化することに焦点を当てています。 Lokadはシナリオで、特定の在庫決定が財務面でどのように実行されるかを評価するために何千ものif-thenの結果（ランダムな需要引き）をシミュレートし、それを改善するために反復します。これは、本質的には「コスト対効果」の在庫決定に調整された特注のモンテカルロ最適化です。

• 自動化＆スケーラビリティ: Lokadのソリューションはスケールでの自動化を目指して設計されています。ERPなどからデータが流れ込み、全体の予測→最適化→補充決定パイプラインがスクリプト（LokadのEnvisionコーディング環境）を介して実行されるクラウドプラットフォームとして提供されています。つまり、ロジックが設定されると、数万から数十万のSKUを手動介入なしで処理できます - 補充オーダーの生成、在庫レベルの推奨などを継続的に行います。プラットフォームは大規模な計算（クラウドクラスターを活用）を処理し、100,000以上のSKU-ロケーションの組み合わせに対する複雑なシミュレーションさえも一晩かそれ以下で実現可能です。アプローチがプログラム化されているため、企業は各アイテムを調整するためにプランナーが必要なく、非常に詳細なルールや目標をエンコードできます。人間の入力は主に設計/監視レベルで行われます（例：コストパラメーターまたはビジネス制約の調整）、予測は各部品ごとに行われません。このレベルの自動化は、何千もの断続的な部品の予測と計画を人間のチームが効果的に行うことができない深いロングテール管理にとって重要です。Lokadは、意思決定に主観的な人間のオーバーライドが関与する場合、効果的なシミュレーションと最適化が実用的でなくなる²⁹ことを明示的に指摘しています - したがって、彼らは人間が正しいモデルと経済パラメーターを設定することに焦点を当てた完全に自動化された決定システムを奨励しています。

• 技術的深さ: 技術的には、Lokadはかなり高度で「エンジニアリング第一」です。サプライチェーン向けの独自のドメイン固有言語（DSL）であるEnvisionを作成しました。これにより、データ、機械学習の予測、最適化ロジックを組み合わせた細かく調整されたスクリプトを記述できます。これは単なるマーケティングではありません - サプライチェーン向けの軽量プログラミング環境であり、専門の断続的需要予測方法や不確実性下での再注文ポイントのカスタム最適化など、複雑なカスタムアルゴリズムを簡潔に実装できます。Lokadの確率最適化と「ランダム変数の代数」²⁶³⁰の使用は、実際の数学的深さを示しています。ML/AIに関して、Lokadは一般的なAIを誇大広告するのではなく、関連する場所で機械学習を適用するかもしれません（たとえば、SKU全体で確率分布を推測したり、パターンを検出したりするため）、しかし常により大きな確率的フレームワークのサービスとして行います。プラットフォームはまた、微分可能プログラミング技術と高度なモデルアンサンブルをサポートしており、彼らの文献によると、現代のAIの採用を示しています。ブラックボックスの「AI」とは異なり、Lokadのアプローチは応用データサイエンスエンジニアリングにより近く、透明で各クライアントのデータに合わせてカスタマイズされています。

• 希薄で不規則な需要の取り扱い: これがLokadの得意分野です。同社の創業者は、従来の方法（Croston法や単純指数平滑法など）を断続的な需要には不十分だと批判しています。なぜなら、これらの方法はしばしば分散を二の次に扱うからです。Lokadの確率的予測は、ゼロ需要期間や異常なスパイクを自然に処理し、需要分布でそれらを表現することによって、アドホックな「異常値の除外」は不要です（たとえば、期間内のゼロの高い確率、1、2、3ユニットなどの小さな確率）。したがって、需要スパイクは捨てられるわけでも盲目的に使用されるわけでもなく、将来のスパイクの確率を通知する1つの観測に過ぎません。同様に、Lokadは「需要分類」（速い/遅い、塊状）に依存しません。そのアルゴリズムは、各SKUの固有の履歴に適応できます。非常に遅い動きの部品の陳腐化のリスクも考慮されています（彼らはサービスの向上に焦点を当てることでの損失を明示的に指摘しています³¹）。要するに、Lokadはパッチを縫い合わせるのではなく、統一された確率モデルで不規則な需要に対処しています。

• 統合＆アーキテクチャ: Lokadは比較的若いソリューションであり、内製で構築されているため、レガシーな取得物はありません - プラットフォームは統一されています。データ統合は通常、クライアントのERP/WMSからのファイルロードまたはAPIを介して達成されます。Lokadはカスタムモデリングアプローチを使用しているため、初期設定では、Lokadのデータサイエンティストが企業と協力して、彼らのビジネスロジックをEnvisionにエンコードする作業が行われます。これは既製のソフトウェアとは異なるパラダイムです：Lokadのプラットフォーム上でカスタムの分析アプリケーションを構築することに近いです。利点は非常に適合しやすく、ビジネスニーズが変わっても（スクリプトを編集することで）ベンダーのリリースサイクルを待つことなくモデルを進化させることができることです。

• 赤旗/懐疑論: Lokadは安全在庫やサービスレベルなどの概念に対する強い姿勢を取っており、この新しいアプローチが実際に優れているかどうかを検証する必要があります。サービスレベルが「時代遅れ」であると主張することは挑発的です；本質的には、Lokadはそれらをコスト指標で置き換えており、コストを十分に定量化できる場合には理にかなっています。企業は、そのコスト入力（欠品コストなど）を提供できるか、あるいは共同で決定できることを確認する必要があります。さもなければ、経済的最適化は仮定されたコストの良いものに限ります。もう1つの考慮事項は、Lokadのソリューションがプログラミングを必要とすることです - これはサプライチェーンソフトウェアにとっては珍しいことです。クライアントがDSLを学ぶか、Lokadのサービスに頼る準備ができていない場合、これは障害になる可能性があります。ただし、Lokadはサプライチェーンサイエンティストがモデル構築のほとんどを行うことで、この問題を緩和しています³²。最後に、Lokadは一般的な「在庫をX％削減しました」という数字を公表していません - これは、大胆なマーケティング統計ではなく技術に焦点を当てている良い兆候です。懐疑論者は、確率的アプローチが企業の現状よりも具体的な改善をもたらすことを確認するために、参照クライアントやパイロットを見たいと考えるでしょう。

ToolsGroup（Service Optimizer 99+）

• 確率予測: ToolsGroupは、サプライチェーン計画に確率モデルを適用する先駆者でした。*「確率予測は、予測不可能な、動きの遅い、長尾のSKUに計画する唯一の信頼できるアプローチである」*と強調しています³。具体的には、ToolsGroupのソフトウェアは、来月の需要について単一の数値を予測するのではなく、全体の分布を計算します（モンテカルロシミュレーションや解析的確率モデルを使用して）。例えば、部品の平均需要が1年に2個の場合、ToolsGroupは年間の需要を次のように表現するかもしれません：0の確率が70％、1の確率が20％、2以上の確率が10％など、過去とパターンに基づいて。この分布は在庫計算に直接反映されます。ToolsGroupの需要モデリングには、断続的な需要間隔（Croston法やより高度なバリアントを使用）やリードタイム、サプライヤーの信頼性などの変動を組み込むことができます。彼らは断続的な需要に特化したアプローチを長年取り入れてきました（1つのホワイトペーパーは「低ボリューム、断続的な需要予測」のアルゴリズムに言及しています）⁸。近年、ToolsGroupは予測を強化するために機械学習を導入しており、類似のパターンを持つアイテムをクラスタリングしたり、因果要因を検出したりしていますが、その核心は純粋な機械学習のブラックボックスではなく、確率論に根ざしています³³。

• 在庫最適化アプローチ: ToolsGroupのアプローチの特徴は、「サービスレベル対在庫」のトレードオフ最適化です。システムは、各SKUロケーションごとに在庫とサービスの曲線を生成し、さまざまな在庫レベルで達成できるサービスレベル（フィル率）を示します³⁴。これらを評価することで、追加の在庫がサービスに対して収益を生み出さなくなるポイントを見つけ出し、効果的に投資全体のサービスを最大化するためのアイテム固有のサービスターゲットを選択します。これは、サービスレベルの用語でフレームされた経済最適化の一種です。通常、ToolsGroupは、ユーザーが希望する総合サービスレベルまたはサービスレベルのミックスを指定し、その目標を最小限の在庫で達成するために在庫を割り当てることを許可します。さらに、ToolsGroupは**多階層最適化（MEIO）**をサポートしています：在庫量だけでなく、ネットワーク内でそれを保持する場所（中央、地域、フィールド）を最小限に抑えてバックオーダーや物流コストを最小化することができます。そのMEIOの能力は高く評価され、航空宇宙、自動車、電子機器などのスペアパーツネットワークで使用されています。また、複数ソース供給（たとえば、部品を在庫から供給するか、サプライヤーから緊急調達するか）も考慮しており、モデルは利用可能性を確保するために最も経済的な方法を選択できます³⁵。ToolsGroupの説明はサービスレベルに重点を置いていますが、基本的な最適化は確かにコストを考慮しています - たとえば、保有コスト、在庫切れのペナルティコスト（時には目標サービスを通じて暗黙的に） - 作業資本を解放し、信頼性を維持する解決策を特定します⁴。

• 自動化とスケーラビリティ: ToolsGroupの主要なセールスポイントは、*「自動運転計画」*の哲学です。予測の調整、パラメータ設定、さらには発注書の生成を自動化することで、手作業を大幅に削減することを目指しています。ソフトウェアは、各SKUを監視し、最適化された在庫にもかかわらずリスクのあるサービスレベルやモデルが予測できなかった需要トレンドの変化など、何かが大幅に逸脱したときにのみ例外を発生させます。これは、数万のアイテムを持つスペアパーツにとって重要です - すべてのプランナーが目を光らせることはできません。実際のユーザーは、このツールが再発注ポイントの計算、推奨購入、およびロケーション間の再配分を自動化し、プランナーには非常に高価な部品や重大な故障などの一部の提案のみをレビューするように残すと報告しています。スケーラビリティに関して、ToolsGroupは、非常に大規模なデータ（たとえば、遅い/速いアイテムの数百万のSKUロケーションの組み合わせを持つ消費財企業、または100k以上の部品を持つグローバルOEM）を参照しています。そのアルゴリズムは効率的ですが、最初はいくつかの重いモンテカルロシミュレーションが計算上負荷がかかることがありました - ここで、数年にわたる研究開発がパフォーマンスを最適化しました。現在、クラウド展開とモダンな処理により、これらのシミュレーションを一晩でスケールさせることができます。ユーザーは、システムが手作業で予測モデルを常に微調整する必要がなく、長いテールを処理し、結果を出力することを信頼できます - これは古いMRPやDIYアプローチとの大きな違いです。ToolsGroupは、プランナーがその自動化を使用して在庫を20-30%減らすことで95%以上のサービスレベルを管理できると自慢しています（これらの数字は参考値として受け入れられるべきであり、保証されたものではありません³⁶）。

• 技術的深さ: ToolsGroupのテクノロジーは、古典的なオペレーションズリサーチと新しいAIを融合させています。コアエンジン（SO99+）は、量的手法にルーツを持っており、たとえば、リードタイム需要にはポアソン、ガンマなどの確率分布（コンボリューションと組み合わせて）を歴史的に使用し、多段階在庫配置のための最適化ソルバーを使用してきました。彼らはまた、予測トレンドを自動的に調整するための「需要のクリープとフェード」、およびサービスレベルをサプライネットワーク全体に伝播させるための*「パワーノードアルゴリズム」*などの概念を導入しました。最近、ToolsGroupはAIに焦点を当てた企業（例：「反応型AI」を提供するEvoなど、「量子学習」と呼ばれるものを提供）を買収しました³⁷。少し曖昧ですが、おそらくこれは新しい機械学習モジュールを意味し、予測を洗練させたり、パラメータを継続的に最適化したりするためのものです。また、小売需要計画ツール（Mi9/JustEnough）³⁸やeコマースフルフィルメント最適化ツール（Onera）³⁹を買収しました。これらの動きは隣接する領域に進出していることを示しています。懐疑論者は尋ねるべきです：これらは統合されていますか、それとも単なる追加機能ですか？これまでのところ、ToolsGroupは小売ユーザー向けにJustEnoughのフロントエンドを統合し、予測のためにそのAIエンジンを活用しています。これは主に動きの速い商品に関連しています。予備部品については、SO99+が依然として中核的な解析エンジンです。同社のAIに関するメッセージは時々バズワードが多いです（「AIサポート機能…最低在庫でサービス目標を達成する」⁴）、しかし、その下には予測の季節性を検出するアルゴリズムや、新興の現場の問題による「断続的な急増」を経験する可能性のある部品を特定するアルゴリズムなど、具体的な機械学習機能があります。全体として、ToolsGroupは堅実なエンジニアリングを実証しています：現代の技術を用いて段階的に改善された安定したプラットフォームを提供しています。また、重い分析の上に比較的ユーザーフレンドリーなUIを提供しており、プランナーが選択すれば複雑さから遮断されます。

• 希薄で不規則な需要の取り扱い: ToolsGroupはここで明確に自社の強みをマーケティングしています。彼らはしばしば、断続的な需要に対して従来の予測が失敗すると述べ、確率モデリング+インテリジェントアナリティクスのアプローチがまさにこのシナリオに適していると主張しています³。不規則な需要の部品に対して、ToolsGroupはおそらく、不規則な需要の推定（たとえば、平均間隔とサイズを推定するCroston法）と不確実性モデリングの組み合わせを使用して、分布を作成するでしょう。重要なのは、平均を計算して通常の分布に挿入するだけでなく、分布が非正規であることを知っていることです（多くのゼロを含む高度に歪んだ分布）。これは、計算された安全在庫（または再発注ポイント）が単純な式に基づくのではなく、その分布の所望のパーセンタイルに基づいていることを意味します。実際には、ToolsGroupのモンテカルロシミュレーションは、リードタイムのために1000の可能な需要結果をシミュレートし、そのうち950の1000の結果が在庫から満たされるようにどれだけの在庫が必要かを決定します（95%サービス）。これは、任意の「安全在庫として2STDを追加する」という仮定がベルカーブ需要を前提としているよりも、断続的な需要を処理するより現実的な方法です。彼らはまた、変化を感知するために「予測アナリティクス」*を組み込んでおり、たとえば、部品が突然使用量が増加した場合、システムはトレンドやレベルの変化を検出し、固定された定期的なレビューよりも迅速に適応することができます。ToolsGroupのリーダーシップ記事では、従来の「異常値のクレンジング」を避けることさえ言及されており、すべての需要データが確率を通知するために使用されます（何かが明らかに一度限りのイベントである場合を除き、その場合でも、再発生の可能性が一部保持されるかもしれません）。要約すると、ToolsGroupは、需要を明示的にモデリングし、実際のデータパターンに連続的に適応することで、不規則な需要を処理しています。

• 統合とアーキテクチャ: ToolsGroupの主要なソリューションは数十年にわたって社内で開発されており、コアの統合は密接です。買収（JustEnough、Onera、Evo）は比較的最近でターゲットが絞られています：Evo AIはおそらく彼らの計画エンジンに組み込まれているでしょう（彼らは「統合されたEvoAIエンジンのおかげで、JustEnoughはAI駆動の計画をリードしている」と述べており、Evoのテクノロジーが予測機能に組み込まれたことを意味しています）。Oneraの部分はより独立しており（小売業向けのリアルタイム在庫可用性）、スペアパーツにはあまり関係ありません。全体として、ToolsGroupのスペアパーツ計画のアーキテクチャは統一されており、需要予測、在庫最適化、補充はすべて同じデータモデルを使用しています。クラウドとオンプレミスの両方を提供していますが、ほとんどの新規展開はクラウドSaaSです。ERPとのデータ統合は、標準コネクタまたはフラットファイルのロード（どんな計画ツールでも）を介して達成されます。ToolsGroupには多くのモジュール（需要計画、S&OP、在庫など）があるため、1つの潜在的な問題は、各クライアントが最新のものを使用し、UIが一貫していることを確認することです。過去には、ユーザーインターフェースがアプリケーションの一部で古く感じるというコメントがありましたが、ToolsGroupはそれを更新しています。買収統合に注意: ベンダーが複数の企業を買収すると、機能が重複したり、UXが異なることがあります。たとえば、「JustEnough」のフロントエンドは、クラシックなToolsGroup UIとは異なる外観を持つかもしれません。顧客は、ロードマップがこれらを統一化しているかどうか、および（特にスペアパーツに関して）2つの異なるモジュールに存在する機能が別々の製品であるかどうかを尋ねるべきです。良いニュースは、ToolsGroupのスペアパーツソリューションがこれらの新しい買収に大きく依存していないため、このユースケースにおける断片化リスクは低いです。

• 注意すべき点/ベンダーの主張: ToolsGroupは多くの企業と同様に、在庫の大幅な削減やサービスの改善を主張する事例研究を持っています。たとえば、公表された事例では、Cray（スーパーコンピュータメーカー）が部品在庫を28%削減し、1300万ドルを節約したと報告されています³⁶、また、シスコはServigisticsユーザー（おそらくシスコも参照として含まれる）が在庫を10〜35%削減したとのメモを残しています⁴⁰。これらは印象的ですが、これらの一部はソフトウェア単体の魔法ではなく、ソフトウェア周りのプロセス改善にも一部帰属すべきです。ToolsGroupは、その資料でやや技術的に率直である傾向がありますが、いくつかのマーケティングも見られます。たとえば、「量子学習」というフレーズ（Evoの買収とともに）はハイプな印象を与えるかもしれません。見込み客は詳細を掘り下げるべきです：使用しているAIモデル（ニューラルネットワーク？勾配ブースティング？何を予測しているのか？）や、新しい部品の履歴がない場合のシステムの処理方法、または手動パラメータの調整に依存しているかどうか（理想的には最小限）。もう1つの小さな注意すべき点：ToolsGroupは引き続き「安全在庫の最適化」について話しています³⁴ – 安全在庫の概念自体は悪くありませんが、誤解されると、彼らはまだ古い数式を使用しているように見えるかもしれません。実際には、彼らは安全在庫レベルを通じて最適化しているので、それは静的なクッションではなく、素朴なユーザーはツールを誤用して静的な安全在庫を設定し、それを二重にしてしまうかもしれません。完全に自動化された最適化の適切な使用を確保すること（手動の安全在庫入力でそれをバイパスしないこと）が重要です。

PTC Servigistics

• 確率予測: Servigisticsはサービス部品のための高度な予測の長い歴史を持っています。その起源（Xelus、MCA Solutions）は、ポアソンや複合ポアソン（需要のため）などの確率モデルと洗練されたシミュレーションに根ざしていました。Servigisticsは、低ボリューム部品の需要確率分布を生成できます - たとえば、特定の部品が1つの需要の5％の確率、2つの需要の0.5％の確率、および月にゼロの需要の94.5％の確率を持つ可能性があるとモデル化するかもしれません。これは、過去のデータと既知のドライバーに基づいています。PTCが引用する*「高度なデータサイエンス」は、これらのアルゴリズムを指す可能性が高いです。Servigisticsは、数十年にわたって開発されたこれらのアルゴリズムを使用して、断続的な使用を予測します。また、IoTデータを使用した予測予測も含まれます：ThingWorx統合を使用すると、センサーの読み取りや予防保守アラート（たとえば、機械時間、振動警告）を部品の予測に組み込むことができます。これは因果関係の予測の形です - 時系列だけでなく、状況からの障害を予測しています。Servigisticsは、返品や修理の予測もサポートしており、部品ネットワークにとって重要です（たとえば、どれだけの故障した部品が返送され修理されるかを予測し、供給を作成します）。要するに、Servigisticsは実際の確率予測*を行い、長い間行ってきました（それが「AI」で予測を行っていたと言えるかもしれません - ただし、それを運用調査または確率モデルと呼んでいました）。PTCは今、それを「AI搭載」予測とラベル付けしていますが、業界の人々は、それが統計的予測方法（Croston法、ベイズ推論など）と最適化アルゴリズムの組み合わせであり、何らかの神秘的なAI魔法ではないことを知っています。要するに、Servigisticsの予測は、断続的な需要に対して非常に堅実と見なされています。

• 在庫最適化アプローチ: Servigisticsはサービス部品での多階層在庫最適化（MEIO）で知られています。これは、多階層スペア最適化の理論を実装した最初のツールの1つでした（SherbrookeのMETRICモデルとその後の研究に基づいています）。MEIOは、全体の供給ネットワーク（中央倉庫、地域デポ、現場など）を見て、各々の在庫レベルを最適化し、ネットワーク効果（たとえば、中央で保持すると、地域全体の変動をカバーできますが、現地で保持するとより迅速な対応が可能です - ツールは最適なバランスを見つけます）。Servigisticsは、特定のサービスレベルのためにコストを最小化するか、特定の予算のために可用性を最大化するかを最適化できます - したがって、真の経済最適化をサポートしています。実際には、多くのユーザーは、セグメントごとにサービスレベルの目標を設定し（たとえば、重要な場合は95％、重要でない場合は85％）、その後、ソフトウェアに最も少ないコストでそれを達成する方法を見つけさせます。他のユーザーはバックオーダーのペナルティコストを入力し、総コストを最小化させます。設定可能なため、サービスレベルの目標とコストベースの最適化の両方を行うことができます。1つの差別化要因：Servigisticsは多段階部品（部品内の部品）を処理します - たとえば、サブアセンブリとトップレベル部品の在庫を最適化することが重要です。また、複数ソースのフルフィルメントロジックもサポートしています（たとえば、1つの場所が在庫切れの場合、他からの横断輸送を考慮します）。これらは、一般的な在庫ツールに欠けている高度な機能です。PTCはまた、同じデータベースを共有する価格最適化モジュールを統合しました。したがって、価格設定と在庫決定は少なくとも共通のデータを使用できます（最適化が本当に統合されているかどうかは不明ですが、価格の変更が需要にどのように影響するかを評価することができると想像できます）。最適化アルゴリズムについては、Servigisticsはおそらく分析手法（ポアソン需要を考慮した多階層在庫の効率的なアルゴリズムであるVari-METRICなど）と、一部の問題に対しては線形計画法やヒューリスティクスを使用していると考えられます。彼らは大規模な顧客基盤からの入力を受けてこれらを継続的に改良してきたため、これらのアルゴリズムはサービス部品計画の最先端と見なされています。

• 自動化＆スケーラビリティ: Servigisticsは、最大かつ最も要求の厳しい組織（例：数十万の部品を持つ軍隊、高い稼働時間要件、限られたプランナーなど）にサービスを提供していることから、自動化が重要です。ソフトウェアは、ポリシーが設定されると、予測を自動的に再計算し、最適な在庫レベルを再計算し、ネットワーク全体での再配置や調達アクションを提案します。その後、プランナーは例外アラートを受け取ります - たとえば、特定の部品が目標在庫数を下回ると予測された場合、または新しい故障トレンドが検出され、在庫を増やす必要がある場合など。UIには、プランナーが使用できるシミュレーションツール（「ここでサービスレベルを上げた場合、コストにどのような影響があるか？」）が用意されていますが、数値計算の重要な部分はすべてバックグラウンドで自動的に行われます。スケールの観点から、Servigisticsは非常に大規模なデータセットでの能力を証明しています。ただし、ハードウェアやクラウドインフラストラクチャが適切にサイズ設定されていることを確認する必要があります - 古いオンプレミス展開では、大規模な実行に多くの時間がかかる場合があります。PTCはおそらく今ではクラウド展開を提供しています（政府向けのFedRAMP準拠のSaaSを含む）⁴¹、これはスループットを向上させるためにスタックを近代化したことを示唆しています。自動化のポイントは、IoTの統合もあります：機械信号が部品の故障を予測した場合、Servigisticsは自動的に予測を調整したり需要信号を作成したりできます（これが彼らの接続されたサービス部品最適化の約束です）⁹。したがって、システムは静的な定期的な計画ではなく、リアルタイムの適応型計画に向かっています。これらすべては、プランナーが手動で反応する必要を減らすことを目的としており、代わりにシステムが予測し、プランナーが監視します。

• 技術的深さ: Servigisticsは、サービス部品のニッチでおそらく最も機能が豊富であり、それは数十年にわたる研究開発と複数の技術の合併によるものです。利点は非常に深い技術の知識です：たとえば、Servigisticsには、航空宇宙向けのシナリオベースの最適化に特化したアルゴリズムを含むMCA Solutionsから、サービス部品の予測に先駆けたXelusからのアルゴリズムが含まれています。PTCは、「XelusとMCAの機能のベストをServigisticsの堅牢なアーキテクチャに成功裏に統合した」と主張しています¹⁰。PTCの下で、ServigisticsはPTCのポートフォリオからのIoTと高度な分析にアクセスできるようになりました（IoT用のThingWorx、おそらくPTCの研究からのいくつかのAI）。PTCは、Servigisticsが2006年に機械学習/AIのコンセプトを導入したと強調しています⁴² - おそらく需要感知のパターン認識や使用の異常検出を指しているでしょう。今日、彼らはそれを**“AIパワードサービスサプライチェーン”**としてマーケティングしています⁴³。具体的には何を意味するのでしょうか？おそらく、大規模なデータセットから学習して予測の精度を向上させるためにMLを使用し（おそらく顧客全体を対象としていますが、データ共有は機密性が高い）、AIを使用して最適なパラメータを特定したり、部品消費を促進する要因（機械の年齢、場所、天候など）を特定したりすることでしょう。在庫戦略を微調整するために強化学習を使用する可能性もあります。詳細は公開されていませんが、Servigisticsがアナリストによる一貫したトップランキングを獲得していることから、技術の深さが相当なものであることが推測されます。ただし、複雑さは裏返しです：ソリューションが多くのことを行うことができるため、企業のニーズが単純な場合は過剰な場合があります。PTCはおそらくUIとテクノロジースタックを近代化しました（Servigisticsは元々クライアントサーバーアプリであり、その後Webベースになりました）。現在、それはサービスライフサイクル管理のためのPTCの広範なテクノロジースタックに位置しており、フィールドサービスシステムやサービス用のAR（拡張現実）インターフェースなどとデータを共有できます。さまざまな技術の統合は、エンドツーエンドを望む場合にはプラスですが、在庫についてしか関心がない場合には膨満と見なされる可能性があります。

• スパースで不規則な需要の取り扱い: Servigisticsはまさにそのシナリオに向けて構築されました（航空宇宙を考えてみてください：航空機部品が何年も故障しない場合、突然故障が発生するかもしれません）。このソリューションは、「低ボリュームで断続的な需要予測」向けの専門的な手法を提供しています⁸。おそらく、Croston法、ベイズブートストラップ、共変量を使用した投与反応モデル（IoTを使用する場合）などが含まれています。また、部品のセグメンテーションの概念もあります - 単に使用量によるABCだけでなく、より微妙なものです。たとえば、部品を需要パターンで分類し、異なる予測アプローチを適用することができます（たとえば、「断続的で低ボリューム」の部品対「断続的でトレンドがある」対「本当に塊状のランダム」）。セグメンテーションにより、たとえば、純粋に断続的な需要の部品がトレンド予測モデルに強制的に適合されないようになります。代わりに、単純なポアソンまたはゼロ膨張ポアソンモデルを使用するかもしれません。Servigisticsはまた、「陳腐化のある断続的な需要」にも対処しており、部品のライフサイクルを追跡し、装置が経時的に陳腐化するにつれて予測を段階的に下げることができます。これは、汎用ツールが見逃すかもしれないものです。重要なのは、Servigisticsが不規則な需要をカバーするために単に高い安全在庫を設定するだけでなく、望ましいサービスレベルを達成するために確率モデルから必要な安全在庫を計算することです。これは、非常に不規則なアイテムの場合、非常に高い在庫を推奨するかもしれません（在庫切れのコストが高い場合）、または逆に、コストが禁止的な場合はより低いサービスを受け入れるかもしれません - これらの決定は、ユーザーからの入力またはデフォルトのコストの仮定によってガイドされる可能性があります。防衛クライアントによってシステムが使用されていたため、おそらく頑健な異常値検出ツールも備えているでしょう - たとえば、1か月に一度のプロジェクトによる急激なスパイクが表示された場合、プランナーはそれをフラグ付けして予測に過度な影響を与えないようにすることができます。ただし、理想的には、代わりに既知の「異常な需要イベント」を入力し、プロセスを介してそれを除外することが望ましいでしょう。いずれにせよ、Servigisticsはこれらすべてのテクニックを活用することで、ほとんど最悪の需要シナリオ（非常にスパースなデータ、高い不確実性）に対処できます。

• 統合とアーキテクチャ: すでに述べたように、Servigisticsは時間をかけて複数のテクノロジーを統合したものです。すべての報告によると、PTCはそれらを1つの製品に統合しています（ユーザーには複数のUIがない - 1つのServigisticsアプリケーションです）。Servigisticsの価格設定モジュールが在庫と同じデータベースを使用していること⁴⁴は、Syncronの分割とは異なる単一プラットフォーム設計を示しています。PTCは大手企業なので、Servigisticsは専門のエンジニアリングとサポートを受けています。潜在的な問題はアップグレードパスです：古いバージョンの顧客は、製品がどれだけ進化し統合されたかを考えると、アップグレードが難しいと感じるかもしれません。また、顧客が機能の一部だけを必要とする場合、依然として大規模なシステムを展開する必要があるかもしれません。ERPや他のシステムとの統合は、通常、インターフェースモジュールを介して行われます - PTCはおそらく、多くの顧客がそれらのERPシステムを使用しているため、SAP、Oracleなどへの標準コネクタを持っています。PTCはまたPLM（製品ライフサイクル管理）のリーダーでもあるため、PLMからのBOMデータをServigisticsにリンクして新製品の部品計画に活用するなど、興味深い統合が可能です。これらの統合は、包括的なプロセス（たとえば、新しい部品導入計画）にとってプラスになるかもしれませんが、各統合ポイントはそれ自体がプロジェクトであるため、「プラグアンドプレイ」とはまったく言えません。そういった洗練されたツールがプラグアンドプレイであると主張することには懐疑的な態度を取るべきです - 実際には、データのクレンジング、マッピング、およびビジネスルールの構成が必要です。

• 赤い旗/懐疑心: Servigisticsのマーケティングは一般的に信頼性がありますが、「X％の改善を保証します」という声明には注意が必要です。彼らのケーススタディ（例：リフトメーカーであるKONEは、二桁の在庫削減を実現しました⁴⁵）は実際のものですが、これらの結果は会社の出発点の成熟度に依存します。会社が非常にアドホックだった場合、Servigisticsとプロセスの遵守を実装すると大きな利益が得られます。しかし、すでにまともな計画プロセスを持っている場合、利益は小さくなるかもしれません。探るべき別の領域は、AI/MLの流行語がどのように結果に繋がるかです。PTCはServigisticsで「次世代AI」を謳っています⁴³ - 購入者として、具体的な例を求めてください：需要予測のためにニューラルネットワークを実装しましたか？ AIを使用して従来のOR手法を超えた在庫戦略を最適化していますか？それとも、それは主に既存の高度な統計情報に対するマーケティングラベルですか？ PTCの技術力を考えると、実際にはMLを使用して修理の回転時間をよりよく予測したり、以前は手動だったパラメータ設定を最適化したりする実際の改善がある可能性が高いです。しかし、それをデモや技術的な議論を通じて検証することは賢明です。買収統合: PTCは統合が成功したと言っていますが、常に残っている別々のモジュールがあるか、ソフトウェアのすべての部分が統一感を持っているかを確認してください。 Blumのベンチマークによると、Servigisticsは「最も幅広い機能群」を持っており、それがすべてのアナリストレポートでリーダーポジションを獲得するのに役立ちました⁴⁶ - 時には幅広さが特定の領域での深さを犠牲にすることがあります。ただし、Servigisticsの場合、ほとんどの領域はかなり深いです。最後に、リソース要件を考慮してください：Servigisticsを実装することは軽い作業ではありません - 最初に構成および調整するために、かなりのコンサルティング（PTCまたは第三者）が必要になるかもしれません。ベンダーが彼らのツールをただオンにしてすぐに在庫を30％削減できると主張している場合、懐疑心を持ち続けてください - 特にサービス部品最適化のような複雑なものに関しては、成功はツール+プロセス+データの正確性の組み合わせから得られます。

GAINSystems（GAINS）

• 確率的予測: GAINSは、マーケティングで「確率的予測」という言葉をあまり使用しないかもしれませんが、計算においては確かに変動性を取り入れています¹³。GAINSシステムはおそらく内部で需要の範囲を生み出し、在庫を最適化するためにそれを使用しています。歴史的に、GAINSの方法論には、平均だけでなく分散も推定する統計的予測モデルが含まれており、それから必要な在庫をシミュレートまたは分析的に決定します。彼らのウェブサイトには明示的に、需要予測、リードタイム、供給などの変動性を取り入れることで*「最適なサービスレベルを達成する」と記載されています¹³。これは、GAINSが需要と供給の分布を考慮に入れていることを意味します。また、**「修理および予防保守計画」**の機能も持っており、これは予測が販売の時系列だけでなく、メンテナンススケジュールや信頼性曲線に基づいて部品の故障も予測していることを意味します（フリート管理、公共事業などの顧客向け）。これは、例えば、部品の故障間隔の分布などの確率的要素を追加します。 GAINSは、データの可用性に応じて、時系列予測（Croston法、指数平滑化が適用可能な場合）と信頼性モデリング（故障率のWeibull分布）の組み合わせを使用している可能性が高いです。さらに、GAINSはS&OPのためのシナリオシミュレーション*の早期採用者であったため、部品需要にもシナリオ思考を適用していると想像できます（最良のケース、最悪のケースなど、これは確率的推論の形態です）。要するに、GAINSは各SKUに対してユーザーに向けて派手なヒストグラムを出力しないかもしれませんが、裏では未来が既知であるとは仮定していません - 実証された統計モデルを使用して変動性に備えて計画しています。

• 在庫最適化アプローチ: GAINSはコストと利益の最適化に重点を置いています。彼らは、在庫の意思決定を継続的に最適化することで、より高い収益性を提供すると位置付けています¹¹。実際に、GAINSは、総コスト（保有コスト、発注コスト、バックオーダーコストを含む）を最小化するか、ある利益指標を最大化するために最適化することができます。彼らはサービスレベルの目標も設定できます - 彼らのサイトでは「目標のサービスレベルを正確に達成する」と言及されています⁴⁷ - ただし、最適な方法で行います。GAINSは、マルチエシュロン在庫最適化もサポートしていますが、彼らの得意分野は、中央とフィールドの場所、おそらく修理ループ在庫を含むシナリオが多いです（彼らは明示的にロータブル最適化を言及しています⁴⁸）。GAINSの強みの1つは、さまざまな制約を考慮した最適化です：修理容量や資金制約などの制約事項を最適化に組み込むことができます。たとえば、修理工場が週にX台しか処理できない場合、GAINSはそのボトルネックをカバーするために余分な予備品をストックするかもしれません - ホリスティックなアプローチです。また、メンテナンス計画も統合しています - たとえば、機器のオーバーホールが6か月後に予定されている場合、GAINSはそのための部品を計画できます。これは確定的需要が確率的なミックスに挿入される一種のものです。これらすべての要素が、単にアイテムごとの在庫ツールよりも「運用に配慮した」包括的な最適化に結びついています。別の側面：GAINSはシナリオ最適化とシナリオ解析を提供しており、異なる戦略（在庫への投資と迅速化など）をシミュレートし、コストとサービスに与える影響を見ることができます。これは意思決定に経済的アプローチを反映しています。GAINSは、エンドツーエンドのサービス供給チェーンのパフォーマンスを最適化しようとしていると言っても過言ではありません。

• 自動化とスケーラビリティ: GAINSはクラウドプラットフォームとして提供されています（展開は数か月で可能と主張しています⁴⁹）。コアデザインの目標は意思決定の自動化であり、プランナーが最良の意思決定を導くか、それを自動化することです。GAINSには**「エキスパートシステム」**の推奨事項などの機能があり、自動的に「ここで在庫を増やす」や「場所AからBに在庫を再バランスする」といったアクションをフラグ付けします。プランナーは承認または調整することができますが、重要な分析はシステムが行います。GAINSは連続的な計画も強調しています：静的パラメータではなく、新しいデータが入ってくるたびに連続的に再最適化します（したがって「機械学習、実証済みのアルゴリズムによる連続最適化」¹¹）。スケールに関して、GAINSは大規模なグローバル運用を持つクライアントを持っており（公開されている例として、BC Transitがフリート全体のバス部品計画にGAINSを使用しています）、彼らのアーキテクチャは現在クラウドベースであり、計算をスケーリングアウトすることが可能です。GAINSにはパフォーマンスの問題があまり聞かれないため、大規模なデータセットを処理するのにかなり適していると言えますが、調整が必要かもしれません。システムは複数のERPとインターフェースし、需要、在庫、BOMなどを取り込み、推奨される注文を出力します。1つのユニークな自動化の側面：GAINSは予算立案および財務計画の目的で予測を生成することもでき、在庫計画をファイナンスと調整することができます - 企業が広範な計画でシステムの出力を信頼するのに役立ちます。全体として、GAINSは主に「手を離して」最適化されており、プランナーが目標と制約を設定し、システムが残りを行い、人間の意思決定が必要な場合にアラートを発生させます（たとえば、非常に高価な新しい部品が導入された場合、その戦略の手動レビューが必要になるかもしれません）。

• 技術的深さ: GAINSは数十年前から存在しており、彼らのアプローチは常に非常に分析的でした。 「高度なヒューリスティック、AI / ML、最適化」という言及 ⁵⁰ は、彼らがさまざまな技術を使用していることを示唆しています。 たとえば、ヒューリスティックアルゴリズムやメタヒューリスティックを使用して、数式では解決できない複雑な最適化問題を解決するかもしれません（例：修理と在庫の同時スケジューリング）。 彼らは機械学習を取り入れて、予測の精度を向上させる可能性が高いです（外部要因に関連付けられた使用パターンの特定や最適な適合モデルの部品の分類など）、およびデータの異常検出に使用するかもしれません。 GAINSはまた、「意思決定エンジニアリング」という概念を導入しました - 彼らのプレスリリースの一つでの用語 ⁵¹ - 連続的に学習し、意思決定を改善するフレームワークを示唆しています。 これには強化学習（システムが時間の経過とともにどのような意思決定が良い結果につながったかを学習し、それに応じて微調整する学習）が含まれる可能性があります。 ベンダーの具体的な情報がないため、GAINSのテクノロジーはLokadのように派手でも実験的でもないかもしれませんが、確かです：証明されたORアルゴリズム（在庫と多段階のため）、統計的予測、およびMLを適用する場所（リードタイム予測の調整や非線形関係の見つけ方など）。 GAINSはまた、計画領域の統合を強調しています：需要、在庫、供給、さらには販売と運用計画（S＆OP）をすべて1つのプラットフォームで統合します ¹⁶。 これは、彼らのデータモデルが高レベルの計画からアイテムレベルの実行まで広がっていることを意味します。 技術的には、それは貴重です。なぜなら、スペアパーツの計画はしばしば孤立しているためです。 GAINSは、それを生産、調達などと接続して、実現可能性を確保しようとしています。 ユーザーインターフェースとエンジニアリングの観点から、GAINSにはモダンなWebインターフェースとKPIのダッシュボードがあります（リアルタイムでのフィル率、回転率などの追跡を強調しています）。 彼らはまた、顧客の成功をよく強調しており、それは各クライアントのためにテクノロジーを微調整する努力を示しています（ブラックボックスではなく、協力的な構成 - サービスのようなもの、製品であるにもかかわらず）。 彼らの予防保守計画などの領域での深さは差別化要因です：ほとんどの在庫ツールはいつ保守を行うかを提案することには踏み込みませんが、GAINSは信頼性モデルと統合して、そのタイミングを最適化し、部品の入手可能性と比較して、システムレベルの最適化の考え方を示すことができます。

• 希薄で不規則な需要の取り扱い: GAINSは確かに複数の戦略を使用して不規則な需要に対処しています。 1つは、間欠性に特化した統計モデルを使用することです - おそらくCroston法や新しいバリアント（例：Syntetos-Boylan近似など）。 さらに、GAINSは予測を改善するために因果関係データを活用できます - たとえば、部品の使用を設備の使用にリンクすることができます。 特定の部品の消費が不規則である場合でも、設備の使用頻度や環境条件などのデータがある場合、GAINSのMLは相関関係を見つけて、純粋な時系列よりもニーズをよりよく予測するかもしれません。 ただし、MLを使用しても、多くのスペアパーツの需要は基本的にランダムです。 GAINSは不確実性下での安全在庫最適化に依存します。 通常、各アイテムに適切な統計的安全在庫を決定します。その変動性と望ましいサービスに応じて。 GAINSはコストに焦点を当てているため、経済に基づいてアイテムごとにサービス目標を動的に変化させるかもしれません（Lokadの考え方と似ています）：部品が非常に不規則で高価な場合、GAINSは、高いサービスを達成するコストが膨大であるため、それを少し下げることを決定するかもしれません（高ダウンタイムコストを持つミッションクリティカルな場合を除く）。 この微妙な違いは、ユーザー定義の優先順位またはGAINS自体のアルゴリズムから来る可能性があります。 トータルシステムのフィル率をコスト予算内で最大化するアプローチ。 GAINSにはまた、**「不規則な需要の急激な上昇」**を処理する機能があります：たとえば、突然の大量注文やリコールが発生した場合、通常のパターンを歪めないようにそれを別個に処理できます。 プラットフォームには、過去のデータの外れ値検出およびクレンジングツールが含まれており、過去の記録に一度だけのイベントがある場合に役立ちます。 懐疑論者は、外れ値のクレンジングが多少手作業的/伝統的であると指摘するかもしれません（実際、Lokadはそのアプローチを批判しています）、しかしGAINSは、コントロールを望むプランナーのためのオプションとして提供している可能性が高いです。 システムに任せると、GAINSはおそらく外れ値の影響を自然に抑制する堅牢な予測手法を使用するでしょう。 要するに、GAINSは、高度な予測、スマートな安全在庫計算、および（計画されたメンテナンスやエンジニアリングの変更などの）追加情報を活用して、それ以外の「ランダム」なイベントを予測することによって、不規則な需要を処理しています。

• 統合とアーキテクチャ: GAINSはGAINS Systemsによって開発された単一のプラットフォームであり、外部製品を取得したことは知られていません。そのため、モジュールは有機的に組み合わせるように構築されています。SaaSとして提供されており、GAINSがインフラストラクチャと更新を担当しています。ソースシステム（ERP、資産管理システム）への統合は、GAINSプロジェクトの重要な部分です - おそらく標準のAPIやバッチアップロードプロセスを持っています。GAINSはしばしば資産管理やERPシステムと統合して、機器リスト、BOM、故障率などを取得します。GAINSは複数の計画領域をカバーしているため、企業が使用するツールの数を減らすことができます（たとえば、需要予測と在庫管理のために別々のツールを使用する代わりに、GAINSを使用することができます）。このアーキテクチャはグローバルな運用をサポートしており、大企業にとって必要不可欠です - 複数通貨、複数単位など。企業がGAINSを予備部品にだけ使用したい場合、製品資料には適切なデータ境界が必要です。しかし、全体的には、アーキテクチャはGAINSの顧客にとって公開レビューで痛点とされているわけではなく、安定して統合されているということを意味しています。

• 注意すべき点 / 懐疑: GAINSはマーケティングで派手さに欠ける傾向があり、明白なバズワードの危険信号が少ないです。最近はAI/MLについてよく言及していますが、これはほぼ義務的です。これらの主張が実証可能な機能で裏付けられていることを確認する必要があります。たとえば、GAINSに尋ねてみてください：「具体的にAIは計画をどのように改善しますか？MLが予測精度や意思決定の品質を向上させたケースを示すことができますか？」 長い歴史を考えると、おそらくできるでしょうが、確認することが良いでしょう。検討すべき別の領域はユーザーエクスペリエンスです - 以前の評価では、数年前のGAINSのUIは最もモダンではなかったと言及されています。その後、更新されましたが、プランナーがそれを使いやすいと感じ、シナリオを設定したりパラメータを調整するのが過度に複雑でないことを確認してください。GAINSは多くをカバーしているため（在庫、予測、S&OPなど）、時には万能なツールはある分野で弱いことがあります。ただし、GAINSは予備部品計画で特に認識されており（GartnerやIDCのレポートで）、全体的にはおそらく一貫して優れています ⁵²。微妙な危険信号：GAINSの迅速な展開のメッセージング（「数か月で稼働」⁴⁹）は文脈を考慮して受け取る必要があります - それはおそらく焦点を当てた範囲と良好なデータの準備を前提としています。複雑な環境で数か月で完全な最適化を達成することは楽観的です。より頻繁に、企業は段階的に進めます（いくつかの場所や製品ラインをパイロットし、その後拡大します）。これは普通のことですが、あまりにも楽観的なスケジュールには注意が必要です。最後に、GAINSはPTCやSAPなどと比較して私企業であり、リスク回避型の企業はベンダーの規模や安定性を心配することがあります。GAINSは約40年の歴史があり、安定していますが、最近は新しい投資と経営陣を受けており、規模を拡大するためと思われます。サポートと研究開発が強力であることを確認してください。私たちの調査では顕著な技術的な危険信号は現れませんでした - GAINSは、通常の注意事項を確認して、特定のニーズに適合するかどうかを確認するという点で、主張通りのものを提供しているようです。

Baxter Planning（現在はSTGの一部で、「Prophet by Baxter」という製品）

• 確率予測: Baxterのソリューションには、断続的需要に適した多くの決定論的および統計的手法を備えた予測エンジン が含まれています⁵³。これは、Baxterのアプローチが比較的古典的であることを示しています：おそらく予測モデルのライブラリ（不規則な需要のためのCroston法、滑らかな需要のための指数平滑化、おそらくインストールベース駆動の需要のための回帰など）を持っており、アイテムごとにどの方法を選択するかを選択または許可します。デフォルトでは完全な確率分布を出力しないかもしれません。代わりに、平均予測と変動の尺度（予測誤差や推奨安全在庫など）を出力するかもしれません。ただし、Baxterはまた、装置にリンクされた部品のための*「故障率ベース」*予測⁵⁴もサポートしています。つまり、ある部品があるMTBF（故障間平均時間）で故障することを知っている場合、Baxterはその装置のインストールベースから需要を計算できます。これ自体が確率的です（故障のためにしばしばポアソン過程を使用）。したがって、その領域では、Baxterは確かに確率モデルを使用しています。Baxterのツールが需要履歴とインストールベース情報を自動的に単一の分布に組み合わせるか、それらがプランナーが調整する別々の出力であるかは不明です。彼らの顧客（通信、IT部品など）を考慮すると、彼らはおそらく比較のために統計的予測と信頼性予測の両方を提供しています。Baxterの資料は「確率予測」としての機能を叫んでいませんが、これはToolsGroupやLokadほどネイティブに確率的ではないことを示しています。代わりに、信頼水準を設定することに頼るかもしれません（たとえば、安全在庫のために高いパーセンタイルを選択する）が、これは間接的に確率的なサービスレベルをもたらします。いずれにせよ、Baxterは断続的需要予測の基本をカバーしていますが、確率的サービスレベルを間接的に提供する代わりに、決定論的方法と安全在庫バッファに重点を置いているかもしれません。

• 在庫最適化アプローチ: Baxter PlanningはそのTCO（総所有コスト）最適化哲学で知られています⁵⁵。これは、在庫決定を行う際に、すべての関連するコスト（保有コスト、発注コスト、在庫切れ/ペナルティ、陳腐化など）を考慮し、合計を最小限に抑えようとすることを意味します。実際には、Baxterのソフトウェアを使用すると、在庫切れのコスト（おそらくSLA違反のペナルティや停止時間のコストを介して）と保有コストを入力できます。その後、システムは、これらをバランスさせる在庫レベルを推奨します。これは、定義上「経済最適化」です。Baxterの多くの顧客は、最低コストでサービス契約（SLA）を達成することを重視しており、Baxterのアプローチは、在庫をこれらのビジネスメトリクスに結びつけるため共鳴します⁵⁵。たとえば、「95%のフィル率を達成する」と言う代わりに、Baxterは「コストを最小限に抑えつつ、SLAに基づいて各在庫切れごとにペナルティを課す」と設定するかもしれません。最適化エンジンは、次の在庫切れを避けることがペナルティよりもコストがかかるポイントまで自然に避けようとします。出力は似ているかもしれません（おそらく約95%のフィルになるかもしれません）、が、ドライバーはコストであり、恣意的なパーセンテージではありません。Baxterは多階層計画をサポートしていますが、多くのクライアントはより単純なネットワーク（単一または二階層）を持っています⁵⁶。フィールド在庫レベルを最適化することができ、通常は各フォワード在庫場所を独立して考慮するか、中央からの基本的なプーリングを行います。クライアントがより複雑なネットワークを持っている場合、Baxterはそれでも対応できますが、ServigisticsやToolsGroup（そのようなもので知られている）ほど高度な多階層アルゴリズムを持っていないかもしれません。Baxterの強みの1つは資材返品およびデポ修理管理です。サービス部品では、部品が返品されて修理されることがあるため、Baxterのソリューションにはそれらの返品の計画が含まれています（これはMCAとともにそれを組み込んだ初期のツールの1つでした）。つまり、どれだけの予備品と修理パイプライン資産が必要かを決定することであり、これ自体が最適化の問題です。Baxterの最適化はおそらく単純なヒューリスティックスやローカル最適化を使用しており、大規模なLPやシミュレーションではなく、対象範囲に対して効果的です。別の注意点：Baxterはしばしば浅いネットワーク（使用地点在庫）と協力して作業するため、在庫を地域レベルで最適化することを強調しています。顧客がフォワード在庫場所のコスト最適化に焦点を当てていることを述べており、ネットワーク最適化よりも各場所を最適化することがBaxterの強みである可能性があります⁵⁷。これは、需要割り当てがある程度与えられた場合、各場所を最適化することが重要であり、多層数学よりも重要である環境では、問題ありません。

• 自動化＆スケーラビリティ: バクスターのソリューションは大規模企業によって使用されており、これは大規模なSKU数にスケーリングされていることを示しています。Servigisticsのように何十万ものSKUが一般的に引用されることはありませんが、おそらく5万以上の部品を適切に処理できるでしょう。多くのバクスターのクライアントは、バクスターの管理サービスを活用しています - バクスターのプランナーが計画を支援または完全に管理することを示しています ⁵⁸。これは、ソフトウェアが自動化の機能を持っていることを示しています（小さなバクスターチームでも、ツールを使用してクライアントの在庫を管理できる）。バクスターのシステムは自動的に補充注文を生成し、在庫の再バランスを推奨し、定期的に計画パラメータを更新できます。おそらく例外管理ダッシュボードを持っているでしょう。ただし、多くの予測手法を使用するアプローチから、適切な手法を設定したり、予測を見直したりするために、少しプランナーの介入が必要かもしれません。ToolsGroupやLokadほど「自動運転」ではないかもしれませんが、手動予測でもありません。バクスターの予測分析への新しい進出（ビジネスユニットのEntercoms買収を通じて）は、より多くの自動異常検出とAIを追加して手動作業を減らすことを示しています。たとえば、需要パターンの変化や部品の寿命終了間近を自動的に検出し、戦略の変更を提案するような機能を追加するかもしれません（プランナーが気づくのを待たずに）。自動化に関するポイント：バクスターは在庫をSLAとオペレーションに合わせることを強調しています - これはしばしばさまざまなビジネスユニット（サービスオペレーション、ファイナンス）からの入力を必要とします。バクスターのツールはおそらく、これらのポリシーをエンコードしてから、それを自動化します。地域で4時間の対応が必要なSLAがある場合、バクスターはその地域に十分な在庫を確保します。コストが高い場合、トレードオフを示すかもしれませんが、最終的にSLAが固定されている場合は、それに適合するように在庫を確保します。したがって、自動化はポリシードリブンです。また、バクスターのクライアントシステムとの統合には、サービス作業オーダーの読み取りやRMA（返品認証）データなどが含まれる可能性があり、これは手動プランナー作業なしに計画を通知する自動化されたデータフローです。まとめると、バクスターは計画プロセスの多くを自動化できますが、プランナーは戦略の設定や異常事象の処理には依然として重要です。計画サービスとして、バクスターは基本的に1人の人物がソフトウェアを介して多くを管理できることを実証しており、これはその効率性を示しています。

• 技術的深さ: バクスターのテクノロジーは、先進的なものよりも実用的と言えるかもしれません。サービス部品の計画のためのすべての基本機能をカバーしていますが、歴史的にAI/MLを重点的にマーケティングしていませんでした。製品「Prophet by Baxter」は、予測分析などの現代のテクノロジーを含むように進化しています。Entercomsの一部の買収（サービスサプライチェーン分析企業）は、おそらくいくつかの機械学習機能や高度な予測モデルを導入したか、開発中です（EntercomsはIoTと分析を使用した予防的なスペアパーツ管理などに特化していました）。したがって、バクスターは予測故障モデリング（SyncronやPTCが行うようなもの）のような機能を持っているか、開発中ですし、パラメータを最適化するためにMLを使用しているかもしれません。多くの予測手法を使用するコアエンジンは、やや古典的です（これはスマートコープのスマートなどのツールで使用されている従来のアプローチであり、プランナーにモデルのスイートを提供しています）。これは、統一された確率モデルよりも少し洗練されていないと見なす人もいるかもしれませんが、それはドメインエキスパートが信頼する方法を各部品タイプに適用できるようにします。バクスターの最適化はTCOを使用しており、カスタムアルゴリズムを示していますが、極めて複雑なものではないかもしれません - 在庫レベルを決定するために限界分析を使用するかもしれません（基本的に、限界コストが限界利益を超えるまで在庫を追加し続けます）。それは論理的で、コスト重視のアプローチですが、ファンシーなアルゴリズムではありません。それは、慎重に各部品に対して行われれば効果的です。バクスターのUIと分析は、アフターセールスサービスに合わせてカスタマイズされています - たとえば、補充率、修理の回転時間、地域ごとのSLA遵守などのメトリクスを追跡しています。彼らのレポートは、在庫の決定がこれらのメトリクスにどのように影響するかについての洞察を提供する可能性があり、これは技術的に貴重です（計画をサービスの結果に接続する）。統合では、バクスターはさまざまなERPとインターフェイスをしなければならず、時には1つの企業内で複数のインターフェイスを持っていることもあります。彼らは堅実なインターフェイスを構築する経験があり、スタンドアロンの計画ハブとして運用することさえあります。LokadのコーディングプラットフォームやToolsGroupのAIラボのような技術革新のレベルを持っていないかもしれませんが、バクスターはドメイン固有の機能（インストールベース管理、契約変更のためのシナリオ分析など）に深さを持っています。クライアントが箱から出たようなML予測や超知能的な自動化を期待する場合、バクスターは専門家が構成する必要があるツールキットを持っているかもしれません。ただし、バクスターはしばしば独自の専門家を派遣してその問題を軽減します。

• スパースで不規則な需要の取り扱い: Baxterの多くの予測手法へのサポートは、適切なモデルを選択することでさまざまな断続的なパターンを処理できることを意味します。おそらく、Croston法（断続的需要に特化したもの）やその派生形を実装または許可しているでしょう。非常に低いボリュームのアイテムに対しては、単純な移動平均を使用することもあります（時にはできることは過去の数件の非ゼロイベントを平均することです）。 Baxterのインストールベース予測への焦点は、不規則な需要に対する差別化要因です：需要履歴が乏しい場合でも、フィールドに1000台の機械があり、それぞれがその部品が必要となる確率が年間5％であることを知っている場合、昨年に消費されたのが2つだけであっても、年間50個の予測を生成できます。そのアプローチは、希薄な履歴だけを見るよりも需要をよりよく予測できる可能性があります。 Baxterはおそらく、サービスレベルの在庫保持を推奨しています（例：95％のサービスレベルの安全在庫を保持）。標準の安全在庫計算機能が含まれています。Lokadは安全在庫を時代遅れと考えるかもしれませんが、Baxterの典型的なユーザーはまだそのような考え方をしているため、ソフトウェアはそれをサポートしています。鍵は、Baxterが安全在庫をコストのトレードオフに結びつけていることです。おそらく、サービスレベル対在庫対コストの表やグラフを生成して、決定を支援することができます。 Blumレポートは、Baxterの顧客が特に前方在庫場所で在庫コストの最適化を重視していることに言及しています⁵⁷ - つまり、Baxterは、各場所でコストに焦点を当てることで、需要が断続的であっても最適化を行うことができます。非常に不規則で低使用頻度のアイテムに対しては、Baxterはおそらく保守的でしょう（たとえば、コストに応じて1つまたは0をストックすることを提案するかもしれません。期待される需要が年間0.3未満の場合、重要でない限りストックしないかもしれません）。これらのルールはシステムに組み込むことができます。 Baxterのツールはおそらく、「ゼロ需要」のアイテムをフラグ付けし、それでもストックされているかどうかを特定し、削減できるかどうかを判断するのに役立ちます（不動在庫の軽減）。逆に、アイテムが長い間需要がなかった後に需要があった場合、それが一過性であると仮定するか、新しいトレンドが現れるかどうかを監視するかを通知することができます。高度な機械学習がない場合、これらの多くはしきい値に基づいたり、プランナーのレビューに依存したりするかもしれませんが、Baxterの計画サービスチームはおそらくそのようなエッジケースを管理するための標準的な方法を持っています。要するに、Baxterは、古典的な断続的予測、ドメイン知識（故障率）、およびコストベースの論理を組み合わせて、在庫レベルを決定することで、不規則な需要に対処しており、効果的ですが、画期的ではありません。

• 統合とアーキテクチャ: Baxter Planningは現在、より大きなグループの一部となっています（Marlin Equityからのプライベートエクイティ投資を受け、2023年現在、他のサービスソフトウェアとともにSTGの下にあると思われます）。コア製品であるProphetはおそらく統一されています（買収の合成物ではなく - Entercomsの部分はおそらく予測分析のモジュールとして統合されました）。 Baxterは通常、SAP、OracleなどのERPと統合して、マスターデータとトランザクションデータを取得します。多くの顧客がSAPを使用している可能性があるため、Baxterはおそらく、SAP ERPを補完する専門のアドオンとして位置付けています（特にSAP SPPが苦戦した後、一部の企業はBaxterを導入しました）。アーキテクチャはクライアントサーバーまたはWebベース（おそらく現在はWebベース）で、中央データベースがあります。ベンダーが複数のテクノロジーを取得して統合していない場合、それは警告のサインです - Baxterの場合、Entercomsの買収だけが目立ちます。これは、予測オファリングを拡張することを目的とした小規模な買収であり、おそらくいくつかの機械学習IPを組み込むことに関連していたでしょう。 Baxterがそれを本当に統合したか、別の分析サービスとして提供しているかを確認する必要があります。別々の場合、それはわずかな統合のギャップかもしれません。 Baxterのソリューションは、従来はオンプレミスまたはホストされていましたが、現在ではおそらくクラウドのSaaSオプションがあります。新しいスタートアップが誇る超現代的なマイクロサービスアーキテクチャを持っていないかもしれませんが、信頼性とドメイン適合性がここではより重要です。企業が複数のサービスオペレーションやデータソースを持っている場合の潜在的な統合の課題は、Baxterのチームがその統合を支援することがよくあります。ユーザー管理に関しては、Baxterはしばしばクライアントのパートナーとして機能するため（一部のクライアントは一部の計画を彼らに外部委託しています）、システムはおそらく複数ユーザーの協力、意思決定の追跡、オーバーライドをサポートしています（そのため、Baxterのスタッフとクライアントのスタッフの両方がやり取りできます）。透明性にとってプラスです。

• 赤い旗/懐疑: Baxter Planningは多くの宣伝をしていません - 他の企業からの華やかなマーケティングと比較して、彼らはある程度地味です。注視すべき点の一つは、Baxterがサービスとして提供される可能性があるため、企業がBaxterの専門家に依存する可能性があることです。これは必ずしも悪いことではありません（Baxterが素晴らしい仕事をしている場合）、しかし、これは異なるモデルです。顧客がソフトウェアを購入してDIYすることを期待していた場合、それを構成するスキルがあるか、十分なトレーニングを受けるかを確認する必要があります。別のポイント：BaxterはTCO最適化を推進していますが、ユースケースを通じてその能力を検証する必要があります - 例えば、ソフトウェアが高コストと低利益のために部品を在庫に入れないように決定する方法を示してもらうか、サービスレベルだけを行っているのではないかを確認してください（つまり、最適化は自動的に行われるのか、プランナーがシナリオを反復する必要があるのか）。Baxterの比較的小さな規模は、グローバルサポートにとって懸念事項となる可能性がありますが、彼らはこのニッチで着実に成長しており、今では投資バックアップもあるため、リソースを持っている可能性が高いです。Baxterには顕著な「虚偽の主張」の問題は見られません。彼らは現実的である傾向があります。むしろ、彼らの機能の幅広さは大手企業よりも狭いです（彼らは製造計画やフィールドサービス管理などの分野に進出せず、コアサービス部品の計画問題に焦点を当てています）、しかし、それは意図的なものです。したがって、その狭い範囲がすべてのニーズをカバーしていることを確認してください（通常、予測と在庫計画はうまくいっていますが、例えば、統合価格最適化が必要な場合、BaxterにはSyncronやServigisticsのような価格ツールはありません）。オールインワンのアフターマーケットスイートが必要な企業にとっては、それが欠点になるかもしれませんが、多くの企業はBaxterを別の価格設定ツールと統合しています。

Syncron

• 確率的予測: Syncronはサービス部品の在庫予測を*「確率的AIモデル」*としてマーケティングしています⁵⁹。これは、基本的な予測を超えて需要の不確実性を捉えるためにAIを使用していることを意味します。ただし、おそらくSyncronのアプローチは、従来の断続的需要の方法と機械学習の強化を組み合わせています。例えば、Syncronはニューラルネットワークや勾配ブースティングモデルを使用して、多くの部品/顧客ケース全体のパターンから学習して、特定期間の需要の確率を予測するかもしれません。Syncronは主に多くの部品を持つOEMにサービスを提供しているため、多くの類似部品にわたるデータがあります。AIは、特定の特徴（使用率、機器の年齢など）を持つ部品が似たような断続的パターンを持つことを検出できます。Syncronは、アイテムを自動的に需要パターンに分類するためにMLを使用している可能性もあります（断続的パターンによるSKUのクラスタリング）。分類されたら、それぞれのクラスに最適な統計モデルを適用できるでしょう - それが「AI支援」の予測アプローチになります。内部知識がない場合、手がかりから推測する必要があります：Syncronのサイトでは「アイテムを動的に分類する」とシナリオ予測⁵⁹と言及しており、アイテムごとに適応するアルゴリズムを示唆しています。彼らはまた、Syncron Uptimeを介してIoTデータを組み込んでいます：つまり、IoTが故障の可能性を示す場合、Syncronはその部品の需要確率を調整できます。それは本質的に確率的です（センサーがトリガーされた場合、この部品が近いうちに必要になる可能性は70％です）。したがって、Syncronは、可能な限り予測に確率を活用しています。より簡単な側面では、Syncronはおそらくプランナー向けに予測平均値と提案された安全在庫（多くのツールと同様に）を提供しています。Syncronがフル分布を提供するか、モンテカルロを使用しているかは明確ではありません - 顧客へのメッセージングはしばしばサービスレベルの達成を参照しているため、出力がそれに合わせられていることを示唆しています（例：「95％のサービスを得るには、3ユニットを在庫に置く」）。したがって、Syncronはおそらく内部で確率的推論を使用していますが、ユーザーエクスペリエンスは、変動を考慮したガイド付き予測のように感じられるかもしれません。彼らは計画にシミュレーションの使用を奨励しており、彼らのマーケティングでは「戦略的シミュレーションと自動最適化」が、最小限の手動作業で行われることがよく言及されています⁶⁰。

• 在庫最適化アプローチ: Syncronの最適化は、歴史的には他社と同様に、最低コストでサービスレベルを満たすことを中心に行われてきました。多くのSyncronの顧客は、差別化されたサービスレベルの目標を設定しています（しばしば重要度マトリックスやPICS/VAU分析を通じて - これはPart Importance and Volume classの略です）⁶¹。Syncronのソフトウェアは、それらの目標を達成するための在庫ポリシーを最適化します。彼らは*「デュアルサービスレベル」などの概念を導入しました - 中央と現場それぞれに1つずつ - 世界的なサービスを確保しながら、地域的な在庫過剰を防ぎます。近年、Syncronは利益と廃棄物削減を強調しています（「廃棄物を作らずに利益を上げる」というキャッチフレーズ⁶²）。これは、経済的最適化と位置付けていることを示唆しています：在庫が価値を生み出す場所にのみ存在することを確認します。ただし、Syncronの既知の方法論はセグメンテーションとビジネスルールを多用しています。たとえば、彼らはしばしば顧客が部品を価値と重要度（たとえば、A、B、CのカテゴリとX、Y、Zの重要度）でセグメント化し、それぞれのセグメントに異なるサービスレベルの目標や再注文ポリシーを適用します。これはやや手動の最適化アプローチであり、純粋なアルゴリズムによるグローバル最適化よりも専門家のルールに依存しています。それにもかかわらず、各セグメント内では、Syncronは伝統的な数式やシミュレーションを使用して再注文ポイント/注文数量を最適化できます。Syncron Inventoryは多階層をある程度扱います（特に中央倉庫→地域→ディーラーネットワーク）。ディーラー在庫のためのモジュールSyncron Retailを持っており、おそらく中央の在庫計画と調整されているでしょう⁶³。また、移動対調達の決定を考慮しています - たとえば、可能であれば1つの場所から余剰を移動して他の場所の需要を満たすことを提案する、これは最適化のステップです。Syncronの注目すべき焦点の1つはグローバルプランニング対ローカルプランニングです。Syncronを使用することで、企業は各地域が独立して計画を立てるのではなく、グローバルに最適化できると宣伝しています。これはおそらく、最適化を実行して全地域の在庫をバランスよく配置し、最適なサービスを提供することを意味します。Syncronの経済的最適化は、LokadのROIやGAINSのコスト最小化のように数学的に明確ではないかもしれませんが、在庫切れコスト設定などの機能には存在しています。ユーザーがコストを入力すると、Syncronはそれを考慮に入れます。わずかな違いは、Syncronがしばしば可用性（稼働時間）を主要な目標として提示していることです。つまり、最小限の在庫でX％の稼働時間を確保すると言うかもしれません。実際には、それはサービスレベルと同じですが、設備の稼働時間として表現されています。Syncronの幅広いスイートを考慮すると、彼らは在庫最適化を価格設定に結びつけています - たとえば、競合他社がめったに在庫を置かない部品の場合、高いサービスの差別化による価格引き上げを提案するかもしれません⁶¹。これはビジネス戦略の結果ですが、Syncronの包括的な視点を示しています（在庫だけではなく、価格設定や顧客価値と相互作用します）。全体として、Syncronの最適化は堅実ですが、ToolsGroupやServigisticsのような純粋なアルゴリズムよりもヒューリスティック/セグメンテーション駆動*の可能性があります。

• 自動化＆スケーラビリティ: Syncronは、そのシステムが*「例外管理、戦略的シミュレーション、自動最適化に向けてアクションを起こす」* ⁶⁰ と述べており、最小限の手動入力で高度な自動化を示しています。多くのSyncronの展開では、プランナーが例外によって管理できるようになっています：システムは購買依頼書を生成し、再バランス提案を行い、目標を達成できないアイテムを特定します。その後、プランナーはそれらの提案を確認するか、例外の原因を調査するだけです。Syncronのスケーラビリティは、大手OEM企業の顧客基盤によって示されています（カタログに何百万ものサービス部品が含まれている企業もありますが、通常はすべてがアクティブではありません）。クラウド専用の展開が役立ちます - SyncronはSaaSモデルで実行されているため、必要に応じてコンピューティングをスケーリングできます。彼らはAIモデルを使用して「何百万もの部品ロケーションの組み合わせ」を処理していると述べています⁵⁹、これはビッグデータ処理を行っていることを意味します（おそらくMLアルゴリズムのために分散コンピューティングを行っている可能性があります）。ユーザーはその複雑さを管理する必要はありません、すべてが裏で行われています。また、Syncronはデータ統合タスクも自動化しています - たとえば、ERPからの日次または週次データフィードを自動的にクリーニングしています（外れ値をクレンジングしたり、欠落しているリードタイムを埋めたりするためにAIが使用されるかもしれません）。さらに、Syncronはフィールドサービス管理とIoTも提供しているため（Mizeを買収し、Uptimeを開発した後）、外部イベントから部品供給アクションをトリガーする自動化も行っています。たとえば、Syncron Uptimeがブラジルの機械で10日後に故障が予測される場合、システムは自動的にその部品がブラジルのデポに在庫されるか、急送されるかを確認するかもしれません。そのクロスモジュールの自動化は、完全に実現されればユニークな能力です。Syncronのディーラー在庫モジュールは、協力を自動化していることを示唆しています - 中央プランナーはディーラーの在庫レベルを見ることができ、ディーラーの注文を待つのではなく、在庫を自動的に移動させることができます。人員の観点から、Syncronの提案は、企業が彼らのソフトウェアを使用して比較的少数のチームでグローバルなサービス部品を管理できるというものです。多くのユーザーは、Syncronが消火活動を減らすのに役立つと評価しています - システムは高いサービスレベルを確保するため、プランナーが頻繁に慌てる必要がなくなります。

• 技術的深さ: Syncronは技術スタックの詳細についてはあまり公開していませんが、明らかにAIとIoTを活用した近代化に投資しています。SyncronのAIには、予測のための機械学習モデル（使用状況などの回帰要因によって補完された時系列モデル、またはパターン認識のためのディープラーニングなど）が含まれるでしょう。彼らはまた、AIをパラメーターチューニングに使用するかもしれません - たとえば、リードタイム分布を自動的に特定したり、部品を季節的と非季節的に分類したりすることがあります。Syncronの別々のモジュール（在庫、価格、アップタイム）は、マイクロサービスまたはモジュラーアーキテクチャを示唆しており、それぞれが専門化されています。欠点としては、在庫と価格が別々のデータベースを持っていたことが指摘されています⁶⁴、つまり元々単一のプラットフォーム上に構築されておらず、統合する必要があったということです。これは、Syncron Priceが買収から来たものであるか、異なる技術で後から開発されたものである可能性があります。完全に統一されていない場合、いくつかの非効率性を引き起こす可能性があります（たとえば、両者の間でマスターデータを同期する必要があるなど）。Syncronは将来のバージョンでこれに対処する可能性がありますが、現時点では考慮事項です。在庫の面だけで、Syncronは「この部品グループのサービスレベルを上げた場合はどうなるか？」などのシミュレーションを行うための深い機能を持っています。これには高速計算エンジンが必要です - Syncronはおそらく迅速なシミュレーションを可能にするために多くの応答曲線を事前計算しているでしょう（在庫対サービス曲線の概念に類似）。IoT（アップタイム）に関して、Syncronの技術は機器データを読み取り、予測モデルを適用（機械学習の異常検出やルールベースのトリガーなど）、部品の必要性が特定された場合、それを在庫システムにフィードします。ここでの洗練さは、センサーデータを部品需要信号に変換することにあります - Syncronは、Uptimeの開発からその専門知識を持っています（これはPTCのThingWorx + Servigisticsアプローチと並行しています）。もう1つの技術的なポイント：Syncronはクラウド専用のマルチテナントSaaSを推進してきました。これは、すべての顧客が最新のコードベースで実行されることを意味し、改善サイクルが速くなりますが、クライアントごとのカスタマイズが少なくなるということでもあります（Lokadのコード自体を書くモデルとは対照的に、Syncronはより標準化されています。カスタムニーズは構成によって処理しますが、クライアントごとにコードを変更するわけではありません）。SyncronにDSLやユーザー拡張可能なコードがあるとは思われませんが、代わりにUIで戦略を調整するための設定とオプションを提供しています。たとえば、ユーザーはサービスレベルを変更したり、分類のしきい値を変更したりできますが、独自のアルゴリズムを簡単に挿入することはできません。これはSaaS製品にとって典型的ですが、技術はさまざまなニーズを組み込んでおく必要があります。

• スパースで不規則な需要の取り扱い: Syncronのアプローチは歴史的にセグメント化とバッファリングでした。彼らは部品を需要の不安定性と重要度で分類する可能性が高いです。純粋に不規則な部品の場合、Syncronはしばしば*「ゼロまたはワン」戦略を推奨します：それが十分に重要であればユニットを在庫に入れるか（在庫がない場合のコストが保持するコストよりも高い場合）、そうでない場合は在庫を入れないか、ということです。たとえば、年間0.2個の平均を予測することは意味がありません。これは基本的には経済的な決定であり、ルールとして偽装されています（それを持っていないコストが数年間保持するコストよりも高い場合は在庫を保持します）。Syncronの新しいAIは、不規則な需要全体でパターンを特定することでより良い結果を出すかもしれません。しかし、パターンがない場合、Syncronは安全在庫ロジックに頼ることになります：たとえば、サービスレベルを設定し、それによって計算される在庫レベルを設定することができます。平均需要が0.2であっても、在庫レベルが0よりも大きくなる可能性があります。彼らはそれにリードタイムを組み込んでいます - 不規則な需要と長いリードタイムがある場合、手元に1つ保持することが正当化されることがよくあります。ツールは、サービス目標が高い場合に1つ手元に保持することを示唆するでしょう。Syncronが強調するもう一つのことは、部品需要の因果要因です：たとえば、機器の使用や今後のサービスキャンペーンが不規則な部品需要を引き起こす可能性があります。Syncronは、そのような情報を計画に取り込むことを奨励しています（彼らのシステムは手動の予測調整や追加の需要ドライバーを受け入れることができます）。彼らのUptimeモジュールが特定の故障モードのトレンドを検出した場合、在庫計画を適切に調整するための情報提供ができます。これは原因がある不規則な需要を処理する積極的な方法です。ただし、本当にランダムな需要の場合、唯一の治療法はバッファであり、Syncronはそれを知っています。彼らは「外れ値の削除」に依存しているのでしょうか？おそらく明示的にはそうではないでしょう。大きな需要の急増はおそらく手動で調査されるか、特別なイベントとして扱われるでしょう。ただし、予測に盲目的に含めるのではなく。Syncronはおそらく、特定のケース（たとえば、OEMがリコールによって多くの部品が必要になることを知っている場合）のために手動予測またはオーバーライド*を設定することを許可しています。したがって、取り扱いは自動分類と例外的なイベントのための人間との連携の組み合わせです。Blum氏の報告でSyncronが価格設定とサービタイゼーションをリードしており、予測が二の次であることを示唆している⁶⁵ことは、Syncronの新しい洒落た予測に対する研究がそれほど優先されていない可能性があることを意味しています。したがって、彼らはおそらくよく知られた方法（Croston、ブートストラップなど）をいくつかのAIと調整したものに頼っているかもしれませんが、他の企業と大きく異なるものではありません。

• 統合とアーキテクチャ: SaaSとしてのSyncronは、顧客のERP（SAP、Oracleなど）と通常は安全なデータ交換またはAPIを介して統合する必要があります。多くの大手OEMは、たとえばSAPとSyncronを統合して、アイテムマスターや在庫状況を取得し、計画された注文を返送することがあります。これはSyncronプロジェクトの標準的な部分です。モジュール化されたアーキテクチャ（在庫、価格など）は、それらのモジュールが定義されたインターフェースを介して互いに通信することを意味します。価格用に別個のデータベースがあることは、データの重複やモジュール間で部品番号などを同期する必要があることを意味し、実装中に痛みを伴うことがあります。おそらくSyncronは、最終的にこれらをバックグラウンドで統一するか（またはすべてのモジュールに統一されたデータレイクを提供するか）でしょう。顧客が複数のSyncronモジュールを使用している場合、それらがどのように接続されているかを明確にすることが重要です - たとえば、価格の変更が在庫最適化ロジック（価格が引き上げられると予測需要が下がる可能性がある）を自動的に更新するかどうか。それとも、基本的にユーザーが調整する必要がある独立した機能なのでしょうか？その統合の成熟度は確認するべき点です。買収: SyncronはMize（フィールドサービス管理）を買収しました - これは在庫最適化に直接影響を与えることはないでしょうが、より多くのデータ（たとえば、部品使用を示すサービスチケットデータ）を提供する可能性があります。統合されれば、完全なクローズドループを提供できるかもしれません：部品の使用→在庫の減少→資産への記録→可能な補充のトリガー。それが実現すれば強力です。Syncronは資金調達を行い、おそらく他の小規模企業と合併した（SyncronとMizeの取引を思い出しますが、いくつかの提携もあります）。これまでに、大きな分断が示唆されるものは何もありませんが、価格DBの問題が1つあります。見込み客にとって、重要な統合の質問は次のとおりです：Syncron Inventoryを既存のIT環境に簡単に接続できますか？通常ははい、他の企業もそれを行っています - ただし、特定のシステムのサポートが確実であることを確認してください（一部の古いERPや自社開発システムはカスタム作業が必要かもしれません）。

• 赤い旗/ベンダーの主張: Syncronの主張は通常、サービタイゼーションの実現、サービスレベルの向上などに関連しています。Syncronを使用して在庫を少なくして98％の可用性を達成した企業の事例があります。これらは信憑性がありますが、どれだけがツールであり、どれだけがプロセスであるかを分離することは難しいです。健全な懐疑心：SyncronにAIの技術的証拠を求める - たとえば、彼らのAIが単純な方法よりもX％優れた予測を行った例など。 「唯一の目的に特化したAIパワードサービスパーツソフトウェア」といったマーケティングフレーズは、競合他社が「唯一」の部分を否定する可能性があるため、一定の懐疑心を持って受け取ることができます。バズワードに関して：「需要感知」 - Syncronは私の知識ではマーケティングでその用語を明示的に使用していない（需要感知は高速移動型サプライチェーンでより一般的です）、したがって、ここでは赤い旗ではありません。 「プラグアンドプレイ」 - SaaSであるSyncronは、より迅速な展開を意味するかもしれませんが、重工業のクライアントでは、データのクレンジングのために真にプラグアンドプレイではありません。 Syncronを含むベンダーが統合が簡単だと言っている場合は注意が必要です。ユーザーエクスペリエンスでは、データをマッピングしてクリーニングするのにかなりの努力が必要であると述べられることがよくあります。 もう1つの潜在的な赤い旗：Syncronが価格設定と稼働時間に重点を置いていることは、彼らの研究開発が分かれている可能性があり、最高の在庫アルゴリズムを作ることに100％集中しているわけではないかもしれませんが、これらの他の分野にも注力している可能性があります。 顧客が在庫最適化の卓越性だけを気にしている場合、Syncronの在庫モジュールだけがToolsGroupやGAINSのように強力であるかどうかを評価する必要があります。 Syncronの競争上の利点は全体のスイート（在庫+価格設定+フィールドサービス）を提供していることなので、そのスイートは全体的な価値に優れているかもしれません（すべてのアフターマーケットレバーを1か所で管理できます）、しかし、個々の専門家が1つの分野で彼らを打ち負かす可能性があります。 最終的な注意：Syncron Inventoryは歴史的にパラメーターの注意深い調整を必要としました（分類のしきい値、レビュー期間など）。 誤って構成されると、結果が失望する可能性があります。 したがって、それは魔法の箱ではなく、ユーザーまたはコンサルタントは正しく設定するための事前作業を行う必要があります。 これらのパラメーターが時間とともに適応できるかどうか（AIまたはルールで）を確認することは、システムが静的にならないようにするために確認する必要があります。

Blue Yonder (JDA)

• 確率予測: Blue Yonderのルーツには、サプライチェーンソフトウェアの古巨頭であるManugisticsとi2 Technologies、そして最近では需要計画のためのAIスタートアップであるBlue Yonder（AIスタートアップ）を買収したことが含まれます。 現在の形では、Blue Yonder Luminateは需要予測に機械学習を使用しており、確率予測を生成することができます。 特に、Blue YonderにはLuminate Demand Edgeという製品があり、高速消費財のための確率的な短期予測を生成します。 スペアパーツに関して、Blue Yonderには**「高度な在庫最適化」*モジュールがあり、これは歴史的に（JDA時代から）確率的最適化アプローチを使用しており、要求の分布をリードタイムにわたって計算し（通常は正規分布またはポアソン分布と仮定される）、在庫を最適化します。 Blue Yonderはおそらく信頼区間またはサービスレベル曲線を出力できるが、標準的なもの以外のアイテムごとのカスタム分布を提供するかどうかはわからない。 ただし、業界のトレンドから、Blue YonderはおそらくML予測から需要分布を取り込むために在庫最適化エンジンを更新しました。 Blue Yonderの需要計画が確率分布（または少なくとも範囲とエラーメトリクス）を生成する場合、在庫最適化はそれを活用して安全在庫をより賢く設定できます。 Blue Yonderにはi2時代からの多段階シミュレーション能力もあります - 彼らは需要の変動とサプライネットワークを通じた伝播をシミュレートできます。 したがって、確率的な概念はそこにありますが、Blue Yonderはスペアパーツのコンテキストでそれを強調することはないかもしれません。 代わりに、彼らは間接的に不確かな結果をカバーする「シナリオプランニング」や「what-if分析」*について話すかもしれません。 要するに、Blue Yonderのスペアパーツの予測は優れており、現代のアルゴリズムを使用していますが、専門のベンダーほど明示的に確率的で断続的な需要に合わせて調整されているとは限りません。 それは、生産部品や販売などを予測するエンジンと同じエンジンに依存している可能性があり、単に異なるチューニングが施されているだけです。

• 在庫最適化アプローチ: Blue Yonderは、サプライチェーンプランニングスイートの一部として、単一階層および多階層の在庫最適化を提供しています。最適化は通常、在庫を最小限に抑えながら望ましい顧客サービスレベルを達成することを目指しています。Blue Yonderのアプローチは、ネットワーク全体でサービスレベルの制約条件に従った総在庫を最小化する数学的最適化モデルを解くことが多く、必要に応じて多階層理論を使用します。固定された在庫予算に対してサービスを最大化する逆のアプローチも取ることができます。ソリューションは、各SKUごとの各ロケーションでの安全在庫または再発注ポイントを提案します。Blue Yonderは、通常（JDAとして）ユーザーによるアイテムまたはグループごとのサービスレベル目標の入力を求めていました。Aアイテム99％、Bアイテム95％などのセグメントでの差別化機能があります。そのため、それが設定されていない限り、各アイテムごとにROIを計算することはありません。しかし、Blue Yonderの強みは広範な計画統合にあります：在庫最適化を供給計画と結びつけることができるため、それらの在庫目標がサプライヤーの容量などと実現可能であることを確認します。特にスペアパーツに関しては、Blue Yonderには修理計画機能もあります（これは以前のJDAサービスパーツ計画ソリューションから来ています）。これは、修理するタイミングと新品を購入するタイミングを調整し、在庫状況を考慮します。その最適化は、よりルールベースです（経済的な修理対置換のしきい値を設定します）。Blue Yonderのネットワーク最適化機能は、スペアパーツがしばしば持つ大規模で複雑な流通ネットワークを処理できます。ユーザーがそれを十分に活用すれば、1つの倉庫から別の倉庫に在庫を再バランスさせることがグローバルサービスにどのように影響するかを見るなどのことができます。Blue Yonderのツールはそのような移動を特定できます。経済的には、Blue Yonderのソリューションは、コスト（バックオーダーコスト、保有コストなど）を絶対に組み込むことができます（コスト最小化モードを使用することを選択した場合）。ただし、多くのJDAの実装は、プランナーが考える方法であるため、サービスレベルツールとして使用することにとどまりました。ただし、構成されていれば、コスト目標を最小限に抑えることができます。1つの欠点：Blue Yonderには、例えばSLAペナルティやダウンタイムコストなどの組み込みの知識がないため、ユーザーはそれらを入力する必要があります。したがって、コストを正しくモデル化するために投資する努力に応じて、経済最適化においてそれほど優れているとは言えません。

• 自動化とスケーラビリティ: Blue Yonderのソリューションは多くのフォーチュン500社によって使用されているため、スケールは一般的に問題ありません。彼らは小売業で膨大なデータセットを処理しています（数千万のSKU-店舗の組み合わせ）。スペアパーツに関しては、ボリュームは小さいかもしれませんが、依然として大きい（多くのデポを持つ大手OEMの場合、数百万の組み合わせまであり得ます）、特に彼らのクラウドインフラストラクチャーでは、Blue Yonderはそれを管理できます。自動化の観点から、Blue Yonderは、更新された予測と在庫目標を生成するためにスケジュールで実行できるエンジンを提供しています。その結果は、ERPに供給される自動補充提案をトリガーすることができます。ただし、Blue Yonderは広範なツールであるため、通常はより多くの監視と調整が必要です。プランナーは、データが正しいことを確認したり、予測モデルを調整したりするために引き続き対話するかもしれません（Blue Yonderの従来の需要計画では、通常、手動でモデルの選択やパラメータの調整が必要でしたが、新しいLuminate AIがそれを削減するかもしれません）。自動化のレベルは、実装によって異なる場合があります：一部の企業は、自動実行のために注文システムと統合し、予測の承認や計画の受け入れについては人間をループに保持しました。現代のBlue Yonderは、AI予測と自動最適化ループを備えたより多くの自律性を推進しています。ただし、Blue Yonderは、スペアパーツに関しては、Syncronのような専門ツールよりも少し多くの監視が必要かもしれません（Blue Yonderにはすべてのスペアパーツ固有のロジックが事前に組み込まれていないため（エンドオブライフの部品の扱い方などを構成する必要があるかもしれません）、ニッチなツールには専用の設定があるかもしれません）。それでも、構成されると、在庫最適化プログラムは定期的に推奨在庫レベルを自動的に再計算します。そして、Blue Yonderの例外管理は、範囲外のアイテムをフラグ付けできます（実際のサービスが目標を下回っている傾向がある場合、それをフラグ付けしてアクションを促します）。Blue Yonderは、サプライヤーやバイヤーにアラートが送信されるなど、コラボレーションワークフローをサポートしています（何か注意が必要な場合）。また、Blue YonderはBlue YonderのS&OPと統合されているため、新製品の導入や廃止などの戦略的変更が在庫計画に自動的に反映されます。その広範な統合は、戦略的計画と戦術的計画をリンクする自動化の形態です。

• 技術的深さ: Blue Yonder（企業）は、パナソニックによる買収後と以前のBlue Yonder AIの後にAI/MLに大きく投資してきました。彼らはデータサイエンスチームを持ち、需要感知のための小売り、ダイナミックセグメンテーション、計画の異常検出など、さまざまな場所にMLを組み込んできました。サービス部品に関しては、興味深い技術的要素の1つはLuminate Control Towerです。これはリアルタイムの可視化および計画ツールです。リアルタイムのイベント（需要の急増や出荷の遅延など）を受け取り、在庫の再計画や即座の緩和策の提案を行うことができます。これはサプライチェーンの最先端技術です（ML駆動のインサイトを持つコントロールタワーのようなもの）。文脈において、たとえば、あるデポが供給の遅延により在庫切れのリスクにさらされていることをスペアパーツプランナーが見るのを助け、その後、自動的に緊急発送や再割り当てを提案することができます。これは、従来の計画ツールが次のバッチ実行まで行わないことです。プラットフォームの深さは、最適化ソルバーでも明らかです。Blue Yonderは、Manugisticsの系譜から強力な最適化アルゴリズムを持っています（大規模な線形および非線形の問題を解決してきました）。彼らはおそらく、大規模な混合整数プログラムなどの多段階在庫最適化を解決するためにこれらを使用しています（一部のベンダーはシミュレートし、一部は数理プログラミングを介して解決しますが、Blue YonderはORのルーツを考慮すると数理プログラミングアプローチを取っている可能性が高いです）。Blue Yonderの技術は幅広い領域をカバーしています。たとえば、多言語対応、クラウド展開、高いセキュリティ（一部のクライアントにとって重要）、ユーザーフレンドリーなダッシュボードなどです。ただし、広範囲にわたるため、複雑さも伴います。Blue Yonderのソリューションは、ときには「計画のためのERP」のように感じられることがあります。多くの構成テーブル、マスターデータの要件があり、それらのすべてがスペアパーツに関連するわけではありません。それは圧倒的です。技術的な哲学は、Lokadのようなリーンスタートアップとは異なります。Blue Yonderは構成可能なモジュールを備えた包括的なプラットフォームを提供していますが、Lokadはカスタマイズされたモデリングプラットフォームを提供しています。Blue Yonderの方が重いですが、標準化されています。彼らはサプライチェーン最適化に関するいくつかの特許も保有していますが、それらはその価値に基づいて評価すべきです。（たとえば、多段階最適化の特定のアルゴリズムや予測技術に特許を取得しているかもしれませんが、それは必ずしも他の人が異なる方法で同様のことをしていないということではありません。）

• スパースで不規則な需要の取り扱い: Blue Yonderは断続的な需要を処理できますが、調整が必要かもしれません。歴史的に、JDAは低頻度アイテムの需要計画にCroston法を実装していました。また、「集約してから分解する」という技術もありました。たとえば、あるSKUのデータが予測するにはあまりにもまばらすぎる場合、より高いレベル（製品ファミリーなど）で予測し、SKUに比例して割り当てることがありました。これは、非常に異なる振る舞いをするサービス部品には理想的ではありませんが、利用可能な技術です。MLを使用すると、Blue Yonderは外部信号としてフリート利用データや気象などのマクロ要因を使用して、より良いシグナルを見つける可能性があります。ただし、デフォルトでは、断続的な歴史的需要のみが与えられた場合、Blue Yonderの予測は通常、「ほとんどの時間が0、時折1」となり、平均は分数で、分散が高くなります。その後、在庫最適化が在庫を確保します。Blue Yonderの不規則なアイテムの在庫最適化は、基本的にポアソンの仮定に基づいて安全在庫を計算するか、リードタイム中の需要の高いパーセンタイルを単純に使用します。たとえば、アイテムが通常1年に0または1を見る場合、リードタイムが90日である場合、そのリードタイムで0または1を想定し、95%のサービスを提供したい場合、安全在庫として1をストックします。これは合理的な結果ですが、その背後にあるモデルは、たとえばToolsGroupのモンテカルロよりも単純で仮定に基づいている可能性があります。ただし、Blue Yonderの利点は、既知の確率や分布がある場合、それをしばしば構成できることです。ただし、自動化されていない場合もあります。プランナーは、奇妙なアイテムの予測パラメータを手動で調整する必要があるかもしれません。Blue Yonderは、エンドオブライフや後継予測には特化していません。特化したベンダーは、通常、需要のベイジアン結合によって部品の後継を自動的に処理します。Blue Yonderはそれを行うことができますが、ツール内のアイテムを「段階的に導入/段階的に廃止」としてリンク設定するなどの設定が必要かもしれません。その後、需要を段階的に処理します。したがって、それは可能ですが、努力が必要です。真にランダムでまれな需要の場合、Blue Yonderは在庫ポリシー（最小=1 最大=1タイプのポリシーなど）に依存します。適切な場合、オプティマイザーが推奨します。1つの良い点は、Blue Yonderのツールがレビュー期間を最適化できることです。非常に遅い部品の場合、四半期ごとのチェックを提案するかもしれません。全体的に、Blue Yonderは、大規模なSCPスイートができるだけうまく断続的な需要に対処できますが、より専門化されたアプローチほど高いサービスを提供し、低い在庫を持つことができないかもしれません。それは、すべての単一のアイテムの分布の微妙なニュアンスを捉えることができない可能性があるため、かなりの構成が必要です。実際には、一部の企業は主要な在庫アイテムにBlue Yonderを使用し、非常にまれで重要なスペアパーツをいくつか手動で計画したり、別個のロジックで計画したりしています（それらは特別な注意が必要な場合があるため、例えば、条件付きメンテナンスなど、Blue Yonderが統合しない場合）。

• 統合とアーキテクチャ: Blue Yonderのプラットフォームは広範囲であり、統合ポイントが多数あります。スペアパーツの場合、ERP（在庫と注文のため）とおそらくEAM（エンタープライズアセット管理、アセットデータのため）との統合が必要になるかもしれません。Blue Yonderには主要なERP用の標準アダプターがありますが、それらは会社固有のデータ構造にカスタマイズが必要な場合があります。Blue Yonderは、より大きな計画スイートの一部として提供されており、モジュール間の内部統合（需要、在庫、供給計画）はネイティブであるため、利点があります（すべてのモジュールが中央データベースで同じデータモデルを共有しています）。Blue Yonderは現在、SaaSとして提供されており（通常はAzureベース）、インフラ負担が軽減されていますが、クラウドへの安全なデータパイプラインが必要です。買収に関して、Blue Yonder（JDA）は過去に多くの企業を買収しましたが、それらを統一しています。同じ名前のAI企業を買収した後のBlue Yonderへの改名は、彼らが1つの現代的なアーキテクチャの下で統合していることを示す声明でもありました。ただし、一部のモジュールは、古いコードベースからの統合されたコモンインターフェースを介してまだ存在するかもしれません。たとえば、コアの在庫最適化は、新しいUIが統一されている一方で、レガシーコンポーネントからのコードを使用しているかもしれません。それが正しく行われていれば、通常、エンドユーザーには関係ありません。Blue Yonderを検討している企業は、それが包括的なソリューションであることを認識すべきです。スペアパーツだけのために購入する場合、機能の一部しか使用していないと感じるかもしれず、不要な複雑さを引きずることになります。ただし、製造計画や販売予測にも使用する予定であれば、1つの統合環境として有益です。サービス部品のためにBlue Yonderを実装する統合作業は、焦点を当てたソリューションと比較して高いかもしれませんので、ROIを考慮する必要があります。

• 赤い旗/懐疑: 歴史的に、これらの大規模なスイートの実装の難しさは主要な懸念事項でした。SAPの場合、複雑なソリューションは扱いにくすぎると失敗する可能性があります。Blue YonderはSAP SPPよりも良い実績を持っていますが、JDAサービスパーツプランニングが完全に採用されなかったケースや、構成が間違っていたために期待通りの結果が得られなかったケースもあります。そのリスクを軽減するために、Blue Yonderは今ではその実績のあるテンプレートとAI支援を推進していますが、懐疑は正当です：実装者が断続的な需要に適切に構成するように確認してください（通常の需要計画プロジェクトのように扱うと構成を誤る可能性があります）。また、Blue YonderはAIに関してグロッシーなマーケティングを行っています（例えば、「在庫をX削減するAIによる自律計画」などと言うかもしれません）。自分のユースケースに特化した証拠やパイロット結果を要求すべきです。プラットフォームの柔軟性は弱点にもなり得ます - 一部のGartner Peer Insightsのレビューでは、JDA/Blue Yonderのユーザーインターフェースが複雑であり、ソリューションが「あまりにも豊富」であると指摘されています。つまり、使用しない複雑さに対処するために支払い、取り扱う必要があります。ベンダー（またはSIパートナー）が販売時に、Blue Yonderはテンプレートを持っているので最小限の構成で簡単に起動できると言っている場合、注意が必要です - テンプレートは役立ちますが、すべてのサービスサプライチェーンにはカスタマイズが必要な固有の属性があります。技術的な側面では、Blue Yonderの多段階在庫最適化がどのような単純化の仮定（例えば、場所間の独立需要や正規性を仮定するなど）を行っているかを確認すべきです - 以前のツールの一部は、より速く解決するためにそれを行っていました。そのような場合、非常に偏った需要分布に対して制約となる可能性があります。Blue Yonderは今ではより優れた計算能力でこれを克服しているかもしれませんが、それは尋ねるべき質問です。ベンダーの主張に関しては、Blue Yonderはおそらく「X社がフィル率を10%向上させ、在庫を20%削減した」といった参照を持っているでしょう - それは良いですが、それが主に実装中に多くの余剰在庫をクレンジングするなどのプロセス改善からほとんど得られたものであるかどうかを検証してください（これはソフトウェアの継続的なアルゴリズムから直接的にではない一時的な利益です）。

(要約すると、Blue Yonderは信頼性があり幅広いですが、スペアパーツの最先端の結果を得るには、企業はその広範なツールキットの適切な部分だけを注意深く選択して使用する必要があります。より広範な計画プロセスとの統合を望む人にとっては安全な選択肢ですが、スペアパーツの最適化技術自体においては必ずしも絶対的な先駆者ではありません。)

SAP SPP / ERP および Oracle

(ランキングでSAPとOracleを取り上げ、それらの制限を強調しました。それらについての詳細な技術的調査は、SAPのSPPがServigisticsのようになろうとしましたが、過度に複雑な設計と柔軟性の欠如のために失敗したことを主に繰り返すでしょう^{19 20}。Oracleのソリューションは技術的にはそれほど野心的ではなく（Oracleの既存の計画の拡張のようなもので、一部の部品向けの機能が追加されています）、一般的に革新をリードしていません。どちらも安全在庫や基本的な確率モデルを用いた確定的計画に依存しており、このニッチ向けのAIへの投資は専門のベンダーほど積極的ではありません。安全な結論：企業がSAPまたはOracle ERPを使用している場合、基本的なニーズには組み込みツールを使用することを検討するかもしれませんが、私たちの基準で定義される真の最適化のためには、これらは不十分です。)

マーケットトレンド＆観察

スペアパーツ最適化ソフトウェアの状況は進化しており、いくつかの注目すべきトレンドがあります：

• 確定的から確率的な計画への移行: 全体的に、確率的手法への明確な移行が見られます。ベンダーと顧客の両方が、伝統的な確定的予測（静的安全在庫を持つ単一の数値）が塊状で予測不可能なスペアパーツ需要には不十分であると認識しています。ToolsGroupは明示的に、確率的予測を長尾アイテムにとって不可欠としています³、他のベンダーもそれに続いています。今や、従来の保守的なベンダーでさえ、マーケティングで「AI駆動」または「確率的」モデルを主張しています。このトレンドは実在します - ほとんどの主要ツールは今や需要分布、モンテカルロシミュレーション、またはシナリオ分析を組み込んで不確実性を捉えています。違いは、それをどれだけ正直かつ深く行っているかにあります。真実を求める購入者は、各ベンダーにその確率論理をデモンストレーションしてもらうべきです（例えば、この例の部品の需要の確率分布を示し、ソフトウェアがそれをどのように最適化するかを示してください）。単一の数値しか提供できず、それを取り巻くだけの人は、おそらく新しいパラダイムを真に受け入れていないかもしれません、トレンドにもかかわらず。

• サービスレベルから経済最適化へ： サービスレベルの目標による管理から期待されるコスト対利益による管理への明確な転換が見られます。これは哲学的な変化です。多くのベンダーは過去にサービス目標を設定し、それに到達するために最適化していました。しかし、今では、リーダー（例：Lokad、GAINS、Baxter）は問題をドルで定義することを推進しています - 在庫コストとダウンタイムまたはSLA違反のペナルティをバランスさせること ^{55 1}。これにより、在庫の意思決定が直接財務成果に結びつき、経営者に共鳴します。部品ごとの欠品コストを指定したり、価値貢献に基づいてSKUごとに最適なサービスレベルを計算したりする機能が見られます。市場のトレンド：一部のアイテムに対しては過剰になり、他のアイテムに対しては不足する可能性がある一般的なサービス目標にうんざりしている企業が増えています。コスト対効果を最適化できるソフトウェアが好まれるようになっています。ただし、多くの組織はまだサービスメトリクスの観点で考えているため、ソフトウェアはしばしば両方のモードを提供しています。しかし、最先端は明らかにROIベースの最適化に向かっています。

• AI/MLのハイプ - ブーンの下にあるいくつかの実質： 今やすべてのベンダーがAI/MLの使用を宣言しています。皮肉な見方：それはしばしば高度な統計の再ブランディングやわずかなMLの追加機能を「AI搭載」としているだけです。ただし、スペアパーツの計画ではAI/MLの新たな実際の用途が出現しています：

  • 断続的需要の分類： MLアルゴリズムを使用して、過去の需要パターンを自動的に検出しています（「この部品にはCrostonを使用する」と人間が言う代わりに）。これにより、より良いモデルやパラメータを選択することで予測が改善されます。
  • 因果要因の統合： 機械学習は外部データ（センサーデータ、使用データ、天候など）を組み込んで部品の需要を予測できます - これは手動方法では難しいことです。PTC（ThingWorx）やSyncron（Uptime）のようなベンダーは、IoT入力を接続することでこれを行っています ⁹。
  • 動的パラメータの調整： AIは、新しいデータが入ってくるたびに安全係数やリードタイムの仮定を調整できます。これにより、プランナーが定期的なレビューを行う代わりに、新しいデータが入るたびに調整できます。
  • 異常検出： MLは、外れ値や変更を識別するのに優れています（たとえば、あるマイナーな部品の需要が突然3倍になった場合、アルゴリズムは、忙しいプランナーよりも迅速かつ確実にそれをフラグ付けします）。
  • 意思決定の自動化： 一部の人々は、システムがシミュレーションを通じて最適な発注ポリシーを「学習」する強化学習を探求しています。

  これらが進行中の中、バイヤーは曖昧なAIの主張に懐疑的であるべきです。たとえば、ベンダーが「当社のAIは在庫を30％削減します」と説明せずに述べるのは疑わしいです。トレンドは、AIが主張するための必須要件になりつつあるが、ベンダーが具体的なAI駆動の機能を示すことができる場合にのみ差別化されるということです。私たちの評価では、Lokadのアプローチ（AIとはラベル付けされていませんが）やToolsGroupの、GAINSの舞台裏のアルゴリズムは実質的な分析力を示しています。SyncronやBlue YonderもAIに投資していますが、マーケティングと実際の能力を区別する必要があります。関連するトレンド：特許をマーケティングとして利用すること。 一部のベンダーは、独自性を示唆するために特許を強調しています。ただし、特許（特定の予測アルゴリズムなど）がそのアプローチが実際に優れているか、製品で効果的に実装されているかを保証するものではありません。それはしばしば実用的な価値よりも美徳のシグナルです。焦点は結果と証拠能力に置かれるべきであり、パンフレットに特許が多いかどうかではないことに留意すべきです。

• IoTと予測メンテナンスの組み込み： 産業が機器にIoTセンサーを採用するにつれて、スペアパーツの計画は予測メンテナンスとリンクされるようになっています。これは、PTC（ThingWorx + Servigistics）やSyncron（Uptime）などのベンダーが初期のリーダーシップを確立しているトレンドです。アイデアは次のとおりです：断続的な故障が需要を発生させるのを待つのではなく、センサーデータを使用して故障を予測し、部品を事前に配置します。これにより、不確実な需要が（より）確実な予定された需要に変わります。これは、故障がある程度予測できる高コストの部品にとってゲームチェンジャーです（たとえば、振動パターンによって）。この能力を持たないベンダーもいます - これには従来の計画を超えたIoT統合と分析が必要です。パートナーシップがさらに形成されているのを見ています：たとえば、IoTプラットフォームが在庫最適化プログラムと提携している場合など。市場のトレンドは、航空宇宙、重機械、エネルギーなどの産業を中心に、顧客が、少なくともIoTデータを使用するロードマップを持っているサービス部品ソフトウェアを期待しているということです。ここで何もストーリーがないベンダーは、将来を見据えた能力において遅れていると見なされるかもしれません。

• 標準としてのマルチエシュロンとグローバリゼーション: 十年前、マルチエシュロン在庫最適化（MEIO）はニッチなハイエンド機能でした。今では、中堅ツールでもますます標準化されています（中堅クラウドソリューションでもマルチエシュロンを宣伝しています）。トレンドは、中堅企業でもグローバルネットワークや複数の在庫場所を持つことが増えているため、ネットワーク全体で最適化する能力が重要です。私たちのリストのすべてのベンダーがある形式のMEIOを提供しています。違いは洗練度にあります（たとえば、Servigisticsの深いFed-RAMP認定、防衛グレードのMEIOと、よりシンプルな2層最適化など）。顧客は、ベンダーのMEIOが本当に統合されていることを確認する必要があります（エシュロン全体でレベルを共同で最適化する）単なる連続（まず中央、次にローカルのシロ）ではないこと。市場は今やグローバル最適化を期待しており、単に「各場所を別々に」アプローチすることは、ネットワークが本当に単一層でない限り、警戒すべきです。また、ネットワークの複雑さが増している（eコマースチャネル、第三者物流倉庫など）、そのため、ソフトウェアは以前よりもスペアパーツのより複雑な流通フローを処理する必要があります。

• スケーラビリティとパフォーマンスの強調: データが大きくなるにつれて（使用状況のより詳細な追跡、IoTデータ、製品の増殖によるより多くのSKU）、スケーラビリティはセールスポイントとなっています。現代のシステムは、クラウドのスケーラビリティとインメモリ計算を宣伝しています。従来のオンプレミスソリューションは、巨大なデータセットでの実行時間に苦労することがありましたが、クラウドコンピューティングによりそれが緩和されました。今、差別化要因は、アルゴリズムがどれだけ効率的かによります。たとえば、何かが変わった場合にシステムがほぼリアルタイムで再最適化できるか（半自動のリバランスのため）、それとも夜通しバッチを実行する必要があるか。推奨事項を段階的に更新できるツールは、応答性に優れています。トレンドは、より頻繁な計画サイクル（連続的な計画さえも）に向かっており、月次のバッチではなくなっています。そのため、連続最適化（GAINSがそれに触れています¹¹）やコントロールタワーの概念（Blue Yonder）が登場しています。基本的に、スペアパーツの計画は、静的で周期的なタスクから、よりオンデマンドで適応型のプロセスにゆっくりと移行しており、ソフトウェアは、より良いパフォーマンスとリアルタイムのデータ処理をサポートするために進化しています。

• 計画と実行、その他の機能の統合: ベンダーは、より「エンドツーエンド」にスコープを広げています。Syncronは保証とフィールドサービスに拡大し、PTCはARとサービス実行に接続し、ToolsGroupは小売実行に拡張しているなど、すべてが示すトレンドは、顧客が予測からフルフィルメントまでを処理する統合プラットフォームを好む可能性があることです。スペアパーツでは、これは在庫最適化をフィールドサービス管理、修理業務、調達、価格設定とリンクさせることを意味します。ベストオブブリードのポイントソリューションは、まだそのニッチで優れています（いくつかの専門ツール間の統合は機能するかもしれませんが）、クラウドとAPIのおかげで、統合が容易になり、ベンダーは隣接する機能をカバーしようとしています。中〜大規模企業は、維持するシステムを減らす傾向があるかもしれません。したがって、市場ではいくつかの統合とスイート構築が見られます。たとえば、Oracle/SAPのような大手プレーヤーがより多くの機能をバンドルしています（必ずしも効果的ではないが）、または専門家がパートナーシップを結んでいます（たとえば、Lokadが在庫に焦点を当てているが、メンテナンスデータに関してEAMシステムと提携しているかもしれません）。この分野では、合併と買収も注目すべきトレンドです：*Thoma Bravo（PE）*がいくつかのサプライチェーンソフトウェアを統合し、Apteanが在庫プランナーを買収し、E2openが計画会社を買収しているのを見てきました。これにより、以前は独立していたソリューションがより大きな提供のモジュールになることがあります。それらの買収が統合されているか、単に一緒にマーケティングされているかを監視することが重要です。一つのブランドを身に着けた分散したソリューションは、スムーズな体験を期待するユーザーにとって悪夢となる可能性があります。

• 増加する懐疑主義と証拠の要求: おそらくメタトレンドですが、購入者は大胆な主張や流行語に対してより懐疑的になっています（当然のことです）。サプライチェーンソフトウェアを選択する際には、エビデンスに基づいた意思決定への需要が高まっています。その結果、ベンダーは、企業独自のデータで自社のテクノロジーを実証するパイロットプロジェクトや概念実証を行うよう迫られるかもしれません。本当に先進的なベンダーは、実際の確率的予測、最適化された結果を示すことで輝くことができますが、流行語に乗っかっているベンダーは、自社のツールをマーケティングスライドから実際のシナリオに簡単に適用できない場合、露呈されます。また、独立したアナリストの評価（IDC MarketScape ²のような）が、スペアパーツの計画の技術的能力に焦点を当てているのを見ることができ、これはいくつかのマーケティングの無駄を排除するのに役立ちます。

• ユーザーエクスペリエンス：エキスパートツールからプランナーフレンドリーへ：もう1つのトレンドは、これらの複雑な分析の使いやすさとアクセシビリティを向上させることです。過去には、一部のツール（特に数学が重いもの）は質素なUIを持っていたか、PhDが解釈する必要がありました。現在は、視覚化（たとえば、需要分布をグラフィカルに表示したり、インタラクティブな在庫サービストレードオフ曲線を示したりする）やシナリオプレイの容易化に重点が置かれています。ベンダーは、UI/UXに投資して、複雑さを隠し、シンプルなインサイトを提示しています（たとえば、「在庫に10万ドル以上投資すると、これらの重要な資産の稼働時間を2％向上させることができます-はい/いいえ？」）。これは重要です。多くの組織は、予備部品の意思決定に異なる職能部門の利害関係者（財務、運用）を巻き込む必要があり、消化しやすい出力が必要です。トレンドは、エグゼクティブ向けのメトリクス（避けられたダウンタイムの価値など）を出力できるツールです（技術的な数字だけでなく）。引き続きブラックボックスのように機能するか、コードの記述が必要なもの（Lokadはコーディングが必要ですが、クライアントのために行うことで緩和しています）は、優れた結果を明確に示さない限り、抵抗に直面する可能性があります。

• 過剰在庫と陳腐化に焦点を当てる：予備部品プランナーは常に過剰在庫と陳腐化（死在庫）を心配してきましたが、今では、経済的な圧力やESGに関する懸念（資本を無駄にしない）のためか、ベンダーは彼らのツールが過剰在庫を知的に削減する方法を強調しています。たとえば、ToolsGroupは、スマートな計画によって陳腐化在庫を5〜20％削減することを引用しています³。より多くのツールには、在庫の削減候補を特定するためのモジュールや機能、補充すべきでない寿命が近づいている部品、書き消す前に過剰在庫を再配置する方法などがあります。このトレンドは、経済最適化のテーマと一致しています-サービスだけでなく、無駄な在庫に資本を拘束しないことが重要です。したがって、現代のソリューションには、在庫の健康状態（回転、過剰、潜在的な在庫切れ）のためのダッシュボードがあり、AIが行動を提案します（これを処分する、それを移動するなど）。これは、クラシックな最適化を超えて、在庫の衛生管理に移行するものであり、予備部品では、部品の10％が移動の90％を占める可能性がありますが、残りは静かに蓄積されてコストの沈み場になる可能性があります。

• サービタイゼーションと成果ベースのメトリクス：製品だけでなく「稼働時間」や「サービス契約」を販売する産業に移行する中で、予備部品の可用性はより大きな視点の一部となります。ソフトウェアが成果ベースのメトリクスに合わせるトレンドは、機器の稼働時間や顧客満足度などの内部メトリクスだけでなく、外部メトリクスと一致することを意味します。Syncronのサービタイゼーションのビジョンはその例です⁶⁵。実際には、在庫最適化を契約の履行などと結び付けることを意味します。たとえば、契約で99％の稼働時間を保証している場合、ソフトウェアはそのコストを最小限に抑えるために最適化し、またパフォーマンスを証明する必要があります（稼働時間の達成にどのように役立ったかについて報告します）。一部のベンダー（PTC、Syncron）は、プランナーがSLA要件を直接入力できるようにし、SLAの遵守を保証するために在庫を最適化します。これは、一般的な「補充率」から契約固有の計画に移行するトレンドです。これはまだ新興の機能であり、主にハイエンドのツールに存在します。

要約すると、市場はよりスマートで統合され、財務的に精通したソリューションに向かって進んでいます。しかし、その代償として多くの専門用語が付随しています。バイヤーのトレンドは、透明性と技術的な検証を要求することであり、これはベンダーに対して「AI」や「最適化」といった主張について具体的になるよう徐々に押し付けています。

結論と推奨事項

予備部品最適化ソフトウェア市場を徹底的に評価した結果、明確な像が浮かび上がります：**一部のベンダーが技術の最先端を進んでいる一方、他のベンダーは再パッケージ化されたコンセプトや浅い約束で遅れを取っています。**グローバルな予備部品を管理する中～大規模企業にとって、以下の結論と推奨事項が導かれます：

• LokadとToolsGroupは技術リーダーとして際立っています。 Lokadの妥協のない確率論的アプローチと経済最適化の焦点は、データサイエンスに基づいたソリューションを採用する準備が整った組織にとって最適な選択肢となります。それは確率的予測（リードタイムに対しても）に完全に応え、ROIを最大化するために本物の確率最適化を使用します ^{28 1}。数十年にわたる改良を経て、ToolsGroupは多くの産業で実証された非常に強力な確率エンジンと実用的な自動化を提供します ⁴。それは高度なモデルを使用して規模でサービスと在庫をバランスよく取ります。両社は、単純な計画の落とし穴を避けることを信憑性のある技術的証拠で示しました（両社とも、コア計算に固定安全在庫や単一点予測を依存していません）。それぞれにわずかな違いがあります - Lokadは究極の柔軟性とカスタマイズ（「サプライチェーンプログラミング」アプローチ）を提供し、一方、ToolsGroupはリッチな機能を備えたよりパッケージ化されたソリューションを提供し（おそらく典型的なプランナー向けに友好的なUIを提供）、カスタムモデリングアプローチに参加し、最大のパフォーマンスを求める企業にとっては、Lokadは魅力的な選択肢です。最新の分析を体現したままである成熟した、アウトオブボックスのソフトウェアを求める企業にとっては、ToolsGroupは安全で強力な選択肢です。両社とも、独立した評価や事例研究を通じて、予備部品の結果（在庫削減、サービス向上）を大幅に改善できることを示し、その主張は洗練された手法によって裏付けられています、単なる言葉ではありません ^{3 4}。

• PTC Servigisticsは包括的な機能を備えた金字塔としての地位を維持しています、特に多階層最適化、修理ループ管理、およびより広範なサービスプロセスとの統合が必要な方々にとって。それは最も深い機能ツールキットを持っており、その30年以上にわたるアルゴリズムの基盤により、Servigisticsではサービス部品計画のほとんどのシナリオをモデル化することができます ⁸。その買収統合に対する私たちの懐疑は、PTCがプラットフォームを統一しているという証拠によって大部分が軽減されました ⁷。したがって、非常に大規模な企業（航空宇宙＆防衛、重工業など）にとって、戦闘テスト済みのソリューションが必要で、それを実装するためのサポート構造を持っている場合、Servigisticsは最高の選択肢です。それは広告通りに最低コストで高いサービス部品の可用性を提供し ⁴³、重要なことは、非常に厳しい環境（軍事など）でそれを証明する参照があることです。注意すべきは、Servigisticsを十分に活用するための組織的なコミットメントがあることを確認することです - その科学は優れていますが、実装された通りに優れているだけです。選択肢を選ぶ際には、PTCに、それらに関連する特定の高度な機能を実証するように求めるべきです（例：IoTデータが予測誤差を減らす方法、またはマルチソースの推奨事項が実際に機能する方法など）。PTCの「AI搭載」という主張は文脈の中で信頼性があります（データサイエンスの歴史を文書化していることを考慮すると ⁴²）、しかし、見込みユーザーはそれらのAI機能がどのように現れるかについて詳細に検討すべきです。

• GAINSとBaxter Planningは、強力なコスト最適化アプローチを求めている企業に適した、ROIに焦点を当てた代替手段を提供しています。 GAINSは、継続的なコストと利益の最適化に明確に焦点を当てており¹¹、サービス供給チェーン全体（修理やメンテナンス計画を含む）のカバレッジも提供しています。 一部の大手企業のような大々的なマーケティングはありませんが、実質的にはすべての技術基準で高い評価を受けています。 Baxter Planningは、TCO主導の哲学⁵⁵と現場での実践経験（および計画サービスオプション）を持ち、より実践的なソリューションであり、より手掛かりを求める企業にとっても信頼性のある選択肢です。 GAINSとBaxterの両方は、真の最適化を求める企業にとって良い選択肢であり、ガイド付きまたはパートナーシップ志向の実装を行うことができます。 また、より大手のプレーヤーよりもコスト効果が高く、必要な機能のほとんどを提供しています。 ただし、彼らは「派手なAI」の部分に少し欠けているかもしれません-既存の方法がうまく機能している場合、これは批判ではありません。 たとえば、GAINSの確率的深さやBaxterの予測精度の主張を検証する必要がありますが、証拠は彼らがうまく機能していることを示しています。 科学技術、通信、または産業部門の企業に特にお勧めします。巨大な複雑さなしに確かな結果が必要な企業。 彼らは現在のプロセスの変更を最小限に抑えつつ、分析を大幅に向上させるでしょう。

• Syncronは、強力な業界に焦点を当てたプレーヤーですが、在庫に加えてより広範なサービススイート（価格設定、フィールドサービス）の価値を重視する場合に主に検討してください。 技術的には、Syncronの在庫最適化は優れており、多くのOEMのニーズを満たすでしょうが、他の企業を明確に凌駕するほどのコアな予測や最適化の革新はありませんでした。 それはまだセグメンテーション戦略とサービスレベルの達成に多少依存しており、機能しますが、LokadやGAINSのアプローチほど純粋に最適ではありません。 とは言え、組織がサービタイゼーションを追求している場合-たとえば、動的なスペアパーツの価格最適化、保証管理、ディーラーポータル機能も必要な場合- Syncronは統合ソリューションを提供しており、在庫最適化の技術的不足を上回る可能性があります。 価格設定と在庫をリンクさせる価値（たとえば、収益性を確保するため）は大きく、Syncronはその提供するものがユニークです。 ただし、目を開いて進んでください：Syncronに「AI」予測と最適化の効果を実証するよう要求し、モジュール間のデータ統合（在庫と価格）に投資する準備をしてください⁶³。 純粋なスペアパーツの優れた在庫管理が唯一の基準である場合、他の企業が上位にランクインしますが、アフターマーケットオペレーションのスイートソリューションには、Syncronが有力な競合他社です。

• 主要なERPソリューション（SAP、Oracle）および汎用サプライチェーンスイートは、スペアパーツの計画に関しては慎重にアプローチする必要があります。 証拠（特に顕著なプロジェクトの失敗を含む）によると、SAPやOracleのネイティブオファリングはしばしば真の最適化を提供できないことが示されています^{19 20}。 彼らは時代遅れの概念（静的安全在庫、単純な予測）を使用し、最高水準のツールがそのまま提供することができるものに近づくためには、重いカスタマイズが必要です。 スペアパーツのオペレーションが比較的単純であるか、すでにこれらのERPに緊密に結びついている場合を除き、SAPやOracleの組み込みのスペアパーツ計画モジュールを主要なソリューションとして依存することは一般的にお勧めしません。 それらはトランザクションシステムとして機能することができ、実行を処理するかもしれませんが、計画知能に関しては、上記の専門ベンダーが一世代進んでいます。 組織が第三者ツールを追加することに非常に抵抗がある場合、1つの戦略は、ポリシー（予測、最小/最大レベルなど）を計算するためにベストオブブリードソリューションを使用し、それらをSAP/Oracleに供給して実行に使用することです- ERPの脳を迂回し、筋肉としてのみ使用する方法です。 このハイブリッドアプローチは一般的であり、それぞれの強みを活用しています。

• ベンダー評価で注視すべき主な赤信号： この調査を通じて、解決策が真に最先端でない可能性があることを示す特定の警告サインを特定しました：

  • 異常値のクリーニングへの過度な重点： ベンダーが遅動パーツの文脈で異常値の手動クレンジングや「需要感知」について多く話す場合、注意が必要です。 現代のソリューションは、変動性を自然に処理するはずです。 異常値に過度に焦点を当てることは、彼らの予測が確率的な方法で異常を取り込むには十分に堅牢でないことを意味するかもしれません。
  • 具体性のないバズワードの過剰： 「AI駆動、量子学習、次世代」といった説明の裏付けがない用語。 常に会話を「どのように」に誘導してください - 例えば、AIが乱れた需要の予測をどのように改善するのか？例を示してください。 マーケティングスローガンを超えて答えられないベンダーは、おそらく古い方法を再パッケージ化している可能性が高いです。
  • 厳格なサービスレベルまたは安全在庫の入力： ツールがすべての対象サービスレベルを入力することを要求し、他の客観的な機能を提供しない場合、それは古い設計かもしれません。 同様に、作業フローを手動で安全在庫の設定に集中させている場合、それは赤信号です。 最高のツールは、これらを計算するか、それらを二次的なメトリクスに変換します¹。
  • 最近の買収の拡大： ベンダーが短期間で複数の企業を買収した場合（特に評価している製品の1つである場合）、バージョンの統合を確認してください。 すべての機能が1つのユーザーインターフェースと1つのデータベースで利用可能かどうか尋ねてください。 たとえば、ToolsGroupが複数の製品を買収した場合 - 予測対在庫対実行のために3つの異なるUIを使用する必要がないことを確認したいと思うでしょう。 Syncronの価格用の別々のDBは小さな問題ですが、知っておく価値があります⁶⁴。 ソフトウェアスイート内の不一致した部分は、効率の低下やデータ同期の問題を引き起こす可能性があります。
  • 特許および結果の代わりに専有用語： 一部のベンダーは、「特許取得の断続的需要アルゴリズムX」と自慢するかもしれません。 それは良さそうですが、その方法が標準アルゴリズムを実質的に上回っているかどうかは疑問です。 しばしば、学術研究（ベンダーによるものと独立したものがあります）は、断続的需要に対する銀の弾丸はないことを示しています。 特許取得のアプローチは、いくつかのケースではわずかに優れているか、単に異なるかもしれません。 改善を示す参照またはテスト結果を要求することが重要です。 特許取得または専有権を持っていると聞いただけで惑わされないでください - 結果の証拠に焦点を当ててください。
  • 「プラグアンドプレイ」または「1クリック」の実装主張： 予備部品の最適化を実装することは、技術の変更と同じくらいプロセスの変更です。 ほとんどの場合、データの課題（欠落しているデータ、不正確なBOMなど）が発生します。 信頼性のあるベンダーは、データの準備と変更管理の必要性を認めるでしょう。 したがって、「プラグアンドプレイ」の主張を黄色の旗として扱い - 実際にライブにするために実際に必要なものを詳しく調べてください。 おそらく、簡単な統合を主張する人々は、データの深層を掘り下げるのに十分ではない基本的なソリューションを持っている可能性が高いです。

• 最終的な推奨事項 - ハイプよりも実質を選択してください： 本当に利益を得るためには、企業は現代の技術と独自のビジネスの現実に合致するソリューションを選択すべきです。 ダウンタイムが重要でデータが利用可能な場合は、確率モデルと経済最適化を使用するソリューション（Lokad、ToolsGroup、Servigistics、GAINS）に傾けてください。 会社が価格設定やサービス実行を見直す必要がある場合は、SyncronやPTCのより広範な提供など、統合スイートを検討してくださいが、最適化技術が損なわれていないことを確認してください。 すべての場合において、選択時に需要の透明性を要求してください：ベンダーにあなたのデータのサンプルをシステムに通して実行して、断続的な需要をどのように処理し、どのような推奨事項を行うかを確認してください。 これにより、マーケティングがすぐに切り捨てられます。 本当に高度な方法を使用している人は、現実的な範囲の結果と最適化された在庫レベルを示すことができるでしょう（そしてこれらの結果を現在の結果や既知のベースラインと比較できます）。

最終的な目標は、最小限の適切なコストで顧客のサービス可用性を最大化し、手作業の監視を最小限に抑えるスペアパーツの最適化ソリューションです。確率的予測、経済的最適化、およびスケールでの自動化に投資しているベンダーは、このバランスを実現するのに明らかに優れています。市場は幸いにもその方向に向かっており、各ベンダーの能力を検証することが重要です。本研究で概説された原則に焦点を当てることで、確率駆動型の計画、コスト便益の焦点、スケーラビリティ、および技術的信頼性に重点を置くことで、ハイプと実質を区別し、スペアパーツの計画を本当に最先端のパフォーマンスに引き上げるプラットフォームを選択できます。

脚注