お問い合わせ

エンタープライズ向けサプライチェーンソフトウェアベンダー、IBMの評価

著者:Léon Levinas-Ménard

最終更新日:2026年11月4日

市場調査に戻る

IBMはサプライチェーン業務向けに複数のアプリケーションを提供している。Sterling Order Managementは注文、在庫、出荷元の選定、受注履行、返品を調整する。Sterling Intelligent Promisingは供給可能量、配送の約束、履行方法を計算する。Planning Analyticsは、業務計画と財務計画を整合させるための構成可能なモデルを提供する。これらの製品はIBMの連携ソフトウェアや導入サービスと組み合わせられる。1 2 3

サプライチェーン総合評価:5.4/10

評価軸 評点
サプライチェーンへの理解の深さ 5.6/10
意思決定と最適化の実質 5.8/10
製品とアーキテクチャの一貫性 4.8/10
技術的透明性 6.8/10
ベンダーの真剣さ 4.2/10

IBMのサプライチェーンソフトウェアで最も強い部分は、業務上の意思決定を実行し、その制約や設定について充実した公開文書を備えている点だ。Premiumの受注履行最適化は、出荷拠点を選ぶ際に品切れや値下げの経済的影響を推定する。一方、製品群全体はトランザクションの実行、構成可能な計画、専門的な予測サービスに分かれたままである。需要と供給が不確かな状況で、補充、生産、受注履行を同時に最適化する共通モデルは公開されていない。3 5 6

主な懸念は、この製品群の保守負担と、広範なAIの宣伝に対して実際に提供される運用モデルとの隔たりにある。IBMは認知型サプライチェーン、ブロックチェーンネットワーク、そして今はエージェントを宣伝してきた。測定可能な業務改善をもたらす製品もあれば、撤退した製品もある。現在のエージェントは主に既存の管理作業を高速化するものであり、より実質的な受注履行ロジックは、その対話インターフェースより以前から存在する。13 14 23 24

IBMとLokadの比較

Sterlingは、Lokadが置き換えようとしていないトランザクション管理を担う。注文状態を保持し、履行を調整し、チャネルをまたいで在庫を公開できる。一方、Lokadの在庫最適化は、業務データと不確かな将来の結果から経済性に応じて順位付けした意思決定を生成し、サプライチェーンサイエンティストが意思決定ロジックの開発と保守を担う。

Sterling Intelligent Promising Premiumは、この考え方と重要な部分で重なる。距離だけで出荷拠点を選ばず、将来の在庫リスクに費用を割り当てる。違いは意思決定問題の範囲である。Premiumは、利用可能な在庫情報と補充情報に照らして履行方法を評価する。Lokadの運用モデルは、その在庫を生み出した購買と配分の意思決定も対象にする。良い出荷判断をしても、数か月前に誤った品揃えを買った経済的損失をすべて取り戻すことはできない。5 10

Planning Analyticsは、はるかに広い経営課題をモデル化できるが、そのモデルは構築と保守を要する。柔軟性が高い分、次元、計算、仮定、見直し手順を定義するチームの責任は大きい。したがって比較すべきは、提供される意思決定プロセスとその維持であって、アプリケーションの数やAIアシスタントの有無ではない。2 12

製品の範囲とバージョン

Sterling Intelligent Promisingは、静的な費用の最適化とPremiumの予測的な在庫費用を区別している。後者はSaaSとして提供され、コンテナ展開向けには追加のハイブリッド機能としても利用できる。中核サービスはコンテナ内で動作し、AI処理はIBM Cloud上で動作する。コンテナのライセンスだけでは、その導入環境に予測機能が含まれるとは確認できない。3

2026年3月のリリースノートは、OMS Agentic Toolkitの一般提供開始を示している。その後のリリースでは、エージェントのアクセス制御、ツール管理、トレース、MCPアプリケーションが加わる。古い概要ページにはまだ限定的な試用と書かれているが、現在の提供状況を示す根拠としては日付付きのリリース履歴のほうが強い。14

Supply Chain Intelligence Suiteは歴史的な評価の対象となる。IBMのライフサイクル記録によれば、2025年5月14日に新規注文の受付を終了している。これは販売終了日であり、既存のすべてのサービス契約がその日に終了したという意味ではない。24

最適化が実際に行うこと

受注履行には実質的な経済メカニズムがある

