市場調査に戻る
SAPはERP、サプライチェーン計画、倉庫管理、輸送ソフトウェアを提供する。クラウド計画アプリケーションのSAP Integrated Business Planning（IBP）は、需要予測、在庫目標、生産・配送計画、受注への割当、販売・操業計画を組み合わせる。SAP S/4HANAなどの取引システムと接続し、計画担当者向けにウェブアプリケーションとExcelアドインを提供する。本評価はIBPと、その計算を実行業務につなぐインターフェースを中心に扱う。(1, 2)
サプライチェーン総合評価：5.2/10
| 評価分野 | 点数 |
|---|---|
| サプライチェーンへの深さ | 5.0/10 |
| 意思決定と最適化の実質 | 5.0/10 |
| 製品とアーキテクチャの整合性 | 5.2/10 |
| 技術的透明性 | 6.4/10 |
| ベンダーの真剣さ | 4.6/10 |
SAPは、異なる計画問題を中心に構成された複数の本格的な数値計算エンジンを提供する。在庫最適化は、サービス目標に対して在庫を配置する際に需要とリードタイムの不確実性を扱う。供給最適化エンジンは、金銭的コストまたは配送優先度を用い、混合整数線形の定式化によって生産、調達、輸送数量を選ぶ。根本的な制約は計算間の受け渡しにある。在庫目標が供給計画に渡され、その周囲の目的、方針、例外は計画担当者が維持する。ネットワーク全体の在庫計算があることは、そこから生じる購買・生産の意思決定に共通の確率的な経済目的があることを証明しない。(3, 4, 6)
文書からは、いくつかの弱点が例外的なほど具体的に見える。SAPは、離散的な選択肢を除いたり、モデル化する将来を短縮したりする性能改善策を説明している。文書化された時系列ベースの保存期間ワークフローでは、利用可能な在庫が後続の最適化から抜け落ちる場合がある。一方、最新の自律型サプライチェーンの発表でも、シナリオの選択と対策の承認を計画担当者が担う。周辺のERP連携が機能していても、これはモデルの忠実性と生産性に重大な制約を与える。(7, 10, 11, 12)
SAPとLokadの比較
部品を今購入するか、納入を早めるか、完成品の販売が遅れるリスクをある程度受け入れるかを判断するメーカーを考える。SAP IBPは、需要とリードタイムの不確実性に対する在庫目標を計算し、設定されたコストで制約付き供給計画を生成できる。利益最大化モードでは、売上額で生産、在庫、輸送、部品のコストを賄えない需要を拒否できる。財務計算は明示されているが、あらかじめ定めた需要・供給シナリオへの依存が中心に残る。(4, 6)
Lokadの文書化された運用モデルは、確率的な需要、リードタイム、その他の関連する不確実性を、経済価値順に並べた意思決定の計算に組み込む。サプライチェーンサイエンティストが顧客と実行可能な意思決定ロジックを維持し、取引システムが結果の注文を記録して実行する。改善対象とする単位は再利用可能な計算だ。仕入先の遅延によって買うべきものが変わるなら、再び手作業で例外処理を繰り返さずとも、修正が今後の購買判断に反映されるべきである。在庫最適化と、より広い設計思想を扱うIntroduction to Supply Chainを参照されたい。
SAPは、はるかに広い取引・実行業務の範囲を提供する。企業はその範囲を保持したまま、計画計算を置き換えたり補完したりできる。本質的な比較は、どれだけの経済情報が計画工程を通じて維持され、改善にどれだけの作業を要するかにある。SAPは豊富な設定・連携管理機能を公開するが、数値計算エンジンにはベンダーが定めた境界が残る。Lokadの顧客別意思決定ロジックにも保守は必要だ。その提案価値は、この作業を、予測、安全在庫、ペナルティ、計画上の例外を調整し続けるよりも生産的にすることにかかっている。
IBPが計算するもの
不確実性は在庫目標に入る
IBP 2608の在庫文書は、多段階の在庫計算に予測誤差、間接需要、リードタイムの変動、補充頻度、ロットサイズを明示的に含めている。在庫保有コストがネットワーク内の配置に影響する。これは需要予測だけにとどまらない、供給の不確実性への実質的な対応を裏付ける。在庫FAQは顧客サービスレベルを制約とする確率的非線形ソルバーを説明し、現行アプリケーションガイドは、その水準を維持しながら在庫コストを最小化することを目的としている。(3, 4)
出力の内容が重要だ。在庫目標は応答・供給計画への入力になるか、外部の業務システムへ渡される。安全在庫目標は所定の補充方針のもとで不確実性を要約するが、将来の入荷、需要、経済的結果の分布全体を、下流のあらゆる意思決定へ運ぶものではない。平均リードタイムが同じ二つの仕入先でも、分布の裾のリスクは大きく異なり得る。望ましい調達先は、完成品の利益率、能力の代替用途、遅延後に取れる選択肢によって変わり得る。検証した資料は、これらの相互作用が一つの確率的な購買・生産目的に入ることを示していない。
SAPは供給変動に起因する在庫も切り分ける。その計算は、予測需要または伝播させた需要の平均と、生産・輸送リードタイム誤差の標準偏差を用いる。これは維持可能な入力機構を示すが、混乱とその結果について較正された同時分布は示さない。これらのパラメータをシステムに取り込み、更新し、仮定が今も成立するか確認する作業も、ソリューション運用の一部となる。(5)
経済的コストと誘導ペナルティが競合する
供給最適化エンジンは利益最大化と配送最大化の双方をサポートする。後者は未配送ペナルティを十分に引き上げ、製品の収益性にかかわらず充足を優先する。SAPはさらに、実際の金銭支出を表さずに調達先の選好を誘導する追加コストを明示的に認める。したがって、コスト目的があるだけでは、設定された目的がお金を測っているとは限らない。(6)
この違いは受注ベースの公平配分計画で明確になる。SAPは充足率に応じてコストを加え、不足や余剰をより均等に配分する。文書にある一つの在庫優先度設定では、拠点間で等しい保有コストが必要となる。これらは配分方針を符号化する仕組みだ。その経済的妥当性は、顧客利益率、不足の結果、廃棄リスクが異なるとき、均等な扱いに機会費用を払う価値が本当にあるかによる。(8)
実務上のリスクは、例外が積み重なり、人工的な価格の層がさらに増えることだ。ある計画担当者が望む結果が出るまでペナルティを上げ、別の担当者が後から競合するペナルティを変える。最適化エンジンはその結果、利益との関係が不明瞭になった設定を正確に最小化し得る。このような導入を評価するには、主要なコスト係数を事業上の結果までたどり、サービスKPIが捉えない損失も含め、生成される意思決定を調べる必要がある。
離散制約がスケーラビリティとの交換条件を露呈する
SAPは2015年4月、IBPの供給定式化を混合整数線形計画として説明した。最小ロットと固定費は二値変数を必要とし、記事は離散的な意思決定を計画期間の初期部分に制限することを勧めた。その後更新された性能ガイドも、期間の短縮、時間集約、緩く結合したサブネットワークの分離、製品分解を推奨する。共有資源と集約制約が難しさの原因であることを明示している。(15, 22)
これらの簡略化は、まさに経済価値を左右し得る相互作用を取り除く。今日購入する一ロットは資金を消費し、数か月後に陳腐化在庫を残すかもしれない。ある工場の能力判断は、別の工場が何を生産すべきかを変える場合がある。問題を短縮・分離すれば計算可能になっても、そうした選択への答えが弱まる可能性がある。多数の不確実な未来に定式化を拡張すれば、さらに計算負荷が増す。数学的に表現できることだけでは、実用的な解決策とはならない。
現行の局所最適化文書は特に具体的だ。この手法はまず離散制約を緩和し、その後、意思決定の部分集合を丸めて固定する。初期解として使う場合、その後に主最適化エンジンを実行する。単独モードでは実行時間が短いと一部の離散要件が満たされないままとなり、文書は固定能力消費などを非対応機能に挙げる。これらは当該モードの制約であり、IBPのすべての最適化実行に当てはめるべきではない。(7)
SAPが公開する携帯電話会社のベンチマークは、MPS形式の実際のMILPインスタンスを提供する。特定の定式化を再現でき、ソルバー比較に役立つ。しかし、そのモデルの経済目的が仕入先の障害、製品採算の変化、欠落した行動に耐えられるかは試さない。(32)
文書化された保存期間の境界
時系列ベースの結合ワークフローは、まず保存期間ヒューリスティックで期限切れに近い在庫を配分し、残った所要量を供給最適化エンジンに渡す。最適化エンジンには、残存する期限付き在庫も、関連する最低残存保存期間の要件も渡らない。SAPはその結果、既存在庫で満たせた需要に対して生産を計画する場合があると明示的に警告する。この最適化エンジンが生成した新規生産と外部入荷は、統合出力上では保存期間が無期限として表現される。(10)
これは経済的な結果を伴う具体的な計算上の分断だ。利用可能な在庫と新規生産が、同時に評価されることなく同じ需要を奪い合い得る。共通の指標に双方の結果を表示しても、その分断は直らない。生鮮・腐敗性商品では、購入企業は実際の計画モード、境界で抜け落ちる意思決定、その解決に継続的な介入が必要かを確認すべきだ。この指摘の対象は文書化された当該時系列ワークフローであり、SAPの倉庫機能や受注ベースの保存期間機能すべてではない。
デマンドセンシングと情報のタイミング
SAPのデマンドセンシング処理は、日次または週次の定期バッチを実行する。受注、配送、予測スナップショット、販促、任意の外部信号を用い、文書のワークフローには勾配ブースティング、週次調整、日次への分解、上限、予測消費ルールが含まれる。計画担当者は分解プロファイルを上書きできる。製品の導入・終売時には、一部機能は週次の学習パターンを使わず、後処理に限定される。(9)
名称自体が別の経済的能力を加えるわけではない。有用な中身は具体的な計算だ。検証では、同じ意思決定期限に入手可能だった同じ情報を用いて予測を比較しなければならない。調達を確定した後に届く受注は、短期予測を改善できても購入判断を改善しない。同様に、週次予測を日次数量へ分けるには日次意思決定レベルの根拠が必要だ。週次の精度では、販促ピークや生鮮品廃棄をうまく扱えたことは証明できない。
技術の歴史：持続するエンジニアリングと繰り返される再出発
| 時期 | 公開された技術の方向性 | 記録から確認できること |
|---|---|---|
| 2010–2015 | HANAとリアルタイムのサプライチェーン | SAPは2010年にHANAを導入し、2013年のSmartOps買収をリアルタイム計画に結びつけた。2015年の最適化記事では従来型のMILP定式化を説明した。(13, 14, 15) |
| 2017 | LeonardoとCoPilot | Leonardoは機械学習、ブロックチェーン、IoT、対話型アプリケーションをまとめた。CoPilotの初期出荷版は、メモ、スクリーンショット、文脈付きチャット、業務オブジェクト認識、簡易作成操作を提供した。(16, 18) |
| 2020 | ブロックチェーンのホスティング縮小 | SAPは、新規顧客と更新契約向けのMultiChain・Quorum提供の終了を発表し、これらのオープンソース部品のホスティングから離れた。既存契約はその条件で継続した。(17) |
| 2019年の文書以降；2023年1月 | 旧世代のアシスタントが保守段階へ | CoPilotのヘルプは製品を保守段階とし、デジタルアシスタント機能についてConversational AIへ案内する。Conversational AI自体も2023年1月に保守段階へ入った。(19, 20) |
| 2026 | Jouleと自律型サプライチェーン | 10月の発表はシナリオ分析、根本原因の提案、物流対策を説明し、新機能の一般提供を第4四半期に予定する。11月の説明でもシナリオ評価と重要な意思決定を計画担当者が担う。(11, 12) |
HANAは技術基盤として存続し、保存・実行の仕組みも文書化されている。それでも2013年のリアルタイムの主張は、データベース性能の提案と、はるかに広い意思決定の提案を混ぜていた。計画データへの高速なアクセスがコストモデルを改善したり、不確実な未来を表現したりするわけではない。現行の最適化サービスは別の計算インフラでも動くため、データベースの速度と最適化全体の待ち時間を混同すべきではない。(14, 23)
アシスタントの変遷はさらに懸念を生む。SAPは賢い企業業務への新たな道を繰り返し示す一方、以前のアシスタント製品は保守段階へ入った。2017年のリリース説明は初期タスクの限界を明示していた。この一連の流れに依然欠けているのは、どれほどの計画作業が消え、以前の約束のどれが実現し、世代間で顧客が何を再構築しなければならないかを継続的に測った説明だ。今日の言語モデルで、過去の企業インテリジェンスの物語を後から正当化することはできない。
ブロックチェーンからの撤退も、実際のエンジニアリング範囲を示す点で参考になる。SAPは第三者の台帳技術を提供し、その後、別のホスティング方式へ顧客を誘導した。記録は製品へのコミットメントが変わったことを示す。台帳のホスティングが在庫や生産の経済性を改善したという根拠はない。この歴史を踏まえると、意思決定レベルで持続的な価値提供が示されるまで、次の大きな変革の主張への信頼は下がる。
ソフトウェア構成と保有コスト
以下の部品には、評価した計画アーキテクチャ内で確認できる役割がある。
| 部品 | 文書化された役割 | 保有する上での影響 |
|---|---|---|
| HANAとSQLScript | データベース・計算環境。SAPの受注ベースIBP計画の求人はHANA SQLScriptを挙げる。(21) | データ処理、モデル有効化、データベース実行に専門的なエンジニアリングを要する。 |
| ABAP、JavaScript、OData | 同じ開発チームの求人がIBP Supplyにこれらの技術を挙げる。(21) | ロジックとインターフェースがバックエンド、画面、サービスの境界にまたがる。 |
| SAP BTP Kubernetes上のSCM Optimization | IBPは計画データを前処理し、ハイパースケーラーの計算クラスターへ送り、結果を受け取る。(23) | 計画実行にはデータベースや画面の遅延以外に、転送、ソルバー実行、再統合が含まれる。 |
| Excelアドインとウェブ計画アプリケーション | 計画担当者が指標、プロファイル、計画を確認・変更する。(2, 9) | クライアント互換性、テンプレート、権限、手動編集が運用環境の一部に残る。 |
| 統合サービスとAPI | 時系列計画データと購買文書は別々のインターフェースで扱い、統合の製品構成は2026年4月に変わった。(28, 29, 33) | マッピング、照合、インターフェース保守、ライセンスをTCOへ含める必要がある。 |
HANAの列ストア管理文書は、インメモリという提案の裏にある工学的な交換条件を示す。書き込みは圧縮効率が低く、古いレコード版を保持し得るデルタ領域に蓄積し、マージによってその状態が統合される。文書はメモリ逼迫、長時間のマージ、手動マージ後の別個の圧縮動作を扱う。これらには容量確保と運用上の配慮が必要だ。その存在から特定のIBPテナントのコストは測れないが、高速なインメモリアクセスを無償のアーキテクチャ上の利点と扱うことはできない。(24)
2026年4月20日より後に取得する新規IBPライセンスについて、SAPの機能文書は従来のS&OPとControl Towerの機能を必須のfoundationライセンスにまとめる。既存のCloud Integration for data services接続は旧ライセンスのもとで継続できるが、新規契約者は別ライセンスのSAP Integration Suiteへ案内される。したがって導入費用を見積もるには、実際の契約世代と統合設計が必要だ。統合されたSAPスイートという一般的な図では、商業上重要な境界が隠れる。(2, 33)
設定は継続的なソフトウェア上の責任である
モデル設定ガイドは、属性、マスターデータ、計画レベル、指標、計算、バージョン、スナップショットを説明する。ソフトウェアコレクションによる移送を用意し、初期設定のアップロードと本番への昇格を区別する。SAPは本番環境でバイナリアップロード経路を直接使わないよう明示的に警告する。作成の多くがフォーム上で行われても、これは成果物と依存関係を伴う開発ライフサイクルだ。(25)
リードタイムの定義変更は、需要の伝播、予測誤差の選択、在庫目標、下流の供給に影響し得る。新たなコストは公平配分の段階や既存ペナルティと相互作用する可能性がある。したがって設定の維持には、事業と計算グラフの両方を理解する人材に加え、管理された昇格と回帰確認作業が必要だ。サブスクリプション料とホスティング料は、顧客、SAP、導入パートナーの誰が行うにせよ、この反復的な労働を含んでいない。
改善を判断する決定的な試験は、有害な推奨への対応だ。チームは欠落した相互作用を特定し、出力を上書きするのではなく問題そのものを変え、過去の意思決定を再現し、持続する修正を導入できるか。SAPは幅広いモデル設定を公開するが、アルゴリズム内部と利用可能な意思決定構造はエンジンに制約される。在庫FAQはアルゴリズムの検査を明確に非公開としている。公開パラメータを繰り返し調整しても、欠けた行動や相互作用をすべて解決することはできない。これはHolimizationで論じる違いだ。事業を通じて初期定式化の見落としが明らかになるにつれ、最適化は改訂可能でなければならない。(3, 25)
自動化、セキュリティ、経済的責任
計画が速くなっても計画作業は残る
SAPのSLB事例は、最大三週間かかっていた計画作業が一週間未満へ、別の作業は二週間から一日未満へ短縮されたと報告する。同じ記事は、四年間で10億ドル超の在庫削減効果と、三年間で在庫日数が37%減ったことを報告する。これはプロセス、変革管理、ソフトウェアの取り組みによる、顧客に帰属させた成果だ。製品デモより実質的な結果を示している。(30)
記事は、チームがデータ収集からシミュレーションとシナリオ計画へ移ったとも述べる。残る総人員、パートナーとベンダーの作業量、導入と継続保守を差し引いた収益は示さない。計画の経過時間を減らし、計画担当者の作業を再配分しても、無人の意思決定工程に必要な労働量は分からない。エージェントによって反復的な分析やソフトウェア変更が安価になる中では、そこが比較すべき点になる。
2026年の発表にもこの緊張関係が残る。Logistics Issue Resolution Agentは数時間の問題をワンクリックの判断へ短縮すると説明され、Supply Chain Planning Assistantは原因と是正案の特定を支援する。11月の説明では、アシスタントが需要、在庫、能力のエージェントを調整してシナリオを作り、評価を計画担当者に委ねる。調査時間は減らせても、文書のワークフローはなお個別の意思決定に人の注意を集中させる。発表は総反復作業量を定量化せず、意思決定全体にわたる経済的な選択も実証していない。(11, 12)
SAPには既存の定期ジョブとデータAPIもある。エージェントの生産性はその既存の自動化を基準に測る必要がある。古いバッチを起動したり例外を表示したりする会話リクエストに、新しい数値計算エンジンを開発した功績を与えるべきではない。より価値のある改善は、反復する修正を再利用可能にし、そもそもそうした例外が必要になる頻度を減らすことだ。
権限には運用上の例外がある
SAPのセキュリティガイドは具体的なアクセス制御表を公開する。文書化された版では、計画バージョン全体のコピー・削除に権限フィルターは適用されず、コピー演算子の書き込みフィルターには明示的な設定が必要だ。これらの操作には対応する認可境界が要る。ユーザーの計画画面が制限されていても、認可されたジョブが変更できる範囲を一律に制限するものではないからだ。(26)
受注・在庫の権限モデルは、複数のフィルターが和集合として結合され、追加の割当によってアクセスが拡大することも明記する。変更履歴はフィルターの変更を記録する。これは重要な管理上の影響を持つ、検査可能な仕組みだ。最小権限を守るには、アカウント侵害や誤った自動化の影響も含め、ロール、フィルター、統合、ジョブを組み合わせた実効的な結果を試す必要がある。(27)
認証はこの問いに答えない。有用なセキュリティの根拠は、文書化された境界と、誤りの後に被害を封じ込められるかである。
成果には検証可能な経済的範囲が要る
SLB事例は、一部事業分野で予測精度が90%に近づいたことを挙げるが、誤差指標、重み、製品・拠点の粒度、期間を定義しない。その割合では詳細な購買判断を裏付けられない。製品や期間を集約すると、業務レベルに不足と過剰が残っていても誤差が相殺され得る。在庫と計画時間の成果は別の主張であり、精度の割合はそれらの因果的な帰属を検証するものではない。(30)
STIHLの記事は有用な導入範囲を示す。初期展開は二つの生産拠点で、製造計画・スケジューリング、輸送管理と連携し、ネットワーク計画を約43の子会社へ広げる計画が記されている。これは段階的な導入とアプリケーション連携の記録であり、全世界の最適化が完了した結果ではない。(31)
検証可能な経済的提案なら、基準、対象の意思決定、評価期間、反復的な労働とソフトウェア費用、不適切な推奨を直す責任を定義する。検証した公開事例は、その完全な収支を示さない。導入と報告された便益は裏付ける一方、その価値のどれほどをIBPに帰属できるか、計画環境の継続費用を超えるかの判断は顧客に残る。
サプライチェーン評価
総合点は、以下の25項目の編集評価の算術平均である。
サプライチェーンへの深さ：5.0/10
| 評価項目 | 点数 |
|---|---|
| 経済的な捉え方 | 6/10 |
| 意思決定としての到達点 | 7/10 |
| サプライチェーンに関する概念の明晰さ | 6/10 |
| 時代遅れの中核的教義からの独立 | 3/10 |
| KPIの見せかけへの耐性 | 3/10 |
平均：5.0/10。
経済的な捉え方 — 6/10。 利益最大化は、商業的に有益な需要と、満たす費用が高すぎる需要を区別できる。サービス目標、配送最大化、人工的な誘導コストは、その経済目的と競合する。どの解釈が意思決定を支配するかは、導入された設定によって決まる。(6, 8)
意思決定としての到達点 — 7/10。 IBPは購買文書インターフェースと実行システムへの接続を備え、調達、生産、配送、割当計画を計算する。業務上の結果を伴う意思決定まで到達する。在庫部品の目標とシナリオ検討ワークフローは、重要な選択・実行責任を個別計算の外に残す。(1, 29, 31)
サプライチェーンに関する概念の明晰さ — 6/10。 多階層部品表、ネットワーク在庫配置、有限資源、不確実な補充は、詳細な業界知識を示す。在庫目標と供給計画の分離によって、それらの能力間で結びついた経済性の扱いが弱まる。(1, 4, 5)
時代遅れの中核的教義からの独立 — 3/10。 合意型計画、サービス目標、担当者が検討するシナリオ、方針に基づく配分が依然として構成原理となっている。これらの仕組みは相当な手作業の計画役割を維持し、次の意思決定の経済価値より計画への準拠を優先し得る。(1, 8, 12)
KPIの見せかけへの耐性 — 3/10。 SAPは顧客の在庫成果を公表するが、SLBの精度主張には解釈に必要な指標と業務上の粒度が欠ける。その定義がない高い割合は、SKU単位のより良い意思決定を示さずに営業上の魅力を加える。(30)
意思決定と最適化の実質：5.0/10
| 評価項目 | 点数 |
|---|---|
| 確率的モデリングの深さ | 5/10 |
| 独自の最適化または機械学習の実質 | 6/10 |
| 現実の制約への対応 | 5/10 |
| 意思決定の自動化と労働生産性 | 5/10 |
| 現実の業務の複雑さへの耐性 | 4/10 |
平均：5.0/10。
確率的モデリングの深さ — 5/10。 在庫最適化は多階層にわたる需要とリードタイムの変動を明示的に考慮する。評価した工程は在庫目標を出力するため、後続の供給計算について、同時確率を扱った意思決定の選択や、重要な裾の依存関係の較正は実証されない。(4, 5)
独自の最適化または機械学習の実質 — 6/10。 SAPは数値定式化、多段階在庫エンジン、具体的なデマンドセンシング工程、公開ソルバーインスタンスを文書化する。これらはエンジニアリングの実質を示す。個々の手法が機能する根拠に比べ、完全なシステムが独自の経済効果を生む根拠は少ない。(3, 9, 32)
現実の制約への対応 — 5/10。 供給定式化は有限能力、資材フロー、ロットサイズ、固定費を含む。局所最適化と結合された保存期間ワークフローは重大な限界を示す。単独モードでは一部の離散制約が満たされない場合があり、期限の迫る在庫は次の計算から消え得る。これらの欠落は実行可能な数量とコストを変え得る。(7, 10, 15)
意思決定の自動化と労働生産性 — 5/10。 定期的な数値計算と報告された計画時間の短縮は、有用な自動化を裏付ける。現在のアシスタント説明には、人による調査、シナリオ評価、対策選択が残る。顧客、ベンダー、パートナーに残る総労働量は測定されていない。(9, 11, 12, 30)
現実の業務の複雑さへの耐性 — 4/10。 設定可能なモデルでは事業ロジックを変えられるが、SAPの性能改善策は離散的な選択肢、長い期間、共有する相互作用を除き得る。その圧力は新たに見つかった経済関係を取り込む能力を制限する。モデルの移送だけでは、実際の業務損失に対する再現と管理された改善を示せない。(22, 25)
製品とアーキテクチャの整合性：5.2/10
| 評価項目 | 点数 |
|---|---|
| アーキテクチャの一貫性 | 5/10 |
| システム境界の明確さ | 7/10 |
| セキュリティへの真剣さ | 5/10 |
| ソフトウェアの簡潔さと保有コスト | 3/10 |
| プログラム経由・エージェント支援の運用への適合性 | 6/10 |
平均：5.2/10。
アーキテクチャの一貫性 — 5/10。 IBPは共有のモデリング・統合機能を提供する一方、在庫、供給最適化、実行は別々の責任を保つ。文書化された保存期間の受け渡しは、共有出力表が意思決定計算の重大な断絶を隠し得ることを示す。(4, 10, 25)
システム境界の明確さ — 7/10。 SAPは最適化の実行場所、時系列・受注ベース計画それぞれに適用するデータAPI、別ライセンスを必要とする統合サービスを文書化する。これらの境界は調べられる。ただし、バージョン、モジュール、契約世代の多さにより、実際の導入範囲の特定は複雑になる。(2, 23, 28, 29, 33)
セキュリティへの真剣さ — 5/10。 公開された権限表とフィルター変更履歴は、検査・試験できる仕組みを示す。バージョン全体の操作と累積権限には、他の認可を通じた意図的な封じ込めが必要だ。評価した証拠では、特権アカウントや統合が侵害された後の被害境界が十分に示されない。(26, 27)
ソフトウェアの簡潔さと保有コスト — 3/10。 文書にあるデータベース、アプリケーション、最適化クラスター、インターフェース、クライアントの各層は、複数の保守責任を生む。顧客固有の計算グラフ、ペナルティ、移送工程が継続的な専門作業を加える。公開便益の主張に対応する完全な運用費の説明はない。(21, 23, 24, 25)
プログラム経由・エージェント支援の運用への適合性 — 6/10。 APIと定期ジョブは画面を繰り返し操作せず実行することを可能にする。版管理された設定も管理可能な成果物となる。データと既存ジョブへのプログラム経由のアクセスは、独自アルゴリズムへの同等の制御を提供するものではなく、エージェントが数値定式化を安全に改善することも示さない。(25, 28, 29)
技術的透明性：6.4/10
| 評価項目 | 点数 |
|---|---|
| 公開技術文書 | 8/10 |
| ベンダーの仲介なしでの検査可能性 | 6/10 |
| 移植性とロックインの可視性 | 5/10 |
| 導入方法の透明性 | 7/10 |
| 技術的主張を支える証拠の密度 | 6/10 |
平均：6.4/10。
公開技術文書 — 8/10。 SAPは入力、アルゴリズム、設定、統合、権限、既知の計算限界について広範なガイドを公開する。保存期間への明示的な警告とモード固有の最適化制約により、販売説明をはるかに超えて製品を評価できる。(7, 10, 25, 26)
ベンダーの仲介なしでの検査可能性 — 6/10。 公開の数学的説明とダウンロードできるMILPインスタンスは外部からの検査を可能にする。在庫アルゴリズムは非公開のままで、最適化インスタンスの一例は本番の意思決定エンジン全体を開示しない。(3, 15, 32)
移植性とロックインの可視性 — 5/10。 データのエクスポート・インポートは文書化され、ソフトウェアコレクションはSAPシステム間で設定を移す。これらは移せるものを明らかにする一方、SAPの計画上の意味体系、アプリケーション、数値演算子への大きな依存を残す。(25, 28, 29)
導入方法の透明性 — 7/10。 設定ガイドはモデルのエンティティ、依存関係、有効化、昇格を説明する。性能ガイドは業務機能が計算可能性に及ぼす影響を論じる。顧客は導入作業の多くを理解できるが、最終的な工数と経済的な妥当性は案件によって異なる。(22, 25)
技術的主張を支える証拠の密度 — 6/10。 仕組みの文書と導入説明は、既存製品の大部分を支える。最新の自律性の物語や報告された精度割合では、意思決定品質、残存労働、純収益の水準での検証がはるかに薄い。(11, 12, 30, 31)
ベンダーの真剣さ：4.6/10
| 評価項目 | 点数 |
|---|---|
| 公開発信の技術的な真剣さ | 5/10 |
| 技術ロードマップの一貫性 | 4/10 |
| 概念の明晰さ | 5/10 |
| 経済的責任 | 3/10 |
| エージェント型ソフトウェア時代の競争優位の持続性 | 6/10 |
平均：4.6/10。
公開発信の技術的な真剣さ — 5/10。 エンジニアリング文書は手法と限界を具体的に挙げる。企業発信はそれらの特定能力から、意思決定工程全体の自律化について同等の証拠がないまま、広範な自律型サプライチェーンの主張へ進む。(10, 11, 12, 22)
技術ロードマップの一貫性 — 4/10。 HANAと数値計画には継続的な開発が見られる。ブロックチェーンのホスティング撤退と相次ぐアシスタントの保守移行発表は、大きな革新の物語が製品へのコミットメントの変化も生んだことを示す。現在のエージェント提案には、これらの世代を通じて提供した価値の連続性を測定する必要がある。(14, 17, 18, 19, 20)
概念の明晰さ — 5/10。 SAPはコスト、制約の種類、複数の数値手法を技術的に正確に区別する。より広い説明では可視性、協働、予測、最適化、支援を混ぜ、どの計算が経済的に望ましい行動を実際に選ぶのかを曖昧にする。(1, 6, 12)
経済的責任 — 3/10。 実名事例は在庫と時間の便益を報告するが、完全な基準、純TCO、経済的失敗の判定条件、不適切な推奨の是正責任を定義しない。プロセス変更、統合、顧客の作業、ソフトウェアの間での成果帰属は未解決だ。(30, 31)
エージェント型ソフトウェア時代の競争優位の持続性 — 6/10。 取引連携、サプライチェーンのデータ構造、既存の数値エンジンは、対話画面よりも持続する資産となる。その価値は、意思決定ロジックの運用と改訂にかかる費用を減らせるかによる。主にシナリオ準備を速めるアシスタントでは、従来の計画作業の多くが残る。(12, 23, 25, 31)
出典資料
外部資料は2026年11月4日に確認した。重要な箇所では文書の版を示し、顧客成果はその公表元に帰属させている。
[1] SAP Integrated Business Planningの機能
SAP。日付なし。予測、S&OP、供給計画、割当、可視性という機能範囲。
[2] SAP Integrated Business Planningのアプリケーションと機能
SAP。2605文書。2026年4月20日より後に取得した契約におけるfoundationライセンスと統合の変更。
SAP。日付なし。確率的非線形の在庫計算、サービス制約、出力、非公開のアルゴリズム内部。
SAP。2026年文書。多段階在庫配置、需要・供給の不確実性、保有コスト、下流への目標インターフェース。
SAP。2605文書。供給変動の安全在庫成分に入力する生産・輸送リードタイムの変動。
SAP。2605文書。時系列MILP、財務・配送目的、制約階層、誘導コスト。
SAP。2608文書。初期解モードと単独モード、緩和された離散要件、非対応機能。
SAP。2026年文書。受注ベースの公平配分コスト構成と在庫優先度設定。
SAP。2605文書。入力信号、定期処理、週次調整、日次への分解、上書き。
SAP。2026年文書。時系列の保存期間ヒューリスティックと最適化エンジンの受け渡し、および不要な生産への警告。
[11] SAP、自律型サプライチェーン管理に向けJouleのアシスタントとエージェントを拡充
SAP。2026-10-08。10月のアシスタント発表、事例、2026年第4四半期に予定する一般提供。
[12] SAP、初回の2026年Gartner Emerging Market QuadrantでMarket Shaperに位置付け
SAP。2026-11。エージェントがシナリオを作り、計画担当者が結果を評価する計画アシスタントのワークフロー。
SAP。2013-02-22。SmartOpsとHANAをリアルタイムのサプライチェーン計画に結びつけるSAP作成の買収発表。
SAP。2020-03。2010年の導入からBusiness Warehouse、Business Suite、S/4HANAに至るHANAの変遷。
[15] IBP for Supply Optimizer：その背後の数学
SAP。2015-04-17。IBPのMILPに関する初期の説明と離散化期間の推奨。
SAP。2017-11-13。Leonardoの技術と位置付けについてSAPが2017年に記した記事。
[17] SAP Cloud PlatformのすべてのMultiChain・Quorumサービスを終了
SAP。2020-08-19。既存契約を維持しつつ、新規顧客と更新向けのMultiChain・Quorum提供を終了するSAPの告知。
SAP。2017-05-10。CoPilotの初期出荷機能とデジタルアシスタントへの構想。
SAP。1905文書。CoPilotの保守状態とアシスタント機能のConversational AIへの移行。
SAP。2023-01のライフサイクル通知。2023年1月以降のConversational AIの保守状態。
[21] SAP Integrated Business Planningの開発者
LinkedIn上のSAP。日付なしの雇用主求人。SAPが作成した受注ベースIBP Supply開発の求人で、当該チームが用いる技術を挙げる。
[22] 時系列ベースの供給最適化エンジン：性能に関する注記
SAP。2018-06-08、後に更新。SAPの最適化性能ガイド。2018年6月の公開以降にページが更新されている。
[23] 時系列ベースの供給計画でのSCM Optimizationの利用
SAP。2605文書。前処理、SAP BTP Kubernetes上のハイパースケーラー計算クラスター、計画結果の返却を文書化。
SAP。HANAプラットフォーム文書。HANA列ストアのデルタ保存、手動マージ、メモリ上の考慮事項、圧縮動作。
SAP。2511。計画モデルのエンティティ、計算依存関係、ソフトウェアコレクション、本番昇格のガイド。
SAP。2605文書。アプリケーションごとの権限フィルターの範囲と例外。
SAP。2026年文書。受注・在庫の権限、累積アクセス付与、フィルター変更履歴。
SAP。2602文書。ODataによる時系列指標の入出力と、受注指標が対象外であること。
SAP。2026年文書。受注ベース計画向けの購買文書の入出力。
[30] SLBがSAP IBPでサプライチェーンを改善した方法
SAP。2025-08-05。SLBの計画時間、在庫、予測精度の成果に関するSAPの記事。
SAP。2024-12。STIHLの初期導入、アプリケーション統合、予定する子会社への拡大に関するSAPの記事。
[32] SAPのサプライチェーンMILPベンチマークインスタンス
GitHub上のSAP。2023年のリポジトリ。架空の携帯電話メーカーについてSAPが公開したMPS最適化インスタンス。
[33] SAP Cloud Integration for Data Servicesを用いたデータ統合
SAP。2026年文書。既存のCI-DS連携と、2026年4月20日より後の新規IBPライセンスで利用できないこと。