Premiumは、SKUと出荷ノードごとに品切れと値下げのリスクを推定し、その費用を注文の出荷元選定に使用する。期待売上の高い拠点に在庫を残し、値下げのリスクがある別拠点から出荷できる。これは実質的な機会費用の計算であり、オムニチャネル小売に直接関係する。5 6

技術FAQは、回帰とディープラーニングによる予測、60日間のリスク評価期間、継続的な再学習を説明する。また、計算結果の費用推定値は表示するものの、需要予測そのものはユーザーに表示しないとしている。これは診断を制約する。不自然な推奨は、売上予測、在庫記録、補充の仮定、金額への換算のいずれからも生じうる。最終費用だけを見ても、原因は切り分けられない。7

入荷予定の補充は明示的に入力に含まれる。公開された連携手順は、売上、供給可能量、商品カタログ、値下げ、注文状態の情報に加え、供給計画のデータを求めている。不足しているのは、不確かな到着日、数量、それらの依存関係がどう計算に入るかという詳細だ。補充予定表を受け取ることと、予定が守られない確率をモデル化することは異なる。まさに品切れ回避に価値が生まれる局面で、この違いが重要になる。10

金銭的費用には、さらに重み付けが行われる

IBMは目的関数の構造を公開している。出荷、処理、能力、品切れ、ノード性能、輸送の費用を加算し、値下げ回避を便益として扱う。ユーザーは目的ごとにゼロから100%の重みを設定し、ゼロにするとその項は無効になる。4

ここには経済的な較正の問題がある。費用が比較可能な金銭的影響を表しているなら、相対的な重みを変えることは、最適化器の内部で一ドルの意味を変えることになる。品切れの重みを下げることで、過大評価された損失を補正する場合もあれば、好みの出荷方針を勝たせるだけの場合もある。ソフトウェアには、両者を妥当に区別する手段が必要だ。重み付きの式を高速に最適化しても、その式が事業を表しているかは決まらない。

ホリミゼーションの視点が直接当てはまる。難しいのは、適切なモデルを構築し維持する作業だ。重要なのは、顧客行動、補充の信頼性、その他の業務制約が変わっても、履行方針が利益を生むかどうかである。ソルバーの速度や選ばれたノードの説明だけでは足りない。

Planning Analyticsの目的は異なる

Planning Analyticsは、構成可能な多次元モデルを通じて業務計画と財務計画を組み合わせる。予測オプションには季節性モデルの選択、外れ値の処理、予測区間が含まれる。文書化された信頼水準は区間の設定値であり、予測精度が95%や99%だという主張ではない。2 11

これらは分析を支えるが、実行可能な確率的サプライチェーン方針を自動的に作るわけではない。系列ごとの予測区間では、製品、拠点、リードタイムをまたいで誤差がどう相互作用するかは分からない。仮定を変えたケースを集めても、確率を割り当てたり、経済的に正当なコミットメントを選んだりすることにはならない。顧客はプラットフォームの周囲に相当なロジックを構築できるが、そのエンジニアリング作業もソリューション費用の一部である。

生産性と設定の保守

エージェントは主に既存の業務を操作する

Order Hubの文書には、実態をよく示す例がある。ユーザーは特定商品の供給可能量を尋ね、セグメントルールを確認し、配分比率の変更を要求する。エージェントは対応するAPIを呼び出す。画面操作やデータ入力の時間は減らせるが、在庫方針を与えるのは引き続きユーザーだ。セグメントの配分を変更するチャット指示だけでは、その配分がなぜ利益を改善するのかは示されない。13

新しいツールキットはMCPを通じた外部エージェントも支える。これは、何をすべきかを判断する難しい仕事に比べれば、安価なインターフェース接続である。ツールへのアクセスをサプライチェーンの知能として宣伝すると、人間が商品を逐次管理する方式を温存し、操作を快適にするだけになりかねない。既存の履行サービスは、より重要な方向をすでに示している。維持された経済モデルから反復的な意思決定を自動生成することだ。14

IBM自身のリリースノートは、新たな保守作業の一部も明らかにする。エージェントの振り分けには類似表現としきい値を用い、管理者は一致しなかったケースを確認して調整できる。したがって、ツール定義、振り分け動作、モデルの応答も、変更後にテストすべき設定群に加わる。操作が速くなることに価値があるのは、節約した総作業量が、その保守と監督の作業量を上回る場合だけだ。14

従来からの設定負担は残る

Sterlingのホスティングサービスにはインフラ運用が含まれるが、製品概要は性能試験を顧客の責任とし、カスタマイズした処理フロー、連携、アップグレード時の修正、試験を導入作業として挙げている。予定されたOS変更では、本番環境へのパッチ適用前に、顧客や導入業者が非本番環境で試験できる期間がある。SaaSはホスティングの責任を移すが、アプリケーションのエンジニアリングをなくすわけではない。1

Planning Analyticsには別の保守技能が必要となる。管理文書は、永続フィーダー、並列クエリ、専用のメモリと設定要件を持つ非公開の計画データ領域を説明する。経済モデルと、その計算に使う構造は同時に発展させなければならない。製品、拠点、シナリオが増えると、業務ロジックと計算資源の双方に作業が発生しうる。12

負担は顧客の採用情報にも現れる。AIVIのSterling開発者求人は、独自Javaサービス、Sterling拡張、連携、DB2、テスト、性能改善の作業を求めている。これは特定小売業者の導入上の必要性を示す証拠だ。稼働するOMSの背後にある技術労働を示しており、IBMの利用料や導入費と併せて費用に含めるべきである。18

ソフトウェアの構成要素

製品と展開形態 文書化された構成要素 保有上の影響
Intelligent Promisingコンテナ KubernetesまたはOpenShift、Cassandra、Kafka、Elasticsearch。 複数の永続的な分散サービスに対して、容量計画、パッチ、バックアップ、互換性のあるアップグレードが必要となる。16
Intelligent Promising Premiumハイブリッド コンテナサービスとIBM CloudのAI処理。 運用とデータフローがローカルとクラウドの境界をまたぐ。3
Planning Analytics TM1モデル、計算ルール、フィーダー、クエリ処理設定。 独立したモデリングと性能管理の技能が必要となる。12
AIVIのSterling導入に関する職務 Java/Java EEとSpring Bootによる拡張、Kafka連携、DB2での作業。 顧客側でのソフトウェア開発は依然として相当な規模になる。18

コンテナ版では、顧客が複数の永続的な分散サービスを運用する必要がある。障害復旧では、アプリケーションプロセスを再起動するだけでなく、データとイベントの状態を整合させる必要がある。16

簡素化も文書化されている。2025年のリリース履歴によれば、OptimizerサービスのデータストアはMongoDBからElasticsearchへ置き換えられ、MongoDBはサポート対象外となった。同じ履歴にはCassandraのアップグレード手順もあり、構成要素をひとつ取り除いても互換性維持の作業が続くことが分かる。17

IBMはこの複雑さの多くを公開している。未解決の経済的問題は、提供する意思決定と労働削減が、その複雑さを抱える費用に見合うかどうかだ。使い慣れたインフラでも運用費用はなくならない。

セキュリティと運用上の封じ込め

SterlingではAPI権限が既定で取り消された状態となり、ソフトウェアのセキュリティ設定ではAPIセキュリティが有効で、厳格な適用が既定となっている。現在のエージェントへのアクセスは、ユーザーグループに別途割り当てられ、エージェント起動時に確認される。これらは、識別可能な認可境界を設ける仕組みである。15 26 27

コンテナの導入手順は、封じ込めについては説得力に欠ける。ミドルウェアのTLS、ポッドポリシー、クラスターロールを設定する一方で、ポッド間のすべての通信を許可するよう運用者に指示している。この広い内部接続性は、厳密に区分された設計と比べて、侵害された構成要素の封じ込めを難しくする。コンテナだけでは、信頼するサービス間や管理権限間の分離は成立しない。16

ホスティングされたOMSについて、IBMは毎日のバックアップと、復旧時間/データ損失の目標として48時間/24時間、または四時間/二時間を記載している。これは具体的な運用パラメーターである。ただし概要には、復旧用コピーと復元権限が、侵害された本番管理者から独立しているかの説明はない。破壊的攻撃への備えでは、この違いのほうが暗号化や認証バッジより重要だ。1

約束、実現、撤退の歴史

時期 訴求または出来事 その後の実態
2016 Watsonを、学び、推論する認知型アドバイザーとして宣伝。 Supply Chain Insightsは、混乱の通知、影響の推定、仮想ワークルームでの専門家の協力を説明する。21
2019 IBMがSterling Supply Chain SuiteをAIとブロックチェーンの統合プラットフォームとして紹介。 広範な訴求は注文管理を越えて企業間ネットワークに及ぶ。22
2022 IBMが自社の認知型サプライチェーンによる改善を報告。 事例は、より広い変革全体で1.6億ドルの費用削減を主張する。28
2022–2023 IBMとMaerskがTradeLensの終了を発表。 Maerskは、業界の参加が不十分で商業的に成り立たなかったことを理由に挙げる。23
2025 IBMがSupply Chain Intelligence SuiteとBlockchain Transparent Supplyの撤退を発表。 Suiteのライフサイクル記録は、5月の新規注文終了を確認する。24 25
2026 OMSにエージェント型ツールキットが加わる。 日付付きリリースは、検索、サービス、管理、連携の具体的な機能を記録する。14

2016年の宣伝は、文書化された仕組みを上回っていた。人間のように世界を理解するシステムという説明は大きな約束だったが、パターンを見つけ、通知を出し、専門家を集める機能ははるかに限定的だった。この隔たりは現在のエージェントの主張にも関係する。新たな世代の語彙が、再び支援型の業務を包んでいるからだ。21

TradeLensは、捨てられた標語よりも強い歴史的検証材料である。プラットフォームは構築されたが、その商業的前提には、実際には確保できなかった参加が必要だった。Maerskの説明が示すのはビジネスモデルの失敗であり、データベースが機能しえないという証拠ではない。業界全体での協力の必要性は、製品設計の問題の一部だった。ベンダーの判断力を評価する際に、外部の細事として扱うことはできない。23

その後の撤退は、IBMの最新サプライチェーンプラットフォームを採用すれば永続的なロードマップが保証されるという考えをさらに弱める。継続するSterlingのトランザクション製品と、その文書化された改善は別の実績を持つ。買い手が必要とするのは、IBM全体の規模から得る安心感ではなく、製品単位の継続性の証拠である。

IBMの2022年の社内事例は、関連する反証でもある。Cognitive Supply Chain Advisor 360と他のIBM構成要素によって、大きな節約と混乱分析の高速化を報告している。ただし、人間の意思決定者を伴う広範な社内変革を述べたものであり、単一の商用計画エンジンの成果を独立測定したものではない。1.6億ドルという数字では、ソフトウェア料金、導入作業、各構成要素の寄与は分離されていない。28

成果と経済的な説明責任

最適化器は反実仮想を測定する

SterlingのBenefitsレポートは、すべての注文に対して並行して別の最適化を実行し、選んだ解を基準と比較する。文書はまた、在庫を保護したノードでの後日の販売を、品切れ回避の便益として報告できると説明する。これは、サービスレベルや予測精度だけを示すよりも有益である。8 9

それでも反実仮想は検証を要する。後日の販売があっても、別の方針なら顧客を失っていたとは限らない。別ノード、代替品、遅い配送でも顧客を維持できたかもしれない。同様に、値下げ回避も基準方針が実際に何をしたかに依存する。モデルが生成したふたつの選択肢を比較すると、モデルの選好を数量化できても、実現利益を過大評価するおそれがある。さらに、ソフトウェア、連携、継続運用の費用は別途差し引く必要がある。

顧客事例が示す業務改善はより限定的である

Novolexの2021年3月の事例は、六週間の予測サイクルを一週間未満に短縮し、在庫を16%減らして運営したと報告する。一方で、分析、議論、見直しには二日間が残り、予測分析は将来の段階として説明されている。この成果はPlanning AnalyticsとCognosによる調整の改善を裏付けるもので、現在のエージェントや確率的な履行機能に遡って帰属させるべきではない。19

hagebauの2023年10月の事例は、ドイツの約350店舗とオーストリアの45店舗へのSterling導入を記録し、注文の可視性と顧客満足度ランキングの改善を挙げている。導入には専門パートナー、IBM Lab Services、独自拡張が関与した。相当な規模でのトランザクションシステム統合を示す一方、正味の経済的収益と継続的なエンジニアリング費用は定量化されていない。20

サプライチェーン評価

サプライチェーンへの理解の深さ

基準 評点
経済的な問題設定 6/10
最終的な意思決定への到達 7/10
サプライチェーンに関する概念の明確さ 6/10
時代遅れの中心的教義からの自由度 4/10
KPIの見せかけへの耐性 5/10

平均:5.6/10

経済的な問題設定 — 6/10。 Premiumは将来の在庫の影響を金額にする。顧客が定める重みと履行に限られた範囲のため、統一的な経済方針にはなっていない。4 5

最終的な意思決定への到達 — 7/10。 履行方針は実行可能な意思決定を生成する。ただし経済的な対象範囲は、サプライチェーン全体より狭い。3

サプライチェーンに関する概念の明確さ — 6/10。 直近の出荷費用と将来の在庫価値を区別する考えは妥当である。上流の購買判断は、文書化された計算の範囲外にある。5 6

時代遅れの中心的教義からの自由度 — 4/10。 構成可能な計画とユーザー主導の配分が依然として中心にある。これらの操作を速めても、人間の計画作業の多くは温存される。2 13

KPIの見せかけへの耐性 — 5/10。 並行比較は選択した方針の可視性を高めるが、反実仮想から推定した便益は実現利益と照合する必要がある。8 9

意思決定と最適化の実質

基準 評点
確率的モデル化の深さ 5/10
独自性のある最適化または機械学習の実質 6/10
現実の制約への対応 7/10
意思決定の自動化と労働生産性 6/10
現実の業務の複雑さに対する適応力 5/10

平均:5.8/10

確率的モデル化の深さ — 5/10。 在庫リスクの確率は意思決定に影響する。ただし、不確かな補充や共通の供給障害との関係は、文書で十分に掘り下げられていない。5 10

独自性のある最適化または機械学習の実質 — 6/10。 期待損失の仕組みは、一般的なAI予測の宣伝より実質がある。その較正と内部予測は、部分的にしか検証できない。6 7

現実の制約への対応 — 7/10。 hagebauの導入は、事業に合わせた連携とカスタマイズを伴いながら、数百店舗で業務利用されていることを示す。20

意思決定の自動化と労働生産性 — 6/10。 履行方法の自動選択は、反復的な意思決定作業をなくす。新しいエージェントと計画アプリケーションには、より多くのユーザー介入が残る。3 13

現実の業務の複雑さに対する適応力 — 5/10。 設定と費用の説明は方針の検証を助けるが、非公開の予測は失敗原因の診断を難しくする。不適切な経済的仮定を修正し、過去の意思決定を再実行し、修正を検証する完全なサイクルは、公開された証拠からは確認できない。7 8

製品とアーキテクチャの一貫性

基準 評点
アーキテクチャの整合性 4/10
システム境界の明確さ 7/10
セキュリティへの真剣さ 5/10
ソフトウェアの簡素さと保有費用 3/10
プログラムおよびエージェント支援による運用との適合性 5/10

平均:4.8/10

アーキテクチャの整合性 — 4/10。 製品ごとに異なるモデルと運用要件が残る。連携によって接続されても、共通の意思決定の意味体系は成立していない。3 12

システム境界の明確さ — 7/10。 IBMは展開形態、予測サービスの境界、必要なデータ供給を、評価に役立つ精度で文書化している。3 10

セキュリティへの真剣さ — 5/10。 明示的な権限と既定の強制適用は有用な基盤である。広い内部接続性と不十分な復旧隔離の説明が、セキュリティの裏付けを限定する。16 26 27

ソフトウェアの簡素さと保有費用 — 3/10。 ミドルウェア群と継続的なカスタマイズは、相当なエンジニアリング作業を課す。文書化されたデータストアのひとつの廃止は、より大きな負担の中での有用な簡素化である。16 17 18

プログラムおよびエージェント支援による運用との適合性 — 5/10。 APIは無人の受注履行を支えるが、対話による設定は主に人間が既存システムを操作する方法を変えるものだ。3 13

技術的透明性

基準 評点
公開技術文書 8/10
ベンダーの仲介なしでの検証可能性 7/10
可搬性とロックインの可視性 5/10
実装方法の透明性 8/10
技術的主張を裏付ける証拠の密度 6/10

平均:6.8/10

公開技術文書 — 8/10。 詳細な目的関数、連携手順、セキュリティ設定、展開要件が、商談を始める前の実質的な評価を可能にする。4 10 16

ベンダーの仲介なしでの検証可能性 — 7/10。 費用の説明と並行比較は、重要な意思決定動作を明らかにする。非公開の予測内部構造は、独立した診断を制限する。7 8

可搬性とロックインの可視性 — 5/10。 コンテナの選択肢とAPIは明確なインターフェースを提供するが、独自モデル、カスタマイズ、クラウド依存の予測サービスは置き換えを難しくする。3 18

実装方法の透明性 — 8/10。 連携手順とバージョン履歴は、買い手が保守見積もりに含められる依存関係を公開している。10 17

技術的主張を裏付ける証拠の密度 — 6/10。 製品文書は具体的な仕組みを裏付ける。顧客事例がより強く裏付けるのは業務の変化であり、最新AI機能による正味の収益ではない。19 20

ベンダーの真剣さ

基準 評点
公開発信の技術的な真剣さ 4/10
技術ロードマップの一貫性 3/10
概念の明確さ 5/10
経済的な説明責任 5/10
エージェント型ソフトウェア時代における競争力の持続性 4/10

平均:4.2/10

公開発信の技術的な真剣さ — 4/10。 マニュアルの精密さは、認知型サプライチェーンという物語が示唆する、はるかに広い能力と対照をなす。4 21

技術ロードマップの一貫性 — 3/10。 TradeLensと撤退したインテリジェンス製品は、重大な継続性の失敗である。存続するOMS製品については、別途、より肯定的な評価が必要となる。23 24

概念の明確さ — 5/10。 専門的な受注履行の推論は、製品群全体の知的サプライチェーンに関する広い約束より堅実である。5 22

経済的な説明責任 — 5/10。 IBMは数量化された事例と反実仮想の測定機構を公開する。寄与の分離、正味の費用、独立検証は未完成である。8 19 28

エージェント型ソフトウェア時代における競争力の持続性 — 4/10。 トランザクションの厚みと経済的な履行ロジックには持続的な価値がある。ルールや管理に対話層を載せることは、ソフトウェア開発費用の低下に対して、はるかに弱い防御にしかならない。1 13

出典

[1] Sterling Order Management Systemの製品概要

出典。2026年11月4日閲覧。

[2] Planning Analyticsによるサプライチェーン計画

出典。2026年11月4日閲覧。

[3] Sterling Intelligent Promising Premium

出典。2026年11月4日閲覧。

[4] 最適化の目的関数

出典。2026年11月4日閲覧。

[5] 最適化の目的:品切れ回避

出典。2026年11月4日閲覧。

[6] 最適化の目的:値下げ回避

出典。2026年11月4日閲覧。

[7] Sterling Intelligent PromisingのFAQ

出典。2026年11月4日閲覧。

[8] Benefitsレポート

出典。2026年11月4日閲覧。

[9] シナリオ:品切れ回避の最適化

出典。2026年11月4日閲覧。

[10] 品切れと値下げの回避設定

出典。2026年11月4日閲覧。

[11] Planning Analytics:予測の詳細設定タブ

出典。2026年11月4日閲覧。

[12] Planning Analyticsのシステムと機能の設定

出典。2026年11月4日閲覧。

[13] Order HubのAIエージェント

出典。2026年11月4日閲覧。

[14] エージェント型AIの新機能

出典。2026年公開または更新、2026年11月4日閲覧。

[15] AIエージェントへのアクセス設定

出典。2026年11月4日閲覧。

[16] Sterling Intelligent Promisingのコンテナ要件

出典。2026年11月4日閲覧。

[17] Sterling Intelligent Promisingの2025年リリース履歴

出典。2025年公開または更新、2026年11月4日閲覧。

[18] AIVI:IBM Sterling OMS開発者

出典。2026年11月4日閲覧。

[19] Novolexの事例

出典。2021年3月公開または更新、2026年11月4日閲覧。

[20] hagebauの事例

出典。2023年10月公開または更新、2026年11月4日閲覧。

[21] IBMが専門職向けの新たなWatsonソリューションを発表

出典。2016年10月25日公開または更新、2026年11月4日閲覧。

[22] IBMがIBM Sterlingブランドを立ち上げ

出典。2019年10月公開または更新、2026年11月4日閲覧。

[23] MaerskとIBMがTradeLensを終了

出典。2022年11月29日公開または更新、2026年11月4日閲覧。

[24] Supply Chain Intelligence Suite SaaSのライフサイクル

出典。2026年2月13日公開または更新、2026年11月4日閲覧。

[25] Supply Chain Intelligence SuiteとBlockchain Transparent Supplyの撤退

出典。2025年1月14日公開または更新、2026年11月4日閲覧。

[26] APIの権限設定

出典。2026年11月4日閲覧。

[27] Sterling OMSのセキュリティプロパティ

出典。2026年11月4日閲覧。

[28] IBMが初の認知型サプライチェーンを構築

出典。2022年7月公開または更新、2026年11月4日閲覧。